Ce chapitre recense un certain nombre de problèmes habituellement rencontrés. S'il n'y a rien ici qui réponde à vos questions, consultez également les chapitres relatifs aux cartes d'interface et aux périphériques.
Si vous rencontrez des erreurs aléatoires, il y a fort à parier que la cause en est un câble défectueux ou une mauvaise terminaison.
Certaines cartes, comme celles architecturées autour du récent composant NCR, effectuent un filtrage numérique et une négociation active de signal et sont par le fait moins sensibles aux problèmes de connectique.
D'autres cartes, comme par exemple les Adaptec 154xC, 154xCF et 274x, sont extrêmement sensibles et peuvent ne plus fonctionner avec certains cordons qui ne perturberaient pas d'autres cartes.
Je le répète donc : certaines cartes sont très sensibles aux problèmes de mauvais câbles et de terminaison, aussi est-il important de vérifier ces deux points avant toute chose lorsque des problèmes apparaissent.
Pour diminuer les risques potentiels, vous devez utiliser des câbles qui :
Un léger courant pour la terminaison doit être fourni par chaque équipement présent sur le bus SCSI, via une diode pour prévenir tout retour de tension. De cette manière, une tension suffisante est disponible en bout de chaîne, là où le bus en a besoin. Pour prévenir tout endommagement dû à un court-circuit, TERMPWR doit être contrôlé au travers d'un fusible ou de tout autre dispositif de limitation du courant.
Si plusieurs équipements, des câbles externes ou un FAST SCSI 2 sont utilisés, une terminaison -- active ou forcée -- parfaite doit être mise à chaque extrémité du bus.
Reportez-vous à la FAQ Comp.Periphs.Scsi (disponible sur tsx-11 dans /pub/linux/ALPHA/scsi) pour plus de renseignements sur les terminaisons actives.
D'autres parties du document feront plus tard référence à la "ligne de commande du noyau".
La ligne de commande du noyau est un ensemble d'options que vous pouvez spécifier, soit après le nom de l'image à l'invite de LILO (LILO : ), soit dans un champ "append" du fichier de configuration de LILO (LILO 0.14 et supérieurs utilisent le fichier /etc/lilo.conf, les versions précédentes /usr/lilo/config).
Démarrez votre système avec LILO et appuyez sur une des touches ALT, CTRL ou SHIFT, au moment où il affiche le prompt. LILO devrait répondre par :
:
A cet instant, vous pouvez sélectionner l'image du noyau sur lequel continuer le démarrage (en tapant son label) ou avoir la liste des images, en apppuyant sur ?. Par exemple :
:?
ramdisk floppy disquedur
Pour démarrer (booter) le noyau avec la ligne de commande que vous avez choisie entrez simplement le nom du noyau, suivi d'une liste d'options. Chaque option est séparée de la précédente par un espace. L'appui sur ENTREE valide la ligne et continue le processus de démarrage.
Les options sont de la forme :
variable=liste_de_valeurs
Ici, liste_de_valeurs peut être une simple valeur ou une liste de valeurs délimitées par des virgules, sans espaces. Exception faite de la spécification du périphérique de boot, chaque valeur doit être numérique et peut être fournie en décimal ou en héxadécimal.
Par exemple, pour démarrer Linux avec une carte compatible Adaptec 1520 non reconnue au démarrage, vous pourriez entrer :
:floppy aha152x=0x340,11,7,1
Si vous ne tenez pas à taper cette commande à chaque démarrage du système, il est également possible d'utiliser l'option "append" dans le fichier de configuration de LILO (LILO 0.13 et plus).
Cela donnera une ligne du genre :
append="aha152x=0x340,11,7,1"
Si c'est le cas, vous avez certainement sélectionné comme adresse pour ce périphérique la même adresse que le contrôleur (traditionnellement l'adresse 7, bien que quelques cartes soient configurées autrement, comme certaines Future Domain fixées à 6 par exemple).
Changez la configuration des cavaliers.
Ce périphérique a certainement un firmware buggé.
Une solution temporaire consiste à utiliser la ligne de commande suivante :
max_scsi_luns=1
Si cela marche, vous pouvez ajouter votre périphérique à la liste des périphériques buggés, dans les sources du noyau. La variable en question s'appelle blacklist et se trouve dans le fichier drivers/scsi/scsi.c. Envoyez ensuite le patch à Linus Torvalds <[email protected]>.
Cela est parfois dû à un mauvais cordon ou à une terminaison mal adaptée.
Référez-vous au chapitre Dysfonctionnement généralisé .
Les routines d'auto-détection pour la plupart des cartes réseau ne sont pas passives. Il se peut qu'elles entrent en conflit avec certaines cartes SCSI et qu'elles en perturbent le bon fonctionnement.
Un périphérique SCSI a été détecté par le noyau mais vous êtes incapable d'y accéder (les commandes mkfs /dev/sdc, tar xvf /dev/st2 par exemple échouent).
Vous n'avez pas de fichier spécial /dev/xxx pour votre périphérique.
Sous Unix, les périphériques sont en mode bloc ou en mode caractère. Les périphériques en mode bloc utilisent un mécanisme de cache, alors que les périphériques en mode caractère ne sont pas bufferisés.
Un périphérique est donc défini sous Unix par son mode (bloc ou caractère), son numéro majeur (ce numéro correspond au pilote qui le gère -- ainsi, le majeur mode bloc 8 correspond aux disques SCSI) et un numéro mineur (ce mineur définit quelle unité est accédée via cette spécification de périphérique -- ainsi, le périphérique référencé par le majeur caractère 4 et le mineur 0 est la première console virtuelle, mineur 1 est la console suivante, etc.). Cependant, accéder aux périphériques par un espace de nommage séparé romprait la tradition d'Unix/Linux ('tout est fichier' !). C'est pourquoi des fichiers spéciaux sont créés sous /dev. Ces fichiers spéciaux vous permettront d'accéder directement à votre troisième disque SCSI via /dev/sdc, au premier port série via /dev/ttyS0, etc.
La meilleure méthode pour créer un fichier spécial est d'utiliser le script MAKEDEV :
cd /dev
puis
MAKEDEV (en tant que root) pour les périphériques que vous voulez créer. Par exemple :
./MAKEDEV sdc
Les caractères génériques "devraient" marcher. Par exemple :
./MAKEDEV sd\*
"devrait" créer les entrées pour tous les disques SCSI (la commande précédente devrait avoir créé /dev/sda à /dev/sdp, avec 15 sous-partitions pour chaque disque).
./MAKEDEV sdc\*
"devrait" créer les entrées pour /dev/sdc et ses 15 sous-partitions possibles (/dev/sdc1, /dev/sdc2, etc.).
J'ai dit "devrait" parce que c'est le comportement standard d'Unix -- le script MAKEDEV de votre installation pourrait ne pas se conformer à cette façon de faire ou pourrait avoir restreint le nombre de fichiers spéciaux qu'il peut créer, auquel cas ce qui précède ne serait plus tout à fait vrai.
Si MAKEDEV ne fait pas le travail pour vous, vous allez devoir créer les fichiers spéciaux à la main grâce à la commande mknod.
Le mode (bloc ou caractère), le majeur et le mineur sont précisés pour les divers périphériques SCSI dans le chapitre Fichiers spéciaux .
Notez les valeurs trouvées dans ce chapitre et tapez (en tant que root) :
mknod /dev/peripherique b|c majeur mineur
par exemple :
mknod /dev/sdc b 8 32
mknod /dev/st0 c 9 0
Il peut y avoir de nombreuses raisons au blocage du bus. Eventuellement, reportez-vous au chapitre dédié à votre carte pour plus de détails.
Certains cas de blocage semblent se produire lorsque plusieurs périphériques sont en cours d'utilisation simultanément. Si cela vous arrive, essayez de contacter le fabricant des périphériques et regardez s'il n'existe pas des mises à jour de firmware qui résoudraient le problème. A l'occasion, essayez de changer de câble ou branchez les périphériques sur une autre machine.
Il se peut également que ce soit dû à des secteurs défectueux sur un des disques ou encore à une mauvaise gestion du DMA (Direct Memory Access) par la carte mère (pour les cartes d'interface qui travaillent en DMA). En fait, tout un tas d'autres raisons peut expliquer un blocage du bus.
De temps en temps, comme nous venons de le signaler, des cas de blocage apparaissent lorsque plusieurs périphériques sont utilisés en même temps sur le bus. Si votre contrôleur est capable de traiter plusieurs requêtes en même temps, essayer de réduire la taille de la queue à 1 et regardez si la situation s'améliore. Cela étant, si vous utilisez des périphériques lents (lecteurs de bandes ou lecteurs de CDROM peu rapides), réduire ainsi la taille de la queue n'est certainement pas la meilleure solution.
Les pilotes SCSI non utilisés consomment inutilement de précieux octets et peuvent amener les systèmes possédant peu de mémoire à en manquer (la mémoire du noyau est non paginable (swappable)). Pour cette raison, il est recommandé de générer un noyau ne comportant que le strict nécessaire pour votre machine.
cd /usr/src/linux
Si vous comptez utiliser une partition racine (root device) autre que la partition racine courante ou une résolution autre que du VGA 80x25, voire si vous générez une disquette de démarrage, éditez le makefile et assurez-vous que les lignes
ROOT_DEV =
et
SVGA_MODE =
sont correctement positionnées.
Si vous avez appliqué des patches, assurez-vous que vous tous vos fichiers sont correctement recompilés. Dans le doute, tapez :
make mrproper
Dans tous les cas, vous devrez configurer le noyau :
make config
Répondez aux questions. Après avoir sauvegardé votre configuration, regénérez les dépendances et recompilez le noyau :
make depend
make
Une fois la génération du noyau terminée, n'oubliez pas de relancer lilo (/sbin/lilo). Vous pouvez également construire une disquette de démarrage :
make zdisk
De nombreux périphériques SCSI verrouillent complètement le bus ou réagissent bizarrement lorsque vous tentez d'accéder à une unité logique (LUN) qui n'est pas l'unité 0. C'est pourquoi les versions récentes du noyau Linux n'essaient plus par défaut de tester les unités logiques autres que 0.
Si cela vous gêne, vous pouvez positionner max_scsi_luns sur la ligne de commande du noyau ; vous pouvez aussi recompiler le noyau en positionnant l'option CONFIG_SCSI_MULTI_LUN au moment de la configuration.
Il est habituel de mettre
max_scsi_luns=8
sur la ligne de commande de LILO.
Si, malgré tout, vos unités logiques ne sont toujours pas correctement détectées (cela peut arriver avec de vieux contrôleurs SCSI->MFM, RLL, ESDI ou SMD), essayez de supprimer le petit bout de code suivant de la fonction scan_scsis() du fichier drivers/scsi/scsi.c :
/* Some scsi-1 peripherals do not handle lun != 0.
I am assuming that scsi-2 peripherals do better */
if((scsi_result[2] & 0x07) == 1 &&
(scsi_result[3] & 0x0f) == 0) break;
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre