Bug 15895

Summary: Compaq Presario CQ60 Notebook: computer unresponsive while adjusting backlight level and fixed by pcie_asm=force
Product: ACPI Reporter: bugzillakernelorg
Component: ECAssignee: Lan Tianyu (tianyu.lan)
Status: CLOSED WILL_FIX_LATER    
Severity: normal CC: acpi-bugzilla, alan, chris, eajnab, fatbabyin, jbarnes, juantxorena, lenb, marwan.tngr, rui.zhang, steubens, tianyu.lan, umang.me+kernel, yakui.zhao
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.4 Tree: Mainline
Regression: No
Attachments: output of acpidump
dmesg output with problem occuring and other possible problems listed
output of acpidump from latest bios
dmesg output after freeze, force power off start up

Description bugzillakernelorg 2010-05-02 14:54:17 UTC
from dmesg:
[88254.064902] ACPI: EC: GPE storm detected, transactions will use polling mode

backlight hardware buttons (fn+f7/f8 are also non functional)

$ cat /sys/class/dmi/id/product_name 
Compaq Presario CQ60 Notebook PC

you can still move the mouse cursor around with the touchpad but it only moves like every 300ms and in big jumps, keyboard/mouse buttons completely dead, and also not delivered when it stops having a fit

dunno what else should be in this bug; please advise

(other keyboard keys are wrong too, any tip on how to fix that would be great! especially: what is the key sym for the touchpad disable button? i can't find it in input.h)
Comment 1 bugzillakernelorg 2010-05-02 14:59:09 UTC
Created attachment 26196 [details]
output of acpidump
Comment 2 Zhang Rui 2010-05-11 08:27:57 UTC
is this a regression?

how to trigger this problem? by pressing the hotkey?
Comment 3 bugzillakernelorg 2010-05-12 11:40:33 UTC
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 :[
Comment 4 Zhang Rui 2010-05-13 03:03:32 UTC
(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.
Comment 5 bugzillakernelorg 2010-05-13 12:36:43 UTC
(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
Comment 6 Zhang Rui 2010-05-14 02:04:52 UTC
hmm, so you can not reproduce the bug any more, and now poking /proc/acpi/video/*/brightness doesn't cause the GPE storm, right?
Comment 7 bugzillakernelorg 2010-05-14 12:35:57 UTC
correct
Comment 8 bugzillakernelorg 2010-05-14 21:59:07 UTC
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
Comment 9 bugzillakernelorg 2010-05-16 04:08:34 UTC
unplugging the cord also triggers display dimming, and causes "invalid framebuffer id"; it might just be an X thing, i dunno
Comment 10 bugzillakernelorg 2010-05-16 04:55:11 UTC
#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)
Comment 11 ykzhao 2010-05-20 06:12:53 UTC
(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.
Comment 12 bugzillakernelorg 2010-05-20 19:57:15 UTC
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
Comment 13 Zhang Rui 2010-05-21 01:07:24 UTC
so the problem seems to be acpi unrelated.
Comment 14 bugzillakernelorg 2010-05-21 08:18:05 UTC
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)
Comment 15 bugzillakernelorg 2010-06-04 20:35:33 UTC
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
Comment 16 bugzillakernelorg 2010-06-04 20:36:39 UTC
Created attachment 26653 [details]
dmesg output with problem occuring and other possible problems listed
Comment 17 bugzillakernelorg 2010-06-24 08:56:04 UTC
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?
Comment 18 bugzillakernelorg 2010-09-23 19:30:24 UTC
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
Comment 19 Len Brown 2010-10-01 06:53:22 UTC
why was hp-wmi rmmod'd?

you have a bunch of i915 stack traces in dmesg --
do they occur only after suspend/resume?
Comment 20 Chris Wilson 2010-10-01 09:10:59 UTC
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.
Comment 21 bugzillakernelorg 2010-10-01 20:28:44 UTC
(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
Comment 22 bugzillakernelorg 2010-11-09 01:43:18 UTC
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
Comment 23 Zhang Rui 2012-05-24 07:32:37 UTC
hi,
does the problem still exist in the latest upstream kernel?
Comment 24 bugzillakernelorg 2012-05-27 05:42:19 UTC
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
Comment 25 bugzillakernelorg 2012-05-27 05:56:01 UTC
Created attachment 73423 [details]
output of acpidump from latest bios
Comment 26 bugzillakernelorg 2012-05-27 21:57:20 UTC
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
Comment 27 bugzillakernelorg 2012-06-07 23:41:22 UTC
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)
Comment 28 Umang 2012-07-04 02:31:03 UTC
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 .
Comment 29 Umang 2012-07-20 03:02:21 UTC
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!
Comment 30 Elco 2012-08-07 07:35:35 UTC
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.
Comment 31 Manasvi Gupta 2012-09-23 08:23:25 UTC
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
Comment 32 Zhang Rui 2012-11-13 06:54:07 UTC
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?
Comment 33 Umang 2012-11-13 13:59:03 UTC
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.
Comment 34 Zhang Rui 2012-11-14 00:22:10 UTC
if you know how to reproduce the freeze, you can just get the dmesg output before and after the freeze.
Comment 35 Umang 2012-11-25 12:35:56 UTC
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?
Comment 36 Zhang Rui 2012-12-11 01:24:31 UTC
(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?
Comment 37 Umang 2012-12-11 07:29:01 UTC
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!
Comment 38 Umang 2013-01-01 18:35:39 UTC
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.
Comment 39 Lan Tianyu 2013-04-11 05:36:21 UTC
Which parameter fix this bug?

"pcie_aspm=force" or "acpi_backlight=vendor"
Comment 40 Lan Tianyu 2013-04-11 05:39:10 UTC
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"
Comment 41 Lan Tianyu 2013-04-14 13:19:55 UTC
ping...
Comment 42 Juan 2013-04-24 21:15:07 UTC
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.
Comment 43 Lan Tianyu 2013-04-25 02:56:25 UTC
OK. So "pcie_aspm=force" fix the problem. This seems a pcie device bug.
Comment 44 Juan 2013-04-25 20:17:24 UTC
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.
Comment 45 Juan 2013-04-26 18:26:08 UTC
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.
Comment 46 bugzillakernelorg 2013-04-28 11:09:12 UTC
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.
Comment 47 Juan 2013-04-28 14:10:36 UTC
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.
Comment 48 bugzillakernelorg 2013-04-28 14:18:36 UTC
that is probably a good idea, plus it won't have all my dribblings on it ;D
Comment 49 Juan 2013-05-01 14:36:09 UTC
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.
Comment 50 Lan Tianyu 2013-05-14 11:46:03 UTC
(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.
Comment 51 bugzillakernelorg 2013-05-14 17:55:09 UTC
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 ...
Comment 52 Lan Tianyu 2013-05-15 01:09:15 UTC
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>
Comment 53 Lan Tianyu 2013-06-03 07:09:53 UTC
ping ...
Comment 54 Lan Tianyu 2013-06-19 05:36:57 UTC
Since no response for long time, close this bug as will_fix_later. Please feel free reopen this bug if available.
Comment 55 j 2017-08-15 06:53:38 UTC
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