Date: Sat, 17 Jan 2004 14:10:38 +0100 From: Stefan Ehmann <shoesoft@gmx.net> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*) Message-ID: <1074345038.1337.25.camel@shoeserv.freebsd> In-Reply-To: <200401170915.i0H9FD7E047822@gw.catspoiler.org> References: <200401170915.i0H9FD7E047822@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1074345038.1337.25.camel>