Created attachment 106537 [details] dmesg ==System Environment== -------------------------- Regression: Yes. Good commit on -next-queued: 1cf0ba14740d96fbf6f58a201f000a34b74f4725 Non-working platforms: BDW ==kernel== -------------------------- origin/drm-intel-nightly:3d788a0e87efd99553d5b00a70ab2a162c2c2283(fails) drm-intel-nightly: 2014y-09m-18d-14h-51m-54s UTC integration manifest origin/drm-intel-next-queued:f2a95be39ef661595379c23964710f0d760a2385(fails) drm/i915/vlv: Remove check for Old Ack during forcewake origin/drm-intel-fixes: 8c875fca1a8d76665c60fa141c220cee65f44f5e(works) drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv ==Bug detailed description== ----------------------------- Start X, then unplug/plug DP, the DP monitor unable to light up. It works well if don't start X. Hardware Environment: root@x-bdw09:~# lspci -nnn 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) 00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09) 00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1] (rev 03) 00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI Controller #1 [8086:9cba] (rev 03) 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I218-LM [8086:15a2] (rev 03) 00:1f.0 ISA bridge [0601]: Intel Corporation Wildcat Point-LP LPC Controller [8086:9cc3] (rev 03) 00:1f.2 SATA controller [0106]: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] [8086:9c83] (rev 03) 00:1f.3 SMBus [0c05]: Intel Corporation Wildcat Point-LP SMBus Controller [8086:9ca2] (rev 03) 00:1f.6 Signal processing controller [1180]: Intel Corporation Wildcat Point-LP Thermal Management Controller [8086:9ca4] (rev 03) ==Reproduce steps== ---------------------------- 1. Plug DP monitor 2. xinit & 3. Unplug DP cable then plug it
What does xrandr --verbose report before unplugging, after and then after plugging it back in?
Created attachment 106985 [details] xrandr --verbose before plugging (In reply to comment #1) > What does xrandr --verbose report before unplugging, after and then after > plugging it back in? Please check the attachment.
Created attachment 106986 [details] xrandr --verbose plugging
Created attachment 106987 [details] xrandr --verbose after unpluging
Your userspace desktop environment didn't respond to the hotplug notification and so did not extend the desktop onto the new output. Kernel/xrandr looks fine so I don't this is a bug, or at least those snapshots are behaving as expected.
0e32b39ceed665bfa4a77a4bc307b6652b991632 is the first bad commit Author: Dave Airlie <airlied@redhat.com> AuthorDate: Fri May 2 14:02:48 2014 +1000 Commit: Dave Airlie <airlied@redhat.com> CommitDate: Tue Jul 22 11:20:26 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.2: check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. Changes since v0.3: updates for mst apis more state checker fixes irq handling improvements fbcon handling support improved reference counting of link - fixes redocking. Changes since v0.4: handle gpu reset hpd reinit without oopsing check link status on HPD irqs fix suspend/resume Changes since v0.5: use proper functions to get max link/lane counts fix another checker backtrace - due to connectors disappearing. set output type in more places fro, unknown->displayport don't talk to devices if no HPD asserted check mst on short irqs only check link status properly rebase onto prepping irq changes. drop unsued force_act Changes since v0.6: cleanup unused struct entry. [airlied: fix some sparse warnings]. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> :040000 040000 93e1ede3cbc00222af2880adafbd633f5b9fd4e5 19d739b7d711dfeebb5335d34dd43f15f1295be2 M drivers The commit unable to revert
I found the first bad commit about this failure. Maybe enable DP 1.2 MST causes this failure.
(In reply to comment #2) > Created attachment 106985 [details] > xrandr --verbose before plugging > > (In reply to comment #1) > > What does xrandr --verbose report before unplugging, after and then after > > plugging it back in? > > Please check the attachment. Here, did you actually meant that this xrandr was with the DP monitor still attached, i.e. before *unplugging*? If so, since the detection at this point declares that DP1 is unconnected, the bug is that we don't detect the display until after we plug it back in.
(In reply to comment #8) > (In reply to comment #2) > > Created attachment 106985 [details] > > xrandr --verbose before plugging > > > > (In reply to comment #1) > > > What does xrandr --verbose report before unplugging, after and then after > > > plugging it back in? > > > > Please check the attachment. > > Here, did you actually meant that this xrandr was with the DP monitor still > attached, i.e. before *unplugging*? > > If so, since the detection at this point declares that DP1 is unconnected, > the bug is that we don't detect the display until after we plug it back in. xrandr --verbose before plugging：DP monitor didn't attach. xrandr --verbose plugging: DP monitor attached xrandr --verbose after unpluging: DP monitor didn't attach
(In reply to Guo Jinxian from comment #9) > (In reply to comment #8) > > (In reply to comment #2) > > > Created attachment 106985 [details] > > > xrandr --verbose before plugging > > > > > > (In reply to comment #1) > > > > What does xrandr --verbose report before unplugging, after and then after > > > > plugging it back in? > > > > > > Please check the attachment. > > > > Here, did you actually meant that this xrandr was with the DP monitor still > > attached, i.e. before *unplugging*? > > > > If so, since the detection at this point declares that DP1 is unconnected, > > the bug is that we don't detect the display until after we plug it back in. > > xrandr --verbose before plugging：DP monitor didn't attach. > xrandr --verbose plugging: DP monitor attached > xrandr --verbose after unpluging: DP monitor didn't attach Everything seems to work. Is this _really_ with a broken kernel?
With mst connectors go away, maybe this is it? Since the connector wont be there we can restore the mode magically in the kernel In that case this is wontfix ... at least according to Dave Airlie.
(In reply to Daniel Vetter from comment #10) > (In reply to Guo Jinxian from comment #9) > > (In reply to comment #8) > > > (In reply to comment #2) > > > > Created attachment 106985 [details] > > > > xrandr --verbose before plugging > > > > > > > > (In reply to comment #1) > > > > > What does xrandr --verbose report before unplugging, after and then after > > > > > plugging it back in? > > > > > > > > Please check the attachment. > > > > > > Here, did you actually meant that this xrandr was with the DP monitor still > > > attached, i.e. before *unplugging*? > > > > > > If so, since the detection at this point declares that DP1 is unconnected, > > > the bug is that we don't detect the display until after we plug it back in. > > > > xrandr --verbose before plugging：DP monitor didn't attach. > > xrandr --verbose plugging: DP monitor attached > > xrandr --verbose after unpluging: DP monitor didn't attach > > Everything seems to work. Is this _really_ with a broken kernel? After unplug/plug, xrandr is able to detect DP monitor, but x unable to light up, we think it's a bug for end user. If kill x then start x, the x works well.
(In reply to Daniel Vetter from comment #11) > With mst connectors go away, maybe this is it? Since the connector wont be > there we can restore the mode magically in the kernel > > In that case this is wontfix ... at least according to Dave Airlie. Sorry, I don't understand you exactly. Could you tell us what should we do? Thanks.
DP MST replugging doesn't work, that's just how it is. We could try to fix that up, but it would be massive amounts of work. So should be tracked in JIRA and needs people actually working on in.
Close it, since developer think it a to-do task and track it on Jira.
while to track the work in Jira, let's keep this bug open here.
*** Bug 86237 has been marked as a duplicate of this bug. ***
Marking as wontfix again.
reopening with severity=enhancement.
Close this since 3.18 stable has that fix.
Closing old verified.
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.