Bug#490071: xorg occupies all cpu time

Michel Dänzer daenzer at debian.org
Wed Aug 6 04:07:04 PDT 2008


On Wed, 2008-08-06 at 12:53 +0200, Brice Goglin wrote:
> Andrea Vettorello wrote:
> >> The last two days, without GDB, again it worked with no issues, so the
> >> glitch, hardware or software, seems disappeared.
> >>     
> >
> > I spoken too early. Well, this time I was able to get a backtrace,
> > don't know if useful:
> >
> > Program received signal SIGINT, Interrupt.
> > 0xb7f0b424 in __kernel_vsyscall ()
> > #0  0xb7f0b424 in __kernel_vsyscall ()
> > #1  0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6
> > #2  0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2
> > #3  0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0)
> >     at ../../src/radeon_accel.c:611
> > #4  0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1)
> >     at ../../src/radeon_accel.c:665
> > #5  0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0)
> >     at ../../src/radeon_accelfuncs.c:686
> > #6  0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146,
> >     w=912, h=173, src=0xa5ded320 "<FF><FF><FF>", srcwidth=3648, rop=3,
> >     planemask=4294967295, trans=-1, bpp=32, depth=24)
> >     at ../../../../hw/xfree86/xaa/xaaImage.c:370
> > #7  0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230,
> >     pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0)
> >     at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218
> > #8  0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230,
> >     pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3,
> >     doBitBlt=0xb7882330 <XAADoImageWrite>, bitPlane=0)
> >     at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203
> > #9  0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008,
> >     pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912,
> >     height=785, dstx=7, dsty=3) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:66
> > #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0,
> >     srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3)
> >     at ../../../miext/cw/cw_ops.c:201
> > #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230,
> >     pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3)
> >     at ../../../miext/damage/damage.c:834
> > #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at ../../dix/dispatch.c:1802
> > #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0)
> >     at ../../Xext/xace.c:281
> > #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502
> > #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp=
> > Cannot access memory at address 0xc0286431
> > ) at ../../dix/main.c:452
> >   
> 
> Did you check that Xorg was actually stuck in there ?

It's a classic backtrace for a GPU lockup - allocating indirect buffers
is one point where things can get stuck if the GPU isn't making
progress.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer





More information about the xorg-driver-ati mailing list