Description of problem: Occasionally, resume from suspend fails to wake up the screen. The LCD on my laptop seems to remain completely off. System log contains this line: localhost kernel: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22 The only way to move forward is to hold down the power button until the computer shuts off, then restart. Version-Release number of selected component (if applicable): xorg-x11-drv-intel.x86_64 2.99.917-28.20160929.fc26 @anaconda How reproducible: It happens occasionally, perhaps every 3-5 suspend/resume cycles. Steps to Reproduce: 1. Suspend system 2. Resume Actual results: Screen appears to be turned off; no display. Expected results: Seeing something on the screen. Additional info:
I have this happen to me on F27 whenever I use an HDMI external monitor. When I suspend (no matter if I've disconnected the external monitor or not) the laptop resumes but the LCD stays blank. Logging in via SSH shows the following line in the system log: kernel: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22 $ sudo yum list installed xorg-x11-drv-intel Installed Packages xorg-x11-drv-intel.x86_64 2.99.917-31.20171025.fc27 @updates This always seems to happen on the resume following the session where I use an external HDMI monitor. System is a Lenovo T460p with a dock. I've been suspending and resuming with this thing for months over a variety of kernels and Fedora's, so I don't think I've got weird hardware, but then again I'm not a graphics guy. I haven't tried to use Gnome, but will look at trying the same thing to see if it still occurs. I realize that the suspend/resume logic has changed over time but any suggestions regarding pre/post resume scripts are welcome. Happy to try debugging logic.
I use an external HDMI monitor nearly all of the time; it is quite possible that this bug only happens when the external HDMI monitor has been used. For me this happens after a few (typically 2-4) suspend/resume cycles; to the best of my recollection it does not happen on first suspend/resume. An additional piece of information is that that the available resolution for the monitor are sometimes (about 50% of the time) incorrectly detected/reported after the monitor has been disconnected and reconnected again. The first time I connect the monitor after a reboot the available resolutions are correct; subsequent times they are sometimes correct and sometimes incorrect. Disconnecting and reconnecting the monitor repeatedly eventually brings up the correct resolutions.
(In reply to Peter Langfelder from comment #2) > I use an external HDMI monitor nearly all of the time; it is quite possible > that this bug only happens when the external HDMI monitor has been used. Do you ever disconnect and use the builtin LCD? That's what I'm doing: plug in at work and use the big monitor, then suspend, go home, try to resume and no LCD graphics. No change in resolution (both monitor and LCD are set to 1920x1080. Laptop is up, but can't figure out what to whack the display driver with to reset it. Comes back when I reboot though :)
Yes, I do sometimes disconnect and use just the laptop LCD. I see pretty much the same symptoms as you, but the no screen state does not happen on every resume after using HDMI external monitor.
I just tried an old work-around and that seemed to bring my display back to life. I ssh'ed into the laptop after I opened the lid and it resumed. There was no graphics activity on the LCD. I then issued the command 'chvt 1' followed by 'chvt 2' which changed the virtual terminal from 2 (where XFCE seems to default) to 1 and back; doing so seemed to kick the display system back into gear and I was able to use the laptop display. I'm now experimenting with using the systemd sleep scripting facility to try this automatically, by changing to vt1 just prior to going to sleep and then changing back to vt2 after resume. Here's the contents of my /usr/lib/systemd/system-sleep/local.sh: #!/usr/bin/env bash # # script to change virtual terminals before and after a suspend/resume # to try and work around an i915 issue with multiple displays if [[ "$2" == "suspend" ]]; then if [[ "$1" == "pre" ]]; then t="pre" vt=1 fi if [[ "$1" == "post" ]]; then t="post" vt=2 fi logger "$t-suspend: switching to vt$vt" chvt $vt fi Not sure this will work, may have to change vt's more than once, but I'm happy that manually doing it brought the display back to life. Yeah, I realize it's just a work around but if I can get it going that will make my life easier. More on this tomorrow...
Yep, this works. When I opened the lid, there was a pause and then console output showed up, then it switched to vt2 and voila, there was my XFCE desktop. So, not a fix but a work-around.
This workaround does not work for me. The LCD does come back to life, but it also logs me out (perhaps because it restarts the X server?).
I'm encountering the same problem with 4.15 kernel on Dell XPS. I have external HDMI monitor connected through docking station and noticed that problem usually happen when I unplug docking station and resume. Any ideas how to tackle issue?
I can confirm this issue too with Arch Linux 4.15.13 on a Lenovo X1 Carbon 5th Gen. The following steps reproduce the problem for me: - connect the laptop to an external display (it does not matter which connection is used HDMI/Thunderbolt) - suspend the laptop - disconnect the external display - wake up from suspend - back in login screen Relevant error logs from journalctl: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22 Process 31076 (xfsettingsd) of user 1000 dumped core. Stack trace of thread 31076: #0 0x00007fec4c8f3fc2 n/a (libglib-2.0.so.0) #1 0x00007fec4c8f506d g_log_default_handler (libglib-2.0.so.0) #2 0x00007fec4c8f530f g_logv (libglib-2.0.so.0) #3 0x00007fec4c8f5490 g_log (libglib-2.0.so.0) #4 0x00005644b2bdce74 n/a (xfsettingsd) #5 0x00007fec4be9ff4a __libc_start_main (libc.so.6) #6 0x00005644b2bdd20a n/a (xfsettingsd)
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 EOL if it remains open with a Fedora 'version' of '26'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.