1. 23 4月, 2010 7 次提交
  2. 22 4月, 2010 6 次提交
  3. 21 4月, 2010 3 次提交
  4. 20 4月, 2010 12 次提交
  5. 17 4月, 2010 3 次提交
  6. 15 4月, 2010 9 次提交
    • J
      ixgbe: fix bug with vlan strip in promsic mode · 5f6c0181
      Jesse Brandeburg 提交于
      The ixgbe driver was setting up 82598 hardware correctly, so that
      when promiscuous mode was enabled hardware stripping was turned
      off.  But on 82599 the logic to disable/enable hardware stripping
      is different, and the code was not updated correctly when the
      hardware vlan stripping was enabled as default.
      
      This change comprises the creation of two new helper functions
      and calling them from the right locations to disable and enable
      hardware stripping of vlan tags at appropriate times.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f6c0181
    • E
      drivers: net: use skb_headlen() · e743d313
      Eric Dumazet 提交于
      replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb)
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e743d313
    • X
      wireless: rt2x00: rt2800usb: identify Sitecom devices · a5e944f1
      Xose Vazquez Perez 提交于
      A very useful information was provided by Sitecom R&D guys:
      
      Please find the information regarding our latest Ralink adapters below;
      
      WL-302    -    VID: 0x0DF6,    PID: 0x002D    -    Ralink RT2771
      WL-315    -    VID: 0x0DF6,    PID: 0x0039    -    Ralink RT2770
      WL-319    -    VID: 0x182D,    PID: 0x0037    -    Ralink RT2860
      WL-321    -    VID: 0x0DF6,    PID: 0x003B    -    Ralink RT2770
      WL-324    -    VID: 0x0DF6,    PID: 0x003D    -    Ralink RT2870
      WL-329    -    VID: 0x0DF6,    PID: 0x0041    -    Ralink RT3572
      WL-343    -    VID: 0x0DF6,    PID: 0x003E    -    Ralink RT3070
      WL-344    -    VID: 0x0DF6,    PID: 0x0040    -    Ralink RT3071
      WL-345    -    VID: 0x0DF6,    PID: 0x0042    -    Ralink RT3072
      WL-608    -    VID: 0x0DF6,    PID: 0x003F    -    Ralink RT2070
      
      Note:
      PID: 0x003C, 0x004A, and 0x004D:   --these products do not exist; devices were never produced/shipped--
      
      The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
      Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a5e944f1
    • C
      ar9170usb: add a couple more USB IDs · 94d0bbe8
      Christian Lamparter 提交于
      This patch adds the following 5 entries to the usbid device table:
      
       * Netgear WNA1000
       * Proxim ORiNOCO Dual Band 802.11n USB Adapter
       * 3Com Dual Band 802.11n USB Adapter
       * H3C Dual Band 802.11n USB Adapter
       * WNC Generic 11n USB dongle
      
      CC: <stable@kernel.org>
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      94d0bbe8
    • G
      wl1251: don't require NVS data when EEPROM is used · afa5ec27
      Grazvydas Ignotas 提交于
      If EEPROM is used, NVS data is now loaded but ignored.
      Stop loading it to avoid need of dummy NVS file for modules with EEPROM.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: NKalle Valo <kvalo@adurom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afa5ec27
    • M
      ath9k-htc: fix lockdep warning and kernel warning after unplugging ar9271 usb device · f8e1d080
      Ming Lei 提交于
      This patch fixes two warnings below after unplugging ar9271 usb device:
      	-one is a kernel warning[1]
      	-another is a lockdep warning[2]
      
      The root reason is that __skb_queue_purge can't be executed in hardirq
      context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge),
      which frees skb with dev_kfree_skb_any which can be run in hardirq
      context safely, then prevent the lockdep warning and kernel warning after
      unplugging ar9271 usb device.
      
      [1] kernel warning
      [  602.894005] ------------[ cut here ]------------
      [  602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87()
      [  602.894005] Hardware name: 6475EK2
      [  602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath]
      [  602.894005] Pid: 2506, comm: ping Tainted: G        W  2.6.34-rc3-wl #20
      [  602.894005] Call Trace:
      [  602.894005]  <IRQ>  [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94
      [  602.894005]  [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc]
      [  602.894005]  [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16
      [  602.894005]  [<ffffffff813269c1>] skb_release_head_state+0x71/0x87
      [  602.894005]  [<ffffffff8132829a>] __kfree_skb+0x16/0x81
      [  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
      [  602.894005]  [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc]
      [  602.894005]  [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc]
      [  602.894005]  [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc]
      [  602.894005]  [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
      [  602.894005]  [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
      [  602.894005]  [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
      [  602.894005]  [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
      [  602.894005]  [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd]
      [  602.894005]  [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
      [  602.894005]  [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df
      [  602.894005]  [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2
      [  602.894005]  [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
      [  602.894005]  [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
      [  602.894005]  [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce
      [  602.894005]  [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
      [  602.894005]  [<ffffffff8100c4fb>] handle_irq+0x88/0x91
      [  602.894005]  [<ffffffff8100baed>] do_IRQ+0x63/0xc9
      [  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff813ba993>] ret_from_intr+0x0/0x16
      [  602.894005]  <EOI>  [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1
      [  602.894005]  [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e
      [  602.894005]  [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e
      [  602.894005]  [<ffffffff811095fe>] __delete_object+0x5a/0xb1
      [  602.894005]  [<ffffffff81109814>] delete_object_full+0x25/0x31
      [  602.894005]  [<ffffffff813a60c0>] kmemleak_free+0x26/0x45
      [  602.894005]  [<ffffffff810ff517>] kfree+0xaa/0x149
      [  602.894005]  [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89
      [  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff813285ce>] skb_release_data+0xc9/0xce
      [  602.894005]  [<ffffffff813282a2>] __kfree_skb+0x1e/0x81
      [  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
      [  602.894005]  [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709
      [  602.894005]  [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d
      [  602.894005]  [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf
      [  602.894005]  [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9
      [  602.894005]  [<ffffffff810e13b4>] ? might_fault+0x68/0xb8
      [  602.894005]  [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8
      [  602.894005]  [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31
      [  602.894005]  [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91
      [  602.894005]  [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
      [  602.894005]  [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63
      [  602.894005]  [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff810357fe>] ? need_resched+0x23/0x2d
      [  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
      [  602.894005]  [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  602.894005]  [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
      [  602.894005] ---[ end trace 91ba2d8dc7826839 ]---
      
      [2] lockdep warning
      [  169.363215] ======================================================
      [  169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
      [  169.366334] 2.6.34-rc3-wl #20
      [  169.366872] ------------------------------------------------------
      [  169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      [  169.366872]  (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89
      [  169.366872]
      [  169.366872] and this task is already holding:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc]
      [  169.366872] which would create a new lock dependency:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..}
      [  169.366872]
      [  169.366872] but this new dependency connects a HARDIRQ-irq-safe lock:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}
      [  169.366872] ... which became HARDIRQ-irq-safe at:
      [  169.366872]   [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b
      [  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
      [  169.366872]   [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73
      [  169.366872]   [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc]
      [  169.366872]   [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
      [  169.366872]   [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
      [  169.366872]   [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
      [  169.366872]   [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
      [  169.366872]   [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
      [  169.366872]   [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
      [  169.366872]   [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
      [  169.366872]   [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
      [  169.366872]   [<ffffffff8100c4fb>] handle_irq+0x88/0x91
      [  169.366872]   [<ffffffff8100baed>] do_IRQ+0x63/0xc9
      [  169.366872]   [<ffffffff813ba993>] ret_from_intr+0x0/0x16
      [  169.366872]   [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115
      [  169.366872]   [<ffffffff81008c4f>] cpu_idle+0x68/0xc4
      [  169.366872]   [<ffffffff813a41e0>] rest_init+0x104/0x10b
      [  169.366872]   [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc
      [  169.366872]   [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7
      [  169.366872]   [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107
      [  169.366872]
      [  169.366872] to a HARDIRQ-irq-unsafe lock:
      [  169.366872]  (clock-AF_INET){++.?..}
      [  169.366872] ... which became HARDIRQ-irq-unsafe at:
      [  169.366872] ...  [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b
      [  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
      [  169.366872]   [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a
      [  169.366872]   [<ffffffff8135cf14>] tcp_close+0x165/0x34d
      [  169.366872]   [<ffffffff8137aced>] inet_release+0x55/0x5c
      [  169.366872]   [<ffffffff81321350>] sock_release+0x1f/0x6e
      [  169.366872]   [<ffffffff813213c6>] sock_close+0x27/0x2b
      [  169.366872]   [<ffffffff8110dd45>] __fput+0x125/0x1ca
      [  169.366872]   [<ffffffff8110de04>] fput+0x1a/0x1c
      [  169.366872]   [<ffffffff8110adc9>] filp_close+0x68/0x72
      [  169.366872]   [<ffffffff8110ae80>] sys_close+0xad/0xe7
      [  169.366872]   [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
      
      (Trimmed at the "other info that might help us debug this" line in
      the interest of brevity... -- JWL)
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Acked-by: NSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f8e1d080
    • M
      ath9k-htc:respect usb buffer cacheline alignment in reg out path · 0fa35a58
      Ming Lei 提交于
      In ath9k-htc register out path, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0fa35a58
    • M
      ath9k-htc:respect usb buffer cacheline alignment in reg in path · e6c6d33c
      Ming Lei 提交于
      In ath9k-htc register in path, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e6c6d33c
    • M
      ath9k-htc:respect usb buffer cacheline alignment in ath9k_hif_usb_alloc_rx_urbs · f28a7b30
      Ming Lei 提交于
      In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f28a7b30
新手
引导
客服 返回
顶部