On Mon, 2012-06-25 at 13:00 +0200, Thomas Renninger wrote: > ACPI processor: Only blindly return apic id 0 for real UP systems > > This fixes a "not loading acpi-cpufreq driver" regression introduced > by git commit d640113fe80e45ebd4a5b4 on SMP systems where the processor > core with ACPI id zero is disabled > (typically should be the case because of hyperthreading). > The regression got spread through stable kernels. > On 3.0.X it got introduced via 3.0.18. > > Such platforms may be rare, but do exist. This problem has been > observed on a: > HP Proliant BL280c G6 blade > This patch restricts the introduced workaround to platforms > with nr_cpu_ids <= 1.
This is not the correct way to submit a patch to stable. See
Documentation/stable_kernel_rules.txt.
Also, patches to mainline should be made against mainline, not the
distribution branch you have to hand.
[...]
> - * Ignores apic_id and always return 0 for CPU0's handle.
> + * Ignores apic_id and always returns 0 for the processor
> + * handle with apic id 0 if nr_cpu_ids is 1.
> + * This should be the case if SMP tables are not found.
[...]
Second 'apic id' should be 'acpi_id'.
Ben.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.
signature.asc
Description: This is a digitally signed message part
