On 16 Jan, Stefan Ehmann wrote: > On Fri, 2004-01-16 at 10:31, Don Lewis wrote: >> The following patch seems to be at least somewhat stable on my machine. >> I did get one last panic in feed_vchan_s16() that I haven't been able to >> reproduce since I added some more sanity checks. Since it was caught in >> the interrupt routine, it's not easy to track down to its root cause. I >> think there is still a bug somewhere, but it's not easy to trigger. > > Good news: no panic so far. > > Bad news: sound stopped working after some time (Chances are that the > system would have panicked on the unpatched kernel at the same time) > > /dev/dsp: Operation not supported by device I think this is unrelated. Maybe something I broke. > I'm not sure why this happened. > > I tried to increase vchans to 5 and got this on printed > cnt 4, newcnt 1, busy 2 I'll go digging through the code later to see I can find the problem. I think I might understand the reason for the panic that I got last night. I think chn_setblocksize() was increasing the buffer size and an interrupt was serviced during the sndbuf_remalloc() call while the lock was dropped for the malloc() call. I thought of a way to fix this and will crank out a new patch. I also want to take a closer look at the parent/child locking relationships.Received on Fri Jan 16 2004 - 12:22:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:38 UTC