diff mbox

[Karmic] SRU: Fix boot hang on Acer TravelMate 2440

Message ID 1260814593-10349-1-git-send-email-stefan.bader@canonical.com
State Accepted
Delegated to: Stefan Bader
Headers show

Commit Message

Stefan Bader Dec. 14, 2009, 6:16 p.m. UTC
SRU Justification:

Impact: Upstream changes between Jaunty and Karmic disabled the ARB_DISABLE
call as it is a NOP on recent platforms. However the test for CPU model
and version missed some systems which then hang on boot.

Fix: The following patch has been tested and was submitted upstream,
but has not been picked up, yet (but IMO is just a matter of time).
As it is a regression agains Jaunty and the impact is a non-working
system, I think this should be taken ahead of stable. It should be
safe as well as it just reduces the number of systems which get handled
the new way.

Testcase: Boot of affected systems hangs without patch.



To: lenb@kernel.org
Cc: linux-acpi@vger.kernel.org, Zhao Yakui <yakui.zhao@intel.com>,
        stable@kernel.org
Subject: [Resend PATCH] acpi: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.
Date:	Fri, 11 Dec 2009 15:17:20 +0800
From: Zhao Yakui <yakui.zhao@intel.com>

OriginalSource: linux-acpi mailing list
BugLink: http://bugs.launchpad.net/bugs/481765

ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms,
reduce contention on c3_lock by skipping the fake ARB_DISABLE.

The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box,
the box can't be booted correctly. But if we still enable ARB_DISABLE on this
box, the box can be booted correctly.

So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f.

http://bugzilla.kernel.org/show_bug.cgi?id=14700

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
cc: stable@kernel.org
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 arch/x86/kernel/acpi/cstate.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

Leann Ogasawara Dec. 15, 2009, 12:20 a.m. UTC | #1
On Mon, 2009-12-14 at 19:16 +0100, Stefan Bader wrote:
> SRU Justification:
> 
> Impact: Upstream changes between Jaunty and Karmic disabled the ARB_DISABLE
> call as it is a NOP on recent platforms. However the test for CPU model
> and version missed some systems which then hang on boot.
> 
> Fix: The following patch has been tested and was submitted upstream,
> but has not been picked up, yet (but IMO is just a matter of time).
> As it is a regression agains Jaunty and the impact is a non-working
> system, I think this should be taken ahead of stable. It should be
> safe as well as it just reduces the number of systems which get handled
> the new way.

The regression seems serious enough that we should pull this in prior to
it hitting stable.  The patch itself looks sane.

Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>

> Testcase: Boot of affected systems hangs without patch.
> 
> 
> 
> To: lenb@kernel.org
> Cc: linux-acpi@vger.kernel.org, Zhao Yakui <yakui.zhao@intel.com>,
>         stable@kernel.org
> Subject: [Resend PATCH] acpi: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.
> Date:	Fri, 11 Dec 2009 15:17:20 +0800
> From: Zhao Yakui <yakui.zhao@intel.com>
> 
> OriginalSource: linux-acpi mailing list
> BugLink: http://bugs.launchpad.net/bugs/481765
> 
> ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms,
> reduce contention on c3_lock by skipping the fake ARB_DISABLE.
> 
> The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box,
> the box can't be booted correctly. But if we still enable ARB_DISABLE on this
> box, the box can be booted correctly.
> 
> So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=14700
> 
> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
> Acked-by: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
> cc: stable@kernel.org
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  arch/x86/kernel/acpi/cstate.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
> index 59cdfa4..2e837f5 100644
> --- a/arch/x86/kernel/acpi/cstate.c
> +++ b/arch/x86/kernel/acpi/cstate.c
> @@ -48,7 +48,7 @@ void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
>  	 * P4, Core and beyond CPUs
>  	 */
>  	if (c->x86_vendor == X86_VENDOR_INTEL &&
> -	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14)))
> +	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
>  			flags->bm_control = 0;
>  }
>  EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
> -- 
> 1.5.4.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Andy Whitcroft Dec. 16, 2009, 9:16 a.m. UTC | #2
On Mon, Dec 14, 2009 at 07:16:33PM +0100, Stefan Bader wrote:
> SRU Justification:
> 
> Impact: Upstream changes between Jaunty and Karmic disabled the ARB_DISABLE
> call as it is a NOP on recent platforms. However the test for CPU model
> and version missed some systems which then hang on boot.
> 
> Fix: The following patch has been tested and was submitted upstream,
> but has not been picked up, yet (but IMO is just a matter of time).
> As it is a regression agains Jaunty and the impact is a non-working
> system, I think this should be taken ahead of stable. It should be
> safe as well as it just reduces the number of systems which get handled
> the new way.
> 
> Testcase: Boot of affected systems hangs without patch.
> 
> 
> 
> To: lenb@kernel.org
> Cc: linux-acpi@vger.kernel.org, Zhao Yakui <yakui.zhao@intel.com>,
>         stable@kernel.org
> Subject: [Resend PATCH] acpi: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.
> Date:	Fri, 11 Dec 2009 15:17:20 +0800
> From: Zhao Yakui <yakui.zhao@intel.com>
> 
> OriginalSource: linux-acpi mailing list
> BugLink: http://bugs.launchpad.net/bugs/481765
> 
> ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms,
> reduce contention on c3_lock by skipping the fake ARB_DISABLE.
> 
> The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box,
> the box can't be booted correctly. But if we still enable ARB_DISABLE on this
> box, the box can be booted correctly.
> 
> So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=14700
> 
> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
> Acked-by: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
> cc: stable@kernel.org
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  arch/x86/kernel/acpi/cstate.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
> index 59cdfa4..2e837f5 100644
> --- a/arch/x86/kernel/acpi/cstate.c
> +++ b/arch/x86/kernel/acpi/cstate.c
> @@ -48,7 +48,7 @@ void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
>  	 * P4, Core and beyond CPUs
>  	 */
>  	if (c->x86_vendor == X86_VENDOR_INTEL &&
> -	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14)))
> +	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
>  			flags->bm_control = 0;
>  }
>  EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
> -- 
> 1.5.4.5

I remember testing this one with the affected user.  Also looks good.

Acked-by: Andy Whitcroft <apw@canonical.com>

-apw
Stefan Bader Dec. 16, 2009, 2:08 p.m. UTC | #3
Applied and pushed. Update about submission: seems
to have been picked up by Len Bron (acpi maintainer)
now.

-Stefan
diff mbox

Patch

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index 59cdfa4..2e837f5 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -48,7 +48,7 @@  void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
 	 * P4, Core and beyond CPUs
 	 */
 	if (c->x86_vendor == X86_VENDOR_INTEL &&
-	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14)))
+	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
 			flags->bm_control = 0;
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);