linux-kernel - [Bisected] Suspend-to-disk fails on a 32-bit x86 system since commit 92923ca

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 21 Mar 2017 16:13:58 +0300
From:   Evgenii Shatokhin <eugene.shatokhin@...dex.ru>
To:     Nathan Zimmer <nzimmer@....com>
Cc:     Mel Gorman <mgorman@...e.de>, Pekka Enberg <penberg@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: [Bisected] Suspend-to-disk fails on a 32-bit x86 system since commit
 92923ca

Hi,

It seems, there is a regression in the kernel that prevents 
suspend-to-disk from working properly on some x86 machines with 32-bit 
Linux systems (ROSA Linux, in this case).

With the mainline kernels 4.2 - 4.10, it takes more than 2 minutes from 
"systemctl hibernate" command till the system powers off. When I try to 
resume the system after that, the system hangs with black screen after 
"Image loading progress 100%" (no ssh access, no reaction to keyboard, 
etc.).

For comparison, it takes less than 10-15 seconds from "systemctl 
hibernate" command till the poweroff when I use kernel 4.1, and the 
system resumes OK then.

Hardware info: https://linux-hardware.org/index.php?probe=e6a06c64c7
Kernel config, just in case: http://pastebin.com/P8vb9qi6

The problem does not show up in a 64-bit system installed on the same 
machine.

Bisection points at the following commit as the first "bad" one:

commit 92923ca3aacef63c92dc297a75ad0c6dfe4eab37
Author: Nathan Zimmer <nzimmer@....com>
Date:   Tue Jun 30 14:56:48 2015 -0700

     mm: meminit: only set page reserved in the memblock region

I reverted it and suspend-to-disk and resume now work OK when I use the 
mainline kernels 4.2 - 4.10.

For the kernels 4.8 - 4.10, I also had to disable CONFIG_RANDOMIZE_BASE 
but that is due to an unrelated issue, which I will report separately.

Regards,
Evgenii