Hide Forgot
Description of problem: With FC6 kernels suspend works only in the first part. Attempts to wake up a machine end up with the following on a screen: .... pnp: Device 00:06 activated. pnp: Device 00:08 activated. pnp: Failed to activate device 00:0a. Restarting tasks... done Enabling non-boot CPUs ... and in this moment everything is dead. No keyboard, and that includes SysRq, no network connection, no anything although the above was recorded in logs on a disk. It does not matter if I add to a boot line options like 'noapic' and/or various 'acpi=...'. Effects are always the same. This particular machine used to suspend to memory (almost) fine with FC4 kernels. The laptop actually does "hibernate" without any problems, at least so far, and when doing that an output quoted above is immediately followed by: ..... ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Lid Switch [LID] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. ...... and everything nicely finishes. BIOS in this box is, unfortunately, creaky and does not provide any real options at all (and I am not aware of updates). To make things more "interesting" it appears that there is no good way to disable "Suspend" buttons, without removing "Hibernate" as well, other then by editing 'pm_main()' in /etc/pm/functions (which will get clobbered on the next update of 'pm-utils'). Sigh! Maybe this is another manifestation of bug 203312 and bug 201508? I am seeing exactly the same "BUG: sleeping function ..." when doing hibernate; although I do not have a record of that from suspend. I am getting only kernel: Intel machine check architecture supported. restorecond: Read error (Interrupted system call) but this shows up in both cases. "Wakeup messages" look otherwise pretty similar for both up to the moment a machine is dead when coming back from suspend. I attach an output from dmidecode for the machine in question. Version-Release number of selected component (if applicable): kernel-2.6.18-1.2849.fc6 How reproducible: always Additional info: Unfortunately this is not mine laptop so later testing possibilities are quite limited.
Created attachment 141603 [details] a dmidecode output for Acer TM 740
Sorry for the really slow response. Have you been able to try a newer kernel or Fedora release, and does it help at all? (Work on hibernation and suspend to ram is going on all the time, so you can generally expect that newer kernels will improve the situation).
> Have you been able to try a newer kernel I do have now an access to TM 740. Maybe in the future. OTOH see a comment in bug 188391 about experiences with suspend/hibernate on F8 and with TM 230 (not the same beast).
That Acer TM 740 in question is NOT available to me anymore. Another TravelMate, but 230, does currently suspend and hibernate but not with a default configuration supplied by F8. It needs updated /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-acer.fdi See bug 437886 for details. The last time I looked there were no quirk data for 740 so quite likely that laptop still has issues but nowadays I cannot check that.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
See comment #4 from yesterday.
thank you for your update.