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

Don Lewis truckman at
Thu Jan 8 12:37:12 PST 2004

On  8 Jan, Stefan Ehmann wrote:
> 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)

I don't understand why it is failing that way.  Are you sure that the
previous change to chn_intr() was backed out?

> At least our assumption that the panic only occurs with vchans enabled
> seems to be true (~ 8 hrs uptime).

More information about the freebsd-current mailing list