On Tue, Jul 18, 2006 at 12:52:44PM +0200, Stefan Seyfried wrote:
> Hi,
>
> i have the following in my queue. This updates the code to the vbetool 0.6
> codebase. There is nothing in there which should actually make any difference
> to s2ram, but it might reduce the "you don't even use the latest v
Hi,
I dug this out again after updating the vbetool code.
This hack does the equivalent of
X=`vbetool vbemode get`
vbetool vbemode set $X
This actually works fine on many intel chips (i810/i855gm, e.g. compaq
nx5000) which are now listed as "VBE_POST|VBE_SAVE" and should be less
intrusive than
Hi,
On Wednesday 19 July 2006 11:17, Stefan Seyfried wrote:
> I dug this out again after updating the vbetool code.
> This hack does the equivalent of
>
> X=`vbetool vbemode get`
>
>
> vbetool vbemode set $X
Nice. [Perhaps I should try it on my box.]
> This actually works fine on many intel
On Wed, Jul 19, 2006 at 12:00:48PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday 19 July 2006 11:17, Stefan Seyfried wrote:
> > I dug this out again after updating the vbetool code.
> > This hack does the equivalent of
> >
> > X=`vbetool vbemode get`
> >
> >
> > vbetool vbemode set $X
On Wednesday 19 July 2006 12:06, Stefan Seyfried wrote:
> On Wed, Jul 19, 2006 at 12:00:48PM +0200, Rafael J. Wysocki wrote:
]--snip--[
> > > +void set_vbe_mode(int mode)
> > > +{
> > > + (void)do_set_mode(mode, 0);
> > > +}
> >
> > I'd remove the (void) here.
>
> I think i did this due to a co
> On Tue, Jul 18, 2006 at 12:52:44PM +0200, Stefan Seyfried wrote:
> > Hi,
> >
> > i have the following in my queue. This updates the code to the vbetool 0.6
> > codebase. There is nothing in there which should actually make any
> > difference
> > to s2ram, but it might reduce the "you don't even
Hi!
> I dug this out again after updating the vbetool code.
> This hack does the equivalent of
>
> X=`vbetool vbemode get`
>
>
> vbetool vbemode set $X
>
> This actually works fine on many intel chips (i810/i855gm, e.g. compaq
> nx5000) which are now listed as "VBE_POST|VBE_SAVE" and should be
On Wed, Jul 19, 2006 at 04:20:35PM +0200, Pavel Machek wrote:
> Looks okay to me. So nx5 now actually works?
Yes. actually it works for some time already, some ACPI-update around ~2.6.10
apparently fixed a lot of the machines.
--
Stefan Seyfried | "Please, just tell peopl
Hi,
The appended patch makes s2disk/s2both and resume use libgcrypt instead
of openssl. It also replaces Blowfish with AES (128bit).
Unfortunately it's huge, but seems to work. I've tested it on two x86_64
machines with 1024- and 2048-bit RSA keys. I'd be grateful if someone
could test it on i
Rafael J. Wysocki wrote:
> The libgcrypt's AES seems to be significantly slower than the openssl's
> Blowfish, but well.
libgcrypt is supposed to do Blowfish too (GCRY_CIPHER_BLOWFISH). What is
the reason for switching to AES?
Michal
Hi!
> > > I believe we should start the "let the whitelist live in HAL" era :-)
> >
> > Okay, can you try to write parser with libxml?
>
> Well, we'd first need to have the infrastructure to match against. We
> have a (very primitive) pci-bus-scanner in the radeontool source. I
> wrote (well, c&
On Wednesday 19 July 2006 18:40, Michal Schmidt wrote:
> Rafael J. Wysocki wrote:
> > The libgcrypt's AES seems to be significantly slower than the openssl's
> > Blowfish, but well.
>
> libgcrypt is supposed to do Blowfish too (GCRY_CIPHER_BLOWFISH). What is
> the reason for switching to AES?
No
Hi Rafael
On 7/19/06, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The appended patch makes s2disk/s2both and resume use libgcrypt instead
> of openssl. It also replaces Blowfish with AES (128bit).
>
It works perfectly (only tested suspend-to-disk). Great work, as usual.
> The libgcry
Il Wed, Jul 19, 2006 at 05:55:17PM +0200, Rafael J. Wysocki ha scritto:
> The libgcrypt's AES seems to be significantly slower than the openssl's
> Blowfish, but well. Also IMHO libgcrypt is less convenient than openssl
> and the documentation sucks.
Agree...
Btw, it should be made very clear
On Wednesday 19 July 2006 21:38, Luca wrote:
> Il Wed, Jul 19, 2006 at 05:55:17PM +0200, Rafael J. Wysocki ha scritto:
> > The libgcrypt's AES seems to be significantly slower than the openssl's
> > Blowfish, but well. Also IMHO libgcrypt is less convenient than openssl
> > and the documentation
Hi,
On Wednesday 19 July 2006 21:09, Fabio Comolli wrote:
> On 7/19/06, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > The appended patch makes s2disk/s2both and resume use libgcrypt instead
> > of openssl. It also replaces Blowfish with AES (128bit).
> >
>
> It works perfectly (only tested su
Hi,
The appended patch fixes Makefiles so that s2both gets built too if 'make' is
run without arguments.
Greetings,
Rafael
--
Makefile | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
Index: suspend/Makefile
==
Hi!
> > > The appended patch makes s2disk/s2both and resume use libgcrypt instead
> > > of openssl. It also replaces Blowfish with AES (128bit).
> > >
> >
> > It works perfectly (only tested suspend-to-disk). Great work, as usual.
>
> Thanks! :-)
>
> > > The libgcrypt's AES seems to be signifi
Hi!
> The appended patch fixes Makefiles so that s2both gets built too if 'make' is
> run without arguments.
Looks good to me. (Sorry, I probably will not be able to test the new
encrypted swsusp -- I'm at OLS and have a lot of fun with new
machine...)
19 matches
Mail list logo