ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 21)
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users — Anything and everything ocf-linux related
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Lee N. <lee...@fr...> - 2008-03-24 19:27:29
|
This patch is for crypto/ocf/talitos for use on linux 2.6.23.
It is applied to the ocf-linux-20071215 release.
Signed-off-by: Lee Nipper <lee...@fr...>
---
crypto/ocf/talitos/talitos.c | 28 +++++++++++++++++++++++-----
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/crypto/ocf/talitos/talitos.c b/crypto/ocf/talitos/talitos.c
index b08d8e5..eaf3f30 100644
--- a/crypto/ocf/talitos/talitos.c
+++ b/crypto/ocf/talitos/talitos.c
@@ -125,6 +125,10 @@
#include <linux/platform_device.h>
#endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19)
+#include <linux/of_platform.h>
+#endif
+
#include <cryptodev.h>
#include <uio.h>
@@ -150,8 +154,13 @@ static void talitos_init_device(struct talitos_softc *sc);
static void talitos_reset_device_master(struct talitos_softc *sc);
static void talitos_reset_device(struct talitos_softc *sc);
static void talitos_errorprocessing(struct talitos_softc *sc);
+#ifdef CONFIG_PPC_MERGE
+static int talitos_probe(struct of_device *ofdev, const struct of_device_id *match);
+static int talitos_remove(struct of_device *ofdev);
+#else
static int talitos_probe(struct platform_device *pdev);
static int talitos_remove(struct platform_device *pdev);
+#endif
#ifdef CONFIG_OCF_RANDOMHARVEST
static int talitos_read_random(void *arg, u_int32_t *buf, int maxwords);
static void talitos_rng_init(struct talitos_softc *sc);
@@ -1088,6 +1097,8 @@ static int talitos_probe(struct platform_device *pdev)
struct device *device = &ofdev->dev;
struct device_node *np = ofdev->node;
const unsigned int *prop;
+ int err;
+ struct resource res;
#endif
static int num_chips = 0;
int rc;
@@ -1104,9 +1115,7 @@ static int talitos_probe(struct platform_device *pdev)
sc->sc_irq = -1;
sc->sc_cid = -1;
-#ifdef CONFIG_PPC_MERGE
- sc->sc_dev = device;
-#else
+#ifndef CONFIG_PPC_MERGE
sc->sc_dev = pdev;
#endif
sc->sc_num = num_chips++;
@@ -1122,6 +1131,7 @@ static int talitos_probe(struct platform_device *pdev)
err = of_address_to_resource(np, 0, &res);
if (err)
return -EINVAL;
+ r = &res;
sc->sc_irq = irq_of_parse_and_map(np, 0);
#else
@@ -1259,9 +1269,17 @@ out:
return -ENOMEM;
}
+#ifdef CONFIG_PPC_MERGE
+static int talitos_remove(struct of_device *ofdev)
+#else
static int talitos_remove(struct platform_device *pdev)
+#endif
{
+#ifdef CONFIG_PPC_MERGE
+ struct talitos_softc *sc = dev_get_drvdata(&ofdev->dev);
+#else
struct talitos_softc *sc = platform_get_drvdata(pdev);
+#endif
int i;
DPRINTF("%s()\n", __FUNCTION__);
@@ -1305,12 +1323,12 @@ static struct of_platform_driver talitos_driver = {
static int __init talitos_init(void)
{
- return of_platform_driver_register(&talitos_driver);
+ return of_register_platform_driver(&talitos_driver);
}
static void __exit talitos_exit(void)
{
- of_platform_driver_unregister(&talitos_driver);
+ of_unregister_platform_driver(&talitos_driver);
}
#else
/* Structure for a platform device driver */
--
1.5.4.2
|
|
From: Nipper L. <Lee...@fr...> - 2008-03-24 18:01:38
|
David, I had forgotten to do 'mknod /dev/crypto c 10 70', and so your suggestion to use the no-hw option on the Configure line actually fixed the problem. So, "no-hw" combined with "--with-cryptodev" on the config works for me. Does this make sense ? Interestingly, after I have done the 'mknod' it seems that the '-engine cryptodev' is redundant to openssl, since it performs using the crypto device without the -engine parameter. If I 'mv /dev/crypto /dev/crypto-hide', then I see the performance change since it is using software. Thanks for your help. Lee > -----Original Message----- > From: Nipper Lee > Sent: Monday, March 24, 2008 10:01 AM > To: ocf-linux-users > Subject: RE: [Ocf-linux-users] ocf-linux-20071215 and openssl > speed -engine cryptodev > > David, Thanks for the suggestion. > > Results are the same (see below). > > If cryptodev is built in, then the code which is attempting > to load libcryptdev.so is the focus. > > Lee > > / # openssl speed -evp des -engine cryptodev -elapsed invalid > engine "cryptodev" > 703:error:25066067:DSO support routines:DLFCN_LOAD:could not > load the shared lib > rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so > ): /usr/lib/engine > s/libcryptodev.so: cannot open shared object file: No such > file or directory 703:error:25070067:DSO support > routines:DSO_load:could not load the shared libra > ry:dso_lib.c:244: > 703:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > found:eng_dyn.c:450: > 703:error:2606A074:engine routines:ENGINE_by_id:no such > engine:eng_list.c:415:id =cryptodev 703:error:25066067:DSO > support routines:DLFCN_LOAD:could not load the shared lib > rary:dso_dlfcn.c:162:filename(libcryptodev.so): > libcryptodev.so: cannot open sha red object file: No such > file or directory 703:error:25070067:DSO support > routines:DSO_load:could not load the shared libra > ry:dso_lib.c:244: > 703:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > found:eng_dyn.c:450: > You have chosen to measure elapsed time instead of user CPU time. > To get the most accurate results, try to run this program > when this computer is idle. > Doing des-cbc for 3s on 16 size blocks: 1226557 des-cbc's in > 3.00s Doing des-cbc for 3s on 64 size blocks: 334717 > des-cbc's in 3.00s Doing des-cbc for 3s on 256 size blocks: > 87400 des-cbc's in 3.00s Doing des-cbc for 3s on 1024 size > blocks: 22095 des-cbc's in 3.00s Doing des-cbc for 3s on 2048 > size blocks: 11068 des-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct > 2007 built on: Mon Mar 24 09:45:54 CDT 2008 > options:bn(64,32) md2(int) rc4(ptr,char) > des(idx,risc1,16,long) aes(partial) ide > a(int) blowfish(idx) > compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS > -D_REENTRANT -DDSO_DLFCN -DH AVE_DLFCN_H -DHAVE_CRYPTODEV > -DB_ENDIAN -DOPENSSL_NO_HW -DB_ENDIAN -DTERMIO -O3 -Wall > available timing options: TIMES TIMEB HZ=100 [sysconf value] > timing function used: ftime The 'numbers' are in 1000s of > bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 > bytes 2048 bytes > des-cbc 6539.46k 7131.12k 7448.20k > 7531.72k 7545.69k > / # > > > > > -----Original Message----- > > From: David McCullough > [mailto:Dav...@se...] > > Sent: Monday, March 24, 2008 7:33 AM > > To: Nipper Lee > > Cc: ocf-linux-users > > Subject: Re: [Ocf-linux-users] ocf-linux-20071215 and openssl > > speed -engine cryptodev > > > > > > Jivin Nipper Lee lays it down ... > > > Hello, > > > > > > I'm working with the ocf-linux-20071215 release targeting > hardware > > > with talitos (FSL SEC) and attempting to get openssl to use the > > > hardware for acceleration. > > > > > > I put ocf into the Linux 2.6.23 kernel and made some > > compile fixes in > > > crypto/ocf/talitos.c to get it building. > > > (I will post patches once they are working.) > > > > > > I applied the openssl-0.9.8g.patch to openssl and > > configured openssl > > > --with cryptodev and openssl built ok. > > > > > > I've hit a snag running openssl and I need a nudge in the right > > > direction. > > > > > > When I run 'openssl speed' referencing the cryptodev engine (see > > > console output below), there's a missing engines library > > > (libcryptodev.so). > > > I'm not sure what software component should provide this library. > > > > I normally build it without HW support. I think it gets > > confused because cryptodev is built in and never loaded as a .so. > > > > Add "no-hw" to your config options and see if that helps, > > > > Cheers, > > Davidm > > > > > / # openssl speed -evp des -engine cryptodev -elapsed > > invalid engine > > > "cryptodev" > > > 708:error:25066067:DSO support routines:DLFCN_LOAD:could > > not load the > > > shared lib > > > rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so): > > > /usr/lib/engine > > > s/libcryptodev.so: cannot open shared object file: No > such file or > > > directory 708:error:25070067:DSO support > > routines:DSO_load:could not > > > load the shared libra > > > ry:dso_lib.c:244: > > > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > > > found:eng_dyn.c:450: > > > 708:error:2606A074:engine routines:ENGINE_by_id:no such > > > engine:eng_list.c:415:id =cryptodev > 708:error:25066067:DSO support > > > routines:DLFCN_LOAD:could not load the shared lib > > > rary:dso_dlfcn.c:162:filename(libcryptodev.so): libcryptodev.so: > > > cannot open sha red object file: No such file or directory > > > 708:error:25070067:DSO support routines:DSO_load:could > not load the > > > shared libra > > > ry:dso_lib.c:244: > > > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > > > found:eng_dyn.c:450: > > > You have chosen to measure elapsed time instead of user CPU time. > > > To get the most accurate results, try to run this program > when this > > > computer is idle. > > > Doing des-cbc for 3s on 16 size blocks: 1226408 des-cbc's > in 3.00s > > > Doing des-cbc for 3s on 64 size blocks: 341066 des-cbc's in 3.00s > > > Doing des-cbc for 3s on 256 size blocks: 87708 des-cbc's in 3.00s > > > Doing des-cbc for 3s on 1024 size blocks: 22085 des-cbc's > in 3.00s > > > Doing des-cbc for 3s on 2048 size blocks: 11056 des-cbc's > in 3.00s > > > OpenSSL 0.9.8g 19 Oct 2007 built on: Fri Mar 21 18:56:03 CDT 2008 > > > options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) > > > aes(partial) ide > > > a(int) blowfish(idx) > > > compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > > > -DDSO_DLFCN -DH AVE_DLFCN_H -DHAVE_CRYPTODEV -DB_ENDIAN > -DB_ENDIAN > > > -DTERMIO -O3 -Wall available timing options: TIMES TIMEB HZ=100 > > > [sysconf value] timing function used: ftime The 'numbers' > > are in 1000s > > > of bytes per second processed. > > > type 16 bytes 64 bytes 256 bytes 1024 > > bytes 2048 > > > bytes > > > des-cbc 6540.84k 7266.39k 7474.45k 7528.31k > > > 7537.51k > > > / # > > > > > > > > > ---------------------------------------------------------------------- > > > --- This SF.net email is sponsored by: Microsoft Defy all > > challenges. > > > Microsoft(R) Visual Studio 2008. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > _______________________________________________ > > > Ocf-linux-users mailing list > > > Ocf...@li... > > > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > > > > > > > -- > > David McCullough, dav...@se..., > > Ph:+61 734352815 > > Secure Computing - SnapGear http://www.uCdot.org > > http://www.cyberguard.com > > > |
|
From: Nipper L. <Lee...@fr...> - 2008-03-24 15:05:32
|
David, Thanks for the suggestion. Results are the same (see below). If cryptodev is built in, then the code which is attempting to load libcryptdev.so is the focus. Lee / # openssl speed -evp des -engine cryptodev -elapsed invalid engine "cryptodev" 703:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared lib rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so): /usr/lib/engine s/libcryptodev.so: cannot open shared object file: No such file or directory 703:error:25070067:DSO support routines:DSO_load:could not load the shared libra ry:dso_lib.c:244: 703:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 703:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:415:id =cryptodev 703:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared lib rary:dso_dlfcn.c:162:filename(libcryptodev.so): libcryptodev.so: cannot open sha red object file: No such file or directory 703:error:25070067:DSO support routines:DSO_load:could not load the shared libra ry:dso_lib.c:244: 703:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: You have chosen to measure elapsed time instead of user CPU time. To get the most accurate results, try to run this program when this computer is idle. Doing des-cbc for 3s on 16 size blocks: 1226557 des-cbc's in 3.00s Doing des-cbc for 3s on 64 size blocks: 334717 des-cbc's in 3.00s Doing des-cbc for 3s on 256 size blocks: 87400 des-cbc's in 3.00s Doing des-cbc for 3s on 1024 size blocks: 22095 des-cbc's in 3.00s Doing des-cbc for 3s on 2048 size blocks: 11068 des-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Mar 24 09:45:54 CDT 2008 options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) aes(partial) ide a(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DH AVE_DLFCN_H -DHAVE_CRYPTODEV -DB_ENDIAN -DOPENSSL_NO_HW -DB_ENDIAN -DTERMIO -O3 -Wall available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes des-cbc 6539.46k 7131.12k 7448.20k 7531.72k 7545.69k / # > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Monday, March 24, 2008 7:33 AM > To: Nipper Lee > Cc: ocf-linux-users > Subject: Re: [Ocf-linux-users] ocf-linux-20071215 and openssl > speed -engine cryptodev > > > Jivin Nipper Lee lays it down ... > > Hello, > > > > I'm working with the ocf-linux-20071215 release targeting hardware > > with talitos (FSL SEC) and attempting to get openssl to use the > > hardware for acceleration. > > > > I put ocf into the Linux 2.6.23 kernel and made some > compile fixes in > > crypto/ocf/talitos.c to get it building. > > (I will post patches once they are working.) > > > > I applied the openssl-0.9.8g.patch to openssl and > configured openssl > > --with cryptodev and openssl built ok. > > > > I've hit a snag running openssl and I need a nudge in the right > > direction. > > > > When I run 'openssl speed' referencing the cryptodev engine (see > > console output below), there's a missing engines library > > (libcryptodev.so). > > I'm not sure what software component should provide this library. > > I normally build it without HW support. I think it gets > confused because cryptodev is built in and never loaded as a .so. > > Add "no-hw" to your config options and see if that helps, > > Cheers, > Davidm > > > / # openssl speed -evp des -engine cryptodev -elapsed > invalid engine > > "cryptodev" > > 708:error:25066067:DSO support routines:DLFCN_LOAD:could > not load the > > shared lib > > rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so): > > /usr/lib/engine > > s/libcryptodev.so: cannot open shared object file: No such file or > > directory 708:error:25070067:DSO support > routines:DSO_load:could not > > load the shared libra > > ry:dso_lib.c:244: > > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > > found:eng_dyn.c:450: > > 708:error:2606A074:engine routines:ENGINE_by_id:no such > > engine:eng_list.c:415:id =cryptodev 708:error:25066067:DSO support > > routines:DLFCN_LOAD:could not load the shared lib > > rary:dso_dlfcn.c:162:filename(libcryptodev.so): libcryptodev.so: > > cannot open sha red object file: No such file or directory > > 708:error:25070067:DSO support routines:DSO_load:could not load the > > shared libra > > ry:dso_lib.c:244: > > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > > found:eng_dyn.c:450: > > You have chosen to measure elapsed time instead of user CPU time. > > To get the most accurate results, try to run this program when this > > computer is idle. > > Doing des-cbc for 3s on 16 size blocks: 1226408 des-cbc's in 3.00s > > Doing des-cbc for 3s on 64 size blocks: 341066 des-cbc's in 3.00s > > Doing des-cbc for 3s on 256 size blocks: 87708 des-cbc's in 3.00s > > Doing des-cbc for 3s on 1024 size blocks: 22085 des-cbc's in 3.00s > > Doing des-cbc for 3s on 2048 size blocks: 11056 des-cbc's in 3.00s > > OpenSSL 0.9.8g 19 Oct 2007 built on: Fri Mar 21 18:56:03 CDT 2008 > > options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) > > aes(partial) ide > > a(int) blowfish(idx) > > compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > > -DDSO_DLFCN -DH AVE_DLFCN_H -DHAVE_CRYPTODEV -DB_ENDIAN -DB_ENDIAN > > -DTERMIO -O3 -Wall available timing options: TIMES TIMEB HZ=100 > > [sysconf value] timing function used: ftime The 'numbers' > are in 1000s > > of bytes per second processed. > > type 16 bytes 64 bytes 256 bytes 1024 > bytes 2048 > > bytes > > des-cbc 6540.84k 7266.39k 7474.45k 7528.31k > > 7537.51k > > / # > > > > > ---------------------------------------------------------------------- > > --- This SF.net email is sponsored by: Microsoft Defy all > challenges. > > Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Ocf-linux-users mailing list > > Ocf...@li... > > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > > > > -- > David McCullough, dav...@se..., > Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org > http://www.cyberguard.com > |
|
From: wangkai1219 <wan...@gm...> - 2008-03-24 15:02:06
|
Thank you. But I don't know if the latest release ocf-linux-20071215 is fit for ixp400, which is the software toolkit for IXP425. And which ixp400 release matches the ocf-linux-20071215. Can anybody help me? ------------------ wangkai1219 2008-03-24 ------------------------------------------------------------- From:David McCullough Send time:2008-03-24 20:28:03 To:wangkai1219 Cc:ocf-linux-users Theme:Re: [Ocf-linux-users] how to calculate MD5 with ocf-linux-20060301 Jivin wangkai1219 lays it down ... > Dear Sir/Madam, > I'm a user of ocf-linux-20060301. > I learned how to use ocf-linux by reading the code cryptotest.c in crypto-tools-20060301. > I found that the minkeylen and maxkeylen for MD5 are 16. But I want to use MD5 without mackey, that is, not HMAC-MD5. > So could you tell me how to use ocf-linux to calculate the MD5, not md5_hmac, and without mackey. Get the latest release, I think that restriction was cleaned up sometime last year, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com --------------------------------------------------------------- Sincerely K.Wang Rm 1-509, Information Sci. & Tech. Bldg (FIT) Dept. of Computer Sci. & Tech. Tsinghua University Beijing 100084, P. R. China Tele: (+86)010-62777703 2008-03-24 |
|
From: Takashi L. <ta...@li...> - 2008-03-24 14:42:55
|
Hya, we ran into the same trouble some time ago (though using different hardware, i.e. x86 and HiFn accelerators). We (unfortunatly only partly) solved the problem by applying the hints of the README.ENGINE file included in the OpenSSL source (as the cryptodev.so engine was never built automatically). Before that the errors encountered were exactly as stated below ... In short we manually compiled the cryptodev engine according the README.ENGINE file, but 2 caveats remained (and I haven't had the time to look into it more concisely yet): We only got it to compile, load and run, with not only using --with-cryptodev but it also defining --with-cryptodev-digests (which we appearently wanted to avoid) when running ./configure. Without the second, the engine would compile and link cleanly, but OpenSSL would refuse to load the engine at runtime (error msg the same as below) ... Moreover OpenSSL refuses to load the engine (independently of stating --with-cryptodev-digests or not) in our Linux-2.4/uClibC environment :-( though again it compiles without any warnings ... Error msg again the same as below ... Well, at least sort of some help(?) ... Or probably someone around who already solved this? regards, -ta On Monday 24 March 2008 13:33:28 David McCullough wrote: > Jivin Nipper Lee lays it down ... > > > Hello, > > > > I'm working with the ocf-linux-20071215 release targeting hardware > > with talitos (FSL SEC) and attempting to get openssl to use the > > hardware for acceleration. > > > > I put ocf into the Linux 2.6.23 kernel and made some compile > > fixes in crypto/ocf/talitos.c to get it building. > > (I will post patches once they are working.) > > > > I applied the openssl-0.9.8g.patch to openssl > > and configured openssl --with cryptodev and openssl built ok. > > > > I've hit a snag running openssl and I need a nudge in the right > > direction. > > > > When I run 'openssl speed' referencing the cryptodev engine > > (see console output below), there's a missing engines library > > (libcryptodev.so). > > I'm not sure what software component should provide this library. > > I normally build it without HW support. I think it gets confused > because cryptodev is built in and never loaded as a .so. > > Add "no-hw" to your config options and see if that helps, > > Cheers, > Davidm > > > / # openssl speed -evp des -engine cryptodev -elapsed > > invalid engine "cryptodev" > > 708:error:25066067:DSO support routines:DLFCN_LOAD:could not load the > > shared lib > > rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so): > > /usr/lib/engine > > s/libcryptodev.so: cannot open shared object file: No such file or > > directory > > 708:error:25070067:DSO support routines:DSO_load:could not load the > > shared libra > > ry:dso_lib.c:244: > > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > > found:eng_dyn.c:450: > > 708:error:2606A074:engine routines:ENGINE_by_id:no such > > engine:eng_list.c:415:id > > =cryptodev > > 708:error:25066067:DSO support routines:DLFCN_LOAD:could not load the > > shared lib > > rary:dso_dlfcn.c:162:filename(libcryptodev.so): libcryptodev.so: cannot > > open sha > > red object file: No such file or directory > > 708:error:25070067:DSO support routines:DSO_load:could not load the > > shared libra > > ry:dso_lib.c:244: > > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > > found:eng_dyn.c:450: > > You have chosen to measure elapsed time instead of user CPU time. > > To get the most accurate results, try to run this > > program when this computer is idle. > > Doing des-cbc for 3s on 16 size blocks: 1226408 des-cbc's in 3.00s > > Doing des-cbc for 3s on 64 size blocks: 341066 des-cbc's in 3.00s > > Doing des-cbc for 3s on 256 size blocks: 87708 des-cbc's in 3.00s > > Doing des-cbc for 3s on 1024 size blocks: 22085 des-cbc's in 3.00s > > Doing des-cbc for 3s on 2048 size blocks: 11056 des-cbc's in 3.00s > > OpenSSL 0.9.8g 19 Oct 2007 > > built on: Fri Mar 21 18:56:03 CDT 2008 > > options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) > > aes(partial) ide > > a(int) blowfish(idx) > > compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > > -DDSO_DLFCN -DH > > AVE_DLFCN_H -DHAVE_CRYPTODEV -DB_ENDIAN -DB_ENDIAN -DTERMIO -O3 -Wall > > available timing options: TIMES TIMEB HZ=100 [sysconf value] > > timing function used: ftime > > The 'numbers' are in 1000s of bytes per second processed. > > type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 > > bytes > > des-cbc 6540.84k 7266.39k 7474.45k 7528.31k > > 7537.51k > > / # > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Ocf-linux-users mailing list > > Ocf...@li... > > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users |
|
From: David M. <Dav...@se...> - 2008-03-24 12:33:33
|
Jivin Nipper Lee lays it down ... > Hello, > > I'm working with the ocf-linux-20071215 release targeting hardware > with talitos (FSL SEC) and attempting to get openssl to use the > hardware for acceleration. > > I put ocf into the Linux 2.6.23 kernel and made some compile > fixes in crypto/ocf/talitos.c to get it building. > (I will post patches once they are working.) > > I applied the openssl-0.9.8g.patch to openssl > and configured openssl --with cryptodev and openssl built ok. > > I've hit a snag running openssl and I need a nudge in the right > direction. > > When I run 'openssl speed' referencing the cryptodev engine > (see console output below), there's a missing engines library > (libcryptodev.so). > I'm not sure what software component should provide this library. I normally build it without HW support. I think it gets confused because cryptodev is built in and never loaded as a .so. Add "no-hw" to your config options and see if that helps, Cheers, Davidm > / # openssl speed -evp des -engine cryptodev -elapsed > invalid engine "cryptodev" > 708:error:25066067:DSO support routines:DLFCN_LOAD:could not load the > shared lib > rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so): > /usr/lib/engine > s/libcryptodev.so: cannot open shared object file: No such file or > directory > 708:error:25070067:DSO support routines:DSO_load:could not load the > shared libra > ry:dso_lib.c:244: > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > found:eng_dyn.c:450: > 708:error:2606A074:engine routines:ENGINE_by_id:no such > engine:eng_list.c:415:id > =cryptodev > 708:error:25066067:DSO support routines:DLFCN_LOAD:could not load the > shared lib > rary:dso_dlfcn.c:162:filename(libcryptodev.so): libcryptodev.so: cannot > open sha > red object file: No such file or directory > 708:error:25070067:DSO support routines:DSO_load:could not load the > shared libra > ry:dso_lib.c:244: > 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not > found:eng_dyn.c:450: > You have chosen to measure elapsed time instead of user CPU time. > To get the most accurate results, try to run this > program when this computer is idle. > Doing des-cbc for 3s on 16 size blocks: 1226408 des-cbc's in 3.00s > Doing des-cbc for 3s on 64 size blocks: 341066 des-cbc's in 3.00s > Doing des-cbc for 3s on 256 size blocks: 87708 des-cbc's in 3.00s > Doing des-cbc for 3s on 1024 size blocks: 22085 des-cbc's in 3.00s > Doing des-cbc for 3s on 2048 size blocks: 11056 des-cbc's in 3.00s > OpenSSL 0.9.8g 19 Oct 2007 > built on: Fri Mar 21 18:56:03 CDT 2008 > options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) > aes(partial) ide > a(int) blowfish(idx) > compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DH > AVE_DLFCN_H -DHAVE_CRYPTODEV -DB_ENDIAN -DB_ENDIAN -DTERMIO -O3 -Wall > available timing options: TIMES TIMEB HZ=100 [sysconf value] > timing function used: ftime > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 > bytes > des-cbc 6540.84k 7266.39k 7474.45k 7528.31k > 7537.51k > / # > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2008-03-24 12:27:55
|
Jivin wangkai1219 lays it down ... > Dear Sir/Madam, > I'm a user of ocf-linux-20060301. > I learned how to use ocf-linux by reading the code cryptotest.c in crypto-tools-20060301. > I found that the minkeylen and maxkeylen for MD5 are 16. But I want to use MD5 without mackey, that is, not HMAC-MD5. > So could you tell me how to use ocf-linux to calculate the MD5, not md5_hmac, and without mackey. Get the latest release, I think that restriction was cleaned up sometime last year, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Nipper L. <Lee...@fr...> - 2008-03-22 00:46:34
|
Hello, I'm working with the ocf-linux-20071215 release targeting hardware with talitos (FSL SEC) and attempting to get openssl to use the hardware for acceleration. I put ocf into the Linux 2.6.23 kernel and made some compile fixes in crypto/ocf/talitos.c to get it building. (I will post patches once they are working.) I applied the openssl-0.9.8g.patch to openssl and configured openssl --with cryptodev and openssl built ok. I've hit a snag running openssl and I need a nudge in the right direction. When I run 'openssl speed' referencing the cryptodev engine (see console output below), there's a missing engines library (libcryptodev.so). I'm not sure what software component should provide this library. Any help is appreciated. Thanks, Lee Nipper / # openssl speed -evp des -engine cryptodev -elapsed invalid engine "cryptodev" 708:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared lib rary:dso_dlfcn.c:162:filename(/usr/lib/engines/libcryptodev.so): /usr/lib/engine s/libcryptodev.so: cannot open shared object file: No such file or directory 708:error:25070067:DSO support routines:DSO_load:could not load the shared libra ry:dso_lib.c:244: 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 708:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:415:id =cryptodev 708:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared lib rary:dso_dlfcn.c:162:filename(libcryptodev.so): libcryptodev.so: cannot open sha red object file: No such file or directory 708:error:25070067:DSO support routines:DSO_load:could not load the shared libra ry:dso_lib.c:244: 708:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: You have chosen to measure elapsed time instead of user CPU time. To get the most accurate results, try to run this program when this computer is idle. Doing des-cbc for 3s on 16 size blocks: 1226408 des-cbc's in 3.00s Doing des-cbc for 3s on 64 size blocks: 341066 des-cbc's in 3.00s Doing des-cbc for 3s on 256 size blocks: 87708 des-cbc's in 3.00s Doing des-cbc for 3s on 1024 size blocks: 22085 des-cbc's in 3.00s Doing des-cbc for 3s on 2048 size blocks: 11056 des-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Fri Mar 21 18:56:03 CDT 2008 options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) aes(partial) ide a(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DH AVE_DLFCN_H -DHAVE_CRYPTODEV -DB_ENDIAN -DB_ENDIAN -DTERMIO -O3 -Wall available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes des-cbc 6540.84k 7266.39k 7474.45k 7528.31k 7537.51k / # |
|
From: wangkai1219 <wan...@gm...> - 2008-03-21 03:40:19
|
Dear Sir/Madam,
I'm a user of ocf-linux-20060301.
I learned how to use ocf-linux by reading the code cryptotest.c in crypto-tools-20060301.
I found that the minkeylen and maxkeylen for MD5 are 16. But I want to use MD5 without mackey, that is, not HMAC-MD5.
So could you tell me how to use ocf-linux to calculate the MD5, not md5_hmac, and without mackey.
Thank you and best wishes.
---------------------------------------------------------------
Sincerely K.Wang
Rm 1-509, Information Sci. & Tech. Bldg (FIT)
Dept. of Computer Sci. & Tech.
Tsinghua University
Beijing 100084, P. R. China
Tele: (+86)010-62777703
2008-03-21
|
|
From: wangkai1219 <wan...@gm...> - 2008-03-21 03:24:15
|
Dear Sir/Madam,
I'm a user of ocf-linux-20060301.
I learned how to use ocf-linux by reading the code cryptotest.c in crypto-tools-20060301.
I found that the minkeylen and maxkeylen for MD5 are 16. But I want to use MD5 without mackey, that is, not HMAC-MD5.
So could you tell me how to use ocf-linux to calculate the MD5, not md5_hmac, and without mackey.
Thank you and best wishes.
---------------------------------------------------------------
Sincerely K.Wang
Rm 1-509, Information Sci. & Tech. Bldg (FIT)
Dept. of Computer Sci. & Tech.
Tsinghua University
Beijing 100084, P. R. China
Tele: (+86)010-62777703
2008-03-21
|
|
From: David M. <Dav...@se...> - 2008-03-20 04:53:26
|
Jivin JUN J lays it down ... > Hi, I did tests by Intel's crypto codelets stuff and have the result in the > attachment crypto_codelets_4096_Mar19th.log > > And I turned the debug on of the NPE driver and added some > ixCryptoAccShow() functions to see the status of write queue and read > queue, > It seems like the write queue(29) is full while no one is > really draining it, > which leads to the "cannot allocate memory" error. > see attachment cryptotest.log Sounds like your access library code is a little mixed up. Are you loading the corrent NPE image with crypto ? If the codelets are having problems then I would guess something is wrong in there. Cheers, Davidm > David McCullough <Dav...@se...> wrote: > Jivin JUN J lays it down ... > > > > I just subscribed and not to follow the old discussions, sorry. > > No problems. See below. > > > Platform: Intel IXP425, LinuxLink 2.6.16.11, Intel Access Library With Crypto v2.4. > > ocf-linux-20071215 software. > > > > I did: > > insmod ixp400.ko > > cat IxNpeMicrocode.dat > /dev/ixNpe > > insmod ixp400_eth.ko > > > > (ethernet works fine) > > > > Then I did: > > # insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/ocf.ko crypto_debug=1 > > > > crypto_init(0xbf1acbc8) > > crypto/ocf/crypto.c,1227:Q_LOCK() > > crypto_proc-sleeping(qe=1 qb=0 kqe=1 kqb=0) > > crypto/ocf/crypto.c,1374:Q_UNLOCK() > > crypto/ocf/crypto.c,1415:RETQ_LOCK > > crypto_ret_proc-sleeping > > crypto/ocf/crypto.c,1446: RETQ_UNLOCK > > > > > > # insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/cryptodev.ko cryptodev_debug=1 > > > > cryptodev_init(bf1b7000) > > > > # insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/ixp4xx/ixp4xx.ko ixp_debug=1 > > > > ixp_init(bf1b8270) > > crypto/ocf/crypto.c,469:DRIVER_LOCK() > > crypto/ocf/crypto.c,514:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=1, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=2, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=11, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=13, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=14, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=6, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > > crypto_register(id=0x0, alg=7, maxoplen=0, flags=0x0) > > crypto/ocf/crypto.c,619:DRIVER_LOCK() > > crypto/ocf/crypto.c,645: DRIVER_UNLOCK() > > > > > > > > At last I did: > > > > #cryptotest > > > > cryptodev_open() > > cryptodev_ioctl(cmd=c0046364 arg=bef84af4) > > cryptodev_ioctl(CRIOGET) > > cryptodev_ioctl(cmd=c030636a arg=bef84b3c) > > cryptodev_ioctl(CIOCGSESSION2) > > cryptodev_ioctl(CIOCGSESSION2) - no mac > > crypto/ocf/crypto.c,355: DRIVER_LOCK() > > crypto/ocf/crypto.c,379: DRIVER_UNLOCK() > > ixp_newsession():alg 2 > > crypto/ocf/crypto.c,381: DRIVER_LOCK() > > crypto/ocf/crypto.c,391: DRIVER_UNLOCK() > > csecreate() > > cseadd() > > cryptodev_ioctl(cmd=c01c6367 arg=bef84b20) > > cryptodev_ioctl(CIOCCRYPT) > > csefind() > > cryptodev_op() > > crypto_dispatch() > > crypto_invoke() > > ixp_process() > > cryptodev_op about to WAIT > > ixp_register_cb(999, 00000000, 0) > > ixp_process_pending(c2885000) > > ixp_q_process(c2e5a9e0) > > > > (freezed here) > > > > ___________________________________________________________________ > > > > I tracked down the source a little and found that it was waiting for the crp_flags > > to be set to CRYPTO_F_DONE around line 310 in crypto/ocf/cryptodev.c. > > And I found there's only one function: > > void crypto_done(struct cryptop *crp); > > to set crp_flags to CRYPTO_F_DONE. > > (Ctrl-c also sends signal to break out the loop but it's been disabled intently.) > > > > > > >From the debug output of ixp4xx.ko I followed the last function ixp_q_process() > > and saw it returned successfully with IX_CRYPTO_ACC_STATUS_SUCCESS == status > > (line 550 in crypto/ocf/ixp4xx/ixp4xx.c) ... > > which means crypto_done() has never been called since the request was sent to > > NPE stuff regardless of the ixCryptoAcc.... function returned successfully. > > > > I don't understand. Actually I met this situation when I was tring to integrate > > MontaVista4.01 plus NPE v2.3 and ocf-linux ... > > > > Any suggestion or hints would be appreciated, thank you very much. > > Thanks for all the detail, makes it easy for see what is happening ;-) > > It looks fairly simple, try the attached "untested" patch and see how you go. > > Somehow you have generated a request that does not call back through the > ixp_perform_cb or ixp_hash_perform_cb routines. Obviously we hadn't hit > that one before. Of course all we had to do was run cryptotest without > args, but that is obviously too hard :-) :-) > > Cheers, > Davidm > > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com > Index: ocf/ixp4xx/ixp4xx.c > =================================================================== > RCS file: ocf/ixp4xx/ixp4xx.c,v > retrieving revision 1.46 > diff -u -r1.46 ixp4xx.c > --- ocf/ixp4xx/ixp4xx.c 12 Oct 2007 01:10:31 -0000 1.46 > +++ ocf/ixp4xx/ixp4xx.c 18 Mar 2008 04:48:30 -0000 > @@ -547,16 +547,15 @@ > q->ixp_q_iv); > } > > - if (IX_CRYPTO_ACC_STATUS_SUCCESS == status) > - return; > - > if (IX_CRYPTO_ACC_STATUS_QUEUE_FULL == status) { > q->ixp_q_crp->crp_etype = ENOMEM; > goto done; > } > > - printk("ixp: %s failed %u\n", crypt_func, status); > - q->ixp_q_crp->crp_etype = EINVAL; > + if (IX_CRYPTO_ACC_STATUS_SUCCESS != status) { > + printk("ixp: %s failed %u\n", crypt_func, status); > + q->ixp_q_crp->crp_etype = EINVAL; > + } > > done: > crypto_done(q->ixp_q_crp); > > > > --------------------------------- > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: JUN J <ee...@ya...> - 2008-03-18 07:01:45
|
# cryptotest 100 4096 cryptodev_open() cryptodev_ioctl(cmd=c0046364 arg=bea66ae4) cryptodev_ioctl(CRIOGET) cryptodev_ioctl(cmd=c030636a arg=bea66b2c) cryptodev_ioctl(CIOCGSESSION2) cryptodev_ioctl(CIOCGSESSION2) - no mac crypto/ocf/crypto.c,355:DRIVER_LOCK() crypto/ocf/crypto.c,379:DRIVER_UNLOCK() ixp_newsession():alg2 crypto/ocf/crypto.c,381:DRIVER_LOCK() crypto/ocf/crypto.c,391:DRIVER_UNLOCK() csecreate() cseadd() cryptodev_ioctl(cmd=c01c6367 arg=bea66b10) cryptodev_ioctl(CIOCCRYPT) csefind() cryptodev_op() crypto_dispatch() crypto_invoke() ixp_process() cryptodev_op about to WAIT ixp_register_cb(999,00000000,0) ixp_process_pending(c3836a00) ixp_q_process(c2e249e0) crypto_done() cryptodev_cb() cryptodev_op finished WAITING error=0 cryptodev_ioctl(cmd=c01c6367 arg=bea66b10) cryptodev_ioctl(CIOCCRYPT) csefind() cryptodev_op() crypto_dispatch() crypto_invoke() ixp_process() ixp_process - detected direction change on session cryptodev_op about to WAIT ... ( repeated for many times ) ... ixp_process - detected direction change on session cryptodev_op about to WAIT ixp_register_cb(935,00000000,0) ixp_process_pending(c3836a00) ixp_q_process(c2e249e0) crypto_done() cryptodev_cb() cryptodev_op finished WAITING error=0 cryptodev_op error in crp processing cryptodev_release() cryptotest:line 392:ioctl(CIOCCRYPT):Cannot allocate memory csefree() crypto_freesession() crypto/ocf/crypto.c,416:DRIVER_LOCK() crypto/ocf/crypto.c,435:DRIVER_UNLOCK() ixp_freesession() crypto/ocf/crypto.c,438:DRIVER_LOCK() crypto/ocf/crypto.c,448:DRIVER_UNLOCK() |
|
From: David M. <Dav...@se...> - 2008-03-18 04:55:56
|
Jivin JUN J lays it down ... > > I just subscribed and not to follow the old discussions, sorry. No problems. See below. > Platform: Intel IXP425, LinuxLink 2.6.16.11, Intel Access Library With Crypto v2.4. > ocf-linux-20071215 software. > > I did: > insmod ixp400.ko > cat IxNpeMicrocode.dat > /dev/ixNpe > insmod ixp400_eth.ko > > (ethernet works fine) > > Then I did: > # insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/ocf.ko crypto_debug=1 > > crypto_init(0xbf1acbc8) > crypto/ocf/crypto.c,1227:Q_LOCK() > crypto_proc-sleeping(qe=1 qb=0 kqe=1 kqb=0) > crypto/ocf/crypto.c,1374:Q_UNLOCK() > crypto/ocf/crypto.c,1415:RETQ_LOCK > crypto_ret_proc-sleeping > crypto/ocf/crypto.c,1446: RETQ_UNLOCK > > > # insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/cryptodev.ko cryptodev_debug=1 > > cryptodev_init(bf1b7000) > > # insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/ixp4xx/ixp4xx.ko ixp_debug=1 > > ixp_init(bf1b8270) > crypto/ocf/crypto.c,469:DRIVER_LOCK() > crypto/ocf/crypto.c,514:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=1, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=2, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=11, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=13, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=14, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=6, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645:DRIVER_UNLOCK() > crypto_register(id=0x0, alg=7, maxoplen=0, flags=0x0) > crypto/ocf/crypto.c,619:DRIVER_LOCK() > crypto/ocf/crypto.c,645: DRIVER_UNLOCK() > > > > At last I did: > > #cryptotest > > cryptodev_open() > cryptodev_ioctl(cmd=c0046364 arg=bef84af4) > cryptodev_ioctl(CRIOGET) > cryptodev_ioctl(cmd=c030636a arg=bef84b3c) > cryptodev_ioctl(CIOCGSESSION2) > cryptodev_ioctl(CIOCGSESSION2) - no mac > crypto/ocf/crypto.c,355: DRIVER_LOCK() > crypto/ocf/crypto.c,379: DRIVER_UNLOCK() > ixp_newsession():alg 2 > crypto/ocf/crypto.c,381: DRIVER_LOCK() > crypto/ocf/crypto.c,391: DRIVER_UNLOCK() > csecreate() > cseadd() > cryptodev_ioctl(cmd=c01c6367 arg=bef84b20) > cryptodev_ioctl(CIOCCRYPT) > csefind() > cryptodev_op() > crypto_dispatch() > crypto_invoke() > ixp_process() > cryptodev_op about to WAIT > ixp_register_cb(999, 00000000, 0) > ixp_process_pending(c2885000) > ixp_q_process(c2e5a9e0) > > (freezed here) > > ___________________________________________________________________ > > I tracked down the source a little and found that it was waiting for the crp_flags > to be set to CRYPTO_F_DONE around line 310 in crypto/ocf/cryptodev.c. > And I found there's only one function: > void crypto_done(struct cryptop *crp); > to set crp_flags to CRYPTO_F_DONE. > (Ctrl-c also sends signal to break out the loop but it's been disabled intently.) > > > >From the debug output of ixp4xx.ko I followed the last function ixp_q_process() > and saw it returned successfully with IX_CRYPTO_ACC_STATUS_SUCCESS == status > (line 550 in crypto/ocf/ixp4xx/ixp4xx.c) ... > which means crypto_done() has never been called since the request was sent to > NPE stuff regardless of the ixCryptoAcc.... function returned successfully. > > I don't understand. Actually I met this situation when I was tring to integrate > MontaVista4.01 plus NPE v2.3 and ocf-linux ... > > Any suggestion or hints would be appreciated, thank you very much. Thanks for all the detail, makes it easy for see what is happening ;-) It looks fairly simple, try the attached "untested" patch and see how you go. Somehow you have generated a request that does not call back through the ixp_perform_cb or ixp_hash_perform_cb routines. Obviously we hadn't hit that one before. Of course all we had to do was run cryptotest without args, but that is obviously too hard :-) :-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: JUN J <ee...@ya...> - 2008-03-18 03:28:16
|
I just subscribed and not to follow the old discussions, sorry.
Platform: Intel IXP425, LinuxLink 2.6.16.11, Intel Access Library With Crypto v2.4.
ocf-linux-20071215 software.
I did:
insmod ixp400.ko
cat IxNpeMicrocode.dat > /dev/ixNpe
insmod ixp400_eth.ko
(ethernet works fine)
Then I did:
# insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/ocf.ko crypto_debug=1
crypto_init(0xbf1acbc8)
crypto/ocf/crypto.c,1227:Q_LOCK()
crypto_proc-sleeping(qe=1 qb=0 kqe=1 kqb=0)
crypto/ocf/crypto.c,1374:Q_UNLOCK()
crypto/ocf/crypto.c,1415:RETQ_LOCK
crypto_ret_proc-sleeping
crypto/ocf/crypto.c,1446: RETQ_UNLOCK
# insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/cryptodev.ko cryptodev_debug=1
cryptodev_init(bf1b7000)
# insmod /lib/modules/2.6.16.11/kernel/crypto/ocf/ixp4xx/ixp4xx.ko ixp_debug=1
ixp_init(bf1b8270)
crypto/ocf/crypto.c,469:DRIVER_LOCK()
crypto/ocf/crypto.c,514:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=1, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=2, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=11, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=13, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=14, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=6, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645:DRIVER_UNLOCK()
crypto_register(id=0x0, alg=7, maxoplen=0, flags=0x0)
crypto/ocf/crypto.c,619:DRIVER_LOCK()
crypto/ocf/crypto.c,645: DRIVER_UNLOCK()
At last I did:
#cryptotest
cryptodev_open()
cryptodev_ioctl(cmd=c0046364 arg=bef84af4)
cryptodev_ioctl(CRIOGET)
cryptodev_ioctl(cmd=c030636a arg=bef84b3c)
cryptodev_ioctl(CIOCGSESSION2)
cryptodev_ioctl(CIOCGSESSION2) - no mac
crypto/ocf/crypto.c,355: DRIVER_LOCK()
crypto/ocf/crypto.c,379: DRIVER_UNLOCK()
ixp_newsession():alg 2
crypto/ocf/crypto.c,381: DRIVER_LOCK()
crypto/ocf/crypto.c,391: DRIVER_UNLOCK()
csecreate()
cseadd()
cryptodev_ioctl(cmd=c01c6367 arg=bef84b20)
cryptodev_ioctl(CIOCCRYPT)
csefind()
cryptodev_op()
crypto_dispatch()
crypto_invoke()
ixp_process()
cryptodev_op about to WAIT
ixp_register_cb(999, 00000000, 0)
ixp_process_pending(c2885000)
ixp_q_process(c2e5a9e0)
(freezed here)
___________________________________________________________________
I tracked down the source a little and found that it was waiting for the crp_flags
to be set to CRYPTO_F_DONE around line 310 in crypto/ocf/cryptodev.c.
And I found there's only one function:
void crypto_done(struct cryptop *crp);
to set crp_flags to CRYPTO_F_DONE.
(Ctrl-c also sends signal to break out the loop but it's been disabled intently.)
>From the debug output of ixp4xx.ko I followed the last function ixp_q_process()
and saw it returned successfully with IX_CRYPTO_ACC_STATUS_SUCCESS == status
(line 550 in crypto/ocf/ixp4xx/ixp4xx.c) ...
which means crypto_done() has never been called since the request was sent to
NPE stuff regardless of the ixCryptoAcc.... function returned successfully.
I don't understand. Actually I met this situation when I was tring to integrate
MontaVista4.01 plus NPE v2.3 and ocf-linux ...
Any suggestion or hints would be appreciated, thank you very much.
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search. |
|
From: Egor N. M. <eg...@pa...> - 2008-02-28 01:47:01
|
David, I'm using openswan 2.4.11 with OCF patch to establish an IPSec tunnel. I noticed that under heavy load packets were disappearing from the tunnel. That is they were reported as received by the virtual ipsec interface, but not sent out by the ethernet interface. The dropped count and error count was zero as well. After some investigation I found that this occured when the ipsec_rsm() called ipsec_rcv_auth_calc() which called ipsec_ocf_rcv() and which finally called crypto_dispatch(). In my case crypto_dispatch() failed with ENOMEM because the crypto queue was full, and ipsec_ocf_rcv returned IPSEC_RCV_REALLYBAD. However, when that happens ipsec_rsm doesn't count this packet as dropped or as an error. -- Egor N. Martovetsky |
|
From: David M. <Dav...@se...> - 2008-01-24 05:34:02
|
Jivin "Adam Cécile (Le_Vert)" lays it down ... > Hi, > > I just got geode-aes.c, geode-aes.h and geode-rng.c from Linux GIT and > rebuild the two kmod. > Still the same issue. Sorry for the slow reply. I wasn't aware of any issues here. Just to be sure, which OCF release are you using ? I do have a geode board floating around here somewhere so I will try and give it a go soon, Thanks, Davidm > Albert Lash a écrit : > > Hi Adam, > > > > This might contain a fix that works submitted by Mello: > > > > http://www.docunext.com/blog/2007/09/25/geode-aes-ocf-cryptodev-openssl/ > > > > I haven't tried it out yet but I will within a week or two. > > > > Albert > > > > On Jan 20, 2008 9:31 AM, "Adam Cécile (Le_Vert)" <ga...@le...> wrote: > > > >> Hello, > >> > >> I just set up Debian Lenny on a PCEngines ALIX. This board have a > >> GeodeLX processor with hardware crypto accelerator, so I patched my > >> kernel to get cryptodev support. > >> Everything is fine when playin with openssl, but openssh just crash when > >> a large amount of data is transfered. > >> > >> A small example: > >> alix:~# scp 100meg.test localhost:/dev/null > >> root@localhost's password: > >> 100meg.test > >> 0% 0 0.0KB/s --:-- ETAReceived disconnect from 127.0.0.1: 2: > >> Corrupted MAC on input. > >> lost connection > >> alix:~# > >> > >> If I unload cryptodev kernel modules, averything works fine again. > >> > >> I found theses guys who reported the same issue: > >> http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF#The_Results > >> http://sourceforge.net/mailarchive/forum.php?thread_name=6250b1390709260752k291cf279h1707ad0b382270bd%40mail.gmail.com&forum_name=ocf-linux-users > >> > >> Tested with OpenSSH 4.6p1 and 4.7p1. > >> > >> Any help would be appreciated. > >> > >> Best regards, Adam. > >> > >> PS: If you don't know at all what's wrong, could you please tell me how > >> to disable cryptodev in sshd (without rebuilding the package wihout > >> --with-ssl-engine) ? > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Ocf-linux-users mailing list > >> Ocf...@li... > >> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > >> > >> > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From:
<ga...@le...> - 2008-01-20 21:10:17
|
Hi, I just got geode-aes.c, geode-aes.h and geode-rng.c from Linux GIT and=20 rebuild the two kmod. Still the same issue. Albert Lash a =E9crit : > Hi Adam, > > This might contain a fix that works submitted by Mello: > > http://www.docunext.com/blog/2007/09/25/geode-aes-ocf-cryptodev-openssl= / > > I haven't tried it out yet but I will within a week or two. > > Albert > > On Jan 20, 2008 9:31 AM, "Adam C=E9cile (Le_Vert)" <ga...@le...= > wrote: > =20 >> Hello, >> >> I just set up Debian Lenny on a PCEngines ALIX. This board have a >> GeodeLX processor with hardware crypto accelerator, so I patched my >> kernel to get cryptodev support. >> Everything is fine when playin with openssl, but openssh just crash wh= en >> a large amount of data is transfered. >> >> A small example: >> alix:~# scp 100meg.test localhost:/dev/null >> root@localhost's password: >> 100meg.test >> 0% 0 0.0KB/s --:-- ETAReceived disconnect from 127.0.0.1: 2: >> Corrupted MAC on input. >> lost connection >> alix:~# >> >> If I unload cryptodev kernel modules, averything works fine again. >> >> I found theses guys who reported the same issue: >> http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF#The_= Results >> http://sourceforge.net/mailarchive/forum.php?thread_name=3D6250b139070= 9260752k291cf279h1707ad0b382270bd%40mail.gmail.com&forum_name=3Docf-linux= -users >> >> Tested with OpenSSH 4.6p1 and 4.7p1. >> >> Any help would be appreciated. >> >> Best regards, Adam. >> >> PS: If you don't know at all what's wrong, could you please tell me ho= w >> to disable cryptodev in sshd (without rebuilding the package wihout >> --with-ssl-engine) ? >> >> ----------------------------------------------------------------------= --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Ocf-linux-users mailing list >> Ocf...@li... >> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users >> >> =20 > > > > =20 |
|
From: Albert L. <alb...@gm...> - 2008-01-20 15:06:33
|
Hi Adam, This might contain a fix that works submitted by Mello: http://www.docunext.com/blog/2007/09/25/geode-aes-ocf-cryptodev-openssl/ I haven't tried it out yet but I will within a week or two. Albert On Jan 20, 2008 9:31 AM, "Adam C=E9cile (Le_Vert)" <ga...@le...> wr= ote: > Hello, > > I just set up Debian Lenny on a PCEngines ALIX. This board have a > GeodeLX processor with hardware crypto accelerator, so I patched my > kernel to get cryptodev support. > Everything is fine when playin with openssl, but openssh just crash when > a large amount of data is transfered. > > A small example: > alix:~# scp 100meg.test localhost:/dev/null > root@localhost's password: > 100meg.test > 0% 0 0.0KB/s --:-- ETAReceived disconnect from 127.0.0.1: 2: > Corrupted MAC on input. > lost connection > alix:~# > > If I unload cryptodev kernel modules, averything works fine again. > > I found theses guys who reported the same issue: > http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF#The_Res= ults > http://sourceforge.net/mailarchive/forum.php?thread_name=3D6250b139070926= 0752k291cf279h1707ad0b382270bd%40mail.gmail.com&forum_name=3Docf-linux-user= s > > Tested with OpenSSH 4.6p1 and 4.7p1. > > Any help would be appreciated. > > Best regards, Adam. > > PS: If you don't know at all what's wrong, could you please tell me how > to disable cryptodev in sshd (without rebuilding the package wihout > --with-ssl-engine) ? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > --=20 My Blogs: http://www.docunext.com/ http://www.albertlash.com/ |
|
From:
<ga...@le...> - 2008-01-20 14:31:04
|
Hello, I just set up Debian Lenny on a PCEngines ALIX. This board have a GeodeLX processor with hardware crypto accelerator, so I patched my kernel to get cryptodev support. Everything is fine when playin with openssl, but openssh just crash when a large amount of data is transfered. A small example: alix:~# scp 100meg.test localhost:/dev/null root@localhost's password: 100meg.test 0% 0 0.0KB/s --:-- ETAReceived disconnect from 127.0.0.1: 2: Corrupted MAC on input. lost connection alix:~# If I unload cryptodev kernel modules, averything works fine again. I found theses guys who reported the same issue: http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF#The_Results http://sourceforge.net/mailarchive/forum.php?thread_name=6250b1390709260752k291cf279h1707ad0b382270bd%40mail.gmail.com&forum_name=ocf-linux-users Tested with OpenSSH 4.6p1 and 4.7p1. Any help would be appreciated. Best regards, Adam. PS: If you don't know at all what's wrong, could you please tell me how to disable cryptodev in sshd (without rebuilding the package wihout --with-ssl-engine) ? |
|
From: RB <ao...@gm...> - 2008-01-14 05:16:26
|
Meh. I was kind of hoping to not buy a 4-year-old crypto chip on a 33MHz bus, but I may have to satisfy myself with a 1401 until the manufacturers move forward. I'm not really looking for the "SSL Accelerators" that server vendors want to sell you for $10k a pop - those don't do much good for what I want and aren't really available to Joe Public, which is kind of the common denominator I look for when getting involved in hardware. Cheap, cheerful, and accesible. Soekris has spoiled us with cheap crypto cards, I just hope they (or someone) continue the trend. |
|
From: Sam S. <sam...@sa...> - 2008-01-14 01:09:02
|
> -----Original Message----- > From: ocf...@li... [mailto:ocf-linux-users- > bo...@li...] On Behalf Of RB > Sent: Sunday, January 13, 2008 7:12 PM > To: ocf...@li... > Subject: [Ocf-linux-users] Hardware > > Does anyone have a line on decent accelerators based on recent chips > one can acquire in an add-on (PCI, etc) package? I'm having a hard > time getting anyone (Soekris/GTGI) to respond to sales queries on > products they advertise with the HiFN 7956, and the SafeXcel and Intel > chips seem fully focused on the embedded market. > > Is anyone else on this list not actively working for a company > integrating crypto accelerators into their products and actually just > interested in accelerated cryptography? > Hi RB, If you have the money, and we are talking Thousands to Tens of Thousands of US Dollars, the SafeXL and other cards are available for purchase. Note that this information IS NOT available online. You need to call the companies directly to arrange a sale - crypto accelerators are marketed as high end items and not marketed towards the (pro)consumer market. I use several Soekris 1401 cards (one in the stress client and one in the server) to reduce overall cpu use (and thus let me model more connections per second) during SSL load tests at consumer internet speeds. Here is the url to Safenet that will lead you contact information for Hifn based cards: http://www.safenet-inc.com/products/accCards/index.asp I suspect some more research would turn up Intel Xscale based combo nic/acceleration cards that are market ready. Note that depending on your need and budget, Dell, HP, IBM, Broadcom, ncircle, etc. provide various solutions that are fully supported in Linux but are not (afaik) supported via OCF. HTH, Sam S. |
|
From: David M. <Dav...@se...> - 2008-01-14 00:32:50
|
Jivin RB lays it down ... > Does anyone have a line on decent accelerators based on recent chips > one can acquire in an add-on (PCI, etc) package? I'm having a hard > time getting anyone (Soekris/GTGI) to respond to sales queries on > products they advertise with the HiFN 7956, and the SafeXcel and Intel > chips seem fully focused on the embedded market. > > Is anyone else on this list not actively working for a company > integrating crypto accelerators into their products and actually just > interested in accelerated cryptography? You should be able to purchase a HIFN PCI card with the 7956 on it. They may be referred to a reference boards. Have a look here for some other products that may help: http://resin.csoft.net/cgi-bin/man.cgi?section=4&topic=hifn Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: RB <ao...@gm...> - 2008-01-14 00:12:09
|
Does anyone have a line on decent accelerators based on recent chips one can acquire in an add-on (PCI, etc) package? I'm having a hard time getting anyone (Soekris/GTGI) to respond to sales queries on products they advertise with the HiFN 7956, and the SafeXcel and Intel chips seem fully focused on the embedded market. Is anyone else on this list not actively working for a company integrating crypto accelerators into their products and actually just interested in accelerated cryptography? |
|
From: David M. <Dav...@se...> - 2008-01-10 04:02:08
|
Jivin wan...@to... lays it down ...
>
> Hello!
>
> I think it is about New Year when you read this email, so I say happy
> New Year to you.
>
> I got a problem when I used ocf-bench to test my ixp425 system.
>
> I compiled mvl30+ixp425software withcrypto V1_5+ocf20050630+openswan2.3.0
> and patches which download from Intel.
Thats a pretty old version you have there :-)
Perhaps you should try something newer.
Also, ocf-bench is a very simple and not well tested app for checking
the overhead that OCF adds to the crypto processing. It is included in
the ocf releases in case someone finds it useful as a reference, it is
not meant to be stable to to be able to be run many times. If it runs
once then it has done it's job ;-)
That said, if you figure it out I am happy to accept patches :-)
> I compiled ocf-bench.c as a module:ocf-bench.o, and I insmod it to test. At
> first about 20 times, it works good.
>
> For details:
>
> # insmod ocf-bench.o request_q_len=200 request_num=1024 request_size=1500
>
> Using ocf-bench.o Crypto Speed tests
>
> OCF: testing ...
>
> OCF: 1224 requests of 1500 bytes in 2 jiffies
>
> IXP: testing ...
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> status1 = 4
>
> IXP: 1213 requests of 1500 bytes in 15 jiffies
>
> insmod: init_module: ocf-bench: Invalid argument
>
>
> >From the test I see that ocf work faster than without ocf when request_q_len
> is bigger than 65.
That same goes for most HW crypto.
> But, later, I got a problem. Ocf-bench can not run test.
>
> For details:
>
> # insmod ocf-bench.o
>
> Using ocf-bench.o
>
> Crypto Speed tests
>
> OCF: testing ...
>
> OCF: 1044 requests of 1500 bytes in 24 jiffies
>
> rateRatio is about 6Mbit/sec
>
> IXP: testing ...
>
> Ocf-bench stopped here. See the code of ocf-bench.c.
Who knows.
> First Ocfbench_init() run ocf test (this is good), then it run ixp test.
>
> Ocfbench_init() invoke ixp_init()
>
> There are some codes of ixp_init():
>
>
>
> status = ixCryptoAccCtxRegister(&ixp_ctx, &ixp_pri, &ixp_sec,
>
> ixp_register_cb, ixp_perform_cb, &ixp_ctx_id);
>
>
>
> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status) {
>
> while (!ixp_registered)
>
> schedule();
>
> return ixp_registered < 0 ? -1 : 0;
>
> }
>
> ixp_registered is 0, so it stopped here.
>
> But why? See some codes of ixp_register_cb():
>
> ixp_register_cb (UINT32 ctx_id, IX_MBUF *bufp, IxCryptoAccStatus status)
>
> {
>
> if (bufp) {
>
> IX_MBUF_MLEN(bufp) = IX_MBUF_PKT_LEN(bufp) = 0;
>
> kfree(IX_MBUF_MDATA(bufp));
>
> IX_MBUF_MDATA(bufp) = NULL;
>
> }
>
>
>
> if (IX_CRYPTO_ACC_STATUS_WAIT == status)
>
> return;
>
> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
>
> ixp_registered = 1;
>
> else
>
> ixp_registered = -1;
>
> }
>
>
>
> I print the status, it is 2 here, == IX_CRYPTO_ACC_STATUS_WAIT, so it can
> not change ixp_registered from 0 to 1 or -1.
>
> Why ocf-bench can work good at first about 20 times, but can not work later?
Sounds like the access library has got upset, it could be due to bugs
in ocf-bench, can't really tell and I am not inclined to go looking.
> I have changed nothing. you can see that ocf test work good, and if only run
> ixp test it is good too.
>
> have you seen something like this? Please help me! I want to know what is
> wrong, and how to let ocf-bench work good.
You would need to make sure the ixp4xx driver does everything correctly
and it close/freeing everything properly etc.
It might be a good idea to try out the latest OCF release and see how
that goes.
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
|
|
From: Nawang C. <naw...@gm...> - 2008-01-02 03:53:05
|
Hi Sam,
I had similar problem with 2.6.22 ubuntu, VOLUNTARY
PREEMPTION on. The machine hangs. It works fine if VOLUNTARY PREEMPTION is
disabled.
On Dec 29, 2007 5:18 PM, Sam Stern <sam...@sa...> wrote:
> Hi All,
>
> I just found this project and am preparing my test system. The system uses
> kernel 2.6.22 (Ubuntu 7.10) and it's default is Preemption = Voluntary
> (It's
> a Soho multi use system). What issues will this kernel setting cause with
> ocf. I am using a Soekris VPN1401 which is little more than a reference
> implementation of a HiFn 7955, Rev0, 32k dram ?
>
> TIA
>
> Sam Stern
> Buffalo, New York, USA
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
--
Nawang Chhetan
Software Engineer
SafeNet India.
|
4 messages has been excluded from this view by a project administrator.
