Bug 13502 - GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4...
Status: CLOSED UNREPRODUCIBLE
Product: ACPI
Classification: Unclassified
Component: EC
All Linux
: P1 normal
Assigned To: Alexey Starikovskiy
:
Depends on:
Blocks: 13070
  Show dependency treegraph
 
Reported: 2009-06-10 20:04 UTC by sveina
Modified: 2011-02-06 23:03 UTC (History)
14 users (show)

See Also:
Kernel Version: 2.6.30
Tree: Mainline
Regression: Yes


Attachments
dmesg output at 20:41 hours uptime, including sleep (125.90 KB, text/plain)
2009-06-11 16:08 UTC, sveina
Details
acpidump output (111.04 KB, text/plain)
2009-06-11 16:09 UTC, sveina
Details
kernel log w/debug on (16MB unpacked) (895.84 KB, application/octet-stream)
2009-06-11 20:15 UTC, sveina
Details
Kernel .config (61.71 KB, application/octet-stream)
2009-06-12 14:42 UTC, sveina
Details
debug battery_get_state (747 bytes, patch)
2009-06-12 15:32 UTC, Alexey Starikovskiy
Details | Diff
dmesg output, including new debugging code (74.65 KB, text/plain)
2009-06-12 16:14 UTC, sveina
Details
dmesg_ec_intr=1 (28.35 KB, application/octet-stream)
2009-09-24 18:49 UTC, Thoralf Dassler
Details
dmesg_ec_intr=_not_used (30.13 KB, application/octet-stream)
2009-09-24 18:49 UTC, Thoralf Dassler
Details

Description sveina 2009-06-10 20:04:11 UTC
Starting in 2.6.30, using select() on any file under /proc/acpi/battery gives the wrong reply, in that it suggests they should be readable immediately but a read() call in fact blocks for 4-5 seconds.

Prior to this, select worked correctly in that read in fact always returned immediately.

This is on a MacBookPro4,1, as far as read-edid is concerned. I'll happily help with any further information you might find useful, although since I'm using this machine for work I can't take it offline to run a git-bisection.
Comment 1 Andrew Morton 2009-06-10 20:10:47 UTC
I marked this as a regression.
Comment 2 Alexey Starikovskiy 2009-06-11 16:01:23 UTC
please provide dmesg and acpidump outputs.
Comment 3 sveina 2009-06-11 16:08:54 UTC
Created attachment 21854 [details]
dmesg output at 20:41 hours uptime, including sleep
Comment 4 sveina 2009-06-11 16:09:19 UTC
Created attachment 21855 [details]
acpidump output
Comment 5 Alexey Starikovskiy 2009-06-11 17:07:33 UTC
please uncomment "#define DEBUG" at the beginning of drivers/acpi/ec.c and attach new dmesg.
Comment 6 sveina 2009-06-11 20:15:17 UTC
Of course that produces a humongous amount of output that overruns the kernel buffer in short order. Here's /var/log/messages instead, which means the boot messages are missing.

The system switches from "sort of working" to "non-working" at ~21:59:26 in that log. "Sort of working" meaning reading it takes only 0.1 seconds on average, which is still a problem, but not as much of one.

I don't really care about how long reading these files take. It can take a second, or a minute. However, select needs to work correctly on them.
Comment 7 sveina 2009-06-11 20:15:59 UTC
Created attachment 21860 [details]
kernel log w/debug on (16MB unpacked)
Comment 8 Alexey Starikovskiy 2009-06-11 20:21:17 UTC
select() never returned anything meaningful from /proc/acpi, it is just not implemented. So, the regression is 4 second read of battery instead of almost instant...
Comment 9 sveina 2009-06-11 20:24:32 UTC
That regression should be a separate bug, then. The one I reported was for select.. I suppose that's a WILL_NOT_FIX, if it's an old bug?
Comment 10 Alexey Starikovskiy 2009-06-11 20:37:48 UTC
it's a "feature" of procfs. There is no estimate on how long read from syntetic file takes. Yes, WILL_NOT_FIX is quite probable. You could edit the header to track the regression.
Comment 11 ykzhao 2009-06-12 07:48:31 UTC
Hi, Sveina
    From the acpidump it seems that the battery info is obtained by using the SMBUS controller that resides in the EC controller.
    But there also exists the acpi device of sbshc/sbs(battery). I don't know whether there exists the conflicts.
    Will you please disable "CONFIG_ACPI_SBS" in kernel configuration and see whether it still takes about 4-5 seconds to read the file of /proc/acpi/battery/*
   thanks.
Comment 12 Alexey Starikovskiy 2009-06-12 08:16:50 UTC
Yakui,
Please notice STA method with call to OSDW(). Direct access to smart battery exists only for acpi_osi=Darwin
Comment 13 sveina 2009-06-12 14:41:25 UTC
CONFIG_ACPI_SBS was already disabled. Hm. I think I'll attach my .config too.
Comment 14 sveina 2009-06-12 14:42:46 UTC
Created attachment 21878 [details]
Kernel .config
Comment 15 Alexey Starikovskiy 2009-06-12 15:32:53 UTC
Created attachment 21881 [details]
debug battery_get_state

EC dump looks quite innocent -- activity is burst at every 10 sec and never spans more than 1 sec.
Please disable DEBUG in ec.c and apply this patch -- we should see where your 4 seconds are coming from...
Comment 16 sveina 2009-06-12 16:14:09 UTC
Created attachment 21883 [details]
dmesg output, including new debugging code

Well, it seems relatively obvious that the cause of my problems is this "GPE storm". What's one of those, exactly?

FTR, I got that message in 2.6.29 too, but without the ensuing troubles.
Comment 17 Alexey Starikovskiy 2009-06-12 17:26:21 UTC
GPE storm is a condition then EC starts to send same event over and over again. If driver gets > 8 of such meaningless events it starts to disable event source during transaction.

So, it looks like polling is what causes the 4 sec times. You may get better results if you change HZ=100 to HZ=1000.

You may also try to use SBS instead of disabling it. It did not work for MacBook owners before, but times change... You need to add "acpi_osi=Darwin" command line option for BIOS to switch to it.

I'm trying to find a way to prevent storm in EC, but have no success so far.
Comment 18 sveina 2009-06-12 20:22:43 UTC
Building SBS support into the kernel causes it to hang shortly after the code is initialized, before doing anything else, with a "GPE Storm" comment.

Building it as a module removed the hang, but although it seems to have initialized fine, there is nothing in /proc/acpi/battery. I'll try without acpi_osi.
Comment 19 sveina 2009-06-12 20:33:41 UTC
Turning off acpi_osi made SBS do nothing at all, as you probably expected.

Meanawhile, upping HZ to 1000 made battery requests take "only" half a second, which is annoying but at least usable. Doesn't this increase power consumption a lot, though? ;_;
Comment 20 Alexey Starikovskiy 2009-06-12 21:03:00 UTC
2 years ago at Intel we failed to notice the difference in power consumption between 100 and 1000 HZ on mobile CoreDuo. With NO_HZ option it should not matter at all.
Comment 21 Justin P. Mattock 2009-07-27 00:17:03 UTC
Seems I've only seen the gpe storm twice, after libc compile and install,
kernel install, and a few more streanous programs. Once the system is idle
I won't have a storm fire off at all. Not sure but on my system hal is not there,
and acpid only has one rule(shutdown -h now). I'm wondering if hal is triggering this, or acpid with some script causing false positives?
Comment 22 Anonymous Emailer 2009-07-27 00:36:05 UTC
Reply-To: svein.ove@aas.no

On Mon, Jul 27, 2009 at 2:17 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
> Justin P. Mattock <justinmattock@gmail.com> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |justinmattock@gmail.com
>
>
>
>
> --- Comment #21 from Justin P. Mattock <justinmattock@gmail.com>  2009-07-27 00:17:03 ---
> Seems I've only seen the gpe storm twice, after libc compile and install,
> kernel install, and a few more streanous programs. Once the system is idle
> I won't have a storm fire off at all. Not sure but on my system hal is not
> there,
> and acpid only has one rule(shutdown -h now). I'm wondering if hal is
> triggering this, or acpid with some script causing false positives?
>
I'll test this theory once I get my laptop back in a week.
Right now I can't even login to the bug-tracker. :/

-- 
Svein Ove Aas
Comment 23 Justin P. Mattock 2009-07-27 00:41:47 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
>
>
>
> --- Comment #22 from Anonymous Emailer<anonymous@kernel-bugs.osdl.org>   2009-07-27 00:36:05 ---
> Reply-To: svein.ove@aas.no
>
> On Mon, Jul 27, 2009 at 2:17 AM,<bugzilla-daemon@bugzilla.kernel.org>  wrote:
>    
>> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>>
>>
>> Justin P. Mattock<justinmattock@gmail.com>  changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>                  CC|                            |justinmattock@gmail.com
>>
>>
>>
>>
>> --- Comment #21 from Justin P. Mattock<justinmattock@gmail.com>    2009-07-27 00:17:03 ---
>> Seems I've only seen the gpe storm twice, after libc compile and install,
>> kernel install, and a few more streanous programs. Once the system is idle
>> I won't have a storm fire off at all. Not sure but on my system hal is not
>> there,
>> and acpid only has one rule(shutdown -h now). I'm wondering if hal is
>> triggering this, or acpid with some script causing false positives?
>>
>>      
> I'll test this theory once I get my laptop back in a week.
> Right now I can't even login to the bug-tracker. :/
>
>    
Cool, to give you an idea of the system I'm using
(just for your reference) is LFS, then once able to boot
xserver,fluxbox,terminal(and some entertainment needs).
very minimal system.

Justin P. Mattock
Comment 24 Thoralf Dassler 2009-07-27 18:37:02 UTC
I too have this GPE storm running the 2.6.30.2 kernel on a Toshiba Satellite L300 with an Insyde H20 Bios version 1.80 (the Bios is a joke), no battery. I have not experienced problems without the battery, so in my case the problem could be benign.

From dmesg:
ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query ignored
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: EC: GPE storm detected, transactions will use polling mode
ACPI: EC: missing confirmations, switch off interrupt mode.
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in poll mode
ACPI: Power Resource [FN00] (on)
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)

I do not currently have acpidump installed, but will install it if it helps to diagnose.
Comment 25 Justin P. Mattock 2009-07-27 18:58:24 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
> Thoralf Dassler<thoralf.dassler@gmail.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |thoralf.dassler@gmail.com
>
>
>
>
> --- Comment #24 from Thoralf Dassler<thoralf.dassler@gmail.com>   2009-07-27 18:37:02 ---
> I too have this GPE storm running the 2.6.30.2 kernel on a Toshiba Satellite
> L300 with an Insyde H20 Bios version 1.80 (the Bios is a joke), no battery. I
> have not experienced problems without the battery, so in my case the problem
> could be benign.
>
> > From dmesg:
> ACPI: EC: Look up EC in DSDT
> ACPI: BIOS _OSI(Linux) query ignored
> ACPI: EC: non-query interrupt received, switching to interrupt mode
> ACPI: EC: GPE storm detected, transactions will use polling mode
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI: Interpreter enabled
> ACPI: (supports S0 S3 S4 S5)
> ACPI: Using IOAPIC for interrupt routing
> ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62
> ACPI: EC: driver started in poll mode
> ACPI: Power Resource [FN00] (on)
> ACPI: No dock devices found.
> ACPI: PCI Root Bridge [PCI0] (0000:00)
>
> I do not currently have acpidump installed, but will install it if it helps to
> diagnose.
>
>    
I think what might help, is if somebody can simply
disable hal(to see if this is the reason), and acpid.
just to see if these two might be the reason for the storm to be fired off.
(I can try over here with a livecd, but might have mixed results).
As of now I can leave my machine on with the latest kernel
to see if I get a storm triggered(wont shutdown, just s2ram if need be).

Also with disabling hal,  some distros  have a hard time with this
example:xserver is built with hal support.

Justin P. Mattock
Comment 26 Thoralf Dassler 2009-07-28 09:59:44 UTC
Ok, I have another Satellite, a P200, on which I updated the kernel to 2.6.30.2. This laptop has a Phoenix Bios. However, the GPE storm seems to be more common than perhaps expected because the P200 also produces the GPE storm during boot.

1st test: P200 (the L300 is in a different location)
----------------------------------------------------
a) acpid and hald disabled. Because they initialise much later in the boot process than where the GPE storm occurs, I expected no change. And yes, after disabling the two daemons, the storm was still there.
b) like in a), plus noacpi and acpi=off boot parameters. Still the storm is there.


2nd test: L300 -- to follow:
----------------------------
In light of the first test, I anticipate the same results.
Comment 27 Justin P. Mattock 2009-07-28 14:20:20 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
>
>
>
> --- Comment #26 from Thoralf Dassler<thoralf.dassler@gmail.com>   2009-07-28 09:59:44 ---
> Ok, I have another Satellite, a P200, on which I updated the kernel to
> 2.6.30.2. This laptop has a Phoenix Bios. However, the GPE storm seems to be
> more common than perhaps expected because the P200 also produces the GPE storm
> during boot.
>
> 1st test: P200 (the L300 is in a different location)
> ----------------------------------------------------
> a) acpid and hald disabled. Because they initialise much later in the boot
> process than where the GPE storm occurs, I expected no change. And yes, after
> disabling the two daemons, the storm was still there.
> b) like in a), plus noacpi and acpi=off boot parameters. Still the storm is
> there.
>
>
> 2nd test: L300 -- to follow:
> ----------------------------
> In light of the first test, I anticipate the same results.
>
>    
Thanks for testing that.
I guess I'm wrong with hal/acpid
being the culprits to fire the storm.

With that in mind it has to be something software related,
i.g. at the moment my machine(macbook ati chipset) has be running
for 19:00 hrs with no signs of a gpe storm.
(I'll let it run all day to see)

Justin P. Mattock
Comment 28 Thoralf Dassler 2009-07-29 14:47:26 UTC
As suspected, the test on the Satellite L300 produces the same results. SO it cannot be hald or acpid.
Comment 29 Justin P. Mattock 2009-07-29 16:06:41 UTC
(In reply to comment #28)
> As suspected, the test on the Satellite L300 produces the same results. SO it
> cannot be hald or acpid.

Well, I'm lost as to what might be causing this.
Thanks for having a look.

As for seeing the gpe storm over here, I've had the system
up and running for 1 day and 20 hours without having a gpe storm.
(with using ubuntu/debian this would have triggered withing about 2/4 hrs).

It has to be something software related, and not kernel related that's
causing this.
Comment 30 Rafael J. Wysocki 2009-08-03 14:47:18 UTC
On Monday 03 August 2009, Svein Ove Aas wrote:
> On Sun, Aug 2, 2009 at 9:09 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> Yes, the bug is still there in 30.4
Comment 31 Justin P. Mattock 2009-08-03 16:04:09 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
>
>
>
> --- Comment #30 from Rafael J. Wysocki<rjw@sisk.pl>   2009-08-03 14:47:18 ---
> On Monday 03 August 2009, Svein Ove Aas wrote:
>    
>> On Sun, Aug 2, 2009 at 9:09 PM, Rafael J. Wysocki<rjw@sisk.pl>  wrote:
>>      
>>> This message has been generated automatically as a part of a report
>>> of regressions introduced between 2.6.29 and 2.6.30.
>>>
>>> The following bug entry is on the current list of known regressions
>>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>>> be listed and let me know (either way).
>>>
>>>        
>> Yes, the bug is still there in 30.4
>>      
>
>    
I've ran my system for 2+ days without hitting this,
but on other system people are hitting this(probably
within a few hours or less).

This has to be something in userspace,
(or maybe the way I compiled the system i.g. CFLAGS).
In any case if you need any info let me know.

Justin P. Mattock
Comment 32 Justin P. Mattock 2009-08-13 03:42:22 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
> Len Brown<len.brown@intel.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Component|EC                          |Power-Battery
>           AssignedTo|acpi_ec@kernel-bugs.osdl.or |astarikovskiy@suse.de
>                     |g                           |
>
>
>
>
>    
I haven't pulled Linus's tree in a few
weeks, I'll go and do so to see if this occurs.

Justin P. Mattock
Comment 33 Justin P. Mattock 2009-08-13 04:10:49 UTC
On Wed, Aug 12, 2009 at 8:42 PM, Justin P.
Mattock<justinmattock@gmail.com> wrote:
> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>>
>>
>> Len Brown<len.brown@intel.com>  changed:
>>
>>            What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>           Component|EC                          |Power-Battery
>>          AssignedTo|acpi_ec@kernel-bugs.osdl.or |astarikovskiy@suse.de
>>                    |g                           |
>>
>>
>>
>>
>>
>
> I haven't pulled Linus's tree in a few
> weeks, I'll go and do so to see if this occurs.
>
> Justin P. Mattock
>

just received a GPE storm detected on the initial
boot after compiling the kernel, As soon as I shutdown
the system and let the machine settle down seems
put the machine in the right state.

Ill run this and see if it fires off after a few hours.

-- 
Justin P. Mattock
Comment 34 Rafael J. Wysocki 2009-08-20 14:39:05 UTC
On Thursday 20 August 2009, Svein Ove Aas wrote:
> 64 bytes from sveina@gmail.com: icmp_seq=4 ttl=247 time=30.6 m
> 
> ..yes, it's still there. Don't worry about me, I'm just having a little fun.
> 
> On Wed, Aug 19, 2009 at 10:40 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13502
> > Subject         : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
> > Submitter       :  <sveina@gmail.com>
> > Date            : 2009-06-10 20:04 (71 days old)
Comment 35 Rafael J. Wysocki 2009-08-26 13:51:24 UTC
On Wednesday 26 August 2009, Svein Ove Aas wrote:
> Still there.
> 
> On Tue, Aug 25, 2009 at 11:05 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13502
> > Subject         : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
> > Submitter       :  <sveina@gmail.com>
> > Date            : 2009-06-10 20:04 (77 days old)
Comment 36 Rafael J. Wysocki 2009-08-26 20:27:56 UTC
On Wednesday 26 August 2009, Svein Ove Aas wrote:
> I should add, this is on 2.6.30.5, not a trunk version.
> 
> Another interesting fact: For some time, every value relating to the
> battery (current, capacity (current and max), voltage, etc. all
> registered as 0.
> 
> Rebooting, or cold-booting the laptop did nothing. However, booting
> into OS X fixed it; I'm wondering if it's missing some initialization
> code.
> 
> Also, timing-wise: It starts lagging when the GPE storm shows up, some
> time after boot. I patched the kernel to log exec's, and the storm is
> not correlated with any such calls.
> 
> On Wed, Aug 26, 2009 at 3:52 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Wednesday 26 August 2009, Svein Ove Aas wrote:
> >> Still there.
> >
> > Thanks for the update.
> >
> >> On Tue, Aug 25, 2009 at 11:05 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> >> > This message has been generated automatically as a part of a report
> >> > of regressions introduced between 2.6.29 and 2.6.30.
> >> >
> >> > The following bug entry is on the current list of known regressions
> >> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> >> > be listed and let me know (either way).
> >> >
> >> >
> >> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13502
> >> > Subject         : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
> >> > Submitter       :  <sveina@gmail.com>
> >> > Date            : 2009-06-10 20:04 (77 days old)
Comment 37 Rafael J. Wysocki 2009-08-27 11:49:42 UTC
On Thursday 27 August 2009, Svein Ove Aas wrote:
> On Wed, Aug 26, 2009 at 10:30 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Wednesday 26 August 2009, Svein Ove Aas wrote:
> >> I should add, this is on 2.6.30.5, not a trunk version.
> >
> > Is the current Linus' tree also affected?
> >
> Yes, as it turns out.
Comment 38 Justin P. Mattock 2009-08-27 14:33:30 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
>
>
>
> --- Comment #37 from Rafael J. Wysocki<rjw@sisk.pl>   2009-08-27 11:49:42 ---
> On Thursday 27 August 2009, Svein Ove Aas wrote:
>    
>> On Wed, Aug 26, 2009 at 10:30 PM, Rafael J. Wysocki<rjw@sisk.pl>  wrote:
>>      
>>> On Wednesday 26 August 2009, Svein Ove Aas wrote:
>>>        
>>>> I should add, this is on 2.6.30.5, not a trunk version.
>>>>          
>>> Is the current Linus' tree also affected?
>>>
>>>        
>> Yes, as it turns out.
>>      
>
>    
apologize for the late response.
At the moment the only time
a gpe storm showed up was after a kernel
compile. After that when things settle down nothing.

Justin P. Mattock
Comment 39 Rafael J. Wysocki 2009-09-10 23:19:42 UTC
On Monday 07 September 2009, Svein Ove Aas wrote:
> Still there.
> 
> On Sun, Sep 6, 2009 at 8:11 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13502
> > Subject         : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
> > Submitter       :  <sveina@gmail.com>
> > Date            : 2009-06-10 20:04 (89 days old)
Comment 40 Justin P. Mattock 2009-09-11 07:05:25 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
>
>
>
> --- Comment #39 from Rafael J. Wysocki<rjw@sisk.pl>   2009-09-10 23:19:42 ---
> On Monday 07 September 2009, Svein Ove Aas wrote:
>    
>> Still there.
>>
>> On Sun, Sep 6, 2009 at 8:11 PM, Rafael J. Wysocki<rjw@sisk.pl>  wrote:
>>      
>>> This message has been generated automatically as a part of a report
>>> of regressions introduced between 2.6.29 and 2.6.30.
>>>
>>> The following bug entry is on the current list of known regressions
>>> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
>>> be listed and let me know (either way).
>>>
>>>
>>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13502
>>> Subject         : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
>>> Submitter       :<sveina@gmail.com>
>>> Date            : 2009-06-10 20:04 (89 days old)
>>>        
>
>    
apologize for the slow delay.(stepped out
for a few)
I haven't updated that system in a few weeks.
I go and do this in the morning and runnit
all day and see.

Justin P. Mattock
Comment 41 Thoralf Dassler 2009-09-11 08:18:20 UTC
The bug occurs in 2.6.30.5, but will try 2.6.31. Will let you know.
Comment 42 sveina 2009-09-11 11:33:05 UTC
It occurs in 2.6.31, with both voluntary and real preemption (if that matters). It's not going away on its own, that's for sure.
Comment 43 Justin P. Mattock 2009-09-11 20:17:20 UTC
O.K. loaded the latest git head.
seems the gpe storm did fire off, but after a couple of restarts the system
seems to be sustained and the storm hasn't fired of since.(keep in mind it's only been 40min)

Ill run it the rest of the day to see if the storm is triggered.
Comment 44 Justin P. Mattock 2009-09-12 19:39:40 UTC
After running the latest git(HEAD) I did receive the
gpe storm after a compile of the kernel, and
a few times after-wards. But as soon as the system settled down
(fans, etc..) I didn't see this message(after over 6 hrs of uptime.

Now something new showed up that I have never seen before on this machine:
[14229.000019] NOHZ: local_softirq_pending 80 

Not sure what this is. The time as to when this showed up (estimate)probably
around 5/6 hrs of uptime. I noticed that the fans on the machine
were screaming, and were not settling down. Either it was too hot because of the
small heat wave were experiencing in SoCal, or something triggered these fans
to full power.
Comment 45 phoenp 2009-09-24 15:37:36 UTC
I can confirm the GPE storm on Satellite Pro L300

[    0.114829] ACPI: EC: GPE storm detected, transactions will use polling mode
[    0.614002] ACPI: EC: missing confirmations, switch off interrupt mode.

The reason it only happens after kernel compile seems to be that subsequent boots start in polling mode rather than attempting interrupt mode.

Not sure how related this is, but Method(_OSC...  for this bios (Insyde 1.50) is broken.

I tried fixing it but my ASL is not so great. Any tips on moving a CreateDWorldField(... out of a while loop?
Comment 46 Thoralf Dassler 2009-09-24 16:47:02 UTC
Got 2.6.31 up now, I get the GPE storm after every reboot.

Specifically passed 'ec_intr=1' at boot time, does make the storm go away.
Comment 47 sveina 2009-09-24 17:38:53 UTC
Hold on, that makes little sense.

ec_intr=1 is the default, and means "use interrupt mode"; a GPE storm makes it fall back to polling mode, as in ec_intr=0.

I might be misunderstanding something here, but.. could you paste your dmesg output, with and without that option? And make sure you haven't simply been lucky so far?
Comment 48 Justin P. Mattock 2009-09-24 18:22:40 UTC
(In reply to comment #45)
> I can confirm the GPE storm on Satellite Pro L300
> 
> [    0.114829] ACPI: EC: GPE storm detected, transactions will use polling mode
> [    0.614002] ACPI: EC: missing confirmations, switch off interrupt mode.
> 
> The reason it only happens after kernel compile seems to be that subsequent
> boots start in polling mode rather than attempting interrupt mode.
> 
> Not sure how related this is, but Method(_OSC...  for this bios (Insyde 1.50)
> is broken.
> 
> I tried fixing it but my ASL is not so great. Any tips on moving a
> CreateDWorldField(... out of a while loop?

I'm not familiar with where the location is of CreateDWorldField
(but will look into it when I get a chance).

As of now the system I was using that was triggering a gpe after a compile
is deleted.(wanted to start over with a fresh redu).

Now I have created an x86_64(hopefully pure64 using the clfs tutorial) So far I have not seen any signs of a gpe storm(but haven't really let the system sit).
After I set things up(running some network experiments) Ill let the system
sit all day and see if the storm gets triggered. latest kernel for this machine is the latest git a few days ago.
Comment 49 Thoralf Dassler 2009-09-24 18:45:28 UTC
Sorry, didn't explain it very well.

I did 'ec_intr=1' only for testing, i.e. to make absolutely sure my boot loader is not using polling mode without me knowing. Thought this was worth a try after comment #45.

Anyway, I attach both dmesg.
Comment 50 Thoralf Dassler 2009-09-24 18:49:30 UTC
Created attachment 23174 [details]
dmesg_ec_intr=1
Comment 51 Thoralf Dassler 2009-09-24 18:49:56 UTC
Created attachment 23175 [details]
dmesg_ec_intr=_not_used
Comment 52 sveina 2009-09-28 13:40:18 UTC
(In reply to comment #51)

I've noticed that ec_intr does not appear to be a valid kernel parameter anymore, on 2.6.31 (at least) and up. There is no mention of it in kernel-parameters.txt, and there is no mention in the actual code, going by grep.

Are you quite sure it's doing anything?
Comment 53 Justin P. Mattock 2009-09-28 17:45:08 UTC
(In reply to comment #48)
> (In reply to comment #45)
> > I can confirm the GPE storm on Satellite Pro L300
> > 
> > [    0.114829] ACPI: EC: GPE storm detected, transactions will use polling mode
> > [    0.614002] ACPI: EC: missing confirmations, switch off interrupt mode.
> > 
> > The reason it only happens after kernel compile seems to be that subsequent
> > boots start in polling mode rather than attempting interrupt mode.
> > 
> > Not sure how related this is, but Method(_OSC...  for this bios (Insyde 1.50)
> > is broken.
> > 
> > I tried fixing it but my ASL is not so great. Any tips on moving a
> > CreateDWorldField(... out of a while loop?
> 
> I'm not familiar with where the location is of CreateDWorldField
> (but will look into it when I get a chance).
> 
> As of now the system I was using that was triggering a gpe after a compile
> is deleted.(wanted to start over with a fresh redu).
> 
> Now I have created an x86_64(hopefully pure64 using the clfs tutorial) So far I
> have not seen any signs of a gpe storm(but haven't really let the system sit).
> After I set things up(running some network experiments) Ill let the system
> sit all day and see if the storm gets triggered. latest kernel for this machine
> is the latest git a few days ago.

This is an update: seems I have no signs of a gpe
storm firing off.(only issue is a bluetooth thing)
At first thought it might be acpid/hal but wasn't the case.

The only idea I can think of that might be triggering this
is maybe the optimizations are wrong when using a distro, which 
causes things to not be aligned.(but could be wrong).
Comment 54 Thoralf Dassler 2009-10-06 16:48:31 UTC
reply to comment #51: 'ec_intr=' is not doing anything, which is what my test tried to work out for definite.
Comment 55 Zhang Rui 2010-03-12 03:11:15 UTC
does the problem still exists in the latest kernel, say 2.6.33 or 2.6.34-rc1?
Comment 56 Justin P. Mattock 2010-03-12 03:59:29 UTC
just loaded open suse a few days ago on my macbook, and noticed the gpe storm.
(not sure though with the battery issue).
keep in mind I think there using 2.6.31.

weird thing is my clfs system, has no gpe storm when loading it on the machine.
Comment 57 Zhang Rui 2010-03-12 05:56:00 UTC
please attach the output of "grep . /sys/firmware/acpi/interrupts/*".
Comment 58 Justin P. Mattock 2010-03-12 06:14:38 UTC
this is with my clfs system, that does not generate a gpe storm:

       0
       0        enabled
       0        invalid
       0        enabled
       0        disabled
       0        invalid
       0        invalid
       0        enabled
       0        enabled
       0        disabled
       0        disabled
       0        invalid
       0        invalid
       0        enabled
       0        invalid
       0        disabled
       0        enabled
       0        enabled
       0        disabled
       0        disabled
       0        disabled
       0        invalid
       0        invalid
       0        enabled
       0        invalid
       0        invalid
       0        invalid
       0        invalid
       0        invalid
     875        enabled
       0        invalid
       0        invalid
       0        invalid
       0        invalid
       0        invalid
       0        invalid
       0        invalid
       0        invalid
     875
     875
       0
Comment 59 Justin P. Mattock 2010-03-12 06:16:38 UTC
my bad I didnt see the period in your grep

 grep . /sys/firmware/acpi/interrupts/*
/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0      enabled
/sys/firmware/acpi/interrupts/ff_pmtimer:       0       invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0       enabled
/sys/firmware/acpi/interrupts/ff_rt_clk:       0        disabled
/sys/firmware/acpi/interrupts/ff_slp_btn:       0       invalid
/sys/firmware/acpi/interrupts/gpe00:       0    invalid
/sys/firmware/acpi/interrupts/gpe01:       0    enabled
/sys/firmware/acpi/interrupts/gpe02:       0    enabled
/sys/firmware/acpi/interrupts/gpe03:       0    disabled
/sys/firmware/acpi/interrupts/gpe04:       0    disabled
/sys/firmware/acpi/interrupts/gpe05:       0    invalid
/sys/firmware/acpi/interrupts/gpe06:       0    invalid
/sys/firmware/acpi/interrupts/gpe07:       0    enabled
/sys/firmware/acpi/interrupts/gpe08:       0    invalid
/sys/firmware/acpi/interrupts/gpe09:       0    disabled
/sys/firmware/acpi/interrupts/gpe0A:       0    enabled
/sys/firmware/acpi/interrupts/gpe0B:       0    enabled
/sys/firmware/acpi/interrupts/gpe0C:       0    disabled
/sys/firmware/acpi/interrupts/gpe0D:       0    disabled
/sys/firmware/acpi/interrupts/gpe0E:       0    disabled
/sys/firmware/acpi/interrupts/gpe0F:       0    invalid
/sys/firmware/acpi/interrupts/gpe10:       0    invalid
/sys/firmware/acpi/interrupts/gpe11:       0    enabled
/sys/firmware/acpi/interrupts/gpe12:       0    invalid
/sys/firmware/acpi/interrupts/gpe13:       0    invalid
/sys/firmware/acpi/interrupts/gpe14:       0    invalid
/sys/firmware/acpi/interrupts/gpe15:       0    invalid
/sys/firmware/acpi/interrupts/gpe16:       0    invalid
/sys/firmware/acpi/interrupts/gpe17:     875    enabled
/sys/firmware/acpi/interrupts/gpe18:       0    invalid
/sys/firmware/acpi/interrupts/gpe19:       0    invalid
/sys/firmware/acpi/interrupts/gpe1A:       0    invalid
/sys/firmware/acpi/interrupts/gpe1B:       0    invalid
/sys/firmware/acpi/interrupts/gpe1C:       0    invalid
/sys/firmware/acpi/interrupts/gpe1D:       0    invalid
/sys/firmware/acpi/interrupts/gpe1E:       0    invalid
/sys/firmware/acpi/interrupts/gpe1F:       0    invalid
/sys/firmware/acpi/interrupts/gpe_all:     875
/sys/firmware/acpi/interrupts/sci:     875
/sys/firmware/acpi/interrupts/sci_not:       0
Comment 60 Zhang Rui 2010-03-12 06:41:44 UTC
please attach the same output in a kernel with the gpe storm. :)
Comment 61 Justin P. Mattock 2010-03-12 18:37:54 UTC
o.k. apologize for the delay(passed out), heres the requested info with open suse,
that has the gpe storm:


 grep . /sys/firmware/acpi/interrupts/*
/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0      enabled
/sys/firmware/acpi/interrupts/ff_pmtimer:       0       invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0       enabled
/sys/firmware/acpi/interrupts/ff_rt_clk:       0        disabled
/sys/firmware/acpi/interrupts/ff_slp_btn:       0       invalid
/sys/firmware/acpi/interrupts/gpe00:       0    invalid
/sys/firmware/acpi/interrupts/gpe01:       0    enabled
/sys/firmware/acpi/interrupts/gpe02:       0    enabled
/sys/firmware/acpi/interrupts/gpe03:       0    disabled
/sys/firmware/acpi/interrupts/gpe04:       0    disabled
/sys/firmware/acpi/interrupts/gpe05:       0    invalid
/sys/firmware/acpi/interrupts/gpe06:       0    invalid
/sys/firmware/acpi/interrupts/gpe07:       0    enabled
/sys/firmware/acpi/interrupts/gpe08:       0    invalid
/sys/firmware/acpi/interrupts/gpe09:       0    disabled
/sys/firmware/acpi/interrupts/gpe0A:       0    enabled
/sys/firmware/acpi/interrupts/gpe0B:       0    enabled
/sys/firmware/acpi/interrupts/gpe0C:       0    disabled
/sys/firmware/acpi/interrupts/gpe0D:       0    disabled
/sys/firmware/acpi/interrupts/gpe0E:       0    disabled
/sys/firmware/acpi/interrupts/gpe0F:       0    invalid
/sys/firmware/acpi/interrupts/gpe10:       0    invalid
/sys/firmware/acpi/interrupts/gpe11:       0    enabled
/sys/firmware/acpi/interrupts/gpe12:       0    invalid
/sys/firmware/acpi/interrupts/gpe13:       0    invalid
/sys/firmware/acpi/interrupts/gpe14:       0    invalid
/sys/firmware/acpi/interrupts/gpe15:       0    invalid
/sys/firmware/acpi/interrupts/gpe16:       0    invalid
/sys/firmware/acpi/interrupts/gpe17:    4384    enabled
/sys/firmware/acpi/interrupts/gpe18:       0    invalid
/sys/firmware/acpi/interrupts/gpe19:       0    invalid
/sys/firmware/acpi/interrupts/gpe1A:       0    invalid
/sys/firmware/acpi/interrupts/gpe1B:       0    invalid
/sys/firmware/acpi/interrupts/gpe1C:       0    invalid
/sys/firmware/acpi/interrupts/gpe1D:       0    invalid
/sys/firmware/acpi/interrupts/gpe1E:       0    invalid
/sys/firmware/acpi/interrupts/gpe1F:       0    invalid
/sys/firmware/acpi/interrupts/gpe_all:    4384
/sys/firmware/acpi/interrupts/sci:    4384
/sys/firmware/acpi/interrupts/sci_not:       0


definitely a big difference in numbers, keep in mind this is from a livecd
(I think what I might do is create two partitions i.g. one with my clfs, and one with suse so things are easier with getting info from the system that gets a gpe storm, to a system that doesnt).
Comment 62 Justin P. Mattock 2010-03-13 06:42:29 UTC
o.k. so with running open suse the GPE storm hits at around three hours of being up(noticed though this fired off earlier on another boot).

as for battery info taking 4 sec's or so
I did not see much with the command acpi
as well as cat /proc/acpi/battery/B*/state
(maybe this issue is fixed).

As for the gpe storm though something is generating these interrupts to storm,
because on my clfs there's nothing(system can run for a week with no gpe storm firing off). I'll try and look at apps to see if any of them are triggering, then go from there.
Comment 63 Justin P. Mattock 2010-03-13 19:56:13 UTC
I should attach this, but figured probably better to just post here(nobody has to download anything).

Anyways I think hal is the culprit with this here's the differences below:




system booting up with haldaemon starting:


/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0      enabled
/sys/firmware/acpi/interrupts/ff_pmtimer:       0       invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0       enabled
/sys/firmware/acpi/interrupts/ff_rt_clk:       0        disabled
/sys/firmware/acpi/interrupts/ff_slp_btn:       0       invalid
/sys/firmware/acpi/interrupts/gpe00:       0    invalid
/sys/firmware/acpi/interrupts/gpe01:       0    enabled
/sys/firmware/acpi/interrupts/gpe02:       0    enabled
/sys/firmware/acpi/interrupts/gpe03:       0    disabled
/sys/firmware/acpi/interrupts/gpe04:       0    disabled
/sys/firmware/acpi/interrupts/gpe05:       0    invalid
/sys/firmware/acpi/interrupts/gpe06:       0    invalid
/sys/firmware/acpi/interrupts/gpe07:       0    enabled
/sys/firmware/acpi/interrupts/gpe08:       0    invalid
/sys/firmware/acpi/interrupts/gpe09:       0    disabled
/sys/firmware/acpi/interrupts/gpe0A:       0    enabled
/sys/firmware/acpi/interrupts/gpe0B:       0    enabled
/sys/firmware/acpi/interrupts/gpe0C:       0    disabled
/sys/firmware/acpi/interrupts/gpe0D:       0    disabled
/sys/firmware/acpi/interrupts/gpe0E:       0    disabled
/sys/firmware/acpi/interrupts/gpe0F:       0    invalid
/sys/firmware/acpi/interrupts/gpe10:       0    invalid
/sys/firmware/acpi/interrupts/gpe11:       0    enabled
/sys/firmware/acpi/interrupts/gpe12:       0    invalid
/sys/firmware/acpi/interrupts/gpe13:       0    invalid
/sys/firmware/acpi/interrupts/gpe14:       0    invalid
/sys/firmware/acpi/interrupts/gpe15:       0    invalid
/sys/firmware/acpi/interrupts/gpe16:       0    invalid
/sys/firmware/acpi/interrupts/gpe17:    2913    enabled
/sys/firmware/acpi/interrupts/gpe18:       0    invalid
/sys/firmware/acpi/interrupts/gpe19:       0    invalid
/sys/firmware/acpi/interrupts/gpe1A:       0    invalid
/sys/firmware/acpi/interrupts/gpe1B:       0    invalid
/sys/firmware/acpi/interrupts/gpe1C:       0    invalid
/sys/firmware/acpi/interrupts/gpe1D:       0    invalid
/sys/firmware/acpi/interrupts/gpe1E:       0    invalid
/sys/firmware/acpi/interrupts/gpe1F:       0    invalid
/sys/firmware/acpi/interrupts/gpe_all:    2913
/sys/firmware/acpi/interrupts/sci:    2913
/sys/firmware/acpi/interrupts/sci_not:       0






system starting with haldaemon disabled:



/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0      enabled
/sys/firmware/acpi/interrupts/ff_pmtimer:       0       invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0       enabled
/sys/firmware/acpi/interrupts/ff_rt_clk:       0        disabled
/sys/firmware/acpi/interrupts/ff_slp_btn:       0       invalid
/sys/firmware/acpi/interrupts/gpe00:       0    invalid
/sys/firmware/acpi/interrupts/gpe01:       0    enabled
/sys/firmware/acpi/interrupts/gpe02:       0    enabled
/sys/firmware/acpi/interrupts/gpe03:       0    disabled
/sys/firmware/acpi/interrupts/gpe04:       0    disabled
/sys/firmware/acpi/interrupts/gpe05:       0    invalid
/sys/firmware/acpi/interrupts/gpe06:       0    invalid
/sys/firmware/acpi/interrupts/gpe07:       0    enabled
/sys/firmware/acpi/interrupts/gpe08:       0    invalid
/sys/firmware/acpi/interrupts/gpe09:       0    disabled
/sys/firmware/acpi/interrupts/gpe0A:       0    enabled
/sys/firmware/acpi/interrupts/gpe0B:       0    enabled
/sys/firmware/acpi/interrupts/gpe0C:       0    disabled
/sys/firmware/acpi/interrupts/gpe0D:       0    disabled
/sys/firmware/acpi/interrupts/gpe0E:       0    disabled
/sys/firmware/acpi/interrupts/gpe0F:       0    invalid
/sys/firmware/acpi/interrupts/gpe10:       0    invalid
/sys/firmware/acpi/interrupts/gpe11:       0    enabled
/sys/firmware/acpi/interrupts/gpe12:       0    invalid
/sys/firmware/acpi/interrupts/gpe13:       0    invalid
/sys/firmware/acpi/interrupts/gpe14:       0    invalid
/sys/firmware/acpi/interrupts/gpe15:       0    invalid
/sys/firmware/acpi/interrupts/gpe16:       0    invalid
/sys/firmware/acpi/interrupts/gpe17:    1917    enabled
/sys/firmware/acpi/interrupts/gpe18:       0    invalid
/sys/firmware/acpi/interrupts/gpe19:       0    invalid
/sys/firmware/acpi/interrupts/gpe1A:       0    invalid
/sys/firmware/acpi/interrupts/gpe1B:       0    invalid
/sys/firmware/acpi/interrupts/gpe1C:       0    invalid
/sys/firmware/acpi/interrupts/gpe1D:       0    invalid
/sys/firmware/acpi/interrupts/gpe1E:       0    invalid
/sys/firmware/acpi/interrupts/gpe1F:       0    invalid
/sys/firmware/acpi/interrupts/gpe_all:    1917
/sys/firmware/acpi/interrupts/sci:    1917
/sys/firmware/acpi/interrupts/sci_not:       0


if issuing the command "acpi"  the number jumps
but if I dont issue acpi the number stays.



/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0      enabled
/sys/firmware/acpi/interrupts/ff_pmtimer:       0       invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0       enabled
/sys/firmware/acpi/interrupts/ff_rt_clk:       0        disabled
/sys/firmware/acpi/interrupts/ff_slp_btn:       0       invalid
/sys/firmware/acpi/interrupts/gpe00:       0    invalid
/sys/firmware/acpi/interrupts/gpe01:       0    enabled
/sys/firmware/acpi/interrupts/gpe02:       0    enabled
/sys/firmware/acpi/interrupts/gpe03:       0    disabled
/sys/firmware/acpi/interrupts/gpe04:       0    disabled
/sys/firmware/acpi/interrupts/gpe05:       0    invalid
/sys/firmware/acpi/interrupts/gpe06:       0    invalid
/sys/firmware/acpi/interrupts/gpe07:       0    enabled
/sys/firmware/acpi/interrupts/gpe08:       0    invalid
/sys/firmware/acpi/interrupts/gpe09:       0    disabled
/sys/firmware/acpi/interrupts/gpe0A:       0    enabled
/sys/firmware/acpi/interrupts/gpe0B:       0    enabled
/sys/firmware/acpi/interrupts/gpe0C:       0    disabled
/sys/firmware/acpi/interrupts/gpe0D:       0    disabled
/sys/firmware/acpi/interrupts/gpe0E:       0    disabled
/sys/firmware/acpi/interrupts/gpe0F:       0    invalid
/sys/firmware/acpi/interrupts/gpe10:       0    invalid
/sys/firmware/acpi/interrupts/gpe11:       0    enabled
/sys/firmware/acpi/interrupts/gpe12:       0    invalid
/sys/firmware/acpi/interrupts/gpe13:       0    invalid
/sys/firmware/acpi/interrupts/gpe14:       0    invalid
/sys/firmware/acpi/interrupts/gpe15:       0    invalid
/sys/firmware/acpi/interrupts/gpe16:       0    invalid
/sys/firmware/acpi/interrupts/gpe17:    2579    enabled
/sys/firmware/acpi/interrupts/gpe18:       0    invalid
/sys/firmware/acpi/interrupts/gpe19:       0    invalid
/sys/firmware/acpi/interrupts/gpe1A:       0    invalid
/sys/firmware/acpi/interrupts/gpe1B:       0    invalid
/sys/firmware/acpi/interrupts/gpe1C:       0    invalid
/sys/firmware/acpi/interrupts/gpe1D:       0    invalid
/sys/firmware/acpi/interrupts/gpe1E:       0    invalid
/sys/firmware/acpi/interrupts/gpe1F:       0    invalid
/sys/firmware/acpi/interrupts/gpe_all:    2579
/sys/firmware/acpi/interrupts/sci:    2579
/sys/firmware/acpi/interrupts/sci_not:       0



I think what's happening is hal is issuing the command "acpi" or
something similar every X amount of seconds, generating interrupts(or whatever), then after doing this for X amount of time, eventually the gpe storm detector fires off(I can fire off a gpe storm manually if I enter "acpi" enough times(took like a 100 or so to manually fire off the gpe storm without waiting three hours)).

right now I rebooted the machine after manually firing off the gpe storm, disabled hal, then will let the system sit all day(with a ssh transaction)and look to see if the number changes at all. if not then I think it's safe to say hal is doing something funny(then I'll go and individually go through all of the *.fdi files and so forth to find the culprit).
Comment 64 Justin P. Mattock 2010-03-13 22:57:42 UTC
o.k. so the system has been sitting for three hours and no signs of a gpe storm.
during this time(with a remote machine) grep . /sys/firmware/acpi/interrupts/*
show's the number staying the same, and not growing(whatever hal is querying is generating 600 or so in a number size to interrupt/* eventually having the gpe detector fire off).

I'll leave the system as is for the remainder of the day to see if something else fires off the gpe storm, if not then start looking into hal.
Comment 65 Justin P. Mattock 2010-03-15 00:02:27 UTC
as a short workaround to atleast have some sort of working desktop I did this:
sudo mv /etc/init.d/hal{,-old}
(disable hal partially)

then vi /etc/X11/xorg.conf and added at the bottom:

Section "ServerFlags"
    Option "AutoAddDevices" "False"
    Option "AllowEmptyInput" "False"
EndSection
(thanks to: http://www.larsen-b.com/Article/341.html)

now I'm able to boot up with ubuntu, suse without hal.

then under:
grep . /sys/firmware/acpi/interrupts/*

shows a number,but the number does not move, which keeps the gpe storm detector from firing off.

I'm going to send a post to the hal people to see what they think.
Comment 66 Florian Mickler 2010-10-07 19:23:04 UTC
...ping...
Comment 67 Justin P. Mattock 2010-10-07 21:17:21 UTC
yeah I ended up removing hal(temporarily) on ubuntu, and no signs of a gpe storm(added hal back, and bamm came right back).. sent a post out to the hal guys, but received no response.

my lfs system are running gnome etc.. without hal and no signs of a gpe storm..
Comment 68 Zhang Rui 2010-10-26 00:48:16 UTC
please try the following commands, and see if the ACPI GPE counts increase or not.
"grep . /proc/acpi/battery/*/*"
"grep . /proc/acpi/ac/*/*"
"grep . /sys/class/thermal/*/*"
Comment 69 Justin P. Mattock 2010-10-26 01:10:50 UTC
at the moment I don't have a system that is having the GPE storm being triggered
(but from what I remember if I removed the battery the GPE storm disappeared and/or used acpi_osi=Darwin so my guess would be /proc/acpi/battery/*/*)

if somebody already has an older ubuntu with hal, please give the results of the above code and/or I will install an older version when I get a chance and post the results(but might be a few days)
Comment 70 Florian Mickler 2010-11-30 10:24:20 UTC
*ping*
Comment 71 Len Brown 2011-01-18 06:55:05 UTC
is this still an issue with a modern kernel?
Comment 72 Justin P. Mattock 2011-01-18 07:19:19 UTC
On Jan 17, 2011, at 10:55 PM, bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
>
>
>
> --- Comment #71 from Len Brown <lenb@kernel.org>  2011-01-18  
> 06:55:05 ---
> is this still an issue with a modern kernel?
>
> -- 
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.


I dont get this anymore with my clfs system.. last I looked into this  
hald was triggering this..
(sent a post to the hald guys, but heard no response)
Comment 73 Florian Mickler 2011-02-06 15:46:33 UTC
I'm closing this as unreproducible then.
Comment 74 Justin P. Mattock 2011-02-06 23:03:50 UTC
On Feb 6, 2011, at 7:48 AM, bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=13502
>
>
> Florian Mickler <florian@mickler.org> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|RESOLVED                    |CLOSED
>
>
>
>
> -- 
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.


alright!!!

Justin P. Mattock

Note You need to log in before you can comment on or make changes to this bug.