Hide Forgot
Description of problem: When trying to resume after suspend via 'apm -s', some activity occurs but screen remains off and the system does not respond to input. Version-Release number of selected component (if applicable): F7 with all updates as of today How reproducible: always Steps to Reproduce: 1. Boot with apm=on acpi=off since acpi tends not to work on the system (thinkpad X24) 2. apm -s 3. tap keys to resume Actual results: system nonresponsive Expected results: normal resumption Additional info: smolt UUID is 96f45488-944e-485a-b127-f2103430cc59
Hello Virgil, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If so, you might like to try the following: # Find out if the system is locked up completely by hitting the caps lock key. * If the capslock light doesn't toggle, the system is completely dead. Try again, but this time before suspending, activate the pm_trace functionality with echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a few bytes of information which we can use to diagnose which driver failed to resume. After the hang, reboot, boot up again, and save the output of dmesg. * If the capslock light does toggle, then the system did come back up, and it's possible that we just failed to reinitialise the video. http://people.freedesktop.org/~hughsient/quirk may contain further useful information to diagnose this problem. It may also be useful to initiate the suspend from a tty (ctrl-alt-f1) and run pm-suspend ; dmesg > dmesg.out ; sync by hand. Upon resuming you'll now have some more debug info to sift through. Additionally, this way when it resumes, you already have a console logged in from which you can type commands 'blind'. Trying vbetool post for example may bring things back to life. # Try rmmod'ing various modules before doing the suspend. If this makes things work again, retry with a smaller set of modules unloaded. Keep retrying until you narrow down which module is to blame. # Another trick that sometimes works to force video to come back up is to enable the BIOS password. This makes the system resume in a VGA text mode that the kernel recovers from a lot easier. Not a real solution, but it can help to diagnose other problems. If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged. Cheers Chris
Thanks Chris! I did update to newer kernels a couple of times after filing this bug and encountered the same behavior, but the machine is a little behind so I'm updating it now and I'll let you know how that goes. After reproducing the problem this evening the caps lock light did not respond. I then tried suspending and resuming from a tty and the system resumed successfully (good to know!). However, switching back to X at that point resulted in what looked like the same hang (dead caps lock); so it looks like the problem is a hard hang triggered by X activity? I'll try more variations with the latest updates tomorrow. Would a dmesg transcript still be helpful?
Symptoms are identical using the latest kernel (2.6.22.5-76.fc7). Previously I had been disabling ACPI in the boot args and using apm -s, which worked better in older versions of Fedora, but I tried pm-suspend today and got the same result. quirk-checker.sh suggested '--quirk-s3-bios --quirk-s3-mode'. They didn't seem to make a difference.
(In reply to comment #2) > I'll try more variations with the latest updates tomorrow. Would a dmesg > transcript still be helpful? Yes and if you can what would be really good is a dmesg output after the system hangs by ssh'ing into the machine from another computer as this may be a possibility. You might also want to try booting with the nolapic or nohz=off options. Can you also attach an lsmod output. Cheers Chris
Created attachment 196981 [details] lsmod output
Thanks. I attached lsmod output. nolapic and nohz=off did not make a difference. While trying them I did notice that I can reproduce the problem without even suspending, just by switching out to a virtual console and then back to X. So I guess this is not a power management issue.
If you rmmod your atheros driver as in: # rmmod ath_pci ath_hal ath_rate_sample and then try switching, do you still have the same issues?
Created attachment 198071 [details] dmesg output
Unloading the atheros modules did not make a difference as far as I could tell.
Thanks for all that. You might be interested in the following: http://www.thinkwiki.org/wiki/Installation_instructions_for_the_ThinkPad_X24 though clearly the X24 comes with a number of different wireless chips since it was brought out and these are one of the usual suspects in suspend/resume issues. If you could try the following as mentioned above it would be appreciated: Initiate the suspend from a tty (ctrl-alt-f1) and run pm-suspend ; dmesg > dmesg.out ; sync by hand. Upon resuming you'll now have some more debug info to sift through. Additionally, this way when it resumes, you already have a console logged in from which you can type commands 'blind'. Trying vbetool post for example may bring things back to life. Cheers Chris
I didn't attach the pm-suspend dmesg because as I mentioned above the problem reproduces without suspending the machine at all, so I didn't think it would be relevant. The problem occurs only when I switch to X so I doubt a blind console will be available to me. The system is using a PCMCIA wifi card. I'll see if the problem reproduces after booting without the card inserted.
I think I can isolate the problem to the 'radeon' xorg driver. After changing the driver in xorg.conf to 'vesa', I can switch to virtual consoles and back without hanging. pm-suspend and pm-hibernate still don't work (they just blank the screen), but they don't result in a hang, and I suspect apm will work fully.
The system does resume successfully after apm -s when not using the radeon driver.
Hi Virgil, No update on this for a few months - are you still having this issue with the latest kernel? Good to hear you isolated the issue down to the graphics driver - I'll keep this in mind for future sus/res reports I come across. Cheers Chris
Closing as per previous comment. Please re-open if this is still an issue for you.
All updates as of a few days ago had not resolved the resume issue when using the radeon driver. When using the vesa driver, resume worked, but the screen did not turn off while suspended.