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
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):
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
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.
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
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:
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.