Re: Time of day clock runs at twice the speed on (old) laptop

[Andrew Doran <ad%netbsd.org@localhost>]

On Mon, Nov 24, 2008 at 07:53:56AM -0500, Jared D. McNeill wrote:

> Magnus Eriksson wrote:
> >I recently installed 4.0.1 to an old laptop I had around (a really old 
> >one, it's a Siemens Scenic Mobile 350 from 1999) and noticed something 
> >weird: The system clock is running twice as fast as it should.
> >
> >
> >Exactly twice, as far as I can tell, but only in some ways:
> >
> >$ date ; sleep 10 ; date
> >Mon Nov 24 11:44:31 CET 2008
> >Mon Nov 24 11:44:51 CET 2008
> >$
> >
> >And it really does seem to sleep for ten seconds.
> >
> >
> >Other symptoms are that "midiplay -x" runs twice as fast as it should; and 
> >when trying out minicom, the transfer rate was exactly half of the correct 
> >value (as reported by my 4.0.1 desktop system on the other side) with the 
> >estimated time to finish correspondingly being twice as far in the future 
> >and ticking down at twice the speed.
> >
> >
> >This is with a 4.0.1 GENERIC_LAPTOP kernel, and a fairly recent 4.0_STABLE 
> >- if that's the correct terminology - gives the same result, both 
> >GENERIC_LAPTOP and a customized kernel.
> >
> >However, a GENERIC.NOACPI kernel works fine.  (It also doesn't interfere 
> >with the sleep/suspend buttons, but that's another story...)
> >
> >
> >Selected parts of dmesg output: (full dmesg attached)
> >
> >$ dmesg | grep time
> >timecounter: Timecounters tick every 10.000 msec
> >timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> >timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
> >ACPI-Safe 32-bit timer
> >attimer0 at isa0 port 0x40-0x43: AT Timer
> >pcppi0: attached to attimer0
> >timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> >$
> >
> >
> >Any idea what is going on?  I know that there is more than one clock 
> >involved, separate ones for time-of-day and precise delays, but how can 
> >only *one* be off like this?  And why isn't the system screaming at me 
> >that the timing sources are so obviously out of sync?
> 
> Hi Magnus --
> 
> If you run the following command as root:
> 
>   # sysctl -w kern.timecounter.hardware=i8254
> 
> Does the problem go away?

FWIW, x86 timer calibration is unreliable in 4.0. It's fixed in -current,
which may matter here.

Andrew