From owner-freebsd-x11@FreeBSD.ORG Tue Jan 13 12:48:28 2009 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FCE41065679 for ; Tue, 13 Jan 2009 12:48:28 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7DE628FC19 for ; Tue, 13 Jan 2009 12:48:26 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 13 Jan 2009 12:41:46 -0000 Received: from p54A3E610.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.230.16] by mail.gmx.net (mp026) with SMTP; 13 Jan 2009 13:41:46 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX198zO958YJ8qGQAE3+PT9VuT8cDpAnT+wDHTB4UsJ JkZ/UoQlW5IR4E Message-ID: <496C8C09.3050204@gmx.de> Date: Tue, 13 Jan 2009 13:41:45 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "O. Hartmann" References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de> In-Reply-To: <496C8A59.6090301@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Cc: Garrett Cooper , freebsd-x11 , Doug Barton , FreeBSD Current Subject: Re: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 12:48:28 -0000 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.