From: Rob Landley <rob@landley.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: uspend to Disk - Kernel 2.6.4 vs. r50p
Date: Tue, 4 May 2004 20:18:23 -0500 [thread overview]
Message-ID: <200405042018.23043.rob@landley.net> (raw)
In-Reply-To: <20040503123150.GA1188@openzaurus.ucw.cz>
On Monday 03 May 2004 07:31, Pavel Machek wrote:
> Hi!
>
> > echo -n disk > /proc/power/state
>
> Use echo 4 > /proc/acpi/sleep, and vanilla kernels.
>
> Pavel
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?)
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?
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.)
Sigh. I _really_ don't have time for this right now. I wonder if it would be
possible to just send Patrick some money?
Rob
next prev parent reply other threads:[~2004-05-06 15:25 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 [this message]
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
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=200405042018.23043.rob@landley.net \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.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