The subject says it all. I've been following the git master for some time. Things worked yesterday, after upgrading (drm, pixman, mesa, xserver, xf86-video-ati) they don't. What I see on the console is the summary message: X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. No errors are reported in Xorg.0.log Finally, when X bails it leaves me in a graphics video mode.
A stack trace would be really useful here; obviously it's not crashing for everyone...
Obviously... The stacktrace is below. Note that this is an older machine, a HP laptop, with a Radeon Mobility 9100IGP graphics card. I have had several, as yet unresolved, issues with this card (e.g., https://bugs.freedesktop.org/show_bug.cgi?id=25597), and most recently GL has stopped working properly. Here's the stactrace X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. Program received signal SIGABRT, Aborted. 0xb72aec66 in raise () from /lib/libc.so.6 (gdb) thread apply all bt full Thread 1 (Thread 0xb726b7c0 (LWP 18702)): #0 0xb72aec66 in raise () from /lib/libc.so.6 No symbol table info available. #1 0xb72b0571 in abort () from /lib/libc.so.6 No symbol table info available. #2 0xb72a7e60 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0xb71e323e in dixGetPrivateAddr (privates=0x826c648, key=0xb71e7e9c) at ../../../include/privates.h:122 __PRETTY_FUNCTION__ = "dixGetPrivateAddr" #4 0xb71e32a9 in dixGetPrivate (privates=0x826c648, key=0xb71e7e9c) at ../../../include/privates.h:137 __PRETTY_FUNCTION__ = "dixGetPrivate" #5 0xb71e334a in dixLookupPrivate (privates=0x826c648, key=0xb71e7e9c) at ../../../include/privates.h:167 No locals. #6 0xb71e3379 in DRI2GetScreen (pScreen=0x826c4f0) at dri2.c:112 No locals. #7 0xb71e4dd4 in DRI2Connect (pScreen=0x826c4f0, driverType=0, fd=0x82aea38, driverName=0xbfacd428, deviceName=0xbfacd424) at dri2.c:959 ds = 0xb71e4dc3 #8 0xb7237784 in __glXDRIscreenProbe (pScreen=0x826c4f0) at glxdri2.c:704 ---Type <return> to continue, or q <return> to quit--- driverName = 0xbfacd448 "\230Ô¬¿+\206\"·ðÄ&\bó\203\"·" deviceName = 0xb72455b8 "hÔ\005" screen = 0x82ae9e8 filename = "ØÎ*\bh\000\000\000h\000\000\000h\000\000\000ô¿<·\220ç*\b`{#\bà\214r·\000\000\000\000øÓ¬¿@7\006\bô¿<·\000\000\000\000 Ñ<·øÓ¬¿Í\027/· Ñ<·\020\000\000\000`{#\bà\214r·\000\000\000\000(Ô¬¿\026\200\006\b\020\000\000\000\001\000\000\000\000\000\000\000?\220\036·\005\000\000\000\000\200\036·ÔÕ\005\000Hâ*\b|Í\004\b" buffer_size = 134644858 pScrn = 0x82620d8 extensions = 0x824bb94 driConfigs = 0x82ae248 i = 134644783 #9 0xb722862b in GlxExtensionInit () at glxext.c:378 glxScreen = 0x811503b extEntry = 0x806cd35 pScreen = 0x826c4f0 i = 0 p = 0xb7247e7c glx_provided = 0 #10 0x080d158e in InitExtensions (argc=1, argv=0xbfacd5a4) at ../../../mi/miinitext.c:541 i = 26 ---Type <return> to continue, or q <return> to quit--- ext = 0x82a7e80 listInitialised = 1 #11 0x0806324e in main (argc=1, argv=0xbfacd5a4, envp=0xbfacd5ac) at main.c:211 i = 256 alwaysCheckForInput = {0, 1}
Looks like your driver isn't calling DRI2ScreenInit. Here's a patch which makes DRI2 simply fail in that case: diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c index d33b0d1..96a8db4 100644 --- a/hw/xfree86/dri2/dri2.c +++ b/hw/xfree86/dri2/dri2.c @@ -956,8 +956,12 @@ Bool DRI2Connect(ScreenPtr pScreen, unsigned int driverType, int *fd, const char **driverName, const char **deviceName) { - DRI2ScreenPtr ds = DRI2GetScreen(pScreen); + DRI2ScreenPtr ds; + + if (!dixPrivateKeyRegistered(dri2ScreenPrivateKey)) + return FALSE; + ds = DRI2GetScreen(pScreen); if (ds == NULL || driverType >= ds->numDrivers || !ds->driverNames[driverType]) return FALSE;
I applied the patch, and now X starts. I'm using the radeon driver. From Xorg.0.log [ 27850.031] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 27850.031] (II) Module radeon: vendor="X.Org Foundation" [ 27850.031] compiled for 1.8.99, module version = 6.13.99 [ 27850.031] Module class: X.Org Video Driver I'll atach the rest of the log file.
Created attachment 36118 [details] Log file after patch
Shouldn't the patch be committed?
Thanks for testing, this is in commit 505724c5f3e4fc1475fa54f20d08c0c06fb32443
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.