From owner-freebsd-current@FreeBSD.ORG Fri Jan 16 13:22:18 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 976F416A4CE for ; Fri, 16 Jan 2004 13:22:18 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1278243D46 for ; Fri, 16 Jan 2004 13:22:05 -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 i0GLLv7E046623; Fri, 16 Jan 2004 13:22:01 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401162122.i0GLLv7E046623@gw.catspoiler.org> Date: Fri, 16 Jan 2004 13:21:57 -0800 (PST) From: Don Lewis To: shoesoft@gmx.net In-Reply-To: <1074282714.8095.39.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: Fri, 16 Jan 2004 21:22:18 -0000 On 16 Jan, Stefan Ehmann wrote: > On Fri, 2004-01-16 at 10:31, Don Lewis wrote: >> 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 think this is unrelated. Maybe something I broke. > 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 I'll go digging through the code later to see I can find the problem. I think I might understand the reason for the panic that I got last night. I think chn_setblocksize() was increasing the buffer size and an interrupt was serviced during the sndbuf_remalloc() call while the lock was dropped for the malloc() call. I thought of a way to fix this and will crank out a new patch. I also want to take a closer look at the parent/child locking relationships.