Description of problem: I have a Dell Latitude D620 laptop. With Fedora 11, suspending and resuming mostly worked: occasionally, the display would be off after resuming, although the system would still be functioning. (To recover, I would simply suspend and then resume until I got a resume for which the display came back.) However, suspend/resume functionality has clearly regressed under Fedora 12. Now, almost 50% of the time, the entire system hangs on resuming from suspend. (It just isn't that the display is off; the Caps Lock key does nothing.) I've tested these kernels: kernel-2.6.31.5-127.fc12.x86_64 kernel-2.6.31.6-145.fc12.x86_64 They both exhibit the problem. I'm using the nv driver with the latest xorg: xorg-x11-drv-nv-2.1.15-2.fc12.x86_64 xorg-x11-server-Xorg-1.7.1-9.fc12.x86_64 (I can't use the nouveau driver; it just turns my screen red, and then melts it.)
Created attachment 374948 [details] output from /var/log/messages Hmmm. Perhaps this isn't a video driver issue after all; per the syslog messages here, the system does seem to recover, but then seems to hang when the iwl3945 driver reinitializes. I'm not sure if it still has any effect under F12, but I unload the iwl3945 driver when suspending: $ cat /etc/pm/config.d/unload_modules # # $ date; ./quirk-checker.sh # # Wed May 21 10:55:50 EDT 2008 # # Checking your system... # # WARNING: iwl3945 is usually okay for suspend - but it might be worth trying # unloading it. # # WARNING: KVM will not suspend in kernels less than 2.6.23, but should work # okay in later kernels. # # Suggestions: # # Add 'SUSPEND_MODULES="kvm_intel kvm iwl3945"' to # /etc/pm/config.d/unload_modules! # SUSPEND_MODULES="iwl3945" I will try manually removing the iwl3945 module before suspending for a while, and see if I still have hangs.
Created attachment 375875 [details] /var/log/messages output from another hang-on-resume Nope, it's not the iwl3945 driver; here's /var/log/messages from a hang that occurred when the driver wasn't loaded.
At this point, what other information can I provide (or what other actions can I take) to help debug this problem? I know that the nv X11 driver is known to be problematic when it comes to ACPI suspend/resume operations, but the nouveau driver is not an option at this time (see bug 543091). I knew how to perform ACPI suspend/resume debugging using pm-utils and this page: http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-debug.html ...but the page is gone now (404 Not Found), and I haven't seen any information on how to debug suspend/resume problems with DeviceKit-power...
Ah, I finally found where the quirk debugging pages went: http://hal.freedesktop.org/quirk/ I enabled PM_TRACE via /sys/power/pm_trace and reproduced a hang. The hash match says: $ grep "hash matches" /tmp/dmesg.txt hash matches drivers/base/power/main.c:416 I'm not sure if this is useful, because the quirk debugging pages claim CONFIG_PM_TRACE doesn't work on x86_64 (which is the architecture I'm running), but I suspect the patch to enable CONFIG_PM_TRACE on x86_64 is in the kernel now. Another piece of information I've noticed that might be helpful: if my laptop is docked when I suspend it, it almost always resumes successfully. If my laptop is not docked when I suspend it, it almost always hangs on suspend. Does any of this information help? Is there any more useful information I can gather? Is there any additional documentation you can point me to? (It is EXTREMELY annoying to have ACPI resume crash so frequently for Fedora 12 on my laptop, when Fedora 11 worked almost perfectly. I'm seriously debating just reinstalling Fedora 11 on my laptop, but I'd really prefer to find the regression between F11 and F12 and fix it...)
Since switching to KMS+nouveau (see bug 543091), I cannot reproduce this bug. So, I'm quite confident that some combination of (UMS, nv driver) was the culprit here. Since KMS is preferred nowadays, there's no point in trying to debug this problem further.