From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@suse.cz>
Cc: Andi Kleen <ak@suse.de>,
kernel list <linux-kernel@vger.kernel.org>,
paul.devriendt@amd.com
Subject: Re: BIOS overwritten during resume (was: Re: Asus L5D resume on battery power)
Date: Thu, 3 Mar 2005 09:02:47 +0100 [thread overview]
Message-ID: <200503030902.48038.rjw@sisk.pl> (raw)
In-Reply-To: <20050302235456.GB1439@elf.ucw.cz>
Hi,
On Thursday, 3 of March 2005 00:54, Pavel Machek wrote:
> Hi!
>
> > > > It seems that we write to the BIOS while moving the image, at least on my box,
> > > > which is quite not correct, IMO.
> > [-- snip --]
> > > >
> > > > IMO this may lead to unexpected results, like the mysterious reboots during
> > > > resume.
> > >
> > > Well, I always thought that ROM-BIOS is expected to
> > > be... well... read-only? Can you really write to your BIOS? [I know
> > > about Flash-BIOSen, but they are certainly not writable by "normal"
> > > write.] Plus we should overwrite it with same values...
> > >
> > > Anyway, IMO bios should be marked as reserved (and we should not be
> > > touching reserved pages). Can you verify that your BIOS is properly
> > > marked reserved? [Ccing l-k, this might be interesting.]
> >
> > It is, but that's even more interesting. Namely, the BIOS-e820 memory map
> > looks as follows:
> >
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> > BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 000000001ff40000 (usable)
> > BIOS-e820: 000000001ff40000 - 000000001ff50000 (ACPI data)
> > BIOS-e820: 000000001ff50000 - 0000000020000000 (ACPI NVS)
> > BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> >
> > and the pages in the first two reserved areas are properly marked as reserved.
> > Moreover, there is an apparent hole between a0000 and e0000 which also
> > is marked as reserved. However, we treat all of these pages as saveable
> > (a page is treated as non-saveable if it is marked as reserved _and_ satisfies
> > specific condition which is met by only one page on my system). Consequently,
> > during resume we try to overwrite all of these pages and we not only try to
> > write to (theoretically) read-only areas, but also we try to write to where there's
> > nothing. :-)
> >
> > Still, there are almost 3500 reserved pages on my system and I'm not sure that
> > we don't need to save at least some of them. Anyway, I'm attaching the full
> > list of pages that are marked as reserved and treated as saveable, so they get
> > overwritten during resume. Please have a look (these are virtual x86-64
> > addresses, but the mapping is straightforward).
>
> [looking at code]
>
> IIRC kernel code/data is marked as PageReserved(), that's why we need
> to save that :(. Not sure what to do with data e820 marked as
> reserved...
Perhaps we need another page flag, like PG_readonly, and mark the pages
reserved by the e820 as PG_reserved | PG_readonly (the same for the areas
that are not returned by e820 at all). Would that be acceptable?
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
next prev parent reply other threads:[~2005-03-03 8:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-25 21:37 Asus L5D resume on battery power Rafael J. Wysocki
[not found] ` <20050227170253.GH1441@elf.ucw.cz>
[not found] ` <200502271919.45767.rjw@sisk.pl>
[not found] ` <200503022250.12823.rjw@sisk.pl>
2005-03-02 22:05 ` BIOS overwritten during resume (was: Re: Asus L5D resume on battery power) Pavel Machek
2005-03-02 23:47 ` Rafael J. Wysocki
2005-03-02 23:54 ` Pavel Machek
2005-03-03 8:02 ` Rafael J. Wysocki [this message]
2005-03-04 11:04 ` Pavel Machek
2005-03-04 13:15 ` Rafael J. Wysocki
2005-03-04 14:44 ` Nigel Cunningham
2005-03-04 20:11 ` Pavel Machek
2005-03-04 23:26 ` Rafael J. Wysocki
2005-03-04 23:37 ` Nigel Cunningham
2005-03-05 0:51 ` Bernard Blackham
2005-03-04 23:41 ` Pavel Machek
2005-03-05 1:10 ` Nigel Cunningham
2005-03-05 9:08 ` Rafael J. Wysocki
2005-03-06 17:29 ` Rafael J. Wysocki
2005-03-06 19:41 ` Pavel Machek
2005-03-06 21:53 ` Rafael J. Wysocki
2005-03-04 14:21 ` Nigel Cunningham
2005-03-05 18:43 ` Rafael J. Wysocki
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=200503030902.48038.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.devriendt@amd.com \
--cc=pavel@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.