From owner-freebsd-current@FreeBSD.ORG Sat Jan 17 12:54:27 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 2B1B116A4CE for ; Sat, 17 Jan 2004 12:54:27 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 143ED43D2F for ; Sat, 17 Jan 2004 12:54:25 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i0HKsH7E051698; Sat, 17 Jan 2004 12:54:21 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401172054.i0HKsH7E051698@gw.catspoiler.org> Date: Sat, 17 Jan 2004 12:54:17 -0800 (PST) From: Don Lewis To: shoesoft@gmx.net In-Reply-To: <1074345038.1337.25.camel@shoeserv.freebsd> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 20:54:27 -0000 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 >> 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. 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. or this. > - 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.