L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Les modules à noyau ouvert de Nvidia arrêtent de compiler sur les noyaux Proxmox 7.0.14-20 et versions ultérieures, et Nvidia a maintenant indiqué publiquement où atterrissait la réparation : une branche de pilote Linux qu’elle appelle 620.xx. Andy Ritger, dont le profil GitHub porte le label d’organisation Nvidia Corporation, a clôturé deux pull request de la communauté le 12 octobre avec presque la même phrase : « Nous avons déjà un correctif équivalent dans notre arborescence, et il devrait être inclus dans nos prochaines versions 620.xx. »
C’est tout ce que Nvidia a dit à propos de la branche. Pas de date de sortie, pas de numéro de version, pas de liste de ce qu’il contient d’autre.
Qu’est-ce qui casse et sur quels noyaux
Le numéro 1433 sur le tracker de module de noyau ouvert de Nvidia, ouvert à 05h55 UTC le 9 octobre et toujours ouvert, rapporte que le pilote 615.71.09 « se construit avec succès sur 7.0.14-19-pve mais ne parvient pas à se compiler sur les deux noyaux les plus récents ». Le journaliste note que les deux noyaux concernés sont « des packages Proxmox officiels, et non des noyaux compilés localement ou des versions candidates », et que l’échec se déclenche lors d’une mise à niveau complète ordinaire d’apt, via le hook DKMS qui reconstruit les modules après un changement de noyau. Le package impliqué est nvidia-kernel-open-dkms 615.71.09-2, du propre référentiel CUDA de Nvidia pour Debian 13.
La cause est un garde qui teste la mauvaise chose. La structure nv_cxl de Nvidia intègre la structure cxl_dev_state du noyau par valeur, mais le code qui l’entoure vérifie uniquement si un en-tête CXL est présent. Proxmox 7.0.14-20 et versions ultérieures fournissent un stub cxl.h qui déclare une fonction et rien d’autre, de sorte que le propre NV_CXL_INIT_SUPPORTED de Nvidia reste correctement indéfini tant que la structure est toujours compilée et que la construction meurt sur un champ avec un type incomplet.
L’un des auteurs a publié une matrice de test à côté du correctif. Sur 7.0.14-19, le stock et les sources corrigées construisent chaque module. Aux niveaux -20, -22 et -23, la source stock échoue avec l’erreur signalée et la source corrigée construit les cinq modules sans erreur.
Fermé car déjà réparé, pas refusé
Deux personnes ont écrit des correctifs indépendamment et aucune n’a été fusionnée. La pull request 1435, ouverte le 9 octobre, modifie la façon dont les champs nv_cxl sont générés. La pull request 1438, ouverte le 10 octobre, remplace le test de présence d’en-tête par celui de NV_CXL_INIT_SUPPORTED. Ritger a fermé 14h38 à 06h02 UTC et 14h35 à 21h30 UTC le 12 octobre, remerciant les deux auteurs et notant que le second était « presque identique » au premier.
Aucune des deux réponses ne conteste le diagnostic ou le patch. L’expression qui fait le travail est « notre arbre », qui n’est pas le référentiel dans lequel les auteurs ont écrit, donc le correctif existe quelque part que ces contributeurs ne peuvent pas voir et le code devant eux n’est pas le code qui sera livré. Nvidia répond ainsi le plus souvent à ses trackers publics, et le quatrième numéro de bug interne enregistré contre le blocage de Xid 109 le 8 octobre est un travail que personne en dehors de Nvidia ne peut suivre non plus.
Rien de ce que vous pouvez installer ne le porte
La dernière version publiée du module Linux à noyau ouvert par Nvidia est la 615.78.08, sortie le 7 octobre, et il s’agit d’une version 615 plutôt que d’une version 620. Une famille de branches n’est pas une version, il n’y a donc aucun numéro à surveiller ni aucune date qui lui est attachée.
Ce qui laisse à un utilisateur de Proxmox les deux correctifs fermés par Nvidia sans fusion, ou le noyau 7.0.14-19 sur lequel la source de stock est toujours construite, jusqu’à ce que quelque chose de 620.xx apparaisse réellement.