Bug 21942 - Mobility x1400 crash and hang (during init?)
Mobility x1400 crash and hang (during init?)
Status: RESOLVED WONTFIX
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300
7.2
Other All
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-26 10:35 UTC by Tom Fogal
Modified: 2009-06-03 09:02 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
The output of 'xdpyinfo' on the user's system. (2.27 KB, text/plain)
2009-05-26 10:35 UTC, Tom Fogal
Details
Output of 'glxinfo' on the user's system. (3.89 KB, text/plain)
2009-05-26 10:37 UTC, Tom Fogal
Details
The content of the Xorg.0.log.old (51.26 KB, text/plain)
2009-05-27 04:37 UTC, Ekaterina Filippova
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Fogal 2009-05-26 10:35:33 UTC
Created attachment 26225 [details]
The output of 'xdpyinfo' on the user's system.

A user is reporting a crash in our OpenGL-based application when running on Mesa DRI drivers.  Another user piped in and mentioned that the app works in a similar environment for him (same distro), except that he is using the ATI drivers.

Both systems are Fedora 10, i686.

works:   Mesa 7.2, though I imagine it's only there because of / for OSMesa.
doesn't: Mesa 7.2, DRI drivers

glxinfo "renderer":
works:   OpenGL renderer string: ATI Mobility Radeon HD 2400 XT
doesn't: OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
         The user reports the non-working card is a "ATI Mobility Radeon X1400"

glxinfo "vendor":
works:   OpenGL vendor string: ATI Technologies Inc.
doesn't: OpenGL vendor string: DRI R300 Project

uname -a:
works:   Linux sangiovese 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23
         23:37:54 EDT 2009 i686 i686 i386 GNU/Linux
doesn't: Linux localhost.localdomain 2.6.27.5-117.fc10.i686 #1 SMP Tue
         Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux

I had them run our app with the environment variables MESA_NO_3DNOW, MESA_NO_ASM, MESA_XSYNC, and MESA_DEBUG all set to 1.  They reported no change in behavior, other than the warning about the lack of a texture compression shared object from the Mesa user.

I attempted to get the user to run our application under gdb.  For our app, this is done a bit strangely; there's a frontend shell script which will pop up an xterm && automatically run gdb in that xterm.  The user reported that the xterm comes up behind another window, and when they click the xterm to raise it, their X server hard locks and they must reboot.  I am not sure if the user is knowledgeable enough to know about zapping the X server or trying to ssh in and reboot, so I can't say whether it's an X lock or a full system lock.

Our debug logs happen to run `xpdyinfo'; I'll attach a log of that.  It seems we trim the output of it slightly though; in particular, the list of visuals is missing.  Ditto for glxinfo.
Comment 1 Tom Fogal 2009-05-26 10:37:10 UTC
Created attachment 26226 [details]
Output of 'glxinfo' on the user's system.

Confusingly, the "OpenGL version string" says Mesa 7.3-devel.  Yet from the
user's yum output, it seems pretty certain that 7.2 is installed.
Comment 2 Tormod Volden 2009-05-26 12:00:45 UTC
Please attach Xorg.0.log.old as well. You might have more luck running gdb remotely in a ssh session. Please also try to reproduce on a newer version of mesa and xf86-video-ati.
Comment 3 Ekaterina Filippova 2009-05-27 04:37:57 UTC
Created attachment 26244 [details]
The content of the Xorg.0.log.old
Comment 4 Ekaterina Filippova 2009-05-29 10:28:05 UTC
I've got my app working with the ATI drivers.  I am sorry but I am disinclined to play with my driver setup anymore. Thus it might be best to close this bug.
Comment 5 Jerome Glisse 2009-06-03 09:02:12 UTC
So won't fix it, maybe when KMS for radeon enter mainline it will help with your issue.