Vojtech Pavlik 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 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 commandline 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 parameterunless 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.
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/
- Follow-Ups:
- Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- From: "Om Narasimhan" <[email protected]>
- Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- From: Vojtech Pavlik <[email protected]>
- Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- References:
- RE: HPET : Legacy Routing Replacement Enable - 3rd try.
- From: "Pallipadi, Venkatesh" <[email protected]>
- Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- From: "Om Narasimhan" <[email protected]>
- Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- From: Andi Kleen <[email protected]>
- Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- From: Vojtech Pavlik <[email protected]>
- RE: HPET : Legacy Routing Replacement Enable - 3rd try.
- Prev by Date: Re: [PATCH] x86_64 irq: reset more to default when clear irq_vector for destroy_irq
- Next by Date: Re: [Q] missing unused dentry in prune_dcache()?
- Previous by thread: Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- Next by thread: Re: HPET : Legacy Routing Replacement Enable - 3rd try.
- Index(es):