[ACPI] GPE storm detected on FS Amilo Pro

[ACPI] GPE storm detected on FS Amilo Pro

[Jacek Luczak]

Hi All,


I've got that ,,GPE storm detected'' issue on my Fujitsu Siemens Amilo Pro
notebook.  I was using 2.6.25.20 (which was fine) for a long while and recently
started testing some latest git versions starting from 2.6.29-rc2 where I've
discovered that issue. So I've made some back kernels and it shows up from
2.6.26 kernel. Bisection between 2.6.25 and 2.6.26 shows that patch:

fa95ba04e6ba11d71e1b87becd054b38faf546c8 is first bad commit
commit fa95ba04e6ba11d71e1b87becd054b38faf546c8
Author: Alexey Starikovskiy <astarikovskiy@suse.de>
Date:   Fri Mar 21 19:36:02 2008 +0300

    ACPI: EC: Detect irq storm

    Problem seems to be that hw fails to clear GPE after we service it and write 1
    into corresponding bit. Thus, as soon as we get interrupts enabled again, we
    receive a new one. Google gives too many results for "acer interrupt storm" for
    this being one-broken-machine case.

    Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9998

    Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>

The bug[1] (reopened recently) seems to be quite different than the one in my
case. I've got no ,,side effects'' of that GPE storm. Notebook works fine and I
didn't discovered any interrupts problems. Up to 2.6.28 GPE storm information is
printed early[2]:

Setting up standard PCI resources
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: EC: GPE storm detected, disabling EC GPE
ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in poll mode
ACPI: PCI Root Bridge [PCI0] (0000:00)

While recent git[3] which I'm now running, shows it after setting-up AC adapter[4]:

ACPI: AC Adapter [ADP1] (on-line)
ACPI: EC: GPE storm detected, transactions will use polling mode
Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 0
ACPI: EC: missing confirmations, switch off interrupt mode.
ACPI: Battery Slot [BAT0] (battery present)
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Lid Switch as /class/input/input1
ACPI: Lid Switch [LID0]
input: Sleep Button (CM) as /class/input/input2
ACPI: Sleep Button (CM) [SLPB]

I'm not sure if the origin of that GPE storm is the same in both cases. Will try
to do bisection here later if needed.

NOTE: In git kernel I've noticed that after boot and obtaining IP from DHCP I've
got such message:

Jan 21 14:44:32 difrost kernel: sky2 eth0: enabling interface
Jan 21 14:44:33 difrost kernel: sky2 eth0: Link is up at 100 Mbps, full duplex,
flow control rx
Jan 21 14:45:36 difrost kernel: ACPI: EC: missing confirmations, switch off
interrupt mode.

This is not fully reproducible, didn't shown on [4].

Regards,
-Jacek

-----
	[1] http://bugzilla.kernel.org/show_bug.cgi?id=9998
	[2] Full 2.6.26.8 dmesg:
http://pin.if.uz.zgora.pl/~difrost/linux-next/ACPI/storm_dmesg.log
	[3] Kernel version: 2.6.29-rc2-12097-gf3b8436-dirty (marked dirty, due to fix
for XFS bug found here)
	[4] Full git kernel dmesg:
http://pin.if.uz.zgora.pl/~difrost/linux-next/ACPI/storm_dmesg_29.log
	[5] /proc/interrupts from git kernel:
http://pin.if.uz.zgora.pl/~difrost/linux-next/ACPI/interrupts.log

Re: [ACPI] GPE storm detected on FS Amilo Pro

[Rafael J. Wysocki]

On Wednesday 21 January 2009, Jacek Luczak wrote:
> Hi All,

Hi Jacek,

> I've got that ,,GPE storm detected'' issue on my Fujitsu Siemens Amilo Pro
> notebook.  I was using 2.6.25.20 (which was fine) for a long while and recently
> started testing some latest git versions starting from 2.6.29-rc2 where I've
> discovered that issue. So I've made some back kernels and it shows up from
> 2.6.26 kernel. Bisection between 2.6.25 and 2.6.26 shows that patch:
> 
> fa95ba04e6ba11d71e1b87becd054b38faf546c8 is first bad commit
> commit fa95ba04e6ba11d71e1b87becd054b38faf546c8
> Author: Alexey Starikovskiy <astarikovskiy@suse.de>
> Date:   Fri Mar 21 19:36:02 2008 +0300
> 
>     ACPI: EC: Detect irq storm
> 
>     Problem seems to be that hw fails to clear GPE after we service it and write 1
>     into corresponding bit. Thus, as soon as we get interrupts enabled again, we
>     receive a new one. Google gives too many results for "acer interrupt storm" for
>     this being one-broken-machine case.
> 
>     Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9998
> 
>     Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
>     Signed-off-by: Len Brown <len.brown@intel.com>
> 
> The bug[1] (reopened recently) seems to be quite different than the one in my
> case. I've got no ,,side effects'' of that GPE storm. Notebook works fine and I
> didn't discovered any interrupts problems.

So everything appears to be OK except that your hardware has a problem,
which is correctly worked around and the message just tells you what happens.

> Up to 2.6.28 GPE storm information is printed early[2]:
> 
> Setting up standard PCI resources
> ACPI: EC: Look up EC in DSDT
> ACPI: Interpreter enabled
> ACPI: (supports S0 S3 S4 S5)
> ACPI: Using IOAPIC for interrupt routing
> ACPI: EC: non-query interrupt received, switching to interrupt mode
> ACPI: EC: GPE storm detected, disabling EC GPE
> ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> ACPI: EC: driver started in poll mode
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> 
> While recent git[3] which I'm now running, shows it after setting-up AC adapter[4]:
> 
> ACPI: AC Adapter [ADP1] (on-line)
> ACPI: EC: GPE storm detected, transactions will use polling mode
> Switched to high resolution mode on CPU 1
> Switched to high resolution mode on CPU 0
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI: Battery Slot [BAT0] (battery present)
> input: Power Button (FF) as /class/input/input0
> ACPI: Power Button (FF) [PWRF]
> input: Lid Switch as /class/input/input1
> ACPI: Lid Switch [LID0]
> input: Sleep Button (CM) as /class/input/input2
> ACPI: Sleep Button (CM) [SLPB]
> 
> I'm not sure if the origin of that GPE storm is the same in both cases. Will try
> to do bisection here later if needed.
> 
> NOTE: In git kernel I've noticed that after boot and obtaining IP from DHCP I've
> got such message:
> 
> Jan 21 14:44:32 difrost kernel: sky2 eth0: enabling interface
> Jan 21 14:44:33 difrost kernel: sky2 eth0: Link is up at 100 Mbps, full duplex,
> flow control rx
> Jan 21 14:45:36 difrost kernel: ACPI: EC: missing confirmations, switch off
> interrupt mode.
> 
> This is not fully reproducible, didn't shown on [4].

This may be related to the issue behind the GPM storm message.

Thanks,
Rafael

Re: [ACPI] GPE storm detected on FS Amilo Pro

[Jacek Luczak]

Hi Rafael,

> So everything appears to be OK except that your hardware has a problem,
> which is correctly worked around and the message just tells you what happens.

Most probably yes, but I'm using that kernel really shortly so there might be
some issues that I didn't noticed. This of course doesn't mean that here we have
 bug, I was just bit confused with that message.

>> NOTE: In git kernel I've noticed that after boot and obtaining IP from DHCP I've
>> got such message:
>>
>> Jan 21 14:44:32 difrost kernel: sky2 eth0: enabling interface
>> Jan 21 14:44:33 difrost kernel: sky2 eth0: Link is up at 100 Mbps, full duplex,
>> flow control rx
>> Jan 21 14:45:36 difrost kernel: ACPI: EC: missing confirmations, switch off
>> interrupt mode.
>>
>> This is not fully reproducible, didn't shown on [4].
> 
> This may be related to the issue behind the GPM storm message.

Is it sth serious? I'm really lost here.

-Jacek

Re: [ACPI] GPE storm detected on FS Amilo Pro

[Rafael J. Wysocki]

On Thursday 22 January 2009, Jacek Luczak wrote:
> Hi Rafael,
> 
> > So everything appears to be OK except that your hardware has a problem,
> > which is correctly worked around and the message just tells you what happens.
> 
> Most probably yes, but I'm using that kernel really shortly so there might be
> some issues that I didn't noticed. This of course doesn't mean that here we have
>  bug, I was just bit confused with that message.
> 
> >> NOTE: In git kernel I've noticed that after boot and obtaining IP from DHCP I've
> >> got such message:
> >>
> >> Jan 21 14:44:32 difrost kernel: sky2 eth0: enabling interface
> >> Jan 21 14:44:33 difrost kernel: sky2 eth0: Link is up at 100 Mbps, full duplex,
> >> flow control rx
> >> Jan 21 14:45:36 difrost kernel: ACPI: EC: missing confirmations, switch off
> >> interrupt mode.
> >>
> >> This is not fully reproducible, didn't shown on [4].
> > 
> > This may be related to the issue behind the GPM storm message.
> 
> Is it sth serious? I'm really lost here.

No, I don't think it's serious.  As long as everything works, there's not need
to worry. :-)

Thanks,
Rafael

Re: [ACPI] GPE storm detected on FS Amilo Pro

[Alexey Starikovskiy]

Hi Jacek,

You did not receive "GPE storm detected" message in earlier kernel only because
there was no detection of it. You can check if you have one by enabling "#define DEBUG" 
at the beginning of the /drivers/acpi/ec.c and looking into dmesg. If there is no storm,
you should see ony 2-3 interrupt messages per single transaction. Storm detector fires 
up at 8 excess interrupts.

Regards,
Alex.


Jacek Luczak wrote:
> Hi All,
> 
> 
> I've got that ,,GPE storm detected'' issue on my Fujitsu Siemens Amilo Pro
> notebook.  I was using 2.6.25.20 (which was fine) for a long while and recently
> started testing some latest git versions starting from 2.6.29-rc2 where I've
> discovered that issue. So I've made some back kernels and it shows up from
> 2.6.26 kernel. Bisection between 2.6.25 and 2.6.26 shows that patch:

Re: [ACPI] GPE storm detected on FS Amilo Pro

[Jacek Luczak]

Hi Alex,

Alexey Starikovskiy pisze:
> Hi Jacek,
> 
> You did not receive "GPE storm detected" message in earlier kernel only
> because
> there was no detection of it. You can check if you have one by enabling
> "#define DEBUG" at the beginning of the /drivers/acpi/ec.c and looking
> into dmesg.

I know, I was bit confused as I've seen that message before. I've double checked
and found that it appeared while I was fixing some stuff in 2.6.26 release
cycle, mea culpa.

> If there is no storm,
> you should see ony 2-3 interrupt messages per single transaction. Storm
> detector fires up at 8 excess interrupts.
> 

thanks for your answer, it was exactly what I was looking for.

While I was doing that 2.6.26 work I've found that IRQ 19 (sata ahci chip) is
doing some ugly stuff, I've reported that and stopped in half of my debug as I
didn't had more time to work on that. There was some ,,nobody cared'' bugs and
so one, I will return to that problem now and check if it's still present. All
those IRQ problems were appearing with suspend/resume. Nevertheless it isn't a
point here.

-Jacek