Latest working kernel version: N/A Earliest failing kernel version: 2.6.27.8 Distribution: Ubuntu 8.10 amd64 Hardware Environment: ThinkPad T61p w/AR5212 miniPCIe Software Environment: Ubuntu 8.10 AMD64, w/compat-wireless snapshot from December 2nd Problem Description: When loaded, the ath5k driver will sometimes produce stutters in my userland performance - I'll be playing music or something else using sound or video, and it'll stutter briefly. I've tested this with no X running and across multiple players, and this is reproducibly only true when the ath5k driver is loaded. I mention this because it sometimes locks my machine up completely - whatever sound was playing on the speaker repeats in an endless stutter, no input devices respond (not even SysRq). Again, only reproducible with ath5k loaded. Steps to reproduce: 1) Load ath5k driver 2) Leave loaded and connected to a network or otherwise for awhile 3) Watch it stutter occasionally 4) Watch a hardlock occur I've checked, and for obvious reasons, I get no messages in /var/log/{syslog,messages} from this. My laptop lacks a serial or parallel port - is there some other way I can debug this?
Not sure if it'll help but you can try turning on ATH5K_DEBUG and setting up a netconsole on a wired ethernet port. Does sysrq-t work while it first starts stuttering? Capturing a few traces at that time could be informative. Can you also lock it up when not playing music? Also, please post your /proc/interrupts after it's been running some time.
Sure. I'll figure out how to set up a netconsole. It's worth noting that this only occurs on WPA networks, as far as I can tell - it's run for hours on WEP networks, but after awhile on a WPA network, it fails dramatically. Yes, it also locks up when not playing music, that only happened once or twice by coincidence, and was interesting as a state indicator.
Additionally, when it first starts stuttering, the system is utterly unresponsive to SysRq input.
(In reply to comment #2) > Sure. I'll figure out how to set up a netconsole. > > It's worth noting that this only occurs on WPA networks, as far as I can tell > - > it's run for hours on WEP networks, but after awhile on a WPA network, it > fails > dramatically. > > Yes, it also locks up when not playing music, that only happened once or > twice > by coincidence, and was interesting as a state indicator. I confirm this behavior. No problem with WEP, With WPA computer locks and become unusable. I also use Ubuntu 8.10. 05:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
So in both cases this is compat-wireless? Can you try with the nohwcrypt parameter? (modprobe ath5k nohwcrypt=1)
I will try it again shortly when I regain access to a WPA network (I'm currently on vacation), but if memory serves I tried this parameter to no effect.
Yes, I also use compat-wireless. I never used the option nohwcrypt and do not have access to WPA wireless for the moment. I will give it a try when going back to university in February. regards,
Ok it is clear that something is going on - I have seen lockups too under heavy load, no oops, nmi_watchdog doesn't work. Since there is a newer bug with more/different info, I'm going to go ahead and close this one so we can put all the info in one place.
*** This bug has been marked as a duplicate of bug 12647 ***