Linux SCSI HOWTO <author>Drew Eckhardt, <tt/drew@cs.colorado.edu/, version française Jean Zundel. <date>v2.15, 20 March 1995 <abstract> Ce HOWTO couvre le sous-système SCSI de Linux, tel qu'implémenté dans la révision 1.1.74 du noyau Linux et le nouveau code alpha. Les révisions antérieures du code SCSI ne sont pas supportées, et peuvent différer significativement en termes de pilotes implémentés, de performances et d'options disponibles. </abstract> <toc> <sect>Introduction <sect1>Licence Les redistributions non-commerciales d'une copie exacte sous toute forme, physique ou électronique, sont autorisées sans permission expresse de l'auteur. Les traductions sont de même autorisées sans permission expresse si elles comprennent une note concernant le traducteur. La redistribution commerciale est autorisée et encouragée, à condition que l'auteur en soit averti et qu'il ait la possibilité de fournir une version à jour. Les citations brèves peuvent être utilisées sans consentement préalable de l'auteur. Le travail dérivant de ce document doit soit inclure une copie exacte de ce fichier, soit permettre l'accès à une copie exacte du document. Dans ce dernier cas, un pointeur vers la copie en question doit être clairement mise en évidence. En bref, nous désirons promouvoir la dissémination de cette information à travers tous les canaux possibles. Nous désirons cependant garder le copyright sur les documents HOWTO, être informés de tout projet de redistribution de ces HOWTO pour nous assurer que des documents caducs ne circulent pas trop et que TOUTES les informations fournies par les HOWTO soit distribuées. Si vous avez des questions sur le projet de documentation Linux, vous pouvez contacter Matt Welsh, le coordinateur des HOWTO Linux, à <tt>mdw@sunsite.edu</tt>. Les questions concernant ce document lui-même doivent être envoyées à Drew Eckardt, <tt>drew@Colorado.EDU</tt>. Les questions et remarques concernant la traduction française doivent être adressées à Jean Zundel, <tt>jean.zundel@lill.frmug.fr.net</tt>. <sect1>Remarque importante <bf>IMPORTANT :</bf> <bf>LES COMPTES-RENDUS DE BOGUES QUI NE SUIVENT PAS LA PROCEDURE SOULIGNEE EN SECTION 2 SERONT IGNORES.</bf> Pour plus d'informations, vous pouvez rejoindre le canal SCSI de la liste des activistes Linux ; écrivez à <tt>linux-activists-request@joker.cs.hut.fi</tt>. avec la ligne <verb> X-Mn-Admin: join SCSI </verb> dans l'en-tête, ainsi qu'à la liste SCSI Linux en écrivant à <tt>majordomo@vger.rutgers.edu</tt> avec la ligne <verb> subscribe linux-scsi </verb> dans le texte. Je suis conscient que ce document n'est pas des plus agréables à l'utilisation, et qu'il peut contenir des inexactitudes et des approximations. Si vous avez des commentaires constructifs à faire sur la façon d'améliorer la situation, libre à vous de m'écrire à ce sujet. <sect><heading><label id="common problems">Problèmes courants</> Cette section dresse la liste de certains des problèmes couramment rencontrés. Si rien ici ne répond à vos questions, il vous faudra également consulter les sections concernant votre adaptateur et les périphériques posant problème. <sect1><heading><label id="general flaky">Défaillances générales</> Les erreurs aléatoires proviennent fréquemment du câblage et des terminaisons. Certains produits, comme ceux qui sont construits autour des circuits NCR les plus récents, intègrent un filtrage digital et une négation active du signal, et ne sont pas très sensibles aux problèmes de câblage. D'autres, comme les Adaptec 154xC, 154xCF et 274x, sont extrêmement sensibles et peuvent échouer avec des câbles qui fonctionnent avec d'autres systèmes. Je le répète : certains adaptateurs s'avèrent <bf>extrêmement</bf> sensibles aux problèmes de câblage et de terminaison et ceux-ci doivent donc être vérifiés avant toute chose en cas d'ennui. Pour minimiser les problèmes, il faut utiliser des câbles qui : <enum> <item>Respectent la norme SCSI-II <item>Possèdent une impédance caractéristique de 132 ohms <item>Proviennent tous de la même source afin d'éviter des incompatibilités d'impédance <item>Proviennent d'un fournisseur réputé comme Amphenol. </enum> La puissance de terminaison doit être fournie par tous les périphériques sur le bus SCSI, à travers une diode pour éviter tout retour de courant, afin qu'une puissance suffisante soit disponible aux extrémités du câble où elle est nécessaire. Afin d'éviter des dommages physiques en cas de court-circuit, TERMPWR doit passer par un fusible ou un autre système de limitation de courant. Si plusieurs périphériques, plusieurs câbles externes ou du FAST SCSI 2 sont utilisés, une terminaison parfaite forcée ou active est requise au deux bouts du bus SCSI. Voir la FAQ <tt>comp.periphs.scsi</tt> <url url="ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi"> pour plus d'informations sur la terminaison active. <sect1>La ligne de commande du noyau D'autres parties de la documentation se réfèrent à une ``ligne de commande du noyau'' (kernel command line). La ligne de commande du noyau est un ensemble d'options que l'on peut spécifier depuis le prompt LILO: après un nom d'image, ou bien dans le champ append de votre fichier de configuration LILO (LILO >= .14 utilise /etc/lilo.conf, les versions antérieures utilisant /etc/lilo/config). Démarrez votre système avec LILO, et frappez l'une des touches Alt, Ctrl ou majuscule quand il propose un prompt. LILO devrait répondre par <tscreen><verb> boot: </verb></tscreen> On peut alors sélectionner une image de noyau à lancer, ou les lister avec ``?'' (NdT : <Shift !> sur un clavier français). Par exemple <tscreen><verb> boot: ? ramdisk floppy harddisk </verb></tscreen> Pour démarrer ce noyau avec les options de ligne de commande que vous avez sélectionnées, entrez simplement son nom suivi d'une liste d'options délimitées par des espaces, en finissant par un retour chariot. Les options prennent la forme : <verb> variable=valuelist </verb> Où valuelist peut être une valeur unique ou une liste de valeurs délimitées par des virgules, sans espace. A l'exception du périphérique racine, les valeurs individuelles sont des nombres, et peuvent être spécifiées en décimal ou en hexadécimal. Par exemple, pour démarrer Linux avec un clone d'Adaptec 1520 non reconnu au démarrage, on peut entrer <tscreen><verb> boot: floppy aha152x=0x340,11,7,1 </verb></tscreen> Si vous désirez ne pas entrer tout ceci à chaque fois, il est aussi possible d'utiliser l'option ``append'' du fichier de configuration de LILO pour les versions .13 et ultérieures. Par exemple, <tscreen><verb> append="aha152x=0x340,11,7,1" </verb></tscreen> <sect1>Un périphérique SCSI apparait à tous les ID possibles Dans ce cas, vous avez déclaré le périphérique à la même adresse que le contrôleur (typiquement 7, bien que certaines cartes utilisent d'autres adresses, comme 6 pour certaines cartes Future Domain). Changez les réglages de cavaliers. <sect1>Un périphérique apparait à toutes les LUN possibles Le périphérique contient un code en ROM défectueux. On peut temporairement essayer d'utiliser l'option de ligne de commande du noyau <tscreen><verb> max_scsi_luns=1 </verb></tscreen> Si ceci fonctionne, il existe une liste de périphériques défectueux dans les sources du noyau, dans la variable blacklist de drivers/scsi/scsi.c. Ajoutez votre périphérique à cette liste et envoyez le patch à Linus. <sect1>Vous obtenez des sense error alors que vous savez que les périphériques sont corrects Cela est parfois provoqué par une terminaison ou des câbles défectueux. Voir <ref id="general flaky">: Défaillance générale <sect1>Un noyau configuré avec le réseau ne fonctionne pas. Les routines d'autodétection de la plupart des pilotes de réseaux ne sont pas passives et peuvent interférer avec certains des pilotes SCSI. <sect1>Périphérique détecté, mais impossible d'y accéder. Un périphérique SCSI est détecté par le noyau, mais vous êtes incapable d'y accéder ; par exemple, mkfs /dev/sdc, tar xvf /dev/rst2, etc., échouent. Vous n'avez pas de fichier spécial dans /dev pour le périphérique. Les périphériques Unix sont identifiés par leur type, bloc ou caractère (les périphériques bloc passent par le buffer cache, ce qui n'est pas le cas des périphériques caractère), par un nombre majeur (c.à.d. quel pilote est utilisé ; le bloc majeur 8 correspond aux périphériques SCSI) et un nombre mineur (c.à.d. à quelle unité on accède pour un pilote donné ; le caractère majeur 4, mineur 0 est la première console virtuelle, mineur1 la suivante, etc). Mais ce genre d'accès par nommage direct aux périphériques enfreindrait le principe unix/Linux : ``Tout est fichier'', ce qui fait que des fichiers spéciaux de périphériques caractère et bloc sont créés sous /dev. Ceci vous permet d'accéder au troisième périphérique SCSI par /dev/sdc, au premier port série par /dev/ttyS0, etc. La méthode préférentielle pour créer un fichier consiste à utiliser le script MAKEDEV : <tscreen><verb> cd /dev </verb></tscreen> et de lancer MAKEDEV (en tant que root) pour les périphériques à créer. Par ex. : <tscreen><verb> ./MAKEDEV sdc </verb></tscreen> les jokers ``devraient'' marcher ; par ex. <tscreen><verb> ./MAKEDEV sd\* </verb></tscreen> ``devrait'' créer des entrées pour tous les périphériques disque SCSI (ceci doit créer les fichiers allant de /dev/sda à /dev/sdp, avec quinze entrées de partition pour chacun) <tscreen><verb> ./MAKEDEV sdc\* </verb></tscreen> ``devrait'' créer les entrées pour /dev/sdc et les quinze partitions permises sur /dev/sdc, etc. Je dis ``devrait'' parce qu'il s'agit là du comportement standard sous unix ; le script MAKEDEV peut ne pas se conformer à cette règle, ou peut avoir restreint le nombre de périphériques qu'il créera. Si la baguette magique de MAKEDEV ne suffit pas, il vous faudra créer les entrées de périphériques à la main avec la commande mknod. Les types bloc/caractère et les nombres majeurs et mineurs sont spécifiés pour divers périphériques SCSI à la sous-section 3 : Fichiers de périphériques, dans la section appropriée. Prenez ces nombres, et entrez (en tant que root) <tscreen><verb> mknod /dev/periph b|c majeur mineur </verb></tscreen> Exemple : <tscreen><verb> mknod /dev/sdc b 8 32 mknod /dev/rst0 c 9 0 </verb></tscreen> <sect1><heading><label id="scsi lockup">Blocages SCSI du système</> De nombreuses causes possibles sont envisageables. Reportez vous également à la section concernant votre adaptateur pour des solutions spécifiques. Il existe des cas dans lesquels les blocages semblent se produire quand plusieurs périphériques fonctionnent en même temps. Vous pouvez alors essayer de contacter le fabriquant des périphériques et voir si des mises à jour du logiciel en ROM susceptibles de corriger le problème sont disponibles. Si possible, essayez un câble SCSI différent, ou essayez sur un autre système. De mauvais blocs sur le disque, ou une mauvaise gestion du DMA par la carte mère (pour les adaptateurs qui l'utilisent) peuvent causer ce problème. De nombreuses autres conditions peuvent mener à ce type d'événement. Ces problèmes surviennent parfois quand plusieurs périphériques fonctionnent sur le même bus en même temps. Dans ce cas, si votre pilote d'adaptateur supporte plus d'une commande en suspens (outstanding command) à la fois, essayez de réduire cette valeur à 1 et voyez si les choses s'arrangent. Si vous avez des unités à bande ou des lecteurs de CD-ROM lents sur le bus, cette solution peut ne pas s'avérer satisfaisante. <sect1><heading><label id="candb kernel">Configuration et construction du noyau</> Les pilotes SCSI non utilisés consomment de la mémoire et aggravent les problèmes sur les petits systèmes parce que la mémoire du noyau n'est pas paginable. Il vous faut donc construire un noyau adapté à votre système, ne comprenant que les pilotes dont vous avez besoin. cd /usr/src/linux Si vous utilisez un périphérique racine différent de celui en cours, ou quelque chose d'autre que du VGA 80x25, et que vous écrivez sur une disquette de démarrage, vous devez éditer le makefile, et vous assurer que les lignes <verb> ROOT_DEV = </verb> et <verb> SVGA_MODE = </verb> correspondent à ce que vous désirez. Si vous avez installé des patches, vous pouvez désirer que tous les fichiers soient reconstruits. Dans ce cas, entrez <tscreen><verb> make mrproper </verb></tscreen> Que vous ayez exécuté make mrproper ou non, entrez <tscreen><verb> make config </verb></tscreen> et répondez aux questions de configuration. Lancez ensuite <tscreen><verb> make depend </verb></tscreen> et finalement <tscreen><verb> make </verb></tscreen> Une fois la compilation terminée, vous pouvez mettre à jour la configuration de lilo, ou écrire une disquette de démarrage en lançant <tscreen><verb> make zdisk </verb></tscreen> <sect1>Les LUNS autres que 0 ne fonctionnent pas Ce problème arrive fréquemment avec les SCSI -> MFM, RLL, ESDI, SMD, et les cartes bridge similaires. A un moment donné, nous en sommes arrivés à conclure que de nombreux périphériques SCSI-I étaient extrêmement défectueux, et nous avons ajouté le code suivant <code> /* Certains peripheriques scsi-1 ne gerent pas lun != 0. Je suppose que les peripheriques scsi-2 font mieux. */ if((scsi_result[2] & 0x07) == 1 && (scsi_result[3] & 0x0f) == 0) break; </code> à scan_scsis() dans drivers/scsi/scsi.c. Si vous supprimez ce code, vos anciens périphériques devraient être correctement détectés si vous n'avez pas utilisé l'option de ligne de commande du noyau max_scsi_luns, ou la définition NO_MULTI_LUN au moment de la compilation. <sect>Comptes-rendus de bogues (Bug Reports) Les développeurs SCSI de Linux ne maintiennent pas forcément les anciennes révisions du code en raison de contraintes d'espace. Si donc vous n'utilisez pas le dernier noyau Linux diffusé publiquement (remarquez que de nombreuses distributions, comme MCC, SLS, Yggdrasil, etc. restent souvent un ou même vingt patches en arrière), il y a de grandes chances pour que nous soyons incapables de résoudre votre problème. En conséquence, avant de rendre compte d'un bug, veuillez vérifier s'il persiste avec le dernier noyau publiquement disponible. Si après vous être mis à jour, et après avoir lu ce document en détail, vous pensez toujours être en présence d'un bug, envoyez un compte-rendu (bug report) au canal SCSI de la liste de diffusion où il sera lu par de nombreuses personnes ayant contribué aux pilotes SCSI de Linux. Dans votre compte-rendu, veuillez fournir le plus d'informations possible concernant votre configuration matérielle, le texte exact et tous les messages que Linux affiche au moment du démarrage, quand la condition d'erreur se produit, ainsi que l'endroit de l'erreur dans le code source. Utilisez les procédures indiquées en Section 2.1 : Capture des messages et en Section 2.2 : Localisation de la source d'un panic(). Une quantité insuffisante d'informations peut conduire à un mauvais diagnostic de votre problème, ou à ce que les développeurs décident qu'il existe d'autres problèmes plus intéressants à résoudre. En conclusion, si nous ne pouvons pas reproduire votre bug, et que vous ne pouvez pas nous dire ce qui ne va pas, il ne sera pas résolu. <sect1>Capture des messages Si vous n'avez pas lancé de système de trace de messages du noyau : Assurez-vous que le système de fichiers /proc est monté. <tscreen><verb> grep proc /etc/mtab </verb></tscreen> Si ce n'est pas le cas, montez-le <tscreen><verb> mkdir /proc chmod 755 /proc mount -t proc /proc /proc </verb></tscreen> Copiez la révision et les messages du noyau dans un fichier log <tscreen><verb> cat /proc/version >/tmp/log cat /proc/kmsg >>/tmp/log </verb></tscreen> Faites Ctrl-C après une seconde ou deux. Si vous faites tourner un traceur, vous devrez chercher dans les fichiers de trace appropriés (/etc/log/sylog.conf devrait vous aider à les localiser), ou utiliser dmesg. Si Linux n'est pas encore démarré, formatez une disquette sous DOS. Notez que si vous avez une distribution qui monte la disquette racine depuis le lecteur et non depuis un disque virtuel en RAM, vous devrez formatter une disquette lisible dans le lecteur non utilisé, ou utiliser leur option de démarrage par disque virtuel. Lancez Linux depuis la disquette de démarrage de votre distribution, de préférence en mode mono-utilisateur en utilisant un disque RAM comme racine. <tscreen><verb> mkdir /tmp/dos </verb></tscreen> Insérez la disquette dans un lecteur libre pour monter la racine, et montez- la. Par ex. <tscreen><verb> mount -t msdos /dev/fd0 /tmp/dos </verb></tscreen> ou <tscreen><verb> mount -t msdos /dev/fd1 /tmp/dos </verb></tscreen> Copiez-y votre trace <tscreen><verb> cp /tmp/log /tmp/dos/log </verb></tscreen> Démontez votre disquette DOS <tscreen><verb> umount /tmp/dos </verb></tscreen> Et arrêtez Linux <tscreen><verb> shutdown </verb></tscreen> Redémarrez sous DOS, et insérez votre fichier de trace dans un message en utilisant votre logiciel de communications favori. <sect1>Localisation de la source d'un panic() Comme d'autres unix, quand une erreur fatale se produit, Linux appelle la fonction panic(). A l'inverse d'autres unix, Linux ne produit pas de core dump vers le périphérique de swap ou de dump avant de redémarrer automatiquement. Un résumé d'informations utiles est affiché afin que l'utilisateur le copie à la main. Par ex. : <tscreen><verb> 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 </verb></tscreen> Prenez le nombre hexadécimal figurant à la ligne EIP:, dans ce cas 19c905, et cherchez dans /usr/src/ linux/zSystem.map le nombre le plus grand inférieur ou égal à cette adresse. <tscreen><verb> 0019a000 T _fix_pointers 0019c700 t _intr_scsi 0019d000 t _NCR53c7x0_intr </verb></tscreen> Ceci vous indique dans quelle fonction l'erreur se trouve. Recompilez le fichier source qui définit cette fonction en activant les informations de debug, ou le noyau entier si vous le préférez en éditant /usr/src/linux/Makefile et en ajoutant un ``-g'' à la définition de CFLAGS. <tscreen><verb> ##standard CFLAGS #</verb></tscreen> Par exemple, <tscreen><verb> CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe </verb></tscreen> devient <tscreen><verb> CFLAGS = -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe </verb></tscreen> Reconstruisez le noyau, de façon incrémentale ou en faisant un <tscreen><verb> make clean make </verb></tscreen> Rendez le noyau démarrable en lui créant une entrée dans votre /etc/lilo.conf <tscreen><verb> image = /usr/src/linux/zImage label = experimental </verb></tscreen> et en relançant LILO en tant que root, ou en créant une disquette de démarrage <tscreen><verb> make zImage </verb></tscreen> Redémarrez et enrregistrez le nouveau EIP de l'erreur. Si script est installé, vous pouvez le démarrer, et il tracera votre session de mise au point dans le fichier typescript. Maintenant, lancez <tscreen><verb> gdb /usr/src/linux/tools/zSystem </verb></tscreen> et entrez <tscreen><verb> info line *<votre EIP></verb></tscreen> Par exemple, <tscreen><verb> info line *0x19c905 </verb></tscreen> A quoi GDB répondra quelque chose comme <tscreen><verb> (gdb) info line *0x19c905 Line 2855 of ``53c7,8xx.c'' starts at address 0x19c905 <intr_scsi+641>and ends at 0x19c913 <intr_scsi+655>. </verb></tscreen> Enregistrez cette information. Entrez ensuite list < numéro de ligne> Par ex., <code> (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", </code> Bien sûr, quit vous sortira de GDB. Enrtegistrez aussi cette information, car elle fournira un contexte au cas où les noyaux des développeurs diffèrent du vôtre. <sect>Hôtes Cette section donne des informations spécifiques sur les divers adaptateurs hôtes qui sont suportés d'une manière ou d'une autre sous Linux. <sect1>Matériel supporté et non supporté Pilotes des noyaux de distributions : Adaptec 152x, Adaptec 154x (y compris les clones de Bustek et les cartes DTC 329x), Adaptec 174x, Adaptec 274x/284x/2940, les cartes se conformant au protocole EATA-DMA (toutes les DPT PMXXXXX/XX et SKXXXXX/XX sauf la PM2001, certaines cartes de NEC and ATT), Future Domain 850, 885, 950, et les autres cartes dans cette série (mais pas les 840, 880 et 881 à moins de faire le patch approprié), Future Domain 16x0 avec les circuits TMC-1800, TMC-18C30 ou TMC18C50, NCR53c8x, les ports SCSI de la PAS16, Seagate ST0x, Trantor T128/T130/T228, Ultrastor 14F, 24F et 34F, et Western Digital 7000. Pilotes alpha : Richoh GSI-8 Nombre de pilotes alpha sont disponibles via FTP anonyme depuis <url url="ftp://tsx-11.mit.edu: /pub/linux/ALPHA/scsi"> Pilotes en cours de développement, mais qui ne sont pas encore publiquement disponibles, et modifications nécessaires pour faire fonctionner des pilotes existants avec d'autres cartes : DPT PM2001 Les annonces SERONT effectuées quand les pilotes seront disponibles pour alpha tests publics. En attendant, ne faites pas perdre du temps aux développeurs en leur demandant par courrier des dates de sortie, etc. <itemize> <item>NCR53c8x0/7x0 <itemize> <item>Un pilote NCR53c8xx a été développé, et devrait supporter ces circuits au prix de modifications allant de mineures à sévères. <item>NCR53c720 - changements dans la détection, modification de l'assembleur pour utiliser les registres du 720 <item>NCR53c710 - changements dans la détection, modification de l'assembleur, modification du code NCR pour utiliser les interruptions fatales ou les interruptions non fatales générées par GPIO pour la complétion de commande. <item>NCR53c700, NCR53c700-66 - changements dans la détection, dans l'initialisation, modification du code NCR pour ne pas utiliser DSA, modification du code Linux pour gérer les changements de contexte. </itemize> <item>Famille NCR53c9x <item>Qlogic </itemize> Hôtes SCSI qui ne marchent pas : <itemize> <item>Tous adaptateurs parallèle-> SCSI <item> Cartes Rancho SCSI <item> et Grass Roots SCSI. </itemize> Hôtes SCSI qui ne marcheront JAMAIS : <itemize> <item>Cartes DTC non-compatibles Adaptec (y compris les 3270 et 3280). Les informations de programmation peuvent être obtenues en signant un accord de non-diffusion avec DTC. Cela veut dire qu'il serait impossible de distribuer un pilote Linux s'il était écrit, puisque le respect de l'accord impliquerait de ne pas distribuer de source, en violation de la GPL, et le respect de la GPL signifierait la distribution du source, en violation de l'accord. </itemize> Si vous voulez faire tourner Linux sur un matériel non supporté, l'alternative consiste soit à écrire un pilote par vous-même (Eric Youngdale et moi-même sommes en général disposés à répondre aux questions techniques concernant les pilotes SCSI de Linux, soit d'en charger quelqu'un. <sect2>Plusieurs adaptateurs hôtes Avec certains adaptateurs (Cf. <ref id="buyers guide"> : Guide d'achat : comparaison des caractéristiques), on peut utiliser plusieurs adaptateurs hôtes du même type dans le même système. Dans ce cas, c'est généralement celui qui se trouve à l'adresse la plus basse qui est scsi0, celui à l'adresse suivante est scsi1, etc. Dans tous les cas, il est possible d'utiliser plusieurs adaptateurs de types différents, pourvu qu'aucune de leurs adresses n'entre en conflit avec les autres. Les contrôleurs SCSI sont scrutés dans l'ordre spécifié par le tableau builtin_scsi_hosts&lsqb &rsqb de drivers/scsi/hosts.c, l'ordre étant actuellement <enum> <item>Ultrastor <item>Adaptec 151x/152x <item>Buslogic <item>Adaptec 154x <item>Adaptec 174x <item>Future Domain 16x0 <item>Always IN2000 <item>Generic NCR5380 <item>PAS16 <item>Seagate <item>Trantor T128/T130 <item>NCR53c8xx <item>EATA-DMA <item>WD7000 <item>pilote de mise au point. </enum> Dans la plupart des cas (par exemple, si vous n'essayez pas d'utiliser à la fois des pilotes Buslogic et Adaptec), cette liste peut être changée à votre convenance (comme en gardant les mêmes périphériques quand de nouveaux sont ajoutés au système sur un nouveau contrôleur) en déplaçant les entrées individuelles. <sect1>Problèmes habituels <sect2>Time-outs SCSI Assurez-vous que les interruptions sont correctement autorisées, et qu'il n'y a aucun conflit d'IRQ, de DMA ou d'adresse avec d'autres cartes. <sect2>Echec des routines d'autodétection sur les cartes qui se fient au BIOS pour l'autodétection Si votre adaptateur SCSI est l'un des suivants : <itemize> <item>Adaptec 152x <item>Adaptec 151x <item>Adaptec AIC-6260 <item>Adaptec AIC-6360 <item>Future Domain 1680 <item>Future Domain TMC-950 <item>Future Domain TMC-8xx <item>Trantor T128 <item>Trantor T128F <item>Trantor T228F <item>Seagate ST01 <item>Seagate ST02 <item>Western Digital 7000 </itemize> et n'est pas détecté au démarrage, par exemple avec le message <tscreen><verb> scsi : 0 hosts </verb></tscreen> ou qu'un message <tscreen><verb> scsi%d : type </verb></tscreen> n'est pas affiché pour chaque adaptateur SCSI supporté, installé dans le système, votre problème réside peut-être dans la routine d'autodétection qui ne reconnaît pas votre carte. L'autodétection échouera avec les pilotes qui utilisent le BIOS pour l'autodétection s'il est désactivé. Vérifiez que votre BIOS est activé, et n'entre pas en conflit avec d'autres BIOS de périphériques. L'autodétection échouera si la ``signature'' de la carte et/ou l'adresse du BIOS ne correspondent pas à ce qu'attend la routine. Si le BIOS est installé, utilisez le DOS et DEBUG pour trouver une signature qui repèrera votre carte - Par exemple, si votre carte réside en 0xc8000, faites sous DOS <tscreen><verb> debug d c800:0 q </verb></tscreen> et envoyez un message au canal SCSI de la liste de diffusion avec le message ASCII résultant, avec la longueur et l'offset depuis l'adresse de base (0xc8000 dans ce cas). Remarquez que le texte <bf>exact</bf> est requis, et que vous devez fournir les portions hexa et ASCII du texte. Si aucun BIOS n'est installé et que vous utilisez un pilote Adaptec 152x, Trantor T128 ou Seagate, vous pouvez forcer la détection par une option de ligne de commande ou de compilation. Consultez la sous-section appropriée concernant votre carte SCSI ainsi que <ref id="general flaky">. <sect2>Echecs avec les cartes utilisant des E/S mappées en mémoire (Y compris les cartes Trantor T128 et Seagate, mais pas les pilotes Adaptec, Generic NCR5380, PAS16 et Ultrastor) Cela se produit souvent quand les ports d'E/S mappés en mémoire sont incorrectement cachés. L'espace d'adressage de la carte doit être marquée incachable dans le réglage XCMOS. Si ce n'est pas possible, vous devrez entièrement désactiver le cache. Si vous avez spécifié manuellement l'adresse de la carte, souvenez-vous que Linux a besoin de l'adresse réelle de la carte, et non du segment sur 16 bits auquel la documentation peut se référer. Par exemple, 0xc8000 serait correct, 0xc800 ne fonctionnerait pas et provoquerait une corruption de la mémoire. <sect2>``kernel panic : cannot mount root device'' au démarrage sur une disquette contenant un pilote ALPHA Il vous faudra éditer l'image binaire du noyau (avant ou après l'avoir écrit sur la disquette), et modifier quelques champs de deux octets (petit-boutien) afin de garantir son fonctionnement sur votre système. <enum> <item> périphérique de swap par défaut à l'offset 502, doit être mis à 0x00 0x00 <item>taille du disque virtuel en 504, doit être réglé sur la taille de la disquette en Ko : 5,25" = 1200, 3,5" = 1440. Ce qui veut dire que les octets sont <tscreen><verb> 3,5" : 0xA0 0x05 5,25" : 0xB0 0x04 </verb></tscreen> <item>périphérique racine en 508, doit être 0x00 0x00, c'est à dire le périphérique de démarrage. </enum> Ecrivez le fichier sur une disquette par dd ou rawrite. Insérez la disquette dans le premier lecteur, attendez qu'il vous demande le root disk, et insérez celui de votre distribution. <sect2>Installation d'un pilote de périphérique non inclus dans le noyau de la distribution Vous devez commencer avec la version du noyau utilisée par l'auteur du pilote. On trouve en général une référence à cette révision dans la documentation du pilote. On trouve diverses révisions du noyau sur <url url="ftp://nic.funet.fi/pub/OS/Linux/PEOPLE/Linus"> dans linux-version.tar.gz Ils sont également mirrorisés sur tsx-11.mit.edu et d'autres sites. cd /usr/src. Enlevez vos anciens sources Linux, mais si vous voulez en garder une copie de sauvegarde <tscreen><verb> mv linux linux-old </verb></tscreen> Désarchivez <tscreen><verb> gunzip <linux-0.99.12.tar.gz | tar xvfp - </verb></tscreen> Appliquez les patches. Ils sont relatifs à un répertoire du système de fichiers. L'examen des lignes de fichier de sortie dans le fichier de patch permet de le repérer (grep sur ^---) ; par exemple, les patches avec ces lignes <tscreen><verb> --- ./kernel/blk_drv/scsi/Makefile --- ./config.in Wed Sep 1 16:19:33 1993 </verb></tscreen> ont leurs fichiers relatifs à /usr/src/linux. Extrayez les sources des pilotes à l'endroit approprié. Vous pouvez entrer <tscreen><verb> tar tfv patches.tar </verb></tscreen> pour obtenir un listing, puis déplacer les fichiers (les fichiers de pilotes SCSI doivent résider en /usr/src/linux/ kernel/drivers/scsi). Vous pouvez soit entrer dans le répertoire auquel ils sont relatifs et entrer <tscreen><verb> patch -p0 <patch_file </verb></tscreen> soit dire au patch d'enlever des composants de début du chemin. Par exemple, si les fichiers commencent par <tscreen><verb> --- linux-new/kernel/blk_drv/scsi/Makefile </verb></tscreen> et que vous voulez les appliquer dans /usr/src/linux, vous pouvez changer de répertoire vers /usr/src/linux et entrer <tscreen><verb> patch -p1 < patches </verb></tscreen> pour enlever le composant ``linux-new''. Après avoir appliqué les patches, cherchez s'il y a des rejets de patch, qui prendront le nom du fichier rejeté avec un suffixe &num ajouté. <tscreen><verb> find /usr/src/linux/ -name "*#" -print </verb></tscreen> S'il en existe, regardez-les. Dans certains cas, les différences tiendront aux identificateurs RCS et seront sans danger. Dans d'autres cas, il vous faudra appliquer manuellement d'importantes parties. Une documentation sur les fichiers diff et patch sont en dehors du champ d'application de ce document. Voyez également <ref id="canb kernel">: Configuration et construction du noyau <sect2>Installation d'un pilote qui n'a pas de patches Dans certains cas, l'auteur d'un pilote peut ne pas offrir de patches avec les fichiers .c et .h qui composent son pilote, ou les patches peuvent ne s'appliquer qu'à une vieille révision du noyau et ne pas s'intégrer proprement. <enum> <item>Copiez les fichiers .c et .h dans /usr/src/linux/drivers/scsi <item>Ajoutez l'option de configuration Editez /usr/src/linux/config.in, ajoutez une ligne dans la section <tscreen><verb> * SCSI low-level drivers </verb></tscreen> puis ajoutez une variable booléenne de configuration pour votre pilote. Par exemple, <tscreen><verb> bool 'Always IN2000 SCSI support' CONFIG_SCSI_IN2000 y </verb></tscreen> <item>Ajoutez les entrées de makefile Editez /usr/src/linux/drivers/scsi/Makefile et ajoutez une entrée comme <code> ifdef CONFIG_SCSI_IN2000 SCSI_OBS := $(SCSI_OBJS) in2000.o SCSI_SRCS := $(SCSI_SRCS) in2000.c endif </code> avant la ligne <code> scsi.a: $(SCSI_OBJS) </code> du makefile, où le fichier .c est le fichier source que vous avez copié et le fichier .o est le nom de base du fichier .c avec un suffixe .o. <item>Ajoutez les points d'entrée Editez /usr/src/linux/drivers/scsi/hosts.c et ajoutez un #include pour le fichier d'en-tête, conditionné par la définition de préprocesseur CONFIG_SCSI que vous avez ajouté au fichier de configuration. Par exemple, après <code> #ifdef CONFIG_SCSI_GENERIC_NCR5380 #include "g_NCR5380.h" #endif </code> vous pouvez ajouter <code> #ifdef CONFIG_SCSI_IN2000 #include "in2000.h" #endif </code> Vous aurez aussi besoin d'ajouter l'entrée Scsi_Host_Template dans le tableau scsi_hosts&lsqb ]. Regardez dans le fichier .h, et vous devriez trouver un #define qui ressemble à quelque chose comme ceci : <code> #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} </code> Prenez le nom de la définition du préprocesseur, et ajoutez-le dans le tableau scsi_hosts&lsqb ], conditionné par la définition du symbole de préprocesseur que vous avez utilisé dans le fichier de configuration. Par exemple, après <code> #ifdef CONFIG_SCSI_GENERIC_NCR5380 GENERIC_NCR5380, #endif </code> vous pouvez ajouter <code> #ifdef CONFIG_SCSI_IN2000 IN2000, #endif </code> </enum> Voyez aussi <ref id="canb kernel">: Configuration et construction du noyau <sect1>Adaptec 152x, 151x, Sound Blaster 16 SCSI, SCSI Pro, Gigabyte, et autres produits basés sur AIC 6260/6360 (Standard) <descrip> <tag/Configurations supportées :/<descrip> <tag/Adresses du BIOS:/0xd8000, 0xdc000, 0xd0000, 0xd4000, 0xc8000, 0xcc000, 0xe0 000, 0xe4000. <tag/Ports:/0x140, 0x340 <tag/IRQ:/9, 10, 11, 12 <tag/DMA:/ non utilisé. <tag/IO:/ port mapped <tag/Autodétection:/Fonctionne avec de nombreuses cartes comportant un BIOS. Toutes les autres cartes, y compris l'Adaptec 1510 et la Sound Blaster 16 SCSI, doivent utiliser la ligne de commande du noyau ou une option de compilation. <tag/Forçage d'autodétection:/Aucun <tag/Compilation:/Définir PORTBASE, IRQ, SCSI_ID, RECONNECT de façon appropriée, voir Définitions <tag/ligne de commande du noyau/aha152x=< PORTBASE> ,< IRQ> ,< SCSI-ID> , < RECONNECT> Généralement, SCSI-ID sera à 7 et RECONNECT différent de zéro. Pour forcer la détection à 0x340, IRQ 11, et SCSI-ID 7, en permettant la déconnexion/reconnexion, vous devez utiliser l'option de ligne de commande suivante : <tscreen><verb> aha152x=0x340,11,7,1 </verb></tscreen> <tag/Problèmes dus à l'ancienneté, résolus par mise à jour : /Le pilote échoue avec des cartes VLB. Il existait un problème de temporisation avec les noyaux antérieurs à la révision 1.0.5. <descrip> <tag/Définitions :/<descrip> <tag/AUTOCONF :/utiliser la configuration que renvoie le contrôleur (uniquement 152x) <tag/IRQ :/forcer le canal d'interruption (9,10,11 or 12) (défaut 11) <tag/SCSI_ID :/forcer le scsiid de AIC-6260 (0-7) (défaut 7) <tag/RECONNECT :/forcer la déconnexion/reconnexion/multiple <tag/commande en attente :/mettre à non-zéro pour activer, zéro pour désactiver. <tag/DONT_SNARF :/Ne pas enregistrer les ports (pl12 et en-dessous) <tag/SKIP_BIOSTEST :/Ne pas tester la signature du BIOS (AHA-1510 ou BIOS désactivé) <tag/PORTBASE :/Forcer la base des ports. Ne pas essayer de détecter </descrip> </descrip> </descrip> </descrip> <! ---------- J'ai rajoute un / descript (?) JZ ------------ > <sect1>Adaptec 154x, AMI FastDisk VLB, Buslogic, DTC 329x (Standard) <descrip> <tag/Configurations supportées :/<descrip> <tag/Ports :/0x330 et 0x334 <tag/IRQs :/9, 10, 11, 12, 14, 15 <tag/Canaux DMA :/5, 6, 7 <tag/IO :/port mapped, bus master </descrip> <tag/Autodétection :/fonctionne avec toutes les configurations supportées, ne demande pas de BIOS installé. <tag/Forçage d'autodétection :/ aucun <tag/Note :/Les cartes sans suffixe, ainsi que les premières cartes dont le suffixe est 'A' ne supportent pas le scatter/gather, et ne fonctionnent donc pas. On peut cependant les faire plus ou moins fonctionner si AHA1542_SCATTER est mis à 0 dans drivers/scsi/aha1542.h. <tag/Note :/Buslogic fabrique une série de cartes compatibles par logiciel avec l'Adaptec 1542, et celles-ci existent sous les formes ISA, VLB et EISA. <tag/Problèmes dûs à l'ancienneté, résolus par mise à jour : <enum> <item>Les révisions du noyau Linux antérieures à .99.10 ne supportent pas la révision 'C'. <item>Les révisions du noyau Linux antérieures à .99.14k ne supportent pas les options de la révision 'C' concernant <itemize> <item>le support du BIOS pour le mapping étendu des disques > 1 Go <item>Support du BIOS pour > 2 disques <item>Support du BIOS pour l'autoscan du bus SCSI </itemize> <item> Les révisions du noyau Linux antérieures à la .99.15e ne supportent pas la 'C' avec le support du BIOS activé pour > 2 disques et le support du BIOS désactivé pour le mapping étendu des disques > 1Go. <item> Les révisions du noyau Linux antérieures à la .99.14u ne supportent pas les révisions 'CF' de la carte. <item> Les révisions du noyau Linux antérieures à la 1.0.5 ont un effet de compétition (race condition) quand plusieurs périphériques sont raccordés en même temps. </enum> <tag/Problèmes habituels :/<enum> <item>On obtient des erreurs inattendues avec une carte 154xC ou 154xCF. Les premiers exemplaires des cartes 154xC avaient un slew rate important sur l'un des signaux SCSI, ce qui donnait des réflexions de signal quand des câbles d'impédance incorrecte étaient utilisés. Les nouvelles cartes ne se comportent pas vraiment mieux, et souffrent également d'une extrême sensibilité au câblage et à la terminaison. Voyez également Problèmes habituels numéros 2 et 3 et la section <ref id="common problems">: Problèmes habituels, et la section <ref id="general flaky">: Défaillance générale. <item> Erreurs inattendues avec une 154xC ou 154x connectée à la fois à des périphériques internes et externes. Il s'agit probablement d'un problème de terminaison. Il faut désactiver le switch 1 pour utiliser l'option logicielle de désactivation de terminaison de l'adaptateur hôte. Voyez également Problèmes habituels numéros 2 et 3 et la section <ref id="common problems">: Problèmes habituels, et la section <ref id="general flaky">: Défaillance générale. <item>Le sous-système SCSI se bloque complètement. Il existe des cas dans lesquels les bloquages semblent se produire quand plusieurs périphériques sont simultanément en activité. Dans ce cas, vous pouvez essayer de contacter le fabricant des périphériques afin de voir si des mises à jour de logiciel embarqué susceptibles de corriger le problème sont disponibles. En dernier recours, vous pouvez rentrer dans aha1542.h et changer AHA1542_MAILBOX en 1. Ceci vous limitera à une seule commande en suspens à la fois sur le bus SCSI, et peut améliorer la situation. Cette solution peut se révéler problématique si vous utilisez des lecteurs de bandes ou des CD-ROM lents sur le bus. Voyez également Problèmes habituels numéros 2 et 3 et la section <ref id="common problems">: Problèmes habituels, la section <ref id="general flaky">: Défaillance générale, et la section <ref id="scsi lockup"> : Blocages SCSI. <item> Un 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 destinées au support du mapping étendu pour les disques > 1Go, le support de plus de deux disques, et pour l'autoscan du bus. Ou installez une version de Linux supérieure ou égale à .99.14k. </enum> </descrip> <sect1>Adaptec 174x <descrip> <tag/Configurations supportées :/<descrip> <tag/Slots :/ 1-8 <tag/Ports :/ carte EISA, sans objet <tag/IRQs :/ 9, 10, 11, 12, 14, 15 <tag/Canaux DMA :/ carte EISA, sans objet <tag/IO :/ port mapped, bus master </descrip> <tag/Autodétection :/ fonctionne avec toutes les configurations supportées <tag/Forçage d'autodétection :/ aucun <tag/Note :/ Cette carte n'est plus fabriquée par Adaptec. <tag/Problèmes habituels :/<enum> <item> 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. Les cartes tournant en mode 1542 standard ne sont pas supportées. </enum> </descrip> <sect1>Adaptec 274x, 284x, 294x (Standard) Des révisions plus récentes peuvent être trouvées sur <url url="ftp://ftp.cpsc.ucalgary.ca /pub/systems/linux/aha274x/aha274x-pre-alpha.tar.gz"> Configurations supportées : <descrip> <tag/274x:/<descrip> <tag/Slots EISA :/1-12 <tag/IRQs :/Toutes <tag/IO :/port mapped, bus master </descrip> <tag/284x :/<descrip> <tag/Ports :/Tous <tag/IRQs :/Toutes <tag/Canaux DMA :/Tous </descrip> <tag/294x/PCI <tag/Note :/Le BIOS DOIT être activé <tag/Note :/Le canal B des cartes 2742AT est ignoré. </descrip> <sect1>Toujours IN2000 (ALPHA) Pilote ALPHA disponible sur <url url="ftp://tsx-11.mit.edu/pub/linux/ALPHA/SCSI/in2000">. Le pilote est in2000.tar.z, le noyau bootable est zImage <descrip> <tag/Port :/ 0x100, 0x110, 0x200, 0x220 <tag/IRQs :/10, 11, 14, 15 <tag/DMA :/inutilisé <tag/IO:/port mapped <tag/Autodétection :/ BIOS non requis <tag/Forçage d'autodétection :/ aucun <tag/Problèmes habituels :/<enum> <item>On connaît certains problèmes sur les systèmes qui ont des disques IDE et avec le swapping. </enum> </descrip> <sect1>EATA: DPT Smartcache, Smartcache Plus, Smartcache III (Standard) <descrip> <tag/Cartes supportées :/Toutes celles qui supportent le protocole EATA-DMA (pas la PM2001). <descrip> <tag/DPT Smartcache :/ PM2011 PM2012A PM2012B <tag/Smartcache III :/ PM2021 PM2022 PM2024 PM2122 PM2124 PM2322 <tag/SmartRAID :/PM3021 PM3222 PM3224 nombre de ces cartes sont aussi disponibles en version SKXXXX, qui sont également suportées. </descrip> <tag/Configuration supportées :/<descrip> <tag/Slots :/ Tous <tag/Ports :/ Tous <tag/IRQs :/ Toutes, level & edge triggered <tag/Canaux DMA :/ ISA ALL, EISA/PCI sans objet <tag/IO :/ port mapped, bus master <tag/Canaux SCSI :/ Tous <tag/Autodétection :/ fonctionne avec toutes les configurations supportées <tag/Compilation :/diskgeometry dans eata_dma.h pour les géométries inhabituelles provenant du vieil utilitaire DPTFMT. La dernière version du pilote EATA-DMA et un disque de démarrage Slackware devrait être disponible sur : <url url="ftp://ftp.uni-mainz.de/pub/Linux/arch/i386/system/EATA/"> <tag/Problèmes habituels :/<enum> <item> Le pilote IDE détecte l'interface ST-506 de la carte EATA. <enum> <item>Cela ressemblera à l'un des deux exemples suivants : <tscreen><verb> hd.c: ST-506 interface disk with more than 16 heads detected, probably due to non-standard sector translation. Giving up. (disk &percnt d: cyl=&percnt 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 </verb></tscreen> Si le pilote IDE se sent vraiment mal, c'est à dire que vous ne pouvez pas accéder à votre (vrai) matériel IDE, changez le port d'E/S et/ou l'IRQ de la carte EATA. <item> Si le pilote IDE trouve du matériel qu'il peut gérer, par exemple des disques durs d'une capacité <=504 Mo, il allouera le port d'E/S et l'IRQ ce qui fait que le pilote EATA ne pourra pas les utiliser. Dans ce cas, changez également le port d'E/S et l'IRQ (!= 14, 15). </enum> <item> Certaines vieilles cartes SK2011 ont un logiciel embarqué défectueux. Contactez le support clientèle pour obtenir une mise à jour. </enum> </descrip> </descrip> <sect1>Future Domain 16x0 avec circuit TMC-1800, TMC-18C30, TMC-18C50 ou TMC- 36C70. <descrip> <tag/Configurations supportées :/<descrip> <tag/BIOS :/2.0, 3.0, 3.2, 3.4, 3.5 <tag/Adresses du BIOS :/0xc8000, 0xca000, 0xce000, 0xde000 <tag/Ports :/0x140, 0x150, 0x160, 0x170 <tag/IRQs :/3, 5, 10, 11, 12, 14, 15 <tag/DMA :/inutilisé <tag/IO:/port mapped </descrip> <tag/Autodétection :/fonctionne avec toutes les configurations supportées, requiert un BIOS installé <tag/Forçage d'autodétection :/aucun <tag/Problèmes dus à l'ancienneté, résolus par mise à jour :/<enum> <item>Les versions anciennes ne supportent pas le circuit TMC-18C50, et échoueront avec les nouvelles cartes. <item>Les versions anciennes ne disposent pas des signatures les plus courantes pour l'autodétection. <item>Les versions antérieures à celle de Linux 1.0.9 et 1.1.6 ne supportent pas le nouveau circuit SCSI ou le BIOS 3.4. </enum> </descrip> <sect1>NCR5380 / T130B générique <descrip> <tag/Configurations supportées et non supportées :/ <descrip> <tag/Ports:/tous <tag/IRQs:/toutes <tag/DMA:/inutilisé <tag/IO:/port mapped </descrip> <tag/Autodétection :/aucune <tag/Forçage d'autodétection :/<descrip> <tag/Compilation :/Definir GENERIC_NCR5380_OVERRIDE en tant que tableau de n-uplets avec port, irq, dma, type de carte - par exemple <code> #define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}} </code> pour une carte NCR5380 avec un port 330, IRQ 5. <code> #define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}} </code> pour une T130B avec un port 0x350. Les anciennes versions du code éliminent l'entrée BOARD_* . Les IRQ symboliques IRQ_NONE and IRQ_AUTO peuvent être utilisées. <tag/Ligne de commande du noyau :/<itemize> <item>ncr5380=port,irq <item>ncr5380=port,irq,dma <item>ncr53c400=port,irq </itemize> 255 peut être utilisé pour aucune IRQ, 254 pour autodétection d'IRQ. </descrip> <tag/Problèmes habituels :/<enum> <item>Utilisation de la carte T130B avec l'ancien pilote NCR5380 générique (release 6 pré-publique) qui ne supporte pas l'option de ligne de commande ncr53c400. Les registres compatibles NCR5380 se situent à l'offset 8 depuis l'adresse de base. Si votre adresse est 0x350, il vous faut donc utiliser <tscreen><verb> ncr53480=0x358,254 </verb></tscreen> sur la ligne de commande du noyau. </enum> <tag/Problèmes dûs à l'ancienneté, résolus par mise à jour :/<enum> <item>Le noyau se bloque pendant un accès disque avec une T130B ou d'autres cartes NCR53c400 Les versions de la release 6 pré-publique du pilote de la NCR5380 générique ne supporte pas les interruptions sur ces cartes. Mettre à jour. </enum> <tag/Notes :/le pilote générique ne supporte pas encore le DMA, ni le pseudo-DMA. </descrip> <sect1>NCR53c8xx (Standard) <descrip> <tag/Configurations supportées et non supportées :/<descrip> <tag/Adresses de base :/Toutes <tag/IRQs :/Toutes <tag/Canaux DMA :/PCI, sans objet <tag/IO:/port mapped, bus mastering </descrip> <tag/Autodétection :/requiert un BIOS PCI et en utilise les routines pour rechercher les périphériques et lire l'espace de configuration Le pilote utilise les valeurs préprogrammées dans certains registres à l'initialisation, un BIOS doit donc être installé. <tag/Problèmes dûs à l'ancienneté, résolus par mise à jour :/<enum> <item> Certaines versions de Linux avaient un problème avec le swapping. Voir la section <ref id="swap hangs"> : Le système plante au swapping <item>Les vieilles versions de Linux ne reconnaissaient pas les cartes ...815 et ...825. </enum> <tag/Problèmes habituels :/<enum> <item>De nombreux utilisateurs ont rencontré des problèmes où le circuit fonctionnait correctement sous DOS, mais échouait sous Linux avec un timeout sur le test 1 en raison d'une interruption perdue. Il s'agit souvent d'une inadéquation entre le jumper matériel de l'IRQ pour un périphérique sur la carte mère et la valeur présente dans la CMOS. Il peut aussi s'agir d'un INTB, INTC ou INTD PCI sélectionné sur une carte PCI dans un système qui ne supporte que l'INTA PCI. Enfin, PCI devrait utiliser des interruptions déclenchées par le niveau (level-sensitive) plutôt que par le front du signal (edge-triggered). Vérifiez que votre carte est réglée pour être level-sensitive, et en cas d'échec, essayez edge-triggered car votre système peut être défectueux. Ce problème est fréquent avec certaines cartes-mères Viglen, dont les réglages de cavaliers d'IRQ ne correspondent PAS à ce qui est indiqué dans la documentation. On m'a dit que l'IRQ 5 est en fait l'IRQ 9, ceci dépendant en fait de votre système. <item>Des blocages se produisent en utilisant en même temps un S3928P, X11 et le circuit NCR en même temps. Il existe des dysfonctionnements dans (au moins) certains circuits S3928P. A éviter. <item>Un message s'affiche au démarrage, disant que l'I/O mapping a été désactivé parce que les bits 0..1 de l'adresse de base indiquent un ``non I/O mapping'' Il s'agit là d'un bug du BIOS sur certaines machines qui se solde par des lectures de dwords des registres de configuration renvoyant les words de 16 bits échangés. <item>Certains systèmes ont des problèmes si le ``write posting'' PCI ou le tamponnage CPU->PCI sont activés. En cas de problème, désactivez ces options. <item>Certains systèmes avec le logiciel NCR SDMS sur un ROM BIOS embarqué et dans le BIOS système sont incapable de booter le DOS. La désactivation de l'image en premier lieu devrait régler ce problème. <item>Certains systèmes possèdent des BIOS complètement défectueux. N'envoyez aucun rapport de bug avant d'être sûr de disposer de la dernière ROM du fournisseur. <itemize> <item>Les cartes Intel P90 requièrent la révision 1.00.04.AX1 </itemize> </enum> </descrip> <sect1>Seagate ST0x/Future Domain TMC-8xx/TMC-9xx <descrip> <tag/Configurations supportées et non supportées : /<descrip> <tag/Adresses de base :/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000 <tag/IRQs :/ 3, 5 <tag/DMA :/inutilisé <tag/IO:/memory mapped </descrip> <tag/Autodétection :/ne recherche que l'adresse, l'IRQ est censée être 5, demande un BIOS installé. <tag/Forçage d'autodétection :/ <descrip> <tag/A la compilation :/Définir OVERRIDE par l'adresse de base, CONTROLLER par FD ou SEAGATE selon le cas, et IRQ par l'IRQ. <tag/ligne de commande du noyau :/<tt>st0x=adresse,irq ou tmc8xx=adresse,irq</tt> (ne fonctionne que pour .99.13b et au-delà) </descrip> <tag/Problèmes dus à l'ancienneté, résolus par mise à jour :/<enum> <item> Les versions antérieures à celle du noyau .99.12 de Linux avaient un problème de handshaking avec certains périphériques lents. Voici ce qui se passe quand vous écrivez des données sur le bus <enum> <item>Ecrire l'octet sur le registre de données, qui est asserted au bus <item>time_remaining = 12us <item>attendre tant que time_remaining > 0 et que REQ n'est pas asserted <item>si time_remaining > 0, assert ACK <item>attendre tant que time_remaining > 0 et que REQ est asserted <item>deassert ACK </enum> Le problème se produit sur des périphériques lents, qui exécutent les commandes pendant la lecture, où le handshake REQ/ACK prend plus de 12us ; REQ ne passe pas à false alors que c'est ce à quoi s'attend le pilote, qui se met à envoyer plusieurs octets de données à chaque impulsion REQ. <item>Sous Linux .99.12, un bug a été introduit quand j'ai corrigé le code d'arbitrage, provoquant ainsi des échecs de sélections sur certains systèmes. Problème réglé avec .99.13. </enum> </descrip> <sect2>Problèmes habituels <sect3>Timeouts de commande Ceux-ci se produisent quand Linux essaye de lire la table de partition ou au cours d'autres accès aux disques. La carte est livrée réglée par défaut pour MS-DOS, c'est à dire que les interruptions sont désactivées. Pour les réactiver sur la Seagate, utilisez le cavalier W3 (ST01) ou JP3 (ST02) et connectez les broches F-G pour sélectionner l'IRQ 5. <sect3> Certains périphériques ne fonctionnent pas Le pilote ne peut pas gérer certains périphériques, en particulier les lecteurs de bandes et les CD-ROM bas de gamme. La Seagate relie le handshaking REQ/ACK du bus SCSI aux signaux IO CHANNEL READY et (optionnellement) OWS du bus du PC. Elle ne vous dit malheureusement pas quand le compteur du chien de garde s'arrête, et il n'y a pas moyen d'être sûr que REQ est descendu, et vous pouvez finir par voir un pulse REQ comme plusieurs pulses. La solution implique l'utilisation d'une courte boucle destinée à voir si REQ est descendu, avec un timeout au cas où on n'attrape pas la transition due à une interruption, etc. Il en résulte une dégradation des performances, et il n'est donc pas désirable de l'appliquer à tous les périphériques SCSI. Elle est sélectionnée pour chaque périphérique avec le champ ``borken'' du périphérique SCSI concerné dans le tableau scsi_devices. En cas de problèmes, vous devriez essayer d'ajouter votre périphérique à la liste de ceux pour lesquels borken n'est pas remis à zéro (actuellement, uniquement les CD-ROM TENEX). <sect3>Future Domain ne fonctionne pas Une carte Future Domain (comme les 840, 841, 880 et 881) ne fonctionne pas. Quelques cartes Future Domain utilisent le mapping de registre de la Seagate, et les bits MSG et CD du registre d'état sont échangés. Il faut éditer seagate.h, échanger les définitions de STAT_MSG et de STAT_CD, et recompiler le noyau avec CONTROLLER défini en SEAGATE, IRQ et OVERRIDE étant correctement spécifiés. <sect3>HDIO_REQ ou HDIO_GETGEO échouent Des messages d'erreurs s'affichent pendant le fdisk du disque, indiquant que les ioctl HDIO_REQ ou HDIO_GETGEO ont échoué... Il faut préciser les têtes, les secteurs et les cylindres. Vous pouvez le faire depuis le menu de fonctions supplémentaires. Voyez la section <ref id="partitioning"> : Partitionnement <sect3>fdisk échoue Après avoir spécifié manuellement la géométrie du disque, les tentatives ultérieures de lectures de la table de partition se soldent par des messages d'erreur du type : limite de partition hors d'une limite de cylindre, les limites physiques ne concordent pas (partition boundary not on a cylinder boundary, physical and logical boundaries don't match), etc. Voir la section <ref id="partitioning"> : Partitionnement <sect3> A fonctionné un temps, mais plus maintenant Certains systèmes qui fonctionnaient avant la .99.13 échouent avec les nouvelles versions de Linux. Les anciennes versions assignaient les registres CONTROL et DATA dans un ordre différent de celui de la documentation, ce qui plantait certains systèmes. Les nouvelles versions assignent correctement les registres, mais cela plante d'autres systèmes. Le code de seagate.c ressemble actuellement à ceci : <code> cli(); DATA = (unsigned char) ((1<<target) | (controller_type == SEAGATE ? 0x80 : 0x40)); CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL | (reselect ? CMD_ATTN : 0); sti(); </code> Il se peut que le changer en <code> cli(); CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL | (reselect ? CMD_ATTN : 0); DATA = (unsigned char) ((1 <<target) | (controller_type == SEAGATE ? 0x80 : 0x40)); sti() </code> résolve votre problème. <sect2>Définitions FAST ou FAST32 utiliseront les transferts aveugles chaque fois que possible. ARBITRATE fera arbitrer le bus par l'adaptateur hôte pour une meilleure compatibilité SCSI-II, au lieu de se contenter d'attendre BUS FREE pour faire son boulot. Devrait nous permettre une commande par Lun quand j'intégrerai ma réorganisation dans les sources de distribution. SLOW_HANDSHAKE permettra la compatibilité avec des périphériques défectueux qui ne pratiquent pas un handshake assez rapide (comme certains CD-ROM) pour le code Seagate. SLOW_RATE=x, x étant un nombre, vous permettra de spécifier une vitesse de transfert par défaut si le handshaking ne fonctionne pas correctement. <sect1>PAS16 SCSI <descrip> <tag/Configurations supportées et non supportées:/ <descrip> <tag/Ports :/0x388, 0x384, 0x38x, 0x288 <tag/IRQs :/10, 12, 14, 15 <tag/IMPORTANT :/ Les IRQ DOIVENT être différentes de celles utilisées pour la partie son de la carte. <tag/DMA :/inutilisé pour la partie SCSI de la carte <tag/IO :/port mapped </descrip> <tag/Autodétection :/ne requiert pas de BIOS <tag/Forçage d'autodétection :/ <descrip> <tag/Compilation :/ Definir PAS16_OVERRIDE comme un tableau de n-uplets de port,irq. Par exemple, <code> #define PAS16_OVERRIDE {{0x388, 10}} </code> pour une carte en port 0x388, IRQ 10. <tag/ligne de commande du noyau :/ pas16=port,irq <tag/Definitions :/ <itemize> <item>AUTOSENSE - si défini, REQUEST SENSE sera automatiquement exécuté pour les commandes qui renvoient un statut CHECK CONDITION. <item>PSEUDO_DMA - active le pseudo-DMA matériel, devrait donner une amélioration des performances de l'ordre de 3-4X par rapport aux E/S pollées. <item>PARITY - active la vérification de parité. Non supporté. <item>SCSI2 - active le support du tagged queuing SCSI-II. Non testé. <item>UNSAFE - laisse les interruptions activées pendant les transferts pseudo-DMA. Ne l'utiliser que si vous avez un problème de caractères perdus pendant des communications à haute vitesse, et même dans ce cas, vous vous en sortirez mieux en modifiant transfersize. <item>USLEEP - active le support des périphériques qui ne se déconnectent pas. Non testé. </itemize> </descrip> <tag/Problèmes habituels :/ <enum> <item>Timeouts de commandes, échecs, etc. Vous devez installer les patches NCR5380 que j'ai posté sur le net il y a quelque temps, qui devraient être intégrés à une future release alpha. Ces patches corrigent un effet de compétition dans les cores de pilotes NCR5380, ainsi que le support de plusieurs périphériques sur les cartes à base de NCR5380. Si cela échoue, vous devez désactiver l'option PSEUDO_DMA en changeant la ligne #define PSEUDO_DMA dans les pilotes drivers/scsi/pas16.c en #undef PSEUDO_DMA. Remarquez que cette solution ne doit être envisagée qu'en dernier recours, car elle induira une sévère dégradation des performances. </enum> </descrip> <sect1>Trantor T128/T128F/T228 <descrip> <tag/Configurations supportées et non supportées :/ <descrip> <tag/Adresses de base :/0xcc000, 00xc8000, 0xdc000, 0xd8000 <tag/IRQs :/ <itemize> <item> aucune, 3, 5, 7 (toutes cartes) <item> 10, 12, 14, 15 (T128F seulement) </itemize> <tag/DMA :/inutilisé <tag/IO :/memory mapped </descrip> <tag/Autodétection :/ fonctionne pour toutes les configurations supportées, requiert un BIOS installé. <tag/Forçage d'autodétection :/ <descrip> <tag/Compilation:/ Définit T128_OVERRIDE en tant que tableau de n-uplets adresse,irq. Par exemple <code> #define T128_OVERRIDE {{0xcc000, 5}} </code> Pour une carte à l'adresse 0xcc000, IRQ 5. Les IRQs symboliques IRQ_NONE et IRQ_AUTO peuvent être utilisées. <tag/ligne de commande du noyau :/ t128=adresse,irq -1 peut être utilisé pour aucune irq, -2 pour l'autodétection. <tag/Définitions :/ <descrip> <tag/AUTOSENSE/ s'il est défini, REQUEST SENSE sera exécuté automatiquement pour les commandes qui renvoient un statut CHECK CONDITION. <tag/PSEUDO_DMA/ active le matériel pseudo-DMA, devrait donner une amélioration des performances de l'ordre de 3-4X par rapport aux E/S pollées. <tag/PARITY/ active la vérification de parité. Non supporté. <tag/SCSI2/ active le support du tagged queuing SCSI-II. Non testé. <tag/UNSAFE/ laisse les interruptions activées pendant les transferts pseudo-DMA. Ne l'utiliser que si vous avez un problème de caractères perdus pendant des communications à haute vitesse, et même dans ce cas, vous vous en sortirez mieux en modifiant transfersize. <tag/USLEEP/ active le support des périphériques qui ne se déconnectent pas. Non testé. </descrip> </descrip> <tag/Problème habituels :/ <enum> <item>Timeouts de commandes, échecs, etc. Vous devez installer les patches NCR5380 que j'ai posté sur le net il y a quelque temps, qui devraient être intégrés à une future release alpha. Ces patches corrigent un effet de compétition dans les cores des pilotes NCR5380, ainsi que le support de plusieurs périphériques sur les cartes à base de NCR5380. Si cela échoue, vous devez désactiver l'option pseudo_DMA en changeant la ligne #define PSEUDO_DMA dans les pilotes drivers/scsi/pas16.c en #undef PSEUDO_DMA. Remarquez que cette solution ne doit être envisagée qu'en dernier recours, car elle induira une sévère dégradation des performances. </enum> </descrip> <sect1>Ultrastor 14f (ISA), 24f (EISA), 34f (VLB) <descrip> <tag/Configurations supportées : / <descrip> <tag/Ports :/0x130, 0x140, 0x210, 0x230, 0x240, 0x310, 0x330, 0x340 <tag/IRQs :/10, 11, 14, 15 <tag/Canaux DMA :/ 5, 6, 7 <tag/IO :/ port mapped, bus master </descrip> <tag/Autodétection :/ ne fonctionne pas pour les cartes au port 0x310, BIOS non requis. <tag/Forçage d'autodétection :/ uniquement à la compilation, définir PORT_OVERRIDE. <tag/Problèmes habituels :/ <enum> <item>L'adresse 0x310 n'est pas supportée par le code d'autodétection, et peut entraîner des conflits si le réseau est activé. Utilisez une adresse différente. <item> L'utilisation d'une Ultrastor à l'adresse 0x330 peut provoquer un blocage du système quand les pilotes de cartes son entrent en autodétection. Utilisez une adresse différente. <item>De nombreux autres pilotes testent diverses adresses de façon dangereuse ; si vous rencontrez des problèmes avec la détection ou que le système se bloque au démarrage, essayez une autre adresse. 0x340 est une adresse recommandée, dont on sait qu'elle fonctionne. <item> Linux ne détecte pas de périphérique SCSI, mais indique que le disque dur sur une carte Ultrastor SCSI est un disque normal, et le pilote de disque dur refuse de le supporter. Notez que si cela se produit, vous obtiendrez probablement le message : <tscreen><verb> 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) </verb></tscreen> Si tel est le cas, vous faites tourner une carte Ultrastor en mode d'émulation WD1003. Il vous faut <enum> <item> Basculer l'Ultrastor en mode natif. Il s'agit là de l'action recommandée, car le pilote SCSI est notablement plus rapide que le pilote IDE, surtout en installant les patches de clustered read/write. Certains utilisateurs ont atteint plus de 2 Mo/sec sur le système de fichiers en utilisant ces patches. Remarquez que ceci sera nécessaire si vous désirez utiliser un disque non dur, ou plus de deux disques durs sur la Ultrastor. <item>Utiliser l'option de ligne de commande : <tscreen><verb> hd=cylindres,têtes,secteurs </verb></tscreen> pour forcer les réglages par défaut pour démarrer, en gardant le nombre de cylindres < =2048, le nombre de têtes <= 16, et le nombre de secteurs <= 255 pour que cylindres * têtes * secteurs soit le même pour les deux géométries. Vous devrez également spécifier la géométrie du disque en lançant fdisk sous Linux. Dans le cas contraire, des entrées de partitions incorrectes seront écrites, qui fonctionneront correctement sous Linux mais échoueront sous MS- DOS qui se sert des entrées de cylindres/têtes/secteurs dans la table. Une fois Linux lancé, on peut éviter de devoir démarrer à la main en recompilant le noyau avec une macro correctement définie dans include/linux/config.h. </enum> </enum> </descrip> <sect1>Western Digital 7000 <descrip> <tag/Configurations supportées :/ <descrip> <tag/Adresses du BIOS :/0xce000 <tag/Ports :/0x350 <tag/IRQs :/15 <tag/Canaux DMA :/6 <tag/IO:/port mapped, bus master </descrip> <tag/Autodétection :/ requiert un BIOS installé <tag/Problèmes habituels :/ <enum> <item>Il existe plusieurs révisions de circuit et de logiciel embarqué. Il apparaît que les cartes de révision 3 ne fonctionnent pas, les cartes de révision 5 fonctionnent, les circuits sans suffixe ne fonctionnent pas, les circuits avec un suffixe 'A' fonctionnent. <item>La carte supporte quelques adresses qui ne sont pas sur la liste des adresses supportées. Si vous vous trouvez dans cette situation, utilisez l'une des adresses suportées et soumettez un rapport comme indiqué en section 2, ``Comptes-rendus de bogues''. </enum> </descrip> <sect>Disques Cette section fournit des informations spécifiques aux périphériques disques. <sect1>Matériel supporté et non supporté Tous les périphériques SCSI ayant une taille de bloc de 256, 512 ou 1024 octets devraient fonctionner. Les autres tailles ne fonctionneront pas (bien qu'il soit souvent possible de corriger cela en changeant les tailles de bloc et/ou de secteur en utilisant la commande MODE SELECT SCSI). La taille de secteur se réfère au nombre d'octets de données alloués par secteur sur un périphérique ; les CD-ROM utilisent par exemple une taille de secteur de 2048 octets. La taille de bloc se réfère à la taille des blocs logiques utilisés pour s'interfacer avec le périphérique. Bien qu'elle soit généralement identique à la taille de secteur, certains périphériques regroupent plusieurs petits secteurs physiques (comme 256 octets dans le cas des lecteurs Syquest 55 Mo) en blocs logiques plus grands, ou vice versa (comme les blocs de 512 octets sur les lecteurs de CD-ROM compatibles SUN). Les médias extractibles, comme les lecteurs Bernouilli, floptical et MO fonctionnent. En théorie, les disques d'une taille allant jusqu'à un téra-octet doivent fonctionner. Il n'y a absolument aucun problème avec les petits disques de 9 Go. <sect1>Problèmes habituels <sect2>Message cylindre > 1024. Au moment du partitionnement, un message s'affiche, du type ``cylinder > 1024'', ou vous êtes incapables de démarrer à partir d'une partition comprenant un cylindre logique dépassant le cylindre 1024. Il s'agit d'une limitation du BIOS. Voir la section <ref id="geometry and parts"> : Géométrie des disques pour une explication. <sect2>Il vous est impossible de partitionner ``/dev/hd* '' Les /dev/hd* ne sont pas des périphériques SCSI, utilisez des /dev/sd*. Voir la section <ref id="device files">: Fichiers périphériques, et la section <ref id="geometry and parts">, Géométrie des disques pour les noms de périphériques la procédure corrects. <sect2>Impossible d'éjecter le support d'un périphérique extractible. Linux essaye de bloquer la porte du lecteur quand un support est chargé afin d'empêcher la corruption du système de fichier due à un changement de support inopiné. Faites un umount de vos disques avant de les éjecter. <sect2>Impossible de démarrer par LILO depuis un disque SCSI Dans certains cas, le pilote SCSI et le BIOS sont en désaccord sur la géométrie correcte à utiliser, et LILO plante après avoir affiché 'LI' au démarrage et/ou d'autres problèmes. La solution consiste à déterminer la géométrie du disque utilisée sous DOS, et en faire une entrée pour votre disque dans /etc/lilo/disktab. (NdT : cette façon de faire est obsolète, voir /usr/doc/lilo/README). Vous pouvez aussi utiliser l'option de fichier de configuration ``linear''. <sect2>fdisk répond par <tscreen><verb> You must set heads sectors and cylinders. You can do this from the extra functions menu. </verb></tscreen> et la géométrie du disque est ``oubliée'' quand fdisk est relancé. Voir la section <ref id="partitioning"> : Partitionnement <sect2>Un seul disque est détecté sur une carte bridge où plusieurs disques sont connectés. Linux ne recherchera pas les LUN après zéro sur les périphériques SCSI antérieurs à la norme ANSI SCSI révision 1. Si vous voulez que des périphériques soient reconnus sur d'autres LUN, il vous faudra modifier drivers/scsi/scsi.c:scan_scsis(). <sect2><heading><label id="swap hangs">Le système se bloque au swap </> Il semble que ceci ait été corrigé, essayez de passer à la 1.1.38. <sect2>Les disques Conner CFP1060S se corrompent Il s'agit d'un bug du microcode de la lecture en avance et du cache. <tscreen> <verb> From Soenke Behrens of Conner tech. support: Ces dernières semaines, nous avons eu plusieurs appels de clients affirmant avoir rencontré de graves problèmes avec les disques SCSI Conner CFP1060 1Go sous le système d'exploitation Linux. Les symptômes consistaient en systèmes de fichiers corrompus (inodes endommagés) indiqués par e2fsck à chaque démarrage système et d'autres erreurs similaires. Il existe maintenant une correction disponible pour les clients possédant un CFP1060x (révisions de microcode 9WA1.62/1.66/1.68) et Linux. Pour appliquer la mise à jour, vous aurez besoin d'un disque de démarrage DOS et des pilotes ASPI pour accéder au disque dur. La mise à jour charge le nouveau code de queuing et lookahead dans la RAM SCSI non-volatile du disque. Si vous rencontrez des problèmes avec un disque dont la révision de microcode est la 9WA1.60, vous devrez contacter le centre de service Conner le plus proche pour procéder à la mise à jour. La révision du microcode se trouve sur l'étiquette du disque, et en dessous, sur l'étiquette de l'un des circuits intégrés. Si vous pensez pouvoir faire vous-même la mise à jour, appelez Conner Technical Support Europe et gardez votre révision de microcode à portée de main. On peut joindre Conner Technical Support Europe au +44-1294-315333, et Conner Technical Support aux USA au 1-800-4CONNER. Soenke Behrens European Technical Support </verb> </tscreen> <sect1><heading><label id="device files">Fichiers périphériques</> Les disques SCSI utilisent le numéro majeur de périphérique bloc 8, et il n'existe pas de périphériques ``raw'' à la BSD. 16 numéros mineurs sont alloués à chaque disque SCSI, avec mineur &percnt 16 == 0 étant le disque entier, les mineurs 1 <= (mineur &percnt 16) <= 4 étant les quatre partitions primaires, les mineurs 5 <= (mineur &percnt 16) <= 15 étant les partitions étendues. En raison des contraintes imposées par l'utilisation de Linux d'un dev_t de 16 bits, seuls 8 bits étant alloués au nombre mineur, les nombres mineurs de disques SCSI sont assignés dynamiquement en commençant par le plus bas des HOST/ID/LUN SCSI. Par exemple, une configuration peut ressembler à ceci (avec un adaptateur hôte) :<table> <tabular ca="lccl"> Périphérique | Cible | Lun | Disque SCSI @ Seagate 84 Mo | 0 | 0 | /dev/sda @ SCSI-> SMD bridge disk 0 | 3 | 0 | /dev/sdb @ SCSI-> SMD bridge disk 1 | 3 | 1 | /dev/sdc @ Wangtek tape | 4 | 0 | aucun @ Maxtor 213 Mo | 6 | 0 | /dev/sdd @ etc. </tabular> </table> La convention de nommage est /dev/sd{lettre} pour le périphérique disque entier ((mineur &percnt 16) == 0) /dev/sd{lettre}{partition} pour les partitions sur ce périphérique (1 < = (mineur &percnt 16) < = 15) Par exemple <table> <tabular ca="llcc"> Périphérique | type | majeur | mineur @ /dev/sda | bloc | 8 | 0 @ /dev/sda1 | bloc | 8 | 1 @ /dev/sda2 | bloc | 8 | 2 @ /dev/sda3 | bloc | 8 | 3 @ etc. </tabular> </table> <sect1>Partitionnement Vous pouvez partitionner vos disques SCSI avec le programme de partitionnement de votre choix, sous DOS, OS/2, Linux ou tout autre système d'exploitation qui supporte le système standard de partitionnement. La façon correcte de lancer le programme fdisk de Linux consiste à préciser le périphérique sur la ligne de commande. Par exemple, pour partitionner le premier disque SCSI, <tscreen><verb> fdisk /dev/sda </verb></tscreen> Si vous ne précisez pas explicitement le périphérique, le programme de partitionnement peut prendre /dev/hda par défaut, qui n'est pas un disque SCSI. Dans certains cas, fdisk répondra par <tscreen><verb> You must set heads sectors and cylinders. You can do this from the extra functions menu. Command (m for help): </verb></tscreen> et/ou afficher un message comme quoi l'ioctl HDIO_REQ ou HDIO_GETGEO a échoué. Dans ce cas, vous devez spécifier manuellement la géométrie du disque comme indiqué à la sous-section <ref id="fdisk geometry"> : Géométrie des disques au moment de lancer fdisk, ainsi que dans /etc/disktab si vous désirez démarrer le noyau depuis ce disque avec LILO. Si vous avez spécifié manuellement la géométrie du disque, les tentatives ultérieures de lancement de fdisk donneront le même message d'erreur. C'est normal, car les PC ne stockent pas les informations concernant la géométrie du disque dans la table de partition. En tout état de cause, il n'y a _AUCUN PROBLEME_, et vous pourrez accéder aux partitions que vous avez créé sur le disque avec Linux. Le code d'installation de quelques fournisseurs pourra buter dessus, auquel cas vous devrez contacter ledit fournisseur afin d'insister pour qu'il corrige ce code. Dans certains cas, vous obtiendrez un message d'avertissement concernant une partition finissant après le cylindre 1024. Si vous créez une de ces partitions, vous serez incapable de démarrer les noyaux de Linux depuis cette partition par LILO. Remarquez cependant que cette restriction n'empêche pas la création d'une partition racine située partiellement ou entièrement au-dessus de cette limite des 1024 cylindres, puisqu'il est possible de créer une petite partition /boot en dessous de la limite ou de démarrer des noyaux depuis des partitions existantes. <sect1><heading><label id="disk geometry and parts">Géométrie des disques </> Sous Linux, chaque disque est vu tel que l'adaptateur SCSI hôte le voit : N blocs, numérotés de 0 à N-1, tous sans erreurs, alors que le DOS et le BIOS ont été conçus à une date antérieure aux disques intelligents et favorisent une géométrie arbitraire en têtes / cylindres / secteurs au lieu d'un adressage linéaire. Ceci peut poser problème au moment de partitionner les disques sous Linux, puisqu'il n'existe aucune manière portable de connaître l'idée que se font le DOS et le BIOS de la géométrie du disque. Dans la plupart des cas, un ioctl() avec HDIO_GETGEO peut être implémenté pour renvoyer cette géométrie. Malheureusement, quand le fournisseur (comme Seagate) a choisi une géométrie perverse, non-standard et non-documentée, cette façon de faire devient impossible et la géométrie doit être spécifiée manuellement. Dans ce dernier cas, vous disposez de plusieurs options : <enum> <item> Si vous ne désirez pas utiliser le DOS, ni démarrer des noyaux depuis ce disque avec LILO, créez une translation telle que têtes * cylindres * secteurs * 512 < la taille de votre disque en octets (un mégaoctet est défini comme 2^20 octets). (NdT : 1 Mo est aussi souvent égal à 10^6 octets pour de nombreux fabriquants de disques dur...) <table> <tabular ca="ccccc"> 1 | < = | têtes | < = | 256 @ 1 | < = | cylindres | < = | 1024 @ 1 | < = | secteurs | < = | 63 @ </tabular </table> <item>Utilisez la géométrie du disque. Dans certains cas, cela implique une reconfiguration du disque afin que celui-ci se trouve en SCSI ID 0, et la désactivation du deuxième disque IDE (si vous en avez un). Vous pouvez utiliser soit un programme comme NU, soit le programme suivant : <code> 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;&ero;ED(&1R:79E#0HD("`D```````D``!O ` end </code> A son exécution, il affiche les secteurs, les têtes et les cylindres du disque dont l'adresse du BIOS a été précisée sur la ligne de commande (0x80 est le premier disque, 0x81 est le second). Par exemple, <tscreen><verb> dparam 0x80 60 17 1007 </verb></tscreen> Signifie que C: a 60 secteurs, 17 têtes et 1007 cylindres. </enum> <sect>CDROMs Cette section donne des informations spécifiques aux lecteurs CD-ROM. <sect1>Matériels supportés et non supportés Les CD SCSI dont la taille de bloc est de 512 ou 2048 octets doivent fonctionner, pas les autres tailles. <sect1>Problèmes habituels <sect2>Impossible de monter le CD-ROM. La syntaxe correcte permettant de monter un CD-ROM ISO-9660 est <tscreen> <verb> mount -t iso9660 /dev/sr0 /point_de_montage -o ro </verb> </tscreen> Remarquez que pour que cela fonctionne, vous devez avoir configuré le noyau pour un support SCSI, votre adaptateur hôte, le pilote CD-ROM SCSI et le système de fichiers iso9660. Remarquez également que, du moins pour Linux 1.1.32, les périphériques en lecture seule comme les CD-ROM ne peuvent pas être montés avec les options read/write par défaut. <sect2>Impossible d'éjecter le CD-ROM. Linux essaye de bloquer la porte du lecteur quand un support est monté afin d'empêcher toute corruption du système de fichiers due à un changement inopiné de support. <sect2>Impossible de jouer le CD en audio. Les programmes workman ou xcdplayer s'en chargeront pour vous. <sect2> workman ou xcdplayer ne fonctionnent pas. Les fonctions de contrôle audio font partie du jeu de commandes SCSI-II, ce qui fait que tout lecteur non SCSI-II ne fonctionnera probablement pas. De même, de nombreux lecteurs de CD-ROM SCSI-I, et certains SCSI-II, utilisent un jeu de commandes propriétaires pour accéder aux fonctions audio au lieu du jeu SCSI-II. Pour les lecteurs NEC, il existe quelque part une version de xcdplayer spécialement adaptée à ce jeu de commande ; essayez de voir vers <url url="ftp://tsx-11.mit.edu/pub/linux/BETA/cdrom"> Ces programmes peuvent fonctionner avec certains des lecteurs de CD-ROM non-SCSI si le lecteur implémente les mêmes ioctl que les pilotes SCSI. <sect1>Fichiers de périphériques Les CD-ROM SCSI utilisent le majeur 11. Les mineurs sont alloués dynamiquement (voir section 4 : Disques, sous-section 4.3 : Fichiers de périphériques pour un exemple), le premier CD-ROM trouvé étant le mineur 0, le second le mineur 1, etc. La convention de nommage standard est /dev/sr{chiffre} par exemple /dev/sr0 /dev/sr1 etc. <sect>Bandes Cette section donne des informations spécifiques aux lecteurs de bande SCSI. <sect1>Matériel supporté et non supporté Les lecteurs utilisant à la fois des longueurs de blocs fixes et variables, plus petites que la longueur du tampon du pilote (32 Ko dans les sources de distribution), sont supportés. Les paramètres (taille de blocs, tamponnage, densité) sont fixés par des ioctl (généralement avec le programme mt), et restent actifs après que le périphérique ait été fermé et réouvert. Pratiquement tous les lecteurs devraient fonctionner, comme : <itemize> <item>Les Archive Viper QIC, y compris les modèles 150M and 525M <item>Les Exabyte 8mm <item>Les Wangtek 5150S <item>Les DAT Wangdat </itemize> <sect1>Problèmes habituels <sect2>Lecteur de bande non reconnu au démarrage. Essayez de démarrer avec une bande dans le lecteur. <sect2>Des bandes comprenant plusieurs fichiers ne peuvent être correctement lues. En lisant une bande comprenant plusieurs fichiers, le premier tar réussit, un second échoue silencieusement, et un réessai de ce second tar réussit. Le programmes de niveau utilisateur, comme tar, ne comprennent pas les marques de fichier. Le premier tar lit jusqu'au bout du fichier. Le second essaie de lire la marque de fichier, n'obtient rien, mais la bande continue jusqu'à la fin de la marque de fichier. Le troisième tar réussit puisque la bande se trouve au début du fichier suivant. Utilisez mt sur le périphérique no-rewind (sans-rembobinage) pour avancer jusqu'au fichier suivant. <sect2>La décompression échoue. La décompression de programmes ne peut gérer les zéros remplissant le dernier bloc du fichier. Il vous faut enrober vos fichiers compressés dans un fichier .tar afin d'empêcher les warnings et les erreurs ; par exemple, au lieu de faire <tscreen><verb> tar cfvz /dev/nrst0 file.1 file.2 ... </verb></tscreen> faites <tscreen><verb> tar cfvz tmp.tar.z file.1 file.2 ... tar cf /dev/nrst0 tmp.tar.z </verb></tscreen> <sect2>Problèmes d'échange de bandes entre systèmes. Vous ne pouvez pas lire une bande fabriquée avec un autre système d'exploitation ou un autre système d'exploitation ne peut lire une bande écrite sous Linux. Des systèmes différents utilisent fréquemment des tailles de blocs différentes. Sur un périphérique bande utilisant une taille de blocs fixe, vous obtiendrez des erreurs au moment de lire des blocs écrits avec une taille de blocs différente. Pour lire ces bandes, vous devez fixer la taille de bloc du lecteur de bande pour qu'elle corresponde à la taille utilisée au moment ou la bande a été écrite, ou à taille variable. <bf>Note</bf> : Il s'agit ici de la taille de bloc matériel, et non du facteur de blocage utilisé avec tar, dump, etc. Il est possible de le faire avec la commande mt : <tscreen><verb> mt setblk <taille></verb></tscreen> ou <tscreen><verb> mt setblk 0 </verb></tscreen> pour avoir un support de taille de bloc variable. Remarquez que ces options de mt ne sont PAS supportées avec la version GNU de mt qui est incluse dans certaines distributions Linux. Vous devez donc utiliser la commande mt SCSI de Linux dérivée de la version BSD. Le source devrait être disponible depuis <url url="ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi"> <sect2>Message d'erreur ``No such device'' Toute tentative d'accès à la bande se traduit par un ``No such device'' ou un mesage d'erreur similaire. Vérifiez le type de votre périphérique bande ; il <bf>doit</bf> être un périphérique de type caractère dont les nombres majeur et mineur correspondent à ceux qui ont été précisés en sous-section C, Fichiers de périphériques. <sect2>La bande lit correctement à une certaine densité, l'écriture échoue De nombreux lecteurs de bandes supportent la lecture à des densité faibles pour des raisons de compatibilité, mais ne peuvent écrire dans ces conditions. C'est exactement le cas avec les lecteurs QIC, qui lisent les vieilles bandes de 60 Mo mais n'écrivent qu'aux formats 120, 150, 250 et 525 Mo. <sect1>Fichiers de périphériques Les bandes SCSI utilisent le fichier de périphérique caractère majeur 9. En raison des contraintes imposées par l'utilisation de Linux d'un dev_t de 16 bits dont seuls 8 bits sont alloués au nombre mineur, les nombres mineurs de bande SCSI sont assignés dynamiquement en commençant par le plus petit des HOST/ID/LUN SCSI. Les périphériques avec rembobinage sont numérotés à partir de zéro ; la première bande SCSI, /dev/rst0 étant c 9 0, la seconde, /dev/rst1 c 9 1, etc. Les périphériques sans rembobinage ont le huitième bit positionné dans le nombre mineur, c'est à dire que /dev/nrst0 est c 9 128. La convention de nommage standard est /dev/nrst{chiffre} pour les périphériques sans rembobinage, et /dev/rst{chiffre} pour ceux avec rembobinage. <sect>Générique Cette section fournit des informations spécifiques au pilote SCSI générique. <sect1>Matériel supporté Le pilote de périphérique générique fournit une interface permettant d'envoyer des comandes SCSI à tout périphérique SCSI : disques, bandes, CD-ROM, robots de chargement de support, etc. Tout ce qui est électriquement compatible avec votre carte SCSI devrait fonctionner. <sect1>Problèmes habituels Aucun :-). <sect1>Fichiers de périphériques Les périphériques génériques SCSI utilisent un majeur caractère 21. En raison des contraintes imposées par l'utilisation de Linux d'un dev_t de 16 bits, les nombres mineurs sont assignés dynamiquement à partir de zéro, un par périphérique, où : /dev/sg0 correspond à la plus basse des cibles/lun numériques sur la première carte SCSI. <sect><heading><label id="buyers guide">Guide d'achat </> Une question fréquemment posée est : ``Linux supporte un grand nombre de cartes différentes ; quel adaptateur hôte SCSI dois-je acheter'' ? La réponse dépend des performances que vous en attendez, de la carte-mère, et des périphériques SCSI que vous projetez de raccorder à votre machine. <sect1>Types de transfert Le facteur de performance le plus important (en terme de vitesse et de réponse interactive pendant les E/S SCSI) est le type de transfert utilisé. <sect2>Handshake à scrutation seule (pure polled handshaking). Une carte d'E/S pure polled utilisera la CPU pour la totalité de la gestion SCSI, y compris REQ/ACK. Même une CPU rapide sera moins performante pour gérer la séquence REQ/ACK qu'une simple machine à états finis, et donnera des taux de transferts d'environ 150 Ko/s sur une machine rapide, et peut-être 60 Ko/s sur une machine lente (à travers le système de fichiers). Le pilote devra également rester à l'intérieur d'une boucle aussi longtemps que le bus SCSI sera occupé, occupant ainsi près de 100&percnt d'utilisation de la CPU et provoquant une très mauvaise réactivité pendant les E/S SCSI. Les CD-ROM lents qui ne font pas de déconnexion/reconnexion tuent littéralement toute interactivité avec ces cartes. <bf>Déconseillé. </bf> <sect2>Handshake à scrutation (Interlocked Polled handshaking) Le cartes qui utilisent des E/S interlocked polled sont essentiellement similaires aux cartes pure polled, mais les signaux REQ/ACK SCSI sont transmis au bus du PC. Hormis ces signaux, toute la gestion SCSI reste dévolue à la CPU. Des taux de transfert de 500-600 Ko/s par le système de fichier sont possibles sur ces cartes. De même qu'avec les cartes à scrutation seule, le pilote doit rester à l'intérieur d'une boucle serrée tant que le bus SCSI est occupé, l'occupation de la CPU dépendant ainsi des taux de transfert des périphériques et de la déconnexion/reconnexion. Elle peut varier entre 25&percnt pour les CD simple vitesse qui gèrent correctement la déconnexion/reconnexion, et 100&percnt pour les lecteurs plus rapides ou les CD-ROM défectueux qui ne peuvent pas se déconnecter/reconnecter. Sur mon 486-66, avec une T128, j'utilise 90&percnt de mon temps CPU pour arriver à un taux de transfert de 547 Ko/s sur un disque capable de 1080 Ko/s en crête. Quelquefois acceptable pour les unités de bandes et les CD-ROM lents quand le prix est un critère essentiel. <sect2>Scrutation par FIFO (FIFO polled) Les cartes qui utilisent les E/S à scrutation par FIFO (First In, First Out) mettent un petit tampon (typiquement 8 Ko) entre la CPU et le bus SCSI, et implémentent souvent un certain niveau d'intelligence. En conséquence, la CPU n'est bloquée que le temps d'envoyer les données à vitesse maximale vers la FIFO et de gérer le reste de la gestion des interruptions pour les conditions de FIFO vide, déconnexion/reconnexion, etc. Le taux de transfert devrait être suffisant pour gérer la plupart des périphériques SCSI, et on a pu mesurer jusqu'à 4 Mo/s en utilisant des commandes SCSI brutes pour lire directement des blocs de 64 Ko sur un Seagate Barcuda avec une Adaptec 1520. L'utilisation de la CPU dépend du taux de transfert des périphériques, les plus rapides générant plus d'interruptions ce qui demande plus de temps CPU. Bien que ce dernier puisse atteindre 75&percnt avec des périphériques rapides, le système reste en général utilisable. Ces cartes fournissent d'excellentes performances en interactif avec des périphériques défectueux qui ne se déconnectent/reconnectent pas (comme les CD-ROM de bas de gamme). Recommandé pour les utilisateurs aux finances limitées. <sect2>DMA esclave (Slave DMA) Les pilotes de cartes qui utilisent le DMA esclave programment le contrôleur DMA du PC pour un canal quand ils font un transfert de données, puis rendent le contrôle au CPU. Les taux de transfert de pointe sont en général handicapés par le médiocre contrôleur DMA des PC, une carte 8-bits ayant même eu des problèmes à dépasser 140-150 Ko/s avec une certaine carte-mère. L'utilisation de la CPU est très raisonnable, légèrement moindre que ce que l'on connait avec des cartes d'E/S à scrutation par FIFO. Ces cartes sont très tolérantes avec les périphériques défectueux qui ne se déconnectent/reconnectent pas, typiquement les CD-ROM bon marché. Acceptable pour les bandes, les lecteurs de CD-ROM lents, etc. <sect2>Bus-mastering DMA Ces cartes sont intelligentes. Les pilotes de ces cartes mettent une commande SCSI, la cible et la LUN de destination, et l'endroit où les données doivent arriver dans une structure, et disent à la carte ``Hep, j'ai une commande pour toi''. Le pilote rend la main aux programmes en train de tourner, et finalement la carte SCSI revient et dit que c'est fait. L'intelligence se situant dans le logiciel embarqué et non au niveau du pilote, ce dernier supporte en général plus de caractéristiques : transferts synchrones, tagged queuing, etc. Avec les patches de clustered read/write (lectures/écritures regroupées), le taux de transfert de pointe en passant par le système de fichiers approche les 100&percnt en écriture et 75 % en lecture. L'utilisation de la CPU est minimale, indépendante de la charge d'E/S, avec une mesure de 5&percnt pendant l'accès à un CD-ROM double vitesse sur une Adaptec 1540 et de 20&percnt pendant un transfert à 1,2 Mo/s sur un disque SCSI. Recommandé dans tous les cas où l'argent n'est pas un facteur crucial, où la carte-mère n'est pas défectueuse (certaines cartes-mères ne fonctionnent pas avec les bus-masters), et des applications où le temps d'obtention des données est plus important que le débit (le temps de traitement dû au bus master peut atteindre 3-4 ms par commande). <sect1>Scatter/gather La deuxième caractéristique la plus importante en matière de performance est le support du scatter/gather. Le temps d'exécution d'une commande SCSI est significatif : il se compte en millisecondes. Les bus master intelligentes comme l'Adaptec 1540 peuvent prendre 3-4 ms pour traiter une commande SCSI avant même que la cible soit atteinte. Sur les périphériques non bufferisés, ce temps de traitement est toujours suffisant pour laisser passer une révolution, donnant ainsi un taux de transfert de 60 Ko/s (avec un disque à 3600 t/m) par bloc transféré à la fois. Afin de maximiser les performances, il faut donc minimiser le nombre de commandes SCSI nécessaires au transfert d'une certaine quantité de données en en transférant plus par commande. En raison de la conception du buffer cache de Linux, des blocs contigus sur disque ne le sont pas en mémoire. Les patches read/write en cluster permettent à 4 Ko de rester contigus. La quantité maximale de données qui peuvent être transférés par commande SCSI sera donc 1 Ko * nombre de régions de scatter/gather sans patches read/write en cluster, 4 Ko * régions avec. Nous avons expérimentalement déterminé que 64 Ko était une quantité raisonnable de données transférables par une seule commande, ce qui signifie 64 tampons de scatter/gather avec les patches de read/writes en cluster, et 16 sans. Le passage de 16 Ko à 64 Ko par transfert nous a permis de constater une amélioration allant de 50&percnt pour l'écriture et la lecture à travers le système de fichiers, à 75&percnt et 100&percnt respectivement en utilisant une carte Adaptec 1540. <sect1>Mailbox ou pas ? Un grand nombre d'adaptateurs hôtes intelligents, comme l'Ultrastor, la WD7000, les Adaptec 1540 et 1740, et la Buslogic ont utilisé une interface similaire à une boîte aux lettres, où les commandes SCSI sont exécutées en mettant une structure de commande SCSI à un endroit précis (la boîte aux lettres), en avertissant la carte (par exemple par un flag de courrier envoyé), et en attendant la réponse (arrivée du courrier). Avec cette interface de programmation de haut niveau, les utilisateurs peuvent souvent mettre leur carte à jour avec une nouvelle révision pour bénéficier de nouvelles caractéristiques, comme le SCSI FAST + WIDE, sans changer de logiciel. Les pilotes tendent vers plus de simplicité, peuvent implémenter un jeu de caractéristiques plus étendues et sont plus stables. D'autres adaptateurs intelligents, comme la famille NCR53c7/8xx et les circuits Adaptec AIC-7770/7870 (y compris les cartes 274x, 284x et 2940), utilisent une interface de programmation de haut niveau. Il se peut que cette option se révèle plus rapide car le traitement peut être déplacé du processeur de la carte vers une CPU rapide, permettre une meilleur flexibilité dans l'implémentation de certaines caractéristiques (comme le mode cible pour des périphériques arbitraires), et ces cartes peuvent êtres fabriquées pour moins cher (ce dont les consommateurs bénéficient dans certains cas, comme les NCR). Par contre, les pilotes tendent à devenir plus complexes, et doivent être modifiés pour profiter des caractéristiques spécifiques aux nouveaux circuits. <sect1>Types de bus Il faut ensuite prendre en considération le type de bus et faire un choix entre ISA, EISA, VESA et PCI. Les publicités vantent fréquemment des bandes passantes ridicules, fondées sur des pointes de taux de transferts, et sur la fiction, ce qui n'est pas très utile. J'ai préféré mettre en avant des chiffres réalistes provenant de performances mesurées avec divers périphériques. <sect2>ISA La bande passante dépasse légèrement 5 Mo/s pour les périphériques à bus-mastering. Avec un bus ISA, l'arbitrage entre bus masters est réalisé par le vénérable contrôleur 8237 qui donne des temps d'acquisition de bus assez élevés. Les pilotes d'interruptions sont à trois états et edge-triggered (déclenchés par le front du signal), ce qui veut dire que les interruptions ne peuvent être partagées. L'ISA est en général non bufferisé, et le bus hôte/mémoire est donc bloqué chaque fois qu'un transfert se produit. Aucun mécanisme n'est fourni permettant d'éviter l'engorgement du bus. <sect2>VESA La bande passante est d'environ 30 Mo/s. Certains systèmes VESA dépassent les caractéristiques du bus, se rendant ainsi incompatibles avec certaines cartes, et ce fait est donc à prendre en compte avant d'acquérir du matériel sans garantie. Le VESA n'est en général pas bufferisé, et le bus hôte/mémoire est donc bloqué chaque fois qu'un transfert se produit. <sect2>EISA La bande passante tourne autour de 30 Mo/s, les opérations de bus-mastering étant en général plus rapides que sur VESA. Certains systèmes EISA peuvent bufferiser le bus, permettant des transferts en mode rafale et minimisant l'impact sur les performances de la CPU. Les pilotes d'interruption peuvent être soit trois-états edge-triggered, soit activés par niveau, à collecteur ouvert, permettant ainsi le partage d'interruptions avec les pilotes qui le supportent. L'EISA allouant un espace d'adressage séparé pour chaque carte, il est en général moins sensible aux conflits de ressources que l'ISA ou le VESA. <sect2>PCI La bande passante tourne autour de 60 Mo/s. La plupart des systèmes PCI implémentent des tampons de write posting sur le bridge hôte, permettant ainsi des vitesses différentes des deux côtés et donc un impact minimal sur les performances bus/CPU. Les drivers d'interruptions PCI sont à collecteur ouvert et activés par niveau, autorisant ainsi le partage d'interruptions avec les pilotes qui le supportent. Des mécanismes empêchent l'engorgement du bus, et empêchent également tant le maître que l'esclave de suspendre une opération de bus-mastering. PCI fournissant un mécanisme de plug-and-play avec des registres de configuration modifiables sur chaque carte, dans un espace d'adressage séparé, un système PCI correctement implémenté est donc plug-and-play. PCI est extrêmement strict quant à la longueur de trace, la charge, les spécification mécaniques, etc, et devrait devenir plus fiable que VESA ou ISA. Pour résumer, PCI est le meilleur bus PC, bien qu'il ait des inconvénients. Il n'est pas encore parvenu à maturité, et bien que la plupart des fabricants aient aplani les difficultés, il reste toujours des stocks de vieux matériel PCI bogué et de BIOS défectueux. C'est pourquoi je recommande _fermement_ une garantie de retour sur le matériel. Même si les dernières cartes-mères sont vraiment plug-and-play, celles qui sont plus anciennes peuvent demander quelques réglages par cavaliers et par logiciel (par exemple pour les assignations d'interruptions) de la part de l'utilisateur. Et, bien que la plupart des utilisateurs aient résolu leurs problèmes avec PCI, cela a en général pris du temps et c'est pour cette raison que je ne peux pas recommander l'achat d'un système PCI s'il est crucial de disposer rapidement d'un système opérationnel. Pour la plupart des périphériques SCSI lents, comme les disques d'un headrate de 2 Mo/s ou moins, les CD-ROM ou les bandes, il n'y aura que peu de différences de performances entre les différents bus PC. En ce qui concerne les disques rapides actuels (les unités de plusieurs giga-octets ont en général une headrate de 4-5 Mo/s, et au moins une compagnie dispose d'une unité à têtes parallèles en alpha-test avec un headrate de 14 Mo/s), les performances se trouveront nettement améliorées par des contrôleurs sur des bus rapides, un utilisateur notant une amélioration d'un facteur de 2,5X en passant d'une carte Adaptec 1542 ISA à une NCR53c810 PCI. A l'exception de situations où le write-posting PCI ou un mécanisme de bufferisation similaire est employé, tous les bus seront inaccessibles quand l'un d'entre eux sera occupé. Donc, bien que la saturation du bus n'interfère pas avec la performance SCSI, elle aura un impact négatif sur la performance interactive. Par exemple, avec un disque SCSI à 4 Mo/s sur un bus ISA, vous aurez perdu 80&percnt de votre bande passante, et vous ne pourriez transférer des images qu'à 6 Mo/s sur un système ISA/VESA ; et un impact similaire serait ressenti dans la plupart des cas sur les processus en arrière-plan. Il faut noter que le fait d'avoir plus de 16 Mo de mémoire n'empêche pas d'utiliser une carte SCSI bus-mastering ISA. Au contraire de nombre de systèmes d'exploitation mal conçus, Linux utilise un double tampon pour la DMA avec un contrôleur ISA vers une zone de mémoire située au-dessus de 16 Mo. Les performances au cours de ces transferts ne diminuent que de 1,5&percnt, ce qui est très peu sensible. Enfin, les différences de prix entre les bus masters fournies avec diverses interfaces sont souvent minimales. A la suite de tout ceci, certains bus auront votre préférence. <descrip> <tag/Stabilité, rapidité d'installation et mauvaises garanties de retour / EISA ISA VESA PCI <tag/Performances et installations personnelles/ PCI EISA VESA ISA </descrip> Comme je l'ai déjà souligné, l'impact sur les performances sera essentiellement déterminé par le choix entre bus mastering et les autres modes de transfert, et le type de bus sera bien moins important au moment d'acquérir un contrôleur SCSI. <sect1>Plusieurs périphériques Si vous mettez plusieurs périphériques sur votre bus SCSI, vous voudrez peut-être que l'adaptateur/pilote que vous envisagez supporte plus d'une commande en suspens (outstanding command) à la fois. Ce point est très important si vous mélangez des périphériques de différentes vitesses, comme un lecteur de bande et un disque dur. Si le pilote Linux ne supporte qu'une commande en attente à la fois, l'accès au disque peut être bloqué pendant qu'une bande est en train de se rembobiner, par exemple. Avec deux disques durs, le problème passera inaperçu, bien que la vitesse totale de transfert approche plus la moyenne que la somme des vitesses individuelles. <sect1>SCSI-I, SCSI-II, SCSI-III FAST et WIDE, etc. Au cours du temps, SCSI a évolué, de nouvelles révisions du standard offrant de meilleures vitesses de transfert, de meilleures méthodes pour accélérer la capacité de transfert, des commandes standardisées pour de nouveaux périphériques et de nouvelles commandes pour les périphériques déjà supportés. Les niveaux de révision ne signifient pas grand-chose par eux-même. A part des différences mineures comme SCSI-II ne permettant pas l'option ``single initiator'' de SCSI-I, la norme SCSI est compatible avec les versions antérieures, les nouvelles caractéristiques étant présentées an tant qu'options. La décision d'appeler un adaptateur SCSI, SCSI-II ou SCSI-III relève presque entièrement du marketing. <sect1>Comparaison des caractéristiques des pilotes Comparaison des caractéristiques des pilotes (les circuits supportés sont listés entre parenthèses) <tabular ca="llcccl"> Pilote | Mode de transfert| Commandes simultanées | SG | >1 @ | | total/LUN | Limite | @ aha152x | FIFO(8k) Polled | 1s/1s | 255s @ (AIC6260, @ AIC6360) @ aha1542 | Busmastering DMA | 8s/1s | 16 | O @ aha1740 | Busmastering DMA | 32s | 16 @ aha274x | Busmastering DMA | 4s/1s | 255s | O @ buslogic | Busmastering DMA | O | 64s, 8196h @ eata_dma | Busmastering DMA | 64s/16s | 64s | O @ fdomain | FIFO(8k) Polled | 1s | 64s @ TMC1800 sauf TMC18c30 @ TMC18c30, avec 2k FIFO @ TMC18c50, @ TMC36c70 @ in2000* | FIFO(2k) Polled | 1s | 255s @ g_NCR5380 | Pure Polled | 16s/2s | 255s | O@ (NCR5380, @ NCR53c80, @ NCR5381, @ NCR53c400) @ gsi8* | Slave DMA | 16s/2s | 255s @ (NCR5380) @ PAS16 | Pure Polled ou | 16s/2s | 255s | O @ (NCR5380) | Interlocked Polled @ (ne marche pas sur certains systèmes) @ seagate | Interlocked Polled| 1s | 255s | N @ wd7000 | Busmastering DMA | 8s | 1 @ t128 | Interlocked Polled| 16s | 255s | O @ (NCR5380) @ ultrastor | Busmastering DMA | O @ 53c7,8xx | Busmastering DMA | 1s/1s | 255s | O @ (NCR53c810) @ </tabular> Notes : <enum> <item>les pilotes marqués d'un '*' ne sont pas inclus dans le noyau de distribution, et les images binaires de démarrage peuvent ne pas être disponibles. <item>les nombres suffixés par un 's' sont des limites arbitraires fixées par logiciel et peuvent être changés par une définition au moment de la compilation. <item>Les limites matérielles sont indiquées par un suffixe 'h', et peuvent différer des limites logicielles actuellement imposées par les pilotes Linux. <item>les nombres non suffixés peuvent indiquer des limites soit matérielles, soit logicielles. </enum> <sect1>Comparaison des cartes <tabular ca=lllll> Carte | Pilote | Bus | Prix (&dollar) | Notes @ Adaptec AIC-6260 | aha152x | ISA | | circuit, pas carte @ Adaptec AIC-6360 | aha152x | VLB | | circuit, pas carte@ | | | | (Utilisé dans la plupart @ | | | | des cartes VESA/ISA @ | | | | multi-IO avec SCSI, @ | | | | les cartes-mères Zenon) @ Adaptec 1520 | aha152x | ISA @ Adaptec 1522 | aha152x | ISA | $80 | 1520 avec FDC @ Adaptec 1510 | aha152x | ISA | | 1520 sans ROM, @ | | | | pas d'autodétection. @ Adaptec 1540C | aha1542 | ISA @ Adaptec 1542C | aha1542 | ISA | | 1540C avec FDC @ Adaptec 1540CF | aha1542 | ISA | | FAST SCSI-II @ Adaptec 1542CF | aha1542 | ISA | $200 | 1540CF avec FDC @ Adaptec 1740 | aha1740 | EISA | | n'est plus produite @ Adaptec 1742 | aha1740 | EISA | | idem, 1740 @ | | | | avec FDC @ Adaptec 2740 | aha274x | EISA @ Adaptec 2742 | aha274x | EISA | | avec FDC @ Adaptec 2840 | aha274x | VLB @ Adaptec 2842 | aha274x | VLB | | avec FDC @ Always IN2000 | in2000 | ISA @ Buslogic 445S | aha1542, | VLB | $250 | FAST SCSI-II, terminaison@ buslogic | | | | active, avec FDC @ Buslogic 747S | aha1542 | EISA | | FAST SCSI-II, terminaison @ buslogic | | | | active, avec FDC @ Buslogic 946S | buslogic | PCI | | FAST SCSI-II, terminaison @ | | | | active. @ DPT PM2011 | eata_dma | ISA | | FAST SCSI-II @ DPT PM2012A | eata_dma | EISA | | FAST SCSI-II @ DPT PM2012B | eata_dma | EISA | | FAST SCSI-II @ DPT PM2021 | eata_dma | ISA | $245 | FAST SCSI-II @ DPT PM2022 | eata_dma | EISA | $449 | FAST SCSI-II @ | | | | terminaison active @ DPT PM2024 | eata_dma | PCI | $395 | FAST SCSI-II @ | | | | terminaison active @ DPT PM2122 | eata_dma | EISA | $595 | FAST SCSI-II @ | | | | terminaison active @ DPT PM2124 | eata_dma | PCI | $595 | FAST SCSI-II @ | | | | terminaison active @ DPT PM2322 | eata_dma | EISA | | FAST SCSI-II @ | | | | terminaison active @ DPT PM3021 | eata_dma | ISA | $1595| FAST SCSI-II @ | | | | multichannel @ | | | | raid/simm sockets @ | | | | terminaison active @ DPT PM3122 | eata_dma | EISA | $1795| FAST SCSI-II @ | | | | multichannel/raid @ | | | | terminaison active @ </tabular>   <tabular ca=lllll> DPT PM3222 | eata_dma | EISA | $1795| FAST SCSI-II @ | | | | multichannel @ | | | | raid/simm sockets @ | | | | terminaison active @ DPT PM3224 | eata_dma | PCI | $1995| FAST SCSI-II @ | | | | multichannel @ | | | | raid/simm sockets @ | | | | terminaison active @ DPT DTC 3 | aha1542 | EISA | | Devrait marcher, mais en @ | | | | raison de restrictions @ | | | | concernant la diffusion @ | | | | de la documentation, @ | | | | le matériel DTC n'est @ | | | | pas supporté @ DTC 3292 | aha1542 | EISA | | 3290 avec FDC @ DTC 3292 | aha1542 | EISA | | 3290 avec FDC @ Future Domain 1680| fdomain | ISA | | FDC @ Future Domain 3260| fdomain | PCI @ NCR53c810 (cartes | 53c7,8xx |PCI | $70 |circuit, pas carte. @ de FIC, Chaintech,| | | | la carte ne comprend pas @ Nextor, Gigabyte, etc.| | | | de BIOS, bien que beaucoup @ CM avec ce circuit par | | | | de cartes mères non @ AMI, ASUS, J-Bond, | | | | équipées de NCR aient le @ etc. Courant dans | | | | BIOS SDMS. @ les systèmes DEC PCI) @ NCR53c815 ( | 53c7,8xx | PCI | $115 | NCR53c810 plus @ Intel PCISCSIKIT,| | | | bios @ NCR8150S, etc) @ NCR53c825 | 53c7,8xx | PCI | | Variante WIDE de @ | | | | NCR53c815. Notez que @ | | | | le pilote Linux @ | | | | actuel ne tient @ | | | | pas compte des @ | | | | transferts WIDE.@ Pro Audio Spectrum 16| pas16| ISA | | Carte son avec SCSI @ Seagate ST01 | seagate | ISA | $20 | IOS ne marche qu'avec @ | | | | certaines unités @ Seagate ST02 | seagate | ISA | $40 | ST01 avec FDC @ Sound Blaster 16 SCSI| aha152x| ISA| | Carte son avec SCSI @ Western Digital 7000| wd7000| ISA | | avec FDC @ Trantor T128 | t128 | ISA @ Trantor T128F | t128 | ISA | | T128 avec FDC et @ | | | | support des IRQ hautes @ Trantor T130B | g_NCR5380 |ISA @ Ultrastor 14F | ultrastor |ISA | | avec FDC @ Ultrastor 24F | ultrastor |EISA | | avec FDC @ Ultrastor 34F | ultrastor |VLB @ </tabular> Notes: <enum> <item>Trantor a récemment été acheté par Adaptec, et certains produits sont vendus sous ce dernier nom. <item>Ultrastor s'est placé sous le régime du Chapitre 11 de la loi US sur les faillites, ce qui fait que le support technique est actuellement inexistant. <item>Diverses cartes Buslogic autres que les 545S, 445S, 747S et 946S _devraient_ fonctionner, bien qu'à ma connaissance aucune n'ait été testée. <item>Le prix de $70 pour les cartes NCR53c810 n'est pas une faute de frappe ; il comprend l'ensemble de pilotes ASPI/CAM pour DOS, OS/2 et Windows (accès 32 bits), et d'autres pilotes sont disponibles en téléchargement gratuit. Si vous ne pouvez pas en trouver une à ce prix, essayez Technoland au 1-800-292-4500 ou 1-408-992-0888, InteliSys au (703)385-0347, Superpower 1 (800) 736-0007, SW (swt@netcom.com) 214-907-0871 fax 214-907-9339 Insight Electronics au 1-609-985-5556 vend des cartes NCR8150S '815 pour $115 si vous n'avez pas de BIOS NCR SDMS dans votre ROM principale. <item>Les circuits SCSI Adaptec récents présentent une sensibilité inhabituelle aux problèmes de câblage et de terminaison. Je ne peux donc pas recommander les révisions 154x C et CF, ni la série 2xxx. Remarquez que les problèmes de fiabilité ne s'appliquent pas aux anciennes révisions 154x B, 174x A, ni, à ma connaissance, aux cartes basées sur les AIC-6360/AIC-6260. De même, la qualité de leur support technique s'est notablement dégradé, de longs délais devenant de plus en plus courants et leurs employés paraissent ignorants (suggérant certains règlements de non-diffusion concernant certains documents alors qu'il n'y en avait aucun) et hostiles (par exemple, refusant de passer la main à quelqu'un d'autre quand ils ne pouvaient pas répondre). Si les utilisateurs désirent se faire tenir par la main, ou exprimer une opinion politique, ils devraient prendre ce point en considération. Sinon, les Adaptec 1510 sont meilleures que les autres cartes ISA dans la même gamme de prix, et il est possible de faire d'excellentes affaires avec les cartes 154x B et 1742 d'occasion et provenants de surplus, ce qui compense, à mon avis, les problèmes de support. <item>Tous les prix donnés pour les contrôleurs DPT sont officiels. Les prix couramment pratiqués devraient être considérablement inférieurs. Toutes les cartes peuvent être mises à niveau avec du cache et des modules raid, la plupart étant également disponibles en version Wide et/ou Differential. </enum> <sect1>Résumé La plupart des utilisateurs ISA, EISA et VESA seront probablement satisfaits par une carte Buslogic, en raison de ses performances, de caractéristiques comme la terminaison active, et de sa compatibilité avec l'Adaptec 1540. Il existe un grand nombre de modèles disponibles avec des interfaces pour bus EISA, ISA, PCI et VESA, en single ended et différentiel, et en largeurs de bus SCSI de 8 et 16 bits. Ceux qui possèdent des systèmes PCI devraient songer aux cartes à base de NCR53c810. Ce sont des contrôleurs SCSI bus-mastering, disponibles pour $70 à l'unité (moins cher que l'Adaptec 1520), et encore moins cher pour de plus grandes quantités (j'ai vu $62 pour 20 unités). Non contentes d'être les cartes SCSI les moins chères, les cartes NCR sont aussi plus rapides que les Adaptec 2940 et Buslogic BT-946, et font preuve d'excellentes performances sous Linux (jusqu'à 4 Mo/s à travers le système de fichiers) en dépit d'options d'optimisation désactivées dans le pilote actuel. Les inconvénients de ces cartes par rapport aux Buslogic sont qu'elles ne sont pas compatibles Adaptec 1540, n'ont pas de terminaison active, et à ma connaissance ne sont supportées que par DOS+Windows, OS/2, Windows NT, SCO, NeXTStep et FreeBSD. Le pilote Linux semble actuellement assez stable sur la plupart des systèmes (nous avons déplacé plusieurs giga-octets de données vers des périphériques à base de NCR sans problème), étonnamment rapide (jusqu'à 4 Mo/s à travers le système de fichier) et il s'enrichira de nouvelles fonctionnalités dans le futur. Malheureusement, l'implémentation actuelle du pilote Linux ne supporte pas la déconnexion/reconnexion, ce qui fait qu'il vous sera impossible d'accéder aux disques SCSI pendant le rembobinage ou la retension des bandes SCSI. Ceux qui désirent une carte SCSI non-PCI pas trop chère trouveront probablement leur bonheur avec une Adaptec 154x B ou 174x A d'occasion ou provenant de surplus, ou avec un quelconque clone Adaptec 1520 (environ $80) s'ils désirent du matériel neuf. Ces cartes offrent un taux de transfert et des performances en interactif corrects pour un prix modeste. </article>