Requests for current-next (15.0-->15.1)

glennmcc · 04-14-2024, 02:49 PM

OH come-on... that was not a "horror".

It was "FUN"

OK, I'll shut my trap now.

Markus Wiesner · 04-14-2024, 04:04 PM

Quote:

Sat Apr 13 19:45:25 UTC 2024
l/imagemagick-7.1.1_29-x86_64-1.txz: Upgraded.
Revert to the previous ImageMagick because the latest one is destroying SVG
files if "identify" or "display" is used on them.
Thanks to pc2005.

See https://www.linuxquestions.org/quest...5/#post6495803

We should revert this revert because the error is in 7.1.1_29 and not 7.1.1_30. It only affected 7.1.1_30 because delegates.xml was not replaced by the .new one.

LuckyCyborg · 04-15-2024, 02:56 AM

Regarding the latest elogind issues with the system sleeping and gracious tucking the tail between legs while running on previous version, well... everybody please be kind to note that in fact elogind do what it's instructed to do: preferring to using the s2idle (aka freeze) for sleeping the system.

If you wonder what the heck is that s2idle ... Well, according with the kernel.org's guys:

https://www.kernel.org/doc/Documenta...wer/states.txt

Code:

State:		Suspend-To-Idle
ACPI state:	S0
Label:		"s2idle" ("freeze")

This state is a generic, pure software, light-weight, system sleep state.
It allows more energy to be saved relative to runtime idle by freezing user
space and putting all I/O devices into low-power states (possibly
lower-power than available at run time), such that the processors can
spend more time in their idle states.

This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
support, or it can be used in addition to Suspend-to-RAM to provide reduced
resume latency.  It is always supported.

This rings some bells to the guys who hit issues with the elogind and sleeping?

That's right, the "s2iddle" power down the drives and put the CPU and processes on idle, but still keeps the system powered on - just what you guys encountered in the last time.

To return to the old elogind's behavior, one should change as following the config file: /etc/elogind/sleep.conf.d/10-elogind.conf

Code:

--- 10-elogind.conf.orig	2024-03-01 09:44:12.000000000 +0200
+++ 10-elogind.conf	2024-04-15 10:36:56.909970247 +0300
@@ -19,4 +19,4 @@
 #HandleNvidiaSleep=no
 #HibernateByUsing=
 #SuspendByUsing=
-#SuspendMode=s2idle deep
+SuspendMode=deep

Then after rebooting the system, you will see The Magic: the "loginctl suspend" command will work as you expected.

PS. If you wonder WHY that that s2idle fails miserably on waking up the system, well... I believe that's another story - who knows? Maybe BOB wanted us to notice the sorry state of this particular feature in Slackware, even it's "a generic, pure software, light-weight, system sleep state."

marav · 04-15-2024, 03:48 AM

Quote:

Originally Posted by LuckyCyborg

To return to the old elogind's behavior, one should change as following the config file: /etc/elogind/sleep.conf.d/10-elogind.conf

Code:

--- 10-elogind.conf.orig	2024-03-01 09:44:12.000000000 +0200
+++ 10-elogind.conf	2024-04-15 10:36:56.909970247 +0300
@@ -19,4 +19,4 @@
 #HandleNvidiaSleep=no
 #HibernateByUsing=
 #SuspendByUsing=
-#SuspendMode=s2idle deep
+SuspendMode=deep

Then after rebooting the system, you will see The Magic: the "loginctl suspend" command will work as you expected.

Before activating this elogind suspend mode
You have to ensure that your system supports this "Suspend to disk" feature, aka "Hibernate", aka "S4 ACPI sleeping state"

To do so:

Code:

# dmesg | grep -E 'ACPI.*supports'

It should return something like this:

Code:

# dmesg | grep -E 'ACPI.*supports'
[    0.407141] ACPI: PM: (supports S0 S3 S4 S5)

Side note:
It can also be activated by adding this to your kernel cmd line

Code:

mem_sleep_default=deep

To check if it works:

Code:

# cat /sys/power/mem_sleep 
s2idle [deep]

LuckyCyborg · 04-15-2024, 03:54 AM

Quote:

Originally Posted by marav

Before activating this elogind suspend mode
You have to ensure that your system supports this "Suspend to disk" feature, aka "Hibernate", aka "S4 ACPI sleeping state"

To do so:

Code:

# dmesg | grep -E 'ACPI.*supports'

It should return something like this:

Code:

# dmesg | grep -E 'ACPI.*supports'
[    0.407141] ACPI: PM: (supports S0 S3 S4 S5)

Yes, you are right.

BUT, in the elogindish (, just like in systemdish), this "Suspend to disk" feature is called "Hibernate" , while the "Suspend" itself is what usually we call "Suspend to RAM" .

Anyway, from my tests the hibernation itself worked OK with this latest version of elogind, the issues was with suspending to RAM, which in fact ended by default being a "freezing" via the configuration preferred s2idle feature.

ZhaoLin1457 · 04-15-2024, 03:59 AM

Quote:

Originally Posted by marav

Side note:
It can also be activated by adding this to your kernel cmd line

Code:

mem_sleep_default=deep

To check if it works:

Code:

# cat /sys/power/mem_sleep 
s2idle [deep]

So is it ultimately a kernel configuration issue?

LuckyCyborg · 04-15-2024, 04:03 AM

Quote:

Originally Posted by ZhaoLin1457

So is it ultimately a kernel configuration issue?

I do not think so.

Because, after all:

Code:

root@darkstar:~# uname -a
Linux darkstar.example.org 6.6.27 #1 SMP PREEMPT_DYNAMIC Sat Apr 13 13:28:46 CDT 2024 x86_64 Intel(R) Core(TM) i5-3570T CPU @ 2.30GHz GenuineIntel GNU/Linux
root@darkstar:~# 
root@darkstar:~# cat /sys/power/mem_sleep
s2idle [deep]
root@darkstar:~#

That's just like in the Slackware 15.0 kernels.

The issue seems to me that elogind is instructed by it's (default?) configuration to prefer the s2idle instead of deep.

marav · 04-15-2024, 04:08 AM

Quote:

Originally Posted by ZhaoLin1457

So is it ultimately a kernel configuration issue?

I don't think so
As the kernel guys said:

Code:

This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
support, or it can be used in addition to Suspend-to-RAM to provide reduced
resume latency.  It is always supported.

Here, for example, my laptop doesn't support S4 ACPI sleep state out of the box, I have to tweak the ACPI table
This has always worked in the past, so I'm convinced it's probably an elogind issue

kgha · 04-15-2024, 04:21 AM

Can't see how LuckyCyborgs post #4218 relates to the problem that suspend/resume in elogind-255.4 breaks network connection and leaves NetworkManager unresponsive after resume? But maybe this is just me being ignorant.

GazL · 04-15-2024, 05:55 AM

Quote:

Originally Posted by ZhaoLin1457

A handful of ALSA purists can be hardly defined as "everyone" .

No, but by definition "everyone" is a superset of both them and everyone else.

Petri Kaukasoina · 04-15-2024, 06:04 AM

Quote:

Originally Posted by LuckyCyborg

Code:

root@darkstar:~# cat /sys/power/mem_sleep
s2idle [deep]
root@darkstar:~#

The issue seems to me that elogind is instructed by it's (default?) configuration to prefer the s2idle instead of deep.

But your cat tells deep is used. So, isn't that preferred by default?

marav · 04-15-2024, 06:16 AM

Quote:

Originally Posted by kgha

Can't see how LuckyCyborgs post #4218 relates to the problem that suspend/resume in elogind-255.4 breaks network connection and leaves NetworkManager unresponsive after resume? But maybe this is just me being ignorant.

With the last version of elogind, there is obviously 2 separate issues
One that breaks the functionality of the powerkey actions
The other that breaks the network connectivity after hibernate

I think he was talking about the first issue

For the second issue, no matter what you do, the only workaround, at least here, is to restart the NetworkManager

LuckyCyborg · 04-15-2024, 06:19 AM

Quote:

Originally Posted by Petri Kaukasoina

But your cat tells deep is used. So, isn't that preferred by default?

Nope. Unfortunately, looks like the elogind 255.4 prefers s2idle because seems to use this configuration option for its preferences:

Code:

SuspendMode=s2idle deep

Speaking of this config option, considering the point raised by @marav, probably the best is to use this:

Code:

--- 10-elogind.conf.orig	2024-03-01 09:44:12.000000000 +0200
+++ 10-elogind.conf	2024-04-15 13:09:53.606969523 +0300
@@ -19,4 +19,4 @@
 #HandleNvidiaSleep=no
 #HibernateByUsing=
 #SuspendByUsing=
-#SuspendMode=s2idle deep
+SuspendMode=deep s2idle

This way, if the "deep" mode is not available, elogind will fallback to "s2idle" .

BTW, someone else noticed that that new config file /etc/elogind/sleep.conf.d/10-elogind.conf has no .new handling, then it will be overridden on upgrading the elogind package?

marav · 04-15-2024, 06:37 AM

I for one, for now, I will stick with:
elogind 252.9 (254 obviously breaks the network after hibernate/resume)
polkit 123 (124 I think is the real culprit for the suspend-to-ram issue)

which work as it should

ZhaoLin1457 · 04-15-2024, 06:47 AM

Quote:

Originally Posted by marav

I for one, for now, I will stick with:
elogind 252.9 (254 obviously breaks the network after hibernate/resume)
polkit 123 (124 I think is the real culprit for the suspend-to-ram issue)

which work as it should

Let's remember that elogind is maintained by programmers affiliated with Gentoo and Devuan. And these programmers do not necessarily use SysV init like Slackware, on the contrary, they can very well use OpenRC or S6.

If we continue to use an old version of elogind, I think we run the risk of elogind becoming incompatible with Slackware and its SysV init.

And then what? Will we follow Devuan and adopt S6 or Gentoo and its OpenRC? I don't think that staying in an old version of elogind is an option, in my humble opinion.