Re: Re: uhci-hcd suspend/resume under the new driver model

[Nigel Cunningham <ncunningham-3EexvZdKGZRWk0Htik3J/w@public.gmane.org>]

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

Hi David.

On Thu, 2005-03-17 at 09:12, David Brownell wrote:
> Hi,
> 
> On Wednesday 16 March 2005 1:44 pm, Nigel Cunningham wrote:
> > On Thu, 2005-03-17 at 08:05, David Brownell wrote:
> > > For the record, I've recently observed that all the swsusp issues
> > > start making sense to me when I start thinking of swsusp as being
> > > completely unrelated to suspend states.  (S4bios aside...)  And if
> > > I don't think of it that way, I keep tripping over complications
> > > where it's fighting against "real" suspend states.
> > > 
> > > The thing is, swsusp in normal usage does not involve system
> > > suspend states like S1/S2/S3, or their analogues in non-ACPI
> > > embedded systems.  Neither does it involve wakeup from those
> > > states ... in fact, it fights against addressing all those.
> > 
> > Both swsusp and suspend2 can enter S4 as their method of powering down,
> > and do use the prepare, enter and finish methods when doing so.
> 
> As I said, S4 aside.  The history I recall is that swsusp came
> out a fair degree of frustration with getting Linux to work
> with the BIOS support ... and lack of firmware init for video,
> etc.  And certainly S4 modes don't seem to be the default, or
> widely used/tested.

I think we're confusing things somewhere. You said "S4bios aside", and
that's fine. I wasn't talking about S4 bios support at all. Instead, I
was talking about the support swsusp and suspend2 have for invoking the
ACPI S4 sleep state. (S4 is suspend-to-disk. The problems you mention
sound more like S3 - suspend to ram).

> > > If swsusp were called a system checkpoint/restore mechanism, it'd
> > > have a much clearer relationship to power management:  enabling
> > > system power-off is a useful side effect, but it's not exactly
> > > the point of a checkpoint mechanism.  I suspect that if it were
> > > packaged as halt-after-checkpoint, plus resume-from-checkpoint,
> > > a lot of technical issues would start shaking out better.  Also
> > > maybe some political/funding ones ... checkpointing has much
> > > value for enterprise server operations.
> > 
> > Checkpointing and restoring is very different from what swsusp and
> > suspend2 do. I've been asked a number of times if I could make Suspend2
> > do checkpointing as well as suspending, and it's simply not possible.
> 
> That is, other folk have noticed that it's essentially the same
> problem...

Only from the point of view of quiescing drivers.

> > The reason is that we really are suspending to disk. We're writing the
> > entire contents of memory, and those contents are only valid while the
> > disk is in exactly the state it is in when we suspend. As soon as you
> > change a file on the disk (as you would after checkpointing), the image
> > is invalid and will create corruption if restored. To do checkpointing,
> > we'd at least have to  modify the implementations to be able to reverse
> > on disk changes back to the point where the checkpoint was taken, and
> > probably also add a mechanism for tracking in-memory changes and
> > updating the image to reflect them. It's not impossible, but it's not
> > what swsusp and Suspend2 do now.
> 
> True, not what they do now.  I didn't intend to imply they did.
> A checkpoint package would have key differences, including those.
> 
> That wasn't my point:  that swsusp, in normal usage, is more of a
> checkpoint/restore than a suspend/resume.  Which is why some of what
> it wants is different from suspend/resume.  In particular, since
> the devices are goin to be powered off, the resume paths are VERY
> different.  They are in fact reset paths, not resume paths.

Ok. I agree suspend to disk is by definition akin to a
checkpoint/restore operation. That's simply because of the nature of the
beast - devices get powered down in this state.

Can we nevertheless please still call it suspend/resume? Checkpointing
is a different creature, and we don't want to confuse the issue.

> > I realise you're writing in the context of freezing drivers, and may
> > simply be thinking in terms of the action being the same as would be
> > required if you were checkpointing. From that point of view I'd probably
> > agree. But in the first instance, I'm reacting to you speaking of
> > calling swsusp a system checkpoint/restore mechanism.
> 
> I'm trying to articulate why so much of the swsusp stuff seems (to me)
> to be fighting against "normal" suspend/resume and wakeup mechanisms,
> which can more naturally be built piecemeal from selective suspend.
> (And why there's any pushback on selective suspend, given that it's so
> basic to "normal" suspend/resume/wakeup.)

Not sure I understand everything you're saying here, so can I see if my
understanding matches/helps clarify?

I see the system states as being like a big clamp over the run-time
power management. To enter the PM_FREEZE state, for example, is to force
all the drivers into a lower state of activity & preparedness than they
would otherwise occupy. In normal operation, they'll happily interact
with each other and float between the various run-time states according
to whatever policy, but when PM_FREEZE comes along, they're collectively
forced to a lowest common denominator. Is that akin to the "fighting
again 'normal' suspend/resume and wakeup mechanisms" you speak of?

Regards,

Nigel 
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


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