On Monday, 26 February 2007 21:35, Andrey Borzenkov wrote:
> On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
> >
> > The patch looks good, but the changelog does not. First, AFAICT, the
> > x86_64 code doesn't touch anything outside the e820 map. Why do you think
> > it does?
> >
>
> the following code:
>
> paddr = round_down(e820.map[0].addr + e820.map[0].size, PAGE_SIZE);
> for (i = 1; i < e820.nr_map; i++) {
> struct e820entry *ei = &e820.map[i];
>
> if (paddr < ei->addr)
> e820_mark_nosave_range(paddr,
> round_up(ei->addr, PAGE_SIZE));
>
> obviously will mark region *between* two e820 regions if they are not
> adjacent. I do not say that it is wrong (I have no idea); but exactly because
> I have no idea I tried to avoid it.
Yes, you are right, sorry. We have to do this for x86_64, because there are
such holes in there on machines with more than 2 GB of RAM and swsusp chokes
on them if they are not marked.
On i386 we shouldn't really mark reserved areas in the highmem zone(s) as
nosave, because they are handled in a different way.
> > Second, it is not true that the region in question is at 0xee00 on x86_64.
> > At least on my box it's above the end of RAM.
> >
>
> On my box the problem region starts at ee800 :) But you are right, it does not
> belong here.
>
> > I think the x86_64 version is correct too.
> >
>
> I do not say it is not. I just say that it does something I cannot verify so I
> better avoid it (i.e. I better change existing behaviour as little as
> possible).
OK
Can you please test your patch with the loop in e820_mark_nosave_regions()
restricted to the zones below highmem?
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
