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?