Here "configuration" means the assignment of PnP resources (addresses, IRQs, and DMAs). There are two parts to this question for each device. Each part should have the same answer.
Of course the configuration of the device hardware and its driver should be the same (and it normally is). But if things are not working right, there may be a difference. This means the the driver has incorrect information about the actually configuration of the hardware. This spells trouble. If the software you use doesn't adequately tell you what's wrong (or automatically configure it correctly) then you need to investigate how your hardware devices and their drivers are configured. While Linux device drivers should "tell all" in some cases it's not easy to determine what has been set in the hardware.
Another problem is that when you view configuration messages on the screen, it's sometimes not clear whether the reported configuration is that of the device driver, the device hardware, or both. If the device driver is assigned a configuration and then checks the hardware out to see if it's configured the same, then the configuration reported by the driver should be that of both the hardware and the driver.
This is not always true, since the driver may accept a configuration that doesn't check out. For example, "setserial" will accept a configuration that doesn't check out (even if you've told it to probe for resources). Thus "setserial" may only be telling you the configuration of the driver and not the hardware.
Some info on configuration may be obtained from the messages from the BIOSs and Linux that appear on the screen when you first start the computer. After all the messages have flashed by, type shift-PageUp to scroll back to them. Typing "dmesg" at any time to the shell prompt will show only the Linux messages and miss the 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. The BIOS messages will show the hardware configuration at that time, but a PnP OS, isapnp, or pci utilities, may have changed it since then.
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. /proc/ioports shows the I/O addresses that the 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 and many that have been allocated to drivers don't show 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, it may mean that this interrupt doesn't exist on the device shown next to it, but does exist on some other device which is not in use, but which somehow has issued an interrupt or two. As of kernel 2.2 the /proc tree has changed.
/proc/pci
or/proc/bus/pci/devices
(in kernel 2.2+). For the ISA bus youmay try running pnpdump --dumpregs
but it's not a sure thing.The results may be difficult to decipher. Don't confuse the read-portaddress which pnpdump
"trys" (and finds something there) with theI/O address of the found device. They are not the same.Messages from the BIOS at boot-time tell you how the hardwareconfiguration was then. If you rely on the BIOS for configuring, thenit should still be the same. Messages from Linux may be from driversthat have checked to see that the hardware is there (and possiblychecked the IRQ and DMA). Of course, if the device works fine, thenit's likely configured the same as the driver.