Description of problem: Cannot suspend or hibernate ASUS U31JG laptop Version-Release number of selected component (if applicable): 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 How reproducible: Every time. Steps to Reproduce: echo mem > /sys/power/state Actual results: Machine goes through suspend procedure and then hangs. The fan comes on at high speed, suggesting the processor is stuck in a loop. Expected results: Machine should suspend.
The bug is still present in the Fedora 15 Alpha kernel.
Created attachment 492164 [details] The workaround I have found a script at http://ubuntuforums.org/showpost.php?p=10359462&postcount=47 which is a workaround. Put this script in /etc/pm/sleep.d/20_custom-ehci_hcd and make sure it is executable and owned by root. Suspend to disk still doesn't work: it suspends just fine, but kernel panics on reboot. Suspend to memory is OK.
*** Bug 697150 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Suspend to disk still doesn't work: it suspends just fine, but kernel panics on > reboot. Suspend to memory is OK. Does it look like https://bugzilla.redhat.com/attachment.cgi?id=492544 attached to bug 697150? See that bug description for a workaround which cured that for me. Would be interesting to know if it, or something similar, helps here too.
(In reply to comment #4) > (In reply to comment #2) > > > Suspend to disk still doesn't work: it suspends just fine, but kernel panics on > > reboot. Suspend to memory is OK. > > Does it look like https://bugzilla.redhat.com/attachment.cgi?id=492544 attached > to bug 697150? See that bug description for a workaround which cured that for > me. Would be interesting to know if it, or something similar, helps here too. It hibernates and resumes, but for some reason the saved image isn't used. When it restarts it tries to enable the swap partition, and then says "software suspend data detected. Rewriting the swap signature." In other words, "I have a saved image, but I'm ignoring it..."
Thanks, seems like two non-related problems: 1) xhci/ehci unbind (kernel) 2) hibernate image detection (probably initrd scripts) Andrew please could you provide output from: # pm-utils-bugreport-info.sh And please provide more data about your swap used for hibernation (e.g. is it in LVM)? And what is the content of your grub.conf?
(In reply to comment #5) > > When it restarts it tries to enable the swap partition, and then says "software > suspend data detected. Rewriting the swap signature." > > In other words, "I have a saved image, but I'm ignoring it..." Are you sure about the last sentence? You do not want to use the same hibernation image more than onec so a signature should be rewritten or you would be in a big trouble on subsequent boots so "Rewriting the swap signature" is what I would expect. In any case with a suitable SUSPEND_MODULES list my Asus K52Jc does "thaw" just fine. The lapto gets apparently consistently when hibernating: [ 7224.510578] irq 17: nobody cared (try booting with the "irqpoll" option) [ 7224.510586] Pid: 0, comm: swapper Tainted: G W 2.6.35.12-88.fc14.x86_64 #1 [ 7224.510590] Call Trace: [ 7224.510594] <IRQ> [<ffffffff81010207>] ? paravirt_read_tsc+0x9/0xd [ 7224.510614] [<ffffffff810a74d7>] __report_bad_irq.clone.1+0x3d/0x8b [ 7224.510617] [<ffffffff810a763f>] note_interrupt+0x11a/0x17f [ 7224.510620] [<ffffffff810a811f>] handle_fasteoi_irq+0xa8/0xce [ 7224.510624] [<ffffffff8100c2ea>] handle_irq+0x88/0x90 [ 7224.510629] [<ffffffff81470b44>] do_IRQ+0x5c/0xb4 [ 7224.510634] [<ffffffff8146b093>] ret_from_intr+0x0/0x11 [ 7224.510635] <EOI> [<ffffffff81265570>] ? intel_idle+0x111/0x139 [ 7224.510643] [<ffffffff8126554f>] ? intel_idle+0xf0/0x139 [ 7224.510648] [<ffffffff81394cf1>] cpuidle_idle_call+0x8b/0xe9 [ 7224.510653] [<ffffffff81008325>] cpu_idle+0xaa/0xcc [ 7224.510660] [<ffffffff814527e6>] rest_init+0x8a/0x8c [ 7224.510665] [<ffffffff81ba1c49>] start_kernel+0x40b/0x416 [ 7224.510669] [<ffffffff81ba12c6>] x86_64_start_reservations+0xb1/0xb5 [ 7224.510672] [<ffffffff81ba13c2>] x86_64_start_kernel+0xf8/0x107 [ 7224.510674] handlers: [ 7224.510675] [<ffffffffa0227da5>] (ath_isr+0x0/0x17e [ath9k]) [ 7224.510689] Disabling IRQ #17 IRQ 17 happens to be associated here with a wireless interface serviced by ath9k driver but despite of this "Disabling" message that interface still works. I have to check if adding ath9k driver to SUSPEND_MODULES will prevent that.
Created attachment 492928 [details] grub.conf
Created attachment 492930 [details] pm-utils-bugreport-info
Andrew thanks, please could you provide your /etc/fstab and output of swapon -s?
(In reply to comment #6) > Thanks, seems like two non-related problems: > 1) xhci/ehci unbind (kernel) > 2) hibernate image detection (probably initrd scripts) > > Andrew please could you provide output from: > # pm-utils-bugreport-info.sh > > And please provide more data about your swap used for hibernation (e.g. is it > in LVM)? It's encrypted, but it's not LVM: [aph@nighthawk ~]$ /sbin/swapon -s Filename Type Size Used Priority /dev/dm-1 partition 6289432 0 -1 /dev/mapper//dev/mapper/luks-4abfe64d-c390-4bcd-9b01-1c7615773497 is active: cipher: aes-xts-plain64 keysize: 512 bits device: /dev/sda5 offset: 4040 sectors size: 12578872 sectors mode: read/write > And what is the content of your grub.conf?
(In reply to comment #10) > Andrew thanks, please could you provide your /etc/fstab /dev/mapper/luks-81316807-19f0-46e7-85e4-31db8c85f4aa / ext4 defaults 1 1 UUID=17745137-32c5-45a2-a9f4-8b760362e1b7 /boot ext3 defaults 1 2 /dev/mapper/luks-4abfe64d-c390-4bcd-9b01-1c7615773497 swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 > and output of swapon -s? Filename Type Size Used Priority /dev/dm-1 partition 6289432 0 -1
Thanks that's all data I need now. I guess it is bug somewhere in initrd scripts which does not count with this combination. AFAIK it works with encrypted LVM swap. I will try to simulate your configuration and track this down.
I've been fighting trying to get hibernate working on my system since F13, where occasionally it worked with 2.6.33.3-85 if I used "resume=UUID=..." on the kernel command line, but have never been able to make it work on F13 2.6.34 kernels or any F14 or F15. I was using encrypted swap not in LVM. Saw this bug, changed my setup to use LVM, and now hibernate works for me in F15, without needing the "resume=UUID" stuff. I'd eventually like to be able to do this without LVM, but for now I'm happy to have it working at all. I've seen two different problems with non-LVM encrypted swap: 1) Sometimes, but not always, hibernate never completes and powers down. Screen goes blank, but very little disk activity, and power light stays on. Caps lock key still toggles its indicator. Waited more than five minutes with no progress. 2) When hibernate does complete, powering up the machine reboots rather than resumes. I haven't seen either problem in F15 with swap in encrypted LVM.
Thanks for that, Eric. It looks like the best thing for me may be to upgrade to F15 and use LLVM this time.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping