From owner-freebsd-current@FreeBSD.ORG Wed Nov 26 05:58:57 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2683716A4CE; Wed, 26 Nov 2003 05:58:57 -0800 (PST) Received: from mta1.tpinternet.pl (outgoing.tpinternet.pl [193.110.120.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1788843FF5; Wed, 26 Nov 2003 05:58:55 -0800 (PST) (envelope-from artur@szuruburu.neostrada.pl) Received: from kaszanka (xu93.neoplus.adsl.tpnet.pl [80.54.114.93]) by mta1.tpinternet.pl (Postfix) with ESMTP id EB0C5AC26; Wed, 26 Nov 2003 14:58:49 +0100 (CET) Date: Wed, 26 Nov 2003 14:59:24 +0100 From: Artur Poplawski To: mat@cnd.mcgill.ca Message-Id: <20031126145924.54d8fdbe.artur@szuruburu.neostrada.pl> In-Reply-To: <20031126074110.GD10278@cnd.mcgill.ca> References: <200311252223.hAPMMueF011485@gw.catspoiler.org> <200311252236.hAPMaLeF011517@gw.catspoiler.org> <20031126074110.GD10278@cnd.mcgill.ca> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: truckman@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: pcm(4) related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 13:58:57 -0000 Mathew Kanner wrote: > On Nov 25, Don Lewis wrote: > > On 25 Nov, Don Lewis wrote: > > > On 25 Nov, Artur Poplawski wrote: > > >> Artur Poplawski wrote: > > >> > > >>> Hello, > > >>> > > >>> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic > > >>> like this: > > > > > >>> Sleeping on "swread" with the following non-sleepable locks held: > > >>> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ > > >>> /usr/src/sys/dev/sound/pcm/dsp.c:146 > > > > > > This enables the panic. > > > > > >>> panic: sleeping thread (pid 583) owns a non-sleepable lock > > > > > > Then the panic happens when another thread tries to grab the mutex. > > > > > > > > > The problem is that the pcm code attempts to hold a mutex across a call > > > to uiomove(), which can sleep if the userland buffer that it is trying > > > to access is paged out. Either the buffer has to be pre-wired before > > > calling getchns(), or the mutex has to be dropped around the call to > > > uiomove(). The amount of memory to be wired should be limited to > > > 'sz' as calculated by chn_read() and chn_write(), which complicates the > > > logic. Dropping the mutex probably has other issues. > > > > Following up to myself ... > > > > It might be safe to drop the mutex for the uiomove() call if the code > > set flags to enforce a limit of one reader and one writer at a time to > > keep the code from being re-entered. The buffer pointer manipulations > > in sndbuf_dispose() and sndbuf_acquire() would probably still have to be > > protected by the mutex. If this can be made to work, it would probably > > be preferable to wiring the buffer. It would have a lot less CPU > > overhead, and would work better with large buffers, which could still be > > allowed to page normally. > > Don, > I never would have suspected that uio might sleep and panic, > thanks for the clue. > > Artur, > Could you try the attached patch. I've tried the patch -- and it works great! :-) I was unable to trigger the panic with the patch applied, although I tried really hard -- so I guess the problem is solved. Mat and Don, I'm really very thankful for your help. Best regards, Artur