On Tue, May 7, 2013 at 6:17 AM, Aaron Plattner <[email protected]> wrote: > On 05/05/2013 04:23 PM, Dave Airlie wrote: >> >> On Thu, May 2, 2013 at 5:55 AM, Aaron Plattner <[email protected]> >> wrote: >>> >>> On 04/30/2013 11:30 PM, Dave Airlie wrote: >>>> >>>> On Wed, May 1, 2013 at 7:14 AM, Aaron Plattner <[email protected]> >>>> 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@entry=0x80259740) at >>> ../../randr/rrcrtc.c:370 >>> 370 ../../randr/rrcrtc.c: No such file or directory. >>> (gdb) bt >>> #0 0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc@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@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? Dave. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
