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

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)

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