Description of problem: I am using iwl3945 on a Dell Latitude D620. When NetworkManager tries to connect to a wireless network after the computer resumes from suspend-to-RAM, the keyboard stops responding (though the mouse still works) and the "events/1" process uses 100% CPU. If I turn off the wireless kill switch on the side of the computer, the keyboard and CPU usage eventually return to normal, but when I turn the switch back on, the bad behavior resumes. Removing and reinserting the iwl3945 module usually fixes the problem until the next suspend-to-RAM. Version-Release number of selected component (if applicable): kernel-2.6.25.11-97.fc9.i686 NetworkManager-0.7.0-0.11.svn3846.fc9.i386 How reproducible: With perhaps 50% probability on each resume. Steps to Reproduce: 1. Configure NetworkManager to automatically connect to a wireless network. 2. Run "pm-suspend" in a gnome-terminal. (I'm not using the GNOME Suspend button because of a separate issue.) 3. Make sure the kill switch is on. Press the power button to resume the computer and enter any necessary BIOS and gnome-screensaver passwords. Actual results: NetworkManager is stuck forever in the one-green-dot stage, occasionally prompting for wireless secrets. Pressing keys on the keyboard has no effect, though the mouse works. "top" (painstakingly started by copying the letters from gucharmap :) indicates that "events/1" is using 100% CPU. Expected results: The keyboard works, CPU usage is reasonable, and NetworkManager connects to the network after a few tries/prompts. Additional info: - I got some stack traces in /var/log/messages, which I will attach. - The problem does not seem to occur with kernel-2.6.25.11-92.fc9.i686.
Created attachment 312879 [details] /var/log/messages output Note the three "INFO: task XXX:### blocked for more than 120 seconds" stack traces near the bottom.
Kyle has got two more kernels built over on koji, why not try these? http://koji.fedoraproject.org/koji/buildinfo?buildID=57826 (2.6.25.13-103.fc9) http://koji.fedoraproject.org/koji/buildinfo?buildID=57445 (2.6.25.12-100.fc9) The .13 kernel appeared only the other day.
(In reply to comment #0) > How reproducible: > With perhaps 50% probability on each resume. More specifically, suspending while NetworkManager is trying to connect to a network (in the one-green-dot stage) appears to trigger the problem.
I can reproduce the problem with both kernel-2.6.25.12-100.fc9.i686 and kernel-2.6.25.13-103.fc9.i686, but it didn't occur immediately after resume; I had to disconnect and reconnect NetworkManager to trigger it. What would help you fix this? I'm no good at kernel hacking, but I can test things / bisect.
I can reproduce the problem with kernel-2.6.25.13-104.fc9.i686. I suspended while NetworkManager was connecting; I resumed; NetworkManager tried and failed to automatically connect; and I canceled the wireless secrets dialog and selected the network again on the nm-applet menu. Only then the keyboard stopped responding and the "events" process started using 100% CPU.
I can still reproduce the problem with kernel-2.6.25.14-106.fc9.i686 . I also tried bisecting with the vanilla kernel. Kernel 94ad374a0751f40d25e22e036c37f7263569d24c has the problem and bce7f793daec3e65ec5c5705d2457b81fe7b5725 doesn't, but I ran into a separate problem with suspend-to-RAM that prevented testing of other versions. I will "bisect" between kernel-2.6.25.11-92.fc9.i686 and kernel-2.6.25.11-97.fc9.i686 instead.
I (on a Dell Latitude D630) and a colleague (on a Thinkpad T61) are having a variation on this problem. We can get the wireless to work after a reboot, but at some point (often after suspend to RAM, but doesn't seem entirely deterministic) a new connection attempt will fail. (At least sometimes with the "events" process using 100% cpu.) Removing and then reinserting the iwl3945 module at this point results in total keyboard lockup requiring a hard reboot. I'm not actually sure what kernel version this started at, but kernel-2.6.25.11-92.fc9.x86_64 seems about the right time frame. I wasn't using wireless much so I didn't see the problem for a while. BTW - we mostly do network connections "by hand", not with NetworkManager.
The problem appears to be gone with kernel-2.6.26.2-14.fc9.i686 .
This problem has been fixed for a while.