Re: IoSkipCurrentIrpStackLocation() design flaw?

From what I remember on storage ports behavior - even in Vista - the disk
is spinned up (powered up to D0) _at any IO request_ if the disk's previous
state was not D0.

I don't even think that the storage port's PPO logic respond to the system
powerup IRP to S0. "For what? The disk will be powered up if the real IO will
touch it" - this logic.

So, the system powerup IRP is out of picture, and we only have 3 potential
racing subjects - a) IO b) idle detection timer c) system powerdown IRP.

b) and c) cannot race - the devnode can only have 1 D power IRP active on
it. So, either the idle detector's power IRP will go after the D power IRP
caused by Sx power IRP, or vice versa. Silently ignoring the D IRPs in a case
the device is already lower then in D0 is a solution. Maybe the storage port
does this.

As about the IO itself - surely it can race with idle detection timer, but
the logic can be so that the IO will always win - if the LUN is lower then in
D0, then the IO IRP will do PoRequestPowerIrp up to D0, and put itself to the
queue. When the power IRP will arrive, then the queue will be consumed and
delivered to lower edges.

The situation with disk IO racing with S power IRP is a bit mystical for
me. Is it possible? If yes - then probably the proper solution would be to
queue the disk IO IRPs till the S state will change back to S0.

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

.

Loading