Bug 21942 - Mobility x1400 crash and hang (during init?)
Summary: Mobility x1400 crash and hang (during init?)
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: 7.2
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
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

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.


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.