Page suivantePage précédenteTable des matières

5. Cartes d'interface

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

5.1 Matériel supporté et non supporté

Les pilotes de la distribution du noyau :

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

MCA :

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

Les pilotes alpha :

Plusieurs pilotes ALPHA sont disponibles à

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

Certains pilotes fonctionnent après quelques modifications :

NCR53c8x0/7x0:

Un pilote NCR53c8xx a été développé mais il ne marche toujours pas avec les
composants NCR53c700, NCR53c700-66, NCR53c710 et NCR53c720. Une liste des
modifications nécessaires pour le faire marcher sur chacun de ces composants
est fournie ci-après, accompagnée d'un résumé de la difficulté de chaque patch.
NCR53c720 (facile) - modifications dans la détection du composant, dans la
phase d'initialisation, dans la traduction des adresses des registres '810
vers l'organisation (mapping) des registres '7xx.
NCR53c710 (facile) - modifications dans la détection du composant, dans la
phase d'initialisation, dans la traduction des adresses des registres '810
vers l'organisation (mapping) des registres '7xx, modification des
gestionnaires d'interruption pour traiter l'interruption IID de l'instruction
INTFLY pour l'émuler (Note aux relecteurs (à supprimer dans la version
définitive) je ne suis pas sûr d'avoir bien compris ce que voulait dire
l'auteur : change interrupt handlers to treat IID interrupt from INTFLY
instruction to emulate it),
NCR53c700, NCR53c700-66 (très compliqué) - modifications dans la détection
des composants, dans la phase d'initialisation. Modification du code du NCR
pour ne pas utiliser DSA, modification du code de la gestion des commutations
de contextes.

Les cartes SCSI qui ne marcheront pas :

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

Les cartes SCSI qui ne marcheront JAMAIS :

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

Les cartes CMD SCSI.

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

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

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

Cartes contrôleur multiples

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

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

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

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

5.2 Problèmes habituels

Timeouts SCSI

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

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

Si votre contrôleur SCSI est un des suivants :

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

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

scsi : 0 hosts

ou encore

scsi%d : type

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

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

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

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

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

debug
d c800:0
q

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dans les fichiers linux-version.tar.gz

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

cd /usr/src

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

mv linux linux-old

Désarchivez le fichier

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

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

--- ./kernel/blk_drv/scsi/Makefile
--- ./config.in Wed Sep  1 16:19:33 1993

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

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

tar tfv patches.tar

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

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

patch -p0 < patch_file

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pcibios_init: entry in high memory, unable to access

allez chercher

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

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

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

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

--- bios32.c.orig       Mon Nov 13 22:35:31 1995
+++ bios32.c    Thu Jan 18 00:15:09 1996
@@ -56,6 +56,7 @@
 #include <linux/pci.h> #include <asm/segment.h>
+#include <asm/system.h> #define PCIBIOS_PCI_FUNCTION_ID        0xb1XX
 #define PCIBIOS_PCI_BIOS_PRESENT       0xb101
@@ -125,7 +126,9 @@
 unsigned long address;          /* %ebx */
 unsigned long length;           /* %ecx */
 unsigned long entry;            /* %edx */
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%edi)"
 : "=a" (return_code),
 "=b" (address),
@@ -134,6 +137,7 @@
 : "0" (service),
 "1" (0),
 "D" (&bios32_indirect));
+       restore_flags(flags);
 switch (return_code) {
 case 0:
@@ -161,11 +165,13 @@
 unsigned char present_status;
 unsigned char major_revision;
 unsigned char minor_revision;
+       unsigned long flags;
 int pack;
 if ((pcibios_entry = bios32_service(PCI_SERVICE))) {
 pci_indirect.address = pcibios_entry;
+               save_flags(flags);
 __asm__("lcall (%%edi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -176,6 +182,7 @@
 : "1" (PCIBIOS_PCI_BIOS_PRESENT),
 "D" (&pci_indirect)
 : "bx", "cx");
+               restore_flags(flags);
 present_status = (pack>> 16) & 0xff;
 major_revision = (pack>> 8) & 0xff;
@@ -210,7 +217,9 @@
 {
 unsigned long bx;
 unsigned long ret;
+       unsigned long flags;
+       save_flags(flags);
 __asm__ ("lcall (%%edi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -221,6 +230,7 @@
 "c" (class_code),
 "S" ((int) index),
 "D" (&pci_indirect));
+       restore_flags(flags);
 *bus = (bx>> 8) & 0xff;
 *device_fn = bx & 0xff;
 return (int) (ret & 0xff00)>> 8;
@@ -232,7 +242,9 @@
 {
 unsigned short bx;
 unsigned short ret;
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%edi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -244,6 +256,7 @@
 "d" (vendor),
 "S" ((int) index),
 "D" (&pci_indirect));
+       restore_flags(flags);
 *bus = (bx>> 8) & 0xff;
 *device_fn = bx & 0xff;
 return (int) (ret & 0xff00)>> 8;
@@ -254,7 +267,9 @@
 {
 unsigned long ret;
 unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;
+       save_flags (flags);
 __asm__("lcall (%%esi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -273,7 +288,9 @@
 {
 unsigned long ret;
 unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%esi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -292,7 +309,9 @@
 {
 unsigned long ret;
 unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%esi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -303,6 +322,7 @@
 "b" (bx),
 "D" ((long) where),
 "S" (&pci_indirect));
+       restore_flags(flags);
 return (int) (ret & 0xff00)>> 8;
 }
@@ -311,7 +331,9 @@
 {
 unsigned long ret;
 unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%esi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -322,6 +344,7 @@
 "b" (bx),
 "D" ((long) where),
 "S" (&pci_indirect));
+       restore_flags(flags);
 return (int) (ret & 0xff00)>> 8;
 }
@@ -330,7 +353,9 @@
 {
 unsigned long ret;
 unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%esi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -341,6 +366,7 @@
 "b" (bx),
 "D" ((long) where),
 "S" (&pci_indirect));
+       restore_flags(flags);
 return (int) (ret & 0xff00)>> 8;
 }
@@ -349,7 +375,9 @@
 {
 unsigned long ret;
 unsigned long bx = (bus << 8) | device_fn;
+       unsigned long flags;
+       save_flags(flags);
 __asm__("lcall (%%esi)\n\t"
 "jc 1f\n\t"
 "xor %%ah, %%ah\n"
@@ -360,6 +388,7 @@
 "b" (bx),
 "D" ((long) where),
 "S" (&pci_indirect));
+       restore_flags(flags);
 return (int) (ret & 0xff00)>> 8;
 }

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

Configurations supportées :

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

Auto-détection :

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

Surcharge de l'auto-détection :

Au moment de la compilation :

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

Ligne de commande du noyau :

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

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

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

aha152x=0x340,11,7,1

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

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

Les constantes :

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

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

Configurations supportées :

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

Auto-détection :

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

Surcharge de l'auto-détection :

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

Notes :

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

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

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

Problèmes fréquents :

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

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

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

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

5.5 Adaptec 174x

Configurations supportées :

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

Auto-détection :

fonctionne avec toutes les configurations gérées

Surcharge de l'auto-détection :

aucune

Remarque :

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

Problèmes courants :

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

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

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

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

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

Configurations supportées :

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

Surcharge de l'auto-détection :

Ligne de commande du noyau :

aha274x=extended
(pour forcer le mapping étendu)

Remarques :

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

5.7 Always IN2000 (standard)

Configurations supportées :

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

Auto-détection :

le BIOS n'est pas nécessaire

Surcharge de l'auto-détection :

aucune

Problèmes courants :

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

5.8 Cartes contrôleurs multi-maîtres BusLogic

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

 Pilote SCSI BusLogic Multi-Maîtres pour Linux
 Version 1.2.2 pour Linux 1.2.13
 Version 1.3.2 pour Linux 1.3.88
 ftp://ftp.dandelion.com/BusLogic-1.2.2.tar.gz
 ftp://ftp.dandelion.com/BusLogic-1.3.2.tar.gz
 16 Avril 1996
 Leonard N. Zubkoff
 Dandelion Digital
 lnz@dandelion.com
BusLogic  Inc.  conçoit  et  fabrique  un  ensemble de  contrôleurs SCSI de hautes
performances,  qui partagent une interface de  programmation commune pour diverses
architectures  de bus, par le biais de leur technologie ASIC Multi-Maîtres (Multi-
Master ASIC). Ce pilote gère tous les contrôleurs BusLogic Multi-Maîtres actuels,
et devrait gérer toutes les cartes Multi-Maîtres à venir avec peu (voire aucune) de
modifications.  Les contrôleurs  basés sur la  nouvelle architecture FlashPoint ne
sont pas gérés par ce pilote ; reportez-vous au fichier  README.FlashPoint pour la
marche à suivre pour passer d'une carte FlashPoint LT non gérée à une carte BT-948
supportée.
Mes buts principaux lorsque j'ai écrit ce pilote BusLogic complètement nouveau pour
Linux  étaient d'exploiter les performances maximales que les contrôleurs SCSI Bus-
Logic  et les périphériques SCSI  modernes sont capables d'atteindre  et de fournir
un pilote extrêmement fiable sur lequel des applications critiques puissent s'appu-
yer. Tout  peut être configuré sur la ligne de  commande du noyau, des performances
jusqu'aux détections d'erreurs. Cela permet à chaque installation d'ajuster les pa-
ramètres de performance et de gestion des erreurs aux besoins locaux.
BusLogic  est une  compagnie avec laquelle il a été très agréable de travailler, et
je  recommande chaleureusement leurs produits à la communauté Linuxienne. En Novem-
bre 1995, j'ai eu l'opportunité de devenir site bêta testeur pour leur dernier pro-
duit Multi-Maîtres - le contrôleur SCSI BT-948 PCI Ultra -, puis de nouveau pour le
contrôleur BT-958 PCI Wide Ultra en Janvier 1996. Cela a été un bénéfice réciproque,
car  nous avons apporté à BusLogic un environnement de test que leurs propres équi-
pes ne pouvaient pas avoir  et la communauté Linuxienne a disposé de contrôleurs de
hautes  performances  qui avaient  correctement été testés sur Linux avant même que
les  produits ne soient  commercialisés. Cette  relation avec BusLogic m'a en outre
donné  l'occasion d'interagir  directement avec leur  équipe technique  et ainsi de
leur  donner connaissance des besoins et des potentialités du monde Linux. Leur in-
térêt et leur support sont très appréciés.
Contrairement  à d'autres  vendeurs, si vous contactez le support technique de Bus-
Logic et que vous annoncez que vous tournez sous Linux, ils ne vont pas vous rétor-
quer que votre utilisation de leur produit n'est pas supportée. Leurs dernières pu-
blications commerciales mentionnent même "Les contrôleurs SCSI BusLogic sont compa-
tibles avec tous les systèmes d'exploitation importants, incluant : ... Linux ...".
BusLogic, Inc. se trouve à 4151  Burton Drive, Santa Clara, California, 95054, USA,
et vous pouvez les contacter par  téléphone au 408/492-9090 ou  par fax au 408/492-
1542. BusLogic dispose d'un  site Web (http://www.buslogic.com), d'un site FTP ano-
nyme (ftp.buslogic.com)  et d'une BBS au 408/492-1984. Le support technique de Bus-
Logic  peut être joint par  courrier électronique à l'adresse techsup@buslogic.com,
par  téléphone au 408/654-0760 ou par fax au  408/492-1542. Des  renseignements sur
leurs réprésentants en Europe et au Japon sont disponibles sur leur site Web.
 LES CONTROLEURS GERES
La  liste  suivante comporte les  contrôleurs  SCSI BusLogic  gérés à la date de ce
document.  Il est  recommandé qu'une  personne se  portant  acquéreur  d'une  carte
BusLogic  non listée  dans la table  suivante contacte l'auteur de ce document pour
vérifier si elle est supportée ou si elle le sera un jour.
Les séries "W" :
BT-948      PCI     Ultra Fast Terminaison unique SCSI-2
BT-958      PCI     Ultra Wide Terminaison unique SCSI-2
BT-958D     PCI     Ultra Wide Différentielle SCSI-2
Les séries "C" :
BT-946C     PCI     Fast Terminaison unique SCSI-2
BT-956C     PCI     Fast Wide Terminaison unique SCSI-2
BT-956CD    PCI     Fast Wide Différentielle SCSI-2
BT-445C     VLB     Fast Terminaison unique SCSI-2
BT-747C     EISA    Fast Terminaison unique SCSI-2
BT-757C     EISA    Fast Wide Terminaison unique SCSI-2
BT-757CD    EISA    Fast Wide Différentielle SCSI-2
BT-545C     ISA     Fast Terminaison unique SCSI-2
BT-540CF    ISA     Fast Terminaison unique SCSI-2
Les séries "S":
BT-445S     VLB     Fast Terminaison unique SCSI-2
BT-747S     EISA    Fast Terminaison unique SCSI-2
BT-747D     EISA    Fast Différentielle SCSI-2
BT-757S     EISA    Fast Wide Terminaison unique SCSI-2
BT-757D     EISA    Fast Wide Différentielle SCSI-2
BT-545S     ISA     Fast Terminaison unique SCSI-2
BT-542D     ISA     Fast Différentielle SCSI-2
BT-742A     EISA    Terminaison unique SCSI-2 (742A version H)
BT-542B     ISA     Terminaison unique SCSI-2 (542B version H)
Les séries "A" :
BT-742A     EISA    Terminaison unique SCSI-2 (742A versions A - G)
BT-542B     ISA     Terminaison unique SCSI-2 (542B versions A - G)
Les contrôleurs AMI FastDisk, véritables clones BusLogic, sont gérés par ce pilote.
 REMARQUES SUR L'INSTALLATION DES CARTES BT-948/958/958D
Les  contrôleurs SCSI BT-948/958/958D PCI Ultra ont des fonctionnalités qui peuvent
nécessiter une certaine attention lors de l'installation de Linux.
o Affectation des ports d'entrée/sortie PCI
 Lorsqu'elles  sont  configurées avec les valeurs par défaut usine, les cartes BT-
 948/958/958D vont  uniquement reconnaître les affectations des ports d'E/S faites
 par le BIOS  PCI de la  carte mère. Les  BT-948/958/958D ne  répondront  plus aux
 ports d'E/S compatibles ISA auxquels les contrôleurs SCSI BusLogic précédents ré-
 pondaient. Le pilote gère les affectations des ports d'E/S PCI. C'est la configu-
 ration à privilégier. Toutefois, si le pilote BusLogic obsolete doit être utilisé
 pour une raison quelconque, comme par exemple une distribution Linux qui n'utili-
 serait pas encore le nouveau pilote dans son noyau de démarrage, BusLogic a fourni
 une option de configuration AutoSCSI qui autorise les ports d'E/S compatibles ISA.
 Pour  activer  cette  option de  compatibilité  ascendante, appelez  l'utilitaire
 AutoSCSI  par  CTRL-B au démarrage du système  et  choisissez "Adapter Configura-
 tion",  "View/Modify Configuration", puis  changez les paramètres "ISA Compatible
 Port"  de "Disable"  à "Primary"  ou "Alternate". Une  fois que  ce  pilote a été
 installé, l'option "ISA Compatible Port" doit être remise à "Disable" pour éviter
 tout conflit de futurs ports  d'E/S. Les anciennes  cartes BT-946C/956C/956CD ont
 également cette option de configuration, mais le défaut usine est "Primary".
o L'ordre de scrutation des emplacements PCI
 Dans les  systèmes  comportant  plusieurs  contrôleurs PCI BusLogic, l'ordre dans
 lequel les  emplacements PCI sont scrutés peut apparaître inversé pour les cartes
 BT-948/958/958D par rapport aux cartes  BT-946C/956C/956CD. Pour démarrer  depuis
 un disque SCSI, il est  nécessaire que le  BIOS du contrôleur et  le noyau soient
 d'accord  sur quel  disque est le disque de  démarrage (boot disk). Cela implique
 qu'ils reconnaissent les  contrôleurs PCI dans  le même ordre. Le  BIOS PCI de la
 carte mère fournit un moyen standard d'énumérer les contrôleurs PCI. Ce moyen est
 utilisé par le noyau Linux. Certaines  implémentations du BIOS PCI  énumèrent les
 emplacements PCI par ordre croissant des numéros de bus et des numéros de contrô-
 leurs, alors que d'autres le font dans le sens contraire.
 Malheureusement,  Microsoft  a  décidé  que Windows 95  énumérerait  toujours les
 emplacements  PCI  dans l'ordre  croissant des  numéros  de bus et des numéros de
 contrôleurs indépendamment de l'énumération du BIOS PCI  et ils ont exigé que leur
 façon de faire soit  supportée par le  BIOS des  contrôleurs pour  être  certifié
 Windows 95. En  conséquence, les défauts usine des cartes BT-948/958/ 958D énumè-
 rent les contrôleurs par numéros croissants. Pour  désactiver ce  fonctionnement,
 appelez l'utilitaire AutoSCSI par CTRL-B au démarrage du système, puis choisissez
 "Adapter Configuration",  "View/Modify Configuration",  appuyez sur  CTRL-F10 et
 changez l'option "Use Bus And Device # For PCI Scanning Seq." à 0FF.
 Ce pilote va interroger la valeur de l'option de  Séquence De Scrutation PCI,  de
 manière  à reconnaître les contrôleurs dans le même ordre qu'ils ont été énumérés
 par le BIOS du contrôleur.
 LA LISTE DE DIFFUSION DES ANNONCES BUSLOGIC
La  liste de diffusion des  annonces BusLogic constitue un forum d'information pour
les  utilisateurs Linux des  nouveautés (nouvelles  versions du  pilote  et  autres
annonces  concernant le  support pour  Linux des  contrôleurs  BusLogic). Pour vous
inscrire à la liste, envoyez un message à l'adresse suivante :
"BusLogic-announce-request@dandelion.com", avec la ligne  "subscribe" dans le corps
du message.

5.9 Les contrôleurs BusLogic FlashPoint

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

Il  n'y a pas de pilote Linux pour les cartes FlashPoint LT/DL/LW (BT-930/932/950),
et quand il va y en avoir ou s'il y en aura n'est pas très clair. Les cartes Flash-
Point  ont une  architecture différente des  cartes Multi-Maîtres  et  n'ont pas de
processeurs  sur la carte ; elles disposent d'un simple séquenceur SCSI. Elles sont
conçues pour les ordinateurs  de bureau  et ne sont pas  spécialement conçues  pour
des systèmes d'exploitation multitâches performants comme Linux.
Les  cartes Multi-Maîtres BT-948/958 ont  un processeur  embarqué et l'interface de
programmation  par "boîte à lettres"  permet de faire du parallélisme et du pipeli-
ning  entre le contrôleur et le système d'exploitation, alors que les cartes Flash-
Point nécessitent de fréquentes interventions du processeur principal. Etant  donné
que les  délais de  prise en  compte des  interruptions  augmentent sur  un système
chargé, les BT-948/958 continuent d'avoir d'excellentes  performances au  contraire
des FlashPoint, qui  s'écroulent  rapidement. De plus, le  firmware des  BT-948/958
possède la  connaissance  de bas niveau pour une  interaction  efficace avec le bus
SCSI. Avec un  séquenceur  SCSI comme dans les  FlashPoint, le  noyau Linux doit en
revanche contenir  lui-même  toutes ces  informations de  bas niveau,  et il est en
général long d'arriver à faire marcher tout cela proprement. Etant  donné le faible
écart de prix entre  ces deux  modèles, les  cartes BT-948 et  BT-958 sont de toute
évidence le meilleur choix pour Linux.
<début de citation> ANNONCE
 Mise à jour des BusLogic FlashPoint vers les BT-948
 1er Février 1996
Depuis  leur  apparition en Octobre 1995, les  BusLogic  FlashPoint  LT  ont  posé
des  problèmes  sous  Linux, si  bien  qu'aucun  pilote  n'est  encore  disponible
pour  cette  nouvelle  carte  Ultra SCSI. Bien que le produit  soit officiellement
déclaré  comme  une carte pour machine de bureau  et ne  soit pas particulièrement
efficace  dans  des environnements  multitâches  performants  tels  que  Linux, la
FlashPoint LT  a été annoncée  comme étant le dernier cri, le  nec plus ultra, par
les vendeurs d'ordinateurs  et elle s'est retrouvée sur certains de leurs systèmes
haut de gamme, à l'exclusion  de ceux équipés  des anciennes cartes Multi-Maîtres.
Cela  a  causé du tort à de  nombreuses personnes  qui  ont  par mégarde acheté un
système en s'attendant à ce que tous les produits BusLogic soient gérés par Linux,
et qui  ont finalement  découvert que la FlashPoint n'était pas supportée et ne le
serait pas avant longtemps, si elle devait l'être un jour.
Après  que  ce  problème a  été  identifié, BusLogic  est entrée  en contact  avec
ses  principaux clients  OEM pour  annoncer que les cartes  Multi-Maîtres BT-946C/
956C seraient  toujours disponibles,  et  que les  utilisateurs  Linux qui avaient
par  mégarde  commandé des systèmes à base  de FlashPoint pourraient mettre à jour
leur  machine avec une BT-946C. Si cela a aidé de nouveaux acheteurs, cela n'était
qu'une solution partielle au problème plus général du support de la FlashPoint pour
les  utilisateurs  de  Linux. Cette  annonce n'apportait  aucun soutien à ceux qui
avaient  initialement acheté une FlashPoint pour  un système d'exploitation qui la
gérait  et qui décidaient plus tard de passer à Linux ou  ceux qui avaient acheté
une  FlashPoint,  croyant  qu'elle était  gérée  et  qui étaient  incapables de la
retourner.
Mi-Décembre,  j'ai demandé à  rencontrer le  responsable de la gestion de BusLogic
pour  discuter  du support pour le  logiciel libre (free software)  et pour  Linux
de la FlashPoint. Des  bruits plus ou moins  exacts avaient  circulé  publiquement
sur l'attitude  de BusLogic  envers Linux  et  j'avais le sentiment  que le  mieux
était d'en  discuter  directement. J'envoyai  un message par  email un  soir  à 11
heures  et  la  réunion  eut lieu  le lendemain  après-midi. Malheureusement,  les
rouages  administratifs tournent lentement, particulièrement  lorsqu'une compagnie
est en cours d'acquisition, c'est pourquoi il a fallu attendre jusqu'à  maintenant
que tous les détails soient parfaitement clairs et qu'une annonce publique  puisse
être faite.
BusLogic  n'est  pas  prête  aujourd'hui  à publier  les  informations nécessaires
à ce  que des parties  tierces puissent  écrire des pilotes  pour  la  FlashPoint.
Les  seuls pilotes  existants pour  la FlashPoint  ont  été  écrits  par  l'équipe
technique de BusLogic  et il n'existe pas de documentation suffisamment  détaillée
pour permettre à un développeur extérieur d'écrire un pilote sans aide conséquente.
Alors  qu'il y a des gens  chez BusLogic  qui ne veulent  pas entendre  parler  de
divulgation  de détails  sur l'architecture  de la  FlashPoint, le débat n'est pas
entièrement  clos. Dans tous les cas, même  si la documentation  était  disponible
aujourd'hui, il faudrait certainement pas mal de temps pour qu'un pilote réellement
utilisable soit écrit, surtout que je ne suis pas convaincu que l'effort en vaille
la peine.
De toute façon, BusLogic continue à fournir une solution SCSI de hautes performan-
ces pour Linux  et ils ne désirent pas voir quelqu'un incapable de travailler sous
Linux  sous prétexte qu'il a une FlashPoint LT. En conséquence, BusLogic  a mis en
place un programme de mise à jour permettant à n'importe quel utilisateur de Linux
dans le monde de changer sa FlashPoint LT pour une nouvelle carte BT-948 Multi-Maî-
tres  PCI Ultra SCSI. La BT-948  est  la successeur  Ultra SCSI de  la BT-946C, et
possède  toutes les  fonctionnalités des contrôleurs BT-946C et  FlashPoint  LT, y
compris une terminaison adaptative (smart termination) et une PROM  flashable pour
faciliter les mises à jour du firmware. Elle est bien sûr compatible avec le pilote
actuel de Linux. Le prix pour cette mise à jour a été fixé à 45 dollars américains,
et  le programme de mise à jour est  réalisé par le Support Technique de BusLogic,
qui peut être contacté par courrier électronique à l'adresse techsup@BusLogic.com,
par téléphone au +1 408 654-0760 ou par fax au +1 408 492-1542.
J'ai un site en bêta test pour le contrôleur BT-948 et les versions 1.2.1  et 1.3.1
de mon pilote BusLogic contiennent déjà le support pour les BT-948. Une gestion sup-
plémentaire (non indispensable) pour les cartes Multi-Maîtres Ultra SCSI sera ajou-
tée dans une future version. En résultat de ce mécanisme de test 'coopératif', plu-
sieurs  problèmes du firmware  ont été décelés et  corrigés (assurez-vous que vous
avez  la version 5.05R ou plus). Mon système de test Linux très chargé a fourni un
environnement de test idéal pour tester le mécanisme de détection et de correction
d'erreurs  SCSI, qui  est bien moins  souvent mis en évidence sur les  machines de
production,  mais qui est crucial pour la  stabilité générale du système. Il a été
très pratique de pouvoir travailler directement avec leur ingénieur responsable du
firmware en reproduisant les problèmes sous le contrôle de l'environnement de debug
du firmware. Il est certain que les  techniques ont  énormément évolué  depuis  le
temps où je  travaillais sur un  firmware pour du  matériel embarqué. Je travaille
actuellement sur des  mesures de performances  et j'espère avoir prochainement des
chiffres et des statistiques.
BusLogic  m'a demandé d'envoyer cette  annonce puisqu'un important pourcentage des
questions  relatives au  support de la  FlashPoint m'a  directement été envoyé par
email ou a été posté dans les groupes de news de Linux auxquels je participe. Pour
résumer, BusLogic offre aux  utilisateurs Linux de mettre à jour leur carte Flash-
Point LT (BT-930) non gérée par une carte gérée BT-948 pour une somme de 45 dollars
américains.
Contactez le support technique de BusLogic à l'adresse techsup@BusLogic.com ou au
+1 408 654-0760 pour bénéficier de leur offre.
 Leonard N. Zubkoff
 lnz@dandelion.com
<fin de citation>

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

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

Parmi ces cartes, on trouve :

La famille des DPT Smartcache (Plus) :
PM2011      ISA     Fast Terminaison unique SCSI-2
PM2012B     EISA    Fast Terminaison unique SCSI-2
La famille des DPT Smartcache III :
PM2021      ISA     Fast Terminaison unique SCSI-2
PM2021W     ISA     Wide Terminaison unique SCSI-2
PM2022      EISA    Fast Terminaison unique SCSI-2
PM2022W     EISA    Wide Terminaison unique SCSI-2
PM2024      PCI     Fast Terminaison unique SCSI-2
PM2024W     PCI     Wide Terminaison unique SCSI-2
PM2122      EISA    Fast Terminaison unique SCSI-2
PM2122W     EISA    Wide Terminaison unique SCSI-2
PM2124      PCI     Fast Terminaison unique SCSI-2
PM2124W     PCI     Wide Terminaison unique SCSI-2
PM2322      EISA    Fast Terminaison unique SCSI-2
PM2322W     EISA    Wide Terminaison unique SCSI-2
La famille des DPT Smartcache VI :
PM2041W     ISA     Wide Terminaison unique SCSI-2
PM2041UW    ISA     Ultra Wide Terminaison unique SCSI-2
PM2042W     EISA    Wide Terminaison unique SCSI-2
PM2042UW    EISA    Ultra Wide Terminaison unique SCSI-2
PM2044W     PCI     Wide Terminaison unique SCSI-2
PM2044UW    PCI     Ultra Wide Terminaison unique SCSI-2
PM2142W     EISA    Wide Terminaison unique SCSI-2
PM2142UW    EISA    Ultra Wide Terminaison unique SCSI-2
PM2144W     PCI     Wide Terminaison unique SCSI-2
PM2144UW    PCI     Ultra Wide Terminaison unique SCSI-2
PM2322W     EISA    Wide Terminaison unique SCSI-2
PM2322UW    EISA    Ultra Wide Terminaison unique SCSI-2
La famille des DPT SmartRAID :
PM3021      ISA     Fast Terminaison unique SCSI-2
PM3021W     ISA     Wide Terminaison unique SCSI-2
PM3122      EISA    Fast Terminaison unique SCSI-2
PM3122W     EISA    Wide Terminaison unique SCSI-2
PM3222      EISA    Fast Terminaison unique SCSI-2
PM3222W     EISA    Wide Terminaison unique SCSI-2
PM3224      PCI     Fast Terminaison unique SCSI-2
PM3224W     PCI     Wide Terminaison unique SCSI-2
PM3334W     PCI     Wide Terminaison unique SCSI-2
PM3334UW    PCI     Ultra Wide Terminaison unique SCSI-2

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

et quelques contrôleurs de :

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

Configurations supportées :

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

Auto-détection :

fonctionne avec toutes les configurations gérées

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

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

Liste de diffusion :

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

Support du répertoire /proc/scsi :

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

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

Pour ensuite désactiver les statistiques, faites :

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

Problèmes habituels :

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

    Solution : utilisez une des disquettes de boot ascsi*.

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

Remarques :

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

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

Configurations supportées :

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

Auto-détection :

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

Surcharge de l'auto-détection :

aucune

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

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

Remarque :

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

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

Configurations supportées et non supportées :

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

Auto-détection :

aucune

Surcharge de l'auto-détection :

A la compilation :

définissez GENERIC_NCR5380_OVERRIDE. Ce doit être un tableau de
nuplets de la forme {'port', 'irq', 'dma', 'type de carte'}. Par exemple :
#define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}}
pour une carte NCR5380 de port 0x330 et d'IRQ 5.
#define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}}
pour une carte T130B sur le port 0x350.
Les vieilles versions du code suppriment l'entrée BOARD_*.
Les valeurs symboliques IRQ_NONE et IRQ_AUTO peuvent être employées pour le
champ IRQ.

Ligne de commande du noyau :

ncr5380=port,irq
ncr5380=port,irq,dma
ncr53c400=port,irq
255 peut être utilisé pour 'pas d'irq' et 254 pour 'auto-détection de l'irq'.

Problèmes fréquents :

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

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

    ncr5380=0x358,254
    

    sur la ligne de commande du noyau.

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

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

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

Remarques :

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

5.13 NCR53c8xx (standard)

Configurations supportées et non supportées :

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

Auto-détection :

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

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

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

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

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

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

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

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

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

    Ces patches devraient s'appliquer sans problèmes.

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

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

    subscribe ncr53c810
    

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

    unsubscribe ncr53c810
    

Problèmes fréquents :

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

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

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

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

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

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

Remarques :

  1. CONFIG_PCI doit être positionnée

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

Configurations supportées et non supportées :

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

Auto-détection :

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

Surcharge de l'auto-détection :

A la compilation :

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

Ligne de commande du noyau :

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

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

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

Problèmes fréquents :

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

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

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

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

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

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

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

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

Le code du fichier seagate.c ressemble maintenant à :

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

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

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

Constantes :

FAST ou FAST32 pour la mise en oeuvre de transferts aveugles
ARBITRATE      va forcer le contrôleur à arbitrer le bus en mode de
 compatibilité SCSI-II, plutôt que d'attendre le signal BUS FREE
 avant de continuer. Cela devrait nous permettre de traiter une
 commande par unité logique le jour où j'intégrerai mes
 modifications de réorganisation dans les sources de
 l'arborescence de référence.
SLOW_HANDSHAKE autorise la compatibilité avec des périphériques déficients,
 qui n'acquittent pas suffisamment rapidement (par exemple
 certains lecteurs de CDROM) pour le code des cartes Seagate.
SLOW_RATE=x,   x étant un entier spécifiant un taux de transfert par défaut
 si le protocole d'acquittement (handshaking) ne fonctionne
 pas correctement.

5.15 PAS16 SCSI (standard)

Configurations supportées et non supportées :

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

Auto-détection :

n'a pas besoin du BIOS

Surcharge de l'auto-détection :

A la compilation : définissez PAS16_OVERRIDE comme un tableau de nuplets
de la forme {'port', 'irq'}. Par exemple :
#define PAS16_OVERRIDE {{0x388, 10}}
pour une carte de port 0x388, IRQ 10.

Ligne de commande du noyau :

pas16=port,irq

Constantes :

AUTOSENSE  - si elle est définie, la commande SCSI 'REQUEST SENSE' sera
 automatiquement émise pour les commandes qui se terminent
 avec un status 'CHECK CONDITION'.
PSEUDO_DMA - autorise le PSEUDO-DMA matériel ; devrait résulter en un
 gain de performance de l'ordre de x3 / x4 par rapport aux
 E/S scrutées (polled I/O).
PARITY     - activation du contrôle de parité. N'est pas géré.
SCSI2      - activation de la gestion de 'files marquées' pour le SCSI-II
 (SCSI-II tagged queuing). Non testé.
UNSAFE     - autorise les interruptions pendant les transferts
 pseudo-DMA. Vous activerez cela uniquement si vous avez
 des problèmes de perte de caractères durant les
 communications à haute vitesse. Cependant, même dans ce cas,
 vous auriez plutôt intérêt à jouer avec les tailles de blocs de
 transfert.
USLEEP     - autorise la gestion des périphériques qui ne se déconnectent
 pas. Non testé.

Problèmes fréquents :

  1. Commandes en timeouts, interruptions, etc.

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

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

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

5.16 Trantor T128/T128F/T228 (standard)

Configurations supportées et non supportées :

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

Auto-détection :

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

Surcharge de l'auto-détection :

A la compilation : la variable T128_OVERRIDE doit être un tableau
de nuplets de la forme {'adresse', 'irq'}. Par exemple :
#define T128_OVERRIDE {{0xcc000, 5}}
pour une carte à l'adresse 0xcc000, IRQ 5.
Les valeurs symboliques IRQ_NONE et IRQ_AUTO peuvent être employées pour le
champ IRQ.

Ligne de commande du noyau :

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

Constantes :

AUTOSENSE  - si elle est définie, la commande SCSI 'REQUEST SENSE' sera
 automatiquement émise pour les commandes qui se terminent
 avec un status 'CHECK CONDITION'.
PSEUDO_DMA - autorise le PSEUDO-DMA matériel ; devrait résulter en un
 gain de performance de l'ordre de x3 / x4 par rapport aux
 E/S scrutées (polled I/O).
PARITY     - activation du contrôle de parité. N'est pas géré.
SCSI2      - activation de la gestion de 'files marquées' pour le SCSI-II
UNSAFE     - autorise les interruptions pendant les transferts
 pseudo-DMA. Vous activerez cela uniquement si vous avez
 des problèmes de perte de caractères durant les
 communications à haute vitesse. Cependant, même dans ce cas,
 vous auriez tout intérêt à jouer avec les tailles de blocs de
 transfert.
USLEEP     - autorise la gestion des périphériques qui ne se déconnectent
 pas. Non testé.

Problèmes fréquents :

  1. Commandes en timeouts, interruptions, etc.

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

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

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

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

Configurations supportées :

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

Auto-détection :

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

Surcharge de l'auto-détection :

uniquement à la compilation (définissez PORT_OVERRIDE)

Problèmes fréquents :

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

5.18 Western Digital 7000 (standard)

Configurations supportées :

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

Auto-détection :

nécessite un BIOS activé.

Problèmes fréquents :

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

5.19 AM53/79C974 (ALPHA)

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

Configurations supportées :

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

5.20 qlogic (standard)

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


Page suivantePage précédenteTable des matières