
  Linux Ethernet-Howto
  par Paul Gortmaker Version francaise: Stephane Alnet
  Version anglaise: v2.65, 1er fevrier 1997

  Ceci  est  l'Ethernet-Howto,  une  compilation  d'informations sur les
  peripheriques Ethernet qui peuvent etre utilises  avec  Linux,  et  la
  facon  de  les  mettre en oeuvre. Ce document espere repondre a toutes
  les questions frequemment posees sur l'utilisation des cartes Ethernet
  sous  Linux.  Notez  que  ce  Howto  se  limite a l'aspect materiel et
  pilotes de bas niveau des cartes Ethernet, et ne couvre pas la  partie
  logicielle   de   choses   comme   ifconfig  et  route.  Consultez  le
  Network Howto pour cela.

  1.  Introduction

  L'Ethernet-Howto indique quelles cartes vous devez  ou  ne  devez  pas
  acheter;  comment  les configurer, comment en utiliser plus d'une a la
  fois, et d'autres problemes et questions classiques. Il  contient  des
  informations  detaillees sur le niveau actuel de suivi pour toutes les
  cartes Ethernet courantes disponibles.

  Il ne couvre pas l'aspect logiciel des choses, tel  qu'il  est  decrit
  dans  le  Network  Howto.  Notez aussi que les questions generales sur
  Ethernet, non liees specifiquement a Linux, ne sont pas (ou  du  moins
  ne  devraient  pas)  faire  partie  de  ce document.  Pour ce genre de
  questions, consultez l'excellente somme d'informations de  la  FAQ  du
  groupe  comp.dcom.lans.ethernet.  Vous pouvez l'obtenir par FTP depuis
  rtfm.mit.edu de la meme maniere que vous obtenez les autres FAQ.

  La presente version couvre les noyaux de  distribution  jusqu'a  et  y
  compris  la version 2.0.33.  Des informations concernant les noyaux de
  developpement jusqu'a la version 2.1.82 sont aussi fournies.

  L'Ethernet-Howto est de:

       Paul Gortmaker, gpg109@rsphy1.anu.edu.au

  La principale source d'information pour la premiere version, en  ASCII
  pur de l'Ethernet-Howto etait:

       Donald J. Becker, becker@cesdis.gsfc.nasa.gov

  que  nous  devons aussi remercier pour l'ecriture de la vaste majorite
  des pilotes de cartes Ethernet qui sont aujourd'hui  disponibles  pour
  Linux. Il est aussi l'auteur originel du serveur NFS. Merci Donald!

  Les  amateurs du WWW auront certainement envie d'aller consulter l'URL
  suivante:

       Donald     Becker      <http://cesdis.gsfc.nasa.gov/pub/peo-
       ple/becker/whoiam.html>

  Consultez  le  desistement de responsabilite (section ``Desistement de
  responsabilite et Copyright'') et les informations sur la copie  a  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 faites...'.

  La version francaise est de

       Stephane Alnet, alnet@u-picardie.fr.

  1.1.  Nouvelles versions de ce document

  Les  nouvelles versions de ce document peuvent etre rapatriees par FTP
  anonyme depuis:

       Sunsite          HOWTO          Archive          <ftp://sun-
       site.unc.edu/pub/Linux/docs/HOWTO/>

  et les divers sites miroirs FTP de Linux.

  (NDT:  En  France,  vous  prefererez  utiliser le site suivant pour le
  document originel:

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

  ou, mieux, la version francaise:

  Archive        des        HOWTO        francais        sur        LIP6
  <ftp://ftp.lip6.fr/pub/linux/french/HOWTO/>

  Archive        des       HOWTO       francais       chez       Freenix
  <http://www.freenix.fr/linux/french/HOWTO/>)

  Des mises a jour seront realisees au fur et a mesure de  l'arrivee  de
  nouvelles informations et/ou de nouveaux pilotes. Si la copie que vous
  etes en train de lire date de plus de 6 mois, c'est soit qu'elle n'est
  plus bonne, soit que j'ai ete trop faineant pour la mettre a jour.

  Si  vous  m'avez  fait  parvenir  une mise-a-jour et qu'elle n'est pas
  incluse dans la version suivante, c'est sans doute que je l'ai  perdue
  dans  les  tonnes  de  courriers  electroniques  ininteressants que je
  recois.   Soyez  gentil  de  la  re-envoyer  (avec   un   message   de
  protestation) et j'essaierai de m'assurer qu'elle soit incluse dans la
  prochaine version.

  Ce document a ete produit en utilisant le systeme SGML  mis  au  point
  specifiquement  pour  le  projet Linux Howto, et des formats de sortie
  varies sont disponibles, dont Postscript, DVI, ASCII, HTML, et bientot
  TeXinfo.

  Je recommanderai de consulter ce document sous sa forme HTML (a l'aide
  d'un navigateur WWW) ou sa  forme  Postscript/DVI.  Ces  deux  formats
  contiennent  des  references  croisees  qui  sont  perdues  lors de la
  traduction en ASCII.

  Si vous souhaitez obtenir la copie officielle  depuis  Sunsite,  voici
  son URL.  (NDT: Elle est en anglais bien evidemment!)

       Ethernet-HOWTO   <http://sunsite.unc.edu/mdw/HOWTO/Ethernet-
       HOWTO.html>

  1.2.  Ethernet-Howto, mode d'emploi

  Comme ce guide devient de plus en plus gros, vous n'avez  certainement
  pas  l'intention  de  passer  la  fin de votre apres-midi a le lire en
  entier. Et la bonne nouvelle est que vous n'etes pas oblige(e)  de  le
  lire du tout.

  Il  y  a  des  chances pour que vous lisiez ce document parce que vous
  n'arrivez pas a faire marcher le tout, et que vous ne savez  pas  quoi
  faire  ou  quoi  verifier.  La prochaine section (``Au secours - Ca ne
  marche pas!'') est destinee aux neophytes de Linux et  vous  indiquera
  la bonne direction.

  Typiquement,  les memes problemes et les memes questions sont re-poses
  sans arret par des personnes differentes. Il y a des chances que votre
  probleme  ou  votre  question  specifique  soit l'une de ces questions
  frequemment posees, et qu'elle trouve sa reponse dans  la  partie  FAQ
  (NDT:  Foire  Aux  Questions)  de  ce  document.  (Voir ``La Foire Aux
  Question'').  Tout le monde devrait  y  jeter  un  coup  d'oeil  avant
  d'envoyer un message demandant de l'aide.

  Si  vous  n'avez  pas encore de carte Ethernet, vous devriez commencer
  par  vous  decider  sur  une  carte.   (Voir  ``Quelle  carte  dois-je
  acheter...'')

  Si  vous  avez deja une carte Ethernet mais que vous n'etes pas sur(e)
  de pouvoir l'utiliser avec Linux, lisez-donc la section  qui  contient
  les informations specifiques a chaque constructeur, et a leurs cartes.
  (Voir ``Informations Specifiques...'')

  Si vous etes interesse(e) par l'un des aspects techniques des  pilotes
  de    peripheriques    de    Linux,    allez    donc    consulter   la
  section ``Informations Techniques'' qui contient ces informations.

  1.3.  Au secours! - Ca ne marche pas!

  Bon, ne paniquez pas. Cette section  va  vous  indiquer  le  chemin  a
  suivre  pour  que  les choses fonctionnent, meme si vous n'avez pas de
  connaissances prealables sur Linux ou le materiel Ethernet.

  La premiere chose a faire est de trouver quel est le modele  de  votre
  carte,  afin  de  pouvoir determiner si Linux dispose d'un pilote pour
  cette carte-la. Des cartes differentes sont typiquement controlees  de
  facon  differente  par l'ordinateur qui les accueille, et le pilote de
  peripherique de Linux (s'il en existe un) contient ces informations de
  controle qui permettent a Linux d'utiliser la carte.

  Si  vous n'avez pas de manuel ou de chose de ce genre qui vous indique
  quel est le modele de la carte, vous pouvez alors essayer ce  qui  est
  decrit  dans  la  section  ``Identifier  une carte inconnue'' qui vous
  aidera sur les cartes mysterieuses.

  Maintenant que vous savez quel type de  carte  vous  avez,  lisez  les
  details  concernant  votre  carte  dans la section destinee aux cartes
  (section  ``Informations  Specifiques...''),  qui  liste   par   ordre
  alphabetique  les constructeurs de carte, les numeros de chaque carte,
  et precise si elle possede un pilote pour Linux ou non. Si votre carte
  est  indiquee  comme  `Non-supportee',  vous  pouvez pratiquement vous
  arreter des maintenant. Si vous ne pouvez pas trouver votre carte dans
  la  liste, verifiez alors si le manuel de votre carte ne l'indique pas
  comme `compatible' avec un autre type de carte connue. Par exemple, il
  existe  des  centaines, si ce n'est des milliers de cartes differentes
  qui ont ete concues pour etre  compatible  avec  le  modele  d'origine
  NE2000 de Novell.

  A  supposer  que  vous  ayez  trouve  que votre carte a un pilote sous
  Linux, vous devez maintenant revenir au CD-ROM ou a quoi que  ce  soit
  d'autre  que  vous  avez  utilise pour l'installation, pour trouver la
  liste des noyaux precompiles qu'il contient. Le noyau est  le  systeme
  d'exploitation  de  base  qui est charge en premier au demarrage de la
  machine, et qui contient  les  pilotes  pour  differentes  parties  du
  materiel, entre autres. Ce n'est pas parce que Linux possede un pilote
  pour votre carte qu'il est pour autant installe dans tous les  noyaux.
  Selon  qui a concu le CD-ROM, il peut n'y avoir que tres peu de noyaux
  tout prets, et tout un  tas  de  pilotes  sous  la  forme  de  modules
  separes,  ou  il  peut  y avoir tout un tas de noyaux, qui couvrent un
  grand nombre de combinaisons de pilotes precompiles. Heureusement,  il
  y  aura  aussi  un  fichier-texte  avec  eux, qui donnera la liste des
  pilotes et les noyaux  dans  lesquels  ils  sont  inclus.  Essayez  de
  trouver  un  noyau qui est indique comme contenant le pilote dont vous
  avez besoin, ou essayez de trouver un module possedant le  nom  de  ce
  pilote.

  Si  vous  trouvez  un noyau precompile qui contient votre pilote, vous
  devez demarrer votre machine en utilisant ce noyau  plutot  que  celui
  que   vous  utilisez  actuellement.  La  plupart  des  systemes  Linux
  utilisent LILO  pour  demarrer,  et  la  documentation  de  LILO  aura
  certainement ete installee sur votre systeme.  Suivez les instructions
  de la documentation pour demarrer un autre noyau, parce que  ce  sujet
  n'est pas l'objet de ce document-ci.

  (NDT:  Vous  pourrez  utilement  consulter  le LILO-MiniHowto si votre
  boot-loader est LILO, par exemple.)

  Si au contraire vous avez trouve  un  petit  module  qui  contient  le
  pilote,  vous  aurez  besoin d'attacher ce module au noyau apres qu'il
  ait demarre. Consultez les  informations  de  votre  distribution  sur
  l'installation  et l'utilisation des modules, ainsi que la section sur
  les modules du present document  (section  ``Utilisation  des  pilotes
  Ethernet comme modules'').

  Si  vous n'avez trouve ni un noyau precompile avec votre pilote, ni ce
  pilote sous la forme d'un module, il y a des  chances  pour  que  vous
  ayez  une  carte  particulierement  peu  banale,  et  vous  allez etre
  oblige(e) de construire votre propre noyau en incluant ce pilote.  Une
  fois  que  Linux  est installe, construire un noyau personnalise n'est
  pas difficile du tout. Vous repondez essentiellement oui ou non  a  ce
  que  vous  souhaitez que le noyau comprenne, et ensuite vous lui dites
  de le construire. Il existe un Kernel-HowTo qui vous aidera a cela.

  (NDT: et sa version francaise, accessible sur

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

  Arrive  a ce point, vous devez etre parvenu d'une facon ou d'une autre
  a demarrer un noyau avec votre pilote integre, ou a charger ce  pilote
  comme  un  module.  A peu pres la moitie des problemes qu'ont les gens
  est liee au fait que le pilote n'a pas ete charge d'une maniere ou  de
  l'autre,  donc  vous  devriez  trouver  que  les  choses fonctionnent,
  maintenant.

  Si cela ne fonctionne toujours pas, vous devriez alors verifier si  le
  noyau  a bel et bien detecte la carte. Pour ce faire, vous devez taper
  dmesg | more une fois logge, apres que le systeme  a  demarre  et  que
  tous  les modules ont ete charge. Cela vous permettra de consulter les
  messages de demarrage que le noyau a fait defiler sur  l'ecran  durant
  le  processus  de  demarrage. Si la carte a ete detectee, vous devriez
  voir quelque part dans cette liste un message du pilote de votre carte
  commencant  par  eth0,  indique  le  nom  du  pilote et les parametres
  materiels (reglage d'interruption  (IRQ),  de  ports  d'entree-sorties
  (E/S),  etc..) pour lesquels la carte est reglee. Si vous ne voyez pas
  de message de ce type, alors le pilote n'a pas detecte votre carte, et
  c'est  pour  cela  que  cela  ne  fonctionne  pas.  Consultez  la  FAQ
  (section ``La Foire Aux Questions'') pour savoir quoi faire  si  votre
  carte  n'est  pas detectee.  Si vous avez une carte compatible NE2000,
  vous y trouverez aussi des trucs specifiques pour faire  detecter  une
  NE2000.

  Si  la  carte a ete detectee, mais que le message de detection indique
  une quelconque erreur, comme un conflit de ressource, alors le  pilote
  ne  s'est  probablement  pas correctement initialise et la carte n'est
  toujours pas utilisable. La plupart des messages d'erreur de  ce  type
  sont eux aussi listes dans la FAQ, ainsi que leur solution.

  Si  le  message  de  detection parait correct, verifiez de nouveau les
  ressources indiquees par le pilote en les comparant avec  celles  pour
  lesquelles  la  carte  est  physiquement  configuree (soit a 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  configuree
  (physiquement ou par logiciel) pour utiliser l'IRQ 15 et que le pilote
  indique IRQ 10 dans les messages de demarrage,  quelque  chose  ne  va
  pas.  La FAQ discute les cas les plus courants ou un pilote ne detecte
  pas correctement les informations de configuration de diverses cartes.

  Arrive  la, vous etes arrive(e) a faire detecter votre carte avec tous
  les parametres corrects, et l'on peut esperer que tout fonctionne.  Si
  ce  n'est pas le cas, vous avez alors soit une erreur de configuration
  logicielle, soit une erreur de configuration materielle. Une erreur de
  configuration  logicielle  serait  de  ne pas avoir configure la bonne
  adresse de reseau pour l'une des commandes ifconfig ou route  (ou  les
  deux!);  la  maniere  de  proceder  est  decrite  en  detail  dans  le
  Network HowTo et  le  `Guide  de  l'Administrateur  Reseau'  (`Network
  Administrator's  Guide' (NAG) en anglais) qui se trouvent certainement
  tous les deux sur le CD-ROM d'installation.

  Une erreur de configuration materielle se produit  quand  un  type  de
  conflit de ressources ou une mauvaise configuration (que le pilote n'a
  pas  detecte  au  demarrage)   empeche   la   carte   de   fonctionner
  correctement.  Vous pouvez typiquement observer cela sous trois formes
  differentes.  (1) Vous obtenez un message  d'erreur  lorsque  ifconfig
  essaie   d'ouvrir   le   peripherique   pour   l'utiliser,   du  genre
  ``SIOCSFFLAGS: Try  again''.   (2)  Le  pilote  indique  des  messages
  d'erreur  sur  eth0  (que  vous  pouvez voir avec dmesg | more) ou des
  incoherences etranges a chaque  fois  qu'il  essaie  d'envoyer  ou  de
  recevoir des donnees.  (3) Le fait de taper cat /proc/net/dev donne un
  nombre non nul dans l'une des colonnes  errs,  drop,  fifo,  frame  ou
  carrier pour eth0.  La plupart des erreurs de configuration materielle
  typiques sont elles aussi discutees dans la FAQ.

  Eh bien, si vous etes parvenu  a  ce  point  et  que  cela  ne  marche
  toujours pas, lisez la section FAQ de ce document, lisez le paragraphe
  specifique   a   votre   carte   dans   la   section    ``Informations
  Specifiques..'',  et  si  cela  ne  fonctionne toujours pas alors vous
  pourrez recourir a  un  envoi  de  message  dans  un  groupe  de  news
  approprie  pour  demander de l'aide.  Si vous devez poster un message,
  veuillez detailler toute information  interessante  dans  ce  message,
  comme  la  marque  de  la  carte, la version du noyau, les messages du
  pilote au demarrage, le resultat de cat /proc/net/dev, une description
  claire  du  probleme,  et bien entendu ce que vous avez deja essaye de
  faire en vue de faire fonctionner l'ensemble.

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

  2.  Quelle carte dois-je acheter pour Linux?

  La reponse a cette question depend fortement de ce que vous  escomptez
  faire  avec  votre  connexion  reseau, et de la quantite de trafic que
  vous verrez.

  Si vous escomptez qu'un utilisateur isole  effectue  occasionnellement
  une  session  FTP ou une connexion WWW, alors une vieille carte 8 bits
  vous rendra probablement heureux.

  Si vous avez l'intention de mettre en place un serveur,  et  que  vous
  exigez  que  la  surcharge  processeur  liee  a  la  reception et a la
  transmission des paquets Ethernet reste la plus basse  possible,  vous
  devrez  certainement  considerer une des cartes PCI les plus recentes,
  comportant la puce 21040 de DEC, ou la puce PCnet-PCI d'AMD.

  Si vous vous trouvez au milieu de ces deux extremes,  alors  n'importe
  quelle carte ISA 16 bits possedant un pilote stable vous conviendra.

  2.1.  Quels sont les pilotes stables, alors?

  Parmi  les cartes ISA 16 bits, les pilotes suivants sont tres murs, et
  vous ne devriez pas avoir de problemes si vous achetez une  carte  qui
  utilise ces pilotes:

       SMC-Ultra/EtherEZ, WD80x3, 3c509, 3c503/16, Lance, NE2000.

  Ceci  ne  signifie pas que tous les autres pilotes sont instables.  Il
  se trouve juste que ceux-ci sont les plus anciens et les plus utilises
  des pilotes Linux, ce qui en fait le choix le plus sur.

  Notez   que  certaines  cartes-meres  pas  cheres  peuvent  avoir  des
  problemes avec la maitrise de bus  que les cartes Lance realisent,  et
  que  certains  clones  NE2000  pas  chers  ont  des difficultes a etre
  detectes au demarrage.

  En ce qui concerne les cartes PCI, les cartes PCnet-PCI qui  utilisent
  le  pilote  Lance  sont  un  choix sur (en dehors des cartes Boca, car
  elles comportent des vices materiels). L'Allied Telsyn AT2450 est  une
  implementation  de  la  puce  PCnet-PCI  qui  est reputee pour son bon
  fonctionnement.

  Le pilote DEC 21040 `tulip' et  le  pilote  3c59x  `vortex'  sont  des
  pilotes  relativement  nouveaux,  mais qui ont deja prouve qu'ils sont
  pratiquement stables.

  2.2.  Cartes 8 bits contre cartes 16 bits

  Vous ne pourrez certainement  plus  acheter  une  carte  Ethernet  ISA
  8  bits  de  nos  jours,  mais vous en trouverez encore plein dans les
  annees qui viennent sur les marches aux puces informatiques ou  autres
  braderies,  et  ce a des prix vraiment tres bas. Cela les rend ideales
  pour les systemes ``Ethernet-a-la-maison''.

  Des cartes 8 bits  qui  donneront  de  bonnes  performances  pour  une
  utilisation  faible  a  moderee sont la wd8003, la 3c503 et la ne1000.
  La  3c501   donnera   des   resultats   faibles,   et   ces   reliques
  antediluviennes (12 ans!) des jours du XT sont a eviter.

  Le  canal  de  donnees  8  bits  n'attenue  pas trop les performances,
  puisque vous pouvez encore esperer obtenir 500 a 800 Ko/s  en  vitesse
  de  transfert FTP pour une carte 8 bits wd8003 (sur un bus ISA rapide)
  a partir d'un serveur rapide. Et si la plupart de votre trafic  reseau
  est  a  destination  de  sites  eloignes,  le goulot d'etranglement se
  situera ailleurs sur le chemin, la seule  difference  de  vitesse  que
  vous  noterez  se  produisant  lorsqu'il  y  a de l'activite sur votre
  reseau local.

  2.3.  Cartes 32 bits / VLB / PCI

  Les pilotes de cartes Ethernet 32 bits sont peu nombreux parce que les
  cartes  Ethernet  32  bits  sont  peu nombreuses.  Les cartes Ethernet
  32 bits sont peu nombreuses parce qu'un reseau a 10 Mbit/s ne justifie
  pas l'ecart de prix important pour acceder a l'interface 32 bits. Mais
  maintenant que les reseaux 100 Mbit/s deviennent  plus  courants,  les
  choses changent neanmoins.

  Consultez  ``E/S  programmees  contre...''  pour savoir pourquoi avoir
  une carte Ethernet 10 Mbit/s sur un bus ISA a 8 MHz ne  constitue  pas
  un  goulot  d'etranglement.  Meme  si le fait que la carte Ethernet se
  trouve sur un bus rapide ne signifie pas que les transferts sont  plus
  rapides,  cela  signifiera  souvent  une  surcharge  processeur  moins
  importante, ce qui est bon pour les systemes multi-utilisateurs.

  AMD offre les puces 32 bits PCnet-VLB et PCnet-PCI.   Consultez  ``AMD
  PCnet-32''  pour plus d'informations sur la version 32 bits de la puce
  LANCE / PCnet-ISA.

  La puce 21040 PCI de DEC est une autre  option  (voir  ``DEC  21040'')
  pour  les  utilisateurs de puissance. De nombreux fabricants proposent
  des cartes basees sur cette puce, et les prix de  ces  cartes  ``sans-
  nom'' sont generalement bas.

  Les  cartes  PCI `Vortex' et `Boomerang' de 3Com constituent aussi une
  autre option, et le prix reste correct si vous pouvez en  obtenir  une
  tant que leur proposition d'evaluation dure

  (NDT:  Je  n'en  ai  jamais  entendu  parle en France, en tout cas pas
  depuis le printemps 97.)

  Des fabricants de clones ont commence a produire  des  clones  PCI  de
  ne2000,  bases  sur  une  puce  RealTek ou une puce Winbond. Le pilote
  Linux ne2000 des noyaux 2.0.31 et  superieurs  acceptera  ces  cartes.
  Cependant  vous  ne beneficierez que de la vitesse plus elevee du bus,
  puisque ces cartes utiliseront encore  l'interface  du  pilote  de  la
  ne2000, qui commence a dater.

  2.4.  Cartes et pilotes 100 M disponibles

  La liste des materiels 100 M reconnus par Linux a l'heure actuelle est
  la suivante: les cartes basees sur  la  puce  DEC  21140;  les  cartes
  3c595/3c90x  Vortex;  et  la  HP  100VG ANY-LAN.  Les pilotes des deux
  premieres sont relativement stables,  mais  les  informations  sur  le
  pilote de la HP sont peu nombreuses jusqu'a present.

  L'EtherExpressPro10/100B possede maintenant un pilote, present dans le
  noyau 2.0 courant.  Pour  les  mises-a-jour  et/ou  des  informations,
  consultez la section correspondante dans ce document.

  La  puce  100Base-?   21140  est supportee avec le meme pilote que son
  equivalent 10 M, la 21040. Les cartes PCI 100 Mbs  EtherPower  de  SMC
  utilisent  cette  puce. Comme pour la 21040, vous aurez le choix entre
  deux pilotes.

  Allez aussi jeter un coup d'oeil sur le site WWW de  Donald,  a  l'URL
  suivante:

  Ethernet                  100M                  <http://ces-
  dis.gsfc.nasa.gov/linux/misc/100mbs.html>

  Donald a fait un bon bout de chemin avec les cartes  EtherPower-10/100
  de  SMC,  et  indique  qu'il  a obtenu pres de 4.6Mo/s d'application a
  application en TCP sur des machines a  processeur  Pentium  100,  puce
  Triton.   (Consultez ``3c595'' et ``DEC 21140'' pour plus de details.)

  Pour des informations sur le 100VG, consultez la section suivante,  et
  cette URL sur le site de Donald:

       La      page      100VG      de      Donald     <http://ces-
       dis.gsfc.nasa.gov/linux/drivers/100vg.html>

  Vous serez peut-etre aussi interesse(e) par:

       La page  Fast  Ethernet  de  Dan  Kegel  <http://alumni.cal-
       tech.edu/~dank/fe/>

  2.5.  100VG contre 100BaseT

  La   plaquette   publicitaire   suivante  est  extraite  d'un  message
  desesperement   bourre   d'informations   poste   par   Donald    dans
  comp.os.linux; elle resume bien la situation:

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

  Le 100VG est arrive sur le marche le  premier,  et  je  sentais  qu'il
  etait  mieux  pense  que  le  100baseTx. J'etais persuade qu'il allait
  gagner, mais visiblement ce ne sera pas le cas.  HP  et  consorts  ont
  fait plusieurs mauvais choix:

  1)  Retarder  la norme de maniere a ce qu'ils puissent amadouer IBM et
  accepter les trames Token Ring. Cela `ressemblait a une bonne  idee  a
  l'epoque',  puisque  cela aurait permis aux boutiques Token Ring de se
  mettre a jour sans devoir faire admettre aux decideurs qu'ils  avaient
  fait  une  enorme bourde en s'acoquinant avec la mauvaise technologie.
  Mais il n'y avait rien a gagner, parce que les deux types de trames ne
  peuvent  pas  coexister  sur  un  reseau,  parce que Token Ring est un
  marecage de complexite , et que IBM a quand meme adopte 100baseT  pour
  finir.

  2)  Ne  produire  que  des  cartes ISA et EISA. (Un modele PCI n'a ete
  annonce que recemment.)  Le bus ISA est  trop  lent  pour  100  M,  et
  relativement  peu  de  machines  EISA  existent.  A l'epoque VLB etait
  classique, rapide, et economique, PCI restant un choix viable. Mais la
  sagesse   des  ``anciens''  disait  que  les  serveurs  continueraient
  d'utiliser le bus EISA hors de prix.

  3) Ne pas m'envoyer une documentation.  Oui,  cela  a  ete  la  raison
  reelle  du  declin du 100VG :-).  J'ai appele partout pour obtenir des
  infos de programmation, et tout ce que  j'ai  pu  obtenir  a  ete  une
  brochure  de quelques pages sur papier glace de AT&T decrivant combien
  le jeu de puce Regatta etait merveilleux.''

  (NDT: ``La norme 100 BAS VG - any LAN proposee par HP (...) ne reprend
  pas  le  principe  du  protocole  Ethernet mais utilise le principe du
  polling. L'utilisation du mot Ethernet a donc ici plutot une  vocation
  commerciale.  Il  faut  changer  les  coupleurs  dans  les stations de
  travail. Toutefois, on conserve les principaux systemes de  cablage.''
  (Pierre Rolin, in ``Reseaux haut debit'', Hermes, 1995). Fin 1997 plus
  personne ne parle de 100VG.

  La norme 100baseT4 utilise un cablage categorie 3 et 4,  100baseTx  un
  cablage categorie 5, 100baseFx de la fibre optique.)

  2.6.

  Entrees/Sorties programmees contre memoire partagee contre DMA

  Ethernet fait 10 Mbit/s. (Ne soyez pas  pedant,  le  3  Mbit/s  et  le
  100  Mbit/s  ne comptent pas.)  Si vous savez deja envoyer et recevoir
  des  paquets  les  uns  derriere  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 a la suite  des
  autres.  Les  pilotes  Linux DP8390 (wd80x3, SMC-ULTRA, 3c503, ne2000,
  etc) s'approchent tres pres de l'envoi de paquets les uns derriere les
  autres  (cela dependra du temps de latence d'interruption courant), et
  la 3c509 ou l'AT1500 n'ont absolument aucun probleme pour emettre  des
  paquets les uns derriere les autres.

  Le  bus ISA peut faire du 5,3 Mo/s (42 Mbit/s), ce qui semble plus que
  necessaire. Vous pouvez utiliser cette  bande  passante  de  plusieurs
  facons, qui sont listees ci-dessous.

  2.6.1.  Entrees/Sorties (E/S) programmees (NE2000, 3c509, etc.)

  Pour: N'utilise aucune ressource systeme  contrainte,  juste  quelques
  registres d'E/S, et n'a pas de limite a 16 M.

  Contre:   Generalement  le  taux  de  transfert  le  plus  faible,  le
  processeur attend tout le temps, et un acces entrelace (interleaved en
  anglais) aux paquets est habituellement difficile voire impossible.

  2.6.2.  Memoire partagee (WD80x3, SMC-Ultra, 3c503, etc.)

  Pour:  Simple,  plus  rapide  que  les E/S programmees, permet l'acces
  aleatoire aux  paquets.  Les  pilotes  Linux  calculent  la  somme  de
  controle (checksum en anglais) des paquets IP entrants lorsqu'ils sont
  copies depuis la carte, ce qui entraine une  reduction  supplementaire
  de  la charge du processeur par rapport a une carte equivalente en E/S
  programmees.

  Contre: Utilise beaucoup d'espace memoire (c'est  important  pour  les
  utilisateur  sous  DOS,  cela  n'a  pratiquement pas d'importance sous
  Linux), et charge encore le processeur.

  2.6.3.  (p.ex.: aucune pour Linux!)  Acces Direct a la  Memoire  (DMA)
  Esclave (normal)

  Pour: Libere le processeur pendant le transfert reel des donnees.

  Contre:   La   verification  des  conditions  aux  limites  de  blocs,
  l'allocation  de  tampons  (buffers  en  anglais)  contigus,   et   la
  programmation  des  registres  DMA en font la plus lente de toutes les
  techniques. Elle utilise en plus un canal DMA  (une  ressource  rare!)
  et necessite des tampons alignes en memoire basse (NDT: affreux!).

  2.6.4.  (p.ex.: LANCE, DEC 21040) DMA en Maitre de Bus (Bus Master)

  Pour: Libere le processeur pendant le transfert des donnees, peut lier
  des tampons entre eux, peut necessiter peu voir pas de perte de  temps
  processeur sur le bus ISA.

  Contre:  Necessite  des tampons en memoire basse et un canal DMA. Tout
  Maitre de Bus aura des problemes avec les autres Maitres  de  Bus  qui
  sont  des  goinfres,  comme certaines cartes SCSI primitives. Quelques
  jeux de puces pour cartes-meres mal penses ont des problemes avec  les
  maitres   de   bus.   Et   une  raison  pour  n'avoir  aucun  type  de
  peripherique DMA est  d'utiliser  un  processeur  486  concu  pour  le
  remplacement  (en  place) d'un 386: ces processeurs doivent vider leur
  cache a  chaque  cycle  DMA.  (Ceci  inclus  les  Cx486DLC,  Ti486DLC,
  Cx486SLC, Ti486SLC, etc.)

  2.7.

  Les types de cables que votre carte peut accepter

  Si vous mettez en place un petit reseau ``personnel'', vous prefererez
  certainement utiliser le ``thinnet'' ou cable Ethernet fin.  C'est  le
  modele  avec  les  connecteurs  BNC  standards.   Consultez  ``Cables,
  Coax...''  pour d'autres questions sur les differents types  de  cable
  Ethernet.

  La  plupart  des cartes Ethernet possede aussi une version `Combo' qui
  ne coute que 60 a 150 francs de plus.  (NDT: Amusant comme les  ecarts
  de  prix  en  dollars se convertissent en ecarts de prix en francs! La
  version anglaise dit ``10 a 20 dollars de plus''. Ces ecarts  de  prix
  sont vrais fin 97.)

  Ces  versions  `Combo' possedent les deux interfaces paire torsadee et
  Ethernet fin integrees, ce qui vous  permet  de  changer  d'avis  plus
  tard.(NDT:  `Combo'  signigie  meme souvent: interface RJ-45 (10baseT,
  paire torsadee) + interface BNC (10base2,  thinnet)  +  interface  AUI
  (pour transceiver ou cable de descente (drop-cable) gros Ethernet).)

  Les   cables   a   paires   torsadees,   avec  les  connecteurs  RJ-45
  (rectangulaires) sont  appeles  techniquement  10BaseT.  Vous  pourrez
  aussi  entendre parler de UTP (Unshielded Twisted Pair, paire torsadee
  non-ecrantee ou non-blindee, NDT).

  Le cablage `thinnet', ou Ethernet fin (cable coaxial RG-58)  avec  les
  connecteur  BNC  (en  metal, a enfoncer puis tourner pour verrouiller)
  est appele techniquement 10Base2.

  Le vieil Ethernet `epais' (Thick Ethernet, sur cable coaxial de 10 mm,
  jaune)  ne se trouve plus que dans les installations anciennes, et est
  appele 10Base5.

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

  (NDT:  Professionnellement  parlant, en dehors de la fibre optique qui
  est encore hors de prix  jusqu'a  la  machine  de  l'utilisateur,  les
  nouveaux  cablages  devraient  etre  realises en ``Categorie 5, classe
  D''. Ce type de cablage supporte non  seulement  10BaseT,  mais  aussi
  100BaseT et les nouveaux debits qui apparaissent.

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

  Et d'abord allez voir ``Cables, Coax...''.:))

  3.

  Foire Aux Questions (FAQ) - Les questions frequemment posees

  Voici quelques unes des questions les plus frequemment posees a propos
  de l'utilisation de Linux avec une connexion Ethernet.  Certaines  des
  questions   les   plus   specifiques   sont   triees   `par  ordre  de
  constructeur'.  Toutefois, puisque par nature ce document est  `vieux'
  au  moment  ou vous l'obtenez, les `nouveaux' problemes n'apparaitront
  pas ici de facon instantanee. Pour ceux-ci, je vous suggere d'utiliser
  intelligement  votre lecteur de news. Par exemple, les utilisateurs de
  `nn' pourront taper

       nn -xX -s'3c'

  afin d'obtenir tous  les  articles  des  groupes  auxquels  vous  avez
  souscrits,  qui  contiennent  `3c'  dans leur sujet (i.e. 3com, 3c509,
  3c503, etc.).

  Morale: lisez la page de manuel de votre lecteur de news.

  3.1.

  Les pilotes `Alpha' -- Comment les obtenir et comment s'en servir

  J'ai  entendu  dire qu'il y avait une version mise-a-jour ou un pilote
  alpha disponible pour ma carte. Ou puis-je l'obtenir?

  Les plus recents des `nouveaux' pilotes peuvent etre  trouves  sur  le
  site  FTP  de Donald: cesdis.gsfc.nasa.gov dans la partie /pub/linux/.
  Les choses y changent frequemment, donc  jetez-y  un  coup  d'oeil  de
  temps a autre.  Vous pourrez preferer utiliser un navigateur WWW sur:

       La       page       Linux      de      Don      <http://ces-
       dis.gsfc.nasa.gov/pub/linux/linux.html>

  pour localiser le pilote que vous cherchez. (Prenez garde des  naviga-
  teurs  WWW  qui  modifient  le source sans rien dire en remplacant les
  tabulations par des  espaces,  etc.  -  si  vous  n'etes  pas  sur(e),
  utilisez ftp, ou au moins une URL FTP, pour le chargement.)

  Maintenant, s'il s'agit reellement d'un pilote alpha, voire pre-alpha,
  s'il vous plait considerez-le comme tel!  En  d'autre  mots,  ne  vous
  plaignez  pas parce que vous n'arrivez pas a deviner ce que vous devez
  en faire. Si vous n'arrivez pas a deviner comment il faut l'installer,
  alors  vous ne devriez certainement pas etre en train de le tester. De
  meme, s'il plante votre machine, ne vous  plaignez  pas.   A  lieu  de
  cela, envoyez-nous un rapport detaille sur le probleme, ou meme mieux,
  un patch!

  Notez que certains des pilotes experimentaux  ou  alpha  `utilisables'
  sont  inclus  dans  l'arborescence  standard  du  noyau.  Lorsque vous
  executez make  config,  l'une  des  premieres  choses  qui  vous  sera
  demandee  est  si  vous souhaitez etre interroge(e) sur les pilotes en
  cours de developpement (``Prompt  for  development  and/or  incomplete
  code/drivers'').  Vous  devrez  repondre  ``Y''  (pour `Yes', `Oui') a
  cette question si vous souhaitez  etre  interroge(e)  sur  l'inclusion
  d'un pilote alpha ou experimental.

  3.2.  Utiliser plus d'une carte Ethernet par machine

  Que faut-il faire pour que Linux puisse gerer deux cartes Ethernet?

  Linux  contient  tout  ce  qu'il  faut  pour utiliser plusieurs cartes
  Ethernet. Toutefois, notez que pour le  moment,  seulement  une  carte
  Ethernet  est  detectee  automatiquement  par  defaut. Cela evite plus
  facilement des blocages au moment du demarrage causes par la detection
  de cartes `sensibles'.

  Vous  pouvez activer la detection automatique de la deuxieme (et de la
  troisieme, et de...) carte de deux facons differentes.

  La methode la plus simple consiste a passer des arguments au noyau  au
  moment  du  demarrage,  ce  qui  est  generalement  fait par LILO.  La
  detection de la deuxieme carte  peut  etre  obtenue  en  utilisant  un
  argument  de  demarrage  aussi simple que ether=0,0,eth1. Dans ce cas,
  eth0 et eth1 seront affectes  dans  l'ordre  dans  lequel  les  cartes
  seront  trouvees  au  demarrage.  Par contre, si vous souhaitez que la
  carte sur le port 0x300 soit eth0 et que la carte sur  le  port  0x280
  soit eth1, vous pourrez utiliser

       LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1

  La  commande  ether= accepte plus d'informations que le numero d'IRQ +
  le  port  d'E/S  +  le  nom  qui  sont  montres  ci-dessus.   Veuillez
  consulter  ``Passage  des  arguments  Ethernet...''   pour  la syntaxe
  complete, les parametres specifiques a chaque carte,  et  des  astuces
  pour LILO.

  Ces  arguments  de demarrage peuvent etre rendus permanents afin de ne
  pas devoir les re-entrer a chaque fois. Consultez la documentation sur
  l'option de configuration `append' de LILO.

  La  seconde  methode (non recommandee) est d'editer le fichier Space.c
  et de remplacer la valeur 0xffe0 pour l'adresse d'entree-sortie par un
  zero.  La  valeur 0xffe0 indique au noyau qu'il ne doit pas essayer de
  detecter ce peripherique  --  la  remplacer  par  un  zero  autorisera
  l'auto-detection du peripherique.

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

  Si  vous  consultez  ce  document  tout en surfant sur le reseau, vous
  pourrez jeter un coup d'oeil a un mini-HOWTO que Donal a sur son  site
  WWW. Consultez

       Plusieurs         Cartes        Ethernet        <http://ces-
       dis.gsfc.nasa.gov/linux/misc/multicard.html>.

  Si vous utilisez les modules avec des cartes basees sur  la  8390,  un
  seul  module  peut  suffire pour controler plusieurs cartes de la meme
  marque. Veuillez consulter ``Les         cartes a base de  8390  comme
  modules''  pour  des  informations  specifiques  sur l'utilisation des
  modules avec plusieurs cartes.

  3.3.  Clones NE2000 bas de gamme

  Voici une liste de quelques clones de la NE-2000 qui sont connus  pour
  avoir  divers  problemes.  La  plupart  de ceux-ci ne sont pas fatals.
  Dans le cas de ceux qui sont indiques  comme  `mauvais  clones',  cela
  signifie  que les cartes n'ont pas les deux octets qui identifient une
  NE2000. Les clones NEx000 ont une PROM d'adresse de  station  (Station
  Address  PROM, SAPROM) dans l'espace-memoire du tampon de paquets. Les
  clones NE2000 ont 0x57,0x57 aux octets 0x0e,0x0f de la SAPROM,  tandis
  que  les  autres clones NE2000 supposes doivent etre detectes par leur
  prefixe d'adresse  de  station.   Cette  liste  n'est  pas  une  liste
  exhaustive  de  tous  les clones NE2000 qui ne possedent pas 0x57,0x57
  dans les octets 0x0e,0x0f de la SAPROM. Il en existe certainement  des
  centaines.  Si vous utilisez une carte qui oblige le pilote a indiquer
  une `signature invalide' (invalid signature en anglais),  vous  devrez
  alors  ajouter  la signature de votre carte dans le pilote. La maniere
  de proceder est decrite ci-dessous.

  Accton NE2000 -- risque de ne pas etre detectee au demarrage, voir ci-
  dessous.

  Artisoft  LANtastic  AE-2  --  OK,  mais  a des registres d'indication
  d'erreur qui fonctionnent imparfaitement.

  AT-LAN-TEC NE2000 -- clone qui utilise la puce Winbod qui  bloque  les
  pilotes SCSI

  ShineNet  LCS-8634  -- clone qui utilise la puce Winbod qui bloque les
  pilotes SCSI

  Cabletron E10**, E20**, E10**-x, E20**-x -- mauvais  clones,  mais  le
  pilote les verifie.  Consultez ``E10**''.

  D-Link  Ethernet  II  --  mauvais  clones, mais le pilote les verifie.
  Consultez ``DE-100 / DE-200''.

  DFI DFINET-300, DFINET-400 --  mauvais  clones,  mais  le  pilote  les
  verifie.  Consultez ``DFI-300 / DFI-400''.

  EtherNext  UTP8, EtherNext UTP16 -- mauvais clones, mais le pilote les
  verifie.

  3.4.

  Problemes avec les cartes NE1000 / NE2000 (et leurs clones)

  Probleme:  Une  carte PCI clone NE2000 n'est pas detectee au demarrage
  avec un noyau 2.0.x.

  Raison: Le pilote ne.c jusqu'a la version 2.0.30  ne  connait  que  le
  numero  d'identification PCI des cartes clones basees sur la puce 8029
  de RealTek. Comme depuis Winbond et Compex ont eux fait des cartes PCI
  clones  NE2000,  avec  des  numero d'identification PCI differents, le
  pilote ne les detecte pas.

  Solution: La solution la plus simple est de mettre a jour votre  noyau
  pour  une version 2.0.31 (ou plus recente). Cette derniere connait les
  identificateurs de pres de cinq puces NE2000 PCI differentes,  et  les
  detectera  automatiquement  au  demarrage  ou  lors  du  chargement en
  module.
  Autrement, apres le demarrage, vous pouvez obtenir l'adresse d'E/S (et
  d'interruption)  que  la carte utilisera en faisant ``cat /proc/pci''.
  Disons par exemple que cette commande indique l'IRQ 9 et le port d'E/S
  0xffe0,  alors  vous pourrez ajouter au prompt de demarrage de LILO la
  commande ether=9,0xffe0,eth0 qui orientera directement le pilote  vers
  votre  carte  et evitera les tentatives de detection basees sur le PCI
  en meme temps. (Les  futurs  noyaux  des  versions  2.1  et  suivantes
  connaitront  les  identificateurs  PCI des clones NE2000 de Winbond et
  Compex, donc ceci ne sera plus necessaire a ce moment-la.)

  Probleme: Ma carte PCI clone  NE2000  est  indiquee  comme  etant  une
  NE1000 (une carte 8 bits!) au demarrage ou lorsque je charge le module
  ne.o sous 2.0.x, et par consequent la carte ne fonctionne pas.

  Raison: Certains clones PCI n'implementent pas l'acces de  largeur  un
  octet  (et  par  consequent  ne  sont  donc pas reellement compatibles
  NE2000 a 100%). Cela entraine que  la  procedure  de  detection  pense
  qu'il s'agit de cartes NE1000 si la detection PCI n'a pas ete utilisee
  (ce qui est le cas lorsqu'une adresse d'E/S explicite  est  donnee  au
  module ou au moment du demarrage).

  Solution:  Vous pouvez passer a la version 2.0.31 (ou une version plus
  recente) comme dit ci-dessus, ou realiser  a  la  main  le  changement
  suivant dans le fichier drivers/net/ne.c:

  ______________________________________________________________________
  -       if (pci_irq_line)
  +       if (pci_irq_line || ioaddr >= 0x400)
              wordlength = 2;   /* Catch broken PCI cards mentioned above. */
  ______________________________________________________________________

  puis  recompiler  le module (ou le noyau). Notez que la version 2.0.31
  et les versions 2.1.x recentes ne necessitent pas d'adresse d'E/S pour
  la  detection  de  la  plupart  des  cartes  au  demarrage  ou avec le
  module ne.o -- il vaut mieux le laisser  detecter  automatiquement  la
  cartes sous ces versions.

  Probleme:  Ma  carte  NE2000 PCI a des performances affreuses, meme en
  reduisant la taille de la fenetre comme il est decrit dans la  section
  sur les trucs pour les performances.

  Raison:  Les  specifications  de  la  puce  8390 originelle, concue et
  vendue il y a plus de dix ans, notaient qu'une  operation  de  lecture
  (depuis  la  puce)  etait necessaire avant l'operation d'ecriture pour
  avoir une securite maximale.  Le pilote possede la  fonctionnalite  de
  le  faire  mais  cela  a ete desactive par defaut depuis les jours des
  versions 1.2, une fois que le probleme qui causait le  plantage  avait
  alors  ete  localise.   Un  utilisateur  a  indique que le fait de re-
  activer cette `contre-fonctionnalite' avait aide les performances  sur
  une carte PCI clone de NE2000 bon marche.

  Solution:  Puisque  cela  n'a  ete rapporte comme solution que par une
  seule personne,  ne  vous  echauffez  pas  trop.  Pour  re-activer  le
  correctif  de  `lecture avant ecriture', il suffit d'editer le fichier
  linux/drivers/net/ne.c, d'enlever les commentaires  qui  entourent  la
  ligne  contenant  NE_RW_BUGFIX  puis  de  reconstruire  le noyau ou le
  module selon  le  cas.   Merci  d'envoyer  un  courrier  decrivant  la
  difference de performance et le type de carte / de puce que vous avez,
  si cela vous a aide.

  Probleme: Ma carte NE*000 bloque ma machine, parfois avec  un  message
  `DMA conflict' (conflit DMA), parfois sans aucun message.

  Raison: Certains noyaux anciens contenaient des erreurs dans le pilote
  et les couches superieures du reseau qui  causaient  ce  comportement.
  Ces erreurs ont ete corrigees il y a bien longtemps, dans les versions
  1.2.9 (et superieures) du noyau.  Mettez votre noyau a jour.

  Probleme: Ma carte NE*000 bloque ma machine pendant la  detection  des
  NE,  ou  il  est  impossible  de lire l'adresse de la station (Station
  Address, SA) correctement.

  Raison:  Les  versions  du   noyau   anterieures   a   la   1.3.7   ne
  reinitialisaient  pas  la  carte  apres  l'avoir trouvee au demarrage.
  Certaines cartes  bon  marche  ne  sont  pas  laissees  dans  un  etat
  raisonnable   apres   l'allumage   de   la  machine  et  doivent  etre
  completement reinitiliasees avant que le moindre essai soit fait  pour
  les  utiliser.   De  meme,  une procedure de detection precedente a pu
  deconfigurer la carte NE avant que la procedure de detection des NE ne
  prenne  place.  Dans ce cas, essayez d'utiliser le mot-cle reserve= au
  demarrage  afin  de  proteger  la  carte  des  autres  procedures   de
  detection.

  Problem:  Le  pilote  NE*000 indique `not found (no reset ack)' (carte
  non trouvee, pas d'acquittement de  la  reinitialisation)  pendant  la
  procedure de detection au demarrage.

  Raison:  Ceci  est  lie au changement precedent. Apres la verification
  initiale  qu'une  8390  se  trouve  a  l'adresse  d'E/S   testee,   la
  reinitialisation   est   effectuee.   Quand  la  carte  a  termine  sa
  reinitialisation, elle est suppose envoyer un  acquittement  indiquant
  que  la  reinitialisation s'est achevee.  Votre carte ne l'a pas fait,
  et le pilote estime donc qu'aucune carte Ne n'est presente.

  Solution: Vous  pouvez  indiquer  au  pilote  que  vous  possedez  une
  mauvaise  carte  (bad  card)  en  utilisant une valeur hexadecimale de
  0xbad au moment du demarrage pour  le  parametre  mem_end  (qui  n'est
  normalement pas utilise). Vous devez aussi fournir une adresse de base
  non nulle pour les ports d'E/S de la  carte  quand  vous  utilisez  la
  valeur  0xbad.  Par  exemple,  une  carte qui se trouve a 0x340 et qui
  n'acquitte pas la reinitialisation utilisera quelque chose comme:

       LILO: linux ether=0,0x340,0,0xbad,eth0

  Ceci permettra a la procedure de detection de la carte  de  continuer,
  meme  si  votre  carte  n'acquitte  pas  la  reinitialisation. Si vous
  utilisez le pilote comme un module, vous pouvez alors fournir l'option
  bad=0xbad  exactement  comme  vous indiquez l'adresse d'E/S. Notez que
  les modules des versions 2.0.x ne comprendront pas l'option bad=,  car
  elle a ete ajoutee durant le developpement des versions 2.1.

  Probleme: Ma carte NE*000 bloque la machine au premier acces reseau.

  Raison:  Ce probleme a ete rapporte pour des noyaux aussi vieux que le
  1.1.57 jusqu'aux noyaux actuels. Il apparait etre confine a  un  petit
  nombre  de  cartes  clones configurables par logiciel. Il apparait que
  ces cartes s'attendent a etre initialisees d'une maniere speciale.

  Solution: De nombreuses personne ont indique que le fait d'executer le
  programme  DOS  de  configuration fourni avec la carte et/ou le pilote
  DOS fourni avec  la  carte  avant  de  redemarrer  a  chaud  (i.e.  en
  utilisant  loadlin  ou  le  `salut-aux-trois-doigts'  (Ctrl-Alt-Suppr,
  NDT)) pour lancer  Linux  permet  a  la  carte  de  fonctionner.  Ceci
  indiquerait  que  ces  cartes  doivent  etre  initialisees d'une facon
  particuliere, legerement differente de ce que le pilote  Linux  actuel
  realise.

  Probleme:  Ma  carte  Ethernet  NE*000  a  l'adresse  0x360 n'est plus
  detectee.
  Raison:  Les  noyaux  recents  (  >  1.1.7X)   comprennent   plus   de
  verification de sante mentale en ce qui concerne les chevauchements de
  zone d'E/S.  Votre carte NE2000 a  une  largeur  d'espace  d'adressage
  d'E/S  de 0x20, ce qui lui fait atteindre la zone utilisee par le port
  parallele a l'adresse 0x378.  D'autres  peripheriques  qui  pourraient
  etre  a  cet  endroit-la seraient le controleur du deuxieme lecteur de
  disquette (s'il y en  a  un)  a  l'adresse  0x370  le  controleur  IDE
  secondaire  aux  adresses  0x376--0x377.   Si  le(s) port(s) sont deja
  enregistres par un autre pilote, le noyau ne laissera  pas  s'executer
  la detection.

  Solution: Vous pouvez soit deplacer votre carte vers une adresse d'E/S
  comme 0x280, 0x340, 0x320, ou compiler votre noyau sans l'option  pour
  l'imprimante parallele.

  Problem:  Le  reseau  `disparait'  a chaque fois que j'imprime quelque
  chose (NE2000).

  Raison: Meme probleme que precedemment, mais vous avez un vieux  noyau
  qui  ne  verifie  pas  les  chevauchements de zones d'adressage d'E/S.
  Utilisez la meme solution que ci-dessus, et profitez-en pour recuperer
  un nouveau noyau, tant qu'a faire.

  Probleme:  NE*000  ethercard  probe  at 0xNNN: 00 00 C5 ... not found.
  (invalid signature yy zz) (carte Ethernet NE*000  testee  a  l'adresse
  0xNNN: 00 00 C5 ... non trouvee, signature yy zz non valide)

  Raison:  Avant  tout, avez-vous une carte NE1000 ou NE2000 a l'adresse
  0xNNN?  Si oui, est-ce que l'adresse materielle indiquee  ressemble  a
  une  adresse  valide?  Si  oui, alors vous avez un clone NE*000 bas de
  gamme. Tous les clones NE*000 sont supposes avoir la valeur 0x57  dans
  les  octets  14 et 15 de leur SA (Station Address) PROM.  La votre n'a
  pas ces valeurs -- elle a `yy zz' a la place.

  Solution: Il existe deux moyens de contourner ce probleme.

  Le plus simple est d'utiliser  une  valeur  0xbad  pour  le  parametre
  mem_end  comme  indique ci-dessus pour le probleme du non-acquittement
  de la reinitialisation. Cela evitera la verification de la  signature,
  pour  autant  qu'un  port  d'E/S non nul soit fourni en meme temps. De
  cette facon, aucune recompilation du noyau n'est necessaire.

  La seconde methode necessite de changer le pilote  lui-meme,  puis  de
  recompiler  votre  noyau.  Le pilote (usr/src/linux/drivers/net/ne.c/)
  comporte un "Mur de la Honte"  aux environs  de  la  ligne  42.  Cette
  liste  est  utilisee  pour  detecter  les  clones  bas  de gamme.  Par
  exemple, la carte DFS utilise `DFI' dans les trois premiers octets  de
  la PROM, au lieu d'utiliser 0x57 aux octets 14 et 15, tels qu'ils sont
  supposes etre.

  Vous pouvez determiner le contenu des trois premiers octets de la PROM
  de votre carte en ajoutant une ligne comme:

      printk("PROM prefix: %2.2x %2.2x %2.2x\n",SA_prom[0],SA_prom[1],SA_prom[2]);

  dans  le  pilote, juste apres le message d'erreur que vous avez obtenu
  ci-dessus, et juste avant le "return ENXIO" de la ligne 227.

  Redemarrez avec ce  changement  en  place,  et  apres  l'echec  de  la
  detection,  vous obtiendrez les trois premiers octets de la PROM comme
  l'exemple pour DFI ci-dessus.  Vous pourrez alors ajouter votre  carte
  dans  la  bad_clone_list[] aux environs de la ligne 43.  Imaginons que
  la ligne ci-dessus ait affiche:

  PROM prefix: 0x3F 0x2D 0x1C

  apres que vous ayez redemarre. Et imaginons que la version 8  bits  de
  votre  carte s'appelle la "FOO-1k" et que la version 16 bits s'appelle
  la "FOO-2k". Vous  pourrez  alors  ajouter  la  ligne  suivante  a  la
  bad_clone_list[] :

       {"FOO-1k", "FOO-2k", {0x3F, 0x2D, 0x1C,}},

  Notez que les deux chaines de caracteres qui contiennent les noms peu-
  vent etre n'importe quoi -- elles sont juste affichees  au  demarrage,
  et  ne  sont  comparees avec rien du tout dans la carte.  Vous pourrez
  aussi enlever la commande printk() que vous  aviez  ajoutee,  si  vous
  voulez. Le noyau ne devrait plus atteindre cette ligne de toute facon.
  Puis recompilez  une  fois  de  plus,  et  votre  carte  devrait  etre
  detectee.

  Probleme:  Des  erreurs  comme  DMA address mismatch (l'adresse DMA ne
  correspond pas).

  Est-ce que la puce est une vraie puce 8390 de National  Semiconductor?
  (DP8390,  DP83901,  DP83902  ou  DP83905)?   Si  ce  n'est pas le cas,
  certaines puces clones n'implementent pas correctement le registre  de
  verification  de  transfert.  Les  pilotes  MS-DOS  ne  font jamais de
  verification d'erreur, donc cela ne  leur  importe  guere.  (Note:  La
  verification  d'adresse  DMS  n'est pas effectuee par defaut depuis la
  version  1.2.4  pour  des  raisons  de  performance.  Autorisez-la  en
  utilisant  la  macro  `NE_SANITY'  dans  ne.c si vous souhaitez que la
  verification soit bien effectuee.)

  Est-ce que les messages se trompent d'un facteur 2?  Si c'est le  cas:
  utilisez-vous  la  NE2000  dans  un  emplacement  16  bits?   Est-elle
  configuree pour n'utiliser que des transferts 8 bits?

  Le pilote Linux s'attend a ce qu'une carte NE2000 se  trouve  dans  un
  emplacement 16 bits. Une carte NE1000 peut etre dans un emplacement de
  taille quelconque. Ce probleme peut aussi se  produire  avec  certains
  clones,  de  facon notoire les anciennes cartes 16 bits de D-Link, qui
  n'ont pas les octets d'identification corrects dans la SAPROM.

  Utilisez-vous le bus ISA a une vitesse superieure a 8  MHz?   Si  vous
  pouvez  changer  la  vitesse  (plus rapide ou plus lente), regardez si
  cela provoque un comportement different.  La plupart des clones NE2000
  fonctionneront  a  16 MHz, mais certains non. Le changement de vitesse
  peut aussi masquer un bus bruyant.

  Quels autres peripheriques  y'a-t-il  sur  le  bus?   Si  le  fait  de
  deplacer  les  peripheriques  change  la fiabilite, alors vous avez un
  probleme de bruit sur le bus -- exactement ce que ce message  d'erreur
  etait destine a detecter. Felicitations, vous avez certainement trouve
  la source d'autres problemes du meme coup.

  Probleme:  La  machine  se  bloque  pendant  le  demarrage  apres   le
  message  `8390...'  ou le message `WD....'. Le fait d'enlever la carte
  NE2000 resoud le probleme.

  Solution: Changez votre adresse d'E/S de base pour  une  valeur  comme
  0x340.   Autre  solution, vous pouvez utiliser l'argument de demarrage
  ``reserve='' pour proteger la carte des procedures  de  detection  des
  autres pilotes de peripheriques.

  Raison:  Votre  clone  NE2000  n'est pas un assez bon clone. Une carte
  NE2000 est un puits sans fond qui attirera tout pilote  qui  tenterait
  une  detection  dans  son  espace  d'adressage.  Le fait de changer la
  carte NE2000 vers une adresse moins populaire l'ecartera du chemin des
  autres procedures de detection automatique, permettant a votre machine
  de demarrer.

  Probleme: La machine  se  bloque  pendant  la  detection  du  SCSI  au
  demarrage.

  Raison:  C'est  le  meme  probleme que precedemment; changez l'adresse
  d'E/S de la carte Ethernet, ou utilisez  les  arguments  de  demarrage
  reserve et ether.

  Probleme: La machine se bloque pendant la detection de la carte son au
  demarrage.

  Raison: Non, en fait c'est pendant la detection silencieuse  du  SCSI,
  et c'est le meme probleme que ci-dessus.

  Probleme:  Ma  carte  NE2000 n'est pas detectee au demarrage. Il n'y a
  aucun message pendant le demarrage.

  Solution: Il n'existe pas de `solution  magique'  parce  qu'il  existe
  tout  un  tas  de  raisons pour qu'elle ne soit pas detectee. La liste
  suivante devrait vous aider a parcourir les problemes possibles.

  1) Construisez un nouveau  noyau  ne  contenant  que  les  pilotes  de
  peripherique dont vous avez besoin.  Verifiez que vous etes reellement
  en train de demarrer le noyau tout frais. Oublier de lancer lilo, etc.
  peut  amener a demarrer l'ancien. (Regardez de pres la date et l'heure
  de compilation indiquee au demarrage.) Cela peut paraitre 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 System.map a la
  recherche de noms comme ne_probe.

  2)  Consultez  attentivement les messages au demarrage.  Est-ce qu'ils
  mentionnent une tentative de  detection  d'une  NE2000  comme  `NE*000
  probe  at  0xNNN:  not  found (bla bla)' ou est-ce que la detection se
  contente d'echouer sans rien dire?  Cela fait une  grosse  difference.
  Utilisez  dmesg|more  pour relire les messages de demarrage apres vous
  etre logge, ou tapez Majuscule+PageUp  (page  precedente)  pour  faire
  defiler  l'ecran  vers  le haut apres que le demarrage soit termine et
  que le prompt de login soit apparu.

  3) Apres le demarrage, faites un cat  /proc/ioports  et  verifiez  que
  tout  l'espace  d'E/S que la carte demandera est vacant.  Si vous avez
  0x300 comme adresse de base, alors le pilote NE2000 demandera la plage
  d'adresse 0x300-0x31f. Si un autre pilote de peripherique a enregistre
  ne serait-ce qu'un port a n'importe quel endroit dans cet  intervalle,
  la procedure de detection ne pourra pas s'effectuer a cette adresse et
  continuera sans rien dire jusqu'a la prochaine adresse testee. Un  cas
  classique  est  que  le pilote lp (imprimante) reserve 0x378 ou que le
  second canal IDE reserve 0x376 ce qui empeche le pilote ne  de  tester
  la plage 0x360-0x380.

  4)  Meme  chose  que precedemment avec cat /proc/interrupts.  Assurez-
  vous qu'aucun autre peripherique  n'a  enregistre  l'interruption  que
  vous  avez  fixee  pour  la  carte Ethernet. Dans ce cas, la detection
  s'effectuera, et le pilote  Ethernet  se  plaindra  vigoureusement  au
  demarrage de ne pas etre capable d'obtenir la ligne d'IRQ desiree.

  5)  Si  vous sechez encore sur l'echec silencieux du pilote, editez-le
  et ajoutez  quelques  printk()  a  la  procedure  de  detection.   Par
  exemple,  avec  une  NE2000  vous  pouvez  ajouter/enlever  des lignes
  (marquees respectivement par un '+' ou un '-') dans netne.c/ comme:

  ______________________________________________________________________
      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;
  +    }
  ______________________________________________________________________

  Le noyau emettra alors des messages pour chaque port qu'il verifie, et
  vous verrez alors si l'adresse de votre carte a ete testee ou pas.

  6)  Vous pouvez aussi recuperer le programme de diagnostic pour NE2000
  sur le site FTP de Don (indique dans le Howto) et  regarder  s'il  est
  capable  de  detecter  votre  carte apres que vous ayez demarre Linux.
  Utilisez l'option `-p 0xNNN' pour lui dire ou regarder pour la  carte.
  (La  valeur  par defaut est 0x300 et il ne va pas regarder ailleurs, a
  la difference de la procedure de detection au demarrage.)

  Le resultat, s'il trouve une carte, ressemblera a:

  ______________________________________________________________________
  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.
  ______________________________________________________________________

  Vos valeurs de registres et de PROM seront  probablement  differentes.
  Notez  que  toutes les valeurs de la PROM sont doublees pour une carte
  16 bits, et que l'adresse Ethernet (00:00:c0:b0:05:65)  apparait  dans
  la  premiere ligne, et que la signature avec le double 0x57 apparait a
  la fin de la PROM.

  Le resultat, s'il n'y a aucune carte installee en  0x300,  ressemblera
  a:

  ______________________________________________________________________
  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.
  ______________________________________________________________________

  Les  valeurs  0xff  apparaissent  parce  que  c'est  la valeur qui est
  retournee lorsque l'on lit un port d'E/S vacant. Si vous avez un autre
  materiel  dans  la  zone qui est testee, vous pourrez voir des valeurs
  differentes de 0xff aussi.

  7) Essayez de demarrer Linux a chaud depuis une disquette de demarrage
  DOS  (via  loadlin)  apres  avoir  execute  le pilote DOS fourni ou le
  programme de configuration de la  carte.  Il  se  peut  qu'il  execute
  quelques    tours   de   passe-passe   supplementaires   (c'est-a-dire
  non standards) pour initialiser la carte.

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

  Exemple:

       A:> ne2000 0x60 10 0x300

  Les  arguments  sont:  le  vecteur  d'interruption   logiciel,   l'IRQ
  materielle,  et  le  port  d'E/S.  Vous pouvez obtenir ce programme de
  n'importe quelle archive msdos dans  le  fichier  pktdrv11.zip  --  la
  version actuelle peut avoir un numero plus recent que 11.

  3.5.

  Problemes avec les cartes SMC Ultra/EtherEZ et WD80*3

  Probleme: Vous obtenez des messages semblables au suivant:

          eth0: bogus packet size: 65531, status=0xff, nxpg=0xff

  Raison: Il y a un probleme de memoire partagee.

  Solution: Les machines PCI qui n'ont pas ete configurees pour traduire
  les peripheriques  ISA  en  memoire  constituent  la  source  la  plus
  courante  pour  ce  probleme. De fait vous lisez la memoire vive du PC
  (toutes les valeurs 0xff que donne le message) au lieu de  la  memoire
  vive de la carte, qui elle contient les donnees du paquet recu.

  D'autres  problemes qui eux sont faciles a regler sont des conflits de
  carte, le fait d'avoir active le cache ou la memoire  morte  ISA  plus
  vite  que  8  MHz.  Il existe aussi un nombre etonnant de pannes de la
  memoire sur  les  cartes  Ethernet,  donc  utilisez  le  programme  de
  diagnostic si vous en avez un pour votre carte Ethernet.

  Probleme:  Une  carte  EtherEZ  de  SMC  ne  fonctionne pas en mode de
  memoire non-partagee (PIO).

  Raison: Les versions les plus anciennes du pilote Ultra  ne  pouvaient
  utiliser la carte que dans le mode de travail a memoire partagee.

  Solution:  Le  pilote  de  la  version 2.0 (et superieures) sait aussi
  utiliser le mode d'E/S programmees (PIO). Mettez votre  noyau  a  jour
  vers  une version 2.0, ou recuperez le fichier de remplacement pour le
  noyau 1.2.13 sur le site FTP/WWW de Donald.

  Probleme:  Une  vieille  wd8003  et/ou  une  wd8013  configurable  par
  cavaliers ont toujours la mauvaise IRQ.

  Raison:  Les vieilles cartes wd8003 et les clones wd8013 configurables
  par cavaliers ne possedent pas l'EEPROM que le pilote sait lire pour y
  trouver  le parametrage de l'IRQ. Si le pilote ne sait pas lire l'IRQ,
  il essaie de determiner automatiquement l'IRQ. Et si la  procedure  de
  detection  automatique retourne zero, le pilote se contente d'affecter
  l'IRQ 5 pour une carte 8 bits ou l'IRQ 10 pour une carte 16 bits.
  Solution: Evitez  le  code  de  detection  automatique  de  l'IRQ,  et
  indiquez  au  noyau  la  valeur  d'IRQ que vous avez configuree sur la
  carte  avec  les  cavaliers  en  la  lui  passant  comme  argument  au
  demarrage.   Par  exemple, si vous utilisez l'IRQ 9, la ligne suivante
  devrait fonctionner.

       LILO: linux ether=9,0,eth0

  Probleme: Une carte SMC Ultra est detectee  comme  etant  une  wd8013,
  mais l'IRQ et l'adresse de base de la memoire partagee sont fausses.

  Raison:  La  carte  Ultra  ressemble  beaucoup  a une wd8013, et si le
  pilote Ultra n'est pas present  dans  le  noyau,  le  pilote  wd  peut
  identifier  l'Ultra  comme  etant  une wd8013. Le test de detection de
  l'Ultra vient avant celui de la wd, donc ceci ne  devrait  normalement
  pas  se  produire.  L'Ultra stocke l'IRQ et l'adresse de base dans son
  EEPROM de facon differente a celle  d'une  wd8013,  d'ou  les  valeurs
  erronees indiquees par le pilote.

  Solution: Recompilez le noyau en n'integrant que les pilotes dont vous
  avez besoin. Si vous avez un melange de cartes wd et  Ultra  dans  une
  machine,  et que vous utilisez les modules, chargez le module ultra en
  premier.

  3.6.  Problemes avec des cartes 3Com

  Probleme: La 3c503 prend l'IRQ N, mais celle-ci  est  requise  par  un
  autre  peripherique  qui a besoin de l'IRQ N (par exemple un pilote de
  CD-ROM, un modem, etc.). Est-ce que cela peut etre repare sans  devoir
  le compiler dans le noyau?

  Solution:  Le  pilote  3c503  recherche  une  ligne  d'IRQ  libre dans
  l'ordre {5, 9/2, 3, 4}, et il devrait prendre une ligne  qui  n'a  pas
  ete  utilisee.  Le  pilote  effectue  ce  choix  lorsque  la carte est
  configuree (ifconfig).

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

  Ce qui suit selectionne l'IRQ 9, adresse de base  0x300,  <une  valeur
  ignoree>, et le port if_port numero 1 (le transceiver externe).

       io=0x300 irq=9 xcvr=1

  Autrement, si le pilote est compile dans le noyau, vous pouvez choisir
  les memes valeurs en passant des parametres via LILO.

       LILO: linux ether=9,0x300,0,1,eth0

  Ce qui suit selectionne l'IRQ  3,  detecte  l'adresse  de  base,  <une
  valeur  ignoree>,  et  le  port  par  defaut  (if_port)  numero  0 (le
  transceiver interne).

       LILO: linux ether=3,0,0,0,eth0

  Probleme: 3c503: configured interrupt X  invalid,  will  use  autoIRQ.
  (3c503:   l'interruption   X   configuree   est   invalide,  detection
  automatique de l'IRQ)

  Raison: La 3c503 ne peut utiliser que l'une des IRQ 5, 2/9, 3 ou 4 (ce
  sont les seules lignes d'IRQ qui sont connectees a 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 necessaire de specifier une valeur d'interruption pour  la  3c503.
  Elle passera en detection automatique lorsqu'elle sera configuree (par
  ifconfig), et elle prendra l'une des IRQ 5, 2/9, 3 ou 4.

  Solution:  Utilisez  l'une  des  IRQ  valides  donnees  ci-dessus,  ou
  autorisez la detection automatique en ne precisant aucune ligne d'IRQ.

  Problem: Le pilote 3c503  fourni  n'utilise  pas  le  port  AUI  (gros
  Ethernet).  Comment faire pour le choisir au lieu du port Ethernet fin
  par defaut?

  Solution: Le port AUI peut etre  selectionne  au  demarrage  pour  les
  pilotes  compiles dans le noyau, et lors de l'insertion du module pour
  les pilotes modulaires.  La selection est surchargee dans  le  bit  de
  poids  le  plus  faible  de  la  variable  dev->rmem_start  qui  n'est
  actuellement pas utilisee, donc un parametre de demarrage comme:

       LILO: linux ether=0,0,0,1,eth0

  devrait fonctionner pour les pilotes compiles dans le noyau.

  Pour specifier le port AUI lorsque vous  chargez  un  module,  ajoutez
  simplement  xcvr=1  a la ligne d'options du module avec vos valeurs de
  port d'E/S et d'IRQ.

  3.7.  Les questions qui ne sont pas specifiques a une carte.

  3.7.1.  Carte Ethernet pas detectee au demarrage.

  La raison habituelle de cet etat de fait est que les gens utilisent un
  noyau qui ne contient pas le code pour leur  carte  a  eux.   Pour  un
  noyau  modulaire,  cela  signifie  generalement  que  le chargement du
  module necessaire n'a pas ete  demande,  ou  qu'une  adresse  d'E/S  a
  besoin d'etre specifie comme option du module

  Si  vous  utilisez un noyau base sur les modules, comme ceux installes
  par la plupart  des  distributions  Linux,  essayez  alors  d'utiliser
  l'utilitaire  de configuration de la distribution pour selectionner le
  module destine a votre carte. Pour les cartes  ISA,  c'est  une  bonne
  idee  que  de  determiner  l'adresse d'E/S de la carte et de l'ajouter
  comme option (p. ex. io=0x340) si l'utilitaire de  configuration  vous
  le  demande. S'il n'y a pas d'utilitaire de configuration, vous devrez
  alors ajouter le nom exact du  module  (et  ses  options)  au  fichier
  /etc/conf.modules -- lisez man modprobe pour plus de details.

  Si  vous  utilisez un noyau precompile qui provient d'une distribution
  Linux, verifiez dans la documentation quel noyau vous  avez  installe,
  et  s'il  a ete construit en incluant le code pour votre carte a vous.
  Si ce n'est pas le cas, vous pouvez soit essayer d'en obtenir  un  qui
  contient le code pour votre carte, soit construire votre propre noyau.

  C'est en general une bonne chose que de construire votre propre noyau,
  ne  contenant  que les pilotes dont vous avez besoin, car cela diminue
  considerablement  la  taille  du  noyau  (preservant  d'autant   votre
  precieuse  memoire  vive  pour  les  applications!)  et cela reduit le
  nombre de procedure de detection de peripheriques qui peuvent deranger
  le  materiel  un  peu  sensible. Construire un nouveau noyau n'est pas
  aussi complique que cela peut paraitre. Vous devez juste repondre  oui
  ou  non a tout un tas de questions sur les pilotes que vous voulez, et
  le systeme fait le reste.

  La seconde raison essentielle est qu'un autre peripherique utilise une
  partie  de  l'espace  d'adressage  d'entree-sortie  dont votre carte a
  besoin. La plupart des cartes ont  une  zone  d'adressage  qui  mesure
  16  ou  32 bits de largeur. Si votre carte est positionnee en 0x300 et
  qu'elle prend 32 octets, alors le pilote demandera la plage d'adresses
  0x300-0x31f.  Si  un  autre  pilote  de  peripherique  a enregistre ne
  serait-ce  qu'un  port  d'entree-sortie,  ou  que  ce  soit  dans  cet
  intervalle,  la procedure de detection n'aura pas lieu a cette adresse
  et le pilote continuera sans rien dire a l'adresse suivante a  tester.
  Donc,  apres le demarrage, faites un cat /proc/ioports et verifiez que
  tout l'espace d'adressage d'entree-sortie que la carte  demandera  est
  bien disponible.

  Autre  probleme: votre carte est configuree pour une adresse d'entree-
  sortie qui n'est pas testee par defaut.  Il  existe  une  liste  (voir
  section  ``adresses  testees'') pour chaque carte de ce document. Meme
  si la configuration d'E/S de votre carte n'est pas dans la  liste  des
  adresses  testees,  vous  pouvez  l'indiquer  au  demarrage  (pour les
  pilotes compiles dans le noyeau en utilisant la commande ether=  comme
  il est decrit dans ``Passage des arguments Ethernet...''.  Les pilotes
  modulaires peuvent utiliser l'option io= afin de specifier une adresse
  qui n'est pas testee par defaut.

  3.7.2.  ifconfig indique la mauvaise adresse d'E/S pour la carte.

  Non, ce n'est pas  vrai.  C'est  vous  qui  l'interpretez  de  maniere
  erronee.  Ce  n'est  pas  une  erreur,  et  les  nombres indiques sont
  corrects. Ce qu'il se passe, c'est que certaines cartes a base de 8390
  (wd80x3,  smc-ultra,  etc.)  sont  telles  que  la puce 8390 se trouve
  decalee par rapport au premier port d'E/S affecte.  Il  s'agit  de  la
  valeur  stockee  dans  dev->base_addr,  qui  est  celle  que  ifconfig
  indique. Si vous souhaitez voir  l'intervalle  complet  d'adresses  de
  ports  que votre carte utilise, vous devriez essayer cat /proc/ioports
  qui vous donnera le nombre que vous attendez.

  3.7.3.  echoue.  Une machine PCI detecte la carte mais la procedure de
  test du pilote

  Les BIOS PCI les plus  recents  peuvent  ne  pas  activer  toutes  les
  cartes  PCI lors de l'allumage de la machine, specialement si l'option
  `PNP OS' du BIOS est activee. Cette contre-fonctionnalite est destinee
  a  supporter  la  prochaine  version de Windows qui utilise encore des
  pilotes en mode reel. Vous pouvez  soit  inhiber  cette  option,  soit
  essayer de mettre a jour votre pilote pour une version qui comprend le
  code capable d'activer une carte desactivee.

  3.7.4.  PCI (0xffff) Des cartes ISA a memoire partagee ne fonctionnent
  pas dans une machine

  Ce probleme se  montre  habituellement  sous  la  forme  d'un  tas  de
  valeurs  0xffff en lecture. Aucune carte a memoire partagee de quelque
  type que ce soit ne fonctionnera dans une machine PCI a moins que vous
  n'ayez  configure correctement le BIOS PCI (PCI ROM BIOSCMOS SETUP/ ou
  quelque chose comme ca).  Vous  devez  le  configurer  pour  permettre
  l'acces  a  la  memoire  partagee  depuis  le  bus  ISA  pour  la zone
  d'adresses que votre carte essaie d'utiliser. Si vous n'arrivez pas  a
  determiner quels parametres sont concernes, interrogez votre revendeur
  ou votre  gourou  informatique  local.  Dans  un  BIOS  AMI  (American
  Megatrends  Inc.),  il existe en general une section ``Plug and Play''
  ou se trouveront sans doute des parametres ``ISA Shared Memory  Size''
  (taille  de  la  memoire  partagee  ISA) et ``ISA Shared Memory Base''
  (adresse de base de la memoire partagee ISA). Pour  des  cartes  comme
  la  wd8013  et la SMC Ultra, changez la taille de sa valeur par defaut
  (`Disabled', desactive) a une valeur de 16 Ko, et changez l'adresse de
  base en prenant l'adresse de base de memoire partagee qui correspond a
  votre carte.

  3.7.5.  Les machines NexGen obtiennent des erreurs         `mismatched
  read page pointers'.

  Un probleme dans le processeur NexGen fait que tous  les  utilisateurs
  de  cartes  basees sur la puce 8390 (wd80x3, 3c503, SMC Ultra/EtherEZ,
  ne2000, etc.) obtiennent ces messages d'erreur. Les versions du  noyau
  2.0 et superieures n'ont pas ces problemes.

  Mettez votre noyau a jour.

  3.7.6.  Asynchronous Transfer Mode (ATM)

  Werner  Almesberger  s'est  preoccupe  de  la disponibilite d'ATM pour
  Linux.  Il a travaille avec  la  carte  ENI155p  d'Efficient  Networks
  (Efficient Networks <http://www.efficient.com/>) et la carte ZN1221 de
  Zeitnet (Zeitnet <http://www.zeitnet.com/>).

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

  Consultez  les  dernieres  informations  et  les  mises a jour a l'URL
  suivante:

       Linux et ATM <http://lrcwww.epfl.ch/linux-atm/>

  3.7.7.  Support de l'Ethernet Gigabit

  Ou en est le support Ethernet Gigabit pour Linux?

  Un pilote pour l'adaptateur  Ethernet  Gigabit  G-NIC  PCI  de  Packet
  Engines  devrait etre ajoute dans l'imminente version 2.0.34 du noyau.
  Pour plus de details, d'information, et les mises a  jour  du  pilote,
  consultez:

       http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html

  3.7.8.  FDDI

  Qu'en est-il de FDDI sous Linux?

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

  3.7.9.  Full Duplex

  Est-ce que le mode Full Duplex me donnera 20 Mbit/s?  Est-ce que Linux
  sait faire du Full Duplex?

  Cameron Spitzer ecrit ce qui suit a  propos  des  cartes  Full  Duplex
  10Base-T:

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

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

  Par contre, 10Base-T (l'interface RJ-45) utilise des (paires de)  fils
  separees  pour  l'emission  et  la  reception, donc il est possible de
  travailler dans les deux sens en meme temps. Le (hub) switch  s'occupe
  du  probleme  des  collisions.  La  vitesse  de  signalisation reste a
  10 Mbit/s.''

  Donc, comme vous pouvez voir, vous ne  serez  encore  capable  que  de
  recevoir  ou  de  transmettre  a  10  Mbit/s;  n'attendez donc pas une
  multiplication par deux des performances. Quant a savoir si  cela  est
  possible  ou  non,  cela  depend  de  la carte et peut-etre du pilote.
  Certaines cartes pratiquent l'auto-negociation, 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  facon,  seul  l'utilisateur serieux/charge notera la difference
  entre les deux modes.

  3.7.10.  Cartes Ethernet pour Linux sur carte-mere PCI Alpha/AXP

  En  ce  qui concerne les versions 2.0, seules les cartes 3C509, depca,
  de4x5 lance32, et tous les  pilotes  pour  8390  (wd,  smc-ultra,  ne,
  3c503,  etc.) ont ete rendus `independants de l'architecture' de facon
  a pouvoir fonctionner sur les systemes bases sur les processeurs Alpha
  de DEC.

  Notes que les changements a faire ne sont pas aussi compliques que ca.
  Vous n'avez besoin que de:

  -multiplier toutes les valeurs relatives a des jiffies par HZ/100 pour
  prendre  en  compte  la  valeur differente de HZ utilisee par l'Alpha.
  (c'est-a-dire que timeout=2; devient timeout=2*HZ/100;)

  -remplacer tout dereferencement de pointeur en memoire d'E/S  (640k  a
  1Mo)  par  les  appels  readb()  writeb() readl() writel() appropries,
  comme le montre cet exemple:

  ______________________________________________________________________
  -       int *mem_base = (int *)dev->mem_start;
  -       mem_base[0] = 0xba5eba5e;
  +       unsigned long mem_base = dev->mem_start;
  +       writel(0xba5eba5e, mem_base);
  ______________________________________________________________________

  -remplacer tous les appels a memcpy() qui ont des adresses memoire sur
  la  plage  d'E/S  comme  source  ou  comme  destination  par  un appel
  a memcpy_fromio() ou a memcpy_toio() selon le cas.

  Vous trouverez plus de details sur  la  maniere  de  gerer  les  acces
  memoire  d'une  facon  independante  de l'architecture dans le fichier
  linux/Documentation/IO-mapping.txt qui est  present  dans  les  noyaux
  recents.

  3.7.11.  Relier deux 10BaseT sans hub

  Est-ce  que  je  peux relier deux systemes bases sur du 10BaseT (RJ45)
  sans utiliser de hub?

  Vous pouvez relier facilement deux machines, mais pas plus  que  cela,
  sans  boitier supplementaire.  Consultez la section ``Paire torsadee''
  qui explique comment faire.

  Par contre, non, vous n'arriverez pas a bricoler un  hub  en  croisant
  quelques fils et autres trucs du genre. Il est pratiquement impossible
  de generer correctement le signal de collision sans re-faire un hub.

  3.7.12.  SIOCSIFxxx: No such device

  J'obtiens un nombre impressionnant de messages  `SIOCSIFxxx:  No  such
  device'   au   demarrage,   suivis   par  un  `SIOCADDRT:  Network  is
  unreachable'.  Qu'est-ce qui ne va pas?

  Votre peripherique Ethernet n'a pas ete detecte pendant le demarrage /
  lors  de  l'insertion  du  module,  et  lorsque ifconfig et route sont
  executes,  ils  n'ont  aucun  peripherique  avec  lequel   travailler.
  Utilisez  dmesg  |  more  pour  consulter les messages du demarrage et
  regardez s'il y a un (ou des) message(s) a propos de la  detection  de
  carte Ethernet.

  3.7.13.  SIOCSFFLAGS: Try again

  J'obtiens  `SIOCSFFLAGS:  Try  again'  lorsque  j'execute  ifconfig --
  Euh..?

  Un autre peripherique 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  necessairement  besoin  de  redemarrer  pour  resoudre  ce
  probleme,   car   certains  peripheriques  ne  prennent  les  IRQ  que
  lorsqu'ils en ont besoin, et qu'ils les rendent quand  ils  ont  fini.
  C'est le cas par exemple des cartes son, des ports serie, le pilote du
  lecteur de disquette, etc. Vous pouvez taper cat /proc/interrupts pour
  voir  quelles  interruptions sont actuellement en cours d'utilisation.
  La plupart des pilotes de de carte Ethernet  sous  Linux  ne  prennent
  l'IRQ que lorsqu'ils sont ouverts via `ifconfig'. Si vous reussissez a
  faire en sorte que l'autre  peripherique  `relache'  la  ligne  d'IRQ,
  alors   vous  serez  capable  de  reessayer  (Try  again  en  anglais)
  avec ifconfig.

  3.7.14.  `Link UNSPEC with HW-addr of  00:00:00:00:00:00'  Utilisation
  de `ifconfig' et message

  Lorsque  j'utilise  ifconfig sans argument, il indique Link UNPSEC (au
  lieu de `Ethernet 10Mbs') et il dit aussi que mon adresse physique est
  a zero.

  C'est parce que les gens utilisent une version du programme `ifconfig'
  plus recente que leur version de  noyau.  Cette  nouvelle  version  de
  `ifconfig'  est  incapable  de fournir ces informations quand elle est
  utilisee en conjonction avec un noyau plus ancien.  Vous  pouvez  soit
  mettre  votre  noyau  a  jour,  soit prendre une version plus ancienne
  d'ifconfig, ou simplement ignorer le probleme.  Le noyau connait votre
  adresse  physique,  donc  le  fait  que ifconfig ne puisse pas la lire
  n'est pas vraiment important.

  Vous pourrez aussi obtenir des informations etranges si  le  programme
  ifconfig que vous utilisez est beaucoup plus vieux que votre noyau.

  3.7.15.  et en transmission (TX Errors) Nombre faramineux d'erreurs en
  reception (RX Errors)

  Quand  j'execute ifconfig sans argument, il indique que j'ai un nombre
  faramineux d'erreurs a la fois dans les  paquets  recus  et  dans  les
  paquets  transmis.  Pourtant  tout  semble fonctionner correctement --
  Est-ce que je me trompe?

  Regardez de nouveau. ifconfig indique: RX packets  gros  nombre  BLANC
  errors  0 BLANC dropped 0 BLANC overrun 0.  Meme chose pour la colonne
  avec TX.  Les grands nombres que vous voyez sont donc le nombre  total
  de  paquets  que  votre  machine a recus et transmis.  Si vous trouvez
  encore  que  c'est  source  de  confusion,  essayez   de   taper   cat
  /proc/net/dev a la place.

  3.7.16.  Liens dans /dev/ pour cartes Ethernet

  J'ai /dev/eth0 qui est un lien vers /dev/xxx.  Est-ce que c'est bon?

  Contrairement  a  ce  que  vous  avez  entendu dire, les fichiers dans
  /dev/* ne sont pas utilises. Vous pouvez detruire tous  les  /dev/wd0,
  /dev/ne0 et ce qui y ressemble.

  3.7.17.  Linux et les ``trailers'' (amorces)

  Dois-je  desactiver  les  ``trailers'' quand je `ifconfig'ure ma carte
  Ethernet?

  Vous ne pouvez pas desactiver les ``trailers'', et vous ne devriez pas
  en  avoir  envie.   Les  ``trailers'' sont une astuce de programmation
  pour eviter des copies de donnees  dans  les  couches  reseau.  L'idee
  etait  d'utiliser  un  en-tete simpliste de taille fixe `H', de mettre
  les informations de l'entete de taille variable a la fin du paquet, et
  d'allouer  tous les paquets `H' octets avant le debut d'une page. Bien
  qu'il s'agissait d'une bonne idee, en pratique cela n'a pas tres  bien
  fonctionne.

  Si  quelqu'un  suggere  l'utilisation  de  `-trailers', notez bien que
  c'est l'equivalent du sang de chevres sacrifiees. Cela ne resoudra pas
  le probleme, mais si le probleme se resoud tout seul, quelqu'un pourra
  invoquer des connaissances approfondies en magie.

  3.7.18.  Acces direct au peripherique Ethernet

  Comment puis-je avoir acces directement au peripherique Ethernet  sous
  Linux, sans avoir a passer par TCP/IP et ses copains?

  ______________________________________________________________________
          int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
  ______________________________________________________________________

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

  Bien  entendu,  vous  devez etre root pour pouvoir faire l'ensemble de
  ces operations.

  4.  Trucs et astuces a propos des performances

  Voici quelques `trucs' que vous pouvez utiliser si vous souffrez  d'un
  faible taux de transfert sur Ethernet, ou pour gagner encore un peu de
  vitesse sur ces fameux transferts FTP.

  Le programme ttcp.c est  un  bon  test  pour  mesurer  la  vitesse  de
  transfert  brute.  Un  autre  truc  classique est de faire un ftp> get
  mon_gros_fichier /dev/null ou mon_gros_fichier fait plus  d'un  Mo  et
  reside  dans  le  cache disque de la machine qui transmet.  (Faites le
  `get' au moins deux fois, car la premiere fois ce  cache  sera  vide.)
  Vous  avez besoin que le fichier soit dans le cache car il faut eviter
  que le temps d'acces au fichier influe sur votre mesure.   C'est  pour
  la  meme  raison  que  vous  envoyez  les  donnees  qui  arrivent vers
  /dev/null plutot que vers le disque.

  4.1.  Concepts generiques

  Meme une carte 8 bits est capable  de  recevoir  des  paquets  qui  se
  suivent  (back-to-back  paquets  en anglais) sans aucun probleme.  Les
  difficultes apparaissent quand l'ordinateur n'enleve pas  suffisamment
  rapidement  de  la carte les paquets recus pour faire de la place pour
  d'autres paquets entrants. Si l'ordinateur ne supprime pas  rapidement
  les paquets deja recus de la memoire de la carte , celle-ci n'aura pas
  assez de place pour mettre les nouveaux paquets.

  Dans ce cas, soit la  carte  detruit  le  nouveau  paquet,  soit  elle
  reecrit  sur  un  paquet  deja  recu. Les deux solutions interromptent
  brutalement le flux du trafic,  necessitent  des  re-transmissions  et
  peuvent  serieusement  degrader  les  performances d'un facteur qui va
  jusqu'a 5!

  Les cartes qui possedent plus de memoire sont  capables  de  conserver
  plus  de  paquets,  et  peuvent donc supporter de gros pics de paquets
  successifs sans detruire de paquets.  Par consequent cela signifie que
  la  carte n'exige pas de l'ordinateur un temps de latence aussi faible
  pour enlever les paquets sans avoir a en detruire.

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

  4.2.  La vitesse du bus ISA

  Comme  indique  precedemment,  si les paquets sont enleves de la carte
  suffisamment rapidement, le probleme de destruction  ou  de  surcharge
  n'apparait  pas  meme  si la taille memoire du tampon de reception est
  petite. Le facteur qui determine la rapidite avec laquelle les paquets
  sont  enleves  de  la  carte  pour  etre  places  dans  la  memoire de
  l'ordinateur est la vitesse du chemin que devront suivre  les  donnees
  entre  les  deux  --  c'est-a-dire  la  vitesse  du  bus  ISA.  (Si le
  processeur est un 386sx-16 poussif, cela jouera aussi un role.)

  La vitesse d'horloge recommandee pour un bus ISA est de 8 MHz, mais de
  nombreuses  cartes-meres  et  de  nombreux  peripheriques peuvent etre
  utilises a des frequences plus elevees. La vitesse  d'horloge  du  bus
  ISA  peut  en  general  etre  modifiee  dans la configuration CMOS, en
  choisissant le rapport entre la frequence du processeur et celle de la
  carte-mere.

  Par  exemple,  voici  quelques  vitesses  de reception mesurees par le
  programme TTCP sur un 486 a 40 MHz, avec une carte  8  bits  WD8003EP,
  pour des vitesses differentes du bus ISA.

  ______________________________________________________________________
          Vitesse du bus ISA (MHz)        TTCP - reception (Ko/s)
          ------------------------        -----------------------
          6.7                             740
          13.4                            970
          20.0                            1030
          26.7                            1075
  ______________________________________________________________________

  Vous  auriez  du mal a faire mieux que 1075 Ko/s avec n'importe quelle
  carte Ethernet 10  Mo/s,  en  utilisant  TCP/IP.   Neanmoins  ne  vous
  attendez  pas  a  ce  que  tous les systemes puissent travailler a des
  vitesses  de  bus  ISA  rapides.    La   plupart   des   systemes   ne
  fonctionneront  pas  correctement  a des vitesses au-dessus de 13 MHz.
  (De meme, certains systemes PCI fixent la vitesse du bus ISA a 8  MHz,
  afin  que  l'utilisateur  final  n'aie  pas  la possibilite de pouvoir
  l'augmenter.)

  En plus de vitesses de transferts plus elevees, vous profiterez  aussi
  en  general  d'une  reduction  de l'utilisation du processeur due a la
  duree plus courte des cycles memoires et d'E/S. (Notez que les disques
  durs  et  les cartes video situees sur le bus ISA afficheront aussi de
  meilleures performances avec une vitesse du bus ISA plus elevee.)

  Soyez sur de  sauvegarder  toutes  vos  donnees  avant  de  faire  des
  experiences  avec  des  vitesses  du bus ISA au-dessus de 8 MHz, et de
  tester attentivement  que  tous  les  peripheriques  ISA  fonctionnent
  correctement apres toute augmentation de vitesse.

  4.3.  Modifier la fenetre de reception TCP

  Une  fois encore, les cartes qui possedent peu de memoire et un trajet
  des donnees entre la carte et la memoire de l'ordinateur  plutot  lent
  provoquent  des  problemes. La fenetre de reception TCP est reglee par
  defaut a 32 Ko, ce qui signifie qu'un ordinateur rapide situe  sur  le
  meme sous-reseau que vous pourra vous inonder de 32 Ko de donnees sans
  s'arreter pour regarder si vous en avez recu le moindre morceau.

  Les versions recentes de la commande route donnent la  possibilite  de
  regler  la  largeur  de  cette  fenetre  a la volee. En general, cette
  fenetre ne doit etre reduite que pour le  reseau  local,  puisque  les
  ordinateurs  qui  sont  a quelques routeurs ou passerelles de distance
  ont suffisamment des `tampons' intermediaires pour  ne  pas  poser  de
  probleme. Un exemple d'utilisation est:

  ______________________________________________________________________
          route add <comme_d_habitude> ... window <largeur_de_fenetre>
  ______________________________________________________________________

  ou  largeur_de_fenetre  est  la  largeur de la fenetre que vous voulez
  utiliser (en octets). Une carte 8 bits 3c503 sur un bus ISA  fonction-
  nant  a  une  vitesse de 8 MHz ou moins tournera correctement avec une
  fenetre d'environ 4 Ko. Une fenetre trop large causera des  surcharges
  et  des pertes de paquets, et une diminution drastique du debit Ether-
  net. Vous pouvez verifier les conditions de travail  de  la  carte  en
  faisant un cat /proc/net/dev qui affichera si des pertes de paquets ou
  des surcharges sont apparues.

  4.4.  Augmenter les performances de NFS

  Des personnes ont remarque que l'utilisation de cartes 8 bits sur  des
  clients  NFS donne des performances moins bonnes que celles attendues,
  en utilisant une taille de paquet NFS de 8Ko (celle donnee a l'origine
  par Sun).

  La  raison  possible de tout ceci pourrait etre la difference entre la
  taille des tampons  des cartes 8 bits et celle des cartes 16 bits.  La
  taille  maximale  d'un  paquet  Ethernet  est  d'environ  1500 octets.
  Maintenant que nous faisons du NFS, des  paquets  NFS  de  8  Ko  vont
  arriver  sous la forme de 6 paquets de taille maximale a la queue-leu-
  leu. Ni les cartes 8 bits ni les cartes 16 bits n'ont  de  probleme  a
  recevoir  ces  paquets  les  uns  derriere  les autres. Le probleme se
  produit parce que la machine n'enleve pas les paquets a  temps  de  la
  carte,  et  que  le  tampon  deborde.   Le  fait que les cartes 8 bits
  necessitent un cycle du bus ISA supplementaire pour  chaque  transfert
  n'aide  pas  beaucoup,  par ailleurs. Ce que vous pouvez faire si vous
  avez une carte 8bits est soit de diminuer la taille de transfert NFS a
  2 Ko (voire 1 Ko), ou d'essayer d'augmenter la vitesse du bus ISA afin
  que les tampons de la carte soient vides plus rapidement.  J'ai trouve
  qu'une  vieille carte WD8003E a 8 MHz (sans autre charge systeme) peut
  soutenir une reception de taille importante avec  une  taille  NFS  de
  2  Ko,  mais pas a 4 Ko, auquel cas les performances etaient degradees
  d'un facteur de trois.

  5.

  Informations specifiques par distributeur/constructeur/modele

  Ce  qui  suit  est  une  liste de nombreuses cartes, rangees par ordre
  alphabetique de distributeur, puis par identifiant de produit.  A cote
  de  chaque  identifiant  de produit, vous verrez soit `supporte', soit
  `partiellement-supporte', soit `non-supporte'.

  Supporte signifie  qu'un  pilote  existe  pour  cette  carte,  que  de
  nombreuses  personnes s'en servent joyeusement et qu'il semble fiable.

  Partiellement-supporte signifie qu'un pilote existe, mais que l'une au
  moins  des  conditions  suivantes  est  vraie:  (1) Le pilote et/ou le
  materiel  comportent  des  erreurs,  ce   qui   peut   provoquer   des
  performances faibles, des echecs de connexion ou meme des crashs.  (2)
  Le pilote est  recent  ou  la  carte  est  tres  peu  connue,  et  par
  consequent  le  pilote a ete peu utilise/teste et l'auteur du pilote a
  eu tres peu de retour sur son fonctionnement. Il est  evident  que  la
  situation  (2) est preferable a la situation (1), et la description de
  la carte/du pilote devrait montrer clairement laquelle est  la  bonne.
  Dans  l'un  comme l'autre cas, vous devrez certainement repondre 'Y' a
  la question ``Prompt for development and/or incomplete code/drivers?''
  (``Presenter  les questions pour les pilotes en cours de developpement
  ou incomplets?'')  lorsque que vous executez make config.

  Non-supporte signifie  qu'il  n'existe  pas  de  pilote  disponible  a
  l'heure  actuelle  pour  cette  carte.  Cela  peut etre du a un manque
  d'interet pour un materiel qui est rare/peu commun, ou parce  que  les
  distributeurs   ne   fourniront   pas  la  documentation  du  materiel
  necessaire pour l'ecriture du pilote.

  Notez que la difference entre `supporte'  et  `partiellement-supporte'
  est   plutot   subjective,  et  qu'elle  est  basee  sur  les  retours
  d'informations fournis par les utilisateurs, observes dans les groupes
  de  news et les listes de diffusions. (Apres tout, il est impossible a
  une personne de tester tous les pilotes avec toutes  les  cartes  pour
  chaque version du noyau!!!)  Soyez donc prevenus qu'une carte indiquee
  comme `partiellement-supportee' pourra tres bien fonctionner pour vous
  (ce  qui  est bien), ou qu'une carte indiquee comme `supportee' pourra
  vous donner des problemes sans fin (ce qui n'est pas aussi bien).

  5.1.  3Com

  Si vous n'etes pas sur de ce qu'est votre carte, mais que vous  pensez
  qu'il  s'agit d'une carte 3Com, vous pourrez certainement le deviner a
  partir  du  numero   d'assemblage.    3Com   dispose   d'un   document
  `Identifying   3Com  Adapters  By  Assembly  Number'  (Identifier  les
  adaptateurs 3Com par leur numero d'assemblage, reference 24500002) qui
  devrait      tres      certainement      eclaircir     les     choses.
  Consultez ``Informations techniques de 3Com'' pour plus d'informations
  sur la facon d'obtenir de 3Com des documents techniques.

  Notez  aussi  que  3Com  possede  un site FTP qui contient des tresors
  caches divers: ftp.3Com.com,  site  que  vous  pourrez  eventuellement
  consulter.

  Pour ceux qui consultent ce document sur le WWW, vous pouvez egalement
  essayer le site WWW de 3Com.

  5.1.1.  3c501

  Statut -- Partiellement-supporte

  Trop tapee du ciboulot pour etre utilisee. Disponible en surplus a  de
  nombreux  endroits.  Evitez-la  comme la peste. Je le redis: n'achetez
  pas cette carte, meme pour faire une  blague.  Ses  performances  sont
  horribles, et elle est derangee a plusieurs points de vue.

  Pour  ceux  qui  ne  seraient  pas encore convaincus, la 3C501 ne sait
  faire qu'une seule chose a 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 recevoir un  paquet
  pendant le chargement d'un paquet a transmettre.  C'etait parfait pour
  un reseau entre deux ordinateurs a base de 8088 ou  le  traitement  de
  chaque  paquet  et la reponse prenaient des dizaines de millisecondes,
  mais les reseaux modernes envoient des paquets les uns a la suite  des
  autres pour pratiquement chaque transaction.
  Les  IRQ  automatiques  fonctionnent,  le  DMA  n'est  pas utilise, la
  detection automatique ne teste que 0x280 et 0x300,  et  le  niveau  de
  debogage est indique dans le troisieme argument passe au demarrage.

  Encore une fois, l'utilisation d'une 3C501 est fortement deconseillee!
  Encore plus avec un noyau IP `multicast', puisque vous allez aboutir a
  un  arret  pendant  que  vous  ecoutez chacun des paquets `multicast'.
  Lisez les commentaires au debut du code source pour plus de details.

  5.1.2.  3c503, 3c503/16

  Statut -- Supporte

  Si  vous  avez  une  3c503/16  vous   serez   peut-etre   interesse(e)
  d'apprendre  que  depuis  le  noyau 1.3.37, le pilote a la possibilite
  d'utiliser en entier les 16 Ko de memoire vive  qui  se  trouvent  sur
  votre  carte.  Les  versions  anterieures traitaient les cartes 16bits
  comme des cartes 8bits, et n'utilisaient que la moitie de  la  memoire
  vive  disponible.  Cette  mise-a-jour  detecte  egalement  le  nouveau
  prefixe de 3Com que l'on trouve sur les cartes nouvellement fabriquees
  mentionnees ci-dessous.

  Les  cartes  3c503/16  recemment  fabriquees  possedent  une  nouvelle
  adresse physique de base parce que 3Com a epuise sa  plage  d'adresses
  physiques  (ils  fabriquent  trop de cartes!). Les cartes commencaient
  habituellement par 02 60 8C, les nouvelles utilisent 00 20 AF. Jusqu'a
  la  version  1.3.37 du noyau, le pilote ne verifiait que les anciennes
  adresses, et ne s'interessait pas aux nouvelles  cartes.  Vous  pouvez
  mettre votre noyau a jour vers une version plus recente que la 1.3.37,
  ou changer les valeurs dans le fichier 3c503.c pour  les  noyaux  plus
  anciens.

  Ces  cartes  devraient avoir la meme vitesse que les WD80x3 qui ont la
  meme largeur de bus, mais il se trouve qu'elles sont en realite un peu
  plus  lentes.   La 3c503 ne possede pas de memoire reprogrammable pour
  stocker sa  configuration  (un  ``EEPROM  setup''),  un  programme  de
  diagnostic  et  de  configuration  n'est  donc  pas  necessaire  avant
  d'utiliser la carte sous Linux. L'adresse de memoire  partagee  de  la
  3c503  est  fixee  en  utilisant  des cavaliers qui sont partages avec
  l'adresse de la memoire programmable  de  demarrage  (``boot  PROM'').
  Cela  a tendance a semer la confusion chez les personnes habituees aux
  autres cartes ISA, sur lesquelles vous laissez  toujours  le  cavalier
  sur  la position `desactivee' (disable en anglais) a moins d'avoir une
  PROM de demarrage.

  Ces  cartes  Ethernet  a  memoire  partagee  ont  aussi  un   mode   a
  Entrees/Sorties  programmees  qui n'utilise pas les possibilites de la
  8390 (leurs ingenieurs ont trouve trop de bogues!)  Le pilote 3c503 de
  Linux  sait  aussi travailler avec la 3c503 en mode d'E/S programmees,
  mais c'est plus lent et moins sur que le mode a memoire  partagee.  De
  plus,  le  mode  d'E/S programmees n'est pas aussi bien teste lors des
  mises a jour des pilotes. Vous ne devriez pas utiliser le  mode  d'E/S
  programmees  a  moins  d'en avoir besoin pour la compatibilite avec le
  DOS.

  La ligne d'IRQ de la 3c503 est fixee par logiciel, sans  l'aide  d'une
  EEPROM.  A  la  difference  des  pilotes sous DOS, le pilote Linux est
  capable de choisir automatiquement l'IRQ: il utilise la premiere ligne
  d'interruption  disponible  parmi {5,2/9,3,4}, en choisissant a chaque
  fois que la carte est ifconfiguree. (Les anciennes versions du  pilote
  selectionnaient  l'IRQ  au moment du demarrage.)  L'appel ioctl() dans
  `ifconfig' retournera EAGAIN si aucune ligne d'IRQ n'est disponible  a
  ce moment-la.

  Des  problemes classiques que les gens ont avec la 3c503 sont discutes
  dans ``Problemes avec...''.

  Si vous avez l'intention d'utiliser  ce  pilote  sous  la  forme  d'un
  module  chargeable, vous devriez probablement consulter ``Utiliser les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.1.3.  3c505

  Statut -- Partiellement-supporte

  Il  s'agit  d'un  pilote  qui  avait  ete  ecrit  par  Craig Southeren
  geoffw@extro.ucc.su.oz.au. Ces cartes utilisent la puce i82586 d'Intel
  et  sont  assez  peu  repandues.  Le  pilote  est inclus dans le noyau
  standard,   mais    il    est    classe    comme    pilote    `alpha'.
  Consultez ``Pilotes alpha'' pour des informations importantes a propos
  de l'utilisation de pilotes Ethernet en phase  de  test  `alpha'  sous
  Linux.

  Vous         devriez        aussi        lire        le        fichier
  /usr/src/linux/drivers/net/README.3c505 si vous comptez  utiliser  une
  de   ces  cartes.   Il  contient  diverses  options  que  vous  pouvez
  activer/desactiver.   Des  informations  techniques  sont  disponibles
  dans ``Programmation des puces Intel''.

  5.1.4.  3c507

  Statut -- Partiellement-supporte

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

  Consultez  ``Pilotes  alpha''  pour   des   informations   importantes
  concernant  l'utilisation  de  pilotes  en  phase de test `alpha' sous
  Linux.     Des    informations     techniques     sont     disponibles
  dans ``Programmation des puces Intel''.

  5.1.5.  3c509 / 3c509B

  Statut -- Supporte

  Cette  carte  est  plutot bon marche et possede de bonnes performances
  pour une conception qui n'est pas `bus-master' (`maitre de bus').   Le
  revers  de  la  medaille  est  que la 3c509 originelle necessitait des
  temps de latence vraiment tres faibles en reponse  aux  interruptions.
  La  3c509B ne souffre pas du meme probleme, car elle possede un tampon
  memoire plus important (voir ci-dessous).  Ces  cartes  utilisent  des
  transferts  en  mode  d'Entrees/Sorties  programmees (PIO), de la meme
  facon qu'une carte ne2000, et  par  consequent  une  carte  a  memoire
  partagee comme la wd8013 sera plus efficace en comparaison.

  La  3c509  d'origine  avait  un  petit tampon memoire pour les paquets
  (4 Ko au total, 2 en reception et 2 en transmission), ce qui  poussait
  le  pilote  a eliminer un paquet si les interruptions etaient masquees
  trop longtemps. Pour minimiser ce probleme, vous pouvez essayer de de-
  masquer  les  interruptions  pendant  les  transferts  sur disques IDE
  (consultez man hdparm) et / ou augmenter la vitesse de votre  bus  ISA
  de facon a ce que les transferts IDE se terminent plus tot.

  Le modele plus recent, la 3c509B, possede 8 Ko de memoire emportee, et
  le   tampon   peut   etre   partage   en   4/4,   5/3   ou   6/2    en
  reception/transmission.   Ce   parametre   est   change  a  l'aide  de
  l'utilitaire de configuration sous DOS, et est stocke dans la  memoire
  EEPROM.  Cela  devrait  eliminer  le  probleme precedent avec la 3c509
  originelle.

  Les utilisateurs de 3c509B devraient utiliser l'utilitaire DOS  fourni
  afin  de  desactiver  le  `plug  and  play',  et afin de determiner le
  support de sortie dont ils ont  besoin.  Le  pilote  Linux  n'est  pas
  capable   aujourd'hui   d'utiliser   la  fonctionnalite  de  detection
  automatique du support physique, donc vous devez selectionner 10Base-T
  ou 10Base-2 ou AUI.  En ce qui concerne la fonctionnalite de detection
  du support physique, Cameron nous dit: ``La selection automatique  est
  une fonctionnalite des pilotes commerciaux de la 3C509(B). Pour autant
  que je sache, personne n'a jamais pretendu que le pilote Linux  essaye
  de  la  realiser.   Lorsque driversnet/3c509.c/ reconnait ma 3C509B au
  demarrage, il dit: eth0: 3c509 at 0x300  tag  1,  10baseT  port,  ...,
  revelant  ainsi  que  la  carte  est  configuree pour le 10BASE-T.  Il
  trouve cette information en lisant la petite  EEPROM,  ce  qui  a  mon
  humble avis est La Bonne Maniere De Faire.''

  En  ce  qui  concerne la partie ``plug-and-pray'' (branchez et priez),
  Cameron ajoute: ``La 3C509B  comporte  le  principe  des  ports  d'E/S
  relogeables   de   3Com,   ainsi   que  le  Plug-and-play  ("PnP")  de
  Microsofttm.  Vous ne pouvez pas utiliser  les  deux  en  meme  temps.
  Certains  BIOS  (detraques, a mon humble avis) commencent une sequence
  PnP en ecrivant a l'adresse  PnP  (0x279  ?),  ce  qui  fait  que  les
  adaptateurs PnP comme la 3C509B entrent dans l'etat PnP, mais ils (ces
  BIOS de rigolos) ne reviennent jamais finir le boulot.  Les 3C509B  se
  bloquent  en  plein  milieu  de la sequence d'identification PnP, sans
  savoir le moins du monde que ce n'etait pas ce que  vous  vouliez,  et
  que  finalement  vous  allez  utiliser la sequence d'identification de
  3Com. 3C5X9CFG /PNPRST elimine ce blocage. Desactivez le  PnP  si  vos
  pilotes (par exemple, Linux) ne l'utilisent pas.

  Le  fait  de  mettre le PnP en route dans les parametres d'usine a ete
  une decision commerciale. Prenez le temps de dire si cela vous a cause
  un  probleme,  ou  pas,  lorsque vous envoyez votre carte de garantie.
  Plus ils auront d'informations et meilleures seront  leurs  decisions.
  Et  aussi,  verifiez  avec  le fournisseur de votre carte-mere si vous
  avez besoin d'une mise-a-jour du BIOS.''

  Il a ete rapporte que vous avez besoin d'effectuer  un  redemarrage  a
  froid  (``hard  reset'') apres avoir effectue le 3C5X9CFG /PNPRST pour
  que les changements prennent effet.

  Certaines personnes ont pose des questions sur les parametres ``Server
  or  Workstation''  (serveur  ou station de travail) et ``Highest Modem
  Speed''  (plus  haute  vitesse  de  modem)  qui  sont  presentes  dans
  l'utilitaire  de  configuration du DOS.  Donald ecrit que ``Ce ne sont
  que des orientations fournies au pilotes, et le pilote Linux n'utilise
  pas  ces  parametres;  il  optimise toujours pour un taux de transfert
  important plutot que pour un temps de latence  faible  (`Server').  Un
  temps  de  latence  faible  etait  un  critere  critique pour le vieux
  trafic, non-fenetre, de IPX. Afin de reduire le temps de  latence,  le
  pilote  sous  DOS  de  la  3c509 inhibe les interruptions de certaines
  operations,  bloquant  les  interruptions  du  port  serie.  D'ou   la
  necessite  du  parametre  `modem  speed' (vitesse du modem). Le pilote
  Linux evite la  necessite  de  desactiver  les  interruptions  sur  de
  longues  periodes  en ne travaillant que sur des paquets complets, par
  exemple en ne commencant pas a transmettre un paquet avant qu'il n'ait
  ete completement transfere sur la carte.''
  Notez  que  la  procedure  de  detection  de  la carte ISA utilise une
  methode differente de la plupart des autres cartes.  A la  base,  vous
  demandez  aux  cartes  de repondre en envoyant des donnees sur un port
  ID_PORT (port 0x100).  Cette  methode  de  detection  signifie  qu'une
  carte  donnee sera toujours detectee en premier dans une configuration
  comportant plusieurs cartes ISA 3c509.  La carte avec la  plus  petite
  adresse  Ethernet  physique  sera toujours eth0. Cela ne devrait gener
  personne, a l'exception des gens qui souhaitent assigner  une  adresse
  physique  sur 6 octets a une interface donnee.  Si vous avez plusieurs
  cartes 3c509, il vaut mieux ajouter des commandes ether=0,0,ethN  sans
  preciser  le  port  d'E/S  (c'est-a-dire  en  utilisant  E/S=zero)  et
  autoriser la procedure de detection a faire  le  tri  pour  determiner
  quelle  carte  est  la  premiere,  sinon elle pourrait ne pas detecter
  toutes vos cartes.

  Si cela vous gene vraiment, jetez  un  coup  d'oeil  au  tout  dernier
  pilote  de  Donald,  car  cela  vous  permettra  d'utiliser une valeur
  0x3c509 dans le champ (inutilise) de l'adresse memoire pour obliger la
  detection a reussir.

  5.1.6.  3c515

  Statut -- Non-supporte

  Il s'agit de l'offre relativement recente 100 M de 3Com en ISA, nom de
  code ``CorkScrew'' (tire-bouchon, en anglais).  Donald  travaille  sur
  le  support  de  ces  cartes,  et cela devrait probablement apparaitre
  bientot dans sa page WWW sur les pilotes.  Le  pilote  sera  incorpore
  dans  celui  des 3c59x/3c90x, et vous auriez certainement interet a le
  chercher dans la page sur les ``Vortex'':

       Vortex       <http://cesdis.gsfc.nasa.gov/linux/drivers/vor-
       tex.html>

  5.1.7.  3c523

  Statut -- Partiellement-supporte

  Cette carte pour bus MCA utilise la puce i82586, et Chris Beauregard a
  modifie le pilote ni52 pour  qu'il  fonctionne  avec  ces  cartes.  Le
  pilote  correspondant peut etre trouve dans l'arborescence des sources
  des noyaux 2.1.

  Plus  de  details  sont  fournis  sur  la  page  MCA  pour   Linux   a
  http://glycerine.cetmm.uni.edu/mca/

  5.1.8.  3c527

  Statut -- Non-supporte

  Eh  oui,  encore  une  autre carte MCA. Eh non, pas beaucoup d'interet
  pour celle-ci. Vous aurez plus de chance avec la 3c529 si  vous  tenez
  au MCA.

  5.1.9.  3c529

  Statut -- Partiellement-supporte

  Cette  carte  utilise  en  fait le meme jeu de puces que la 3c509.  De
  fait, Donald a place des points de depart dans le pilote de  la  3c509
  pour  verifier l'existence de cartes MCA apres la detection des cartes
  EISA, et avant la detection des cartes ISA. Mais cela n'a guere evolue
  plus loin que ca. Donald ecrit:

  ``Je n'ai pas acces a une machine MCA (et je ne comprends pas non plus
  completement le code de detection), donc  je  n'ai  jamais  ecrit  les
  routines  mca_adaptor_select_mode()  ou mca_adaptor_id(). Si vous etes
  capable de trouver un moyen d'obtenir l'adresse d'E/S que l'adaptateur
  s'est  vu  affecter au demarrage, vous pouvez tout simplement l'ecrire
  en dur a la place de la procedure de detection  mise  en  commentaire.
  Soyez  sur(e)  de  conserver  le  code  qui  lit  l'IRQ,  l'if_port et
  l'adresse Ethernet.''

  Darrell Frappier (aa822@detroit.freenet.org) indique que  vous  pouvez
  obtenir  l'adresse  d'E/S en executant la disquette de reference PS/2,
  et qu'une fois que vous avez mis cette information directement dans le
  pilote, cela fonctionne bel et bien.

  Le  code  de detection MCA qui est necessaire appraraitra certainement
  prochainement dans le pilote d'une version de developpement du  noyau,
  maintenant que le support MCA est integre au noyau.

  PLus  de  details  peuvent  etre  trouves sur la page MCA pour Linux a
  l'adresse http://glycerine.cetmm.uni.edu/mca/.

  5.1.10.  3c562

  Statut -- Supporte

  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 difficulte est d'arriver a faire en sorte que les deux
  pilotes  Linux  partagent  la  meme interruption.  Il y a une serie de
  nouveaux registres et un peu de  support  de  partage  d'interruptions
  materielles.   Vous  aurez  besoin  d'utiliser  un  noyau  2.0 ou plus
  recent, qui comporte ce qu'il faut pour le partage d'interruptions.

  Un peu en commentaire, certaines personnes ont indique que  la  partie
  modem  de  la  carte n'est pas tres bien documentee pour l'utilisateur
  final (le manuel dit juste qu'elle `comprend le jeu de commandes  AT')
  et  qu'elle  ne  se  connecte  pas  aussi bien que des modems d'autres
  marques. La recommandation est plutot d'acheter une 3c589B a la place,
  puis  d'obtenir  une  carte  modem  PCMCIA  par  une  societe  qui est
  specialisee dans les modems.

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

  Consultez ``PCMCIA'' pour plus d'information sur  les  jeux  de  puces
  PCMCIA, les activateurs de sockets, etc.

  5.1.11.  3c575

  Statut -- Non-supporte

  Un  pilote  pour  cette  carte PCMCIA est en cours de developpement et
  l'on peut esperer qu'il sera inclus dans le paquetage PCMCIA de  David
  d'ici quelques mois.

  5.1.12.  3c579

  Statut -- Supporte

  La  version  EISA  de la 509. La version EISA actuelle utilise la meme
  puce de largeur 16 bits  plutot  qu'une  interface  32  bits,  et  les
  performances  ne  sont donc pas epoustouflantes.  Le code de detection
  EISA a ete ajoute dans 3c509.c pour la version 0.99pl14.  Assurez-vous
  que  la  carte  est configuree pour le mode d'adressage EISA. Lisez la
  section precedente sur la 3c509 pour des informations sur le pilote.

  5.1.13.  3c589 / 3c589B

  Statut -- Partiellement-supporte

  Beaucoup de monde utilise cette carte PCMCIA depuis deja un  bon  bout
  de  temps.  Notez  qu'elle n'est pas incluse (a l'heure actuelle) dans
  l'arborescence par defaut du noyau. Vous aurez aussi besoin  d'un  jeu
  de  puces  pour  que le controleur PCMCIA soit gere par le noyau.  Des
  pilotes sont disponibles sur le site FTP de Donald:

          cesdis.gsfc.nasa.gov:/pub/linux/pcmcia/README.3c589
          cesdis.gsfc.nasa.gov:/pub/linux/pcmcia/3c589.c
          cesdis.gsfc.nasa.gov:/pub/linux/pcmcia/dbether.c

  Ou, pour ceux qui consultent ce  document  sur  le  WWW,  vous  pouvez
  essayer:

       Le        PCMCIA        chez       Donald       <http://ces-
       dis.gsfc.nasa.gov/linux/pcmcia.html>

  Vous aurez encore besoin d'un activateur de socket PCMCIA (un  `socket
  enabler'), aussi.

  Consultez  ``PCMCIA''  pour  plus  d'information sur les jeux de puces
  PCMCIA, les activateurs de sockets, etc.

  Le "B" dans le nom signifie la meme chose ici que dans le  cas  de  la
  3c509.

  5.1.14.  3c590 / 3c595

  Statut -- Supporte

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

  Vortex       <http://cesdis.gsfc.nasa.gov/linux/drivers/vor-
  tex.html>

  Notez qu'il existe en fait deux cartes 3c590, des modeles des premiers
  temps  ayant  32  Ko de memoire, et des modeles plus recents qui n'ont
  que 8 Ko (glups!) de memoire. Il y a des  chances  pour  que  vous  ne
  puissiez  plus  acheter  une 3c59x neuve, car elles ont ete remplacees
  par les 3c90x. Si vous achetez une carte d'occasion, essayez d'obtenir
  la  version  32 Ko. Les cartes 3c595 ont 64 Ko, car vous ne pouvez pas
  faire grand-chose avec seulement 8 Ko de memoire vive a 100 Mb/s!

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

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

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

  5.1.15.  3c592 / 3c597

  Statut -- Supporte

  Ce  sont  les  versions  EISA  des series 3c59x. La 3c592/3c597 (aussi
  connue sous le nom de Demon) devrait fonctionner avec le pilote Vortex
  presente au paragraphe precedent.

  5.1.16.  3c900 / 3c905

  Statut -- Supporte

  Ces  cartes  (aussi  connues  sous  le  nom  de `Boomerang', ou encore
  EtherLink III XL) ont ete recemment mises sur le marche pour remplacer
  les  cartes  3c590/3c595. Cameron Spitzer de 3Com ecrit que la ``3C900
  possede un maitre de bus a ramasse-miette controle par  un  anneau  de
  descripteurs en memoire principale. A part ca, elle ressemble beaucoup
  a une 3C590.''

  Vous devriez encore pouvoir obtenir quelques unes de ces cartes  a  un
  prix  reduit  en passant par l'une des offres d'evaluation de 3Com, si
  vous etes rapide.

  Pour utiliser cette carte avec les noyaux 2.0, vous devez  obtenir  le
  pilote 3c59x.c mis a jour sur le site de Donald:

       Vortex       <http://cesdis.gsfc.nasa.gov/linux/drivers/vor-
       tex.html>

  Ce pilote 3c59x mis a jour vous permet d'utiliser  la  3c900  dans  un
  mode  de  compatibilite 3c59x, et l'on rapporte qu'il est relativement
  bien stable.  Notez  que  ce  pilote  mis  a  jour  pourrait  integrer
  l'arborescence des sources de la 2.0 a une date ulterieure.

  (NDT: Cela semble etre le cas depuis la 2.0.31.)

  Sur  la  meme  page  WWW,  vous trouverez aussi le pilote experimental
  boomerang.c qui utilise certaines  des  ameliorations  des  3c900  par
  rapport aux 3c590x. Puisqu'il s'agit d'un pilote nouveau/experimental,
  il vaut mieux que vous utilisiez le pilote 3c59x.c mis a  jour  si  la
  stabilite du systeme est le plus important.

  Donald  a  mis  en  place  une  liste de diffusion sur le support, les
  annonces, etc... du pilote Vortex. Pour vous abonner a  la  liste,  il
  suffit de faire:

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

  5.2.  Accton

  5.2.1.  Accton MPX

  Statut -- Supporte

  Ne  vous  laissez  pas  avoir par le nom. Cette carte est tout de meme
  supposee etre une compatible NE2000. Le `MPX' est suppose etre la pour
  `MultiPacket  Accelerator'  (accelerateur multi-paquet), ce qui, selon
  Accton, augmente substantiellement le debit. Mais si vous envoyez deja
  des  paquets  les uns a la suite des autres, comment pouvez-vous aller
  un tant soit peu plus vite...

  5.2.2.  Accton EN1203, EN1207, EtherDuo-PCI

  Statut -- Supporte

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

  Consultez ``DEC 21040'' pour plus d'informations sur ces cartes, et la
  situation actuelle du pilote.

  5.2.3.  Adaptateur Accton EN2209 pour port parallele (EtherPocket)

  Statut -- Partiellement-supporte

  Un  pilote pour ces adaptateurs sur port parallele est disponible mais
  ne fait pas encore partie des sources des noyaux  2.0  ou  2.1.   Vous
  pouvez obtenir le pilote sur:

       http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html

  5.2.4.  Accton EN2212 PCMCIA

  Statut -- Partiellement-supporte

  David Hinds a travaille sur un pilote pour cette carte, et vous feriez
  certainement mieux de consulter la derniere version de  son  paquetage
  PCMCIA pour voir ce qu'il en est.

  5.3.  Allied Telesyn/Telesis

  5.3.1.  AT1500

  Statut --Supporte

  Il  s'agit  d'une serie de cartes Ethernet peu cheres qui utilisent la
  version 79C960 de la puce LANCE d'AMD. Ce sont des  cartes  maitresses
  de  bus,  et elles figurent donc parmi les cartes Ethernet sur bus ISA
  disponibles les plus rapides.

  La selection du DMA et des informations sur la numerotation de la puce
  se trouvent dans ``AMD LANCE''.

  Plus  d'informations  techniques  sur  les  cartes Ethernet basees sur
  l'AMD LANCE sont disponibles dans ``Notes sur l'AMD...''.

  5.3.2.  AT1700

  Statut -- Supporte

  Notez que pour acceder a ce pilote  pendant  make  config  vous  devez
  encore  repondre  `Y'  a  la  question ``Prompt for development and/or
  incomplete code/drivers?'' en premier lieu. Ceci est  tout  simplement
  du  au manque de retour d'information sur la stabilite du pilote etant
  donne  qu'il  s'agit  d'une  carte  relativement  rare.    Ceci   aura
  certainement ete modifie pour les noyaux 2.1.

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

  Une  fonctionnalite  unique est la possibilite de piloter du cable STP
  (Shielded Twisted Pair, paire torsadee blindee)  150  ohms  couramment
  instlalle  pour  le  Token  Ring,  en  plus  du  cable  100  ohms  UTP
  (Unshielded Twisted Pair, paire torsadee non-blindee) de 10BaseT.  Une
  version fibre optique de la carte (AT1700FT) existe egalement.

  La  puce Fujitsu utilisee sur l'AT1700 a un defaut de conception: elle
  ne peut etre remise completement a  zero  qu'en  effectuant  un  cycle
  d'allumage  de  la  machine.  Le  fait  d'appuyer  sur  le  bouton  de
  redemarrage (`Reset') ne reinitialise pas l'interface du bus. Cela  ne
  serait  pas  genant,  si  la  carte  ne pouvait etre detectee qu'apres
  qu'elle ait ete  recemment  reinitialisee.  La  solution/le  moyen  de
  contourner  le  probleme est d'eteindre puis de rallumer la machine si
  le noyau a un probleme pour detecter l'AT1700.

  Certaines series de production de  l'AT1700  ont  un  autre  probleme:
  elles  sont  concues pour utiliser de facon permanente le canal DMA 5.
  Ceci n'est pas documente, il n'existe aucun cavalier  pour  desactiver
  cette  "fonctionnalite", et aucun pilote n'ose utiliser la possibilite
  de DMA  a  cause  de  problemes  de  compatibilite.  Aucun  pilote  de
  peripherique ne sera ecrit pour utiliser la DMA si le fait d'installer
  une seconde carte dans la machine casse les deux cartes,  et  le  seul
  moyen de desactiver le DMA est d'utiliser un couteau.

  5.3.3.  AT2450

  Statut -- Supporte

  La  version  PCI  de  l'AT1500, qui ne souffre pas des problemes de la
  carte PCI 79c970 de Boca. Allied Telsyn en etait encore au  stade  des
  `beta-test'  au  debut/a  la  mi-1995, donc elle ne devrait pas s'etre
  repandue aupres des divers revendeurs a l'heure qu'il est (mais ca  ne
  fait pas de mal de demander.)

  La selection du DMA et des informations sur la numerotation de la puce
  se trouvent dans ``AMD LANCE''.

  Plus d'informations techniques sur  les  cartes  Ethernet  basees  sur
  l'AMD LANCE sont disponibles dans ``Notes sur l'AMD...''.

  5.4.  AMD / Advanced Micro Devices

  Carl  Ching  d'AMD a eu la gentillesse de fournir une description tres
  detaillee de tous les produits Ethernet d'AMD cites, ce qui  a  permis
  de clarifier cette section.

  5.4.1.  AMD LANCE (7990, 79C960/961/961A, PCnet-ISA)

  Statut -- Supporte

  Il  n'existe en fait aucune carte Ethernet AMD. Vous etes certainement
  en train de lire ce paragraphe parce que les seules marques  que  vous
  pouvez trouver sur votre carte disent `AMD' et le numero ci-dessus. La
  7990 est la puce `LANCE' d'origine, mais  la  plupart  des  choses  (y
  compris ce document) se referent a toutes ces puces similaires sous la
  denomination de puces `LANCE' (...incorrectement, devrais-je ajouter).

  Les numeros ci-dessus se referent aux puces d'AMD qui sont le coeur de
  nombreuses cartes Ethernet.  Par exemple,  l'AT1500  d'Allied  Telesis
  (voir  ``AT1500''),  et la NE1500/2100 (voir ``NE1500'') utilisent ces
  puces.

  La 7990/79c90 a ete remplace depuis bien longtemps  par  des  versions
  plus  recentes.  La  79C960  (aussi  connue  sous le nom de PCnet-ISA)
  contient pour l'essentiel la base de la 79c90, avec  tout  le  support
  materiel  complementaire  requis, ce qui permet de monter une solution
  Ethernet en une seule puce. La 79c961  (PCnet-ISA+)  est  une  version
  ``Plug  and  Play'',  sans  cavaliers, de la 960. La derniere puce des
  series ISA est la 79c961A (PCnet-ISA II), qui ajoute des capacites  de
  full  duplex.  Toutes les cartes comportant une de ces puces devraient
  fonctionner avec le pilote lance.c, a  l'exception  de  tres  vieilles
  cartes  qui  utilisent  la  7990  d'origine  avec  une configuration a
  memoire partagee. Ces  cartes  anciennes  peuvent  etre  reperees  par
  l'absence de cavaliers pour le choix d'un canal DMA.

  Un  probleme  classique  que  les  gens  rencontrent  est  le  message
  `busmaster arbitration failure'. Ce message s'affiche quand le  pilote
  LANCE  ne  peut  pas  obtenir  un  acces  au  bus  apres  qu'un  temps
  raisonnable  se  soit  ecoule  (50   micro-secondes).   Cela   indique
  habituellement  que  l'implementation  de la maitrise de bus DMA de la
  carte-mere est incorrecte, ou qu'un autre peripherique  monopolise  le
  bus,  ou  qu'il  y  a  un  conflit de canal DMA. Si votre programme de
  configuration du BIOS possede la `GAT  option'  (GAT  pour  Guaranteed
  Access  Time, temps d'acces garanti), essayez de modifier ce parametre
  pour voir si cela va mieux.

  Notez aussi que le  pilote  ne  cherche  une  carte  valide  qu'a  ces
  adresses: 0x300, 0x320, 0x340, 0x360, et qu'une adresse fournie par un
  argument de demarrage ether= est  ignoree  sans  qu'il  en  soit  fait
  mention  (ceci  sera  corrige),  donc assurez-vous que votre carte est
  configuree pour l'une des adresses d'E/S ci-dessus, pour l'instant.

  Le pilote fonctionnera encore correctement, meme si plus de 16  Mo  de
  memoire  sont  installes, car des tampons-relais en memoire basse sont
  utilises au besoin (c'est-a-dire que toute donnee situee au-dela de la
  limite  des  16  Mo  est copiee dans un tampon en-dessous de la limite
  avant d'etre remis a la carte pour transmission.)

  Le canal DMA peut etre configure avec les bits (inutilises  en  dehors
  de  ca)  de  la  valeur  de dev->mem_start (aussi connue comme PARAM_1
  (voir ``PARAM_1'').  S'il n'est pas fixe, il  est  teste  en  activant
  chaque  canal  DMA  tour  a  tour  et en regardant si l'initialisation
  reussit.

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

  Voir ``Notes on AMD...'' pour plus d'informations sur ces puces.

  5.4.2.  AMD 79C965 (PCnet-32)

  Statut -- Supporte

  Il  s'agit de la PCnet-32 -- une version 32 bits, maitre de bus, de la
  puce LANCE originelle pour les systemes VLB (Vesa Local Bus) et a  bus
  local.  Bien  que  ces  puces  puissent  etre  utilisee avec le pilote
  lance.c standard, une version 32 bits (lance32.c) est aussi disponible
  qui  n'a pas a se preoccuper des limitations a 16 Mo liees au bus ISA.

  5.4.3.  AMD 79C970/970A (PCnet-PCI)

  Statut -- Supporte

  Il s'agit de la PCnet-PCI -- similaire a la PCnet-32, mais concue pour
  des  systemes  bases  sur  le  bus  PCI.  De  nouveau,  consultez  les
  informations ci-dessus sur la PCnet-32.  Cela signifie que vous  devez
  construire  un noyau comportant le support du BIOS PCI. La 970A ajoute
  le support du mode full duplex ainsi que d'autres fonctionnalites  par
  rapport a la conception d'origine de la 970.

  Notez  que  l'implementation  de Boca pour la 79C970 ne fonctionne pas
  sur les machines Pentium rapides. Il s'agit  d'un  probleme  materiel,
  puisqu'il affecte aussi les utilisateurs DOS. Consultez la section sur
  Boca pour plus de details.

  5.4.4.  AMD 79C971 (PCnet-FAST)

  Statut -- Supporte

  Il s'agit de la puce 100  Mbits  d'AMD  pour  les  systemes  PCI,  qui
  comporte elle aussi le mode full duplex. Elle a ete introduite en juin
  1996 sur le marche.

  5.4.5.  AMD 79C974 (PCnet-SCSI)

  Statut -- Supporte

  Il s'agit de la PCnet-SCSI -- qui a la base est traitee 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 supporte -- il s'agit
  de l'Ethernet-HOWTO, pas du SCSI-HOWTO.

  5.5.  Ansel Communications

  5.5.1.  AC3200 EISA

  Statut -- Partiellement-supporte

  Notez  que  pour  acceder  a  ce pilote pendant make config vous devez
  encore repondre `Y' a la  question  ``Prompt  for  development  and/or
  incomplete  code/drivers?''  en premier lieu. Ceci est tout simplement
  du au manque de retour d'information sur la stabilite du pilote  etant
  donne qu'il s'agit d'une carte relativement rare.

  Ce  pilote  est  inclus  dans le noyau actuel comme pilote en phase de
  test `alpha'. Il est base sur la classique puce NS8390  utilisee  dans
  les  cartes  NE2000 et WD80x3.  Veuillez consulter ``Pilotes `alpha'''
  dans le present document pour des informations importantes  concernant
  les pilotes `alpha'.

  Si  vous  l'utilisez,  veuillez  informer  l'un de nous de comment les
  choses fonctionnent, car nous avons eu peu  de  retour  d'information,
  meme si le pilote est dans le noyau depuis la version 1.1.25.

  Si vous avez l'intention d'utiliser ce pilote comme module chargeable,
  vous devriez certainement  lire  ``Utilisation  des  pilotes  Ethernet
  comme modules'' ainsi que ``Les cartes basees sur le 8390 en modules''
  pour des informations specifiques aux modules.

  5.6.  Apricot

  5.6.1.  Apricot Xen-II On Board Ethernet

  Statut -- Supporte

  Cette carte Ethernet sur carte-mere utilise une puce i82596 maitre  de
  bus.  Elle ne peut se trouver qu'a l'adresse d'E/S 0x300.  L'auteur de
  ce pilote est Mark Evans.  En  consultant  le  source  du  pilote,  il
  apparait que l'IRQ est materiellement fixee a 10.

  Les  premieres  versions  du  pilote avaient une tendance a croire que
  tout ce qui vivait  en  0x300  etait  un  adaptateur  reseau  Apricot.
  Depuis,  l'adresse  materielle est testee afin d'eviter ces detections
  erronees.

  5.7.  Arcnet

  Statut -- Supporte

  Avec  le  cout  vraiment  tres  bas  et  les  meilleures  performances
  d'Ethernet,  il  est  probable  que  la  plupart  des endroits vont se
  debarasser de leur materiel Arcnet pour rien, ce qui amenera un  grand
  nombre de systemes a la maison a utiliser Arcnet.

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

  Le pilote Arcnet d'Avery Pennarun a ete dans le noyau par  defaut  des
  la  version  1.1.80.  Le  pilote Arcnet utilise `arc0' pour son nom au
  lieu de l'`eth0' habituel pour les peripheriques Ethernet.

  Les rapports de bogues et les rapports de succes  sur  Arcnet  peuvent
  etre adressees a:

  apenwarr@foxnet.net

  Le   noyau  standard  comporte  des  fichiers  d'information  pour  la
  configuration des cavaliers et des aides plus generales.

  On peut supposer que le pilote fonctionne aussi avec les cartes ARCnet
  100 Mb/s!

  5.8.  AT&T

  Notez  que  le  StarLAN d'AT&T est une technologie orpheline, comme le
  LattisNet de SynOptics, et qu'elle ne peut pas etre utilisee  dans  un
  environnement  10Base-T  standard,  sans  un  hub qui `parle' les deux
  protocoles.

  5.8.1.  AT&T T7231 (LanPACER+)

  Statut -- Non-supporte

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

  5.9.  AT-Lan-Tec / RealTek

  5.9.1.  AT-Lan-Tec / RealTek Pocket adaptor

  Statut -- Supporte

  Il s'agit d'un adaptateur de poche generique, peu cher,  developpe  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.
  Notez qu'une quantite substantielle d'information est contenue dans le
  fichier source du pilote, atp.c.
  Notez que le nom du peripherique que vous passez a ifconfig n'est  pas
  eth0 mais atp0 pour ce peripherique.

  5.9.2.  RealTek 8029

  Statut -- Supporte

  Il s'agit d'une implementation PCI a une seule puce d'un clone NE2000.
  Differents fournisseurs vendent maintenant des cartes comportant cette
  puce.    Consultez   ``NE2000   PCI''   pour   des   informations  sur
  l'utilisation d'une de ces cartes.

  5.9.3.  RealTek 8129/8139

  Statut -- Partiellement-supporte

  Encore une autre solution Ethernet PCI a puce unique de  RealTek.   Un
  pilote  pour les cartes basees sur cette puce devrait etre inclus dans
  la version 2.0.34 du noyau Linux. Pour plus d'informations, consultez:

       http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html

  5.10.  Boca Research

  Oui, ils font autre chose que des cartes series multi-ports. :-)

  5.10.1.  Boca BEN (PCI, VLB)

  Statut -- Supporte

  Ces  cartes  sont  basees  sur  les  puces PCnet d'AMD.  Les acheteurs
  prevoyants doivent etre prevenus que de nombreux utilisateurs  ont  eu
  des problemes sans fin avec ces cartes.  Les proprietaires de systemes
  Pentium rapides ont ete specialement touches. Notez  qu'il  ne  s'agit
  pas  d'un  probleme du pilote, puisqu'il touche aussi les utilisateurs
  de DOS/Windows/NT.  Le numero du support  technique  de  Boca  est  le
  1 (407) 241-8088,

  (NDT: Ce numero est bien entendu aux Etats-Unis.)

  et vous pouvez aussi les joindre a 75300.2672@compuserve.com.

  Donald  a  realise  un  test  comparatif  entre  les  cartes  PCI Boca
  precedentes et une implementation similaire d'Allied  Telsyn  avec  la
  puce   PCnet/PCI,   qui   montrait  que  le  probleme  se  situe  dans
  l'implementation faite par Boca de la puce PCnet/PCI. Les resultats de
  ce test peuvent etre trouves sur le serveur WWW de Don:

       Linux @ CESDIS <http://cesdis.gsfc.nasa.gov/linux/>

  Boca  offre une `reparation - garantie' aux proprietaires affectes par
  ce probleme, qui entraine l'ajout  d'un  des  condensateurs  manquant,
  mais  il semble que cette correction ne fonctionne pas a 100 % pour la
  plupart des gens, bien que cela en aide quelques uns.

  Si vous pensez encore acheter  une  de  ces  cartes,  alors  au  moins
  essayez  d'obtenir  une  regle  de retour inconditionnel sous 7 jours,
  pour que vous puissiez la rendre si ele ne fonctionne pas correctement
  dans votre systeme.

  Des  informations  plus  generales  sur  les  puces  AMD  se  trouvent
  dans ``AMD LANCE''.

  Plus d'informations techniques sur  les  cartes  Ethernet  basees  sur
  l'AMD LANCE sont disponibles dans ``Notes sur l'AMD...''.

  5.11.  Cabletron

  Donald  ecrit:  ``Oui, encore une autre de ces societes qui ne donnera
  pas ses informations pour programmer. Ils ont attendu des  mois  avant
  de   confirmer   qu'en   fait   toutes   leurs   informations  etaient
  proprietaires, depensant deliberement mon temps. Evitez  leurs  cartes
  comme la peste si vous le pouvez.  Notez aussi que certaines personnes
  ont appele Cabletron, et se sont entendu dire  des  choses  comme  `un
  certain  D.  Becker  travaille  sur  un pilote pour Linux' -- laissant
  entendre que je travaille pour eux.  Ce N'est PAS le cas.''

  Si vous vous sentez pret a leur demander pourquoi ils ne donneront pas
  leurs  informations  de  programmation  bas  niveau  afin que les gens
  puissent utiliser leurs cartes, ecrivez a  support@ctron.com.   Dites-
  leur que vous utilisez Linux, et que vous etes surpris qu'ils n'aident
  pas les systemes ouverts. Et non, le kit de developpement habituel est
  sans utilite. Il ne contient qu'un fichier-objet pour DOS que l'on est
  suppose lier avec son executable. Un fichier que vous n'avez meme  pas
  le droit de desassembler.

  5.11.1.  E10**, E10**-x, E20**, E20**-x

  Statut -- Partiellement-supporte

  Il  s'agit  de presque-clones NEx000 qui fonctionnent avec les pilotes
  NEx000 standards d'apres les  informations  qui  nous  sont  revenues,
  grace a un test special-Cabletron dans la procedure de detection. S'il
  y a le moindre probleme, il ne sera tres certainement pas resolu,  car
  les informations de programmation ne sont pas disponibles.

  5.11.2.  E2100

  Statut -- Partiellement-supporte

  Un  fois  de  plus,  on  ne  peut  pas  faire  grand-chose  quand  les
  informations de programmation sont proprietaires.  La E2100  beneficie
  d'une  conception  lamentable.   Des qu'elle mappe sa memoire partagee
  pendant un transfert de paquet, elle le fait  en  utilisant  toute  la
  zone de 128 Ko!  Cela signifie que vous ne pouvez pas, sur cette zone,
  utiliser de facon securisee un autre peripherique a  memoire  partagee
  gere par interruption, y compris une autre E2100. Cela fonctionnera la
  plupart du temps, mais de temps a autre cela vous sautera a la figure.
  (Oui,  on  pourrait  eviter  ce probleme en inhibant les interruptions
  pendant le transfert des  paquets,  mais  dans  ce  cas-la  on  perdra
  pratiquement  a  coup  sur  des  tops  d'horloge.)  De  plus,  si vous
  programmez incorrectement la carte, ou que  vous  arretez  la  machine
  juste  au mauvais moment, meme le bouton de `reset' ne la rendra pas a
  la vie. Vous devrez eteindre la machine et attendre qu'elle se  repose
  pendant 30 secondes.

  La  selection  du  support  physique est automatique, mais vous pouvez
  outrepasser cette  fonctionnalite  en  utilisant  les  bits  de  poids
  faibles   du   parametre  dev->mem_end.   Consultez  ``PARAM_2''.  Les
  utilisateurs des modules peuvent specifier une valeur  xcvr=N  sur  la
  ligne de commande d'insmod pour faire la meme chose.
  Ne  prenez  pas  non plus la E2100 pour un clone de NE2100.  L'E2100 a
  une conception de DP8390 National Semiconductor a memoire partagee,  a
  peu  pres  similaire  a une WD8013 avec des lesions cerebrales, tandis
  que la NE2100 (et la NE1500) utilise une conception basee sur la  puce
  maitre-de-bus LANCE d'AMD.

  Vous  trouverez  un  pilote  pour  la  E2100  dans  le noyau standard.
  Toutefois,  au   vu   de   l'indisponibilite   des   informations   de
  programmation,   n'attendez  pas  des  corrections  de  bogues.   N'en
  utilisez pas a moins d'etre deja coince.

  Si vous avez l'intention d'utiliser  ce  pilote  sous  la  forme  d'un
  module  chargeable, vous devriez probablement consulter ``Utiliser les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.11.3.  E22**

  Statut -- Partiellement-supporte

  Si  l'on en croit les informations trouvees dans un bulletin technique
  de Cabletron, ces cartes utilisent le  jeu  de  puce  standard  PC-net
  d'AMD (section ``AMD PC-Net'') et devraient fonctionner avec le pilote
  generique lance.

  5.12.  Cogent

  Voici ou et comment les joindre:

          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
                           (Telephone entre 8h et 17h, heure de la cote
                            Pacifique)
          Fax (360) 378-2882
          Compuserve GO COGENT
          Bulletin Board Service (360) 378-5405
          Internet: support@cogentdata.com

  5.12.1.  EM100-ISA/EISA

  Statut -- Partiellement-supporte

  Ces cartes utilisent la puce SMC 91c100 et devraient fonctionner  avec
  le pilote SMC 91c92, mais cela reste a verifier.

  5.12.2.  Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964

  Statut -- Supporte

  Il  s'agit  encore  une  fois d'une implementation de la 21040 de DEC,
  dont on peut esperer qu'elle fonctionne correctement  avec  le  pilote
  21040 classique.

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

  Consultez ``DEC 21040'' pour plus d'information  sur  ces  cartes,  et
  l'etat d'avancement actuel du pilote.

  5.13.  Compaq

  Compaq  n'est  pas  vraiment dans le domaine de la conception et de la
  fabrication de  cartes  Ethernet,  mais  beaucoup  de  leurs  systemes
  comportent des controleurs Ethernet integres a la carte-mere.

  5.13.1.  Compaq Deskpro / Compaq XL (Embedded AMD Chip)

  Statut -- Supporte

  Des machines comme celles de la serie XL ont une puce PCI 79c97x d'AMD
  sur la  carte-mere  qui  peut  etre  utilisee  avec  le  pilote  LANCE
  standard.  Mais avant de pouvoir l'utiliser, vous devez faire quelques
  manipulations pour que le BIOS PCI se trouve a une place ou Linux peut
  le  voir.  Frank  Maas  a ete suffisamment sympa pour nous fournir les
  details:

  ``Le probleme avec cette machine Compaq est que le repertoire PCI  est
  charge  en memoire haute, a un endroit ou le noyau Linux ne pourra pas
  (n'ira pas) le chercher. Resultat: la carte n'est jamais  detectee  ni
  utilisable  (en  passant: la souris ne fonctionnera pas non plus).  La
  maniere de contourner le probleme (telle qu'elle est decrite en detail
  dans  http://www-c724.uibk.ac.at/XL/) est de charger MS-DOS, de lancer
  un petit pilote que Compaq a ecrit 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 deplacer le repertoire PCI a
  un endroit  ou  il  est  normalement  stocke  (et  ou  Linux  peut  le
  trouver).''

  Des  informations  plus  generales  sur  les  puces  AMD  se  trouvent
  dans ``AMD LANCE''.

  5.14.  Danpex

  5.14.1.  Danpex EN9400

  Statut -- Supporte

  Encore une autre carte basee sur la puce 21040 de DEC,  dont  on  sait
  qu'elle fonctionne correctement, et a un prix relativement faible.

  Consultez  ``DEC  21040''  pour  plus d'information sur ces cartes, et
  l'etat d'avancement actuel du pilote.

  5.15.  D-Link

  5.15.1.  DE-100, DE-200, DE-220-T, DE-250

  Statut -- Supporte

  Certaines des premieres cartes D-Link ne possedaient pas la  signature
  0x57 en PROM, mais le pilote ne2000 en a connaissance. Pour les cartes
  configurables par  logiciel,  vous  pouvez  obtenir  le  programme  de
  configuration  sur www.dlink.com.  Les cartes DE2** etaient celles les
  plus frequemment indiquees comme possedant les erreurs  de  difference
  d'adresse  de  transfert  avec les premieres versions de Linux.  Notez
  qu'il existe aussi des cartes chez  Digital  (DEC,  Digital  Equipment
  Corporation) nommees DE100 et DE200, mais la similitude s'arrete la.

  5.15.2.  DE-520

  Statut -- Supporte

  Il  s'agit d'une carte PCI qui utilise la version PCI de la puce LANCE
  d'AMD. Des informations sur la selection DMA et  la  numerotation  des
  puces se trouvent dans ``AMD LANCE''.

  Des  informations plus techniques sur les cartes Ethernet basee sur la
  puce LANCE d'AMD sont disponibles dans ``Notes sur l'AMD...''.

  5.15.3.  DE-530

  Statut -- Supporte

  Il s'agit d'une implementation generique de la puce PCI 21040 de  DEC,
  dont  on  sait  qu'elle  fonctionne  avec  le  pilote  generique 21040
  `tulip'.

  Consultez ``DEC 21040'' pour plus d'information  sur  ces  cartes,  et
  l'etat d'avancement actuel du pilote.

  5.15.4.  DE-600

  Statut -- Supporte

  Les   utilisateurs   de   portables   et   les  autres  personnes  qui
  souhaiteraient un moyen rapide de mettre leur ordinateur sur  Ethernet
  pourront  etre  interesses  par  ceci.   Le  pilote  est  inclus  dans
  l'arborescence du noyau par  defaut.   Bjorn  Ekwall  bj0rn@blox.se  a
  ecrit  le  pilote.   Attendez-vous a des taux de transfert de 180 Ko/s
  par le port parallele. Vous devriez lire le fichier README.DLINK  dans
  l'arborescence du noyau, aussi.

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

  Notez  que  le  nom  de  peripherique  que  vous passez a ifconfig est
  maintenant eth0 et non pas celui precedemment utilise, dl0.

  Si votre port parallele ne se trouve pas a l'adresse  standard  0x378,
  il  vous faudra recompiler le noyau.  Bjorn ecrit: ``Puisque le pilote
  de la DE-620 essaie de supprimer  la  moindre  microseconde  dans  les
  boucles,  j'ai  defini l'IRQ et l'adresse du port comme des constantes
  plutot que comme des variables.  Cela donne  une  vitesse  utilisable,
  mais  cela  signifie  aussi que vous ne pouvez pas changer ces valeurs
  depuis par exemple lilo; vous _devez_ recompiler...''  Notez aussi que
  certains  portables implementent le port parallele interne a l'adresse
  0x3bc, ce qui est l'endroit ou les ports paralleles  etaient/sont  sur
  les cartes monochromes.

  5.15.5.  DE-620

  Statut -- Supporte

  Meme  chose que pour la DE-600, avec seulement deux formats de sortie.
  Bjorn a ecrit un pilote pour ce  modele,  pour  les  versions  1.1  et
  superieures du noyau. Consultez les informations ci-dessus a propos de
  la DE-600.

  5.15.6.  DE-650

  Statut -- Partiellement-supporte

  Des gens utilisent cette carte PCMCIA depuis quelques temps deja  avec
  leur  portable.  Il  s'agit d'une conception simple basee sur le 8390,
  qui ressemble beaucoup a une NE2000.  La  carte  PCMCIA  `LinkSys'  et
  l'IC-Card  Ethernet  (disponibles  chez  Midwest Micro) sont supposees
  etre des clones de DE-650, de plus.  Notez qu'a l'heure  actuelle,  ce
  pilote  ne  fait pas partie du noyau standard, et que vous devrez donc
  appliquer quelques patchs.

  Consultez ``Support du PCMCIA''  dans  ce  document,  et  si  vous  le
  pouvez, jetez un coup d'oeil a:

       La       page      PCMCIA      de      Don      <http://ces-
       dis.gsfc.nasa.gov/linux/pcmcia.html>

  5.16.  DFI

  5.16.1.  DFINET-300 et DFINET-400

  Statut -- Supporte

  Ces cartes sont maintenant  detectees  (depuis  la  version  0.99pl15)
  grace  a  Eberhard  Moenkeberg  (emoenke@gwdg.de)  qui a note qu'elles
  utilisent `DFI' dans les trois premiers octets de la PROM, a la  place
  de 0x57 dans les octets 14 et 15, ce que font toutes les autres cartes
  NE1000 et NE2000. (La 300 est un  semblant  de  clone  8  bits  de  la
  NE1000, et la 400 est un semblant de clone NE2000.)

  5.17.  Digital / DEC

  5.17.1.  DEPCA, DE100/1, DE200/1/2, DE210, DE422

  Statut -- Supporte

  Depuis  la version 1.0 de Linux, un pilote est inclus en standard pour
  ces cartes. Il a ete ecrit par David C. Davies.  De  la  documentation
  est  incluse  dans  le  fichier source depca.c, qui comprend aussi des
  informations sur la facon d'utiliser plus d'une de ces cartes dans une
  machine.   Notez  que  la  DE422  est  une carte EISA. Ces cartes sont
  toutes basees sur la puce LANCE d'AMD. Consultez  ``AMD  LANCE''  pour
  plus  d'informations.   Un maximum de deux des cartes ISA peuvent etre
  utilisees, parce que leurs adresses d'E/S  de  base  ne  peuvent  etre
  fixees  qu'a  0x300  ou  0x200.  Si vous avez l'intention de le faire,
  veuillez lire les notes dans le fichier  source  du  pilote,  depca.c,
  dans l'arborescence du noyau standard.

  Ce  pilote  fonctionnera aussi sur les machines a processeur Alpha, et
  il  comprend  differents  ioctl()  avec  lesquels  l'utilisateur  peut
  s'amuser.

  5.17.2.  Digital EtherWorks 3 (DE203, DE204, DE205)

  Statut -- Supporte

  Ce pilote est inclus dans les versions 1.1.62 et superieures du noyau.
  Ces cartes utilisent une puce proprietaire de DEC, par opposition a la
  puce  LANCE  utilisee  dans les cartes anterieures comme la DE200. Ces
  cartes peuvent fonctionner en memoire partagee ou en E/S  programmees,
  bien que vous ayez un gain en performance de 50 pourcents en utilisant
  le mode PIO (E/S programmees). La taille de la memoire  partagee  peut
  etre  reglee  a 2 Ko, 32 Ko, ou 64 Ko, mais seules les valeurs 2 et 32
  ont ete testees avec ce pilote.  David dit que les  performances  sont
  virtuellement  les  memes  entre  le  mode 2 Ko et le mode 32 Ko. Plus
  d'informations  (y  compris  l'utilisation  du  pilote  comme   module
  chargeable)  figurent  en  tete  du fichier source du pilote, ewrk3.c,
  ainsi que dans le fichier README.ewrk3. Ces deux fichiers se  trouvent
  dans la distribution standard du noyau.

  Le  pilote  standard  a  un  nombre  d'appels ioctl() interessants qui
  peuvent etre utilises pour lire ou effacer les  statistiques  sur  les
  paquets,   lire/ecrire  l'EEPROM,  changer  l'adresse  materielle,  et
  d'autre choses du meme genre. Les bidouilleurs pourront lire  le  code
  source pour plus d'information a ce sujet.

  David  a  aussi  ecrit un utilitaire de configuration pour cette carte
  (outre les lignes du programme DOS NICSETUP.EXE)  ainsi  que  d'autres
  outils. Vous pouvez les trouver sur sunsite.unc.edu dans le repertoire
  /pub/Linux/system/Network/management   --    cherchez    un    fichier
  ewrk3tools-X.XX.tar.gz.

  (NDT: Le lecteur francais aura bien entendu tout interet a utiliser un
  site miroir, plus rapide. Par exemple:

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

  La prochaine version de ce pilote (la 0.40) comprendra le  support  du
  processeur  Alpha comme depca.c et est disponible maintenant aupres de
  David si vous le lui demandez.

  5.17.3.  DE425 (EISA), DE434, DE435, DE500

  Statut -- Supporte

  Ces cartes sont basees sur la puce  21040  mentionnee  plus  bas.   Ce
  pilote est inclus dans les versions 1.1.86 et superieures du noyau, et
  il a aussi ete ecrit par David C. Davies de DEC.  Il est  certain  que
  c'est  agreable d'avoir le support de quelqu'un qui est dans la place.
  La DE500 utilise les  puces  21140  plus  recentes  pour  fournir  des
  connexions  Ethernet  10/100Mb/s.   Lisez  la section sur la 21040 ci-
  dessous pour plus d'informations.

  Notez que pour la  version  1.1.91,  David  a  ajoute  une  option  de
  compilation  qui  permet aux cartes non concues par DEC de fonctionner
  avec ce pilote. Jetez un coup d'oeil a README.de4x5 pour les  details.

  Toutes  les  cartes  Digital  realiseront  la detection automatique du
  media (a l'exception, temporaire, de la DE500 a cause d'un probleme de
  patente).

  Ce  pilote  est aussi pret a fonctionner avec les processeurs Alpha et
  accepte d'etre charge comme module. Les utilisateurs  peuvent  acceder
  aux  fonctionnalites internes du pilotes par des appels ioctl() - voir
  l'outil ewrk3 et les sources de4x5.c  pour  des  informations  sur  la
  facon de proceder.

  5.17.4.  DEC 21040, 21041, 2114x, Tulip

  Statut -- Supporte

  La  21040 de DEC est une solution Ethernet en une seule puce maitre de
  bus proposee par Digital, similaire a la puce PCnet  d'AMD.  La  21040
  est   specifiquement  concue  pour  l'architecture  a  bus  PCI.   Les
  nouvelles cartes PCI EtherPower de SMC utilisent cette puce.

  Vous avez le choix entre deux pilotes pour les cartes basees sur cette
  puce. Vous pouvez utiliser le pilote de la DE425 dont nous avons parle
  plus haut, et le pilote generique pour 21040 que Donald a ecrit.

  Attention: Meme si votre carte est basee sur cette puce,  les  pilotes
  peuvent  ne  pas  fonctionner pour vous.  David C.  Davies ecrit: ``Il
  n'y aucune garantie que SOIT tulip.c SOIT de4x5.c  feront  fonctionner
  une  autre  carte  basee sur le DC2114x que celles pour lesquelles ils
  ont ete ecrit.   POURQUOI??   demandez-vous.  Parce  qu'il  existe  un
  registre,  le  Registre  a  Usage  General  (General Purpose Register,
  CSR12) qui, primo,  dans  la  DC21140A  est  programmable  par  chaque
  fabricant  et  ils  le  font tous d'une facon differente, et, secundo,
  dans la DC21142/3 est maintenant un registre de  controle  SIA  (a  la
  DC21041).  La  seule  petite  lueur  d'espoir  est  que nous puissions
  decoder la SROM pour aider la configuration du pilote. Et  encore,  ce
  n'est  pas  une  solution garantie puisque certains constructeurs (par
  exemple  la  carte  9332  de  SMC)  ne  suivent  pas  le   format   de
  programmation SROM recommande par Digital Semiconductor.''

  En  termes non-techniques, cela signifie que si vous n'etes pas sur(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 a votre revendeur avant d'avoir a la payer.

  La puce 21041, mise-a-jour, se trouve aussi a la place de la 21040 sur
  la  plupart  des  recentes  cartes  EtherPower  de  SMC.  La 21140 est
  destinee au support du 100Base-? et fonctionne avec les pilotes  Linux
  de  la  puce  21040.   Pour utiliser le pilote de4x5 de David avec des
  cartes non concues par DEC, lisez le  fichier  README.de4x5  pour  les
  details.

  Donald  a  utilise des cartes EtherPower-10/100 de SMC pour developper
  le  pilote  `tulip'.  Notez  que  le  pilote  qui   se   trouve   dans
  l'arborescence  du  noyau  a  l'heure actuelle n'est pas la version la
  plus a jour. Si vous avez des problemes avec ce pilote,  vous  devriez
  recuperer la derniere version sur le site FTP/WWW de Donald.

  Pilote                   Tulip                  <http://ces-
  dis.gsfc.nasa.gov/linux/drivers/tulip.html>

  L'URL  ci-dessus  contient  aussi  une  liste  (non  exhaustive)   des
  differentes cartes/constructeurs qui utilisent la puce 21040.

  Notez  egalement  que  le  pilote  tulip est encore considere comme un
  pilote alpha (voir ``Pilotes alpha'') actuellement, et qu'il doit donc
  etre   traite   comme   tel.   Pour  l'utiliser,  vous  devrez  editer
  arch/i386/config.in et enlever les commentaires qui entourent la ligne
  sur le support CONFIG_DEC_ELCP.

  Donald  a  meme  cree  une liste de diffusion pour les annonces sur le
  support du pilote tulip, etc. Pour vous y abonner,  vous  n'avez  qu'a
  taper:

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

  5.18.  Farallon

  Farallon  vend  des  adaptateurs  et  des  transceivers EtherWave.  Ce
  peripherique  permet  de  mettre  en  serie  plusieurs   peripheriques
  10baseT.

  5.18.1.  Etherwave de Farallon

  Statut -- Supporte

  On rapporte qu'il s'agit d'un clone de 3c509 qui inclut le transceiver
  EtherWave. Des gens les ont utilises avec succes sous  Linux  avec  la
  version  actuelle  du  pilote  3c509.  C'est  bien  trop cher pour une
  utilisation generalisee, mais c'est une  bonne  option  pour  des  cas
  particuliers.   Les  prix chez Hublet demarrent a 125 dollars (environ
  750 francs), et l'EtherWave ajoute entre 75 et 100 dollars (450 a  600
  francs)  au  prix de la carte -- c'est bien si vous avez tire un cable
  trop court, mais pas si  vous  avez  deux  reseaux  qui  tombent  trop
  courts.

  5.19.  Hewlett Packard

  Les  cartes 272** utilisent des E/S programmees, similaires aux cartes
  NE*000, mais le port de transferts de donnees peut etre `eteint' quand
  vous  n'y accedez pas, ce qui evite les problemes avec les pilotes qui
  realisent une detection automatique.

  Merci a Glenn Talbott  d'avoir  aide  a  eclaircir  la  confusion  qui
  regnait  dans  cette section en ce qui concerne les numeros de version
  des materiels HP.

  5.19.1.  27245A

  Statut -- Supporte

  Carte 8 bits 10BaseT basee sur le 8390, non  recommandee  pour  toutes
  les  raisons  des 8 bits. Elle a ete re-concue  il y a quelques annees
  pour augmenter l'integration, ce qui a cause des changements dans  les
  durees  d'initialisation,  qui  affectent les programmes de test, mais
  pas les pilotes reseau. (La nouvelle carte n'est pas `prete' aussi tot
  que  l'ancienne  apres  etre entree ou sortie du mode en boucle locale
  (loopback)).

  Si vous avez l'intention d'utiliser  ce  pilote  sous  la  forme  d'un
  module  chargeable, vous devriez probablement consulter ``Utiliser les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.19.2.  HP PC Lan+ (27247, 27252A)

  Statut -- Supporte

  La HP PC Lan+ est differente de la carte HP PC Lan standard. Ce pilote
  a ete ajoute a la liste des pilotes du noyau standard pendant le cycle
  de  developpement des version 1.1.x. Il peut etre utilise soit en mode
  PIO (E/S programmees) comme une ne2000, ou en  mode  memoire  partagee
  comme une wd8013.

  La  47B  est  une carte 16 bits 10BaseT avec AUI a base de 8390, et la
  52A est une carte 16 bits ThinLAN avec AUI a base de 8390.  Ces cartes
  comportent  32  Ko  de  memoire  vive  embarquee  pour  le  tampon  de
  reception/transmission des paquets au lieu des  16  Ko  habituels,  et
  elles offrent toutes les deux une fonction de detection automatique du
  connecteur reseau.

  Si vous avez l'intention d'utiliser  ce  pilote  sous  la  forme  d'un
  module  chargeable, vous devriez probablement consulter ``Utiliser les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.19.3.  HP-J2405A

  Statut -- Supporte

  Ces  cartes  sont  meilleur  marche, et legerement plus rapides que la
  27247/27252A, mais il leur manque certaines fonctionnalites, comme  la
  connectivite  AUI  ou  ThinLAN  (10Base2),  et un support pour PROM de
  demarrage (boot PROM). C'est une conception  plutot  generique  de  la
  LANCE,  mais  une  decision mineure de conception la rend incompatible
  avec un pilote generique `NE2100'. Un support special pour cette carte
  (y  compris la lecture du canal DMA sur la carte) est inclus grace aux
  informations fournies par Glenn Talbott de chez HP.

  Plus d'informations techniques sur les cartes basee sur la puce AMD se
  trouvent dans ``Notes sur AMD...''.

  5.19.4.  Carte Ethernet embarquee de l'HP-Vectra

  Statut -- Supporte

  L'HP-Vectra  possede  une  puce  PCnet  d'AMD  sur sa carte-mere.  Les
  premieres versions du noyau la detectaient comme  etant  la  HP-J2405A
  mais  c'est  incorrect, car le Vectra ne renvoie pas l'IRQ et le canal
  DMA comme la J2405A.  Recuperez un noyau plus recent  que  la  version
  1.1.53 pour eviter ce probleme.

  La selection du DMA et des informations sur la numerotation de la puce
  se trouvent dans ``AMD LANCE''.
  Plus d'informations techniques sur les cartes basees sur la  puce  AMD
  se trouvent dans ``Notes sur AMD...''.

  5.19.5.  Cartes HP 10/100 VG Any Lan (27248B, J2573, J2577, J2585)

  Statut -- Supporte

  Ce pilote a ete fourni par Jaroslav Kysela (perex@pf.jcu.cz) pour  les
  premiers  noyaux 1.3.x. Eu egard a la nouveaute du pilote et au nombre
  relativement peu important de cartes VG en utilisation, il y a eu  peu
  de retour d'information sur ce pilote.

  Donald  a  aussi  ecrit  un  pilote  pour ces cartes. Contrairement au
  precedent, il ne figure pas presentement dans l'arborescence  standard
  du  noyau.  Consultez  l'URL  suivante pour plus d'informations sur le
  travail 100VG de Donald.

       La    page     100VG     Donald's     100VG     <http://ces-
       dis.gsfc.nasa.gov/linux/drivers/100vg.html>

  5.20.  IBM / International Business Machines

  5.20.1.  IBM Thinkpad 300

  Statut -- Supporte

  Celui-ci  est  compatible  avec le Z-note de Zenith, base sur une puce
  Intel. Voir ``Z-note''.

  Ce site est suppose avoir une base de  donnees  exhaustive  de  choses
  utiles  pour les versions recentes du Thinkpad. Je ne l'ai pas verifie
  moi-meme.

       Thinkpad-info          <http://peipa.essex.ac.uk/html/linux-
       thinkpad.html>

  Pour  ceux d'entre vous qui n'ont pas de navigateur WWW a portee de la
  main, essayez peipa.essex.ac.uk:/pub/tp750/.

  5.20.2.  Adaptateur `Credit Card' pour Ethernet d'IBM IBM Credit  Card
  Adaptor for Ethernet -

  Statut -- Partiellement-supporte

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

  Consultez ``Support PCMCIA'' dans ce document, et si  vous  le  pouvez
  jetez un coup d'oeil a:

       La      page      PCMCIA      de     Donald     <http://ces-
       dis.gsfc.nasa.gov/linux/pcmcia.html>

  5.20.3.  IBM Token Ring

  Statut -- Partiellement-supporte

  Le support de Token Ring necessite plus que la  simple  ecriture  d'un
  pilote, il necessite d'ecrire les routines pour le routage source pour
  Token Ring. C'est le routage par la source qui sera  le  plus  long  a
  ecrire.

  Peter De Schrijver a depense de son temps sur Token Ring recemment, et
  a travaille avec des cartes Token Ring ISA et MCA d'IBM.

  Le code Token Ring actuel a ete inclus dans les  premiers  noyaux  des
  series 1.3.x.

  Peter  dit qu'il a ete teste a l'origine avec une carte Token Ring MCA
  16/4 Megabit, mais qu'il  devrait  fonctionner  avec  d'autres  cartes
  basees sur Tropic.

  5.21.  Cartes Ethernet ICL

  5.21.1.  ICL EtherTeam 16i/32

  Statut -- Supporte

  Mika  Kuoppala  (miku@pupu.elt.icl.fi)  a  ecrit  ce pilote, qui a ete
  inclus dans les premiers noyaux 1.3.4x. Cette carte  utilise  la  puce
  MB86965 de Fujitsu qui est aussi utilisee dans les cartes AT1700.

  5.22.  Cartes Ethernet Intel

  5.22.1.  Ether Express

  Statut -- Supporte

  Cette carte utilise l'Intel i82586. (Surprenant, hein?)  Les premieres
  versions de ce pilote (dans les noyaux 1.2) etaient classees en  cours
  de  test `alpha', parce qu'il ne fonctionnait pas correctement pour la
  plupart des  gens.   Le  pilote  des  versions  2.0  du  noyau  semble
  fonctionner bien mieux pour ceux qui l'ont essaye. Les commentaires au
  debut du fichier source donnent la liste  de  certains  des  problemes
  associes a ces cartes.

  D'autres  informations  techniques sont aussi disponibles sur l'i82586
  dans ``Programmation des puces Intel'' ainsi que dans le  code  source
  du pilote eexpress.c.  N'ayez pas peur de le lire. ;-)

  5.22.2.  Ether Express PRO/10

  Statut -- Supporte

  Bao  Chau  Ha a ecrit un pilote pour ces cartes, qui a ete inclus dans
  les premiers noyaux 1.3.x. Il peut aussi fonctionner avec certains des
  systemes  Ethernet  integres  de  Compaq,  qui  sont bases sur la puce
  i82595.

  5.22.3.  Ether Express PRO/10 PCI (EISA)

  Statut -- Partiellement-supporte

  John Stalba (stalba@ultranet.com) a ecrit un pilote  pour  la  version
  PCI. Ces cartes utilisent la puce d'interface PCI PLX9036 avec la puce
  controleur-reseau i82596 d'Intel. Si  votre  carte  comporte  la  puce
  i82557,  alors  vous  n'avez  pas  cette  carte,  mais au contraire la
  version ``+'' dont il  est  question  ci-dessous,  qui  necessite  par
  consequent le pilote EEPro100 plutot que celui-ci.

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

       Pilote              EEPro10               <http://www.ultra-
       net.com/~stalba/eep10pci.html>

  Si vous avez la carte EISA, vous devrez certainement bidouiller un peu
  le  pilote  pour  prendre  en  compte  les  differents  mecanismes  de
  detection (PCI ou EISA) qui sont utilises dans chaque cas.

  5.22.4.  Ether Express PRO/10+

  Statut -- Supporte

  Un petit changement dans le nom (par rapport a la precedente) mais une
  conception differente. Cette carte utilise  la  puce  i82557,  et  par
  consequent  necessite  le  pilote  eepro100  dont  il est question ci-
  dessous.

  5.22.5.  Ether Express PRO 10/100B

  Statut -- Supporte

  Un pilote pour cette carte est inclus dans les sources du  noyau  2.0,
  vous  n'avez  donc  plus besoin de vous le procurer separement.  Notez
  que ce pilote ne fonctionnera pas avec les cartes 100A qui  sont  plus
  anciennes.

  Pour les mises-a-jour du pilote et / ou des informations, consultez:

       Page          de          l'EEPro-100B          <http://ces-
       dis.gsfc.nasa.gov/linux/drivers/eepro100.html>

  Apparemment Donald a ete oblige de signer un accord de confidentialite
  qui  etablit  qu'il  pouvait  en  fait  communiquer  le code-source du
  pilote! Comment prendre une telle preuve de betise de la part d'Intel?

  Ce  pilote  sera  inclus  dans l'arborescence des versions 2.1 un jour
  dans le futur. Il  existe  aussi  une  liste  de  diffusion  pour  les
  annonces  a  propos  du pilote. Pour vous y abonner, il vous suffit de
  faire:

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

  5.23.  LinkSys

  LinkSys  produit  tout  un  tas  de clones NE2000 differents, certains
  etant de simple cartes ISA, d'autres des cartes ISA `plug and play' et
  memes  des  clones  de  NE2000  PCI  bases  sur l'un des jeux de puces
  NE2000-PCI supporte. Il existe tout simplement trop  de  modeles  pour
  pouvoir tous les lister ici.

  Linux est mentionne dans leur page WWW de support. Consultez:

       http://www.linksys.com/support/solution/nos/linux.htm

  si  vous avez des problemes a utiliser une de leurs cartes avec Linux.

  5.23.1.  Cartes LinkSys Etherfast 10/100.

  Statut -- Supporte

  Attention avec ces cartes - apparemment certaines utilisent le jeu  de
  puces  de  DEC,  et  d'autres  un  jeu de puces PNIC proprietaire. Les
  pilotes pour les puces DEC ne fonctionneront pas avec les cartes PNIC.
  Merci a Blake Wright d'avoir fourni ces informations utiles.

  5.23.2.  LinkSys Pocket Ethernet Adapter Plus (PEAEPP)

  Statut -- Supporte

  On  suppose  qu'il  s'agit d'un clone du DE-620, et il parait que cela
  fonctionne bien  avec  ce  pilote.   Consultez  ``DE-620''  pour  plus
  d'information.

  5.23.3.  Adaptateur LinkSys PCMCIA

  Statut -- Supporte

  On  suppose  qu'il  s'agit  d'un DE-650 avec une etiquette differente.
  Consultez ``DE-650'' pour plus d'information.

  5.24.  Microdyne

  5.24.1.  Microdyne Exos 205T

  Statut -- Partiellement-supporte

  Une   autre    carte    basee    sur    l'i82586.    Dirk    Niggemann
  dabn100@hermes.cam.ac.uk  a  ecrit  un  pilote  qu'il  classe  dans la
  categorie ``pre-alpha'' et dont il  aimerait  bien  que  les  gens  le
  testent. Ecrivez-lui pour plus de details.

  5.25.  Mylex

  Mylex peut etre joint aux numeros suivants, au cas ou quelqu'un aurait
  envie de leur demander quelque chose.
          MYLEX CORPORATION, Fremont
          Ventes: 800-77-MYLEX, (510) 796-6100
          FAX:    (510) 745-8016.

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

  5.25.1.  Mylex LNE390A, LNE390B

  Statut -- Partiellement-supporte

  Ces cartes  EISA  plutot  anciennes  utilisent  une  implementation  a
  memoire  partagee  similaire aux wd80x3. Si vous etes interesse(e) par
  le test d'un pilote pour cette carte, contactez-moi (pg).

  5.25.2.  Mylex LNP101

  Statut -- Supporte

  Il s'agit d'une carte PCI basee sur la puce 21040  de  DEC.   On  peut
  selectionner  les  ports  10BaseT, 10Base2 ou 10Base5 (AUI).  La carte
  LNP101 a ete testee et elle fonctionne avec le pilote 21040 generique.

  Consultez  la  section  sur  la  puce  21040 (``DEC 21040'') pour plus
  d'information.

  5.25.3.  Mylex LNP104

  Statut -- Partiellement-supporte

  La LNP104 utilise la puce 21050  de  DEC  pour  fournir  quatre  ports
  10BaseT  independants. Elle devrait fonctionner avec les pilotes 21040
  recents qui savent partager les IRQ,  mais  personne  a  ce  jour  n'a
  indique l'avoir essayee (autant que je sache).

  5.26.  Ethernet chez Novell: NExxxx et les clones associes.

  Le prefixe  `NE'  vient  de  `Novell  Ethernet'.  Novell  a  suivi  la
  conception  la moins chere decrite dans les documentations de National
  Semiconductor, et a vendu les droits de fabrication a Eagle (s'en  est
  debarasse?),  juste  pour  pouvoir  mettre  sur  le  marche des cartes
  Ethernet  a  prix  raisonnables.  (La  maintenant  omnipresente  carte
  NE2000.)

  5.26.1.  NE1000, NE2000

  Statut -- Supporte

  NOTE: Si vous utilisez un noyau plus ancien que la version 1.2.9, nous
  vous recommandons fortement de le mettre a jour vers une version  plus
  recente.  Des corrections importantes ont ete apportees au pilote dans
  la 1.2.7, et un autre correctif important a ete  apporte  aux  couches
  superieures  (dev.c)  dans  la 1.2.9. Les deux problemes corriges dans
  ces  versions  peuvent  faire  qu'une  carte  ne2000  bloquera   votre
  ordinateur.

  ``NE2000''  est  maintenant  un  nom  generique  pour  une  conception
  rachitique basee sur la  puce  8390  de  National  Semiconductor.  Ces
  cartes  utilisent  des E/S programmees plutot que la memoire partagee,
  ce qui amene  une  installation  plus  facile  mais  des  performances
  legerement  moins  bonnes  et  quelques  problemes.  De  nouveau,  les
  economies faites en utilisant une NE1000 (8 bits) plutot qu'une NE2000
  ne  sont  garanties  que  si vous esperez une utilisation legere.  Des
  problemes peuvent survenir avec des clones NE2000 bas de gamme.   Vous
  devriez  lire  ``Problemes avec...'', ainsi que ``Clones NE2000 bas de
  gamme''.

  Quelques clones NE2000 recemment apparus utilisent la puce `AT/LANTic'
  83905  de National Semiconductor, qui offre un mode a memoire partagee
  similaire a la wd8013 et une configuration logicielle via  EEPROM.  Le
  mode  a  memoire  partagee donnera moins de charge processeur (et sera
  donc plus efficace) que le mode a E/S programmees.

  En general ce n'est pas une bonne idee de placer  un  clone  NE2000  a
  l'adresse  d'E/S  0x300  parce  que  pratiquement  tous les pilotes de
  peripheriques testent cette adresse  au  demarrage.   Certains  clones
  NE2000  bas  de  gamme  n'acceptent  pas  tellement d'etre titilles au
  mauvais endroit, et ils repondront en bloquant  votre  machine.  0x320
  est  egalement  une  mauvaise  idee  car  les  pilotes  SCSI testent a
  l'adresse 0x330.

  Donald a ecrit un programme de diagnostic  pour  NE2000  (ne2k.c)  qui
  fonctionne  pour  toutes les cartes NE2000.  Consultez ``Programmes de
  diagnostic'' pour plus d'information.

  Si vous avez l'intention d'utiliser  ce  pilote  sous  la  forme  d'un
  module  chargeable, vous devriez probablement consulter ``Utiliser les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.26.2.  NE2000-PCI (RealTek/Winbond/Compex)

  Statut -- Supporte

  Oui,  croyez  le ou pas, des gens fabriquent des cartes PCI basees sur
  le concept d'interface vieux de dix ans de la  NE2000.   Actuellement,
  presque  toutes  ces cartes sont basees sur la puce 8029 de RealTek ou
  la puce 89c940 de Winbond.  Les cartes  Compex,  KTI,  VIA  et  Netvin
  utilisent   apparemment   aussi   ces   puces,   mais   possedent   un
  identificateur PCI different.  Le noyau Linux 2.0.33  est  capable  de
  detecter  automatiquement  toutes  ces  cartes et de les utiliser. (Si
  vous utilisez un noyau version 2.0.30 ou plus ancien, vous devriez  le
  mettre a jour pour vous assurer que votre carte sera detectee.)

  Notez  que  vous  devez  repondre  `Y'  a  l'option  `Other ISA cards'
  (`Autres cartes ISA?') lorsque vous executez make config car  en  fait
  vous  utilisez  le meme pilote NE2000 que celui des cartes ISA.  (Cela
  devrait vous donner l'idee que ces cartes ne sont en aucun point aussi
  intelligentes  que,  disons, une carte a base de DEC 21040...) Dans le
  futur, un pilote NE2000 uniquement pour le PCI sera  inclus  dans  les
  sources   du  noyau  pour  ces  cartes.   Le  pilote  est  visiblement
  disponible pour test a:

       http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html

  Certaines cartes-meres recents n'activent pas toutes les cartes PCi  a
  l'allumage  de  la  machine, ce qui entraine generalement que la carte
  est detectee, mais qu'elle echoue lors du test. Le code  pour  activer
  de   telles   cartes   devrait  etre  ajoute  au  pilote  ne.c  de  la
  version 2.0.34, base sur ce qui se trouve dans le pilote limite au PCI
  que nous avons mentionne.

  Si  vous  avez  une  carte  PCI  NE2000  qui n'est pas detectee par le
  pilote, veuillez contacter le responsable du  pilote  NE2000  qui  est
  indique  dans /usr/src/linux/MAINTAINERS, en lui indiquant le resultat
  d'un cat /proc/pci et de dmesg afin que le support  pour  votre  carte
  puisse etre ajoute dans le pilote.

  5.26.3.  NE-10/100

  Statut -- Non-supporte

  Il  s'agit  de  cartes  ISA  100Mb/s  basees  sur les puces DP83800 et
  DP83840 de National Semiconductor. Il n'y a actuellement aucun support
  logiciel, et personne n'a indique qu'il travaille a un pilote.

  5.26.4.  NE1500, NE2100

  Statut -- Supporte

  Ces  cartes  utilisent  la  puce  7990  LANCE originelle d'AMD et sont
  supportees en utilisant le pilote Linux lance. Les clones NE2100  plus
  recents utilisent la puce mise-a-jour PCnet/ISA d'AMD.

  Des versions plus anciennes du pilote lance avaient des problemes pour
  obtenir  la  ligne  d'IRQ  via  l'affectation  automatique  d'IRQ  des
  cartes   7990  originelles  de  Novell/Eagle.  Heureusement  cela  est
  maintenant resolu. Si ce n'est pas le cas, specifiez l'IRQ  via  LILO,
  et indiquez-nous si cela pose encore des problemes.

  La selection du DMA et des informations sur la numerotation de la puce
  se trouvent dans ``AMD LANCE''.

  Des informations plus techniques sur les cartes  Ethernet  basees  sur
  l'AMD LANCE sont disponibles dans ``Notes sur l'AMD...''.

  5.26.5.  NE3200

  Statut -- Non-supporte

  Cette  carte  utilise  un petit 80186 qui tourne doucement a 8 MHz, et
  vous auriez donc tout interet a utiliser un clone NE2000 pas cher a la
  place.  Meme  si  un  pilote  etait disponible, la carte NE2000 serait
  certainement encore la plus rapide.

  5.26.6.  NE5500

  Statut -- Supporte

  Ce sont juste des cartes basees sur la puce PCnet-PCI  ('970A)  d'AMD.
  Plus  d'informations  sur les cartes a base de LANCE/PCnet se trouvent
  dans ``AMD LANCE''.

  5.27.  Proteon

  5.27.1.  Proteon P1370-EA

  Statut -- Supporte

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

  5.27.2.  Proteon P1670-EA

  Statut -- Supporte

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

  Consultez la section sur la  puce  21040  (``DEC  21040'')  pour  plus
  d'information sur le pilote.

  5.28.  Pure Data

  5.28.1.  PDUC8028, PDI8023

  Statut -- Supporte

  Les  series  PDUC8028  et  PDI8023  de  cartes  PureData  fonctionnent
  apparemment correctement, grace au  code  de  detection  special  qu'a
  fourni  Mike  Jagdis  jaggy@purplet.demon.co.uk.   Le support pour ces
  cartes est integre dans le pilote Western Digital (WD).

  5.29.  Racal-Interlan

  Racal-Interlan peut etre joint via  le  WWW  a  www.interlan.com.   Je
  crois  qu'ils  etaient  connus  sous  le  nom  de MiCom-Interlan a une
  epoque.

  5.29.1.  ES3210

  Statut -- Partiellement-supporte

  Il s'agit d'une carte EISA a memoire partagee basee sur le  8390.   Un
  pilote  experimental  pour  les versions 2.0 est disponible (aupres de
  moi, pg). On indique qu'il fonctionne correctement, mais la  detection
  de  l'IRQ  EISA  et  de  l'adresse  de  memoire partagee parait ne pas
  fonctionner avec (au moins) les premieres  revisions  de  ces  cartes.
  Dans  ce  cas,  vous  pouvez  les  fournir  au demarrage; par exemple,
  ether=5,0,0xd0000,eth0 pour l'IRQ 5 et la memoire partagee en 0xd0000.
  L'adresse  de base d'E/S est detectee automatiquement et une valeur de
  zero doit donc etre utilisee.

  Ce pilote apparaitra prochainement dans les noyaux 2.1.

  5.29.2.  NI5010

  Statut -- Partiellement-supporte

  Ce pilote, par Jan-Pascal  van  Best  (jvbest@qv3pluto.leidenuniv.nl),
  supporte  les  vieilles  cartes 8 bits de MiCom-Interlan.  Vous pouvez
  obtenir le pilote depuis:

       Pilote            NI5010             <http://qv3pluto.leide-
       nuniv.nl/jvbest/ni5010/ni5010.html>

  Jan-Pascal  a  recu  peu  de  retour  d'information  sur  ce pilote et
  apprecierait si vous lui envoyiez une note disant s'il  fonctionne  ou
  pas.

  5.29.3.  NI5210

  Statut -- Partiellement-supporte

  Michael Hipp a ecrit un pilote pour cette carte. Il est inclus dans le
  noyau standard en tant que pilote en phase `alpha'.  Michael  aimerait
  recevoir  des informations des utilisateurs qui possedent cette carte.
  Consultez ``Les pilotes `Alpha''' pour  des  informations  importantes
  sur  l'utilisation  des pilotes Ethernet en phase de test `alpha' avec
  Linux.

  Michael dit que ``le bus systeme interne semble etre  lent.   On  perd
  donc  souvent  des  paquets a cause de surcharges lors d'une reception
  depuis une machine rapide.''

  Cette carte utilise aussi  l'une  des  puces  Intel.   Consultez  ``La
  programmation des puces Intel'' pour plus d'informations techniques.

  5.29.4.  NI6510 (not EB)

  Statut -- Partiellement-supporte

  Il  existe  egalement  un  pilote  pour  la  NI6510 (basee sur la puce
  LANCE), et il a aussi ete ecrit par Michael Hipp.  La aussi, il s'agit
  d'un  pilote  `alpha'. Pour une raison inconnue, cette carte n'est pas
  compatible avec le pilote LANCE generique.   Consultez  ``Les  pilotes
  `Alpha'''  pour  des  informations  importantes  sur l'utilisation des
  pilotes Ethernet en phase de test `alpha' avec Linux.

  5.29.5.  EtherBlaster (aka NI6510EB)

  Statut -- Supporte

  Depuis le noyau 1.3.23, le pilote LANCE  generique  comprend  un  test
  supplementaire pour la signature 0x52, 0x44 specifique de la NI6510EB.
  D'autres ont indique que cette signature n'est pas la meme pour toutes
  les  cartes  NI6510EB,  ce  qui  peut  amener le pilote lance a ne pas
  detecter votre carte. Si cela vous  arrive,  vous  pouvez  changer  la
  procedure  de detection (aux environs de la ligne 322 de lance.c) pour
  qu'elle printk() (affiche) quelles sont les valeurs pour votre  carte,
  puis utiliser ces valeurs a la place du 0x52, 0x44 donne par defaut.

  Les  cartes  devraient  probablement  etre  placees  en  mode  `hautes
  performances' et non pas dans le mode compatible-NI6510  lorsque  l'on
  utilise le pilote lance.

  5.30.  Sager

  5.30.1.  Sager NP943

  Statut -- Partiellement-supporte

  Il  s'agit  juste  d'un  clone  de 3c501, avec un prefixe de S.A. PROM
  different. Je pense qu'elle est aussi tapee du ciboulot que  la  vraie
  3c501,  en  passant.  Les  noyaux  1.1.53  et  superieurs verifient la
  presence de l'identificateur de la NP943 puis la  traitent  comme  une
  3c501  apres  ca.  Consultez  ``3Com  3c501''  pour  toutes les bonnes
  raisons qui font que vous ne devriez vraiment pas avoir  ne  serait-ce
  que l'intention d'utiliser une de ces cartes.

  5.31.  Schneider & Koch

  5.31.1.  SK G16

  Statut -- Supporte

  Ce  pilote  a  ete  inclus  dans les noyaux des versions 1.1, et a ete
  ecrit par PJD Weichmann et SWS Bern. Il se trouve que la  SK  G16  est
  similaire  a  la  NI6510, en ce sens qu'elle est basee sur la premiere
  edition de la puce LANCE (la 7990). Une  fois  de  plus,  cette  carte
  semble ne pas fonctionner avec le pilote LANCE generique.

  5.32.  SEEQ

  5.32.1.  SEEQ 8005

  Statut -- Supporte

  Ce  pilote a ete inclus dans les premiers noyaux 1.3.x, et a ete ecrit
  par Hamish Coleman. Peu d'informations sur la carte figurent  dans  le
  pilote,  et  donc  peu d'informations ont ete mises ici.  Si vous avez
  une question, vous  aurez  probablement  tout  interet  a  envoyer  un
  message a hamish@zot.apana.org.au.

  5.33.  SMC (Standard Microsystems Corp.)

  Veuillez   consulter   ``Western   Digital''   pour  les  informations
  concernant les cartes SMC. (SMC a achete la division cartes reseau  de
  Western Digital il y a deja quelques temps.)

  5.34.  Thomas Conrad

  5.34.1.  Thomas Conrad TC-5048

  Encore une autre carte PCI basee sur la puce 21040 de DEC.

  Consultez  la  section  sur  la  puce  21040 (``DEC 21040'') pour plus
  d'informations.

  5.35.  Western Digital / SMC

  La partie Ethernet de Western Digital a  ete  achetee  par  SMC.   Une
  erreur  classique  que  font  les  gens est de croire que la carte SMC
  Elite Ultra, relativement recente, est la meme que  les  modeles  deja
  plus  anciens  SMC  Elite16  --  ce  n'est  pas le cas.  Elles ont des
  pilotes distincts.

  Voici comment contacter  SMC  (non  pas  que  vous  en  ayez  vraiment
  besoin).

       SMC / Standard Microsystems Corp., 80 Arkay Drive, Hauppage,
       New York, 11788, USA.

  Support Technique par telephone:

          800-992-4762 (USA)
          800-433-5345 (Canada)
          516-435-6250 (Autres pays)

  Demande de documentation:

          800-SMC-4-YOU (USA)
          800-833-4-SMC (Canada)
          516-435-6255  (Autres pays)

  Support technique par courrier electronique:

          techsupt@ccmail.west.smc.com

  Site FTP:

          ftp.smc.com

  Site WWW: SMC <http://www.smc.com>

  5.35.1.  WD8003, SMC Elite

  Statut -- Supporte

  Ce sont les versions 8 bits de la carte. La 8003 8 bits est legerement
  moins  chere,  mais  ne  vaut  ces  economies que pour une utilisation
  legere. Notez que certaines des cartes sans EEPROM  (des  clones  avec
  des  cavaliers, ou des vieilles vieilles vieilles cartes wd8003) n'ont
  aucun moyen d'indiquer la ligne d'IRQ qu'elles utilisent. Dans ce cas,
  l'affectation  automatique  d'IRQ  est utilisee, et si cela echoue, le
  pilote utilise l'IRQ 5  sans  rien  dire.   Vous  pouvez  obtenir  les
  disquettes  d'installation/de  parametrage  de  SMC sur le site FTP de
  SMC.  Notez que certains des plus recents  programmes  'SuperDisk'  de
  SMC  ne  reussiront  pas  a detecter les cartes vraiment vieilles sans
  EEPROM.  Le fichier SMCDSK46.EXE semble etre un bon choix  en  fin  de
  compte.  Notez  aussi que les reglages des cavaliers pour toutes leurs
  cartes  se  trouvent  dans  un  fichier  texte  dans  l'archive   sus-
  mentionnee.  La derniere (meilleure?) version peut etre obtenue depuis
  ftp.smc.com.

  Comme ces cartes sont fondamentalement les memes que leurs  homologues
  16  bits  (WD8013  /  SMC  Elite16), vous devriez consulter la section
  suivante pour plus d'information.

  5.35.2.  WD8013, SMC Elite16

  Statut -- Supporte

  Au fil des ans, la conception  a  ajoute  plus  de  registres  et  une
  EEPROM.  (Les premieres cartes wd8003 sont apparues il y a environ dix
  ans!) Les clones portent en general un nom  en  `8013',  et  utilisent
  habituellement  une  conception  sans EEPROM (avec des cavaliers). Les
  cartes SMC dernier modele auront la puce SMC  83c690  au  lieu  de  la
  DP8390  de  National  Semiconductor  que  l'on trouvait sur les cartes
  anterieures.  La conception a memoire partagee rend les cartes un  peu
  plus rapides que les cartes a E/S programmees (PIO), specialement avec
  des paquets de taille importante.  Plus important, du point de vue  du
  pilote,  cela  evite  quelques  bogues  dans le mode PIO du 8390, cela
  permet un acces sur au tampon de paquets sur un systeme  multi-thread,
  et  l'on  n'a  pas un registre de donnees PIO qui bloque votre machine
  pendant les procedures de detection apres un redemarrage a chaud.

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

  Pour  les  cartes  qui  n'ont  pas  une  quantite de memoire embarquee
  standard, la taille de la memoire peut etre  specifiee  au  moment  du
  demarrage  (ou  passee  a  insmod  si  vous utilisez les modules).  La
  taille memoire standard est de 8 Ko pour une carte 8 bits et de 16  Ko
  pour  une  carte  16  bits.   Par  exemple,  les ancestrales WD8003EBT
  peuvent etre configurees par  cavaliers  pour  utiliser  32  Ko.  Pour
  permettre  l'utilisation  complete  de  cette memoire, vous utiliserez
  quelque chose comme (pour une  adresse  d'E/S  de  base  de  0x280  et
  l'IRQ 9):

  ______________________________________________________________________
          LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0
  ______________________________________________________________________

  Consultez aussi ``Les problemes des 8013'' pour certains des problemes
  les  plus  classiques  et  les  questions  qui  reviennent   le   plus
  frequemment.

  Si  vous  avez  l'intention  d'utiliser  ce  pilote sous la forme d'un
  module chargeable, vous devriez probablement consulter ``Utiliser  les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.35.3.  SMC Elite Ultra

  Statut -- Supporte

  Cette carte Ethernet est basee  sur  une  nouvelle  puce  de  SMC,  la
  83c790, qui comporte quelques nouvelles fonctionnalites.  Bien qu'elle
  possede un mode qui est similaire aux anciennes cartes  Ethernet  SMC,
  elle  n'est  pas entierement compatible avec les vieux pilotes WD80*3.
  Neanmoins, dans ce mode le pilote partage la plupart de son  code avec
  les  autres  pilotes  8390, tout en operant legerement plus rapidement
  qu'un clone WD8013.

  Puisque qu'une partie de l'Ultra ressemble a une 8013, la procedure de
  detection  de  l'Ultra  est  supposee  trouver  une Ultra avant que la
  procedure de detection de la wd8013 n'ait une chance  de  l'identifier
  par erreur.

  Donald  a  mentionne qu'il est possible d'ecrire un pilote separe pour
  le mode `Altego' de l'Ultra, qui permet d'enchainer les  transmissions
  au  cout  d'une  utilisation inefficace des tampons de reception, mais
  cela n'arrivera probablement jamais.

  Utilisateurs d'adaptateurs SCSI maitres de bus, prenez note:  dans  le
  manuel  qui accompagne Interactive UNIX, il est mentionne qu'une bogue
  dans la SMC Ultra cause des corruptions de donnees  avec  des  disques
  SCSI   utilises   derriere   un   adaptateur  aha-154X.   Cela  touche
  certainement aussi des cartes compatibles aha-154X, comme  les  cartes
  BusLogic, et les adaptateurs SCSI AMI-FastDisk.

  SMC  a  reconnu  que  le  probleme se produit avec Interactive, et des
  anciens pilotes Windows NT. Il s'agit d'un conflit materiel  avec  des
  revisions  anterieures  de  la  carte  qui peut etre contourne dans la
  conception du pilote. Le pilote actuel de l'Ultra vous protege  contre
  ce  probleme en n'activant la memoire partagee que lors des transferts
  de donnees avec la carte. Assurez-vous que votre version de noyau soit
  au  moins la 1.1.84, ou que la version du pilote indiquee au demarrage
  est au moins  smc-ultra.c:v1.12,  sinon  vous  etes  vulnerable  a  ce
  probleme.

  Si  vous  avez  l'intention  d'utiliser  ce  pilote sous la forme d'un
  module chargeable, vous devriez probablement consulter ``Utiliser  les
  pilotes Ethernet comme modules'' ainsi que ``Les cartes a base de 8390
  comme modules'' pour des informations specifiques aux modules.

  5.35.4.  SMC Elite Ultra32 EISA

  Status -- Partiellement-Supporte

  Cette carte EISA partage plein de points communs  avec  son  homologue
  ISA.  Un pilote qui fonctionne (et qui est stable) est disponible pour
  les noyaux 2.0 sur demande aupres de l'auteur  de  ce  document.   Les
  remerciements  vont a Leonard Zubkoff pour l'achat de quelques unes de
  ces cartes afin que Leonard et moi-meme puissions ajouter  le  support
  Linux pour celles-ci. Le pilote sera inclus dans une version future du
  noyau Linux 2.1.x, ceci dit.

  5.35.5.  SMC EtherEZ (8416)

  Statut -- Supporte

  Cette carte utilise la puce 83c795 de SMC et supporte la specification
  Plug 'n Play. Elle comporte aussi un mode compatible SMC Ultra qui lui
  permet d'etre utilisee avec le pilote Ultra de Linux. Soyez sur(e)  de
  configurer  votre  carte  pour ce mode de compatibilite. Consultez les
  informations ci-dessus pour des notes sur le pilote Ultra.

  Pour les noyaux 1.2, la carte devait etre configuree  pour  operer  en
  memoire  partagee.  Neanmoins les noyaux 2.0 peuvent utiliser la carte
  en mode a memoire partagee ou a E/S programmees.  Le  mode  a  memoire
  partagee  sera  legerement  plus rapide, et utilisera considerablement
  moins de ressources processeur, par ailleurs.

  Notez que  les  verifications  specifiques  a  l'EtherEZ  avaient  ete
  ajoutees  au  pilote  SMC  Ultra  dans  le  noyau  1.1.84,  et que par
  consequent les versions anterieures du  noyau  ne  detecteront  ou  ne
  gereront pas correctement ces cartes.

  5.35.6.  SMC EtherPower PCI (8432)

  Statut -- Supporte

  NB:  L'EtherPower  II  est  une carte totalement differente. Voir plus
  bas!

  Ces cartes sont une implementation de base de la puce  21040  de  DEC,
  c'est-a-dire  une  grosse  puce  et  quelques  transceivers.  Donald a
  utilise une de ces cartes pour son developpement du  pilote  generique
  21040  (aussi  connu  sous le nom de tulip.c). Merci de nouveau a Duke
  Kamstra,  d'avoir  fourni  une  carte   sur   laquelle   realiser   le
  developpement.

  Certaines  des dernieres revisions de cette carte utilisent la recente
  puce 21041 de DEC, ce qui peut causer des problemes avec des  versions
  anciennes  du  pilote  tulip. Si vous avez des problemes, assurez-vous
  d'utiliser la derniere version du pilote, qui peut ne  pas  encore  se
  trouver dans l'arborescence actuelle du noyau.

  Consultez  ``DEC  21040'' pour plus de details sur l'utilisation d'une
  de ces cartes, et l'etat d'avancement actuel du pilote.

  Apparemment, la toute derniere revision de la carte,  l'EtherPower-II,
  utilise  la  puce  9432.  Il  n'est  pas  clair a ce point si celle-ci
  fonctionnera avec le pilote actuel. Comme d'habitude, si  vous  n'etes
  pas  sur,  verifiez  que  vous  pourrez  rendre  la  carte  si elle ne
  fonctionne pas avec le pilote Linux avant de payer la carte.

  5.35.7.  SMC EtherPower II PCI (9432)

  Statut -- Partiellement-supporte

  Ces cartes, basees sur  la  puce  83c170  de  SMC,  sont  completement
  differentes des cartes basees sur la Tulip. Un nouveau pilote en phase
  de  test  ``alpha''  nomme  epic100.c  devrait  etre  inclus  dans  le
  noyau  2.0.34  pour  supporter  ces  cartes.   Pour  plus  de details,
  consultez:

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

  5.35.8.  SMC 3008

  Statut -- Non-supporte

  Ces cartes 8 bits sont basees sur la puce MB86950 de Fujitsu, qui  est
  une  ancienne  version  de la MB86965 utilisee dans le pilote Linux de
  l'at1700. Russ dit que vous devriez probablement pouvoir bidouiller un
  pilote  en  regardant le code de at1700.c et son pilote en mode paquet
  pour la  carte  Tiara  (tiara.asm).   Ces  cartes  ne  sont  pas  tres
  repandues.

  5.35.9.  SMC 3016

  Statut -- Non-supporte

  Il  s'agit  de  cartes  16  bits  a  E/S  mappees,  a  puce 8390, tres
  similaires a une carte NE2000 generique. Si vous  pouvez  obtenir  les
  specifications  chez  SMC,  alors realiser un portage du pilote NE2000
  sera certainement relativement facile.  Ces cartes ne  sont  pas  tres
  repandues.

  5.35.10.  SMC-9000 / SMC 91c92/4

  Statut -- Supporte

  La  SMC9000  est  une  carte  VLB  basee  sur la puce 91c92.  La 91c92
  apparait aussi sur un petit nombre d'autres cartes de marque, mais est
  plutot peu commune.  Erik Stahlman (erik@vt.edu) a ecrit ce pilote qui
  se trouve dans les noyaux 2.0, mais  pas  dans  les  noyaux  1.2  plus
  anciens.   Vous devriez pouvoir mettre le pilote dans une arborescence
  de noyau 1.2 avec un minimum de difficulte.

  5.35.11.  SMC 91c100

  Statut -- Partiellement-supporte

  Le pilote SMC 91c92 est suppose fonctionner pour les cartes basees sur
  cette  puce  100Base-T,  mais  a  l'heure  actuelle  cela  n'a pas ete
  verifie.

  5.36.  Xircom

  Pendant des temps  immemoriaux,  Xircom  ne  voulait  pas  donner  les
  informations necessaires a l'ecriture d'un pilote, a moins que vous ne
  leur signiez  un  papier  leur  abandonnant  votre  vie.   Apparemment
  suffisamment  d'utilisateurs  de Linux les ont embetes pour obtenir du
  support pour un pilote (ils pretendent que leurs  cartes  fonctionnent
  sur tous les systemes d'exploitation reseau populaires...) pour qu'ils
  aient change leur politique  afin  de  permettre  de  diffuser  de  la
  documentation  sans  avoir  a signer un accord de confidentialite.  et
  apparemment ils fourniront aussi le code source  du  pilote  SCO.   Si
  vous  voulez  verifier que c'est le cas, vous pouvez joindre Xircom au
  1-800-874-7875, 1-800-438-4526 ou au +1-818-878-7600.

  (NDT: les deux premiers numeros sont des numeros verts aux  Etats-Unis
  et  ne  sont  pas  accessibles  depuis  l'etranger.  Le dernier est un
  numero international.)

  Toutefois, pour l'instant personne  ne  s'est  precipite  pour  offrir
  d'ecrire  un  pilote,  donc  tous  leurs  produits  sont  encore  non-
  supportes.

  5.36.1.  PE1, PE2, PE3-10B*

  Statut -- Non-supporte

  Ce n'est pas pour vous reconforter, mais si  vous  avez  l'un  de  ces
  adaptateurs  sur  port  parallele, vous pourrez peut-etre les utiliser
  sous l'emulateur DOS avec les pilotes DOS fournis  par  Xircom.   Vous
  devrez  autoriser  l'acces de DOSEMU au port parallele, et vous devrez
  certainement jouer avec SIG (le generateur  d'interruptions  idiot  de
  DOSEMU, en anglais Silly Interrupt Generator).

  5.37.  Zenith

  5.37.1.  Z-Note

  Statut -- Supporte

  L'adaptateur  reseau  integre  au  Z-Note  est base sur la puce i82593
  d'Intel, et utilise deux canaux DMA. Il  existe  un  pilote  (alpha?),
  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 executez make config.
  Consultez ``Programmation des puces Intel'' pour des informations plus
  techniques.  Notez aussi que l'IBM ThinkPad 300 est compatible avec le
  Z-Note.

  5.38.  Znyx

  5.38.1.  Znyx ZX342 (DEC 21040 based)

  Statut -- Supporte

  Vous avez le choix entre deux pilotes pour les cartes basees sur cette
  puce.  D'une  part  le  pilote  DE425 ecrit par David, d'autre part le
  pilote 21040 generique ecrit par Donald.

  Notez que depuis la version 1.1.91,  David  a  ajoute  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
  README.de4x5 pour les details.

  Consultez ``DEC 21040'' pour plus d'informations sur ces cartes, et la
  situation actuelle du pilote.

  5.39.  Identifier une carte inconnue

  OK, l'ami du voisin du cousin de votre oncle a un frere qui  a  trouve
  une  vieille carte Ethernet ISA dans le boitier de l'AT qui servait de
  cage pour le hamster de son fils. D'une maniere 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 soupcon d'une  idee  de
  ce qu'est cette carte et il n'y a aucune documentation.

  Tout  d'abord,  cherchez  n'importe  quel numero de modele evident qui
  pourrait fournir un indice. Un numero de modele qui contient 2000 sera
  certainement  un  clone  de  NE2000. Une carte avec 8003 ou 8013 ecrit
  quelque part dessus sera une carte WD80x3 de  Western/Digital  ou  une
  SMC Elite, ou un clone d'une de celles-ci.

  5.39.1.   (Network Interface Controller, NIC) Identifier le controleur
  d'interface reseau

  Cherchez la plus grosse puce sur  la  carte.  Ce  sera  le  controleur
  reseau  (NIC) lui-meme, et la plupart peuvent etre identifies par leur
  numero de serie . Si vous savez quel NIC se trouve sur  la  carte,  ce
  qui suit devrait vous aider a deviner de quelle carte il s'agit.

  Encore  a  l'heure actuelle, le NIC le plus courant est la puce DP8390
  de National Semiconductor, aussi connue sous le nom de NS32490,  aussi
  connue  sous  le  nom de DP83901, aussi connue sous le nom de DP83902,
  aussi connue sous le nom de DP83905,  aussi  connue  sous  le  nom  de
  DP83907.  Et  il  ne  s'agit  que  de  celles  fabriquees par National
  Semiconductor! D'autres societes 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.  Le deuxieme type de cartes basees sur le 8390 sont  les
  wd80x3  (de Western/Digital) et ses clones. Des cartes avec un DP83905
  peuvent etre configurees pour etre une  NE2000  ou  une  wd8013.   Les
  versions  les  plus  recentes  des  wd80x3  de  base  et des SMC Elite
  possedent un 83c690 en lieu et place du DP8390 d'origine.  Les  cartes
  SMC  Ultra ont un 83c790, et utilise un pilote legerement different de
  celui des cartes wd80x3.  Les cartes EtherEZ de SMC ont un 83c795,  et
  utilisent  le  meme  pilote  que  la SMC Ultra.  Toutes les cartes BNC
  basees sur un type de 8390 ou de clone de 8390 auront generalement  un
  8392  (ou un 83c692, ou un XXX392) en boitier DIP 16 broches tout pres
  du connecteur BNC.

  Un autre NIC courant que l'on trouve sur des cartes plus anciennes est
  l'Intel  i82586.  Les  cartes  qui  comportent  cette puce incluent la
  3c505, la 3c507, la 3c523, l'EtherExpress-ISA d'Intel, l'Exos-205T  de
  Microdyne, et la NI5210 de Racal-Interlan.

  Le NIC d'origine de la carte LANCE d'AMD etait numerote AM7990, et les
  revisions plus recentes incluent le 79c960, le 79c961, le  79c965,  le
  79c970,  et  le 79c974.  La plupart des cartes avec l'une de ces puces
  fonctionnera avec le pilote LANCE de Linux, a l'exception des vieilles
  cartes NI6510 de Racal-Interlan qui possedent leur propre pilote.

  Les  cartes  PCI  les  plus recentes et qui comportent une puce de DEC
  numerotee 21040, 21041, 21140, ou un numero approchant,  sur  le  NIC,
  devraient  etre  capable  d'utiliser  le  pilote  `tulip' ou le pilote
  `de4x5' de Linux.

  Les autres cartes PCI qui comportent une grosse puce  marquee  RTL8029
  sont  des  clones  de  NE2000,  et  le pilote `ne' des versions 2.0 et
  superieures du noyau Linux devrait automatiquement detecter ces cartes
  au demarrage.

  5.39.2.  Identifier l'adresse Ethernet

  Chaque carte Ethernet possede sa propre adresse sur six octets qui est
  unique et propre a cette carte. Les trois  premiers  octets  de  cette
  adresse  Ethernet  sont  les memes pour chaque carte construite par un
  constructeur particulier. Par exemple, toutes les adresses des  cartes
  de  SMC  commencent  par  00:00:c0.  Les  trois  derniers  octets sont
  affectes  par  le  constructeur  de  facon  unique  a   chaque   carte
  individuelle au fur et a mesure qu'elles sont produites.

  Si  votre  carte comporte un autocollant qui donne tous les six octets
  de son adresse, vous pouvez identifier le constructeur  a  partir  des
  trois  premier.  Toutefois,  il est plus courant de ne trouver que les
  trois derniers octets, imprimes sur un autocollant attache a une  PROM
  enchassee sur la carte, ce qui ne vous indique rien du tout.

  Vous  pouvez  determiner  quel constructeur possede quelles adresses a
  partir de la RFC-1340. Apparemment il existe egalement une liste  plus
  a  jour  qui  est  disponible  a divers endroits. Essayez de faire une
  recherche WWW ou FTP sur  EtherNet-codes  ou  Ethernet-codes  et  vous
  trouverez quelque chose.

  5.39.3.  Quelques astuces pour essayer d'utiliser une carte inconnue

  Si vous n'etes toujours pas sur(e) de quelle carte il s'agit, mais que
  vous  avez  un peu reduit le champ des possibilites, alors vous pouvez
  construire un noyau en y incluant tout un tas de pilotes, et  voir  si
  l'un d'entre eux detecte automatiquement la carte lors du demarrage.

  Si  le  noyau ne detecte pas la carte, il se peut que la carte ne soit
  pas configuree a l'une des adresses  que  le  pilote  teste  lorsqu'il
  recherche  une  carte. Dans ce cas, vous pourriez essayer de recuperer
  scanport.tar.gz sur votre site FTP Linux  local,  et  voir  s'il  peut
  trouver  l'adresse  pour  laquelle  votre  carte  est  configuree.  Ce
  programme parcourt l'espace d'adressage  d'entree/sortie  de  0x100  a
  0x3ff  en cherchant des peripheriques qui ne sont pas deja enregistres
  dans /proc/ioports. S'il trouve un peripherique inconnu qui demarre  a
  une  adresse  donnee,  vous  pouvez  alors  explicitement  diriger les
  procedures de detection Ethernet vers cette adresse  en  utilisant  un
  argument de demarrage ether=.

  Si  vous  arrivez  a  faire  en sorte que la carte soit detectee, vous
  pouvez alors  deviner  la  fonction  des  cavaliers  inconnus  en  les
  modifiant  un par un et en regardant a quelle adresse d'E/S de base et
  a quelle IRQ la carte est detectee. Les parametres d'IRQ peuvent aussi
  habituellement  etre  determines  en  suivants les traces au dos de la
  carte jusqu'a l'endroit ou les cavaliers sont soudes.  En comptant les
  `doigts  d'or'  sur la face arriere, depuis l'extremite de la carte ou
  se situe la plaque metallique 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 bits ne comportent que les doigts 1 a 31.

  Les  cavaliers  qui paraissent ne servir a rien servent generalement a
  selectionner l'adresse memoire  d'une  ROM  de  demarrage  (boot  ROM)
  optionnelle.  D'autres  cavaliers  situes  pres des connecteurs BNC ou
  RJ-45 ou AUI servent generalement a selectionner le  support  physique
  de sortie. Ceux-ci se situent typiquement pres des `boites noires' qui
  contiennent les convertisseurs de tension,  marquees  YCL,  Valor,  ou
  Fil-Mag.
  Une  collection  interessante  de  configurations  de  cavaliers  pour
  diverses cartes se trouve a l'URL suivante:

       Parametrage          des           cartes           Ethernet
       <http://www.syd.dit.csiro.au/staff/ken/personal/NIC/>

  5.40.  Pilotes pour peripheriques Non-Ethernet

  Quelques  autres  pilotes  existent  dans  les  sources  Linux  qui se
  presentent comme un peripherique  Ethernet  vis-a-vis  des  programmes
  reseaux,  bien  qu'ils  ne  soient pas reellement Ethernet.  Les voici
  brievement presentes pour etre complet.

  dummy.c - Le but de ce pilote est  de  fournir  un  peripherique  pour
  designer  une  route qui le traverse, mais sans transmettre reellement
  de paquets.

  eql.c - Load Equalizer (egaliseur de charge), qui  regroupe  plusieurs
  peripheriques esclaves (generalement des modems) et repartit la charge
  en  transmission  entre  eux  tout  en  ne   presentant   qu'un   seul
  peripherique aux programmes reseau.

  ibmtr.c - IBM Token Ring (anneau a jeton), qui n'est pas reellement de
  l'Ethernet. L'anneau a `jeter' necessite du routage par la  source  et
  autres trucs degoutants.

  loopback.c  -  Loopback  (boucle  locale), par lequel passent tous les
  paquets emis  par  votre  machine  a  destination  de  votre  machine.
  Essentiellement,  il  se  contente  de  sortir  les paquets de la file
  d'attente d'emission et de  les  placer  dans  la  file  d'attente  de
  reception.

  pi2.c - Interface Ottawa Amateur Radio Club PI et PI2.

  plip.c   -   Parallel  Line  Internet  Protocol  (PLIP,  IP  sur  port
  parallele), qui permet a deux ordinateurs  de  s'envoyer  des  paquets
  l'un a l'autre via leurs ports paralleles, en mode point-a-point.

  ppp.c  -  Point-to-Point Protocol (RFC1331), destine a la transmission
  de datagrammes multi-protocoles sur un lien point-a-point (de nouveau,
  en general des modems).

  (NDT:  C'est  le  mode de connexion le plus couramment employe par les
  fournisseurs d'acces Internet. Consultez le PPP-Howto.)

  slip.c - Serial Line Internet Protocol (SLIP, IP sur port serie),  qui
  permet  a deux ordinateurs de s'envoyer des paquets l'un a l'autre via
  leurs ports serie (generalement via  des  modems),  en  mode  point-a-
  point.

  tunnel.c  - Fournit un tunnel IP (dit aussi `IP over IP', `IP sur IP',
  NDT) a travers lequel vous pouvez envoyer du trafic  reseau  de  facon
  transparente entre sous-reseaux.

  (NDT:  Pratique pour gerer certains problemes delicats de politique de
  routage, par exemple.)

  wavelan.c - Un transceiver radio semblable a de  l'Ethernet,  controle
  par  le coprocesseur 82586 d'Intel qui est utilise sur d'autres cartes
  Ethernet comme l'Intel EtherExpress.

  6.  Cables, Coaxial, Paire Torsadee

  Si vous demarrez un reseau a partir de rien, il  sera  beaucoup  moins
  couteux  d'utiliser  l'Ethernet  fin, du cable RG-58 co-axial avec des
  connecteurs BNC, que le `gros' Ethernet  (thick  Ethernet),  du  cable
  RG-5  avec  des  connecteurs  N, ou que du 10BaseT, des cables a paire
  torsadee avec des connecteurs RJ-45 rectangulaires.  Consultez  ``Type
  de cables...'' pour une introduction rapide sur les cables.

  Notez   aussi   que   la   Foire   Aux   Questions   (FAQ)  du  groupe
  comp.dcom.lans.ethernet contient un tas d'informations utiles sur  les
  cables et tout ce genre de choses.  Jetez un coup d'oeil a

       Usenet FAQs <ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/>

  pour la FAQ de ce groupe de news.

  (NDT:  Le  lecteur  francophone  utilisera bien entendu un site miroir
  comme URL sur ibp a completer..  <ftp://ftp.lip6.fr/faq/...>  ou  tout
  site equivalent proche de chez lui.)

  6.1.  Ethernet fin (thinnet)

  L'Ethernet  fin  est  `l'ether  de choix'. Le cable n'est pas cher. Si
  vous fabriquez vos cables vous-memes, le cable RG58A a ame solide  est
  a  $0.27/m et le cable multibrins RG58AU est a 3,40F/m.  (NDT: Le prix
  du RG58A est en dollar car je n'ai pas pu trouver de prix pour ce type
  de  cable  en  France!)   Les connecteurs BNC a visser sont a moins de
  deux dollars chacun.  (NDT: A sertir,  environ  10  francs  pieces,  a
  souder  un  peu  plus  cher  mais  vous  n'avez  pas besoin d'un outil
  special.)

  Les autres pieces diverses sont tout aussi bon marche.

  Il est important que vous terminiez chaque extremite du cable avec  un
  `bouchon' de 50 ohms (NDT: bouchon ou terminateur..), donc prevoyez 70
  francs pour une paire. Il est aussi vital que votre cable ne  comporte
  pas  de  `patte  qui  pend'  --  les  connecteurs  en `T' doivent etre
  raccordes directement aux cartes Ethernet, sans cable entre le `T'  et
  la carte.

  Le  seul  point  noir est que si vous avez un grand nombre de machines
  raccordees entre elles, il suffit qu'un imbecile coupe  le  reseau  en
  debranchant un des cables qui se trouvent sur les cotes de son `T', et
  tout le reseau se retrouve par terre parce qu'il  voit  une  impedance
  infinie  (circuit  ouvert) au lieu de la terminaison a 50 ohms qui est
  necessaire.  Notez que vous pouvez enlever la piece en forme de `T' de
  la carte Ethernet elle-meme sans tuer tout le sous-reseau, pour autant
  que vous n'enleviez pas les cables du `T' lui-meme. Bien entendu  cela
  perturbera  la  machine d'ou vous venez d'enlever le `T'. 8-) Et notez
  aussi que si vous creez un petit reseau constitue  de  seulement  deux
  machines,  vous  devez  quand  meme  mettre  en  place  les `T' et les
  bouchons de 50 ohms. -- vous ne  pouvez  pas  juste  cabler  les  deux
  machines entre elles!

  NDT:  Notez aussi que vous ne devez pas creer une boucle avec le cable
  non plus, en reliant toutes les machines entre elles et en reliant  la
  derniere machine avec la premiere. La presence d'un bouchon de 50 ohms
  a chaque extremite du cable (et il ne doit y avoir que deux extremites
  8-) ) est indispensable pour qu'Ethernet fonctionne correctement. (Fin
  de la note)
  Notez qu'il existe un petit  nombre  de  cartes  qui  possede  une  un
  cavalier  qui,  quand il est ferme, place une resistance de 50 ohms en
  travers de l'entree BNC. Avec ces cartes, vous pouvez utiliser un  `T'
  BNC  et un bouchon comme d'habitude, ou au contraire enficher le cable
  directement dans la carte et fermer le cavalier pour mettre en  oeuvre
  la terminaison integree a la carte.

  Il  existe  aussi des systemes de cablage rigolos qui font comme si un
  seul fil arrivait a la carte, mais en fait le fil est une boucle,  les
  deux  longueurs  de  cable  reposant  cote-a-cote, recouvertes par une
  protection exterieure, ce qui donne au fil une section de forme ovale.
  A  l'extremite de cette boucle est insere un connecteur BNC sur lequel
  se connecte votre carte. Vous avez donc l'equivalent d'un aller-retour
  de  cable  et  d'un  `T'  BNC,  mais  avec  ce type de cablage, il est
  impossible pour l'utilisateur d'enlever un cable d'un seul cote du `T'
  et donc de perturber le reseau.

  (NDT:  C'est  une bonne idee, mais la realisation du cablage entre les
  prises de raccordement est delicate, et  le  moindre  defaut  amplifie
  rapidement les problemes de l'Ethernet fin.  )

  6.2.  Paire torsadee

  Les  reseaux  a  paire  torsadee necessitent des hubs actifs, dont les
  prix demarrent aux environ de 600 francs, et le  prix  du  cable  brut
  peut etre en fait superieur a celui de Thinnet.  Ils sont generalement
  vendus  en  pretendant  que  vous  pouvez   utiliser   votre   cablage
  telephonique existant, mais il est rare de trouver une installation ou
  c'est le cas.

  (NDT: Ca c'est du pessimisme avere. J'ai deja fait pire. :])

  La pretention que  vous  pourrez  augmenter  les  vitesses  est  aussi
  suspecte,  car la plupart des methodes proposees utilisent du cable de
  meilleure  qualite  (entendez   FF++)   et   des   terminaisons   plus
  sophistiquees (+++FFFF++) que ce que vous pouvez esperer installer.

  De  nouveaux  machins apparaissent, qui vous permettent de chainer les
  machines entre elles, et autres trucs du  meme  genre.   Par  exemple,
  Farallon  vend  des  adaptateurs  et  des  transceivers  EtherWave. Ce
  peripherique permet a plusieurs autres  peripheriques  10BaseT  d'etre
  chaines  entre  eux. Ils vendent aussi un clone de 3c509 qui inclut le
  transceiver EtherWave.  La contrepartie est que  c'est  plus  cher  et
  moins  sur  qu'un  mini-hub  bon  marche (600-900 francs) et une autre
  carte Ethernet.  Vous feriez probablement mieux de choisir  l'approche
  avec le hub ou de passer au Thinnet/10Base2.

  D'un  autre  cote,  les  prix des hubs sont en chute libre, toutes les
  propositions Ethernet 100Mb/s  utilisent  la  paire  torsadee,  et  la
  plupart  des  installations professionnelles neuves utilisent la paire
  torsadee. (Certainement pour eviter le probleme des idiots qui  jouent
  avec les BNC comme decrit ci-dessus.)

  (NDT:  Euh, c'est peut-etre aussi parce qu'avec un cablage banalise on
  peut  faire  de  la  voix  (entendez:  du  telephone),  de  la  donnee
  (entendez: du reseau), et de la video, sur le meme cable, ce qui coute
  quand meme moins cher que trois cablage differents!)

  De plus, Russ Nelson ajoute que `Les nouvelles installations devraient
  utiliser  du  cablage  Categorie 5. Toute autre chose est une perte de
  temps  de  votre  installateur,  car   le   100Base-ce-que-vous-voulez
  necessitera du Cat. 5.'

  (NDT:  Pour  etre  precis,  c'est  du Categorie 5, Classe D qu'il faut
  exiger. Un pour le type de cable, un pour la plage de frequence. :))

  Si vous n'avez que deux machines a raccorder, il est possible d'eviter
  l'utilisation  d'un hub, en croisant les paires emissions et reception
  (1-2 et 3-6).

  Si vous tenez le connecteur RJ-45 face a vous (comme si vous alliez le
  brancher  dans  votre  bouche)  avec le petit clip de fixation vers le
  haut, alors les broches sont numerotees de 1 a 8 de la gauche vers  la
  droite. L'utilisation des broches est la suivante:

          Numero de broche        Utilisation
          ----------              ----------
          1                       Sortie des Donnees (+)
          2                       Sortie des Donnees (-)
          3                       Entree des Donnees (+)
          4                       Reserve pour le telephone
          5                       Reserve pour le telephone
          6                       Entree des Donnees (-)
          7                       Reserve pour le telephone
          8                       Reserve pour le telephone

  Si vous souhaitez fabriquer un cable, ce qui suit devrait vous fournir
  tous les details voulus.  Les paires de signaux differentiels  doivent
  se  trouver  sur  la meme paire torsadee afin d'obtenir l'impedance et
  les pertes minimales requises d'un cable UTP.  Si  vous  consultez  la
  table  ci-dessus,  vous constatez que 1+2 et 3+6 sont les ensembles de
  paires de signaux differentiels. Pas 1+3 et 2+6 !!!!!!  A 10 MHz, avec
  des distances courtes, vous echapperez *peut-etre* aux consequences de
  telles erreurs, si c'est vraiment sur une courte  distance.  Mais  n'y
  pensez meme pas a 100 MHz.

  Pour  un  cordon  de  brassage normal, avec les extremites `A' et `B',
  vous  avez  besoin  d'un  raccordement  `droit',  broche  par  broche,
  l'entree  et  la  sortie utilisant chacune une paire de fils (pour des
  problemes d'impedance). 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 etre  sur
  la  meme paire torsadee. De meme, les fils qui joignent 3A-3B et 6A-6B
  doivent etre sur une autre paire torsadee.

  Maintenant, si vous n'avez pas de hub, mais que vous voulez  fabriquer
  un  `cable  null'  (ou cable croise, NDT), ce que vous souhaitez faire
  est que l'entree de `A' devienne la sortie de `B', et que la sortie de
  `A' devienne l'entree de `B', sans changer la polarite.  Cela signifie
  donc raccorder 1A a 3B (sortie+ de A vers entree- de B)  et  2A  a  6B
  (sortie-  de  A vers entree- de B). Ces deux fils doivent etre sur une
  paire torsadee. Ils transportent ce que  la  carte/le  connecteur  `A'
  considere  comme  la  sortie,  et  ce qui est vu comme l'entree par la
  carte/le connecteur `B'. Puis raccordez 3A a  1B  (entree+  de  A  sur
  sortie+  de B) et 6A a 2B (entree- de A sur sortie- de B). Ces deux-la
  aussi doivent etre sur une paire torsadee. Ils transportent ce que  la
  carte/le  connecteur  `A'  considere  comme  son  entree, et ce que la
  carte/le connecteur `B' considere comme sa sortie.

  Donc, si vous considerez un cordon de brassage normal,  enlevez  l'une
  de  ses  extremites, echangez les emplacements des paires de reception
  et d'emission dans le nouveau connecteur, sertissez-le, et  vous  avez
  un  cable  `null'  (enfin, croise, quoi! NDT). Rien de bien complique.
  Vous voulez juste que le signal transmis par une carte soit envoye sur
  le recepteur de la seconde, et vice versa.

  Notez qu'avant que 10BaseT soit ratifie en tant que norme, il existait
  d'autres formats de reseau qui utilisaient des connecteurs RJ-45, avec
  le  meme  principe  de  cablage  que  ci-dessus.  Des exemples sont le
  LattisNet de SynOptics et le StarLAN d'AT&T.  Dans certains cas (comme
  les premieres cartes 3C503) vous pouvez positionner des cavaliers pour
  que la carte puisse dialoguer avec des hubs de differents types,  mais
  dans  la  plupart des cas les cartes concues pour ces anciens types de
  reseaux ne fonctionneront pas avec un hub/un reseau 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, combine avec un transceiver AUI /
  10BaseT.)

  6.3.  Thick Ethernet -         Le `gros' Ethernet

  Le  `Thick  ethernet' est pratiquement obsolete, et n'est generalement
  utilise que pour rester compatible avec une implementation  existante.
  Vous  pouvez  outrepasser  les  regles  et  connecter des brins courts
  d'Ethernet fin (ThinNet 10Base2) et epais (ThickNet 10Base5)  ensemble
  avec  un connecteur passif N-vers-BNC a 15 francs, et c'est souvent la
  meilleure solution pour  etendre  un  reseau  ThickNet  existant.  Une
  solution correcte (mais plus chere) est d'utiliser un repeteur dans ce
  cas.

  7.  Configuration logicielle et diagnostics de carte

  Dans la plupart des cas, si la configuration est faite  par  logiciel,
  et  stockee  dans une EEPROM, vous devrez demarrer DOS, et utiliser le
  programme DOS fourni pour configurer l'IRQ, les ports d'E/S, l'adresse
  memoire  et  autres choses sur la carte. Du reste, on peut esperer que
  c'est quelque chose que vous ne configurerez  qu'une  seule  fois.  Si
  vous  ne  disposez  pas  du  logiciel DOS pour votre carte, essayer de
  chercher sur le site WWW du constructeur de votre carte.  Si  vous  ne
  connaissez  pas  le  nom  du  site, essayez de le deviner, par exemple
  `www.mon-constructeur.com'  ou  `mon-constructeur'  est  le   nom   du
  constructeur.  Cela fonctionne pour SMC, 3Com, et plein plein d'autres
  fabricants.

  On trouve certaines cartes pour  lesquelles  des  versions  Linux  des
  utilitaires  de  configuration  existent,  et  elle  sont listees ici.
  Donald  a  ecrit  quelques  petits  programmes   de   diagnostic   qui
  fonctionnent  sous  Linux.  La  plupart  d'entre  eux sont le resultat
  d'outils de debogage  qu'il  a  cree  pendant  l'ecriture  des  divers
  pilotes.  Ne  vous  attendez  pas  a des interfaces rigolotes avec des
  menus. Vous aurez besoin de  lire  le  code-source  pour  utiliser  la
  plupart  d'entre  eux.  Meme  si  votre  carte n'a pas de programme de
  configuration  correspondant,  vous  pouvez  encore  obtenir  un   peu
  d'information  juste  en  tapant  cat /proc/net/dev -- a condition que
  votre carte ait ete au moins detectee au demarrage.

  Dans tous les cas, vous devrez executer la plupart de  ces  programmes
  en  tant  que  root  (pour  permettre l'acces aux ports d'E/S) et vous
  devrez  certainement  desactiver  la  carte  reseau  avant  en  tapant
  ifconfig eth0 down (Note: remplacer eth0 par atp0 ou toute autre chose
  appropriee.)

  7.1.  Programmes de configuration pour cartes Ethernet

  7.1.1.  Cartes WD80x3

  Pour ceux d'entre vous  qui  ont  des  cartes  wd80x3,  il  existe  le
  programme  wdsetup  qui  peut etre trouve dans wdsetup-0.6a.tar.gz sur
  les sites FTP linux.  Je ne suis pas sur qu'il soit encore  activement
  maintenu,  car il n'a pas ete mis a jour depuis deja pas mal de temps.
  S'il fonctionne correctement pour vous, c'est parfait, sinon, utilisez
  la  version  DOS  que  vous devriez avoir obtenue avec votre carte. Si
  vous n'avez pas la version DOS, vous serez heureux d'apprendre que les
  disquettes de configuration et les pilotes SMC sont disponibles sur le
  site FTP de SMC.

  Bien entendu, vous devez avoir une carte avec EEPROM pour utiliser cet
  utilitaire.   Les vieilles, vieilles cartes wd8003, et certains clones
  wd8013 utilisent a la place des cavaliers pour configurer la carte.

  7.1.2.  Cartes Digital / DEC

  La carte EtherWorks 3 de Digital  peut  etre  configuree  d'une  facon
  similaire  au  programme DOS NICSETUP.EXE.  David C. Davies l'a ecrit,
  ainsi que certains autres outils pour l'EtherWorks 3,  en  conjonction
  avec  le  pilote.   Regardez  sur  sunsite.unc.edu  dans le repertoire
  /pub/linux/system/Network/management   un   fichier   qui    s'appelle
  ewrk3tools-X.XX.tar.gz.

  (NDT:  Le  lecteur  francais  aura tout interet a utiliser un site FTP
  plus          proche,           comme           par           exemple:
  ftp://ftp.lip6.fr/pub/linux/sunsite/system/Network/management)

  7.1.3.  Cartes NE2000+ ou AT/LANTIC

  Certaines implementations de la puce DP83905 de National Semiconductor
  (comme  l'AT/LANTIC  et  la  NE2000+)  peuvent  etre  configurees  par
  logiciel.  (Notez  que  ces  cartes  peuvent  aussi  emuler  une carte
  wd8013!) Vous pouvez recuperer le fichier  /pub/linux/setup/atlantic.c
  sur  le  serveur  FTP de Donald, cesdis.gsfc.nasa.gov, pour configurer
  cette carte.  De plus, les programmes de configuration pour les cartes
  DP83905  de  Kingston semblent fonctionner avec toutes les cartes, car
  ils ne verifient pas une adresse specifique au constructeur  avant  de
  vous autoriser a les utiliser. Suivez l'URL que voici:

       Logiciel       Kingston       <http://www.kingston.com/down-
       load/etherx/etherx.htm>

  et recuperez 20XX12.EXE et INFOSET.EXE.

  Soyez attentif en configurant des cartes NE2000+, car vous pouvez leur
  fournir   des  valeurs  de  parametrage  erronees  qui  causeront  des
  problemes. Un exemple classique est d'activer accidentellement la  ROM
  de  demarrage dans l'EEPROM (meme si aucune ROM n'est installee) et de
  fournir une valeur qui entre en conflit avec la carte VGA. Le resultat
  est  un ordinateur qui se contente de vous envoyer des `bip' (les BIOS
  AMI bippent huit fois lors d'echec VGA) quand vous l'allumez  et  rien
  n'apparait a l'ecran.

  Vous  pouvez  typiquement  vous sortir de ce mauvais pas en faisant ce
  qui suit:

  Enlevez  la  carte  de  la  machine,  redemarrez  et  entrez  dans  la
  configuration  CMOS.  Changez  le  parametre  `Display Adapter' (carte
  video) en `Not Installed' (pas de carte video) et changez le disque de
  demarrage par defaut (`Default Boot Drive' ou `Boot Sequence', NDT) en
  `A:' (votre lecteur de disquette).  Changez aussi le  parametre  `Wait
  for  F1  if  any  Error' (attendre un appui sur F1 en cas d'erreur) en
  `Disabled' (desactive).  De cette facon, l'ordinateur devrait demarrer
  sans  intervention  de  l'utilisateur.  Maintenant creez une disquette
  DOS  de  demarrage  (`format  a:  /s  /u')  et  copiez  le   programme
  default.exe  de  l'archive  20XX12.EXE sur cette disquette. Puis tapez
  echo default > a:autoexec.bat afin que le programme qui remet la carte
  a des valeurs par defaut coherentes soit execute automatiquement quand
  vous demarrez sur cette disquette.  Eteignez la  machine,  reinstallez
  la  carte  ne2000+,  inserez votre nouvelle disquette de demarrage, et
  rallumez la machine. Elle devrait certainement vous bipper de  nouveau
  a la figure, mais vous devriez voir la lumiere du lecteur de disquette
  s'allumer pendant qu'elle demarre a partir de la  disquette.  Attendez
  une  minute  ou  deux  que le lecteur de disquette s'arrete, indiquant
  ainsi que la machine a fini d'executer le programme default.exe,  puis
  eteignez  votre  ordinateur.  Lorsque  vous  le  rallumez, vous pouvez
  esperer avoir un ecran qui fonctionne de nouveau, ce qui  vous  permet
  de  remettre  les  parametres  CMOS  a  leurs anciennes valeurs, et de
  changer de nouveau les parametres de l'EEPROM de  la  carte  pour  les
  valeurs que vous voulez.

  Notez que si vous n'avez pas de DOS sous la main, vous pouvez utiliser
  la methode ci-dessus avec un disque de  demarrage  Linux  qui  execute
  automatiquement  le  programme  atlantic  de  Donald  (avec les bonnes
  options sur la ligne de commande) au lieu d'une disquette de demarrage
  DOS qui execute automatiquement le programme default.exe.

  7.1.4.  Cartes 3Com

  La  famille  des cartes Etherlink III de 3Com (c'est-a-dire les 3c5x9)
  peut etre configuree en utilisant un autre utilitaire de configuration
  de      Donald.       Vous      pouvez      obtenir     le     fichier
  /pub/linux/setup/3c5x9setup.c  sur   le   serveur   FTP   de   Donald,
  cesdis.gsfc.nasa.gov,  afin  de  configurer  ces  cartes.   (Notez que
  l'utilitaire  de  configuration  DOS  3c5x9B  peut   comprendre   plus
  d'options  se  rapportant  aux  nouvelles  series  ``B'' de la famille
  Etherlink III).

  7.2.  Programmes de diagnostic pour cartes Ethernet

  Tous les programmes de diagnostic que  Donald  a  ecrit  peuvent  etre
  obtenus a partir de cette URL.

       Diagnostics     pour     cartes     Ethernet    <http://ces-
       dis.gsfc.nasa.gov/pub/linux/diag/diagnostic.html>

  Allied Telesis AT1700 -- cherchez le fichier  /pub/linux/diag/at1700.c
  sur cesdis.gsfc.nasa.gov.

  Cabletron  E21XX  --  cherchez  le  fichier  /pub/linux/diag/e21.c sur
  cesdis.gsfc.nasa.gov.

  HP  PCLAN+  --   cherchez   le   fichier   /pub/linux/diag/hp+.c   sur
  cesdis.gsfc.nasa.gov.

  Intel  EtherExpress  -- cherchez le fichier /pub/linux/diag/eexpress.c
  sur cesdis.gsfc.nasa.gov.

  Cartes  NE2000  --  cherchez  le  fichier  /pub/linux/diag/ne2k.c  sur
  cesdis.gsfc.nasa.gov.  Il existe aussi une version PCI pour les clones
  NE2000-PCI qui sont maintenant classiques.

  Adaptateur  de  poche   RealTek   (ATP)   --   cherchez   le   fichier
  /pub/linux/diag/atp-diag.c sur cesdis.gsfc.nasa.gov.

  Toutes  les  autres  cartes  --  essayez de taper cat /proc/net/dev et
  dmesg pour savoir quelles informations utiles le noyau possede sur  la
  carte en question.

  8.  Informations Techniques

  Pour  ceux d'entre vous qui souhaitent jouer avec les pilotes actuels,
  ou essayer de faire leur  propre  pilote  pour  une  carte  qui  n'est
  actuellement  pas  supportee,  ces  informations  peuvent  se  reveler
  utiles. Si vous n'entrez pas dans cette categorie  de  personne,  vous
  devriez peut-etre sauter cette section.

  8.1.  Adresses testees

  Lors  des essais realises afin de determiner quelle carte Ethernet est
  presente, les adresses  suivantes  sont  automatiquement  testees,  en
  considerant  que  le  type  de  la  carte n'a pas ete specifie dans le
  noyau.  Les  noms  de   fichier   qui   suivent   se   trouvent   dans
  /usr/src/linux/drivers/net/.

  ______________________________________________________________________
          3c501.c:        0x280, 0x300
          3c503.c:        0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2a0, 0x2e0
          3c505.c:        0x300, 0x280, 0x310
          3c507.c:        0x300, 0x320, 0x340, 0x280
          3c509.c:        port d'identification special
          apricot.c:      0x300
          at1700.c:       0x300, 0x280, 0x380, 0x320, 0x340, 0x260, 0x2a0, 0x240
          atp.c:          0x378, 0x278, 0x3bc
          depca.c         0x300, 0x200
          de600.c:        0x378
          de620.c:        0x378
          eexpress.c:     0x300, 0x270, 0x320, 0x340
          hp.c:           0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240
          hp-plus.c       0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340
          lance.c:        0x300, 0x320, 0x340, 0x360
          ne.c:           0x300, 0x280, 0x320, 0x340, 0x360
          ni52.c:         0x300, 0x280, 0x360, 0x320, 0x340
          ni65.c:         0x300, 0x320, 0x340, 0x360
          smc-ultra.c:    0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380
          wd.c:           0x300, 0x280, 0x380, 0x240
  ______________________________________________________________________

  Il existe certaines cartes Ethernet, clones de la NE2000, qui sont des
  trous  noirs  attendant  les   pilotes   qui   font   des   detections
  automatiques.  Alors  que de nombreux clones NE2000 sont surs jusqu'au
  moment ou ils sont actives, certains ne peuvent pas etre reinitialises
  dans  un  etat  sur.  Ces cartes Ethernet dangeureuses bloqueront tout
  acces d'E/S sur leurs `ports  de  donnees'.  Les  endroit  typiquement
  dangeureux sont:

  ______________________________________________________________________
          Adresse de base configuree    Endroits dangeureux
          par cavalier sur la carte     (adresse de base + 0x10 - 0x1f)
                  0x300 *                         0x310-0x317
                  0x320                           0x330-0x337
                  0x340                           0x350-0x357
                  0x360                           0x370-0x377
  ______________________________________________________________________

  *  L'adresse  0x300  est  l'endroit  traditionnel  ou placer une carte
  Ethernet, mais c'est aussi un endroit  populaire  ou  mettre  d'autres
  peripheriques  (souvent  des  controleurs  SCSI).  L'adresse 0x320 est
  souvent celle choisie ensuite, mais c'est mauvais pour la procedure de
  detection  de  l'AHA1542.  L'adresse 0x360 est mauvaise, parce qu'elle
  est en conflit avec le port parallele qui se trouve en 0x378. Si  vous
  avez  deux  controleurs  IDE, ou deux controleurs de disquettes, alors
  0x360 est aussi un mauvais choix, car une carte  NE2000  les  demolira
  aussi.

  Notez  que  les noyaux > 1.1.7x conservent un log de qui utilise quels
  ports d'E/S, et ne laisseront pas un pilote utiliser des  ports  d'E/S
  precedemment  enregistres par un autre pilote. Il peut en resulter que
  des procedures de detection echoueront sans rien  dire.   Vous  pouvez
  voir qui utilise quels ports d'E/S en tapant cat /proc/ioports si vous
  avez active le systeme de fichier proc.

  Pour eviter ces cartes Ethernet menacantes, voici ce que  vous  pouvez
  faire:

  o  Testez  le BIOS du peripherique dans l'espace memoire. C'est simple
     et toujours sur, mais cela ne fonctionne que pour  des  cartes  qui
     ont toujours des BIOS, comme les controleurs SCSI primaires.

  o  Evitez  de  tester  l'un  des emplacements ci-dessus jusqu'a ce que
     vous pensiez avoir trouve votre peripherique.   Les  clones  NE2000
     ont  un  intervalle de redemarrage de <base>+0x18 a <base>+0x1f qui
     donnera 0xff en lecture, donc commencez par lire la en  premier  si
     c'est  possible.   Vous  pouvez  aussi  tester  de  facon sure dans
     l'espace de la 8390 aux adresses <base>+0x00  -  <base>+0x0f,  mais
     cet espace vous renverra des valeurs quasi-aleatoires.

  o  Si vous devez tester dans l'intervalle dangereux, par exemple si le
     peripherique pour lequel vous programmez n'a que peu d'emplacements
     de  ports,  commencez par verifier qu'il n'y a pas une NE2000 a cet
     endroit-la. Vous pouvez voir comment faire en regardant le code  de
     detection dans /usr/src/linux/net/inet/ne.c.

  o  Utilisez  l'argument de demarrage `reserve' pour proteger des zones
     sensibles des procedures de detection. Lisez les  informations  sur
     l'utilisation  des  arguments  au  moment  du  demarrage  avec LILO
     dans ``La commande `reserve'''.

  8.2.  Ecriture d'un pilote de carte

  La seule chose indispensable pour utiliser  une  carte  Ethernet  sous
  Linux  est  le  pilote  approprie. Pour que cela soit possible, il est
  essentiel que le  constructeur  diffuse  les  informations  techniques
  necessaires  a  la  programmation de ce pilote a destination du public
  sans que vous (ou quelqu'un d'autre) ne soyez oblige  de  leur  vendre
  votre  ame.  Un  bon  indice des chances d'obtenir de la documentation
  (ou, si vous ne programmez pas,  les  chances  que  quelqu'un  d'autre
  pourra  ecrire ce pilote dont vous avez vraiment, vraiment besoin) est
  la disponibilite du pilote en mode paquet Crynwr (nee Clarkson ). Russ
  Nelson  dirige cette operation, et il a ete d'un grand service par son
  aide au cours du developpement de certain  pilotes  pour  Linux.  Vous
  pouvez essayer cette URL pour consulter le programme de Russ.

       Pilote     en     mode     paquet     de     Russ     Nelson
       <http://www.crynwr.com/crynwr/home.html>

  Une fois la documentation obtenue, vous pouvez ecrire un  pilote  pour
  votre carte et l'utiliser sous Linux (du moins en theorie).  Rappelez-
  vous neanmoins que certains materiels anciens qui ont ete  crees  pour
  des  machines  XT  ne  fonctionneront  pas  bien dans un environnement
  multitache comme Linux.  Leur  utilisation  entrainera  des  problemes
  importants si votre reseau est raisonnablement charge.

  La plupart des cartes possedent des pilotes pour des interfaces MS-DOS
  comme  NDIS  ou  ODI,  mais  ceux-ci  sont  inutiles  pour  Linux.  De
  nombreuses  personnes  ont  suggere  de les integrer directement ou de
  realiser une traduction automatique, mais c'est quasiment  impossible.
  Les  pilotes  MS-DOS  s'attendent  a  travailler  en mode 16 bits et a
  utiliser des `interruptions logicielles', deux  notions  incompatibles
  avec  le  noyau Linux. Cette incompatibilite est en faite un avantage,
  puisque certains pilotes pour Linux  sont  considerablement  meilleurs
  que  leur  equivalent  MS-DOS. Par exemple, la serie des pilote `8390'
  utilise des zones tampon de transmissions en ping-pong, qui commencent
  seulement a apparaitre dans le monde MS-DOS.

  (Des  zones  tampon  de  transmissions  en ping-pong signifie que l'on
  utilise au moins deux zones de la taille  maximale  d'un  paquet  pour
  transmettre  les  paquets.  L'une des zones est chargee pendant que la
  carte est en train de transmettre  l'autre.  Le  deuxieme  paquet  est
  alors  transmis des que le premier est fini, etc. De cette maniere, la
  plupart des cartes sont capables d'envoyer des paquets a la queue-leu-
  leu  sur le cable.)

  Bon.  Donc  vous avez decide d'ecrire un pilote pour la carte Ethernet
  Machin,  puisque  vous  avez  les  informations   necessaires   a   sa
  programmation, et que personne ne l'a encore fait (.. ce sont les deux
  conditions principales ;-) ). Vous devriez commencer avec le squelette
  de  pilote  reseau 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 recents.
  Jetez aussi un coup d'oeil sur  le  `Kernel  Hackers  Guide'  a  l'URL
  suivante:

       KHG <http://www.redhat.com:8080/HyperNews/get/khg.html>

  8.3.  Inteface du pilote avec le noyau

  Voici  quelques notes sur les fonctions que vous devrez ecrire si vous
  creez un nouveau pilote. Lisez-les en gardant le squelette  de  pilote
  decrit ci-dessus: cela simplifiera les choses.

  8.3.1.  Detection de la carte (Probe)

  Appelee au demarrage pour verifier l'existence de la carte.  Meilleure
  si elle peut verifier sans indiscretion en  lisant  la  memoire,  etc.
  Peut  aussi  lire  les  ports d'E/S. Ecrire au demarrage sur les ports
  d'E/S pour detecter la carte n'est pas bien parce que cela  risque  de
  tuer  un autre peripherique.  Certaines parties de l'initialisation du
  peripherique sont habituellement faites a ce niveau (allouer  l'espace
  d'E/S,  les  IRQ,  remplir  les  champs  de dev->???, etc.)  Vous avez
  besoin de savoir a quels ports d'E/S et a  quelles  zones  memoire  la
  carte peut etre configuree, comment autoriser l'utilisation de memoire
  partagee (si besoin), comment selectionner  et  mettre  en  oeuvre  la
  generation d'interruptions, etc.

  8.3.2.  Gestionnaire d'interruptions (Interrupt handler)

  Appele  par  le noyau quand la carte declenche une interruption.  A la
  responsabilite  de  determiner   pourquoi   la   carte   a   declenche
  l'interruption,  et d'agir en consequence.  Les conditions habituelles
  d'interruption sont l'arrivee de donnees, la fin  d'une  transmission,
  l'indication  de  conditions  d'erreur.  Vous avez besoin de connaitre
  les bits d'informations lies a une interruption afin de  pouvoir  agir
  en consequence.

  8.3.3.  Fonction de transmission (Transmit function)

  Est liee a dev->hard_start_xmit() et est appelee par le noyau quand ce
  dernier  desire   envoyer   des   donnees   par   l'intermediaire   du
  peripherique.  Envoie  les  donnees  sur  la  carte  et  declenche  la
  transmission.  Vous avez  besoin  de  savoir  comment  empaqueter  les
  donnees  et  comment les faire parvenir sur la carte (copie en memoire
  partagee, transfert sur les ports d'E/S, DMA?) et au bon  endroit  sur
  la  carte.   Puis  vous devez savoir comment dire a la carte d'envoyer
  les  donnees  sur  le  cable,  et   (eventuellement)   d'emettre   une
  interruption  quand  ce sera fini.  Quand le peripherique ne peut plus
  accepter  de  paquets  supplementaires,  il  doit  armer  le   drapeau
  dev->tbusy.   Quand  de la place est devenue disponible, en general au
  cours d'une interruption de fin de transmission, dev->tbusy doit  etre
  desarme  et  les niveaux superieurs doivent etre informes en utilisant
  mark_bh(INET_BH).

  8.3.4.  Fonction de reception (Receive function)

  Appelee par le gestionnaire d'interruption du  noyau  quand  la  carte
  indique  que  des donnees sont disponibles. Recupere les donnees de la
  carte, les empaquete dans  un  sk_buff  et  informe  le  noyau  de  la
  presence  des  donnees en effectuant un netif_rx(sk_buff).  Vouz devez
  savoir comment mettre en oeuvre le declenchement d'interruptions a  la
  reception   de   donnees,  comment  verifier  les  bits  d'information
  correspondant a la reception, et comment recuperer les donnees  depuis
  la carte (de nouveau par memoire partagee, ports d'E/S, DMA, etc.)

  8.3.5.  Fonction d'ouverture (Open function)

  Est  liee  a  dev->open.  Est  appelee  par  les  couches reseau quand
  quelqu'un fait ifconfig eth0 up - cela doit mettre le peripherique  en
  route  et  l'autoriser  a  recevoir et transmettre des donnees.  Toute
  incantation speciale liee a l'initialisation et qui n'aurait  pas  ete
  realisee dans la sequence de detection (autoriser la generation d'IRQ,
  etc.) viendra ici.

  8.3.6.  Fonction de fermeture (facultative) (Close function)

  Met  la carte dans un etat sain quand quelqu'un effectue ifconfig eth0
  down.  Doit liberer les IRQ et  les  canaux  DMA  si  le  materiel  le
  permet,  et  eteindre  tout  ce  qui  pourrait economiser de l'energie
  (comme le transmetteur ).

  8.3.7.  Autres fonctions

  Des choses comme une fonction de reinitialisation, afin  que,  si  les
  choses  se  degradent,  le  pilote  puisse essayer de reinitialiser la
  carte en dernier recours. Generalement  fait  quand  une  transmission
  depasse  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.

  8.4.  Les interruptions et Linux

  Il  y  a  deux genres de gestionnaires d'interruptions sous Linux: les
  rapides et les lents. Vous decidez a quel type  appartient  celui  que
  vous   installez   a   l'aide  des  informations  que  vous  passez  a
  irqaction(). Les rapides, comme le gestionnaire d'interruption du port
  serie,  tournent  avec  _toutes_  les  interruptions  interdites.  Les
  gestionnaires normaux, comme ceux  des  pilotes  de  cartes  Ethernet,
  tournent  avec  les  autres interruptions (que celle(s) qu'ils sont en
  train de gerer, NDT) autorisees.

  La structure d'interruption est a deux niveaux.   La  partie  `rapide'
  s'occupe  des  registres  de  peripherique,  enleve  les  paquets,  et
  eventuellement arme un drapeau.  Apres  cela,  et  une  fois  que  les
  interruptions  ont  ete re-autorisees, la partie lente est executee si
  le drapeau est arme.

  Le drapeau entre les deux partie est arme par:

       mark_bh(INET_BH);

  En general ce drapeau est arme a l'interieur de dev_rint() pendant une
  interruption  de  reception  de  paquet,  et  arme  directement par le
  gestionnaire de  peripherique  pendant  une  interruption  de  fin  de
  transmission.

  Vous   vous   demandez   peut-etre  pourquoi  tous  les  gestionnaires
  d'interruption ne peuvent pas tourner en `mode normal' avec les autres
  interruptions  autorisees.  Ross Biro utilise le scenario suivant pour
  illustrer le probleme:

  o  Vous recevez une interruption du port serie, et vous commencez a la
     traiter.  L'interruption du port serie est maintenant masquee.

  o  Vous recevez une interruption reseau et vous commencez a transferer
     un paquet de taille maximale de 1500 octets depuis la carte.

  o  Un autre caractere arrive sur le port serie, mais les interruptions
     sont masquees!

  La  structure d'interruption `rapide' resoud ce probleme en autorisant
  les gestionnaires d'interruption a duree limitee   a  s'executer  sans
  risque  de  laisser leurs lignes d'interruption masquees par une autre
  demande d'interruption.

  Une autre distinction entre les gestionnaires  d'interruption  rapides
  et  lents est constituee par les arguments passes au gestionnaire.  Un
  gestionnaire `lent' est defini comme

  ______________________________________________________________________

                  static void
                  handle_interrupt(int reg_ptr)
                  {
                      int irq = -(((struct pt_regs *)reg_ptr)->orig_eax+2);
                      struct device *dev = irq2dev_map[irq];
                  ...
  ______________________________________________________________________

  Tandis qu'un gestionnaire rapide  obtient  directement  le  numero  de
  l'interruption:

  ______________________________________________________________________

                  static void
                  handle_fast_interrupt(int irq)
                  {
                  ...
  ______________________________________________________________________

  Enfin,  un  aspect  important  des performances reseau est le temps de
  latence. La seule carte qui resoud vraiment ce probleme est la  3c509,
  qui  permet  le  declenchement  d'une  interruption  predictive.  Elle
  fournit un reglage du temps de reponse a une interruption afin que  le
  pilote  puisse  regler  precisement  combien  de  temps a l'avance une
  interruption est generee.

  8.5.  Programmation des puces Intel (i82586 et i82593)

  Ces puces sont utilisees dans bon nombre de cartes,  plus  precisement
  la 3c507 ('86), l'Intel EtherExpress 16 ('86), l'exos205t de Microdyne
  ('86), le Z-Note ('93), et la ni5210 de Racal-Interlan ('86).

  Russ Nelson ecrit: La plupart des cartes basees sur la  82586  peuvent
  reutiliser  un peu de leur code. Plus, en fait, que les adapatateurs a
  base de 8390. Il n'existe que trois differences entre elles:

  o  Le code pour obtenir l'adresse Ethernet,

  o  Le code pour modifier CA sur la 82586, et

  o  Le code pour reinitialiser la 82586.

  L'Intel EtherExpress 16 est une exception, car elle mappe la 82586 sur
  des  adresses  d'entree/sortie.  Oui,  elle  mappe sur des E/S.  C'est
  plutot heteroclite, mais cela fonctionne.

  Garrett Wollman avait fait un pilote AT&T  pour  BSD  qui  utilise  le
  copyright  BSD.  La derniere version que j'ai (Septembre 92) n'utilise
  qu'un seul tampon de transmission. Vous pouvez  et  meme  devez  faire
  mieux  que  ca si vous avez la memoire qu'il faut.  L'AT&T et la 3c507
  l'ont; la ni5210 ne l'a pas.

  Les gens de chez Intel m'ont donne une indication vraiment  importante
  sur  la  facon  de  placer  dans la file d'attente plusieurs paquets a
  transmettre. Vous mettez en place une liste  de  blocs  (NOP->  XMIT->
  NOP->  XMIT->  NOP->  XMIT->  debut),  puis  vous  mettez  le pointeur
  `suivant' de chacun des blocs  NOP  vers  eux-memes.  Maintenant  vous
  demarrez l'unite de commande sur cette chaine. Elle va continuellement
  travailler sur le premier  block  NOP.   Pour  transmettre  le  paquet
  suivant,  vous le deposez dans le block XMIT (transmit - transmission)
  suivant, et vous faites pointer le NOP precedent vers  lui.  De  cette
  facon,   vous   n'avez  pas  besoin  d'attendre  que  la  transmission
  precedente soit finie, vous  pouvez  placer  dans  la  file  d'attente
  plusieurs  paquets  sans ambigueite sur le fait de savoir s'il va etre
  accepte, et vous pouvez eviter le delai lie au demarrage de l'unite de
  commande.'

  8.6.  Informations techniques de 3Com

  Si  vous  etes  interesse(e) par l'ecriture de pilotes pour les cartes
  3Com, vous pouvez obtenir  de  la  documentation  technique  de  3Com.
  Cameron a ete suffisamment gentil pour nous dire comment y parvenir:

  Les  adaptateurs  Ethernet de 3Com sont documentes pour les auteurs de
  pilotes dans nos `References Techniques' (Technical References,  TRs).
  Ces  manuels  decrivent  les  interfaces du programmeur avec la carte,
  mais  elles  ne  parlent   pas   des   diagnostics,   des   programmes
  d'installation, etc., que l'utilisateur final peut voir.

  Le  departement  marketing  de la Division Adaptateur Reseaux (Network
  Adapter Division) est responsable de la diffusion des TRs.   Pour  que
  ce  programme  reste  efficace,  nous  le centralisons dans une entite
  appele `CardFacts'. CardFacts est un systeme telephonique  automatise.
  Vous  l'appelez  avec  un  telephone  a  frequences vocales et il vous
  envoie  des  choses  par  telecopie.   Pour  obtenir  un  TR,  appelez
  CardFacts au 408-727-7021.

  (NDT:  Cela  ne fonctionne qu'aux Etats-Unis.)  Demandez le formulaire
  de commande du  developpeur  (Developer's  Order  Form),  le  document
  numero  9070.  Ayez  votre  numero  de  fax  sous la main lorsque vous
  appelez.  Completez  le  formulaire  de  commande  et  envoyez-le  par
  telecopie  au  408-764-5004.  Les manuels sont expedies par le service
  J+2 de Federal Express.

  Apres avoir obtenu un manuel, si  vous  ne  parvenez  toujours  pas  a
  savoir  comment  programmer la carte, essayez notre BBS `CardBoard' au
  1-800-876-3266,  et  si  vous  ne  pouvez  pas  le  faire,  ecrivez  a
  Andy_Chan@3Mail.3com.com  et  demandez-lui une autre solution. Si vous
  avez un probleme vraiment bloquant auquel personne n'a  encore  trouve
  de   solution,   le   gars   qui   a   besoin   de   le   savoir   est
  Steve_Lebus@3Mail.3com.com.

  Il y a des gens ici qui pensent que nous sommes trop liberaux avec les
  manuels, et qui cherchent des preuves que le systeme est trop onereux,
  ou prend trop de temps et d'effort. C'est pourquoi  il  est  important
  d'essayer  d'utiliser CardFacts avant que vous ne commenciez a appeler
  ou a envoyer des messages aux gens que j'ai nommes ici.

  Il y a meme des gens qui pensent que nous devrions etre comme  Diamond
  et  Xircom,  d'exiger  un  `partenariat'  resserre avec les auteurs de
  pilotes pour empecher que  des  pilotes  de  faibles  performances  ne
  soient ecrits. Jusqu'a present, les consommateurs de 3Com ont ete tres
  bons sur ce point, et il n'y a pas  de  probleme  avec  le  niveau  de
  demande que nous avons obtenu. Nous avons besoin que votre cooperation
  et votre retenue continuent pour le conserver ainsi.

          Cameron Spitzer, 408-764-6339
          3Com NAD
          Santa Clara
          travail: camerons@nad.3com.com
          maison:  cls@truffula.sj.ca.us

  8.7.

  Notes sur les cartes basees sur la puce PCnet / LANCE d'AMD

  La  puce LANCE (Local Area Network Controller for Ethernet, Controleur
  Reseau Local pour Ethernet) d'AMD constituait l'offre initiale,  et  a
  depuis ete remplacee par la puce `PCnet-ISA', aussi connue en tant que
  79C960.  La 79C960, une puce relativement recente d'AMD, est le  coeur
  de  nombreuses nouvelles cartes qui sont produites aujourd'hui.  Notez
  que le nom `LANCE' est reste, et certaines personnes se referent a  la
  nouvelle  puce en utilisant l'ancien nom.  Dave Roberts de la Division
  des  Produits  Reseaux  (Network  Products  Division)  d'AMD   a   ete
  suffisamment  gentil  pour  nous  fournir  les  informations suivantes
  concernant cette puce:

  `En ce qui concerne l'architecture elle-meme,  AMD  l'a  developpee  a
  l'origine  et l'a reduite a une seule puce -- la PCnet(tm)-ISA -- il y
  a plus d'un an. Elle se vend comme des petits pains depuis.

  Fonctionnellement, elle est  equivalente  a  une  NE1500.  Le  jeu  de
  registres est identique a 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 meme a la base.  Initialement  Novell  l'a  appele  la  2100,  mais
  ensuite  a essaye de distinguer entre cartes coax et 10Base-T. Tout ce
  qui etait purement 10Base-T devait  etre  numerote  dans  l'intervalle
  1500. C'est la seule difference.

  De  nombreuses societes offrent des produits bases sur la PCnet-ISA, y
  compris HP, Racal-Datacom, Allied  Telesis,  Boca  Research,  Kingston
  Technology,  etc.   Les  cartes  sont a la base les memes, excepte que
  certains constructeurs ont ajoute des fonctionnalites `sans-cavaliers'
  (`jumperless')  qui  permettent  a  la  carte  d'etre  configuree  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  ecrire  des pilotes pour la
  plupart des cartes basees sur la  puce  PCnet-ISA  peut  se  contenter
  d'obtenir  la  documentation  technique  aupres  d'AMD.  Appelez notre
  centre de distribution documentaire au (800)222-9323  et  demandez  la
  documentation de l'Am79C960, PCnet-ISA. Elle est gratuite.

  Un  moyen  rapide  de comprendre si la carte est une carte `brute' est
  simplement de  la  regarder.  Si  elle  est  brute,  elle  doit  juste
  comporter  une grosse puce, un quartz, une petite PROM d'adresse IEEE,
  eventuellement un support pour une ROM de demarrage, et un  connecteur
  (1,  2  ou  3,  selon  les options de media offertes).  Notez que s'il
  s'agit d'une carte coax, elle  comportera  aussi  quelques  composants
  pour  le  transceiver,  mais  ils devraient etre pres du connecteur et
  eloignes de la PCnet-ISA.'

  Des informations concernant la puce LANCE se trouvent  aussi  dans  le
  fichier lance.c qui est inclus dans le noyau standard.

  Une   note   pour  les  bidouilleurs  potentiels  de  cartes  est  que
  differentes implementations de la LANCE effectuent le `redemarrage' de
  differentes  facons.  Certaines reprennent ou elles s'etaient arretees
  dans l'anneau, et d'autres demarrent directement au debut de l'anneau,
  comme  si elles venaient d'etre initialisees.  C'est important lorsque
  vous mettez en place la liste pour le multicast.

  8.8.  Multicast et Mode `Promiscuous'

  Une  des  autres  choses  sur  lesquels   Donald   a   travaille   est
  l'implementation  des  points  d'entree  pour  le multicast et le mode
  `promiscuous'. Tous les pilotes  ISA  publies  (c'est-a-dire  pas  les
  pilotes  au stade `alpha') supportent aujourd'hui le mode promiscuous.

  Donald  ecrit:  `Au  debut  je  prevoyais  de   le   faire   lors   de
  l'implementation  soit  de  /dev/*  soit  de  l'interface DDI, mais ce
  n'etait pas vraiment la bonne facon de faire. Nous ne  devons  activer
  les  modes multicast ou promiscuous que lorsque quelque chose souhaite
  regarder les paquets, et le desactiver  quand  cette  application  est
  finie,  rien de tout cela n'etant vraiment lie a la mise en route ou a
  l'arret de la partie materielle.

  Je  commencerai  par   parler   du   mode   `promiscuous',   qui   est
  conceptuellement  facile a implementer. Pour la plupart des materiels,
  vous n'avez qu'a positionner un bit de registre, et  a  partir  de  ce
  moment-la  vous  obtenez tous les paquets qui passent sur le fil. Bon,
  ce n'est pas vraiment aussi simple que cela; pour  certains  materiels
  vous  devez  arreter  la  carte  (en  perdant potentiellement quelques
  paquets), la reconfigurer,  puis  la  reactiver.  C'est  degoutant  et
  risque,  mais la solution alternative semble etre d'obliger toutes les
  applications a s'enregistrer avant que  vous  ne  demarriez  la  carte
  Ethernet au moment du demarrage du noyau.

  Ok, ca c'est facile, donc je passe a quelque chose qui n'est pas aussi
  evident: le multicast. On peut le realiser de deux facons:

  1. Utiliser le mode promiscuous, et  un  filtre  de  paquet  comme  le
     filtre  de paquet de Berkeley (Berkeley packet filter, BPF). Le BPF
     est un langage a pile de  recherche  de  motifs  (pattern  matching
     stack),  avec  lequel  vous  ecrivez  un  programme qui extrait les
     adresses qui vous interessent. Son  avantage  est  qu'il  est  tres
     general et programmable. Son inconvenient est qu'il n'existe pas de
     moyen general pour le noyau d'eviter d'avoir a mettre en  route  le
     mode  promiscuous et de passer chaque paquet qui circule sur le fil
     a travers tous les filtres de  paquets  qui  se  sont  enregistres.
     Consultez ``Le Berkeley Packet Filter'' pour plus d'informations.

  2. Utiliser  le  filtre  multicast  que  la plupart des puces Ethernet
     possedent.

  Je devine que je devrais donner une liste de ce que quelques cartes ou
  puces Ethernet fournissent:
          Puce/carte  Promiscuous  Filtre Multicast
          -----------------------------------------
          Seeq8001/3c501  Oui     Filtre binaire (1)
          3Com/3c509      Oui     Filtre binaire (1)
          8390            Oui     Hashage a six bits Autodin II (2) (3)
          LANCE           Oui     Hashage a six bits Autodin II (2) (3)
          i82586          Oui     Hashage a six bits Autodin II cache (2) (4)

  1. Ces  cartes  pretendent avoir un filtre, mais il s'agit d'un simple
     oui/non `accepte tous les paquets multicast', ou  `n'accepte  aucun
     paquet multicast'.

  2. AUTODIN  II est le polynome standard de controle Ethernet (somme de
     controle/checksum CRC). Dans ce principe,  les  adresses  multicast
     sont  hashees  et  recherchees dans une table de hashage. Si le bit
     correspondant est  active,  ce  paquet  est  accepte.  Les  paquets
     Ethernet  sont  concus de telle facon que la partie materielle pour
     realiser ceci est triviale -- vous memorisez juste (habituellement)
     six  bits du circuit CRC (qui est necessaire de toute facon pour la
     verification d'erreur) apres 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).

  3. Ces puces utilisent le hashage a six bits, et  necessitent  que  la
     table  soit  calculee  et  chargee par l'hote. Cela signifie que le
     noyau doit comprendre le code pour le CRC.

  4. Le 82586 utilise le hashage a six bits de facon  interne,  mais  il
     calcule   la  table  de  hashage  lui-meme  a  partir  d'une  liste
     d'adresses multicast a accepter.

  Notez qu'aucune de ces puces ne realise un filtrage parfait,  et  nous
  avons  encore besoin d'un module de niveau intermediaire pour realiser
  le filtrage final.  Notez  aussi  que  dans  chaque  cas  nous  devons
  conserver  une  liste  complete  des adresses multicast acceptees pour
  recalculer la table de hashage quand elle change.

  Ma premiere approche du support de niveau intermediaire est  detaillee
  dans l'esquisse de pilote skeleton.c.

  Cela ressemble a ce qui suit:

  ______________________________________________________________________
          #ifdef HAVE_MULTICAST
          static void set_multicast_list(struct device *dev, int num_addrs,
                           void *addrs);
          #endif
          .
          .

          ethercard_open() {
          ...
          #ifdef HAVE_MULTICAST
                  dev->set_multicast_list = &set_multicast_list;
          #endif
          ...

          #ifdef HAVE_MULTICAST
          /* Set or clear the multicast filter for this adaptor.
             num_addrs -- -1      Promiscuous mode, receive all packets
             num_addrs -- 0       Normal mode, clear multicast list
             num_addrs > 0        Multicast mode, receive normal and
                  MC packets, and do best-effort filtering.
           */
          /* Positionne ou vide le filtre multicast pour cet adaptateur.
             num_addrs -- -1    Mode promiscuous, recoit tous les paquets
             num_addrs -- 0     Mode normal, efface la liste multicast
             num_addrs > 0      Mode multicast, recoit les paquets normaux
                  et les paquets multicast, et filtre du mieux possible.
           */
          static void
          set_multicast_list(struct device *dev, int num_addrs, void *addrs)
          {
          ...
  ______________________________________________________________________

  Tous commentaires, critiques, etc. sont les bienvenus.''

  8.9.

  Le filtre de paquet de Berkeley (Berkeley Packet Filter -- BPF)

  L'idee generale pour les developpeurs est que la fonctionnalite du BPF
  ne  doit  pas etre fournie par le noyau, mais doit se trouver dans une
  librairie de compatibilite (dont on espere qu'elle servira peu).

  Pour ceux qui ne seraient pas au  courant:  BPF  (le  Berkeley  Packet
  Filter)  est  un  mecanisme  destine a specifier aux couches reseau du
  noyau quels paquets vous interessent. Il est implemente sous la  forme
  d'un  interpreteur  d'un  langage  a pile specialise construit dans un
  niveau bas du code reseau. Une application passe  un  programme  ecrit
  dans  ce langage au noyau, et le noyau execute le programme sur chaque
  paquet entrant. Si le noyau possede plusieurs applications BPF, chaque
  programme est execute sur chaque paquet.

  Le  probleme  est  qu'il  est difficile de deduire quel type de paquet
  interesse reellement l'application a partir du programme de  filtrage,
  donc  la  solution  est  de  toujours executer le filtre.  Imaginez un
  programme qui enregistre un programme BPF  pour  extraire  un  flux  a
  faible taux de donnees envoye a une adresse multicast.  La plupart des
  cartes Ethernet possedent un filtre  d'adresses  multicast  implemente
  sous  la  forme  d'une  table  de  hashage  a 64 entrees qui ignore la
  plupart des  paquets  multicast  non  souhaites,  donc  les  capacites
  existent  pour  faire de cette operation une operation peu couteuse en
  ressources. Mais avec le BPF, le noyau doit passer l'interface en mode
  promiscuous,  recevoir  _tous_ les paquets, et les passer a travers ce
  filtre. C'est un travail,  a  propos,  qu'il  est  tres  difficile  de
  comptabiliser dans le processus qui a demande les paquets.

  9.  Faire du reseau avec un portable

  Il n'existe actuellement que peu de moyens de mettre votre portable en
  reseau. Vous pouvez utiliser le code SLIP  (et  tourner  aux  vitesses
  d'une liaison serie); vous pouvez acheter l'un des rares portables qui
  comportent une carte Ethernet compatible NE2000; vous  pouvez  obtenir
  un  portable avec un slot PCMCIA supporte integre; vous pouvez obtenir
  un portable avec une station de bureau et y mettre une carte  Ethernet
  ISA; ou vous pouvez utiliser un adaptateur Ethernet sur port parallele
  comme le DE-600 de D-Link.

  9.1.  Utiliser SLIP (Serial Line IP, IP sur lien serie)

  C'est la solution la moins chere, mais de loin la plus  difficile.  En
  plus,  vous  n'obtiendrez pas des taux de transfert tres eleves. Comme
  SLIP n'est pas vraiment lie aux cartes Ethernet, nous  n'en  parlerons
  pas plus ici. Consultez le NET-2 Howto.

  9.2.  NE2000 integree

  Cette  solution  limite severement vos choix de portable et est plutot
  chere. Soyez sur(e) de lire les specifications attentivement, car vous
  pourriez  decouvrir que vous devrez acheter un transceiver additionnel
  non-standard pour pouvoir mettre reellement la machine sur un  reseau.
  Une  bonne idee est de demarrer le portable avec un noyau qui comporte
  le pilote ne2000, et  de  s'assurer  que  la  carte  est  detectee  et
  fonctionne avant de passer a la caisse.

  9.3.  Support PCMCIA

  Comme  ce  domaine  du  developpement sous Linux est plutot recent, je
  vous suggererais de vous inscrire a la  liste  de  diffusion  LAPTOPS.
  Consultez  ``les  listes  de  diffusion...''   qui decrit comment vous
  inscrire a une liste.

  Essayez de  determiner  exactement  de  quel  materiel  vous  disposez
  (c'est-a-dire  le fabricant de la carte, le fabricant du controleur de
  puces PCMCIA) puis demandez sur la liste  LAPTOPS.  En  tout  etat  de
  cause,  ne  vous attendez pas a ce que les choses soient tres simples.
  Attendez-vous a chercher et a tourner un peu en rond,  a  patcher  les
  noyaux,  etc.  Peut-etre,  un  jour, vous serez capable de taper `make
  config' 8-)

  A l'heure actuelle, les deux jeux de puces PCMCIA qui sont utilisables
  avec Linux sont le TCIC/2 de Databook et l'i82365 d'Intel.

  Il  existe  un certain nombre de programmes sur tsx-11.mit.edu dans le
  repertoire  /pub/linux/packages/laptops/  qui  pourront   se   reveler
  utiles.

  (NDT:  Bien  entendu,  le  lecteur  francais  se rapportera a l'un des
  miroirs       de        tsx-11,        comme        par        exemple
  ftp://ftp.lip6.fr/pub/linux/tsx-11/packages/laptops/.)

  Cela  va  des  pilotes  pour cartes Ethernet PCMCIA aux programmes qui
  communiquent avec la puce du controleur PCMCIA. Notez que ces  pilotes
  sont  en  general  lies  a une puce PCMCIA specifique (c'est-a-dire la
  82365 d'Intel ou la TCIC/2).

  Pour les cartes compatibles NE2000,  certaines  personnes  ont  reussi
  juste en configurant la carte sous DOS, puis en demarrant Linux depuis
  l'invite de commande DOS via loadlin.

  Pour ceux d'entre vous qui lisent ce document sur le WWW, vous  pouvez
  essayer:

       La      page      PCMCIA      de     Donald     <http://ces-
       dis.gsfc.nasa.gov/linux/pcmcia.html>

  De toute facon, le probleme des pilotes PCMCIA n'est pas specifique au
  monde  Linux.  Ca a ete un vrai desastre dans le monde MS-DOS. Dans ce
  monde, les gens s'attendent a ce que le materiel fonctionne  s'ils  se
  contentent  de  lire  le  manuel.  Ils  ne  s'attendent pas a ce qu'il
  fonctionne  en  presence  d'une  partie   materielle   ou   logicielle
  etrangere, ou qu'il fonctionne de facon optimale, mais ils s'attendent
  a ce que le logiciel vendu avec le produit fonctionne.  La plupart des
  adaptateurs PCMCIA ne passent meme pas ce test.

  Les  choses  evoluent  pour  les  utilisateurs Linux qui souhaitent un
  support PCMCIA, car des progres substantiels ont ete realises.  Un des
  pionniers de ces efforts est David Hinds. Son dernier paquetage PCMCIA
  peut  etre  obtenu  sur  cb-iris.stanford.edu   dans   le   repertoire
  /pub/pcmcia/.  Cherchez  un fichier comme pcmcia-cs-X.Y.Z.tgz ou X.Y.Z
  est le dernier numero de version. Vous devriez aussi le trouver sur le
  site tsx-11.mit.edu (ou son miroir le plus proche, NDT).

  Notez  que le logiciel d'acces 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 employe.

  9.4.  Carte Ethernet ISA dans la station de bureau.

  Les stations de bureau (docking stations en anglais, ou  encore  dock,
  NDT)  coutent typiqement environ 1500 francs et fournissent deux slots
  ISA pleine-taille, deux ports serie et un port parallele.  La  plupart
  des  stations de bureau sont alimentees par les batteries du portable,
  et quelques unes permettent d'ajouter  des  batteries  supplementaires
  dans  la  station  de  bureau si vous utilisez des cartes ISA courtes.
  Vous pouvez ajouter une carte  Ethernet  pas  chere  et  profiter  des
  performances d'Ethernet a pleine vitesse.

  9.5.  Adaptateurs de poche et sur port parallele.

  Les  adaptateurs  Ethernet  `de  poche' peuvent aussi repondre a votre
  besoin. Jusque recemment  ils  coutaient  en  fait  plus  cher  qu'une
  station de bureau et une carte Ethernet bon marche, et la plupart vous
  attachaient a une alimentation  electrique  en  brique.   Aujourd'hui,
  vous  pouvez  choisir  entre  celle de D-Link ou celle de RealTek.  La
  plupart des autres societes traitent  l'information  de  programmation
  comme  un  secret  de  fabrication,  donc le support sera lent a venir
  (s'il vient jamais!).   Xircom  (voir  ``Xircom'')  apparemment  donne
  maintenant ses specifications, mais personne ne travaille actuellement
  sur un pilote.

  Notez que la vitesse de transfert ne sera pas aussi importante que  ca
  (peut-etre 200 Ko/s en pointe?) a cause des limitations de l'interface
  du port parallele.

  Consultez ``DE-600 / DE-620'' et ``RealTek'' pour les  adaptateurs  de
  poche utilisables sous Linux.

  Vous  pouvez parfois eviter la brique avec les adaptateurs en achetant
  ou en fabriquant un cable qui prend l'alimentation sur le port clavier
  du portable (voir ``alimentation du clavier'').

  10.  Questions diverses.

  Tout  ce  qui se rapporte a Ethernet et qui ne rentrait pas ailleurs a
  fini ici. Cela n'est peut-etre pas interessant ou ne rentre  pas  bien
  dans le cadre du document, mais c'est la, un point c'est tout.

  10.1.  Passage des arguments Ethernet au noyau

  Voici  deux  commandes generiques du noyau qui peuvent etre passees au
  noyau au moment du demarrage. Vous pouvez le faire avec LILO, loadlin,
  ou  tout  autre  utilitaire  de  demarrage  qui  accepte des arguments
  optionnels.

  Par exemple, si la commande etait `blabla'  et  qu'elle  attend  trois
  arguments  (disons  123,  456  et  789), alors, avec LILO, vous pouvez
  taper au demarrage:

  LILO: linux blabla=123,456,789

  Note: les E/S et les IRQ des cartes PCI sont assignees par le BIOS  au
  demarrage.  Cela signifie que tout argument de demarrage pour l'IRQ ou
  les ports d'entree/sortie d'une carte PCI est generalement ignore.

  Pour plus d'information sur les (et une liste complete des)  arguments
  de demarrage, veuillez consulter le

       BootPrompt-HOWTO     <http://sunsite.unc.edu/mdw/HOWTO/Boot-
       Prompt-HOWTO.html>

  10.1.1.  La commande ether

  Sous sa forme la plus generique, elle ressemble a quelque chose comme:

       ether=IRQ,ADR_DE_BASE,PARAM_1,PARAM_2,NOM

  Tous  les arguments sont optionnels. Le premier argument non-numerique
  est considere comme le NOM.

  IRQ: Evident.  Une valeur d'IRQ de `0' (habituellement la  valeur  par
  defaut)  signifie  affectation automatique de l'IRQ. C'est un accident
  de l'Histoire que le  parametre  d'IRQ  soit  en  premier  plutot  que
  l'adr_de_base  --  cela  sera  corrige  lorsque  quelque chose d'autre
  changera.
  ADR_DE_BASE: Evident aussi.  Une  valeur  de  `0'  (habituellement  la
  valeur par defaut) signifie de tester une liste d'adresses specifiques
  a ce type de carte pour essayer de detecter une carte Ethernet.

  PARAM_1:  Utilise  a  l'origine  comme  une  valeur  qui  passe  outre
  l'adresse  de  depart  de  la  zone  memoire pour une carte Ethernet a
  memoire partagee, comme la WD80*3.   Certains  pilotes  utilisent  les
  quatre  bits  de  poids faible de cette valeur pour fixer le niveau de
  message de debogage.  0 -- defaut, 1-7 -- niveaux 1 a 7  (7  etant  le
  niveau  le  plus  bavard), 8 -- niveau 0 (pas de messages).  Le pilote
  LANCE utilise les quatre bits de poids faible  de  cette  valeur  pour
  selectionner  le canal DMA. Sinon il utilise l'affectation automatique
  du DMA.

  PARAM_2: Le pilote 3c503 l'utilise pour choisir entre  le  transceiver
  interne  et  le  transceiver  externe.   0 -- defaut/interne, 1 -- AUI
  externe.  Les cartes E21XX de Cabletron utilisent les quatre  bits  de
  poids faible de PARAM_2 pour choisir le support physique. Sinon il est
  detecte automatiquement.

  NOM:  Selectionne  le  peripherique  reseau  auquel  les  valeurs   se
  referent.   Le  noyau standard utilise les noms `eth0', `eth1', `eth2'
  et `eth3' pour les cartes Ethernet attachees au bus,  et  `atp0'  pour
  l'adaptateur  `de poche' sur port parallele.  Le pilote ARCnet utilise
  le nom `arc0'.  Le comportement par defaut est  de  tester  une  seule
  carte  Ethernet  pour `eth0'.  Vous ne pouvez activer plusieurs cartes
  qu'en fixant  de  facon  explicite  leur  adresse  de  base  avec  les
  parametres  de  LILO.   Le  noyau  1.0 considerait les cartes Ethernet
  basees sur la puce LANCE comme un cas special. Les arguments  de  LILO
  etaient  ignores,  et  les  cartes  LANCE recevaient toujours des noms
  `eth<n>' en commencant a  `eth0'.  Les  cartes  supplementaires,  non-
  LANCE,  devaient  etre  affectees a `eth<n+1>', et le test habituel de
  `eth0'  devait  alors  etre  desactive  avec   quelque   chose   comme
  `ether=0,-1,eth0'. (Oui, c'est bogue.)

  10.1.2.  La commande reserve

  Cette  autre  commande  LILO est utilisee exactement comme la commande
  `ether=' ci-dessus, c'est-a-dire que l'on ajoute son nom  aux  options
  specifiees dans lilo.conf:

       reserve=IO-base,extent{,IO-base,extent...}

  Sur certaines machines, il peut etre necessaire d'empecher les pilotes
  de peripherique de tester des peripheriques (auto-detection) dans  une
  zone specifique. Cela peut etre le cas a cause d'un materiel mal concu
  qui fige le demarrage (comme certaines cartes Ethernet), d'un materiel
  qui  est  identifie par erreur, d'un materiel dont l'etat a ete change
  par une  procedure  de  detection  precedente,  ou  plus  encore  d'un
  materiel que vous ne souhaitez pas voir initialise par le noyau.

  L'argument  de  demarrage reserve repond a cette attente en specifiant
  une region de port d'E/S qui ne doit pas etre  testee.   Cette  region
  est  reservee  dans la table d'enregistrement des ports du noyau comme
  si un peripherique avait deja ete trouve dans cette region. Notez  que
  ce  mecanisme  ne devrait pas etre necessaire sur toutes les machines.
  C'est seulement lorsqu'il y a un probleme ou un cas  special  que  son
  utilisation peut se reveler necessaire.

  Les  ports  d'E/S  dans  la  zone  specifiee  sont proteges contre les
  procedures de detection de peripheriques. Nous avons montre  que  cela
  est  necessaire  lorsqu'un  pilote  se bloque sur une carte NE2000, ou
  identifie de facon erronee un autre peripherique comme etant le  sien.
  Un  pilote  de  peripherique  correct  ne  devrait pas tester une zone
  reservee, a moins  qu'un  autre  argument  de  demarrage  ne  specifie
  explicitement  qu'il doive le faire sur cette zone.  Cela implique que
  reserve sera le  plus  souvent  utilise  avec  un  autre  argument  de
  demarrage. Donc si vous specifiez une zone de reserve pour proteger un
  peripherique donne, vous devez  generalement  specifier  explicitement
  une detection pour ce peripherique. La plupart des pilotes ignorent la
  table d'enregistrement des  ports  si  on  leur  fournit  une  adresse
  explicite.

  Par exemple, la ligne de demarrage

       LILO: linux  reserve=0x300,32  ether=0,0x300,eth0

  oblige  tous les peripheriques a l'exception des pilotes Ethernet a ne
  pas tester la plage 0x300-0x31f.

  Comme d'habitude avec les specificateurs de demarrage, il  existe  une
  limite  de  11  parametres,  donc vous ne pouvez specifier que 5 zones
  reservees  par  mot-cle  reserve.   Plusieurs  specificateurs  reserve
  fonctionneront si vous avez une requete inhabituellement compliquee.

  10.2.  Utilisation des pilotes Ethernet comme modules

  Consultez  la page de manuel de insmod(8) pour des informations sur le
  passage des arguments au module lors de son chargement.   La  commande
  lsmod   vous  montrera  quels  modules  sont  charges,  et  rmmod  les
  supprimera.

  Actuellement, tous les modules sont  places  dans  le  sous-repertoire
  modules  dans  votre  arborescence  du noyau Linux (en general sous la
  forme de liens symboliques). Pour generer reellement les modules, vous
  devez  taper  make modules apres avoir fini de construire correctement
  le  noyau.  Les  versions  anterieures  du   noyau   les   compilaient
  automatiquement,  ce qui n'etait pas sympa pour ceux qui compilent sur
  des machines 386sx-16 avec 4Mo.

  La plupart des modules  acceptent  des  arguments  comme  io=0x340  et
  irq=12 sur la ligne de commande d'insmod.  Il est FORTEMENT RECOMMANDE
  que  vous  fournissiez  ces  parametres  pour  eviter   la   detection
  automatique  de  la  carte.  A  la difference des peripheriques PCI et
  EISA, il n'existe pas de moyen vraiment sur de realiser une  detection
  automatique  des peripheriques ISA, et cela doit donc etre evite quand
  on utilise les pilotes sous la forme de modules chargeables.

  Une liste de tous les parametres que chaque module accepte  peut  etre
  trouvee dans le fichier:

  /usr/src/linux/Documentation/networking/net-modules.txt

  Vous  avez  interet a le lire pour trouver quelles options vous pouvez
  utiliser pour votre carte specifique.

  Une fois que vous avez devine les arguments  (les  options)  que  vous
  allez utiliser, vous pouvez inserer le module en tapant sous root:

  ______________________________________________________________________
          insmod mod_name.o [io=val1[,val2,...]] [irq=val7[,val8,...]]
  ______________________________________________________________________

  Les  listes  de  valeurs separees par des virgules sont utilisees pour
  des  modules  qui  sont  capables  de  prendre  en  charge   plusieurs
  peripheriques  depuis un seul module, comme c'est le cas pour tous les
  pilotes 8390, et le pilote PLIP.

  Une fois qu'un module a  ete  insere,  vous  pouvez  l'utiliser  comme
  d'habitude,  et executer des commandes ifconfig. Si vous configurez le
  reseau au demarrage, assurez-vous que vos fichiers /etc/rc*  executent
  la(les) commande(s) insmod avant d'arriver a la commande ifconfig.

  Notez  aussi  qu'un  module  occupe  ne  peut  pas etre supprime. Cela
  signifie que vous devez faire un ifconfig  eth0  down  (desactiver  la
  carte Ethernet) avant de pouvoir supprimer le(s) module(s).

  10.2.1.  Cartes basees sur le 8390 comme modules

  La  liste  courante  des pilotes bases sur le 8390 est: 3c503, ac3200,
  e2100, hp, hp-plus, ne, smc-ultra and wd.  Ces  cartes  n'etaient  pas
  disponibles  comme modules pour les versions du noyau anterieures a la
  1.3.42 (cela n'inclut  pas  certains  des  pilotes  PCMCIA  distribues
  separement  (par  exemple le de-650) qui sont aussi bases sur le 8390,
  mais qui etaient disponibles sous la  forme  de  modules  depuis  deja
  quelques temps.)

  Si  vous  avez  une  carte basee sur la puce 8390, vous devrez inserer
  deux modules, 8390.o puis ensuite le module pour votre  carte.  Si  le
  support  pour  le  8390  a  ete integre dans votre noyau, vous n'aurez
  alors pas besoin d'inserer le  module  8390.   (Le  support  8390  est
  integre  des qu'une carte basee sur le 8390 doit etre integree dans le
  noyau.) Un petit cat /proc/ksyms | grep 8390 vous dira si  le  support
  8390 est present dans votre noyau.

  Pour  une  carte basee sur le 8390, vous devrez supprimer le module de
  la carte avant de supprimer le module 8390, puisque le module 8390 est
  utilise  par le module de la carte, et donc marque comme occupe (busy,
  en anglais).

  La serie des pilotes reseaux permet maintenant d'utiliser des systemes
  a  plusieurs  cartes  sans  charger  plusieurs  fois  le  meme  module
  (efficacite en occupation memoire!). Pour  cela,  specifiez  plusieurs
  valeurs separees par des virgules, comme dans:

  ______________________________________________________________________
          insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
  ______________________________________________________________________

  La  commande  ci-dessus  permet  a un seul et meme module de controler
  quatre cartes 3c503, les  cartes  2  et  4  utilisant  le  transceiver
  externe.

  Il  est  *FORTEMENT  RECOMMANDE*  que  vous  fournissiez  io=  au lieu
  d'utiliser la detection automatique. Si  un  argument  io=  n'est  pas
  fourni,  alors  les  pilotes  ISA  8390  indiqueront  que la detection
  automatique n'est pas recommandee, et feront, a contrecoeur  et  parce
  qu'il  le  faut, la detection pour une *SEULE CARTE* -- si vous voulez
  utiliser  plusieurs  cartes   vous   *devez*   fournir   un   argument
  io=0xNNN,0xQQQ,....

  Le  module  ne  est  une  exception a ce qui precede. Une carte NE2000
  comporte essentiellement une puce 8390, un bus de liaison et un peu de
  RAM.  A  cause  de  cela,  la  procedure  de  detection de ne est plus
  envahissante que les autres, et c'est pour cela qu'au  demarrage  nous
  nous  assurons  que  la detection de ne est faite en dernier parmi les
  cartes a base de 8390 (afin qu'elle ne marche pas sur les  platebandes
  d'autres  cartes  a  base de 8390).  Avec les modules, nous ne pouvons
  pas assurer que toutes les cartes a base de 8390 non-ne ont  deja  ete
  trouvees.   Par  consequent,  le  module  ne  NECESSITE qu'un argument
  io=0xNNN lui soit passe via  insmod.  Il  refusera  de  pratiquer  une
  detection automatique.

  Il  faut  aussi  noter  que l'affectation automatique des IRQ (``auto-
  IRQ'') n'est pas aussi sure durant l'agitation qui regne au niveau  de
  l'activite  des  interruptions sur une machine en ordre de marche. Des
  cartes comme la NE2000 qui ne peuvent obtenir la configuration de leur
  IRQ  depuis une EEPROM ou un registre de configuration se comporteront
  mieux si on leur fournit aussi un argument irq=M. Le fichier

       /usr/src/linux/Documentation/networking/net-modules.txt

  donne aussi la liste des facons dont la  configuration  des  interrup-
  tions  est  determinee pour les differentes cartes si une valeur irq=N
  n'est pas donnee.

  10.3.

  Les listes de diffusion et les groupes de news Linux

  Si vous avez des questions sur votre carte Ethernet, s'il  vous  plait
  LISEZ  ce document en premier. Vous pourrez aussi joindre le canal NET
  (reseau) des listes de  diffusion  Linux  en  envoyant  un  message  a
  majordomo@vger.rutgers.edu  pour  obtenir  de  l'aide  sur  les listes
  disponibles et la facon de les rejoindre.  (NDT:  envoyez  un  message
  contenant simplement le mot "help" a l'adresse indiquee.)

  Bien  plus,  gardez  a  l'esprit  que le canal NET ne concerne que les
  discussions sur le developpement  logiciel.  Les  questions  generales
  concernant  la  configuration  de  votre systeme doivent etre dirigees
  vers  comp.os.linux.setup  a  moins  que  vous  ne  soyez   activement
  implique(e)  dans  le developpement d'une partie du reseau pour Linux.
  Nous vous demandons s'il  vous  plait  de  respecter  cette  ligne  de
  conduite generale pour le contenu de vos messages.

  D'autre  part, les groupes de news comp.sys.ibm.pc.hardware.networking
  et comp.dcom.lans.ethernet doivent etre utilises  pour  des  questions
  qui ne sont pas specifiques a Linux.

  10.4.  Autres documents

  La  plupart  des  informations  que  vous  trouvez  dans  ce  document
  proviennent de messages sauvegardes des groupes de comp.os.linux.*, ce
  qui montre qu'il s'agit d'une source d'informations valable.  D'autres
  informations tres utiles proviennent de tout un tas de petits fichiers
  de Donald lui-meme.

  Bien  entendu,  si  vous  configurez  une carte Ethernet, vous voudrez
  configurer les logiciels que vous allez utiliser, et vous  lirez  pour
  cela le Howto NET-3.  Ou encore, si vous vous sentez pousser des ailes
  de  ``hacker'',  vous  pourrez  toujours  grapiller  des  informations
  supplementaires directement dans les fichiers sources des pilotes. Ils
  comportent en general un paragraphe ou  deux  qui  decrit  les  points
  importants, avant que le code ne demarre...
  Pour  ceux  d'entre  vous qui recherchent des informations qui ne sont
  pas specifiques a  Linux  (comme:  qu'est-ce  que  10BaseT,  qu'est-ce
  qu'AUI,  que  fait  un  hub, etc.) je vous recommande fortement la FAQ
  Ethernet (Ethernet-FAQ) qui est postee regulierement dans le groupe de
  news comp.dcom.lans.ethernet.  Vous pouvez aussi la recuperer sur tout
  site qui offre les FAQ, comme

       Les FAQ de Usenet  <ftp://ftp.lip6.fr/pub/doc/faq/usenet-by-
       hierarchy/>

  Vous  pouvez aussi consulter la `Page d'accueil d'Ethernet' pour ainsi
  dire, qui se trouve a l'URL suivante:

       La           page            d'accueil            d'Ethernet
       <http://wwwhost.ots.utexas.edu/ethernet/ethernet-home.html>

  10.5.  Contributions

  D'autres  personnes qui ont contribue (directement ou indirectement) a
  l'Ethernet-HOWTO, par ordre alphabetique:

          Ross Biro               <bir7@leland.stanford.edu>
          Alan Cox                <iialan@www.linux.org.uk>
          David C. Davies         <davies@wanton.enet.dec.com>
          Bjorn Ekwall            <bj0rn@blox.se>
          David Hinds             <dhinds@allegro.stanford.edu>
          Michael Hipp            <mhipp@student.uni-tuebingen.de>
          Mike Jagdis             <jaggy@purplet.demon.co.uk>
          Duke Kamstra            <kamstra@ccmail.west.smc.com>
          Russell Nelson          <nelson@crynwr.com>
          Cameron Spitzer         <camerons@NAD.3Com.com>
          Dave Roberts            <david.roberts@amd.com>
          Glenn Talbott           <gt@hprnd.rose.hp.com>

  Ces adresses de courrier electronique ne sont  intentionnellement  pas
  des  liens  `mailto'  afin  de proteger ces personnes de programmes de
  filtrage WWW qui alimentent des robots `spammeurs'.  Mille fois  merci
  a  ces  personnes,  et  a tous les autres testeurs non-mentionnes d'ou
  qu'ils soient.

  10.6.  Desistement de responsabilite et Copyright

  Ce document n'est pas la bible. Toutefois, il s'agit  certainement  de
  la  source  d'informations  la  plus  a jour que vous pourrez trouver.
  Personne n'est responsable de ce qui arrive a  votre  materiel  hormis
  vous-meme.  Si  votre carte Ethernet ou tout autre piece materielle de
  votre ordinateur part en  fumee  (...bien  que  ce  soit  pratiquement
  impossible!)  nous  ne  prenons  aucune responsabilite. LES AUTEURS NE
  SONT RESPONSABLES D'AUCUN DOMMAGE ENCOURU  DU  FAIT  D'ACTIONS  PRISES
  BASEES SUR LES INFORMATIONS COMPRISES DANS CE DOCUMENT.

  Ce  document  est  Copyright  (c) 1993-1997 by Paul Gortmaker.  Il est
  permis de faire et de distribuer des copies verbatim de  ce  manuel  a
  condition que la notice de copyright et que cette notice de permission
  soient preservees dans toutes les copies.

  Il est permis de copier et de distribuer des versions modifiees de  ce
  document  sous les memes conditions que la copie verbatim, a condition
  que cette notice de copyright soit incluse  exactement  telle  qu'elle
  est  dans  l'original,  et  que  le travail derive resultant, dans son
  integralite, soit distribue sous les termes d'une notice de permission
  identique a celle-ci.

  Il  est  permis  de  copier  et  de  distribuer  des traductions de ce
  document dans d'autres langues, sous  les  memes  conditions  que  ci-
  dessus pour les versions modifiees.

  Si  vous  avez  l'intention  d'integrer  ce  document  dans un travail
  destine a la publication, contactez-moi  (par  courrier  electronique)
  afin de pouvoir obtenir les informations les plus a jour possible. Par
  le passe, des versions depassees des documents  Linux  HOWTO  ont  ete
  publiees,   causant   aux   developpeurs   le  prejudice  indu  d'etre
  empoisonnes par des questions dont les reponses figuraient  deja  dans
  les versions a jour.

  En  accord  avec cette notice, la version originale (en anglais) telle
  qu'elle apparait dans l'Ethernet-HOWTO est fournie ici:

  This document is not gospel. However, it is probably the  most  up  to
  date  info  that  you  will be able to find. Nobody is responsible for
  what happens to your hardware but yourself. If your ethercard  or  any
  other  hardware  goes  up in smoke (...nearly impossible!)  we take no
  responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE  FOR  ANY  DAMAGES
  INCURRED  DUE  TO  ACTIONS  TAKEN BASED ON THE INFORMATION INCLUDED IN
  THIS DOCUMENT.

  This  document  is  Copyright  (c)  1993-1997   by   Paul   Gortmaker.
  Permission  is  granted to make and distribute verbatim copies of this
  manual provided the copyright notice and this  permission  notice  are
  preserved on all copies.

  Permission is granted to copy and distribute modified versions of this
  document under the conditions for verbatim copying, provided that this
  copyright  notice is included exactly as in the original, and that the
  entire resulting derived work is distributed  under  the  terms  of  a
  permission notice identical to this one.

  Permission  is  granted  to  copy  and distribute translations of this
  document  into  another  language,  under  the  above  conditions  for
  modified versions.

  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.

  Ce document fait partie des HOWTO Linux traduits  en  francais.   Vous
  pouvez  trouver  une  liste  a  jour  de  ces  documents  a  l'adresse
  <http://www.freenix.fr/linux/HOWTO/Liste-des-HOWTO.html>

  Les HOWTO Linux font partie du Linux Documentation Project  (LDP).  Si
  vous  souhaitez participer au LDP ou a sa traduction en francais, vous
  pouvez     consulter     <http://www.freenix.fr/linux/HOWTO/Liste-des-
  HOWTO.html> ou contacter Eric Dumas, dumas@linux.eu.org.

  Cette  version  francaise  a ete realisee par Stephane Alnet <alnet@u-
  picardie.fr>. Elle est Copyright (c) 1997, Stephane Alnet,  selon  les
  termes de la notice ci-dessus.

  Si  vous  constatez  des erreurs dans la traduction en francais, merci
  d'en informer le traducteur. Vos remarques  seront  prises  en  compte
  pour la prochaine version de la traduction.

  10.7.  Conclusion

  Si  vous  avez trouve une faute de frappe enaurme, ou des informations
  depassees dans ce document, merci d'envoyer un courrier  electronique.
  Il  a  tendance  a  devenir grand, et il est facile de rater certaines
  choses.  Si vous avez envoye un courrier a propos d'une  modification,
  et qu'elle n'a pas ete incluse dans la version suivante, n'hesitez pas
  a la re-envoyer, car elle a pu se perdre dans le flot habituel de SPAM
  et de prospectus.

  Merci!

