Hi again, I took a closer look at the problem, but I can't really figure out what is going wrong.
So, the assert that is triggered is always the following one: > Xorg: > /var/tmp/portage/x11-base/xorg-server-1.19.5/work/xorg-server-1.19.5/dix/privates.c:385: > dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed. This happens when glamor_init() calls dixRegisterPrivateKey() with type=PRIVATE_PIXMAP. I think the only place where .created is incremented is dixInitScreenPrivates(), which is called from AllocatePixmap(). But apparantly this is never called before glamor_init(). I then had a look at modeset, which uses dixRegisterScreenSpecificPrivateKey() instead of dixRegisterPrivateKey(). I then proceeded to replace all calls with type=PRIVATE_PIXMAP and type=PRIVATE_GC in glamor with this. This helps somewhat, but now it crashes later. Same assertion failure, but now in Xv: > Xorg: > /var/tmp/portage/x11-base/xorg-server-1.19.5/work/xorg-server-1.19.5/dix/privates.c:385: > dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed. > > Thread 1 "Xorg" received signal SIGABRT, Aborted. > 0x00007fada58d1178 in raise () from /lib64/libc.so.6 > #0 0x00007fada58d1178 in raise () from /lib64/libc.so.6 > No symbol table info available. > #1 0x00007fada58d25fa in abort () from /lib64/libc.so.6 > No symbol table info available. > #2 0x00007fada58ca0b7 in ?? () from /lib64/libc.so.6 > No symbol table info available. > #3 0x00007fada58ca162 in __assert_fail () from /lib64/libc.so.6 > No symbol table info available. > #4 0x0000000000461871 in dixRegisterPrivateKey (key=0x8bf7a0 > <XF86XVWindowKeyRec>, type=PRIVATE_WINDOW, size=0) > at > /var/tmp/portage/x11-base/xorg-server-1.19.5/work/xorg-server-1.19.5/dix/privates.c:385 > t = PRIVATE_XSELINUX > offset = 21715344 > bytes = 8 > __PRETTY_FUNCTION__ = "dixRegisterPrivateKey" > #5 0x00000000004abbdd in xf86XVScreenInit (pScreen=0xf54de0, > adaptors=0x7fffebda4eb8, num=1) > at > /var/tmp/portage/x11-base/xorg-server-1.19.5/work/xorg-server-1.19.5/hw/xfree86/common/xf86xv.c:239 > pScrn = 0x8 > ScreenPriv = 0xecb850 > #6 0x00007fad9e5a3a67 in ScreenInit (pScreen=0xf54de0, argc=0, argv=0x0) > at > /var/tmp/portage/x11-base/xorg-server-1.19.5/work/xorg-server-1.19.5/hw/xfree86/drivers/modesetting/driver.c:1683 > glamor_adaptor = 0x14fd760 > pScrn = 0xed3680 > ms = 0xefdd80 > visual = 0x99f4e8 I could of course continue to also replace these calls, but honestly it feels like opening a can of worms. My impression is that modeset does some initialization in the wrong order, which by chance works in the non-hotplug scenario. Which led me to investigate what happens with non-hotplug. The funny thing is, nothing happens. modeset isn't even loaded for the device. So something prematurely stops all the probing for /dev/dri/card1. I'd like to investigate this further, but at the moment I have no idea what to look for. With best wishes, Tobias Hans de Goede wrote: > Hi, > > On 20-10-17 19:08, [email protected] wrote: >> On laptop systems with a dedicated (powerful) GPU A, you usually >> have all connectors routed to another (less-powerful) GPU B. >> >> With my setup (GPU A = Nvidia, GPU B = Intel) I keep GPU A switched >> off by not loading the nouveau kernel driver during boot. >> >> Loading nouveau while X is running then crashes the server: >> [ 540.775] (EE) 0: /usr/bin/X (xorg_backtrace+0x41) [0x57fa31] >> [ 540.775] (EE) 1: /usr/bin/X (0x400000+0x183429) [0x583429] >> [ 540.775] (EE) 2: /lib64/libpthread.so.0 (0x7ff02d508000+0x10ec0) >> [0x7ff02d518ec0] >> [ 540.775] (EE) 3: /lib64/libc.so.6 (gsignal+0x38) [0x7ff02d1a2178] >> [ 540.775] (EE) 4: /lib64/libc.so.6 (abort+0x16a) [0x7ff02d1a35fa] >> [ 540.775] (EE) 5: /lib64/libc.so.6 (0x7ff02d16f000+0x2c0b7) >> [0x7ff02d19b0b7] >> [ 540.775] (EE) 6: /lib64/libc.so.6 (0x7ff02d16f000+0x2c162) >> [0x7ff02d19b162] >> [ 540.775] (EE) 7: /usr/bin/X (dixRegisterPrivateKey+0x247) [0x452197] >> [ 540.775] (EE) 8: /usr/lib64/xorg/modules/libglamoregl.so >> (glamor_init+0x160) [0x7ff00ee564d0] >> [ 540.775] (EE) 9: /usr/lib64/xorg/modules/drivers/modesetting_drv.so >> (0x7ff01c19a000+0x83e1) [0x7ff01c1a23e1] >> [ 540.775] (EE) 10: /usr/bin/X (AddGPUScreen+0xf3) [0x4348b3] >> [ 540.775] (EE) 11: /usr/bin/X (0x400000+0x90271) [0x490271] >> [ 540.775] (EE) 12: /usr/bin/X (0x400000+0x9547b) [0x49547b] >> [ 540.775] (EE) 13: /usr/bin/X (0x400000+0x905d7) [0x4905d7] >> [ 540.775] (EE) 14: /usr/bin/X (xf86VTEnter+0x1bb) [0x47399b] >> [ 540.775] (EE) 15: /usr/bin/X (WakeupHandler+0xda) [0x438e3a] >> [ 540.775] (EE) 16: /usr/bin/X (WaitForSomething+0x1ce) [0x57d6fe] >> [ 540.775] (EE) 17: /usr/bin/X (0x400000+0x34221) [0x434221] >> [ 540.775] (EE) 18: /usr/bin/X (0x400000+0x382f8) [0x4382f8] >> [ 540.775] (EE) 19: /lib64/libc.so.6 (__libc_start_main+0xf0) >> [0x7ff02d18f670] >> [ 540.776] (EE) 20: /usr/bin/X (_start+0x29) [0x4235b9] >> >> In particular note that GLAMOR is initialized for GPU A, which >> makes no sense since it has no connectors. >> >> Fix this by bailing out early in the modesetting DDX when a setup >> with zero connectors is detected. >> >> Signed-off-by: Tobias Jakobi <[email protected]> > > Sorry, but NACK. The modesetting driver actually had such a check before > and I removed it because not having a driver breaks rendering on > the dedicated GPU with "DRI_PRIME=1" for dri2 clients. > > I guess that there is some sort of assumption in the code for dealing > with glamor failure that it only happens on coldplug, if you really > want to be able to modprobe nouveau later you should figure out what > is exactly going wrong and fix that. > > Note BTW that nouveau should runtime suspend the GPU, even with Xorg > running and there really is no need to not load nouveau. > > Regards, > > Hans _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
