From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 00:24:33 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 2F30916A4CE for ; Thu, 8 Jan 2004 00:24:33 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CFD543D68 for ; Thu, 8 Jan 2004 00:24:31 -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 i088ON7E018946; Thu, 8 Jan 2004 00:24:27 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401080824.i088ON7E018946@gw.catspoiler.org> Date: Thu, 8 Jan 2004 00:24:23 -0800 (PST) From: Don Lewis To: shoesoft@gmx.net In-Reply-To: <1073510185.707.8.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: Thu, 08 Jan 2004 08:24:33 -0000 On 7 Jan, Stefan Ehmann wrote: > On Wed, 2004-01-07 at 21:15, Don Lewis wrote: >> Try the following patch. I won't guarantee that you still won't see >> panics, but at least it should panic cleanly instead of stomping on some >> innocent block of memory that corrupts data or some critical structure >> that will trigger a mysterious and hard to debug panic at some later >> time. >> >> The reason for changing the KASSERT to a test and an explicit call to >> panic() is to make sure that the error is always caught because the >> sound code is typically not compiled with INVARIANTS, so the KASSERT >> will typically be ignored. The vchan stuff really needs a proper fix, >> but I don't understand the sound code well enough. > > Nice patch - unfortunately sound doesn't work any longer with vchans > enabled (which is set to 4 at boot time here). > > I get "pcm0:virtual:0: play interrupt timeout, channel dead" whenever I > try to play anything. > > However, if I do "hw.snd.pcm0.vchans: 4 -> 0" it works nice again. > > I'll probably try later if I'm able to get a panic with vchans disabled > (Especially those that had - at least not in an obvious way - any sound > stuff in backtrace) > > If not, maybe the panic gets triggered if for some reason the dsp device > isn't ready again after a song played and a new virtual dsp device is > opened and vchan code gets in action (combined with other bad things). > > It can't be vchans alone because I just had three mpg123s open and they > just played fine. I think it is caused by the vchans, but it will also depend on where things land in the kernel heap. Sometimes you get lucky and sometimes not. I think the problem with my patch is that the CHN_F_RUNNING flag isn't set on the channel that I thought it was, so the desired interrupt routine isn't getting run. I'm having a real hard time understanding how this stuff all hangs together, which is making it difficult to do a proper fix.