Le SCSI HOWTO Linux

par Drew Eckhardt,<drew@PoohSticks.ORG> (transformé au format linuxdoc-sgml par Dieter Faulbaum), <faulbaum@bii.bessy.de> (Adaptation française : Thierry Danis thierry.danis@hol.fr, le 28 Novembre 1997).

Version 2.30, 30 Août 1996

1. Introduction

Copyright

Ce document est distribué sous les contraintes de la GPL (GNU Public Licence). Les lignes suivantes sont le texte intégral anglais de la licence.

This documentation is free documentation; you can redistribute it and/or
modify it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This documentation is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this documentation; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

En dehors de l'aspect GPL, j'apprécierais que les personnes intéressées à publier ce document me demandent (<drew@PoohSticks.ORG>) auparavant si une version plus récente existe. A chaque fois qu'une version un peu ancienne est publiée, on me pose des questions qui ont déjà leur réponse dans les derniers documents, et la réputation de l'éditeur en fait les frais. Je préférerais également que toute réference à un site de distribution gratuit, voire à des distributeurs commerciaux, soit laissée intacte.

IMPORTANT:

LES RAPPORTS D'ANOMALIES ET AUTRES APPELS A L'AIDE QUI NE SUIVENT PAS LES PROCEDURES DECRITES DANS LA SECTION Signaler une anomalie SERONT IGNORES.

Ce HOWTO couvre le sous-système SCSI de Linux, tel qu'il existe dans le noyau version 1.2.10 et dans des codes alpha plus récents. Les versions plus vieilles du code SCSI ne sont plus supportées et peuvent différer sensiblement en ce qui concerne les pilotes implémentés, les performances et les options disponibles.

Pour toute information supplémentaire, vous pouvez vous inscrire à la liste de diffusion linux-scsi, en envoyant un email à majordomo@vger.rutgers.edu contenant la ligne suivante dans le corps du message :

subscribe linux-scsi

Vous pouvez vous radier de la liste en envoyant un email à la même adresse contenant dans le corps du message :

unsubscribe linux-scsi

Une fois votre inscription effective, vous pouvez envoyer des emails dans la liste de diffusion à l'adresse suivante :

linux-scsi@vger.rutgers.edu

Je suis conscient que ce document n'est pas des plus conviviaux et qu'il comporte certainement des erreurs et des imprécisions. Si vous avez des remarques constructives, n'hésitez pas à me les poster.

2. Les problèmes courants

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.

2.1 Dysfonctionnement généralisé

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 :

  1. se prévalent d'une compatibilité SCSI-II,
  2. ont une impédance caractéristique de 132 ohms,
  3. proviennent tous d'une même source, afin d'éviter les écarts d'impédance,
  4. sont proposées par un vendeur réputé (tel qu'Amphenol).

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.

2.2 La ligne de commande du noyau

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"

2.3 Un périphérique apparaît à toutes les adresses SCSI

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.

2.4 Le même périphérique est reconnu à chaque unité logique

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 <Linus.Torvalds@cs.Helsinki.FI>.

2.5 Vous avez des 'sense errors' alors que vous savez que votre matériel n'a pas d'erreurs

Cela est parfois dû à un mauvais cordon ou à une terminaison mal adaptée.

Référez-vous au chapitre Dysfonctionnement généralisé.

2.6 Un noyau configuré avec support réseau ne marche pas

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.

2.7 Des périphériques sont détectés, mais il est impossible d'y accéder

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/périphérique b|c majeur mineur

par exemple :

mknod /dev/sdc b 8 32
mknod /dev/st0 c 9 0

2.8 Le SCSI se bloque

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.

2.9 Configurer et regénérer le noyau

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

2.10 Les unités logiques autres que la première ne fonctionnent pas

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;

3. Signaler une anomalie

Soumis à des contraintes de place, les développeurs des parties SCSI de Linux ne maintiennent pas obligatoirement les vieilles versions du code. Si vous ne tournez pas avec la dernière version du noyau (la plupart des distributions de Linux, (MCC, SLS, Yggdrasil, etc.) peuvent avoir jusqu'à une vingtaine de patches de retard sur le dernier noyau), il y a une forte probabilité pour que vous ne soyez pas capable de résoudre votre problème. Avant de signaler une anomalie, vérifiez si elle existe encore avec la toute dernière version du noyau.

Si après avoir mis à jour votre noyau et lu entièrement ce document, vous pensez vraiment avoir découvert un problème, envoyez par email un rapport d'anomalie à la liste de diffusion SCSI, où il aura des chances d'être lu par la plupart des personnes ayant participé au développement des pilotes SCSI pour Linux.

Mettez dans votre rapport d'anomalie le maximum d'information sur votre configuration matérielle, le texte exact des messages que Linux affiche au démarrage, le moment où l'erreur se produit et à quel endroit dans les sources l'erreur a été levée. Référez-vous aux chapitres Capture des messages SCSI et Localisation de l'origine d'un panic().

Des informations incomplètes peuvent conduire à de mauvais diagnostics ou à un classement vertical de la part du développeur du pilote, qui risque d'estimer qu'il a plus important à corriger.

Retenez bien ceci : si nous ne pouvons pas reproduire le problème et si vous ne pouvez pas nous dire ce qui ne marche pas, l'anomalie ne sera jamais corrigée.

3.1 Capture des messages SCSI

Si aucun archiveur (logger) de messages ne tourne, il va falloir en lancer un. Vérifiez que le système de fichiers /proc est monté :

grep proc /etc/mtab

S'il ne l'est pas, il faut le monter :

mkdir /proc
chmod 755 /proc
mount -t proc /proc /proc

Recopiez ensuite la version du noyau et ses messages dans un fichier de log :

cat /proc/version > /tmp/log
cat /proc/kmsg >> /tmp/log

Attendez une seconde ou deux (le temps que le cat /proc/kmsg se termine) puis tapez CTRL-C.

Si un logger de messages tourne, vous allez devoir chercher dans le fichier de traces adéquat (jetez un oeil à /etc/syslog.conf pour trouver où se cache ce fichier). Vous pouvez aussi taper la commande dmesg.

Si Linux n'est pas lancé, formatez une disquette sous DOS. Si votre distribution monte la disquette en tant que racine (root) plutôt qu'un disque RAM, vous allez devoir formater une disquette et la mettre dans le lecteur non utilisé par la racine (si vous disposez de deux lecteurs). Si vous n'avez pas de second lecteur, il vous faudra utiliser l'option de démarrage 'ramdisk'.

Maintenant, démarrez depuis la disquette de boot de votre distribution, de préférence en mode utilisateur simple (single user) et en demandant à placer la racine (root) dans un disque RAM.

mkdir /tmp/dos

Insérez la disquette dans un lecteur non utilisé pour monter la racine et montez-la :

mount -t msdos /dev/fd0 /tmp/dos

ou

mount -t msdos /dev/fd1 /tmp/dos

Copiez-y ensuite votre fichier de traces :

cp /tmp/log /tmp/dos/log

Démontez votre disquette DOS

umount /tmp/dos

et arrêtez Linux.

shutdown

Redémarrez sous DOS puis incluez le fichier de traces dans votre mail.

3.2 Localisation de l'origine d'un panic()

Ainsi que d'autres Unix le font, Linux appelle la fonction du noyau panic() lorsqu'une erreur fatale est détectée. Par contre, contrairement à d'autres Unix, Linux ne produit pas un fichier de dump dans la swap. Il ne redémarre pas non plus. Il laisse dans le fichier de traces des informations intéressantes. Par exemple :

Unable to handle kernel NULL pointer dereference at virtual address c0000004
current->tss,cr3 = 00101000, %cr3 = 00101000
*pde = 00102027
*pte = 00000027
Oops: 0000
EIP:    0010:0019c905
EFLAGS: 00010002
eax: 0000000a   ebx: 001cd0e8   ecx: 00000006   edx: 000003d5
esi: 001cd0a8   edi: 00000000   ebp: 00000000   esp: 001a18c0
ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=001a09c8)
Stack: 0019c5c6 00000000 0019c5b2 00000000 0019c5a5 001cd0a8 00000002 00000000
       001cd0e8 001cd0a8 00000000 001cdb38 001cdb00 00000000 001ce284 0019d001
       001cd004 0000e800 fbfff000 0019d051 001cd0a8 00000000 001a29f4 00800000
Call Trace: 0019c5c6 0019c5b2 0018c5a5 0019d001 0019d051 00111508 00111502
            0011e800 0011154d 00110f63 0010e2b3 0010ef55 0010ddb7
Code: 8b 57 04 52 68 d2 c5 19 00 e8 cd a0 f7 ff 83 c4 20 8b 4f 04
Aiee, killing interrupt handler
kfree of non-kmalloced memory: 001a29c0, next= 00000000, order=0
task[0] (swapper) killed: unable to recover
Kernel panic: Trying to free up swapper memory space
In swapper task - not syncing

Prenez la valeur hexadécimale du registre EIP (le compteur de programme ; ici, en l'occurence, 19c905). Cherchez ensuite dans le fichier /usr/src/linux/zSystem.map (ou le fichier System.map correspondant au noyau que vous êtes en train d'exécuter) la plus grande valeur inférieure à la valeur du registre EIP. Par exemple,

0019a000 T _fix_pointers
0019c700 t _intr_scsi
0019d000 t _NCR53c7x0_intr

indique dans quelle fonction l'erreur fatale s'est produite. Recompilez ce fichier en ayant autorisé les options de debug (vous pouvez aussi les autoriser à un niveau plus global en éditant le fichier /usr/src/linux/Makefile et en ajoutant l'option "-g" à la variable CFLAGS).

#
# standard CFLAGS
#

Par exemple :

CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe

devient

CFLAGS = -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe

Regénérez le noyau, incrémentalement ou en tapant

make clean
make

Rendez le noyau démarrable (bootable) en créant une entrée dans le fichier /etc/lilo.conf :

image = /usr/src/linux/zImage
label = experimental

N'oubliez pas de relancer LILO en tant que root (/sbin/lilo). Vous pouvez aussi créer une disquette de démarrage :

make zImage

Redémarrez et notez le nouvel EIP pour l'erreur.

Si vous avez installé script, lancez-le ; il va tracer toute votre session dans un fichier.

Maintenant, lancez

gdb /usr/src/linux/tools/zSystem

et tapez

info line *<votre EIP>

Par exemple,

info line *0x19c905

GDB devrait répondre quelque chose du genre

(gdb) info line *0x19c905
Line 2855 of "53c7,8xx.c" starts at address 0x19c905 <intr_scsi+641&>
   and ends at 0x19c913 <intr_scsi+655>.

Mémorisez cette information. Entrez ensuite

list <numéro de ligne>

Par exemple,

(gdb) list 2855
2850    /*      printk("scsi%d : target %d lun %d unexpected disconnect\n",
2851                host->host_no, cmd->cmd->target, cmd->cmd->lun); */
2852            printk("host : 0x%x\n", (unsigned) host);
2853            printk("host->host_no : %d\n", host->host_no);
2854            printk("cmd : 0x%x\n", (unsigned) cmd);
2855            printk("cmd->cmd : 0x%x\n", (unsigned) cmd->cmd);
2856            printk("cmd->cmd->target : %d\n", cmd->cmd->target);
2857            if (cmd) {;
2858                abnormal_finished(cmd, DID_ERROR << 16);
2859            }
2860            hostdata->dsp = hostdata->script + hostdata->E_schedule /
2861                sizeof(long);
2862            hostdata->dsp_changed = 1;
2863        /* SCSI PARITY error */
2864        }
2865
2866        if (sstat0_sist0 & SSTAT0_PAR) {
2867            fatal = 1;
2868            if (cmd && cmd->cmd) {
2869                printk("scsi%d : target %d lun %d parity error.\n",

quit vous permet de sortir de GDB.

Sauvegardez également cette information, car elle permettra de fournir le contexte dans lequel l'erreur s'est produite, pour le cas où les développeurs n'auraient pas exactement la même arborescence.

4. Les modules

Ce chapitre fournit des détails spécifiques sur le support des modules chargeables et sur la manière dont ces modules sont utilisés avec le SCSI.

4.1 Informations générales

Les modules chargeables permettent à l'utilisateur ou à l'administrateur du système d'étendre les fonctionnalités du noyau en y chargeant des fichiers objet. L'utilisation la plus courante des modules est l'ajout de pilotes pour de nouveaux périphériques ou la prise en compte de différents types de systèmes de fichiers.

L'utilisation des modules pour le SCSI présente plusieurs avantages. Un de ceux-ci est que le responsable d'un parc important de machines n'a à gérer qu'un seul noyau pour tout le parc et n'a plus qu'à charger les modules nécessaires machine par machine.

Pour ceux qui ont l'intention de créer une nouvelle distribution, il est possible de lancer un script depuis la disquette de démarrage qui va demander à l'utilisateur quels modules sont à charger. Cela permet de gagner de la mémoire (qui serait gaspillée si le noyau contenait tous les pilotes) et cela réduit le risque que l'auto-détection d'une carte vienne perturber le fonctionnement d'autres cartes.

Les modules sont parfaits pour les portables, qui ont tendance à être moins fournis que leurs grands frères de bureaux. Dans ce cas, un noyau aussi réduit que possible avec chargement des modules à la demande est l'idéal. De plus, les modules sont bien adaptés au mécanisme des cartes PCMCIA, puisqu'ils peuvent être chargés puis déchargés au gré des insertions/retraits des cartes PCMCIA. (Note : actuellement, les pilotes qlogic et 152x supportent le PCMCIA).

Un dernier avantage des modules est que les développeurs de pilotes ont plus de facilité à mettre au point et tester leurs pilotes si ceux-ci sont sous forme de modules (il n'est plus nécessaire de redémarrer la machine à chaque essai, à condition bien sûr que le pilote ne soit pas buggé au point qu'il ait mis en rideau le PC).

Mais, il y a toujours un mais, les modules ont aussi leurs limitations. Si votre partition racine (root) est sur un périphérique SCSI, vous ne serez pas capable d'utiliser les versions 'modularisées' des pilotes SCSI nécessaires à l'accès à votre disque. Cela est dû au fait que le noyau doit être capable de monter la partition racine avant de pouvoir charger le moindre module depuis le disque. Cela étant, des réflexions sont en cours pour modifier le chargeur et le noyau de manière à ce que celui-ci soit capable de précharger des modules avant d'essayer de monter la partition racine. Il est fort probable qu'à l'avenir la limitation actuelle ne soit plus de mise.

4.2 Le support des modules dans les noyaux 1.2.N

Les modules noyau pour le SCSI sont partiellement supportés dans la série 1.2.N du noyau. Alors qu'aucun des pilotes de haut niveau (disque, bande, etc.) ne peut être modularisé, la plupart des pilotes de bas niveau peuvent être chargés et déchargés à la demande (par exemple les 1542 et 1522). Chaque fois qu'un pilote de bas niveau est chargé, il commence par rechercher les cartes qu'il peut gérer. Ensuite, pour chaque carte détectée, le bus SCSI est scruté et des structures de données internes sont renseignées, si bien qu'il sera possible d'utiliser tous les périphériques attachés aux cartes reconnues.

Lorsque vous en avez terminé avec un pilote de bas niveau, celui-ci peut être déchargé. Gardez à l'esprit que l'utilisation d'un pilote se fait au travers des montages, des fichiers ouverts, etc. Si vous essayez de décharger un module en cours d'utilisation (utilitaire rmmod), le noyau va refuser le retrait du pilote. Lorsqu'un pilote est déchargé, toutes ses structures internes sont libérées, si bien que le système retourne dans l'état où il se trouvait avant l'insertion du module. Vous pourrez recharger le pilote plus tard si vous le désirez.

4.3 Le support des modules dans les noyaux 1.3.N

Le code SCSI a été complètement modularisé dans les noyaux 1.3.N. Vous pouvez donc démarrer avec un noyau n'ayant aucun support SCSI, les modules se chargeant par la suite, jusqu'à ce que tous les périphériques SCSI possibles soient accessibles.

Si vous le voulez, vous pouvez intégrer dans le noyau une certaine partie du code SCSI et charger le reste plus tard sous forme de modules. Tout cela dépend entièrement de vous.

Si vous démarrez avec un noyau qui n'a aucun support SCSI, vous devrez commencer par charger la base SCSI. La base se trouve dans un module nommé "scsi_mod" ; elle est indispensable à la gestion du SCSI. Elle ne contient par contre aucun pilote spécifique de bas niveau et de ce fait ne scrutera ni carte, ni périphérique. Cette base n'activera pas non plus de pilotes de disques SCSI, de lecteurs de bandes, etc. Si vous avez répondu 'Y' à la question CONFIG_SCSI au moment de construire le noyau, vous n'aurez pas besoin de charger ce module.

Maintenant que "scsi_mod" est présent dans le noyau, vous pouvez ajouter les modules plus ou moins dans n'importe quel ordre pour ouvrir l'accès à vos périphériques. Des compteurs d'utilisation sont présents pour éviter de retirer un pilote occupé. Si vous utilisez rmmod, vous en serez averti par un message d'erreur.

Les pilotes de haut niveau pour les disques, les lecteurs de CDROM, les lecteurs de bandes et le support SCSI générique se trouvent respectivement dans les modules "sd_mod", "sr_mod", "st" et "sg". Lorsque vous chargez un pilote de haut niveau, tous les périphériques détectés (par les pilotes de bas niveau) et gérés par ce pilote sont automatiquement activés.

L'utilisation des modules avec des pilotes de bas niveau a été décrite dans le chapitre Le support des modules dans les noyaux 1.2.N. Lorsqu'un pilote de bas niveau est chargé, le bus est scruté et chaque périphérique reconnu est ensuite éventuellement pris en charge par un pilote de plus haut niveau (voir paragraphe précédent).

5. Cartes d'interface

Ce chapitre donne des informations spécifiques sur les diverses cartes d'interface SCSI qui sont supportées d'une manière ou d'une autre par Linux.

5.1 Matériel supporté et non supporté

Les pilotes de la distribution du noyau :

Adaptec 152x, Adaptec 154x (les cartes DTC 329x fonctionnent théoriquement, mais ne sont pas explicitement gérées), Adaptec 174x, Adaptec 274x/284x (le support pour la 294x nécessite une version plus récente du pilote), BusLogic MultiMaster Host Adapters, les cartes compatibles avec les protocoles EATA-DMA et EATA-PIO (DPT PM2001, PM2011, PM2012A, PM2012B, PM2021, PM2022, PM2024, PM2122, PM2124, PM2322, PM2041, PM2042, PM2044, PM2142, PM2144, PM2322, PM3021, PM3122, PM3222, PM3224, PM3334, quelques cartes de NEC, AT&T, SNI, AST, Olivetti et Alphatronix), Future Domain 850, 885, 950 et d'autres cartes de cette série (sauf les cartes 840, 841, 880 et 881 à moins que vous n'appliquiez le patch adéquat), Future Domain 16x0 avec les composants TMC-1800, TMC-18C30 ou TMC-18C50, NCR53c8xx, PAS16, les ports SCSI, Seagate ST0x, les cartes Trantor T128/T130/T228, Ultrastor 14F, 24F et 34F et les Western Digital 7000.

MCA :

Les cartes MCA compatibles avec une des cartes précédemment citées fonctionnent.

Les pilotes alpha :

Plusieurs pilotes ALPHA sont disponibles à

ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi

Certains pilotes fonctionnent après quelques modifications :

NCR53c8x0/7x0:

Un pilote NCR53c8xx a été développé mais il ne marche toujours pas avec les
composants NCR53c700, NCR53c700-66, NCR53c710 et NCR53c720. Une liste des
modifications nécessaires pour le faire marcher sur chacun de ces composants
est fournie ci-après, accompagnée d'un résumé de la difficulté de chaque patch.

NCR53c720 (facile) - modifications dans la détection du composant, dans la
phase d'initialisation, dans la traduction des adresses des registres '810
vers l'organisation (mapping) des registres '7xx.

NCR53c710 (facile) - modifications dans la détection du composant, dans la
phase d'initialisation, dans la traduction des adresses des registres '810 
vers l'organisation (mapping) des registres '7xx, modification des
gestionnaires d'interruption pour traiter l'interruption IID de l'instruction
INTFLY pour l'émuler (Note aux relecteurs (à supprimer dans la version
définitive) je ne suis pas sûr d'avoir bien compris ce que voulait dire
l'auteur : change interrupt handlers to treat IID interrupt from INTFLY
instruction to emulate it),

NCR53c700, NCR53c700-66 (très compliqué) - modifications dans la détection
des composants, dans la phase d'initialisation. Modification du code du NCR
pour ne pas utiliser DSA, modification du code de la gestion des commutations
de contextes.

Les cartes SCSI qui ne marcheront pas :

Tous les adapteurs parallèle->SCSI, les cartes Rancho SCSI et les cartes Grass Roots SCSI. Les cartes BusLogic FlashPoint, telles que les BT-930/932/950, ne sont actuellement pas supportées.

Les cartes SCSI qui ne marcheront JAMAIS :

Les cartes non compatibles Adaptec, les cartes non NCR53c8xx DTC (y compris les 3270 et les 3280).

Les cartes CMD SCSI.

L'obtention d'informations techniques sur ces cartes nécessite la signature d'un accord de confidentialité (NDA : non-disclosure agreement) avec DTC/CMD. En conséquence, distribuer un pilote pour Linux est impossible car se conformer à cet accord signifie qu'il n'est pas possible de fournir les sources, ce qui est en violation de la GPL. Inversement, se conformer à la GPL signifie que les sources doivent être rendus publics, ce qui est en conflit avec la NDA.

Si vous voulez utiliser Linux sur du matériel non supporté, deux options s'offrent à vous :

  1. écrire vous-même le pilote (Eric Youngdale et moi-même répondons volontiers aux questions techniques sur les pilotes SCSI pour Linux),
  2. faire développer le pilote (les tarifs habituels des sous-traitants rendent cette solution non viable pour une utilisation personnelle),

Cartes contrôleur multiples

Avec certaines cartes (voir Guide de l'acheteur : comparaison des fonctionnalités), vous pouvez utiliser plusieurs contrôleurs du même type sur la même machine. Dans ce cas, la plus petite adresse SCSI va être référencée par le noyau comme scsi0, la suivante comme scsi1, etc.

Dans tous les cas, il est possible d'utiliser des contrôleurs de types différents, sous réserve que leurs adresses n'entrent pas en conflit. Les cartes contrôleur sont scrutées dans l'ordre suivant (défini dans le tableau builtin_scsi_hosts[] du fichier drivers/scsi/hosts.c) :

BusLogic, Ultrastor 14/34F, Ultrastor 14F, Adaptec 151x/152x, Adaptec 154x, Adaptec 174x, AIC7XXX, AM53C974, Future Domain 16x0, Always IN2000, Generic NCR5380, QLOGIC, PAS16, Seagate, Trantor T128/T130, NCR53c8xx, EATA-DMA, WD7000 et le pilote de mise au point.

Dans la plupart des cas (c'est-à-dire si vous n'utilisez pas en même temps une BusLogic et une Adaptec), le tableau précédent peut être changé pour définir un ordre qui vous convient mieux (de manière à garder le même ordre pour les périphériques de votre ancienne carte lorsque vous ajoutez une nouvelle carte dans votre système); il vous suffit de déplacer les entrées du tableau.

5.2 Problèmes habituels

Timeouts SCSI

Vérifiez que les interruptions sont bien autorisées et qu'il n'y a pas de conflits d'IRQ, de DMA ou d'adresses avec d'autres cartes.

Echec de l'auto-détection des cartes qui s'appuient sur le BIOS

Si votre contrôleur SCSI est un des suivants :

Adaptec 152x, Adaptec 151x, Adaptec AIC-6260, Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950, Future Domain TMC-8xx, Trantor T128, Trantor T128F, Trantor T228F, Seagate ST01, Seagate ST02 ou un Western Digital 7000

et qu'il n'est pas détecté au démarrage (vous avez eu par exemple :

scsi : 0 hosts

ou encore

scsi%d : type

au démarrage), vous avez certainement un problème avec la routine d'auto-détection qui ne reconnaît pas votre carte contrôleur.

L'auto-détection échoue pour les pilotes qui s'appuient sur le BIOS si celui-ci est désactivé. Vérifiez plutôt deux fois qu'une que votre BIOS est activé et qu'il n'entre pas en conflit avec celui d'un autre périphérique.

L'auto-détection peut également échouer si la "signature" de la carte et son adresse de BIOS ne font pas partie de la liste des cartes connues.

Si le BIOS est installé, redémarrez sous DOS et utilisez DEBUG pour trouver la signature de votre carte.

Par exemple, si votre carte se trouve à l'adresse 0xc8000, redémarrez sous DOS puis tapez :

debug
d c800:0
q

Envoyez ensuite un message à la liste de diffusion SCSI avec le message ASCII obtenu, sa longueur et son déplacement par rapport à l'adresse de base (par exemple 0xc8000). Attention : le texte exact est nécessaire et vous aurez certainement à fournir une version ASCII et une autre binaire du message.

Si aucun BIOS n'est installé et si vous utilisez une Adaptec 152x, une Trantor T128 ou un contrôleur Seagate, vous pouvez utiliser la ligne de commande (LILO) ou bien surcharger des variables au moment de la compilation de manière à ce que l'auto-détection fonctionne malgré tout.

Reportez-vous à la section appropriée de votre carte SCSI, ainsi qu'au chapitre Dysfonctionnement généralisé.

Pannes de contrôleurs utilisant des E/S mappées en mémoire

(Les cartes Trantor T128 et Seagate sont de telles cartes. Les cartes Adaptec, Generic NCR5380, PAS16 et Ultrastor n'en sont pas)

Les pannes sont souvent dues à un 'cache' des ports d'entrées/sorties incorrect. L'espace d'adressage de la carte doit être indiqué comme 'non cachable' dans les paramètres de la XCMOS. Si ce n'est pas possible, il vous faudra complètement interdire le 'cache'.

Si vous avez manuellement spécifié l'adresse de la carte, souvenez-vous que Linux a besoin de la véritable adresse de la carte et non pas de l'adresse segmentée (par segments de 16 octets) à laquelle la documentation pourrait faire référence.

Ainsi, 0xc8000 est une adresse valide, tandis que 0xc800 ne marche pas et risque de causer des problèmes d'intégrité de la mémoire du noyau.

"kernel panic : cannot mount root device" au démarrage avec une disquette de démarrage comportant un pilote ALPHA

Vous allez devoir éditer l'image binaire du noyau (avant ou après l'avoir écrite sur la disquette) pour modifier quelques champs de deux octets (en petit indien -- little endian), afin de garantir qu'il fonctionnera sur votre système.

  1. le périphérique de pagination (swap) par défaut. Il se trouve à l'offset 502 et doit valoir 0x00 0x00
  2. la taille du disque mémoire (RAM disk) se trouve à l'offset 504. Elle doit valoir la taille de la disquette de démarrage, en Ko. Par exemple, pour une disquette 5,25", on trouvera 1200. Pour une disquette 3,5", on aura 1440.
    C'est à dire que les octets doivent être 
    
    3,5" : 0xA0 0x05
    5,25" : 0xB0 0x04
    
  3. l'identificateur du périphérique de la racine (root device) se trouve à la position 508 et doit valoir 0x00 0x00 (qui représente le périphérique de démarrage).

Recopiez le fichier sur la disquette par dd ou rawrite. Insérez ensuite la disquette dans un lecteur puis relancez. Attendez qu'il vous soit demandé d'insérer la disquette racine (root disk) puis mettez celle fournie avec votre distribution.

Installation d'un pilote non inclus dans le noyau de la distribution

Vous devez commencer avec la version du noyau utilisée par le développeur du pilote. Il arrive qu'on trouve la version en question dans la documentation incluse avec le pilote.

Des versions récentes du noyau sont présentes à l'adresse

nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus

dans les fichiers linux-version.tar.gz

On peut également les trouver sur divers sites et autres miroirs (dont tsx-11.mit.edu).

cd /usr/src

Supprimez l'ancienne arborescence des sources de Linux ou faites-en une copie :

mv linux linux-old

Désarchivez le fichier

gunzip < linux-0.99.12.tar.gz | tar xvfp -

(pour la version 0.99.12 ici). Appliquez les patches. Habituellement, les patches sont relatifs à un des répertoires de l'arborescence. En recherchant la chaîne '---' dans le fichier de patch, vous pouvez savoir à partir d'où l'appliquer. Ainsi, des lignes

--- ./kernel/blk_drv/scsi/Makefile

--- ./config.in Wed Sep  1 16:19:33 1993

vous pouvez déduire que les fichiers à modifier sont relatifs à /usr/src/linux.

Désarchivez les sources du pilote à l'endroit approprié :

tar tfv patches.tar

vous fournira d'abord une liste des fichiers. Déplacez quelques fichiers si nécessaire (les sources des pilotes SCSI doivent se trouver dans le répertoire /usr/src/linux/kernel/drivers/scsi).

Vous pouvez ensuite aller dans le répertoire racine du patch et taper :

patch -p0 < patch_file

Vous pouvez également demander à 'patch' d'éliminer les chemins initiaux des noms des fichiers à modifier. Ainsi, si les fichiers commencent par

--- linux-new/kernel/blk_drv/scsi/Makefile

et que vous voulez appliquer le patch directement depuis /usr/src/linux, vous pouvez faire les opérations suivantes :

cd /usr/src/linux
patch -p1 < patches

pour supprimer le "linux-new" des noms des fichiers.

Une fois les patches appliqués, vérifiez qu'il n'y a pas eu de rejets (un fichier de rejet a la même nom que le fichier à modifier, un suffixe # y étant ajouté).

find /usr/src/linux/ -name "*#" -print

Si vous trouvez des fichiers de rejet, éditez-les. Parfois, seules les chaînes d'identification RCS seront différentes. Cela ne posera alors pas de problème. Dans d'autres cas, il vous faudra appliquer d'importantes parties du patch à la main. Il n'est pas dans l'optique de ce document de décrire les fichiers de différences ou l'utilisation de patch.

Référez-vous également à la section Configurer et regénérer le noyau.

Installation d'un pilote qui n'a pas de patches

L'auteur d'un pilote ne fournit parfois pas de patches avec les .c et .h qui forment le pilote. Il se peut aussi que les patches soient faits pour une vieille version du noyau et qu'ils risquent de ne pas passer avec le noyau courant.

  1. copiez les .c et les .h dans /usr/src/linux/drivers/scsi
  2. ajoutez l'option de configuration Editez /usr/src/linux/config.in puis ajoutez une ligne (une variable de configuration booléenne pour votre pilote) dans le chapitre
    *
    * SCSI low-level drivers
    *
    
    Par exemple
    bool 'Always IN2000 SCSI support' CONFIG_SCSI_IN2000 y
    
  3. ajoutez les entrées dans le Makefile Editez /usr/src/linux/drivers/scsi/Makefile et ajoutez une entrée similaire à
    ifdef CONFIG_SCSI_IN2000
    SCSI_OBS := $(SCSI_OBJS) in2000.o
    SCSI_SRCS := $(SCSI_SRCS) in2000.c
    endif
    
    juste avant la ligne
    scsi.a: $(SCSI_OBJS)
    
    du makefile. Ici, le fichier .c est votre fichier source et le .o est le fichier objet généré à partir de votre fichier source (le .c est remplacé par le .o).
  4. ajoutez les points d'entrée Editez /usr/src/linux/drivers/scsi/hosts.c puis ajoutez un #include pour le fichier d'entête, mis en conditionnel par la constante que vous venez de définir dans le fichier de configuration. Par exemple, après
    #ifdef CONFIG_SCSI_GENERIC_NCR5380
    #include "g_NCR5380.h"
    #endif
    
    vous pouvez ajouter
    #ifdef CONFIG_SCSI_IN2000
    #include "in2000.h"
    #endif
    
    Vous devez également ajouter l'entrée pour le Scsi_Host_Template dans le tableau scsi_hosts[]. Jetez un oeil dans le fichier .h et vous devriez y trouver un #define qui ressemble à :
    #define IN2000 {"Always IN2000", in2000_detect, \
        in2000_info, in2000_command,    \
        in2000_queuecommand,            \
        in2000_abort,                   \
        in2000_reset,                   \
        NULL,                           \
        in2000_biosparam,               \
        1, 7, IN2000_SG, 1, 0, 0}
    
    Ajoutez la constante IN2000 dans le tableau scsi_hosts[], rendue conditionnelle par le symbole que vous venez de définir dans le fichier de configuration. Par exemple, après
    #ifdef CONFIG_SCSI_GENERIC_NCR5380
            GENERIC_NCR5380,
    #endif
    
    vous pouvez ajouter
    #ifdef CONFIG_SCSI_IN2000
            IN2000,
    #endif
    
    Référez-vous au chapitre Configurer et regénérer le noyau.

Panne d'une carte PCI dans un système Compaq

Un certain nombre de machines Compaq logent les extensions 32-bit du BIOS permettant de tester les contrôleurs PCI dans une zone mémoire inaccessible au noyau Linux (cela est dû à l'organisation de la mémoire). Si Linux est incapable de détecter une carte PCI SCSI connue comme étant supportée et si le noyau affiche un message du genre

pcibios_init: entry in high memory, unable to access

allez chercher

ftp://ftp.compaq.com/pub/softpaq/Software-Solutions/sp0921.zip

C'est un programme auto-extractible qui vous permettra de reloger le code du BIOS32.

Un système SCSI avec des contrôleurs PCI se bloque après le message %d Hosts

Certains systèmes PCI ont un BIOS défectueux qui masque les interruptions et qui n'arrive pas à les démasquer avant de rendre la main à l'appelant. Le patch suivant corrige ce problème :

--- bios32.c.orig       Mon Nov 13 22:35:31 1995
+++ bios32.c    Thu Jan 18 00:15:09 1996
@@ -56,6 +56,7 @@
 #include <linux/pci.h>

 #include <asm/segment.h>
+#include <asm/system.h>

 #define PCIBIOS_PCI_FUNCTION_ID        0xb1XX
 #define PCIBIOS_PCI_BIOS_PRESENT       0xb101
@@ -125,7 +126,9 @@
        unsigned long address;          /* %ebx */
        unsigned long length;           /* %ecx */
        unsigned long entry;            /* %edx */
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%edi)"
                : "=a" (return_code),
                  "=b" (address),
@@ -134,6 +137,7 @@
                : "0" (service),
                  "1" (0),
                  "D" (&bios32_indirect));
+       restore_flags(flags);

        switch (return_code) {
                case 0:
@@ -161,11 +165,13 @@
        unsigned char present_status;
        unsigned char major_revision;
        unsigned char minor_revision;
+       unsigned long flags;
        int pack;

        if ((pcibios_entry = bios32_service(PCI_SERVICE))) {
                pci_indirect.address = pcibios_entry;

+               save_flags(flags);
                __asm__("lcall (%%edi)\n\t"
                        "jc 1f\n\t"
                        "xor %%ah, %%ah\n"
@@ -176,6 +182,7 @@
                        : "1" (PCIBIOS_PCI_BIOS_PRESENT),
                          "D" (&pci_indirect)
                        : "bx", "cx");
+               restore_flags(flags);

                present_status = (pack >> 16) & 0xff;
                major_revision = (pack >> 8) & 0xff;
@@ -210,7 +217,9 @@
 {
        unsigned long bx;
        unsigned long ret;
+       unsigned long flags;

+       save_flags(flags);
        __asm__ ("lcall (%%edi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -221,6 +230,7 @@
                  "c" (class_code),
                  "S" ((int) index),
                  "D" (&pci_indirect));
+       restore_flags(flags);
        *bus = (bx >> 8) & 0xff;
        *device_fn = bx & 0xff;
        return (int) (ret & 0xff00) >> 8;
@@ -232,7 +242,9 @@
 {
        unsigned short bx;
        unsigned short ret;
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%edi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -244,6 +256,7 @@
                  "d" (vendor),
                  "S" ((int) index),
                  "D" (&pci_indirect));
+       restore_flags(flags);
        *bus = (bx >> 8) & 0xff;
        *device_fn = bx & 0xff;
        return (int) (ret & 0xff00) >> 8;
@@ -254,7 +267,9 @@
 {
        unsigned long ret;
        unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;

+       save_flags (flags);
        __asm__("lcall (%%esi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -273,7 +288,9 @@
 {
        unsigned long ret;
        unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%esi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -292,7 +309,9 @@
 {
        unsigned long ret;
        unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%esi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -303,6 +322,7 @@
                  "b" (bx),
                  "D" ((long) where),
                  "S" (&pci_indirect));
+       restore_flags(flags);
        return (int) (ret & 0xff00) >> 8;
 }

@@ -311,7 +331,9 @@
 {
        unsigned long ret;
        unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%esi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -322,6 +344,7 @@
                  "b" (bx),
                  "D" ((long) where),
                  "S" (&pci_indirect));
+       restore_flags(flags);
        return (int) (ret & 0xff00) >> 8;
 }

@@ -330,7 +353,9 @@
 {
        unsigned long ret;
        unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%esi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -341,6 +366,7 @@
                  "b" (bx),
                  "D" ((long) where),
                  "S" (&pci_indirect));
+       restore_flags(flags);
        return (int) (ret & 0xff00) >> 8;
 }

@@ -349,7 +375,9 @@
 {
        unsigned long ret;
        unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;

+       save_flags(flags);
        __asm__("lcall (%%esi)\n\t"
                "jc 1f\n\t"
                "xor %%ah, %%ah\n"
@@ -360,6 +388,7 @@
                  "b" (bx),
                  "D" ((long) where),
                  "S" (&pci_indirect));
+       restore_flags(flags);
        return (int) (ret & 0xff00) >> 8;
 }

5.3 Adaptec 152x, 151x, 1505, 282x, Sound Blaster 16 SCSI, SCSI Pro, Gigabyte et autres produits basés sur l'AIC 6260/6360 (standard)

Configurations supportées :

adresses du BIOS : 0xd8000, 0xdc000, 0xd0000, 0xd4000, 0xc8000, 0xcc000,
                   0xe0000, 0xe4000.
Ports            : 0x140, 0x340
IRQs             : 9, 10, 11, 12
DMA              : non utilisé
E/S              : port mappé

Auto-détection :

Cela marche avec de nombreuses cartes qui ont un BIOS installé. Toutes les autres cartes,
y compris les Adaptec 1510 et les Sound Blaster 16 SCSI, nécessitent d'utiliser une ligne
de commande du noyau ou une surcharge au moment de la compilation.

Surcharge de l'auto-détection :

Au moment de la compilation :

Définissez PORTBASE, IRQ, SCSI_ID, RECONNECT, PARITE de manière adéquate (voir Définitions)

Ligne de commande du noyau :

aha152x=<PORTBASE>[,<IRQ>[,<SCSI-ID>[,<RECONNECT>[,<PARITE>]]]]

Le champ SCSI-ID est l'identificateur SCSI de la carte contrôleur. Aucun autre périphérique connecté sur ce bus SCSI ne doit avoir ce numéro. Habituellement, il est fixé à 7.

Pour forcer l'auto-détection à l'adresse 0x340, l'IRQ 11, SCSI-ID 7 et autoriser la connexion/déconnexion, vous devez utiliser la ligne de commande suivante :

aha152x=0x340,11,7,1

Problèmes préhistoriques, résolus en mettant à jour le noyau :

  1. le pilote n'arrive pas à gérer les cartes VLB. Il y avait un problème de temporisation avec les noyaux antérieurs à la version 1.0.5.

Les constantes :

AUTOCONF       : utiliser la configuration reportée par le contrôleur (uniquement pour les 152x)
IRQ            : surcharge du niveau d'interruption (9,10,11 ou 12) (11 par défaut)
SCSI_ID        : surcharge du SCSI ID de l'AIC-6260 (0-7) (7 par défaut)
RECONNECT      : surcharge l'indicateur de déconnexion/resélection (une valeur non nulle
                 signifie 'autoriser', une valeur nulle signifie 'interdire')
DONT_SNARF     : n'enregistre pas les ports (pl12 et inférieurs)
SKIP_BIOSTEST  : ne teste pas la signature du BIOS (pour la AHA-1510 ou en cas de BIOS débrayé)
PORTBASE       : force le port de base. Il ne faut pas essayer l'auto-détection

5.4 Adaptec 154x, AMI FastDisk VLB, DTC 329x (standard)

Configurations supportées :

Ports          : 0x330 et 0x334
IRQs           : 9, 10, 11, 12, 14, 15
Canaux DMA     : 5, 6, 7
E/S            : port mappé, contrôle de bus (bus master)

Auto-détection :

détecte uniquement les cartes en 0x330 et 0x334.

Surcharge de l'auto-détection :

aha1542=<PORTBASE>[,<BUSON>,<BUSOFF>[,<VITESSEDMA>]]

Notes :

  1. BusLogic produit une série de cartes logiciellement compatibles avec les Adaptec 1542. Ces cartes existent en ISA, VLB, EISA et plusieurs variétés en PCI.
  2. Des cartes sans suffixe et les premières cartes à suffixe 'A' n'acceptent pas le 'découpage' / 'réassemblage' (scatter/gather), et, de ce fait, ne fonctionnent pas. Moyennant une redéfinition du mot 'fonctionnement', on peut les faire marcher à condition de mettre AHA1542_SCATTER à 0 dans le fichier drivers/scsi/aha1542.h.

Problèmes préhistoriques, résolus en mettant à jour le noyau :

  1. Les versions du noyau antérieures à la version 0.99.10 ne gèrent pas la version 'C' des contrôleurs.
  2. Les versions du noyau antérieures à la version 0.99.14k ne gèrent pas les options suivantes pour les cartes version 'C' :
  3. Les versions du noyau antérieures à la version 0.99.15e ne gèrent pas les versions 'C' avec support du BIOS pour plus de 2 disques activé et le support du BIOS pour le mapping étendu des disques > 1G désactivé
  4. Les versions du noyau antérieures à la version 0.99.14u ne supportent les versions 'CF' de ce type de cartes
  5. Il existait un séquencement critique (race condition) dans les versions du noyau antérieures à la version 1.0.5 lorsque plusieurs périphériques étaient accédés simultanément.

Problèmes fréquents :

  1. erreurs 'non attendues' avec des cartes 154xC ou 154xCF. Certaines cartes 154xC parmi les premiers exemplaires généraient un signal à haute fréquence sur un des signaux SCSI, provoquant des réflexions dans des câbles de mauvaise impédance.

    Les nouvelles cartes ne sont pas vraiment meilleures et sont pointilleuses sur la qualité des câbles et sur la sensibilité des terminaisons.

    Référez-vous aux chapitres Problèmes fréquents #2 et #3, Problèmes habituels, ou Dysfonctionnement généralisé.

  2. erreurs 'non attendues' avec des cartes 154xC ou 154x lorsqu'à la fois des périphériques internes et externes sont connectés. C'est probablement un problème de terminaison. Afin de pouvoir utiliser l'option logicielle permettant de désactiver la terminaison interne de la carte, vous devez positionner le cavalier 1 sur OFF. Référez-vous aux chapitres Problèmes fréquents #1 et #3, Problèmes habituels, ou Dysfonctionnement généralisé.
  3. le sous-système SCSI se bloque complètement. Dans certains cas, le blocage semble se produire lors de l'utilisation simultanée de plusieurs périphériques. Si cela arrive, contactez le fabricant de ces périphériques et voyez si une éventuelle mise à jour du firmware résoudrait le problème. En dernier recours, vous pouvez modifier AHA1542_MAILBOX à 1 dans le fichier aha1542.h. Cela va limiter le nombre de commandes présentes sur le bus SCSI à 1 à la fois. Il se peut que ça résolve le problème. Par contre, une fois encore, si vous avez des périphériques lents (lecteur de bandes, lecteur de CDROM), ce contournement risque de ne pas être une solution utilisable. Reportez-vous aux chapitres Problèmes fréquents #1 et #2, Problèmes habituels ou Le SCSI se bloque.
  4. Le message "Interrupt received, but no mail" est affiché au démarrage et vos périphériques SCSI ne sont pas détectés. Désactivez les options du BIOS pour la gestion du mapping étendu pour les disques > 1G, pour la gestion de plus de 2 périphériques et pour la scrutation automatique du bus (autoscanning). Ou alors, passez à une version de Linux 0.99.14k (ou plus récente).
  5. Si des erreurs de temporisation infinie apparaissent sur des cartes version 'C', entrez dans le programme de configuration Adaptec puis autorisez la négociation synchrone.
  6. Linux 1.2.x affiche le message "Unable to determine Adaptec DMA priority. Disabling board." Cela est dû à un conflit sur certains systèmes avec un pilote BusLogic obsolète. Vous pouvez soit regénérer votre noyau sans ce pilote, soit lui fournir une option sur la ligne de commande lui indiquant de scruter une adresse autre que celle de votre contrôleur. Par exemple, si votre carte Adaptec répond à l'adresse 0x334 et qu'il n'y a aucune autre carte en 0x330, utilisez la ligne de commande suivante :
    buslogic=0x330
    
  7. Le système se bloque lors d'accès simultanés à plusieurs périphériques sur des cartes 1542C ou 1540C avec la déconnexion activée. Quelques versions du firmware des Adaptec avaient des erreurs. Une mise à jour avec la version du BIOS v2.11 est censée corriger ce problème.

5.5 Adaptec 174x

Configurations supportées :

Emplacements   : 1-8
Ports          : non significatif (carte EISA)
IRQs           : 9, 10, 11, 12, 14, 15
Canaux DMA     : non significatif (carte EISA)
E/S            : port mappé, contrôle de bus

Auto-détection :

fonctionne avec toutes les configurations gérées

Surcharge de l'auto-détection :

aucune

Remarque :

  1. Cette carte n'est plus fabriquée par Adaptec.

Problèmes courants :

  1. Si le pilote de l'Adaptec 1740 affiche le message "aha1740: Board detected, but EBCNTRL = %x, so disabled it."

    votre carte a été désactivée parce qu'elle ne tournait pas en mode étendu (enhanced mode). Les cartes qui fonctionnent en mode 1542 standard ne sont pas gérées.

5.6 Adaptec 274x, 284x (standard) 294x (ALPHA)

Une nouvelle version qui gère également les cartes Adaptec 294x est disponible à l'adresse

ftp://ftp.ims.com/pub/Linux/aic7xxx

Configurations supportées :

                    274x           284x            294x
Emplacements EISA : 1-12           N/A             N/A
Ports             : N/A            TOUS            TOUS
IRQs              : ALL            TOUTES          TOUTES
Canaux DMA        : N/A            TOUS            N/A
E/S               : port mappé, contrôle de bus

Surcharge de l'auto-détection :

Ligne de commande du noyau :

aha274x=extended
(pour forcer le mapping étendu)

Remarques :

  1. Le BIOS doit être activé
  2. Le canal B des cartes 2742AT est ignoré
  3. CONFIG_PCI (lors de la génération du noyau) doit être positionnée si vous utilisez une carte PCI.

5.7 Always IN2000 (standard)

Configurations supportées :

Ports          : 0x100, 0x110, 0x200, 0x220
IRQs           : 10, 11, 14, 15
DMA            : non utilisé
E/S            : port mappé

Auto-détection :

le BIOS n'est pas nécessaire

Surcharge de l'auto-détection :

aucune

Problèmes courants :

  1. un problème connu concerne les systèmes avec des disques IDE et la pagination (swapping).

5.8 Cartes contrôleurs multi-maîtres BusLogic

(cette section est Copyright 1995 par Leonard N. Zubkoff <lnz@dandelion.com>) (le fichier README.BusLogic constitue une documentation plus complète du pilote BusLogic ; lisez-le)

                  Pilote SCSI BusLogic Multi-Maîtres pour Linux

                       Version 1.2.2 pour Linux 1.2.13
                       Version 1.3.2 pour Linux 1.3.88

                 ftp://ftp.dandelion.com/BusLogic-1.2.2.tar.gz
                 ftp://ftp.dandelion.com/BusLogic-1.3.2.tar.gz

                                 16 Avril 1996

                               Leonard N. Zubkoff
                               Dandelion Digital
                               lnz@dandelion.com

BusLogic  Inc.  conçoit  et  fabrique  un  ensemble de  contrôleurs SCSI de hautes
performances,  qui partagent une interface de  programmation commune pour diverses
architectures  de bus, par le biais de leur technologie ASIC Multi-Maîtres (Multi-
Master ASIC). Ce pilote gère tous les contrôleurs BusLogic Multi-Maîtres actuels,
et devrait gérer toutes les cartes Multi-Maîtres à venir avec peu (voire aucune) de
modifications.  Les contrôleurs  basés sur la  nouvelle architecture FlashPoint ne
sont pas gérés par ce pilote ; reportez-vous au fichier  README.FlashPoint pour la
marche à suivre pour passer d'une carte FlashPoint LT non gérée à une carte BT-948
supportée.

Mes buts principaux lorsque j'ai écrit ce pilote BusLogic complètement nouveau pour
Linux  étaient d'exploiter les performances maximales que les contrôleurs SCSI Bus-
Logic  et les périphériques SCSI  modernes sont capables d'atteindre  et de fournir
un pilote extrêmement fiable sur lequel des applications critiques puissent s'appu-
yer. Tout  peut être configuré sur la ligne de  commande du noyau, des performances
jusqu'aux détections d'erreurs. Cela permet à chaque installation d'ajuster les pa-
ramètres de performance et de gestion des erreurs aux besoins locaux.

BusLogic  est une  compagnie avec laquelle il a été très agréable de travailler, et
je  recommande chaleureusement leurs produits à la communauté Linuxienne. En Novem-
bre 1995, j'ai eu l'opportunité de devenir site bêta testeur pour leur dernier pro-
duit Multi-Maîtres - le contrôleur SCSI BT-948 PCI Ultra -, puis de nouveau pour le
contrôleur BT-958 PCI Wide Ultra en Janvier 1996. Cela a été un bénéfice réciproque,
car  nous avons apporté à BusLogic un environnement de test que leurs propres équi-
pes ne pouvaient pas avoir  et la communauté Linuxienne a disposé de contrôleurs de
hautes  performances  qui avaient  correctement été testés sur Linux avant même que
les  produits ne soient  commercialisés. Cette  relation avec BusLogic m'a en outre
donné  l'occasion d'interagir  directement avec leur  équipe technique  et ainsi de
leur  donner connaissance des besoins et des potentialités du monde Linux. Leur in-
térêt et leur support sont très appréciés.

Contrairement  à d'autres  vendeurs, si vous contactez le support technique de Bus-
Logic et que vous annoncez que vous tournez sous Linux, ils ne vont pas vous rétor-
quer que votre utilisation de leur produit n'est pas supportée. Leurs dernières pu-
blications commerciales mentionnent même "Les contrôleurs SCSI BusLogic sont compa-
tibles avec tous les systèmes d'exploitation importants, incluant : ... Linux ...".

BusLogic, Inc. se trouve à 4151  Burton Drive, Santa Clara, California, 95054, USA,
et vous pouvez les contacter par  téléphone au 408/492-9090 ou  par fax au 408/492-
1542. BusLogic dispose d'un  site Web (http://www.buslogic.com), d'un site FTP ano-
nyme (ftp.buslogic.com)  et d'une BBS au 408/492-1984. Le support technique de Bus-
Logic  peut être joint par  courrier électronique à l'adresse techsup@buslogic.com,
par  téléphone au 408/654-0760 ou par fax au  408/492-1542. Des  renseignements sur
leurs réprésentants en Europe et au Japon sont disponibles sur leur site Web.

                        LES CONTROLEURS GERES

La  liste  suivante comporte les  contrôleurs  SCSI BusLogic  gérés à la date de ce
document.  Il est  recommandé qu'une  personne se  portant  acquéreur  d'une  carte
BusLogic  non listée  dans la table  suivante contacte l'auteur de ce document pour
vérifier si elle est supportée ou si elle le sera un jour.

Les séries "W" :

BT-948      PCI     Ultra Fast Terminaison unique SCSI-2
BT-958      PCI     Ultra Wide Terminaison unique SCSI-2
BT-958D     PCI     Ultra Wide Différentielle SCSI-2

Les séries "C" :

BT-946C     PCI     Fast Terminaison unique SCSI-2
BT-956C     PCI     Fast Wide Terminaison unique SCSI-2
BT-956CD    PCI     Fast Wide Différentielle SCSI-2
BT-445C     VLB     Fast Terminaison unique SCSI-2
BT-747C     EISA    Fast Terminaison unique SCSI-2
BT-757C     EISA    Fast Wide Terminaison unique SCSI-2
BT-757CD    EISA    Fast Wide Différentielle SCSI-2
BT-545C     ISA     Fast Terminaison unique SCSI-2
BT-540CF    ISA     Fast Terminaison unique SCSI-2

Les séries "S": 

BT-445S     VLB     Fast Terminaison unique SCSI-2
BT-747S     EISA    Fast Terminaison unique SCSI-2
BT-747D     EISA    Fast Différentielle SCSI-2
BT-757S     EISA    Fast Wide Terminaison unique SCSI-2
BT-757D     EISA    Fast Wide Différentielle SCSI-2
BT-545S     ISA     Fast Terminaison unique SCSI-2
BT-542D     ISA     Fast Différentielle SCSI-2
BT-742A     EISA    Terminaison unique SCSI-2 (742A version H)
BT-542B     ISA     Terminaison unique SCSI-2 (542B version H)

Les séries "A" :

BT-742A     EISA    Terminaison unique SCSI-2 (742A versions A - G)
BT-542B     ISA     Terminaison unique SCSI-2 (542B versions A - G)

Les contrôleurs AMI FastDisk, véritables clones BusLogic, sont gérés par ce pilote.

                REMARQUES SUR L'INSTALLATION DES CARTES BT-948/958/958D

Les  contrôleurs SCSI BT-948/958/958D PCI Ultra ont des fonctionnalités qui peuvent
nécessiter une certaine attention lors de l'installation de Linux.

o Affectation des ports d'entrée/sortie PCI

  Lorsqu'elles  sont  configurées avec les valeurs par défaut usine, les cartes BT-
  948/958/958D vont  uniquement reconnaître les affectations des ports d'E/S faites
  par le BIOS  PCI de la  carte mère. Les  BT-948/958/958D ne  répondront  plus aux
  ports d'E/S compatibles ISA auxquels les contrôleurs SCSI BusLogic précédents ré-
  pondaient. Le pilote gère les affectations des ports d'E/S PCI. C'est la configu-
  ration à privilégier. Toutefois, si le pilote BusLogic obsolete doit être utilisé
  pour une raison quelconque, comme par exemple une distribution Linux qui n'utili-
  serait pas encore le nouveau pilote dans son noyau de démarrage, BusLogic a fourni
  une option de configuration AutoSCSI qui autorise les ports d'E/S compatibles ISA.

  Pour  activer  cette  option de  compatibilité  ascendante, appelez  l'utilitaire
  AutoSCSI  par  CTRL-B au démarrage du système  et  choisissez "Adapter Configura-
  tion",  "View/Modify Configuration", puis  changez les paramètres "ISA Compatible
  Port"  de "Disable"  à "Primary"  ou "Alternate". Une  fois que  ce  pilote a été
  installé, l'option "ISA Compatible Port" doit être remise à "Disable" pour éviter
  tout conflit de futurs ports  d'E/S. Les anciennes  cartes BT-946C/956C/956CD ont
  également cette option de configuration, mais le défaut usine est "Primary".

o L'ordre de scrutation des emplacements PCI

  Dans les  systèmes  comportant  plusieurs  contrôleurs PCI BusLogic, l'ordre dans
  lequel les  emplacements PCI sont scrutés peut apparaître inversé pour les cartes
  BT-948/958/958D par rapport aux cartes  BT-946C/956C/956CD. Pour démarrer  depuis
  un disque SCSI, il est  nécessaire que le  BIOS du contrôleur et  le noyau soient
  d'accord  sur quel  disque est le disque de  démarrage (boot disk). Cela implique
  qu'ils reconnaissent les  contrôleurs PCI dans  le même ordre. Le  BIOS PCI de la
  carte mère fournit un moyen standard d'énumérer les contrôleurs PCI. Ce moyen est
  utilisé par le noyau Linux. Certaines  implémentations du BIOS PCI  énumèrent les
  emplacements PCI par ordre croissant des numéros de bus et des numéros de contrô-
  leurs, alors que d'autres le font dans le sens contraire.

  Malheureusement,  Microsoft  a  décidé  que Windows 95  énumérerait  toujours les
  emplacements  PCI  dans l'ordre  croissant des  numéros  de bus et des numéros de
  contrôleurs indépendamment de l'énumération du BIOS PCI  et ils ont exigé que leur
  façon de faire soit  supportée par le  BIOS des  contrôleurs pour  être  certifié
  Windows 95. En  conséquence, les défauts usine des cartes BT-948/958/ 958D énumè-
  rent les contrôleurs par numéros croissants. Pour  désactiver ce  fonctionnement,
  appelez l'utilitaire AutoSCSI par CTRL-B au démarrage du système, puis choisissez
  "Adapter Configuration",  "View/Modify Configuration",  appuyez sur  CTRL-F10 et
  changez l'option "Use Bus And Device # For PCI Scanning Seq." à 0FF.

  Ce pilote va interroger la valeur de l'option de  Séquence De Scrutation PCI,  de
  manière  à reconnaître les contrôleurs dans le même ordre qu'ils ont été énumérés
  par le BIOS du contrôleur.

                        LA LISTE DE DIFFUSION DES ANNONCES BUSLOGIC

La  liste de diffusion des  annonces BusLogic constitue un forum d'information pour
les  utilisateurs Linux des  nouveautés (nouvelles  versions du  pilote  et  autres
annonces  concernant le  support pour  Linux des  contrôleurs  BusLogic). Pour vous
inscrire à la liste, envoyez un message à l'adresse suivante :
"BusLogic-announce-request@dandelion.com", avec la ligne  "subscribe" dans le corps
du message.

5.9 Les contrôleurs BusLogic FlashPoint

(cette section est Copyright 1995 par Leonard N. Zubkoff <lnz@dandelion.com>)

Il  n'y a pas de pilote Linux pour les cartes FlashPoint LT/DL/LW (BT-930/932/950),
et quand il va y en avoir ou s'il y en aura n'est pas très clair. Les cartes Flash-
Point  ont une  architecture différente des  cartes Multi-Maîtres  et  n'ont pas de
processeurs  sur la carte ; elles disposent d'un simple séquenceur SCSI. Elles sont
conçues pour les ordinateurs  de bureau  et ne sont pas  spécialement conçues  pour
des systèmes d'exploitation multitâches performants comme Linux.

Les  cartes Multi-Maîtres BT-948/958 ont  un processeur  embarqué et l'interface de
programmation  par "boîte à lettres"  permet de faire du parallélisme et du pipeli-
ning  entre le contrôleur et le système d'exploitation, alors que les cartes Flash-
Point nécessitent de fréquentes interventions du processeur principal. Etant  donné
que les  délais de  prise en  compte des  interruptions  augmentent sur  un système
chargé, les BT-948/958 continuent d'avoir d'excellentes  performances au  contraire
des FlashPoint, qui  s'écroulent  rapidement. De plus, le  firmware des  BT-948/958
possède la  connaissance  de bas niveau pour une  interaction  efficace avec le bus
SCSI. Avec un  séquenceur  SCSI comme dans les  FlashPoint, le  noyau Linux doit en
revanche contenir  lui-même  toutes ces  informations de  bas niveau,  et il est en
général long d'arriver à faire marcher tout cela proprement. Etant  donné le faible
écart de prix entre  ces deux  modèles, les  cartes BT-948 et  BT-958 sont de toute
évidence le meilleur choix pour Linux.

<début de citation>

                                ANNONCE
                Mise à jour des BusLogic FlashPoint vers les BT-948
                             1er Février 1996

Depuis  leur  apparition en Octobre 1995, les  BusLogic  FlashPoint  LT  ont  posé
des  problèmes  sous  Linux, si  bien  qu'aucun  pilote  n'est  encore  disponible
pour  cette  nouvelle  carte  Ultra SCSI. Bien que le produit  soit officiellement
déclaré  comme  une carte pour machine de bureau  et ne  soit pas particulièrement
efficace  dans  des environnements  multitâches  performants  tels  que  Linux, la
FlashPoint LT  a été annoncée  comme étant le dernier cri, le  nec plus ultra, par
les vendeurs d'ordinateurs  et elle s'est retrouvée sur certains de leurs systèmes
haut de gamme, à l'exclusion  de ceux équipés  des anciennes cartes Multi-Maîtres.
Cela  a  causé du tort à de  nombreuses personnes  qui  ont  par mégarde acheté un
système en s'attendant à ce que tous les produits BusLogic soient gérés par Linux,
et qui  ont finalement  découvert que la FlashPoint n'était pas supportée et ne le
serait pas avant longtemps, si elle devait l'être un jour.

Après  que  ce  problème a  été  identifié, BusLogic  est entrée  en contact  avec
ses  principaux clients  OEM pour  annoncer que les cartes  Multi-Maîtres BT-946C/
956C seraient  toujours disponibles,  et  que les  utilisateurs  Linux qui avaient
par  mégarde  commandé des systèmes à base  de FlashPoint pourraient mettre à jour
leur  machine avec une BT-946C. Si cela a aidé de nouveaux acheteurs, cela n'était
qu'une solution partielle au problème plus général du support de la FlashPoint pour
les  utilisateurs  de  Linux. Cette  annonce n'apportait  aucun soutien à ceux qui
avaient  initialement acheté une FlashPoint pour  un système d'exploitation qui la
gérait  et qui décidaient plus tard de passer à Linux ou  ceux qui avaient acheté
une  FlashPoint,  croyant  qu'elle était  gérée  et  qui étaient  incapables de la
retourner.

Mi-Décembre,  j'ai demandé à  rencontrer le  responsable de la gestion de BusLogic
pour  discuter  du support pour le  logiciel libre (free software)  et pour  Linux
de la FlashPoint. Des  bruits plus ou moins  exacts avaient  circulé  publiquement
sur l'attitude  de BusLogic  envers Linux  et  j'avais le sentiment  que le  mieux
était d'en  discuter  directement. J'envoyai  un message par  email un  soir  à 11
heures  et  la  réunion  eut lieu  le lendemain  après-midi. Malheureusement,  les
rouages  administratifs tournent lentement, particulièrement  lorsqu'une compagnie
est en cours d'acquisition, c'est pourquoi il a fallu attendre jusqu'à  maintenant
que tous les détails soient parfaitement clairs et qu'une annonce publique  puisse
être faite.

BusLogic  n'est  pas  prête  aujourd'hui  à publier  les  informations nécessaires
à ce  que des parties  tierces puissent  écrire des pilotes  pour  la  FlashPoint.
Les  seuls pilotes  existants pour  la FlashPoint  ont  été  écrits  par  l'équipe
technique de BusLogic  et il n'existe pas de documentation suffisamment  détaillée
pour permettre à un développeur extérieur d'écrire un pilote sans aide conséquente.
Alors  qu'il y a des gens  chez BusLogic  qui ne veulent  pas entendre  parler  de
divulgation  de détails  sur l'architecture  de la  FlashPoint, le débat n'est pas
entièrement  clos. Dans tous les cas, même  si la documentation  était  disponible
aujourd'hui, il faudrait certainement pas mal de temps pour qu'un pilote réellement
utilisable soit écrit, surtout que je ne suis pas convaincu que l'effort en vaille
la peine.

De toute façon, BusLogic continue à fournir une solution SCSI de hautes performan-
ces pour Linux  et ils ne désirent pas voir quelqu'un incapable de travailler sous
Linux  sous prétexte qu'il a une FlashPoint LT. En conséquence, BusLogic  a mis en
place un programme de mise à jour permettant à n'importe quel utilisateur de Linux
dans le monde de changer sa FlashPoint LT pour une nouvelle carte BT-948 Multi-Maî-
tres  PCI Ultra SCSI. La BT-948  est  la successeur  Ultra SCSI de  la BT-946C, et
possède  toutes les  fonctionnalités des contrôleurs BT-946C et  FlashPoint  LT, y
compris une terminaison adaptative (smart termination) et une PROM  flashable pour
faciliter les mises à jour du firmware. Elle est bien sûr compatible avec le pilote
actuel de Linux. Le prix pour cette mise à jour a été fixé à 45 dollars américains,
et  le programme de mise à jour est  réalisé par le Support Technique de BusLogic,
qui peut être contacté par courrier électronique à l'adresse techsup@BusLogic.com,
par téléphone au +1 408 654-0760 ou par fax au +1 408 492-1542.

J'ai un site en bêta test pour le contrôleur BT-948 et les versions 1.2.1  et 1.3.1
de mon pilote BusLogic contiennent déjà le support pour les BT-948. Une gestion sup-
plémentaire (non indispensable) pour les cartes Multi-Maîtres Ultra SCSI sera ajou-
tée dans une future version. En résultat de ce mécanisme de test 'coopératif', plu-
sieurs  problèmes du firmware  ont été décelés et  corrigés (assurez-vous que vous
avez  la version 5.05R ou plus). Mon système de test Linux très chargé a fourni un
environnement de test idéal pour tester le mécanisme de détection et de correction
d'erreurs  SCSI, qui  est bien moins  souvent mis en évidence sur les  machines de
production,  mais qui est crucial pour la  stabilité générale du système. Il a été
très pratique de pouvoir travailler directement avec leur ingénieur responsable du
firmware en reproduisant les problèmes sous le contrôle de l'environnement de debug
du firmware. Il est certain que les  techniques ont  énormément évolué  depuis  le
temps où je  travaillais sur un  firmware pour du  matériel embarqué. Je travaille
actuellement sur des  mesures de performances  et j'espère avoir prochainement des
chiffres et des statistiques.

BusLogic  m'a demandé d'envoyer cette  annonce puisqu'un important pourcentage des
questions  relatives au  support de la  FlashPoint m'a  directement été envoyé par
email ou a été posté dans les groupes de news de Linux auxquels je participe. Pour
résumer, BusLogic offre aux  utilisateurs Linux de mettre à jour leur carte Flash-
Point LT (BT-930) non gérée par une carte gérée BT-948 pour une somme de 45 dollars
américains.

Contactez le support technique de BusLogic à l'adresse techsup@BusLogic.com ou au
+1 408 654-0760 pour bénéficier de leur offre.

                Leonard N. Zubkoff
                lnz@dandelion.com
<fin de citation>

5.10 EATA: DPT SmartCache, SmartCache Plus, SmartCache III, SmartCache IV et SmartRAID (standard)

Cartes gérées : toutes, du moment qu'elles supportent le protocole EATA-DMA.

Parmi ces cartes, on trouve :

La famille des DPT Smartcache (Plus) :
PM2011      ISA     Fast Terminaison unique SCSI-2
PM2012B     EISA    Fast Terminaison unique SCSI-2

La famille des DPT Smartcache III :
PM2021      ISA     Fast Terminaison unique SCSI-2
PM2021W     ISA     Wide Terminaison unique SCSI-2
PM2022      EISA    Fast Terminaison unique SCSI-2
PM2022W     EISA    Wide Terminaison unique SCSI-2
PM2024      PCI     Fast Terminaison unique SCSI-2
PM2024W     PCI     Wide Terminaison unique SCSI-2
PM2122      EISA    Fast Terminaison unique SCSI-2
PM2122W     EISA    Wide Terminaison unique SCSI-2
PM2124      PCI     Fast Terminaison unique SCSI-2
PM2124W     PCI     Wide Terminaison unique SCSI-2
PM2322      EISA    Fast Terminaison unique SCSI-2
PM2322W     EISA    Wide Terminaison unique SCSI-2

La famille des DPT Smartcache VI :
PM2041W     ISA     Wide Terminaison unique SCSI-2
PM2041UW    ISA     Ultra Wide Terminaison unique SCSI-2
PM2042W     EISA    Wide Terminaison unique SCSI-2
PM2042UW    EISA    Ultra Wide Terminaison unique SCSI-2
PM2044W     PCI     Wide Terminaison unique SCSI-2
PM2044UW    PCI     Ultra Wide Terminaison unique SCSI-2
PM2142W     EISA    Wide Terminaison unique SCSI-2
PM2142UW    EISA    Ultra Wide Terminaison unique SCSI-2
PM2144W     PCI     Wide Terminaison unique SCSI-2
PM2144UW    PCI     Ultra Wide Terminaison unique SCSI-2
PM2322W     EISA    Wide Terminaison unique SCSI-2
PM2322UW    EISA    Ultra Wide Terminaison unique SCSI-2

La famille des DPT SmartRAID :
PM3021      ISA     Fast Terminaison unique SCSI-2
PM3021W     ISA     Wide Terminaison unique SCSI-2
PM3122      EISA    Fast Terminaison unique SCSI-2
PM3122W     EISA    Wide Terminaison unique SCSI-2
PM3222      EISA    Fast Terminaison unique SCSI-2
PM3222W     EISA    Wide Terminaison unique SCSI-2
PM3224      PCI     Fast Terminaison unique SCSI-2
PM3224W     PCI     Wide Terminaison unique SCSI-2
PM3334W     PCI     Wide Terminaison unique SCSI-2
PM3334UW    PCI     Ultra Wide Terminaison unique SCSI-2

mais également les versions 'différentielles' des contrôleurs ci-dessus.

et quelques contrôleurs de :

NEC, AT&T, SNI, AST, Olivetti, Alphatronix.

Configurations supportées :

Emplacements   : Tous
Ports          : Tous
IRQs           : Tous les niveaux sur changements d'état (edge triggered)
Canaux DMA     : Tous les ISA, non significatifs pour les EISA/PCI
E/S            : port mappé, contrôle de bus
Canaux SCSI    : Tous

Auto-détection :

fonctionne avec toutes les configurations gérées

La dernière version du pilote EATA-DMA est disponible à l'adresse :

ftp.i-Connect.Net:/pub/Local/EATA/

Liste de diffusion :

La liste de diffusion EATA constitue un forum pour les utilisateurs Linux des pilotes EATA-DMA et EATA-PIO pour les discussions et les annonces des nouvelles versions et autres annonces. Pour vous abonner à la liste, envoyez un message à "linux-eata-request@i-connect.net" avec la ligne "subscribe" dans le corps du message.

Support du répertoire /proc/scsi :

Pour avoir accès à des statistiques plus poussées, entrez les commandes suivantes :

echo "eata_dma latency" >/proc/scsi/eata_dma/<no_driver>

Pour ensuite désactiver les statistiques, faites :

echo "eata_dma nolatency" >/proc/scsi/eata_dma/<no_driver>

Problèmes habituels :

  1. La Slackware ne trouve pas le contrôleur.

    Solution : utilisez une des disquettes de boot ascsi*.

  2. Le pilote IDE arrive à détecter l'interface ST-506 de la carte EATA dans les anciens noyaux (<v1.3).
    1. Cela ressemble à l'un des 2 exemples suivants :
      hd.c: ST-506 interface disk with more than 16 heads detected,
        probably due to non-standard sector translation.  Giving up.
        (disk %d: cyl=%d, sect=63, head=64)
      
      hdc: probing with STATUS instead of ALTSTATUS
      hdc: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
      hdc: cannot handle disk with 0 physical heads
      hdd: probing with STATUS instead of ALTSTATUS
      hdd: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
      hdd: cannot handle disk with 0 physical heads
      
      Si le pilote IDE a des problèmes à cause de cela (vous ne pouvez pas accéder à vos véritables périphériques IDE par exemple), changez le port d'E/S et/ou les IRQ de la carte EATA.
    2. Si le pilote IDE trouve des équipements qu'il sait traiter, par exemple des disques durs d'une capacité <=504MB, il va allouer le port d'E/S et l'IRQ de manière à ce que le pilote eata ne puisse pas les utiliser. Dans ce cas, changez aussi le port d'E/S et le niveau d'interruption (IRQ != 14, 15).
  3. Le firmware de certaines vieilles cartes SK2011 est défectueux. Contactez le support client de DPT pour une mise à jour.

Remarques :

  1. CONFIG_PCI doit être positionnée si vous utilisez une carte PCI.

5.11 Future Domain 16x0 with TMC-1800, TMC-18C30, TMC-18C50 ou composant TMC-36C70

Configurations supportées :

BIOS           : 2.0, 3.0, 3.2, 3.4, 3.5
Adresses BIOS  : 0xc8000, 0xca000, 0xce000, 0xde000
Ports          : 0x140, 0x150, 0x160, 0x170
IRQs           : 3, 5, 10, 11, 12, 14, 15
DMA            : non utilisé
E/S            : port mappé

Auto-détection :

fonctionne avec toutes les configurations gérées. Requiert un BIOS activé

Surcharge de l'auto-détection :

aucune

Problèmes préhistoriques, réglés par une mise à jour :

  1. Les vieilles versions ne gèrent pas le composant TMC-18C50 et se plantent avec les nouvelles cartes.
  2. Les routines d'auto-détection des vieilles versions n'ont pas les plus récentes signatures des BIOS.
  3. Les versions avant celle incluse dans Linux 1.0.9 et 1.1.6 ne gèrent pas le nouveau composant SCSI ou le BIOS 3.4.

Remarque :

  1. Le BIOS des Future Domain scrute souvent les périphériques SCSI de l'identificateur le plus élevé jusqu'à l'ID 0, dans l'ordre inverse des autres BIOS SCSI. sda va alors correspondre au dernier périphérique (par analogie avec le DOS, D: au lieu de C:). Vous aurez certainement besoin d'utiliser l'option de surcharge 'disktab' avec LILO.

5.12 NCR5380 générique / T130B (standard)

Configurations supportées et non supportées :

Ports          : Tous
IRQs           : Tous
canaux DMA     : le DMA n'est pas utilisé
E/S            : port mappé

Auto-détection :

aucune

Surcharge de l'auto-détection :

A la compilation :

définissez GENERIC_NCR5380_OVERRIDE. Ce doit être un tableau de
nuplets de la forme {'port', 'irq', 'dma', 'type de carte'}. Par exemple :
#define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}}

pour une carte NCR5380 de port 0x330 et d'IRQ 5.

#define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}}

pour une carte T130B sur le port 0x350.

Les vieilles versions du code suppriment l'entrée BOARD_*.

Les valeurs symboliques IRQ_NONE et IRQ_AUTO peuvent être employées pour le
champ IRQ.

Ligne de commande du noyau :

ncr5380=port,irq
ncr5380=port,irq,dma
ncr53c400=port,irq

255 peut être utilisé pour 'pas d'irq' et 254 pour 'auto-détection de l'irq'.

Problèmes fréquents :

  1. Utilisation d'une carte T130B avec le vieux pilote NCR5380 générique (version 6 pré-publique) qui ne gérait pas la ligne de commande pour le ncr53c400.

    Les registres des cartes compatibles NCR5380 ont un déplacement de 8 par rapport à l'adresse de base. Ainsi, si votre adresse est 0x350, utilisez :

    ncr5380=0x358,254
    

    sur la ligne de commande du noyau.

Problèmes préhistoriques, réglés par une mise à jour :

  1. Le noyau se bloque lors d'accès disques avec une carte T130B ou d'autres cartes NCR53c400.

    Les versions 6 pré-publiques du pilote générique NCR5380 ne géraient pas les interruptions sur ces cartes. Mettez à jour votre pilote.

Remarques :

  1. Le pilote générique ne gère pas le DMA actuellement et le pseudo-DMA n'est pas mieux supporté par le pilote générique.

5.13 NCR53c8xx (standard)

Configurations supportées et non supportées :

Adresses de base : Toutes
IRQs             : Toutes
Canaux DMA       : non significatif (PCI)
E/S              : port mappé, contrôle de bus

Auto-détection :

requiert un BIOS PCI, utilise les routines du BIOS PCI pour rechercher les
contrôleurs et pour lire les données de configuration

Le pilote utilise les valeurs pré-programmées dans certains regsitres pour son initialisation, aussi un BIOS doit-il être activé.

Problèmes préhistoriques, réglés par une mise à jour :

  1. D'anciennes versions de Linux avaient un problème avec la pagination (swapping). Reportez-vous au chapitre Le système se fige en swappant
  2. Les noyaux des distributions incluent la version 4 ou 5 du pilote, qui ne gère pas certaines fonctionnalités bien utiles comme la déconnexion / reconnexion (l'effet le plus manifeste en est le blocage complet des périphériques SCSI lors du rembobinage d'une bande), contrôleurs multiples et opérations sans BIOS.

    La dernière version du pilote est disponible à l'adresse :

    ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/ncr53c810
    

    La versions courante est pour la 1.2.10 (et les derniers patches), bien que la prochaine version soit destinée exclusivement aux noyaux 1.3.x. Ces patches ne sont pas totalement propres, à cause de patches pour le format ELF (et d'autres) qui se trouvaient dans mon arborescence de travail. Si vous ne pouvez pas corriger vous-mêmes les (quatre) problèmes d'application des patches, ne les utilisez surtout pas. Seul le dernier patch est nécessaire ; ce ne sont pas des versions incrémentales.

    Si vous ne pouvez pas attendre et désirez utiliser le dernier pilote NCR avec un noyau 1.3.x, Harald Evensen <Harald.Evensen@pvv.unit.no> a adapté les patches pour les noyaux 1.3.x

    ftp://ftp.pvv.unit.no/pub/Linux/ALPHA/ncr
    

    Ces patches devraient s'appliquer sans problèmes.

    S'il vous plaît, lisez tous les fichiers README dans ces répertoires. Vous devriez également rejoindre la liste de diffusion NCR si vous êtes intéressé à avoir les dernières versions du pilote. Les corrections de bugs intermédiaires et les annonces sont faites sur cette liste.

    Pour vous inscrire, envoyez un courrier à majordomo@colorado.edu avec

    subscribe ncr53c810
    

    dans le corps du message. Pour vous retirer de la liste, envoyez à la même adresse un message contenant

    unsubscribe ncr53c810
    

Problèmes fréquents :

  1. De nombreuses personnes ont rencontré des problèmes de composants fonctionnant bien sous DOS mais plantant sous Linux avec un problème de temporisation (timeout) lors du test 1 (interruption perdue).

    Cela est souvent dû à un désaccord entre la valeur sélectionnée par le cavalier réglant le niveau d'interruption (IRQ) pour un emplacement ou un périphérique de la carte mère et la valeur fixée dans la CMOS. VERIFIEZ TOUJOURS QUE :

    Cela peut également être dû aux INTB, INTC ou INTD PCI sélectionnées sur une carte PCI dans un système qui ne gère que l'INTA PCI. Si vous utilisez une carte NCR qui vous permet de choisir par cavalier la ligne d'interruption PCI utilisée, assurez-vous que vous avez configuré l'INTA.

    Enfin, le PCI doit utiliser des interruptions sur niveau (level-sensitive) plutôt que sur front (edge triggered). Vérifiez que votre carte est positionnée pour générer des interruptions sur niveau. Si cela ne marche toujours pas, essayez les interruptions sur front, au cas où votre système serait défectueux.

    Ce problème est assez fréquent avec quelques cartes Viglen, pour lesquelles la configuration des cavaliers d'interruptions n'est pas documentée dans le manuel. On m'a dit que ce qui devrait être une IRQ5 est en fait une IRQ9. Votre cas sera peut-être différent.

  2. Des blocages et d'autres problèmes apparaissent lors de l'utilisation d'une carte vidéo PCI S3 928 et Tseng Lab ET4000W32. Il y a des bugs matériels dans certaines versions de ces composants. Ne les utilisez pas.
  3. Un message au démarrage vous indique que l'organisation (mapping) des E/S a été désactivée parce que les bits 0..1 de l'adresse de base 0 indiquaient un mapping non E/S. Le message exact est :
    the I/O mapping was disabled because base address 0 bits 0..1 indicated a
    non I/O mapping
    
    Cela est dû à un bug du BIOS sur certaines machines : la lecture double mots de registres de configuration retourne les mots de 16 bits de poids forts et de poids faibles inversés.
  4. Certaines machines ont des problèmes si l'écriture différée PCI ou la bufferisation CPU->PCI sont activées. Si vous avez des problèmes, désactivez ces options.
  5. Certains systèmes avec le firmware NCR SDMS dans la ROM du BIOS de la carte et dans le BIOS du système ne sont pas capables de booter sous DOS. Désactiver l'image dans un des BIOS devrait résoudre le problème.
  6. Si vous rencontrez le message
    "scsi%d: IRQ0 not free, detaching"
    
    ou
    "scsi%d: IRQ255 not free, detaching"
    
    le composant NCR avait tous ses bits à 0 ou à 1 dans le registre de configuration PCI. Soit vous avez des problèmes de configuration (reportez-vous au chapitre Problèmes fréquents 1), soit le BIOS de votre carte mère est défectueux. Un contournement serait d'éditer le fichier drivers/scsi/ncr53c7,8xx.c puis de changer pci_init() pour mettre :
    irq = my_irq;
    
    avant
    return normal_init (tpnt, board, chip, (int) base,
        (int) io_port, (int) irq, DMA_NONE, 1, bus, device_fn,
        options);
    
  7. Certains systèmes ont des composants BIOS honteusement buggés. Ne faites pas de rapport d'anomalie avant d'être certain que vous avez reçu les plus récentes ROM de votre vendeur.
  8. Les lignes de commande ncr53c810=xxx, etc. ne marchent pas. Dans les noyaux d'origine, les points d'entrée correspondants ne sont intentionnellement pas inclus dans le fichier init/main.c : Le pilote fait malgré tout des auto-détections pour une carte dont des paramètres ont été passés sur la ligne de commande. Ainsi, si une ligne de commande est utilisée alors que la carte a été reconnue par la routine de configuration PCI, vous allez au devant de gros problèmes. La seule raison pour laquelle vous pourriez avoir besoin d'une surcharge par la ligne de commande serait de contourner un bug du matériel PCI et du BIOS. Dans ce cas, certaines routines de correction d'erreurs ne marcheront pas, rendant la surcharge plus qu'inutile. Enfin, pratiquement toutes les personnes qui _pensent_ avoir besoin d'une surcharge sur la ligne de commande le font parce qu'elles ont eu un message de la part du pilote. Si le pilote vous signale que vous avez une problème de configuration, votre système est défectueux ou alors vous avez un problème de configuration et aucune ligne de commande ne pourra y remédier. Si quelqu'un a ajouté les points d'entrée adéquats dans le fichier init/main.c pour les lignes de commande, elle ne sont pas gérées et peuvent parfaitement ne pas fonctionner.
  9. Certaines cartes NCR (Nexstor est la plus connue) qui n'utilisent pas un BIOS NCR sortent en timeouts. Certaines de ces ROMs gèrent les transferts synchrones et asynchrones, mais établissent une négociation de transferts synchrones au démarrage du système, ce qui laisse les disques dans un état non défini. Lorsque le pilote NCR Linux issu de la distribution essaie de dialoguer avec ces périphériques, il expire en timeout et ne s'en sort pas car il ne fait ni reset du bus, ni renégociation. Si vous rencontrez ce problème, vous pouvez désactiver les transferts synchrones dans le programme de configuration de la carte ou mettre à jour votre pilote NCR avec une version récente ALPHA qui sait traiter la négociation synchrone.
  10. Les cartes Tyan S1365 '825 ont des problèmes de temporisation (timeouts), tout particulièrement lorsque les déconnexions sont autorisées. Les documentations de certaines de ces cartes inversent les positions du cavalier d'activation de la terminaison - si bien que celle-ci est activée alors que vous auriez voulu la désactiver, et inversement. Essayez de changer la position du cavalier.

Remarques :

  1. CONFIG_PCI doit être positionnée

5.14 Seagate ST0x/Future Domain TMC-8xx/TMC-9xx (standard)

Configurations supportées et non supportées :

Adresses de base : 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000
IRQs             : 3, 5
Canaux DMA       : le DMA n'est pas utilisé
E/S              : mappées en mémoire

Auto-détection :

teste uniquement les adresses, le niveau d'interruption (IRQ) étant supposé
valoir 5 ; nécessite un BIOS installé.

Surcharge de l'auto-détection :

A la compilation :

Définir OVERRIDE à la valeur de l'adresse de base, CONTROLLER à FD ou SEAGATE
en fonction de la configuration et IRQ à la valeur de niveau d'interruption
de la carte.

Ligne de commande du noyau :

st0x=adresse,irq ou tmc8xx=adresse,irq (uniquement pour les noyau 0.99.13b et
plus récents)

Problèmes préhistoriques, réglés par une mise à jour :

  1. Les versions des noyaux 0.99.12 et antérieurs avaient un problème d'acquittement (handshaking) avec certains périphériques lents. Notamment, voici ce qui se passait lorsque vous écriviez des données sur le bus :
    1. écrire l'octet dans le registre de donnée ; le registre de données est placé sur le bus,
    2. temps_restant = 12us,
    3. attendre tant que temps_restant > 0 et que le signal REQ n'est pas généré,
    4. si temps_restant > 0, générer le signal ACQ,
    5. attendre tant que temps_restant > 0 et le signal REQ est généré,
    6. redescendre le signal ACQ
    Ce problème apparaissait sur certains périphériques lents qui traitaient chaque commande après l'avoir lue et pour lesquels le protocole REQ/ACQ (requête / acquittement) prenait plus de 12us - REQ n'était pas faux au moment où le pilote l'attendait, si bien que le pilote finissait pas envoyer plusieurs octets de données à chaque impulsion REQ.
  2. Avec Linux 0.99.12, j'ai introduit un bug en corrigeant le code d'arbitrage. Sur certains systèmes, la sélection des périphériques sortait en échec. Ce problème a été corrigé en 0.99.13.

Problèmes fréquents :

  1. Certains commandes sortent en timeouts lorsque Linux essaie de lire une table de partition ou de faire d'autres accès disques.

    La carte est fournie avec une configuration prévue par défaut pour MSDOS, c'est-à-dire que les interruptions sont désactivées. Pour les réactiver sur les cartes Seagate, fermez les pattes F-G (choix de l'IRQ 5) sur le cavalier W3 (ST01) ou JP3 (ST02).

  2. Le pilote ne parvient pas à gérer certains périphériques, en particulier des dérouleurs de bandes SCSI bon marché et des lecteurs de CDROM. La Seagate reporte le protocole REQ/ACQ du bus SCSI dans les signaux IO CHANNEL READY et, éventuellement, OWS du bus du PC. Malheureusement, vous n'êtes pas averti de l'expiration du timer de surveillance (watchdog timer) et vous n'avez aucun moyen de savoir avec certitude que le signal REQ est descendu ; vous risquez finalement de voir passer une seule impulsion REQ comme plusieurs impulsions REQ.

    Etre capable de traiter ce cas implique de mettre en oeuvre une boucle active pour surveiller la descente du signal REQ, avec un délai de surveillance au cas où vous auriez manqué la transition à cause d'une interruption, etc. Vous observerez une dégradation des performances ; il pourrait être judicieux de ne pas appliquer cette méthode à tous les périphériques SCSI. La sélection peut se faire périphérique par périphérique via le champ "broken" des entrées du tableau scsi_devices. Si vous avez des problèmes, vous pourrez tenter d'ajouter votre périphérique à la liste des équipements pour lesquels le champ "broken" n'est pas positionné à 0 (actuellement, il n'y a que les lecteurs de CDROM TENEX).

  3. Une carte Future Domain (en particulier les 840, 841, 880 et 881) ne marche pas.

    Quelques-unes des cartes Future Domain utilisent l'organisation (mapping) des registres des Seagate ; les bits MSG et CD du registre d'état sont inversés.

    Editez le fichier seagate.h, échangez les définitions de STAT_MSG et STAT_CD puis recompilez le noyau avec la variable CONTROLLER définie à SEAGATE et les variables IRQ et OVERRIDE correctement positionnées.

  4. Lors d'une tentative de partionnement de votre disque (par fdisk), vous avez un message indiquant que les ioctl HDIO_REQ ou HDIO_GETGEO ont échoué, ou encore
    You must set heads sectors and cylinders.
    You can do this from the extra functions menu.
    
    Reportez-vous à la section Partitionnement des disques
  5. Après avoir spécifié manuellement la géométrie du disque, les essais de lecture de la table des partitions provoquent les messages d'erreurs "partition boundary not on a cylinder boundary", "physical and logical boundaries don't match", etc. Reportez-vous à la section Partitionnement des disques
  6. Sur certains système qui fonctionnaient avant la version 0.99.13, les nouvelles versions de Linux échouent. Les anciennes versions affectaient les registres CONTROL et DATA dans un ordre différent de celui expliqué dans la documentation Seagate, ce qui perturbait certains systèmes. Les nouvelles versions se conforment au document, mais cela perturbe maintenant d'autres systèmes.

Le code du fichier seagate.c ressemble maintenant à :

cli();
DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL |
            (reselect ? CMD_ATTN : 0);
sti();

Votre problème peut être corrigé en changeant ce code en :

cli();
CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL |
            (reselect ? CMD_ATTN : 0);
DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
sti();

Constantes :

FAST ou FAST32 pour la mise en oeuvre de transferts aveugles

ARBITRATE      va forcer le contrôleur à arbitrer le bus en mode de
               compatibilité SCSI-II, plutôt que d'attendre le signal BUS FREE
               avant de continuer. Cela devrait nous permettre de traiter une
               commande par unité logique le jour où j'intégrerai mes
               modifications de réorganisation dans les sources de
               l'arborescence de référence.

SLOW_HANDSHAKE autorise la compatibilité avec des périphériques déficients,
               qui n'acquittent pas suffisamment rapidement (par exemple
               certains lecteurs de CDROM) pour le code des cartes Seagate.

SLOW_RATE=x,   x étant un entier spécifiant un taux de transfert par défaut
               si le protocole d'acquittement (handshaking) ne fonctionne
               pas correctement.

5.15 PAS16 SCSI (standard)

Configurations supportées et non supportées :

Ports          : 0x388, 0x384, 0x38x, 0x288
IRQs           : 10, 12, 14, 15
     IMPORTANT : les IRQ DOIVENT être différentes des IRQ utilisées par la
                 partie de gestion du son de la carte
DMA            : n'est pas utilisé par la partie SCSI de la carte
E/S            : port mappé

Auto-détection :

n'a pas besoin du BIOS

Surcharge de l'auto-détection :

A la compilation : définissez PAS16_OVERRIDE comme un tableau de nuplets
de la forme {'port', 'irq'}. Par exemple :

#define PAS16_OVERRIDE {{0x388, 10}}

pour une carte de port 0x388, IRQ 10.

Ligne de commande du noyau :

pas16=port,irq

Constantes :

AUTOSENSE  - si elle est définie, la commande SCSI 'REQUEST SENSE' sera
             automatiquement émise pour les commandes qui se terminent
             avec un status 'CHECK CONDITION'.

PSEUDO_DMA - autorise le PSEUDO-DMA matériel ; devrait résulter en un
             gain de performance de l'ordre de x3 / x4 par rapport aux
             E/S scrutées (polled I/O).

PARITY     - activation du contrôle de parité. N'est pas géré.

SCSI2      - activation de la gestion de 'files marquées' pour le SCSI-II
             (SCSI-II tagged queuing). Non testé.

UNSAFE     - autorise les interruptions pendant les transferts
             pseudo-DMA. Vous activerez cela uniquement si vous avez
             des problèmes de perte de caractères durant les
             communications à haute vitesse. Cependant, même dans ce cas,
             vous auriez plutôt intérêt à jouer avec les tailles de blocs de
             transfert.

USLEEP     - autorise la gestion des périphériques qui ne se déconnectent
             pas. Non testé.

Problèmes fréquents :

  1. Commandes en timeouts, interruptions, etc.

    Utilisez les patches pour les NCR5380 que j'ai postés sur le réseau il y a quelque temps (ils devraient être intégrés dans la prochaine version alpha). Ces patches corrigent un séquencement critique (race condition) des précédentes versions du pilote NCR5380. Ils corrigent également un problème de gestion de plusieurs périphériques pour les contrôleurs basés sur le NCR5380.

    Si cela échoue, vous devrez interdire l'option PSEUDO_DMA en changeant la ligne #define PSEUDO_DMA du fichier drivers/scsi/pas16.c en #undef PSEUDO_DMA.

    Remarquez que cette solution doit être considérée uniquement en dernier recours, car elle pénalise gravement les performances.

5.16 Trantor T128/T128F/T228 (standard)

Configurations supportées et non supportées :

Adresses de base :  0xcc000, 00xc8000, 0xdc000, 0xd8000
IRQs             : aucune, 3, 5, 7 (toutes cartes)
                   10, 12, 14, 15 (T128F uniquement)
DMA              : non utilisé
E/S              : mémoire mappée

Auto-détection :

fonctionne sur toutes les configurations supportées ; nécessite un BIOS
installé.

Surcharge de l'auto-détection :

A la compilation : la variable T128_OVERRIDE doit être un tableau
de nuplets de la forme {'adresse', 'irq'}. Par exemple :

#define T128_OVERRIDE {{0xcc000, 5}}

pour une carte à l'adresse 0xcc000, IRQ 5.

Les valeurs symboliques IRQ_NONE et IRQ_AUTO peuvent être employées pour le
champ IRQ.

Ligne de commande du noyau :

t128=adresse,irq
-1 peut être utilisé pour "pas d'irq", -2 pour "auto-détection de l'irq".

Constantes :

AUTOSENSE  - si elle est définie, la commande SCSI 'REQUEST SENSE' sera
             automatiquement émise pour les commandes qui se terminent
             avec un status 'CHECK CONDITION'.

PSEUDO_DMA - autorise le PSEUDO-DMA matériel ; devrait résulter en un
             gain de performance de l'ordre de x3 / x4 par rapport aux
             E/S scrutées (polled I/O).

PARITY     - activation du contrôle de parité. N'est pas géré.

SCSI2      - activation de la gestion de 'files marquées' pour le SCSI-II
             
UNSAFE     - autorise les interruptions pendant les transferts
             pseudo-DMA. Vous activerez cela uniquement si vous avez
             des problèmes de perte de caractères durant les
             communications à haute vitesse. Cependant, même dans ce cas,
             vous auriez tout intérêt à jouer avec les tailles de blocs de
             transfert.

USLEEP     - autorise la gestion des périphériques qui ne se déconnectent
             pas. Non testé.

Problèmes fréquents :

  1. Commandes en timeouts, interruptions, etc.

    Utilisez les patches pour les NCR5380 que j'ai postés sur le réseau il y quelque temps (ils devraient être intégrés dans la prochaine version alpha). Ces patches corrigent un séquencement critique (race condition) des précédentes versions du pilote NCR5380. Ils corrigent également un problème de gestion de plusieurs périphériques pour les contrôleurs basés sur le NCR5380.

    Si cela échoue, vous devrez interdire l'option PSEUDO_DMA en changeant la ligne #define PSEUDO_DMA du fichier drivers/scsi/pas16.c en #undef PSEUDO_DMA.

    Remarquez que cette solution doit être considérée uniquement en dernier recours, car elle pénalise gravement les performances.

5.17 Ultrastor 14f (ISA), 24f (EISA), 34f (VLB) (standard)

Configurations supportées :

Ports          : 0x130, 0x140, 0x210, 0x230, 0x240, 0x310, 0x330, 0x340
IRQs           : 10, 11, 14, 15
Canaux DMA     : 5, 6, 7
E/S            : port mappé, contrôle de bus

Auto-détection :

ne marche pas pour les cartes sur le port 0x310. Le BIOS n'est pas nécessaire.

Surcharge de l'auto-détection :

uniquement à la compilation (définissez PORT_OVERRIDE)

Problèmes fréquents :

  1. L'adresse 0x310 n'est pas reconnue par le code d'auto-détection et peut créer des conflits si le réseau est activé. Utilisez une adresse différente.
  2. L'utilisation d'une carte Ultrastor à l'adresse 0x330 peut provoquer des blocages du système lorsque les pilotes sons sont en phase d'auto-détection. Utilisez une adresse différente.
  3. D'autres pilotes effectuent des auto-détections dangereuses à diverses adresses. Si vous avez des problèmes de détection ou si le système se bloque au démarrage, essayez une autre adresse. 0x340 est réputée être une adresse qui marche.
  4. Linux ne détecte aucun périphérique SCSI, mais reconnaît votre disque dur connecté à une carte SCSI Ultrastor comme un disque normal, sans que le pilote de disque arrive à le gérer. Notez que lorsque cela se produit, vous avez probablement le message
    hd.c: ST-506 interface disk with more than 16 heads detected,
    probably due to non-standard sector translation.  Giving up.
    (disk %d: cyl=%d, sect=63, head=64)
    
    Si c'est le cas, vous utilisez la carte Ultrastor en mode émulation WD1003. Vous devez alors :
    1. basculer la carte Ultrastor en mode natif. C'est ce qu'il y a de mieux à faire, étant donné que les disques SCSI sont sensiblement plus rapides que les disques IDE, spécialement avec les patches de lectures/écritures groupées. Certains ont obtenu des débits soutenus de plus de 2Mo/s à travers le système de gestion de fichiers, après application de ces patches. Notez que cela ne sera pas nécessaire si vous n'utilisez pas de disque dur ou si vous branchez plus de deux disques durs sur la carte Ultrastor.
    2. utilisez la ligne de commande du noyau
      hd=cylindres,têtes,secteurs
      
      pour surcharger les paramètres de configuration par défaut, de manière à pouvoir démarrer vous-même, tout en vous assurant que le nombre de cylindres <= 2048, le nombre de têtes <= 16 et le nombre de secteurs <= 255 soient tels que cylindres * têtes * secteurs soit le même dans les deux représentations. Vous devez également préciser la géométrie du disque au moment d'utiliser fdisk sous Linux. Si vous omettez de le faire, de mauvaises valeurs risqueraient d'être écrites dans la table des partitions. Ces valeurs seront correctes pour Linux, mais provoqueront des erreurs sous MSDOS, qui se base sur les triplets <tête/cylindre/secteur> de la table des partitions. Une fois que Linux a démarré, vous pouvez vous épargner la peine de préciser manuellement à chaque démarrage la géométrie en modifiant comme il le faut la macro HD_TYPE du fichier include/linux/config.h et en recompilant le noyau.

5.18 Western Digital 7000 (standard)

Configurations supportées :

Adresses du BIOS : 0xce000
Ports            : 0x350
IRQs             : 15
Canaux DMA       : 6
E/S              : port mappé, contrôle de bus

Auto-détection :

nécessite un BIOS activé.

Problèmes fréquents :

  1. Il existe plusieurs versions du composant et du firmware. La version 3 de la carte est connue pour ne pas fonctionner, alors que les cartes de version 5 marchent. De même, les composants sans suffixe ne fonctionnent pas, alors que ceux marqués d'un 'A' marchent.
  2. La carte gère quelques adresses BIOS qui n'apparaissent pas dans la liste des adresses supportées. Si vous vous trouvez dans cette situation, utilisez une des adresses supportées et envoyez un rapport d'anomalie suivant la procédure décrite dans le chapitre Signaler une anomalie.

5.19 AM53/79C974 (ALPHA)

ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/AM53C974-0.3.tar.gz

Configurations supportées :

Ports          : Tous
IRQs           : Tous
Canaux DMA     : 6
E/S            : port mappé, contrôle de bus (sans intelligence)

5.20 qlogic (standard)

Hé, Drew, où est ce chapitre (I (D.F.). Je ne l'ai vu que dans la table des matières ;-) ?

6. Disques

Les informations contenues dans ce chapitre concernent les disques.

6.1 Matériel supporté et non supporté

Tous les périphériques SCSI à accès direct, d'une taille de bloc de 256, 512 ou 1024 octets devraient fonctionner. Les autres tailles de bloc ne marchent pas (notez que cela peut souvent être corrigé en modifiant la taille des blocs et/ou des secteurs en utilisant la commande SCSI MODE SELECT).

La taille des secteurs fait référence au nombre d'octets de données présents par secteur sur un périphérique (les lecteurs de CDROM utilisent par exemple une taille de secteur de 2048 octets).

La taille des blocs fait référence à la taille des blocs logiques utilisés pour s'interfacer avec le périphérique. Bien que cette valeur soit habituellement identique à la taille des secteurs, certains périphériques regroupent plusieurs secteurs physiques plus petits (par exemple 256 octets dans le cas des périphériques Syquest de 55 Mo) en un seul bloc logique plus important ou l'inverse (des blocs de 512 octets sur les lecteurs de CDROM compatibles SUN, par exemple).

Les périphériques amovibles incluent les disques Bernouilis, les disques flopticals, les disques magnéto-optiques et les Syquest.

En théorie, les périphériques d'une taille inférieure à 1 To (téra-octets) devraient marcher. Il n'y a en particulier aucun problème avec les minuscules disques de 9 Go.

6.2 Problèmes fréquents

Message 'Cylindre supérieur à 1024'

Au moment du partitionnement, un message d'avertissement "cylinder > 1024" s'affiche ou bien vous êtes incapable de démarrer depuis une partition possédant des cylindres au-delà du cylindre 1024.

C'est une limitation du BIOS.

Reportez-vous aux chapitres Géométrie et Partitionnement pour des explications plus détaillées.

Vous êtes incapable de partitionner "/dev/hd*"

Les /dev/hd* font référence à des périphériques IDE. Utilisez /dev/sd* pour vos disques SCSI.

Reportez-vous aux chapitres Fichiers spéciaux, Géométrie et Partitionnement pour les noms de fichiers corrects et la marche à suivre pour le partionnement.

Impossibilité d'éjecter le média d'un périphérique amovible

Linux tente de verrouiller la porte du lecteur lorsqu'un média est monté, afin d'éviter les endommagements du système de fichiers résultants d'un changement de support.

Démontez vos disques amovibles avant de les éjecter.

Impossibilité de démarrer depuis un disque SCSI en utilisant LILO

Dans certaines conditions, le pilote SCSI et le BIOS ne sont pas d'accord sur le mapping du BIOS correct à utiliser. Le résultat est que LILO se bloque après avoir affiché les lettres 'LI' au moment du boot.

Comme contournement, trouvez quelle géométrie est utilisée sous DOS puis créez une entrée pour votre disque dans le fichier /etc/lilo/disktab.

Vous pouvez éventuellement également utiliser l'option "linear" pour LILO.

Fdisk répond par

You must set heads sectors and cylinders.
You can do this from the extra functions menu.

et la géométrie du disque n'est pas mémorisée lorsque fdisk est réexécuté.

Reportez-vous au chapitre Partitionnement.

Un seul périphérique est détecté sur une carte pont (bridge board) avec plusieurs périphériques

Linux ne recherche pas les unités logiques (LUNs) supérieures à 0 sur les périphériques SCSI qui retournent une version ANSI SCSI 1. Si vous voulez que toutes les unités logiques soient reconnues, allez modifier la fonction scan_scsis() du fichier drivers/scsi/scsi.c.

Le système se fige en swappant

La version 1.1.38 devrait avoir corrigé le problème. Essayez de faire une mise à jour de votre pilote.

Les disques Conner CFP1060S sont endommagés

Cela est dû à un erreur du microcode dans les fonctions de lecture anticipée et dans le cache.

>D'après Soenke Behrens, du support technique de Conner :

Ces dernières semaines, nous avons reçu des appels de plusieurs clients
qui nous affirmaient avoir de sérieux problèmes avec les disques SCSI
Conner CFP1060x de 1Go en utilisant le système d'exploitation Linux.
Des erreurs étaient détectées par e2fsck à chaque démarrage du système
(inodes abîmés) entre autres.

Une correction est maintenant disponible pour les clients possédant
des CFP1060x (versions de microcode 9WA1.62/1.66/1.68) sous Linux. Pour
appliquer la mise à jour, vous aurez besoin d'une disquette bootable DOS,
et des pilotes ASPI qui permettent l'accès au disque dur. La mise à jour
télécharge un nouveau code de gestion de files (mise en file et lecture)
dans la mémoire SCSI non-volatile du disque.

Si vous avez des problèmes avec des disques dont le microcode est à la
version 9WA1.60, contactez votre centre Conner le plus proche pour une
mise à jour. La version du microcode peut être trouvée sur l'étiquette
du disque ou, sur sa face inférieure, sur l'étiquette d'un des circuits
intégrés.

Si vous vous sentez assez sûr de vous pour faire vous-même la mise à jour,
appelez le support technique de Conner, après avoir noté la version de
votre microcode. Le support technique de Conner en Europe peut être joint
 au +44-1294-315333. Le support américain peut être joint au 1-800-4CONNER.

Salutations,
Soenke Behrens
Support Technique Europe

6.3 Fichiers spéciaux

Les disques SCSI utilisent le majeur bloc 8. Il n'y a pas d'accès en mode "raw", comme sous BSD.

16 mineurs sont attribués pour chaque disque SCSI, mineur % 16 == 0 représentant le disque entier, 1 <= (mineur % 16) <= 4 les 4 partitions principales et 5 <= (mineur % 16) <= 15 les partitions étendues.

Exemple de configuration avec un seul contrôleur :

Périphérique                 Adresse  Unité logique     disque SCSI
Seagate 84M                  0        0                 /dev/sda
Disque 0 SCSI->SMD bridge    3        0                 /dev/sdb
Disque 1 SCSI->SMD bridge    3        1                 /dev/sdc
Dérouleur de bande Wangtek   4        0                 aucun
Maxtor 213M                  6        0                 /dev/sdd

etc.

La convention de nommage standard est

/dev/sd{lettre} pour le disque entier ((mineur % 16) == 0)

/dev/sd{lettre}{partition} pour les partitions de ce disque (1 <= (mineur % 16) <= 15)

Par exemple :

/dev/sda        périphérique mode bloc de majeur 8 et de mineur 0
/dev/sda1       périphérique mode bloc de majeur 8 et de mineur 1
/dev/sda2       périphérique mode bloc de majeur 8 et de mineur 2
/dev/sdb        périphérique mode bloc de majeur 8 et de mineur 16

etc.

6.4 Partitionnement

Vous pouvez partitionner vos disques SCSI en utilisant l'outil de votre choix, sous DOS, OS/2, Linux ou n'importe quel autre système d'exploitation supportant le schéma de partionnement standard.

Le meilleur moyen d'utiliser le programme fdisk de Linux est de spécifier le périphérique sur la ligne de commande. Par exemple, pour partitionner le premier disque SCSI, tapez :

fdisk /dev/sda

Si vous ne précisez pas explicitement le périphérique, le programme de partionnement pourrait prendre par défaut /dev/hda, qui n'est pas un disque SCSI.

Il peut arriver que fdisk affiche

You must set heads sectors and cylinders.
You can do this from the extra functions menu.

Command (m for help):

ou qu'il sorte un message comme quoi "HDIO_REQ ou HDIO_GETGEO ioctl" a échoué. Dans ce cas, spécifiez manuellement la géométrie du disque ( Géométrie) au moment de lancer fdisk ou entrez-la dans /etc/disktab si vous avez l'intention de booter sur ce disque en utilisant LILO.

Si vous avez manuellement précisé la géométrie du disque, les utilisations ultérieures de fdisk vous donneront le même message d'erreur. C'est normal, puisque les PC ne stockent pas les informations de géométrie dans la table des partitions. Cela ne cause AUCUN PROBLEME et vous n'aurez pas de soucis à accéder aux partitions créées par Linux. Certains programmes mal écrits peuvent en être gênés ; contactez votre revendeur et insistez pour qu'il corrige son code si cela arrivait.

Un message d'avertissement vous signale parfois que votre partition se termine au-delà du cylindre 1024. Si vous créez une telle partition, vous ne serez pas capable de démarrer dessus avec LILO. Cela étant, rien n'empêche de créer une partition racine (root) partiellement ou entièrement située au-delà de ce cylindre 1024. Il est en effet toujours possible de créer une petite partition /boot sous la barrière des 1024 ou de démarrer le noyau directement depuis une autre partition.

6.5 Géométrie

Sous Linux, chaque disque est vu tel que le contrôleur SCSI le voit : N blocs, numérotés de 0 à N - 1, sans erreurs, là où le DOS / BIOS considèrent avoir affaire à des disques intelligents et appliquent une transformation arbitraire <tête/cylindre/secteur> à cet adressage linéaire.

Cela peut poser un problème lorsque vous partitionnez votre disque sous Linux, puisqu'il n'y a pas de moyen portable de récupérer la géométrie estimée par le DOS/BIOS. Dans la plupart des cas, un ioctl() HDIO_GETGEO peut être implémenté pour obtenir ce mapping. Malheureusement, lorsque le vendeur (au hasard Seagate) choisit un mapping retors, non standard et non documenté, cela n'est plus possible et il est nécessaire de préciser manuellement la géométrie.

Si vous en arrivez là, plusieurs options sont possibles :

  1. Si cela ne vous gêne pas d'utiliser DOS ou de démarrer depuis le disque avec LILO, créez une traduction telle que tête * cylindre * secteur * 512 < taille de votre disque en octets (un mégaoctet est défini par 2^20 octets).
    1 <= tête <= 256
    1 <= cylindre <= 1024
    1 <= secteur <= 63
    
  2. Utilisez le mapping du BIOS. Dans certains cas, cela implique qu'il faudra reconfigurer le disque de manière à ce qu'il soit à l'adresse SCSI 0 et qu'il faudra désactiver le second disque IDE (si vous en avez un).

Sous DOS, vous pouvez utiliser un programme tel que NU (Norton Utilities). Vous pouvez aussi lancer le programme suivant :

begin 664 dparam.com
MBAZ``##_B+^!`+N!`(H'0SP@=/D\,'5:@#]X=`6`/UAU4(!_`3AU2H!_`P!U
M1(I7`H#J,(#Z`7<Y@,*`M`C-$PCD=3-14HC()#\PY.@R`.@J`%J(\/[`,.3H
M)0#H'0!8AL2Q!M+L0.@7`+K"`;0)S2'#NIP!ZR"ZQ0'K&[K5`>L6N]T!,=*Y
M"@#W\8#",$N(%PG`=>^)VK0)S2'#=7-A9V4Z(&1P87)A;2`P>#@P#0H@("!O
L<B`@9'!A<F%M(#!X.#$-"B1);G9A;&ED(&1R:79E#0HD("`D```````D``!O
`
end

Lorsque vous le lancerez, il affichera le nombre de secteurs, de cylindres et de têtes du disque dont l'adresse BIOS a été fournie sur la ligne de commande (0x80 pour le premier disque, 0x81 pour le second disque, etc.).

Par exemple, dparam 0x80

60      17      1007

signifie que C: a 60 secteurs, 17 têtes et 1007 cylindres.

7. Les lecteurs de CDROM

Ce chapitre contient des informations spécifiques aux lecteurs de CDROM.

7.1 Matériel supporté et non supporté

Les lecteurs de CDROM SCSI avec une taille de bloc de 512 ou 2048 octets doivent marcher. D'autres tailles de bloc ne fonctionneront pas.

7.2 Problèmes fréquents

Impossibilité de monter le CDROM

La syntaxe correcte pour monter un CDROM ISO-9660 est la suivante :

mount -t iso9660 /dev/sr0 /point_de_montage -o ro

Il est évident que pour que cela fonctionne, il faut avoir intégré dans le noyau (ou en module) le support SCSI pour votre contrôleur, pour le pilote SCSI et le système de fichiers iso9660.

Notez aussi que dans les noyaux 1.1.32, les périphériques en lecture seule tels que les CDROM ne peuvent pas être montés avec les options par défaut (lecture/écriture (read/write)).

Impossibilité d'éjecter le CDROM

Linux tente de verrouiller la porte du lecteur lorsqu'un média est monté, afin d'éviter les endommagements du système de fichiers résultants d'un changement de support.

Impossibilité d'écouter des CD audio

Essayez donc workman ou xcdplayer.

Workman ou xcdplayer ne marchent pas

Les fonctions de contrôle des fonctionnalités audio font partie de l'ensemble des commandes de la norme SCSI-II. Les lecteurs qui ne sont pas SCSI-II n'ont donc que peu de chances de marcher. De plus, quelques lecteurs de CDROM SCSI-I et SCSI-II utilisent un ensemble de commandes propriétaires au lieu des commandes de la norme SCSI-II. Il existe une version de xcdplayer pour les lecteurs NEC - jetez un oeil sur tsx-11.mit.edu au répertoire /pub/linux/BETA/cdrom.

Ces programmes peuvent également marcher avec quelques lecteurs de CDROM non SCSI, si leurs pilotes implémentent les mêmes ioctls que les pilotes SCSI.

Les disques supplémentaires sur les chargeurs SCSI ne marchent pas

La plupart des chargeurs de CDROM attribuent une unité logique à chaque disque. Vérifiez que vous avez bien un fichier spécial (/dev/...) pour chaque plateau de votre chargeur (reportez-vous aux chapitres Fichiers spéciaux et Les unités logiques autres que la première ne fonctionnent pas.

7.3 Fichiers spéciaux

Les CDROM SCSI utilisent le majeur 11.

Les mineurs sont attribués dynamiquement (reportez-vous aux chapitres Disques, Fichiers spéciaux pour des exemples) le premier CDROM trouvé ayant le mineur 0, le deuxième le mineur 1, etc.

La convention standard de nommage est la suivante :

/dev/sr{chiffre}, bien que certaines distributions aient utilisé /dev/scd{chiffre}. Par exemple :

/dev/sr0        /dev/scd0
/dev/sr1        /dev/scd1

8. Les lecteurs de bandes

Les informations de ce chapitre concernent les lecteurs de bandes.

8.1 Matériel supporté et non supporté

Les périphériques utilisant des tailles de blocs fixes ou variables plus petites que la taille du buffer du pilote SCSI (32Ko dans les sources de la distribution du noyau) sont gérés.

Les paramètres (taille de bloc, bufférisation, densité) sont réglés via des ioctls (habituellement par le programme mt) ; ils restent actifs même si le périphérique est fermé puis réouvert (ici, périphérique est à prendre au sens : fichier spécial représentant ce périphérique).

Théoriquement, tous les lecteurs doivent marcher, y compris :

8.2 Problèmes fréquents

Le lecteur de bande n'est pas reconnu au démarrage

Essayez de démarrer avec une bande dans le lecteur.

Impossibilité de lire correctement des bandes comportant plusieurs fichiers

En lisant des bandes avec plusieurs fichiers, le premier tar est correct, mais le suivant échoue sans remontée d'erreurs. Un second essai de tar réussit.

Les programmes utilisateur, tels que tar, ne savent pas interpréter les marques de fichiers. Le premier tar lit la bande jusqu'à la fin du fichier. Le second tar essaie de lire la marque de fichier (file mark) et n'obtient aucune donnée. Par contre, la bande a dépassé la marque de fichier, si bien que la troisième lecture lit le deuxième fichier de la bande.

Utilisez mt sur le fichier spécial attaquant le lecteur en mode 'non-rembobinage' (no-rewind) pour avancer jusqu'au fichier suivant.

La décompression échoue

Les programmes de décompression ne sont pas capables de gérer les zéros qui comblent le dernier bloc du fichier.

Pour éliminer les avertissements et les erreurs, mettez vos fichiers compressés dans un fichier tar. Plutôt que de faire :

tar cfvz /dev/nst0 fichier.1 fichier.2 ...

faites :

tar cfvz tmp.tar.z fichier.1 fichier.2 ...

tar cf /dev/nst0 tmp.tar.z

Problèmes de lecture de bandes faites sur d'autres systèmes

Vous n'arrivez pas à relire une bande faite sur un autre système d'exploitation ou bien un autre système d'exploitation n'arrive pas à relire les bandes faites sous Linux.

Les différents systèmes utilisent souvent des tailles de blocs différentes. Sur un lecteur de bande utilisant une taille fixe, vous allez avoir des erreurs en essayant de lire des blocs inscrits avec une autre taille.

Pour lire ces bandes, vous devez ajuster la taille des blocs de votre pilote de bandes à la taille avec laquelle la bande a été écrite. Vous pouvez aussi essayer de le configurer pour qu'il utilise une taille variable.

REMARQUE : cette taille est une taille physique de bloc et n'est pas le facteur de blocage utilisé par tar, dump et consors.

Vous pouvez le faire par la commande mt :

mt setblk <taille>

ou

mt setblk 0

pour indiquer au pilote d'utiliser une taille de bloc variable.

Notez que ces options de mt ne sont pas supportées par la version GNU de mt qui est incluse dans certaines distributions de Linux. Utilisez plutôt la version mt dérivée de BSD. Les sources devraient être disponibles à l'adresse

tsx-11.mit.edu:/pub/linux/ALPHA/scsi

ST_BUFFER_BLOCKS (définie dans le fichier /usr/src/linux/drivers/scsi/st_options.h dans les noyaux récents et /usr/src/linux/drivers/scsi/st.c dans les anciens noyaux) est initialisée de manière à autoriser une taille maximale des buffers de 32Ko. Editez le fichier précédent pour augmenter cette limite.

Message d'erreur "No such device"

Tous les essais pour accéder à la bande se terminent par un message du genre

"No such device".

Vérifiez le type du fichier spécial représentant votre lecteur. Ce doit être un fichier en mode caractère, les majeur et mineur devant être en concordance avec les valeurs définies dans le chapitre Fichiers spéciaux.

Les lectures de bandes à une certaine densité marchent, mais les écritures échouent

Plusieurs lecteurs de bandes acceptent les lectures à une densité inférieure pour compatibilité avec des matériels plus anciens, mais ils n'écrivent pas à ces mêmes densités.

C'est le cas en particulier des lecteurs QIC, qui peuvent relire des vieilles cassettes de 60Mo, mais qui ne savent plus écrire que des bandes de 120, 150, 250 ou 525Mo.

Le repositionnement de la bande bloque le bus SCSI

Cela est fréquent avec les équipements SCSI qui ne gèrent qu'une commande en attente à la fois (reportez-vous au chapitre Périphériques multiples pour une explication plus détaillée, et Guide de l'acheteur : comparaison des fonctionnalités pour voir quels lecteurs souffrent de cette limitation), bien que cela puisse également être dû à un lecteur de bandes refusant les déconnexions.

Dans tous les cas, vous pouvez contourner ce problème en éditant le fichier drivers/scsi/sr.c et en ajoutant une ligne

#define ST_NOWAIT

au début. Regénérez ensuite le noyau.

Cela va avoir pour effet de retarder les éventuelles erreurs jusqu'à la prochaine commande SCSI exécutée. Il est pour cela préférable de faire

mt status

après qu'une commande de repositionnement a été demandée par mt. Cela vous évitera d'écraser des fichiers sur la bande si le positionnement a échoué.

Vous pouvez aussi envisager de changer votre contrôleur pour un modèle mieux supporté ou de vous équiper d'un lecteur de bande plus récent, si vous avez besoin d'utiliser ce contournement et que vous désiriez écrire plusieurs fichiers sur une même bande.

8.3 Fichiers spéciaux

Les lecteurs de bandes SCSI utilisent le majeur 9.

Linux utilise le type dev_t sur 16 bits, dont 8 bits sont réservés pour le mineur. Pour cette raison, les mineurs pour les bandes SCSI sont affectés dynamiquement et commencent au plus petit numéro d'adapteur SCSI, périphérique ou unité logique.

Les mineurs des fichiers spéciaux rembobinant les bandes commencent à 0, 0 étant le premier lecteur de bande SCSI (/dev/st0 créé par mknod /dev/st0 c 9 0), le deuxième lecteur étant /dev/st1 (mknod /dev/st1 c 9 1), etc.

Les mineurs des fichiers spéciaux ne rembobinant pas les bandes ont le bit de poids fort à 1, c'est-à-dire que /dev/nst0 a été créé par : mknod /dev/nst0 c 9 128.

La convention standard de nommage est

/dev/nst{chiffre} pour les opérations sans rembobinage
/dev/st{chiffre}  pour les opérations avec rembobinage

9. Pilote générique

Les informations contenues dans ce chapitre sont spécifiques au pilote SCSI générique.

9.1 Matériel supporté

Le pilote SCSI générique fournit une interface normalisée permettant d'envoyer des commandes SCSI à tous les périphériques SCSI - disques, bandes, CDROM, chargeurs multi-disques, etc.

Tout équipement électriquement compatible avec votre carte SCSI doit fonctionner.

9.2 Problèmes fréquents

Aucun :-)

9.3 Fichiers spéciaux

Les fichiers spéciaux du pilote SCSI générique utilisent le mode caractère, de majeur 21. A cause des mêmes contraintes que précédemment, les mineurs sont attribués dynamiquement à partir de 0, un par périphérique,

/dev/sg0

correspondant au plus petit périphérique ou unité logique sur le premier contrôleur.

10. Guide de l'acheteur

Une question fréquente est :

"Linux gère un nombre plutôt élevé de contrôleurs différents. Quel contrôleur dois-je acheter ?"

La réponse dépend des performances que vous espérez ou dont vous avez besoin, de la carte mère et des périphériques que vous avez l'intention de connecter à votre machine.

10.1 Types de transfert

Le facteur le plus important affectant les performances (en terme de débit et de temps de réponse lors des E/S SCSI) est le type de transfert utilisé. La table ci-dessous liste les divers types de transfert, les effets de chacun sur les performances et quelques recommandations sur leur emploi.

Type de transfert

Description / Performance / Recommandations

Scrutation pure (Pure Polled)

Une carte d'E/S scrutée conduit le processeur central à faire tout le traitement SCSI, y compris le protocole REQ/ACQ.

Même un processeur rapide va être plus lent à gérer les séquences REQ/ACQ qu'une simple machine à états finis. Le débit peut descendre à 150Ko/s sur une machine rapide et parfois 60Ko/s sur une machine lente (à travers le système de fichiers).

Le pilote doit également se mettre en boucle (tight loop) tant que le bus SCSI est occupé, ce qui conduit à une utilisation de 100% du processeur et à des temps de réponse déplorables lors des E/S SCSI. Les lecteurs de CDROM lents qui ne se déconnectent/reconnectent pas vont complètement écrouler le système avec de telles cartes.

Non recommandées.

Scrutation inter-verrouillée (Interlocked Polled)

Les cartes utilisant des E/S à scrutation inter-verrouillée sont principalement les mêmes que les cartes précédentes, le protocole REQ/ACQ étant effectué conjointement avec les signaux de protocole du bus PC. Tous les traitements SCSI hors protocole REQ/ACQ sont gérés par le processeur.

Avec de telles cartes, des pointes de 500-600Ko/s peuvent être mesurées à travers le système de fichiers.

De même qu'avec les cartes à scrutation pure, le pilote doit se mettre en boucle tant que le bus SCSI est occupé, ce qui rend l'utilisation du processeur dépendante des taux de transfert des périphériques et des déconnexions/reconnexions. L'utilisation du processeur peut varier de 25% pour des lecteurs de CDROM simple vitesse qui gèrent proprement les déconnexions/reconnexions, à 100% pour les périphériques rapides ou les lecteurs de CDROM déficients qui n'arrivent pas à se déconnecter/reconnecter.

Sur mon 486-66, avec une carte T128, j'utilise 90% du processeur pour un débit soutenu de 547Ko/s avec un disque dont le débit maximum est de 1080Ko/s.

Ces cartes sont parfois acceptables pour des périphériques lents (bandes, CDROM) lorsque le prix est le principal critère.

Scrutation par FIFO (FIFO Polled)

Les cartes implémentant une scrutation par FIFO utilisent un tampon de taille réduite (typiquement 8Ko) entre le processeur et le bus SCSI et possèdent quelque intelligence. Le processeur principal n'est plus mis à contribution que lors des transferts de données à pleine vitesse avec la FIFO ou lorsqu'il termine le traitement des interruptions FIFO pour les conditions vides, les déconnexions/reconnexions, etc.

Les taux de transfert maximums devraient être suffisants pour traiter la plupart des périphériques SCSI et peuvent atteindre 4Mo/s sur un Seagate Baracuda rapide avec une Adaptec 1520 en utilisant des commandes SCSI directes de lecture de blocs de 64Ko.

L'utilisation du processeur central dépend des taux de transfert des périphériques, les plus rapides générant le plus d'interruptions et demandant donc plus de temps processeur. Bien que le taux d'utilisation du processeur puisse être important avec des périphériques rapides (jusqu'à 75%), le système reste utilisable. Ces cartes offrent une excellente réponse interactive avec des périphériques défectueux qui ne se déconnectent/reconnectent pas (typiquement, des lecteurs CDROM bon marché).

Recommandées pour un usage personnel, pour un budget raisonnable.

DMA esclave

Les pilotes pour les cartes mettant en oeuvre du DMA esclave programment le contrôleur DMA du PC pour un canal lorsqu'elles font un transfert de données et rendent le contrôle au processeur principal.

Les taux de transfert sont habituellement pénalisés par les mauvaises performances des contrôleurs DMA utilisés sur les PC, une telle carte 8-bits ne pouvant pas dépasser les 140-150Ko/s.

La consommation du processeur est très raisonnable, légèrement moins qu'avec les cartes à scrutation par FIFO. Ces cartes tolèrent parfaitement les périphériques défectueux qui ne se déconnectent/reconnectent pas (typiquement, des lecteurs CDROM bon marché).

Acceptables pour les lecteurs CDROM lents, les lecteurs de bandes, etc.

DMA à contrôle de bus (Busmastering DMA)

Ces cartes sont intelligentes. Les pilotes pour ces contrôleurs envoient dans une structure d'E/S une commande SCSI, l'identificateur de la destination et de son unité logique, ainsi que l'adresse de fin des données, puis ils avertissent la carte qu'ils ont une commande pour elle. Le pilote rend la main au système et la carte répond plus tard pour signaler qu'elle a terminé l'E/S.

Puisque l'intelligence est dans le firmware du contrôleur et non dans le pilote, les pilotes pour ces cartes supportent classiquement plus de fonctionnalités - transferts synchrones, files marquées (tagged queuing), etc.

Avec les patches de lectures/écritures groupées, des taux de transferts à travers le système de fichiers atteignent pratiquement 100% des performances maximales en écriture et 75% en lecture.

L'utilisation du processeur est réduite à son minimum, quelle que soit la charge des E/S, avec 5% d'utilisation sur des accès à un CDROM double vitesse via une Adaptec 1540 et 20% lors d'un transfert soutenu à 1,2Mo/s sur un disque SCSI.

Recommandées dans tous les cas où le prix n'est pas la priorité, où la carte mère n'est pas défectueuse (certaines de ces cartes ne fonctionnent pas avec le contrôle de bus) et où des applications pour lesquelles le temps d'obtention des données est plus important que le débit (le supplément (overhead) dû à l'utilisation d'un contrôleur de bus est de 3-4ms par commande) ne seront pas utilisées.

10.2 Découpage/Réassemblage (Scatter/gather)

Le second point le plus important pour les performances est la gestion des E/S par découpage/réassemblage. Le supplément d'exécution d'une commande SCSI est non négligeable (de l'ordre de plusieurs millisecondes). Les contrôleurs de bus intelligents tels que l'Adaptec 1540 peuvent prendre 3-4ms pour traiter une commande SCSI avant même que la cible ne la reçoive. Sur les périphériques non bufferisés, ce supplément est toujours suffisant pour manquer un tour de galette, ce qui conduit à des taux de transfert de 60Ko/s (sur un lecteur à 3.600 tours/minute) par bloc transféré. Ainsi, pour maximiser les performances, il est nécessaire de minimiser le nombre de commandes SCSI envoyées pour transférer une certaine quantité de données en augmentant le nombre d'octets transférés pour chaque commande. La conception du cache des tampons de Linux fait que les blocs disque contigus ne sont pas contigus en mémoire. Avec les patches de lectures/écritures groupées, 4Ko utiles de données sont! ! ! contigus. La taille totale des blocs transférés en une seule commande SCSI est donc de 1Ko * nombre de régions de découpage/réassemblage sans le patch et de 4Ko * nombre de régions avec. Nous avons déterminé expérimentalement que 64Ko est une valeur raisonnable pour une seule commande SCSI - c'est-à-dire 64 buffers de découpage/réassemblage sans le patch, 16 avec. Suite au changement de 16Ko à 64Ko des transferts, nous avons observé une amélioration de 50% du débit maximal, à travers le système de fichiers, pour les écritures et les lectures, à 100% pour les premières et 75% pour les secondes, avec une carte Adaptec 1540.

10.3 BAL contre non-BAL (Mailbox vs. non-mailbox)

Certains contrôleurs intelligents, comme les cartes Ultrastor, WD7000, Adaptec 1540, 1740 et BusLogic ont utilisé une interface de type boîte aux lettres, dans laquelle les commandes SCSI sont exécutées simplement en plaçant une structure SCSI à une adresse mémoire donnée (BAL), en le signalant à la carte (c'est-à-dire en positionnant un indicateur d'émission pour la BAL), puis en attendant une réponse (courrier entrant). Grâce à cette interface de programmation de haut niveau, les utilisateurs peuvent souvent mettre à jour leur carte pour bénéficier des avantages des nouvelles fonctionnalités, telles que le FAST ou le WIDE SCSI, sans modifications du logiciel. Les pilotes ont tendance à être plus simples, à offrir plus de fonctionnalités et à être plus stables.

D'autres contrôleurs intelligents, comme la famille des NCR53c7/8xx ou les composants Adaptec AIC-7770/7870 (comprenant les cartes 274x, 284x et 2940) utilisent une interface de programmation de moins haut niveau. Leurs performances peuvent être meilleures, puisque la charge de travail peut être répartie entre le processeur de la carte et le processeur (plus rapide) principal de la machine. Ils offrent également une plus grande souplesse pour la réalisation de certaines fonctionnalités (le mode cible (target mode) pour certains périphériques par exemple). De plus, ces cartes peuvent être plus économiques à la production (dans certains cas, cette économie se retrouve au niveau du consommateur - voir les NCR). En contrepartie, les pilotes sont plus compliqués (comprenez : sont plus sujets à avoir des erreurs) et ils doivent être modifiés pour prendre en compte les fonctionnalités présentes sur les composants plus récents.

10.4 Les types de bus

Le type du bus est le prochain choix à considérer (ISA, EISA, VESA et PCI). Les personnes chargées du marketing clament souvent des débits maximums (bandwidth) absurdes, basés sur des taux de transfert en rafale (burst) qui relèvent presque de la fiction et qui ne servent de toute façon à rien. Par opposition, j'ai choisi de parler de valeurs réalistes, quotidiennes, basées sur les performances mesurées avec divers périphériques.

Bus

Débit maximum / description,

ISA

Le débit maximum est légèrement meilleur que 5Mo/s pour des cartes à contrôle de bus. Avec un bus ISA, l'arbitrage des contrôleurs de bus est réalisé par un vénérable DMA 8237 ; les temps d'acquisition du bus sont relativement médiocres. Les pilotes d'interruptions sont à trois états (tri-state) ou sur changement d'état (edge triggered). Cela signifie que les interruptions ne peuvent pas être partagées. Généralement, l'ISA n'est pas bufferisé et le bus mémoire de la machine hôte est occupé à chaque transfert. Aucun mécanisme n'existe pour empêcher une saturation du bus.

VESA

Le débit maximum se situe aux alentours de 30Mo/s. Certains systèmes VESA exploitent le bus en dehors de ses spécifications, ce qui les rend incompatibles avec certaines cartes. Tenez-en compte au moment d'acheter votre matériel s'il ne bénéficie pas d'une garantie. Généralement, le VESA est non bufferisé ; le bus mémoire de la machine hôte est occupé à chaque transfert.

EISA

Le débit maximum se situe aux alentours de 30Mo/s, les opérations de contrôle de bus étant généralement plus rapides que pour le VESA. Certains systèmes EISA bufferisent le bus, ce qui permet d'observer des transferts en rafale vers le bus mémoire de la machine hôte, plus rapide, et de minimiser l'impact sur les performances du processeur central. Les gestionnaires d'interruptions EISA peuvent être à trois états (tri-state), sur changement d'état (edge triggered) ou actifs sur collecteur ouvert (open collector level-active) ; cela permet le partage des interruptions avec les autres gestionnaires qui le gèrent. Puisque l'EISA alloue un espace d'adressage séparé pour chaque carte, il est habituellement moins sujet aux conflits de ressources que l'ISA ou le VESA.

PCI

Le débit maximum se situe aux alentours de 60Mo/s. La plupart des systèmes PCI utilisent des tampons d'écriture différée (write posting buffers) sur la carte, ce qui permet de minimiser l'effet des transferts rapides de part et d'autre sur les performances du bus et du processeur central. Les gestionnaires d'interruptions PCI sont actifs sur collecteur ouvert ; cela permet le partage des interruptions avec les autres gestionnaires qui le gèrent. Des mécanismes sont prévus pour éviter la saturation du bus et pour permettre à l'esclave et au maître de suspendre une opération de contrôle de bus.

Puisque le PCI offre un mécanisme plug-n-play via des registres de configuration réinscriptibles sur chaque carte, dans un espace d'adressage séparé, un système qui implémente correctement la gestion PCI est plug-and play.

Le PCI est très sévère sur la longueur des pistes, la charge, les spécifications mécaniques, etc. et devrait finalement être plus fiable que le VESA ou l'ISA.

Pour résumer, le PCI est le meilleur bus pour PC ; il a cependant des inconvénients. Le PCI en est encore à ses balbutiements et, bien que les constructeurs aient corrigé les problèmes, il circule toujours quelques vieilles cartes au composant PCI ou au BIOS défectueux. Je recommanderais pour cette raison que vous vous assuriez de pouvoir retourner le matériel en cas de défaut. Si les plus récentes cartes PCI sont véritablement plug-and-play, les anciennes cartes nécéssitaient une intervention de la part de l'utilisateur pour positionner correctement les cavaliers et configurer le logiciel (l'affectation des interruptions par exemple). Bien que la plupart des utilisateurs aient résolu leurs problèmes PCI, cela a demandé du temps et je déconseillerais l'achat d'une carte PCI si la disponibilité du système est très critique.

Pour de nombreux périphériques SCSI lents (disques à 2Mo/s ou moins, lecteurs de CDROM, lecteurs de bandes), il n'y a pas de grandes variations de débit en fonction de l'interface avec le bus du PC. Pour les disques SCSI actuels (typiquement, les derniers disques haut de gamme de plusieurs giga-octets ont un taux par tête de 4 à 5Mo/s et plusieurs compagnies expérimentent des disques à 14Mo/s par tête), le débit sera nettement meilleur avec des contrôleurs sur des bus plus rapides ; certains ont même relevé un facteur d'amélioration de 2,5 en passant d'une carte ISA Adaptec 1542 à une carte PCI NCR53c810.

A l'exception des cas où un mécanisme d'écriture différée ou de bufferisation des écritures est mis en oeuvre, lorsqu'un des bus de votre système est occupé, tous les autres bus sont inutilisables. Ainsi, bien qu'une saturation du bus n'affecte pas les performances SCSI, elle peut avoir un effet négatif sur la réponse interactive du système. Par exemple, si vous avez un disque SCSI à 4Mo/s en ISA, vous perdrez 80% de votre bande passante. Dans un système ISA/VESA, vous n'obtiendrez pas mieux que 6Mo/s. La plupart du temps, l'impact sur les tâches en arrière plan est également très sensible.

Notez bien qu'avoir plus de 16Mo de mémoire n'implique pas l'utilisation d'une carte SCSI à contrôle de bus ISA. Contrairement à certains autres systèmes d'exploitation, Linux effectue une double bufferisation lors des transferts à accès direct mémoire (DMA) sur un contrôleur ISA à destination d'une zone au-delà des 16Mo. De tels transferts ne sont pénalisés que de 1,5%, ce qui est très raisonnable.

Pour terminer, la différence de prix pour des cartes à contrôle de bus pour chacune de ces interfaces de bus est souvent minime.

Avec tout cela à l'esprit, en fonction de vos priorités, vos préférences iront vers

Stabilité, installations critiques,
et pas de garantie                      EISA ISA VESA PCI

Performances et installations personnelles
                                        PCI EISA VESA ISA

Comme je l'ai déjà mentionné plus haut, le contrôle de bus (bus mastering) plus que tout autre mode de transfert aura un impact bénéfique sur les performances de tout le système et il doit être plus important dans votre choix que le type de bus au moment de votre achat d'une carte SCSI.

10.5 Périphériques multiples

Si vous envisagez d'utiliser plusieurs périphériques sur votre bus SCSI, assurez-vous que votre contrôleur est capable de supporter plusieurs commandes en attente à un instant donné. C'est essentiel pour les lecteurs de bandes et souhaitable si vous comptez mélanger des périphériques de vitesses différentes (un lecteur de CDROM et un disque dur, par exemple). Si le pilote Linux ne gère qu'une seule commande à la fois, vous risquez de bloquer vos entrées/sorties avec vos disques durs pendant que le lecteur de bandes rembobine ou va à la fin de la cassette (cela peut durer une demi-heure). Avec deux disques, le problème n'est pas aussi sensible, bien que le débit atteigne la moyenne des deux transferts, plutôt que leur somme.

10.6 Les options SCSI-I, SCSI-II, SCSI-III FAST et WIDE, etc.

Au fil des ans, le SCSI a évolué, les nouvelles versions de la norme apportant de meilleures performances, des méthodes pour augmenter les débits, des commandes normalisées pour les nouveaux périphériques et de nouvelles commandes pour les périphériques déjà supportés.

En tant que telles, les évolutions de la version ne signifient rien. Exception faite de quelques détails mineurs (du genre : le SCSI-II n'autorise pas l'option "initiateur unique" du SCSI-I), les versions sont compatibles ascendantes, les nouvelles fonctionnalités étant intégrées en tant qu'options et n'étant pas obligatoires. La décision d'appeler un périphérique SCSI SCSI-I, SCSI-II ou SCSI-III est donc entièrement un choix de vente.

10.7 Comparaison des pilotes

Comparaison des pilotes (les chips supportés sont listés entre parenthèses)

                                        Nombre de
                                        commandes       SG              > 1
Pilote          Mode de transfert       simultanées     limite          cartes

                                        total/LUN

AM53C974        Contrôle de bus, DMA    12s/1s          255s            O
aha152x         Scrutation par FIFO(8k) 7s/1s           255s            N
    (AIC6260,
    AIC6360)
aha1542         Contrôle de bus, DMA    8s/1s           16              O
aha1740         Contrôle de bus, DMA    32s             16              N
aha274x         Contrôle de bus, DMA    4s/1s           255s            O
BusLogic        Contrôle de bus, DMA    192/31          128s, 8192h     O
(ces valeurs sont valables pour les BT-948/958/958D, les cartes plus
                             anciennes supportant moins de commandes)

eata_dma        Contrôle de bus, DMA    64s-8192h/2-64  512s, 8192h     O
fdomain         Scrutation par FIFO(8k) 1s              64s             N
    (TMC1800,   sauf le TMC18c30
    TMC18c30,   avec une FIFO de 2k
    TMC18c50,
    TMC36c70)

in2000*         Scrutation par FIFO(2k) 1s              255s            N
g_NCR5380       Scrutation pure         16s/2s          255s            O
    (NCR5380,
    NCR53c80,
    NCR5381,
    NCR53c400)
gsi8*           DMA esclave             16s/2s          255s
    (NCR5380)
PAS16           Scrutation pure         16s/2s          255s            O
    (NCR5380)   ou Scrutation inter-verrouillée
                (quelques échecs sur certains systèmes !)
seagate         Scrutation inter-verrouillée
                                        1s/1s           255s            N
wd7000          Contrôle de bus, DMA    16s/1s          16              O
t128            Scrutation inter-verrouillée
                                        16s             255s            O
    (NCR5380)
qlogic          Scrutation inter-verrouillée
                                        1s/1s           255s            N
ultrastor       Contrôle de bus, DMA    16s/2s          32              O
53c7,8xx        Contrôle de bus, DMA
    (NCR53c810,
     NCR53c815,
     NCR53c820,
     NCR53c825)
    rel5                                1s/1s           127s            N
    rel10                               8s/1s           127s            O

Remarques :

  1. Les pilotes marqués d'un astérisque (*) ne sont pas inclus dans la distribution du noyau et des images de démarrage binaires peuvent ne pas être disponibles.
  2. Les nombres suffixés par un 's' représentent des limites arbitraires dans le logiciel, qui peuvent être changées par un #define au moment de la compilation.
  3. Les limitations matérielles sont indiquées par le suffixe 'h' et peuvent différer des limites logicielles actuellement imposées par les pilotes de Linux.
  4. Des nombres sans suffixe peuvent indiquer soit des limitations matérielles, soit des limitations logicielles.
  5. La version 5 du pilote NCR53c810 est incluse dans les noyaux standard 1.2.x et 1.3.x ; la version 10 peut être téléchargée par FTP anonyme.
  6. A l'exception de la AM53C974, les cartes à contrôle de bus DMA sont intelligentes ; les NCR exécutent du microcode depuis la mémoire principale, les AIC7770 exécutent leur microcode depuis de la mémoire embarquée sur le composant, toutes les autres utilisent une interface du style BAL (mailbox).

10.8 Comparaison des contrôleurs

Carte                   Pilote          Bus     Prix    Remarques

Adaptec AIC-6260        aha152x         ISA             composant,
                                                        pas une carte
Adaptec AIC-6360        aha152x         VLB             composant,
                                                        pas une carte
    (utilisé dans la plupart des cartes multi-E/S
     VESA/ISA avec des cartes principales Zenon)
Adaptec 1520            aha152x         ISA
Adaptec 1522            aha152x         ISA     $80     1520 avec CdD
                                                        (Contrôleur de Disquet-
                                                         tes)
Adaptec 1510            aha152x         ISA             1520 sans ROM de boot,
                                                        auto-détection échouent.
Adaptec 1540C           aha1542         ISA
Adaptec 1542C           aha1542         ISA             1540C avec CdD
Adaptec 1540CF          aha1542         ISA             FAST SCSI-II
Adaptec 1542CF          aha1542         ISA     $200    1540CF avec CdD
Adaptec 1640            aha1542         MCA

Adaptec 1740            aha1740         EISA            n'est plus fabriquée
Adaptec 1742            aha1740         EISA            n'est plus fabriquée
                                                        1740
                                                        avec CdD
Adaptec 2740            aha274x         EISA
Adaptec 2742            aha274x         EISA            avec CdD
Adaptec 2840            aha274x         VLB
Adaptec 2842            aha274x         VLB             avec CdD
Adaptec 2940            aha274x         PCI
Always IN2000           in2000          ISA
BusLogic BT-948         BusLogic        PCI     $180    Ultra SCSI
BusLogic BT-958         BusLogic        PCI     $230    Wide Ultra SCSI
(reportez-vous au chapitre Cartes contrôleurs multi-maîtres BusLogic pour des détails sur d'autres cartes BusLogic)
DPT     PM2011          eata_dma        ISA             FAST SCSI-II
        PM2012A         eata_dma        EISA            FAST SCSI-II
        PM2012B         eata_dma        EISA            FAST SCSI-II
        PM2021          eata_dma        ISA             FAST SCSI-II
        PM2022          eata_dma        EISA            FAST SCSI-II
        PM2024          eata_dma        PCI             FAST SCSI-II
        PM2122          eata_dma        EISA            FAST SCSI-II
        PM2322          eata_dma        EISA            FAST SCSI-II
        PM2124          eata_dma        PCI             FAST SCSI-II
        PM2124          eata_dma        PCI             FAST SCSI-II
        PM2124          eata_dma        PCI             FAST SCSI-II
        PM2124          eata_dma        PCI             FAST SCSI-II
        PM2124          eata_dma        PCI             FAST SCSI-II
        PM2124          eata_dma        PCI             FAST SCSI-II
        PM2041W         eata_dma        ISA             Wide
                                                        Terminaison unique
                                                                (Single-ended)
                                                        SCSI-II
        PM2041UW        eata_dma        ISA             Ultra Wide
                                                        Terminaison unique
        PM2042W         eata_dma        EISA            Wide
                                                        Terminaison unique
        PM2042UW        eata_dma        EISA            Ultra Wide
                                                        Terminaison unique
        PM2044W         eata_dma        PCI             Wide
                                                        Terminaison unique
        PM2044UW        eata_dma        PCI             Ultra Wide
                                                        Terminaison unique
        PM2142W         eata_dma        EISA            Wide
                                                        Terminaison unique
        PM2142UW        eata_dma        EISA            Ultra Wide
                                                        Terminaison unique
        PM2144W         eata_dma        PCI             Wide
                                                        Terminaison unique
        PM2144UW        eata_dma        PCI             Ultra Wide
                                                        Terminaison unique
        PM3021          eata_dma        ISA             multi-canaux
                                                        raid/emplacements simm
        PM3122          eata_dma        EISA            multi-canaux/raid
        PM3222          eata_dma        EISA            multi-canaux
                                                        raid/emplacements simm
        PM3224          eata_dma        PCI             multi-canaux
                                                        raid/emplacements simm
        PM3334          eata_dma        PCI             Wide Ultra SCSI
                                                        multi-canaux
                                                        raid/emplacements simm

DTC 3290                aha1542         EISA            bien qu'ils devraient
                                                        marcher, les matériels
                                                        DTC ne sont pas gérés,
                                                        à cause de la politique
                                                        de diffusion des docu-
                                                        mentations
DTC 3130                53c7,8xx        PCI             '810
DTC 3130B               53c7,8xx        PCI             '815
DTC 3292                aha1542         EISA            3290 avec CdD
DTC 3292                aha1542         EISA            3290 avec CdD
Future Domain 1680      fdomain         ISA             CdD
Future Domain 3260      fdomain         PCI
NCR53c810 (cartes       53c7,8xx        PCI     $60     composant, pas une
    vendues                                     (carte) carte. Les cartes ne
    par FIC, Chaintech,                                 possèdent pas de BIOS,
    Nextor, Gigabyte, etc.                              bien que la plupart des
    Cartes avec composant vendues                       cartes non équipées de
    par AMI, ASUS, J-Bond,                              NCR aient le BIOS SDMS
    etc. Fréquentes dans les
    systèmes PCI DEC)
NCR53c815 (            53c7,8xx         PCI     $100    NCR53c810 + BIOS
    Intel PCISCSIKIT,
    NCR8150S, etc.)
NCR53c825              53c7,8xx         PCI     $120    Variante "WIDE" du
                                                        NCR53c815.  Notez que
                                                        le pilote actuel de
                                                        Linux ne négocie pas de
                                                        transferts "WIDE".
Pro Audio Spectrum 16   pas16           ISA             Carte son avec SCSI
Seagate ST01            seagate         ISA     $20     Le BIOS ne marche qu'a-
                                                        vec certains lecteurs
Seagate ST02            seagate         ISA     $40     ST01 avec CdD
Sound Blaster 16 SCSI   aha152x         ISA             Carte son avec SCSI
Western Digital 7000    wd7000          ISA             avec CdD
Trantor T128            t128            ISA
Trantor T128F           t128            ISA             T128 avec CdD et sup-
                                                        port pour des IRQs éle-
                                                        vées
Trantor T130B           g_NCR5380       ISA
Ultrastor 14F           ultrastor       ISA             avec CdD
Ultrastor 24F           ultrastor       EISA            avec CdD
Ultrastor 34F           ultrastor       VLB

Remarques :

  1. Trantor a été récemment rachetée par Adaptec et certains de leurs produits sont maintenant vendus sous le nom d'Adaptec.
  2. Suite à un dépôt de bilan, il n'existe plus aucun support technique à cette heure pour les cartes Ultrastor.
  3. Le prix des cartes à contrôle de bus NCR53c810 n'est pas une erreur de frappe ; il inclut le paquetage standard des pilotes ASPI/CAM pour DOS, OS/2 et Windows (accès 32 bits) et d'autres pilotes peuvent être téléchargés gratuitement. Certains n'ont pas eu à se plaindre de la compagnie
    SW (swt@netcom.com) (214) 907-0871 fax (214) 907-9339
    
    Au 23 décembre 1995, leur prix était de $53 pour les cartes '810.
  4. Les derniers composants SCSI d'Adaptec font montre d'une sensibilité inhabituelle aux problèmes de câblage et de terminaison. C'est pourquoi je ne recommanderais pas les cartes Adaptec 154x C et CF, pas plus que la série 2xxx. A remarquer que ces problèmes de fiabilité ne sont pas constatés sur les vieilles cartes 154x B et 174x A ou encore, d'après ce que j'en sais, sur les cartes à base des composants AIC-6360/AIC-6260 (1505, 1510, 1520, etc.). La qualité de leur support technique a également baissé, les délais se sont fréquemment allongés et les employés sont incompétents (arguant par exemple de certaines clauses de confidentialité sur des documents, alors qu'il n'y en avait pas), parfois hostiles (refusant de passer les questions à d'autres techniciens lorsqu'ils sont incapables d'y répondre eux-mêmes).
  5. Si des utilisateurs désirent une collaboration ou veulent établir des relations 'politiques' avec Adaptec, les remarques précédentes doivent êtres prises en considération. Cela étant, les Adaptec 152x/1510/1505 sont meilleures que les autres cartes ISA dans la même gamme de prix et il y a des affaires à faire avec des cartes usagées ou des surplus de 154x B et 1742, ce qui, à mon avis, doit faire oublier le problème du support.
  6. Toutes les cartes DPT peuvent être mises à jour avec des modules mémoire (cache) et raid. Toutes les cartes sont également disponibles en versions "Wide" et/ou différentielles.
  7. Les cartes NCR ne sont pas toutes équivalentes. Ainsi, alors que l'ASUS SC200 utilise une terminaison active, la plupart des autres cartes NCR53c810 utilisent une terminaison passive. Presque toutes les cartes '825 ont une terminaison active, mais certaines ont une ROM pour le BIOS tandis que d'autres ont une ROM Flash. La plupart des cartes '825 ont un large connecteur externe, un large connecteur interne et un connecteur interne fin, bien que quelques-unes n'aient pas ce dernier (les cartes bon marché de CSC).

10.9 Pour résumer

La majorité des utilisateurs de cartes ISA, EISA, VESA et PCI seront probablement mieux servis par les cartes multi-maîtres BusLogic, de par leur performance, leurs fonctionnalités (comme la terminaison active) et leur compatibilité avec les Adaptec 1540. Un certain nombre de modèles est disponible avec des interfaces EISA, ISA, PCI et VESA, en terminaison simple ou différentielle, en 8 ou 16 bits. Les tous récents modèles Ultra SCSI PCI, les BT-948/958/958D, incluent également une ROM Flash pour faciliter les mises à jour du firmware et une terminaison automatique "adaptative" (smart termination).

Les personnes désirant tirer les meilleures performances d'E/S peuvent envisager l'acquisition de cartes de chez DPT, qui sont les seules à gérer le RAID, le cache et plusieurs canaux SCSI.

Les personnes avec des systèmes PCI pourront regarder du côté des cartes basées sur le composant NCR53c8xx. Ce sont des cartes à contrôle de bus ; on peut trouver des '810 à $53 l'unité (c'est-à-dire moins chères que les Adaptec 1520). Le magazine C't a évalué certaines de ces cartes. Il ressort des tests qu'elles sont plus rapides que les Adaptec 2940 et les BusLogic BT-946C (sous DOS) et qu'elles s'en tirent honorablement sous Linux (jusqu'à 6Mo/s à travers le système de fichiers). Les inconvénients de ces cartes comparées aux BusLogic est qu'elles ne sont pas compatibles avec les Adaptec 1540, qu'elles peuvent être livrées avec ou sans terminaison active et que vous allez devoir récupérer les dernières versions des pilotes (standard dans les noyaux 1.3.5x et disponibles par FTP pour les noyaux 1.2.x) pour exploiter pleinement le matériel, et qu'enfin vous aurez peut-être plus de problèmes qu'avec des interfaces de type BAL (mailbox) comme sur les BusLogic ou les DPT.

S'il est important que tout marche du premier coup, une carte multi-maîtres BusLogic ou DPT est probablement le meilleur choix, la simplicité des interfaces de type BAL comparée à la complexité des interfaces des NCR53c8xx et des Adaptec AIC7xxx faisant la différence.

Ceux qui veulent des cartes non PCI pour un petit budget seront certainement heureux de trouver leur bonheur dans les surplus de cartes Adaptec 154x B ou 174x A, voire avec des clones d'Adaptec 1520 (aux alentours de $80) pour des cartes neuves. Ces cartes ont des débits et une réponse interactive acceptables pour un prix modique.

11. Affectation des numéros de mineur

Suite à l'utilisation par Linux du type dev_t sur 16 bits, 8 bits étant réservés pour le mineur, les disques SCSI, les lecteurs de bandes ou de CDROM et les fichiers spéciaux génériques ont des mineurs attribués dynamiquement, suivant l'algorithme suivant :

Pour tous les contrôleurs SCSI, de scsi0 jusqu'à scsiN
        Pour tous les identificateurs SCSI sur le bus, de 0 à 7, sauf pour
        l'identificateur du contrôleur courant
                Pour toutes les unités logiques, de 0 à max_scsi_luns
                - test de la combinaison <bus, cible, unité logique> en
                  envoyant une commande TEST UNIT READY. Si une unité logique
                  est supposée absente, ne plus continuer les tests pour le
                  couple <bus, cible>.
                - émission d'une commande INQUIRY pour déterminer ce qui
                  a été trouvé (type du périphérique, vendeur, modèle,
                  version du firmware, etc.).
                - renvoi du résultat de cette reconnaissance à une fonction
                  spéciale d'identification propre à chaque pilote de haut
                  niveau présent (par exemple le pilote de disques, de
                  lecteur de bandes, etc.). Attachement de ce périphérique
                  à la prochaine unité disponible pour chaque pilote qui
                  désire gérer ce périphérique. Le gestionnaire générique
                  va tous les attacher.
                - s'il s'agissait d'un périphérique SCSI-I ou qui fait
                  partie d'une liste de périphériques connus comme ne
                  gérant pas plusieurs unités logiques, stopper les tests
                  pour le couple <bus, cible>.
                - s'il s'agissait d'un périphérique connu comme pouvant
                  gérer plusieurs unités logiques, une scrutation de toutes
                  les unités logiques potentielles est commencée, surchargeant
                  la valeur max_scsi_luns.

Il y a souvent des problèmes avec ce genre d'approche, car si votre système possède des périphériques qui ne sont pas branchés en permanence, les mineurs vont dépendre des périphériques présents au moment du boot. Cela peut être gênant, car les scripts de démarrage ou le fichier /etc/fstab peuvent contenir des instructions pour monter des partitions spécifiques. Ces commandes peuvent échouer si le disque a un mineur différent d'une fois sur l'autre.

Ce problème n'a pas été complètement résolu. Un programme qu'on peut trouver sur tsx-11 crée une arborescence /dev/scsi basée sur le numéro d'hôte, l'identificateur et le numéro d'unité logique. Ce n'est pas particulièrement propre, mais cela permet d'éviter pas mal d'ennuis.

Une meilleure solution passera sans doute par le pseudo répertoire /proc/scsi. Nous y travaillons actuellement, aussi pour l'instant ne pouvons-nous pas dire quelle sera sa forme définitive. A l'heure où j'écris ces lignes, cette approche semble prometteuse pour résoudre certains de ces points.