Les périphériques PCI sont pratiquement tous auto- configurés -- la
machine et le système d'exploitation vont allouer des ressources aux
cartes si nécessaire.
Les interruptions peuvent être partagées sur le bus PCI. Non
seulement ils le peuvent, mais le système va souvent être plus
performant lorsque les IRQs sont partagés, et particulièrement sur
les systèmes i386.
Il existe plusieurs standard PCI différents. Occasionnellement, vous
trouverez une carte de spécification PCI2.2 qui va juste fonctionner
sur un système de spécification 2.1. De même, plusieurs cartes avec
des ponts intégrés (telles que les cartes réseaux multi-port) ne
fonctionneront pas correctement sur d'anciens systèmes.
Le bus PCI supporte deux niveaux de signalisation, 3.3v et 5v. Les
cartes fonctionnant avec la signalisation 3.3v ont une seconde
"coupure" au niveau de leur connecteur PCI. La plupart des cartes
PCI utilisent la signalisation 5v, utilisée par la plupart des
ordinateurs. Les ordinateurs à carte unique Soekris (Net45x1 et
Net4801) sont des machines communes qui ne supportent que la
signalisation 3.3v.
12.1.2 - Périphériques ISA
Les périphériques ISA ne peuvent partager de ressources et de
manière générale, doivent être configurés manuellement en utilisant
des paramètres qui ne rentrent pas en conflit avec d'autres
périphériques système.
Quelques périphériques ISA sont"Plug and Play"
(isapnp(4))
-- si vous avez des problèmes avec de tels périphériques, vérifiez leur
configuration dans votre
dmesg(8),
ISAPNP ne fonctionne pas toujours comme on le souhaite.
De manière générale, si vous avez le choix évitez les cartes ISA au
profit de cartes PCI. Les cartes ISA sont plus difficiles à
configurer et ont un impact négatif plus grand sur les performances
système.
12.1.3 - Un périphérique est "reconnu" mais il est marqué comme
"not configured" dans le dmesg
Ceci veut clairement dire que votre périphérique n'est pas supporté par
le noyau que vous utilisez. Vous ne serez donc pas en mesure de
l'utiliser.
PCI et de nombreux autres types de périphériques offrent des
informations d'identification afin que le système d'exploitation puisse
les reconnaître correctement et activer s'il y a lieu le support de ces
périphériques. Ajouter ces informations est chose facile, ajouter le
support d'un périphérique ne l'est pas. Souvent. Voici une partie d'un
dmesg avec deux exemples de périphériques "not configured" :
...
vendor "Intel", unknown product 0x5201 (class network subclass
ethernet,
rev 0x03) at pci2 dev 9 function 1 not configured
...
"Intel EE Pro 100" rev 0x03 at pci2 dev 10 function 0 not configured
...
Dans le premier exemple (une carte réseau), le code du constructeur a
été identifié ainsi que le type générique de la carte. Cependant, le
modèle exact de cette carte n'a pu être identifié. Le second exemple
montre une autre carte réseau qu'un développeur a vu et a saisi dans le
fichier d'identification utilisée pour identifier la carte. Cependant,
les cartes ne seront pas fonctionnelles dans les deux cas vu qu'elles
sont affichées comme "not configured", ce qui veut dire
qu'aucun pilote ne leur a été affecté.
Que puis-je faire dans le cas d'un périphérique not
configured ?
Si le périphérique ou la carte que vous avez ne vous est pas utile,
vous pouvez ignorer les périphériques "not configured"
puisqu'ils ne causeront aucun dommage à votre système. Certains
périphériques spéciaux ne sont pas configurés à bon escient afin que
le BIOS du système puisse les gérer.
Dans certains cas, c'est juste une variante d'un périphérique
supporté. Si c'est le cas, il serait relativement facile pour un
développeur d'ajouter le support de cette nouvelle carte. Dans
d'autres cas, c'est peut- être une puce ou une implémentation qui
n'est absolument pas supportée (telle que dans les exemples
précédents). Dans ce cas, un nouveau pilote devra être écrit mais ce
n'est pas toujours possible. Des fois, le périphérique n'est pas
entièrement documenté. Vous êtes bien entendu invité à écrire un
pilote pour le périphérique vous-même si vous en avez les
compétences.
Si vous utilisez un noyau d'installation, le périphérique n'est
peut-être pas supporté par la méthode d'installation que vous avez
utilisé mais supporté par un disque de démarrage différent. C'est
chose commune pour des utilisateurs de certaines cartes SCSI
populaires qui ont mal lu les notes de bas de page sur la page
consacrée à la plate-forme i386 et
qui essaient de démarrer avec des disquettes de démarrage ne
supportant pas leur carte SCSI au lieu d'utiliser la disquette
adéquate.
Si vous utilisez un noyau modifié, vous avez peut-être supprimé le
support du périphérique dont vous avez besoin. De manière générale,
la suppression de périphériques dans le noyau est une
mauvaise idée.
Avant de faire un rapport sur un périphérique "not
configured", assurez-vous d'abord que vous avez utilisé le
dernier snapshot disponible pour
voir si le support de ce périphérique n'a pas été récemment ajouté.
Puis vérifiez les
archives des listes de diffusion
pour voir si le problème n'a pas été discuté. Rappelez-vous
cependant que si vous utilisez une ancienne version d'OpenBSD, vous
devriez mettre à jour votre système pour bénéficier des derniers
pilotes.
12.1.4 - J'ai une carte listée dans le matériel "supporté" mais elle
ne fonctionne pas !
Malheureusement, beaucoup de constructeurs utilisent les numéros de
modèle pour indiquer leur position sur le marché, au lieu de la nature
technique du produit. Pour cette raison, vous avez peut-être acheté un
produit avec le même nom et du même modèle qu'un produit listé dans les
pages consacrées aux plates-formes,
alors qu'en réalité c'est un produit entièrement différent qui ne
fonctionne pas sous OpenBSD. Par exemple, plusieurs cartes réseau
sans-fil sorties mises sur le marché il y a un certain temps utilisaient
la puce Prism2 donc le pilote
(wi(4)).
Mais plus tard, lorsque des puces à bas prix sont devenues disponibles,
plusieurs fabricants ont changé leur produit pour utiliser des puces
pour lesquelles aucun pilote libre n'existait. En revanche, ils n'ont
pas changé le nom de leur produit. Les cartes réseau sans-fil sont
malheureusement loin d'êtres les seules dans ce cas.
12.2 - DEC Alpha
[aucune information pour le moment]
12.3 - AMD 64
[aucune information pour le moment]
12.4 - Carte de développement CATS ARM
[aucune information pour le moment]
12.5 - HP300
[aucune information pour le moment]
12.6 - HPPA
[aucune information pour le moment]
12.7 - i386
12.7.1 - Cartes réseau ISA
Etant donné qu'OpenBSD fonctionne bien sur le matériel ancien, les
utilisateurs finissent souvent par utiliser des cartes réseau NIC avec
les systèmes OpenBSD. Le matériel ISA nécessité beaucoup plus de
configuration et de compréhension que le matériel PCI. De manière
générale, vous ne pouvez pas vous contenter d'insérer votre carte dans
la machine et espérer qu'elle fonctionne par magie. Avec plusieurs
machines, si votre périphérique ISA n'est pas en mode "Plug 'n' Play"
(PNP), vous devez réserver les ressources que la carte utilise au niveau
du BIOS.
3Com 3C509B ep(4)
C'est une carte réseau ISA très performante, supportée par le
périphérique
ep(4).
La version 'B' peut être distinguée de la version non-B par le nom
figurant sur la carte et par une puce principale plus large sur la carte
(approximativement 2.5cm sur un côté pour la version 'B' vs. 2cm sur un
côté pour l'ancienne version), et elle fournira de meilleures
performances sur un système chargé ou doté de deux cartes réseau.
Les 3C509B sont livrées avec une configuration en mode PNP, qui
malheureusement n'est pas conforme aux standards, et cause des problèmes
dans le support
isapnp(4) d'OpenBSD.
L'adaptateur est d'abord sélectionné comme périphérique non-PNP, puis
une seconde fois lorsque le support PNP devient disponible. Le résultat
est l'affichage d'une carte réseau supplémentaire dans le dmesg. Le
fonctionnement peut alors être correct ou problématique. Il est
hautement recommandé de désactiver le mode PNP pour les cartes 3C509B et
de configurer manuellement la carte avec des paramètres non conflictuels
à l'aide des utilitaires DOS 3Com avant la configuration.
Le pilote ep(4) va trouver les cartes en utilisant n'importe quelle
combinaison matérielle qui ne cause pas de conflit avec d'autres
périphériques dans le système.
Si vous avez plusieurs cartes 3C509 dans votre système, il est
recommandé d'inscrire l'adresse MAC sur la surface des cartes située à
l'extérieur du boîtier et d'utiliser dmesg pour identifier les cartes.
Il est à noter que les cartes 3C509, 3C905 et 3C590 sont souvent
confondues. La carte 3C509 est une carte ISA 10Mbps, les cartes 3C905 et
3C590 sont des cartes PCI.
NE2000
La première carte NE2000 a été développée au milieu des années 1980 par
Novell. Depuis, plusieurs constructeurs ont produit des cartes très
similaires généralement appelées "compatible NE2000" ou clones. La
performance de ces cartes clones varie énormément. Alors que quelques
anciennes cartes "compatibles NE2000" ont de très bonnes performances,
la plupart des cartes actuellement disponibles ont de faibles
performances. Les cartes "compatible NE2000" sont supportées par le
pilote
ne(4)
sous OpenBSD.
OpenBSD va bien gérer quelques cartes "compatible NE2000" capables
d'utiliser ISAPNP lorsque le mode ISAPNP est activé. D'autres cartes
vont devoir être configurés soit par le biais de cavaliers soit à l'aide
d'un utilitaire de configuration sous DOS. Malheureusement, les
premières cartes NE2000 n'avaient pas de support pour la configuration
logicielle ou ISAPNP, il n'y a aucun standard -- vous avez besoin de
l'utilitaire fourni au départ avec votre carte. Ce qui peut souvent être
difficile à obtenir.
Le pilote ne(4) supporte trois configurations des cartes ISA NE2000 dans
le noyau GENERIC OpenBSD :
ne0: port 0x240 irq 9
ne1: port 0x300 irq 10
ne2: port 0x280 irq 9
Si ces paramètres ne sont pas acceptables, vous pouvez les ajuster en
utilisant
User Kernel Configuration (UKC) ou en
compilant un noyau personnalisé.
Il est à noter que le pilote ne(4) est assez "idiot" -- seul le port E/S
est sondé, l'IRQ correspondant est
supposée.
dmesg(8)
ne va pas refléter l'IRQ réelle de l'adaptateur dans le cas des pilotes
ISA ne(4). Si ce n'est l'IRQ réelle utilisée par votre carte, ça ne
marchera pas.
Il est à noter qu'il existe des cartes non-ISA qui utilisent le pilote
ne(4) -- des cartes PCI et PCMCIA existent. Ces notes ne s'appliquent
pas à ces cartes qui sont auto-configurés.
12.7.2 - OpenBSD ne fonctionne pas sur mon système
0386/80386SX/80486SX !
80386sx
Le 80386sx peut adresser au maximum 16M, ce qui est au plus près du
minimum supporté par OpenBSD/i386. La plupart des systèmes 80386sx ne
peuvent supporter plus de 8M de RAM, ce qui les placent dans la
catégorie 'Pour Experts Uniquement", puisque des étapes non triviales et
une seconde machine sont nécessaires pour commencer. Consultez aussi la
prochaine section :
80386
OpenBSD pourra fonctionner sur un système 80386 ou 80386sx SI ce système
a un coprocesseur mathématique (Floating Point Unit, ou FPU) 80387 ou
80387sx. Malheureusement, ces FPUs ne sont pas très communs, plusieurs
systèmes 80386 ne les auront donc pas. OpenBSD ne pourra pas fonctionner
sans ce FPU sur plate-forme i386. Encore une fois, soyez conscient que
c'est vraiment un processeur très faible pour un système d'exploitation
comme OpenBSD qui utilise autant le chiffrement. Vous ne serez
probablement satisfait des performances d'une telle machine pour une
utilisation générale.
80486SX
Le processeur 80486SX fût une version "bas de gamme" du 80486. Il lui
manque le support matériel de la virgule flottante (comme le 80386)
qu'OpenBSD nécessite. Heureusement, des processeurs complets 80486DX
sont assez communs et constituent une mise à jour facile sur la plupart
des systèmes.
12.7.3 - Mon dmesg affiche plusieurs périphériques
partageant la même interruption (IRQ) !
C'est entièrement acceptable et, en vérité, même souhaitable pour les
périphériques PCI. C'est une caractéristique de la conception du bus
PCI. Certaines personnes diront que le partage de requêtes
d'interruption est une mauvaise chose, cependant ils confondent la
situation avec un bus ISA (où le partage d'IRQs n'est pas permit) ou ils
ont une expérience avec du mauvais matériel ou logiciel.
Les périphériques ISA ne peuvent pas partager des IRQs. Si vous trouvez
des périphériques ISA partageant des IRQs, vous devez corriger le
problème.
12.7.5 - Mon clavier / ma souris n'arrête pas de se bloquer
(ou d'avoir un comportement complètement erratique) !
Ces symptômes se produisent souvent lorsqu'on utilise un "switch box"
(appelé aussi commutateur KVM) pour connecter plusieurs machines à un
seul clavier, un seul écran et une seule souris. Vous pouvez essayer
plusieurs "switch box" de différentes marques/conceptions. Cependant,
OpenBSD est plus sensible à la commutation de la souris que d'autres
systèmes d'exploitation. Le problème vient plus souvent de la
commutation de la souris. Si vous n'utilisez pas la souris, la solution
est simple : ne connectez pas le câble souris à la machine. Si vous
utilisez la souris, une solution de contournement est d'utiliser une
souris par machine et de continuer à faire de la commutation clavier et
écran.
Une autre solution de contournement consiste à utiliser un adaptateur
PS/2 vers USB, permettant à OpenBSD de voir une souris de type USB,
Si vous voulez uniquement avoir un accès console à la machine,
vous devriez peut-être considérer l'utilisation d'une console série.
12.7.6 - Est que les WinModems sont supportés ?
Les WinModems sont des modems à bas prix qui s'appuient sur le
processeur pour gérer le traitement du signal qui est normalement
effectué au niveau matériel dans un "vrai" modem. Vu le nombre de
composants WinModem incompatibles et typiquement non documentés, OpenBSD
ne supporte pas les WinModems et ce n'est pas prêt de changer.
12.7.7 - Qu'est-il arrivé au support RAID des cartes Adaptec (aac)?
Adaptec a refusé de fournir une documentation précise et utile pour
leurs contrôleurs RAID (aac(4)),
à base de FSA.
Ces contrôleurs RAID semblent être très buggés. Cette documentation est
donc nécessaire pour créer un pilote utilisable.
Vu que le pilote était très peu fiable, il a été supprimé du noyau
GENERIC.
Je peux toujours compiler mon propre noyau avec le support aac(4),
n'est-ce pas ?
Bien sûr.
Mais quelle partie de l'expression "très peu fiable" n'avez-vous pas
compris ?
Ce n'est pas une fonctionnalité "expérimentale" mais un pilote connu
pour être défectueux.
Il fonctionnera peut-être correctement avec certaines variations de
matériel mais nous ne vous recommandons pas de parier vos données sur ce
pilote.
12.7.8 - Ma carte ami(4) ne supporte qu'un seul disque logique !
ami(4)
contient un bogue connu qui cause une corruption de données si vous
utilisez plus d'un seul volume sur certains contrôleurs.
Pour les contrôleurs ayant ce problème, OpenBSD vous limitera à un seul
disque logique. Vous aurez alors un message dans votre dmesg qui
ressemble au message suivant :
ami0: FW A.04.03, BIOS vA.04.03, 4MB RAM
ami0: 3 channels, 16 targets, 2 logical drives
ami0: firmware buggy, limiting access to first logical disk
scsibus0 at ami0: 1 targets
12.8 - Mac68k
12.8.1 - Plus le temps passe, plus mon horloge dévie de l'heure
exacte. Pourquoi ?
Cela était causé par un bogue de longue durée, fixé dans OpenBSD 3.9.
12.9 - MacPPC
12.9.1 - Pourquoi mon pilote bm(4) est si lent ?
Le pilote
bm,
supportant le composant BMAC utilisé sur certains systèmes MacPPC (y
compris les premiers iMacs) a des problèmes en 100Mbps. Il est hautement
recommandé de forcer le pilote à 10Mbps en utilisant l'option "media
10baseT" dans votre fichier /etc/hostname.bm0 sinon forcez
cette vitesse au niveau de votre hub ou de votre commutateur.
12.10 - MVME68k
[aucune information pour le moment]
12.11 - MVME88k
[aucune information pour le moment]
12.12 - SPARC
[aucune information pour le moment]
12.13 - UltraSPARC (sparc64)
12.13.1 - Mon système UltraSPARC ne veut pas démarrer à partir de
l'image sur disquette
Seul les modèles Ultra 1/1e et Ultra 2 peuvent démarrer
n'importe quel OS à partir d'une disquette. Utilisez les
méthodes d'installation CD-ROM, Miniroot ou démarrage
réseau pour effectuer votre installation.
12.13.2 - J'obtiens le message "partition extends past end of unit"
dans disklabel
Le disklabel BSD ne peut décrire une géométrie disque supérieur à 8Go
sous sparc et sparc64, bien que les entrées disklabel individuelles
peuvent être plus larges.
A chaque fois que vous exécutez disklabel(8), ce dernier effectue des
vérifications pour s'assurer que les entrées disklabel correspondent
bien à sa compréhension de la géométrie disque. Seulement, comme il voit
une géométrie tronquée, il vous le signale et ne vous permettra pas
d'éditer des entrées au delà de cette zone de 8Go sauf si vous lui dites
d'utiliser la géométrie réelle.
Vous pouvez faire cela à l'aide de la commande 'g' de l'éditeur en ligne
de commande de disklabel(8) et dites
lui d'utiliser "[d]isk geometry" :
# disklabel -E wd0
# Inside MBR partition 3: type A6 start 63 size 17912412
[...]
Initial label editor (enter '?' for help at any prompt)
> g
[d]isk, [b]ios, or [u]ser geometry: [d] d
> w
> q
Vous aurez toujours des messages d'avertissement, mais vous pourrez
configurer et utiliser votre disque comme vous le souhaitez.
Une meilleure solution nécessiterait d'être compatible avec les systèmes
existants déjà utilisés ainsi qu'avec Solaris s'exécutant sur des
disques de capacité supérieure à 8Go mais cette solution n'existe pas
aujourd'hui.
12.14 - DEC VAX
12.14.1 - Puis-je utiliser le simulateur VAX SIMH ?
Oui !
Le simulateur VAX SIMH peut être
utilisé pour effectivement émuler un un vrai VAX.
Les instructions sont disponibles ici.
![[OpenBSD]](../../images/smalltitle.gif){kind=small}
![[back]](../../images/back.gif){kind=small}
www@openbsd.org