Bug 465415

Setting version back to rawhide I don't know why John Poelstra changed it to 8, I guess this was accidental.

I've just retested this with latest everything relevant (from koji) this still happens:
kernel-2.6.27.4-68.fc10.x86_64
libdrm-2.4.0-0.21.fc10.x86_64
xorg-x11-server-Xorg-1.5.2-10.fc10.x86_64
xorg-x11-drv-ati-6.9.0-38.fc10.x86_64
mesa-libGL-7.2-0.13.fc10.x86_64

This time I've logged in remotely and did some poking. There is some interesting info in xorg.log (will attach) about the server EQ overflowing (with a backtrace).

Also once I kill blobAndConquer, X starts working again, and the following messages are seen on the terminal from which I started blobAndConquer:

Mesa 7.3-devel implementation error: radeon_program_pair.c::allocate_input_registers(): Don't know how to handle inputs 0x8


Please report at bugzilla.freedesktop.org
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 354
Software fallback:!fp->translated
***************************************************************************
Mesa 7.3-devel implementation error: radeon_program_pair.c::allocate_input_registers(): Don't know how to handle inputs 0x8


And then lots of repeating of the radeon_program_pair.c::allocate_input_registers() message.

Created attachment 321901 [details]
xorg.log with errors and backtrace

Okay, this sortof belongs in another bug. Sort of. I just remembered that I've had (and am still having) issues with vdrift as well.

If you install the vdrift + vdrift-data packages from F-9 on rawhide (the rawhide vdrift is broken see bug 467860) and the try to start it on my system I get:

"""
Mesa 7.3-devel implementation error: Command buffer contains 308 uncommitted dwords
in r300FlushCmdBufLocked called from r300DestroyContext.

Please report at bugzilla.freedesktop.org
vdrift: r300_cmdbuf.c:184: r300BeginBatch: Assertion `r300->cmdbuf.written == r300->cmdbuf.reserved' failed.
Aborted
"""

I'm tagging this onto this bug report (for now) because, iirc, then with some earlier mesa versions from rawhide blobAndConquer used to give similar errors. So this might be related to this bug.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still happens with kernel -132 and xorg-x11-drv-ati -61

Backtrace is always interesting:

0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e76f6]
1: /usr/bin/Xorg(mieqEnqueue+0x291) [0x4c8261]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc4) [0x491194]
3: /usr/bin/Xorg(xf86PostMotionEvent+0xa9) [0x491369]
4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7fa2fc821126]
5: /usr/bin/Xorg [0x47a485]
6: /usr/bin/Xorg [0x46b027]
7: /lib64/libc.so.6 [0x7fa308d77120]
8: /lib64/libc.so.6(ioctl+0x7) [0x7fa308e25707]
9: /usr/lib64/libdrm.so.2 [0x7fa307696023]
10: /usr/lib64/libdrm.so.2(drmGetLock+0x67) [0x7fa307696237]
11: /usr/lib64/xorg/modules/extensions//libdri.so(DRILock+0xed) [0x7fa3078d692d]
12: /usr/lib64/xorg/modules/extensions//libdri.so(DRIDoWakeupHandler+0x3d) [0x7fa3078d698d]
13: /usr/lib64/xorg/modules/extensions//libdri.so(DRIWakeupHandler+0x66) [0x7fa3078d5976]
14: /usr/bin/Xorg(WakeupHandler+0x4b) [0x44a49b]
15: /usr/bin/Xorg(WaitForSomething+0x1ef) [0x4e4c0f]
16: /usr/bin/Xorg(Dispatch+0x7f) [0x44661f]
17: /usr/bin/Xorg(main+0x45d) [0x42ccdd]
18: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fa308d62566]
19: /usr/bin/Xorg [0x42c0b9]

I believe this is libdrm crash -- reassigning.

This no longer happens in rawhide, closing.