Dropping CONFIG_PM_DISK?

Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
It seems noone is maintaining it, equivalent functionality is provided
by swsusp, and it is confusing users...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

On Sun, 2004-02-29 at 10:00, Pavel Machek wrote:
> Hi!
> 
> Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> It seems noone is maintaining it, equivalent functionality is provided
> by swsusp, and it is confusing users...

Except that pmdisk code is +/- readable, swsusp is not...

Ben.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

On Ne 29-02-04 10:52:01, Benjamin Herrenschmidt wrote:
> On Sun, 2004-02-29 at 10:00, Pavel Machek wrote:
> > Hi!
> > 
> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> > It seems noone is maintaining it, equivalent functionality is provided
> > by swsusp, and it is confusing users...
> 
> Except that pmdisk code is +/- readable, swsusp is not...

Would you be willing to either maintain pmdisk or (preffered) split it
up and submit me pieces?

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

> > Except that pmdisk code is +/- readable, swsusp is not...
> 
> Would you be willing to either maintain pmdisk or (preffered) split it
> up and submit me pieces?

Heh, if I had time ... :)

Ben.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> > > Except that pmdisk code is +/- readable, swsusp is not...
> > 
> > Would you be willing to either maintain pmdisk or (preffered) split it
> > up and submit me pieces?
> 
> Heh, if I had time ... :)

Well, unless someone steps up, I guess I'll just let it bitrot, and
when its broken enough, I'll attempt removal. I really do not have
time to maintain two implementations...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Nigel Cunningham]

I'd like to work on patching it into suspend2. I'm being real slow at
the moment because I'm not working on suspend much at all, but that
doesn't mean I don't want to do anything :>

Regards,

Nigel

On Mon, 2004-03-01 at 01:40, Pavel Machek wrote:
> Hi!
> 
> > > > Except that pmdisk code is +/- readable, swsusp is not...
> > > 
> > > Would you be willing to either maintain pmdisk or (preffered) split it
> > > up and submit me pieces?
> > 
> > Heh, if I had time ... :)
> 
> Well, unless someone steps up, I guess I'll just let it bitrot, and
> when its broken enough, I'll attempt removal. I really do not have
> time to maintain two implementations...
> 								Pavel
-- 
My work on Software Suspend was graciously brought to you between
October and January by LinuxFund.org.

Re: Dropping CONFIG_PM_DISK?

[Romano Giannetti]

On Sun, Feb 29, 2004 at 12:00:40AM +0100, Pavel Machek wrote:
> Hi!
> 
> Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> It seems noone is maintaining it, equivalent functionality is provided
> by swsusp, and it is confusing users...
> 								Pavel

Last time I tried (2.6.1) PM_DISK was the only suspend mechanism that worked
on my vaio with ACPI enabled (PGC-FX701). I had not time (my humble
apologies to Nigel) to make more tests, I've been swamped with a conference
deadline, but I can try to help finding out the problem in the next weeks, I
hope. 

Romano

-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569

Re: Dropping CONFIG_PM_DISK?

[Karol Kozimor]

Thus wrote Pavel Machek:
> Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> It seems noone is maintaining it, equivalent functionality is provided
> by swsusp, and it is confusing users...

It may be ugly, it may be unmaintained, but I get the impression that it
works for some people for whom swsusp doesn't. So unless swsusp works for
everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> > It seems noone is maintaining it, equivalent functionality is provided
> > by swsusp, and it is confusing users...
> 
> It may be ugly, it may be unmaintained, but I get the impression that it
> works for some people for whom swsusp doesn't. So unless swsusp works for
> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.

Do you have example when pmdisk works and swsusp does not? I'm not
aware of any in recent history...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

> Hi!
>
>> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>> > It seems noone is maintaining it, equivalent functionality is provided
>> > by swsusp, and it is confusing users...
>> 
>> It may be ugly, it may be unmaintained, but I get the impression that it
>> works for some people for whom swsusp doesn't. So unless swsusp works for
>> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>
> Do you have example when pmdisk works and swsusp does not? I'm not
> aware of any in recent history...

For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
to get pmdisk to resume once, and swsusp2 makes it half-way through
the resume.  The old swsusp doesn't even get that far.

-- 
Måns Rullgård
mru@kth.se

Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Sun, 29 Feb 2004 18:32:21 +0100, Måns Rullgård <mru@kth.se> wrote:

> Pavel Machek <pavel@ucw.cz> writes:
>
>> Hi!
>>
>>> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>>> > It seems noone is maintaining it, equivalent functionality is provided
>>> > by swsusp, and it is confusing users...
>>>
>>> It may be ugly, it may be unmaintained, but I get the impression that it
>>> works for some people for whom swsusp doesn't. So unless swsusp works for
>>> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>>
>> Do you have example when pmdisk works and swsusp does not? I'm not
>> aware of any in recent history...
>
> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> to get pmdisk to resume once, and swsusp2 makes it half-way through
> the resume.

Hate to hear this - 2.0 is said to work _flawlessly_ on 2.4.24 and
on 2.6.2 within the bounds of more complex PM/driver issues.

2.4.25 and 2.6.3 patches are undergoing testing.

If you like to try again, please have a look at http://swsusp.sf.net.

There is also comprehensive FAQ and Howto on the site.

You also will find a lot of user support wrt specific HW.

Myself is running 2.0 on 2.4.2[345] without any stability issues
whatsoever this year.

In short, I am confident we can make it work for you!

Regards
Michael

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> >> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> >> > It seems noone is maintaining it, equivalent functionality is provided
> >> > by swsusp, and it is confusing users...
> >> 
> >> It may be ugly, it may be unmaintained, but I get the impression that it
> >> works for some people for whom swsusp doesn't. So unless swsusp works for
> >> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
> >
> > Do you have example when pmdisk works and swsusp does not? I'm not
> > aware of any in recent history...
> 
> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> to get pmdisk to resume once, and swsusp2 makes it half-way through
> the resume.  The old swsusp doesn't even get that far.

Try current swsusp with minimal drivers, init=/bin/bash.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Måns Rullgård]

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> >> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>> >> > It seems noone is maintaining it, equivalent functionality is provided
>> >> > by swsusp, and it is confusing users...
>> >> 
>> >> It may be ugly, it may be unmaintained, but I get the impression that it
>> >> works for some people for whom swsusp doesn't. So unless swsusp works for
>> >> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>> >
>> > Do you have example when pmdisk works and swsusp does not? I'm not
>> > aware of any in recent history...
>> 
>> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
>> to get pmdisk to resume once, and swsusp2 makes it half-way through
>> the resume.  The old swsusp doesn't even get that far.
>
> Try current swsusp with minimal drivers, init=/bin/bash.

Well, if I do that it works.  Or at least some old version did, I
assume the later ones would too.  However, that sort of removes the
whole point.  Taking down the system enough to be able to unload
almost everything is as close as rebooting you'll get.

BTW, is there some easier way to track the development than using the
patches from the web page?  Unpatching after a couple of BK merges
isn't the easiest thing.  Is there a BK tree somewhere I can pull
from?

-- 
Måns Rullgård
mru@kth.se

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> >> >> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> >> >> > It seems noone is maintaining it, equivalent functionality is provided
> >> >> > by swsusp, and it is confusing users...
> >> >> 
> >> >> It may be ugly, it may be unmaintained, but I get the impression that it
> >> >> works for some people for whom swsusp doesn't. So unless swsusp works for
> >> >> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
> >> >
> >> > Do you have example when pmdisk works and swsusp does not? I'm not
> >> > aware of any in recent history...
> >> 
> >> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> >> to get pmdisk to resume once, and swsusp2 makes it half-way through
> >> the resume.  The old swsusp doesn't even get that far.
> >
> > Try current swsusp with minimal drivers, init=/bin/bash.
> 
> Well, if I do that it works.  Or at least some old version did, I
> assume the later ones would too.  However, that sort of removes the
> whole point.  Taking down the system enough to be able to unload
> almost everything is as close as rebooting you'll get.

Well, now do a search for "which module/application causes failure".

> BTW, is there some easier way to track the development than using the
> patches from the web page?  Unpatching after a couple of BK merges
> isn't the easiest thing.  Is there a BK tree somewhere I can pull
> from?

Are you using swsusp2? That's _not_ what I'm talking about. swsusp is
in mainline.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

>> > Try current swsusp with minimal drivers, init=/bin/bash.
>> 
>> Well, if I do that it works.  Or at least some old version did, I
>> assume the later ones would too.  However, that sort of removes the
>> whole point.  Taking down the system enough to be able to unload
>> almost everything is as close as rebooting you'll get.
>
> Well, now do a search for "which module/application causes failure".

I know, it just takes an awful time.

>> BTW, is there some easier way to track the development than using the
>> patches from the web page?  Unpatching after a couple of BK merges
>> isn't the easiest thing.  Is there a BK tree somewhere I can pull
>> from?
>
> Are you using swsusp2?

Well, trying to.  Isn't it supposed to be the latest and greatest?

> That's _not_ what I'm talking about. swsusp is in mainline.

It would still be the same module(s) that caused it to fail, right?

-- 
Måns Rullgård
mru@kth.se

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> >> > Try current swsusp with minimal drivers, init=/bin/bash.
> >> 
> >> Well, if I do that it works.  Or at least some old version did, I
> >> assume the later ones would too.  However, that sort of removes the
> >> whole point.  Taking down the system enough to be able to unload
> >> almost everything is as close as rebooting you'll get.
> >
> > Well, now do a search for "which module/application causes failure".
> 
> I know, it just takes an awful time.

Binary search should be pretty fast.

> >> BTW, is there some easier way to track the development than using the
> >> patches from the web page?  Unpatching after a couple of BK merges
> >> isn't the easiest thing.  Is there a BK tree somewhere I can pull
> >> from?
> >
> > Are you using swsusp2?
> 
> Well, trying to.  Isn't it supposed to be the latest and greatest?

It is latest, but not most stable.

								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: Dropping CONFIG_PM_DISK?

[Nigel Cunningham]

Can you provide specific examples? I can fix bugs if I'm given
reproducible issues instead of hand waving :>

Nigel

On Mon, 2004-03-01 at 23:39, Pavel Machek wrote:
> It is latest, but not most stable.

-- 
My work on Software Suspend was graciously brought to you between
October and January by LinuxFund.org.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> Can you provide specific examples? I can fix bugs if I'm given
> reproducible issues instead of hand waving :>
> 

Try compiling with regparm=3; you are likely to find some
missing asmlinkages.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Dropping CONFIG_PM_DISK?

[Nigel Cunningham]

Forgive my ignorance, but I don't see how that could be something that
makes suspend2 less stable than the already-merged versions. They have
the same problem (assuming your patch hasn't been merged yet).

Regards,

Nigel

On Tue, 2004-03-02 at 01:46, Pavel Machek wrote:
> Hi!
> 
> > Can you provide specific examples? I can fix bugs if I'm given
> > reproducible issues instead of hand waving :>
> > 
> 
> Try compiling with regparm=3; you are likely to find some
> missing asmlinkages.
> 				Pavel
-- 
My work on Software Suspend was graciously brought to you between
October and January by LinuxFund.org.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> Forgive my ignorance, but I don't see how that could be something that
> makes suspend2 less stable than the already-merged versions. They have
> the same problem (assuming your patch hasn't been merged yet).

Okay... well...

swsusp2 is meant to be feature-full. in kernel swsusp is meant to be
stable. Perhaps swsusp2 manages to be both feature-full and stable at
same time; at that point I'm obviously doing not-too-good job.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Mon, 01 Mar 2004 11:08:01 +0100, Måns Rullgård <mru@kth.se> wrote:

> Pavel Machek <pavel@ucw.cz> writes:
>
>>> > Try current swsusp with minimal drivers, init=/bin/bash.
>>>
>>> Well, if I do that it works.  Or at least some old version did, I
>>> assume the later ones would too.  However, that sort of removes the
>>> whole point.  Taking down the system enough to be able to unload
>>> almost everything is as close as rebooting you'll get.
>>
>> Well, now do a search for "which module/application causes failure".
>
> I know, it just takes an awful time.
>
>>> BTW, is there some easier way to track the development than using the
>>> patches from the web page?  Unpatching after a couple of BK merges
>>> isn't the easiest thing.  Is there a BK tree somewhere I can pull
>>> from?
>>
>> Are you using swsusp2?
>
> Well, trying to.  Isn't it supposed to be the latest and greatest?
>
>> That's _not_ what I'm talking about. swsusp is in mainline.
>
> It would still be the same module(s) that caused it to fail, right?
>

Further to my post yesterday, here is a short article which may be of interest.

http://lwn.net/Articles/68747/

So, to make it work better lets get PM usable :)

swsusp2 mailing list: swsusp-devel@lists.sourceforge.net

Regards
Michael