[ACPI] Located the problem with the VIA KT400 board

[Andrew de Q. <ad...@li...>]

Hi, I think I've just spotted the problem, and unfortunately, I think it is an 
AML problem.

When your board boots, several devices are configured without IRQs set (i.e. 
the IRQ returned by _CRS is 0) (I think this is called "boot disabled 
devices"). They have a list of possible IRQs (all of them > 15) in _PRS.

The linux code for setting an IRQ is in 
drivers/acpi/pci_link.c/acpi_pci_link_set().
Theres a wee fix to make in here for my patch for the polarity etc, but your 
problem is when it creates the resource entry to send to the _SRS method.

It does something like:
if (irq <= 15) {
  ... create an IRQ resource
} else {
  ... create an extended IRQ resource
}

However, the _SRS code in your BIOS has the following for the relevant 
devices:

            Method(_SRS, 1) {
                CreateByteField(Arg0, 0x1, IRD1)
                CreateByteField(Arg0, 0x2, IRD2)
                ShiftLeft(IRD2, 0x8, Local0)
                Or(Local0, IRD1, Local0)
                Store(0x0, Local1)
                ShiftRight(Local0, 0x1, Local0)
                While(LGreater(Local0, 0x0)) {
                    Increment(Local1)
                    ShiftRight(Local0, 0x1, Local0)
                }
                And(PIRD, 0xf, PIRD)
                ShiftLeft(Local1, 0x4, Local1)
                Or(PIRD, Local1, PIRD)
            }

This assumes the resource passed to it is a normal IRQ resource, and cannot 
cope with extended ones. It only checks bytes 1&2 of the argument. For an 
extended argument, it would have to check bytes 5,6,7,8.

In linux, the call to acpi_pci_link_set() from acpi_pci_link_check() does not 
check the return status of the call. Otherwise this error would be detected.