Bug 15895

Created attachment 26196 [details]
output of acpidump

is this a regression?

how to trigger this problem? by pressing the hotkey?

using the gnome brightness applet / /proc/acpi/video/*/brightness
and i'll be damned if it isn't doing it now, i do not know what might have set off the GPE storm, all i do is run / suspend my laptop daily for about 2 weeks at a time, and nothing in recent memory might have been a factor.

further, my brightness keys have been broken for a while, sending wrong keysyms; and have been since: https://bugzilla.kernel.org/show_bug.cgi?id=15344, and as alluded to in the first post

i'd _really_ like to fix my keysyms, before the hp_wmi thing it was sending the right keysyms for all the extra keys, it hasn't since; is this sort of thing permanent? i also downgraded my bios checked functionality (was still broke) and then upgraded it again in the spirit of comment #28 on #15344 after that suggestion failed, and that also failed.

i'm glad to report and troubleshoot bugs but if its going to break my laptop i'll be sad :[

(In reply to comment #3)
> using the gnome brightness applet / /proc/acpi/video/*/brightness
> and i'll be damned if it isn't doing it now,

Sorry, I don't quite understand.
do you mean the problem can be reproduced by poking /proc/acpi/video/*/brightness?

> 
> further, my brightness keys have been broken for a while, sending wrong
> keysyms; and have been since:
> https://bugzilla.kernel.org/show_bug.cgi?id=15344, and as alluded to in the
> first post
> 
you should push Matthew to look at that bug. :p

> i'd _really_ like to fix my keysyms, before the hp_wmi thing it was sending
> the
> right keysyms for all the extra keys, it hasn't since;

> is this sort of thing permanent?

I'm not sure as I'm not the maintainer of hp-wmi driver.
IMO, this is a bug that should be fixed.
so please feel free to report this in that bug report as well.

(In reply to comment #4)
> (In reply to comment #3)
> > using the gnome brightness applet / /proc/acpi/video/*/brightness
> > and i'll be damned if it isn't doing it now,
> 
> Sorry, I don't quite understand.
> do you mean the problem can be reproduced by poking
> /proc/acpi/video/*/brightness?
> 

sorry, i felt what i had typed was a little wobbly, when it was doing it; the gnome brightness applet was writing to that location as far as i know to change the backlight level. it is not now and hasn't since done it again. i do not know what could have caused it to have a "GPE storm" at that time, when i reported the bug

also, i thought i did push on the bug :] suggestions welcome

hmm, so you can not reproduce the bug any more, and now poking /proc/acpi/video/*/brightness doesn't cause the GPE storm, right?

correct

ok; i think something is going on related with this bug,

[ 1956.776653] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[ 3825.258778] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[ 4013.281294] CE: hpet increasing min_delta_ns to 15000 nsec
[ 5373.476818] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

the computer is still unresponsive and its related to the backlight, it's been going unresponsive after going idle, the display dims the backlight, then it turns it off after a bit longer; when jostled from inactivity the computer is unresponsive until i switch tty's to 1 and back to 7 where the X server lives

unplugging the cord also triggers display dimming, and causes "invalid framebuffer id"; it might just be an X thing, i dunno

#8, #9 aren't sure bets either; wifi just disconnected and it did it, its probably random :[ (will try and see what X has to do with it)

(In reply to comment #9)
> unplugging the cord also triggers display dimming, and causes "invalid
> framebuffer id"; it might just be an X thing, i dunno

Will you please boot the system into the console mode and see whether the issue still exists when using the following command to adjust the backlight brightness?
   >echo XXX > /sys/class/backlight/*/brightness


thanks.

the computer has not acted in the manner of the first post since the first post (after a reboot it hasn't since reoccured), sorry for dragging the bug offtopic

the other posts regarding X just make X unresponsive until i switch tty's

and my keys are still busted

so in summary; original problem has not reoccured and is not happening at the moment

so the problem seems to be acpi unrelated.

possibly; but the backlight was goverened by acpi at the time; i'll report back if it ever happens again (also the GPE storm was an acpi EC message, and it preceded the problem)

alright, this is occurring again, i tried echo 100 > /proc/acpi/video/OVGA/DD03/brightness, echo 20 > ... /brightness, and the brightness smoothly changed with no effect on the machine, leading me to think this is an Xorg problem; though i got the ACPI EC message again, and there are some weird things in my dmesg (which i'll attach shortly) i don't know of any of those messages warrant looking into, but some sound dire, like:

[568130.419426] NOHZ: local_softirq_pending 100

and there are some stack dumps that don't look like oopses' i don't know where i should file those either

Created attachment 26653 [details]
dmesg output with problem occuring and other possible problems listed

happened again following:

[86016.309637] ACPI: EC: GPE storm detected, transactions will use polling mode

i noticed that the backlight is normally faded, and i think its done in SW with ACPI, in addition to being nonresponsive the normal smooth transition changes to a staccato of discrete transitions, with some that would make it smooth but slow, missing

how do i post the requisite ACPI tables in a form that can be consumed here to see if this is the case?

someday i'll leave less speculation on bugs ... but today, i found out the GPE storm, and the unresponsive computer were all after hp-wmi is rmmod'd after having been loaded

why was hp-wmi rmmod'd?

you have a bunch of i915 stack traces in dmesg --
do they occur only after suspend/resume?

They're allocation failures which may or may not be expected (difficult to know whether the kernel includes the backported fix). And the framebuffer error which is likely the ubuntu copy-fb hack. Those warning don't seem of themselves pertinent to the computer being unresponsive when adjusting the backlight.

If you grab the Intel ACPI compiler [iasl] that can decompile the tables into a human readable form.

(In reply to comment #19)
> why was hp-wmi rmmod'd?
related to my escapade with another bug:
https://bugzilla.kernel.org/show_bug.cgi?id=15344

ok, i looked at latencytop last time this happened; and looked at the code

drivers/acpi/ec.c:
...
        /* check if we received SCI during transaction */
        ec_check_sci_sync(ec, acpi_ec_read_status(ec));
        if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
                msleep(1);
                /* It is safe to enable the GPE outside of the transaction. */
                acpi_enable_gpe(NULL, ec->gpe);
        } else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
                pr_info(PREFIX "GPE storm detected, "
...

well, turns out the latency and the manner in which it is unresponsive is closely related to the time in msleep (msec_to_jiffies + 1, then schedule slack until the next wakeup)

you can force the bit and it exhibits the unresponsiveness that i opened the bug for. if msleep could be factored out (i don't know how to do it myself, but i'm investigating) then the responsiveness should be maintained. recently Alexey Starikovskiy has been removed as the maintainer, apparently his email is unreachable; so i haven't been able to figure out why the sleep is in there at all

hi,
does the problem still exist in the latest upstream kernel?

it does it with 2.6.38 still, i think i stumbled on a way to provoke it so i may be trying the latest if i can.

normally i have display dimming inhibited but i've been burning dvds today and turned inhibit off, as the display is dimming if i interrupt it with the mouse it seems that a few attempts at dimming will cause the GPE storm, or suspending

any idea why the GPE storms even happen, can't the logic be changed to disable the polling after a while? from my understanding there were bios & machines that would never recover from the "storm", but this laptop very rarely ever triggers one, sometimes during suspend and it is always temporary

Created attachment 73423 [details]
output of acpidump from latest bios

running:
Linux krang 3.4.0-999-generic #201205260406 SMP Sat May 26 08:07:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

from ubuntu's daily kernel buildbot, currently waiting for problem to reoccur

i've ran 3.4 for a while, not long enough to exhibit the problem like it does with the older kernel, but i had to reboot.

question: could compcache/zram have anything to do with helping the gpe storm code being triggered or is swap latency or complexity not interesting to that code path

(the reboot was because i couldn't rmmod zram with 3.4, still use it though)

I have the same issue. I just installed the 3.4 mainline kernels for Ubuntu from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/ and I was easily able to reproduce the freeze. It just took persistent changing and within a few seconds my computer froze. 

This bug was also reported on Launchpad https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007765 where someone else has also tested it on 3.4 and found that the problem still exists.

Please let me know if I can give you any other information about the freeze. If it helps, there are various logs uploaded from my computer at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1015364 .

Can this bug not be marked as NEEDINFO anymore? This bug has been reproduced by at least two people. 

If there is still more information necessary, those of us affected could try to find whatever information you need.

Thanks!

What additional information is required? I am experiencing this bug too, and it's really annoying.

If I knew what information was needed, I could try to provide it to help solve this bug.

Hello,

I came here from (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007765).  

I am affected by this bug as well, but, I am using Ubuntu 12.04.1 with Kernel version -> 3.2.0-31-generic. If there is a similar bug logged for v3.2 can someone kindly provide link for it? I will update that one with my issue.

Thank you,
Manasvi Gupta

hmm, first of all, let's make sure that we're talking about the same problem.

so, Umang, Elco, and Manasvi,
can you see the GPE  storm messages in your laptop?
can you see the i915 error messages in your laptop?

and  bugzillakernelorg@lez.ath.cx,
can you check which error message is related?
say, can you get the GPE Storm message when the backlight still works?
or can you get the i915 messages when the backlight still works?

Thanks for your message, Zhang. Could you post details about how to check those error messages? I'm guessing that I will need to look in some system log. I don't mind trying to reproduce the freeze and looking for error messages.

if you know how to reproduce the freeze, you can just get the dmesg output before and after the freeze.

Created attachment 87211 [details]
dmesg output after freeze, force power off start up

I'm sorry I seem to have missed your reply.

Anyway, reproducing this bug is really easy. So I typed `dmesg >> Desktop/dmesg-before.txt` (and ensured there was content in the file), then reproduced the freeze. After forcing the laptop to power off and booting up again, I ran `dmesg >> Desktop/dmesg-after.txt`. Unfortunately, the before file was empty after the restart. So I have attached the after file.

Did you want me to get the dmesg output after the freeze but before a restart? Is there a way to do that?

(In reply to comment #35)
> Created an attachment (id=87211) [details]
> dmesg output after freeze, force power off start up
> 
No, this does not seems to be a dmesg output after resume.
I can not see any messages about system suspending.

could you please redo the test?

I'd be happy to redo the test. However, I feel as though I did something wrong the first time and I'm probably going to do wrong again. So it would be awesome if you could clarify if this is what you want me to do:

1. Boot the laptop. Save dmesg output (as "dmesg-before").

2. Then reproduce the bug by rapidly changing the brightness.

3. Now, the computer is frozen and I cannot do anything with the computer. So I have to force power-off the computer by holding the power button down for a few seconds. The laptop is now completely powered off.

4. Power on the laptop again and save dmesg output as "dmesg-after".

Is this what you want me to do? Because the system doesn't suspend or resume; I have to force it to shut down and then boot once again. So I don't think you will see anything about suspending or resuming.

Do let me know what I should do.

Thanks!

A workaround was posted on Launchpad. (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007765/comments/71)

I can now change my brightness settings without the system freezing.

Which parameter fix this bug?

"pcie_aspm=force" or "acpi_backlight=vendor"

Could you provide the output of dmicode? I can make add your machine into acpi backlight list and then you don't need to add "acpi_backlight=vendor"

ping...

Hello,

I had the same problem with a Dell Inspiron 5521,with an Intel HD 4000, and with "acpi_backlight=vendor" in the grub config. After adding "pcie_aspm=force" doesn't freezes anymore.

OK. So "pcie_aspm=force" fix the problem. This seems a pcie device bug.

Don't want to pressure or anything, but this is something that is going to be fixed, or the fix is to use pcie_aspm=force? Because this freezes my system, so I have to choose between a laptop that freezes when changing the brightness or a laptop that freezes randomly.

An update: it turns out that pcie_aspm=force doesn't fully solves the problem. With that option, sometimes it works, but it may freeze the computer anyway. The problem I had in my previous post about the random freezes were actually related to the automatic brightness change from my power-saving options.

So the bug still stands: laptops with intel graphics freezes when changing the brightness.

sorry about the late reply, and mixing in other problems i had with the original post.

aspm has nothing to do with it for me, and everything i noticed happening could be explained by only _X_ being nonresponsive during backlight changes, not the entire computer, and it was never a lock up, just temporary unresponsiveness while the backlight was doing a fading trick of some sort.

i've always had very weird things happen with linux when i've got little free memory and things like X are candidates for being swapped out a bit. willing to bet this is just an artifact of that.

to reiterate, the initial bug was never about a permanent freeze.

If that's the case, shall I open a new bug with the hard-freeze issue? I'll provide any needed information, but I haven't found anything in any log.

that is probably a good idea, plus it won't have all my dribblings on it ;D

More updates: at leastin my system (dell inspiron 15r 5521), pcie_asm=force is not needed. I needed to add "dell_laptop.backlight=0" instead.

Two comments:
1.- I found this solution by mere luck, in an obscure post of an obscure forum with somebody with a similar problem (not the same). The documentation for the dell laptop kernel stuff is incredibly sparse, not to say nonexistant.
2.- Although pcie_asm=force was finally unneeded, it solved the problem partially. I went for a sure hard freeze when changing the brightness to a possible freeze.

(In reply to comment #46)
> sorry about the late reply, and mixing in other problems i had with the
> original post.
> aspm has nothing to do with it for me, and everything i noticed happening
> could
> be explained by only _X_ being nonresponsive during backlight changes, not
> the
> entire computer, and it was never a lock up, just temporary unresponsiveness
> while the backlight was doing a fading trick of some sort.
Hi:
    Does "ACPI: EC: GPE storm detected" take place during changing backlight or your system is freezed? If not, I think the log is not related with the freeze.
It's better to test this after rebooting machine because the log only take place once. You can just check whether it exist after the first X org freeze.

> i've always had very weird things happen with linux when i've got little free
> memory and things like X are candidates for being swapped out a bit. willing
> to
> bet this is just an artifact of that.
> to reiterate, the initial bug was never about a permanent freeze.

i know the GPE storm message is only posted once, and it happens after, because the EC is involved in the backlight animation this laptop/firmware does on level changes, and there's a 20ms or 200ms timeout or something on transactions in polling mode, leading to the freeze.

if it was simple to reproduce the GPE storm i could probably tell hp about it ...

It's better to open EC debug to see what happen in the EC driver during changing brightness.
Please open the EC debug and attach the output of dmesg after changing brightness.
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d45b287..34189f4 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -27,7 +27,7 @@
  */

 /* Uncomment next line to get verbose printout */
-/* #define DEBUG */
+#define DEBUG

 #include <linux/kernel.h>
 #include <linux/module.h>

ping ...

Since no response for long time, close this bug as will_fix_later. Please feel free reopen this bug if available.

i was bugzillakernelorg, and i lost access to that dns alias in may 2013, sorry for not responding

i do not plan on reopening this bug, just felt bad i left it

thanks