Open EccTM opened 3 months ago
There appears to be something similar to this: https://forums.developer.nvidia.com/t/drm-nv-drm-atomic-commit-nvidia-drm-error-nvidia-drm-gpu-id-0x00000900-flip-event-timeout-on-head-0/284760
I'm not ~setting nvidia-drm.fbdev=1
anywhere or~ seeing any output in my journalctl about Flip event timeout on head 0
, but it could easily be related though.
I'll capture a full journalctl and dmesg next time it happens and dig through them for any signs of this.
After looking into that link, I do have fbdev=1
set - /sys/module/nvidia_drm/parameters/fbdev
contains 'Y' - apparently the Fedora package enables it by default.
I'm going to add nvidia-drm.fbdev=0
to /etc/default/grub and regenerate grub, then see if I still have the issue occur.
Ah so this is the same error I've been getting when powering on an AVR that is connected to the HDMI port of my 3070 Ti. The system locks up and will only unfreeze if I turn off the AVR.
kernel: [drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000b00] Flip event timeout on head 1
over and over in the log.
I haven't seen the issue since I used sudo rpm-ostree kargs --editor
and added nvidia-drm.fbdev=0
as a kernel arg, which seems to be the temporary solution for that issue.
ujust regenerate-grub
didn't use the arguments from /etc/default/grub when I tried adding it there.
I still haven't ruled this out as solved, because I never faced this issue prior to updating to F40 - my prior Arch Linux install had fbdev=1 explicitly enabled without issue, and bluefin-dx-nvidia:39 would've defaulted to fbdev=1 as well.
Will give this a shot and report back. I don't think adding the args to grub will do anything, and the arg should be added as you mentioned with rpm-ostree kargs
Added nvidia-drm.fbdev=0
kargs and it seems to be working. cat /sys/module/nvidia_drm/parameters/fbdev
returns N
.
I don't have the nvidia-drm.fbdev=0
set on my desktop. But I had a similar issue when on 39 and prior to us doing early loading of the nvidia drivers. After doing early loading I haven't seen the issue. However, since it didn't happen consistently (normally would only notice if gdm failed) I couldn't pin it down to anything but fbdev being flaky.
On 40 now and I haven't seen issue. But I think this is part of nvidia actually having a bit of difference between different generations and cards
Any word on where the Nvidia 555 beta driver sits in the fedora/bluefin packaging pipeline?
I'd like to re-test nvidia-drm.fbdev=1
with the new driver and see if it still causes issues.
Any word on where the Nvidia 555 beta driver sits in the fedora/bluefin packaging pipeline? I'd like to re-test
nvidia-drm.fbdev=1
with the new driver and see if it still causes issues.
We will be shipping Nvidia 555 once the stable driver has been released and is being packaged by RPMFusion. We believe it's too risky to ship a beta driver since Bluefin is meant to be a reliable desktop experience, and there have already been complaints about the desktop experience using the new driver from users on other distros.
Describe the bug
Since the latest tag moved to bluefin-dx-nvidia:40, this issue has occurred maybe 4 times, and I never seen it when on bluefin-dx-nvidia:39. I'm not sure if this is actually a Bluefin issue, an upstream issue, or simply an aging GPU.
Output to my left monitor will just randomly hang on a frame and stop updating.
Tried turning the monitor physically off and on, and also tried going into GNOME settings and switching the screen off and on under the Display section - but both attempts just locked up the right monitor too, and lead to a hard reboot.
What did you expect to happen?
My screen(s) to not become unimpressive photo frames at random.
Output of
rpm-ostree status
Extra information or context
GTX 1080, Wayland Flatpaks of Firefox and mpv open at time of crash usually.
I've skimmed the last hour or so of my journalctl, and the freezing happening around the same time (23:49~) gnome-shell complains about a null pointer issue. TBH, I don't know what I'm looking at in this log at all though.
last hour of journalctl