https://bugzilla.kernel.org/show_bug.cgi?id=45151
--- Comment #24 from Feng Tang <feng.t...@intel.com> 2012-08-21 15:44:57 ---
>
> > Yes, that's weird, Comment #1 should work while Comment #9 should not which
> > simply add some debug info.
> There is something that is worse, now in all four test the acpi work
> correctly!
> I do not understand how the "debug string" can change this behavior.
I don't think these are worse :) As I said before, this issue is highly bound
with EC driver, with these lots of ACPI debug info, the timing is changed,
which makes your EC driver work "normally" in interrupt mode, not polling mode
(you can't find "GPE storm" info any more in these dmesgs).
Could you try the following patch _only_ without any previou patches or those
"debug string" in cmdline?
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 7edaccc..9196ab6 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -71,7 +71,7 @@ enum ec_command {
#define ACPI_EC_UDELAY_GLK 1000 /* Wait 1ms max. to get global lock */
#define ACPI_EC_MSI_UDELAY 550 /* Wait 550us for MSI EC */
-#define ACPI_EC_STORM_THRESHOLD 8 /* number of false interrupts
+#define ACPI_EC_STORM_THRESHOLD 20 /* number of false interrupts
per one transaction */
enum {
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
