Hi, I'm reporting a bug as the Debian maintainer of the Xfce desktop environment. Since people have started to upgrade to future new stable version (Buster, currently testing) I have had multiple bug reports with a similar behavior. The locking infrastructure in Debian buster with Xfce relies on following components: - LightDM (the login screen manager) with its greeter, lightdm-gtk-greeter - light-locker: the lock screen light-locker works by drawing a simple window on top of the desktop on VT7 and locking it, then doing a vt-switch to a new lightdm on VT8. When entering the correct login/password on the login screen, a DBus message is sent to light-locker which unlocks the screen. Unfortunately, on setups with Intel adapters (of various generations, I personnaly reproduced on a ThinkPad X250 with Broadwell and Thinkpad X230 with Ivy Bridge) when the screen is then shut down (for power saving or because of a suspend), the screen doesn't turn back on when moving the mouse or entering keys. As far as I can tell the only way to bring back the screen is to manually switch VT (with ctrl-alt-Fx). There's a downtream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805711 but unfortunately there's a lot of noise so I'm a bit lost myself. There's an upstream bug report on Light Locker (https://github.com/the-cavalry/light-locker/issues/108) but it doesn't seem completely related. uname -m: x86_64 (but I guess i386 is affected as well) uname -r: 4.19.0-4-amd64 Linux Distribution: Debian testing/sid Machine: at least ThinkPads X230 and X250 for me but Debian bug report shows a lot more Display connector: LVDS, eDP, DP (and I guess HDMI, VGA...) - DDX is modesetting from Xorg core If you want more specific information please ask. I know the issue is weird. It's likely a bad interaction between various components (i915, DDX) and a not-often used codepath (vt-switch + DPMS maybe?)
> Unfortunately, on setups with Intel adapters (of various generations, I > personnaly reproduced on a ThinkPad X250 with Broadwell and Thinkpad X230 > with Ivy Bridge) when the screen is then shut down (for power saving or > because of a suspend), the screen doesn't turn back on when moving the mouse > or entering keys. > Have you tried to verify the issue with drmtip? Can you please attach the dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M?
I tried to build drm-tip but for some reason (most likely my configuration) the system doesn't boot at all (nothing happens after loading the ramdisk). I'll investigate that but it'll take a bit more time.
(In reply to Yves-Alexis from comment #2) > I tried to build drm-tip but for some reason (most likely my configuration) > the system doesn't boot at all (nothing happens after loading the ramdisk). > > I'll investigate that but it'll take a bit more time. I can confirm that the issues happens with drm-tip. I've taken dmesg logs with the parameters. I've only kept lines with drm: for clarity but I can provide the whole log if needed.
Created attachment 144587 [details] drm message at boot This is the dmesg from kernel startup to complete login on the desktop. Only line with drm: are shown
Created attachment 144588 [details] dmesg after locking This is dmesg output after locking the screen (using light-locker-command --lock). When that happens, light-locker locks the screen on vt7 and show a lightdm greeter on vt8. It also shuts the screen off, and it's impossible to wake it back unless one does a Ctrl-Alt-F1 then Alt-F8. Same thing happens when suspending/resuming or even locking after X screensaver activation.
Other data points: - it seems that it's really linked to the vt-switch and how it's handled by lightdm-gtk-greeter (https://github.com/the-cavalry/light-locker/issues/114#issuecomment-499392688) - it only happens with the 'modesetting' DDX, not with the intel one (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929834#66)
@ville, I there this message in dmesg. Any suggestion? [4.141545] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B FIFO underrun
Apart from error mentioned by Lakshmi in comment 7, I could see another one [drm:drm_dp_dual_mode_detect] DP dual mode HDMI ID: (err -6). This is coming many times.
@Yves-Alexis in reference to comment 6, is it confirmed that issue is with vt switch?
Also the error which i mentioned in comment 8, is not the real error. It is coming because during display probing, we call loop for all displays. And as HDMI is not connected, during that iteration we could not find edid and its failing.
(In reply to Jyoti Yadav from comment #9) > @Yves-Alexis in reference to comment 6, is it confirmed that issue is with > vt switch? I don't have a hard evidence, but it looks a bit related. Maybe there's something else going on but apparently other lockers don't have issue with backlight not going back up.
@Yves-Alexis, In dmesg logs, we could see [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B FIFO underrun error only just once. After that looks like display has recovered this underrun issue and this is seen when we are plugging DP display. Can you please explain this locking scenario? What is exactly you hotplugging in? And this blank screen persists?
(In reply to Jyoti Yadav from comment #12) > @Yves-Alexis, In dmesg logs, we could see > [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B FIFO underrun > > error only just once. After that looks like display has recovered this > underrun issue and this is seen when we are plugging DP display. > > Can you please explain this locking scenario? What is exactly you > hotplugging in? This is totally unrelated to hotplugging. It happens on a laptop with no attached screen. By “locking” I mean “locking the screen”, so I have to enter a password to gain access to my desktop. Is there something else confusing? > > And this blank screen persists? Until I manually do a vt-switch, yes. And a lot of people don't know about this workaround and desperately try to access their computer once locked (see the downstream bug reports).
There's nothing wrong in the dmesg; try checking Xorg.log.
Reporter, can you please attach the xorg.log?
Created attachment 144873 [details] Xorg log Probable relevant line: [ 980.751] (WW) modeset(0): hotplug event: connector 85's link-state is BAD, tried resetting the current mode. You may be leftwith a black screen if this fails... The blank screen issue comes up every time the laptop has been sleeping for a longer time (> 1 hour or so).
(In reply to silvio from comment #16) > Created attachment 144873 [details] > Xorg log > > Probable relevant line: > > [ 980.751] (WW) modeset(0): hotplug event: connector 85's link-state is > BAD, tried resetting the current mode. You may be leftwith a black screen if > this fails... > > The blank screen issue comes up every time the laptop has been sleeping for > a longer time (> 1 hour or so). (Clarification: I am not the original reporter but believe to have the same issue. Switching to a VT and back to X solves it).
I just want to confirm that according to Debian BTS lots of people are suffering from this issue (not only with Intel graphics but also AMD with free radeon driver). I can confirm that the issue exists here on two different laptops as well. Kind regards, Andreas.
I can reproduce this just by doing "xset dpms force off", but not always. First and foremost, the X server needs to be in a "weird" state. I don't know how to get into that state, but using my laptop for a few days (suspends, resumes, docking with two external monitors, undocking, etc.) always eventually gets it there. If I now switch to another virtual console and "startx", I can't reproduce it there, but if I logout again and switch back to the "weird" X that's been running for a few days, it's reproducible just fine. (Which makes me think this is an xorg-server issue, possibly modesetting driver, not kernel/drm.) Anyway, let's assume I'm in this "weird" X server: If neither compton (nor any other compositor) nor xss-lock (nor xscreensaver nor anything similar) is running, "xset dpms force off" makes the screen black (and turns off display backlight, as it should), and no amount of mouse movements and/or key presses brings it back on. VT switch helps. (BUT, if there was fullscreen glxgears or mpv, mouse/keys does bring the screen back on. Move it one pixel off, it won't, but if the GL app is exactly fullscreen, it works.) If compton is running, but the entire screen is occupied by a single window and therefore unredirected, it's the same as above: if it's a GL app, screen comes back on, if it's something boring like urxvt or xscreensaver or xsecurelock, it doesn't. If compton is running and there are multiple windows on the screen, everything works fine, screen comes back up after moving the mouse. That's expected at this point as compton is kind of like a fullscreen GL thing, right? If xss-lock is running and the screen is locked, regardless of whether compton is there or not (it'd have unredirected it anyway), "xset dpms force off" does make the screen black, but the display backlight stays on. (This seems unrelated, but it doesn't happen in a fresh non-weird X, so I'm attributing it to this weirdness as well.) If the screen is not locked, "xset dpms force off" locks it and displays the screen saver. In non-weird X, even unlocked "… off" results in black screen with no backlight.
I think i'm having the same/related issue on a lenovo flex10 with intel i915 running debian 10.1 kernel 4.19. With xscreensaver configured and xscreensaver daemon running (autostarted by xfce and no error message if xscreensaver-demo is opened) instead of the screensaver working as expected i get a blank screen after a time independent of xscreensaver settings and have to log back in from the command line after ctrl-f2 ctrl-f1. However with Xscreensaver daemon running and xscreensaver-demo running the screensaver works as expected rather than going to a blank screen and an input switches the display back to the active display as expected. And if i boot into the kernel from debian 9 the blank screen problem does not occur.
@Yves-Alexis, would you mind reproducing this issue with latest drmtip to see if there are any improvements?
(In reply to Lakshmi from comment #21) > @Yves-Alexis, would you mind reproducing this issue with latest drmtip to > see if there are any improvements? I'm testing drmtip (d88a66d195bc) and so far it looks better than before. I'd prefer testing a bit more though.
(In reply to Yves-Alexis from comment #22) > (In reply to Lakshmi from comment #21) > > @Yves-Alexis, would you mind reproducing this issue with latest drmtip to > > see if there are any improvements? > > I'm testing drmtip (d88a66d195bc) and so far it looks better than before. > I'd prefer testing a bit more though. Thanks for the feedback.
I can confirm that my problems are fixed as of 5.3.7, and I'm fairly certain it's due to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26b1d3b527e7bf3e24b814d617866ac5199ce68d, because when I rename the Xorg binary to tmp-Xorg, I can reproduce it again. I can reproduce it reliably using this sequence of events: 1. connect laptop to ThinkPad Ultra Dock 2. activate both external displays using xrandr 3. deactivate external displays again 4. suspend laptop 5. resume laptop 6. xset dpms force off
(In reply to Tomas Janousek from comment #24) > I can confirm that my problems are fixed as of 5.3.7, and I'm fairly certain > it's due to > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=26b1d3b527e7bf3e24b814d617866ac5199ce68d, because when I rename the Xorg > binary to tmp-Xorg, I can reproduce it again. > > I can reproduce it reliably using this sequence of events: > > 1. connect laptop to ThinkPad Ultra Dock > 2. activate both external displays using xrandr > 3. deactivate external displays again > 4. suspend laptop > 5. resume laptop > 6. xset dpms force off Thanks for the pointer. I'll test the Debian 5.3.0-1-amd64 (5.3.7-based) kernel and follow up in a few days.
(In reply to Yves-Alexis from comment #25) > Thanks for the pointer. I'll test the Debian 5.3.0-1-amd64 (5.3.7-based) > kernel and follow up in a few days. Possibly worth noting that you may alternatively cherry-pick https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 into xserver-xorg-core and test this without rebooting or even without quitting your main X. Nevermind though if "in a few days" is caused by general business. :-)
(In reply to Tomas Janousek from comment #26) > (In reply to Yves-Alexis from comment #25) > > Thanks for the pointer. I'll test the Debian 5.3.0-1-amd64 (5.3.7-based) > > kernel and follow up in a few days. > > Possibly worth noting that you may alternatively cherry-pick > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 into > xserver-xorg-core and test this without rebooting or even without quitting > your main X. Nevermind though if "in a few days" is caused by general > business. :-) I just rebooted in that kernel and: [ 66.479748] broken atomic modeset userspace detected, disabling atomic The “in a few days” was merely because I wasn't really able to trigger the problem reliably so I prefer to test it during a few days before reporting success or failure :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/309.
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.