Rechercher  

5. Cartes d'interface

Contenu de cette section

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 ete developpe mais il ne marche toujours pas avec les
composants NCR53c700, NCR53c700-66, NCR53c710 et NCR53c720. Une liste des
modifications necessaires pour le faire marcher sur chacun de ces composants
est fournie ci-apres, accompagnee d'un resume de la difficulte de chaque patch.

NCR53c720 (facile) - modifications dans la detection 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 detection 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'emuler (Note aux relecteurs (a supprimer dans la version
definitive) je ne suis pas sur 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 (tres complique) - modifications dans la detection
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 a dire que les octets doivent etre 
   
   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" (&amp;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" (&amp;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" (&amp;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" (&amp;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" (&amp;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" (&amp;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" (&amp;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" (&amp;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 utilise
E/S : port mappe

Auto-détection :

Cela marche avec de nombreuses cartes qui ont un BIOS installe. Toutes les autres cartes,
y compris les Adaptec 1510 et les Sound Blaster 16 SCSI, necessitent 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 :

Definissez PORTBASE, IRQ, SCSI_ID, RECONNECT, PARITE de maniere adequate (voir Definitions)

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 reportee par le controleur (uniquement pour les 152x)
IRQ : surcharge du niveau d'interruption (9,10,11 ou 12) (11 par defaut)
SCSI_ID : surcharge du SCSI ID de l'AIC-6260 (0-7) (7 par defaut)
RECONNECT : surcharge l'indicateur de deconnexion/reselection (une valeur non nulle
signifie 'autoriser', une valeur nulle signifie 'interdire')
DONT_SNARF : n'enregistre pas les ports (pl12 et inferieurs)
SKIP_BIOSTEST : ne teste pas la signature du BIOS (pour la AHA-1510 ou en cas de BIOS debraye)
PORTBASE : force le port de base. Il ne faut pas essayer l'auto-detection

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 mappe, controle de bus (bus master)

Auto-détection :

detecte 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' :
   • support du BIOS pour le mapping étendu des disques > 1G
   • support du BIOS pour plus de 2 disques
   • support du BIOS pour la scrutation automatique du bus SCSI

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 mappe, controle de bus

Auto-détection :

fonctionne avec toutes les configurations gerees

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 mappe, controle de bus

Surcharge de l'auto-détection :

Ligne de commande du noyau :

aha274x=extended
(pour forcer le mapping etendu)

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 utilise
E/S : port mappe

Auto-détection :

le BIOS n'est pas necessaire

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-Maitres 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. concoit et fabrique un ensemble de controleurs SCSI de hautes
performances, qui partagent une interface de programmation commune pour diverses
architectures de bus, par le biais de leur technologie ASIC Multi-Maitres (Multi-
Master ASIC). Ce pilote gere tous les controleurs BusLogic Multi-Maitres actuels,
et devrait gerer toutes les cartes Multi-Maitres a venir avec peu (voire aucune) de
modifications. Les controleurs bases sur la nouvelle architecture FlashPoint ne
sont pas geres par ce pilote ; reportez-vous au fichier README.FlashPoint pour la
marche a suivre pour passer d'une carte FlashPoint LT non geree a une carte BT-948
supportee.

Mes buts principaux lorsque j'ai ecrit ce pilote BusLogic completement nouveau pour
Linux etaient d'exploiter les performances maximales que les controleurs SCSI Bus-
Logic et les peripheriques SCSI modernes sont capables d'atteindre et de fournir
un pilote extremement fiable sur lequel des applications critiques puissent s'appu-
yer. Tout peut etre configure sur la ligne de commande du noyau, des performances
jusqu'aux detections d'erreurs. Cela permet a chaque installation d'ajuster les pa-
rametres de performance et de gestion des erreurs aux besoins locaux.

BusLogic est une compagnie avec laquelle il a ete tres agreable de travailler, et
je recommande chaleureusement leurs produits a la communaute Linuxienne. En Novem-
bre 1995, j'ai eu l'opportunite de devenir site beta testeur pour leur dernier pro-
duit Multi-Maitres - le controleur SCSI BT-948 PCI Ultra -, puis de nouveau pour le
controleur BT-958 PCI Wide Ultra en Janvier 1996. Cela a ete un benefice reciproque,
car nous avons apporte a BusLogic un environnement de test que leurs propres equi-
pes ne pouvaient pas avoir et la communaute Linuxienne a dispose de controleurs de
hautes performances qui avaient correctement ete testes sur Linux avant meme que
les produits ne soient commercialises. Cette relation avec BusLogic m'a en outre
donne l'occasion d'interagir directement avec leur equipe technique et ainsi de
leur donner connaissance des besoins et des potentialites du monde Linux. Leur in-
teret et leur support sont tres apprecies.

Contrairement a 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 retor-
quer que votre utilisation de leur produit n'est pas supportee. Leurs dernieres pu-
blications commerciales mentionnent meme "Les controleurs SCSI BusLogic sont compa-
tibles avec tous les systemes d'exploitation importants, incluant : ... Linux ...".

BusLogic, Inc. se trouve a 4151 Burton Drive, Santa Clara, California, 95054, USA,
et vous pouvez les contacter par telephone 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 etre joint par courrier electronique a l'adresse techsup@buslogic.com,
par telephone au 408/654-0760 ou par fax au 408/492-1542. Des renseignements sur
leurs representants en Europe et au Japon sont disponibles sur leur site Web.

LES CONTROLEURS GERES

La liste suivante comporte les controleurs SCSI BusLogic geres a la date de ce
document. Il est recommande qu'une personne se portant acquereur d'une carte
BusLogic non listee dans la table suivante contacte l'auteur de ce document pour
verifier si elle est supportee ou si elle le sera un jour.

Les series "W" :

BT-948 PCI Ultra Fast Terminaison unique SCSI-2
BT-958 PCI Ultra Wide Terminaison unique SCSI-2
BT-958D PCI Ultra Wide Differentielle SCSI-2

Les series "C" :

BT-946C PCI Fast Terminaison unique SCSI-2
BT-956C PCI Fast Wide Terminaison unique SCSI-2
BT-956CD PCI Fast Wide Differentielle 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 Differentielle SCSI-2
BT-545C ISA Fast Terminaison unique SCSI-2
BT-540CF ISA Fast Terminaison unique SCSI-2

Les series "S": 

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

Les series "A" :

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

Les controleurs AMI FastDisk, veritables clones BusLogic, sont geres par ce pilote.

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

Les controleurs SCSI BT-948/958/958D PCI Ultra ont des fonctionnalites qui peuvent
necessiter une certaine attention lors de l'installation de Linux.

o Affectation des ports d'entree/sortie PCI

Lorsqu'elles sont configurees avec les valeurs par defaut usine, les cartes BT-
948/958/958D vont uniquement reconnaitre les affectations des ports d'E/S faites
par le BIOS PCI de la carte mere. Les BT-948/958/958D ne repondront plus aux
ports d'E/S compatibles ISA auxquels les controleurs SCSI BusLogic precedents re-
pondaient. Le pilote gere les affectations des ports d'E/S PCI. C'est la configu-
ration a privilegier. Toutefois, si le pilote BusLogic obsolete doit etre utilise
pour une raison quelconque, comme par exemple une distribution Linux qui n'utili-
serait pas encore le nouveau pilote dans son noyau de demarrage, BusLogic a fourni
une option de configuration AutoSCSI qui autorise les ports d'E/S compatibles ISA.

Pour activer cette option de compatibilite ascendante, appelez l'utilitaire
AutoSCSI par CTRL-B au demarrage du systeme et choisissez "Adapter Configura-
tion", "View/Modify Configuration", puis changez les parametres "ISA Compatible
Port" de "Disable" a "Primary" ou "Alternate". Une fois que ce pilote a ete
installe, l'option "ISA Compatible Port" doit etre remise a "Disable" pour eviter
tout conflit de futurs ports d'E/S. Les anciennes cartes BT-946C/956C/956CD ont
egalement cette option de configuration, mais le defaut usine est "Primary".

o L'ordre de scrutation des emplacements PCI

Dans les systemes comportant plusieurs controleurs PCI BusLogic, l'ordre dans
lequel les emplacements PCI sont scrutes peut apparaitre inverse pour les cartes
BT-948/958/958D par rapport aux cartes BT-946C/956C/956CD. Pour demarrer depuis
un disque SCSI, il est necessaire que le BIOS du controleur et le noyau soient
d'accord sur quel disque est le disque de demarrage (boot disk). Cela implique
qu'ils reconnaissent les controleurs PCI dans le meme ordre. Le BIOS PCI de la
carte mere fournit un moyen standard d'enumerer les controleurs PCI. Ce moyen est
utilise par le noyau Linux. Certaines implementations du BIOS PCI enumerent les
emplacements PCI par ordre croissant des numeros de bus et des numeros de contro-
leurs, alors que d'autres le font dans le sens contraire.

Malheureusement, Microsoft a decide que Windows 95 enumererait toujours les
emplacements PCI dans l'ordre croissant des numeros de bus et des numeros de
controleurs independamment de l'enumeration du BIOS PCI et ils ont exige que leur
facon de faire soit supportee par le BIOS des controleurs pour etre certifie
Windows 95. En consequence, les defauts usine des cartes BT-948/958/ 958D enume-
rent les controleurs par numeros croissants. Pour desactiver ce fonctionnement,
appelez l'utilitaire AutoSCSI par CTRL-B au demarrage du systeme, puis choisissez
"Adapter Configuration", "View/Modify Configuration", appuyez sur CTRL-F10 et
changez l'option "Use Bus And Device # For PCI Scanning Seq." a 0FF.

Ce pilote va interroger la valeur de l'option de Sequence De Scrutation PCI, de
maniere a reconnaitre les controleurs dans le meme ordre qu'ils ont ete enumeres
par le BIOS du controleur.

LA LISTE DE DIFFUSION DES ANNONCES BUSLOGIC

La liste de diffusion des annonces BusLogic constitue un forum d'information pour
les utilisateurs Linux des nouveautes (nouvelles versions du pilote et autres
annonces concernant le support pour Linux des controleurs BusLogic). Pour vous
inscrire a la liste, envoyez un message a 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 tres clair. Les cartes Flash-
Point ont une architecture differente des cartes Multi-Maitres et n'ont pas de
processeurs sur la carte ; elles disposent d'un simple sequenceur SCSI. Elles sont
concues pour les ordinateurs de bureau et ne sont pas specialement concues pour
des systemes d'exploitation multitaches performants comme Linux.

Les cartes Multi-Maitres BT-948/958 ont un processeur embarque et l'interface de
programmation par "boite a lettres" permet de faire du parallelisme et du pipeli-
ning entre le controleur et le systeme d'exploitation, alors que les cartes Flash-
Point necessitent de frequentes interventions du processeur principal. Etant donne
que les delais de prise en compte des interruptions augmentent sur un systeme
charge, les BT-948/958 continuent d'avoir d'excellentes performances au contraire
des FlashPoint, qui s'ecroulent rapidement. De plus, le firmware des BT-948/958
possede la connaissance de bas niveau pour une interaction efficace avec le bus
SCSI. Avec un sequenceur SCSI comme dans les FlashPoint, le noyau Linux doit en
revanche contenir lui-meme toutes ces informations de bas niveau, et il est en
general long d'arriver a faire marcher tout cela proprement. Etant donne le faible
ecart de prix entre ces deux modeles, les cartes BT-948 et BT-958 sont de toute
evidence le meilleur choix pour Linux.

<debut de citation>

ANNONCE
Mise a jour des BusLogic FlashPoint vers les BT-948
1er Fevrier 1996

Depuis leur apparition en Octobre 1995, les BusLogic FlashPoint LT ont pose
des problemes sous Linux, si bien qu'aucun pilote n'est encore disponible
pour cette nouvelle carte Ultra SCSI. Bien que le produit soit officiellement
declare comme une carte pour machine de bureau et ne soit pas particulierement
efficace dans des environnements multitaches performants tels que Linux, la
FlashPoint LT a ete annoncee comme etant le dernier cri, le nec plus ultra, par
les vendeurs d'ordinateurs et elle s'est retrouvee sur certains de leurs systemes
haut de gamme, a l'exclusion de ceux equipes des anciennes cartes Multi-Maitres.
Cela a cause du tort a de nombreuses personnes qui ont par megarde achete un
systeme en s'attendant a ce que tous les produits BusLogic soient geres par Linux,
et qui ont finalement decouvert que la FlashPoint n'etait pas supportee et ne le
serait pas avant longtemps, si elle devait l'etre un jour.

Apres que ce probleme a ete identifie, BusLogic est entree en contact avec
ses principaux clients OEM pour annoncer que les cartes Multi-Maitres BT-946C/
956C seraient toujours disponibles, et que les utilisateurs Linux qui avaient
par megarde commande des systemes a base de FlashPoint pourraient mettre a jour
leur machine avec une BT-946C. Si cela a aide de nouveaux acheteurs, cela n'etait
qu'une solution partielle au probleme plus general du support de la FlashPoint pour
les utilisateurs de Linux. Cette annonce n'apportait aucun soutien a ceux qui
avaient initialement achete une FlashPoint pour un systeme d'exploitation qui la
gerait et qui decidaient plus tard de passer a Linux ou ceux qui avaient achete
une FlashPoint, croyant qu'elle etait geree et qui etaient incapables de la
retourner.

Mi-Decembre, j'ai demande a 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 circule publiquement
sur l'attitude de BusLogic envers Linux et j'avais le sentiment que le mieux
etait d'en discuter directement. J'envoyai un message par email un soir a 11
heures et la reunion eut lieu le lendemain apres-midi. Malheureusement, les
rouages administratifs tournent lentement, particulierement lorsqu'une compagnie
est en cours d'acquisition, c'est pourquoi il a fallu attendre jusqu'a maintenant
que tous les details soient parfaitement clairs et qu'une annonce publique puisse
etre faite.

BusLogic n'est pas prete aujourd'hui a publier les informations necessaires
a ce que des parties tierces puissent ecrire des pilotes pour la FlashPoint.
Les seuls pilotes existants pour la FlashPoint ont ete ecrits par l'equipe
technique de BusLogic et il n'existe pas de documentation suffisamment detaillee
pour permettre a un developpeur exterieur d'ecrire un pilote sans aide consequente.
Alors qu'il y a des gens chez BusLogic qui ne veulent pas entendre parler de
divulgation de details sur l'architecture de la FlashPoint, le debat n'est pas
entierement clos. Dans tous les cas, meme si la documentation etait disponible
aujourd'hui, il faudrait certainement pas mal de temps pour qu'un pilote reellement
utilisable soit ecrit, surtout que je ne suis pas convaincu que l'effort en vaille
la peine.

De toute facon, BusLogic continue a fournir une solution SCSI de hautes performan-
ces pour Linux et ils ne desirent pas voir quelqu'un incapable de travailler sous
Linux sous pretexte qu'il a une FlashPoint LT. En consequence, BusLogic a mis en
place un programme de mise a jour permettant a n'importe quel utilisateur de Linux
dans le monde de changer sa FlashPoint LT pour une nouvelle carte BT-948 Multi-Mai-
tres PCI Ultra SCSI. La BT-948 est la successeur Ultra SCSI de la BT-946C, et
possede toutes les fonctionnalites des controleurs BT-946C et FlashPoint LT, y
compris une terminaison adaptative (smart termination) et une PROM flashable pour
faciliter les mises a jour du firmware. Elle est bien sur compatible avec le pilote
actuel de Linux. Le prix pour cette mise a jour a ete fixe a 45 dollars americains,
et le programme de mise a jour est realise par le Support Technique de BusLogic,
qui peut etre contacte par courrier electronique a l'adresse techsup@BusLogic.com,
par telephone au +1 408 654-0760 ou par fax au +1 408 492-1542.

J'ai un site en beta test pour le controleur BT-948 et les versions 1.2.1 et 1.3.1
de mon pilote BusLogic contiennent deja le support pour les BT-948. Une gestion sup-
plementaire (non indispensable) pour les cartes Multi-Maitres Ultra SCSI sera ajou-
tee dans une future version. En resultat de ce mecanisme de test 'cooperatif', plu-
sieurs problemes du firmware ont ete deceles et corriges (assurez-vous que vous
avez la version 5.05R ou plus). Mon systeme de test Linux tres charge a fourni un
environnement de test ideal pour tester le mecanisme de detection et de correction
d'erreurs SCSI, qui est bien moins souvent mis en evidence sur les machines de
production, mais qui est crucial pour la stabilite generale du systeme. Il a ete
tres pratique de pouvoir travailler directement avec leur ingenieur responsable du
firmware en reproduisant les problemes sous le controle de l'environnement de debug
du firmware. Il est certain que les techniques ont enormement evolue depuis le
temps ou je travaillais sur un firmware pour du materiel embarque. Je travaille
actuellement sur des mesures de performances et j'espere avoir prochainement des
chiffres et des statistiques.

BusLogic m'a demande d'envoyer cette annonce puisqu'un important pourcentage des
questions relatives au support de la FlashPoint m'a directement ete envoye par
email ou a ete poste dans les groupes de news de Linux auxquels je participe. Pour
resumer, BusLogic offre aux utilisateurs Linux de mettre a jour leur carte Flash-
Point LT (BT-930) non geree par une carte geree BT-948 pour une somme de 45 dollars
americains.

Contactez le support technique de BusLogic a l'adresse techsup@BusLogic.com ou au
+1 408 654-0760 pour beneficier 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'etat (edge triggered)
Canaux DMA : Tous les ISA, non significatifs pour les EISA/PCI
E/S : port mappe, controle de bus
Canaux SCSI : Tous

Auto-détection :

fonctionne avec toutes les configurations gerees

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 utilise
E/S : port mappe

Auto-détection :

fonctionne avec toutes les configurations gerees. Requiert un BIOS active

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 utilise
E/S : port mappe

Auto-détection :

aucune

Surcharge de l'auto-détection :

A la compilation :

definissez GENERIC_NCR5380_OVERRIDE. Ce doit etre 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'entree BOARD_*.

Les valeurs symboliques IRQ_NONE et IRQ_AUTO peuvent etre employees pour le
champ IRQ.

Ligne de commande du noyau :

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

255 peut etre utilise pour 'pas d'irq' et 254 pour 'auto-detection 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 mappe, controle de bus

Auto-détection :

requiert un BIOS PCI, utilise les routines du BIOS PCI pour rechercher les
controleurs et pour lire les donnees 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 :

   • L'IRQ que vous employez est utilisée uniquement par le composant NCR de votre carte ou par l'emplacement dans lequel la carte NCR est installée
   • Les cavaliers de sélection des IRQ pour le composant de la carte ou pour son emplacement correspondent à la configuration de la CMOS
   • Certaines cartes mères PCI savent faire une affectation "automatique" des IRQ. Cela ne fonctionnera pas.

   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 utilise
E/S : mappees en memoire

Auto-détection :

teste uniquement les adresses, le niveau d'interruption (IRQ) etant suppose
valoir 5 ; necessite un BIOS installe.

Surcharge de l'auto-détection :

A la compilation :

Definir OVERRIDE a la valeur de l'adresse de base, CONTROLLER a FD ou SEAGATE
en fonction de la configuration et IRQ a 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 recents)

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 controleur a arbitrer le bus en mode de
compatibilite SCSI-II, plutot que d'attendre le signal BUS FREE
avant de continuer. Cela devrait nous permettre de traiter une
commande par unite logique le jour ou j'integrerai mes
modifications de reorganisation dans les sources de
l'arborescence de reference.

SLOW_HANDSHAKE autorise la compatibilite avec des peripheriques deficients,
qui n'acquittent pas suffisamment rapidement (par exemple
certains lecteurs de CDROM) pour le code des cartes Seagate.

SLOW_RATE=x, x etant un entier specifiant un taux de transfert par defaut
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 etre differentes des IRQ utilisees par la
partie de gestion du son de la carte
DMA : n'est pas utilise par la partie SCSI de la carte
E/S : port mappe

Auto-détection :

n'a pas besoin du BIOS

Surcharge de l'auto-détection :

A la compilation : definissez 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 definie, la commande SCSI 'REQUEST SENSE' sera
automatiquement emise pour les commandes qui se terminent
avec un status 'CHECK CONDITION'.

PSEUDO_DMA - autorise le PSEUDO-DMA materiel ; devrait resulter en un
gain de performance de l'ordre de x3 / x4 par rapport aux
E/S scrutees (polled I/O).

PARITY - activation du controle de parite. N'est pas gere.

SCSI2 - activation de la gestion de 'files marquees' pour le SCSI-II
(SCSI-II tagged queuing). Non teste.

UNSAFE - autorise les interruptions pendant les transferts
pseudo-DMA. Vous activerez cela uniquement si vous avez
des problemes de perte de caracteres durant les
communications a haute vitesse. Cependant, meme dans ce cas,
vous auriez plutot interet a jouer avec les tailles de blocs de
transfert.

USLEEP - autorise la gestion des peripheriques qui ne se deconnectent
pas. Non teste.

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 utilise
E/S : memoire mappee

Auto-détection :

fonctionne sur toutes les configurations supportees ; necessite un BIOS
installe.

Surcharge de l'auto-détection :

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

#define T128_OVERRIDE {{0xcc000, 5}}

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

Les valeurs symboliques IRQ_NONE et IRQ_AUTO peuvent etre employees pour le
champ IRQ.

Ligne de commande du noyau :

t128=adresse,irq
-1 peut etre utilise pour "pas d'irq", -2 pour "auto-detection de l'irq".

Constantes :

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

PSEUDO_DMA - autorise le PSEUDO-DMA materiel ; devrait resulter en un
gain de performance de l'ordre de x3 / x4 par rapport aux
E/S scrutees (polled I/O).

PARITY - activation du controle de parite. N'est pas gere.

SCSI2 - activation de la gestion de 'files marquees' pour le SCSI-II

UNSAFE - autorise les interruptions pendant les transferts
pseudo-DMA. Vous activerez cela uniquement si vous avez
des problemes de perte de caracteres durant les
communications a haute vitesse. Cependant, meme dans ce cas,
vous auriez tout interet a jouer avec les tailles de blocs de
transfert.

USLEEP - autorise la gestion des peripheriques qui ne se deconnectent
pas. Non teste.

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 mappe, controle de bus

Auto-détection :

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

Surcharge de l'auto-détection :

uniquement a la compilation (definissez 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,tetes,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 mappe, controle de bus

Auto-détection :

necessite un BIOS active.

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 mappe, controle 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 ;-) ?

Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre

[22 février 2002, JDNet]