On Friday 03 August 2007 20:38:17 Robert Hancock wrote:
quoted text
> It appears that the latest BIOS version 1805 for the ASUS A8N-SLI Deluxe
> board fixes the broken ACPI timer override that was in earlier versions,
> and which the kernel ignores on nForce4 chipsets. Now the same override:
> 
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> 
> seems to be needed, since without acpi_use_timer_override we end up
> getting this (with apic=verbose):

That's really bad.
 
quoted text
> ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> ...trying to set up timer (IRQ0) through the 8259A ...  failed.
> ...trying to set up timer as Virtual Wire IRQ... failed.
> ...trying to set up timer as ExtINT IRQ... works.
> 
> and the timer IRQ ends up routed as XT-PIC instead of IO-APIC-edge. With 
> acpi_use_timer_override we just get:
> 
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> 
> and it works through the IO-APIC.
> 
> I should think there must be a better way to handle this automatically.. 

I have pending patches to key the NF5 case on the PCI-ID, but
that obviously cannot be done for NF4.

I cannot think of anything good but putting DMI BIOS version
checks in for that specific board.

quoted text
> Is there some way we can tell, given we have a chipset with a 
> potentially broken BIOS, from the configuration of the IOAPIC whether 
> the timer override is needed or not? Unfortunately I don't have output 
> from apic=verbose with the old BIOS with the broken override, but maybe 
> somebody else can provide that..

We don't really know which pins are connected where. This means they
likely have some bits they tweaked to get the different behaviour, but they're 
unknown. There are also some northbridge bits that can be tweaked
(e.g. some of the ATI BIOS workarounds used to use that) 
but it's still unknown what the Nvidia chipset actually does and if
they really help here.

Ok in theory you could diff config space dumps between the two BIOS 
versions to try to figure it out, but that would be still pretty risky
and I don't think it would be a good idea to trust such results.

-Andi

 
-
unsubscribe notice
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/