From owner-freebsd-current@FreeBSD.ORG Fri Jan 16 11:52:08 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 C42AC16A4D0 for ; Fri, 16 Jan 2004 11:52:08 -0800 (PST) Received: from email07.aon.at (WARSL402PIP8.highway.telekom.at [195.3.96.97]) by mx1.FreeBSD.org (Postfix) with SMTP id 1500E43D45 for ; Fri, 16 Jan 2004 11:52:06 -0800 (PST) (envelope-from shoesoft@gmx.net) Received: (qmail 341326 invoked from network); 16 Jan 2004 19:51:47 -0000 Received: from m119p020.dipool.highway.telekom.at (HELO ?62.46.4.212?) ([62.46.4.212]) (envelope-sender ) by 172.18.5.236 (qmail-ldap-1.03) with SMTP for ; 16 Jan 2004 19:51:47 -0000 From: Stefan Ehmann To: Don Lewis In-Reply-To: <200401160931.i0G9VV7E044831@gw.catspoiler.org> References: <200401160931.i0G9VV7E044831@gw.catspoiler.org> Content-Type: text/plain Message-Id: <1074282714.8095.39.camel@shoeserv.freebsd> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 16 Jan 2004 20:51:55 +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: Fri, 16 Jan 2004 19:52:08 -0000 On Fri, 2004-01-16 at 10:31, Don Lewis wrote: > On 15 Jan, Stefan Ehmann wrote: > > This time the system survived sysctl but as soon as sound playback > > starts the assertion in channel.c:978 gets triggered. > > > > Looks like setting up sound would be a good idea since there are > > probably more traps ahead. > > Judging by all the arrows I just dug out of my back, I'd say you are > correct. Really enabling the lock assertion checks turned up quite a > few things, and I found some more locking problems by inspection. > > The following patch seems to be at least somewhat stable on my machine. > I did get one last panic in feed_vchan_s16() that I haven't been able to > reproduce since I added some more sanity checks. Since it was caught in > the interrupt routine, it's not easy to track down to its root cause. I > think there is still a bug somewhere, but it's not easy to trigger. Good news: no panic so far. Bad news: sound stopped working after some time (Chances are that the system would have panicked on the unpatched kernel at the same time) /dev/dsp: Operation not supported by device I'm not sure why this happened. I tried to increase vchans to 5 and got this on printed cnt 4, newcnt 1, busy 2 However, I get same message when I try to play anything.