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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <200702262223.14974.rjw@sisk.pl>
Date:	Mon, 26 Feb 2007 22:23:14 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Andrey Borzenkov <arvidjaar@...l.ru>
Cc:	"Lebedev, Vladimir P" <vladimir.p.lebedev@...el.com>,
	"Karasyov, Konstantin A" <konstantin.a.karasyov@...el.com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pm@...ts.osdl.org, Andrew Morton <akpm@...l.org>
Subject: Re: 2.6.19: ACPI reports AC not present after resume from STD

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/