Red Hat Bugzilla – Bug 506659
ath5k: phy0 periodicaly uses considerable cpu and ssh connections lock up for several seconds
Last modified: 2009-11-28 22:23:57 EST
Description of problem:
SSH connections stall for several seconds while the phy0 process's CPU usage becomes high. This happens randomly, usually every few minutes.
Version-Release number of selected component (if applicable):
Not sure, using an Atheros AR5414 chip, a WPA/TKIP connection over the SSH connection.
Steps to Reproduce:
1. Connect to an SSH server
2. Have top or a CPU monitor program running
3. SSH connection stalls as the phy0 process consumes way-more-than-usual CPU cycles.
SSH stalls while phy0's process goes up.
Continuous SSH connection availability.
lspci -vvv (results for the atheros chip):
03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)
Subsystem: IBM ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (AR5BXB6)
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: 128 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at 75200000 (64-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: ath5k
Kernel modules: ath5k
No kernel errors are thrown.
I realize this is probably related to ath5k's known rate-setting issues and the new minstrel rate algorithm. Please let me know if this is a duplicate or how I can contribute some more information.
Actually, it sounds more like periodic scanning to me. Are you using NetworkManager?
Yes, I'm using NetworkManager. I guess I should fall back to wpa_supplicant?
That might be worthwhile, although honestly I'm not sure if NM is triggering scans or if wpa_supplicant does it. I wonder if you can recreate the issue with and open or WEP network?
Also, it is probably worthwhile to run iwevent and see if there are any events coincident with the delays.
I've confirmed by watching iwevent and iwconfig wlan0 that you were indeed correct that the periodic scanning is the culprit. On a WPA or open network iwevent will output:
11:41:56.761202 wlan0 Scan request completed
periodically as iwconfig reports frequency change. This will coincide with the connection stalls and phy0 CPU usage.
Furthermore, using wpa_supplicant and disabling NetworkManager, this behavior is not reproducible (perhaps only by manually triggering a scan?)
OK, at least we understand the issue. FWIW, there has been some work done in the upstream kernel that will mitigate this issue. However, it will take some time for this to appear in Fedora -- could be F-12...
Any progress on this? I am at FC12 and this problem still persists. I have:
When I ping my base station, I see occasionally:
64 bytes from 192.168.1.1: icmp_seq=57 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=1.39 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=1.39 ms
64 bytes from 192.168.1.1: icmp_seq=60 ttl=64 time=1.29 ms
64 bytes from 192.168.1.1: icmp_seq=61 ttl=64 time=4236 ms
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=3243 ms
64 bytes from 192.168.1.1: icmp_seq=63 ttl=64 time=2244 ms
64 bytes from 192.168.1.1: icmp_seq=64 ttl=64 time=1244 ms
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=237 ms
64 bytes from 192.168.1.1: icmp_seq=66 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_seq=67 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=68 ttl=64 time=1.28 ms
64 bytes from 192.168.1.1: icmp_seq=69 ttl=64 time=1.83 ms
The system is doing scan at the points when this happens. I am using NetworkManager. This is a really annoying problem as it makes the system very difficult to use (especially ssh connections stop from time to time and make editing files pain).
(the system where I see this is an up to date FC12 as of Nov-28 2009)
03:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)