From nobody@FreeBSD.ORG Sun May 16 12:52:09 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 1464B1512C; Sun, 16 May 1999 12:52:09 -0700 (PDT)
Message-Id: <19990516195209.1464B1512C@hub.freebsd.org>
Date: Sun, 16 May 1999 12:52:09 -0700 (PDT)
From: sobomax@altavista.net
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: On fast machines kernel reports negative i586_bzero bandwith values due to datatype overflow
X-Send-Pr-Version: www-1.0

>Number:         11736
>Category:       kern
>Synopsis:       On fast machines kernel reports negative i586_bzero bandwith values due to datatype overflow
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 16 13:00:01 PDT 1999
>Closed-Date:    Wed Aug 25 15:03:50 PDT 1999
>Last-Modified:  Wed Aug 25 15:10:02 PDT 1999
>Originator:     Maxim Sobolev
>Release:        4.0-CURRENT
>Organization:
Vega International Capital
>Environment:
>Description:
On the fast machine with lot of cache (K6-2 250MHz, 1024KBcache respectevly
in my case) i586_bzero bandwith in bytes may exceed 2^31 (signed long
datatype maximum value - i.e >  2.147.483.648 bytes/s) and kernel in
verbose mode will report negative bandwith.
>How-To-Repeat:
1. Take a relatively fast machine
2. Boot with -v option
3. Look at the dmesg output ;)
>Fix:
--- npx.c.orig	Sat May 15 01:14:13 1999
+++ npx.c	Sat May 15 02:01:51 1999
@@ -696,8 +696,8 @@
 	if (usec <= 0)
 		usec = 1;
 	if (bootverbose)
-		printf("%s bandwidth = %ld bytes/sec\n",
-		    funcname, (long)(BUFSIZE * (int64_t)1000000 / usec));
+		printf("%s bandwidth = %ld Kbytes/sec\n",
+		    funcname, (long)(BUFSIZE * (int64_t)1000000 / (1024*usec)));
 	free(buf, M_TEMP);
 	return (usec);
 }

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: bde 
State-Changed-When: Mon Jun 7 01:50:24 PDT 1999 
State-Changed-Why:  
I believe that the problem is actually caused by using SMP or APM.  Then 
microtime() doesn't work right when it is called early in timezero(). 
It still works on fast machines (ones that have bzero() and i586_bzero() 
bandwidths > 10^8 bytes/sec). 

From: Maxim Sobolev <sobomax@altavista.net>
To: freebsd-gnats-submit@freebsd.org, sobomax@altavista.net,
	bde@freebsd.org
Cc:  
Subject: Re: kern/11736: On fast machines kernel reports negative i586_bzero 
 bandwith values due to datatype overflow
Date: Thu, 26 Aug 1999 00:44:05 +0300

 It seems that all OK now, so you can close this PR.
 
 -Maxim
 
 
State-Changed-From-To: analyzed->closed  
State-Changed-By: cpiazza 
State-Changed-When: Wed Aug 25 15:03:50 PDT 1999 
State-Changed-Why:  
Originator reports that the problem disappeared 

From: Bruce Evans <bde@zeta.org.au>
To: bde@freebsd.org, freebsd-gnats-submit@freebsd.org,
	sobomax@altavista.net
Cc:  
Subject: Re: kern/11736: On fast machines kernel reports negative i586_bzero bandwith values due to datatype overflow
Date: Thu, 26 Aug 1999 08:01:11 +1000

 >It seems that all OK now, so you can close this PR.
 
 I don't think I actually fixed it.  The problem is that the test is
 run before interrupts are enabled, so the i8254 clock overflows
 after 10 msec.  I fixed overflow detection, so the clock is accurate
 for up to 20 msec depending on when the test is started.  The test
 writes 10^6 bytes which normally takes 5-10 msec on a P5 (it takes
 about 6 msec on my P5/133).  However, K6-1's at least are slower
 (the test takes about 12 msec on my K6-1/233), so there is some
 chance of it not working.
 
 Possible fixes:
 1) always use the TSC for timing the test.
 2) use a smaller buffer and be more careful about caching.  The test
    should be more careful about caching anyway.
 
 Bruce
 
>Unformatted:
