From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Add support to resume swsusp from initrd
Date: Sun, 05 Dec 2004 21:21:38 +0000 [thread overview]
Message-ID: <1102281698.9384.29.camel@tyrosine> (raw)
In-Reply-To: <20041205211230.GC1012@elf.ucw.cz>
On Sun, 2004-12-05 at 22:12 +0100, Pavel Machek wrote:
> > echo -n "set 03:02" >/sys/power/resume
>
> I'd prefer not to have this one. Is it actually usefull? Then resume
> could be triggered by echo -n "03:02" > /sys/power/resume...
resume_device is set by swsusp_read, which requires name_to_dev_t to be
working. At the point where that's called, the device driver hasn't been
loaded and we don't have the information to get the dev_t. Once the
driver has been loaded, name_to_dev_t has already been discarded (it's
marked __init). So we need to set resume_device somehow.
> > will set /dev/hda2 as the resume device.
> >
> > echo -n "resume 03:02" >/sys/power/resume
> >
> > will attempt a resume from /dev/hda2. Patches are against
> > 2.6.10-rc3.
>
> Nice way to loose your data :-). [Note note note -- I'm not going to
> merge it before my bigdiff goes to mainline, so expect to rediff it
> when 2.6.10 is out. I can generate the big diff if you want to test it
> now.]
Heh. Yes, that's no problem. A new bigdiff for -rc3 would be helpful.
> You really need to make sure that userland processes are stopped
> before swsusp-resume is started. You should do freeze_process(). Then
> resume process depends on having enough memory available, so you
> probably want to free_some_memory() and warn in documentation about
> the fact.
Ok. I'll look into that. The main reason I want code like this is that
Debian use modular IDE drivers that are stored in the initrd. The disks
won't be touched until the root file system is mounted, and we'll
trigger the resume before then, so there shouldn't be any risk of data
loss. At this point, there shouldn't be any userspace running other than
a single shell script - do you think it's still a problem?
> Ugh, and you really should document "list of bad ideas with resume
> from userspace". It is extremely easy to shoot yourself into the foot
> with this one.
Will do.
Thanks,
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2004-12-05 21:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-05 20:48 [PATCH/RFC] Add support to resume swsusp from initrd Matthew Garrett
2004-12-05 21:12 ` Pavel Machek
2004-12-05 21:21 ` Matthew Garrett [this message]
2004-12-05 21:29 ` Pavel Machek
2004-12-05 21:42 ` Matthew Garrett
2004-12-05 21:49 ` Pavel Machek
2004-12-06 10:02 ` Stefan Seyfried
2004-12-05 21:18 ` Pavel Machek
2004-12-06 23:15 ` Matthew Garrett
2004-12-07 9:44 ` Pavel Machek
2004-12-07 11:39 ` Matthew Garrett
2004-12-07 11:46 ` Pavel Machek
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=1102281698.9384.29.camel@tyrosine \
--to=mjg59@srcf.ucam.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
/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