Bug 1180380 - Blank external monitor after resume from suspend
Blank external monitor after resume from suspend
Status: NEW
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.3
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-12-27 11:14 UTC by Jan Kara
Modified: 2022-02-21 10:10 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jack: needinfo? (jack)


Attachments
dmesg from the system (128.31 KB, text/plain)
2020-12-27 11:14 UTC, Jan Kara
Details
Xorg.log from the machine (31.78 KB, text/x-log)
2020-12-27 11:14 UTC, Jan Kara
Details
dmesg with drm.debug=1 (19.76 KB, application/gzip)
2021-01-04 09:47 UTC, Jan Kara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kara 2020-12-27 11:14:06 UTC
Created attachment 844706 [details]
dmesg from the system

After resuming from suspend to RAM the external display connected through DVI port on the docking station remains blank. Internal display is fine. I can use xrandr to make the monitor work like:

xrandr --output DP1-1 --mode some-other-mode
xrandr --output DP1-1 --mode original-mode
Comment 1 Jan Kara 2020-12-27 11:14:35 UTC
Created attachment 844707 [details]
Xorg.log from the machine
Comment 2 Jan Kara 2020-12-27 11:18:32 UTC
The xorg log looks like everything is fine. The kernel i915 driver shows on resume:

[  312.487879] [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

which may be related to the problem...

BTW, this is DELL Latitude E7250 laptop. The problem started happening after updating from Leap 15.0 to Leap 15.2.
Comment 3 Takashi Iwai 2020-12-28 10:25:40 UTC
Could you give the dmesg output with drm.debug=0x0e option (you can set dynamically via /sys/module/drm/parameters/debug) around suspend/resume?

Also, is this a regression during Leap 15.2 release?

And, just to be sure, could you check either SLE15-SP3 kernel-default?
Comment 4 Jan Kara 2021-01-04 09:47:00 UTC
Created attachment 844794 [details]
dmesg with drm.debug=1
Comment 5 Jan Kara 2021-01-04 09:47:30 UTC
(In reply to Jan Kara from comment #4)
> Created attachment 844794 [details]
> dmesg with drm.debug=1

Sorry with drm.debug=0x0e...
Comment 6 Jan Kara 2021-01-04 09:49:53 UTC
(In reply to Takashi Iwai from comment #3)
> Also, is this a regression during Leap 15.2 release?

Well, I know 15.0 (with 4.12-based kernel) worked fine. I'm not sure about 15.1. I didn't have it installed on this machine. I can try booting just the kernel from 15.1 if needed.

> And, just to be sure, could you check either SLE15-SP3 kernel-default?

OK, I'll install a kernel from SLE15-SP3 and will let you know.
Comment 7 Takashi Iwai 2021-01-05 12:04:31 UTC
It turned out that SLE15-SP3 kernel contains a 5.11 upstream patch that caused a regression for Intel HDMI, so you might hit another problem with it.  Please avoid testing SLE15-SP3 kernel as of now.
Comment 8 Jan Kara 2021-01-05 14:50:57 UTC
(In reply to Takashi Iwai from comment #7)
> It turned out that SLE15-SP3 kernel contains a 5.11 upstream patch that
> caused a regression for Intel HDMI, so you might hit another problem with
> it.  Please avoid testing SLE15-SP3 kernel as of now.

OK, thanks for info.
Comment 9 Russell Sandish 2021-01-10 23:49:15 UTC
I've got this problem with OpenSUSE Tumbleweed after a recent dup. Version 20210107 fails to resume correctly after a suspend (monitor is blank, but can log in via ssh). Works correctly with version 20201209.

For some reason, the Windows system seems to have switch to Gnome - this may be the problem:

Was:

zen>ps -ef|grep dm
root       611     1  0 Jan06 ?        00:00:00 /usr/sbin/rpc.idmapd
root      1455     1  0 Jan06 ?        00:00:00 /usr/bin/sddm
root      1457  1455  0 Jan06 tty7     00:49:27 /usr/bin/Xorg.bin -nolisten tcp -auth /run/sddm/{165cb406-6b48-4b18-8d01-486816598429} -background none -noreset -displayfd 17 -seat seat0 vt7
root      1685  1455  0 Jan06 ?        00:00:00 /usr/libexec/sddm/sddm-helper --socket /tmp/sddm-authd9cad494-ec18-4ba3-9777-b649684f65d4 --id 1 --start fvwm --user rks

Now:

rusnuc>ps -ef|grep dm
root       820     1  0 10:42 ?        00:00:00 /usr/sbin/gdm
root      2907   820  0 10:43 ?        00:00:00 gdm-session-worker [pam/gdm-password]
rks       2927  2907  0 10:43 tty2     00:00:00 /usr/libexec/gdm/gdm-x-session --register-session --run-script fvwm
rks       2929  2927  0 10:43 tty2     00:00:00 /usr/bin/Xorg.bin vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3

When I get a spare day or so, I might try a complete reinstall from scratch, and make sure that KDM is selected as my windowing system (I actually use neither KDM or Gnome, but usually selected KDM as it was the default in the past).
Comment 10 Russell Sandish 2021-01-10 23:52:42 UTC
Oh, and BTW - I think I've had this problem with OpenSUSE Leap since way back. My one  Leap machine I have here I always do a full reboot, never suspend and resume, since it doesn't work. I always assumed it was an ACPI issue, that would be fixed when migrating to newer hardware.
Comment 11 Russell Sandish 2021-01-11 22:37:51 UTC
What is worse is that when the screensaver turns off the monitor after a period of inactivity, it is impossible to resume the monitor. There appears to be nothing to do but reboot the computer at this point.

After doing a clean install, the problem still remains. I haven't checked the suspend/resume is similarly affected as yet, but presumably so. I'll report back later if different.

The workaround is to disable the Energy saver mode under power settings, and to not use suspend. But this is a major showstopper bug, and I will not upgrade my laptop until this is sorted.

On the plus side, it does look like last year's wicked bug (https://bugzilla.opensuse.org/show_bug.cgi?id=1157394) has now been fixed.
Comment 12 Russell Sandish 2021-01-13 02:44:57 UTC
After the clean install of Tumbleweed with KDE desktop, suspend/resume is working correctly. However, I do need to disable "Screen Energy Saving" under "Power Management" (KDE Settings), to prevent the computer from going to sleep and not waking up.
Comment 13 Takashi Iwai 2021-01-18 15:04:40 UTC
Russell, your problem might be different from the original issue.  The only same thing is that it's Intel and the screen goes blank, but in Jan's case, the screen can be recovered simply via xrandr.  Better to open another bug report for avoiding the mix up.
Comment 14 Jan Kara 2021-02-03 11:00:34 UTC
BTW this seems to be some kind of a race because it doesn't happen in 100% of cases. In about 10% of cases the external monitor works just fine after resume. Also it has happened to me already twice over several weeks, that the external monitor didn't come up even after xrandr off - on cycle and I had to reboot the machine.
Comment 15 Miroslav Beneš 2022-02-11 12:18:09 UTC
Jan, is there anything new? There is Leap 15.3 now which may work better.
Comment 16 Jan Kara 2022-02-21 10:10:02 UTC
Good question. I have a new laptop now and the old one still has 15.2 installed. I will update it to 15.3 and try it with the external monitor.