[BUG] NVIDIA v495.29.05 driver spamming dbus-enabled applications with invalid messages

@user97930 That makes sense because it takes time for the dbus message queue to fill up if there is no valid destination to route these messages.

@qumaciel Did you follow the instructions to enable and start the service on boot? Did you also reboot to clear the dbus queue? If the service starts correctly without any errors (systemctl status nvidia-fake-powerd.service), then run dbus-monitor --system as the root user and inspect for errors or post a sample of the output here.

This also fixes an issue with a laggy external display/100% CPU under Xorg when the internal panel is disabled on an NVIDIA-based laptop.

Thanks for the AUR package, it fixed it for me.
In my case it was mostly Google Chrome and KDE spamming the journal with these messages. They didn’t explicitly mention nvidia-powerd as the destination - just “1:29” or similar, but they stopped as soon as I started the nvidia-fake-powerd service.

This also worked for 495.46.

Just a note for other to remember to use one or the other. If you use the AUR, do not manually do this file creation.
I used this method, provided by user16974, and it worked perfectly. Thank you.

1 Like

for nixos, this seems to work to prevent journal spamming atleast: workaround for nvidia dbus errors for nix https://forums.developer.nvidia.com/t/bug-nvidia-v495-29-05-driver-spamming-dbus-enabled-applications-with-invalid-messages/192892/36 · GitHub

1 Like

How is this reported in October of last year but not even acknowledged? Just noticed dbus-daemon keeps taking up 2.4GB and it’s all Nvidia messages.

Report about this on Arch Linux tracker - FS#72903 : [nvidia] dbus spamming

This bug is fixed in the next series, the 510.xx beta changelog mentions it:

  • Fixed a bug which caused OpenGL and Vulkan applications to generate excessive traffic over dbus while attempting to communicate with nvidia-powerd, even though nvidia-powerd was not running.



For me it is not. I disabled the fake service, installed the driver, rebooted and 20 hours later the dbus queue was full and the dbus process consuming over 300mb. Re-enabled the fake service and the full queue spam stopped immediately.

Sounds odd, there’s definitely no more spam looking at dbus-monitor --system as root with 510.39.01 for me.

Have you tried removing any possible remaining workarounds and booting cleanly (service, old dbus .conf, etc…). Perhaps it’s confusing the drivers into thinking powerd is running, and so it starts using it.

That was a good call, it seems that the workaround files being present was enough to trigger the spam. Once I completely vanished the files (uninstalled the AUR package and not just disabled the service) and rebootet, the spam is gone.

The 510.39.01 BETA seems to be working well for me and I can confirm that the powerd dbus messages no longer spam.

Manual removal of workaround (the service disable and status commands probably aren’t required, better to be thorough):

systemctl stop nvidia-fake-powerd.service 
systemctl disable nvidia-fake-powerd.service 
rm -vf /etc/dbus-1/system.d/nvidia-fake-powerd.conf
rm -vf /etc/systemd/system/nvidia-fake-powerd.service
systemctl daemon-reload
systemctl status nvidia-fake-powerd.service

Hello, thanks for your solution.
I tried this on my Ubuntu 20.04 and maybe it works.
However, actually I face the issue like Error `Failed to establish dbus connection` when running `sim = gym.create_sim(...)`
When I tried your solution, it does not help and the error mentioned in this post still occurs, even a simple pyqt program may fail.
Would you please come and see how to fix the issue in this post?

Please read the entire thread, there are many suggestions including validation that the service is running and monitoring the system message bus for errors. It’s entirely possible that the software you’re trying to use calls a different bus name. If this is the case, it shouldn’t be difficult to adjust the workaround to accommodate.

sudo systemctl status nvidia-fake-powerd.service
sudo dbus-monitor --system

This “workaround” is only useful for specific driver versions within the 495 series in cases where applications use OpenGL/EGL. A much better solution might be to downgrade to 470 or upgrade to the 510 beta.

Just upgraded to 510.47.03 (current production branch release as of 2022-02-01) and everything seems fine. I had experienced the bug on 495.46, and had reverted to the 470 series driver.

I’m on Slackware64-current (no systemd).

Hey, dzy201415!
I’m interested in applying the binary patch, however I’m using a different version: 495.29.05. (Unfortunately, I cannot switch to v510 either, since “davinchi resolve” does not work properly with it at the moment).
Could you please at least provide me a general direction on how to create such a patch? I already have some minimal experience on patching binary files, but I need to know at least where to start looking for, like a function’s symbol or kinda.

P.S. I’m so sorry for necroposting on this one :o

I’d personally recommend to go back to the (still supported) 470 branch for now (current 470.103.01, was never affected by the dbus issue) if 510 is giving you issues rather than try to binary patch an old new feature branch that’s affected by known security vulnerabilities.

Yes, I will also suggest using the old one whenever possible. The binary patch is found by simply searching the reference of string “nvidia.powerd.server” in reverse tools (which could be in the procedure that generate the dbus message), and change jz → jmp after that. It will not prevent the driver trying to send the message, and might also cause unexpected behavior.

Has this been fixed by now?

Yes, in v510.

1 Like