From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 08:39:44 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 A1DA516A506 for ; Thu, 8 Jan 2004 08:39:44 -0800 (PST) Received: from email03.aon.at (WARSL402PIP6.highway.telekom.at [195.3.96.93]) by mx1.FreeBSD.org (Postfix) with SMTP id DA67443D46 for ; Thu, 8 Jan 2004 08:39:41 -0800 (PST) (envelope-from shoesoft@gmx.net) Received: (qmail 288580 invoked from network); 8 Jan 2004 16:39:40 -0000 Received: from m126p001.dipool.highway.telekom.at (HELO ?62.46.5.161?) ([62.46.5.161]) (envelope-sender ) by qmail3rs.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 8 Jan 2004 16:39:40 -0000 From: Stefan Ehmann To: Don Lewis In-Reply-To: <200401080958.i089wr7E019126@gw.catspoiler.org> References: <200401080958.i089wr7E019126@gw.catspoiler.org> Content-Type: text/plain Message-Id: <1073579992.722.6.camel@shoeserv.freebsd> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 08 Jan 2004 17:39:53 +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: Thu, 08 Jan 2004 16:39:44 -0000 On Thu, 2004-01-08 at 10:58, Don Lewis wrote: > On 7 Jan, Stefan Ehmann wrote: > 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. Again - no luck. This time even disabling vchans doesn't help. No sound at all. The code seems to be really tricky. I get: kernel: pcm0:virtual:0: play interrupt timeout, channel dead kernel: pcm0:play:0: play interrupt timeout, channel dead each try to change vchans aftet that results in a kernel: x: 2 (last message repeated 9 times) At least our assumption that the panic only occurs with vchans enabled seems to be true (~ 8 hrs uptime).