Re: pcm(4) related panic

From: Artur Poplawski <artur_at_szuruburu.neostrada.pl>
Date: Wed, 26 Nov 2003 14:59:24 +0100
Mathew Kanner <mat_at_cnd.mcgill.ca> wrote:

> On Nov 25, Don Lewis wrote:
> > On 25 Nov, Don Lewis wrote:
> > > On 25 Nov, Artur Poplawski wrote:
> > >> Artur Poplawski <artur_at_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 _at_ \   
> > >>>         /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
Received on Wed Nov 26 2003 - 04:58:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:31 UTC