After reinstalling, computer hangs when putting to sleep/suspend

Also please provide a complete set of journal of a normal boot and shutdown. No need to try a suspend. It is only to see if there are additional errors in the journal from hardware/software/firmware. You can upload the journal to https://paste.opensuse.org/

Limit the output so that we only see the journal from the last boot (described above)
sudo journalctl -b -1

When I run
systemctl isolate multi-user.target

I get
Warning: The unit file, source configuration file or drop-ins of multi-user.target changed on disk. Run 'systemctl daemo n-reload' to reload units.

I didn’t understand the purpose of the command, but now I’ve educated myself.
After running the command after rebooting, it is accepted without any errors but after rebooting for a second time, slot 0 is opened, I get a warning about pressing T to show the boot messages then the GRUB screen is shown, countdown to boot into openSUSE lags significantly and input feedback is also delayed, then SDDM loads, I put my credentials and the graphical session is loaded again.

Did you manage to solve this issue?
Could you provide the outputs of:

cat /sys/power/state
cat /sys/power/mem_sleep

Nope, I couldn’t change the system to a non-graphical target.

freeze mem disk
s2idle [deep]

BTW, these are my kernel params

splash=silent resume=/dev/system/swap quiet security=apparmor crashkernel=364M,high crashkernel=72M,low

1 Like

Please try booting with the following kernel commandline option:

mem_sleep_default=s2idle
# or if that doesn't work
mem_sleep_default=shallow

Make sure all peripherals except display, keyboard, and mouse are disconnected prior to booting and testing suspend. You can add them back later if suspend works to see if any of them breaks it.

First parameter:
Case LEDS and GPU LEDS didn’t turn off but keyboard LED did. When pressing a key, keyboard switched on but display did not receive any signals, then keyboard froze, no LED feedback when pressing capslock. Fans didn’t spin at max speed and I could switch off by holding the power button, unlike before when I had to switch-off the PSU.

Second parameter: I got a good crash log:
sudo journalctl -b -1 -k -p 4

Oh, also, it started like the previous but trying to get keyboard feedback I pressed all the alt+ctrl+F1 to F12 combinations one by one and the monitor suddenly started flashing, then a crash log I didn’t have time to read then finally, restarting on its own.

As suspend in the VM is crashing the host, it only adds more complication and doesn’t help much for future troubleshooting and even less so for protecting the host from unsafe shutdowns. Especially if you’re filing a kernel bug report, they won’t accept a tainted kernel.

Could you repeat the process with the host after:

  1. Reset BIOS settings to its defaults and reset CMOS for good measure
  2. Update all firmware using fwupd

You mean VM as in virtualbox? I can uninstall virtualbox.

This is in most cases a really bad advice. The TO did not indicate any changes in BIOS prior reinstallation. Resetting the BIOS to factory defaults will in most cases degrade the system performance and cause much issues as the manufacturer of the computer system did proper adjustments (CPU settings, raid settings, VT-settings, …)

When giving such advice you should at least mention that it is absolutely necessary to note down, which settings will change back to factory defaults (summary before reset will applied)…

Your last crash log looks like that your guess from your first post was already right. It seems like it is the same problem as reported on github.

But as this problem should already be patched in the Tumbleweed kernel, it appears that a new/similar one was introduced

Yeah, and there’s a new report.

You would think many would be reporting such a monumental bug, apparently everyone uses Nvidia?

If you want performance without bloated marketing blaba…yes :wink:

1 Like

Personally I would recommend virt-manager (qemu/kvm) which can be setup from Yast. But it’s not required to remove Virtualbox if you have many images in its format.

Anyway my response was not meant to remove VBox but to not troubleshoot from it. The VM crashing the host is quite surprising :face_with_spiral_eyes: and along with Vbox’s tainted kernel makes it completely unsuitable for further troubleshooting.

This looks like a kernel regression but as you’ve already tried several other distros with potentially older kernels I think it might be the firmware or other settings.
Just to be certain, when you have the time try a live ISO with an older kernel on the host and see if the issue can be reproduced. Do not use the 6.6 LTS kernel (there’s apparently some communication issue at kernel.org causing a whole bunch of problematic “fixes” being backported to the LTS kernels so you might end up with the same problem), use 6.1 if possible or some other stable kernel from the 6.6 series when you were certain this bug didn’t happen.

Edit: you can get kernel 6.4.0 from the ALP repo. I used it to verify a kexec kernel bug which was introduced in 6.7.x series:
https://download.opensuse.org/repositories/Kernel:/ALP-current/standard/x86_64/

@lavadrop can you show your kernel boot options before looking at installing an unsupported kernel from a development repo for a completely different product…

cat /proc/cmdline

I would look at disabling the display core driver with a kernel boot option amdgpu.dc=0 first as a test and also make sure your system is up to date with the 6.8.2 kernel from yesterdays snapshot release.

I have no need for a virtual machine other than upgrading firmware that can only be updated on Windows, like with the Sony Dualshock or my pulsar mouse. I ran all those VMs out of curiosity. I already uninstalled virtualbox.
Distros with kernels older than 6.4 don’t support my GPU. This exact hardware was running fine and suspend was working fine until I reinstalled. Last known snapshot that ran fine was one week before Feb 26th.

Sure.
BOOT_IMAGE=/boot/vmlinuz-6.8.1-1-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap quiet security=apparmor mitigations=auto

I just upgraded to today’s snapshot, will try your suggestion.

Ah okay. If the latest kernel didn’t fix the issue, grab an RPM of an older kernel for testing but not too old that it doesn’t support your system.

A good guide on performing git bisect to find/submit Linux kernel regression report:
https://www.leemhuis.info/files/misc/How%20to%20bisect%20a%20Linux%20kernel%20regression%20—%20The%20Linux%20Kernel%20documentation.html

It can be used to build stable kernels too :wink:

@lavadrop or check out Kernel HEAD (6.9 rc2) as this is what is being worked on.

https://download.opensuse.org/repositories/Kernel:/HEAD/standard/

And a new snapshot was released tonight, so might want to upgrade first…