[email protected]De nombreux utilisateurs de Linux --- y compris votre serviteur ! --- aimeraient employer Linux sur une machine à bus PCI. Ce document propose une étude de la compatibilité des cartes PCI (mères et d'extension) avec Linux, réalisée grâce à une enquête menée auprès d'utilisateurs.
Si vous disposez d'informations à ce propos (et dignes d'intérêt !), n'hésitez à contacter l'auteur de ce document ou, si l'anglais écrit génère une terrible angoisse, celui de cette adaptation française (adresse email : cf. dernière page).
Dans ce document le terme "embarqué" désigne un circuit installé sur la carte-mère, par opposition à un composant de carte d'extension. J'ai traduit "driver" par "pilote".
Le bus d'un PC peut mettre en oeuvre une ou plusieurs des normes dont la liste suit (certaines d'entre elles sont mutuellement exclusives).
Peu onéreux, lent (le plus souvent 8Mhz), standard, nombre de cartes d'extension disponibles très élevé
Onéreux, rapide, relativement peu de cartes spécifiques (seules capables d'exploiter au mieux ses possibilités)
Conçu et cautionné par IBM. Rapide mais peu répandu
Basé sur l'ISA (qu'il épaule), peu onéreux, rapide, relativement peu de cartes spécifiques.
Onéreux, rapide, peu de cartes spécifiques mais ce standard l'emportera probablement, ce qui diminuera le coût et la rareté des matériels compatibles.
ISA/VESA-Local-Bus et EISA/VLB : cette combinaison, sur bus à fréquences d'horloges élevées, pose divers problèmes et s'avère assez peu fiable mais son faible coût et ses très honorables performances lui assurèrent un bon succès commercial. La plupart des cartes récentes paraissent fiables.
EISA : fiable et ouvert (standard n'appartenant pas à un constructeur) mais assez cher, surtout prévu pour les machines des utilisateurs avertis et les serveurs de réseaux. Peu de cartes disponibles.
PCI : ouvert, au moins aussi rapide que l'EISA et câblé sur 64 bits (considération capitale pour les machines Pentium), gagne du terrain.
PCI n'est pas, comme le fut la combinaison (E)ISA/Local-Bus, dépendant du processeur employé. Un composant PCI est commun à toutes les lignes de processeurs (DEC Alpha, Intel et compatibles, Power ...) et son installation sur une carte mère PCI n'implique aucun circuit d'interfaçage : seul le BIOS varie, ce qui garantit des coûts de production moins élevés que ceux de l'(E)ISA/Local Bus).
Extrait (adapté) du document de "propagande pro-PCI" de Craig Sutphin :
Contrairement à certains autres bus locaux, le PCI est conçu pour servir toutes les cartes d'extension : vidéo, mais aussi réseau, interfaces disques ("contrôleurs") ... A 33 MHz le bus PCI transfère (sur 32 bits) jusqu'à 132 Moctets par seconde. Une extension (passage à 64 bits) des logiques d'adressage et de transfert des données peut doubler ce débit sans remettre en cause l'existant. Le PCI reste indépendant du processeur et administre au mieux les transferts en permettant au bus local de véhiculer les données sans employer le bus principal (processeur/mémoire). Cela constitue, pour les utilisateurs de PC rapides, une importante augmentation de la fiabilité, de la performance et de la facilité d'exploitation (caractéristiques non triviales avec des bus travaillant à 33MHz). Divers modes évolués d'exploitation du bus améliorent les performances des cartes d'extension sans grever le système central. L'interfaçage des composants PCI ne nécessite aucune circuiterie spécifique.
On se reportera au chapitre sur les Benchmarks pour obtenir des résultats de tests, bruts (et parfois incohérents) sur les cartes ASUS PCI pour 486 et 586.
Le circuit embarqué NCR de gestion de la chaîne SCSI-II constitue l'une des plus alléchantes caractéristiques de certaines cartes-mères PCI. Il est théoriquement au moins aussi rapide que celui des cartes Adaptec 174x (EISA) mais reste beaucoup moins onéreux. Des pilotes (drivers) pour DOS et OS/2 sont disponibles. Drew Eckard a publié la version 3 de son pilote pour circuit NCR53c810. J'utilise actuellement le noyau 1.1.78 (9 janvier 1994). Cela fonctionne si bien que j'ai revendu mon adaptec-1542B-ISA. :-)
NCR est une marque de semiconducteurs :-) NdT
Certaines cartes mères PCI intègrent le circuit NCR53c810. On peut aussi l'acheter sur carte d'extension pour à peu près 70 dollars.
Les patchs pour NCR et fichiers images de disques de boot sont disponibles sur tsx-11.mit.edu, probablement dans /pub/linux/ALPHA/scsi/ncr. Ils doivent aussi se trouver sur les sites-miroirs.
Les plus récentes distributions Slackware (postérieures à 2.0) doivent aussi pouvoir gérer ce circuit. Les plus récentes versions non stabilisées du noyau (1.1.41, par exemple) ne nécessitent plus aucun patch. Depuis la version 1.2 le pilote NCR est dans le noyau standard.
J'ai remarqué une seule chose qui ne fonctionne pas encore dans le pilote NCR actuel. La Déconnection/Reconnection n'est pas gérée, ce qui rends pénible l'utilisation d'un streamer SCSI. En effet une commande comme "mt erase" bloque tout le bus SCSI jusqu'à sa fin. Cela est bien embêtant.
Drew y travaille, voir plus bas.
Le système FreeBSD gère le NCR53c810 depuis un bon moment déjà, y compris les "Tagged Command Queues", le "FAST" et le "WIDE" SCSI ansi que la déconnection pour les 53c810, 815 et 825. Drew dit qu'il serait possible d'adapter le pilote FreeBSD pour Linux. Y a-t-il des volontaires ?
J'ai l'impression que l'évolution séparée de FreeBSD et Linux oblige à réinventer la roue un peu trop souvent. Un peu plus de coopération ne nuirait pas à aucun des deux systèmes...
Après une trop longue attente, j'ai abandonné la carte NCR pour une des cartes, performantes mais chères, contrôleur SCSI PCI de marque DPT qui sont mentionnées dans cet article. Evidemment, juste après j'ai appris que Drew fournissait en test une nouvelle version de son pilote. :-)
Drew a déclaré à la fin de Mars à propos de contrôleurs SCSI sur bus PCI : (légèrement modifié pour clarification dans le contexte)
Les cartes Adaptec 2940, Buslogic BT946, BT946W, DPT PCI, Future Domain 3260, NCR53c810, NCR53c815, NCR53c820, et NCR53c825 fonctionnent toutes plus ou moins.
Des versions Alpha du pilote NCR font des choses sympas commme la connection/reconnection et les transferts synchrones. Elles sont maintenant disponibles publiquement. Toute personne interessée voulant jouer avec devrait
Le pilote scsi EATA-DMA a subi de gros changements et prend en charge maintenant aussi les contrôleurs PCI SCSI, les contrôleurs multiples et tous les canaux SCSI sur les cartes SmartCache/Raid multicanaux.
Le pilote prend en charge tous les contrôleurs SCSI au protocole EATA-DMA (document CAM/89-004 rev. 2.0c) et a été testé avec beaucoup de ces contrôleurs dans des configurations diverses.
Il s'agit des : (ISA) (EISA) (PCI)
DPT Smartcache: PM2011 PM2012A
PM2012B
Smartcache III: PM2021 PM2022 PM2024
PM2122 PM2124
PM2322
SmartRAID : PM3021 PM3122 PM3224
PM3222
et d'autres contrôleurs NEC ou ATT.
Sur une carte DPT de base (sans cache ni module RAID), un MC680x0 gère le (ou les) circuits DMA busmaster ansi que le circuit contrôleur SCSI. La carte SCSI DPT se comporte presque comme un coprocesseur SCSI.
La carte DPT peut aussi émuler un contrôleur IDE (interface ST506), ce qui vous permet de l'utiliser avec tous les systèmes d'exploitation même s'ils n'ont pas de pilote EATA.
Sur une carte avec cache, c'est le 680x0 qui assure la gestion de ce cache. La carte DPT admet jusqu'à 64 Mo de RAM en tant que cache disque.
Sur une carte avec module RAID, c'est aussi le 680x0 qui gère le RAID, assurant le "mirroring" en RAID-1, le "striping" et la génération des codes ECC en RAID-5, etc.
Les cartes d'entrée de gamme utilisent un Motorola 68000 tandis que les hauts de gamme, plus tournées vers le RAID, utilisent un processeur 68020, 68030 ou 68040/40MHz.
Les prix officiels vont de 245 $ à 1995 $ (1er décembre 1994).
Comme on m'a demandé de nombreuses fois où acheter ces cartes en Europe, j'ai demandé à DPT de m'envoyer la liste de leurs distributeurs européens officiels. En voici un court extrait :
Autriche : Macrotron GmbH Tel:+43 1 408 15430 Fax:+43 1 408 1545 Danemark : Tallgrass Technologies A/S Tel:+45 86 14 7000 Fax:+45 86 14 7333 Finlande : Computer 2000 Finnland OY Tel:+35 80 887 331 Fax:+35 80 887 333 43 France : Chip Technologies Tel:+33 1 49 60 1011 Fax:+33 1 49 599350 Allemagne: Akro Datensysteme GmbH Tel:+49 (0)89 3178701 Fax:+49 (0)89 31787299 Russie : Soft-tronik Tel:+7 812 315 92 76 Fax:+7 812 311 01 08 GB . : Ambar Systems Ltd. Tel:+44 296 435 511 Fax:+44 296 479 461
"A mon avis, les cartes DPT sont les cartes SCSI les mieux conçues disponibles pour PC. Et j'ai écris du code pour presque tous les types de cartes SCSI pour PC. (Bien que rétroactivement, je me demande bien pourquoi !) ;-)" Jon R. Taylor ([email protected]) President, Visionix, Inc.
La dernière version du pilote EATA-DMA et une image de disquette de boot Slackware sont disponibles à l'adresse : ftp.uni-mainz.de:/pub/Linux/Drivers/SCSI/EATA
Le pilote est inclus dans le noyau standard depuis la version 1.1.81.
L'auteur peut être joint aux adresses suivantes : [email protected] or [email protected]
Rik Faith ([email protected]) m'a indiqué le 1er Février 1995 que la carte Future Domain TMC-3260 PCI SCSI était prise en charge par le pilote Future Domain 16x0 SCSI driver. Le SCSI-HOWTO peut contenir des informations plus récentes.
James Soutter ([email protected]) m'a demandé de préciser les points suivants :
Le SCSI-2 "Fast Wide" est parfois, à tort, désigné par "SCSI-3". Il diffère du SCSI-2 standard dans la mesure où il met en oeuvre un bus de données SCSI sur 16 bits (et non 8). Cela porte le taux de transfert maximum à 20Moctets/seconde (au lieu de 10) mais nécessite l'emploi de disques adaptés (Fast Wide).Ce théorique gain en performances n'accélèrera peut-être pas certains systèmes car les taux de transfert "internes" (des plateaux au métacontrôleur) de la plupart des disques restent inférieurs à 10Moctets/seconde. Un seul disque de ce type ne peut donc se trouver limité par la bande passante offerte par une carte SCSI-2 standard.
Dans le catalogue Seagate d'octobre 1993, seul un disque Fast Wide SCSI-2 a un taux de tranfert interne supérieur à 10 Mo/s ( le ST12450W). La pluspart des disques ont un taux de transfert interne de 6 Mo/s au plus, bien que le ST12450W ne soit pas la seule exception à cette règle. En conclusion, la norme Fast Wide SCSI est conçue pour le marché des serveurs et n'apporte pas forcément d'avantages à une station de travail.
Plutôt que d'acheter une carte mère à interface SCSI intégrée ou bien d'attendre le pilote NCR, vous pourriez acheter une carte contrôleur SCSI séparée. D'après Drew, la seule option PCI SCSI qui a une chance de marcher est la Buslogic 946. Elle est censée être compatible à l'Adaptec 1540 comme les cartes EISA/VESA/ISA de la série.
Drew a indiqué que les autres cartes PCI SCSI ont peu de chances d'être prises en charge par Linux ou les systèmes BSD car les contrôleurs à base de circuit NCR sont moins chers et plus courants.
Selon [email protected] (Bradley Broom) :
La Buslogic BT-946C PCI SCSI fonctionne si l'on débraye, grâce au
programme MS/DOS AUTOSCSI livré par son constructeur, l'option
"enable Disconnection".
Ernst Kloecker ([email protected]) écrit (citation adaptée) :
Talus Corporation dispose d'un pilote NS/FIP pour cartes PCI à circuit SCSI "NCR". Il sera diffusé sous peu, peut-être même à titre gracieux.
Toutes les cartes mères PCI ne disposent pas du circuit. Les cartes ASUS anciennes l'ont ainsi qu'une des cartes J-Bond.( La pluspart des cartes mères actuelles (06/95) considèrent que c'est à vous d'acheter le NCR53c810 séparément.) Certaines marques fournissent une alternative comme vous pouvez le lire dans le texte de Drew...
Le circuit NCR est assez évolué pour prendre en charge des disques formatés par d'autres circuits.
Ce qui semble assez naturel si aucun des circuits impliqués n'effectue de translation ! NdT.
Les dernières cartes mères PCI ne gèrent plus les barettes SIMMS à parité. Comme j'achetais habituellement des barettes SIMMS sans parité à cause de leur coût, je ne pensais pas que ce soit un problème avant de rajouter une carte Gravis-Ultrasound dans ma machine. Sous DOS le pilote SBOS et l'utilitaire de test se plaignent de la sorte "nmi procedure disabled on this pc". La documentation conseille de changer de carte mère dans ce cas, ce qui n'aide pas beaucoup.
La Gravis-Ultrasound fonctionne bien dans les cartes ASUS-SP3 et ASUS-SP4, malgré cela, mais ma Gravis-Ultrasound-Max génère avec gmod un "kernel panic" sur les deux cartes. De plus, de temps en temps, le fait de jouer des fichiers .au sur /dev/audio provoque des choses bizarres, comme jouer le reste d'un son précédent après le nouveau. Le gestionaire de son recommende un buffer de 65536 octets avec la GUS Max contrairement au petit buffer de la GUS - je ne sais pas pourquoi. Les deux cartes possèdent chacunes 1Mo de DRAM. Ces problèmes ne sont peut-être pas liés au problème NMI mais plûtot au gestionaire de son ?
J'ai entendu dire que ce n'est pas seulement ASUS mais la pluspart des cartes récentes qui ne gèrent pas la parité et le NMI.
De plus en plus bizarre, la carte ASUS-TP4 à chipset Triton fonctionne bien avec la GUS Max - il charge bien le pilote SBOS. Je dois admettre que je ne comprends pas tout.
comme la SP3, mais le chipset Saturn est moins buggé.
comme la AP4 mais plus récente, chipset SiS, fonctions d'économie d'énergie, EIDE, rs232 avec 2 16550 et port centronics. Seulement 2 connecteurs pour barettes SIMM, a l'air de fonctionner avec l'AMD486DX4/120 mais pas très fiable avec le NCR53c810 et sous différents systèmes d'exploitation (Windows-NT, Windows 95, OS2). Après mise à jour vers une carte Pentium ASUS SP4, tous les problèmes ont disparus ce qui confirme que cela venait de la carte. A l'air de bien fonctionner quand même sous Linux.
fonctions d'économie d'énergie, 1 slot VLB, 3 slots ISA, 4 slots PCI, seul le contrôleur EIDE est intégré, il n'y a ni contrôleur de disquettes, ni rs232/centronics. Très petite taille.
Prend l'AMD486DX2/66 pour un DX4/100. On peut corriger ça en soudant une broche (laquelle ?) à la masse, mais de toute façon je ne recommenderais pas cette carte.
Celle que j'ai testé ne fonctionnait ni sous OS2 ni sous Linux bien que certaines personnes l'utilisent avec ses deux systèmes.
Le slot VLB est censé être plus lent qu'un slot VLB normal à cause du pont PCI vers VLB, mais sans nuire à la rapidité du coté PCI.
Identique à la SP3-SiS, mais pour Pentium90/100.
Peut utiliser la nouvelle ram EDO et la future SRAM. La mémoire SRAM devrait augmenter les performances de façon considérable. Cette carte n'a pas accepté les barrettes PS2-SIMMS de 8Mo qui marchaient sans problème sur une ASUS SP4. Après échange contre d'autres barettes plus volumineuses (16 puces au lieu de 8 si je me souviens bien) cela s'est mis à fonctionner. Testée avec un P90 et un P100.
J'ai essayé de comparer la vitesse CPU sur deux cartes ASUS : pour le 486 j'ai testé la SP3 SiS (celle qui a un slot VLB) et pour le 586, la TP4/XE. Les deux cartes avait 16 Mo de RAM, le système était inutilisé. Les tests whestone et dhrystone ont été employés en changeant le CPU.
Je dois reconnaitre que je n'ai pas encore lu la faq sur les benchmarks et que je serais donc amené à beaucoup modifier cette partie bientôt. Si vous avez des commentaires, n'hésitez pas à me les envoyer par courrier électronique.
Je suis spécialement étonné par le fait que l'AMD486DX4/100 est plus rapide au test dhrystones que le DX4/120 ! Je ne retrouve pas cette incohérence en comparant les P90 et P100.
Le problème vient peut-être du fait que lorsque j'ai branché l'amdDX4-100, la carte était configurée pour un DX2-66. Bien que le BIOS voyait bien qu'il s'agissait d'un DX4-100, la carte a peut-être utilisé les mauvaises fréquences d'horloge... mais puisque le DX2-66 fonctionne à 33Mhz * 2 et le DX4 à 33Mhz * 3, cela aurait du être correct ?
La carte avec le DX4-120 est configurée en 40Mhz * 3 = 120 Mhz.
Je me demande aussi si le test whetstone fournit des chiffres aussi égaux sur d'autres machines ?
Comme la plupart des cartes de cette catégorie elle n'offre qu'un cache mémoire en lecture (perte de performances estimée par rapport aux cartes avec cache en écriture : environ 3% (?)).
Le BIOS prend en charge les disques SCSI sous DOS/Windows sans pilote additionnel (ASPI livré) Autres pilotes fournis : OS2, Windows-NT, SCO-Unix, Netware (3.11 et 4, d'après ce que j'ai compris).
Gert Doering ([email protected]) affirme que le pilote fourni pour SCO ne fonctionne pas correctement. Plusieurs commandes "time dd if=/dev/rhd20 of=/dev/null bs=100k count=500" mènent à un "kernel panic".
Il semble préférable, lorsque l'on emploie le circuit embarqué d'origine Adaptec, de ne pas employer l'option de "sync negotiation" (configuration accessible grâce au setup en BIOS de la carte Adaptec).
Attention : de graves accidents d'exploitation ("kernel panic") surviennent parfois lors du redémarrage du système après un changement de configuration. Cela ne semble pas prêter à conséquence (le redémarrage suivant se déroule correctement) mais ... Testé par votre serviteur ! NdT.
Une version plus récente de cette carte-mère existe (ASUS-PCI-I/SP3G, le `G' est important) et ces problèmes ont probablement été corrigés. Elle emploie le nouvel ensemble de circuits Intel (version 4) "Saturn-ZX" et supporte donc les options PCI les plus évoluées (level triggered shareable and BIOS-configurable). En sus : port souris PS/2 (aux), dispositif d'économie d'énergie EPA et support pour DX-4.
Les dernières informations disponibles indiquent que certains utilisateurs de cette carte (ASUS-SP3-G) constatent qu'elle ne supporte pas (crashes sous Linux) l'option "PCI-to-Memory-Posting". Tout fonctionne parfaitement lorsque cette option est débrayée. [email protected] pense que cela peut relever d'un problème avec le noyau Linux car certaines parties du système semblent continuer de fonctionner lors des crashes, ce qui peut révéler un bogue dans le code du swapper. MS-DOS, OS/2 et Windows ne présentent pas ce symptôme.
Contrairement à d'autres compte-rendus, j'ai trouvé que le curseur souris de déplace de façon très souple sous X (comme sur le bon vieux 386) - par contre il sautille avec certains jeux DOS...
Les performances sont très bonnes ! J'ai fais tourner des gros tests de calcul en virgule flottante ( 500x500 doubles - à peu près 4megs) et j'ai constaté que les performances en mode 3x33 (100Mhz) était à peu près 1.5x supérieures à celles en mode 2x (66Mhz)... J'étais un peu sceptique à propos du triplement de fréquence mais il me semble que ça tient ses promesses :-)
Le système hautement configurable de gestion de la consommation "energy star" ne fonctionne pas avec les processeurs AMD DX4 actuels - il faut un processeur SL.
J'ai vraiement besoin d'un disque SCSI et d'une carte vidéo PCI :-)
(J'ai reçu le coup de téléphone d'une personne qui a eu le problème du composant défectueux SMC FIFO. Ils se plantent après l'utilisation de X-window.)
Pat Duffy ([email protected]) nous dit :
Saturn I: Ce sont les versions 1 et 2 des chipsets Saturn. Saturn II: Aussi appelé version 4 du chipset Saturn. Autant que je le sache , la version 3 n'a jamais étée livrée, et (d'après un petit nombre de gens qui la possèdent) la SP3G intègre maintenant la version 4 (Saturn II). Vous êtes perdus ? He bien, la seule vraie réponse est de disposer de la carte et d'y lancer le script de déboggage du chipset PCI. A ma connaissance, pourtant, la carte SP3G est livrée avec la version 4 (Saturn II).
Divers utilisateurs emploient des cartes "Number Nine" (nom abrégé : #9) Level 12 et ELSA Winner 1000 (modèle 2000 aussi, vraisemblablement) et autres basées sur le circuit S3 928. La nouvelle version d'XFree (3.1) prend en charge les cartes Tseng ET4000/W32 en mode accéléré, les chipsets S3 Vision 864 et 964 y compris sur les cartes telles que l'ELSA Winner 1000Pro et 2000Pro, Number Nine GXE64 et GXE64Pro, Miro Crystal 20SV). Les modes vidéos comptant 16 ou 32 bits par pixel (16 bpp) sont à présent disponibles. Le circuit d'horloge Chrontel8391 est maintenant reconnu par le serveur S3.
Les cartes S3 Trio32 et Trio64 comme la SPEA V7 Mirage P64 PCI et MIRO Crystal 40SV, sont maintenant gérées. La Mach32 et la Mach64 sont gérées maintenant en mode accéléré.
Le pilote SVGA
La gestion du mode 16bpp (65K couleurs au lieu des 256 habituelles) pour les Mach32 ainsi que le mode 32bpp de certaines cartes S3 et P9000 a été rajoutée.
[email protected] déclare :
Par ailleurs :
La Spea V7 Mirage P64 PCI 2M à base de Trio64 fonctionne bien depuis XFree86(tm)-3.1.1.
L'ATI Graphics Ultra Pro pour PCI avec 2Mo VRAM et le DAC ATI68875C fonctionne bien (1280x1024 256 74Hz non-entrelacé) selon [email protected].
[email protected] (John Edward Bauer) indique que la Paradise WD90C33 PCI bloque la machine lorsque la sauvegarde d'écran de X Window entre en action. Les nouveaux noyaux corrigent ce problème.
miroChrystal 8S/PCI (1Mo) S3 - aucun problème.
Stephen Tweedie indique que sa carte Cirrus Logics 5434 PCI fonctionne bien. Elle fonctionne en 64 bits avec 2M et marche parfaitement avec le pilote SVGA en 8, 16 et 32 bits par pixel.
Les cartes ISA fonctionnent, bien entendu, mais d'aucuns aimeraient utiliser les versions PCI. L'auteur de la plupart (sinon tous) des programmes pilotes pour cartes Ethernet (Donald Becker ([email protected])) déclare :
Le code LANCE a été étendu pour gérer la version PCI. J'espère fournir le code de détection PCI (à peu près une douzaine de lignes supplémentaires dans le pilote LANCE) dans la prochaine version du noyau. Je suis en train de travailler sur le mode 32 bit. Je n'ai pas encore commencé le code 21040.
Je vais écrire des versions adaptées au mode PCnet32 et à la carte DEC 21040. Cela couvrira la majorité du marché des cartes Ethernet PCI.
Voir l'URL : file://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
Les noyaux 1.1.50 et ultérieurs gèrent les cartes basées sur le circuit AMD. Une carte-mère Pentium permet alors d'obtenir environ 900Ko/seconde sous ftp avec environ 20% de charge CPU (circuit AMD Lance).
Tous les matériels Ethernet basés sur le chip AMD PCnet/PCI doivent fonctionner. Les cartes Boca coûtent, aux US, moins de 70$.
Geoffry Coram a indiqué dans les news qu'il a réussi à faire fonctionner sa carte 3com 590 TPO. Il a du télécharger le pilote alpha à l'adresse : http://cesdis.gsfc.nasa.gov/linux/drivers. On peut y trouver aussi d'autres pilotes. Voir aussi http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
Donald Holmgren dit qu'il a réussi à connecter sa carte DEC DE435 (PCI) au réseau local sur coax fin (BNC). Le pilote DE435 vérifie d'abord la prise pour paire torsadée, puis commute vers le port alternatif (sélectionable par cavalier en AUI ou BNC) si le port 10BaseT ne fonctionne pas.
Jim Cusick utilise la carte Boca 1PI sur coax fin. Elle fonctionne très bien. On ira voir à l'URL : http://cesdis.gsfc.nasa.gov/linux/misc/boca-failure.html pour des détails sur les disfonctionements du début avec cette carte. Ma deuxième carte, après retour pour échange de la première, était étiquetée "PN 4186". La précédente qui ne marchait pas était une "PN4185". Précisez à la commande que vous voulez le modèle le plus récent. A 70 $, cette carte est une bonne affaire.
Dave Platt recommande d'éviter à tout prix la carte Boca BEN1PI. Elle ne serait pas fiable à cause de défauts de conception et Boca ne semble pas en mesure de corriger le problème. La carte 3Com 3c590 PCI "Vortex" est disponible en version combo (10BaseT, thin coax at AUI). Le pilote Linux de cette carte ne fait pas encore partie du noyau standard, mais est disponible à l'URL http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html et peut être patché dans les derniers noyaux 1.2.x (ainsi que les 1.3.x) sans beaucoup de difficulté. Le pilote Linux ne peut pas utiliser la possibilité d'autodétection d'interface de cette carte - le programme DOS fourni permet de configurer la carte afin qu'elle utilise l'interface choisie ( coax fin dans notre cas). Une fois cela fait, le pilote Linux utilise l'interface correcte.
Il a utilisé avec succes une 3c590 pendant plusieurs semaines.
Dave Kennedy nous fait part qu'il a eu deux des cartes Boca citées plus haut et qu'elles fonctionnent bien sous charge légère. Craig ne les recommende pas car Boca ne semble pas suivre les spécifications d'AMD mais il a pu les utiliser pendant deux semaines sans problèmes. Il a testé les performances NFS en transférant de gros fichiers depuis et vers son serveur (16M, 8M). Il a aussi essayé de travailler localement avec tous ses fichiers de données montés par NFS et cela sans problèmes. Les performances paraissent améliorées de 100 pour cent par rapport à sa carte ISA NE2000. (note de l'éditeur : cela aurait sans doute été la même chose avec la SMC ISA Elite Ultra ?)
Quelqu'un a mentionné sur usenet avoir utilisé la 3Com-3c590-TPO (EtherLink III - PCI). Pour que cela fonctionne avec son noyau Linux 1.2.8, il lui a fallu le pilote "3c59x.c" avec le "vortex.patch".
Il parait que la carte DEC435 PCI marche bien avec les pilotes fournis dans la distribution Slackware - Je pense donc qu'ils sont dans le noyau standard ?
Liste des utilisateurs qui ont répondu à mon questionnaire, sur le type de cartes mères qu'ils emploient ... et résultats obtenus lors de l'installation et l'utilisation de Linux :
[email protected] fonctionne.
[email protected] - fonctionne.
[email protected] - fonctionne. [email protected] - fonctionne [email protected] - fonctionne (Premier-II)
[email protected] - fonctionne
[email protected] - Fonctionne. Probablement équipée de l'ensemble de circuits ("chipset") déficient Intel "Saturn".
[email protected] - Ne fonctionne pas.
[email protected] - Fonctionne.
[email protected] - Fonctionne.
[email protected] - fonctionne
Seul le streamer (floppy tape de marque Archive) ne fonctionne pas.
Drew Eckhardt ([email protected]) utilise la Diamond Stealth 64 VRAM avec 4M de Mémoire (à base de 964). Elle fonctionne très bien en 1024x768 72Hz et 32bpp de même qu'en 16bpp et 8bpp. Il lui a fallu le serveur X311u2S3 de ftp.xfree86.org. Les possesseurs de cartes Diamond à base de 968 devront faire de même.
Manuel de Vega Barreiro
Pentium à 90MHz, 32Mo de RAM et 512Ko de cache à 2 niveaux. Fonctionne parfaitement (une compilation de noyau n'exige que 10 minutes).
La carte-mère offre :
Avantages : j'emploie pour le moment une Adaptec 1542CF et un disque Seagate d'un giga. Aucun problème. Carte vidéo ATI Graphics Pro Turbo (PCI), très véloce. Les ports série gèrent un modem TeleBit T3000 (38400) sans pertes de caractères. Les adresses mémoires situées au-delà de 16Mo sont aussi servies par le cache. Trois bancs de circuits SIMM (2 barettes par banc) pouvant chacun supporter 64 Mo (32 Mo par barette). Chaque banc doit bien entendu être complet (2 barettes). Support CPU ZIF. BIOS flash PHOENIX.
Inconvénients : RAM maxi 192Mo mais cache limité à 512Ko. La carte vidéo est très véloce mais il n'existe pas pour le moment de serveur X pour circuit Mach64 (le serveur SVGA existant n'exploite du moins pas ses possibilités). Je ne sais pas si le "contrôleur" IDE intégré fonctionne car je n'apprécie guère les standards spécifiques à une plateforme et n'ai donc pas acheté de disque IDE mais emploie un Seagate 31200N et un NEC 3Xi.
Mitch.
J'ai acheté une carte "SA486P AIO-II" supportant les 486 SX/DX/DX2/DX4. Elle offre :
J'utilise un 486/DX2-66, un disque dur Seagate "Barracuda" 2.1Go (ST12550N), un streamer Wangtek 5525ES et une vieille carte S3 (ISA). Tout fonctionna parfaitement dès le premier boot (noyau 1.1.50). Et cela perdure depuis un mois. Note : j'employais une Buslogic BT-445S et ai pu placer le disque sous le contrôle du circuit NCR sans reformater ... tout a survécu. Les périphériques SCSI paraissent nettement plus rapides. Seules réserves :
1/ lilo ne peut booter le système sans une édition manuelle de /etc/disktab, effectuée une fois pour toutes.
2/ Afin que l'ensemble fonctionne : disconnect/reconnect est débrayé. Cela autorise donc le verrouillage du bus SCSI même durant de longues opérations ("rewind" du streamer) ... La négociation du mode synchrone est elle aussi débrayée. Cela entraîne une certaine perte de performances.
Je crois que Drew (auteur du pilote pour circuit SCSI NCR) résout en ce moment ces limitations.
Quelques problèmes avec Windows.
Tout fonctionne bien. L'installation de la distribution Slackware s'avéra très aisée et je peux employer Quicken 7 pour DOS grâce à DOSEMU. J'emploie X Window en 1152x900 à 67Hz.
Je n'ai pas eu de problèmes avec cette carte, le contrôleur PCI IDE intégré (j'espère passer au SCSI bientôt) et une ATI Mach32 (GUP) avec 2Mo de VRAM.
Attention : Le DSA ne fonctionne qu'avec le firmware ("BIOS") A07 !! A06, trop bogué, interdit le reboot !! Pour récupérer ce code : ftp dell.com, fichier /dellbbs/dsa/dsaman17.zip
A part cela aucun problème sous Linux. Machine faisant office de serveur de noms, de serveur de news et de serveur WWW sur l'Internet depuis deux mois ...
Gateway 2000, Pentium à 66 MHz, carte-mère Intel offrant 5 slots ISA et 3 PCI. Je n'utilise qu'une carte PCI #9 GXe level 12 (2 Mo VRAM et 1 Mo DRAM) achetée chez Dell. Je n'emploie le mode graphique, sous Linux, qu'à partir des consoles et attends quelques adaptations d'XFree86 avant de l'essayer en 1280x1024. J'ai pu utiliser cette carte sous DOS/Windows en 1280x1024x256 sans problème. Installées par ailleurs : carte Ethernet "Etherlink 3C509" (Etherlink III), la carte Mitsumi
Interfaçant probablement un lecteur de CD-ROM., l'Adaptec 1542C et une carte série/parallèle (la machine comprend donc 3 ports série).
32 Mo de mémoire installés et reconnus par DOS et Linux. Une souris bus (Microsoft en mode PS/2).
Aucun problème jusqu'à présent.
Gateway 2000 P5-60 à carte-mère Intel "Mercury", BIOS sur EPROM Flash d'origine AMI (1.00.03.AF1, (c)'92) 16Mo RAM, interface IDE embarquée et carte vidéo PCI : ATI AX0 (Mach32 Ultra XLR).
Aucun problème avec ce matériel jusqu'à présent, mais n'a rien essayé de très spécial (pilotes SCSI ou accélérateurs d'IDE).
8Mo RAM, S3 805 1Mo DRAM PCI Disque dur 260Mo Seagate IDE (je ne peux exploiter le circuit NCR53c810 faute de pilote), Linux 0.99pl15d fonctionne bien.
17 machines 60MHz Pentium (carte Intel "Premier").
Intel Premier Plato-babyAT 90mhz avec Buslogic bt946c w/4.86 mcode w/4.22 autoSCSI, ATI Xpression (Mach64) (j'emploie les pilotes disponibles sur sunsite et un moniteur AcerView 56L).
4 disques durs IDE. Linux (Slackware 2.0) perçoit les deux premiers et ce que contrôle la BusLogic (qui émule une Adaptec 1542). DOS perçoit tout. BusLogic (aux US du moins ! NdT) expédie sans problèmes les circuits permettant de procéder à une mise-à-jour matérielle (boîtiers PLCC). Une Sound Blaster SCSI-2 contrôle aussi un lecteur de CD. Config complète, donc : 4 disques IDE (2 pour Linux) et 2 contrôleurs SCSI.
La configuration de mon système est la suivante : 16 Mo de RAM 60ns, carte ethernet 3Com Etherlink-III (10base2), ATI Mach 64 2 Mo de VRAM, CDROM SCSI double vitesse Toshiba, NCR 53c810 PCI SCSI, lecteur de cartouches 270 Mo Syquest 3270, écran Viewsonic 17 pouces, Pentium 90 (non buggé). Je tourne sous Slackware 2.1.0 avec un noyau 1.2.0 et d'autres mises à jour diverses.
Tout fonctionne sans problème. Je ne recommende pas les lecteurs Syquest. J'ai utilisé les modèles 3105 et 3270 qui sont tous les deux très, très fragiles. De plus les cartouches sont facilement endommagées ce qui m'a causé de fréquents problèmes. Je suis en train de m'intéresser à d'autres systèmes de stockage amovible (MO, Zip, Minidisc, etc).
Quelques informations qui peuvent être utiles :
On peut télécharger par ftp les mises à jour de Flash Bios à partir de wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/plato. Le numéro de version actuelle est 1.00.12.AX1. Les mises à jour de BIOS doivent être effectuées dans l'ordre. De 1.00.03.AZ1 vers 1.00.06.AX1 vers 1.00.08.AX1 vers 1.00.10.AX1 vers 1.00.12.AX1. On peut aussi télécharger ces mises à jour sur le BBS Intel.
Si vous utilisez la carte PCI SCSI NCR 53c810 sans BIOS avec la Plato, il se peut que vous ayez du mal à la faire reconnaitre. J'ai du modifier un des cavaliers de la carte NCR : Celui qui contrôle si il y a 1 ou 2 cartes SCSI NCR dans votre machine doit être sur "2". Je ne sais pas pourquoi, mais c'est comme ça que j'ai réussi à la faire marcher. L'autre cavalier contrôle le choix de l'interruption (A, B, C, D). Je l'ai laissé sur A (position par défaut).
Il n'y a rien à faire dans le BIOS pour configurer la carte NCR 53c810. Ne vous en faites pas - une fois les cavaliers de la carte bien positionnés, elle sera bien détectée ! Le PCI c'est bien du "plug and play" !
ASUS-PCI-Board (SP3) équipé de :
L'utilisateur s'est contenté d'installer la nouvelle carte mère, de réinstaller les cartes et de connecter les câbles ... et tout a fonctionné du premier coup. Mais il n'emploie aucune carte d'extension PCI.
Carte ASUS-PCI avec 486DX66/2, miro-crystal 8s PCI avec serveur pour S3 de XFree86-2.0, n'utilisant pas le circuit SCSI NCR embarqué pour cause de manque de pilotes sous Linux mais testé sous DOS et reconnu très véloce. Aucun problème de compatibilité.
Carte ASUS PCI/I-486SP3 à 486DX2/66, 16Mo RAM (2x8), miroChrystal 8S/PCI (1Mo) S3, Soundblaster PRO, Adaptec 1542b (3.20 ROM) carte SCSI et deux disques (Fujitsu M2694ESA et Quantum LPS52) plus QIC-150 Streamer. Aucun problème !
Aucun problème. SLIP et la carte Orchid-Soundwave-32 fonctionnent. J'attends moi aussi le pilote pour NCR. Seul problème rencontré : les performances du disque IDE laissent à désirer sous Linux alors que ce très récent disque WD vole sous DOS/WfW.
L'interface IDE fonctionne en mode ISA sous Linux et un pilote commute le mode PCI sous DOS. Cela explique la perte de charge constatée. Cf. aussi le cas de [email protected] NdT.
Le circuit SCSI embarqué est mis hors-fonction. Problèmes de prime abord avec la chaîne IDE (interface embarquée) : "un jumper, sur la carte, permet de spécifier si la ligne d'IRQ 14 provient du bus ISA ou PCI. Un exemple fourni par le manuel montre une connexion à l'INT A du PCI. Ne pas le respecter. La configuration du Supra exige l'emploi de setserial (pour préciser que le port est un 16550A). Slackware : utiliser /etc/rc.d/rc.serial."
J'utilise la configuration suivante :
Tout fonctionne. Vitesse satisfaisante. Les performances de la carte ATI-GUP-PCI (Mach32) restent en deça des indices de benchmarks. Si j'avais de l'argent j'achèterais un P90 Plato et une carte #9GXE64Pro !
J'ai fait tourner cette carte 24h sur 24 ces 6 derniers mois. Elle a fonctionné sans problème sous DOS/Windows, OS/2 Warp et Linux (24h/24).
DOS et Linux fonctionnent parfaitement. Machine extrêmement véloce. Les benchmarks de BYTE pour machines Unix lui accordent une puissance à peu près égale à celle d'une Sun SPARC 20 sous Solaris 2.3. Le PC effectue plus vite le test de vitesse de calcul en arithmétique entière et celui portant sur la manipulation des processus (changement de contexte y compris). La station Sun l'emporte lors des traitements en virgule flottante et sur l'un des tests de vitesse du système de disques.
Emploie un Gateway 2000 sans problème. La carte son livrée (modèle non précisé) ne fonctionne pas. Il espère obtenir satisfaction après un échange contre une véritable Sound Blaster.
486 DX2/66 vendue par ESCOM (type de carte mère non précisé) avec IDE embarqué et sans circuit SCSI "NCR". Adaptec 1542cf et carte vidéo SPEA v7 mercury lite (s3, PCI, 1Mo), ISA-Soundblaster-16, mitsumi-cdrom (simple vitesse). Seul le streamer Archive ne fonctionne pas. Le spea-v7 s'entend parfaitement avec XFree86-2.1 !
Il abandonna tout cela pour adopter une carte ASUS-SP3-G et constata qu'elle ne supporte pas les transferts en mode rafale du bus PCI vers la mémoire ("PCI-to-Memory posting"). Seul Linux crashe, Windows et OS/2 fonctionnent. Débrayer cette option rend le tout parfaitement stable. Lire à ce propos "http://wsiserv.informatik.uni-tuebingen.de/ jw".
ASUS-PCI et AMD486dx40 (cadencé à 33MHz ?!). La carte ISA-ET3000 Optima 1024A ISA fonctionne bien. Pas de problème avec le disque SCSI Quantum540S connecté au NCR53c810 intégré.
Linux refuse de démarrer lorsque la carte SCSI-PCI-SC200 se trouve dans le système.
Gateway 2000 G/W 2000 4DX2/66 PCI ATI-Graphics-Ultra-Pro IDE
Fonctionne bien, seule la carte IDE fonctionne en mode ISA sous Linux, beaucoup plus lentement que sous DOS après basculement en mode PCI par un programme MS-DOS spécifique. Plus lent sous Linux, donc : un patch serait le bienvenu.
La carte ASUS / 16Mo-RAM, carte ISA S3/928, interface IDE embarquée, disque Seagate ST4550A. Aucun problème avec les noyaux Linux plus récents.
Problème rencontré :
Ma souris, sous X, ne réagit plus comme d'habitude. Le pointeur semble
bondir lorsque je la déplace vite. Ce problème a je crois été traité
dans un newsgroup Linux. L'utilisation du 16550 expliquerait ce
phénomène. Après deux semaines d'utilisation je m'y suis habitué :-)
Réduire le seuil du tampon fourni par le 16550 devrait améliorer la situation. Un patch pour setserial le permettrait mais je ne sais où le trouver.
Carte-mère ASUS PCI/I-486SP3 (Award BIOS 4.50), 16 Mo RAM Circuit SCSI "NCR" mis hors-fonction, Carte PCI Genoa Phantom/W32 2Mo
Adaptec AHA-1542CF (BIOS v2.01) pour :
mke2fs (0.4, v. 1.11.93) fige le système et interdit l'installation.
(Version ancienne, indique l'utilisation d'un noyau obsolète NdT).
Le remplacement de la carte vidéo Genoa Phantom/W32 2Mo PCI par une ELSA Winner 1000 2Mo PCI corrigea le problème. Le système fonctionne aussi avec une vieille carte VGA ISA de marque EIZO. Cela met en cause la carte Genoa.
Carte ASUS SP3 i486DX2/66 NCR53c810 hors-fonction Adaptec 1542B dans un slot ISA : 2 disques (200Mo Maxtor, 420Mo Fujitsu), SyQuest 88Mo et streamer Tandberg carte vidéo ELSA Winner 1000 PCI, 1Mo-VRAM Soundblaster Pro dans slot ISA (IRQ 5) Interface IDE embarquée mise hors-fonction Circuits embarqués pour série, parallèle et contrôleur de disquettes en fonction.
La machine se fige parfois après un reset (logiciel ou matériel). Ce n'est probablement pas dû à l'Adaptec ou à la carte son car le système ne redémarre pas, parfois, même lorsqu'elles sont déposées. Mais sitôt lancé (lorsque le message du BIOS de l'ELSA apparaît) tout fonctionne à merveille.
Mêmes symptômes ici depuis l'installation d'une carte clone à base de Cirrus 5428 / VLB dans une machine EISA/VLB NdT.
Les deux ports série sont bien détectés en mode 16550 mais lors de certains transferts perdent de nombreux caractères en mode V42bis. Cela semble relever d'un problème matériel.
Le mode rafale CPU->PCI fonctionne bien sous DOS/Windows
Le mode rafale CPU->PCI ne fonctionne pas correctement avec linux0.99p15 : pertes de pages écrans lors de basculements de consoles virtuelles et blocages du système laissant le voyant SCSI allumé lors de l'invocation d'applications massives telles que ghostview ou xdvi.
(Je pense que ces applications exigent beaucoup de transferts en mode CPU->PCI-burst à cause des importants volumes de données transférés vers la carte ELSA lors de leur invocation).
Tout fonctionne bien après mise hors-fonction du mode CPU->PCI-Burst. La carte vidéo délivre 93k xstones en 1152x846 (peu de cache pour les fontes avec 1Mo). Le mode Opaquemove sous twm est un poil mieux que "supportable" :-)
Un programme DOS nommé SATURN.EXE, lancé avant de démarrer Linux,
aide ce dernier à exploiter le mode burst sans accroc.
Quelqu'un a affirmé que certains de ces problèmes disparaîtraient si je pouvais débrayer le mode "sync negotiation" de l'Adaptec mais j'ignore si la 1542B permet cela.
Avec le mode CPU->PCI-Burst la carte vidéo atteint 95k xstones, ce gain ne justifie pas l'effort. L'utilisateur aimerait exploiter la carte vidéo en mode 1152x900 mais cela ne semble pas possible car elle interprète toute résolution horizontale supérieure à 1024 comme égale à 1280, entamant la bande passante au point de devoir réduire la dimension verticale à 816 pixels.
Aucune carte d'extension PCI pour le moment, mais désire acheter une carte vidéo PCI. Utilise une carte d'interface SCSI WD7000 en attendant le pilote pour circuit NCR embarqué.
Tout fonctionne parfaitement. Le premier port série (sert un modem 14.4) se bloque parfois lors des tentatives de reconnexions après utilisation du modem. Ce problème serait causé par un circuit (SMC-LSI) du 16550 déficient. La souris Logitech série connectée au second port fonctionne bien, mais je cherche comment diminuer le seuil du tampon fourni par le 16550.
Tout semble fonctionner correctement mais l'utilisateur n'a pas
encore essayé d'installer une carte Ethernet, d'imprimer ou
d'exploiter un streamer.
Des problèmes de blocages du système lorsqu'il utilisait find furent
résolus par l'application des patches de clustering SCSI mais ils
relevaient plutôt de dysfonctionnements des anciennes version du noyau.
La carte vidéo ELSA-Winner-1000 se fige parfois. L'affichage devient pour le moins étrange et il faut relancer le système. Le revendeur a parlé d'un bug de la carte ELSA mais le constructeur a affirmé avoir résolu cela. le problème n'est pas systématique, l'utilisateur tâche donc de l'ignorer.
Tout bien considéré la machine fonctionne bien en utilisation de bureautique orienté traitement de textes (emacs, LaTeX, xfig, ghostview) et semble très véloce, à peine au-dessous des stations Sun coûtant au moins 3 fois plus cher qu'il emploie par ailleurs.
Le mode CPU->PCI-Burst est débrayé car le BIOS ne supporte pas correctement cela.
PCI48IX Rev. 1.0. Constructeur inconnu, documentation par "TMC". Le BIOS ne permet guère de paramétrer le bus PCI.
La carte ISA multifonctions d'interface IDE de type UMC (863+865) fonctionne bien sous DOS et OS/2 mais pas sous Linux.
Angelo Haritsis ([email protected]) a rassemblé les éléments de cette section.
Ne pas acheter de carte-mère PCI/VLB, elles paraissent toutes mal conçues. Opter pour une carte PCI/ISA. Eviter les jeu de composants (chipsets) de marque OPTi modèles 82C596, 82C597 et 82C822 comme sur la carte mère TMC PCI54PV.
(Je connais au moins une personne qui n'a pas de problème avec sa TMC PCI54PV. Il lui a fallu seulement mettre sa carte NCR53c810 dans le slot A qui semble le seul capable de faire du busmaster.)
Diverses rumeurs laissent entendre que les cartes mères Intel ne peuvent supporter plus d'une carte d'extension bus master. On dit aussi que le chipset Saturn II pose divers problèmes ... mais je l'emploie avec satisfaction !
Opter pour une carte à connecteurs 72 points (vélocité maximale). Toutes les cartes Intel offrent cela.
La carte-mère Intel pour Pentium 90 à chipset Premiere II (connue aussi sous le nom de "Plato") paraît satisfaisante. Opter pour un BIOS intégrant le code du contrôleur SCSI NCR embarqué afin que même le 53c810 permette à MS-DOS de fonctionner. La version 1.00.08 (ou peut-être 1.00.06) offre un BIOS pour le circuit NCR intégré au BIOS principal (AMI). Une disquette permet de mettre à jour ce dernier (inscrit sur EPROM FLASH). La plus récente version repérée porte le numéro 1.00.10 et corrige tous les problèmes de jeunesse de ce produit.
La plupart des cartes-mères exigent une configuration explicite (via le SETUP) des paramètres PCI bas-niveau ... pour chaque connecteur (slot PCI) ! Cela ménage la compatibilité de ce bus avec les cartes ISA. Sur les plus anciennes cartes PCI des cavaliers (jumpers) doivent configurer le mode d'exploitation des lignes d'interruptions fournies par chaque slot PCI (INTA et parfois INTB, INTC et INTD) et de leur interfaçage avec les lignes du classique 8259. Si une carte-mère donnée intègre ces cavaliers leurs positions doivent impérativement correspondre au paramètrage (SETUP) du bus PCI. Les documents fournis avec un certain nombre de cartes (Viglens, par exemple) sont partiellement erronés. L'installation exige en ce cas quelques tâtonnements.
Tous les circuits NCR 8XX emploient le bus mastering (peuvent prendre le contrôle du bus) et se connectent directement au bus PCI. Ils correspondent aux spécifications PCI version 2.0 et sont donc capables de transferts en mode rafale sur 32 bits à 33MHz (133 Mo/s).
8 bits Fast SCSI-2 (10 Mo/s). Nécessite un BIOS spécifique sur la carte mère. 100 broches Quad Flat Pack (PQFP). Premier circuit SCSI pour PCI. Le moins onéreux car le plus produit.
8 bits Fast SCSI-2 (10 Mo/s). Terminaisons passives ("single ended") uniquement. Interface pour BIOS externe (circuit idéal pour conception de carte). 128 broches QFP.
16 bits Fast SCSI-2 (20 Mo/s). Terminaisons passives ou différentielles. Interface pour BIOS externe. 160 broches QFP.
NCR annoncera dans les 6 prochains mois 4 nouveaux circuits. Brochages compatibles avec les 810 et 825 et quelques nouvelles fonctions.
Tous ces circuits nécessitent un BIOS sous MS-DOS. Le 810 seul exige son implantation sur la carte-mère. La plus récente version du BIOS NCR porte le numéro 3.04.00 et permet à MS-DOS d'employer les disques de plus d'un Go.
Les tests de vélocité du magazine allemand "C't" indiquent que ces circuits fonctionnent nettement plus vite que la BusLogic BT-946. Un utilisateur a constaté un niveau de performances d'environ 10 à 15% supérieur à celui d'une Adaptec 2940 et qu'avec un très rapide disque dur le tout semble environ deux fois et demi plus rapide qu'une Adaptec 1540.
Ca fonctionne. point.
Sur certaines cartes Intel Plato, le bios NCR ne reconnait pas la carte car il doit la voir en tant que "contrôleur SCSI secondaire", et que sur la pluspart des cartes SCSI le cavalier de sélection primaire/secondaire a été soudé en position primaire (pour économiser un centime, sans doute).
Solution:
Près du circuit NCR, il y a 3 connections (sorte de trous) avec un strap,
qui ressemblent à
O--O O
Cela indique que le primaire est configuré par défaut. Pour la carte
Intel Plato il devrait être comme ceci
O O--O
La meilleure solution est d'enlever le strap et de mettre à la place
un cavalier à deux positions.
Frederic Potter a rajouté une détection des périphériques PCI dans les noyaux récents. Si vous faites "cat /proc/pci" vous devriez obtenir la liste de vos cartes. Si certaines de vos cartes ne sont pas bien reconnues, envoyez un courrier électronique à "[email protected]".
Voir arch/i386/kernel/bios32.c et include/linux/pci.h dans les sources du noyau pour en savoir plus sur le fonctionnement de la détection PCI.
Quelles autres cartes PCI peut-on utiliser ? A part les nombreuses cartes graphiques, j'aimerais entendre parler d'autres cartes comme les cartes ethernet, de capture d'écran ou de TEST. Cyclades a en beta test en ce moment :
Ce produit appelé Cyclom-Ye possède les caractéristiques suivantes :
Si vous avez l'argent nécessaire optez pour une ASUS-SP4, P90, c'est ce que je possède en ce moment. Si vous pouvez vous le permettre 32 Mo de RAM est très supérieur à 16 Mo.
Dans un avenir proche, le futur standard sera le chipset Triton qui permettra l'utilisation des barettes mémoires EDO et SRAM. Les deux seront plus chères que de la RAM PS2, et en ce moment (28 juin 1995) la SRAM n'est pas encore disponible. Si la RAM EDO est plus chère ce n'est pas à cause des coûts de production, il parait qu'ils sont identiques.
Pour un système à hautes performances, je choisirais quand même une ASUS-TP4/XE avec de la RAM EDO mais si vous n'en avez pas un besoin urgent il vaut mieux attendre encore un peu.
Pour le choix d'une carte graphique, je dirais que la meilleure des cartes bon marché qui s'accorde parfaitement avec un écran Samsung Syncmaster 15Gli, est la SPEA V7 Mirage P64 à circuit Trio64 en version 2 Mo de DRAM. Pour des affichages plus sophistiqués tel l'Iiyama-IDEK 8617-T, je pense que la PCI Mach64 ATI-GUP-Turbo (pas le modèle moins cher GUP-Turbo-Windows) serait un bon choix : avec 4 Mo de RAM on peut avoir 16 millions de couleurs dans les résolutions supérieures. Elle est bien gérée par XFree86(tm)-3.1.1, et il y a aussi des serveurs X commerciaux, parmi lesquels je recommenderais Accelerated/X, qui la font fonctionner très efficacement.
Pour du SCSI je conseille un contrôleur DPT plustôt que le (moins cher et très rapide) NCR53c810 si l'on compte utiliser beaucoup de streamer SCSI. Le pilote Linux pour NCR53c810 ne gère pas, en effet, les connection/déconnection ce qui bloque le bus SCSI à chaque opération du type "mt rewind", "mt fsf", etc. Cela implique de pénaliser les performances pendant l'utilisation de Tar. Mais allez voir les nouveaux pilotes alpha de Drew avant de prendre un décision, peut-être résolvent-ils ces problèmes.
Pour des serveurs, le DPT reste de toute façon le contrôleur de choix à cause de la bonne gestion du cache matériel ( avec tri des accès, ce qui rend le cache embarqué intéressant même sur un environnement Linux ou l'OS gère son propre cache) et du support raid jusqu'au niveau 5.
Si vous ne voulez dépenser autant d'argent en équipement informatique (vous avez aussi une vie) vous pourriez prendre une ASUS-SP3-SiS avec un AMD-DX2/66 ou un DX4/100. La SPEA V7 Mirage P64 PCI avec 2 Mo de DRAM est un bon choix car elle utilise le circuit S3 Trio64 qui est bien supporté par XFree86(tm)-3.1.1 et de plus n'est pas chère et rapide.
Depuis XFree86(tm)-3.1, l'ET4000/w32-PCI rapide et peu chère est aussi un bon choix.
Les personnes suivantes ont directement contribué à la rédaction de ce document :
J'ai collecté la plupart des informations présentées ici par email et articles de news postés par les personnes dont les noms suivent :
[email protected],
[email protected],
[email protected] (oeuvrant sur le pilote du NCR53c810),
[email protected],
[email protected],
[email protected],
[email protected],
[email protected] (iX-Magazine),
[email protected], [email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected], [email protected], Ulrich Teichert, [email protected],
[email protected],
[email protected]
[email protected],
[email protected],
Gert Doering ([email protected]),
James D. Levine ([email protected]),
Georg von Below ([email protected]),
Jerome Meyers ([email protected]),
Angelo Haritsis ([email protected]),
[email protected] et son copain [email protected].
Nat aimerait remercier les courageux relecteurs/correcteurs de ce
document :
Xavier Cazin,
René Cougnenc
---------------------------------------
Truc pour vérifier la release du chipset PCI (merci à Jean-Louis Matrat).
Sous debug: -o cf8 f0 -i c000 86 -i c001 80 -i c002 A3 -i c003 04 -i c008 11 -o cf8 00 -q
Les valeurs retournées indiquent :
---------------------------------------
Pour récupérer les fichiers permettant de reprogrammer un BIOS de carte Plato :
ftp.ibp.fr:/pub/linux/packages/GCC/plato.tar.gz
Un newsgroup nommé alt.comp.periphs.mainboard.asus traite du cas des cartes mères ASUS.
Note destinée aux utilisateurs de Linux résidant en France : Une conférence répartie sur de nombreux BBS français traite de Linux. Elle est reliée au newsgroup Usenet "fr.comp.os.linux".
Divers sites publics proposent fichiers et informations utiles. Connexion par modem/réseau téléphonique commuté, sans parité, 8 bits de données et 1 bit de stop :
brasil (1) 44 67 08 44 Bulletin Board System
bbs-fdn (1) 48 89 58 59 Site Linux et uucp anonyme de
l'association FDN. Login guest,
ou nuucp sans mot de passe.
remcomp (1) 40 22 90 93 Site uucp anonyme.
(1) 42 47 06 11 Login: nuucp, pas de mot de
passe. Liste des fichiers dans
~/catalogue.gz
renux (1) 42 37 78 92 Site Linux ou uucp anonyme.
Liste des fichiers dans:
/mirror/catalogue.zip
shagshag (1) 40 30 04 68 Site Linux
fasterix (1) 47 07 32 34 fichiers /gnu et /vrac
magix (1) 45 21 02 52
paoux (1) 60 82 29 34 Site Linux ou uucp anonyme
spia (16) 47 42 56 25 Site Linux
stdin BBS (16) 72 34 54 37 Bulletin Board System
Le Lien (16) 72 08 98 79 Bulletin Board System
Suptel Nancy (16) 83 53 16 17 Bulletin Board System
(16) 83 53 20 21
cafard naum (16) 51 70 16 32 Bulletin Board System
(16) 51 70 16 34 Site Linux ou uucp anonyme.
Serveurs ftp :
ftp.ibp.fr 132.227.60.2 /pub/linux : miroir de tsx-11.mit.edu.
ftp.fdn.org 193.55.4.75 /pub/Linux
ftp.loria.fr 152.81.10.10 /pub/linux
ftp.univ-angers.fr 193.49.144.1 /pub/Linux
Voir aussi :
fgb1.fgb.mw.tu-muenchen.de 129.187.200.1 /pub/linux
ftp.denet.dk 129.142.6.74 /pub/OS/linux
ftp.dfv.rwth-aachen.de 137.226.4.105 /pub/linux
ftp.ibr.cs.tu-bs.de 134.169.34.15 /pub/os/linux
ftp.informatik.rwth-aachen.de 137.226.112.172 /pub/Linux
ftp.informatik.tu-muenchen.de 131.159.0.110 /pub/Linux
ftp.mcc.ac.uk 130.88.203.12 /pub/linux
ftp.stack.urc.tue.nl 131.155.2.71 /pub/linux
ftp.win.tue.nl 131.155.70.100 /pub/linux
nic.funet.fi 128.214.6.100 /pub/OS/Linux
src.doc.ic.ac.uk 146.169.2.1 /packages/linux
© Copyright 1993, 94 by Michael Will ([email protected]) - réservé aux usages non commerciaux. La licence GPL (Gnu Public License) s'applique. Si vous ne pouvez pas obtenir une copie de la GPL, je serais heureux de vous en envoyer une.
Si vous vendez ce HOWTO sur un CD ou dans un livre je serais heureux d'en obtenir un exemplaire pour référence.
Vous pouvez me contacter par courrier électronique ou bien au +49-7071-969063.
La reproduction de la présente traduction ne nécessite pas l'autorisation de ses traducteurs : Nat ([email protected]) et Olivier ([email protected]).
Les marques citées restent la propriété de leurs possesseurs. Les informations fournies ne sont assorties d'aucune garantie.