Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates

From: Jens Schweikhardt <schweikh_at_schweikhardt.net>
Date: Mon, 23 May 2005 19:56:09 +0200
...
# Lets try this:
# 0. If you're overclocking your CPU, don't.

Never did.

# 1. Boot with ACPI enabled and print the two kern.timecount sysctls above.
# I'm curious if its picking up the ACPI timecounter.

Isn't APIC enabled unless I disable it with hint.acpi.0.disabled="1"?

# 2. Shutdown and unplug the machine for about 20 minutes or overnight if
# convenient. Plug it back in, go into BIOS Setup and check the clock.  If its
# off or dead then the CMOS battery is dead.

This is my home machine, which I turn off at night. The BIOS clock
looks good. And this would not explain why it's the same system
that works with a different kernel.

# 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt
# handler is reactivated and the RTC fiddled.

Will do so next. I've nailed the change between March 6 and March 30.
1.218 is from 2005/03/24 21:34:16, which would fit.

# > Some time in the past, the system would hang at boot with acpi enabled.
# > So I kept a hint.acpi.0.disabled="1" in /boot/device.hints. But even
# > without that hint, the time dilation effect (hey, it's the Einstein
# > Year!) is the same...
# 
# This would imply the source of the problem is not in the timecounter,
# which doesn't make sense.

It's puzzling, but dammit, these are deterministic machines :-) I'm sure
in the end we'll find the cause. Thanks for your patience.

# Are you running ntpd?

Yes.

Regards,

	Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Received on Mon May 23 2005 - 15:56:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:35 UTC