Trying to test the latest git (to see how well >2048px large windows work) I hit the following assertion: X: kgem.c:1350: kgem_retire: Assertion `bo->domain == 3' failed. As my notebook-display just went dead, my debugging capabilities are a bit crippled.
Drat. Could do with the backtrace. Depending on just where the bookkeeping failed it could just be a typo, or it could be a serious use-after-free.
I haven't found the right magic sequence to trigger this locally with gen3. I await further enlightenment, hopefully things will just work...
Thanks a lot for your patience - I'll give it a try next weekend.
Found the trigger, in my case a pageflip. commit a83d90ee61be44a2a36b56ad24bbc6544320448f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed May 9 20:34:52 2012 +0100 sna: Avoid randomly changing domains of active bo After attaching the bo to the scanout, mark it as retired in order to update its domains so that the assertion during retirement later is correct. Reported-by: Clemens Eisserer <linuxhippy@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49526 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just gave it a try and it works - Thanks!
Sorry to inform you the problem still persists, however only with my external monitor at home (1280x1024) - but not with the larger one in my student's residence (1920x1280). With UXA everything works fine. Most of the time, the machine hard-locks when gdb is attached right after receiving SIGABRT - so I can't get a stack-trace most of the time. Only I single time I was able to retrieve one, however doesn't look that helpful to me: Program received signal SIGABRT, Aborted. 0x004c0416 in __kernel_vsyscall () (gdb) bt #0 0x004c0416 in __kernel_vsyscall () #1 0x45daa98f in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x45dac2d5 in __GI_abort () at abort.c:91 #3 0x45deb02a in __libc_message (do_abort=2, fmt=0x45ee594c "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 #4 0x45df1f12 in malloc_printerr (action=<optimized out>, str=<optimized out>, ptr=0x961f5b1) at malloc.c:5021 #5 0x08155ab0 in RegionUninit (_pReg=0x95c3560) at ../../include/regionstr.h:143 #6 RegionUninit (_pReg=0x95c3560) at damage.c:2007 #7 RegionEmpty (_pReg=0x95c3560) at ../../include/regionstr.h:165 #8 DamageEmpty (pDamage=0x95c3558) at damage.c:2009 #9 0x0810938e in xf86RotateRedisplay (pScreen=0x9367620) at xf86Rotate.c:254 #10 xf86RotateBlockHandler (screenNum=0, blockData=0xb770e008, pTimeout=0xbfba8dec, pReadmask=0x8236c40) at xf86Rotate.c:268 #11 0x0807a4f8 in BlockHandler (pTimeout=0xbfba8dec, pReadmask=0x8236c40) at dixutils.c:384 #12 0x080a5971 in WaitForSomething (pClientsReady=0x9512cd0) at WaitFor.c:219 #13 0x08075f1e in Dispatch () at dispatch.c:366 #14 0x0806440a in main (argc=7, argv=0xbfba8f64, envp=0xbfba8f84) at main.c:287
Yeah, that's a known xserver bug. It fails to update its damage across a modeswitch and so chases a stale pointer. Was fixed in 1.12.0 but now broken again. *sigh*
I am on 1.11.4, so that would explain it ;)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.