From owner-freebsd-current Mon Nov 6 11:38:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA10359 for current-outgoing; Mon, 6 Nov 1995 11:38:25 -0800 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA10342 for ; Mon, 6 Nov 1995 11:37:48 -0800 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.12/8.6.9) id VAA14050; Mon, 6 Nov 1995 21:34:12 +0200 From: John Hay Message-Id: <199511061934.VAA14050@zibbi.mikom.csir.co.za> Subject: Re: Time problems To: bde@zeta.org.au (Bruce Evans) Date: Mon, 6 Nov 1995 21:34:12 +0200 (SAT) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG (FreeBSD-current) In-Reply-To: <199511031523.CAA11301@godzilla.zeta.org.au> from "Bruce Evans" at Nov 4, 95 02:23:25 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1877 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > >> Perhaps the 8254 clock is being accessed too fast. Try adding some delays > >> before each inb() and outb() in clock.c:getit(). Count to 100 or so to > >> get at least 1 usec delay. > > >I added "for(x=0;x<100;x++);" between the inb and outb instructions and now > >the 100 second delay takes 98-99 seconds. So this is now much closer. It is > >also being probed as a 90MHz processor now. So it looks like this helps. > > Are you sure it takes <= 99 seconds? I doubt that the hardware error is > more than 1 part in 1000. > > We need a more reliable method of slowing down i/o accesses iff necessary. > In getit(), it is probably acceptable to add some dummy i/o's. It may > only be necessary to add a delay between the back to back i/o's (after the > outb and before the first inb). Try that (add one or more inb(0x84)'s). I tried one and two dummy inb's there and it was better, but still below 99 seconds. Then I added an inb between the low and high inb's and then two inb's and that seems to do the trick for getit(). It now take a little more than 99 seconds for the 100 second delay. > > >I ran your program with the pentium timer disabled and regularly got > >negative numbers. The numbers vary, but things that I got was -6, -38, > >-44, -17, etc... > > You would need similar delays in microtime() for the non-pentium version > to work. Try adding such delays (`inb $0x84, %al' immediately after the > outb). I tried a few combinations up to two inb's after the outb and after the first inb, but I still get negative numbers. I also tried Garrett's program and apart from it coredumping sometimes the min value is always a negative number -99 and worse. On a more positive note, if I run with a "fixed up" getit() my cpu speed gets probed correctly and then the pentium clock seems to be fairly accurate. John -- John Hay -- John.Hay@csir.co.za