sound/pcm/* bugs (was: Re: page fault panic tracked down
(selwakeuppri()) - really sound/pcm/*)
truckman at FreeBSD.org
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
>> 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
>> 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.
> - 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