Greetings,
With NVIDIA v495.29.05 drivers, I am seeing a big problem with weird/invalid dbus messages being sent to a dbus-enabled OpenGL software (a Second Life viewer in this case).
After a few minutes of running the 3D software, the /var/log/messages log fills up at an alarming rate (over 100 messages per second, leading to hundreds of MB large log files in a matter of just a few minutes) with messages such as:
Oct 24 14:55:32 localhost dbus-daemon[1939]: [system] Rejected: destination has a full message queue, 0 matched rules; type="error", sender="(unset)" ((bus)) interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.ServiceUnknown" requested_reply="1" destination=":1.25" (uid=0 pid=12679 comm="./bin/cool_vl_viewer-bin")
Running dbus-monitor --system, I get, when the OpenGL app is running, messages such as:
method call time=1635081664.325234 sender=:1.19 -> destination=nvidia.powerd.server serial=21792 path=/nvidia/powerd/datapacket; interface=nvidia.powerd.datapacket; member=AutoflDatapacket
struct {
int32 4193
int32 10538
int64 1461543769
double 1.98642e+08
double 3.44308e+22
double 7.41929e+19
double 5.64176e-315
int32 0
int32 1668
}
error time=1635081664.325251 sender=org.freedesktop.DBus -> destination=:1.19 error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=21792
string "The name nvidia.powerd.server was not provided by any .service files"
What is bizarre, is that while this SL viewer does act as a dbus server (for being sent and acting upon “SLURLs” by processing requests by other viewers or a web browser), it does so only on the session bus (not on the system bus), and only for a custom service and methods that do not involve at all upowerd.
When I disable the dbus support in the viewer, the issue does not happen. Instrumenting the code to try and detect illegal dbus methods requests on the session bus does not lead to any result (no error detected), and increasing the rate at which dbus is polled at each frame (glib-gio is used for dbus support in this viewer) does not either prevent the “full message queue” to occur.
Also, it must be noted that this computer is tuned for performances and as such does not even have upower installed: the reason why NVIDIA’s beta driver insists on trying to “speak to” powerd is therefore a mystery on its own !
Reverting to v470.74 which is the last valid/working driver for me…
nvidia-bug-report.log.gz attached.nvidia-bug-report.log.gz (303.9 KB)