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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200702250226.34877.arvidjaar@mail.ru>
Date:	Sun, 25 Feb 2007 02:26:31 +0300
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
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
Subject: Re: 2.6.19: ACPI reports AC not present after resume from STD

On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday, 24 February 2007 10:55, Andrey Borzenkov wrote:
> > On Вторник 13 февраля 2007, Andrey Borzenkov wrote:
> > > On Четверг 07 декабря 2006, Lebedev, Vladimir P wrote:
> > > > Please register new bug, attach acpidump and dmesg.
> > >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=7995
> > >
> > > regards
> >
> > Well, this starts looking like ACPI is not at fault.
> >
> > When reporting AC state ACPI just reads contents of system memory (I
> > presume it gets updated by BIOS/ACPI when AC state changes). It looks
> > like this memory area is restored during resume from STD. I updated
> > mentioned bug report with more detailed description. Now if someone could
> > suggest a way to catch if specific physical address gets saved/restored
> > this would finally explain it.
>
> First, if you want the reserved memory areas to be left alone by swsusp,
> you need to mark them as 'nosave'.  On x86_64 this is done by the function
> e820_mark_nosave_range() in arch/x86_64/kernel/e820.c that can be ported to
> i386 with no problems.  However, we haven't found that very useful, so far,
> since no one has ever reported any problems with the current approach,
> which is to save and restore them.
>

Well, the following proof of concept patch fixes this issue for me. Please 
notice that original version of e820_mark_nosave_range() could fail to 
exclude some areas due to alignment issues (exactly what happened to me on 
first try) so it still can explain your problem too.

-andrey


View attachment "nosave_reserved_memory" of type "text/x-diff" (4302 bytes)

Content of type "application/pgp-signature" skipped