EndeavourOS – Slow wake from suspend and sometimes touchpad stops working

Hi, I installed EndeavourOS no too long ago and the system runs perfectly i am using kde and i riced it and it feels and looks fine. the only problem i have with it is that when i close my laptops screen or suspend it and when i try to wake it up it takes a long time to wake up. when i does the screen sometimes turns on (still black) then off again. And right before it turns on again i (most of the time) see white text come up on the screen with a bunch of errors and in alot of lines i see “Failed to enable link training”. sometimes the touchpad stops working and i have to reset it with terminal.

When i looked into it, the probelm is most likely coming from my nvidia gpu.

NVIDIA GPU info:

NVIDIA-SMI 595.58.03
Driver Version: 595.58.03
CUDA Version: 13.2

GPU: NVIDIA GeForce RTX 2050 (4GB VRAM)NVIDIA GPU info:NVIDIA-SMI 595.58.03
Driver Version: 595.58.03
CUDA Version: 13.2

GPU: NVIDIA GeForce RTX 2050 (4GB VRAM)

i sent the error logs that i could find to chatgpt so i can understand whats going on and it said something about intel integrated graphics and my GPU conflicting but i don’t trust it with my system

here is what it said:

  • The Intel GPU (i915) is failing to properly reinitialize the display (eDP) after suspend

  • This causes the delay + error spam

  • Other devices (like the touchpad) break as a side effect

i am not using systemboot not grub and i think thats about all the information that i have and understand a bit. i can send logs but they are too long so if i need to send something specific i will.

Hi @zgaw, welcome to the forum and congrats on your first post! :slightly_smiling_face:

Your analysis is on the right track.

The issue is your Intel iGPU (i915 driver) failing to properly reinitialize the laptop screen after suspend — that’s what causes the long wake time and other errors.
The touchpad breaking is just a side effect of the messy resume.

A common fix for this is disabling Panel Self Refresh (PSR),
a power saving feature on Intel GPUs.

Add the following to your bootloader kernel parameters:

i915.enable_psr=0

If that doesn’t fully fix it, also add:

nvidia.NVreg_PreserveVideoMemoryAllocations=1

That one helps NVIDIA properly save its state during suspend.

Reboot.

Let us know how it goes!

Hi, thanks for the help! I tried both i915.enable_psr=0 and nvidia.NVreg_PreserveVideoMemoryAllocations=1, but unfortunately it didn’t fix the issue — I still get the “failed to enable link training” error and slow wake after suspend.

Hi @zgaw, since those didn’t help we need to see what’s actually happening during resume. Right after a problematic wake, run:

journalctl -b -1 -k | grep -E "i915|nvidia|link training|drm|suspend|resume" | tail -60

Hi, here are the relevant logs from suspend to wake:

Apr 16 23:14:03 kernel: PM: suspend entry (s2idle)
Apr 16 23:14:12 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:14:29 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:14:46 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:14:50 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Apr 16 23:14:50 kernel: queueing ieee80211 work while going to suspend
Apr 16 23:14:50 kernel: PM: Some devices failed to suspend, or early wake event detected
Apr 16 23:14:51 kernel: PM: suspend exit
Apr 16 23:14:51 kernel: PM: suspend entry (s2idle)
Apr 16 23:15:02 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:15:15 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:15:36 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:15:48 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:16:10 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:16:26 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:18:15 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Apr 16 23:18:15 kernel: queueing ieee80211 work while going to suspend
Apr 16 23:18:15 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:18:15 kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:502:eDP-1][ENCODER:501:DDI A/PHY A][DPRX] Failed to enable link training
Apr 16 23:18:15 kernel: i915 0000:00:02.0: [drm] i915 raw-wakerefs=1 wakelocks=1 on cleanup
Apr 16 23:18:15 kernel: WARNING: intel_runtime_pm_driver_release [i915]
Apr 16 23:18:16 kernel: PM: suspend exit

The Failed to enable link training error keeps repeating during resume, along with suspend failures and retries, which seems to match the long wake time I’m experiencing.

Hi @zgaw

Those repeated Failed to enable link training errors on the eDP-1 display during suspend are the culprit—your GPU is getting stuck trying to power down, so the whole system can’t sleep properly.

Quick test: Try a different kernel first before digging deeper.

Switch to LTS or RT in EndeavourOS settings and see if the issue goes away. Sometimes newer kernels have i915 regressions that older ones don’t.

If that doesn’t help, we can try disabling Panel Self-Refresh or other i915 tweaks. But kernel swap is the fastest way to rule things out.

Hi @made-lief

Sorry for the late response. I installed the lts kernel and it boots ok no failed stuff but i get a black screen with a cursor on the top left of the screen and no GUI. the only thing i can do is open TTY and mess with some stuff there and i am doing that currently. and managed to break my other kernel but had timeshift setup so thats why it took me a long time.

Hi @zgaw, no worries about the wait — glad Timeshift saved you! :blush:

The black screen with cursor is most likely because the NVIDIA driver package for the LTS kernel is missing. The regular nvidia package only works with the standard kernel — each kernel needs its own matching driver.

From TTY, run:

sudo pacman -S nvidia-open-lts
sudo mkinitcpio -P
sudo reboot

Also worth trying a different kernel if LTS keeps giving trouble.

List available kernels in the repo.

pacman -Ss '^linux[0-9-]*$'

Example zen kernel

sudo pacman -S linux-zen linux-zen-headers nvidia-zen
sudo mkinitcpio -P
sudo reboot

To check what’s actually failing before rebooting:

systemctl status display-manager

Hi, i want to add that i am using the dkms driver (isnt the dkms driver an “all-rounder”) and planning to switch to hyprland and i don’t know if it will work smoothly on the lts kernel

If you use dkms all you need is linux-headers and linux-lts-headers for the dkms driver to work on both kernels.
Also, I am not shure if you need to do mkinitcpio as endeavouros uses dracut per default, introduced all the way back in 2022:

So you shouldn’t need mkinitcpio, unless you have it for some reason. (which I really doubt you have :sweat_smile:)

Thanks @Mellow

@zgaw Phjoejjj… i am also not running EOS… Forget the HOW TO kernel installation stuff.

The main first thing is replace lightdm with plasma login.

And check if the kernel and drivers are installed the right EOS way. For this i cannot advise as I am running another system.

Nowhere in this Thread is any mention of lightdm…
I think you are confusing this with another thread you are currently active in that is mentioning lightdm, sddm and plasma login manager…

Hi @Mellow

I already have both linux-headers (installed when i first installed the nvidia drivers) and linux-lts-headers (installed when i installed the lts kernel). And i reinstalled the lts kernel headers when i troubleshooting the black screen by myself.

Hi, sorry for the late reply. i did some digging about your problem, and also had some personal stuff going on.

I am not shure why the lts-kernel is giving you just the black screen with the cursor and nothing else, maybe you can explain a bit further about it, like how you installed it, and what is going on etc, and also, does the normal mainline kernel still work?

And about the other problem, the “failed to enable link training” part. I looked this up and it seems that this has been happening a lot in the past. I have seen posts from 2014, 2015, 2016, 2018 and 2019, 2023,… its related to the i915 driver, so intel related, not really nvidia like you would usually expect. But everywhere i looked I have not really found a solution, like the one thing that really fixes it, apart from updating and then it got fixed by itself.
Apart from some workarounds that worked for some people:

  • If on Wayland try x11 or the other way around
  • Trying lts-kernel
  • temporarly downgrading various packages related to this issue / loading old snapshot
  • not plugging in second monitor via DP/thunderbold or, at all
  • Updates/Firmware+BIOS
  • trying kernel parameters like: i915.enable_psr=0, i915.disable_power_well=0 and/or drm.debug=0xe + making shure some GPU switcher (prime, or envycontrol for excample) is set to intel (you can also try to set it to nvidia just to test)

So thats what I found out, not much but its all i have. i think this might be more of an issue that you can find a workaround, but the real problem is more upstream and we cant do much about it apart from hope and wait to maybe an update fixes it for real, but yes maybe some parameter, setting or config can also fix it for you.

Here are some links that i used, not all, some just had issue but no comments or solutions, maybe there is something inside that helps you..

This one also has some ways to fix it when you scroll all the way down (but some probably only work on nix bc eos doesnt have a configuration.nix as far as i know, so leave these out probably)

This is what broke my mainline kernel. something about /efi not mounting and fat and vfat no longer being supported. I remembered that i setup timeshift after installing linux because i heard people saying that i will break my distro no matter what. After that scare i haven’t looked into it that much, but i think i managed to do somthing wrong while adding stuff to the entries conf files. I will try to modify them again though maybe i will find somthing

Thank you for the posts with similar problems. I will look into those and see what i can find myself. I remember seeing a post where someone with the same issue said he will just stick to turning his computer off instead of suspending. If i dont find anything else maybe thats what i will do.

Thank you both for you help. @Mellow @made-lief

Its always good to have something like that no matter what. I myself use btrfs-assistant with snapper and snapper tools. Whenever I successfully boot, it creates a snapshot, whenever I update or install something, pre and post update snapshots. Should something go wrong, I can boot straight into the snapshot with grub and restore it, all graphicly without any hassle. Can say it saved me a good couple times when I got lost.
But even if I didn’t have that, shure you can get stuff done with arch-chroot, which is what most use when you can’t get in anymore for whatever reason.

Its a learning process, and every time there is an issue we learn something, and that doesn’t matter if we ourselves messed something up, or if it’s upstream, in anyway when we try to fix it we learn something new.
And I can tell a story about that one where I got kernel panics straight for more than half a year, everyone telling me there is a hardware issue with my laptop, yet recently pretty much everything disappeared, all with one update. But yes, I learned a lot in that time to be honest :sweat_smile: