Created attachment 135592 [details] journal for Linux v4.14.0-2 (Arch Linux kernel) Bug description: After a system sleep/resume (and sometimes after leaving the laptop idle, allowing DPMS to kick in?), the screen remains black. System environment: -- chipset: SKL (HD Graphics 530) -- system architecture: 64-bit -- xf86-video-intel: 1:2.99.917+800+g37a682aa-1 -- xserver: 1.19.5-1 -- mesa: 17.2.5-1 -- libdrm: 2.4.88-1 -- kernel: 4.14-2 (and also 4.13.10 and drm-tip v4.14-2225-gb4da24717364) -- Linux distribution: Arch Linux -- Machine or mobo model: Clevo P651RA laptop -- Display connector: eDP Reproducing steps: 1. Suspend system (via sleep button or "systemctl suspend") 2. Resume system by pressing the power button The issue occurs both from X and from the console (with no X running) and occurs both with and without nouveau. Additional info: The laptop has hybrid graphics ("Nvidia Optimus"), with Intel i7-6700HQ (using i915) + Nvidia GTX 965M (using nouveau). It has a mux which can be configured in BIOS to "Hybrid" or "Discrete", external connectors are wired to the Nvidia GPU. I had a workaround for this black screen since at least 4.11.6-1-ARCH, invoking this from "/usr/lib/systemd/system-sleep/fix-edp1-black-screen post suspend": echo detect > /sys/class/drm/card0-eDP-1/status Before I automated that, I used to trigger this from a KDE Plasma shortcut: xset dpms force off; xset dpms force on This worked until kernel 4.12.10, after an upgrade to 4.13.10 (and also 4.14), the above methods fail. With 4.14, I observe the following: 1. The initial boot works. 2. The first/second s/r cycle may survive. While the backlight is turned on, a flicker (with no picture) is visible and it takes 1-3 (?) seconds before the console (or SDDM lock screen with X) becomes visible. 3. Further sessions that fail result in a black screen (no flickering is visible at all even if the backlight is on). "xrandr" shows no modes associated with eDP1 (but reports it as "connected"). It seems that the black screen occurs in the next s/r cycle when /sys/class/drm/card0-eDP-1/modes is empty (with 4.14). Attached is a full journal with current drm-tip with the following events: 1. Boot to console (no Xorg), everything is OK 2. Suspend+resume, still OK 3. Suspend+resume, black screen. Attempts to "fix" this with "echo detect > /sys/class/drm/card0-eDP-1/status" have no effect. 4. Suspend+resume, still black screen. Writing "detect" still does not work. 5. Shutdown.
Comment on attachment 135592 [details] journal for Linux v4.14.0-2 (Arch Linux kernel) Oops... I did not meant to publish that log, that was a longer session where I tried a couple of things from my main installation with an external monitor connected. If possible, please remove it since it contains some private details.
Created attachment 135593 [details] journal for Linux v4.14-2225-gb4da24717364 (this is the log as described in the original description, it was executed in a separate installation with less interference)
Hello Peter, could you try https://bugs.freedesktop.org/show_bug.cgi?id=101991#c18? Thank you.
Created attachment 135875 [details] journal for Linux v4.14-2225-gb4da24717364 (drm-tip) + SKL DMC 1.27 Hi Elizabeth, (In reply to Elizabeth from comment #3) > Hello Peter, could you try > https://bugs.freedesktop.org/show_bug.cgi?id=101991#c18? Thank you. Updating firmware and applying the kernel patch makes no difference. Note that I do not get a GPU hang. In case of failure, I can see: [drm:intel_dp_start_link_train] [CONNECTOR:58:eDP-1] Link Training failed at link rate = 270000, lane count = 2 Could it be related?
After replacing the panel (I accidentallly cracked it), I could not reproduce the issue anymore with any of these kernels: 4.12.10-1 4.14.12-1 (Arch Linux kernel) v4.15-rc7-1656-gd8bf435a0cf9 (drm-tip, 2018y-01m-08d-09h-58m-24s) Marking as WORKSFORME (I still have the original panel in case more testing is desired).
Closing this now. Please re-open if occurs again.
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.