Every now and then, when I wake up my laptop from suspend, the display stays black. This seems happen when I start out working on an external screen (so the laptop screen is disabled), then suspend the machine and unplug the external screen (pretty much at the same time, I can't which happened first). Using Ctrl-Alt-F<N> to switch to other terminals still works, but Ctrl-Alt-F7 always brings up just a black screen. I tried debugging this further, but did not get very far. The logs (dmesg, journalctl, Xorg log) don't seem to contain anything useful, except for lots of kscreen output (attached). I tried to interact with the still-running X session by setting DISPLAY and XAUTHORITY in another terminal. "xrandr -q" showed my laptop screen, including all its resolutions, as being turned off. I tried to turn it on ("xrandr --auto"), which failed saying xrandr: Configure crtc 0 failed Again, I was unable to get any further details about this error from any logs. Needless to say, this is an extremely disruptive bug; I lose my entire session state of all running applications. I have no idea which product and component to assign this to, so I figured I'd start with the X server.
You will want to capture drm.debug=0xe dmesg from across suspend (including the failure). xrandr --verbose of before/after suspend will be useful, and please attach Xorg.0.log.
> You will want to capture drm.debug=0xe dmesg from across suspend (including the failure). So you're saying I should just have this debug flag set on my kernel cmdline all the time? How bad will that be in terms of degrading performance (this is my machine for productive work) and spamming the system logs? The actual failure happens fairly rarely.
(In reply to post+fdo from comment #2) > > You will want to capture drm.debug=0xe dmesg from across suspend (including the failure). > > So you're saying I should just have this debug flag set on my kernel cmdline > all the time? How bad will that be in terms of degrading performance (this > is my machine for productive work) and spamming the system logs? The actual > failure happens fairly rarely. Hello, This flag only adds information in the dmesg, it shouldn't affect any process nor the performance of your laptop. Could you please add more HW and SW information? It could be a related to this other bug https://bugs.freedesktop.org/show_bug.cgi?id=101865 Thanks.
> Could you please add more HW and SW information? Not sure what exactly you need. This is an Acer laptop, the CPU is "Intel(R) Core(TM) i7-6700HQ", and I am running Debian testing amd64. I have seen this issue with various kernel versions, including 4.10 and 4.11, and with Xorg 1.19.?.
Hello again, any luck getting a log with debug information Comment #1??
Sorry, I am not using that laptop any more.
(In reply to post+fdo from comment #6) > Sorry, I am not using that laptop any more. Understood. Thank you for the time invested, if someone else can replicate with same HW please reopen. Meanwhile, similar bug 100924 was open with an APL platform, follow there. Thank you. *** This bug has been marked as a duplicate of bug 100924 ***
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.