Questions and answers from the Slimbook user community

¡Bienvenido al foro de la comunidad!

Si tienes problemas de software, este es tu sitio. Construyamos entre todos un lugar mejor, proporcionando experiencias, información de uso y tips. Si tienes alguna pregunta, procura dar información detallada sobre tu sistema.

Si tienes problemas de hardware, tramita la GARANTÍA AQUÍ, ya que nuestros técnicos no suelen revisar el foro por estar trabajando en reparaciones.

0

Slimbook Evo14 unable to wake up from sleep in recent linux kernels

Avatar
RJ

Hi,

I have a slimbook evo 14 that I bought about three months back. It's been working fine apart from occasional hiccups. Starting with kernel 6.18 (I observed this in 6.18.3 I believe), the laptop does not wake up from sleep when going to sleep with command `systemctl suspend`. I always have to do a hard poweroff. The issue isn't fixed with linux 6.19.6. Currently I have reverted back to using linux-lts 6.12.74 where suspend-wakeup works, but this is not sustainable. Has anyone else observed this issue and has been able to find a workaround? 

System: Arch linux with slimbook-meta-common slimbook-meta-evo slimbook-meta-plasma meta packages installed

DE: Plasma 6.6

Also tested with window manager hyprland, same result. 

Thanks,

Roshan


Evo 14
Avatar
Discard
9 Answers
0
Avatar
Samanta Sanchez Slimbook
Best Answer

Good morning, RJ
Have you tried any other ways for suspending the laptop? (eg, closing the lid, going into Plasma and suspend from there)

We have not gotten any incidences that newer kernels break suspending the device, but we will take a look into it
After suspending, does the laptop stay in breath mode (LED indicator fading in and out slowly), or does the laptop come out from suspending(so LED indicator fixed) but nothing shows on the screen?

Checking logs might also give away what is the issue after suspending the laptop (so dmesg, or journalctl)
You could check these and see if there's any errors or any RIPs in the kernel after waking up from suspending the device

Regards,

Avatar
Discard
0
Avatar
RJ
Best Answer

Hi Samanta,

The LED stays in "breath mode" after pressing the keyboard keys.I tested a few things:

1. Pressing the F1 key for sleep.

2. Pressing sleep on plasma.

3. Closing the lid

All result in the same issue - the pc doesn't wake. However, almost on accident, I happened to press the power button for short time when trying to do a force shutdown. This surprisingly seems to work and the pc wakes up.  I have following in the journalctl logs (reverse order, so most recent one on top)
Mar 06 10:24:20 electro kernel: GPIO 0 is active: 0x18057800
Mar 06 10:24:20 electro kernel: PM: noirq resume of devices complete after 172.292 msecs
Mar 06 10:24:20 electro kernel: PM: Triggering wakeup from IRQ 9
Mar 06 10:24:20 electro kernel: ACPI: EC: interrupt unblocked
Mar 06 10:24:20 electro kernel: ACPI: \_SB_.PEP_: Failed to transitioned to state screen on
Mar 06 10:24:20 electro kernel: ACPI Error: Aborting method \_SB.PEP._DSM due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
Mar 06 10:24:20 electro kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ACDC.RTAC], AE_NOT_FOUND (20250807/psargs-332)
Mar 06 10:24:20 electro kernel: ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms exit
Mar 06 10:24:20 electro kernel:    evmisc-0132 ev_queue_notify_reques: Dispatching Notify on [SDCR] (Device) Value 0x01 (Device Check) Node 0000000041628360
Mar 06 10:24:20 electro kernel: ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 exit
Mar 06 10:24:20 electro kernel: amd_pmc AMDI000A:00: Last suspend didn't reach deepest state
Mar 06 10:24:20 electro kernel: PM: resume from suspend-to-idle
Mar 06 10:24:20 electro kernel: ACPI: PM: Wakeup unrelated to ACPI SCI
Mar 06 10:24:20 electro kernel: PM: Triggering wakeup from IRQ 7
Mar 06 10:24:20 electro kernel: Timekeeping suspended for 7.999 seconds
Mar 06 10:24:20 electro kernel: Timekeeping suspended for 11.188 seconds
Mar 06 10:24:20 electro kernel: amd_pmc: SMU idlemask s0i3: 0xfeff1afd
Mar 06 10:24:20 electro kernel: PM: suspend-to-idle
Mar 06 10:24:20 electro kernel: ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 entry
Mar 06 10:24:20 electro kernel: ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms entry
Mar 06 10:24:20 electro kernel: ACPI: \_SB_.PEP_: Successfully transitioned to state screen off
Mar 06 10:24:20 electro kernel: PM: noirq suspend of devices complete after 46.406 msecs
Mar 06 10:24:20 electro kernel: ACPI: EC: interrupt blocked
Mar 06 10:24:20 electro kernel: PM: late suspend of devices complete after 1.403 msecs
Mar 06 10:24:20 electro kernel: Disabling GPIO #130 interrupt for suspend.
Mar 06 10:24:20 electro kernel: Disabling GPIO #8 interrupt for suspend.
Mar 06 10:24:20 electro kernel: Clearing debounce for GPIO #0 during suspend.
Mar 06 10:24:20 electro kernel: PM: start suspend of devices complete after 119.088 msecs
Mar 06 10:24:20 electro kernel: PM: suspend of devices complete after 117.733 msecs
Mar 06 10:24:20 electro kernel: queueing ieee80211 work while going to suspend
Mar 06 10:24:20 electro kernel: GFP mask restricted

Best

Avatar
Discard
0
Avatar
Samanta Sanchez Slimbook
Best Answer

Good afternoon, Roshan

We have tried the same setup that you currently have and the device suspends correctly, it might be an issue with your current OS configuration
I recommend sticking with the 6.12 kernel until newer kernel versions fix the issue

Regards,

Avatar
Discard
0
Avatar
AndyM48
Best Answer

My reply in https://slimbook.com/en/forum/questions-and-answers-from-the-slimbook-user-community-1/question/executive-14-wifi-randomly-hard-blocked-11522 may help?

Avatar
Discard
0
Avatar
Arkarlos
Best Answer

Coincidentally I have switched today from fedora gnome to kde, and I am experiencing the exact same problem. Included the "trick" of pressing the power button briefly to wake the computer up.

Avatar
Discard
0
Avatar
RJ
Best Answer

@AndyM48 thanks for the suggestion but I don't think that is the cause. I turned off the wifi before suspending with `nmcli radio wifi off` and `systemctl suspend` - the same thing happens. 

I think the issue lies in whatever changed in newer versions of the kernel, maybe related to amdgpu. I am honestly regretting choosing AMD over Intel - never had such issues with Intel in my XPS13.  This is also independent of desktop environment/window manager since I have also tried the same thing with hyprland.  

I have a feeling that the laptop might not even be going to sleep, or at least in the sleep state it should be going to. The initial suspicion arose because usually the battery discharge is 1% per hour during sleep. But since this issue started happening, the discharge is more than 3% per hour. This points to the laptop not going to proper sleep state. I checked it with `amd-s2idle` utility from AMD. With the newer kernel version, during the sleep test, the hardware sleep is 0%, whereas in linux-lts, the hardware sleep is ~50%. The utility also complains "Did not reach hardware sleep state" in the case of recent linux kernel.

|    | Start Time          | Duration   | Hardware Sleep   | Battery Start   | Battery Delta   | Battery Ave Rate   | Wake Pin   | Wake Interrupt   |
|---:|:--------------------|:-----------|:-----------------|:----------------|:----------------|:-------------------|:-----------|:-----------------|
|  0 | 2026-03-07 12:52:25 | 0:00:16    | 0.00%            | 80.00%          | 0.00%           | 0.00W              |            | ACPI SCI         |
|  1 | 2026-03-07 12:52:46 | 0:00:15    | 0.00%            | 80.00%          | 0.00%           | 0.00W              |            | ACPI SCI         |
|  2 | 2026-03-07 12:53:06 | 0:00:15    | 0.00%            | 80.00%          | 0.00%           | 0.00W              |            | ACPI SCI         |

|    | Start Time          | Duration   | Hardware Sleep   | Battery Start   | Battery Delta   | Battery Ave Rate   | Wake Pin   | Wake Interrupt   |
|---:|:--------------------|:-----------|:-----------------|:----------------|:----------------|:-------------------|:-----------|:-----------------|
|  0 | 2026-03-09 09:02:24 | 0:00:12    | 50.00%           | 80.00%          | 0.00%           | 0.00W              |            | ACPI SCI         |
|  1 | 2026-03-09 09:02:40 | 0:00:13    | 46.15%           | 80.00%          | 0.00%           | 0.00W              |            | ACPI SCI         |
I don't really understand the output from the amd-s2idle utility. But I did notice a difference in GPIO's listed in the table. The following GPIO was only there for the test with linux-lts.  
    gpio     int|active|trigger|S0i3| S3|S4/S5| Z|wake|pull|  orient|       debounce|reg
    #18      😷|     ↑|   edge|    |   |     |  |    |    |input  ↑|               |0x50800
Best,
RJ
Avatar
Discard
0
Avatar
Samanta Sanchez Slimbook
Best Answer

Good morning, RJ

If you haven't tried it yet, you can try using `mem_sleep_default=deep` in your kernel parameters to force the system to go to deep sleep and see if with newer kernels your device can go to sleep properly

Regards,

Avatar
Discard
0
Avatar
RJ
Best Answer

Hi Samanta,

Thanks for the suggestion. Evo14 only supports s2idle, so I doubt this would help. But I will try it in the future. 

$ cat /sys/power/mem_sleep
[s2idle]

Best,

RJ

Avatar
Discard
0
Avatar
Paquito
Best Answer

Hi RJ.

I suggest you a RAM test.

Best regards

Avatar
Discard