Hi!
_Can we get a suspend-to-RAM maintainer_?
Noone cares about s2ram these days. I do care a little, seife
maintains whitelist, you care for mac mini, Len/Andrew/Intel acpi team
helps sometimes... But I feel we should have someone listed in the
MAINTAINERS file. Patrick was close, but...
> >
On Wed, Apr 25, 2007 at 12:38:47PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 25 Apr 2007, Adrian Bunk 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
On Wednesday, 25 April 2007 21:38, Linus Torvalds wrote:
>
> On Wed, 25 Apr 2007, Adrian Bunk wrote:
Well, I told Pavel that I wouldn't take part in this thread, but since you're
making some rude and unfounded personal remarks, I feel I have to speak.
[--snip--]
> And that's a *fundamental*
Hi!
> > > .. 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 and type "STD" and press "I'm feeling
On Wed, 25 Apr 2007, Kenneth Crudup wrote:
>
> Any working suspend-to-disk method takes care of that for me. (I'm
> really not sure why Linus hates S2D so much, though. Back in the day
> there was a lot more BIOS support, but that's been years now.)
The really sad part is that APM actually
Hi!
> > > 3W for the complete system? In CPU state S1? [1]
> >
> > In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
> > the devices are off, but the motherboard and memory is powered.
>
> As far as I understand it, the CPU isn't off in S1.
>
> > > And even 3W would
On Wed, 25 Apr 2007, Pavel Machek wrote:
> You'll miss compression part, but that provides only small speedup.
Not here:
fgrep -h Compressed /var/log/rawlog*
Apr 22 13:41:34 vaio kernel: Compressed 8562 bytes into 46779248 (45
percent compression).
Apr 22 16:09:13 vaio kernel:
On Wed, 25 Apr 2007, Pavel Machek wrote:
> I'm starting to think that we should fix the idle power consumption
> problem. Cell phones do it right. They pretend to be ready/idle all
> the time, yet they have _days_ of standby.
My laptop goes nearly everywhere I do; I DO NOT want it on when I'm
On Wed, 25 Apr 2007 21:25:12 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > And even 3W would still be a waste of energy.
> >
> > .. 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
On Wed, 25 Apr 2007, Adrian Bunk 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 and type
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 most - up to you)
> the devices are off, but the motherboard and
> In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
> the devices are off, but the motherboard and memory is powered.
>
> > And even 3W would still be a waste of energy.
>
> .. but if the alternative is a feature that just isn't worth it, and
> likely to not only have its
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 most - up to you)
the devices are off, but the motherboard and memory is powered.
> And even 3W would still be a waste of energy.
.. but if the
On 4/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Ok ok ok, suspend-to-disk has some other uses, too.
But ... you are really using suspend-to-disk as a workaround for "my
desktop takes too much power when idle". Imagine pressing "lock
screensaver" combination, and your machine going to low
On Wed, Apr 25, 2007 at 07:34:05PM +0200, Pavel Machek wrote:
> Hi!
>
> > > Even I am running in-kernel swsusp, but my managers were pretty clear
> > > they want graphical progress bar hiding all the 'ugly' swsusp
> > > messages... and in the end the same uswsusp enables compression, too.
> > >
Hi!
> > Even I am running in-kernel swsusp, but my managers were pretty clear
> > they want graphical progress bar hiding all the 'ugly' swsusp
> > messages... and in the end the same uswsusp enables compression, too.
> >
> > > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
On Wed, Apr 25, 2007 at 07:23:50AM +, Pavel Machek wrote:
> 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
Pavel Machek wrote:
..and it means that 'echo disk > ...' should work w/o suspend2 patch,
too. (Just try it). You'll miss compression part, but that provides
only small speedup.
In my experience, the speedup is significant, both in hibernating and in
waking up, and since the full image is
On Wed, 2007-04-25 at 07:29 +, Pavel Machek wrote:
> > userspace-driven-suspend is already in the kernel, today. So it's not
> > really "two versions side by side doing the same thing", but more of:
> >
> >A B C + D E F G H
> >
> > where "ABC" is used by the uswsusp code today,
On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
> suspend-to-disk is a workaround for
>
> 'suspend-to-ram eats too much power' (plus some details like
> being able to replace battery).
>
...and let me add 'suspend-to-disk' is a workaround for when s2ram does
not work for
Hi.
On Wed, 2007-04-25 at 11:07 +0200, 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
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 I can to
Hi.
On Wed, 2007-04-25 at 10:48 +0200, Xavier Bestel wrote:
> On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
> > > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
> > > whole thing. I think they've _all_ caused problems for the "true" suspend
> > >
On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
> > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
> > whole thing. I think they've _all_ caused problems for the "true" suspend
> > (suspend-to-ram), and the last thing I want to see is three or four
>
> Well, it
Hi.
On Wed, 2007-04-25 at 07:29 +, Pavel Machek wrote:
> Hi!
>
> > > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
> > > the whole thing. I think they've _all_ caused problems for the "true"
> > > suspend (suspend-to-ram), and the last thing I want to see is three or
On Wed, 2007-04-25 at 08:10 +, Pavel Machek wrote:
> Hi!
>
> > > > userspace-driven-suspend is already in the kernel, today. So it's not
> > > > really "two versions side by side doing the same thing", but more of:
> > > >
> > > >A B C + D E F G H
> > > >
> > > > where "ABC" is
Hi!
> > > userspace-driven-suspend is already in the kernel, today. So it's not
> > > really "two versions side by side doing the same thing", but more of:
> > >
> > >A B C + D E F G H
> > >
> > > where "ABC" is used by the uswsusp code today, and "ABCDEFGH" is used by
> > >
Hi!
> > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
> > the whole thing. I think they've _all_ caused problems for the "true"
> > suspend (suspend-to-ram), and the last thing I want to see is three or
> > four different suspend-to-disk implementations. So unlike Ingo,
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 versions.
The 'promise' is 'if you can get
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
> the whole thing. I think they've _all_ caused problems for the "true"
> suspend (suspend-to-ram), and the last thing I want to see is three or
> four different suspend-to-disk
* Linus Torvalds [EMAIL PROTECTED] wrote:
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
the whole thing. I think they've _all_ caused problems for the true
suspend (suspend-to-ram), and the last thing I want to see is three or
four different suspend-to-disk
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 versions.
The 'promise' is 'if you can get echo disk
Hi!
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
the whole thing. I think they've _all_ caused problems for the true
suspend (suspend-to-ram), and the last thing I want to see is three or
four different suspend-to-disk implementations. So unlike Ingo, I
don't
Hi!
userspace-driven-suspend is already in the kernel, today. So it's not
really two versions side by side doing the same thing, but more of:
A B C + D E F G H
where ABC is used by the uswsusp code today, and ABCDEFGH is used by
suspend2. So any suspend2 merge
On Wed, 2007-04-25 at 08:10 +, Pavel Machek wrote:
Hi!
userspace-driven-suspend is already in the kernel, today. So it's not
really two versions side by side doing the same thing, but more of:
A B C + D E F G H
where ABC is used by the uswsusp code
Hi.
On Wed, 2007-04-25 at 07:29 +, Pavel Machek wrote:
Hi!
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
the whole thing. I think they've _all_ caused problems for the true
suspend (suspend-to-ram), and the last thing I want to see is three or
four
On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
whole thing. I think they've _all_ caused problems for the true suspend
(suspend-to-ram), and the last thing I want to see is three or four
Well, it is a bit
Hi.
On Wed, 2007-04-25 at 10:48 +0200, Xavier Bestel wrote:
On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
whole thing. I think they've _all_ caused problems for the true suspend
(suspend-to-ram), and the
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 I can to help.
Hi.
On Wed, 2007-04-25 at 11:07 +0200, 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
On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
suspend-to-disk is a workaround for
'suspend-to-ram eats too much power' (plus some details like
being able to replace battery).
...and let me add 'suspend-to-disk' is a workaround for when s2ram does
not work for a
On Wed, 2007-04-25 at 07:29 +, Pavel Machek wrote:
userspace-driven-suspend is already in the kernel, today. So it's not
really two versions side by side doing the same thing, but more of:
A B C + D E F G H
where ABC is used by the uswsusp code today, and ABCDEFGH is
Pavel Machek wrote:
..and it means that 'echo disk ...' should work w/o suspend2 patch,
too. (Just try it). You'll miss compression part, but that provides
only small speedup.
In my experience, the speedup is significant, both in hibernating and in
waking up, and since the full image is
On Wed, Apr 25, 2007 at 07:23:50AM +, Pavel Machek wrote:
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
Hi!
Even I am running in-kernel swsusp, but my managers were pretty clear
they want graphical progress bar hiding all the 'ugly' swsusp
messages... and in the end the same uswsusp enables compression, too.
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
On Wed, Apr 25, 2007 at 07:34:05PM +0200, Pavel Machek wrote:
Hi!
Even I am running in-kernel swsusp, but my managers were pretty clear
they want graphical progress bar hiding all the 'ugly' swsusp
messages... and in the end the same uswsusp enables compression, too.
I
On 4/25/07, Pavel Machek [EMAIL PROTECTED] wrote:
Ok ok ok, suspend-to-disk has some other uses, too.
But ... you are really using suspend-to-disk as a workaround for my
desktop takes too much power when idle. Imagine pressing lock
screensaver combination, and your machine going to low power
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 most - up to you)
the devices are off, but the motherboard and memory is powered.
And even 3W would still be a waste of energy.
.. but if the
In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
the devices are off, but the motherboard and memory is powered.
And even 3W would still be a waste of energy.
.. but if the alternative is a feature that just isn't worth it, and
likely to not only have its own
On Wed, 25 Apr 2007, Adrian Bunk 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 and type STD and
On Wed, 25 Apr 2007 21:25:12 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
And even 3W would still be a waste of energy.
.. 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
On Wed, 25 Apr 2007, Pavel Machek wrote:
I'm starting to think that we should fix the idle power consumption
problem. Cell phones do it right. They pretend to be ready/idle all
the time, yet they have _days_ of standby.
My laptop goes nearly everywhere I do; I DO NOT want it on when I'm
Hi!
3W for the complete system? In CPU state S1? [1]
In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
the devices are off, but the motherboard and memory is powered.
As far as I understand it, the CPU isn't off in S1.
And even 3W would still be a waste
On Wed, 25 Apr 2007, Pavel Machek wrote:
You'll miss compression part, but that provides only small speedup.
Not here:
fgrep -h Compressed /var/log/rawlog*
Apr 22 13:41:34 vaio kernel: Compressed 8562 bytes into 46779248 (45
percent compression).
Apr 22 16:09:13 vaio kernel:
Hi!
.. 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 and type STD and press I'm feeling lucky. Google is
On Wed, 25 Apr 2007, Kenneth Crudup wrote:
Any working suspend-to-disk method takes care of that for me. (I'm
really not sure why Linus hates S2D so much, though. Back in the day
there was a lot more BIOS support, but that's been years now.)
The really sad part is that APM actually did
On Wednesday, 25 April 2007 21:38, Linus Torvalds wrote:
On Wed, 25 Apr 2007, Adrian Bunk wrote:
Well, I told Pavel that I wouldn't take part in this thread, but since you're
making some rude and unfounded personal remarks, I feel I have to speak.
[--snip--]
And that's a *fundamental*
On Wed, Apr 25, 2007 at 12:38:47PM -0700, Linus Torvalds wrote:
On Wed, 25 Apr 2007, Adrian Bunk 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.
On Wed, 25 Apr 2007, Rafael J. Wysocki wrote:
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 (and virtually kiss your hairy feet) if you could
Hi!
_Can we get a suspend-to-RAM maintainer_?
Noone cares about s2ram these days. I do care a little, seife
maintains whitelist, you care for mac mini, Len/Andrew/Intel acpi team
helps sometimes... But I feel we should have someone listed in the
MAINTAINERS file. Patrick was close, but...
On Wednesday, 25 April 2007 22:08, Pavel Machek wrote:
Hi!
.. 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
Hi!
.. 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 and type STD and press I'm feeling
On Wed, 25 Apr 2007, Pavel Machek wrote:
Can I get you on IRC somewhere? No, I do not think I'm a moron, and
yes, I need to suspend^Wsnapshot the devices before, so I have that in
the snapshot. Of course, I'll need to resume^Wrestore the devices
before writing snapshot. That's okay, it
On Wednesday, 25 April 2007 22:44, Linus Torvalds wrote:
On Wed, 25 Apr 2007, Pavel Machek wrote:
Can I get you on IRC somewhere? No, I do not think I'm a moron, and
yes, I need to suspend^Wsnapshot the devices before, so I have that in
the snapshot. Of course, I'll need to
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 (and virtually kiss your hairy feet) if you could actually
show me a single
On Wednesday, 25 April 2007 23:30, 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 (and virtually kiss your
Hi!
Can I get you on IRC somewhere? No, I do not think I'm a moron, and
yes, I need to suspend^Wsnapshot the devices before, so I have that in
the snapshot. Of course, I'll need to resume^Wrestore the devices
before writing snapshot. That's okay, it does not take long.
You do NOT need
Hi!
And no, three different implementations doesn't cut it. Even _two_ is
too much. We need to get *rid* of something, not add more.
swsusp can be dropped. It is nice -- self contained, extremely easy to
setup, Andrew likes it. uswsusp has all the features, and pretty
elegant
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 never hear from
the
On Wed, 25 Apr 2007, Pavel Machek wrote:
But ... you are really using suspend-to-disk as a workaround for my
desktop takes too much power when idle.
While rare is the day admittedly, that my machine isn't on, there are
days I take a break from lng days and won't work for 2-5 days at
a
On Wed, 25 Apr 2007, Adrian Bunk wrote:
Some people might boot Windows between suspending and resuming.
Oh yeah- that, too. Since iTunes doesn't work well with VMWare, I do this
all the time.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630
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 for suspend.
THEY HAVE ABSOLUTELY NOTHING IN COMMON!
Nobody in
On Wed, 25 Apr 2007, Adrian Bunk wrote:
For me it was a serious regression if STD was removed without any
replacement.
Amen. I have even made material donations to the SS2 effort to give the
developer what he'd needed to fix an issue with a certain configuration
and will do so again if need
Pavel Machek wrote:
STD needs to snapshot system, and then it needs devices to be
suspended so that snapshot is consistent.
One question though, there are devices that can be suspended (broken
suspend) and restore in such a case wouldn't work at all. The only
possible way would be then to
Hi!
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 for suspend.
THEY HAVE ABSOLUTELY NOTHING IN COMMON!
Nobody in their right mind thinks that
Linus Torvalds wrote:
Tell me, what does suspend do, and what does freeze (snapshot) do?
And name *one* thing that have in common.
I'll tell you: Nada. Zero. Zilch. Nothing.
Freeze for a disk is a total no-op. There is no DMA, there is no
nothing. In contrast, suspend for a disk is a
Hi!
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 for suspend.
THEY HAVE ABSOLUTELY NOTHING IN COMMON!
Nobody in their right mind thinks that
Tell me, what does suspend do, and what does freeze (snapshot) do?
And name *one* thing that have in common.
Both of them have to ensure you can make a consistent snapshot. Doing
that means you've got to be able to define a single point at which the
snapshot is made and is internally
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 missing.
And by hibernation, you mean what? You mean snapshot +
On Thu, 26 Apr 2007, Pavel Machek wrote:
Suspend syncs caches/spins down. Freeze does not do anything.
That's okay, I keep claiming freeze is subset of suspend. Can you
name device where that is not true?
Sure. Like just about any PCI device that doesn't do things on its own.
A freeze
On Wed, 25 Apr 2007, Chuck Ebbert wrote:
Freeze is a subset of suspend, isn't it? (It might be an empty subset
in some cases.)
NO IT IS NOT!
Yes, you are parroting Pavel, but he can say it a million times, and it's
*still* not true.
That's like saying read() is a subset of write(), isn't
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.
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 about it for five
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!
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 snapshot +
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
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 and
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 done the
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 changes to
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 engine
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_ consistent with
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 (becasue there is
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 that
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
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:
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 that
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 sure why Linus
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 state
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 most - up to
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.
I've
201 - 300 of 320 matches
Mail list logo
