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

Reply via email to