linux-kernel - swsusp on an AMD x2-64, 2.6.24: regression?

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <47A24072.4090001@msgid.tls.msk.ru>
Date:	Fri, 01 Feb 2008 00:41:06 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: swsusp on an AMD x2-64, 2.6.24: regression?

Since I upgraded from 2.6.23 to 2.6.24, suspend to
disk does not work anymore on this machine.  I'm
trying to debug this now, for several hours already,
without much luck so far.

The machine is based on AMD X2-64 (BE-2400) CPU and
NVidia MCP51PV (GeForce 6150/NForce 430) chipset.

Up until 2.6.23 (both 32- and 64-bit kernels), suspend/
resume worked just fine without any glitch.

With 2.6.24, it tries to suspend, saves pages to disk,
when prints this:

..Saving pages... done.
Sl
Suspending console(s)
_

At this point, nothing more happens.  It does not
react to keyboard or to any other external events,
only reset/poweroff helps.  Note the "Sl" stuff -
I guess it's a beginning of some message, but I
don't know which one.

After a hard reboot after that, the system resumes
from the saved image.

This happens with both 32- and 64-bits kernels, when
using either good'old `echo disk > /sys/power/state'
or when using s2disk from uswsusp (with 32bits kernel,
as this utility does not work with 64bits kernel when
compiled as 32bits application).  Note that when using
s2disk with 2.6.24, very similar picture is shown -
that same "Sl" line.

The only noticeable changes in my config (x86-64 one)
compared with the one from 2.6.23 is - I enabled tickless
(dyntics) and high-res timers, CPU_IDLE and FAIR_CGROUP_SCHED.
I recompiled the kernel without those options (on by one), --
the effect on suspend is exactly the same.

Is there anything I can do to further diagnose this?

Thanks!

/mjt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/