/usr/share/doc/HOWTO/fr-html/Ethernet-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Linux Ethernet-Howto</title>
</head>
<body>
<h1>Linux Ethernet-Howto</h1>
<h2>par Paul Gortmaker Version française&nbsp;: Mathieu Arnold</h2>
Version anglaise&nbsp;: v2.7, 5 mai 1999
<hr>
<em>Ceci est l'<i>Ethernet-Howto</i>, 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 <i>Howto</i> se limite à l'aspect matériel et pilotes de bas
niveau des cartes Ethernet, et ne couvre pas la partie logicielle
de choses comme <code>ifconfig</code> et <code>route</code>.
Consultez le <i>Network&nbsp;Howto</i> pour ce type
d'informations.</em>
<hr>
<h2><a name="main-intro"></a> <a name="s1">1. Introduction</a></h2>
<p>L'<i>Ethernet-Howto</i> 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.</p>
<p>Il <em>ne</em> couvre <em>pas</em> l'aspect logiciel des choses,
tel qu'il est décrit dans le <i>NET-3-Howto</i>. 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
<code>comp.dcom.lans.ethernet</code>. Vous pouvez l'obtenir par FTP
depuis <code>rtfm.mit.edu</code> de la même manière que vous
obtenez les FAQs des autres forums.</p>
<p>La présente version couvre les noyaux de distribution jusqu'à la
version 2.2.7 incluse.</p>
<p>L'<i>Ethernet-Howto</i> est de&nbsp;:</p>
<blockquote>Paul Gortmaker,
<code>p_gortmaker@yahoo.com</code></blockquote>
<p>La principale source d'information pour la première version, en
ASCII pur de l'<i>Ethernet-Howto</i> était&nbsp;:</p>
<blockquote>Donald J. Becker,
<code>becker@cesdis.gsfc.nasa.gov</code></blockquote>
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&nbsp;!
<p>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&nbsp; <a href=
"#copyright">Désistement de responsabilité et Copyright</a>) 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...'.</p>
<p>La version française est de&nbsp;:</p>
<blockquote>Mathieu Arnold,
<code>arn_mat@club-internet.fr</code>.</blockquote>
<h2><a name="new-doc"></a> <a name="ss1.1">1.1 Nouvelles versions
de ce document</a></h2>
<p>Les nouvelles versions de ce document peuvent être rapatriées
depuis&nbsp;:</p>
<blockquote><a href=
"ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/">Sunsite HOWTO
Archive</a></blockquote>
Ceci est l'emplacement officiel de ce document, il peut aussi être
récupéré depuis divers sites miroirs WWW/FTP de Linux.
<p>(NDT&nbsp;: En France, vous préférerez utiliser le site suivant
pour le document originel&nbsp;:</p>
<p><a href="ftp://ftp.lip6.fr/pub/linux/sunsite/docs/HOWTO/">Miroir
de Sunsite</a></p>
<p>ou, mieux, la version française&nbsp;:</p>
<p><a href="ftp://ftp.lip6.fr/pub/linux/french/HOWTO/">Archive des
HOWTO français sur LIP6</a></p>
<p><a href=
"http://www.freenix.org/unix/linux/french/HOWTO/">Archive des HOWTO
français chez Freenix</a>)</p>
<p>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.</p>
<p>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.</p>
<h2><a name="using"></a> <a name="ss1.2">1.2 Ethernet-Howto, mode
d'emploi</a></h2>
<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)</em> 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.</p>
<p>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&nbsp;(
<a href="#help">Au secours - Ca ne marche pas~!</a>) est destinée
aux néophytes de Linux et vous indiquera la bonne direction.</p>
<p>Typiquement, les mêmes problèmes et les mêmes questions sont
posés <em>sans arrêt</em> 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&nbsp;: Foire Aux Questions) de ce document.
(Voir&nbsp; <a href="#faq">La Foire Aux Questions</a>). Tout le
monde devrait y jeter un coup d'oeil avant d'envoyer un message
demandant de l'aide.</p>
<p>Si vous n'avez pas encore de carte Ethernet, vous devriez
commencer par en choisir une. (Voir&nbsp; <a href=
"#what-card">Quelle carte dois-je acheter...</a>)</p>
<p>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&nbsp; <a href="#card-intro">Informations
Spécifiques...</a>)</p>
<p>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&nbsp; <a href="#tech-intro">Informations Techniques</a> qui
contient ces informations.</p>
<h2><a name="help"></a> <a name="ss1.3">1.3 Au secours&nbsp;! - Ca
ne marche pas&nbsp;!</a></h2>
<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.</p>
<p>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.</p>
<p>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&nbsp; <a href=
"#mystery">Identifier une carte inconnue</a>, qui vous aidera sur
les cartes mystérieuses.</p>
<p>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&nbsp; <a href="#card-intro">Informations
Spécifiques...</a>), 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.</p>
<p>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</em> 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.</p>
<p>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&nbsp; <a href="#modules">Utilisation
des pilotes Ethernet comme modules</a>).</p>
<p>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 <i>Kernel-HowTo</i> qui
vous aidera dans cette opération.</p>
<p>(NDT&nbsp;: et sa version française, accessible sur</p>
<p><a href=
"ftp://ftp.lip6.fr/pub/linux/french/HOWTO/Kernel-HOWTO">Traduction
du Kernel-Howto</a>)</p>
<p>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.</p>
<p>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 <code>dmesg | more</code> 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 <code>eth0</code>,
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&nbsp;: 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&nbsp;!)</p>
<p>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&nbsp; <a href=
"#faq">La Foire Aux Questions</a>) 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.</p>
<p>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.</p>
<p>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&nbsp;15 et que le pilote indique IRQ&nbsp;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.</p>
<p>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
<code>ifconfig</code> ou <code>route</code> (ou les deux&nbsp;!);
la manière de procéder est décrite en détail dans le
<i>Network&nbsp;HowTo</i> et le `Guide de l'Administrateur Réseau'
(`<i>Network Administrator's Guide</i>' (NAG) en anglais) qui se
trouvent certainement tous les deux sur le CD-ROM
d'installation.</p>
<p>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)&nbsp;Vous obtenez un message
d'erreur lorsque <code>ifconfig</code> essaie d'ouvrir le
périphérique pour l'utiliser, du genre ``<code>SIOCSFFLAGS: Try
again</code>''. (2)&nbsp;Le pilote indique des messages d'erreur
sur <code>eth0</code> (que vous pouvez voir avec <code>dmesg |
more</code>) ou des incohérences étranges à chaque fois qu'il
essaie d'envoyer ou de recevoir des données. (3)&nbsp;Le fait de
taper <code>cat /proc/net/dev</code> donne un nombre non nul dans
l'une des colonnes <code>errs</code>, <code>drop</code>,
<code>fifo</code>, <code>frame</code> ou <code>carrier</code> pour
<code>eth0</code>. (4)&nbsp;Taper <code>cat /proc/interrupts</code>
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.</p>
<p>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</em>
alors vous pourrez recourir à un envoi de message dans un groupe de
<i>news</i> 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 <code>cat
/proc/net/dev</code>, une description claire du problème, et bien
entendu ce que vous avez déjà essayé en vue de faire fonctionner
l'ensemble.</p>
<p>Vous serez surpris de voir le nombre de personnes qui envoient
des choses totalement inutiles comme ``Est-ce que quelqu'un peut
m'aider&nbsp;? 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.</p>
<h2><a name="what-card"></a> <a name="s2">2. Quelle carte dois-je
acheter pour Linux&nbsp;?</a></h2>
<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.</p>
<p>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&nbsp;bits vous contentera probablement.</p>
<p>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.</p>
<p>Si vous vous trouvez au milieu de ces deux extrêmes, alors
n'importe quelle carte PCI bon marché ou une carte ISA 16&nbsp;bits
possédant un pilote stable vous conviendra.</p>
<h2><a name="ss2.1">2.1 Quels sont les pilotes stables,
alors&nbsp;?</a></h2>
<p>Parmi les cartes ISA 16&nbsp;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&nbsp;:</p>
<blockquote>SMC-Ultra/EtherEZ, SMC-Elite (WD80x3), 3c509, Lance,
NE2000.</blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="8-vs-16"></a> <a name="ss2.2">2.2 Cartes 8&nbsp;bits
contre cartes 16&nbsp;bits</a></h2>
<p>Vous ne pourrez certainement plus acheter une carte Ethernet ISA
8&nbsp;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&nbsp;bits car les cartes PCI deviennent de plus en plus
communes.</p>
<p>La wd8003, la 3c503 et la ne1000 sont des cartes 8&nbsp;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&nbsp;ans&nbsp;!) des beaux jours du XT sont à
éviter. (Envoyez les a Alan, il les collectionne...)</p>
<p>Le canal de données 8&nbsp;bits n'atténue pas trop les
performances, puisque vous pouvez encore espérer obtenir 500 à
800&nbsp;Ko/s en vitesse de transfert FTP pour une carte
8&nbsp;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.</p>
<h2><a name="ss2.3">2.3 Cartes 32&nbsp;bits (VLB/EISA/PCI)</a></h2>
<p>Notez qu'un réseau à 10&nbsp;Mbps ne justifie pas l'utilisation
d'une interface 32&nbsp;bits. Consultez&nbsp; <a href=
"#data-xfer">E/S programmées contre...</a>, qui explique pourquoi
avoir une carte Ethernet 10&nbsp;Mbit/s sur un bus ISA à 8&nbsp;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.</p>
<p>Bien sûr, avec la démocratisation des réseaux 100&nbsp;Mbps, les
cartes 32&nbsp;bits deviennent une obligation pour pouvoir tirer
avantage de toute la bande passante. AMD propose les puces
32&nbsp;bits PCnet-VLB et PCnet-PCI. Consultez&nbsp; <a href=
"#pcnet-32">AMD PCnet-32</a> pour plus d'informations sur la
version 32&nbsp;bits de la puce LANCE / PCnet-ISA.</p>
<p>La puce tulip (21xxx) PCI de DEC est une autre option
(voir&nbsp; <a href="#dec-21040">DEC 21040</a>) 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.</p>
<p>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
<a href="#vortex">3c590/3c595</a>)</p>
<p>Les cartes EtherExpress Pro 10/100 PCI d'Intel sont aussi
connues pour marcher plutôt bien avec Linux. (voir <a href=
"#eepro100">EtherExpress</a>).</p>
<p>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 <code>ne2k-pci.c</code>
est aussi disponible. Il devrait être légerement plus efficace que
le pilote ISA <code>ne.c</code></p>
<h2><a name="ss2.4">2.4 Cartes et pilotes 100 M
disponibles</a></h2>
<p>La liste des matériels 100&nbsp;M reconnus par Linux à l'heure
actuelle est la suivante&nbsp;: les cartes basées sur la puce
DEC&nbsp;21140; les cartes 3c595/3c90x&nbsp;Vortex; la
EtherExpressPro10/100B; la PCnet-FAST; la SMC 83c170 (epic100) et
la HP 100VG&nbsp;ANY-LAN.</p>
<p>Allez aussi jeter un coup d'oeil sur les pages des constructeurs
des cartes, vous pouvez aussi aller sur l'une des adresse
suivantes&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html">Ethernet
100M</a></blockquote>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/drivers/100vg.html">La page
100VG de Donald</a></blockquote>
<blockquote><a href="http://alumni.caltech.edu/~dank/fe/">La page
Fast Ethernet de Dan Kegel</a></blockquote>
<h2><a name="ss2.5">2.5 100VG contre 100BaseT</a></h2>
<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
<code>comp.os.linux</code>; elle résume bien la situation:</p>
<p>``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).</p>
<p>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&nbsp;:</p>
<p>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.</p>
<p>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&nbsp;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.</p>
<p>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.''</p>
<p>(NDT&nbsp;: ``La norme 100&nbsp;BAS&nbsp;VG&nbsp;- any&nbsp;LAN
proposée par HP (...) ne reprend pas le principe du protocole
Ethernet mais utilise le principe du <i>polling</i>. 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,
<i>in</i> ``Réseaux haut débit'', Hermès, 1995). Fin&nbsp;1997 plus
personne ne parle de&nbsp;100VG.</p>
<p>La norme 100baseT4 utilise un câblage catégorie
3&nbsp;et&nbsp;4, 100baseTx un câblage catégorie&nbsp;5, 100baseFx
de la fibre optique.)</p>
<h2><a name="cable-intro"></a> <a name="ss2.6">2.6 Les types de
câbles que votre carte peut accepter</a></h2>
<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&nbsp;fin (câble coaxial RG-58) avec les
connecteur BNC (en métal, à enfoncer puis tourner pour verrouiller)
est appelé techniquement 10Base2.</p>
<p>La plupart des cartes Ethernet possèdent aussi une version
`Combo' qui ne coûte que 60&nbsp;à&nbsp;150 francs de plus.
(NDT&nbsp;: Amusant comme les écarts de prix en dollars se
convertissent en écarts de prix en francs&nbsp;! La version
anglaise dit ``10 à 20 dollars de plus''. Ces écarts de prix sont
vrais fin 97.)</p>
<p>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&nbsp;: `Combo' signigie même souvent&nbsp;:
interface RJ-45 (10baseT, paire torsadée) + interface BNC (10base2,
thinnet) + interface AUI (pour <i>transceiver</i> ou câble de
descente (drop-cable) gros Ethernet).)</p>
<p>Les câbles à paires torsadées, avec les connecteurs&nbsp;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).</p>
<p>Le vieil Ethernet&nbsp;`épais' (Thick Ethernet, sur câble
coaxial de 10&nbsp;mm) ne se trouve plus que dans les installations
anciennes et est appelé&nbsp;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.</p>
<p>Les grandes installations professionnelles utiliseront le plus
souvent du&nbsp;10BaseT au lieu de&nbsp;10Base2. 10Base2 n'offre
pas de moyen pour passer au 100&nbsp;Mbit/s, quel que soit le nom
qu'on leur donne.</p>
<p>(NDT&nbsp;: 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.</p>
<p>Pour la maison, vous choisirez entre Ethernet fin (simple et pas
cher) et une connectique style&nbsp;RJ-45 (un peu moins simple, un
peu plus cher, mais plus `propre' électriquement parlant) selon vos
envies et votre budget&nbsp;!</p>
<p>Référez vous a <a href="#cable">Cables, Coax...</a> pour plus de
détails sur les différents types de cables.</p>
<h2><a name="faq"></a> <a name="s3">3. Foire Aux Questions (FAQ) -
Les questions fréquemment posées</a></h2>
<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 : <a href=
"http://www.deja.com">Dejanews</a>.</p>
<h2><a name="alfa"></a> <a name="ss3.1">3.1 Les pilotes `Alpha' --
Comment les obtenir et comment s'en servir</a></h2>
<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&nbsp;?</p>
<p>Les plus récents des `nouveaux' pilotes peuvent être trouvés sur
le site FTP de Donald&nbsp;: <code>cesdis.gsfc.nasa.gov</code> dans
la partie <code>/pub/linux/</code>. 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&nbsp;:</p>
<blockquote><a href="http://cesdis.gsfc.nasa.gov/linux/">La page
Linux de Don</a></blockquote>
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.)
<p>Maintenant, s'il s'agit réellement d'un pilote alpha, voire
pré-alpha, s'il vous plaît considérez-le comme tel&nbsp;! 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&nbsp;!</p>
<p>Notez que certains des pilotes expérimentaux ou alpha
`utilisables' sont inclus dans l'arborescence standard du noyau.
Lorsque vous exécutez <code>make config</code>, 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&nbsp;``Y'' (pour `<i>Yes</i>', `Oui') à cette question si
vous souhaitez être interrogé(e) sur l'inclusion d'un pilote alpha
ou expérimental.</p>
<h2><a name="two-card"></a> <a name="ss3.2">3.2 Utiliser plus d'une
carte Ethernet par machine</a></h2>
<p>Que faut-il faire pour que Linux puisse gérer deux cartes
Ethernet&nbsp;?</p>
<p>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 <code>/lib/modules/</code>).</p>
<p><em>Avec le pilote chargé en module&nbsp;:</em> 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
<code>/etc/conf.modules</code>.</p>
<p>Par exemple, supposez qu'un utilisateur ait deux cartes ISA
NE2000, une à <code>Ox300</code> et l'autre à <code>0x240</code>,
il aura les lignes suivantes dans son
<code>/etc/conf.modules</code>&nbsp;:</p>
<pre>
        alias eth0 ne
        alias eth1 ne
        options ne io=0x240,0x300
</pre>
<p>Explication&nbsp;: cela dit que si l'administrateur (ou le
noyau) fait un <code>modprobe eth0</code> ou un <code>modprobe
eth1</code>, alors le pilote <code>ne.o</code> devra être chargé
pour <code>eth0</code> et <code>eth1</code>. De plus, quand le
module se chargera, il le sera avec comme options
<code>io=0x240,0x300</code>. Ainsi, le pilote saura où aller
chercher les cartes. Notez que le <code>0x</code> est important,
des trucs comme <code>300h</code> couramment utilisés dans le monde
DOS ne marcheront pas. Le fait d'inverser <code>0x240</code> et
<code>0x300</code> aura pour effet d'inverser physiquement
<code>eth0</code> et <code>eth1</code>.</p>
<p>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&nbsp;?), tels que le module
<code>3c501.o</code> 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 <code>/etc/conf.modules</code> ressemblerait alors
à&nbsp;:</p>
<pre>
        alias eth0 3c501
        alias eth1 3c501
        options eth0 -o 3c501-0 io=0x280 irq=5
        options eth1 -o 3c501-1 io=0x300 irq=7
</pre>
<p>Dans cet exemple, l'option <code>-o</code> 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
<code>irq=</code> 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.)</p>
<p>Pour finir, voici un exemple avec une carte 3c503 à
<code>0x350</code> et une SMC Elite16 (wd8013) à
<code>0x280</code>. Vous auriez&nbsp;:</p>
<pre>
        alias eth0 wd
        alias eth1 3c503
        options wd io=0x280
        options 3c503 io=0x350
</pre>
<p>Pour les cartes PCI, vous avez juste besoin des lignes
<code>alias</code> pour associer les interface <code>ethN</code>
aux pilotes correspondants, puisque les adresses d'entrée/sortie
des cartes PCI sont automatiquement détectées.</p>
<p>Les modules disponibles sont généralements situés dans le
répertoire <code>/lib/modules/`uname -r`/net</code> où la commande
<code>uname -r</code> retourne la version du noyau (ex&nbsp;:
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 <code>/etc/conf.modules</code>, il ne vous
reste plus qu'à tester avec la commande&nbsp;:</p>
<pre>
        modprobe ethN
        dmesg | tail
</pre>
<p>Où N est le numéro de l'interface que vous testez.</p>
<p><em>Avec le pilote compilé dans le noyau&nbsp;:</em> 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</em> 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'.</p>
<p>(Note&nbsp;: 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&nbsp;: 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.)</p>
<p>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.</p>
<p>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
<code>ether=0,0,eth1</code>. Dans ce cas, <code>eth0</code> et
<code>eth1</code> 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&nbsp;<code>0x300</code>
soit&nbsp;<code>eth0</code> et que la carte sur le
port&nbsp;<code>0x280</code> soit&nbsp;<code>eth1</code>, vous
pourrez utiliser</p>
<blockquote><code>LILO: linux ether=5,0x300,eth0
ether=15,0x280,eth1</code></blockquote>
<p>La commande&nbsp;<code>ether=</code> accepte plus d'informations
que le numéro d'IRQ&nbsp;+ le port&nbsp;d'E/S&nbsp;+ le nom qui
sont montrés ci-dessus. Veuillez consulter&nbsp; <a href=
"#lilo">Passage des arguments Ethernet...</a> pour la syntaxe
complète, les paramètres spécifiques à chaque carte, et des astuces
pour LILO.</p>
<p>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 `<code>append</code>'
de LILO.</p>
<p>La seconde méthode (non recommandée) est d'éditer le fichier
<code>Space.c</code> et de remplacer la valeur <code>0xffe0</code>
pour l'adresse d'entrée-sortie par un zéro. La valeur
<code>0xffe0</code> indique au noyau qu'il ne doit pas essayer de
détecter ce périphérique --&nbsp;la remplacer par un zéro
autorisera l'auto-détection du périphérique.</p>
<p>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&nbsp;forwarding''. Mais
généralement un vieil AT/286 avec quelque chose comme le logiciel
`kbridge' est une meilleure solution.</p>
<p>Si vous consultez ce document tout en <i>surfant</i> sur le
réseau, vous pourrez jeter un coup d'oeil à un <i>mini-HOWTO</i>
que Donald a sur son site WWW. Consultez&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/misc/multicard.html">Plusieurs
Cartes Ethernet</a>.</blockquote>
<h2><a name="ss3.3">3.3 le <code>ether=</code> n'a rien changé.
Pourquoi&nbsp;?</a></h2>
<p>Comme il a été dit précédemment, la commande <code>ether=</code>
ne marche <em>que</em> 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
<code>ether=</code> 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</em> faire les changements dans le
fichier <code>/etc/conf.modules</code>.</p>
<p>Si vous utilisez un pilote compilé dans le noyau et avez ajouté
la ligne <code>ether=</code> à votre fichier de configuration LILO,
notez qu'il ne sera pris en compte que lorsque vous relancerez
<code>lilo</code> pour mettre à jour les informations.</p>
<h2><a name="ne2k-probs"></a> <a name="ss3.4">3.4 Problèmes avec
les cartes NE1000 / NE2000 (et leurs clones)</a></h2>
<p><b>Problème&nbsp;:</b> Une carte PCI clone NE2000 n'est pas
détectée au démarrage avec un noyau 2.0.x.</p>
<p><b>Raison&nbsp;:</b> Le pilote <code>ne.c</code> 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.</p>
<p><b>Solution&nbsp;:</b> 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.</p>
<p><b>Problème&nbsp;:</b> Ma carte PCI clone NE2000 est indiquée
comme étant une NE1000 (une carte 8&nbsp;bits&nbsp;!) au démarrage
ou lorsque je charge le module <code>ne.o</code> sous 2.0.x, et par
conséquent la carte ne fonctionne pas.</p>
<p><b>Raison&nbsp;:</b> 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%). Cela entraîne que la
procédure de détection pense qu'il s'agit de cartes NE1000.</p>
<p><b>Solution&nbsp;:</b> 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à.</p>
<p><b>Problème&nbsp;:</b> 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.</p>
<p><b>Raison&nbsp;:</b> Les spécifications de la puce&nbsp;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é.</p>
<p><b>Solution&nbsp;:</b> 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 <code>linux/drivers/net/</code>,
d'enlever les commentaires qui entourent la ligne contenant
<code>NE_RW_BUGFIX</code> 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&nbsp;/ de puce que
vous avez, si cela vous a aidé. (la même chose peut être effectuée
sur le fichier <code>ne2k-pci.c</code> également).</p>
<p><b>Problème&nbsp;:</b> Le pilote <code>ne2k-pci.c</code> donne
un message d'erreur ressemblant a <code>timeout waiting for Tx
RDC</code> avec une carte NE2000 PCI et ne marche pas.</p>
<p><b>Raison&nbsp;:</b> Votre carte et/ou le lien vers le bus PCI
ne sait pas gérer les optimisations d'E/S du pilote.</p>
<p><b>Solution&nbsp;:</b> 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 <code>ne.c</code> (ou commenter la ligne
<code>#define USE_LONGIO</code> du <code>ne2k-pci.c</code>), ce qui
vous permettrait d'utiliser la carte.</p>
<p><b>Problème&nbsp;:</b> Ma carte ISA Plug and Play NE2000 (telle
que la RealTek 8019) n'est pas détectée.</p>
<p><b>Raison&nbsp;:</b> A l'origine, les spécifications de NE2000
(et par conséquent le pilote linux NE2000) ne supportent pas le
PnP.</p>
<p><b>Solution&nbsp;:</b> 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
<code>/etc/conf.modules</code> telle <code>options ne
io=0xNNN</code> ou <code>0xNNN</code> 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
<code>ether=0,0xNNN,eth0</code> 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</em>. Essayez <code>man
isapnp</code> 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&nbsp;:</p>
<p><a href="http://www.roestock.demon.co.uk/isapnptools/">ISA PNP
Tools</a></p>
<p><b>Problème&nbsp;:</b> Le pilote NE*000 indique `<code>not found
(no reset ack)</code>' (carte non trouvée, pas d'acquittement de la
réinitialisation) pendant la procédure de détection au
démarrage.</p>
<p><b>Raison&nbsp;:</b> Cela est lié au changement précédent. Après
la vérification initiale qu'une&nbsp;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.</p>
<p><b>Solution&nbsp;:</b> Vous pouvez indiquer au pilote que vous
possédez une <em>mauvaise carte</em> (<i>bad card</i>) en utilisant
une valeur héxadécimale <code>0xbad</code> au moment du démarrage
pour le paramètre <code>mem_end</code> (qui n'est normalement pas
utilisé). Vous <em>devez</em> aussi fournir une adresse de base non
nulle pour les ports d'E/S de la carte quand vous utilisez la
valeur <code>0xbad</code>. Par exemple, une carte qui se trouve à
<code>0x340</code> et qui n'acquitte pas la réinitialisation
utilisera quelque chose comme&nbsp;:</p>
<blockquote><code>LILO: linux
ether=0,0x340,0,0xbad,eth0</code></blockquote>
<p>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 <code>bad=0xbad</code> exactement comme vous
indiquez l'adresse d'E/S</p>
<p><b>Problème&nbsp;:</b> Ma carte NE*000 bloque la machine au
premier accès réseau.</p>
<p><b>Raison&nbsp;:</b> 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.</p>
<p><b>Solution&nbsp;:</b> 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 <code>loadlin</code> ou le
`salut-aux-trois-doigts' (<code>Ctrl-Alt-Suppr</code>, 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.</p>
<p><b>Problème&nbsp;:</b> Ma carte Ethernet NE*000 à l'adresse
<code>0x360</code> n'est pas détectée.</p>
<p><b>Raison&nbsp;:</b> Votre carte NE2000 a une largeur d'espace
d'adressage d'E/S de <code>0x20</code>, ce qui lui fait atteindre
la zone utilisée par le port parallèle à
l'adresse&nbsp;<code>0x378</code>. 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
<code>0x370</code> et le contrôleur IDE secondaire aux adresses
<code>0x376--0x377</code>. 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.</p>
<p><b>Solution&nbsp;:</b> Vous pouvez soit déplacer votre carte
vers une adresse d'E/S comme <code>0x280, 0x340, 0x320</code>, ou
compiler votre noyau sans l'option pour l'imprimante parallèle.</p>
<p><b>Problème&nbsp;:</b> Le réseau `disparaît' à chaque fois que
j'imprime quelque chose (NE2000).</p>
<p><b>Raison&nbsp;:</b> 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.</p>
<p><b>Problème&nbsp;:</b> <code>NE*000 ethercard probe at 0xNNN: 00
00 C5 ... not found. (invalid signature yy zz)</code> (carte
Ethernet NE*000 testée à l'adresse 0xNNN: 00 00 C5 ... non trouvée,
signature yy zz non valide)</p>
<p><b>Raison&nbsp;:</b> Avant tout, avez-vous une carte NE1000 ou
NE2000 à l'adresse 0xNNN&nbsp;? Si oui, est-ce que l'adresse
matérielle indiquée ressemble à une adresse valide&nbsp;? Si oui,
alors vous avez un clone NE*000 bas de gamme. Tous les clones
NE*000 sont supposés avoir la valeur <code>0x57</code> 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.</p>
<p><b>Solution&nbsp;:</b> Il existe deux moyens de contourner ce
problème.</p>
<p>Le plus simple est d'utiliser une valeur <code>0xbad</code> pour
le paramètre <code>mem_end</code> 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.</p>
<p>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 (<code>/usr/src/linux/drivers/net/ne.c</code>) 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 <code>0x57</code> aux octets 14 et
15, tels qu'ils sont supposés être.</p>
<p><b>Problème&nbsp;:</b> La machine se bloque pendant le démarrage
après le message&nbsp;`<code>8390...</code>' ou le
message&nbsp;`<code>WD....</code>'. Le fait d'enlever la carte
NE2000 résoud le problème.</p>
<p><b>Solution&nbsp;:</b> Changez votre adresse d'E/S de base pour
une valeur comme <code>0x340</code>. Autre solution, vous pouvez
utiliser l'argument de démarrage ``<code>reserve=</code>'' en
conjonction avec l'argument ``<code>ether=</code>'' pour protéger
la carte des procédures de détection des autres pilotes de
périphériques.</p>
<p><b>Raison&nbsp;:</b> 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.</p>
<p><b>Problème&nbsp;:</b> La machine se bloque pendant la détection
du SCSI au démarrage.</p>
<p><b>Raison&nbsp;:</b> 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 <code>reserve</code> et
<code>ether</code>.</p>
<p><b>Problème&nbsp;:</b> La machine se bloque pendant la détection
de la carte son au démarrage.</p>
<p><b>Raison&nbsp;:</b> Non, en fait c'est pendant la détection
silencieuse du&nbsp;SCSI, et c'est le même problème que
ci-dessus.</p>
<p><b>Problème&nbsp;:</b> Ma carte NE2000 n'est pas détectée au
démarrage. Il n'y a aucun message pendant le démarrage.</p>
<p><b>Solution&nbsp;:</b> 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.</p>
<p>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 <code>lilo</code>, 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 <code>System.map</code> à la
recherche de noms comme <code>ne_probe</code>.</p>
<p>2) Consultez attentivement les messages au démarrage. Est-ce
qu'ils mentionnent une tentative de détection d'une NE2000 comme
`<code>NE*000 probe at 0xNNN: not found (bla bla)</code>' ou est-ce
que la détection se contente d'échouer sans rien dire&nbsp;? Cela
fait une grosse différence. Utilisez <code>dmesg|more</code> 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.</p>
<p>3) Après le démarrage, faites un <code>cat /proc/ioports</code>
et vérifiez que tout l'espace d'E/S que la carte demandera est
vacant. Si vous avez <code>0x300</code> comme adresse de base,
alors le pilote NE2000 demandera la plage d'adresse
<code>0x300-0x31f</code>. 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 <code>lp</code>
(imprimante) réserve <code>0x378</code> ou que le second canal IDE
réserve <code>0x376</code> ce qui empêche le pilote <code>ne</code>
de tester la plage <code>0x360-0x380</code>.</p>
<p>4) Même chose que précédemment avec <code>cat
/proc/interrupts</code>. 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.</p>
<p>5) Si vous séchez encore sur l'échec silencieux du pilote,
éditez-le et ajoutez quelques <code>printk()</code> à 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&nbsp;<code>linux/drivers/net/ne.c</code>
comme&nbsp;:</p>
<hr>
<pre>
    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;
+    }
</pre>
<hr>
<p>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.</p>
<p>6) Vous pouvez aussi récupérer le programme de diagnostic pour
NE2000 sur le site FTP de Don (indiqué dans le <i>Howto</i>) et
regarder s'il est capable de détecter votre carte après que vous
avez démarré Linux. Utilisez l'option `<code>-p 0xNNN</code>' pour
lui dire où regarder pour la carte. (La valeur par défaut est
<code>0x300</code> et il ne va pas regarder ailleurs, à la
différence de la procédure de détection au démarrage.)</p>
<p>Le résultat, s'il trouve une carte, ressemblera à&nbsp;:</p>
<hr>
<pre>
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.
</pre>
<hr>
<p>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&nbsp;bits, et que l'adresse Ethernet
(<code>00:00:c0:b0:05:65</code>) apparaît dans la première ligne,
et que la signature avec le double <code>0x57</code> apparaît à la
fin de la&nbsp;PROM.</p>
<p>Le résultat, s'il n'y a aucune carte installée
en&nbsp;<code>0x300</code>, ressemblera à&nbsp;:</p>
<hr>
<pre>
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.
</pre>
<hr>
<p>Les valeurs <code>0xff</code> 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 <code>0xff</code>
aussi.</p>
<p>7) Essayez de démarrer Linux à chaud depuis une disquette de
démarrage DOS (via <code>loadlin</code>) 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&nbsp;standards) pour initialiser la carte.</p>
<p>8) Essayez le pilote en mode paquet (packet driver)
<code>ne2000.com</code> 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.</p>
<p>Exemple&nbsp;:</p>
<blockquote><code>A:&gt; ne2000 0x60 10 0x300</code></blockquote>
<p>Les arguments sont&nbsp;: 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
<code>pktdrv11.zip</code> -- la version actuelle peut avoir un
numéro plus récent que 11.</p>
<h2><a name="8013-probs"></a> <a name="ss3.5">3.5 Problèmes avec
les cartes SMC Ultra/EtherEZ et WD80*3</a></h2>
<p><b>Problème&nbsp;:</b> Vous obtenez des messages semblables
à&nbsp;:</p>
<pre>
        eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
</pre>
<p><b>Raison&nbsp;:</b> Il y a un problème de mémoire partagée.</p>
<p><b>Solution&nbsp;:</b> Les machines&nbsp;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&nbsp;<code>0xff</code> que donne le message) au lieu de la
mémoire vive de la carte, qui elle contient les données du paquet
reçu.</p>
<p>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&nbsp;ROM' pour cette zone, ou encore de faire
fonctionner le bus ISA plus vite que 8&nbsp;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.</p>
<p><b>Problème&nbsp;:</b> Une carte EtherEZ de SMC ne fonctionne
pas en mode de mémoire non-partagée&nbsp;(PIO).</p>
<p><b>Raison&nbsp;:</b> Les versions les plus anciennes du pilote
Ultra ne pouvaient utiliser la carte que dans le mode de travail à
mémoire partagée.</p>
<p><b>Solution&nbsp;:</b> Le pilote de la version&nbsp;2.0 (et
supérieures) sait aussi utiliser le mode d'E/S
programmées&nbsp;(PIO). Mettez votre noyau à jour vers une
version&nbsp;2.0 ou plus récente.</p>
<p><b>Problème&nbsp;:</b> Une vieille wd8003 et/ou une&nbsp;wd8013
configurable par cavaliers ont toujours la mauvaise&nbsp;IRQ.</p>
<p><b>Raison&nbsp;:</b> 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&nbsp;5 pour
une carte 8&nbsp;bits ou l'IRQ&nbsp;10 pour une carte
16&nbsp;bits.</p>
<p><b>Solution&nbsp;:</b> 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).</p>
<p><b>Problème&nbsp;:</b> Une carte SMC&nbsp;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.</p>
<p><b>Raison&nbsp;:</b> La carte&nbsp;Ultra ressemble beaucoup à
une&nbsp;wd8013, et si le pilote Ultra n'est pas présent dans le
noyau, le pilote&nbsp;wd peut identifier l'Ultra comme étant une
wd8013. Le test de détection de l'Ultra vient avant celui de
la&nbsp;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.</p>
<p><b>Solution&nbsp;:</b> Recompilez le noyau en n'intégrant que
les pilotes dont vous avez besoin. Si vous avez un mélange de
cartes wd&nbsp;et&nbsp;Ultra dans une machine, et que vous utilisez
les modules, chargez le module ultra en premier.</p>
<h2><a name="3com-probs"></a> <a name="ss3.6">3.6 Problèmes avec
des cartes 3Com</a></h2>
<p><b>Problème&nbsp;:</b> La 3c503 prend l'IRQ&nbsp;N, mais
celle-ci est requise par un autre périphérique qui a besoin de
l'IRQ&nbsp;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&nbsp;?</p>
<p><b>Solution&nbsp;:</b> Le pilote 3c503 recherche une ligne d'IRQ
libre dans l'ordre&nbsp;{5,&nbsp;9/2,&nbsp;3,&nbsp;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&nbsp;(<code>ifconfig</code>).</p>
<p>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.</p>
<p>Ce qui suit sélectionne l'IRQ&nbsp;9, adresse de
base&nbsp;<code>0x300</code>, &lt;une valeur ignorée&gt;, et le
port&nbsp;<code>if_port</code> numéro&nbsp;1 (le transceiver
externe).</p>
<blockquote><code>io=0x300 irq=9 xcvr=1</code></blockquote>
<p>Autrement, si le pilote est compilé dans le noyau, vous pouvez
choisir les mêmes valeurs en passant des paramètres <i>via</i>
LILO.</p>
<blockquote><code>LILO: linux
ether=9,0x300,0,1,eth0</code></blockquote>
<p>Ce qui suit sélectionne l'IRQ&nbsp;3, détecte l'adresse de base,
&lt;une valeur ignorée&gt;, et le port par
défaut&nbsp;(<code>if_port</code>) numéro&nbsp;0 (le transceiver
interne).</p>
<blockquote><code>LILO: linux
ether=3,0,0,0,eth0</code></blockquote>
<p><b>Problème&nbsp;:</b> <code>3c503: configured interrupt X
invalid, will use autoIRQ.</code> (3c503: l'interruption X
configurée est invalide, détection automatique de l'IRQ)</p>
<p><b>Raison&nbsp;:</b> La 3c503 ne peut utiliser que l'une des
IRQ&nbsp;5, 2/9, 3&nbsp;ou&nbsp;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 <code>ifconfig</code>), et elle prendra l'une des IRQ&nbsp;5,
2/9, 3&nbsp;ou&nbsp;4.</p>
<p><b>Solution&nbsp;:</b> Utilisez l'une des IRQ&nbsp;valides
données ci-dessus, ou autorisez la détection automatique en ne
précisant aucune ligne d'IRQ.</p>
<p><b>Problème&nbsp;:</b> Le pilote 3c503 fourni n'utilise pas le
port&nbsp;AUI (gros Ethernet). Comment faire pour le choisir au
lieu du port Ethernet&nbsp;fin par défaut&nbsp;?</p>
<p><b>Solution&nbsp;:</b> Le port&nbsp;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
<code>dev-&gt;rmem_start</code> qui n'est actuellement pas
utilisée, donc un paramètre de démarrage comme&nbsp;:</p>
<blockquote><code>LILO: linux
ether=0,0,0,1,eth0</code></blockquote>
devrait fonctionner pour les pilotes compilés dans le noyau.
<p>Pour spécifier le port&nbsp;AUI lorsque vous chargez un module,
ajoutez simplement <code>xcvr=1</code> à la ligne d'options du
module avec vos valeurs de port d'E/S et d'IRQ.</p>
<h2><a name="ss3.7">3.7 Les questions qui ne sont pas spécifiques à
une carte.</a></h2>
<h3>Linux et les cartes Ethernet ISA Plug and Play</h3>
<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 <code>io=</code> dans votre <code>/etc/conf.modules</code>.
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).</p>
<p>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.</p>
<p>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
<code>io=</code>.</p>
<h3>Carte Ethernet non détectée au démarrage.</h3>
<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.</p>
<p>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&nbsp;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.&nbsp;ex.
<code>io=0x340</code>) 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
<code>/etc/conf.modules</code> --&nbsp;lisez <code>man
modprobe</code> pour plus de détails.</p>
<p>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.</p>
<p>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&nbsp;!) 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.</p>
<p>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&nbsp;ou 32&nbsp;bits de largeur. Si votre
carte est positionnée en&nbsp;<code>0x300</code> et qu'elle prend
32&nbsp;octets, alors le pilote demandera la plage d'adresses
<code>0x300-0x31f</code>. 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 <code>cat
/proc/ioports</code> et vérifiez que tout l'espace d'adressage
d'entrée-sortie que la carte demandera est bien disponible.</p>
<p>Autre problème&nbsp;: 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&nbsp;<code>ether=</code> comme il est décrit dans&nbsp;
<a href="#lilo">Passage des arguments Ethernet...</a>. Les pilotes
modulaires peuvent utiliser l'option&nbsp;<code>io=</code> dans le
fichier <code>/etc/conf.modules</code> afin de spécifier une
adresse qui n'est pas testée par défaut.</p>
<h3><code>ifconfig</code> indique la mauvaise adresse d'E/S pour la
carte.</h3>
<p>Non, ce n'est pas vrai. C'est vous qui l'interprétez de manière
erronée. Ce n'est&nbsp;<em>pas</em> une erreur, et les nombres
indiqués sont corrects. Ce qu'il se passe, c'est que certaines
cartes à base de&nbsp;8390 (wd80x3, smc-ultra, etc.) sont telles
que la puce&nbsp;8390 se trouve décalée par rapport au premier
port&nbsp;d'E/S affecté. Il s'agit de la valeur stockée
dans&nbsp;<code>dev-&gt;base_addr</code>, qui est celle que
<code>ifconfig</code> indique. Si vous souhaitez voir l'intervalle
complet d'adresses de ports que votre carte utilise, vous devriez
essayer <code>cat /proc/ioports</code> qui vous donnera le nombre
que vous attendez.</p>
<h3>Une machine PCI détecte la carte mais la procédure de test du
pilote échoue.</h3>
<p>Certains BIOS&nbsp;PCI peuvent ne pas activer toutes les
cartes&nbsp;PCI lors de l'allumage de la machine, spécialement si
l'option `PNP&nbsp;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.</p>
<h3>Des cartes ISA à mémoire partagée ne fonctionnent pas dans une
machine PCI (<code>0xffff</code>)</h3>
<p>Ce problème se révèle habituellement sous la forme d'une série
de valeurs&nbsp;<code>0xffff</code> en lecture. Aucune carte à
mémoire partagée de quelque type que ce soit ne fonctionnera dans
une machine&nbsp;PCI à moins que vous n'ayez configuré correctement
le BIOS&nbsp;PCI (<code>PCI ROM BIOS/CMOS SETUP</code> 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&nbsp;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&nbsp;wd8013 et la SMC&nbsp;Ultra, changez la
taille de sa valeur par défaut (`Disabled', désactivé) à une valeur
de 16&nbsp;Ko, et changez l'adresse de base en prenant l'adresse de
base de mémoire partagée qui correspond à votre carte.</p>
<h3>On dirait que ma carte envoie des données, mais elle ne reçoit
jamais rien.</h3>
<p>Faites un <code>cat /proc/interrupts</code>. 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.</p>
<h3>Asynchronous Transfer Mode (ATM)</h3>
<p>Werner Almesberger s'est préoccupé de la disponibilité d'ATM
pour Linux. Il a travaillé avec la carte&nbsp;ENI155p d'Efficient
Networks ( <a href="http://www.efficient.com/">Efficient
Networks</a>) et la carte&nbsp;ZN1221 de Zeitnet ( <a href=
"http://www.zeitnet.com/">Zeitnet</a>).</p>
<p>Werner dit que le pilote de la&nbsp;ENI155p est relativement
stable, tandis que celui de la&nbsp;ZN1221 n'est actuellement pas
terminé.</p>
<p>Consultez les dernières informations et les mises à jour à l'URL
suivante&nbsp;:</p>
<blockquote><a href="http://lrcwww.epfl.ch/linux-atm/">Linux et
ATM</a></blockquote>
<h3>Support de l'Ethernet Gigabit</h3>
<p>Où en est le support Ethernet Gigabit pour Linux&nbsp;?</p>
<p>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&nbsp;:</p>
<blockquote>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html</code></blockquote>
<p>Le pilote <code>acenic.c</code> 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é.</p>
<h3>FDDI</h3>
<p>Qu'en est-il de FDDI sous Linux&nbsp;?</p>
<p>Cela fonctionne. Larry Stefani a écrit un pilote pour la
version&nbsp;2.0 du noyau pour les cartes&nbsp;DEFEA (FDDI EISA)
et&nbsp;DEFPA (FDDI PCI) de&nbsp;DEC (Digital Equipment
Corporation). Il a été inclus dans la version&nbsp;2.0.24 du noyau.
Néanmoins, ce sont les seules cartes qui fonctionnent sous Linux
actuellement.</p>
<h3>Full Duplex</h3>
<p>Est-ce que le mode Full&nbsp;Duplex me donnera
20&nbsp;Mbit/s&nbsp;? Est-ce que Linux sait faire du
Full&nbsp;Duplex&nbsp;?</p>
<p>Cameron Spitzer écrit ce qui suit à propos des cartes
Full&nbsp;Duplex 10Base-T&nbsp;:</p>
<p>``Si vous connectez une carte Full Duplex à un hub (NDT&nbsp;:
un switch) Full&nbsp;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.</p>
<p>Le Full&nbsp;Duplex 10Base-2 ou 10Base-5 (coaxial fin et gros
coaxial) ne peut pas exister. Le mode Full&nbsp;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&nbsp;:
le réseau ne fonctionnerait pas si c'était le cas.</p>
<p>Par contre, 10Base-T (l'interface&nbsp;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&nbsp;Mbit/s.''</p>
<p>Donc, comme vous pouvez voir, vous ne serez encore capable de
recevoir ou de transmettre qu'à 10&nbsp;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.</p>
<h3>Les machines SMP et les cartes Ethernet</h3>
<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&nbsp;: 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 <code>spin_lock</code> 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&nbsp;:</p>
<p>Dans la version 2.0 des noyaux, seul un processeur était
autorisé a passer en `mode noyau' (ex&nbsp;: 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&nbsp;!)</p>
<p>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.</p>
<p>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&nbsp;: un
processeur peut s'occuper du réseau alors qu'un autre peut écrire
sur un disque au même moment.</p>
<p>Ok, avec tout cela en tête, voici deux petits problèmes&nbsp;:
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
<code>cat /proc/net/dev</code>). 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.</p>
<p>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&nbsp;!) processeurs essaieront de faire plus
d'une de ces opérations au même moment.</p>
<p>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. [Note technique&nbsp;: 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 <code>irqsave</code> et qu'ils sont tenus fermés pour
un long moment.]</p>
<p>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&nbsp;: un verrou global sur le pilote ne serait pas nécessaire
si quelques verrous protégeant quelques registres/réglages
critiques suffisent).</p>
<p>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.</p>
<p>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.</p>
<h3>Cartes Ethernet pour Linux sur carte-mère PCI Alpha/AXP</h3>
<p>En ce qui concerne les versions&nbsp;2.0, seules les
cartes&nbsp;3C509, depca, de4x5, lance32, et tous les pilotes
pour&nbsp;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&nbsp;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.</p>
<p>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&nbsp;:</p>
<p>- multiplier toutes les valeurs relatives à des
<code>jiffies</code> par <code>HZ/100</code> pour prendre en compte
la valeur différente de <code>HZ</code> utilisée par l'Alpha.
(c'est-à-dire que <code>timeout=2;</code> devient
<code>timeout=2*HZ/100;</code>)</p>
<p>- remplacer tout déréférencement de pointeur en mémoire d'E/S
(640k&nbsp;à 1Mo) par les appels <code>readb() writeb() readl()
writel()</code> appropriés, comme le montre cet exemple&nbsp;:</p>
<hr>
<pre>
-       int *mem_base = (int *)dev-&gt;mem_start;
-       mem_base[0] = 0xba5eba5e;
+       unsigned long mem_base = dev-&gt;mem_start;
+       writel(0xba5eba5e, mem_base);
</pre>
<hr>
<p>- remplacer tous les appels à&nbsp;<code>memcpy()</code> qui ont
des adresses mémoire sur la plage&nbsp;d'E/S comme source ou comme
destination par un appel à&nbsp;<code>memcpy_fromio()</code> ou
à&nbsp;<code>memcpy_toio()</code> selon le cas.</p>
<p>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
<code>linux/Documentation/IO-mapping.txt</code> qui est présent
dans les noyaux récents.</p>
<h3>L'Ethernet et Linux sur les SUN/Sparc.</h3>
<p>Pour les dernières informations à propos des Sparc, essayez donc
l'URL suivante&nbsp;:</p>
<p><a href="http://www.geog.ubc.ca/sparc">Linux Sparc</a></p>
<p>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
<code>hw</code> de <code>ifconfig</code> pour assigner une unique
adresse MAC.</p>
<p>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.</p>
<h3>L'Ethernet, Linux et les autres architectures.</h3>
<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&nbsp;!)</p>
<h3>Relier deux 10 et 100 BaseT sans hub</h3>
<p>Est-ce que je peux relier deux systèmes basés sur du
10/100BaseT&nbsp;(RJ45) sans utiliser de hub&nbsp;?</p>
<p>Vous pouvez relier facilement deux machines, mais pas plus que
cela, sans boîtier supplémentaire. Consultez la section&nbsp;
<a href="#utp">Paire torsadée</a> qui explique comment faire.</p>
<p>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.</p>
<h3>SIOCSIFxxx: No such device</h3>
<p>J'obtiens un nombre impressionnant de messages
`<code>SIOCSIFxxx: No such device</code>' au démarrage, suivis par
un `<code>SIOCADDRT: Network is unreachable</code>'. Qu'est-ce qui
ne va pas&nbsp;?</p>
<p>Votre périphérique Ethernet n'a pas été détecté pendant le
démarrage&nbsp;/ lors de l'insertion du module, et lorsque
<code>ifconfig</code>&nbsp;et <code>route</code> sont exécutés, ils
n'ont aucun périphérique avec lequel travailler. Utilisez
<code>dmesg | more</code> 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.</p>
<h3>SIOCSFFLAGS: Try again</h3>
<p>J'obtiens `<code>SIOCSFFLAGS: Try again</code>' lorsque
j'exécute <code>ifconfig</code> -- Euh..&nbsp;?</p>
<p>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&nbsp;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 <code>cat
/proc/interrupts</code> pour voir quelles interruptions sont
actuellement <em>en cours d'utilisation</em>. La plupart des
pilotes de carte Ethernet sous Linux ne prennent l'IRQ que
lorsqu'ils sont ouverts via `<code>ifconfig</code>'. 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 (<i>Try
again</i> en anglais) avec&nbsp;<code>ifconfig</code>.</p>
<h3>Utilisation de `ifconfig' et message `Link UNSPEC with HW-addr
of 00:00:00:00:00:00'</h3>
<p>Lorsque j'utilise <code>ifconfig</code> sans argument, il
indique <code>Link UNPSEC</code> (au lieu de `Ethernet 10Mbs') et
il dit aussi que mon adresse physique est à zéro.</p>
<p>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'<code>ifconfig</code>, ou simplement
ignorer le problème. Le noyau connaît votre adresse physique, donc
le fait que <code>ifconfig</code> ne puisse pas la lire n'est pas
vraiment important.</p>
<p>Vous pourrez aussi obtenir des informations étranges si le
programme <code>ifconfig</code> que vous utilisez est beaucoup plus
vieux que votre noyau.</p>
<h3>Nombre faramineux d'erreurs en réception (RX Errors) et en
transmission (TX Errors)</h3>
<p>Quand j'exécute <code>ifconfig</code> 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&nbsp;?</p>
<p>Regardez de nouveau. <code>ifconfig</code> indique&nbsp;:
<code>RX packets</code> <i>gros nombre</i> <b>BLANC</b>
<code>errors 0</code> <b>BLANC</b> <code>dropped 0</code>
<b>BLANC</b> <code>overrun 0</code>. Même chose pour la colonne
avec <code>TX</code>. 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 <code>cat /proc/net/dev</code> à la place.</p>
<h3>Liens dans <code>/dev/</code> pour cartes Ethernet</h3>
<p>J'ai <code>/dev/eth0</code> qui est un lien vers
<code>/dev/</code>xxx. Est-ce que c'est bon&nbsp;?</p>
<p>Contrairement à ce que vous avez entendu dire, les fichiers dans
<code>/dev/*</code> ne sont pas utilisés. Vous pouvez détruire tous
les <code>/dev/wd0, /dev/ne0</code> et ce qui y ressemble.</p>
<h3>Linux et les ``trailers'' (amorces)</h3>
<p>Dois-je désactiver les ``trailers'' quand je `ifconfig'ure ma
carte Ethernet&nbsp;?</p>
<p>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é.</p>
<p>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.</p>
<h3>Accès direct au périphérique Ethernet</h3>
<p>Comment puis-je avoir accès directement au périphérique Ethernet
sous Linux, sans avoir à passer par TCP/IP et ses
copains&nbsp;?</p>
<hr>
<pre>
        int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
</pre>
<hr>
<p>Ceci vous donne une socket qui peut recevoir tous les types de
protocoles. Utilisez l'appel <code>recvfrom()</code> sur cette
socket, cela remplira la structure <code>sockaddr</code> avec le
type de périphérique dans le champ <code>sa_family</code> et le nom
du périphérique dans le tableau <code>sa_data</code>. Je ne sais
pas qui a inventé <code>SOCK_PACKET</code> 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
<code>sendto()</code>.</p>
<p>Bien entendu, vous devez être root pour pouvoir faire l'ensemble
de ces opérations.</p>
<h2><a name="perf"></a> <a name="s4">4. Trucs et astuces à propos
des performances</a></h2>
<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.</p>
<p>Le programme <code>ttcp.c</code> est un bon test pour mesurer la
vitesse de transfert brute. Un autre truc classique est de faire un
<code>ftp&gt; get mon_gros_fichier /dev/null</code> où
<code>mon_gros_fichier</code> fait plus d'un&nbsp;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
<code>/dev/null</code> plutôt que vers le disque.</p>
<h2><a name="ss4.1">4.1 Concepts génériques</a></h2>
<p>Même une carte 8&nbsp;bits est capable de recevoir des paquets
qui se suivent (<i>back-to-back paquets</i> 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.</p>
<p>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&nbsp;!</p>
<p>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.</p>
<p>La plupart des cartes 8&nbsp;bits ont un tampon de 8&nbsp;Ko, et
la plupart des cartes 16&nbsp;bits ont un tampon de 16&nbsp;Ko. La
plupart des pilotes sous Linux réserveront 3&nbsp;Ko de ce tampon
(pour deux tampons de transmission), laissant 5&nbsp;Ko d'espace de
réception pour une carte 8&nbsp;bits. Cela ne laisse de la place
que pour 3 paquets Ethernet de pleine taille (1500 octets).</p>
<h2><a name="ss4.2">4.2 La vitesse des cartes et du bus
ISA</a></h2>
<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 --&nbsp;c'est-à-dire la vitesse
du bus ISA. (Si le processeur est un 386sx-16 poussif, cela jouera
aussi un rôle.)</p>
<p>La vitesse d'horloge recommandée pour un bus ISA est de
8&nbsp;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.</p>
<p>Par exemple, voici quelques vitesses de réception mesurées par
le programme TTCP sur un 486 à 40&nbsp;MHz, avec une carte
8&nbsp;bits WD8003EP, pour des vitesses différentes du bus ISA.</p>
<pre>
        Vitesse du bus ISA (MHz)        TTCP - réception (Ko/s)
        ------------------------        -----------------------
        6.7                             740
        13.4                            970
        20.0                            1030
        26.7                            1075
</pre>
<p>Vous auriez du mal à faire mieux que 1075&nbsp;Ko/s avec
<em>n'importe quelle</em> carte Ethernet 10&nbsp;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&nbsp;MHz. (De même, certains systèmes&nbsp;PCI
fixent la vitesse du bus ISA à 8&nbsp;MHz, afin que l'utilisateur
final n'ait pas la possibilité de pouvoir l'augmenter.)</p>
<p>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.)</p>
<p>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&nbsp;MHz,
et de tester attentivement que tous les périphériques ISA
fonctionnent correctement après toute augmentation de vitesse.</p>
<h2><a name="ss4.3">4.3 Modifier la fenêtre de réception
TCP</a></h2>
<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&nbsp;Ko, ce qui signifie qu'un
ordinateur rapide situé sur le même sous-réseau que vous pourra
vous inonder de 32&nbsp;Ko de données sans s'arrêter pour regarder
si vous en avez reçu le moindre morceau.</p>
<p>Les versions récentes de la commande <code>route</code> 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&nbsp;:</p>
<hr>
<pre>
        route add &lt;comme_d_habitude&gt; ... window &lt;largeur_de_fenetre&gt;
</pre>
<hr>
où <code>largeur_de_fenetre</code> est la largeur de la fenêtre que
vous voulez utiliser (en octets). Une carte 8&nbsp;bits 3c503 sur
un bus ISA fonctionnant à une vitesse de 8&nbsp;MHz ou moins
tournera correctement avec une fenêtre d'environ 4&nbsp;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 <code>cat
/proc/net/dev</code> qui affichera si des pertes de paquets ou des
surcharges sont apparues.
<h2><a name="ss4.4">4.4 Augmenter les performances de NFS</a></h2>
<p>Des personnes ont remarqué que l'utilisation de cartes
8&nbsp;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).</p>
<p>La raison possible de tout cela pourrait être la différence
entre la taille des tampons des cartes 8&nbsp;bits et celle des
cartes 16&nbsp;bits. La taille maximale d'un paquet Ethernet est
d'environ 1500 octets. Maintenant que nous faisons du NFS, des
paquets NFS de 8&nbsp;Ko vont arriver sous la forme de 6 paquets de
taille maximale à la queue-leu-leu. Ni les cartes 8&nbsp;bits ni
les cartes 16&nbsp;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&nbsp;bits nécessitent un
cycle du bus ISA supplémentaire pour chaque transfert n'aide pas
beaucoup, par ailleurs. Ce que vous <em>pouvez</em> faire si vous
avez une carte 8bits est soit de diminuer la taille de transfert
NFS à 2&nbsp;Ko (voire 1&nbsp;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&nbsp;MHz (sans autre charge système) peut soutenir une réception
de taille importante avec une taille NFS de 2&nbsp;Ko, mais pas
à&nbsp;4&nbsp;Ko, auquel cas les performances étaient dégradées
d'un facteur trois.</p>
<p>D'un autre coté, si l'option par défaut est d'utiliser des blocs
de 1&nbsp;Ko, et que vous avez au moins une carte ISA 16&nbsp;bits,
vous aurez certainement de meilleures performances en passant a
4&nbsp;Ko (ou même 8&nbsp;Ko).</p>
<h2><a name="card-intro"></a> <a name="s5">5. Informations
spécifiques par distributeur/constructeur/modèle</a></h2>
<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é'.</p>
<p>`Supporté' signifie qu'un pilote existe pour cette carte, que de
nombreuses personnes en sont contentes et qu'il semble fiable.</p>
<p>`Partiellement supporté' signifie qu'un pilote existe, mais que
l'une au moins des conditions suivantes est vraie&nbsp;:
(1)&nbsp;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)&nbsp;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&nbsp;(2) est préférable à la
situation&nbsp;(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&nbsp;?'') lorsque vous lancerez
<code>make config</code>.</p>
<p>`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.</p>
<p>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&nbsp;!!!) 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).</p>
<p>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 <code>alias eth0 pilote</code> dans votre fichier de
configuration <code>/etc/conf.modules</code>.</p>
<h2><a name="3com"></a> <a name="ss5.1">5.1 3Com</a></h2>
<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&nbsp; <a href="#3com-tech">Informations techniques de
3Com</a> pour plus d'informations sur la façon d'obtenir de 3Com
des documents techniques.</p>
<p>Notez aussi que vous pouvez éventuellement consulter le site FTP
de 3Com qui recèle diverses gâteries&nbsp;:
<code>ftp.3Com.com</code>.</p>
<p>Pour ceux qui consultent ce document sur le WWW, vous pouvez
aussi essayer leur site WWW (<code>www.3com.com</code>).</p>
<h3><a name="3c501"></a> 3c501</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c501</p>
<p>Cette carte 8&nbsp;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.</p>
<p>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.</p>
<p>Les IRQ automatiques fonctionnent, le DMA n'est pas utilisé, la
détection automatique ne teste que <code>0x280</code> et
<code>0x300</code>, et le niveau de débogage est indiqué dans le
troisième argument passé au démarrage.</p>
<p>Encore une fois, l'utilisation d'une 3C501 est <em>fortement
déconseillée</em>&nbsp;! Encore plus avec un noyau IP `multicast',
puisque vous allez aboutir à un arrêt pendant que vous écoutez
<em>chacun</em> des paquets `multicast'. Lisez les commentaires au
début du code source pour plus de détails.</p>
<h3><a name="3c503"></a> EtherLink II, 3c503, 3c503/16</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c503 (+8390)</p>
<p>La 3c503 ne possède pas de mémoire reprogrammable pour stocker
sa configuration (un ``EEPROM setup'')&nbsp;; 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' (<i>disable</i> en anglais) à
moins d'avoir une PROM de démarrage.</p>
<p>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&nbsp;!). 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.</p>
<p>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&nbsp;: il utilise la
première ligne d'interruption disponible parmi&nbsp;{5,2/9,3,4}, en
choisissant à chaque fois que la carte est
<code>ifconfig</code>urée. (Les anciennes versions du pilote
sélectionnaient l'IRQ au moment du démarrage). L'appel
<code>ioctl()</code> dans `ifconfig' retournera <code>EAGAIN</code>
si aucune ligne d'IRQ n'est disponible à ce moment-là.</p>
<p>Des problèmes classiques que les gens ont avec la 3c503 sont
abordés dans&nbsp; <a href="#3com-probs">Problèmes avec...</a>.</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<p>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.</p>
<h3><a name="3c505"></a> EtherLink plus, 3c505</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c505</p>
<p>Il s'agit d'un pilote qui avait été écrit par Craig Southeren
<code>geoffw@extro.ucc.su.oz.au</code>. 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&nbsp; <a href="#alfa">Pilotes alpha</a> pour des
informations importantes à propos de l'utilisation de pilotes
Ethernet en phase de test `alpha' sous Linux.</p>
<p>Vous devriez aussi lire le fichier
<code>/usr/src/linux/drivers/net/README.3c505</code> si vous
comptez utiliser une de ces cartes. Il contient diverses options
que vous pouvez activer ou désactiver.</p>
<h3><a name="3c507"></a> EtherLink-16, 3c507</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c507</p>
<p>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'.</p>
<p>Consultez&nbsp; <a href="#alfa">Pilotes alpha</a> pour des
informations importantes concernant l'utilisation de pilotes en
phase de test `alpha' sous Linux.</p>
<h3><a name="3c509"></a> EtherLink III, 3c509 / 3c509B</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c509</p>
<p>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.</p>
<p>La 3c509 d'origine avait un petit tampon mémoire pour les
paquets (4&nbsp;Ko au total, 2&nbsp;en réception et 2&nbsp;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 <code>man
hdparm</code>) et&nbsp;/&nbsp;ou augmenter la vitesse de votre
bus&nbsp;ISA de façon à ce que les transferts&nbsp;IDE se terminent
plus tôt.</p>
<p>Le modèle plus récent, la 3c509B, possède 8&nbsp;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.</p>
<p>Les utilisateurs de 3c509B devraient utiliser soit l'utilitaire
DOS fourni afin de désactiver le `<i>plug and play</i>',
<em>et</em> de déterminer le support de sortie dont ils ont besoin.
Le pilote Linux <em>n'est pas</em> capable aujourd'hui d'utiliser
la fonctionnalité de détection automatique du support physique,
donc vous <em>devez</em> sélectionner 10Base-T ou 10Base-2 ou AUI.
Notez que pour arrêter totalement le PnP, vous devrez faire un
<code>3C5X9CFG /PNP:DISABLE</code> et ensuite, éteindre et rallumer
la machine pour que cela prenne effet.</p>
<p>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&nbsp;; 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.''</p>
<p>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
<code>ID_PORT</code> (port <code>0x100</code> jusqu'à
<code>0x1ff</code> par intervalle de <code>0x10</code>). 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</em> <code>eth0</code>. 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
<code>ether=0,0,ethN</code> 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.</p>
<p>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
<code>0x3c509</code> dans le champ (inutilisé) de l'adresse mémoire
pour obliger la détection à réussir.</p>
<h3><a name="cork"></a> 3c515</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c515</p>
<p>Il s'agit de l'offre 100&nbsp;Mb/s de 3Com en ISA, nom de code
``<i>CorkScrew</i>'' (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''&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html">Vortex</a></blockquote>
<h3><a name="3c523"></a> 3c523</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c523</p>
<p>Cette carte pour bus&nbsp;MCA utilise la puce i82586, et Chris
Beauregard a modifié le pilote <code>ni52</code> pour qu'il
fonctionne avec ces cartes. Le pilote correspondant peut être
trouvé dans l'arborescence des sources des noyaux&nbsp;2.2.</p>
<p>Plus de détails sont fournis sur la page MCA pour Linux à
<code>http://glycerine.cetmm.uni.edu/mca/</code></p>
<h3><a name="3c527"></a> 3c527</h3>
<p>Statut&nbsp;: Non supporté</p>
<p>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.</p>
<h3><a name="3c529"></a> 3c529</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c509</p>
<p>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.</p>
<p>On peut trouver plus de détails sur la page MCA pour Linux à
l'adresse <code>http://glycerine.cetmm.uni.edu/mca/</code>.</p>
<h3>3c562</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c589 (distribué
séparément)</p>
<p>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.</p>
<p>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.</p>
<p>Consultez&nbsp; <a href="#pcmcia">PCMCIA</a> pour en savoir plus
sur les jeux de puces PCMCIA, les activateurs de sockets, etc.</p>
<h3>3c575</h3>
<p>Statut&nbsp;: Inconnu</p>
<p>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.</p>
<h3><a name="3c579"></a> 3c579</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c509</p>
<p>La version EISA de la 509. La version EISA actuelle utilise la
même puce de largeur 16&nbsp;bits plutôt qu'une interface
32&nbsp;bits, et les performances ne sont donc pas époustouflantes.
Le code de détection EISA a été ajouté dans <code>3c509.c</code>
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&nbsp;3c509 pour des informations sur le pilote.</p>
<h3><a name="3c589"></a> 3c589 / 3c589B</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c589</p>
<p>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.</p>
<p>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 <a href=
"#pcmcia">Support PCMCIA</a> pour plus d'informations sur les
pilotes, les chipsets supportés, les activateurs de sockets,
etc.</p>
<h3><a name="vortex"></a> 3c590 / 3c595</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c59x</p>
<p>Ces cartes ``Vortex'' sont destinées aux machines à bus PCI, la
3c590 constituant l'offre à 10&nbsp;Mb/s de 3Com et la 3c595 celle
à 100&nbsp;Mb/S. Notez aussi que vous pouvez utiliser la 595 comme
une 590 (c'est-à-dire en mode 10&nbsp;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&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html">Vortex</a></blockquote>
<p>Notez qu'il existe en fait deux cartes 3c590, des modèles des
premiers temps ayant 32&nbsp;Ko de mémoire, et des plus récents qui
n'en ont que 8&nbsp;. 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&nbsp;Ko. Les cartes 3c595 ont 64&nbsp;Ko, car vous ne
pouvez pas faire grand-chose avec seulement 8&nbsp;Ko de mémoire
vive à 100&nbsp;Mb/s&nbsp;!</p>
<p>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.</p>
<p>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&nbsp;:</p>
<p><code>echo subscribe | /bin/mail
linux-vortex-request@cesdis.gsfc.nasa.gov</code></p>
<h3>3c592 / 3c597</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c59x</p>
<p>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.</p>
<h3>3c900 / 3c905 / 3c905B</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c59x</p>
<p>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.</p>
<p>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 <code>3c59x.c</code> mis à jour sur le site
de Donald&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html">Vortex</a></blockquote>
<p>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&nbsp;:</p>
<p><code>echo subscribe | /bin/mail
linux-vortex-request@cesdis.gsfc.nasa.gov</code></p>
<h3>3c985</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: acenic</p>
<p>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.</p>
<h2><a name="accton"></a> <a name="ss5.2">5.2 Accton</a></h2>
<h3>Accton MPX</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne (+8390)</p>
<p>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.</p>
<h3>Accton EN1203, EN1207, EtherDuo-PCI</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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.</p>
<p>Consultez&nbsp; <a href="#dec-21040">DEC 21040</a> pour plus
d'informations sur ces cartes, et la situation actuelle du
pilote.</p>
<h3>Adaptateur Accton EN2209 pour port parallèle (EtherPocket)</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: ?</p>
<p>Un pilote pour ces adaptateurs sur port parallèle est disponible
mais ne fait pas encore partie des sources des noyaux 2.0
ou&nbsp;2.1. Vous pouvez obtenir ce pilote sur&nbsp;:</p>
<blockquote>
<code>http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html</code></blockquote>
<h3>Accton EN2212 PCMCIA</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: ?</p>
<p>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.</p>
<h2><a name="allied-telesis"></a> <a name="ss5.3">5.3 Allied
Telesyn/Telesis</a></h2>
<h3><a name="at-1500"></a> AT1500</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: lance</p>
<p>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.</p>
<p>La sélection du DMA et des informations sur la numérotation de
la puce se trouvent dans&nbsp; <a href="#lance">AMD LANCE</a>.</p>
<p>Plus d'informations techniques sur les cartes Ethernet basées
sur l'AMD LANCE sont disponibles dans&nbsp; <a href=
"#amd-notes">Notes sur l'AMD...</a>.</p>
<h3><a name="at1700"></a> AT1700</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: at1700</p>
<p>Notez que pour accéder à ce pilote lors du <code>make
config</code> 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 à&nbsp;:
<code>http://www.cc.hit-u.ac.jp/nagoya/at1700/</code></p>
<p>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.</p>
<p>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.</p>
<p>La puce Fujitsu utilisée sur l'AT1700 a un défaut de
conception&nbsp;: 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.</p>
<p>Certaines séries de production de l'AT1700 ont un autre
problème&nbsp;: 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.</p>
<p>Certaines séries de l'AT1700 ont un autre problème&nbsp;: 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.</p>
<h3><a name="at2450"></a> AT2450</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>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&nbsp;
<a href="#lance">AMD LANCE</a>.</p>
<p>Plus d'informations techniques sur les cartes Ethernet basées
sur l'AMD LANCE sont disponibles dans&nbsp; <a href=
"#amd-notes">Notes sur l'AMD...</a>.</p>
<h3>AT1500</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
rtl8139</p>
<p>Cette carte utilise la puce Realtek 8139, référez vous à la
section <a href="#rtl8139">Realtek 8139</a></p>
<h3><a name="at2540"></a> AT2540FX</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
eepro100</p>
<p>Cette carte utilise une puce i82557, et par conséquent,
pourrait&nbsp;/&nbsp;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.</p>
<h2><a name="amd"></a> <a name="ss5.4">5.4 AMD / Advanced Micro
Devices</a></h2>
<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.</p>
<h3><a name="lance"></a> AMD LANCE (7990, 79C960/961/961A,
PCnet-ISA)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: lance</p>
<p>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).</p>
<p>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&nbsp; <a href="#at-1500">AT1500</a>), et la
NE1500/2100 (voir&nbsp; <a href="#ne1500">NE1500</a>) utilisent ces
puces.</p>
<p>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&nbsp;79c90, avec
tout le support matériel complémentaire requis, ce qui permet de
monter une solution Ethernet en une seule puce. La&nbsp;79c961
(PCnet-ISA+) est une version ``Plug and Play'', sans cavaliers, de
la&nbsp;960. La dernière puce des séries&nbsp;ISA est
la&nbsp;79c961A (PCnet-ISA&nbsp;II), qui ajoute des capacités de
<i>full duplex</i>. Toutes les cartes comportant une de ces puces
devraient fonctionner avec le pilote <code>lance.c</code>, à
l'exception de très vieilles cartes qui utilisent la&nbsp;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&nbsp;DMA.</p>
<p>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.</p>
<p>Notez aussi que le pilote ne cherche une carte valide qu'à ces
adresses&nbsp;: <code>0x300, 0x320, 0x340, 0x360</code>, et qu'une
adresse fournie par un argument de démarrage <code>ether=</code>
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.</p>
<p>Le pilote fonctionnera encore correctement, même si plus de
16&nbsp;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&nbsp;Mo est copiée dans
un tampon en-dessous de la limite avant d'être remis à la carte
pour transmission).</p>
<p>Le canal DMA peut être configuré avec les bits (inutilisés en
dehors de ça) de la valeur de <code>dev-&gt;mem_start</code> (aussi
connue comme <code>PARAM_1</code> (voir&nbsp; <a href=
"#ether">PARAM_1</a>). S'il n'est pas fixé, il est testé en
activant chaque canal DMA tour à tour et en regardant si
l'initialisation réussit.</p>
<p>La carte HP-J2405A est une exception&nbsp;: avec cette carte, il
est facile de lire les valeurs stockées en EEPROM pour l'IRQ et le
DMA.</p>
<p>Voir&nbsp; <a href="#amd-notes">Notes on AMD...</a> pour plus
d'informations sur ces puces.</p>
<h3><a name="pcnet-32"></a> AMD 79C965 (PCnet-32)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>Il s'agit de la PCnet-32 -- une version 32&nbsp;bits, à contrôle
de bus, de la puce&nbsp;LANCE originelle pour les systèmes VLB
(Vesa Local Bus) et à bus local. Bien que ces puces puissent être
utilisée avec le pilote <code>lance.c</code> standard, une version
32&nbsp;bits (<code>pcnet32.c</code>) est aussi disponible,
laquelle n'a pas à se préoccuper des limitations à 16&nbsp;Mo liées
au bus&nbsp;ISA.</p>
<h3><a name="pcnet-pci"></a> AMD 79C970/970A (PCnet-PCI)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>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&nbsp;970A ajoute le support du mode <i>full duplex</i>
ainsi que d'autres fonctionnalités par rapport à la conception
d'origine de la&nbsp;970.</p>
<p>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.</p>
<h3>AMD 79C971 (PCnet-FAST)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>Il s'agit de la puce 100&nbsp;Mbits d'AMD pour les
systèmes&nbsp;PCI, qui comporte elle aussi le mode <i>full
duplex</i>. Elle a été introduite en juin 1996 sur le marché.</p>
<h3>AMD 79C972 (PCnet-FAST+)</h3>
<p>Statut&nbsp;: Inconnu, Nom du pilote&nbsp;: pcnet32</p>
<p>Devrait marcher exactement comme la '971, mais reste à confirmer
quand même.</p>
<h3>AMD 79C974 (PCnet-SCSI)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>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</em>, pas du
<i>SCSI-HOWTO</i>.</p>
<h2><a name="ansel"></a> <a name="ss5.5">5.5 Ansel
Communications</a></h2>
<h3>AC3200 EISA</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
ac3200</p>
<p>Notez que pour accéder à ce pilote lors du <code>make
config</code> 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.</p>
<p>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&nbsp; <a href=
"#alfa">Pilotes `alpha'</a> dans le présent document pour des
informations importantes concernant les pilotes `alpha'.</p>
<p>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.</p>
<p>Si vous avez l'intention d'utiliser ce pilote comme module
chargeable, vous devriez lire&nbsp; <a href="#modules">Utilisation
des pilotes Ethernet comme modules</a> pour des informations
spécifiques aux modules.</p>
<h2><a name="ss5.6">5.6 Apricot</a></h2>
<h3>Apricot Xen-II On Board Ethernet</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: apricot</p>
<p>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
<code>0x300</code>. En consultant le source du pilote, il apparaît
que l'IRQ est matériellement fixée à 10.</p>
<p>Les premières versions du pilote avaient une tendance à croire
que tout ce qui vivait en <code>0x300</code> était un adaptateur
réseau Apricot. Depuis, l'adresse matérielle est testée afin
d'éviter ces détections erronées.</p>
<h2><a name="arcnet"></a> <a name="ss5.7">5.7 Arcnet</a></h2>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: arcnet (arc-rimi,
com90xx, com20020)</p>
<p>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.</p>
<p>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&nbsp;!)</p>
<p>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.</p>
<p>Vous pouvez envoyer rapports de bogues et comptes-rendus
victorieux concernant Arcnet à&nbsp;:</p>
<p><code>apenwarr@foxnet.net</code></p>
<p>Le noyau standard comporte des fichiers d'information pour la
configuration des cavaliers et des aides plus générales.</p>
<p>Le pilote est également censé fonctionner avec les cartes ARCnet
100&nbsp;Mb/s&nbsp;!</p>
<h2><a name="ss5.8">5.8 AT&amp;T</a></h2>
<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.</p>
<h3>AT&amp;T T7231 (LanPACER+)</h3>
<p>Statut&nbsp;: Non supporté</p>
<p>Ces cartes StarLAN utilisent une interface similaire à la puce
i82586. A une époque, Matthijs Melchior
(<code>matthijs.n.melchior@att.com</code>) 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.</p>
<h2><a name="boca"></a> <a name="ss5.9">5.9 Boca Research</a></h2>
<p>Oui, ils font autre chose que des cartes séries multi-ports.
:-)</p>
<h3><a name="boca-ben"></a> Boca BEN (ISA, VLB; PCI)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32, lance</p>
<p>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&nbsp;(407)&nbsp;241-8088,</p>
<p>(NDT&nbsp;: Ce numéro est bien entendu aux États-Unis.)</p>
<p>et vous pouvez aussi les joindre à
<code>75300.2672@compuserve.com</code>. Les anciennes cartes ISA ne
semblent pas souffrir des mêmes maux.</p>
<p>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&nbsp;:</p>
<blockquote><a href="http://cesdis.gsfc.nasa.gov/linux/">Linux @
CESDIS</a></blockquote>
<p>Boca offre une `réparation&nbsp;- 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&nbsp;% pour la plupart des gens, bien que cela
en aide quelques uns.</p>
<p>Si vous pensez <em>encore</em> acheter une de ces cartes, alors
essayez au moins d'obtenir une clause de retour inconditionnel sous
7&nbsp;jours, pour que vous puissiez la rendre si elle ne
fonctionne pas correctement sur votre système.</p>
<p>Des informations plus générales sur les puces AMD se trouvent
dans&nbsp; <a href="#lance">AMD LANCE</a>.</p>
<p>Plus d'informations techniques sur les cartes Ethernet basées
sur l'AMD LANCE sont disponibles dans&nbsp; <a href=
"#amd-notes">Notes sur l'AMD...</a>.</p>
<h2><a name="ctron"></a> <a name="ss5.10">5.10 Cabletron</a></h2>
<p>Donald écrit&nbsp;: ``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.&nbsp;Becker travaille sur un pilote
pour Linux' -- laissant entendre que je travaillais pour eux. Ce
N'est PAS le cas.''</p>
<p>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 à <code>support@ctron.com</code> 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.</p>
<h3><a name="e10xx"></a> E10**, E10**-x, E20**, E20**-x</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: ne
(+8390)</p>
<p>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.</p>
<h3><a name="e2100"></a> E2100</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: e2100
(+8390)</p>
<p>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&nbsp;Ko</em>&nbsp;! Cela signifie que vous
<em>ne pouvez pas</em>, 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</em> éteindre la machine et
<em>attendre</em> qu'elle se repose pendant 30&nbsp;secondes.</p>
<p>La sélection du support physique est automatique, mais vous
pouvez outrepasser cette fonctionnalité en utilisant les bits de
poids faibles du paramètre <code>dev-&gt;mem_end</code>.
Consultez&nbsp; <a href="#ether">PARAM_2</a>. Les utilisateurs des
modules peuvent spécifier une valeur <code>xcvr=N</code> comme
<code>option</code> dans le fichier
<code>/etc/conf.modules</code>.</p>
<p>Ne prenez pas non plus la&nbsp;E2100 pour un clone
de&nbsp;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.</p>
<p>Vous trouverez un pilote pour la&nbsp;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.</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<h3><a name="e2200"></a> E22**</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
lance</p>
<p>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&nbsp; <a href="#lance">AMD
PC-Net</a>) et devraient fonctionner avec le pilote générique
<code>lance</code>.</p>
<h2><a name="ss5.11">5.11 Cogent</a></h2>
<p>Voici où et comment les joindre&nbsp;:</p>
<pre>
        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
</pre>
<h3>EM100-ISA/EISA</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
smc9194</p>
<p>Ces cartes utilisent la puce SMC 91c100 et devraient fonctionner
avec le pilote SMC 91c92, mais cela reste à vérifier.</p>
<h3>Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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.</p>
<p>L'EM400 et l'EM964 sont des cartes à quatre ports qui utilisent
un pont DEC 21050 et quatre puces 21040.</p>
<p>Consultez&nbsp; <a href="#dec-21040">DEC 21040</a> pour plus
d'information sur ces cartes, et l'état d'avancement actuel du
pilote.</p>
<h2><a name="ss5.12">5.12 Compaq</a></h2>
<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.</p>
<h3>Compaq Deskpro / Compaq XL (Embedded AMD Chip)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>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&nbsp;:</p>
<p>``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&nbsp;:
la carte n'est jamais détectée ni utilisable (en passant&nbsp;: 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).''</p>
<p>Des informations plus générales sur les puces AMD se trouvent
dans&nbsp; <a href="#lance">AMD LANCE</a>.</p>
<h3>Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: tlan</p>
<p>Ces systèmes utilisent une puce Texas Instrument ThunderLAN,
pour plus d'informations, référez vous à la section <a href=
"#tlan">ThunderLAN</a>.</p>
<h2><a name="ss5.13">5.13 Danpex</a></h2>
<h3>Danpex EN9400</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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é.</p>
<p>Consultez&nbsp; <a href="#dec-21040">DEC 21040</a> pour plus
d'information sur ces cartes, et l'état d'avancement actuel du
pilote.</p>
<h2><a name="d-link"></a> <a name="ss5.14">5.14 D-Link</a></h2>
<h3><a name="de-100"></a> DE-100, DE-200, DE-220-T, DE-250</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne (+8390)</p>
<p>Certaines des premières cartes D-Link ne possédaient pas la
signature <code>0x57</code> en PROM, mais le pilote ne2000 en a
connaissance. Pour les cartes configurables par logiciel, vous
pouvez obtenir le programme de ad hoc sur
<code>www.dlink.com</code>. 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à.</p>
<h3><a name="de-520"></a> DE-520</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>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&nbsp; <a href="#lance">AMD
LANCE</a>.</p>
<p>Des informations plus techniques sur les cartes Ethernet basées
sur la puce LANCE d'AMD sont disponibles dans&nbsp; <a href=
"#amd-notes">Notes sur l'AMD...</a>.</p>
<h3>DE-528</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne, ne2k-pci
(+8390)</p>
<p>On dirait que D-Link a aussi commencé à fabriquer des clones de
NE2000.</p>
<h3><a name="de-530"></a> DE-530</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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'.</p>
<p>Consultez&nbsp; <a href="#dec-21040">DEC 21040</a> pour plus
d'information sur ces cartes, et l'état d'avancement actuel du
pilote.</p>
<h3><a name="de-600"></a> DE-600</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de600</p>
<p>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 <code>bj0rn@blox.se</code> a
écrit le pilote. Attendez-vous à des taux de transfert de
180&nbsp;Ko/s par le port parallèle. Vous devriez lire le fichier
README.DLINK dans l'arborescence du noyau.</p>
<p>(NDT&nbsp;: Ce fichier est bien entendu en anglais.)</p>
<p>Notez que le nom de périphérique que vous passez à
<code>ifconfig</code> est <em>maintenant</em> <code>eth0</code> et
non pas celui précédemment utilisé, <code>dl0</code>.</p>
<p>Si votre port parallèle <em>ne</em> se trouve <em>pas</em> à
l'adresse standard <code>0x378</code>, il vous faudra recompiler le
noyau. Bjorn écrit&nbsp;: ``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&nbsp;; vous _devez_ recompiler...'' Notez aussi
que certains portables implémentent le port parallèle interne à
l'adresse <code>0x3bc</code>, ce qui est l'endroit où les ports
parallèles étaient/sont sur les cartes monochromes.</p>
<h3><a name="de-620"></a> DE-620</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de620</p>
<p>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.</p>
<h3><a name="de-650"></a> DE-650</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: de650
?</p>
<p>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</em> fait <em>pas</em> partie du noyau standard, et que vous
devrez donc appliquer quelques patches.</p>
<p>Consultez&nbsp; <a href="#pcmcia">Support du PCMCIA</a> dans ce
document, et si vous le pouvez, jetez un coup d'oeil à&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/pcmcia.html">La page PCMCIA de
Don</a></blockquote>
<h2><a name="dfi"></a> <a name="ss5.15">5.15 DFI</a></h2>
<h3><a name="dfi-300"></a> DFINET-300 et DFINET-400</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne (+8390)</p>
<p>Ces cartes sont maintenant détectées (depuis la
version&nbsp;0.99pl15) grâce à Eberhard Moenkeberg
(<code>emoenke@gwdg.de</code>) qui a noté qu'elles utilisent `DFI'
dans les trois premiers octets de la PROM, à la place
de&nbsp;<code>0x57</code> dans les octets 14&nbsp;et 15, ce que
font toutes les autres cartes NE1000&nbsp;et NE2000. (La&nbsp;300
est un semblant de clone 8&nbsp;bits de la NE1000, et la&nbsp;400
est un semblant de clone NE2000.)</p>
<h2><a name="dec"></a> <a name="ss5.16">5.16 Digital / DEC</a></h2>
<h3><a name="dec-200"></a> DEPCA, DE100/1, DE200/1/2, DE210,
DE422</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: depca</p>
<p>De la documentation incluse dans le fichier source
<code>depca.c</code> 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&nbsp; <a href="#lance">AMD LANCE</a> 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'à <code>0x300</code> ou <code>0x200</code>. Si vous avez
l'intention de le faire, veuillez lire les notes dans le fichier
source du pilote, <code>depca.c</code>, dans l'arborescence du
noyau standard.</p>
<p>Ce pilote fonctionnera aussi sur les machines à processeur
Alpha, et il comprend différents <code>ioctl()</code> avec lesquels
l'utilisateur peut s'amuser.</p>
<h3><a name="dec-ewrk3"></a> Digital EtherWorks 3 (DE203, DE204,
DE205)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ewrk3</p>
<p>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&nbsp;Ko, 32&nbsp;Ko, ou
64&nbsp;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&nbsp;Ko et le mode 32&nbsp;Ko. Plus d'informations
(y compris l'utilisation du pilote comme module chargeable)
figurent en tête du fichier source du pilote, <code>ewrk3.c</code>,
ainsi que dans le fichier <code>README.ewrk3</code>. Ces deux
fichiers se trouvent dans la distribution standard du noyau. Ce
pilote supporte les CPU alpha tout comme le
<code>depca.c</code>.</p>
<p>Le pilote standard a un certain nombre d'appels
<code>ioctl()</code> 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.</p>
<p>David a aussi écrit un utilitaire de configuration pour cette
carte (outre les lignes du programme DOS <code>NICSETUP.EXE</code>)
ainsi que d'autres outils. Vous pouvez les trouver sur la majorité
des sites Linux dans le répertoire
<code>/pub/Linux/system/Network/management</code> --&nbsp;cherchez
un fichier <code>ewrk3tools-X.XX.tar.gz</code>.</p>
<p>(NDT&nbsp;: Le lecteur français aura bien entendu tout intérêt à
utiliser un site miroir, plus rapide. Par exemple&nbsp;:</p>
<p>
<code>ftp://ftp.lip6.fr/pub/linux/sunsite/system/Network/management</code>)</p>
<h3><a name="dec-eisa"></a> DE425 EISA, DE434, DE435, DE500</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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 à <code>README.de4x5</code> pour les
détails.</p>
<p>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).</p>
<p>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 <code>ioctl()</code> --&nbsp;voir l'outil <code>ewrk3</code>
et les sources <code>de4x5.c</code> pour des informations sur la
façon de procéder.</p>
<h3><a name="dec-21040"></a> DEC 21040, 21041, 2114x, Tulip</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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.</p>
<p>Vous avez le choix entre <em>deux</em> 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.</p>
<p><b>Attention&nbsp;:</b> Même si votre carte est basée sur cette
puce, <em>les pilotes peuvent ne pas fonctionner pour vous</em>.
David C. Davies écrit&nbsp;: ``Il n'y aucune garantie que SOIT
<code>tulip.c</code> SOIT <code>de4x5.c</code> feront fonctionner
une autre carte basée sur le DC2114x que celles pour lesquelles ils
ont été écrit. POURQUOI&nbsp;?? 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.''</p>
<p>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</em> de l'avoir
payée.</p>
<p>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
<code>de4x5</code> de David avec des cartes non conçues par DEC,
lisez le fichier <code>README.de4x5</code> pour les détails.</p>
<p>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.</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html">Pilote
Tulip</a></blockquote>
<p>L'URL ci-dessus contient aussi une liste (non exhaustive) de
différents cartes/constructeurs qui utilisent la puce 21040.</p>
<p>Notez également que le pilote tulip est encore considéré comme
un pilote <em>alpha</em> (voir&nbsp; <a href="#alfa">Pilotes
alpha</a>) actuellement, et qu'il doit donc être traité comme tel.
Pour l'utiliser, vous devrez éditer
<code>arch/i386/config.in</code> et enlever les commentaires qui
entourent la ligne sur le support <code>CONFIG_DEC_ELCP</code>.</p>
<p>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&nbsp;:</p>
<p><code>echo subscribe | /bin/mail
linux-tulip-request@cesdis.gsfc.nasa.gov</code></p>
<h2><a name="ss5.17">5.17 Farallon</a></h2>
<p>Farallon vend des adaptateurs et des transceivers EtherWave. Ce
périphérique permet de mettre en série plusieurs périphériques
10baseT.</p>
<h3>Etherwave de Farallon</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: 3c509</p>
<p>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. 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 --&nbsp;c'est bien
si vous avez tiré un câble trop court, mais pas si vous avez deux
réseaux qui tombent trop courts.</p>
<h2><a name="ss5.18">5.18 Fujitsu</a></h2>
<p>Contrairement à de nombreux fabricants de puces, Fujitsu a aussi
fabriqué et vendu des cartes réseau basées sur les leurs.</p>
<h3>Fujitsu FMV-181/182/183/184</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: fmv18x</p>
<p>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.</p>
<h2><a name="hp"></a> <a name="ss5.19">5.19 Hewlett
Packard</a></h2>
<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.</p>
<p>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.</p>
<h3><a name="hp-27245a"></a> 27245A</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: hp (+8390)</p>
<p>Carte 8&nbsp;bits 10BaseT basée sur le&nbsp;8390, non
recommandée pour toutes les raisons des 8&nbsp;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
(<i>loopback</i>)).</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<h3>HP EtherTwist, PC Lan+ (27247, 27252A)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: hp+ (+8390)</p>
<p>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.</p>
<p>La 47B est une carte 16&nbsp;bits 10BaseT avec AUI à base de
8390, et la 52A est une carte 16&nbsp;bits ThinLAN avec AUI à base
de 8390. Ces cartes comportent 32&nbsp;Ko de mémoire vive embarquée
pour le tampon de réception/transmission des paquets au lieu des
16&nbsp;Ko habituels, et elles offrent toutes les deux une fonction
de détection automatique du connecteur réseau.</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<h3>HP-J2405A</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: lance</p>
<p>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.</p>
<p>Plus d'informations techniques sur les cartes basée sur la puce
AMD se trouvent dans&nbsp; <a href="#amd-notes">Notes sur
AMD...</a>.</p>
<h3>Carte Ethernet embarquée de l'HP-Vectra</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: lance</p>
<p>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&nbsp; <a href="#lance">AMD LANCE</a>.</p>
<p>Plus d'informations techniques sur les cartes basées sur la puce
AMD se trouvent dans&nbsp; <a href="#amd-notes">Notes sur
AMD...</a>.</p>
<h3>Cartes HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585, J970,
J973)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: hp100</p>
<p>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 <code>make
config</code> dans les sources du noyau.</p>
<h3>HP NetServer 10/100TX PCI (D5013A)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: eepro100</p>
<p>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.</p>
<h2><a name="ibm"></a> <a name="ss5.20">5.20 IBM / International
Business Machines</a></h2>
<h3><a name="thinkpad-300"></a> IBM Thinkpad 300</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: znet</p>
<p>Celui-ci est compatible avec le Z-note de Zénith, basé sur une
puce Intel. Voir&nbsp; <a href="#z-note">Z-note</a>.</p>
<p>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.</p>
<blockquote><a href=
"http://peipa.essex.ac.uk/html/linux-thinkpad.html">Thinkpad-info</a></blockquote>
<p>Pour ceux d'entre vous qui n'ont pas de navigateur WWW à portée
de la main, essayez <code>peipa.essex.ac.uk:/pub/tp750/</code>.</p>
<h3>IBM Credit Card Adaptor for Ethernet - Adaptateur `Credit Card'
pour Ethernet d'IBM</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: ?
(distribué séparément)</p>
<p>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.</p>
<p>Consultez&nbsp; <a href="#pcmcia">Support PCMCIA</a> dans ce
document, et si vous le pouvez jetez un coup d'oeil à&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/pcmcia.html">La page PCMCIA de
Donald</a></blockquote>
<h3>IBM Token Ring</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
ibmtr</p>
<p>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.</p>
<p>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.</p>
<p>Le code Token Ring actuel a été inclus dans les premiers noyaux
des séries 1.3.x.</p>
<p>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.</p>
<h2><a name="ss5.21">5.21 Cartes Ethernet ICL</a></h2>
<h3>ICL EtherTeam 16i/32</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: eth16i</p>
<p>Mika Kuoppala (<code>miku@pupu.elt.icl.fi</code>) 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.</p>
<h2><a name="intel"></a> <a name="ss5.22">5.22 Cartes Ethernet
Intel</a></h2>
<p>Note&nbsp;: les noms de certaines cartes Intel sont ambigus au
possible et prêtent à confusion . Si vous avez un doute, vérifiez
le numéro sur la puce principale de la carte <code>i8xxxx</code>,
ou, pour les cartes PCI, utilisez les informations disponibles dans
le repertoire <code>/proc</code> et ensuite, comparez-les aux
numéros listés ici.</p>
<h3>Ether Express</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: eexpress</p>
<p>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.</p>
<p>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 <code>outb</code> par des <code>outb_p</code>
dans le pilote a permis d'éviter des blocages pour au moins une
personne.</p>
<h3>Ether Express PRO/10</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: eepro</p>
<p>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.</p>
<h3>Ether Express PRO/10 PCI (EISA)</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: ?
(distribué séparement)</p>
<p>John Stalba (<code>stalba@ultranet.com</code>) 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</em> 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.</p>
<p>Vous pouvez obtenir le pilote `alpha' pour les cartes PCI
PRO/10, ainsi que les instructions pour l'utiliser, à&nbsp;:</p>
<blockquote><a href=
"http://www.ultranet.com/~stalba/eep10pci.html">Pilote
EEPro10</a></blockquote>
<p>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.</p>
<h3><a name="eepro100"></a> Ether Express PRO 10/100B</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: eepro100</p>
<p>Notez que ce pilote <em>ne</em> fonctionnera <em>pas</em> avec
les cartes 100A qui sont plus anciennes. Les numéros de puces que
gère le pilote sont i82557/i82558.</p>
<p>Pour les mises à jour du pilote et&nbsp;/ ou des informations,
consultez&nbsp;:</p>
<blockquote><a href=
"http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html">Page de
l'EEPro-100B</a></blockquote>
<p>Pour vous inscrire à la liste de diffusion relative à ce pilote,
tapez la commande suivante&nbsp;:</p>
<blockquote><code>echo subscribe | /bin/mail
linux-eepro100-request@cesdis.gsfc.nasa.gov</code></blockquote>
<p>Apparemment Donald a été obligé de signer un accord de
confidentialité qui établit qu'il pouvait en fait communiquer le
code-source du pilote&nbsp;! Comment prendre une telle preuve de
bêtise de la part d'Intel&nbsp;?</p>
<h2><a name="ss5.23">5.23 Kingston</a></h2>
<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&nbsp; <a href=
"http://www.kingston.com">Kingston Web Page</a> pour plus de
détails.</p>
<p>Il paraît que la carte à base de KNE40 DEC 21041 tulip
fonctionne très bien avec le pilote tulip générique</p>
<h2><a name="ss5.24">5.24 LinkSys</a></h2>
<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.</p>
<p>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&nbsp;:</p>
<blockquote>
<code>http://www.linksys.com/support/solution/nos/linux.htm</code></blockquote>
<h3>Cartes LinkSys Etherfast 10/100.</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: tulip</p>
<p>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 à&nbsp;:</p>
<blockquote>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/pnic.html</code></blockquote>
<p>Pour plus d'informations sur les différentes versions de ces
cartes, référez vous au site de LinkSys mentionné ci-dessus.</p>
<h3>LinkSys Pocket Ethernet Adapter Plus (PEAEPP)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de620</p>
<p>On suppose qu'il s'agit d'un clone du DE-620, et il paraît que
cela fonctionne bien avec ce pilote. Consultez&nbsp; <a href=
"#de-620">DE-620</a> pour plus d'information.</p>
<h3>Adaptateur LinkSys PCMCIA</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de650 (?)</p>
<p>On suppose qu'il s'agit d'un DE-650 "recarrossé" avec une
étiquette différente. Consultez&nbsp; <a href="#de-650">DE-650</a>
pour plus d'information.</p>
<h2><a name="ss5.25">5.25 Microdyne</a></h2>
<h3>Microdyne Exos 205T</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;: ?</p>
<p>Une autre carte basée sur l'i82586. Dirk Niggemann
<code>dirk-n@dircon.co.uk</code> 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.</p>
<h2><a name="ss5.26">5.26 Mylex</a></h2>
<p>Mylex peut être joint aux numéros suivants, au cas où quelqu'un
aurait envie de leur demander quelque chose.</p>
<pre>
        MYLEX CORPORATION, Fremont Ventes: 800-77-MYLEX, (510) 796-6100 FAX:
        (510) 745-8016.
</pre>
<p>Ils ont aussi un site WWW: <a href="http://www.mylex.com">Site
WWW de Mylex</a></p>
<h3>Mylex LNE390A, LNE390B</h3>
<p>Statut&nbsp;: supporté, Nom du pilote&nbsp;: lne390 (+8390)</p>
<p>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.</p>
<h3>Mylex LNP101</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>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.</p>
<p>Consultez la section sur la puce 21040 ( <a href=
"#dec-21040">DEC 21040</a>) pour plus d'information.</p>
<h3>Mylex LNP104</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
de4x5, tulip</p>
<p>La LNP104 utilise la puce 21050 de DEC pour fournir
<em>quatre</em> 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).</p>
<h2><a name="novell"></a> <a name="ss5.27">5.27 Ethernet chez
Novell&nbsp;: NExxxx et les clones associés.</a></h2>
<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é&nbsp;?), juste pour pouvoir mettre sur
le marché des cartes Ethernet à prix raisonnables. (La maintenant
omniprésente carte NE2000).</p>
<h3><a name="ne2k"></a> NE1000, NE2000</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne (+8390)</p>
<p>``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 à <a href="#ne2k-probs">Problèmes avec...</a>.</p>
<p>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.</p>
<p>En général ce n'est pas une bonne idée de placer un clone de
NE2000 à l'adresse d'E/S <code>0x300</code> parce que pratiquement
<em>tous</em> 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 <code>0x320</code> est
également une mauvaise idée car les pilotes SCSI testent
<code>0x330</code>.</p>
<p>Donald a écrit un programme de diagnostic pour NE2000
(<code>ne2k.c</code>) qui fonctionne pour toutes les cartes NE2000.
Consultez&nbsp; <a href="#diag">Programmes de diagnostic</a> pour
plus d'information.</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<h3><a name="ne2k-pci"></a> NE2000-PCI
(RealTek/Winbond/Compex)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne, ne2k-pci
(+8390)</p>
<p>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&nbsp;89c940 de Winbond. Les cartes
Compex, KTI, VIA et Netvin utilisent apparemment aussi ces puces,
mais possèdent un une signature PCI différente.</p>
<p>Le dernier noyau Linux&nbsp;2.0 est capable de détecter
automatiquement toutes ces cartes et de les utiliser. (Si vous
utilisez un noyau version&nbsp;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 <code>ne.c</code> et le pilote PCI plus récent
<code>ne2k-pci.c</code>.</p>
<p>Pour utiliser le pilote original, vous devez répondre `Y' à
l'option `Other ISA cards' (`Autres cartes ISA&nbsp;?') lorsque
vous exécutez <code>make config</code> car en fait vous utilisez le
même pilote&nbsp;NE2000 que celui des cartes&nbsp;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...).</p>
<p>Le récent pilote PCI diffère de la version ISA/PCI par le fait
que le support pour les cartes 8&nbsp;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 à&nbsp;:</p>
<blockquote>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html</code></blockquote>
<p>Si vous avez une carte PCI NE2000 qui <em>n'est pas</em>
détectée par le dernier pilote, veuillez contacter le responsable
du pilote&nbsp;NE2000 qui est indiqué dans
<code>/usr/src/linux/MAINTAINERS</code>, en lui joignant les
sorties d'un <code>cat /proc/pci</code> et de <code>dmesg</code>
afin que le support pour votre carte puisse être ajouté dans le
pilote.</p>
<p>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&nbsp;: PCNet-PCI ou
RealTek 8139). En cas de doute, regardez la puce principale et
comparez avec ce qui est écrit ici.</p>
<h3>NE-10/100</h3>
<p>Statut&nbsp;: Non supporté</p>
<p>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.</p>
<h3><a name="ne1500"></a> NE1500, NE2100</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: lance</p>
<p>Ces cartes utilisent la puce 7990 LANCE originelle d'AMD et sont
supportées grâce au pilote Linux <code>lance</code>. Les clones de
NE2100 plus récents reposent sur la puce mise à jour PCnet/ISA
d'AMD.</p>
<p>Des versions plus anciennes du pilote <code>lance</code> avaient
des problèmes pour obtenir la ligne d'IRQ via l'affectation
automatique d'IRQ des cartes&nbsp;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.</p>
<p>La sélection du DMA et des informations sur la numérotation de
la puce se trouvent dans&nbsp; <a href="#lance">AMD LANCE</a>.</p>
<p>Des informations plus techniques sur les cartes Ethernet basées
sur l'AMD LANCE sont disponibles dans&nbsp; <a href=
"#amd-notes">Notes sur l'AMD...</a>.</p>
<h3>NE/2 MCA</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
ne2</p>
<p>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&nbsp;: Novell Ethernet Adapter NE/2, Compex
ENET-16 MC/P, et l'Ethernet Adapter AE/2 de chez Arco.</p>
<h3><a name="ne3200"></a> NE3200</h3>
<p>Statut&nbsp;: Non supporté</p>
<p>Cette vieille carte EISA utilise un 80186 à 8&nbsp;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.</p>
<h3><a name="ne3210"></a> NE3210</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne3210 (+8390)</p>
<p>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.</p>
<h3>NE5500</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: pcnet32</p>
<p>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&nbsp; <a href="#lance">AMD LANCE</a>.</p>
<h2><a name="ss5.28">5.28 Proteon</a></h2>
<h3>Proteon P1370-EA</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne (+8390)</p>
<p>Il s'agit apparemment d'un clone de NE2000, et il fonctionne
correctement avec Linux.</p>
<h3>Proteon P1670-EA</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>Encore une autre carte PCI basée sur la puce Tulip de DEC. On
rapporte qu'elle fonctionne correctement avec Linux.</p>
<p>Consultez la section sur la puce 21040 ( <a href=
"#dec-21040">DEC 21040</a>) pour plus d'informations sur le
pilote.</p>
<h2><a name="ss5.29">5.29 Pure Data</a></h2>
<h3>PDUC8028, PDI8023</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: wd (+8390)</p>
<p>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 <code>jaggy@purplet.demon.co.uk</code>. Le
support pour ces cartes est intégré dans le pilote Western Digital
(WD).</p>
<h2><a name="ss5.30">5.30 Racal-Interlan</a></h2>
<p>On peut joindre Racal-Interlan via le WWW à
<code>www.interlan.com</code>. Je crois qu'ils étaient connus sous
le nom de MiCom-Interlan à une époque.</p>
<h3>ES3210</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
es3210</p>
<p>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&nbsp;; par exemple, pour
une carte utilisant l'IRQ&nbsp;5 et la mémoire partagée
en&nbsp;<code>0xd0000</code>. Avec un pilote modulaire, ajoutez
<code>options es3210 irq=5 mem=0xd0000</code> à votre fichier
<code>/etc/conf.modules</code>. Si le pilote est intégré au noyau,
donnez lui <code>ether=5,0,0xd0000,eth0</code> 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.</p>
<h3>NI5010</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
ni5110</p>
<p>Le pilote pour ces vieilles cartes 8&nbsp;bits MiCom-Interlan
était disponible séparément, mais on le trouve maintenant en tant
que pilote expérimental dans les noyaux 2.2.</p>
<h3>NI5210</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
ni52</p>
<p>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&nbsp; <a href="#alfa">Les pilotes `Alpha'</a> pour des
informations importantes sur l'utilisation des pilotes Ethernet en
phase de test `alpha' avec Linux.</p>
<h3><a name="ni65xx"></a> NI6510 (not EB)</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
ni65</p>
<p>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&nbsp; <a href="#alfa">Les pilotes `Alpha'</a> pour des
informations importantes sur l'utilisation des pilotes Ethernet en
phase de test `alpha' avec Linux.</p>
<h3>EtherBlaster (aka NI6510EB)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: lance</p>
<p>Depuis le noyau 1.3.23, le pilote LANCE générique comprend un
test supplémentaire pour la signature <code>0x52, 0x44</code>
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 <code>lance</code> à 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 <code>lance.c</code>) pour qu'elle
<code>printk()</code> (affiche) quelles sont les valeurs pour votre
carte, puis utiliser ces valeurs à la place du <code>0x52,
0x44</code> donné par défaut.</p>
<p>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 <code>lance</code>.</p>
<h2><a name="ss5.31">5.31 RealTek</a></h2>
<h3><a name="aep-100"></a> RealTek RTL8002/8012 (AT-Lan-Tec) Pocket
adaptor</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: atp</p>
<p>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, <code>atp.c</code>.</p>
<p>Notez que dans les premières versions de ce pilote, le nom de
périphérique que vous passiez à <code>ifconfig</code> <em>n'était
pas</em> <code>eth0</code> mais&nbsp;<code>atp0</code>.</p>
<h3>RealTek 8009</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne (+8390)</p>
<p>C'est un clone de NE2000 ISA, et il fonctionne très bien avec le
pilote NE2000 Linux. Le programme <code>rset8009.exe</code> peut
être obtenu depuis le site WWW de RealTek's
<code>http://www.realtek.com.tw</code> - ou via ftp depuis le même
site.</p>
<h3>RealTek 8019</h3>
<p>Statut&nbsp;: Support, Nom du pilote&nbsp;: ne (+8390)</p>
<p>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
<code>io=0xNNN</code> au fichier <code>/etc/conf.modules</code>. Le
programme <code>rset8009.exe</code> peut être obtenu depuis le site
WWW de RealTek's <code>http://www.realtek.com.tw</code> --&nbsp;ou
via ftp depuis le même site.</p>
<h3>RealTek 8029</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne2k-pci</p>
<p>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&nbsp; <a href="#ne2k-pci">NE2000
PCI</a> 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.</p>
<h3><a name="rtl8139"></a> RealTek 8129/8139</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
rtl8139</p>
<p>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&nbsp;2.0.34 du noyau Linux. Pour plus
d'informations, consultez&nbsp;:</p>
<blockquote>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html</code></blockquote>
<h2><a name="ss5.32">5.32 Sager</a></h2>
<h3>Sager NP943</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
3c501</p>
<p>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&nbsp; <a href="#3c501">3Com 3c501</a> 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.</p>
<h2><a name="ss5.33">5.33 Schneider &amp; Koch</a></h2>
<h3>SK G16</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: sk_g16</p>
<p>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.</p>
<h2><a name="ss5.34">5.34 SEEQ</a></h2>
<h3>SEEQ 8005</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: seeq8005</p>
<p>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 à <code>hamish@zot.apana.org.au</code>.</p>
<h2><a name="smc"></a> <a name="ss5.35">5.35 SMC (Standard
Microsystems Corp.)</a></h2>
<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.</p>
<p>Voici comment contacter SMC&nbsp;:</p>
<p>SMC / Standard Microsystems Corp., 80 Arkay Drive, Hauppage, New
York, 11788, USA. Support technique par téléphone&nbsp;:
800-992-4762 (USA) ou 800-433-5345 (Canada) ou 516-435-6250 (Autres
pays). Demandes de documentation&nbsp;: 800-SMC-4-YOU (USA) ou
800-833-4-SMC (Canada) ou 516-435-6255 (Autres pays). Support
technique par E-mail&nbsp;:
<code>techsupt@ccmail.west.smc.com</code>. Site FTP &nbsp;:
<code>ftp.smc.com</code>. Site Web&nbsp;: <a href=
"http://www.smc.com">SMC</a>.</p>
<h3>WD8003, SMC Elite</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: wd (+8390)</p>
<p>Ce sont les versions 8&nbsp;bits de la carte. La 8003
8&nbsp;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</em> 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 <code>SMCDSK46.EXE</code> 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&nbsp;?) version
peut être obtenue depuis <code>ftp.smc.com</code>.</p>
<p>Comme ces cartes sont fondamentalement les mêmes que leurs
homologues 16&nbsp;bits (WD8013 / SMC Elite16), vous devriez
consulter la section suivante pour en savoir plus.</p>
<h3><a name="8013"></a> WD8013, SMC Elite16</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: wd (+8390)</p>
<p>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&nbsp;!) 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.</p>
<p>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&nbsp;bits affecteront l'IRQ 5).</p>
<p>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 <code>/etc/conf.modules</code> si
vous utilisez les modules). La taille mémoire standard est de
8&nbsp;Ko pour une carte 8&nbsp;bits et de 16&nbsp;Ko pour une
carte 16&nbsp;bits. Par exemple, les antédiluviennes WD8003EBT
peuvent être configurées par cavaliers pour utiliser 32&nbsp;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
<code>0x280</code> et l'IRQ&nbsp;9)&nbsp;:</p>
<hr>
<pre>
        LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0
</pre>
<hr>
<p>Consultez aussi&nbsp; <a href="#8013-probs">Les problèmes des
8013</a> pour certains des problèmes les plus classiques et les
questions qui reviennent le plus fréquemment.</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<h3><a name="ultra"></a> SMC Elite Ultra</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: smc-ultra
(+8390)</p>
<p>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.</p>
<p>Puisqu'une partie de l'Ultra <em>ressemble</em> à 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.</p>
<p>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.</p>
<p>Utilisateurs d'adaptateurs SCSI dotés du contrôle de bus, prenez
note&nbsp;: 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.</p>
<p>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
<code>smc-ultra.c:v1.12</code>, sinon vous êtes vulnérable à ce
problème.</p>
<p>Si vous avez l'intention d'utiliser ce pilote sous la forme d'un
module chargeable, vous devriez probablement consulter&nbsp;
<a href="#modules">Utiliser les pilotes Ethernet comme modules</a>
pour des informations spécifiques aux modules.</p>
<h3><a name="ultra32"></a> SMC Elite Ultra32 EISA</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: smc-ultra32
(+8390)</p>
<p>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é.</p>
<h3>SMC EtherEZ (8416)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: smc-ultra
(+8390)</p>
<p>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</em> 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.</p>
<p>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.</p>
<h3><a name="smc-pci"></a> SMC EtherPower PCI (8432)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>NB&nbsp;: L'EtherPower&nbsp;II est une carte totalement
différente. Voir plus bas&nbsp;!</p>
<p>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 <code>tulip.c</code>).
Merci de nouveau à Duke Kamstra, d'avoir fourni une carte sur
laquelle réaliser le développement.</p>
<p>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 <code>tulip</code>. 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.</p>
<p>Consultez&nbsp; <a href="#dec-21040">DEC 21040</a> pour plus de
détails sur l'utilisation d'une de ces cartes, et l'état
d'avancement actuel du pilote.</p>
<p>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</em> de payer.</p>
<h3><a name="smc-pci-II"></a> SMC EtherPower II PCI (9432)</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
epic100</p>
<p>Ces cartes, basées sur la puce&nbsp;83c170 de&nbsp;SMC, sont
complètement différentes des cartes basées sur la&nbsp;Tulip. Un
nouveau pilote est inclus dans les noyau&nbsp;2.0 et 2.2 pour les
supporter. Pour plus de détails, consultez&nbsp;:</p>
<p>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html</code></p>
<h3>SMC 3008</h3>
<p>Statut&nbsp;: Non supporté</p>
<p>Ces cartes 8&nbsp;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
<code>at1700.c</code> et son pilote DOS en mode paquet pour la
carte Tiara (<code>tiara.asm</code>). Ces cartes ne sont pas très
répandues.</p>
<h3>SMC 3016</h3>
<p>Statut&nbsp;: Non supporté</p>
<p>Il s'agit de cartes 16&nbsp;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.</p>
<h3>SMC-9000 / SMC 91c92/4</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: smc9194</p>
<p>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 (<code>erik@vt.edu</code>) 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.</p>
<h3>SMC 91c100</h3>
<p>Statut&nbsp;: Partiellement supporté, Nom du pilote&nbsp;:
smc9194</p>
<p>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é.</p>
<h2><a name="ss5.36">5.36 Texas Instruments</a></h2>
<h3><a name="tlan"></a> ThunderLAN</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: tlan</p>
<p>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.</p>
<h2><a name="ss5.37">5.37 Thomas Conrad</a></h2>
<h3>Thomas Conrad TC-5048</h3>
<p>Encore une autre carte PCI basée sur la puce 21040 de DEC.</p>
<p>Consultez la section sur la puce 21040 ( <a href=
"#dec-21040">DEC 21040</a>) pour plus d'informations.</p>
<h2><a name="ss5.38">5.38 VIA</a></h2>
<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 à&nbsp;:</p>
<blockquote><code>http://www.via.com.tw/</code></blockquote>
<h3>VIA 86C926 Amazon</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne, ne2k-pci
(+8390)</p>
<p>Ce contrôleur est l'offre NE2000 PCI de VIA. Vous avez le choix
entre le pilote ISA/PCI <code>ne.c</code> ou le pilote PCI
<code>ne2k-pci.c</code>. Référez vous à la section NE2000 PCI pour
plus de détails.</p>
<h3>VIA 86C100A Rhine II (et 3043 Rhine I)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: via-rhine</p>
<p>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&nbsp;bits, les
gains sont limités. Pour plus de détails, et les mises à jour,
référez vous à&nbsp;:</p>
<p>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html</code></p>
<h2><a name="ss5.39">5.39 Western Digital</a></h2>
<p>Référez vous à la section <a href="#smc">SMC</a> pour plus
d'informations sur les cartes SMC. (SMC a racheté la section cartes
réseau de Western Digital il y a bien longtemps).</p>
<h2><a name="ss5.40">5.40 Winbond</a></h2>
<p>Winbond ne fabrique, ni ne vend de cartes au grand
public&nbsp;--&nbsp;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.</p>
<h3>Winbond 89c840</h3>
<p>Statut&nbsp;: Partiellement Supporté, Nom du pilote&nbsp;:
winbond-840</p>
<p>Ce pilote n'est pas actuellement distribué avec le noyau, car il
est en phase de test. Il est disponible à&nbsp;:</p>
<p>
<code>http://cesdis.gsfc.nasa.gov/linux/drivers/test/winbond-840.c</code></p>
<h3>Winbond 89c940</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: ne, ne2k-pci
(+8390)</p>
<p>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.</p>
<h2><a name="xircom"></a> <a name="ss5.41">5.41 Xircom</a></h2>
<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.</p>
<p>(NDT&nbsp;: 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).</p>
<h3>Xircom PE1, PE2, PE3-10B*</h3>
<p>Statut&nbsp;: Non supporté.</p>
<p>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 <i>Silly Interrupt
Generator</i>).</p>
<h3>Cartes Xircom PCMCIA</h3>
<p>Statut&nbsp;: Partiellement Supporté, Nom du pilote&nbsp;:
????</p>
<p>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.</p>
<h2><a name="zenith"></a> <a name="ss5.42">5.42 Zenith</a></h2>
<h3><a name="z-note"></a> Z-Note</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: znet</p>
<p>L'adaptateur réseau intégré au Z-Note est basé sur la puce
i82593 d'Intel, et utilise <em>deux</em> canaux DMA. Un pilote
(alpha&nbsp;?), 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
<code>make config</code>. Notez aussi que l'IBM ThinkPad 300 est
compatible avec le Z-Note.</p>
<h2><a name="zynx"></a> <a name="ss5.43">5.43 Znyx</a></h2>
<h3>Znyx ZX342 (DEC 21040 based)</h3>
<p>Statut&nbsp;: Supporté, Nom du pilote&nbsp;: de4x5, tulip</p>
<p>Vous avez le choix entre <em>deux</em> 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.</p>
<p>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 <code>README.de4x5</code> pour les détails.</p>
<p>Consultez&nbsp; <a href="#dec-21040">DEC 21040</a> pour plus
d'informations sur ces cartes, et la situation actuelle du
pilote.</p>
<h2><a name="mystery"></a> <a name="ss5.44">5.44 Identifier une
carte inconnue</a></h2>
<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.</p>
<p>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.</p>
<h3>Identifier le contrôleur d'interface réseau (Network Interface
Controller, NIC)</h3>
<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.</p>
<p>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&nbsp;! 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&nbsp;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</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>Identifier l'adresse Ethernet</h3>
<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 <code>00:00:c0</code>. Les trois derniers octets
sont affectés par le constructeur de façon unique à chaque carte
individuelle au fur et à mesure de leur fabrication.</p>
<p>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.</p>
<p>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 <code>EtherNet-codes</code>
ou <code>Ethernet-codes</code> et vous trouverez quelque chose.</p>
<h3>Quelques astuces pour essayer d'utiliser une carte
inconnue</h3>
<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.</p>
<p>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 <code>scanport.tar.gz</code> 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 <code>0x100</code> à <code>0x3ff</code> en
cherchant des périphériques qui ne sont pas déjà enregistrés dans
<code>/proc/ioports</code>. 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 <code>ether=</code>.</p>
<p>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, 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&nbsp;bits ne comportent que les
doigts 1 à 31.</p>
<p>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.</p>
<p>Une collection intéressante de configurations de cavaliers pour
diverses cartes se trouve à l'URL suivante&nbsp;:</p>
<blockquote><a href="http://www.slug.org.au/NIC/">Paramétrage des
cartes Ethernet</a></blockquote>
<h2><a name="ss5.45">5.45 Pilotes pour périphériques
Non-Ethernet</a></h2>
<p>Quelques autres pilotes existent dans les sources Linux qui se
présentent <em>comme</em> 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.</p>
<p><code>dummy.c</code> - 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.</p>
<p><code>eql.c</code> - 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.</p>
<p><code>ibmtr.c</code> - 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.</p>
<p><code>loopback.c</code> - 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.</p>
<p><code>pi2.c</code> - Interface Ottawa Amateur Radio Club PI et
PI2.</p>
<p><code>plip.c</code> - 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.</p>
<p><code>ppp.c</code> - 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).</p>
<p>(NDT&nbsp;: C'est le mode de connexion le plus couramment
employé par les fournisseurs d'accès Internet. Consultez le
<i>PPP-Howto</i>.)</p>
<p><code>slip.c</code> - 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.</p>
<p><code>tunnel.c</code> - 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.</p>
<p>(NDT&nbsp;: Pratique pour gérer certains problèmes délicats de
politique de routage, par exemple.)</p>
<p><code>wavelan.c</code> - 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.</p>
<h2><a name="cable"></a> <a name="s6">6. Câbles, Coaxial, Paire
Torsadée</a></h2>
<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.</p>
<p>Référez vous à <a href="#cable-intro">Type de cable...</a> pour
une introduction sur les câbles. Notez aussi que la Foire Aux
Questions (FAQ) du groupe <i>comp.dcom.lans.ethernet</i> contient
un tas d'informations utiles sur les câbles et tout ce genre de
choses. Jetez un coup d'oeil à&nbsp;:</p>
<blockquote><a href=
"ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/">Usenet
FAQs</a></blockquote>
<p>pour la FAQ de ce groupe de news.</p>
<p>(NDT&nbsp;: Le lecteur francophone utilisera bien entendu un
site miroir comme <a href="ftp://ftp.lip6.fr/faq/...">URL sur ibp à
compléter..</a> ou tout site équivalent proche de chez lui).</p>
<h2><a name="bnc"></a> <a name="ss6.1">6.1 Ethernet fin
(thinnet)</a></h2>
<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 à $0.27/m et le
câble multibrins RG58AU est à 3,40F/m. (NDT&nbsp;: Le prix du RG58A
est en dollar car je n'ai pas pu trouver de prix pour ce type de
câble en France&nbsp;!) Les connecteurs BNC à baïonnette sont à
moins de deux dollars chacun. (NDT&nbsp;: A sertir, environ 10
francs pièces, à souder un peu plus cher mais vous n'avez pas
besoin d'un outil spécial).</p>
<p>Les autres pièces diverses sont tout aussi bon marché.</p>
<p>Il est important que vous terminiez chaque extrémité du câble
avec un `bouchon' de 50&nbsp;ohms (NDT&nbsp;: 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.</p>
<p>Il y a quelques inconvénients à utiliser l'Ethernet fin. Le
premier est qu'il est limité a 10&nbsp;Mbps&nbsp;--&nbsp;pour
100&nbsp;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&nbsp;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</em> mettre
en place les `T' et les bouchons de 50 ohms. -- vous <em>ne pouvez
pas</em> juste câbler les deux machines entre elles&nbsp;!</p>
<p>NDT&nbsp;: 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</em> 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)</p>
<p>Il existe aussi des systèmes de câblage rigolos qui <em>font
comme si</em> 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.</p>
<p>(NDT&nbsp;: 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. )</p>
<h2><a name="utp"></a> <a name="ss6.2">6.2 Paire torsadée</a></h2>
<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.</p>
<p>(NdT&nbsp;: Ca c'est du pessimisme avéré. J'ai déjà fait
pire.&nbsp;:])</p>
<p>D'un autre côté, les prix des hubs sont en chute libre, toutes
les propositions Ethernet 100&nbsp;Mbps utilisent la paire
torsadée, et la plupart des installations professionnelles neuves
utilisent la paire torsadée.</p>
<p>(NDT&nbsp;: Euh, c'est peut-être aussi parce qu'avec un câblage
banalisé on peut faire de la voix (entendez&nbsp;: du téléphone),
de la donnée (entendez&nbsp;: 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&nbsp;!)</p>
<p>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.'</p>
<p>(NDT&nbsp;: 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.&nbsp;:))</p>
<p>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).</p>
<p>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&nbsp;:</p>
<pre>
        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
</pre>
<p>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&nbsp;!!!!!! A 10&nbsp;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&nbsp;MHz.</p>
<p>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.</p>
<p>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.</p>
<p>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&nbsp;! 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.</p>
<p>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).</p>
<h2><a name="ss6.3">6.3 Thick Ethernet - Le `gros'
Ethernet</a></h2>
<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.</p>
<h2><a name="utils"></a> <a name="s7">7. Configuration logicielle
et diagnostics de carte</a></h2>
<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</em> d'autres fabricants.</p>
<p>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 <code>cat /proc/net/dev</code>
--&nbsp;à condition que votre carte ait été au moins détectée au
démarrage.</p>
<p>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 <code>ifconfig eth0 down</code> en premier.</p>
<h2><a name="config"></a> <a name="ss7.1">7.1 Programmes de
configuration pour cartes Ethernet</a></h2>
<h3>Cartes WD80x3</h3>
<p>Pour ceux d'entre vous qui ont des cartes wd80x3, il existe le
programme <code>wdsetup</code> qui peut être trouvé dans
<code>wdsetup-0.6a.tar.gz</code> 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.</p>
<p>Bien entendu, vous <em>devez</em> avoir une carte avec EEPROM
pour utiliser cet utilitaire. Les vieilles, <em>vieilles</em>
cartes wd8003, et certains clones de wd8013 utilisent à la place
des cavaliers pour configurer la carte.</p>
<h3>Cartes Digital / DEC</h3>
<p>La carte EtherWorks 3 de Digital peut être configurée d'une
façon similaire au programme DOS <code>NICSETUP.EXE</code>. David
C. Davies l'a écrit, ainsi que certains autres outils pour
l'EtherWorks 3, en conjonction avec le pilote. Regardez sur
<code>metalab.unc.edu</code> dans le répertoire
<code>/pub/linux/system/Network/management</code> un fichier qui
s'appelle <code>ewrk3tools-X.XX.tar.gz</code>.</p>
<p>(NDT&nbsp;: Le lecteur français aura tout intérêt à utiliser un
site FTP plus proche, comme par exemple&nbsp;:
<code>ftp://ftp.lip6.fr/pub/linux/sunsite/system/Network/management</code>)</p>
<h3>Cartes NE2000+ ou AT/LANTIC</h3>
<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&nbsp;!) Vous pouvez récupérer le fichier
<code>/pub/linux/setup/atlantic.c</code> sur le serveur FTP de
Donald, <code>cesdis.gsfc.nasa.gov</code>, 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&nbsp;:</p>
<blockquote><a href=
"http://www.kingston.com/download/etherx/etherx.htm">Logiciel
Kingston</a></blockquote>
et récupérez <code>20XX12.EXE</code> et <code>INFOSET.EXE</code>.
<p>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.</p>
<p>Vous pouvez typiquement vous sortir de ce mauvais pas en faisant
ce qui suit&nbsp;:</p>
<p>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 <code>default.exe</code> de l'archive
<code>20XX12.EXE</code> sur cette disquette. Puis tapez <code>echo
default &gt; a:autoexec.bat</code> 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 <code>default.exe</code>, 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.</p>
<p>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 <code>atlantic</code> 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 <code>default.exe</code>.</p>
<h3>Cartes 3Com</h3>
<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
<code>/pub/linux/setup/3c5x9setup.c</code> sur le serveur FTP de
Donald, <code>cesdis.gsfc.nasa.gov</code>, 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).</p>
<h2><a name="diag"></a> <a name="ss7.2">7.2 Programmes de
diagnostic pour cartes Ethernet</a></h2>
<p>Tous les programmes de diagnostic que Donald a écrit peuvent
être obtenus à partir de cette URL.</p>
<blockquote><a href=
"ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/index.html">Diagnostics
pour cartes Ethernet</a></blockquote>
<p>Allied Telesis AT1700 -- cherchez le fichier
<code>/pub/linux/diag/at1700.c</code> sur
<code>cesdis.gsfc.nasa.gov</code>.</p>
<p>Cabletron E21XX -- cherchez le fichier
<code>/pub/linux/diag/e21.c</code> sur
<code>cesdis.gsfc.nasa.gov</code>.</p>
<p>HP PCLAN+ -- cherchez le fichier
<code>/pub/linux/diag/hp+.c</code> sur
<code>cesdis.gsfc.nasa.gov</code>.</p>
<p>Intel EtherExpress -- cherchez le fichier
<code>/pub/linux/diag/eexpress.c</code> sur
<code>cesdis.gsfc.nasa.gov</code>.</p>
<p>Cartes NE2000 -- cherchez le fichier
<code>/pub/linux/diag/ne2k.c</code> sur
<code>cesdis.gsfc.nasa.gov</code>. Il existe aussi une
version&nbsp;PCI pour les clones NE2000-PCI qui sont maintenant
classiques.</p>
<p>Adaptateur de poche RealTek (ATP) -- cherchez le fichier
<code>/pub/linux/diag/atp-diag.c</code> sur
<code>cesdis.gsfc.nasa.gov</code>.</p>
<p>Toutes les autres cartes -- essayez de taper <code>cat
/proc/net/dev</code> et <code>dmesg</code> pour savoir quelles
informations utiles le noyau possède sur la carte en question.</p>
<h2><a name="tech-intro"></a> <a name="s8">8. Informations
Techniques</a></h2>
<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.</p>
<h2><a name="data-xfer"></a> <a name="ss8.1">8.1 Entrées/Sorties
programmées contre mémoire partagée contre DMA</a></h2>
<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.</p>
<p>Le bus&nbsp;ISA peut faire du&nbsp;5,3&nbsp;Mo/s
(42&nbsp;Mbit/s), ce qui semble plus que nécessaire pour l'ethernet
a 10&nbsp;Mbps. En cas d'utilisations de cartes 100&nbsp;Mbps, il
est clair que vous aurez à utiliser un bus plus rapide pour
utiliser toute la bande passante.</p>
<h3>Entrées/Sorties (E/S) programmées (NE2000, 3c509, etc.)</h3>
<p><b>Pour&nbsp;:</b> N'utilise aucune ressource système
contrainte, juste quelques registres d'E/S, et n'a pas de limite à
16&nbsp;M.</p>
<p><b>Contre&nbsp;:</b> Généralement le taux de transfert le plus
faible, le processeur attend tout le temps, et un accès entrelacé
(<i>interleaved</i> en anglais) aux paquets est habituellement
difficile voire impossible.</p>
<h3>Mémoire partagée (WD80x3, SMC-Ultra, 3c503, etc.)</h3>
<p><b>Pour&nbsp;:</b> 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 (<i>checksum</i> 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.</p>
<p><b>Contre&nbsp;:</b> 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.</p>
<h3>Accès Direct à la Mémoire (DMA) Esclave (normal) (p.ex.&nbsp;:
aucune pour Linux&nbsp;!)</h3>
<p><b>Pour&nbsp;:</b> Libère le processeur pendant le transfert
réel des données.</p>
<p><b>Contre&nbsp;:</b> La vérification des conditions aux limites
de blocs, l'allocation de tampons (<i>buffers</i> en anglais)
contigus, et la programmation des registres DMA en font la plus
lente de toutes les techniques. Elle utilise en plus un
canal&nbsp;DMA (une ressource rare&nbsp;!) et nécessite des tampons
alignés en mémoire basse.</p>
<h3><a name="master"></a> DMA en Bus Master (p.ex.&nbsp;: LANCE,
DEC 21040)</h3>
<p><b>Pour&nbsp;:</b> 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.</p>
<p><b>Contre&nbsp;:</b> (seulement pour les cartes ISA) Nécessite
des tampons en mémoire basse et un canal&nbsp;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&nbsp;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</em> type de périphérique&nbsp;DMA est d'utiliser un
processeur&nbsp;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.)</p>
<h2><a name="skel"></a> <a name="ss8.2">8.2 Écriture d'un pilote de
carte</a></h2>
<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&nbsp;:</p>
<blockquote><a href="http://www.crynwr.com/crynwr/home.html">Pilote
en mode paquet de Russ Nelson</a></blockquote>
<p>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é.</p>
<p>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&nbsp;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.</p>
<p>(`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).</p>
<p>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 <code>;-)</code> ). 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&nbsp;:</p>
<blockquote><a href=
"http://www.redhat.com:8080/HyperNews/get/khg.html">KHG</a></blockquote>
<h2><a name="ss8.3">8.3 Inteface du pilote avec le noyau</a></h2>
<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&nbsp;: cela simplifiera les
choses.</p>
<h3>Détection de la carte (Probe)</h3>
<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</em> 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
<code>dev-&gt;???</code>, 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.</p>
<h3>Gestionnaire d'interruptions (Interrupt handler)</h3>
<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.</p>
<h3>Fonction de transmission (Transmit function)</h3>
<p>Est liée à <code>dev-&gt;hard_start_xmit()</code> 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&nbsp;?) 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 <code>dev-&gt;tbusy</code>. Quand de la
place est devenue disponible, en général au cours d'une
interruption de fin de transmission, <code>dev-&gt;tbusy</code>
doit être désarmé et les niveaux supérieurs doivent être informés
en utilisant <code>mark_bh(INET_BH)</code>.</p>
<h3>Fonction de réception (Receive function)</h3>
<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
<code>netif_rx(sk_buff)</code>. 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.)</p>
<h3>Fonction d'ouverture (Open function)</h3>
<p>Est liée à <code>dev-&gt;open</code>. Est appelée par les
couches réseau quand quelqu'un fait <code>ifconfig eth0 up</code> -
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.</p>
<h3>Fonction de fermeture (facultative) (Close function)</h3>
<p>Met la carte dans un état propre quand quelqu'un effectue
<code>ifconfig eth0 down</code>. 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).</p>
<h3>Autres fonctions</h3>
<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.</p>
<h2><a name="3com-tech"></a> <a name="ss8.4">8.4 Informations
techniques de 3Com</a></h2>
<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&nbsp;:</p>
<p>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.</p>
<p>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.</p>
<p>(NDT&nbsp;: 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.</p>
<p>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.</p>
<h2><a name="amd-notes"></a> <a name="ss8.5">8.5 Notes sur les
cartes basées sur la puce PCnet / LANCE d'AMD</a></h2>
<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&nbsp;:</p>
<p>`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.</p>
<p>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.</p>
<p>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.'</p>
<p>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.</p>
<h2><a name="promisc"></a> <a name="ss8.6">8.6 Multicast et Mode
`Promiscuous'</a></h2>
<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</em> (c'est-à-dire
<b>pas</b> les pilotes au stade `alpha') supportent aujourd'hui le
mode promiscuous.</p>
<p>Donald écrit&nbsp;: 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&nbsp;; 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&nbsp;: le <i>multicast</i>. On
peut le réaliser de deux façons&nbsp;:</p>
<ol>
<li>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&nbsp; <a href="#bpf">Le Berkeley Packet Filter</a> pour
plus d'informations.</li>
<li>Utiliser le filtre multicast que la plupart des puces Ethernet
possèdent.</li>
</ol>
<p>Je crois que je devrais donner une liste de ce que quelques
cartes ou puces Ethernet fournissent&nbsp;:</p>
<pre>

        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)
</pre>
<ol>
<li>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'.</li>
<li>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).</li>
<li>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.</li>
<li>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.</li>
</ol>
<p>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.</p>
<h2><a name="bpf"></a> <a name="ss8.7">8.7 Le filtre de paquets de
Berkeley (Berkeley Packet Filter -- BPF)</a></h2>
<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).</p>
<p>Pour ceux qui ne seraient pas au courant&nbsp;: 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.</p>
<p>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 <b>tous</b>
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.</p>
<h2><a name="notebook"></a> <a name="s9">9. Faire du réseau avec un
portable</a></h2>
<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.</p>
<h2><a name="ss9.1">9.1 Utiliser SLIP (Serial Line IP, IP sur
liaison série)</a></h2>
<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 <i>NET-2
Howto</i>.</p>
<h2><a name="pcmcia"></a> <a name="ss9.2">9.2 Support
PCMCIA</a></h2>
<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'&nbsp;8-).</p>
<p>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.</p>
<p>Il existe un certain nombre de programmes sur
<code>tsx-11.mit.edu</code> dans le répertoire
<code>/pub/linux/packages/laptops/</code> qui pourront se révéler
utiles.</p>
<p>(NDT&nbsp;: Bien entendu, le lecteur français se rapportera à
l'un des miroirs de tsx-11, comme par exemple
<code>ftp://ftp.lip6.fr/pub/linux/tsx-11/packages/laptops/</code>.)</p>
<p>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).</p>
<p>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 <code>loadlin</code>.</p>
<p>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</p>
<blockquote><a href="ftp://cb-iris.stanford.edu/pub/pcmcia">PCMCIA
Package</a></blockquote>
<p>Cherchez un fichier comme <code>pcmcia-cs-X.Y.Z.tgz</code> où
<code>X.Y.Z</code> est le dernier numéro de version. Vous devriez
aussi pouvoir le trouver sur le site FTP
<code>tsx-11.mit.edu</code> (ou son miroir le plus proche,
NDT).</p>
<p>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.</p>
<h2><a name="ss9.3">9.3 Carte Ethernet ISA dans la station
d'accueil.</a></h2>
<p>Les stations d'accueil (<i>docking stations</i> en anglais, ou
encore <i>dock</i>, 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.</p>
<h2><a name="ss9.4">9.4 Adaptateurs de poche et sur port
parallèle.</a></h2>
<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&nbsp;Ko/s en pointe&nbsp;?) à
cause des limitations du port parallèle.</p>
<p>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&nbsp;
<a href="#aep-100">alimentation du clavier</a>).</p>
<p>Consultez&nbsp; <a href="#de-600">DE-600 / DE-620</a> et&nbsp;
<a href="#aep-100">RealTek</a> pour deux adaptateurs de poche
utilisables sous Linux.</p>
<h2><a name="misc"></a> <a name="s10">10. Questions
diverses.</a></h2>
<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à.</p>
<h2><a name="lilo"></a> <a name="ss10.1">10.1 Passage des arguments
Ethernet au noyau</a></h2>
<p>Voici deux commandes génériques du noyau qui peuvent être
passées au noyau au moment du démarrage (<code>ether</code> et
<code>reserve</code>). Vous pouvez le faire avec LILO, loadlin, ou
tout autre utilitaire de démarrage qui accepte des arguments
optionnels.</p>
<p>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&nbsp;:</p>
<p><code>LILO: linux blabla=123,456,789</code></p>
<p>Pour plus d'informations, ainsi qu'une liste complète, sur les
arguments de démarrage, veuillez consulter le</p>
<blockquote><a href=
"http://metalab.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html">BootPrompt-HOWTO</a></blockquote>
<h3><a name="ether"></a> L'argument <code>ether</code></h3>
<p>La commande <code>ether=</code> est utilisée en conjonction avec
le pilote compilé dans le noyau. Le <code>ether=</code> n'aura
<em>absolument aucun effet</em> sur un pilote modulaire. Sous sa
forme la plus générique, elle ressemble à quelque chose
comme&nbsp;:</p>
<blockquote>
<code>ether=IRQ,ADR_DE_BASE,PARAM_1,PARAM_2,NOM</code></blockquote>
<p>Tous les arguments sont optionnels. Le premier argument
non-numérique est considéré comme le NOM.</p>
<p><b>IRQ:</b> 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&nbsp;--&nbsp;cela sera corrigé lorsque
quelque chose d'autre changera.</p>
<p><b>ADR_DE_BASE:</b> 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.</p>
<p><b>PARAM_1:</b> 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&nbsp;--&nbsp;défaut,
1-7&nbsp;--&nbsp;niveaux&nbsp;1 à 7 (7 étant le niveau le plus
bavard), 8&nbsp;--&nbsp;niveau&nbsp;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.</p>
<p><b>PARAM_2:</b> Le pilote 3c503 l'utilise pour choisir entre le
transceiver interne et le transceiver externe.
0&nbsp;--&nbsp;défaut/interne, 1&nbsp;--&nbsp;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.</p>
<p><b>NOM:</b> 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é.)</p>
<h3><a name="reserve"></a> La commande <code>reserve</code></h3>
<p>Cette autre commande LILO est utilisée exactement comme la
commande `<code>ether=</code>' ci-dessus, c'est-à-dire que l'on
ajoute son nom aux options spécifiées dans
<code>lilo.conf</code>&nbsp;:</p>
<blockquote>
<code>reserve=IO-base,extent{,IO-base,extent...}</code></blockquote>
<p>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</em> 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.</p>
<p>L'argument de démarrage <code>reserve</code> 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.</p>
<p>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 <code>reserve</code> sera le plus souvent utilisé avec
un autre argument de démarrage. Donc si vous spécifiez une zone de
<code>reserve</code> 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.</p>
<p>Par exemple, la ligne de démarrage</p>
<blockquote><code>LILO: linux reserve=0x300,32
ether=0,0x300,eth0</code></blockquote>
<p>oblige tous les périphériques à l'exception des pilotes Ethernet
à ne pas tester la plage <code>0x300-0x31f</code>.</p>
<p>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é <code>reserve</code>. Plusieurs
spécificateurs <code>reserve</code> fonctionneront si vous avez une
requête inhabituellement compliquée.</p>
<h2><a name="modules"></a> <a name="ss10.2">10.2 Utilisation des
pilotes Ethernet comme modules</a></h2>
<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
<code>modprobe(8)</code> dans certains cas, ils sont
automatiquement chargés par le noyau via <code>kerneld</code> (pour
les 2.0) ou <code>kmod</code> (pour les 2.1) qui eux-mêmes font
appel à <code>modprobe</code>.</p>
<p>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.</p>
<p>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 <code>/etc/conf.modules</code>. Les deux
options qui y ont le plus d'interêt (pour les cartes ethernet) sont
<code>alias</code> et <code>options</code>. La commande
<code>modprobe</code> consulte ce fichier pour obtenir des
informations sur les modules.</p>
<p>Les modules utilisés sont normalement stockés dans un répertoire
nommé <code>/lib/modules/`uname -r`/net</code> où la commande
<code>uname -r</code> retourne la version du noyau (ex&nbsp;:
2.0.34). Vous pouvez aller y faire un tour pour savoir quels
modules correspondent à votre carte.</p>
<p>La première chose à mettre dans votre
<code>/etc/conf.modules</code> est une ligne indiquant à
<code>modprobe</code> où se trouve le pilote à utiliser avec
<code>eth0</code> (et <code>eth1</code>, ...), ceci grâce à un
alias. Par exemple, si vous avez une carte ISA SMC EtherEZ qui
utilise le module <code>smc-ultra.o</code>, vous aurez besoin de
créer un alias entre ce pilote et <code>eth0</code> en ajoutant
cette ligne&nbsp;:</p>
<pre>
        alias eth0 smc-ultra
</pre>
<p>Vous pourrez aussi avoir à ajouter une ligne
d'<code>options</code> indiquant lesquelles doivent être utilisées
avec tel module (ou alias de module). Continuons l'exemple
ci-dessus&nbsp;: avec la ligne <code>alias</code> seule, le noyau
vous préviendrait (cf. <code>dmesg</code>) que l'autodétection des
cartes ISA n'est <em>pas</em> 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
<code>0x280</code>.</p>
<pre>
        options smc-ultra io=0x280
</pre>
<p>La plupart des modules ISA acceptent des arguments comme
<code>io=0x340</code> et <code>irq=12</code> sur la ligne de
commande d'<code>insmod</code>. Il est <em>REQUIS</em> ou du moins
<em>FORTEMENT RECOMMANDÉ</em> 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.</p>
<p>Une liste de toutes les options acceptées par chaque module se
trouve dans le fichier&nbsp;:</p>
<p>
<code>/usr/src/linux/Documentation/networking/net-modules.txt</code></p>
<p>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.</p>
<hr>
<pre>
        option 3c503 io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
</pre>
<hr>
<p>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.</p>
<p>Notez aussi que les modules <code>utilisés</code> ne peuvent
être supprimés de la mémoire. Cela signifie que vous aurez à faire
un <code>ifconfig eth0 down</code> (arrêter la carte ethernet)
avant de pouvoir les supprimer.</p>
<p>La commande <code>lsmod</code> vous dira quels sont les modules
qui sont chargés, s'ils sont utilisés, et <code>rmmod</code> les
supprimera.</p>
<h2><a name="ss10.3">10.3 Documents associés</a></h2>
<p>La plupart des informations que vous trouvez dans ce document
proviennent de messages sauvegardés des groupes de
<code>comp.os.linux.*</code>, 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.</p>
<p>Bien entendu, si vous configurez une carte Ethernet, vous
voudrez configurer les logiciels que vous allez utiliser, et vous
lirez pour cela le <i>Howto NET-3</i>. 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...</p>
<p>Pour ceux d'entre vous qui recherchent des informations qui ne
sont pas spécifiques à Linux (comme&nbsp;: 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
<code>comp.dcom.lans.ethernet</code> et/ou
<em>comp.sys.ibm.pc.hardware.networking</em>. Les archives de news
tels que <code>deja.com</code> sont aussi une source intarissable
de réponses. Vous pouvez aussi récupérer les FAQ de ces groupes de
news sur par exemple&nbsp;:</p>
<blockquote><a href=
"ftp://ftp.lip6.fr/pub/doc/faq/usenet-by-hierarchy/">Les FAQ de
Usenet</a></blockquote>
<p>Vous pouvez aussi consulter la `Page d'accueil d'Ethernet' pour
ainsi dire, qui se trouve à l'URL suivante&nbsp;:</p>
<blockquote><a href=
"http://wwwhost.ots.utexas.edu/ethernet/ethernet-home.html">La page
d'accueil d'Ethernet</a></blockquote>
<h2><a name="copyright"></a> <a name="ss10.4">10.4 Désistement de
responsabilité et Copyright</a></h2>
<p>Ce document <em>n'est pas</em> 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&nbsp;!) 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <i>Linux
HOWTO</i> 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>
<p>En accord avec cette notice, la version originale (en anglais)
telle qu'elle apparaît dans l'<i>Ethernet-HOWTO</i> est fournie
ici&nbsp;:</p>
<p>This document is <em>not</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>Permission is granted to copy and distribute translations of
this document into another language, under the above conditions for
modified versions.</p>
<p>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 <code>diff -u
old.sgml new.sgml</code> 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.</p>
<p>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>
<p>Ce document fait partie des <i>HOWTO Linux</i> traduits en
français. Vous pouvez trouver une liste à jour de ces documents à
l'adresse <a href=
"http://www.freenix.org/unix/linux/HOWTO/Liste-des-HOWTO.html">http://www.freenix.org/unix/linux/HOWTO/Liste-des-HOWTO.html</a></p>
<p>Les <i>HOWTO Linux</i> font partie du <i>Linux Documentation
Project</i> (LDP). Si vous souhaitez participer au LDP ou à sa
traduction en français, vous pouvez consulter <a href=
"http://www.freenix.org/unix/linux/HOWTO/Liste-des-HOWTO.html">http://www.freenix.org/unix/linux/HOWTO/Liste-des-HOWTO.html</a>
ou contacter Eric Dumas, <code>dumas@linux.eu.org</code>.</p>
<p>Cette version française a été réalisée par Mathieu Arnold
<code>&lt;arn_mat@club-internet.fr&gt;</code>, Stéphane Alnet
<code>&lt;alnet@u-picardie.fr&gt;</code> était l'ancien traducteur.
Elle est Copyright (c) 1997-1998, Mathieu Arnold, selon les termes
de la notice ci-dessus.</p>
<p>Si vous constatez des erreurs <em>dans la traduction</em> en
français, merci d'en informer le traducteur. Vos remarques seront
prises en compte pour la prochaine version de la traduction.</p>
<h2><a name="ss10.5">10.5 Conclusion</a></h2>
<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.</p>
<p>Merci&nbsp;!</p>
<p>Paul Gortmaker, <code>p_gortmaker@yahoo.com</code></p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / Ethernet-HOWTO.html
