Maxim Sobolev wrote:
> John Baldwin wrote:
> > > The same is here (OPL3-SA driver on Toshiba Satellite Pro 445CDX notebook).
> > > I found that after reverting the following deltas (jhb's 10 August commit)
> > > sound starts working again:
> > That's a rather large commit. Is this the ast() fixup? Is the process that
> > has the sound device open hung? Is it stuck in a wait channel? If so, can you
> > do a ps and find the wait channel? Is it chewing up large amounts of CPU time?
> > Has it exited with a signal?
> Somebody tracked it down to kern_synch.c,v 1.154 and I'm confirming that reverting
> this delta indeed fixes the problem. The process in question hangs and doesn't
> respond to any signals (SIGKILL included). Following is the relevant piece of `ps
> axl' output:
> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
> 0 275 267 0 -8 0 41496 212 - R+ v0 0:00,74 madplay /cdr
> Please note that even though madplay above is in the `RUN' state it doesn't consume
> any CPU time.
> Please let me know if any additional information would be necessary.
FYI: the same problem affects another my -current machine with sb16 card, with exactly
the same symptoms, i.e. I hear 0.5 second or so of audio, then it halts and process
hangs in the RUN state not responding to signals.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message