public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox