[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Time of day clock runs at twice the speed on (old) laptop
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.
Main Index |
Thread Index |