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?
-Len
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.
-
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]
