From owner-freebsd-current@FreeBSD.ORG Sat Jan 17 11:22:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0F3116A4CF for ; Sat, 17 Jan 2004 11:22:20 -0800 (PST) Received: from email05.aon.at (WARSL402PIP4.highway.telekom.at [195.3.96.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 5C63E43D53 for ; Sat, 17 Jan 2004 11:22:17 -0800 (PST) (envelope-from shoesoft@gmx.net) Received: (qmail 92320 invoked from network); 17 Jan 2004 19:22:00 -0000 Received: from m084p003.dipool.highway.telekom.at (HELO ?62.46.0.99?) ([62.46.0.99]) (envelope-sender ) by qmail5rs.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 17 Jan 2004 19:22:00 -0000 From: Stefan Ehmann To: Don Lewis In-Reply-To: <1074345038.1337.25.camel@shoeserv.freebsd> References: <200401170915.i0H9FD7E047822@gw.catspoiler.org> <1074345038.1337.25.camel@shoeserv.freebsd> Content-Type: text/plain Message-Id: <1074367329.2465.6.camel@shoeserv.freebsd> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 17 Jan 2004 20:22:10 +0100 Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org Subject: Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 19:22:21 -0000 On Sat, 2004-01-17 at 14:10, 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. > > - 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. Seems like some of my interpretation were wrong. The failing at the first try opening /dev/dsp seems to be related to the last point. If output is sent to esd by ogg123 (e.g) is terminated but sound is played for some more seconds. If the next file is opened the device is still busy. Still have no clue why there are some non-used vchans busy.