From: Rob Landley <rob@landley.net>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: uspend to Disk - Kernel 2.6.4 vs. r50p
Date: Sat, 8 May 2004 23:31:30 -0500 [thread overview]
Message-ID: <200405082331.30669.rob@landley.net> (raw)
In-Reply-To: <20040508225401.GF29255@atrey.karlin.mff.cuni.cz>
On Saturday 08 May 2004 17:54, Pavel Machek wrote:
> Hi!
>
> > I'm one of the people for whom Patrick's suspend worked and yours didn't.
> > Now I've been busy with other things for a couple months (Penguicon 2.0
> > went quite well, by the way), and there's talk of yanking Patrick's
> > suspend code from the kernel. Right, so I've got to deal with this. I
> > can't say I'm thrilled, but I DO want to continue to be able to suspend
> > my laptop.
> >
> > What kind of debug info do I need to report to get your suspend code
> > fixed, and who do I need to report it to?
> >
> > I just tested 2.6.5, which went "boing" trying to suspend with some kind
> > of debug message that gave me a hex number (not a panic, but I didn't
> > have a pen handy, I can try again and write it down if you like.
> > Anything else I should do?)
>
> Try it with minimal drivers from signle user mode...
I'll give it a whack...
> > I asked Nigel a few months ago, and he pointed me to an enormous flag day
> > patch that will probably be integrated into the kernel when hell freezes
> > over. (I have no idea why it's so intrusive, by the way. Isn't half the
> > point of sysfs and the new 2.6 device infrastructure that finding all the
> > devices that need to be shut up doesn't require the kind of insanity
> > doing it under 2.4 did?
>
> Nigel's refrigerator is way more elaborate and very intrusive, but he
> seems to work *always*. Original refrigerator (shared by swsusp and
> pmdisk) only tries a bit and eventually gives up if stopping system is
> too hard. Hopefully Nigel's code can be simplified.
I hope so too. Software suspend is a really nice feature, and he seems to be
the one putting in the most time on it.
> > I read the docs and read through your code a bit, and every screenful or
> > so it says "this code is guaranteed to eat your data if you look at it
> > funny". I've been using Patrick's suspend code for something like eight
> > months now, and it never ate any of my data. Failed to resume a few
> > times, but no worse than sync followed by yanking the power cord, fsck
> > did its thing and life went on. (Yes, I back up regularly. But I've
> > gotten the distinct impression that you have no faith whatsoever in your
> > own work, and reinstalling and restoring from backups is a real pain,
> > especially when you're on the road.)
>
> It did not eat *my* data in last eight months.
>
> If patrick does not warn you, its his problem.
Yeah, but his code works for me. :)
> If you suspend, mount
> your filesytems, do some work and then resume, you are probably going
> to do some pretty nasty corruption. Just don't do that.
>
> But this problem is shared by swsusp, swsusp2 *and* pmdisk.
I know. I also know that ext2 (and derivatives) have both "last mounted" and
"last written to" datestamp fields (other filesystems probably do as well,
but I don't use 'em) and it would be really nice to check those as matching
what they were when you suspended, and abort the resume if they don't
match...
> > Sigh. I _really_ don't have time for this right now. I wonder if it
> > would be possible to just send Patrick some money?
>
> He's out of time, so money is not likely to help. Sending some money
> to Nigel might do the trick ;-).
> Pavel
His code isn't the one I've gotten to work yet... :)
Rob
next prev parent reply other threads:[~2004-05-09 4:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-29 6:41 uspend to Disk - Kernel 2.6.4 vs. r50p Hamie
2004-05-03 12:31 ` Pavel Machek
2004-05-03 14:56 ` Grzegorz Piotr Jaskiewicz
2004-05-03 19:29 ` Pavel Machek
2004-05-03 20:07 ` Grzegorz Piotr Jaskiewicz
2004-05-03 20:09 ` Pavel Machek
2004-05-04 20:55 ` Peter Osterlund
2004-05-05 1:18 ` Rob Landley
2004-05-06 15:43 ` Romano Giannetti
2004-05-06 16:22 ` Rob Landley
2004-05-08 22:54 ` Pavel Machek
2004-05-09 4:31 ` Rob Landley [this message]
2004-05-09 21:49 ` Pavel Machek
2004-05-11 17:49 ` Rob Landley
2004-05-09 22:31 ` Nigel Cunningham
2004-05-09 22:43 ` Pavel Machek
2004-05-09 22:48 ` Pavel Machek
2004-05-09 22:50 ` Nigel Cunningham
2004-05-09 22:51 ` 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=200405082331.30669.rob@landley.net \
--to=rob@landley.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.