Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86721 > unrolled thread

Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU Tj <tj.iam.tj@proton.me> - 2025-04-03 20:00 +0200
    Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU Benjamin Martin <benjamin@bmg7.com> - 2025-07-21 18:20 +0200
      Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU Benjamin Martin <benjamin@bmg7.com> - 2025-07-25 03:30 +0200
        Bug#1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU Raymond Burkholder <ray@oneunified.net> - 2025-07-26 06:30 +0200
        Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Tj <tj.iam.tj@proton.me> - 2025-07-26 18:00 +0200
          Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Benjamin Martin <benjamin@bmg7.com> - 2025-07-26 18:20 +0200
            Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Benjamin Martin <benjamin@bmg7.com> - 2025-07-31 01:50 +0200
              Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Benjamin Martin <benjamin@bmg7.com> - 2025-08-06 23:20 +0200
                Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Tj <tj.iam.tj@proton.me> - 2025-08-07 11:10 +0200
                  Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Benjamin Martin <benjamin@bmg7.com> - 2025-08-07 14:10 +0200
                    Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Tj <tj.iam.tj@proton.me> - 2025-08-07 15:40 +0200
                    Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Tj <tj.iam.tj@proton.me> - 2025-08-07 17:20 +0200
                      Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Tj <tj.iam.tj@proton.me> - 2025-08-08 09:30 +0200
                      Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000 Tj <tj.iam.tj@proton.me> - 2025-08-09 00:20 +0200

#86721 — 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: tj.iam.tj@proton.me

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 0000:01:00.0: DRM: MM: using COPY for buffer copies
 nouveau 0000:01:00.0: sec2: cmdq: timeout waiting for queue ready
 nouveau 0000:01:00.0: gr: init failed, -110
-nouveau 0000:01:00.0: DRM: allocated 2560x1440 fb: 0x200000, bo 0000000094c55ef2
+nouveau 0000:01:00.0: DRM: allocated 2560x1440 fb: 0x200000, bo 00000000afe506a5
 nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
 nouveau 0000:01:00.0: DRM: Disabling PCI power management to avoid bug
 nouveau 0000:01:00.0: gr: fecs falcon already acquired by gr!
 nouveau 0000:01:00.0: gr: init failed, -16
+nouveau 0000:01:00.0: Xorg[734]: failed to idle channel 2 [Xorg[734]]
 nouveau 0000:01:00.0: gr: fecs falcon already acquired by gr!
 nouveau 0000:01:00.0: gr: init failed, -16
+nouveau 0000:01:00.0: Xorg[734]: failed to idle channel 2 [Xorg[734]]
+nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00009000
+nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00009000
+nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00009000
...

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       1    A
1       1    B
2       2    C
3       2    D

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/

[toc] | [next] | [standalone]

#88479

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 0000: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 0000:01:00.0: i2c: aux 0004: magic wait 00008000
>
> and timeout messages:
>
> 	nouveau 0000:01:00.0: sec2:cmdq: timeout waiting for reply
>   	nouveau 0000:01:00.0: gr: init failed, -110
> 	nouveau 0000: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 0000:01:00.0: gr: failed to construct context
> 	nouveau 0000:01:00.0: fifo:000000:0003:[Xorg[932]] ectx 0[gr]: -110
> 	nouveau 0000:01:00.0: fifo:000000: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

[toc] | [prev] | [next] | [standalone]

#88539

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.

[toc] | [prev] | [next] | [standalone]

#88549

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.

[toc] | [prev] | [next] | [standalone]

#88550 — 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.

[toc] | [prev] | [next] | [standalone]

#88551 — 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.

[toc] | [prev] | [next] | [standalone]

#88607 — 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.

[toc] | [prev] | [next] | [standalone]

#88689 — 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

[toc] | [prev] | [next] | [standalone]

#88694 — Bug#1088522: nouveau 0000:01:00.0: i2c: aux 0004: magic wait 00008000

On Wednesday, 6 August 2025 at 21:13, Benjamin Martin <benjamin@bmg7.com> 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?

[toc] | [prev] | [next] | [standalone]

#88697 — 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 <benjamin@bmg7.com> 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?

[toc] | [prev] | [next] | [standalone]

#88698 — 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).

[toc] | [prev] | [next] | [standalone]

#88699 — 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 +0000 N Tj config: Debian v6.15.6 enable DRM_NOUVEAU_GSP_DEFAULT
18fc0cd28e807 2025-08-07 13:45:53 +0000 N Tj config: import Debian v6.15.6 config
ca23184e137d6 2025-08-07 13:42:42 +0000 N Tj defconfig: add debian+tj v6.15
30e1edbe28128 2025-08-07 13:42:42 +0000 N Tj ath: add module_param country_default for regulatory domain control
852c7433a5467 2025-08-07 13:42:42 +0000 N Tj cfg80211: suppress regdom warning when phy not ready
39c61beb7d2ec 2025-08-07 13:42:42 +0000 N Tj debian: call linux-update-symlinks from postinst (v6.14+)
9ea18f3b0a5d4 2025-08-07 13:42:42 +0000 N Tj debian: no -dbg package using KDEB_NO_DBG=1
55762f40f581c 2025-08-07 13:42:42 +0000 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

[toc] | [prev] | [next] | [standalone]

#88704 — 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 <u.kleine-koenig@baylibre.com> 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

[toc] | [prev] | [next] | [standalone]

#88711 — 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web