On Sat, 27 Jan 2007 04:29:57 -0500 Len Brown <lenb@xxxxxxxxxx> wrote: > On Friday 26 January 2007 20:24, Andrew Morton wrote: > > > > The new stuff which just landed in Len's tree caused a huge mess in > > arch/x86_64/kernel/genapic.c:clustered_apic_check() when applying > > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/always-use-physical-delivery-mode-on-8-cpus > > on top of it. > > The ACPI change this cleanup patch is conflicting with is quite small: > > ------------------------- arch/x86_64/kernel/genapic.c ------------------------- > index b007433..0b3603a 100644 > @@ -58,8 +58,8 @@ void __init clustered_apic_check(void) > * Some x86_64 machines use physical APIC mode regardless of how many > * procs/clusters are present (x86_64 ES7000 is an example). > */ > - if (acpi_fadt.revision > FADT2_REVISION_ID) > - if (acpi_fadt.force_apic_physical_destination_mode) { > + if (acpi_gbl_FADT.header.revision > FADT2_REVISION_ID) > + if (acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL) { > genapic = &apic_cluster; > goto print; > } > > In fact the ACPI change has trashed a fair slice of Andi's pending tree. > > > > I think I'll revert to yesterday's git-acpi, let you guys sort it all out. > > Send me a version of the always-use-physical-delivery-mode-on-8-cpus patch > that applies to Linus' tree (the one above doesn't), and I'll be happy to apply > the 2-line diff above to it. > OK, so I took another look. This ACPI update does extensive damage to Andi's pending queue. I fixed four patches, dropped four or five more, hit more problems then gave up again. I'll go back to Thursday's git-acpi again. Longer-term, I expect Andi will merge before acpi does, and you're looking at a fairly large amount of fixing after that happens. - 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
