Re: HPET : Legacy Routing Replacement Enable - 3rd try.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Vojtech Pavlik wrote:
On Fri, Oct 27, 2006 at 04:42:38AM +0200, Andi Kleen wrote:

On Wed, Oct 25, 2006 at 02:20:22PM -0700, Om Narasimhan wrote:
I tested against five different bioses (some with 8132, some with
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.
What ACPI timer?  I don't think we have any fallback for int 0.

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, explained
this case in the code and decided to solely rely on the command line
parameter for LRR capability. Rational for this approach is ,
This means the systems which you said fixes this would need the command
line parameter to work?
1. At present, there are not many BIOSes which implement LRR (correctly)
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?
Generally we try to work everywhere without command line parameter
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.

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).

The timer is routed to ioapic pin 2 which is irq0 with source override. With this patch with hpet_lrr_force=1 timer irq is set to 2 for x86_64 and 0 for i386, that can't be right?

--Mika


-
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]
  Powered by Linux