Hi all, the ath9k driver is not working very nicely with the AR5008 Wireless chip. It is associated with a Fritz!Box 7270 but gets disassociated a lot: [ 4506.432379] No probe response from AP ${AP_MAC} after 500ms, disconnecting. [ 4507.347979] wlan0: direct probe to AP ${AP_MAC} (try 1) [ 4507.352632] wlan0: direct probe responded [ 4507.352635] wlan0: authenticate with AP ${AP_MAC} (try 1) [ 4507.355748] wlan0: authenticated [ 4507.355768] wlan0: associate with AP ${AP_MAC} (try 1) [ 4507.359639] wlan0: RX ReassocResp from ${AP_MAC} (capab=0x431 status=0 aid=1) [ 4507.359643] wlan0: associated [ 6993.360735] No probe response from AP ${AP_MAC} after 500ms, disconnecting. [ 6994.269301] wlan0: direct probe to AP ${AP_MAC} (try 1) [ 6994.272477] wlan0: direct probe responded [ 6994.272482] wlan0: authenticate with AP ${AP_MAC} (try 1) [ 6994.275806] wlan0: authenticated [ 6994.275826] wlan0: associate with AP ${AP_MAC} (try 1) [ 6994.280846] wlan0: RX ReassocResp from ${AP_MAC} (capab=0x431 status=0 aid=1) [ 6994.280850] wlan0: associated [10273.947093] No probe response from AP ${AP_MAC} after 500ms, disconnecting. [10274.856676] wlan0: direct probe to AP ${AP_MAC} (try 1) [10274.860329] wlan0: direct probe responded [10274.860333] wlan0: authenticate with AP ${AP_MAC} (try 1) [10274.864723] wlan0: authenticated [10274.864741] wlan0: associate with AP ${AP_MAC} (try 1) [10274.868622] wlan0: RX ReassocResp from ${AP_MAC} (capab=0x431 status=0 aid=1) [10274.868636] wlan0: associated This goes on and on and on... Some info: Linux freax 2.6.32-rc8 #2 SMP Sat Nov 21 16:34:36 CET 2009 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux 01:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01) Subsystem: D-Link System Inc Device 3a70 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 28 Region 0: Memory at dfff0000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable- Address: 00000000 Data: 0000 Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Vector table: BAR=0 offset=00000000 PBA: BAR=0 offset=00000000 Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSVoil- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [140] Virtual Channel <?> Kernel driver in use: ath9k Kernel modules: ath9k Cheers Bjoern
I confirm this issue, but with a worse failure mode: After disconnect my system doesn't reassociate until I bring interface down and up. Un/reloading the driver also helps, but then sometimes I run into another bug where uping the interface gives error 132 (or -132?) and reboot is required, so I avoid that. I have seen this issue with all access points that I have used, so far three: Jensen Scandinavia (chinese rebrand) Air:Link 7954v2 LongRange (has other issues; it crashes under high UDP load regardless of clientside radio, that's unrelated) Linksys WAP54G Self-built soekris with AR5212 card running oldish Linux+madwifi in master mode In particular the latter two APs are running solid in office and home production environments with daily use for several years. The first AP uses WEP, the last two no encryption at all. My kernel is 2.6.32-rc6 git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git commit 5618ca6abc2d6f475b258badc017a5254cf43d1b from Dec 2. The last change in drivers/net/wireless/ath is commit e55ea2b152569f09ef6bb28d5a341a4e5a21f5ce from Oct 28. --8<-- dmesg excerpt udev: starting version 141 ath9k 0000:02:02.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 ath: EEPROM regdomain: 0x64 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x64 phy0: Selected rate control algorithm 'ath9k_rate_control' Registered led device: ath9k-phy0::radio Registered led device: ath9k-phy0::assoc Registered led device: ath9k-phy0::tx Registered led device: ath9k-phy0::rx phy0: Atheros AR5416 MAC/BB Rev:2 AR5133 RF Rev:81: mem=0xf8320000, irq=21 udev: renamed network interface wlan0 to eth1 .. after manual config: eth1: direct probe to AP xx (try 1) eth1: direct probe responded eth1: authenticate with AP xx (try 1) eth1: authenticated eth1: associate with AP xx (try 1) eth1: RX AssocResp from xx (capab=0x401 status=0 aid=14) eth1: associated .. some time later: No probe response from AP xx after 500ms, disconnecting. -->8-- --8<-- lspci -vvs 2:2 # lspci -vvs 2:2 02:02.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01) Subsystem: Apple Computer Inc. Device 0087 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 168, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at d0200000 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] #80 [0000] Kernel driver in use: ath9k Kernel modules: ath9k -->8-- (This is not an Apple system though, I retrofitted this card into my ThinkPad.)
Another thing; if the link is left idle the disconnect happens (much) quicker. I keep a ping running, but it is not a reliable workaround. I never run wpa_supplicant. This is on a Gentoo system. Power Management was on, and I just now switched it off, after reading what looks to be the same bug: http://bugzilla.kernel.org/show_bug.cgi?id=14267
Running fine after iwconfig power off for 50 minutes now.
Please see http://bugzilla.kernel.org/show_bug.cgi?id=14267 for further comments. This bug is definately a duplicate, please close it as such?
*** This bug has been marked as a duplicate of bug 14267 ***
Thanks for the additional info, I'll keep track of bug #14267