Re: [suse-amd64] False "lost ticks" on dual-Opteron system (=> timer twice as fast)

[Andi Kleen]

> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/