![]() | |||||||||||
Messages in this thread |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-10-27 08:01 [from the cache] ©2003-2008 | |||||||||||