Freezing kernel threads for suspend or hibernation

Freezing kernel threads for suspend or hibernation

[Alan Stern]

There are a few threads in the USB core which currently do want to be
frozen.  The reason is simple enough: If left running, they would resume
some suspended devices.  Why?  Because of pending I/O requests or wakeup
requests.

This raises the question: What to do about remote wakeup requests that are
received while a suspend or hibernation is in progress?  Actually that's
two separate questions.

With hibernation, the issue arises only while preparing the memory 
snaphot.  After the snaphot is saved to disk, devices do _not_ get 
suspended before the system is shut down.  Or is that in fact not true?  
Doesn't entering S4 require the OS to put devices in a low-power state?

Anyway, there's no question about what should happen with snapshotting.  
Devices should be quiesced, with no interrupt requests and no remote
wakeup.  Still, what if a request received before the pre_snapshot call is
sitting in a kernel thread's queue?  It's not so easy for the thread to
recognize that it needs to stop processing its queue, because there's no
way to notify it about the upcoming snapshot.

(Furthermore, as a practical matter it's not so easy to do the right thing
for snapshotting, because at the moment the same method call is used for
both snapshot and suspend.  That at least we are going to fix.)


On the other side of the fence, consider suspend.  In principle I don't 
see anything wrong with handling remote wakeup requests while the system 
is trying to suspend.  What should happen is that the device is resumed, 
then the parent should fail to suspend because it has an unsuspended 
child, and the entire system suspend transition should fail.  This is just 
a shortcut for what would happen anyway -- even if the system did manage 
to suspend completely, the pending wakeup request would bring it right 
back up.

The problem to worry about is losing wakeup requests.  This can happen if
a request arrives at the wrong time and the driver isn't careful about
handling it.  For example, maybe the device can't be woken because its
parent is already suspended.  But the request has been acknowledged by the
CPU, so the device won't continue to send more requests.  As a result the
system gets suspended and stays that way.  I think solutions to this
problem must be bus-specific; it's hard to say anything that would hold in
all cases.

Alan Stern

Re: Freezing kernel threads for suspend or hibernation

[Rafael J. Wysocki]

On Monday, 14 May 2007 23:21, Alan Stern wrote:
> There are a few threads in the USB core which currently do want to be
> frozen.  The reason is simple enough: If left running, they would resume
> some suspended devices.  Why?  Because of pending I/O requests or wakeup
> requests.
> 
> This raises the question: What to do about remote wakeup requests that are
> received while a suspend or hibernation is in progress?  Actually that's
> two separate questions.
> 
> With hibernation, the issue arises only while preparing the memory 
> snaphot.  After the snaphot is saved to disk, devices do _not_ get 
> suspended before the system is shut down.  Or is that in fact not true?  
> Doesn't entering S4 require the OS to put devices in a low-power state?

At present the devices are just powered off (more precisely, device_shutdown()
is called before ->enter(ACPI_STATE_S4)).  [That should be changed, IMHO,
and we've already discussed it.]

> Anyway, there's no question about what should happen with snapshotting.  
> Devices should be quiesced, with no interrupt requests and no remote
> wakeup.  Still, what if a request received before the pre_snapshot call is
> sitting in a kernel thread's queue?  It's not so easy for the thread to
> recognize that it needs to stop processing its queue, because there's no
> way to notify it about the upcoming snapshot.

I have a patch that introduces "suspend" notifiers which may be useful here.
It was withdrawn temporarily, because it interfered with some more urgent
things, but I'm going to resubmit it (or a reworked version) soon.

> (Furthermore, as a practical matter it's not so easy to do the right thing
> for snapshotting, because at the moment the same method call is used for
> both snapshot and suspend.  That at least we are going to fix.)
> 
> 
> On the other side of the fence, consider suspend.  In principle I don't 
> see anything wrong with handling remote wakeup requests while the system 
> is trying to suspend.  What should happen is that the device is resumed, 
> then the parent should fail to suspend because it has an unsuspended 
> child, and the entire system suspend transition should fail.  This is just 
> a shortcut for what would happen anyway -- even if the system did manage 
> to suspend completely, the pending wakeup request would bring it right 
> back up.

Agreed.

> The problem to worry about is losing wakeup requests.  This can happen if
> a request arrives at the wrong time and the driver isn't careful about
> handling it.  For example, maybe the device can't be woken because its
> parent is already suspended.  But the request has been acknowledged by the
> CPU, so the device won't continue to send more requests.  As a result the
> system gets suspended and stays that way.  I think solutions to this
> problem must be bus-specific; it's hard to say anything that would hold in
> all cases.

Agreed again.

Greetings,
Rafafel


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King