I have also noticed that the irq_tables.c that getpir gave me gives me the wrong checksum. I don't know if this is an error in the pir of the factory bios or the getpir. I'll have to look into this more. Just another example of irq_tables.c not being right.
Jon
On 12/19/06, Corey Osgood corey_osgood@verizon.net wrote:
Li-Ta Lo wrote:
On Tue, 2006-12-19 at 17:17 -0500, Jon Dufresne wrote:
In that case this utility program is very misleading, at least to me. Perhaps a large comment should be added to the .c file that either gives a warning that it is incomplete or tips on what to add.
There is no way for the utility to know if it is generating something useful. There is zero intelligence in the utility and it just dumps whatever it is in the memory in a human and compiler readable form. This is a totally use at your own risk thing.
Ollie
So, how exactly do you know if it works or not, just try it? And if it fails, how do you make it "just work", is there some method for figuring out where it goes wrong? And finally, would disabling ACPI from the factory BIOS (if there is such an option) help this?
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)? I've given up on that particular board, because slot a cpus are so rare these days, but the tyan s2507 (my next target) uses a chip with the same PCI ID. I'll test the script on that once I get done recompiling the entire system (god bless gentoo).
-Corey
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios