Subject: Re: swsusp update: supports discontingmem/highmem
From: Nigel Cunningham <ncunningham@users.sourceforge.net>
Reply-To: ncunningham@users.sourceforge.net
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@zip.com.au>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <20040405212354.GA3633@elf.ucw.cz>
References: <20040405212354.GA3633@elf.ucw.cz>
Content-Type: text/plain
Message-Id: <1081203867.2577.11.camel@calvin.wpcb.org.au>
Mime-Version: 1.0
Date: Tue, 06 Apr 2004 08:24:28 +1000
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1369
Lines: 45

Hi.

On Tue, 2004-04-06 at 07:23, Pavel Machek wrote:
> +		if (PageReserved(page)) {
> +			printk("highmem reserved page?!\n");
> +			BUG();
> +		}

We dealt with this recently in suspend2. It's perfectly valid to have a
Reserved Highmem page. They need to be completely ignored, and whatever
driver is responsible for the memory should handle any required state
persistance. We're setting NoSave for such pages in the parsing of the
e820 table at boot time.

> +		if (!save)
> +			panic("Not enough memory");

Can't you back out nicely if you don't have enough memory for the image?

> +		if (!save->data)
> +			panic("Not enough memory");

(Ditto)
 
> +	/* Fixme: this is too late; we should do this ASAP to avoid "infinite reboots" problem */

Fully agree. I've been meaning to do this too.

Regards,

Nigel
-- 
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.

-
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/