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

MaxX2342 · December 1, 2021, 8:47pm

@dzy201415 @ionen @Tatsh FYI: Gentoo incorporated the binary patch with =x11-drivers/nvidia-drivers-495.44-r2 (latest ~amd64)

user88664 · December 9, 2021, 5:26pm

nvidia-fake-powerd does the job, thank you all…but I assume the spamming of the dbus is still going on in the background which I am not very happy about it. What a strange/silly bug and even stranger to still be present after so many revisions of the driver.
(Running Endeavour OS with 495.44 drivers on a 5950x)

NoXPhasma · December 14, 2021, 3:38am

Driver version 495.46 seems to have fixed this issue for me. Can anyone confirm?

ionen · December 14, 2021, 6:01am

A reliable way to check is with dbus-monitor --system (as root), will see something like potentially ~10000 dbus powerd request per second when using OpenGL if the issue still exists.

And unfortunately, this still happens with 495.46. As far as I can tell, 495.46 is just adding support for additional cards and didn’t really change anything (its Changelog is mentioning the changes from previous versions – I’d imagine a bigger release is coming up).

Unless using wayland/GBM, for now I personally recommend to just use 470 production branch (470.93 was newly released and still isn’t affected) rather than elaborate workarounds if used distro allows it. But fake-powerd or the binary patch (applies as-is for .46 too) still works (latter still to be done with caution).

NoXPhasma · December 14, 2021, 10:20am

You are right, I was running dbus-monitor --system without root and didn’t had that spam. With root I can see it as well. Bummer.

dinosaur · December 14, 2021, 12:50pm

It is time for NVIDIA officials to speak up, don’t you think ?.. I cannot understand that such a huge flaw is left unfixed for three consecutive releases (and two releases and over one month and a half after I reported this bug).

erich.alt_nvidia · December 15, 2021, 7:04pm

I can confirm 495.46 spams /var/log/messages with the dbus-daemon messages and causes the kwin_x11 process to be pegged at 100% CPU, whereas 470.74 solves the problem (no messages and kwin_x11 behaves fine).

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

I did not try the “nvidia-fake-powerd” solution, as it’s easy enough to just revert to the 470 series driver.

user97930 · December 16, 2021, 9:22am

Hi, I’m trying your solution, but I’m getting this error on Ubuntu 20.04LTS:

systemctl status nvidia-fake-powerd.service
● nvidia-fake-powerd.service - NVIDIA fake powerd service
     Loaded: loaded (/etc/systemd/system/nvidia-fake-powerd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2021-12-16 10:11:50 CET; 10s ago
    Process: 375891 ExecStart=/usr/bin/dbus-test-tool black-hole --system --name=nvidia.powerd.server (code=exited, status=217/USER)
   Main PID: 375891 (code=exited, status=217/USER)

pro 16 10:11:50 PC-3090 systemd[1]: Starting NVIDIA fake powerd service...
pro 16 10:11:50 PC-3090 systemd[375891]: nvidia-fake-powerd.service: Failed to determine user credentials: No such process
pro 16 10:11:50 PC-3090 systemd[375891]: nvidia-fake-powerd.service: Failed at step USER spawning /usr/bin/dbus-test-tool: No such process
pro 16 10:11:50 PC-3090 systemd[1]: nvidia-fake-powerd.service: Main process exited, code=exited, status=217/USER
pro 16 10:11:50 PC-3090 systemd[1]: nvidia-fake-powerd.service: Failed with result 'exit-code'.
pro 16 10:11:50 PC-3090 systemd[1]: Failed to start NVIDIA fake powerd service.

Would you know what’s going on? Thanks

user16974 · December 16, 2021, 6:30pm

There are a couple of issues with Ubuntu that will require some tweaks to the deployment. First, the dbus-test-tool isn’t installed by default. For that you’ll need to apt install dbus-tests. Next, the system account for dbus is named messagebus. You’ll need to rename the user in both files. The following changes allow it to start within my 20.04 LTS test VM:

/etc/dbus-1/system.d/nvidia-fake-powerd.conf

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
        <policy user="messagebus">
                <allow own="nvidia.powerd.server"/>
        </policy>
        <policy context="default">
                <allow send_destination="nvidia.powerd.server"/>
                <allow receive_sender="nvidia.powerd.server"/>
        </policy>
</busconfig>

/etc/systemd/system/nvidia-fake-powerd.service

[Unit]
Description=NVIDIA fake powerd service

[Service]
Type=dbus
BusName=nvidia.powerd.server
ExecStart=/usr/bin/dbus-test-tool black-hole --system --name=nvidia.powerd.server
User=messagebus
Group=messagebus
LimitNPROC=2
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=default.target
Alias=dbus-nvidia.fake-powerd.service

And of course:

systemctl daemon-reload
systemctl restart nvidia-fake-powerd.service
systemctl status nvidia-fake-powerd.service

user97930 · December 17, 2021, 8:18am

Great, thanks… the user was the problem, I didn’t know the name :)

But weird thing is that even after I did config with wrong username, after reboot, the messages didn’t appear anymore. Even though the service nvidia-fake-powerd failed to start.
Weird.

qumaciel · December 17, 2021, 6:24pm

The nvidia-fake-powerd didn’t solved the issue for me.

I’m on Garuda.

user16974 · December 17, 2021, 10:02pm

@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.

user191239281 · December 20, 2021, 2:23pm

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.

TwoD · December 21, 2021, 10:15pm

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.

cyberdeath · December 26, 2021, 10:29pm

This also worked for 495.46.

42communicate · January 6, 2022, 1:35am

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.

user6650 · January 7, 2022, 10:27am

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

C0rn3j · January 11, 2022, 10:25am

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

C0rn3j · January 11, 2022, 4:49pm

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.

https://www.nvidia.com/Download/driverResults.aspx/184911/en-us

NoXPhasma · January 12, 2022, 1:46pm

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.