On Fri, Oct 27, 2006 at 04:42:38AM +0200, Andi Kleen wrote:There seems to be lot of confusion here. Current code isn't using hpet as tick source if legacy is not supported. This patch adds hpet_lrr_force but it's not clear how it interacts with hpet_use_timer - in some places it is hpet_use_timer and some (hpet_use_timer && hpet_lrr_force).
On Wed, Oct 25, 2006 at 02:20:22PM -0700, Om Narasimhan wrote:
I tested against five different bioses (some with 8132, some withWhat ACPI timer? I don't think we have any fallback for int 0.
CK-804 ..etc) and I observed three different patterns.
1. HW is LRR capable, HPET ACPI it is 1, timer interrupt is on INT2.
Before the fix: Linux cannot get timer interrupts on INT0, goes for ACPI timer.
Not sure what you mean with INT2. Pin2 on ioapic 0 perhaps?
After the fix : Works fine. This is according to hpet spec.On what exact motherboard was that?
To handle case 3, I removed all references to acpi_hpet_lrr, explainedThis means the systems which you said fixes this would need the command
this case in the code and decided to solely rely on the command line
parameter for LRR capability. Rational for this approach is ,
line parameter to work?
1. At present, there are not many BIOSes which implement LRR (correctly)Generally we try to work everywhere without command line parameter
2. People would see the bootup message (MP-BIOS bug...) if LRR is
enabled and no timer interrupt on INT0. They can pass the hpet_lrr=1
to make everything work fine.
Is it the right approach?
unless something is terminally broken.
JFYI: The new per-cpu timekeeping code doesn't need the HPET legacy bit,
thus not replacing IRQ0 (PIT) and IRQ13 (RTC). It still can do that, but
will work just as well without it.