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

Don Lewis truckman at
Sat Jan 17 12:54:27 PST 2004

On 17 Jan, Stefan Ehmann wrote:
> 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.

I haven't seen this ...

> - 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.

or this.

> - 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.

I have seen this.  I've been testing with wavplay and when I ^c the
player it can take quite a while before the sound stops playing and the
player exits.  I think it is sitting in chn_flush(), but I haven't
looked closely at it.

More information about the freebsd-current mailing list