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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1074345038.1337.25.camel>