sound/pcm/* bugs (was: Re: page fault panic tracked down
(selwakeuppri()) - really sound/pcm/*)
shoesoft at gmx.net
Fri Jan 16 12:22:46 PST 2004
On Fri, 2004-01-16 at 20:51, Stefan Ehmann wrote:
> On Fri, 2004-01-16 at 10:31, Don Lewis wrote:
> > On 15 Jan, Stefan Ehmann wrote:
> > > This time the system survived sysctl but as soon as sound playback
> > > starts the assertion in channel.c:978 gets triggered.
> > >
> > > Looks like setting up sound would be a good idea since there are
> > > probably more traps ahead.
> > Judging by all the arrows I just dug out of my back, I'd say you are
> > correct. Really enabling the lock assertion checks turned up quite a
> > few things, and I found some more locking problems by inspection.
> > 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'm not sure why this happened.
> I tried to increase vchans to 5 and got this on printed
> cnt 4, newcnt 1, busy 2
> However, I get same message when I try to play anything.
Just right after I sent the message I noticed that the sound started
working again. Probably because of some more sysctl vchan calls - but I
can't make out any deterministic behaviour yet. After some other sysctls
it stopped working again...
More information about the freebsd-current