Help with debuging Xserver / Goes in an infinite loop

Joshua C. joshuacov at googlemail.com
Tue Oct 13 12:59:08 UTC 2009 

2009/10/13 Rodd Clarkson <rodd at clarkson.id.au>:
> On Mon, 2009-10-05 at 23:05 +0200, Joshua C. wrote:
>> 2009/10/5 Adam Jackson <ajax at redhat.com>:
>> > On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
>> >
>> >> (gdb) bt
>> >> #0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
>> >> #1  0x00000000004e615a in WaitForSomething (
>> >>     pClientsReady=<value optimized out>) at WaitFor.c:228
>> >> #2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
>> >> #3  0x000000000042d205 in main (argc=<value optimized out>,
>> >>     argv=0x7fffa2ac9218, envp=<value optimized out>) at main.c:397
>> >
>> > Okay, this isn't the server actually taking 100% of the CPU (almost
>> > certainly), it's before that.  If you type 'cont' to resume, and then ^C
>> > the gdb process once the CPU goes wild, you should break back to the gdb
>> > prompt; _that_'s the backtrace I need.
>> >
>> > Of course, you might not, in which case debugging this gets a bit
>> > harder.
>> >
>> > - ajax
>> >
>> > --
>> > fedora-devel-list mailing list
>> > fedora-devel-list at redhat.com
>> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>> >
>>
>> (gdb) handle SIGUSR1 nostop
>> Signal        Stop      Print   Pass to program Description
>> SIGUSR1       No        Yes     Yes             User defined signal 1
>> (gdb) handle SIGUSR2 nostop
>> Signal        Stop      Print   Pass to program Description
>> SIGUSR2       No        Yes     Yes             User defined signal 2
>> (gdb) handle SIGPIPE nostop
>> Signal        Stop      Print   Pass to program Description
>> SIGPIPE       No        Yes     Yes             Broken pipe
>> (gdb) cont
>> Continuing.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
>> #1  0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
>> arg=0x7fff78cabbc0) at xf86drm.c:187
>> #2  0x0000003cd600335c in drmCommandWriteRead (fd=8,
>> drmCommandIndex=<value optimized out>, data=0x7fff78cabbc0,
>> size=<value optimized out>)
>>     at xf86drm.c:2363
>> #3  0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf=<value
>> optimized out>) at radeon_bufmgr_gem.c:282
>> #4  0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
>> index=0) at radeon_exa.c:279
>> #5  0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
>> index=0) at exa.c:523
>> #6  0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
>> index=0, pReg=0x0) at exa.c:543
>> #7  0x00007f6c69beceac in ExaCheckComposite (op=<value optimized out>,
>> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=<value optimized
>> out>,
>>     ySrc=<value optimized out>, xMask=0, yMask=0, xDst=19, yDst=85,
>> width=55, height=18) at exa_unaccel.c:342
>> #8  0x00007f6c69beb564 in exaComposite (op=<value optimized out>,
>> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=<value optimized
>> out>,
>>     ySrc=<value optimized out>, xMask=0, yMask=0, xDst=19, yDst=85,
>> width=55, height=18) at exa_render.c:967
>> #9  0x000000000052eb90 in damageComposite (op=8 '\b', pSrc=<value
>> optimized out>, pMask=<value optimized out>, pDst=0x27a04b0, xSrc=1,
>> ySrc=0,
>>     xMask=<value optimized out>, yMask=<value optimized out>, xDst=19,
>> yDst=85, width=55, height=<value optimized out>) at damage.c:643
>> #10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
>> #11 0x00000000004471d4 in Dispatch () at dispatch.c:456
>> #12 0x000000000042d205 in main (argc=<value optimized out>,
>> argv=0x7fff78cac198, envp=<value optimized out>) at main.c:397
>>
>
> Hmmm, I wonder if you're not having the same issues (or similar) to me.
>
> See: https://bugzilla.redhat.com/show_bug.cgi?id=528593
>
> If I run gdb I get the following:
>
> #0  0x00000032c16d9717 in ioctl () at ../sysdeps/unix/syscall-template.S:82
> #1  0x00000032dec03203 in drmIoctl (fd=9, request=3221775460,
>    arg=0x7fff192a1ab0) at xf86drm.c:188
> #2  0x00000032dec0344c in drmCommandWriteRead (fd=<value optimized out>,
>    drmCommandIndex=<value optimized out>, data=<value optimized out>,
>    size=<value optimized out>) at xf86drm.c:2394
> #3  0x00007f7cc9f81f59 in bo_wait (bo=0x1cdc780) at radeon_bo_gem.c:206
> #4  0x00007f7cc9f82035 in bo_map (bo=0x1cdc780, write=<value optimized out>)
>    at radeon_bo_gem.c:181
> #5  0x00007f7cca24f36d in _radeon_bo_map (line=2320,
>    func=<value optimized out>, file=0x1 <Address 0x1 out of bounds>, write=0,
>    bo=<value optimized out>) at /usr/include/drm/radeon_bo.h:151
> #6  R600DownloadFromScreenCS (line=2320, func=<value optimized out>,
>    file=0x1 <Address 0x1 out of bounds>, write=0, bo=<value optimized out>)
>    at r600_exa.c:2320
> #7  0x00007f7cc9545100 in exaGetImage (pDrawable=0x1b37dc0, x=1536, y=704,
>    w=256, h=64, format=<value optimized out>,
>    planeMask=<value optimized out>, d=<value optimized out>)
>    at exa_accel.c:1283
> #8  0x0000000000552a94 in miSpriteGetImage (pDrawable=0x1b37dc0, sx=1536,
>    sy=704, w=256, h=64, format=<value optimized out>,
>    planemask=<value optimized out>, pdstLine=<value optimized out>)
>    at misprite.c:425
> #9  0x000000000042dec0 in DoGetImage (planemask=<value optimized out>,
>    height=<value optimized out>, width=<value optimized out>,
>    y=<value optimized out>, x=<value optimized out>,
>    drawable=<value optimized out>, format=<value optimized out>,
>    client=0x1d2f5f0, im_return=<value optimized out>) at dispatch.c:2244
> #10 ProcGetImage (planemask=<value optimized out>,
>    height=<value optimized out>, width=<value optimized out>,
>    y=<value optimized out>, x=<value optimized out>,
>    drawable=<value optimized out>, format=<value optimized out>,
>    client=0x1d2f5f0, im_return=<value optimized out>) at dispatch.c:2331
> #11 0x000000000042c60c in Dispatch () at dispatch.c:445
> #12 0x0000000000421c9a in main (argc=<value optimized out>,
>    argv=<value optimized out>, envp=<value optimized out>) at main.c:285
>
>
>
>
> Rodd
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Yes, I think it's the same. In my case the mouse pointer also stops
working shortly after the screen freeezes. Until now I haven't seen
this happen after login but only with firefox. I also use kde, no
gnome here. You have radeon 3670 and mine is rs482. Testing with
F12-snap3 didn't show any improvements either.

I hope this gets fixed soon because the pc is almost useless (happens
100% of time).

More information about the fedora-devel-list mailing list