Bug 13502
| Summary: | GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | sveina |
| Component: | EC | Assignee: | Alexey Starikovskiy (astarikovskiy) |
| Status: | CLOSED UNREPRODUCIBLE | ||
| Severity: | normal | CC: | akpm, alga777, astarikovskiy, florian, hsolmarketing9, jhonpeteraus31, justinmattock, kdato, lenb, me, nemesis, phoenp, rjw, rui.zhang, sveina, tklegalsca, yakui.zhao |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 13070 | ||
| Attachments: |
dmesg output at 20:41 hours uptime, including sleep
acpidump output kernel log w/debug on (16MB unpacked) Kernel .config debug battery_get_state dmesg output, including new debugging code dmesg_ec_intr=1 dmesg_ec_intr=_not_used |
||
|
Description
sveina
2009-06-10 20:04:11 UTC
I marked this as a regression. please provide dmesg and acpidump outputs. Created attachment 21854 [details]
dmesg output at 20:41 hours uptime, including sleep
Created attachment 21855 [details]
acpidump output
please uncomment "#define DEBUG" at the beginning of drivers/acpi/ec.c and attach new dmesg. 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. Created attachment 21860 [details]
kernel log w/debug on (16MB unpacked)
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... 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? 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. 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.
Yakui, Please notice STA method with call to OSDW(). Direct access to smart battery exists only for acpi_osi=Darwin CONFIG_ACPI_SBS was already disabled. Hm. I think I'll attach my .config too. Created attachment 21878 [details]
Kernel .config
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...
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.
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. 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. 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? ;_; 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. 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? 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 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 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. 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 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. 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 As suspected, the test on the Satellite L300 produces the same results. SO it cannot be hald or acpid. (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. 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
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 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 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 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)
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)
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)
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.
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 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)
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 The bug occurs in 2.6.30.5, but will try 2.6.31. Will let you know. 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. 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. 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. 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? 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. 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? (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. 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. Created attachment 23174 [details]
dmesg_ec_intr=1
Created attachment 23175 [details]
dmesg_ec_intr=_not_used
(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? (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). reply to comment #51: 'ec_intr=' is not doing anything, which is what my test tried to work out for definite. does the problem still exists in the latest kernel, say 2.6.33 or 2.6.34-rc1? 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. please attach the output of "grep . /sys/firmware/acpi/interrupts/*". 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
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 please attach the same output in a kernel with the gpe storm. :) 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). 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. 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). 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. ...ping... 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/*/*" *ping* is this still an issue with a modern kernel? I'm closing this as unreproducible then. |