LinuxLists.cc - Power Management Update

2003-08-30 21:27:33

Subject: Power Management Update

I'm pleased to announce the release of the first patchset of power
management changes for 2.6.0. The purpose of this release is to give
people a chance to review and test the PM code before it's sent on to
Linus.

These patches include a number of cleanups and fixes to the PM core code,
the driver core PM code, and swsusp. I have verified that all suspend
states (standby, suspend-to-ram, and suspend-to-disk) work on a number of
personal systems using ACPI as the low-level power interface. However,
this is with limited functionality (from a VGA console with minimal
processes running).

These patches should restore suspend functionality for those that were
able to successfully do it before -test3 and -test4. My apologies for the
inconvenience my previous changes caused. These patches will probably not
allow any more people to suspend/resume than before.

The net benefit of these, and the already committed ones, are a cleaner
power management subsystem and the development of the proper framework for
successfully suspending and resuming the entire system. There are still
several rough edges, though we seem to be making headway on those
relatively rapidly, and are my sole focus at the moment.

My main concerns right now are:

- Platform devices, and more generally, devices that may belong to more
than one class. It's mainly a driver model problem, though it has PM
implications that appear to be holding a few people up.

- Drivers
Drivers have always been the main impedence to having a working PM core,
though it's been difficult to make a lot of progress. I have a number of
devices that I will verify work properly, and be in contact with the
maintainers if necessary. (Though, I seem to be having more problems
with IRQ routing at the moment.)

- Getting it work on more systems.
Hopefully we will not run into any serious issues, though the PM code
has traditionally been finicky. I have a wide array of test machines and
willing testers, so this should move quickly.

- APM
I unfortunately have not had a chance to look into the reported APM
problems. But, I'm happy to say that I finally dug out an old laptop
that has APM on it. I should make traction soon.

I encourage willing people to download the patch, test, and report any
problems back to me and/or the list. I cannot guarantee definite or timely
results for systems where PM simply doesn't work. However, the more
systems we characterize, the easier this will become in the future. Please
be patient.

If you're using BitKeeper, you can pull the tree from:

bk://kernel.bkbits.net:/home/mochel/linux-2.5-power

Or, a GNU patch is available at:

http://developer.osdl.org/~mochel/patches/test4-pm1/test4-pm1.diff.bz2

There are split patches for each BK revision in that directory. The
changelogs are appended.

Pat

This will update the following files:

arch/i386/kernel/suspend.c | 141 ------------
arch/i386/kernel/suspend_asm.S | 94 --------
arch/i386/Makefile | 1
arch/i386/kernel/Makefile | 2
arch/i386/power/Makefile | 2
arch/i386/power/cpu.c | 141 ++++++++++++
arch/i386/power/swsusp.S | 104 ++++++++-
drivers/acpi/sleep/main.c | 53 ++--
drivers/acpi/sleep/proc.c | 73 ++++++
drivers/acpi/sleep/sleep.h | 3
drivers/base/core.c | 33 +--
drivers/base/power/main.c | 13 -
drivers/base/power/power.h | 3
drivers/base/power/resume.c | 21 +
drivers/base/power/suspend.c | 10
include/asm-i386/suspend.h | 7
include/linux/suspend.h | 1
kernel/power/Makefile | 2
kernel/power/console.c | 2
kernel/power/disk.c | 337 ++++++++++++++++++++++++++++++
kernel/power/main.c | 450 ++++++++---------------------------------
kernel/power/power.h | 39 +--
kernel/power/swsusp.c | 357 +++++++++++++++++++-------------
kernel/sys.c | 2
24 files changed, 1053 insertions(+), 838 deletions(-)

through these ChangeSets:

<[email protected]> (03/08/30 1.1301)
[acpi] Replace /proc/acpi/sleep

- Bad to remove proc file now, even though it's nearly useless. Reinstated
in the name of compatibility.

- Restored original semantics - if software_suspend() is enabled, then just
call that (and never go into low-power state). Otherwise, call acpi_suspend().

- acpi_suspend() is simply a wrapper for pm_suspend(), passing down the right
argument. This is so we don't have to do everything manually anymore.

- Fixed long-standing bug by checking for "4b" in string written in to
determine if we want to enter S4bios.

<[email protected]> (03/08/30 1.1300)
[swsusp] Restore software_suspend() call.

- Allows 'backdoor' interface to swsusp, as requested by Pavel.

- Simply a wrapper to pm_suspend(), though guaranteeing that swsusp is used,
and system is shutdown (and put into low-power state).

- Call in sys_reboot() changed back to call to software_suspend().

<[email protected]> (03/08/30 1.1299)
[swsusp] Use BIO interface when reading from swap.

- bios are the preferred method for doing this type of stuff in 2.6. The
__bread() uses bio's in the end anyway.

- bios make it really easy to implement write functionality, so we are able
to reset the swap signature immediately after checking it during resume.
So, if something happens while resuming, we will still have valid swap to
use.

- Thanks to Jens for some help in getting it working several months ago.

<[email protected]> (03/08/29 1.1298)
[swsusp] Minor cleanups in read_suspend_image()

- Make resume_bdev global to file, so we don't have to pass it around (we
always use the same one, so it shouldn't make a difference).

- Allocate cur in read_suspend_image(), since it's the only function that
uses it.

- Check all errors and make sure we free cur if any happen.

- Make sure to return errors from the functions called, not our own.

- Free the pagedir if we hit an error after we allocate it.

<[email protected]> (03/08/27 1.1297)
[acpi] Move register save closer to call to enter sleep state.

- By moving acpi_{save,restore}_state_mem() into acpi_pm_enter(), implying
after interrupts have been disabled and nothing else is running on the
system, S3 is able to resume properly.

<[email protected]> (03/08/27 1.1296)
[power] Make sure devices get added to the PM lists before bus_add_device().

- Prevents ordering issues when drivers add more devices ->probe().

<[email protected]> (03/08/26 1.1295)
[power] Separate suspend-to-disk from other suspend sequences.

- Put in kernel/power/disk.c
- Make compilation depend on CONFIG_SOFTWARE_SUSPEND (should probably be
renamed to CONFIG_PM_STD or some such).

<[email protected]> (03/08/25 1.1294)
[power] Fix handling of pm_users.

- Actually decrement on device_pm_release()
- Call from device_pm_remove().

<[email protected]> (03/08/25 1.1292)
[power] Fix device suspend handling

- Handle -EAGAIN in device_suspend() properly: keep going, with error reset
to 0.

- Call dpm_resume() if we got a real error, instead of device_resume(), which
would deadlock.

<[email protected]> (03/08/22 1.1276.19.8)
[power] swsusp Cleanups

- do_magic()
- Rename to swsusp_arch_suspend().
- Move declaration to swsusp.c

- arch_prepare_suspend()
- Return an int
- Fix x86 version to return -EFAULT if cpu does not have pse, instead of
calling panic().
- Call from swsusp_save().

- do_magic_suspend_1()
- Move body to pm_suspend_disk()
- Remove.

- do_magic_suspend_2()
- Rename to swsusp_suspend()
- Move IRQ fiddling to suspend_save_image(), since that's the only call
that needs it.
- Return an int.

- do_magic_resume_1()
- Move body to pm_resume().
- Remove

- do_magic_resume_2()
- Rename to swsusp_resume().
- Return an int.

- swsusp general
- Remove unnecessary includes.
- Remove suspend_pagedir_lock, since it was only used to disable IRQs.
- Change swsusp_{suspend,resume} return an int, so pm_suspend_disk() knows
if anything failed.

<[email protected]> (03/08/22 1.1276.19.7)
[power] Move i386-specific swsusp code to arch/i386/power/

<[email protected]> (03/08/22 1.1276.19.6)
[power] Fix up sysfs state handling.

<[email protected]> (03/08/22 1.1276.19.5)
[power] Make sure console level is high when suspending.

<[email protected]> (03/08/22 1.1276.20.1)
[power] Fix sysfs state reporting.

2003-08-31 12:32:21

by Felipe Alfaro Solana

[permalink] [raw]

Subject: Re: Power Management Update

On Sat, 2003-08-30 at 23:25, Patrick Mochel wrote:
> I'm pleased to announce the release of the first patchset of power
> management changes for 2.6.0. The purpose of this release is to give
> people a chance to review and test the PM code before it's sent on to
> Linus.

Hi!

Running with 2.6.0-test4-mm4:

# echo 4 > /proc/acpi/sleep

Stopping tasks: ======|
Freeing memory: ..|
hdc: start_power_step(step: 0)
Unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU: 0
EIP: 0060:[<00000000>] Not taintled VLI
EFLAGS: 00010282
EIP is at 0x0
eax: c032f180 ebx: c039588c ecx: c02f7b50 edx: 00000282
esi: 00000000 edi: cffa1e2c ebp: c13ce780 esp: cffa1d40
ds: 007b es: 007b ss: 0068
Process bash (pid: 1, threadinfo=cffa0000 task=c12bb940)
Stack: c01fbcd1 c039588c cffa1e2c 00000000 00000088 0000001e 0000000f
cffa1e2c
c039588c c03957e0 c01fc063 c039588c cffa1e2c 00000001 cffa0000
c13cd600
cffa0000 cffa1e2c 00000202 00000001 c01fc8a3 c13ce780 ffffffff
00000001
Call Trace:
[<c01fbcd1>] start_request+0x131/0x290
[<c01fc063>] ide_do_request+0x203/0x3b0
[<c01fc8a3>] ide_do_drive_cmd+0xd3/0x130
[<c0205592>] generic_ide_suspend+0x92/0xc0
[<c01f17e8>] suspend_device+0x98/0x100
[<c01f18a8>] device_suspend+0x58/0x80
[<c0138739>] prepare+0x39/0xc0
[<c01387cc>] pm_suspend_disk+0xc/0xc0
[<c0137cc5>] enter_state+0xa5/0xb0
[<c013974b>] software_suspend+0x3b/0x40
[<c01c898a>] acpi_system_write_sleep+0xb3/0xcd
[<c01c88d7>] acpi_system_write_sleep+0x0/0xcd
[<c01564b8>] vfs_write+0xb8/0x130
[<c01565e2>] sys_write+0x42/0x70
[<c02ba00e>] sysenter_past_esp+0x43/0x65

Code: Bad EIP value.
<0>Kernel panic: Attempted to kill init!

Thanks!

Attachments:

config-2.6.0-test4-mm4 (20.35 kB)

2003-08-31 13:04:57

On Mon, Sep 08, 2003 at 12:54:12PM -0700, Patrick Mochel wrote:
> > * swsusp doesn't like accelerated graphics. If the following modules are
> > loaded:
> > i830 68120 20
> > intel_agp 14744 1
> > agpgart 25640 3 intel_agp
> > resuming fails. (Different kind of failures, from spontaneous reboot to
>
> This is not suprising, and likely something that many people will run
> into. There is a lot of driver work that needs to be done, especially WRT
> video devices, as many of them are not tied into the new driver model at
> all.

If you want more testers and interesting bug reports, that should be some
kinfd of priority, no ? Everybody is running with accelerated graphics
modules, nowadays.
>
> For now, the best I can say is to manually unload those modules before
> suspending and reloading them after resume. We'll work on getting the
> drivers fixed up, but it will probably take a while.
>
> > However, the mouse is not working anymore (mouse is usb, the only usb
> > device connected) nor network on eth1 (I haven't tried eth0.)
>
> For both the mouse and eth1, will they work if you unload the modules
> first, and reload them after resuming?

Ok, I tried this: after a normal boot, I went back to runlevel 3,
ifconfig'ed down eth1, unloaded modules i830, hid, ehci-hcd, uhcd-hcd
ne2K-pci and 8390 and echoed 4 to /proc/sleep/acpi. Note that intel_agp,
agpgart and usbcore were still there, those modules can't be removed once
loaded.

The system suspended and resumed correctly.

I ifconfig'ed up eth1 (which loaded automagically the two modules), and
network was working. I loaded hid, ehci-hcd and uhcd-hcd, and mouse was
working. I telinit'ed 5, X started, went back to runlevel 3 to load i830
which I had forgotten, went back again to runlevel 5. X was working fine,
and video acceleration too. (I think I saw a little glitch on screen; a
little gray line, there, that diseapeared quickly.)

Then I tried to pinpoint more precisely what was wrong. Back to telinit
3. ifconfig down eth1, but keep the modules loaded. rmmod i830, hid, but
keep ehci-hcd and uhci-hcd. I expected that, at least, the computer would
suspend and resume, and I wanted to see if I could recover my mouse and
network interface. I got a black screen at suspend time, and had to
reboot with magic sysrq. I thought that the computer wouldn't suspend
twice in a row.

After a clean boot, I tried again my latest experiment: telinit 3, rmmod
i830, rmmod hid, ifconfig eth1 down, echo 4 > /proc/acpi/sleep.
As I said, the computer should be able to suspend/resume in that
configuration. This time, it failed at resuming. Beautifull kernel panic,
tried to kill init, etc.

It isn't logical. To sum up:

agpgart i830 hid+uhci+ehci eth1 | suspend+resume
+intel_agp |
----------------------------------------------------------+--
unloaded unloaded loaded loaded+up | works but
| mouse+eth1 fail

loaded unloaded unloaded unloaded | works and
| mouse+eth1 can be
| recovered

loaded unloaded partially loaded | does not work.
loaded but down

What this probably means is that one of my succes was a piece of luck,
non reliably reproducible. Unfortunately, my wife came back from her
trip, and I now have much less time for testing...

If, anyway, I decide to try test5, what patches should be applied ?

?ric

2003-09-09 15:56:54

by Patrick Mochel

[permalink] [raw]

Subject: Re: Power Management Update

On Tue, 9 Sep 2003, ?ric Brunet wrote:

> On Mon, Sep 08, 2003 at 12:54:12PM -0700, Patrick Mochel wrote:
> > > * swsusp doesn't like accelerated graphics. If the following modules are
> > > loaded:
> > > i830 68120 20
> > > intel_agp 14744 1
> > > agpgart 25640 3 intel_agp
> > > resuming fails. (Different kind of failures, from spontaneous reboot to
> >
> > This is not suprising, and likely something that many people will run
> > into. There is a lot of driver work that needs to be done, especially WRT
> > video devices, as many of them are not tied into the new driver model at
> > all.
>
> If you want more testers and interesting bug reports, that should be some
> kinfd of priority, no ? Everybody is running with accelerated graphics
> modules, nowadays.

It is a priority, but they pose a stiff challenge that not many know how
to resolve, including yours truly. We'll get there..

> agpgart i830 hid+uhci+ehci eth1 | suspend+resume
> +intel_agp |
> ----------------------------------------------------------+--
> unloaded unloaded loaded loaded+up | works but
> | mouse+eth1 fail
>
> loaded unloaded unloaded unloaded | works and
> | mouse+eth1 can be
> | recovered
>
> loaded unloaded partially loaded | does not work.
> loaded but down
>
> What this probably means is that one of my succes was a piece of luck,
> non reliably reproducible. Unfortunately, my wife came back from her
> trip, and I now have much less time for testing...

Heh, thanks for testing this so far. This is definitely helpful in
pointing out some trouble areas.

Pat