updated

LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml

@@ -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>
 

LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml

@@ -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>
 

LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml

@@ -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">
+<p> Copyright (c) 1998-2003 by David S. Lawyer <url url="mailto:dave@lafn.org">
-<!-- license.H begin -->
+<!-- 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
+<p> Any brand names (starts with a capital letter such as MS Windows)
-be a trademark).  Such trademarks belong to their respective owners.
+should be assumed to be a trademark).  Such trademarks belong to their
-<!-- copyright.H end -->
+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
+url="http://tldp.org/HOWTO/Plug-and-Play-HOWTO.html">.  The
-version you are now reading is: v1.06, September 2002 .
+version you are now reading is: v1.07, August 2003 .
 
 <sect1> New in Recent Versions
-<p>
+<p> For a full revision history going back to the first version see
-v1.06 September 2002: Revised about telling the BIOS if the OS is PnP
+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
+doc: Linux is now a PnP OS (sort of), PCI has almost replaced
-v1.04 March 2002 finding a device driver, PCI serial ports, 
+ISA<newline>
-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
 
 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
+communication channels.  On the ISA bus before Plug-and-Play, the
-bus-resources were formerly set in hardware devices by jumpers.
+bus-resources were formerly set in hardware devices by jumpers or
-Software drivers were assigned bus-resources by configuration files
+switches.  Software drivers were assigned bus-resources by
-(or the like) or by probing the for the device at addresses where it's
+configuration files (or the like) or by probing the for the device at
-expected to reside.  The PCI bus was PnP-like from the beginning but
+addresses where it's expected to reside.  The PCI bus was PnP-like
-at first it wasn't called PnP (and often still isn't called PnP).
+from the beginning but at first it wasn't called PnP (and often still
-While the PCI bus specifications don't use the term PnP it supports in
+isn't called PnP).  While the PCI bus specifications don't use the
-hardware what today is called PnP.
+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
+effectively with the devices they control.
-by the BIOS and/or kernel and/or device drivers in a non-centralized
-manner. 
 
 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
+starting at address 0xe9000000.  It then informs the device driver of
-card (or routing table for PCI) may specify that it can only use
+what it's done (except the BIOS can't do this).  It's not always this
-certain IRQ numbers or that the 1 MB of memory must lie within a
+simple as the card (or routing table for PCI) may specify that it can
-certain range of addresses.  The details are different for the PCI and
+only use certain IRQ numbers or that the 1 MB of memory must lie
-ISA buses with more complexity on the ISA bus.
+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
+drivers can issue commands to do their own bus-resource configuring
-to rely on the BIOS.  Unfortunately a driver might take a bus-resource
+and don't need to rely on the BIOS.  Unfortunately a driver might take
-needed by another device).  Some device drivers store the last
+a bus-resource which another device will need later on.  Some device
-configuration they used and use it the next time the computer is
+drivers may store the last configuration they used in a configuration
-powered on.
+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
+last one used).  Thus a PnP device needs to be re-configured each time
-is powered on.  Also, if a new device has been added, then it too
+the PC is powered on.  Also, if a new device has been added, then it
-needs to be configured.  Allocating bus-resources to this new device
+too needs to be configured.  Allocating bus-resources to this new
-might involve taking some bus-resources away from an existing device
+device might involve taking some bus-resources away from an existing
-and assigning the existing device alternative bus-resources that it
+device and assigning the existing device alternative bus-resources
-can use instead.  At present, Linux can't allocate with this
+that it can use instead.  At present, Linux can't allocate with this
-sophistication.
+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
+rest of the PnP configuring of devices (but not inform their
-drivers).
+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)
+what's on the PCI bus type <tt/lspci/.  Or type <tt/scanpci/ but it's
-and/or look at <tt>/proc/pci</tt> or <tt>/proc/bus/pci</tt>.  The
+not as easy to read.  The -v option will show more detail.  And/or
-boot-up messages on your display are useful (use shift-PageUp to back
+look at the "file" <tt>/proc/pci</tt>.  The boot-up messages on your
-up thru them).  See <ref id="boot_time_msgs" name="Boot-time
+display show devices which have been found on various buses (use
-Messages">
+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
+Eventually, the ISA bus should become extinct.  When this happens, PnP
-be easier since it will be easy to find out how the BIOS has
+will be a little easier since it will be easier to find out how the
-configured the hardware.  There will still be the need to match up
+BIOS has configured the hardware.  There will still be the need to
-device drivers with devices and also a need to configure devices that
+match up device drivers with devices and also a need to configure
-are added when the PC is up and running. 
+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
+problem but it's not as severe as it once was.  It's debatable
-really a PnP operating system and seems to mainly rely on and device
+whether or not Linux is really a PnP operating system.  It seems to
-drivers and the PnP BIOS to configure bus-resources for devices.  But
+mainly rely on and device drivers and the PnP BIOS to configure
-the kernel provides help for the drivers in the form of PnP programs
+bus-resources for devices.
-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
+But the kernel provides help for the drivers in the form of programs
-driver may find out how the BIOS has configured it.  The kernel
+they may call on that do PnP.  In many cases, the device driver, with
-provides the drivers with some functions (program code) that the
+the help of such programs, does all the needed configuring.  In some
-drivers may use to find out if their device exists, how it's been
+cases the BIOS may configure and then the device driver may find out
-configured, and functions to modify the configuration.  Kernel 2.2
+how the BIOS has configured it.  The kernel provides the drivers with
-could do this only for the PCI bus but Kernel 2.4 has this feature for
+some functions (program code) that the drivers may use to find out if
-both the ISA and PCI buses (provided that the PNP options have been
+their device exists, how it's been configured, and functions to modify
-selected when compiling the kernel).  This by no means guarantees that
+the configuration.  Kernel 2.2 could do this only for the PCI bus but
-all drivers will fully and correctly use these features.
+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
+word "kernel-doc" or the like.  Use the "locate" command to find it.
-documentation directory see pci.txt ("How to Write Linux PCI Drivers")
+In this documentation directory see pci.txt ("How to Write Linux PCI
-and the file: /usr/include/linux/pci.h.  Unless you are a driver guru
+Drivers") and the file: /usr/include/linux/pci.h.  Unless you are a
-and know C Programming, these files are written so tersely that they
+driver guru and know C Programming, these files are written so tersely
-will not actually teach you how to write a driver.  But it will give
+that they will not actually teach you how to write a driver.  But it
-you some idea of what PnP type functions are available for drivers to
+will give you some idea of what PnP type functions are available for
-use.  For the ISA bus see isapnp.txt and possibly (for kernel 2.4)
+drivers to use.  For the ISA bus see isapnp.txt and possibly (for
-/usr/include/linux/isapnp.h.
+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
+(PnP).  The configuring of bus-resources is normally done by the
-(but some may not be feasible in your situation).  If the device
+various device drivers using pnp support provided by modules or built
-driver configures it, then you don't need to do anything.  If the BIOS
+into the kernel.  If this doesn't work, there are 4 other methods
-configures it, you hope that the driver can find out what the BIOS did
+listed below to cope with PnP (but some may not be feasible in your
-otherwise you may need to tell it this in a configuration file or the
+situation).  If the BIOS configures it, you hope that the driver can
-like.
+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
+PnP (called "PCI Configuration").  For ISA, the kernel provided
-is).  For ISA, the kernel provided no functions for PnP configuring
+no functions for PnP configuring until version 2.4.  So if you have a
-until version 2.4.  So if you have a late version of both the kernel
+modern version of both the kernel and the driver then the driver is more
-and the driver then the driver is more likely to configure PnP
+likely to configure ISA PnP (bus-resources).  But if you have older
-(bus-resources).  But if you have older versions (or if the driver
+versions (or if the driver maintainer failed to add PnP support to it)
-maintainer didn't add PnP support to it) then the driver will likely
+then the driver may not configure ISA PnP.
-not configure 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).
+<p> The <tt/isapnp/ standalone program is only for PnP devices on the
-It was much needed prior to the 2.4 kernels.  After the 2.4 kernel,
+ISA bus (non-PCI).  It was much needed prior to the 2.4 kernels.
-which provided functionality to allow drivers deal with ISA PnP,
+After the 2.4 kernel, which provided functionality to allow drivers
-isapnp is less significant (although the kernel may have reused some
+deal with ISA PnP, the isapnp standalone program is less significant.
-of the isapnp code).
+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>
+<p><itemize>
-<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
+append="...". into the lilo.conf file and then use the lilo command to
-info into the kernel loader.
+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
+parameters to the module.  Parameters to a module (including ones that
-/usr/lib/modules_help/descr.gz shows a list of possible module
+automatically load) may be specified in /etc/modules.conf.  There are
-parameters.  Parameters to a module (including ones that automatically
+usually tools used to modify this file which are
-load) may be specified in /etc/modules.conf.  There are usually tools
+distribution-dependent.  Comments in this file should help regarding
-used to modify this file which are distribution-dependent.  Comments
+how to modify it.  Also, any module your put in /etc/modules will get
-in this file should help regarding how to modify it.  Also, any module
+loaded along with its parameters.
-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
+with a driver you may need to look at the driver documentation (check
-kernel documentation tree).  Some brief examples of a few drivers is
+the kernel documentation tree).  Some brief examples of a few drivers
-presented in the following sections:
+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">
+<sect>How Do I Find Devices and How Are They Configured? <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>
 
-Of course the configuration of the device hardware and its driver
+<sect1>Finding and How-Configured Are Related
-should be the same (and it normally is).  But if things are not
+<p>Once you find your hardware, the same program that found it usually
-working right, it could be because there's a difference.  This means
+tells you how it's configured.  So finding out how it's configured is
-the the driver has incorrect information about the actual
+usually the same procedure as finding the hardware.
-configuration of the hardware.  This spells trouble.  If the software
+
-you use doesn't adequately tell you what's wrong (or automatically
+<sect1>Devices Have Two "Configurations"
-configure it correctly) then you need to investigate how your hardware
+<p> Here "configuration" means the assignment of PnP bus-resources
-devices and their drivers are configured.  While Linux device drivers
+(addresses, IRQs, and DMAs).  For each device, there are two parts to
-should "tell all" in some cases it's not easy to determine what has
+the configuration question:
-been set in the hardware.
+<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?
+Messages from the BIOS at boot-time tell you how the hardware
-<p> There may be a programs you can run from the command line (such as
+configuration was then.  For the case where only the BIOS does the
-"setserial" for serial ports) to determine this.   The /proc directory
+configuring, then it should still be the same.  Messages from Linux
-tree is useful.  It seems that there are many files buried deep in
+may be from drivers that used kernel PnP functions to inspect and/or
-this tree that contain bus-resource info.  Only a couple of them will
+set bus-resources.  These should be correct, but beware of messages
-be mentioned here.  /proc/ioports shows the I/O addresses that the
+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
+interrupts that have been allocated to drivers don't show here at all
-they're not currently being used.  For example, even though your
+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
+which is not currently in use has issued them.  A device not in use
-the kernel) may still issue some interrupts for various reasons.
+(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
+devices on the PCI bus with the "lspci" and/or "scanpci" commands or
-for kernels &lt 2.2: see <tt>/proc/pci</tt> or <tt>/proc/bus/pci</tt>
+look at <tt>/proc/pci</tt>.  The option -v will show more detail.
-for later kernels.  Note that IRQs for <tt>/proc/pci</tt> are in
+<tt>/proc/buspci/devices</tt> shows a cryptic display so you probably
-hexadecimal.  Don't bother trying to decipher
+want to avoid it.  Note that IRQs for <tt>/proc/pci</tt> are in
-<tt>/proc/bus/pci/devices</tt> since "lspci" will do that for you.
+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
+determine how many bytes of address resources are needed. 
-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.
 
-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
+<tt/pnpdump/ uses for communication with PnP cards  with the I/O
-of the found device.  They are not the same.  To try to find missing
+address of the found device.  They are not the same.  
-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.
 
-Messages from the BIOS at boot-time tell you how the hardware
+<sect1>Non-PnP Cards <label id="non_pnp">
-configuration was then.  In case only the BIOS does the configuring,
+<p>In contrast to PnP cards, non-PnP cards always have their resources
-then it should still be the same.  Messages from Linux may be from
+set in the hardware.  That is they always have an address and IRQ.
-drivers that used kernel PnP functions to inspect and/or set
+Sometimes this can be found by probing done by the device driver or by
-bus-resources.  These should be correct, but beware of messages that
+other software that does probing.  For example "scanport" (Debian only
-only show what is in some configuration file (what the driver thinks).
+??) probes most IO port address and may find ISA devices.  But be
-Of course, if the device works fine, then it's likely configured the
+warned that it might hang your PC.  Sometimes it will fail to find
-same as the driver.
+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
+So one way to try to find such hardware is to start a driver, which
-have been set up.  Unfortunately, since the hardware forgets its
+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
+not be the same under Linux.  For non PnP hardware (or where someone
-because in many cases both Windows and Linux simply accept what the
+has disabled PnP inside the device by jumpers or Windows software),
-BIOS has set.  But where Windows and/or Linux do the configuring, they
+then using Windows should work OK.  Even for PnP, it often turns
-may do it differently.  So don't count on devices being configured the
+out to be the same because in many cases both Windows and Linux simply
-same.
+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)
+Controller (APIC).  See the file "IO-APIC" in the i386 directory of
-where the interrupt is just a message sent to a special address over
+the kernel documentation.  Another new development is Message
-the main computer bus (no interrupt lines needed).  But the device
+Signalled Interrupts (MSI) where the interrupt is just a message sent
-that sends such a message must first gain control of the main bus so
+to a special address over the main computer bus (no interrupt lines
-that it can send the interrupt message.  Such a message contains more
+needed).  But the device that sends such a message must first gain
-info than just "I'm sending an interrupt".
+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
+example, the mapping choices that the PCI BIOS has are limited.  Some
-may use more lines and thus have more choices.  The BIOS knows about
+motherboards may use more lines and thus have more choices.  The BIOS
-how this is wired.
+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