sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*)

Stefan Ehmann shoesoft at
Sat Jan 17 05:10:55 PST 2004

On Sat, 2004-01-17 at 10:15, Don Lewis wrote:
> I think this problem can be caused by a transient malloc() M_NOWAIT
> failure.
> Changes in this version of the patch:
> 	When increasing blksz in chn_setblocksize(), increase the size
> 	of bufsoft before increasing bufhard, and decrease bufsoft after
> 	decreasing bufhard in an attempt to avoid the buffer overflow in
> 	feed_vchan_s16().
> 	Buffers are now allocated using M_WAITOK, requiring locks to
> 	be dropped for the malloc() calls.  This required adding a mutex
> 	parameter to sndbuf_remalloc().
> 	Locking order between parent and child channels is changed.  The
>         parent is now locked first and then the child.  The list of
>         children is protected by the parent's lock.  There are still
>         potential race conditions in the vchan creation/destruction code
>         because all the locks have to be dropped in order to call
>         malloc(), etc.
> 	Locking cleaned up to eliminate the need for MTX_RECURSE.
> 	A new mutex allocator for the channel mutexes was added that
> 	initializes the mutexes with the MTX_DUPOK flags so that multiple
> 	channel mutexes of the same type can be held at once.
> 	Locking simplification in dsp_ioctl().
> 	Added KASSERTs in chn_wrfeed().

Some more observations:

- I haven't run the patched kernel long enough to see if it actually
prevents panics.

- Sometimes when trying to open dsp it fails at the first attempt, but
works if I try again. I had similar experiences when I first used vchans
but these problems have been gone for long.

- This also seems to lock up one of the vchans each time this happens (I
haven't really tested this yet but I'm pretty sure). For instance, if I
try to set the number of vchans to anything lower than 3 right now it
fails saying device busy. My guess would be that those vchans were
locked but never unlocked for some reason.

- If I use esd as output device (e.g. for ogg123 because it doesn't work
properly with the default output) an I stop the player, it takes some
seconds before the sound actually stops playing (until the buffer is
written to dsp). This doesn't happen with unpatched pcm module.

More information about the freebsd-current mailing list