PCI devices zijn meestal zelfconfigurerend -- de computer en het
besturingssysteem zullen middelen toekennen aan de kaarten zoals vereist.
Interrupts kunnen gedeeld worden op de PCI bus. Ze kunnen dit niet
alleen, het systeem zal vaak beter presteren wanneer de IRQs gedeeld zijn,
vooral op i386 systemen.
Er zijn verscheidene verschillende PCI bus standaarden.
U zal nu en dan een PCI2.2 specificatie kaart vinden die gewoon niet zal
werken in een PCI2.1 specificatie systeem.
Ook zullen veel kaarten met on-board bridges (zoals multi-port netwerkkaarten)
niet goed werken in oudere systemen.
De PCI bus ondersteunt twee niveaus van signalering, 3.3v en 5v.
Kaarten die werken met 3.3v signalering hebben een tweede inkerving in hun
PCI connector.
De meeste PCI kaarten gebruiken 5v signalering, wat door de meeste computers
gebruikt wordt.
De Soekris single-board computers (Net45x1 en Net4801) zijn
veel voorkomende computers die alleen 3.3v signalering ondersteunen.
12.1.2 - ISA devices
ISA devices kunnen geen middelen delen, en moeten in het algemeen handmatig
geconfigureerd worden op instellingen die niet in conflict zijn met andere
devices in het systeem.
Sommige ISA devices zijn "Plug and Play"
(isapnp(4))
-- als u echter enig probleem hebt met deze devices, verifieer dan hun
configuratie in uw
dmesg(8), ISAPnP werkt niet altijd zoals gewenst.
In het algemeen, als u een keuze hebt, wordt de meeste mensen best
aangeraden om ISA kaarten te vermijden ten voordele van PCI. ISA kaarten zijn
moeilijker te configureren en hebben een veel negatievere invloed op de
prestaties van het systeem.
12.1.3 - Mijn device wordt "herkend" maar zegt "not
configured" in dmesg
In het kort, betekent dit dat uw device niet ondersteund wordt door de
kernel die u gebruikt, dus u zal het niet kunnen gebruiken.
PCI en veel andere types van devices bieden identificatie-informatie zodat
het besturingssysteem devices juist kan herkennen en ondersteunen.
Herkenning toevoegen is gemakkelijk, ondersteuning toevoegen is dat vaak niet.
Hier is een gedeelte van een dmesg met twee voorbeelden van
"not configured" devices:
...
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
...
Bij de eerste (een netwerkadapter) werd de code van de verkoper
geïdentificeerd en het algemene type van kaart werd bepaald, maar het
precieze model van de kaart niet.
Het tweede voorbeeld was een andere netwerkadapter, die een ontwikkelaar
gezien had en ingevoerd had in het identificatiebestand dat gebruikt wordt
om de kaart te identificeren.
In beide gevallen echter, zullen de kaarten niet-functioneel zijn,
aangezien beide getoond worden als "not configured", wat betekent
dat er zich aan de kaart geen driver heeft vastgemaakt.
Wat kan ik doen aan een not configured device?
Als het device of de kaart die u ziet niet degene is die u nodig hebt,
kan u de "not configured" devices veilig negeren, ze zullen uw
systeem geen kwaad doen.
Sommige "special purpose" devices worden met opzet ongeconfigureerd gelaten
zodat het systeem BIOS ze zal behandelen.
In sommige gevallen is het gewoon een variant van een reeds ondersteund
device, en in dit geval zou het voor een ontwikkelaar relatief eenvoudig
kunnen zijn om ondersteuning voor de nieuwe kaart toe te voegen.
In andere gevallen zou het een volledig niet-ondersteunde chipset of
implementatie kunnen zijn (zoals de bovenstaande voorbeelden).
In dat geval zou er een nieuwe driver geschreven moeten worden, wat misschien
zelfs niet mogelijk is als het device niet volledig gedocumenteerd is.
U bent zeker welkom om zelf een driver te schrijven voor het device.
Als u een installatiekernel draait, zou het kunenn dat het device niet
ondersteund wordt door het installatiemedium dat u gebruikte, maar misschien
wel ondersteund wordt door een andere boot disk.
Dit komt vaak voor bij gebruikers van sommige populaire SCSI kaarten die
de voetnoten op de i386 platform pagina
verkeerd gelezen hebben, en alle bootdiskettes uitproberen waarop hun
SCSI kaart NIET ondersteund wordt, veeleer dan die ene waarop ze wel
ondersteund wordt.
Als u een gewijzigde kernel draait, kan het zijn dat u ondersteuning
hebt verwijderd voor een device dat u nu nodig hebt.
In het algemeen is het verwijderen van devices uit een kernel een
slecht idee.
Dit is een van de redenen waarom.
Alvorens een "not configured" device te melden, zorg dan dat u
eerst de meest recente snapshot hebt getest,
aangezien ondersteuning reeds toegevoegd zou kunnen zijn, en kijk de
mailinglijst archieven na om te zien of het
probleem reeds besproken is.
Onthou echter, als u een oudere versie van OpenBSD gebruikt, dat u in het
algemeen zal moeten upgraden om het voordeel van gelijk welke nieuw geschreven
driver te verkrijgen.
12.1.4 - Ik heb een kaart die vermeld staat als "ondersteund", maar ze
werkt niet!
Jammer genoeg gebruiken veel fabrikanten product modelnummers om hun
marktpositie aan te duiden, veeleer dan de technische aard van een product.
Om deze reden kan u een product kopen met dezelfde naam of hetzelfde
modelnummer als een product vermeld op de
platform pagina's, maar met een totaal verschillend
product komen te zitten, dat misschien niet werkt met OpenBSD.
Veel vroege draadloze netwerkadapters waren bijvoorbeeld gebaseerd op de
Prism2 chip set, gebruik makend van de
(wi(4))
driver, maar later, wanneer goedkopere chips beschikbaar werden, veranderden
veel fabrikanten hun product om chips te gebruiken waarvoor er geen open
bron drivers bestaan, maar ze veranderden nooit hun modelnummers.
Draadloze netwerkadapters zijn jammer genoeg helemaal niet het enige
voorbeeld hiervan.
12.1.5 - Worden WinModems ondersteund?
WinModems zijn goedkope modems die zich verlaten op de processor om veel
van de signaalverwerking te doen die in een "echte" modem gewoonlijk in
hardware gedaan wordt.
Door de variëteit van incompatibele en typisch niet-gedocumenteerde
WinModem chips, is er geen ondersteuning voor WinModems in OpenBSD, en dit
zal waarschijnlijk niet veranderen.
12.1.6 - Wat is er gebeurd met de Adaptec RAID ondersteuning (aac)?
Adaptec weigerde nuttige en nauwkeurige documentatie aan te bieden over hun
FSA-gebaseerde
(aac(4))
RAID controllers.
Aangezien deze RAID controllers heel buggy lijken te zijn, is deze
documentatie cruciaal voor een nuttige driver.
Aangezien deze driver zo onbetrouwbaar was, werd hij verwijderd uit de
GENERIC kernel.
Ik kan toch mijn eigen kernel compileren met aac(4) ondersteuning, juist?
Natuurlijk.
Maar welk deel van "onbetrouwbaar" hebt u niet begrepen?
Dit is geen "experimentele" mogelijkheid, dit is een driver waarvan geweten
is dat hij fouten bevat.
Misschien werkt hij goed genoeg met bepaalde variaties van hardware om
bruikbaar te zijn, maar we raden niet aan om uw gegevens er op in te zetten.
12.1.7 - Mijn ami(4) kaart ondersteunt slechts één logische schijf!
Er is een gekende bug in
ami(4)
die gegevenscorruptie zal veroorzaken indien u meer dan één logische schijf
gebruikt op bepaalde controllers.
Bij controllers met dit probleem zal OpenBSD u beperken tot één logische
schijf, met een boodschap in dmesg die lijkt op:
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.2 - DEC Alpha
[nog niets]
12.3 - AMD 64
12.3.1 - Kan ik OpenBSD/amd64 draaien op mijn Intel P4
In het geval van veel nieuwere processoren is het antwoord "ja".
Jammer genoeg is het moeilijk om uit te zoeken welke Intel processorvariaties
netjes de amd64 instructieset ondersteunen en welke niet, het is gewoonlijk
gemakkelijker om het gewoon te proberen en te kijken of het werkt.
12.3.2 - Kan ik mijn i386 binary draaien op OpenBSD/amd64?
Neen.
OpenBSD/amd64 is een platform dat volledig gescheiden is van OpenBSD/i386,
en momenteel wordt er geen binaire compatibiliteit voorzien.
Aangezien OpenBSD open source toepassingen aanmoedigt, is er bij de
ontwikkelaars niet veel interesse in binaire compatibiliteit tussen
platformen.
Merk op dat de OpenBSD/amd64 en OpenBSD/i386 boot loaders (vanaf OpenBSD 4.2)
elkaars kernels kunnen laden, wat het gemakkelijker maakt om het systeem
te herinstalleren met het "andere" platform.
Dat moet echter volledig wissen en herinstalleren zijn -- binaries die
overblijven van de "vorige" installatie zullen waarschijnlijk uw leven
onaangenaam maken.
12.3.3 - Is het altijd beter om OpenBSD/amd64 te draaien op processoren
die dat kunnen?
Niet altijd.
Er zijn echter een aantal redenen waarom men kan wensen OpenBSD/i386
te gebruiken i.p.v. OpenBSD/amd64, zelfs op hardware die amd64 code
ondersteunt:
Nood aan i386 binaire (of ander besturingssysteem) compatibiliteit.
Moet toepassingen draaien die niet "64 bit clean" zijn.
Moet de schijf naar een andere machine kunnen verplaatsen.
Op sommige toepassingen en sommige hardware kan OpenBSD/i386 beter
presteren dan OpenBSD/amd64.
Relatief weinig mensen zullen dit ooit ervaren, en er wordt aan gewerkt
om deze situaties zo veel mogelijk te elimineren.
12.4 - ARM-gebaseerde apparaten
[nog niets]
12.5 - HP300
[nog niets]
12.6 - HPPA
[nog niets]
12.7 - i386
12.7.1 - ISA NICs
Aangezien OpenBSD goed draait op oudere hardware, zullen gebruikers
uiteindelijk vaak ISA NICs gebruiken op OpenBSD systemen.
ISA hardware vereist veel meer configuratie en begrip dan PCI hardware.
In het algemeen kan u niet gewoon de kaart in de computer duwen en
verwachten dat ze magisch werkt.
In veel machines moet u, als uw ISA device niet in een "Plug 'n' Play" (PNP)
modus staat, de middelen die de kaart gebruikt, reserveren in het BIOS
van het systeem.
3Com 3C509B ep(4)
Dit is een uitstekend presterende ISA NIC, ondersteund door de
ep(4)
driver.
De 'B' versie kan onderscheiden worden van de niet-B versie door labeling
op de kaart en door de grotere "hoofd"-chip op het bord (ongeveer 2.5cm voor
een zijde voor de 'B' versie, tegenover 2cm voor een zijde op de oudere
versie), en zal betere prestaties bieden op een belast of dual netwerkkaart
systeem.
De 3C509B wordt geleverd geconfigureerd in een PNP modus, die jammer genoeg
niet voldoet aan de standaarden en problemen veroorzaakt in OpenBSD's
isapnp(4) ondersteuning.
De adapter wordt eerst opgepikt als een niet-PNP device, vervolgens opnieuw
nadat de PNP ondersteuning on-line komt, met als resultaat dat er een extra
NIC getoond wordt in de dmesg.
Dit kan prima werken, of het kan andere problemen veroorzaken. Het wordt ten
zeerste aanbevolen dat de 3C509B kaarten PNP modus uitgeschakeld hebben en,
vóór de configuratie, handmatig geconfigureerd worden op
niet-conflicterende instellingen met de 3Com DOS-gebaseerde
configuratie-utilities.
De ep(4) driver zal de kaarten oppikken op gelijk welke hardware combinatie
die niet conflicteert met andere devices in het systeem.
Als u meerdere 3C509 kaarten in uw systeem hebt, wordt het aanbevolen dat u
de rug van de kaarten labelt met het MAC adres, en de dmesg gebruikt om
te achterhalen welke welke is.
Merk op dat de 3C509, de 3C905 en de 3C590 vaak verward worden.
De 3C509 is een 10Mbps ISA card, de 3C905 en 3C590 zijn PCI kaarten.
NE2000
De oorspronkelijke NE2000 NIC werd in het midden van de jaren '80 ontwikkeld
door Novell. Sinds dan hebben veel fabrikanten kaarten geproduceerd die heel
gelijkaardig zijn, die in het algemeen NE2000-compatibel genoemd worden, of
klonen.
Hoewel enkele oudere NE2000-compatibele kaarten heel goed presteerden,
presteren veel van de momenteel beschikbare vrij slecht.
NE2000-compatibelen worden ondersteund door de
ne(4)
driver in OpenBSD.
OpenBSD zal sommige ISAPNP-capabele NE2000-compatibele kaarten goed
behandelen indien de ISAPNP modus aangezet wordt.
Andere kaarten zullen ofwel met jumpers ofwel met een DOS-gebaseerde
configuratie-utility moeten ingesteld worden.
Jammer genoeg zijn er, aangezien de orginele NE2000 kaarten geen software
configuratie of ISAPNP ondersteuning hadden, hiervoor geen standaarden --
u hebt de utility nodig die oorspronkelijk bij uw specifieke kaart geleverd
werd.
Dit kan vaak moeilijk zijn om te verkrijgen.
De ne(4) driver ondersteunt drie configuraties van de ISA NE2000 kaart
in de GENERIC OpenBSD kernel:
ne0: port 0x240 irq 9
ne1: port 0x300 irq 10
ne2: port 0x280 irq 9
Als deze instellingen niet aanvaardbaar zijn, kan u ze aanpassen met de
User Kernel Configuration (UKC) of door
een aangepaste kernel te bouwen.
Merk op dat de ne(4) driver vrij "dom" is -- alleen de I/O poort wordt
onderzocht, als gelijk welk van de bovenstaande I/O adressen gedetecteerd
wordt, dan wordt de overeenstemmende IRQ aangenomen.
dmesg(8)
zal niet de werkelijke IRQ van de adapter weerspiegelen in het geval van
ISA ne(4) drivers.
Als dit niet de werkelijke IRQ is waarop uw kaart is ingesteld, zal ze niet
werken.
Merk op dat er niet-ISA kaarten zijn die de ne(4) driver gebruiken -- er
bestaan ook PCI en PCMCIA ne(4) kaarten. Deze opmerkingen zijn daarop niet
van toepassing, die kaarten zijn auto-configurerend.
12.7.2 - OpenBSD wil niet werken op mijn 80386/80386SX/80486SX systeem!
80386SX/DX
Ondersteuning voor de 80386DX en 80386sx processoren werd achterwege gelaten
voor OpenBSD 4.2.
Bovenop de beperkingen van de 80386 chip zijn deze systemen gewoon te traag
en hadden ze zelden voldoende RAM en de vereiste FPU om OpenBSD te draaien.
80486SX
De 80486SX chip was een "goedkope" versie van de 80486, die de hardware
floating point ondersteuning ontbeert (zoals de 80386) die OpenBSD vereist.
Gelukkig zijn volledige 80486DX chips redelijk beschikbaar, en is in de
meeste systemen een gemakkelijke upgrade.
De 80486DX en nieuwere chips draaien OpenBSD prima.
12.7.3 - Mijn dmesg toont meerdere devices die dezelfde Interrupt
(IRQ) delen!
Dit is volledig aanvaardbaar, en in feite zelfs wenselijk voor PCI devices.
Dit is een ontwerpfunctionaliteit van de PCI bus.
Sommige mensen zullen zeggen dat interrupt requests (IRQs) delen slecht is,
nochtans verwarren ze ofwel de situatie met de ISA bus (waarbij het delen
van IRQ's niet toegestaan is), of ervaring uit het verleden met defecte
hardware of software.
ISA devices kunnen geen IRQ's delen. Als u ziet dat ISA devices IRQ's delen,
moet u dit probleem corrigeren.
12.7.4 - Mijn toetsenbord/muis blijft vastlopen (of wordt gek)!
Dit wordt het vaakst gezien wanneer een "switch box" (soms een "KVM swicth"
genoemd) gebruikt wordt om
meerdere computers aan één toetsenbord, monitor en muis te hangen.
U kan experimenteren met verschillende merken en ontwerpen van switch boxes,
maar OpenBSD lijkt gevoeliger aan het schakelen van de muis dan sommige andere
besturingssystemen.
Het probleem is gewoonlijk enkel het schakelen van de muis.
Als u de muis niet gebruikt, is de oplossing eenvoudig: hang de muiskabel
niet aan de computer.
Als u de muis gebruikt, is een gemakkelijke oplossing "één muis per
computer", en enkel het toetsenbord en de monitor schakelen.
Het zou kunnen dat het gebruik van een PS/2 muis -> USB poort adaptor (zodat
OpenBSD een USB muis ziet) dit probleem omzeilt.
Als u gewoon console toegang wil tot de machine, kan u in de plaats
misschien het gebruik van een
seriële console overwegen.
12.8 - Landisk
[nog niets]
12.9 - Luna88k
[nog niets]
12.10 - Mac68k
[nog niets]
12.11 - MacPPC
12.11.1 - Waarom is mijn bm(4) netwerkadapter zo traag?
De
bm
driver, die de BMAC chip ondersteunt die op sommige MacPPC systemen (inclusief
vroege iMacs) gebruikt wordt, heeft problemen wanneer hij op 100Mbps gedraaid
wordt.
Het wordt ten zeerste aanbevolen dat u de driver forceert op 10Mbps door
een "media 10baseT" optie te gebruiken in uw
/etc/hostname.bm0 bestand, of forceer het anders op 10Mbps op uw
hub of switch.
12.12 - MVME68k
[nog niets]
12.13 - MVME88k
[nog niets]
12.14 - SGI
[nog niets]
12.15 - SPARC
[nog niets]
12.16 - UltraSPARC (sparc64)
12.16.1 - Mijn UltraSPARC wil niet booten vanaf de diskette-image
Alleen de Ultra 1/1e en Ultra 2 kunnen gelijk welk besturingssysteem
vanaf diskette starten.
Gebruik in de plaats CD-ROM, Miniroot, of netwerk boot om uw installatie te
doen.
12.16.2 - Ik krijg "partition extends past end of unit" boodschappen
in disklabel
Op sparc en sparc64 systemen kan de BSD disklabel een schijfgeometrie
groter dan 8 GB niet beschrijven, hoewel individuele disklabel entries
groter kunnen zijn.
Elke keer u disklabel(8) draait, voert het enkele gezondheidstests voor de
disklabel uit tegen wat het denkt dat de juiste schijfgeometrie is,
en aangezien het een afgebroken geometrie ziet, waarschuwt het u en zal het
u geen entries buiten dit 8GB gebied laten wijzigen, tenzij u vraagt de
echte schijfgeometrie te gebruiken.
Doe dit met het 'g' commando van de commandogestuurde editor van
disklabel(8) en vraag het de
"[d]isk geometry" te gebruiken:
# 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
U zal nog steeds de waarschuwingsboodschappen krijgen, maar u kan uw schijf
configureren en gebruiken zoals u wenst.
Een goede oplossing zou compatibel moeten zijn met bestaande systemen die
al in gebruik zijn, én met Solaris dat draait op schijven groter dan 8 GB,
maar dit is nog niet uitgewerkt.
12.17 - DEC VAX
12.17.1 - Kan ik de SIMH VAX simulator gebruiken?
Ja!
De SIMH VAX simulator
kan gebruikt worden om effectief een echte VAX te emuleren.
Instructies vindt u hier.
12.18 - Sharp Zaurus
12.18.1 - USB apparaten werken niet
De Zaurus heeft momenteel heel weinig beschikbaar op zijn USB poort, dus
vele USB apparaten zullen niet werken als ze rechtstreeks met de Zaurus
worden verbonden.
U zal een gevoede USB hub moeten gebruiken om deze apparaten te gebruiken.
![[OpenBSD]](../../images/smalltitle.gif){kind=small}
![[terug]](../../images/back.gif){kind=small}
www@openbsd.org