From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 09:15:43 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 BA5BD16A4CE; Thu, 8 Jan 2004 09:15:43 -0800 (PST) Received: from hak.cnd.mcgill.ca (hak.cnd.mcgill.ca [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 976B343D64; Thu, 8 Jan 2004 09:15:41 -0800 (PST) (envelope-from mat@hak.cnd.mcgill.ca) Received: from hak.cnd.mcgill.ca (localhost [127.0.0.1]) by hak.cnd.mcgill.ca (8.12.9/8.12.8) with ESMTP id i08HCG15045956; Thu, 8 Jan 2004 12:12:16 -0500 (EST) (envelope-from mat@hak.cnd.mcgill.ca) Received: (from mat@localhost) by hak.cnd.mcgill.ca (8.12.9/8.12.8/Submit) id i08HCGwo045955; Thu, 8 Jan 2004 12:12:16 -0500 (EST) Date: Thu, 8 Jan 2004 12:12:15 -0500 From: Mathew Kanner To: Don Lewis Message-ID: <20040108171215.GE38657@cnd.mcgill.ca> References: <1073510185.707.8.camel@shoeserv.freebsd> <200401080958.i089wr7E019126@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401080958.i089wr7E019126@gw.catspoiler.org> User-Agent: Mutt/1.4.1i Organization: I speak for myself, operating in Montreal, CANADA X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hak.cnd.mcgill.ca cc: cg@freebsd.org cc: current@freebsd.org cc: shoesoft@gmx.net cc: orion@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 17:15:43 -0000 On Jan 08, Don Lewis wrote: > 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. > > Some other wierdness that I noticed is that if one of the > chn_setblocksize() is called for one of the vchans, vchan_setblocksize() > will get called, which will call chn_notify(parent, CHN_N_BLOCKSIZE). > When this happens, the parent will interate over all of its children > looking for the one with the minimum bufhard blksz. It will then call > chn_setblocksize() on itself, and chn_setblocksize() will call > sndbuf_remalloc() on its bufsoft, which will set reallocate the buffer > with the size (blkcnt * blksz). If this channel is the parent vchan and > the new size of bufsoft is smaller than the size of bufhard (which never > gets reallocated), feed_vchan_s16() will write past the end of bufsoft > and things will go boom sometime later. > > Try the patch below in place of my previous patch. As you might guess, > I'm grasping at straws. > Hello Don, I'm joining this discussion late and I dont understand the circumstances that cause the panic. Is it reproduceable with by a regular user? Anyway, the area which you are working (vchans, feeders, etc) is extremely confusing to me but I will spend some time with it this weekend. I think Orion might be a good person to ask about the role of buffers and channels, I've cc'ed him with this e-mail. --Mat -- Any idiot can face a crisis; it is this day-to-day living that wears you out. - Chekhov