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

From: Jens Schweikhardt <schweikh_at_schweikhardt.net>
Date: Sat, 21 May 2005 11:28:57 +0200
On Fri, May 20, 2005 at 12:44:50PM -0700, Doug White wrote:
...
# > Note that there's no
# > irq0: clk                         745029       1000
# > appearing. I'm not an expert, but that's unexpected to my eyes.
# 
# Not totally (I don't have irq0 on any of my -current machines after the
# lapic change), but it being there before and then going away implies the
# kernel is choosing a different timecounter than before, and the new one
# may be bogus.
# 
# Can you get the output of 'sysctl kern.timecounter' for both working and
# broken kernels?


broken:
kern.timecounter.stepwarnings: 0
kern.timecounter.nbinuptime: 221327
kern.timecounter.nnanouptime: 0
kern.timecounter.nmicrouptime: 640
kern.timecounter.nbintime: 951
kern.timecounter.nnanotime: 22
kern.timecounter.nmicrotime: 929
kern.timecounter.ngetbinuptime: 410
kern.timecounter.ngetnanouptime: 76
kern.timecounter.ngetmicrouptime: 3599
kern.timecounter.ngetbintime: 0
kern.timecounter.ngetnanotime: 0
kern.timecounter.ngetmicrotime: 5
kern.timecounter.nsetclock: 2
kern.timecounter.hardware: i8254
kern.timecounter.choice: TSC(-100) i8254(0) dummy(-1000000)
kern.timecounter.tick: 1
kern.timecounter.smp_tsc: 0

working:
kern.timecounter.stepwarnings: 0
kern.timecounter.nbinuptime: 630606
kern.timecounter.nnanouptime: 0
kern.timecounter.nmicrouptime: 1220
kern.timecounter.nbintime: 127348
kern.timecounter.nnanotime: 58801
kern.timecounter.nmicrotime: 68578
kern.timecounter.ngetbinuptime: 1983
kern.timecounter.ngetnanouptime: 423
kern.timecounter.ngetmicrouptime: 34313
kern.timecounter.ngetbintime: 0
kern.timecounter.ngetnanotime: 0
kern.timecounter.ngetmicrotime: 5
kern.timecounter.nsetclock: 1
kern.timecounter.hardware: i8254
kern.timecounter.choice: TSC(-100) i8254(0) dummy(-1000000)
kern.timecounter.tick: 1
kern.timecounter.smp_tsc: 0

# When did you pull sources for the original working kernel and the new
# broken kernel?

Working: around March 5 (I always cvsup before compiling a system)
Broken:  May 17 (after the ATA hangs at boot were fixed)

# > pcib0: <MPTable Host-PCI bridge> pcibus 0 on motherboard
# 
# Is ACPI disabled on purpose?  It should work on such a new system. ACPI
# provides a couple of timecounters of its own that we'd prefer to use.

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...


Regards,

	Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Received on Sat May 21 2005 - 07:29:20 UTC

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