On Mon, 2010-06-28 at 23:49 -0400, Len Brown wrote: > From: Len Brown <len.brown@xxxxxxxxx> > 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@xxxxxxxxx> > --- > > 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
