> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
