From cjohnson@neunacht.netgsi.com  Wed May 13 22:42:51 1998
Received: from neunacht.netgsi.com (neunacht.netgsi.com [192.55.203.174])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11379
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 13 May 1998 22:42:48 -0700 (PDT)
          (envelope-from cjohnson@neunacht.netgsi.com)
Received: (from root@localhost)
	by neunacht.netgsi.com (8.8.8/8.8.6) id BAA12770;
	Thu, 14 May 1998 01:42:46 -0400 (EDT)
Message-Id: <199805140542.BAA12770@neunacht.netgsi.com>
Date: Thu, 14 May 1998 01:42:46 -0400 (EDT)
From: cjohnson@netgsi.com
Reply-To: cjohnson@netgsi.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Fix for Cyrix I8254 bug
X-Send-Pr-Version: 3.2

>Number:         6630
>Category:       kern
>Synopsis:       [PATCH] Fix for Cyrix I8254 bug
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    phk
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 13 22:40:01 PDT 1998
>Closed-Date:    Tue May 06 10:35:39 PDT 2003
>Last-Modified:  Tue May 06 10:35:39 PDT 2003
>Originator:     Christopher T. Johnson
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
NetGSi, Inc
>Environment:
	Any Cyrix GX(m) cpu using the 5510 or 5520 support chipset.

>Description:
	The Cyrix 5510 and 5520 chipset has a serious flaw in the 
	I8254 programmable interupt timer.  When the I8254 PIT is
	sent a "LATCH" command, it is suppose to copy the current counter
	into a 16 bit latch counter as an atomic action.  Instead, either
	the latch fails to take place, or there is no latch register.

	When the standard clock calibration loops run, the i8254 is miss
	tracked giving bogus timings.  In addition, the TSC is callibrated
	against the i8254 using the same busted logic giving such wonderful
	readings as a Pentium MMX running at 180 Mhz being detected as
	a 9Mhz Pentium.  (poor english sorry)

	In addition to these simple things going astray, the callout() routines
	die because they are based on the calibrations of the TSC or I8254.

	The biggest problem is that the DELAY() routine dies.  This causes
	things like APM to panic as well as many other kernel drivers that
	need sub second timing.

>How-To-Repeat:

	find a Compaq Presario 1215 and boot FreeBSD.  Type date a few times
	and see what the time warp is like.

>Fix:
Index: LINT
===================================================================
RCS file: /usr/cvsroot/src/sys/i386/conf/LINT,v
retrieving revision 1.429
diff -u -r1.429 LINT
--- LINT	1998/04/29 17:09:41	1.429
+++ LINT	1998/05/14 05:09:57
@@ -136,6 +136,11 @@
 # of Cyrix 6x86 and 6x86MX CPUs.  If this option is not set and
 # FAILESAFE is defined, NO_LOCK bit of CCR1 is cleared.  (NOTE 3)
 #
+# CPU_CYRIX_NO_I8254_LATCH enables a patch to deal with the I8254
+# programable interupt timer failing to latch in a number of cyrix
+# chipsets.  This can be seen by run away Time of Day clocks and 
+# panics when trying to do sub second time keeping.
+#
 # CPU_DISABLE_5X86_LSSER disables load store serialize (i.e. enables
 # reorder).  This option should not be used if you use memory mapped
 # I/O device(s). 
@@ -196,6 +201,7 @@
 options		"CPU_SUSP_HLT"
 options		"CYRIX_CACHE_WORKS"
 options		"CYRIX_CACHE_REALLY_WORKS"
+options		"CPU_CYRIX_NO_I8254_LATCH"
 #options	"NO_F00F_HACK"
 
 #
Index: options.i386
===================================================================
RCS file: /usr/cvsroot/src/sys/i386/conf/options.i386,v
retrieving revision 1.77
diff -u -r1.77 options.i386
--- options.i386	1998/04/18 04:58:01	1.77
+++ options.i386	1998/05/14 05:12:18
@@ -68,6 +68,7 @@
 CPU_UPGRADE_HW_CACHE		opt_cpu.h
 CYRIX_CACHE_WORKS		opt_cpu.h
 CYRIX_CACHE_REALLY_WORKS	opt_cpu.h
+CPU_CYRIX_NO_I8254_LATCH	opt_clock.h
 
 # The CPU type affects the endian conversion functions all over the kernel.
 I386_CPU		opt_global.h
Index: clock.c
===================================================================
RCS file: /usr/cvsroot/src/sys/i386/isa/clock.c,v
retrieving revision 1.119
diff -u -r1.119 clock.c
--- clock.c	1998/04/05 01:04:48	1.119
+++ clock.c	1998/05/14 05:20:02
@@ -402,7 +402,9 @@
 {
 	u_long ef;
 	int high, low;
-
+#if CPU_CYRIX_NO_I8254_LATCH
+	int ret1, ret2;
+#endif
 	ef = read_eflags();
 	disable_intr();
 
@@ -411,10 +413,21 @@
 
 	low = inb(TIMER_CNTR0);
 	high = inb(TIMER_CNTR0);
+#if CPU_CYRIX_NO_I8254_LATCH
+	ret1 = (high << 8) | low;
 
+	outb(TIMER_MODE, TIMER_SEL0 | TIMER_LATCH);
+	low = inb(TIMER_CNTR0);
+	high= inb(TIMER_CNTR0);
+	ret2 = (high <<8) | low;
+#endif
 	CLOCK_UNLOCK();
 	write_eflags(ef);
+#if CPU_CYRIX_NO_I8254_LATCH
+	return (ret1 > ret2 ? ret1 : ret2);
+#else
 	return ((high << 8) | low);
+#fi
 }
 
 /*


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Tue May 19 03:07:39 PDT 1998 
State-Changed-Why:  
awaiting committer 

From: Kevin Day <toasty@home.dragondata.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: Re: kern/6630
Date: Sat, 21 Nov 1998 13:05:32 -0600 (CST)

 I have also experienced this behavior, and confirmed with Cyrix what
 Christopher has said in this PR.
 
 In the 5510 and 5520 support chips for the MediaGX and MediaGXm, the LATCH
 command to the 8254 does nothing. While his patch works, it's still not
 perfect. It brings the 8254 to within 1% accuracy, which is good enough for
 my uses though.
 
 (It sees my 233 GXm as 209 MHz....)
 
 If I write a detection check to see if the 5510 or 5520 is present, could
 that be useful? 
 
 Where would this be called though, if the 8254 check is done so soon,
 vendor/device ID's haven't yet been probed at that time.....
 
 Suggestions?
 
 Kevin Day

From: Poul-Henning Kamp <phk@FreeBSD.ORG>
To: freebsd-gnats-submit@freebsd.org, cjohnson@netgsi.com
Cc:  Subject: Re: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Sat, 21 Nov 1998 21:00:56 +0100

 The correct patch for this will to handle both the getit() and the
 i8254_get_timecount() functions.
 
 Poul-Henning
 

From: Sheldon Hearn <sheldonh@iafrica.com>
To: "Christopher T. Johnson" <cjohnson@netgsi.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Fri, 19 Mar 1999 13:31:22 +0200

 Hi Cristopher,
 
 Quite a bit of work has been done on the clock code since your problem
 report.
 
 Could you provide feedback for a recent CURRENT?
 
 Thanks,
 Sheldon.
 

From: cjohnson@netgsi.com (Christopher T. Johnson)
To: sheldonh@iafrica.com (Sheldon Hearn)
Cc:  
Subject: Re: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Wed, 24 Mar 1999 15:38:43 +0000 (GMT)

 I'm sorry but that machine was returned to vender because it was not stable
 enough for FreeBSD (There were buttons on the box that would generated
 undocumented interupts leading to panics).
 	Chris
 
 
 > 
 > Hi Cristopher,
 > 
 > Quite a bit of work has been done on the clock code since your problem
 > report.
 > 
 > Could you provide feedback for a recent CURRENT?
 > 
 > Thanks,
 > Sheldon.
 > 
 
 
 
Responsible-Changed-From-To: freebsd-bugs->julian 
Responsible-Changed-By: unfurl 
Responsible-Changed-When: Thu Jul 1 18:33:44 PDT 1999 
Responsible-Changed-Why:  
Whistle is currently using the Cyrix 5510 chipsets. Please test this patch if necessary or close the PR altogether if this is fixed. 

From: Kevin Day <toasty@dragondata.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/6630
Date: Sat, 22 Apr 2000 00:45:43 -0500 (CDT)

 As a rather late followup:
 
 The 5510 and 5520 have long since been discontinued, and what's left of
 Cyrix is no longer going to be producing these. (The MediaGX line of
 processors is dead). My final talks with the Cyrix guys on their last visit
 was that there isn't a workaround to their knowledge, other than not relying
 on the latch at all and doing multiple reads.
 
 A solution isn't likely to appear, so this PR could probably be closed with
 the comment that anyone unfortunate enough to be using one of these beasties
 should apply the patch here for a usable-but-not-perfect fix.
 
 -- Kevin
 
State-Changed-From-To: suspended->feedback 
State-Changed-By: dougb 
State-Changed-When: Sun May 27 15:26:26 PDT 2001 
State-Changed-Why:  

Julian, what do you think about closing this, one way or another? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=6630 
Responsible-Changed-From-To: julian->phk 
Responsible-Changed-By: julian 
Responsible-Changed-When: Mon Feb 25 11:14:02 PST 2002 
Responsible-Changed-Why:  
phk is Mr timekeeper. 
he can decide to do somethign or throw away (since it is for 3.0). 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=6630 

From: Joseph Holland King <gte743n@cad.gatech.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Wed, 20 Nov 2002 18:20:43 -0500

 this has been idle for over six months. can it be marked closed?
 
 -- 
 Holland King        
 gte743n@cad.gatech.edu

From: Joseph Holland King <gte743n@cad.gatech.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Mon, 17 Feb 2003 00:15:01 -0500

 This PR can be closed
 -- 
 Holland King        
 gte743n@cad.gatech.edu

From: Joseph Holland King <gte743n@cad.gatech.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Thu, 6 Mar 2003 01:48:58 -0500

 this pr can be closed
 
 -- 
 Holland King        
 gte743n@cad.gatech.edu

From: insane@wreck.org
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: kern/6630: [PATCH] Fix for Cyrix I8254 bug
Date: Tue, 29 Apr 2003 19:06:05 -0400

 This PR can be closed
 
 -- 
 Holland King        
 gte743n@cad.gatech.edu
State-Changed-From-To: feedback->closed 
State-Changed-By: phk 
State-Changed-When: Tue May 6 10:35:01 PDT 2003 
State-Changed-Why:  
Close ancient hardware issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=6630 
>Unformatted:
