Help with debuging Xserver / Goes in an infinite loop

[Joshua C.]

I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
read the instructions here
http://www.x.org/wiki/Development/Documentation/ServerDebugging but
this didin't help. My Xserver goes in an infinite loop and starts
consuming 100% my cpu. Therefore the whole system freezes and I have
to manually reboot it. This happens all the time when I use firefox on
random sites. After restart there is nothing in the xorg.0.log and
everything repeats itself when I start firefox again. Therefore I need
to remove the savesession.js from the firefox home directory.

On the second mashine I also turned this on: handle SIGUSR1 nostop,
handle SIGUSR2 nostop, handle SIGPIPE nostop.

The Xserver just keeps running and I get no messages on the second
mashine. How to debug it?

[Joshua C.]

2009/10/3 Joshua C. :
> I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
> read the instructions here
> http://www.x.org/wiki/Development/Documentation/ServerDebugging but
> this didin't help. My Xserver goes in an infinite loop and starts
> consuming 100% my cpu. Therefore the whole system freezes and I have
> to manually reboot it. This happens all the time when I use firefox on
> random sites. After restart there is nothing in the xorg.0.log and
> everything repeats itself when I start firefox again. Therefore I need
> to remove the savesession.js from the firefox home directory.
>
> On the second mashine I also turned this on: handle SIGUSR1 nostop,
> handle SIGUSR2 nostop, handle SIGPIPE nostop.
>
> The Xserver just keeps running and I get no messages on the second
> mashine. How to debug it?

Anyone? Any ideas?

[Adam Jackson]

On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote:
> I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
> read the instructions here
> http://www.x.org/wiki/Development/Documentation/ServerDebugging but
> this didin't help. My Xserver goes in an infinite loop and starts
> consuming 100% my cpu. Therefore the whole system freezes and I have
> to manually reboot it. This happens all the time when I use firefox on
> random sites. After restart there is nothing in the xorg.0.log and
> everything repeats itself when I start firefox again. Therefore I need
> to remove the savesession.js from the firefox home directory.
>
> On the second mashine I also turned this on: handle SIGUSR1 nostop,
> handle SIGUSR2 nostop, handle SIGPIPE nostop.
>
> The Xserver just keeps running and I get no messages on the second
> mashine. How to debug it?

I wouldn't expect you to get messages on the second machine.  If you're
using 100% of the CPU it's because you're busy doing something _other_
than printing to the log.

What does 'bt' in gdb show?

- ajax

[Joshua C.]

2009/10/5 Adam Jackson :
> On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote:
> > I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
> > read the instructions here
> > http://www.x.org/wiki/Development/Documentation/ServerDebugging but
> > this didin't help. My Xserver goes in an infinite loop and starts
> > consuming 100% my cpu. Therefore the whole system freezes and I have
> > to manually reboot it. This happens all the time when I use firefox on
> > random sites. After restart there is nothing in the xorg.0.log and
> > everything repeats itself when I start firefox again. Therefore I need
> > to remove the savesession.js from the firefox home directory.
> >
> > On the second mashine I also turned this on: handle SIGUSR1 nostop,
> > handle SIGUSR2 nostop, handle SIGPIPE nostop.
> >
> > The Xserver just keeps running and I get no messages on the second
> > mashine. How to debug it?
>
> I wouldn't expect you to get messages on the second machine.  If you're
> using 100% of the CPU it's because you're busy doing something _other_
> than printing to the log.
>
> What does 'bt' in gdb show?
> ajax
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

When should I issue this command? After attaching gdb and sending the
handle options I type in cont and the server keeps going until it
freezes the mashine. No other messages are reported.

PS: I thought this isn't the right place for this question and
reposted it on the [e-mail].

[Adam Jackson]

On Mon, 2009-10-05 at 17:39 +0200, Joshua C. wrote:
> 2009/10/5 Adam Jackson :
> > On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote:
> > > The Xserver just keeps running and I get no messages on the second
> > > mashine. How to debug it?
> >
> > I wouldn't expect you to get messages on the second machine.  If you're
> > using 100% of the CPU it's because you're busy doing something _other_
> > than printing to the log.
> >
> > What does 'bt' in gdb show?
>
> When should I issue this command? After attaching gdb and sending the
> handle options I type in cont and the server keeps going until it
> freezes the mashine. No other messages are reported.

Before typing in cont, of course.  "cont" continues execution from where
you're currently stopped.  "bt" shows a backtrace of where you're
currently stopped.

- ajax

[Colin Walters]

On Mon, Oct 5, 2009 at 4:06 PM, Adam Jackson  wrote:
> Before typing in cont, of course.  "cont" continues execution from where
> you're currently stopped.  "bt" shows a backtrace of where you're
> currently stopped.

If you're not planning to actively debug and just want a stack, i'd
use: gstack $(pidof Xorg)

[Joshua C.]

2009/10/5 Colin Walters :
> On Mon, Oct 5, 2009 at 4:06 PM, Adam Jackson  wrote:
> > Before typing in cont, of course.  "cont" continues execution from where
> > you're currently stopped.  "bt" shows a backtrace of where you're
> > currently stopped.
>
> If you're not planning to actively debug and just want a stack, i'd
> use: gstack $(pidof Xorg)
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

(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

[root@localhost ~]# gstack $(pidof X)
#0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
#1  0x00000000004e615a in WaitForSomething ()
#2  0x0000000000446ef2 in Dispatch ()
#3  0x000000000042d205 in main ()

[Adam Jackson]

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

[Joshua C.]

2009/10/5 Adam Jackson :
> 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
> [e-mail]
> 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

["Jóhann B. Guðmundsson"]

On 10/05/2009 09:05 PM, Joshua C. wrote:
> 2009/10/5 Adam Jackson :
> > 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
> > [e-mail]
> > 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

Which kernel are you using ?

JBG

[Joshua C.]

2009/10/6 "Jóhann B. Guðmundsson" :
> On 10/05/2009 09:05 PM, Joshua C. wrote:
> > 2009/10/5 Adam Jackson :
> > > 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
> > > [e-mail]
> > > 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
>
> Which kernel are you using ?
>
> JBG
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

I think the following can be useful:

lspci -vvv:
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon
Xpress 200M] (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 010f
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
> TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

Latency: 66 (2000ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at c8000000 (32-bit, prefetchable)
[size=128M]
        Region 1: I/O ports at 9000 [size=256]
        Region 2: Memory at c0100000 (32-bit, non-prefetchable)
[size=64K]
        [virtual] Expansion ROM at c0120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: radeon
        Kernel modules: radeon, radeonfb

Installed packages:
kernel-debuginfo-2.6.30.8-64.fc11.x86_64
kernel-debuginfo-common-x86_64-2.6.30.8-64.fc11.x86_64
kernel-2.6.30.8-64.fc11.x86_64

xorg-x11-server-utils-7.4-7.1.fc11.x86_64
xorg-x11-server-common-1.6.4-0.1.fc11.x86_64
xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64
xorg-x11-server-debuginfo-1.6.4-0.1.fc11.x86_64

xorg-x11-drv-ati-debuginfo-6.12.2-18.fc11.x86_64
xorg-x11-drv-ati-6.12.2-18.fc11.x86_64

mesa-dri-drivers-7.6-0.2.fc11.x86_64
mesa-libGLU-7.6-0.2.fc11.x86_64
mesa-libGL-7.6-0.2.fc11.x86_64
mesa-debuginfo-7.6-0.1.fc11.x86_64

libdrm-debuginfo-2.4.11-2.fc11.x86_64
libdrm-2.4.11-2.fc11.x86_64

I've also attached my Xorg.0.log.

Usually there are no error messages in dmesg. However once I found
this in there (not sure if it's related):
[drm:drm_buffer_object_validate] *ERROR* Out of aperture space or DRM
memory quota.
[drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.
ffff880142183000 19219 20000a7 10000a7
[drm:drm_buffer_object_validate] *ERROR* Out of aperture space or DRM
memory quota.
[drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.
ffff880142183000 19219 20000a7 10000a7
[drm:drm_buffer_object_validate] *ERROR* Out of aperture space or DRM
memory quota.
[drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.
ffff880142183000 19219 20000a7 10000a7
[drm:drm_buffer_object_validate] *ERROR* Out of aperture space or DRM
memory quota.
[drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.
ffff880142183000 19219 20000a7 10000a7

The same is with the Xorg.0.log - no error messages. But two weeks ago
I saw this (never seen it since then):
(EE) RADEON(0): ADVANCE_RING count != expected (14 vs 16) at
radeon_textured_videofuncs.c:1623
(EE) RADEON(0): ADVANCE_RING count != expected (14 vs 16) at
radeon_textured_videofuncs.c:1623
(EE) RADEON(0): ADVANCE_RING count != expected (14 vs 16) at
radeon_textured_videofuncs.c:1623

[Matej Cepl]

Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:

Do we have a bug for this? If not, please do file one and include all 
those information you collected for this thread together with /var/log/
Xorg.0.log (if possible after the problem happened -- on reboot put 3 to 
the end of the kernel command line, so Xorg is not started on boot, and 
then you can save previous /var/log/Xorg.0.log from the session which 
ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg 
(if you can get it from other terminal than the one where you run gdb in 
moment things go bad).

Thank you very much,

Matěj

[Joshua C.]

2009/10/6 Matej Cepl :
> Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:
>
> Do we have a bug for this? If not, please do file one and include all
> those information you collected for this thread together with /var/log/
> Xorg.0.log (if possible after the problem happened -- on reboot put 3 to
> the end of the kernel command line, so Xorg is not started on boot, and
> then you can save previous /var/log/Xorg.0.log from the session which
> ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg
> (if you can get it from other terminal than the one where you run gdb in
> moment things go bad).
>
> Thank you very much,
>
> Matěj
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452

[Joshua C.]

2009/10/6 Joshua C. :
> 2009/10/6 Matej Cepl :
> > Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:
> >
> > Do we have a bug for this? If not, please do file one and include all
> > those information you collected for this thread together with /var/log/
> > Xorg.0.log (if possible after the problem happened -- on reboot put 3 to
> > the end of the kernel command line, so Xorg is not started on boot, and
> > then you can save previous /var/log/Xorg.0.log from the session which
> > ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg
> > (if you can get it from other terminal than the one where you run gdb in
> > moment things go bad).
> >
> > Thank you very much,
> >
> > Matěj
> >
> > --
> > fedora-devel-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452

I tried the latest F12-Snap3-x86_64-Live-KDE from 18.09.2009. There
were also other problems but I think this still exists in F12. I've
updated my bug report with the output from gdb.

[Joshua C.]

2009/10/6 Joshua C. :
> 2009/10/6 Joshua C. :
> > 2009/10/6 Matej Cepl :
> > > Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:
> > >
> > > Do we have a bug for this? If not, please do file one and include all
> > > those information you collected for this thread together with /var/log/
> > > Xorg.0.log (if possible after the problem happened -- on reboot put 3 to
> > > the end of the kernel command line, so Xorg is not started on boot, and
> > > then you can save previous /var/log/Xorg.0.log from the session which
> > > ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg
> > > (if you can get it from other terminal than the one where you run gdb in
> > > moment things go bad).
> > >
> > > Thank you very much,
> > >
> > > Matěj
> > >
> > > --
> > > fedora-devel-list mailing list
> > > [e-mail]
> > > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> > Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452
>
> I tried the latest F12-Snap3-x86_64-Live-KDE from 18.09.2009. There
> were also other problems but I think this still exists in F12. I've
> updated my bug report with the output from gdb.

Looking into the debug output I think this is bug in the radeon-driver
or the drm component. Most of the instances refer to drm*** or exa***
functions. Maybe I should update the bug report?

[Rodd Clarkson]

On Mon, 2009-10-05 at 23:05 +0200, Joshua C. wrote:
> 2009/10/5 Adam Jackson :
> > 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
> > [e-mail]
> > 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

[Joshua C.]

2009/10/13 Rodd Clarkson :
> On Mon, 2009-10-05 at 23:05 +0200, Joshua C. wrote:
> > 2009/10/5 Adam Jackson :
> > > 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
> > > [e-mail]
> > > 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
> [e-mail]
> 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).