As part of developing Windows XP drivers for an IO Hub, we are stuck with an issue which happens only when a particular PCI-e graphics adapter is present on the system (Matrox G550). Three of our drivers, one gigabit Ethernet and two custom class drivers do not load and device manger displays error code 12.
I went through a previous thread related to the same error code and did some analysis by using the !arbiter debug extension. It seems that there is a conflict happening on the IO ranges. We confirmed this with the two custom class drivers by filtering out the IO range in IRP_MN_FILTER_RESOURCE_REQUIREMENTS IRP. We were able to load those two drivers successfully in that case. But we don?t have a workaround in hand for the NDIS 5.1 miniport driver
Going through the !arbiter log for the IO arbiters, we see ranges that conflict with our devices being claimed by a PCI to PCI bridge that is present on the PCI-e graphics card. Please find excerpts from !arbiter below
DEVNODE 865caee8 (PCI\VEN_8086&DEV_8185&SUBSYS_00000000&REV_00\3&11583659&0&C0)
Port Arbiter “PCI I/O Port (b=03)” at e1439ca4
Allocated ranges:
0000000000000000 - 00000000000003af 00000000 00000000000003b0 - 00000000000003bb P 86590e50 (pci) 00000000000003bc - 00000000000003bf 00000000 00000000000003c0 - 00000000000003df P 86590e50 (pci) 00000000000003e0 - 00000000000007af 00000000 000000000000e7e0 - 000000000000ebaf 00000000 … … The first and third ranges below conflicts with the our device?s IO range. 000000000000ebb0 - 000000000000ebbb P 86590e50 (pci) 000000000000ebbc - 000000000000ebbf 00000000 000000000000ebc0 - 000000000000ebdf P 86590e50 (pci) 000000000000ebe0 - 000000000000efaf 00000000 000000000000ffc0 - 000000000000ffdf P 86590e50 (pci) … … 000000000000ffe0 - ffffffffffffffff 00000000 Possible allocation: < none >
DEVNODE 86590bb0 (PCI\VEN_104C&DEV_8231&SUBSYS_00000000&REV_03\4&2739770a&0&00C0) Port Arbiter “PCI I/O Port (b=04)” at e1003a0c Allocated ranges: 0000000000000000 - 00000000000003af 00000000 00000000000003b0 - 00000000000003bb S P 86590830 (G400DH) 00000000000003bc - 00000000000003bf 00000000 00000000000003c0 - 00000000000003df S P 86590830 (G400DH) 00000000000003e0 - 00000000000007af 00000000 … … 000000000000ffbc - 000000000000ffbf 00000000 000000000000ffe0 - ffffffffffffffff 00000000 Possible allocation: < none >
Device node 86590bb0 is the only node present under the bridge. The !pci and !devnode for the device only shows two IO ranges that are actually requested by the device. Please find the details below.
0: kd> !devnode 0x86590bb0 6 DevNode 0x86590bb0 for PDO 0x86590e50 Parent 0x865caee8 Sibling 0000000000 Child 0x86590590 InterfaceType 0x5 Bus Number 0x4 InstancePath is “PCI\VEN_104C&DEV_8231&SUBSYS_00000000&REV_03\4&2739770a&0&00C0” ServiceName is “pci” State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) StateHistory[07] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[06] = DeviceNodeStarted (0x308) StateHistory[05] = DeviceNodeStartPostWork (0x307) StateHistory[04] = DeviceNodeStartCompletion (0x306) StateHistory[03] = DeviceNodeResourcesAssigned (0x304) StateHistory[02] = DeviceNodeDriversAdded (0x303) StateHistory[01] = DeviceNodeInitialized (0x302) StateHistory[00] = DeviceNodeUninitialized (0x301) … … StateHistory[08] = Unknown State (0x0) Flags (0x000000f0) DNF_ENUMERATED, DNF_IDS_QUERIED, DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED UserFlags (0x00000008) DNUF_NOT_DISABLEABLE CapabilityFlags (0x00000003) DeviceD1, DeviceD2 DisableableDepends = 1 (including self) CmResourceList at 0xe100f228 Version 0.0 Interface 0x5 Bus #0x3 … … Entry 6 - Port (0x1) Undetermined Sharing (0) Flags (0x24) - PORT_MEMORY 10_BIT_DECODE POSITIVE_DECODE Range starts at 0x3b0 for 0xc bytes Entry 7 - Port (0x1) Undetermined Sharing (0) Flags (0x24) - PORT_MEMORY 10_BIT_DECODE POSITIVE_DECODE Range starts at 0x3c0 for 0x20 bytes
We are confused why PCI driver is claiming such a large number of IO ranges in this particular case. Any clues/hints on how to resolve this would be of great help. I am not an expert on PCI, so please correct me in case my understanding is wrong.
Sorry for the long mail, couldn?t find an alternate way to send the logs
The PCI driver claims the superset of what all possible VGA devices below
the bridge might need. At the point when it sets up the bridges, it doesn’t
know what, specifically, the Matrox driver will need.
If you work through all the rules in the PCI specs, and all their
implications, you’ll probably see that this is necessary.
In any case, you’ve already answered your own question. Your device isn’t
going to work with this graphics adapter and this BIOS. There’s not much
you’ll be able to do about that.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev… > Hello experts, > > As part of developing Windows XP drivers for an IO Hub, we are stuck with > an issue which happens only when a particular PCI-e graphics adapter is > present on the system (Matrox G550). Three of our drivers, one gigabit > Ethernet and two custom class drivers do not load and device manger > displays error code 12. > > I went through a previous thread related to the same error code and did > some analysis by using the !arbiter debug extension. It seems that there > is a conflict happening on the IO ranges. We confirmed this with the two > custom class drivers by filtering out the IO range in > IRP_MN_FILTER_RESOURCE_REQUIREMENTS IRP. We were able to load those two > drivers successfully in that case. But we don?t have a workaround in hand > for the NDIS 5.1 miniport driver > > Going through the !arbiter log for the IO arbiters, we see ranges that > conflict with our devices being claimed by a PCI to PCI bridge that is > present on the PCI-e graphics card. Please find excerpts from !arbiter > below > > DEVNODE 865caee8 > (PCI\VEN_8086&DEV_8185&SUBSYS_00000000&REV_00\3&11583659&0&C0) > Port Arbiter “PCI I/O Port (b=03)” at e1439ca4 > Allocated ranges: > 0000000000000000 - 00000000000003af 00000000 > bus> > 00000000000003b0 - 00000000000003bb P 86590e50 (pci) > 00000000000003bc - 00000000000003bf 00000000 > bus> > 00000000000003c0 - 00000000000003df P 86590e50 (pci) > 00000000000003e0 - 00000000000007af 00000000 > bus> > 000000000000e7e0 - 000000000000ebaf 00000000 > bus> > … > … > The first and third ranges below conflicts with the our device?s IO range. > 000000000000ebb0 - 000000000000ebbb P 86590e50 (pci) > 000000000000ebbc - 000000000000ebbf 00000000 > bus> > 000000000000ebc0 - 000000000000ebdf P 86590e50 (pci) > 000000000000ebe0 - 000000000000efaf 00000000 > bus> > 000000000000ffc0 - 000000000000ffdf P 86590e50 (pci) > … > … > 000000000000ffe0 - ffffffffffffffff 00000000 > bus> > Possible allocation: > < none > > > DEVNODE 86590bb0 > (PCI\VEN_104C&DEV_8231&SUBSYS_00000000&REV_03\4&2739770a&0&00C0) > Port Arbiter “PCI I/O Port (b=04)” at e1003a0c > Allocated ranges: > 0000000000000000 - 00000000000003af 00000000 > bus> > 00000000000003b0 - 00000000000003bb S P 86590830 > (G400DH) > 00000000000003bc - 00000000000003bf 00000000 > bus> > 00000000000003c0 - 00000000000003df S P 86590830 > (G400DH) > 00000000000003e0 - 00000000000007af 00000000 > bus> > … > … > 000000000000ffbc - 000000000000ffbf 00000000 > bus> > 000000000000ffe0 - ffffffffffffffff 00000000 > bus> > Possible allocation: > < none > > > Device node 86590bb0 is the only node present under the bridge. The !pci > and !devnode for the device only shows two IO ranges that are actually > requested by the device. Please find the details below. > > 0: kd> !devnode 0x86590bb0 6 > DevNode 0x86590bb0 for PDO 0x86590e50 > Parent 0x865caee8 Sibling 0000000000 Child 0x86590590 > InterfaceType 0x5 Bus Number 0x4 > InstancePath is > “PCI\VEN_104C&DEV_8231&SUBSYS_00000000&REV_03\4&2739770a&0&00C0” > ServiceName is “pci” > State = DeviceNodeStarted (0x308) > Previous State = DeviceNodeEnumerateCompletion (0x30d) > StateHistory[07] = DeviceNodeEnumerateCompletion (0x30d) > StateHistory[06] = DeviceNodeStarted (0x308) > StateHistory[05] = DeviceNodeStartPostWork (0x307) > StateHistory[04] = DeviceNodeStartCompletion (0x306) > StateHistory[03] = DeviceNodeResourcesAssigned (0x304) > StateHistory[02] = DeviceNodeDriversAdded (0x303) > StateHistory[01] = DeviceNodeInitialized (0x302) > StateHistory[00] = DeviceNodeUninitialized (0x301) > … > … > StateHistory[08] = Unknown State (0x0) > Flags (0x000000f0) DNF_ENUMERATED, DNF_IDS_QUERIED, > DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED > UserFlags (0x00000008) DNUF_NOT_DISABLEABLE > CapabilityFlags (0x00000003) DeviceD1, DeviceD2 > DisableableDepends = 1 (including self) > CmResourceList at 0xe100f228 Version 0.0 Interface 0x5 Bus #0x3 > … > … > Entry 6 - Port (0x1) Undetermined Sharing (0) > Flags (0x24) - PORT_MEMORY 10_BIT_DECODE POSITIVE_DECODE > Range starts at 0x3b0 for 0xc bytes > Entry 7 - Port (0x1) Undetermined Sharing (0) > Flags (0x24) - PORT_MEMORY 10_BIT_DECODE POSITIVE_DECODE > Range starts at 0x3c0 for 0x20 bytes > > 0: kd> !pci 101 3 0 0 > > PCI Configuration Space (Segment:0000 Bus:03 Device:00 Function:00) > Common Header: > 00: VendorID 104c Texas Instruments > 02: DeviceID 8231 > 04: Command 0007 IOSpaceEn MemSpaceEn BusInitiate > 06: Status 0010 CapList > 08: RevisionID 03 > 09: ProgIF 00 > 0a: SubClass 04 PCI-PCI Bridge > 0b: BaseClass 06 Bridge Device > 0c: CacheLineSize 0010 BurstDisabled > 0d: LatencyTimer 00 > 0e: HeaderType 01 > 0f: BIST 00 > 10: BAR0 00000000 > 14: BAR1 00000000 > 18: PriBusNum 03 > 19: SecBusNum 04 > 1a: SubBusNum 04 > 1b: SecLatencyTmr 20 > 1c: IOBase f1 > 1d: IOLimit 01 > 1e: SecStatus 22a0 66MHzCapable FB2BCapable InitiatorAbort > DEVSELTiming:1 > 20: MemBase fd80 > 22: MemLimit fe00 > 24: PrefMemBase fa01 > 26: PrefMemLimit fbf1 > 28: PrefBaseHi 00000000 > 2c: PrefLimitHi 00000000 > 30: IOBaseHi 0000 > 32: IOLimitHi 0000 > 34: CapPtr 50 > 38: ROMBAR 00000000 > 3c: IntLine 00 > 3d: IntPin 00 > 3e: BridgeCtrl 0008 VGAEnable > > We are confused why PCI driver is claiming such a large number of IO > ranges in this particular case. Any clues/hints on how to resolve this > would be of great help. I am not an expert on PCI, so please correct me > in case my understanding is wrong. > > Sorry for the long mail, couldn?t find an alternate way to send the logs > > > Thanks, > Anees > >
Well, since you quote that deck (for which I supplied a lot of the content)
it’s worth pointing out that you can’t build a VGA device which works with
DOS (including Windows 98) and which has no I/O ports. We’re stuck with
that.
Furthermore, it’s tricky (though by no means prohibitive) to use
memory-mapped I/O regions in the adapter boot ROM, which drives some
designers to leave the I/O ports in their subsequent designs.
Some day we’ll stop seeing I/O port problems like this.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… >>arbiter debug extension. It seems that there is a conflict happening on >>the IO ranges. > > In year 1999, there was a .ppt file for download from Microsoft about “PCI > hardware design guidelines for Windows”. > > In this file - 10 years ago - it was said that the IO space is obsolete > for PCI devices, and all new device designs should use memory space > instead. > > 10 years passed. > > Nothing surprising that we now have unresolvable conflicts of several > hardware devices inside this tiny 64KB IO space. > > – > Maxim S. Shatskih > Windows DDK MVP > xxxxx@storagecraft.com > http://www.storagecraft.com > >
Thank you Jake for providing the VGA related information.
Is this the same case for every VGA capable graphics adapter which is behind a PCI bridge ? My debug environment is currently limited and I could not try this out myself. If yes, then what is the preferred resolution? Should the BIOS allocate resources that do not fall into the VGA range for all the devices? I have an option to get the BIOS changes accordingly, so wanted to confirm whether this is the normal way of getting rid of this issue or not.
Maxim,
I understand your point, and have read about it earlier. But at this point in time, I have to get the drivers up and running for the existing hardware and my options are limited to (a) making changes either to the driver or (b) Modified BIOS if the required change makes sense to the BIOS developer.
There’s not much you can do about VGA resources. What you can affect is the
other devices. If you have any control over the drivers, you can make it so
that they don’t use their I/O BARs, using only their MMIO BARs.
Put PciIoSpaceNotRequired in those INFs and those devices won’t conflict
with the VGA. This assumes, of course, that the drivers don’t use the I/O
BARs, the devices actually have MMIO BARs, and you using Vista or later.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev… > Thank you Jake for providing the VGA related information. > > Is this the same case for every VGA capable graphics adapter which is > behind a PCI bridge ? My debug environment is currently limited and I > could not try this out myself. If yes, then what is the preferred > resolution? Should the BIOS allocate resources that do not fall into the > VGA range for all the devices? I have an option to get the BIOS changes > accordingly, so wanted to confirm whether this is the normal way of > getting rid of this issue or not. > > Maxim, > > I understand your point, and have read about it earlier. But at this point > in time, I have to get the drivers up and running for the existing > hardware and my options are limited to (a) making changes either to the > driver or (b) Modified BIOS if the required change makes sense to the BIOS > developer. > > Thanks, > Anees > >
Thanks Jake.
We are are currently targeting XP Embedded, but will remember the INF additions for when we move to Vista/7 .
Will investigate the possibilities of making changes in the BIOS to get this working for XP.