This is probably related to: http://bugzilla.kernel.org/show_bug.cgi?id=14247
...says that it's fixed in linux-2.6.32-rc3

Thanks!  The messages do appear to be very similar to the ones in that report.  In this case, however, they've continued to occur in 2.6.32 and now .33.1.

This is bug 14733

*** This bug has been marked as a duplicate of bug 14733 ***

Hi, I am reopening this bug because (1) it is not clear to me that it really is a duplicate of bug 14733 (the error message mostly matches, but I see none of the other symptoms reported by others in that bug); and (2) something has changed between kernels 3.0.1 and 3.0.3.

In 3.0.1 I still got these error messages periodically.  In 3.0.3 I now do not seem to be getting them, but another message has appeared that I've never seen before:

[122286.091067] ACPI: EC: GPE storm detected, transactions will use polling mode

This doesn't sound good either.

Note: There is one ACPI/PM config difference between the 3.0.1 and 3.0.3 kernels - "CONFIG_PM_RUNTIME=y" was added.

Whoops, spoke too soon: the original error is still arising too:

[170533.996057] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20110413/evregion-478)
[170533.996085] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node ffff88013ae7ce98), AE_TIME (20110413/psparse-536)
[170533.996125] ACPI Exception: AE_TIME, Evaluating _BST (20110413/battery-455)

It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?

The problem still exists as of 3.2.2.

The problem still exists as of 3.4.2.

I've submit this bug also to ubuntu launchpad: https://bugs.launchpad.net/bugs/578506

It affect kernel since ubuntu 10.04, kernel version 2.6.32. Still exists with all kernel upgrade from that date.

The problem still exists as of 3.6.6.

Please attach the output of dmesg with the following patch.
https://bugzilla.kernel.org/attachment.cgi?id=96101

Debug
(1) Try with kernel parameter "ec.ec_delay=5000"

(2) Try the following patch.
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 57c676a..12aea77 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -124,7 +124,7 @@ struct transaction {
 struct acpi_ec *boot_ec, *first_ec;
 EXPORT_SYMBOL(first_ec);

-static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
+static int EC_FLAGS_MSI = 1; /* Out-of-spec MSI controller */
 static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
 static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan */

Hi, Please try this patch first. Thanks.

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d45b287..6376fd2 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -223,7 +223,7 @@ static int ec_check_sci_sync(struct acpi_ec *ec, u8 state)
 static int ec_poll(struct acpi_ec *ec)
 {
        unsigned long flags;
-       int repeat = 2; /* number of command restarts */
+       int repeat = 4; /* number of command restarts */
        while (repeat--) {
                unsigned long delay = jiffies +
                        msecs_to_jiffies(ec_delay);
@@ -241,8 +241,10 @@ static int ec_poll(struct acpi_ec *ec)
                        }
                        advance_transaction(ec, acpi_ec_read_status(ec));
                } while (time_before(jiffies, delay));
-               if (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF)
-                       break;
+
+               //if (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF)
+               //      break;
+               pr_info(PREFIX "%s: repeat %d \n", __func__, 4 - repeat);
                pr_debug(PREFIX "controller reset, restart transaction\n");
                spin_lock_irqsave(&ec->lock, flags);
                start_transaction(ec);

Hi, this bug is as same as bug 14733 and bug 48221. This issue can be resolved by Comment #13 patch. So mark this duplicate. The patch can't resolve your problem. Please feel free to reopen the bug.

*** This bug has been marked as a duplicate of bug 14733 ***

Hi,

I applied the patch in Comment #103 of bug 14733 to kernel 3.9.2.  I am still getting the following messages.  Can you please double-check whether this really is a duplicate of bug 14733.

[339580.516060] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20130117/evregion-286)
[339580.516090] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node ffff88013ae8be98), AE_TIME (20130117/psparse-537)
[339580.516127] ACPI Exception: AE_TIME, Evaluating _BST (20130117/battery-492)
[339581.024062] ACPI: EC: input buffer is not empty, aborting transaction
[339581.024076] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20130117/evregion-286)
[339581.024102] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node ffff88013ae8be98), AE_TIME (20130117/psparse-537)
[339581.024139] ACPI Exception: AE_TIME, Evaluating _BST (20130117/battery-492)
[339581.532075] ACPI: EC: input buffer is not empty, aborting transaction
[339581.532089] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20130117/evregion-286)
[339581.532115] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node ffff88013ae8be98), AE_TIME (20130117/psparse-537)
[339581.532152] ACPI Exception: AE_TIME, Evaluating _BST (20130117/battery-492)
[339582.040046] ACPI: EC: input buffer is not empty, aborting transaction
[339582.040060] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20130117/evregion-286)
[339582.040091] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node ffff88013ae8be98), AE_TIME (20130117/psparse-537)
[339582.040130] ACPI Exception: AE_TIME, Evaluating _BST (20130117/battery-492)
[339584.600085] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20130117/evregion-286)
[339584.600114] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node ffff88013ae8be98), AE_TIME (20130117/psparse-537)
[339584.600152] ACPI Exception: AE_TIME, Evaluating _BST (20130117/battery-492)
[339920.788928] ACPI: EC: GPE storm detected(9 GPEs), transactions will use polling mode

Please attach the output of dmesg with opening EC debug option and the patch in the comment 13. It's better with kernel param "log_buf_len=16M"

The following patch is to open the EC debug.
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index a4d8db1..c420e26 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -27,7 +27,7 @@
  */

 /* Uncomment next line to get verbose printout */
-/* #define DEBUG */
+#define DEBUG

 #include <linux/kernel.h>
 #include <linux/module.h>

Any update?

Although the problem persisted with the setup in comment 15, it seems the patch did make it much less frequent, so testing was not easy.

Currently running vanilla 3.9.5, and in this version it seems the logic in the ec_poll function has changed, so will run this way for a while to see if the problem recurs.

Ok. Thanks for testing. Please attach the dmesg with patch in the Comment #16 when the problem in the comment #15 occurs.

ping...

Since no response for one month, close this bug as INSUFFICIENT_DATA. Please feel free to reopen if there is any update.

Having run with 3.9.5 for some time, I can report that I no longer see the ACPI Exception messages.  I do see many of the following informational notes from the small patch:

[709211.996078] ACPI: EC: ec_poll: repeat 0 
[709212.496092] ACPI: EC: ec_poll: repeat 1 
[709212.996084] ACPI: EC: ec_poll: repeat 2 
[709213.496048] ACPI: EC: ec_poll: repeat 3 
[709242.756053] ACPI: EC: ec_poll: repeat 0 
[709243.384045] ACPI: EC: ec_poll: repeat 0 
[1159297.524088] ACPI: EC: ec_poll: repeat 0 
[1211913.260089] ACPI: EC: ec_poll: repeat 0 
[1211913.760105] ACPI: EC: ec_poll: repeat 1 
[1211977.252051] ACPI: EC: ec_poll: repeat 0 
[1211977.752066] ACPI: EC: ec_poll: repeat 1 
[1212007.256081] ACPI: EC: ec_poll: repeat 0 
[1212007.756111] ACPI: EC: ec_poll: repeat 1 
[1212008.256027] ACPI: EC: ec_poll: repeat 2 
[2183309.012084] ACPI: EC: ec_poll: repeat 0 

And I also get:

[182326.665697] ACPI: EC: GPE storm detected(9 GPEs), transactions will use polling mode

Can you confirm whether the GPE storm message is a problem and whether it's related to this issue?  If not, I think this can be closed.

GPE storm happen on some machines and ec driver has proper process of using polling mode. The important things is whether there is an exception. So this is not an issue.