I am working with a PCIe endpoint device. When my WDM driver gets IRP_MN_START_DEVICE I pass it to the next lower device object in the stack. The device stack includes the device object managed by my driver, next is a device object managed by acpi.sys (is this normal?) and on the bottom is a device object managed by pci.sys. When the IRP completes the status is 0xC000000D (status invalid parameter). I am looking for advice, hints on things I can check to find the problem.
I am working with a PCIe endpoint device. When my WDM driver gets IRP_MN_START_DEVICE
Why do you have a WDM driver and not a KMDF driver?
What kind of a device is this?
I pass it to the next lower device object in the stack. The device stack includes the device object managed by my driver, next is a device object managed by acpi.sys (is this normal?) and on the bottom is a device object managed by pci.sys. When the IRP completes the status is 0xC000000D (status invalid parameter).
Do you take any action before you hand it down, or change the IRP in any
way? With START_DEVICE, you are supposed to let each of the lower
devices handle it first, then you take whatever action you need to take.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I am working from an existing driver code base but it is the first time we are trying to control a PCIe device. The device is a development board with a DSP on it. The driver makes no changes to the IRP before passing it on to the lower device.
I am working from an existing driver code base but it is the first time we are trying to control a PCIe device. The device is a development board with a DSP on it. The driver makes no changes to the IRP before passing it on to the lower device.
Odd. I don’t understand why it should get “invalid parameter”. Is
there something unusual in the PCIe configuration space? Do you use
only memory BARs, or do you have I/O as well? MSI interrupts or MSI-X?
Is the device actually mentioned in the ACPI DSDT?
This is mostly shooting in the dark, but maybe you’ll provide some
tidbit that brings up an old memory.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
70: CapID 10 PCI Express Capability
71: NextPtr 00
72: Express Caps 0002 Type:Endpoint
74: Device Caps 012c8701
78: Device Control 2800 MRR:512 NS ap pf et MP:128 ro ur fe nf ce
7a: Device Status 0009 tp ap UR fe nf CE
7c: Link Caps 00033422
80: Link Control 00c0 ES CC rl ld RCB:64 ASPM:None
82: Link Status 1022 SCC lt lte NLW:x2 LS:2.5
84: Slot Caps 00000000
88: Slot Control 0000 pcc PI:?? AI:?? hpi cc pde mrls pfd ab
8a: Slot Status 0000 pds hpi cc pdc ms pfd ab
8c: Root Control 0000 pmei fs nfs cs
8e: Reserved 0000
90: Root Status 00000000 pmep pmes ID:0
That’s odd. Do you expect 4 memory BARs or 5? The 5th BAR (BAR4) has
the “prefetchable” bit set but no address. If BAR4 is not used, it
should return ALL zeros. If you expected an address here, then the
address assignment failed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The driver does handle IRP_MN_FILTER_RESOURCE_REQUIREMENTS but does not change anything for this device type. I will try to skip this step to see if it makes a difference.
Tim,
I expect only 4 memory BARs. I will check on that. Maybe that is the problem.
The firmware engineer was not sure why the prefetchable bit was set so I asked him to request small memory regions for BAR4 (and BAR5). With that change the device start is now passing OK.