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.
--
Vojtech Pavlik
Director SuSE Labs
-
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]
