ac100 team mailing list archive

[Gordan Bobic <gordan@xxxxxxxxxx>]

On 09/02/2011 05:49 PM, Henning Heinold wrote:
> On Fri, Sep 02, 2011 at 05:32:05PM +0100, Gordan Bobic wrote:
> > > I have here locally a patch which fixes completly the build of aes
> > > and using the latest
> > > stuff from the nvidia git tree. I have now pushed it to
> > >
> > > https://gitorious.org/~woglinde/ac100/woglindes-marvin24s-kernel/commits/chromeos-ac100-2.6.38-aes
> >
> > Awesome, thanks Henning. I got the patchset that enables AES and it
> > didn't work against Marc's kernel tree (tegra-aes.[c|h] issues),
> > although it patched cleanly. I got those two files out of your tree
> > and rebuilt, and it seems to work now - module loads and the
> > availability is exposed in /proc/crypto! :D Going to do some testing
> > with cryptodev enabled openssl tonight. :)
>
> ????
> Before I pushed I rebased it against the latest commits from Marvin24 and


There was a difference post-patch between the files in your tree and the 
ones I had. I'll

> I already tried to get it working with the openssl engine, but it did not
> work.

I actually have with working. I can see the reference count on the 
module go up and get the expected output from "openssl speed -evp 
aes-128-cbc"

There seems to be a bug somewhere in the kernel module, though. At the 
end of the test run, I get:

*** glibc detected *** openssl: double free or corruption (!prev): 
0x0067abd8 ***
Aborted

I get this both with the new openssl 1.0.0d I just built and the older 
version that has been working correctly with AES offload on my 
SheevaPlug for a while. Also checked the new built openssl on the 
SheevaPlug and that works correctly without the mentioned double free 
error. I also did a package verify on glibc and that passes the checks.

So I'm guessing there is a but in the tegra-aes kernel module where it 
does something weird with the memory addresses.

Performance-wise, the AES speed is about 1/3 of what it is on a 1.2GHz 
Marvell Kirkwood, so as expected, it's not great, but it does seem to 
free up CPU time which I guess is the main point. Kirkwood's offloaded 
AES performance beats both Tegra's userspace and offloaded figures.

Tegra manages about 6400 8KB blocks in 3 seconds in software and about 
2500 8KB blocks using the offload.

For Kirkwood figures, have a look here:
http://www.altechnative.net/?p=174

The method I used is the same (crytpodev kernel module).

Gordan