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

From: Andrey Borzenkov <arvidjaar@mail.ru>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-acpi@vger.kernel.org, linux-pm@lists.osdl.org,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.19: ACPI reports AC not present after resume from STD
Date: Sun, 25 Feb 2007 13:37:07 +0300	[thread overview]
Message-ID: <200702251337.08914.arvidjaar@mail.ru> (raw)
In-Reply-To: <200702251117.30462.rjw@sisk.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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?

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFF4WbUR6LMutpd94wRAoOVAKDNZxeHKRJ+8IVVpR2zZZF5dTYEDACg0hKi
7dffkAFBZnBSQ/3VkNP6tFU=
=nezM
-----END PGP SIGNATURE-----
_______________________________________________
linux-pm mailing list
linux-pm@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/linux-pm