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

[Don Lewis]

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.