* Corey Osgood <corey_osgood(a)verizon.net> [061220 03:40]:
So, how exactly do you know if it works or not, just
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
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
up on that particular board, because slot a cpus are so rare these days,
Did you get RAM stable?
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/