[Bookworm] Désactiver les ponts des bus msi

Tags: #<Tag:0x00007f2c9b3fb780>

Bonsoir,

Les admin d’ordi nécessitant l’option pci = nopci dans le chargeur d’amorçage pour démarrer devraient lire cette doc..

Au paragraphe 4.5.2 est donné la commande :
echo 1 > /sys/bus/pci/devices/$bridge/msi_bus

Sur le PC tout ces fichiers sont chargés d’un 1 par défaut,
Bref, remplacer quelques 1 par des 0 n’a aucun effet :confused:.
Après un redémarrage tout est à nouveau à 1.

Sauriez vous rendre permanent le changement de paramètre dans ces fichiers, s’il vous plaît.

Merci pour votre attention

Les éléments dans /sys ne sont pas de véritables fichiers mais une interface système avec le noyau. Il s’agit d’un système de fichiers virtuel appelé « sysfs ». Cf. man sysfs. Cela fonctionne un peu comme /proc (procfs). Pour appliquer des attributs au démarrage de façon persistante, on peut installer le paquet sysfsutils et le configurer avec le fichier /etc/sysfs.conf. Ou bien on peut se créer un script d’init ou un service systemd.

Pour le reste de ton message concernant les MSI, c’est un peu confus. Pourquoi vouloir mettre msi_bus à 1 s’il est déjà à 1 par défaut ?

1 J'aime

Pardon ?

Remplacer des 1 par des 0 :
—>
1111111
Remplacer le deuxième, le troisième et le cinquième 1 par des 0 donne :
1100101

Heu, non ?

Quoi qu’il en soit merci Pascal pour ces précisions sur les dossiers sys et proc.

Quel rapport avec /sys/bus/pci/devices/$bridge/msi_bus ?

Pour préciser le bus-msi du périphérique pci qui oblige d’ajouter l’option pci=nomsi au bootloader de l’ordi.

En réactivant les bus-msi les un après les autres, il devrait être possible de détecter le périphérique pci responsable des incompatibilités avec le msi du noyau.

Vous sauriez remplir /etc/sysfs.conf ? :slightly_smiling_face:

Les tests de plusieurs ligne du style comme ci-dessous sont inefficaces :

cat /etc/sysfs.conf
#
# /etc/sysfs.conf - Configuration file for setting sysfs attributes.
#
# The sysfs mount directory is automatically prepended to the attribute paths.
# The attribute paths support glob(7) wildcard patterns.
#
# Syntax:
# attribute = value
# mode attribute = 0600 # (any valid argument for chmod)
# owner attribute = root:wheel # (any valid argument for chown)
#
# Examples:
#
# Always use the powersave CPU frequency governor
# devices/system/cpu/cpu0/cpufreq/scaling_governor = powersave
#
# Use userspace CPU frequency governor and set initial speed
# devices/system/cpu/cpu0/cpufreq/scaling_governor = userspace
# devices/system/cpu/cpu0/cpufreq/scaling_setspeed = 600000
#
# Set permissions of suspend control file
# mode power/state = 0660
# owner power/state = root:power
devices/pci0000\:00/0000\:00\:03.1/msi_bus = "0"

devices/pci0000:00/0000:00:03.1/msi_bus = "0"
devices/pci0000:00/0000:00:03.1/msi_bus = 0
Plus d’autres que la honte préfère garder secrète :unamused:

La preuve de l’inefficacité :

systool -b pci -A msi_bus | grep -A 1 3.1
  0000:00:03.1 Silicon Integrated Systems [SiS] USB 1.1 Controller
    msi_bus             = "1"

Le chemin exact dans le dossier /sys : :blush:

$ less /sys/devices/pci0000\:00/0000\:00\:03.1/m
modalias  msi_bus

Bien que cela serve d’introduction utile pour la structure du sysfs et pour comprendre le fonctionnement de udev, le changement avec sysfs est souvent une perte de temps qui n’est donc pas nécessaire

:sweat_smile:

Ton problème n’est pas celui-là je suppose.
Il faudrait peut-être commencer par le début: c’est quoi ton problème ?
As-tu un message noyau qui t’indique une erreur ?
dmesg ne dit vraiment rien du tout sur ce ‹ problème › msi ?
Comment sais-tu que tu as un ‹ problème › ?
Est-ce un ‹ problème › relatif à l’ACPI ?
Pourquoi n’arrives-tu pas identifier spécifiquement le device à ‹ problème › ?

for i in /sys/bus/pci/devices/*/msi_bus;do printf "${i/*es\//} ";cat $i ;done 

lspci -t

Aucun problème, même si je me sens un tantinet psychotique en affirmant une telle chose.

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-5-amd64 root=UUID=ad672b5b-e68c-4aaf-8bde-113269cba2d8 ro pci=nomsi quiet
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-5-amd64 root=UUID=ad672b5b-e68c-4aaf-8bde-113269cba2d8 ro pci=nomsi quiet

dmesg n’offre que ces deux lignes contenant le terme « msi ».

JE SUIS PRESQUE UN IGNARE EN CE QUI CONCERNE LES LANGAGES DE BAS NIVEAUX, et je suis de niveau bas en anglais.
Depuis quelques jours je développe des babioles en Pyobject, et j’angoisse d’avoir autant de mal à comprendre Gtk.
Bref, je me baladais dans le dossier /etc pour observer en détail comment évolue systemd sur cette machine.
Et je suis tombé sur un fichier qui blacklist d’ancien périphérique, je ne sais pas pourquoi, une « réaction psychosomatique », je me suis souvenu de cette option pci=nomsi.
J’ai donc pris de ses nouvelles, www.kernel.doc a su me renseigner.

www.kernel.doc suggère d’envoyer un petit message lorsque l’option pci=nomsi est ajoutée au chargeur d’amorçage.
www.kernel.doc propose aussi de désactiver msi de plusieurs façons (globalement, selon le périphérique ou le pont).

Voilà, voilà, je m’exerce tout en me disant que je vais pouvoir apporter de l’information utile à www.kernel.doc.

L’acpi :thinking: si, éventuellement aussi, vaguement, confusément. Mais l’amorceur de démarrage de la machine se satisfait de la seul option pci=nomsi pour charger le système d’exploitation.
Sans ces neuf caractères « magiques » le système d’exploitation Debian ne se charge pas.

Bah, j’ai confiance, si je n’arrive pas c’est que je ne peux pas avancer suffisamment rapidement. J’ai prévu de faire des essais avec udevadm, udev, et la variable ENV :blush:.

0000:00:00.0/msi_bus 1
0000:00:01.0/msi_bus 1
0000:00:02.0/msi_bus 1
0000:00:02.5/msi_bus 1
0000:00:03.0/msi_bus 1
0000:00:03.1/msi_bus 1
0000:00:03.3/msi_bus 1
0000:00:04.0/msi_bus 1
0000:00:05.0/msi_bus 1
0000:00:06.0/msi_bus 1
0000:00:07.0/msi_bus 1
0000:00:0d.0/msi_bus 1
0000:00:0d.1/msi_bus 1
0000:00:0d.2/msi_bus 1
0000:00:0d.3/msi_bus 1
0000:00:0f.0/msi_bus 1
0000:01:00.0/msi_bus 1
0000:02:00.0/msi_bus 1
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           +-02.0
           +-02.5
           +-03.0
           +-03.1
           +-03.3
           +-04.0
           +-05.0
           +-06.0-[02]----00.0
           +-07.0-[03-06]--
           +-0d.0
           +-0d.1
           +-0d.2
           +-0d.3
           \-0f.0

Merci pour l’attention.

C’est donc un bon début puisque le système a automatiquement détecté que pour ta carte mère, cette option pci=nomsi était nécessaire.

Que fait-elle précisément, concrètement, techniquement n’est pas forcément la question essentielle, mais elle a bien un effet, comme tu le constates.
Mon interprétation est que kernel.org est intéressé par l’analyse des PC qui ont besoin de cette option, nécessaire pour le moment, rien de plus.

Si tu psychotes, et ne comprends absolument pas ce que tu fais en tripatouillant sysfs, je ne pourrais que te conseiller que de ne toucher à rien relatif à msi, et surtout pas de bricoler udev ou systemd ou je ne sais quoi, pour résoudre un problème qui n’existe pas fonctionnellement.
Comprendre avant d’agir.

C’est une option ajoutée « manuellement ».

Oh :pensive:
Il est vrai que ces affaires d’interupt au niveau du processeur me dépasse.
Mais en langage de bas niveau, il serait possible de faire appelle aux banques mémoire lié aux périphériques.
Bref, c’est une façon comme une autre d’approfondir l’utilisation des technologies de l’information et de la communication.

À chaqu’un ses réponses aux questions métaphysiques :blush:
Le sens de la vie, de l’action → à la compréhension ou de la compréhension → à l’action ?
L’adaptation empirique, rationnelle, pragmatique, manichéenne. Il en faut pour tous, non ?
Bref, /home est sur une partition séparée, des sauvegardes sont faites. Le risque est minimisé.

Bonne continuation à vous, et merci pour les conseils. « Un avisé en vaut deux » :sweat_smile:

Il faut soit habiter dans le noyau, ou être son développeur pour comprendre exactement ce que fait cette option msi pour certaines cartes mère.
Il est aussi possible que son effet ne soit nécessaire uniquement dans la phase de boot, création des devices, relativement au BIOS, et activée après boot, ce qui expliquerait que non visible.
Good luck !

1 J'aime

Alors, un retour pour ceux qui planchent sur /sys

0000:00:03.1 Silicon Integrated Systems [SiS] USB 1.1 Controller`
Est un « contrôleur » et non un « pont » :upside_down_face:

En précisant dans /etc/sysfs.conf les adresses des ponts à déactiver, l’opération est correctement réalisée :

  0000:00:01.0 Silicon Integrated Systems [SiS] PCI-to-PCI bridge
    msi_bus             = "0"
--
  0000:00:06.0 Silicon Integrated Systems [SiS] PCI-to-PCI bridge
    msi_bus             = "0"
--
  0000:00:07.0 Silicon Integrated Systems [SiS] PCI-to-PCI bridge
    msi_bus             = "0"

Probable,
Je vais donc m’en tenir là et envoyer une notification comme demandé.

Bonne continuation à tous,
Et merci pour tout.

Bonjour pam547,

En lisant la conversation j’ai pensé que des petites précisions s’imposent concernant ce que sont les MSIs et en quel est l’effet de pci=nomsi.

Pour commencer, une interruption est un mécanisme qui permet à un périphérique d’interrompre ce que le CPU exécute pour qu’il traite un évènement concernant ce périphérique, par exemple quand un carte réseau a reçu un paquet. En effet, quand les interruptions n’existaient pas, le CPU devait périodiquement vérifier l’état de tout les périphériques, périodiquement, pour voir si il y avait des évènements à traiter. Ce qui pose d’évidents problèmes de performances. Avec les interruptions, le CPU n’a plus besoin de vérifier chaque périphérique un par un, il peut exécuter ce qu’il veut, puis quand un périphérique a un évènement pour le CPU, il peut demander au CPU de le traiter pour lui.

Historiquement, les interruptions étaient des entrées du CPU (je simplifie en oubliant volontairement contrôleur d’interruptions) sur lesquelles les périphériques signalaient un interruption en passant l’entrée de l’état bas à l’état haut (ou vice-versa selon le design hardware). Le problème c’est qu’au fur et à mesure que le nombre de périphériques augmente, il faut aussi augmenter le nombre d’interruptions disponibles, sinon le CPU se retrouve à faire du polling pour vérifier quel périphérique à des données à traiter.

Quand PCI-Express a été introduit, les Message Signaled Interrupts (MSI) on été ajoutées dans la version 2.2. Elles permettent de remplacer les interruptions « hardware » (avec un fil d’interruption dédié) par un message envoyé sur le bus PCI-E au contrôleur de bus disant « j’ai une interruption ». Ce qui permet d’avoir autant d’interruptions qu’on veut par périphérique PCI-E.

C’est un mécanisme courant sur les machines modernes. En revanche sur les PC plus anciens il était courant d’avoir un bus PCI-E sans que les MSI soient supportées. Dans ce cas, le noyau doit savoir qu’il doit utiliser les interruptions normales au lieu des MSI pour les périphériques en question.

En théorie cette information est indiquée par un flag dans l’une des tables ACPI, et le noyau est censé en déduire quel périphérique peut, ou non, utiliser les MSI. Mais lorsque ce n’est pas le cas, les drivers des périphériques en question pensent devoir utiliser les MSI, mais ça ne fonctionne pas, et donc le driver ne fonctionne pas. Dans ce cas, il faut indiquer manuellement au noyau que les MSI ne sont pas supportées, c’est à ça que sert pci=nomsi: cette option indique au noyau que sur cette plateforme, il ne faut pas utiliser les interruptions MSI. Il est parfois également possible de le préciser par driver, avec un paramètre spécifique au driver.

Pour en revenir à la modification que tu essayes de faire dans /syscelle-ci n’a aucun effet et c’est attendu. Seul un petit nombre de contrôleur ou de bridges PCI-E sont capable de changer dynamiquement leur configuration concernant les MSIs. Il est donc probable que modifier ce 1 en 0 ne fasse rien dans le driver. Si tu souhaites désactiver les MSI par périphérique, ta meilleure chance est de trouver pour chaque driver le paramètre adéquat. Par exemple pour le driver nouveau (cartes graphiques Nvidia) il faut passer nouveau.config=NvMSI=0.

Voilà, en espérant que ça éclaircisse un peu la situation

1 J'aime