En résumé, à date d'aujourd'hui :
- L'arrêt de l'AER permet de masquer le problème. Il est possible de masquer le problème au plus proche de la source en masquant le reporting des erreurs "Correctable", Ca se fait en passant de 1 à 0 le bit 1 dans le registre CI_ERR_ROOT_COMMAND. Ce registre est à la position 44 decimal (0x2c hexa) dans la capability ECAP_AER. Ce registre est sur 4 octets (long). Exemple :
sudo setpci -v -d 8086:9d15 ECAP_AER+0x2c.l=0x06
8086:9d15 est l'adresse du port pci sur lequel est connecté le module qui pose problème (le module WIFI dans notre cas). Elle se trouve avec un
sudo lshw -numeric
- Il y a une interaction avec l'ASPM du module WIFI. Il faudrait voir sur la configuration du module et non pas celle du bridge PCI. Pas plus d'information sur ce sujet. La désactivation de l'ASPM du bridge empire le problème des erreurs (fréquence plus importante)
- Maintenant, il faut automatiser l’exécution de cette commande dans
systemctl
Pour intervenir sur les machines des personnes qu'on aide, il est préférable de rester au niveau des paramètres du noyau passés par GRUB, c'est beaucoup plus simple. le paramètre dans grub pci=noaer est celui qui est le plus approprié, pcie_asmp=off désactive également l'AER. Il corrige ou intervient peut être sur la source, mais ce n'est pas prouvé.
Pour info :
sudo setpci -v -d 8086:9d15 ECAP_AER+0x2c.l
retourne
0000:00:1c.5 (ecap 0001 @100) @12c = 00000000
quand pcie_aspm=off est activé. Donc ce paramètre arrête l'AER! (la valeur est
0000000f lorsque l'AER est actif
AJOUT :
J'ai complété l'essai, avec le paramètre pcie_aspm=off, en réactivant le report d'erreur et l'AER, sans que les messages pcieport... ne réapparaissent. Conclusion : l'ASPM a bien un rôle, elle intervient probablement au niveau du module en lui même et non pas au niveau du bridge pci.
FIN AJOUT
En cherchant sur l'erreur rencontré par Naziel, j'ai suivi le lien donné par xubu et je suis tombé sur ceci :
https://github.com/lwfinger/rtlwifi_new/issues/317
Sur les noyaux 4.4, il faut utiliser le github de lwfinger. Par contre, sur les noyaux récents, il dit clairement que le driver ce situe dans le noyau et qu'il ne faut pas utiliser le sien. (Commentaire du 21 Fevrier 2018, dans le lien ci-dessus)
