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
On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <[email protected]> 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" <[email protected]>
: To: "Linux Kernel Mailing List" <[email protected]>
: Cc: "Rafael J. Wysocki" <[email protected]>
: Subject: GPE storm detected, disabling EC GPE
: Date: Thu, 5 Jun 2008 21:01:55 +0000
: Sender: [email protected]
:
: 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.
On Saturday, 7 June 2008 09:55:26 Andrew Morton wrote:
> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <[email protected]> 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" <[email protected]>
> : To: "Linux Kernel Mailing List" <[email protected]>
> : Cc: "Rafael J. Wysocki" <[email protected]>
> : Subject: GPE storm detected, disabling EC GPE
> : Date: Thu, 5 Jun 2008 21:01:55 +0000
> : Sender: [email protected]
> :
> : 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 [email protected]
> 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
On Sat, Jun 7, 2008 at 12:59 PM, Maxim Levitsky <[email protected]> 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
On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton <[email protected]> wrote:
> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <[email protected]> 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" <[email protected]>
> : To: "Linux Kernel Mailing List" <[email protected]>
> : Cc: "Rafael J. Wysocki" <[email protected]>
> : Subject: GPE storm detected, disabling EC GPE
> : Date: Thu, 5 Jun 2008 21:01:55 +0000
> : Sender: [email protected]
> :
> : 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
Justin Mattock wrote:
> On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton <[email protected]> wrote:
>> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock" <[email protected]> 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" <[email protected]>
>> : To: "Linux Kernel Mailing List" <[email protected]>
>> : Cc: "Rafael J. Wysocki" <[email protected]>
>> : Subject: GPE storm detected, disabling EC GPE
>> : Date: Thu, 5 Jun 2008 21:01:55 +0000
>> : Sender: [email protected]
>> :
>> : 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.
On Sat, Jun 7, 2008 at 7:28 PM, Alexey Starikovskiy
<[email protected]> wrote:
> Justin Mattock wrote:
>>
>> On Sat, Jun 7, 2008 at 6:55 AM, Andrew Morton <[email protected]>
>> wrote:
>>>
>>> On Sat, 7 Jun 2008 06:21:54 +0000 "Justin Mattock"
>>> <[email protected]> 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" <[email protected]>
>>> : To: "Linux Kernel Mailing List" <[email protected]>
>>> : Cc: "Rafael J. Wysocki" <[email protected]>
>>> : Subject: GPE storm detected, disabling EC GPE
>>> : Date: Thu, 5 Jun 2008 21:01:55 +0000
>>> : Sender: [email protected]
>>> :
>>> : 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
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.
On Sat, Jun 7, 2008 at 9:27 PM, Alexey Starikovskiy
<[email protected]> 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
> 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
On Tue, Jun 10, 2008 at 3:30 PM, Len Brown <[email protected]> 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
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
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.
On Wed, Jun 11, 2008 at 10:29 AM, Alexey Starikovskiy
<[email protected]> 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