Re: [PATCH] Fix not loading acpi-cpufreq driver regression

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday, July 12, 2012, Thomas Renninger wrote:
> Commit d640113fe80e45ebd4a5b420b introduced a regression 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.
> Look out for a disabled processor with acpi_id 0 in dmesg:
> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)
> 
> 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.
> 
> Signed-off-by: Thomas Renninger <trenn@suse.de>
> CC: stable@vger.kernel.org

Applied to the pm-cpufreq branch of the linux-pm.git tree.

Thanks,
Rafael


> ---
>  drivers/acpi/processor_core.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index c850de4..eff7222 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -189,10 +189,12 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
>  		 *     Processor (CPU3, 0x03, 0x00000410, 0x06) {}
>  		 * }
>  		 *
> -		 * Ignores apic_id and always return 0 for CPU0's handle.
> +		 * Ignores apic_id and always returns 0 for the processor
> +		 * handle with acpi id 0 if nr_cpu_ids is 1.
> +		 * This should be the case if SMP tables are not found.
>  		 * Return -1 for other CPU's handle.
>  		 */
> -		if (acpi_id == 0)
> +		if (nr_cpu_ids <= 1 && acpi_id == 0)
>  			return acpi_id;
>  		else
>  			return apic_id;
> 
>