Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

if power button pressed 1x it creates the same ACPI event twice

600 views
Skip to first unread message

Sander Eikelenboom

unread,
Jan 13, 2015, 11:40:06 AM1/13/15
to
Hi Rafael / Len,

When i press the power-button on my intel NUC, i get twp ACPI power-events shortly
after one another (within a second), instead of just one.

It doesn't matter if i have the old /proc/acpi interface enabled or disabled in the kernel config.

I have tested a few older kernels lingering around on the box and 3.14 already
has this problem. 3.2 (from the debian repo) doesn't have the problem, it only
fires one event.

I did find another report:
Re: lenovo ultrabay docking station: if power button pressed 1x it creates 2x the same ACPI event
http://www.spinics.net/lists/linux-acpi/msg54723.html
But that hasn't come to a conclusion ...


Unfortunately 3.2 - 3.19-rc4 is a bit of a largish bisect window, so that's
unfeasible :-)

I compiled in apci debug support and tried:
echo "0x00080000" > /sys/module/acpi/parameters/debug_layer
echo "0xffffffff" > /sys/module/acpi/parameters/debug_level

But i don't get any extra output in dmesg ?

Do you have any ideas for a debug patch or better values to figure out what is going on ?

--
Sander

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Sander Eikelenboom

unread,
Jan 13, 2015, 11:50:06 AM1/13/15
to
Tuesday, January 13, 2015, 5:35:10 PM, you wrote:

> Hi Rafael / Len,

> When i press the power-button on my intel NUC, i get twp ACPI power-events shortly
> after one another (within a second), instead of just one.

> It doesn't matter if i have the old /proc/acpi interface enabled or disabled in the kernel config.

> I have tested a few older kernels lingering around on the box and 3.14 already
> has this problem. 3.2 (from the debian repo) doesn't have the problem, it only
> fires one event.

> I did find another report:
> Re: lenovo ultrabay docking station: if power button pressed 1x it creates 2x the same ACPI event
> http://www.spinics.net/lists/linux-acpi/msg54723.html
> But that hasn't come to a conclusion ...


> Unfortunately 3.2 - 3.19-rc4 is a bit of a largish bisect window, so that's
> unfeasible :-)

> I compiled in apci debug support and tried:
> echo "0x00080000" > /sys/module/acpi/parameters/debug_layer
> echo "0xffffffff" > /sys/module/acpi/parameters/debug_level

> But i don't get any extra output in dmesg ?

> Do you have any ideas for a debug patch or better values to figure out what is going on ?

> --
> Sander

Hmm is it normal that it registers in this way (twice) ?

[ 5.817980] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[ 5.837907] ACPI: Power Button [PWRB]
[ 5.847540] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 5.866915] ACPI: Power Button [PWRF]

Sander Eikelenboom

unread,
Jan 19, 2015, 8:10:05 AM1/19/15
to
Hello Sander,
Hi Rafael / Len,

Got some more time to test:

- It's indeed giving one event for both registered power buttons (which in reality
are just one hardware button) printing acpid's "%e" revealed that:
1421672289-161192235 | button/power PBTN 00000080 00000000
1421672289-279647745 | button/power LNXPWRBN:00 00000080 00000004

So i tested on another box (amd instead of intel), and that also registers 2
power buttons:

# dmesg | grep -i button
[ 13.435060] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[ 13.435294] ACPI: Power Button [PWRB]
[ 13.435495] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 13.435683] ACPI: Power Button [PWRF]

So the question is .. should both register and should scripts adjust to pick up just one of them ?
Or can, as a more general solution, just one be ignored when registering ?

Sander Eikelenboom

unread,
Jan 19, 2015, 8:30:05 AM1/19/15
to
Whoops sorry for the fragmentation of the report ... but just thought the output
under kernel 3.2.0 could be handy as well .. as that only fires one event:

[ 4.003753] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[ 4.003838] ACPI: Power Button [PWRB]
[ 4.003977] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[ 4.005530] ACPI: Power Button [PWRF]

It registers also two ..
But when the power button is pressed only fires this one:

1421673524-817561070 | button/power PBTN 00000080 00000000

Sander Eikelenboom

unread,
Feb 10, 2015, 5:50:05 PM2/10/15
to
Hello Sander,
Hi Rafael / Len,

Unfortunately haven't heard anything back .. and with 3.19-rc6 it seems
miraculously fixed, i receive only one event on a powerbutton press.

However with 3.19.0 (final) .. it was back again .. 1 press .. 2 events.

So i bisected ... but i came out on the netlink commit below. Now seems acpid to
be using input layer and netlink if the deprecated /proc/apci/events is not compiled in (which
isn't at present) according to [1].

But how the fsck this relates to one another... the only thing i can imagine is
that i have to take that text literal: It uses both input layer and netlink
simultaneously and will receive an event via both of those ways which slightly
differ in naming but have the same origin ?

acpid used is debian wheezy: acpid 1:2.0.16-1+deb7u1 amd64 Advanced Configuration and Power Interface event daemon

--
Sander

[1] http://manpages.ubuntu.com/manpages/precise/man8/acpid.8.html



8b7c36d810c61ab16997f4387fc16291410700f8 is the first bad commit
commit 8b7c36d810c61ab16997f4387fc16291410700f8
Author: Pablo Neira <pa...@netfilter.org>
Date: Thu Jan 29 10:51:53 2015 +0100

netlink: fix wrong subscription bitmask to group mapping in

The subscription bitmask passed via struct sockaddr_nl is converted to
the group number when calling the netlink_bind() and netlink_unbind()
callbacks.

The conversion is however incorrect since bitmask (1 << 0) needs to be
mapped to group number 1. Note that you cannot specify the group number 0
(usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
since this is rejected through -EINVAL.

This problem became noticeable since 97840cb ("netfilter: nfnetlink:
fix insufficient validation in nfnetlink_bind") when binding to bitmask
(1 << 0) in ctnetlink.

Reported-by: Andre Tomt <an...@tomt.net>
Reported-by: Ivan Delalande <col...@arista.com>
Signed-off-by: Pablo Neira Ayuso <pa...@netfilter.org>
Signed-off-by: David S. Miller <da...@davemloft.net>

:040000 040000 1a624f23ebb1006bcd734f850c2350bdce751356 e24acc011aea2048599514ed278582a27265fab6 M net

Rafael J. Wysocki

unread,
Feb 10, 2015, 7:20:05 PM2/10/15
to
On Tuesday, February 10, 2015 11:46:17 PM Sander Eikelenboom wrote:

[cut]

> Hi Rafael / Len,
>
> Unfortunately haven't heard anything back .. and with 3.19-rc6 it seems
> miraculously fixed, i receive only one event on a powerbutton press.
>
> However with 3.19.0 (final) .. it was back again .. 1 press .. 2 events.
>
> So i bisected ... but i came out on the netlink commit below. Now seems acpid to
> be using input layer and netlink if the deprecated /proc/apci/events is not compiled in (which
> isn't at present) according to [1].
>
> But how the fsck this relates to one another... the only thing i can imagine is
> that i have to take that text literal: It uses both input layer and netlink
> simultaneously and will receive an event via both of those ways which slightly
> differ in naming but have the same origin ?

That's unlikely.

I'm not sure what the problem is ATM and I suppose it would require some serious
debugging, so I'd recomment filing an ACPI bug at bugzilla.kernel.org and adding
this information to it. That increases the chances that someone will take care
of it sooner that I can.


--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
0 new messages