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.
It looks like to me, s2both is entirely implemented in user space?
(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 --
Then can you please report this problem for that tool? We only deal with kernel bugs here, thanks.
(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.
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.
(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!