Date: Wed, 14 Jan 2009 18:04:30 +0100 From: Stefan Ehmann <shoesoft@gmx.net> To: freebsd-current@freebsd.org Cc: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>, Christoph Mallon <christoph.mallon@gmx.de>, freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) Message-ID: <200901141804.31326.shoesoft@gmx.net> In-Reply-To: <496CA9E3.90700@mail.zedat.fu-berlin.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <496C8A59.6090301@gmx.de> <496CA9E3.90700@mail.zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 13 January 2009 15:49:07 O. Hartmann wrote: > 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). I've been observing this since 7.0 IIRC. With 6.x I never noticed this. When performing a portupgrade or running mencoder everything becomes very sluggish sometimes. E.g. Redrawing windows takes several second, even moderately sized videos can't be played back smoothly anymore. 4BSD seems to be better than ULE but still not perfect. As a workaround I run load intensive tasks with idprio(1), nice(1) doesn't really help that much. Unfortunately I've never been able to reduce this to a simple reproducible test case. E.g. if Xorg has to be involved and what kind of load causes the problems. But my conclusions were similar to your findings. Simply using lots of CPU doesn't affect the responsiveness of the system. But when high disk or network I/O is involved the problem occurs. Also, I figured this would not happen on every system. Otherwise there would have been more complaints on the lists. This also seems to correlate with your statement that the problem is significant on UP hardware, I run a 4+ years old Athlon XP CPU. -- Stefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901141804.31326.shoesoft>