Date: Tue, 13 Jan 2009 13:34:33 +0100 From: Christoph Mallon <christoph.mallon@gmx.de> To: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> Cc: Garrett Cooper <yanefbsd@gmail.com>, freebsd-x11 <freebsd-x11@freebsd.org>, Doug Barton <dougb@freebsd.org>, FreeBSD Current <freebsd-current@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: <496C8A59.6090301@gmx.de> In-Reply-To: <496C5F37.4070006@mail.zedat.fu-berlin.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496C8A59.6090301>