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.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message