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). >Received on Thu Jan 08 2004 - 11:37:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:37 UTC