Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 371841 - x11-libs/libdrm-2.4.25 assertion failure triggered by some video drivers
Summary: x11-libs/libdrm-2.4.25 assertion failure triggered by some video drivers
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-15 20:21 UTC by Martin von Gagern
Modified: 2015-02-22 01:56 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2011-06-15 20:21:56 UTC
Switching sci-astronomy/stellarium-0.10.6 from full-screen to windowed display (using F11) caused the application to crash a moment after the smaller window is first drawn. In order to obtain more information, I executed it from the command line the second time, and got this error message:

stellarium: /var/tmp/portage/x11-libs/libdrm-2.4.25/work/libdrm-2.4.25/nouveau/nouveau_pushbuf.c:273: nouveau_pushbuf_flush: Assertion `!nouveau_pushbuf_space(chan, min)' failed.

After closing the window and displaying this error message, my X session froze. The error messages from Xorg.0.log appears to be consistent with bug #263057:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a34a8]
 1: /usr/bin/X (mieqEnqueue+0x1c3) [0x4a2a23]
 2: /usr/bin/X (xf86PostMotionEventM+0x96) [0x47fbb6]
 3: /usr/bin/X (xf86PostMotionEventP+0x31) [0x47fcb1]
 4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f32995e1000+0x4866) [0x7f32995e5866]
 5: /usr/bin/X (0x400000+0x6d878) [0x46d878]
 6: /usr/bin/X (0x400000+0x11b146) [0x51b146]
 7: /lib64/libpthread.so.0 (0x358de00000+0xf890) [0x358de0f890]
 8: /lib64/libc.so.6 (ioctl+0x7) [0x358d2cf7c7]
 9: /usr/lib64/libdrm.so.2 (drmIoctl+0x30) [0x35976038d0]
10: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x3597605d9b]
11: /usr/lib64/libdrm_nouveau.so.1 (0x7f329b0c0000+0x315d) [0x7f329b0c315d]
12: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xda) [0x7f329b0c36fa]
13: /usr/lib64/libdrm_nouveau.so.1 (0x7f329b0c0000+0x220c) [0x7f329b0c220c]
14: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x1b6) [0x7f329b0c2796]
15: /usr/bin/X (_CallCallbacks+0x34) [0x436014]
16: /usr/bin/X (FlushAllOutput+0x2c) [0x46310c]
17: /usr/bin/X (0x400000+0x3162b) [0x43162b]
18: /usr/bin/X (0x400000+0x25bcd) [0x425bcd]
19: /lib64/libc.so.6 (__libc_start_main+0xec) [0x358d21eecc]
20: /usr/bin/X (0x400000+0x25729) [0x425729]

I've had similar issues in the past, see bug #364019 comment #9. Back then it was nvidia-drivers, now it's x11-drivers/xf86-video-nouveau-0.0.16_pre20110323 and sys-kernel/gentoo-sources-2.6.39. But bug #263057 comment #43 states that the above backtrace is just the a side effect of some other bug, so I'd rather concentrate on the libdrm assertion failure in this bug report.

Searching e.g. Google for "nouveau_pushbuf_flush Assertion nouveau_pushbuf_space" yields a large number of hits, but few of them seem actually valuable. It appears that Ubuntu has expired most of its instances with the exception of https://bugs.launchpad.net/bugs/586714 and https://bugs.launchpad.net/bugs/757251. I could not find any matching bug report at all on https://bugs.freedesktop.org/ with the exception of https://bugs.freedesktop.org/show_bug.cgi?id=26193#c17 which is supposedly fixed. If you consider this an upstream bug, I'd be willing to file an upstream bug report, although I won't mind you doing it either.

Further details about my system: running kde-base/kwin-4.6.3-r1 with desktop effects rendered using x11-libs/libXrender-0.9.6 as the OpenGL effects were horribly slow using nouveau. This is an ~amd64 system, with the Gentoo packages fairly up to date.
Comment 1 Martin von Gagern 2011-06-15 21:08:48 UTC
Rebooted, couldn't reproduce at first. Then I ran a live stream video using www-plugins/adobe-flash-10.3.181.14-r1 and www-plugins/nspluginwrapper-1.4.0-r1 in full-screen mode, and after that, I could reproduce the issue, including the X crash, at my first attempt. I did view just such a full screen video before my first crash as well, so that might play a major role as well, and might even be introducing some kind of inconsistency in the first place.
Comment 2 Martin von Gagern 2011-06-16 16:25:28 UTC
Even after running flash videos, I cannot reproduce this problem in every case. So I'd classify this thing as "happens sometimes", which makes debugging and testing of solutions a lot harder. :-(
Comment 3 Rémi Cardona (RETIRED) gentoo-dev 2011-06-16 20:45:00 UTC
Care to try with the latest ~arch ebuilds (libdrm, xorg, xf86-video-nouveau, gentoo-sources) if you're not already using them?

Thanks
Comment 4 Martin von Gagern 2011-06-17 09:33:02 UTC
Updated yesterday, and couldn't reproduce just now. But as I couldn't reliably reproduce this before either, that's not a sure indication. Will try to remember giving this another try every now and then, as there might be other aspects involved which I hadn't considered before.
Comment 5 Matt Turner gentoo-dev 2015-02-22 01:56:17 UTC
Nouveau has undergone a ton of changes since 2011. I'd guess this is already fixed. If it's not report it to https://bugs.freedesktop.org/enter_bug.cgi?product=DRI