http://bugs.freedesktop.org/show_bug.cgi?id=21942

           Summary: Mobility x1400 crash and hang (during init?)
           Product: Mesa
           Version: 7.2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/r300
        AssignedTo: dri-devel@lists.sourceforge.net
        ReportedBy: tfo...@alumni.unh.edu


Created an attachment (id=26225)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=26225)
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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to