I went through the BIOS setup, and found a disabled feature "ACPI 2.0", which I enabled. Now Linux finds the HPET timer.
Great. The machine came like this? I wish OEMs wouldn't do such things...
# grep -i hpet boot.log ACPI: HPET (v001 A M I OEMHPET 0x04000518 MSFT 0x00000097) @ 0x00000000e8ff3c30 ACPI: HPET id: 0x102282a0 base: 0xfec01000 time.c: Using 14.318180 MHz HPET timer. time.c: Using HPET based timekeeping. hpet0: at MMIO 0xfec01000, IRQs 2, 8, 0 hpet0: 69ns tick, 3 32-bit timers hpet_acpi_add: no address or irqs in _CRS
and everything appears to work (though there's still no designated CPU to handle the timer interrupts). xntpd syncs quickly, I'm happy (so far ;-).
Great.
So that explains why nobody sees this problem. But the TSC-based fallback timekeeping is still broken on SMP systems with PowerNow and distributed IRQ handling, which both together seem to be rare enough ;-).
There is a patch pending for the TSC problem - using the pmtimer instead in this case. But the distributed timer interrupt problem is weird. It should not happen. You sure it was IRQ 0 that was duplicated and not "LOC" ? When you watch -n1 cat /proc/interrupts does the rate roughly match up to 1000Hz? -Andi