You are not logged in.
I suppose that when only one out of three external displays goes Black Screen
The idea is that DPMS triggers this, not that it is DPMS.
Please don't rely on any tools/settings, block the extension entirely.
Whatever you configure cannot be fully trusted since eg. "xset dpms force off" can always explicitly enter DPMS from soewhere.
Check
xdpyinfo | grep -i dpms
On a formal note: please don't bump/blog. Edit your previous post to mend it if nobody has yet replied.
Online
I suppose that when only one out of three external displays goes Black Screen
The idea is that DPMS triggers this, not that it is DPMS.
Please don't rely on any tools/settings, block the extension entirely.
Whatever you configure cannot be fully trusted since eg. "xset dpms force off" can always explicitly enter DPMS from soewhere.
Checkxdpyinfo | grep -i dpms
On a formal note: please don't bump/blog. Edit your previous post to mend it if nobody has yet replied.
OK, I shall keep this in mind at all times from now on.
[pswiatki@sdr-aptv Video_EDID]$ xdpyinfo | grep -i dpms
DPMS
Aha! So, extension is active. I shall proceed to the complete removal of this extension as explained earlier. Will report when results emerge.
Offline
OK, DPMS extension removal affected the system so greatly, it could not function properly any more.
Here's the journal from that situation: https://0x0.st/KAqL.txt
[root@sdr-aptv log]# journalctl -b -2 | grep "kernel.*ERROR"
Sep 21 19:11:32 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for ACT sent
Sep 21 19:11:42 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] flip_done timed out
Sep 21 19:11:52 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:11:52 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] commit wait timed out
Sep 21 19:12:02 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] flip_done timed out
Sep 21 19:12:02 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] DSB 0 timed out waiting for idle (current head=0x40, head=0x0, tail=0x80)
Sep 21 19:12:13 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:12:13 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] commit wait timed out
Sep 21 19:12:37 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] flip_done timed out
Sep 21 19:12:37 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] DSB 1 timed out waiting for idle (current head=0xff791000, head=0x0, tail=0x1040)
Sep 21 19:12:52 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:12:52 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] commit wait timed out
Sep 21 19:13:02 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] flip_done timed out
Sep 21 19:13:02 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] DSB 1 timed out waiting for idle (current head=0xff791000, head=0x0, tail=0x1040)
Sep 21 19:13:19 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:13:19 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] commit wait timed out
Sep 21 19:13:29 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] flip_done timed out
Sep 21 19:13:29 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] DSB 1 timed out waiting for idle (current head=0xff78d000, head=0x0, tail=0x1040)
Sep 21 19:13:43 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:13:43 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:339:pipe D] commit wait timed out
Sep 21 19:13:54 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:13:54 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:382:DP-4] commit wait timed out
Sep 21 19:14:04 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:14:04 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* [PLANE:264:plane 1D] commit wait timed out
Sep 21 19:14:14 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
Sep 21 19:14:14 sdr-aptv kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to wait for pipe D: -110
The keyboard as well as the pointing device would frequently freeze, xrandr / autorandr would hang more or less indefinitely. Not possible to switch to VT, or really do anything substantial. I did not understand what was going on. When DPMS extension got reinstated, everything returned back to the previous state.
Xorg.log doesn't show much, as far as I can tell. If interested: http://0x0.st/KAqO.txt
Offline
Also, I have to swap cables for HPs to see whether it is the left one (that keeps giving me grief now), or it is one of the dock's DP outputs (standard size DP connector in this case). Will post the result as soon as I see something.
... and I did. First suspend / resume cycle - no issues whatsoever. Interesting, not sure how this is possible. Maybe it is a bad cable, who knows. To be able to reach one of the HPs, I had to use a longer mini-DP to DP cable. Then again, when that particular HP was doing nasty stuff (Black Screen every other minute and after resume from sleep), it was connected to the standard-size DP on the dock. So.... Not sure how this works. Just checked: firmware revision is the same on both HPs. I will play more with the current setup to see if everything remains proper. Then, I shall reintroduce KVM to see how things change.
Sadly, second suspend / resume cycle failed. This time: AOC did not wake up (Black Screen , No signal). Switching to VT and back rectified the problem, and all is now stable.
Journal is here: http://0x0.st/KAWX.txt and Xorg.log here: http://0x0.st/KAW8.txt.
Last edited by pswiatki (2025-09-22 17:56:01)
Offline
I don't like that the disabled DPMS causes you any kind of problem to begin with.
Can you test the behavior (w/ and w/o DPMS) on a bare-bones X11 session (like "startx xterm")?
Online
I don't like that the disabled DPMS causes you any kind of problem to begin with.
Can you test the behavior (w/ and w/o DPMS) on a bare-bones X11 session (like "startx xterm")?
Yes, I can. The only problem is that the last time I used startx commando was.... 26 years ago, or so. Some 11 years before Lennart and Kay started working on systemd. Back then I could issue init 3 and be happy. How can I prepare the system for startx execution these days? Can you give me some hints?
Just read init can also by used with systemd, but nevertheless - let me know what is the best way to test what you propose. Thanks!
Last edited by pswiatki (2025-09-25 12:01:00)
Offline
Edit: disregard. I posted to the wrong thread…
Last edited by seth (2025-09-23 07:49:52)
Online
OK, it looks more and more like the problem transitioned to the other HP monitor (which would indicate an issue with the mini-DP port on the dock). bare-bone X11 not tested yet. Will let you know when done.
Offline
Ok, sorry about that (there was quite a mess the last day because gnome and systemd got updated…) but the xinitrc / process is actually documented in the last link in my signature.
Installing xorg-xinit, twm and xterm and running "startx" from a console login (2nd link in my signature…) should™ do.
Online
Ok, sorry about that (there was quite a mess the last day because gnome and systemd got updated…) but the xinitrc / process is actually documented in the last link in my signature.
Installing xorg-xinit, twm and xterm and running "startx" from a console login (2nd link in my signature…) should™ do.
Thanks! I did my homework and found the relevant information on systemd: the commando to switch runlevels was: systemctl isolate multi-user.target (and I came back with systemctl isolate graphical.target).
I did startx and got two xterm windows automagically, created some more after loading up the autorandr profile appropriate for my setup (to have all displays active) and tried suspend / resume cycles. The results were similar. First, the monitor I suspected The Most went Black Screen, but on a subsequent suspend / resume cycle, that particular monitor came back OK, while the other two(!) did not. Perhaps the dock is acting up. I will consider getting a newer dock (second-hand, naturally) and test again. Moreover, I will switch to my other PC (which has no internal display, as it's a desktop PC) and check if things are better there. That machine has 4 DP outputs on an older nVidia Quadro graphics card.
Last edited by pswiatki (2025-09-26 22:24:34)
Offline
Was that w/ or w/o DPMS enabled?
How did you trigger the suspend ("systemctl suspend" or did you start some GUI, notably gnome stuff)?
Online
Was that w/ or w/o DPMS enabled?
How did you trigger the suspend ("systemctl suspend" or did you start some GUI, notably gnome stuff)?
DPMS was enabled. I will have to retry with DPMS extension for X disabled.
To be honest, I pressed the sleep button on the keyboard. Who knows what the OS did behind the scenes to suspend. I shall retry with systemctl suspend to be sure.
Offline