IRP Status 0xC000000D

Sorry everyone another newbee to deal with.

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.

Thanks,
Rony

xxxxx@drti.com wrote:

Sorry everyone another newbee to deal with.

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.

Do you at least copy the stack location to the next?

Yes Alex. I use IoCopyCurrentIrpStackLocationToNext() to do that.

xxxxx@drti.com wrote:

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.

I would also suggest you move to KMDF first and debug/trace PNP events related callbacks.

Tim,

Here is the PCI configuration information (using !pci). The device is currently configured to use legacy interrupts.

2: kd> !pci 301 0 1 0

PCI Configuration Space (Segment:0000 Bus:01 Device:00 Function:00)
Common Header:
00: VendorID 104c Texas Instruments
02: DeviceID b005
04: Command 0007 IOSpaceEn MemSpaceEn BusInitiate
06: Status 0010 CapList
08: RevisionID 01
09: ProgIF 00
0a: SubClass 80 Other Signal Processing Controller
0b: BaseClass 11 Signal Processing
0c: CacheLineSize 0010 BurstDisabled
0d: LatencyTimer 00
0e: HeaderType 00
0f: BIST 00
10: BAR0 f7a00000
14: BAR1 d4700008
18: BAR2 d4600008
1c: BAR3 f7b00000
20: BAR4 00000008
24: BAR5 00000000
28: CBCISPtr 00000000
2c: SubSysVenID ac1e
2e: SubSysID 0040
30: ROMBAR 00000000
34: CapPtr 40
3c: IntLine 10
3d: IntPin 01
3e: MinGnt 00
3f: MaxLat 00
Device Private:
40: 00035001 00000000 00000000 00000000
50: 00807005 00000000 00000000 00000000
60: 00000000 00000000 00000000 00000000
70: 00020010 012c8701 00092800 00033422
80: 102200c0 00000000 00000000 00000000
90: 00000000 0000001f 00000000 00000006
a0: 00000002 00000000 00000000 00000000
b0: 00000000 00000000 00000000 00000000
c0: 00000000 00000000 00000000 00000000
d0: 00000000 00000000 00000000 00000000
e0: 00000000 00000000 00000000 00000000
f0: 00000000 00000000 00000000 00000000
Capabilities:
40: CapID 01 PwrMgmt Capability
41: NextPtr 50
42: PwrMgmtCap 0003 Version=3
44: PwrMgmtCtrl 0000 DataScale:0 DataSel:0 D0

50: CapID 05 MSI Capability
51: NextPtr 70
52: MsgCtrl 64BitCapable MultipleMsgEnable:0 (0x1) MultipleMsgCapable:0 (0x1)
54: MsgAddr 0
58: MsgAddrHi 0
5c: MsData 0

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

Enhanced Capabilities:
100: CapID 0001 Advanced Error Reporting Capability
Version 1
NextPtr 000

Do you modify the device resources in IRP_MN_QUERY_RESOURCES and IRP_MN_QUERY_RESOURCE_REQUIREMENTS?

xxxxx@drti.com wrote:

10: BAR0 f7a00000
14: BAR1 d4700008
18: BAR2 d4600008
1c: BAR3 f7b00000
20: BAR4 00000008
24: BAR5 00000000

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.

Alex,

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.

Tim,

You were spot on.

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.

Thank you all for the help.

Rony