Hi everyone.
Suspend2, version 2.2.2 is now available from
http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz2
This is the first stable release since switching to sharing the lowlevel code
with swsusp. It means that I'm now more dependent on Rafael and Pavel not
changing things in an incompatible way, but it is a gain in that it reduces
the amount of code that needs to be maintained by approximately 1000 lines.
Since I announced my new job a few weeks ago, the impetus to seek to merge
Suspend2 has been renewed. I'm currently building a git tree to this end.
It's not yet publicly available because I'm using stgit and am sometimes
modifying earlier patches in the series and rebasing it against later
versions of Linus' tree, but once it's done, I'll let people know where to
find it.
Regards,
Nigel
On ?t 28-03-06 16:01:14, Nigel Cunningham wrote:
> Hi everyone.
>
> Suspend2, version 2.2.2 is now available from
>
> http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz2
>
> This is the first stable release since switching to sharing the lowlevel code
> with swsusp. It means that I'm now more dependent on Rafael and Pavel not
> changing things in an incompatible way, but it is a gain in that it reduces
> the amount of code that needs to be maintained by approximately 1000 lines.
Nice, thanks.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
Nigel Cunningham wrote:
> Hi everyone.
>
> Suspend2, version 2.2.2 is now available from
>
> http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz2
Wow! Is this ever freaking fast!
Try it folks. Once you do, you'll never go back to the slow way!
Cheers
On ?t 28-03-06 18:51:51, Mark Lord wrote:
> Nigel Cunningham wrote:
> >Hi everyone.
> >
> >Suspend2, version 2.2.2 is now available from
> >
> >http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz2
>
> Wow! Is this ever freaking fast!
> Try it folks. Once you do, you'll never go back to the slow way!
Please do try code at suspend.sf.net. It should be as fast and not
needing big kernel patch.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
Hi.
On Wednesday 29 March 2006 19:19, Pavel Machek wrote:
> On ?t 28-03-06 18:51:51, Mark Lord wrote:
> > Nigel Cunningham wrote:
> > >Hi everyone.
> > >
> > >Suspend2, version 2.2.2 is now available from
> > >
> > >http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz
> > >2
> >
> > Wow! Is this ever freaking fast!
> > Try it folks. Once you do, you'll never go back to the slow way!
>
> Please do try code at suspend.sf.net. It should be as fast and not
> needing big kernel patch.
Don't bother suggesting that to x86_64 owners: compilation is currently broken
in vbetool/lrmi.c (at least).
Regards,
Nigel
On St 29-03-06 20:50:27, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 29 March 2006 19:19, Pavel Machek wrote:
> > On ?t 28-03-06 18:51:51, Mark Lord wrote:
> > > Nigel Cunningham wrote:
> > > >Hi everyone.
> > > >
> > > >Suspend2, version 2.2.2 is now available from
> > > >
> > > >http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz
> > > >2
> > >
> > > Wow! Is this ever freaking fast!
> > > Try it folks. Once you do, you'll never go back to the slow way!
> >
> > Please do try code at suspend.sf.net. It should be as fast and not
> > needing big kernel patch.
>
> Don't bother suggesting that to x86_64 owners: compilation is currently broken
> in vbetool/lrmi.c (at least).
It seems to work at least for some users. I do not have x86-64 machine
easily available, so someone else will have to fix that one.
(Also it should be possible to compile suspend without s2ram support,
avoiding the problem).
Pavel
--
Picture of sleeping (Linux) penguin wanted...
Hi,
On Wednesday 29 March 2006 12:50, Nigel Cunningham wrote:
> On Wednesday 29 March 2006 19:19, Pavel Machek wrote:
> > On Út 28-03-06 18:51:51, Mark Lord wrote:
> > > Nigel Cunningham wrote:
> > > >Hi everyone.
> > > >
> > > >Suspend2, version 2.2.2 is now available from
> > > >
> > > >http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.tar.bz
> > > >2
> > >
> > > Wow! Is this ever freaking fast!
> > > Try it folks. Once you do, you'll never go back to the slow way!
> >
> > Please do try code at suspend.sf.net. It should be as fast and not
> > needing big kernel patch.
>
> Don't bother suggesting that to x86_64 owners: compilation is currently broken
> in vbetool/lrmi.c (at least).
You need to specify ARCH=x86_64 in the Makefile.
Unfortunately this has not been documented (yet).
Greetings,
Rafael
On Thursday 30 March 2006 11:26, Pavel Machek wrote:
> On St 29-03-06 20:50:27, Nigel Cunningham wrote:
> > Hi.
> > > Please do try code at suspend.sf.net. It should be as fast and not
> > > needing big kernel patch.
> >
> > Don't bother suggesting that to x86_64 owners: compilation is currently
> > broken in vbetool/lrmi.c (at least).
>
> It seems to work at least for some users. I do not have x86-64 machine
> easily available, so someone else will have to fix that one.
It builds fine here on x86_64 with gcc 4.1.
> Pavel
--
Arkadiusz Mi?kiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
On Thursday 30 March 2006 19:26, Pavel Machek wrote:
> On St 29-03-06 20:50:27, Nigel Cunningham wrote:
> > Hi.
> >
> > On Wednesday 29 March 2006 19:19, Pavel Machek wrote:
> > > On ?t 28-03-06 18:51:51, Mark Lord wrote:
> > > > Nigel Cunningham wrote:
> > > > >Hi everyone.
> > > > >
> > > > >Suspend2, version 2.2.2 is now available from
> > > > >
> > > > >http://stage.suspend2.net/downloads/all/suspend2-2.2.2-for-2.6.16.ta
> > > > >r.bz 2
> > > >
> > > > Wow! Is this ever freaking fast!
> > > > Try it folks. Once you do, you'll never go back to the slow way!
> > >
> > > Please do try code at suspend.sf.net. It should be as fast and not
> > > needing big kernel patch.
> >
> > Don't bother suggesting that to x86_64 owners: compilation is currently
> > broken in vbetool/lrmi.c (at least).
>
> It seems to work at least for some users. I do not have x86-64 machine
> easily available, so someone else will have to fix that one.
>
> (Also it should be possible to compile suspend without s2ram support,
> avoiding the problem).
> Pavel
I just found the line saying pciutils-devel is needed. Maybe that will make
the difference.
Regards,
Nigel
On Thursday 30 March 2006 19:34, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday 29 March 2006 12:50, Nigel Cunningham wrote:
> > Don't bother suggesting that to x86_64 owners: compilation is currently
> > broken in vbetool/lrmi.c (at least).
I get:
nigel@nigel_c_laptop:/usr/src/uswsusp/suspend$ make suspend
cc -Wall -O2 -c vbetool/lrmi.c -o vbetool/lrmi.o
vbetool/lrmi.c:83: error: field ‘vm’ has incomplete type
vbetool/lrmi.c: In function ‘get_int_seg’:
vbetool/lrmi.c:111: warning: cast to pointer from integer of different size
vbetool/lrmi.c: In function ‘get_int_off’:
vbetool/lrmi.c:118: warning: cast to pointer from integer of different size
vbetool/lrmi.c: In function ‘LRMI_init’:
vbetool/lrmi.c:147: warning: cast from pointer to integer of different size
vbetool/lrmi.c:155: warning: cast from pointer to integer of different size
vbetool/lrmi.c:156: warning: cast from pointer to integer of different size
vbetool/lrmi.c: In function ‘set_regs’:
vbetool/lrmi.c:191: error: ‘IF_MASK’ undeclared (first use in this function)
vbetool/lrmi.c:191: error: (Each undeclared identifier is reported only once
vbetool/lrmi.c:191: error: for each function it appears in.)
vbetool/lrmi.c:191: error: ‘IOPL_MASK’ undeclared (first use in this function)
vbetool/lrmi.c: In function ‘em_inbl’:
vbetool/lrmi.c:337: error: invalid lvalue in asm output 0
vbetool/lrmi.c: In function ‘em_inb’:
vbetool/lrmi.c:345: error: invalid lvalue in asm output 0
vbetool/lrmi.c: In function ‘em_inw’:
vbetool/lrmi.c:353: error: invalid lvalue in asm output 0
vbetool/lrmi.c: In function ‘em_inl’:
vbetool/lrmi.c:361: error: invalid lvalue in asm output 0
vbetool/lrmi.c: In function ‘run_vm86’:
vbetool/lrmi.c:594: warning: implicit declaration of function ‘VM86_TYPE’
vbetool/lrmi.c:594: error: ‘VM86_INTx’ undeclared (first use in this function)
vbetool/lrmi.c:595: warning: implicit declaration of function ‘VM86_ARG’
vbetool/lrmi.c:613: error: ‘VIF_MASK’ undeclared (first use in this function)
vbetool/lrmi.c:613: error: ‘TF_MASK’ undeclared (first use in this function)
vbetool/lrmi.c:618: error: ‘VM86_UNKNOWN’ undeclared (first use in this
function)
vbetool/lrmi.c: In function ‘LRMI_int’:
vbetool/lrmi.c:840: error: ‘IF_MASK’ undeclared (first use in this function)
vbetool/lrmi.c:840: error: ‘IOPL_MASK’ undeclared (first use in this function)
make: *** [vbetool/lrmi.o] Error 1
nigel@nigel_c_laptop:/usr/src/uswsusp/suspend$
Regards,
Nigel
Hi!
> > > > Please do try code at suspend.sf.net. It should be as fast and not
> > > > needing big kernel patch.
> > >
> > > Don't bother suggesting that to x86_64 owners: compilation is currently
> > > broken in vbetool/lrmi.c (at least).
> >
> > It seems to work at least for some users. I do not have x86-64 machine
> > easily available, so someone else will have to fix that one.
> >
> > (Also it should be possible to compile suspend without s2ram support,
> > avoiding the problem).
>
> I just found the line saying pciutils-devel is needed. Maybe that will make
> the difference.
I do not see missing includes, so I'm not sure it will help. Can you
try adding
ARCH=x86_64
to Makefile?
Pavel
--
Picture of sleeping (Linux) penguin wanted...
Nigel Cunningham <[email protected]> wrote:
> make: *** [vbetool/lrmi.o] Error 1
LRMI will never compile on x86_64 - the kernel doesn't do vm86. It
should be using the x86emu backend.
--
Matthew Garrett | [email protected]
Hi.
On Thursday 30 March 2006 21:55, Pavel Machek wrote:
> Hi!
>
> > > > > Please do try code at suspend.sf.net. It should be as fast and not
> > > > > needing big kernel patch.
> > > >
> > > > Don't bother suggesting that to x86_64 owners: compilation is
> > > > currently broken in vbetool/lrmi.c (at least).
> > >
> > > It seems to work at least for some users. I do not have x86-64 machine
> > > easily available, so someone else will have to fix that one.
> > >
> > > (Also it should be possible to compile suspend without s2ram support,
> > > avoiding the problem).
> >
> > I just found the line saying pciutils-devel is needed. Maybe that will
> > make the difference.
>
> I do not see missing includes, so I'm not sure it will help. Can you
> try adding
>
> ARCH=x86_64
>
> to Makefile?
Heh. It worked. Maybe you should have something to figure out what arch the
user is using :) It seems a bit strange to tell the compiler that I'm using
the arch it ought to know I'm using.
Regards,
Nigel
Hi!
> > I do not see missing includes, so I'm not sure it will help. Can you
> > try adding
> >
> > ARCH=x86_64
> >
> > to Makefile?
>
> Heh. It worked. Maybe you should have something to figure out what arch the
> user is using :) It seems a bit strange to tell the compiler that I'm using
> the arch it ought to know I'm using.
Good. Does
ARCH=`uname -m`
work, too? If so, I'll commit it... when sf.net gets up.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
Hi,
On Thursday 30 March 2006 11:39, Nigel Cunningham wrote:
> On Thursday 30 March 2006 19:34, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Wednesday 29 March 2006 12:50, Nigel Cunningham wrote:
> > > Don't bother suggesting that to x86_64 owners: compilation is currently
> > > broken in vbetool/lrmi.c (at least).
>
> I get:
Please try the Makefile that I use on x86_64 (attached).
Greetings,
Rafael
Hi,
On Thursday 30 March 2006 14:05, Pavel Machek wrote:
> > > I do not see missing includes, so I'm not sure it will help. Can you
> > > try adding
> > >
> > > ARCH=x86_64
> > >
> > > to Makefile?
> >
> > Heh. It worked. Maybe you should have something to figure out what arch the
> > user is using :) It seems a bit strange to tell the compiler that I'm using
> > the arch it ought to know I'm using.
>
> Good. Does
>
> ARCH=`uname -m`
>
> work, too?
No, it doesn't.
Rafael
On Thursday 30 March 2006 14:17, Rafael J. Wysocki wrote:
> On Thursday 30 March 2006 14:05, Pavel Machek wrote:
> > > > I do not see missing includes, so I'm not sure it will help. Can you
> > > > try adding
> > > >
> > > > ARCH=x86_64
> > > >
> > > > to Makefile?
> > >
> > > Heh. It worked. Maybe you should have something to figure out what arch the
> > > user is using :) It seems a bit strange to tell the compiler that I'm using
> > > the arch it ought to know I'm using.
> >
> > Good. Does
> >
> > ARCH=`uname -m`
> >
> > work, too?
>
> No, it doesn't.
Something like this works, though:
ARCH:=$(shell uname -m)
Rafael
On Čt 30-03-06 14:24:50, Rafael J. Wysocki wrote:
> On Thursday 30 March 2006 14:17, Rafael J. Wysocki wrote:
> > On Thursday 30 March 2006 14:05, Pavel Machek wrote:
> > > > > I do not see missing includes, so I'm not sure it will help. Can you
> > > > > try adding
> > > > >
> > > > > ARCH=x86_64
> > > > >
> > > > > to Makefile?
> > > >
> > > > Heh. It worked. Maybe you should have something to figure out what arch the
> > > > user is using :) It seems a bit strange to tell the compiler that I'm using
> > > > the arch it ought to know I'm using.
> > >
> > > Good. Does
> > >
> > > ARCH=`uname -m`
> > >
> > > work, too?
> >
> > No, it doesn't.
>
> Something like this works, though:
>
> ARCH:=$(shell uname -m)
looks good, can you commit it (when sf works again :-).
Pavel
--
Picture of sleeping (Linux) penguin wanted...
On Thursday 30 March 2006 14:59, Pavel Machek wrote:
> On Čt 30-03-06 14:24:50, Rafael J. Wysocki wrote:
> > On Thursday 30 March 2006 14:17, Rafael J. Wysocki wrote:
> > > On Thursday 30 March 2006 14:05, Pavel Machek wrote:
> > > > > > I do not see missing includes, so I'm not sure it will help. Can you
> > > > > > try adding
> > > > > >
> > > > > > ARCH=x86_64
> > > > > >
> > > > > > to Makefile?
> > > > >
> > > > > Heh. It worked. Maybe you should have something to figure out what arch the
> > > > > user is using :) It seems a bit strange to tell the compiler that I'm using
> > > > > the arch it ought to know I'm using.
> > > >
> > > > Good. Does
> > > >
> > > > ARCH=`uname -m`
> > > >
> > > > work, too?
> > >
> > > No, it doesn't.
> >
> > Something like this works, though:
> >
> > ARCH:=$(shell uname -m)
>
> looks good, can you commit it (when sf works again :-).
Yup, I will.
Rafael
Hi.
On Thursday 30 March 2006 22:13, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 30 March 2006 11:39, Nigel Cunningham wrote:
> > On Thursday 30 March 2006 19:34, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Wednesday 29 March 2006 12:50, Nigel Cunningham wrote:
> > > > Don't bother suggesting that to x86_64 owners: compilation is
> > > > currently broken in vbetool/lrmi.c (at least).
> >
> > I get:
>
> Please try the Makefile that I use on x86_64 (attached).
Am I right in guessing that I don't need to anymore, given the other emails on
this thread?
Regards,
Nigel
On Friday 31 March 2006 01:14, Nigel Cunningham wrote:
> On Thursday 30 March 2006 22:13, Rafael J. Wysocki wrote:
> > On Thursday 30 March 2006 11:39, Nigel Cunningham wrote:
> > > On Thursday 30 March 2006 19:34, Rafael J. Wysocki wrote:
> > > > On Wednesday 29 March 2006 12:50, Nigel Cunningham wrote:
> > > > > Don't bother suggesting that to x86_64 owners: compilation is
> > > > > currently broken in vbetool/lrmi.c (at least).
> > >
> > > I get:
> >
> > Please try the Makefile that I use on x86_64 (attached).
>
> Am I right in guessing that I don't need to anymore, given the other emails on
> this thread?
Yes, you are. :-)
Greetings,
Rafael