* Andi Kleen ak@suse.de [051123 18:36]:
You probably don't need most of it. Just a basic SRAT table (no AML methods) and enough to keep the ACPI interpreter from aborting early.
Or alternatively just fix the bug that caused you to go with discontig APICs in the first place.
Andi,
I really like your insisting way, but what we tried to express is that there is hardware that just forces you to have discontiguous APIC ids, so either you disable parts of the hardware or you are forced to do nasty things.
Wrt the ACPI tables a good rule of thumb is that if you start to have some of them you have to have them all. For example if you have a logical subset of them and try to cover the rest with PIRQ or MPTABLE you will fail because Linux moans about incorrect tables without even looking at them. And no, there is no reason for not reading a HPET table when there's no MADT available. And no, I'm not going to send a fix since I'm really not motivated to dig into that code any minute more than absolutely necessary.
I agree that there's a reason that the Linux ACPI code is as it is, but in fact as it is a reaction to zillions of buggy bioses it is not always the best solution to have clean firmware not working with it "fixed" to behave like the others out there.
Stefan