1. Please describe the problem: After upgrading the system and moving from kernel-6.5.12-300 to kernel-6.6.2-201, the nouveau driver doesn't work anymore on the system and external monitor is not recognized anymore. 2. What is the Version-Release number of the kernel: 6.6.2-201.fc39.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes, with previous version of the kernel, the external monitor was working properly. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: On a laptop with dedicated NVIDIA video card, moving from kernel-6.5.12-300 to kernel-6.6.2-201 should corrupt the external monitor usage. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Not tested. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Attaching the bug found on the dmesg. Reproducible: Always
Created attachment 2002543 [details] cutted dmesg log
Created attachment 2002599 [details] journalctl --no-hostname -k
After update to 6.6.3-200 kernel, the issue is still present.
Still not possible to have a working monitor also after upgrade to 6.6.4-200 release.
Created attachment 2004385 [details] journalctl -b -3 --no-hostname X failure confirmed on very first boot with 6.6.7 kernel, where latest previous 6.5.11 was working normally. From remote login on failing boot: # lsmod | grep veau | sort drm_display_helper 229376 1 nouveau drm_exec 12288 1 nouveau drm_ttm_helper 12288 1 nouveau gpu_sched 57344 1 nouveau i2c_algo_bit 20480 1 nouveau mxm_wmi 12288 1 nouveau nouveau 3465216 1 ttm 110592 2 drm_ttm_helper,nouveau video 77824 1 nouveau wmi 45056 3 video,mxm_wmi,nouveau # From first booting into multi-user.target: # inxi -Sz --vs inxi 3.3.31-00 (2023-11-02) System: Kernel: 6.6.7-200.fc39.x86_64 arch: x86_64 bits: 64 Desktop: Trinity Distro: Fedora release 39 (Thirty Nine) # inxi -Gxxz Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel arch: Fermi pcie: speed: 2.5 GT/s lanes: 16 ports: active: DP-1,DP-2 empty: none bus-ID: 01:00.0 chip-ID: 10de:107d temp: 48.0 C Display: server: X.org v: 1.20.14 with: Xwayland v: 23.2.2 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: nouveau gpu: nouveau display-ID: 00srv.ij.net:0 Monitor-1: DP-1 model: Acer K272HUL res: 2560x1440 dpi: 109 diag: 686mm (27") Monitor-2: DP-2 model: Dell P2213 res: 1680x1050 dpi: 90 diag: 558mm (22") API: EGL v: 1.5 platforms: device: 0 drv: nouveau device: 1 drv: swrast gbm: drv: nouveau surfaceless: drv: nouveau inactive: wayland,x11 API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 23.2.1 note: incomplete (EGL sourced) renderer: NVD9, llvmpipe (LLVM 16.0.6 128 bits) # I next booted into multi-user.target, then issued systemctl isolate graphical to get X to startup normally. Another three straight attempts to boot normally succeeded in X starting normally before clicking submit here.
While booting kernel 6.6.7-200.fc39 on a Acer Aspire 5 laptop, I see many kernel messages like this: Dec 22 02:04:24 fedora kernel: ------------[ cut here ]------------ Dec 22 02:04:24 fedora kernel: nouveau 0000:02:00.0: timeout Dec 22 02:04:24 fedora kernel: WARNING: CPU: 0 PID: 1372 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:220 gf100_vmm_invalidate> Dec 22 02:04:24 fedora kernel: Modules linked in: rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_f> Dec 22 02:04:24 fedora kernel: snd_intel_dspcfg mac80211 snd_intel_sdw_acpi videobuf2_common btusb kvm snd_hda_codec mei_pxp snd_hda_c> Dec 22 02:04:24 fedora kernel: CPU: 0 PID: 1372 Comm: gnome-shell Tainted: G W 6.6.7-200.fc39.x86_64 #1 Dec 22 02:04:24 fedora kernel: Hardware name: Acer Aspire A515-54G/Doc_WC, BIOS V1.16 12/11/2019 Dec 22 02:04:24 fedora kernel: RIP: 0010:gf100_vmm_invalidate+0x21b/0x230 [nouveau] Dec 22 02:04:24 fedora kernel: Code: 8b 40 10 48 8b 78 10 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 b7 f0 61 f8 48 89 da 48 c7 c7 31 ae 71> Dec 22 02:04:24 fedora kernel: RSP: 0018:ffffc900019db7e0 EFLAGS: 00010286 Dec 22 02:04:24 fedora kernel: RAX: 0000000000000000 RBX: ffff888101b31c50 RCX: 0000000000000027 Dec 22 02:04:24 fedora kernel: RDX: ffff888256421588 RSI: 0000000000000001 RDI: ffff888256421580 Dec 22 02:04:24 fedora kernel: RBP: ffff88810ff6d200 R08: 0000000000000000 R09: ffffc900019db668 Dec 22 02:04:24 fedora kernel: R10: 0000000000000003 R11: ffffffffba346508 R12: 0000000002000001 Dec 22 02:04:24 fedora kernel: R13: ffff88811df04f80 R14: ffff88813aa98600 R15: 0000000000000001 Dec 22 02:04:24 fedora kernel: FS: 00007fe50e111640(0000) GS:ffff888256400000(0000) knlGS:0000000000000000 Dec 22 02:04:24 fedora kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 22 02:04:24 fedora kernel: CR2: 0000562ad262c3a8 CR3: 00000001064fa006 CR4: 00000000003706f0 Dec 22 02:04:24 fedora kernel: Call Trace: Dec 22 02:04:24 fedora kernel: <TASK> Dec 22 02:04:24 fedora kernel: ? gf100_vmm_invalidate+0x21b/0x230 [nouveau] Dec 22 02:04:24 fedora kernel: ? __warn+0x81/0x130 Dec 22 02:04:24 fedora kernel: ? gf100_vmm_invalidate+0x21b/0x230 [nouveau] Dec 22 02:04:24 fedora kernel: ? report_bug+0x171/0x1a0 Dec 22 02:04:24 fedora kernel: ? console_unlock+0x78/0x120 Dec 22 02:04:24 fedora kernel: ? handle_bug+0x3c/0x80 Dec 22 02:04:24 fedora kernel: ? exc_invalid_op+0x17/0x70 Dec 22 02:04:24 fedora kernel: ? asm_exc_invalid_op+0x1a/0x20 Dec 22 02:04:24 fedora kernel: ? gf100_vmm_invalidate+0x21b/0x230 [nouveau] Dec 22 02:04:24 fedora kernel: nvkm_vmm_unref_pdes+0xeb/0x1f0 [nouveau] Dec 22 02:04:24 fedora kernel: nvkm_vmm_unref_ptes+0x18c/0x250 [nouveau] Dec 22 02:04:24 fedora kernel: ? nv50_instobj_release+0x7b/0xc0 [nouveau] Dec 22 02:04:24 fedora kernel: nvkm_vmm_iter.isra.0+0x2a6/0x890 [nouveau] Dec 22 02:04:24 fedora kernel: ? nvkm_vmm_iter.isra.0+0x36f/0x890 [nouveau] Dec 22 02:04:24 fedora kernel: ? __pfx_nvkm_vmm_unref_ptes+0x10/0x10 [nouveau] Dec 22 02:04:24 fedora kernel: ? __pfx_gf100_vmm_pgt_unmap+0x10/0x10 [nouveau] Dec 22 02:04:24 fedora kernel: nvkm_vmm_ptes_unmap_put+0xa0/0xc0 [nouveau] Dec 22 02:04:24 fedora kernel: ? __pfx_nvkm_vmm_unref_ptes+0x10/0x10 [nouveau] Dec 22 02:04:24 fedora kernel: ? __pfx_gf100_vmm_pgt_unmap+0x10/0x10 [nouveau] Dec 22 02:04:24 fedora kernel: nvkm_vmm_put_locked+0x233/0x2c0 [nouveau] Dec 22 02:04:24 fedora kernel: ? __slab_free+0xf1/0x330 Dec 22 02:04:24 fedora kernel: nvkm_uvmm_mthd+0xf2c/0x1070 [nouveau] Dec 22 02:04:24 fedora kernel: ? __slab_free+0xf1/0x330 Dec 22 02:04:24 fedora kernel: ? nvkm_ioctl+0x10b/0x250 [nouveau] Dec 22 02:04:24 fedora kernel: nvkm_ioctl+0x10b/0x250 [nouveau] Dec 22 02:04:24 fedora kernel: nvif_object_mthd+0xb4/0x200 [nouveau] Dec 22 02:04:24 fedora kernel: nvif_vmm_put+0x64/0x80 [nouveau] Dec 22 02:04:24 fedora kernel: nouveau_vma_del+0x80/0xd0 [nouveau] Dec 22 02:04:24 fedora kernel: nouveau_gem_object_close+0x27a/0x2c0 [nouveau] Dec 22 02:04:24 fedora kernel: drm_gem_handle_delete+0x6a/0xd0 Dec 22 02:04:24 fedora kernel: ? __pfx_drm_gem_close_ioctl+0x10/0x10 Dec 22 02:04:24 fedora kernel: drm_ioctl_kernel+0xca/0x170 Dec 22 02:04:24 fedora kernel: drm_ioctl+0x26d/0x4b0 Dec 22 02:04:24 fedora kernel: ? __pfx_drm_gem_close_ioctl+0x10/0x10 Dec 22 02:04:24 fedora kernel: nouveau_drm_ioctl+0x5a/0xb0 [nouveau] Dec 22 02:04:24 fedora kernel: __x64_sys_ioctl+0x94/0xd0 Dec 22 02:04:24 fedora kernel: do_syscall_64+0x5d/0x90 Dec 22 02:04:24 fedora kernel: ? __x64_sys_ioctl+0xaf/0xd0 Dec 22 02:04:24 fedora kernel: ? syscall_exit_to_user_mode+0x2b/0x40 Dec 22 02:04:24 fedora kernel: ? do_syscall_64+0x6c/0x90 Dec 22 02:04:24 fedora kernel: ? exc_page_fault+0x7f/0x180 Dec 22 02:04:24 fedora kernel: entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Dec 22 02:04:24 fedora kernel: RIP: 0033:0x7fe511b8e17d Dec 22 02:04:24 fedora kernel: Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89> Dec 22 02:04:24 fedora kernel: RSP: 002b:00007fff881fa280 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Dec 22 02:04:24 fedora kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe511b8e17d Dec 22 02:04:24 fedora kernel: RDX: 00007fff881fa310 RSI: 0000000040086409 RDI: 0000000000000013 Dec 22 02:04:24 fedora kernel: RBP: 00007fff881fa2d0 R08: 0000000000020450 R09: 0000000000000007 Dec 22 02:04:24 fedora kernel: R10: 0000559c58e2d3c0 R11: 0000000000000246 R12: 00007fff881fa310 Dec 22 02:04:24 fedora kernel: R13: 0000000040086409 R14: 0000000000000013 R15: 0000559c58e437e0 Dec 22 02:04:24 fedora kernel: </TASK> Dec 22 02:04:24 fedora kernel: ---[ end trace 0000000000000000 ]---
Still here also with kernel 6.6.8-200.fc39.x86_64. Is anyone taking a look at this? We get an error from 6.6.2-201, and we're moving forward with this on every new release!
Hi, happy new year to everyone! Just to inform that also with 6.6.9-200.fc39.x86_64 the problem is still present. Is anyone taking a look at this? Will be?
Does the rawhide kernel have the same issue?
External monitor is not recognized.
The problem is still present also with 6.6.13-200.fc39
This bug seems to have disappeared with kernel-6.7.7-200.fc39.x86_64. Maybe this is because of nvidia-gpu-firmware-20240220-1.fc39.noarch, which was added recently.
The machine that reports this bug, with new kernels (6.7.x) doesn't boot anymore! When lightdm should start, some null pointer trigger a system reboot (and I don't have any logs to report, if any idea, to get them will be very appreciated). I'm using version-lock at this point to have a running system (also if without external monitors).
Although the system will boot up with kernel 6.7.7 and the updated firmware, it does have some serious issues. The driver timeouts still occur, especially on poweron/poweroff, restart and suspend/resume. These operations take unusually long (more than two minutes) and eat up a lot of battery as well. When powering on the machine, the system will spontaneusly reboot after a minute or so, and the second boot works, but the first doesn't. Maybe this is what bitchecker observed. So for the time being, kernel version 6.5.12 still works more reliably. I hope that this will get fixed before Fedora 40 is out in mid-April.
After updates, running 6.8.7-300.fc40.x86_64 kernel, if I attach HDMI cable the system become unresponsive and doesn't work anymore.
6.8.7-200 is still b0rken with many driver timeouts and a blank screen while booting. This means I cannot install Fedora 40 because it uses a 6.8 series kernel :( Back to 6.5.12-300, which works fine. root@fedora:~# journalctl -k -b -1 ... Apr 27 20:38:45 fedora kernel: nouveau 0000:02:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ TIMEOUT ] Apr 27 20:38:47 fedora kernel: nouveau 0000:02:00.0: gr: init failed, -16 Apr 27 20:38:49 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:38:51 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:38:53 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:38:55 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:38:57 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:38:59 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:39:01 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:39:03 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:39:05 fedora kernel: nouveau 0000:02:00.0: timeout Apr 27 20:39:07 fedora kernel: nouveau 0000:02:00.0: timeout ,,,
I tried to reproduce this with a different Fermi from that in comment #5, and with 6.7 kernel, but it works just fine: # inxi -GSxxz --vs --zl --hostname inxi 3.3.34-00 (2024-04-13) Host: gb970 Kernel: 6.7.11-200.fc39.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.40-14.fc39 Desktop: TDE (Trinity) v: R14.1.1 tk: Qt v: 3.5.0 wm: Twin dm: 1: TDM 2: XDM Distro: Fedora Linux 39 (Thirty Nine) Graphics: Device-1: NVIDIA GF108 [GeForce GT 630] vendor: Gigabyte driver: nouveau v: kernel arch: Fermi pcie: speed: 2.5 GT/s lanes: 16 ports: active: DVI-I-1,HDMI-A-1 empty: VGA-1 bus-ID: 01:00.0 chip-ID: 10de:0f00 temp: 46.0 C Display: x11 server: X.Org v: 1.20.14 compositor: Twin v: 3.0 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: nouveau gpu: nouveau display-ID: :0 screens: 1 Screen-1: 0 s-res: 3600x1200 s-dpi: 120 Monitor-1: DVI-I-1 pos: right model: Dell P2213 res: 1680x1050 dpi: 90 diag: 558mm (22") Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,left model: NEC EA243WM res: 1920x1200 dpi: 94 diag: 612mm (24.1") API: OpenGL v: 4.3 vendor: mesa v: 23.3.6 glx-v: 1.4 es-v: 3.1 direct-render: yes renderer: NVC1 device-ID: 10de:0f00 API: Vulkan v: 1.3.275 surfaces: xcb,xlib device: 0 type: cpu driver: N/A device-ID: 10005:0000 # Same success with both modesetting and with nouveau display drivers.
Adding the kernel argument "nouveau.noaccel=1" (for example via GRUB) seems to suppress this problem, as described in https://gitlab.freedesktop.org/drm/nouveau/-/issues/319.
With the suggested kernel argument, I still see kernel panic when I attach an HDMI cable. Now I'm running 6.8.10-300.fc40.x86_64
Running 6.10.7-200.fc40.x86_64 the bug is still present! At the moment, external monitor is not recognized at all.
There is a recent kernel patch for this issue, see https://gitlab.freedesktop.org/drm/nouveau/-/issues/319.
(In reply to bitchecker from comment #20) > Running 6.10.7-200.fc40.x86_64 the bug is still present! > > At the moment, external monitor is not recognized at all. With 6.10.8-200.fc40.x86_64 same behavior!
FEDORA-2024-7a9026ca00 (kernel-6.10.10-200.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7a9026ca00
FEDORA-2024-03743e1292 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-03743e1292` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-03743e1292 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-7a9026ca00 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-7a9026ca00` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-7a9026ca00 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Created attachment 2046913 [details] plain dmesg from kernel 6.10.10-200.fc40 I have a newer old NVidia than reported here previously, where local keyboard and display haven't been available without using nomodeset since kernel 6.6.14: System: Host: big41 Kernel: 6.10.10-200.fc40.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.41-37.fc40 clocksource: tsc avail: hpet,acpi_pm parameters: ro root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 audit=0 selinux=0 noresume consoleblank=0 mitigations=off nomodeset Desktop: IceWM v: 3.6.0 vt: 7 dm: 1: KDM 2: XDM Distro: Fedora Linux 40 (Forty) Graphics: Device-1: NVIDIA GK107 [GeForce GT 640] vendor: ZOTAC driver: N/A alternate: nouveau non-free: N/A status: unknown device ID pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s bus-ID: 01:00.0 chip-ID: 10de:0fc1 class-ID: 0300 6.10.10 is no better than the past many.
My comment 26 experience applies also with Debian Testing (kernel 6.1 OK; 6.9 not) and openSUSE Tumbleweed (kernel 6.6.50 OK, 6.7.9 and up not).
For now - can install kernel-6.11.0-63.fc42.x86_64 from rawhide to get this fix https://bugzilla.redhat.com/show_bug.cgi?id=2252577#c7
Upstream are lots of nouveau bugs, but I couldn't find a match, and so created https://gitlab.freedesktop.org/drm/nouveau/-/issues/385 [GK107 10de:0fc1 Kepler] [drm:drm_client_modeset_probe] No connectors reported connected - black screen; no keyboard response
> Upstream are lots of nouveau bugs, but I couldn't find a match, and so created yes - I'm stuck at 6.7.12-200.fc39.x86_64 due to https://bugzilla.redhat.com/show_bug.cgi?id=2274749
FEDORA-2024-03743e1292 (kernel-6.10.10-100.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-7a9026ca00 (kernel-6.10.10-200.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
To clarify comment #29, I was using 6.10.10-200.fc40, among others, in F40 with my GK107 - no fix apparent.
Updated to 6.10.10-200.fc40.x86_64. Before the update, external monitor was not recognized, now the system crashes like reported for older versions!
Upgraded system to Fedora 41, running kernel 6.11.5-300.fc41.x86_64, still same problem.
Running 6.12.8-200.fc41.x86_64, same problem. Will someone address this?
I've switched from nouveau to nvidia driver - thats working better for me with external/usb-c display - with quirks: https://forums.developer.nvidia.com/t/bug-kfence-use-after-free-read-in-nv-dma-release-sgt-0x29-0x70-nvidia/304219
(In reply to bitchecker from comment #36) > Running 6.12.8-200.fc41.x86_64, same problem. > Will someone address this? Methinks odds it will happen will remain poor unless you report which GPU model(s) experience this. As you can see in my previous comments here, I included complete model information, whether working or not.
(In reply to Felix Miata from comment #38) > Methinks odds it will happen will remain poor unless you report which GPU > model(s) experience this. As you can see in my previous comments here, I > included complete model information, whether working or not. Really, I reported everything as asked but, you're right, better to clarify: 01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)
My Kepler GK107 10de:0fc1 continues to work just dandy with 6.6.64-200.fc41 and 6.6.75-200.fc41, but requires nomodeset with 6.12.13-200.fc41 among all other kernels newer than 6.6.x to avoid black screen and non-working keyboard. Failure is identical with Tumbleweed's recent kernels >6.6.x: # dmesg | grep -C2 'any crtc' [ 32.839504] [ T514] [drm] Initialized nouveau 1.4.0 for 0000:01:00.0 on minor 0 [ 32.841043] [ T514] nouveau 0000:01:00.0: drm: DDC responded, but no EDID for DVI-I-1 [ 32.850622] [ T514] nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes [ 32.872192] [ T45] nouveau 0000:01:00.0: drm: DDC responded, but no EDID for DVI-I-1 [ 32.881755] [ T45] nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes [ 32.883203] [ T45] nouveau 0000:01:00.0: drm: DDC responded, but no EDID for DVI-I-1 [ 32.892746] [ T45] nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes [ 35.645348] [ T572] Adding 1903664k swap on /dev/sda5. Priority:-2 extents:1 across:1903664k [ 35.932009] [ T571] EXT4-fs (sda3): mounted filesystem 41ddbe36-4522-40fb-9899-2437b222bbe5 r/w without journal. Quota mode: none.
any news on this? after upgrade to Fedora 42, no monitor is detected but a screen alert is showed (I'll upload the screen when it happens again)
In the upstream bug I provided in comment #29 you can see I provided a workaround for the trouble I have with my older Kepler. Have you tried using it? I have no Pascal like yours to try.
setting "nomodeset" nothing changes.
Nomodeset is for emergency workarounds with limited functionality, not solving main issues. I was referring to video= kernel cmdline options.
sorry but I don't understand. which option I shoud try to pass to kernel cmdline option? `video=` like this?
https://www.kernel.org/doc/Documentation/fb/modedb.txt explains video= usage. It's a workaround for broken or absent EDID from a display, or errant handling of that data using your specific GPU. EDID data tells the system various acceptable and preferred display parameters. GPUs can provide anywhere from one to 8 or more outputs with varying names according to various factors. The content of the /sys/class/drm/ directory contains the output names as determined by the kernel, which include it/those you need when using video=. The upstream bug has examples of those I used, but the output names you need must be matched to the connections your GPU provides, and to the resolutions of your displays. e.g., I used video=HDMI-A-1:d video=DVI-D-1:2560x1440@60e video=DVI-I-1:1680x1050@60D for a three output card, to: 1-disable the HDMI port 2-tell the kernel to enable DVI-D, which is connected to a native 2560x1440 display that wants 60 refresh 3-tell the kernel to enable DVI-I, which is connected to a native 1680x1050 display that wants 60 refresh.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.