Permanent crashes when putting my laptop to sleep after latest update

Hello there.

I’m posting again regarding this issue, but this time I just cannot seem to be able to put my laptop to sleep anymore. This is an Asus ROG laptop, and I’m using KDE Plasma. I’m currently running the 6.2.6 kernel, and the solution to this issue was previously running the LTS kernel (which happened to be 5.16 iirc). I reluctantly used that as a solution, but that simply being a workaround, I’d like to have an actual, permanent solution to my issue.

I’ve reinstalled the system because I had some unrelated issues, and since then, because the LTS kernel is version 6.1, it also crashes my system when it’s put to sleep. Like I described in my previous post, the laptop doesn’t even get to the point of sleeping. It starts doing all the preparations, but it never reaches the state, seemingly getting caught in an infinite loop for some reason. The laptop then becomes completely unresponsive, so not even REISUB works to bring it back up, requiring a hard power off to “fix”. I have no idea if this is an issue with systemd, upower, or what have you.

I can post my newest journalctl crash log, but it doesn’t look much different to the ones I posted on my previous thread, so I can’t know where to start troubleshooting the problem. This all seems to have started when the 6.1 Linux kernel dropped, where something about the handling of sleep state on this laptop broke completely.

How can I even begin approaching the troubleshooting of this issue? Is there something I can do to submit a bug report or something? Because this issue seems to be very random and not having a clear cause (that I can see), it could be anything, so at least I’d like to have an idea of what could be causing this before submitting any bug reports.

Here are some things I would suggest checking/trying:

  1. Make sure nvidia_drm.modeset=1 is on the kernel boot line

  2. Create the file /etc/modprobe.d/nvidia-power-management.conf

options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp
  1. Enable one or both of the following services
    • sudo systemctl enable nvidia-suspend.service
    • sudo systemctl enable nvidia-persistenced.service (if external monitor is used)

NOTE: At this point, you could try rebooting, and test suspend.

  1. Edit the file /usr/share/sddm/scripts/Xsetup
#!/bin/sh
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
  1. Create file /etc/X11/xorg.conf.d/20-nvidia.conf
Section "Module"
    Load "modesetting"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:1:0:0"
    Option "AllowEmptyInitialConfiguration"
EndSection 
  • The BusID should be PCI:1:0:0, but you can find yours using
lspci | grep -E 'VGA|3D'

Hoping this works for you, or at least changes the output messages to something you can troubleshoot.

Okay, so I tried the first 3 steps, and my system completely broke. It stopped booting into the desktop, and whenever I booted, the greeter would just be a black screen and stay frozen there. Since it was just the display manager malfunctioning, I could still log in through TTY2, and I tried reversing the steps you suggested, but nothing.

I was the entire day yesterday troubleshooting the issue, trying to get my laptop to boot normally again. I tried every suggested solution I could find (seemingly something like this is caused by Nvidia driver issues), but nothing worked. I gave up and reinstalled the OS from scratch. I’m unsure if I should follow the rest of the steps now lol.

That is unfortunate, I had a high confidence this would work. I use this on my Asus gl752vv, while not exactly your unit, spec wise seems close (mine actually being the lower spec).

There are two other items I did not think to mention, that may impact the outcome. I do not use optimus-manager or envycontrol (or other such apps). With the nvidia drivers since v5xx these apps just didn’t seem to provide any real benefit to me any longer. I don’t see that you mention using this, and the conflict with optimus-manager would come at step 5 I believe, which you did not do. Again, just mentioning this as related to video.

The other item I do, and may have a higher impact to the situation, is remove the xf86-video-intel. I do this during install, and actually uncheck GPU drivers. The kernel i915 driver gives me all my resolutions, where as the xf86-video-intel would limit these. The newest ISO does not install this, but not knowing which ISO you used you can do

yay -Ss xf86-video-intel

to see if it is installed and remove if desired.

It is definitely your choice on how or if you proceed, and I wish you all the luck resolving your issue.

Please run inxi -Fxx0z | eos-sendlog and post the link here. Would be easier for everyone to look at your spec without going to another post.

I had a look at your spec it’s an Intel CPU + Nvidia. Could you or did you try this and see if it stops your issue.

Okay, I’ll try this out in a while. The method I’ve always used for installing the Nvidia drivers since I started using EndeavourOS has been the same: by using the suggested nvidia-inst package. I think this package does not include nvidia-prime, and I believe it also removes it if it’s installed.

And for the record, I’m using the latest ISO, so I think these instructions apply.

The nvidia-inst is a way to install, which works very well, if the ISO boot nvidia option does not work for you. You are correct, that does not install nvidia-prime. That is on my Asus laptop, so I must have installed that at some point without adding it to my notes. I believe it is useful to force it from the cli to use the nvidia dGpu. It may handle other things as well, so that would probably be a good thing to have installed in any event.

s4ndm4n’s suggestion is enumerates a few items. The first is adding the ibt=off to kernel boot line. This works with 11th gen Intel or later. I do not need that kernel boot with Asus i7-7600HQ, but do need it on my newer HP Omen i7-11800H. This is fairly trivial to implement and test if you wanted to try though.

Another item is using the new nvidia-open drivers. Those drivers only work with GTX 16xx (Turing/Ampere) or newer cards, so I don’t believe that will give you any relief. This is your rig, so your choice if you venture down the rabbit hole.

Then it also points out that nvidia v530 drivers are in BETA, with several fixes. Hopefully this drops sooner rather than later, but is a waiting game.

Okay, I won’t mark this as solved just yet, because I need more testing, but I think I’ve managed to fix this.

So if I indeed managed to fix this issue, then it turns out this is completely unrelated to kernel updates or EndeavourOS at all. It just so happened that it started happening at about the same time as a kernel update dropped.

So what happened was that I noticed that even normal power off had started becoming hit or miss, i.e. sometimes I would try shutting down my laptop from the shutdown menu option and when Plymouth showed that it had reached target power off state, the sceen would just go black and the laptop would become unresponsive and the fan would keep spinning… exactly like it was happening with the sleep state.

So as you might be suspecting, yes, I actually went and took apart my laptop to remove the CMOS battery. Once the UEFI settings were reset (and I disabled Secure Boot again), I haven’t had the problem since. It’s only been a couple days, but I’m able to put the laptop to sleep normally for now, and it powers off normally.

So I’ll come back in a couple of days, and if it truly stopped happening, then I’ll mark this as solved. Thanks for the assistance.

1 Like

Glad to hear you have possibly found the solution.

I am also looking forward to your update if this is the solution as I have an older Asus ROG laptop, though currently working, in case it has issues in the future.

Okay, spoke too soon. After this had seemingly stopped, it’s come back again with a vengeance. And apparently, I’m not crazy, since it seems like vanilla Arch users have the same thing happen to them. It’s completely unrelated to Nvidia chips, and it’s 100% something broken in the kernel.

1 Like