Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
The fix has been added to v6.16 in experimental and backported to v6.12.40 that will be in trixie-security shortly. I did a fresh install of Trixie on my test drive, and this morning installed security update 6.12.41 and rebooted, everything is working good with the 3 monitors. Thanks again. Benjamin.
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
On Mon, Aug 11, 2025 at 07:16:23PM +, Tj wrote: > On Monday, 11 August 2025 at 16:22, Benjamin Martin wrote: > > 3 monitors > GPU locked up > > Thank-you. That confirms that with just the GSP firmware file unavailable the > driver falls back to its own initialisation functions and we see the same > messages as originally about table A, etc. > > The fix has been added to v6.16 in experimental and backported to v6.12.40 > that will be in trixie-security shortly. I would be interested if the unfixed kernel can be repaired when you have nouveau.config=NvGspRm=1 in the kernel command line. If this is confirmed I'd care to add this info to the help text of CONFIG_DRM_NOUVEAU_GSP_DEFAULT. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
On Monday, 11 August 2025 at 16:22, Benjamin Martin wrote: > 3 monitors > GPU locked up Thank-you. That confirms that with just the GSP firmware file unavailable the driver falls back to its own initialisation functions and we see the same messages as originally about table A, etc. The fix has been added to v6.16 in experimental and backported to v6.12.40 that will be in trixie-security shortly.
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
On Saturday, 9 August 2025 at 03:23, Benjamin Martin wrote: > From what I could tell it still loaded the firmware. The 3 monitors > worked correctly. > > I did a simular test with my Fedora install, see message 112. (I renamed > the nvidia folder .) As you say, the firmware was loaded (thank goodness for my 'firmware loaded' patch): nouveau :01:00.0: Firmware loaded: nvidia/tu117/gsp/gsp-535.113.01.bin I, of course, forgot that the driver and firmware are in the initial ramdisk! So, would you mind repeating the experiment but after confirming the sym-link is broken, as a last step before booting into this kernel doing: $ sudo update-initramfs -u -v -k 6.15.6 Capture and share the kernel log as before and report whether the 3rd output (monitor) was activated. And of course, to undo this deliberate break, after reinstating the firmware file regenerating the initrd again: $ sudo update-initramfs -u -v -k 6.15.6
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
TJ, Please see attached. From what I could tell it still loaded the firmware. The 3 monitors worked correctly. I did a simular test with my Fedora install, see message 112. (I renamed the nvidia folder .) Regards Benjamin Aug 09 02:51:44 debian kernel: Linux version 6.15.6 ([email protected]) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #318 SMP PREEMPT_DYNAMIC Thu Aug 7 14:22:34 UTC 2025 Aug 09 02:51:44 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.15.6 root=UUID=6c47cad0-3157-4246-94b0-1985db645ff0 ro quiet splash Aug 09 02:51:44 debian kernel: BIOS-provided physical RAM map: Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x-0x0005efff] usable Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x0005f000-0x0005] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x0006-0x0009] usable Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x000a-0x000f] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x0010-0x74668fff] usable Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x74669000-0x74669fff] ACPI NVS Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7466a000-0x7466afff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7466b000-0x7dc9efff] usable Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7dc9f000-0x7f148fff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7f149000-0x7f1c5fff] ACPI data Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7f1c6000-0x7f66bfff] ACPI NVS Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7f66c000-0x7fffefff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x7000-0x7fff] usable Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x8000-0x88ff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0xe000-0xefff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0xfe00-0xfe010fff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0xfec0-0xfec00fff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0xfee0-0xfee00fff] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0xff00-0x] reserved Aug 09 02:51:44 debian kernel: BIOS-e820: [mem 0x0001-0x000474ff] usable Aug 09 02:51:44 debian kernel: NX (Execute Disable) protection: active Aug 09 02:51:44 debian kernel: APIC: Static calls initialized Aug 09 02:51:44 debian kernel: efi: EFI v2.7 by American Megatrends Aug 09 02:51:44 debian kernel: efi: ACPI 2.0=0x7f5d1000 ACPI=0x7f5d1000 SMBIOS=0x7fd39000 SMBIOS 3.0=0x7fd38000 ESRT=0x7824af18 MEMATTR=0x77911018 MOKvar=0x7fd5 INITRD=0x74753a98 RNG=0x7f1c5018 Aug 09 02:51:44 debian kernel: random: crng init done Aug 09 02:51:44 debian kernel: efi: Remove mem38: MMIO range=[0xe000-0xefff] (256MB) from e820 map Aug 09 02:51:44 debian kernel: e820: remove [mem 0xe000-0xefff] reserved Aug 09 02:51:44 debian kernel: efi: Not removing mem39: MMIO range=[0xfe00-0xfe010fff] (68KB) from e820 map Aug 09 02:51:44 debian kernel: efi: Not removing mem40: MMIO range=[0xfec0-0xfec00fff] (4KB) from e820 map Aug 09 02:51:44 debian kernel: efi: Not removing mem41: MMIO range=[0xfee0-0xfee00fff] (4KB) from e820 map Aug 09 02:51:44 debian kernel: efi: Remove mem42: MMIO range=[0xff00-0x] (16MB) from e820 map Aug 09 02:51:44 debian kernel: e820: remove [mem 0xff00-0x] reserved Aug 09 02:51:44 debian kernel: SMBIOS 3.1.1 present. Aug 09 02:51:44 debian kernel: DMI: Gigabyte Technology Co., Ltd. B360N GSM/B360N GSM-CF, BIOS F17 12/21/2023 Aug 09 02:51:44 debian kernel: DMI: Memory slots populated: 2/4 Aug 09 02:51:44 debian kernel: tsc: Detected 3700.000 MHz processor Aug 09 02:51:44 debian kernel: tsc: Detected 3699.850 MHz TSC Aug 09 02:51:44 debian kernel: e820: update [mem 0x-0x0fff] usable ==> reserved Aug 09 02:51:44 debian kernel: e820: remove [mem 0x000a-0x000f] usable Aug 09 02:51:44 debian kernel: last_pfn = 0x475000 max_arch_pfn = 0x4 Aug 09 02:51:44 debian kernel: MTRR map: 5 entries (3 fixed + 2 variable; max 23), built from 10 variable MTRRs Aug 09 02:51:44 debian kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT Aug 09 02:51:44 debian kernel: last_pfn = 0x8 max_arch_pfn = 0x4 Aug 09 02:51:44 debian kernel: found SMP MP-table at [mem 0x000fce40-0x000fce4f] Aug 09 02:51:44 debian kernel: esrt: Reserving ESRT space from 0x7824af18 to 0x7824af50. Aug 09 02:51:44 debian kernel: e820: update [mem 0x7824a000-0x7824afff] usable ==> reserved Aug 09 02:51:44 debian kernel: Using GB pages for direct mapping Aug 09 02:51:44 debian kernel: Secure boot disabled Aug 09 02:51:44 debian kernel:
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
Benjamin, could you do a test for us (with my custom kernel build) ?
We want to determine what happens when this option is enabled but the firmware
cannot be found. I tried to determine it from the source-code but there are so
many levels of indirection it will be easier to simply test.
The firmware for TU117 GSP is sym-linked to the TU116, that is in turn
sym-linked to TU102 files. So, to *temporarily, for this test only* prevent
that firmware being found do:
$ sudo mv /usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin{,.disabled}
Then check the tu117 sym-link is now broken:
$ realpath -e /usr/lib/firmware/nvidia/tu117/gsp/gsp-535.113.01.bin
realpath: /usr/lib/firmware/nvidia/tu117/gsp/gsp-535.113.01.bin: No such file
or directory
Reboot and share the kernel log. I'm hoping it falls back to the VBIOSInit
routine and you see the same messages we saw originally, with those "table '*'
not found" messages.
To reinstate the firmware file do:
$ sudo mv /usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin{.disabled,}
$ realpath -e /usr/lib/firmware/nvidia/tu117/gsp/gsp-535.113.01.bin
/usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
On Friday, 8 August 2025 at 05:47, Uwe Kleine-König wrote: > so the TL;DR; of this bug is that we just need to enable > DRM_NOUVEAU_GSP_DEFAULT + maybe take care that the matching firmware is > packaged, right? > > Maybe the same effect can be achieved by using > > nouveau.config=NvGspRm=1 > > on the kernel command-line. Yes, although we should document this and stipulate this will only work for kernel v6.6+ I think we should enable GSP by default as Fedora did [0] for v6.14+ [1]. For firmware-nonfree from what I can see linux-firmware's copy-firmware.sh via WHENCE already installs the correct links for TU117: creating link nvidia/tu117/gsp -> ../tu116/gsp ... creating link nvidia/tu116/gsp/gsp-535.113.01.bin -> ../../tu102/gsp/gsp-535.113.01.bin [0] https://gitlab.com/cki-project/kernel-ark/-/commit/0995cb5643bf77ec1d5ada23e2860d836b9e19b9 [1] https://kojipkgs.fedoraproject.org//packages/kernel/6.14.0/63.fc42/x86_64/kernel-core-6.14.0-63.fc42.x86_64.rpm
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
hello, On Thu, Aug 07, 2025 at 09:25:42PM -0600, Benjamin Martin wrote: > Connected the 3 screens and rebooted and it worked!!! YEA!!! And as soon as > the driver loaded the GPU fan speed slowed down too, just like in Fedora. so the TL;DR; of this bug is that we just need to enable DRM_NOUVEAU_GSP_DEFAULT + maybe take care that the matching firmware is packaged, right? Maybe the same effect can be achieved by using nouveau.config=NvGspRm=1 on the kernel command-line. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
HI, find /lib/firmware/nvidia/tu117 -ls Please see attached file. # this is the vital symbolic link sudo ln -s ../../tu116/gsp/gsp-535.113.01.bin /usr/lib/firmware/nvidia/tu117/gsp/ I got an error on this one saying the file already existed. Now install the kernel with: sudo apt install ./linux-image-6.15.6_6.15.6-318_amd64.deb Once/if we've sorted out the GSP firmware file and required sym-links you can go ahead and boot into this kernel to test. Please report back and share the boot log whether it works or not; e.g: Connected the 3 screens and rebooted and it worked!!! YEA!!! And as soon as the driver loaded the GPU fan speed slowed down too, just like in Fedora. sudo journalctl --dmesg > /tmp/dmesg-v6.15.6+debian_tj.log See attached log. So is this something that can be pushed in an update to the kernel in Trixie? I am not planning to install Trixie right away as my daily runner. So if this could be available in a few months I might just wait till this patch has been applied. Thank you both TJ and Uwe for your time and effort in this. Regards, Benjamin benjamin@fedora:~$ find /lib/firmware/nvidia/tu117 -ls 16943 0 drwxr-xr-x 1 root root 34 Jul 5 21:56 /lib/firmware/nvidia/tu117 16945 0 drwxr-xr-x 1 root root 160 Jul 5 21:56 /lib/firmware/nvidia/tu117/acr 405266 4 lrwxrwxrwx 1 root root 25 Jun 26 18:00 /lib/firmware/nvidia/tu117/acr/bl.bin.xz -> ../../tu116/acr/bl.bin.xz 405267 4 lrwxrwxrwx 1 root root 36 Jun 26 18:00 /lib/firmware/nvidia/tu117/acr/ucode_ahesasc.bin.xz -> ../../tu116/acr/ucode_ahesasc.bin.xz 405268 4 lrwxrwxrwx 1 root root 32 Jun 26 18:00 /lib/firmware/nvidia/tu117/acr/ucode_asb.bin.xz -> ../../tu116/acr/ucode_asb.bin.xz 405269 4 lrwxrwxrwx 1 root root 35 Jun 26 18:00 /lib/firmware/nvidia/tu117/acr/ucode_unload.bin.xz -> ../../tu116/acr/ucode_unload.bin.xz 405270 4 lrwxrwxrwx 1 root root 32 Jun 26 18:00 /lib/firmware/nvidia/tu117/acr/unload_bl.bin.xz -> ../../tu116/acr/unload_bl.bin.xz 16953 0 drwxr-xr-x 1 root root 446 Jul 5 21:56 /lib/firmware/nvidia/tu117/gr 405271 4 lrwxrwxrwx 1 root root 29 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/fecs_bl.bin.xz -> ../../tu116/gr/fecs_bl.bin.xz 405272 4 -rw-r--r-- 1 root root 732 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/fecs_data.bin.xz 405273 16 -rw-r--r-- 1 root root15032 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/fecs_inst.bin.xz 405274 4 -rw-r--r-- 1 root root 172 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/fecs_sig.bin.xz 405275 4 lrwxrwxrwx 1 root root 30 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/gpccs_bl.bin.xz -> ../../tu116/gr/gpccs_bl.bin.xz 405276 4 -rw-r--r-- 1 root root 736 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/gpccs_data.bin.xz 405277 8 -rw-r--r-- 1 root root 6176 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/gpccs_inst.bin.xz 405278 4 -rw-r--r-- 1 root root 172 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/gpccs_sig.bin.xz 405279 4 lrwxrwxrwx 1 root root 36 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/sw_bundle_init.bin.xz -> ../../tu102/gr/sw_bundle_init.bin.xz 405280 4 lrwxrwxrwx 1 root root 28 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/sw_ctx.bin.xz -> ../../tu116/gr/sw_ctx.bin.xz 405281 4 lrwxrwxrwx 1 root root 36 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/sw_method_init.bin.xz -> ../../tu102/gr/sw_method_init.bin.xz 405282 4 lrwxrwxrwx 1 root root 31 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/sw_nonctx.bin.xz -> ../../tu116/gr/sw_nonctx.bin.xz 405283 4 lrwxrwxrwx 1 root root 41 Jun 26 18:00 /lib/firmware/nvidia/tu117/gr/sw_veid_bundle_init.bin.xz -> ../../tu102/gr/sw_veid_bundle_init.bin.xz 16963 0 drwxr-xr-x 1 root root 30 Jul 5 21:56 /lib/firmware/nvidia/tu117/nvdec 405285 4 lrwxrwxrwx 1 root root 33 Jun 26 18:00 /lib/firmware/nvidia/tu117/nvdec/scrubber.bin.xz -> ../../tu116/nvdec/scrubber.bin.xz 16966 0 drwxr-xr-x 1 root root 66 Jul 5 21:56 /lib/firmware/nvidia/tu117/sec2 405286 4 lrwxrwxrwx 1 root root 28 Jun 26 18:00 /lib/firmware/nvidia/tu117/sec2/desc.bin.xz -> ../../tu116/sec2/desc.bin.xz 405287 4 lrwxrwxrwx 1 root root 29 Jun 26 18:00 /lib/firmware/nvidia/tu117/sec2/image.bin.xz -> ../../tu116/sec2/image.bin.xz 405288 4 lrwxrwxrwx 1 root root 27 Jun 26 18:00 /lib/firmware/nvidia/tu117/sec2/sig.bin.xz -> ../../tu116/sec2/sig.bin.xz 405284 4 lrwxrwxrwx 1 root root 12 Jun 26
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
I was attempting to figure out how the Fedora nvidia-gpu-firmware package creates what seem to be sym-links from the various model directories to the single instance of the GSP firmware version file. In the Fedora install can you report what this reports (adjust the path prefix if that file-system is mounted somewhere else) ? find /lib/firmware/nvidia/tu117 -ls I'm expecting to see symbolic links for the gsp.*.bin files to another directory. With this information I can give you instructions on duplicating the layout in the Debian install, but even without it I think this is what you'll need to do (in the running Debian instance): # this may already be installed sudo apt install firmware-nvidia-graphics # this may already exist sudo mkdir --parents /usr/lib/firmware/nvidia/tu117/gsp # this is the vital symbolic link sudo ln -s ../../tu116/gsp/gsp-535.113.01.bin /usr/lib/firmware/nvidia/tu117/gsp/ The kernel build is ready. I've used v6.15.6 with the config patch since it will be easy to compare its log against the Debian v6.15.6 log you've already shared and we can see if it matches the Fedora log of their v6.15.4. Here's confirmation the config option is in this kernel: $ dpkg-deb --fsys-tarfile ../../builds/linux-image-6.15.6_6.15.6-318_amd64.deb | tar -x -f - --to-stdout | grep DRM_NOUVEAU_GSP_DEFAULT CONFIG_DRM_NOUVEAU_GSP_DEFAULT=y The kernel package is in my Proton Drive at: https://drive.proton.me/urls/MN32XF7V30#2v1RKvNvLLUA The sha256.sum file is there also (ffd663ea8fbb33342857279f497f6513fefd5e5127f858e92acf839e054ac081). Download both files to the same directory then do: sha256sum -c sha256.sum That should report: linux-image-6.15.6_6.15.6-318_amd64.deb: OK Now install the kernel with: sudo apt install ./linux-image-6.15.6_6.15.6-318_amd64.deb Once/if we've sorted out the GSP firmware file and required sym-links you can go ahead and boot into this kernel to test. Please report back and share the boot log whether it works or not; e.g: sudo journalctl --dmesg > /tmp/dmesg-v6.15.6+debian_tj.log Note: as well as the Nvidia config change this kernel includes a handful of my own patches that I apply to all my builds. One of them reports all firmware files that are loaded and hopefully - if nouveau is using the firmware loader library - it'll tell us for sure which firmware files are being loaded. The patch stack on top of v6.15.6 mainline in this kernel is: $ git l -n 10 fd77d0df971df 2025-08-07 13:47:07 + N Tj config: Debian v6.15.6 enable DRM_NOUVEAU_GSP_DEFAULT 18fc0cd28e807 2025-08-07 13:45:53 + N Tj config: import Debian v6.15.6 config ca23184e137d6 2025-08-07 13:42:42 + N Tj defconfig: add debian+tj v6.15 30e1edbe28128 2025-08-07 13:42:42 + N Tj ath: add module_param country_default for regulatory domain control 852c7433a5467 2025-08-07 13:42:42 + N Tj cfg80211: suppress regdom warning when phy not ready 39c61beb7d2ec 2025-08-07 13:42:42 + N Tj debian: call linux-update-symlinks from postinst (v6.14+) 9ea18f3b0a5d4 2025-08-07 13:42:42 + N Tj debian: no -dbg package using KDEB_NO_DBG=1 55762f40f581c 2025-08-07 13:42:42 + N Tj firmware: report each loaded firmware file 1562d94823254 2025-07-10 16:08:55 +0200 N Greg Kroah-Hartman Linux 6.15.6 62901034ddc8a 2025-07-10 16:08:55 +0200 N Borislav Petkov (AMD) x86/process: Move the buffer clearing before MONITOR
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
> I can definitely try to build a kernel with a patch, if step by step > instruction are provided or a link to an online tutorial . A .deb > package may be preferred. It'll be easier for me to build it for you. I'll do that once I'm sure we know what we're dealing with. Today I've spent a few hours minutely examining the differences in the logs you provided for v6.15 for Fedora and Debian in message #63, looking for differences in the kernel configs for each, and comparing the source-code between mainline, Fedora and Debian for clues. Since there were no differences in nouveau across all three I worked to understand why the initialisation of the GPU results in different messages between the two distros. In the v6.15 logs Fedora's nouveau does NOT report what Debian does "drm: BIT table 'A' not found" and "drm: BIT table 'A' not found" nor does it report the earlier "pmu: firmware unavailable". I strongly suspect this is because Fedora config sets CONFIG_DRM_NOUVEAU_GSP_DEFAULT=y (and we don't). This tells the driver to use the GPU's system processor to do all the initialisation after loading the requisite firmware. As we see in message #80 Fedora ship "nvidia/tu117/gsp/gsp-535.113.01.bin" whereas in Debian we do not, or if we do, I can't find it ( I can see some gsp*.bin up to tu116, but not tu117 ). I'm going to consult with the other kernel team members on the best way to have you test this and if proved correct what we need to do in our kernel and firmware to fix this, and for which releases. For your testing I think it'll be sufficient to build a kernel with CONFIG_DRM_NOUVEAU_GSP_DEFAULT=y since it should pick up the firmware file provided by Fedora (if you do/have copy/copied it from the Fedora install to Debian).
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
I can definitely try to build a kernel with a patch, if step by step instruction are provided or a link to an online tutorial . A .deb package may be preferred. Would this patch get pushed upstream for testing and then released in a future kernel update? Regards, Benjamin. On 8/7/25 03:04, Tj wrote: On Wednesday, 6 August 2025 at 21:13, Benjamin Martin wrote: Any more info on this bug? I'll do some more investigation and consider a patched kernel. Are you able to build a kernel locally if I provide a patch or would you prefer a binary kernel .deb package? @Uwe: do we have a mechanism to offer 'trusted' custom builds via Debian infrastructure?
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
On Wednesday, 6 August 2025 at 21:13, Benjamin Martin wrote: > Any more info on this bug? I'll do some more investigation and consider a patched kernel. Are you able to build a kernel locally if I provide a patch or would you prefer a binary kernel .deb package? @Uwe: do we have a mechanism to offer 'trusted' custom builds via Debian infrastructure?
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
Hi, Any more info on this bug? Regards, Benjamin On 7/31/25 07:59, Uwe Kleine-König wrote: Hello, On Wed, Jul 30, 2025 at 05:45:01PM -0600, Benjamin Martin wrote: Did you need more information from me or were you working on a custom kernel patch? I have the impression we're in need of someone with a deeper understanding of the nouveau driver. @Tj, do you agree? In that case we should bring this problem to upstream's attention. Best regards Uwe
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
Hello, On Wed, Jul 30, 2025 at 05:45:01PM -0600, Benjamin Martin wrote: > Did you need more information from me or were you working on a custom kernel > patch? I have the impression we're in need of someone with a deeper understanding of the nouveau driver. @Tj, do you agree? In that case we should bring this problem to upstream's attention. Best regards Uwe signature.asc Description: PGP signature
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
Hi, Did you need more information from me or were you working on a custom kernel patch? Regards Benjamin.
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
Hi Tj, This is the GPU >> https://www.techpowerup.com/gpu-specs/t400.c3808 The 3 monitors are : Dell U2722DE connected to DP 1 Dell U2722D connected to DP 2 and 3 All monitors are connected with mini display port to normal display port cables. Both monitors models have DP pass-through, meaning each monitor also has a display port output. (This only works if the GPU supports that, I do not know if my GPU (the Nvidia T400) supports DP pass-through. Best Regards, Benjamin On 7/26/25 09:49, Tj wrote: I've had some time to come back to this now there's a lot of to-and-fro with more data. Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1088522;filename=Debian6.15boot.log;msg=63 that contains three boots: 1. 2 monitors 2. 3 monitors 3. 2 monitors I think the cause is pretty obvious. Nouveau needs to ask the GPU how many outputs it has and query each for monitor capabilities. That is done over i2c. It looks to me as if an incorrect i2c auxiliary channel is being used. I further suspect commit 752a281032b2 may give us a lead to what is going on here. Note its commit message specifically calls out crashing GPUs that have off-chip Display Port. I scanned the bug messages but didn't find any detail about how the monitors are connected (also, some adapters use DP internally but expose the output via HDMI). So let's also get the exact make/model of the GPU adapter.
Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000
I've had some time to come back to this now there's a lot of to-and-fro with more data. Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1088522;filename=Debian6.15boot.log;msg=63 that contains three boots: 1. 2 monitors 2. 3 monitors 3. 2 monitors I think the cause is pretty obvious. Nouveau needs to ask the GPU how many outputs it has and query each for monitor capabilities. That is done over i2c. It looks to me as if an incorrect i2c auxiliary channel is being used. I further suspect commit 752a281032b2 may give us a lead to what is going on here. Note its commit message specifically calls out crashing GPUs that have off-chip Display Port. I scanned the bug messages but didn't find any detail about how the monitors are connected (also, some adapters use DP internally but expose the output via HDMI). So let's also get the exact make/model of the GPU adapter.
