Bug 12635

Summary: ath5k scanning makes system choppy
Product: Networking Reporter: Benjamin Schindler (bschindler)
Component: WirelessAssignee: networking_wireless (networking_wireless)
Severity: normal CC: kernel-bugzilla, linville, mcgrof, me, nick, vickieharmstrong
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.28 (and earlier - have not tried 2.6.29-rcX) Tree: Mainline
Regression: No

Description Benjamin Schindler 2009-02-05 04:07:34 UTC
Latest working kernel version: Madwifi was unaffected, but ath5k was from the very beginning
Earliest failing kernel version:
Distribution: gentoo
Hardware Environment: Thinkpad T42
Software Environment: linux 2.6.28
Problem Description: When havin wpa_supplicant running, it continously (about every minute maybe? I'm not sure) emits a 

As soon this happens, the computer becomes very choppy. Meaning Sound may skip, flash games come to a crawl etc. After the scan is done, resposivity is back to normal. When the scan is in progress (takes about 5 seconds here), the ath5k process takes ~30% cpu time which I find to be very high just for a scan
Steps to reproduce: Play some flash game (www.bumperball.com is an option :) ), start a scan and watch the speed of flash. Music may skip too, but that doesn't occur all the time

If you need more info or If I can assist in debugging - just let me know
Comment 1 Bob Copeland 2009-02-09 11:35:25 UTC
The problem is that scanning changes channels, which in turn calls ath5k_hw_reset, thus reloading all the registers for the card.  This is how it has pretty much always worked.  This is also, I suspect, a cause for a number of bad behaviors of the card, such as noise floor timeouts and perhaps some lockups.  We need to make channel changes a much simpler affair.
Comment 2 Benjamin Schindler 2009-02-09 11:57:15 UTC

I just spotted that part in the code (base.c, ath5k_chan_set)

Is there any way I can help on this? 
Comment 3 Bob Copeland 2009-04-02 11:29:01 UTC
This patch *may* help, by reducing the total number of channels:


Otherwise Nick is working on "reset-light" I believe.
Comment 4 Benjamin Schindler 2009-04-02 12:19:22 UTC
Well, if somebody is already working on reset-light, then I'd rather wait for that. If there are patches for that which need testing, I'd surely give them a go
Comment 5 Bob Copeland 2009-04-02 18:49:08 UTC
Fair enough.  One thing you can try in the interim is to add to your wpa_supplicant.conf "scan_freq=2412 2437 2462" -- that will limit the channels that are scanned to 1,6, and 11, which should reduce the problems by a lot.
Comment 6 Nicholas J Kreucher 2009-08-27 09:24:37 UTC
I believe this could be the root problem for this distro bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760 (basically, every 2min when NetworkManager does a network scan, all wireless traffic stops for ~5sec until it's done). I see channel hopping happening during the (background!) scan, to echo the comments above.
Comment 7 Bob Copeland 2009-08-27 09:51:24 UTC
Yes, all hardware does this, ath5k just takes longer to scan since there are two bands and tons of channels (and it doesn't help that reset is pretty heavy-weight).  Patches for spreading out background scans have been posted recently.  There are many fewer channels in 2.6.31.
Comment 8 John W. Linville 2010-02-26 16:48:31 UTC
Are you still experiencing this problem with kernels versions >=2.6.31?
Comment 9 Chris Chiappa 2010-03-24 15:04:22 UTC
I still see this on Debian with their 2.6.31 and 2.6.32 kernels (most recently 2.6.32-3 on amd64).  It makes interactive use very bad with NetworkManager.
I've reported it there as Bug#575229: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575229
Comment 10 John W. Linville 2010-08-11 18:16:43 UTC
I think this situation has been vastly improved between the original report and 2.6.35.  I'm going to close this now -- please reopen if you truly believe a serious issue remains.
Comment 11 Helen Allred 2017-06-29 02:53:49 UTC
It doesn't! I still see some minor glyphs corruption, but that's another story.

So it took approximately 10 cycles to get this fixed... ;-)