Bug 457067
| Summary: | iwl3945 on Dell Latitude D620: keyboard does not respond after resume | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt McCutchen <matt> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 9 | CC: | scholnik | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | kernel-2.6.26.2-14.fc9.i686 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-10-15 00:23:32 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Matt McCutchen
2008-07-29 14:47:29 UTC
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. |