[Pm-utils] [patch] disable suspend when kernel image changed

[Richard Zidlicky]

On Thu, Apr 08, 2010 at 09:31:47PM +0200, Rafael J. Wysocki wrote:
> On Thursday 08 April 2010, Nigel Cunningham wrote:
> > Hi.
> > 
> > On 08/04/10 20:25, Richard Zidlicky wrote:
> > > On Thu, Apr 08, 2010 at 07:06:31PM +1000, Nigel Cunningham wrote:
> > >> On 08/04/10 05:52, Richard Zidlicky wrote:
> > >>> Hi,
> > >>>
> > >>> trying to fix this crash situation: /boot/vmlinuz-XXX exists and is the currently
> > >>> running kernel, I decide to reconfigure and recompile it, overwrite /boot/vmlinuz-XXX
> > >>> and hit pm-hibernate.
> > >>>
> > > ...
> > > ...
> > >>>
> > >>> --- 01grub.rz   2010-04-07 19:52:02.000000000 +0200
> > >>> +++ 01grub      2010-04-07 21:22:30.000000000 +0200
> > >>> @@ -15,6 +15,7 @@
> > >>>
> > >>>           [ -x /sbin/grubby -a -x /sbin/grub ] || return $NA
> > >>>           [ -e "/boot/vmlinuz-$(uname -r)" ] || return 1
> > >>> +       [ /var/log/boot.log -ot "/boot/vmlinuz-$(uname -r)" ]&&   return $NA
> > >>>           out=$(/sbin/grubby --info /boot/vmlinuz-$(uname -r) |grep index)
> > >>>           [ -n "${out}" ] || return 1
> > >>>           current=${out#index=}
> > >>
> > >> With anything relatively recent (post about 2.6.27 IIRC), this should be
> > >> unnecessary. Code has been added so that you can hibernate with one
> > >> kernel and resume with another.
> > >
> > > definitely not the case - just triggered it with 2.6.33.2 yesterday:
> > >
> > > Apr  7 16:23:45 localhost kernel: [   23.188781] Freezing user space processes ... (elapsed 0.01 seconds) done.
> > > Apr  7 16:23:45 localhost kernel: [   23.199054] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > > Apr  7 16:23:45 localhost kernel: [   23.222282] PM: Loading image data pages (182231 pages) ...
> > > Apr  7 16:23:45 localhost kernel: [   23.222310] PM: Image mismatch: version
> > > Apr  7 16:23:45 localhost kernel: [   23.222355]
> > > Apr  7 16:23:45 localhost kernel: [   23.222378] PM: Read 728924 kbytes in 0.01 seconds (72892.40 MB/s)
> > > Apr  7 16:23:45 localhost kernel: [   23.222433] PM: Restore failed, recovering.
> > > Apr  7 16:23:45 localhost kernel: [   23.230013] Restarting tasks ... done.
> > > Apr  7 16:23:45 localhost kernel: [   24.047245] EXT3-fs (dm-6): recovery required on readonly filesystem
> > >
> > > it was exactly the same kernel release - only slightly reconfigured&  recompiled.
> > 
> > Hmm. My apologies; you're absolutely right.
> > 
> > I'll have to email Rafael (cc'd) - I'm not sure why that check is still 
> > there. I know it is possible for you to hibernate one kernel and resume 
> > from another - I've done it with TuxOnIce using the low-level code 
> > Rafael put in. Perhaps he's discovered something that makes it 
> > unreliable or such like.
> 
> That still should work, although only on x86-64, because I've never had the
> time to implement it on x86-32.
> 
> That said, I haven't tried it myself recently and the feature might regress due
> to the general x86 change flow.

so it is something that does not work at the moment but might get implemented.
If so, is there any possibility to test at runtime whether it will work with
a particular combination of kernel images?

Somehow pm-utils needs to safeguard against current situation where a resume can 
fail with data loss so if the feature can not be reliably detected I would still
advocate to disable it in circumstances where it can not be guaranteed to work.


Richard