[PATCH] Fix not loading acpi-cpufreq driver regression

[PATCH] Fix not loading acpi-cpufreq driver regression

[Thomas Renninger]

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.

Signed-off-by: Thomas Renninger <trenn@suse.de>

---
 drivers/acpi/processor_core.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: linux-3.0-SLE11-SP2/drivers/acpi/processor_core.c
===================================================================
--- linux-3.0-SLE11-SP2.orig/drivers/acpi/processor_core.c
+++ linux-3.0-SLE11-SP2/drivers/acpi/processor_core.c
@@ -201,10 +201,12 @@ int acpi_get_cpuid(acpi_handle handle, i
 		 *     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 apic 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;

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

[Thomas Renninger]

On Monday, June 25, 2012 01:00:10 PM 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.

Wallak:
Can you give this patch a try and double check whether things still
work for you.
If I understand it correctly you tried a UP compiled kernel?
On this one I expect nr_cpu_ids to be statically set to 1 and the
patch should be fine for you.

The only other candidate I can think of which needs this,
are platforms with only 1 core available and no SMP APIC/ACPI mapping 
table, but a
Processor (...)
ACPI object.
Those should also still be covered with my patch.

Thanks,

   Thomas

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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

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

[Thomas Renninger]

...
> > 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.
I guess I should add
CC: stable@vger.kernel.org
in the signed-off area, not in the mail header?

 
> Also, patches to mainline should be made against mainline, not the
> distribution branch you have to hand.
Wow, the diff patched with offset only against a reasonable recent
kernel (3.5-rcX). But yes: It does not anymore after doing a git pull.
I'll resend.

> 
> [...]
> > -                * 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'.
Correct.

Thanks,

   Thomas

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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On Mon, 2012-06-25 at 16:39 +0200, Thomas Renninger wrote:
> ...
> > > 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.
> I guess I should add
> CC: stable@vger.kernel.org
> in the signed-off area, not in the mail header?
[...]

Right.  You may put it in the mail header, but it *must* be in the
commit message so that it can be picked up after it lands in Linus's
tree.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

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

[Thomas Renninger]

ACPI processor: Only blindly return apic id 0 for real UP systems

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

---
 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;

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

[Thomas Renninger]

Hi,

On Monday, June 25, 2012 05:39:58 PM Thomas Renninger wrote:
> ACPI processor: Only blindly return apic id 0 for real UP systems

what is the state here?
I expect it needs to go mainline (3.5-rc6?) via Len first before
showing up in stable?
Len: Can you push this one please, it fixes a regression which got
spread through stable kernels.

Thanks,

   Thomas
> 
> 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
> 
> ---
>  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;
> 

[GIT PULL] Power management fix for 3.5-rc7

[Rafael J. Wysocki]

Hi Linus,

Please pull one power management fix for 3.5-rc7 on top of commit
bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a:

  Linux 3.5-rc6

with commit hash dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a

  ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume

from the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-for-3.5-rc7

It removes some old code known to cause problems to happen that was
re-introduced by mistake during the 3.4 merge window.  Since this code causes
systems to crash and the fix is -stable material, I'm regarding it as serious
enough.  It technically belongs to ACPI, but since it affects suspend/resume
I hope Len won't mind me pushing it.

Thanks!


 drivers/acpi/acpica/hwsleep.c | 22 ----------------------
 1 file changed, 22 deletions(-)

---------------

Jonathan Nieder (1):
      ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume

Re: [GIT PULL] Power management fix for 3.5-rc7

[Thomas Renninger]

Hi,

On Wednesday, July 11, 2012 07:43:19 PM Rafael J. Wysocki wrote:
> Hi Linus,
> 
> Please pull one power management fix for 3.5-rc7...

There are two patches (at least these, maybe Len has more?)
from the ACPI area which should still show up in 3.5.
I take the chance and use this thread to draw attention to
these, so that they do not fall off (especially one is critical).

No idea whether they first have to go through Len's
tree. I searched there but couldn't find them commited
in the release branch.

I'll post them to this thread, based on latest Linus' master.

   Thomas

[PATCH] Fix not loading acpi-cpufreq driver regression

[Thomas Renninger]

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

---
 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;

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

[Rafael J. Wysocki]

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;
> 
>