IRP_MN_START_DEVICE and IRP_MN_STOP_DEVICE semantics

NTDEV
1

You could think that the semantics of these two basic PNP IRPs should be very clear in the docs and correctly implemented in most drivers. But the real situation seems to be far from this.

A few days ago I raised an issue about the exact semantics in the managed newsgroup. Specifically, I raised the issue if a PNP STOP is (and if should be) an implicit power-down or not; and if a PNP START is (and if should be) *always* an implicit power-up or not.

I made then a little research and the results are almost astonishing. The issue seems to be one of the worst documented in the WDK. The WDK is ambiguous, sometimes almost contradictory and even possibly wrong. Similarly, checking the WDK sources for both illustrative samples and production ones, it seems that most drivers don’t implement them correctly.

The exact power management meaning of PNP start/stop is closely related to the fact that a driver can receive a PNP START in two different situations: One as the initial start-up, and another one after a PNP STOP. And a driver might need to handle both cases in a quite different way. Many drivers seem to be not fully aware about the two different situations. And they seem to be not completely ready to handle both situations correctly.

The unclear documentation of the topic might be the reason for the incorrect implementation on the drivers. Another reason could be that many drivers never realized a full transition from the NT legacy model to the PNP/WDM one. But there was one thing that I couldn’t understand at all:

If many drivers don’t have a robust handling of PNP STOP and (multiple) PNP START IRPs, then why Windows doesn’t frequently crash when the PNP manager performs a rebalance? (I’m far from being a storage expert, but after checking the storage class driver sources, I’m not sure the storage stack can always survive a rebalance).

The answer is probably obvious to some experts, but it wasn’t at all to me, not before the research. The answer is that Win 2k and later (as opposed to Win 98 and Me) will (almost) never perform a rebalance. And then NT drivers are extremely unlikely to get a PNP STOP at all. Let alone that it seems that Windows completely avoids a rebalance for devices that are just peer with critical ones.

This is supposed to change with the multilevel rebalance feature introduced in Vista. But some third party references indicate that this is not enabled in Vista yet. I don’t know if this is true or not (and I would like to hear an answer). The references mention hardware related complications. But I guess that a possible reason for not being enabled and/or implemented in Vista yet, is because it might break many drivers.

My modest conclusion of the research is that I was right about my initial assumptions. A PNP STOP should not be an implicit power down, and a subsequent PNP start should not be an implicit power-up. This is derived from the fact that a resource rebalance should be performed as quickly as possible, and that drivers should succeed a query STOP as much as possible.

It is unlikely that drivers would meet these requirements without proper documentation. And then the chances for realizing multilevel rebalance are small.

Some references:

http://support.microsoft.com/kb/314068
“The description includes an explanation of why many of the devices on your computer seem to use the same IRQ and why Windows XP does not include resource rebalancing.”

http://www.microsoft.com/whdc/system/pnppwr/hotadd/hotplugpci.mspx
“Dynamic configuration will exercise code paths that currently might not be exercised completely in Windows 2000 and Windows XP, so drivers that work on Windows 2000 and Windows XP might fail on later versions of Windows operating systems unless properly implemented.”

http://www.microsoft.com/whdc/system/bus/PCI/multilevel-rebal.mspx
“Handling Stop Semantics
…
Typical driver actions during the stop request should:
…
Keep the device in the D0 state—do not transition the device to a higher Dx state that would cause the hardware context to be lost.”

2

>My modest conclusion of the research is that I was right about my initial

assumptions. A PNP STOP should not be an implicit power down, and a

Default KMDF handler for PNP STOP causes an implicit power down.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

3

If you go back and read the various postings on the KMDF, you will realize
that much of this effort was understanding what should be done with all the
potential states for the PnP and Power requests. It seemed every time
there was a new presentation (over the course of 5 years of effort) the
number of states in the state machine grew. It also became quickly obvious
that this was extremely complex and that probably no driver really had it
right.

So now you are complaining that WDK is ambiguous, well in the 10 years
since Microsoft first presented PnP/Power to many of us (there was a one
day NDA conference after WinHEC 1997) many of could have told you this.
Yes it is true that most drivers see very few PNP IRP’s other than startup
and shutdown, but just because you code something that will not crash
often, you are still coding a crash.

Now, you claim that you are correct, and probably for a well designed
device what you are proposing can be gotten away with, but KMDF was
designed to be reliable as possible for all devices. I can think of
clients devices that bad things would happen if you tried a rebalance in
anything but a powered down state. While yes the device should not do
that, it does and there are a lot out there, so should Microsoft say forget
it for devices that act this way, or do the safe thing for devices that act
this way? Personally, I believe they made the right choice.

I am not a KMDF expert but if you really do not want your device to shut
down, I suspect you could query the PnP and power states and determine what
is happening to handle this. You might argue that, this querying should be
done for the poorly designed devices, but the play it safe approach of KMDF
is better IMHO.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
You could think that the semantics of these two basic PNP IRPs should be
very clear in the docs and correctly implemented in most drivers. But the
real situation seems to be far from this.

A few days ago I raised an issue about the exact semantics in the managed
newsgroup. Specifically, I raised the issue if a PNP STOP is (and if should
be) an implicit power-down or not; and if a PNP START is (and if should be)
always an implicit power-up or not.

I made then a little research and the results are almost astonishing. The
issue seems to be one of the worst documented in the WDK. The WDK is
ambiguous, sometimes almost contradictory and even possibly wrong.
Similarly, checking the WDK sources for both illustrative samples and
production ones, it seems that most drivers don’t implement them correctly.

The exact power management meaning of PNP start/stop is closely related to
the fact that a driver can receive a PNP START in two different situations:
One as the initial start-up, and another one after a PNP STOP. And a driver
might need to handle both cases in a quite different way. Many drivers seem
to be not fully aware about the two different situations. And they seem to
be not completely ready to handle both situations correctly.

The unclear documentation of the topic might be the reason for the
incorrect implementation on the drivers. Another reason could be that many
drivers never realized a full transition from the NT legacy model to the
PNP/WDM one. But there was one thing that I couldn’t understand at all:

If many drivers don’t have a robust handling of PNP STOP and (multiple) PNP
START IRPs, then why Windows doesn’t frequently crash when the PNP manager
performs a rebalance? (I’m far from being a storage expert, but after
checking the storage class driver sources, I’m not sure the storage stack
can always survive a rebalance).

The answer is probably obvious to some experts, but it wasn’t at all to me,
not before the research. The answer is that Win 2k and later (as opposed to
Win 98 and Me) will (almost) never perform a rebalance. And then NT drivers
are extremely unlikely to get a PNP STOP at all. Let alone that it seems
that Windows completely avoids a rebalance for devices that are just peer
with critical ones.

This is supposed to change with the multilevel rebalance feature introduced
in Vista. But some third party references indicate that this is not enabled
in Vista yet. I don’t know if this is true or not (and I would like to hear
an answer). The references mention hardware related complications. But I
guess that a possible reason for not being enabled and/or implemented in
Vista yet, is because it might break many drivers.

My modest conclusion of the research is that I was right about my initial
assumptions. A PNP STOP should not be an implicit power down, and a
subsequent PNP start should not be an implicit power-up. This is derived
from the fact that a resource rebalance should be performed as quickly as
possible, and that drivers should succeed a query STOP as much as possible.

It is unlikely that drivers would meet these requirements without proper
documentation. And then the chances for realizing multilevel rebalance are
small.

Some references:

http://support.microsoft.com/kb/314068
“The description includes an explanation of why many of the devices on your
computer seem to use the same IRQ and why Windows XP does not include
resource rebalancing.”

http://www.microsoft.com/whdc/system/pnppwr/hotadd/hotplugpci.mspx
“Dynamic configuration will exercise code paths that currently might not be
exercised completely in Windows 2000 and Windows XP, so drivers that work
on Windows 2000 and Windows XP might fail on later versions of Windows
operating systems unless properly implemented.”

http://www.microsoft.com/whdc/system/bus/PCI/multilevel-rebal.mspx
“Handling Stop Semantics
.
Typical driver actions during the stop request should:
.
Keep the device in the D0 state-do not transition the device to a higher Dx
state that would cause the hardware context to be lost.”

4

Hi Don,

Please note that I didn’t mention KMDF at all in my post here. The KMDF behavior is incidental from my point of view. If you read the thread on the newsgroup, I did mention KMDF there, but only because it was the KMDF docs that made me aware about the issue.

So I’m not complaining, at least not specifically, about the KMDF behavior. I am complaining about the docs, about an (IMHO) incorrect system behavior. And what it is more important (as you’ll see below), about an inconsistent behavior. Actually, complaining is probably not the right term, let’s say I am just noting a problem.

It is true that there are many other ambiguities in the WDK. But most of them become clear when you check the samples. And most of them don’t carry over actual system behavior. In this case the WDK ambiguity corresponds to an actual inconsistent system behavior.

You have much more experience than me with actual hardware devices for Windows. So I trust you that some devices aren’t ready to reassign resources without being powered down. But I’m sure you realize that unnecessarily power cycling the device is bad, sometimes too bad. And I mentioned many cases and reasons on the newsgroup.

So if your device can’t survive a rebalance without a power cycle, then ideally the device should be fixed. If that is not possible, then the driver should (if possible) deal with the situation (say, performing a software reset). If that is not possible, then the driver should provoke an explicit power cycle. Finally, if none is possible or desirable, then the driver should fail the QUERY STOP. The other way around doesn’t make much sense to me.

But again, what is most important is consistent system behavior. So you are happy that KMDF would power down your device on rebalance, because some of your client devices would need so. Unfortunately that is not the case. KMDF typically will not power down the device. It just assumes an implicit power down on STOP. And unless the lower layers agree with that assumption, the device won’t be powered down.

As far as I can see, the XP SP2 PCI bus driver doesn’t power down the device on STOP. I didn’t check other bus drivers, or the PCI bus driver on Vista. But after reading the WHDC article on PCI multilevel rebalance, I doubt very much this behavior changed in Vista. I wouldn’t make any sense.

And it is not only about the implicit power-down on STOP. It is also about the implicit power-up on a subsequent START. In this case the system behavior is more or less consistent (but, IMHO, still wrong). Most drivers seem to agree that a START is *always* an implicit power-up. This brings the non-sense situation I mentioned in the newsgroup (where devices powered down because of idle detection, would be unnecessarily powered up on rebalance). And this is disregarding if STOP should be an implicit power-down or not.

Furthermore, most drivers consider every START an implicit power-up, but seem to not be ready for the possibility that this power-up would need restoring hardware context.

5

" why Windows doesn’t frequently crash when the PNP manager performs a rebalance?"

Windows rarely if ever does a rebalance, although this may change soon. Many devices do not concern themselves with power management, so as along as they deal with Start from Stopped and Start from AddDevice, they will be ok.

KMDF merges power and pnp into a single more or less coherent state machine and thus is a far preferable programming environment. Hopefully underneath (inside) KMDF, Microsoft has actually gotten the merge correct.

6

Please, don’t send the same letter for me.
Thank you very much.

On 5/28/07, xxxxx@rahul.net wrote:
>
> You could think that the semantics of these two basic PNP IRPs should be
> very clear in the docs and correctly implemented in most drivers. But the
> real situation seems to be far from this.
>
> A few days ago I raised an issue about the exact semantics in the managed
> newsgroup. Specifically, I raised the issue if a PNP STOP is (and if should
> be) an implicit power-down or not; and if a PNP START is (and if should be)
> always an implicit power-up or not.
>
> I made then a little research and the results are almost astonishing. The
> issue seems to be one of the worst documented in the WDK. The WDK is
> ambiguous, sometimes almost contradictory and even possibly wrong.
> Similarly, checking the WDK sources for both illustrative samples and
> production ones, it seems that most drivers don’t implement them correctly.
>
> The exact power management meaning of PNP start/stop is closely related to
> the fact that a driver can receive a PNP START in two different situations:
> One as the initial start-up, and another one after a PNP STOP. And a driver
> might need to handle both cases in a quite different way. Many drivers seem
> to be not fully aware about the two different situations. And they seem to
> be not completely ready to handle both situations correctly.
>
> The unclear documentation of the topic might be the reason for the
> incorrect implementation on the drivers. Another reason could be that many
> drivers never realized a full transition from the NT legacy model to the
> PNP/WDM one. But there was one thing that I couldn’t understand at all:
>
> If many drivers don’t have a robust handling of PNP STOP and (multiple)
> PNP START IRPs, then why Windows doesn’t frequently crash when the PNP
> manager performs a rebalance? (I’m far from being a storage expert, but
> after checking the storage class driver sources, I’m not sure the storage
> stack can always survive a rebalance).
>
> The answer is probably obvious to some experts, but it wasn’t at all to
> me, not before the research. The answer is that Win 2k and later (as opposed
> to Win 98 and Me) will (almost) never perform a rebalance. And then NT
> drivers are extremely unlikely to get a PNP STOP at all. Let alone that it
> seems that Windows completely avoids a rebalance for devices that are just
> peer with critical ones.
>
> This is supposed to change with the multilevel rebalance feature
> introduced in Vista. But some third party references indicate that this is
> not enabled in Vista yet. I don’t know if this is true or not (and I would
> like to hear an answer). The references mention hardware related
> complications. But I guess that a possible reason for not being enabled
> and/or implemented in Vista yet, is because it might break many drivers.
>
> My modest conclusion of the research is that I was right about my initial
> assumptions. A PNP STOP should not be an implicit power down, and a
> subsequent PNP start should not be an implicit power-up. This is derived
> from the fact that a resource rebalance should be performed as quickly as
> possible, and that drivers should succeed a query STOP as much as possible.
>
> It is unlikely that drivers would meet these requirements without proper
> documentation. And then the chances for realizing multilevel rebalance are
> small.
>
>
> Some references:
>
> http://support.microsoft.com/kb/314068
> “The description includes an explanation of why many of the devices on
> your computer seem to use the same IRQ and why Windows XP does not include
> resource rebalancing.”
>
> http://www.microsoft.com/whdc/system/pnppwr/hotadd/hotplugpci.mspx
> “Dynamic configuration will exercise code paths that currently might not
> be exercised completely in Windows 2000 and Windows XP, so drivers that work
> on Windows 2000 and Windows XP might fail on later versions of Windows
> operating systems unless properly implemented.”
>
> http://www.microsoft.com/whdc/system/bus/PCI/multilevel-rebal.mspx
> “Handling Stop Semantics
> ?
> Typical driver actions during the stop request should:
> ?
> Keep the device in the D0 state?do not transition the device to a higher
> Dx state that would cause the hardware context to be lost.”
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

7

xxxxx@rahul.net wrote:

…
And it is not only about the implicit power-down on STOP. It is also about the implicit power-up on a subsequent START. In this case the system behavior is more or less consistent (but, IMHO, still wrong). Most drivers seem to agree that a START is *always* an implicit power-up. …

Furthermore, most drivers consider every START an implicit power-up, but seem to not be ready for the possibility that this power-up would need restoring hardware context.

I’m not sure I fully understand what you are arguing. Are you
suggesting that a driver should tell its device to power up when it
receives IRP_MN_START_DEVICE and power down when it receives
IRP_MN_STOP_DEVICE? My assumption is that my device can be told to
power down after I get IRP_MN_STOP_DEVICE, but it’s up to the power IRPs
to tell me to do that. That is, START_DEVICE means “power has been
applied and you should get ready for I/O”, and STOP_DEVICE means “you
should stop doing I/O now, because your device may be asked to power
down shortly”.

Are you saying something different?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

OP: If your point is that the PnP and power state machines in Windows are poorly documented in the DDK/WDK, when documented at all, you’re absolutely correct. If you’re also saying that this may be the reason so many drivers implement power and PnP correctly, I’m sure you’re right.

You’re surprised, and just a bit peaved it seems, that so fundamental a fact as to whether _STOP_DEVICE should be an implicit power down isn’t clearly described. Yeah. Welcome to the world of Windows driver development.

As folks have alluded to earlier in this thread, it took some *very* smart people more than an elapsed year to get the integrated PnP/Power state machine built for KMDF. And this is working WITH the Windows source code, and the devs responsible for PnP/Power in Windows. After that year, it took considerable tweaking and tunining to ferret out the special cases.

To me, this is evidence not of the paucity of documentation for PnP/Power, but to the complexity of the actual implementation. There’s a lot of historical “baggage” and remnants of the long process of grafting PnP/Power into an already established Windows O/S that need to be dealt with. In other words, it’s pretty darn hard to document that which by its very nature is unclear, ambiguous, and fraught with special cases.

So, yeah… PnP/Power is implemented ugly. But it does work. And we get to live with it. And thus, seemingly simple questions like “Is _STOP_DEVICE an implied power down” draw both groans and differing opinions.

Now maybe you understand why the experienced Windows driver devs on this list are some of the most ardent supporters of KMDF – where this work has been done for you.

Finally, if you want a simple answer to a simple question: “Is _STOP_DEVICE an request to implicitly power down your device?” The simple answer is “Yes.” Or, if you don’t like that answer and you understand what _STOP_DEVICE means, and your device has different needs/requirements, then choose an answer you prefer. It’s engineering, after all. Maybe THAT’s why there’s no pat answer for stuff like this in the WDK/DDK… you’ve gotta UNDERSTAND what’s going on, and when you do, you can decide for yourself.

Peter
OSR

9

Tim Roberts wrote:

I’m not sure I fully understand what you are arguing. Are you
suggesting that a driver should tell its device to power up when it
receives IRP_MN_START_DEVICE and power down when it receives
IRP_MN_STOP_DEVICE?

I mean that STOP and a *subsequent* START should not imply any change whatsoever to the current power state (why it should?). STOP should not mean much more than just pause I/O because the assigned I/O resources could be changed. And the *subsequent* START should mean only that I/O can continue with the new assigned resources.

Note again the difference between a (subsequent) START following a STOP and the initial one after AddDevice.

If the device was already powered down (because you are implementing idle detection), then it doesn’t make much sense to power it up just for reassigning resources. And if it is powered on, then there is no need to power cycle it.

The whole point is that a rebalance would be a much more frequent and common operation in the future. Then it should be done as quickly as possible (read, without a power cycle which could be very expensive).

10

Hi Peter,

OP: If your point is that the PnP and power state machines in Windows are poorly documented…
You’re surprised, and just a bit peaved it seems, …

I apologize if I sounded as too negative and too complaining. That wasn’t my intention at all. I do realize about the impossibility of documenting everything (let alone, clearly and precisely) in the WDK, and I do know about the historical and compatibility complications.

So, yeah… PnP/Power is implemented ugly. But it does work.

I beg to differ, I’m not sure you can say that this specific Pnp aspect does work. Windows currently doesn’t (almost) implement rebalance. Without rebalance, the meaning and behavior of STOP is irrelevant because drivers don’t ever see a STOP.

Finally, if you want a simple answer to a simple question: “Is _STOP_DEVICE an request to
implicitly power down your device?” The simple answer is “Yes.”

Are you sure? I mean: I know who you are, your level of knowledge, your close relation to Ms, etc. But that answer seems to contradict the latest recommendations from the PCI and PNP teams. See the WHDC PCI multilevel rebalance article, or the WINHEC presentation. It clearly says to *not* power down the device on STOP. And I think I explained well enough why this makes sense. And Once again, the PCI bus driver (at least on XP) doesn’t power down the card on STOP.

As folks have alluded to earlier in this thread, it took some *very* smart people more than an
elapsed year to get the integrated PnP/Power state machine built for KMDF. And this is working
WITH the Windows source code, and the devs responsible for PnP/Power in Windows.

I sense from your (and others ones) reaction that some people see on this some kind of attack against KMDF. Absolutely not, I think KDMF is great. I have no doubts whatsoever about the level of people that designed and developed KMDF. People like Doron and Eliyas (to name the ones I know) have proved more than once their caliber. Further, I’m extremely grateful for their very valuable help in many occasions. I’m also sure that the core Pnp/Pm teams were involved.

This doesn’t mean they couldn’t have made a mistake. It doesn’t mean they couldn’t have missed something. Honestly, I don’t understand why pointing a mistake (disregarding if I’m right or wrong) is taken as a negative attitude. And if I am right, this doesn’t mean at all I am smarter than them. What I think it happened is that I am looking at this with “fresh new eyes”.

If somebody disagrees with my technical arguments (about why STOP shouldn’t be an implicit power, and why a subsequent START should not be an implicit power-up) then please let’s stay at the technical level. I didn’t see yet any technical reply, except perhaps Don Burn’s one.

And BTW Don, I forgot to add then, that relying on your device to be actually powered down is not exactly playing safe. Even if the bus driver (or whoever should do it) would agree to power down the device on STOP (which doesn’t seem to be the case), it still doesn’t mean it could actually do it. As you know, powering down a single device is not always guaranteed.

11

You are microoptimizing rebalance, focusing on how long it would take in
your scheme vs one where there is an implicit power change. The problem
with rebalance has nothing to do really with how long it takes vs the
fact that most drivers do not properly handle it today (outside of a
KMDF driver or other msft provided port drivers). Furthermore, you are
not looking at the time it takes to do the following (in kmdf terms)
which must be done during stop compared to the time it takes to power
off the hardware after all of these tasks are completed

1 Stop and wait for self managed io (watch dog timers, etc)
2 In flight I/Os that are touching hardware
3 Stopping your dma engine
4 Miscellaneous disabling of your hardware state
5 Disconnecting your interrupt, draining DPCs for ISR

These tasks will take much longer than the final step of an implicit
power change (if you are the bus driver, as the FDO, there is no hw
state change).
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rahul.net
Sent: Tuesday, May 29, 2007 1:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRP_MN_START_DEVICE and IRP_MN_STOP_DEVICE semantics

Tim Roberts wrote:

I’m not sure I fully understand what you are arguing. Are you
suggesting that a driver should tell its device to power up when it
receives IRP_MN_START_DEVICE and power down when it receives
IRP_MN_STOP_DEVICE?

I mean that STOP and a *subsequent* START should not imply any change
whatsoever to the current power state (why it should?). STOP should not
mean much more than just pause I/O because the assigned I/O resources
could be changed. And the *subsequent* START should mean only that I/O
can continue with the new assigned resources.

Note again the difference between a (subsequent) START following a STOP
and the initial one after AddDevice.

If the device was already powered down (because you are implementing
idle detection), then it doesn’t make much sense to power it up just for
reassigning resources. And if it is powered on, then there is no need to
power cycle it.

The whole point is that a rebalance would be a much more frequent and
common operation in the future. Then it should be done as quickly as
possible (read, without a power cycle which could be very expensive).

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

12

Saying that pnp doesn’t work b/c stop is not sent regularly is a bit
misguided. For the most part, there are not a lot of cases where a
rebalance is necessary after the machine has booted, esp on a desktop
machine w/no cardbus slots. Not to say that it does not happen
regularly on other platforms (such servers with hotplug pci), but just
b/c one aspect of pnp is rare does not mean that all of it doesn’t work.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rahul.net
Sent: Tuesday, May 29, 2007 2:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRP_MN_START_DEVICE and IRP_MN_STOP_DEVICE semantics

Hi Peter,

OP: If your point is that the PnP and power state machines in Windows
are poorly documented…
You’re surprised, and just a bit peaved it seems, …

I apologize if I sounded as too negative and too complaining. That
wasn’t my intention at all. I do realize about the impossibility of
documenting everything (let alone, clearly and precisely) in the WDK,
and I do know about the historical and compatibility complications.

So, yeah… PnP/Power is implemented ugly. But it does work.

I beg to differ, I’m not sure you can say that this specific Pnp aspect
does work. Windows currently doesn’t (almost) implement rebalance.
Without rebalance, the meaning and behavior of STOP is irrelevant
because drivers don’t ever see a STOP.

Finally, if you want a simple answer to a simple question: “Is
_STOP_DEVICE an request to
implicitly power down your device?” The simple answer is “Yes.”

Are you sure? I mean: I know who you are, your level of knowledge, your
close relation to Ms, etc. But that answer seems to contradict the
latest recommendations from the PCI and PNP teams. See the WHDC PCI
multilevel rebalance article, or the WINHEC presentation. It clearly
says to *not* power down the device on STOP. And I think I explained
well enough why this makes sense. And Once again, the PCI bus driver (at
least on XP) doesn’t power down the card on STOP.

As folks have alluded to earlier in this thread, it took some *very*
smart people more than an
elapsed year to get the integrated PnP/Power state machine built for
KMDF. And this is working
WITH the Windows source code, and the devs responsible for PnP/Power
in Windows.

I sense from your (and others ones) reaction that some people see on
this some kind of attack against KMDF. Absolutely not, I think KDMF is
great. I have no doubts whatsoever about the level of people that
designed and developed KMDF. People like Doron and Eliyas (to name the
ones I know) have proved more than once their caliber. Further, I’m
extremely grateful for their very valuable help in many occasions. I’m
also sure that the core Pnp/Pm teams were involved.

This doesn’t mean they couldn’t have made a mistake. It doesn’t mean
they couldn’t have missed something. Honestly, I don’t understand why
pointing a mistake (disregarding if I’m right or wrong) is taken as a
negative attitude. And if I am right, this doesn’t mean at all I am
smarter than them. What I think it happened is that I am looking at this
with “fresh new eyes”.

If somebody disagrees with my technical arguments (about why STOP
shouldn’t be an implicit power, and why a subsequent START should not be
an implicit power-up) then please let’s stay at the technical level. I
didn’t see yet any technical reply, except perhaps Don Burn’s one.

And BTW Don, I forgot to add then, that relying on your device to be
actually powered down is not exactly playing safe. Even if the bus
driver (or whoever should do it) would agree to power down the device on
STOP (which doesn’t seem to be the case), it still doesn’t mean it could
actually do it. As you know, powering down a single device is not always
guaranteed.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

13

xxxxx@rahul.net wrote:

Are you sure? I mean: I know who you are, your level of knowledge, your close relation to Ms, etc. But that answer seems to contradict the latest recommendations from the PCI and PNP teams. See the WHDC PCI multilevel rebalance article, or the WINHEC presentation. It clearly says to *not* power down the device on STOP. And I think I explained well enough why this makes sense. And Once again, the PCI bus driver (at least on XP) doesn’t power down the card on STOP.

How could it? How could the PCI bus driver possibly know enough about
my device to kill its power? The only driver that can power down my
device is MY driver. Now, the bus driver could conceivably fire off a
power IRP ASKING me to kill my power, after it receives my STOP_DEVICE
IRP, but that wouldn’t be a PnP decision.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

14

Doron Holan wrote:

You are microoptimizing rebalance, focusing on how long it would take in
your scheme vs one where there is an implicit power change…
Furthermore, you are
not looking at the time it takes to do the following (in kmdf terms)
which must be done during stop compared to the time it takes to power
off the hardware after all of these tasks are completed
…
These tasks will take much longer than the final step of an implicit
power change (if you are the bus driver, as the FDO, there is no hw state change).

I beg to differ. Saving and restoring full hardware context might take (depending on the case) much longer than all the other tasks.

But the main problem is not the processing time in the driver because of the implicit power state change. The main problem is the actual physical power-cycle of the device. All the tasks you mention are nothing in comparison to the consequences of a power-cycle for some devices. Spin-down and spin-up, on-board OS reboot, loss of on-board cache, warm-up, firmware upload, FPGA configure, loss of routing tables, power spike, etc, etc.

Further, an indirect consequence is that drivers might veto the STOP (if it implies a power-down), then affecting the possibilities of the Pnp manager realizing a rebalance.

And once again, the most important issue is perhaps consistent system behavior. So if Microsoft decides that a STOP is an implicit power-down, then so be it no matter what I believe it is correct or not. But then in-box bus drivers should follow the rule (currently doesn’t seem to be the case).

The problem with rebalance has nothing to do really with how long it takes vs the
fact that most drivers do not properly handle it today (outside of a
KMDF driver or other msft provided port drivers).

I know, and I think I mentioned that in my original post. To be honest, I am not sure the problem is on third party drivers only. I’m not sure in-box drivers like, storage class, serial and floppy drivers are ready for a rebalance. For sure the in-box serial driver is not handling it correctly. But it is mostly academic in this case because it will veto a QUERY STOP when the device is opened.

Saying that pnp doesn’t work b/c stop is not sent regularly is a bit
misguided.

Sorry for not being clear. I didn’t mean that PNP doesn’t work, of course it does. What I meant is that PNP rebalance doesn’t work very well. Or that at least we don’t yet how well it works.

15

Tim Roberts wrote:

How could it? How could the PCI bus driver possibly know enough about
my device to kill its power? The only driver that can power down my
device is MY driver. Now, the bus driver could conceivably fire off a
power IRP ASKING me to kill my power, after it receives my STOP_DEVICE
IRP, but that wouldn’t be a PnP decision.

Well, that is what would happen in the implicit power-down model.

If you would rewrite the PCI bus driver using KMDF (yeah, I know you won’t), then it will power-down your card *automatically* upon receiving an IRP_MN_STOP_DEVICE Irp. It won’t ask you or send any QUERY or SET power Irps. It would assume that if you didn’t fail the Pnp QUERY_STOP, then you agreed to power down.

16

Tim Roberts wrote:

How could it? How could the PCI bus driver possibly know enough about
my device to kill its power?

I just realized you might be talking about something completely different. Are you asking how technically and physically the PCI bus driver can power down your PCI card? If so, yes, the PCI bus driver knows about this much more than the function driver.

It involves the configuration space (which is a bus driver realm anyway) to put the card in the state known as D3hot. Or it involves motherboard resources with ACPI help to put the card in the D3cold state.

You (the function driver) never physically power-down (or up) the card by yourself, you always ask the PCI bus driver to do it.

17

>5 Disconnecting your interrupt, draining DPCs for ISR

I think the classic WDM driver never disconnected the interrupt on powering
down. Disabling the interrupt in hardware-specific way - yes, but
IoDisconnectInterrupt?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

18

Yes, this is one area where KMDF pushes the envelope (for power pageable
devices at least). We disconnect the interrupt as a preventative
measure against interrupt storms. If there are no connected interrupt
sw interrupt handlers, the likelyhood of a storm is lower since there is
no one there to listen ;). On a pnp stop you definitely have to
disconnect the interrupt though since the assignment can change on
restart.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Tuesday, May 29, 2007 8:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRP_MN_START_DEVICE and IRP_MN_STOP_DEVICE semantics

5 Disconnecting your interrupt, draining DPCs for ISR

I think the classic WDM driver never disconnected the interrupt on
powering
down. Disabling the interrupt in hardware-specific way - yes, but
IoDisconnectInterrupt?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

19

Hi Ijor,

I don’t see anyone taking it that way. Question orthodoxy! This is good.

I think we’re ALL trying to give you technical answers. But these are not just “black and white”…

Like most good engineering answers, the answer to the question “Should *I* power down *my device* when I get a _STOP_DEVICE” must be “it depends.”

I’d say that the short, safe, simple, answer is “yes.” You really can’t go wrong powering down your device. Might take longer. Might not. Might not matter. But unmap your mappings, disable and disconnect your interrupt, return your resources, and power it down. All will be good with the world. No harm done.

If you know better *for your device* then, by all means DON’T power down your device when you get a _STOP_DEVICE.

This is precisely why WDM lets you take these decisions. Like we always say about PnP/Power in WDM: “The good news is that drivers get to be intimately involved in the PnP/Power management process. The bad news is that drivers get to be intimately involved in the PnP/Power management process.”

The PROBLEM is that most driver devs – do to lack of knowledge, training, time, hardware information, testing, or DDK documentation – don’t really seem to be in a position to make the tradeoff.

So… I’m not sure what the issue is, if any: SHOULD the DDK docs be better? Duh!! I don’t know ANYbody who doesn’t think that everything in the DDK doc set except the UMDF and KMDF docs (which were only recently completed) would benefit by a major re-write from square zero. Will this happen? Common sense would say it’s not really likely. But, again, perhaps the real issue is the inherent complexity of the problem. Can you imagine DDK docs that said “when you get a _STOP_DEVICE use your engineering judgement as to how to proceed”???

Now, do we need a really good BOOK that discusses all these issues? Yeah, we do. I’m hoping that’s what the next MS Press book on Windows driver development will contain.

Peter
OSR

20

Hi Peter,

Peter Viscarola (OSR) wrote:

I think we’re ALL trying to give you technical answers. But these are not just “black and white”…

Like most good engineering answers, the answer to the question “Should *I* power down *my
device* when I get a _STOP_DEVICE” must be “it depends.”
…
If you know better *for your device* then, by all means DON’T power down your device when
you get a _STOP_DEVICE. This is precisely why WDM lets you take these decisions

I’m not sure you got my point. And it is probably all my fault that I didn’t explain myself good enough. At the risk of being redundant, would try to make myself clear.

I’m not asking a technical question, at least not that question. The question I am asking is not technical. And the technical issues I am raising are not exactly questions, they are (modestly) comments and recommendations.

It is obvious that the technical answer to the question “Should I power-down my device on STOP”, is “it depends”. And I already know what is better in my specific case. So I am not asking that.

What I am asking is: “Should I expect that future versions of the in-box PCI bus driver will power-down my device on STOP automatically?”. That seems an odd idea to most people here, but that is the KMDF model. Again, a KMDF bus driver would do exactly that. It would power-down the device on STOP. And it would do it *without* asking the function driver.

I am not worried too much about the KMDF behavior. Right or wrong, the practical implications are not too important. They are not too important because I can use classic WDM for my function driver if I need to. And because nobody is actually going to write a third party PCI bus driver using KMDF.

So my main concern is if the KMDF model would be applied to the whole Pnp system. Then indeed a future PCI driver might implement the same behavior. I guess nobody here knows the answer. And I would guess that not even the Pnp devs know for sure. They might know what is technically better, but the compatibility implications might be more important than anything else.

Then I am making two technical *comments*. One is that I believe that a STOP should not be considered an automatic/implicit power-down. This should be decided by the function driver and Power Policy Owner, not by the bus driver or by the Pnp model. Currently, this is the actual behavior of the PCI bus driver.

The other comment is that a *subsequent* Pnp START should not be considered an implicit power-up. I don’t see any sense whatsoever in powering-up a device (if it was powered down for idle reasons), just for the purpose of rebalance. This is perhaps the most important comment, because everybody (including in-box function and bus drivers) do assume an implicit power-up on *every* START, not just the initial one.

In essence, I am saying that a Pnp STOP and the subsequent (not the initial one) START should not imply any change *whatsoever* to the current device power state. Not without an explicit request by the Power Policy Owner.