Thread (10 messages) 10 messages, 2 authors, 2007-02-26

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

From: Rafael J. Wysocki <hidden>
Date: 2007-02-25 10:58:07
Also in: linux-acpi, lkml

On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:
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
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.

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help