I/O Port Hex Addresses

[prolific96]

Name VIA VT6421 RAID Controller
Manufacturer VIA Technologies, Inc.
Status OK
PNP Device ID PCI\VEN_1106&DEV_3249&SUBSYS_32491106&REV_50\4&3B1D9AB8&0&5040
I/O Port 0x00009000-0x0000BFFF
I/O Port 0x00009400-0x0000940F
I/O Port 0x00009800-0x0000980F
I/O Port 0x00009C00-0x00009C0F
I/O Port 0x0000A000-0x0000A01F
I/O Port 0x0000A400-0x0000A4FF
IRQ Channel IRQ 18

That is a reading of my SATA card from msinfo32.exe ..

How are the I/O Port Hex addresses determined ? Are they a physical property of the PCI card, so that if this card was put into a different computer msinfo32 would show the same I/O port addresses ?

 

[Peter]

PCI devices are getting their resources mapped by the PCI plug&play procedure, no static resources at all. So the answer to your question absolutely is No. Even as you add/remove/enable/disable other stuff in your current system, you'll find that sometimes doing so changes other devices' resource mapping.

 

[jlbenedict]

Originally posted by: Peter
PCI devices are getting their resources mapped by the PCI plug&play procedure, no static resources at all. So the answer to your question absolutely is No. Even as you add/remove/enable/disable other stuff in your current system, you'll find that sometimes doing so changes other devices' resource mapping.

Yep.. you can thank ACPI for this (along with Windows XP).
I remember how on a Windows 98 machine, you could manually change the I/O address range for a device. This worked well, if you didn't want that devices I/O resources to be assigned to multiple devices, which sometimes happend under Winows 98. Windows XP has no issues with I/O or IRQ sharing.

 

[Peter]

Nope, neither ACPI nor XP. The PCI init is done by BIOS, during POST - and it's always been that way ever since PCI first appeared.

Also, there has never been such a thing as "IRQ conflicts" amongst PCI devices; IRQ sharing capability is and has always been mandatory for PCI devices (and their AGP, PCIE, PCIX and chipset-integrated siblings). What's being perceived as "sharing conflicts" is always, 100%, driver bugs.

I/O address ranges must be uniquely assigned though, and BIOS bugs in /that/ area are rarely seen these days.