On Sunday, 25 February 2007 18:14, Andrey Borzenkov wrote:

On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:

quoted

On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:

quoted

On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:

quoted

On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:

quoted

On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:

quoted

Hi,

On Saturday, 24 February 2007 10:55, Andrey Borzenkov wrote:

quoted

On Вторник 13 февраля 2007, Andrey Borzenkov wrote:

quoted

On Четверг 07 декабря 2006, Lebedev, Vladimir P wrote:

quoted

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

quoted

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 :)

You don't need to do this for highmem, because swsusp won't save reserved
highmem pages anyway.

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

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?

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.

I think the x86_64 version is correct too.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html