Software suspend support in Fedora.

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 --]