Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)

quoted

quoted

Ah, also: The "Freeing memory" phase takes forever. That should
really be fixed.

Well, it does the trick for me, but it takes 50% or so of suspend
time. Some memory managment guru making "freeing memory" faster would
certainly be welcome.
								Pavel
PS: But I'd like to keep it simple...

Haven't looked at it yet. Several crash reports so far, mostly
lockups right after printing the number of pages to save. I wonder
if we have something broken in there. It dies for me once too at
this point.

The PMU locking up with interrupts disabled, for me (Lombard, 400 MHz).
Seems to happen more often on slow machines.
Otherwise, it works (saving to the last swap partition if you try to
specify which one to use; patch sent to Ben FWIW).

Also, at least on pmac laptops, the HD is usually so fast, that
I suspect spending 10 seconds freeing things is less efficient than
spending this 10 seconds writing 200Mb of data to disk :) Also, one
wakup, it's quite painful to see everything be swapped in again. It
may make sense to be less agressive on the memory freeing, though
finding a good balance isn't easy.

I don't mind the wait for memory being freed. Copying more pages with
interrupts disabled would mean a higher chance for PMU lockup, won't it?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

I don't mind the wait for memory being freed. Copying more pages with
interrupts disabled would mean a higher chance for PMU lockup, won't it?

It's also possible that there is a bug and it just crashes :)

Also, I do suspend devices before the page copy, and I quickly hacked a
PMU sysdev that should suspend ADB interrupts (at least) so that should
be fine, except if you have a brightness request in flight maybe ?

The whole PMU suspend thing must be reworked I suppose. (And the battery
monitoring thing "paused" as well, we must wait for async PMU requests,
that is at least battery requests and backlight ones to stop)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi!

quoted

quoted

quoted

Ah, also: The "Freeing memory" phase takes forever. That should
really be fixed.

Well, it does the trick for me, but it takes 50% or so of suspend
time. Some memory managment guru making "freeing memory" faster would
certainly be welcome.
								Pavel
PS: But I'd like to keep it simple...

Haven't looked at it yet. Several crash reports so far, mostly
lockups right after printing the number of pages to save. I wonder
if we have something broken in there. It dies for me once too at
this point.

The PMU locking up with interrupts disabled, for me (Lombard, 400 MHz).
Seems to happen more often on slow machines.
Otherwise, it works (saving to the last swap partition if you try to
specify which one to use; patch sent to Ben FWIW).

What is "PMU locking"? Is there some part of powermac harware that
kills machine if you sleep too long with interrupts disabled?

								Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

What is "PMU locking"? Is there some part of powermac harware that
kills machine if you sleep too long with interrupts disabled?

The PMU is the "Power Management Unit". It's a microcontroller
that does a bunch of things, some PM related, but also the ADB
emulation for the keyboard & trackpad on laptops, the real time
clock, battery management, etc...

We communicate with it via an SPI, it's asynchronous (interrupt
driven) protocol (banging things to a shit register basically).

The kernel is continuously talking to the PMU. If for some reason
communication stops in the middle of a message exchange, the PMU
can time out and shuts the box down.

"PMU suspend" is a hook I added to the driver that completes
pending requests and stops answering to "event" interrupts (those
interrupts are sent by the PMU when we need to read it's incoming
event messages, like keystrokes, environement events, etc...).

When we get such an interrupt, we send a command to read the
event and get the data in the reply. The PMU can timeout in the
middle of that exchange, but won't timeout if we don't ask for
the data at all...

On suspend-to-RAM, since the PMU driver drives the whole suspend
process, there is no real problem, it does things the right way.

But with suspend-to-disk, it's just yet-another device, and so we
need to make sure we properly stop pending communication. The quick
hack I did (added a sysdev with suspend/resume hooks for it) may not
be perfect yet :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

I don't mind the wait for memory being freed. Copying more pages with
interrupts disabled would mean a higher chance for PMU lockup, won't it?

It's also possible that there is a bug and it just crashes :)

Also, I do suspend devices before the page copy, and I quickly hacked a
PMU sysdev that should suspend ADB interrupts (at least) so that should
be fine, except if you have a brightness request in flight maybe ?

I haven't. I've added another pmu_suspend/pmu_resume around the bulk of
pmdisk_save, that seems to have improved things (but not completely). It's
executed outside your sysdev calls, so it shouldn't really improve things.

The whole PMU suspend thing must be reworked I suppose. (And the battery
monitoring thing "paused" as well, we must wait for async PMU requests,
that is at least battery requests and backlight ones to stop)

Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?

Normally yes... pmud isn't running at this point (all processes are frozen)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?

Normally yes... pmud isn't running at this point (all processes are frozen)

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 28 Jan 2004 17:09:36 +0100 (CET)
Michael Schmitz [off-list ref] wrote:

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files,
play with swap priorities to make sure the pages are swapped out to
the file_not_ used for suspend.

Can you try with swsusp2 ppc port, if you have time.

:)

--
Hu Gang / Steve
Linux Registered User 204016
GPG Public Key: http://soulinfo.com/~hugang/HuGang.asc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Can you try with swsusp2 ppc port, if you have time.

It would be really nice if you could provide a unique diff, would be
easier to test ;-)

--
Colin, lazy


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files,
play with swap priorities to make sure the pages are swapped out to
the file_not_ used for suspend.

Can you try with swsusp2 ppc port, if you have time.

I'll have a look at it. Unless you take care of PMU timeouts some way,
I'd dare predict it won't work, though.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 2004-01-29 at 03:09, Michael Schmitz wrote:

quoted

quoted

Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?

Normally yes... pmud isn't running at this point (all processes are frozen)

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

Hrm... Remove the PMU_SYSTEM_READY, it's a bug to call it on a 101...
And it's not needed anyway.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 2004-01-29 at 03:09, Michael Schmitz wrote:

quoted

quoted

Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?

Normally yes... pmud isn't running at this point (all processes are frozen)

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

Ah ? What's up ? suspend trashes the swap ? That's very bad...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 2004-01-29 at 04:02, Hugang wrote:

On Wed, 28 Jan 2004 17:09:36 +0100 (CET)
Michael Schmitz [off-list ref] wrote:

quoted

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files,
play with swap priorities to make sure the pages are swapped out to
the file_not_ used for suspend.

Can you try with swsusp2 ppc port, if you have time.

Well, I though you would do it :) The basis is the same, only the
page copy routine in the assembly has to change afaik...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi!

quoted

quoted

quoted

Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?

Normally yes... pmud isn't running at this point (all processes are frozen)

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

Ah ? What's up ? suspend trashes the swap ? That's very bad...

No, it does not.

But swap space is shared between suspend and swap. And if that place
is full (unlikely), you've got a problem.
								Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

Ah ? What's up ? suspend trashes the swap ? That's very bad...

Nope; freeing memory puts everything in the highest priority swap (happens
to be the first one), and suspend doesn't find enough room in that swap
area. The calculation of free swap done by pmdisk is bogus, it calculates
total free swap, not free swap in the area that pmdisk is going to use for
the snapshot.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Can you try with swsusp2 ppc port, if you have time.

It would be really nice if you could provide a unique diff, would be
easier to test ;-)

Seconded. And I'd like to have it all in one single diff - I started
losing track of what patch to apply on top of the first one already.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

Hrm... Remove the PMU_SYSTEM_READY, it's a bug to call it on a 101...
And it's not needed anyway.

I'm trying a if (pmu_kind != 3) around that call - should it rather be <= 3 ?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 2004-01-29 at 20:30, Michael Schmitz wrote:

quoted

quoted

OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
note: if you are saving a large system and have multiple swap files, play
with swap priorities to make sure the pages are swapped out to the file
_not_ used for suspend.

Hrm... Remove the PMU_SYSTEM_READY, it's a bug to call it on a 101...
And it's not needed anyway.

I'm trying a if (pmu_kind != 3) around that call - should it rather be <= 3 ?

Just remove it for you tests. Only KEYLARGO based PMUs have this call

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/