1. 02 8月, 2014 1 次提交
  2. 21 7月, 2014 4 次提交
  3. 18 7月, 2014 3 次提交
    • B
      net: huawei_cdc_ncm: add "subclass 3" devices · c2a6c781
      Bjørn Mork 提交于
      Huawei's usage of the subclass and protocol fields is not 100%
      clear to us, but there appears to be a very strict system.
      
      A device with the "shared" device ID 12d1:1506 and this NCM
      function was recently reported (showing only default altsetting):
      
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        1
            bAlternateSetting       0
            bNumEndpoints           1
            bInterfaceClass       255 Vendor Specific Class
            bInterfaceSubClass      3
            bInterfaceProtocol     22
            iInterface              8 CDC Network Control Model (NCM)
            ** UNRECOGNIZED:  05 24 00 10 01
            ** UNRECOGNIZED:  06 24 1a 00 01 1f
            ** UNRECOGNIZED:  0c 24 1b 00 01 00 04 10 14 dc 05 20
            ** UNRECOGNIZED:  0d 24 0f 0a 0f 00 00 00 ea 05 03 00 01
            ** UNRECOGNIZED:  05 24 06 01 01
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x85  EP 5 IN
              bmAttributes            3
                Transfer Type            Interrupt
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0010  1x 16 bytes
              bInterval               9
      
      Cc: Enrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2a6c781
    • B
      net: qmi_wwan: add two Sierra Wireless/Netgear devices · 53433300
      Bjørn Mork 提交于
      Add two device IDs found in an out-of-tree driver downloadable
      from Netgear.
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53433300
    • D
      wan/x25_asy: integer overflow in x25_asy_change_mtu() · a28d0e87
      Dan Carpenter 提交于
      If "newmtu * 2 + 4" is too large then it can cause an integer overflow
      leading to memory corruption.  Eric Dumazet suggests that 65534 is a
      reasonable upper limit.
      
      Btw, "newmtu" is not allowed to be a negative number because of the
      check in dev_set_mtu(), so that's ok.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a28d0e87
  4. 17 7月, 2014 4 次提交
    • C
      net: ppp: fix creating PPP pass and active filters · cc25eaae
      Christoph Schulz 提交于
      Commit 568f194e ("net: ppp: use
      sk_unattached_filter api") inadvertently changed the logic when setting
      PPP pass and active filters. This applies to both the generic PPP subsystem
      implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP subsystem
      implemented by drivers/isdn/i4l/isdn_ppp.c. The original code in ppp_ioctl()
      (or isdn_ppp_ioctl(), resp.) handling PPPIOCSPASS and PPPIOCSACTIVE allowed to
      remove a pass/active filter previously set by using a filter of length zero.
      However, with the new code this is not possible anymore as this case is not
      explicitly checked for, which leads to passing NULL as a filter to
      sk_unattached_filter_create(). This results in returning EINVAL to the caller.
      
      Additionally, the variables ppp->pass_filter and ppp->active_filter (or
      is->pass_filter and is->active_filter, resp.) are not reset to NULL, although
      the filters they point to may have been destroyed by
      sk_unattached_filter_destroy(), so in this EINVAL case dangling pointers are
      left behind (provided the pointers were previously non-NULL).
      
      This patch corrects both problems by checking whether the filter passed is
      empty or non-empty, and prevents sk_unattached_filter_create() from being
      called in the first case. Moreover, the pointers are always reset to NULL
      as soon as sk_unattached_filter_destroy() returns.
      Signed-off-by: NChristoph Schulz <develop@kristov.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc25eaae
    • A
      net/mlx4_en: cq->irq_desc wasn't set in legacy EQ's · 858e6c32
      Amir Vadai 提交于
      Fix a regression introduced by commit 35f6f453 ("net/mlx4_en: Don't use
      irq_affinity_notifier to track changes in IRQ affinity map").
      When core is started in legacy EQ's (number of IRQ's < rx rings), cq->irq_desc
      was NULL.  This caused a kernel crash under heavy traffic - when having more
      than rx NAPI budget completions.
      Fixed to have it set for both EQ modes.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      858e6c32
    • S
      sunvnet: clean up objects created in vnet_new() on vnet_exit() · a4b70a07
      Sowmini Varadhan 提交于
      Nothing cleans up the objects created by
      vnet_new(), they are completely leaked.
      
      vnet_exit(), after doing the vio_unregister_driver() to clean
      up ports, should call a helper function that iterates over vnet_list
      and cleans up those objects. This includes unregister_netdevice()
      as well as free_netdev().
      Signed-off-by: NSowmini Varadhan <sowmini.varadhan@oracle.com>
      Acked-by: NDave Kleikamp <dave.kleikamp@oracle.com>
      Reviewed-by: NKarl Volz <karl.volz@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b70a07
    • M
      r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40 · 7a9810e7
      Michel Dänzer 提交于
      The ethernet port on my ASUS A88X Pro mainboard stopped working
      several times a day, with messages like these in dmesg:
      
      AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e address=0x0000000000003000 flags=0x0050]
      
      Searching the web for these messages led me to similar reports about
      different hardware supported by r8169, and eventually to commits
      3ced8c95 ('r8169: enforce RX_MULTI_EN
      for the 8168f.') and eb2dc35d ('r8169:
      RxConfig hack for the 8168evl'). So I tried this change, and it fixes
      the problem for me.
      Signed-off-by: NMichel Dänzer <michel@daenzer.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a9810e7
  5. 15 7月, 2014 6 次提交
    • O
      hso: fix deadlock when receiving bursts of data · 8f9818af
      Olivier Sobrie 提交于
      When the module sends bursts of data, sometimes a deadlock happens in
      the hso driver when the tty buffer doesn't get the chance to be flushed
      quickly enough.
      
      Remove the endless while loop in function put_rxbuf_data() which is
      called by the urb completion handler.
      If there isn't enough room in the tty buffer, discards all the data
      received in the URB.
      
      Cc: David Miller <davem@davemloft.net>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jan Dumon <j.dumon@option.com>
      Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f9818af
    • O
      hso: remove unused workqueue · 5c763edf
      Olivier Sobrie 提交于
      The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
      in the code. So, remove it.
      Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c763edf
    • C
      net: ppp: don't call sk_chk_filter twice · 3916a319
      Christoph Schulz 提交于
      Commit 568f194e ("net: ppp: use
      sk_unattached_filter api") causes sk_chk_filter() to be called twice when
      setting a PPP pass or active filter. This applies to both the generic PPP
      subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP
      subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The first call is from
      within get_filter(). The second one is through the call chain
      
        ppp_ioctl() or isdn_ppp_ioctl()
        --> sk_unattached_filter_create()
            --> __sk_prepare_filter()
                --> sk_chk_filter()
      
      The first call from within get_filter() should be deleted as get_filter() is
      called just before calling sk_unattached_filter_create() later on, which
      eventually calls sk_chk_filter() anyway.
      
      For 3.15.x, this proposed change is a bugfix rather than a pure optimization as
      in that branch, sk_chk_filter() may replace filter codes by other codes which
      are not recognized when executing sk_chk_filter() a second time. So with
      3.15.x, if sk_chk_filter() is called twice, the second invocation may yield
      EINVAL (this depends on the filter codes found in the filter to be set, but
      because the replacement is done for frequently used codes, this is almost
      always the case). The net effect is that setting pass and/or active PPP filters
      does not work anymore, since sk_unattached_filter_create() always returns
      EINVAL due to the second call to sk_chk_filter(), regardless whether the filter
      was originally sane or not.
      Signed-off-by: NChristoph Schulz <develop@kristov.de>
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3916a319
    • J
      mlx4: mark napi id for gro_skb · 32b333fe
      Jason Wang 提交于
      Napi id was not marked for gro_skb, this will lead rx busy loop won't
      work correctly since they stack never try to call low latency receive
      method because of a zero socket napi id. Fix this by marking napi id
      for gro_skb.
      
      The transaction rate of 1 byte netperf tcp_rr gets about 50% increased
      (from 20531.68 to 30610.88).
      
      Cc: Amir Vadai <amirv@mellanox.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32b333fe
    • N
      bonding: fix ad_select module param check · 548d28bd
      Nikolay Aleksandrov 提交于
      Obvious copy/paste error when I converted the ad_select to the new
      option API. "lacp_rate" there should be "ad_select" so we can get the
      proper value.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      
      Fixes: 9e5f5eeb ("bonding: convert ad_select to use the new option
      API")
      Reported-by: NKarim Scheik <karim.scheik@prisma-solutions.at>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      548d28bd
    • C
      net: pppoe: use correct channel MTU when using Multilink PPP · a8a3e41c
      Christoph Schulz 提交于
      The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
      ppp_generic module) tries to determine how big a fragment might be. According
      to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
      corresponding comment and code in ppp_mp_explode():
      
      		/*
      		 * hdrlen includes the 2-byte PPP protocol field, but the
      		 * MTU counts only the payload excluding the protocol field.
      		 * (RFC1661 Section 2)
      		 */
      		mtu = pch->chan->mtu - (hdrlen - 2);
      
      However, the pppoe module *does* include the PPP protocol field in the channel
      MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
      certain circumstances (one byte if PPP protocol compression is used, two
      otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
      module has to subtract two bytes from the channel MTU. This error only
      manifests itself when using Multilink PPP, as otherwise the channel MTU is not
      used anywhere.
      
      In the following, I will describe how to reproduce this bug. We configure two
      pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
      a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
      computed by adding the two link MTUs and subtracting the MP header twice, which
      is 4 bytes long.) The necessary pppd statements on both sides are "multilink
      mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
      rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
      side, we additionally need to start two pppoe-server instances to be able to
      establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
      of the PPP network interface to the MRRU (2976) on both sides of the connection
      in order to make use of the higher bandwidth. (If we didn't do that, IP
      fragmentation would kick in, which we want to avoid.)
      
      Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
      server over the PPP link. This results in the following network packet:
      
         2948 (echo payload)
       +    8 (ICMPv4 header)
       +   20 (IPv4 header)
      ---------------------
         2976 (PPP payload)
      
      These 2976 bytes do not exceed the MTU of the PPP network interface, so the
      IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
      prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
      than the negotiated MRRU. So this packet would have to be divided in three
      fragments. But this does not happen as each link MTU is assumed to be two bytes
      larger. So this packet is diveded into two fragments only, one of size 1489 and
      one of size 1488. Now we have for that bigger fragment:
      
         1489 (PPP payload)
       +    4 (MP header)
       +    2 (PPP protocol field for the MP payload (0x3d))
       +    6 (PPPoE header)
      --------------------------
         1501 (Ethernet payload)
      
      This packet exceeds the link MTU and is discarded.
      
      If one configures the link MTU on the client side to 1501, one can see the
      discarded Ethernet frames with tcpdump running on the client. A
      
      ping -s 2948 -c 1 192.168.15.254
      
      leads to the smaller fragment that is correctly received on the server side:
      
      (tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [end], length 1492
      
      and to the bigger fragment that is not received on the server side:
      
      (tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
      52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
        length 1515: PPPoE  [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
        Flags [begin], length 1493
      
      With the patch below, we correctly obtain three fragments:
      
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [begin], length 1492
      52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [none], length 1492
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 27: PPPoE  [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
        Flags [end], length 5
      
      And the ICMPv4 echo request is successfully received at the server side:
      
      IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
        length 2976)
          192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
            length 2956
      
      The bug was introduced in commit c9aa6895
      ("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
      to 3.10 upwards but the fix can be applied (with minor modifications) to
      kernels as old as 2.6.32.
      Signed-off-by: NChristoph Schulz <develop@kristov.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8a3e41c
  6. 14 7月, 2014 1 次提交
  7. 12 7月, 2014 3 次提交
  8. 11 7月, 2014 1 次提交
  9. 10 7月, 2014 5 次提交
  10. 09 7月, 2014 6 次提交
  11. 08 7月, 2014 5 次提交
    • O
      net/mlx4_en: Don't configure the HW vxlan parser when vxlan offloading isn't set · e326f2f1
      Or Gerlitz 提交于
      The add_vxlan_port ndo driver code was wrongly testing whether HW vxlan offloads
      are supported by the device instead of checking if they are currently enabled.
      
      This causes the driver to configure the HW parser to conduct matching for vxlan
      packets but since no steering rules were set, vxlan packets are dropped on RX.
      
      Fix that by doing the right test, as done in the del_vxlan_port ndo handler.
      
      Fixes: 1b136de1 ('net/mlx4: Implement vxlan ndo calls')
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e326f2f1
    • B
      net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2 · 8dcb4b15
      Bernd Wachter 提交于
      There's a new version of the Telewell 4G modem working with, but not
      recognized by this driver.
      Signed-off-by: NBernd Wachter <bernd.wachter@jolla.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8dcb4b15
    • D
      Revert "net: stmmac: add platform init/exit for Altera's ARM socfpga" · 26a9ebca
      David S. Miller 提交于
      This reverts commit 0acf1676.
      
      Breaks the build due to missing reference to phy_resume in
      the resulting dwmac-socfpga.o object.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26a9ebca
    • Z
      powerpc/ucc_geth: deal with a compile warning · 8844a006
      Zhao Qiang 提交于
      deal with a compile warning: comparison between
      'enum qe_fltr_largest_external_tbl_lookup_key_size'
      and 'enum qe_fltr_tbl_lookup_key_size'
      
      the code:
      	"if (ug_info->largestexternallookupkeysize ==
      	     QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES)"
      is warned because different enum, so modify it.
      
      	"enum qe_fltr_largest_external_tbl_lookup_key_size
      	             largestexternallookupkeysize;
      
      	enum qe_fltr_tbl_lookup_key_size {
      		 QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES
      			 = 0x3f,         /* LookupKey parsed by the Generate LookupKey
      					    CMD is truncated to 8 bytes */
      		 QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES
      			 = 0x5f,         /* LookupKey parsed by the Generate LookupKey
      					    CMD is truncated to 16 bytes */
      	 };
      
      	 /* QE FLTR extended filtering Largest External Table Lookup Key Size */
      	 enum qe_fltr_largest_external_tbl_lookup_key_size {
      		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_NONE
      			 = 0x0,/* not used */
      		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_8_BYTES
      			 = QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES,        /* 8 bytes */
      		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_16_BYTES
      			 = QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES,       /* 16 bytes */
      	 };"
      Signed-off-by: NZhao Qiang <B45475@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8844a006
    • A
      rt2800usb: Don't perform DMA from stack · 2c4db12e
      Andrea Merello 提交于
      Function rt2800usb_autorun_detect() passes the address of a variable
      allocated onto the stack to be used for DMA by the USB layer. This has
      been caught by my debugging-enabled kernel.
      
      This patch change things in order to allocate that variable via
      kmalloc, and it adjusts things to handle the kmalloc failure case,
      propagating the error.
      
      [ 7363.238852] ------------[ cut here ]------------
      [ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0()
      [ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4]
      [ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib]
      [ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G           O  3.16.0-rc3-wl+ #31
      [ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
      [ 7363.297511]  0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758
      [ 7363.305062]  ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0
      [ 7363.312622]  ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8
      [ 7363.320161] Call Trace:
      [ 7363.322661]  [<ffffffff8175dcad>] dump_stack+0x4d/0x6f
      [ 7363.327847]  [<ffffffff8106d372>] warn_slowpath_common+0x82/0xb0
      [ 7363.333893]  [<ffffffff8106d3e7>] warn_slowpath_fmt+0x47/0x50
      [ 7363.339686]  [<ffffffff813a93b4>] check_for_stack+0xa4/0xf0
      [ 7363.345298]  [<ffffffff813a995c>] debug_dma_map_page+0x10c/0x150
      [ 7363.351367]  [<ffffffff81521bd9>] usb_hcd_map_urb_for_dma+0x229/0x720
      [ 7363.357890]  [<ffffffff8152256d>] usb_hcd_submit_urb+0x2fd/0x930
      [ 7363.363929]  [<ffffffff810eac31>] ? irq_work_queue+0x71/0xd0
      [ 7363.369617]  [<ffffffff810ab5a7>] ? wake_up_klogd+0x37/0x50
      [ 7363.375219]  [<ffffffff810ab7a5>] ? console_unlock+0x1e5/0x420
      [ 7363.381081]  [<ffffffff810abc25>] ? vprintk_emit+0x245/0x530
      [ 7363.386773]  [<ffffffff81523d3c>] usb_submit_urb+0x30c/0x580
      [ 7363.392462]  [<ffffffff81524295>] usb_start_wait_urb+0x65/0xf0
      [ 7363.398325]  [<ffffffff815243ed>] usb_control_msg+0xcd/0x110
      [ 7363.404014]  [<ffffffffa005514d>] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb]
      [ 7363.411544]  [<ffffffffa0074292>] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb]
      [ 7363.418986]  [<ffffffffa0074aa1>] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb]
      [ 7363.426168]  [<ffffffffa0063ffd>] rt2800_probe_hw+0x11d/0xf90 [rt2800lib]
      [ 7363.432989]  [<ffffffffa0074b7d>] rt2800usb_probe_hw+0xd/0x50 [rt2800usb]
      [ 7363.439808]  [<ffffffffa00453d8>] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib]
      [ 7363.446992]  [<ffffffffa00bfa48>] ? ieee80211_led_names+0xb8/0x100 [mac80211]
      [ 7363.454156]  [<ffffffffa0056116>] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb]
      [ 7363.460971]  [<ffffffffa0074250>] rt2800usb_probe+0x10/0x20 [rt2800usb]
      [ 7363.467616]  [<ffffffff8152799e>] usb_probe_interface+0xce/0x1c0
      [ 7363.473651]  [<ffffffff81480c20>] really_probe+0x70/0x240
      [ 7363.479079]  [<ffffffff81480f01>] __driver_attach+0xa1/0xb0
      [ 7363.484682]  [<ffffffff81480e60>] ? __device_attach+0x70/0x70
      [ 7363.490461]  [<ffffffff8147eef3>] bus_for_each_dev+0x63/0xa0
      [ 7363.496146]  [<ffffffff814807c9>] driver_attach+0x19/0x20
      [ 7363.501570]  [<ffffffff81480468>] bus_add_driver+0x178/0x220
      [ 7363.507270]  [<ffffffff8148151b>] driver_register+0x5b/0xe0
      [ 7363.512874]  [<ffffffff815271b0>] usb_register_driver+0xa0/0x170
      [ 7363.518905]  [<ffffffffa007a000>] ? 0xffffffffa0079fff
      [ 7363.524074]  [<ffffffffa007a01e>] rt2800usb_driver_init+0x1e/0x20 [rt2800usb]
      [ 7363.531247]  [<ffffffff810002d4>] do_one_initcall+0x84/0x1b0
      [ 7363.536932]  [<ffffffff8113aa60>] ? kfree+0xd0/0x110
      [ 7363.541931]  [<ffffffff8112730a>] ? __vunmap+0xaa/0xf0
      [ 7363.547538]  [<ffffffff810ca07e>] load_module+0x1aee/0x2040
      [ 7363.553141]  [<ffffffff810c6f10>] ? store_uevent+0x50/0x50
      [ 7363.558676]  [<ffffffff810ca66e>] SyS_init_module+0x9e/0xc0
      [ 7363.564285]  [<ffffffff81764012>] system_call_fastpath+0x16/0x1b
      [ 7363.570338] ---[ end trace 01ef5f822bea9882 ]---
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2c4db12e
  12. 04 7月, 2014 1 次提交