drm: Don't race connector registration

Commit Message

Dave Hansen Feb. 1, 2017, 8:55 p.m. UTC

On 02/01/2017 12:52 AM, Daniel Vetter wrote:
> On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
>> I added some printk()s all over and gathered a bit more information
>> about what's going on.  It looks like the display doesn't work until the
>> drm connector code cleans up the *old* connector.  For some reason, it
>> isn't motivated to do that until I go to the console and back.
>>
>> In this case, the display was connected to DP-4.
>> intel_dp_destroy_mst_connector() got called on it when I switched away,
>> but drm_connector_cleanup() did not get called.  Upon switching back
>> DP-3/5/6 get created.  One of these *eventually* ends up being
>> "enabled", but is not now.  When I switch over to the console,
>> drm_connector_cleanup() finally gets called on the old connector: DP-4
>> and I can switch back to X and I see one of DP-3/5/6 enabled and working.
>>
>> Here are some snippets of dmesg interspersed with what I was doing:
> 
> Ok, so the delayed deleting seems to be involved in the bug (and we only
> do that since we recently introduced refcounting for hotplugged
> connectors). The question is who's getting confused, either kernel or X.
> To figure this out, next time things are out of sync, please compare the
> output of
> 
> $ xrandr
> 
> with what's reported in /sys/class/drm/*/status:
> 
> $ grep . /sys/class/drm/card0-DP-*/status

OK, I collected that 4 times:
1. When everything is OK
2. When the DVI is unplugged
3. When the DVI is re-plugged (no output)
4. After I press Ctrl-Alt-F2 (back to OK)

The good vs. bad diff looks like this:

 HDMI2 disconnected (normal left inverted right x axis y axis)
@@ -41,5 +32,5 @@
 /sys/class/drm/card0-DP-1/status:disconnected
 /sys/class/drm/card0-DP-2/status:disconnected
 /sys/class/drm/card0-DP-3/status:disconnected
-/sys/class/drm/card0-DP-5/status:connected
+/sys/class/drm/card0-DP-4/status:connected
 /sys/class/drm/card0-DP-6/status:disconnected

But it's very interesting that when I unplug the DVI, the xrandr output
does not change.  Only the /sys/class/drm/.../status does.

> Another question: What desktop are you using, and if you unplug a screen,
> does that general reconfigure the desktop size to disable that output? The
> zombie connector only sticks around as long as someone is still using it
> in the screen configuration. As soon as the reconfiguration has happened,
> it should go away. You can test this by manually disabling the output when
> it's stuck as on:
> 
> $ xrandr --output DP-4 --off

Yep, it does the delayed cleanup.  The output still shows up in xrandr
(as an 8x8 display) at this point, but it can at least be turned back on.

xrandr snippet:

	Screen 0: minimum 8 x 8, current 8 x 8, maximum 32767 x 32767

So, if I do a pair of these:

	xrandr --output DP-4 --off
	xrandr --output DP-4 --auto

it does bring the display back consistently.

Patch

--- xdebug.1485980540.start.log	2017-02-01 12:22:20.328242293 -0800
+++ xdebug.1485980621.dvi-replugged.log	2017-02-01 12:23:41.964241982 -0800
@@ -25,15 +25,6 @@ 
 DP2-1 disconnected (normal left inverted right x axis y axis)
 DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x
axis y axis) 518mm x 324mm
    1920x1200      60.0*+
-   1920x1080      60.0
-   1600x1200      60.0
-   1680x1050      59.9
-   1280x1024      60.0
-   1280x960       60.0
-   1024x768       60.0
-   800x600        60.3
-   640x480        59.9
-   720x400        70.1
 DP2-3 disconnected (normal left inverted right x axis y axis)
 HDMI1 disconnected (normal left inverted right x axis y axis)