From owner-freebsd-current@FreeBSD.ORG Sat Jan 17 05:10:55 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 F37B216A4CE for ; Sat, 17 Jan 2004 05:10:54 -0800 (PST) Received: from email07.aon.at (WARSL402PIP8.highway.telekom.at [195.3.96.97]) by mx1.FreeBSD.org (Postfix) with SMTP id E9B0143D55 for ; Sat, 17 Jan 2004 05:10:51 -0800 (PST) (envelope-from shoesoft@gmx.net) Received: (qmail 282634 invoked from network); 17 Jan 2004 13:10:29 -0000 Received: from m084p020.dipool.highway.telekom.at (HELO ?62.46.0.116?) ([62.46.0.116]) (envelope-sender ) by 172.18.5.236 (qmail-ldap-1.03) with SMTP for ; 17 Jan 2004 13:10:29 -0000 From: Stefan Ehmann To: Don Lewis In-Reply-To: <200401170915.i0H9FD7E047822@gw.catspoiler.org> References: <200401170915.i0H9FD7E047822@gw.catspoiler.org> Content-Type: text/plain Message-Id: <1074345038.1337.25.camel@shoeserv.freebsd> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 17 Jan 2004 14:10:38 +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 13:10:55 -0000 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.