| Summary: | at server shutdown: dixGetPrivateAddr: Assertion `key->initialized' failed | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Yann Dirson <ydirson> | ||||||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||
| Severity: | critical | ||||||||||||
| Priority: | medium | Keywords: | patch | ||||||||||
| Version: | 7.6 (2010.12) | ||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||
| OS: | Linux (All) | ||||||||||||
| Whiteboard: | |||||||||||||
| i915 platform: | i915 features: | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 46964 [details]
Full Xorg.log
And here is the full log for reference
Does this still happen with xserver 1.10.x? Can you get a full gdb backtrace from the assertion failure? (In reply to comment #2) > Does this still happen with xserver 1.10.x? Yes, 1.10.1-2 from recent wheezy has the same problem. > Can you get a full gdb backtrace from the assertion failure? #1 0x00007f29b2c0d650 in abort () at abort.c:92 #2 0x00007f29b2c03581 in __assert_fail ( assertion=0x7f29b0e251dd "key->initialized", file=<value optimized out>, line=116, function=0x7f29b0e253a0 "dixGetPrivateAddr") at assert.c:81 #3 0x00007f29b0e2292b in dixGetPrivateAddr (pScreen=<value optimized out>) at ../../../../include/privates.h:116 #4 dixGetPrivate (pScreen=<value optimized out>) at ../../../../include/privates.h:131 #5 dixLookupPrivate (pScreen=<value optimized out>) at ../../../../include/privates.h:161 #6 DRI2GetScreen (pScreen=<value optimized out>) at ../../../../hw/xfree86/dri2/dri2.c:113 #7 0x00007f29b0e244f6 in DRI2CloseScreen (pScreen=0x25f9b80) at ../../../../hw/xfree86/dri2/dri2.c:1178 #8 0x00007f29b09e8556 in radeon_dri2_close_screen (pScreen=0x25f9b80) at ../../src/radeon_dri2.c:1296 #9 0x00007f29b09e8a90 in RADEONCloseScreen_KMS (scrnIndex=0, pScreen=0x25f9b80) at ../../src/radeon_kms.c:833 #10 0x00000000004a9bbb in CursorCloseScreen (index=0, pScreen=0x25f9b80) at ../../xfixes/cursor.c:191 #11 0x00000000005695cc in AnimCurCloseScreen (index=<value optimized out>, pScreen=<value optimized out>) at ../../render/animcur.c:106 #12 0x0000000000425897 in main (argc=9, argv=<value optimized out>, envp=<value optimized out>) at ../../dix/main.c:320 Created attachment 47016 [details] Kernel DRM logs May be linked to this assert: the firmware could not be loaded, and some drm functionnality was not activated. But maybe not linked: it looks like this particular firmware was never added to the official kernel (only to the linux-firmware git repo, did not even know about that one), so it it were the culprit, I would have expected more people to get this bug. See eg. http://bugs.debian.org/565437 Created attachment 47027 [details] [review] Only call radeon_dri2_close_screen() if DRI2 was enabled. (In reply to comment #4) > May be linked to this assert: the firmware could not be loaded, and some drm > functionnality was not activated. Well, installing the firmware will likely work around this problem, and you'll probably want to do it anyway for better overall performance. But first, please verify that this X driver patch fixes the problem. (In reply to comment #5) > Created an attachment (id=47027) [details] > Only call radeon_dri2_close_screen() if DRI2 was enabled. > > (In reply to comment #4) > > May be linked to this assert: the firmware could not be loaded, and some drm > > functionnality was not activated. > > Well, installing the firmware will likely work around this problem, and you'll > probably want to do it anyway for better overall performance. > > But first, please verify that this X driver patch fixes the problem. It works perfectly with that patch (let's note for the record that I have already installed the firmware, but not rebooted yet since then, and stat confirms no access to the firmware file since installation of the firmware-linux-nonfree package). Anything I can do to help getting this patch into master ? I just pushed the fix last week, sorry it took so long. |
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.
Created attachment 46963 [details] X log from gdm On a Debian/testing box with a RS880 [Radeon HD 4250], when one user closes his session, the screen claims video signal has disapeared. Xorg.*.log show absolutely nothing wrong, but gdm's X log does show this assert, see attachement. Seems pretty much reproducible, although I can't tell when it first happenned, so it's not easy to track the regression. I can do more tests if required.