public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: David Greaves <david@dgreaves.com>
Cc: Linux Kernel M/L <linux-kernel@vger.kernel.org>
Subject: Re: [2.6.21.1] resume doesn't run suspended kernel?
Date: Sun, 27 May 2007 09:10:38 -0400	[thread overview]
Message-ID: <4659834E.4070506@tmr.com> (raw)
In-Reply-To: <4659442E.2060307@dgreaves.com>

David Greaves wrote:
> Bill Davidsen wrote:
>> Anyway, I pulled the plug on the UPS, and the system shut down. But when
>> it powered up, it booted the default kernel rather than the test kernel,
>> decided that it couldn't resume, and then did a cold boot.
> 
> Booting the machine isn't the kernel's job, it's the bootloader's job.
> 
And resume is not the the bootloader's job... if memory and registers 
are restored, and a jump is made to the resume address, a resumed system 
should result. clearly some part of that didn't happen :-(

>> I can bypass this by making the debug kernel the default, but WHY? Is
>> the kernel not saved such that any kernel can be rolled back into memory
>> and run? Actually, the answer is HELL NO, so I really ask if this is the
>> intended mode of operation, that only the default boot kernel will restore.
> 
> Yes.
> 
> It is very dangerous to attempt a resume with a different kernel than the one
> that has gone to sleep.
> Different kernels may be compiled with different options that affect where or
> how in-memory structures are saved.
> 
If the mainline resume is depending on that no wonder resume is so 
fragile. User action can change order of module loads, kmalloc calls 
move allocated structures, etc. Counting on anything to be locked in 
place seems naive.

> So you suspend with a kernel which holds your filesystem data/cache/inodes at
> 0x1234000 and restore with a kernel that expects to see your filesystem data at
> 0x1235000.
> 
> Ouch.
> 
I would hope that the data used by the resumed kernel would be the same 
data that was suspended, not something from another kernel.

> Personally I think the kernel suspend should write a signature - similar to a
> hash of the bzImage - into the suspend image so it won't even attempt a resume
> if there's a mismatch. (Yes, I made this mistake once whilst playing with suspend).
> 
Someone else dropped a note saying the FC kernels use suspend2, and work 
fine. I'm off to look at the FC source and see if that's the case. That 
would explain why suspend works and resume doesn't, hopefully there's a 
2.6.21 suspend2 patch in that case.

Thanks for the feedback in any case.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

  reply	other threads:[~2007-05-27 13:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-26 22:42 [2.6.21.1] resume doesn't run suspended kernel? Bill Davidsen
2007-05-27  8:41 ` David Greaves
2007-05-27 13:10   ` Bill Davidsen [this message]
2007-05-27 15:26     ` David Greaves
2007-05-27 21:20     ` Pavel Machek
2007-05-27 21:17   ` Pavel Machek
2007-05-27 21:14 ` Pavel Machek
2007-05-28  3:15   ` Bill Davidsen
2007-05-28 13:21     ` Bill Davidsen
2007-05-28 13:26       ` Pavel Machek
2007-05-28 17:57         ` Rafael J. Wysocki
2007-05-28 22:48           ` Nigel Cunningham
2007-05-29 11:29             ` Pavel Machek
2007-05-29 12:03               ` Rafael J. Wysocki
2007-05-29 12:23                 ` Nigel Cunningham
2007-05-29 12:40                 ` Pavel Machek
2007-05-29 13:13                   ` Nigel Cunningham
2007-05-29 21:51                     ` Rafael J. Wysocki
2007-06-04 11:02                     ` Pavel Machek
2007-06-04 11:05                       ` Nigel Cunningham
2007-06-05  7:23 ` Stefan Seyfried
2007-06-05 14:08   ` Bill Davidsen
     [not found] <fa.rXcMBo+RSE/6L84EBqFCeyFql/k@ifi.uio.no>
2007-05-27  2:44 ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4659834E.4070506@tmr.com \
    --to=davidsen@tmr.com \
    --cc=david@dgreaves.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox