Bug 13710

Hi, Alexey
    From the dmesg log it seems that the box can be resumed when there is no boot option of "acpi_sleep=". But there is no video. Right?
    If so, it seems that this is a graphics issue instead of an ACPI issue.
    Will you please do the following test to double check it? (Don't add the boot option of: "test_suspend=", "acpi_sleep="
    a. kill the process using the /proc/acpi/event
    b. assure that the i915 driver is loaded(If it is compiled as built-in kernel, please skip this step)
    c. dmesg >dmesg_before; echo mem > /sys/power/state; dmesg >dmesg_after; sync;
    d. press the power button and see whether the box can be resumed.
    e. reboot the system and see whether there exists the file of dmesg_after. If it exists, it is a graphics issue. Please file a new bug in https://bugs.freedesktop.org/

    At the same time from the dmesg log it seems that there exist two warning backtrace.
    1. PM: resume devices took 5.784 seconds
[   11.621574] ------------[ cut here ]------------
[   11.621579] WARNING: at kernel/power/suspend_test.c:52 suspend_test_finish+0x7c/0x80()
[   11.621580] Hardware name:       
       This is caused by that it will take more than five seconds to resume the device on this box. This is related with the following commit:
       >commit a9d7052363a6e06bb623ed1876c56c7ca5b2c6d8
       >Author: Rafael J. Wysocki <rjw@sisk.pl>
       >Date:   Wed Jun 10 01:27:12 2009 +0200

    PM: Separate suspend to RAM functionality from core 

    2. Corrupted low memory at ffff880000004200 (4200 phys) = 00420301
[   60.816163] ------------[ cut here ]------------
[   60.816169] WARNING: at arch/x86/kernel/check.c:134
       It seems that this is related with the hardware issue. After the CHECK_CORRUPTION is enabled in kernel configuration, it will check the possible memory corruption.When the memory corruption is detected, it will complain the above warning message.
      
    Thanks.

(In reply to comment #0)

> To make clean test i used test_suspend=mem with acpi_sleep options
> (s3_bios and/or s3_mode) and without acpi_sleep. Any acpi_sleep option will
> make my PC freeze.

that's right. these options don't work all the time.
sometimes they may freeze the laptop.

> Without acpi_sleep it will resume but with black screen and i can access
> it with ssh. Disabling kms will resume with black console but Xorg will
> enable video.

In order to get the video back, you MUST set CONFIG_DRM_I915_KMS.
why do you want to disable kms?

So I think the main problem here is the two warnings after resume.
 
> [   60.816159] Corrupted low memory at ffff880000004200 (4200 phys) =
> 00420301

I have no idea about this yet.

> [   11.621573] PM: resume devices took 5.784 seconds
> [   11.621574] ------------[ cut here ]------------
> [   11.621579] WARNING: at kernel/power/suspend_test.c:52
> suspend_test_finish+0x7c/0x80()

look at the suspend_test_finish source code.

        /* Warning on suspend means the RTC alarm period needs to be
         * larger -- the system was sooo slooowwww to suspend that the
         * alarm (should have) fired before the system went to sleep!
         *
         * Warning on either suspend or resume also means the system
         * has some performance issues.  The stack dump of a WARN_ON
         * is more likely to get the right attention than a printk...
         */
        WARN(msec > (TEST_SUSPEND_SECONDS * 1000), "Component: %s\n", label);

this doesn't seem like a problem to me.

So the only problem left is the low memory corruption.

Alexey Fisher,
please make sure the memory corruption also occurs on a real resume.

Created attachment 22226 [details]
dmesg _after

- agp and drm module are and was compiled in
- after real resume i get both warning: slow_path and memory corruption.

Yakui pointed me to this patch:
https://bugs.freedesktop.org/show_bug.cgi?id=21576#c16

It solves part of the problem. Now after resume i can get video back... but i still get this two traces.

Created attachment 22227 [details]
dmesg_after_w_patch

Hi, Alexey
    Thanks for the test.
    From the test it seems that the box can be resumed from S3. And the remaining issue is the two warning backtrace after resume.
    And these two issues are not related with the ACPI.
    a. The following backtrace is caused by that it will take more than five seconds to resume device. 
>[   11.621573] PM: resume devices took 5.784 seconds
> [   11.621574] ------------[ cut here ]------------
> [   11.621579] WARNING: at kernel/power/suspend_test.c:52
> suspend_test_finish+0x7c/0x80()
       And this is related with the following commit: (sorry that I give the incorrect commit).
   >ommit 77437fd4e61f87cc94d9314baa5cbf50e3ccdf54
Author: David Brownell <dbrownell@users.sourceforge.net>
Date:   Wed Jul 23 21:28:33 2008 -0700

    b. the second backtrace is related with the memory corruption check.

thanks.

So if i understand correctly:
- suspend_test trace is sort of spam and do not mean anything serious.. except you'll get a lot of wrong bug reports? 

- second trace ... should actually be handled by CONFIG_X86_RESERVE_LOW_64K, which is by enabled me. But it's not activated because BIOS vendor is "Intel Corp."

Created attachment 22230 [details]
intel_bios.diff

This patch solve the issue with memory corruption on Intel BIOS.

(In reply to comment #8)
> So if i understand correctly:
> - suspend_test trace is sort of spam and do not mean anything serious..
> except
> you'll get a lot of wrong bug reports? 
yes. This is not serious. It only comlains that the device resume time exceeds the predefined test time.

> - second trace ... should actually be handled by CONFIG_X86_RESERVE_LOW_64K,
> which is by enabled me. But it's not activated because BIOS vendor is "Intel
> Corp."
What you have done is right. Please send your patch to mailing list.

Thanks.

Hi, Rui
    From the log it seems that the issue of low memory corrupt can be fixed by the patch in comment 39.
    In fact this is not related with Linux ACPI. Even when the system is booted normally, it will complain that the low memory is corrupted when the patch in comment #9 is not applied.
    
    How about close this bug?
    Thanks.

I send this patch to mailinglist.

I did some more investigation and found that Windows have same issue on this board.

The patch is shipped in linux-tip tree.
>http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=6aa542a694dc9ea4344a8a590d2628c33d1b9431

So this bug can be marked as resolved.

Thanks.

6aa542a694dc9ea4344a8a590d2628c33d1b9431
x86: Add quirk for Intel DG45ID board to avoid low memory corruption

shipped in v2.6.31-rc5
closed