Hi,
has any uswsusp[1] (aka suspend-utils) or plymouth[2] developer tested the
two together? It seems there is a hang during resume from s2disk, and the
resume can be continued by pressing ALT-SysRq-K or ALT-SysRq-E.
This is not hardware specific neither new. For example, there is a bug report
for Debian[3] opened in 2010 (don't get confused by the reference to the
blinking fb cursor bug). Personally, I have tested on Ubuntu 12.04 and
Arch Linux (stable and some rc kernel versions for some months now).
Easily reproduced also in a virtual machine, without graphical splash.
The hang does not occur if using the in-kernel hibernation, nor when
not starting plymouth before resume.
ALT-SysRq-T shows this backtrace for the 'plymouthd' and 'resume' processes:
[?? 51.853427] plymouthd?????? D 0000000000000000???? 0??? 55????? 1 0x00000004
[?? 51.853427]? ffff88000da6fd18 0000000000000086 ffff88000da58000 ffff88000da6ffd8
[?? 51.853427]? ffff88000da6ffd8 ffff88000da6ffd8 ffff88000da59000 ffff88000da58000
[?? 51.853427]? 0000000000000000 ffff88000da58490 ffff88000da6fc78 ffff88000d9bd500
[?? 51.853427] Call Trace:
[?? 51.853427]? [<ffffffff8107d879>] ? finish_task_switch+0x49/0xd0
[?? 51.853427]? [<ffffffff8145daa1>] ? __schedule+0x431/0x900
[?? 51.853427]? [<ffffffff8145e0af>] schedule+0x3f/0x60
[?? 51.853427]? [<ffffffff8109b9b3>] __refrigerator+0x43/0xe0
[?? 51.853427]? [<ffffffff810bdb72>] ? cgroup_freezing+0x32/0x40
[?? 51.853427]? [<ffffffff8106499d>] get_signal_to_deliver+0x56d/0x600
[?? 51.853427]? [<ffffffff8118687c>] ? destroy_inode+0x3c/0x70
[?? 51.853427]? [<ffffffff81014278>] do_signal+0x68/0x750
[?? 51.853427]? [<ffffffff811b04f1>] ? ep_poll+0x2a1/0x360
[?? 51.853427]? [<ffffffff811b09ed>] ? sys_epoll_ctl+0xad/0x850
[?? 51.853427]? [<ffffffff8116dfeb>] ? fput+0x16b/0x210
[?? 51.853427]? [<ffffffff810149e5>] do_notify_resume+0x65/0x80
[?? 51.853427]? [<ffffffff81460122>] int_signal+0x12/0x17
[?? 51.853427] resume????????? S ffff88000da593c8???? 0??? 57????? 1 0x00000000
[?? 51.853427]? ffff88000da5fd48 0000000000000082 ffff88000da59000 ffff88000da5ffd8
[?? 51.853427]? ffff88000da5ffd8 ffff88000da5ffd8 ffffffff8180d020 ffff88000da59000
[?? 51.853427]? ffff88000da59000 ffff88000da5ffd8 ffff88000da5ffd8 ffff88000da5ffd8
[?? 51.853427] Call Trace:
[?? 51.853427]? [<ffffffff8108014c>] ? ttwu_do_wakeup+0x2c/0x120
[?? 51.853427]? [<ffffffff8145eed8>] ? _raw_spin_unlock_irqrestore+0x38/0x50
[?? 51.853427]? [<ffffffff8145e0af>] schedule+0x3f/0x60
[?? 51.853427]? [<ffffffff812e20f7>] vt_event_wait+0xa7/0x130
[?? 51.853427]? [<ffffffff81072570>] ? abort_exclusive_wait+0xb0/0xb0
[?? 51.853427]? [<ffffffff812e225d>] vt_waitactive+0x2d/0x60
[?? 51.853427]? [<ffffffff8145cc26>] ? mutex_lock+0x16/0x30
[?? 51.853427]? [<ffffffff812e4886>] vt_move_to_console+0x56/0xc0
[?? 51.853427]? [<ffffffff81094388>] pm_prepare_console+0x18/0x40
[?? 51.853427]? [<ffffffff81095974>] hibernation_restore+0x14/0x130
[?? 51.853427]? [<ffffffff8109afe8>] snapshot_ioctl+0x218/0x4a0
[?? 51.853427]? [<ffffffff8117e787>] do_vfs_ioctl+0x97/0x530
[?? 51.853427]? [<ffffffff8118ae14>] ? mntput+0x24/0x40
[?? 51.853427]? [<ffffffff8116dfeb>] ? fput+0x16b/0x210
[?? 51.853427]? [<ffffffff8117ecb9>] sys_ioctl+0x99/0xa0
[?? 51.853427]? [<ffffffff8145fe69>] system_call_fastpath+0x16/0x1b
Does plymouthd register to listen for console change, or something else
that it can't do while refrigerated?
There was on May 18th a patch proposed for the vt_event_wait() function[4],
but that patch has no effect for this particular hang.
Apparently Mandriva has a patch[5] to add plymouth support to uswsusp, but one
would assume that s2disk/resume should not hang in its default state.
Any ideas?
Mikko
--
[1] http://suspend.sourceforge.net/
[2] http://cgit.freedesktop.org/plymouth/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593795
[4] "Race in vt_event_wait() during suspend/resume": http://article.gmane.org/gmane.linux.kernel/1299487
[5] changelog e.g.: http://rpmfind.net//linux/RPM/mandriva/2011/x86_64/media/main/release/suspend-0.8-12.20080612.x86_64.html