From owner-freebsd-current@FreeBSD.ORG Tue Nov 25 14:36:34 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 0E99D16A4CF for ; Tue, 25 Nov 2003 14:36:33 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2725243FEA for ; Tue, 25 Nov 2003 14:36:31 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hAPMaLeF011517; Tue, 25 Nov 2003 14:36:25 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200311252236.hAPMaLeF011517@gw.catspoiler.org> Date: Tue, 25 Nov 2003 14:36:21 -0800 (PST) From: Don Lewis To: artur@szuruburu.neostrada.pl In-Reply-To: <200311252223.hAPMMueF011485@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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: Tue, 25 Nov 2003 22:36:34 -0000 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.