Description of problem: When I suspend or hibernate the computer (using the KDE menu, pm-suspend or even 'echo -n "disk" > /sys/power/state'), the computer completes the suspend/hibernate procedure, but instead of going to sleep it starts right up and resumes. It's easier to see it when I hibernate the machine: it stores the memory on the disk (I can see the progress counter), and then it reboots the computer, and resumes from the disk. In /var/log/messages, I see nothing obvious: Dec 1 08:02:13 gauret kernel: ACPI: Preparing to enter system sleep state S3 Dec 1 08:02:13 gauret kernel: Disabling non-boot CPUs ... Dec 1 08:02:13 gauret kernel: Extended CMOS year: 2000 Dec 1 08:02:13 gauret kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Dec 1 08:02:13 gauret kernel: Intel machine check architecture supported. Dec 1 08:02:13 gauret kernel: Intel machine check reporting enabled on CPU#0. Dec 1 08:02:13 gauret kernel: Extended CMOS year: 2000 Dec 1 08:02:13 gauret kernel: ACPI: PCI Interrupt Link [LTID] BIOS reported IRQ 0, using IRQ 22 Dec 1 08:02:13 gauret kernel: ACPI: Waking up from system sleep state S3 Except it never went into sleep state S3... I am usually using the proprietary nvidia kernel module, but I tried without it and the bug is still there. This did not happen with the F9 kernel. I upgraded from F9 to F10 using preupgrade. Version-Release number of selected component (if applicable): kernel-2.6.27.5-117.fc10.i686 How reproducible: always
I have news : suspend/hibernate works fine after a fresh reboot, but fail everytime afterwards. This is with kernel-2.6.27.12-170.2.5.fc10.i686
2.6.27.12-170.2.5.fc10.x86_64 AMD X2 and Nvidia card In F9 suspend worked just fine. But now in F10 every second attempt (after a reboot) to suspend fails. My log is similar to the one reported before and I'll post it at the end. I found more bug reports that specifically mention it only not working on the second attempt. I will point from there to here, though Aurelien Bompard doesn't seem to specifically have this only on the second time. Feb 4 13:02:51 ArmyBox kernel: PM: Syncing filesystems ... done. Feb 4 13:03:03 ArmyBox kernel: Freezing user space processes ... (elapsed 0.00 seconds) done. Feb 4 13:03:03 ArmyBox kernel: Freezing remaining freezable tasks ... (elapsed 3.61 seconds) done. Feb 4 13:03:03 ArmyBox kernel: Suspending console(s) (use no_console_suspend to debug) Feb 4 13:03:03 ArmyBox kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache Feb 4 13:03:03 ArmyBox kernel: sd 0:0:0:0: [sda] Stopping disk Feb 4 13:03:03 ArmyBox kernel: serial 00:0b: disabled Feb 4 13:03:03 ArmyBox kernel: mpu401 00:07: disabled Feb 4 13:03:03 ArmyBox kernel: ns558 00:06: disabled Feb 4 13:03:03 ArmyBox kernel: NVRM: RmPowerManagement: 4 Feb 4 13:03:03 ArmyBox kernel: sky2 eth0: disabling interface Feb 4 13:03:03 ArmyBox kernel: sata_sil24 0000:01:00.0: PCI INT A disabled Feb 4 13:03:03 ArmyBox kernel: forcedeth 0000:00:13.0: wake-up capability disabled by ACPI Feb 4 13:03:03 ArmyBox kernel: forcedeth 0000:00:13.0: PME# disabled Feb 4 13:03:03 ArmyBox kernel: sata_nv 0000:00:10.0: PCI INT A disabled Feb 4 13:03:03 ArmyBox kernel: Intel ICH 0000:00:0d.0: PCI INT A disabled Feb 4 13:03:03 ArmyBox kernel: ehci_hcd 0000:00:0b.1: PCI INT B disabled Feb 4 13:03:03 ArmyBox kernel: ohci_hcd 0000:00:0b.0: PCI INT A disabled Feb 4 13:03:03 ArmyBox kernel: ohci_hcd 0000:00:0b.0: PME# enabled Feb 4 13:03:03 ArmyBox kernel: ohci_hcd 0000:00:0b.0: wake-up capability enabled by ACPI Feb 4 13:03:03 ArmyBox kernel: ohci_hcd 0000:00:0b.0: PME# enabled Feb 4 13:03:03 ArmyBox kernel: ohci_hcd 0000:00:0b.0: wake-up capability enabled by ACPI Feb 4 13:03:03 ArmyBox kernel: ACPI: Preparing to enter system sleep state S3 Feb 4 13:03:03 ArmyBox kernel: Disabling non-boot CPUs ... Feb 4 13:03:03 ArmyBox kernel: Broke affinity for irq 1 Feb 4 13:03:03 ArmyBox kernel: CPU 1 is now offline Feb 4 13:03:03 ArmyBox kernel: SMP alternatives: switching to UP code Feb 4 13:03:03 ArmyBox kernel: CPU1 is down Feb 4 13:03:03 ArmyBox kernel: Extended CMOS year: 2000 Feb 4 13:03:03 ArmyBox kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Feb 4 13:03:03 ArmyBox kernel: Extended CMOS year: 2000 Feb 4 13:03:03 ArmyBox kernel: pcieport-driver 0000:00:16.0: Linking AER extended capability Feb 4 13:03:03 ArmyBox kernel: pcieport-driver 0000:00:17.0: Linking AER extended capability Feb 4 13:03:03 ArmyBox kernel: Enabling non-boot CPUs ... Feb 4 13:03:03 ArmyBox kernel: SMP alternatives: switching to SMP code Feb 4 13:03:03 ArmyBox kernel: Booting processor 1/1 ip 6000 Feb 4 13:03:03 ArmyBox kernel: Initializing CPU#1 Feb 4 13:03:03 ArmyBox kernel: Calibrating delay using timer specific routine.. 4822.00 BogoMIPS (lpj=2411003) Feb 4 13:03:03 ArmyBox kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Feb 4 13:03:03 ArmyBox kernel: CPU: L2 Cache: 1024K (64 bytes/line) Feb 4 13:03:03 ArmyBox kernel: CPU 1/1 -> Node 0 Feb 4 13:03:03 ArmyBox kernel: CPU: Physical Processor ID: 0 Feb 4 13:03:03 ArmyBox kernel: CPU: Processor Core ID: 1 Feb 4 13:03:03 ArmyBox kernel: x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 Feb 4 13:03:03 ArmyBox kernel: CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ stepping 02 Feb 4 13:03:03 ArmyBox kernel: CPU1 is up Feb 4 13:03:03 ArmyBox kernel: ACPI: Waking up from system sleep state S3
(In reply to comment #2) > though Aurelien Bompard doesn't seem to specifically have this only on > the second time. I do have this problem only on the second time, that's what I tried to say in comment 1. After a fresh reboot it works fine, but everytime after that it fails. So we have similar symptoms here.
Oh, indeed. I completely read over that switching between different bugs. Then I think the other two I also posted in are possibly duplicates.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.