<!--
  $Id: Ethernet-HOWTO.sgml,v 1.1.1.1 2003/01/03 02:38:54 traduc Exp $

  $Log: Ethernet-HOWTO.sgml,v $
  Revision 1.1.1.1  2003/01/03 02:38:54  traduc
  Ajout des HOWTO existants à l'archive.

  Revision 1.17  1999/06/28 12:17:11  mat
  rere joël avec suppression des commentaires superflus.

  Revision 1.16  1999/06/22 19:41:25  mat
  relecture de joël appliquée

  Revision 1.15  1999/06/17 21:12:25  mat
  relecture de carine appliquée

  Revision 1.14  1999/06/08 11:35:39  mat
  mise a jour terminée, envoi en relecture...

  Revision 1.13  1999/03/31 21:06:28  mat
  petit oubli dans la version précédente

  Revision 1.12  1999/03/31 20:51:46  mat
  freenix.{fr,org}/linux -> freenix.org/unix/linux

  Revision 1.11  1999/03/03 20:14:25  mat
  Changement de mail

-->
<!--

        Le fichier-source SGML de l'Ethernet-Howto
        ==========================================

        Par Paul Gortmaker.
        Traduction française~: Mathieu Arnold.

        Date de modification~: 5 mai 1999
        Date de traduction~: 14 décembre 1997

        (Ne pas oublier de mettre à jour la référence à la version
        courante du noyau dans l'introduction, et la date/numéro de
        version dans le résumé~!)


        Historique~:

        1) Juillet 93 - Je cherchais des infos pour utiliser ethernet sur un
           portable, et je regardais les fichiers du site ftp de Donald (qui
           s'appelait alors ftp.super.org) - Donald avait tout un tas de
           fichiers d'informations qui étaient en vrac, et pendant que j'en
           discutais avec lui, il a mentionné que ce serait bien si un jour
           toutes ces informations étaient assemblées dans un seul document. Le
           projet Howto venait de démarrer, le NET-Howto en était le premier
           représentant (né de toute la confusion qui avait suivi le grand
           changement concernant le réseau lors de la 0.99pl10). J'ai rassemblé
           toutes les infos de Donald, j'ai ajouté des choses que j'avais
           glanées dans les news, j'ai copié le style d'ensemble du NET-Howto,
           et le premier Ethernet-Howto a atteint l'Internet au cours du mois
           d'août 93.


        2) Décembre 93 - Donald réalise une version HTML de l'Ethernet-Howto,
           mais elle n'est guère diffusée et je ne continue à tenir à jour que
           la version ASCII.

        3) Printemps 94 - L'Ethernet-Howto est publié dans la Bible Linux - 30
           pages d'un livre qui en comporte environ 750, publié par Linux System
           Labs.

        4) Donald change de boulot, et met en place sa page WWW avec des
           informations à jour sur les nouveaux pilotes Linux, et d'autres
           nouvelles sur Ethernet. Reportez-vous à l'URL contenue dans ce
           document.

        5) Un an (juillet 94) après sa naissance, disparition de l'affreux
           formatage à base de tabulations et d'espaces. La dernière version
           ASCII qui ait été maintenue à la main est la version 1.03, datée du
           22 juin 94. Toutes les versions ASCII plus récentes ont été générées
           à partir de ce source SGML.

        6) J'ai conservé le fichier converti jusqu'en octobre 94 à cause d'un
           bug dans le système de références croisées d'HTML. Un correctif
           devait arriver, mais ne vint jamais. J'ai fini par trouver un moyen
           de contourner le problème.

        7) Novembre 95 voit une réorganisation majeure du document, qui met en
           tête la FAQ et toutes les choses intéressantes. Les gens ne lisent
           jamais plus loin que les quelques premières pages, de toute
           façon...~:-)

        8) Octobre 96, Linux 2.0 semble s'être stabilisé aux environs du patch
           21. Bonne époque pour une mise à jour. On vire les parties qui
           documentent des bogues relatives aux noyaux 1.0 et 1.1.

        9) Février 97 - quelques mises à jour et correctifs supplémentaires,
           pour l'amener à la 2.0.28 et la 2.1.24 respectivement.

        10) Novembre 97 - pre-2.0.31 et 2.1.6x, mise à jour pour le nouveau
            livre LSL.

        11) Février 98 - 2.0.33 et 2.1.84, des mises à jour mineures en plus,
            des trucs vieillots en moins.

        12) Juillet 98 - 2.0.36 et 2.1.131, comme précédemment et on se
            concentre sur l'utilisation des modules, puisque toutes les
            distributions les utilisent maintenant.

        13) Novembre 98 - 2.0.35/2.1.126, beaucoup de modifications, ajout des
            noms de modules dans les titres pour aider les utilisateurs de
            modules (non diffusée)

        14) Mai 99 - 2.0.36/2.2.7, Suppression de vieilleries, ajout d'une
            section sur les problèmes de SMP, suppressions des références a la
            série 2.1.

A FAIRE~:

        Reformater au format de mise en page HowTo commun. Cela signifie
        supprimer progressivement toutes les sections <sect2>. Je ne suis pas
        sûr d'aimer cette idée.

        Indexer le document une fois que ce sera possible en SGML (glups~!)

        Remplacer tous les <code> par <verb> ou <tscreen>, c'est a dire,
        utiliser soit <verb> soit <tscreen> systématiquement.

        Les trois choses précédentes ne seront probablement jamais faites car
        l'arrivée du DocBook est proche.

        Il faudrait peut être supprimer tous les informations non relatives a
        Linux pour réduire la taille de ce document.  (Peut être qu'au lieu de
        les supprimer, il vaudrait mieux les mettre dans un autre document non
        mis a jour~?) J'ai commencé a mettre en commentaires et a supprimer
        certaines de ces informations.


NOTES DU TRADUCTEUR~:

        - Cette version a certainement encore besoin d'un bon coup de
          relecture. En particulier, il faudrait comparer la version française
          avec la version anglaise pour être sûr qu'il n'y a pas des fautes de
          frappe qui traînent (et des contre sens, etc.)

        - L'abréviation de kilo-octet est Ko. Le 'K' des informaticiens vaut
          1024, alors que le 'k' de tout le reste du monde vaut 1000 (c'est vrai
          en particulier en télécoms~: une liaison à 64kbit/s fait 64000 bits
          par seconde, pas 64Kbit/s ce qui ferait 65536 bits par seconde). Donc
          un canal B RNIS français `fait du' 8000 bits par seconde. Par contre,
          M peut désigner 1024*1024 (Mo), ou 1000*1000 (MHz).

        - Ma traduction de certaines formules anglaises est plus que
          lourdingue. Vous êtes invité(e) à faire toute remarque critique visant
          à améliorer ce document~!

        - <em></> est utilisé pour indiquer l'insistance (<em>EM</>phasize),
          <it></> est utilisé pour indiquer l'italique (termes latins, <it>e.g.</>),
          <sl></> est utilisé pour les noms de <sl>newsgroups</>, ou les termes
          anglais laissés tels quels dans le texte (par exemple les noms des
          autres <sl>HOWTOs</>).
        Désolé si cela paraît prétentieux, mais utiliser `<em></>' pour faire de
        l'italique me hérisse un peu. ;)
        [Note sur la note~: mais c'est pas pour autant que ça sort plus beau
        avec linux-sgml, grrr..]

        Autre Note~: Je n'utilise pas les notations <tt/machin/ au profit de
        <tt>machin</> parceque sinon, le mode SGML d'xemacs+ispell perds la
        boule

        Version 0.1~: version originale

        Version 0.2~: corrections, remise en forme. Utilisation de '~' pour
        faire des espaces insécables (j'ai lu le DTD~!)
-->

<!doctype linuxdoc system>

<article>

<title>Linux Ethernet-Howto

<author>par Paul Gortmaker
        Version française~: Mathieu Arnold

<date>Version anglaise~: v2.7, 5 mai 1999

<abstract>
        Ceci est l'<sl>Ethernet-Howto</>, une compilation d'informations sur les
        périphériques Ethernet qui peuvent être utilisés avec Linux, et la façon
        de les mettre en oeuvre. Notez que ce <sl>Howto</> se limite à l'aspect
        matériel et pilotes de bas niveau des cartes Ethernet, et ne couvre pas
        la partie logicielle de choses comme <tt>ifconfig</> et
        <tt>route</>. Consultez le <sl>Network~Howto</> pour ce type
        d'informations.
</abstract>

<toc>

<sect>Introduction<label id="main-intro">
<p>
        L'<sl>Ethernet-Howto</> indique quelles cartes vous devriez ou ne
        devriez pas acheter; comment les configurer, comment en utiliser
        plusieurs en même temps et d'autres problèmes et questions classiques.
        Il contient des informations détaillées sur le niveau actuel du support
        pour toutes les cartes Ethernet parmi les plus courantes disponibles.

        Il <em>ne</> couvre <em>pas</> l'aspect logiciel des choses, tel qu'il
        est décrit dans le <sl>NET-3-Howto</>. Notez aussi que les questions
        générales sur Ethernet, non liées spécifiquement à Linux, ne sont pas
        traitées dans ce document (ou du moins ne le devraient pas l'être).
        Pour ce genre de questions, consultez l'excellent ensemble
        d'informations de la FAQ du groupe <tt>comp.dcom.lans.ethernet</>.  Vous
        pouvez l'obtenir par FTP depuis <tt>rtfm.mit.edu</> de la même manière
        que vous obtenez les FAQs des autres forums.

        La présente version couvre les noyaux de distribution jusqu'à la version
        2.2.7 incluse.

        L'<sl>Ethernet-Howto</> est de~:
<quote>
        Paul Gortmaker, <tt>p_gortmaker@yahoo.com</>
</quote>

        La principale source d'information pour la première version, en ASCII
        pur de l'<sl>Ethernet-Howto</> était~:
<quote>
        Donald J. Becker, <tt>becker@cesdis.gsfc.nasa.gov</>
</quote>
        que nous devons aussi remercier pour l'écriture de la vaste majorité des
        pilotes de cartes Ethernet qui sont aujourd'hui disponibles pour
        Linux. Il est aussi l'auteur du serveur NFS originel. Merci Donald~!

        Ce document est Copyright (c) 1993-1999 Paul Gortmaker, et 1998-1999
        Mathieu Arnold pour la version française. Consultez le désistement de
        responsabilité (section~<ref id="copyright" name="Désistement de
        responsabilité et Copyright">) et les informations sur la copie à la
        fin de ce document pour avoir plus d'informations sur la
        redistribution de ce document ainsi que tout le tremblement habituel
        sur 'nous ne sommes pas responsables de ce que vous pouvez réussir a
        casser...'.


        La version française est de~:
<quote>
        Mathieu Arnold, <tt>arn_mat@club-internet.fr</>.
</quote>

<sect1>Nouvelles versions de ce document<label id="new-doc">
<p>
        Les nouvelles versions de ce document peuvent être rapatriées depuis~:
<quote>
        <url url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/"
             name="Sunsite HOWTO Archive">
</quote>
        Ceci est l'emplacement officiel de ce document, il peut aussi être
        récupéré depuis divers sites miroirs WWW/FTP de Linux.

        (NDT~: En France, vous préférerez utiliser le site suivant pour le
        document originel~:

        <url url="ftp://ftp.lip6.fr/pub/linux/sunsite/docs/HOWTO/"
             name="Miroir de Sunsite">

        ou, mieux, la version française~:

        <url url="ftp://ftp.lip6.fr/pub/linux/french/HOWTO/"
             name="Archive des HOWTO français sur LIP6">

        <url url="http://www.freenix.org/unix/linux/french/HOWTO/" name="Archive des
        HOWTO français chez Freenix">)

        Des mises à jour seront réalisées au fur et à mesure de l'arrivée de
        nouvelles informations et/ou de nouveaux pilotes. Si la copie que vous
        êtes en train de lire date de plus de 6 mois, alors, vous devriez
        aller vérifier qu'une nouvelle version n'est pas disponible.

        Ce document est consultable sous divers formats (postscript, dvi,
        ASCII, HTML...). Je recommanderai de consulter ce document sous sa
        forme HTML (à l'aide d'un navigateur WWW) ou sa forme
        Postscript/DVI. Ces deux formats contiennent des références croisées
        qui ne sont pas incluses dans le format texte ASCII.


<sect1>Ethernet-Howto, mode d'emploi<label id="using">
<p>
        Comme ce guide devient de plus en plus gros, vous n'avez certainement
        pas l'intention de passer la fin de votre après-midi à le lire en
        entier. Et la bonne nouvelle est que vous n'êtes pas <em>obligé(e)</>
        de le lire du tout. Les versions HTML, postscript et dvi possèdent
        une table des matières qui vous permettra de trouver plus vite
        l'information que vous cherchez.

        Il y a des chances pour que vous lisiez ce document parce que vous
        n'arrivez pas à faire marcher le tout, et que vous ne savez pas quoi
        faire ou quoi vérifier. La prochaine section~(<ref id="help" name="Au
        secours - Ca ne marche pas~!">) est destinée aux néophytes de Linux et
        vous indiquera la bonne direction.

        Typiquement, les mêmes problèmes et les mêmes questions sont posés
        <em>sans arrêt</> par des personnes différentes. Il y a des chances que
        votre problème ou votre question spécifique soit l'une de ces questions
        fréquemment posées, et qu'elle trouve sa réponse dans la partie FAQ
        (NDT~: Foire Aux Questions) de ce document.  (Voir~<ref id="faq"
        name="La Foire Aux Questions">). Tout le monde devrait y jeter un coup
        d'oeil avant d'envoyer un message demandant de l'aide.

        Si vous n'avez pas encore de carte Ethernet, vous devriez commencer par
        en choisir une. (Voir~<ref id="what-card" name="Quelle carte dois-je
        acheter...">)

        Si vous avez déjà une carte Ethernet mais que vous n'êtes pas sûr(e) de
        pouvoir l'utiliser avec Linux, lisez donc la section qui contient les
        informations spécifiques à chaque constructeur, et à ses cartes.
        (Voir~<ref id="card-intro" name="Informations Spécifiques...">)

        Si vous êtes intéressé(e) par l'un des aspects techniques des pilotes de
        périphériques de Linux, allez donc consulter la section~<ref
        id="tech-intro" name="Informations Techniques"> qui contient ces
        informations.


<sect1>Au secours~! - Ca ne marche pas~!<label id="help">
<p>
        Bon, ne paniquez pas. Cette section va vous indiquer le chemin à suivre
        pour que les choses fonctionnent, même si vous n'avez pas de
        connaissances préalables sur Linux ou le matériel Ethernet.

        La première chose à faire est de trouver quel est le modèle de votre
        carte, afin de pouvoir déterminer si Linux dispose d'un pilote pour
        cette carte-là. Des cartes différentes sont typiquement contrôlées de
        façon différente par l'ordinateur qui les accueille, et le pilote de
        périphérique de Linux (s'il en existe un) contient ces informations de
        contrôle qui permettent à Linux d'utiliser la carte.

        Si vous n'avez pas de manuel ou de document de ce genre pour vous
        indiquer quel est le modèle de la carte, vous pouvez alors essayer la
        méthode décrite dans la section~<ref id="mystery" name="Identifier une
        carte inconnue">, qui vous aidera sur les cartes mystérieuses.

        Maintenant que vous savez quel type de carte vous avez, lisez les
        détails concernant celle-ci dans la section destinée aux cartes
        (section~<ref id="card-intro" name="Informations Spécifiques...">), qui
        liste par ordre alphabétique les constructeurs de carte, les numéros de
        chaque carte, et précise s'il existe un pilote pour Linux ou non. Si
        votre carte est indiquée comme `Non-supportée', vous pouvez pratiquement
        vous arrêter dès maintenant. Si vous ne pouvez pas trouver votre carte
        dans la liste, vérifiez alors si le manuel de celle-ci ne l'indique pas
        comme `compatible' avec un autre type de carte connu. Par exemple, il
        existe des centaines, si ce n'est des milliers de cartes différentes qui
        ont été conçues pour être compatible avec le modèle d'origine NE2000 de
        Novell.

        Supposons que vous avez trouvé un pilote sous Linux pour votre carte,
        vous n'avez plus qu'à le récupérer et à l'utiliser. Ce <em>n'est pas</>
        parce que Linux possède un pilote pour votre carte que celui-ci est pour
        autant installé dans tous les noyaux. (Le noyau est le coeur du système
        d'exploitation qui est chargé en premier au démarrage et qui contient
        entre autres choses, les drivers de divers périphériques).  Selon la
        distribution de Linux que vous utilisez, il peut n'y avoir que très peu
        de noyaux tout prêts, et tout un tas de pilotes sous la forme de modules
        séparés, ou il peut y avoir tout un tas de noyaux, qui couvrent un grand
        nombre de combinaisons de pilotes précompilés.

        La majorité des distributions actuelles de linux sont livrées avec
        beaucoup de petits modules qui sont les divers pilotes. Les modules
        requis sont généralements chargés lors du démarrage, ou à la demande
        pour pouvoir accéder à un péripherique particulier. Vous aurez besoin
        d'attacher ce module au noyau après qu'il ait démarré. Consultez les
        informations de votre distribution sur l'installation et l'utilisation
        des modules, ainsi que la section sur les modules du présent document
        (section~<ref id="modules" name="Utilisation des pilotes Ethernet comme
        modules">).

        Si vous n'avez pas trouvé de noyau précompilé avec votre pilote, ni de
        pilote sous la forme d'un module, il y a des chances pour que vous ayez
        une carte particulièrement peu banale, et vous allez être obligé(e) de
        construire votre propre noyau en incluant ce pilote. Une fois que Linux
        est installé, construire un noyau personnalisé n'est pas difficile du
        tout. Vous répondez essentiellement oui ou non à ce que vous souhaitez
        que le noyau comprenne, et ensuite vous lui dites de le construire. Il
        existe un <sl>Kernel-HowTo</> qui vous aidera dans cette opération.

        (NDT~: et sa version française, accessible sur

        <url url="ftp://ftp.lip6.fr/pub/linux/french/HOWTO/Kernel-HOWTO"
        name="Traduction du Kernel-Howto">)

        Arrivé à ce point, vous devriez être parvenu d'une façon ou d'une autre
        à démarrer un noyau avec votre pilote intégré, ou à charger ce pilote
        comme un module. A peu près la moitié des problèmes que les gens
        rencontrent est liée au fait que le pilote n'a pas été chargé d'une
        manière ou de l'autre, donc vous devriez constater que tout fonctionne,
        maintenant.

        Si cela ne fonctionne toujours pas, il vous faut alors vérifier si le
        noyau a bel et bien détecté la carte. Pour ce faire, vous devez taper
        <tt>dmesg | more</tt> une fois loggé, après que le système a démarré et
        que tous les modules ont été chargés. Cela vous permettra de consulter
        les messages que le noyau a fait défiler sur l'écran durant le processus
        de démarrage. Si la carte a été détectée, vous devriez voir quelque part
        dans cette liste un message du pilote de votre carte commençant par
        <tt>eth0</>, et indiquant le nom du pilote et les paramètres matériels
        (réglage d'interruption (IRQ), de ports d'entrée-sorties (E/S), etc.)
        pour lesquels la carte est réglée. (Note~: lors du boot, le noyau de
        Linux donne la liste de toutes les cartes PCI, qu'il ait le pilote ou
        non - ne le confondez pas avec la détection des pilotes qui intervient
        après~!)

        Si vous ne voyez pas de message d'identification de ce type, alors le
        pilote n'a pas détecté votre carte, et c'est pour cela que cela ne
        fonctionne pas. Consultez la FAQ (section~<ref id="faq" name="La Foire
        Aux Questions">) pour savoir quoi faire si votre carte n'est pas
        détectée.  Si vous avez une carte compatible NE2000, vous y trouverez
        aussi des astuces spécifiques pour faire détecter une NE2000.

        Si la carte a été détectée, mais que le message de détection indique une
        quelconque erreur, telle qu'un conflit de ressources, alors le pilote ne
        s'est probablement pas correctement initialisé et la carte n'est
        toujours pas utilisable. La plupart des messages d'erreur de ce type
        sont eux aussi listés dans la FAQ, ainsi que leur solution.

        Si le message de détection paraît correct, vérifiez de nouveau les
        ressources indiquées par le pilote en les comparant avec celles pour
        lesquelles la carte est physiquement configurée (soit à l'aide de petits
        `cavaliers' noirs sur la carte, soit par un logiciel utilitaire fourni
        avec la carte par son constructeur).  Les ressources doivent
        correspondre exactement. Par exemple, si votre carte est configurée
        (physiquement ou par logiciel) pour utiliser l'IRQ~15 et que le pilote
        indique IRQ~10 dans les messages de démarrage, quelque chose ne va
        pas. La FAQ évoque les cas les plus courants où un pilote ne détecte pas
        correctement les informations de configuration de diverses cartes.

        A ce stade, vous êtes arrivé(e) à faire détecter votre carte avec tous
        les paramètres corrects, et l'on peut espérer que tout fonctionne. Si ce
        n'est pas le cas, vous avez alors soit une erreur de configuration
        logicielle, soit une erreur de configuration matérielle. Une erreur de
        configuration logicielle serait de ne pas avoir configuré la bonne
        adresse de réseau pour l'une des commandes <tt>ifconfig</> ou
        <tt>route</> (ou les deux~!); la manière de procéder est décrite en
        détail dans le <sl>Network~HowTo</> et le `Guide de l'Administrateur
        Réseau' (`<sl>Network Administrator's Guide</>' (NAG) en anglais) qui se
        trouvent certainement tous les deux sur le CD-ROM d'installation.

        Une erreur de configuration matérielle se produit quand un type de
        conflit de ressources ou une mauvaise configuration (que le pilote n'a
        pas détecté au démarrage) empêche la carte de fonctionner
        correctement. Vous pouvez typiquement observer cela sous plusieurs
        formes différentes.  (1)~Vous obtenez un message d'erreur lorsque
        <tt>ifconfig</> essaie d'ouvrir le périphérique pour l'utiliser, du
        genre ``<tt>SIOCSFFLAGS: Try again</>''.  (2)~Le pilote indique des
        messages d'erreur sur <tt>eth0</> (que vous pouvez voir avec <tt>dmesg |
        more</tt>) ou des incohérences étranges à chaque fois qu'il essaie
        d'envoyer ou de recevoir des données.  (3)~Le fait de taper <tt>cat
        /proc/net/dev</tt> donne un nombre non nul dans l'une des colonnes
        <tt>errs</>, <tt>drop</>, <tt>fifo</>, <tt>frame</> ou <tt>carrier</>
        pour <tt>eth0</>. (4)~Taper <tt>cat /proc/interrupts</> donne un nombre
        d'interruptions égal à zéro pour la carte.  La plupart des erreurs de
        configuration matérielle typiques sont elles aussi abordées dans la FAQ.

        Eh bien, si vous êtes parvenu à ce point et que cela ne marche toujours
        pas, lisez la section FAQ de ce document, voyez le paragraphe spécifique
        à votre carte dans la section ``Informations Spécifiques..'', <em>et si
        cela ne fonctionne toujours pas</> alors vous pourrez recourir à un
        envoi de message dans un groupe de <it>news</> approprié pour demander
        de l'aide. Si vous devez poster un message, veuillez détailler toute
        information intéressante dans ce message, comme la marque de la carte,
        la version du noyau, les messages du pilote au démarrage, le résultat de
        <tt>cat /proc/net/dev</tt>, une description claire du problème, et bien
        entendu ce que vous avez déjà essayé en vue de faire fonctionner
        l'ensemble.

        Vous serez surpris de voir le nombre de personnes qui envoient des
        choses totalement inutiles comme ``Est-ce que quelqu'un peut m'aider~?
        Mon Ethernet ne fonctionne pas.'' et rien d'autre.  Les lecteurs des
        groupes de news ont tendance à ignorer des messages aussi idiots, alors
        qu'une description détaillée et instructive du problème pourra permettre
        à un `gourou-Linux' de résoudre tout de suite votre problème.


<sect>Quelle carte dois-je acheter pour Linux~?<label id="what-card">
<p>
        La réponse à cette question dépend fortement de ce que vous comptez
        faire avec votre connexion réseau, et du volume du trafic qui va y
        passer.

        Si vous vous attendez à ce qu'un seul utilisateur effectue
        occasionnellement une session FTP ou une connexion WWW, alors même une
        vieille carte ISA 8~bits vous contentera probablement.

        Si vous avez l'intention de mettre en place un serveur, et que vous
        exigez que la charge processeur liée à la réception et à la transmission
        des données sur le réseau reste la plus basse possible, vous devrez
        certainement choisir une des cartes PCI, qui utilisent le bus-mastering,
        telles celles comportant la puce tulip (21xxx) de DEC, ou la puce
        PCnet-PCI d'AMD.

        Si vous vous trouvez au milieu de ces deux extrêmes, alors n'importe
        quelle carte PCI bon marché ou une carte ISA 16~bits possédant un pilote
        stable vous conviendra.

<sect1>Quels sont les pilotes stables, alors~?
<p>
        Parmi les cartes ISA 16~bits, les pilotes suivants sont très au point,
        et vous ne devriez pas avoir de problèmes si vous achetez une carte qui
        utilise ces pilotes~:
<quote>
        SMC-Ultra/EtherEZ, SMC-Elite (WD80x3), 3c509, Lance, NE2000.
</quote>

        Cela ne signifie pas que tous les autres pilotes sont instables. Il se
        trouve juste que ceux-ci sont les plus anciens et les plus utilisés des
        pilotes Linux, ce qui en fait le choix le plus sûr.

        Notez que certaines cartes-mères pas chères peuvent avoir des problèmes
        avec le bus-mastering que les cartes ISA Lance utilisent, et que
        certains clones NE2000 bon marché ont des difficultés à être détectés au
        démarrage.

        Les pilotes PCI les plus couramment utilisés sous Linux sont
        probablement le 3Com Vortex/Boomerang (3c59x/3c9xx), le DEC tulip
        (21xxx), et l'EtherExpressPro 100 d'Intel. Les divers clones PCI-NE2000
        sont également très courants, mais l'achat d'une telle carte ne peut se
        justifier que si le critère du prix est plus important que celui des
        performances.

<sect1>Cartes 8~bits contre cartes 16~bits<label id="8-vs-16">
<p>
        Vous ne pourrez certainement plus acheter une carte Ethernet ISA 8~bits
        de nos jours, mais vous en trouverez encore beaucoup dans les années à
        venir sur les marchés aux puces informatiques ou autres braderies, et ce
        à des prix vraiment très bas. Cela les rend idéales pour les systèmes
        ``Ethernet-à-la-maison''. cette constatation est d'ailleurs aussi
        valable pour les cartes ISA 16~bits car les cartes PCI deviennent de
        plus en plus communes.

        La wd8003, la 3c503 et la ne1000 sont des cartes 8~bits qui donneront de
        bonnes performances pour une utilisation faible à modérée.  La 3c501
        donnera des résultats faibles, et ces reliques antédiluviennes
        (12~ans~!) des beaux jours du XT sont à éviter. (Envoyez les a Alan, il
        les collectionne...)

        Le canal de données 8~bits n'atténue pas trop les performances, puisque
        vous pouvez encore espérer obtenir 500 à 800~Ko/s en vitesse de
        transfert FTP pour une carte 8~bits wd8003 (sur un bus ISA rapide) à
        partir d'un serveur rapide. Et si la plupart de votre trafic réseau est
        à destination de sites éloignés, le goulot d'étranglement se situera
        ailleurs sur le chemin, la seule différence de vitesse que vous noterez
        se produisant lorsqu'il y a de l'activité sur votre réseau local.

<sect1>Cartes 32~bits (VLB/EISA/PCI)
<p>
        Notez qu'un réseau à 10~Mbps ne justifie pas l'utilisation d'une
        interface 32~bits.  Consultez~<ref id="data-xfer" name="E/S programmées
        contre...">, qui explique pourquoi avoir une carte Ethernet 10~Mbit/s
        sur un bus ISA à 8~MHz ne constitue vraiment pas un goulot
        d'étranglement. Même si le fait que la carte Ethernet se trouve sur un
        bus rapide ne signifie pas que les transferts sont plus rapides, cela
        entraînera souvent une charge processeur supplémentaire moins
        importante, ce qui est bon pour les systèmes multi-utilisateurs.

        Bien sûr, avec la démocratisation des réseaux 100~Mbps, les cartes
        32~bits deviennent une obligation pour pouvoir tirer avantage de toute
        la bande passante. AMD propose les puces 32~bits PCnet-VLB et PCnet-PCI.
        Consultez~<ref id="pcnet-32" name="AMD PCnet-32"> pour plus
        d'informations sur la version 32~bits de la puce LANCE / PCnet-ISA.

        La puce tulip (21xxx) PCI de DEC est une autre option (voir~<ref
        id="dec-21040" name="DEC 21040">) pour les utilisateurs de puissance. De
        nombreux fabricants proposent des cartes basées sur cette puce, et les
        prix de ces cartes ``sans-nom'' sont généralement bas.

        Les cartes PCI `Vortex' et `Boomerang' de 3Com constituent aussi une
        autre option, et le prix reste correct si vous pouvez en obtenir une
        tant que leur proposition d'évaluation dure. (voir <ref id="vortex"
        name="3c590/3c595">)

        Les cartes EtherExpress Pro 10/100 PCI d'Intel sont aussi connues pour
        marcher plutôt bien avec Linux. (voir <ref id="eepro100"
        name="EtherExpress">).

        Des fabricants de clones ont commencé à produire des clones PCI de
        NE2000, basés sur une puce RealTek ou une puce Winbond. Le pilote Linux
        NE2000 des noyaux 2.0.31 et supérieurs accepte ces cartes. Cependant
        vous ne bénéficierez que de la vitesse plus élevée du bus, puisque ces
        cartes utiliseront encore l'interface du pilote de la NE2000, qui
        commence à dater. Depuis la version 2.0.34 du noyau, un pilote
        specifique à ces cartes <tt>ne2k-pci.c</> est aussi disponible. Il
        devrait être légerement plus efficace que le pilote ISA <tt>ne.c</>

<sect1>Cartes et pilotes 100 M disponibles
<p>
        La liste des matériels 100~M reconnus par Linux à l'heure actuelle est
        la suivante~: les cartes basées sur la puce DEC~21140; les cartes
        3c595/3c90x~Vortex; la EtherExpressPro10/100B; la PCnet-FAST; la SMC
        83c170 (epic100) et la HP 100VG~ANY-LAN.

        Allez aussi jeter un coup d'oeil sur les pages des constructeurs des
        cartes, vous pouvez aussi aller sur l'une des adresse suivantes~:

<!--

XXX - Ajouter les liens vers les autres cartes 100Mbps, ou supprimer celles ci.

        <ref id="vortex" name="3c595"> 
        <ref id="dec-21040" name="DEC 21140">
-->

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html"
                name="Ethernet 100M">
</quote>

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/drivers/100vg.html"
                name="La page 100VG de Donald">
</quote>

<quote>
        <url url="http://alumni.caltech.edu/&tilde;dank/fe/"
                name="La page Fast Ethernet de Dan Kegel">
</quote>

<sect1>100VG contre 100BaseT
<p>
        Le 100BaseT est beaucoup plus répandu que le 100VG et la plaquette
        publicitaire suivante est extraite d'un vieux message désespérement
        bourré d'informations posté par Donald dans <tt>comp.os.linux</>; elle
        résume bien la situation:

        ``Pour ceux qui ne seraient pas au courant, il y a deux normes Ethernet
        en compétition, le 100VG (aussi connu sous le nom de 100baseVG ou encore
        100VG-AnyLAN) et le 100baseT (qui, selon le type du câble, s'appelle
        100bastTx, 100baseT4 ou 100baseFx).

        Le 100VG est arrivé sur le marché le premier, et je sentais qu'il était
        mieux pensé que le 100baseTx. J'étais persuadé qu'il allait gagner, mais
        visiblement ce ne sera pas le cas. HP et al. ont fait plusieurs mauvais
        choix~:

        1) Retarder la norme de manière à ce qu'ils puissent être compatibles
        avec IBM et accepter les trames Token Ring. Cela `semblait une bonne
        idée à l'époque', puisque cela aurait permis aux installations Token
        Ring de se mettre à jour sans devoir faire admettre aux décideurs qu'ils
        avaient fait une énorme bourde en s'alliant avec la mauvaise
        technologie. Mais il n'y avait rien à gagner, parce que les deux types
        de trames ne peuvent pas coexister sur un réseau, parce que Token Ring
        est un monstre de complexité <!-- :( -->, et que IBM a quand même adopté
        100baseT pour finir.

        2) Ne produire que des cartes ISA et EISA. (Un modèle PCI n'a été
        annoncé que récemment.) Le bus ISA est trop lent pour 100~M, et
        relativement peu de machines EISA existent. A l'époque VLB était
        classique, rapide, et économique, PCI restant un choix viable. Mais la
        sagesse des ``anciens'' disait que les serveurs continueraient
        d'utiliser le bus EISA hors de prix.

        3) Ne pas m'envoyer une documentation. Oui, cela a été la raison réelle
        du déclin du 100VG :-). J'ai appelé partout pour obtenir des infos de
        programmation, et tout ce que j'ai pu obtenir a été une brochure de
        quelques pages sur papier glacé de AT&amp;T décrivant combien le jeu de
        puce Regatta était merveilleux.''

        (NDT~: ``La norme 100~BAS~VG~- any~LAN proposée par HP (...) ne reprend
        pas le principe du protocole Ethernet mais utilise le principe du
        <sl>polling</>. L'utilisation du mot Ethernet a donc ici plutôt une
        vocation commerciale. Il faut changer les coupleurs dans les stations de
        travail. Toutefois, on conserve les principaux systèmes de câblage.''
        (Pierre Rolin, <it>in</> ``Réseaux haut débit'', Hermès, 1995). Fin~1997
        plus personne ne parle de~100VG.

        La norme 100baseT4 utilise un câblage catégorie 3~et~4, 100baseTx un
        câblage catégorie~5, 100baseFx de la fibre optique.)


<sect1>Les types de câbles que votre carte peut accepter
       <label id="cable-intro">
<p>
        Si vous mettez en place un petit réseau ``personnel'', vous préférerez
        certainement utiliser le ``thinnet'' ou câble Ethernet fin. C'est le
        modèle avec les connecteurs BNC standards. Le câblage `thinnet', ou
        Ethernet~fin (câble coaxial RG-58) avec les connecteur BNC (en métal, à
        enfoncer puis tourner pour verrouiller) est appelé techniquement
        10Base2.

        La plupart des cartes Ethernet possèdent aussi une version `Combo' qui
        ne coûte que 60~à~150 francs de plus. (NDT~: Amusant comme les écarts de
        prix en dollars se convertissent en écarts de prix en francs~! La
        version anglaise dit ``10 à 20 dollars de plus''. Ces écarts de prix
        sont vrais fin 97.)

        Ces versions `Combo' possèdent les deux interfaces paire torsadée et
        Ethernet fin intégrées, ce qui vous permet de changer d'avis plus
        tard.(NDT~: `Combo' signigie même souvent~: interface RJ-45 (10baseT,
        paire torsadée) + interface BNC (10base2, thinnet) + interface AUI (pour
        <sl>transceiver</> ou câble de descente (drop-cable) gros Ethernet).)

        Les câbles à paires torsadées, avec les connecteurs~RJ-45
        (rectangulaires un peu plus grande que les prises `téléphone') sont
        appelés techniquement 10BaseT. Vous pourrez aussi entendre parler de UTP
        (Unshielded Twisted Pair, paire torsadée non-écrantée ou non-blindée,
        NDT).

        Le vieil Ethernet~`épais' (Thick Ethernet, sur câble coaxial de 10~mm)
        ne se trouve plus que dans les installations anciennes et est
        appelé~10Base5. La prise en forme de D avec 15 broches présente sur
        quelques cartes Ethernet (connecteur AUI) est utilisée pour connecter de
        l'ethernet épais et des transceivers externes.

        Les grandes installations professionnelles utiliseront le plus souvent
        du~10BaseT au lieu de~10Base2. 10Base2 n'offre pas de moyen pour passer
        au 100~Mbit/s, quel que soit le nom qu'on leur donne.

        (NDT~: Professionnellement parlant, en dehors de la fibre optique qui
        est encore hors de prix jusqu'à la machine de l'utilisateur, les
        nouveaux câblages devraient être réalisés en ``Catégorie 5, classe
        D''. Ce type de câblage supporte non seulement 10BaseT, mais aussi
        100BaseT et les nouveaux débits qui apparaissent.

        Pour la maison, vous choisirez entre Ethernet fin (simple et pas cher)
        et une connectique style~RJ-45 (un peu moins simple, un peu plus cher,
        mais plus `propre' électriquement parlant) selon vos envies et votre
        budget~!

        Référez vous a <ref id="cable" name="Cables, Coax..."> pour plus de
        détails sur les différents types de cables.

<sect>Foire Aux Questions (FAQ) - Les questions fréquemment posées
      <label id="faq">
<p>
        Voici quelques unes des questions les plus fréquemment posées à propos
        de l'utilisation de Linux avec une connexion Ethernet. Certaines des
        questions les plus spécifiques sont triées `par ordre de constructeur'.
        Il y a de fortes chances pour que la question que vous voulez poser l'ai
        déjà été, et aie déjà une réponse. Donc, si jamais vous ne trouvez pas
        la réponse ici, vous le trouverez certainement sur une archive de
        newsgroups comme : <url url="http://www.deja.com" name="Dejanews">.

<sect1>Les pilotes `Alpha' -- Comment les obtenir et comment s'en servir
       <label id="alfa">
<p>
        J'ai entendu dire qu'il y avait une version mise-à-jour ou un pilote
        préliminaire/alpha disponible pour ma carte. Où puis-je l'obtenir~?

        Les plus récents des `nouveaux' pilotes peuvent être trouvés sur le site
        FTP de Donald~: <tt>cesdis.gsfc.nasa.gov</> dans la partie
        <tt>/pub/linux/</tt>. Les choses y changent fréquemment, donc jetez-y un
        coup d'oeil de temps à autre. Vous pourrez préférer utiliser un
        navigateur WWW sur~:
<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/"
               name="La page Linux de Don">
</quote>
        pour localiser le pilote que vous cherchez. (Prenez garde aux
        navigateurs WWW qui modifient le source sans rien dire en remplaçant les
        tabulations par des espaces, etc. - si vous n'êtes pas sûr(e), utilisez
        ftp, ou au moins une URL FTP, pour le chargement.)

        Maintenant, s'il s'agit réellement d'un pilote alpha, voire pré-alpha,
        s'il vous plaît considérez-le comme tel~! En d'autres termes, ne vous
        plaignez pas parce que vous n'arrivez pas à comprendre ce que vous devez
        en faire. Si vous ne savez pas comment l'installer, alors vous ne
        devriez certainement pas être en train de le tester. De même, s'il
        plante votre machine, ne vous plaignez pas. Au lieu de cela,
        envoyez-nous un rapport détaillé sur le problème, ou même mieux, un
        patch~!

        Notez que certains des pilotes expérimentaux ou alpha `utilisables' sont
        inclus dans l'arborescence standard du noyau. Lorsque vous exécutez
        <tt>make config</>, l'une des premières choses qui vous sera demandée
        est si vous souhaitez être interrogé(e) sur les pilotes en cours de
        développement (``Prompt for development and/or incomplete
        code/drivers''). Vous devrez répondre~``Y'' (pour `<sl>Yes</>', `Oui') à
        cette question si vous souhaitez être interrogé(e) sur l'inclusion d'un
        pilote alpha ou expérimental.

<sect1>Utiliser plus d'une carte Ethernet par machine<label id="two-card">
<p>
        Que faut-il faire pour que Linux puisse gérer deux cartes Ethernet~?

        La réponse à cette question est différente selon que les pilotes ont été
        compilés directement dans le noyau ou en tant que modules.  De nos
        jours, la majorité des distributions utilisent des pilotes sous forme de
        modules. Ceci permet de ne pas avoir à fournir une tonne de noyaux
        chacun ayant un jeu de pilotes spécifique.  A la place, un petit noyau
        de base est utilisé et les pilotes sont tous compilés en modules, ces
        modules étant chargés à la demande dès que le système est allé assez
        loin dans son démarrage pour accéder aux modules (habituellement dans
        <tt>/lib/modules/</>).

        <em>Avec le pilote chargé en module~:</> Dans le cas de pilotes PCI, le
        module détectera normalement toutes les cartes de même type d'un seul
        coup. Cependant, pour les cartes ISA, la détection automatique n'est
        pas une opération qui marche à coup sûr, et vous aurez très 
        certainement à fournir les adresses d'entrée/sortie de base de la carte
        pour que le module sache où regarder. Ces informations sont placées
        dans le fichier <tt>/etc/conf.modules</tt>.

        Par exemple, supposez qu'un utilisateur ait deux cartes ISA NE2000, une
        à <tt>Ox300</> et l'autre à <tt>0x240</>, il aura les lignes suivantes
        dans son <tt>/etc/conf.modules</tt>~:

<verb>
        alias eth0 ne
        alias eth1 ne
        options ne io=0x240,0x300
</verb>

        Explication~: cela dit que si l'administrateur (ou le noyau) fait un
        <tt>modprobe eth0</> ou un <tt>modprobe eth1</>, alors le pilote
        <tt>ne.o</> devra être chargé pour <tt>eth0</> et <tt>eth1</>. De plus,
        quand le module se chargera, il le sera avec comme options
        <tt>io=0x240,0x300</>. Ainsi, le pilote saura où aller chercher les
        cartes. Notez que le <tt>0x</> est important, des trucs comme
        <tt>300h</> couramment utilisés dans le monde DOS ne marcheront pas. Le
        fait d'inverser <tt>0x240</> et <tt>0x300</> aura pour effet d'inverser
        physiquement <tt>eth0</> et <tt>eth1</>.

        La majorité des pilotes ISA peuvent prendre plusieurs valeurs
        d'entrée/sortie séparées par des virgules comme dans cet exemple pour
        prendre en charge plusieurs cartes. Cependant, certains pilotes (plus
        anciens~?), tels que le module <tt>3c501.o</> sont pour l'instant
        incapables de gérer plus d'une carte par chargement du module. Dans ce
        cas, vous pouvez charger le module deux fois pour avoir les deux cartes
        détectées. Votre <tt>/etc/conf.modules</tt> ressemblerait alors à~:

<verb>
        alias eth0 3c501
        alias eth1 3c501
        options eth0 -o 3c501-0 io=0x280 irq=5
        options eth1 -o 3c501-1 io=0x300 irq=7
</verb>

        Dans cet exemple, l'option <tt>-o</> a été utilisée pour donner à chaque
        instance du module un nom unique, puisqu'il n'est pas possible d'avoir
        deux modules ayant le même nom. L'option <tt>irq=</> a également été
        utilisée, pour indiquer l'interruption materielle de la carte. (Cette
        méthode peut aussi être utilisée pour les modules qui gèrent les listes
        d'adresses d'entrée/sortie, bien qu'elle soit moins efficace, car on se
        retrouve avec le module chargé deux fois alors que cela n'est pas
        nécessaire.)

        Pour finir, voici un exemple avec une carte 3c503 à <tt>0x350</> et une
        SMC Elite16 (wd8013) à <tt>0x280</>. Vous auriez~:

<verb>
        alias eth0 wd
        alias eth1 3c503
        options wd io=0x280
        options 3c503 io=0x350
</verb>

        Pour les cartes PCI, vous avez juste besoin des lignes <tt>alias</> pour
        associer les interface <tt>ethN</> aux pilotes correspondants, puisque
        les adresses d'entrée/sortie des cartes PCI sont automatiquement
        détectées.

        Les modules disponibles sont généralements situés dans le répertoire
        <tt>/lib/modules/`uname -r`/net</tt> où la commande <tt>uname -r</>
        retourne la version du noyau (ex~: 2.0.34). Vous pouvez aller y faire un
        tour pour voir ceux qui sont faits pour votre carte. Puis, lorsque vous
        aurez les bons paramètres dans votre <tt>/etc/conf.modules</tt>, il ne
        vous reste plus qu'à tester avec la commande~:

<verb>
        modprobe ethN
        dmesg | tail
</verb>

        Où N est le numéro de l'interface que vous testez.

        <em>Avec le pilote compilé dans le noyau~:</> Si vous avez le pilote
        compilé dans le noyau, alors, voici tout ce qu'il faut savoir pour
        utiliser plusieurs cartes Ethernet. Toutefois, notez que pour le moment,
        seulement <em>une</> carte Ethernet est détectée automatiquement par
        défaut. Cela contribue à éviter des blocages possibles au moment du
        démarrage, causés par la détection de cartes `sensibles'.

        (Note~: Depuis les derniers noyaux 2.1, la détection des périphériques a
        été découpée en deux parties, celle qui est sûre, et celle qui ne l'est
        pas . Par conséquent, tout ce qui est sûr (ex~: PCI et EISA) sera
        détecté de manière automatique. Les systèmes avec plus d'une carte dont
        une sur un port ISA nécessiteront toujours la procédure suivante.)

        Vous pouvez activer la détection automatique de la deuxième (et de la
        troisième, et de...) carte de deux façons différentes.

        La méthode la plus simple consiste à passer des arguments au noyau au
        moment du démarrage, ce qui est généralement fait par LILO. La détection
        de la deuxième carte peut être obtenue en utilisant un argument de
        démarrage aussi simple que <tt>ether=0,0,eth1</>. Dans ce cas,
        <tt>eth0</> et <tt>eth1</> seront affectés dans l'ordre dans lequel les
        cartes seront trouvées dans cet ordre au démarrage. Par contre, si vous
        souhaitez que la carte sur le port~<tt>0x300</> soit~<tt>eth0</> et que
        la carte sur le port~<tt>0x280</> soit~<tt>eth1</>, vous pourrez
        utiliser

<tscreen>
        LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
</tscreen>

        La commande~<tt>ether=</> accepte plus d'informations que le numéro
        d'IRQ~+ le port~d'E/S~+ le nom qui sont montrés ci-dessus. Veuillez
        consulter~<ref id="lilo" name="Passage des arguments Ethernet..."> pour
        la syntaxe complète, les paramètres spécifiques à chaque carte, et des
        astuces pour LILO.

        Ces arguments de démarrage peuvent être rendus permanents afin de ne pas
        devoir les ré-entrer à chaque fois. Consultez la documentation sur
        l'option de configuration `<tt>append</>' de LILO.

        La seconde méthode (non recommandée) est d'éditer le fichier
        <tt>Space.c</> et de remplacer la valeur <tt>0xffe0</> pour l'adresse
        d'entrée-sortie par un zéro. La valeur <tt>0xffe0</> indique au noyau
        qu'il ne doit pas essayer de détecter ce périphérique --~la remplacer
        par un zéro autorisera l'auto-détection du périphérique.

        Notez que si vous avez l'intention d'utiliser Linux sur une machine qui
        servira de passerelle entre deux réseaux, vous devrez recompiler un
        noyau avec l'option ``IP~forwarding''. Mais généralement un vieil AT/286
        avec quelque chose comme le logiciel `kbridge' est une meilleure
        solution.

        Si vous consultez ce document tout en <sl>surfant</> sur le réseau, vous
        pourrez jeter un coup d'oeil à un <sl>mini-HOWTO</> que Donald a sur son
        site WWW. Consultez~:

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/misc/multicard.html"
        name="Plusieurs Cartes Ethernet">.
</quote>
        <!-- URL française~? -->

<sect1>le <tt>ether=</> n'a rien changé. Pourquoi~?
<p>
        Comme il a été dit précédemment, la commande <tt>ether=</> ne marche
        <em>que</> pour les pilotes qui ont été compilés dans le
        noyau. Maintenant, la majorité des distributions utilisent les pilotes
        dans leur forme modulaire, ce qui fait que la commande <tt>ether=</>
        n'est plus guère utilisée. (Certaines vieilles documentations ont
        peut-être encore à être mises à jour pour refléter ce changement.) Si
        vous voulez passer des options à un pilote modulaire vous <em>devez</>
        faire les changements dans le fichier <tt>/etc/conf.modules</>.

        Si vous utilisez un pilote compilé dans le noyau et avez ajouté la ligne
        <tt>ether=</> à votre fichier de configuration LILO, notez qu'il ne sera
        pris en compte que lorsque vous relancerez <tt>lilo</> pour mettre à
        jour les informations.


<sect1>Problèmes avec les cartes NE1000 / NE2000 (et leurs clones)
       <label id="ne2k-probs">
<p>
        <bf>Problème~:</>
         Une carte PCI clone NE2000 n'est pas détectée au démarrage avec un
         noyau 2.0.x.

        <bf>Raison~:</>
         Le pilote <tt>ne.c</> jusqu'à la version 2.0.30 ne connaît que le
         numéro d'identification PCI des cartes clones basées sur la puce 8029
         de RealTek. Comme depuis beaucoup d'autres ont eux aussi fait des
         cartes PCI clones NE2000, avec des numéro d'identification PCI
         différents, le pilote ne les détecte pas.

        <bf>Solution~:</>
         La solution la plus simple est de mettre à jour votre noyau pour une
         version 2.0.31 (ou plus récente). Cette dernière connaît les
         identificateurs de près de cinq puces NE2000 PCI différentes, et les
         détectera automatiquement au démarrage ou lors du chargement en
         module. Si vous passez à la version 2.0.34 (ou plus récente) du noyau,
         vous aurez un pilote spécifique aux cartes NE2000 PCI, qui est un peu
         plus léger et plus rapide que le pilote ISA/PCI.

        <bf>Problème~:</>
         Ma carte PCI clone NE2000 est indiquée comme étant une NE1000 (une
         carte 8~bits~!) au démarrage ou lorsque je charge le module <tt>ne.o</>
         sous 2.0.x, et par conséquent la carte ne fonctionne pas.

        <bf>Raison~:</>
         Certains clones PCI n'implémentent pas l'accès de largeur un octet (et
         par conséquent ne sont donc pas réellement compatibles NE2000 à
         100&percnt;). Cela entraîne que la procédure de détection pense qu'il
         s'agit de cartes NE1000.

        <bf>Solution~:</>
         Vous devez passer à la version 2.0.31 (ou une version plus récente)
         comme dit ci-dessus. Le pilote vérifie maintenant si ce bug matériel
         est là.

        <bf>Problème~:</>
         Ma carte NE2000 PCI a des performances affreuses, même en réduisant la
         taille de la fenêtre comme il est décrit dans la section sur les trucs
         pour les performances.

        <bf>Raison~:</>
         Les spécifications de la puce~8390 originelle, conçue et vendue il y a
         plus de dix ans, notaient qu'une opération de lecture (depuis la puce)
         était nécessaire avant chaque opération d'écriture pour avoir une
         sécurité maximale. Le pilote possède la fonctionnalité pour le faire
         mais cela a été désactivé par défaut depuis l'époque des versions 1.2
         du noyau. Un utilisateur a indiqué que le fait de réactiver cette
         `contre-fonctionnalité' avait aidé à améliorer les performances sur une
         carte PCI clone de NE2000 bon marché.

        <bf>Solution~:</>
         Puisque cela n'a été rapporté comme solution que par une seule
         personne, ne vous échauffez pas trop. Pour ré-activer le correctif de
         `lecture avant écriture', il suffit d'éditer le fichier du pilote dans
         <tt>linux/drivers/net/</tt>, d'enlever les commentaires qui entourent
         la ligne contenant <tt>NE_RW_BUGFIX</> puis de reconstruire le noyau ou
         le module selon le cas. Merci d'envoyer un courrier décrivant la
         différence de performance et le type de carte~/ de puce que vous avez,
         si cela vous a aidé. (la même chose peut être effectuée sur le fichier
         <tt>ne2k-pci.c</> également).

        <bf>Problème~:</>
         Le pilote <tt>ne2k-pci.c</> donne un message d'erreur ressemblant a
         <tt>timeout waiting for Tx RDC</> avec une carte NE2000 PCI et ne
         marche pas.
        
        <bf>Raison~:</>
         Votre carte et/ou le lien vers le bus PCI ne sait pas gérer les
         optimisations d'E/S du pilote.

        <bf>Solution~:</>
         Tout d'abord, vérifiez les réglages de votre BIOS pour voir si vous
         avez un réglage de timing du bus PCI trop agressif pour des opérations
         stables. Sinon, vous pouvez utiliser le pilote ISA/PCI <tt>ne.c</> (ou
         commenter la ligne <tt>#define USE_LONGIO</> du <tt>ne2k-pci.c</>), ce
         qui vous permettrait d'utiliser la carte.

        <bf>Problème~:</>
         Ma carte ISA Plug and Play NE2000 (telle que la RealTek 8019) n'est pas
         détectée.

        <bf>Raison~:</>
         A l'origine, les spécifications de NE2000 (et par conséquent le pilote
         linux NE2000) ne supportent pas le PnP.

        <bf>Solution~:</> 
         Utilisez la disquette de configuration DOS qui est fournie avec la
         carte pour désactiver le PnP, et pour régler les adresses
         d'entrée/sortie et l'IRQ. Ajoutez une ligne au
         <tt>/etc/conf.modules</tt> telle <tt>options ne io=0xNNN</> ou
         <tt>0xNNN</> est l'adresse d'entrée/sortie en hexadecimal. (Ceci
         suppose l'utilisation des modules, si tel n'est pas le cas, utilisez
         une commande telle <tt>ether=0,0xNNN,eth0</> lors du boot). Vous aurez
         peut être aussi a configurer cette irq dans le BIOS pour qu'elle ne
         soit pas affectée à une carte PnP. D'un autre côté, si vous devez
         laisser le PnP pour rester compatible avec un autre système
         d'exploitation, allez regarder le paquetage <em>isapnptools</>. Essayez
         <tt>man isapnp</> pour voir si il n'est pas déjà installé sur votre
         système. S'il ne l'est pas, allez jeter un coup d'oeil à l'URL~:

         <url url="http://www.roestock.demon.co.uk/isapnptools/" name="ISA PNP
         Tools">

        <bf>Problème~:</>
         Le pilote NE*000 indique `<tt>not found (no reset ack)</>' (carte non
         trouvée, pas d'acquittement de la réinitialisation) pendant la
         procédure de détection au démarrage.

        <bf>Raison~:</>
         Cela est lié au changement précédent. Après la vérification initiale
         qu'une~8390 se trouve à l'adresse d'E/S testée, la réinitialisation est
         effectuée. Quand la carte a terminé sa réinitialisation, elle est
         supposée envoyer un acquittement indiquant que la réinitialisation
         s'est achevée. Votre carte ne l'a pas fait, et le pilote estime donc
         qu'aucune carte NE n'est présente.

        <bf>Solution~:</>
         Vous pouvez indiquer au pilote que vous possédez une <em>mauvaise
         carte</> (<sl>bad card</>) en utilisant une valeur héxadécimale 
         <tt>0xbad</> au moment du démarrage pour le paramètre <tt>mem_end</>
         (qui n'est normalement pas utilisé). Vous <em>devez</> aussi fournir
         une adresse de base non nulle pour les ports d'E/S de la carte quand
         vous utilisez la valeur <tt>0xbad</>. Par exemple, une carte qui se
         trouve à <tt>0x340</> et qui n'acquitte pas la réinitialisation
         utilisera quelque chose comme~:

<tscreen>
        LILO: linux ether=0,0x340,0,0xbad,eth0
</tscreen>

         Cela permettra à la procédure de détection de la carte de continuer,
         même si votre carte n'acquitte pas la réinitialisation. Si vous
         utilisez le pilote comme un module, vous pouvez alors fournir l'option
         <tt>bad=0xbad</> exactement comme vous indiquez l'adresse d'E/S

        <bf>Problème~:</>
         Ma carte NE*000 bloque la machine au premier accès réseau.

        <bf>Raison~:</>
         Ce problème a été rapporté pour des noyaux aussi vieux que le 1.1.57
         jusqu'aux noyaux actuels. Il apparaît être confiné à un petit nombre de
         cartes clones configurables par logiciel. Il apparaît que ces cartes
         s'attendent à être initialisées d'une manière spéciale.

        <bf>Solution~:</>
         De nombreuses personnes ont indiqué que le fait d'exécuter le programme
         DOS de configuration fourni avec la carte et/ou le pilote DOS fourni
         avec la carte avant de redémarrer à chaud (i.e. en utilisant
         <tt>loadlin</> ou le `salut-aux-trois-doigts' (<tt>Ctrl-Alt-Suppr</>,
         NDT)) pour lancer Linux permet à la carte de fonctionner. Ceci
         indiquerait que ces cartes doivent être initialisées d'une façon
         particulière, légèrement différente de ce que le pilote Linux actuel
         réalise.

        <bf>Problème~:</>
         Ma carte Ethernet NE*000 à l'adresse <tt>0x360</> n'est pas détectée.

        <bf>Raison~:</>
         Votre carte NE2000 a une largeur d'espace d'adressage d'E/S de
         <tt>0x20</>, ce qui lui fait atteindre la zone utilisée par le port
         parallèle à l'adresse~<tt>0x378</>. D'autres périphériques pourraient
         se trouver à cet endroit-là, comme le contrôleur du deuxième lecteur de
         disquette (s'il y en a un) à l'adresse <tt>0x370</> et le contrôleur
         IDE secondaire aux adresses <tt>0x376--0x377</>. Si le(s) port(s) sont
         déjà enregistrés par un autre pilote, le noyau ne laissera pas
         s'exécuter la détection.

        <bf>Solution~:</>
         Vous pouvez soit déplacer votre carte vers une adresse d'E/S comme
         <tt>0x280, 0x340, 0x320</>, ou compiler votre noyau sans l'option pour
         l'imprimante parallèle.

        <bf>Problème~:</>
         Le réseau `disparaît' à chaque fois que j'imprime quelque chose
         (NE2000).

        <bf>Raison~:</>
         Même problème que précédemment, mais vous avez un vieux noyau qui ne
         vérifie pas les chevauchements de zones d'adressage d'E/S. Utilisez la
         même solution que ci-dessus, et profitez-en pour récupérer un nouveau
         noyau, tant qu'à faire.

        <bf>Problème~:</>
         <tt>NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid
         signature yy zz)</tt> (carte Ethernet NE*000 testée à l'adresse 0xNNN:
         00 00 C5 ... non trouvée, signature yy zz non valide)

        <bf>Raison~:</>
         Avant tout, avez-vous une carte NE1000 ou NE2000 à l'adresse 0xNNN~? Si
         oui, est-ce que l'adresse matérielle indiquée ressemble à une adresse
         valide~? Si oui, alors vous avez un clone NE*000 bas de gamme. Tous les
         clones NE*000 sont supposés avoir la valeur <tt>0x57</> dans les octets
         14 et 15 de leur SA (Station Address) PROM. La vôtre n'a pas ces
         valeurs -- elle a `yy zz' à la place.

        <bf>Solution~:</>
         Il existe deux moyens de contourner ce problème.

         Le plus simple est d'utiliser une valeur <tt>0xbad</> pour le paramètre
         <tt>mem_end</> comme indiqué ci-dessus pour le problème du
         non-acquittement de la réinitialisation. Cela évitera la vérification
         de la signature, pour autant qu'un port d'E/S non nul soit fourni en
         même temps. De cette façon, aucune recompilation du noyau n'est
         nécessaire.

         La seconde méthode (pour les hackers) nécessite de changer le pilote
         lui-même, puis de recompiler votre noyau (ou le module). Le pilote
         (<tt>/usr/src/linux/drivers/net/ne.c</>) comporte une petite "Galerie
         des horreurs" aux environs de la ligne 42. Cette liste est utilisée
         pour détecter les clones bas de gamme. Par exemple, la carte DFS
         utilise `DFI' dans les trois premiers octets de la PROM, au lieu
         d'utiliser <tt>0x57</> aux octets 14 et 15, tels qu'ils sont supposés
         être.

        <bf>Problème~:</>
         La machine se bloque pendant le démarrage après le
         message~`<tt>8390...</>' ou le message~`<tt>WD....</>'. Le fait
         d'enlever la carte NE2000 résoud le problème.

        <bf>Solution~:</>
         Changez votre adresse d'E/S de base pour une valeur comme <tt>0x340</>.
         Autre solution, vous pouvez utiliser l'argument de démarrage
         ``<tt>reserve=</>'' en conjonction avec l'argument ``<tt>ether=</>''
         pour protéger la carte des procédures de détection des autres pilotes
         de périphériques.

        <bf>Raison~:</>
         Votre clone NE2000 n'est pas un assez bon clone. Une carte NE2000 est
         un puits sans fond qui attirera tout pilote qui tenterait une détection
         dans son espace d'adressage. Le fait de changer la carte NE2000 vers
         une adresse moins populaire l'écartera du chemin des autres procédures
         de détection automatique, permettant à votre machine de démarrer.

        <bf>Problème~:</>
         La machine se bloque pendant la détection du SCSI au démarrage.

        <bf>Raison~:</>
         C'est le même problème que précédemment; changez l'adresse d'E/S de la
         carte Ethernet, ou utilisez les arguments de démarrage <tt>reserve</>
         et <tt>ether</>.

        <bf>Problème~:</>
         La machine se bloque pendant la détection de la carte son au démarrage.

        <bf>Raison~:</>
         Non, en fait c'est pendant la détection silencieuse du~SCSI, et c'est
         le même problème que ci-dessus.

        <bf>Problème~:</>
         Ma carte NE2000 n'est pas détectée au démarrage. Il n'y a aucun message
         pendant le démarrage.

        <bf>Solution~:</>
         Il n'existe pas de `solution magique' parce qu'il existe tout un tas de
         raisons pour qu'elle ne soit pas détectée. La liste suivante devrait
         vous aider à parcourir les problèmes possibles.

        1) Construisez un nouveau noyau ne contenant que les pilotes de
           périphérique dont vous avez besoin. Vérifiez que vous êtes réellement
           en train de démarrer le noyau tout frais. Oublier de lancer
           <tt>lilo</>, etc. peut amener à démarrer l'ancien. (Regardez de près
           la date et l'heure de compilation indiquée au démarrage.) Cela peut
           paraître idiot, mais nous l'avons tous fait un jour. Assurez-vous que
           le pilote est bien inclus dans le nouveau noyau, en consultant le
           fichier <tt>System.map</> à la recherche de noms comme
           <tt>ne_probe</>.

        2) Consultez attentivement les messages au démarrage. Est-ce qu'ils
           mentionnent une tentative de détection d'une NE2000 comme `<tt>NE*000
           probe at 0xNNN: not found (bla bla)</>' ou est-ce que la détection se
           contente d'échouer sans rien dire~? Cela fait une grosse
           différence. Utilisez <tt>dmesg|more</tt> pour relire les messages de
           démarrage après vous être loggé, ou tapez Majuscule+PageUp (page
           précédente) pour faire défiler l'écran vers le haut après que le
           démarrage soit terminé et que le prompt de login soit apparu.

        3) Après le démarrage, faites un <tt>cat /proc/ioports</> et vérifiez
           que tout l'espace d'E/S que la carte demandera est vacant. Si vous
           avez <tt>0x300</> comme adresse de base, alors le pilote NE2000
           demandera la plage d'adresse <tt>0x300-0x31f</>. Si un autre pilote
           de périphérique a enregistré ne serait-ce qu'un port à n'importe quel
           endroit dans cet intervalle, la procédure de détection ne pourra pas
           s'effectuer à cette adresse et continuera sans rien dire jusqu'à la
           prochaine adresse testée. Un cas classique est que le pilote
           <tt>lp</> (imprimante) réserve <tt>0x378</> ou que le second canal
           IDE réserve <tt>0x376</> ce qui empêche le pilote <tt>ne</> de tester
           la plage <tt>0x360-0x380</>.

        4) Même chose que précédemment avec <tt>cat /proc/interrupts</>.
           Assurez-vous qu'aucun autre périphérique n'a enregistré
           l'interruption que vous avez fixée pour la carte Ethernet. Dans ce
           cas, la détection s'effectuera, et le pilote Ethernet se plaindra
           vigoureusement au démarrage de ne pas être capable d'obtenir la ligne
           d'IRQ désirée.

        5) Si vous séchez encore sur l'échec silencieux du pilote, éditez-le et
           ajoutez quelques <tt>printk()</> à la procédure de détection. Par
           exemple, avec une NE2000 vous pouvez ajouter/enlever des lignes
           (marquées respectivement par un '+' ou un '-') dans~<tt>linux/drivers/net/ne.c</>
           comme~:
<code>
    int reg0 = inb_p(ioaddr);

+    printk("NE2k probe - now checking %x\n",ioaddr);
-    if (reg0 == 0xFF)
+    if (reg0 == 0xFF) {
+       printk("NE2k probe - got 0xFF (vacant I/O port)\n");
        return ENODEV;
+    }
</code>

           Le noyau émettra alors des messages pour chaque port qu'il vérifie,
           et vous verrez alors si l'adresse de votre carte a été testée ou non.

        6) Vous pouvez aussi récupérer le programme de diagnostic pour NE2000
           sur le site FTP de Don (indiqué dans le <sl>Howto</>) et regarder
           s'il est capable de détecter votre carte après que vous avez démarré
           Linux. Utilisez l'option `<tt>-p 0xNNN</>' pour lui dire où regarder
           pour la carte. (La valeur par défaut est <tt>0x300</> et il ne va pas
           regarder ailleurs, à la différence de la procédure de détection au
           démarrage.)

           Le résultat, s'il trouve une carte, ressemblera à~:
<code>
Checking the ethercard at 0x300.
  Register 0x0d (0x30d) is 00
  Passed initial NE2000 probe, value 00.
8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00
SA PROM  0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20
SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57

        NE2000 found at 0x300, using start page 0x40 and end page 0x80.
</code>

           Vos valeurs de registres et de PROM seront probablement différentes.
           Notez que toutes les valeurs de la PROM sont doublées pour une carte
           16~bits, et que l'adresse Ethernet (<tt>00:00:c0:b0:05:65</>)
           apparaît dans la première ligne, et que la signature avec le double
           <tt>0x57</> apparaît à la fin de la~PROM.

           Le résultat, s'il n'y a aucune carte installée en~<tt>0x300</>,
           ressemblera à~:
<code>
Checking the ethercard at 0x300.
  Register 0x0d (0x30d) is ff
  Failed initial NE2000 probe, value ff.
8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SA PROM        0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

 Invalid signature found, wordlength 2.
</code>

           Les valeurs <tt>0xff</> apparaissent parce que c'est la valeur qui
           est retournée lorsque l'on lit un port d'E/S vacant. Si vous avez un
           autre matériel dans la zone qui est testée, vous pourrez voir des
           valeurs différentes de <tt>0xff</> aussi.

        7) Essayez de démarrer Linux à chaud depuis une disquette de démarrage
           DOS (via <tt>loadlin</>) après avoir exécuté le pilote DOS fourni ou
           le programme de configuration de la carte. Il se peut qu'il exécute
           quelques tours de passe-passe supplémentaires (c'est-à-dire
           non~standards) pour initialiser la carte.

        8) Essayez le pilote en mode paquet (packet driver) <tt>ne2000.com</> de
           Russ Nelson pour voir s'il peut au moins voir votre carte -- si ce
           n'est pas le cas, alors les choses vont vraiment mal.

        Exemple~:
<tscreen>
        A:> ne2000 0x60 10 0x300
</tscreen>

           Les arguments sont~: le vecteur d'interruption logiciel, l'IRQ
           matérielle, et le port d'E/S. Vous pouvez obtenir ce programme de
           n'importe quelle archive msdos dans le fichier <tt>pktdrv11.zip</> --
           la version actuelle peut avoir un numéro plus récent que 11.


<sect1>Problèmes avec les cartes SMC Ultra/EtherEZ et WD80*3
       <label id="8013-probs">
<p>
        <bf>Problème~:</>
         Vous obtenez des messages semblables à~:
<verb>
        eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
</verb>

        <bf>Raison~:</>
         Il y a un problème de mémoire partagée.

        <bf>Solution~:</>
         Les machines~PCI qui n'ont pas été configurées pour traduire les
         périphériques ISA en mémoire constituent la source la plus courante
         pour ce problème. De fait vous lisez la mémoire vive du PC (toutes les
         valeurs~<tt>0xff</> que donne le message) au lieu de la mémoire vive de
         la carte, qui elle contient les données du paquet reçu.

         D'autres problèmes courants qui eux sont faciles à régler sont des
         conflits de carte, le fait d'avoir activé le cache ou la mémoire morte
         'shadow~ROM' pour cette zone, ou encore de faire fonctionner le bus ISA
         plus vite que 8~MHz. Il existe aussi un nombre étonnant de pannes de la
         mémoire sur les cartes Ethernet, donc utilisez le programme de
         diagnostic si vous en avez un pour votre carte Ethernet.

        <bf>Problème~:</>
         Une carte EtherEZ de SMC ne fonctionne pas en mode de mémoire
         non-partagée~(PIO).

        <bf>Raison~:</>
         Les versions les plus anciennes du pilote Ultra ne pouvaient utiliser
         la carte que dans le mode de travail à mémoire partagée.

        <bf>Solution~:</>
         Le pilote de la version~2.0 (et supérieures) sait aussi utiliser le
         mode d'E/S programmées~(PIO). Mettez votre noyau à jour vers une
         version~2.0 ou plus récente.

        <bf>Problème~:</>
         Une vieille wd8003 et/ou une~wd8013 configurable par cavaliers ont
         toujours la mauvaise~IRQ.

        <bf>Raison~:</>
         Les vieilles cartes wd8003 et les clones wd8013 configurables par
         cavaliers ne possèdent pas l'EEPROM que le pilote sait lire pour y
         trouver le paramétrage de l'IRQ. Si le pilote ne sait pas lire l'IRQ,
         il essaie de déterminer automatiquement l'IRQ. Et si la procédure de
         détection automatique retourne zéro, le pilote se contente d'affecter
         l'IRQ~5 pour une carte 8~bits ou l'IRQ~10 pour une carte 16~bits.

        <bf>Solution~:</>
         Evitez le code de détection automatique de l'IRQ, et indiquez au noyau
         la valeur d'IRQ que vous avez configurée sur la carte avec les
         cavaliers en la lui passant comme argument dans votre fichier de
         configuration de modules (ou au démarrage si vous l'avez compilé dans
         le noyau).

        <bf>Problème~:</>
         Une carte SMC~Ultra est détectée comme étant une wd8013, mais l'IRQ et
         l'adresse de base de la mémoire partagée sont fausses.

        <bf>Raison~:</>
         La carte~Ultra ressemble beaucoup à une~wd8013, et si le pilote Ultra
         n'est pas présent dans le noyau, le pilote~wd peut identifier l'Ultra
         comme étant une wd8013. Le test de détection de l'Ultra vient avant
         celui de la~wd, donc ceci ne devrait normalement pas se produire.
         L'Ultra stocke l'IRQ et l'adresse de base dans son EEPROM de façon
         différente à celle d'une wd8013, d'où les valeurs erronées indiquées
         par le pilote.

        <bf>Solution~:</>
         Recompilez le noyau en n'intégrant que les pilotes dont vous avez
         besoin. Si vous avez un mélange de cartes wd~et~Ultra dans une machine,
         et que vous utilisez les modules, chargez le module ultra en premier.

<sect1>Problèmes avec des cartes 3Com<label id="3com-probs">
<p>
        <bf>Problème~:</>
         La 3c503 prend l'IRQ~N, mais celle-ci est requise par un autre
         périphérique qui a besoin de l'IRQ~N (par exemple un pilote de CD-ROM,
         un modem, etc.). Est-ce que cela peut être réparé sans devoir le
         compiler dans le noyau~?

        <bf>Solution~:</>
         Le pilote 3c503 recherche une ligne d'IRQ libre dans
         l'ordre~{5,~9/2,~3,~4}, et il devrait prendre une ligne qui n'a pas été
         utilisée. Le pilote effectue ce choix lorsque la carte est
         configurée~(<tt>ifconfig</>).

         Si vous utilisez un pilote en module, vous pouvez vous servir des
         paramètres du module afin de choisir diverses choses, y compris la
         valeur d'IRQ.

         Ce qui suit sélectionne l'IRQ~9, adresse de base~<tt>0x300</>, &lt;une valeur
         ignorée&gt;, et le port~<tt>if_port</> numéro~1 (le transceiver
         externe).
<tscreen>
        io=0x300 irq=9 xcvr=1
</tscreen>

         Autrement, si le pilote est compilé dans le noyau, vous pouvez choisir
         les mêmes valeurs en passant des paramètres <it>via</> LILO.
<tscreen>
      LILO: linux ether=9,0x300,0,1,eth0
</tscreen>

         Ce qui suit sélectionne l'IRQ~3, détecte l'adresse de base, &lt;une
         valeur ignorée&gt;, et le port par défaut~(<tt>if_port</>) numéro~0 (le
         transceiver interne).
<tscreen>
      LILO: linux ether=3,0,0,0,eth0
</tscreen>

        <bf>Problème~:</>
         <tt>3c503: configured interrupt X invalid, will use autoIRQ.</tt>
         (3c503: l'interruption X configurée est invalide, détection automatique
         de l'IRQ)

        <bf>Raison~:</>
         La 3c503 ne peut utiliser que l'une des IRQ~5, 2/9, 3~ou~4 (ce sont les
         seules lignes d'IRQ qui sont connectées à la carte). Si vous passez en
         argument au noyau une valeur d'IRQ qui n'est pas dans cet ensemble,
         vous obtiendrez le message ci-dessus. Normalement, il n'est pas
         nécessaire de spécifier une valeur d'interruption pour la 3c503. Elle
         passera en détection automatique lorsqu'elle sera configurée (par
         <tt>ifconfig</>), et elle prendra l'une des IRQ~5, 2/9, 3~ou~4.

        <bf>Solution~:</>
         Utilisez l'une des IRQ~valides données ci-dessus, ou autorisez la
         détection automatique en ne précisant aucune ligne d'IRQ.

        <bf>Problème~:</>
         Le pilote 3c503 fourni n'utilise pas le port~AUI (gros Ethernet).
         Comment faire pour le choisir au lieu du port Ethernet~fin par défaut~?

        <bf>Solution~:</>
         Le port~AUI peut être sélectionné au démarrage pour les pilotes
         compilés dans le noyau, et lors de l'insertion du module pour les
         pilotes modulaires. La sélection est réalisée par le bit de poids le
         plus faible de la variable <tt>dev-&gt;rmem_start</> qui n'est
         actuellement pas utilisée, donc un paramètre de démarrage comme~:
<tscreen>
        LILO: linux ether=0,0,0,1,eth0
</tscreen>
         devrait fonctionner pour les pilotes compilés dans le noyau.

         Pour spécifier le port~AUI lorsque vous chargez un module, ajoutez
         simplement <tt>xcvr=1</> à la ligne d'options du module avec vos
         valeurs de port d'E/S et d'IRQ.


<sect1>Les questions qui ne sont pas spécifiques à une carte.
<p>


<sect2>Linux et les cartes Ethernet ISA Plug and Play
<p>
        Pour de meilleurs résultats (et au moins, rien qui empire) il est
        recommandé que vous utilisiez le petit programme qui a été livré avec la
        carte pour désactiver le mécanisme PnP, et régler la carte pour utiliser
        une IRQ et une adresse d'E/S fixe. Assurez-vous que l'adresse d'E/S que
        vous allez utiliser est testée lors du boot, ou si vous utilisez des
        modules, donnez les adresses avec une option <tt>io=</> dans
        votre <tt>/etc/conf.modules</>. Vous aurez certainement aussi à entrer
        dans le BIOS et à marquer l'IRQ en question comme utilisée par une carte
        ISA, et non disponible pour le PnP (si votre ordinateur à cette option).

        Notez que vous n'avez pas besoin d'installer le DOS pour lancer la
        configuration. Vous n'aurez besoin que d'une disquette de boot DOS et de
        lancer le programme depuis la disquette fournie. Vous pouvez aussi
        télécharger OpenDOS ou FreeDOS gratuitement.

        Si vous avez besoin d'avoir le PnP activé pour rester compatible avec un
        autre système d'exploitation, alors, vous aurez à utiliser le paquetage
        isapnptools avec Linux pour configurer la carte à chaque boot. Vous
        aurez quand même à vous assurer que l'adresse d'E/S est testée par le
        pilote au démarrage, ou fourni comme option <tt>io=</>.


<sect2>Carte Ethernet non détectée au démarrage.
<p>
        La raison habituelle de cet état de fait est que les gens utilisent un
        noyau qui ne contient pas le code pour leur carte à eux. Pour un noyau
        modulaire, cela signifie généralement que le chargement du module
        nécessaire n'a pas été demandé, ou qu'une adresse d'E/S a besoin d'être
        spécifiée comme option du module.

        Si vous utilisez un noyau basé sur les modules, comme ceux installés par
        la plupart des distributions Linux, essayez alors d'utiliser
        l'utilitaire de configuration de la distribution pour sélectionner le
        module destiné à votre carte. Pour les cartes~ISA, c'est une bonne idée
        que de déterminer l'adresse d'E/S de la carte et de l'ajouter comme
        option (p.~ex. <tt>io=0x340</>) si l'utilitaire de configuration vous le
        demande. S'il n'y a pas d'utilitaire de configuration, vous devrez alors
        ajouter le nom exact du module (et ses options) au fichier
        <tt>/etc/conf.modules</> --~lisez <tt>man modprobe</> pour plus de
        détails.

        Si vous utilisez un noyau précompilé qui provient d'une distribution
        Linux, vérifiez dans la documentation quel noyau vous avez installé, et
        s'il a été construit en incluant le code pour votre carte à vous. Si ce
        n'est pas le cas, vous pouvez soit essayer d'en obtenir un qui contient
        le code pour votre carte, soit construire votre propre noyau.

        C'est en général une bonne chose que de construire votre propre noyau,
        ne contenant que les pilotes dont vous avez besoin, car cela diminue
        considérablement la taille du noyau (préservant d'autant votre précieuse
        mémoire vive pour les applications~!) et cela réduit le nombre de
        procédure de détection de périphériques qui peuvent déranger le matériel
        un peu sensible. Construire un nouveau noyau n'est pas aussi compliqué
        que cela peut paraître. Vous devez juste répondre oui ou non à toute une
        série de questions sur les pilotes que vous voulez, et le système fait
        le reste.

        La seconde raison essentielle est qu'un autre périphérique utilise une
        partie de l'espace d'adressage d'entrée-sortie dont votre carte a
        besoin. La plupart des cartes ont une zone d'adressage qui mesure 16~ou
        32~bits de largeur. Si votre carte est positionnée en~<tt>0x300</> et
        qu'elle prend 32~octets, alors le pilote demandera la plage d'adresses
        <tt>0x300-0x31f</>. Si un autre pilote de périphérique a enregistré ne
        serait-ce qu'un port d'entrée-sortie, où que ce soit dans cet
        intervalle, la procédure de détection n'aura pas lieu à cette adresse et
        le pilote continuera sans rien dire à l'adresse suivante à tester. Donc,
        après le démarrage, faites un <tt>cat /proc/ioports</tt> et vérifiez que
        tout l'espace d'adressage d'entrée-sortie que la carte demandera est
        bien disponible.

        Autre problème~: votre carte est configurée pour une adresse
        d'entrée-sortie qui n'est pas testée par défaut. La liste des adresses
        testées pour chaque carte est disponible juste après les commentaires de
        début dans chaque fichier source. Même si la configuration d'E/S de
        votre carte n'est pas dans la liste des adresses testées, vous pouvez
        l'indiquer au démarrage (pour les pilotes compilés dans le noyeau en
        utilisant la commande~<tt>ether=</> comme il est décrit dans~<ref
        id="lilo" name="Passage des arguments Ethernet...">. Les pilotes
        modulaires peuvent utiliser l'option~<tt>io=</> dans le fichier
        <tt>/etc/conf.modules</> afin de spécifier une adresse qui n'est pas
        testée par défaut.


<sect2><tt>ifconfig</> indique la mauvaise adresse d'E/S pour la carte.
<p>
        Non, ce n'est pas vrai. C'est vous qui l'interprétez de manière
        erronée. Ce n'est~<em>pas</> une erreur, et les nombres indiqués sont
        corrects. Ce qu'il se passe, c'est que certaines cartes à base de~8390
        (wd80x3, smc-ultra, etc.) sont telles que la puce~8390 se trouve décalée
        par rapport au premier port~d'E/S affecté. Il s'agit de la valeur
        stockée dans~<tt>dev->base_addr</>, qui est celle que <tt>ifconfig</>
        indique. Si vous souhaitez voir l'intervalle complet d'adresses de ports
        que votre carte utilise, vous devriez essayer <tt>cat /proc/ioports</tt>
        qui vous donnera le nombre que vous attendez.

<sect2>Une machine PCI détecte la carte mais la procédure de test du pilote
échoue.
<p>
        Certains BIOS~PCI peuvent ne pas activer toutes les cartes~PCI lors de
        l'allumage de la machine, spécialement si l'option `PNP~OS' du BIOS est
        activée. Cette contre-fonctionnalité est destinée à supporter la version
        actuelle de Windows qui utilise encore des pilotes en mode réel. Vous
        pouvez soit inhiber cette option, soit essayer de mettre à jour votre
        pilote pour une version qui comprend le code capable d'activer une carte
        désactivée.

<sect2>Des cartes ISA à mémoire partagée ne fonctionnent pas dans une machine
PCI (<tt>0xffff</>)
<p>
        Ce problème se révèle habituellement sous la forme d'une série de
        valeurs~<tt>0xffff</> en lecture. Aucune carte à mémoire partagée de
        quelque type que ce soit ne fonctionnera dans une machine~PCI à moins
        que vous n'ayez configuré correctement le BIOS~PCI (<tt>PCI ROM
        BIOS/CMOS SETUP</> ou quelque chose comme ça). Vous devez le configurer
        pour permettre l'accès à la mémoire partagée depuis le bus ISA pour la
        zone d'adresses que votre carte essaie d'utiliser. Si vous n'arrivez pas
        à déterminer quels paramètres sont concernés, interrogez votre revendeur
        ou votre gourou informatique local. Dans un BIOS~AMI (American
        Megatrends Inc.), il existe en général une section ``Plug and Play'' où
        se trouveront sans doute des paramètres ``ISA Shared Memory Size''
        (taille de la mémoire partagée ISA) et ``ISA Shared Memory Base''
        (adresse de base de la mémoire partagée ISA). Pour des cartes comme
        la~wd8013 et la SMC~Ultra, changez la taille de sa valeur par défaut
        (`Disabled', désactivé) à une valeur de 16~Ko, et changez l'adresse de
        base en prenant l'adresse de base de mémoire partagée qui correspond à
        votre carte.

<sect2>On dirait que ma carte envoie des données, mais elle ne reçoit jamais
rien.
<p>
        Faites un <tt>cat /proc/interrupts</tt>. Le nombre total d'interruptions
        générées par la carte vous sera donné. S'il est à zéro et qu'il
        n'augmente pas lorsque vous essayez d'utiliser la carte, alors, il y a
        très certainement un conflit d'interruptions entre la carte et un autre
        périphérique installé (que le pilote de l'autre soit chargé ou non). La
        seule solution est de changer l'IRQ de l'un des deux périphériques pour
        une autre IRQ non utilisée.

<!--
<sect2>Les machines NexGen obtiennent des erreurs `mismatched read page
pointers'.
<p>
        Un problème dans le processeur NexGen fait que tous les utilisateurs de
        cartes basées sur la puce~8390 (wd80x3, 3c503, SMC Ultra/EtherEZ,
        ne2000, etc.) obtiennent ces messages d'erreur. Les versions du noyau
        2.0 et supérieures n'ont pas ces problèmes.

        Mettez votre noyau à jour.
-->

<sect2>Asynchronous Transfer Mode (ATM)
<p>
        Werner Almesberger s'est préoccupé de la disponibilité d'ATM pour Linux.
        Il a travaillé avec la carte~ENI155p d'Efficient Networks (<url
        url="http://www.efficient.com/" name="Efficient Networks">) et la
        carte~ZN1221 de Zeitnet (<url url="http://www.zeitnet.com/"
        name="Zeitnet">).

        Werner dit que le pilote de la~ENI155p est relativement stable, tandis
        que celui de la~ZN1221 n'est actuellement pas terminé.

        Consultez les dernières informations et les mises à jour à l'URL
        suivante~:
<quote>
        <url url="http://lrcwww.epfl.ch/linux-atm/"
             name="Linux et ATM">
</quote>

<sect2>Support de l'Ethernet Gigabit
<p>
        Où en est le support Ethernet Gigabit pour Linux~?

        Il y a pour le moment au moins deux supports. Un pilote pour
        l'adaptateur Ethernet Gigabit G-NIC PCI de Packet Engines est disponible
        dans les versions 2.0 et 2.2 du noyau. Pour plus de détails,
        d'information, et les mises à jour du pilote, consultez~:

<quote>
        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html</tt>
</quote>

        Le pilote <tt>acenic.c</> disponible dans les noyaux 2.2 peut être
        utilisé pour la carte Ethernet Gigabit Alteon AceNIC et d'autres cartes
        basées sur le chipset Tigon comme la 3Com 3c985. Le pilote devrait aussi
        fonctionner avec la NetGear GA620, mais cela n'a pas encore été vérifié.


<sect2>FDDI
<p>
        Qu'en est-il de FDDI sous Linux~?

        Cela fonctionne. Larry Stefani a écrit un pilote pour la version~2.0 du
        noyau pour les cartes~DEFEA (FDDI EISA) et~DEFPA (FDDI PCI) de~DEC
        (Digital Equipment Corporation). Il a été inclus dans la version~2.0.24
        du noyau. Néanmoins, ce sont les seules cartes qui fonctionnent sous
        Linux actuellement.


<sect2>Full Duplex
<p>
        Est-ce que le mode Full~Duplex me donnera 20~Mbit/s~? Est-ce que Linux
        sait faire du Full~Duplex~?

        Cameron Spitzer écrit ce qui suit à propos des cartes Full~Duplex
        10Base-T~:

        ``Si vous connectez une carte Full Duplex à un hub (NDT~: un switch)
        Full~Duplex, et que votre système est suffisamment rapide et ne fait pas
        grand-chose d'autre, il pourra maintenir le lien occupé dans les deux
        directions.

        Le Full~Duplex 10Base-2 ou 10Base-5 (coaxial fin et gros coaxial) ne
        peut pas exister. Le mode Full~Duplex fontionne en inhibant la détection
        des collisions dans l'adaptateur réseau. C'est pour cela que vous ne
        pouvez pas le faire avec un coax~: le réseau ne fonctionnerait pas si
        c'était le cas.

        Par contre, 10Base-T (l'interface~RJ-45) utilise des (paires de) fils
        séparées pour l'émission et la réception, donc il est possible de
        travailler dans les deux sens en même temps. Le (hub) switch s'occupe du
        problème des collisions. La vitesse de signalisation reste à
        10~Mbit/s.''

        Donc, comme vous pouvez voir, vous ne serez encore capable de recevoir
        ou de transmettre qu'à 10~Mbit/s; n'attendez donc pas une multiplication
        par deux des performances. Quant à savoir si cela est possible ou non,
        cela dépend de la carte et peut-être du pilote.  Certaines cartes
        pratiquent l'auto-négociation, d'autres auront besoin de l'aide du
        pilote, et d'autres auront besoin que l'utilisateur choisisse une option
        dans la configuration sur EEPROM de la carte. De toute façon, seule une
        utilisation sérieuse/lourde montrera une différence entre les deux
        modes.


<sect2>Les machines SMP et les cartes Ethernet
<p>
        Si vous avez dépensé un peu d'argent en plus pour avoir une machine
        multiprocesseur (MP), alors, vous devriez aussi vous payer une bonne
        carte Ethernet. Pour les versions 2.0, cela n'était pas vraiment une
        obligation, mais avec l'avènement des 2.2, cela est devenu
        nécessaire. La majorité des vieilles cartes (ex~: ISA, PIO et avec accès
        partagé à la mémoire) n'ont pas été conçues en pensant aux machines
        multiprocesseurs. Par conséquent, il vous faudra acheter une carte de
        facture récente, et vous assurer que le pilote a été mis a jour pour
        gérer les opérations multiprocesseurs. (Le plus important, c'est le "de
        facture récente" - les PCI-NE2000 sont juste des trucs vieux de plus de
        10 ans sur un bus récent.) Chercher <tt>spin_lock</> dans les sources
        d'un pilote donne une bonne indication sur le fait que le pilote a été
        prévu pour marcher sur les machines multiprocesseurs. Pour plus de
        détails sur pourquoi vous devez prendre une bonne carte pour le MP (et
        ce qui se passera si vous ne le faites pas) se trouve ci dessous~:

        Dans la version 2.0 des noyaux, seul un processeur était autorisé a
        passer en `mode noyau' (ex~: changer des données dans le noyau, ou
        accéder aux périphériques), quelque soit le moment. Donc, du point de
        vue de la carte (et du pilote associé) il n'y avait aucune différence
        avec le fonctionnement en monoprocesseur (UP) et tout continuait à
        marcher comme si de rien n'était. (C'était la façon la plus simple de
        faire du multiprocesseur avec Linux à ce moment-là. De cette manière,
        vous savez qu'il n'est pas possible que deux processeurs essayent de
        changer la même chose au même moment~!)

        L'inconvénient de n'autoriser qu'un seul processeur à être en mode noyau
        au même moment était que vous n'aviez de vraies performances MP que si
        les programmes faisaient surtout du calcul sans accéder à la machine. Si
        les programmes faisaient beaucoup d'opérations d'entrées sorties (E/S),
        comme par exemple lire ou écrire sur un disque ou à travers un réseau,
        alors, tous les processeurs sauf un étaient en attente d'une opération
        d'E/S pendant que le seul processeur en mode noyau essayait de faire
        plaisir à tout le monde à la fois. Le noyau devient le goulot
        d'étranglement et comme un seul processeur est autorisé à exécuter le
        noyau, les performances d'une machine MP se réduisaient rapidement à
        celles d'une machine UP.

        Comme cela est clairement loin de l'idéal (spécialement pour les
        serveurs de fichiers, les serveurs WWW, les routeurs, etc...) les
        versions 2.2 des noyaux ont largement amélioré tout ce qui touche aux
        verrouillages - et par conséquent, plus d'un processeur peut être en
        mode noyau à un instant donné. A la place d'un énorme verrou autour du
        noyau dans sa globalité, il y a beaucoup plus de verrous plus petits qui
        empêchent les données critiques d'êtres manipulées par plus d'un
        processeur à la fois - ex~: un processeur peut s'occuper du réseau alors
        qu'un autre peut écrire sur un disque au même moment.

        Ok, avec tout cela en tête, voici deux petits problèmes~: Des verrous
        plus localisés signifient qu'il peut y avoir un processeur essayant
        d'envoyer les données via le pilote ethernet pendant qu'un autre
        processeur essaye d'accéder à la carte pour autre chose (par exemple
        pour récupérer les statistiques pour <tt>cat /proc/net/dev</>). Et hop -
        les statistiques ont été envoyées par la carte et vous avez récupéré les
        données à envoyer pour les statistiques. Eh oui, la carte a bien été
        embêtée de recevoir plusieurs demandes à la fois, et il y a de fortes
        chance que cela ait planté la machine du même coup.

        Par conséquent, le pilote qui marchait pour les machines UP n'est
        désormais plus vraiment utilisable - on doit y ajouter des verrous qui
        contrôlent l'accès à la carte pour que les 3 actions de recevoir,
        émettre et manipuler les données puissent être utilisées à divers degrés
        d'opération. Le truc qui peut faire peur est qu'un pilote qui n'a pas
        été mis a jour pour fonctionner de manière stable en MP marchera très
        probablement si le réseau n'est pas chargé, mais fera planter la machine
        ou fera de drôles de choses lorsque deux (ou plus~!) processeurs
        essaieront de faire plus d'une de ces opérations au même moment.

        Les pilotes ethernet gérant le MP requièreront (au minimum) un
        verrouillage englobant tout le pilote pour qu'il fonctionne sur le
        principe de `chacun son tour'. Avec ce mécanisme mis en place, les
        choses seront mises en files d'attente et le matériel sera utilisé de la
        même manière qu'en mode UP, et par conséquent, devrait être stable. Le
        coté négatif est que un verrouillage englobant le pilote ethernet a
        presque d'aussi mauvaises performances qu'un verrou global sur le noyau
        (mais a une échelle plus réduite) - c'est à dire que vous ne pouvez
        avoir qu'un seul processeur travaillant avec la carte à la
        fois. &lsqb;Note technique~: L'impact sur les performances peut aussi
        inclure l'augmentation des temps de latence sur les interruptions si les
        verrous qui ont besoin d'être ajoutés sont du type <tt>irqsave</> et
        qu'ils sont tenus fermés pour un long moment.&rsqb;

        Il existe deux voies d'amélioration possibles à partir de cette
        situation.  Vous pouvez essayer de minimiser le temps entre le moment où
        le verrou est fermé et quand il est relâché et/ou vous pouvez trouver
        une manière plus fine, avec plus de verrous (ex~: un verrou global sur
        le pilote ne serait pas nécessaire si quelques verrous protégeant
        quelques registres/réglages critiques suffisent).

        Toutefois, pour les vieilles cartes débiles qui n'ont pas été conçues
        dans l'esprit du MP, aucune de ces améliorations n'est possible.
        Le pire est que ces pauvres cartes requièrent que le processeur déplace
        les données de la carte vers la mémoire de l'ordinateur, donc, dans le
        pire des cas le verrou sera fermé pour toute la durée que chaque paquet
        de 1,5 Ko mettra à transiter à travers le bus ISA.

        Les cartes plus récentes déplacent leurs données de et vers la mémoire
        sans avoir recours au processeur. Ceci est une grande amélioration car
        le verrouillage ne dure que le court instant où le processeur dit à la
        carte où dans la mémoire prendre/mettre les données. Les cartes de
        facture récente ne sont d'ailleurs pas faites pour avoir un verrou
        global autour du pilote.

<sect2>Cartes Ethernet pour Linux sur carte-mère PCI Alpha/AXP
<p>
        En ce qui concerne les versions~2.0, seules les cartes~3C509, depca,
        de4x5, lance32, et tous les pilotes pour~8390 (wd, smc-ultra, ne, 3c503,
        etc.) ont été rendus `indépendants de l'architecture' de façon à pouvoir
        fonctionner sur les systèmes basés sur les processeurs~Alpha de
        DEC. D'autres pilotes PCI mis à jour sont disponibles sur la page WWW de
        Donald marcheront certainement, puisqu'ils ont été créés pour être
        indépendants de l'architecture.

        Notez que les changements à faire pour que le pilote ne soit pas
        dépendant de l'architecture ne sont pas aussi compliqués que cela peut
        paraître. Vous n'avez besoin que de~:

        - multiplier toutes les valeurs relatives à des <tt>jiffies</> par
        <tt>HZ/100</tt> pour prendre en compte la valeur différente de <tt>HZ</>
        utilisée par l'Alpha. (c'est-à-dire que <tt>timeout=2;</> devient
        <tt>timeout=2*HZ/100;</tt>)

        - remplacer tout déréférencement de pointeur en mémoire d'E/S (640k~à
        1Mo) par les appels <tt>readb() writeb() readl() writel()</tt>
        appropriés, comme le montre cet exemple~:
<code>
-       int *mem_base = (int *)dev->mem_start;
-       mem_base[0] = 0xba5eba5e;
+       unsigned long mem_base = dev->mem_start;
+       writel(0xba5eba5e, mem_base);
</code>

        - remplacer tous les appels à~<tt>memcpy()</> qui ont des adresses
        mémoire sur la plage~d'E/S comme source ou comme destination par
        un appel à~<tt>memcpy_fromio()</> ou à~<tt>memcpy_toio()</> selon le
        cas.

        Vous trouverez plus de détails sur la manière de gérer les accès
        mémoire d'une façon indépendante de l'architecture dans le fichier
        <tt>linux/Documentation/IO-mapping.txt</tt> qui est présent dans les
        noyaux récents.

<sect2>L'Ethernet et Linux sur les SUN/Sparc.
<p>
        Pour les dernières informations à propos des Sparc, essayez donc l'URL
        suivante~:

        <url url="http://www.geog.ubc.ca/sparc" name="Linux Sparc">

        Notez que quelques adaptateurs ethernet pour Sparc récupèrent leurs
        adresses MAC depuis l'ordinateur hôte, et que par conséquent, vous
        pourriez vous retrouver avec plusieurs interfaces ayant toutes les mêmes
        adresses MAC. Si vous devez mettre plusieurs interfaces sur la même
        machine, alors, vous aurez à utiliser l'option <tt>hw</> de
        <tt>ifconfig</> pour assigner une unique adresse MAC.

        Les problèmes de portage des pilotes PCI vers la plate-forme Sparc sont
        les mêmes que pour la plate-forme AXP. En plus, il y aura certainement
        des problèmes d'ordre des octets, le Sparc étant grand boutiste alors
        que les AXP et ix86 sont petits boutistes.


<sect2>L'Ethernet, Linux et les autres architectures.
<p>
        Il y a beaucoup d'autres plate formes sur lesquelles Linux tourne, comme
        les Atari/Amiga (m68k). Tout comme dans le cas des Sparc, le mieux est
        de vérifier sur la page principale du port pour savoir ce qui est
        supporté. (Des pointeurs seraient bienvenus - envoyez les~!)


<sect2>Relier deux 10 et 100 BaseT sans hub
<p>
        Est-ce que je peux relier deux systèmes basés sur du 10/100BaseT~(RJ45)
        sans utiliser de hub~?

        Vous pouvez relier facilement deux machines, mais pas plus que cela,
        sans boîtier supplémentaire. Consultez la section~<ref id="utp"
        name="Paire torsadée"> qui explique comment faire.

        Par contre, non, vous n'arriverez pas à bricoler un hub en croisant
        quelques fils et autres trucs du genre. Il est pratiquement impossible
        de générer correctement le signal de collision sans refaire un hub.

<sect2>SIOCSIFxxx: No such device
<p>
        J'obtiens un nombre impressionnant de messages `<tt>SIOCSIFxxx: No such
        device</>' au démarrage, suivis par un `<tt>SIOCADDRT: Network is
        unreachable</>'. Qu'est-ce qui ne va pas~?

        Votre périphérique Ethernet n'a pas été détecté pendant le démarrage~/
        lors de l'insertion du module, et lorsque <tt>ifconfig</>~et
        <tt>route</> sont exécutés, ils n'ont aucun périphérique avec lequel
        travailler. Utilisez <tt>dmesg | more</tt> pour consulter les messages
        du démarrage et regardez s'il y a un (ou des) message(s) à propos de la
        détection de carte Ethernet.

<sect2>SIOCSFFLAGS: Try again
<p>
        J'obtiens `<tt>SIOCSFFLAGS: Try again</>' lorsque j'exécute
        <tt>ifconfig</> -- Euh..~?

        Un autre périphérique a pris l'IRQ que votre carte Ethernet essaie
        d'utiliser, ce qui fait que la carte ne peut pas utiliser l'IRQ. Vous
        n'avez pas nécessairement besoin de redémarrer pour résoudre ce
        problème, car certains périphériques ne prennent les~IRQ que lorsqu'ils
        en ont besoin, et les rendent quand ils ont fini. C'est le cas par
        exemple des cartes son, des ports série, du pilote du lecteur de
        disquette, etc. Vous pouvez taper <tt>cat /proc/interrupts</tt> pour
        voir quelles interruptions sont actuellement <em>en cours
        d'utilisation</>. La plupart des pilotes de carte Ethernet sous Linux
        ne prennent l'IRQ que lorsqu'ils sont ouverts via `<tt>ifconfig</>'. Si
        vous réussissez à faire en sorte que l'autre périphérique `relâche' la
        ligne d'IRQ, alors vous serez capable de réessayer (<sl>Try again</> en
        anglais) avec~<tt>ifconfig</>.

<sect2>Utilisation de `ifconfig' et message `Link UNSPEC with HW-addr of
00:00:00:00:00:00'
<p>
        Lorsque j'utilise <tt>ifconfig</> sans argument, il indique <tt>Link
        UNPSEC</> (au lieu de `Ethernet 10Mbs') et il dit aussi que mon adresse
        physique est à zéro.

        C'est parce que les gens utilisent une version du programme `ifconfig'
        plus récente que leur version de noyau. Cette nouvelle version de
        `ifconfig' est incapable de fournir ces informations quand elle est
        utilisée en conjonction avec un noyau plus ancien. Vous pouvez soit
        mettre votre noyau à jour, soit prendre une version plus ancienne
        d'<tt>ifconfig</>, ou simplement ignorer le problème. Le noyau connaît
        votre adresse physique, donc le fait que <tt>ifconfig</> ne puisse pas
        la lire n'est pas vraiment important.

        Vous pourrez aussi obtenir des informations étranges si le programme
        <tt>ifconfig</> que vous utilisez est beaucoup plus vieux que votre
        noyau.

<sect2>Nombre faramineux d'erreurs en réception (RX Errors) et en transmission
(TX Errors)
<p>
        Quand j'exécute <tt>ifconfig</> sans argument, il indique que j'ai un
        nombre faramineux d'erreurs à la fois dans les paquets reçus et dans les
        paquets transmis. Pourtant tout semble fonctionner correctement --
        Est-ce que je me trompe~?

        Regardez de nouveau. <tt>ifconfig</> indique~: <tt>RX packets</> <sl>gros
        nombre</> <bf>BLANC</> <tt>errors 0</> <bf>BLANC</> <tt>dropped 0</>
        <bf>BLANC</> <tt>overrun 0</>. Même chose pour la colonne avec
        <tt>TX</>. Les grands nombres que vous voyez sont donc le nombre total
        de paquets que votre machine a reçus et transmis. Si vous trouvez
        encore que c'est source de confusion, essayez de taper <tt>cat
        /proc/net/dev</tt> à la place.

<sect2>Liens dans <tt>/dev/</tt> pour cartes Ethernet
<p>
        J'ai <tt>/dev/eth0</tt> qui est un lien vers <tt>/dev/</tt>xxx. Est-ce
        que c'est bon~?

        Contrairement à ce que vous avez entendu dire, les fichiers dans
        <tt>/dev/*</tt> ne sont pas utilisés. Vous pouvez détruire tous les
        <tt>/dev/wd0, /dev/ne0</tt> et ce qui y ressemble.

<sect2>Linux et les ``trailers'' (amorces)
<p>
        Dois-je désactiver les ``trailers'' quand je `ifconfig'ure ma carte
        Ethernet~?

        Vous ne pouvez pas désactiver les ``trailers'', et vous ne devriez pas
        en avoir envie. Les ``trailers'' sont une astuce de programmation pour
        éviter des copies de données dans les couches réseau. L'idée était
        d'utiliser un en-tête simpliste de taille fixe `H', de mettre les
        informations de l'entête de taille variable à la fin du paquet, et
        d'allouer tous les paquets `H' octets avant le début d'une page. Alors
        qu'il s'agissait d'une bonne idée, en pratique cela n'a pas très bien
        fonctionné.

        Si quelqu'un suggère l'utilisation de `-trailers', notez bien que c'est
        l'équivalent du sang de chèvres sacrifiées. Cela ne résoudra pas le
        problème, mais si le problème se résoud tout seul, quelqu'un pourra
        invoquer des connaissances approfondies en magie.

<sect2>Accès direct au périphérique Ethernet
<p>
        Comment puis-je avoir accès directement au périphérique Ethernet sous
        Linux, sans avoir à passer par TCP/IP et ses copains~?

<code>
        int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
</code>

        Ceci vous donne une socket qui peut recevoir tous les types de
        protocoles. Utilisez l'appel <tt>recvfrom()</> sur cette socket, cela
        remplira la structure <tt>sockaddr</> avec le type de périphérique dans
        le champ <tt>sa_family</> et le nom du périphérique dans le tableau
        <tt>sa_data</>. Je ne sais pas qui a inventé <tt>SOCK_PACKET</> pour
        Linux (cela fait une éternité qu'il est là), mais c'est du beau
        travail. Vous pouvez l'utiliser pour envoyer des choses directement en
        utilisant l'appel <tt>sendto()</>.

        Bien entendu, vous devez être root pour pouvoir faire l'ensemble de ces
        opérations.


<sect>Trucs et astuces à propos des performances<label id="perf">
<p>
        Voici quelques `trucs' que vous pouvez utiliser si vous souffrez d'un
        faible taux de transfert sur Ethernet, ou pour gagner encore un peu de
        vitesse sur ces fameux transferts FTP.

        Le programme <tt>ttcp.c</> est un bon test pour mesurer la vitesse de
        transfert brute. Un autre truc classique est de faire un <tt>ftp> get
        mon_gros_fichier /dev/null</tt> où <tt>mon_gros_fichier</> fait plus
        d'un~Mo et réside dans le cache disque de la machine qui transmet.
        (Faites le `get' au moins deux fois, car la première fois ce cache sera
        vide.) Vous avez besoin que le fichier soit dans le cache car il faut
        éviter que le temps d'accès au fichier influe sur votre mesure. C'est
        pour la même raison que vous envoyez les données qui arrivent vers
        <tt>/dev/null</tt> plutôt que vers le disque.


<sect1>Concepts génériques
<p>
        Même une carte 8~bits est capable de recevoir des paquets qui se suivent
        (<sl>back-to-back paquets</> en anglais) sans aucun problème. Les
        difficultés apparaissent quand l'ordinateur n'enlève pas suffisamment
        rapidement de la carte les paquets reçus pour faire de la place pour
        d'autres paquets entrants. Si l'ordinateur ne supprime pas rapidement
        les paquets déjà reçus de la mémoire de la carte , celle-ci n'aura pas
        assez de place pour mettre les nouveaux paquets.

        Dans ce cas, soit la carte détruit le nouveau paquet, soit elle réécrit
        sur un paquet déjà reçu. Les deux solutions interrompent brutalement le
        flux du trafic, nécessitent des re-transmissions et peuvent sérieusement
        dégrader les performances d'un facteur qui va jusqu'à 5~!

        Les cartes qui possèdent plus de mémoire sont capables de conserver plus
        de paquets, et peuvent donc supporter de gros pics de paquets successifs
        sans détruire de paquets. Par conséquent cela signifie que la carte
        n'exige pas de l'ordinateur un temps de latence aussi faible pour
        enlever les paquets sans avoir à en détruire.

        La plupart des cartes 8~bits ont un tampon de 8~Ko, et la plupart des
        cartes 16~bits ont un tampon de 16~Ko. La plupart des pilotes sous Linux
        réserveront 3~Ko de ce tampon (pour deux tampons de transmission),
        laissant 5~Ko d'espace de réception pour une carte 8~bits. Cela ne
        laisse de la place que pour 3 paquets Ethernet de pleine taille (1500
        octets).

<sect1>La vitesse des cartes et du bus ISA
<p>
        Comme indiqué précédemment, si les paquets sont enlevés de la carte
        suffisamment rapidement, le problème de destruction ou de surcharge
        n'apparaît pas même si la taille mémoire du tampon de réception est
        petite. Le facteur qui détermine la rapidité avec laquelle les paquets
        sont enlevés de la carte pour être placés dans la mémoire de
        l'ordinateur est la vitesse du chemin que devront suivre les données
        entre les deux --~c'est-à-dire la vitesse du bus ISA. (Si le processeur
        est un 386sx-16 poussif, cela jouera aussi un rôle.)

        La vitesse d'horloge recommandée pour un bus ISA est de 8~MHz, mais de
        nombreuses cartes-mères et de nombreux périphériques peuvent être
        utilisés à des fréquences plus élevées. La vitesse d'horloge du bus ISA
        peut en général être modifiée dans la configuration CMOS, en choisissant
        le rapport entre la fréquence du processeur et celle de la
        carte-mère. Certaines cartes-mères n'auront pas cette option, et vous
        serez coincés avec la valeur par défaut.

        Par exemple, voici quelques vitesses de réception mesurées par le
        programme TTCP sur un 486 à 40~MHz, avec une carte 8~bits WD8003EP, pour
        des vitesses différentes du bus ISA.

<verb>
        Vitesse du bus ISA (MHz)        TTCP - réception (Ko/s)
        ------------------------        -----------------------
        6.7                             740
        13.4                            970
        20.0                            1030
        26.7                            1075
</verb>

        Vous auriez du mal à faire mieux que 1075~Ko/s avec <em>n'importe
        quelle</em> carte Ethernet 10~Mo/s, en utilisant TCP/IP. Néanmoins ne
        vous attendez pas à ce que tous les systèmes puissent travailler à des
        vitesses de bus ISA rapides. La plupart des systèmes ne fonctionneront
        pas correctement à des vitesses au-dessus de 13~MHz. (De même, certains
        systèmes~PCI fixent la vitesse du bus ISA à 8~MHz, afin que
        l'utilisateur final n'ait pas la possibilité de pouvoir l'augmenter.)

        En plus de vitesses de transferts supérieures, vous profiterez aussi en
        général d'une réduction de l'utilisation du processeur due à la durée
        plus courte des cycles mémoires et d'E/S. (Notez que les disques durs et
        les cartes vidéo situées sur le bus ISA afficheront aussi de meilleures
        performances avec une vitesse du bus ISA plus élevée.)

        Soyez sûr de sauvegarder toutes vos données avant de faire des
        expériences avec des vitesses du bus ISA au-dessus de 8~MHz, et de
        tester attentivement que tous les périphériques ISA fonctionnent
        correctement après toute augmentation de vitesse.

<sect1>Modifier la fenêtre de réception TCP
<p>
        Une fois encore, les cartes qui possèdent peu de mémoire et un trajet
        des données entre la carte et la mémoire de l'ordinateur plutôt lent
        provoquent des problèmes. La fenêtre de réception TCP est réglée par
        défaut à 32~Ko, ce qui signifie qu'un ordinateur rapide situé sur le
        même sous-réseau que vous pourra vous inonder de 32~Ko de données sans
        s'arrêter pour regarder si vous en avez reçu le moindre morceau.

        Les versions récentes de la commande <tt>route</> donnent la possibilité
        de régler la largeur de cette fenêtre à la volée. En général, cette
        fenêtre ne doit être réduite que pour le réseau local, puisque les
        ordinateurs qui sont à quelques routeurs ou passerelles de distance ont
        suffisamment de `tampons' intermédiaires pour ne pas poser de
        problème. Un exemple d'utilisation est~:
<code>
        route add <comme_d_habitude> ... window <largeur_de_fenetre>
</code>
        où <tt>largeur_de_fenetre</> est la largeur de la fenêtre que vous
        voulez utiliser (en octets). Une carte 8~bits 3c503 sur un bus ISA
        fonctionnant à une vitesse de 8~MHz ou moins tournera correctement avec
        une fenêtre d'environ 4~Ko. Une fenêtre trop large causera des
        surcharges et des pertes de paquets, et une diminution drastique du
        débit Ethernet. Vous pouvez vérifier les conditions de travail de la
        carte en faisant un <tt>cat /proc/net/dev</tt> qui affichera si des
        pertes de paquets ou des surcharges sont apparues.

<sect1>Augmenter les performances de NFS
<p>
        Des personnes ont remarqué que l'utilisation de cartes 8~bits sur des
        clients NFS donne des performances moins bonnes que celles attendues, en
        utilisant une taille de paquet NFS de 8Ko (celle donnée à l'origine par
        Sun).

        La raison possible de tout cela pourrait être la différence entre la
        taille des tampons des cartes 8~bits et celle des cartes 16~bits. La
        taille maximale d'un paquet Ethernet est d'environ 1500
        octets. Maintenant que nous faisons du NFS, des paquets NFS de 8~Ko vont
        arriver sous la forme de 6 paquets de taille maximale à la
        queue-leu-leu. Ni les cartes 8~bits ni les cartes 16~bits n'ont de
        problème à recevoir ces paquets les uns derrière les autres. Le problème
        se produit parce que la machine n'enlève pas les paquets à temps de la
        carte, et que le tampon déborde. Le fait que les cartes 8~bits
        nécessitent un cycle du bus ISA supplémentaire pour chaque transfert
        n'aide pas beaucoup, par ailleurs. Ce que vous <em>pouvez</> faire si
        vous avez une carte 8bits est soit de diminuer la taille de transfert
        NFS à 2~Ko (voire 1~Ko), soit d'essayer d'augmenter la vitesse du bus
        ISA afin que les tampons de la carte soient vidés plus rapidement. J'ai
        trouvé qu'une vieille carte WD8003E à 8~MHz (sans autre charge système)
        peut soutenir une réception de taille importante avec une taille NFS de
        2~Ko, mais pas à~4~Ko, auquel cas les performances étaient dégradées
        d'un facteur trois.

        D'un autre coté, si l'option par défaut est d'utiliser des blocs de
        1~Ko, et que vous avez au moins une carte ISA 16~bits, vous aurez
        certainement de meilleures performances en passant a 4~Ko (ou même
        8~Ko).


<sect>Informations spécifiques par distributeur/constructeur/modèle
      <label id="card-intro">
<p>
        Ce qui suit est une liste de nombreuses cartes, rangées par ordre
        alphabétique de distributeur, puis par identifiant de produit. A côté de
        chaque identifiant de produit, vous verrez soit `supporté', soit
        `partiellement supporté', soit `non supporté'.

        `Supporté' signifie qu'un pilote existe pour cette carte, que de
        nombreuses personnes en sont contentes et qu'il semble fiable.

        `Partiellement supporté' signifie qu'un pilote existe, mais que l'une au
        moins des conditions suivantes est vraie~: (1)~Le pilote et/ou le
        matériel comportent des erreurs, ce qui peut engendrer de piètres
        performances, des échecs de connexion ou même des crashs. (2)~Le pilote
        est récent ou la carte est très peu connue, et par conséquent celui-ci a
        été peu utilisé/testé et son auteur a eu très peu de retours quant à son
        fonctionnement. Il est évident que la situation~(2) est préférable à la
        situation~(1), et la description de la carte et du pilote devrait
        montrer clairement laquelle est la bonne. Dans un cas comme dans
        l'autre, vous devrez certainement répondre 'Y' à la question ``Prompt
        for development and/or incomplete code/drivers?'' (``Demander
        confirmation pour pour les pilotes en cours de développement ou
        incomplets~?'')  lorsque vous lancerez <tt>make config</>.

        `Non supporté' signifie qu'il n'existe pas de pilote disponible à
        l'heure actuelle pour cette carte. Cela peut être dû à un manque
        d'intérêt pour un matériel qui est rare ou peu commun, ou au fait que
        les distributeurs n'en fournissent pas la documentation nécessaire pour
        l'écriture du pilote.

        Notez que la différence entre `supporté' et `partiellement supporté' est
        plutôt subjective, et qu'elle est basée sur les retours d'informations
        fournis par les utilisateurs, observés dans les groupes de news et les
        listes de diffusion. (Après tout, il est impossible à une personne de
        tester tous les pilotes avec toutes les cartes pour chaque version du
        noyau~!!!)  Soyez donc prévenus que telle carte indiquée comme
        `partiellement supportée' pourra fonctionner impeccablement pour vous
        (ce qui est bien), alors que telle autre indiquée comme `supportée' vous
        donnera des problèmes sans fin (ce qui n'est pas aussi bien).

        Après le statut, le nom du pilote donné dans le noyau de Linux est
        indiqué. Ceci sera aussi le nom du module tel qu'il apparait à la ligne
        <tt>alias eth0 pilote</> dans votre fichier de configuration
        <tt>/etc/conf.modules</tt>.


<sect1>3Com<label id="3com">
<p>
        Si vous n'êtes pas sûr de ce qu'est votre carte, mais que vous pensez
        qu'il s'agit d'une 3Com, vous pourrez certainement le déterminer à
        partir du numéro d'assemblage. 3Com dispose d'un document `Identifying
        3Com Adapters By Assembly Number' (Identifier les adaptateurs 3Com par
        leur numéro d'assemblage, référence 24500002) qui devrait très
        certainement éclaircir les choses. Consultez~<ref id="3com-tech"
        name="Informations techniques de 3Com"> pour plus d'informations sur la
        façon d'obtenir de 3Com des documents techniques.

        Notez aussi que vous pouvez éventuellement consulter le site FTP de 3Com
        qui recèle diverses gâteries~: <tt>ftp.3Com.com</>.

        Pour ceux qui consultent ce document sur le WWW, vous pouvez aussi
        essayer leur site WWW (<tt>www.3com.com</>).

<sect2>3c501<label id="3c501">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c501

        Cette carte 8~bits datant de l'âge de pierre, trop tapée du ciboulot
        pour être utilisée.  Evitez-la comme la peste. N'achetez pas cette
        carte, même pour faire une blague. Ses performances sont atroces, et
        elle a de nombreuses déficiences.

        Pour ceux qui ne seraient pas encore convaincus, la 3C501 ne sait faire
        qu'une chose à la fois -- pendant que vous enlevez un paquet du tampon
        (qui ne peut en contenir qu'un seul), elle ne peut pas en recevoir un
        autre, pas plus qu'elle ne peut en recevoir un pendant le chargement
        d'un paquet à transmettre. C'était parfait pour un réseau entre deux
        ordinateurs à base de 8088 où le traitement de chaque paquet et la
        réponse prenaient des dizaines de millisecondes, mais les réseaux
        modernes envoient des paquets les uns à la suite des autres pour
        pratiquement chaque transaction.

        Les IRQ automatiques fonctionnent, le DMA n'est pas utilisé, la
        détection automatique ne teste que <tt>0x280</> et <tt>0x300</>, et le
        niveau de débogage est indiqué dans le troisième argument passé au
        démarrage.

        Encore une fois, l'utilisation d'une 3C501 est <em>fortement
        déconseillée</>~! Encore plus avec un noyau IP `multicast', puisque vous
        allez aboutir à un arrêt pendant que vous écoutez <em>chacun</> des
        paquets `multicast'. Lisez les commentaires au début du code source pour
        plus de détails.

<sect2>EtherLink II, 3c503, 3c503/16<label id="3c503">
<p>
        Statut~: Supporté, Nom du pilote~: 3c503 (+8390)

        La 3c503 ne possède pas de mémoire reprogrammable pour stocker sa
        configuration (un ``EEPROM setup'')~; un programme de diagnostic et de
        configuration n'est donc pas nécessaire avant d'utiliser la carte sous
        Linux. L'adresse de mémoire partagée de la 3c503 est fixée en utilisant
        des cavaliers qui sont partagés avec l'adresse de la mémoire
        programmable de démarrage (``boot PROM''). Cela a tendance à semer la
        confusion chez les personnes habituées aux autres cartes ISA, sur
        lesquelles on laisse toujours le cavalier sur la position `désactivée'
        (<sl>disable</> en anglais) à moins d'avoir une PROM de démarrage.

        Ces cartes devraient être aussi rapide que les cartes WD80x3 qui
        utilisent le même bus, mais il apparaît qu'elles sont légèrement plus
        lentes. Ces cartes Ethernet à mémoire partagée ont aussi un mode à
        Entrées/Sorties programmées qui n'utilise pas les possibilités de la
        8390 (leurs ingénieurs ont trouvé trop de bogues~!). Le pilote 3c503 de
        Linux sait aussi travailler avec la 3c503 en mode d'E/S programmées,
        mais c'est plus lent et moins sûr que le mode à mémoire partagée. De
        plus, le mode d'E/S programmées n'est pas aussi bien testé lors des
        mises à jour des pilotes. Vous ne devriez pas utiliser le mode d'E/S
        programmées à moins d'en avoir besoin pour la compatibilité avec le DOS.

        La ligne d'IRQ de la 3c503 est fixée par logiciel, sans l'aide d'une
        EEPROM. A la différence des pilotes sous DOS, le pilote Linux est
        capable de choisir automatiquement l'IRQ~: il utilise la première ligne
        d'interruption disponible parmi~{5,2/9,3,4}, en choisissant à chaque
        fois que la carte est <tt>ifconfig</>urée. (Les anciennes versions du
        pilote sélectionnaient l'IRQ au moment du démarrage). L'appel
        <tt>ioctl()</> dans `ifconfig' retournera <tt>EAGAIN</> si aucune ligne
        d'IRQ n'est disponible à ce moment-là.

        Des problèmes classiques que les gens ont avec la 3c503 sont abordés
        dans~<ref id="3com-probs" name="Problèmes avec...">.

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

        Notez que certains vieux 386 sans disques ont des 3c503 sur la carte
        mère (faites par 3Com, mais vendues sous un autre nom, tel que `Bull')
        l'identificateur n'est pas celui des cartes 3Com, et elles ne seront
        donc pas détectées. Pour plus de détails, référez-vous au paquetage
        Etherboot, dont vous aurez besoin pour démarrer ces PC sans disques.

<sect2>EtherLink plus, 3c505<label id="3c505">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c505

        Il s'agit d'un pilote qui avait été écrit par Craig Southeren
        <tt>geoffw@extro.ucc.su.oz.au</>. Ces cartes utilisent la puce i82586
        d'Intel et sont assez peu répandues. Le pilote est inclus dans le noyau
        standard, mais il est classé comme pilote `alpha'. Consultez~<ref
        id="alfa" name="Pilotes alpha"> pour des informations importantes à
        propos de l'utilisation de pilotes Ethernet en phase de test `alpha'
        sous Linux.

        Vous devriez aussi lire le fichier
        <tt>/usr/src/linux/drivers/net/README.3c505</tt> si vous comptez
        utiliser une de ces cartes. Il contient diverses options que vous pouvez
        activer ou désactiver.

<sect2>EtherLink-16, 3c507<label id="3c507">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c507

        Cette carte utilise l'une des puces Intel, et le développement du pilote
        est fortement lié à celui du pilote de la carte Ether Express d'Intel.
        Le pilote est inclus dans la distribution standard du noyau, mais en
        tant que pilote `alpha'.

        Consultez~<ref id="alfa" name="Pilotes alpha"> pour des informations
        importantes concernant l'utilisation de pilotes en phase de test `alpha'
        sous Linux.

<sect2>EtherLink III, 3c509 / 3c509B<label id="3c509">
<p>
        Statut~: Supporté, Nom du pilote~: 3c509

        Cette carte est plutôt bon marché et possède de bonnes performances pour
        une conception ISA qui ne soit pas `bus-master'. Le revers de la médaille
        est que la 3c509 originelle nécessitait des temps de latence vraiment
        très faibles en réponse aux interruptions. La 3c509B ne souffre pas du
        même problème, car elle possède un tampon mémoire plus important (voir
        ci-dessous). Ces cartes utilisent des transferts en mode
        d'Entrées/Sorties programmées (PIO), de la même façon qu'une carte
        ne2000, et par conséquent une carte à mémoire partagée comme la wd8013
        sera plus efficace en comparaison.

        La 3c509 d'origine avait un petit tampon mémoire pour les paquets (4~Ko
        au total, 2~en réception et 2~en transmission), ce qui poussait le
        pilote à éliminer un paquet si les interruptions étaient masquées trop
        longtemps. Pour minimiser ce problème, vous pouvez essayer de dé-masquer
        les interruptions pendant les transferts sur disques IDE (consultez
        <tt>man hdparm</>) et~/~ou augmenter la vitesse de votre bus~ISA de
        façon à ce que les transferts~IDE se terminent plus tôt.

        Le modèle plus récent, la 3c509B, possède 8~Ko de mémoire, et le tampon
        peut être partagé en 4/4, 5/3 ou 6/2 en réception/transmission. Ce
        paramètre est changé à l'aide de l'utilitaire de configuration sous DOS,
        et est stocké dans la mémoire EEPROM. Cela devrait éliminer le problème
        précédent avec la 3c509 originelle.

        Les utilisateurs de 3c509B devraient utiliser soit l'utilitaire DOS
        fourni afin de désactiver le `<sl>plug and play</>', <em>et</> de
        déterminer le support de sortie dont ils ont besoin. Le pilote Linux
        <em>n'est pas</> capable aujourd'hui d'utiliser la fonctionnalité de
        détection automatique du support physique, donc vous <em>devez</>
        sélectionner 10Base-T ou 10Base-2 ou AUI.  Notez que pour arrêter
        totalement le PnP, vous devrez faire un <tt>3C5X9CFG /PNP:DISABLE</tt>
        et ensuite, éteindre et rallumer la machine pour que cela prenne effet.

        Certaines personnes ont posé des questions sur les paramètres ``Server
        or Workstation'' (serveur ou station de travail) et ``Highest Modem
        Speed'' (plus haute vitesse de modem) qui sont présentés dans
        l'utilitaire de configuration du DOS. Donald écrit que ``Ce ne sont que
        des orientations fournies au pilotes, et le pilote Linux n'utilise pas
        ces paramètres~; il optimise toujours pour un taux de transfert
        important plutôt que pour un temps de latence faible (`Server'). Un
        temps de latence faible était un critère critique pour le vieux trafic,
        non-fenêtré, de IPX. Afin de réduire le temps de latence, le pilote sous
        DOS de la 3c509 inhibe les interruptions de certaines opérations,
        bloquant les interruptions du port série. D'où la nécessité du paramètre
        `modem speed' (vitesse du modem). Le pilote Linux évite la nécessité de
        désactiver les interruptions sur de longues périodes en ne travaillant
        que sur des paquets complets, par exemple en ne commençant pas à
        transmettre un paquet avant qu'il n'ait été complètement transféré sur
        la carte.''

        Notez que la procédure de détection de la carte ISA utilise une méthode
        différente de la plupart des autres cartes. A la base, vous demandez aux
        cartes de répondre en envoyant des données sur un port <tt>ID_PORT</>
        (port <tt>0x100</> jusqu'à <tt>0x1ff</> par intervalle de <tt>0x10</>).
        Cette méthode de détection signifie qu'une carte donnée sera toujours
        détectée en premier dans une configuration comportant plusieurs cartes
        ISA 3c509. La carte avec la plus petite adresse Ethernet physique sera
        <em>toujours</> <tt>eth0</>. Cela ne devrait gêner personne, à
        l'exception de ceux qui souhaitent assigner une adresse physique sur 6
        octets à une interface donnée. Si vous avez plusieurs cartes 3c509, il
        vaut mieux ajouter des commandes <tt>ether=0,0,ethN</> sans préciser le
        port d'E/S (c'est-à-dire en utilisant E/S=zéro) et autoriser la
        procédure de détection à faire le tri pour déterminer quelle carte est
        la première. Utiliser une valeur d'E/S non nulle va faire que toutes les
        cartes ne seront pas détectées : donc, ne le faites pas.

        Si cela vous gêne vraiment, jetez un coup d'oeil au tout dernier pilote
        de Donald, car cela vous permettra d'utiliser une valeur <tt>0x3c509</>
        dans le champ (inutilisé) de l'adresse mémoire pour obliger la détection
        à réussir.

<sect2>3c515<label id="cork">
<p>
        Statut~: Supporté, Nom du pilote~: 3c515

        Il s'agit de l'offre 100~Mb/s de 3Com en ISA, nom de code
        ``<sl>CorkScrew</>'' (tire-bouchon, en anglais). Un pilote assez jeune
        pour ces cartes venant de Donald est inclus dans la version 2.2 du
        noyau. Pour les dernières informations, vous auriez certainement intérêt
        à le chercher dans la page sur les ``Vortex''~:

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html"
                name="Vortex">
</quote>

<sect2>3c523<label id="3c523">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c523

        Cette carte pour bus~MCA utilise la puce i82586, et Chris Beauregard a
        modifié le pilote <tt>ni52</> pour qu'il fonctionne avec ces cartes. Le
        pilote correspondant peut être trouvé dans l'arborescence des sources
        des noyaux~2.2.

        Plus de détails sont fournis sur la page MCA pour Linux à
        <tt>http://glycerine.cetmm.uni.edu/mca/</tt>

<sect2>3c527<label id="3c527">
<p>
        Statut~: Non supporté

        Eh oui, encore une autre carte MCA. Eh non, pas beaucoup d'intérêt pour
        celle-ci. Vous aurez plus de chance avec la 3c529 si vous êtes coincé(e)
        avec le MCA.

<sect2>3c529<label id="3c529">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c509

        Cette carte utilise en fait le même jeu de puces que la 3c509. De fait,
        Donald a placé des points d'entrée dans le pilote de la 3c509 pour
        vérifier l'existence de cartes MCA après la détection des cartes EISA,
        et avant celle des cartes ISA, longtemps avant que le MCA soit supporté
        par le noyau. Le code de détection MCA est inclus dans le pilote livré
        avec le noyau 2.2.

        On peut trouver plus de détails sur la page MCA pour Linux à l'adresse
        <tt>http://glycerine.cetmm.uni.edu/mca/</tt>.

<sect2>3c562
<p>
        Statut~: Supporté, Nom du pilote~: 3c589 (distribué séparément)

        Cette carte PCMCIA est la combinaison d'une carte Ethernet 3c589B et
        d'un modem. Le modem est vu comme un modem standard par l'utilisateur
        final. La seule difficulté est d'arriver à faire en sorte que les deux
        pilotes Linux partagent la même interruption. Il y a une série de
        nouveaux registres et un peu de support de partage d'interruptions
        matérielles. Vous aurez besoin d'utiliser un noyau 2.0 ou plus récent,
        qui comporte ce qu'il faut pour le partage d'interruptions.

<!--
XXX produit n'étant plus distribué...

        Un peu en commentaire, certaines personnes ont indiqué que la partie
        modem de la carte n'est pas très bien documentée pour l'utilisateur
        final (le manuel dit juste qu'elle `comprend le jeu de commandes AT') et
        qu'elle ne se connecte pas aussi bien que des modems d'autres
        marques. La recommandation est plutôt d'acheter une 3c589B à la place,
        puis d'obtenir une carte modem PCMCIA par une société qui est
        spécialisée dans les modems.
-->

        Merci de nouveau à Cameron pour l'obtention d'un exemplaire d'essai et
        l'envoi d'une documentation à David Hinds. Consultez le paquetage PCMCIA
        de David pour plus d'informations.

        Consultez~<ref id="pcmcia" name="PCMCIA"> pour en savoir plus sur les
        jeux de puces PCMCIA, les activateurs de sockets, etc.

<sect2>3c575
<p>
        Statut~: Inconnu

        Un pilote pour cette carte PCMCIA est en cours de développement et l'on
        peut espérer qu'il sera inclus dans le paquetage PCMCIA de David dans le
        futur. Le mieux est de regarder dans le paquetage PCMCIA pour voir ce
        qui s'y passe.


<sect2>3c579<label id="3c579">
<p>
        Statut~: Supporté, Nom du pilote~: 3c509

        La version EISA de la 509. La version EISA actuelle utilise la même puce
        de largeur 16~bits plutôt qu'une interface 32~bits, et les performances
        ne sont donc pas époustouflantes. Le code de détection EISA a été ajouté
        dans <tt>3c509.c</> pour la version 0.99pl14. Assurez-vous que la carte
        est configurée pour le mode d'adressage EISA. Lisez la section
        précédente sur la~3c509 pour des informations sur le pilote.


<sect2>3c589 / 3c589B<label id="3c589">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c589

        Beaucoup de monde utilise cette carte PCMCIA depuis déjà un bon bout de
        temps. Notez qu'elle n'est pas incluse (à l'heure actuelle) dans
        l'arborescence par défaut du noyau. Le "B" dans le nom signifie la même
        chose ici que dans le cas de la 3c509.

        Les pilotes sont disponibles sur le site ftp de Donald, et dans le
        paquetage PCMCIA de David Hinds. Vous aurez aussi besoin d'avoir un
        chipset PCMCIA supporté. Allez faire un tour dans le <ref id="pcmcia"
        name="Support PCMCIA"> pour plus d'informations sur les pilotes, les
        chipsets supportés, les activateurs de sockets, etc.


<sect2>3c590 / 3c595<label id="vortex">
<p>
        Statut~: Supporté, Nom du pilote~: 3c59x

        Ces cartes ``Vortex'' sont destinées aux machines à bus PCI, la 3c590
        constituant l'offre à 10~Mb/s de 3Com et la 3c595 celle à 100~Mb/S.
        Notez aussi que vous pouvez utiliser la 595 comme une 590 (c'est-à-dire
        en mode 10~Mb/s). Le pilote est inclus dans les sources du noyau 2.0,
        mais est aussi continuellement mis à jour. Si vous rencontrez
        des problèmes avec le pilote des noyaux 2.0, vous pouvez obtenir un
        pilote à jour à partir de l'URL suivante~:

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html"
             name="Vortex">
</quote>

        Notez qu'il existe en fait deux cartes 3c590, des modèles des premiers
        temps ayant 32~Ko de mémoire, et des plus récents qui n'en ont que 8~.
        Il y a des chances pour que vous ne puissiez plus acheter une 3c59x
        neuve, car elles ont été remplacées par les 3c90x. Si vous achetez une
        carte d'occasion, essayez d'obtenir la version 32~Ko. Les cartes 3c595
        ont 64~Ko, car vous ne pouvez pas faire grand-chose avec seulement 8~Ko
        de mémoire vive à 100~Mb/s~!

        Grand merci à Cameron Spitzer et Terry Murphy de 3Com pour l'envoi de
        cartes et de documentation à Donald afin qu'il puisse écrire le pilote.

        Donald a mis en place une liste de diffusion pour le support du pilote
        Vortex. Pour vous abonner à la liste, vous n'avez qu'à faire~:

        <tt>echo subscribe | /bin/mail
        linux-vortex-request@cesdis.gsfc.nasa.gov</tt>


<sect2>3c592 / 3c597
<p>
        Statut~: Supporté, Nom du pilote~: 3c59x

        Ce sont les versions EISA des séries 3c59x. La 3c592/3c597 (aussi connue
        sous le nom de Demon) devrait fonctionner avec le pilote Vortex présenté
        au paragraphe précédent.

<sect2>3c900 / 3c905 / 3c905B
<p>
        Statut~: Supporté, Nom du pilote~: 3c59x

        Ces cartes (aussi connues sous le nom de `Boomerang', ou encore
        EtherLink III XL) ont été mises sur le marché pour remplacer les cartes
        3c590/3c595.

        Le support pour la version à base de Cyclone 'B' a récemment été
        ajouté. Pour utiliser cette carte avec les anciens noyaux 2.0, vous
        devez obtenir le pilote <tt>3c59x.c</> mis à jour sur le site de
        Donald~:
<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html"
                name="Vortex">
</quote>

        Si vous avez un doute, allez faire un tour sur la page WWW
        ci-dessus. Donald a mis en place une liste de diffusion sur les annonces
        concernant le support du pilote Vortex, entre autres.  Pour vous abonner
        à la liste, il suffit de faire~:

        <tt>echo subscribe | /bin/mail
        linux-vortex-request@cesdis.gsfc.nasa.gov</tt>

<sect2>3c985
<p>
        Statut~: Supporté, Nom du pilote~: acenic

        Ce pilote, par Jes Sorensen, est disponible dans les noyaux 2.2. Il
        supporte plusieurs autres modèles de cartes Gigabit en plus du modèle
        3Com.


<sect1>Accton<label id="accton">
<p>

<sect2>Accton MPX
<p>
        Statut~: Supporté, Nom du pilote~: ne (+8390)

        Ne vous laissez pas avoir par le nom. Cette carte est tout de même
        supposée être une compatible NE2000, et devrait par conséquent
        fonctionner avec le pilote du même nom.


<sect2>Accton EN1203, EN1207, EtherDuo-PCI
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Une autre implémentation de la puce PCI 21040 de DEC. La carte EN1207
        comporte le 21140, mais a aussi un connecteur 10Base-2, ce qui s'est
        révélé source de problèmes pour certaines personnes en terme de
        sélection de ce support. Par contre, l'utilisation de la carte avec du
        10Base-T et du 100Base-T a fonctionné pour certaines autres. Donc, comme
        pour tous les achats, vous devez d'abord essayer et vous assurer que
        vous pourrez retourner la carte si elle ne fonctionne pas pour vous.

        Consultez~<ref id="dec-21040" name="DEC 21040"> pour plus d'informations
        sur ces cartes, et la situation actuelle du pilote.

<sect2>Adaptateur Accton EN2209 pour port parallèle (EtherPocket)
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ?

        Un pilote pour ces adaptateurs sur port parallèle est disponible mais ne
        fait pas encore partie des sources des noyaux 2.0 ou~2.1. Vous pouvez
        obtenir ce pilote sur~:
<quote>
        <tt>http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html</tt>
</quote>


<sect2>Accton EN2212 PCMCIA
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ?

        David Hinds a commencé à travailler sur un pilote pour cette carte, et
        vous devriez de consulter la dernière version de son paquetage PCMCIA
        pour savoir où il en est.


<sect1>Allied Telesyn/Telesis<label id="allied-telesis">
<p>

<sect2>AT1500<label id="at-1500">
<p>
        Statut~: Supporté, Nom du pilote~: lance

        Il s'agit d'une série de cartes Ethernet peu chères qui utilisent la
        version 79C960 de la puce LANCE d'AMD. Ce sont des cartes utilisant le
        le contrôle du bus, et elles figurent donc parmi les cartes Ethernet ISA
        les plus rapides.

        La sélection du DMA et des informations sur la numérotation de la puce
        se trouvent dans~<ref id="lance" name="AMD LANCE">.

        Plus d'informations techniques sur les cartes Ethernet basées sur l'AMD
        LANCE sont disponibles dans~<ref id="amd-notes" name="Notes sur
        l'AMD...">.

<sect2>AT1700<label id="at1700">
<p>
        Statut~: Supporté, Nom du pilote~: at1700

        Notez que pour accéder à ce pilote lors du <tt>make config</> vous devez
        encore répondre `Y' à la question ``Prompt for development and/or
        incomplete code/drivers?'' au tout début. C'est simplement dû au manque
        de retour d'informations sur la stabilité du pilote, étant donné qu'il
        s'agit d'une carte relativement rare. Si vous avez des problèmes avec le
        pilote qui est livré avec le noyau, vous serez peut etre interessé par
        celui qui est disponible à~:
        <tt>http://www.cc.hit-u.ac.jp/nagoya/at1700/</tt>

        Les cartes Ethernet Allied Telesis des séries AT1700 sont basées sur la
        MB86965 de Fujitsu. Cette puce utilise une interface à E/S programmées,
        et une paire de tampons de transmission à taille fixe. Cela permet
        d'envoyer des petits groupes de paquets les uns à la suite des autres,
        avec une courte pause pendant le changement de tampon.

        Une fonctionnalité unique est la possibilité de piloter du câble STP
        (Shielded Twisted Pair, paire torsadée blindée) 150 ohms couramment
        installé pour le Token Ring, en plus du câble 100 ohms UTP (Unshielded
        Twisted Pair, paire torsadée non-blindée) de 10BaseT. Une version fibre
        optique de la carte (AT1700FT) existe également.

        La puce Fujitsu utilisée sur l'AT1700 a un défaut de conception~: elle
        ne peut être remise complètement à zéro qu'en effectuant un cycle
        d'allumage de la machine. Le fait d'appuyer sur le bouton de redémarrage
        (`Reset') ne réinitialise pas l'interface du bus. Cela ne serait pas
        gênant, si la carte ne pouvait être détectée qu'après qu'elle ait été
        récemment réinitialisée. Le moyen de contourner le problème est
        d'éteindre puis de rallumer la machine si le noyau a un problème pour
        détecter l'AT1700.

        Certaines séries de production de l'AT1700 ont un autre problème~: elles
        sont conçues pour utiliser de façon permanente le canal DMA 5. Cela
        n'est pas documenté, il n'existe aucun cavalier pour désactiver cette
        "fonctionnalité", et aucun pilote n'ose utiliser la possibilité de DMA à
        cause de problèmes de compatibilité. Aucun pilote de périphérique ne
        sera écrit pour utiliser la DMA si le fait d'installer une seconde carte
        dans la machine casse les deux cartes, et le seul moyen de désactiver le
        DMA est d'utiliser un couteau.

        Certaines séries de l'AT1700 ont un autre problème~: Elles sont bloquées
        sur le canal DMA 5. Cela n'est pas documenté, et il n'y a pas de
        cavaliers pour désactiver cette "fonctionnalité", et aucun pilote n'ose
        utiliser le DMA a cause des problèmes de compatibilité. Aucun pilote ne
        sera écrit pour utiliser le DMA a cause car le fait d'installer une
        deuxième carte empêcherais les DEUX de marcher, et le seul moyen de
        désactiver le DMA, c'est avec un couteau.


<sect2>AT2450<label id="at2450">
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        La version PCI de l'AT1500, qui ne souffre pas des problèmes de la carte
        PCI 79c970 de Boca. La sélection du DMA et des informations sur la
        numérotation de la puce se trouvent dans~<ref id="lance" name="AMD
        LANCE">.

        Plus d'informations techniques sur les cartes Ethernet basées sur l'AMD
        LANCE sont disponibles dans~<ref id="amd-notes" name="Notes sur
        l'AMD...">.


<sect2>AT1500
<p>
        Statut~: Partiellement supporté, Nom du pilote~: rtl8139

        Cette carte utilise la puce Realtek 8139, référez vous à la section <ref
        id="rtl8139" name="Realtek 8139">


<sect2>AT2540FX<label id="at2540">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: eepro100

        Cette carte utilise une puce i82557, et par conséquent,
        pourrait~/~devrait fonctionner avec le pilote de la carte eepro100. Si
        vous l'essayez, envoyez-nous quelques renseignements complémentaires
        pour que cette section s'étoffe un peu.

<sect1>AMD / Advanced Micro Devices<label id="amd">
<p>
        Carl Ching d'AMD a eu la gentillesse de fournir une description très
        détaillée de tous les produits Ethernet d'AMD cités, ce qui a permis de
        clarifier cette section.

<sect2>AMD LANCE (7990, 79C960/961/961A, PCnet-ISA)<label id="lance">
<p>
        Statut~: Supporté, Nom du pilote~: lance

        Il n'existe en fait aucune carte Ethernet AMD. Vous êtes certainement en
        train de lire ce paragraphe parce que les seules marques que vous ayez
        pu trouver sur votre carte disent `AMD' et le numéro ci-dessus. La 7990
        est la puce `LANCE' d'origine, mais la plupart des documents (y compris
        celui-ci) se réfèrent à toutes ces puces similaires sous la dénomination
        de puces `LANCE' (...incorrectement, devrais-je ajouter).

        Les numéros ci-dessus se réfèrent aux puces d'AMD qui sont le coeur de
        nombreuses cartes Ethernet. Par exemple, l'AT1500 d'Allied Telesis
        (voir~<ref id="at-1500" name="AT1500">), et la NE1500/2100 (voir~<ref
        id="ne1500" name="NE1500">) utilisent ces puces.

        La 7990/79c90 a été remplacée depuis bien longtemps par des versions
        plus récentes. La 79C960 (aussi connue sous le nom de PCnet-ISA)
        contient pour l'essentiel la base de la~79c90, avec tout le support
        matériel complémentaire requis, ce qui permet de monter une solution
        Ethernet en une seule puce. La~79c961 (PCnet-ISA+) est une version
        ``Plug and Play'', sans cavaliers, de la~960. La dernière puce des
        séries~ISA est la~79c961A (PCnet-ISA~II), qui ajoute des capacités de
        <sl>full duplex</>. Toutes les cartes comportant une de ces puces
        devraient fonctionner avec le pilote <tt>lance.c</>, à l'exception de
        très vieilles cartes qui utilisent la~7990 d'origine avec une
        configuration à mémoire partagée. Ces cartes anciennes peuvent être
        repérées par l'absence de cavaliers pour le choix d'un canal~DMA.

        Parmi les problèmes classiques, on rencontre le message `busmaster
        arbitration failure'. Celui-ci s'affiche quand le pilote LANCE ne peut
        pas obtenir un accès au bus après qu'un temps raisonnable se soit écoulé
        (50 micro-secondes). Cela indique habituellement que l'implémentation de
        la maîtrise de bus DMA de la carte-mère est incorrecte, ou qu'un autre
        périphérique monopolise le bus, ou qu'il y a un conflit de canal DMA. Si
        votre programme de configuration du BIOS possède la `GAT option' (GAT
        pour Guaranteed Access Time, temps d'accès garanti), essayez de modifier
        ce paramètre pour voir si cela va mieux.

        Notez aussi que le pilote ne cherche une carte valide qu'à ces
        adresses~: <tt>0x300, 0x320, 0x340, 0x360</>, et qu'une adresse fournie
        par un argument de démarrage <tt>ether=</> est ignorée sans qu'il en
        soit fait mention (cela sera corrigé), donc assurez-vous que votre carte
        est configurée pour l'une des adresses d'E/S ci-dessus, pour l'instant.

        Le pilote fonctionnera encore correctement, même si plus de 16~Mo de
        mémoire sont installés, car des tampons-relais en mémoire basse sont
        utilisés au besoin (c'est-à-dire que toute donnée située au-delà de la
        limite des 16~Mo est copiée dans un tampon en-dessous de la limite avant
        d'être remis à la carte pour transmission).

        Le canal DMA peut être configuré avec les bits (inutilisés en dehors de
        ça) de la valeur de <tt>dev->mem_start</> (aussi connue comme
        <tt>PARAM_1</> (voir~<ref id="ether" name="PARAM_1">). S'il n'est pas
        fixé, il est testé en activant chaque canal DMA tour à tour et en
        regardant si l'initialisation réussit.

        La carte HP-J2405A est une exception~: avec cette carte, il est facile
        de lire les valeurs stockées en EEPROM pour l'IRQ et le DMA.

        Voir~<ref id="amd-notes" name="Notes on AMD..."> pour plus
        d'informations sur ces puces.


<sect2>AMD 79C965 (PCnet-32)<label id="pcnet-32">
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Il s'agit de la PCnet-32 -- une version 32~bits, à contrôle de bus, de
        la puce~LANCE originelle pour les systèmes VLB (Vesa Local Bus) et à bus
        local. Bien que ces puces puissent être utilisée avec le pilote
        <tt>lance.c</> standard, une version 32~bits (<tt>pcnet32.c</>) est
        aussi disponible, laquelle n'a pas à se préoccuper des limitations à
        16~Mo liées au bus~ISA.

<sect2>AMD 79C970/970A (PCnet-PCI)<label id="pcnet-pci">
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Il s'agit de la PCnet-PCI -- similaire à la PCnet-32, mais conçue pour
        des systèmes basés sur le bus PCI. De nouveau, consultez les
        informations ci-dessus sur la PCnet-32. Cela signifie que vous devez
        construire un noyau comportant le support du BIOS PCI. La~970A ajoute le
        support du mode <sl>full duplex</> ainsi que d'autres fonctionnalités
        par rapport à la conception d'origine de la~970.

        Notez que l'implémentation de Boca pour la 79C970 ne fonctionne pas sur
        les machines Pentium rapides. Il s'agit d'un problème matériel,
        puisqu'il affecte aussi les utilisateurs DOS. Consultez la section sur
        Boca pour plus de détails.

<sect2>AMD 79C971 (PCnet-FAST)
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Il s'agit de la puce 100~Mbits d'AMD pour les systèmes~PCI, qui comporte
        elle aussi le mode <sl>full duplex</>. Elle a été introduite en juin
        1996 sur le marché.

<sect2>AMD 79C972 (PCnet-FAST+)
<p>
        Statut~: Inconnu, Nom du pilote~: pcnet32

        Devrait marcher exactement comme la '971, mais reste à confirmer quand
        même.

<sect2>AMD 79C974 (PCnet-SCSI)
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Il s'agit de la PCnet-SCSI -- qui à la base est traitée comme une 970 du
        point de vue Ethernet. Consultez aussi les informations ci-dessus. Ne
        demandez pas si la partie SCSI de la puce est supportée -- il s'agit de
        l'<em>Ethernet-HOWTO</>, pas du <sl>SCSI-HOWTO</>.

<sect1>Ansel Communications<label id="ansel">
<p>

<sect2>AC3200 EISA
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ac3200

        Notez que pour accéder à ce pilote lors du <tt>make config</> vous devez
        encore répondre `Y' à la question ``Prompt for development and/or
        incomplete code/drivers?'' au tout début. C'est simplement dû au manque
        de retour d'informations sur la stabilité du pilote, étant donné qu'il
        s'agit d'une carte relativement rare.

        Ce pilote est inclus dans le noyau actuel comme étant en phase de test
        `alpha'. Il est basé sur la classique puce NS8390 utilisée dans les
        cartes NE2000 et WD80x3. Veuillez consulter~<ref id="alfa" name="Pilotes
        `alpha'"> dans le présent document pour des informations importantes
        concernant les pilotes `alpha'.

        Si vous l'utilisez, veuillez informer l'un d'entre nous de la façon dont
        les choses fonctionnent, car nous avons eu peu de retour d'informations,
        même si le pilote est dans le noyau depuis la version 1.1.25.

        Si vous avez l'intention d'utiliser ce pilote comme module chargeable,
        vous devriez lire~<ref id="modules" name="Utilisation des pilotes
        Ethernet comme modules"> pour des informations spécifiques aux modules.

<sect1>Apricot
<p>

<sect2>Apricot Xen-II On Board Ethernet
<p>
        Statut~: Supporté, Nom du pilote~: apricot

        Cette carte Ethernet sur carte-mère utilise une puce i82596 à contrôle
        du bus. Elle ne peut se trouver qu'à l'adresse d'E/S <tt>0x300</>. En
        consultant le source du pilote, il apparaît que l'IRQ est matériellement
        fixée à 10.

        Les premières versions du pilote avaient une tendance à croire que tout
        ce qui vivait en <tt>0x300</> était un adaptateur réseau Apricot.
        Depuis, l'adresse matérielle est testée afin d'éviter ces détections
        erronées.

<sect1>Arcnet<label id="arcnet">
<p>
        Statut~: Supporté, Nom du pilote~: arcnet (arc-rimi, com90xx, com20020)

        Avec le coût vraiment très bas et les meilleures performances
        d'Ethernet, il est probable que la plupart des endroits disposant d'un
        réseau vont se débarrasser de leur matériel Arcnet pour rien, ce qui
        amènera un grand nombre de systèmes personnels à utiliser Arcnet.

        Un avantage d'Arcnet est que toutes les cartes ont des interfaces
        identiques, donc un seul pilote fonctionnera pour tout le monde. Il
        comporte aussi une gestion intégrée des erreurs, et est donc supposé ne
        jamais perdre un paquet. (Chouette pour le trafic UDP~!)

        Le pilote Arcnet d'Avery Pennarun est dans le noyau par défaut depuis la
        version 1.1.80. Le pilote Arcnet utilise `arc0' comme nom au lieu de
        l'`eth0' habituel pour les périphériques Ethernet.

        Vous pouvez envoyer rapports de bogues et comptes-rendus victorieux
        concernant Arcnet à~:

        <tt>apenwarr@foxnet.net</tt>

        Le noyau standard comporte des fichiers d'information pour la
        configuration des cavaliers et des aides plus générales.

        Le pilote est également censé fonctionner avec les cartes ARCnet
        100~Mb/s~!

<sect1>AT&amp;T
<p>
        Notez que le StarLAN d'AT&amp;T est une technologie orpheline, comme le
        LattisNet de SynOptics, et qu'elle ne peut pas être utilisée dans un
        environnement 10Base-T standard, sans un hub qui `parle' les deux
        protocoles.

<sect2>AT&amp;T T7231 (LanPACER+)
<p>
        Statut~: Non supporté

        Ces cartes StarLAN utilisent une interface similaire à la puce i82586. A
        une époque, Matthijs Melchior (<tt>matthijs.n.melchior@att.com</>)
        jouait avec le pilote de la 3c507, et avait presque quelque chose
        d'utilisable qui fonctionnait. Nous n'en avons pas entendu parler
        beaucoup depuis lors.

<sect1>Boca Research<label id="boca">
<p>
        Oui, ils font autre chose que des cartes séries multi-ports. :-)

<sect2>Boca BEN (ISA, VLB; PCI)<label id="boca-ben">
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32, lance

        Ces cartes sont basées sur les puces PCnet d'AMD. Les acheteurs
        exigeants doivent être prévenus que de nombreux utilisateurs ont eu des
        problèmes sans fin avec ces cartes VLB/PCI. Les propriétaires de
        systèmes Pentium rapides ont été tout particulièrement touchés. Notez
        qu'il ne s'agit pas d'un problème de pilote, puisqu'il touche aussi les
        utilisateurs de DOS/Windows/NT. Le numéro du support technique de Boca
        est le 1~(407)~241-8088,

        (NDT~: Ce numéro est bien entendu aux États-Unis.)

        et vous pouvez aussi les joindre à <tt>75300.2672@compuserve.com</>. Les
        anciennes cartes ISA ne semblent pas souffrir des mêmes maux.

        Donald a réalisé un test comparatif entre les cartes PCI Boca et une
        implémentation similaire d'Allied Telsyn avec la puce PCnet/PCI, qui
        montrait que le problème se situe dans l'implémentation faite par Boca
        de la puce PCnet/PCI. On peut consulter les résultats de ce test sur le
        serveur WWW de Don~:
<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/" name="Linux @ CESDIS">
</quote>

        Boca offre une `réparation~- garantie' aux propriétaires affectés par ce
        problème qui entraîne l'ajout d'un des condensateurs manquants, mais il
        semble que cette correction ne fonctionne pas à 100~% pour la plupart
        des gens, bien que cela en aide quelques uns.

        Si vous pensez <em>encore</> acheter une de ces cartes, alors essayez au
        moins d'obtenir une clause de retour inconditionnel sous 7~jours, pour
        que vous puissiez la rendre si elle ne fonctionne pas correctement sur
        votre système.

        Des informations plus générales sur les puces AMD se trouvent dans~<ref
        id="lance" name="AMD LANCE">.

        Plus d'informations techniques sur les cartes Ethernet basées sur l'AMD
        LANCE sont disponibles dans~<ref id="amd-notes" name="Notes sur
        l'AMD...">.

<sect1>Cabletron<label id="ctron">
<p>
        Donald écrit~: ``Oui, encore une autre de ces sociétés qui ne donnera
        pas ses informations pour programmer. Ils ont attendu des mois avant de
        confirmer qu'en fait toutes leurs informations étaient propriétaires,
        gaspillant délibérément mon temps. Évitez leurs cartes comme la peste si
        vous le pouvez.  Notez aussi que certaines personnes ont appelé
        Cabletron, et se sont entendues dire des choses comme `un certain
        D.~Becker travaille sur un pilote pour Linux' -- laissant entendre que
        je travaillais pour eux.  Ce N'est PAS le cas.''

<!--
        Si vous vous sentez prêt à leur demander pourquoi ils ne donneront pas
        leurs informations de programmation bas niveau afin que les gens
        puissent utiliser leurs cartes, écrivez à <tt>support@ctron.com</>.
        Dites-leur que vous utilisez Linux, et que vous êtes surpris qu'ils
        n'aident pas les systèmes ouverts. Et non, le kit de développement
        habituel ne peut avoir aucune utilité. Il ne contient qu'un
        fichier-objet pour DOS que l'on est supposé lier avec son exécutable. Un
        fichier que vous n'avez même pas le droit de désassembler.
-->

        Apparemment, Cabletron a changé sa politique à propos des informations
        sur la programmation (tout comme Xircom) depuis que Donald a fait ce
        commentaire il y a quelques années. Envoyez un e-mail à
        <tt>support@ctron.com</> si vous voulez vérifier ce point précis, ou
        demander des informations techniques. Toutefois, à l'heure actuelle, il
        y a très peu de demandes pour des pilotes mis à jour pour les cartes
        E20xx et E21xx.

<sect2>E10**, E10**-x, E20**, E20**-x<label id="e10xx">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ne (+8390)

        Il s'agit de presque-clones de NEx000 qui fonctionnent avec les pilotes
        NEx000 standard d'après les informations qui nous sont revenues, grâce à
        un test spécial-Cabletron dans la procédure de détection. S'il y a le
        moindre problème, il ne sera très certainement pas résolu, car les
        informations de programmation ne sont pas disponibles.


<sect2>E2100<label id="e2100">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: e2100 (+8390)

        Un fois de plus, on ne peut pas faire grand-chose quand les informations
        de programmation sont propriétaires. La E2100 bénéficie d'une conception
        lamentable. Dès qu'elle mappe sa mémoire partagée pendant un transfert
        de paquet, elle le fait en utilisant <em>toute la zone de 128~Ko</>~!
        Cela signifie que vous <em>ne pouvez pas</>, sur cette zone, utiliser de
        façon sécurisée un autre périphérique à mémoire partagée géré par
        interruption, y compris une autre E2100. Cela fonctionnera la plupart du
        temps, mais de temps à autre cela vous sautera à la figure.  (Oui, on
        pourrait éviter ce problème en inhibant les interruptions pendant le
        transfert des paquets, mais dans ce cas-là on perdra pratiquement à coup
        sûr des tops d'horloge). De plus, si vous programmez incorrectement la
        carte, ou que vous arrêtez la machine juste au mauvais moment, même le
        bouton de `reset' ne la rendra pas à la vie. Vous <em>devrez</> éteindre
        la machine et <em>attendre</> qu'elle se repose pendant 30~secondes.

        La sélection du support physique est automatique, mais vous pouvez
        outrepasser cette fonctionnalité en utilisant les bits de poids faibles
        du paramètre <tt>dev-&gt;mem_end</>. Consultez~<ref id="ether"
        name="PARAM_2">. Les utilisateurs des modules peuvent spécifier une
        valeur <tt>xcvr=N</> comme <tt>option</> dans le fichier
        <tt>/etc/conf.modules</tt>.

        Ne prenez pas non plus la~E2100 pour un clone de~NE2100. L'E2100 repose
        sur une DP8390 de National Semiconductor à mémoire partagée, à peu près
        similaire à une WD8013 avec des lésions cérébrales, tandis que la NE2100
        (et la NE1500) utilise une conception basée sur la puce à contrôle du
        bus LANCE d'AMD.

        Vous trouverez un pilote pour la~E2100 dans le noyau standard.
        Toutefois, au vu de l'indisponibilité des informations de programmation,
        n'attendez pas des corrections de bogues. N'en utilisez pas à moins d'en
        avoir une sur les bras.

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

<sect2>E22**<label id="e2200">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: lance

        Si l'on en croit les informations trouvées dans un bulletin technique de
        Cabletron, ces cartes utilisent le jeu de puces standard PC-net d'AMD
        (section~<ref id="lance" name="AMD PC-Net">) et devraient fonctionner
        avec le pilote générique <tt>lance</>.


<sect1>Cogent
<p>
        Voici où et comment les joindre~:
<verb>
        Cogent Data Technologies, Inc.
        175 West Street, P.O. Box 926
        Friday Harbour, WA 98250, USA.

        Cogent Sales              (service commercial)
        15375 S.E. 30th Place, Suite 310
        Bellevue, WA 98007, USA.

        Technical Support:        (support technique)
        Phone (360) 378-2929 between 8am and 5pm PST
                         (Téléphone entre 8h et 17h, heure de la côte
                          Pacifique)
        Fax (360) 378-2882
        Compuserve GO COGENT
        Bulletin Board Service (360) 378-5405
        Internet: support@cogentdata.com
</verb>

<sect2>EM100-ISA/EISA
<p>
        Statut~: Partiellement supporté, Nom du pilote~: smc9194

        Ces cartes utilisent la puce SMC 91c100 et devraient fonctionner avec le
        pilote SMC 91c92, mais cela reste à vérifier.

<sect2>Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Il s'agit encore une fois d'une implémentation de la 21040 de DEC, dont
        on peut espérer qu'elle fonctionne correctement avec le pilote 21040
        classique.

        L'EM400 et l'EM964 sont des cartes à quatre ports qui utilisent un pont
        DEC 21050 et quatre puces 21040.

        Consultez~<ref id="dec-21040" name="DEC 21040"> pour plus d'information
        sur ces cartes, et l'état d'avancement actuel du pilote.

<sect1>Compaq
<p>
        Compaq n'est pas vraiment dans le domaine de la conception et de la
        fabrication de cartes Ethernet, mais beaucoup de leurs systèmes
        comportent des contrôleurs Ethernet intégrés à la carte-mère.

<sect2>Compaq Deskpro / Compaq XL (Embedded AMD Chip)
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Des machines comme celles de la série XL ont une puce PCI 79c97x d'AMD
        sur la carte-mère qui peut être utilisée avec le pilote LANCE
        standard. Mais avant de pouvoir l'utiliser, vous devez faire quelques
        manipulations pour que le BIOS PCI se trouve à une place où Linux peut
        le voir. Frank Maas a été suffisamment sympa pour nous fournir les
        détails~:

        ``Le problème avec cette machine Compaq est que le point d'entrée du bus
        PCI est chargé en mémoire haute, à un endroit où le noyau Linux ne
        pourra pas (n'ira pas) le chercher. Résultat~: la carte n'est jamais
        détectée ni utilisable (en passant~: la souris ne fonctionnera pas non
        plus). La manière de contourner le problème (telle qu'elle est décrite
        en détail dans http://www-c724.uibk.ac.at/XL/) est de charger MS-DOS, de
        lancer un petit pilote que Compaq a écrit puis de charger le noyau Linux
        en utilisant LOADLIN. Ok, je vous laisse le temps de dire 'beurk', mais
        pour l'instant c'est la seule solution qui fonctionne que je
        connaisse. Le petit pilote se contente de déplacer le répertoire PCI à
        un endroit où il est normalement stocké (et où Linux peut le trouver).''

        Des informations plus générales sur les puces AMD se trouvent dans~<ref
        id="lance" name="AMD LANCE">.


<sect2>Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip)
<p>
        Statut~: Supporté, Nom du pilote~: tlan

        Ces systèmes utilisent une puce Texas Instrument ThunderLAN, pour plus
        d'informations, référez vous à la section <ref id="tlan"
        name="ThunderLAN">.


<sect1>Danpex
<p>

<sect2>Danpex EN9400
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Encore une autre carte basée sur la puce 21040 de DEC, dont on sait
        qu'elle fonctionne correctement, et à un prix relativement modéré.

        Consultez~<ref id="dec-21040" name="DEC 21040"> pour plus d'information
        sur ces cartes, et l'état d'avancement actuel du pilote.


<sect1>D-Link<label id="d-link">
<p>

<sect2>DE-100, DE-200, DE-220-T, DE-250<label id="de-100">
<p>

        Statut~: Supporté, Nom du pilote~: ne (+8390)

        Certaines des premières cartes D-Link ne possédaient pas la signature
        <tt>0x57</> en PROM, mais le pilote ne2000 en a connaissance. Pour les
        cartes configurables par logiciel, vous pouvez obtenir le programme de
        ad hoc sur <tt>www.dlink.com</>. Les cartes DE2** étaient celles les
        plus fréquemment indiquées comme possédant des erreurs de correspondance
        sur des fausses adresses de transfert avec les premières versions de
        Linux. Notez qu'il existe aussi des cartes chez Digital (DEC, Digital
        Equipment Corporation) nommées DE100 et DE200, mais la similitude
        s'arrête là.

<sect2>DE-520<label id="de-520">
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Il s'agit d'une carte PCI qui utilise la version PCI de la puce LANCE
        d'AMD. Des informations sur la sélection DMA et la numérotation des
        puces se trouvent dans~<ref id="lance" name="AMD LANCE">.

        Des informations plus techniques sur les cartes Ethernet basées sur la
        puce LANCE d'AMD sont disponibles dans~<ref id="amd-notes" name="Notes
        sur l'AMD...">.

<sect2>DE-528
<p>
        Statut~: Supporté, Nom du pilote~: ne, ne2k-pci (+8390)

        On dirait que D-Link a aussi commencé à fabriquer des clones de NE2000.


<sect2>DE-530<label id="de-530">
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Il s'agit d'une implémentation générique de la puce PCI 21040 de DEC,
        dont on sait qu'elle fonctionne avec le pilote générique 21040 `tulip'.

        Consultez~<ref id="dec-21040" name="DEC 21040"> pour plus d'information
        sur ces cartes, et l'état d'avancement actuel du pilote.

<sect2>DE-600<label id="de-600">
<p>
        Statut~: Supporté, Nom du pilote~: de600

        Les utilisateurs de portables et autres personnes qui souhaitent un
        moyen rapide de mettre leur ordinateur sur Ethernet pourront être
        intéressés par ceci. Le pilote est inclus dans l'arborescence du noyau
        par défaut. Bjorn Ekwall <tt>bj0rn@blox.se</> a écrit le pilote.
        Attendez-vous à des taux de transfert de 180~Ko/s par le port
        parallèle. Vous devriez lire le fichier README.DLINK dans l'arborescence
        du noyau.

        (NDT~: Ce fichier est bien entendu en anglais.)

        Notez que le nom de périphérique que vous passez à <tt>ifconfig</> est
        <em>maintenant</> <tt>eth0</> et non pas celui précédemment utilisé,
        <tt>dl0</>.

        Si votre port parallèle <em>ne</> se trouve <em>pas</> à l'adresse
        standard <tt>0x378</>, il vous faudra recompiler le noyau. Bjorn écrit~:
        ``Puisque le pilote de la DE-620 essaie de supprimer la moindre
        microseconde dans les boucles, j'ai défini l'IRQ et l'adresse du port
        comme des constantes plutôt que comme des variables. Cela donne une
        vitesse utilisable, mais cela signifie aussi que vous ne pouvez pas
        changer ces valeurs depuis par exemple lilo~; vous _devez_
        recompiler...''  Notez aussi que certains portables implémentent le port
        parallèle interne à l'adresse <tt>0x3bc</>, ce qui est l'endroit où les
        ports parallèles étaient/sont sur les cartes monochromes.

<sect2>DE-620<label id="de-620">
<p>
        Statut~: Supporté, Nom du pilote~: de620

        Même chose que pour la DE-600, avec seulement deux formats de sortie.
        Bjorn a écrit un pilote pour ce modèle, pour les versions 1.1 et
        supérieures du noyau. Consultez les informations ci-dessus à propos de
        la DE-600.

<sect2>DE-650<label id="de-650">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: de650 ?

        Des gens utilisent cette carte PCMCIA depuis quelque temps déjà avec
        leur portable. Il s'agit d'une conception simple basée sur le 8390, qui
        ressemble beaucoup à une NE2000. La carte PCMCIA `LinkSys' et l'IC-Card
        Ethernet sont, de plus, supposées être des clones de DE-650. Notez qu'à
        l'heure actuelle, ce pilote <em>ne</> fait <em>pas</> partie du noyau
        standard, et que vous devrez donc appliquer quelques patches.

        Consultez~<ref id="pcmcia" name="Support du PCMCIA"> dans ce document,
        et si vous le pouvez, jetez un coup d'oeil à~:
<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/pcmcia.html"
             name="La page PCMCIA de Don">
</quote>

<sect1>DFI<label id="dfi">
<p>

<sect2>DFINET-300 et DFINET-400<label id="dfi-300">
<p>
        Statut~: Supporté, Nom du pilote~: ne (+8390)

        Ces cartes sont maintenant détectées (depuis la version~0.99pl15) grâce
        à Eberhard Moenkeberg (<tt>emoenke@gwdg.de</>) qui a noté qu'elles
        utilisent `DFI' dans les trois premiers octets de la PROM, à la place
        de~<tt>0x57</> dans les octets 14~et 15, ce que font toutes les autres
        cartes NE1000~et NE2000. (La~300 est un semblant de clone 8~bits de la
        NE1000, et la~400 est un semblant de clone NE2000.)


<sect1>Digital / DEC<label id="dec">
<p>

<sect2>DEPCA, DE100/1, DE200/1/2, DE210, DE422<label id="dec-200">
<p>
        Statut~: Supporté, Nom du pilote~: depca

        De la documentation incluse dans le fichier source <tt>depca.c</>
        comprend des informations sur la façon d'utiliser plus d'une de ces
        cartes dans une machine. Notez que la DE422 est une carte EISA. Ces
        cartes sont toutes basées sur la puce LANCE d'AMD. Consultez~<ref
        id="lance" name="AMD LANCE"> pour plus d'informations. Au maximum, deux
        des cartes ISA peuvent être utilisées, parce que leurs adresses d'E/S de
        base ne peuvent être fixées qu'à <tt>0x300</> ou <tt>0x200</>. Si vous
        avez l'intention de le faire, veuillez lire les notes dans le fichier
        source du pilote, <tt>depca.c</>, dans l'arborescence du noyau standard.

        Ce pilote fonctionnera aussi sur les machines à processeur Alpha, et il
        comprend différents <tt>ioctl()</> avec lesquels l'utilisateur peut
        s'amuser.

<sect2>Digital EtherWorks 3 (DE203, DE204, DE205)<label id="dec-ewrk3">
<p>
        Statut~: Supporté, Nom du pilote~: ewrk3

        Ces cartes utilisent une puce propriétaire de DEC, par opposition à la
        puce LANCE utilisée dans les cartes antérieures comme la DE200. Ces
        cartes peuvent fonctionner en mémoire partagée ou en E/S programmées,
        bien que vous ayez un gain de performance de 50 % en utilisant le mode
        PIO (E/S programmées). La taille de la mémoire partagée peut être réglée
        à 2~Ko, 32~Ko, ou 64~Ko, mais seules les valeurs 2 et 32 ont été testées
        avec ce pilote. David dit que les performances sont virtuellement les
        mêmes entre le mode 2~Ko et le mode 32~Ko. Plus d'informations (y
        compris l'utilisation du pilote comme module chargeable) figurent en
        tête du fichier source du pilote, <tt>ewrk3.c</>, ainsi que dans le
        fichier <tt>README.ewrk3</>. Ces deux fichiers se trouvent dans la
        distribution standard du noyau. Ce pilote supporte les CPU alpha tout
        comme le <tt>depca.c</>.

        Le pilote standard a un certain nombre d'appels <tt>ioctl()</>
        intéressants qui peuvent être utilisés pour lire ou effacer les
        statistiques sur les paquets, lire/écrire l'EEPROM, changer l'adresse
        matérielle, et d'autres choses du même genre. Les bidouilleurs pourront
        lire le code source pour plus d'information à ce sujet.

        David a aussi écrit un utilitaire de configuration pour cette carte
        (outre les lignes du programme DOS <tt>NICSETUP.EXE</>) ainsi que
        d'autres outils. Vous pouvez les trouver sur la majorité des sites Linux
        dans le répertoire <tt>/pub/Linux/system/Network/management</tt>
        --~cherchez un fichier <tt>ewrk3tools-X.XX.tar.gz</>.

        (NDT~: Le lecteur français aura bien entendu tout intérêt à utiliser un
        site miroir, plus rapide. Par exemple~:

        <tt>ftp://ftp.lip6.fr/pub/linux/sunsite/system/Network/management</tt>)

<sect2>DE425 EISA, DE434, DE435, DE500<label id="dec-eisa">
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Ces cartes sont basées sur la puce 21040 mentionnée plus bas.  La DE500
        utilise les puces 21140 pour fournir des connexions Ethernet
        10/100Mb/s. Lisez la section sur la 21040 ci-dessous pour plus
        d'informations.  Il existe aussi quelques option de compilation qui
        permettent aux cartes non conçues par DEC de fonctionner avec ce
        pilote. Jetez un coup d'oeil à <tt>README.de4x5</> pour les détails.

        Toutes les cartes Digital réaliseront la détection automatique du média
        (à l'exception, temporaire, de la DE500 à cause d'un problème de
        brevet).

        Ce pilote est aussi prêt à fonctionner avec les processeurs Alpha et
        accepte d'être chargé comme module. Les utilisateurs peuvent accéder aux
        fonctionnalités internes du pilotes par des appels <tt>ioctl()</>
        --~voir l'outil <tt>ewrk3</> et les sources <tt>de4x5.c</> pour des
        informations sur la façon de procéder.

<sect2>DEC 21040, 21041, 2114x, Tulip<label id="dec-21040">
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        La 21040 de DEC est une solution Ethernet en une seule puce à contrôle
        proposée par Digital, similaire à la PCnet d'AMD. La 21040 est
        spécifiquement conçue pour l'architecture à bus PCI. Les nouvelles
        cartes PCI EtherPower de SMC l'utilisent.

        Vous avez le choix entre <em>deux</> pilotes pour les cartes basées sur
        cette puce. Vous pouvez utiliser le pilote de la DE425 dont nous avons
        parlé plus haut, et le pilote générique `tulip' pour 21040.

        <bf>Attention~:</> Même si votre carte est basée sur cette puce, <em>les
        pilotes peuvent ne pas fonctionner pour vous</>. David C. Davies écrit~:
        ``Il n'y aucune garantie que SOIT <tt>tulip.c</> SOIT <tt>de4x5.c</>
        feront fonctionner une autre carte basée sur le DC2114x que celles pour
        lesquelles ils ont été écrit. POURQUOI~??  demandez-vous. Parce qu'il
        existe un registre, le Registre multi-usages (General Purpose Register,
        CSR12) qui, primo, dans la DC21140A est programmable par chaque
        fabricant et ils le font tous d'une façon différente, et, secundo, dans
        la DC21142/3 est maintenant un registre de contrôle SIA (façon
        DC21041). La seule petite lueur d'espoir est que nous puissions décoder
        la SROM pour aider à la configuration du pilote. Et encore, ce n'est pas
        une solution garantie puisque chez certains constructeurs (par exemple
        la carte 9332 de SMC) on ne suit pas le format de programmation SROM
        recommandé par Digital Semiconductor.''

        En termes non-techniques, cela signifie que si vous n'êtes pas sûr(e)
        qu'une carte inconnue avec une puce DC2114x fonctionnera avec le(s)
        pilote(s) Linux, alors vous devez vous assurer que vous pourrez rendre
        la carte à votre revendeur <em>avant</> de l'avoir payée.

        La puce 21041 mise à jour, se trouve aussi à la place de la 21040 sur la
        plupart des cartes récentes EtherPower de SMC. La 21140 est destinée au
        support du 100Base-? et fonctionne avec les pilotes Linux de la puce
        21040. Pour utiliser le pilote <tt>de4x5</> de David avec des cartes non
        conçues par DEC, lisez le fichier <tt>README.de4x5</> pour les détails.

        Donald a utilisé des cartes EtherPower-10/100 de SMC pour développer le
        pilote `tulip'. Notez que le pilote qui se trouve dans l'arborescence du
        noyau à l'heure actuelle n'est pas la version la plus à jour. Si vous
        avez des problèmes avec ce pilote, vous devriez récupérer la dernière
        version sur le site FTP/WWW de Donald.
<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html"
             name="Pilote Tulip">
</quote>

        L'URL ci-dessus contient aussi une liste (non exhaustive) de différents
        cartes/constructeurs qui utilisent la puce 21040.

        Notez également que le pilote tulip est encore considéré comme un pilote
        <em>alpha</> (voir~<ref id="alfa" name="Pilotes alpha">) actuellement,
        et qu'il doit donc être traité comme tel. Pour l'utiliser, vous devrez
        éditer <tt>arch/i386/config.in</tt> et enlever les commentaires qui
        entourent la ligne sur le support <tt>CONFIG_DEC_ELCP</>.

        Donald a même créé une liste de diffusion pour les annonces sur le
        support du pilote tulip, etc. Pour vous y abonner, il vous suffit de
        taper~:

        <tt>echo subscribe | /bin/mail
        linux-tulip-request@cesdis.gsfc.nasa.gov</tt>

<sect1>Farallon
<p>
        Farallon vend des adaptateurs et des transceivers EtherWave. Ce
        périphérique permet de mettre en série plusieurs périphériques 10baseT.

<sect2>Etherwave de Farallon
<p>
        Statut~: Supporté, Nom du pilote~: 3c509

        On rapporte qu'il s'agit d'un clone de 3c509 qui inclut le transceiver
        EtherWave. Des gens les ont utilisés avec succès sous Linux avec la
        version actuelle du pilote 3c509. C'est bien trop cher pour une
        utilisation généralisée, mais c'est une bonne option pour des cas
        particuliers.  <!-- pas réussi à trouver ça chez Inmac. Si quelqu'un a
        une référence potable pour ce truc.. ;) - steph --> Les prix chez Hublet
        démarrent à 125 dollars (environ 750 francs), et l'EtherWave ajoute
        entre 75 et 100 dollars (450 à 600 francs) au prix de la carte --~c'est
        bien si vous avez tiré un câble trop court, mais pas si vous avez deux
        réseaux qui tombent trop courts.  <!-- rien compris~! - steph --> <!-- à
        mon avis ça veut dire que c'est bien si on a un câble qui est trop court
        pour le rallonger avec l'adaptateur, mais que ça fait cher si on doit
        rallonger plus (ça c'est dans le cas où c'est de l'humour). Sinon, c'est
        peut-être juste pour insister sur le fait que l'utilisation doit être
        exceptionnelle à cause du prix. Mais c'est pas clair, comme quoi les
        smileys ça aide, des fois ;-) AM -->

<sect1>Fujitsu
<p>
        Contrairement à de nombreux fabricants de puces, Fujitsu a aussi
        fabriqué et vendu des cartes réseau basées sur les leurs.

<sect2>Fujitsu FMV-181/182/183/184
<p>
        Statut~: Supporté, Nom du pilote~: fmv18x

        Si on en croit le pilote, ces cartes sont faites dans la lignée de
        l'implémentation de la Fujitsu MB86965, ce qui les rend très similaires
        aux cartes Allied Telesis AT1700.

<sect1>Hewlett Packard<label id="hp">
<p>
        Les cartes 272** utilisent des E/S programmées, similaires aux cartes
        NE*000, mais le port de transferts de données peut être `éteint' quand
        vous n'y accédez pas, ce qui évite les problèmes avec les pilotes qui
        réalisent une détection automatique.

        Merci à Glenn Talbott d'avoir aidé à éclaircir la confusion qui régnait
        dans cette section en ce qui concerne les numéros de version des
        matériels HP.

<sect2>27245A<label id="hp-27245a">
<p>
        Statut~: Supporté, Nom du pilote~: hp (+8390)

        Carte 8~bits 10BaseT basée sur le~8390, non recommandée pour toutes les
        raisons des 8~bits. Elle a été repensée il y a quelques années pour
        augmenter l'intégration, ce qui a causé des changements dans les durées
        d'initialisation, qui affectent les programmes de test, mais pas les
        pilotes réseau. (La nouvelle carte n'est pas `prête' aussi vite que
        l'ancienne après être entrée ou sortie du mode en boucle locale
        (<sl>loopback</>)).

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

<sect2>HP EtherTwist, PC Lan+ (27247, 27252A)
<p>
        Statut~: Supporté, Nom du pilote~: hp+ (+8390)

        La HP PC Lan+ est différente de la carte HP PC Lan standard. Ce pilote a
        été ajouté à la liste des pilotes du noyau standard pendant le cycle de
        développement des version 1.1.x. Il peut être utilisé soit en mode PIO
        (E/S programmées) comme une ne2000, ou en mode mémoire partagée comme
        une wd8013.

        La 47B est une carte 16~bits 10BaseT avec AUI à base de 8390, et la 52A
        est une carte 16~bits ThinLAN avec AUI à base de 8390. Ces cartes
        comportent 32~Ko de mémoire vive embarquée pour le tampon de
        réception/transmission des paquets au lieu des 16~Ko habituels, et elles
        offrent toutes les deux une fonction de détection automatique du
        connecteur réseau.

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

<sect2>HP-J2405A
<p>
        Statut~: Supporté, Nom du pilote~: lance

        Ces cartes sont meilleur marché, et légèrement plus rapides que la
        27247/27252A, mais il leur manque certaines fonctionnalités, comme la
        connectivité AUI ou ThinLAN (10Base2), et un support pour PROM de
        démarrage (boot PROM). C'est une conception plutôt générique de la
        LANCE, mais une décision mineure de conception la rend incompatible avec
        un pilote générique `NE2100'. Un support spécial pour cette carte (y
        compris la lecture du canal DMA sur la carte) est inclus grâce aux
        informations fournies par Glenn Talbott de chez HP.

        Plus d'informations techniques sur les cartes basée sur la puce AMD se
        trouvent dans~<ref id="amd-notes" name="Notes sur AMD...">.

<sect2>Carte Ethernet embarquée de l'HP-Vectra
<p>
        Statut~: Supporté, Nom du pilote~: lance

        L'HP-Vectra possède une puce PCnet d'AMD sur sa carte-mère. La sélection
        du DMA et des informations sur la numérotation de la puce se trouvent
        dans~<ref id="lance" name="AMD LANCE">.

        Plus d'informations techniques sur les cartes basées sur la puce AMD se
        trouvent dans~<ref id="amd-notes" name="Notes sur AMD...">.

<sect2>Cartes HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585, J970, J973)
<p>
        Statut~: Supporté, Nom du pilote~: hp100

        Ce pilote supporte aussi certains produits Complex VG. Comme ce pilote
        supporte les cartes ISA, EISA et PCI, il se trouve dans la section des
        cartes ISA quand vous faites un <tt>make config</> dans les sources du
        noyau.

<sect2>HP NetServer 10/100TX PCI (D5013A)
<p>
        Statut~: Supporté, Nom du pilote~: eepro100

        Apparemment, ces cartes sont juste des cartes Intel EtherExpress Pro
        10/100B card dont on a changé la marque. Allez voir la section sur Intel
        pour plus de détails.

<sect1>IBM / International Business Machines<label id="ibm">
<p>

<sect2>IBM Thinkpad 300<label id="thinkpad-300">
<p>
        Statut~: Supporté, Nom du pilote~: znet

        Celui-ci est compatible avec le Z-note de Zénith, basé sur une puce
        Intel. Voir~<ref id="z-note" name="Z-note">.

        Ce site est supposé avoir une base de données exhaustive de choses
        utiles pour les versions récentes du Thinkpad. Je ne l'ai pas vérifié
        moi-même.

<quote>
        <url url="http://peipa.essex.ac.uk/html/linux-thinkpad.html"
             name="Thinkpad-info">
</quote>

        Pour ceux d'entre vous qui n'ont pas de navigateur WWW à portée de la
        main, essayez <tt>peipa.essex.ac.uk:/pub/tp750/</tt>.

<sect2>IBM Credit Card Adaptor for Ethernet - Adaptateur `Credit Card' pour
Ethernet d'IBM
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ? (distribué séparément)

        Des personnes utilisent aussi cette carte PCMCIA avec Linux. Comme déjà
        noté, vous aurez besoin d'un jeu de puces PCMCIA supporté par Linux sur
        votre portable, et vous devrez mettre à jour le support PCMCIA dans le
        noyau standard.

        Consultez~<ref id="pcmcia" name="Support PCMCIA"> dans ce document, et
        si vous le pouvez jetez un coup d'oeil à~:

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/pcmcia.html"
             name="La page PCMCIA de Donald">
</quote>

<sect2>IBM Token Ring
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ibmtr

        Le support de Token Ring nécessite plus que la simple écriture d'un
        pilote, il faut aussi écrire les routines de routage source pour Token
        Ring. C'est le routage par la source qui sera le plus long à écrire.

        Peter De Schrijver a passé du temps sur Token Ring récemment, et a
        travaillé avec des cartes Token Ring ISA et MCA d'IBM.

        Le code Token Ring actuel a été inclus dans les premiers noyaux des
        séries 1.3.x.

        Peter dit qu'il a été testé à l'origine avec une carte Token Ring MCA
        16/4 Megabit, mais qu'il devrait fonctionner avec d'autres cartes basées
        sur Tropic.

<sect1>Cartes Ethernet ICL
<p>

<sect2>ICL EtherTeam 16i/32
<p>
        Statut~: Supporté, Nom du pilote~: eth16i

        Mika Kuoppala (<tt>miku@pupu.elt.icl.fi</>) a écrit ce pilote, qui a été
        inclus dans les premiers noyaux 1.3.4x. Cette carte utilise la puce
        MB86965 de Fujitsu qui est aussi utilisée dans les cartes AT1700.

<sect1>Cartes Ethernet Intel<label id="intel">
<p>
        Note~: les noms de certaines cartes Intel sont ambigus au possible et
        prêtent à confusion <!--ambiguous and confusing at best-->. Si vous avez
        un doute, vérifiez le numéro sur la puce principale de la carte
        <tt>i8xxxx</>, ou, pour les cartes PCI, utilisez les informations
        disponibles dans le repertoire <tt>/proc</> et ensuite, comparez-les aux
        numéros listés ici.

<sect2>Ether Express
<p>
        Statut~: Supporté, Nom du pilote~: eexpress

        Cette carte utilise l'Intel i82586. Les premières versions de ce pilote
        (dans les noyaux 1.2) étaient classées en cours de test `alpha', parce
        qu'elles ne fonctionnaient pas correctement pour la plupart des gens. Le
        pilote des versions 2.0 du noyau semble fonctionner bien mieux pour ceux
        qui l'ont essayé. Toutefois, les sources le donnent comme étant toujours
        expérimental, et pose pas mal de probleme sur les machines rapides.

        Les commentaires au début du fichier source donnent la liste de certains
        des problèmes (et solutions) associés à ces cartes.Il a été rapporté que
        la bidouille de ralentissement qui consiste à remplacer tous les
        <tt>outb</> par des <tt>outb_p</> dans le pilote a permis d'éviter des
        blocages pour au moins une personne.

<sect2>Ether Express PRO/10
<p>
        Statut~: Supporté, Nom du pilote~: eepro

        Bao Chau Ha a écrit un pilote pour ces cartes, qui a été inclus dans les
        premiers noyaux 1.3.x. Il peut aussi fonctionner avec certains des
        systèmes Ethernet intégrés de Compaq, basés sur la puce i82595.

<sect2>Ether Express PRO/10 PCI (EISA)
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ? (distribué séparement)

        John Stalba (<tt>stalba@ultranet.com</>) a écrit un pilote pour la
        version PCI. Ces cartes utilisent la puce d'interface PCI PLX9036 avec
        la puce contrôleur-réseau i82596 d'Intel. Si votre carte comporte la
        i82557, alors vous <em>n'avez pas</> cette carte, mais au contraire
        la version dont il est question ci-dessous, qui nécessite par conséquent
        le pilote EEPro100 plutôt que celui-ci.

        Vous pouvez obtenir le pilote `alpha' pour les cartes PCI PRO/10, ainsi
        que les instructions pour l'utiliser, à~:

<quote>
        <url url="http://www.ultranet.com/~stalba/eep10pci.html"
             name="Pilote EEPro10">
</quote>

        Si vous avez la carte EISA, vous devrez certainement bidouiller un peu
        le pilote pour prendre en compte les différents mécanismes de détection
        (PCI ou EISA) qui sont utilisés dans chaque cas.

<sect2>Ether Express PRO 10/100B<label id="eepro100">
<p>
        Statut~: Supporté, Nom du pilote~: eepro100

        Notez que ce pilote <em>ne</> fonctionnera <em>pas</> avec les cartes
        100A qui sont plus anciennes. Les numéros de puces que gère le pilote
        sont i82557/i82558.

        Pour les mises à jour du pilote et~/ ou des informations, consultez~:

<quote>
        <url url="http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html"
             name="Page de l'EEPro-100B">
</quote>

        Pour vous inscrire à la liste de diffusion relative à ce pilote, tapez
        la commande suivante~:

<quote>
        <tt>echo subscribe | /bin/mail
        linux-eepro100-request@cesdis.gsfc.nasa.gov</tt>
</quote>

        Apparemment Donald a été obligé de signer un accord de confidentialité
        qui établit qu'il pouvait en fait communiquer le code-source du pilote~!
        Comment prendre une telle preuve de bêtise de la part d'Intel~?

<sect1>Kingston
<p>
        Kingston fait plusieurs cartes, incluant des cartes à base de NE2000+,
        AMD PCnet, et DEC tulip. La majorité des cartes devrait marcher avec
        leurs pilotes respectifs. Voyez~<url url="http://www.kingston.com"
        name="Kingston Web Page"> pour plus de détails.

        Il paraît que la carte à base de KNE40 DEC 21041 tulip fonctionne très
        bien avec le pilote tulip générique


<sect1>LinkSys
<p>
        LinkSys produit tout un tas de clones de NE2000, certains étant
        de simple cartes ISA, d'autres des cartes ISA `plug and play' et même
        des clones de NE2000 PCI basés sur l'un des jeux de puces NE2000-PCI
        supportés. Il existe tout simplement trop de modèles pour pouvoir tous
        les citer ici.

        LinkSys aime bien Linux, ils ont une page WWW de support spécifique, et
        Linux est imprimé sur les boîtes de certains de leurs
        produits. Consultez~:

<quote>
        <tt>http://www.linksys.com/support/solution/nos/linux.htm</tt>
</quote>

<sect2>Cartes LinkSys Etherfast 10/100.
<p>
        Statut~: Supporté, Nom du pilote~: tulip

        Notez que ces cartes ont connu quelques `révisions' (c-à-d différents
        chipsets utilisés) mais toutes avaient le même nom. La première
        utilisait le chipset DEC. La seconde, le contrôleur réseau Lite-On PNIC
        82c168 PCI, et le support pour celle-ci a été inclus dans le pilote
        tulip standard (depuis la version 0.83). Plus d'informations sur PNIC
        à~:

<quote
        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/pnic.html</>
</quote>

        Pour plus d'informations sur les différentes versions de ces cartes,
        référez vous au site de LinkSys mentionné ci-dessus.

<sect2>LinkSys Pocket Ethernet Adapter Plus (PEAEPP)
<p>
        Statut~: Supporté, Nom du pilote~: de620

        On suppose qu'il s'agit d'un clone du DE-620, et il paraît que cela
        fonctionne bien avec ce pilote. Consultez~<ref id="de-620"
        name="DE-620"> pour plus d'information.

<sect2>Adaptateur LinkSys PCMCIA
<p>
        Statut~: Supporté, Nom du pilote~: de650 (?)

        On suppose qu'il s'agit d'un DE-650 "recarrossé" avec une étiquette différente.
        Consultez~<ref id="de-650" name="DE-650"> pour plus d'information.

<sect1>Microdyne
<p>

<sect2>Microdyne Exos 205T
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ?

        Une autre carte basée sur l'i82586. Dirk Niggemann
        <tt>dirk-n@dircon.co.uk</> a écrit un pilote qu'il classe dans la
        catégorie ``pré-alpha'' et dont il aimerait bien que les gens le
        testent. Ecrivez-lui pour plus de détails.

<sect1>Mylex
<p>
        Mylex peut être joint aux numéros suivants, au cas où quelqu'un aurait
        envie de leur demander quelque chose.

<verb>
        MYLEX CORPORATION, Fremont Ventes: 800-77-MYLEX, (510) 796-6100 FAX:
        (510) 745-8016.
</verb>

        Ils ont aussi un site WWW:
        <url url="http://www.mylex.com" name="Site WWW de Mylex">

<sect2>Mylex LNE390A, LNE390B
<p>
        Statut~: supporté, Nom du pilote~: lne390 (+8390)

        Ces cartes EISA plutôt anciennes utilisent une implémentation à mémoire
        partagée similaire aux wd80x3. Un pilote pour ces cartes est disponible
        dans les noyaux 2.2. Assurez vous de bien spécifier une zone de mémoire
        inférieure a 1 Mo ou alors, supérieure à la taille totale de la RAM de
        votre ordinateur.

<sect2>Mylex LNP101
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Il s'agit d'une carte PCI basée sur la puce 21040 de DEC. On peut
        sélectionner les ports 10BaseT, 10Base2 ou 10Base5 (AUI). La carte
        LNP101 a été testée et elle fonctionne avec le pilote 21040 générique.

        Consultez la section sur la puce 21040 (<ref id="dec-21040" name="DEC
        21040">) pour plus d'information.

<sect2>Mylex LNP104
<p>
        Statut~: Partiellement supporté, Nom du pilote~: de4x5, tulip

        La LNP104 utilise la puce 21050 de DEC pour fournir <em>quatre</> ports
        10BaseT indépendants. Elle devrait fonctionner avec les pilotes 21040
        récents qui savent partager les IRQ, mais personne à ce jour n'a indiqué
        l'avoir essayée (autant que je sache).

<sect1>Ethernet chez Novell~: NExxxx et les clones associés.<label id="novell">
<p>
        Le préfixe `NE' vient de `Novell Ethernet'. Novell a suivi la conception
        la moins chère décrite dans les documentations de National
        Semiconductor, et a vendu les droits de fabrication à Eagle (s'en est
        débarrassé~?), juste pour pouvoir mettre sur le marché des cartes
        Ethernet à prix raisonnables. (La maintenant omniprésente carte NE2000).

<sect2>NE1000, NE2000<label id="ne2k">
<p>
        Statut~: Supporté, Nom du pilote~: ne (+8390)

        ``NE2000'' est maintenant un nom générique pour une conception
        minimaliste basée sur la puce 8390 de National Semiconductor. Ces cartes
        utilisent des E/S programmées plutôt que la mémoire partagée, ce qui
        amène une installation plus facile mais des performances légèrement
        moins bonnes et quelques problèmes. Certains des problèmes qui peuvent
        survenir avec les cartes NE2000 sont cités à <ref id="ne2k-probs"
        name="Problèmes avec...">.

        Quelques clones de NE2000 utilisent la puce `AT/LANTic' 83905 de
        National Semiconductor, qui offre un mode à mémoire partagée similaire à
        celui de la wd8013 et une configuration logicielle via une EEPROM. Le
        mode à mémoire partagée engendrera moins de charge processeur (et sera
        donc plus efficace) que le mode à E/S programmées.

        En général ce n'est pas une bonne idée de placer un clone de NE2000 à
        l'adresse d'E/S <tt>0x300</> parce que pratiquement <em>tous</> les
        pilotes de périphériques testent cette adresse au démarrage. Certains
        clones de NE2000 bas de gamme acceptent difficilement d'être titillés au
        mauvais endroit, et ils répondront en bloquant votre machine.  L'adresse
        <tt>0x320</> est également une mauvaise idée car les pilotes SCSI
        testent <tt>0x330</>.

        Donald a écrit un programme de diagnostic pour NE2000 (<tt>ne2k.c</>)
        qui fonctionne pour toutes les cartes NE2000. Consultez~<ref id="diag"
        name="Programmes de diagnostic"> pour plus d'information.

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

<sect2>NE2000-PCI (RealTek/Winbond/Compex)<label id="ne2k-pci">
<p>
        Statut~: Supporté, Nom du pilote~: ne, ne2k-pci (+8390)

        Oui, croyez-le ou non, des gens fabriquent des cartes PCI basées sur la
        vieille interface de la NE2000, conçue il y a plus de dix
        ans. Actuellement, presque toutes ces cartes sont basées sur la puce
        8029 de RealTek ou la puce~89c940 de Winbond. Les cartes Compex, KTI,
        VIA et Netvin utilisent apparemment aussi ces puces, mais possèdent un
        une signature PCI différente.

        Le dernier noyau Linux~2.0 est capable de détecter automatiquement
        toutes ces cartes et de les utiliser. (Si vous utilisez un noyau
        version~2.0.34 ou plus ancien, vous devriez le mettre à jour pour vous
        assurer que votre carte sera détectée). Il y a dorénavant deux pilotes
        que vous pouvez utiliser, le pilote ISA/PCI originel <tt>ne.c</> et le
        pilote PCI plus récent <tt>ne2k-pci.c</>.

        Pour utiliser le pilote original, vous devez répondre `Y' à l'option
        `Other ISA cards' (`Autres cartes ISA~?') lorsque vous exécutez <tt>make
        config</> car en fait vous utilisez le même pilote~NE2000 que celui des
        cartes~ISA. (Cela devrait accréditer l'idée que ces cartes ne sont en
        aucune façon aussi intelligentes que, disons, une carte à base de
        PCNet-PCI ou DEC 21040...).

        Le récent pilote PCI diffère de la version ISA/PCI par le fait que le
        support pour les cartes 8~bits NE1000 a été supprimé et que les données
        transitent de/vers la carte en de plus gros paquets, sans les pauses que
        les vieilles ISA NE2000 nécessitaient pour opérer de façon fiable. Il en
        résulte un pilote légèrement plus petit, et légèrement plus efficace,
        mais ne vous emballez pas trop vite, les différences ne seront pas
        éclatantes en utilisation normale. (Si vous voulez beaucoup d'efficacité
        avec peu de charge CPU, alors une NE2000 PCI est un très mauvais choix).
        Des mises à jour ainsi que plus d'informations sont disponibles à~:

<quote>
        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html</tt>
</quote>

        Si vous avez une carte PCI NE2000 qui <em>n'est pas</> détectée par le
        dernier pilote, veuillez contacter le responsable du pilote~NE2000 qui
        est indiqué dans <tt>/usr/src/linux/MAINTAINERS</tt>, en lui joignant
        les sorties d'un <tt>cat /proc/pci</tt> et de <tt>dmesg</tt> afin que le
        support pour votre carte puisse être ajouté dans le pilote.

        Notez aussi que pas mal de fabricants de cartes sont connus pour mettre
        un autocollant `Compatible NE2000' sur les boîtes de leurs produits même
        si c'est totalement différent (ex~: PCNet-PCI ou RealTek 8139). En cas
        de doute, regardez la puce principale et comparez avec ce qui est écrit
        ici.

<sect2>NE-10/100
<p>
        Statut~: Non supporté

        Il s'agit de cartes ISA 100Mb/s basées sur les puces DP83800 et DP83840
        de National Semiconductor. Il n'y a actuellement aucun support logiciel,
        et personne n'a indiqué qu'il travaillait à un pilote. Apparemment, la
        documentation de ces puces n'est pas disponible, à part un bien pauvre
        PDF insuffisant pour créer un pilote.

<sect2>NE1500, NE2100<label id="ne1500">
<p>
        Statut~: Supporté, Nom du pilote~: lance

        Ces cartes utilisent la puce 7990 LANCE originelle d'AMD et sont
        supportées grâce au pilote Linux <tt>lance</>. Les clones de NE2100 plus
        récents reposent sur la puce mise à jour PCnet/ISA d'AMD.

        Des versions plus anciennes du pilote <tt>lance</> avaient des problèmes
        pour obtenir la ligne d'IRQ via l'affectation automatique d'IRQ des
        cartes~7990 originelles de Novell/Eagle. Heureusement cela est
        maintenant résolu. Si ce n'est pas le cas, spécifiez l'IRQ via LILO, et
        indiquez-nous si cela pose encore des problèmes.

        La sélection du DMA et des informations sur la numérotation de la puce
        se trouvent dans~<ref id="lance" name="AMD LANCE">.

        Des informations plus techniques sur les cartes Ethernet basées sur
        l'AMD LANCE sont disponibles dans~<ref id="amd-notes" name="Notes sur
        l'AMD...">.

<sect2>NE/2 MCA
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ne2

        Quelques cartes NE2000 MCA ont été fabriquées par diverses sociétés. Ce
        pilote, disponible dans les noyaux 2.2 détectera les cartes suivantes~:
        Novell Ethernet Adapter NE/2, Compex ENET-16 MC/P, et l'Ethernet Adapter
        AE/2 de chez Arco.

<sect2>NE3200<label id="ne3200">
<p>
        Statut~: Non supporté

        Cette vieille carte EISA utilise un 80186 à 8~MHz en compagnie d'un
        i82586. Personne ne travaille à un support et de toute façon, il n'y a
        ni documentation sur la carte, ni de vraie demande pour un pilote.

<sect2>NE3210<label id="ne3210">
<p>
        Statut~: Supporté, Nom du pilote~: ne3210 (+8390)

        Cette carte EISA est complètement différente de la NE3200, car elle
        utilise une puce National Semiconductor 8390. Le pilote se trouve dans
        les noyaux 2.2. Assurez vous d'avoir réglé la mémoire partagée en
        dessous de 1 Mo, ou au dessus de la plus grande adresse de mémoire
        physique qui est installée sur la machine.

<sect2>NE5500
<p>
        Statut~: Supporté, Nom du pilote~: pcnet32

        Ce sont juste des cartes basées sur la puce PCnet-PCI ('970A) d'AMD.
        Plus d'informations sur les cartes à base de LANCE/PCnet se trouvent
        dans~<ref id="lance" name="AMD LANCE">.

<sect1>Proteon
<p>

<sect2>Proteon P1370-EA
<p>
        Statut~: Supporté, Nom du pilote~: ne (+8390)

        Il s'agit apparemment d'un clone de NE2000, et il fonctionne
        correctement avec Linux.

<sect2>Proteon P1670-EA
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Encore une autre carte PCI basée sur la puce Tulip de DEC. On rapporte
        qu'elle fonctionne correctement avec Linux.

        Consultez la section sur la puce 21040 (<ref id="dec-21040" name="DEC
        21040">) pour plus d'informations sur le pilote.

<sect1>Pure Data
<p>

<sect2>PDUC8028, PDI8023
<p>
        Statut~: Supporté, Nom du pilote~: wd (+8390)

        Les séries PDUC8028 et PDI8023 de cartes PureData semblent fonctionner
        correctement, grâce au code de détection spécial qu'a fourni Mike Jagdis
        <tt>jaggy@purplet.demon.co.uk</>. Le support pour ces cartes est intégré
        dans le pilote Western Digital (WD).

<sect1>Racal-Interlan
<p>
        On peut joindre Racal-Interlan via le WWW à <tt>www.interlan.com</>. Je
        crois qu'ils étaient connus sous le nom de MiCom-Interlan à une époque.

<sect2>ES3210
<p>
        Statut~: Partiellement supporté, Nom du pilote~: es3210

        Il s'agit d'une carte EISA à mémoire partagée basée sur le 8390. Un
        pilote expérimental pour les versions 2.2 du noyau est disponible.  On
        indique qu'il fonctionne correctement, mais la détection de l'IRQ EISA
        et de l'adresse de mémoire partagée paraît ne pas fonctionner avec (au
        moins) les premières révisions de ces cartes. (Ce problème n'est pas
        spécifique à Linux d'ailleurs). Dans ce cas, vous devez les fournir au
        pilote~; par exemple, pour une carte utilisant l'IRQ~5 et la mémoire
        partagée en~<tt>0xd0000</>. Avec un pilote modulaire, ajoutez
        <tt>options es3210 irq=5 mem=0xd0000</> à votre fichier
        <tt>/etc/conf.modules</tt>.  Si le pilote est intégré au noyau, donnez
        lui <tt>ether=5,0,0xd0000,eth0</> au boot.  L'adresse de base d'E/S est
        détectée automatiquement et une valeur de zéro doit donc être utilisée.

<sect2>NI5010
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ni5110

        Le pilote pour ces vieilles cartes 8~bits MiCom-Interlan était
        disponible séparément, mais on le trouve maintenant en tant que pilote
        expérimental dans les noyaux 2.2.

<sect2>NI5210
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ni52

        Cette carte utilise aussi les puces Intel et Michael Hipp a écrit un
        pilote pour elle. Il est inclus dans le noyau standard en tant que
        pilote en phase `alpha'. Michael aimerait recevoir des informations des
        utilisateurs qui possèdent cette carte.  Consultez~<ref id="alfa"
        name="Les pilotes `Alpha'"> pour des informations importantes sur
        l'utilisation des pilotes Ethernet en phase de test `alpha' avec Linux.

<sect2>NI6510 (not EB)<label id="ni65xx">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: ni65

        Il existe également un pilote pour la NI6510 (basée sur la puce LANCE),
        et il a aussi été écrit par Michael Hipp. Là aussi, il s'agit d'un
        pilote `alpha'. Pour une raison inconnue, cette carte n'est pas
        compatible avec le pilote LANCE générique. Consultez~<ref id="alfa"
        name="Les pilotes `Alpha'"> pour des informations importantes sur
        l'utilisation des pilotes Ethernet en phase de test `alpha' avec Linux.

<sect2>EtherBlaster (aka NI6510EB)
<p>
        Statut~: Supporté, Nom du pilote~: lance

        Depuis le noyau 1.3.23, le pilote LANCE générique comprend un test
        supplémentaire pour la signature <tt>0x52, 0x44</> spécifique de la
        NI6510EB. D'autres ont indiqué que cette signature n'est pas la même
        pour toutes les cartes NI6510EB, ce qui peut amener le pilote
        <tt>lance</> à ne pas détecter votre carte. Si cela vous arrive, vous
        pouvez changer la procédure de détection (aux environs de la ligne 322
        de <tt>lance.c</>) pour qu'elle <tt>printk()</> (affiche) quelles sont
        les valeurs pour votre carte, puis utiliser ces valeurs à la place du
        <tt>0x52, 0x44</> donné par défaut.

        Les cartes devraient probablement être placées en mode `hautes
        performances' et non pas dans le mode compatible-NI6510 lorsque l'on
        utilise le pilote <tt>lance</>.

<sect1>RealTek
<p>

<sect2>RealTek RTL8002/8012 (AT-Lan-Tec) Pocket adaptor<label id="aep-100">
<p>
        Statut~: Supporté, Nom du pilote~: atp

        Il s'agit d'un adaptateur de poche générique, peu cher, développé en
        OEM, vendu par AT-Lan-Tec, et (sans doute) par un certain nombre
        d'autres fournisseurs. Un pilote est inclus dans le noyau standard. Une
        quantité substantielle d'information est contenue dans le fichier source
        du pilote, <tt>atp.c</>.

        Notez que dans les premières versions de ce pilote, le nom de
        périphérique que vous passiez à <tt>ifconfig</> <em>n'était pas</>
        <tt>eth0</> mais~<tt>atp0</>.

<sect2>RealTek 8009
<p>
        Statut~: Supporté, Nom du pilote~: ne (+8390)

        C'est un clone de NE2000 ISA, et il fonctionne très bien avec le pilote
        NE2000 Linux. Le programme <tt>rset8009.exe</> peut être obtenu depuis
        le site WWW de RealTek's <tt>http://www.realtek.com.tw</tt> - ou via ftp
        depuis le même site.

<sect2>RealTek 8019
<p>

        Statut~: Support, Nom du pilote~: ne (+8390)

        Celle-ci est la version "Plug and Pray" de la précédente. Utilisez
        l'utilitaire DOS pour désactiver le PnP et activez la configuration
        logicielle. Attribuez une IRQ et des adresses d'E/S raisonnables, et
        tout devrait aller pour le mieux. (Si vous utilisez les modules,
        n'oubliez pas d'ajouter une option <tt>io=0xNNN</> au fichier
        <tt>/etc/conf.modules</>. Le programme <tt>rset8009.exe</> peut être
        obtenu depuis le site WWW de RealTek's <tt>http://www.realtek.com.tw</>
        --~ou via ftp depuis le même site.

<sect2>RealTek 8029
<p>
        Statut~: Supporté, Nom du pilote~: ne2k-pci

        Il s'agit d'une implémentation PCI sur une seule puce d'un clone de
        NE2000. Différents fournisseurs vendent maintenant des cartes comportant
        cette puce. Consultez~<ref id="ne2k-pci" name="NE2000 PCI"> pour des
        informations sur l'utilisation d'une de ces cartes. Notez qu'il s'agit
        d'un design de plus de dix ans collé sur un bus PCI, et ce ne sera pas
        vraiment meilleur que pour le pendant ISA.

<sect2>RealTek 8129/8139<label id="rtl8139">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: rtl8139

        Encore une autre solution Ethernet PCI sur une puce unique de
        RealTek. Un pilote pour les cartes basées sur elle devrait être inclus
        dans la version~2.0.34 du noyau Linux. Pour plus d'informations,
        consultez~:

<quote>
        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html</tt>
</quote>

<sect1>Sager
<p>

<sect2>Sager NP943
<p>
        Statut~: Partiellement supporté, Nom du pilote~: 3c501

        Il s'agit juste d'un clone de 3c501, avec un préfixe de S.A. PROM
        différent. Je pense qu'elle est aussi cliniquement morte que la vraie
        3c501, en passant.  Le pilote vérifie la présence de l'identificateur de
        la NP943 et la traite comme une 3c501 par la suite. Consultez~<ref
        id="3c501" name="3Com 3c501"> pour toutes les bonnes raisons qui font
        que vous ne devriez vraiment pas avoir ne serait-ce que l'intention
        d'utiliser une de ces cartes.

<sect1>Schneider &amp; Koch
<p>

<sect2>SK G16
<p>
        Statut~: Supporté, Nom du pilote~: sk_g16

        Ce pilote, écrit par PJD Weichmann et SWS Bern, a été inclus dans les
        noyaux des versions 1.1. Il se trouve que la SK G16 est semblable à la
        NI6510, en ce sens qu'elle est basée sur la première édition de la puce
        LANCE (la 7990). Une fois de plus, cette carte semble ne pas fonctionner
        avec le pilote LANCE générique.

<sect1>SEEQ
<p>

<sect2>SEEQ 8005
<p>
        Statut~: Supporté, Nom du pilote~: seeq8005

        Ce pilote qui est l'oeuvre de Hamish Coleman a été inclus dans les
        premiers noyaux 1.3.x. Peu d'informations sur la carte figurent dans le
        pilote, et donc pas grand chose à en dire ici. Si vous avez une
        question, vous aurez probablement tout intérêt à envoyer un message à
        <tt>hamish@zot.apana.org.au</>.

<sect1>SMC (Standard Microsystems Corp.) <label id="smc">
<p>
        La division Ethernet de Western Digital a été achetée par SMC il y a bien
        longtemps lorsque les wd8003 et wd8013 étais les produits phares. Depuis
        lors, SMC a continué de faire des cartes ISA basées sur le 8390 (Elite16,
        Ultra, EtherZ) et a aussi étoffé son catalogue de quelques produits PCI.

        Voici comment contacter SMC~: 

        SMC / Standard Microsystems Corp., 80 Arkay Drive, Hauppage, New York,
        11788, USA.  Support technique par téléphone~: 800-992-4762 (USA) ou
        800-433-5345 (Canada) ou 516-435-6250 (Autres pays).  Demandes de
        documentation~: 800-SMC-4-YOU (USA) ou 800-833-4-SMC (Canada) ou
        516-435-6255 (Autres pays).  Support technique par E-mail~:
        <tt>techsupt@ccmail.west.smc.com</>.  Site FTP ~: <tt>ftp.smc.com</>.
        Site Web~: <url url="http://www.smc.com" name="SMC">.

<sect2>WD8003, SMC Elite
<p>
        Statut~: Supporté, Nom du pilote~: wd (+8390)

        Ce sont les versions 8~bits de la carte. La 8003 8~bits est légèrement
        moins chère, mais ne vaut ces économies que pour une utilisation
        légère. Notez que certaines des cartes sans EEPROM (des clones avec des
        cavaliers, ou de vieilles <em>vieilles</> vieilles cartes wd8003) n'ont
        aucun moyen d'indiquer la ligne d'IRQ qu'elles utilisent. Dans ce cas,
        l'affectation automatique d'IRQ est utilisée, et si cela échoue, le
        pilote utilise l'IRQ 5 sans rien dire. Vous pouvez obtenir les
        disquettes d'installation/de paramétrage de SMC sur leur site FTP.
        Notez que certains des plus récents programmes 'SuperDisk' de SMC ne
        réussiront pas à détecter les vraies vieilles cartes sans EEPROM. Le
        fichier <tt>SMCDSK46.EXE</> semble être un bon choix passe-partout.
        Notez aussi que les réglages des cavaliers pour toutes leurs cartes se
        trouvent dans un fichier texte dans l'archive sus-mentionnée. La
        dernière (meilleure~?) version peut être obtenue depuis
        <tt>ftp.smc.com</>.

        Comme ces cartes sont fondamentalement les mêmes que leurs homologues
        16~bits (WD8013 / SMC Elite16), vous devriez consulter la section
        suivante pour en savoir plus.

<sect2>WD8013, SMC Elite16<label id="8013">
<p>
        Statut~: Supporté, Nom du pilote~: wd (+8390)

        Au fil des ans, la conception a ajouté plus de registres et une
        EEPROM. (Les premières cartes wd8003 sont apparues il y a environ dix
        ans~!) Les clones portent en général un nom en `8013', et se passent
        habituellement d'EEPROM au profit de cavaliers. Les cartes SMC dernier
        modèle auront la puce SMC 83c690 au lieu de la DP8390 de National
        Semiconductor que l'on trouvait sur les premières. Les cartes conçues
        pour utiliser la mémoire partagée sont un peu plus rapides que celles
        qui reposent sur les E/S programmées (PIO), spécialement avec des
        paquets de taille importante. Plus important, du point de vue du pilote,
        cela permet d'éviter quelques bogues du mode PIO du 8390, de garantir un
        accès sûr au tampon de paquets sur un système multi-thread, et de ne
        plus avoir un registre de données PIO qui bloque votre machine pendant
        les procédures de détection après un redémarrage à chaud.

        Les cartes sans EEPROM qui ne peuvent pas lire l'IRQ sélectionnée
        essaieront l'affectation automatique d'IRQ (auto-IRQ), et si cela
        échoue, affecteront sans rien dire l'IRQ 10. (Les versions 8~bits
        affecteront l'IRQ 5).

        Pour les cartes qui n'ont pas une quantité de mémoire embarquée
        standard, la taille de la mémoire peut être spécifiée au moment du
        démarrage (ou dans le fichier <tt>/etc/conf.modules</> si vous utilisez
        les modules). La taille mémoire standard est de 8~Ko pour une carte
        8~bits et de 16~Ko pour une carte 16~bits. Par exemple, les
        antédiluviennes WD8003EBT peuvent être configurées par cavaliers pour
        utiliser 32~Ko. Pour avoir un accès complet à cette mémoire, vous aurez
        recours à quelque chose comme (pour une adresse d'E/S de base de
        <tt>0x280</> et l'IRQ~9)~:

<code>
        LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0
</code>

        Consultez aussi~<ref id="8013-probs" name="Les problèmes des 8013"> pour
        certains des problèmes les plus classiques et les questions qui
        reviennent le plus fréquemment.

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

<sect2>SMC Elite Ultra<label id="ultra">
<p>
        Statut~: Supporté, Nom du pilote~: smc-ultra (+8390)

        Cette carte Ethernet est basée sur la 83c790 de SMC, qui comporte
        quelques nouveautés par rapport à la 83c690. Bien qu'elle possède un
        mode similaire aux anciennes cartes Ethernet SMC, elle n'est pas
        entièrement compatible avec les vieux pilotes WD80*3. Néanmoins, dans ce
        mode le pilote partage la plupart de son code avec les autres pilotes
        8390, tout en étant légèrement plus rapide qu'un clone de WD8013.

        Puisqu'une partie de l'Ultra <em>ressemble</> à une 8013, sa procédure
        de détection est censée en trouver une avant que celle de la wd8013 
        n'ait une chance de l'identifier par erreur.

        Donald a mentionné qu'il est possible d'écrire un pilote séparé pour le
        mode `Altego' de l'Ultra, qui permet d'enchaîner les transmissions au
        coût d'une utilisation inefficace des tampons de réception, mais cela
        n'arrivera probablement jamais.

        Utilisateurs d'adaptateurs SCSI dotés du contrôle de bus, prenez note~:
        dans le manuel qui accompagne Interactive UNIX, il est mentionné qu'une
        bogue dans la SMC Ultra cause des corruptions de données avec des
        disques SCSI utilisés derrière un adaptateur aha-154X. Cela touche
        certainement aussi des cartes compatibles aha-154X, comme les BusLogic,
        et les adaptateurs SCSI AMI-FastDisk.

        SMC a reconnu que le problème se produit avec Interactive, et des
        anciens pilotes Windows NT. Il s'agit d'un conflit matériel avec des
        révisions antérieures de la carte qui peut être contourné dans la
        conception du pilote. Le pilote actuel de l'Ultra vous protège contre ce
        problème en n'activant la mémoire partagée que lors des transferts de
        données avec la carte. Assurez-vous que votre version de noyau soit au
        moins la 1.1.84, ou que celle du pilote indiquée au démarrage est au
        moins <tt>smc-ultra.c:v1.12</>, sinon vous êtes vulnérable à ce
        problème.

        Si vous avez l'intention d'utiliser ce pilote sous la forme d'un module
        chargeable, vous devriez probablement consulter~<ref id="modules"
        name="Utiliser les pilotes Ethernet comme modules"> pour des
        informations spécifiques aux modules.

<sect2>SMC Elite Ultra32 EISA<label id="ultra32">
<p>
        Statut~: Supporté, Nom du pilote~: smc-ultra32 (+8390)

        Cette carte EISA partage nombre de points communs avec son pendant
        ISA. Un pilote qui fonctionne (et qui est stable) est inclus dans les
        versions 2.0 et 2.2 du noyau. Les remerciements vont à Leonard Zubkoff
        pour l'achat de quelques unes de ces cartes afin que le support Linux
        pour celles-ci puisse être réalisé.

<sect2>SMC EtherEZ (8416)
<p>
        Statut~: Supporté, Nom du pilote~: smc-ultra (+8390)

        Cette carte utilise la puce 83c795 de SMC et supporte la spécification
        Plug 'n Play. Elle comporte aussi un mode compatible <em>SMC Ultra</>
        qui lui permet d'être utilisée avec le pilote Ultra de Linux. Pour de
        meilleurs résultats, utilisez le programme provenant de chez SMC et
        permettant de désactiver le PnP et de la configurer pour le mode à
        mémoire partagée. Consultez les informations ci-dessus pour des notes
        sur le pilote Ultra.

        Pour les noyaux 1.2, la carte devait être configurée pour opérer en
        mémoire partagée. Néanmoins, les noyaux 2.0 peuvent utiliser la carte
        dans ce mode ou en E/S programmées. Celui-là sera légèrement plus
        rapide, et requerra moins de ressources processeur, par ailleurs.

<sect2>SMC EtherPower PCI (8432)<label id="smc-pci">
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        NB~: L'EtherPower~II est une carte totalement différente. Voir plus
        bas~!

        Ces cartes sont une implémentation de base de la puce 21040 de DEC,
        c'est-à-dire une grosse puce et quelques transceivers. Donald a utilisé
        une de ces cartes pour son développement du pilote générique 21040
        (aussi connu sous le nom de <tt>tulip.c</>). Merci de nouveau à Duke
        Kamstra, d'avoir fourni une carte sur laquelle réaliser le
        développement.

        Certaines des dernières révisions de cette carte utilisent la récente
        puce 21041 de DEC, ce qui peut causer des problèmes avec des versions
        anciennes du pilote <tt>tulip</>. Si vous avez des problèmes,
        assurez-vous d'utiliser la dernière version du pilote, qui peut ne pas
        encore se trouver dans l'arborescence actuelle du noyau.

        Consultez~<ref id="dec-21040" name="DEC 21040"> pour plus de détails sur
        l'utilisation d'une de ces cartes, et l'état d'avancement actuel du
        pilote.

        Apparemment, la toute dernière révision de la carte, l'EtherPower-II,
        utilise la puce 9432. Il n'est pas certain pour l'instant que celle-ci
        fonctionnera avec le pilote actuel. Comme d'habitude, si vous n'êtes pas
        sûr, vérifiez que vous pourrez rendre la carte si elle ne fonctionne pas
        avec le pilote Linux <em>avant</> de payer.

<sect2>SMC EtherPower II PCI (9432)<label id="smc-pci-II">
<p>
        Statut~: Partiellement supporté, Nom du pilote~: epic100

        Ces cartes, basées sur la puce~83c170 de~SMC, sont complètement
        différentes des cartes basées sur la~Tulip. Un nouveau pilote est inclus
        dans les noyau~2.0 et 2.2 pour les supporter. Pour plus de détails, 
        consultez~:

        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html</tt>

<sect2>SMC 3008
<p>
        Statut~: Non supporté

        Ces cartes 8~bits sont basées sur la puce MB86950 de Fujitsu, qui est
        une ancienne version de la MB86965 utilisée dans le pilote Linux de
        l'at1700. Russ dit que vous devriez probablement pouvoir bidouiller un
        pilote en regardant le code de <tt>at1700.c</> et son pilote DOS en mode
        paquet pour la carte Tiara (<tt>tiara.asm</>). Ces cartes ne sont pas
        très répandues.

<sect2>SMC 3016
<p>
        Statut~: Non supporté

        Il s'agit de cartes 16~bits à E/S mappées, à puce 8390, très similaires
        à une carte NE2000 générique. Si vous pouvez obtenir les spécifications
        chez SMC, alors réaliser un portage du pilote NE2000 sera certainement
        relativement facile. Ces cartes ne sont pas très répandues.

<sect2>SMC-9000 / SMC 91c92/4
<p>
        Statut~: Supporté, Nom du pilote~: smc9194

        La SMC9000 est une carte VLB basée sur la puce 91c92. La 91c92 apparaît
        aussi sur un petit nombre de cartes d'autres marques, mais est plutôt
        peu commune. Erik Stahlman (<tt>erik@vt.edu</>) a écrit ce pilote qui se
        trouve dans les noyaux 2.0, mais pas dans les 1.2 plus anciens.  Vous
        devriez pouvoir l'intégrer à une arborescence de noyau 1.2 avec un
        minimum de difficultés.

<sect2>SMC 91c100
<p>

        Statut~: Partiellement supporté, Nom du pilote~: smc9194

        Le pilote SMC 91c92 est supposé fonctionner pour les cartes basées sur
        cette puce 100Base-T, mais à l'heure actuelle cela n'a pas été vérifié.

<sect1>Texas Instruments
<p>

<sect2>ThunderLAN<label id="tlan">
<p>
        Statut~: Supporté, Nom du pilote~: tlan

        Ce pilote supporte beaucoup de cartes ethernet intégrées aux ordinateurs
        Compaq, incluant les familles NetFlex et Netelligent. Il supporte aussi
        les produits Olicom 2183, 2185, 2325 et 2326.

<sect1>Thomas Conrad
<p>

<sect2>Thomas Conrad TC-5048
<p>
        Encore une autre carte PCI basée sur la puce 21040 de DEC.

        Consultez la section sur la puce 21040 (<ref id="dec-21040" name="DEC
        21040">) pour plus d'informations.

<sect1>VIA
<p>
        Vous ne verrez probablement jamais une carte VIA, car VIA fabrique
        plusieurs puces réseau qui sont ensuite utilisées par d'autres dans la
        construction de leurs cartes ethernet. Ils ont un site WWW à~:

<quote>
        <tt>http://www.via.com.tw/</tt>
</quote>

<sect2>VIA 86C926 Amazon
<p>
        Statut~: Supporté, Nom du pilote~: ne, ne2k-pci (+8390)

        Ce contrôleur est l'offre NE2000 PCI de VIA. Vous avez le choix entre le
        pilote ISA/PCI <tt>ne.c</> ou le pilote PCI <tt>ne2k-pci.c</>. Référez
        vous à la section NE2000 PCI pour plus de détails.

<sect2>VIA 86C100A Rhine II (et 3043 Rhine I)
<p>
        Statut~: Supporté, Nom du pilote~: via-rhine

        Ce pilote relativement récent se trouve dans les noyaux 2.0 et
        2.2. Cette puce est une amélioration de la NE2000 86C926 dans la mesure
        où elle gère les transferts par contrôle de bus, mais du fait de
        l'obligation d'aligner les tampons sur 32~bits, les gains sont
        limités. Pour plus de détails, et les mises à jour, référez vous à~:

        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html</tt>


<sect1>Western Digital
<p>
        Référez vous à la section <ref id="smc" name="SMC"> pour plus
        d'informations sur les cartes SMC. (SMC a racheté la section cartes
        réseau de Western Digital il y a bien longtemps).

<sect1>Winbond
<p>
        Winbond ne fabrique, ni ne vend de cartes au grand public~--~au lieu de
        cela, ils font des puces pour cartes réseau tout en un, les vendent à
        d'autres entreprises, qui les collent sur une carte PCI, ajoutent leur
        nom et ensuite, les revendent.

<sect2>Winbond 89c840
<p>
        Statut~: Partiellement Supporté, Nom du pilote~: winbond-840

        Ce pilote n'est pas actuellement distribué avec le noyau, car il est en
        phase de test. Il est disponible à~:

        <tt>http://cesdis.gsfc.nasa.gov/linux/drivers/test/winbond-840.c</tt>

<sect2>Winbond 89c940
<p>
        Statut~: Supporté, Nom du pilote~: ne, ne2k-pci (+8390)

        Cette puce est l'une des deux que l'on retrouve souvent sur les cartes
        NE2000 PCI de bas de gamme vendues par beaucoup de fabriquants. Notez
        que c'est toujours une idée vieille de plus de 10 ans collée sur un bus
        PCI. Les performances ne seront pas meilleures que pour l'équivalent
        ISA.
        
<sect1>Xircom<label id="xircom">
<p>
        Depuis des temps immémoriaux, Xircom refusait de dévoiler les informations 
        nécessaires à l'écriture d'un pilote, à moins que vous ne vous livriez  
        à eux corps et âme. Apparemment, suffisamment d'utilisateurs de Linux les 
        ont harcelé pour obtenir du support pour un pilote (ils prétendent 
        supporter tous les systèmes d'exploitation réseau populaires...), ce qui
        les a amenés à changer de politique afin de permettre la diffusion de la 
        documentation, sans avoir à signer un accord de confidentialité. Certains 
        ont dit qu'ils allaient distribuer les sources du pilote SCO, alors que 
        d'autres ont dit qu'ils ne fournissaient plus de documentation sur les 
        produits `obsolètes', comme les premiers modèles PE. Si vous êtes intéressés 
        et que vous voulez vérifier par vous même, vous pouvez joindre Xircom au
        1-800-874-7875, 1-800-438-4526 ou au +1-818-878-7600.

        (NDT~: les deux premiers numéros sont des numéros verts aux États-Unis et
        ne sont pas accessibles depuis l'étranger. Le dernier est un numéro
        international).

<sect2>Xircom PE1, PE2, PE3-10B*
<p>
        Statut~: Non supporté.

        Ce n'est pas pour vous réconforter, mais si vous avez l'un de ces
        adaptateurs sur port parallèle, vous pourrez peut-être l'utiliser sous
        l'émulateur DOS avec les pilotes DOS fournis par Xircom. Vous devrez
        autoriser l'accès de DOSEMU au port parallèle, et certainement jouer
        avec SIG (le générateur d'interruptions stupides de DOSEMU, en anglais
        <sl>Silly Interrupt Generator</>).

<sect2>Cartes Xircom PCMCIA
<p>
        Statut~: Partiellement Supporté, Nom du pilote~: ????

        Les pilotes de certaines cartes Xircom PCMCIA sont disponibles dans le
        paquetage PCMCIA de David Hinds. Vérifiez là-bas pour de plus amples
        informations.

<sect1>Zenith<label id="zenith">
<p>

<sect2>Z-Note<label id="z-note">
<p>
        Statut~: Supporté, Nom du pilote~: znet

        L'adaptateur réseau intégré au Z-Note est basé sur la puce i82593
        d'Intel, et utilise <em>deux</> canaux DMA. Un pilote (alpha~?), est
        disponible dans la version courante du noyau. Comme tous les adaptateurs
        de poche ou portables, il se trouve dans la section `Pocket and portable
        adaptors' lorsque vous exécutez <tt>make config</>.  Notez aussi que
        l'IBM ThinkPad 300 est compatible avec le Z-Note.

<sect1>Znyx<label id="zynx">
<p>

<sect2>Znyx ZX342 (DEC 21040 based)
<p>
        Statut~: Supporté, Nom du pilote~: de4x5, tulip

        Vous avez le choix entre <em>deux</> pilotes pour les cartes basées sur
        cette puce. D'une part le pilote DE425 écrit par David, d'autre part le
        pilote 21040 générique écrit par Donald.

        Notez que depuis la version 1.1.91, David a ajouté une option de
        compilation qui permet aux cartes non-Digital (comme les cartes Znyx) de
        fonctionner avec ce pilote. Jetez un coup d'oeil au fichier
        <tt>README.de4x5</> pour les détails.

        Consultez~<ref id="dec-21040" name="DEC 21040"> pour plus d'informations
        sur ces cartes, et la situation actuelle du pilote.


<sect1>Identifier une carte inconnue<label id="mystery">
<p>
        OK, l'ami du voisin du cousin de votre oncle a un frère qui a trouvé une
        vieille carte Ethernet ISA dans le boîtier de l'AT qui servait de cage
        pour le hamster de son fils. D'une manière ou d'une autre vous avez fini
        par vous retrouver avec cette carte et vous voudriez essayer de
        l'utiliser avec Linux, mais personne n'a le commencement du début d'une
        idée de ce qu'elle est et il n'y a aucune documentation.

        Tout d'abord, cherchez n'importe quel numéro de modèle évident qui
        pourrait fournir un indice. Un numéro de modèle qui contient 2000 sera
        certainement un clone de NE2000. Une carte avec 8003 ou 8013 écrit
        quelque part dessus sera une carte WD80x3 de Western/Digital ou une SMC
        Elite, ou un clone de l'une d'elles.

<sect2>Identifier le contrôleur d'interface réseau (Network Interface
Controller, NIC)
<p>
        Cherchez la plus grosse puce sur la carte. Ce sera le contrôleur réseau
        (NIC) lui-même, et la plupart peuvent être identifiés par leur
        référence. Si vous savez quel NIC se trouve sur la carte, ce qui suit
        devrait vous aider à deviner de laquelle il s'agit.

        Encore à l'heure actuelle, le NIC le plus courant est la puce DP8390 de
        National Semiconductor, alias NS32490, alias DP83901, alias DP83902,
        alias DP83905, alias DP83907. Et il ne s'agit que de celles fabriquées
        par National Semiconductor~! D'autres sociétés comme Winbond et UMC
        produisent des clones de DP8390 et DP83905, comme la 89c904 de Winbond
        (un clone de DP83905) et la 9090 d'UMC. Si la carte a quelque chose qui
        s'approche d'un 8390, il y a des chances pour qu'il s'agisse d'un clone
        de NE1000 ou de NE2000. Parmi les cartes basées sur le~8390, arrivent en
        deuxième position les wd80x3 (de Western/Digital) et ses clones.  Des
        cartes avec un DP83905 peuvent être configurées pour être une NE2000
        <em>ou</> une wd8013. Les versions les plus récentes des wd80x3 de base
        et des SMC Elite possèdent un 83c690 en lieu et place du DP8390
        d'origine.  Les cartes SMC Ultra ont un 83c790, et utilisent un pilote
        légèrement différent de celui des cartes wd80x3. Les cartes EtherEZ de
        SMC ont un 83c795, et utilisent le même pilote que la SMC Ultra. Toutes
        les cartes BNC basées sur un genre de 8390 ou l'un de ses clones auront
        généralement un 8392 (ou un 83c692, ou un ???392) en boîtier DIP 16
        broches tout près du connecteur BNC.

        L'Intel i82586 est un autre NIC courant que l'on trouve sur des cartes
        plus anciennes. Parmi celles qui en comportent un, citons la 3c505, la
        3c507, la 3c523, l'EtherExpress-ISA d'Intel, l'Exos-205T de Microdyne,
        et la NI5210 de Racal-Interlan.

        Le NIC d'origine de la carte LANCE d'AMD était numéroté AM7990, et les
        révisions plus récentes incluent le 79c960, le 79c961, le 79c965, le
        79c970, et le 79c974. La plupart des cartes ayant l'une de ces puces
        fonctionnera avec le pilote LANCE de Linux, à l'exception des vieilles
        cartes NI6510 de Racal-Interlan qui possèdent leur propre pilote.

        Les cartes PCI plus récentes et qui comportent un NIC de DEC référencé
        21040, 21041, 21140, ou un numéro approchant, devraient être capables
        d'utiliser le pilote `tulip' ou le `de4x5' de Linux.

        D'autres cartes PCI qui comportent une grosse puce marquée RTL8029,
        89C940 ou 86C926 sont des clones de NE2000, et le pilote `ne' des
        versions 2.0 et supérieures du noyau Linux devrait automatiquement les
        détecter au démarrage.

<sect2>Identifier l'adresse Ethernet
<p>
        Chaque carte Ethernet possède sa propre adresse sur six octets qui lui
        est unique et propre. Les trois premiers octets de cette adresse
        Ethernet sont les mêmes pour chaque carte construite par un constructeur
        donné.  Par exemple, toutes les adresses des cartes de SMC commencent
        par <tt>00:00:c0</>. Les trois derniers octets sont affectés par le
        constructeur de façon unique à chaque carte individuelle au fur et à
        mesure de leur fabrication.

        Si votre carte comporte un autocollant qui donne tous les six octets de
        son adresse, vous pouvez identifier le constructeur à partir des trois
        premiers. Toutefois, il est plus courant de ne trouver que les trois
        derniers octets, imprimés sur un autocollant attaché à une PROM montée
        sur la carte, ce qui ne vous indique rien du tout.

        Vous pouvez déterminer quel constructeur possède quelles adresses à
        partir de la RFC-1340. Apparemment il existe également une liste plus à
        jour qui est disponible à divers endroits. Essayez de faire une
        recherche WWW ou FTP sur <tt>EtherNet-codes</> ou <tt>Ethernet-codes</>
        et vous trouverez quelque chose.

<sect2>Quelques astuces pour essayer d'utiliser une carte inconnue
<p>
        Si vous n'êtes toujours pas sûr(e) de quelle carte il s'agit, mais que
        vous avez un peu réduit le champ des possibilités, alors vous pouvez
        construire un noyau en y incluant tout un tas de pilotes, et voir si
        l'un d'entre eux détecte automatiquement la carte lors du démarrage.

        Si le noyau ne détecte pas la carte, il se peut que la carte ne soit pas
        configurée à l'une des adresses que le pilote teste lorsqu'il en
        recherche une. Dans ce cas, vous pourriez essayer de récupérer
        <tt>scanport.tar.gz</> sur votre site FTP Linux préféré, et voir s'il
        peut trouver l'adresse pour laquelle votre carte est configurée. Ce
        programme parcourt l'espace d'adressage d'entrée/sortie de <tt>0x100</>
        à <tt>0x3ff</> en cherchant des périphériques qui ne sont pas déjà
        enregistrés dans <tt>/proc/ioports</tt>.  S'il en trouve un qui soit
        inconnu et qui démarre à une adresse donnée, vous pouvez alors
        explicitement diriger les procédures de détection Ethernet vers cette
        adresse en utilisant un argument de démarrage <tt>ether=</>.

        Si vous arrivez à faire en sorte que la carte soit détectée, vous pouvez
        alors deviner la fonction des cavaliers inconnus en les modifiant un par
        un et en regardant à quelle adresse d'E/S de base et à quelle IRQ la
        carte est détectée. Les paramètres d'IRQ peuvent aussi habituellement
        être déterminés en suivants les traces au dos de la carte jusqu'à
        l'endroit où les cavaliers sont soudés. En comptant les `doigts d'or'
        sur la face arrière, depuis l'extrémité de la carte où se situe la
        plaque métallique qui se fixe au coffret du PC, <!-- d'accord, c'est pas
        dans la version US, mais c'est plus clair, non~?-) - steph --> vous avez
        les IRQ 9, 7, 6, 5, 4, 3, 10, 11, 12, 15, et 14 sur les `doigts' 4, 21,
        22, 23, 24, 25, 34, 35, 36, 37, et 38 respectivement. Les cartes
        huit~bits ne comportent que les doigts 1 à 31.

        Les cavaliers qui paraissent ne servir à rien ont généralement pour
        fonction de sélectionner l'adresse mémoire d'une ROM de démarrage (boot
        ROM) optionnelle. D'autres situés près des connecteurs BNC, RJ-45 ou AUI
        servent généralement à sélectionner le support physique de
        sortie. Ceux-ci se situent typiquement près des `boîtes noires' qui
        contiennent les convertisseurs de tension, marquées YCL, Valor, ou
        Fil-Mag.

        Une collection intéressante de configurations de cavaliers pour diverses
        cartes se trouve à l'URL suivante~:

<quote>
        <url url="http://www.slug.org.au/NIC/"
             name="Paramétrage des cartes Ethernet">
</quote>

<sect1>Pilotes pour périphériques Non-Ethernet
<p>
        Quelques autres pilotes existent dans les sources Linux qui se
        présentent <em>comme</> un périphérique Ethernet vis-à-vis des
        programmes réseaux, bien qu'ils ne soient pas réellement Ethernet. Les
        voici brièvement présentés pour être complet.

        <tt>dummy.c</> - Le but de ce pilote est de fournir un périphérique pour
        désigner une route qui le traverse, mais sans transmettre réellement de
        paquets.

        <tt>eql.c</> - Load Equalizer (égaliseur de charge), qui regroupe
        plusieurs périphériques esclaves (généralement des modems) et répartit
        la charge en transmission entre eux tout en ne présentant qu'un seul
        périphérique aux programmes réseau.

        <tt>ibmtr.c</> - IBM Token Ring (anneau à jeton), qui n'est pas
        réellement de l'Ethernet. L'anneau à `jeter' nécessite du routage par la
        source et autres trucs dégoûtants.

        <tt>loopback.c</> - Loopback (boucle locale), par lequel passent tous
        les paquets émis par votre machine à destination de votre machine.
        Essentiellement, il se contente de sortir les paquets de la file
        d'attente d'émission et de les placer dans la file d'attente de
        réception.

        <tt>pi2.c</> - Interface Ottawa Amateur Radio Club PI et PI2.

        <tt>plip.c</> - Parallel Line Internet Protocol (PLIP, IP sur port
        parallèle), qui permet à deux ordinateurs de s'envoyer des paquets l'un
        à l'autre via leurs ports parallèles, en mode point-à-point.

        <tt>ppp.c</> - Point-to-Point Protocol (RFC1331), destiné à la
        transmission de datagrammes multi-protocoles sur un lien point-à-point
        (de nouveau, en général des modems).

        (NDT~: C'est le mode de connexion le plus couramment employé par les
        fournisseurs d'accès Internet. Consultez le <sl>PPP-Howto</>.)

        <tt>slip.c</> - Serial Line Internet Protocol (SLIP, IP sur port série),
        qui permet à deux ordinateurs de s'envoyer des paquets l'un à l'autre
        via leurs ports série (généralement via des modems), en mode
        point-à-point.

        <tt>tunnel.c</> - Fournit un tunnel IP (dit aussi `IP over IP', `IP sur
        IP', NDT) à travers lequel vous pouvez envoyer du trafic réseau de façon
        transparente entre sous-réseaux.

        (NDT~: Pratique pour gérer certains problèmes délicats de politique de
        routage, par exemple.)

        <tt>wavelan.c</> - Un transceiver radio semblable à de l'Ethernet,
        contrôlé par le coprocesseur 82586 d'Intel qui est utilisé sur d'autres
        cartes Ethernet comme l'Intel EtherExpress.


<sect>Câbles, Coaxial, Paire Torsadée<label id="cable">
<p>
        Si vous démarrez un réseau à partir de rien, vous aurez a choisir entre
        l'Ethernet fin (du câble RG-58 co-axial avec des connecteurs BNC) ou le
        10BaseT (des câbles à paire torsadée avec des connecteurs RJ-45
        rectangulaires). Quant au `gros' Ethernet (thick Ethernet), du câble
        RG-5 avec des connecteurs N, tombé en désuétude, on ne le rencontre
        pratiquement plus.

        Référez vous à <ref id="cable-intro" name="Type de cable..."> pour une
        introduction sur les câbles. Notez aussi que la Foire Aux Questions
        (FAQ) du groupe <sl>comp.dcom.lans.ethernet</> contient un tas
        d'informations utiles sur les câbles et tout ce genre de choses. Jetez
        un coup d'oeil à~:

<quote>
        <url url="ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/"
             name="Usenet FAQs">
</quote>

        pour la FAQ de ce groupe de news.

        (NDT~: Le lecteur francophone utilisera bien entendu un site miroir
        comme
        <url url="ftp://ftp.lip6.fr/faq/..." name="URL sur ibp à compléter..">
        ou tout site équivalent proche de chez lui).

<sect1>Ethernet fin (thinnet)<label id="bnc">
<p>
        Le cable Ethernet fin n'est pas cher. Si vous fabriquez vos câbles
        vous-même, le câble RG58A à âme monobrin est à &dollar;0.27/m et le
        câble multibrins RG58AU est à 3,40F/m. (NDT~: Le prix du RG58A est en
        dollar car je n'ai pas pu trouver de prix pour ce type de câble en
        France~!)  Les connecteurs BNC à baïonnette sont à moins de deux dollars
        chacun. (NDT~: A sertir, environ 10 francs pièces, à souder un peu plus
        cher mais vous n'avez pas besoin d'un outil spécial).

        Les autres pièces diverses sont tout aussi bon marché.

        Il est important que vous terminiez chaque extrémité du câble avec un
        `bouchon' de 50~ohms (NDT~: bouchon ou terminateur..), donc prévoyez 70
        francs pour une paire. Il est aussi vital que votre câble ne comporte
        pas de `patte qui pend' -- les connecteurs en `T' doivent être raccordés
        directement aux cartes Ethernet, sans câble entre le `T' et la carte.


        Il y a quelques inconvénients à utiliser l'Ethernet fin. Le premier est
        qu'il est limité a 10~Mbps~--~pour 100~Mbps, il faut de la paire
        torsadée. Le second point noir est que si vous avez un grand nombre de
        machines raccordées entre elles, il suffit qu'un imbécile coupe le
        réseau en débranchant un des câbles qui se trouvent sur les côtés de son
        `T', et tout le réseau se retrouve par terre parce qu'il voit une
        impédance infinie (circuit ouvert) au lieu de la terminaison à 50~ohms
        qui est nécessaire. Notez que vous pouvez enlever la pièce en forme de
        `T' de la carte Ethernet elle-même sans tuer tout le sous-réseau, pour
        autant que vous n'enleviez pas les câbles du `T' lui-même. Bien entendu
        cela perturbera la machine d'où vous venez d'enlever le `T'. 8-) Et
        notez aussi que si vous créez un petit réseau constitué de seulement
        deux machines, vous devez <em>quand même</> mettre en place les `T' et
        les bouchons de 50 ohms. -- vous <em>ne pouvez pas</> juste câbler les
        deux machines entre elles~!

        NDT~: Notez aussi que vous ne devez pas créer une boucle avec le câble
        non plus, en reliant toutes les machines entre elles et en reliant la
        dernière machine avec la première. La présence d'un bouchon de 50 ohms à
        <em>chaque</> extrémité du câble (et il ne doit y avoir que deux
        extrémités 8-) ) est indispensable pour qu'Ethernet fonctionne
        correctement. (Fin de la note)

<!--
        Notez qu'il existe un petit nombre de cartes qui possèdent une
        "terminaison sur la carte". Cela signifie que ces cartes possèdent un
        cavalier qui, quand il est fermé, place une résistance de 50 ohms en
        travers de l'entrée BNC. Avec ces cartes, vous pouvez utiliser un `T'
        BNC et un bouchon comme d'habitude, ou au contraire enficher le câble
        directement dans la carte et fermer le cavalier pour mettre en oeuvre la
        terminaison intégrée à la carte.
-->

        Il existe aussi des systèmes de câblage rigolos qui <em>font comme si</>
        un seul fil arrivait à la carte, mais en fait les deux longueurs de
        câble reposant côte-à-côte, recouvertes par une protection extérieure,
        ce qui donne au fil une section de forme ovale. A l'extrémité de cette
        boucle est inséré un connecteur BNC sur lequel se connecte votre
        carte. Vous avez donc l'équivalent d'un aller-retour de câble et d'un
        `T' BNC, mais avec ce type de câblage, il est impossible pour
        l'utilisateur d'enlever un câble d'un seul côté du `T' et donc de
        perturber le réseau.

        (NDT~: C'est une bonne idée, mais la réalisation du câblage entre les
        prises de raccordement est délicate, et le moindre défaut amplifie
        rapidement les problèmes de l'Ethernet fin. <!-- Pour ceux que cela
        intéresse, lesdits problèmes comprennent entre autres~: les pbs de mise
        à la terre du coax, les problèmes de paradiaphonie et de sensibilité des
        contacts,... Je réfléchis à une liste et je la mets~?? stef--> )



<sect1>Paire torsadée<label id="utp">
<p>
        Les réseaux à paire torsadée nécessitent des hubs actifs, dont les prix
        démarrent aux environ de 300 francs, et le prix du câble brut peut être
        en fait supérieur à celui du Thinnet. Vous devriez ignorer ceux qui
        disent que vous pouvez utiliser votre câblage téléphonique existant, car
        il est rare de trouver une installation où c'est le cas.

        (NdT~: Ca c'est du pessimisme avéré. J'ai déjà fait pire.~:])

<!--
        La prétention que vous pourrez augmenter les vitesses est aussi
        suspecte, car la plupart des méthodes proposées utilisent du câble de
        meilleure qualité (entendez FF++) et des terminaisons plus sophistiquées
        (+++FFFF++) que ce que vous pouvez espérer installer.
-->

        D'un autre côté, les prix des hubs sont en chute libre, toutes les
        propositions Ethernet 100~Mbps utilisent la paire torsadée, et la
        plupart des installations professionnelles neuves utilisent la paire
        torsadée.

        (NDT~: Euh, c'est peut-être aussi parce qu'avec un câblage banalisé on
        peut faire de la voix (entendez~: du téléphone), de la donnée
        (entendez~: du réseau), et de la vidéo, sur le même câble, ce qui coûte
        quand même moins cher que trois câblages différents~!)

        De plus, Russ Nelson ajoute que `Les nouvelles installations devraient
        utiliser du câblage Catégorie 5. Toute autre chose est une perte de
        temps de votre installateur, car le 100Base-ce-que-vous-voulez
        nécessitera du Cat. 5.'

        (NDT~: Pour être précis, c'est du Catégorie 5, Classe D qu'il faut
        exiger. Un pour le type de câble, un pour la plage de fréquence.~:))

        Si vous n'avez que deux machines à raccorder, il est possible d'éviter
        l'utilisation d'un hub, en croisant les paires émissions et réception
        (1-2 et 3-6).

        Si vous tenez le connecteur RJ-45 face à vous (comme si vous alliez le
        brancher dans votre bouche) avec le petit clip de fixation vers le haut,
        alors les broches sont numérotées de 1 à 8 de la gauche vers la
        droite. L'utilisation des broches est la suivante~:

<verb>
        Numéro de broche        Utilisation
        ----------              ----------
        1                       Sortie des Données (+)
        2                       Sortie des Données (-)
        3                       Entrée des Données (+)
        4                       Réservé pour le téléphone
        5                       Réservé pour le téléphone
        6                       Entrée des Données (-)
        7                       Réservé pour le téléphone
        8                       Réservé pour le téléphone
</verb>

        Si vous souhaitez fabriquer un câble, ce qui suit devrait vous fournir
        tous les détails voulus. Les paires de signaux différentiels doivent se
        trouver sur la même paire torsadée afin d'obtenir l'impédance et les
        pertes minimales requises d'un câble UTP. Si vous consultez la table
        ci-dessus, vous constatez que 1+2 et 3+6 sont les ensembles de paires de
        signaux différentiels. Pas 1+3 et 2+6~!!!!!!  A 10~MHz, avec des
        distances courtes, vous échapperez *peut-être* aux conséquences de
        telles erreurs, si c'est vraiment sur une courte distance. Mais n'y
        pensez même pas à 100~MHz.

        Pour un cordon de brassage normal, avec les extrémités `A' et `B', vous
        avez besoin d'un raccordement `droit', broche par broche, l'entrée et la
        sortie utilisant chacune une paire de fils (pour des problèmes
        d'impédance). Cela signifie donc que le 1 de A va au 1 de B, que le 2 de
        A va au 2 de B, que le 3 de A va au 3 de B et que le 6 de A va au 6 de
        B. Les fils qui joignent 1A-1B et 2A-2B doivent être sur la même paire
        torsadée. De même, les fils qui joignent 3A-3B et 6A-6B doivent être sur
        une autre paire torsadée.

        Maintenant, si vous n'avez pas de hub, mais que vous voulez fabriquer un
        `câble null' (ou câble croisé, NDT), ce que vous souhaitez faire est que
        l'entrée de `A' devienne la sortie de `B', et que la sortie de `A'
        devienne l'entrée de `B', sans changer la polarité. Cela signifie donc
        raccorder 1A à 3B (sortie+ de A vers entrée+ de B) et 2A à 6B (sortie-
        de A vers entrée- de B). Ces deux fils doivent être sur une paire
        torsadée. Ils transportent ce que la carte/le connecteur `A' considère
        comme la sortie, et ce qui est vu comme l'entrée par la carte/le
        connecteur `B'. Puis raccordez 3A à 1B (entrée+ de A sur sortie+ de B)
        et 6A à 2B (entrée- de A sur sortie- de B). Ces deux-là aussi doivent
        être sur une paire torsadée. Ils transportent ce que la carte/le
        connecteur `A' considère comme son entrée, et ce que la carte/le
        connecteur `B' considère comme sa sortie.

        Donc, si vous considérez un cordon de brassage normal, enlevez l'une de
        ses extrémités, échangez les emplacements des paires de réception et
        d'émission dans le nouveau connecteur, sertissez-le, et vous avez un
        câble `null' (enfin, croisé, quoi~! NDT). Rien de bien compliqué. Vous
        voulez juste que le signal transmis par une carte soit envoyé sur le
        récepteur de la seconde, et vice versa.

        Notez qu'avant que 10BaseT soit ratifié en tant que norme, il existait
        d'autres formats de réseau qui utilisaient des connecteurs RJ-45, avec
        le même principe de câblage que ci-dessus. Des exemples sont le
        LattisNet de SynOptics et le StarLAN d'AT&amp;T. Dans certains cas
        (comme les premières cartes 3C503) vous pouvez positionner des cavaliers
        pour que la carte puisse dialoguer avec des hubs de différents types,
        mais dans la plupart des cas les cartes conçues pour ces anciens types
        de réseaux ne fonctionneront pas avec un hub/un réseau 10BaseT
        standard. (Notez que si les cartes ont aussi un port AUI, il n'y a
        aucune raison que vous ne puissiez pas l'utiliser, combiné avec un
        transceiver AUI / 10BaseT).


<sect1>Thick Ethernet - Le `gros' Ethernet
<p>
        Le `Thick ethernet' est pratiquement obsolète, et n'est généralement
        utilisé que pour rester compatible avec une implémentation
        existante. Vous pouvez outrepasser les règles et connecter des brins
        courts d'Ethernet fin (ThinNet 10Base2) et épais (ThickNet 10Base5)
        ensemble avec un connecteur passif N-vers-BNC à 15 francs, et c'est
        souvent la meilleure solution pour étendre un réseau ThickNet
        existant. Une solution correcte (mais plus chère) est d'utiliser un
        répéteur dans ce cas.
</sect>

<sect>Configuration logicielle et diagnostics de carte<label id="utils">
<p>
        Dans la plupart des cas, si la configuration est faite par logiciel, et
        stockée dans une EEPROM, vous devrez démarrer DOS, et utiliser le
        programme DOS fourni par le constructeur pour configurer l'IRQ, les
        ports d'E/S, l'adresse mémoire et autres choses sur la carte. Du reste,
        on peut espérer que c'est quelque chose que vous ne configurerez qu'une
        seule fois. Si vous ne disposez pas du logiciel DOS pour votre carte,
        essayez de chercher sur le site WWW du constructeur de votre carte. Si
        vous ne connaissez pas le nom du site, tentez de le deviner, par exemple
        `www.mon-constructeur.com' où `mon-constructeur' est le nom du fabricant
        de la carte. Cela fonctionne pour SMC, 3Com, et plein <em>plein</>
        d'autres fabricants.

        On trouve certaines cartes pour lesquelles des versions Linux des
        utilitaires de configuration existent, et elles sont listées ici. Donald
        a écrit quelques petits programmes de diagnostic qui fonctionnent sous
        Linux. La plupart d'entre eux sont le résultat d'outils de débogage
        qu'il a créés pendant l'écriture des divers pilotes. Ne vous attendez
        pas à des interfaces rigolotes avec des menus. Vous aurez besoin de lire
        le code-source pour utiliser la plupart d'entre eux. Même si votre carte
        n'a pas de programme de configuration correspondant, vous pouvez encore
        obtenir un peu d'information juste en tapant <tt>cat /proc/net/dev</tt>
        --~à condition que votre carte ait été au moins détectée au démarrage.

        Dans tous les cas, vous devrez exécuter la plupart de ces programmes en
        tant que root (pour permettre l'accès aux ports d'E/S) et vous devrez
        certainement désactiver la carte réseau avant en tapant <tt>ifconfig
        eth0 down</> en premier.

<sect1>Programmes de configuration pour cartes Ethernet<label id="config">
<p>

<sect2>Cartes WD80x3
<p>
        Pour ceux d'entre vous qui ont des cartes wd80x3, il existe le programme
        <tt>wdsetup</> qui peut être trouvé dans <tt>wdsetup-0.6a.tar.gz</> sur
        les sites FTP linux. il n'est pas activement maintenu, et n'a pas été
        mis à jour depuis déjà pas mal de temps. S'il fonctionne correctement
        pour vous, c'est parfait, sinon, utilisez la version DOS que vous
        devriez avoir obtenue avec votre carte. Si vous n'avez pas la version
        DOS, vous serez heureux d'apprendre que les disquettes de configuration
        et les pilotes SMC sont disponibles sur le site FTP de SMC.

        Bien entendu, vous <em>devez</> avoir une carte avec EEPROM pour
        utiliser cet utilitaire. Les vieilles, <em>vieilles</> cartes wd8003, et
        certains clones de wd8013 utilisent à la place des cavaliers pour
        configurer la carte.

<sect2>Cartes Digital / DEC
<p>
        La carte EtherWorks 3 de Digital peut être configurée d'une façon
        similaire au programme DOS <tt>NICSETUP.EXE</>. David C. Davies l'a
        écrit, ainsi que certains autres outils pour l'EtherWorks 3, en
        conjonction avec le pilote. Regardez sur <tt>metalab.unc.edu</> dans le
        répertoire <tt>/pub/linux/system/Network/management</tt> un fichier qui
        s'appelle <tt>ewrk3tools-X.XX.tar.gz</>.

        (NDT~: Le lecteur français aura tout intérêt à utiliser un site FTP plus
        proche, comme par exemple~:
        <tt>ftp://ftp.lip6.fr/pub/linux/sunsite/system/Network/management</tt>)

<sect2>Cartes NE2000+ ou AT/LANTIC
<p>
        Certaines implémentations de la puce DP83905 de National Semiconductor
        (comme l'AT/LANTIC et la NE2000+) peuvent être configurées par
        logiciel. (Notez que ces cartes peuvent aussi émuler une carte wd8013~!)
        Vous pouvez récupérer le fichier <tt>/pub/linux/setup/atlantic.c</tt>
        sur le serveur FTP de Donald, <tt>cesdis.gsfc.nasa.gov</>, pour
        configurer cette carte. De plus, les programmes de configuration pour
        les cartes DP83905 de Kingston semblent fonctionner avec toutes les
        cartes, car ils ne vérifient pas une adresse spécifique au constructeur
        avant de vous autoriser à les utiliser. Suivez l'URL que voici~:

<quote>
        <url url="http://www.kingston.com/download/etherx/etherx.htm"
             name="Logiciel Kingston">
</quote>
        et récupérez <tt>20XX12.EXE</> et <tt>INFOSET.EXE</>.

        Soyez attentif en configurant des cartes NE2000+, car vous pouvez leur
        fournir des valeurs de paramètrage erronées qui causeront des
        problèmes. Un exemple classique est d'activer accidentellement la ROM de
        démarrage dans l'EEPROM (même si aucune ROM n'est installée) et de
        fournir une valeur qui entre en conflit avec la carte VGA. Le résultat
        est un ordinateur qui se contente de vous envoyer des `bip' quand vous
        l'allumez et où rien n'apparaît à l'écran.

        Vous pouvez typiquement vous sortir de ce mauvais pas en faisant ce qui
        suit~:

        Enlevez la carte de la machine, redémarrez et entrez dans la
        configuration CMOS. Changez le paramètre `Display Adapter' (carte vidéo)
        en `Not Installed' (pas de carte vidéo) et changez le disque de
        démarrage par défaut (`Default Boot Drive' ou `Boot Sequence', NDT) en
        `A:' (votre lecteur de disquette). Changez aussi le paramètre `Wait for
        F1 if any Error' (attendre un appui sur F1 en cas d'erreur) en
        `Disabled' (désactivé). De cette façon, l'ordinateur devrait démarrer
        sans intervention de l'utilisateur. Maintenant créez une disquette DOS
        de démarrage (`format a: /s /u') et copiez le programme
        <tt>default.exe</> de l'archive <tt>20XX12.EXE</> sur cette
        disquette. Puis tapez <tt>echo default > a:autoexec.bat</tt> afin que le
        programme qui remet la carte à des valeurs par défaut cohérentes soit
        exécuté automatiquement quand vous démarrez sur cette disquette.
        Eteignez la machine, réinstallez la carte ne2000+, insérez votre
        nouvelle disquette de démarrage, et rallumez la machine. Elle devrait
        certainement vous bipper de nouveau à la figure, mais vous devriez voir
        la lumière du lecteur de disquette s'allumer pendant qu'elle démarre à
        partir de la disquette. Attendez une minute ou deux que le lecteur de
        disquette s'arrête, indiquant ainsi que la machine a fini d'exécuter le
        programme <tt>default.exe</>, puis éteignez votre ordinateur. Lorsque
        vous le rallumez, vous pouvez espérer avoir un écran qui fonctionne de
        nouveau, ce qui vous permet de remettre les paramètres CMOS à leurs
        anciennes valeurs, et de changer de nouveau les paramètres de l'EEPROM
        de la carte pour les valeurs que vous voulez.

        Notez que si vous n'avez pas de DOS sous la main, vous pouvez utiliser
        la méthode ci-dessus avec un disque de démarrage Linux qui exécute
        automatiquement le programme <tt>atlantic</> de Donald (avec les bonnes
        options sur la ligne de commande) au lieu d'une disquette de démarrage
        DOS qui exécute automatiquement le programme <tt>default.exe</>.

<sect2>Cartes 3Com
<p>
        La famille des cartes Etherlink III de 3Com (c'est-à-dire les 3c5x9)
        peut être configurée en utilisant un autre utilitaire de configuration
        de Donald. Vous pouvez obtenir le fichier
        <tt>/pub/linux/setup/3c5x9setup.c</tt> sur le serveur FTP de Donald,
        <tt>cesdis.gsfc.nasa.gov</>, afin de configurer ces cartes. (Notez que
        l'utilitaire de configuration DOS 3c5x9B peut comprendre plus d'options
        se rapportant aux nouvelles séries ``B'' de la famille Etherlink III).


<sect1>Programmes de diagnostic pour cartes Ethernet<label id="diag">
<p>
        Tous les programmes de diagnostic que Donald a écrit peuvent être
        obtenus à partir de cette URL.

<quote>
        <url url="ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/index.html"
             name="Diagnostics pour cartes Ethernet">
</quote>

        Allied Telesis AT1700 -- cherchez le fichier
        <tt>/pub/linux/diag/at1700.c</tt> sur <tt>cesdis.gsfc.nasa.gov</>.

        Cabletron E21XX -- cherchez le fichier <tt>/pub/linux/diag/e21.c</tt>
        sur <tt>cesdis.gsfc.nasa.gov</>.

        HP PCLAN+ -- cherchez le fichier <tt>/pub/linux/diag/hp+.c</tt> sur
        <tt>cesdis.gsfc.nasa.gov</>.

        Intel EtherExpress -- cherchez le fichier
        <tt>/pub/linux/diag/eexpress.c</tt> sur <tt>cesdis.gsfc.nasa.gov</>.

        Cartes NE2000 -- cherchez le fichier <tt>/pub/linux/diag/ne2k.c</tt> sur
        <tt>cesdis.gsfc.nasa.gov</>. Il existe aussi une version~PCI pour les
        clones NE2000-PCI qui sont maintenant classiques.

        Adaptateur de poche RealTek (ATP) -- cherchez le fichier
        <tt>/pub/linux/diag/atp-diag.c</tt> sur <tt>cesdis.gsfc.nasa.gov</>.

        Toutes les autres cartes -- essayez de taper <tt>cat /proc/net/dev</tt>
        et <tt>dmesg</> pour savoir quelles informations utiles le noyau possède
        sur la carte en question.


<sect>Informations Techniques<label id="tech-intro">
<p>
        Pour ceux d'entre vous qui souhaitent comprendre comment marche la
        carte, ou jouer avec les pilotes actuels, ou même essayer de faire leur
        propre pilote pour une carte qui n'est actuellement pas supportée, ces
        informations peuvent se révéler utiles. Si vous n'entrez pas dans cette
        catégorie de personne, vous devriez peut-être sauter cette section.

<sect1>Entrées/Sorties programmées contre mémoire partagée contre DMA
       <label id="data-xfer">
<p>
        Si vous savez déjà envoyer et recevoir des paquets les uns derrière les
        autres, vous ne pouvez tout simplement pas mettre plus de bits sur le
        fil. Toutes les cartes Ethernet modernes peuvent recevoir des paquets
        les uns à la suite des autres. Les pilotes Linux DP8390 (wd80x3,
        SMC-ULTRA, 3c503, ne2000, etc) s'approchent très près de l'envoi de
        paquets les uns derrière les autres (cela dépendra du temps de latence
        d'interruption courant), et la 3c509 ou l'AT1500 n'ont absolument aucun
        problème pour émettre des paquets les uns derrière les autres.

        Le bus~ISA peut faire du~5,3~Mo/s (42~Mbit/s), ce qui semble plus que
        nécessaire pour l'ethernet a 10~Mbps. En cas d'utilisations de cartes
        100~Mbps, il est clair que vous aurez à utiliser un bus plus rapide pour
        utiliser toute la bande passante.

<sect2>Entrées/Sorties (E/S) programmées (NE2000, 3c509, etc.)
<p>
        <bf>Pour~:</> N'utilise aucune ressource système contrainte, juste
        quelques registres d'E/S, et n'a pas de limite à 16~M.

        <bf>Contre~:</> Généralement le taux de transfert le plus faible, le
        processeur attend tout le temps, et un accès entrelacé
        (<sl>interleaved</> en anglais) aux paquets est habituellement difficile
        voire impossible.

<sect2>Mémoire partagée (WD80x3, SMC-Ultra, 3c503, etc.)
<p>
        <bf>Pour~:</> Simple, plus rapide que les E/S programmées, permet
        l'accès aléatoire aux paquets. Les pilotes Linux calculent la somme de
        contrôle (<sl>checksum</> en anglais) des paquets IP entrants lorsqu'ils
        sont copiés depuis la carte, ce qui entraîne une réduction
        supplémentaire de la charge du processeur par rapport à une carte
        équivalente en E/S programmées.

        <bf>Contre~:</> Utilise beaucoup d'espace mémoire (c'est important pour
        les utilisateur sous DOS, cela n'a pratiquement pas d'importance sous
        Linux), et charge encore le processeur.

<sect2>Accès Direct à la Mémoire (DMA) Esclave (normal) (p.ex.~: aucune pour
Linux~!)
<p>
        <bf>Pour~:</> Libère le processeur pendant le transfert réel des
        données.

        <bf>Contre~:</> La vérification des conditions aux limites de blocs,
        l'allocation de tampons (<sl>buffers</> en anglais) contigus, et la
        programmation des registres DMA en font la plus lente de toutes les
        techniques. Elle utilise en plus un canal~DMA (une ressource rare~!) et
        nécessite des tampons alignés en mémoire basse.

<sect2>DMA en Bus Master (p.ex.~: LANCE, DEC 21040) <label id="master">
<p>
        <bf>Pour~:</> Libère le processeur pendant le transfert des données,
        peut lier des tampons entre eux, peut nécessiter peu voire pas de perte
        de temps processeur sur le bus ISA. La majorité des pilotes
        bus-mastering pour linux utilisent un schéma 'copybreak' où les gros
        paquets sont directements placés dans les tampons réseau du noyau par la
        carte, les petits paquets étant copiés par le CPU qui est plus rapide
        pour ce type de traitements.

        <bf>Contre~:</> (seulement pour les cartes ISA) Nécessite des tampons en
        mémoire basse et un canal~DMA pour les cartes. Tout Maître de Bus aura
        des problèmes avec les autres Maîtres de Bus qui sont des goinfres,
        comme certaines cartes~SCSI primitives. Quelques jeux de puces pour
        cartes-mères mal pensés ont des problèmes avec les maîtres de bus. Et
        une raison pour n'avoir <em>aucun</> type de périphérique~DMA est
        d'utiliser un processeur~486 conçu pour être inséré (ou monté) en lieu
        et place d'un 386: ces processeurs doivent vider leur cache à chaque
        cycle DMA. (Ceci inclus les Cx486DLC, Ti486DLC, Cx486SLC, Ti486SLC,
        etc.)

<!--

L'ISA se meurt, a supprimer bientôt.

<sect1>Adresses testées
<p>
        Lors des essais réalisés afin de déterminer quelle carte Ethernet est
        présente, les adresses suivantes sont automatiquement testées, en
        considérant que le type de la carte n'a pas été spécifié dans le
        noyau. Les noms de fichier qui suivent se trouvent dans
        <tt>/usr/src/linux/drivers/net/</tt>.

<code>
        3c501.c:        0x280, 0x300
        3c503.c:        0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2a0, 0x2e0
        3c505.c:        0x300, 0x280, 0x310
        3c507.c:        0x300, 0x320, 0x340, 0x280
        3c509.c:        port d'identification spécial
        apricot.c:      0x300
        at1700.c:       0x300, 0x280, 0x380, 0x320, 0x340, 0x260, 0x2a0, 0x240
        atp.c:          0x378, 0x278, 0x3bc
        depca.c         0x300, 0x200
        de600.c:        0x378
        de620.c:        0x378
        eexpress.c:     0x300, 0x270, 0x320, 0x340
        hp.c:           0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240
        hp-plus.c       0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340
        lance.c:        0x300, 0x320, 0x340, 0x360
        ne.c:           0x300, 0x280, 0x320, 0x340, 0x360
        ni52.c:         0x300, 0x280, 0x360, 0x320, 0x340
        ni65.c:         0x300, 0x320, 0x340, 0x360
        smc-ultra.c:    0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380
        wd.c:           0x300, 0x280, 0x380, 0x240
</code>

        Il existe certaines cartes Ethernet, clones de la NE2000, qui sont des
        trous noirs attendant les pilotes qui font des détections
        automatiques. Alors que de nombreux clones NE2000 sont sûrs jusqu'au
        moment où ils sont activés, certains ne peuvent pas être réinitialisés
        dans un état sûr. Ces cartes Ethernet dangereuses bloqueront tout accès
        d'E/S sur leurs `ports de données'. Les endroits typiquement dangereux
        sont:
<code>
        Adresse de base configurée    Endroits dangereux
        par cavalier sur la carte     (adresse de base + 0x10 - 0x1f)
                0x300 *                         0x310-0x317
                0x320                           0x330-0x337
                0x340                           0x350-0x357
                0x360                           0x370-0x377
</code>

        * L'adresse <tt>0x300</> est l'endroit traditionnel où placer une carte
          Ethernet, mais c'est aussi un endroit populaire où mettre d'autres
          périphériques (souvent des contrôleurs SCSI). L'adresse <tt>0x320</>
          est souvent celle choisie ensuite, mais c'est mauvais pour la
          procédure de détection de l'AHA1542. L'adresse <tt>0x360</> est
          mauvaise, parce qu'elle est en conflit avec le port parallèle qui se
          trouve en <tt>0x378</>. Si vous avez deux contrôleurs IDE, ou deux
          contrôleurs de disquettes, alors <tt>0x360</> est aussi un mauvais
          choix, car une carte NE2000 les démolira aussi.

        Notez que les noyaux &gt; 1.1.7x conservent un log de qui utilise quels
        ports d'E/S, et ne laisseront pas un pilote utiliser des ports d'E/S
        précédemment enregistrés par un autre pilote. Il peut en résulter que
        des procédures de détection échoueront sans rien dire. Vous pouvez voir
        qui utilise quels ports d'E/S en tapant <tt>cat /proc/ioports</tt> si
        vous avez activé le système de fichier <tt>proc</>.

        Pour éviter ces cartes Ethernet menaçantes, voici ce que vous pouvez
        faire~:

<itemize>

<item> Testez le BIOS du périphérique dans l'espace mémoire. C'est simple et
       toujours sûr, mais cela ne fonctionne que pour des cartes qui ont
       toujours des BIOS, comme les contrôleurs SCSI primaires.

<item> Evitez de tester l'un des emplacements ci-dessus jusqu'à ce que vous
       pensiez avoir trouvé votre périphérique. Les clones NE2000 ont un
       intervalle de redémarrage de &lt;base&gt;+0x18 à &lt;base&gt;+0x1f qui
       donnera 0xff en lecture, donc commencez par lire là en premier si c'est
       possible. Vous pouvez aussi tester de façon sûre dans l'espace de la 8390
       aux adresses &lt;base&gt;+0x00 - &lt;base&gt;+0x0f, mais cet espace vous
       renverra des valeurs quasi-aléatoires.

<item> Si vous devez tester dans l'intervalle dangereux, par exemple si le
       périphérique pour lequel vous programmez n'a que peu d'emplacements de
       ports, commencez par vérifier qu'il n'y a pas une NE2000 à cet
       endroit-là. Vous pouvez voir comment faire en regardant le code de
       détection dans <tt>/usr/src/linux/net/inet/ne.c</tt>.

<item> Utilisez l'argument de démarrage `reserve' pour protéger des zones
       sensibles des procédures de détection. Lisez les informations sur
       l'utilisation des arguments au moment du démarrage avec LILO dans~<ref
       id="reserve" name="La commande `reserve'">.

</itemize>

-->

<sect1>Écriture d'un pilote de carte<label id="skel">
<p>
        La seule chose indispensable pour utiliser une carte Ethernet sous Linux
        est le pilote approprié. Pour que cela soit possible, il est essentiel
        que le constructeur diffuse les informations techniques nécessaires à la
        programmation de ce pilote à destination du public sans que vous (ou
        quelqu'un d'autre) ne soyez obligé de leur vendre votre âme. Une bonne
        indication des chances d'obtenir de la documentation (ou, si vous ne
        programmez pas, des chances que quelqu'un d'autre puisse écrire ce
        pilote dont vous avez vraiment, vraiment besoin) est la disponibilité du
        pilote en mode paquet de Crynwr (ex Clarkson). Russ Nelson dirige cette
        opération, et il a été d'un grand service par son aide au cours du
        développement de certains pilotes pour Linux. Vous pouvez essayer cette
        URL pour consulter le programme de Russ~:

<quote>
        <url url="http://www.crynwr.com/crynwr/home.html"
             name="Pilote en mode paquet de Russ Nelson">
</quote>

        Une fois la documentation obtenue, vous pouvez écrire un pilote pour
        votre carte et l'utiliser sous Linux (du moins en théorie).
        Rappelez-vous néanmoins que certains matériels anciens qui ont été créés
        pour des machines XT ne fonctionneront pas bien dans un environnement
        multitâches comme Linux. Leur utilisation entraînera des problèmes
        importants si votre réseau est raisonnablement chargé.

        La plupart des cartes possèdent des pilotes pour des interfaces MS-DOS
        comme NDIS ou ODI, mais ceux-ci sont inutiles pour Linux. De nombreuses
        personnes ont suggéré de les intégrer directement ou de réaliser une
        traduction automatique, mais c'est quasiment impossible. Les pilotes
        MS-DOS s'attendent à travailler en mode 16~bits et à utiliser des
        `interruptions logicielles', deux notions incompatibles avec le noyau
        Linux. Cette incompatibilité est en fait un avantage, puisque certains
        pilotes pour Linux sont considérablement meilleurs que leur équivalent
        MS-DOS. Par exemple, la série des pilotes `8390' utilise des zones
        tampon de transmissions en ping-pong, qui commencent seulement à
        apparaître dans le monde MS-DOS.

        (`Des zones tampon de transmissions en ping-pong' signifie que l'on
        utilise au moins deux zones de la taille maximale d'un paquet pour
        transmettre les paquets. L'une des zones est chargée pendant que la
        carte est en train de transmettre l'autre. Le deuxième paquet est alors
        transmis dès que le premier est parti, etc. De cette manière, la plupart
        des cartes sont capables d'envoyer des paquets à la dos à dos sur le
        câble).

        Bon. Vous avez donc décidé d'écrire un pilote pour la carte Ethernet
        Machin, puisque vous avez les informations nécessaires à sa
        programmation, et que personne d'autre ne l'a encore fait (... ce sont
        les deux conditions principales <tt>;-)</> ). Vous devriez commencer
        avec le squelette du pilote réseau qui est fourni avec la distribution
        source du noyau Linux. Il se trouve dans le fichier
        /usr/src/linux/drivers/net/skeleton.c dans tous les noyaux récents.
        Jetez aussi un coup d'oeil sur le `Kernel Hackers Guide' à l'URL
        suivante~:

<quote>
        <url url="http://www.redhat.com:8080/HyperNews/get/khg.html"
             name="KHG">
</quote>

<sect1>Inteface du pilote avec le noyau
<p>
        Voici quelques notes sur les fonctions que vous devrez écrire si vous
        créez un nouveau pilote. Lisez-les en gardant sous la main le squelette
        de pilote décrit ci-dessus~: cela simplifiera les choses.

<sect2>Détection de la carte (Probe)
<p>
        Appelée au démarrage pour vérifier l'existence de la carte. Meilleure si
        elle peut vérifier en douceur en lisant la mémoire etc. Peut aussi lire
        les ports d'E/S. Ecrire au démarrage sur les ports d'E/S pour détecter
        la carte n'est <em>pas bien</> parce que cela risque de tuer un autre
        périphérique. Certaines parties de l'initialisation du périphérique sont
        habituellement faites à ce niveau (allouer l'espace d'E/S, les IRQ,
        remplir les champs de <tt>dev-&gt;???</>, etc.)  Vous avez besoin de
        savoir à quels ports d'E/S et à quelles zones mémoire la carte peut être
        configurée, comment autoriser l'utilisation de mémoire partagée (si
        besoin), comment sélectionner et mettre en oeuvre la génération
        d'interruptions, etc.

<sect2>Gestionnaire d'interruptions (Interrupt handler)
<p>
        Appelé par le noyau quand la carte déclenche une interruption. A la
        responsabilité de déterminer pourquoi la carte a déclenché
        l'interruption, et d'agir en conséquence. Les conditions habituelles
        d'interruption sont l'arrivée de données, la fin d'une transmission,
        l'indication de conditions d'erreur. Vous avez besoin de connaître les
        bits d'informations liés à une interruption afin de pouvoir agir en
        conséquence.


<sect2>Fonction de transmission (Transmit function)
<p>
        Est liée à <tt>dev-&gt;hard_start_xmit()</> et est appelée par le noyau
        quand ce dernier désire envoyer des données par l'intermédiaire du
        périphérique. Envoie les données sur la carte et déclenche la
        transmission. Vous avez besoin de savoir comment empaqueter les données
        et comment les faire parvenir sur la carte (copie en mémoire partagée,
        transfert sur les ports d'E/S, DMA~?) et au bon endroit sur la carte.
        Puis vous devez savoir comment dire à la carte d'envoyer les données sur
        le câble, et (éventuellement) émettre une interruption quand ce sera
        fini. Quand le périphérique ne peut plus accepter de paquets
        supplémentaires, il doit armer le drapeau <tt>dev-&gt;tbusy</>. Quand de
        la place est devenue disponible, en général au cours d'une interruption
        de fin de transmission, <tt>dev-&gt;tbusy</> doit être désarmé et les
        niveaux supérieurs doivent être informés en utilisant
        <tt>mark_bh(INET_BH)</>.


<sect2>Fonction de réception (Receive function)
<p>
        Appelée par le gestionnaire d'interruptions du noyau quand la carte
        indique que des données sont disponibles. Récupère les données de la
        carte, les empaquette dans un sk_buff et informe le noyau de la présence
        des données en effectuant un <tt>netif_rx(sk_buff)</>. Vouz devez savoir
        comment mettre en oeuvre le déclenchement d'interruptions à la réception
        de données, comment vérifier les bits d'informations correspondant à la
        réception, et comment récupérer les données depuis la carte (là encore,
        par mémoire partagée, ports d'E/S, DMA, etc.)

<sect2>Fonction d'ouverture (Open function)
<p>
        Est liée à <tt>dev-&gt;open</>. Est appelée par les couches réseau quand
        quelqu'un fait <tt>ifconfig eth0 up</> - cela doit mettre le
        périphérique en route et l'autoriser à recevoir et transmettre des
        données. Toute incantation spéciale liée à l'initialisation et qui
        n'aurait pas été réalisée dans la séquence de détection (autoriser la
        génération d'IRQ, etc.) trouvera sa place ici.


<sect2>Fonction de fermeture (facultative) (Close function)
<p>
        Met la carte dans un état propre quand quelqu'un effectue <tt>ifconfig
        eth0 down</>. Doit libérer les IRQ et les canaux DMA si le matériel le
        permet, et éteindre tout ce qui pourrait économiser de l'énergie (comme
        le transmetteur).

<sect2>Autres fonctions
<p>
        Des éléments comme une fonction de réinitialisation, afin que, si les
        choses se dégradent, le pilote puisse essayer de réinitialiser la carte
        en dernier recours. Généralement fait quand une transmission dépasse son
        temps maximal ou quelque chose du genre. Ou encore une fonction pour
        lire les registres qui contiennent les statistiques sur la carte, si
        elle en comporte.

<sect1>Informations techniques de 3Com<label id="3com-tech">
<p>
        Si vous êtes intéressé(e) par l'écriture de pilotes pour les cartes
        3Com, vous pouvez obtenir de la documentation technique de 3Com.
        Cameron a été suffisamment gentil pour nous dire comment y parvenir~:

        Les adaptateurs Ethernet de 3Com sont documentés pour les auteurs de
        pilotes dans nos `Références Techniques' (Technical References,
        TRs). Ces manuels décrivent les interfaces du programmeur avec la carte,
        mais elles ne parlent pas des diagnostics, des programmes
        d'installation, etc., que l'utilisateur final peut voir.

        Le département marketing de la Division Adaptateurs Réseaux (Network
        Adapter Division) est responsable de la diffusion des TRs. Pour que ce
        programme reste efficace, nous le centralisons dans une entité appelée
        `CardFacts'. C'est est un système téléphonique automatisé. Vous
        l'appelez avec un téléphone à fréquences vocales et il vous envoie des
        choses par télécopie. Pour obtenir un TR, appelez CardFacts au
        408-727-7021.

        (NDT~: Cela ne fonctionne qu'aux Etats-Unis.)  Demandez le formulaire de
        commande du développeur (Developer's Order Form), le document numéro
        9070. Ayez votre numéro de fax sous la main lorsque vous
        appelez. Complétez le formulaire de commande et envoyez-le par télécopie
        au 408-764-5004. Les manuels sont expédiés par le service J+2 de Federal
        Express.

        Il y a des gens ici qui pensent que nous sommes trop libéraux avec les
        manuels, et qui cherchent des preuves que le système est trop onéreux,
        ou prend trop de temps et d'effort. Jusqu'à présent, les clients de 3Com
        ont été très bien sur ce point, et il n'y a pas de problème avec le
        niveau de demandes que nous avons obtenu. Nous avons besoin que votre
        coopération et votre retenue se maintiennent pour continuer ainsi.

<sect1>Notes sur les cartes basées sur la puce PCnet / LANCE d'AMD
       <label id="amd-notes">
<p>
        La puce LANCE (Local Area Network Controller for Ethernet, Contrôleur de
        Réseau Local pour Ethernet) d'AMD constituait l'offre initiale, et a
        depuis été remplacée par la puce `PCnet-ISA', aussi connue en tant que
        79C960. Notez que le nom `LANCE' est resté, et certaines personnes se
        réfèrent à la nouvelle puce en utilisant l'ancien nom. Dave Roberts de
        la Division des Produits Réseaux (Network Products Division) d'AMD a eu
        l'amabilité de nous fournir les informations suivantes concernant cette
        puce~:

        `Fonctionnellement, elle est équivalente à une NE1500. Le jeu de
        registres est identique à celui de la vieille LANCE avec les additions
        de l'architecture 1500/2100. Les vieux pilotes 1500/2500 fonctionneront
        avec la PCnet-ISA. L'architecture NE1500 et NE2100 est la même à la
        base. Initialement Novell l'a appelé la 2100, mais ensuite a essayé de
        distinguer entre cartes coax et 10Base-T. Tout ce qui était purement
        10Base-T devait être numéroté dans la série 1500. C'est la seule
        différence.

        De nombreuses sociétés offrent des produits basés sur la PCnet-ISA, y
        compris HP, Racal-Datacom, Allied Telesis, Boca Research, Kingston
        Technology, etc. Les cartes sont à la base les mêmes, excepté que
        certains constructeurs ont ajouté des fonctionnalités `sans-cavaliers'
        (`jumperless') qui permettent à la carte d'être configurée par
        logiciel. La plupart n'en ont pas. AMD offre un paquetage de conception
        standard pour une carte qui utilise la PCnet-ISA et de nombreux
        fabricants utilisent notre conception sans changement. Cela signifie que
        n'importe qui souhaitant écrire des pilotes pour la plupart des cartes
        basées sur la puce PCnet-ISA peut se contenter d'obtenir la
        documentation technique auprès d'AMD. Appelez notre centre de
        distribution documentaire au (800)222-9323 et demandez la documentation
        de l'Am79C960, PCnet-ISA. Elle est gratuite.

        Un moyen rapide pour savoir si la carte est une carte `générique' est
        simplement de la regarder. Si elle l'est, elle doit juste comporter une
        grosse puce, un quartz, une petite PROM d'adresse IEEE, éventuellement
        un support pour une ROM de démarrage, et un connecteur (1, 2 ou 3, selon
        les options de média offertes). Notez que s'il s'agit d'une carte coax,
        elle comportera aussi quelques composants pour le transceiver, mais ils
        devraient être près du connecteur et éloignés de la PCnet-ISA.'

        Une note pour les bidouilleurs potentiels de cartes est que différentes
        implémentations de la LANCE effectuent le `redémarrage' de différentes
        façons. Certaines reprennent où elles s'étaient arrêtées dans l'anneau,
        et d'autres démarrent directement au début de l'anneau, comme si elles
        venaient d'être initialisées.

<sect1>Multicast et Mode `Promiscuous'<label id="promisc">
<p>
        Une des autres choses sur lesquels Donald a travaillé est
        l'implémentation des points d'entrée pour le multicast et le mode
        `promiscuous'. Tous les pilotes ISA <em>publiés</> (c'est-à-dire
        <bf>pas</> les pilotes au stade `alpha') supportent aujourd'hui le mode
        promiscuous.

        Donald écrit~: Je commencerai par parler du mode `promiscuous', qui est
        conceptuellement facile à implémenter. Pour la plupart des matériels,
        vous n'avez qu'à positionner un bit de registre, et à partir de ce
        moment-là vous obtenez tous les paquets qui passent sur le fil. Bon, ce
        n'est pas vraiment aussi simple que cela~; pour certains matériels, vous
        devez arrêter la carte (en perdant potentiellement quelques paquets), la
        reconfigurer, puis la réactiver. Ok, ça c'est facile, donc je passe à
        quelque chose qui n'est pas aussi évident~: le <sl>multicast</>. On peut
        le réaliser de deux façons~:

<enum>

<item> Utiliser le mode promiscuous, et un filtre de paquets comme celui de
       Berkeley (Berkeley packet filter, BPF). Le BPF est un langage à pile de
       comparaison de modèles (pattern matching stack), avec lequel vous écrivez
       un programme qui extrait les adresses qui vous intéressent. Son avantage
       est qu'il est très général et programmable. Son inconvénient est qu'il
       n'existe pas de moyen général pour le noyau d'éviter d'avoir à mettre en
       route le mode promiscuous et de passer chaque paquet qui circule sur le
       fil à travers tous les filtres de paquets qui se sont
       enregistrés. Consultez~<ref id="bpf" name="Le Berkeley Packet Filter">
       pour plus d'informations.

<item> Utiliser le filtre multicast que la plupart des puces Ethernet possèdent.

</enum>

        Je crois que je devrais donner une liste de ce que quelques cartes ou
        puces Ethernet fournissent~:

<verb>

        Puce/carte  Promiscuous  Filtre Multicast
        -----------------------------------------
        Seeq8001/3c501  Oui     Filtre binaire (1)
        3Com/3c509      Oui     Filtre binaire (1)
        8390            Oui     Hashage à six bits Autodin II (2) (3)
        LANCE           Oui     Hashage à six bits Autodin II (2) (3)
        i82586          Oui     Hashage à six bits Autodin II caché (2) (4)

</verb>

<enum>

<item> Ces cartes prétendent avoir un filtre, mais il s'agit d'un simple oui/non
       `accepte tous les paquets multicast', ou `n'accepte aucun paquet
       multicast'.

<item> AUTODIN II est le polynôme standard de contrôle Ethernet (somme de
       contrôle/checksum CRC). Dans ce principe, les adresses multicast sont
       hashées et recherchées dans une table de hashage. Si le bit correspondant
       est activé, ce paquet est accepté. Les paquets Ethernet sont conçus de
       telle façon que la partie matérielle pour réaliser ceci est triviale --
       vous mémorisez juste (habituellement) six bits du circuit CRC (qui est
       nécessaire de toute façon pour la vérification d'erreur) après les six
       premiers octets (l'adresse de destination), et vous les utilisez comme
       index dans la table de hashage (six bits -- une table de 64-bits).

<item> Ces puces utilisent le hashage à six bits, et nécessitent que la table
       soit calculée et chargée par l'hôte. Cela signifie que le noyau doit
       comprendre le code pour le CRC.

<item> Le 82586 utilise le hashage à six bits de façon interne, mais il calcule
       la table de hashage lui-même à partir d'une liste d'adresses multicast à
       accepter.

</enum>

        Notez qu'aucune de ces puces ne réalise un filtrage parfait, et nous
        avons encore besoin d'un module de niveau intermédiaire pour réaliser le
        filtrage final. Notez aussi que dans chaque cas nous devons conserver
        une liste complète des adresses multicast acceptées pour recalculer la
        table de hashage quand elle change.

<sect1>Le filtre de paquets de Berkeley (Berkeley Packet Filter -- BPF)
      <label id="bpf">
<p>
        L'idée générale des développeurs est que la fonctionnalité du BPF ne
        doit pas être fournie par le noyau, mais doit se trouver dans une
        bibliothèque de compatibilité (dont on espère qu'elle servira peu).

        Pour ceux qui ne seraient pas au courant~: BPF (le Berkeley Packet
        Filter) est un mécanisme destiné à spécifier aux couches réseau du noyau
        quels paquets vous intéressent. Il est implémenté sous la forme d'un
        interpréteur d'un langage à pile spécialisé construit dans un niveau bas
        du code réseau. Une application passe un programme écrit dans ce langage
        au noyau, et le noyau exécute le programme sur chaque paquet entrant. Si
        le noyau possède plusieurs applications BPF, chaque programme est
        exécuté sur chaque paquet.

        Le problème est qu'il est difficile de déduire quel type de paquet
        intéresse réellement l'application à partir du programme de filtrage,
        donc la solution est de toujours exécuter le filtre. Imaginez un
        programme qui enregistre un programme BPF pour extraire un flux de
        données de faible débit envoyé à une adresse multicast. La plupart des
        cartes Ethernet possèdent un filtre d'adresses multicast implémenté sous
        la forme d'une table de hashage à 64 entrées qui ignore la plupart des
        paquets multicast non souhaités, donc les capacités existent pour faire
        de cette opération une opération peu coûteuse en ressources. Mais avec
        le BPF, le noyau doit passer l'interface en mode promiscuous, recevoir
        <bf>tous</> les paquets, et les passer à travers ce filtre. D'ailleurs, c'est
        un travail qu'il est très difficile de comptabiliser dans le processus
        qui a demandé les paquets.

<sect>Faire du réseau avec un portable<label id="notebook">
<p>
        Il existe plusieurs façons de mettre votre portable en réseau. Vous
        pouvez utiliser le code SLIP (et tourner aux vitesses d'une liaison
        série). Vous pouvez employer un portable avec un slot PCMCIA intégré, ou
        bien avec une station d'accueil et y mettre une carte Ethernet ISA.
        Vous pouvez encore utiliser un adaptateur Ethernet sur port parallèle.

<sect1>Utiliser SLIP (Serial Line IP, IP sur liaison série)
<p>
        C'est la solution la moins chère, mais de loin la plus difficile. En
        plus, vous n'obtiendrez pas des taux de transfert très élevés. Comme
        SLIP n'est pas vraiment lié aux cartes Ethernet, nous n'en parlerons pas
        plus ici. Consultez le <sl>NET-2 Howto</>.

<sect1>Support PCMCIA<label id="pcmcia">
<p>
        Essayez de déterminer exactement de quel matériel vous disposez
        (c'est-à-dire le fabricant de la carte, celui du contrôleur de puces
        PCMCIA) puis demandez sur la liste LAPTOPS. En tout état de cause, ne
        vous attendez pas à ce que les choses soient très simples.
        Attendez-vous à chercher et à tourner un peu en rond, à patcher les
        noyaux, etc. Peut-être qu'un jour vous serez capable de taper `make
        config'~8-).

        A l'heure actuelle, les deux jeux de puces PCMCIA qui sont utilisables
        avec Linux sont le TCIC/2 de Databook et l'i82365 d'Intel.

        Il existe un certain nombre de programmes sur <tt>tsx-11.mit.edu</> dans
        le répertoire <tt>/pub/linux/packages/laptops/</tt> qui pourront se
        révéler utiles.

        (NDT~: Bien entendu, le lecteur français se rapportera à l'un des
        miroirs de tsx-11, comme par exemple
        <tt>ftp://ftp.lip6.fr/pub/linux/tsx-11/packages/laptops/</tt>.)

        Cela va des pilotes pour cartes Ethernet PCMCIA aux programmes qui
        communiquent avec la puce du contrôleur PCMCIA. Notez que ces pilotes
        sont en général liés à une puce PCMCIA spécifique (c'est-à-dire la 82365
        d'Intel ou la TCIC/2).

        Pour les cartes compatibles NE2000, certaines personnes ont réussi juste
        en configurant la carte sous DOS, puis en démarrant Linux depuis
        l'invite de commande DOS via <tt>loadlin</>.

        Les choses évoluent pour les utilisateurs de Linux qui souhaitent un
        support PCMCIA, car des progrès substantiels ont été réalisés. Le
        dernier paquetage de David Hinds, qui en est l'un des artisans, se
        trouve sur

<quote>
        <url url="ftp://cb-iris.stanford.edu/pub/pcmcia"
                name="PCMCIA Package">
</quote>

        Cherchez un fichier comme <tt>pcmcia-cs-X.Y.Z.tgz</> où <tt>X.Y.Z</> est
        le dernier numéro de version. Vous devriez aussi pouvoir le trouver sur
        le site FTP <tt>tsx-11.mit.edu</> (ou son miroir le plus proche, NDT).

        Notez que le logiciel d'accès PCMCIA de Donald fonctionne en tant que
        processus utilisateur, alors que David Hinds propose une solution au
        niveau du noyau. Vous serez certainement mieux servi(e) par le paquetage
        de David car il est plus couramment employé, et en constant
        développement.

<sect1>Carte Ethernet ISA dans la station d'accueil.
<p>
        Les stations d'accueil (<sl>docking stations</> en anglais, ou encore
        <sl>dock</>, NDT) coûtent typiqement environ 1500 francs et fournissent
        deux slots ISA standard, deux ports série et un port parallèle. La
        plupart d'entre elles sont alimentées par les batteries du portable, et
        quelques unes permettent d'en ajouter dans la station même, pour peu que
        vous utilisiez des cartes ISA courtes.  Ainsi, vous pouvez utiliser une
        carte réseau économique et profiter des performances d'Ethernet à pleine
        vitesse.

<sect1>Adaptateurs de poche et sur port parallèle.
<p>
        Les adaptateurs Ethernet `de poche' peuvent aussi répondre à vos
        besoins. Notez que la vitesse de transfert ne sera pas aussi importante
        que ça (peut-être 200~Ko/s en pointe~?) à cause des limitations du port
        parallèle.

        La plupart d'entre eux vont vous entraver avec une alimentation qui
        ressemble a un gros pavé. Vous pourrez parfois vous passer du pavé des
        adaptateurs en achetant ou en fabriquant un câble qui prend
        l'alimentation sur le port clavier du portable (voir~<ref id="aep-100"
        name="alimentation du clavier">).

        Consultez~<ref id="de-600" name="DE-600 / DE-620"> et~<ref id="aep-100"
        name="RealTek"> pour deux adaptateurs de poche utilisables sous Linux.

<sect>Questions diverses.<label id="misc">
<p>
        Tout ce qui se rapporte à Ethernet et qui ne rentrait pas ailleurs se
        retrouve ici. Ce n'est peut-être pas significatif, ni intéressant pour
        tout le monde, mais de totue façon, c'est là.

<sect1>Passage des arguments Ethernet au noyau<label id="lilo">
<p>
        Voici deux commandes génériques du noyau qui peuvent être passées au
        noyau au moment du démarrage (<tt>ether</> et <tt>reserve</>). Vous
        pouvez le faire avec LILO, loadlin, ou tout autre utilitaire de
        démarrage qui accepte des arguments optionnels.

        Par exemple, si la commande était `blabla' et qu'elle attende trois
        arguments (disons 123, 456 et 789), alors, avec LILO, vous pourriez
        taper au démarrage~:

        <tt>LILO: linux blabla=123,456,789</tt>

        Pour plus d'informations, ainsi qu'une liste complète, sur les arguments
        de démarrage, veuillez consulter le

<quote>
        <url url="http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html"
             name="BootPrompt-HOWTO">
</quote>

<sect2>L'argument <tt>ether</><label id="ether">
<p>
        La commande <tt>ether=</> est utilisée en conjonction avec le pilote
        compilé dans le noyau. Le <tt>ether=</> n'aura <em>absolument aucun
        effet</> sur un pilote modulaire. Sous sa forme la plus générique, elle
        ressemble à quelque chose comme~:

<tscreen>
        ether=IRQ,ADR_DE_BASE,PARAM_1,PARAM_2,NOM
</tscreen>

        Tous les arguments sont optionnels. Le premier argument non-numérique
        est considéré comme le NOM.

        <bf>IRQ:</>
        Evident. Une valeur d'IRQ de `0' (habituellement la valeur par défaut)
        signifie affectation automatique de l'IRQ. C'est un accident de
        l'Histoire que le paramètre d'IRQ soit en premier plutôt que l'adresse
        de base~--~cela sera corrigé lorsque quelque chose d'autre changera.

        <bf>ADR_DE_BASE:</>
        Evident aussi. Une valeur de `0' (habituellement la valeur par défaut)
        signifie de tester une liste d'adresses spécifiques à ce type de carte
        pour essayer de détecter une carte Ethernet.

        <bf>PARAM_1:</>
        Utilisé à l'origine comme une valeur qui passe outre l'adresse de départ
        de la zone mémoire pour une carte Ethernet à mémoire partagée, comme la
        WD80*3. Certains pilotes utilisent les quatre bits de poids faible de
        cette valeur pour fixer le niveau de message de débogage. 0~--~défaut,
        1-7~--~niveaux~1 à 7 (7 étant le niveau le plus bavard), 8~--~niveau~0
        (pas de messages). Le pilote LANCE utilise les quatre bits de poids
        faible de cette valeur pour sélectionner le canal DMA. Sinon il utilise
        l'affectation automatique du DMA.

        <bf>PARAM_2:</>
        Le pilote 3c503 l'utilise pour choisir entre le transceiver interne et
        le transceiver externe. 0~--~défaut/interne, 1~--~AUI externe. Les
        cartes E21XX de Cabletron utilisent les quatre bits de poids faible de
        PARAM_2 pour choisir le support physique. Sinon il est détecté
        automatiquement.

        <bf>NOM:</>
        Sélectionne le périphérique réseau auquel les valeurs se réfèrent. Le
        noyau standard utilise les noms `eth0', `eth1', `eth2' et `eth3' pour
        les cartes Ethernet attachées au bus, et `atp0' pour l'adaptateur `de
        poche' sur port parallèle. Le pilote ARCnet utilise le nom `arc0'. Le
        comportement par défaut est de tester une seule carte Ethernet pour
        `eth0'. Vous ne pouvez activer plusieurs cartes qu'en fixant de façon
        explicite leur adresse de base avec les paramètres de LILO. Le noyau 1.0
        considérait les cartes Ethernet basées sur la puce LANCE comme un cas
        spécial. Les arguments de LILO étaient ignorés, et les cartes LANCE
        recevaient toujours des noms `eth&lt;n&gt;' en commençant à `eth0'. Les
        cartes supplémentaires, non-LANCE, devaient être affectées à
        `eth&lt;n+1&gt;', et le test habituel de `eth0' devait alors être
        désactivé avec quelque chose comme `ether=0,-1,eth0'. (Oui, c'est
        bogué.)

<sect2> La commande <tt>reserve</><label id="reserve">
<p>
        Cette autre commande LILO est utilisée exactement comme la commande
        `<tt>ether=</>' ci-dessus, c'est-à-dire que l'on ajoute son nom aux
        options spécifiées dans <tt>lilo.conf</>~:

<tscreen>
        reserve=IO-base,extent{,IO-base,extent...}
</tscreen>

        Sur certaines machines, il peut être nécessaire d'empêcher les pilotes
        de périphérique de tester des périphériques (auto-détection) dans une
        zone spécifique. Cela peut être le cas à cause d'un matériel mal conçu
        qui <em>fige</> le démarrage (comme certaines cartes Ethernet), qui est
        identifié par erreur, dont l'état a été changé par une procédure de
        détection précédente, ou plus encore d'un matériel que vous ne souhaitez
        pas voir initialisé par le noyau.

        L'argument de démarrage <tt>reserve</> répond à cette attente en
        spécifiant une région de port d'E/S qui ne doit pas être testée. Cette
        région est réservée dans la table d'enregistrement des ports du noyau
        comme si un périphérique avait déjà été trouvé dans cette région. Notez
        que ce mécanisme ne devrait pas être nécessaire sur toutes les
        machines. C'est seulement lorsqu'il y a un problème ou un cas spécial
        que son utilisation peut se révéler nécessaire.

        Les ports d'E/S dans la zone spécifiée sont protégés contre les
        procédures de détection de périphériques. Nous avons montré que cela est
        nécessaire lorsqu'un pilote se bloque sur une carte NE2000, ou identifie
        de façon erronée un autre périphérique comme étant le sien. Un pilote de
        périphérique correct ne devrait pas tester une zone réservée, à moins
        qu'un autre argument de démarrage ne spécifie explicitement qu'il doive
        le faire sur cette zone. Cela implique que <tt>reserve</> sera le plus
        souvent utilisé avec un autre argument de démarrage. Donc si vous
        spécifiez une zone de <tt>reserve</> pour protéger un périphérique
        donné, vous devez généralement spécifier explicitement une détection
        pour ce périphérique. La plupart des pilotes ignorent la table
        d'enregistrement des ports si on leur fournit une adresse explicite.

        Par exemple, la ligne de démarrage
<tscreen>
        LILO: linux  reserve=0x300,32  ether=0,0x300,eth0
</tscreen>

        oblige tous les périphériques à l'exception des pilotes Ethernet à ne
        pas tester la plage <tt>0x300-0x31f</>.

        Comme d'habitude avec les spécificateurs de démarrage, il existe une
        limite de 11 paramètres, donc vous ne pouvez spécifier que 5 zones
        réservées par mot-clé <tt>reserve</>. Plusieurs spécificateurs
        <tt>reserve</> fonctionneront si vous avez une requête inhabituellement
        compliquée.

<sect1>Utilisation des pilotes Ethernet comme modules<label id="modules">
<p>
        La majorité des distributions disponibles ont des noyaux avec très peu
        de pilotes intégrés. Les pilotes sont fournis comme modules chargeables
        dynamiquement. Ces pilotes modulaires sont normalement chargés par
        l'administrateur via la commande <tt>modprobe(8)</> dans certains cas,
        ils sont automatiquement chargés par le noyau via <tt>kerneld</> (pour
        les 2.0) ou <tt>kmod</> (pour les 2.1) qui eux-mêmes font appel à
        <tt>modprobe</>.

        Votre distribution offre peut être de jolis outils graphiques pour
        configurer les modules ethernet. Si possible, essayez de les utiliser
        avant tout. La description qui suit explique ce qui se cache derrière
        ces jolis petits programmes et ce que'ils changent.

        Les informations qui déterminent quels modules doivent être utilisés et
        les options qui leur sont associées sont en principe stockées dans le
        fichier <tt>/etc/conf.modules</tt>. Les deux options qui y ont le plus
        d'interêt (pour les cartes ethernet) sont <tt>alias</> et
        <tt>options</>.  La commande <tt>modprobe</> consulte ce fichier pour
        obtenir des informations sur les modules.

        Les modules utilisés sont normalement stockés dans un répertoire nommé
        <tt>/lib/modules/`uname -r`/net</tt> où la commande <tt>uname -r</>
        retourne la version du noyau (ex~: 2.0.34). Vous pouvez aller y faire un
        tour pour savoir quels modules correspondent à votre carte.

        La première chose à mettre dans votre <tt>/etc/conf.modules</> est une
        ligne indiquant à <tt>modprobe</> où se trouve le pilote à utiliser avec
        <tt>eth0</> (et <tt>eth1</>, ...), ceci grâce à un alias. Par exemple,
        si vous avez une carte ISA SMC EtherEZ qui utilise le module
        <tt>smc-ultra.o</>, vous aurez besoin de créer un alias entre ce pilote
        et <tt>eth0</> en ajoutant cette ligne~:

<verb>
        alias eth0 smc-ultra
</verb>

        Vous pourrez aussi avoir à ajouter une ligne d'<tt>options</> indiquant
        lesquelles doivent être utilisées avec tel module (ou alias de
        module). Continuons l'exemple ci-dessus~: avec la ligne <tt>alias</>
        seule, le noyau vous préviendrait (cf. <tt>dmesg</>) que l'autodétection
        des cartes ISA n'est <em>pas</> une bonne idée.  Pour supprimer cet
        avertissement, il suffirait d'ajouter une ligne donnant au module
        l'adresse d'E/S de votre carte, dans ce cas, l'adresse hexadécimale
        <tt>0x280</>.

<verb>
        options smc-ultra io=0x280
</verb>

        La plupart des modules ISA acceptent des arguments comme <tt>io=0x340</>
        et <tt>irq=12</> sur la ligne de commande d'<tt>insmod</>. Il est
        <em>REQUIS</> ou du moins <em>FORTEMENT RECOMMANDÉ</> que vous
        fournissiez ces paramètres pour éviter la détection automatique de la
        carte. A la différence des périphériques PCI et EISA, il n'existe pas de
        moyen vraiment sûr de réaliser une détection automatique de la majorité
        des périphériques ISA, et cela doit donc être évité quand on utilise les
        pilotes sous la forme de modules chargeables.

        Une liste de toutes les options acceptées par chaque module se trouve
        dans le fichier~:

        <tt>/usr/src/linux/Documentation/networking/net-modules.txt</tt>

        Vous avez intérêt à le lire pour trouver les options à utiliser pour
        votre carte. Notez que quelques modules permettent les listes d'options
        séparées par des virgules, ils sont capables de gérer plusieurs cartes
        depuis un seul module, par exemple les cartes à base de 8390, ainsi que
        le pilote PLIP.

<code>
        option 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
</code>

        La commande ci-dessus permet à un seul et même module de contrôler
        quatre cartes 3c503, les cartes 2 et 4 utilisant le transceiver
        externe. Ne mettez pas d'espace autour des '=' ou des virgules.

        Notez aussi que les modules <tt>utilisés</> ne peuvent être supprimés de
        la mémoire. Cela signifie que vous aurez à faire un <tt>ifconfig eth0
        down</> (arrêter la carte ethernet) avant de pouvoir les supprimer.

        La commande <tt>lsmod</> vous dira quels sont les modules qui sont
        chargés, s'ils sont utilisés, et <tt>rmmod</> les supprimera.

<sect1>Documents associés
<p>
        La plupart des informations que vous trouvez dans ce document
        proviennent de messages sauvegardés des groupes de
        <tt>comp.os.linux.*</>, ce qui montre qu'il s'agit d'une vraie source
        d'informations. D'autres renseignements très utiles proviennent de tout
        un tas de petits fichiers de Donald lui-même.

        Bien entendu, si vous configurez une carte Ethernet, vous voudrez
        configurer les logiciels que vous allez utiliser, et vous lirez pour
        cela le <sl>Howto NET-3</>. Ou encore, si vous vous sentez pousser des
        ailes de ``hacker'', vous pourrez toujours grapiller des informations
        supplémentaires directement dans les fichiers sources des pilotes. Ils
        comportent en général un paragraphe ou deux décrivant les points
        importants, avant que le code ne démarre...

        Pour ceux d'entre vous qui recherchent des informations qui ne sont pas
        spécifiques à Linux (comme~: qu'est-ce que 10BaseT, qu'est-ce qu'AUI,
        que fait un hub, etc.) je vous recommande fortement d'utiliser le groupe
        de news <tt>comp.dcom.lans.ethernet</> et/ou
        <em>comp.sys.ibm.pc.hardware.networking</>. Les archives de news tels
        que <tt>deja.com</> sont aussi une source intarissable de réponses. Vous
        pouvez aussi récupérer les FAQ de ces groupes de news sur par exemple~:

<quote>
        <url url="ftp://ftp.lip6.fr/pub/doc/faq/usenet-by-hierarchy/"
             name="Les FAQ de Usenet">
</quote>

        Vous pouvez aussi consulter la `Page d'accueil d'Ethernet' pour ainsi
        dire, qui se trouve à l'URL suivante~:
<quote>
        <url url="http://wwwhost.ots.utexas.edu/ethernet/ethernet-home.html"
             name="La page d'accueil d'Ethernet">
</quote>

<sect1>Désistement de responsabilité et Copyright<label id="copyright">
<p>
        Ce document <em>n'est pas</> la bible. Toutefois, il s'agit certainement
        de la source d'informations la plus à jour que vous pourrez
        trouver. Personne n'est responsable de ce qui arrive à votre matériel
        hormis vous-même. Si votre carte Ethernet ou tout autre partie
        matérielle de votre ordinateur part en fumée (...bien que ce soit
        pratiquement impossible~!) nous n'en prenons aucune responsabilité. LES
        AUTEURS NE SONT RESPONSABLES D'AUCUN DOMMAGE ENCOURU CONSÉCUTIF A DES
        ACTIONS EFFECTUÉES EN SE BASANT SUR LES INFORMATIONS COMPRISES DANS CE
        DOCUMENT.

        Ce document est Copyright (c) 1993-1997 by Paul Gortmaker. Il est permis
        de faire et de distribuer des copies complètes de ce manuel à condition
        que la notice de copyright et que cette notice de permission soient
        préservées dans toutes les copies.

        Il est permis de copier et de distribuer des versions modifiées de ce
        document sous les mêmes conditions que la copie complète, à condition
        que cette notice de copyright soit incluse exactement telle qu'elle
        l'est dans l'original, et que le travail dérivé résultant, dans son
        intégralité, soit distribué sous les termes d'une notice de permission
        identique à celle-ci.

        Il est permis de copier et de distribuer des traductions de ce document
        dans d'autres langues, sous les mêmes conditions que ci-dessus pour les
        versions modifiées.

        Si vous avez l'intention d'intégrer ce document dans un travail destiné
        à la publication, contactez-moi (par courrier électronique) afin de
        pouvoir obtenir les informations les plus à jour possible. Par le passé,
        des versions dépassées de documents <sl>Linux HOWTO</> ont été publiées,
        causant aux développeurs le préjudice indû d'être empoisonnés par des
        questions dont les réponses figuraient déjà dans les versions à jour.


<p>
        En accord avec cette notice, la version originale (en anglais) telle
        qu'elle apparaît dans l'<sl>Ethernet-HOWTO</> est fournie ici~:

        This document is <em>not</> gospel. However, it is probably the most up
        to date info that you will be able to find. Nobody is responsible for
        what happens to your hardware but yourself. If your ethercard or any
        other hardware goes up in smoke (...nearly impossible!)  we take no
        responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE FOR ANY DAMAGES
        INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION INCLUDED IN THIS
        DOCUMENT.

        This document is Copyright (c) 1993-1997 by Paul Gortmaker. Permission
        is granted to make and distribute verbatim copies of this manual
        provided the copyright notice and this permission notice are preserved
        on all copies.

        Permission is granted to copy and distribute modified versions of this
        document under the conditions for verbatim copying, provided that this
        copyright notice is included exactly as in the original, and that the
        entire resulting derived work is distributed under the terms of a
        permission notice identical to this one.

        Permission is granted to copy and distribute translations of this
        document into another language, under the above conditions for modified
        versions.

        A hint to people considering doing a translation.  First,
        translate the SGML source (available via FTP from the HowTo
        main site) so that you can then generate other output formats.
        Be sure to keep a copy of the original English SGML source that
        you translated from! When an updated HowTo is released,
        get the new SGML source for that version, and then a simple
        <tt>diff -u old.sgml new.sgml</> will show you exactly what has
        changed so that you can easily incorporate those changes into
        your translated SMGL source without having to re-read or
        re-translate everything.

        If you are intending to incorporate this document into a published work,
        please make contact (via e-mail) so that you can be supplied with the
        most up to date information available. In the past, out of date versions
        of the Linux HowTo documents have been published, which caused the
        developers undue grief from being plagued with questions that were
        already answered in the up to date versions.

<p>
        Ce document fait partie des <sl>HOWTO Linux</> traduits en français.
        Vous pouvez trouver une liste à jour de ces documents à l'adresse
        <url url="http://www.freenix.org/unix/linux/HOWTO/Liste-des-HOWTO.html">

        Les <sl>HOWTO Linux</> font partie du <sl>Linux Documentation Project</>
        (LDP). Si vous souhaitez participer au LDP ou à sa traduction en
        français, vous pouvez consulter
        <url url="http://www.freenix.org/unix/linux/HOWTO/Liste-des-HOWTO.html">
        ou contacter Eric Dumas, <tt>dumas@linux.eu.org</>.

<p>
        Cette version française a été réalisée par Mathieu Arnold
        <tt>&lt;arn_mat@club-internet.fr&gt;</tt>, Stéphane Alnet
        <tt>&lt;alnet@u-picardie.fr&gt;</tt> était l'ancien traducteur. Elle est
        Copyright (c) 1997-1998, Mathieu Arnold, selon les termes de la notice
        ci-dessus.

        <!-- Q~: est-ce que j'ai le droit de mettre mon copyright ici,
                BTW~? (Stéphane)
             Q2~: et moi~:) (Mathieu)
             Q3~: euh ... et les relecteurs ? Y peuvent aussi ? ;) (joel)
                  c'est pas juste, Carine a pas lue jusqu'ici ;) (Mathieu)
                  Hé, Carine !!! Tu viens jeter un coup d'oeil ici ? Ça parle de toi
! (Joel)
        -->

        Si vous constatez des erreurs <em>dans la traduction</> en français,
        merci d'en informer le traducteur. Vos remarques seront prises en compte
        pour la prochaine version de la traduction.

<sect1>Conclusion
<p>

        Si vous avez trouvé une faute de frappe énaurme, ou des informations
        dépassées dans ce document, merci d'envoyer un courrier électronique.
        Il est énorme, et il est facile de rater certaines choses.  Si vous avez
        envoyé un courrier à propos d'une modification, et qu'elle n'a pas été
        incluse dans la version suivante, n'hésitez pas à la ré-envoyer, car
        elle a pu se perdre dans le flot habituel de SPAM et de prospectus que
        je reçois.

        Merci~!

        Paul Gortmaker, <tt>p_gortmaker@yahoo.com</>
</article>

<!--  LocalWords:  ether PIO ThunderLAN tulip Fujitsu PCNet-PCI RealTek Semiconductor
 -->
<!--  LocalWords:  Arcnet Cabletron Becker eth MiCom-Interlan RealTek's PROM
 -->
<!--  LocalWords:  consoeur Sager Schneider Koch SEEQ Western SMC smc-ultra BNC
 -->
<!--  LocalWords:  Zubkoff Farallon Kingston LinkSys Compaq NetFlex Netelligent
 -->
<!--  LocalWords:  Olicom Amazon Thomas Conrad master Winbond winbond David
 -->
<!--  LocalWords:  Hinds ifconfig
 -->