diff --git a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml index c47b1ca3..76991173 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml @@ -3442,7 +3442,7 @@ nfs server attached by a Null-Modem parallel cable. Plug-and-Play-HOWTO, The Linux Plug-and-Play HOWTO -Updated: September 2002. +Updated: August 2003. How to get your Linux system to support Plug-and-Play. diff --git a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml index 4b8045d1..890caa8f 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml @@ -1464,7 +1464,7 @@ How to install and use PCMCIA Card Services for Linux. Plug-and-Play-HOWTO, The Linux Plug-and-Play HOWTO -Updated: September 2002. +Updated: August 2003. How to get your Linux system to support Plug-and-Play. diff --git a/LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml b/LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml index ac785bc4..b276614e 100644 --- a/LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml +++ b/LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml @@ -3,10 +3,12 @@ Plug-and-Play-HOWTO David S.Lawyer - v1.06, September 2002 + v1.07, August 2003 +

Copyright (c) 1998-2003 by David S. Lawyer + 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: 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. 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. Trademarks. -

Any brand names (starts with a capital letter) should be assumed to -be a trademark). Such trademarks belong to their respective owners. - +

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. Credits @@ -118,24 +120,27 @@ answer.

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: . 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: . 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 . New in Recent Versions -

-v1.06 September 2002: Revised about telling the BIOS if the OS is PnP +

For a full revision history going back to the first version see +the source file (in linuxdoc format) at . + +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", 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 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. How It Works (simplified) -

Here's an oversimplified view of how PnP should work. The PnP +

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). Starting Up the PC

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). Buses

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 /proc/pci or /proc/bus/pci. The -boot-up messages on your display are useful (use shift-PageUp to back -up thru them). See +what's on the PCI bus type /proc/pci. 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 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 . 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 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. How Linux Does PnP

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. How to Deal with PnP Cards Introduction to Dealing with PnP Cards

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. (For the PCI bus you only need a PCI BIOS, otherwise you need a PnP BIOS) - by jumpers or + by jumpers or DOS/Windows software (but many cards can't do this) 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 - Device Driver Configures

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. - ISA only: Disable PnP ?

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). Isapnp (part of isapnptools)

The PnP Software/Documents

- +

(Never got into kernel.) - 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: Serial Port Driver Example

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. - What Is My Current Configuration?

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. - - What is the configuration of the device driver software? - I.e.: What does the driver think the hardware configuration is? - What configuration (if any) is set in the device hardware? - +How Do I Find Devices and How Are They Configured?

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. + +Devices Have Two "Configurations" +

Here "configuration" means the assignment of PnP bus-resources +(addresses, IRQs, and DMAs). For each device, there are two parts to +the configuration question: + + What does the driver think the hardware configuration is? + What configuration (if any) is actually set in the device hardware? + +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). + +Finding Hardware +

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) + +Watch the + on the screen +Look in + PCI: + ISA Bus: + ISA Bus: + ISA Bus: For + ISA Bus: For , + ISA Bus: If , + + Boot-time Messages

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. - How Are My Device Drivers Configured? -

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. + + The /proc Directory Tree

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. - How Are My Hardware Devices Configured? +PCI Bus Inspection

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 < 2.2: see /proc/pci or /proc/bus/pci -for later kernels. Note that IRQs for /proc/pci are in -hexadecimal. Don't bother trying to decipher -/proc/bus/pci/devices since "lspci" will do that for you. +devices on the PCI bus with the "lspci" and/or "scanpci" commands or +look at /proc/pci. The option -v will show more detail. +/proc/buspci/devices shows a cryptic display so you probably +want to avoid it. Note that IRQs for /proc/pci 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 pnpdump --dumpregs +ISA Bus Introduction

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. + +ISA PnP cards

If it's a PnP card you may try running pnpdump --dumpregs 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 -Non-PnP Cards

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). + +Non-PnP Cards with jumpers

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. + +Neither PnP nor jumpers

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 . + +Use MS Windows

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. Error Messages Unexpected Interrupt @@ -1663,18 +1778,23 @@ and explains why IRQ stands for Interrupt ReQuest.

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