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

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

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

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