Forum Linux.noyau Comment limiter le chargement d'un driver réseau à une seule interface ?

Posté par  .
Étiquettes :
2
4
nov.
2011

Bonjour,

Sur un ordinateur avec deux cartes réseaux identiques, ( eth0 et eth1 ), je voudrais charger un driver différent sur chaque interface.
Mais quand je charge le driver pour eth0, il détecte aussi eth1 et se l'accapare, m'empêchant ainsi de charger mon autre driver.
Comment résoudre ce problème ?

Voici plus de détails:
L'ordinateur est une single-board-computer au format VME avec deux interfaces Intel Pro/100.
Je voudrais charger e100 (driver Linux) sur eth0 et ec_e100 (driver temps-réel pour EtherCAT) sur eth1.
Il n'y a pas de disque dur, aussi l'ordinateur démarre Debian 6.0 i686 en réseau.
Il démarre en PXE/TFTP via eth0, il télécharge le noyau puis initrd. Il trouve le driver e100 dans initrd, le charge pour pouvoir initialiser le réseau et monter sa racine en NFS.
Le module e100 ne peut plus être déchargé sous peine de bloquer l'ordinateur puisqu'il n'aura plus accès à sa racine.
Au cours de l'init, il faut donc je charge le module e100 uniquement sur eth0 et que je laisse eth1 libre pour pouvoir charger l'autre module plus tard.

Est ce qu'il y a une méthode standard pour faire ca ? Ou bien est ce que je dois modifier le code du driver e100 (ce que je souhaiterai éviter) ?

Merci d'avance pour votre aide.

  • # argument de boot du kernel, ça fonctionne ?

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

    eth0=e100

    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

  • # udev, alias, modprobe et compagnie

    Posté par  . Évalué à 2.

    je ne sais pas si ca entre en jeu au moment des drivers chargés par l'initrd

    mais il fut un temps ou on pouvait blacklister un module, ou lui dire qu'il ne se charge pour pour telle ou telle carte.

    on doit donc pouvoir specifier quelque part que eth0=e100 et eth1=ec_e100

    de memoire le fichier contenait des lignes comme

    alias eth0 e100
    alias eth1 ec_e100
    alias eth2 off

    • [^] # Re: udev, alias, modprobe et compagnie

      Posté par  . Évalué à 3. Dernière modification le 05 novembre 2011 à 10:29.

      J'ai ça chez moi dans /etc/modprobe.conf :

      # more /etc/modprobe.conf
alias eth0 bnx2
alias eth1 bnx2
alias eth2 bnx2x
alias eth3 bnx2x
alias eth4 tg3
alias eth5 tg3

  • # Probe PCI

    Posté par  . Évalué à 1.

    À mon humble avis (les avis, c'est comme les trouducu, tout le monde en a un ;) ), je ne crois pas que ça soit possible sans modifier / configurer le driver de ton NIC : dans un driver qui fait du "probe PCI", tel que celui de ton NIC, il va détecter tous les devices PCI qu'il peut traiter (par l'intermédiaire des vendorID / deviceID) : si tes 2 cartes apparaissent dans un même driver, elles vont être gérées par celui-ci. Je pense donc les contournements avec les modprobe / modules.conf ne marcheront pas ... Faudrait voir si c'est faisable de modifier les 2 drivers pour ne gérer que les interfaces dont tu passerais la mac address par exemple.

  • # OK je vais hacker les drivers

    Posté par  . Évalué à 1.

    Je remercie chacun de vous pour vos avis, mais je crois que c'est ninis666
    qui a raison: ca se passe directement au niveau du probe PCI et donc je vais être obligé de hacker les drivers.

    Je reviendrai poster les résultats de mon expérience dans ce thread.

    • [^] # Re: OK je vais hacker les drivers

      Posté par  . Évalué à 2.

      avant de modifier/recompiler les modules/drivers
      ce serait mieux d'utiliser ce que font les autres (c'est ainsi plus facile à maintenir à la mise à jour du noyau)

      http://www.linuxquestions.org/questions/linux-general-1/module-load-order-648599/

      You type the modules by the order you want in /etc/initramfstools.d/modules
      then
      sudo initramfs-update -k all -u

    • [^] # Re: OK je vais hacker les drivers

      Posté par  . Évalué à 4.

      Eh bien non, il n'a pas raison. Normalement modprobe.conf est bien la pour forcer tel ou tel driver pour telle ou telle interface.

      Essaie avant de mettre en doute.

      • [^] # Re: OK je vais hacker les drivers

        Posté par  . Évalué à 0.

        Moi je regarde dans le manuel de modprobe.conf et de modprobe, et je constate qu'il n'y a aucun moyen externe d'empêcher le driver d'initialiser les deux cartes identiques.

        Voici un essai pour le prouver.
        Le système est Debian 6.0.3 / i386 dans VirtualBox avec deux cartes Intel Pro/1000 identiques.

        # modinfo e1000
filename:       /lib/modules/2.6.32-5-686/kernel/drivers/net/e1000/e1000.ko
version:        7.3.21-k5-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     383459ED2D46B8379FCB399
alias:          pci:v00008086d000010B5sv*sd*bc*sc*i*
alias:          pci:v00008086d00001099sv*sd*bc*sc*i*
alias:          pci:v00008086d0000108Asv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Csv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001079sv*sd*bc*sc*i*
alias:          pci:v00008086d00001078sv*sd*bc*sc*i*
alias:          pci:v00008086d00001077sv*sd*bc*sc*i*
alias:          pci:v00008086d00001076sv*sd*bc*sc*i*
alias:          pci:v00008086d00001075sv*sd*bc*sc*i*
alias:          pci:v00008086d00001028sv*sd*bc*sc*i*
alias:          pci:v00008086d00001027sv*sd*bc*sc*i*
alias:          pci:v00008086d00001026sv*sd*bc*sc*i*
alias:          pci:v00008086d0000101Esv*sd*bc*sc*i*
alias:          pci:v00008086d0000101Dsv*sd*bc*sc*i*
alias:          pci:v00008086d0000101Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001019sv*sd*bc*sc*i*
alias:          pci:v00008086d00001018sv*sd*bc*sc*i*
alias:          pci:v00008086d00001017sv*sd*bc*sc*i*
alias:          pci:v00008086d00001016sv*sd*bc*sc*i*
alias:          pci:v00008086d00001015sv*sd*bc*sc*i*
alias:          pci:v00008086d00001014sv*sd*bc*sc*i*
alias:          pci:v00008086d00001013sv*sd*bc*sc*i*
alias:          pci:v00008086d00001012sv*sd*bc*sc*i*
alias:          pci:v00008086d00001011sv*sd*bc*sc*i*
alias:          pci:v00008086d00001010sv*sd*bc*sc*i*
alias:          pci:v00008086d0000100Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000100Esv*sd*bc*sc*i*
alias:          pci:v00008086d0000100Dsv*sd*bc*sc*i*
alias:          pci:v00008086d0000100Csv*sd*bc*sc*i*
alias:          pci:v00008086d00001009sv*sd*bc*sc*i*
alias:          pci:v00008086d00001008sv*sd*bc*sc*i*
alias:          pci:v00008086d00001004sv*sd*bc*sc*i*
alias:          pci:v00008086d00001001sv*sd*bc*sc*i*
alias:          pci:v00008086d00001000sv*sd*bc*sc*i*
depends:        
vermagic:       2.6.32-5-686 SMP mod_unload modversions 686 
parm:           TxDescriptors:Number of transmit descriptors (array of int)
parm:           RxDescriptors:Number of receive descriptors (array of int)
parm:           Speed:Speed setting (array of int)
parm:           Duplex:Duplex setting (array of int)
parm:           AutoNeg:Advertised auto-negotiation setting (array of int)
parm:           FlowControl:Flow Control setting (array of int)
parm:           XsumRX:Disable or enable Receive Checksum offload (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           debug:Debug level (0=none,...,16=all) (int)

# rmmod e1000
# dmesg -c > /dev/null
# modprobe e1000 debug=16
# dmesg
[  295.421795] e1000 0000:00:08.0: PCI INT A disabled
[  295.768052] e1000 0000:00:03.0: PCI INT A disabled
[  303.432163] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[  303.432163] Copyright (c) 1999-2006 Intel Corporation.
[  303.432163] e1000 0000:00:03.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
[  303.868994] e1000: 0000:00:03.0: e1000_probe: (PCI:33MHz:32-bit) 08:00:27:3e:c8:8d
[  303.936125] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[  303.936125] e1000 0000:00:08.0: PCI INT A -> Link[LNKD] -> GSI 9 (level, low) -> IRQ 9
[  304.368570] e1000: 0000:00:08.0: e1000_probe: (PCI:33MHz:32-bit) 08:00:27:00:e3:f1
[  304.452184] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  304.456184] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[  304.476065] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  304.824878] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
[  304.976103] ADDRCONF(NETDEV_UP): eth1: link is not ready

        On voit bien que le driver exécute e1000_probe pour chaque carte et donc c'est probablement cette fonction que je vais modifier pour arriver à mes fins. Je vais ajouter un paramètre au module pour sélectionner la carte que je veux initialiser.

        • [^] # Re: OK je vais hacker les drivers

          Posté par  . Évalué à 2.

          essaye de la faire à l'envers
          charge le driver eth1 (ec_e100) AVANT celui de eth0 (e100)

          ainsi e100 ne pourra pas prendre eth1 car il est deja géré par un autre module

      • [^] # Re: OK je vais hacker les drivers

        Posté par  . Évalué à -1.

        On est obligé de modifier le driver en commentant certaines entrés référencées par la struct "pci_driver" : il y a une table listant tous les devices PCI que le driver doit gérer. Les bidouilles avec modprobe / depmod ne peuvent pas marcher dans ce cas précis ....

        Comme dirait l'autre, "get things done !" : ne donnez votre avis que sur les sujets que vous maîtrisez / avez déjà fait !

  • # bien relire la documentation

    Posté par  . Évalué à 0.

    En fait en relisant la documentation Ethercat Master 1.5.0, section 4.2 Native EtherCAT Device drivers, j'ai compris qu'il faut charger le driver ec_e100 à la place du driver e100, car le driver ec_e100 peut aussi être utilisé pour faire de l'Ethernet standard.

Suivre le flux des commentaires

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