Archlinux.fr [Forums]

Bonjour,

Lors de l'installation d'une nouvelle machine (clevo de chez Why!), j'ai l'erreur suivante qui apparait sans arrêt, que ce soit avec l'iso sur USB ou après le redémarrage.
J'ai bien sûr "qwanté" la chose, et les solutions apportées m'ont laissé les bras pendants...

Problème matériel ? Ou de pilote ? Dans ce cas, comment fais-je pour les charger sur l'iso ?

Il y a déjà un post sur le sujet ici, mais le boot était bloquant, ce qui n'est pas le cas chez moi. Et aucune solution n'est donnée. Enfin peut être le pcie_aspm=off, mais je ne sais pas où je devrais le mettre au démarrage de l'iso...

Avec tous mes remerciements pour m'avoir lu jusque là...

PS. je ne savais pas trop où mettre ce post, installation, réseau, matériel ??

Bonjour,
Démarre avec l'option noaer ajouté à la ligne de paramètres du noyau linux.

Bonjour, merci beaucoup pour la réponse.

En fait, j'ai l'impression qu'il y a encore plus d'erreurs

Il m'a fallu un moment pour comprendre où le mettre Pour ceux qui passeraient par là, au démarrage, au moment de la demande de quoi démarrer, taper e avant la fin du compte à rebours, é l'écrire à la fin de la ligne.

Du coup, j'ai testé avec pcie_aspm=off au même endroit, et là ça marche.

Il reste un truc qui me chiffonne, c'est que je ne comprends pas vraiment.

J'ai trouvé cette page (Fedora) qui en parle. Si je comprends bien, cette commande supprime le mode d'économie d'énergie. Si c'est bien le cas... pas cool!

Possible de le faire seulement pour le composant qui pose problème?

Encore un gros merci pour ton aide.

noaer désactive la génération des messages d'erreur et la pollution des logs, ça ne corrige pas le bug avec le matériel.
Par contre pcie_aspm=off désactive les fonctionnalités, alors plus de messages certes mais plus de fonctionnalités non plus.

Il faut un compromis, avec noaer quels sont les autres messages ?

Ce sont exactement les mêmes les mêmes. Il y en a juste plus.

Est-ce une "défaillance" matérielle ? ou juste un problème de pilote?

gile a écrit : ↑mar. 03 sept. 2019, 17:35 Ce sont exactement les mêmes les mêmes. Il y en a juste plus.

Rhaa j'avais pas vérifié, le paramètre correcte est d'ajouter pci=noaer

Est-ce une "défaillance" matérielle ? ou juste un problème de pilote?

Un bug dans la communication entre le matériel et le pilote qui est normalement corrigé ensuite, le noyau rapporte quand même l'évènement dans les logs.

J'ai fait une autre recherche, essaie d'abord avec pci=noaer, en fonction du résultat satisfaisant ou pas, essaie ensuite avec le paramètre pci=nommconf qui aboutit à l'utilisation de l'ancienne méthode d'accès.

Pour info la doc des paramètres du noyau

Un très très gros merci pour ton aide!!!

Alors :

• pci=noaer ne me permet pas d'aller bien loin. une fois le démarrage terminé, je ne peux pas monter quoi que ce soit (destination déjà montée ou buzi). Et je ne comprend vraiment pas cette réaction au vu de l'explication donnée sur ton lien (très instructif)!
• pci=nommconf fait le travail.

Si je comprend bien, je peux laisser nommconf et conserver les apports de aspm?

gile a écrit : ↑mar. 03 sept. 2019, 19:48 Si je comprend bien, je peux laisser nommconf et conserver les apports de aspm?

Oui d'après ce que j'en ai compris c'est un ancien protocole qui est utilisé avec pci=nommconf, et aspm est conservé. Tu pourras toujours faire de nouveaux essais à la sortie des prochains noyaux linux, dès fois que le bug aura été corrigé.

Un super gros merci à toi! je passe le fil en résolu.