Date:	Sun, 25 Feb 2007 20:14:22 +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, Andrew Morton <akpm@...l.org>
Subject: Re: 2.6.19: ACPI reports AC not present after resume from STD

On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
> On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:
> > On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
> > > On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:
> > > > 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.
> > >
> > > Great job, thanks for the patch!  It looks good, so I'm going to
> > > forward it for merging.
> >
> > Please no; I'm currently testing slightly more polished version; I will
> > send it later.
>
> OK
>
> > Could anybody explain (or give pointer to) what happens which region that
> > is not page-aligned? In particular, the very first one:
> >
> >  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> >  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> >
> > Will the kernel allocate partial page (how?) or will the kernel ignore
> > last (first) incomplete page? In the former case how those incomplete
> > pages can be detected?
>
> Well, on x86_64, if I understand e820_register_active_regions() correctly,
> the partial pages won't be registered.
>

It appears that for low memory kernel will ignore incomplete pages for sure. I 
hope it does the same for high memory - but for now I just throw this in and 
pray :) This also significantly simplifies patch.

As this touches quite sensitive field, I Cc Andrew - if he considers this 
appropriate for mm; or would you do it as part of your tree? Also he probably 
can easily clarify memory allocation questions :p

regards

-andrey

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

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists