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 a
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)
> > > over
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 wit
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 (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 g
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 keyb
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 w
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 defin
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 CON
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, otherwise
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 'platform_
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 T
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 A
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 y
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 com
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 n
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 all
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, "Rafae
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 sus
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
> > > schedulers
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 functio
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
> > proper
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 n
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 about
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 "rele
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 pre
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 "uns
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 all
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 exam
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 ar
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 suspe
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 userspac
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, I'v
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 list
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 resume/
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" <[EMA
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 you
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 *)
> #defi
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 USB/f
> 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 unsubscr
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 io
* 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 tha
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 h
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 userspace
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 machine
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 other
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 m
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 existing
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 actual
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 preven
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 tim
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
together
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". (Thank
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 rea
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 that,
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
De
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 th
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 bugs
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 ST
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 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 late
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
> author
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
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 supp
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 transaction number or whatever)
> that you'll need to get the hardwa
On Wed, 25 Apr 2007, H. Peter Anvin wrote:
>
> That was the 1990s. On a brand new server system:
>
> 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA
> Engine (rev b1)
>
> For better or worse, slave DMA seems to be making a comeback of sorts.
> Not to mention all kinds of
Linus Torvalds wrote:
>
> On Thu, 26 Apr 2007, Pavel Machek wrote:
>> Ok, I guess I'll have nightmares of DMA controllers doing DMAs from
>> chips that are no longer there tonight.
>
> Umm. Welcome to the 21st century: we don't do that "separate DMA
> controller" thing any more. All devices do t
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.
Really, no.
"suspend to ram" doesn't _have_ a "snapshot point"
On Wed, 2007-04-25 at 21:25 +0200, Adrian Bunk wrote:
> On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote:
> >
> >
> > On Wed, 25 Apr 2007, Adrian Bunk wrote:
> > >
> > > 3W for the complete system? In CPU state S1? [1]
> >
> > In STR, 3W is quite realistic. The CPU is off, all (or
On Thu, 26 Apr 2007, Alan Cox wrote:
>
> You bet there is. We need to know if data arrived or not, because there
> is no guarantee that the data retrieved if we inadvertently re-execute a
> command will be the same. The hardware state itself isn't the problem,
> its the combination of hardware s
Sort of my 2-many-cents story on why I need "snapshot/restore"...
Am Wed, 25 Apr 2007 13:08:09 -0700 (PDT)
schrieb Linus Torvalds <[EMAIL PROTECTED]>:
>
>
> On Wed, 25 Apr 2007, Kenneth Crudup wrote:
> >
> > Any working suspend-to-disk method takes care of that for me. (I'm
> > really not su
On Thu, 26 Apr 2007, Pavel Machek wrote:
>
> Ok, I guess I'll have nightmares of DMA controllers doing DMAs from
> chips that are no longer there tonight.
Umm. Welcome to the 21st century: we don't do that "separate DMA
controller" thing any more. All devices do their own DMA.
> Only the fact
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 function that just
freezes stuff.
So in the "snapshot+shutdown" path, you
On Thu, 26 Apr 2007, Pavel Machek wrote:
Now, if the old kernel left DMAs running, it could be overwriting
the data we are copying in.
The *thaw* needs to happen with devices quiescent.
But that sure doesn't have anythign to do with the "snapshot()" path. In
fact, you'll have rebooted the mac
> STR does not need to "ensure that you have a consistent snapshot".
Linus I think someone's been spiking your guinness again...
> Why? Becuase there is no _room_ for inconsistency. There's nothing to be
> "inconsistent with", since any changes to memory (by things like DMA or
> other setup tha
Hi!
> > > Why? Becuase there is no _room_ for inconsistency. There's nothing to be
> > > "inconsistent with", since any changes to memory (by things like DMA or
> > > other setup that happens while the suspend process is going on) is by
> > > _definition_ consistent with the resume image (becas
On Thu, 26 Apr 2007, Pavel Machek wrote:
> >
> > Why? Becuase there is no _room_ for inconsistency. There's nothing to be
> > "inconsistent with", since any changes to memory (by things like DMA or
> > other setup that happens while the suspend process is going on) is by
> > _definition_ cons
On Thu, 26 Apr 2007, 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 eng
Hi!
> > Both of them have to ensure you can make a consistent snapshot.
>
> Bzzt. Wrong again. Very much so.
>
> STR does not need to "ensure that you have a consistent snapshot".
>
> Why? Becuase there is no _room_ for inconsistency. There's nothing to be
> "inconsistent with", since any chan
Hi!
> > Current design is:
>
> Broken. Yes. I've tried to tell you.
Ok.
...
> It's worse than just confusing, it's *idiotic*.
>
> It _can_ work in practice, but
> - we have pretty damn solid evidence that it doesn't work all that often
>in practice
> - the fact that something *can* be
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 STD is both of those. There's a reason it's called "STD". Go
> to google
On Thu, 26 Apr 2007, Pavel Machek wrote:
>
> Current design is:
Broken. Yes. I've tried to tell you.
> Twice. Once during snapshot (then we spin it up when the snapshot is
> done), and once during shutdown.
And nobody can possibly say that is "sane". But it's a direct result of
the incorrect
Hi!
> > > I don't understand how you can even *claim* something like that.
> >
> > BTW most problems are in thaw/resume functions.
>
> And do you realize that the thaw/resume functions are totally different
> too?
>
> Or rather, they *would* be, if you allowed them to.
>
> For example, for "s
On Wed, 25 Apr 2007, Alan Cox wrote:
>
> Both of them have to ensure you can make a consistent snapshot.
Bzzt. Wrong again. Very much so.
STR does not need to "ensure that you have a consistent snapshot".
Why? Becuase there is no _room_ for inconsistency. There's nothing to be
"inconsistent
Hi!
> > > 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 missing.
>
> And by "hibernation", you mean what? You mean "snapshot + shutdown",
> right?
>
> Think ab
On Thu, 26 Apr 2007, Pavel Machek wrote:
> >
> > I don't understand how you can even *claim* something like that.
>
> BTW most problems are in thaw/resume functions.
And do you realize that the thaw/resume functions are totally different
too?
Or rather, they *would* be, if you allowed them to
1 - 100 of 161 matches
Mail list logo
