Re: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics)

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