Bug 91974 - [BDW][bisected] unrecoverable black screen after killing X
Summary: [BDW][bisected] unrecoverable black screen after killing X
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2015-09-11 09:33 UTC by Khumba
Modified: 2017-11-06 17:46 UTC (History)
5 users (show)

See Also:
i915 platform: BDW
i915 features: display/Other


Attachments
dmesg after killing X (73.30 KB, text/plain)
2015-09-11 09:33 UTC, Khumba
no flags Details
X log after killing X (28.04 KB, text/plain)
2015-09-11 09:34 UTC, Khumba
no flags Details
xrandr from a working session and good commit (746 bytes, text/plain)
2015-09-11 09:34 UTC, Khumba
no flags Details
X server config, NixOS generated (4.87 KB, text/plain)
2015-09-11 09:35 UTC, Khumba
no flags Details
lspci -knnvvv (33.84 KB, text/plain)
2015-09-11 09:35 UTC, Khumba
no flags Details
xrandr --verbose after restarting X (5.28 KB, text/plain)
2015-09-11 10:20 UTC, Khumba
no flags Details
xf86-video-intel-2016-05-07.gentoo.build.log (315.00 KB, text/plain)
2016-05-21 02:18 UTC, Khumba
no flags Details
xf86-video-intel-2016-05-19.nixos.build.log (60.97 KB, text/plain)
2016-05-21 02:19 UTC, Khumba
no flags Details

Description Khumba 2015-09-11 09:33:35 UTC
Created attachment 118208 [details]
dmesg after killing X

7d9a746 - (refs/bisect/bad) sna: Be robust in handling DPMS failures (3 months ago) <Chris Wilson>

This commit starts causing problems with my laptop's Intel card.  If I close an X session by letting xinitrc finish, then I'm returned to the login screen without problem.  If I kill the X process or stop it via systemctl, then my laptop display turns off and won't turn back on short of a reboot: starting X again, and closing the lid, don't help.  (I didn't try suspending.)

The laptop's built-in display is seen as eDP1.  If there are other displays attached via HDMI or DP, they continue functioning normally, in console mode and X.  I don't see anything out of the ordinary in the logs.

Machine:

$ uname -a
Linux mikasa 3.18.21 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux

- X Server version 1.17.2

- ASUS N550JK with dual Intel and NVIDIA graphics (only Intel active).

- The xrandr output is from a normally functioning session (from the commit prior to this bad one).
Comment 1 Khumba 2015-09-11 09:34:18 UTC
Created attachment 118209 [details]
X log after killing X
Comment 2 Khumba 2015-09-11 09:34:42 UTC
Created attachment 118210 [details]
xrandr from a working session and good commit
Comment 3 Khumba 2015-09-11 09:35:06 UTC
Created attachment 118211 [details]
X server config, NixOS generated
Comment 4 Khumba 2015-09-11 09:35:18 UTC
Created attachment 118212 [details]
lspci -knnvvv
Comment 5 Chris Wilson 2015-09-11 09:43:46 UTC
What does xrandr say when the screen is black? Just sounds like nothing chooses to enable the eDP1 as it is off by user action.
Comment 6 Khumba 2015-09-11 10:20:04 UTC
Created attachment 118213 [details]
xrandr --verbose after restarting X

As far as I can see, xrandr thinks things are fine.  Input devices function.  /sys/class/backlight/intel_backlight shows full brightness.  The built-in display is just off for some reason.  (Note that the display is dead even if I don't restart X.)
Comment 7 Chris Wilson 2015-09-11 10:22:26 UTC
Ok, not a configuration issue
Comment 8 Khumba 2015-09-11 10:30:12 UTC
Suspending to RAM and resuming brings the display back to life.

I know little about the graphics stack, so please let me know if you want me to try things or what additional info to provide; I don't know, myself.

Downstream bug is here, by the way: https://github.com/NixOS/nixpkgs/issues/9755
Comment 9 Khumba 2015-09-11 17:13:46 UTC
Things I forgot to mention in the middle of the night:

- I tested upgrading to a 4.1 kernel together with xf86-video-intel at commit a29e765 (what NixOS is shipping) and the problem was present.

- I tested with my current 3.18.21 kernel at xf86-video-intel master, also bad.
Comment 10 Jan Horak 2015-10-14 10:55:29 UTC
I've got same issue on my Lenovo X250:

lspci
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)

uname -a
Linux honzik-ntb 4.2.2-040202-generic #201509291435 SMP Tue Sep 29 18:37:34 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Kubuntu 15.04 - Plasma5
ssdm version: 0.11.0-0ubuntu10

When the error shows in dmesg computer goes to sleep everytime.
Comment 11 Jani Nikula 2016-04-25 09:18:36 UTC
Still an issue with latest kernels and userspace?
Comment 12 Khumba 2016-04-26 07:36:14 UTC
I need to test again with latest versions.  Back in March (see the NixOS bug) I tried with a newer xf86-video-intel on Gentoo and couldn't repro, but then I never did repro on Gentoo.

I'm on holiday and without this particular box until mid-May, so further testing from me will have to wait until then.
Comment 13 Khumba 2016-05-21 02:17:26 UTC
Okay, I did a fresh round of testing, here are the results.  While it still is an issue with latest versions on NixOS, I haven't been able to repro on Gentoo.  The NixOS build of xf86-video-intel uses the default configure flags, whereas Gentoo specifies them via USE flags, so I mention what's being used below.  I'll also upload the build logs of (4) and (5).

(1) gentoo arch=amd64 sm=openrc kernel=4.4.6-gentoo xorg-server=1.17.4 xf86-video-intel=2.99.917-r2(date=2014-12-21)
  (USE="dri sna udev -debug -uxa -xvmc"; the defaults)
  kill X: works

(2) nixos head=6e0dddf(release-16.03) sm=systemd kernel=4.4.10 xorg-server=1.17.4 xf86-video-intel=2015-11-14(rev=0340718)
  kill X: broken

(3) nixos *head=06aae7c(master)+changes* sm=systemd *kernel=4.6* xorg-server=1.17.4 xf86-video-intel=2015-11-14(rev=0340718)
  kill X: broken

(4) nixos head=06aae7c(master)+changes sm=systemd kernel=4.6 xorg-server=1.17.4 *xf86-video-intel=2016-05-19(rev=25d2c2d)*
  kill X: broken

...okay, back to Gentoo to try to repro there...

(5) gentoo arch=amd64 sm=openrc kernel=4.4.6-gentoo xorg-server=1.17.4 *xf86-video-intel=2016-05-07(rev=88733a7)*
  (USE="dri sna udev -debug -dri3 -uxa -xvmc")
  (Note: Gentoo enables dri3 by default, but the ebuild says that dri3
   depends on xorg-server-1.18, so to avoid upgrading I disabled it.)
  kill X: works
Comment 14 Khumba 2016-05-21 02:18:59 UTC
Created attachment 123951 [details]
xf86-video-intel-2016-05-07.gentoo.build.log
Comment 15 Khumba 2016-05-21 02:19:25 UTC
Created attachment 123952 [details]
xf86-video-intel-2016-05-19.nixos.build.log
Comment 16 Jari Tahvanainen 2017-02-13 07:43:32 UTC
Khumba (freedesktop-bugs-79382@khumba.net) and Jan (horacius@gmail.com), are you still seeing this problem with latest kernel and userspace? Based on the comment 13 this failure was visible on NixOS, not in gentoo anymore. Chris (chris@chris-wilson.co.uk), is there something out there which could have impacted this?
Comment 17 Jari Tahvanainen 2017-02-17 07:50:12 UTC
During chat with Chris: "X has turned the eDP on, the kernel hasn't. As far X is concerned, it has performed a modeset on eDP to 1366x768 but the screen is still blank." -Chris
Comment 18 Elizabeth 2017-11-03 22:59:59 UTC
(In reply to Jari Tahvanainen from comment #16)
> Khumba (freedesktop-bugs-79382@khumba.net) and Jan (horacius@gmail.com), are
> you still seeing this problem with latest kernel and userspace? Based on the
> comment 13 this failure was visible on NixOS, not in gentoo anymore. Chris
> (chris@chris-wilson.co.uk), is there something out there which could have
> impacted this?
Hello everybody, could this case be closed? Actual NixOs is 17.09 and latest stable is kernel 4.13.11, still reproducible with it?
Comment 19 Khumba 2017-11-05 17:40:16 UTC
I only ever saw this problem on NixOS, which I haven't been running on this laptop for quite a while now, so feel free to consider this resolved.
Comment 20 Elizabeth 2017-11-06 16:21:07 UTC
Thanks for the update Khumba. Closing.


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.