[PATCH] modesetting: fail PreInit() if the device has zero connectors

Mon Oct 30 09:42:17 UTC 2017

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, tobias.jakobi1 at uni-bielefeld.de 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 <tjakobi at math.uni-bielefeld.de>
> 
> 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