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