X freezing occasionally

Younes Manton younes.m at gmail.com
Sat Aug 7 17:51:35 PDT 2010


On Sat, Aug 7, 2010 at 8:34 PM, walt <w41ter at gmail.com> wrote:
>
> Hi list,
>
> This freezing problem happened once yesterday for the first time, and
> (so far) only once today, so it's not easy to reproduce.
>
> I'm running an oddball gemisch of stable and unstable software, so it's
> definitely not a "supported configuration".
>
> I'm not at all surprised this is happening, but I thought I'd ask for your
> observations anyway.
>
> Both times X has locked up, firefox was just starting to load a web page
> that I'd clicked on.  (Two different websites.)
>
> I can ssh into the machine and use top to see /usr/bin/Xorg using 100%
> of CPU (an older single-core amd 32-bit cpu).
>
> Strace shows Xorg is printing endless numbers of the messages below:
> ioctl(7, 0x40086482, 0xbffdc7c8)        = ? ERESTARTSYS (To be restarted)
> --- SIGALRM (Alarm clock) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
>
> If I'm interpreting correctly, fd 7 is (no surprise):
> X  3758   root   7u   CHR   226,0   0t0    2008 /dev/dri/card0
>
> Now for dessert :)
>
> (II) NOUVEAU(0): Modeline "1280x1024"x76.0  141.82  1280 1376 1512 1744  1024 1025 1028 1070 -hsync +vsync (81.3 kHz)
> [mi] EQ overflowing. The server is probably stuck in an infinite loop. [Yes, I suspected that already.]
>
> Backtrace:
> 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80a169b]
> 1: /usr/bin/X (mieqEnqueue+0x196) [0x80a14e6]
> 2: /usr/bin/X (xf86PostMotionEventP+0xe8) [0x80b4958]
> 3: /usr/lib/xorg/modules/input/evdev_drv.so (0xb69da000+0x3321) [0xb69dd321]
> 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb69da000+0x35c9) [0xb69dd5c9]
> 5: /usr/bin/X (0x8048000+0x663bf) [0x80ae3bf]
> 6: /usr/bin/X (0x8048000+0xea23c) [0x813223c]
> 7: (vdso) (__kernel_sigreturn+0x0) [0xb76f5400]
> 8: /usr/lib/libdrm.so.2 (drmCommandWrite+0x3b) [0xb715986b]
> 9: /usr/lib/libdrm_nouveau.so.1 (0xb7176000+0x2e12) [0xb7178e12]
> 10: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xf1) [0xb7179001]
> 11: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_map+0x33) [0xb71790d3]
> 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0xb712c000+0x4eca) [0xb7130eca]
> 13: /usr/lib/xorg/modules/libexa.so (0xb70fa000+0x7602) [0xb7101602]
> 14: /usr/bin/X (0x8048000+0xaa26d) [0x80f226d]
> 15: /usr/bin/X (0x8048000+0x43d6e) [0x808bd6e]
> 16: /usr/bin/X (0x8048000+0x464ff) [0x808e4ff]
> 17: /usr/bin/X (0x8048000+0x1ddf5) [0x8065df5]
> 18: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb721bbb6]
> 19: /usr/bin/X (0x8048000+0x1d9a1) [0x80659a1]
>
> Kernel is today's Linus.git with its (unmodified) nouveau support.
> x11-drivers/xf86-video-nouveau-0.0.16_pre20100615 (gentoo linux)
> x11-drivers/xf86-input-evdev-2.4.0
> x11-libs/libdrm-2.4.21
> x11-base/xorg-server-1.7.7-r1
>
> My real question is: how likely is this freezing to be caused by an actual bug
> somewhere, or is it more likely that my odd mix of package versions just don't
> play nicely together.
>
> BTW, I'm just doing all of this learn something, not to build a production machine.
> I can afford to tinker with it a bit :)
>
> Thanks.

If you're running an NV50 class card it's likely one of two known bugs
in Nouveau and not your software environment. Look for something like
the following in your log:

[drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x########)



More information about the xorg mailing list