From nobody@FreeBSD.ORG  Tue May 16 05:35:35 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 4765437B77B; Tue, 16 May 2000 05:35:35 -0700 (PDT)
Message-Id: <20000516123535.4765437B77B@hub.freebsd.org>
Date: Tue, 16 May 2000 05:35:35 -0700 (PDT)
From: y.grossel@hexanet.fr
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: Incessant messages "microuptime() went backwards"
X-Send-Pr-Version: www-1.0

>Number:         18598
>Category:       kern
>Synopsis:       Incessant messages "microuptime() went backwards"
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May 16 05:40:00 PDT 2000
>Closed-Date:    Thu May 18 15:19:07 PDT 2000
>Last-Modified:  Thu May 18 23:20:00 PDT 2000
>Originator:     Yann GROSSEL
>Release:        4.0 STABLE
>Organization:
>Environment:
FreeBSD aldebaran.x.tld 4.0-STABLE FreeBSD 4.0-STABLE #0: Mon May 15 18:38:42 CEST 2000     root@aldebaran.x.tld:/usr/obj/usr/src/sys/ALDEBARAN  i386

>Description:

While doing intense disk operations (using pax) the kernel suddenly started
to log infinite number of similar messages :

May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.702791 -> 5991,661169)
May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.702791 -> 5991,666666)
May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.702791 -> 5991,694225)
May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.711393 -> 5991,-694696436)

and so on until reboot.

>How-To-Repeat:
Don't know
>Fix:
-

>Release-Note:
>Audit-Trail:

From: Joe Karthauser <joe@pavilion.net>
To: y.grossel@hexanet.fr
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/18598: Incessant messages "microuptime() went backwards"
Date: Tue, 16 May 2000 20:10:57 +0100

 > May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.702791 -> 5991,661169)
 > May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.702791 -> 5991,666666)
 > May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.702791 -> 5991,694225)
 > May 15 18:03:11 aldebaran /kernel: microuptime() went backwards (5991.711393 -> 5991,-694696436)
 
 I got this too last night when running postgresql for the first time:
 
 FreeBSD genius.systems.pavilion.net 5.0-CURRENT FreeBSD 5.0-CURRENT #69: Tue May  2 14:12:50 BST 2000     joe@genius.systems.pavilion.net:/usr/src/sys/compile/GENIUS  i386
 
 Joe
 
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. 

From: Bruce Evans <bde@zeta.org.au>
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
 
 
>Unformatted:
