From owner-freebsd-current Sun Feb 17 15:28:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id B264337B402; Sun, 17 Feb 2002 15:28:07 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g1HNRuA01838; Sun, 17 Feb 2002 15:27:56 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200202172327.g1HNRuA01838@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Michael Smith , Poul-Henning Kamp , Bruce Evans , freebsd-current@FreeBSD.ORG Subject: Re: ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? ) In-reply-to: Your message of "Sun, 17 Feb 2002 15:18:01 PST." <200202172318.g1HNI1I02804@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Feb 2002 15:27:56 -0800 From: Michael Smith 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 > > :I would like to see "the PIIX problem" caught on camera, personally. > :We're aware of one errata for it already, and we work around it. If > :there's another problem, or ideally if someone has some relatively quick > :code to test it, that would be much better. > > Holy shit. We are screwed. It's a free-running counter with NO > synchronization whatsoever. None. Zip. Zero. Sounds like we need to smack whoever made your chipset as well. Intel learned their lesson (finally) with later revisions of the PIIX4. I'm guessing you're running this against a ServerWorks system. > It looks like the hardware is using an adder with fast carry > (basically a forward looking carry calculation), which can result in a > later bit being set before the earlier bits are updated. However, if > this is the case then it is almost certain that you can catch the ripple > as well, or even catch the counter while the bit states are changing. Lame. Incredibly lame. > The only way to get a guarenteed accurate sample under these circumstances > is something like this, where you calculate a mask that results in > reasonable accurancy without causing the cpu to go into an infinite > loop and then read the timer until you get two samples that are the same: > > u1 = TIMER_READ; > u2 = TIMER_READ; > while ((u1 ^ u2) & 0xFFFFFFF0) { <<<<<<<< mask must be chosen > u1 = u2; > u2 = TIMER_READ; > } > return(u2 & 0xFFFFFFF0) <<<<<<<< same mask here > > Here are some more from my debug output: Interesting. This would be reasonably robust in the ripple-counter case we have to deal with on the old PIIX4. Have you tried implementing the above yet, or measuring how much it costs? At any rate, please let me know for sure whether you're running on a ServerWorks board, and I'll see if I can't find a Big Stick to hit them with. Thanks, Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message