I have an older eeepc model (1201HA). I have always had to put the kernel lines "acpi_osi=Linux acpi_backlight=vendor" to make several hotkeys work, but on the more recent kernel versions (this is present on all the 3.15 releases), my power button isn't recognized (I also checked with xev). When I suspend I can't resume (the light just keeps blinking but neither the power button nor enter will do anything), so I have to hard reset at that point. I'm currently using 3.14.11. With that version everything is working fine. I'm using Arch Linux so the kernel should be identical to upstream which is why I'm reporting this here. This is my first bug report to kernel.org so the categories where a bit confusing to me.
Correction: I had just updated to kernel 3.14.11 and have noticed it is also affected. Latest working version for me is: 3.10.46. I think the problems started with the 3.14.* series.
Why do you think the power button is not recognized? Does it not power off the machine too?
Please attach dmesg boot log from the last known good kernel and the first known bad one.
(In reply to Rafael J. Wysocki from comment #2) > Why do you think the power button is not recognized? Does it not power off > the machine too? Yes. Nothing happens when the power button is pressed and it is not seen by xev.
Created attachment 145051 [details] Dmesg from current kernel
(In reply to Rafael J. Wysocki from comment #3) > Please attach dmesg boot log from the last known good kernel and the first > known bad one. I added the kernel log from my current kernel. Unfortunately I don't have a good kernel anymore because even the lts releases from my distribution are now on the "broken" versions and I noticed too late. If it is impossible to analyse my issue now, then I get that, apologize, the bug can be closed and I'll just hope it'll go away on its own in a future release.
(In reply to th3voic3 from comment #6) > (In reply to Rafael J. Wysocki from comment #3) > > Please attach dmesg boot log from the last known good kernel and the first > > known bad one. > > I added the kernel log from my current kernel. Unfortunately I don't have a > good kernel anymore because even the lts releases from my distribution are > now on the "broken" versions and I noticed too late. But according to comment #0, 3.14.11 works for you, don't you have that kernel installed?
BTW, please attach the acpidump of your eeepc machine.
ping...
Created attachment 147951 [details] acpidump
I have attached the acpidump. (In reply to Zhang Rui from comment #7) > (In reply to th3voic3 from comment #6) > > (In reply to Rafael J. Wysocki from comment #3) > > > Please attach dmesg boot log from the last known good kernel and the > first > > > known bad one. > > > > I added the kernel log from my current kernel. Unfortunately I don't have a > > good kernel anymore because even the lts releases from my distribution are > > now on the "broken" versions and I noticed too late. > > But according to comment #0, 3.14.11 works for you, don't you have that > kernel installed? I am using Arch Linux so the regular kernel was too new, so was the lts one and so I had to use an aur package which worked at first and then was upgraded too. I'll see if I can rewrite the PKGBUILD to get the kernel I want.
(In reply to th3voic3 from comment #11) > I have attached the acpidump. > > (In reply to Zhang Rui from comment #7) > > (In reply to th3voic3 from comment #6) > > > (In reply to Rafael J. Wysocki from comment #3) > > > > Please attach dmesg boot log from the last known good kernel and the > first > > > > known bad one. > > > > > > I added the kernel log from my current kernel. Unfortunately I don't have > a > > > good kernel anymore because even the lts releases from my distribution > are > > > now on the "broken" versions and I noticed too late. > > > > But according to comment #0, 3.14.11 works for you, don't you have that > > kernel installed? > > I am using Arch Linux so the regular kernel was too new, so was the lts one > and so I had to use an aur package which worked at first and then was > upgraded too. I'll see if I can rewrite the PKGBUILD to get the kernel I > want. Oh and see comment #1 with my correction of comment #0. Is there anywhere I can edit the original comment?
First of all, it would be great if you can upgrade your BIOS, because I've seen quite a lot of checksum errors in your acpidump output. Second, please give detailed description about "my power button isn't recognized" in comment #0. please attach the output of " grep . /sys/bus/acpi/devices/*/hid" and " ls /sys/bus/acpi/drivers/*/" in your broken kernel.
Created attachment 147991 [details] acpidump after bios update
Upgraded my bios and attached a new acpidump. On "My power button isn't recognized": As I said nothing happens when I press that button (as I'm running systemd it should power off or in my case hibernate the system). It also makes resuming from suspend impossible. No matter what I do once the system is suspended (which is indicated by the blinking power led), nothing will wake it up, which in this case doesn't mean a resume without a working display or anything it simply will not do anything. The power led just keeps blinking. If I long press the power button at that point, the netbook will turn off and I can then boot it again. I tried checking with "xev" if a button event is displayed when I press the power button and nothing happens there either.
Created attachment 148001 [details] grep . /sys/bus/acpi/devices/*/hid
Created attachment 148011 [details] ls /sys/bus/acpi/drivers/*/
(In reply to th3voic3 from comment #15) > Upgraded my bios and attached a new acpidump. > > On "My power button isn't recognized": > > As I said nothing happens when I press that button (as I'm running systemd > it should power off or in my case hibernate the system). so nothing happens even if you press the power button when the system is running, right? please attach the output of "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the button when system is running. And if it is possible, please do attach the same output for a working kernel you have. > It also makes > resuming from suspend impossible. No matter what I do once the system is > suspended (which is indicated by the blinking power led), nothing will wake > it up, which in this case doesn't mean a resume without a working display or > anything it simply will not do anything. The power led just keeps blinking. > If I long press the power button at that point, the netbook will turn off > and I can then boot it again. please attach the output of "cat /proc/acpi/wakeup" > > I tried checking with "xev" if a button event is displayed when I press the > power button and nothing happens there either.
(In reply to Zhang Rui from comment #18) > so nothing happens even if you press the power button when the system is > running, right? right > please attach the output of "grep . /sys/firmware/acpi/interrupts/*" both > before and after pressing the button when system is running. will do > And if it is possible, please do attach the same output for a working kernel > you have. I compiled a working kernel again so I'll do that to > please attach the output of "cat /proc/acpi/wakeup" ok
Created attachment 148261 [details] Interrupts for broken kernel before power button is pressed
Created attachment 148271 [details] Interrupts for broken kernel after power button is pressed
Created attachment 148281 [details] Acpi Wakeup for broken kernel
Created attachment 148291 [details] Interrupts for working kernel before power button is pressed
Created attachment 148301 [details] Interrupts for working kernel after power button is pressed
Created attachment 148311 [details] Acpi Wakeup for working kernel
I don't know if it is important, but the "Interrupts for working kernel" file was created after resuming from suspend. Should I deactivate button handling and do it again?
(In reply to th3voic3 from comment #26) > I don't know if it is important, but the "Interrupts for working kernel" > file was created after resuming from suspend. please get the interrupts output before pressing the power button and JUST after pressing the power button.
(In reply to th3voic3 from comment #19) > (In reply to Zhang Rui from comment #18) > > And if it is possible, please do attach the same output for a working > kernel > > you have. > > I compiled a working kernel again so I'll do that to > great, then can you please check if 3.13 works for you? I want to make sure if this is an 3.14 regression or not.
(In reply to Zhang Rui from comment #28) > (In reply to th3voic3 from comment #19) > > (In reply to Zhang Rui from comment #18) > > > And if it is possible, please do attach the same output for a working > kernel > > > you have. > > > > I compiled a working kernel again so I'll do that to > > > great, then can you please check if 3.13 works for you? > I want to make sure if this is an 3.14 regression or not. I'm pretty sure it doesn't. My working kernel right now is 3.10.46 and it didn't work with 3.10.53. But I'll try to find some time on the weekend to check other versions. Maybe the regression is already at that point though.
It would be good if you could test plain 3.11, then.
1. Need to confirm if the GPE 0E is used for your power button: Comparing the working kernel with the broken one. I noticed that there is GPE 0E fired on the working kernel, but on the broken kernel, no GPE 0E firing can be seen. Bad: /sys/firmware/acpi/interrupts/gpe0D: 7039 enabled /sys/firmware/acpi/interrupts/gpe0E: 0 enabled Good: /sys/firmware/acpi/interrupts/gpe0D: 2613 enabled /sys/firmware/acpi/interrupts/gpe0E: 1 enabled Can you try to press the power button several times and catch the interrupts again to confirm: the number for GPE 0E can increase each time you pressed the button? 2. Need to figure out the affection commit: BTW, I didn't see any possible changes between 3.9 and 3.11 can cause such an issue. Since you can build kernel now, could you please help to do a git bisect using the upstream git repository to figure out the culprit commit?
I'm sorry. I just moved to a new apartment and can't find the time to do more testing. Will update as soon as possible :-)
Please get the output of the "grep . /sys/firmware/acpi/interrupts/*" before and after pressing the power button for three times, at runtime, in working kernel.
(In reply to Zhang Rui from comment #34) > Please get the output of the "grep . /sys/firmware/acpi/interrupts/*" before > and after pressing the power button for three times, at runtime, in working > kernel. please do this test for bad kernel as well.
Bug closed as there is no response from the bug reporter. please feel free to reopen it if you can provide the information required in comment #34.
Just wanted to say, that after doing a few experiments, this can be considered solved. I found out, that I had to hibernate at least once and suspend works fine.