A quick update on this. There is a subtle race condition in this
callback between its invocation and the actual Sx irp coming to your
driver. Since the callback is called before the PnP device tree lock is
held, you have a window where your driver can load after the callback
has been called and before the tree is locked. If you selectively
suspend in this window, you will not receive a callback to indicate that
you should cancel selective suspend and move into D0. What this means
to me is either
- you ignore the problem and say that the device will never be plugged
in right when the machine is going into Sx
Or
- you use the actual Sx irp as the indication to cancel the selective
suspend request, bring your device into D0, and then into the
appropriate Dx state based on the indicated Sx state.
For WDF, I can’t choose 1) since I can’t generically make that statement
for all drivers. I have chosen 2) since I can handle its drawbacks (it
can come at dispatch level, it can come after the paging device is off
so you can’t cause paging i/o, etc).
Thx
d
-----Original Message-----
From: Doron Holan
Sent: Friday, September 03, 2004 2:22 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 StateLet 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 GroupThis 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
