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

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).