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

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