resume from S2R changes from 5.15.19 to 5.15.27

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.

The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

regards Henrik

Giovanni

2022-04-05 08:36:55 UTC

Post by Henrik Carlqvist
If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for
example between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a
binary search for that point. Now you know that 5.15.19 work as
before and 5.15.27 works at after. What about the version in the
middle in between? That would be 5.15.23. Once you have tested with
kernel 5.15.23 you will know if the next step is to search between
5.15.19 and 5.15.23 or between 5.15.23 and 5.15.27.

The handling of events by buttons is done on elogin daemon.
The elogin daemon interacts with acpi daemon. I suggest to check the
log to see which events are detected at boot time.

Ciao
Giovanni

--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

Jim Diamond

2022-04-07 00:40:54 UTC

Post by Giovanni

The handling of events by buttons is done on elogin daemon.
The elogin daemon interacts with acpi daemon. I suggest to check the
log to see which events are detected at boot time.

Giovanni,

I'm not sure which log you are referring to, but in /var/log the only
file I see with "elogind" is /var/log/message. At boot time there are
lines like this

Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event3 (Power Button)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event1 (Power Button)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event2 (Lid Switch)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event8 (HP WMI hotkeys)

but this is the same set of devices for both .19 and .27.

Were you thinking of some other log information?

Jim

Giovanni

2022-04-07 12:40:50 UTC

Post by Jim Diamond
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event3 (Power Button)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event1 (Power Button)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event2 (Lid Switch)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event8 (HP WMI hotkeys)
but this is the same set of devices for both .19 and .27.
Were you thinking of some other log information?
Jim

No, that's the log which shows that the buttons are trapped by
elogin-daemon and that led me to think of problems in elogind. But also
this package didn't change.

Kernel change-logs show modifications in the area, with several
references to 'suspend'.
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.25
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.26
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.27

Ciao
Giovanni

--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

Jim Diamond

2022-04-09 15:25:43 UTC

Post by Giovanni

No, that's the log which shows that the buttons are trapped by
elogin-daemon and that led me to think of problems in elogind. But also
this package didn't change.
Kernel change-logs show modifications in the area, with several
references to 'suspend'.
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.25
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.26
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.27

Giovanni,

thanks for those links. There are some suspend comments in other
changelogs as well, but the 5.15.25 does talk about a problem with the
AC adapter on another HP system.

So maybe .24 or .25 would be the place to start compiling kernels, as
Henrik suggested.

Cheers.
Jim

Jim Diamond

2022-04-07 00:08:12 UTC

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

Hi Henrik,

thanks for your thoughts. I was hoping not to dig through the source
code (to say nothing of doing a binary search with kernel compiles at
each stage), but I may end up doing that.

I don't know how many people are reading this newsgroup these days,
but I am somewhat intrigued if I am the only person having this issue.
I had previously posted this to alt.os.linux since it is not
slackware-specific (it also happens to me with the artix system I was
using while waiting for 15.0 to appear). However, sadly that group is
mostly full of spam these days.

Cheers.

Jim

User

2022-04-07 18:25:03 UTC

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

Hi Henrik,
thanks for your thoughts. I was hoping not to dig through the source
code (to say nothing of doing a binary search with kernel compiles at
each stage), but I may end up doing that.
I don't know how many people are reading this newsgroup these days,
but I am somewhat intrigued if I am the only person having this issue.
I had previously posted this to alt.os.linux since it is not
slackware-specific (it also happens to me with the artix system I was
using while waiting for 15.0 to appear). However, sadly that group is
mostly full of spam these days.
Cheers.
Jim

I did some testing on my laptop running Slackware 15.0 with 5.15.27.

Suspend to RAM
- Awakens on opening the case
- Does nothing on removing/attaching power

Suspend to disk
- Awakens on opening the case
- Does nothing on removing/attaching power

User

2022-04-08 19:04:30 UTC

On 2022-04-05 at 02:45 ADT, Henrik Carlqvist

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

Hi Henrik,
thanks for your thoughts. I was hoping not to dig through the source
code (to say nothing of doing a binary search with kernel compiles at
each stage), but I may end up doing that.
I don't know how many people are reading this newsgroup these days,
but I am somewhat intrigued if I am the only person having this issue.
I had previously posted this to alt.os.linux since it is not
slackware-specific (it also happens to me with the artix system I was
using while waiting for 15.0 to appear). However, sadly that group is
mostly full of spam these days.
Cheers.
Jim

I did some testing on my laptop running Slackware 15.0 with 5.15.27.
Suspend to RAM
- Awakens on opening the case
- Does nothing on removing/attaching power
Suspend to disk
- Awakens on opening the case
- Does nothing on removing/attaching power

Screen Saver Mode
- Awakens on opening the case
- Awakens on removing/attaching power

Jim Diamond

2022-04-08 21:37:23 UTC

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

<snip>

Post by Jim Diamond
I don't know how many people are reading this newsgroup these days,
but I am somewhat intrigued if I am the only person having this issue.
I had previously posted this to alt.os.linux since it is not
slackware-specific (it also happens to me with the artix system I was
using while waiting for 15.0 to appear). However, sadly that group is
mostly full of spam these days.

I did some testing on my laptop running Slackware 15.0 with 5.15.27.
Suspend to RAM
- Awakens on opening the case
- Does nothing on removing/attaching power

Thanks for the report. Can you tell me what sort of processor you
have? (In short, AMD or Intel? And further, the model number if you
don't mind.)

Cheers.
Jim

User

2022-04-10 10:56:56 UTC

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

<snip>

I did some testing on my laptop running Slackware 15.0 with 5.15.27.
Suspend to RAM
- Awakens on opening the case
- Does nothing on removing/attaching power

Thanks for the report. Can you tell me what sort of processor you
have? (In short, AMD or Intel? And further, the model number if you
don't mind.)
Cheers.
Jim

Its a 10th Gen Intel

Jim Diamond

2022-04-10 23:25:16 UTC

I've hunted around a bit, but don't see any obvious reasons for this. (I
define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.
The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

<snip>

I did some testing on my laptop running Slackware 15.0 with 5.15.27.
Suspend to RAM
- Awakens on opening the case
- Does nothing on removing/attaching power

Thanks for the report. Can you tell me what sort of processor you
have? (In short, AMD or Intel? And further, the model number if you
don't mind.)
Cheers.

Its a 10th Gen Intel

Thanks. Not a surprise, now that I know it is an issue with how some
AMD systems handle AC power events.

Jim

John Forkosh

2022-04-05 10:52:59 UTC

Post by Jim Diamond
I have a laptop running Slackware64 15.0, which, previous to upgrading
to 5.15.27, required me to press a keyboard key after opening the lid
to awaken it (after it was suspended to RAM).
After upgrading to 5.15.27 (the dirty pipe saga of 2022), the laptop
now awakens just by opening the lid. (I consider this to be A Good
Thing.)
However, it also awakens (with the lid still closed) if I unplug the
AC power. (I consider this to be A Bad Thing.)
I've hunted around a bit, but don't see any obvious reasons for this.
(I define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.
This happened with both Slackware64 15.0 and with Artix, so I'm
leaning in the "something specific with kernel" direction, as opposed
to "something peculiar of my distro".
FWIW, it is an HP Envy x360 with a Ryzen 4700U.
Has anyone here seen this on their hardware? I'd like it NOT to
wakeup when the AC power is disconnected, and if anyone has some
ideas, I'd be happy to hear it.
Thanks. Jim

You might be able to add a file in /etc/acpi/events/ so that it
ignores that AC power connected/disconnected event. I'd tried but
failed to do a similar thing on a yoga-style laptop -- disable the
keyboard when folded to yoga-style, and re-enable it when folded back.
So, first modify the acpi/acpi_handler.sh to log every single event
it ever sees. Then plug/unplug the AC power and check the logs.
If you're actually trapping those events, then you should likely be
able to add some events/ scripts to handle them however you prefer.
(But, like I said, I failed to accomplish all that.)

--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )

Giovanni

2022-04-05 13:46:33 UTC

Post by John Forkosh
You might be able to add a file in /etc/acpi/events/ so that it
ignores that AC power connected/disconnected event. I'd tried but
failed to do a similar thing on a yoga-style laptop -- disable the
keyboard when folded to yoga-style, and re-enable it when folded
back. So, first modify the acpi/acpi_handler.sh to log every single
event it ever sees. Then plug/unplug the AC power and check the
logs. If you're actually trapping those events, then you should
likely be able to add some events/ scripts to handle them however you
prefer. (But, like I said, I failed to accomplish all that.)

That may work on 14.2 and lower versions. The elogind daemon intercepts
the events before they get to the acp handler.

In 15.0 had to change the file /etc/elogind/logind.conf to ignore 'halt'
and 'suspend' events.

Ciao
Giovanni

--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

Jim Diamond

2022-04-07 00:02:54 UTC

Post by Giovanni

That may work on 14.2 and lower versions. The elogind daemon intercepts
the events before they get to the acp handler.
In 15.0 had to change the file /etc/elogind/logind.conf to ignore 'halt'
and 'suspend' events.

Hi Giovanni,

as I mentioned to John, I was hoping to avoid it waking up in the
first place, which I assume (*cough*) is because of some change in how
"hardware events" are handled.

I did change a couple of entries in /etc/elogind/logind.conf when I
initially installed 15.0, but that file hasn't been changed since well
before 5.15.27 was installed.

Jim

Jim Diamond

2022-04-07 00:00:03 UTC

Post by John Forkosh

Hi John,

thanks for the thoughts. I think that for acpi_handler.sh to do
anything, the laptop has to be "awake". So, by the time that
acpi_handler.sh is called, the thing I don't want to happen has
already happened.

I did contemplate handling the "wakeup" there by checking to see if
the lid is closed, and, if so, put the laptop back to sleep, but I was
hoping to prevent the wakeup in the first place.

Cheers.
Jim

Jim Diamond

2022-04-09 20:56:08 UTC

Just in case anyone cares, here is the "answer" (with thanks to Henrik
and Giovanni):

In 5.15.24 drivers/acpi/x86/s2idle.c has this code:

/*
* Some Intel based LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U don't
* use intel-hid or intel-vbtn but require the EC GPE to be enabled while
* suspended for certain wakeup devices to work, so mark it as wakeup-capable.
*
* Only enable on !AMD as enabling this universally causes problems for a number
* of AMD based systems.
*/
if (!acpi_s2idle_vendor_amd())
acpi_ec_mark_gpe_for_wake();

and in 5.15.25, notwithstanding the warning in the comment, it has
been changed to

/*
* Some LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U, require the
* EC GPE to be enabled while suspended for certain wakeup devices to
* work, so mark it as wakeup-capable.
*/
acpi_ec_mark_gpe_for_wake();

This causes the system to wake up on a variety of EC (embedded
controller) events, including opening the lid and unplugging or
plugging in the AC power. (Tested by re-compiling 5.15.25 with the
s2idle.c code from 5.15.24 and testing with that modified kernel.)

Jim

Henrik Carlqvist

2022-04-10 01:10:54 UTC

Post by Jim Diamond
/*
* Some Intel based LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U
don't * use intel-hid or intel-vbtn but require the EC GPE to be
enabled while * suspended for certain wakeup devices to work, so
mark it as wakeup-capable. *
* Only enable on !AMD as enabling this universally causes problems
for a number * of AMD based systems.
*/
if (!acpi_s2idle_vendor_amd())
acpi_ec_mark_gpe_for_wake();
and in 5.15.25, notwithstanding the warning in the comment, it has been
changed to
/*
* Some LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U, require
the * EC GPE to be enabled while suspended for certain wakeup
devices to * work, so mark it as wakeup-capable.
*/
acpi_ec_mark_gpe_for_wake();
This causes the system to wake up on a variety of EC (embedded
controller) events, including opening the lid and unplugging or plugging
in the AC power. (Tested by re-compiling 5.15.25 with the s2idle.c code
from 5.15.24 and testing with that modified kernel.)
Jim

Nice work! So who made this change and why? Some digging with git gives:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
git checkout v5.15.25
cd drivers/acpi/x86/
git diff v5.15.24 s2idle.c

The above command shows that the only difference between 5.15.25 and
5.15.24 in s2idle.c are those lines that you have identified. So if you
prefer the behavior of 5.15.24 you can safely use that file as you did.

git blame s2idle.c

Shows that the change was made by Mario Limonciello who has an email
address indicating that he is working at AMD. The commit was
0044583276952 and it was made 2022-01-28.

git log s2idle.c

Gives a rather long explanation to why the AMD check was removed.

The information retreived by these git command lines could also be
retrieved by pointing and clicking in "gitk --all".

So your next step will probably be to consider wether your local fix is
good enough for now or if you want to discuss this with Mario to also get
it fixed in a better way in future releases.

regards Henrik

Jim Diamond

2022-04-10 23:32:05 UTC