Date: Wed, 07 Jan 2004 22:16:26 +0100 From: Stefan Ehmann <shoesoft@gmx.net> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*) Message-ID: <1073510185.707.8.camel@shoeserv.freebsd> In-Reply-To: <200401072015.i07KFl7E017500@gw.catspoiler.org> References: <200401072015.i07KFl7E017500@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1073510185.707.8.camel>