On Tue, Jul 23, 2013 at 12:16 PM, Michael Leun <lkml20130126@xxxxxxxxxxxxxxx> wrote: > On Tue, 23 Jul 2013 11:29:57 -0700 > Colin Cross <ccross@xxxxxxxxxxx> wrote: > >> On Tue, Jul 23, 2013 at 11:08 AM, Michael Leun >> <lkml20130126@xxxxxxxxxxxxxxx> wrote: >> > On Mon, 22 Jul 2013 16:55:58 -0700 >> > Colin Cross <ccross@xxxxxxxxxxx> wrote: >> > >> >> On Mon, Jul 22, 2013 at 4:02 PM, Michael Leun >> >> <lkml20130126@xxxxxxxxxxxxxxx> wrote: >> >> > On Mon, 6 May 2013 16:50:18 -0700 >> >> > Colin Cross <ccross@xxxxxxxxxxx> wrote: >> >> > >> >> >> Avoid waking up every thread sleeping in a futex_wait call >> >> >> during >> >> > [...] >> >> > >> >> > With 3.11-rc s2disk from suspend-utils stopped working: Frozen at >> >> > displaying 0% of saving image to disk. >> >> > >> >> > echo "1" >/sys/power/state still works. >> >> > >> >> > Bisecting yielded 88c8004fd3a5fdd2378069de86b90b21110d33a4, >> >> > reverting that from 3.11-rc2 makes s2disk working again. >> >> > >> >> >> >> I think the expanded use of the freezable_* helpers is exposing an >> >> existing bug in hibernation. The SNAPSHOT_FREEZE ioctl calls >> >> freeze_processes(), which sets the global system_freezing_cnt and >> >> pm_freezing. try_to_freeze_tasks then sends every process except >> >> current a signal which causes them all to end up in the >> >> refrigerator. The current task then returns back to userspace and >> >> continues its work to suspend to disk. If that task ever hits a >> >> call to try_to_freeze() in the kernel, it will see >> >> system_freezing_cnt and pm_freezing=true and freeze, and suspend >> >> to disk will hang forever. It could hit try_to_freeze() because >> >> of a signal delivered to the task, or from calling any syscall >> >> that uses a freezable_* helper like the one I added to sys_futex. >> >> >> >> I think the right solution is to add a flag to the freezing task >> >> that marks it unfreezable. I think PF_NOFREEZE would work, >> >> although it is normally used on kernel threads, can you see if the >> >> attached patch helps? >> > >> > That patch helps. >> > >> > BTW, the only machine I can reproduce this bug with is an i7-3630QM >> > notebook. Cannot reproduce on an Core Duo U1400 and cannot >> > reproduce on an i7 M 620. >> > >> > Are the sysreq backtraces still wanted? If so, any tip, how I could >> > get them saved? > > Darren Hart <dvhart@xxxxxxxxxxxxxxx> wrote: > >> Typically by setting up a serial console or a netconsole and saving > [...] >> Is this what you are asking? > > Yes, and it indeed works - I halfway expected the net / netconsole > stuff being already frozen in that situation... > > Thanks, Darren - see below for the backtraces. > >> >> Any chance that the failing machine has threads=y in the suspend.conf >> file? > > Yes, that indeed is the trigger / difference, enabling that on the > U4100 (its not a U1400) machine makes that fail also and disabling > makes it work on the i7-3630QM. Thanks, if you get a chance sysrq w might be interesting but I think we have enough info to solve the problem. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
