Bug 98306 - [DP] Cannot get MST display back after power cycle
Summary: [DP] Cannot get MST display back after power cycle
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) All
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: Triaged, ReadyForDev
Depends on:
Reported: 2016-10-18 09:24 UTC by Kirill A. Shutemov
Modified: 2019-06-12 08:24 UTC (History)
7 users (show)

See Also:
i915 platform: HSW
i915 features: display/DP MST

dmesg with drm.debug=0xe (205.62 KB, text/plain)
2016-10-18 09:24 UTC, Kirill A. Shutemov
no flags Details
[PATCH] drm/i915: Refresh that status of MST capable connectors in ->detect() (2.24 KB, patch)
2016-10-19 17:29 UTC, Ville Syrjala
no flags Details | Splinter Review
dmesg with the patch (342.39 KB, text/plain)
2016-10-19 20:32 UTC, Kirill A. Shutemov
no flags Details
dmesg with drm.debug=0x1e log_buf_len=4M (686.73 KB, text/plain)
2018-04-30 13:49 UTC, Kirill A. Shutemov
no flags Details
dmesg with drm.debug=0x1e log_buf_len=4M (566.16 KB, text/plain)
2018-09-14 12:32 UTC, Kirill A. Shutemov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill A. Shutemov 2016-10-18 09:24:30 UTC
Created attachment 127375 [details]
dmesg with drm.debug=0xe

Steps to reproduce:

1. Boot machine (Haswell) with MST monitor (Dell UP2414Q, DP1.2 enabled) attached. It boots fine.

2. Disable the monitor with button on front.

3. Re-enable the monitor. Nothing appears on the screen. It goes to sleep.

Before commit 27d4efc5591a5853de54713bc717de73c8951e17 I used workaround with switching console and back. I doesn't work. Not anymore. See bug #97666 for dmesg without the commit.
Comment 1 Kirill A. Shutemov 2016-10-18 09:26:45 UTC
I've embed annotation into dmesg describing what I did at which point.
Comment 2 Ville Syrjala 2016-10-19 17:29:22 UTC
Created attachment 127407 [details] [review]
[PATCH] drm/i915: Refresh that status of MST capable connectors in  ->detect()

This *might* help. I didn't trawl through the log in detail yet, but cooking up a patch for bug 98323 made me think of this one too. Please test.
Comment 3 Kirill A. Shutemov 2016-10-19 20:31:32 UTC
Oh, well, it makes workaround work again, but it bring NULL pointer dereference back on the second console-and-back too. Seems the same as in #97666. :-/
Comment 4 Kirill A. Shutemov 2016-10-19 20:32:21 UTC
Created attachment 127411 [details]
dmesg with the patch
Comment 5 Ville Syrjala 2016-10-20 09:01:58 UTC
(In reply to Kirill A. Shutemov from comment #3)
> Oh, well, it makes workaround work again, but it bring NULL pointer
> dereference back on the second console-and-back too. Seems the same as in
> #97666. :-/

Win some, lose some :( Well, I suspected the oops would reappear since it wasn't meant to disappear with the bad commit in the first place. So I think this is the fix we want anyway for this particular regression, and as far as the oops goes that's still unresolved it seems. I'm not sure what happened with the connector ref counting work, but that would have supposedly been the way to fix this sort of stuff.
Comment 6 Kirill A. Shutemov 2016-10-20 10:22:47 UTC
Should we re-open bug #97666 in this case?
Comment 7 Ville Syrjala 2016-10-20 10:52:12 UTC
(In reply to Kirill A. Shutemov from comment #6)
> Should we re-open bug #97666 in this case?

Yeah, since that was about the oops it's probably better to continue working that problem there.
Comment 8 Ville Syrjala 2016-11-11 17:28:08 UTC
Potential fix, testing appreciated
Comment 9 Kirill A. Shutemov 2016-11-14 01:41:30 UTC
I guess, it should fix wake up of the display after power-cycle without console-and-back.

Tested with your dp_mst_fixes_4 -- it doesn't help.
Comment 10 Carlos Santa 2016-11-16 22:42:35 UTC
If it helps, I get the following :

[  169.359737] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Also, I was not able to bring back the screen w/ CTRL + ALT + F1/F7.
Comment 11 Jani Saarinen 2016-12-09 10:09:44 UTC
Kiril, still issue seen with latest kernel?
Comment 12 Kirill A. Shutemov 2016-12-12 07:01:56 UTC
Situation is still the same on v4.9.
Comment 13 Jani Saarinen 2017-03-08 07:41:59 UTC
Kiril, with latest changes on atomic / watermark is this still valid?
Comment 14 Kirill A. Shutemov 2017-03-09 23:43:26 UTC
The same on 4.11.0-rc1-00096-gea6200e84182
Comment 15 Paul Menzel 2017-04-07 10:40:51 UTC
A user here experiences a similar issue on a *Dell Inc. OptiPlex 7010* with the monitor *DELL U2410*. X.Org Server 1.19.3 is used with the modesetting driver.

$ lspci -nn -s 0:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
$ more /proc/version 
Linux version 4.9.20.mx64.147 (root@lassmichmalbittekurznachdenken.molgen.mpg.de) (gcc version 5.3.0 (GCC) ) #1 SMP Mon Apr 3 09:59:18 CEST 2017

Turning off the monitor, and back on again, it goes into powersaving mode. Restarting the X.Org Server with for example `systemctl restart gdm.service` fixes the problem.

Please tell me, if you want me to open a separate bug report for this issue.
Comment 16 Jani Saarinen 2017-06-08 07:04:21 UTC
Kiris, propably anything not changed but asking still if valid with latest drm-tip?
Comment 17 Armando Antonio 2017-06-29 17:26:59 UTC
I could not reproduce the issue with the following configuration:

        Graphic stack

kernel version              : 4.12.0-rc3-drm-tip-ww22-commit-187376e+
architecture                : x86_64
os version                  : Ubuntu 17.04
os codename                 : zesty
kernel driver               : i915
bios revision               : 4.6
bios release date           : 03/02/2017

        Graphic drivers
mesa                        : 17.0.3
modesetting                 : modesetting_drv.so
xorg-xserver                : 1.19.3
libdrm                      : 2.4.81
cairo                       : 1.14.8
xserver                     : X.Org X Server
intel-gpu-tools (tag)       : intel-gpu-tools-1.18-211-g00ce341b
intel-gpu-tools (commit)    : 00ce341b

platform                   : HSW-Nuc
motherboard id             : D54250WYK
form factor                : Desktop
cpu family                 : Core i5
cpu family id              : 6
cpu information            : Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz
gpu card                   : Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
memory ram                 : 3.79 GB
max memory ram             : 16 GB
display resolution         : 1600x900
cpu thread                 : 4
cpu core                   : 2
cpu model                  : 69
cpu stepping               : 1
socket                     : Socket LGA1150
signature                  : Type 0, Family 6, Model 69, Stepping 1
hard drive                 : 223GiB (240GB)
current cd clock frequency : 450000 kHz
maximum cd clock frequency : 450000 kHz
displays connected         : DP-1


             kernel parameters
quiet splash fastboot drm.debug=0xe

Comment 18 Paul Menzel 2017-06-30 09:28:58 UTC
(In reply to Armando Antonio from comment #17)
> I could not reproduce the issue with the following configuration:


What display did you test with?

The problem still persists here with DRM tip.
Comment 19 Armando Antonio 2017-07-27 21:43:29 UTC
I used a generic Dell monitor with resolution 1920x1080. Regards
Comment 20 Jani Saarinen 2018-03-29 07:11:13 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 21 Jani Saarinen 2018-04-23 07:47:04 UTC
Kiril, can you test with latest drm-tip, some changes to MST there.
Comment 22 Kirill A. Shutemov 2018-04-23 12:08:08 UTC
(In reply to Jani Saarinen from comment #21)
> Kiril, can you test with latest drm-tip, some changes to MST there.

Will do after LSF/MM 2018.
Comment 23 Kirill A. Shutemov 2018-04-30 08:12:56 UTC
Nope. Still need to switch to console and back to get the display work.
Comment 24 Jani Saarinen 2018-04-30 08:30:29 UTC
Do you tried with https://cgit.freedesktop.org/drm-tip and can you also send dmesg with drm.debug=0x1e log_buf_len=4M?
Comment 25 Kirill A. Shutemov 2018-04-30 13:49:29 UTC
Created attachment 139228 [details]
dmesg with drm.debug=0x1e log_buf_len=4M


64.325890 - power off the display
71.040522 - power it back on

Then I switched to console and back to workaround the issue.
Comment 26 Kirill A. Shutemov 2018-04-30 13:50:43 UTC
It's on drm-tip: 317c4acc3b82 "drm-tip: 2018y-04m-29d-23h-12m-54s UTC integration manifest"
Comment 27 Lakshmi 2018-09-10 12:16:22 UTC
Sorry for delay...

Kirill, Do you still have this issue?
Comment 28 Lakshmi 2018-09-10 12:19:13 UTC
If you still have the issue,

Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.

If not I can close the bug.
Comment 29 Kirill A. Shutemov 2018-09-14 12:32:57 UTC
Created attachment 141562 [details]
dmesg with drm.debug=0x1e log_buf_len=4M

The bug still persists on current Linus' tree and drm-tip. This is log from drm-tip.
Comment 30 Lakshmi 2019-04-15 15:38:42 UTC
Kirill, Can you please verify the issue once again with drmtip? Last time you verified was 6 months ago.
If the issue persists please the attach the dmesg from boot.
Comment 31 Kirill A. Shutemov 2019-04-19 14:16:56 UTC
Sorry, I don't have the hardware anymore to trigger the issue.
Comment 32 Lakshmi 2019-06-12 08:24:55 UTC
To confirm this issue exists in drmtip, we need someone to reproduce this issue. Closing this bug as WORKSFORME.

Please reopen this issue if it occurs on drmtip (https://cgit.freedesktop.org/drm-tip).

Remember to add dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M, if the problem persists with drmtip.

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.