Power management relationship between stacks

NTDEV
1

I have a driver that calls another driver to perform services. I’m trying to
understand what the right power management behavior for my driver is.

My driver doesn’t directly talk to any hardware, and is root enumerated. The
other driver who’s services I use, is essentially a communication stack with
communication hardware at the bottom of the it’s stack.

My problem is that if the system tries to standby/hibernate, the other
driver’s stack doesn’t complete device power irps until all references to
that stack have been released. My understanding of sleep modes is that if a
driver stack is put to sleep (via system/device power irps), it’s supposed
to queue any I/O that comes in. I’m trying to decide if the correct behavior
is for my driver to close all connections and release any references on
standby/hibernate or if the other driver stack is the one with faulty
behavior and needs to just cope (by queuing) with ongoing I/O requests when
put to sleep, and not indefinitely stall the device power irp. I have source
code for both driver stacks, although one is from an outside consortium and
I generally try not to own it.

If I think of the other driver as if it were the TCP stack with the TDI
interface at the top, then on suspend my driver would not be expected to
close all the TCP connection and release all the network address objects. On
there other hand, there are examples in the system that must do something
special at suspend/hibernate time. For example, the iSCSI initiator, which
must not be in the PnP tree of the NIC card, but yet must use the TDI
interface and TCP stack to do all it’s I/O. On system suspend, I assume
disks get flushed and written via the iSCSI initiator before the TCP/NIC
stack is put to sleep.

Another comparable might be the USB disk driver. If the system suspends,
does the USB disk driver need to do anything special, or are his requests
just queued down in the USB controller driver, and on wakeup, they get
processed. It seems like the USB disk driver might be almost oblivious to
suspend, but all the right stuff happens in the underlying hardware driver.

Any opinions?

  • Jan
2

In an ideal world, you fix the hw based communication stack to handle
incoming i/o and active connections during a system power transition.
That said, it might be harder to do in practice then in theory. Are
there othere clients of this communication stack? Do these other
clients close their connections?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, April 30, 2007 1:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Power management relationship between stacks

I have a driver that calls another driver to perform services. I’m
trying to understand what the right power management behavior for my
driver is.

My driver doesn’t directly talk to any hardware, and is root enumerated.
The other driver who’s services I use, is essentially a communication
stack with communication hardware at the bottom of the it’s stack.

My problem is that if the system tries to standby/hibernate, the other
driver’s stack doesn’t complete device power irps until all references
to that stack have been released. My understanding of sleep modes is
that if a driver stack is put to sleep (via system/device power irps),
it’s supposed to queue any I/O that comes in. I’m trying to decide if
the correct behavior is for my driver to close all connections and
release any references on standby/hibernate or if the other driver stack
is the one with faulty behavior and needs to just cope (by queuing) with
ongoing I/O requests when put to sleep, and not indefinitely stall the
device power irp. I have source code for both driver stacks, although
one is from an outside consortium and I generally try not to own it.

If I think of the other driver as if it were the TCP stack with the TDI
interface at the top, then on suspend my driver would not be expected to
close all the TCP connection and release all the network address
objects. On there other hand, there are examples in the system that must
do something special at suspend/hibernate time. For example, the iSCSI
initiator, which must not be in the PnP tree of the NIC card, but yet
must use the TDI interface and TCP stack to do all it’s I/O. On system
suspend, I assume disks get flushed and written via the iSCSI initiator
before the TCP/NIC stack is put to sleep.

Another comparable might be the USB disk driver. If the system suspends,
does the USB disk driver need to do anything special, or are his
requests just queued down in the USB controller driver, and on wakeup,
they get processed. It seems like the USB disk driver might be almost
oblivious to suspend, but all the right stuff happens in the underlying
hardware driver.

Any opinions?

  • Jan

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