Hi,

On my system, my vendor (IBM) preinstalls a filter driver (IBM Active
PCI a.k.a. ibmhpf.sys) that sits between the PCI bus and PCI device
drivers (such as mine). It manages some IBM-specific PCI hotplug
functionality and should be "transparent" to PCI device drivers. My
device driver is not aware of this filter and continues to work as
usual. However, after I reload my driver (Disable+Enable in the Device
Manager), it would no longer operate normally, getting null MDLs in its
DispatchRead routine. As you know, there can be two reasons for getting
null MDLs:
1. Not having DO_DIRECT_IO in your DEVICE_OBJECT's Flags. (Obviously I
always had this flag set.)
2. Passing a zero-sized buffer to ReadFile. (I don't do this.)

Inspecting my device with Walter Oney's DevView revealed the reason:
while my FDO has DO_DIRECT_IO in its flags, IBM's FiDO does not -- and
IBM's FiDO has relocated from being between my FDO and the PCI bus, to
be *on top* of my FDO!

What can cause this FiDO (whose source code I obviously don't have) to
be inserted at the right place on system startup, but at the wrong
place on subsequent reload of my driver?

Is there a registry entry for the IBM driver as an upper (or possibly lower)
filter? If yes, can you show it. If not, you need to determine how the IBM
driver comes to be installed. I'd guess things work OK when you stack is
built at boot but not when it is later (re)built. That makes me wonder if
IBM has some "bus" logic somewhere to ensure the filter is placed on the
stack and isn't relying purely on the OS.

--
James Antognini
Windows DDK and WDK Support


This posting is provided "AS IS" with no warranties, and confers no rights.



"Ilya Konstantinov" <ilya.konstantinov@gmail.com> wrote in message
news:1129204210.786748.138640@g49g2000cwa.googlegr oups.com...

James Antognini [MSFT] wrote:
there ought to be an upper filter spec in the registry for the PCI class
that points to this driver. Although if it is truly a hotplug pci bus
attitude adjuster one would think that pci device insertion/removal
would have been tested. Then again it makes the mistake of not honoring
the device type characteristics of the lower device - so its already a
bit broken.

I wonder what verifier would have to say?
--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

James Antognini [MSFT] wrote:
I found no UpperFilter or LowerFilter entries in their INF file. Could
they somehow add themselves as a filter programatically? If so, can I
change my order in the stack programatically as well upon detecting
IBM's filter driver above me in the stack?

Mark Roddy wrote:
for BusRelations changes and then IoAttachDeviceToDeviceStack-ing). If
they were a sane filter (using an UpperFilter on top of the PCI bus
driver), an AddDevice handler would've been enough, wouldn't it?

Another curious fact is that, while a Device Manager Disable+Enable
makes their FiDo go on top of my FDO, a full Uninstall+AddNewHardware
of my device makes their FiDo go into the right place. Why could that
be?

Ilya Konstantinov wrote:
it also has correctly manage deleting its attached device object, and
that is a bit tricky and it appears not implemented correctly in this
driver.

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com