Bug 97211

Summary:	Repetitive s2both may fail if "threads = y" in suspend.conf
Product:	Power Management	Reporter:	Rainer Fiebig (jrf)
Component:	Hibernation/Suspend	Assignee:	Rafael J. Wysocki (rjw)
Status:	CLOSED INVALID
Severity:	low	CC:	aaron.lu
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	4.0 and earlier	Subsystem:
Regression:	No	Bisected commit-id:

Description Rainer Fiebig 2015-04-24 10:46:47 UTC

After 2 successful s2both/resume in a row, the immediately following s2both aborts after only a part of the image has been written to disk (originally reported as Bug 83821).

Turned out this happens only with s2both (not s2disk) AND if "threads = y" in /etc/suspend.conf AND if memory usage is low (for instance after a system start).

It can be prevented by setting "threads = n". 

An alternative solution/workaround can be found under 2) in Comment 72 in the report for Bug 47931.

Comment 1 Aaron Lu 2015-04-28 07:26:57 UTC

It looks like to me, s2both is entirely implemented in user space?

Comment 2 Rainer Fiebig 2015-04-28 17:45:32 UTC

(In reply to Aaron Lu from comment #1)
> It looks like to me, s2both is entirely implemented in user space?

That's right, afaik. In my system it's implemented by /usr/lib/pm-utils/module.d/uswsusp. Some parameters can be changed in suspend.conf.

From a section of uswsusp:

if [ -z "$SUSPEND_HYBRID_MODULE" ] && 
	grep -q mem /sys/power/state && \
	command_exists s2both && \
	check_hibernate; then
	SUSPEND_HYBRID_MODULE="uswsusp"
	do_suspend_hybrid()
	{
		# bnc#304995 workaround
		export SUSE_IGNORE_FBMODES="true"
		get_s2ram_opts
		if [ -z "${S2DISK_CONF}" ]; then
			s2both --force $S2RAM_OPTS
		else
			s2both --config $S2DISK_CONF $S2RAM_OPTS
		fi
	}
	if [ "$METHOD" = "suspend_hybrid" ]; then
		add_before_hooks uswsusp_hooks
		add_module_help uswsusp_help
	fi
fi
--

I use a little script in /etc/pm/config.d in order to execute s2both instead of s2ram: 

if [ "$METHOD" = "suspend" ]; then
METHOD=suspend_hybrid
fi
--

Comment 3 Aaron Lu 2015-05-04 02:36:36 UTC

Then can you please report this problem for that tool? We only deal with kernel bugs here, thanks.

Comment 4 Rainer Fiebig 2015-05-04 10:08:59 UTC

(In reply to Aaron Lu from comment #3)
> Then can you please report this problem for that tool? We only deal with
> kernel bugs here, thanks.

Are you kidding me?

I first described this issue in Comment 54 in the thread for Bug 81551 and asked (!) whether to file a bug report here.

The answer from Rafeal J. Wysocki in Comment 56 was:

"Yes, a new report, please."

Annoying.

So waste your own time and report this yourself - wherever you think it fits!

Thanks.

Comment 5 Aaron Lu 2015-05-05 01:57:16 UTC

No I'm not, I'm not good at kidding in English so I seldom do that :-)

Well, first, I didn't follow 81551 closely and didn't notice those words and I thought it is reported due to bug 47931 where I asked you to file a new bug about the too high MEM_MAP memory issue; second, different people have different opinions and I don't think we should handle user space bugs in kernel bugzilla, but that didn't stop other people from taking a look at this for you if they want to.

Anyway, feel free to reopen it if you don't think it should be closed.

Comment 6 Rainer Fiebig 2015-05-05 10:52:23 UTC

(In reply to Aaron Lu from comment #5)

snip
> 
> Anyway, feel free to reopen it if you don't think it should be closed.

Not worth the hassle. 

I'd rather continue enjoying my world-monopoly for endlessly repetitive s2boths with the aforementioned setup.

No kidding!