Latest working kernel version: unknown Earliest failing kernel version: 2.6.24 Distribution: Debian Hardware Environment: HP nc4010 notebook Problem Description: when the power button is pressed it sometimes produces two acpi events, sometimes one. With 2.6.26-rc8 I get two events quite reliably, with two different 2.6.25 Debian kernels I get two events more or less often. Steps to reproduce: cat /proc/acpi/event press the power button -> two events are printed on the terminal On most systems only one event is generated. Generating two events or even variable number of events makes using the button for anything but poweroff (like hibernation) quite difficult.
Created attachment 16695 [details] dmi info from the machine
You say that 2.6.24 was the earliest kernel that failed. This perhaps implies that 2.6.23 did not fail? Confusing. Please clarify.
Hi, Michael According to the description it seems that two or more events are produced when the power button is pressed. IMO this issue is related with the Hardware/BIOS firmware. Anyway please attach the output of acpidump. Thanks.
Michal, could you please attach the acpidump output please? please attach the result of "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the power button.
It probably failed with 2.6.22 as well. Whatever I had before 2.6.24. Probably never had 2.6.23.
Created attachment 16768 [details] acpidump output
Created attachment 16769 [details] the changed interrrupts
Created attachment 16770 [details] the interrupt list
look like bug 10509 I will try if unloading button helps
does power button work under windows?
Hi, michal, any update?
Unloading the button module before suspend seems to work around the problem so far. I did not try running Windows on this machine.
You said that it used to work with 2.6.22, right? Do you mean you can get ONLY one event reliably? Please make a double check. Because the symptom shows that this may be a hardware issue and it should always fail in all kernel releases.
No I said it did not work with 2.6.22. I had 2.6.18 before that but I probably only had it because I installed an old release of Debian, and upgraded immediately. I also think that this issue is somewhat hardware specific but not only to this particular hardware. There is at least bug 10509 which describes pretty much the same on a completely different system. This makes me think that such problem is not really uncommon, and the workaround should not be too difficult. It would have to be implemented either in the kernel or in every software that uses the kernel acpi events. The workaround should be probably put in place as people get really confused by this behaviour, and possibly report bugs against something completely different as well.
(In reply to comment #14) > No I said it did not work with 2.6.22. > > I had 2.6.18 before that but I probably only had it because I installed an > old > release of Debian, and upgraded immediately. > so this is a hardware issue. :) > the workaround should not be too difficult. no. there can be some workarounds for some issues caused by this hardware bug, like the one for suspend in #10509. but there is no way to workaround the hardware bug in kernel, I mean, if a power button key press generates two button events, how can Linux kernel know that the second button event is a bogus one? IMO, any ugly hacks for some platform specific problems are hard to get into the base kernel, and this bug should really be handled in user space. BTW, if the problem can not be reproduced in windows, it becomes a Linux specific issue and we should take care of it in Linux kernel. But now, I'll reject it as it's a hardware issue and we can not fix it. :( Sorry that I can not help you, please try to upgrade the BIOS and see if it helps.
Upgrading the bios is not really an option on this system. There are only bioses for a slightly different model available, and the only boot option other than the hardrive is network boot. Should the upgrade cause trouble reverting it would be very difficult. And yes, it is possible to detect the bogus events. The hardware usually does not make it reasonably possible to press the power button more than once in a second.
(In reply to comment #16) > > And yes, it is possible to detect the bogus events. Yes. We can do this but we SHOULD NOT fix it in this way because this is not a generic solution. Besides, this can done in user space as well. > The hardware usually does > not make it reasonably possible to press the power button more than once in a > second. > Yes, as you said, it's "usually" but not "always". If we do it in this way then we'll get more bug report about no respond from the second power button key press in one second. :p User space is free/flexible to implement any workarounds while this is not true for kernel. :(