ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 22)
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: David M. <Dav...@se...> - 2007-12-31 04:05:15
|
Jivin Sam Stern lays it down ... > 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 ? I have had several reports of crashes using preemption on 2.6 with OCF. IIRC most of those are from cryptosoft users, but I am not 100% sure, I haven't had a chance to debug it yet. Hopefully something I can try when I am back in the office. I have used OCF and a hifn PCI card on a Soekris net4801 board without any problems, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Sam S. <sam...@sa...> - 2007-12-29 12:03:14
|
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 |
|
From: David M. <Dav...@se...> - 2007-12-28 09:15:54
|
Jivin Tomasz Rostanski lays it down ... ... > >I should have a new version out today (famous last words). It might be > >good to try it out and see if there has been any improvements. Quite a > >lot of potential locking/sleeping and other bus have been fixed and you > >may be just hitting one of those. > > I have used the latest version but got the same. However I have finally > found out what causes the freezes for me. It's something in ixp400_eth > driver. When I use the driver in version 1.4 with ixp400 access lib 2.4 > the crypto works. When I use driver in version 1.6 or 1.7 it freezes. I > also made a test and use ixp400_eth 1.6 with ixp400 access lib 2.0 and > get the freeze (1.4 works perfect). > So it seems that the problem is being caused by something in ixp400_eth > driver. > Unfortunately the number of changes between 1.4 and 1.6 is huge and I > don't have the driver in version 1.5 to check it so it will be difficult > to find out what causes problem :( As soon as I track it down I let you > know what was wrong. Hmm, at least it's a start. Sorry I took so long to reply, I was on leave since the release went out (Good timing I know ;-) Let us know how you go, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Tomasz R. <tro...@pr...> - 2007-12-28 08:27:39
|
Hi David, David McCullough wrote: > Jivin Tomasz Rostanski lays it down ... >> David, >> >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>> >>>>> Jivin Tomasz Rostanski lays it down ... >>>>>> Hi David, >>>>>>> Jivin Tomasz Rostanski lays it down ... >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Do you made any progress? >>>>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>>>> works fine (although throughput seems to be down). >>>>>>> >>>>>>> The driver is at least processing requests ok. >>>>>>> >>>>>>> Are you installing the correct NPE code with something like: >>>>>>> >>>>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>>>> I have NPE code compiled in. I have also made a build without compiling >>>>>> it in, the result was the same. >>>>> We have an updated patch for CSR-2.4 at: >>>>> >>>>> http://www.snapgear.org/snapgear/downloads.html >>>>> >>>>> might be something in there that helps you. I am effectively running SG >>>>> Linux 3.5 on my IXP425's with that access lib patch applied, >>>> I have imported this patch (not everything I need) to our trunk and >>>> checked with the OCF 20070727 and... is working! >>>> Thank you for your help. >>> No problems, glad it worked ;-) >> But now I have a problems with openssh. >> >> When I run first "openssl speed -evp des -elapsed -engine cryptodev" >> >> I got: >> >> # ssh 192.168.0.10 >> [ 151.390000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.400000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.410000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.420000] ixp_freesession() >> [ 151.440000] ixp_newsession() >> [ 151.440000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.450000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.460000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.480000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.490000] ixp_freesession() >> The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. >> RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. >> Are you sure you want to continue connecting (yes/no)? yes >> Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. >> [ 153.270000] ixp_newsession() >> [ 153.270000] ixp_newsession() >> [ 153.280000] ixp_process() >> [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) >> [ 153.280000] ixp_process_pending(c3575400) >> [ 153.290000] ixp_process_pending in while >> [ 153.290000] ixp_q_process(c28949e0) >> evp_crypt: EVP_Cipher failed >> [ 153.300000] ixp_freesession() >> [ 153.300000] ixp_freesession() >> >> but when I run ssh without running openssl speed before I got the freeze >> in ixp_q_process. >> >> Do you use some patch for ssh too? I found some patches which adds some >> openssl engine initialization to ssh but it won't helped. > > Sorry I took so long to get back to you on this. > > I have just gone through the above sequences here and ssh works fine for > me in both cases. I am not getting the "evp_crypt: EVP_Cipher failed" > error either. I tried both into my ixp and out of the ixp board. > > Which versions of openssl/openssh are you using ? Not that it should > really matter. I am running with CSR 2.4 and 0.9.8g (I've updated) and > ssh 4.7p1, probably also updated, but no patches are needed for ssh > IIRC. > > I don't see any ixp_perform_cb, to me this says the ixp crypto is not > happy still. Does the "openssl speed" test give you numbers comparable > to that on the ocf-linux web page benchmarks section ? If not it sounds > like the crypto is just not working, which comes back to the correct > NPE code or the call to ixCryptoAccInit failing. Perhaps add some debug > to that code to make sure he crypto engine is started correctly. Look > for a kernel message: > > ixCryptoAccInit failed, assuming already initialised! > > when loading the ixp4xx driver, if you get that investigate further ;-) > > I should have a new version out today (famous last words). It might be > good to try it out and see if there has been any improvements. Quite a > lot of potential locking/sleeping and other bus have been fixed and you > may be just hitting one of those. I have used the latest version but got the same. However I have finally found out what causes the freezes for me. It's something in ixp400_eth driver. When I use the driver in version 1.4 with ixp400 access lib 2.4 the crypto works. When I use driver in version 1.6 or 1.7 it freezes. I also made a test and use ixp400_eth 1.6 with ixp400 access lib 2.0 and get the freeze (1.4 works perfect). So it seems that the problem is being caused by something in ixp400_eth driver. Unfortunately the number of changes between 1.4 and 1.6 is huge and I don't have the driver in version 1.5 to check it so it will be difficult to find out what causes problem :( As soon as I track it down I let you know what was wrong. Regards, Tomasz |
|
From: Tomasz R. <tro...@pr...> - 2007-12-17 09:40:53
|
Hi David, David McCullough pisze: > Jivin Tomasz Rostanski lays it down ... >> David, >> >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>> >>>>> Jivin Tomasz Rostanski lays it down ... >>>>>> Hi David, >>>>>>> Jivin Tomasz Rostanski lays it down ... >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Do you made any progress? >>>>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>>>> works fine (although throughput seems to be down). >>>>>>> >>>>>>> The driver is at least processing requests ok. >>>>>>> >>>>>>> Are you installing the correct NPE code with something like: >>>>>>> >>>>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>>>> I have NPE code compiled in. I have also made a build without compiling >>>>>> it in, the result was the same. >>>>> We have an updated patch for CSR-2.4 at: >>>>> >>>>> http://www.snapgear.org/snapgear/downloads.html >>>>> >>>>> might be something in there that helps you. I am effectively running SG >>>>> Linux 3.5 on my IXP425's with that access lib patch applied, >>>> I have imported this patch (not everything I need) to our trunk and >>>> checked with the OCF 20070727 and... is working! >>>> Thank you for your help. >>> No problems, glad it worked ;-) >> But now I have a problems with openssh. >> >> When I run first "openssl speed -evp des -elapsed -engine cryptodev" >> >> I got: >> >> # ssh 192.168.0.10 >> [ 151.390000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.400000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.410000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.420000] ixp_freesession() >> [ 151.440000] ixp_newsession() >> [ 151.440000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.450000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.460000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.480000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.490000] ixp_freesession() >> The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. >> RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. >> Are you sure you want to continue connecting (yes/no)? yes >> Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. >> [ 153.270000] ixp_newsession() >> [ 153.270000] ixp_newsession() >> [ 153.280000] ixp_process() >> [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) >> [ 153.280000] ixp_process_pending(c3575400) >> [ 153.290000] ixp_process_pending in while >> [ 153.290000] ixp_q_process(c28949e0) >> evp_crypt: EVP_Cipher failed >> [ 153.300000] ixp_freesession() >> [ 153.300000] ixp_freesession() >> >> but when I run ssh without running openssl speed before I got the freeze >> in ixp_q_process. >> >> Do you use some patch for ssh too? I found some patches which adds some >> openssl engine initialization to ssh but it won't helped. > > Sorry I took so long to get back to you on this. > > I have just gone through the above sequences here and ssh works fine for > me in both cases. I am not getting the "evp_crypt: EVP_Cipher failed" > error either. I tried both into my ixp and out of the ixp board. > > Which versions of openssl/openssh are you using ? Not that it should > really matter. I am running with CSR 2.4 and 0.9.8g (I've updated) and > ssh 4.7p1, probably also updated, but no patches are needed for ssh > IIRC. > > I don't see any ixp_perform_cb, to me this says the ixp crypto is not > happy still. Does the "openssl speed" test give you numbers comparable > to that on the ocf-linux web page benchmarks section ? If not it sounds > like the crypto is just not working, which comes back to the correct > NPE code or the call to ixCryptoAccInit failing. Perhaps add some debug > to that code to make sure he crypto engine is started correctly. Look > for a kernel message: > > ixCryptoAccInit failed, assuming already initialised! > > when loading the ixp4xx driver, if you get that investigate further ;-) > > I should have a new version out today (famous last words). It might be > good to try it out and see if there has been any improvements. Quite a > lot of potential locking/sleeping and other bus have been fixed and you > may be just hitting one of those. I gave a try and... the openssl speed hangs. The cryptodev stays forever in do {...} while ((crp->crp_flags & CRYPTO_F_DONE) == 0) loop. The ixp driver ends ixp_proces_pending but never call crypto_done() function (with ixp->ixp_q having only one element). The initialization of crypto engine seems to be ok. Tomasz |
|
From: David M. <Dav...@se...> - 2007-12-15 12:35:29
|
Hi all,
A new release of the ocf-linux package is up (20071215):
http://ocf-linux.sourceforge.net/
Most of the fallout from the last release which included some
significant API changes has been cleaned up. The notable updates are:
* New PA Semi driver
* Talitos driver fully updated
* various locking bugs fixed
* other cleanups
* openssl-0.9.8g patch
* openswan-2.4.11 patch
* linux-2.6.23 support
Tested under 2.4.35 and 2.6.23 across multiple architectures.
Also, join up the mailing list if you are interested/working on this:
http://lists.sourceforge.net/mailman/listinfo/ocf-linux-users
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
|
|
From: David M. <Dav...@se...> - 2007-12-14 03:34:32
|
Jivin wan...@to... lays it down ...
>
> Hi!
>
> I compiled ocf20050630 with mvl30 and ixp400lib(with crypto) for two
> months.
>
> Now I get a problem that Warning: .space repeat count is zero, ignored.
>
> Last time ocf041201 was compiled and worked good with ixp400lib V1.4 and
> mvl30. Because I want to use openswan on my system, so I choice ocf20050630.
You should be able to use the 2007 release. The 2005 release is pretty
old now :-)
> My linux system:Mvl30 with ixp425lsp
>
> Patch:
>
> ixp400linuxintegrationpatch-1.1.patch
>
> ixp400linuxethernerdriverpatch-1.1.patch
>
> copy crypto/ from standard linux-2.4.26 (I have tested that crypto work
> good)
>
> add ocf20041201 is good
>
> but add ocf20050630 get warning
>
> standard input}: Assembler messages:
>
> {standard input}:5172: Warning: .space repeat count is zero, ignored
>
> {standard input}:5175: Warning: .space repeat count is zero, ignored
>
> {standard input}:5178: Warning: .space repeat count is zero, ignored
I have no idea what may be causing this. It looks like a mis-match from
the assembler and the compiler versions. Have you changed toolchains or
something ?
> For details:
>
>
>
> make[1]: Entering directory `/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.
> 18/crypto'
>
> make -C ocf modules
>
> make[2]: Entering directory `/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.
> 18/crypto/ocf'
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=crypto -DEXPORT_SYMTAB -c crypto.c
>
> {standard input}: Assembler messages:
>
> {standard input}:5172: Warning: .space repeat count is zero, ignored
>
> {standard input}:5175: Warning: .space repeat count is zero, ignored
>
> {standard input}:5178: Warning: .space repeat count is zero, ignored
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=criov -DEXPORT_SYMTAB -c criov.c
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=random -DEXPORT_SYMTAB -c random.c
>
> {standard input}: Assembler messages:
>
> {standard input}:821: Warning: .space repeat count is zero, ignored
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=rndtest -c -o rndtest.o rndtest.c
>
> /workspace/tosenv/arm/bin/arm-linux-ld -EB -r -o ocf.o crypto.o criov.o
> random.o rndtest.o
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=cryptodev -c -o cryptodev.o cryptodev.c
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=cryptosoft -c -o cryptosoft.o cryptosoft.c
>
> /workspace/tosenv/arm/bin/arm-linux-gcc -mbig-endian -D__KERNEL__
> -I/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -Os -mapcs -mno-sched-prolog
> -fno-strict-aliasing -fno-common -fno-common -pipe -g -mapcs-32
> -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -mshort-load-bytes
> -msoft-float -DMODULE -DFIPS_TEST_RNG -I./.
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/include
> -I/usr/local/arm/ixp425/mioo-vpn/ixp400_xscale_sw/src/linux
> -DKBUILD_BASENAME=ixp4xx -I/.
> -I/modules/ixp425/ixp400-1.4/ixp400_xscale_sw/src/include
> -I/modules/ixp425/ixp400-1.4/ixp400_xscale_sw/src/linux -DUSE_IXP4XX_CRYPTO
> -D__ixp42X -c -o ixp4xx/ixp4xx.o ixp4xx/ixp4xx.c
>
> ixp4xx/ixp4xx.c: In function `ixp_register_cb':
>
> ixp4xx/ixp4xx.c:471: warning: `ixp' might be used uninitialized in this
> function
>
> make[2]: Leaving directory
> `/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/crypto/ocf'
>
> make[1]: Leaving directory
> `/usr/local/arm/ixp425/mioo-vpn/linux-mv425-2.4.18/crypto'
>
>
>
> I know the warning that `ixp' might be used uninitialized in this function
This warning would not apprear using current sources.
> is because that the ixp_register_cb is initialized zero.
>
> But I do not know why I got warning such as
>
> {standard input}: Assembler messages:
>
> {standard input}:5172: Warning: .space repeat count is zero, ignored
>
> {standard input}:5175: Warning: .space repeat count is zero, ignored
>
> {standard input}:5178: Warning: .space repeat count is zero, ignored
>
> I waiting for your help, thank you!
No idea, what compiler versions are you using.
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
|
|
From: David M. <Dav...@se...> - 2007-12-14 02:33:07
|
Jivin Egor N. Martovetsky lays it down ... > David, > > I was able to go to unlocked_ioctl. Things improved quite > a bit. I suppose this should be included in the next ocf release, > although there > is a chance that it will expose bugs in some drivers - like it did in mine. This is now in for the next release. Thanks, David > The problem that I saw with ocf-bench, turned out to be my driver > bug after all - I accidentally had one of the variables declared static > in *_process(), > and it was being modified by other threads. Actually, it seems the bkl > was in ioctl > for awhile, I looked in 2.4 tree, it is there. > > Another issue is that I think the throughput calculation is not correct > in cryptotest.c, > at least not for SMP environment. To calculate the throughput we want > to have > total data size processed divided by real time it took to process it. > So the nops > should always be multiplied by the number of threads. Also, to > calculate time we > are interested in real time, not the time that processes spent running > divided by > the number of threads. This gives incorrect results for SMP systems > with more than 1 thread. Ideally we would synchronize threads, but for > now I take > delta between first process start time and last process stop time as > execution time. > > > David McCullough wrote: > > >Jivin Egor N. Martovetsky lays it down ... > > > > > >>David - thanks for a quick response. I have comments in line. > >> > >>David McCullough wrote: > >> > >> > >> > >>>Jivin Egor N. Martovetsky lays it down ... > >>> > >>> > >>> > >>> > >>>>David, > >>>> > >>>>I noticed that the throughput I get when using cryptotest or OpenSSL > >>>>speed > >>>>is much worse than what I get using ocf-bench. I also don't get much > >>>>improvement, if at all, when running mutiple threads of the above > >>>>programs. > >>>> > >>>> > >>>> > >>>> > >>>ocf-bench runs in kernel mode, the data does not need to be > >>>copied from user space to kernel space and back. This make a massive > >>>difference to performance. > >>> > >>>All user apps need to pass their data through to the kernel and back. > >>>Unfortunately we don't have a zero copy API for OCF (yet ;-) > >>> > >>>Basically, for OCF accelerated user space, you need to be using larger > >>>packets to help overcome the overheads of the user-kernel-user copies, > >>>but it will never be a good as in-kernel crypto with a zero copy > >>>interface. > >>> > >>> > >>Yes, I was aware of the copying, and it explains some of the performance > >>degradation, > >>that I see with a single thread user space program vs. kernel mode. As > >>you point out, the performance > >>of user space program gets better relative to kernel mode, as the packet > >>size is increased. However, > >>in ocf-bench I can keep cpu 100% utilized submitting and processing done > >>packets, while a single thread > >>of cryptotest is unable to do that, so I tried to run a few threads, and > >>saw the throughput get worse. > >> > >> > > > >All that makes sense, except that it got worse, see below. > > > > > > > >>>>It seems that this is a result of using ioctl(vs unlocked_ioctl) to > >>>>access /dev/crypto, which > >>>>would only allow one process doing crypto at a given time. Is that a > >>>>known problem and > >>>>are there plans to fix it? > >>>> > >>>> > >>>I wasn't aware that ioctl would prevent multiple processes from working > >>>in parallel. I have seen performance improvements with multiple threads > >>>on 2.4 systems. Haven't checked on 2.6 > >>> > >>> > >>In 2.6 kernel the do_ioctl() function in fs/ioctl.c does a kernel lock > >>before calling device's ioctl. > >> > >> > > > >Ok, that is just plain ugly :-( This used to be ok and I obviously missed > >the addition of ioctl_unlocked and the BKL. > > > >It should be safe to switch cryptodev across to ioctl_unlocked since > >that is what the code expects (and gets on other kernels/systems). > > > > > > > >>Since cryptodev ioctl submits a packet and waits for completion before > >>returning, effectively > >>only one request can be processed at a given time, and I am not able to > >>take advantage of multiple > >>crypto channels executing in parallel. > >> > >> > >> > >>>>Also, is ocf-bench SMP safe? I had to set CRYPTO_F_BATCH in the > >>>>crp_flags to make it work, > >>>>otherwise with the CRYPTO_F_CBIMM it would not work in the SMP mode. > >>>> > >>>> > >>>I have never thought nor checked that ocf-bench is SMP safe. Which OCF > >>>driver are you using when doing your tests ? It could explain a few > >>>things, > >>> > >>> > >>> > >>It's my own driver, for a new PA Semi chip, and since it is still under > >>development - > >>yes, it can explain a few things. :) > >> > >> > > > >I was more interested in whether is was cryptosoft or one of the HW > >drivers. Generally the HW drivers work better with immediate callbacks > >as there is still a "gap" between the callin and callback. > > > >When your completion call is run before you have returned from the > >initial request, your code needs to be a lot more careful ;-) > > > >Unfortunately OCF hasn't had a huge amount of SMP focus. I have run it > >on SMP machines using hifn drivers, but not that often. So you may hit > >some other SMP issues. > > > > > > > >>But in this case, I don't think so, because in general it works fine, > >>and ocf-bench > >>works fine in nosmp mode, or with CRYPTO_F_BATCH mode, which makes > >>the completions go through a callback queue that is protected by > >>spinlocks, as opposed > >>to immediate callbacks. > >> > >> > > > >If you get a handle on what is happening let me know, it would be nice > >to get it fixed. > > > >Cheers, > >Davidm > > > > > > > > > -- > Egor N. Martovetsky > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-12-14 00:35:15
|
Jivin Tomasz Rostanski lays it down ... > David, > > >Jivin Tomasz Rostanski lays it down ... > >>Hi David, > >> > >>>Jivin Tomasz Rostanski lays it down ... > >>>>Hi David, > >>>>>Jivin Tomasz Rostanski lays it down ... > >>>>>>Hi David, > >>>>>> > >>>>>>Do you made any progress? > >>>>>Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and > >>>>>ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed > >>>>>works fine (although throughput seems to be down). > >>>>> > >>>>>The driver is at least processing requests ok. > >>>>> > >>>>>Are you installing the correct NPE code with something like: > >>>>> > >>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe > >>>>I have NPE code compiled in. I have also made a build without compiling > >>>>it in, the result was the same. > >>>We have an updated patch for CSR-2.4 at: > >>> > >>> http://www.snapgear.org/snapgear/downloads.html > >>> > >>>might be something in there that helps you. I am effectively running SG > >>>Linux 3.5 on my IXP425's with that access lib patch applied, > >> > >>I have imported this patch (not everything I need) to our trunk and > >>checked with the OCF 20070727 and... is working! > >>Thank you for your help. > > > >No problems, glad it worked ;-) > > But now I have a problems with openssh. > > When I run first "openssl speed -evp des -elapsed -engine cryptodev" > > I got: > > # ssh 192.168.0.10 > [ 151.390000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.400000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.410000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.420000] ixp_freesession() > [ 151.440000] ixp_newsession() > [ 151.440000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.450000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.460000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.480000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.490000] ixp_freesession() > The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. > RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. > [ 153.270000] ixp_newsession() > [ 153.270000] ixp_newsession() > [ 153.280000] ixp_process() > [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) > [ 153.280000] ixp_process_pending(c3575400) > [ 153.290000] ixp_process_pending in while > [ 153.290000] ixp_q_process(c28949e0) > evp_crypt: EVP_Cipher failed > [ 153.300000] ixp_freesession() > [ 153.300000] ixp_freesession() > > but when I run ssh without running openssl speed before I got the freeze > in ixp_q_process. > > Do you use some patch for ssh too? I found some patches which adds some > openssl engine initialization to ssh but it won't helped. Sorry I took so long to get back to you on this. I have just gone through the above sequences here and ssh works fine for me in both cases. I am not getting the "evp_crypt: EVP_Cipher failed" error either. I tried both into my ixp and out of the ixp board. Which versions of openssl/openssh are you using ? Not that it should really matter. I am running with CSR 2.4 and 0.9.8g (I've updated) and ssh 4.7p1, probably also updated, but no patches are needed for ssh IIRC. I don't see any ixp_perform_cb, to me this says the ixp crypto is not happy still. Does the "openssl speed" test give you numbers comparable to that on the ocf-linux web page benchmarks section ? If not it sounds like the crypto is just not working, which comes back to the correct NPE code or the call to ixCryptoAccInit failing. Perhaps add some debug to that code to make sure he crypto engine is started correctly. Look for a kernel message: ixCryptoAccInit failed, assuming already initialised! when loading the ixp4xx driver, if you get that investigate further ;-) I should have a new version out today (famous last words). It might be good to try it out and see if there has been any improvements. Quite a lot of potential locking/sleeping and other bus have been fixed and you may be just hitting one of those. Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-12-13 01:45:10
|
Jivin Nawang Chhetan lays it down ... > HI David, > Please send me the diff for the changes, you made since last > release. I am using a driver which calls crpto_newsession function from > soft_irq context. When I do a simple ping the sessions are created fine with > only the warning. But if I flood heavy traffic my machine hangs. > > This is how I use. > But in general don't you think it is not advisable, to take a spin lock and > then call a sleeping fucntion, which what we do when we call > crypto_newsession with cryptosoft as provider. Ok, thats was fairly easy to fix. I do not run my kernels with spinlock debug enabled, adding that highlighted a couple of locking issues and I have put some fixes in place. See attached patch. I am trying to get a release out this week (fixes, new openswan, new drivers etc). Cheers, Davidm > On Dec 10, 2007 4:18 PM, David McCullough < > Dav...@se...> wrote: > > > > > Jivin Nawang Chhetan lays it down ... > > > No. > > > > Ok, what sort of load/testing produced it ? > > > > I ran OCF + cryptosoft through our benchmark suite on an IXP425 (arm-be) > > just a couple of days ago without problems. > > > > I can send you the diffs against that last release in case there is > > something we have fixed in there. The trick is the openswan diffs, > > as I have moved up to 2.4.11 now, > > > > Cheers, > > Davidm > > > > > > > > On Dec 10, 2007 4:07 PM, David McCullough < > > > Dav...@se...> wrote: > > > > > > > > > > > Jivin Nawang Chhetan lays it down ... > > > > > Hi David, > > > > > I browsed through the swcr_newsession code. I realized > > > > there is > > > > > something seriously wrong. > > > > > I am attaching dmesg dump, which clearly indicates where the > > following > > > > bug > > > > > message is generated > > > > > BUG: sleeping function called from invalid context at > > > > > kernel/rwsem.c:20 > > > > > > > > Is this with pre-emption turned on still ? > > > > > > > > Thanks, > > > > David > > > > > > > > PS > > > > I wil get to your other mail, just very busy at the moment :-( > > > > > > > > > I am using OCF with cryptosoft. Basically this result because we > > take a > > > > lock > > > > > in cryto_newsession before calling the swcr_newsession. > > swcr_newsession > > > > > further calls a linux crypto library function which is sleeping. > > > > > > > > > > ****************** > > > > > dmesg > > > > > [ 524.873107] crypto/ocf/crypto.c,354: DRIVER_LOCK() > > > > > [ 524.873120] swcr_newsession() > > > > > [ 524.873127] swcr_newsession crypto_alloc_blkcipher(cbc(aes), 0x0) > > > > > [ 524.873136] BUG: sleeping function called from invalid context at > > > > > kernel/rwsem.c:20 > > > > > [ 524.880781] in_atomic():0, irqs_disabled():1 > > > > > [ 524.880825] [<c013fa32>] down_read+0x12/0x20 > > > > > [ 524.880845] [<c01e8bce>] crypto_alg_lookup+0x1e/0x50 > > > > > [ 524.880865] [<c01e8c30>] crypto_alg_mod_lookup+0x30/0x260 > > > > > [ 524.880891] [<c01e8ea6>] crypto_alloc_base+0x26/0x80 > > > > > [ 524.880914] [<e0ae2f6d>] swcr_newsession+0x1cd/0x770 > > [cryptosoft] > > > > > [ 524.880964] [<e09f8351>] crypto_newsession+0x1d1/0x240 [ocf] > > > > > ****************** > > > > > > > > > > Please comment. > > > > > > > > > > -- > > > > > Nawang Chhetan > > > > > Software Engineer > > > > > SafeNet India. > > > > > > > > -- > > > > David McCullough, dav...@se..., Ph:+61 > > > > 734352815 > > > > Secure Computing - SnapGear http://www.uCdot.org > > > > http://www.cyberguard.com > > > > > > > > > > > > > > > > -- > > > Nawang Chhetan > > > Software Engineer > > > SafeNet India. > > > > -- > > David McCullough, dav...@se..., Ph:+61 > > 734352815 > > Secure Computing - SnapGear http://www.uCdot.org > > http://www.cyberguard.com > > > > > > -- > Nawang Chhetan > Software Engineer > SafeNet India. -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-12-13 01:28:31
|
Jivin Kabir Ahsan lays it down ... > Hi David > Sorry for writing directly. I tried using the openswan/ocf mailing list > but I guess my posting is not showing up. > Any how, I wanted to let you know that when I run OCF-based IPsec with > CBIMM=1 in SMP mode for kernel 2.6.23 then I run spinlock recursion > issue in the ipsec_rsm routine. This problem could be easily manifested > using the OCF-null driver. > Is this a known bug? If yes, is there any recent patch to fix the > problem? That makes sense I guess, as CBIMM means we call back into ipsec before the call to do the request returns. Makes the coding much trickier to get right. On an SMP kernel I would disable CBIMM in fact I would almost always do that, but I know that small low- cache systems can go quite a bit faster using CBIMM, so it stays. If anyone want to suggest fixes for these it would be appreciated :-) Otherwise I will try and review the locking when I get some time and see if we can reduce the locking windows and cleanup CBIMM, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-12-13 00:32:37
|
Jivin Kabir Ahsan lays it down ... > Hi > Has anyone tried to run OCF Openswan for SMP kernel in particular > on 2.6.23? I see spinlock recursion problem in ipsec code. Do you have any details on where in the code it is happening. I don't really have time just now to bring up an SMP system and try it thats all :-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-12-10 10:45:09
|
Jivin Nawang Chhetan lays it down ... > No. Ok, what sort of load/testing produced it ? I ran OCF + cryptosoft through our benchmark suite on an IXP425 (arm-be) just a couple of days ago without problems. I can send you the diffs against that last release in case there is something we have fixed in there. The trick is the openswan diffs, as I have moved up to 2.4.11 now, Cheers, Davidm > > On Dec 10, 2007 4:07 PM, David McCullough < > Dav...@se...> wrote: > > > > > Jivin Nawang Chhetan lays it down ... > > > Hi David, > > > I browsed through the swcr_newsession code. I realized > > there is > > > something seriously wrong. > > > I am attaching dmesg dump, which clearly indicates where the following > > bug > > > message is generated > > > BUG: sleeping function called from invalid context at > > > kernel/rwsem.c:20 > > > > Is this with pre-emption turned on still ? > > > > Thanks, > > David > > > > PS > > I wil get to your other mail, just very busy at the moment :-( > > > > > I am using OCF with cryptosoft. Basically this result because we take a > > lock > > > in cryto_newsession before calling the swcr_newsession. swcr_newsession > > > further calls a linux crypto library function which is sleeping. > > > > > > ****************** > > > dmesg > > > [ 524.873107] crypto/ocf/crypto.c,354: DRIVER_LOCK() > > > [ 524.873120] swcr_newsession() > > > [ 524.873127] swcr_newsession crypto_alloc_blkcipher(cbc(aes), 0x0) > > > [ 524.873136] BUG: sleeping function called from invalid context at > > > kernel/rwsem.c:20 > > > [ 524.880781] in_atomic():0, irqs_disabled():1 > > > [ 524.880825] [<c013fa32>] down_read+0x12/0x20 > > > [ 524.880845] [<c01e8bce>] crypto_alg_lookup+0x1e/0x50 > > > [ 524.880865] [<c01e8c30>] crypto_alg_mod_lookup+0x30/0x260 > > > [ 524.880891] [<c01e8ea6>] crypto_alloc_base+0x26/0x80 > > > [ 524.880914] [<e0ae2f6d>] swcr_newsession+0x1cd/0x770 [cryptosoft] > > > [ 524.880964] [<e09f8351>] crypto_newsession+0x1d1/0x240 [ocf] > > > ****************** > > > > > > Please comment. > > > > > > -- > > > Nawang Chhetan > > > Software Engineer > > > SafeNet India. > > > > -- > > David McCullough, dav...@se..., Ph:+61 > > 734352815 > > Secure Computing - SnapGear http://www.uCdot.org > > http://www.cyberguard.com > > > > > > -- > Nawang Chhetan > Software Engineer > SafeNet India. -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-12-10 10:45:06
|
Jivin Nawang Chhetan lays it down ... > Hi David, > I browsed through the swcr_newsession code. I realized there is > something seriously wrong. > I am attaching dmesg dump, which clearly indicates where the following bug > message is generated > BUG: sleeping function called from invalid context at > kernel/rwsem.c:20 Is this with pre-emption turned on still ? Thanks, David PS I wil get to your other mail, just very busy at the moment :-( > I am using OCF with cryptosoft. Basically this result because we take a lock > in cryto_newsession before calling the swcr_newsession. swcr_newsession > further calls a linux crypto library function which is sleeping. > > ****************** > dmesg > [ 524.873107] crypto/ocf/crypto.c,354: DRIVER_LOCK() > [ 524.873120] swcr_newsession() > [ 524.873127] swcr_newsession crypto_alloc_blkcipher(cbc(aes), 0x0) > [ 524.873136] BUG: sleeping function called from invalid context at > kernel/rwsem.c:20 > [ 524.880781] in_atomic():0, irqs_disabled():1 > [ 524.880825] [<c013fa32>] down_read+0x12/0x20 > [ 524.880845] [<c01e8bce>] crypto_alg_lookup+0x1e/0x50 > [ 524.880865] [<c01e8c30>] crypto_alg_mod_lookup+0x30/0x260 > [ 524.880891] [<c01e8ea6>] crypto_alloc_base+0x26/0x80 > [ 524.880914] [<e0ae2f6d>] swcr_newsession+0x1cd/0x770 [cryptosoft] > [ 524.880964] [<e09f8351>] crypto_newsession+0x1d1/0x240 [ocf] > ****************** > > Please comment. > > -- > Nawang Chhetan > Software Engineer > SafeNet India. -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Nawang C. <naw...@gm...> - 2007-12-10 09:24:16
|
Hi All,
I browsed through the swcr_newsession code. I realized there is
something seriously wrong.
I am attaching dmesg dump, which clearly indicates where the following bug
message is generated
BUG: sleeping function called from invalid context at
kernel/rwsem.c:20
I am using OCF with cryptosoft. Basically this result because we take a lock
in cryto_newsession before calling the swcr_newsession. swcr_newsession
further calls a linux crypto library function which is sleeping.
******************
dmesg
[ 524.873107] crypto/ocf/crypto.c,354: DRIVER_LOCK()
[ 524.873120] swcr_newsession()
[ 524.873127] swcr_newsession crypto_alloc_blkcipher(cbc(aes), 0x0)
[ 524.873136] BUG: sleeping function called from invalid context at
kernel/rwsem.c:20
[ 524.880781] in_atomic():0, irqs_disabled():1
[ 524.880825] [<c013fa32>] down_read+0x12/0x20
[ 524.880845] [<c01e8bce>] crypto_alg_lookup+0x1e/0x50
[ 524.880865] [<c01e8c30>] crypto_alg_mod_lookup+0x30/0x260
[ 524.880891] [<c01e8ea6>] crypto_alloc_base+0x26/0x80
[ 524.880914] [<e0ae2f6d>] swcr_newsession+0x1cd/0x770 [cryptosoft]
[ 524.880964] [<e09f8351>] crypto_newsession+0x1d1/0x240 [ocf]
******************
Please comment.
--
Nawang Chhetan
Software Engineer
SafeNet India.
|
|
From: Tomasz R. <tro...@pr...> - 2007-11-09 11:22:37
|
David, > Jivin Tomasz Rostanski lays it down ... > ... >>> The authenticity of host '192.168.0.10 (192.168.0.10)' can't be >>> established. >>> RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. >>> Are you sure you want to continue connecting (yes/no)? yes >>> Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. >>> [ 153.270000] ixp_newsession() >>> [ 153.270000] ixp_newsession() >>> [ 153.280000] ixp_process() >>> [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) >>> [ 153.280000] ixp_process_pending(c3575400) >>> [ 153.290000] ixp_process_pending in while >>> [ 153.290000] ixp_q_process(c28949e0) >>> evp_crypt: EVP_Cipher failed >>> [ 153.300000] ixp_freesession() >>> [ 153.300000] ixp_freesession() >>> >>> but when I run ssh without running openssl speed before I got the freeze >>> in ixp_q_process. >>> >>> Do you use some patch for ssh too? I found some patches which adds some >>> openssl engine initialization to ssh but it won't helped. >> I have used the cryptosoft module with the debugging enabled instead of >> ixp4xx and ssh worked. So it seems that there is still some problem with >> the ixp4xx module... > > Good test, did you double check that cryptosoft was doing the work by > enabling debug ? Yes. > I have just finished cleaning up the 2.6.23 support, so I should have a > chance to test ssh next week, just bug me if I don't ;-) I will do ;) Tomasz |
|
From: David M. <Dav...@se...> - 2007-11-09 10:50:07
|
Jivin Tomasz Rostanski lays it down ... ... > >The authenticity of host '192.168.0.10 (192.168.0.10)' can't be > >established. > >RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. > >Are you sure you want to continue connecting (yes/no)? yes > >Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. > >[ 153.270000] ixp_newsession() > >[ 153.270000] ixp_newsession() > >[ 153.280000] ixp_process() > >[ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) > >[ 153.280000] ixp_process_pending(c3575400) > >[ 153.290000] ixp_process_pending in while > >[ 153.290000] ixp_q_process(c28949e0) > >evp_crypt: EVP_Cipher failed > >[ 153.300000] ixp_freesession() > >[ 153.300000] ixp_freesession() > > > >but when I run ssh without running openssl speed before I got the freeze > >in ixp_q_process. > > > >Do you use some patch for ssh too? I found some patches which adds some > > openssl engine initialization to ssh but it won't helped. > > I have used the cryptosoft module with the debugging enabled instead of > ixp4xx and ssh worked. So it seems that there is still some problem with > the ixp4xx module... Good test, did you double check that cryptosoft was doing the work by enabling debug ? I have just finished cleaning up the 2.6.23 support, so I should have a chance to test ssh next week, just bug me if I don't ;-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Tomasz R. <tro...@pr...> - 2007-11-09 10:13:17
|
David, > David, > >> Jivin Tomasz Rostanski lays it down ... >>> Hi David, >>> >>>> Jivin Tomasz Rostanski lays it down ... >>>>> Hi David, >>>>>> Jivin Tomasz Rostanski lays it down ... >>>>>>> Hi David, >>>>>>> >>>>>>> Do you made any progress? >>>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>>> works fine (although throughput seems to be down). >>>>>> >>>>>> The driver is at least processing requests ok. >>>>>> >>>>>> Are you installing the correct NPE code with something like: >>>>>> >>>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>>> I have NPE code compiled in. I have also made a build without >>>>> compiling it in, the result was the same. >>>> We have an updated patch for CSR-2.4 at: >>>> >>>> http://www.snapgear.org/snapgear/downloads.html >>>> >>>> might be something in there that helps you. I am effectively >>>> running SG >>>> Linux 3.5 on my IXP425's with that access lib patch applied, >>> >>> I have imported this patch (not everything I need) to our trunk and >>> checked with the OCF 20070727 and... is working! >>> Thank you for your help. >> >> No problems, glad it worked ;-) > > But now I have a problems with openssh. > > When I run first "openssl speed -evp des -elapsed -engine cryptodev" > > I got: > > # ssh 192.168.0.10 > [ 151.390000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.400000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.410000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.420000] ixp_freesession() > [ 151.440000] ixp_newsession() > [ 151.440000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.450000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.460000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.480000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.490000] ixp_freesession() > The authenticity of host '192.168.0.10 (192.168.0.10)' can't be > established. > RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. > [ 153.270000] ixp_newsession() > [ 153.270000] ixp_newsession() > [ 153.280000] ixp_process() > [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) > [ 153.280000] ixp_process_pending(c3575400) > [ 153.290000] ixp_process_pending in while > [ 153.290000] ixp_q_process(c28949e0) > evp_crypt: EVP_Cipher failed > [ 153.300000] ixp_freesession() > [ 153.300000] ixp_freesession() > > but when I run ssh without running openssl speed before I got the freeze > in ixp_q_process. > > Do you use some patch for ssh too? I found some patches which adds some > openssl engine initialization to ssh but it won't helped. I have used the cryptosoft module with the debugging enabled instead of ixp4xx and ssh worked. So it seems that there is still some problem with the ixp4xx module... Tomasz |
|
From: Mosquito <mos...@gm...> - 2007-11-05 10:06:57
|
David McCullough 提到: > Jivin Mosquito lays it down ... >> HI...guys:) > > Hi. > >> I'm a newbie of kernel and ocf-linux... >> and i got a work to write a driver for a product's prototype... >> so i need make ocf-linux worked first... >> >> i have some problem with make it work... >> i'm using ubuntu 7.10... >> and i trying to build it with kernel 2.6.22.10... >> >> I'm following instruction in readme... >> and somebody's note >> http://www.docunext.com/resources/mediawiki/index.php/My_Notes_on_Patching_2.6.22_with_OCF >> >> I'm patch kernel source with ocf-linux-26-XXXXXXXX.patch.gz >> it's have no error msg...but when i make menuconfig >> i didn't see OCF's option... >> so i follow the note... >> manual add {source "crypto/ocf/Kconfig"} into <$Linux Source >> dir$>/drivers/crypto/Kconfig >> and then i can set options for OCF when i make menuconfig... >> is this a bug need to fix?? >> >> then...i set OCF option as "M"...to be complier as module... >> and then i build kernel with those commands... >> make-kpkg clean >> make-kpkg --initrd kernel_image kernel_headers >> dpkg -i linux-image-2.6.22.10.Custom_i386.deb >> dpkg -i linux-headers-2.6.22.10.Custom_i386.deb >> >> it's should be fine...and i reboot...using new kernel to boot... >> but like the note...OCF didn't complier as module... > > So you have built the kernel ok with OCF support enabled as a module ? well...I'm not sure actually... because with the patch "ocf-linux-26-XXXXXXXX.patch.gz"... and after set crypto options and ocf options when i make menuconfig.. i thought it's should be built as module when i build the kernel... but it's look like not include it... I've build it by manual like the note and you say... "make -C /usr/src/linux-source-2.6.22/ M=`pwd` modules modules_install" I just wondering does that correct? >> the note say david remind that he skipped "install kernel" part... >> but i'm not sure what does that mean... >> so i subscribe this mailing list and hope some one give me some help... > > Try something like: > > make -C /usr/src/linux-source-2.6.22/ M=`pwd` modules modules_install > > Not sure exactly what you need here as I always build from my own source > trees and not debian ones ;-) If that all works then try loading the > modules: > > modprobe ocf > lsmod | grep ocf > > Cheers, > David hm...I've hang on ocf,cryptodev,cryptosoft... and I'm running the script bench-ocf... it's will show me something like result... it's should be fine, right? anyway...thanks for your reply...:) Best regards~ mosquito PS.My thunderbid with Gmail IMAP is look like insane... sorry about the spam...= =" |
|
From: David M. <Dav...@se...> - 2007-11-05 03:46:32
|
Jivin Mosquito lays it down ... > HI...guys:) Hi. > I'm a newbie of kernel and ocf-linux... > and i got a work to write a driver for a product's prototype... > so i need make ocf-linux worked first... > > i have some problem with make it work... > i'm using ubuntu 7.10... > and i trying to build it with kernel 2.6.22.10... > > I'm following instruction in readme... > and somebody's note > http://www.docunext.com/resources/mediawiki/index.php/My_Notes_on_Patching_2.6.22_with_OCF > > I'm patch kernel source with ocf-linux-26-XXXXXXXX.patch.gz > it's have no error msg...but when i make menuconfig > i didn't see OCF's option... > so i follow the note... > manual add {source "crypto/ocf/Kconfig"} into <$Linux Source > dir$>/drivers/crypto/Kconfig > and then i can set options for OCF when i make menuconfig... > is this a bug need to fix?? > > then...i set OCF option as "M"...to be complier as module... > and then i build kernel with those commands... > make-kpkg clean > make-kpkg --initrd kernel_image kernel_headers > dpkg -i linux-image-2.6.22.10.Custom_i386.deb > dpkg -i linux-headers-2.6.22.10.Custom_i386.deb > > it's should be fine...and i reboot...using new kernel to boot... > but like the note...OCF didn't complier as module... So you have built the kernel ok with OCF support enabled as a module ? > the note say david remind that he skipped "install kernel" part... > but i'm not sure what does that mean... > so i subscribe this mailing list and hope some one give me some help... Try something like: make -C /usr/src/linux-source-2.6.22/ M=`pwd` modules modules_install Not sure exactly what you need here as I always build from my own source trees and not debian ones ;-) If that all works then try loading the modules: modprobe ocf lsmod | grep ocf Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-11-05 03:34:45
|
Jivin Eran Ben-Avi lays it down ...
...
> > I have made a few small changes to your patch so it should be safe on
> > 2.4 systems yet still select tasklets on 2.6 automatically.
> >
> > Could you have a look at it ? I have done some basic testing here
> > and it seems ok, haven't checked your performance increases yet ;-)
> >
> Sorry for the late response.
> It seems to be ok. I will test it more intensely in the next few days.
No problems, I have it sitting there ready to go :-)
Cheers,
Davidm
> > -----Inline Attachment Follows-----
> >
> > Index: openswan/linux/include/openswan/ipsec_rcv.h
> > ===================================================================
> > RCS file: openswan/linux/include/openswan/ipsec_rcv.h,v
> > retrieving revision 1.13
> > diff -u -r1.13 ipsec_rcv.h
> > --- openswan/linux/include/openswan/ipsec_rcv.h 26 Jun 2007
> > 06:28:52
> >
> -0000 1.13
> > +++ openswan/linux/include/openswan/ipsec_rcv.h 26 Sep 2007
> > 14:17:25
> >
> -0000
> > @@ -149,6 +149,9 @@
> >
> > #ifdef CONFIG_KLIPS_OCF
> > struct work_struct workq;
> > +#ifdef DECLARE_TASKLET
> > + struct tasklet_struct tasklet;
> > +#endif
> > #endif
> > #ifndef NET_21
> > struct net_device *devp;
> > Index: openswan/linux/include/openswan/ipsec_xmit.h
> > ===================================================================
> > RCS file: openswan/linux/include/openswan/ipsec_xmit.h,v
> > retrieving revision 1.9
> > diff -u -r1.9 ipsec_xmit.h
> > --- openswan/linux/include/openswan/ipsec_xmit.h 26 Jun
> > 2007
> >
> 05:26:25 -0000 1.9
> > +++ openswan/linux/include/openswan/ipsec_xmit.h 26 Sep
> > 2007
> >
> 14:17:25 -0000
> > @@ -140,6 +140,9 @@
> > int next_state;
> > #ifdef CONFIG_KLIPS_OCF
> > struct work_struct workq;
> > +#ifdef DECLARE_TASKLET
> > + struct tasklet_struct tasklet;
> > +#endif
> > #endif
> > #ifdef CONFIG_KLIPS_ALG
> > struct ipsec_alg_auth *ixt_a;
> > Index: openswan/linux/net/ipsec/ipsec_ocf.c
> > ===================================================================
> > RCS file: openswan/linux/net/ipsec/ipsec_ocf.c,v
> > retrieving revision 1.27
> > diff -u -r1.27 ipsec_ocf.c
> > --- openswan/linux/net/ipsec/ipsec_ocf.c 11 Jul 2007 00:35:01
> > -0000
> >
> 1.27
> > +++ openswan/linux/net/ipsec/ipsec_ocf.c 26 Sep 2007 14:17:25 -0000
> > @@ -56,7 +56,11 @@
> > #define USE_BATCH 1 /* enable batch mode */
> > #define USE_CBIMM 1 /* enable immediate callbacks */
> > #define FORCE_QS 0 /* force use of queues for continuation
> > of
> >
> state machine */
> > -
> > +#ifdef DECLARE_TASKLET
> > +#define USE_TASKLET 1 /* use tasklet for continuation of
> > state
> >
> machine */
> > +#else
> > +#define USE_TASKLET 0 /* don't use tasklet for continuation of
> > state
> >
> machine */
> > +#endif
> > /*
> > * Because some OCF operations are synchronous (ie.,
> > software
> >
> encryption)
> > * we need to protect ourselves from distructive re-entry. All we do
> > @@ -83,15 +87,21 @@
> > (*sm)(arg); \
> > })
> >
> > -#if FORCE_QS == 0
> > - #define PROCESS_NEXT(wq, wqsm, sm, arg) \
> > +#if USE_TASKLET == 1
> > + #define PROCESS_NEXT(this, wqsm, sm) ({ \
> > + tasklet_init(&this->tasklet, \
> > + (void (*)(unsigned long)) sm, (unsigned long)this); \
> > + tasklet_schedule(&this->tasklet); \
> > + })
> > +#elif FORCE_QS == 0
> > + #define PROCESS_NEXT(this, wqsm, sm) \
> > if (in_interrupt()) { \
> > - PROCESS_LATER(wq, wqsm, arg); \
> > + PROCESS_LATER(this->workq, wqsm, this); \
> > } else { \
> > - PROCESS_NOW(sm, arg); \
> > + PROCESS_NOW(sm, this); \
> > }
> > #else
> > - #define PROCESS_NEXT(wq, wqsm, sm, arg) PROCESS_LATER(wq,
> > wqsm,
> >
> arg)
> > + #define PROCESS_NEXT(this, wqsm, sm)
> > PROCESS_LATER(this->workq,
> >
> wqsm, this)
> > #endif
> >
> > /*
> > @@ -218,6 +228,7 @@
> > return 1;
> > }
> >
> > +#if USE_TASKLET == 0
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> > static void
> > ipsec_rsm_wq(struct work_struct *work)
> > @@ -228,6 +239,7 @@
> > #else
> > #define ipsec_rsm_wq ipsec_rsm
> > #endif
> > +#endif /* USE_TASKLET */
> >
> > static int
> > ipsec_ocf_rcv_cb(struct cryptop *crp)
> > @@ -235,7 +247,6 @@
> > struct ipsec_rcv_state *irs = (struct
> > ipsec_rcv_state
> >
> *)crp->crp_opaque;
> >
> > KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb\n");
> > -
> > if (irs == NULL) {
> > KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb: "
> > "NULL irs in callback\n");
> > @@ -273,7 +284,7 @@
> > crp = NULL;
> >
> > /* setup the rest of the processing now */
> > - PROCESS_NEXT(irs->workq, ipsec_rsm_wq, ipsec_rsm, irs);
> > + PROCESS_NEXT(irs, ipsec_rsm_wq, ipsec_rsm);
> > return 0;
> > }
> >
> > @@ -396,6 +407,7 @@
> > return(IPSEC_RCV_PENDING);
> > }
> >
> > +#if USE_TASKLET == 0
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> > static void
> > ipsec_xsm_wq(struct work_struct *work)
> > @@ -406,6 +418,7 @@
> > #else
> > #define ipsec_xsm_wq ipsec_xsm
> > #endif
> > +#endif /* USE_TASKLET */
> >
> > static int
> > ipsec_ocf_xmit_cb(struct cryptop *crp)
> > @@ -445,7 +458,7 @@
> > crp = NULL;
> >
> > /* setup the rest of the processing now */
> > - PROCESS_NEXT(ixs->workq, ipsec_xsm_wq, ipsec_xsm, ixs);
> > + PROCESS_NEXT(ixs, ipsec_xsm_wq, ipsec_xsm);
> > return 0;
> > }
> >
> >
> >
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
|
|
From: Eran Ben-A. <era...@ya...> - 2007-11-01 14:34:04
|
=0A=0A----- Original Message ----=0A> From: David McCullough <David_Mccullo= ug...@se...>=0A> To: Eran Ben-Avi <era...@ya...>=0A> Cc= : lin...@vg...; ocf...@li...=0A> S= ent: Wednesday, September 26, 2007 12:26:10 PM=0A> Subject: Re: Openswan 2.= 4.9 - tasklet or workqueue ?=0A> =0A> =0A> Jivin Eran Ben-Avi lays it down = ...=0A> > > Jivin Eran Ben-Avi lays it down ...=0A> > > > Hi,=0A> > > > =0A= > > > > I tested IPSec(tunnel mode) routing performance=0A> > > between 2 G= bE ports using packet generator(SMARTBIT)=0A> > > on ARM 500MHz with lates= t OCF patched on=0A> > > Openswan2.4.9 and I noticed the callback functions= =0A> > > are using workqueue.=0A> > > > Since RX was performed in NAPI mode= with higher=0A> > > priority then TX (in workqueue), the callback=0A> > > = function(in ipsec_ocf.c) was starved with zero=0A> > > routing.=0A> > > > T= he problem was solved after I switched to use=0A> > > tasklet instead of th= e workqueue.=0A> > > > Is there a room for updating next OCF release ?=0A> = > > =0A> > > Sure, send in a patch. This is against=0A> > > ocf-linux-2007= 0727 right ?=0A> > Yes.=0A> > Can you please estimate when next release wil= l be=0A> > ready?=0A> =0A> I can probably do one in about a week (offline n= ext week). I could more=0A> easily drop a diff since the last release if th= at helps you out.=0A> =0A> I have made a few small changes to your patch so= it should be safe on=0A> 2.4 systems yet still select tasklets on 2.6 auto= matically.=0A> =0A> Could you have a look at it ? I have done some basic t= esting here=0A> and it seems ok, haven't checked your performance increase= s yet ;-)=0A> =0ASorry for the late response.=0AIt seems to be ok. I will t= est it more intensely in the next few days.=0AThanks.=0A=0A> Thanks,=0A> Da= vidm=0A> =0A> -- =0A> David McCullough, david_mccullough@securecomputing.c= om, =0A> Ph:+61=0A> =0A 734352815=0A> Secure Computing - SnapGear =0A> htt= p://www.uCdot.org=0A> =0A http://www.cyberguard.com=0A> =0A> =0A> -----Inli= ne Attachment Follows-----=0A> =0A> Index: openswan/linux/include/openswan/= ipsec_rcv.h=0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> R= CS file: openswan/linux/include/openswan/ipsec_rcv.h,v=0A> retrieving revis= ion 1.13=0A> diff -u -r1.13 ipsec_rcv.h=0A> --- openswan/linux/include/open= swan/ipsec_rcv.h 26 Jun 2007=0A> 06:28:52=0A> =0A -0000 1.13=0A> +++ = openswan/linux/include/openswan/ipsec_rcv.h 26 Sep 2007=0A> 14:17:25=0A>= =0A -0000=0A> @@ -149,6 +149,9 @@=0A> =0A> #ifdef CONFIG_KLIPS_OCF=0A> = struct work_struct workq;=0A> +#ifdef DECLARE_TASKLET=0A> + struc= t tasklet_struct tasklet;=0A> +#endif=0A> #endif=0A> #ifndef NET_21=0A= > struct net_device *devp;=0A> Index: openswan/linux/include/openswan/= ipsec_xmit.h=0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> R= CS file: openswan/linux/include/openswan/ipsec_xmit.h,v=0A> retrieving revi= sion 1.9=0A> diff -u -r1.9 ipsec_xmit.h=0A> --- openswan/linux/include/open= swan/ipsec_xmit.h 26 Jun=0A> 2007=0A> =0A 05:26:25 -0000 1.9=0A> +++ = openswan/linux/include/openswan/ipsec_xmit.h 26 Sep=0A> 2007=0A> =0A 14:= 17:25 -0000=0A> @@ -140,6 +140,9 @@=0A> int next_state;=0A> #i= fdef CONFIG_KLIPS_OCF=0A> struct work_struct workq;=0A> +#ifdef DEC= LARE_TASKLET=0A> + struct tasklet_struct tasklet;=0A> +#endif=0A> #e= ndif=0A> #ifdef CONFIG_KLIPS_ALG=0A> struct ipsec_alg_auth *ixt_a;=0A= > Index: openswan/linux/net/ipsec/ipsec_ocf.c=0A> =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> RCS file: openswan/linux/net/ipsec/ipsec_oc= f.c,v=0A> retrieving revision 1.27=0A> diff -u -r1.27 ipsec_ocf.c=0A> --- o= penswan/linux/net/ipsec/ipsec_ocf.c 11 Jul 2007 00:35:01=0A> -0000=0A> = =0A 1.27=0A> +++ openswan/linux/net/ipsec/ipsec_ocf.c 26 Sep 2007 14:= 17:25 -0000=0A> @@ -56,7 +56,11 @@=0A> #define USE_BATCH 1 /* enable ba= tch mode */=0A> #define USE_CBIMM 1 /* enable immediate callbacks */=0A= > #define FORCE_QS 0 /* force use of queues for continuation=0A> of=0A= > =0A state machine */=0A> -=0A> +#ifdef DECLARE_TASKLET=0A> +#define USE_T= ASKLET 1 /* use tasklet for continuation of=0A> state=0A> =0A machine */= =0A> +#else=0A> +#define USE_TASKLET 0 /* don't use tasklet for continuati= on of=0A> state=0A> =0A machine */=0A> +#endif=0A> /*=0A> * Because some= OCF operations are synchronous (ie.,=0A> software=0A> =0A encryption)=0A> = * we need to protect ourselves from distructive re-entry. All we do=0A> = @@ -83,15 +87,21 @@=0A> (*sm)(arg); \=0A> })=0A> =0A> -#if F= ORCE_QS =3D=3D 0=0A> - #define PROCESS_NEXT(wq, wqsm, sm, arg) \=0A> +#i= f USE_TASKLET =3D=3D 1=0A> + #define PROCESS_NEXT(this, wqsm, sm) ({ \= =0A> + tasklet_init(&this->tasklet, \=0A> + (void (*)(uns= igned long)) sm, (unsigned long)this); \=0A> + tasklet_schedule(&thi= s->tasklet); \=0A> + })=0A> +#elif FORCE_QS =3D=3D 0=0A> + #defin= e PROCESS_NEXT(this, wqsm, sm) \=0A> if (in_interrupt()) { \=0A> -= PROCESS_LATER(wq, wqsm, arg); \=0A> + PROCESS_LATER(= this->workq, wqsm, this); \=0A> } else { \=0A> - PROCES= S_NOW(sm, arg); \=0A> + PROCESS_NOW(sm, this); \=0A> }= =0A> #else=0A> - #define PROCESS_NEXT(wq, wqsm, sm, arg) PROCESS_LATER(= wq,=0A> wqsm,=0A> =0A arg)=0A> + #define PROCESS_NEXT(this, wqsm, sm)=0A= > PROCESS_LATER(this->workq,=0A> =0A wqsm, this)=0A> #endif=0A> =0A> /*= =0A> @@ -218,6 +228,7 @@=0A> return 1;=0A> }=0A> =0A> +#if USE_TASKL= ET =3D=3D 0=0A> #if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,20)=0A> st= atic void=0A> ipsec_rsm_wq(struct work_struct *work)=0A> @@ -228,6 +239,7 = @@=0A> #else=0A> #define ipsec_rsm_wq ipsec_rsm=0A> #endif=0A> +#e= ndif /* USE_TASKLET */=0A> =0A> static int=0A> ipsec_ocf_rcv_cb(struct c= ryptop *crp)=0A> @@ -235,7 +247,6 @@=0A> struct ipsec_rcv_state *irs = =3D (struct=0A> ipsec_rcv_state=0A> =0A *)crp->crp_opaque;=0A> =0A> K= LIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb\n");=0A> -=0A> if = (irs =3D=3D NULL) {=0A> KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_= ocf_rcv_cb: "=0A> "NULL irs in callback\n");=0A> @@ -273,7= +284,7 @@=0A> crp =3D NULL;=0A> =0A> /* setup the rest of the p= rocessing now */=0A> - PROCESS_NEXT(irs->workq, ipsec_rsm_wq, ipsec_rsm,= irs);=0A> + PROCESS_NEXT(irs, ipsec_rsm_wq, ipsec_rsm);=0A> return= 0;=0A> }=0A> =0A> @@ -396,6 +407,7 @@=0A> return(IPSEC_RCV_PENDING)= ;=0A> }=0A> =0A> +#if USE_TASKLET =3D=3D 0=0A> #if LINUX_VERSION_CODE >= =3D KERNEL_VERSION(2,6,20)=0A> static void=0A> ipsec_xsm_wq(struct work_s= truct *work)=0A> @@ -406,6 +418,7 @@=0A> #else=0A> #define ipsec_xsm_w= q ipsec_xsm=0A> #endif=0A> +#endif /* USE_TASKLET */=0A> =0A> static = int=0A> ipsec_ocf_xmit_cb(struct cryptop *crp)=0A> @@ -445,7 +458,7 @@=0A>= crp =3D NULL;=0A> =0A> /* setup the rest of the processing now = */=0A> - PROCESS_NEXT(ixs->workq, ipsec_xsm_wq, ipsec_xsm, ixs);=0A> + = PROCESS_NEXT(ixs, ipsec_xsm_wq, ipsec_xsm);=0A> return 0;=0A> }=0A>= =0A> =0A> =0A=0A=0A=0A__________________________________________________= =0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam protectio= n around =0Ahttp://mail.yahoo.com |
|
From: Mosquito <mos...@gm...> - 2007-10-31 16:18:39
|
HI...guys:) I'm a newbie of kernel and ocf-linux... and i got a work to write a driver for a product's prototype... so i need make ocf-linux worked first... i have some problem with make it work... i'm using ubuntu 7.10... and i trying to build it with kernel 2.6.22.10... I'm following instruction in readme... and somebody's note http://www.docunext.com/resources/mediawiki/index.php/My_Notes_on_Patching_2.6.22_with_OCF I'm patch kernel source with ocf-linux-26-XXXXXXXX.patch.gz it's have no error msg...but when i make menuconfig i didn't see OCF's option... so i follow the note... manual add {source "crypto/ocf/Kconfig"} into <$Linux Source dir$>/drivers/crypto/Kconfig and then i can set options for OCF when i make menuconfig... is this a bug need to fix?? then...i set OCF option as "M"...to be complier as module... and then i build kernel with those commands... make-kpkg clean make-kpkg --initrd kernel_image kernel_headers dpkg -i linux-image-2.6.22.10.Custom_i386.deb dpkg -i linux-headers-2.6.22.10.Custom_i386.deb it's should be fine...and i reboot...using new kernel to boot... but like the note...OCF didn't complier as module... the note say david remind that he skipped "install kernel" part... but i'm not sure what does that mean... so i subscribe this mailing list and hope some one give me some help... thanks a lot:) best regards~ mosquito |
|
From: Tomasz R. <tro...@pr...> - 2007-10-26 12:24:42
|
David, > Jivin Tomasz Rostanski lays it down ... >> Hi David, >> >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>>> Jivin Tomasz Rostanski lays it down ... >>>>>> Hi David, >>>>>> >>>>>> Do you made any progress? >>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>> works fine (although throughput seems to be down). >>>>> >>>>> The driver is at least processing requests ok. >>>>> >>>>> Are you installing the correct NPE code with something like: >>>>> >>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>> I have NPE code compiled in. I have also made a build without compiling >>>> it in, the result was the same. >>> We have an updated patch for CSR-2.4 at: >>> >>> http://www.snapgear.org/snapgear/downloads.html >>> >>> might be something in there that helps you. I am effectively running SG >>> Linux 3.5 on my IXP425's with that access lib patch applied, >> >> I have imported this patch (not everything I need) to our trunk and >> checked with the OCF 20070727 and... is working! >> Thank you for your help. > > No problems, glad it worked ;-) But now I have a problems with openssh. When I run first "openssl speed -evp des -elapsed -engine cryptodev" I got: # ssh 192.168.0.10 [ 151.390000] ixp_newsession() [ 151.400000] ixp_freesession() [ 151.400000] ixp_newsession() [ 151.400000] ixp_freesession() [ 151.410000] ixp_newsession() [ 151.410000] ixp_freesession() [ 151.410000] ixp_newsession() [ 151.420000] ixp_freesession() [ 151.440000] ixp_newsession() [ 151.440000] ixp_freesession() [ 151.450000] ixp_newsession() [ 151.450000] ixp_freesession() [ 151.450000] ixp_newsession() [ 151.460000] ixp_freesession() [ 151.460000] ixp_newsession() [ 151.460000] ixp_freesession() [ 151.470000] ixp_newsession() [ 151.470000] ixp_freesession() [ 151.470000] ixp_newsession() [ 151.470000] ixp_freesession() [ 151.480000] ixp_newsession() [ 151.480000] ixp_freesession() [ 151.480000] ixp_newsession() [ 151.490000] ixp_freesession() The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. [ 153.270000] ixp_newsession() [ 153.270000] ixp_newsession() [ 153.280000] ixp_process() [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) [ 153.280000] ixp_process_pending(c3575400) [ 153.290000] ixp_process_pending in while [ 153.290000] ixp_q_process(c28949e0) evp_crypt: EVP_Cipher failed [ 153.300000] ixp_freesession() [ 153.300000] ixp_freesession() but when I run ssh without running openssl speed before I got the freeze in ixp_q_process. Do you use some patch for ssh too? I found some patches which adds some openssl engine initialization to ssh but it won't helped. Tomasz |
|
From: David M. <Dav...@se...> - 2007-10-24 10:37:55
|
Jivin Tomasz Rostanski lays it down ... > Hi David, > > >Jivin Tomasz Rostanski lays it down ... > >>Hi David, > >>>Jivin Tomasz Rostanski lays it down ... > >>>>Hi David, > >>>> > >>>>Do you made any progress? > >>>Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and > >>>ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed > >>>works fine (although throughput seems to be down). > >>> > >>>The driver is at least processing requests ok. > >>> > >>>Are you installing the correct NPE code with something like: > >>> > >>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe > >>I have NPE code compiled in. I have also made a build without compiling > >>it in, the result was the same. > > > >We have an updated patch for CSR-2.4 at: > > > > http://www.snapgear.org/snapgear/downloads.html > > > >might be something in there that helps you. I am effectively running SG > >Linux 3.5 on my IXP425's with that access lib patch applied, > > > I have imported this patch (not everything I need) to our trunk and > checked with the OCF 20070727 and... is working! > Thank you for your help. No problems, glad it worked ;-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
4 messages has been excluded from this view by a project administrator.
