PC freezes when trying to reboot or power off

Hi all.

At least 50% of the times, every time I restart or power off Tumbleweed, the PC freezes. I can try via terminal or GUI, it’s the same.

It either freezes right when I click/give the command or a couple of seconds after, and a white led on my laptop’s keyboard starts to blink. I can only hard reset to proceed.

This is only happening on Tumbleweed, not with other distros or Windows.

It’s basically a simple Tumbleweed KDE installation without the extra KDE apps. And I have four flatpaks installed: Haruna, Firefox, ffmpeg-full, Elisa. I don’t even have opi or packman enabled.

I have the current Nvidia drivers installed (Nvidia G)06.

General specs: 16GB RAM, Intel i9 13th gen with iGPU, Nvidia dGPU 4080.
Adding that I use an external monitor with USB-C to DisplayPort.

Do you have any suggestion to troubleshoot this or at least investigate further?

1 Like

I am having issues with a Lenovo laptop with an Intel and NVIDIA GPU. My issues are not during reboot/poweroff but more random freezes after using the NVIDIA GPU.

I suspect it is the NVIDIA drivers not playing well together with Wayland. Are you using Wayland or X11?

I have tried both the proprietary NVIDIA drivers and the nouveau drivers. Both result in crashes when switcing back from NVIDIA to Intel. Much better nouveau drivers should be on their way, so I am crossing my fingers and not using the NVIDIA GPU under Wayland for now… (I have not done any serious testing with X11)

Hope this helps - it’s my 2 (euro) cents :wink:

/Jaybe

Hi, thanks for caring to answer!

I am using Xorg, because on KDE there’s a process (kwin_wayland, with Wayland indeed) that uses a lot of my CPU for nothing.

I will still try to remove and re-install the proprietary Nvidia drivers. These are necessary to me to use external monitor’s audio. :')

EDIT: nope, it doesn’t work instead as I’ve suddenly experienced another kernel panic when shutting off.

For now, seems that this is the solution: SDB:NVIDIA troubleshooting - openSUSE Wiki

For those like me using systemd-boot instead of GRUB, simply add the line in the file /etc/kernel/cmdline

Maybe (I’m not sure) it might be necessary to run these commands after:
sudo sdbootutil install
sudo sdbootutil add-all-kernels

However, pressing the “e” button while choosing which OS to boot will make users able to type the additional line. Same for GRUB.
For GRUB alone, YaST will do the trick with its GUI (which is unavailable with systemd-boot).

Why am I using systemd-boot? Because it’s the only one that will allow me to have bootable snapshots.

Added nvidia-drm.fdev=0 to the kernel parameters too and this solved once and for all. Seems that no other errors are appearing.

We really need a lot of polishing in Suse, not just automated tests, at least in Slowroll or Leap since the issues appear in the latter too.

@shishimaru is suse-prime in play? Normally for iGPU/dGPU fbdev=1 nosimplefb=1 should suffice…

Can’t test proprietary setups (nvidia)…

Seems an almost common error for some TW and Arch users. I found the solution at the Nvidia forum, seems that it’s still not completely fixed (I’m not sure) [545.29.06-18.1]Flip event timeout error on startup, shutdown and sometimes suspend. Wayland unusable - Graphics / Linux / Linux - NVIDIA Developer Forums

By the way, yes, suse-prime is in offload mode. Probably would work better if in nvidia mode only. A simple workaround would be to unplug the external monitor before booting in Suse and before powering off or restarting.

Also haven’t tried “nosimplefb=1” yet, unless it’s default.

@shishimaru I use switcherooctl, but if it’s sound related, I would have thought as a separate PCI device would not be needed for sound to work over HDMI?

Well, every time I say “it finally works” I get a new kernel panic.

I’ll just renounce for now, Suse is giving me hours and hours and hours, and weeks of troubleshooting that any other distro, from Ubuntu to Fedora to Arch Linux, isn’t giving me. And not just related to this specific issue with kernel panic.

For now I’ll just workaround by unplugging the DisplayPort cable and eventually plug it again when the system boots. This will be unplugged again before rebooting/turning off.