On Fri, Dec 28, 2012 at 03:23:11PM -0800, David Miller wrote:
> From: Herbert Xu
> Date: Sat, 29 Dec 2012 09:42:49 +1100
>
> > On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> >> I'm not sure how this patchset should be dealt with (should 1st patch go
> >> through different tree
From: Herbert Xu
Date: Sat, 29 Dec 2012 09:42:49 +1100
> On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
>> I'm not sure how this patchset should be dealt with (should 1st patch go
>> through different tree than 2nd and 3rd?), so therefore it's RFC.
>>
>> Second patch makes rfc3
On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> I'm not sure how this patchset should be dealt with (should 1st patch go
> through different tree than 2nd and 3rd?), so therefore it's RFC.
>
> Second patch makes rfc3686 template work with asynchronous block ciphers and
> third p
> Tcrypt does all work in module init, which can take long time and therefore
> triggers 'soft lockup' warning.
>
> Possible solutions are:
> 1. Build kernel with CONFIG_LOCKUP_DETECTOR option disabled,
> 2. Boot kernel with 'nowatchdog' argument,
> 3. Ignore warning.
>
>
>> ERROR: could not ins
Quoting Sandra Schlichting :
I think you are using wrong module argument, type= instead of mode=. Try
'modprobe tcrypt sec=2 mode=402' instead.
Thanks. I would never have thought of that =)
Now it preforms the test, but gives this interesting error:
[root@amd ~]# modprobe tcrypt sec=2 mode=4
Quoting Sandra Schlichting :
Why you want to workaround this? It's safe to ignore hmac(crc32) warning.
Because it stops from proceeding. I would have expected that
modprobe tcrypt sec=1 type=1000
would have executed all test cases.
Even if I just want to test one
[root@amd ~]# modprobe tcr
Quoting Sandra Schlichting :
Hi all,
On my Fedora 17 64bit AMD desktop computer I get this error
[root@amd ~]# uname -a
Linux amd 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
[root@amd ~]# modprobe tcrypt sec=1 type=1000
ERROR: could not insert 'tcryp
On Fri, Dec 21, 2012 at 10:04 AM, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> Add Device Tree suport to the omap-aes crypto
> driver. Currently, only support for OMAP2 and
> OMAP3 is being added but support for OMAP4 will
> be added in a subsequent patch.
>
> CC: Dmitry Kasatkin
> Signed-o
Some hardware crypto drivers register asynchronous ctr(aes), which is left
unused in IPSEC because rfc3686 template only supports synchronous block
ciphers. Some other drivers register rfc3686(ctr(aes)) to workaround this
limitation but not all.
This patch changes rfc3686 to use asynchronous block
rfc3686 in CTR module is now able of using asynchronous ctr(aes) from
aesni-intel, so rfc3686(ctr(aes)) in aesni-intel is no longer needed.
Signed-off-by: Jussi Kivilinna
---
arch/x86/crypto/aesni-intel_glue.c | 37
1 file changed, 37 deletions(-)
diff --g
IPSEC uses block ciphers asynchronous, but probes only for synchronous block
ciphers and makes ealg entries only available if synchronous block cipher is
found. So with setup, where hardware crypto driver registers asynchronous
block ciphers and software crypto module is not build, ealg is not mark
I'm not sure how this patchset should be dealt with (should 1st patch go
through different tree than 2nd and 3rd?), so therefore it's RFC.
Second patch makes rfc3686 template work with asynchronous block ciphers and
third patch changes aesni-intel to use this template. First patch fixed problem
in
12 matches
Mail list logo
