RE: revert yenta free_irq on suspend

RE: revert yenta free_irq on suspend

[Brown, Len]

>So I guess I'll just have to revert the ACPI change that 
>caused drivers to do request_irq/free_irq. I'd prefer it
>if the ACPI people did that revert themselves, though.

If that is what you want, I'll be happy to do it.

If one believes that suspend/resume is working on a large number of
systems -- working to a level that a distro can acutally support it,
then restoring our temporary resume IRQ router hack to make many systems
work
is clearly the right thing to do.

But that believe would be total fantasy -- supsend/resume is not
working on a large number of machines, and no distro is currently
able to support it.  (I'm talking about S3 suspend to RAM primarily,
suspend to disk is less interesting -- though Red Hat doesn't
even support _that_)

We can got back to the old hack, but it will probably just delay
the day that suspend/resume is working broadly, and actually
can be deployed and supported by distros.

-Len

RE: revert yenta free_irq on suspend

[Linus Torvalds]

On Sun, 31 Jul 2005, Brown, Len wrote:
> 
> If one believes that suspend/resume is working on a large number of
> systems -- working to a level that a distro can acutally support it,
> then restoring our temporary resume IRQ router hack to make many systems
> work is clearly the right thing to do.

I don't believe that it works on a huge number of devices as-is, no.

But I'm definitely even less likely to believe in this "two steps forward,
one step back" dance. Because as far as I can tell, it's equally often
"one step forward, two steps back", and nobody can tell when we go forware 
more than we go backwards.

So I'd rather have "one tenth of a step forward, but if we see even a 
_hint_ of a step back, we revert immediately".

I realize that sounds damn timid and boring, but the thing is:

 - even _if_ (and quite frankly, judging by the complaints, I find that 
   unlikely) we're doing more forward progress than backwards progress 
   ("backwards progress? you moron!"), the "one step back" thing is really 
   doing a _huge_ amount of psychological damage to the whole thing.

   The thing is, we're better off making very very slow progress that is 
   _steady_, than having people who _used_ to have things work for them 
   suddenly break.

   So I believe that if we fix two machines and break one machine, we've 
   actually regressed. It doesn't matter that we fixed more than we broke: 
   we _still_ regressed. Because it means that people can't trust the 
   progress we make!

So this is why I'm a very strong proponent of the fact that if we _ever_
have anybody complain that a patch broke things, we should immediately
revert it, unless we can fix it asap.

Btw, this argument is much less true in areas where we can "think" about
the problems. In non-driver/non-firmware cases.

When we can logically argue from a purely theoretical standpoint for a
"known correct solution", and expect the theoretical argument to actually
be reflected in practice, I'm much more open to an argument of "ok, we
know where we are going, and we'll have to break a few eggs just because
the changes are extensive".

But when it comes to device drivers and badly documented stuff that
developers can usually not even reproduce, our #1 strength is the people
for whom it works, and when something breaks, that's a huge big red flag,
and then I really think that "revert or fix immediately" is the only
reasonable alternative. Otherwise we'll just oscillate about a point that
we don't even know where it is, and have no way to judge if the
oscillations are getting more violent or are dampening out - we don't have
a reference point.

But as with everything, there is no total black-and-white case. Things 
_do_ break occasionally, and clearly we can't guarantee nonbreakage or 
we'll end up being static.

But this particular thing has clearly caused a _lot_ of noise, with
second-order breakage from fixes from the first order one. At the very 
least alternatives should be tried, and I think there _are_ much less 
intrusive alternatives that are _much_ less likely to have these kinds of 
negative side effects.

		Linus

Re: revert yenta free_irq on suspend

[Rafael J. Wysocki]

On Sunday, 31 of July 2005 07:03, Brown, Len wrote:
> >So I guess I'll just have to revert the ACPI change that 
> >caused drivers to do request_irq/free_irq. I'd prefer it
> >if the ACPI people did that revert themselves, though.
> 
> If that is what you want, I'll be happy to do it.
> 
> If one believes that suspend/resume is working on a large number of
> systems -- working to a level that a distro can acutally support it,
> then restoring our temporary resume IRQ router hack to make many systems
> work
> is clearly the right thing to do.
> 
> But that believe would be total fantasy -- supsend/resume is not
> working on a large number of machines, and no distro is currently
> able to support it.  (I'm talking about S3 suspend to RAM primarily,
> suspend to disk is less interesting -- though Red Hat doesn't
> even support _that_)
> 
> We can got back to the old hack, but it will probably just delay
> the day that suspend/resume is working broadly, and actually
> can be deployed and supported by distros.

May I propose to keep this change in -mm?

This issue has already been discussed on the linux-pm list and the people
there seem to agree thet the way to go is to convert all PCI drivers to the
model in which they drop their IRQs on suspend and request them back on
resume (ref. http://lists.osdl.org/pipermail/linux-pm/2005-May/000955.html).

There are some drivers that already do it (eg the USB drivers), but there are
many drivers that don't and in fact the recent problems have been related to
them.  If the change stays in -mm we will be able to convert the drivers
gradually and they will hopefully get some testing.  When it's done, it
will be safe to push the change along with the converted drivers to
mainline.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: revert yenta free_irq on suspend

[Dave Jones]

On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote:

 > But that believe would be total fantasy -- supsend/resume is not
 > working on a large number of machines, and no distro is currently
 > able to support it.  (I'm talking about S3 suspend to RAM primarily,
 > suspend to disk is less interesting -- though Red Hat doesn't
 > even support _that_)

After the 'swsusp works just fine' lovefest at OLS, I spent a little
while playing with the current in-tree swsusp implementation last week.

The outcome: I'm no more enthusiastic about enabling this in Red Hat
kernels than I ever was before.  It seems to have real issues with LVM
setups (which is default on Red Hat/Fedora installs these days).
After convincing it where to suspend/resume from by feeding it
the major/minor of my swap partition, it did actually seem
to suspend. And resume (though it did spew lots of 'sleeping whilst
atomic warnings, but thats trivial compared to whats coming up next).

I rebooted, and fsck found all sorts of damage on my / partition.
After spending 30 minutes pressing 'y', to fix things up, it failed
to boot after lots of files were missing.
Why it wrote anything to completely different lv to where I told it
(and yes, I did get the major:minor right) I have no idea, but
as it stands, it definitly isn't production-ready.

I'll look into it again sometime soon, but not until after I've
reinstalled my laptop.  (I'm just thankful I had the sense not to
try this whilst I was at OLS).

		Dave

Re: revert yenta free_irq on suspend

[Andreas Steinmetz]

Dave Jones wrote:
> On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote:
> 
>  > But that believe would be total fantasy -- supsend/resume is not
>  > working on a large number of machines, and no distro is currently
>  > able to support it.  (I'm talking about S3 suspend to RAM primarily,
>  > suspend to disk is less interesting -- though Red Hat doesn't
>  > even support _that_)
> 
> After the 'swsusp works just fine' lovefest at OLS, I spent a little
> while playing with the current in-tree swsusp implementation last week.
> 
> The outcome: I'm no more enthusiastic about enabling this in Red Hat
> kernels than I ever was before.  It seems to have real issues with LVM
> setups (which is default on Red Hat/Fedora installs these days).
> After convincing it where to suspend/resume from by feeding it
> the major/minor of my swap partition, it did actually seem
> to suspend. And resume (though it did spew lots of 'sleeping whilst
> atomic warnings, but thats trivial compared to whats coming up next).
> 
> I rebooted, and fsck found all sorts of damage on my / partition.
> After spending 30 minutes pressing 'y', to fix things up, it failed
> to boot after lots of files were missing.
> Why it wrote anything to completely different lv to where I told it
> (and yes, I did get the major:minor right) I have no idea, but
> as it stands, it definitly isn't production-ready.
> 
> I'll look into it again sometime soon, but not until after I've
> reinstalled my laptop.  (I'm just thankful I had the sense not to
> try this whilst I was at OLS).

Hmm,
I'm using swsusp on my x86_64 laptop with lvm and dm-crypt. Works just
fine except for nasty spontaneous reboots from time to time caused by
yenta_socket (I do get these since I started to access my pcmcia flash
disk from initrd to retrieve the dm-crypt swap key). It does work since
at least 2.6.11 up to 2.6.13-rc4 and if the yenta_socket caused
spontaneous reboots after resume could be fixed I'd call it production
ready.

gringo:~ # fdisk -l /dev/hda

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot   Start      End      Blocks   Id  System
/dev/hda1            1      244     1959898+  83  Linux
/dev/hda2          245      488     1959930   82  Linux swap / Solaris
/dev/hda3          489      732     1959930   82  Linux swap / Solaris
/dev/hda4          733     9729    72268402+   5  Extended
/dev/hda5          733      976     1959898+  82  Linux swap / Solaris
/dev/hda6          977     9729    70308441   88  Linux plaintext (*)

(*) dm-crypt :-)

gringo:~ # vgdisplay
  --- Volume group ---
  VG Name               rootvg
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  27
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                8
  Open LV               8
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               67.05 GB
  PE Size               4.00 MB
  Total PE              17165
  Alloc PE / Size       14464 / 56.50 GB
  Free  PE / Size       2701 / 10.55 GB
  VG UUID               oHluq0-H5Nd-90dU-psLn-ygNT-u4GJ-D8aJhG

All filesystems are ext3 as I did have nasty experiences with reiserfs
on lvm+raid on another 2.6 system without ever using swsusp there.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: revert yenta free_irq on suspend

[Dave Jones]

On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote:

 > gringo:~ # fdisk -l /dev/hda
 > 
 > Disk /dev/hda: 80.0 GB, 80026361856 bytes
 > 255 heads, 63 sectors/track, 9729 cylinders
 > Units = cylinders of 16065 * 512 = 8225280 bytes
 > 
 >    Device Boot   Start      End      Blocks   Id  System
 > /dev/hda1            1      244     1959898+  83  Linux
 > /dev/hda2          245      488     1959930   82  Linux swap / Solaris
 > /dev/hda3          489      732     1959930   82  Linux swap / Solaris
 > /dev/hda4          733     9729    72268402+   5  Extended
 > /dev/hda5          733      976     1959898+  82  Linux swap / Solaris
 > /dev/hda6          977     9729    70308441   88  Linux plaintext (*)
 > 
 > (*) dm-crypt :-)

Your swap partitions are outside of your lv's.

		Dave

Re: revert yenta free_irq on suspend

[Andreas Steinmetz]

Dave Jones wrote:
> On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote:
> 
>  > gringo:~ # fdisk -l /dev/hda
>  > 
>  > Disk /dev/hda: 80.0 GB, 80026361856 bytes
>  > 255 heads, 63 sectors/track, 9729 cylinders
>  > Units = cylinders of 16065 * 512 = 8225280 bytes
>  > 
>  >    Device Boot   Start      End      Blocks   Id  System
>  > /dev/hda1            1      244     1959898+  83  Linux
>  > /dev/hda2          245      488     1959930   82  Linux swap / Solaris
>  > /dev/hda3          489      732     1959930   82  Linux swap / Solaris
>  > /dev/hda4          733     9729    72268402+   5  Extended
>  > /dev/hda5          733      976     1959898+  82  Linux swap / Solaris
>  > /dev/hda6          977     9729    70308441   88  Linux plaintext (*)
>  > 
>  > (*) dm-crypt :-)
> 
> Your swap partitions are outside of your lv's.

Right, then this could be the problem you encountered. However the swap
partitions are set up with dm-crypt including the partition I do resume
from so I'm using device mapper to resume which is quite close to LVM.

-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: revert yenta free_irq on suspend

[Pavel Machek]

Hi!

>  > But that believe would be total fantasy -- supsend/resume is not
>  > working on a large number of machines, and no distro is currently
>  > able to support it.  (I'm talking about S3 suspend to RAM primarily,
>  > suspend to disk is less interesting -- though Red Hat doesn't
>  > even support _that_)
> 
> After the 'swsusp works just fine' lovefest at OLS, I spent a little
> while playing with the current in-tree swsusp implementation last week.
> 
> The outcome: I'm no more enthusiastic about enabling this in Red Hat
> kernels than I ever was before.  It seems to have real issues with LVM
> setups (which is default on Red Hat/Fedora installs these days).
> After convincing it where to suspend/resume from by feeding it
> the major/minor of my swap partition, it did actually seem
> to suspend. And resume (though it did spew lots of 'sleeping whilst
> atomic warnings, but thats trivial compared to whats coming up
> next).

I do not know much about LVM. How exactly did you resume= command line
look like? You were not resuming from initrd, right?

You did not boot *anything* between suspend and resume, right?

> I rebooted, and fsck found all sorts of damage on my / partition.
> After spending 30 minutes pressing 'y', to fix things up, it failed
> to boot after lots of files were missing.
> Why it wrote anything to completely different lv to where I told it
> (and yes, I did get the major:minor right) I have no idea, but
> as it stands, it definitly isn't production-ready.

Could you try to suspend on plain old swap-partition, first, to verify
that your drivers cooperate?
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Software suspend support in Fedora.

[Dave Jones]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

On Wed, Aug 03, 2005 at 11:23:01AM +0200, Pavel Machek wrote:

 > > The outcome: I'm no more enthusiastic about enabling this in Red Hat
 > > kernels than I ever was before.  It seems to have real issues with LVM
 > > setups (which is default on Red Hat/Fedora installs these days).
 > > After convincing it where to suspend/resume from by feeding it
 > > the major/minor of my swap partition, it did actually seem
 > > to suspend. And resume (though it did spew lots of 'sleeping whilst
 > > atomic warnings, but thats trivial compared to whats coming up
 > > next).
 > 
 > I do not know much about LVM. How exactly did you resume= command line
 > look like? You were not resuming from initrd, right?

Indeed, this was very likely the problem. Doing a resume if I had
any partition mounted was *bad* news.  We implemented the necessary
bits in our initrd today to detect resume partitions, and erm.. resume them.
So far so good, no repeats of the corruption I saw.

As of tomorrow rawhide kernels (for the unenlightened: these will
eventually be FC5) will have software suspend support.

Our initial experiments with it have been fairly positive, though as
expected there are a number of drivers that don't survive the resume
correctly. http://www.livejournal.com/users/kernelslacker/22975.html
has more info on this.  As we start getting users jumping on this, I
imagine more of these bugs will appear. But without testing, these are
never going to get fixed eh ? :)

 > Could you try to suspend on plain old swap-partition, first, to verify
 > that your drivers cooperate?
 
So, we've tested in on a /dev/hdaX, /dev/sdaX, and /dev/mapper/VolGroup00-LogVol01
so far, and its done the right thing every time.

It's looking pretty good, and unless something catastrophic happens,
we'll be supporting this feature from now on.
Whilst it's likely still got some niggles that need working out, 
It's come a long way since I last spent time looking into this, and
I'm sure it'll get there.  Kudos to all involved.

		Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]

Hi!

>  > > The outcome: I'm no more enthusiastic about enabling this in Red Hat
>  > > kernels than I ever was before.  It seems to have real issues with LVM
>  > > setups (which is default on Red Hat/Fedora installs these days).
>  > > After convincing it where to suspend/resume from by feeding it
>  > > the major/minor of my swap partition, it did actually seem
>  > > to suspend. And resume (though it did spew lots of 'sleeping whilst
>  > > atomic warnings, but thats trivial compared to whats coming up
>  > > next).
>  > 
>  > I do not know much about LVM. How exactly did you resume= command line
>  > look like? You were not resuming from initrd, right?
> 
> Indeed, this was very likely the problem. Doing a resume if I had
> any partition mounted was *bad* news.  We implemented the necessary
> bits in our initrd today to detect resume partitions, and erm.. resume them.
> So far so good, no repeats of the corruption I saw.

Aha, good.

> As of tomorrow rawhide kernels (for the unenlightened: these will
> eventually be FC5) will have software suspend support.
> 
> Our initial experiments with it have been fairly positive, though as
> expected there are a number of drivers that don't survive the resume
> correctly. http://www.livejournal.com/users/kernelslacker/22975.html

I see, having ext3 (or anything else) mounted when doing resume is
going to kill you data, fast. I thought warning in docs was good
enough :-).

Anyway, if you want to make this idiot-proof, I think the preferred
way is to kill suspend signature during the boot [it is must-have for
failsafe boot, so you can recover system if resume crashes it]. That
way user can echo whatever to resume, but having no signature means he
is not going to cause big damage.

[Actually there are more easy ways to kill some data. Suspend, do
normal boot next time, change something on disk, reboot and make it
resume. Bye-bye data.]

Okay, I realized I had too many warnings in there, and some things
(like no driver support) is not _that_ dangerous, while resuming with
filesystems mounted clearly is. I'll probably change the warning to:

 * BIG FAT WARNING *********************************************************
 *
 * If you touch anything on disk between suspend and resume...
 *                              ...kiss your data goodbye.
 *
 * If you do resume from initrd after your filesystems are mounted...
 *                              ...bye bye root partition.
 *                      [this is actually same case as above]
 *
 * If you have unsupported (*) devices using DMA, you may have some
 * problems. If your disk driver does not support suspend... (IDE does),
 * it may cause some problems, too. If you change kernel command line
 * between suspend and resume, it may do something wrong. If you change
 * your hardware while system is suspended... well, it was not good idea;
 * but it wil probably only crash.
 *
 * (*) suspend/resume support is needed to make it safe.



								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Hi!

Actually, more responses to the fedora discussion:

No, swsusp can not yet resume from swap file. It would need to mount
the filesystem, first, and as you know that is not good idea. (Even
read-only mount replays journal on ext3, beware).

SMP support is way more experimental than UP support. It uses cpu
hotplug infrastructure, etc...

We have some ppc support, but it was not officially blessed by BenH,
and it it did not get much testing. No chance for ppc/SMP support for
example.

[Cc-ing alan cox]

Suspend should work okay on PATA [what areas do you think it is
incomplete in?]. Recently, it was made to work on SATA, too
[experimental, I'd say]. It did not eat data recently due to SATA/PATA
problems. It is broken on most SCSI drivers (well, probably all of
them), but it is likely that you'll "just" get a crash in such case.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Alan Cox]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Mon, Aug 15, 2005 at 02:20:00PM +0200, Pavel Machek wrote:
> Suspend should work okay on PATA [what areas do you think it is
> incomplete in?]. Recently, it was made to work on SATA, too

ACPI requires that the ACPI taskfiles are sent to the drivers. That isn't
done. We then don't restore all the drive state correctly so parts of your
disk can just "vanish".

> [experimental, I'd say]. It did not eat data recently due to SATA/PATA
> problems. It is broken on most SCSI drivers (well, probably all of

It does for various people I know. In some cases we even know why. SATA has
the same basic problems as PATA although the infrastructure to handle it looks
ok with the scsi/sata pm patch that appeared.


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Hi!

> > Suspend should work okay on PATA [what areas do you think it is
> > incomplete in?]. Recently, it was made to work on SATA, too
> 
> ACPI requires that the ACPI taskfiles are sent to the drivers. That isn't
> done. We then don't restore all the drive state correctly so parts of your
> disk can just "vanish".

We have had done normal boot, so drive should be in sane state. With
echo "shutdown"  > /sys/power/disk, ACPI is not even involved (it
thinks it is regular powerdown). With echo "platform" > ..., yes, we
tell ACPI, and that means that we should follow the specs. Maybe you
want to make "shutdown" the default, then...

Do you agree that suspend/resume PATA support is okay on system
without ACPI enabled?
								Pavel

-- 
if you have sharp zaurus hardware you don't need... you know my address

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Alan Cox]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On Mon, Aug 15, 2005 at 02:34:17PM +0200, Pavel Machek wrote:
> Do you agree that suspend/resume PATA support is okay on system
> without ACPI enabled?

I believe so for PATA, well as much as anything in the PATA stack is "working".
Once you get into ACPI world it gets murkier and once you get into suspend to
ram its a total failure.

Alan


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

Hi.

On Mon, 2005-08-15 at 22:20, Pavel Machek wrote:
> Hi!
> 
> Actually, more responses to the fedora discussion:
> 
> No, swsusp can not yet resume from swap file. It would need to mount
> the filesystem, first, and as you know that is not good idea. (Even
> read-only mount replays journal on ext3, beware).

Pavel, could you please stop saying that? What it really needs is to
record the devices and blocks to read from in the image header. Suspend2
has done this for ages and it does work, as you know.

> SMP support is way more experimental than UP support. It uses cpu
> hotplug infrastructure, etc...

It works fine. Hotplug cpu was a little flakey for a while, but it's up
to standard now. I've recently switched from the old method after giving
it good testing, and the only problems I've seen have been in
combination with dynticks, and there the fault was dynticks, not
hotplug.

> We have some ppc support, but it was not officially blessed by BenH,
> and it it did not get much testing. No chance for ppc/SMP support for
> example.
> 
> [Cc-ing alan cox]
> 
> Suspend should work okay on PATA [what areas do you think it is
> incomplete in?]. Recently, it was made to work on SATA, too
> [experimental, I'd say]. It did not eat data recently due to SATA/PATA
> problems. It is broken on most SCSI drivers (well, probably all of
> them), but it is likely that you'll "just" get a crash in such case.

I'm always bemused when I see reports of problems with SATA. I've been
using it for 18 months with suspending and it's always just worked.
Maybe I just have a good chipset.

Regards,

Nigel

-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Software suspend support in Fedora.

[Alan Cox]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Tue, Aug 16, 2005 at 09:23:39AM +1000, Nigel Cunningham wrote:
> I'm always bemused when I see reports of problems with SATA. I've been
> using it for 18 months with suspending and it's always just worked.
> Maybe I just have a good chipset.

Its essentially pot luck depending on the hardware/bios configuration if ACPI 
is involved. Nothing to do with hardware quality.


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: revert yenta free_irq on suspend

[Matthew Garrett]

Brown, Len <len.brown@intel.com> wrote:

> But that believe would be total fantasy -- supsend/resume is not
> working on a large number of machines, and no distro is currently
> able to support it.  (I'm talking about S3 suspend to RAM primarily,
> suspend to disk is less interesting -- though Red Hat doesn't
> even support _that_)

It's still failing on a large number of machines, but it's working on a
larger set. We (Ubuntu) shipped with suspend to RAM support in our
previous release. Frankly, at this stage the three biggest problems are:

a) resuming video (not going to be fixed in the ACPI core)
b) SATA resume (not going to be fixed in the ACPI core)
c) Motherboard chipsets that don't seem to be programmed to handle
memory refresh (not going to be fixed in the ACPI core)

People /do/ use this code, and breaking a large number of working setups
in order to fix a bug that appears on a small number of setups (and can
be worked around in a rather less invasive way) isn't sensible.
-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org