Bug 542878

Summary: system frequently hangs after resume from suspend
Product: [Fedora] Fedora Reporter: James Ralston <ralston>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dougsland, gansalmon, itamar, jesse.brandeburg, kernel-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-25 23:43:07 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 Flags
output from /var/log/messages
none
/var/log/messages output from another hang-on-resume none

Description James Ralston 2009-12-01 02:21:15 UTC 
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.)
Comment 1 James Ralston 2009-12-01 02:35:03 UTC 
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.
Comment 2 James Ralston 2009-12-03 18:56:36 UTC 
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.
Comment 3 James Ralston 2009-12-03 19:38:27 UTC 
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...
Comment 4 James Ralston 2010-01-13 22:00:31 UTC 
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...)
Comment 5 James Ralston 2010-05-25 23:43:07 UTC 
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.