Switch to CachyOS, they have patches as usual :)
To be honest, they are usually super fast when it comes Nvidia kernel modules … that’s just to name one thing. They really are a bleeding edge distribution.
I took a look at your bug report log and I can see in /var/log/Xorg.0.log.old that the X server started with just your Intel device, and then when the eGPU was plugged in it treated it as a hotplug and loaded the modesetting driver. The intention behind that is to be able to extend your desktop onto the monitors on the eGPU without having to restart Xorg.
The Xorg server does have a path to support hot unplug, but it’s triggered by udev’s device removal path. To trigger that I think you have to write a 1 to /sys/class/drm/card1/device/remove. Unfortunately, nvidia-drm doesn’t currently have a way to respond to device removal requests; currently you have to rmmod nvidia-drm completely. I have a change to add that removal path that I’m working on internally, but I should be able to provide it as a patch if you’re interested in testing it.
I think you can disable this behavior in the X server by setting
Option "AutoAddGPU" "false"
in the ServerFlags section of xorg.conf.
ah, that’s a cool feature in general!
Sure, please do sign me up :) Speaking of patches, if you could help with sources for debianization then it would make any testing infinitely easier as ppl would be able to easily build local packages, switch between them easily and then return to vanilla ones when done testing.
This indeed has solved this issue: thank you so much! :)))
My issue is (not sure if same as yours):
4090 + 570.86.16 works fine
5090 + 570.86.16 ( or any one before) Ubuntu does not boot, even a live USB with nothing
(and btw my 5090 works fine with windows 11 + 572)
Are you suggesting I need to reinstall 570.86.16 in MIT/Open mode ?
When you say yours does not work with legacy, just black screen too ? (plus fan in high speed)
LFC is still broken in this version: Wildly fluctuating refresh rate and flicker at low framerates. @array mentioned the same problem below in 570 release feedback & discussion - #78 by array, and I’m also still seeing the same thing, which has been happening since at least version 550.
Also, the desktop is really stuttery unless I use NVreg_EnableGpuFirmware=0, and firefox and thunderbird crashes when closing a window when running under XWayland. I found some people mentioning similar problems with Firefox in version 560 in 560 release feedback & discussion - #23 by multi_monitor_vrr and 560 release feedback & discussion - #28 by steckums. Seems like a segfault somewhere in /lib64/libEGL_nvidia.so.0, deep inside mozilla::gl::GLLibraryEGL::fSwapInterval.
There are still these bugs only on wayland afflicting minecraft in this driver version
I periodically take packages from their repository, including nvidia drivers, at the moment they don’t even have a 6.14-rc kernel, the more drivers for it. And I don’t think it’s a good idea to shift the responsibility for corrections from developers to community. As they stated they consider the linux-next branch when developing and know about problems before us.
So that posting quick patch or (incredibly) whole minor driver update before kernel release not should be impossible
Now looking forward, with the risk of repeating myself, this needs fixing:
- Games using vkd3d-proton needs an uplift in performance
- Suspend isn’t working properly for everyone.
- VRAM not being released properly in wayland, it works for me tho’ with workarounds but Hyprland seems to have issues?
- When the card is in P8, KDE still seems to stutter more than it should.
- This fd/VRAM leak Fd leak with explicit sync and kde plasma
- Prevent games from crashing when VRAM reaches OOM, seems to happen with apps too?
- Boot fails on some notebooks when on battery (internal display remains dark)
- Ampere (?) GPUs suffer from increased power usage? Increased idle consumption with driver 570
- Black screen over HDMI 2.1 with VRR enabled in kde and a fullscreen game is opened. Switching to DisplayPort works around the issue so most likely some HDMI 2.1 compatibility bug.
I added some other unfixed bugs:
- GPU stays at P0 on some multiple monitors configuration: GPU is stuck to maximun power state at idle when using multiple monitors
- NVDEC and NVENC force the GPU P2 state if you don’t have the issue above: Remove "P2 forced" state from drivers
- GSP is still not ready for desktop usage: Stutering and low fps scrolling in browsers on Wayland when GSP firmware is enabled - #16 by cats
It’s really annoying to always repeat the same things and Nvidia is not even responding. GSP is mandatory for Blackwell GPU according to NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules | NVIDIA Technical Blog, so 5090 and 5080 owners will have completely stuttery desktop experience. It really unacceptable, with the price of these GPUs.
comment out or remove this line in nvidia-drm/nvidia-drm-drv.c
. date = “20160202”,
Over a year later and still bugged.
I am still going to write it, 570 was released last week, even earlier really, since it was first released in the cuda package. There’s no way that driver would contain compatibility for the changes that is in 6.14-rc that came out on sunday.
If you follow next/RC commits, things changes very quickly there. I’m sure you know this.
Like I said, there are patches already, perhaps not official ones but still…
It’s a Debian problem. I run Arch with 3090 for years and never expertienced any kernel related issues.
Thanks for the additions.
Yeah, I know what you mean. I mean, I’d rather have them fix bugs than sit here and reply to threads. I know they have their own tracking system but it’s really confusing for normal people to know what they have on their todo/bug list.
And if they want to be dead quiet about some issues, fine, I’ll keep on repeating them then. :)
BUT, with that being said, Nvidia employees, we do like when you share stuff with us. :)
Final Fantasy VII Rebirth missing ground textures is still an issue that needs to be addressed.
Yes I experienced the black screen with the legacy, had to edit the GRUB boot parameters to blacklist nouveau to boot, I think these were my extra temp boot parameters (you can also remove quiet splash temporarily as well):
nomodeset nouveau.modeset=0 nouveau.blacklist=1 rd.driver.blacklist=nouveau acpi=off
Then reinstall with MIT/Open if you are using the run file, I did it from the CUDA Ubuntu 24 install following the steps and choosing sudo apt-get install -y nvidia-open.
I didn’t mean support for a kernel that didn’t exist at the time of driver release, but meant official patch by the time of arrival kernel rc 6-8 ,that users have no problems with the driver by the time of kernel official release. I appreciate the community’s work and that they fix these problems. But I will not stop saying that a company as poor as nvidia can do it yourself, rather than relying on others.
Had an issue with nv_drm_atomic_commit Flip event timeouts, used nvidia_drm.fbdev=0 to prevent it.
VRR/LFC is broken. At high frame rates, the monitor will mostly mirror the application frame rate as expected. As the frame rate decreases, the reported frame rate at the monitor will start to deviate and the lower the frame rate the greater the deviation. As the frame rate starts approaching the VRR minimum, it becomes so unstable that it engages LFC when it should not. On a monitor with a range of 48-144, a stable 55 at the application ends up on the monitor as anywhere between 40-144 and is rapidly switching between LFC and non-LFC.
eglinfo crashes on fedora kde 41 with the following message:
EGL device extensions string:
EGL_EXT_device_drm, EGL_EXT_device_drm_render_node
Platform Device platform:
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
[1] 6666 segmentation fault (core dumped) eglinfo
nvidia-bug-report.log.gz (1.4 MB)
abrt-crashinfo.tar.gz (2.3 MB)
I have the same issue.
For me it causes firefox to remain unresponsive until I kill and restart all instances.
Arch upgraded to 570 in stable for kernel 6.13 support and it broke DisplayPort MST. Only the last monitor in chain is working.
By the looks of it this is an issue on NVIDIA side.
Specs in downstream report: DisplayPort MST regression with 570.86.16-2 (#25) · Issues · Arch Linux / Packaging / Packages / nvidia-utils · GitLab