I'm on Ubuntu 18.04. While analyzing bug 107441 I found that kernels since 4.17 failed to initialize the 2nd monitor attached to my Skylake HW, an Acer n4640g (Celeron® G3900T"). The most obvious missing lines from the DRM debug diff is the missing retraining like: [drm:intel_dp_check_link_status [i915]] DDI D: channel EQ not ok, retraining ... and then there is the missing drm_atomic_add_affected_connectors: [drm:intel_dump_pipe_config [i915]] planes on this crtc [drm:intel_dump_pipe_config [i915]] [PLANE:28:plane 1A] disabled, scaler_id = -1 -[drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 2A] disabled, scaler_id = -1 -[drm:intel_dump_pipe_config [i915]] [PLANE:34:cursor A] disabled, scaler_id = -1 -[drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:47:pipe B] to (ptrval) -[drm:intel_atomic_check [i915]] [CONNECTOR:61:DP-3] checking for sink bpp constrains +[drm:intel_dump_pipe_config [i915]] [PLANE:33:plane 2A] disabled, scaler_id = -1 +[drm:intel_dump_pipe_config [i915]] [PLANE:38:cursor A] disabled, scaler_id = -1 +[drm:intel_atomic_check [i915]] [CONNECTOR:72:DP-3] checking for sink bpp constrains [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to EDID reported max of 24 [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 4 max bw 270000 pixel clock 148500KHz No idea if it's related, but 4.17 is also the first kernel to spill some ACPI error messages before the splash screen: [ 0.049039] ACPI Error: Result stack is empty! State= (ptrval) (20180313/dswstate-65) [ 0.049046] ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand (20180313/dsutils-612) [ 0.049050] ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0 (20180313/dsutils-727) Tested kernels are: * Ok - Ubuntu 18.04 + linux-image-4.15.0-29-generic (4.15.0-29.31) * Ok - Ubuntu 18.04 + linux-image-4.16.18-041618-generic (4.16.18-041618.201806252030) * Fail - Ubuntu 18.04 + linux-image-4.17.11-041711-generic (4.17.11-041711.201807280505) * Fail - Ubuntu 18.04 + linux-image-4.18.0-041800rc7-generic (4.18.0-041800rc7.201807292230)
Created attachment 140923 [details] dmesg of 4.16.18 with dual monitor DisplayPort
Created attachment 140924 [details] dmesg of 4.17.11 with dual monitor DisplayPort
Created attachment 140925 [details] dmesg of 4.18rc7 with dual monitor DisplayPort
$ git bisect log # bad: [60cc43fc888428bb2f18f08997432d426a243338] Linux 4.17-rc1 # good: [0adb32858b0bddf4ada5f364a84ed60b196dbcda] Linux 4.16 git bisect start 'v4.17-rc1' 'v4.16' '--' 'drivers/gpu/drm' # good: [c7963f5f13dfecb3e5d375b4d807927272bf28d0] drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function git bisect good c7963f5f13dfecb3e5d375b4d807927272bf28d0 # bad: [713d451d2df321f1f6128eb6aeeadbefb521a9c9] drm/amd/display: Use MACROS instead of dm_logger git bisect bad 713d451d2df321f1f6128eb6aeeadbefb521a9c9 # good: [0b8eeac5c6ca6dcb19cce04bf8910006ac73dbd3] Merge tag 'drm-misc-next-2018-03-09-3' of git://anongit.freedesktop.org/drm/drm-misc into drm-next git bisect good 0b8eeac5c6ca6dcb19cce04bf8910006ac73dbd3 # good: [7e60946feb4287111dc61a13ee66ea4295f4f6b4] drm/i915/gvt: Release gvt->lock at the failure of finding page track git bisect good 7e60946feb4287111dc61a13ee66ea4295f4f6b4 # bad: [cf07a60f03f06d6298f4e70b3865bd5faac21c3b] drm/i915: Update DRIVER_DATE to 20180308 git bisect bad cf07a60f03f06d6298f4e70b3865bd5faac21c3b # bad: [edb2e5301c4489d8c99b0f3d86a074df27f6f8ff] drm/i915: Track whether the DP link is trained or not git bisect bad edb2e5301c4489d8c99b0f3d86a074df27f6f8ff # good: [93eef7d65329b62cf8a6db918fe5ca5d84eedf50] drm/i915: Stop kicking the signaling thread on seqno wraparound git bisect good 93eef7d65329b62cf8a6db918fe5ca5d84eedf50 # good: [470e7c6189dbce4c0d1beb8cce7e38a9bd5f5144] drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating git bisect good 470e7c6189dbce4c0d1beb8cce7e38a9bd5f5144 # good: [dba14b27dd3ca5ce5b3a1d538862e7dce556dba7] drm/i915: Reinitialize sink scrambling/TMDS clock ratio on HPD git bisect good dba14b27dd3ca5ce5b3a1d538862e7dce556dba7 # bad: [2fed7955bf4c2e87e8b3759939fd0ad961da776e] drm/i915: Nuke intel_dp->channel_eq_status git bisect bad 2fed7955bf4c2e87e8b3759939fd0ad961da776e # bad: [c85d200e832197e23ceeadfda9745646a242fd46] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook git bisect bad c85d200e832197e23ceeadfda9745646a242fd46 # first bad commit: [c85d200e832197e23ceeadfda9745646a242fd46] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook
Created attachment 140956 [details] [review] Fix: Re-apply "Perform link quality check unconditionally during long pulse"
Created attachment 140957 [details] dmesg of 4.18rc7 with dual monitor DisplayPort + fix
Without the patch the monitor is in a strange state. xrandr sees it with modes etc., but the monitor is "frozen": you can't access any of its own OSD. Power cycling doesn't help. As long as the monitor is connected to the DP, it could also be a brick with electricity.
Just tested drm-tip with the same result. Broken without the revert.
The logs don't seem to make any real sense. With the current code we can see the link retraining kicking in, but it fails for some reason. With the proposed fix (which should really be more of a no-op because the current code does have the code to retrain the link, just in a slightly different place than before) we don't see any retraining happening.
(In reply to Ville Syrjala from comment #9) > The logs don't seem to make any real sense. With the current code we can see > the link retraining kicking in, but it fails for some reason. With the > proposed fix (which should really be more of a no-op because the current > code does have the code to retrain the link, just in a slightly different > place than before) we don't see any retraining happening. Hmm. Seem I had the logs reversed. So with the fix we get the failed retraining once. And somehow that "fixes" things. In neither case do we see the sink signalling a hpd to indicate that the link has issues.
(In reply to Ville Syrjala from comment #10) > (In reply to Ville Syrjala from comment #9) > > The logs don't seem to make any real sense. With the current code we can see > > the link retraining kicking in, but it fails for some reason. With the > > proposed fix (which should really be more of a no-op because the current > > code does have the code to retrain the link, just in a slightly different > > place than before) we don't see any retraining happening. > > Hmm. Seem I had the logs reversed. So with the fix we get the failed > retraining once. And somehow that "fixes" things. In neither case do we see > the sink signalling a hpd to indicate that the link has issues. Yup - nothing tells the HW about the wrong link, just the unconditional call in intel_dp_long_pulse detects it and retrains the link and settles on the lower lane count with the higher rate. The original code had the additional debug message: [drm:intel_dp_check_link_status [i915]] DDI D: channel EQ not ok, retraining $ grep "DP-3.*Training Pa" *_drm dmesg-4.16.18_dual_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:61:DP-3] Link Training Passed at Link Rate = 162000, Lane count = 4 dmesg-4.16.18_dual_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:61:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2 dmesg-4.16.18_dual_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:61:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2 dmesg-4.17.11_dual_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 162000, Lane count = 4 dmesg_4.18rc7_dual_fixed_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 162000, Lane count = 4 dmesg_4.18rc7_dual_fixed_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2 dmesg_4.18rc7_dual_fixed_drm:[drm:intel_dp_start_link_train [i915]] [CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2 All this may also be flawy monitor HW / firmware, as it doesn't happen with all of them. Originally I even thought that the DP of the monitor might be broken, as I'm on kernel 4.4 on Ubuntu Trusty, and some other of the same model just worked. But since we have a few hundred or even thousand of them I was just happy to see that kernel 4.15 with Ubuntu Bionic was working. So I thought it might be a driver problem after all. In the end I'm not able to verify anything from the HW side. I don't know if this problem indicates really a HW problem or is just an accepted quality margin in production of the monitor. It is broken in 4.4, working in 4.15 and broken since 4.17 again. These newer model of these monitors seem to have problems with DPMS, where they report the wrong DPMS state (queried via xset q) and won't wake up on user interaction (at least that's my unverified interpretation) and the user has to power cycle them to get a picture after DPMS off. That's the bug I would like to understand and fix, but I can not reproduce it locally, even with HW from the users send in :-(
Hi, I believe I have this bug here with my setup. Dell XPS 9343 (Broadwell i7-5600U) with an Dell P2715Q external monitor. Worked fine on Ubuntu 18.04 (kernel 4.15), but since Ubuntu 18.10 (kernel 4.18), the external screen doesn't wake up after a period of inactivity: - leave the laptop idle for a while, gnome screen lock will take over and shut down the internal panel & external screen (it enters power saving mode). Same behaviour as 18.04. - however, if I come back after an hour or so and move the mouse or press a key, only the internal panel wakes up. The external screen remains blank (Xorg probably think that the external screen is on as the password prompt of gnome screen lock will not be visible on the internal panel, it's probably displayed on the blank surface -- I have to enter my password blind to get back to the desktop). Running xrandr without any argument sometimes helps getting the external screen to turn on. If I press a button on the monitor, it tells that it doesn't receive any signal. Switching it's input from it's usual DP input to another one, and switching back again does restore the image. Turning the monitor OFF and ON again also bring the content back.
Do you still see this issue on latest drm-tip?
Hi, Yes. I have just tested the last drm-tip 5.0.0 kernel (https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2019-01-09/), the issue is still there. Something do happen on the external screen when it's trying to wake up (power led on the screen stops glowing as it is normally in stand by mode), but instead of turning on, it says "entering power save mode" and goes back to sleep. Note that this usually happens after an "extended" sleep time only (> ~5 minutes).
One more detail: when the external screen goes back to sleep instead of fully waking up, xrandr *does* see the screen, it's just off/standing by. Forcing xrandr to reconfigure the screens immediately wakes up the external screen and everything is fine again (until next time). For me, this would be: $ xrandr --output DP-1 --mode 3840x2160 --right-of eDP-1 --primary I have been trying this today, success every time (and better than having to disconnect & reconnect the monitor).
If you are able to reproduce the issue with 5.0 kernel, could you attach the dmesg logs with drm.debug set to 0xE? I want to understand the link training status etc. Also if possible, capture the dmesg logs when you force a m ode through xrand to wake the second monitor. Manasi
Created attachment 143121 [details] dmesg of 5.0.0 drm-tip booting with dual monitor DisplayPort Boot log of 5.0.0 drm-tip with drm.debug=0xe The external monitor comes up fine at boot time.
Created attachment 143122 [details] dmesg of 5.0.0 drm-tip failing to wake up external monitor, failing once when forcing mode with xrandr, then succeeding the second time This dmesg log shows the following sequence: 1. locking gnome-shell, which puts the monitors in standby mode 2. after a while, returning to the laptop and resuming work : the external monitor tries to wake up but fails and returns to sleep 3. after a couple of minutes : forcing mode with xrandr : external monitor tries to wake up, but this time it fails and returns to sleep... again 4. after a couple of minutes : trying to force mode with xrandr a 2nd time : this time it succeeds
(In reply to Cedric M from comment #18) > Created attachment 143122 [details] > dmesg of 5.0.0 drm-tip failing to wake up external monitor, failing once > when forcing mode with xrandr, then succeeding the second time > > This dmesg log shows the following sequence: > > 1. locking gnome-shell, which puts the monitors in standby mode > > 2. after a while, returning to the laptop and resuming work : the external > monitor tries to wake up but fails and returns to sleep The log shows we correctly resume the display: [ 3200.652687] [drm:intel_enable_pipe [i915]] enabling pipe B Then the display magically disappears: [ 3200.724984] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:75:DP-1] status updated from connected to disconnected Then (presumably) userspace responds by turning it off: [ 3201.164373] [drm:intel_disable_pipe [i915]] disabling pipe B And almost immediately the display magically reappears: [ 3202.240649] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:75:DP-1] status updated from disconnected to connected > > 3. after a couple of minutes : forcing mode with xrandr : external monitor > tries to wake up, but this time it fails and returns to sleep... again And the same sequence repeats after you manually try to turn the display back on. So looks like a broken display of some sort. I presme it would work just fine if userspace didn't respond to the bogus hpd by turning the display off. Also I'm not sure why userspace isn't turning the display back on after it reappears. > > 4. after a couple of minutes : trying to force mode with xrandr a 2nd time : > this time it succeeds
Thank you Ville for your analysis. Not sure what I can do about it though :-( The sad thing is that is used to work perfectly -- not sure how or what layer was able to deal with this behaviour/recover from it, voluntarily or not. Any idea of what userspace layer I may look at? (the one that presumably turns the monitor off/on -- and sometimes fails to turn it on) (Ubuntu 18.10/gnome-shell) Cheers
I'm on a ThinkPad X250 (Broadwell) with a Dell P2715Q (Rev A03), and I have the same problem, currently on kernel 4.19, but 4.20 and 4.18 have had the same issues. My userspace is Debian Gnome 3.30 at the moment. Happy to supply more version info if that's helpful. Another thing I came across is that past firmware revisions (A01, A02) have had issues with wakeup from standby: https://www.dell.com/community/Monitors/P2715Q-monitor-won-t-wake-from-sleep-from-power-saving/td-p/5141951
@Jan, do you still have the issue? Have you tried drmtip (https://cgit.freedesktop.org/drm-tip)?
(In reply to Lakshmi from comment #22) > @Jan, do you still have the issue? Have you tried drmtip > (https://cgit.freedesktop.org/drm-tip)? Sorry - forgot to close it. Was fixed by my attached patch as https://cgit.freedesktop.org/drm-tip/commit/?id=3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 Don't have the HW anymore, but back then it did.
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.