Driver version 550.90.07 does not resolve the issue unfortunately. My laptop still freezes completely when there’s graphical activity on the NVIDIA card. The system freezes hard with this driver version (not even Num Lock responds).
EDIT: I switched to the open DRM driver to see if this resolves the issue.
I’m trying the solution proposed by 0xwojak and it works.
I created the do-not-udevadm-trigger-on-update file and added nvidia.NVreg_EnableGpuFirmware=0.
I didn’t do anything else.
I can’t say anything about a long-term test yet, but I haven’t had a freeze for 2 hours, even when updating the system via the GUI and using the gpu.
And unlike the open driver, standby works very well.
@0xwojak thanks. Nvidia should hire you.
I have updated to the latest beta 555.52.04 and have done full extensive workload with 0 problems on Arch Linux, so according to the changelog it should be completely resolved for good.
Issue hasn’t been solved, still kernel panics on shutdown but seems to be rarer
If You use nvidia 555.52.04 without NVreg_EnableGpuFirmware=0 option You use nvidia-open driver so will be no kernel panics, but maybe will another problems.
With NVreg_EnableGpuFirmware=1 option (full proprietary mode) nvidia 555.52.04 driver does not fix problem with kernel panics.
Thanks for the heads up, I completely excluded that the GSP firmware is on by default now and I haven’t had the issues with the laptop with it unlike my workstation.
Thanks once again!
At last!
Version 550.90.07 also seems to have solved crashes on my machine. See hw specs here.
I’m now using NVIDIA Proprietary Driver 550.90.07 with default settings (no unusual modprobe or command line parameters, no do-not-udevadm-trigger-on-update).
nvidia_uvm 4911104 0
nvidia_drm 118784 2
nvidia_modeset 1605632 2 nvidia_drm
nvidia 60567552 29 nvidia_uvm,nvidia_modeset
drm_kms_helper 249856 4 drm_display_helper,amdgpu,nvidia_drm
[ 5.297065] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 550.90.07 Fri May 31 09:35:42 UTC 2024
[ 5.322183] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 550.90.07 Fri May 31 09:30:47 UTC 2024
No issues so far since Thu 6th. I hope I don’t jinx it :pray:
Thanks to all who’ve helped bring this to a successful end.
Well, I tested and no fix yet. Check the bloq mayus key in the video
Since applying the solution proposed by 0xwojak I’ve had no more problems using the laptop.
However, I do experience a systematic freeze (100%) when I want to shut down the computer via the graphical interface (menu → shut down → reconfirm shutdown and then a complete freeze). I’m using KDE with Wayland.
I’ve also had rare freezes on session startup.
In short, no, the problem hasn’t been solved, even with the advice given above.
The open driver version 550.90.07 doesn’t fix the standby problem either.
Pathetic, very little progress, no reaction from nvidia for so long.
Horror, pure horror, still no problems on 535
I tried again with drivers series 555 on CachyOS and Endeavour. Both freeze after a few minutes. Either while switching from Steam to another app or just idel on desktop. Hard reset required in all cases.
I uninstalled Nvidia 555 and installed 535 (with X11 not wayland). It is very stable after several hours. No freeze. I can switch from Steam to file manager, to package installer or other app without any hiccup. Resume from stand-by is a bit hit or miss though. Power off is fine. Benchmarks from Shadow of the Tomb Raider (DX 12) or Cyberpunk show no real difference with 555 and wayland.
Glad it works but sad to see that despite promises from Nvidia, 555 and wayland is far from being stable for all of us…
My laptop: Lenovo Legion Slim 7 2023, AMD zen4 7840HS with Radeon 780m, RTX 4060 (hybrid graphics), 32 GB RAM, 3 TB SSD.
Try the 555-open driver, works fine for me for weeks now.
Like I said I am not using SDDM (login manager). I just launch wayland session via
/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland
to shut down wayland session gracefully I use python script
#!/usr/bin/env python
import time
import os
import signal
import psutil
PROCS_TO_KILL = [
'startplasma-way', 'kwin_wayland_wr', 'kwin_wayland', 'Xwayland',
'xwaylandvideobr'
]
def main():
pids = list()
for process in psutil.process_iter():
for proc_to_kill in PROCS_TO_KILL:
if proc_to_kill in process.name():
print(f"Process ID: {process.pid}, Name: {process.name()}")
pids.append(process.pid)
# send all the processes a SIGTERM
for p in pids:
os.kill(p, signal.SIGTERM)
# give them a short time to do any cleanup
time.sleep(2)
# in case still exist - send them a SIGKILL to definitively remove them
# if they are already exited, just ignore the error and carry on
for p in pids:
try:
os.kill(p, signal.SIGKILL)
except ProcessLookupError:
pass
if __name__ == '__main__':
main()
and then sudo shutdown -h now
in last 3 weeks it froze on me once. Used to freeze daily. But definitely have to baby it / navigate the minefield. Not as usable as it should be.
Hi all. Unfortunately, as Kiba said here previously, the problem has not been solved.
Since Jun 12 til now I’ve experienced several crashes. While not that many times as before, the laptop still randomly freezes on session startup or shutdown when running with the latest proprietary driver.
Blacklisting nvidia-uvm seems to fix the problem, but I’ve moved back to the open kernel driver (NVIDIA UNIX Open Kernel Module for x86_64 550.90.07) which works just fine.
HW Specs: NVIDIA GeForce RTX 3050 Mobile + AMD Ryzen 9 5900HX CPU with AMD Radeon (Cezanne) Graphics
SW Specs: Cinnamon 5.6.8 over Xorg 1.21.1.7 running on Debian 12
Laptop/Mobo: Lenovo IdeaPad 5 Pro 16ACH6
Lenove P16 also has this issue, not seen after back to 535
kernel: [ 2209.139725] BUG: kernel NULL pointer dereference, address: 000000000000006d
kernel: [ 2209.139739] #PF: supervisor read access in kernel mode
kernel: [ 2209.139742] #PF: error_code(0x0000) - not-present page
kernel: [ 2209.139790]
kernel: [ 2209.139793] ? show_regs.cold+0x1a/0x1f
kernel: [ 2209.139797] ? __die_body+0x20/0x70
kernel: [ 2209.139801] ? __die+0x2b/0x37
kernel: [ 2209.139803] ? page_fault_oops+0x136/0x2c0
kernel: [ 2209.139809] ? _nv013861rm+0x34/0x50 [nvidia]
kernel: [ 2209.140694] ? os_free_mem+0x26/0x30 [nvidia]
kernel: [ 2209.141008] ? do_user_addr_fault+0x303/0x660
kernel: [ 2209.141014] ? os_release_spinlock+0x1a/0x20 [nvidia]
kernel: [ 2209.141262] ? _nv050307rm+0xed/0x1d0 [nvidia]
kernel: [ 2209.141574] ? exc_page_fault+0x77/0x170
kernel: [ 2209.141578] ? asm_exc_page_fault+0x27/0x30
kernel: [ 2209.141581] ? acpi_unregister_debugger+0x31/0x60
kernel: [ 2209.141586] ? pwq_dec_nr_in_flight+0x1e/0xa0
kernel: [ 2209.141591] process_one_work+0x2b7/0x3d0
kernel: [ 2209.141594] worker_thread+0x4d/0x3f0
kernel: [ 2209.141596] ? process_one_work+0x3d0/0x3d0
kernel: [ 2209.141598] kthread+0x127/0x150
kernel: [ 2209.141601] ? set_kthread_struct+0x50/0x50
kernel: [ 2209.141603] ret_from_fork+0x1f/0x30
kernel: [ 2209.141608]
I have kernel panics with nvidia proprietary drivers 550.90.07 and 555.52.04 versions with and without kernel option NVreg_EnableGpuFirmware=0. With nvidia-open drivers versions 550 and 555 there are no any kernel panics but I have lower perfomance with extenal monitor with open drivers.
Today has released nvidia 555.58 nfb driver with “Fixed a bug that could lead to a kernel panic, due to a failure to release a spinlock under some conditions.” but I sure that this driver does not fix problem.
When will be fixed this problem? This is a critical issue but nvidia hasn’t solved it for 4 months
Never friend, forget this.
@amrits sorry for ping, i’d also like to press a bit on the topic to know about the situation, as a fellow costumer, and for the people below pre-turing that must still use the official closed stack.
I myself am quite happy with the kernel-open drivers, i will keep using them as long as we have kernel panic, freezing issues, and am so exited to see them at action once it starts being the priority once 560 comes, therefore i will also admit that it still needs improvements (e.g from my experience: external displays, dgpu mode only performance issues, etc), as we all know with software like this it needs to be ironed out, i understand, therefore still even compared to the closed ones, at some regards.
If possible for now would like to hear feedback about the situation.
Many thanks.