Re: Problems with PM_FREEZE

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]

Hi Alan.

On Wed, 2005-09-28 at 12:58, Alan Stern wrote:
> On Wed, 28 Sep 2005, Nigel Cunningham wrote:
> 
> > Yes, that's true. If the usb modules are loaded when suspending and not
> > loaded when resuming or vice versa, you'll get inconsistencies:
> > 
> > State at suspend	State at resume		Image state
> > 
> > Built in		Built in		Freeze->Freeze
> > Loaded modules	Unloaded modules	Undefined->Freeze
> > Unloaded modules	Loaded modules		Freeze->Undefined
> 
> This table is misleading.  Better to describe it like this:
> 
> 	If the image doesn't contain USB drivers, the device state
> 	doesn't matter.
> 
> 	If the image does contain USB drivers and the boot kernel
> 	did not meddle with the device states, then the devices
> 	will be suspended even though the image thinks they are
> 	frozen.

So a power off or reboot doesn't reset the USB devices?

> 	If the image does contain USB drivers and the boot kernel
> 	did meddle with the device states, then the devices probably
> 	will not be resumable by the image kernel.  They will have
> 	to be rediscovered.

Even if frozen? They should end up in the same state. But then USB
suspend/resume hasn't worked reliably for me, so I'm still in
unload-usb-while-suspending mode.

> > I guess there are three possible solutions:
> > 1) Leave things as they are and say it is the user's problem if they
> > make the state inconsistent.
> > 2) Keep knowledge of the device states across the atomic restore and use
> > that information in deciding what to do in device resume/powerup.
> > 3) Make device drivers handle the situation properly without knowledge
> > of what state the hardware is really in (or check the real state - where
> > possible - and rely on that in deciding what to do).
> > 
> > 2 seems to me to make for the most reliable solution.
> 
> No.  The best answer is to
> 
> 	(A) tell the boot kernel that the impending freeze is for a
> 	restore-from-disk, so that it can wipe out the state of any
> 	devices it has changed, and
> 
> 	(B) tell the image kernel that it is resuming from disk, so
> 	that it can know that the devices are really suspended even
> 	though its internal records say they are frozen.

But if the drivers are loaded, we will tell them to freeze, so the state
will be frozen.

> Better than (A) would be to tell the boot kernel that it _is_ only a boot 
> kernel, so that its drivers will know not to mess up the state of any 
> devices.  This would have the side effect of making it impossible to 
> reload an image from a USB drive, but that's pretty much unavoidable 
> anyway.

I would like to be able to get suspend to and resuming from usb going at
some stage. No chance?

The problem with telling the kernel it is only a boot kernel is that we
don't know that until we look and see if there's an image, which may
involve running an initramfs/initrd first (encryption, eg).

Regards,

Nigel



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]