PCI devices are mostly self-configuring -- the computer and OS will
allocate resources to the cards as required.
Interrupts can be shared on the PCI bus. Not only can they be, the
system will often perform better when the IRQs are shared, especially on
i386 systems.
There are several different PCI bus standards.
You will occasionally find a PCI2.2 specification card that will just
not work in a PCI2.1 specification system.
Also, many cards with on-board bridges (such as, multi-port network
cards) will not work well in older systems.
The PCI bus supports two levels of signaling, 3.3v and 5v.
Cards that work with 3.3v signaling have a second notch cut in their
PCI connector.
Most PCI cards use 5v signaling, which is used by most computers.
The Soekris single-board computers (Net45x1 and Net4801) are
commonly-encountered computers that only support 3.3v signaling.
12.1.2 - ISA devices
ISA devices cannot share resources, and in general, must be
manually configured to settings that don't conflict with other
devices in the system.
Some ISA devices are "Plug and Play"
(isapnp(4))
-- if you have any problem with these devices, though, verify their
configuration in your
dmesg(8), ISAPnP doesn't always work as desired.
In general, if you have a choice, most people are best advised to avoid
ISA cards in favor of PCI. ISA cards are more difficult to configure and
have a much greater negative impact on the system's performance.
12.1.3 - My device is "recognized" but says "not
configured" in dmesg
In short, it means your device is not supported by the kernel you
are using, so you will not be able to use it.
PCI and many other types of devices offer identifying information
so that the OS can properly recognize and support devices.
Adding recognition is easy, adding support is often not.
Here is part of a dmesg with two examples of "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
...
The first one (a network adapter) had its vendor code identified and the
general type of card was determined, but not the precise model of the
card.
The second example was another network adapter, this one a developer had
seen and had entered into the identification file that is
used to identify the card.
In both cases, however, the cards will be non-functional, as both are
shown as "not configured", meaning no driver has attached to
the card.
What can I do about a not configured device?
If the device or card you are seeing is not one you need, you can
safely ignore the "not configured" devices, they will not hurt
your system.
Some "special purpose" devices are deliberately left unconfigured so the
system's BIOS will handle them.
In some cases, it is just a variation of an already supported
device, in which case, it may be relatively easy for a developer to add
support for the new card.
In other cases, it may be a totally unsupported chip set or
implementation (such as the above examples).
In that case, a new driver would have to be written, which may not even
be possible if the device is not fully documented.
You are certainly welcome to write a driver for the device yourself.
If you are running an install kernel, the device may not be
supported by the install media you used, but may be supported by a
different boot disk.
This is a common with users of some popular SCSI cards who misread the
footnotes on the i386 platform page
and try all the boot floppies their SCSI card is NOT supported on,
rather than the one that it is supported on.
If you are running a modified kernel, you may have removed support
for a device you now need.
In general, removing devices from a kernel is a
bad idea.
This is one reason why.
Before reporting a "not configured" device, make sure you
have first tested the most recent
snapshot, as support may already have
been added, and check the mail list archives
to see if the issue has been discussed already.
Remember, however, if you are using an older version of OpenBSD, you
will generally have to upgrade to get the benefit of any new driver
written.
12.1.4 - I have a card listed as "supported", but it doesn't
work!
Unfortunately, many manufacturers use product model numbers to indicate
marketplace position, rather than the technical nature of a product.
For this reason, you may buy a product with the same name or model
number as a product listed in the platform
pages, but end up with a totally different product that may not work
with OpenBSD.
For example, many early wireless network adapters were based on the
Prism2 chip set, using the
(wi(4))
driver, but later, when lower-cost chips became available, many
manufacturers changed their product to use chips for which no open
source drivers exist, but never changed their model numbers.
Wireless network adapters, unfortunately, are far from the only
example of this.
12.1.5 - Are WinModems supported?
WinModems are low-cost modems which rely on the processor to do much of
the signal processing normally done in hardware in a "real" modem.
Due to the variety of incompatible and typically undocumented WinModem
chips, there is no support for WinModems in OpenBSD, and this is not
likely to change.
12.1.6 - What happened to the Adaptec RAID support (aac)?
Adaptec has refused to provide useful and accurate documentation about
their FSA-based
(aac(4))
RAID controllers.
As these RAID controllers seem to be very buggy, this documentation is
critical for a useful driver.
Since this driver was so unreliable, it was removed from the GENERIC
kernel.
I can compile my own kernel with aac(4) support, right?
Sure.
But what part of "unreliable" did you fail to understand?
This isn't an "experimental" feature, this is a known-flawed driver.
Maybe it works with some variations of hardware sufficiently well to be
usable, but we don't recommend betting your data on it.
12.1.7 - My ami(4) card will only support one logical disk!
There is a known bug with
ami(4)
which will cause data corruption if you use more than one volume on
some controllers.
On controllers with this issue, OpenBSD will limit you to one logical
disk, resulting in a message in your dmesg that looks like:
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
[nothing yet]
12.3 - AMD 64
12.3.1 - Can I run OpenBSD/amd64 on my Intel P4
In the case of many newer processors, the answer is "yes".
Unfortunately, trying to find out which Intel processor variations do
and which do not properly support the amd64 instruction set is difficult,
it is usually easier to just try it and see if it works.
12.3.2 - Can I run my i386 binary on OpenBSD/amd64?
No.
OpenBSD/amd64 is a totally separate platform from OpenBSD/i386, and at
this point, no binary compatibility is provided.
As OpenBSD encourages open source applications, there is not much
interest in binary compatibility across platforms with developers.
Note that the OpenBSD/amd64 and OpenBSD/i386 boot loaders will
(as of OpenBSD 4.2)
load each other's kernels, making it easier to reload a system with the
"other" platform.
However, it has to be a complete wipe and reload -- left-over binaries
from the "previous" installation will most likely make your life
unpleasant.
12.3.3 - Is it always better to run OpenBSD/amd64 on processors that
can?
Not always.
There are a number of reasons one may desire to use OpenBSD/i386
over OpenBSD/amd64, even on hardware that supports amd64 code:
Need for i386 binary (or other OS) compatibility.
Need to run apps that are not "64 bit clean".
Need for ability to move the disk system to another machine
On some apps and some hardware, OpenBSD/i386 may outperform
OpenBSD/amd64.
Relatively few people will ever experience this, and work is
on-going to eliminate as many of these situations as possible.
12.4 - ARM-based appliances
[nothing yet]
12.5 - HP300
[nothing yet]
12.6 - HPPA
[nothing yet]
12.7 - i386
12.7.1 - ISA NICs
As OpenBSD runs well on older hardware, users often will end up using
ISA NICs on OpenBSD systems.
ISA hardware requires much more configuration and understanding than
does PCI hardware.
In general, you can't just stuff the card in the computer and expect it
to magically work.
In many machines, if your ISA device is not in a "Plug 'n' Play" (PNP)
mode, you must reserve the resources the card uses in the system's BIOS.
3Com 3C509B ep(4)
This is an excellent performing ISA NIC, supported by the
ep(4)
driver.
The 'B' version can be distinguished from the non-B version by labeling
on the card and by the larger "main" chip on the board (approximately
2.5cm on a side for the 'B' version, vs. 2cm on a side on the older
version), and will provide better performance on a loaded or dual
network card system.
The 3C509B ships configured in a PNP mode, which unfortunately does not
comply with standards, and causes problems in OpenBSD's
isapnp(4) support.
The adapter is picked up first as a non-PNP device, then again after the
PNP support comes on-line, resulting in an extra NIC showing in the
dmesg.
This may work fine, or it may cause other problems. It is highly
recommended that the 3C509B cards have PNP mode disabled and manually
configured to non-conflicting settings using the 3Com DOS-based
configuration utilities before configuration.
The ep(4) driver will pick the cards up at any hardware combination that
does not conflict with other devices in the system.
If you have multiple 3C509 cards in your system, it is recommended that
you label the cards' spine with the MAC address, and use the dmesg to
identify which is which.
Note that the 3C509, the 3C905 and the 3C590 are often confused.
The 3C509 is a 10Mbps ISA card, the 3C905 and 3C590 are PCI
cards.
NE2000
The original NE2000 NIC was developed in the mid-1980s by Novell.
Since then, many manufacturers have produced cards that are very
similar, which are generally called NE2000-compatibles, or clones.
Performance of these clone cards varies greatly.
While some older NE2000-compatible cards performed very well, many of
the currently-available ones perform poorly.
NE2000-compatibles are supported by the
ne(4)
driver in OpenBSD.
OpenBSD will handle some ISAPNP-capable NE2000-compatible cards well if
the ISAPNP mode is turned on.
Other cards will have to be set using either jumpers or a DOS-based
configuration utility.
Unfortunately, as the original NE2000 cards did not have software
configuration or ISAPNP support, there are no standards for this -- you
need the utility that will have been originally supplied with your
specific card.
This can often be difficult to obtain.
The ne(4) driver supports three configurations of the ISA NE2000 card
in the GENERIC OpenBSD kernel:
ne0: port 0x240 irq 9
ne1: port 0x300 irq 10
ne2: port 0x280 irq 9
If these settings are not acceptable, you can adjust them using
User Kernel Configuration (UKC) or
by building a customized kernel.
Note that the ne(4) driver is fairly "dumb" -- only the I/O port is
probed, if any of the above I/O addresses is detected, the corresponding
IRQ is assumed.
dmesg(8)
will not reflect the actual IRQ of the adapter in the case of ISA ne(4)
drivers.
If this is not the actual IRQ your card is set to, it will not work.
Note that there are non-ISA cards that use the ne(4) driver -- PCI and
PCMCIA ne(4) cards exist. These notes do not apply to them, these
devices are auto-configuring.
12.7.2 - OpenBSD won't work on my 80386/80386SX/80486SX system!
80386SX/DX
Support for the 80386DX and 80386sx processors was dropped for OpenBSD
4.2.
In addition to limitations of the 80386 chip, the systems are just too
slow and rarely had enough RAM and the FPU required to run OpenBSD.
80486SX
The 80486SX chip was a "low-cost" version of the 80486, which lacked the
hardware floating point support (like the 80386) OpenBSD requires.
Fortunately, full 80486DX chips are fairly available, and is an easy
upgrade in most systems.
The 80486DX and newer chips run OpenBSD fine.
12.7.3 - My dmesg shows multiple devices sharing the same Interrupt
(IRQ)!
This is entirely acceptable, and in fact, even desirable for PCI
devices.
This is a design feature of the PCI bus.
Some people will say that sharing interrupt requests (IRQs) is bad,
however they are either confusing the situation with the ISA bus (where
IRQ sharing is not permitted), or past experience with broken hardware
or software.
ISA devices can not share IRQs. If you find ISA devices sharing IRQs,
you must correct this problem.
12.7.4 - My keyboard/mouse keeps locking up (or goes crazy)!
This is most often seen when using a "switch box" (sometimes called a
"KVM switch") to attach multiple
computers to one keyboard, monitor and mouse.
You can experiment with different brand and design switch boxes, but
OpenBSD seems to be more sensitive to switching the mouse than some
other operating systems.
The problem is usually just the switching of the mouse.
If you are not using the mouse, the solution is simple:
don't attach the mouse cable to the computer.
If you are using the mouse, an easy solution is "one mouse per computer",
and switch just the keyboard and monitor.
You may find using a PS/2 Mouse -> USB port adapter (so OpenBSD sees a
USB mouse) will work around this problem.
If you just want console access to the machine, you
may wish to consider using a
serial console instead.
12.8 - Landisk
[nothing yet]
12.9 - Luna88k
[nothing yet]
12.10 - Mac68k
[nothing yet]
12.11 - MacPPC
12.11.1 - Why is my bm(4) network adapter so slow?
The
bm
driver, supporting the BMAC chip used on some MacPPC systems (including
early iMacs) has issues when run at 100Mbps.
It is highly recommended that you force the driver to 10Mbps by using
a "media 10baseT" option in your /etc/hostname.bm0
file, or otherwise force it to 10Mbps at your hub or switch.
12.12 - MVME68k
[nothing yet]
12.13 - MVME88k
[nothing yet]
12.14 - SGI
[nothing yet]
12.15 - SPARC
[nothing yet]
12.16 - UltraSPARC (sparc64)
12.16.1 - My UltraSPARC won't boot from the floppy image
Only the Ultra 1/1e and Ultra 2 can boot any OS from floppy disk.
Use CD-ROM, Miniroot, or network boot to do your installation instead.
12.16.2 - I'm getting "partition extends past end of unit"
messages in disklabel
On sparc and sparc64 systems, the BSD disklabel cannot describe a disk
geometry larger than 8GB, while individual disklabel entries can be
larger.
Everytime you run disklabel(8), it performs some sanity checks of the
disklabel entries against what it thinks is the correct drive geometry,
and since it sees a truncated geometry, it warns and will not let you
edit entries outside this 8GB area unless you tell it to use the real
drive geometry.
Do this using the 'g' command of the command-driven editor of
disklabel(8) and tell it to use the
"[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
You will still get the warning messages, but you can configure and use
your disk as desired.
A proper solution would have to be compatible with existing systems
already in use, plus be compatible with Solaris running on disks larger
than 8GB, but this has not been worked out yet.
12.17 - DEC VAX
12.17.1 - Can I use the SIMH VAX simulator?
Yes!
The SIMH VAX simulator
can be used to effectively emulate a real VAX.
Instructions can be found here.
12.18 - Sharp Zaurus
12.18.1 - USB devices aren't working properly
The Zaurus has very little current available on its USB port, so many
USB devices will not work plugged directly into the Zaurus.
You will need to use a powered USB hub to run these devices.
![[OpenBSD]](../images/smalltitle.gif){kind=small}
![[back]](../images/back.gif){kind=small}
www@openbsd.org