[PATCH] xfree86: detach scanout pixmaps when detaching output GPUs

[Aaron Plattner]

On 13-05-08 01:10 PM, Aaron Plattner wrote:
> On 05/06/2013 03:43 PM, Dave Airlie wrote:
>> On Tue, May 7, 2013 at 6:17 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
>>> On 05/05/2013 04:23 PM, Dave Airlie wrote:
>>>>
>>>> On Thu, May 2, 2013 at 5:55 AM, Aaron Plattner <aplattner at nvidia.com>
>>>> wrote:
>>>>>
>>>>> On 04/30/2013 11:30 PM, Dave Airlie wrote:
>>>>>>
>>>>>> On Wed, May 1, 2013 at 7:14 AM, Aaron Plattner <aplattner at nvidia.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Commit 8f4640bdb9d3988148e09a08d2c7e3bab1d538d6 fixed a bit of a
>>>>>>> chicken-and-egg problem by detaching GPU screens when their providers
>>>>>>> are destroyed, which happens before CloseScreen is called.  However,
>>>>>>> this created a new problem: the GPU screen tears down its RandR crtc
>>>>>>> objects during CloseScreen and if one of them is active, it tries to
>>>>>>> detach the scanout pixmap then.  This crashes because
>>>>>>> RRCrtcDetachScanoutPixmap tries to get the master screen's screen
>>>>>>> pixmap, but crtc->pScreen->current_master is already NULL at that
>>>>>>> point.
>>>>>>>
>>>>>>> It doesn't make sense for an unbound GPU screen to still be scanning
>>>>>>> out its former master screen's pixmap, so detach them first when the
>>>>>>> provider is destroyed.
>>>>>>
>>>>>>
>>>>>> Any instructions on how to reproduce this? I've been trying to get it
>>>>>> to happen here.
>>>>>
>>>>>
>>>>> 1. Start X on an Intel system with a DisplayLink device attached.
>>>>> 2. xrandr --setprovideroutputsource 1 0
>>>>> 3. xrandr --output DVI-0 --off (unless you apply "xfree86: don't enable
>>>>> anything in xf86InitialConfiguration for GPU screens")
>>>>> 4. xrandr --auto
>>>>> 5. Terminate the X server.
>>>>>
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc at entry=0x80259740) at
>>>>> ../../randr/rrcrtc.c:370
>>>>> 370     ../../randr/rrcrtc.c: No such file or directory.
>>>>> (gdb) bt
>>>>> #0  0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc at entry=0x80259740)
>>>>> at ../../randr/rrcrtc.c:370
>>>>> #1  0x8010bfab in RRCrtcDestroyResource (value=0x80259740, pid=63) at
>>>>> ../../randr/rrcrtc.c:678
>>>>> #2  0x80062fbe in doFreeResource (res=0x8025bc58, skip=skip at entry=0) at
>>>>> ../../dix/resource.c:873
>>>>> #3  0x8006415b in FreeClientResources (client=0x8023f350) at
>>>>> ../../dix/resource.c:1139
>>>>> #4  0x800641fc in FreeAllResources () at ../../dix/resource.c:1154
>>>>> #5  0x8002b556 in main (argc=3, argv=0xbffff704, envp=0xbffff714) at
>>>>> ../../dix/main.c:321
>>>>> (gdb) p crtc->pScreen->current_master
>>>>> $1 = (ScreenPtr) 0x0
>>>>> (gdb) p crtc->pScreen->myNum
>>>>> $2 = 256
>>>>>
>>>>>> I did notice that xrandr is now broken for detach? how are you detaching
>>>>>> btw?
>>>>>> xrandr --setoutputprovidersource 0x67 0x0 should detach I would think,
>>>>>> but it fails now.
>>>>>
>>>>>
>>>>> Yeah, I noticed that too, and hacked it up to allow me to test it.  I'll
>>>>> try to clean up the change for review.
>>>>>
>>>>> The crash doesn't occur at detach time or if I pull the USB cable.
>>>>
>>>>
>>>> I'm having absolutely no luck reproducing this with the X server
>>>> master + my for-keithp tree pulled in.
>>>>
>>>> I'm not sure what I could be doing different than you are, I've even
>>>> valgrinded it.
>>>
>>>
>>> That's really weird.  I wonder if stuff is initializing in a different order
>>> on your system for some reason.  I just rebuilt at commit
>>> 2746c681639f9512e6e45fb8d0151b996b6aff7f and verified that the problem still
>>> occurs.
>>
>> Can you attach a full Xorg log where it happens?
>
> Attached.  I built the server from commit
> 6993f8b459e25b1a7a0a03e209688a28ce6c2c56 this time.

Our internal QA and end users are continuing to report this crash.
E.g., 
https://devtalk.nvidia.com/default/topic/551709/linux/319-32-the-infamous-blank-black-screen-/post/3859909/#3859909

-- 
Aaron