ACPI: EC: GPE storm detected, disabling EC GPE

ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

Well; I was hoping it was going to be just an easy fix, but unfortunately
changing
 if (atomic_read(&ec->irq_count) > 5) {
 to
if (atomic_read(&ec->irq_count) > 20) {
does seem to make the message disappear, for a while, probably at
around three hours,(for me at least) then the message appeared again.
:-(
So leaving me back to the beginning of try to have a go at this.
regards;
-- 
Justin P. Mattock

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Andrew Morton]

On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <justinmattock@gmail.com> wrote:

> Well; I was hoping it was going to be just an easy fix, but unfortunately
> changing
>  if (atomic_read(&ec->irq_count) > 5) {
>  to
> if (atomic_read(&ec->irq_count) > 20) {
> does seem to make the message disappear, for a while, probably at
> around three hours,(for me at least) then the message appeared again.
> :-(
> So leaving me back to the beginning of try to have a go at this.
> regards;

I removed bugzilla from cc - that only works if there's [Bug 1234] in
the Subject:.

I added linux-acpi to cc - this is an acpi problem.

What Justin is mysteriously referring to here is:


: From: "Justin Mattock" <justinmattock@gmail.com>
: To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
: Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
: Subject: GPE storm detected, disabling EC GPE
: Date: 	Thu, 5 Jun 2008 21:01:55 +0000
: Sender: linux-kernel-owner@vger.kernel.org
: 
: FWIW I noticed a post where the person had changed 5 to 20, and it
: seemed to work for them;
: So with that in mind I decide to give that a go, here is the location:
: drivers/acpi/ec.c
: @@ -527,47 +488,51 @@ static u32 acpi_ec_gpe_handler(void *data)
:  {
:         acpi_status status = AE_OK;
:         struct acpi_ec *ec = data;
:        u8 state = acpi_ec_read_status(ec);
: 
:         pr_debug(PREFIX "~~~> interrupt\n");
:        atomic_inc(&ec->irq_count);
: -       if (atomic_read(&ec->irq_count) > 5) {
: +       if (atomic_read(&ec->irq_count) > 20) {
:                pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
:                ec_switch_to_poll_mode(ec);
:                goto end;
:        }
: 
: Now I don't know if this will work for other brands, but for
: me(Macbook Pro ATI chipset) I have not received the
: GPE storm detected, disabling EC GPE message, but it's only been an
: hour, maybe after two or three this might appear.
: Also is this good or bad to set 5 to 20 for the system?

Could someone from acpi land please help here?

Justin, has this machine always had this problem or is it something
which earlier kernels handled correctly?

Thanks.

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Maxim Levitsky]

On Saturday, 7 June 2008 09:55:26 Andrew Morton wrote:
> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <justinmattock@gmail.com> wrote:
> 
> > Well; I was hoping it was going to be just an easy fix, but unfortunately
> > changing
> >  if (atomic_read(&ec->irq_count) > 5) {
> >  to
> > if (atomic_read(&ec->irq_count) > 20) {
> > does seem to make the message disappear, for a while, probably at
> > around three hours,(for me at least) then the message appeared again.
> > :-(
> > So leaving me back to the beginning of try to have a go at this.
> > regards;
> 
> I removed bugzilla from cc - that only works if there's [Bug 1234] in
> the Subject:.
> 
> I added linux-acpi to cc - this is an acpi problem.
> 
> What Justin is mysteriously referring to here is:
> 
> 
> : From: "Justin Mattock" <justinmattock@gmail.com>
> : To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
> : Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> : Subject: GPE storm detected, disabling EC GPE
> : Date: 	Thu, 5 Jun 2008 21:01:55 +0000
> : Sender: linux-kernel-owner@vger.kernel.org
> : 
> : FWIW I noticed a post where the person had changed 5 to 20, and it
> : seemed to work for them;
> : So with that in mind I decide to give that a go, here is the location:
> : drivers/acpi/ec.c
> : @@ -527,47 +488,51 @@ static u32 acpi_ec_gpe_handler(void *data)
> :  {
> :         acpi_status status = AE_OK;
> :         struct acpi_ec *ec = data;
> :        u8 state = acpi_ec_read_status(ec);
> : 
> :         pr_debug(PREFIX "~~~> interrupt\n");
> :        atomic_inc(&ec->irq_count);
> : -       if (atomic_read(&ec->irq_count) > 5) {
> : +       if (atomic_read(&ec->irq_count) > 20) {
> :                pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
> :                ec_switch_to_poll_mode(ec);
> :                goto end;
> :        }
> : 
> : Now I don't know if this will work for other brands, but for
> : me(Macbook Pro ATI chipset) I have not received the
> : GPE storm detected, disabling EC GPE message, but it's only been an
> : hour, maybe after two or three this might appear.
> : Also is this good or bad to set 5 to 20 for the system?
> 
> Could someone from acpi land please help here?
> 
> Justin, has this machine always had this problem or is it something
> which earlier kernels handled correctly?
> 
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

I have acer aspire 5720G which shows this message in latest -git
but doesn't show it in ubuntu 2.6.24 kernel.

I also noticed that in -git volume wheel behaves strangely, it sometimes increases volume
when I rotate it in direction of decrease, and vise versa.

Since the EC is in charge of volume wheel, it could be related.

Best regards,
	Maxim Levitsky

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Guillaume Chazarain]

On Sat, Jun 7, 2008 at 12:59 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> I also noticed that in -git volume wheel behaves strangely, it sometimes increases volume
> when I rotate it in direction of decrease, and vise versa.

I have a similar problem, the ACPI keys on my laptop are very laggy
(like 1 second), maybe you are seeing the same thing with your volume
wheel?

changing
 if (atomic_read(&ec->irq_count) > 5) {
 to
if (atomic_read(&ec->irq_count) > 20) {
fixed the problem completely for me.

It's all in http://bugzilla.kernel.org/show_bug.cgi?id=9998

Cheers.

-- 
Guillaume

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <justinmattock@gmail.com> wrote:
>
>> Well; I was hoping it was going to be just an easy fix, but unfortunately
>> changing
>>  if (atomic_read(&ec->irq_count) > 5) {
>>  to
>> if (atomic_read(&ec->irq_count) > 20) {
>> does seem to make the message disappear, for a while, probably at
>> around three hours,(for me at least) then the message appeared again.
>> :-(
>> So leaving me back to the beginning of try to have a go at this.
>> regards;
>
> I removed bugzilla from cc - that only works if there's [Bug 1234] in
> the Subject:.
>
> I added linux-acpi to cc - this is an acpi problem.
>
> What Justin is mysteriously referring to here is:
>
>
> : From: "Justin Mattock" <justinmattock@gmail.com>
> : To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
> : Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> : Subject: GPE storm detected, disabling EC GPE
> : Date:         Thu, 5 Jun 2008 21:01:55 +0000
> : Sender: linux-kernel-owner@vger.kernel.org
> :
> : FWIW I noticed a post where the person had changed 5 to 20, and it
> : seemed to work for them;
> : So with that in mind I decide to give that a go, here is the location:
> : drivers/acpi/ec.c
> : @@ -527,47 +488,51 @@ static u32 acpi_ec_gpe_handler(void *data)
> :  {
> :         acpi_status status = AE_OK;
> :         struct acpi_ec *ec = data;
> :        u8 state = acpi_ec_read_status(ec);
> :
> :         pr_debug(PREFIX "~~~> interrupt\n");
> :        atomic_inc(&ec->irq_count);
> : -       if (atomic_read(&ec->irq_count) > 5) {
> : +       if (atomic_read(&ec->irq_count) > 20) {
> :                pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
> :                ec_switch_to_poll_mode(ec);
> :                goto end;
> :        }
> :
> : Now I don't know if this will work for other brands, but for
> : me(Macbook Pro ATI chipset) I have not received the
> : GPE storm detected, disabling EC GPE message, but it's only been an
> : hour, maybe after two or three this might appear.
> : Also is this good or bad to set 5 to 20 for the system?
>
> Could someone from acpi land please help here?
>
> Justin, has this machine always had this problem or is it something
> which earlier kernels handled correctly?
>
> Thanks.
>

This issue just recently started, 2.6.25-rc9 and below don't give me
this message.

-- 
Justin P. Mattock

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Alexey Starikovskiy]

Justin Mattock wrote:
> On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <justinmattock@gmail.com> wrote:
>>
>>> Well; I was hoping it was going to be just an easy fix, but unfortunately
>>> changing
>>>  if (atomic_read(&ec->irq_count) > 5) {
>>>  to
>>> if (atomic_read(&ec->irq_count) > 20) {
>>> does seem to make the message disappear, for a while, probably at
>>> around three hours,(for me at least) then the message appeared again.
>>> :-(
>>> So leaving me back to the beginning of try to have a go at this.
>>> regards;
>> I removed bugzilla from cc - that only works if there's [Bug 1234] in
>> the Subject:.
>>
>> I added linux-acpi to cc - this is an acpi problem.
>>
>> What Justin is mysteriously referring to here is:
>>
>>
>> : From: "Justin Mattock" <justinmattock@gmail.com>
>> : To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
>> : Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
>> : Subject: GPE storm detected, disabling EC GPE
>> : Date:         Thu, 5 Jun 2008 21:01:55 +0000
>> : Sender: linux-kernel-owner@vger.kernel.org
>> :
>> : FWIW I noticed a post where the person had changed 5 to 20, and it
>> : seemed to work for them;
>> : So with that in mind I decide to give that a go, here is the location:
>> : drivers/acpi/ec.c
>> : @@ -527,47 +488,51 @@ static u32 acpi_ec_gpe_handler(void *data)
>> :  {
>> :         acpi_status status = AE_OK;
>> :         struct acpi_ec *ec = data;
>> :        u8 state = acpi_ec_read_status(ec);
>> :
>> :         pr_debug(PREFIX "~~~> interrupt\n");
>> :        atomic_inc(&ec->irq_count);
>> : -       if (atomic_read(&ec->irq_count) > 5) {
>> : +       if (atomic_read(&ec->irq_count) > 20) {
>> :                pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
>> :                ec_switch_to_poll_mode(ec);
>> :                goto end;
>> :        }
>> :
>> : Now I don't know if this will work for other brands, but for
>> : me(Macbook Pro ATI chipset) I have not received the
>> : GPE storm detected, disabling EC GPE message, but it's only been an
>> : hour, maybe after two or three this might appear.
>> : Also is this good or bad to set 5 to 20 for the system?
>>
>> Could someone from acpi land please help here?
>>
>> Justin, has this machine always had this problem or is it something
>> which earlier kernels handled correctly?
>>
>> Thanks.
>>
> 
> This issue just recently started, 2.6.25-rc9 and below don't give me
> this message.
> 
Yes, the problem which we are fighting here is that almost all Acer notebooks come with
broken EC. It sends interrupts not regarding the fact that we already ACKed it.
It comes unnoticed on almost all machines (some notice laggy keyboard, because it's 
the same controller after all and it's busy with sending ACPI interrupts and then 
providing same status byte over and over), but on some machines keystrokes become 
missing, which is not tolerable (#9998).
Acer technical support does not care about the issue as they don't support Linux on these machines,
and Windows seems to be fine.
There is a similar bug report #10724, with two suggested patches, which should increase a threshold of 
stray interrupts before we shutdown them and switch to poll mode.

Regards,
Alex.

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

On Sat, Jun 7, 2008 at 7:28 PM, Alexey Starikovskiy
<astarikovskiy@suse.de> wrote:
> Justin Mattock wrote:
>>
>> On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton <akpm@linux-foundation.org>
>> wrote:
>>>
>>> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock"
>>> <justinmattock@gmail.com> wrote:
>>>
>>>> Well; I was hoping it was going to be just an easy fix, but
>>>> unfortunately
>>>> changing
>>>>  if (atomic_read(&ec->irq_count) > 5) {
>>>>  to
>>>> if (atomic_read(&ec->irq_count) > 20) {
>>>> does seem to make the message disappear, for a while, probably at
>>>> around three hours,(for me at least) then the message appeared again.
>>>> :-(
>>>> So leaving me back to the beginning of try to have a go at this.
>>>> regards;
>>>
>>> I removed bugzilla from cc - that only works if there's [Bug 1234] in
>>> the Subject:.
>>>
>>> I added linux-acpi to cc - this is an acpi problem.
>>>
>>> What Justin is mysteriously referring to here is:
>>>
>>>
>>> : From: "Justin Mattock" <justinmattock@gmail.com>
>>> : To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
>>> : Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
>>> : Subject: GPE storm detected, disabling EC GPE
>>> : Date:         Thu, 5 Jun 2008 21:01:55 +0000
>>> : Sender: linux-kernel-owner@vger.kernel.org
>>> :
>>> : FWIW I noticed a post where the person had changed 5 to 20, and it
>>> : seemed to work for them;
>>> : So with that in mind I decide to give that a go, here is the location:
>>> : drivers/acpi/ec.c
>>> : @@ -527,47 +488,51 @@ static u32 acpi_ec_gpe_handler(void *data)
>>> :  {
>>> :         acpi_status status = AE_OK;
>>> :         struct acpi_ec *ec = data;
>>> :        u8 state = acpi_ec_read_status(ec);
>>> :
>>> :         pr_debug(PREFIX "~~~> interrupt\n");
>>> :        atomic_inc(&ec->irq_count);
>>> : -       if (atomic_read(&ec->irq_count) > 5) {
>>> : +       if (atomic_read(&ec->irq_count) > 20) {
>>> :                pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
>>> :                ec_switch_to_poll_mode(ec);
>>> :                goto end;
>>> :        }
>>> :
>>> : Now I don't know if this will work for other brands, but for
>>> : me(Macbook Pro ATI chipset) I have not received the
>>> : GPE storm detected, disabling EC GPE message, but it's only been an
>>> : hour, maybe after two or three this might appear.
>>> : Also is this good or bad to set 5 to 20 for the system?
>>>
>>> Could someone from acpi land please help here?
>>>
>>> Justin, has this machine always had this problem or is it something
>>> which earlier kernels handled correctly?
>>>
>>> Thanks.
>>>
>>
>> This issue just recently started, 2.6.25-rc9 and below don't give me
>> this message.
>>
> Yes, the problem which we are fighting here is that almost all Acer
> notebooks come with
> broken EC. It sends interrupts not regarding the fact that we already ACKed
> it.
> It comes unnoticed on almost all machines (some notice laggy keyboard,
> because it's the same controller after all and it's busy with sending ACPI
> interrupts and then providing same status byte over and over), but on some
> machines keystrokes become missing, which is not tolerable (#9998).
> Acer technical support does not care about the issue as they don't support
> Linux on these machines,
> and Windows seems to be fine.
> There is a similar bug report #10724, with two suggested patches, which
> should increase a threshold of stray interrupts before we shutdown them and
> switch to poll mode.
>
> Regards,
> Alex.
>
>
>
>
>
>
>
>

Interesting, over here I'm using a Macbook Pro ATI chipset. I'm not
experiencing things like missing keys or anything of that nature.
but am concerned with what might happen to the hardware in the long
run. As for the patches I did apply those,
and it did give me a better idea of what is happening., but just to
get a right info, when ACPI: EC: gpe storm detected message appears
does it disable interrupt mode for that moment and then go back to it
original state, or is it once the gpe storm is triggered the interupt
mode is disabled until a reboot is performed. from looking at the data
from the patches that I used from here it looks like something in the
system triggers that message, but then after a few seconds  goes back
to its original state, until another storm is detected.
I don't have a problem with this message if it's triggering and then
returning to it's original state until another storm triggers this
message again, but I am concerned with the message being triggered,
and then the system is stuck in that mode until a reboot.(but if this
is O.K. for the system then that's cool too).
regards;

-- 
Justin P. Mattock

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Alexey Starikovskiy]

Justin Mattock wrote:
> Interesting, over here I'm using a Macbook Pro ATI chipset. I'm not
> experiencing things like missing keys or anything of that nature.
> but am concerned with what might happen to the hardware in the long
> run. As for the patches I did apply those,
> and it did give me a better idea of what is happening., but just to
> get a right info, when ACPI: EC: gpe storm detected message appears
> does it disable interrupt mode for that moment and then go back to it
> original state, or is it once the gpe storm is triggered the interupt
> mode is disabled until a reboot is performed. from looking at the data
> from the patches that I used from here it looks like something in the
> system triggers that message, but then after a few seconds  goes back
> to its original state, until another storm is detected.
> I don't have a problem with this message if it's triggering and then
> returning to it's original state until another storm triggers this
> message again, but I am concerned with the message being triggered,
> and then the system is stuck in that mode until a reboot.(but if this
> is O.K. for the system then that's cool too).
If interrupt storm from EC is detected EC interrupt will be disabled permanently.
EC driver then starts to poll hardware for events in half-second interval, so it is
still fully functional, but may be there is going to be impact on power consumption, etc.

Regards,
Alex.

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

On Sat, Jun 7, 2008 at 9:27 PM, Alexey Starikovskiy
<astarikovskiy@suse.de> wrote:
> Justin Mattock wrote:
>>
>> Interesting, over here I'm using a Macbook Pro ATI chipset. I'm not
>> experiencing things like missing keys or anything of that nature.
>> but am concerned with what might happen to the hardware in the long
>> run. As for the patches I did apply those,
>> and it did give me a better idea of what is happening., but just to
>> get a right info, when ACPI: EC: gpe storm detected message appears
>> does it disable interrupt mode for that moment and then go back to it
>> original state, or is it once the gpe storm is triggered the interupt
>> mode is disabled until a reboot is performed. from looking at the data
>> from the patches that I used from here it looks like something in the
>> system triggers that message, but then after a few seconds  goes back
>> to its original state, until another storm is detected.
>> I don't have a problem with this message if it's triggering and then
>> returning to it's original state until another storm triggers this
>> message again, but I am concerned with the message being triggered,
>> and then the system is stuck in that mode until a reboot.(but if this
>> is O.K. for the system then that's cool too).
>
> If interrupt storm from EC is detected EC interrupt will be disabled
> permanently.
> EC driver then starts to poll hardware for events in half-second interval,
> so it is
> still fully functional, but may be there is going to be impact on power
> consumption, etc.
>
> Regards,
> Alex.
>

Hmmm, power consumption., well that's not bad, but maybe I should be
concerned with my battery, maybe I should
remove my battery, and use it only if I need be., just to be on the
safe side. (apple already replaced this one for free, without apple
care, so
I don't think they want to do that again.)
regards;

-- 
Justin P. Mattock

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Pavel Machek]

Hi!

On Sat 2008-06-07 23:28:08, Alexey Starikovskiy wrote:
> Justin Mattock wrote:
> >On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton 

> >This issue just recently started, 2.6.25-rc9 and below 
> >don't give me
> >this message.
> >
> Yes, the problem which we are fighting here is that 
> almost all Acer notebooks come with
> broken EC. It sends interrupts not regarding the fact 
> that we already ACKed it.
> It comes unnoticed on almost all machines (some notice 
> laggy keyboard, because it's the same controller after 
> all and it's busy with sending ACPI interrupts and then 
> providing same status byte over and over), but on some 
> machines keystrokes become missing, which is not 
> tolerable (#9998).

But the acer workaround breaks other machines, right?

So what about

a) use dmi blacklist for acers?

or

b) if EC storm is detected print message telling 'please pass
ec_polled=true if you experience keyboard problems', but do nothing
else?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Alexey Starikovskiy]

Pavel Machek wrote:
> Hi!
>
> On Sat 2008-06-07 23:28:08, Alexey Starikovskiy wrote:
>   
>> Justin Mattock wrote:
>>     
>>> On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton 
>>>       
>
>   
>>> This issue just recently started, 2.6.25-rc9 and below 
>>> don't give me
>>> this message.
>>>
>>>       
>> Yes, the problem which we are fighting here is that 
>> almost all Acer notebooks come with
>> broken EC. It sends interrupts not regarding the fact 
>> that we already ACKed it.
>> It comes unnoticed on almost all machines (some notice 
>> laggy keyboard, because it's the same controller after 
>> all and it's busy with sending ACPI interrupts and then 
>> providing same status byte over and over), but on some 
>> machines keystrokes become missing, which is not 
>> tolerable (#9998).
>>     
>
> But the acer workaround breaks other machines, right?
>
>   
As I know, the first workaround broke your machine,
may be you could check if it is broken now?
> So what about
>
> a) use dmi blacklist for acers?
>
>   
It is not only Acers. ASUS eeePC is known to be affected, some Apple 
notebook too.
> or
>
> b) if EC storm is detected print message telling 'please pass
> ec_polled=true if you experience keyboard problems', but do nothing
> else?
>
>   
There are no reports about broken machines for 2.6.26-rc5 beside #10724,
which has same broken controller, sending same amount of stray interrupts.
If there will be report from a good machine affected by this workaround 
then I will
certainly go with b)

Thanks,
Alex.

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

On Wed, Jun 11, 2008 at 10:29 AM, Alexey Starikovskiy
<aystarik@gmail.com> wrote:
> Pavel Machek wrote:
>>
>> Hi!
>>
>> On Sat 2008-06-07 23:28:08, Alexey Starikovskiy wrote:
>>
>>>
>>> Justin Mattock wrote:
>>>
>>>>
>>>> On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton
>>
>>
>>>>
>>>> This issue just recently started, 2.6.25-rc9 and below don't give me
>>>> this message.
>>>>
>>>>
>>>
>>> Yes, the problem which we are fighting here is that almost all Acer
>>> notebooks come with
>>> broken EC. It sends interrupts not regarding the fact that we already
>>> ACKed it.
>>> It comes unnoticed on almost all machines (some notice laggy keyboard,
>>> because it's the same controller after all and it's busy with sending ACPI
>>> interrupts and then providing same status byte over and over), but on some
>>> machines keystrokes become missing, which is not tolerable (#9998).
>>>
>>
>> But the acer workaround breaks other machines, right?
>>
>>
>
> As I know, the first workaround broke your machine,
> may be you could check if it is broken now?
>>
>> So what about
>>
>> a) use dmi blacklist for acers?
>>
>>
>
> It is not only Acers. ASUS eeePC is known to be affected, some Apple
> notebook too.
>>
>> or
>>
>> b) if EC storm is detected print message telling 'please pass
>> ec_polled=true if you experience keyboard problems', but do nothing
>> else?
>>
>>
>
> There are no reports about broken machines for 2.6.26-rc5 beside #10724,
> which has same broken controller, sending same amount of stray interrupts.
> If there will be report from a good machine affected by this workaround then
> I will
> certainly go with b)
>
> Thanks,
> Alex.
>
>
>

FWIW: just to let you guys know over here with a Macbook Pro ATI
chipset, as a small test removing the battery
I did not receive this message after 5+ hours of uptime. Normally on a
good run with the battery attached I get around an hour or so before
this triggers.
regards;

-- 
Justin P. Mattock

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Len Brown]

> Could someone from acpi land please help here?

Alexey maintains the EC, and he's supplied 3 patches to test
in the bug report.  The 3rd is awaiting word from Justin.

cheers,
-Len

> Justin, has this machine always had this problem or is it something
> which earlier kernels handled correctly?

note that the EC storm detection is new -- so the failure may
have simply been different in older kernels -- such as a huge
number of ACPI interrupts.

cheers,
-len

Re: ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

On Tue, Jun 10, 2008 at 3:30 PM, Len Brown <lenb@kernel.org> wrote:
>
>
>> Could someone from acpi land please help here?
>
> Alexey maintains the EC, and he's supplied 3 patches to test
> in the bug report.  The 3rd is awaiting word from Justin.
>
> cheers,
> -Len
>
>> Justin, has this machine always had this problem or is it something
>> which earlier kernels handled correctly?
>
> note that the EC storm detection is new -- so the failure may
> have simply been different in older kernels -- such as a huge
> number of ACPI interrupts.
>
> cheers,
> -len
>
>

Hello; O.K. I applied the patch. after rebooting I was still seeing
this message, also I noticed HAL daemon was taking longer
to start. when unplugging the A/C adapter with pommed the screen
wouldn't dim, and under dmesg nothing about the battery.
when unplugging and plugging in. also with suspend the screen took
longer than normal to recover. So feeling uncomfortable
with how this patch was causing the system to react, I reverted back
just to be safe. After reverting it took a few reboots to bring the
battery
back to a good state. I'm not sure if this was because of ec.c or not.
Now before this patch The only chage that I had done was change 5 to
20,
after a few day's I did notice this message to dissipate. Maybe this
is just something with a macbook pro, and not other computers, with
this patch.
regards;

-- 
Justin P. Mattock