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