Re: debugging xorg-x11

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

 



On Thu, 2004-05-27 at 00:40, Charles R. Anderson wrote:
> I have a FC2 system whose X11 has locked up after sitting on a
> screensaver overnight.  I can still get into the system via ssh, but I
> cannot vt switch away from the locked up X11.  The X process is taking 
> up all the CPU:
> 
> USER       PID %CPU %MEM   VSZ  RSS TT       STAT  STARTED     TIME COMMAND
> root     23040 97.7  5.2 67488 20248 ?       R     May 22 1-16:02:50 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
> 
> strace shows it in a tight loop:
> 
> select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
> select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
> select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
> 
> Xorg.0.log shows this repeating error:
> 
> (EE) RADEON(0): GetBuffer timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): GetBuffer timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> ...
> 
> How can I go about debugging this so I can make a meaningful bug
> report?  What debuginfo packages and gdb version do I need?
> 
> xorg-x11-6.7.0-2 is using radeon driver for this card:
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
>         Subsystem: ATI Technologies Inc Radeon 7000/Radeon VE
>         Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 161
>         Memory at d0000000 (32-bit, prefetchable)
>         I/O ports at d000 [size=256]
>         Memory at dd000000 (32-bit, non-prefetchable) [size=64K]
>         Capabilities: [58] AGP version 2.0
>         Capabilities: [50] Power Management version 2
> 
> kernel is 2.6.5-1.358smp.  Chipset:
> 
> 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
>         Flags: bus master, medium devsel, latency 0
>         Memory at d8000000 (32-bit, prefetchable)
>         Capabilities: [a0] AGP version 2.0
>         Capabilities: [c0] Power Management version 2
> 
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
>         Flags: bus master, 66Mhz, medium devsel, latency 0
>         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>         I/O behind bridge: 0000d000-0000dfff
>         Memory behind bridge: dc000000-ddffffff
>         Prefetchable memory behind bridge: d0000000-d7ffffff
>         Expansion ROM at 0000d000 [disabled] [size=4K]
>         Capabilities: [80] Power Management version 2
> 
> CPUs:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 8
> model name      : Pentium III (Coppermine)
> stepping        : 3
> cpu MHz         : 799.919
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse
> bogomips        : 1572.86
> 
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 8
> model name      : Pentium III (Coppermine)
> stepping        : 3
> cpu MHz         : 799.919
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse
> bogomips        : 1597.44
> 
> Thanks.

I'm guessing a gl-based screensaver is what has you stuck. Once you
reboot, use glxinfo to see if dri is enabled, then try running glxgears
(or tuxracer). I think you will see similar behavior (screen will lock
up, but you can ssh in and reboot that way). At least it seems I can
reproduce it that way here. (I have screensavers disabled).

-- 
Chris Kloiber




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux