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 <[email protected]>
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 <[email protected]>
Signed-off-by: Len Brown <[email protected]>
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
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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Len Brown <[email protected]>
>
> 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
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:
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
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
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