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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
