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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408201936.i7KJZw40003489>