Timekeeping hosed by factor 3, high lapic[01] interrupt rates
Jens Schweikhardt
schweikh at schweikhardt.net
Sat May 21 02:29:20 PDT 2005
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)
More information about the freebsd-current
mailing list