Messages in this thread | | | From | Andi Kleen <> | Subject | Re: ASUS M2NPV-VM APIC/ACPI Bug (patched) | Date | Thu, 19 Oct 2006 14:41:07 +0200 |
| |
On Wednesday 18 October 2006 09:30, Len Brown wrote: > On Wednesday 18 October 2006 02:44, Daniel Mierswa wrote: > > Some people have deeper problems with the Asus M2NPV-VM mainboard > > (rather the chipset of the mainboard). > > A google for "Asus M2NPV-VM apic" shows that. I'm one of them, > > desperately searching a way to fix that, using that board with an AMD > > Athlon64 X2 3800+ Dual Core Processor. > > It wouldn't boot because of APIC and ACPI errors. There were "kind of" > > workarounds by passing acpi=off/noirq and noapic to the kernel which > > resulted in sometimes bad internal clock. I for myself had the same > > problem and due to the error with my internal system clock all > > applications and drivers gone mad, including > > sound,video,graphics,usb,etc.. I googled around and saw the following: > > http://lkml.org/lkml/2006/8/13/25 > > Actually that was a patch created for the 2.6.18-rc4 kernel. I tried > > several kernels all with the same results. Some of them are > > 2.6.18-mm3, 2.6.19-rc2, 2.6.17, 2.6.18, 2.6.18.1, some gentoo patched > > sources and what not. All will hang after the io scheduler gets loaded, > > passing acpi=off/noirq to the kernel will workaround that one. Then it > > will boot on and finally reach the ochi_hcd driver which will not load > > because of shared IRQ problems, passing nousb to the kernel will > > workaround that. It will boot more and come to the dhcp client, where it > > fails because of an Interrupt error. > > Some people passing noapic acpi=off/noirq to the kernel got later sound > > problems, they fixed that by passing "snd-hda-intel model=3stack > > position_fix=1" which worked around that interrupt problem. So with the > > patch provided on http://lkml.org/lkml/2006/8/13/25 it all works out. > > The internal system clock works just fine, the drivers load > > all fine, no need to patch the sound,graphics or anything at all. No > > need for kernel parameters either. Here's the patch again, created by > > diff -ur on the current 2.6.18.1 kernel: > > > > --- io_apic.c.orig 2006-10-18 08:02:50.000000000 +0200 > > +++ io_apic.c 2006-10-18 07:40:48.000000000 +0200 > > @@ -337,12 +337,12 @@ > > nvidia_hpet_detected = 0; > > acpi_table_parse(ACPI_HPET, > > nvidia_hpet_check); > > - if (nvidia_hpet_detected == 0) { > > +/* if (nvidia_hpet_detected == 0) { > > acpi_skip_timer_override = 1; > > printk(KERN_INFO "Nvidia board " > > "detected. Ignoring ACPI " > > "timer override.\n"); > > - } > > + }*/ > > #endif > > I recall quite clearly that Nvidia told us that that acpi_skip_timer_override > was necessary in NFORCE2 days. I don't remember the HPET qualification to > that statement -- I guess that came later. > Unfortunately, my NFORCE2 board is dead, so I can't really test this out directly. > > Perhaps checking for PCI_VENDOR_ID_NVIDIA is too broad and the workaround > is counter-productive on their newer NVIDIA chip-sets?
I suppose Asus just "forgot" again to enable the HPET in their NF5 BIOS. In general they seem to hate ACPI tables -- near all their mcfg tables are broken too. Maybe we need to define the ASUS subset of ACPI (just kidding) @)
Anyways, I suppose we'll need a list of all unique PCI IDs for NF3,NF4 to key this workaround on. Andy do you have a complete list?
>ps. >One (other) problem with this code is that it checks for an HPET table, >but doesn't check that the kernel has HPET support enabled.
Keying on PCI-IDs would fix that too.
-Andi - 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/
| |