From junki@qn-lpr2-98.quicknet.inet.fi Fri Mar 12 19:23:17 1999
Return-Path: <junki@qn-lpr2-98.quicknet.inet.fi>
Received: from qn-lpr2-98.quicknet.inet.fi (qn-lpr2-98.quicknet.inet.fi [194.251.102.98])
	by hub.freebsd.org (Postfix) with ESMTP id B420B14E3B
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 12 Mar 1999 19:23:14 -0800 (PST)
	(envelope-from junki@qn-lpr2-98.quicknet.inet.fi)
Received: (from junki@localhost)
	by qn-lpr2-98.quicknet.inet.fi (8.9.3/8.9.1) id FAA14122;
	Sat, 13 Mar 1999 05:23:12 +0200 (EET)
	(envelope-from junki)
Message-Id: <199903130323.FAA14122@qn-lpr2-98.quicknet.inet.fi>
Date: Sat, 13 Mar 1999 05:23:12 +0200 (EET)
From: Juha Nurmela <junki@qn-lpr2-98.quicknet.inet.fi>
Reply-To: junki@qn-lpr2-98.quicknet.inet.fi
To: FreeBSD-gnats-submit@freebsd.org
Subject: Slow timekeeping on certain motherboards/cpus/chipsets
X-Send-Pr-Version: 3.2

>Number:         10565
>Category:       kern
>Synopsis:       Slow timekeeping on certain motherboards/cpus/chipsets
>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:   Fri Mar 12 19:30:00 PST 1999
>Closed-Date:    Sat May 29 00:11:24 PDT 1999
>Last-Modified:  Sat May 29 00:12:46 PDT 1999
>Originator:     Juha Nurmela
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
ACME Inc.
>Environment:

	Timecounter "i8254"  frequency 1193182 Hz
	Timecounter "TSC"  frequency 74539244 Hz
	CPU: AMD K5 model 0 (74.54-MHz 586-class CPU)
		Origin = "AuthenticAMD"  Id = 0x500  Stepping=0
		Features=0x3bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC>

	chip0: <Intel 82437VX PCI cache memory controller> rev 0x02 on pci0.0.0
	chip1: <Intel 82371SB PCI to ISA bridge> rev 0x01 on pci0.7.0

>Description:

	Time does not increment. Well, very slowly and not in any determinable
	constant rate. Using the timerchip for timecounter instead
	of tsc register works around the problem.

	Another 'fix' with my mobo is to keep the cpu busy, and not let
	it enter HLT. 'while : ; do date; done' almost does the trick as
	well as a idle-priority process in tight loop (does it better).

	Looks like the mobo does bad SMI stuff whenever a HLT is executed,
	and it cannot really be changed in the bios settings which disable
	power management.

>How-To-Repeat:

	With this kind of PC, build a kernel which contains no apm0,
	nor SMP, and watch date in idlish system, then in busyish system.
	Date should step almost properly in busy state and halt
	almost completely in idle system.

>Fix:

	It might be nice to have a std way to set the existing hlt_vector in
	swtch.s into just RET (which it already is with SMP).
		options "CPU_HALT_NO" and/or
		sysctl -w machdep.do_halt=0
	cp_time[] via sysctl would be nice too...


>Release-Note:
>Audit-Trail:

From: "Daniel C. Sobral" <dcs@newsguy.com>
To: junki@qn-lpr2-98.quicknet.inet.fi
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/10565: Slow timekeeping on certain motherboards/cpus/chipsets
Date: Sat, 13 Mar 1999 17:57:12 +0900

 Would you happen to have apm enabled in these computers?
 
 Juha Nurmela wrote:
 > 
 > >Number:         10565
 > >Category:       kern
 > >Synopsis:       Slow timekeeping on certain motherboards/cpus/chipsets
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       low
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Quarter:
 > >Keywords:
 > >Date-Required:
 > >Class:          change-request
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Fri Mar 12 19:30:00 PST 1999
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Juha Nurmela
 > >Release:        FreeBSD 4.0-CURRENT i386
 > >Organization:
 > ACME Inc.
 > >Environment:
 > 
 >         Timecounter "i8254"  frequency 1193182 Hz
 >         Timecounter "TSC"  frequency 74539244 Hz
 >         CPU: AMD K5 model 0 (74.54-MHz 586-class CPU)
 >                 Origin = "AuthenticAMD"  Id = 0x500  Stepping=0
 >                 Features=0x3bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC>
 > 
 >         chip0: <Intel 82437VX PCI cache memory controller> rev 0x02 on pci0.0.0
 >         chip1: <Intel 82371SB PCI to ISA bridge> rev 0x01 on pci0.7.0
 > 
 > >Description:
 > 
 >         Time does not increment. Well, very slowly and not in any determinable
 >         constant rate. Using the timerchip for timecounter instead
 >         of tsc register works around the problem.
 > 
 >         Another 'fix' with my mobo is to keep the cpu busy, and not let
 >         it enter HLT. 'while : ; do date; done' almost does the trick as
 >         well as a idle-priority process in tight loop (does it better).
 > 
 >         Looks like the mobo does bad SMI stuff whenever a HLT is executed,
 >         and it cannot really be changed in the bios settings which disable
 >         power management.
 > 
 > >How-To-Repeat:
 > 
 >         With this kind of PC, build a kernel which contains no apm0,
 >         nor SMP, and watch date in idlish system, then in busyish system.
 >         Date should step almost properly in busy state and halt
 >         almost completely in idle system.
 > 
 > >Fix:
 > 
 >         It might be nice to have a std way to set the existing hlt_vector in
 >         swtch.s into just RET (which it already is with SMP).
 >                 options "CPU_HALT_NO" and/or
 >                 sysctl -w machdep.do_halt=0
 >         cp_time[] via sysctl would be nice too...
 > 
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 > 
 > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > with "unsubscribe freebsd-bugs" in the body of the message
 
 --
 Daniel C. Sobral			(8-DCS)
 dcs@newsguy.com
 dcs@freebsd.org
 
 	"My theory is that his ignorance clouded his poor judgment."
 
 
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Sat May 29 00:11:24 PDT 1999 
State-Changed-Why:  
I had occasion to work on a K5 cpu last week and checked this.  I've now 
added code to -current which will prevent the tsc from being used for 
timekeeping on a K5/step0.  Will probably be merged to -stable later. 
>Unformatted:
