We’re going to try an experiment of having per-release feedback and discussion threads. Please provide feedback specific to the 550.78 release here. I can’t promise that I’ll have time to read through all of it but I’ll skim it for highlights.
If you have a problem that’s not specific to 550.78, feel free to find a thread discussing your problem or, if there isn’t one, create one by following the suggestions in the PLEASE read this first thread.
It seems that native Wayland apps can now use Vulcan without crashing, at least my apps no longer crash on destroying swapchain. Was crashing in fedora 39 kde plasma 5 Wayland, 550.76. Now works fine in fedora 40 plasma 6, 550.78.
Unity crash in all 550.* versions, including the 550.78 that I’m testing, there is a oficial post in this forum with title " [550.47] Unity Editor on Linux crashes when using Vulkan Graphics backend with Nvidia 550 drivers]" reporting the fail. I’m experimenting the same crash with this version.
not much to comment on with this release, however I was able to update just fine and everything seems as OK as it is right now - hoping to see explicit sync and multi monitor gsync soon!
Also the following combination fails to offload and uses integrated graphics instead: GLES 2.0 + XWayland.
I tested with different variants of glmark2 and got the follwing results:
GL + native wayland = success (nvidia adapter is used)
GL + XWayland = success
GLES + native wayland = success
GLES + XWayland = fail, intel integrated graphics is used despite all required environment variables are set
nvidia-bug-report.log.gz (1.3 MB)
Also the following combination fails to offload and uses integrated graphics instead: GLES 2.0 + XWayland
Alas, this is a known limitation. Current drivers do not support EGL’s X11 platform with Xwayland, meaning there is no way to use GLES. Fortunately, Kyle Brenneman recently completed work on adding support for this. It is expected to be available in the 560 driver release.
Thanks for the report. The issue has been reproduced by NVIDIA and is being tracked in bug number 4640985.
I find that the 6.8.9 kernel prevents my onboard Turing mobile card from entering D3cold. Same kernel config and environment works with the 6.7.9 kernel. Is this a known issue? See link for nvidia-bug-report.log.gz
While I am at it, I have another (different) Coffee Lake system (Lenovo P53), where I see the following with the same kernel (but possibly slightly deviating kernel config), environment and driver package:
p53 /usr/src/linux # cat /proc/driver/nvidia/gpus/0000\:01\:00.0/power
Runtime D3 status: ?
Video Memory: ?
GPU Hardware Support:
Video Memory Self Refresh: ?
Video Memory Off: ?
I think I have crossed all the t’s and dotted all the i’s. The system in question shows this in dmesg:
[ 0.254552] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.439291] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[ 0.443360] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
Is this relevant for the observation above?
Built Linux 6.9.0 from vanilla sources, selected default options with “make oldconfig” from my 6.8.9 config. 550.78 worked okay until I ran Elite Dangerous Odyssey in Steam: the process stalled while pre-computing Vulkan shaders at 90%, and the kernel was in real trouble. Seems to be having trouble with the nvidia driver.
[ 1738.236307] general protection fault, probably for non-canonical address 0x8b0698f3231a575c: 0000 [#1] PREEMPT SMP NOPTI
[ 1738.236323] CPU: 18 PID: 21942 Comm: fossilize_repla Tainted: P OE 6.9.0 #1
[ 1738.236329] Hardware name: System76 Thelio Mega/Thelio Mega, BIOS FBe Z5 12/07/2020
[…and so forth…]
I’m pretty sure someone would like to see this dmesg dump, but I’m not sure where to send it. Please advise. BTW, I’m running Linux 6.8.9 now with the 550.78 driver, haven’t had any problems with that combination. Using Linux Mint 21,3 and gcc 11.
[Edit: discovered I could upload the dmesg.txt.gz here, have done so. X was completely locked up, couldn’t even ctrl-alt-f1 to get a virtual terminal. Had to ssh in to get the info. ]
-Scott
dmesg.txt.gz (41.8 KB)
I have trouble starting Wayland with nvidia open kernel driver. It will start in Xorgg and not in Wayland. I have Fedora 40.
nvidia-bug-report.log.gz (818.3 KB)
So I built the open driver and installed it. Have had no grumblings in my dmesg, and seems to be running well on Linux 6.9.0.
Have had an intermittent issue that has plagued the last two drivers with 6.8.9 and 6.9.0 (including the current combination, Linux 6.9.0 and driver 550.78): I get tearing when I move windows sometimes. Sometimes a warm boot fixes it, sometimes it takes a cold boot /and/ a warm boot, and this time I fixed it by going to telinit 1, unloading the nvidia modules, then going to telinit 5.
Just had a long play session with Elite Dangerous Odyssey, and again, nothing weird in dmesg. Working well after the above workaround.
Compared to 4060Ti, A6000 runs like a potato.
Having spent $7k on a GPU that runs like a Ford Pinto compared to a GPU that retailed for under $500 running like F1, it’s an embarrassment to the whole management team. They are NOT happy campers right now.
I’m having a black screen issue on Arch Linux since updating to Linux 6.9.1 and nvidia-550.78-4 about two hours ago. I’m running KDE 6 on Wayland with an RTX 3080 Ti.
I have KDE set up to log my user in automatically after I put in my LUKS password, but now it only logs to a black screen with a cursor. Oddly, if I alt-tab, I can see a really badly rendered view of the task switcher, so something is actually loading, but not much and not correctly. I’m certain the issue is with the driver, as everything was working fine before I shut down yesterday, and Pacman only installed those two packages when I updated and restarted this morning.
I’ve tried a few different things so far. The issue occurs with SDDM, LightDM, and LY, as well as (except for one fluke) when running /usr/bin/startplasma-wayland manually. I can get XFCE running (obviously X11), but not KDE6 on X11. Moving out ~/.config/plasma-org.kde.plasma.desktop-appletsrc, as well as all other Plasma config files, doesn’t appear to do anything. I’m honestly not familiar enough with Wayland yet to know how to force basic settings for my monitor, the way I might try with X11, but I’m open to the idea. I don’t have any environmental variables set (at least that I know of ) that would cause issues with KDE, Wayland, or NVIDIA.
I’m still hacking away at it for now. I’d really gotten used to some of the accessibility features in KDE 6, so if anyone has any ideas, I’m all ears.
Edit: I managed to get KDE 6 to “work” by downgrading to ‘nvidia-550.78-2’ via Pacman. However, while I can log in now, at least, it only detect my monitor as a normal 3440x1440@60 display, rather than the 175 Hz, HDR, G-SYNC display it is. This despite the fact that all those features were working perfectly only last night. Same issue when I restore my old config files, as well.
Edit 2: Alright, I managed to fix it by uninstalled the older versions I’d tried, reinstalling nvidia-550.78-4, and adding the nvidia_drm.fbdev=1 kernel parameter to my cmdline, per the Arch Wiki. I already had nvidia_drm.modeset=1 in there, but it apparently wasn’t enough? Regardless, everything appears to work in both Wayland and X11 now.
I found this error in the system log May 18 14:59:46 knut gnome-shell[4175]: Running GNOME Shell (using mutter 46.1) as a Wayland display server
May 18 14:59:46 knut rtkit-daemon[2048]: Successfully made thread 4457 of process 4175 (/usr/bin/gnome-shell) owned by ‘42’ RT at priority 20.
May 18 14:59:46 knut gnome-shell[4175]: Made thread ‘KMS thread’ realtime scheduled
May 18 14:59:46 knut gnome-shell[4175]: Device ‘/dev/dri/card1’ prefers shadow buffer
May 18 14:59:46 knut /usr/libexec/gdm-wayland-session[4077]: gnome-session-binary[4077]: DEBUG(+): GsmAutostartApp: (pid:4175) done (signal:9)
May 18 14:59:46 knut /usr/libexec/gdm-wayland-session[4077]: gnome-session-binary[4077]: WARNING: Application ‘org.gnome.Shell.desktop’ killed by signal 9
May 18 14:59:46 knut gnome-session-binary[4077]: DEBUG(+): GsmAutostartApp: (pid:4175) done (signal:9)
May 18 14:59:46 knut gnome-session-binary[4077]: WARNING: Application ‘org.gnome.Shell.desktop’ killed by signal 9
May 18 14:59:46 knut gnome-session-binary[4077]: Unrecoverable failure in required component org.gnome.Shell.desktop
May 18 14:59:46 knut /usr/libexec/gdm-wayland-session[4067]: dbus-daemon[4067]: [session uid=42 pid=4067] Activating service name=‘ca.desrt.dconf’ requested by ‘:1.2’ (uid=42 pid=4077 comm="/usr/libexec/gnome-session-binary --autost>
May 18 14:59:46 knut /usr/libexec/gdm-wayland-session[4077]: gnome-session-binary[4077]: DEBUG(+): GsmManager: disposing manager
May 18 14:59:46 knut gnome-session-binary[4077]: DEBUG(+): GsmManager: disposing manager
Hi @dagbdagb , I don’t mean to hijack this thread, but on my system I get
Runtime D3 status: Not supported
Video Memory: Active
GPU Hardware Support:
Video Memory Self Refresh: Not Supported
Video Memory Off: Supported
I have a GTX 1650 dGPU with a Radeon RX Vega iGPU and a Ryzen 7 4800H CPU. Does the above Runtime D3 status: Not supported mean D3 is really not possible on this system, or am I missing some required configuration?
I am running Fedora 40, and I have xorg-x11-drv-nvidia-power installed, which theoretically should take care of all the necessary bits.
RTD3 is not enabled by default on Turing cards. Does this still happen if you follow the steps here? Chapter 22. PCI-Express Runtime D3 (RTD3) Power Management
So, your card is a Turing card. I think it should be possible to enable this, given a little bit of effort.
First order of business is to read the relevant docs and set the right kernel module option to enable the feature on Turing.
Then, there is a number of additional i’s and t’s to dot and slash. Read the chapter above carefully, then cross-reference the relevant Arch and Gentoo docs on this particular topic to find additional nuggets of information.
Do understand that the feature isn’t default enabled for one or more reasons. These reasons may or may not apply to your hardware/firmware/system/distribution.
Good luck!
Thanks @jrelvas and @dagbdagb for the pointers. I had taken a look at NVIDIA’s docs, and everything seemed to be in order, but I will take a more thorough look to make sure I haven’t overlooked anything relevant.
I had the same issue. This is related to simpledrmfb driver so I added initcall_blacklist=simpledrm_platform_driver_init to the kernel command line. You can instead add nvidia_drm.modeset=1 and nvidia_drm.fbdev=1: to replace simpledrm fbdev driver by Nvidia ones.