Re: mysterious X lockups on Sarge

From: Stefan O'Rear (stefanor_at_cox.net)
Date: 08/31/04

  • Next message: Clive Menzies: "Re: KDE 3.3 logout crashes the system"
    Date: Tue, 31 Aug 2004 11:18:45 -0700
    To: debian-user@lists.debian.org
    
    

    On Tue, Aug 31, 2004 at 02:26:12PM -0300, ScruLoose wrote:
    > Hi all,
    >
    > For several weeks now, I've been having X lock up on me occasionally,
    > and I'm a bit stumped as to where to start debugging it...
    >
    > I'm running Sarge on a P4 3.2 HT, and my video card is a GeForce FX
    > 5200 using the nvidia binary driver. I've had this problem on both a
    > home-rolled 2.4.22 kernel and the Debian 2.6.7-SMP kernel-package.
    Do you get the same problem with the generic VESA drivers? (no modules
    in the kernel, just Driver "vesa" - works for my SiS 315 even though
    they say it's unsupported)

    >
    > Every couple of days or so X seems to die an abrupt death. The display
    > will freeze completely, keyboard input has no effect (including
    > CTRL-ALT-F1 and CTRL-ALT-BACKSPACE). The system is still running,
    > though: If XMMS is playing when the problem hits, the music keeps on
    > going; and I can ssh in to the box no problem. If I kill -9 the XDM and
    > /usr/X11R6/bin/X processes then the screen goes black... but then doing
    > /etc/init.d/xdm start just silently fails. So I've been ssh-ing in just
    > to reboot the box.
    Try deleting the pidfile before restarting xdm. (/var/run/xdm.pid)
    Or perhaps just do sudo startx?

    >
    > Now, I've had this happen while I was surfing the web, and while the
    > screensaver was running, and sometimes after the monitor has gone to
    > sleep (oh, and once in the middle of a game of armagetron).
    >
    > A "tail" of XFree86.0.log shows a bunch of GetModeLine entries, but
    > nothing that looks like error or panic or "ack! I'm dying!"...
    > I've done an 8-hr run of memtest86 with no complaints at all, the
    > temperature seems to be happy, and loading the crap out of the system
    > doesn't make it fail (I tried 5 hours of a kernel-compile loop, and 2
    > hours of cpuburn with no problems).
    When you ssh in, does "dmesg" show anything abnormal?

    > So where do I start looking to figure out what's causing this and/or to
    > fix it.

    -- 
    The world's most effective spam filter:
            ln -sf /dev/full /var/mail/$USER
    -- 
    To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    

  • Next message: Clive Menzies: "Re: KDE 3.3 logout crashes the system"

    Relevant Pages

    • Re: OS Question
      ... driver, should not distress you. ... I've made the unwarranted assumption that having multiple threads is ... To protect data in user mode ... Permanence (if apps all crash the lock state is retained because ...
      (microsoft.public.development.device.drivers)
    • Re: LOR with netisr changes
      ... ::> It's just a bug in the driver. ... the softc and is intended to be covered by the driver's softc lock. ... this is a hack to work around a recursion in net80211. ...
      (freebsd-current)
    • Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796
      ... let's go back to the detach case where you actually need a drain. ... guarantee that that won't be forever since it can ensure the task handler ... with the lock held the entire time and doesn't drop it. ... Also, in general the entry points to the driver (ifnet functions, ifmedia ...
      (freebsd-current)
    • Re: [PATCH] Remove process freezer from suspend to RAM pathway
      ... My question referred to drivers trying to bind or unbind a device ... The thread trying to bind is holding a lock which is ... Spinning in the driver with the lock not held is impossible, ... would be easiest to jump directly into the freezer! ...
      (Linux-Kernel)
    • Re: [linux-pm] Re: Hibernation considerations
      ... task to give up the lock. ... To prevent this, the driver ... The task doing the I/O (which will be a user task) ... if userspace can aquire locks that prevent the kernel from shutting off then it's possible for misbehaving userspace code to stop the kernel by simply choosing to never release the lock. ...
      (Linux-Kernel)