* Andi Kleen <[email protected]> [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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
