This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 807615 - In both fedora 15 and 16 after pm-hibernate resume nearly completes, then reboots. Can be suppressed with acpi=off when resuming
In both fedora 15 and 16 after pm-hibernate resume nearly completes, then reb...
Status: CLOSED DUPLICATE of bug 806315
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-03-28 06:44 EDT by aaronsloman
Modified: 2012-03-28 17:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-28 17:55:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description aaronsloman 2012-03-28 06:44:52 EDT
Description of problem:
I have a desktop PC running fedora 15 (currently and a Dell latitude E6410 laptop running fedora 16 (currently 3.3.0-4.fc16.i686). On both machines I find for these and earlier kernels that after pm-hibernate resume may work once or twice and then the next time seems to be about to complete, fails, and reboots, making hibernate unusable.

The F15 machine uses grub, the F16 machine uses grub2. A similar workaround works for both.

Following an obscure hint found in a search for cures I now have two boot entries, in grub/grub2 one for booting and one for resuming. The resume entry is the default and it is identical with the boot entry except for the addition of "acpi=off". This seems to be totally reliable at fixing the problem: on both machines resume completes as expected, and I can go through many hibernate-resume cycles without problems.

Two problems remain: after kernel update I have to make a duplicate entry by hand in grub.cfg/grub.conf, which not all users would be able to do. Also I have to remember that a fresh boot requires the entry without acpi=off (as that stops some things working when used at boot time).

I can live with this but it is not acceptable for a production system.

I don't know if this has something to do with use of i915 driver, required for both machines (both use Intel core i5 cpu and intel integrated graphics). 

Version-Release number of selected component (if applicable):

Symptom is present in latest releases of fedora 15 and fedora 16 kernels. However it was also present in previous kernels. I thought at first that it might be connected with the tendency of pm-hibernate to crash, but that has been fixed in 3.3.0-4.fc16.i686 whereas my resume bug continues (as reported in bug #785384 -- see comment no 42).

How reproducible: Very. Leaving out acpi=off causes resume to reboot usually between second and fourth time hibernating.

Steps to Reproduce:
1. pm-hibernate
2. attempt to resume
Actual results:
Note: I boot in non-graphical mode so that I can see progress. After hibernate, everything seems to be progressing normally, including switch to high resolution, then shortly before resume is about to complete it freezes with screen blank and a reboot starts automatically.

But if I select grub menu item with acpi=off, or add it manually at boot time, the resume succeeds always.

Expected results:
Should not need different kernel flags for boot and resume.

Additional info:
I have had this problem for several months. I assumed it was connected with the problem of hibernate freezing, but it seems not to be. So, although I had mentioned this in the bug reports on freezing I have been advise to raise this as a separate bug.
Comment 1 aaronsloman 2012-03-28 17:55:09 EDT
Apologies for duplication.
I forgot that I had reported this earlier, as bug #806315
Comment 2 aaronsloman 2012-03-28 17:55:42 EDT

*** This bug has been marked as a duplicate of bug 806315 ***

Note You need to log in before you can comment on or make changes to this bug.