[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).


Reply to: