Bug 465415 - X freezes with certain OpenGL apps (ati x1950 pro)
X freezes with certain OpenGL apps (ati x1950 pro)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-03 03:05 EDT by Hans de Goede
Modified: 2018-04-11 03:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-02 16:17:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.log with errors and backtrace (175.15 KB, text/plain)
2008-10-30 05:27 EDT, Hans de Goede
no flags Details

  None (edit)
Description Hans de Goede 2008-10-03 03:05:48 EDT
Fully up2date x86_64 rawhide system with an RV570. When running "blobAndConquer" (yum install blobAndConquer) X freezes, blobAndConquer was running in windowed mode and all apps stop responding (no keyb and mouse). This happens both with and without modesetting and also with 2.6.26.5 from F-8 updates.

I can still ssh in and everything else seems to work fine, also no CPU is being used while X is hanging. I happily do some more tests to help debug this. So what should I do attach strace to the blobAndConquer process, or ... ?
Comment 1 Hans de Goede 2008-10-24 03:43:20 EDT
Setting version back to rawhide I don't know why John Poelstra changed it to 8, I guess this was accidental.
Comment 2 Hans de Goede 2008-10-30 05:16:13 EDT
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.
Comment 3 Hans de Goede 2008-10-30 05:27:50 EDT
Created attachment 321901 [details]
xorg.log with errors and backtrace
Comment 4 Hans de Goede 2008-10-31 08:45:51 EDT
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.
Comment 5 Bug Zapper 2008-11-25 22:29:55 EST
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
Comment 6 Hans de Goede 2008-12-02 08:02:43 EST
Still happens with kernel -132 and xorg-x11-drv-ati -61
Comment 7 Matěj Cepl 2008-12-19 07:03:45 EST
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.
Comment 8 Hans de Goede 2009-04-02 16:17:40 EDT
This no longer happens in rawhide, closing.

Note You need to log in before you can comment on or make changes to this bug.