On 8/12/07, Andi Kleen <ak@xxxxxxx> wrote: > On Sunday 12 August 2007 04:42, Len Brown wrote: > I think it's because LinuxBIOS which Y.H. is working on is unable/unwilling > to supply any ACPI tables. So he prefers to kludge around it in the kernel > to adapt to the ever changing hardware. > > I already had this argument recently about k8topology.c. It's getting > messier and messier and I would really like to retire it (it was originally > only written for a very early BIOS without SRAT); the only > reason not to is LinuxBIOS. > > Apparently one problem is that the Linux ACPI code is not very > friendly to partial tables (e.g. only SRAT); perhaps that is something > that could be improved. > > I skipped these hacks for now because I'm quite sceptical of them. maybe for intel x86_64, it is hard to make kernel with numa enabled with acpi=off. but for amd k8 based system (even for later ...), it is rather simple and clear to make numa enabled together bus enable... with acpi=off. i don't think my patch has problem with intel platform. I like to make the cluster (with two way above, with two ht chain) to work properly with acpi=off. also we can use that as good debug feature... it is good to verify system/hw/bios could work with kernel (acpi=off). So other os without acpi support or with broken acpi support still can work... BTW: does any intel x86_64 system support numa/bus_numa? YH - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
