2.6.35-rc3 regression: IBM Maia system is unbootable [ACPI related?]
in [Kernel]
|
Prev: [PATCH] X86: intel_ips, check for kzalloc properly
Next: [PATCH 8/8 v2]tuners:tuner-simple Fix warning: variable 'tun' set but not used
From: Len Brown on 29 Jun 2010 00:00 From: Len Brown <len.brown(a)intel.com> Subject: [PATCH] ACPI: handle systems which asynchoronously enable ACPI mode Folklore suggested that such systems existed in the pre-history of ACPI. However, we removed the SCI_EN polling loop from acpi_hw_set_mode() in b430acbd7c4b919886fa7fd92eeb7a695f1940d3 because it delayed resume by 3 seconds on boxes that refused to set SCI_EN. Matthew removed the call to acpi_enable() from the suspend resume path. James found a modern system that still needs to be polled upon boot. So here we restore the workaround, except that we put it in acpi_enable() rather than the low level acpi_hw_set_mode(). https://bugzilla.kernel.org/show_bug.cgi?id=16271 Signed-off-by: Len Brown <len.brown(a)intel.com> --- James, What does the IBM system see with this patch? thanks, -Len drivers/acpi/acpica/evxfevnt.c | 19 +++++++++++-------- 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/acpi/acpica/evxfevnt.c b/drivers/acpi/acpica/evxfevnt.c index d97b8dc..18b3f14 100644 --- a/drivers/acpi/acpica/evxfevnt.c +++ b/drivers/acpi/acpica/evxfevnt.c @@ -70,6 +70,7 @@ acpi_ev_get_gpe_device(struct acpi_gpe_xrupt_info *gpe_xrupt_info, acpi_status acpi_enable(void) { acpi_status status; + int retry; ACPI_FUNCTION_TRACE(acpi_enable); @@ -98,16 +99,18 @@ acpi_status acpi_enable(void) /* Sanity check that transition succeeded */ - if (acpi_hw_get_mode() != ACPI_SYS_MODE_ACPI) { - ACPI_ERROR((AE_INFO, - "Hardware did not enter ACPI mode")); - return_ACPI_STATUS(AE_NO_HARDWARE_RESPONSE); + for (retry = 0; retry < 30000; ++retry) { + if (acpi_hw_get_mode() == ACPI_SYS_MODE_ACPI) { + if (retry != 0) + ACPI_WARNING((AE_INFO, + "Platform took > %d00 usec to enter ACPI mode", retry)); + return_ACPI_STATUS(AE_OK); + } + acpi_os_stall(100); /* 100 usec */ } - ACPI_DEBUG_PRINT((ACPI_DB_INIT, - "Transition to ACPI mode successful\n")); - - return_ACPI_STATUS(AE_OK); + ACPI_ERROR((AE_INFO, "Hardware did not enter ACPI mode")); + return_ACPI_STATUS(AE_NO_HARDWARE_RESPONSE); } ACPI_EXPORT_SYMBOL(acpi_enable) -- 1.7.2.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 29 Jun 2010 00:10 On Mon, 2010-06-28 at 17:59 -0400, Len Brown wrote: > Is this a production system with a production BIOS? It's got a production BIOS, yes ... not sure about the system, it might be a B model. > BTW, "Instantly" here isn't actually instantly, it is > "before the return from SMM". ENOCONTEXT? As I explained in the previous email, it takes about 1ms before it reports as entered ACPI mode. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 29 Jun 2010 12:50
On Mon, 2010-06-28 at 23:49 -0400, Len Brown wrote: > From: Len Brown <len.brown(a)intel.com> > Subject: [PATCH] ACPI: handle systems which asynchoronously enable ACPI mode > > Folklore suggested that such systems existed > in the pre-history of ACPI. > > However, we removed the SCI_EN polling loop from > acpi_hw_set_mode() in b430acbd7c4b919886fa7fd92eeb7a695f1940d3 > because it delayed resume by 3 seconds on boxes > that refused to set SCI_EN. > > Matthew removed the call to acpi_enable() from > the suspend resume path. > > James found a modern system that still needs to be polled > upon boot. > > So here we restore the workaround, except that we > put it in acpi_enable() rather than the low level > acpi_hw_set_mode(). > > https://bugzilla.kernel.org/show_bug.cgi?id=16271 > > Signed-off-by: Len Brown <len.brown(a)intel.com> > --- > > James, What does the IBM system see with this patch? The output is this: [ 0.084088] ACPI: Core revision 20100428 [ 0.119451] ACPI Warning: Platform took > 100 usec to enter ACPI mode (20100428/evxfevnt-106) [ 0.128231] Setting APIC routing to physical flat So it's very fast ... actually it's behaving like there's some caching issue and it needs two reads to return the correct value James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |