IRP_MN_QUERY_POWER for a System Power State

Michal_Vodicka-2 · September 1, 2004, 10:50pm

Once my driver receive this IRP which queries for S0 -> Sx transition, it has to perform some actions which should be reverted on Sx -> S0 transition. However, some other driver can refuse query and system remains in S0 state. DDK docs states Power Manager typically sends IRP_MN_SET_POWER IRP to reaffirm S0. I’m uncertain if I can depend on it. My question is: will be IRP_MN_QUERY_POWER for S0 -> S[1-4]always followed by IRP_MN_SET_POWER for Sx -> S0? Presume system is powered up from lower Sx states sooner or later.

What I’m trying to solve are race conditions with selective suspend. It is disabled on mentioned query and has to be reenabled later. If query is refused by some other driver and there isn’t reaffirmation IRP, our device would stay powered and drain batteries. Please don’t tell me about timer, I have it already there because code is originated from DDK sample and it is nightmare.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · September 2, 2004, 1:05am

You should get the S0 IIRC on a failed attempt to go to Sx, but WDF uses
a callback object to basically do the same thing. A bit easier to
handle the async part as well.

You want to create one via ExCreateCallback w/a specific name, see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/
hh/kmarch/k104_1e38a631-7e65-4b4b-8d51-3150a8073511.xml.asp

and then register it, ExRegisterCallback, see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/
hh/kmarch/k102_db841434-fe00-448d-b5bb-2c35d1ad0ec4.xml.asp

You will get called when the system is going to Sx and when it moves
back into S0.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, September 01, 2004 7:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Once my driver receive this IRP which queries for S0 -> Sx transition,
it has to perform some actions which should be reverted on Sx -> S0
transition. However, some other driver can refuse query and system
remains in S0 state. DDK docs states Power Manager typically sends
IRP_MN_SET_POWER IRP to reaffirm S0. I’m uncertain if I can depend on
it. My question is: will be IRP_MN_QUERY_POWER for S0 -> S[1-4]always
followed by IRP_MN_SET_POWER for Sx -> S0? Presume system is powered up
from lower Sx states sooner or later.

What I’m trying to solve are race conditions with selective suspend. It
is disabled on mentioned query and has to be reenabled later. If query
is refused by some other driver and there isn’t reaffirmation IRP, our
device would stay powered and drain batteries. Please don’t tell me
about timer, I have it already there because code is originated from DDK
sample and it is nightmare.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Maxim_S_Shatskih · September 2, 2004, 7:26am

After Sn QUERY power IRP, the following can occur:

S0 QUERY (means a veto imposed by some other component and undoing of
hibernation)
Sn SET
Sm SET with m != n (for “forced” hibernate)

So, do not rely on QUERY IRP to do anything except possible veto
imposition, as KBDCLASS behaves.

Do the real things in a SET IRP, it cannot be cancelled midway.

And surely, the system power IRP is just a conceptual “input” to the policy
power owner code. The PPO must issue the device SET IRP as a result, and the
real work must be done in device power path.
Synchronizing the selective suspend and the system shutdown/standby is up
to your PPO.

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

----- Original Message -----
From: “Michal Vodicka”
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 02, 2004 6:48 AM
Subject: [ntdev] IRP_MN_QUERY_POWER for a System Power State

> Once my driver receive this IRP which queries for S0 -> Sx transition, it has
to perform some actions which should be reverted on Sx -> S0 transition.
However, some other driver can refuse query and system remains in S0 state. DDK
docs states Power Manager typically sends IRP_MN_SET_POWER IRP to reaffirm S0.
I’m uncertain if I can depend on it. My question is: will be IRP_MN_QUERY_POWER
for S0 -> S[1-4]always followed by IRP_MN_SET_POWER for Sx -> S0? Presume
system is powered up from lower Sx states sooner or later.
>
> What I’m trying to solve are race conditions with selective suspend. It is
disabled on mentioned query and has to be reenabled later. If query is refused
by some other driver and there isn’t reaffirmation IRP, our device would stay
powered and drain batteries. Please don’t tell me about timer, I have it
already there because code is originated from DDK sample and it is nightmare.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · September 2, 2004, 12:04pm

Furthermore, you can get an Sx irp w/out a query if the machine is low
on batteries.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, September 02, 2004 4:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRP_MN_QUERY_POWER for a System Power State

After Sn QUERY power IRP, the following can occur:

S0 QUERY (means a veto imposed by some other component and undoing
of
hibernation)
Sn SET
Sm SET with m != n (for “forced” hibernate)

So, do not rely on QUERY IRP to do anything except possible veto
imposition, as KBDCLASS behaves.

Do the real things in a SET IRP, it cannot be cancelled midway.

And surely, the system power IRP is just a conceptual “input” to the
policy
power owner code. The PPO must issue the device SET IRP as a result, and
the
real work must be done in device power path.
Synchronizing the selective suspend and the system shutdown/standby
is up
to your PPO.

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

----- Original Message -----
From: “Michal Vodicka”
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 02, 2004 6:48 AM
Subject: [ntdev] IRP_MN_QUERY_POWER for a System Power State

> Once my driver receive this IRP which queries for S0 -> Sx transition,
it has
to perform some actions which should be reverted on Sx -> S0 transition.
However, some other driver can refuse query and system remains in S0
state. DDK
docs states Power Manager typically sends IRP_MN_SET_POWER IRP to
reaffirm S0.
I’m uncertain if I can depend on it. My question is: will be
IRP_MN_QUERY_POWER
for S0 -> S[1-4]always followed by IRP_MN_SET_POWER for Sx -> S0?
Presume
system is powered up from lower Sx states sooner or later.
>
> What I’m trying to solve are race conditions with selective suspend.
It is
disabled on mentioned query and has to be reenabled later. If query is
refused
by some other driver and there isn’t reaffirmation IRP, our device would
stay
powered and drain batteries. Please don’t tell me about timer, I have it
already there because code is originated from DDK sample and it is
nightmare.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · September 2, 2004, 3:11pm

Callback idea is interesting but it seems as callback could be called at DISPATCH_LEVEL, too. From docs it is unclear if it can occur also for \Callback\PowerState. It would be a problem because I have to wait somewhere until selective suspend is really cancelled to avoid race conditions.

As for WDF, I examined DDK 3790.1218 and it seems as under re-construction and not feasible for immediate use. The only USB sample doesn’t contain selective suspend related code (commented out). Maybe sometimes in the future but I need reliable driver just now. BTW, do you plan to release WDF sources when it is final? Without them I would hesitate to use it.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 7:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

You should get the S0 IIRC on a failed attempt to go to Sx, but WDF uses
a callback object to basically do the same thing. A bit easier to
handle the async part as well.

You want to create one via ExCreateCallback w/a specific name, see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/
hh/kmarch/k104_1e38a631-7e65-4b4b-8d51-3150a8073511.xml.asp

and then register it, ExRegisterCallback, see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/
hh/kmarch/k102_db841434-fe00-448d-b5bb-2c35d1ad0ec4.xml.asp

You will get called when the system is going to Sx and when it moves
back into S0.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, September 01, 2004 7:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Once my driver receive this IRP which queries for S0 -> Sx transition,
it has to perform some actions which should be reverted on Sx -> S0
transition. However, some other driver can refuse query and system
remains in S0 state. DDK docs states Power Manager typically sends
IRP_MN_SET_POWER IRP to reaffirm S0. I’m uncertain if I can depend on
it. My question is: will be IRP_MN_QUERY_POWER for S0 -> S[1-4]always
followed by IRP_MN_SET_POWER for Sx -> S0? Presume system is powered up
from lower Sx states sooner or later.

What I’m trying to solve are race conditions with selective suspend. It
is disabled on mentioned query and has to be reenabled later. If query
is refused by some other driver and there isn’t reaffirmation IRP, our
device would stay powered and drain batteries. Please don’t tell me
about timer, I have it already there because code is originated from DDK
sample and it is nightmare.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · September 2, 2004, 3:18pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 1:26 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRP_MN_QUERY_POWER for a System Power State

And surely, the system power IRP is just a conceptual “input” to the policy
power owner code. The PPO must issue the device SET IRP as a result, and the
real work must be done in device power path.

Yes, but the problem is I can’t wait for selective suspend finish (cancel, completion) in device power path because of possible deadlock. And the wait is necessary because of race conditions. However, maybe there isn’t a deadlock in system power IRP path; I’ll examine it.

Synchronizing the selective suspend and the system shutdown/standby is up
to your PPO.

My driver is PPO and it is what I’m trying to solve. There is a lot of race conditions and deadlock possibilities when selective suspend comes into play. Especially with XP SP2.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · September 2, 2004, 3:28pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 6:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Furthermore, you can get an Sx irp w/out a query if the machine is low
on batteries.

I’m aware about it. Just curious: which Sx I can get in this state? S5?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · September 2, 2004, 3:39pm

This callback is definitely called only at passive level. WDF relies on
this for the very reasons I am recommending it to you. (The storage
stack relies on this to mark PAGEable code as non paged as well.) You
can block until your have cleared out of the selective suspend state.
Blocking in your callback will block the transition to Sx until you
return.

Yes, WDF is still in beta. I am not recommending that you use it now
for your driver. I am just saying that WDF uses the methods I am
recommending for the same task. USB SS support in WDF is implemented
and in the build, but no public sample uses it yet (we don’t have any
generic hardware to demonstrate it on). All you need to do to enable it
is call WdfDeviceAssignS0IdleSettings with an IdleCaps of
IdleUsbSelectiveSuspend.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, September 02, 2004 12:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Callback idea is interesting but it seems as callback could be called at
DISPATCH_LEVEL, too. From docs it is unclear if it can occur also for
\Callback\PowerState. It would be a problem because I have to wait
somewhere until selective suspend is really cancelled to avoid race
conditions.

As for WDF, I examined DDK 3790.1218 and it seems as under
re-construction and not feasible for immediate use. The only USB sample
doesn’t contain selective suspend related code (commented out). Maybe
sometimes in the future but I need reliable driver just now. BTW, do you
plan to release WDF sources when it is final? Without them I would
hesitate to use it.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 7:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

You should get the S0 IIRC on a failed attempt to go to Sx, but WDF
uses
a callback object to basically do the same thing. A bit easier to
handle the async part as well.

You want to create one via ExCreateCallback w/a specific name, see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/

hh/kmarch/k104_1e38a631-7e65-4b4b-8d51-3150a8073511.xml.asp

and then register it, ExRegisterCallback, see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/

hh/kmarch/k102_db841434-fe00-448d-b5bb-2c35d1ad0ec4.xml.asp

You will get called when the system is going to Sx and when it moves
back into S0.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, September 01, 2004 7:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Once my driver receive this IRP which queries for S0 -> Sx transition,
it has to perform some actions which should be reverted on Sx -> S0
transition. However, some other driver can refuse query and system
remains in S0 state. DDK docs states Power Manager typically sends
IRP_MN_SET_POWER IRP to reaffirm S0. I’m uncertain if I can depend on
it. My question is: will be IRP_MN_QUERY_POWER for S0 -> S[1-4]always
followed by IRP_MN_SET_POWER for Sx -> S0? Presume system is powered
up
from lower Sx states sooner or later.

What I’m trying to solve are race conditions with selective suspend.
It
is disabled on mentioned query and has to be reenabled later. If query
is refused by some other driver and there isn’t reaffirmation IRP, our
device would stay powered and drain batteries. Please don’t tell me
about timer, I have it already there because code is originated from
DDK
sample and it is nightmare.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · September 2, 2004, 3:40pm

I don’t know, but I wouldn’t rely on an particular value, just the fact
that you will get an Sx irp without a query. If you use the Ex callback
will be called in this state.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, September 02, 2004 12:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 6:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Furthermore, you can get an Sx irp w/out a query if the machine is low
on batteries.

I’m aware about it. Just curious: which Sx I can get in this state? S5?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · September 2, 2004, 4:04pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 9:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

This callback is definitely called only at passive level. WDF relies on
this for the very reasons I am recommending it to you. (The storage
stack relies on this to mark PAGEable code as non paged as well.) You
can block until your have cleared out of the selective suspend state.
Blocking in your callback will block the transition to Sx until you
return.

Seems really promising. One more question: who calls the callback and in which context? Is it called just before system power IRP is sent or later? I’m still affraid about deadlock, I saw too many in past months.

Yes, WDF is still in beta. I am not recommending that you use it now
for your driver. I am just saying that WDF uses the methods I am
recommending for the same task.

I comprehended it It was just a comment because I was pondering to rewrite my driver using WDF and decided it is too soon.

USB SS support in WDF is implemented
and in the build, but no public sample uses it yet (we don’t have any
generic hardware to demonstrate it on). All you need to do to enable it
is call WdfDeviceAssignS0IdleSettings with an IdleCaps of
IdleUsbSelectiveSuspend.

In other words, it wasn’t tested with real hardware One more reason to see sources. Don’t take me wrong: my driver is currently based on BulkUsb sample and I really rerget I used it. Too many problems with real device and high stress conditions. I mean really high stress, much higher than HCT tests produce. Driver was successfully signed several times and there are still deadlock possibilities. It is hard to fix such issues when base design is bad.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · September 2, 2004, 4:22pm

No, I never said I didn’t have real hardware. I said I didn’t have a
public sample. I have a private test driver that test usb ss. The issue
is that a public sample needs to have readily available hardware that it
isn’t proprietary. I have something in the works, but nothing public
yet. The code is tested.

The Po subsystem calls the callback. It gets called before you move
into Sx and after you have returned into S0. You will not see a S power
irp while this callback is being made.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, September 02, 2004 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 9:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

This callback is definitely called only at passive level. WDF relies
on
this for the very reasons I am recommending it to you. (The storage
stack relies on this to mark PAGEable code as non paged as well.) You
can block until your have cleared out of the selective suspend state.
Blocking in your callback will block the transition to Sx until you
return.

Seems really promising. One more question: who calls the callback and in
which context? Is it called just before system power IRP is sent or
later? I’m still affraid about deadlock, I saw too many in past months.

Yes, WDF is still in beta. I am not recommending that you use it now
for your driver. I am just saying that WDF uses the methods I am
recommending for the same task.

I comprehended it It was just a comment because I was pondering to
rewrite my driver using WDF and decided it is too soon.

USB SS support in WDF is implemented
and in the build, but no public sample uses it yet (we don’t have any
generic hardware to demonstrate it on). All you need to do to enable
it
is call WdfDeviceAssignS0IdleSettings with an IdleCaps of
IdleUsbSelectiveSuspend.

In other words, it wasn’t tested with real hardware One more reason
to see sources. Don’t take me wrong: my driver is currently based on
BulkUsb sample and I really rerget I used it. Too many problems with
real device and high stress conditions. I mean really high stress, much
higher than HCT tests produce. Driver was successfully signed several
times and there are still deadlock possibilities. It is hard to fix such
issues when base design is bad.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · September 2, 2004, 4:40pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 10:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

The Po subsystem calls the callback. It gets called before you move
into Sx and after you have returned into S0. You will not see a S power
irp while this callback is being made.

Thanks, you convinced me to try it. The scenario I’m affraid of is following:

power state callback is called because of S0 -> Sx
called code tries to cancel selective suspend and waits until it finishes
cancel attempt is too late and idle callback is called before. It wins races (handled correctly) and sends D2 IRP
idle callback waits until D2 request is finished and then signals an event for which is SS cancel code waiting

If D2 is blocked for some reason, there is a deadlock. Is there any possibility it is blocked when power state callback is called? In Po subsystem or USB stack with XP SP2 changes. It seems as there should be no reason to block but I want to be sure.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · September 2, 2004, 4:53pm

The Po subsystem won’t block it. It allows d irps at any time (of
course, if there is a D irp already in the stack, the D0 irp will get
queued until the in stack D irp completes). What you described is
pretty much how WDF works and I have tested this on xp sp2 and it worked
just fine.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, September 02, 2004 1:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2004 10:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

The Po subsystem calls the callback. It gets called before you move
into Sx and after you have returned into S0. You will not see a S
power
irp while this callback is being made.

Thanks, you convinced me to try it. The scenario I’m affraid of is
following:

power state callback is called because of S0 -> Sx
called code tries to cancel selective suspend and waits until it
finishes
cancel attempt is too late and idle callback is called before. It wins
races (handled correctly) and sends D2 IRP
idle callback waits until D2 request is finished and then signals an
event for which is SS cancel code waiting

If D2 is blocked for some reason, there is a deadlock. Is there any
possibility it is blocked when power state callback is called? In Po
subsystem or USB stack with XP SP2 changes. It seems as there should be
no reason to block but I want to be sure.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Jake_Oshins · September 3, 2004, 1:27pm

Actually, you could get any S-state here. It just depends on what you set
your battery-critical policy for in the control panel.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I don’t know, but I wouldn’t rely on an particular value, just the fact
that you will get an Sx irp without a query. If you use the Ex callback
will be called in this state.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, September 02, 2004 12:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, September 02, 2004 6:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
>
> Furthermore, you can get an Sx irp w/out a query if the machine is low
> on batteries.
>
I’m aware about it. Just curious: which Sx I can get in this state? S5?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Jake_Oshins · September 3, 2004, 1:32pm

Let me amplify what Doron is saying here.

The power state callback is called *before* the Power manager calls into the
PnP manager and locks the PnP tree, which is *before* the Power manager
starts sending any S-state IRPs.

The power state callback was created specifically so that you could be
guaranteed that you could do pageable, blockable operations as part of a
system power state transition, even if your driver has to clear
DO_POWER_PAGABLE.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The Po subsystem won’t block it. It allows d irps at any time (of
course, if there is a D irp already in the stack, the D0 irp will get
queued until the in stack D irp completes). What you described is
pretty much how WDF works and I have tested this on xp sp2 and it worked
just fine.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, September 02, 2004 1:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, September 02, 2004 10:18 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
>
> The Po subsystem calls the callback. It gets called before you move
> into Sx and after you have returned into S0. You will not see a S
power
> irp while this callback is being made.
>
Thanks, you convinced me to try it. The scenario I’m affraid of is
following:

- power state callback is called because of S0 -> Sx
- called code tries to cancel selective suspend and waits until it
finishes
- cancel attempt is too late and idle callback is called before. It wins
races (handled correctly) and sends D2 IRP
- idle callback waits until D2 request is finished and then signals an
event for which is SS cancel code waiting

If D2 is blocked for some reason, there is a deadlock. Is there any
possibility it is blocked when power state callback is called? In Po
subsystem or USB stack with XP SP2 changes. It seems as there should be
no reason to block but I want to be sure.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · September 3, 2004, 4:54pm

Thank you. I already implemented it and it seems as optimal solution. Callback is called before Sx query IRP is sent and is called again to reaffirm S0 even if some driver vetoes query. I hope number of registered callbacks isn’t limited as I register one per device; it is easier.

The only minor drawback when used for selective suspend cancellation is that if device is already suspended, it has to be awakened there (D2 -> D0) even if following S0 -> Sx transition puts it back to D2.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jake Oshins[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, September 03, 2004 7:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRP_MN_QUERY_POWER for a System Power State

Let me amplify what Doron is saying here.

The power state callback is called *before* the Power manager calls into the
PnP manager and locks the PnP tree, which is *before* the Power manager
starts sending any S-state IRPs.

The power state callback was created specifically so that you could be
guaranteed that you could do pageable, blockable operations as part of a
system power state transition, even if your driver has to clear
DO_POWER_PAGABLE.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Doron Holan” wrote in message
> news:xxxxx@ntdev…
> The Po subsystem won’t block it. It allows d irps at any time (of
> course, if there is a D irp already in the stack, the D0 irp will get
> queued until the in stack D irp completes). What you described is
> pretty much how WDF works and I have tested this on xp sp2 and it worked
> just fine.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Thursday, September 02, 2004 1:39 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
>
> > ----------
> > From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
>] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Thursday, September 02, 2004 10:18 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
> >
> > The Po subsystem calls the callback. It gets called before you move
> > into Sx and after you have returned into S0. You will not see a S
> power
> > irp while this callback is being made.
> >
> Thanks, you convinced me to try it. The scenario I’m affraid of is
> following:
>
> - power state callback is called because of S0 -> Sx
> - called code tries to cancel selective suspend and waits until it
> finishes
> - cancel attempt is too late and idle callback is called before. It wins
> races (handled correctly) and sends D2 IRP
> - idle callback waits until D2 request is finished and then signals an
> event for which is SS cancel code waiting
>
> If D2 is blocked for some reason, there is a deadlock. Is there any
> possibility it is blocked when power state callback is called? In Po
> subsystem or USB stack with XP SP2 changes. It seems as there should be
> no reason to block but I want to be sure.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · September 3, 2004, 5:25pm

I wouldn’t consider having to move into D0 and then back into Dx a
drawback. This allows you to distinguish between arming for selective
suspend and arming for wake from Sx. The 2 reasons for arming could be
different. Or, if you don’t wake form Sx, you have to move into D3 and
you are not allowed to have a Dx -> Dx transition, so you have to move
D2 -> D0 -> D3 anyways.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, September 03, 2004 1:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Thank you. I already implemented it and it seems as optimal solution.
Callback is called before Sx query IRP is sent and is called again to
reaffirm S0 even if some driver vetoes query. I hope number of
registered callbacks isn’t limited as I register one per device; it is
easier.

The only minor drawback when used for selective suspend cancellation is
that if device is already suspended, it has to be awakened there (D2 ->
D0) even if following S0 -> Sx transition puts it back to D2.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Jake Oshins[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, September 03, 2004 7:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRP_MN_QUERY_POWER for a System Power State

Let me amplify what Doron is saying here.

The power state callback is called *before* the Power manager calls
into the
PnP manager and locks the PnP tree, which is *before* the Power
manager
starts sending any S-state IRPs.

The power state callback was created specifically so that you could be

guaranteed that you could do pageable, blockable operations as part of
a
system power state transition, even if your driver has to clear
DO_POWER_PAGABLE.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no
rights.

“Doron Holan” wrote in message
> news:xxxxx@ntdev…
> The Po subsystem won’t block it. It allows d irps at any time (of
> course, if there is a D irp already in the stack, the D0 irp will get
> queued until the in stack D irp completes). What you described is
> pretty much how WDF works and I have tested this on xp sp2 and it
worked
> just fine.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Thursday, September 02, 2004 1:39 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
>
> > ----------
> > From:
>
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
>] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Thursday, September 02, 2004 10:18 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
> >
> > The Po subsystem calls the callback. It gets called before you move
> > into Sx and after you have returned into S0. You will not see a S
> power
> > irp while this callback is being made.
> >
> Thanks, you convinced me to try it. The scenario I’m affraid of is
> following:
>
> - power state callback is called because of S0 -> Sx
> - called code tries to cancel selective suspend and waits until it
> finishes
> - cancel attempt is too late and idle callback is called before. It
wins
> races (handled correctly) and sends D2 IRP
> - idle callback waits until D2 request is finished and then signals an
> event for which is SS cancel code waiting
>
> If D2 is blocked for some reason, there is a deadlock. Is there any
> possibility it is blocked when power state callback is called? In Po
> subsystem or USB stack with XP SP2 changes. It seems as there should
be
> no reason to block but I want to be sure.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · September 3, 2004, 5:44pm

It depends on power configuration. We have customers with machines where D2 -> D0 -> D2 occurs on every suspend as both S1 and S3 are mapped to D2. I was able to avoid it using previous method but I don’t see it as a problem. OS suspend is relatively rare event and who cares about unnecessary device power transition.

I probably missed part of docs which states Dx -> Dx transitions are forbidden. From code samples I was under impression lowering as D2 -> D3 is allowed. BTW, recently I had race conditions which sometimes caused D3 -> D2 transition and the result was non-functional device. Only disable/enable device helped; D2 -> D0 wasn’t enough.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, September 03, 2004 11:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

I wouldn’t consider having to move into D0 and then back into Dx a
drawback. This allows you to distinguish between arming for selective
suspend and arming for wake from Sx. The 2 reasons for arming could be
different. Or, if you don’t wake form Sx, you have to move into D3 and
you are not allowed to have a Dx -> Dx transition, so you have to move
D2 -> D0 -> D3 anyways.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, September 03, 2004 1:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State

Thank you. I already implemented it and it seems as optimal solution.
Callback is called before Sx query IRP is sent and is called again to
reaffirm S0 even if some driver vetoes query. I hope number of
registered callbacks isn’t limited as I register one per device; it is
easier.

The only minor drawback when used for selective suspend cancellation is
that if device is already suspended, it has to be awakened there (D2 ->
D0) even if following S0 -> Sx transition puts it back to D2.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Jake Oshins[SMTP:xxxxx@windows.microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, September 03, 2004 7:30 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] IRP_MN_QUERY_POWER for a System Power State
>
> Let me amplify what Doron is saying here.
>
> The power state callback is called *before* the Power manager calls
into the
> PnP manager and locks the PnP tree, which is *before* the Power
manager
> starts sending any S-state IRPs.
>
> The power state callback was created specifically so that you could be

> guaranteed that you could do pageable, blockable operations as part of
a
> system power state transition, even if your driver has to clear
> DO_POWER_PAGABLE.
>
> –
> Jake Oshins
> Windows Kernel Group
>
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
>
> “Doron Holan” wrote in message
> > news:xxxxx@ntdev…
> > The Po subsystem won’t block it. It allows d irps at any time (of
> > course, if there is a D irp already in the stack, the D0 irp will get
> > queued until the in stack D irp completes). What you described is
> > pretty much how WDF works and I have tested this on xp sp2 and it
> worked
> > just fine.
> >
> > d
> >
> > -----Original Message----->
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> > Sent: Thursday, September 02, 2004 1:39 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
> >
> > > ----------
> > > From:
> >
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> >] on behalf of Doron Holan[SMTP:xxxxx@windows.microsoft.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Thursday, September 02, 2004 10:18 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] IRP_MN_QUERY_POWER for a System Power State
> > >
> > > The Po subsystem calls the callback. It gets called before you move
> > > into Sx and after you have returned into S0. You will not see a S
> > power
> > > irp while this callback is being made.
> > >
> > Thanks, you convinced me to try it. The scenario I’m affraid of is
> > following:
> >
> > - power state callback is called because of S0 -> Sx
> > - called code tries to cancel selective suspend and waits until it
> > finishes
> > - cancel attempt is too late and idle callback is called before. It
> wins
> > races (handled correctly) and sends D2 IRP
> > - idle callback waits until D2 request is finished and then signals an
> > event for which is SS cancel code waiting
> >
> > If D2 is blocked for some reason, there is a deadlock. Is there any
> > possibility it is blocked when power state callback is called? In Po
> > subsystem or USB stack with XP SP2 changes. It seems as there should
> be
> > no reason to block but I want to be sure.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com>
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@upek.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>