Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261205AbUCAJkm (ORCPT ); Mon, 1 Mar 2004 04:40:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261184AbUCAJkl (ORCPT ); Mon, 1 Mar 2004 04:40:41 -0500 Received: from gprs153-254.eurotel.cz ([160.218.153.254]:34944 "EHLO amd.ucw.cz") by vger.kernel.org with ESMTP id S261205AbUCAJke (ORCPT ); Mon, 1 Mar 2004 04:40:34 -0500 Date: Mon, 1 Mar 2004 10:40:23 +0100 From: Pavel Machek To: M?ns Rullg?rd Cc: linux-kernel@vger.kernel.org Subject: Re: Dropping CONFIG_PM_DISK? Message-ID: <20040301094023.GF352@elf.ucw.cz> References: <1ulUA-33w-3@gated-at.bofh.it> <20040229161721.GA16688@hell.org.pl> <20040229162317.GC283@elf.ucw.cz> <20040229181053.GD286@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1850 Lines: 43 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?] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/