[GIT PULL] Power management fix for 3.5-rc7

[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] ACPICA: Fix possible fault in return package object repair code

[Thomas Renninger]

From: Bob Moore <robert.moore@intel.com>

Fixes a problem that can occur when a lone package object is
wrapped with an outer package object in order to conform to
the ACPI specification. Can affect these predefined names:
_ALR,_MLS,_PSS,_TRT,_TSS,_PRT,_HPX,_DLM,_CSD,_PSD,_TSD

https://bugzilla.kernel.org/show_bug.cgi?id=44171

The bug got introduce by commit 6a99b1c94d053b3420eaa4a4bc
in v3.4-rc6, thus it needs to get pushed into 3.4 stable
kernels as well.

Reported-by: Vlastimil Babka <caster@gentoo.org>
Tested-by: Vlastimil Babka <caster@gentoo.org>
Tested-by: marc.collin@laboiteaprog.com
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
CC: stable@vger.kernel.org

---
 drivers/acpi/acpica/nspredef.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/acpica/nspredef.c b/drivers/acpi/acpica/nspredef.c
index 23ce096..fe66260 100644
--- a/drivers/acpi/acpica/nspredef.c
+++ b/drivers/acpi/acpica/nspredef.c
@@ -638,7 +638,7 @@ acpi_ns_check_package(struct acpi_predefined_data *data,
 			/* Create the new outer package and populate it */
 
 			status =
-			    acpi_ns_wrap_with_package(data, *elements,
+			    acpi_ns_wrap_with_package(data, return_object,
 						      return_object_ptr);
 			if (ACPI_FAILURE(status)) {
 				return (status);

Re: [PATCH] ACPICA: Fix possible fault in return package object repair code

[Linus Torvalds]

This needs sign-offs for the whole chain if you send it to me (ie I
need to see a sign-off from the person who sends it to me)

          Linus

On Thu, Jul 12, 2012 at 2:00 AM, Thomas Renninger <trenn@suse.de> wrote:
> From: Bob Moore <robert.moore@intel.com>
>
> Fixes a problem that can occur when a lone package object is
> wrapped with an outer package object in order to conform to
> the ACPI specification. Can affect these predefined names:
> _ALR,_MLS,_PSS,_TRT,_TSS,_PRT,_HPX,_DLM,_CSD,_PSD,_TSD
>
> https://bugzilla.kernel.org/show_bug.cgi?id=44171
>
> The bug got introduce by commit 6a99b1c94d053b3420eaa4a4bc
> in v3.4-rc6, thus it needs to get pushed into 3.4 stable
> kernels as well.
>
> Reported-by: Vlastimil Babka <caster@gentoo.org>
> Tested-by: Vlastimil Babka <caster@gentoo.org>
> Tested-by: marc.collin@laboiteaprog.com
> Signed-off-by: Bob Moore <robert.moore@intel.com>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> CC: stable@vger.kernel.org
>
> ---
>  drivers/acpi/acpica/nspredef.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/acpica/nspredef.c b/drivers/acpi/acpica/nspredef.c
> index 23ce096..fe66260 100644
> --- a/drivers/acpi/acpica/nspredef.c
> +++ b/drivers/acpi/acpica/nspredef.c
> @@ -638,7 +638,7 @@ acpi_ns_check_package(struct acpi_predefined_data *data,
>                         /* Create the new outer package and populate it */
>
>                         status =
> -                           acpi_ns_wrap_with_package(data, *elements,
> +                           acpi_ns_wrap_with_package(data, return_object,
>                                                       return_object_ptr);
>                         if (ACPI_FAILURE(status)) {
>                                 return (status);

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

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

[Rafael J. Wysocki]

On Thursday, July 12, 2012, Thomas Renninger wrote:
> 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.

Thanks for the heads up!

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

OK, I'm not sure if Len is planning a pull request any time soon, but
since I'm the cpufreq maintainer now officially I'm going push the second
patch in the next round.

As far as the ACPICA fix is concerned, I'd prefer to ask Bob and Len first
to avoid conflicts.

Thanks,
Rafael

[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 --]