From owner-freebsd-current@FreeBSD.ORG Tue Jan 13 14:49:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEBFB106566B; Tue, 13 Jan 2009 14:49:00 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 333AD8FC1E; Tue, 13 Jan 2009 14:49:00 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LMkZf-00057o-3K>; Tue, 13 Jan 2009 15:48:59 +0100 Received: from e178063220.adsl.alicedsl.de ([85.178.63.220] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LMkZe-0003Xu-W6>; Tue, 13 Jan 2009 15:48:59 +0100 Message-ID: <496CA9E3.90700@mail.zedat.fu-berlin.de> Date: Tue, 13 Jan 2009 15:49:07 +0100 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Christoph Mallon References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de> In-Reply-To: <496C8A59.6090301@gmx.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.63.220 X-Mailman-Approved-At: Tue, 13 Jan 2009 15:22:28 +0000 Cc: Garrett Cooper , freebsd-x11 , Doug Barton , FreeBSD Current Subject: Re: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 14:49:01 -0000 Christoph Mallon wrote: > O. Hartmann schrieb: >> Garrett Cooper wrote: >>> - I've rebuilt my xorg-server a few times and it's still claiming that >>> it was built with 7.1-RC2 -_-... >>> - I can get the Xorg server to go full tilt by just compiling >>> something, like buildworld, via an xterm. >>> >> I also experienced this, but not only with the mentioned 'nv' driver, >> also with 'vesa'. Compiling a kernel or making buildworld, even with no >> -jX option, turns the box sometimes in a state of unresponseness. Mouse >> jumping, no keyboard response, sometimes for more than a minute. This >> happens on a FBSD 8.0-CUR/AMD64 UP box and it also happens on a FreeBSD >> 7.1-STABLE box (also amd64, 4 cores). But on SMP boxes I reralized that >> the problem does not impact that harsh as seen on UP boxes. >> We also had several P4 32bit machines with HTT enabled around, one of >> them was built with FreeBSD 7.1-STABLE AND Xorg and I never realized the >> bumpy X11, even when disabling HTT and running UP and Xorgs vesa driver. >> >> Well, it also seems to make no difference whether I use USB2 stack (in >> FreeBSD 8) or the old one. > > I regularly can observe that batch jobs like large compile jobs get a > lower priority number (i.e. they get preferred by the scheduler) than > X on my UP machine with SCHED_ULE (7.0-STABLE from early July). Just a > bit X activity (switching desktops, scrolling in a browser etc.) is > enough to make its priority number higher than that of make+gcc. > This also causes interesting cascades like stuttering music: > - gcc preferred over X > - X cannot redraw xterm fast enough > - buffer of xterm fills > - mplayer cannot write its status line to xterm and blocks > - because mplayer blocks it cannot feed more data to the sound device > - music stutters ... try moving/draging a xterm rapidly over your screen while playing music, copying a file or encoding, decoding or even compiling something. In my case, suddenly those activities stop running. It is sometimes only noticable when listening to music. I realised those ghost-stops also without X11 - when high disk I/O and/or network I/O happens. This is even harsh on a NFS-server. As I mentioned, this is significantly on UP boxes, but can also be watched on some slower/older SMP hardware (both with FreeBSD 7.1-STABLE AND FreeBSD 8.0-CURRENT).