AHCI controller missing after resume from suspend, remount fails

qqspaniard · 2024-06-25 02:30:55

On:
- HP ENVY x360 Convertible 13-ay0xxx
- 6.9.6-arch1-1

When resuming from sleep, AHCI controller fails. /dev/sda3 fails to mount, and journalctl fails to log.
When I run dmesg -w prior to suspend, on resume I see the following

i2c_hid_acpi i2c-ELAN2514:00: failed to change power setting
i2c_hid_acpi i2c-ELAN2514:00: dpm_run_callback(): acpi_subsys_resume+0x0/0x80 returns -121
...
ahci 0000:04:00.0: PM: Controller reset failed (0xffffffff)
ahci 0000:04:00.0: PM: dpm_run_callback(): pci_pm_resume+0x0/0xf0 returns -5

When I terminate dmesg, the terminal continues to run, but I can only use bash's built-in commands. Everything in /usr/bin is inaccessible, giving "Input/Output Error"

FWIW, I would like to append the complete dmesg output, but it's quite difficult to manually transcribe the terminal output to another machine.

EDIT 1:
I learned how to downgrade kernel revisions, and found that kernel v6.5.0 works, whereas kernel v6.5.1 does not. I'm not sure where I can find the changes between the versions to debug further...

I would really appreciate any help to debug.

Last edited by qqspaniard (2024-06-25 02:34:22)

cryptearth · 2024-06-25 05:07:38

do you really mean 6.5.0 as last working kernel? as this is quite some time ago and current lts is 6.6 or so
anyway: recently there were some changes made to the base ahci driver - also along some power management stuff
as I also suffered from a recent change and got it reverted I noticed that many changes in the past commits were introduced for some good reason but without much testing and hence cause quite some weired issues all over the place
I don't want to "blame" anybody as thier intentions are towards the greater good - but changes to such fundamental base drivers should undergo quite a lot of testing before pushed to mainline upstream

qqspaniard · 2024-06-25 18:00:07

I haven't tested every version between 6.5 and 6.9.6, I may try to do that today

gromit · 2024-06-25 18:14:27

I think if you have an issue with 6.9.X it makes sense to first check if the 6.8 release is working i.e. by installing it via the archive:

sudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.8.arch1-1-x86_64.pkg.tar.zst

You can also try the latest mainline candidate to see if its already fixed upstream:

sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.10rc5-1-x86_64.pkg.tar.zst

If you find an old version working and its not yet fixed in mainline its a regression and we can debug it together

qqspaniard · 2024-06-28 23:46:26

I think I've identified my problem...
https://wiki.archlinux.org/title/Ryzen# … nd_suspend

My UEFI doesn't allow modification to any of the ahci bits, but

 processor.max_cstate=1

fixed the problem. Anyone know why its a "less ideal solution"?

Last edited by qqspaniard (2024-06-29 18:48:52)

seth · 2024-06-29 07:41:14

Your CPU cannot power down and will suck up a lot of battery
Also some idiots are probably gonna spray-paint the Alhambra when they learn abotu that, so try whether you get away with https://wiki.archlinux.org/title/Intel_ … up_from_S3

qqspaniard · 2024-06-29 19:06:20

Thanks for the reply Seth,

I read through the linked wiki (and the links from there as well), and came up with these systemd scripts:

$ cat /etc/systemd/system/root-suspend.service

[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=cpupower idle-set -E

[Install]
WantedBy=sleep.target

$ cat /etc/systemd/system/root-resume.service

[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=cpupower set-idle -D0

[Install]
WantedBy=suspend.target

With these started, and processor.max_cstate=1 removed, I'm back to square 1. Any ideas?

seth · 2024-06-29 20:27:23

I'd personally prefer to just use https://wiki.archlinux.org/title/Power_ … stem-sleep to avoid service handling, but more importantly, you're supposed to disable the c-states before the sleep and enable them afterwards.

qqspaniard · 2024-06-29 21:55:10

Oooh thanks for that tip.
If I'm disabling c-states with cpupower, how does this solution suffer from the kernel-option solution?

seth · 2024-06-29 21:58:22

The plan is to only disable them around the S3, so for a couple of seconds it's like you had the parameter set, but most of the time your allow the CPU to power down.

qqspaniard · 2024-07-01 03:09:16

Ok, so, I've created this file

at /usr/lib/systemd/system-sleep/set-cstates.sh

#!/bin/sh
case $1/$2 in
        pre/*)
                echo "Enabling C-States"
                cpupower idle-set -E
                ;;
        post/*)
                echo "Disabling C-States"
                cpupower set-idle -D0
esac

With the kernel-option solution still enabled, this seems to work. Without the option, this does not work.

In journalctl, I see the echo messages before and after suspend.
Is there any way to determine whether or not the correct c-states have been entered?

seth · 2024-07-01 06:46:55

seth wrote:

The plan is to only disable them around the S3

qqspaniard · 2024-07-01 18:55:51

:facepalm:
Yes, of course, thank you.

This now "works" (suspend/resume), but I find that the battery life is still draining >10%/hour in when suspended. My understanding is that the c-states are disabled pre-suspend, and are being re-enabled after resume. This will still result in c-state 0 during suspend -> cpu power drain. Am I supposed to be re-enabling c-states before the suspend completes?

Last edited by qqspaniard (2024-07-01 18:56:11)

seth · 2024-07-01 21:00:00

Am I supposed to be re-enabling c-states before the suspend completes?

No, that's hardly possible.

Do you s3 or s2idle?
On S3, the c-states should have asolutely no impact, but on s2idle they most likely will (because the CPU cannot shut down, you're effectively not idling)

 cat /sys/power/mem_sleep

qqspaniard · 2024-07-01 22:28:35

Looks like

 [s2idle]

On another machine (also arch), I see

 [s2idle] deep

Should I switch one or both of these to s3?
I don't have any power issues on the machine running "deep"...

Last edited by qqspaniard (2024-07-01 22:28:48)

seth · 2024-07-01 22:35:07

You're running s2idle on both, "deep" is the same as S3, but apparently no option on the problematc system.
processor.max_cstate=1 causes the same power drain during s2idle?

qqspaniard · 2024-07-01 22:49:55

Correct. It seems as though entering the sleep state works just fine, but that the power drain in both solutions is quite bad.

I've found this blog post to attempt to re-enable S3 sleep:
https://blog.wyraz.de/linux/enabling-s3 … n-aero-13/

but I also see in these threads that s2idle should be supported now?
https://bbs.archlinux.org/viewtopic.php?id=256365&p=2

Last edited by qqspaniard (2024-07-01 22:57:46)

d.ALT · 2024-07-02 07:27:26

Do you have any (maybe hidden) options in uEFI related to something like VMD Controller?

qqspaniard · 2024-07-02 17:20:20

The only thing I can see that would maybe be relevant is the "Adaptive battery optimizer". (Note this is a ryzen device)

(Apologies for the lack of an external vid-cap card)
https://ibb.co/album/G3fnBq

Last edited by qqspaniard (2024-07-02 17:21:54)

seth · 2024-07-02 20:22:28

https://h30434.www3.hp.com/t5/Notebook- … ue#M614837
No idea whether that works

qqspaniard · 2024-07-06 19:52:37

No dice. Seems like HP doesn't want me to tinker with the bios...

Why is it that Ryzen x Linux doesn't play well with s2idle?

seth · 2024-07-07 06:34:50

It's not only ryzen, see the liked intel wiki.
Have you tried to add "ahci.mobile_lpm_policy=1" the kernel parameters instead of limiting the c-state?

qqspaniard · 2024-07-08 16:57:47

With

 ahci.mobile_lpm_policy=1

The machine successfully enters suspend mode, but never recovers. AFAICT no input triggers a resume from sleep

seth · 2024-07-08 21:12:02

Can you sleep/wake with rtcwake?

sudo rtcwake -m mem --date +1minute

Arch Linux

#1 2024-06-25 02:30:55

AHCI controller missing after resume from suspend, remount fails

#2 2024-06-25 05:07:38

Re: AHCI controller missing after resume from suspend, remount fails

#3 2024-06-25 18:00:07

Re: AHCI controller missing after resume from suspend, remount fails

#4 2024-06-25 18:14:27

Re: AHCI controller missing after resume from suspend, remount fails

#5 2024-06-28 23:46:26

Re: AHCI controller missing after resume from suspend, remount fails

#6 2024-06-29 07:41:14

Re: AHCI controller missing after resume from suspend, remount fails

#7 2024-06-29 19:06:20

Re: AHCI controller missing after resume from suspend, remount fails

#8 2024-06-29 20:27:23

Re: AHCI controller missing after resume from suspend, remount fails

#9 2024-06-29 21:55:10

Re: AHCI controller missing after resume from suspend, remount fails

#10 2024-06-29 21:58:22

Re: AHCI controller missing after resume from suspend, remount fails

#11 2024-07-01 03:09:16

Re: AHCI controller missing after resume from suspend, remount fails

#12 2024-07-01 06:46:55

Re: AHCI controller missing after resume from suspend, remount fails

#13 2024-07-01 18:55:51

Re: AHCI controller missing after resume from suspend, remount fails

#14 2024-07-01 21:00:00

Re: AHCI controller missing after resume from suspend, remount fails

#15 2024-07-01 22:28:35

Re: AHCI controller missing after resume from suspend, remount fails

#16 2024-07-01 22:35:07

Re: AHCI controller missing after resume from suspend, remount fails

#17 2024-07-01 22:49:55

Re: AHCI controller missing after resume from suspend, remount fails

#18 2024-07-02 07:27:26

Re: AHCI controller missing after resume from suspend, remount fails

#19 2024-07-02 17:20:20

Re: AHCI controller missing after resume from suspend, remount fails

#20 2024-07-02 20:22:28

Re: AHCI controller missing after resume from suspend, remount fails

#21 2024-07-06 19:52:37

Re: AHCI controller missing after resume from suspend, remount fails

#22 2024-07-07 06:34:50

Re: AHCI controller missing after resume from suspend, remount fails

#23 2024-07-08 16:57:47

Re: AHCI controller missing after resume from suspend, remount fails

#24 2024-07-08 21:12:02

Re: AHCI controller missing after resume from suspend, remount fails

Board footer