Created attachment 129323 [details] s4 dmesg log ======Description====================== DUT hangs after coming back from Hibernate in fedora 25 64 bits, display goes black and system is frozen. ====== Steps to Reproduce ============= 1. Install fedora 25 on BDW platform from https://getfedora.org/workstation/download 2.Since suspend to disk is not enabled by default, need to add a "resume" parameter in Grub as described in fedora forum: https://ask.fedoraproject.org/en/question/96389/fedora-24-how-to-enable-hibernate/ 3. after Adding parameters and updating grub, do a suspend to disk: #echo disk > /sys/power/state 4. Turn Device back on. Expected behavior: Machine resumes and show's previous state. Actual behavior: Machine resumes, starts showing previous state, but after a couple of seconds display goes black and machine is frozen. ===========Hardware information ==================== Processor Model Family : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz Core Memory : 5881 MB GPU Card & Driver : Intel Corporation HD Graphics 5500 (rev 09), i915 BIOS & Firmware Version : 1.69, B0CN69WW Platform Manufacturer & Type : LENOVO, Notebook Motherboard Model & Type : 80E5, Motherboard ================== Software information ================= Kernel : 4.8.0-22-generic Architecture : 64 bits Mesa : 13.0.2 xorg-xserver : 1.18.4 vaapi (inteldriver) : 1.7.3 cairo : 1.15.2-0intel1 intel-gpu-tools : 1.17-1 ====Attachments ===== dmesg.log, using drm.debug=0xe
Found this issue during 2016Q4 Update tool test execution, however this is also reproducible on a fresh Fedora 25 OS, also was able to reproduce this issue on two different platforms.
The dmesg attached doesn't contain the actual suspend/resume sequence. Could you try capturing it right after resume: # echo disk > /sys/power/state; dmesg > dmesg.log; sync Also could you try if the problem also happens by booting with nomodeset? Also trying with the latest drm-tip would be useful providing the same log. Thanks.
Humberto can you please help us to retest this scenario... Make sure if the problem continues attach logs and mark as REOPENED. if the issue is not present, please CLOSE the bug
with nomodeset the BDW on Fedora 25 does not enter to X, it shows the following messsage "HSW/BDW HD-audio HDMI/DP requieres binding with gfx driver"
looks like that after try to come back from S4 the system restart, for that reason does not works the following command # echo disk > /sys/power/state; dmesg > dmesg.log; sync the dmesg attached is after to come back from S4
Created attachment 132779 [details] dmesg.log
(In reply to Humberto Israel Perez Rodriguez from comment #4) > with nomodeset the BDW on Fedora 25 does not enter to X, it shows the > following messsage "HSW/BDW HD-audio HDMI/DP requieres binding with gfx > driver" Yes, but can you do a successful hibernate/resume cycle in this case?
(In reply to Humberto Israel Perez Rodriguez from comment #5) > looks like that after try to come back from S4 the system restart, for that > reason does not works the following command > > # echo disk > /sys/power/state; dmesg > dmesg.log; sync > > the dmesg attached is after to come back from S4 > (In reply to Humberto Israel Perez Rodriguez from comment #6) > Created attachment 132779 [details] > dmesg.log Yes, this new dmesg is again from a normal kernel boot, so not from the resumed kernel. We'd need to get the log from the resumed kernel to progress in this, so could you try to get it with one of the following methods: - serial console - netconsole - pstore (CC'd Marta and Tomi to help set it up)
I tried to reproduce this issue, but when the platform try to come back from S4 the system go to restart. Adding dmesg after to come back from S4 I used this configuration ====================================== Software ====================================== kernel version : 4.11.11-300.fc26.x86_64 hostname : localhost.localdomain architecture : x86_64 [sudo] password for gfx: kernel driver : i915 bios revision : 5.6 bios release date : 05/11/2017 hardware acceleration : disabled swap partition : enabled on (/dev/dm-1) ====================================== Graphic drivers ====================================== mesa : 17.1.5 ====================================== Hardware ====================================== platform : Broadwell motherboard id : NUC5i7RYB form factor : Desktop cpu family : Core i7 cpu family id : 6 cpu information : Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz gpu card : Intel Corporation Iris Graphics 6100 (rev 09) (prog-if 00 [VGA controller]) memory ram : 15.56 GB max memory ram : 16 GB display resolution : 1920x1080 cpu thread : 4 cpu core : 2 cpu model : 61 cpu stepping : 4 socket : Socket BGA1168 signature : Type 0, Family 6, Model 61, Stepping 4 current cd clock frequency : 337500 kHz maximum cd clock frequency : 540000 kHz displays connected : DP-1
Created attachment 133498 [details] dmesg.log
(In reply to Imre Deak from comment #7) > (In reply to Humberto Israel Perez Rodriguez from comment #4) > > with nomodeset the BDW on Fedora 25 does not enter to X, it shows the > > following messsage "HSW/BDW HD-audio HDMI/DP requieres binding with gfx > > driver" > > Yes, but can you do a successful hibernate/resume cycle in this case? Hi Imre, we are not able to resume on Fedora as Humberto said in the https://bugs.freedesktop.org/show_bug.cgi?id=99669#c5 for that reason the kernel log and dmesg does not contains any useful information regarding resuming
(In reply to Imre Deak from comment #8) > (In reply to Humberto Israel Perez Rodriguez from comment #5) > > looks like that after try to come back from S4 the system restart, for that > > reason does not works the following command > > > > # echo disk > /sys/power/state; dmesg > dmesg.log; sync > > > > the dmesg attached is after to come back from S4 > > > (In reply to Humberto Israel Perez Rodriguez from comment #6) > > Created attachment 132779 [details] > > dmesg.log > > Yes, this new dmesg is again from a normal kernel boot, so not from the > resumed kernel. We'd need to get the log from the resumed kernel to progress > in this, so could you try to get it with one of the following methods: > > - serial console > - netconsole > - pstore (CC'd Marta and Tomi to help set it up) Hi Imre, as i've commented in my last comment, due to we are not able to resume i am afraid that this steps cannot be completed
(In reply to Elizabeth from comment #11) > (In reply to Imre Deak from comment #7) > > (In reply to Humberto Israel Perez Rodriguez from comment #4) > > > with nomodeset the BDW on Fedora 25 does not enter to X, it shows the > > > following messsage "HSW/BDW HD-audio HDMI/DP requieres binding with gfx > > > driver" > > > > Yes, but can you do a successful hibernate/resume cycle in this case? > > Hi Imre, we are not able to resume on Fedora as Humberto said in the > https://bugs.freedesktop.org/show_bug.cgi?id=99669#c5 for that reason the > kernel log and dmesg does not contains any useful information regarding > resuming Hi, comment 5 was about booting _without_ the nomodeset option. I wanted to know what happens if you boot _with_ nomodeset and try to do #echo disk > /sys/power/state and resume. It doesn't matter if the graphics functionality is reduced (that is Fedora does not enter X as Humberto wrote above) you can issue the above command from any text or ssh terminal. I just want to know if the problem persists or not by disabling the graphics driver.
(In reply to Elizabeth from comment #12) > (In reply to Imre Deak from comment #8) > > (In reply to Humberto Israel Perez Rodriguez from comment #5) > > > looks like that after try to come back from S4 the system restart, for that > > > reason does not works the following command > > > > > > # echo disk > /sys/power/state; dmesg > dmesg.log; sync > > > > > > the dmesg attached is after to come back from S4 > > > > > (In reply to Humberto Israel Perez Rodriguez from comment #6) > > > Created attachment 132779 [details] > > > dmesg.log > > > > Yes, this new dmesg is again from a normal kernel boot, so not from the > > resumed kernel. We'd need to get the log from the resumed kernel to progress > > in this, so could you try to get it with one of the following methods: > > > > - serial console > > - netconsole > > - pstore (CC'd Marta and Tomi to help set it up) > > Hi Imre, as i've commented in my last comment, due to we are not able to > resume i am afraid that this steps cannot be completed The above 3 methods are exactly for cases where you cannot resume. serial and net console may give you usable log before the machine freezes, pstore could provide a log after the machine freezes and you rebooted the machine.
Hello again, I tried this with Fedora 27 and latest mainline 4.16.0-rc7. I followed the steps in comment #1. The hang doesn't occur in when the machine turns on again, but the resume from hibernation fails: When # echo disk > /sys/power/state [Mar28 14:11] PM: hibernation entry [ +0.001937] PM: Syncing filesystems ... [ +0.024215] PM: done. After power on: [ 1.782484] PM: Using 3 thread(s) for decompression [ 1.782486] PM: Loading and decompressing image data (791432 pages)... [ 1.782504] Hibernate inconsistent memory map detected! [ 1.782553] PM: Image mismatch: architecture specific data [ 1.782599] PM: Read 3165728 kbytes in 0.01 seconds (316572.80 MB/s) [ 1.784687] PM: Error -1 resuming [ 1.784751] PM: Failed to load hibernation image, recovering. [ 1.785016] PM: Basic memory bitmaps freed Disk: Device Start End Sectors Size Type /dev/sda1 2048 411647 409600 200M EFI System /dev/sda2 411648 2508799 2097152 1G Linux filesystem /dev/sda3 2508800 19286015 16777216 8G Linux swap /dev/sda4 19286016 351651839 332365824 158.5G Linux LVM $ cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT="4.16.0-rc7" #GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rhgb quiet resume=/dev/sda3" GRUB_DISABLE_RECOVERY="true" $ uname -a Linux localhost.localdomain 4.16.0-rc7 #1 SMP Wed Mar 28 13:09:23 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux Should I close this bug an open a new one for this issue?
Created attachment 138398 [details] hibernate_log_boot First booted and copied dmesg, then dmesg -C and run the echo disk command: [Mar28 14:11] PM: hibernation entry [ +0.001937] PM: Syncing filesystems ... [ +0.024215] PM: done.
Created attachment 138399 [details] hibernate_log_resume And the dmesg after the power on button.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
(In reply to Elizabeth from comment #15) > Hello again, I tried this with Fedora 27 and latest mainline 4.16.0-rc7. I > followed the steps in comment #1. > > The hang doesn't occur in when the machine turns on again, but the resume > from hibernation fails: > > When # echo disk > /sys/power/state > > [Mar28 14:11] PM: hibernation entry > [ +0.001937] PM: Syncing filesystems ... > [ +0.024215] PM: done. > > After power on: > > [ 1.782484] PM: Using 3 thread(s) for decompression > [ 1.782486] PM: Loading and decompressing image data (791432 pages)... > [ 1.782504] Hibernate inconsistent memory map detected! > [ 1.782553] PM: Image mismatch: architecture specific data Looks like hibernation image corruption. Does this happen always? Does it happen when booting with the following kernel parameters: modprobe.blacklist="snd_hda_intel,i915" 3
Created attachment 138500 [details] hibernate_log_resume-no_1915 (In reply to Imre Deak from comment #19) > (In reply to Elizabeth from comment #15) > > ... > Looks like hibernation image corruption. > > Does this happen always? I tried 4 times, yes it does. > Does it happen when booting with the following kernel parameters: > > modprobe.blacklist="snd_hda_intel,i915" 3 I tried 5 times. It failed the first time, but couldn't reproduce; the four after worked fine.
*** Bug 102305 has been marked as a duplicate of this bug. ***
Closing, please re-open if still occurs.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.