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.
I've embed annotation into dmesg describing what I did at which point.
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.
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. :-/
Created attachment 127411 [details] dmesg with the patch
(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.
Should we re-open bug #97666 in this case?
(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.
Potential fix, testing appreciated https://patchwork.freedesktop.org/series/14821/
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.
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.
Kiril, still issue seen with latest kernel?
Situation is still the same on v4.9.
Kiril, with latest changes on atomic / watermark is this still valid?
The same on 4.11.0-rc1-00096-gea6200e84182
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.
Kiris, propably anything not changed but asking still if valid with latest drm-tip?
I could not reproduce the issue with the following configuration: ====================================== Graphic stack ====================================== ====================================== Software ====================================== 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 1.19.99.1 intel-gpu-tools (tag) : intel-gpu-tools-1.18-211-g00ce341b intel-gpu-tools (commit) : 00ce341b ====================================== Hardware ====================================== 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 ====================================== Firmware ====================================== ====================================== kernel parameters ====================================== quiet splash fastboot drm.debug=0xe regards.
(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.
I used a generic Dell monitor with resolution 1920x1080. Regards
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.
Kiril, can you test with latest drm-tip, some changes to MST there.
(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.
Nope. Still need to switch to console and back to get the display work.
Do you tried with https://cgit.freedesktop.org/drm-tip and can you also send dmesg with drm.debug=0x1e log_buf_len=4M?
Created attachment 139228 [details] dmesg with drm.debug=0x1e log_buf_len=4M Timestamps: 64.325890 - power off the display 71.040522 - power it back on Then I switched to console and back to workaround the issue.
It's on drm-tip: 317c4acc3b82 "drm-tip: 2018y-04m-29d-23h-12m-54s UTC integration manifest"
Sorry for delay... Kirill, Do you still have this issue?
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.
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.
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.
Sorry, I don't have the hardware anymore to trigger the issue.
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.