From owner-freebsd-current@FreeBSD.ORG Mon Jul 26 21:47:10 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 EB4F116A4CE for ; Mon, 26 Jul 2004 21:47:10 +0000 (GMT) Received: from lakermmtao07.cox.net (lakermmtao07.cox.net [68.230.240.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 756B343D45 for ; Mon, 26 Jul 2004 21:47:10 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao07.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040726214709.YYXP6416.lakermmtao07.cox.net@dolphin.local.net> for ; Mon, 26 Jul 2004 17:47:09 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.12.11/8.12.11) with ESMTP id i6QLl9SQ001138 for ; Mon, 26 Jul 2004 16:47:09 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.12.11/8.12.11/Submit) id i6QLl9B0001137 for freebsd-current@freebsd.org; Mon, 26 Jul 2004 16:47:09 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 26 Jul 2004 16:47:09 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: 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 Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2004 21:47:11 -0000 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). > > Within an else branch within the main while loop, we have: > > else { > timeout = (hz * sndbuf_getblksz(bs)) / > (sndbuf_getspd(bs) * sndbuf_getbps(bs)); > if (timeout < 1) > timeout = 1; > timeout = 1; > > Why the formulaic calculation of timeout, if it's simply going to be > unconditionally set to 1 immediately afterwards anyway? What's going > on here? > > 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. Perhaps a few other people might try it and see? I still don't know what to make of the earlier business with the setting of "timeout". Looks to me like something that just got overlooked in the course of a series of edits. -- Conrad J. Sabatier -- "In Unix veritas"