Description of problem: After a suspend to ram, a wireless card does not associate to the accesspoint any more. Even stopping/starting NetworkManager etc. does not solve this. Unloading the module crashes the machine every second time. Version-Release number of selected component (if applicable): kernel-2.6.23.8-63.fc8 How reproducible: every time Steps to Reproduce: 1. boot into kernel 2. use NetworkManager to connect to wireless spot (WPA encrypted) 3. suspend 4. resume 5. Actual results: No network connection possible Expected results: Network connection as before suspend Additional info: Machine is a Thinkpad T43 (ATI X300 video card, Atheros 5312 WLAN device)
Do you get any sort of output from the crash?
Created attachment 289915 [details] section from /var/log/messages just resuming from sleep I'm just trying to get useful logs or to find a reproducible way to crash the kernel via suspend/resume. Attached is a section cut from /var/log/messages showing wakeup from resume. I'm not really sure, whether the line stopping disk etc. while resuming is right. Even "disabling non-boot-cpus" looks like coming from suspend.
I am seeing the exact same symptoms, reproducible every time, with a thinkpad T41. If anyone can suggest what additional info can be useful, I would be happy to provide it.
1. service NetworkManager stop && ifconfig ath0/wlan0 down && modprobe -r ath5k 2. Wait a few minutes (why?) 3. ifconfig wlan0 up && service NetworkManager start reconnects to AP (for me), but not every time. Sadly I don't know exactly, what happens.
On my system, unencrypted connections work without a problem. Also I can connect to WEP network after a resume, if I unload the ath5k mac80211 and cfg80211 modules.
For me, the failure mode involves lots of WEP decrypt failed (ICV) messages, coming from dmesg. Does this happen for you as well? I also seem to have to wait a few minutes after unloading ath5k in order to have a chance to connect to the AP with NetworkManager. However, unloading the modules during suspend and using system-config-network instead of NetworkManager works every time. Does anyone have any suggestions on how to track this down?
OK, I have a WPA2 encrypted link and use NetworkManager. Normally, wpa_supplicant is not started as service; after suspend it looks like wpa_supplicant is started. Stopping it seems to enhance a chance getting a connection. I'll try to reproduce this at the weekend or to configure a network connection without NetworkManager. I can't confirm nor deny WEP decrypt messages. My var/log/messages is already appended to this bugzilla entry.
Created attachment 292306 [details] Clear the key cache after resume in the ath5k driver Recompiling the kernel with the attached patch fixes this problem for me, and I can connect to WEP networks after a suspend-resume cycle. It seems that on my computer, the key cache comes back as junk after resume, causing the bug. I suppose this patch should be merged with the linux-2.6-ath5k-use-soft-wep.patch
Another crash after unloading ath5k. Sadly, nothing is logged into /var/log/messages. Any recommendations, how to get more information about this one? Thanks, Matthias
@Alex Eskin: Thanks a lot! Your attached patch solves my problem. After recompiling a recent kernel (2.6.23.14-107) with your supplied patch I was able to connect directly after resume. I'd appreciate, if this patch could go into ath5k/fedora kernels.
NEEDINFO for me? What is the question?
As I wrote in my first post, a device managed by ath5k did not associate to an access point after suspend/resume. I did try to unload/load the module after resume. That brought me some kernel crashes, but not each time. Sadly, there is no message /stack trace in /var/log/messages With the patch applied to the kernel, those problems do not occur any more. Thus I don't need to unload ath5k. As I said at #10, I'd really appreciate, if the patch would be integrated in fedora kernels. Is it possible, to get the patch into fedora kernels?
http://koji.fedoraproject.org/koji/buildinfo?buildID=33481 That is a rawhide kernel, but AFAIK it should work on F8. There should be an F8 kernel with it soon, but I'm not sure exactly when -- I'll let you know.
Thank you! That sounds great! since I was able to compile a kernel for F8, I'll wait for a new F8 kernel.
Did the fix get into kernel-2.6.23.14-115.fc8? There were some fixes for wireless, so I tried it. Sadly, after suspend ath5k does not reconnect. Either, the fix does not work with the new version, or it didn't make it into 2.6.23-14-115
Not in -115
fixed in 2.6.24.3-12. Thanks a lot.