Cette section dresse la liste de certains des problèmes couramment rencontrés. Si rien ici ne répond à vos questions, il vous faudra également consulter les sections concernant votre adaptateur et les périphériques posant problème.
Les erreurs aléatoires proviennent fréquemment du câblage et des terminaisons.
Certains produits, comme ceux qui sont construits autour des circuits NCR les plus récents, intègrent un filtrage digital et une négation active du signal, et ne sont pas très sensibles aux problèmes de câblage.
D'autres, comme les Adaptec 154xC, 154xCF et 274x, sont extrêmement sensibles et peuvent échouer avec des câbles qui fonctionnent avec d'autres systèmes.
Je le répète : certains adaptateurs s'avèrent extrêmement sensibles aux problèmes de câblage et de terminaison et ceux-ci doivent donc être vérifiés avant toute chose en cas d'ennui.
Pour minimiser les problèmes, il faut utiliser des câbles qui :
La puissance de terminaison doit être fournie par tous les périphériques sur le bus SCSI, à travers une diode pour éviter tout retour de courant, afin qu'une puissance suffisante soit disponible aux extrémités du câble où elle est nécessaire. Afin d'éviter des dommages physiques en cas de court-circuit, TERMPWR doit passer par un fusible ou un autre système de limitation de courant.
Si plusieurs périphériques, plusieurs câbles externes ou du FAST SCSI 2 sont utilisés, une terminaison parfaite forcée ou active est requise au deux bouts du bus SCSI.
Voir la FAQ comp.periphs.scsi
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi
pour plus d'informations sur
la terminaison active.
D'autres parties de la documentation se réfèrent à une ``ligne de commande du noyau'' (kernel command line).
La ligne de commande du noyau est un ensemble d'options que l'on peut spécifier depuis le prompt LILO: après un nom d'image, ou bien dans le champ append de votre fichier de configuration LILO (LILO >= .14 utilise /etc/lilo.conf, les versions antérieures utilisant /etc/lilo/config).
Démarrez votre système avec LILO, et frappez l'une des touches Alt, Ctrl ou majuscule quand il propose un prompt. LILO devrait répondre par
boot:
On peut alors sélectionner une image de noyau à lancer, ou les lister avec ``?'' (NdT : <Shift !> sur un clavier français). Par exemple
boot: ?
ramdisk floppy harddisk
Pour démarrer ce noyau avec les options de ligne de commande que vous avez sélectionnées, entrez simplement son nom suivi d'une liste d'options délimitées par des espaces, en finissant par un retour chariot.
Les options prennent la forme :
variable=valuelistOù valuelist peut être une valeur unique ou une liste de valeurs délimitées par des virgules, sans espace. A l'exception du périphérique racine, les valeurs individuelles sont des nombres, et peuvent être spécifiées en décimal ou en hexadécimal.
Par exemple, pour démarrer Linux avec un clone d'Adaptec 1520 non reconnu au démarrage, on peut entrer
boot: floppy aha152x=0x340,11,7,1
Si vous désirez ne pas entrer tout ceci à chaque fois, il est aussi possible d'utiliser l'option ``append'' du fichier de configuration de LILO pour les versions .13 et ultérieures.
Par exemple,
append="aha152x=0x340,11,7,1"
Dans ce cas, vous avez déclaré le périphérique à la même adresse que le contrôleur (typiquement 7, bien que certaines cartes utilisent d'autres adresses, comme 6 pour certaines cartes Future Domain).
Changez les réglages de cavaliers.
Le périphérique contient un code en ROM défectueux.
On peut temporairement essayer d'utiliser l'option de ligne de commande du noyau
max_scsi_luns=1
Si ceci fonctionne, il existe une liste de périphériques défectueux dans les sources du noyau, dans la variable blacklist de drivers/scsi/scsi.c. Ajoutez votre périphérique à cette liste et envoyez le patch à Linus.
Cela est parfois provoqué par une terminaison ou des câbles défectueux.
Voir general flaky : Défaillance générale
Les routines d'autodétection de la plupart des pilotes de réseaux ne sont pas passives et peuvent interférer avec certains des pilotes SCSI.
Un périphérique SCSI est détecté par le noyau, mais vous êtes incapable d'y accéder ; par exemple, mkfs /dev/sdc, tar xvf /dev/rst2, etc., échouent.
Vous n'avez pas de fichier spécial dans /dev pour le périphérique.
Les périphériques Unix sont identifiés par leur type, bloc ou caractère (les périphériques bloc passent par le buffer cache, ce qui n'est pas le cas des périphériques caractère), par un nombre majeur (c.à.d. quel pilote est utilisé ; le bloc majeur 8 correspond aux périphériques SCSI) et un nombre mineur (c.à.d. à quelle unité on accède pour un pilote donné ; le caractère majeur 4, mineur 0 est la première console virtuelle, mineur1 la suivante, etc). Mais ce genre d'accès par nommage direct aux périphériques enfreindrait le principe unix/Linux : ``Tout est fichier'', ce qui fait que des fichiers spéciaux de périphériques caractère et bloc sont créés sous /dev. Ceci vous permet d'accéder au troisième périphérique SCSI par /dev/sdc, au premier port série par /dev/ttyS0, etc.
La méthode préférentielle pour créer un fichier consiste à utiliser le script MAKEDEV :
cd /dev
et de lancer MAKEDEV (en tant que root) pour les périphériques à créer. Par ex. :
./MAKEDEV sdc
les jokers ``devraient'' marcher ; par ex.
./MAKEDEV sd\*
``devrait'' créer des entrées pour tous les périphériques disque SCSI (ceci doit créer les fichiers allant de /dev/sda à /dev/sdp, avec quinze entrées de partition pour chacun)
./MAKEDEV sdc\*
``devrait'' créer les entrées pour /dev/sdc et les quinze partitions permises sur /dev/sdc, etc.
Je dis ``devrait'' parce qu'il s'agit là du comportement standard sous unix ; le script MAKEDEV peut ne pas se conformer à cette règle, ou peut avoir restreint le nombre de périphériques qu'il créera.
Si la baguette magique de MAKEDEV ne suffit pas, il vous faudra créer les entrées de périphériques à la main avec la commande mknod.
Les types bloc/caractère et les nombres majeurs et mineurs sont spécifiés pour divers périphériques SCSI à la sous-section 3 : Fichiers de périphériques, dans la section appropriée.
Prenez ces nombres, et entrez (en tant que root)
mknod /dev/periph b|c majeur mineur
Exemple :
mknod /dev/sdc b 8 32
mknod /dev/rst0 c 9 0
De nombreuses causes possibles sont envisageables. Reportez vous également à la section concernant votre adaptateur pour des solutions spécifiques.
Il existe des cas dans lesquels les blocages semblent se produire quand plusieurs périphériques fonctionnent en même temps. Vous pouvez alors essayer de contacter le fabriquant des périphériques et voir si des mises à jour du logiciel en ROM susceptibles de corriger le problème sont disponibles. Si possible, essayez un câble SCSI différent, ou essayez sur un autre système. De mauvais blocs sur le disque, ou une mauvaise gestion du DMA par la carte mère (pour les adaptateurs qui l'utilisent) peuvent causer ce problème. De nombreuses autres conditions peuvent mener à ce type d'événement.
Ces problèmes surviennent parfois quand plusieurs périphériques fonctionnent sur le même bus en même temps. Dans ce cas, si votre pilote d'adaptateur supporte plus d'une commande en suspens (outstanding command) à la fois, essayez de réduire cette valeur à 1 et voyez si les choses s'arrangent. Si vous avez des unités à bande ou des lecteurs de CD-ROM lents sur le bus, cette solution peut ne pas s'avérer satisfaisante.
Les pilotes SCSI non utilisés consomment de la mémoire et aggravent les problèmes sur les petits systèmes parce que la mémoire du noyau n'est pas paginable.
Il vous faut donc construire un noyau adapté à votre système, ne comprenant que les pilotes dont vous avez besoin.
cd /usr/src/linux
Si vous utilisez un périphérique racine différent de celui en cours, ou quelque chose d'autre que du VGA 80x25, et que vous écrivez sur une disquette de démarrage, vous devez éditer le makefile, et vous assurer que les lignes
ROOT_DEV =
et
SVGA_MODE =
correspondent à ce que vous désirez.
Si vous avez installé des patches, vous pouvez désirer que tous les fichiers soient reconstruits. Dans ce cas, entrez
make mrproper
Que vous ayez exécuté make mrproper ou non, entrez
make config
et répondez aux questions de configuration. Lancez ensuite
make depend
et finalement
make
Une fois la compilation terminée, vous pouvez mettre à jour la configuration de lilo, ou écrire une disquette de démarrage en lançant
make zdisk
Ce problème arrive fréquemment avec les SCSI -> MFM, RLL, ESDI, SMD, et les cartes bridge similaires.
A un moment donné, nous en sommes arrivés à conclure que de nombreux périphériques SCSI-I étaient extrêmement défectueux, et nous avons ajouté le code suivant
/* Certains peripheriques scsi-1 ne gerent pas lun != 0. Je suppose que les peripheriques scsi-2 font mieux. */ if((scsi_result[2] & 0x07) == 1 && (scsi_result[3] & 0x0f) == 0) break;
à scan_scsis() dans drivers/scsi/scsi.c. Si vous supprimez ce code, vos anciens périphériques devraient être correctement détectés si vous n'avez pas utilisé l'option de ligne de commande du noyau max_scsi_luns, ou la définition NO_MULTI_LUN au moment de la compilation.
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