Forum Linux.noyau Ordre de chargement des modules

Posté par  .
Étiquettes :
1
14
nov.
2010
Bonsoir Forum,

Si je viens à toi ce soir, c'est que j'ai une question dont je pressens la réponse triviale mais dont je n'arrive pas à me dépêtrer.

Tout commence avec une installation de Linux Mint 10 (basée sur Ubuntu 10.10) sur un poste utilisateur. Rien de passionnant si ce n'est que le ventirad du processeur fait un bruit de casserole à pleine puissance.

Or, cela tombe bien, il est parfaitement contrôlable via fancontrol, moyennant le chargement du module w83627hf. Soit : ajout dans /etc/modules et roule.

L'ordi ronronne, et tout content de moi je l'arrête. Redémarrage le lendemain : de nouveau le ventirad à fond !? Pourtant fancontrol est démarré. Bizarre. Je parcours l'arborescence (/sys/class/hwmon/...) pour retrouver le fichier stockant la valeur de la tension appliquée (pwm2 dans mon cas) et surprise ! Il n'est plus à hwmon1/device/pwm2 mais hwmon0/device/pwm2.

Or évidemment le coup d'avant il était sur hwmon1, et pwmconfig (l'utilitaire de fancontrol) l'avait reconnu comme tel.

Qu'à cela ne tienne : je change les valeurs à la main dans /etc/fancontrol et redémarre fancontrol. Ca marche. Je redémarre l'ordi » "on" avait encore changé de hwmon..

Bref...il se trouve qu'effectivement en plus du module w83* est également chargé k8temp dynamiquement pour le processeur. Je le rajoute dans /etc/modules histoire d'imposer une séquence de chargement des modules, et donc j'espère une séquence fixe de /sys/class/hwmon. Las... apparemment rien n'y fait, ça continue à faire le yoyo...

La dernière solution que je vois est de blacklister k8temp dans /etc/modules, mais ne vois-tu pas, cher Forum, un moyen plus élégant d'imposer la séquence de /sys/class/hwmon plutôt ?

  • # udev

    Posté par  . Évalué à 3.

    Regarde du côté de udev, c'est lui qui se charge du nommage des périphériques. A cette heure, je n'ai pas le temps de t'en dire plus, mais c'est l'idée. Tu peux aussi regarder du côté de hal (mais je suis moins sur de cette piste).

    • [^] # Re: udev

      Posté par  . Évalué à 1.

      Merci du tuyau mais est-ce qu'il s'agit bien là d'un périphérique ? je veux dire : j'ai pris l'habitude d'y accéder via /sys/class/hwmon/hwmonX mais il s'agit d'un lien symbolique pointant vers /sys/devices...

      Je rejoins le commentaire ci-dessous : udev "marche" t'il aussi pour /sys ?

      • [^] # Re: udev

        Posté par  . Évalué à 1.

        et dans /sys/devices/.... t'as pas un "fichier" qui contiendrait le nom du device en plus de celui qu'il faut modifier ?
        Si c'est le cas, il te faut un script au boot qui parse tous les hwmon existants et qui effectue la modif pour celui qui correspond au "bon" device. Cela permet de ne plus dépendre de l'ordre de chargement.

        • [^] # Re: udev

          Posté par  . Évalué à 1.

          Oui ce serait possible mais, outre le fait que je suis une buse en script shell, j'aurais plutôt tendance à renvoyer la balle à la config de fancontrol :

          - depuis "peu" /etc/fancontrol doit obligatoirement contenir le chemin d'accès et le nom du chipset (DEVNAME/DEVPATH)
          - ces informations étant ramenées automatiquement par pwmconfig, on ne peut plus éditer soit-même le fichier, fancontrol détectant qu'il n'est plus "à jour"

          Et d'un autre côté malgré le nom il réclame encore l'indication de hwmonX ! M'est avis qu'on a un peu (passez-moi l'expression !) le "cul entre 2 chaises" et que, quitte à indiquer DEVPATH/DEVNAME, on pourrait s'abstraire de l'indication de hwmon et ce que tu préconises devrait être embarqué dans le daemon fancontrol (enfin c'est mon avis).

  • # /etc/initramfstools.d/modules

    Posté par  (site web personnel) . Évalué à 3.

    J'ai eu un problème similaire il y a quelques années sur une Debian, avec une machine doté de 2 controleurs SCSI différents, et dont je voulais forcer un ordre précis de chargement de modules (afin d'avoir un certain ordre dans le montage des disques).

    La solution a été de lister les modules, dans l'ordre de leur chargement, dans le /etc/initramfstools.d/modules , puis de regénerer le /initrd via la commande "initramfs-update -k all -u"

    Au reboot suivant, les modules étaient chargés dans le bon ordre.

    Voir à ce sujet : http://www.linuxquestions.org/questions/linux-general-1/modu(...)

    Le problème ici, est que le module est chargé dans le initrd, et donc avant les mécanismes de /etc/modprobe.*, /etc/modules, udev, etc... Il faut donc configurer ceci dans le initrd, en passant par initramfs.

    • [^] # Re: /etc/initramfstools.d/modules

      Posté par  (site web personnel) . Évalué à 3.

      J'ai aussi eu un problème similaire, avec un contrôleur disque qui pouvait être géré par deux modules, et c'était celui qui en faisait le moins (ata_piix) qui était chargé d'abord et damait le pion à celui dont j'avais besoin (ahci) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598518 [excusez mon mauvais anglais]

      tu peux forcer le chargement d'un module avant un autre en établissant une dépendance entre eux dans /etc/modules/aliases.conf avec la syntaxe "softdep module-suivant pre:module-precedent" et recharger l'initramfs.

      Par exemple, avant que mon bug soit corrigé je devais faire

      cat >> /etc/modprobe.d/aliases.conf <<\EOF
      softdep ata_piix pre: ahci
      EOF

      initramfs-update -k all -u

      pour que le module ahci soit chargé avant ata_piix

      Dans ton cas, si j'ai bien compris, tu devrais faire quelque chose comme

      cat >> /etc/modprobe.d/aliases.conf <<\EOF
      softdep k8temp pre: w83627hf
      EOF

      initramfs-update -k all -u

      Cela dit, si changer l'ordre des modules résout ton problème, c'est un hack sale, le vrai problème est un problème de nommage non persistant, pour /dev c'est udev qui doit s'en charger. Sous Debian Squeeze udev génère des nommages persistants pour les périphériques réseaux et lecteurs de disques optiques. Les règles par défaut sont dans /lib/udev/rules.d , et les règles générées (persistance de nommage par exemple) sont dans /etc/udev/rules.d (attention, c'est un langage à goto !).

      Pour /sys je ne sais pas…

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: /etc/initramfstools.d/modules

        Posté par  . Évalué à 1.

        Ta solution est séduisante et correspond tout à fait à mon besoin mais pourquoi la qualifies-tu de "hack sale" ? Il n'est pas lié à une quelconque version de initramfs et sera régénéré à chaque mise à jour non ?

        Alors certes ça ne correspond pas à ce que fait udev pour les /dev mais bon....de là à la considérer comme une vieille rustine...

        • [^] # Re: /etc/initramfstools.d/modules

          Posté par  (site web personnel) . Évalué à 2.

          j'appelle cela un hack sale parce que ton problème est un problème de nommage, pas d'ordre de chargement des modules.
          Il se trouve que c'est un peu par hasard, ça tombe bien, que le nom dépende de l'ordre de chargement des modules, donc changer l'ordre de chargement change le nom, mais c'est une conséquence involontaire .
          On n'a pas fait l'ordre de changement des modules pour donner des noms différents, mais on donne des noms différents parce que les modules sont différents, et pour faire simple, on nomme selon l'ordre de chargement.

          Fixer un nom en changeant l'ordre de chargement, c'est un peu une "undocumented feature", c'est pas fait pour, ça peut changer... Bon ok dans ce cas précis je ne pense pas que ça va changer avant longtemps, et à ta place je ferais peut-être ça aussi, mais à regret ;)
          Une autre conséquence pourrait être qu'en fixant arbitrairement un ordre de chargement tu obtienne des dysfonctionnement collatéraux. Personnellement je ne maitrise pas assez le noyau pour être sûr de moi :).

          J'aime faire propre, c'est ce qui m'a poussé à faire un rapport de bug : je n'avais pas envie de mettre dans mes procédures d'install une ligne spécifique à une catégorie de bécane que j'administre. Autant que ça soit déjà dans le CD d'install.
          Ce qui était utile en fait : je n'était pas le seul à en souffrir et tout le monde corrigeait salement dans son coin.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: /etc/initramfstools.d/modules

            Posté par  . Évalué à 1.

            Ok je comprends ce que tu veux dire et ne peux qu'acquiescer.

            Il faudrait d'ailleurs que j'aille faire un tour du côté de fancontrol pour rapporter cette histoire parce que bon, c'est bien gentil d'avoir chamboulé pwmconfig pour y inclure le chemin d'accès (et non le lien symbolique) dans /sys...mais de l'autre il faut quand même lui spécifier hwmonX et il est perdu quand ça change !

            Merci en tout cas pour l'explication !

    • [^] # Re: /etc/initramfstools.d/modules

      Posté par  (site web personnel) . Évalué à 2.

      Voir à ce sujet : http://www.linuxquestions.org/questions/linux-general-1/modu(...)

      Oooooh fun, je n'avais pas trouvé quand j'ai eu le problème, j'ai bien fait de rapporter le bug, ça fait donc au moins deux ans que le cadavre était dans la penderie :

      However, we currently delete modules.* when creating the image packages, because we assume all those files are generated by depmod. Oops.

      ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.