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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496C8C09.3050204>