so suspend to disk does not work with scsi?
>> > - depends on PM && SWAP
>> > + depends on PM && SWAP && IDE=y && BLK_DEV_IDEDISK=y
implies IDE is needed.
btw: would it be somehow possible to resume after initrd phase?
or some other idea how a generic kernel with modules in the initrd
could use suspend to disk? or a laptop where the initrd is needed
to setup a dm-crypt volume with the right decrypton key?
Regards, Andreas
Hi.
On Tue, 2004-03-30 at 07:34, Andreas Jellinghaus wrote:
> so suspend to disk does not work with scsi?
>
> >> > - depends on PM && SWAP
> >> > + depends on PM && SWAP && IDE=y && BLK_DEV_IDEDISK=y
>
> implies IDE is needed.
It is at the moment, I'm afraid. I'm hoping to get SCSI support for
suspend2 finished shortly. I did suspend a OSDL machine to SCSI in
January, but the driver lacked the power management that I needed to
reload the second half of the image and thereby be sure all was okay.
> btw: would it be somehow possible to resume after initrd phase?
> or some other idea how a generic kernel with modules in the initrd
> could use suspend to disk? or a laptop where the initrd is needed
> to setup a dm-crypt volume with the right decrypton key?
That should be doable, provided that the initrd doesn't mount anything.
Decryption is 'interesting'. The key needs to be set up in the resumed
kernel too. (Shouldn't be a problem, if you manage to suspend to it!).
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
[currently no scsi support]
ah, ok.
> > btw: would it be somehow possible to resume after initrd phase?
> > or some other idea how a generic kernel with modules in the initrd
> > could use suspend to disk? or a laptop where the initrd is needed
> > to setup a dm-crypt volume with the right decrypton key?
>
> That should be doable, provided that the initrd doesn't mount anything.
> Decryption is 'interesting'. The key needs to be set up in the resumed
> kernel too. (Shouldn't be a problem, if you manage to suspend to it!).
I don't know if loading modules can be done without, but the usual way
is to mount /sys and /proc so you can see what hardware is available.
I do that too for my dm-crypt setup, even mount a tmpfs at /dev,
create devices, start usb hotplugging, etc. but after getting the
decryption key, all filesystems are unmounted again, all processes
killed, there is nothing visible to me left. would that still create
some problems in the kernel internals preventing resume (or making it
too hard to do)?
Regards, Andras
Hi.
On Tue, 2004-03-30 at 17:31, Andreas Jellinghaus wrote:
> > That should be doable, provided that the initrd doesn't mount anything.
> > Decryption is 'interesting'. The key needs to be set up in the resumed
> > kernel too. (Shouldn't be a problem, if you manage to suspend to it!).
>
> I don't know if loading modules can be done without, but the usual way
> is to mount /sys and /proc so you can see what hardware is available.
They would be fine. The key thing is that none of the filesystems which
have journals get mounted. That would cause the crash recovery routines
to run, resulting inconsistency between the image on disk and the one
that the suspend image contains. You could probably do just about
anything, so long as those filesystems aren't mounted. Assuming that is
done, actually calling suspend after an initrd is run shouldn't be a
problem, so far as I know.
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.