From owner-freebsd-current Sun Feb 17 12:21: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6602337B433 for ; Sun, 17 Feb 2002 12:21:01 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id g1HKHtN05682; Sun, 17 Feb 2002 21:17:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? In-Reply-To: Your message of "Sun, 17 Feb 2002 18:54:13 +1100." <20020217184436.M934-100000@gamplex.bde.org> Date: Sun, 17 Feb 2002 21:17:54 +0100 Message-ID: <5680.1013977074@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020217184436.M934-100000@gamplex.bde.org>, Bruce Evans writes: >> This occurs both with and without the gettimeofday Giant-removal patch, so >> I am fairly sure it has nothing to do with any of my current work. This is >> running -current on a DELL2550 (2xCPUs), compiled with the SMP option. The Gian removal doesn't come anywhere near this. >The fact that the timecounter usually goes backwards by about 0.68 seconds >is probably significant, but I can't quite explain it. >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Well: 2^32 / 3579545 = 1199.86 seconds. 2^24 / 3579545 = 4.68 seconds. So even assuming that ACPI reported a wrong width, four seconds should still be enough to prevent a wraparound even though we cycle through the timecounter ring in one second. >I just wrote the following fix for some of the overflow problems. It is true that if a process is not running for arbitrary long time the timecounter may be modified underneat it, and bruce's patch is actually a pretty elegant solution for that case. By all means try it. I have had one other report of a similar problem, with the added information that changing to the TSC or i8254 instead of PIXX made it go away so I am not entirely convinced this is really what we are looking for in this case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message