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.
Here "configuration" means the assignment of PnP bus-resources (addresses, IRQs, and DMAs). For each device, there are two parts to the configuration question:
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 that of the device driver, the device hardware, or both. If the device driver has either set the configuration in the hardware or has otherwise checked the hardware then the driver should have the correct information.
But sometimes the driver has been provided incorrect resources by a 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. But the serial port doesn't work right (if at all).
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)
Some info on configuration may be obtained by reading the messages from the BIOS and from Linux that appear on the screen when you first 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 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 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 the card or chip. The 2nd device on card (or chip) 08 would be: 00:08:1.
The BIOS messages display first and will show the actual hardware configuration at that time, but isapnp, or pci utilities, or device drivers may change it later. As an alternative to eventually using Shift-PageUp to read them, try freezing them by hitting the "Pause" 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.
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 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 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 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.
It's easy to find out what bus-resources have been assigned to
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 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 resources are needed.
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.
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
pnpdump uses for communication with PnP cards with the I/O
address of the found device. They are not the same.
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.
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).
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.
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 Non-PnP Cards.
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. 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.