Bill Davidsen wrote: > 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 :-(
Well, what if you wanted to boot a 2nd, dual-boot OS? The bootloader needs to boot the kernel which may choose to resume. Is there a misunderstanding here? I read your OP as saying that you booted kernel B (configured to have suspend support) and then hit suspend. When the machine rebooted the "default kernel" ie, kernel A, not kernel B was selected by the bootloader. Since the default kernel didn't have or couldn't resume, it simply booted. Just what I'd expect. >> 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. Err, no. It's a lot more sophisticated. However it does ask that you not resume with a different kernel than you suspended with - not unreasonable!! >> 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. Linux based OSes provide enough rope to build a harness or a noose. Choose wisely :) As you suggest you are about to, it may be best to get a distro-configured system or do some more background research. Mainline doesn't provide scripts to interact with bootloaders etc. Nb I replied because I've just done some work configuring s2d and now have 3 desktop/server machines doing suspend2disk on 2.6.21 quite nicely - thanks all around. David - 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/
