Message ID | 1260814593-10349-1-git-send-email-stefan.bader@canonical.com |
---|---|
State | Accepted |
Delegated to: | Stefan Bader |
Headers | show |
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 >
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
Applied and pushed. Update about submission: seems to have been picked up by Len Bron (acpi maintainer) now. -Stefan
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);