sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*)

Don Lewis truckman at FreeBSD.org
Thu Jan 8 00:24:33 PST 2004


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.

I think it is caused by the vchans, but it will also depend on where
things land in the kernel heap.  Sometimes you get lucky and sometimes
not.

I think the problem with my patch is that the CHN_F_RUNNING flag isn't
set on the channel that I thought it was, so the desired interrupt
routine isn't getting run.  I'm having a real hard time understanding
how this stuff all hangs together, which is making it difficult to do a
proper fix.




More information about the freebsd-current mailing list