* Corey Osgood corey_osgood@verizon.net [061220 03:40]:
So, how exactly do you know if it works or not, just try it?
yes. there is no other way.
And if it fails, how do you make it "just work", is there some method for figuring out where it goes wrong?
I have seen one machine where the PIRQ created was for a _completely_ different machine. On others, the factory bios just fails to create a _working_ version. After ACPI became state of the art, the information is just not reliable anymore. It might just work and you're lucky. Or it might just not. In that case the error might go from typo in routing information all the way to totally bogus data with a pirq header.
And finally, would disabling ACPI from the factory BIOS (if there is such an option) help this?
It might. I have no idea about their code paths. If you can still use the box with acpi=off, it's a first indicator for pirq correctness.
The safest way is still implementing a simple ACPI DSDT. Have a look at LinuxBIOSv2/src/mainboard/via/epia-m/dsdt.asl for a sample of doing IRQ routing in ACPI. Its not more complex than mptable+pirq
Also, hate to hijack this, but I just noticed something from my work on the FIC SD11, in my irq_tables.c (generated by get_pir.c), it set the device ID of the southbridge (via vt686a) to 0x586, when it should have been 0x0686, according to everything I know about this board (manuals, lspci, etc). Is there some known bug in get_pir.c that could have caused this (perhaps when dealing with a PCI ID beginning with 0)?
No, this is weird and looks like an error when in fact it is not.
get_pir.c does not do anything with the information. It just dumps what it finds. So if it says 0x586 then that is what the factory bios vendor chose to put in there.
And actually not without a reason: If you look at the pirq parsing and interrupt init code in Linux, you see that it only knows a very limited number of interrupt controllers.
Linux takes the information from the pirq table and hammers it into the interrupt controller. To make that work, it has to know the register layout of that interrupt controller.
So when you read 0x586 as the device id, you can assume that the real meaning of that value is: make the OS use the vt586 register layout of the interrupt controller. In fact, the vt686 is compatible to the vt586 in that regard, so the value is fine. So, instead of just numbering the methods 0...x they chose pseudo device ids to identify the different init methods.
I've given up on that particular board, because slot a cpus are so rare these days,
Did you get RAM stable?
Stefan