public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Michael Frank <mhf@linuxmail.org>
Cc: Nigel Cunningham <ncunningham@users.sourceforge.net>,
	linux-kernel@vger.kernel.org
Subject: Re: Reserved page flaging of 2.4 kernel memory changed recently?
Date: Tue, 10 Feb 2004 19:51:37 +0100	[thread overview]
Message-ID: <20040210185137.GD4478@dualathlon.random> (raw)
In-Reply-To: <200402100625.41288.mhf@linuxmail.org>

On Tue, Feb 10, 2004 at 11:24:01PM +0800, Michael Frank wrote:
> By what I read on LKML, 64bit is probably more fussy then 32bit. eg when 
> accessing non-existing memory such as on a system with memory holes 
> with /dev/mem often causes MCE's. 

yes, this happens on ia64 and it may happen on x86-64 too.

> And here is an example of touching non-RAM going wrong on a x86 PC:
> 
> One swsusp user received a MCE on swsusp accessing 0xa0000 (video). 
> This seems to be quite recent hardware: a Athlon mobile XP 20000.
> This Compaq evo is running alright with NOMCE on the commandline.

this is possible too.

> Here is a patch for 2.4.2[45], which marks non-ram, CPU-broken-pages, and 
> nosave kernel-pages pages with PG_nosave. 
> 
> Applications such as swsusp, netdump or debuggers have just to check 
> the PG_nosave bit to be safe.
> 
> I actually would like to rename the bit PG_nosave to PG_donttouch ;)

;)

> 
> diff -uN -r -X /home/mhf/sys/dont/dontdiff linux-2.4.24-Vanilla/arch/i386/mm/init.c linux-2.4.24-mhf179/arch/i386/mm/init.c
> --- linux-2.4.24-Vanilla/arch/i386/mm/init.c	2004-01-21 15:53:01.000000000 +0800
> +++ linux-2.4.24-mhf179/arch/i386/mm/init.c	2004-02-10 06:15:31.000000000 +0800
> @@ -451,15 +451,18 @@
>  {
>  	if (!page_is_ram(pfn)) {
>  		SetPageReserved(page);
> +		SetPageNosave(page);
>  		return;
>  	}
>  	
>  	if (bad_ppro && page_kills_ppro(pfn)) {
>  		SetPageReserved(page);
> +		SetPageNosave(page);
>  		return;
>  	}
>  	
>  	ClearPageReserved(page);
> +	ClearPageNosave(page);

why this clearpagenosave? looks superflous, you're not doing it in the
normal zone anyways.

> +#if defined(__nosave_begin)

this won't work right, __nosave_begin isn't a preprocessor thing so it
will be ignored when you uncomment it. You probably can use #if 0
instead and a comment near __nosave_begin to turn it to 1 when enabling
the suspend code.

> What is your opinion of this approach?

except for the above two nitpicks, the patch is correct and needed for
safe suspend IMHO. 2.6 seems to miss this thing too, why not add it to
2.6 first?

> BTW, The patch below is needed to run it with a nosave region on 
> Vanilla 2.4.2[45]:
> 
> diff -ruN linux-2.4.24/arch/i386/vmlinux.lds software-suspend-linux-2.4.24-rev7/arch/i386/vmlinux.lds
> --- linux-2.4.24/arch/i386/vmlinux.lds	2004-01-22 19:46:03.000000000 +1300
> +++ software-suspend-linux-2.4.24-rev7/arch/i386/vmlinux.lds	2004-01-30 15:23:38.000000000 +1300
> @@ -53,6 +53,12 @@
>    __init_end = .;
>  
>    . = ALIGN(4096);
> +  __nosave_begin = .;
> +  .data_nosave : { *(.data.nosave) }
> +  . = ALIGN(4096);
> +  __nosave_end = .;
> +
> +  . = ALIGN(4096);
>    .data.page_aligned : { *(.data.idt) }
>  
>    . = ALIGN(32);
> 
> also uncomment in mm/init.c the line:
> //extern char __nosave_begin, __nosave_end; 

yep.

  reply	other threads:[~2004-02-10 18:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-05  2:07 Reserved page flaging of 2.4 kernel memory changed recently? Michael Frank
2004-02-08  2:06 ` Andrea Arcangeli
2004-02-10 15:24   ` Michael Frank
2004-02-10 18:51     ` Andrea Arcangeli [this message]
2004-02-10 19:38       ` Michael Frank
2004-02-11  8:36       ` Michael Frank
2004-02-19  7:26     ` Pavel Machek
2004-02-19  9:00       ` Michael Frank
2004-02-19 16:14         ` Pavel Machek
2004-02-19 17:37           ` Michael Frank
2004-02-19 17:35             ` Pavel Machek
2004-02-19 17:59               ` Michael Frank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040210185137.GD4478@dualathlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhf@linuxmail.org \
    --cc=ncunningham@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox