I see the same with ThinkPad T450s. kernel-4.8.5-300.fc25 is fine, kernel-4.8.6-300.fc25 is broken. After disconnecting the laptop from docking station, it thinks the external display is still connected, and even when I put it back, the display no longer works (I need to reboot to get both displays working again).

However, when I tried the same with direct VGA cable (no docking station involved), it worked fine. So either this is just about docking stations, or this is about certain types of connections (e.g. DP affected, but VGA not).

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)

I'm proposing this for blocker/FE discussion, because yesterday we've approved FE for 4.8.6 kernel for several reasons. And also we have lots of people using docking stations, of course.

I'm running Fedora 23 with 4.7.3-100.fc23.x86_64 kernel on X1 Carbon 3rd gen.

When I have my docking station connected with extrenal DP display, I see this:

$ xrandr
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
eDP1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1368x768      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm
   1920x1080     60.00*+  50.00    59.94  
   1680x1050     59.88  
   1400x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08  
DP2-2 disconnected (normal left inverted right x axis y axis)
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Previously, when I undocked, xrandr reported DP2-1 as disconnected. However, for the past couple of weeks, it keeps reporting it connected for about 40 seconds.

It's entirely different version fo kernel, but the problem seems very similar.

Maybe it's not a kernel issue?

It's a kernel issue. I gave Miro instructions to check what statuses of displays the kernel reports and in his case, the external monitor is correctly reported as disconnected after undocking, so it's a different issue somewhere higher in the graphics stack.

Jiri, what blocker criterion do you believe this is violating?

The closest I can find is "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional.", but that would be a really hard argument to make that it's entirely non-functional.

I'd give this a +1 FE, but unless you can see a more specific criterion this violates, I'm -1 blocker. (On the grounds that I think this would fail the "last blocker at Go/No-Go" test.)

For the purposes of documentation, does it work OK if you manually disable the external output before undocking?

oh, and for the record, I'm definitely -1 blocker on this. Maybe +1 FE, but we introduced this with a kernel FE, so maybe we should cut our losses at some point. :P

(In reply to Stephen Gallagher from comment #4)
> Jiri, what blocker criterion do you believe this is violating?

Don't ask me because I'm not the one who proposed it as a blocker. But I think it's certainly an annoying issue which will hit quite a few users, so we should treat it as a priority at least for after-release updates.

It should not be difficult to track down the change that made the regression. I happened between 4.8.5 and 4.8.6 and Rui Matos says it's already fixed in 4.9.

You can manually disable the external output even after undocking and it fixes the situation, but I'm not sure the monitor will turn on when you dock the laptop and manually enable the external output again (can't try right now, running a different kernel).

I do not think this should qualify as either blocker or fe TBH. It doesn't really get in the way of installation in most cases. I do expect that this will be fixed with a release day update.

Can those of you seeing this issue please test the scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=16358486 and let me know if that fixes things?

(In reply to Justin M. Forbes from comment #9)
> Can those of you seeing this issue please test the scratch build at
> https://koji.fedoraproject.org/koji/taskinfo?taskID=16358486 and let me know
> if that fixes things?

No, in my case it doesn't help.

It doesn't fix it for me either.

How about this one? Sorry, since I don't have a docking station, I can't test here, I am trying to get things fixed for release though.

http://koji.fedoraproject.org/koji/taskinfo?taskID=16375871

Much appreciated. Unfortunately that doesn't help either.

But upstream 4.9.x works?

http://koji.fedoraproject.org/koji/taskinfo?taskID=16390060 This looks to have the actual fix with a patch pulled from next.  Test and feedback please?

Yes, that works. Thanks!

(In reply to Kamil Páral from comment #16)
> Yes, that works. Thanks!

Talking about comment 15.

I'd be inclined to take this as long as it's constrained (no rebase from upstream at the same time).

Discussed at mini blocker review during go/no-go meeting [1].

This bug was rejected as Final Blocker - this clearly doesn't violate any of the criteria and can reasonably be fixed with an update

[1] https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.html

kernel-4.8.7-300.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-876deae183

kernel-4.8.7-100.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fe1b74912f

kernel-4.8.7-200.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-14c4187e3a

kernel-4.8.7-300.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-876deae183

kernel-4.8.7-200.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-14c4187e3a

kernel-4.8.7-100.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fe1b74912f

FWIW, running 4.8.7-200.fc24.x86_64 (and previously 4.8.6) on a Thinkpad X250 with Ultra Dock Pro, external display on DisplayPort through dock.  I can reproduce:

- Machine running on dock
- Suspend
- Remove from dock
- Resume
- xrandr Correctly "sees" just the laptop panel
- Suspend
- Dock
- Resume
- xrandr still only seems the laptop panel.
- Remove and reconnect DP cable, then:

Nov 13 01:39:11 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:12 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:12 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:13 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:14 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:14 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:15 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:15 vimes kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting
Nov 13 01:39:15 vimes kernel: [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
Nov 13 01:39:16 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:17 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:17 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:18 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:19 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:19 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:20 vimes kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
Nov 13 01:39:20 vimes kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting
Nov 13 01:39:20 vimes kernel: [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns

Sorry about the noise...  This morning I finally updated the X250's BIOS to the latest, 1.24.  Now I can no longer get this to reproduce - two scenarios, both under 4.8.7-200.fc24.x86_64:

- System running on dock, both monitors working.
- Hot-undock.
- System/xrandr adjusts to just laptop panel.
- Hot-dock.
- System/xrandr adjusts back to both monitors.

- System running on dock, both monitors working.
- Suspend to RAM.
- Undock.
- Resume.
- System/xrandr adjusts to just laptop panel.
- Suspend to RAM.
- Dock.
- Resume.
- System/xrandr adjusts back to both monitors.

I don't see the i915 errors in dmesg any more, just this when resuming in the second scenario:

[drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22

Discussed at 2016-11-14 freeze exception review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-11-14/f25-blocker-review.2016-11-14-17.00.html . If we'd had a bit more time we would have liked to pull this in, but as it's getting close to go/no-go again it seems not worth the risk of pulling another new kernel in just to fix this. There are a lot of affected users, but a 0-day fix will solve most use cases here, it seems unlikely people need to dock/undock from the live image very often.

(In reply to Fedora Update System from comment #20)
> kernel-4.8.7-300.fc25 has been submitted as an update to Fedora 25.
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-876deae183

Fixes the issue for me.

kernel-4.8.8-100.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ee3a114958

kernel-4.8.7-200.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.8.8-100.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ee3a114958

kernel-4.8.7-300.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.8.8-100.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

I'm seeing the same issue on an HP EliteBook 840, with Fedora 25 and kernel 4.8.14-300.fc25.x86_64