From owner-freebsd-bugs Thu May 18 23:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id B2A2237BC1B for ; Thu, 18 May 2000 23:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA35403; Thu, 18 May 2000 23:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 18 May 2000 23:20:01 -0700 (PDT) Message-Id: <200005190620.XAA35403@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/18598 Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/18598; it has been noted by GNATS. From: Bruce Evans To: phk@FreeBSD.ORG Cc: y.grossel@hexanet.fr, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/18598 Date: Fri, 19 May 2000 16:12:36 +1000 (EST) On Thu, 18 May 2000 phk@FreeBSD.ORG wrote: > Synopsis: Incessant messages "microuptime() went backwards" > > State-Changed-From-To: open->closed > State-Changed-By: phk > State-Changed-When: Thu May 18 15:19:07 PDT 2000 > State-Changed-Why: > We resolved this in email to be the APM bios changing the frequency > of the i8254 under our feet. Nothing much we can do in that case. Um, we can easily make it jump forwards instead of backwards. From i386/isa/clock.c: > static u_int > i8254_get_timecount(struct timecounter *tc) > { > u_int count; ^^^^^ > ... > low = inb(TIMER_CNTR0); > high = inb(TIMER_CNTR0); > count = timer0_max_count - ((high << 8) | low); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This sometimes underflows to a large unsigned value if something changes the actual maximum count to a value smaller than timer0_max_count underneath us. We really want `count' to be a small negative value instead of a large positive one. > if (count < i8254_lastcount || ^^^^^^^^^^^^^^^^^^^^^^^ Since both variables in the comparison are unsigned, this doesn't detect the underflow. Possible workarounds: 1) Used signed ints more and/or 2) replace the large unsigned counts by 0. 3) Whenever a large unsigned count is detected, adjust timer0_max_count and associated variables to match it, or adjust timer0_max_count to match the actual hardware max count (which was presumably adjusted by APM), or adjust the hardware max count to match the original timer0_max_count. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message