[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#275735: xserver-xfree86-dbg: server (normal and -dbg) lock with radeon (Mobility 7500 M7 LW) on an ibook



retitle 275735 xlibmesa-dri: [radeon_dri] card locks up in drmDMA() after RADEONCPGetBuffer() on Radeon Mobility M7 LW [Radeon Mobility 7500] rev 0
reassign 275735 xlibmesa-dri
tag 275735 + moreinfo upstream
thanks

On Mon, Oct 18, 2004 at 11:02:14AM -0400, Michel Dänzer wrote:
> On Mon, 2004-10-18 at 07:31 -0500, Branden Robinson wrote:
> > 
> > On Sat, Oct 09, 2004 at 11:43:38PM +0200, David Decotigny wrote:
> > > Here are some gdb traces on the -dbg version of the server (debian 2.6.8 ppc UP
> > > kernel). In gdb I tried to break multiple times to see whether the call
> > > stack changed. Another trace comes afterwards, which was made with the
> > > "normal" version of the server (ie no debug):
> > [...]
> > > 0x0fe154cc in ioctl () from /lib/libc.so.6
> > > (gdb) bt
> > > #0  0x0fe154cc in ioctl () from /lib/libc.so.6
> > > #1  0x1047b520 in drmDMA (fd=7, request=0x7ffff560) at xf86drm.c:796
> > > #2  0x10053764 in RADEONCPGetBuffer (pScrn=0x10d40f40) at radeon_accel.c:490
> > > #3  0x10051bb4 in RADEONSetupForScanlineImageWriteCP (pScrn=0x10d40f40, rop=3,
> > >     planemask=4294967295, trans_color=-1, bpp=32, depth=24)
> > >     at radeon_accelfuncs.c:941
> > > #4  0x102dcfd0 in XAAWritePixmapScanline (pScrn=0x10d40f40, x=525, y=53,
> > >     w=374, h=3, src=0x10fb7bc0 "", srcwidth=1496, rop=3, planemask=4294967295,
> > >     trans=-1, bpp=32, depth=24) at xaaImage.c:354
> > 
> > This sort of thing is a bit beyond me.  Locking up during an ioctl()
> > suggests to me that the problem might be in the kernel DRM driver.
> 
> This is one of many possible symptoms of a chip lockup, which is
> probably caused by the 3D driver in xlibmesa-dri.

Okay.  I'm reassigning the bug accordingly.

M. Decotigny, you should be able to confirm whether this is a DRI driver
problem by doing either of the following:

1) removing the xlibmesa-dri package;

or

2) setting the environment variable LIBGL_ALWAYS_INDIRECT to a non-null
   value in the process environment of *every* program that uses the GL
   library.

I generally recommend approach 1) as it's sure to rule out usage of the
DRI driver.

Can you please confirm whether or not disabling the DRI driver makes this
problem go away?

-- 
G. Branden Robinson                |    I have a truly elegant proof of the
Debian GNU/Linux                   |    above, but it is too long to fit
branden@debian.org                 |    into this .signature file.
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature


Reply to: