Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
On Fri, Jul 25, 2025 at 08:24:48PM -0600, Benjamin Martin wrote: > Hello Uwe, > > I changed the NVIDIA file to .bak and then updated the initramfs with > Fedora's command. > > With 3 monitors connected I got a black screen, the monitors were turned on, > but black. See log for 3 monitors. > > With 2 monitors I was able to login and get to the desktop but was unable to > use it. It was very very sluggish, the mouse cursor was about 5 seconds > behind my actions. The CPU fan was on high about the whole time, indicating > high CPU usage. I think that this is because of Wayland. On Debian I am > using X11. See log for two monitors. I suspect that the Debian kernel can load the compressed firmware and just emits a misleading error message about the non-existing uncompressed files before it finds the compressed ones. (That would be easily verifiable by moving the Debian files out of /lib/firmware/nvidia without placing the compressed Fedora files there. If it behaves differently than with the compressed files, they are used.) > I had to use the rescue kernel to login and revert the changes. > > Another thing I noticed is the GPU fan, On Debian I can always hear it, its > not high, but audible, With Fedora, when the firmware files load on boot, I > can hear that fan slow down to an unnoticeable level. However when booting > Fedora without the firmware files I could hear the GPU fan, the same as > Debian. It never slowed down like before. > > So to me, this makes it clear that Debian needs to update its NVIDIA > firmware files in the kernel. Either that or Fedora has driver or config changes on top of the nouveau driver that are missing in Debian. Yesterday I tried to find the Fedora kernel sources archive, but I only found something older. Do you happen to know where to look for these? If it was only firmware files then it had to be good with Debian kernel + the Fedora firmware versions. If you want to you can test with the Fedora tree and run: find /lib/firmware -name \*.xz -print0 | unxz --files0 (untested, the intention is to uncompress all files). My expectation would be that this behaves in the same way as with the compressed Fedora firmware files, just without the error messages. > Is this something that could get pushed into Trixie yet? I doubt it, but I > guess maybe a patch could be made that I could install locally. The difficulty with firmware updates is that the changes introduced with updating are not transparent. So even if an update helps you, it might break someone else's setup ... But sure, a local modification is possible once we found the culprit. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hello Raymond, On Fri, Jul 25, 2025 at 09:20:19PM -0600, Raymond Burkholder wrote: > On 2025-07-25 20:24, Benjamin Martin wrote: > > With 3 monitors connected I got a black screen, the monitors were turned > > on, but black. See log for 3 monitors. > > > With 2 monitors I was able to login and get to the desktop but was > > You problem seems similar to mine. I thought it had to do with 2 monitors > on DisplayPort and one on HDMI. My mouse was also sluggish. And in certain > modeset settings, I'd get a blinking cursor in the upper left corner and > nothing else. > > All when using Wayland. > > I ended up connecting all three monitors as display port to one card: NVIDIA > GeForce RTX 5070 Ti. I have this nvidia driver installed: 575.64.03 If you're using the proprietary driver, all comparison is moot. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
On 2025-07-25 20:24, Benjamin Martin wrote: With 3 monitors connected I got a black screen, the monitors were turned on, but black. See log for 3 monitors. With 2 monitors I was able to login and get to the desktop but was You problem seems similar to mine. I thought it had to do with 2 monitors on DisplayPort and one on HDMI. My mouse was also sluggish. And in certain modeset settings, I'd get a blinking cursor in the upper left corner and nothing else. All when using Wayland. I ended up connecting all three monitors as display port to one card: NVIDIA GeForce RTX 5070 Ti. I have this nvidia driver installed: 575.64.03 I think the key point though is I switched away from Wayland back to X11. Everything is responsive again. As much as I'd like to run Wayland, it does seem to have some shortcomings. You can choose X11 mode in Trixie with KDE (assuming that is what you are using), but choosing the renderer in the lower left corner prior to logging in. Hope this helps.
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hello Benjamin, On Thu, Jul 24, 2025 at 07:27:31PM -0600, Benjamin Martin wrote: > I forgot to mention that the Fedora firmware files were all compressed. > Maybe that is the reason for the firmware errors in the log. Where as the > Debian files are not compressed. funny, I noticed that difference but thought that they won't have their kernel patched for that. It seems I was wrong. Given that Debian can do two monitors without firmware: I wonder what Fedora does without firmware. Does Fedora still boot if you do mv /lib/firmware/nvidia /lib/firmware/nvidia.bak plus the Fedora equivalent of update-initramfs? Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hi Uwe, I forgot to mention that the Fedora firmware files were all compressed. Maybe that is the reason for the firmware errors in the log. Where as the Debian files are not compressed. Regards Benjamin.
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hi Uwe, I tried this, but it did not help. with 3 monitors it still locks up. With 2 monitors it works and I can get to the desktop. Please see attached log. Regards, Benjamin Jul 24 00:56:34 debian kernel: Linux version 6.15-amd64 ([email protected]) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.15.6-1~exp1 (2025-07-11) Jul 24 00:56:34 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.15-amd64 root=UUID=6c47cad0-3157-4246-94b0-1985db645ff0 ro quiet Jul 24 00:56:34 debian kernel: BIOS-provided physical RAM map: Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x-0x0005efff] usable Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x0005f000-0x0005] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x0006-0x0009] usable Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x000a-0x000f] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x0010-0x74668fff] usable Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x74669000-0x74669fff] ACPI NVS Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7466a000-0x7466afff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7466b000-0x7dc9efff] usable Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7dc9f000-0x7f148fff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7f149000-0x7f1c5fff] ACPI data Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7f1c6000-0x7f66bfff] ACPI NVS Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7f66c000-0x7fffefff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x7000-0x7fff] usable Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x8000-0x88ff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0xe000-0xefff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0xfe00-0xfe010fff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0xfec0-0xfec00fff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0xfee0-0xfee00fff] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0xff00-0x] reserved Jul 24 00:56:34 debian kernel: BIOS-e820: [mem 0x0001-0x000474ff] usable Jul 24 00:56:34 debian kernel: NX (Execute Disable) protection: active Jul 24 00:56:34 debian kernel: APIC: Static calls initialized Jul 24 00:56:34 debian kernel: efi: EFI v2.7 by American Megatrends Jul 24 00:56:34 debian kernel: efi: ACPI 2.0=0x7f5d1000 ACPI=0x7f5d1000 SMBIOS=0x7fd39000 SMBIOS 3.0=0x7fd38000 ESRT=0x78329d18 MEMATTR=0x77911018 MOKvar=0x7fd5 INITRD=0x74753a98 RNG=0x7f1c5018 Jul 24 00:56:34 debian kernel: random: crng init done Jul 24 00:56:34 debian kernel: efi: Remove mem38: MMIO range=[0xe000-0xefff] (256MB) from e820 map Jul 24 00:56:34 debian kernel: e820: remove [mem 0xe000-0xefff] reserved Jul 24 00:56:34 debian kernel: efi: Not removing mem39: MMIO range=[0xfe00-0xfe010fff] (68KB) from e820 map Jul 24 00:56:34 debian kernel: efi: Not removing mem40: MMIO range=[0xfec0-0xfec00fff] (4KB) from e820 map Jul 24 00:56:34 debian kernel: efi: Not removing mem41: MMIO range=[0xfee0-0xfee00fff] (4KB) from e820 map Jul 24 00:56:34 debian kernel: efi: Remove mem42: MMIO range=[0xff00-0x] (16MB) from e820 map Jul 24 00:56:34 debian kernel: e820: remove [mem 0xff00-0x] reserved Jul 24 00:56:34 debian kernel: secureboot: Secure boot disabled Jul 24 00:56:34 debian kernel: SMBIOS 3.1.1 present. Jul 24 00:56:34 debian kernel: DMI: Gigabyte Technology Co., Ltd. B360N GSM/B360N GSM-CF, BIOS F17 12/21/2023 Jul 24 00:56:34 debian kernel: DMI: Memory slots populated: 2/4 Jul 24 00:56:34 debian kernel: tsc: Detected 3700.000 MHz processor Jul 24 00:56:34 debian kernel: tsc: Detected 3699.850 MHz TSC Jul 24 00:56:34 debian kernel: e820: update [mem 0x-0x0fff] usable ==> reserved Jul 24 00:56:34 debian kernel: e820: remove [mem 0x000a-0x000f] usable Jul 24 00:56:34 debian kernel: last_pfn = 0x475000 max_arch_pfn = 0x4 Jul 24 00:56:34 debian kernel: MTRR map: 5 entries (3 fixed + 2 variable; max 23), built from 10 variable MTRRs Jul 24 00:56:34 debian kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT Jul 24 00:56:34 debian kernel: last_pfn = 0x8 max_arch_pfn = 0x4 Jul 24 00:56:34 debian kernel: found SMP MP-table at [mem 0x000fce40-0x000fce4f] Jul 24 00:56:34 debian kernel: esrt: Reserving ESRT space from 0x78329d18 to 0x78329d50. Jul 24 00:56:34 debian kernel: e820: update [mem 0x78329000-0x78329fff] usable ==> reserved Jul 24 00:56:34 debian kernel: Using GB pages for direct mapping Jul 24 00:56:34 debian
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hello Benjamin, On Tue, Jul 22, 2025 at 09:29:02PM -0600, Benjamin Martin wrote: > I ran the this command on both installs, and both are the same, see attached > screen shot. > > If I go in the /lib/firmware/nvidia/gsp/, There are a few differences there, > see attached screenshot. All the rest of the files under tu117 are the same. > > The Fedora folder nvidia has quite a few more folders than the Debian. See > attached. I didn't check in detail, having more files can be beneficial, or not matter at all. The easy and quick test would be: mv /lib/firmware/nvidia /lib/firmware/nvidia.bak cp -a /path/to/fedora/mount/lib/firmware/nvidia /lib/firmware/nvidia update-initramfs -u -k $(uname -r) and then reboot. After the test restore the original /lib/firmware/nvidia to not confuse dpkg. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hello Benjamin, On Mon, Jul 21, 2025 at 10:10:16AM -0600, Benjamin Martin wrote: > Please provide complete file paths to check the firmware files. There are quite a lot, I think the relevant files are: $ /sbin/modinfo nouveau | grep firmware | grep tu117 firmware: nvidia/tu117/acr/ucode_ahesasc.bin firmware: nvidia/tu117/acr/bl.bin firmware: nvidia/tu117/acr/ucode_asb.bin firmware: nvidia/tu117/acr/ucode_unload.bin firmware: nvidia/tu117/acr/unload_bl.bin firmware: nvidia/tu117/nvdec/scrubber.bin firmware: nvidia/tu117/gsp/gsp-535.113.01.bin firmware: nvidia/tu117/gsp/bootloader-535.113.01.bin firmware: nvidia/tu117/gsp/booter_unload-535.113.01.bin firmware: nvidia/tu117/gsp/booter_load-535.113.01.bin firmware: nvidia/tu117/gr/sw_veid_bundle_init.bin firmware: nvidia/tu117/gr/sw_method_init.bin firmware: nvidia/tu117/gr/sw_bundle_init.bin firmware: nvidia/tu117/gr/sw_nonctx.bin firmware: nvidia/tu117/gr/sw_ctx.bin firmware: nvidia/tu117/gr/gpccs_sig.bin firmware: nvidia/tu117/gr/gpccs_data.bin firmware: nvidia/tu117/gr/gpccs_inst.bin firmware: nvidia/tu117/gr/gpccs_bl.bin firmware: nvidia/tu117/gr/fecs_sig.bin firmware: nvidia/tu117/gr/fecs_data.bin firmware: nvidia/tu117/gr/fecs_inst.bin firmware: nvidia/tu117/gr/fecs_bl.bin firmware: nvidia/tu117/sec2/sig.bin firmware: nvidia/tu117/sec2/image.bin firmware: nvidia/tu117/sec2/desc.bin These should be in /lib/firmware. > If I copy /lib/modules/6.15.4-200.fc42.x86_64 from Fedora into Debian's > /lib/modules/, can I use "sudo update-grub" to update the grub boot entry > or do I need to manually edit the entry? I'm not sure if it does the right thing. Certainly it would need copying the kernel to /boot, too and then maybe `update-initramfs -k all -u` does the right thing. If it works that would result in the fedora kernel being booted with Debian firmware files only. Might be worth a try. But my thought was to edit the grub menulist item, in the assumption that your machine has both fedora and Debian installed without swapping harddisks. The above test is maybe more sensible, because when booting the fedora kernel+initramfs with Debian rootfs it's not entirely clear without further checking how relevant the firmware files are that might be in the fedora initramfs. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hi, Please provide complete file paths to check the firmware files. If I copy /lib/modules/6.15.4-200.fc42.x86_64 from Fedora into Debian's /lib/modules/, can I use "sudo update-grub" to update the grub boot entry or do I need to manually edit the entry? regards, Benjamin On 7/21/25 09:50, Uwe Kleine-König wrote: Hello, On Sat, Jul 12, 2025 at 08:51:22PM -0600, Benjamin Martin wrote: Uwe, I tried to run the commands you gave on my Fedora install but was met with errors when running the make commands, I did not try it on my Debian install. Please see attached boot logs of Fedora, and Debian with kernel 6.15 installed. There are 3 boot sessions in the Debian boot log. First was with 2 monitors, 2nd was with all 3 connected (it failed), and 3rd was with 2 connected. Fedora was with all 3 connected. Thanks. For the future can you please use journalctl -b -k to only contain the kernel logs. That makes it a bit easier on the receiving end. Comparing the 2nd Debian log with the fedora one I don't spot the problem. Debian has a message nouveau :01:00.0: pmu: firmware unavailable which might be a hint that the relevant hint is related to firmware. There are a few more differences: Debian has several lines nouveau :01:00.0: i2c: aux 0004: magic wait 8000 and timeout messages: nouveau :01:00.0: sec2:cmdq: timeout waiting for reply nouveau :01:00.0: gr: init failed, -110 nouveau :01:00.0: timeout WARNING: CPU: 2 PID: 932 at drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:841 gf100_gr_fecs_bind_pointer+0x123/0x140 [nouveau] ee1004 wmi_bmof snd_hwdep snd_pcm pcspkr intel_uncore snd_timer snd mei_me mei soundcore intel_pch_thermal raid6_pq joydev intel_pmc_core pmt_telemetry pmt_class intel_vsec acpi_pad evdev sg msr parport_pc ppdev lp parport configfs efi_pstore nfnetlink efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid nouveau uas usb_storage mxm_wmi drm_gpuvm gpu_sched sd_mod drm_ttm_helper ttm drm_exec drm_display_helper cec rc_core drm_client_lib drm_kms_helper ahci libahci xhci_pci libata drm nvme xhci_hcd iTCO_wdt scsi_mod intel_pmc_bxt igb iTCO_vendor_support nvme_core watchdog usbcore i2c_algo_bit e1000e nvme_keyring dca nvme_auth i2c_i801 usb_common video i2c_smbus scsi_common fan wmi button RIP: 0010:gf100_gr_fecs_bind_pointer+0x123/0x140 [nouveau] gf100_grctx_generate+0x2c4/0x720 [nouveau] gf100_gr_chan_new+0x458/0x490 [nouveau] nvkm_cgrp_ectx_get+0x154/0x1e0 [nouveau] nvkm_cgrp_vctx_get+0xf7/0x2b0 [nouveau] nvkm_chan_cctx_get+0x125/0x220 [nouveau] nvkm_uchan_object_new+0xd3/0x1e0 [nouveau] nvkm_ioctl_new+0x141/0x220 [nouveau] ? __pfx_nvkm_uchan_object_new+0x10/0x10 [nouveau] ? __pfx_gf100_gr_object_new+0x10/0x10 [nouveau] nvkm_ioctl+0xbc/0x190 [nouveau] nvif_object_ctor+0x121/0x1a0 [nouveau] nouveau_abi16_ioctl+0x4fa/0x5b0 [nouveau] nouveau_drm_ioctl+0xa2/0xb0 [nouveau] nouveau :01:00.0: gr: failed to construct context nouveau :01:00.0: fifo:00:0003:[Xorg[932]] ectx 0[gr]: -110 nouveau :01:00.0: fifo:00:0003:0003:[Xorg[932]] vctx 0[gr]: -110 Can you please compare the used firmware blobs between Debian and fedora? And maybe try booting the Debian system with the fedora kernel (and vice versa). For the latter I'd copy fedora's /lib/modules/6.15.4-200.fc42.x86_64 into the Debian rootfs and then edit fedora's grub boot entry to use root=UUID=6c47cad0-3157-4246-94b0-1985db645ff0 instead of root=UUID=9445de78-114f-4960-9823-cefaa8824cf1 rootflags=subvol=root resume=UUID=ae6b6cd8-1d85-4f26-b7e6-ce442951cc79 . If you spot a difference in the firmware files it might also be worth to boot Debian with fedora's firmware blobs. Best regards Uwe
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hello, On Sat, Jul 12, 2025 at 08:51:22PM -0600, Benjamin Martin wrote: > Uwe, I tried to run the commands you gave on my Fedora install but was met > with errors when running the make commands, I did not try it on my Debian > install. > > > Please see attached boot logs of Fedora, and Debian with kernel 6.15 > installed. There are 3 boot sessions in the Debian boot log. First was with > 2 monitors, 2nd was with all 3 connected (it failed), and 3rd was with 2 > connected. Fedora was with all 3 connected. Thanks. For the future can you please use journalctl -b -k to only contain the kernel logs. That makes it a bit easier on the receiving end. Comparing the 2nd Debian log with the fedora one I don't spot the problem. Debian has a message nouveau :01:00.0: pmu: firmware unavailable which might be a hint that the relevant hint is related to firmware. There are a few more differences: Debian has several lines nouveau :01:00.0: i2c: aux 0004: magic wait 8000 and timeout messages: nouveau :01:00.0: sec2:cmdq: timeout waiting for reply nouveau :01:00.0: gr: init failed, -110 nouveau :01:00.0: timeout WARNING: CPU: 2 PID: 932 at drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:841 gf100_gr_fecs_bind_pointer+0x123/0x140 [nouveau] ee1004 wmi_bmof snd_hwdep snd_pcm pcspkr intel_uncore snd_timer snd mei_me mei soundcore intel_pch_thermal raid6_pq joydev intel_pmc_core pmt_telemetry pmt_class intel_vsec acpi_pad evdev sg msr parport_pc ppdev lp parport configfs efi_pstore nfnetlink efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid nouveau uas usb_storage mxm_wmi drm_gpuvm gpu_sched sd_mod drm_ttm_helper ttm drm_exec drm_display_helper cec rc_core drm_client_lib drm_kms_helper ahci libahci xhci_pci libata drm nvme xhci_hcd iTCO_wdt scsi_mod intel_pmc_bxt igb iTCO_vendor_support nvme_core watchdog usbcore i2c_algo_bit e1000e nvme_keyring dca nvme_auth i2c_i801 usb_common video i2c_smbus scsi_common fan wmi button RIP: 0010:gf100_gr_fecs_bind_pointer+0x123/0x140 [nouveau] gf100_grctx_generate+0x2c4/0x720 [nouveau] gf100_gr_chan_new+0x458/0x490 [nouveau] nvkm_cgrp_ectx_get+0x154/0x1e0 [nouveau] nvkm_cgrp_vctx_get+0xf7/0x2b0 [nouveau] nvkm_chan_cctx_get+0x125/0x220 [nouveau] nvkm_uchan_object_new+0xd3/0x1e0 [nouveau] nvkm_ioctl_new+0x141/0x220 [nouveau] ? __pfx_nvkm_uchan_object_new+0x10/0x10 [nouveau] ? __pfx_gf100_gr_object_new+0x10/0x10 [nouveau] nvkm_ioctl+0xbc/0x190 [nouveau] nvif_object_ctor+0x121/0x1a0 [nouveau] nouveau_abi16_ioctl+0x4fa/0x5b0 [nouveau] nouveau_drm_ioctl+0xa2/0xb0 [nouveau] nouveau :01:00.0: gr: failed to construct context nouveau :01:00.0: fifo:00:0003:[Xorg[932]] ectx 0[gr]: -110 nouveau :01:00.0: fifo:00:0003:0003:[Xorg[932]] vctx 0[gr]: -110 Can you please compare the used firmware blobs between Debian and fedora? And maybe try booting the Debian system with the fedora kernel (and vice versa). For the latter I'd copy fedora's /lib/modules/6.15.4-200.fc42.x86_64 into the Debian rootfs and then edit fedora's grub boot entry to use root=UUID=6c47cad0-3157-4246-94b0-1985db645ff0 instead of root=UUID=9445de78-114f-4960-9823-cefaa8824cf1 rootflags=subvol=root resume=UUID=ae6b6cd8-1d85-4f26-b7e6-ce442951cc79 . If you spot a difference in the firmware files it might also be worth to boot Debian with fedora's firmware blobs. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Hello Benjamin, On Tue, Jun 24, 2025 at 09:57:04PM -0600, Benjamin Martin wrote: > Please see attached log, this is with the Debian 13 (Trixie), I get the same > results as with Debian 12. With 3 monitors it locks up (just the monitors or > the graphics card, not the computer, I can still login with ssh), and with 2 > monitors it works. It does look like the the error is different in the logs. > I think it is the actual graphics card that is "locking up" because I can > turn off the monitors and turn them on again and they will still display > that same thing as before. The only way to get out of this is to reboot the > computer. > > Boot 1 is at the beginning of the log file and it is with the 3 screens > turned on. > > Boot 2 starts at Jun-24 20:19:25 and is with 2 screens > > I was really hoping that we could get this fixed before Trixie becomes > stable. As I really wanted to update my main computer to Trixie, when it > becomes stable. > > I had one guy look at this problem and he thinks that it is the "plymouth > service" that is causing this problem. He was unable to troubleshoot it any > further as he said it is almost imposible to remove plymouth from Debian and > still have a working system. > > I have tested with the latest Fedora +KDE and all 3 screens works great, no > problems whatsoever. Currently Fedora is using kernel 6.15** But I remember > checking back when Fedora was still on the same kernel version as Trixie and > it was working then as well. > > So this has me believe that it is not in the kernel but something that is > added by Debian. If you want I can send you a boot log from Fedora so that > you can compare it with Debian. That would be great, ideally with similar kernels. Given that Fedora is at 6.15, can you try with Debian's 6.15 kernel from experimental to compare? Also I wouldn't be surprised if userspace also plays a role here. So creating a monolithic kernel for your system and booting that once with Debian and once with Fedora would probably also help. That would be done using something like: git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git cd linux-stable git checkout v6.15.4 cp /boot/config-$(uname -r) arch/x86/configs/my_defconfig make my_defconfig make localmodconfig make localyesconfig make -j 12 make install Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Package: linux-image-6.13.1+debian+tj Followup-For: Bug #1088522 X-Debbugs-Cc: [email protected] Thank-you for the boot logs Benjamin. The 3-monitor log initially confused me since it started with the 2-monitor log and looked identical. Once I'd figured it contained multiple boots and cleaned it I compared differences using: diff -u <( sed -n '/kernel:/ s/^.*kernel: \(nouveau.*\)/\1/p' /tmp/bootlog_2_screens.log ) <( sed -n '/kernel:/ s/^.*kernel: \(nouveau.*\)/\1/p' /tmp/bootlog_3_screens.log ) --- /dev/fd/63 2025-04-03 18:21:05.169414147 +0100 +++ /dev/fd/62 2025-04-03 18:21:05.169414147 +0100 @@ -44,18 +44,303 @@ nouveau :01:00.0: DRM: MM: using COPY for buffer copies nouveau :01:00.0: sec2: cmdq: timeout waiting for queue ready nouveau :01:00.0: gr: init failed, -110 -nouveau :01:00.0: DRM: allocated 2560x1440 fb: 0x20, bo 94c55ef2 +nouveau :01:00.0: DRM: allocated 2560x1440 fb: 0x20, bo afe506a5 nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device nouveau :01:00.0: DRM: Disabling PCI power management to avoid bug nouveau :01:00.0: gr: fecs falcon already acquired by gr! nouveau :01:00.0: gr: init failed, -16 +nouveau :01:00.0: Xorg[734]: failed to idle channel 2 [Xorg[734]] nouveau :01:00.0: gr: fecs falcon already acquired by gr! nouveau :01:00.0: gr: init failed, -16 +nouveau :01:00.0: Xorg[734]: failed to idle channel 2 [Xorg[734]] +nouveau :01:00.0: i2c: aux 0004: magic wait 9000 +nouveau :01:00.0: i2c: aux 0004: magic wait 9000 +nouveau :01:00.0: i2c: aux 0004: magic wait 9000 ... After looking at other logs and reports it seems the "sec2" and "gr" messages are expected for the TU117 models. The important part here is "failed to idle channel 2". Based on my experience using an Nvidia Quadro NVS420 that contains 2 GPUs and has 4 outputs I *think* the channels are paired such that: Channel Pair Monitor 0 1A 1 1B 2 2C 3 2D It may be the case that for the GPU model here there is a problem in operating the second pair (channel 2 in your case). I've skimmed through the nouveau commit history from v6.1 up to current master but could not see anything obvious related to this, but then again the code is extremely complex and covers so many models I suspect it needs someone intimately familiar with the hardware and code to know what to look for. I'd recommend the following in an attempt to narrow down the cause and possibly identify a fix: 1) Test a recent mainline kernel [0] (if building a kernel is a problem maybe try a pre-built kernel from experimental [1]). If the issue is resolved we can try to identify where the fix is either through commit history or a git bisect. Note however even if a fix is found it may not be possible to back-port it to v6.1 since the code has undergone some large recfactors between these versions. 2) Whether or not you can identify a fixed version report this to the nouveau developers via their issue tracker [2] since they're best placed to know what is going on and suggest further steps. I did browse through closed and open reports for something similar that might shed light but the single report there has no follow-up. I was going to recommend reporting to their mailing list [3] as well but, at least for me, their mail archive web-site is unreachable. [0] https://www.kernel.org/ [1] https://tracker.debian.org/pkg/linux [2] https://gitlab.freedesktop.org/drm/nouveau [3] https://lists.freedesktop.org/archives/nouveau/
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Control: tags -1 + moreinfo Hi Benjamin, On Sun, Dec 01, 2024 at 08:59:58PM -0600, Benjamin Martin wrote: > HI, > > Please see bug report 1088524, Its the same but with more information. > > > Please see attached boot log. Thanks for providing the full log. As I understand from the subject this is only aproblem with 3 screens. So if this is correct and with two screens all is green, do boot please with two screens and attach this full boot logs as well for comparision. In meanwhile there is as well newer kernel available, please upgrade to 6.1.129-1 and report back if the problem persist with the nwer kernel as well. Ideally if yes, then testing newer kernel from unstable or experimental would be great to determine if the issue is fixed. Thanks already. Regards,
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Control: tags -1 + moreinfo Hi, On Wed, Nov 27, 2024 at 08:36:35PM -0600, Benjamin Martin wrote: > Package: nouveau > Severity: important > X-Debbugs-Cc: [email protected] > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: 12.8 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-28-amd64 (SMP w/6 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled Could you please provide a full boot log with that? I notice that the kernel is tained with TAINT_OOT_MODULE, so please try to boot without loading of those OOT modules, what is the outcome? Regards, Salvatore
Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
Package: nouveau Severity: important X-Debbugs-Cc: [email protected] Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-28-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
