[gentoo-user] Problem building x11-libs:libxcb-1.16

[Walter Dnes]

  I have a desktop PC and and a "hot backup" ready to take over on a
moment's notice.  I keep the configs and settings the same.  Today I
tried to update both machines.  The main desktop was OK, but the hot
backup ran into a prolem with x11-libs:libxcb-1.16  Before anybody asks,
/etc/locale.gen is identical on both.  The uncommented lines are...

en_US ISO-8859-1
en_US.UTF-8 UTF-8

  Not sure about the error message

UnicodeEncodeError: 'latin-1' codec can't encode character '\u201c' in position 
68: ordinal not in range(256)

  Build log attached.  Any ideas?.

-- 
Roses are red
Roses are blue
Depending on their velocity
Relative to you


x11-libs:libxcb-1.16:20231024-010713.log.gz
Description: application/gzip

RE: [gentoo-user] RE: libva-glx.so.2

[Laurence Perkins]

> From: Dale rdalek1...@gmail.com
> Sent: Monday, October 23, 2023 12:47 PM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] RE: libva-glx.so.2
>
> Laurence Perkins wrote:
> > From: Laurence Perkins lperk...@openeye.net
> > Sent: Monday, October 23, 2023 11:05 AM
> > To: gentoo-user@lists.gentoo.org
> > Subject: [gentoo-user] libva-glx.so.2
> >
> > I have a program with an embedded copy of ffmpeg that is choking on a lack 
> > of libva-glx.so.2.
> >
> > Debian has it in a libva-glx package.
> > Manjaro has it in their general libva package.
> >
> > On Gentoo there is no trace of it...  At least not until I use the 'ebuild' 
> > tool to build the libva package manually and sic 'find' on the compilation 
> > results.
> >
> > Then I find 
> > /var/tmp/portage/media-libs/libva-2.19.0/work/libva-2.19.0/va/.libs/libva-glx.so.2
> >
> > So...  apparently it builds the glx support libraries in a *hidden* folder? 
> >  And I'm guessing then the ebuild's install phase fails to spot it?
> >
> > I'm thinking this is probably worthy of a bug report, but I want to make 
> > sure there's not some reason why these libraries are being left out on 
> > purpose first.  Other distros have them, and I see at least one bug report 
> > about Steam now requiring it, so it probably needs sorting out somehow...
> >
> >
> > LMP
>
> Bit of a followup.  Poking around a bit more I find "-Dwith_glx=no" embedded 
> in the ebuild.  So apparently somebody back in the day decided it wasn't even 
> worthy of a USE flag.  I can tweak my own locally for now and will put a 
> request for it on the bug tracker.
>
> LMP
>
>
> If you not familiar with this site, you may want to check it out.  It comes 
> in handy when trying to find what file belongs to what package when you don't 
> have it yet.
>
> https://www.portagefilelist.de/index.php
>
> I found this:
>
> https://www.portagefilelist.de/index.php?fs=*libva*glx*#panchor
>
> In case that link doesn't work, I searched for this.  *libva*glx*  It shows 
> the following, for others who don't want to search.
>
>
> FilenameFilepath  
>Category Package Version Arch
> libva-glx.so.1.4000.0 /usr/lib64/libva-glx.so.1.4000.0 
> media-libs media-libs/libva-compat 1.8.3-r2 amd64
> libva-glx.so.1 /usr/lib64/libva-glx.so.1  
>media-libs media-libs/libva-compat 1.8.3-r2 amd64
> libva-glx.so.1.4000.0.debug  
> /usr/lib/debug/usr/lib64/libva-glx.so.1.4000.0.debug media-libs 
> media-libs/libva-compat 1.8.3-r2 amd64
>
>
> If that is the exact ones you are looking for, that's where they come from.
>
> Hope that helps.
>
> Dale
>
> :-)  :-)
>

Well that's interesting...  I have PFL installed on my systems so I can use the 
"e-file" command to search that database, but I was searching specifically for 
the libva-2.x version of it and so found nothing.

Meanwhile, further digging has found 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9eaf08653a2ada19b94c9807a6b85008a125b3c

So apparently they turned it off back in April, but left it on in the 
libva-compat package since that doesn't cause circular dependency issues.

Problem is that everyone else still uses it, so if you're running stuff that 
wasn't compiled on Gentoo it might not work as well as you might like.

I'm going to ask nicely and see if we can have a USE flag for it.  I'd really 
rather not maintain a fork of the ebuild for something so trivial.

LMP

Re: [gentoo-user] RE: libva-glx.so.2

[Dale]

Laurence Perkins wrote:
>
> > From: Laurence Perkins lperk...@openeye.net
> 
>
> > Sent: Monday, October 23, 2023 11:05 AM
>
> > To: gentoo-user@lists.gentoo.org 
>
> > Subject: [gentoo-user] libva-glx.so.2
>
> >
>
> > I have a program with an embedded copy of ffmpeg that is choking on
> a lack of libva-glx.so.2.
>
> >
>
> > Debian has it in a libva-glx package.
>
> > Manjaro has it in their general libva package.
>
> >
>
> > On Gentoo there is no trace of it…  At least not until I use the
> ‘ebuild’ tool to build the libva package manually and sic ‘find’ on
> the compilation results.
>
> >
>
> > Then I find
> /var/tmp/portage/media-libs/libva-2.19.0/work/libva-2.19.0/va/.libs/libva-glx.so.2
>
> >
>
> > So…  apparently it builds the glx support libraries in a *hidden*
> folder?  And I’m guessing then the ebuild’s install phase fails to
> spot it? 
>
> >
>
> > I’m thinking this is probably worthy of a bug report, but I want to
> make sure there’s not some reason why these libraries are being left
> out on purpose first.  Other distros have them, and I see at least one
> bug report about Steam now requiring it, so it probably needs sorting
> out somehow…
>
> >
>
> >
>
> > LMP
>
>  
>
> Bit of a followup.  Poking around a bit more I find "-Dwith_glx=no"
> embedded in the ebuild.  So apparently somebody back in the day
> decided it wasn't even worthy of a USE flag.  I can tweak my own
> locally for now and will put a request for it on the bug tracker.
>
>  
>
> LMP
>


If you not familiar with this site, you may want to check it out.  It
comes in handy when trying to find what file belongs to what package
when you don't have it yet. 

https://www.portagefilelist.de/index.php

I found this: 

https://www.portagefilelist.de/index.php?fs=*libva*glx*#panchor

In case that link doesn't work, I searched for this.  *libva*glx*  It
shows the following, for others who don't want to search.


Filename                                Filepath                        
                Category     Package     Version     Arch
libva-glx.so.1.4000.0             /usr/lib64/libva-glx.so.1.4000.0    
media-libs     media-libs/libva-compat     1.8.3-r2     amd64
libva-glx.so.1                         /usr/lib64/libva-glx.so.1        
        media-libs     media-libs/libva-compat     1.8.3-r2     amd64
libva-glx.so.1.4000.0.debug 
/usr/lib/debug/usr/lib64/libva-glx.so.1.4000.0.debug     media-libs    
media-libs/libva-compat     1.8.3-r2     amd64


If that is the exact ones you are looking for, that's where they come
from. 

Hope that helps.

Dale

:-)  :-) 

[gentoo-user] RE: libva-glx.so.2

[Laurence Perkins]

> From: Laurence Perkins lperk...@openeye.net
> Sent: Monday, October 23, 2023 11:05 AM
> To: gentoo-user@lists.gentoo.org
> Subject: [gentoo-user] libva-glx.so.2
>
> I have a program with an embedded copy of ffmpeg that is choking on a lack of 
> libva-glx.so.2.
>
> Debian has it in a libva-glx package.
> Manjaro has it in their general libva package.
>
> On Gentoo there is no trace of it...  At least not until I use the 'ebuild' 
> tool to build the libva package manually and sic 'find' on the compilation 
> results.
>
> Then I find 
> /var/tmp/portage/media-libs/libva-2.19.0/work/libva-2.19.0/va/.libs/libva-glx.so.2
>
> So...  apparently it builds the glx support libraries in a *hidden* folder?  
> And I'm guessing then the ebuild's install phase fails to spot it?
>
> I'm thinking this is probably worthy of a bug report, but I want to make sure 
> there's not some reason why these libraries are being left out on purpose 
> first.  Other distros have them, and I see at least one bug report about 
> Steam now requiring it, so it probably needs sorting out somehow...
>
>
> LMP

Bit of a followup.  Poking around a bit more I find "-Dwith_glx=no" embedded in 
the ebuild.  So apparently somebody back in the day decided it wasn't even 
worthy of a USE flag.  I can tweak my own locally for now and will put a 
request for it on the bug tracker.

LMP

[gentoo-user] libva-glx.so.2

[Laurence Perkins]

I have a program with an embedded copy of ffmpeg that is choking on a lack of 
libva-glx.so.2.

Debian has it in a libva-glx package.
Manjaro has it in their general libva package.

On Gentoo there is no trace of it...  At least not until I use the 'ebuild' 
tool to build the libva package manually and sic 'find' on the compilation 
results.

Then I find 
/var/tmp/portage/media-libs/libva-2.19.0/work/libva-2.19.0/va/.libs/libva-glx.so.2

So...  apparently it builds the glx support libraries in a *hidden* folder?  
And I'm guessing then the ebuild's install phase fails to spot it?

I'm thinking this is probably worthy of a bug report, but I want to make sure 
there's not some reason why these libraries are being left out on purpose 
first.  Other distros have them, and I see at least one bug report about Steam 
now requiring it, so it probably needs sorting out somehow...


LMP

Re: [gentoo-user] rsync options after backup restore. Transfer speed again.

[Frank Steinmetzger]

Am Mon, Oct 23, 2023 at 02:29:26AM -0500 schrieb Dale:
> Dale wrote:
> >
> > Second problem.  The transfer speed is back to the old slower speed. 
> > I'm pretty sure I am using the same old options on both ends.  Still,
> > it's back to being slow again.  Some info:
> >
> >
> > <<< SNIP >>>
> > Did I miss something?  Typo maybe?  I'm pretty sure I used copy and
> > paste but still. 
> >
> > Thanks.
> >
> > Dale
> >
> > :-)  :-) 
> 
> 
> I been working on the speed problem again.  I rebuilt the kernel on
> fireball and I think some changes made a huge change.  This is the
> results from fireball now:
> 
> 
> root@fireball / # cryptsetup benchmark
> # Tests are approximate using memory only (no storage IO).
> PBKDF2-sha1   931239 iterations per second for 256-bit key
> PBKDF2-sha256    1356501 iterations per second for 256-bit key
> PBKDF2-sha512 972705 iterations per second for 256-bit key
> PBKDF2-ripemd160  648871 iterations per second for 256-bit key
> PBKDF2-whirlpool  362077 iterations per second for 256-bit key
> argon2i   5 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> argon2id  4 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> # Algorithm |   Key |  Encryption |  Decryption
>     aes-cbc    128b   570.8 MiB/s  2045.6 MiB/s
>     serpent-cbc    128b    91.1 MiB/s   310.0 MiB/s
>     twofish-cbc    128b   198.7 MiB/s   218.9 MiB/s
>     aes-cbc    256b   428.8 MiB/s  1670.4 MiB/s
>     serpent-cbc    256b    91.6 MiB/s   309.5 MiB/s
>     twofish-cbc    256b   199.8 MiB/s   219.2 MiB/s
>     aes-xts    256b  1821.2 MiB/s  1767.1 MiB/s
>     serpent-xts    256b   265.9 MiB/s   270.2 MiB/s
>     twofish-xts    256b   201.0 MiB/s   204.2 MiB/s
>     aes-xts    512b  1440.0 MiB/s  1445.9 MiB/s
>     serpent-xts    512b   265.0 MiB/s   257.2 MiB/s
>     twofish-xts    512b   198.2 MiB/s   201.6 MiB/s
> root@fireball / #

There you go. Told ya. :)

> As you can see, aes-cbc is fast now and I think that is what cryptsetup
> uses.  It used to be really slow I think. 

Cryptsetup uses aes-xts these days, I think it’s been mentioned in this 
thread somewhere.

> Now on to the nas box.  I've recompiled the kernel with some added
> options.  Still, it refuses to speed up.  I kinda think it is the CPU
> lacking support for encryption.  I'm asking others just in case I'm
> missing something.  Also, fireball uses a older kernel, 5.14 or so.  The
> nas box uses 6.1 or so.  The menus are different and that is why it is
> hard to get them to match up.  I may have missed something.

Everything you need for that is in the crypto menu at the bottom.

> This is the bench mark from nas box. 
> 
> nas ~ # cryptsetup benchmark
> # Tests are approximate using memory only (no storage IO).
> PBKDF2-sha1   700919 iterations per second for 256-bit key
> PBKDF2-sha256 924670 iterations per second for 256-bit key
> PBKDF2-sha512 729190 iterations per second for 256-bit key
> PBKDF2-ripemd160  517559 iterations per second for 256-bit key
> PBKDF2-whirlpool  359593 iterations per second for 256-bit key
> argon2i   4 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> argon2id  4 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> # Algorithm |   Key |  Encryption |  Decryption
>     aes-cbc    128b    63.6 MiB/s    41.6 MiB/s
>     serpent-cbc    128b    81.0 MiB/s   212.4 MiB/s
>     twofish-cbc    128b   192.5 MiB/s   222.1 MiB/s
>     aes-cbc    256b    47.5 MiB/s    30.0 MiB/s
>     serpent-cbc    256b    81.2 MiB/s   212.7 MiB/s
>     twofish-cbc    256b   192.3 MiB/s   221.9 MiB/s
>     aes-xts    256b    65.9 MiB/s    41.6 MiB/s
>     serpent-xts    256b   201.7 MiB/s   205.7 MiB/s
>     twofish-xts    256b   216.2 MiB/s   214.5 MiB/s
>     aes-xts    512b    48.8 MiB/s    30.0 MiB/s
>     serpent-xts    512b   202.7 MiB/s   205.6 MiB/s
>     twofish-xts    512b   216.4 MiB/s   214.0 MiB/s
> nas ~ #
> […]
> The aes shows up on fireball.  It does not on the nas box.  Is the speed
> above as good as I can expect with this older CPU?

If not done yet, you can check whether you enabled the 64 bit versions of 
the crypto modules. They could push performance by a few more percent.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

The last chance is often the second-last, if you look close enough.


signature.asc
Description: PGP signature

Re: [gentoo-user] rsync options after backup restore. Transfer speed again.

[Michael]

On Monday, 23 October 2023 08:29:26 BST Dale wrote:

> I been working on the speed problem again.  I rebuilt the kernel on
> fireball and I think some changes made a huge change.  This is the
> results from fireball now:
> 
> 
> root@fireball / # cryptsetup benchmark
> # Tests are approximate using memory only (no storage IO).
> PBKDF2-sha1   931239 iterations per second for 256-bit key
> PBKDF2-sha2561356501 iterations per second for 256-bit key
> PBKDF2-sha512 972705 iterations per second for 256-bit key
> PBKDF2-ripemd160  648871 iterations per second for 256-bit key
> PBKDF2-whirlpool  362077 iterations per second for 256-bit key
> argon2i   5 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> argon2id  4 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> # Algorithm |   Key |  Encryption |  Decryption
> aes-cbc128b   570.8 MiB/s  2045.6 MiB/s
> serpent-cbc128b91.1 MiB/s   310.0 MiB/s
> twofish-cbc128b   198.7 MiB/s   218.9 MiB/s
> aes-cbc256b   428.8 MiB/s  1670.4 MiB/s
> serpent-cbc256b91.6 MiB/s   309.5 MiB/s
> twofish-cbc256b   199.8 MiB/s   219.2 MiB/s
> aes-xts256b  1821.2 MiB/s  1767.1 MiB/s
> serpent-xts256b   265.9 MiB/s   270.2 MiB/s
> twofish-xts256b   201.0 MiB/s   204.2 MiB/s
> aes-xts512b  1440.0 MiB/s  1445.9 MiB/s
> serpent-xts512b   265.0 MiB/s   257.2 MiB/s
> twofish-xts512b   198.2 MiB/s   201.6 MiB/s
> root@fireball / #
> 
> 
> As you can see, aes-cbc is fast now and I think that is what cryptsetup
> uses.  It used to be really slow I think. 

Yep, it was many times slower with your previous kernel.  Now it will saturate 
your 1Gbps network link, as long as the other box can take it.


> Now on to the nas box.  I've recompiled the kernel with some added
> options.  Still, it refuses to speed up.  I kinda think it is the CPU
> lacking support for encryption.  I'm asking others just in case I'm
> missing something.

No, you're not missing anything, although in a previous message you had posted 
a benchmark result for the Phenom performance being around 4 times higher than 
what you show below.  As I mentioned then, the Phenom CPU does not have AES-NI 
crypto hardware acceleration.  it is a rather old CPU.  Assuming the MoBo has 
the latest OEM firmware and you have also added microcode in your kernel 
(CONFIG_MICROCODE_AMD=y), then probably that's all it can do.  Small 
optimisations may show up between kernel releases, yet again patches to 
address CPU vulnerabilities (retpoline?) could make things a bit worse.


> Also, fireball uses a older kernel, 5.14 or so.  The
> nas box uses 6.1 or so.  The menus are different and that is why it is
> hard to get them to match up.  I may have missed something.  This is the
> bench mark from nas box. 

You can diff previous and current kernel config files to see what has changed.  
For the crypto settings you can grep for AES and for CRYPT to make sure you 
have not left out what you'd need for disk encryption.

> nas ~ # cryptsetup benchmark
> # Tests are approximate using memory only (no storage IO).
> PBKDF2-sha1   700919 iterations per second for 256-bit key
> PBKDF2-sha256 924670 iterations per second for 256-bit key
> PBKDF2-sha512 729190 iterations per second for 256-bit key
> PBKDF2-ripemd160  517559 iterations per second for 256-bit key
> PBKDF2-whirlpool  359593 iterations per second for 256-bit key
> argon2i   4 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> argon2id  4 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> # Algorithm |   Key |  Encryption |  Decryption
> aes-cbc128b63.6 MiB/s41.6 MiB/s
> serpent-cbc128b81.0 MiB/s   212.4 MiB/s
> twofish-cbc128b   192.5 MiB/s   222.1 MiB/s
> aes-cbc256b47.5 MiB/s30.0 MiB/s
> serpent-cbc256b81.2 MiB/s   212.7 MiB/s
> twofish-cbc256b   192.3 MiB/s   221.9 MiB/s
> aes-xts256b65.9 MiB/s41.6 MiB/s
> serpent-xts256b   201.7 MiB/s   205.7 MiB/s
> twofish-xts256b   216.2 MiB/s   214.5 MiB/s
> aes-xts512b48.8 MiB/s30.0 MiB/s
> serpent-xts512b   202.7 MiB/s   205.6 MiB/s
> twofish-xts512b   216.4 MiB/s   214.0 MiB/s
> nas ~ #

How does your aes-xts 30.0 MiB/s shown above compare with your previous 
benchmark result?  I'm sure it was quite higher than this.


> I seem to recall it 

Re: [gentoo-user] rsync options after backup restore. Transfer speed again.

[Dale]

Dale wrote:
>
> Second problem.  The transfer speed is back to the old slower speed. 
> I'm pretty sure I am using the same old options on both ends.  Still,
> it's back to being slow again.  Some info:
>
>
> <<< SNIP >>>
> Did I miss something?  Typo maybe?  I'm pretty sure I used copy and
> paste but still. 
>
> Thanks.
>
> Dale
>
> :-)  :-) 


I been working on the speed problem again.  I rebuilt the kernel on
fireball and I think some changes made a huge change.  This is the
results from fireball now:


root@fireball / # cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1   931239 iterations per second for 256-bit key
PBKDF2-sha256    1356501 iterations per second for 256-bit key
PBKDF2-sha512 972705 iterations per second for 256-bit key
PBKDF2-ripemd160  648871 iterations per second for 256-bit key
PBKDF2-whirlpool  362077 iterations per second for 256-bit key
argon2i   5 iterations, 1048576 memory, 4 parallel threads (CPUs)
for 256-bit key (requested 2000 ms time)
argon2id  4 iterations, 1048576 memory, 4 parallel threads (CPUs)
for 256-bit key (requested 2000 ms time)
# Algorithm |   Key |  Encryption |  Decryption
    aes-cbc    128b   570.8 MiB/s  2045.6 MiB/s
    serpent-cbc    128b    91.1 MiB/s   310.0 MiB/s
    twofish-cbc    128b   198.7 MiB/s   218.9 MiB/s
    aes-cbc    256b   428.8 MiB/s  1670.4 MiB/s
    serpent-cbc    256b    91.6 MiB/s   309.5 MiB/s
    twofish-cbc    256b   199.8 MiB/s   219.2 MiB/s
    aes-xts    256b  1821.2 MiB/s  1767.1 MiB/s
    serpent-xts    256b   265.9 MiB/s   270.2 MiB/s
    twofish-xts    256b   201.0 MiB/s   204.2 MiB/s
    aes-xts    512b  1440.0 MiB/s  1445.9 MiB/s
    serpent-xts    512b   265.0 MiB/s   257.2 MiB/s
    twofish-xts    512b   198.2 MiB/s   201.6 MiB/s
root@fireball / #


As you can see, aes-cbc is fast now and I think that is what cryptsetup
uses.  It used to be really slow I think. 

Now on to the nas box.  I've recompiled the kernel with some added
options.  Still, it refuses to speed up.  I kinda think it is the CPU
lacking support for encryption.  I'm asking others just in case I'm
missing something.  Also, fireball uses a older kernel, 5.14 or so.  The
nas box uses 6.1 or so.  The menus are different and that is why it is
hard to get them to match up.  I may have missed something.  This is the
bench mark from nas box. 


nas ~ # cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1   700919 iterations per second for 256-bit key
PBKDF2-sha256 924670 iterations per second for 256-bit key
PBKDF2-sha512 729190 iterations per second for 256-bit key
PBKDF2-ripemd160  517559 iterations per second for 256-bit key
PBKDF2-whirlpool  359593 iterations per second for 256-bit key
argon2i   4 iterations, 1048576 memory, 4 parallel threads (CPUs)
for 256-bit key (requested 2000 ms time)
argon2id  4 iterations, 1048576 memory, 4 parallel threads (CPUs)
for 256-bit key (requested 2000 ms time)
# Algorithm |   Key |  Encryption |  Decryption
    aes-cbc    128b    63.6 MiB/s    41.6 MiB/s
    serpent-cbc    128b    81.0 MiB/s   212.4 MiB/s
    twofish-cbc    128b   192.5 MiB/s   222.1 MiB/s
    aes-cbc    256b    47.5 MiB/s    30.0 MiB/s
    serpent-cbc    256b    81.2 MiB/s   212.7 MiB/s
    twofish-cbc    256b   192.3 MiB/s   221.9 MiB/s
    aes-xts    256b    65.9 MiB/s    41.6 MiB/s
    serpent-xts    256b   201.7 MiB/s   205.7 MiB/s
    twofish-xts    256b   216.2 MiB/s   214.5 MiB/s
    aes-xts    512b    48.8 MiB/s    30.0 MiB/s
    serpent-xts    512b   202.7 MiB/s   205.6 MiB/s
    twofish-xts    512b   216.4 MiB/s   214.0 MiB/s
nas ~ #


I seem to recall it being said that the old CPU in the nas box lacks the
aes instruction set.  This is a list of the CPU flags from the nas box.


nas ~ # cpuid2cpuflags
CPU_FLAGS_X86: 3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a
nas ~ #


The aes shows up on fireball.  It does not on the nas box.  Is the speed
above as good as I can expect with this older CPU?  I can include the
kernel config if needed.  If you know what driver you are looking for,
let me know what to grep for.  If not sure, I can attach the config file. 

Is this it?  Is this as fast as this old CPU can get? 

Dale

:-)  :-)