Description of problem: (on Dell Latitude E6410): I have grub2 entries for Fedora 16 and for Windows 7 on same drive. /boot has its own partition. If I run Win7 and then shut-down and then power up and run Fedora, I can use pm-hibernate OK. However, if when running Win7 instead of shut-down I use reboot/restart, I can boot Fedora from grub menu, but pm-hibernate fails, though as far as I can tell everything else works. In order to get hibernation working again I have to shut down fedora completely and reboot. Version-Release number of selected component (if applicable): pm-utils-1.4.1-13.fc16.i686 kernel-3.4.4-4.fc16.i686 grub2-1.99-13.fc16.3.i686 How reproducible: So far pm-hibernate has failed to work every time after rebooting from Win7 (i.e. without complete shut-down between windows and linux) Steps to Reproduce: 1. (Optional I think) Run Fedora and hibernate. 2. Reboot and run Windows 3. Reboot/Restart from windows (i.e. do not shut down completelyfrom windows) 4. Select Fedora from grub menu 5. When Fedora is up run pm-hibernate Actual results: Hibernate starts, and it goes out of graphic mode for a while then comes back with full linux Xwindow screen. The only way to shut down after that is either reboot or shutdown, not hibernate. Expected results: Hibernate should work after reboot from windows. Additional info: As long as I shut down completely from windows, then power up and go back to fedora from grub2 menu, pm-hibernate works fine. It seems that windows re-start leaves something in a state that prevents linux from hibernating. Would it be possible for grub or pm-hibernate to detect that state and fix it? I can now live with this, but for a user who does not know about the need to avoid using restart from windows, this can be a time-wasting and mysterious bug. I spent many hours trying to understand how I could get hibernate to work after hibernating, running windows then rebooting into linux from windows, and it was only a hunch that led me to try shutting down windows instead of rebooting/restarting. Others may not have that hunch and will conclude that pm-hibernate is unusable after running windows and then resuming linux, and will probably waste time for others by filing bug reports about hibernate not working. So a fix for this seems to be highly desirable, even though the bug no longer bothers me.
I guess the firmware is not correctly reset after reboot, maybe the BIOS update could help. In case it is kernel failure, some kernel workaround could be added. Please provide output of the following command (after hibernation failure and reboot) to check whether it is kernel or pm-utils issue: # pm-utils-bugreport-info.sh Also try booting the kernel with the following arguments (add them to grub): no_console_suspend debug ignore_loglevel acpi.debug_layer=0x2 acpi.debug_level=0xffffffff 3 And then hibernate by: # echo disk > /sys/power/state It may show some hints whats wrong during hibernation. There could be also written something useful in syslog that could help.
(In reply to comment #1) > I guess the firmware is not correctly reset after reboot, maybe the BIOS > update could help. I think I have the latest BIOS (updated twice since the machine was new). But I'll check again. Thanks for the other information. It will require me to find some free time to experiment, which is a bit difficult now. When I get the time I'll report back. Note that if I reboot from linux I have no problem using hibernate after the reboot. It is only if I reboot from Win7 that the problem arises. So if it is a bug in windows (e.g. because the windows developers assume that anyone using reboot wishes to re-enter windows, not another operating system) then it may be impossible for linux developers to fix, unless grub or the kernel can detect what windows has done and alter it during the reboot process. Anyhow, I hope to report back later.
(In reply to comment #2) > So if it is a bug in windows (e.g. because the windows developers assume > that anyone using reboot wishes to re-enter windows, not another operating > system) then it may be impossible for linux developers to fix, unless grub > or the kernel can detect what windows has done and alter it during the > reboot process. > Such problems was quite common in the past. The windows driver set the firmware / device to some specific state and it wasn't reset on reboot to initial state that was expected by Linux driver. Sometimes this was resolvable by BIOS update, sometimes the Linux driver was fixed to cope with it. But at least we need to find out which driver is in trouble and why.
Also try to check with newer version of kernel / Fedora (e.g. from the Live CD). Maybe the problem is already fixed.
(In reply to comment #1) > I guess the firmware is not correctly reset after reboot, maybe the BIOS > update could help. > > Also try booting the kernel with the following arguments (add them to grub): > no_console_suspend debug ignore_loglevel acpi.debug_layer=0x2 > acpi.debug_level=0xffffffff 3 > > And then hibernate by: > # echo disk > /sys/power/state I have tried that, and also using pm-hibernate, after upgrading to kernel3.4.7-1.fc16.i686. I still get hibernate failing after windows reboot, but not after windows shutdown. I did not notice anything new being displayed on the terminal, with the extra grub arguments. However, there are differences in the entries in /var/log/messages and the output of pm-utils-bugreport-info.sh Messages when hibernate SUCCEEDS (after windows shutdown and fedora boot): Aug 12 13:29:40 lape kernel: [ 72.543106] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. Aug 12 13:29:40 lape kernel: [ 72.582944] sd 0:0:0:0: [sda] Synchronizing SCSI cache Aug 12 13:29:40 lape kernel: [ 72.714470] e1000e 0000:00:19.0: wake-up capability enabled by ACPI Aug 12 13:29:40 lape kernel: [ 72.795770] PM: freeze of devices complete after 241.945 msecs Aug 12 13:29:40 lape kernel: [ 72.795843] PM: late freeze of devices complete after 0.064 msecs Aug 12 13:29:40 lape kernel: [ 72.796352] PM: noirq freeze of devices complete after 0.503 msecs Aug 12 13:29:40 lape kernel: [ 72.796661] ACPI: Preparing to enter system sleep state S4 Aug 12 13:29:40 lape kernel: [ 72.801795] PM: Saving platform NVS memory Aug 12 13:29:40 lape kernel: [ 72.802665] Disabling non-boot CPUs ... Messages when hibernate FAILS and linux continues running (after windows reboot): Aug 12 11:34:40 lape kernel: [ 341.379427] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. Aug 12 11:34:40 lape kernel: [ 341.421409] sd 0:0:0:0: [sda] Synchronizing SCSI cache Aug 12 11:34:40 lape kernel: [ 341.964328] e1000e 0000:00:19.0: em1: Hardware Error Aug 12 11:34:40 lape kernel: [ 342.725933] pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2 Aug 12 11:34:40 lape kernel: [ 342.725940] dpm_run_callback(): pci_pm_freeze+0x0/0xa0 returns -2 Aug 12 11:34:40 lape kernel: [ 342.725959] PM: Device 0000:00:19.0 failed to freeze async: error -2 Aug 12 11:34:40 lape kernel: [ 342.757468] usb usb1: root hub lost power or was reset Aug 12 11:34:40 lape kernel: [ 342.761432] usb usb2: root hub lost power or was reset Aug 12 11:34:40 lape kernel: [ 342.877927] dell_wmi: Received unknown WMI event (0x11) Aug 12 11:34:40 lape kernel: [ 343.069740] ata6: SATA link down (SStatus 0 SControl 300) Aug 12 11:34:40 lape kernel: [ 343.071739] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 12 11:34:40 lape kernel: [ 343.073085] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04) Aug 12 11:34:40 lape kernel: [ 343.073731] ata5: SATA link down (SStatus 0 SControl 300) Aug 12 11:34:40 lape kernel: [ 343.075710] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Aug 12 11:34:40 lape kernel: [ 343.080562] ata2.00: configured for UDMA/100 Aug 12 11:34:40 lape kernel: [ 343.088730] usb 2-1: reset high-speed USB device number 2 using ehci_hcd Aug 12 11:34:40 lape kernel: [ 343.112232] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04) Aug 12 11:34:40 lape kernel: [ 343.112678] ata1.00: configured for UDMA/133 Aug 12 11:34:40 lape kernel: [ 343.112797] sd 0:0:0:0: [sda] Starting disk Aug 12 11:34:40 lape kernel: [ 343.304525] usb 1-1: reset high-speed USB device number 2 using ehci_hcd Aug 12 11:34:40 lape kernel: [ 343.329488] firewire_core 0000:03:00.4: rediscovered device fw0 Aug 12 11:34:40 lape kernel: [ 343.491483] usb 2-1.8: reset full-speed USB device number 3 using ehci_hcd Aug 12 11:34:40 lape kernel: [ 343.696334] usb 1-1.4: reset high-speed USB device number 3 using ehci_hcd Aug 12 11:34:40 lape kernel: [ 344.637122] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S Aug 12 11:34:40 lape kernel: [ 344.645316] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1 Aug 12 11:34:40 lape kernel: [ 344.651412] dell_wmi: Received unknown WMI event (0x11) Aug 12 11:34:40 lape kernel: [ 344.818275] PM: restore of devices complete after 2063.135 msecs Aug 12 11:34:40 lape kernel: [ 344.819885] Restarting tasks ... done. .... [Eventually returns to display state showing Xterm window with hibernate command which failed] Does that indicate that there's a problem with usb devices after windows reboot? Difference in output of pm-utils-bugreport-info.sh with and without hibernate succeeding. The same modules are shown in the output, though in different orders. The two outputs are the same up to a point. Here's the bugreport after SUCCESSFUL hibernate (following complete windows shutdown and linux boot): /usr/lib/pm-utils/sleep.d/99video hibernate hibernate: success. Sun Aug 12 12:08:56 BST 2012: performing hibernate Sun Aug 12 13:29:40 BST 2012: Awake. Sun Aug 12 13:29:40 BST 2012: Running hooks for thaw Running hook /usr/lib/pm-utils/sleep.d/99video thaw hibernate: ...etc.... (The time gap was a result of pausing for lunch!) Here's the bugreport output after FAILED hibernate (attempted after windows reboot redirected into linux boot): /usr/lib/pm-utils/sleep.d/99video hibernate hibernate: success. Sun Aug 12 11:34:36 BST 2012: performing hibernate /usr/lib/pm-utils/pm-functions: line 321: echo: write error: No such file or directory Sun Aug 12 11:34:40 BST 2012: Awake. Sun Aug 12 11:34:40 BST 2012: Running hooks for thaw Running hook /usr/lib/pm-utils/sleep.d/99video thaw hibernate: Note the 'write error' report above. I looked in the (pm-functions) file referred to and found this in lines 312 to 323. if [ -z "$HIBERNATE_MODULE" ] && \ [ -f /sys/power/disk ] && \ grep -q disk /sys/power/state; then HIBERNATE_MODULE="kernel" do_hibernate() { [ -n "${HIBERNATE_MODE}" ] && \ grep -qw "${HIBERNATE_MODE}" /sys/power/disk && \ echo -n "${HIBERNATE_MODE}" > /sys/power/disk echo -n "disk" > /sys/power/state } fi Could there be a bug in that file causing the write error? I used google to search for that error report, and found that others have reported this. E.g. here's an Arch linux report, although it does not mention rebooting from windows: https://bugs.archlinux.org/task/21944 And this slackware discussion: http://slaky.blogspot.co.uk/, under: 2.6.33 and 2.6.34 kernel suspend hibernate trouble, which states: This is not a bug. This is caused from: kernel: hub 6-0:1.0: cannot reset port 1 (err = -19) kernel: hub 6-0:1.0: cannot disable port 1 (err = -19) PM: Device usb2 failed to freeze async: error -2 kernel: PM: Device usb2 failed to suspend async: error -2 kernel: PM: Some devices failed to suspend I can't tell if those comments are really relevant to my problem. Is it possible that windows reboot leaves usb devices in a state that causes problems for linux hibernate? I'll now go and see if I have problems using usb devices in linux after windows reboot.
(In reply to comment #5) I wrote: > I can't tell if those comments are really relevant to my problem. Is it > possible that windows reboot leaves usb devices in a state that causes > problems for linux hibernate? I'll now go and see if I have problems using > usb devices in linux after windows reboot. After windows reboot I was able to use usb ports for flash memory, usb mouse, and dvb-tv usb dongle. But pm-hibernate still fails, and I still get Sun Aug 12 17:14:07 BST 2012: performing hibernate /usr/lib/pm-utils/pm-functions: line 321: echo: write error: No such file or directory and in /var/log/messages: Aug 12 17:14:08 lape kernel: [ 436.281229] PM: Syncing filesystems ... done. Aug 12 17:14:11 lape kernel: [ 436.327165] Freezing user space processes ... (elapsed 0.01 seconds) done. Aug 12 17:14:11 lape kernel: [ 436.339615] PM: Preallocating image memory... done (allocated 94617 pages) Aug 12 17:14:11 lape kernel: [ 436.414084] PM: Allocated 378468 kbytes in 0.07 seconds (5406.68 MB/s) Aug 12 17:14:11 lape kernel: [ 436.415635] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. Aug 12 17:14:11 lape kernel: [ 436.451191] sd 0:0:0:0: [sda] Synchronizing SCSI cache Aug 12 17:14:11 lape kernel: [ 437.011217] pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2 Aug 12 17:14:11 lape kernel: [ 437.011225] dpm_run_callback(): pci_pm_freeze+0x0/0xa0 returns -2 Aug 12 17:14:11 lape kernel: [ 437.011242] PM: Device 0000:00:19.0 failed to freeze async: error -2 Aug 12 17:14:11 lape kernel: [ 437.036457] usb usb1: root hub lost power or was reset Aug 12 17:14:11 lape kernel: [ 437.040384] usb usb2: root hub lost power or was reset I guess I'll just have to remember never to reboot/restart directly from windows -- only shut down.
Thanks for info. > /usr/lib/pm-utils/pm-functions: line 321: echo: write error: No such file or > directory This indicates the problem is in kernel, i.e. the kernel refuse to hibernate for some reason. The cause of this problem seems to be in network controller: > Aug 12 11:34:40 lape kernel: [ 341.964328] e1000e 0000:00:19.0: em1: Hardware Error > Aug 12 11:34:40 lape kernel: [ 342.725933] pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2 > Aug 12 11:34:40 lape kernel: [ 342.725940] dpm_run_callback(): pci_pm_freeze+0x0/0xa0 returns -2 > Aug 12 11:34:40 lape kernel: [ 342.725959] PM: Device 0000:00:19.0 failed to freeze async: error -2 You can try to remove the module before hibernation (this is only workaround): # ifconfig em1 down # modprobe -r e1000e # pm-hibernate The e1000e driver is under heavy development, the driver version included in kernel-3.4.7-1 is 1.9.5. It's quite old, current upstream version is 2.0.0.1 and it contains many interesting bug fixes in comparison to 1.9.5. The current version in F17 kernel-3.5.1-1.fc17 is 2.0.0 (not too much different from 2.0.0.1). Thus it would be great to try with F17 (probably liveCD should be usable for this test), or you could try to upgrade the e1000e driver on F16 yourself (unsupported), hints: 1. yum install kernel-devel 2. download driver from: http://sourceforge.net/projects/e1000/files/e1000e stable/2.0.0.1/ 3. unpack, 4. cd src && make && make install 5. modprobe -r e1000e && modprobe e1000e 6. check with dmesg, that you have the 2.0.0.1 version, i.e.: e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0.1-NAPI
(In reply to comment #7) > The e1000e driver is under heavy development, the driver version included in > kernel-3.4.7-1 is 1.9.5. It's quite old, current upstream version is 2.0.0.1 > and it contains many interesting bug fixes in comparison to 1.9.5. The > current version in F17 kernel-3.5.1-1.fc17 is 2.0.0 (not too much different > from 2.0.0.1). Thus it would be great to try with F17 (probably liveCD > should be usable for this test), or you could try to upgrade the e1000e > driver on F16 yourself (unsupported) I decided not to risk damaging my F16 installation, so have got the liveCD for F17+lxde and am installing to a spare partition (on Dell Latitude E6410). (I assume I would not be able to test hibernate while running a live CD without actually installing it.) The first attempt failed because I wanted to re-use my old /usr/local partition and installation crashed because it tried to add /usr/local/man directories and they already existed. That's no reason to crash. It should have renamed the old ones and created the new ones. I'll submit a bug report. Meanwhile starting to install F17 again. I'll report back later.
(In reply to comment #8) > (I assume I would not be able to test hibernate while running a live CD > without actually installing it.) > It depends where is your swap. If your swap is on physical partition, it may work from the LiveCD (we have used this setup during PM test days). If your swap is on LVM or even encrypted it will probably not work from the LiveCD. However, the physical installation is always the best option.
(In reply to comment #9) > (In reply to comment #8) > > (I assume I would not be able to test hibernate while running a live CD > > without actually installing it.) > > > It depends where is your swap. If your swap is on physical partition, it may > work from the LiveCD (we have used this setup during PM test days). If your > swap is on LVM or even encrypted it will probably not work from the LiveCD. > However, the physical installation is always the best option. I do use swap on a physical partition, and also /boot with grub information is in its own partitition. I had thought that getting a live CD started after restarting windows in such a way that I could test hibernating and resuming would be tricky. Anyhow, I have now got F17 running with kernel kernel 3.5.1-1.fc17.i686 At first I thought the hibernate problem after windows restart had been solved, then more experimenting revealed that this interacts with bug #806315 (Resume from pm-hibernate requires acpi=off on Dell latitude E6410 using kernel 3.3.0-4.fc16) If I use standard grub+boot settings, run windows, leave it with restart, enter linux, then I can hibernate. However resume then fails (most times) unless I resume with acpi=off added to boot parameters. If I use acpi-off when resuming after hibernate, everything works perfectly for me (maybe not for others) except that if I hibernate linux, then run win7 then leave with 'restart' then resume linux with acpi=off, I can no longer hibernate! The error messages are the same as reported above in comment #5, for for F16 . (My normal mode of working is repeated hibernate and resume without rebooting -- e.g. on my desktop PC running 3.3.7-1.fc16.i686 'uptime' shows 67 days although most of those days I have hibernated and resumed at least once, and sometimes more. The experiments reported here were on a laptop.) Anyhow it looks as if acpi=off stops hibernate working but only after windows 7 restart. So the workaround is never restart windows in order to resume linux, only shutdown windows. I hope that makes sense. If there is some alternative to 'acpi=off' to enable linux to resume from hibernate (with i915 driver) I am willing to try it, and then see if that solves the problem of hibernating after windows restart. But I've done a lot of searching and experimenting and have not found any other way to enable resume to complete. Without acpi=off resume gets almost to the end of resuming, as shown by the percentage progress report, then the screen goes blank and it reboots. It seems to be related to the last stage of restoring graphic mode after resume, but everything goes too fast to see exactly what's happening, and I can't find any relevant error log.
To sort this out: 1) It seems this problem gets fixed (at least partially) by kernel upgrade, because the machine didn't refuse to hibernate after reboot from windows. 2) Another problem (probably with video driver) encountered that blocks the machine to correctly resume, dupe of bug 806315. The resume with acpi=off is hack, it could have consequencies thus I didn't consider it for now. Please upload output of dmesg command (as attachement) and also output of dmidecode. Does your machine have multiple graphics cards (i.e. second card supplementary to integrated graphics)?
I tried to reproduce this. I don't have access to E6410, so I acquired machine with core i5 and e1000e, but I was unable to reproduce, everything worked as expected on f17. Please provide output of dmesg and dmidecode as requested in comment 11.
Created attachment 604651 [details] Output of dmesg at various stages during tests of switching between F17 and windows 7 Apologies for delay. As requested I attach output of dmesg (lightly annotated), though I forgot to add the previously suggested extra flags to grub.cfg. If necessary I can repeat the process with those flags, thought not immediately as I have visitors. This is a summary of the actions: Start from machine shut down completely, with kernel 3.5.1-1.fc17.i686 1 Boot F17 after running win7 then using win7 restart. run dmesg 2 Hibernate and resume with acpi=off run dmesg 3 Repeat hibernate and resume with acpi=off run dmesg 4 Hibernate, boot win7, restart from win7, resume linux with acpi=off run dmesg 5 Try to hibernate: fails run dmesg After that I had to shutdown because hibernate no longer worked. The output of each call of dmesg was included in the following outputs, so I've attached only the final long output (about 1375 lines), but broken into five sections, each of which starts with DMESG in upper case, so it is easy to find. Searching (caseless) for 'error' reveals the error reports. I hope this is of some use.
Thanks, your e1000e problem seems to be fixed in the current f17 kernel (it may not work correctly with the acpi=off, that's OK). I do not think there is a chance for the e1000e driver to be updated in this late f16 life cycle, thus if you are not against I would close this BZ. For the "resume from hibernation" problem I will continue commenting in bug 806315.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" 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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.