NDIS_STATUS_PENDING and OID_PNP_SET_POWER in NDIS 5.1

NTDEV
1

I need to defer OID_PNP_SET_POWER in my NDIS 5.1 driver while I want for
a confirmation from Xen that the device has been put to sleep. The docs
for OID_PNP_SET_POWER say I can return NDIS_STATUS_PENDING but those
docs to appear to be targeted towards a 6.0 driver as they refer to
NdisMOidRequestComplete not NdisMSetInformationComplete.

Can I return NDIS_STATUS_PENDING from
MiniPortSetInformation(OID_PNP_SET_POWER)?

Right now i’m doing that and scheduling a workitem to complete the
request, but I’m getting a crash when I make the call to
NdisMSetInformationComplete. I am raising IRQL to DISPATCH_LEVEL just
before the call to NdisMSetInformationComplete as per the docs and can’t
see anything else I’m doing wrong.

Thanks

James

2

>

I need to defer OID_PNP_SET_POWER in my NDIS 5.1 driver while I want
for
a confirmation from Xen that the device has been put to sleep. The
docs
for OID_PNP_SET_POWER say I can return NDIS_STATUS_PENDING but those
docs to appear to be targeted towards a 6.0 driver as they refer to
NdisMOidRequestComplete not NdisMSetInformationComplete.

Can I return NDIS_STATUS_PENDING from
MiniPortSetInformation(OID_PNP_SET_POWER)?

Right now i’m doing that and scheduling a workitem to complete the
request, but I’m getting a crash when I make the call to
NdisMSetInformationComplete. I am raising IRQL to DISPATCH_LEVEL just
before the call to NdisMSetInformationComplete as per the docs and
can’t
see anything else I’m doing wrong.

My crash was caused by passing the adapter context and not the adapter
handle to NdisMSetInformationComplete. Dumb mistake.

James

3

It should be fine. And AFAIK, you do not need to raise to DISPATCH. I
think the DOCs really mean you can call that DDI at IRQL <= DISPATCH_LEVEL.
In my amateur opinion (IMAO?) it is nonsensical to specify IRQL ==
DISPATCH_LEVEL for a DDI in this case as it would be unreasonable for NDIS
to make that assumption simply to optimize spinlock acquisition. The
context rules of NDIS miniports might require that you be interior to the
scope of the miniport lock but that is not what is stated (nor is there a
good way to accomplish that feat - NdisIMSwitchToMiniport seems rather
unlikely to be necessary).

What does the crash look like (stack back-trace)?

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, August 27, 2010 8:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS_STATUS_PENDING and OID_PNP_SET_POWER in NDIS 5.1

I need to defer OID_PNP_SET_POWER in my NDIS 5.1 driver while I want for
a confirmation from Xen that the device has been put to sleep. The docs
for OID_PNP_SET_POWER say I can return NDIS_STATUS_PENDING but those
docs to appear to be targeted towards a 6.0 driver as they refer to
NdisMOidRequestComplete not NdisMSetInformationComplete.

Can I return NDIS_STATUS_PENDING from
MiniPortSetInformation(OID_PNP_SET_POWER)?

Right now i’m doing that and scheduling a workitem to complete the
request, but I’m getting a crash when I make the call to
NdisMSetInformationComplete. I am raising IRQL to DISPATCH_LEVEL just
before the call to NdisMSetInformationComplete as per the docs and can’t
see anything else I’m doing wrong.

Thanks

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Ok, my mail reader just caught up after my last post. Glad to hear it is
all good.

Never mind :slight_smile:

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, August 27, 2010 9:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS_STATUS_PENDING and OID_PNP_SET_POWER in NDIS 5.1

I need to defer OID_PNP_SET_POWER in my NDIS 5.1 driver while I want
for
a confirmation from Xen that the device has been put to sleep. The
docs
for OID_PNP_SET_POWER say I can return NDIS_STATUS_PENDING but those
docs to appear to be targeted towards a 6.0 driver as they refer to
NdisMOidRequestComplete not NdisMSetInformationComplete.

Can I return NDIS_STATUS_PENDING from
MiniPortSetInformation(OID_PNP_SET_POWER)?

Right now i’m doing that and scheduling a workitem to complete the
request, but I’m getting a crash when I make the call to
NdisMSetInformationComplete. I am raising IRQL to DISPATCH_LEVEL just
before the call to NdisMSetInformationComplete as per the docs and
can’t
see anything else I’m doing wrong.

My crash was caused by passing the adapter context and not the adapter
handle to NdisMSetInformationComplete. Dumb mistake.

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer