Pavel Machek <[email protected]> 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
[email protected]
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?]
Pavel Machek <[email protected]> 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
[email protected]
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.
On Mon, 01 Mar 2004 11:08:01 +0100, M?ns Rullg?rd <[email protected]> wrote:
> Pavel Machek <[email protected]> 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: [email protected]
Regards
Michael
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.
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
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.
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?]