I got an issue that sleepstudy report shows there are some devices are still active more than 20 secs in S0i3, so it will impact the battery.
I want to trace the connected standby in kernel debugger to find out the reason why those device are still active, but I don’t know which kernel routines are relevant with connected standby.
In traditional s3, s4 procedure, the windows kernel would start sleep procedure from “PopIssueActionRequest” routine, is the S0ix same?
//dlcu
xxxxx@hotmail.com wrote:
I got an issue that sleepstudy report shows there are some devices are still active more than 20 secs in S0i3, so it will impact the battery.
I want to trace the connected standby in kernel debugger to find out the reason why those device are still active, but I don’t know which kernel routines are relevant with connected standby.
In traditional s3, s4 procedure, the windows kernel would start sleep procedure from “PopIssueActionRequest” routine, is the S0ix same?
Connected standby still has a large degree of black magic. It’s
difficult to diagnose, because it’s almost like ESP. With normal
standby, PnP initiates a procedure that notifies all of the drivers that
“standby is coming”. Drivers take specific action, and then the kernel
goes into standby.
With connected standby, the procedure is essentially upside-down. When
the kernel wants to go into connected standby, it doesn’t do any
asking. It merely looks through its tables to determine whether or not
everyone is already in a low-power state. If they aren’t, it can’t go
to connected standby. If they are, then the kernel quietly removes the
power without telling anyone. No notifications.
All of your devices already have to be well-behaved. If any driver is
not aggressively going into a low-power state, then your system cannot
do connected standby.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.