On Mon, Feb 28, 2011 at 12:02 PM, Mike Travis <travis@xxxxxxx> wrote: > > > Yinghai Lu wrote: >> >> On Mon, Feb 28, 2011 at 11:23 AM, Mike Travis <travis@xxxxxxx> wrote: >>> >>> Yinghai Lu wrote: >>>> >>>> On 02/27/2011 04:15 AM, Ingo Molnar wrote: >>>>> >>>>> * Ingo Molnar <mingo@xxxxxxx> wrote: >>>>> >>>>>> You could avoid all this ugly workaround of bootmem limitations by >>>>>> moving the allocation to memblock_alloc() and desupporting the >>>>>> log_buf_len= >>>>>> boot parameter on non-memblock architectures. >>>>> >>>>> memblock_alloc() could return -ENOSYS on architectures that do not >>>>> implement it - thus enabling such optional features without ugly #ifdef >>>>> CONFIG_HAVE_MEMBLOCK conditionals. >>>> >>>> Mike, >>>> >>>> please check updated patch... >>>> >>>> with the memblock change, you don't need to change acpi SRAT handling >>>> etc >>>> any more. >>> >>> I had to debug a weird ACPI -> Node mapping last week and the >>> "improved" SRAT messages helped that considerably. It was >>> far easier to spot which Node didn't have the correct assignments. >>> I'd submit that patch even without needing fewer (like 512 lines >>> max instead of 4096 lines max) bytes in the log buffer. >> >> Your current change to ACPI srat is not complete yet. >> >> you only handle x2apic entries. >> >> According to ACPI 4.0 spec, We should have mixed entries with apic >> entries and x2apic entries. >> apic entries are for apic id < 255. >> x2apic entries are for apic id > 255. >> >> Yinghai > > Are you sure you can run both "legacy" and "x2" apic modes in > the same SSI under the Intel or AMD rules? > No. According to ACPI 4.0 Spec: even the CPUs are with x2apic mode (aka pre-enabled in BIOS), if their apic id < 255, BIOS still need to use xapic entries for them. Yinghai -- 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
