Date: Fri, 16 Jan 2004 13:21:57 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: shoesoft@gmx.net Cc: current@FreeBSD.org Subject: Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*) Message-ID: <200401162122.i0GLLv7E046623@gw.catspoiler.org> In-Reply-To: <1074282714.8095.39.camel@shoeserv.freebsd>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401162122.i0GLLv7E046623>