Date: Tue, 13 Jan 2009 13:41:45 +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: <496C8C09.3050204@gmx.de> In-Reply-To: <496C8A59.6090301@gmx.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de>
index | next in thread | previous in thread | raw e-mail
Christoph Mallon schrieb: > 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 I just realised that this is the classical priority inversion scenario: mplayer has a far higher priority than the compile job, but cannot run because it is waiting for X. This reminds me of the poor little mars probe Sojourner.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496C8C09.3050204>