When the computer is first turned on, the BIOS program runs before the operating system is loaded. Modern BIOSs are PnP and can configure most of the PnP devices. Some old PCI BIOSs will only configure the PCI bus. Here are some of the choices which may exist in your BIOS's CMOS menu:
Regardless of how you answer this to the BIOS, the PnP BIOS will PnP-configure the hard-drive, floppy, video card, and keyboard to make the system bootable as well as configure the LPC bus (if you have one). If you said no PnP OS then the BIOS should configure everything.
How should you answer this question to your BIOS? If you have at at least the 2.4 kernel you could answer it either way and Linux will usually work fine. Even if you have Windows 2000 or XP on the same PC, it will usually work OK either way. This is because both Windows and Linux are supposedly PnP OS's and if the OS is PnP it should be able to also handle the case where the BIOS has configured everything (if you said it wasn't PnP). But I still suggest saying that it's not a PnP OS unless there is a known reason to say otherwise.
It's not often clear whether to say yes or no. If isapnp was used by Linux, then Linux does the configuring and it was claimed that it's best to say it's a PnP OS. Why isapnp would have trouble when presented with devices already configured by the BIOS isn't clear, but such trouble sometimes happened and was fixed by stopping the BIOS from configuring (saying yes, it's a PnP OS). There were a few cases where saying no fixed a problem. So if isapnp is doing it's job OK, you should probably say it's PnP. If isapnp isn't used, no is usually best. The Linux device drivers for PCI devices should configure PCI devices OK. But for the case of PCI devices driven by non-PCI drivers, then you may say it's not PnP to get the BIOS to configure them.
If you also run these Windows OS's on the same PC, you should say that you don't have a PnP OS. That's what MS suggests you do. Perhaps MS hopes that the BIOS will do a better job at configuring than Windows will. That makes sense because the BIOS should be designed for the particular idiosyncrasies of the motherboard, especially today when many devices are built into the motherboard. PnP OS = no should also be OK for Linux kernels 2.4 and higher. But for Linux kernel prior to 2.4, it's not clear which is best. (see the above subsection). So if you have problems with Linux you might try saying you have a PnP OS to satisfy Linux but this is going against what MS suggest (but will probably work OK anyway).
When the BIOS configures a device different from what Windows has in it's registry, Windows will tell you that it's finding new hardware. What it's really doing is finding old hardware that has been configured differently so it thinks it's new hardware. At any rate, it records the configuration that the BIOS has used in its registry and the device should work OK from now on.
For Windows9x, MS suggest that you tell the BIOS that you have a PnP OS (the exact opposite of the case for Windows 2000 and XP). This should also be OK for Linux if you have kernel 2.4 or later. But if you have a Linux kernel prior to 2.4 then it's best for Linux to say that it's not a PnP OS. One way to resolve this dilemma is to set it up for the OS you use more frequently. Then when you boot the other OS, manually go into the BIOS and change the setting. This is a lot of bother but it's feasible if you almost never use one of the OS's. Otherwise there are better ways to resolved this dilemma.
The second way to resolve this dilemma is to get Linux to resource-configure everything. See Linux prior to the 2.4 kernel. Then you tell the BIOS it's a PnP OS.
The third way to resolve this dilemma is to tell the BIOS it's not a PnP OS. This is going against what MS says you should do, but it's possible to get MS Windows9x to work OK if you understand what to do (and why). If you tell the BIOS it's not a PnP OS, shouldn't MS Windows detect how the BIOS has configured things and change it if it doesn't like what the BIOS has done? It should, but unfortunately, it doesn't seem to work this way.
What Windows9x seems to do when it finds hardware that is already configured by the BIOS is to just leave it alone and not reconfigure it. Now Windows9x keeps a record of the bus-resource configuration in its registry. If the BIOS configuration is different, it should either correct what's in its registry to conform to what the BIOS has set or reconfigure everything per what's in the registry. Bad news. It seems to do neither and thinks the actual configuration is the same as in the registry when in fact it's different.
But if the registry happens to contain a bus-resource configuration that is exactly the same as how the BIOS configures things, then everything will obviously work OK. A device will thus work fine if the BIOS has configured it the same as recorded in the registry. So the way to get MS Windows to work OK is to get the registry in sync with how the BIOS configures. As mentioned previously, the BIOS configures things per its ESCD (which is something like the registry for the BIOS). See The BIOS's ESCD Database. So we need to get the registry in sync with the BIOS's ESCD so that the registry and the ESCD contain the same configuration. In some cases, these two just happen to be in sync and you don't need to do anything.
One question you may think of is: how did the BIOS's ESCD and Windows registry ever get out of sync in the first place? Here's one scenario. You install Windows with the BIOS set to a PnP OS. Then Windows configures most everything and saves that configuration in its registry. Then later on you change the BIOS setting to not a PnP OS. Then upon booting, the BIOS configures everything and it doesn't do it exactly like Windows did it. Thus the actual configuration of the hardware and what Windows has in its registry are now different.
One way to try to get the Registry and the ESCD the same is to install (or reinstall) Windows when the BIOS is set for "not a PnP OS". This should present Windows with hardware configured by the BIOS. If this configuration is without conflicts, Windows will hopefully leave it alone and save it in it's Registry. Then the ESCD and the registry are in sync.
Another method is to remove devices that are causing problems in Windows by clicking on "remove" in the Device Manager. Then reboot with "Not a PnP OS" (set it in the BIOS's CMOS as you start to boot). Windows will then reinstall the devices, hopefully using the bus-resource settings as configured by the BIOS. Be warned that Windows will likely ask you to insert the Window installation CD since it sometimes can't find the driver files (and the like) even though they are still there. A workaround for this is to select "skip file" which will avoid installing the file from a CD. If the file is still on the HD, then the driver will hopefully find it OK even though the Window's install program requested you install it from a CD (which you skipped doing).
As a test I "removed" a NIC card which used a Novell compatible driver. Upon rebooting, Windows reinstalled it with Microsoft Networking instead of Novell. This meant that the Novell Client needed to be reinstalled --a lot of unnecessary work. So in a case like this it may be better to not fib to Windows95/98 but instead to get Linux to configure bus-resources.
When using a Window-Linux PC (dual boot) you might notice a change in the way the BIOS configures due to Windows9x (and other versions of Windows ??) modifying the ESCD. It supposedly does this only if you "force" a configuration or install a legacy device. See Using Windows to set ESCD. Device drivers that do configuring may modify what the BIOS has done as will the isapnp or PCI Utilities programs if you run them.
Modern BIOSs allow you to manually allocate resources, primarily IRQs. There is usually an option to set the an allocation to "auto" so that the BIOS decides how to allocate the resource. "Auto" is often a good choice unless you have old legacy non-pnp ISA cards.
If you have such non-PnP cards, then it may be important to reserve resources (such as IRQ's) for these in the BIOS. Otherwise the BIOS may use these resources for some other device and create conflicts. An exception is that for some common legacy devices (such as parallel and serial ports, disk drives), the BIOS may find them (look at the screen at boot-time) so you don't need to reserve resources for them. If you've used Windows on your PC, it might be true that Windows has already told the BIOS about them by running the ICU utility (or the like) under Windows.
For PCI, the BIOS may let you assign IRQs to card slots 1, 2, 3, 4, etc. If you do this, you should know what card is in what slot. Actually, each slot has 4 PCI IRQs: A, B, C, and D. If the BIOS menu doesn't say which of these (A, B, C, D) is being assigned to an IRQ number, it's likely that it's only assigning the IRQ number to PCI IRQ A. But many PCI cards only use IRQ A so it's then just like assigning an IRQ to a slot. See PCI Interrupts
This is a little risky to do. It will erase the BIOSs ESCD data-base of how your PnP devices should be configured as well as the list of how legacy (non-PnP) devices are configured. Never do this unless you are convinced that this data-base is wrong and needs to be remade. It was stated somewhere that you should do this only if you can't get your computer to boot. If the BIOS loses the data on legacy ISA devices, then you'll need to run ICA again under DOS/Windows to reestablish this data.