Hi!
> I didn't know who to include as the wizards of the matter.
>
> > > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> > > kernel with just the necessary parts for my work (version 2.6.23-rc3
> > > taken from kernel.org), then I can't make the machine sleep: when I
> >
Hi!
> Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
> latest patch you posted, and while the kernel driver seem to work ok
> (though you can feel the lack of a proper acceleration curve), the
> synaptics driver in X doesn't work in any useable way. I updated the one
> that c
On Ne 25-12-05 09:27:51, Benjamin Herrenschmidt wrote:
> On Sat, 2005-12-24 at 21:17 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
> > > latest patch you posted, and while the kernel driver
Hi!
> > On Mon, 2005-08-01 at 15:54 +0200, Antonio-M. Corbi Bellot wrote:
> >
> > > Has anyone observed this behaviour (O.S. halt ok but _no_ power-off at
> > > the end) with these new '-rc' kernels?
> >
> > Yes. I haven't looked for the cause yet though.
>
> I found that if you comment the
>
Hi!
> > > Pavel Machek wrote:
> > >
> > > >Can you try without USB?
> > > >
> > > Not really. The keyboard is USB, and there's no PS/2 connector. I guess
> > > I maybe could do it via a timer, unload the modules and then ha
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
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!
> > 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
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!
> > (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
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!
> > 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
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
> >
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
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
16 matches
Mail list logo
