On Mon, Jun 09, 2014 at 10:37:21PM +0200, wessels wrote:
> Otto thanks for the warning. Any details about why it was disabled? Anyhow
> tomorrow I'll begin further testing but things do look good.
>
> Many thanks all. I was a bit afraid that I hit nasty bug but not sofar.
Almost all of the the t
Otto thanks for the warning. Any details about why it was disabled? Anyhow
tomorrow I'll begin further testing but things do look good.
Many thanks all. I was a bit afraid that I hit nasty bug but not sofar.
Kind regards,
Wessels
On Mon, Jun 9, 2014 at 10:21 PM, Otto Moerbeek wrote:
> On Mon
On Mon, Jun 09, 2014 at 10:11:08PM +0200, wessels wrote:
> Thanks Sime,
>
> yes setting kern.usercrypto=1 did the trick. Apparently in OpenBSD 4.4 that
> was enabled by default and this was changed in a later release.
>
> # sysctl kern.usercrypto=1
> kern.usercrypto: 0 -> 1
> # openssl speed -ev
Thanks Sime,
yes setting kern.usercrypto=1 did the trick. Apparently in OpenBSD 4.4 that
was enabled by default and this was changed in a later release.
# sysctl kern.usercrypto=1
kern.usercrypto: 0 -> 1
# openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
Doing aes-128-cbc
On Mon, 9 Jun 2014 21:40:16 +0200, wessels wrote:
> Suggestions how to get this (acceleration) working again? Should it be
> invoked differently?
Is `sysctl kern.usercrypto` enabled?
Several systems need a newer version of OpenBSD. Systems are Alix 2d with
an AMD Geode, a bit dated but it works.
Current systems run OpenBSD 4.4 and the hardware acceleration via glxsb
works perfectly:
# openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
To get the most accur
6 matches
Mail list logo