[PATCH] xfree86: detach scanout pixmaps when detaching output GPUs
aplattner at nvidia.com
Mon May 6 13:17:11 PDT 2013
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
>>>> 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
More information about the xorg-devel