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

[Andy Whitcroft]

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 at kernel.org
> Cc: linux-acpi at vger.kernel.org, Zhao Yakui <yakui.zhao at intel.com>,
>         stable at 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 at 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 at intel.com>
> Acked-by: Pallipadi, Venkatesh <venkatesh.pallipadi at intel.com>
> cc: stable at kernel.org
> Signed-off-by: Stefan Bader <stefan.bader at 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 at canonical.com>

-apw