Linux Ethernet-Howto par Paul Gortmaker Version française : Mathieu Arnold Version anglaise : v2.7, 5 mai 1999 _________________________________________________________________ _Ceci est l'Ethernet-Howto, une compilation d'informations sur les périphériques Ethernet qui peuvent être utilisés avec Linux, et la façon de les mettre en oeuvre. Notez que ce Howto se limite à l'aspect matériel et pilotes de bas niveau des cartes Ethernet, et ne couvre pas la partie logicielle de choses comme ifconfig et route. Consultez le Network Howto pour ce type d'informations._ _________________________________________________________________ 1. Introduction L'_Ethernet-Howto_ indique quelles cartes vous devriez ou ne devriez pas acheter; comment les configurer, comment en utiliser plusieurs en même temps et d'autres problèmes et questions classiques. Il contient des informations détaillées sur le niveau actuel du support pour toutes les cartes Ethernet parmi les plus courantes disponibles. Il _ne_ couvre _pas_ l'aspect logiciel des choses, tel qu'il est décrit dans le _NET-3-Howto_. Notez aussi que les questions générales sur Ethernet, non liées spécifiquement à Linux, ne sont pas traitées dans ce document (ou du moins ne le devraient pas l'être). Pour ce genre de questions, consultez l'excellent ensemble d'informations de la FAQ du groupe comp.dcom.lans.ethernet. Vous pouvez l'obtenir par FTP depuis rtfm.mit.edu de la même manière que vous obtenez les FAQs des autres forums. La présente version couvre les noyaux de distribution jusqu'à la version 2.2.7 incluse. L'_Ethernet-Howto_ est de : Paul Gortmaker, p_gortmaker@yahoo.com La principale source d'information pour la première version, en ASCII pur de l'_Ethernet-Howto_ était : Donald J. Becker, becker@cesdis.gsfc.nasa.gov que nous devons aussi remercier pour l'écriture de la vaste majorité des pilotes de cartes Ethernet qui sont aujourd'hui disponibles pour Linux. Il est aussi l'auteur du serveur NFS originel. Merci Donald ! Ce document est Copyright (c) 1993-1999 Paul Gortmaker, et 1998-1999 Mathieu Arnold pour la version française. Consultez le désistement de responsabilité (section Désistement de responsabilité et Copyright) et les informations sur la copie à la fin de ce document pour avoir plus d'informations sur la redistribution de ce document ainsi que tout le tremblement habituel sur 'nous ne sommes pas responsables de ce que vous pouvez réussir a casser...'. La version française est de : Mathieu Arnold, arn_mat@club-internet.fr. 1.1 Nouvelles versions de ce document Les nouvelles versions de ce document peuvent être rapatriées depuis : Sunsite HOWTO Archive Ceci est l'emplacement officiel de ce document, il peut aussi être récupéré depuis divers sites miroirs WWW/FTP de Linux. (NDT : En France, vous préférerez utiliser le site suivant pour le document originel : Miroir de Sunsite ou, mieux, la version française : Archive des HOWTO français sur LIP6 Archive des HOWTO français chez Freenix) Des mises à jour seront réalisées au fur et à mesure de l'arrivée de nouvelles informations et/ou de nouveaux pilotes. Si la copie que vous êtes en train de lire date de plus de 6 mois, alors, vous devriez aller vérifier qu'une nouvelle version n'est pas disponible. Ce document est consultable sous divers formats (postscript, dvi, ASCII, HTML...). Je recommanderai de consulter ce document sous sa forme HTML (à l'aide d'un navigateur WWW) ou sa forme Postscript/DVI. Ces deux formats contiennent des références croisées qui ne sont pas incluses dans le format texte ASCII. 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 après-midi à le lire en entier. Et la bonne nouvelle est que vous n'êtes pas _obligé(e)_ de le lire du tout. Les versions HTML, postscript et dvi possèdent une table des matières qui vous permettra de trouver plus vite l'information que vous cherchez. Il y a des chances pour que vous lisiez ce document parce que vous n'arrivez pas à faire marcher le tout, et que vous ne savez pas quoi faire ou quoi vérifier. La prochaine section ( Au secours - Ca ne marche pas~!) est destinée aux néophytes de Linux et vous indiquera la bonne direction. Typiquement, les mêmes problèmes et les mêmes questions sont posés _sans arrêt_ par des personnes différentes. Il y a des chances que votre problème ou votre question spécifique soit l'une de ces questions fréquemment posées, et qu'elle trouve sa réponse dans la partie FAQ (NDT : Foire Aux Questions) de ce document. (Voir La Foire Aux Questions). Tout le monde devrait y jeter un coup d'oeil avant d'envoyer un message demandant de l'aide. Si vous n'avez pas encore de carte Ethernet, vous devriez commencer par en choisir une. (Voir Quelle carte dois-je acheter...) Si vous avez déjà une carte Ethernet mais que vous n'êtes pas sûr(e) de pouvoir l'utiliser avec Linux, lisez donc la section qui contient les informations spécifiques à chaque constructeur, et à ses cartes. (Voir Informations Spécifiques...) Si vous êtes intéressé(e) par l'un des aspects techniques des pilotes de périphériques de Linux, allez donc consulter la section 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 à suivre pour que les choses fonctionnent, même si vous n'avez pas de connaissances préalables sur Linux ou le matériel Ethernet. La première chose à faire est de trouver quel est le modèle de votre carte, afin de pouvoir déterminer si Linux dispose d'un pilote pour cette carte-là. Des cartes différentes sont typiquement contrôlées de façon différente par l'ordinateur qui les accueille, et le pilote de périphérique de Linux (s'il en existe un) contient ces informations de contrôle qui permettent à Linux d'utiliser la carte. Si vous n'avez pas de manuel ou de document de ce genre pour vous indiquer quel est le modèle de la carte, vous pouvez alors essayer la méthode décrite dans la section Identifier une carte inconnue, qui vous aidera sur les cartes mystérieuses. Maintenant que vous savez quel type de carte vous avez, lisez les détails concernant celle-ci dans la section destinée aux cartes (section Informations Spécifiques...), qui liste par ordre alphabétique les constructeurs de carte, les numéros de chaque carte, et précise s'il existe un pilote pour Linux ou non. Si votre carte est indiquée comme `Non-supportée', vous pouvez pratiquement vous arrêter dès maintenant. Si vous ne pouvez pas trouver votre carte dans la liste, vérifiez alors si le manuel de celle-ci ne l'indique pas comme `compatible' avec un autre type de carte connu. Par exemple, il existe des centaines, si ce n'est des milliers de cartes différentes qui ont été conçues pour être compatible avec le modèle d'origine NE2000 de Novell. Supposons que vous avez trouvé un pilote sous Linux pour votre carte, vous n'avez plus qu'à le récupérer et à l'utiliser. Ce _n'est pas_ parce que Linux possède un pilote pour votre carte que celui-ci est pour autant installé dans tous les noyaux. (Le noyau est le coeur du système d'exploitation qui est chargé en premier au démarrage et qui contient entre autres choses, les drivers de divers périphériques). Selon la distribution de Linux que vous utilisez, il peut n'y avoir que très peu de noyaux tout prêts, et tout un tas de pilotes sous la forme de modules séparés, ou il peut y avoir tout un tas de noyaux, qui couvrent un grand nombre de combinaisons de pilotes précompilés. La majorité des distributions actuelles de linux sont livrées avec beaucoup de petits modules qui sont les divers pilotes. Les modules requis sont généralements chargés lors du démarrage, ou à la demande pour pouvoir accéder à un péripherique particulier. Vous aurez besoin d'attacher ce module au noyau après qu'il ait démarré. Consultez les informations de votre distribution sur l'installation et l'utilisation des modules, ainsi que la section sur les modules du présent document (section Utilisation des pilotes Ethernet comme modules). Si vous n'avez pas trouvé de noyau précompilé avec votre pilote, ni de pilote sous la forme d'un module, il y a des chances pour que vous ayez une carte particulièrement peu banale, et vous allez être obligé(e) de construire votre propre noyau en incluant ce pilote. Une fois que Linux est installé, construire un noyau personnalisé n'est pas difficile du tout. Vous répondez essentiellement oui ou non à ce que vous souhaitez que le noyau comprenne, et ensuite vous lui dites de le construire. Il existe un _Kernel-HowTo_ qui vous aidera dans cette opération. (NDT : et sa version française, accessible sur Traduction du Kernel-Howto) Arrivé à ce point, vous devriez être parvenu d'une façon ou d'une autre à démarrer un noyau avec votre pilote intégré, ou à charger ce pilote comme un module. A peu près la moitié des problèmes que les gens rencontrent est liée au fait que le pilote n'a pas été chargé d'une manière ou de l'autre, donc vous devriez constater que tout fonctionne, maintenant. Si cela ne fonctionne toujours pas, il vous faut alors vérifier si le noyau a bel et bien détecté la carte. Pour ce faire, vous devez taper dmesg | more une fois loggé, après que le système a démarré et que tous les modules ont été chargés. Cela vous permettra de consulter les messages que le noyau a fait défiler sur l'écran durant le processus de démarrage. Si la carte a été détectée, vous devriez voir quelque part dans cette liste un message du pilote de votre carte commençant par eth0, et indiquant le nom du pilote et les paramètres matériels (réglage d'interruption (IRQ), de ports d'entrée-sorties (E/S), etc.) pour lesquels la carte est réglée. (Note : lors du boot, le noyau de Linux donne la liste de toutes les cartes PCI, qu'il ait le pilote ou non - ne le confondez pas avec la détection des pilotes qui intervient après !) Si vous ne voyez pas de message d'identification de ce type, alors le pilote n'a pas détecté votre carte, et c'est pour cela que cela ne fonctionne pas. Consultez la FAQ (section La Foire Aux Questions) pour savoir quoi faire si votre carte n'est pas détectée. Si vous avez une carte compatible NE2000, vous y trouverez aussi des astuces spécifiques pour faire détecter une NE2000. Si la carte a été détectée, mais que le message de détection indique une quelconque erreur, telle qu'un conflit de ressources, alors le pilote ne s'est probablement pas correctement initialisé et la carte n'est toujours pas utilisable. La plupart des messages d'erreur de ce type sont eux aussi listés dans la FAQ, ainsi que leur solution. Si le message de détection paraît correct, vérifiez de nouveau les ressources indiquées par le pilote en les comparant avec celles pour lesquelles la carte est physiquement configurée (soit à l'aide de petits `cavaliers' noirs sur la carte, soit par un logiciel utilitaire fourni avec la carte par son constructeur). Les ressources doivent correspondre exactement. Par exemple, si votre carte est configurée (physiquement ou par logiciel) pour utiliser l'IRQ 15 et que le pilote indique IRQ 10 dans les messages de démarrage, quelque chose ne va pas. La FAQ évoque les cas les plus courants où un pilote ne détecte pas correctement les informations de configuration de diverses cartes. A ce stade, vous êtes arrivé(e) à faire détecter votre carte avec tous les paramètres corrects, et l'on peut espérer que tout fonctionne. Si ce n'est pas le cas, vous avez alors soit une erreur de configuration logicielle, soit une erreur de configuration matérielle. Une erreur de configuration logicielle serait de ne pas avoir configuré la bonne adresse de réseau pour l'une des commandes ifconfig ou route (ou les deux !); la manière de procéder est décrite en détail dans le _Network HowTo_ et le `Guide de l'Administrateur Réseau' (`_Network Administrator's Guide_' (NAG) en anglais) qui se trouvent certainement tous les deux sur le CD-ROM d'installation. Une erreur de configuration matérielle se produit quand un type de conflit de ressources ou une mauvaise configuration (que le pilote n'a pas détecté au démarrage) empêche la carte de fonctionner correctement. Vous pouvez typiquement observer cela sous plusieurs formes différentes. (1) Vous obtenez un message d'erreur lorsque ifconfig essaie d'ouvrir le périphérique 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 incohérences étranges à chaque fois qu'il essaie d'envoyer ou de recevoir des données. (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. (4) Taper cat /proc/interrupts donne un nombre d'interruptions égal à zéro pour la carte. La plupart des erreurs de configuration matérielle typiques sont elles aussi abordées dans la FAQ. Eh bien, si vous êtes parvenu à ce point et que cela ne marche toujours pas, lisez la section FAQ de ce document, voyez le paragraphe spécifique à votre carte dans la section ``Informations Spécifiques..'', _et si cela ne fonctionne toujours pas_ alors vous pourrez recourir à un envoi de message dans un groupe de _news_ approprié pour demander de l'aide. Si vous devez poster un message, veuillez détailler toute information intéressante dans ce message, comme la marque de la carte, la version du noyau, les messages du pilote au démarrage, le résultat de cat /proc/net/dev, une description claire du problème, et bien entendu ce que vous avez déjà essayé en vue de faire fonctionner l'ensemble. Vous serez surpris de voir le nombre de personnes qui envoient des choses totalement inutiles comme ``Est-ce que quelqu'un peut m'aider ? Mon Ethernet ne fonctionne pas.'' et rien d'autre. Les lecteurs des groupes de news ont tendance à ignorer des messages aussi idiots, alors qu'une description détaillée et instructive du problème pourra permettre à un `gourou-Linux' de résoudre tout de suite votre problème. 2. Quelle carte dois-je acheter pour Linux ? La réponse à cette question dépend fortement de ce que vous comptez faire avec votre connexion réseau, et du volume du trafic qui va y passer. Si vous vous attendez à ce qu'un seul utilisateur effectue occasionnellement une session FTP ou une connexion WWW, alors même une vieille carte ISA 8 bits vous contentera probablement. Si vous avez l'intention de mettre en place un serveur, et que vous exigez que la charge processeur liée à la réception et à la transmission des données sur le réseau reste la plus basse possible, vous devrez certainement choisir une des cartes PCI, qui utilisent le bus-mastering, telles celles comportant la puce tulip (21xxx) de DEC, ou la puce PCnet-PCI d'AMD. Si vous vous trouvez au milieu de ces deux extrêmes, alors n'importe quelle carte PCI bon marché ou une carte ISA 16 bits possédant un pilote stable vous conviendra. 2.1 Quels sont les pilotes stables, alors ? Parmi les cartes ISA 16 bits, les pilotes suivants sont très au point, et vous ne devriez pas avoir de problèmes si vous achetez une carte qui utilise ces pilotes : SMC-Ultra/EtherEZ, SMC-Elite (WD80x3), 3c509, Lance, NE2000. Cela ne signifie pas que tous les autres pilotes sont instables. Il se trouve juste que ceux-ci sont les plus anciens et les plus utilisés des pilotes Linux, ce qui en fait le choix le plus sûr. Notez que certaines cartes-mères pas chères peuvent avoir des problèmes avec le bus-mastering que les cartes ISA Lance utilisent, et que certains clones NE2000 bon marché ont des difficultés à être détectés au démarrage. Les pilotes PCI les plus couramment utilisés sous Linux sont probablement le 3Com Vortex/Boomerang (3c59x/3c9xx), le DEC tulip (21xxx), et l'EtherExpressPro 100 d'Intel. Les divers clones PCI-NE2000 sont également très courants, mais l'achat d'une telle carte ne peut se justifier que si le critère du prix est plus important que celui des performances. 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 beaucoup dans les années à venir sur les marchés aux puces informatiques ou autres braderies, et ce à des prix vraiment très bas. Cela les rend idéales pour les systèmes ``Ethernet-à-la-maison''. cette constatation est d'ailleurs aussi valable pour les cartes ISA 16 bits car les cartes PCI deviennent de plus en plus communes. La wd8003, la 3c503 et la ne1000 sont des cartes 8 bits qui donneront de bonnes performances pour une utilisation faible à modérée. La 3c501 donnera des résultats faibles, et ces reliques antédiluviennes (12 ans !) des beaux jours du XT sont à éviter. (Envoyez les a Alan, il les collectionne...) Le canal de données 8 bits n'atténue pas trop les performances, puisque vous pouvez encore espérer obtenir 500 à 800 Ko/s en vitesse de transfert FTP pour une carte 8 bits wd8003 (sur un bus ISA rapide) à partir d'un serveur rapide. Et si la plupart de votre trafic réseau est à destination de sites éloignés, le goulot d'étranglement se situera ailleurs sur le chemin, la seule différence de vitesse que vous noterez se produisant lorsqu'il y a de l'activité sur votre réseau local. 2.3 Cartes 32 bits (VLB/EISA/PCI) Notez qu'un réseau à 10 Mbps ne justifie pas l'utilisation d'une interface 32 bits. Consultez E/S programmées contre..., qui explique pourquoi avoir une carte Ethernet 10 Mbit/s sur un bus ISA à 8 MHz ne constitue vraiment pas un goulot d'étranglement. Même si le fait que la carte Ethernet se trouve sur un bus rapide ne signifie pas que les transferts sont plus rapides, cela entraînera souvent une charge processeur supplémentaire moins importante, ce qui est bon pour les systèmes multi-utilisateurs. Bien sûr, avec la démocratisation des réseaux 100 Mbps, les cartes 32 bits deviennent une obligation pour pouvoir tirer avantage de toute la bande passante. AMD propose les puces 32 bits PCnet-VLB et PCnet-PCI. Consultez AMD PCnet-32 pour plus d'informations sur la version 32 bits de la puce LANCE / PCnet-ISA. La puce tulip (21xxx) PCI de DEC est une autre option (voir DEC 21040) pour les utilisateurs de puissance. De nombreux fabricants proposent des cartes basées sur cette puce, et les prix de ces cartes ``sans-nom'' sont généralement bas. Les cartes PCI `Vortex' et `Boomerang' de 3Com constituent aussi une autre option, et le prix reste correct si vous pouvez en obtenir une tant que leur proposition d'évaluation dure. (voir 3c590/3c595) Les cartes EtherExpress Pro 10/100 PCI d'Intel sont aussi connues pour marcher plutôt bien avec Linux. (voir EtherExpress). Des fabricants de clones ont commencé à produire des clones PCI de NE2000, basés sur une puce RealTek ou une puce Winbond. Le pilote Linux NE2000 des noyaux 2.0.31 et supérieurs accepte ces cartes. Cependant vous ne bénéficierez que de la vitesse plus élevée du bus, puisque ces cartes utiliseront encore l'interface du pilote de la NE2000, qui commence à dater. Depuis la version 2.0.34 du noyau, un pilote specifique à ces cartes ne2k-pci.c est aussi disponible. Il devrait être légerement plus efficace que le pilote ISA ne.c 2.4 Cartes et pilotes 100 M disponibles La liste des matériels 100 M reconnus par Linux à l'heure actuelle est la suivante : les cartes basées sur la puce DEC 21140; les cartes 3c595/3c90x Vortex; la EtherExpressPro10/100B; la PCnet-FAST; la SMC 83c170 (epic100) et la HP 100VG ANY-LAN. Allez aussi jeter un coup d'oeil sur les pages des constructeurs des cartes, vous pouvez aussi aller sur l'une des adresse suivantes : Ethernet 100M La page 100VG de Donald La page Fast Ethernet de Dan Kegel 2.5 100VG contre 100BaseT Le 100BaseT est beaucoup plus répandu que le 100VG et la plaquette publicitaire suivante est extraite d'un vieux message désespérement bourré d'informations posté par Donald dans comp.os.linux; elle résume bien la situation: ``Pour ceux qui ne seraient pas au courant, il y a deux normes Ethernet en compétition, le 100VG (aussi connu sous le nom de 100baseVG ou encore 100VG-AnyLAN) et le 100baseT (qui, selon le type du câble, s'appelle 100bastTx, 100baseT4 ou 100baseFx). Le 100VG est arrivé sur le marché le premier, et je sentais qu'il était mieux pensé que le 100baseTx. J'étais persuadé qu'il allait gagner, mais visiblement ce ne sera pas le cas. HP et al. ont fait plusieurs mauvais choix : 1) Retarder la norme de manière à ce qu'ils puissent être compatibles avec IBM et accepter les trames Token Ring. Cela `semblait une bonne idée à l'époque', puisque cela aurait permis aux installations Token Ring de se mettre à jour sans devoir faire admettre aux décideurs qu'ils avaient fait une énorme bourde en s'alliant avec la mauvaise technologie. Mais il n'y avait rien à gagner, parce que les deux types de trames ne peuvent pas coexister sur un réseau, parce que Token Ring est un monstre de complexité , et que IBM a quand même adopté 100baseT pour finir. 2) Ne produire que des cartes ISA et EISA. (Un modèle PCI n'a été annoncé que récemment.) Le bus ISA est trop lent pour 100 M, et relativement peu de machines EISA existent. A l'époque VLB était classique, rapide, et économique, PCI restant un choix viable. Mais la sagesse des ``anciens'' disait que les serveurs continueraient d'utiliser le bus EISA hors de prix. 3) Ne pas m'envoyer une documentation. Oui, cela a été la raison réelle du déclin du 100VG :-). J'ai appelé partout pour obtenir des infos de programmation, et tout ce que j'ai pu obtenir a été une brochure de quelques pages sur papier glacé de AT&T décrivant combien le jeu de puce Regatta était merveilleux.'' (NDT : ``La norme 100 BAS VG - any LAN proposée par HP (...) ne reprend pas le principe du protocole Ethernet mais utilise le principe du _polling_. L'utilisation du mot Ethernet a donc ici plutôt une vocation commerciale. Il faut changer les coupleurs dans les stations de travail. Toutefois, on conserve les principaux systèmes de câblage.'' (Pierre Rolin, _in_ ``Réseaux haut débit'', Hermès, 1995). Fin 1997 plus personne ne parle de 100VG. La norme 100baseT4 utilise un câblage catégorie 3 et 4, 100baseTx un câblage catégorie 5, 100baseFx de la fibre optique.) 2.6 Les types de câbles que votre carte peut accepter Si vous mettez en place un petit réseau ``personnel'', vous préférerez certainement utiliser le ``thinnet'' ou câble Ethernet fin. C'est le modèle avec les connecteurs BNC standards. Le câblage `thinnet', ou Ethernet fin (câble coaxial RG-58) avec les connecteur BNC (en métal, à enfoncer puis tourner pour verrouiller) est appelé techniquement 10Base2. La plupart des cartes Ethernet possèdent aussi une version `Combo' qui ne coûte que 60 à 150 francs de plus. (NDT : Amusant comme les écarts de prix en dollars se convertissent en écarts de prix en francs ! La version anglaise dit ``10 à 20 dollars de plus''. Ces écarts de prix sont vrais fin 97.) Ces versions `Combo' possèdent les deux interfaces paire torsadée et Ethernet fin intégrées, ce qui vous permet de changer d'avis plus tard.(NDT : `Combo' signigie même souvent : interface RJ-45 (10baseT, paire torsadée) + interface BNC (10base2, thinnet) + interface AUI (pour _transceiver_ ou câble de descente (drop-cable) gros Ethernet).) Les câbles à paires torsadées, avec les connecteurs RJ-45 (rectangulaires un peu plus grande que les prises `téléphone') sont appelés techniquement 10BaseT. Vous pourrez aussi entendre parler de UTP (Unshielded Twisted Pair, paire torsadée non-écrantée ou non-blindée, NDT). Le vieil Ethernet `épais' (Thick Ethernet, sur câble coaxial de 10 mm) ne se trouve plus que dans les installations anciennes et est appelé 10Base5. La prise en forme de D avec 15 broches présente sur quelques cartes Ethernet (connecteur AUI) est utilisée pour connecter de l'ethernet épais et des transceivers externes. Les grandes installations professionnelles utiliseront le plus souvent du 10BaseT au lieu de 10Base2. 10Base2 n'offre pas de moyen pour passer au 100 Mbit/s, quel que soit le nom qu'on leur donne. (NDT : Professionnellement parlant, en dehors de la fibre optique qui est encore hors de prix jusqu'à la machine de l'utilisateur, les nouveaux câblages devraient être réalisés en ``Catégorie 5, classe D''. Ce type de câblage supporte non seulement 10BaseT, mais aussi 100BaseT et les nouveaux débits qui apparaissent. Pour la maison, vous choisirez entre Ethernet fin (simple et pas cher) et une connectique style RJ-45 (un peu moins simple, un peu plus cher, mais plus `propre' électriquement parlant) selon vos envies et votre budget ! Référez vous a Cables, Coax... pour plus de détails sur les différents types de cables. 3. Foire Aux Questions (FAQ) - Les questions fréquemment posées Voici quelques unes des questions les plus fréquemment posées à propos de l'utilisation de Linux avec une connexion Ethernet. Certaines des questions les plus spécifiques sont triées `par ordre de constructeur'. Il y a de fortes chances pour que la question que vous voulez poser l'ai déjà été, et aie déjà une réponse. Donc, si jamais vous ne trouvez pas la réponse ici, vous le trouverez certainement sur une archive de newsgroups comme : Dejanews. 3.1 Les pilotes `Alpha' -- Comment les obtenir et comment s'en servir J'ai entendu dire qu'il y avait une version mise-à-jour ou un pilote préliminaire/alpha disponible pour ma carte. Où puis-je l'obtenir ? Les plus récents des `nouveaux' pilotes peuvent être trouvés sur le site FTP de Donald : cesdis.gsfc.nasa.gov dans la partie /pub/linux/. Les choses y changent fréquemment, donc jetez-y un coup d'oeil de temps à autre. Vous pourrez préférer utiliser un navigateur WWW sur : La page Linux de Don pour localiser le pilote que vous cherchez. (Prenez garde aux navigateurs WWW qui modifient le source sans rien dire en remplaçant les tabulations par des espaces, etc. - si vous n'êtes pas sûr(e), utilisez ftp, ou au moins une URL FTP, pour le chargement.) Maintenant, s'il s'agit réellement d'un pilote alpha, voire pré-alpha, s'il vous plaît considérez-le comme tel ! En d'autres termes, ne vous plaignez pas parce que vous n'arrivez pas à comprendre ce que vous devez en faire. Si vous ne savez pas comment l'installer, alors vous ne devriez certainement pas être en train de le tester. De même, s'il plante votre machine, ne vous plaignez pas. Au lieu de cela, envoyez-nous un rapport détaillé sur le problème, ou même mieux, un patch ! Notez que certains des pilotes expérimentaux ou alpha `utilisables' sont inclus dans l'arborescence standard du noyau. Lorsque vous exécutez make config, l'une des premières choses qui vous sera demandée est si vous souhaitez être interrogé(e) sur les pilotes en cours de développement (``Prompt for development and/or incomplete code/drivers''). Vous devrez répondre ``Y'' (pour `_Yes_', `Oui') à cette question si vous souhaitez être interrogé(e) sur l'inclusion d'un pilote alpha ou expérimental. 3.2 Utiliser plus d'une carte Ethernet par machine Que faut-il faire pour que Linux puisse gérer deux cartes Ethernet ? La réponse à cette question est différente selon que les pilotes ont été compilés directement dans le noyau ou en tant que modules. De nos jours, la majorité des distributions utilisent des pilotes sous forme de modules. Ceci permet de ne pas avoir à fournir une tonne de noyaux chacun ayant un jeu de pilotes spécifique. A la place, un petit noyau de base est utilisé et les pilotes sont tous compilés en modules, ces modules étant chargés à la demande dès que le système est allé assez loin dans son démarrage pour accéder aux modules (habituellement dans /lib/modules/). _Avec le pilote chargé en module :_ Dans le cas de pilotes PCI, le module détectera normalement toutes les cartes de même type d'un seul coup. Cependant, pour les cartes ISA, la détection automatique n'est pas une opération qui marche à coup sûr, et vous aurez très certainement à fournir les adresses d'entrée/sortie de base de la carte pour que le module sache où regarder. Ces informations sont placées dans le fichier /etc/conf.modules. Par exemple, supposez qu'un utilisateur ait deux cartes ISA NE2000, une à Ox300 et l'autre à 0x240, il aura les lignes suivantes dans son /etc/conf.modules : alias eth0 ne alias eth1 ne options ne io=0x240,0x300 Explication : cela dit que si l'administrateur (ou le noyau) fait un modprobe eth0 ou un modprobe eth1, alors le pilote ne.o devra être chargé pour eth0 et eth1. De plus, quand le module se chargera, il le sera avec comme options io=0x240,0x300. Ainsi, le pilote saura où aller chercher les cartes. Notez que le 0x est important, des trucs comme 300h couramment utilisés dans le monde DOS ne marcheront pas. Le fait d'inverser 0x240 et 0x300 aura pour effet d'inverser physiquement eth0 et eth1. La majorité des pilotes ISA peuvent prendre plusieurs valeurs d'entrée/sortie séparées par des virgules comme dans cet exemple pour prendre en charge plusieurs cartes. Cependant, certains pilotes (plus anciens ?), tels que le module 3c501.o sont pour l'instant incapables de gérer plus d'une carte par chargement du module. Dans ce cas, vous pouvez charger le module deux fois pour avoir les deux cartes détectées. Votre /etc/conf.modules ressemblerait alors à : alias eth0 3c501 alias eth1 3c501 options eth0 -o 3c501-0 io=0x280 irq=5 options eth1 -o 3c501-1 io=0x300 irq=7 Dans cet exemple, l'option -o a été utilisée pour donner à chaque instance du module un nom unique, puisqu'il n'est pas possible d'avoir deux modules ayant le même nom. L'option irq= a également été utilisée, pour indiquer l'interruption materielle de la carte. (Cette méthode peut aussi être utilisée pour les modules qui gèrent les listes d'adresses d'entrée/sortie, bien qu'elle soit moins efficace, car on se retrouve avec le module chargé deux fois alors que cela n'est pas nécessaire.) Pour finir, voici un exemple avec une carte 3c503 à 0x350 et une SMC Elite16 (wd8013) à 0x280. Vous auriez : alias eth0 wd alias eth1 3c503 options wd io=0x280 options 3c503 io=0x350 Pour les cartes PCI, vous avez juste besoin des lignes alias pour associer les interface ethN aux pilotes correspondants, puisque les adresses d'entrée/sortie des cartes PCI sont automatiquement détectées. Les modules disponibles sont généralements situés dans le répertoire /lib/modules/`uname -r`/net où la commande uname -r retourne la version du noyau (ex : 2.0.34). Vous pouvez aller y faire un tour pour voir ceux qui sont faits pour votre carte. Puis, lorsque vous aurez les bons paramètres dans votre /etc/conf.modules, il ne vous reste plus qu'à tester avec la commande : modprobe ethN dmesg | tail Où N est le numéro de l'interface que vous testez. _Avec le pilote compilé dans le noyau :_ Si vous avez le pilote compilé dans le noyau, alors, voici tout ce qu'il faut savoir pour utiliser plusieurs cartes Ethernet. Toutefois, notez que pour le moment, seulement _une_ carte Ethernet est détectée automatiquement par défaut. Cela contribue à éviter des blocages possibles au moment du démarrage, causés par la détection de cartes `sensibles'. (Note : Depuis les derniers noyaux 2.1, la détection des périphériques a été découpée en deux parties, celle qui est sûre, et celle qui ne l'est pas . Par conséquent, tout ce qui est sûr (ex : PCI et EISA) sera détecté de manière automatique. Les systèmes avec plus d'une carte dont une sur un port ISA nécessiteront toujours la procédure suivante.) Vous pouvez activer la détection automatique de la deuxième (et de la troisième, et de...) carte de deux façons différentes. La méthode la plus simple consiste à passer des arguments au noyau au moment du démarrage, ce qui est généralement fait par LILO. La détection de la deuxième carte peut être obtenue en utilisant un argument de démarrage aussi simple que ether=0,0,eth1. Dans ce cas, eth0 et eth1 seront affectés dans l'ordre dans lequel les cartes seront trouvées dans cet ordre au démarrage. Par contre, si vous souhaitez que la carte sur le port 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 numéro d'IRQ + le port d'E/S + le nom qui sont montrés ci-dessus. Veuillez consulter Passage des arguments Ethernet... pour la syntaxe complète, les paramètres spécifiques à chaque carte, et des astuces pour LILO. Ces arguments de démarrage peuvent être rendus permanents afin de ne pas devoir les ré-entrer à chaque fois. Consultez la documentation sur l'option de configuration `append' de LILO. La seconde méthode (non recommandée) est d'éditer le fichier Space.c et de remplacer la valeur 0xffe0 pour l'adresse d'entrée-sortie par un zéro. La valeur 0xffe0 indique au noyau qu'il ne doit pas essayer de détecter ce périphérique -- la remplacer par un zéro autorisera l'auto-détection du périphérique. Notez que si vous avez l'intention d'utiliser Linux sur une machine qui servira de passerelle entre deux réseaux, vous devrez recompiler un noyau avec l'option ``IP forwarding''. Mais généralement un vieil AT/286 avec quelque chose comme le logiciel `kbridge' est une meilleure solution. Si vous consultez ce document tout en _surfant_ sur le réseau, vous pourrez jeter un coup d'oeil à un _mini-HOWTO_ que Donald a sur son site WWW. Consultez : Plusieurs Cartes Ethernet. 3.3 le ether= n'a rien changé. Pourquoi ? Comme il a été dit précédemment, la commande ether= ne marche _que_ pour les pilotes qui ont été compilés dans le noyau. Maintenant, la majorité des distributions utilisent les pilotes dans leur forme modulaire, ce qui fait que la commande ether= n'est plus guère utilisée. (Certaines vieilles documentations ont peut-être encore à être mises à jour pour refléter ce changement.) Si vous voulez passer des options à un pilote modulaire vous _devez_ faire les changements dans le fichier /etc/conf.modules. Si vous utilisez un pilote compilé dans le noyau et avez ajouté la ligne ether= à votre fichier de configuration LILO, notez qu'il ne sera pris en compte que lorsque vous relancerez lilo pour mettre à jour les informations. 3.4 Problèmes avec les cartes NE1000 / NE2000 (et leurs clones) _Problème :_ Une carte PCI clone NE2000 n'est pas détectée au démarrage avec un noyau 2.0.x. _Raison :_ Le pilote ne.c jusqu'à la version 2.0.30 ne connaît que le numéro d'identification PCI des cartes clones basées sur la puce 8029 de RealTek. Comme depuis beaucoup d'autres ont eux aussi fait des cartes PCI clones NE2000, avec des numéro d'identification PCI différents, le pilote ne les détecte pas. _Solution :_ La solution la plus simple est de mettre à jour votre noyau pour une version 2.0.31 (ou plus récente). Cette dernière connaît les identificateurs de près de cinq puces NE2000 PCI différentes, et les détectera automatiquement au démarrage ou lors du chargement en module. Si vous passez à la version 2.0.34 (ou plus récente) du noyau, vous aurez un pilote spécifique aux cartes NE2000 PCI, qui est un peu plus léger et plus rapide que le pilote ISA/PCI. _Problème :_ Ma carte PCI clone NE2000 est indiquée comme étant une NE1000 (une carte 8 bits !) au démarrage ou lorsque je charge le module ne.o sous 2.0.x, et par conséquent la carte ne fonctionne pas. _Raison :_ Certains clones PCI n'implémentent pas l'accès de largeur un octet (et par conséquent ne sont donc pas réellement compatibles NE2000 à 100%). Cela entraîne que la procédure de détection pense qu'il s'agit de cartes NE1000. _Solution :_ Vous devez passer à la version 2.0.31 (ou une version plus récente) comme dit ci-dessus. Le pilote vérifie maintenant si ce bug matériel est là. _Problème :_ Ma carte NE2000 PCI a des performances affreuses, même en réduisant la taille de la fenêtre comme il est décrit dans la section sur les trucs pour les performances. _Raison :_ Les spécifications de la puce 8390 originelle, conçue et vendue il y a plus de dix ans, notaient qu'une opération de lecture (depuis la puce) était nécessaire avant chaque opération d'écriture pour avoir une sécurité maximale. Le pilote possède la fonctionnalité pour le faire mais cela a été désactivé par défaut depuis l'époque des versions 1.2 du noyau. Un utilisateur a indiqué que le fait de réactiver cette `contre-fonctionnalité' avait aidé à améliorer les performances sur une carte PCI clone de NE2000 bon marché. _Solution :_ Puisque cela n'a été rapporté comme solution que par une seule personne, ne vous échauffez pas trop. Pour ré-activer le correctif de `lecture avant écriture', il suffit d'éditer le fichier du pilote dans linux/drivers/net/, 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 décrivant la différence de performance et le type de carte / de puce que vous avez, si cela vous a aidé. (la même chose peut être effectuée sur le fichier ne2k-pci.c également). _Problème :_ Le pilote ne2k-pci.c donne un message d'erreur ressemblant a timeout waiting for Tx RDC avec une carte NE2000 PCI et ne marche pas. _Raison :_ Votre carte et/ou le lien vers le bus PCI ne sait pas gérer les optimisations d'E/S du pilote. _Solution :_ Tout d'abord, vérifiez les réglages de votre BIOS pour voir si vous avez un réglage de timing du bus PCI trop agressif pour des opérations stables. Sinon, vous pouvez utiliser le pilote ISA/PCI ne.c (ou commenter la ligne #define USE_LONGIO du ne2k-pci.c), ce qui vous permettrait d'utiliser la carte. _Problème :_ Ma carte ISA Plug and Play NE2000 (telle que la RealTek 8019) n'est pas détectée. _Raison :_ A l'origine, les spécifications de NE2000 (et par conséquent le pilote linux NE2000) ne supportent pas le PnP. _Solution :_ Utilisez la disquette de configuration DOS qui est fournie avec la carte pour désactiver le PnP, et pour régler les adresses d'entrée/sortie et l'IRQ. Ajoutez une ligne au /etc/conf.modules telle options ne io=0xNNN ou 0xNNN est l'adresse d'entrée/sortie en hexadecimal. (Ceci suppose l'utilisation des modules, si tel n'est pas le cas, utilisez une commande telle ether=0,0xNNN,eth0 lors du boot). Vous aurez peut être aussi a configurer cette irq dans le BIOS pour qu'elle ne soit pas affectée à une carte PnP. D'un autre côté, si vous devez laisser le PnP pour rester compatible avec un autre système d'exploitation, allez regarder le paquetage _isapnptools_. Essayez man isapnp pour voir si il n'est pas déjà installé sur votre système. S'il ne l'est pas, allez jeter un coup d'oeil à l'URL : ISA PNP Tools _Problème :_ Le pilote NE*000 indique `not found (no reset ack)' (carte non trouvée, pas d'acquittement de la réinitialisation) pendant la procédure de détection au démarrage. _Raison :_ Cela est lié au changement précédent. Après la vérification initiale qu'une 8390 se trouve à l'adresse d'E/S testée, la réinitialisation est effectuée. Quand la carte a terminé sa réinitialisation, elle est supposée envoyer un acquittement indiquant que la réinitialisation s'est achevée. Votre carte ne l'a pas fait, et le pilote estime donc qu'aucune carte NE n'est présente. _Solution :_ Vous pouvez indiquer au pilote que vous possédez une _mauvaise carte_ (_bad card_) en utilisant une valeur héxadécimale 0xbad au moment du démarrage pour le paramètre mem_end (qui n'est normalement pas utilisé). 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 à 0x340 et qui n'acquitte pas la réinitialisation utilisera quelque chose comme : LILO: linux ether=0,0x340,0,0xbad,eth0 Cela permettra à la procédure de détection de la carte de continuer, même si votre carte n'acquitte pas la réinitialisation. Si vous utilisez le pilote comme un module, vous pouvez alors fournir l'option bad=0xbad exactement comme vous indiquez l'adresse d'E/S _Problème :_ Ma carte NE*000 bloque la machine au premier accès réseau. _Raison :_ Ce problème a été rapporté pour des noyaux aussi vieux que le 1.1.57 jusqu'aux noyaux actuels. Il apparaît être confiné à un petit nombre de cartes clones configurables par logiciel. Il apparaît que ces cartes s'attendent à être initialisées d'une manière spéciale. _Solution :_ De nombreuses personnes ont indiqué que le fait d'exécuter le programme DOS de configuration fourni avec la carte et/ou le pilote DOS fourni avec la carte avant de redémarrer à chaud (i.e. en utilisant loadlin ou le `salut-aux-trois-doigts' (Ctrl-Alt-Suppr, NDT)) pour lancer Linux permet à la carte de fonctionner. Ceci indiquerait que ces cartes doivent être initialisées d'une façon particulière, légèrement différente de ce que le pilote Linux actuel réalise. _Problème :_ Ma carte Ethernet NE*000 à l'adresse 0x360 n'est pas détectée. _Raison :_ Votre carte NE2000 a une largeur d'espace d'adressage d'E/S de 0x20, ce qui lui fait atteindre la zone utilisée par le port parallèle à l'adresse 0x378. D'autres périphériques pourraient se trouver à cet endroit-là, comme le contrôleur du deuxième lecteur de disquette (s'il y en a un) à l'adresse 0x370 et le contrôleur IDE secondaire aux adresses 0x376--0x377. Si le(s) port(s) sont déjà enregistrés par un autre pilote, le noyau ne laissera pas s'exécuter la détection. _Solution :_ Vous pouvez soit déplacer votre carte vers une adresse d'E/S comme 0x280, 0x340, 0x320, ou compiler votre noyau sans l'option pour l'imprimante parallèle. _Problème :_ Le réseau `disparaît' à chaque fois que j'imprime quelque chose (NE2000). _Raison :_ Même problème que précédemment, mais vous avez un vieux noyau qui ne vérifie pas les chevauchements de zones d'adressage d'E/S. Utilisez la même solution que ci-dessus, et profitez-en pour récupérer un nouveau noyau, tant qu'à faire. _Problème :_ NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz) (carte Ethernet NE*000 testée à l'adresse 0xNNN: 00 00 C5 ... non trouvée, signature yy zz non valide) _Raison :_ Avant tout, avez-vous une carte NE1000 ou NE2000 à l'adresse 0xNNN ? Si oui, est-ce que l'adresse matérielle indiquée ressemble à une adresse valide ? Si oui, alors vous avez un clone NE*000 bas de gamme. Tous les clones NE*000 sont supposés avoir la valeur 0x57 dans les octets 14 et 15 de leur SA (Station Address) PROM. La vôtre n'a pas ces valeurs -- elle a `yy zz' à la place. _Solution :_ Il existe deux moyens de contourner ce problème. Le plus simple est d'utiliser une valeur 0xbad pour le paramètre mem_end comme indiqué ci-dessus pour le problème du non-acquittement de la réinitialisation. Cela évitera la vérification de la signature, pour autant qu'un port d'E/S non nul soit fourni en même temps. De cette façon, aucune recompilation du noyau n'est nécessaire. La seconde méthode (pour les hackers) nécessite de changer le pilote lui-même, puis de recompiler votre noyau (ou le module). Le pilote (/usr/src/linux/drivers/net/ne.c) comporte une petite "Galerie des horreurs" aux environs de la ligne 42. Cette liste est utilisée pour détecter les clones bas de gamme. Par exemple, la carte DFS utilise `DFI' dans les trois premiers octets de la PROM, au lieu d'utiliser 0x57 aux octets 14 et 15, tels qu'ils sont supposés être. _Problème :_ La machine se bloque pendant le démarrage après le message `8390...' ou le message `WD....'. Le fait d'enlever la carte NE2000 résoud le problème. _Solution :_ Changez votre adresse d'E/S de base pour une valeur comme 0x340. Autre solution, vous pouvez utiliser l'argument de démarrage ``reserve='' en conjonction avec l'argument ``ether='' pour protéger la carte des procédures de détection des autres pilotes de périphériques. _Raison :_ Votre clone NE2000 n'est pas un assez bon clone. Une carte NE2000 est un puits sans fond qui attirera tout pilote qui tenterait une détection dans son espace d'adressage. Le fait de changer la carte NE2000 vers une adresse moins populaire l'écartera du chemin des autres procédures de détection automatique, permettant à votre machine de démarrer. _Problème :_ La machine se bloque pendant la détection du SCSI au démarrage. _Raison :_ C'est le même problème que précédemment; changez l'adresse d'E/S de la carte Ethernet, ou utilisez les arguments de démarrage reserve et ether. _Problème :_ La machine se bloque pendant la détection de la carte son au démarrage. _Raison :_ Non, en fait c'est pendant la détection silencieuse du SCSI, et c'est le même problème que ci-dessus. _Problème :_ Ma carte NE2000 n'est pas détectée au démarrage. Il n'y a aucun message pendant le démarrage. _Solution :_ Il n'existe pas de `solution magique' parce qu'il existe tout un tas de raisons pour qu'elle ne soit pas détectée. La liste suivante devrait vous aider à parcourir les problèmes possibles. 1) Construisez un nouveau noyau ne contenant que les pilotes de périphérique dont vous avez besoin. Vérifiez que vous êtes réellement en train de démarrer le noyau tout frais. Oublier de lancer lilo, etc. peut amener à démarrer l'ancien. (Regardez de près la date et l'heure de compilation indiquée au démarrage.) Cela peut paraître idiot, mais nous l'avons tous fait un jour. Assurez-vous que le pilote est bien inclus dans le nouveau noyau, en consultant le fichier System.map à la recherche de noms comme ne_probe. 2) Consultez attentivement les messages au démarrage. Est-ce qu'ils mentionnent une tentative de détection d'une NE2000 comme `NE*000 probe at 0xNNN: not found (bla bla)' ou est-ce que la détection se contente d'échouer sans rien dire ? Cela fait une grosse différence. Utilisez dmesg|more pour relire les messages de démarrage après vous être loggé, ou tapez Majuscule+PageUp (page précédente) pour faire défiler l'écran vers le haut après que le démarrage soit terminé et que le prompt de login soit apparu. 3) Après le démarrage, faites un cat /proc/ioports et vérifiez 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 périphérique a enregistré ne serait-ce qu'un port à n'importe quel endroit dans cet intervalle, la procédure de détection ne pourra pas s'effectuer à cette adresse et continuera sans rien dire jusqu'à la prochaine adresse testée. Un cas classique est que le pilote lp (imprimante) réserve 0x378 ou que le second canal IDE réserve 0x376 ce qui empêche le pilote ne de tester la plage 0x360-0x380. 4) Même chose que précédemment avec cat /proc/interrupts. Assurez-vous qu'aucun autre périphérique n'a enregistré l'interruption que vous avez fixée pour la carte Ethernet. Dans ce cas, la détection s'effectuera, et le pilote Ethernet se plaindra vigoureusement au démarrage de ne pas être capable d'obtenir la ligne d'IRQ désirée. 5) Si vous séchez encore sur l'échec silencieux du pilote, éditez-le et ajoutez quelques printk() à la procédure de détection. Par exemple, avec une NE2000 vous pouvez ajouter/enlever des lignes (marquées respectivement par un '+' ou un '-') dans linux/drivers/net/ne.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 émettra alors des messages pour chaque port qu'il vérifie, et vous verrez alors si l'adresse de votre carte a été testée ou non. 6) Vous pouvez aussi récupérer le programme de diagnostic pour NE2000 sur le site FTP de Don (indiqué dans le _Howto_) et regarder s'il est capable de détecter votre carte après que vous avez démarré Linux. Utilisez l'option `-p 0xNNN' pour lui dire où regarder pour la carte. (La valeur par défaut est 0x300 et il ne va pas regarder ailleurs, à la différence de la procédure de détection au démarrage.) Le résultat, s'il trouve une carte, ressemblera à : _________________________________________________________________ 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 différentes. Notez que toutes les valeurs de la PROM sont doublées pour une carte 16 bits, et que l'adresse Ethernet (00:00:c0:b0:05:65) apparaît dans la première ligne, et que la signature avec le double 0x57 apparaît à la fin de la PROM. Le résultat, s'il n'y a aucune carte installée en 0x300, ressemblera à : _________________________________________________________________ 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 retournée lorsque l'on lit un port d'E/S vacant. Si vous avez un autre matériel dans la zone qui est testée, vous pourrez voir des valeurs différentes de 0xff aussi. 7) Essayez de démarrer Linux à chaud depuis une disquette de démarrage DOS (via loadlin) après avoir exécuté le pilote DOS fourni ou le programme de configuration de la carte. Il se peut qu'il exécute quelques tours de passe-passe supplémentaires (c'est-à-dire non standards) pour initialiser la carte. 8) Essayez le pilote en mode paquet (packet driver) 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 matérielle, 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 numéro plus récent que 11. 3.5 Problèmes avec les cartes SMC Ultra/EtherEZ et WD80*3 _Problème :_ Vous obtenez des messages semblables à : eth0: bogus packet size: 65531, status=0xff, nxpg=0xff _Raison :_ Il y a un problème de mémoire partagée. _Solution :_ Les machines PCI qui n'ont pas été configurées pour traduire les périphériques ISA en mémoire constituent la source la plus courante pour ce problème. De fait vous lisez la mémoire vive du PC (toutes les valeurs 0xff que donne le message) au lieu de la mémoire vive de la carte, qui elle contient les données du paquet reçu. D'autres problèmes courants qui eux sont faciles à régler sont des conflits de carte, le fait d'avoir activé le cache ou la mémoire morte 'shadow ROM' pour cette zone, ou encore de faire fonctionner le bus ISA plus vite que 8 MHz. Il existe aussi un nombre étonnant de pannes de la mémoire sur les cartes Ethernet, donc utilisez le programme de diagnostic si vous en avez un pour votre carte Ethernet. _Problème :_ Une carte EtherEZ de SMC ne fonctionne pas en mode de mémoire non-partagée (PIO). _Raison :_ Les versions les plus anciennes du pilote Ultra ne pouvaient utiliser la carte que dans le mode de travail à mémoire partagée. _Solution :_ Le pilote de la version 2.0 (et supérieures) sait aussi utiliser le mode d'E/S programmées (PIO). Mettez votre noyau à jour vers une version 2.0 ou plus récente. _Problème :_ 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 possèdent pas l'EEPROM que le pilote sait lire pour y trouver le paramétrage de l'IRQ. Si le pilote ne sait pas lire l'IRQ, il essaie de déterminer automatiquement l'IRQ. Et si la procédure de détection automatique retourne zéro, le pilote se contente d'affecter l'IRQ 5 pour une carte 8 bits ou l'IRQ 10 pour une carte 16 bits. _Solution :_ Evitez le code de détection automatique de l'IRQ, et indiquez au noyau la valeur d'IRQ que vous avez configurée sur la carte avec les cavaliers en la lui passant comme argument dans votre fichier de configuration de modules (ou au démarrage si vous l'avez compilé dans le noyau). _Problème :_ Une carte SMC Ultra est détectée comme étant une wd8013, mais l'IRQ et l'adresse de base de la mémoire partagée sont fausses. _Raison :_ La carte Ultra ressemble beaucoup à une wd8013, et si le pilote Ultra n'est pas présent dans le noyau, le pilote wd peut identifier l'Ultra comme étant une wd8013. Le test de détection de l'Ultra vient avant celui de la wd, donc ceci ne devrait normalement pas se produire. L'Ultra stocke l'IRQ et l'adresse de base dans son EEPROM de façon différente à celle d'une wd8013, d'où les valeurs erronées indiquées par le pilote. _Solution :_ Recompilez le noyau en n'intégrant que les pilotes dont vous avez besoin. Si vous avez un mélange de cartes wd et Ultra dans une machine, et que vous utilisez les modules, chargez le module ultra en premier. 3.6 Problèmes avec des cartes 3Com _Problème :_ La 3c503 prend l'IRQ N, mais celle-ci est requise par un autre périphérique qui a besoin de l'IRQ N (par exemple un pilote de CD-ROM, un modem, etc.). Est-ce que cela peut être réparé sans devoir le compiler dans le noyau ? _Solution :_ Le pilote 3c503 recherche une ligne d'IRQ libre dans l'ordre {5, 9/2, 3, 4}, et il devrait prendre une ligne qui n'a pas été utilisée. Le pilote effectue ce choix lorsque la carte est configurée (ifconfig). Si vous utilisez un pilote en module, vous pouvez vous servir des paramètres du module afin de choisir diverses choses, y compris la valeur d'IRQ. Ce qui suit sélectionne l'IRQ 9, adresse de base 0x300, , et le port if_port numéro 1 (le transceiver externe). io=0x300 irq=9 xcvr=1 Autrement, si le pilote est compilé dans le noyau, vous pouvez choisir les mêmes valeurs en passant des paramètres _via_ LILO. LILO: linux ether=9,0x300,0,1,eth0 Ce qui suit sélectionne l'IRQ 3, détecte l'adresse de base, , et le port par défaut (if_port) numéro 0 (le transceiver interne). LILO: linux ether=3,0,0,0,eth0 _Problème :_ 3c503: configured interrupt X invalid, will use autoIRQ. (3c503: l'interruption X configurée est invalide, détection 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 connectées à la carte). Si vous passez en argument au noyau une valeur d'IRQ qui n'est pas dans cet ensemble, vous obtiendrez le message ci-dessus. Normalement, il n'est pas nécessaire de spécifier une valeur d'interruption pour la 3c503. Elle passera en détection automatique lorsqu'elle sera configurée (par ifconfig), et elle prendra l'une des IRQ 5, 2/9, 3 ou 4. _Solution :_ Utilisez l'une des IRQ valides données ci-dessus, ou autorisez la détection automatique en ne précisant aucune ligne d'IRQ. _Problème :_ Le pilote 3c503 fourni n'utilise pas le port AUI (gros Ethernet). Comment faire pour le choisir au lieu du port Ethernet fin par défaut ? _Solution :_ Le port AUI peut être sélectionné au démarrage pour les pilotes compilés dans le noyau, et lors de l'insertion du module pour les pilotes modulaires. La sélection est réalisée par le bit de poids le plus faible de la variable dev->rmem_start qui n'est actuellement pas utilisée, donc un paramètre de démarrage comme : LILO: linux ether=0,0,0,1,eth0 devrait fonctionner pour les pilotes compilés dans le noyau. Pour spécifier le port AUI lorsque vous chargez un module, ajoutez simplement xcvr=1 à 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 spécifiques à une carte. Linux et les cartes Ethernet ISA Plug and Play Pour de meilleurs résultats (et au moins, rien qui empire) il est recommandé que vous utilisiez le petit programme qui a été livré avec la carte pour désactiver le mécanisme PnP, et régler la carte pour utiliser une IRQ et une adresse d'E/S fixe. Assurez-vous que l'adresse d'E/S que vous allez utiliser est testée lors du boot, ou si vous utilisez des modules, donnez les adresses avec une option io= dans votre /etc/conf.modules. Vous aurez certainement aussi à entrer dans le BIOS et à marquer l'IRQ en question comme utilisée par une carte ISA, et non disponible pour le PnP (si votre ordinateur à cette option). Notez que vous n'avez pas besoin d'installer le DOS pour lancer la configuration. Vous n'aurez besoin que d'une disquette de boot DOS et de lancer le programme depuis la disquette fournie. Vous pouvez aussi télécharger OpenDOS ou FreeDOS gratuitement. Si vous avez besoin d'avoir le PnP activé pour rester compatible avec un autre système d'exploitation, alors, vous aurez à utiliser le paquetage isapnptools avec Linux pour configurer la carte à chaque boot. Vous aurez quand même à vous assurer que l'adresse d'E/S est testée par le pilote au démarrage, ou fourni comme option io=. Carte Ethernet non détectée au démarrage. La raison habituelle de cet état de fait est que les gens utilisent un noyau qui ne contient pas le code pour leur carte à eux. Pour un noyau modulaire, cela signifie généralement que le chargement du module nécessaire n'a pas été demandé, ou qu'une adresse d'E/S a besoin d'être spécifiée comme option du module. Si vous utilisez un noyau basé sur les modules, comme ceux installés par la plupart des distributions Linux, essayez alors d'utiliser l'utilitaire de configuration de la distribution pour sélectionner le module destiné à votre carte. Pour les cartes ISA, c'est une bonne idée que de déterminer l'adresse d'E/S de la carte et de l'ajouter comme option (p. ex. 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 détails. Si vous utilisez un noyau précompilé qui provient d'une distribution Linux, vérifiez dans la documentation quel noyau vous avez installé, et s'il a été construit en incluant le code pour votre carte à vous. Si ce n'est pas le cas, vous pouvez soit essayer d'en obtenir un qui contient le code pour votre carte, soit construire votre propre noyau. C'est en général une bonne chose que de construire votre propre noyau, ne contenant que les pilotes dont vous avez besoin, car cela diminue considérablement la taille du noyau (préservant d'autant votre précieuse mémoire vive pour les applications !) et cela réduit le nombre de procédure de détection de périphériques qui peuvent déranger le matériel un peu sensible. Construire un nouveau noyau n'est pas aussi compliqué que cela peut paraître. Vous devez juste répondre oui ou non à toute une série de questions sur les pilotes que vous voulez, et le système fait le reste. La seconde raison essentielle est qu'un autre périphérique utilise une partie de l'espace d'adressage d'entrée-sortie dont votre carte a besoin. La plupart des cartes ont une zone d'adressage qui mesure 16 ou 32 bits de largeur. Si votre carte est positionnée en 0x300 et qu'elle prend 32 octets, alors le pilote demandera la plage d'adresses 0x300-0x31f. Si un autre pilote de périphérique a enregistré ne serait-ce qu'un port d'entrée-sortie, où que ce soit dans cet intervalle, la procédure de détection n'aura pas lieu à cette adresse et le pilote continuera sans rien dire à l'adresse suivante à tester. Donc, après le démarrage, faites un cat /proc/ioports et vérifiez que tout l'espace d'adressage d'entrée-sortie que la carte demandera est bien disponible. Autre problème : votre carte est configurée pour une adresse d'entrée-sortie qui n'est pas testée par défaut. La liste des adresses testées pour chaque carte est disponible juste après les commentaires de début dans chaque fichier source. Même si la configuration d'E/S de votre carte n'est pas dans la liste des adresses testées, vous pouvez l'indiquer au démarrage (pour les pilotes compilés dans le noyeau en utilisant la commande ether= comme il est décrit dans Passage des arguments Ethernet.... Les pilotes modulaires peuvent utiliser l'option io= dans le fichier /etc/conf.modules afin de spécifier une adresse qui n'est pas testée par défaut. ifconfig indique la mauvaise adresse d'E/S pour la carte. Non, ce n'est pas vrai. C'est vous qui l'interprétez de manière erronée. Ce n'est _pas_ une erreur, et les nombres indiqués sont corrects. Ce qu'il se passe, c'est que certaines cartes à base de 8390 (wd80x3, smc-ultra, etc.) sont telles que la puce 8390 se trouve décalée par rapport au premier port d'E/S affecté. Il s'agit de la valeur stockée dans 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. Une machine PCI détecte la carte mais la procédure de test du piloteéchoue. Certains BIOS PCI peuvent ne pas activer toutes les cartes PCI lors de l'allumage de la machine, spécialement si l'option `PNP OS' du BIOS est activée. Cette contre-fonctionnalité est destinée à supporter la version actuelle de Windows qui utilise encore des pilotes en mode réel. Vous pouvez soit inhiber cette option, soit essayer de mettre à jour votre pilote pour une version qui comprend le code capable d'activer une carte désactivée. Des cartes ISA à mémoire partagée ne fonctionnent pas dans une machinePCI (0xffff) Ce problème se révèle habituellement sous la forme d'une série de valeurs 0xffff en lecture. Aucune carte à mémoire partagée de quelque type que ce soit ne fonctionnera dans une machine PCI à moins que vous n'ayez configuré correctement le BIOS PCI (PCI ROM BIOS/CMOS SETUP ou quelque chose comme ça). Vous devez le configurer pour permettre l'accès à la mémoire partagée depuis le bus ISA pour la zone d'adresses que votre carte essaie d'utiliser. Si vous n'arrivez pas à déterminer quels paramètres sont concernés, interrogez votre revendeur ou votre gourou informatique local. Dans un BIOS AMI (American Megatrends Inc.), il existe en général une section ``Plug and Play'' où se trouveront sans doute des paramètres ``ISA Shared Memory Size'' (taille de la mémoire partagée ISA) et ``ISA Shared Memory Base'' (adresse de base de la mémoire partagée ISA). Pour des cartes comme la wd8013 et la SMC Ultra, changez la taille de sa valeur par défaut (`Disabled', désactivé) à une valeur de 16 Ko, et changez l'adresse de base en prenant l'adresse de base de mémoire partagée qui correspond à votre carte. On dirait que ma carte envoie des données, mais elle ne reçoit jamaisrien. Faites un cat /proc/interrupts. Le nombre total d'interruptions générées par la carte vous sera donné. S'il est à zéro et qu'il n'augmente pas lorsque vous essayez d'utiliser la carte, alors, il y a très certainement un conflit d'interruptions entre la carte et un autre périphérique installé (que le pilote de l'autre soit chargé ou non). La seule solution est de changer l'IRQ de l'un des deux périphériques pour une autre IRQ non utilisée. Asynchronous Transfer Mode (ATM) Werner Almesberger s'est préoccupé de la disponibilité d'ATM pour Linux. Il a travaillé avec la carte ENI155p d'Efficient Networks ( Efficient Networks) et la carte ZN1221 de Zeitnet ( Zeitnet). Werner dit que le pilote de la ENI155p est relativement stable, tandis que celui de la ZN1221 n'est actuellement pas terminé. Consultez les dernières informations et les mises à jour à l'URL suivante : Linux et ATM Support de l'Ethernet Gigabit Où en est le support Ethernet Gigabit pour Linux ? Il y a pour le moment au moins deux supports. Un pilote pour l'adaptateur Ethernet Gigabit G-NIC PCI de Packet Engines est disponible dans les versions 2.0 et 2.2 du noyau. Pour plus de détails, d'information, et les mises à jour du pilote, consultez : http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html Le pilote acenic.c disponible dans les noyaux 2.2 peut être utilisé pour la carte Ethernet Gigabit Alteon AceNIC et d'autres cartes basées sur le chipset Tigon comme la 3Com 3c985. Le pilote devrait aussi fonctionner avec la NetGear GA620, mais cela n'a pas encore été vérifié. FDDI Qu'en est-il de FDDI sous Linux ? Cela fonctionne. Larry Stefani a écrit un pilote pour la version 2.0 du noyau pour les cartes DEFEA (FDDI EISA) et DEFPA (FDDI PCI) de DEC (Digital Equipment Corporation). Il a été inclus dans la version 2.0.24 du noyau. Néanmoins, ce sont les seules cartes qui fonctionnent sous Linux actuellement. 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 écrit ce qui suit à propos des cartes Full Duplex 10Base-T : ``Si vous connectez une carte Full Duplex à un hub (NDT : un switch) Full Duplex, et que votre système est suffisamment rapide et ne fait pas grand-chose d'autre, il pourra maintenir le lien occupé dans les deux directions. Le Full Duplex 10Base-2 ou 10Base-5 (coaxial fin et gros coaxial) ne peut pas exister. Le mode Full Duplex fontionne en inhibant la détection des collisions dans l'adaptateur réseau. C'est pour cela que vous ne pouvez pas le faire avec un coax : le réseau ne fonctionnerait pas si c'était le cas. Par contre, 10Base-T (l'interface RJ-45) utilise des (paires de) fils séparées pour l'émission et la réception, donc il est possible de travailler dans les deux sens en même temps. Le (hub) switch s'occupe du problème des collisions. La vitesse de signalisation reste à 10 Mbit/s.'' Donc, comme vous pouvez voir, vous ne serez encore capable de recevoir ou de transmettre qu'à 10 Mbit/s; n'attendez donc pas une multiplication par deux des performances. Quant à savoir si cela est possible ou non, cela dépend de la carte et peut-être du pilote. Certaines cartes pratiquent l'auto-négociation, d'autres auront besoin de l'aide du pilote, et d'autres auront besoin que l'utilisateur choisisse une option dans la configuration sur EEPROM de la carte. De toute façon, seule une utilisation sérieuse/lourde montrera une différence entre les deux modes. Les machines SMP et les cartes Ethernet Si vous avez dépensé un peu d'argent en plus pour avoir une machine multiprocesseur (MP), alors, vous devriez aussi vous payer une bonne carte Ethernet. Pour les versions 2.0, cela n'était pas vraiment une obligation, mais avec l'avènement des 2.2, cela est devenu nécessaire. La majorité des vieilles cartes (ex : ISA, PIO et avec accès partagé à la mémoire) n'ont pas été conçues en pensant aux machines multiprocesseurs. Par conséquent, il vous faudra acheter une carte de facture récente, et vous assurer que le pilote a été mis a jour pour gérer les opérations multiprocesseurs. (Le plus important, c'est le "de facture récente" - les PCI-NE2000 sont juste des trucs vieux de plus de 10 ans sur un bus récent.) Chercher spin_lock dans les sources d'un pilote donne une bonne indication sur le fait que le pilote a été prévu pour marcher sur les machines multiprocesseurs. Pour plus de détails sur pourquoi vous devez prendre une bonne carte pour le MP (et ce qui se passera si vous ne le faites pas) se trouve ci dessous : Dans la version 2.0 des noyaux, seul un processeur était autorisé a passer en `mode noyau' (ex : changer des données dans le noyau, ou accéder aux périphériques), quelque soit le moment. Donc, du point de vue de la carte (et du pilote associé) il n'y avait aucune différence avec le fonctionnement en monoprocesseur (UP) et tout continuait à marcher comme si de rien n'était. (C'était la façon la plus simple de faire du multiprocesseur avec Linux à ce moment-là. De cette manière, vous savez qu'il n'est pas possible que deux processeurs essayent de changer la même chose au même moment !) L'inconvénient de n'autoriser qu'un seul processeur à être en mode noyau au même moment était que vous n'aviez de vraies performances MP que si les programmes faisaient surtout du calcul sans accéder à la machine. Si les programmes faisaient beaucoup d'opérations d'entrées sorties (E/S), comme par exemple lire ou écrire sur un disque ou à travers un réseau, alors, tous les processeurs sauf un étaient en attente d'une opération d'E/S pendant que le seul processeur en mode noyau essayait de faire plaisir à tout le monde à la fois. Le noyau devient le goulot d'étranglement et comme un seul processeur est autorisé à exécuter le noyau, les performances d'une machine MP se réduisaient rapidement à celles d'une machine UP. Comme cela est clairement loin de l'idéal (spécialement pour les serveurs de fichiers, les serveurs WWW, les routeurs, etc...) les versions 2.2 des noyaux ont largement amélioré tout ce qui touche aux verrouillages - et par conséquent, plus d'un processeur peut être en mode noyau à un instant donné. A la place d'un énorme verrou autour du noyau dans sa globalité, il y a beaucoup plus de verrous plus petits qui empêchent les données critiques d'êtres manipulées par plus d'un processeur à la fois - ex : un processeur peut s'occuper du réseau alors qu'un autre peut écrire sur un disque au même moment. Ok, avec tout cela en tête, voici deux petits problèmes : Des verrous plus localisés signifient qu'il peut y avoir un processeur essayant d'envoyer les données via le pilote ethernet pendant qu'un autre processeur essaye d'accéder à la carte pour autre chose (par exemple pour récupérer les statistiques pour cat /proc/net/dev). Et hop - les statistiques ont été envoyées par la carte et vous avez récupéré les données à envoyer pour les statistiques. Eh oui, la carte a bien été embêtée de recevoir plusieurs demandes à la fois, et il y a de fortes chance que cela ait planté la machine du même coup. Par conséquent, le pilote qui marchait pour les machines UP n'est désormais plus vraiment utilisable - on doit y ajouter des verrous qui contrôlent l'accès à la carte pour que les 3 actions de recevoir, émettre et manipuler les données puissent être utilisées à divers degrés d'opération. Le truc qui peut faire peur est qu'un pilote qui n'a pas été mis a jour pour fonctionner de manière stable en MP marchera très probablement si le réseau n'est pas chargé, mais fera planter la machine ou fera de drôles de choses lorsque deux (ou plus !) processeurs essaieront de faire plus d'une de ces opérations au même moment. Les pilotes ethernet gérant le MP requièreront (au minimum) un verrouillage englobant tout le pilote pour qu'il fonctionne sur le principe de `chacun son tour'. Avec ce mécanisme mis en place, les choses seront mises en files d'attente et le matériel sera utilisé de la même manière qu'en mode UP, et par conséquent, devrait être stable. Le coté négatif est que un verrouillage englobant le pilote ethernet a presque d'aussi mauvaises performances qu'un verrou global sur le noyau (mais a une échelle plus réduite) - c'est à dire que vous ne pouvez avoir qu'un seul processeur travaillant avec la carte à la fois. [Note technique : L'impact sur les performances peut aussi inclure l'augmentation des temps de latence sur les interruptions si les verrous qui ont besoin d'être ajoutés sont du type irqsave et qu'ils sont tenus fermés pour un long moment.] Il existe deux voies d'amélioration possibles à partir de cette situation. Vous pouvez essayer de minimiser le temps entre le moment où le verrou est fermé et quand il est relâché et/ou vous pouvez trouver une manière plus fine, avec plus de verrous (ex : un verrou global sur le pilote ne serait pas nécessaire si quelques verrous protégeant quelques registres/réglages critiques suffisent). Toutefois, pour les vieilles cartes débiles qui n'ont pas été conçues dans l'esprit du MP, aucune de ces améliorations n'est possible. Le pire est que ces pauvres cartes requièrent que le processeur déplace les données de la carte vers la mémoire de l'ordinateur, donc, dans le pire des cas le verrou sera fermé pour toute la durée que chaque paquet de 1,5 Ko mettra à transiter à travers le bus ISA. Les cartes plus récentes déplacent leurs données de et vers la mémoire sans avoir recours au processeur. Ceci est une grande amélioration car le verrouillage ne dure que le court instant où le processeur dit à la carte où dans la mémoire prendre/mettre les données. Les cartes de facture récente ne sont d'ailleurs pas faites pour avoir un verrou global autour du pilote. Cartes Ethernet pour Linux sur carte-mère 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 été rendus `indépendants de l'architecture' de façon à pouvoir fonctionner sur les systèmes basés sur les processeurs Alpha de DEC. D'autres pilotes PCI mis à jour sont disponibles sur la page WWW de Donald marcheront certainement, puisqu'ils ont été créés pour être indépendants de l'architecture. Notez que les changements à faire pour que le pilote ne soit pas dépendant de l'architecture ne sont pas aussi compliqués que cela peut paraître. Vous n'avez besoin que de : - multiplier toutes les valeurs relatives à des jiffies par HZ/100 pour prendre en compte la valeur différente de HZ utilisée par l'Alpha. (c'est-à-dire que timeout=2; devient timeout=2*HZ/100;) - remplacer tout déréférencement de pointeur en mémoire d'E/S (640k à 1Mo) par les appels readb() writeb() readl() writel() appropriés, 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 à memcpy() qui ont des adresses mémoire sur la plage d'E/S comme source ou comme destination par un appel à memcpy_fromio() ou à memcpy_toio() selon le cas. Vous trouverez plus de détails sur la manière de gérer les accès mémoire d'une façon indépendante de l'architecture dans le fichier linux/Documentation/IO-mapping.txt qui est présent dans les noyaux récents. L'Ethernet et Linux sur les SUN/Sparc. Pour les dernières informations à propos des Sparc, essayez donc l'URL suivante : Linux Sparc Notez que quelques adaptateurs ethernet pour Sparc récupèrent leurs adresses MAC depuis l'ordinateur hôte, et que par conséquent, vous pourriez vous retrouver avec plusieurs interfaces ayant toutes les mêmes adresses MAC. Si vous devez mettre plusieurs interfaces sur la même machine, alors, vous aurez à utiliser l'option hw de ifconfig pour assigner une unique adresse MAC. Les problèmes de portage des pilotes PCI vers la plate-forme Sparc sont les mêmes que pour la plate-forme AXP. En plus, il y aura certainement des problèmes d'ordre des octets, le Sparc étant grand boutiste alors que les AXP et ix86 sont petits boutistes. L'Ethernet, Linux et les autres architectures. Il y a beaucoup d'autres plate formes sur lesquelles Linux tourne, comme les Atari/Amiga (m68k). Tout comme dans le cas des Sparc, le mieux est de vérifier sur la page principale du port pour savoir ce qui est supporté. (Des pointeurs seraient bienvenus - envoyez les !) Relier deux 10 et 100 BaseT sans hub Est-ce que je peux relier deux systèmes basés sur du 10/100BaseT (RJ45) sans utiliser de hub ? Vous pouvez relier facilement deux machines, mais pas plus que cela, sans boîtier supplémentaire. Consultez la section Paire torsadée qui explique comment faire. Par contre, non, vous n'arriverez pas à bricoler un hub en croisant quelques fils et autres trucs du genre. Il est pratiquement impossible de générer correctement le signal de collision sans refaire un hub. SIOCSIFxxx: No such device J'obtiens un nombre impressionnant de messages `SIOCSIFxxx: No such device' au démarrage, suivis par un `SIOCADDRT: Network is unreachable'. Qu'est-ce qui ne va pas ? Votre périphérique Ethernet n'a pas été détecté pendant le démarrage / lors de l'insertion du module, et lorsque ifconfig et route sont exécutés, ils n'ont aucun périphérique avec lequel travailler. Utilisez dmesg | more pour consulter les messages du démarrage et regardez s'il y a un (ou des) message(s) à propos de la détection de carte Ethernet. SIOCSFFLAGS: Try again J'obtiens `SIOCSFFLAGS: Try again' lorsque j'exécute ifconfig -- Euh.. ? Un autre périphérique a pris l'IRQ que votre carte Ethernet essaie d'utiliser, ce qui fait que la carte ne peut pas utiliser l'IRQ. Vous n'avez pas nécessairement besoin de redémarrer pour résoudre ce problème, car certains périphériques ne prennent les IRQ que lorsqu'ils en ont besoin, et les rendent quand ils ont fini. C'est le cas par exemple des cartes son, des ports série, du pilote du lecteur de disquette, etc. Vous pouvez taper cat /proc/interrupts pour voir quelles interruptions sont actuellement _en cours d'utilisation_. La plupart des pilotes de carte Ethernet sous Linux ne prennent l'IRQ que lorsqu'ils sont ouverts via `ifconfig'. Si vous réussissez à faire en sorte que l'autre périphérique `relâche' la ligne d'IRQ, alors vous serez capable de réessayer (_Try again_ en anglais) avec ifconfig. Utilisation de `ifconfig' et message `Link UNSPEC with HW-addr of00:00:00:00:00:00' Lorsque j'utilise ifconfig sans argument, il indique Link UNPSEC (au lieu de `Ethernet 10Mbs') et il dit aussi que mon adresse physique est à zéro. C'est parce que les gens utilisent une version du programme `ifconfig' plus récente que leur version de noyau. Cette nouvelle version de `ifconfig' est incapable de fournir ces informations quand elle est utilisée en conjonction avec un noyau plus ancien. Vous pouvez soit mettre votre noyau à jour, soit prendre une version plus ancienne d'ifconfig, ou simplement ignorer le problème. Le noyau connaît votre adresse physique, donc le fait que ifconfig ne puisse pas la lire n'est pas vraiment important. Vous pourrez aussi obtenir des informations étranges si le programme ifconfig que vous utilisez est beaucoup plus vieux que votre noyau. Nombre faramineux d'erreurs en réception (RX Errors) et en transmission(TX Errors) Quand j'exécute ifconfig sans argument, il indique que j'ai un nombre faramineux d'erreurs à la fois dans les paquets reçus et dans les paquets transmis. Pourtant tout semble fonctionner correctement -- Est-ce que je me trompe ? Regardez de nouveau. ifconfig indique : RX packets _gros nombre_ _BLANC_ errors 0 _BLANC_ dropped 0 _BLANC_ overrun 0. Même chose pour la colonne avec TX. Les grands nombres que vous voyez sont donc le nombre total de paquets que votre machine a reçus et transmis. Si vous trouvez encore que c'est source de confusion, essayez de taper cat /proc/net/dev à la place. Liens dans /dev/ pour cartes Ethernet J'ai /dev/eth0 qui est un lien vers /dev/xxx. Est-ce que c'est bon ? Contrairement à ce que vous avez entendu dire, les fichiers dans /dev/* ne sont pas utilisés. Vous pouvez détruire tous les /dev/wd0, /dev/ne0 et ce qui y ressemble. Linux et les ``trailers'' (amorces) Dois-je désactiver les ``trailers'' quand je `ifconfig'ure ma carte Ethernet ? Vous ne pouvez pas désactiver les ``trailers'', et vous ne devriez pas en avoir envie. Les ``trailers'' sont une astuce de programmation pour éviter des copies de données dans les couches réseau. L'idée était d'utiliser un en-tête simpliste de taille fixe `H', de mettre les informations de l'entête de taille variable à la fin du paquet, et d'allouer tous les paquets `H' octets avant le début d'une page. Alors qu'il s'agissait d'une bonne idée, en pratique cela n'a pas très bien fonctionné. Si quelqu'un suggère l'utilisation de `-trailers', notez bien que c'est l'équivalent du sang de chèvres sacrifiées. Cela ne résoudra pas le problème, mais si le problème se résoud tout seul, quelqu'un pourra invoquer des connaissances approfondies en magie. Accès direct au périphérique Ethernet Comment puis-je avoir accès directement au périphérique Ethernet sous Linux, sans avoir à 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 périphérique dans le champ sa_family et le nom du périphérique dans le tableau sa_data. Je ne sais pas qui a inventé SOCK_PACKET pour Linux (cela fait une éternité qu'il est là), mais c'est du beau travail. Vous pouvez l'utiliser pour envoyer des choses directement en utilisant l'appel sendto(). Bien entendu, vous devez être root pour pouvoir faire l'ensemble de ces opérations. 4. Trucs et astuces à 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 où mon_gros_fichier fait plus d'un Mo et réside dans le cache disque de la machine qui transmet. (Faites le `get' au moins deux fois, car la première fois ce cache sera vide.) Vous avez besoin que le fichier soit dans le cache car il faut éviter que le temps d'accès au fichier influe sur votre mesure. C'est pour la même raison que vous envoyez les données qui arrivent vers /dev/null plutôt que vers le disque. 4.1 Concepts génériques Même une carte 8 bits est capable de recevoir des paquets qui se suivent (_back-to-back paquets_ en anglais) sans aucun problème. Les difficultés apparaissent quand l'ordinateur n'enlève pas suffisamment rapidement de la carte les paquets reçus pour faire de la place pour d'autres paquets entrants. Si l'ordinateur ne supprime pas rapidement les paquets déjà reçus de la mémoire de la carte , celle-ci n'aura pas assez de place pour mettre les nouveaux paquets. Dans ce cas, soit la carte détruit le nouveau paquet, soit elle réécrit sur un paquet déjà reçu. Les deux solutions interrompent brutalement le flux du trafic, nécessitent des re-transmissions et peuvent sérieusement dégrader les performances d'un facteur qui va jusqu'à 5 ! Les cartes qui possèdent plus de mémoire sont capables de conserver plus de paquets, et peuvent donc supporter de gros pics de paquets successifs sans détruire de paquets. Par conséquent cela signifie que la carte n'exige pas de l'ordinateur un temps de latence aussi faible pour enlever les paquets sans avoir à en détruire. La plupart des cartes 8 bits ont un tampon de 8 Ko, et la plupart des cartes 16 bits ont un tampon de 16 Ko. La plupart des pilotes sous Linux réserveront 3 Ko de ce tampon (pour deux tampons de transmission), laissant 5 Ko d'espace de réception pour une carte 8 bits. Cela ne laisse de la place que pour 3 paquets Ethernet de pleine taille (1500 octets). 4.2 La vitesse des cartes et du bus ISA Comme indiqué précédemment, si les paquets sont enlevés de la carte suffisamment rapidement, le problème de destruction ou de surcharge n'apparaît pas même si la taille mémoire du tampon de réception est petite. Le facteur qui détermine la rapidité avec laquelle les paquets sont enlevés de la carte pour être placés dans la mémoire de l'ordinateur est la vitesse du chemin que devront suivre les données entre les deux -- c'est-à-dire la vitesse du bus ISA. (Si le processeur est un 386sx-16 poussif, cela jouera aussi un rôle.) La vitesse d'horloge recommandée pour un bus ISA est de 8 MHz, mais de nombreuses cartes-mères et de nombreux périphériques peuvent être utilisés à des fréquences plus élevées. La vitesse d'horloge du bus ISA peut en général être modifiée dans la configuration CMOS, en choisissant le rapport entre la fréquence du processeur et celle de la carte-mère. Certaines cartes-mères n'auront pas cette option, et vous serez coincés avec la valeur par défaut. Par exemple, voici quelques vitesses de réception mesurées par le programme TTCP sur un 486 à 40 MHz, avec une carte 8 bits WD8003EP, pour des vitesses différentes du bus ISA. Vitesse du bus ISA (MHz) TTCP - réception (Ko/s) ------------------------ ----------------------- 6.7 740 13.4 970 20.0 1030 26.7 1075 Vous auriez du mal à faire mieux que 1075 Ko/s avec _n'importe quelle_ carte Ethernet 10 Mo/s, en utilisant TCP/IP. Néanmoins ne vous attendez pas à ce que tous les systèmes puissent travailler à des vitesses de bus ISA rapides. La plupart des systèmes ne fonctionneront pas correctement à des vitesses au-dessus de 13 MHz. (De même, certains systèmes PCI fixent la vitesse du bus ISA à 8 MHz, afin que l'utilisateur final n'ait pas la possibilité de pouvoir l'augmenter.) En plus de vitesses de transferts supérieures, vous profiterez aussi en général d'une réduction de l'utilisation du processeur due à la durée plus courte des cycles mémoires et d'E/S. (Notez que les disques durs et les cartes vidéo situées sur le bus ISA afficheront aussi de meilleures performances avec une vitesse du bus ISA plus élevée.) Soyez sûr de sauvegarder toutes vos données avant de faire des expériences avec des vitesses du bus ISA au-dessus de 8 MHz, et de tester attentivement que tous les périphériques ISA fonctionnent correctement après toute augmentation de vitesse. 4.3 Modifier la fenêtre de réception TCP Une fois encore, les cartes qui possèdent peu de mémoire et un trajet des données entre la carte et la mémoire de l'ordinateur plutôt lent provoquent des problèmes. La fenêtre de réception TCP est réglée par défaut à 32 Ko, ce qui signifie qu'un ordinateur rapide situé sur le même sous-réseau que vous pourra vous inonder de 32 Ko de données sans s'arrêter pour regarder si vous en avez reçu le moindre morceau. Les versions récentes de la commande route donnent la possibilité de régler la largeur de cette fenêtre à la volée. En général, cette fenêtre ne doit être réduite que pour le réseau local, puisque les ordinateurs qui sont à quelques routeurs ou passerelles de distance ont suffisamment de `tampons' intermédiaires pour ne pas poser de problème. Un exemple d'utilisation est : _________________________________________________________________ route add ... window _________________________________________________________________ où largeur_de_fenetre est la largeur de la fenêtre que vous voulez utiliser (en octets). Une carte 8 bits 3c503 sur un bus ISA fonctionnant à une vitesse de 8 MHz ou moins tournera correctement avec une fenêtre d'environ 4 Ko. Une fenêtre trop large causera des surcharges et des pertes de paquets, et une diminution drastique du débit Ethernet. Vous pouvez vérifier les conditions de travail de la carte en faisant un 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 remarqué que l'utilisation de cartes 8 bits sur des clients NFS donne des performances moins bonnes que celles attendues, en utilisant une taille de paquet NFS de 8Ko (celle donnée à l'origine par Sun). La raison possible de tout cela pourrait être la différence entre la taille des tampons des cartes 8 bits et celle des cartes 16 bits. La taille maximale d'un paquet Ethernet est d'environ 1500 octets. Maintenant que nous faisons du NFS, des paquets NFS de 8 Ko vont arriver sous la forme de 6 paquets de taille maximale à la queue-leu-leu. Ni les cartes 8 bits ni les cartes 16 bits n'ont de problème à recevoir ces paquets les uns derrière les autres. Le problème se produit parce que la machine n'enlève pas les paquets à temps de la carte, et que le tampon déborde. Le fait que les cartes 8 bits nécessitent un cycle du bus ISA supplémentaire pour chaque transfert n'aide pas beaucoup, par ailleurs. Ce que vous _pouvez_ faire si vous avez une carte 8bits est soit de diminuer la taille de transfert NFS à 2 Ko (voire 1 Ko), soit d'essayer d'augmenter la vitesse du bus ISA afin que les tampons de la carte soient vidés plus rapidement. J'ai trouvé qu'une vieille carte WD8003E à 8 MHz (sans autre charge système) peut soutenir une réception de taille importante avec une taille NFS de 2 Ko, mais pas à 4 Ko, auquel cas les performances étaient dégradées d'un facteur trois. D'un autre coté, si l'option par défaut est d'utiliser des blocs de 1 Ko, et que vous avez au moins une carte ISA 16 bits, vous aurez certainement de meilleures performances en passant a 4 Ko (ou même 8 Ko). 5. Informations spécifiques par distributeur/constructeur/modèle Ce qui suit est une liste de nombreuses cartes, rangées par ordre alphabétique de distributeur, puis par identifiant de produit. A côté de chaque identifiant de produit, vous verrez soit `supporté', soit `partiellement supporté', soit `non supporté'. `Supporté' signifie qu'un pilote existe pour cette carte, que de nombreuses personnes en sont contentes et qu'il semble fiable. `Partiellement supporté' signifie qu'un pilote existe, mais que l'une au moins des conditions suivantes est vraie : (1) Le pilote et/ou le matériel comportent des erreurs, ce qui peut engendrer de piètres performances, des échecs de connexion ou même des crashs. (2) Le pilote est récent ou la carte est très peu connue, et par conséquent celui-ci a été peu utilisé/testé et son auteur a eu très peu de retours quant à son fonctionnement. Il est évident que la situation (2) est préférable à la situation (1), et la description de la carte et du pilote devrait montrer clairement laquelle est la bonne. Dans un cas comme dans l'autre, vous devrez certainement répondre 'Y' à la question ``Prompt for development and/or incomplete code/drivers?'' (``Demander confirmation pour pour les pilotes en cours de développement ou incomplets ?'') lorsque vous lancerez make config. `Non supporté' signifie qu'il n'existe pas de pilote disponible à l'heure actuelle pour cette carte. Cela peut être dû à un manque d'intérêt pour un matériel qui est rare ou peu commun, ou au fait que les distributeurs n'en fournissent pas la documentation nécessaire pour l'écriture du pilote. Notez que la différence entre `supporté' et `partiellement supporté' est plutôt subjective, et qu'elle est basée sur les retours d'informations fournis par les utilisateurs, observés dans les groupes de news et les listes de diffusion. (Après tout, il est impossible à une personne de tester tous les pilotes avec toutes les cartes pour chaque version du noyau !!!) Soyez donc prévenus que telle carte indiquée comme `partiellement supportée' pourra fonctionner impeccablement pour vous (ce qui est bien), alors que telle autre indiquée comme `supportée' vous donnera des problèmes sans fin (ce qui n'est pas aussi bien). Après le statut, le nom du pilote donné dans le noyau de Linux est indiqué. Ceci sera aussi le nom du module tel qu'il apparait à la ligne alias eth0 pilote dans votre fichier de configuration /etc/conf.modules. 5.1 3Com Si vous n'êtes pas sûr de ce qu'est votre carte, mais que vous pensez qu'il s'agit d'une 3Com, vous pourrez certainement le déterminer à partir du numéro d'assemblage. 3Com dispose d'un document `Identifying 3Com Adapters By Assembly Number' (Identifier les adaptateurs 3Com par leur numéro d'assemblage, référence 24500002) qui devrait très certainement éclaircir les choses. Consultez Informations techniques de 3Com pour plus d'informations sur la façon d'obtenir de 3Com des documents techniques. Notez aussi que vous pouvez éventuellement consulter le site FTP de 3Com qui recèle diverses gâteries : ftp.3Com.com. Pour ceux qui consultent ce document sur le WWW, vous pouvez aussi essayer leur site WWW (www.3com.com). 3c501 Statut : Partiellement supporté, Nom du pilote : 3c501 Cette carte 8 bits datant de l'âge de pierre, trop tapée du ciboulot pour être utilisée. Evitez-la comme la peste. N'achetez pas cette carte, même pour faire une blague. Ses performances sont atroces, et elle a de nombreuses déficiences. Pour ceux qui ne seraient pas encore convaincus, la 3C501 ne sait faire qu'une chose à la fois -- pendant que vous enlevez un paquet du tampon (qui ne peut en contenir qu'un seul), elle ne peut pas en recevoir un autre, pas plus qu'elle ne peut en recevoir un pendant le chargement d'un paquet à transmettre. C'était parfait pour un réseau entre deux ordinateurs à base de 8088 où le traitement de chaque paquet et la réponse prenaient des dizaines de millisecondes, mais les réseaux modernes envoient des paquets les uns à la suite des autres pour pratiquement chaque transaction. Les IRQ automatiques fonctionnent, le DMA n'est pas utilisé, la détection automatique ne teste que 0x280 et 0x300, et le niveau de débogage est indiqué dans le troisième argument passé au démarrage. Encore une fois, l'utilisation d'une 3C501 est _fortement déconseillée_ ! Encore plus avec un noyau IP `multicast', puisque vous allez aboutir à un arrêt pendant que vous écoutez _chacun_ des paquets `multicast'. Lisez les commentaires au début du code source pour plus de détails. EtherLink II, 3c503, 3c503/16 Statut : Supporté, Nom du pilote : 3c503 (+8390) La 3c503 ne possède pas de mémoire reprogrammable pour stocker sa configuration (un ``EEPROM setup'') ; un programme de diagnostic et de configuration n'est donc pas nécessaire avant d'utiliser la carte sous Linux. L'adresse de mémoire partagée de la 3c503 est fixée en utilisant des cavaliers qui sont partagés avec l'adresse de la mémoire programmable de démarrage (``boot PROM''). Cela a tendance à semer la confusion chez les personnes habituées aux autres cartes ISA, sur lesquelles on laisse toujours le cavalier sur la position `désactivée' (_disable_ en anglais) à moins d'avoir une PROM de démarrage. Ces cartes devraient être aussi rapide que les cartes WD80x3 qui utilisent le même bus, mais il apparaît qu'elles sont légèrement plus lentes. Ces cartes Ethernet à mémoire partagée ont aussi un mode à Entrées/Sorties programmées qui n'utilise pas les possibilités de la 8390 (leurs ingénieurs ont trouvé trop de bogues !). Le pilote 3c503 de Linux sait aussi travailler avec la 3c503 en mode d'E/S programmées, mais c'est plus lent et moins sûr que le mode à mémoire partagée. De plus, le mode d'E/S programmées n'est pas aussi bien testé lors des mises à jour des pilotes. Vous ne devriez pas utiliser le mode d'E/S programmées à moins d'en avoir besoin pour la compatibilité avec le DOS. La ligne d'IRQ de la 3c503 est fixée par logiciel, sans l'aide d'une EEPROM. A la différence des pilotes sous DOS, le pilote Linux est capable de choisir automatiquement l'IRQ : il utilise la première ligne d'interruption disponible parmi {5,2/9,3,4}, en choisissant à chaque fois que la carte est ifconfigurée. (Les anciennes versions du pilote sélectionnaient l'IRQ au moment du démarrage). L'appel ioctl() dans `ifconfig' retournera EAGAIN si aucune ligne d'IRQ n'est disponible à ce moment-là. Des problèmes classiques que les gens ont avec la 3c503 sont abordés dans Problèmes 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 pour des informations spécifiques aux modules. Notez que certains vieux 386 sans disques ont des 3c503 sur la carte mère (faites par 3Com, mais vendues sous un autre nom, tel que `Bull') l'identificateur n'est pas celui des cartes 3Com, et elles ne seront donc pas détectées. Pour plus de détails, référez-vous au paquetage Etherboot, dont vous aurez besoin pour démarrer ces PC sans disques. EtherLink plus, 3c505 Statut : Partiellement supporté, Nom du pilote : 3c505 Il s'agit d'un pilote qui avait été écrit par Craig Southeren geoffw@extro.ucc.su.oz.au. Ces cartes utilisent la puce i82586 d'Intel et sont assez peu répandues. Le pilote est inclus dans le noyau standard, mais il est classé comme pilote `alpha'. Consultez Pilotes alpha pour des informations importantes à propos de l'utilisation de pilotes Ethernet en phase de test `alpha' sous Linux. Vous devriez aussi lire le fichier /usr/src/linux/drivers/net/README.3c505 si vous comptez utiliser une de ces cartes. Il contient diverses options que vous pouvez activer ou désactiver. EtherLink-16, 3c507 Statut : Partiellement supporté, Nom du pilote : 3c507 Cette carte utilise l'une des puces Intel, et le développement du pilote est fortement lié à celui du pilote de la carte Ether Express d'Intel. Le pilote est inclus dans la distribution standard du noyau, mais en tant que pilote `alpha'. Consultez Pilotes alpha pour des informations importantes concernant l'utilisation de pilotes en phase de test `alpha' sous Linux. EtherLink III, 3c509 / 3c509B Statut : Supporté, Nom du pilote : 3c509 Cette carte est plutôt bon marché et possède de bonnes performances pour une conception ISA qui ne soit pas `bus-master'. Le revers de la médaille est que la 3c509 originelle nécessitait des temps de latence vraiment très faibles en réponse aux interruptions. La 3c509B ne souffre pas du même problème, car elle possède un tampon mémoire plus important (voir ci-dessous). Ces cartes utilisent des transferts en mode d'Entrées/Sorties programmées (PIO), de la même façon qu'une carte ne2000, et par conséquent une carte à mémoire partagée comme la wd8013 sera plus efficace en comparaison. La 3c509 d'origine avait un petit tampon mémoire pour les paquets (4 Ko au total, 2 en réception et 2 en transmission), ce qui poussait le pilote à éliminer un paquet si les interruptions étaient masquées trop longtemps. Pour minimiser ce problème, vous pouvez essayer de dé-masquer les interruptions pendant les transferts sur disques IDE (consultez man hdparm) et / ou augmenter la vitesse de votre bus ISA de façon à ce que les transferts IDE se terminent plus tôt. Le modèle plus récent, la 3c509B, possède 8 Ko de mémoire, et le tampon peut être partagé en 4/4, 5/3 ou 6/2 en réception/transmission. Ce paramètre est changé à l'aide de l'utilitaire de configuration sous DOS, et est stocké dans la mémoire EEPROM. Cela devrait éliminer le problème précédent avec la 3c509 originelle. Les utilisateurs de 3c509B devraient utiliser soit l'utilitaire DOS fourni afin de désactiver le `_plug and play_', _et_ de déterminer le support de sortie dont ils ont besoin. Le pilote Linux _n'est pas_ capable aujourd'hui d'utiliser la fonctionnalité de détection automatique du support physique, donc vous _devez_ sélectionner 10Base-T ou 10Base-2 ou AUI. Notez que pour arrêter totalement le PnP, vous devrez faire un 3C5X9CFG /PNP:DISABLE et ensuite, éteindre et rallumer la machine pour que cela prenne effet. Certaines personnes ont posé des questions sur les paramètres ``Server or Workstation'' (serveur ou station de travail) et ``Highest Modem Speed'' (plus haute vitesse de modem) qui sont présentés dans l'utilitaire de configuration du DOS. Donald écrit que ``Ce ne sont que des orientations fournies au pilotes, et le pilote Linux n'utilise pas ces paramètres ; il optimise toujours pour un taux de transfert important plutôt que pour un temps de latence faible (`Server'). Un temps de latence faible était un critère critique pour le vieux trafic, non-fenêtré, de IPX. Afin de réduire le temps de latence, le pilote sous DOS de la 3c509 inhibe les interruptions de certaines opérations, bloquant les interruptions du port série. D'où la nécessité du paramètre `modem speed' (vitesse du modem). Le pilote Linux évite la nécessité de désactiver les interruptions sur de longues périodes en ne travaillant que sur des paquets complets, par exemple en ne commençant pas à transmettre un paquet avant qu'il n'ait été complètement transféré sur la carte.'' Notez que la procédure de détection de la carte ISA utilise une méthode différente de la plupart des autres cartes. A la base, vous demandez aux cartes de répondre en envoyant des données sur un port ID_PORT (port 0x100 jusqu'à 0x1ff par intervalle de 0x10). Cette méthode de détection signifie qu'une carte donnée sera toujours détectée en premier dans une configuration comportant plusieurs cartes ISA 3c509. La carte avec la plus petite adresse Ethernet physique sera _toujours_ eth0. Cela ne devrait gêner personne, à l'exception de ceux qui souhaitent assigner une adresse physique sur 6 octets à une interface donnée. Si vous avez plusieurs cartes 3c509, il vaut mieux ajouter des commandes ether=0,0,ethN sans préciser le port d'E/S (c'est-à-dire en utilisant E/S=zéro) et autoriser la procédure de détection à faire le tri pour déterminer quelle carte est la première. Utiliser une valeur d'E/S non nulle va faire que toutes les cartes ne seront pas détectées : donc, ne le faites pas. Si cela vous gêne vraiment, jetez un coup d'oeil au tout dernier pilote de Donald, car cela vous permettra d'utiliser une valeur 0x3c509 dans le champ (inutilisé) de l'adresse mémoire pour obliger la détection à réussir. 3c515 Statut : Supporté, Nom du pilote : 3c515 Il s'agit de l'offre 100 Mb/s de 3Com en ISA, nom de code ``_CorkScrew_'' (tire-bouchon, en anglais). Un pilote assez jeune pour ces cartes venant de Donald est inclus dans la version 2.2 du noyau. Pour les dernières informations, vous auriez certainement intérêt à le chercher dans la page sur les ``Vortex'' : Vortex 3c523 Statut : Partiellement supporté, Nom du pilote : 3c523 Cette carte pour bus MCA utilise la puce i82586, et Chris Beauregard a modifié le pilote ni52 pour qu'il fonctionne avec ces cartes. Le pilote correspondant peut être trouvé dans l'arborescence des sources des noyaux 2.2. Plus de détails sont fournis sur la page MCA pour Linux à http://glycerine.cetmm.uni.edu/mca/ 3c527 Statut : Non supporté Eh oui, encore une autre carte MCA. Eh non, pas beaucoup d'intérêt pour celle-ci. Vous aurez plus de chance avec la 3c529 si vous êtes coincé(e) avec le MCA. 3c529 Statut : Partiellement supporté, Nom du pilote : 3c509 Cette carte utilise en fait le même jeu de puces que la 3c509. De fait, Donald a placé des points d'entrée dans le pilote de la 3c509 pour vérifier l'existence de cartes MCA après la détection des cartes EISA, et avant celle des cartes ISA, longtemps avant que le MCA soit supporté par le noyau. Le code de détection MCA est inclus dans le pilote livré avec le noyau 2.2. On peut trouver plus de détails sur la page MCA pour Linux à l'adresse http://glycerine.cetmm.uni.edu/mca/. 3c562 Statut : Supporté, Nom du pilote : 3c589 (distribué séparément) Cette carte PCMCIA est la combinaison d'une carte Ethernet 3c589B et d'un modem. Le modem est vu comme un modem standard par l'utilisateur final. La seule difficulté est d'arriver à faire en sorte que les deux pilotes Linux partagent la même interruption. Il y a une série de nouveaux registres et un peu de support de partage d'interruptions matérielles. Vous aurez besoin d'utiliser un noyau 2.0 ou plus récent, qui comporte ce qu'il faut pour le partage d'interruptions. Merci de nouveau à Cameron pour l'obtention d'un exemplaire d'essai et l'envoi d'une documentation à David Hinds. Consultez le paquetage PCMCIA de David pour plus d'informations. Consultez PCMCIA pour en savoir plus sur les jeux de puces PCMCIA, les activateurs de sockets, etc. 3c575 Statut : Inconnu Un pilote pour cette carte PCMCIA est en cours de développement et l'on peut espérer qu'il sera inclus dans le paquetage PCMCIA de David dans le futur. Le mieux est de regarder dans le paquetage PCMCIA pour voir ce qui s'y passe. 3c579 Statut : Supporté, Nom du pilote : 3c509 La version EISA de la 509. La version EISA actuelle utilise la même puce de largeur 16 bits plutôt qu'une interface 32 bits, et les performances ne sont donc pas époustouflantes. Le code de détection EISA a été ajouté dans 3c509.c pour la version 0.99pl14. Assurez-vous que la carte est configurée pour le mode d'adressage EISA. Lisez la section précédente sur la 3c509 pour des informations sur le pilote. 3c589 / 3c589B Statut : Partiellement supporté, Nom du pilote : 3c589 Beaucoup de monde utilise cette carte PCMCIA depuis déjà un bon bout de temps. Notez qu'elle n'est pas incluse (à l'heure actuelle) dans l'arborescence par défaut du noyau. Le "B" dans le nom signifie la même chose ici que dans le cas de la 3c509. Les pilotes sont disponibles sur le site ftp de Donald, et dans le paquetage PCMCIA de David Hinds. Vous aurez aussi besoin d'avoir un chipset PCMCIA supporté. Allez faire un tour dans le Support PCMCIA pour plus d'informations sur les pilotes, les chipsets supportés, les activateurs de sockets, etc. 3c590 / 3c595 Statut : Supporté, Nom du pilote : 3c59x Ces cartes ``Vortex'' sont destinées aux machines à bus PCI, la 3c590 constituant l'offre à 10 Mb/s de 3Com et la 3c595 celle à 100 Mb/S. Notez aussi que vous pouvez utiliser la 595 comme une 590 (c'est-à-dire en mode 10 Mb/s). Le pilote est inclus dans les sources du noyau 2.0, mais est aussi continuellement mis à jour. Si vous rencontrez des problèmes avec le pilote des noyaux 2.0, vous pouvez obtenir un pilote à jour à partir de l'URL suivante : Vortex Notez qu'il existe en fait deux cartes 3c590, des modèles des premiers temps ayant 32 Ko de mémoire, et des plus récents qui n'en ont que 8 . Il y a des chances pour que vous ne puissiez plus acheter une 3c59x neuve, car elles ont été remplacées par les 3c90x. Si vous achetez une carte d'occasion, essayez d'obtenir la version 32 Ko. Les cartes 3c595 ont 64 Ko, car vous ne pouvez pas faire grand-chose avec seulement 8 Ko de mémoire vive à 100 Mb/s ! Grand merci à Cameron Spitzer et Terry Murphy de 3Com pour l'envoi de cartes et de documentation à Donald afin qu'il puisse écrire le pilote. Donald a mis en place une liste de diffusion pour le support du pilote Vortex. Pour vous abonner à la liste, vous n'avez qu'à faire : echo subscribe | /bin/mail linux-vortex-request@cesdis.gsfc.nasa.gov 3c592 / 3c597 Statut : Supporté, Nom du pilote : 3c59x Ce sont les versions EISA des séries 3c59x. La 3c592/3c597 (aussi connue sous le nom de Demon) devrait fonctionner avec le pilote Vortex présenté au paragraphe précédent. 3c900 / 3c905 / 3c905B Statut : Supporté, Nom du pilote : 3c59x Ces cartes (aussi connues sous le nom de `Boomerang', ou encore EtherLink III XL) ont été mises sur le marché pour remplacer les cartes 3c590/3c595. Le support pour la version à base de Cyclone 'B' a récemment été ajouté. Pour utiliser cette carte avec les anciens noyaux 2.0, vous devez obtenir le pilote 3c59x.c mis à jour sur le site de Donald : Vortex Si vous avez un doute, allez faire un tour sur la page WWW ci-dessus. Donald a mis en place une liste de diffusion sur les annonces concernant le support du pilote Vortex, entre autres. Pour vous abonner à la liste, il suffit de faire : echo subscribe | /bin/mail linux-vortex-request@cesdis.gsfc.nasa.gov 3c985 Statut : Supporté, Nom du pilote : acenic Ce pilote, par Jes Sorensen, est disponible dans les noyaux 2.2. Il supporte plusieurs autres modèles de cartes Gigabit en plus du modèle 3Com. 5.2 Accton Accton MPX Statut : Supporté, Nom du pilote : ne (+8390) Ne vous laissez pas avoir par le nom. Cette carte est tout de même supposée être une compatible NE2000, et devrait par conséquent fonctionner avec le pilote du même nom. Accton EN1203, EN1207, EtherDuo-PCI Statut : Supporté, Nom du pilote : de4x5, tulip Une autre implémentation de la puce PCI 21040 de DEC. La carte EN1207 comporte le 21140, mais a aussi un connecteur 10Base-2, ce qui s'est révélé source de problèmes pour certaines personnes en terme de sélection de ce support. Par contre, l'utilisation de la carte avec du 10Base-T et du 100Base-T a fonctionné pour certaines autres. Donc, comme pour tous les achats, vous devez d'abord essayer et vous assurer que vous pourrez retourner la carte si elle ne fonctionne pas pour vous. Consultez DEC 21040 pour plus d'informations sur ces cartes, et la situation actuelle du pilote. Adaptateur Accton EN2209 pour port parallèle (EtherPocket) Statut : Partiellement supporté, Nom du pilote : ? Un pilote pour ces adaptateurs sur port parallèle est disponible mais ne fait pas encore partie des sources des noyaux 2.0 ou 2.1. Vous pouvez obtenir ce pilote sur : http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html Accton EN2212 PCMCIA Statut : Partiellement supporté, Nom du pilote : ? David Hinds a commencé à travailler sur un pilote pour cette carte, et vous devriez de consulter la dernière version de son paquetage PCMCIA pour savoir où il en est. 5.3 Allied Telesyn/Telesis AT1500 Statut : Supporté, Nom du pilote : lance Il s'agit d'une série de cartes Ethernet peu chères qui utilisent la version 79C960 de la puce LANCE d'AMD. Ce sont des cartes utilisant le le contrôle du bus, et elles figurent donc parmi les cartes Ethernet ISA les plus rapides. La sélection du DMA et des informations sur la numérotation de la puce se trouvent dans AMD LANCE. Plus d'informations techniques sur les cartes Ethernet basées sur l'AMD LANCE sont disponibles dans Notes sur l'AMD.... AT1700 Statut : Supporté, Nom du pilote : at1700 Notez que pour accéder à ce pilote lors du make config vous devez encore répondre `Y' à la question ``Prompt for development and/or incomplete code/drivers?'' au tout début. C'est simplement dû au manque de retour d'informations sur la stabilité du pilote, étant donné qu'il s'agit d'une carte relativement rare. Si vous avez des problèmes avec le pilote qui est livré avec le noyau, vous serez peut etre interessé par celui qui est disponible à : http://www.cc.hit-u.ac.jp/nagoya/at1700/ Les cartes Ethernet Allied Telesis des séries AT1700 sont basées sur la MB86965 de Fujitsu. Cette puce utilise une interface à E/S programmées, et une paire de tampons de transmission à taille fixe. Cela permet d'envoyer des petits groupes de paquets les uns à la suite des autres, avec une courte pause pendant le changement de tampon. Une fonctionnalité unique est la possibilité de piloter du câble STP (Shielded Twisted Pair, paire torsadée blindée) 150 ohms couramment installé pour le Token Ring, en plus du câble 100 ohms UTP (Unshielded Twisted Pair, paire torsadée non-blindée) de 10BaseT. Une version fibre optique de la carte (AT1700FT) existe également. La puce Fujitsu utilisée sur l'AT1700 a un défaut de conception : elle ne peut être remise complètement à zéro qu'en effectuant un cycle d'allumage de la machine. Le fait d'appuyer sur le bouton de redémarrage (`Reset') ne réinitialise pas l'interface du bus. Cela ne serait pas gênant, si la carte ne pouvait être détectée qu'après qu'elle ait été récemment réinitialisée. Le moyen de contourner le problème est d'éteindre puis de rallumer la machine si le noyau a un problème pour détecter l'AT1700. Certaines séries de production de l'AT1700 ont un autre problème : elles sont conçues pour utiliser de façon permanente le canal DMA 5. Cela n'est pas documenté, il n'existe aucun cavalier pour désactiver cette "fonctionnalité", et aucun pilote n'ose utiliser la possibilité de DMA à cause de problèmes de compatibilité. Aucun pilote de périphérique ne sera écrit pour utiliser la DMA si le fait d'installer une seconde carte dans la machine casse les deux cartes, et le seul moyen de désactiver le DMA est d'utiliser un couteau. Certaines séries de l'AT1700 ont un autre problème : Elles sont bloquées sur le canal DMA 5. Cela n'est pas documenté, et il n'y a pas de cavaliers pour désactiver cette "fonctionnalité", et aucun pilote n'ose utiliser le DMA a cause des problèmes de compatibilité. Aucun pilote ne sera écrit pour utiliser le DMA a cause car le fait d'installer une deuxième carte empêcherais les DEUX de marcher, et le seul moyen de désactiver le DMA, c'est avec un couteau. AT2450 Statut : Supporté, Nom du pilote : pcnet32 La version PCI de l'AT1500, qui ne souffre pas des problèmes de la carte PCI 79c970 de Boca. La sélection du DMA et des informations sur la numérotation de la puce se trouvent dans AMD LANCE. Plus d'informations techniques sur les cartes Ethernet basées sur l'AMD LANCE sont disponibles dans Notes sur l'AMD.... AT1500 Statut : Partiellement supporté, Nom du pilote : rtl8139 Cette carte utilise la puce Realtek 8139, référez vous à la section Realtek 8139 AT2540FX Statut : Partiellement supporté, Nom du pilote : eepro100 Cette carte utilise une puce i82557, et par conséquent, pourrait / devrait fonctionner avec le pilote de la carte eepro100. Si vous l'essayez, envoyez-nous quelques renseignements complémentaires pour que cette section s'étoffe un peu. 5.4 AMD / Advanced Micro Devices Carl Ching d'AMD a eu la gentillesse de fournir une description très détaillée de tous les produits Ethernet d'AMD cités, ce qui a permis de clarifier cette section. AMD LANCE (7990, 79C960/961/961A, PCnet-ISA) Statut : Supporté, Nom du pilote : lance Il n'existe en fait aucune carte Ethernet AMD. Vous êtes certainement en train de lire ce paragraphe parce que les seules marques que vous ayez pu trouver sur votre carte disent `AMD' et le numéro ci-dessus. La 7990 est la puce `LANCE' d'origine, mais la plupart des documents (y compris celui-ci) se réfèrent à toutes ces puces similaires sous la dénomination de puces `LANCE' (...incorrectement, devrais-je ajouter). Les numéros ci-dessus se réfèrent aux puces d'AMD qui sont le coeur de nombreuses cartes Ethernet. Par exemple, l'AT1500 d'Allied Telesis (voir AT1500), et la NE1500/2100 (voir NE1500) utilisent ces puces. La 7990/79c90 a été remplacée depuis bien longtemps par des versions plus récentes. La 79C960 (aussi connue sous le nom de PCnet-ISA) contient pour l'essentiel la base de la 79c90, avec tout le support matériel complémentaire requis, ce qui permet de monter une solution Ethernet en une seule puce. La 79c961 (PCnet-ISA+) est une version ``Plug and Play'', sans cavaliers, de la 960. La dernière puce des séries ISA est la 79c961A (PCnet-ISA II), qui ajoute des capacités de _full duplex_. Toutes les cartes comportant une de ces puces devraient fonctionner avec le pilote lance.c, à l'exception de très vieilles cartes qui utilisent la 7990 d'origine avec une configuration à mémoire partagée. Ces cartes anciennes peuvent être repérées par l'absence de cavaliers pour le choix d'un canal DMA. Parmi les problèmes classiques, on rencontre le message `busmaster arbitration failure'. Celui-ci s'affiche quand le pilote LANCE ne peut pas obtenir un accès au bus après qu'un temps raisonnable se soit écoulé (50 micro-secondes). Cela indique habituellement que l'implémentation de la maîtrise de bus DMA de la carte-mère est incorrecte, ou qu'un autre périphérique monopolise le bus, ou qu'il y a un conflit de canal DMA. Si votre programme de configuration du BIOS possède la `GAT option' (GAT pour Guaranteed Access Time, temps d'accès garanti), essayez de modifier ce paramètre pour voir si cela va mieux. Notez aussi que le pilote ne cherche une carte valide qu'à ces adresses : 0x300, 0x320, 0x340, 0x360, et qu'une adresse fournie par un argument de démarrage ether= est ignorée sans qu'il en soit fait mention (cela sera corrigé), donc assurez-vous que votre carte est configurée pour l'une des adresses d'E/S ci-dessus, pour l'instant. Le pilote fonctionnera encore correctement, même si plus de 16 Mo de mémoire sont installés, car des tampons-relais en mémoire basse sont utilisés au besoin (c'est-à-dire que toute donnée située au-delà de la limite des 16 Mo est copiée dans un tampon en-dessous de la limite avant d'être remis à la carte pour transmission). Le canal DMA peut être configuré avec les bits (inutilisés en dehors de ça) de la valeur de dev->mem_start (aussi connue comme PARAM_1 (voir PARAM_1). S'il n'est pas fixé, il est testé en activant chaque canal DMA tour à tour et en regardant si l'initialisation réussit. La carte HP-J2405A est une exception : avec cette carte, il est facile de lire les valeurs stockées en EEPROM pour l'IRQ et le DMA. Voir Notes on AMD... pour plus d'informations sur ces puces. AMD 79C965 (PCnet-32) Statut : Supporté, Nom du pilote : pcnet32 Il s'agit de la PCnet-32 -- une version 32 bits, à contrôle de bus, de la puce LANCE originelle pour les systèmes VLB (Vesa Local Bus) et à bus local. Bien que ces puces puissent être utilisée avec le pilote lance.c standard, une version 32 bits (pcnet32.c) est aussi disponible, laquelle n'a pas à se préoccuper des limitations à 16 Mo liées au bus ISA. AMD 79C970/970A (PCnet-PCI) Statut : Supporté, Nom du pilote : pcnet32 Il s'agit de la PCnet-PCI -- similaire à la PCnet-32, mais conçue pour des systèmes basés sur le bus PCI. De nouveau, consultez les informations ci-dessus sur la PCnet-32. Cela signifie que vous devez construire un noyau comportant le support du BIOS PCI. La 970A ajoute le support du mode _full duplex_ ainsi que d'autres fonctionnalités par rapport à la conception d'origine de la 970. Notez que l'implémentation de Boca pour la 79C970 ne fonctionne pas sur les machines Pentium rapides. Il s'agit d'un problème matériel, puisqu'il affecte aussi les utilisateurs DOS. Consultez la section sur Boca pour plus de détails. AMD 79C971 (PCnet-FAST) Statut : Supporté, Nom du pilote : pcnet32 Il s'agit de la puce 100 Mbits d'AMD pour les systèmes PCI, qui comporte elle aussi le mode _full duplex_. Elle a été introduite en juin 1996 sur le marché. AMD 79C972 (PCnet-FAST+) Statut : Inconnu, Nom du pilote : pcnet32 Devrait marcher exactement comme la '971, mais reste à confirmer quand même. AMD 79C974 (PCnet-SCSI) Statut : Supporté, Nom du pilote : pcnet32 Il s'agit de la PCnet-SCSI -- qui à la base est traitée comme une 970 du point de vue Ethernet. Consultez aussi les informations ci-dessus. Ne demandez pas si la partie SCSI de la puce est supportée -- il s'agit de l'_Ethernet-HOWTO_, pas du _SCSI-HOWTO_. 5.5 Ansel Communications AC3200 EISA Statut : Partiellement supporté, Nom du pilote : ac3200 Notez que pour accéder à ce pilote lors du make config vous devez encore répondre `Y' à la question ``Prompt for development and/or incomplete code/drivers?'' au tout début. C'est simplement dû au manque de retour d'informations sur la stabilité du pilote, étant donné qu'il s'agit d'une carte relativement rare. Ce pilote est inclus dans le noyau actuel comme étant en phase de test `alpha'. Il est basé sur la classique puce NS8390 utilisée dans les cartes NE2000 et WD80x3. Veuillez consulter Pilotes `alpha' dans le présent document pour des informations importantes concernant les pilotes `alpha'. Si vous l'utilisez, veuillez informer l'un d'entre nous de la façon dont les choses fonctionnent, car nous avons eu peu de retour d'informations, même si le pilote est dans le noyau depuis la version 1.1.25. Si vous avez l'intention d'utiliser ce pilote comme module chargeable, vous devriez lire Utilisation des pilotes Ethernet comme modules pour des informations spécifiques aux modules. 5.6 Apricot Apricot Xen-II On Board Ethernet Statut : Supporté, Nom du pilote : apricot Cette carte Ethernet sur carte-mère utilise une puce i82596 à contrôle du bus. Elle ne peut se trouver qu'à l'adresse d'E/S 0x300. En consultant le source du pilote, il apparaît que l'IRQ est matériellement fixée à 10. Les premières versions du pilote avaient une tendance à croire que tout ce qui vivait en 0x300 était un adaptateur réseau Apricot. Depuis, l'adresse matérielle est testée afin d'éviter ces détections erronées. 5.7 Arcnet Statut : Supporté, Nom du pilote : arcnet (arc-rimi, com90xx, com20020) Avec le coût vraiment très bas et les meilleures performances d'Ethernet, il est probable que la plupart des endroits disposant d'un réseau vont se débarrasser de leur matériel Arcnet pour rien, ce qui amènera un grand nombre de systèmes personnels à utiliser Arcnet. Un avantage d'Arcnet est que toutes les cartes ont des interfaces identiques, donc un seul pilote fonctionnera pour tout le monde. Il comporte aussi une gestion intégrée des erreurs, et est donc supposé ne jamais perdre un paquet. (Chouette pour le trafic UDP !) Le pilote Arcnet d'Avery Pennarun est dans le noyau par défaut depuis la version 1.1.80. Le pilote Arcnet utilise `arc0' comme nom au lieu de l'`eth0' habituel pour les périphériques Ethernet. Vous pouvez envoyer rapports de bogues et comptes-rendus victorieux concernant Arcnet à : apenwarr@foxnet.net Le noyau standard comporte des fichiers d'information pour la configuration des cavaliers et des aides plus générales. Le pilote est également censé fonctionner avec les cartes ARCnet 100 Mb/s ! 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 être utilisée dans un environnement 10Base-T standard, sans un hub qui `parle' les deux protocoles. AT&T T7231 (LanPACER+) Statut : Non supporté Ces cartes StarLAN utilisent une interface similaire à la puce i82586. A une époque, 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 Boca Research Oui, ils font autre chose que des cartes séries multi-ports. :-) Boca BEN (ISA, VLB; PCI) Statut : Supporté, Nom du pilote : pcnet32, lance Ces cartes sont basées sur les puces PCnet d'AMD. Les acheteurs exigeants doivent être prévenus que de nombreux utilisateurs ont eu des problèmes sans fin avec ces cartes VLB/PCI. Les propriétaires de systèmes Pentium rapides ont été tout particulièrement touchés. Notez qu'il ne s'agit pas d'un problème de pilote, puisqu'il touche aussi les utilisateurs de DOS/Windows/NT. Le numéro du support technique de Boca est le 1 (407) 241-8088, (NDT : Ce numéro est bien entendu aux États-Unis.) et vous pouvez aussi les joindre à 75300.2672@compuserve.com. Les anciennes cartes ISA ne semblent pas souffrir des mêmes maux. Donald a réalisé un test comparatif entre les cartes PCI Boca et une implémentation similaire d'Allied Telsyn avec la puce PCnet/PCI, qui montrait que le problème se situe dans l'implémentation faite par Boca de la puce PCnet/PCI. On peut consulter les résultats de ce test sur le serveur WWW de Don : Linux @ CESDIS Boca offre une `réparation - garantie' aux propriétaires affectés par ce problème qui entraîne l'ajout d'un des condensateurs manquants, mais il semble que cette correction ne fonctionne pas à 100 % pour la plupart des gens, bien que cela en aide quelques uns. Si vous pensez _encore_ acheter une de ces cartes, alors essayez au moins d'obtenir une clause de retour inconditionnel sous 7 jours, pour que vous puissiez la rendre si elle ne fonctionne pas correctement sur votre système. Des informations plus générales sur les puces AMD se trouvent dans AMD LANCE. Plus d'informations techniques sur les cartes Ethernet basées sur l'AMD LANCE sont disponibles dans Notes sur l'AMD.... 5.10 Cabletron Donald écrit : ``Oui, encore une autre de ces sociétés qui ne donnera pas ses informations pour programmer. Ils ont attendu des mois avant de confirmer qu'en fait toutes leurs informations étaient propriétaires, gaspillant délibérément mon temps. Évitez leurs cartes comme la peste si vous le pouvez. Notez aussi que certaines personnes ont appelé Cabletron, et se sont entendues dire des choses comme `un certain D. Becker travaille sur un pilote pour Linux' -- laissant entendre que je travaillais pour eux. Ce N'est PAS le cas.'' Apparemment, Cabletron a changé sa politique