P2P and Windows NT

[Benoit Lemieux <Benoit.Lemieux@matrox.com>]

Hi everyone,

We are experiencing some problems mapping devices behind a P2P bridge with a
440LX chipset and possibly MPS 1.4 on Windows NT 4 service pack 3.

For those interested (I hope someone is) I include 4 files in the
attachment pcimap.zip. Files pci1.map and msdrpt1.txt are respectively the
full dump of PCI config space and WinMSD report BEFORE I start my driver.
Files pci2.map and msdrpt2.txt are respectively the full dump of PCI config
space and WinMSD report AFTER I start my driver.

In essence, when I call HalAssignSlotResource() to determine the resource
requirements of the target device the function at first returns
STATUS_NO_SUCH_DEVICE. From pci1.map it's the device 8 on bus 2 that I tried
to map. If I call again HalAssignSlotResource(), but with bus 1 instead
of 2 and the same device number then the function succeeds. So the function
HalAssignSlotResource() did a reassignment of PCI resources (address and bus
number!). Up to now it's not so bad, we can live with that as long as we
always do two passes of HalAssignSlotResource() (one to force PCI reassignment
and the second to really get the work done properly).

HOWEVER, it's not so simple. On the secondary bus of the P2P bridge we have
two PCI devices and one of the two is a display controller. The display
driver (mga64.sys) is started after boot drivers have started. That driver
starts before ours and assumes the PCI address returned by
the call to the VideoPortDriver to VideoPortGetAccessRanges(). Later when we
call HalAssignSlotResource() on the second PCI device, the address reported by
the VideoPortDriver is NOT considered at all, and HalAssignSlotResource()
changes the frame buffer and register address of the display controller.
Obviously when our driver finishes its DriverEntry the system freezes because
the display controller is not at the same address recorded by the
display driver anymore. To verify this I start Windows NT in VGA safe mode (the
display driver is started in that mode too, but it's not used, so resources
are mapped by the driver). Files pci1.map and msdrpt2.txt were dumped that way.

Some will say OK. Just load your device driver before the display driver. Yeah
maybe, but suppose you have a system with a P2P bridge on the motherboard and 
you try to use products from ABC and DEF, what happen to PCI resources of
product ABC when the device driver for product DEF starts? It's exactly what
we are experiencing. The display driver is not written by us and we consider
it as a separate product.

We found and old mail from Marshal Brumer of Microsoft:

"In future versions of Windows we will be able to configure the bridge 
and devices beyond the bridge.  This will enable the dynamic 
reallocation of resources to devices as they are added/removed from the 
system.  A Plug and Play OS will know about all of the resources in the 
system and be in the best position to make these changes dynamically."

I guess it's what he meant by dynamic change.

By the way I tried the switch /PCILOCK without success, PCI base address of
the devices behind the P2P and the bus number of the P2P are still shuffled.

The machine I currently use is not an exception, many of our customers
reported similar problems on their 440LX machines. We validated our driver in
the past 2 years on Major brand machines including industrial PCs with 16 PCI
slots (4 P2P bridges) and we never noticed a similar behavior. Our driver can
support more than 8 boards in some configurations. Each board having a P2P
bridge on it.

We have at Matrox many products using P2P and my guest is that they may all
suffer from that problem. And why not other vendors?

Questions: 

Who is responsible for this, the BIOS or HAL? 

Is there something else I'm missing? 

Why HAL is not considering the resources reported by the VideoPortDriver? 

Is the AGP (which is seen as a P2P bridge) the source of the problem?


Any help or comments on similar experiences will be greatly appreciated.

pcimap.zip

Benoit Lemieux,
Imaging Software Leader 

Matrox Electronics Systems Ltd                Phone:  (514) 685-7230  x2465
1025 St-Regis Blvd
Dorval, Quebec, Canada                        Fax:    (514) 969-6273
H9P 2T4