Laptop lid ignored suspend when externally powered despite Xfce power settings

Hi.

I’ve been trying to make my laptop enter suspend mode even when the external power supply is plugged in — FTR it’s a Tuxedo InfinityBook Pro 15. It doesn’t. Instead the display is just blanked and the battery is drained overnight. So far I have to open the action menu and select “Suspend” manually for suspend to work and I don’t like that at all.

So I thought I had made a mistake and double checked Xfce power settings and they were exactly like I wanted: lid close shall suspend, both if on battery and if on mains. I then edited /etc/systemd/logind.conf to change these parameters as follows:

# These settings were initially commented out
HandleLidSwitch=suspend
HandleLidSwitchExternalPower=suspend

That didn’t change anything.

So since Xfce power manager doesn’t seem to do what it’s told, I then deduced it had to be overridden so I changed /etc/Upower/Upower.conf as follows:

IgnoreLid=true    # It was initially commented out

And as expected, no more lid action in Xfce power manager.

Except now nothing ever happens! Contrary to what I understood from reading the documentation, the exact opposite to what I want happens. I rebooted, twice, same thing. Now I’m lost. So, change of plans:

  • How do I tell my minion, when I close the damn lid, to suspend no matter what, should I run a desktop environment or not, should I be logged in or not, should I be on a text console (tty) or not? I want it to suspend when I close the lid. Period. Not hibernate. Only suspend and nothing else. How do I achieve that?

Thanks in advance for any hint or suggestion.

Sounds like no S3 is involved, but S0 suspend (so-called modern standby). Of course it puts everything into power save mode, but still drains battery, just like a smartphone and sometimes it doesn’t work good.

systemctl suspend
# after wake up (or unblank) check  the journal:
journalctl --boot 0 | sed -n -r "/Starting.+Suspend/,/Finished.+Suspend/p"
# and
cat /sys/power/mem_sleep       

Here you go:

cat /sys/power/mem_sleep
[s2idle]
journalctl --boot 0 | sed -n -r "/Starting.+Suspend/,/Finished.+Suspend/p"

shows nothing. But I haven’t put my laptop to sleep today. I’ll reboot (software updates just hit) and be back…

I rebooted, put the laptop to sleep (using the action button), closed and opened the lid and ran the command again:

oct 03 19:40:58 machine systemd[1]: Starting System Suspend...
oct 03 19:40:58 machine wpa_supplicant[768]: p2p-dev-wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
oct 03 19:40:58 machine wpa_supplicant[768]: p2p-dev-wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
oct 03 19:40:58 machine wpa_supplicant[768]: nl80211: deinit ifname=p2p-dev-wlp3s0 disabled_11b_rates=0
oct 03 19:40:58 machine systemd-sleep[2475]: Successfully froze unit 'user.slice'.
oct 03 19:40:58 machine systemd-sleep[2475]: Performing sleep operation 'suspend'...
oct 03 19:40:58 machine kernel: PM: suspend entry (s2idle)
oct 03 19:41:06 machine kernel: Filesystems sync: 0.035 seconds
oct 03 19:41:06 machine kernel: Freezing user space processes
oct 03 19:41:06 machine kernel: Freezing user space processes completed (elapsed 0.032 seconds)
oct 03 19:41:06 machine kernel: OOM killer disabled.
oct 03 19:41:06 machine kernel: Freezing remaining freezable tasks
oct 03 19:41:06 machine kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
oct 03 19:41:06 machine kernel: printk: Suspending console(s) (use no_console_suspend to debug)
oct 03 19:41:06 machine kernel: fxpm, fxgmac_suspend callin
oct 03 19:41:06 machine kernel: fxpm,_fxgmac_shutdown, callin
oct 03 19:41:06 machine kernel: fxgmac_net_powerdown callin here.
oct 03 19:41:06 machine kernel: fxgmac_net_powerdown continue with down process.
oct 03 19:41:06 machine kernel: fxgmac_free_irqs, MSIx irq_tx clear done, ch=0
oct 03 19:41:06 machine kernel: fxgmac_free_irqs, MSIx rx irq clear done, total=4
oct 03 19:41:06 machine kernel: napi_disable, msix ch0 napi disabled done,del=1
oct 03 19:41:06 machine kernel: napi_disable, msix ch1 napi disabled done,del=1
oct 03 19:41:06 machine kernel: napi_disable, msix ch2 napi disabled done,del=1
oct 03 19:41:06 machine kernel: napi_disable, msix ch3 napi disabled done,del=1
oct 03 19:41:06 machine kernel: fxgmac_config_powerdown, phy and mac status update
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x0000a00c
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x00000000
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x0000a00d
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x00000000
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x0000a00e
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x00000000
oct 03 19:41:06 machine kernel: config_wol callout
oct 03 19:41:06 machine kernel: fxgmac_update_aoe_ipv4addr, Get net device binary IP ok, 0xca01a8c0
oct 03 19:41:06 machine kernel: fxgmac_update_aoe_ipv4addr, update arp ipaddr reg from 0x00000000 to 0xca01a8c0
oct 03 19:41:06 machine kernel: fxgmac_get_netdev_ip6addr FXGMAC_NS_IFA_GLOBAL_UNICAST is set, 2
oct 03 19:41:06 machine kernel: fxgmac_get_netdev_ip6addr get ipv6 addr failed, use default.
oct 03 19:41:06 machine kernel: fxgmac_update_ns_offload_ipv6addr, get net device ipv6 addr with err and ignore NS offload.
oct 03 19:41:06 machine kernel: fxgmac_get_netdev_ip6addr FXGMAC_NS_IFA_LOCAL_LINK is set, 1
oct 03 19:41:06 machine kernel: fxgmac_get_netdev_ip6addr get ipv6 addr failed, use default.
oct 03 19:41:06 machine kernel: fxgmac_update_ns_offload_ipv6addr, get net device ipv6 addr with err and ignore NS offload.
oct 03 19:41:06 machine kernel: fxgmac_config_powerdown callout, reg=0x0000800f
oct 03 19:41:06 machine kernel: fxgmac_net_powerdown callout, powerstate=1.
oct 03 19:41:06 machine kernel: fxpm,_fxgmac_shutdown, save pci state done.
oct 03 19:41:06 machine kernel: fxpm,_fxgmac_shutdown callout, enable wake=1.
oct 03 19:41:06 machine kernel: fxpm, fxgmac_suspend callout to sleep
oct 03 19:41:06 machine kernel: pcieport 0000:00:08.3: quirk: disabling D3cold for suspend
oct 03 19:41:06 machine kernel: ACPI: EC: interrupt blocked
oct 03 19:41:06 machine kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ACDC.RTAC], AE_NOT_FOUND (20230628/psargs-330)
oct 03 19:41:06 machine kernel: ACPI Error: Aborting method \_SB.PEP._DSM due to previous error (AE_NOT_FOUND) (20230628/psparse-529)
oct 03 19:41:06 machine kernel: ACPI: EC: interrupt unblocked
oct 03 19:41:06 machine kernel: fxpm, fxgmac_resume callin
oct 03 19:41:06 machine kernel: fxgmac_net_powerup callin
oct 03 19:41:06 machine kernel: fxgmac start callin here.
oct 03 19:41:06 machine kernel: CHIP_RESET 0x80000001
oct 03 19:41:06 machine kernel: [drm] PCIE GART of 512M enabled (table at 0x000000801FD00000).
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: SMU is resuming...
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: SMU is resumed successfully!
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 16 ok, ctrl=0x08100204, data=0x0000006a
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x00000052
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x0000231d
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x00000051
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x000004a9
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x00000057
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x0000264c
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x0000a00c
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x00002600
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x0000a00d
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x00001800
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x0000a00e
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x00000000
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 30 ok, ctrl=0x081e0204, data=0x00000027
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 31 ok, ctrl=0x081f0204, data=0x0000a812
oct 03 19:41:06 machine kernel: fxgmac_dismiss_all_int callin
oct 03 19:41:06 machine kernel: fxgmac hw init call in
oct 03 19:41:06 machine kernel: fxgmac_flush_tx_queues, reg=0x00000000897f8334, val=0x001f0009
oct 03 19:41:06 machine kernel: fxgmac_flush_tx_queues wait... reg=0x00000000897f8334, val=0x00000000
oct 03 19:41:06 machine kernel: enable_rss callout, rss ctrl reg=0x80001807
oct 03 19:41:06 machine kernel: yt6801 0000:02:00.0 enp2s0: 1 Tx hardware queues, 8192 byte fifo per queue
oct 03 19:41:06 machine kernel: yt6801 0000:02:00.0 enp2s0: 4 Rx hardware queues, 8192 byte fifo per queue
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 4 ok, ctrl=0x08040204, data=0x00001de1
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 0 ok, ctrl=0x08000204, data=0x00009140
oct 03 19:41:06 machine kernel: fxgmac enable rx checksum.
oct 03 19:41:06 machine kernel: fxgmac_update_vlan_hash_tabl done,hash tbl=00000000.
oct 03 19:41:06 machine kernel: fxgmac enable MAC rx vlan stripping.
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 18 ok, ctrl=0x08120204, data=0x00000c00
oct 03 19:41:06 machine kernel: fxgmac hw init callout
oct 03 19:41:06 machine kernel: napi_enable, msix ch0 napi enabled done,add=1
oct 03 19:41:06 machine kernel: napi_enable, msix ch1 napi enabled done,add=1
oct 03 19:41:06 machine kernel: napi_enable, msix ch2 napi enabled done,add=1
oct 03 19:41:06 machine kernel: napi_enable, msix ch3 napi enabled done,add=1
oct 03 19:41:06 machine kernel: fxgmac_req_irqs, MSIx irq_tx request ok, ch=0, irq=74,enp2s0-ch0-Tx-0
oct 03 19:41:06 machine kernel: fxgmac_req_irqs, MSIx irq request ok, total=4,67~73
oct 03 19:41:06 machine kernel: fxgmac_write_ephy_reg id 18 ok, ctrl=0x08120204, data=0x00000c00
oct 03 19:41:06 machine kernel: fxgmac_net_powerup callout, powerstate=2.
oct 03 19:41:06 machine kernel: fxpm, fxgmac_resume callout
oct 03 19:41:06 machine kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully.
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1 on hub 8
oct 03 19:41:06 machine kernel: amdgpu 0000:65:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 13 on hub 0
oct 03 19:41:06 machine kernel: [drm] ring gfx_32778.1.1 was added
oct 03 19:41:06 machine kernel: [drm] ring compute_32778.2.2 was added
oct 03 19:41:06 machine kernel: [drm] ring sdma_32778.3.3 was added
oct 03 19:41:06 machine kernel: [drm] ring gfx_32778.1.1 ib test pass
oct 03 19:41:06 machine kernel: [drm] ring compute_32778.2.2 ib test pass
oct 03 19:41:06 machine kernel: [drm] ring sdma_32778.3.3 ib test pass
oct 03 19:41:06 machine kernel: OOM killer enabled.
oct 03 19:41:06 machine kernel: Restarting tasks ... done.
oct 03 19:41:06 machine kernel: random: crng reseeded on system resumption
oct 03 19:41:06 machine wpa_supplicant[768]: wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
oct 03 19:41:06 machine systemd-sleep[2475]: System returned from sleep operation 'suspend'.
oct 03 19:41:06 machine systemd-sleep[2475]: Successfully thawed unit 'user.slice'.
oct 03 19:41:06 machine systemd[1]: systemd-suspend.service: Deactivated successfully.
oct 03 19:41:06 machine kernel: PM: suspend exit
oct 03 19:41:06 machine wpa_supplicant[768]: wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
oct 03 19:41:06 machine wpa_supplicant[768]: nl80211: deinit ifname=wlp3s0 disabled_11b_rates=0
oct 03 19:41:06 machine systemd[1]: Finished System Suspend.

And I also get the same results after running systemctl suspend.

Is it a good sign? (I guess yes, it is…)

Sure, s2idle is the “modern standby”. In terms of this method, it works, but is not particularly energy-saving. It is a pure software mode and not firmware-supported, as with S3 (Deep). For example:

This is worth looking at. A PCIe device, probably the GPU oder NVME is still running normally.

and also these Bugs here… Is there probably a Firmware Update available?

So what you call:

is actually what it should do. Just like a smartphone, it “blanks” to suspend and you can instantly wake it up. But that doesn’t turn off anything.

Your system only support 1 mode, s2idle. If there were 2-3 modes we could have tried to change it, but now you do not have a choice. It is working as expected in this stupid mode. Many modern laptops indeed do not support the good old deep sleep anymore. We can thank microsoft for that, they actively pushed for this new type of sleep to become mass adopted.

You can try to update the uefi and see if another mode comes up, some uefis also have secret menus to enable the s3 mode.

Or you can configure it to hibernate instead of suspend.

Or you can play with TLP and TLP-UI to see if you manage to make some rules and turn off some additional parts of the hardware in suspend/idle, to make it a bit more efficient, but do not hope for much.

1 Like

Hi, I’m doing https://fostips.com/lid-close-action-ubuntu-21-04-laptop/ like this, everything is fine

That is interesting. Fact I ordered the laptop but without the default NVMe drive. Instead I ordered it with no drive and recycled the NVMe disk that was present in a Slimbook computer (which is also advertised to be 100% Linux compatible). Could that be a reason other sleep modes are disabled?

I see. I preferred suspend to avoid stressing the NVMe drive as I happen to be using it every single day. There are 16GB to shove into swap (compressed, I know but still a lot to my eyes).

No idea what that is :sweat_smile:

The laptop is fairly new (first sold after end of august this year). I’ll check if there’s a new firmware available but I doubt there is. Although, cost nothing to check…

Tlp is the default power management service. Tlp-ui is a nice gui program for the otherwise veeery exhaustive config files. I have not played with the standby though.
A middlegrade ssd should have about 70 TB write capacity. A 16GB every day +the normal usage might be a bit too much indeed if you want it to last more than 3-4 years.

1 Like

This sounds like a serious design flaw in these Intel chipsets. (I know be avoiding these chipsets as long as I possibly can!)

So I do not have any devices with that chipset to test, but I do have some XFCE installations around. This may not fix your problem, but it may help in your troubleshooting.

So you have to choose to use either systemd or xfce to manage power. If you want to just use systemd, you will need to run this, at least for lid actions:

xfconf-query --create --channel xfce4-power-manager --property /xfce4-power-manager/logind-handle-lid-switch --type bool --set 'true'

# Changes should be instant and you can test, then the following will revert the above change

xfconf-query --channel xfce4-power-manager --property /xfce4-power-manager/logind-handle-lid-switch --type bool --set 'false'
1 Like

No. In newer laptops S3 suspend called deep in linux is just not implemented. It saves money for the manufacture, since they don’t have to deal with the firmware for suspend anymore, but it is not that energy savvy.

On the PCIe device there is a “quirk” mentioned. That means this device has problems with powering off, therefore it is disabling a shutdown of that hardware. But it doesn’t prevent the suspend process at all, it just runs normally.

A s2idle suspend needs all hardware to be compatible and the linux kernel needs proper drivers which set all hardware to the lowest possible power save state. If it is not able to do so, then it will not save power. This type of suspend doesn’t shutdown hardware.

2 Likes

I am still not sure what this topic is about:

  • Is there a problem with lid switch detection
  • Or is there a problem with the machine going to sleep generally
  • Or are we all just sour because the oems do not support deep sleep anymore

I think it’s the third, because the OP told us something happens when lid is closed, and with manuall issuing a sleep command it “sleeps”, so i think everything works as expected and only an explanation was due.
As for “draining overnight”, well mine drains over 5 hours in that mode…which is pretty much the battery life if i am lightly using it. As said, that mode does not really save much, and nowadays the lcd screen isn’t the biggest consumer.

1 Like

It’s actually an AMD Ryzen 7 8845HS because I precisely wanted to avoid Intel :frowning: . Guess we’re fooled anyway.

I won’t. Because neither do exactly what they’re supposed to do. Example: suspend only works when I unplug the power cord. Even with settings in the current form, which I’ve shared earlier. It’s hopeless IMHO.

I’ve come to despise the computer industry for these exact same reasons. I remember the nineties when you had total control over your computer. Now only a bunch of m°r°ns have the power to decide what you will do. They use it and abuse it. I’m desperately sick of this.

Know what? I’ll give up suspend and use poweroff instead. I’ll convince myself I don’t need that sh… It’s more straightforward than fixing this mess.

Thanks all of you for your hindsight. You’ve been of great help so I could understand what’s going on.

I do the same, the laptop with manjaro and ssd boots to desktop in less than 20 seconds and shuts down in maybe 5, so it is not big deal.

1 Like

Power management with suspend for current hardware - TUXEDO Computers

Modern Standby

Intel and AMD have been supporting the new Modern Standby (MS) standard developed by Microsoft, which is gradually replacing suspend-to-RAM,for some years now. MS uses a step-by-step process to maintain the battery’s state of charge as far as possible. Components are switched off when they are not in use.

Unfortunately, this mode still has some issues. Some users report that the battery is draining heavily in idle mode or that there are problems waking up the components. These problems affect Windows, macOS and Linux. However, the sleep behaviour of S0ix is improved under Linux with every kernel update.

Intel and AMD no longer officially support S3 deep since Intel Gen 11 and Ryzen 6000. Although Intel still supports S3 in some current CPUs, it cannot be guaranteed that S3 will function properly. For the Intel P- and U-processors of the 12th and 13th generation used in many modern notebooks, S3 is no longer supported. However, the S- and H-processors still support S3.

You can verify this on your device by entering cat /sys/power/mem_sleep. If deep is displayed in square brackets, your CPU is using S3 mode. It is not known how long this will be the case.

Unfortunately, this does not guarantee that S3 will work satisfactorily. The mainboard manufacturers have the final say here, as not all components such as WiFi modules or NVME/SSDs support S3 equally well. Anything that is not standard after installation is untested and cannot be supported by us.

3 Likes

This is informative. And unfortunate…

EDIT: Just noticing how, again, Microsoft tries to shove their name into everything they touch. This is beyond pathetic. If they do the same mess as when they forced the “”““standardizing””“” their office format, well, we’re going to be in a deep mess. And maybe deeper than anticipated.

Modern Standby (MS) standard developed by Microsoft

:facepalm:

They ought to watch it, or the laptops and notebooks with this “technology” might need energy efficiency ratings (and possibly extra tariffs, at least in the EU) applied. Plus extra WEEE costs for all the extra replacement batteries needed.

Here’s some update.

After some time I noticed the battery didn’t charge anymore. Opening the laptop I saw the battery was swollen.

I’ve talked with Tuxedo support and they explained my (charging) issues could be due to the battery being faulty — I ranted about that but sent them my laptop eventually. Now that I have it back, leaving in “Modern Suspend” mode overnight seems to take about 5% of the total charge. I’ll keep on watching, of course but so far a bad Lithium battery may be the root cause.

I also have to add that I configured Tuxedo Control Center charging profile for maximum battery lifespan, which involves slow charging speed and reduced maximum capacity (about 80% of the total). That profile is called “Stationary use” for what it’s worth. It is the recommended setting when the laptop is mostly connected to the power supply unit.

The suspend-on-lid-close is irrelevant of course. My DIY procedure is to unplug the power and run systemctl suspend so far. I’ll see if that improves along with system updates as Tuxedo support also told me they were actively working on fixing issues provided they are reported to them, obviously.