Messages in this thread | | | Date | Wed, 18 Sep 2013 16:21:49 +0100 | From | Al Viro <> | Subject | Re: [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming |
| |
On Wed, Sep 18, 2013 at 02:52:39PM +0100, Al Viro wrote: > On Tue, Aug 27, 2013 at 07:48:43AM +0400, Andrew Savchenko wrote: > > > Additional (but probably useless) information on this bug may be found > > > here: https://forums.gentoo.org/viewtopic-p-7371120.html > > Something's very fishy there: > > [quote] > Digging into suspend-utils code shows that the following ioctl fails on > "/dev/snapshot": > > Code: > ioctl(dev, _IO(3, 1), 0); > [end quote] > > but that's _not_ anything freeze-related - that's HDIO_GETGEO, and with zero > as last argument it will fail, no matter what. With EFAULT, if nothing > else... > > Which ioctl() it really is? A bit further down you write "I modified suspend > code to see errno, so freeze on /dev/snapshot fails [with EAGAIN]", so you > have isolated the call in question. Could you quote the actual code?
*scratches head* _IO('3', 1), perhaps? At least that would make sense in such context... Assuming that's the case, slap printk(KERN_INFO "freeze_process() => %d", error); after the call of freeze_process() in kernel/power/user.c along with printk(KERN_INFO "__usermodehelper_disable() => %d", error); and printk(KERN_INFO "try_to_freeze_tasks() => %d", error); in kernel/power/process.c:freeze_process(), after the calls of __usermodehelper_disable() and try_to_freeze_tasks() resp.
FWIW, I suspect that it's __usermodehelper_disable() - it does retval = wait_event_timeout(running_helpers_waitq, atomic_read(&running_helpers) == 0, RUNNING_HELPERS_TIMEOUT); and returns -EAGAIN on timeout. I'm not familiar with swsusp code, but it smells like we end up waiting for linuxrc itself to finish.
Pavel, any suggestions? If SNAPSHOT_FREEZE really wants everything run via usermodehelper gone for some reason, what makes /linuxrc different from e.g /sbin/modprobe?
| |