On Sat, Jun 30, 2007 at 12:44:22AM +0200, Pavel Machek wrote:
> Hi!
>
> > By the way.
> >
> > > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > > index eb461b8..dc13af5 100644
> > > --- a/kernel/power/power.h
> > > +++ b/kernel/power/power.h
> >
> >
> >
Hi!
> By the way.
>
> > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > index eb461b8..dc13af5 100644
> > --- a/kernel/power/power.h
> > +++ b/kernel/power/power.h
>
>
> Don't these definitions need to be exported to userspace? That
> definitely is not
Hi!
By the way.
diff --git a/kernel/power/power.h b/kernel/power/power.h
index eb461b8..dc13af5 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
Don't these definitions need to be exported to userspace? That
definitely is not a header file
On Sat, Jun 30, 2007 at 12:44:22AM +0200, Pavel Machek wrote:
Hi!
By the way.
diff --git a/kernel/power/power.h b/kernel/power/power.h
index eb461b8..dc13af5 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
Don't these definitions
Am Samstag 26 Mai 2007 schrieb Rafael J. Wysocki:
Hi Rafael!
> The outcome was, more-or-less, that we'll work on merging suspend2 or
> at least some parts of it.
>
> However, in the meantime there have been some discussions implying that
> we have some important problems with suspend/hibernation
On Saturday, 26 May 2007 19:37, Martin Steigerwald wrote:
> Am Mittwoch 25 April 2007 schrieb Pavel Machek:
> > Hi!
> >
> > > This is why there's a lot to be said for
> > >
> > > echo mem > /sys/power/state
> > >
> > > and being able to follow the path through _one_ object (the kernel)
> > >
Am Mittwoch 25 April 2007 schrieb Pavel Machek:
> Hi!
>
> > This is why there's a lot to be said for
> >
> > echo mem > /sys/power/state
> >
> > and being able to follow the path through _one_ object (the kernel)
> > over trying to figure out the interaction between many different
> > parts
Am Mittwoch 25 April 2007 schrieb Pavel Machek:
Hi!
This is why there's a lot to be said for
echo mem /sys/power/state
and being able to follow the path through _one_ object (the kernel)
over trying to figure out the interaction between many different
parts with different
On Saturday, 26 May 2007 19:37, Martin Steigerwald wrote:
Am Mittwoch 25 April 2007 schrieb Pavel Machek:
Hi!
This is why there's a lot to be said for
echo mem /sys/power/state
and being able to follow the path through _one_ object (the kernel)
over trying to figure out
Am Samstag 26 Mai 2007 schrieb Rafael J. Wysocki:
Hi Rafael!
The outcome was, more-or-less, that we'll work on merging suspend2 or
at least some parts of it.
However, in the meantime there have been some discussions implying that
we have some important problems with suspend/hibernation that
Matthew Garrett wrote:
> On Sat, Apr 28, 2007 at 12:15:50PM -0700, David Lang wrote:
>> with dynaticks now in the kernel it may even be possible to have the idle
>> process decide that the next event is far enough away that it should
>> suspend-to-ram until that point.
>
> This would be ideal
On Sat, Apr 28, 2007 at 12:15:50PM -0700, David Lang wrote:
> with dynaticks now in the kernel it may even be possible to have the idle
> process decide that the next event is far enough away that it should
> suspend-to-ram until that point.
This would be ideal (and it's broadly what the OLPC
On Sat, 28 Apr 2007, Bill Davidsen wrote:
Linus Torvalds wrote:
(And for me personally, I'd love to have all my machines "sleep" by
default, but wake up by eithernet and keyboard - I'd love for my screen
saver to literally put the machine to sleep, but not have to worry about
touching a
Linus Torvalds wrote:
(And for me personally, I'd love to have all my machines "sleep" by
default, but wake up by eithernet and keyboard - I'd love for my screen
saver to literally put the machine to sleep, but not have to worry about
touching a keyboard - just ssh'ing into them should still
Linus Torvalds wrote:
(And for me personally, I'd love to have all my machines sleep by
default, but wake up by eithernet and keyboard - I'd love for my screen
saver to literally put the machine to sleep, but not have to worry about
touching a keyboard - just ssh'ing into them should still
On Sat, 28 Apr 2007, Bill Davidsen wrote:
Linus Torvalds wrote:
(And for me personally, I'd love to have all my machines sleep by
default, but wake up by eithernet and keyboard - I'd love for my screen
saver to literally put the machine to sleep, but not have to worry about
touching a
On Sat, Apr 28, 2007 at 12:15:50PM -0700, David Lang wrote:
with dynaticks now in the kernel it may even be possible to have the idle
process decide that the next event is far enough away that it should
suspend-to-ram until that point.
This would be ideal (and it's broadly what the OLPC
Matthew Garrett wrote:
On Sat, Apr 28, 2007 at 12:15:50PM -0700, David Lang wrote:
with dynaticks now in the kernel it may even be possible to have the idle
process decide that the next event is far enough away that it should
suspend-to-ram until that point.
This would be ideal (and it's
On Friday, 27 April 2007 12:19, Johannes Berg wrote:
> On Fri, 2007-04-27 at 12:18 +0200, Rafael J. Wysocki wrote:
>
> > 1) We define platform_hibernation if CONFIG_ACPI is set.
>
> Let's just define it always then in the common code so we don't have
> even more magic bits platforms need to
On Fri, 2007-04-27 at 14:09 +0200, Rafael J. Wysocki wrote:
> Yes. Still, I'd like to rework your patch to deal with ACPI without
> introducing hibernate_ops . I'm going to do this later today if you don't
> mind. :-)
Not at all :) That's why I actually sent it out instead of just saying
"well
On Fri, 2007-04-27 at 12:18 +0200, Rafael J. Wysocki wrote:
> 1) We define platform_hibernation if CONFIG_ACPI is set.
Let's just define it always then in the common code so we don't have
even more magic bits platforms need to define even if they don't care at
all. And please don't put #ifdef
On Friday, 27 April 2007 11:41, Johannes Berg wrote:
> On Thu, 2007-04-26 at 21:02 +0200, Rafael J. Wysocki wrote:
>
> > Yes. That's because we want to be able to repeat creating the image
> > without closing the fd in some situations.
>
> Oh yeah, I just checked and it's not in fact necessary.
On Fri, 2007-04-27 at 11:41 +0200, Johannes Berg wrote:
> No, because acpi doesn't know at build time whether it can actually do
> S4 or not.
Actually, you could probably do it by making some weak symbol for it
that only ACPI overrides, and then check in the ACPI code if S4 is
possible,
On Thu, 2007-04-26 at 21:02 +0200, Rafael J. Wysocki wrote:
> Yes. That's because we want to be able to repeat creating the image
> without closing the fd in some situations.
Oh yeah, I just checked and it's not in fact necessary. I'm just
confused.
> Still, we could use a global var
On Thu, 2007-04-26 at 21:02 +0200, Rafael J. Wysocki wrote:
Yes. That's because we want to be able to repeat creating the image
without closing the fd in some situations.
Oh yeah, I just checked and it's not in fact necessary. I'm just
confused.
Still, we could use a global var
On Fri, 2007-04-27 at 11:41 +0200, Johannes Berg wrote:
No, because acpi doesn't know at build time whether it can actually do
S4 or not.
Actually, you could probably do it by making some weak symbol for it
that only ACPI overrides, and then check in the ACPI code if S4 is
possible, otherwise
On Friday, 27 April 2007 11:41, Johannes Berg wrote:
On Thu, 2007-04-26 at 21:02 +0200, Rafael J. Wysocki wrote:
Yes. That's because we want to be able to repeat creating the image
without closing the fd in some situations.
Oh yeah, I just checked and it's not in fact necessary. I'm
On Fri, 2007-04-27 at 12:18 +0200, Rafael J. Wysocki wrote:
1) We define platform_hibernation if CONFIG_ACPI is set.
Let's just define it always then in the common code so we don't have
even more magic bits platforms need to define even if they don't care at
all. And please don't put #ifdef
On Friday, 27 April 2007 12:19, Johannes Berg wrote:
On Fri, 2007-04-27 at 12:18 +0200, Rafael J. Wysocki wrote:
1) We define platform_hibernation if CONFIG_ACPI is set.
Let's just define it always then in the common code so we don't have
even more magic bits platforms need to define even
On Fri, 2007-04-27 at 14:09 +0200, Rafael J. Wysocki wrote:
Yes. Still, I'd like to rework your patch to deal with ACPI without
introducing hibernate_ops . I'm going to do this later today if you don't
mind. :-)
Not at all :) That's why I actually sent it out instead of just saying
well I
Hi.
On Thu, 2007-04-26 at 23:22 +0200, Rafael J. Wysocki wrote:
> On Thursday, 26 April 2007 22:55, Nigel Cunningham wrote:
> > Hi.
> >
> > On Thu, 2007-04-26 at 22:37 +0200, Rafael J. Wysocki wrote:
> > > On Thursday, 26 April 2007 22:16, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On
On Thursday, 26 April 2007 22:55, Nigel Cunningham wrote:
> Hi.
>
> On Thu, 2007-04-26 at 22:37 +0200, Rafael J. Wysocki wrote:
> > On Thursday, 26 April 2007 22:16, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Thu, 2007-04-26 at 21:28 +0200, Rafael J. Wysocki wrote:
> > > > On Thursday, 26
Hi!
> > #define SNAPSHOT_SET_IMAGE_SIZE _IOW(SNAPSHOT_IOC_MAGIC, 6,
> > unsigned long)
>
> So I'm not supposed to be able to suspend the 16Gb-ram, 32bits servers
> I have here?
(You are right, this should have been u64)
Snapshot image is by design limited by ammount of lowmem. If
On Thu, 26 Apr 2007, Rafael J. Wysocki wrote:
The general scheme has been working for four or five years - if there
was a fundamental issue, we would have found it by now.
The scheme isn't complicated.
Conceptually, it is complicated just because you're using the LRU.
I know that I've seen
Hi.
On Thu, 2007-04-26 at 17:06 -0400, Theodore Tso wrote:
> On Thu, Apr 26, 2007 at 08:56:48AM -0700, Linus Torvalds wrote:
> >
> >
> > On Thu, 26 Apr 2007, Pavel Machek wrote:
> > >
> > > Yes, probably will. The other option is to break existing 32-bit
> > > userspace, which is a bit more
On Thu, Apr 26, 2007 at 08:56:48AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 26 Apr 2007, Pavel Machek wrote:
> >
> > Yes, probably will. The other option is to break existing 32-bit
> > userspace, which is a bit more common AFAICT.
>
> And *this* is why kernel/userspace things simply should
Hi!
> > > See? Two *totally* different cases. They have *nothing* in common. Not the
> > > call sequence, not the logic, not *anything*.
> >
> > Except that both methods cannot rely upon hot-pluggable devices
> > still being present on resume/restore. It is exceptionally common
> > to unplug
Hi.
On Thu, 2007-04-26 at 22:37 +0200, Rafael J. Wysocki wrote:
> On Thursday, 26 April 2007 22:16, Nigel Cunningham wrote:
> > Hi.
> >
> > On Thu, 2007-04-26 at 21:28 +0200, Rafael J. Wysocki wrote:
> > > On Thursday, 26 April 2007 18:10, Pekka Enberg wrote:
> > > >
> > > > On 4/26/2007,
On Thursday, 26 April 2007 22:16, Nigel Cunningham wrote:
> Hi.
>
> On Thu, 2007-04-26 at 21:28 +0200, Rafael J. Wysocki wrote:
> > On Thursday, 26 April 2007 18:10, Pekka Enberg wrote:
> > >
> > > On 4/26/2007, "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > > In principle, we could add
Hi.
On Thu, 2007-04-26 at 21:28 +0200, Rafael J. Wysocki wrote:
> On Thursday, 26 April 2007 18:10, Pekka Enberg wrote:
> >
> > On 4/26/2007, "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > In principle, we could add suspend2 as an alternative (in analogy with
> > > the I/O
> > >
On Thursday, 26 April 2007 02:34, Linus Torvalds wrote:
>
> On Wed, 25 Apr 2007, Linus Torvalds wrote:
> >
> > The *thaw* needs to happen with devices quiescent.
>
> Btw, I sure as hell hope you didn't use "suspend()" for that. You're
> (again) much better off having a totally separate
On Thursday, 26 April 2007 18:10, Pekka Enberg wrote:
>
> On 4/26/2007, "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > In principle, we could add suspend2 as an alternative (in analogy with the
> > I/O
> > schedulers, for example), but I think for this purpose it should be reviewed
> >
Matt Mackall wrote:
On Tue, Apr 24, 2007 at 11:29:56PM +0200, Pavel Machek wrote:
We do not want to fragment the testing base, and suspend2 does not
really have any interesting features over uswsusp.
The testing base is already fragmented!
What the current situation means is that you simply
On Thursday, 26 April 2007 20:40, Johannes Berg wrote:
> On Thu, 2007-04-26 at 20:40 +0200, Rafael J. Wysocki wrote:
>
> > > * it surfaces kernel implementation details about pm_ops and thus makes
> > >the whole thing very fragile
> >
> > Can you elaborate?
>
> Well it tells userspace
On Thu, 2007-04-26 at 20:40 +0200, Rafael J. Wysocki wrote:
> > * it surfaces kernel implementation details about pm_ops and thus makes
> >the whole thing very fragile
>
> Can you elaborate?
Well it tells userspace about pm_ops->enter/prepare/finish etc.
Also, it seems that it needs a
On Thursday, 26 April 2007 18:31, Johannes Berg wrote:
> On Thu, 2007-04-26 at 13:30 +0200, Pavel Machek wrote:
>
> > > From looking at pm_ops which I was recently working with a lot, it seems
> > > that it was designed by somebody who was reading the ACPI documentation
> > > and was otherwise
On Thu, Apr 26, 2007 at 01:09:53PM +0200, Pavel Machek wrote:
> #define SNAPSHOT_SET_IMAGE_SIZE _IOW(SNAPSHOT_IOC_MAGIC, 6,
> unsigned long)
So I'm not supposed to be able to suspend the 16Gb-ram, 32bits servers
I have here?
OG.
-
To unsubscribe from this list: send the line
Xavier Bestel wrote:
On Wed, 2007-04-25 at 18:50 +1000, Nigel Cunningham wrote:
(And guess what, it uses APM and suspend is really faster and way more
reliable than each kernel implementation I could try).
If you tried Suspend2 and had problems with reliability, please send me
logs. I'll do
On Thu, 26 Apr 2007, Josh Triplett wrote:
>
> http://www.gettysfamily.org/wordpress/?p=32
> http://www.gettysfamily.org/wordpress/?p=33
>
> You cannot resume "too fast"; suspend to RAM should become so fast that you
> use it without even thinking about it.
Yes. I think the OLPC is a prime
Pavel Machek wrote:
>> For suspend to ram, in contrast, since you *know* that nobody will be
>> touching the hardware, and since the timings are very different anyway
>> (you'd hope that you can resume in a second or two), you'd generally want
>> to keep the DMA engine tables right where they
On Thu, 2007-04-26 at 10:14 -0600, Chris Friesen wrote:
> Johannes Berg wrote:
>
> > Judging from experience with the wext 32/64 bit fiasco it seems to be
> > rather uncommon to use 32-bit userspace on 64-bit machines.
>
> I disagree...it's quite common. I think its the standard way of doing
>
On Thu, 2007-04-26 at 13:30 +0200, Pavel Machek wrote:
> > From looking at pm_ops which I was recently working with a lot, it seems
> > that it was designed by somebody who was reading the ACPI documentation
> > and was otherwise pretty clueless, even at that level std tries to look
> > like
By the way.
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index eb461b8..dc13af5 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
Don't these definitions need to be exported to userspace? That
definitely is not a header file for
On Thu, 26 Apr 2007, Chris Friesen wrote:
>
> I disagree...it's quite common. I think its the standard way of doing things
> for ppc64, for instance.
It is, although most x86-64 installations seem to be 64-bit user space
*if*you*install*from*scatch*.
Of course, at least some users (yeah,
Johannes Berg wrote:
Judging from experience with the wext 32/64 bit fiasco it seems to be
rather uncommon to use 32-bit userspace on 64-bit machines.
I disagree...it's quite common. I think its the standard way of doing
things for ppc64, for instance.
Chris
-
To unsubscribe from this
On Thu, 26 Apr 2007, Mark Lord wrote:
> Linus Torvalds wrote:
> >
> > See? Two *totally* different cases. They have *nothing* in common. Not the
> > call sequence, not the logic, not *anything*.
>
> Except that both methods cannot rely upon hot-pluggable devices
> still being present on
On 4/26/2007, "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> In principle, we could add suspend2 as an alternative (in analogy with the I/O
> schedulers, for example), but I think for this purpose it should be reviewed
> properly.
Yeah, this makes sense.
On 4/26/2007, "Rafael J. Wysocki"
On Thu, 26 Apr 2007, Alan Cox wrote:
>
> > The PCI spec for controlling DMA is really pretty nasty. You can disable
> > it in the PCI config word, of course, but that usually just messes up the
> > device entirely.
>
> And some devices ignore it. Some of the older Cyrix stuff I have appears
>
On Thu, 26 Apr 2007, Pavel Machek wrote:
>
> Yes, probably will. The other option is to break existing 32-bit
> userspace, which is a bit more common AFAICT.
And *this* is why kernel/userspace things simply should not be done.
It's simply better to do things entirely in the kernel. Because
On Thu, 26 Apr 2007, Pavel Machek wrote:
>
> #define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, void *)
> #define SNAPSHOT_SET_IMAGE_SIZE _IOW(SNAPSHOT_IOC_MAGIC, 6,
> unsigned long)
> #define SNAPSHOT_AVAIL_SWAP _IOR(SNAPSHOT_IOC_MAGIC, 7, void *)
>
On Thursday, 26 April 2007 13:12, Pekka Enberg wrote:
> On 4/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > Please stop using FUD.
> > > Graphical progress it's not in the kernel, even with suspend2.
> >
> > It was ascii-art, but still 'graphical', last time I checked.
>
> Suspend2 talks to
Linus Torvalds wrote:
See? Two *totally* different cases. They have *nothing* in common. Not the
call sequence, not the logic, not *anything*.
Except that both methods cannot rely upon hot-pluggable devices
still being present on resume/restore. It is exceptionally common
to unplug all
> The PCI spec for controlling DMA is really pretty nasty. You can disable
> it in the PCI config word, of course, but that usually just messes up the
> device entirely.
And some devices ignore it. Some of the older Cyrix stuff I have appears
not to care how the master bit is set.
-
To
Hi!
> > > The interface isn't even 64/32-bit compatible...
> >
> > It's not . And it's one of the worst interface I've seen lately. Did
> > anyone actually review this crap before it went in? I completely
> > agree with Linus that these kind of boundaries that lead to horribly
> > complex
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > The interface isn't even 64/32-bit compatible...
>
> It's not . And it's one of the worst interface I've seen lately. Did
> anyone actually review this crap before it went in? I completely
> agree with Linus that these kind of boundaries
On Thu, 2007-04-26 at 13:30 +0200, Pavel Machek wrote:
> That code goes back to Patrick, AFAICT. (And yes, ACPI S3 and ACPI S4
> low-level enter is pretty similar).
But that doesn't excuse abusing the same interface, IMHO.
> Patches would be welcome
:) I'll see what I can do. Shouldn't be too
On Thu, Apr 26, 2007 at 12:17:12PM +0200, Johannes Berg wrote:
> On Tue, 2007-04-24 at 23:24 +0200, Pavel Machek wrote:
>
> > I believe uswsusp user/kernel separation is clean enough. Kernel
> > provides "snapshot image" and "resume image". (Thanks go to Rafael for
> > very clean interface).
>
>
Hi!
> > Yes, probably will. The other option is to break existing 32-bit
> > userspace, which is a bit more common AFAICT.
>
> Judging from experience with the wext 32/64 bit fiasco it seems to be
> rather uncommon to use 32-bit userspace on 64-bit machines.
Well, it would break 32-bit
On Thu, 2007-04-26 at 13:26 +0200, Pavel Machek wrote:
> Yes, probably will. The other option is to break existing 32-bit
> userspace, which is a bit more common AFAICT.
Judging from experience with the wext 32/64 bit fiasco it seems to be
rather uncommon to use 32-bit userspace on 64-bit
Hi!
> > That's where I started: whole "suspend to disk" thing actually has _more_
> > to do with "shutdown" than with "suspend".
>
> From looking at pm_ops which I was recently working with a lot, it seems
> that it was designed by somebody who was reading the ACPI documentation
> and was
Hi!
> > We do not want to fragment the testing base, and suspend2 does not
> > really have any interesting features over uswsusp.
>
> The testing base is already fragmented!
>
> What the current situation means is that you simply never hear from
> the people who get fed up with suspend but who
Hi!
> > This one should prevent ioctl numbers changing, too.
>
> > -#define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, void *)
> > +#define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, u32) /*
> > void * */
>
> Afaict that'll actually change ioctl numbers breaking
On Thu, 2007-04-26 at 13:16 +0200, Pavel Machek wrote:
> This one should prevent ioctl numbers changing, too.
> -#define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, void *)
> +#define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, u32) /*
> void * */
Afaict that'll
Hi!
> > Does this seem to help?
>
> No idea, I haven't actually tried it yet, last time I tried uswsusp on
> my 32/32 machine it didn't work due to endian problems that were
> supposed to be resolved but I haven't had a chance to pick all the bits
> together that you need.
This one should
On 4/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Please stop using FUD.
> Graphical progress it's not in the kernel, even with suspend2.
It was ascii-art, but still 'graphical', last time I checked.
Suspend2 talks to an userspace client via netlink. While I find the
name of the message
Hi!
> > > > I believe uswsusp user/kernel separation is clean enough. Kernel
> > > > provides "snapshot image" and "resume image". (Thanks go to Rafael for
> > > > very clean interface).
> > >
> > > The interface isn't even 64/32-bit compatible...
> >
> > Which parts?
>
> ioctl numbers last
On Thu, 2007-04-26 at 12:40 +0200, Pavel Machek wrote:
> Does this seem to help?
No idea, I haven't actually tried it yet, last time I tried uswsusp on
my 32/32 machine it didn't work due to endian problems that were
supposed to be resolved but I haven't had a chance to pick all the bits
On Thu, 2007-04-26 at 12:30 +0200, Pavel Machek wrote:
> On Thu 2007-04-26 12:17:12, Johannes Berg wrote:
> > On Tue, 2007-04-24 at 23:24 +0200, Pavel Machek wrote:
> >
> > > I believe uswsusp user/kernel separation is clean enough. Kernel
> > > provides "snapshot image" and "resume image".
On Wed, 2007-04-25 at 15:55 -0700, Linus Torvalds wrote:
> That's where I started: whole "suspend to disk" thing actually has _more_
> to do with "shutdown" than with "suspend".
From looking at pm_ops which I was recently working with a lot, it seems
that it was designed by somebody who was
Hi!
> > The interface isn't even 64/32-bit compatible...
>
> Which parts?
>
> ioctl(AVAIL_SWAP,
> ...hmm, is this the one you are complaining about? It returns
> loff_t through a pointer. Maybe there's another interface
> that can return available swap, and we should use
On Thu 2007-04-26 12:17:12, Johannes Berg wrote:
> On Tue, 2007-04-24 at 23:24 +0200, Pavel Machek wrote:
>
> > I believe uswsusp user/kernel separation is clean enough. Kernel
> > provides "snapshot image" and "resume image". (Thanks go to Rafael for
> > very clean interface).
>
> The interface
On Tue, 2007-04-24 at 23:24 +0200, Pavel Machek wrote:
> I believe uswsusp user/kernel separation is clean enough. Kernel
> provides "snapshot image" and "resume image". (Thanks go to Rafael for
> very clean interface).
The interface isn't even 64/32-bit compatible...
johannes
signature.asc
Hi.
On Thu, 2007-04-26 at 00:27 -0700, David Lang wrote:
> On Thu, 26 Apr 2007, Nigel Cunningham wrote:
>
> > Hi.
> >
> > On Thu, 2007-04-26 at 01:33 +0200, Olivier Galibert wrote:
> >> On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote:
> >>> .. but if the alternative is a feature
On Thu, 26 Apr 2007, Nigel Cunningham wrote:
Hi.
On Thu, 2007-04-26 at 01:33 +0200, Olivier Galibert wrote:
On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote:
.. but if the alternative is a feature that just isn't worth it, and
likely to not only have its own bugs, but cause
Hi.
On Thu, 2007-04-26 at 01:33 +0200, Olivier Galibert wrote:
> On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote:
> > .. but if the alternative is a feature that just isn't worth it, and
> > likely to not only have its own bugs, but cause bugs elsewhere? (And yes,
> > I believe
Hello.
On Wed, 2007-04-25 at 23:30 +0200, Pavel Machek wrote:
> Hi!
>
> > > Please ask anyone who's worked with me if he's had any problem with that.
> > > If anyone say I'm unable to work with anybody else, I'd say you're right.
> > > Till
> > > then, I feel offended.
> >
> > I'll apologise
Hi.
Hmm. Perhaps I should have added to that last reply that recognising
that they store similar information doesn't mean I think they need the
same high-level routine for both state transitions.
I'd really like to see each driver have some sort of state machine
controlling its power management,
Alan Cox wrote:
> Mind you some laptops think S2RAM is just a transition state on the way
> to disk, leave them in ACPI S2RAM and the firmware will magically turn it
> into a save to disk and back to ram if the battery runs low or you leave
> it idle too long.
The OS does this (or at least it's
Hi.
On Wed, 2007-04-25 at 20:03 -0700, Linus Torvalds wrote:
>
> On Thu, 26 Apr 2007, Nigel Cunningham wrote:
> >
> > Sorry. I wasn't clear. I wasn't saying that suspend to ram has a
> > snapshot point. I was trying to say it has a point where you're seeking
> > to save information (PCI state /
Hi.
On Wed, 2007-04-25 at 19:04 -0700, Linus Torvalds wrote:
>
> On Thu, 26 Apr 2007, Nigel Cunningham wrote:
> >
> > That's where I think you're overstretching the argument. Like suspend
> >(to ram), we're concerned at the snapshot point with getting the hardware
> >in the same state at a
Hi.
On Thu, 2007-04-26 at 01:45 +0200, Pavel Machek wrote:
> > What's your argument? Your argument seems to be that it's not stupid,
> > because it can work. Can't you see that that simply isn't an
> > argument at
>
> I tried keeping module_init/thaw/resume similar code, so that driver
>
Hi.
On Wed, 2007-04-25 at 15:18 -0700, Linus Torvalds wrote:
>
> On Wed, 25 Apr 2007, Pavel Machek wrote:
> >
> > Not the same... but they are still related. "freeze" (for atomic
> > snapshot) is actually subset of "suspend"... freeze needs DMAs off and
> > saved state, and you need DMAs off
Hi.
On Wed, 2007-04-25 at 15:55 -0700, Linus Torvalds wrote:
>
> On Thu, 26 Apr 2007, Nigel Cunningham wrote:
> > >
> > > And name *one* thing that have in common.
> >
> > Set/reset the scsi transaction id thingy? Hibernation didn't work with
> > SCSI for a long time precisely because that
Hi.
On Wed, 2007-04-25 at 15:55 -0700, Linus Torvalds wrote:
On Thu, 26 Apr 2007, Nigel Cunningham wrote:
And name *one* thing that have in common.
Set/reset the scsi transaction id thingy? Hibernation didn't work with
SCSI for a long time precisely because that support was
Hi.
On Wed, 2007-04-25 at 15:18 -0700, Linus Torvalds wrote:
On Wed, 25 Apr 2007, Pavel Machek wrote:
Not the same... but they are still related. freeze (for atomic
snapshot) is actually subset of suspend... freeze needs DMAs off and
saved state, and you need DMAs off and saved state
Hi.
On Thu, 2007-04-26 at 01:45 +0200, Pavel Machek wrote:
What's your argument? Your argument seems to be that it's not stupid,
because it can work. Can't you see that that simply isn't an
argument at
I tried keeping module_init/thaw/resume similar code, so that driver
authors can
Hi.
On Wed, 2007-04-25 at 20:03 -0700, Linus Torvalds wrote:
On Thu, 26 Apr 2007, Nigel Cunningham wrote:
Sorry. I wasn't clear. I wasn't saying that suspend to ram has a
snapshot point. I was trying to say it has a point where you're seeking
to save information (PCI state / SCSI
Hi.
On Wed, 2007-04-25 at 19:04 -0700, Linus Torvalds wrote:
On Thu, 26 Apr 2007, Nigel Cunningham wrote:
That's where I think you're overstretching the argument. Like suspend
(to ram), we're concerned at the snapshot point with getting the hardware
in the same state at a later stage.
Alan Cox wrote:
Mind you some laptops think S2RAM is just a transition state on the way
to disk, leave them in ACPI S2RAM and the firmware will magically turn it
into a save to disk and back to ram if the battery runs low or you leave
it idle too long.
The OS does this (or at least it's
Hi.
Hmm. Perhaps I should have added to that last reply that recognising
that they store similar information doesn't mean I think they need the
same high-level routine for both state transitions.
I'd really like to see each driver have some sort of state machine
controlling its power management,
1 - 100 of 330 matches
Mail list logo
