Bug 104867

Summary: Clock running at 2x speed of wall clock
Product: Base System Reporter: Jeffrey D. Brower <Jeff>
Component: i386Assignee: freebsd-i386 (Nobody) <i386>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Jeffrey D. Brower 2006-10-27 20:30:19 UTC 
date command shows os time advancing exactly 2x the speed of the wall clock.

Motherboard:  ASUS P5A-B ACPI Bios Rev 1011 (current for this board)
CPU:  AMD-K6-III/450

sysctl kern.clockrate reports hz=1000, tick=1000, profhz=1024, stathz=128

kernel recompiled to include CLK_USE_I8254_CALIBRATION and the condition does not change, nor does the output of sysctl.kern.clockrate

How-To-Repeat: use date command.  wait exactly 1 minute. use date command.  Elapsed time will show 2 minutes have passed on the computer.
Comment 1 Rebecca Cran freebsd_committer freebsd_triage 2008-05-09 22:31:29 UTC 
Could you check which timecounter is being used, with the 
kern.timecounter.hardware sysctl?  The ACPI-safe source is known to run 
far too fast on many systems, and it's better to use i8254 instead: try 
putting the following in /etc/sysctl.conf and rebooting

kern.timecounter.hardware=i8254

If the clock is still running slightly fast (e.g. 1s per minute) then 
you can configure ntpd to track and correct the drift. There's a guide 
to setting it up in the handbook at 
http://www.freebsd.org/doc/en/books/handbook/network-ntp.html

-- 
Bruce Cran
Comment 2 Jeffrey D. Brower 2008-05-10 00:58:23 UTC 
I verified that the timecounter was indeed i8254 after I recompiled with
that option and it still ran double time.
 
Everything I tried failed - even NTP gave up because it was constantly
slewing.  No one could solve it and I never got an answer so I ended up
pulling the box and replacing it with a more modern motherboard about a year
and a half ago and I have had no problems since.
 
Frankly, the board was past its prime anyway - but it was fine for a
dedicated firewall if I could have gotten it to work.  I just needed the
clock to be right so that the logs would match in case I needed to do
forensics.
 
--  Jeff
Comment 3 Volker Werth freebsd_committer freebsd_triage 2008-05-12 00:18:14 UTC 
State Changed
From-To: open->closed


according to Bruce, the issue does not occur anymore as the machine 
has been swapped.