Hi, Sebastian,
On Wed, 2008-04-30 at 00:12 +0200, Sebastian Siewior wrote:
> * Huang, Ying | 2008-04-25 11:11:17 [+0800]:
>
> >Hi, Sebastian,
> Hi Huang,
>
> sorry for the delay.
>
> >I changed the patches to group the read or write together instead of
> >interleaving. Can you help me to test t
Hi,
On Sat, 2008-05-03 at 23:25 -0700, dean gaudet wrote:
> one of the more important details in evaluating these changes would be the
> family/model/stepping of the processors being microbenchmarked... could
> you folks include /proc/cpuinfo with the results?
The file attached is /proc/cpuinfo
On Tue, 6 May 2008, Herbert Xu wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW: is it guaranteed for crypto functions that they read the source data
only once?
There is no such guarantee.
Cheers,
So we'll have to copy the sector to temporary space before encrypting it.
I'll look at
Herbert Xu wrote:
> Actually this just exposed an ancient bug in hmac. It relied
on the key to be in identity-mapped memory which has never been
guaranteed.
This patch fixes the problem for me.
I have tested the patch and it resolves the issue indeed. It also let's
the same RIPEMD hmac test
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
>
> BTW: is it guaranteed for crypto functions that they read the source data
> only once?
There is no such guarantee.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana
Adrian-Ken R??egsegger <[EMAIL PROTECTED]> wrote:
>
> using the cryptodev-2.6 tree I noticed that the hmac tests that have
> keys larger than blocksize for md5 and the various sha algorithms all
> fail (tcrypt mode=10[0-5]). The other tests seem to pass just fine.
>
> The issue seems to have come
