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 regardsWell, 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