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 versions.
>
> The 'promise' is 'if you can get echo disk > /sys/power/state working,
> uswsusp will work. too'. IOW it should be ok to debug the in-kernel
> parts, only.
Hello Nigel, Pavel, Rafael and everyone else who is involved,
I would like to ask what come out of the suspend2 merge discussion. Nigel
just told that suspend2 likely won't be merged anytime soon and thats its
business as usual:
---------------------------------------------------------------------
It's pretty much business as usual. Linus doesn't want another
implementation merged, and he wants the three of us (Pavel, Rafael and
myself) to agree on a way forward. He also believes that we're
approaching things from the wrong direction at the moment. Funnily
enough, this is the one area on which we do all agree.
---------------------------------------------------------------------
http://lists.suspend2.net/lurker/message/20070510.021641.fe306add.en.html
Has there been any further discussion and preferably agreement on the way
to go forward?
Although you Linus, as I read from different mails only use suspend to
RAM, there are many users out there who use suspend to disk daily.
I used in kernel software suspend initially and it worked quite nice with
starting from 2.6.10 or 2.6.11 where suspend2 didn't work for me before
2.6.14 with the hibernate script. But from then on suspend2 worked better
than in kernel software suspend for me and colleagues on:
- ThinkPad T23
- ThinkPad T42
- Possibly some other ThinkPads
- as well various Dell workstations we have at work
It was faster and more reliable, yielding uptimes up to 40 days on my
workstation recently (with 2.6.17.7 still). And even that uptime was only
ended by booting a newly build kernel (2.6.21 with sws 2.2.9.13). For me
in the role of a user actually this is a really satisfying solution!
I tried userspace software suspend from time to time but then just was fed
up with it, cause I could not get it to work within any sensible amount
of time - even with some bog standard Debian kernel, I think it was some
2.6.18 one. Maybe I am dumb, but so be it, it should not be that
complicated to get it to work. Recently I didn't even bother to try
anymore. Well and I read in the suspend2 merge discussion that even in
kernel suspend does not work reliably anymore.
As long I cannot be convinced that the vanilla kernel contains a suspend
to disk solution that works as good as suspend2 I will patch suspend2
into all of the desktop kernels I build.
Thats quite bad IMHO for exactly the same reason than having drivers
maintained out of the kernel. For the same reason I think swap prefetch
should go in as soon as possible. It will never have the adoption and
care taking of an in-kernel-tree solution.
I am convinced that a working suspend to RAM just is not enough - well it
wasn't working correctly last time I checked. But I even don't bother
about suspend to RAM anymore. I can wait those additional seconds for
suspend to disk and it allows me to drive my laptops without batteries
most of the time and have workstations switched off completely so that
they do not consume standby power.
So please, pretty please consider working together on a reliable, fast,
stable, easy to use and configurable in-kernel-tree snapshot solution!
Actually I as a user I couldn't care less about the implementation
details, but as someone who is interested in kernel technologies I like
it to be a clean and well designed solution, too. ;-)
Maybe when the Linux Foundation organizes a meeting for Nigel, Pavel,
Rafael and other kernel developers interested in creating such a solution
it will help. To me it seems such a concentrated meeting in a good
atmosphere could be more effective than endless mailing list discussions
not leading to a clear result. When its not easy for the involved people
to work together maybe a casual bystander who understands enough of
kernel details should moderate the meeting and help finding an agreement.
It would just be such a pity to miss the chance to have a nicely working
snapshot solution in the Linux kernel, that may even be interesting for
virtualization (you could store a backup of a machine state permanently
or even more of them - if not already available through other
technologies like well suspend2 with filewriter for example).
Regards,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
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 the interaction between many different
> > > parts with different versions.
> >
> > The 'promise' is 'if you can get echo disk > /sys/power/state working,
> > uswsusp will work. too'. IOW it should be ok to debug the in-kernel
> > parts, only.
>
> Hello Nigel, Pavel, Rafael and everyone else who is involved,
>
> I would like to ask what come out of the suspend2 merge discussion. Nigel
> just told that suspend2 likely won't be merged anytime soon and thats its
> business as usual:
>
> ---------------------------------------------------------------------
> It's pretty much business as usual. Linus doesn't want another
> implementation merged, and he wants the three of us (Pavel, Rafael and
> myself) to agree on a way forward. He also believes that we're
> approaching things from the wrong direction at the moment. Funnily
> enough, this is the one area on which we do all agree.
> ---------------------------------------------------------------------
> http://lists.suspend2.net/lurker/message/20070510.021641.fe306add.en.html
>
>
> Has there been any further discussion and preferably agreement on the way
> to go forward?
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 suspend2 doesn't solve
and that IMHO are more urgent than the merging of suspend2 right not.
So, as far as I'm concerned, the plan is to fix the more urgent problems first
and to work on merging suspend2 as far as there's time to do this.
The problem is there are only a few people working on it and there's a lot to
do, so I can only ask you to be patient. ;-)
Greetings,
Rafael
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 suspend2
> doesn't solve and that IMHO are more urgent than the merging of
> suspend2 right not.
>
> So, as far as I'm concerned, the plan is to fix the more urgent
> problems first and to work on merging suspend2 as far as there's time
> to do this.
>
> The problem is there are only a few people working on it and there's a
> lot to do, so I can only ask you to be patient. ;-)
Thats fine with me - I understand that. I just thought that there has been
no outcome at all.
I will try to be patient as long as I do not dig into kernel hacking
myself deeply enough to be able to help with that - did not do more than
to put together two conflicting patches to compile my own kernels till
now and forward port a patch for a sundance network card. I can help
with testing once there is something testable tough.
Regards,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7