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

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

[Michael Schmitz]

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

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

[Benjamin Herrenschmidt]

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

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

[Michael Schmitz]

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

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

[Benjamin Herrenschmidt]

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

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

[Michael Schmitz]

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

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

[Hugang]

On Wed, 28 Jan 2004 17:09:36 +0100 (CET)
Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> 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/

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

[Colin Leroy]

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

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

[Michael Schmitz]

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

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

[Michael Schmitz]

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

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

[Benjamin Herrenschmidt]

On Thu, 2004-01-29 at 04:02, Hugang wrote:
> On Wed, 28 Jan 2004 17:09:36 +0100 (CET)
> Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> 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.

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/

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

[Benjamin Herrenschmidt]

On Thu, 2004-01-29 at 03:09, Michael Schmitz wrote:
> > > 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/

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

[Michael Schmitz]

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

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

[Benjamin Herrenschmidt]

On Thu, 2004-01-29 at 20:30, Michael Schmitz 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.
> >
> > 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/

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

[Benjamin Herrenschmidt]

On Thu, 2004-01-29 at 03:09, Michael Schmitz wrote:
> > > 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/

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

[Pavel Machek]

Hi!

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

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

[Michael Schmitz]

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

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

[Pavel Machek]

Hi!

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

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

[Benjamin Herrenschmidt]

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