Re: [PATCH 2/2] Fix console handling during suspend/resume

[Nigel Cunningham <ncunningham@linuxmail.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1897 bytes --]

Hi.

On Friday 16 June 2006 13:22, Linus Torvalds wrote:
> On Fri, 16 Jun 2006, Nigel Cunningham wrote:
> > > You don't _need_ to save a consistent system image. There's no "single
> > > snapshot in time" needed.
> >
> > Yes, you do. If you save an image that has, say, pages in the lru that
> > are also in the free lists or a similar situation with driver data,
> > you're going to get an oops some time after resume at best, and possibly
> > ruin your filesystem at worst.
>
> Absolutely. I've acknowledged this several times. But that's not a "device
> state" thing, that's a MM state thing.
>
> I 100% agree that we must have a consistent image of free memory after
> resume. That's not in question at all. What I dispute is that this is
> "device state" and has anything to do with suspending devices..

Ok.

> The fact that this only affects STD and not STR should make people realize
> that it's not a "device" issue. STR suspends/resumes devices too, so if
> STR doesn't have that issue, then clearly it's not actually tied to the
> notion of device suspend/resume per se.

It seems me that STR has an advantage because for most devices, S3 != power 
off. Where S3 does involve powering off (some video cards, especially), the 
problem does become the same as for suspend to disk. This makes me fail to 
see your logic. Perhaps I'm being muddle headed, or we're again saying the 
same thing in different ways, but if you need to do different things for 
different hardware depending on what the hardware does when you enter S3 (or 
S5), then isn't it by nature a device/driver issue?

> It's really not at all different from _any_ memory allocation after the
> start of writing the image to memory, is it?

In this area, I agree.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

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