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.
Attachment:
signature.asc
Description: This is a digitally signed message part
