Date: Fri, 20 Aug 2004 12:35:58 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: conrads@cox.net Cc: freebsd-current@FreeBSD.org Subject: Re: pcm timeout (debug output from snd_ich driver) Message-ID: <200408201936.i7KJZw40003489@gw.catspoiler.org> In-Reply-To: <20040818193348.7633da35@dolphin.local.net>
index | next in thread | previous in thread | raw e-mail
On 18 Aug, Conrad J. Sabatier wrote:
> On Wed, 18 Aug 2004 19:24:58 -0500
> "Conrad J. Sabatier" <conrads@cox.net> wrote:
>
>> OK, I enabled debug output in the sound driver in the hopes of finding
>> out a little bit more about what's going on with these insufferable
>> pcm timeouts using the snd_ich driver.
>
> Also, I've been meaning to ask: is there no possibility of somehow
> recovering gracefully from this condition so that the sound device might
> still be useable (similar to the recovery from ata and other timeouts),
> rather than leaving the device flat-out broken?
Only if we know where it is getting lost.
Try adding a three of global integers variables to ich.c. Increment one
of them on entry to inch_intr(), and increment the others in the area of
the code that calls chn_intr().
debug2++;
if (ch->run) {
debug3++;
chn_intr(ch->channel);
}
Make the variables readable via sysctl with something like the
following:
SYSCTL_INT(_debug_ich, OID_AUTO, debug1, CTLFLAG_RD,
&debug1, 0, "Number of times ich_intr() called");
Run the sound code until it hangs, and then use sysctl to see which if
any of these variables continue to increment.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408201936.i7KJZw40003489>