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