From owner-freebsd-current@FreeBSD.ORG Tue Jul 27 22:22:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 448AB16A4D2 for ; Tue, 27 Jul 2004 22:22:12 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F13EB43D66 for ; Tue, 27 Jul 2004 22:22:11 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i6RMLvDa061031; Tue, 27 Jul 2004 15:22:01 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200407272222.i6RMLvDa061031@gw.catspoiler.org> Date: Tue, 27 Jul 2004 15:21:57 -0700 (PDT) From: Don Lewis To: conrads@cox.net In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: Questionable code in sys/dev/sound/pcm/channel.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2004 22:22:12 -0000 On 27 Jul, Conrad J. Sabatier wrote: > > On 26-Jul-2004 Conrad J. Sabatier wrote: >> >> On 26-Jul-2004 Conrad J. Sabatier wrote: >>> I'm a little perplexed at the following bit of logic in chn_write() >>> (which is where the "interrupt timeout, channel dead" messages are >>> being generated). > > [snip] > >>> Also, at the end of the function: >>> >>> if (count <= 0) { >>> c->flags |= CHN_F_DEAD; >>> printf("%s: play interrupt timeout, channel dead\n", >>> c->name); >>> } >>> >>> return ret; >>> } >>> >>> Could it be that the conditional test is wrong here? Perhaps >>> we should be using (count < 0) instead? >> >> I'm now running a kernel built with this last conditional test >> changed to "if (count < 0)" and sound is still working OK. Have yet >> to see if this eliminates the interrupt timeout messages. > > Well, that was a failure. :-) Didn't see any timeout error messages, > but the device still died eventually, nonetheless. I've since changed > back to the original code. That's an interesting data point. At this point I'd start looking at the driver code for your sound hardware. I suspect that the driver interrupt code is either no longer seeing interrupts, or it is no longer calling chn_intr().