1. 10 7月, 2012 1 次提交
  2. 28 6月, 2012 1 次提交
    • T
      ath9k: fix panic caused by returning a descriptor we have queued for reuse · 6bb51c70
      Tom Hughes 提交于
      Commit 3a2923e8 introduced a bug when a corrupt descriptor
      is encountered - although the following descriptor is discarded
      and returned to the queue for reuse the associated frame is
      also returned for processing. This leads to a panic:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
      IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
      Call Trace:
      <IRQ>
      [<ffffffff812d7fa0>] ? map_single+0x60/0x60
      [<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
      [<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
      [<ffffffff8105e133>] tasklet_action+0x63/0xd0
      [<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
      [<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
      [<ffffffff815f9d5c>] call_softirq+0x1c/0x30
      [<ffffffff810151f5>] do_softirq+0x75/0xb0
      [<ffffffff8105df95>] irq_exit+0xb5/0xc0
      [<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
      [<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
      <EOI>
      [<ffffffff8131840a>] ? intel_idle+0xea/0x150
      [<ffffffff813183eb>] ? intel_idle+0xcb/0x150
      [<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
      [<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
      [<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
      [<ffffffff815cda8e>] rest_init+0x72/0x74
      [<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
      [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
      [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
      [<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
      
      Making sure bf is cleared to NULL in this case restores the
      old behaviour.
      Signed-off-by: NTom Hughes <tom@compton.nu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6bb51c70
  3. 26 6月, 2012 1 次提交
  4. 07 6月, 2012 5 次提交
  5. 11 5月, 2012 1 次提交
    • J
      drivers/net: Convert compare_ether_addr to ether_addr_equal · 2e42e474
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e42e474
  6. 24 4月, 2012 2 次提交
  7. 12 4月, 2012 1 次提交
  8. 10 4月, 2012 1 次提交
    • R
      ath9k: recover ar9380 chips from rare stuck state · 01e18918
      Rajkumar Manoharan 提交于
      In the experiment with Azimuth ADEPT-n testbed where the APs transmit
      power was reduced to 25% and the signal strength was futher attenuated
      by 20dB and induced a path loss of ~7dB, the station was reporting
      beacon losses and the following issue were observed.
      
      * rx clear is stuck at low for more than 300ms
      * dcu chain and complete state is stuck at one of the hang signature
      
      This patch triggers the hang detection logic that recovers the chip
      from any of the above conditions. As the issue was originally reported
      in ChromeOs with AR9382 chips, this detection logic is enabled only for
      AR9380/2 chips.
      
      Cc: Paul Stewart <pstew@google.com>
      Reported-by: NGary Morain <gmorain@google.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      01e18918
  9. 27 3月, 2012 1 次提交
    • E
      ath9k: fix a memory leak in ath_rx_tasklet() · b5447ff9
      Eric Dumazet 提交于
      commit 0d95521e (ath9k: use split rx buffers to get rid of order-1 skb
      allocations) added in memory leak in error path.
      
      sc->rx.frag should be cleared after the pskb_expand_head() call, or else
      we jump to requeue_drop_frag and leak an skb.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Felix Fietkau <nbd@openwrt.org>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Trond Wuellner <trond@chromium.org>
      Cc: Grant Grundler <grundler@chromium.org>
      Cc: Paul Stewart <pstew@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b5447ff9
  10. 13 3月, 2012 1 次提交
  11. 08 3月, 2012 2 次提交
  12. 06 3月, 2012 1 次提交
  13. 07 2月, 2012 1 次提交
  14. 20 12月, 2011 1 次提交
  15. 16 12月, 2011 1 次提交
  16. 01 12月, 2011 2 次提交
  17. 22 11月, 2011 1 次提交
  18. 12 10月, 2011 4 次提交
  19. 01 10月, 2011 1 次提交
  20. 27 9月, 2011 1 次提交
    • M
      ath9k: Fix a dma warning/memory leak · ba542385
      Mohammed Shafi Shajakhan 提交于
      proper dma_unmapping and freeing of skb's has to be done in the rx
      cleanup for EDMA chipsets when the device is unloaded and this also
      seems to address the following warning which shows up occasionally when
      the device is unloaded
      
      	Call Trace:
      	[<c0148cd2>] warn_slowpath_common+0x72/0xa0
      	[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
      	[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
      	[<c0148da3>] warn_slowpath_fmt+0x33/0x40
      	[<c03b669c>] dma_debug_device_change+0x19c/0x200
      	[<c0657f12>] notifier_call_chain+0x82/0xb0
      	[<c0171370>] __blocking_notifier_call_chain+0x60/0x90
      	[<c01713bf>] blocking_notifier_call_chain+0x1f/0x30
      	[<c044f594>] __device_release_driver+0xa4/0xc0
      	[<c044f647>] driver_detach+0x97/0xa0
      	[<c044e65c>] bus_remove_driver+0x6c/0xe0
      	[<c029af0b>] ? sysfs_addrm_finish+0x4b/0x60
      	[<c0450109>] driver_unregister+0x49/0x80
      	[<c0299f54>] ? sysfs_remove_file+0x14/0x20
      	[<c03c3ab2>] pci_unregister_driver+0x32/0x80
      	[<f92c2162>] ath_pci_exit+0x12/0x20 [ath9k]
      	[<f92c8467>] ath9k_exit+0x17/0x36 [ath9k]
      	[<c06523cd>] ? mutex_unlock+0xd/0x10
      	[<c018e27f>] sys_delete_module+0x13f/0x200
      	[<c02139bb>] ? sys_munmap+0x4b/0x60
      	[<c06547c5>] ? restore_all+0xf/0xf
      	[<c0657a20>] ? spurious_fault+0xe0/0xe0
      	[<c01832f4>] ? trace_hardirqs_on_caller+0xf4/0x180
      	[<c065b863>] sysenter_do_call+0x12/0x38
      	 ---[ end trace 16e1c1521c06bcf9 ]---
      	Mapped at:
      	[<c03b7938>] debug_dma_map_page+0x48/0x120
      	[<f92ba3e8>] ath_rx_init+0x3f8/0x4b0 [ath9k]
      	[<f92b5ae4>] ath9k_init_device+0x4c4/0x7b0 [ath9k]
      	[<f92c2813>] ath_pci_probe+0x263/0x330 [ath9k]
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba542385
  21. 17 9月, 2011 1 次提交
  22. 15 9月, 2011 1 次提交
  23. 30 8月, 2011 2 次提交
  24. 25 8月, 2011 3 次提交
  25. 11 8月, 2011 1 次提交
  26. 10 8月, 2011 1 次提交
  27. 09 8月, 2011 1 次提交