Created attachment 127644 [details] Kernel config file Hi there, Reporting bug as previously discussed at https://bugzilla.kernel.org/show_bug.cgi?id=177731, looks like 4.9 have a regression of screen suspend/resume issue. Suspending the laptop will "likely" not turn on the screen back (sometimes does, but is very rare). I had that problem also at 4.6 or 4.7 (I can't remember properly), but 4.8 was fine, suspending the device has no major problems. I'm using my same kernel configuration for both 4.8 and 4.9, and no problem detected there for 4.8 and failing for 4.9-rc1 4.9-rc2 and 4.9-rc3 I done some testing with pm_test and seems to fail under "device" test, freezer works fine. Also, I have a problem since 4.8 with PM screen power saving, tested with both Ubuntu 16.10 with kernel 4.8 and my Gentoo with kernel 4.8 and 4.9, the problem in specific is: PM turns off the screen after some minutes, then will never turn it back. This second issue is quite different than the suspend regression, but may worth to mention it. On 4.8 suspension works fine, but PM power saving with turn off the screen correctly and not turn it on. Works fine deactivating that PM option on both Gnome or Powerdevil (KDE). With 4.9 everything fails, suspension and PM screen saving. Please, any extra test you need from my side, please ask it to me and I can provide it to you.
Created attachment 127645 [details] lspci -vvv
Please add drm.debug=14 module parameter, and attach dmesg all the way from boot up to and including the failing suspend/resume cycle.
Created attachment 127780 [details] 1st debug - first suspend OK, all others failed I'm really sorry my delay of this. Attaching a full boot. - 1st suspend = Worked fine - 2nd suspend = Didn't suspended and screen goes black - 3rd-6th suspend try = Didn't worked with black screen - 7th suspend try = Got suspended and the screen still back. Had to shutdown.
Created attachment 127781 [details] 2nd debug - 1st suspension went black and never got back OK, now I have another full boot. 1st suspension: Suspension OK, but the screen went black and didn't went back 2nd suspension: Suspension OK, but screen still black. 3rd suspension: Suspension OK, but screen still black. Poweroff.
Still reproducible at 4.9-rc4
What's the status here? In case anyone wonders why I'm asking: I recently added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressions@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail thread for example).
Still reproducible at 4.9.0-rc5, working fine currently with 4.8.9
This still reproducible on Linux 4.9.0-rc6, tested with xf86-video-intel and modesetting I discovered a faster workaround for this, instead suspend and wake-up until the screen can "recover", I can do ctrl+F<x> to switch between X and Linux shell. That fixes faster the problem, but is a workaround after all. Please, if you need some extra information about this, I'm happy to lend it.
Still reproducible on rc7. There is some way I can help guys? I can't reproduce this issue with 4.8.12
Highest+Blocker as being regression w/o workaround.
I can confirm this still happening on 4.9 (final) and, since a couple of rc, the control+alt+fX trick doesn't work anymore, looks like DRM gets on a wrong state, and the only way to recover it, is restarting SDDM (in my case) on a blind way (ctrl+alt+fX, login, restart SDDM all with a black screen) As extra info, my laptop have 2 videocards, and I can change from intel+nvidia (muxless) to Nvidia dedicated. Using Nvidia dedicated I don't experience this behavior, this is only using intel one at front. With Nvidia activated or Nvidia deactivated (Nvidia blob+bbswitch or Nouveau vgaswitcheroo) the problem persists.
Created attachment 128573 [details] Dmesg from boot to fail Attaching a log with drm.debug=0x1e from boot, until sddm loads drm, then suspension, go back and screen never goes back, so I took a dmesg after resume with the screen black. My screen is eDP-1 as you can see at log
Created attachment 128574 [details] Dmesg from boot to fail, then restart drm This dmesg log is same as 128573, but I took a snapshot after I fixed the screen issue restarting X. Seems like restarting X it get fix my problem for now. Even all terminals are with black screen, I may assume because drm is rendering the monitor for all screens, and restarting X may communicate with drm module to restart
Using early KMS for Skylake with the firmware on initrd makes the same behaviour, but this time with the workaround back I mentioned before (back and forward between TTY and X)
Changing priority since actually being regression with workaround. Pablo, is comment 14 related to 4.9.X or 4.10.Y kernel?
Yes, I'm currently using 4.9.4, and randomly after suspension the screen starts black, I still need to use the workaround of moving from X to TTY, and TTY to X to make it work again.
removing also NEEDINFO status since information has been provided
I started experiencing the same issue since linux next-20170407 on Haswell. I already posted a comment to a similar bug which also happens on Skylake here: https://bugs.freedesktop.org/show_bug.cgi?id=100221#c8
Adding tag into "Whiteboard" field - ReadyForDev The bug still active *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
This is still a problem on 4.11.1, almost any suspend on ram will keep the screen to never turn on, unless I start executing xrandr on a terminal and will turn on
Created attachment 131523 [details] DMESG drm with 0x1e, suspend, wake, open terminal, xrandr, screen turns on Attaching a new log enabling the screen only with xrandr instead restarting drm. The following error always appears on Xorg.0.log at start time, not sure if related. [ 8859.247] (EE) [ 8859.247] (EE) Backtrace: [ 8859.248] (EE) 0: /usr/bin/X (xorg_backtrace+0x4e) [0x58cf3e] [ 8859.248] (EE) 1: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f93f8f16000+0x1733ad) [0x7f93f90893ad] [ 8859.248] (EE) 2: /usr/bin/X (0x400000+0x111f61) [0x511f61] [ 8859.248] (EE) 3: /usr/bin/X (0x400000+0x1139af) [0x5139af] [ 8859.248] (EE) 4: /usr/bin/X (0x400000+0x35f4b) [0x435f4b] [ 8859.248] (EE) 5: /usr/bin/X (0x400000+0x3a088) [0x43a088] [ 8859.248] (EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f93fd4ad2c0] [ 8859.248] (EE) 7: /usr/bin/X (_start+0x2a) [0x423faa] [ 8859.248] (EE) [ 8859.248] sna_present_queue_vblank:477 assertion 'msc - swap->msc < 1ull<<31' failed
Hi Pablo, we have tested on our side with the latest drm-tip and we are not able to reproduce it. Can you also try using drm-tip and if the problem persist on your end attach updated logs, also change the status to REOPENED. If the behavior on your end is no longer reproducible please change the bug to RESOLVED.
Question, how are you doing the tests? I'm under 4.12.1, and is quite easy to reproduce this issue under xf86-video-intel, but very randomly fails under modesetting, and still quite easy to fix the problem with the mentioned workaround.
Created attachment 132784 [details] DMESG debug.drm 4.12.1 Attaching a new debug log under xf86-video-intel w/intel-virtual-output. On this test, 1st suspend didn't show anything on screen, 2nd suspend neither and I had to make Xorg crash to make it work (playing with intel-virtual-output under bug 101324)
Hello Pablo, any news with latest tip? Maybe not helpful but have you tried with PM-utils?
Hi Elizabeth I just tried with 4.14-rc7 and still same problem. There is some way I can help you to provide more useful info?
(In reply to Pablo Cholaky from comment #26) > Hi Elizabeth > > I just tried with 4.14-rc7 and still same problem. There is some way I can > help you to provide more useful info? Hello Pablo, a bisection to identify culprit commit definitively could help. Also some test with PM-utils tool may or not show a difference.
[ 12.515534] [drm] Finished loading i915/skl_dmc_ver1_26.bin (v1.26)
(In reply to Pablo Cholaky from comment #26) > Hi Elizabeth > > I just tried with 4.14-rc7 and still same problem. There is some way I can > help you to provide more useful info? Hi Pablo, looks like link training failure on eDP: [16864.962219] [drm:intel_dp_start_link_train [i915]] Clock recovery check failed, cannot continue channel equalization Could you try the drm-tip branch from git://anongit.freedesktop.org/drm-tip (booting again with drm.debug=0x1e) and attach the dmesg log? Please also keep the bootup messages in the log and also include the messages after you managed to recover the display (by running xrandr or whatever was needed). Thanks.
HI, No feedback if this still issue. Please re-open if still valid with latest drm-tip as proposed by Imre.
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.