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 [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]
