NDIS bug with D3 power state?

NTDEV
1

Hi all,

in my NDIS miniport I seem to hit a bug in NDIS. When the miniport is brought up after the “Test Driver Support for D3 Power State” WHQL test, NDIS still asks the miniport for offloading without first setting OID_TASK_OFFLOAD. The problem seems to be that some bits of state persist in NDIS guts after the test, even though the adapter was completely torn down and reinitialized (MPHalt + MPInitialize).

I can easily work around this by defaulting the encapsulation header size to 14 (I only support IEEE 802.3 encapsulation anyway), but I was wondering if anybody ever saw this.

2

Just because the adapter is torn down, doesn’t mean the devnode was shut down. NDIS can start and stop your device at will, this doesn’t mean it forgets everything about it.

If you don’t want your device to be destroyed on D3, tell NDIS you support power OIDs.

3

wrote in message news:xxxxx@ntdev…
> Hi all,
>
> in my NDIS miniport I seem to hit a bug in NDIS. When the miniport is
> brought up after the “Test Driver Support for D3 Power State” WHQL test,
> NDIS still asks the miniport for offloading without first setting
> OID_TASK_OFFLOAD. The problem seems to be that some bits of state persist
> in NDIS guts after the test, even though the adapter was completely torn
> down and reinitialized (MPHalt + MPInitialize).
>
> I can easily work around this by defaulting the encapsulation header size
> to 14 (I only support IEEE 802.3 encapsulation anyway), but I was
> wondering if anybody ever saw this.
>

How do you run WHQL tests on Linux??
– pa

4

> NDIS can start and stop your device at will, this doesn’t mean

it forgets everything about it.

True, but if the miniport context changes, I simply do not
have access to the old one to get encapsulation information.

Replying to Pavel,

How do you run WHQL tests on Linux??

Don’t infer incorrect information from my mail domain,
or at least incomplete. :wink:

I use Linux-hosted Windows VMs for WHQL, and they
work great. The only minor inconvenience is that you
need a VNC or RDP session for DTM Studio and that’s
a bit clumsy (I’d very much prefer a web-based interface,
as long as it weren’t IE only).

5

> (I’d very much prefer a web-based interface,

as long as it weren’t IE only).

And the WHQL / Winqual website is IE only!

Tim.

6

wrote in message news:xxxxx@ntdev…
>> NDIS can start and stop your device at will, this doesn’t mean
>> it forgets everything about it.
>
> True, but if the miniport context changes, I simply do not
> have access to the old one to get encapsulation information.
>
> Replying to Pavel,
>
>> How do you run WHQL tests on Linux??
>
> Don’t infer incorrect information from my mail domain,
> or at least incomplete. :wink:
>
> I use Linux-hosted Windows VMs for WHQL, and they
> work great. The only minor inconvenience is that you
> need a VNC or RDP session for DTM Studio and that’s
> a bit clumsy (I’d very much prefer a web-based interface,
> as long as it weren’t IE only).
>

Ok then Alex G. may be right - if your driver does not declare
power management capability, NDIS will bring down the miniport
on exit from D0 and initialize it again on return to D0.
To avoid this just reply correctly to the OID which asks your PnP
capabilities;
see NDIS samples.

(As a temporary hack, you can save the state in a static variable, since the
driver will stay in memory :slight_smile:

Regards,
– pa

7

It’s “by design” that a miniport can go from HALTED -> INITIALIZED. In fact, technically, a miniport is born in the HALTED state, so this transition is the very first thing that happens to it. It’s also not surprising that it can happen more than once – e.g., if you have an NDIS5 IM driver plugged into an NDIS6 stack, you probably would see this transition quite often.

Internally, NDIS does keep some state around, even though your own MiniportAdapterContext is (presumably) deleted and recreated anew. It’s entirely possible that we do have a bug where we are incorrectly neglecting to re-set task offload configuration on your miniport. However, it’s fairly difficult to investigate this without knowing more about the situation – what’s the OS version and what kind of miniport are you? What is this precise sequence of events that you observe and would expect to observe?

Also, to set expectations here – if there really is an OS bug, I probably can’t give you a very satisfying resolution. The sun has set on NDIS5 driver model (and Windows XP), so we are not in the habit of churning fixes on them anymore. Since it sounds like you’ve found an easy workaround, I it might not be worth chasing this one down.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@redhat.com
Sent: Tuesday, October 05, 2010 6:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS bug with D3 power state?

Hi all,

in my NDIS miniport I seem to hit a bug in NDIS. When the miniport is brought up after the “Test Driver Support for D3 Power State” WHQL test, NDIS still asks the miniport for offloading without first setting OID_TASK_OFFLOAD. The problem seems to be that some bits of state persist in NDIS guts after the test, even though the adapter was completely torn down and reinitialized (MPHalt + MPInitialize).

I can easily work around this by defaulting the encapsulation header size to 14 (I only support IEEE 802.3 encapsulation anyway), but I was wondering if anybody ever saw this.

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

8

There are other reasons causing reinit upon Dn->D0.

  1. the setting of NOT_HALT_ON_SUSPEND flag in attribute.
  2. There is a check box (or radio button somewhere in the advanced tab
    or the power management tab). I don’t have a Windows box to confirm its
    exact name.

Calvin

if your driver does not declare
power management capability, NDIS will bring down the miniport
on exit from D0 and initialize it again on return to D0.
To avoid this just reply correctly to the OID which asks your PnP
capabilities;
see NDIS samples.

(As a temporary hack, you can save the state in a static variable,
since the driver will stay in memory :slight_smile:

Regards,
– pa