LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2003-08-19 13:42:29 +00:00
parent 927eef594b
commit e1ff215426
3 changed files with 326 additions and 204 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
View File

@ -3442,7 +3442,7 @@ nfs server attached by a Null-Modem parallel cable. </Para>
Plug-and-Play-HOWTO</ULink>,
<CiteTitle>The Linux Plug-and-Play HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: September 2002</CiteTitle>.
<CiteTitle>Updated: August 2003</CiteTitle>.
How to get your Linux system to support Plug-and-Play. </Para>
</ListItem>

2
LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
View File

@ -1464,7 +1464,7 @@ How to install and use PCMCIA Card Services for Linux. </Para>
Plug-and-Play-HOWTO</ULink>,
<CiteTitle>The Linux Plug-and-Play HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: September 2002</CiteTitle>.
<CiteTitle>Updated: August 2003</CiteTitle>.
How to get your Linux system to support Plug-and-Play. </Para>
</ListItem>

526
LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml
View File

@ -3,10 +3,12 @@
<title> Plug-and-Play-HOWTO </title>
<author>David S.Lawyer
<tt><url url="mailto:dave@lafn.org"></tt>
<date> v1.06, September 2002
<date> v1.07, August 2003
<!--
Revision history:
v1.07 August 2003: New M$ url, reserve resources for isa-pnp, lspci+,
scanport may not find hdw, finding dev. and config.
v1.06 September 2002: Revised about telling the BIOS if the OS is PnP
v1.05 July 2002: typos: or => of, and => an, A Allocate => Allocate,
programs => program; Dell PCs: "Plug and Play Configuration Error",
@ -52,11 +54,11 @@ It doesn't cover what's called "Universal Plug and Play"
<sect> Introduction
<sect1> Copyright, Trademarks, Disclaimer, & Credits
<sect1>1. Copyright, Trademarks, Disclaimer, & Credits
<sect2> Copyright
<p> Copyright (c) 1998-2001 by David S. Lawyer <url url="mailto:dave@lafn.org">
<!-- license.H begin -->
<p> Copyright (c) 1998-2003 by David S. Lawyer <url url="mailto:dave@lafn.org">
<!-- license.D begin -->
Please freely copy and distribute (sell or give away) this document
in any format. Send any corrections and comments to the document
@ -67,7 +69,7 @@ provided that you:
<item> If it's not a translation: Email a copy of your derivative work
(in a format LDP accepts) to the author(s) and maintainer (could be
the same person). If you don't get a response then email the LDP
(Linux Documentation Project): submit@linuxdoc.org.
(Linux Documentation Project): submit@en.tldp.org.
<item>License the derivative work in the spirit of this license or use
GPL. Include a copyright notice and at least a pointer to the
license used.
@ -85,9 +87,9 @@ them. Since this is free documentation, it should be obvious that I
cannot be held legally responsible for any errors.
<sect2>Trademarks.
<p> Any brand names (starts with a capital letter) should be assumed to
be a trademark). Such trademarks belong to their respective owners.
<!-- copyright.H end -->
<p> Any brand names (starts with a capital letter such as MS Windows)
should be assumed to be a trademark). Such trademarks belong to their
respective owners. <!-- license.D end -->
<sect2> Credits
@ -118,24 +120,27 @@ answer.
<p> New versions of the Plug-and-Play-HOWTO should appear every few
months or so and will be available to browse and/or download at LDP
mirror sites. For a list of mirror sites see: <url
url="http://linuxdoc.org/mirrors.html">. Various formats are
url="http://tldp.org/mirrors.html">. Various formats are
available. If you only want to quickly check the date of the latest
version look at: <url
url="http://linuxdoc.org/HOWTO/Plug-and-Play-HOWTO.html">. The
version you are now reading is: v1.06, September 2002 .
url="http://tldp.org/HOWTO/Plug-and-Play-HOWTO.html">. The
version you are now reading is: v1.07, August 2003 .
<sect1> New in Recent Versions
<p>
v1.06 September 2002: Revised about telling the BIOS if the OS is PnP
<p> For a full revision history going back to the first version see
the source file (in linuxdoc format) at <url
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Plug-and-Play-HOWTO.sgml.gz">.
v1.07 August 2003: New M$ url, reserve resources for isa-pnp, lspci+,
scanport may not find hdw, finding dev. and config.
v1.06 September 2002: Revised about telling the BIOS if the OS is
PnP<newline>
v1.05 July 2002 typos: or => of, and => an, A Allocate => Allocate,
programs => program; Dell PCs: "Plug and Play Configuration Error",
clarity on telling BIOS if your OS is PnP, "Intro to PnP" had truncated
sentence, routing IRQs on PCI clarified, Change of emphasis in entire
doc: Linux is now a PnP OS (sort of), PCI has almost replaced ISA
v1.04 March 2002 finding a device driver, PCI serial ports,
v1.04 March 2002 finding a device driver, PCI serial ports,
alias example in modules.conf, PnP needed for linmodems
v1.03 August 2001: error messages, boot-prompt parameters
doc: Linux is now a PnP OS (sort of), PCI has almost replaced
ISA<newline>
The version 1.0 (Nov. 2000) was long overdue and recognized that the
kernel is doing more in helping device drivers set up PnP. Kernel 2.4
@ -553,17 +558,17 @@ standard PCI specifications (which are not called "PnP") provide the
equivalent of PnP for the PCI bus.
PnP matches up devices with their device drivers and specifies their
communication channels. On the ISA bus before Plug-and-Play the
bus-resources were formerly set in hardware devices by jumpers.
Software drivers were assigned bus-resources by configuration files
(or the like) or by probing the for the device at addresses where it's
expected to reside. The PCI bus was PnP-like from the beginning but
at first it wasn't called PnP (and often still isn't called PnP).
While the PCI bus specifications don't use the term PnP it supports in
hardware what today is called PnP.
communication channels. On the ISA bus before Plug-and-Play, the
bus-resources were formerly set in hardware devices by jumpers or
switches. Software drivers were assigned bus-resources by
configuration files (or the like) or by probing the for the device at
addresses where it's expected to reside. The PCI bus was PnP-like
from the beginning but at first it wasn't called PnP (and often still
isn't called PnP). While the PCI bus specifications don't use the
term PnP, it supports in hardware what today is called PnP.
<sect1> How It Works (simplified)
<p> Here's an oversimplified view of how PnP should work. The PnP
<p> Here's how PnP should work in theory. The PnP
configuration program finds all PnP devices and asks each what
bus-resources it needs. Then it checks what bus-resources (IRQs,
etc.) it has to give away. Of course, if it has reserved
@ -575,18 +580,30 @@ possible). It then tells each physical device what bus-resources are
assigned to it and the devices set themselves up to use only the
assigned bus-resources. Then the device drivers somehow find out what
bus-resources their devices use and are thus able to communicate
effectively with the devices they control. In Linux all this is done
by the BIOS and/or kernel and/or device drivers in a non-centralized
manner.
effectively with the devices they control.
For example, suppose a card needs one interrupt (IRQ number) and 1 MB
of shared memory. The PnP program reads this request from the card.
It then assigns the card IRQ5 and 1 MB of memory addresses space,
starting at address 0xe9000000. It's not always this simple as the
card (or routing table for PCI) may specify that it can only use
certain IRQ numbers or that the 1 MB of memory must lie within a
certain range of addresses. The details are different for the PCI and
ISA buses with more complexity on the ISA bus.
starting at address 0xe9000000. It then informs the device driver of
what it's done (except the BIOS can't do this). It's not always this
simple as the card (or routing table for PCI) may specify that it can
only use certain IRQ numbers or that the 1 MB of memory must lie
within a certain range of addresses. The details are different for
the PCI and ISA buses with more complexity on the ISA bus.
One way commonly used to allocate resources is to start with one
device and allocate it bus-resources. Then do the same for the next
device, etc. Then if finally all devices get allocated resources
without conflicts, then all is OK. But if allocating a needed
resource would create a conflict, then it's necessary to go back and
try to make some changes in previous allocations so as to obtain the
needed bus-resource. This is called rebalancing. Linux doesn't do
rebalancing but MS Windows does in some cases. For Linux, all this is
done by the BIOS and/or kernel and/or device drivers. In Linux the
device driver doesn't allocate any resources until the driver starts
up, so one way to avoid conflicts is just not to start any device that
might cause a conflict.
There are some shortcuts that PnP software may use. One is to keep
track of how it assigned bus-resources at the last configuration (when the
@ -601,23 +618,23 @@ originally a PnP OS but has been gradually becoming a PnP OS. PnP
originally worked in Linux because a PnP BIOS would configure the
bus-resources and the device drivers would find out (using programs
supplied by the Linux kernel) what the BIOS has done. Today, most
drivers can issue commands to do their own configuring and don't need
to rely on the BIOS. Unfortunately a driver might take a bus-resource
needed by another device). Some device drivers store the last
configuration they used and use it the next time the computer is
powered on.
drivers can issue commands to do their own bus-resource configuring
and don't need to rely on the BIOS. Unfortunately a driver might take
a bus-resource which another device will need later on. Some device
drivers may store the last configuration they used in a configuration
file and use it the next time the computer is powered on.
If the device hardware remembered their previous configuration, then
there wouldn't be any hardware to configure at the next boot-time, but
they seem to forget their configuration when the power is turned off.
Some devices contain a default configuration (but not necessarily the
last one used). Thus a PnP needs to be re-configured each time the PC
is powered on. Also, if a new device has been added, then it too
needs to be configured. Allocating bus-resources to this new device
might involve taking some bus-resources away from an existing device
and assigning the existing device alternative bus-resources that it
can use instead. At present, Linux can't allocate with this
sophistication.
last one used). Thus a PnP device needs to be re-configured each time
the PC is powered on. Also, if a new device has been added, then it
too needs to be configured. Allocating bus-resources to this new
device might involve taking some bus-resources away from an existing
device and assigning the existing device alternative bus-resources
that it can use instead. At present, Linux can't allocate with this
sophistication (and MS Windows XP may not be able to do it either).
<sect1> Starting Up the PC
<p> When the PC is first turned on the BIOS chip runs its program to
@ -637,24 +654,25 @@ into memory from the hard-disk). If you've told the BIOS that you
have a PnP operating system (PnP OS), it should start booting the PC
as above and let the operating system finish the PnP configuring.
Otherwise, a PnP-BIOS will (prior to booting) likely try to do the
rest of the PnP configuring of devices (but not informing their
drivers).
rest of the PnP configuring of devices (but not inform their
drivers of what it did).
<sect1> Buses
<p> ISA is the old bus of the old IBM PCs while PCI is a newer and
faster bus from Intel. The PCI bus was designed for what is today
called PnP. It makes it easy (as compared to the ISA bus) to find out
called PnP. This makes it easy (as compared to the ISA bus) to find out
how PnP bus-resources have been assigned to hardware devices. To see
what has happened use the commands <tt/lspci/ or scanpci (Xwindows)
and/or look at <tt>/proc/pci</tt> or <tt>/proc/bus/pci</tt>. The
boot-up messages on your display are useful (use shift-PageUp to back
up thru them). See <ref id="boot_time_msgs" name="Boot-time
Messages">
what's on the PCI bus type <tt/lspci/. Or type <tt/scanpci/ but it's
not as easy to read. The -v option will show more detail. And/or
look at the "file" <tt>/proc/pci</tt>. The boot-up messages on your
display show devices which have been found on various buses (use
shift-PageUp to back up thru them). See <ref id="boot_time_msgs"
name="Boot-time Messages">
For the ISA bus there was a real problem with implementing PnP since no
one had PnP in mind when the ISA bus was designed and there are almost
no I/O addresses available for PnP to use for sending configuration info
to physical device. As a result, the way PnP was shoehorned onto the
to a physical device. As a result, the way PnP was shoehorned onto the
ISA bus is very complicated. Whole books have been written about it.
See <ref id="pnp_book" name="PnP Book">. Among other things, it
requires that each PnP device be assigned a temporary "handle" by the
@ -662,28 +680,31 @@ PnP program so that one may address it for PnP configuring. Assigning
these "handles" is call "isolation". See <ref id="isolation_"
name="ISA Isolation"> for the complex details.
Eventually, the ISA bus should become extinct. When it does, PnP will
be easier since it will be easy to find out how the BIOS has
configured the hardware. There will still be the need to match up
device drivers with devices and also a need to configure devices that
are added when the PC is up and running.
Eventually, the ISA bus should become extinct. When this happens, PnP
will be a little easier since it will be easier to find out how the
BIOS has configured the hardware. There will still be the need to
match up device drivers with devices and also a need to configure
devices that are added when the PC is up and running.
<sect1> How Linux Does PnP <label id="how_linux_pnps">
<p> Linux has had serious problems dealing with PnP and still has a
problem but it's not as severe as it once was. Linux still is not
really a PnP operating system and seems to mainly rely on and device
drivers and the PnP BIOS to configure bus-resources for devices. But
the kernel provides help for the drivers in the form of PnP programs
they may call on. In many cases, the device driver does all the needed
configuring. In other cases the BIOS may configure and then the device
driver may find out how the BIOS has configured it. The kernel
provides the drivers with some functions (program code) that the
drivers may use to find out if their device exists, how it's been
configured, and functions to modify the configuration. Kernel 2.2
could do this only for the PCI bus but Kernel 2.4 has this feature for
both the ISA and PCI buses (provided that the PNP options have been
selected when compiling the kernel). This by no means guarantees that
all drivers will fully and correctly use these features.
problem but it's not as severe as it once was. It's debatable
whether or not Linux is really a PnP operating system. It seems to
mainly rely on and device drivers and the PnP BIOS to configure
bus-resources for devices.
But the kernel provides help for the drivers in the form of programs
they may call on that do PnP. In many cases, the device driver, with
the help of such programs, does all the needed configuring. In some
cases the BIOS may configure and then the device driver may find out
how the BIOS has configured it. The kernel provides the drivers with
some functions (program code) that the drivers may use to find out if
their device exists, how it's been configured, and functions to modify
the configuration. Kernel 2.2 could do this only for the PCI bus but
Kernel 2.4 has this feature for both the ISA and PCI buses (provided
that the PNP options have been selected when compiling the kernel).
This by no means guarantees that all drivers will fully and correctly
use these features.
In addition, the kernel helps avoid resource conflicts by not allowing
two devices to use the same bus-resources at the same time.
@ -700,16 +721,15 @@ url="http://www.astarte.free-online.co.uk">. But it never was put
into the kernel.
To see what help the kernel may provide to device drivers see the
kernel documentation. This documentation (if you have it) is a
directory /usr/.../.../Documentation where one of the ... contains the
word "kernel". Use the "locate" command to find it. In this
documentation directory see pci.txt ("How to Write Linux PCI Drivers")
and the file: /usr/include/linux/pci.h. Unless you are a driver guru
and know C Programming, these files are written so tersely that they
will not actually teach you how to write a driver. But it will give
you some idea of what PnP type functions are available for drivers to
use. For the ISA bus see isapnp.txt and possibly (for kernel 2.4)
/usr/include/linux/isapnp.h.
word "kernel-doc" or the like. Use the "locate" command to find it.
In this documentation directory see pci.txt ("How to Write Linux PCI
Drivers") and the file: /usr/include/linux/pci.h. Unless you are a
driver guru and know C Programming, these files are written so tersely
that they will not actually teach you how to write a driver. But it
will give you some idea of what PnP type functions are available for
drivers to use. For the ISA bus see isapnp.txt and possibly (for
kernel 2.4) /usr/include/linux/isapnp.h.
When the PC starts up you may note from the messages on the screen
that some Linux device drivers often find their hardware devices (and
@ -896,18 +916,19 @@ reestablish this data.
<sect> How to Deal with PnP Cards
<sect1> Introduction to Dealing with PnP Cards
<p> Today most all new internal boards (cards) are Plug-and-Play
(PnP). There are 5 different methods listed below to cope with PnP
(but some may not be feasible in your situation). If the device
driver configures it, then you don't need to do anything. If the BIOS
configures it, you hope that the driver can find out what the BIOS did
otherwise you may need to tell it this in a configuration file or the
like.
(PnP). The configuring of bus-resources is normally done by the
various device drivers using pnp support provided by modules or built
into the kernel. If this doesn't work, there are 4 other methods
listed below to cope with PnP (but some may not be feasible in your
situation). If the BIOS configures it, you hope that the driver can
find out what the BIOS did, otherwise you may need to tell the driver
this in a configuration file or the like.
<itemize>
<item> <ref id="dev_d_conf" name="Device Driver Configures">
<item> <ref id="bios_conf" name= "BIOS Configures"> (For the PCI bus
you only need a PCI BIOS, otherwise you need a PnP BIOS)
<item> <ref id="disable_pnp" name="ISA only: Disable PnP"> by jumpers or
<item> <ref id="disable_pnp" name="ISA cards only: Disable PnP"> by jumpers or
DOS/Windows software (but many cards can't do this)
<item> <ref id="isapnp_" name="Isapnp"> is a program you can always
use to configure PnP devices on the ISA bus only
@ -923,7 +944,7 @@ informed depends on the driver. You may need to do something to
inform it. See <ref id="tell_driver_config" name="Tell the Driver the
Configuration">
<sect1> Device Driver Configures <label id="dev_d_conf">
<sect1> Device Driver Configures, Reserving Resources <label id="dev_d_conf">
<p> Many device drivers (with the help of code provided by the kernel)
will use PnP methods to set the bus-resources in the hardware but only
for the device that they control. Since the driver has done the
@ -931,15 +952,26 @@ configuring, it obviously knows the configuration and there is no need
for you to tell it this info. This is obviously the easiest way to do
it since you don't have to do anything if the driver does it all.
If you have old pre-pnp ISA hardware, the Linux Pnp software may not
know about it and the bus-resources it requires. So it might
erroneously allocate the resources that this old hardware needs to
some other device. The result is a resource conflict but there's a way
to try to avoid it. You can reserve the resources that the old ISA
card needs by giving arguments to the isa-pnp module or to the kernel
(if the pnp is built into the kernel). For example, to reserve irq 5
give this argument to the isa-pnp module (or to the kernel):
isapnp_reserve_irq=5. See BootPrompt-HOWTO. Instead of ..._irq there
are also _io, _dma, and _mem. Is this clever enough to prevent a PCI
device from using such reserved resources ??
For PCI devices, most drivers will configure PnP but for ISA devices
it's problematical. This is because PCI has always been inherently
PnP even though PnP for PCI was called "PCI Configuration" (and still
is). For ISA, the kernel provided no functions for PnP configuring
until version 2.4. So if you have a late version of both the kernel
and the driver then the driver is more likely to configure PnP
(bus-resources). But if you have older versions (or if the driver
maintainer didn't add PnP support to it) then the driver will likely
not configure PnP.
PnP (called "PCI Configuration"). For ISA, the kernel provided
no functions for PnP configuring until version 2.4. So if you have a
modern version of both the kernel and the driver then the driver is more
likely to configure ISA PnP (bus-resources). But if you have older
versions (or if the driver maintainer failed to add PnP support to it)
then the driver may not configure ISA PnP.
Unfortunately, a driver may grab bus-resources that are needed by other
devices (but not yet allocated to them by the kernel). Thus a true
@ -1069,7 +1101,7 @@ hardware" list: Start --> Programs --> Accessories --> System Tools
--> System Information --> Hardware Resources --> Forced Hardware.
When you "force" a change of bus-resources in Windows, it should put
your change into the ESCD (provided you exit Windows normally).
>From the "System Information" window you may also inspect how IRQs and
From the "System Information" window you may also inspect how IRQs and
IO ports have been allocated under Windows.
Even if Windows shows no conflict of bus-resources, there may be a
@ -1095,7 +1127,7 @@ sure its configuration is "forced" (see the previous section). If
it's "forced" Windows should update the ESCD when you shut down the
PC.
<sect1> ISA only: Disable PnP ? <label id="disable_pnp">
<sect1> ISA cards only: Disable PnP ? <label id="disable_pnp">
<p> PCI devices are inherently PnP so it can't be disabled. But a few
ISA devices had options for disabling PnP by jumpers or by running a
Windows program that comes with the device (jumperless configuration).
@ -1123,11 +1155,13 @@ Dos/Windows configuration software again).
<sect1> Isapnp (part of isapnptools) <label id="isapnp_">
<p> <tt/isapnp/ is only for PnP devices on the ISA bus (non-PCI).
It was much needed prior to the 2.4 kernels. After the 2.4 kernel,
which provided functionality to allow drivers deal with ISA PnP,
isapnp is less significant (although the kernel may have reused some
of the isapnp code).
<p> The <tt/isapnp/ standalone program is only for PnP devices on the
ISA bus (non-PCI). It was much needed prior to the 2.4 kernels.
After the 2.4 kernel, which provided functionality to allow drivers
deal with ISA PnP, the isapnp standalone program is less significant.
But the isa-pnp module (or the equivalent built into the kernel) is now
very significant. This module is called on by various device drivers
to do configure bus-resources.
In some cases Linux distributions have been set up to run isapnp
automatically at startup. If you need to set it up yourself much of
@ -1234,15 +1268,14 @@ be very consistent.
<sect1> PnP Software/Documents <label id="sw_and_docs">
<p>
<itemize>
<p><itemize>
<item><url url="http://www.roestock.demon.co.uk/isapnptools/"
name="Isapnptools homepage">
<item><url url="http://www.astarte.free-online.co.uk" name="Proposal
for a Configuration Manager for Linux"> (Never got into kernel.)
<item> <url url="http://www.io.com/~cdb/mirrors/lpsg/pnp-linux.html"
name="Failed PnP driver project">
<item <url url="http://www.microsoft.com/hwdev/respec/pnpspecs.htm"
<item <url url="http://www.microsoft.com/hwdev/tech/pnp/default.asp"
name="PnP Specs. from Microsoft">
<item> Book: PCI System Architecture, 4th ed. by Tom Shanley +,
MindShare 1999. Covers PnP-like features on the PCI bus.
@ -1282,25 +1315,24 @@ parameters to the kernel via the "boot-prompt". See The
Boot-Prompt-HOWTO which describes some of the bus-resource and other
parameters. Once you know what parameters to give to the kernel, one
may put them into a boot loader configuration file. For example, put
append="...". into the lilo.conf file and then the lilo to get this
info into the kernel loader.
append="...". into the lilo.conf file and then use the lilo command to
get this info into the lilo kernel loader.
If the driver is loaded as a module, in many cases the module will
find the bus-resources it needs and set them in the device. In other
find the bus-resources needed and then set them in the device. In other
cases (mostly for older PCs) you may need to give bus-resources as
parameters to the module. In some versions of Linux
/usr/lib/modules_help/descr.gz shows a list of possible module
parameters. Parameters to a module (including ones that automatically
load) may be specified in /etc/modules.conf. There are usually tools
used to modify this file which are distribution-dependent. Comments
in this file should help regarding how to modify it. Also, any module
your put in /etc/modules will get loaded along with its parameters.
parameters to the module. Parameters to a module (including ones that
automatically load) may be specified in /etc/modules.conf. There are
usually tools used to modify this file which are
distribution-dependent. Comments in this file should help regarding
how to modify it. Also, any module your put in /etc/modules will get
loaded along with its parameters.
While there is great non-uniformity about how drivers find out about
bus-resources, the end goal is the same. If you're having problems
with a driver you may need to look at driver documentation (check the
kernel documentation tree). Some brief examples of a few drivers is
presented in the following sections:
with a driver you may need to look at the driver documentation (check
the kernel documentation tree). Some brief examples of a few drivers
is presented in the following sections:
<sect1> Serial Port Driver Example
<p> For PCI serial ports (and for newer 2.4 kernels for ISA), the
@ -1344,26 +1376,33 @@ ISA-PnP card. You may need to manually intervene to avoid conflicts.
For the ALSA driver, support for ISA-PnP is optional and you may use
isapnp tools if you want to.
<sect> What Is My Current Configuration? <label id="current_config">
<p> Here "configuration" means the assignment of PnP bus-resources
(addresses, IRQs, and DMAs). There are two parts to this question for
each device. Each part should have the same answer.
<enum>
<item> What is the configuration of the device driver software?
I.e.: What does the driver think the hardware configuration is?
<item> What configuration (if any) is set in the device hardware?
</enum>
<sect>How Do I Find Devices and How Are They Configured? <label id="current_config">
Of course the configuration of the device hardware and its driver
should be the same (and it normally is). But if things are not
working right, it could be because there's a difference. This means
the the driver has incorrect information about the actual
configuration of the hardware. This spells trouble. If the software
you use doesn't adequately tell you what's wrong (or automatically
configure it correctly) then you need to investigate how your hardware
devices and their drivers are configured. While Linux device drivers
should "tell all" in some cases it's not easy to determine what has
been set in the hardware.
<sect1>Finding and How-Configured Are Related
<p>Once you find your hardware, the same program that found it usually
tells you how it's configured. So finding out how it's configured is
usually the same procedure as finding the hardware.
<sect1>Devices Have Two "Configurations"
<p> Here "configuration" means the assignment of PnP bus-resources
(addresses, IRQs, and DMAs). For each device, there are two parts to
the configuration question:
<enum>
<item> What does the driver think the hardware configuration is?
<item> What configuration (if any) is actually set in the device hardware?
</enum>
Each part should have the same answer (the same configuration).
The configuration of the device hardware and its driver should be the
same (and usually is). But if things are not working right, it could
be because there's a difference. This means the the driver has
incorrect information about the actual configuration of the hardware.
This spells trouble. If the software you use doesn't adequately tell
you what's wrong (or automatically configure it correctly) then you
need to investigate how your hardware devices and their drivers are
configured. While Linux device drivers should "tell all" in some
cases it may not be easy to determine what has been set in the
hardware.
Another problem is that when you view configuration messages on the
screen, it's sometimes not clear whether the reported configuration is
@ -1377,7 +1416,37 @@ script, by incorrect resource parameters given to a module, or perhaps
just hasn't been told what the resources are and tries to use
incorrect default resources. For example, one can uses "setserial" to
tell the serial port driver an incorrect resource configuration and the
driver accepts it without question.
driver accepts it without question. But the serial port doesn't work
right (if at all).
<sect1>Finding Hardware
<p>A common problem is that the software doesn't detect your device
and/or determine the right driver for it. For PnP devices, detecting
them is easy via PnP software. This means that since the PCI bus is
inherently PnP, there are no hidden devices. Even though PnP devices
are easy to find by PnP methods, if the driver doesn't use PnP methods
but uses the old method of probing for them at likely address, they
may not be found. This is because that until the resources are set in
a PnP device (by the BIOS or Linux), the device may have no address at
all so probing at likely address yields nothing. For the old ISA
bus, some of the devices may be non-PnP and thus the old probing
methods may find them. So many drivers still probe, in addition to
using PnP methods.
Ways to Find Hardware Devices (and their configurations): (follow link
to more details)
<itemize>
<item>Watch the <ref id="boot_time_msgs" name="Boot-time Messages">
on the screen
<item>Look in <ref id="proc_dir" name="The /proc Directory Tree">
<item> PCI: <ref id="pci_" name="PCI Bus Inspection">
<item> ISA Bus: <ref id="isa_bus" name="ISA Bus Introduction">
<item> ISA Bus: <ref id="isa_pnp" name="PnP cards">
<item> ISA Bus: For <ref id="non_pnp" name="Non-PnP Cards">
<item> ISA Bus: For <ref id="jumpers_" name="Cards with jumpers">,
<item> ISA Bus: If <ref id="neither_" name="Neither PnP nor jumpers">,
<item> <ref id="check_ms" name="Use MS Windows">
</itemize>
<sect1> Boot-time Messages <label id="boot_time_msgs">
<p> Some info on configuration may be obtained by reading the messages
@ -1386,11 +1455,11 @@ start the computer. These messages often flash by too fast to read
but once they stop type Shift-PageUp a few times to scroll back to
them. To scroll forward thru them type Shift-PageDown. Typing
"dmesg" at any time to the shell prompt will show only the Linux
kernel messages and miss some of the most important ones (including
kernel messages and may miss some of the most important ones (including
ones from the BIOS). The messages from Linux may sometimes only show
what the device driver thinks the configuration is, perhaps as told it
via an incorrect configuration file. Checking log files in /var/log
may also useful.
may also be useful.
For the PCI bus, the notation: 00:1a:0 means the PCI bus 00 (the main
PCI bus), PCI card (or chip) 1a, and function 0 (the first device) on
@ -1405,72 +1474,118 @@ key. Press any key to resume. But once the messages from Linux start
to appear, it's too late to use "Pause" since it will not freeze the
messages from Linux.
<sect1> How Are My Device Drivers Configured?
<p> There may be a programs you can run from the command line (such as
"setserial" for serial ports) to determine this. The /proc directory
tree is useful. It seems that there are many files buried deep in
this tree that contain bus-resource info. Only a couple of them will
be mentioned here. /proc/ioports shows the I/O addresses that the
Messages from the BIOS at boot-time tell you how the hardware
configuration was then. For the case where only the BIOS does the
configuring, then it should still be the same. Messages from Linux
may be from drivers that used kernel PnP functions to inspect and/or
set bus-resources. These should be correct, but beware of messages
that only show what the driver was told from a configuration file.
It could be wrong. Of course, if the device works fine, then it's
likely configured the same as the driver.
<sect1> The /proc Directory Tree <label id="proc_dir">
<p> The /proc directory tree is useful for finding configuration and
devices. It seems that there are many files buried deep in this tree
that contain bus-resource info. Only a couple of them will be
mentioned here. /proc/ioports shows the I/O addresses that the active
drivers use (or try if it's wrong). They might not be set this way in
hardware.
/proc/interrupts shows only interrupts currently in use. Many
interrupts that have been allocated to drivers don't show at all since
they're not currently being used. For example, even though your
interrupts that have been allocated to drivers don't show here at all
since they're not currently being used. For example, even though your
floppy drive has a floppy disk in it and is ready to use, the
interrupt for it will not show unless its in use. Again, just because
an interrupt shows up here doesn't mean that it exists in the
hardware. A clue that it doesn't exist in hardware will be if it
shows that 0 interrupts have been issued by this interrupt. Even if
it shows some interrupts have been issued there is no guarantee that
it shows a few interrupts have been issued there is no guarantee that
they came from the device shown. It could be that some other device
which is not currently in use has issued them. A device not in use (per
the kernel) may still issue some interrupts for various reasons.
which is not currently in use has issued them. A device not in use
(per the kernel) may still issue some interrupts for various reasons.
<sect1> How Are My Hardware Devices Configured?
<sect1>PCI Bus Inspection <label id="pci_">
<p> It's easy to find out what bus-resources have been assigned to
devices on the PCI bus with the "lspci" or "scanpci" commands. For
for kernels &lt 2.2: see <tt>/proc/pci</tt> or <tt>/proc/bus/pci</tt>
for later kernels. Note that IRQs for <tt>/proc/pci</tt> are in
hexadecimal. Don't bother trying to decipher
<tt>/proc/bus/pci/devices</tt> since "lspci" will do that for you.
devices on the PCI bus with the "lspci" and/or "scanpci" commands or
look at <tt>/proc/pci</tt>. The option -v will show more detail.
<tt>/proc/buspci/devices</tt> shows a cryptic display so you probably
want to avoid it. Note that IRQs for <tt>/proc/pci</tt> are in
hexadecimal.
In most cases for PCI you will only see how the hardware is now
In most cases, for PCI you will only see how the hardware is now
configured and not what resources are required. In some cases you
only see the base addresses (the starting addresses of the range) but
not the ending addresses. If you see the entire range then you can
determine how many bytes of address resource is needed. So in some
cases you could calculate the needed resources and possibly set (with
setpci --hard to use) a different address range (of the same length)
if needed. You only need to tell the device what the new base address
is since it internally has a knowledge of the length.
determine how many bytes of address resources are needed.
For the ISA bus you may try running <tt>pnpdump --dumpregs</tt>
<sect1>ISA Bus Introduction <label id="isa_bus">
<p>For cards on the ISA bus, it's not as simple as for the PCI bus
which is inherently PnP. Newer ISA cards are PnP but older ones are
not. Also, some cards that are PnP have had their PnP disabled by
special software which runs only on MS. The non PnP cards are
configured by jumpers on the card or by MS software.
<sect1>ISA PnP cards <label id="isa_pnp">
<p>If it's a PnP card you may try running <tt>pnpdump --dumpregs</tt>
but it's not a sure thing. The results may be seem cryptic but they
can be deciphered. Don't confuse the read-port address which
<tt/pnpdump/ "tries" (and finds something there) with the I/O address
of the found device. They are not the same. To try to find missing
hardware on the ISA bus (both PnP and legacy) try the program
"scanport" (Debian only ??) but be warned that it might hang your PC.
It will not show the IRQ nor will it positively identify the hardware.
<tt/pnpdump/ uses for communication with PnP cards with the I/O
address of the found device. They are not the same.
Messages from the BIOS at boot-time tell you how the hardware
configuration was then. In case only the BIOS does the configuring,
then it should still be the same. Messages from Linux may be from
drivers that used kernel PnP functions to inspect and/or set
bus-resources. These should be correct, but beware of messages that
only show what is in some configuration file (what the driver thinks).
Of course, if the device works fine, then it's likely configured the
same as the driver.
<sect1>Non-PnP Cards <label id="non_pnp">
<p>In contrast to PnP cards, non-PnP cards always have their resources
set in the hardware. That is they always have an address and IRQ.
Sometimes this can be found by probing done by the device driver or by
other software that does probing. For example "scanport" (Debian only
??) probes most IO port address and may find ISA devices. But be
warned that it might hang your PC. Sometimes it will fail to find
hardware that's actually there (since the hardware has the default
0xff in it's registers). Even if It finds the hardware it will not
show the IRQ nor will it positively identify the hardware.
Some people have attempted to use Windows to see how bus-resources
have been set up. Unfortunately, since the hardware forgets its
So one way to try to find such hardware is to start a driver, which
may probe for such hardware. By looking at the boot-time messages, you
might see a driver start and find the hardware. Otherwise, you may
need to find a driver and start it (for example, by having it load as
a module).
Finding the right driver may be difficult. Sometimes there just isn't
any driver since some devices aren't supported by Linux (yet ?). To
determine which driver you need, look at any documentation which might
identify the card. If this fails, look on the card itself, including
important names/numbers on the chips. But the identification of the
driver module you need may not be anywhere on the card. You could
find the FCC id on the card and then search the Internet with the FCC
id number to try to find more information about the card (or the chips
on it).
<sect1>Non-PnP Cards with jumpers <label id="jumpers_">
<p>If the card has jumpers to set the resources (configuration) then
one may look at how the jumpers are set. There are some cards that had
both PnP and jumpers. They worked like jumper cards if PnP was
somehow disabled. Sometimes a card has labels on it showing how the
jumpers are set (or at least giving some clue). You may need the
documentation that came with the card (either printed or on a floppy
disk). Perhaps you can find it on the Internet.
<sect1>Neither PnP nor jumpers <label id="neither_">
<p>One the most difficult cases is where software running under MS has
been used to configure either a non-PnP card or a PnP card where PnP
has been disabled by the same MS software. So you can't configure it
by PnP nor by jumpers. In this case your only hope is to probe for
addresses as described in <ref id="non_pnp" name="Non-PnP Cards">.
<sect1>Use MS Windows <label id="check_ms">
<p>Some people have attempted to use Windows to see how bus-resources
have been set up. Unfortunately, since PnP hardware forgets its
bus-resource configuration when powered down, the configuration may
not be the same under Linux. It sometimes turns out to be the same
because in many cases both Windows and Linux simply accept what the
BIOS has set. But where Windows and/or Linux do the configuring, they
may do it differently. So don't count on devices being configured the
same.
not be the same under Linux. For non PnP hardware (or where someone
has disabled PnP inside the device by jumpers or Windows software),
then using Windows should work OK. Even for PnP, it often turns
out to be the same because in many cases both Windows and Linux simply
accept what the BIOS has set. But where Windows and/or Linux do the
configuring, they may do it differently. So don't count on PnP
devices being configured the same.
<sect>Error Messages
<sect1> Unexpected Interrupt
@ -1663,18 +1778,23 @@ and explains why IRQ stands for Interrupt ReQuest.
<p> There are two newer developments in PCI interrupts that are not
covered here. They are especially important for cases of more than
one CPU per computer. One is the Advanced Programmable Interrupt
Controller (APIC). Another is Message Signalled Interrupts (MSI)
where the interrupt is just a message sent to a special address over
the main computer bus (no interrupt lines needed). But the device
that sends such a message must first gain control of the main bus so
that it can send the interrupt message. Such a message contains more
info than just "I'm sending an interrupt".
Controller (APIC). See the file "IO-APIC" in the i386 directory of
the kernel documentation. Another new development is Message
Signalled Interrupts (MSI) where the interrupt is just a message sent
to a special address over the main computer bus (no interrupt lines
needed). But the device that sends such a message must first gain
control of the main bus so that it can send the interrupt message.
Such a message contains more info than just "I'm sending an
interrupt".
Ordinary PCI interrupts are different than ISA interrupts, but since
they are normally mapped to IRQs they behave in about the same way.
One major difference is that the BIOS does this mapping. Under Linux
it's not feasible to change it ?? unless the CMOS menu will let you do
it. Another major difference is that PCI interrupts may be shared.
it. But if you have the advanced APIC then there's a way to specify
it.
Another major difference is that PCI interrupts may be shared.
For example IRQ5 may be shared between two PCI devices. This sharing
ability is built into the hardware and all device drivers are supposed
to support it. Note that you can't share the same interrupt between
@ -1685,7 +1805,7 @@ its C programming code.
Here are some of the details of the PCI interrupt system. Each PCI
card (and device mounted on the motherboard) has 4 possible
interrupts: INTA#, INTB#, INTC#, INTD#. From now on we may call them
interrupts: INTA#, INTB#, INTC#, INTD#. From now on we will call them
just A, B, C, and D. Each has its own pin on the edge connector of a
PCI card. Thus for a 7-slot system (for 7 cards) there could be 7 x 4
= 28 different interrupt lines for the cards. But the specs permit a
@ -1698,10 +1818,10 @@ For example, W may be routed to IRQ5. Suppose we designate the B
interrupt from slot 3 as interrupt 3B. Then interrupt 3B could be
permanently connected to W which is routed to IRQ5.
One simple method of hard-wired connecting these lines from PCI
One simple method of connecting (hard-wiring) these lines from PCI
devices (such as 3B) to the interrupts W, etc. would be to connect all
A interrupts (INTA#) to line W, all B's to X, etc. This method was
once used several years ago but it is not a good solution. Here's
once used many years ago but it is not a good solution. Here's
why. If a card only needs one interrupt, it's required that it use A.
If it needs two interrupts, it must use both A and B, etc. Thus INTA#
is used much more often than INTD#. So one winds up with an excessive
@ -1715,7 +1835,7 @@ One method of doing this would be to have wire W share interrupts 1A,
to wires 1A, 2B, etc. Likewise wire X could be connected to wires 1B,
2C, 3D, 4A, 5B, 6C, 7D, etc. Then on startup, the BIOS maps the X, W,
Y, Z to IRQs. After that it writes the IRQ that each device uses into
a hardware configuration register in each device. From then on any
a hardware configuration register in each device. From then on, any
program interrogating this register can find out what IRQ the device
uses. Note that writing the IRQ in a register on a PCI card doesn't
in any way set the IRQ for that device.
@ -1727,9 +1847,9 @@ interrupt. The PCI interrupt letter of a device is often fixed and
hardwired into the device. The assignment of interrupts is done by
the BIOS mapping the PCI interrupts to the ISA interrupts as mentioned
above. If there are only 4 lines (W, X, Y, and Z) as in the above
example, the choices the PCI BIOS has are limited. Some motherboards
may use more lines and thus have more choices. The BIOS knows about
how this is wired.
example, the mapping choices that the PCI BIOS has are limited. Some
motherboards may use more lines and thus have more choices. The BIOS
knows about how this is wired.
On the PCI bus, the BIOS assigns IRQs (interrupts) so as to avoid
conflicts with the IRQs it knows about on the ISA bus. Sometimes
@ -1772,6 +1892,8 @@ and send out simultaneously a sequence of bits to the wire. The
allowed bits are either a 1 (positive voltage) or an "open 0" of no
voltage (open circuit or tri-state). To do this, each PnP device just
starts to sequentially send out its serial number on this wire,
voltage (open circuit or tri-state). To do this, each PnP device just
starts to sequentially send out its serial number on this wire,
bit-by-bit, starting with the high-order bit. If any device sends a
1, a 1 will be heard on the wire by all other devices. If all devices
send an "open 0" nothing will be heard on the wire. The object is to