Re: Dropping CONFIG_PM_DISK?

[Pavel Machek <pavel@ucw.cz>]

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?]