From owner-freebsd-current@FreeBSD.ORG Tue Jul 27 22:15:27 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 2A1A016A4D2 for ; Tue, 27 Jul 2004 22:15:27 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D1E43D54 for ; Tue, 27 Jul 2004 22:15:26 +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 i6RMF6jQ061016; Tue, 27 Jul 2004 15:15:10 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200407272215.i6RMF6jQ061016@gw.catspoiler.org> Date: Tue, 27 Jul 2004 15:15:06 -0700 (PDT) From: Don Lewis To: mat@cnd.mcgill.ca In-Reply-To: <20040727152327.GA92352@cnd.mcgill.ca> 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:15:27 -0000 On 27 Jul, Mathew Kanner wrote: > On Jul 26, John-Mark Gurney wrote: >> Conrad J. Sabatier wrote this message on Mon, Jul 26, 2004 at 16:35 -0500: >> > 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? >> >> Well, if you look at the annotations, that absolute set of timeout was >> added in rev 1.65 by cg with the comment: >> tweaks to reduce latency/pauses in output >> > > > I think this has been raised on the mailling list before. > IIRC, the logic for this is to check frequently for dead channels but > CG is the authoriy. My suspicion is that this change was made to reduce the consequences of lost wakeups from the interrupt routine. This would have been more of a problem when tsleep() was used in chn_sleep() and shouldn't be needed now that the top and bottom halves of the code use the channel lock and chn_sleep() uses msleep() to atomically release the lock and wait for the wakeup from the interrupt code. That said, setting timeout to 1 shouldn't hurt anything and will just waste a bit of CPU time. >> > 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; >> > } >> >> that was changed in rev1.52 (by cg also), and previously was just a check >> for count == 0.. >> >> So, I'd recommend a message off to cg and ask why he made this changes... The original version of the code always set timeout to 1 and looped on (count > 0), so count could never go negative. When the code was changed to set count to something larger than 1, count could go negative if (hz % timeout != 0), so the condition for setting CHN_F_DEAD had to be modified accordingly. My suspicion is that there is sometimes enough latency in executing the interrupt routine that the hardware DMA pointer is wrapping and chn_dmaupdate() is calculating delta as zero. This would cause chn_wrfeed() not to consume any data from the software buffer (and skip the wakeup()), which might be enough to cause the chn_write() to time out while waiting for space to become available in the software buffer. It would be interesting to enable the debug code in chn_dmaupdate(), and add (delta == 0) as a condition to trigger the device_printf(). The bigger question is what is the cause of the latency ...