Device stack reordering when driver is reloaded

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?

James
Thu Oct 13 16:34:17 CDT 2005

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.googlegroups.com...
> 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?
>

Mark
Thu Oct 13 21:48:47 CDT 2005

James Antognini [MSFT] wrote:
> 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.
>
My guess is that this is an improperly implemented bus filter driver -
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

Ilya
Tue Oct 18 11:31:20 CDT 2005

James Antognini [MSFT] wrote:
> Is there a registry entry for the IBM driver as an upper (or possibly lower)
> filter?

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:
> My guess is that this is an improperly implemented bus filter driver -
> 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.

>From looking at their driver's strings dump, I can guess they both
handle AddDevice and IRP_MN_QUERY_DEVICE_RELATIONS (probably waiting
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?

Mark
Fri Oct 28 17:15:21 CDT 2005

Ilya Konstantinov wrote:
> James Antognini [MSFT] wrote:
>
>>Is there a registry entry for the IBM driver as an upper (or possibly lower)
>>filter?
>
>
> 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:
>
>>My guess is that this is an improperly implemented bus filter driver -
>>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.
>
>
>>From looking at their driver's strings dump, I can guess they both
> handle AddDevice and IRP_MN_QUERY_DEVICE_RELATIONS (probably waiting
> 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?
>
A bus filter driver has to do the IoAttach in QueryDeviceRelations, but
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