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.
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 Donpour 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.
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.
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.
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 :
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.
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.
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, <une valeur
ignorée>, 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, <une
valeur ignorée>, 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
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.
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=.
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.
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.
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.
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.
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
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é.
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.
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.
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.
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.
Pour les dernières informations à propos des Sparc, essayez donc l'URL suivante :
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.
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 !)
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.
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.
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.
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.
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.
/dev/ pour cartes EthernetJ'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.
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.
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.