From owner-cvs-src@FreeBSD.ORG Fri Apr 30 22:54:28 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E26A316A4CE; Fri, 30 Apr 2004 22:54:28 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5403E43D46; Fri, 30 Apr 2004 22:54:28 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i415sQ5v025065; Sat, 1 May 2004 15:54:26 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i415sNI2004125; Sat, 1 May 2004 15:54:25 +1000 Date: Sat, 1 May 2004 15:54:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mike Silbersack In-Reply-To: <20040430220507.B8726@odysseus.silby.com> Message-ID: <20040501154619.W19822@gamplex.bde.org> References: <200404272003.i3RK3RFZ048001@repoman.freebsd.org> <20040430220507.B8726@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: John Baldwin Subject: Re: cvs commit: src/sys/i386/isa clock.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2004 05:54:29 -0000 On Fri, 30 Apr 2004, Mike Silbersack wrote: > On Tue, 27 Apr 2004, John Baldwin wrote: > > > jhb 2004/04/27 13:03:27 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/isa clock.c > > Log: > > - The i8254 uses IRQ 0, not IRQ 8. Correct i8254_intsrc to reference the > > correct interrupt source. > > - Cache a pointer to the i8254_intsrc's pending method to avoid several > > pointer indirections in i8254_get_timecount(). > > Does this fix a bug with clock handling? I ask because my system's clock > has been running fast recently, and I haven't had time to investigate why > that is occuring... This fixes breakage of the i8254 timecounter last December by the new interrupt code. Counter overflow was not detected properly, so there was sometimes a false negative which caused the clock to jump by 1/HZ seconds. I think false positives were also possible, and the jump for fals negatives made the clock run fast. However, the i8254 timecounter is rarely used on new systems. It is now used mainly on SMP systems without acpi. Bruce