1. 15 6月, 2013 1 次提交
  2. 13 6月, 2013 1 次提交
  3. 12 6月, 2013 2 次提交
  4. 04 6月, 2013 3 次提交
  5. 31 5月, 2013 1 次提交
  6. 23 5月, 2013 1 次提交
  7. 18 5月, 2013 1 次提交
    • S
      ath9k: Fix crash on module unload · af690092
      Sujith Manoharan 提交于
      Make sure that any open relayfs files are closed before
      unregistering with mac80211, otherwise this crash is seen:
      
      [ 1331.097846] BUG: unable to handle kernel paging request at 6b6b6b8b
      [ 1331.098170] IP: [<c063d0d6>] debugfs_remove+0x26/0x80
      [ 1331.098170] *pdpt = 000000002f9aa001 *pde = 0000000000000000
      [ 1331.098170] Oops: 0000 [#1] PREEMPT SMP
      [ 1331.098170] Modules linked in: iptable_raw xt_CT nf_conntrack_ipv4 nf_defrag]
      [ 1331.098170] Pid: 4794, comm: rmmod Tainted: G        WC   3.9.1+ #5 To Be Fi.
      [ 1331.098170] EIP: 0060:[<c063d0d6>] EFLAGS: 00010202 CPU: 0
      [ 1331.098170] EIP is at debugfs_remove+0x26/0x80
      [ 1331.098170] EAX: f2f3acd0 EBX: f2f3acd0 ECX: 00000006 EDX: f8622348
      [ 1331.098170] ESI: 6b6b6b6b EDI: 00000001 EBP: ee251e14 ESP: ee251e0c
      [ 1331.098170]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [ 1331.098170] CR0: 8005003b CR2: 6b6b6b8b CR3: 2e7b7000 CR4: 000007e0
      [ 1331.098170] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [ 1331.098170] DR6: ffff0ff0 DR7: 00000400
      [ 1331.098170] Process rmmod (pid: 4794, ti=ee250000 task=efaa2560 task.ti=ee25)
      [ 1331.098170] Stack:
      [ 1331.098170]  f241e170 0000000a ee251e1c f861394d ee251e28 c04e3088 f241e170 4
      [ 1331.098170]  c04e30fe f45482b0 ee251e54 c04e3187 f25e86b0 ee251e54 f8618748 0
      [ 1331.098170]  0000000a 00000001 ee251e68 f860065b f2509e20 f25085a0 f5b6e8a4 8
      [ 1331.098170] Call Trace:
      [ 1331.098170]  [<f861394d>] remove_buf_file_handler+0xd/0x20 [ath9k]
      [ 1331.098170]  [<c04e3088>] relay_remove_buf+0x18/0x30
      [ 1331.098170]  [<c04e30fe>] relay_close_buf+0x2e/0x40
      [ 1331.098170]  [<c04e3187>] relay_close+0x77/0xf0
      [ 1331.098170]  [<f8618748>] ? dpd_exit+0x38/0x40 [ath9k]
      [ 1331.098170]  [<f860065b>] ath9k_deinit_softc+0x8b/0xa0 [ath9k]
      [ 1331.098170]  [<f86006b8>] ath9k_deinit_device+0x48/0x60 [ath9k]
      [ 1331.098170]  [<f86107f1>] ath_pci_remove+0x31/0x50 [ath9k]
      [ 1331.098170]  [<c06dbff8>] pci_device_remove+0x38/0xc0
      [ 1331.098170]  [<c079daa4>] __device_release_driver+0x64/0xc0
      [ 1331.098170]  [<c079db97>] driver_detach+0x97/0xa0
      [ 1331.098170]  [<c079cacc>] bus_remove_driver+0x6c/0xe0
      [ 1331.098170]  [<c079c197>] ? bus_put+0x17/0x20
      [ 1331.098170]  [<c079cae3>] ? bus_remove_driver+0x83/0xe0
      [ 1331.098170]  [<c079e709>] driver_unregister+0x49/0x80
      [ 1331.098170]  [<c06dc138>] pci_unregister_driver+0x18/0x80
      [ 1331.098170]  [<f8610602>] ath_pci_exit+0x12/0x20 [ath9k]
      [ 1331.098170]  [<f8619ce0>] ath9k_exit+0x17/0x337 [ath9k]
      [ 1331.098170]  [<c09e537d>] ? mutex_unlock+0xd/0x10
      [ 1331.098170]  [<c04bd36c>] sys_delete_module+0x17c/0x250
      [ 1331.098170]  [<c0540dc4>] ? do_munmap+0x244/0x2d0
      [ 1331.098170]  [<c0540e96>] ? vm_munmap+0x46/0x60
      [ 1331.098170]  [<c09e8dc4>] ? restore_all+0xf/0xf
      [ 1331.098170]  [<c09ebf50>] ? __do_page_fault+0x4c0/0x4c0
      [ 1331.098170]  [<c04b18e4>] ? trace_hardirqs_on_caller+0xf4/0x180
      [ 1331.098170]  [<c09ef28d>] sysenter_do_call+0x12/0x38
      [ 1331.098170] Code: 90 8d 74 26 00 55 89 e5 83 ec 08 89 1c 24 89 74 24 04 3e 82
      [ 1331.098170] EIP: [<c063d0d6>] debugfs_remove+0x26/0x80 SS:ESP 0068:ee251e0c
      [ 1331.098170] CR2: 000000006b6b6b8b
      [ 1331.727971] ---[ end trace b5bb9f2066cef7f9 ]---
      
      Cc: <stable@vger.kernel.org>
      Acked-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Tested-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af690092
  8. 24 4月, 2013 1 次提交
  9. 23 4月, 2013 1 次提交
  10. 09 4月, 2013 2 次提交
  11. 02 2月, 2013 1 次提交
  12. 31 1月, 2013 1 次提交
  13. 14 1月, 2013 1 次提交
  14. 10 1月, 2013 1 次提交
    • S
      ath9k: add spectral scan feature · e93d083f
      Simon Wunderlich 提交于
      Adds the spectral scan feature for ath9k. AR92xx and AR93xx chips
      are supported for now. The spectral scan is triggered by configuring
      a mode through a debugfs control file. Samples can be gathered via
      another relay debugfs file.
      
      Essentially, to try it out:
      
      echo chanscan > /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan_ctl
      iw dev wlan0 scan
      cat /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan0 > samples
      echo disable > /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan_ctl
      
      This feature is still experimental.
      
      The special "chanscan" mode is used to perform spectral scan while
      mac80211 is scanning for channels. To allow this,
      sw_scan_start/complete() ops have been added.
      
      The patch contains code snippets and information from Zefir Kurtisi and
      information provided by Adrian Chadd and Felix Fietkau.
      Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e93d083f
  15. 08 1月, 2013 2 次提交
  16. 12 12月, 2012 1 次提交
  17. 11 12月, 2012 1 次提交
  18. 22 11月, 2012 2 次提交
  19. 30 10月, 2012 1 次提交
  20. 25 9月, 2012 2 次提交
  21. 12 9月, 2012 1 次提交
  22. 18 7月, 2012 2 次提交
  23. 13 7月, 2012 1 次提交
  24. 07 6月, 2012 2 次提交
  25. 24 4月, 2012 1 次提交
  26. 12 4月, 2012 1 次提交
  27. 11 4月, 2012 2 次提交
  28. 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
  29. 27 3月, 2012 1 次提交
  30. 16 3月, 2012 1 次提交