Open-gpu-kernel-modules - Historique des versions

Admin le 7 août 2026 à 16:40

2026-08-07T16:40:04Z

← Version précédente		Version du 7 août 2026 à 16:40
Ligne 1 :		Ligne 1 :
	[https://github.com/aikitoria/open-gpu-kernel-modules Source].		[https://github.com/aikitoria/open-gpu-kernel-modules Source].
	== Prérequis ==		== Prérequis ==
	* ~~Un ou plusieurs~~ GPU NVIDIA grand public dont la fonction P2P est désactivée par le pilote (architecture Turing ou plus récente).		* Au moins deux GPU NVIDIA grand public dont la fonction P2P est désactivée par le pilote officiel et prise en charge par le pilote modifié (architecture Turing ou plus récente). Il est recommandé d'utiliser des GPU de même architecture ou de même génération.
	* Recommandé : activer l’option <code>Above 4G Decoding</code> dans le BIOS de la carte mère, particulièrement avec plusieurs GPU. Activer également <code>Resizable BAR</code> si la plateforme le permet.		* Recommandé : activer l’option <code>Above 4G Decoding</code> dans le BIOS de la carte mère, particulièrement avec plusieurs GPU. Activer également <code>Resizable BAR</code> si la plateforme le permet.
	* Recommandé : utiliser un démarrage en mode <code>UEFI</code> et désactiver le <code>CSM</code>. Cette configuration facilite la gestion de plusieurs GPU, l’allocation des ressources PCIe au-dessus de 4 Gio via <code>Above 4G Decoding</code> et l’utilisation éventuelle de <code>Resizable BAR</code>		* Recommandé : utiliser un démarrage en mode <code>UEFI</code> et désactiver le <code>CSM</code>. Cette configuration facilite la gestion de plusieurs GPU, l’allocation des ressources PCIe au-dessus de 4 Gio via <code>Above 4G Decoding</code> et l’utilisation éventuelle de <code>Resizable BAR</code>

Admin : /* Vérification de l'installation */

2026-08-07T10:24:56Z

Vérification de l'installation

← Version précédente		Version du 7 août 2026 à 10:24
Ligne 141 :		Ligne 141 :
	# reboot		# reboot
	== Vérification de l'installation ==		== Vérification de l'installation ==
	* On ~~test si~~ le ~~p2p~~ est bien activé :
			* On vérifie que le P2P est bien activé en lecture et en écriture :
	# nvidia-smi topo -p2p r		# nvidia-smi topo -p2p r
	# nvidia-smi topo -p2p w		# nvidia-smi topo -p2p w

	Exemple de résultat avec deux GPU :		Exemple de résultat avec deux GPU :
	GPU0 GPU1		GPU0 GPU1
	GPU0 X <font color="blue">OK</font>		GPU0 X <font color="blue">OK</font>
	GPU1 <font color="blue">OK</font> X		GPU1 <font color="blue">OK</font> X

			La valeur <font color="blue">OK</font> entre les GPU indique que le P2P est disponible dans les deux sens.

			=== Benchmark CUDA ===

	* On peut installer les outils de benchmark CUDA. Le CUDA Toolkit doit être installé au préalable :		* On peut installer les outils de benchmark CUDA. Le CUDA Toolkit doit être installé au préalable :
	# cd /opt		# cd /opt
Ligne 156 :		Ligne 163 :
	# cmake -S . -B build -DCMAKE_CUDA_COMPILER=/usr/local/cuda-<font color="blue">13.3</font>/bin/nvcc		# cmake -S . -B build -DCMAKE_CUDA_COMPILER=/usr/local/cuda-<font color="blue">13.3</font>/bin/nvcc
	# cmake --build build --target p2pBandwidthLatencyTest -j$(nproc)		# cmake --build build --target p2pBandwidthLatencyTest -j$(nproc)

			La version <font color="blue">13.3</font> est à adapter à la version du CUDA Toolkit installée.

	Puis on lance le benchmark :		Puis on lance le benchmark :
	# /opt/cuda-samples/build/cpp/5_Domain_Specific/p2pBandwidthLatencyTest/p2pBandwidthLatencyTest		# /opt/cuda-samples/build/cpp/5_Domain_Specific/p2pBandwidthLatencyTest/p2pBandwidthLatencyTest

	Exemple de résultat :		Exemple de résultat :
	P2P Connectivity Matrix		P2P Connectivity Matrix
Ligne 195 :		Ligne 206 :
	0 1.92 1.31		0 1.92 1.31
	1 1.35 1.66		1 1.35 1.66
	~~Les chiffres utiles (analyse ChatGPT) :~~

	~~Unidirectionnel~~		Dans cet exemple, avec deux RTX 3060 reliées en PCIe 3.0 x8/x8 :
	* sans P2P : ~3~~.14–3.~~15 GB/s
	* avec P2P : 6.60 GB/s		* '''Bande passante unidirectionnelle GPU à GPU''' :
	soit environ ×2,1		** sans P2P : environ 3,14 à 3,15 GB/s ;
	~~Bidirectionnel~~		** avec P2P : 6,60 GB/s ;
	* sans P2P : ~4.6 GB/s		** soit un gain d'environ ×2,1.
	* avec P2P : 12.47 GB/s
	soit environ ×2,7		* '''Bande passante bidirectionnelle GPU à GPU''' :
	Latence ~~GPU→GPU~~		** sans P2P : environ 4,6 GB/s ;
	* sans P2P : ~~~12–15~~ µs		** avec P2P : 12,47 GB/s ;
	* avec P2P : ~0.8 µs		** soit un gain d'environ ×2,7.
	~~donc~~ une réduction ~~énorme,~~ de ~~l’ordre~~ de ~~15–18×~~
			* '''Latence GPU à GPU''' :
			** sans P2P : environ 12 à 15 µs ;
			** avec P2P : environ 0,8 µs ;
			** soit une réduction de la latence d'environ ×15 à ×18.

			{{Méta bandeau
			\| niveau = information
			\| icône = information
			\| texte =
			Le programme <code>p2pBandwidthLatencyTest</code> permet surtout de vérifier le fonctionnement du P2P et de comparer les transferts avec et sans accès direct. NVIDIA précise que les CUDA Samples ne sont pas destinés à fournir des mesures de performances absolues.
			}}

			=== Benchmark avec BeelLlama ===

			Exemple de benchmark réel avec deux RTX 3060 12 Go limitées à 140 W.

	~~Exemple de benchmark réel via Beellama sur 2 gpu RTX 3060 12GB bridé à 140w :~~		* Sans P2P :
	* Sans ~~p2p~~ :
	# /opt/beellama.cpp/build/bin/llama-bench -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -sm tensor -ts 1/1 -t 4 -b 1024 -ub 1024 -fa on --load-mode none -ctk kvarn6 -ctv kvarn6 --kv-tail-tokens 1024 -p 65536 -n 256 -r 5		# /opt/beellama.cpp/build/bin/llama-bench -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -sm tensor -ts 1/1 -t 4 -b 1024 -ub 1024 -fa on --load-mode none -ctk kvarn6 -ctv kvarn6 --kv-tail-tokens 1024 -p 65536 -n 256 -r 5
	* ~~avec p2p~~ :
			* Avec P2P :
	# GGML_CUDA_P2P=1 /opt/beellama.cpp/build/bin/llama-bench -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -sm tensor -ts 1/1 -t 4 -b 1024 -ub 1024 -fa on --load-mode none -ctk kvarn6 -ctv kvarn6 --kv-tail-tokens 1024 -p 65536 -n 256 -r 5		# GGML_CUDA_P2P=1 /opt/beellama.cpp/build/bin/llama-bench -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -sm tensor -ts 1/1 -t 4 -b 1024 -ub 1024 -fa on --load-mode none -ctk kvarn6 -ctv kvarn6 --kv-tail-tokens 1024 -p 65536 -n 256 -r 5

	-> ~~Le gain existe~~, ~~mais il est faible dans llama~~-~~bench :~~		Résultats :

			{\| class="wikitable"
			! Test
			! Sans P2P
			! Avec P2P
			! Gain
			\|-
			\| <code>pp65536</code>
			\| 558,19 t/s
			\| 560,92 t/s
			\| +0,49 %
			\|-
			\| <code>tg256</code>
			\| 28,35 t/s
			\| 28,45 t/s
			\| +0,35 %
			\|}

	~~Test Sans P2P Avec P2P Gain~~		Le gain dans <code>llama-bench</code> reste donc faible sur cette configuration à deux GPU, malgré l'amélioration importante de la bande passante et de la latence mesurée par le benchmark CUDA. Cela indique que les transferts GPU à GPU ne constituent pas ici le principal facteur limitant.
	~~pp65536 558.19 t/s 560.92 t~~/~~s +0~~,~~49 %~~
	~~tg256 28~~.~~35 t/s 28~~.~~45 t/s +0,35 %~~

	~~Le p2p devrait donner~~ de ~~meilleur résultat avec un~~ switch PCIe de type PLX.		Avec davantage de GPU, notamment lorsqu'ils sont reliés au même switch PCIe de type PLX, l'intérêt du P2P peut devenir plus important : une partie des échanges GPU à GPU peut alors rester à l'intérieur du switch PCIe au lieu de transiter par la mémoire système. Le gain réel dépend cependant du logiciel, du mode de répartition utilisé et de la topologie PCIe.

Admin : /* Vérification de l'installation */

2026-08-07T10:22:35Z

Vérification de l'installation

← Version précédente		Version du 7 août 2026 à 10:22
Ligne 158 :		Ligne 158 :
	Puis on lance le benchmark :		Puis on lance le benchmark :
	# /opt/cuda-samples/build/cpp/5_Domain_Specific/p2pBandwidthLatencyTest/p2pBandwidthLatencyTest		# /opt/cuda-samples/build/cpp/5_Domain_Specific/p2pBandwidthLatencyTest/p2pBandwidthLatencyTest
			Exemple de résultat :
			P2P Connectivity Matrix
			D\D 0 1
			0 1 1
			1 1 1
			Unidirectional P2P=Disabled Bandwidth Matrix (GB/s)
			D\D 0 1
			0 331.67 3.14
			1 3.15 333.23
			Unidirectional P2P=Enabled Bandwidth (P2P Writes) Matrix (GB/s)
			D\D 0 1
			0 303.04 6.60
			1 6.60 333.44
			Bidirectional P2P=Disabled Bandwidth Matrix (GB/s)
			D\D 0 1
			0 317.19 4.63
			1 4.60 333.87
			Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
			D\D 0 1
			0 317.38 12.47
			1 12.47 334.05
			P2P=Disabled Latency Matrix (us)
			GPU 0 1
			0 1.38 14.76
			1 12.29 1.35

			CPU 0 1
			0 1.62 4.69
			1 4.38 1.57
			P2P=Enabled Latency (P2P Writes) Matrix (us)
			GPU 0 1
			0 1.38 0.82
			1 0.80 1.34

			CPU 0 1
			0 1.92 1.31
			1 1.35 1.66
			Les chiffres utiles (analyse ChatGPT) :

			Unidirectionnel
			* sans P2P : ~3.14–3.15 GB/s
			* avec P2P : 6.60 GB/s
			soit environ ×2,1
			Bidirectionnel
			* sans P2P : ~4.6 GB/s
			* avec P2P : 12.47 GB/s
			soit environ ×2,7
			Latence GPU→GPU
			* sans P2P : ~12–15 µs
			* avec P2P : ~0.8 µs
			donc une réduction énorme, de l’ordre de 15–18×

			Exemple de benchmark réel via Beellama sur 2 gpu RTX 3060 12GB bridé à 140w :
			* Sans p2p :
			# /opt/beellama.cpp/build/bin/llama-bench -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -sm tensor -ts 1/1 -t 4 -b 1024 -ub 1024 -fa on --load-mode none -ctk kvarn6 -ctv kvarn6 --kv-tail-tokens 1024 -p 65536 -n 256 -r 5
			* avec p2p :
			# GGML_CUDA_P2P=1 /opt/beellama.cpp/build/bin/llama-bench -m /opt/models/Qwen3.6-27B-MTP-GGUF/UD-Q4_K_XL/Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -sm tensor -ts 1/1 -t 4 -b 1024 -ub 1024 -fa on --load-mode none -ctk kvarn6 -ctv kvarn6 --kv-tail-tokens 1024 -p 65536 -n 256 -r 5

			-> Le gain existe, mais il est faible dans llama-bench :

			Test Sans P2P Avec P2P Gain
			pp65536 558.19 t/s 560.92 t/s +0,49 %
			tg256 28.35 t/s 28.45 t/s +0,35 %

			Le p2p devrait donner de meilleur résultat avec un switch PCIe de type PLX.

Admin le 7 août 2026 à 09:41

2026-08-07T09:41:29Z

← Version précédente		Version du 7 août 2026 à 09:41
Ligne 140 :		Ligne 140 :

	# reboot		# reboot
			== Vérification de l'installation ==
			* On test si le p2p est bien activé :
			# nvidia-smi topo -p2p r
			# nvidia-smi topo -p2p w
			Exemple de résultat avec deux GPU :
			GPU0 GPU1
			GPU0 X <font color="blue">OK</font>
			GPU1 <font color="blue">OK</font> X
			* On peut installer les outils de benchmark CUDA. Le CUDA Toolkit doit être installé au préalable :
			# cd /opt
			# git clone <nowiki>https://</nowiki>github.com/NVIDIA/cuda-samples.git
			# cd /opt/cuda-samples
			# export PATH=/usr/local/cuda-<font color="blue">13.3</font>/bin:$PATH
			# export LD_LIBRARY_PATH=/usr/local/cuda-<font color="blue">13.3</font>/lib64:${LD_LIBRARY_PATH}
			# cmake -S . -B build -DCMAKE_CUDA_COMPILER=/usr/local/cuda-<font color="blue">13.3</font>/bin/nvcc
			# cmake --build build --target p2pBandwidthLatencyTest -j$(nproc)
			Puis on lance le benchmark :
			# /opt/cuda-samples/build/cpp/5_Domain_Specific/p2pBandwidthLatencyTest/p2pBandwidthLatencyTest

Admin : /* Pilote NVIDIA */

2026-08-07T09:20:12Z

Pilote NVIDIA

@@ Ligne 113 : / Ligne 113 : @@
 Lors du choix du type de module noyau, sélectionner la version <code>MIT/GPL</code> (Open Kernel Modules).
 === Installation du projet ===
 On clone le dépôt dans <code>/opt</code> :

Admin : /* Installation du projet */

2026-08-07T09:09:01Z

Installation du projet

← Version précédente		Version du 7 août 2026 à 09:09
Ligne 117 :		Ligne 117 :

	# cd /opt		# cd /opt
	# git clone https://github.com/aikitoria/open-gpu-kernel-modules.git		# git clone <nowiki>https://</nowiki>github.com/aikitoria/open-gpu-kernel-modules.git
	# cd open-gpu-kernel-modules		# cd open-gpu-kernel-modules

Admin le 7 août 2026 à 09:08

2026-08-07T09:08:41Z

@@ Ligne 1 : / Ligne 1 : @@
 [https://github.com/aikitoria/open-gpu-kernel-modules Source].
 == Prérequis ==
-* Un ou plusieurs GPU NVIDIA grand public dont la fonction P2P est désactivée par le pilote.
+* Un ou plusieurs GPU NVIDIA grand public dont la fonction P2P est désactivée par le pilote (architecture Turing ou plus récente).
 * Recommandé : activer l’option <code>Above 4G Decoding</code> dans le BIOS de la carte mère, particulièrement avec plusieurs GPU. Activer également <code>Resizable BAR</code> si la plateforme le permet.
 * Recommandé : utiliser un démarrage en mode <code>UEFI</code> et désactiver le <code>CSM</code>. Cette configuration facilite la gestion de plusieurs GPU, l’allocation des ressources PCIe au-dessus de 4 Gio via <code>Above 4G Decoding</code> et l’utilisation éventuelle de <code>Resizable BAR</code>
@@ Ligne 102 : / Ligne 102 : @@
 Si ACS est présent, les indicateurs <code>ReqRedir</code> et <code>CmpltRedir</code> doivent désormais apparaître désactivés (<code>-</code>).

Admin : /* Recommandé : désactiver ACS sur les ports PCIe concernés */

2026-08-07T08:45:12Z

Recommandé : désactiver ACS sur les ports PCIe concernés

← Version précédente		Version du 7 août 2026 à 08:45
Ligne 29 :		Ligne 29 :
	# cat /proc/cmdline		# cat /proc/cmdline

	=== Recommandé : désactiver ACS sur les ports PCIe concernés ===		=== Recommandé : vérifier et désactiver ACS sur les ports PCIe concernés ===

	Lorsque l’ACS est activé sur les ports racine, le trafic GPU à GPU peut être redirigé vers le complexe racine du processeur, ce qui réduit fortement la bande passante P2P.		Lorsque l’ACS est activé sur les ports racine ou les bridges PCIe, le trafic GPU à GPU peut être redirigé vers le complexe racine du processeur, ce qui réduit fortement la bande passante P2P.

	~~==== Via le BIOS ====~~		Tous les ports PCIe n’exposent cependant pas nécessairement ACS. Il faut donc commencer par identifier les ports utilisés par les GPU, puis vérifier si ACS est présent et actif sur ceux-ci.

	~~Certaines cartes mères permettent de désactiver directement l’ACS sur~~ les ports PCIe ~~depuis le BIOS~~. ~~Lorsqu’elle est disponible~~, ~~cette méthode~~ est ~~à privilégier~~.

	~~==== Via le noyau Linux ====~~

	~~Le noyau Linux permet de désactiver~~ les ~~fonctions de redirection ACS sur des~~ ports PCIe ~~précis avec l’option <code>pci~~=~~disable_acs_redir~~=~~</code>. Cette méthode est disponible avec le noyau Debian standard et ne nécessite pas de patch.~~		==== Identifier les ports PCIe utilisés par les GPU ====

	* On ~~commence par identifier le ou les ports~~ PCIe ~~concernés~~ :		* On affiche la topologie PCIe :
	# lspci -tv		# lspci -tv

Ligne 53 :		Ligne 49 :
	<font color = grey>...</font>		<font color = grey>...</font>

	~~Les~~ deux ports PCIe ~~à modifier seront donc~~ <code>0000:00:01.0</code> et <code>0000:00:01.1</code>.		Dans cet exemple, les deux GPU sont respectivement connectés aux ports PCIe <code>0000:00:01.0</code> et <code>0000:00:01.1</code>.

			==== Vérifier l’état d’ACS ====

			* On vérifie si les ports concernés exposent ACS :
			# lspci -s 0000:00:01.0 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'
			# lspci -s 0000:00:01.1 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'

			Si aucune ligne n’est retournée, le port concerné n’expose pas ACS et aucune modification n’est nécessaire.

			Si ACS est présent, une sortie de ce type peut apparaître :

			Capabilities: [140 v1] Access Control Services
			ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd- EgressCtrl- DirectTrans-
			ACSCtl: SrcValid+ TransBlk- ReqRedir+ CmpltRedir+ UpstreamFwd- EgressCtrl- DirectTrans-

			Les indicateurs <code>ReqRedir+</code> et <code>CmpltRedir+</code> indiquent que les fonctions de redirection ACS sont activées.

			Si ces indicateurs sont actifs sur un port situé sur le chemin entre les GPU, il est recommandé de désactiver la redirection ACS.

			==== Via le BIOS ====

			Certaines cartes mères permettent de désactiver directement ACS sur les ports PCIe depuis le BIOS. Lorsqu’elle est disponible, cette méthode est à privilégier.

			==== Via le noyau Linux ====

			Le noyau Linux permet de désactiver les fonctions de redirection ACS sur des ports PCIe précis avec l’option <code>pci=disable_acs_redir=</code>. Cette méthode est disponible avec le noyau Debian standard et ne nécessite pas de patch.

	* On édite GRUB :		* On édite GRUB :
Ligne 63 :		Ligne 85 :
	GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt</font> pci=disable_acs_redir=0000:00:01.0;0000:00:01.1<font color="grey">"		GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt</font> pci=disable_acs_redir=0000:00:01.0;0000:00:01.1<font color="grey">"
	...</font>		...</font>

			Plusieurs ports peuvent être indiqués en les séparant par un point-virgule.

	* On met à jour GRUB :		* On met à jour GRUB :
Ligne 73 :		Ligne 97 :
	# cat /proc/cmdline		# cat /proc/cmdline

	* On vérifie ensuite ~~si les~~ ports concernés ~~exposent ACS et, le cas échéant, l’état de ses fonctions de redirection~~ :		* On vérifie ensuite à nouveau l’état ACS des ports concernés :
	# lspci -s 0000:00:01.0 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'		# lspci -s 0000:00:01.0 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'
	# lspci -s 0000:00:01.1 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'		# lspci -s 0000:00:01.1 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'

	~~Si aucune ligne n’est retournée, le port concerné n’expose pas ACS et il n’y a rien à désactiver sur celui-ci.~~		Si ACS est présent, les indicateurs <code>ReqRedir</code> et <code>CmpltRedir</code> doivent désormais apparaître désactivés (<code>-</code>).

	Si ACS est présent, les indicateurs <code>ReqRedir</code> et <code>CmpltRedir</code> doivent apparaître désactivés (<code>-</code>) ~~après application de l’option~~.

Admin : /* Via le noyau Linux */

2026-08-07T08:39:53Z

Via le noyau Linux

← Version précédente		Version du 7 août 2026 à 08:39
Ligne 73 :		Ligne 73 :
	# cat /proc/cmdline		# cat /proc/cmdline

	* On vérifie ensuite ~~l’état ACS des~~ ports concernés :		* On vérifie ensuite si les ports concernés exposent ACS et, le cas échéant, l’état de ses fonctions de redirection :
	# lspci -s 0000:00:01.0 -vv \| grep -E 'ACSCap\|ACSCtl'		# lspci -s 0000:00:01.0 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'
	# lspci -s 0000:00:01.1 -vv \| grep -E 'ACSCap\|ACSCtl'		# lspci -s 0000:00:01.1 -vv \| grep -E 'Access Control Services\|ACSCap\|ACSCtl'

	~~Les~~ indicateurs <code>ReqRedir</code> et <code>CmpltRedir</code> doivent apparaître désactivés (<code>-</code>).		Si aucune ligne n’est retournée, le port concerné n’expose pas ACS et il n’y a rien à désactiver sur celui-ci.

			Si ACS est présent, les indicateurs <code>ReqRedir</code> et <code>CmpltRedir</code> doivent apparaître désactivés (<code>-</code>) après application de l’option.

Admin : /* Prérequis */

2026-08-07T08:33:45Z

Prérequis

← Version précédente		Version du 7 août 2026 à 08:33
Ligne 36 :		Ligne 36 :

	Certaines cartes mères permettent de désactiver directement l’ACS sur les ports PCIe depuis le BIOS. Lorsqu’elle est disponible, cette méthode est à privilégier.		Certaines cartes mères permettent de désactiver directement l’ACS sur les ports PCIe depuis le BIOS. Lorsqu’elle est disponible, cette méthode est à privilégier.

			==== Via le noyau Linux ====

			Le noyau Linux permet de désactiver les fonctions de redirection ACS sur des ports PCIe précis avec l’option <code>pci=disable_acs_redir=</code>. Cette méthode est disponible avec le noyau Debian standard et ne nécessite pas de patch.

			* On commence par identifier le ou les ports PCIe concernés :
			# lspci -tv

			Exemple de résultat :
			<font color = grey>...</font>
			-[<font color = blue>0000:00</font>]-+-00.0 Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers
			+-<font color = blue>01.0</font>-[01]--+-00.0 NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate]
			\| \-00.1 NVIDIA Corporation GA106 High Definition Audio Controller
			+-<font color = blue>01.1</font>-[02]--+-00.0 NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate]
			\| \-00.1 NVIDIA Corporation GA106 High Definition Audio Controller
			<font color = grey>...</font>

			Les deux ports PCIe à modifier seront donc <code>0000:00:01.0</code> et <code>0000:00:01.1</code>.

			* On édite GRUB :
			# vi /etc/default/grub

			On ajoute à la variable <code>GRUB_CMDLINE_LINUX_DEFAULT</code> l’option <code>pci=disable_acs_redir=</code> suivie de l’adresse des ports PCIe concernés :

			<font color="grey">...
			GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt</font> pci=disable_acs_redir=0000:00:01.0;0000:00:01.1<font color="grey">"
			...</font>

			* On met à jour GRUB :
			# update-grub

			* On redémarre :
			# reboot

			* Après redémarrage, on vérifie que l’option a bien été appliquée :
			# cat /proc/cmdline

			* On vérifie ensuite l’état ACS des ports concernés :
			# lspci -s 0000:00:01.0 -vv \| grep -E 'ACSCap\|ACSCtl'
			# lspci -s 0000:00:01.1 -vv \| grep -E 'ACSCap\|ACSCtl'

			Les indicateurs <code>ReqRedir</code> et <code>CmpltRedir</code> doivent apparaître désactivés (<code>-</code>).

Open-gpu-kernel-modules - Historique des versions

Admin le 7 août 2026 à 16:40

Admin : /* Vérification de l'installation */

Admin : /* Vérification de l'installation */

Admin le 7 août 2026 à 09:41

Admin : /* Pilote NVIDIA */

Admin : /* Installation du projet */

Admin le 7 août 2026 à 09:08

Admin : /* Recommandé : désactiver ACS sur les ports PCIe concernés */

Admin : /* Via le noyau Linux */

Admin : /* Prérequis */

Admin : /* Vérification de l'installation */

Admin : /* Vérification de l'installation */

Admin : /* Pilote NVIDIA */

Admin : /* Installation du projet */

Admin : /* Recommandé : désactiver ACS sur les ports PCIe concernés */

Admin : /* Via le noyau Linux */

Admin : /* Prérequis */