On Fri, 23 Jan 2004 18:12:53 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> There is at least one reason I think your code cannot work: When
> resuming, you are basically blowing up the MMU hash table and kernel
> page tables when copying the pages. I'm hacking on an implementation
> of
> Attached file is current version of port swsusp to ppc, STILL can not
> works, Benjamin, gave me some comments.
>
> I has add one files swsusp2-asm.S. The save/restore processor state base
> on pmac_sleep.S. The copybackup is copy from gcc generate assmeble.
>
> Now the suspend has no problem,
On Fri, 23 Jan 2004 06:53:26 +1300
Nigel Cunningham <[EMAIL PROTECTED]> wrote:
> I know nothing about the PPC. Is it a uniprocessor?
>
> Regards,
>
> Nigel
There is a document abourt ppc, that can download from Moto,
It help me to understand what is ppc, cool.
http://soulinfo.com/~hugang/tmp/M
I know nothing about the PPC. Is it a uniprocessor?
Regards,
Nigel
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
signature.asc
Description: This is a digitally signed message part
On Tue, 20 Jan 2004 09:03:11 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-01-20 at 04:56, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2004-01-20 at 00:39, Benjamin Herrenschmidt wrote:
> > > I see no reason why this would be needed on ppc, only the last
> > > step, t
Hi!
> > FYI, this is that "ugly C-generated assembly" we are talking about. I
> > do not think it is so bad.
>
> The x86 version has been cleaned up and isn't _that_ bad, though it
> could definitely use some comments and I don't like the "Lxxx" labels,
> I'd rather either use number with the "nb
Hi.
On Wed, 2004-01-21 at 10:54, Benjamin Herrenschmidt wrote:
> > FYI, this is that "ugly C-generated assembly" we are talking about. I
> > do not think it is so bad.
>
> The x86 version has been cleaned up and isn't _that_ bad, though it
> could definitely use some comments and I don't like the
> FYI, this is that "ugly C-generated assembly" we are talking about. I
> do not think it is so bad.
The x86 version has been cleaned up and isn't _that_ bad, though it
could definitely use some comments and I don't like the "Lxxx" labels,
I'd rather either use number with the "nb" or "nf" GAS co
On Wed, 2004-01-21 at 05:30, Nigel Cunningham wrote:
> I'm really interested to see how you are going to initiate and execute
> the suspend.
>
> Perhaps I'm just ignorant, but I can't see how you can do it without
> resorting to the same tricks we use now with regards to CPU context. I
> think you
Hi!
> > On Tue, 2004-01-20 at 00:39, Benjamin Herrenschmidt wrote:
> > > I see no reason why this would be needed on ppc, only the last step,
> > > that is the actual CPU state save, should matter.
> >
> > Besides saving the CPU state, the code copies the original kernel back.
> > It sort of defe
I'm really interested to see how you are going to initiate and execute
the suspend.
Perhaps I'm just ignorant, but I can't see how you can do it without
resorting to the same tricks we use now with regards to CPU context. I
think you're going to find yourself reinventing the wheel.
Regards,
Nige
Hi!
> > > > Well, *all* the data pages are saved, so that would be okay (even if
> > > > they changed, as I'm replacing all the data pages, that should work),
> > > > but I'm not saving kernel text for example.
> > >
> > > Ahh... that's an interesting point. You aren't saving kernel text. I'm
> >
Hi!
> > No, I really do not want to make things more complicated in 2.6. And
> > you should not want to complicate it, too.
>
> I will not impose that limitation on a ppc implementation. I don't
> even want to load the resume image from the boot kernel, it's much more
> easier to load it from the
Hi!
> > Well, *all* the data pages are saved, so that would be okay (even if
> > they changed, as I'm replacing all the data pages, that should work),
> > but I'm not saving kernel text for example.
>
> Ahh... that's an interesting point. You aren't saving kernel text. I'm
> not sure how that cou
On Tue, 2004-01-20 at 22:36, Pavel Machek wrote:
> Hi!
>
> > > Well, *all* the data pages are saved, so that would be okay (even if
> > > they changed, as I'm replacing all the data pages, that should work),
> > > but I'm not saving kernel text for example.
> >
> > Ahh... that's an interesting po
On Tue, 2004-01-20 at 21:04, Pavel Machek wrote:
> Well, *all* the data pages are saved, so that would be okay (even if
> they changed, as I'm replacing all the data pages, that should work),
> but I'm not saving kernel text for example.
Ahh... that's an interesting point. You aren't saving kerne
> I'm not passing device information, but devices *do* have internal
> state. I quiesce them before booting new kernel, but there's probably
> more than one way to quiesce devices...
Not that many. You don't quite know in what state they are when
the BIOS calls you neither in most cases :) Nor wh
> Swsusp saves the data structures from the suspended kernel, so they have to
> match the data structures of the resumed kernel, right?
>
> I't s a bit like trying insmod -f on a module compiled for a completely
> different kernel version... *bang*
No, swsusp saves the whole memory image, includ
Hi!
> > > Well, then what you do is not swsusp.
> > >
> > > swsusp does assume same kernel during suspend and resume. Doing resume
> > > within bootloader (and thus avoiding this) would be completely
> > > different design.
> >
> > Wait... what the hell in swsusp requires this assumption ? It seem
Hi!
> > (1) There's routine during resume that copies pages to their old
> > locations. If you (would want to) have different kernel during resume,
> > how do you guarantee that that "kernel being resumed" does not use
> > memory ocupied by copying routine?
>
> By having the copy routine sit else
On Tue, 20 Jan 2004, Benjamin Herrenschmidt wrote:
> > Well, then what you do is not swsusp.
> >
> > swsusp does assume same kernel during suspend and resume. Doing resume
> > within bootloader (and thus avoiding this) would be completely
> > different design.
>
> Wait... what the hell in swsusp re
> (1) There's routine during resume that copies pages to their old
> locations. If you (would want to) have different kernel during resume,
> how do you guarantee that that "kernel being resumed" does not use
> memory ocupied by copying routine?
By having the copy routine sit elsewhere. You can h
Hi!
> > Well, then what you do is not swsusp.
> >
> > swsusp does assume same kernel during suspend and resume. Doing resume
> > within bootloader (and thus avoiding this) would be completely
> > different design.
>
> Wait... what the hell in swsusp requires this assumption ? It seems to
> me li
Hi!
> > You need to check resulting assembly for stack accesses. So yes, you
> > can compile it from .c file, _but you have to read it_.
>
> Hrm... That's awful and terribly fragile. You should either write
> it entirely in assembly (thus readable & commented) or write it in
Take a look before c
> You need to check resulting assembly for stack accesses. So yes, you
> can compile it from .c file, _but you have to read it_.
Hrm... That's awful and terribly fragile. You should either write
it entirely in assembly (thus readable & commented) or write it in
C with a temporary stack or whateve
> Well, then what you do is not swsusp.
>
> swsusp does assume same kernel during suspend and resume. Doing resume
> within bootloader (and thus avoiding this) would be completely
> different design.
Wait... what the hell in swsusp requires this assumption ? It seems to
me like a completely unne
Hi!
> I can answer a couple of the questions:
>
> > What is this file ? It's absolutely horrible
>
> It should contain the .S equivalent to the swsusp2.c file. It would be
> best if swsusp2.c could simply be compiled, but it appears that it can't
> at the moment on x86 (I need to learn x86 a
Hi!
> > That idea is to have a section that doesn't get replaced when we copy
> > the original kernel back. Thus, small amounts of data that suspend uses
> > or stores can be given the __nosave attribute. An example is the cpu
> > frequency value, which should match the boot kernel, not the value
On Tue, 2004-01-20 at 04:56, Nigel Cunningham wrote:
> Hi.
>
> On Tue, 2004-01-20 at 00:39, Benjamin Herrenschmidt wrote:
> > I see no reason why this would be needed on ppc, only the last step,
> > that is the actual CPU state save, should matter.
>
> Besides saving the CPU state, the code copie
Hi.
On Tue, 2004-01-20 at 00:39, Benjamin Herrenschmidt wrote:
> I see no reason why this would be needed on ppc, only the last step,
> that is the actual CPU state save, should matter.
Besides saving the CPU state, the code copies the original kernel back.
It sort of defeats the purpose to remov
> It should contain the .S equivalent to the swsusp2.c file. It would be
> best if swsusp2.c could simply be compiled, but it appears that it can't
> at the moment on x86 (I need to learn x86 assembly so I can understand
> why).
I see no reason why this would be needed on ppc, only the last step,
Hi.
I can answer a couple of the questions:
On Mon, 2004-01-19 at 16:35, Benjamin Herrenschmidt wrote:
> What is this file ? It's absolutely horrible
It should contain the .S equivalent to the swsusp2.c file. It would be
best if swsusp2.c could simply be compiled, but it appears that it can'
Hi !
Some comments...
>Index: arch/ppc/kernel/swsusp2-asm.S
>===
>--- arch/ppc/kernel/swsusp2-asm.S (revision 0)
>+++ arch/ppc/kernel/swsusp2-asm.S (revision 0)
What is this file ? It's absolutely horrible
>Index: a
Hi.
I'd love to be able to help, but unfortunately the old assembly I know
is good old 6502 :> Hopefully someone else will pipe up and get you
going.
Once you do get it going, I'll be happy to help keep the other parts
updated, so far as I'm able.
Regards,
Nigel
On Mon, 2004-01-19 at 15:52, Hu
34 matches
Mail list logo
