Today most all new internal boards (cards) are Plug-and-Play (PnP). Some of these have jumpers (or this like) which may be changed to disable PnP. Since software exists in Linux (and Dos/Windows) to handle PnP, it is sometimes best to keep PnP enabled even when you have the option of disabling it. If you patch the kernel for Plug-and-Play it not only configures the hardware by putting resource information into its registers but it also tries to provides this information to the driver software so that you may not need to configure it. For example, for a serial port you may not need to use "setserial".
If you have a PnP card, then your have one or more of the following options for configuring it:
Many devices are PnP only with no option for disabling it. Even when you have the option of doing so, you may not want to disable PnP for the following reasons:
Your BIOS must obviously support PnP to do this. To find out more about your BIOS, look on the Web. Some BIOS may have minimal PnP capabilities and try to turn over the difficult parts of the configuration task to Window utilities (which can't happen under Linux). In this case if the BIOS does maintain a configuration data base, you might try to help set up this data base by using the ICU under DOS/Windows.
First you set up the BIOS for "Not a PnP Operating System" (or the like). See Configuring a PnP BIOS This will make the BIOS do the configuring instead of leaving it to the operating system.
The BIOS's non-volatile data-base is called the ESCD (Extended System Configuration Data). The ESCD not only stores the configuration of PnP devices but stores configuration information of non-PnP devices so as to avoid conflicts. When you install a new non-PnP device you are supposed to tell the BIOS's ESCD about it by running the Dos/Windows ICU (Intel Configuration Utility) program prior to installation. You will also need to run this to tell the ESCD about the existing non-PnP devices on the PC (unless someone else has already done so).
The non-volatile ESCD configuration is usually saved on a chip but sometimes it's put on a hard-drive?? Each time the BIOS starts up under Linux it should configure things this way. You may want to take notes on how ICU (and the BIOS) has configured things (or print them out). However, if you add a new non-PnP device you need to run the ICU program again. If it's PnP then the BIOS will automatically configure it and hopefully not change the configuration on any of the other existing devices on your PC. But it might have to reconfigure some of the existing devices in order to allocate the required resources to the new device. If this happens you'll need to find out what happened (using /proc/pci and of the isapnp "pnpdump" command) and take corrective action.
Note that under Dos/Windows the configuration is also put in a Windows file on the hard disk so the the operating system knows where everything is. This doesn't happen in Linux which auto-detects devices.
This is only for PnP devices on the ISA bus (non-PCI).
Running the Linux program "isapnp" at boot-time will configure such
devices to the resource values you set in /etc/isapnp.conf. You need
the package isapnptools, available in many distributions of
Linux. Type "locate pnp" to see what you may already have available
for isapnp. If your Linux distribution automatically installed
isapnptools, isapnp may already be running at startup. In this case,
all you need to do is to edit /etc/isapnp.conf per "man
isapnp.conf". Note that this is like manually configuring PnP since
you make the decisions as to how to configure as you edit the
configuration file. If you use "isapnp" like this and have a PnP
BIOS, should you tell the BIOS (when you set it up) that you have a
PnP operating system ??
If you only ran isapnp once to configure ISA-PnP devices but failed to run isapnp each time the computer starts up then if you have MS Windows (95 or 98) on the same PC the following problem might occur: When you use MS Windows (95 or 98), Windows may configure your PnP cards differently in such a way that it doesn't work right (if at all) when you go back to use Linux.
A huge patch exists to do this. The resulting kernel is stable and includes documentation: serial.txt to show how to deal with the serial port. It provides "files" in the /proc tree so that you can see what is going on and can echo commands into one of these files for custom configuration. One problem is that many device drivers don't know about it so that you still may have to use the traditional configuration files, etc. for configuration. See http://lucifer.hemmet.s-hem.chalmers.se/~dwh