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

Fri Nov 3 09:09:00 UTC 2017

HI,

On 30-10-17 10:42, Tobias Jakobi wrote:
> 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.

Weird, on my XPS15 9550 where the nvidia GPU does not have/drives any outputs
I do get 2 devices in xrandr --listproviders as expected. You may want to start
with figuring out why the normal setup where you load nouveau normally is not
working. Perhaps once that works, it will also powerdown the GPU properly.

Regards,

Hans

> 
> 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
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 