Re: 2.6.19: ACPI reports AC not present after resume from STD

["Rafael J. Wysocki" <rjw@sisk.pl>]

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