Date: Tue, 25 Nov 2003 14:22:56 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: artur@szuruburu.neostrada.pl Cc: freebsd-current@FreeBSD.org Subject: Re: pcm(4) related panic Message-ID: <200311252223.hAPMMueF011485@gw.catspoiler.org> In-Reply-To: <20031125223443.45cdfae3.artur@szuruburu.neostrada.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 Nov, Artur Poplawski wrote: > Artur Poplawski <artur@szuruburu.neostrada.pl> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311252223.hAPMMueF011485>