ocf-linux-users — Anything and everything ocf-linux related

Re: [Ocf-linux-users] Openswan 2.4.9 - tasklet or workqueue ?

[David M. <Dav...@se...>]

Jivin Eran Ben-Avi lays it down ...
> > Jivin Eran Ben-Avi lays it down ...
> > > Hi,
> > > 
> > > I tested IPSec(tunnel mode) routing performance
> > between 2 GbE ports using packet generator(SMARTBIT)
> >  on ARM 500MHz with latest OCF patched on
> > Openswan2.4.9 and I noticed the callback functions
> > are using workqueue.
> > > Since RX was performed in NAPI mode with higher
> > priority then TX (in workqueue), the callback
> > function(in ipsec_ocf.c) was starved with zero
> > routing.
> > > The problem was solved after I switched to use
> > tasklet instead of the workqueue.
> > > Is there a room for updating next OCF release ?
> > 
> > Sure,  send in a patch. This is against
> > ocf-linux-20070727 right ?
> Yes.
> Can you please estimate when next release will be
> ready?

I can probably do one in about a week (offline next week). I could more
easily drop a diff since the last release if that helps you out.

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 ;-)

Thanks,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] SafeXcel 1141

[David M. <Dav...@se...>]

Jivin Nawang Chhetan lays it down ...
> Hi David,
>           I'll really appreciate if you please tell me whether I am
> committing an elementry mistake here ? If so I'll re-investigate my
> findings.

So for being a bit slow,  I've been a little snowed under for the last 3
weeks.

> On 9/11/07, Nawang Chhetan <naw...@gm...> wrote:
> > Hi David,
> >             Thanks for a prompt reply. I ran the cryptotest program
> > and attached are the results. My observations is that when I run:
> >
> > ./cryptotest i.e small number of packets everything is fine. See
> > cryptotest-1.txt

> >
> > while with
> >
> > ./cryptotest -z i.e. large number of packets.There is a kernal paging error.
> >
> > and Yes error 22 is EINVAL( I forgot to mention).
> > Running openssl ( as suggested in benchmark page ) didn't do any ocf
> > acceleration.  I am using openssl version 0.9.8e (I applied the patch
> > provided by you with the distribution)
> > We need to mention "-engine cryptodev" , but how do we specify the
> > device i.e safe,hifn,cryptosoft etc.

I do that by only loading the driver I wish to test and unloading the
others ;-)

> > I am using kernel version 2.6.16.1 with kernel pre-emption on.

I think I have mentioned this before,  but I have not done any testing
with preemption enabled.  Try with it off just to eliminate that option.

>From the crash it seems like a corruption or timing/alloc/free bug,  so
the preemption is a candidate.  Try it and see :-)

Cheers,
Davidm

> > On 9/11/07, David McCullough <Dav...@se...> wrote:
> > >
> > > Jivin Nawang Chhetan lays it down ...
> > > > Hi David,
> > > >                I just tried the simple ocf-bench test program with
> > > > SafeXcel 1141 card. But all the operations fail.
> > > > I am attaching a tar ball which contains following three files:
> > > > 1. lsmod.txt
> > > > 2. lspci.txt
> > > > 3. ocfbench-dmesg.txt
> > > > with respective details.
> > > >
> > > > Please have a look at them.
> > >
> > > It is possible that ocf-bench is not calling into OCF with parameters
> > > that will work with the safenet.  Pretty sure the error 22 will be an
> > > EINVAL.  Check your errno.h
> > >
> > > Try running cryptotest from user space or "openssl speed" as they are
> > > safe.  If that works I'll look at what could be wrong with ocf-bench.
> > > Examples of running the apps are on:
> > >
> > >         http://ocf-linux.sourceforge.net/benchmarks.html
> > >
> > > Cheers,
> > > Davidm
> > >
> > > > On 9/5/07, David McCullough <Dav...@se...> wrote:
> > > > >
> > > > > Jivin Nawang Chhetan lays it down ...
> > > > > > Hi David,
> > > > > >                I am trying to run "bench-ocf" with safe.ko . I dont
> > > > > > see any debug messages( I insert the modules with debug messages
> > > > > > enabled).  Seems even though open-ssl does all the stuff mentioned in
> > > > > > the script "bench-ocf", 1141 card is not used. Can you give me some
> > > > > > directions here ?
> > > > >
> > > > > Send me the output of:
> > > > >
> > > > >         lsmod
> > > > >
> > > > > If you want to be sure only the safenet driver is used,  make sure that
> > > > > you do not load cryptosoft or any other crypto driver.  Just load:
> > > > >
> > > > >         ocf
> > > > >         safe
> > > > >         cryptodev
> > > > >
> > > > > Cheers,
> > > > > Davidm
> > > > >
> > > > > > On 9/5/07, David McCullough <Dav...@se...> wrote:
> > > > > > >
> > > > > > > Jivin Nawang Chhetan lays it down ...
> > > > > > > > Hi David,
> > > > > > > >                I was testing OCF with SafeXcel 1141 card. Just wanted
> > > > > > > > to know which version of the 1141 card you tested OCF with i.e. REV1
> > > > > > > > or REV1.1.
> > > > > > >
> > > > > > > I think I have used both as I had to work around a bug in version1 IIRC.
> > > > > > > I have also used the 1741.
> > > > > > >
> > > > > > > Note that none of these were cards,  but PCI chips on an embedded board,
> > > > > > > but they look like cards ;-)
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Davidm
> > > > > > >
> > > > > > > --
> > > > > > > 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
> > > > >
> > >
> > >
> > >
> > > --
> > > David McCullough,  dav...@se...,   Ph:+61 734352815
> > > Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com
> > >
> >
> >
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] ocf-bench and safe driver.

[David M. <Dav...@se...>]

Jivin Nawang Chhetan lays it down ...
> Hi David,
>                I started investigating what's going wrong with Ocf's
> SafeXcel driver i.e. safe.I noticed following things:
> 
> 1. safe only accepts crypto operations i.e. cryptop with crp-flags set
> either with CRYPTO_F_SKBUF or CRYPTO_F_IOV .

That is true,  adding support for contiguous buffers should be easy,
especially in the latest version of OCF.

> 2. Neither of the above two flags is set by ocf-bench, therefore the test
> application fails when used with safe driver.
> 
> I have questions regarding above observations:
> 1. I noticed this text in safe /* XXX we don't handle contiguous blocks! */
> safe driver. Why is this so ?

IIRC,  it just hasn't been implemented.  Looking through the code I
can't see any reason it can't be made to work.

> 2. Moreover, why is that only some driver check this flag(in there
> xxxx_process function) and while others don't ?

ixp4xx, safe and hifn all check these flags in various places.  hifn and
ixp4xx just happen to also implement the contiguous buffer options as
well.

It would be very easy to change ocf-bench to use IOV's, alternatively,
it would not be much harder to change safe.c to support contiguous
buffers.

Cheers,
Davidm


-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[Tomasz R. <tro...@pr...>]

Hi,

Did you have a chance to try the intel's ixp400 library newer than 2.1?
Few days ago Intel has released version 3.0 of this lib. The versions 
prior to 2.4 was removed from main download page 
(http://www.intel.com/design/network/products/npfamily/download_ixp400.htm);


Regards,
Tomasz

David McCullough pisze:
> Jivin Tomasz Rostanski lays it down ...
>> Hi,
>>
>> It seems that the crypto_done is never been called, so the loop is 
>> waiting infinitive and the device freezes.
>> So it definitelly could as you have described. However I have checked 
>> the function ixCryptoAccAuthCryptPerform to see if it has changed since 
>> 2.0 version of the library but is exactly the same.
>> I'll try to find what are the differences in crypto part of the library 
>> - maybe there I will find the clue.
> 
> Lets hope.  We have 2.1 running here (not sure if thats in your tree or
> not).  It seems to be behaving so far.  Mostly IXP465 testing though.
> 
>> btw. The ixpCryptoAccCtxRegister failed 6 error I got when I tried to 
>> run this on another board - I have returned to my current one ;)
> 
> Ok,  best I can tell, 6 = ALG unsupported, which doesn't really make
> sense,  but perhaps that helps you.  You can find the enum (grrr enum
> errors) in:
> 
> 	ixp400-1.4/ixp400_xscale_sw/src/include/IxCryptoAcc.h
> 
> Cheers,
> Davidm
> 
>> David McCullough wrote:
>>> Jivin Tomasz Rostanski lays it down ...
>>>> Hi,
>>>>
>>>> I have debug the code a bit and found where the freeze is.
>>>> The waiting code in cryptodev_op is never ending from the while loop:
>>>> do {
>>>> 	wait_event_interruptible(...);
>>>> } while ((crp->crp_flags & CRYPTO_F_DONE) == 0);
>>>>
>>>> When I set the rp->crp_flags to CRYPTO_F_DONE in ixp_q_process before 
>>>> return when status equals to IX_CRYPTO_ACC_STATUS_SUCCESS the freeze is 
>>>> not happening.
>>>> So maybe there is something is wrong with wait_event_interruptible 
>>>> function in my kernel or I don't know.
>>>
>>> We have seen something like this just recently.  A hash of a 0 length
>>> buffer would cause an error and the access lib would not report it,  or
>>> call the callback.
>>>
>>> Any chance you are doing something like this ?
>>>
>>> Setting CRYPTO_F_DONE in ixp_q_process when you get a
>>> IX_CRYPTO_ACC_STATUS_SUCCESS is not good,  you will be returning before
>>> the operation is completed.
>>>
>>> CRYPTO_F_DONE is set by the call to crypto_done,  which happens on error
>>> or when the callback occurs.
>>>
>>> I am guessing you are past this error as well:
>>>
>>> 	"ixpCryptoAccCtxRegister failed 6"
>>>
>>> Cheers,
>>> Davidm
>>>
>>>
>>>> David McCullough napisa?(a):
>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>> Hi,
>>>>>>
>>>>>>>> I have checked the latest ixp400 access lib (2.4) and ixp_400 
>>>>>>>> ethernet driver (1.7). I didn't use the Intel patches for crypto 
>>>>>>>> initialization in ixp400_eth.
>>>>>>>> The result is still the same - the device freezes when I run openssl 
>>>>>>>> or ssh.
>>>>>>>> I'm having microcode compiled in driver - load it from file to 
>>>>>>>> /dev/ixNpe, so I have recompiled it and load the microcode from file 
>>>>>>>> but this didn't make any difference.
>>>>>>> Are you using the "crypto version" of the access library ?
>>>>>> Yes, I'm using the crypto version of the library.
>>>>>>
>>>>>>>> Could this issue be related with the hardware? I'm using the 
>>>>>>>> AirTegrity box which was designed completely by them and not uses 
>>>>>>>> redboot bootloader but their own one. Could it be the reason of the 
>>>>>>>> problem I'm having?
>>>>>>> No,  we do the same,  it has no bearing on how the NPE's do their 
>>>>>>> thing.
>>>>>>>
>>>>>>> Are you loading the correct NPE code (with crypto support etc).
>>>>>> Normally I have NPE code compiled in the sources. I'm using the version 
>>>>>> with crypto support so it should be ok.
>>>>> ok.
>>>>>
>>>>>>>> I'll give a try on Gateworks GW2347 and see if it will be working as 
>>>>>>>> it should or not.
>>>>>> Ok, I have a problem with initialization crypto on the gw2347 - the 
>>>>>> message:
>>>>>> "ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
>>>>> Thats sounds weird.  It sounds like the crypto isn't working properly
>>>>> for some reason.
>>>>>
>>>>> ixpCryptoAccCtxRegister doesn't need much to work.
>>>>>
>>>>>> checked and the ixp4xx module when loading returns the error that 
>>>>>> cannot initialize crypto.
>>>>> That is ok,  if the network driver init's the crypto then you will get
>>>>> this error since we cannot tell that it has been done,  yet it returns a
>>>>> fail if it is already initted.
>>>>>
>>>>> Might be worth checking the details of the error.
>>>>>
>>>>> Cheers,
>>>>> Davidm
>>>>>
>>>>>>>> David McCullough napisa?(a):
>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> Which access library version are you using ?
>>>>>>>>>> The full name is ixp400accesslibrarywithcrypto-2.3.1
>>>>>>>>> Ok,  not sure we have tested OCF with version 2.3 of the access lib.
>>>>>>>>> It is part of our tree so I will try it.
>>>>>>>>>
>>>>>>>>> Not sure you mentioned which sources you are using,  but the
>>>>>>>>> uClinux-dist or SnapGear dists have very good IXP425 support
>>>>>>>>> and less patching ;-)
>>>>>>>>>
>>>>>>>>>>> Can you load ocf, cryptodev and ixp4xx all with debug enabled:
>>>>>>>>>>>
>>>>>>>>>>> 	modprobe ocf crypto_debug=1
>>>>>>>>>>> 	modprobe cryptodev cryptodev_debug=1
>>>>>>>>>>> 	modprobe ixp4xx ixp_debug=1
>>>>>>>>>>>
>>>>>>>>>>> The run the test, capture all the console output and send me a copy
>>>>>>>>>>> for reference.
>>>>>>>>>> The output is attached (ocf.log).
>>>>>>>>> Ok,  I will try and get some time on it in the next day or so, 
>>>>>>>>> thanks.
>>>>>>>>>
>>>>>>>>> Actually,  just had a quick look,  I think the access lib is blowing 
>>>>>>>>> the
>>>>>>>>> stack.  It is renowned for doing this.
>>>>>>>>>
>>>>>>>>> If you can try increasing the kernel stack size to 8K if it isn't
>>>>>>>>> already it might help.
>>>>>>>>>
>>>>>>>>> Otherwise,  you may find the info to fix it in our access lib patch:
>>>>>>>>>
>>>>>>>>> 	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
>>>>>>>>>
>>>>>>>>> Or perhaps try the Snapgear/uClinux-dist if you have time.  We have 
>>>>>>>>> all
>>>>>>>>> these sort or problems sorted already ;-)
>>>>>>>>>
>>>>>>>>>>> Have you tried turning off preemption ?  I don't think I have ever
>>>>>>>>>>> tested with that.
>>>>>>>>>> Yes, I have tried but didn't help :(
>>>>>>>>> Oh well,  looks like a real bug then ;-)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Davidm
>>>>>>>>>
>>>>>>>>>>>> David McCullough napisa?(a):
>>>>>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried using ixp4xx module for hardware crypto on my ixp425 
>>>>>>>>>>>>>> device with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using 
>>>>>>>>>>>>>> ixp400 access library with crypto in version 2.3.1 and 
>>>>>>>>>>>>>> ixp400_eth driver in version 1.6 (with Intel's patch for OCF 
>>>>>>>>>>>>>> support - 
>>>>>>>>>>>>>> http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm loading the modules like described in Intel readme:
>>>>>>>>>>>>>> mknod /dev/crypto c 10 70
>>>>>>>>>>>>>> mknod -m 666 /dev/ixNpe c 241 0
>>>>>>>>>>>>>> modprobe ixp400 >/dev/null 2>/dev/null
>>>>>>>>>>>>>> modprobe ixp400_eth >/dev/null 2>/dev/null
>>>>>>>>>>>>>> modprobe ocf
>>>>>>>>>>>>>> modprobe cryptodev
>>>>>>>>>>>>>> modprobe ixp4xx ixp_init_crypto=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then when I run the: openssl speed -elapsed -evp des-ede3-cbc 
>>>>>>>>>>>>>> -cpu -engine cryptodev the device hangs (I'm using 
>>>>>>>>>>>>>> openssl-0.9.8a patched for OCF). The same happend when I tried 
>>>>>>>>>>>>>> to connect from the device using ssh.
>>>>>>>>>>>>>> I have enabled debugging and saw that the debugging from 
>>>>>>>>>>>>>> ixp_q_process is the last one displayed. So I have started 
>>>>>>>>>>>>>> adding some debug messages to that function and found that the 
>>>>>>>>>>>>>> hand appears after the following code:
>>>>>>>>>>>>>> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
>>>>>>>>>>>>>> 	return;
>>>>>>>>>>>>>> So I have changed return to goto done and check what will 
>>>>>>>>>>>>>> happen - this time the openssl didn't hang and did it's work. 
>>>>>>>>>>>>>> But the ssh is not working - displays evp_crypt: EVP_Cipher 
>>>>>>>>>>>>>> failed and exits.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have tried the cryptosoft module instead of ixp4xx and this 
>>>>>>>>>>>>>> one works without any problems, so it seems that some problem 
>>>>>>>>>>>>>> exists in ixp4xx module.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have any clue what could be wrong? I'm almost sure that 
>>>>>>>>>>>>>> someday on older kernel (2.6.12) I got ixp4xx working without 
>>>>>>>>>>>>>> problems.
>>>>>>>>>>>>> You might want to try incorporating the latest code from the 
>>>>>>>>>>>>> sourceforge
>>>>>>>>>>>>> site.  I haven't seen a like up like you describe on the ixp for 
>>>>>>>>>>>>> a long
>>>>>>>>>>>>> time and I don't know exactly everything that is in the Intel 
>>>>>>>>>>>>> patches.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try out the latest download at:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	ocf-linux.sourceforge.net
>>>>>>>>>>>>>
>>>>>>>>>>>>> and then it will be much easier for me to help you.  I run IXP 
>>>>>>>>>>>>> boards
>>>>>>>>>>>>> here and can easily try some things,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Davidm
>>>>>>>>>>>>>
> 

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[Tomasz R. <tro...@pr...>]

David,

I have also noticed that the ixp_process_pending have only one element 
on the list. This function is run only once. Is it normal behaviour or not?
I have add a call to crypto_done just before the end of the function but 
I got no change at all - as openssl was freezing still is freezing.
If you have any clue or idea which piece of code should I debug closer 
please let me know.

Thanks,
Tomasz

David McCullough pisze:
> Jivin Tomasz Rostanski lays it down ...
>> Hi,
>>
>> It seems that the crypto_done is never been called, so the loop is 
>> waiting infinitive and the device freezes.
>> So it definitelly could as you have described. However I have checked 
>> the function ixCryptoAccAuthCryptPerform to see if it has changed since 
>> 2.0 version of the library but is exactly the same.
>> I'll try to find what are the differences in crypto part of the library 
>> - maybe there I will find the clue.
> 
> Lets hope.  We have 2.1 running here (not sure if thats in your tree or
> not).  It seems to be behaving so far.  Mostly IXP465 testing though.
> 
>> btw. The ixpCryptoAccCtxRegister failed 6 error I got when I tried to 
>> run this on another board - I have returned to my current one ;)
> 
> Ok,  best I can tell, 6 = ALG unsupported, which doesn't really make
> sense,  but perhaps that helps you.  You can find the enum (grrr enum
> errors) in:
> 
> 	ixp400-1.4/ixp400_xscale_sw/src/include/IxCryptoAcc.h
> 
> Cheers,
> Davidm
> 
>> David McCullough wrote:
>>> Jivin Tomasz Rostanski lays it down ...
>>>> Hi,
>>>>
>>>> I have debug the code a bit and found where the freeze is.
>>>> The waiting code in cryptodev_op is never ending from the while loop:
>>>> do {
>>>> 	wait_event_interruptible(...);
>>>> } while ((crp->crp_flags & CRYPTO_F_DONE) == 0);
>>>>
>>>> When I set the rp->crp_flags to CRYPTO_F_DONE in ixp_q_process before 
>>>> return when status equals to IX_CRYPTO_ACC_STATUS_SUCCESS the freeze is 
>>>> not happening.
>>>> So maybe there is something is wrong with wait_event_interruptible 
>>>> function in my kernel or I don't know.
>>>
>>> We have seen something like this just recently.  A hash of a 0 length
>>> buffer would cause an error and the access lib would not report it,  or
>>> call the callback.
>>>
>>> Any chance you are doing something like this ?
>>>
>>> Setting CRYPTO_F_DONE in ixp_q_process when you get a
>>> IX_CRYPTO_ACC_STATUS_SUCCESS is not good,  you will be returning before
>>> the operation is completed.
>>>
>>> CRYPTO_F_DONE is set by the call to crypto_done,  which happens on error
>>> or when the callback occurs.
>>>
>>> I am guessing you are past this error as well:
>>>
>>> 	"ixpCryptoAccCtxRegister failed 6"
>>>
>>> Cheers,
>>> Davidm
>>>
>>>
>>>> David McCullough napisa?(a):
>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>> Hi,
>>>>>>
>>>>>>>> I have checked the latest ixp400 access lib (2.4) and ixp_400 
>>>>>>>> ethernet driver (1.7). I didn't use the Intel patches for crypto 
>>>>>>>> initialization in ixp400_eth.
>>>>>>>> The result is still the same - the device freezes when I run openssl 
>>>>>>>> or ssh.
>>>>>>>> I'm having microcode compiled in driver - load it from file to 
>>>>>>>> /dev/ixNpe, so I have recompiled it and load the microcode from file 
>>>>>>>> but this didn't make any difference.
>>>>>>> Are you using the "crypto version" of the access library ?
>>>>>> Yes, I'm using the crypto version of the library.
>>>>>>
>>>>>>>> Could this issue be related with the hardware? I'm using the 
>>>>>>>> AirTegrity box which was designed completely by them and not uses 
>>>>>>>> redboot bootloader but their own one. Could it be the reason of the 
>>>>>>>> problem I'm having?
>>>>>>> No,  we do the same,  it has no bearing on how the NPE's do their 
>>>>>>> thing.
>>>>>>>
>>>>>>> Are you loading the correct NPE code (with crypto support etc).
>>>>>> Normally I have NPE code compiled in the sources. I'm using the version 
>>>>>> with crypto support so it should be ok.
>>>>> ok.
>>>>>
>>>>>>>> I'll give a try on Gateworks GW2347 and see if it will be working as 
>>>>>>>> it should or not.
>>>>>> Ok, I have a problem with initialization crypto on the gw2347 - the 
>>>>>> message:
>>>>>> "ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
>>>>> Thats sounds weird.  It sounds like the crypto isn't working properly
>>>>> for some reason.
>>>>>
>>>>> ixpCryptoAccCtxRegister doesn't need much to work.
>>>>>
>>>>>> checked and the ixp4xx module when loading returns the error that 
>>>>>> cannot initialize crypto.
>>>>> That is ok,  if the network driver init's the crypto then you will get
>>>>> this error since we cannot tell that it has been done,  yet it returns a
>>>>> fail if it is already initted.
>>>>>
>>>>> Might be worth checking the details of the error.
>>>>>
>>>>> Cheers,
>>>>> Davidm
>>>>>
>>>>>>>> David McCullough napisa?(a):
>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> Which access library version are you using ?
>>>>>>>>>> The full name is ixp400accesslibrarywithcrypto-2.3.1
>>>>>>>>> Ok,  not sure we have tested OCF with version 2.3 of the access lib.
>>>>>>>>> It is part of our tree so I will try it.
>>>>>>>>>
>>>>>>>>> Not sure you mentioned which sources you are using,  but the
>>>>>>>>> uClinux-dist or SnapGear dists have very good IXP425 support
>>>>>>>>> and less patching ;-)
>>>>>>>>>
>>>>>>>>>>> Can you load ocf, cryptodev and ixp4xx all with debug enabled:
>>>>>>>>>>>
>>>>>>>>>>> 	modprobe ocf crypto_debug=1
>>>>>>>>>>> 	modprobe cryptodev cryptodev_debug=1
>>>>>>>>>>> 	modprobe ixp4xx ixp_debug=1
>>>>>>>>>>>
>>>>>>>>>>> The run the test, capture all the console output and send me a copy
>>>>>>>>>>> for reference.
>>>>>>>>>> The output is attached (ocf.log).
>>>>>>>>> Ok,  I will try and get some time on it in the next day or so, 
>>>>>>>>> thanks.
>>>>>>>>>
>>>>>>>>> Actually,  just had a quick look,  I think the access lib is blowing 
>>>>>>>>> the
>>>>>>>>> stack.  It is renowned for doing this.
>>>>>>>>>
>>>>>>>>> If you can try increasing the kernel stack size to 8K if it isn't
>>>>>>>>> already it might help.
>>>>>>>>>
>>>>>>>>> Otherwise,  you may find the info to fix it in our access lib patch:
>>>>>>>>>
>>>>>>>>> 	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
>>>>>>>>>
>>>>>>>>> Or perhaps try the Snapgear/uClinux-dist if you have time.  We have 
>>>>>>>>> all
>>>>>>>>> these sort or problems sorted already ;-)
>>>>>>>>>
>>>>>>>>>>> Have you tried turning off preemption ?  I don't think I have ever
>>>>>>>>>>> tested with that.
>>>>>>>>>> Yes, I have tried but didn't help :(
>>>>>>>>> Oh well,  looks like a real bug then ;-)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Davidm
>>>>>>>>>
>>>>>>>>>>>> David McCullough napisa?(a):
>>>>>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried using ixp4xx module for hardware crypto on my ixp425 
>>>>>>>>>>>>>> device with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using 
>>>>>>>>>>>>>> ixp400 access library with crypto in version 2.3.1 and 
>>>>>>>>>>>>>> ixp400_eth driver in version 1.6 (with Intel's patch for OCF 
>>>>>>>>>>>>>> support - 
>>>>>>>>>>>>>> http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm loading the modules like described in Intel readme:
>>>>>>>>>>>>>> mknod /dev/crypto c 10 70
>>>>>>>>>>>>>> mknod -m 666 /dev/ixNpe c 241 0
>>>>>>>>>>>>>> modprobe ixp400 >/dev/null 2>/dev/null
>>>>>>>>>>>>>> modprobe ixp400_eth >/dev/null 2>/dev/null
>>>>>>>>>>>>>> modprobe ocf
>>>>>>>>>>>>>> modprobe cryptodev
>>>>>>>>>>>>>> modprobe ixp4xx ixp_init_crypto=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then when I run the: openssl speed -elapsed -evp des-ede3-cbc 
>>>>>>>>>>>>>> -cpu -engine cryptodev the device hangs (I'm using 
>>>>>>>>>>>>>> openssl-0.9.8a patched for OCF). The same happend when I tried 
>>>>>>>>>>>>>> to connect from the device using ssh.
>>>>>>>>>>>>>> I have enabled debugging and saw that the debugging from 
>>>>>>>>>>>>>> ixp_q_process is the last one displayed. So I have started 
>>>>>>>>>>>>>> adding some debug messages to that function and found that the 
>>>>>>>>>>>>>> hand appears after the following code:
>>>>>>>>>>>>>> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
>>>>>>>>>>>>>> 	return;
>>>>>>>>>>>>>> So I have changed return to goto done and check what will 
>>>>>>>>>>>>>> happen - this time the openssl didn't hang and did it's work. 
>>>>>>>>>>>>>> But the ssh is not working - displays evp_crypt: EVP_Cipher 
>>>>>>>>>>>>>> failed and exits.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have tried the cryptosoft module instead of ixp4xx and this 
>>>>>>>>>>>>>> one works without any problems, so it seems that some problem 
>>>>>>>>>>>>>> exists in ixp4xx module.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have any clue what could be wrong? I'm almost sure that 
>>>>>>>>>>>>>> someday on older kernel (2.6.12) I got ixp4xx working without 
>>>>>>>>>>>>>> problems.
>>>>>>>>>>>>> You might want to try incorporating the latest code from the 
>>>>>>>>>>>>> sourceforge
>>>>>>>>>>>>> site.  I haven't seen a like up like you describe on the ixp for 
>>>>>>>>>>>>> a long
>>>>>>>>>>>>> time and I don't know exactly everything that is in the Intel 
>>>>>>>>>>>>> patches.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try out the latest download at:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 	ocf-linux.sourceforge.net
>>>>>>>>>>>>>
>>>>>>>>>>>>> and then it will be much easier for me to help you.  I run IXP 
>>>>>>>>>>>>> boards
>>>>>>>>>>>>> here and can easily try some things,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Davidm
>>>>>>>>>>>>>
> 

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[David M. <Dav...@se...>]

Jivin Tomasz Rostanski lays it down ...
> Hi,
> 
> It seems that the crypto_done is never been called, so the loop is 
> waiting infinitive and the device freezes.
> So it definitelly could as you have described. However I have checked 
> the function ixCryptoAccAuthCryptPerform to see if it has changed since 
> 2.0 version of the library but is exactly the same.
> I'll try to find what are the differences in crypto part of the library 
> - maybe there I will find the clue.

Lets hope.  We have 2.1 running here (not sure if thats in your tree or
not).  It seems to be behaving so far.  Mostly IXP465 testing though.

> btw. The ixpCryptoAccCtxRegister failed 6 error I got when I tried to 
> run this on another board - I have returned to my current one ;)

Ok,  best I can tell, 6 = ALG unsupported, which doesn't really make
sense,  but perhaps that helps you.  You can find the enum (grrr enum
errors) in:

	ixp400-1.4/ixp400_xscale_sw/src/include/IxCryptoAcc.h

Cheers,
Davidm

> David McCullough wrote:
> >Jivin Tomasz Rostanski lays it down ...
> >>Hi,
> >>
> >>I have debug the code a bit and found where the freeze is.
> >>The waiting code in cryptodev_op is never ending from the while loop:
> >>do {
> >>	wait_event_interruptible(...);
> >>} while ((crp->crp_flags & CRYPTO_F_DONE) == 0);
> >>
> >>When I set the rp->crp_flags to CRYPTO_F_DONE in ixp_q_process before 
> >>return when status equals to IX_CRYPTO_ACC_STATUS_SUCCESS the freeze is 
> >>not happening.
> >>So maybe there is something is wrong with wait_event_interruptible 
> >>function in my kernel or I don't know.
> >
> >
> >We have seen something like this just recently.  A hash of a 0 length
> >buffer would cause an error and the access lib would not report it,  or
> >call the callback.
> >
> >Any chance you are doing something like this ?
> >
> >Setting CRYPTO_F_DONE in ixp_q_process when you get a
> >IX_CRYPTO_ACC_STATUS_SUCCESS is not good,  you will be returning before
> >the operation is completed.
> >
> >CRYPTO_F_DONE is set by the call to crypto_done,  which happens on error
> >or when the callback occurs.
> >
> >I am guessing you are past this error as well:
> >
> >	"ixpCryptoAccCtxRegister failed 6"
> >
> >Cheers,
> >Davidm
> >
> >
> >>David McCullough napisa?(a):
> >>>Jivin Tomasz Rostanski lays it down ...
> >>>>Hi,
> >>>>
> >>>>>>I have checked the latest ixp400 access lib (2.4) and ixp_400 
> >>>>>>ethernet driver (1.7). I didn't use the Intel patches for crypto 
> >>>>>>initialization in ixp400_eth.
> >>>>>>The result is still the same - the device freezes when I run openssl 
> >>>>>>or ssh.
> >>>>>>I'm having microcode compiled in driver - load it from file to 
> >>>>>>/dev/ixNpe, so I have recompiled it and load the microcode from file 
> >>>>>>but this didn't make any difference.
> >>>>>Are you using the "crypto version" of the access library ?
> >>>>Yes, I'm using the crypto version of the library.
> >>>>
> >>>>>>Could this issue be related with the hardware? I'm using the 
> >>>>>>AirTegrity box which was designed completely by them and not uses 
> >>>>>>redboot bootloader but their own one. Could it be the reason of the 
> >>>>>>problem I'm having?
> >>>>>No,  we do the same,  it has no bearing on how the NPE's do their 
> >>>>>thing.
> >>>>>
> >>>>>Are you loading the correct NPE code (with crypto support etc).
> >>>>Normally I have NPE code compiled in the sources. I'm using the version 
> >>>>with crypto support so it should be ok.
> >>>ok.
> >>>
> >>>>>>I'll give a try on Gateworks GW2347 and see if it will be working as 
> >>>>>>it should or not.
> >>>>Ok, I have a problem with initialization crypto on the gw2347 - the 
> >>>>message:
> >>>>"ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
> >>>Thats sounds weird.  It sounds like the crypto isn't working properly
> >>>for some reason.
> >>>
> >>>ixpCryptoAccCtxRegister doesn't need much to work.
> >>>
> >>>>checked and the ixp4xx module when loading returns the error that 
> >>>>cannot initialize crypto.
> >>>That is ok,  if the network driver init's the crypto then you will get
> >>>this error since we cannot tell that it has been done,  yet it returns a
> >>>fail if it is already initted.
> >>>
> >>>Might be worth checking the details of the error.
> >>>
> >>>Cheers,
> >>>Davidm
> >>>
> >>>>>>David McCullough napisa?(a):
> >>>>>>>Jivin Tomasz Rostanski lays it down ...
> >>>>>>>>Hi,
> >>>>>>>>
> >>>>>>>>>Which access library version are you using ?
> >>>>>>>>The full name is ixp400accesslibrarywithcrypto-2.3.1
> >>>>>>>Ok,  not sure we have tested OCF with version 2.3 of the access lib.
> >>>>>>>It is part of our tree so I will try it.
> >>>>>>>
> >>>>>>>Not sure you mentioned which sources you are using,  but the
> >>>>>>>uClinux-dist or SnapGear dists have very good IXP425 support
> >>>>>>>and less patching ;-)
> >>>>>>>
> >>>>>>>>>Can you load ocf, cryptodev and ixp4xx all with debug enabled:
> >>>>>>>>>
> >>>>>>>>>	modprobe ocf crypto_debug=1
> >>>>>>>>>	modprobe cryptodev cryptodev_debug=1
> >>>>>>>>>	modprobe ixp4xx ixp_debug=1
> >>>>>>>>>
> >>>>>>>>>The run the test, capture all the console output and send me a copy
> >>>>>>>>>for reference.
> >>>>>>>>The output is attached (ocf.log).
> >>>>>>>Ok,  I will try and get some time on it in the next day or so, 
> >>>>>>>thanks.
> >>>>>>>
> >>>>>>>Actually,  just had a quick look,  I think the access lib is blowing 
> >>>>>>>the
> >>>>>>>stack.  It is renowned for doing this.
> >>>>>>>
> >>>>>>>If you can try increasing the kernel stack size to 8K if it isn't
> >>>>>>>already it might help.
> >>>>>>>
> >>>>>>>Otherwise,  you may find the info to fix it in our access lib patch:
> >>>>>>>
> >>>>>>>	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
> >>>>>>>
> >>>>>>>Or perhaps try the Snapgear/uClinux-dist if you have time.  We have 
> >>>>>>>all
> >>>>>>>these sort or problems sorted already ;-)
> >>>>>>>
> >>>>>>>>>Have you tried turning off preemption ?  I don't think I have ever
> >>>>>>>>>tested with that.
> >>>>>>>>Yes, I have tried but didn't help :(
> >>>>>>>Oh well,  looks like a real bug then ;-)
> >>>>>>>
> >>>>>>>Cheers,
> >>>>>>>Davidm
> >>>>>>>
> >>>>>>>>>>David McCullough napisa?(a):
> >>>>>>>>>>>Jivin Tomasz Rostanski lays it down ...
> >>>>>>>>>>>>Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>>I tried using ixp4xx module for hardware crypto on my ixp425 
> >>>>>>>>>>>>device with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using 
> >>>>>>>>>>>>ixp400 access library with crypto in version 2.3.1 and 
> >>>>>>>>>>>>ixp400_eth driver in version 1.6 (with Intel's patch for OCF 
> >>>>>>>>>>>>support - 
> >>>>>>>>>>>>http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
> >>>>>>>>>>>>
> >>>>>>>>>>>>I'm loading the modules like described in Intel readme:
> >>>>>>>>>>>>mknod /dev/crypto c 10 70
> >>>>>>>>>>>>mknod -m 666 /dev/ixNpe c 241 0
> >>>>>>>>>>>>modprobe ixp400 >/dev/null 2>/dev/null
> >>>>>>>>>>>>modprobe ixp400_eth >/dev/null 2>/dev/null
> >>>>>>>>>>>>modprobe ocf
> >>>>>>>>>>>>modprobe cryptodev
> >>>>>>>>>>>>modprobe ixp4xx ixp_init_crypto=0
> >>>>>>>>>>>>
> >>>>>>>>>>>>Then when I run the: openssl speed -elapsed -evp des-ede3-cbc 
> >>>>>>>>>>>>-cpu -engine cryptodev the device hangs (I'm using 
> >>>>>>>>>>>>openssl-0.9.8a patched for OCF). The same happend when I tried 
> >>>>>>>>>>>>to connect from the device using ssh.
> >>>>>>>>>>>>I have enabled debugging and saw that the debugging from 
> >>>>>>>>>>>>ixp_q_process is the last one displayed. So I have started 
> >>>>>>>>>>>>adding some debug messages to that function and found that the 
> >>>>>>>>>>>>hand appears after the following code:
> >>>>>>>>>>>>if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
> >>>>>>>>>>>>	return;
> >>>>>>>>>>>>So I have changed return to goto done and check what will 
> >>>>>>>>>>>>happen - this time the openssl didn't hang and did it's work. 
> >>>>>>>>>>>>But the ssh is not working - displays evp_crypt: EVP_Cipher 
> >>>>>>>>>>>>failed and exits.
> >>>>>>>>>>>>
> >>>>>>>>>>>>I have tried the cryptosoft module instead of ixp4xx and this 
> >>>>>>>>>>>>one works without any problems, so it seems that some problem 
> >>>>>>>>>>>>exists in ixp4xx module.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Do you have any clue what could be wrong? I'm almost sure that 
> >>>>>>>>>>>>someday on older kernel (2.6.12) I got ixp4xx working without 
> >>>>>>>>>>>>problems.
> >>>>>>>>>>>You might want to try incorporating the latest code from the 
> >>>>>>>>>>>sourceforge
> >>>>>>>>>>>site.  I haven't seen a like up like you describe on the ixp for 
> >>>>>>>>>>>a long
> >>>>>>>>>>>time and I don't know exactly everything that is in the Intel 
> >>>>>>>>>>>patches.
> >>>>>>>>>>>
> >>>>>>>>>>>Try out the latest download at:
> >>>>>>>>>>>
> >>>>>>>>>>>	ocf-linux.sourceforge.net
> >>>>>>>>>>>
> >>>>>>>>>>>and then it will be much easier for me to help you.  I run IXP 
> >>>>>>>>>>>boards
> >>>>>>>>>>>here and can easily try some things,
> >>>>>>>>>>>
> >>>>>>>>>>>Cheers,
> >>>>>>>>>>>Davidm
> >>>>>>>>>>>
> >>
> >
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[Tomasz R. <tro...@pr...>]

Hi,

It seems that the crypto_done is never been called, so the loop is 
waiting infinitive and the device freezes.
So it definitelly could as you have described. However I have checked 
the function ixCryptoAccAuthCryptPerform to see if it has changed since 
2.0 version of the library but is exactly the same.
I'll try to find what are the differences in crypto part of the library 
- maybe there I will find the clue.

Tomasz

btw. The ixpCryptoAccCtxRegister failed 6 error I got when I tried to 
run this on another board - I have returned to my current one ;)

David McCullough wrote:
> Jivin Tomasz Rostanski lays it down ...
>> Hi,
>>
>> I have debug the code a bit and found where the freeze is.
>> The waiting code in cryptodev_op is never ending from the while loop:
>> do {
>> 	wait_event_interruptible(...);
>> } while ((crp->crp_flags & CRYPTO_F_DONE) == 0);
>>
>> When I set the rp->crp_flags to CRYPTO_F_DONE in ixp_q_process before 
>> return when status equals to IX_CRYPTO_ACC_STATUS_SUCCESS the freeze is 
>> not happening.
>> So maybe there is something is wrong with wait_event_interruptible 
>> function in my kernel or I don't know.
> 
> 
> We have seen something like this just recently.  A hash of a 0 length
> buffer would cause an error and the access lib would not report it,  or
> call the callback.
> 
> Any chance you are doing something like this ?
> 
> Setting CRYPTO_F_DONE in ixp_q_process when you get a
> IX_CRYPTO_ACC_STATUS_SUCCESS is not good,  you will be returning before
> the operation is completed.
> 
> CRYPTO_F_DONE is set by the call to crypto_done,  which happens on error
> or when the callback occurs.
> 
> I am guessing you are past this error as well:
> 
> 	"ixpCryptoAccCtxRegister failed 6"
> 
> Cheers,
> Davidm
> 
> 
>> David McCullough napisa?(a):
>>> Jivin Tomasz Rostanski lays it down ...
>>>> Hi,
>>>>
>>>>>> I have checked the latest ixp400 access lib (2.4) and ixp_400 ethernet 
>>>>>> driver (1.7). I didn't use the Intel patches for crypto initialization 
>>>>>> in ixp400_eth.
>>>>>> The result is still the same - the device freezes when I run openssl or 
>>>>>> ssh.
>>>>>> I'm having microcode compiled in driver - load it from file to 
>>>>>> /dev/ixNpe, so I have recompiled it and load the microcode from file 
>>>>>> but this didn't make any difference.
>>>>> Are you using the "crypto version" of the access library ?
>>>> Yes, I'm using the crypto version of the library.
>>>>
>>>>>> Could this issue be related with the hardware? I'm using the AirTegrity 
>>>>>> box which was designed completely by them and not uses redboot 
>>>>>> bootloader but their own one. Could it be the reason of the problem I'm 
>>>>>> having?
>>>>> No,  we do the same,  it has no bearing on how the NPE's do their thing.
>>>>>
>>>>> Are you loading the correct NPE code (with crypto support etc).
>>>> Normally I have NPE code compiled in the sources. I'm using the version 
>>>> with crypto support so it should be ok.
>>> ok.
>>>
>>>>>> I'll give a try on Gateworks GW2347 and see if it will be working as it 
>>>>>> should or not.
>>>> Ok, I have a problem with initialization crypto on the gw2347 - the 
>>>> message:
>>>> "ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
>>> Thats sounds weird.  It sounds like the crypto isn't working properly
>>> for some reason.
>>>
>>> ixpCryptoAccCtxRegister doesn't need much to work.
>>>
>>>> checked and the ixp4xx module when loading returns the error that cannot 
>>>> initialize crypto.
>>> That is ok,  if the network driver init's the crypto then you will get
>>> this error since we cannot tell that it has been done,  yet it returns a
>>> fail if it is already initted.
>>>
>>> Might be worth checking the details of the error.
>>>
>>> Cheers,
>>> Davidm
>>>
>>>>>> David McCullough napisa?(a):
>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> Which access library version are you using ?
>>>>>>>> The full name is ixp400accesslibrarywithcrypto-2.3.1
>>>>>>> Ok,  not sure we have tested OCF with version 2.3 of the access lib.
>>>>>>> It is part of our tree so I will try it.
>>>>>>>
>>>>>>> Not sure you mentioned which sources you are using,  but the
>>>>>>> uClinux-dist or SnapGear dists have very good IXP425 support
>>>>>>> and less patching ;-)
>>>>>>>
>>>>>>>>> Can you load ocf, cryptodev and ixp4xx all with debug enabled:
>>>>>>>>>
>>>>>>>>> 	modprobe ocf crypto_debug=1
>>>>>>>>> 	modprobe cryptodev cryptodev_debug=1
>>>>>>>>> 	modprobe ixp4xx ixp_debug=1
>>>>>>>>>
>>>>>>>>> The run the test, capture all the console output and send me a copy
>>>>>>>>> for reference.
>>>>>>>> The output is attached (ocf.log).
>>>>>>> Ok,  I will try and get some time on it in the next day or so, thanks.
>>>>>>>
>>>>>>> Actually,  just had a quick look,  I think the access lib is blowing 
>>>>>>> the
>>>>>>> stack.  It is renowned for doing this.
>>>>>>>
>>>>>>> If you can try increasing the kernel stack size to 8K if it isn't
>>>>>>> already it might help.
>>>>>>>
>>>>>>> Otherwise,  you may find the info to fix it in our access lib patch:
>>>>>>>
>>>>>>> 	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
>>>>>>>
>>>>>>> Or perhaps try the Snapgear/uClinux-dist if you have time.  We have all
>>>>>>> these sort or problems sorted already ;-)
>>>>>>>
>>>>>>>>> Have you tried turning off preemption ?  I don't think I have ever
>>>>>>>>> tested with that.
>>>>>>>> Yes, I have tried but didn't help :(
>>>>>>> Oh well,  looks like a real bug then ;-)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Davidm
>>>>>>>
>>>>>>>>>> David McCullough napisa?(a):
>>>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I tried using ixp4xx module for hardware crypto on my ixp425 
>>>>>>>>>>>> device with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using ixp400 
>>>>>>>>>>>> access library with crypto in version 2.3.1 and ixp400_eth driver 
>>>>>>>>>>>> in version 1.6 (with Intel's patch for OCF support - 
>>>>>>>>>>>> http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
>>>>>>>>>>>>
>>>>>>>>>>>> I'm loading the modules like described in Intel readme:
>>>>>>>>>>>> mknod /dev/crypto c 10 70
>>>>>>>>>>>> mknod -m 666 /dev/ixNpe c 241 0
>>>>>>>>>>>> modprobe ixp400 >/dev/null 2>/dev/null
>>>>>>>>>>>> modprobe ixp400_eth >/dev/null 2>/dev/null
>>>>>>>>>>>> modprobe ocf
>>>>>>>>>>>> modprobe cryptodev
>>>>>>>>>>>> modprobe ixp4xx ixp_init_crypto=0
>>>>>>>>>>>>
>>>>>>>>>>>> Then when I run the: openssl speed -elapsed -evp des-ede3-cbc 
>>>>>>>>>>>> -cpu -engine cryptodev the device hangs (I'm using openssl-0.9.8a 
>>>>>>>>>>>> patched for OCF). The same happend when I tried to connect from 
>>>>>>>>>>>> the device using ssh.
>>>>>>>>>>>> I have enabled debugging and saw that the debugging from 
>>>>>>>>>>>> ixp_q_process is the last one displayed. So I have started adding 
>>>>>>>>>>>> some debug messages to that function and found that the hand 
>>>>>>>>>>>> appears after the following code:
>>>>>>>>>>>> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
>>>>>>>>>>>> 	return;
>>>>>>>>>>>> So I have changed return to goto done and check what will happen 
>>>>>>>>>>>> - this time the openssl didn't hang and did it's work. But the 
>>>>>>>>>>>> ssh is not working - displays evp_crypt: EVP_Cipher failed and 
>>>>>>>>>>>> exits.
>>>>>>>>>>>>
>>>>>>>>>>>> I have tried the cryptosoft module instead of ixp4xx and this one 
>>>>>>>>>>>> works without any problems, so it seems that some problem exists 
>>>>>>>>>>>> in ixp4xx module.
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have any clue what could be wrong? I'm almost sure that 
>>>>>>>>>>>> someday on older kernel (2.6.12) I got ixp4xx working without 
>>>>>>>>>>>> problems.
>>>>>>>>>>> You might want to try incorporating the latest code from the 
>>>>>>>>>>> sourceforge
>>>>>>>>>>> site.  I haven't seen a like up like you describe on the ixp for a 
>>>>>>>>>>> long
>>>>>>>>>>> time and I don't know exactly everything that is in the Intel 
>>>>>>>>>>> patches.
>>>>>>>>>>>
>>>>>>>>>>> Try out the latest download at:
>>>>>>>>>>>
>>>>>>>>>>> 	ocf-linux.sourceforge.net
>>>>>>>>>>>
>>>>>>>>>>> and then it will be much easier for me to help you.  I run IXP 
>>>>>>>>>>> boards
>>>>>>>>>>> here and can easily try some things,
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Davidm
>>>>>>>>>>>
>>
> 

Re: [Ocf-linux-users] Openswan 2.4.9 - tasklet or workqueue ?

[David M. <Dav...@se...>]

Jivin Kabir Ahsan-r9aahw lays it down ...
> We can also do direct function call of ipsec_xsm or ipsec_rsm instead
> of using tasklet. 

Care to come up with something that still works for 2.4 but it targetted
more at 2.6 ?  I wasn't all the happy with the double function thing
going on there,

Cheers,
Davidm


> -----Original Message-----
> From: lin...@vg... [mailto:lin...@vg...] On Behalf Of Eran Ben-Avi
> Sent: Thursday, August 30, 2007 2:58 AM
> To: David McCullough
> Cc: lin...@vg...
> Subject: Re: Openswan 2.4.9 - tasklet or workqueue ?
> 
> 
> --- David McCullough
> <Dav...@se...> wrote:
> 
> > 
> > 
> > 
> > Jivin Eran Ben-Avi lays it down ...
> > > Hi,
> > > 
> > > I tested IPSec(tunnel mode) routing performance
> > between 2 GbE ports using packet generator(SMARTBIT)  on ARM 500MHz 
> > with latest OCF patched on
> > Openswan2.4.9 and I noticed the callback functions are using 
> > workqueue.
> > > Since RX was performed in NAPI mode with higher
> > priority then TX (in workqueue), the callback function(in ipsec_ocf.c) 
> > was starved with zero routing.
> > > The problem was solved after I switched to use
> > tasklet instead of the workqueue.
> > > Is there a room for updating next OCF release ?
> > 
> > Sure,  send in a patch. This is against
> > ocf-linux-20070727 right ?
> Yes.
> Can you please estimate when next release will be ready?
> 
> Thanks. 
> 
> > 
> > Cheers,
> > Davidm
> > 
> > --
> > David McCullough, 
> > dav...@se...,   Ph:+61
> > 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org 
> > http://www.cyberguard.com
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> > linux-crypto" in the body of a message to maj...@vg... 
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > 
> 
> 
> 
>        
> ____________________________________________________________________________________
> Got a little couch potato? 
> Check out fun summer activities for kids.
> http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] OCF/OpenSwan tunnel crashes

[David M. <Dav...@se...>]

Jivin Ronan Morrissey lays it down ...
> I have replicated this crash with cryptosoft. The systems falls over during
> a 10 second blast of 6.8 Mbits from Smartbits. This usiing using OpenSwan (
> 2.4.9) up on OCF(20070727) (using the lastest openSwan patch) and then up
> setting a VPN tunnel.

The call sequence looks pretty obvious.

Definately try setting USE_CBIMM to 0.

It may have some impact on performance,  but for loaded systems
it may actually be better.  Besides,  hangs are bad for performance as
well.

cryptosoft could be more of a trigger here as well since it is actually
SW it can callback before returning from crypto_process,  which is still
possible with HW,  but much less likely.

Do you have kernel preemption enabled ?  Is it possible to try turning
it off if it is ?

Cheers,
Davidm

> The system details are
> Kernel 2.6.18.8-EL5
> 
> model name: Intel(R) Pentium(R) 4 CPU 2.40GHz
> 
> cpu MHz: 2392.119, cache size: 512 KB, stepping: 7
> The crash log is below
> 
> BUG: soft lockup detected on CPU#0!
> 
>  [<c044a0b7>] softlockup_tick+0x98/0xa6
>  [<c042cc98>] update_process_times+0x39/0x5c
>  [<c04176ec>] smp_apic_timer_interrupt+0x5c/0x64
>  [<c04049bf>] apic_timer_interrupt+0x1f/0x24
>  [<c05fc458>] _spin_lock+0x7/0xf
>  [<e1021e13>] ipsec_tunnel_SAlookup+0x40/0x561 [ipsec]
>  [<e102243c>] ipsec_tunnel_start_xmit+0x108/0x154 [ipsec]
>  [<c05a3d8a>] dev_hard_start_xmit+0x198/0x1ee
>  [<c05b1a7a>] __qdisc_run+0xe4/0x19a
>  [<c05a557b>] dev_queue_xmit+0x144/0x24d
>  [<c05a7b50>] neigh_connected_output+0x79/0x8c
>  [<c05c2755>] ip_output+0x1ce/0x1f9
>  [<c05bef8b>] ip_forward+0x1d9/0x22e
>  [<c05bddc5>] ip_rcv+0x3ef/0x429
>  [<c05a39b9>] netif_receive_skb+0x2c1/0x339
>  [<e08d4c41>] e1000_clean_rx_irq+0x3ef/0x49b [e1000]
>  [<e08d33c5>] e1000_clean+0x69/0x106 [e1000]
>  [<c05a5354>] net_rx_action+0x92/0x175
>  [<c04281cf>] __do_softirq+0x5a/0xbb
>  [<c0406461>] do_softirq+0x52/0x9d
>  [<c0406406>] do_IRQ+0xa5/0xae
>  [<c040492e>] common_interrupt+0x1a/0x20
>  [<c04df347>] memcpy+0x17/0x28
>  [<e1021d3d>] ipsec_tunnel_xsm_complete+0x7c/0x112 [ipsec]
>  [<e1022c66>] ipsec_xsm+0x123/0x126 [ipsec]
>  [<e1031e2e>] ipsec_ocf_xmit_cb+0x10c/0x111 [ipsec]
>  [<e0b03e76>] crypto_done+0x72/0x110 [ocf]
>  [<e0b29cf9>] swcr_process+0xa04/0xa2e [cryptosoft]
>  [<e0b03fe2>] crypto_invoke+0xce/0xd4 [ocf]
>  [<c0434ef8>] finish_wait+0x2a/0x4b
>  [<e0b0477b>] crypto_proc+0x15d/0x4c7 [ocf]
>  [<c0434e65>] autoremove_wake_function+0x0/0x2d
>  [<e0b0461e>] crypto_proc+0x0/0x4c7 [ocf]
>  [<c0404c3b>] kernel_thread_helper+0x7/0x10
> 
> Has anyone else seen this crash?
> 
> On 07/09/2007, Ronan Morrissey <ron...@gm...> wrote:
> >
> > Hello,
> >
> > I seem to be having some problems with setting OpenSwan (2.4.9) up on
> > OCF(20070727) (using the lastest openSwan patch) and then up setting a VPN
> > tunnel up.
> >
> > I have a RHEL5 system using a 2.6.18 kernel.
> >
> > I can setup a host to host connection and the tunnel works fine with
> > pings, scp and ftp all working through the tunnel for both cryptosoft and my
> > hardware accelerator.
> >
> > My problems arise when I try to setup  the two hosts as gateways. When I
> > setup a system where packets are coming from somewhere else on the network
> > and are allowed to pass through the VPN (via the connection details in
> > ipsec.conf) I get system crashes for cryptosoft and my hardware driver ( I
> > can get no ouput log files :( ).
> >
> > From what I have read on other forums some kind of race condition in OCF
> > could be causing this. Has anyone else seen these kind of issues. There was
> > a recommendation to try setting the USE_CBIMM flag to zero in ipsec_ocf.c
> > which would disable immediate callbacks. This may resolve an appartently
> > know race condition between the network stack and OCF! Is this true. What
> > impact on performance would this action have
> >
> > --
> > Regards,
> > Ronan
> 
> 
> 
> 
> -- 
> Regards,
> Ronan

> -------------------------------------------------------------------------
> 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


-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[David M. <Dav...@se...>]

Jivin Tomasz Rostanski lays it down ...
> Hi,
> 
> I have debug the code a bit and found where the freeze is.
> The waiting code in cryptodev_op is never ending from the while loop:
> do {
> 	wait_event_interruptible(...);
> } while ((crp->crp_flags & CRYPTO_F_DONE) == 0);
> 
> When I set the rp->crp_flags to CRYPTO_F_DONE in ixp_q_process before 
> return when status equals to IX_CRYPTO_ACC_STATUS_SUCCESS the freeze is 
> not happening.
> So maybe there is something is wrong with wait_event_interruptible 
> function in my kernel or I don't know.


We have seen something like this just recently.  A hash of a 0 length
buffer would cause an error and the access lib would not report it,  or
call the callback.

Any chance you are doing something like this ?

Setting CRYPTO_F_DONE in ixp_q_process when you get a
IX_CRYPTO_ACC_STATUS_SUCCESS is not good,  you will be returning before
the operation is completed.

CRYPTO_F_DONE is set by the call to crypto_done,  which happens on error
or when the callback occurs.

I am guessing you are past this error as well:

	"ixpCryptoAccCtxRegister failed 6"

Cheers,
Davidm


> David McCullough napisa?(a):
> >Jivin Tomasz Rostanski lays it down ...
> >>Hi,
> >>
> >>>>I have checked the latest ixp400 access lib (2.4) and ixp_400 ethernet 
> >>>>driver (1.7). I didn't use the Intel patches for crypto initialization 
> >>>>in ixp400_eth.
> >>>>The result is still the same - the device freezes when I run openssl or 
> >>>>ssh.
> >>>>I'm having microcode compiled in driver - load it from file to 
> >>>>/dev/ixNpe, so I have recompiled it and load the microcode from file 
> >>>>but this didn't make any difference.
> >>>Are you using the "crypto version" of the access library ?
> >>Yes, I'm using the crypto version of the library.
> >>
> >>>>Could this issue be related with the hardware? I'm using the AirTegrity 
> >>>>box which was designed completely by them and not uses redboot 
> >>>>bootloader but their own one. Could it be the reason of the problem I'm 
> >>>>having?
> >>>No,  we do the same,  it has no bearing on how the NPE's do their thing.
> >>>
> >>>Are you loading the correct NPE code (with crypto support etc).
> >>Normally I have NPE code compiled in the sources. I'm using the version 
> >>with crypto support so it should be ok.
> >
> >ok.
> >
> >>>>I'll give a try on Gateworks GW2347 and see if it will be working as it 
> >>>>should or not.
> >>Ok, I have a problem with initialization crypto on the gw2347 - the 
> >>message:
> >>"ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
> >
> >Thats sounds weird.  It sounds like the crypto isn't working properly
> >for some reason.
> >
> >ixpCryptoAccCtxRegister doesn't need much to work.
> >
> >>checked and the ixp4xx module when loading returns the error that cannot 
> >>initialize crypto.
> >
> >That is ok,  if the network driver init's the crypto then you will get
> >this error since we cannot tell that it has been done,  yet it returns a
> >fail if it is already initted.
> >
> >Might be worth checking the details of the error.
> >
> >Cheers,
> >Davidm
> >
> >>>>David McCullough napisa?(a):
> >>>>>Jivin Tomasz Rostanski lays it down ...
> >>>>>>Hi,
> >>>>>>
> >>>>>>>Which access library version are you using ?
> >>>>>>The full name is ixp400accesslibrarywithcrypto-2.3.1
> >>>>>Ok,  not sure we have tested OCF with version 2.3 of the access lib.
> >>>>>It is part of our tree so I will try it.
> >>>>>
> >>>>>Not sure you mentioned which sources you are using,  but the
> >>>>>uClinux-dist or SnapGear dists have very good IXP425 support
> >>>>>and less patching ;-)
> >>>>>
> >>>>>>>Can you load ocf, cryptodev and ixp4xx all with debug enabled:
> >>>>>>>
> >>>>>>>	modprobe ocf crypto_debug=1
> >>>>>>>	modprobe cryptodev cryptodev_debug=1
> >>>>>>>	modprobe ixp4xx ixp_debug=1
> >>>>>>>
> >>>>>>>The run the test, capture all the console output and send me a copy
> >>>>>>>for reference.
> >>>>>>The output is attached (ocf.log).
> >>>>>Ok,  I will try and get some time on it in the next day or so, thanks.
> >>>>>
> >>>>>Actually,  just had a quick look,  I think the access lib is blowing 
> >>>>>the
> >>>>>stack.  It is renowned for doing this.
> >>>>>
> >>>>>If you can try increasing the kernel stack size to 8K if it isn't
> >>>>>already it might help.
> >>>>>
> >>>>>Otherwise,  you may find the info to fix it in our access lib patch:
> >>>>>
> >>>>>	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
> >>>>>
> >>>>>Or perhaps try the Snapgear/uClinux-dist if you have time.  We have all
> >>>>>these sort or problems sorted already ;-)
> >>>>>
> >>>>>>>Have you tried turning off preemption ?  I don't think I have ever
> >>>>>>>tested with that.
> >>>>>>Yes, I have tried but didn't help :(
> >>>>>Oh well,  looks like a real bug then ;-)
> >>>>>
> >>>>>Cheers,
> >>>>>Davidm
> >>>>>
> >>>>>>>>David McCullough napisa?(a):
> >>>>>>>>>Jivin Tomasz Rostanski lays it down ...
> >>>>>>>>>>Hi,
> >>>>>>>>>>
> >>>>>>>>>>I tried using ixp4xx module for hardware crypto on my ixp425 
> >>>>>>>>>>device with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using ixp400 
> >>>>>>>>>>access library with crypto in version 2.3.1 and ixp400_eth driver 
> >>>>>>>>>>in version 1.6 (with Intel's patch for OCF support - 
> >>>>>>>>>>http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
> >>>>>>>>>>
> >>>>>>>>>>I'm loading the modules like described in Intel readme:
> >>>>>>>>>>mknod /dev/crypto c 10 70
> >>>>>>>>>>mknod -m 666 /dev/ixNpe c 241 0
> >>>>>>>>>>modprobe ixp400 >/dev/null 2>/dev/null
> >>>>>>>>>>modprobe ixp400_eth >/dev/null 2>/dev/null
> >>>>>>>>>>modprobe ocf
> >>>>>>>>>>modprobe cryptodev
> >>>>>>>>>>modprobe ixp4xx ixp_init_crypto=0
> >>>>>>>>>>
> >>>>>>>>>>Then when I run the: openssl speed -elapsed -evp des-ede3-cbc 
> >>>>>>>>>>-cpu -engine cryptodev the device hangs (I'm using openssl-0.9.8a 
> >>>>>>>>>>patched for OCF). The same happend when I tried to connect from 
> >>>>>>>>>>the device using ssh.
> >>>>>>>>>>I have enabled debugging and saw that the debugging from 
> >>>>>>>>>>ixp_q_process is the last one displayed. So I have started adding 
> >>>>>>>>>>some debug messages to that function and found that the hand 
> >>>>>>>>>>appears after the following code:
> >>>>>>>>>>if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
> >>>>>>>>>>	return;
> >>>>>>>>>>So I have changed return to goto done and check what will happen 
> >>>>>>>>>>- this time the openssl didn't hang and did it's work. But the 
> >>>>>>>>>>ssh is not working - displays evp_crypt: EVP_Cipher failed and 
> >>>>>>>>>>exits.
> >>>>>>>>>>
> >>>>>>>>>>I have tried the cryptosoft module instead of ixp4xx and this one 
> >>>>>>>>>>works without any problems, so it seems that some problem exists 
> >>>>>>>>>>in ixp4xx module.
> >>>>>>>>>>
> >>>>>>>>>>Do you have any clue what could be wrong? I'm almost sure that 
> >>>>>>>>>>someday on older kernel (2.6.12) I got ixp4xx working without 
> >>>>>>>>>>problems.
> >>>>>>>>>You might want to try incorporating the latest code from the 
> >>>>>>>>>sourceforge
> >>>>>>>>>site.  I haven't seen a like up like you describe on the ixp for a 
> >>>>>>>>>long
> >>>>>>>>>time and I don't know exactly everything that is in the Intel 
> >>>>>>>>>patches.
> >>>>>>>>>
> >>>>>>>>>Try out the latest download at:
> >>>>>>>>>
> >>>>>>>>>	ocf-linux.sourceforge.net
> >>>>>>>>>
> >>>>>>>>>and then it will be much easier for me to help you.  I run IXP 
> >>>>>>>>>boards
> >>>>>>>>>here and can easily try some things,
> >>>>>>>>>
> >>>>>>>>>Cheers,
> >>>>>>>>>Davidm
> >>>>>>>>>
> >
> 
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[Tomasz R. <tro...@pr...>]

Hi,

I have debug the code a bit and found where the freeze is.
The waiting code in cryptodev_op is never ending from the while loop:
do {
	wait_event_interruptible(...);
} while ((crp->crp_flags & CRYPTO_F_DONE) == 0);

When I set the rp->crp_flags to CRYPTO_F_DONE in ixp_q_process before 
return when status equals to IX_CRYPTO_ACC_STATUS_SUCCESS the freeze is 
not happening.
So maybe there is something is wrong with wait_event_interruptible 
function in my kernel or I don't know.

Regards,
Tomasz

David McCullough napisa?(a):
> Jivin Tomasz Rostanski lays it down ...
>> Hi,
>>
>>>> I have checked the latest ixp400 access lib (2.4) and ixp_400 ethernet 
>>>> driver (1.7). I didn't use the Intel patches for crypto initialization 
>>>> in ixp400_eth.
>>>> The result is still the same - the device freezes when I run openssl or 
>>>> ssh.
>>>> I'm having microcode compiled in driver - load it from file to 
>>>> /dev/ixNpe, so I have recompiled it and load the microcode from file but 
>>>> this didn't make any difference.
>>> Are you using the "crypto version" of the access library ?
>> Yes, I'm using the crypto version of the library.
>>
>>>> Could this issue be related with the hardware? I'm using the AirTegrity 
>>>> box which was designed completely by them and not uses redboot 
>>>> bootloader but their own one. Could it be the reason of the problem I'm 
>>>> having?
>>> No,  we do the same,  it has no bearing on how the NPE's do their thing.
>>>
>>> Are you loading the correct NPE code (with crypto support etc).
>> Normally I have NPE code compiled in the sources. I'm using the version 
>> with crypto support so it should be ok.
> 
> ok.
> 
>>>> I'll give a try on Gateworks GW2347 and see if it will be working as it 
>>>> should or not.
>> Ok, I have a problem with initialization crypto on the gw2347 - the message:
>> "ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
> 
> Thats sounds weird.  It sounds like the crypto isn't working properly
> for some reason.
> 
> ixpCryptoAccCtxRegister doesn't need much to work.
> 
>> checked and the ixp4xx module when loading returns the error that cannot 
>> initialize crypto.
> 
> That is ok,  if the network driver init's the crypto then you will get
> this error since we cannot tell that it has been done,  yet it returns a
> fail if it is already initted.
> 
> Might be worth checking the details of the error.
> 
> Cheers,
> Davidm
> 
>>>> David McCullough napisa?(a):
>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>> Hi,
>>>>>>
>>>>>>> Which access library version are you using ?
>>>>>> The full name is ixp400accesslibrarywithcrypto-2.3.1
>>>>> Ok,  not sure we have tested OCF with version 2.3 of the access lib.
>>>>> It is part of our tree so I will try it.
>>>>>
>>>>> Not sure you mentioned which sources you are using,  but the
>>>>> uClinux-dist or SnapGear dists have very good IXP425 support
>>>>> and less patching ;-)
>>>>>
>>>>>>> Can you load ocf, cryptodev and ixp4xx all with debug enabled:
>>>>>>>
>>>>>>> 	modprobe ocf crypto_debug=1
>>>>>>> 	modprobe cryptodev cryptodev_debug=1
>>>>>>> 	modprobe ixp4xx ixp_debug=1
>>>>>>>
>>>>>>> The run the test, capture all the console output and send me a copy
>>>>>>> for reference.
>>>>>> The output is attached (ocf.log).
>>>>> Ok,  I will try and get some time on it in the next day or so, thanks.
>>>>>
>>>>> Actually,  just had a quick look,  I think the access lib is blowing the
>>>>> stack.  It is renowned for doing this.
>>>>>
>>>>> If you can try increasing the kernel stack size to 8K if it isn't
>>>>> already it might help.
>>>>>
>>>>> Otherwise,  you may find the info to fix it in our access lib patch:
>>>>>
>>>>> 	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
>>>>>
>>>>> Or perhaps try the Snapgear/uClinux-dist if you have time.  We have all
>>>>> these sort or problems sorted already ;-)
>>>>>
>>>>>>> Have you tried turning off preemption ?  I don't think I have ever
>>>>>>> tested with that.
>>>>>> Yes, I have tried but didn't help :(
>>>>> Oh well,  looks like a real bug then ;-)
>>>>>
>>>>> Cheers,
>>>>> Davidm
>>>>>
>>>>>>>> David McCullough napisa?(a):
>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I tried using ixp4xx module for hardware crypto on my ixp425 device 
>>>>>>>>>> with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using ixp400 access 
>>>>>>>>>> library with crypto in version 2.3.1 and ixp400_eth driver in 
>>>>>>>>>> version 1.6 (with Intel's patch for OCF support - 
>>>>>>>>>> http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
>>>>>>>>>>
>>>>>>>>>> I'm loading the modules like described in Intel readme:
>>>>>>>>>> mknod /dev/crypto c 10 70
>>>>>>>>>> mknod -m 666 /dev/ixNpe c 241 0
>>>>>>>>>> modprobe ixp400 >/dev/null 2>/dev/null
>>>>>>>>>> modprobe ixp400_eth >/dev/null 2>/dev/null
>>>>>>>>>> modprobe ocf
>>>>>>>>>> modprobe cryptodev
>>>>>>>>>> modprobe ixp4xx ixp_init_crypto=0
>>>>>>>>>>
>>>>>>>>>> Then when I run the: openssl speed -elapsed -evp des-ede3-cbc -cpu 
>>>>>>>>>> -engine cryptodev the device hangs (I'm using openssl-0.9.8a 
>>>>>>>>>> patched for OCF). The same happend when I tried to connect from the 
>>>>>>>>>> device using ssh.
>>>>>>>>>> I have enabled debugging and saw that the debugging from 
>>>>>>>>>> ixp_q_process is the last one displayed. So I have started adding 
>>>>>>>>>> some debug messages to that function and found that the hand 
>>>>>>>>>> appears after the following code:
>>>>>>>>>> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
>>>>>>>>>> 	return;
>>>>>>>>>> So I have changed return to goto done and check what will happen - 
>>>>>>>>>> this time the openssl didn't hang and did it's work. But the ssh is 
>>>>>>>>>> not working - displays evp_crypt: EVP_Cipher failed and exits.
>>>>>>>>>>
>>>>>>>>>> I have tried the cryptosoft module instead of ixp4xx and this one 
>>>>>>>>>> works without any problems, so it seems that some problem exists in 
>>>>>>>>>> ixp4xx module.
>>>>>>>>>>
>>>>>>>>>> Do you have any clue what could be wrong? I'm almost sure that 
>>>>>>>>>> someday on older kernel (2.6.12) I got ixp4xx working without 
>>>>>>>>>> problems.
>>>>>>>>> You might want to try incorporating the latest code from the 
>>>>>>>>> sourceforge
>>>>>>>>> site.  I haven't seen a like up like you describe on the ixp for a 
>>>>>>>>> long
>>>>>>>>> time and I don't know exactly everything that is in the Intel 
>>>>>>>>> patches.
>>>>>>>>>
>>>>>>>>> Try out the latest download at:
>>>>>>>>>
>>>>>>>>> 	ocf-linux.sourceforge.net
>>>>>>>>>
>>>>>>>>> and then it will be much easier for me to help you.  I run IXP boards
>>>>>>>>> here and can easily try some things,
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Davidm
>>>>>>>>>
> 

Re: [Ocf-linux-users] OCF/OpenSwan tunnel crashes

[Ronan M. <ron...@gm...>]

I have replicated this crash with cryptosoft. The systems falls over during
a 10 second blast of 6.8 Mbits from Smartbits. This usiing using OpenSwan (
2.4.9) up on OCF(20070727) (using the lastest openSwan patch) and then up
setting a VPN tunnel.

The system details are
Kernel 2.6.18.8-EL5

model name: Intel(R) Pentium(R) 4 CPU 2.40GHz

cpu MHz: 2392.119, cache size: 512 KB, stepping: 7
The crash log is below

BUG: soft lockup detected on CPU#0!

 [<c044a0b7>] softlockup_tick+0x98/0xa6

 [<c042cc98>] update_process_times+0x39/0x5c

 [<c04176ec>] smp_apic_timer_interrupt+0x5c/0x64

 [<c04049bf>] apic_timer_interrupt+0x1f/0x24

 [<c05fc458>] _spin_lock+0x7/0xf

 [<e1021e13>] ipsec_tunnel_SAlookup+0x40/0x561 [ipsec]

 [<e102243c>] ipsec_tunnel_start_xmit+0x108/0x154 [ipsec]

 [<c05a3d8a>] dev_hard_start_xmit+0x198/0x1ee

 [<c05b1a7a>] __qdisc_run+0xe4/0x19a

 [<c05a557b>] dev_queue_xmit+0x144/0x24d

 [<c05a7b50>] neigh_connected_output+0x79/0x8c

 [<c05c2755>] ip_output+0x1ce/0x1f9

 [<c05bef8b>] ip_forward+0x1d9/0x22e

 [<c05bddc5>] ip_rcv+0x3ef/0x429

 [<c05a39b9>] netif_receive_skb+0x2c1/0x339

 [<e08d4c41>] e1000_clean_rx_irq+0x3ef/0x49b [e1000]

 [<e08d33c5>] e1000_clean+0x69/0x106 [e1000]

 [<c05a5354>] net_rx_action+0x92/0x175

 [<c04281cf>] __do_softirq+0x5a/0xbb

 [<c0406461>] do_softirq+0x52/0x9d

 [<c0406406>] do_IRQ+0xa5/0xae

 [<c040492e>] common_interrupt+0x1a/0x20

 [<c04df347>] memcpy+0x17/0x28

 [<e1021d3d>] ipsec_tunnel_xsm_complete+0x7c/0x112 [ipsec]

 [<e1022c66>] ipsec_xsm+0x123/0x126 [ipsec]

 [<e1031e2e>] ipsec_ocf_xmit_cb+0x10c/0x111 [ipsec]

 [<e0b03e76>] crypto_done+0x72/0x110 [ocf]

 [<e0b29cf9>] swcr_process+0xa04/0xa2e [cryptosoft]

 [<e0b03fe2>] crypto_invoke+0xce/0xd4 [ocf]

 [<c0434ef8>] finish_wait+0x2a/0x4b

 [<e0b0477b>] crypto_proc+0x15d/0x4c7 [ocf]

 [<c0434e65>] autoremove_wake_function+0x0/0x2d

 [<e0b0461e>] crypto_proc+0x0/0x4c7 [ocf]

 [<c0404c3b>] kernel_thread_helper+0x7/0x10

Has anyone else seen this crash?

On 07/09/2007, Ronan Morrissey <ron...@gm...> wrote:
>
> Hello,
>
> I seem to be having some problems with setting OpenSwan (2.4.9) up on
> OCF(20070727) (using the lastest openSwan patch) and then up setting a VPN
> tunnel up.
>
> I have a RHEL5 system using a 2.6.18 kernel.
>
> I can setup a host to host connection and the tunnel works fine with
> pings, scp and ftp all working through the tunnel for both cryptosoft and my
> hardware accelerator.
>
> My problems arise when I try to setup  the two hosts as gateways. When I
> setup a system where packets are coming from somewhere else on the network
> and are allowed to pass through the VPN (via the connection details in
> ipsec.conf) I get system crashes for cryptosoft and my hardware driver ( I
> can get no ouput log files :( ).
>
> From what I have read on other forums some kind of race condition in OCF
> could be causing this. Has anyone else seen these kind of issues. There was
> a recommendation to try setting the USE_CBIMM flag to zero in ipsec_ocf.c
> which would disable immediate callbacks. This may resolve an appartently
> know race condition between the network stack and OCF! Is this true. What
> impact on performance would this action have
>
> --
> Regards,
> Ronan




-- 
Regards,
Ronan

Re: [Ocf-linux-users] OCF Linux question about sys_dup

[David M. <Dav...@se...>]

Jivin Albert Lash lays it down ...
> Hello David,
> 
> I'm trying to get OCF linux modules installed but I'm getting an  
> error when trying to insmod cryptodev.ko.
> 
> So far I've tracked down the problem to:
> 
> cryptodev: Unknown symbol sys_dup

Just a double check that you are running the new kernel that you built
after applying the OCF patch.  The process should be something like:

	1) get kernel source
	2) apply OCF patch
	3) make config ...
	4) make
	5) install newly built kernel
	6) make modules modules_install
	7) reboot
	8) try it out

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] OCF Linux question about sys_dup

[David M. <Dav...@se...>]

Jivin Albert Lash lays it down ...
> Hello David,
> 
> I'm trying to get OCF linux modules installed but I'm getting an  
> error when trying to insmod cryptodev.ko.
> 
> So far I've tracked down the problem to:
> 
> cryptodev: Unknown symbol sys_dup

How did you add ocf to your kernel ?

Did you apply the "big" 2.6.22 patch or did you integrate it by hand ?

Check that all the parts of the patch:

	ocf/patches/linux-2.6.22-ocf.patch

have been applied.  Particularly the export of sys_dup.

> I attempted to export the symbol as suggested here:
> 
> http://mail.nl.linux.org/kernelnewbies/2004-04/msg00333.html
> 
> and also found someone else experiencing a similar problem here:
> 
> http://lists.openswan.org/pipermail/users/2007-January/011553.html
> 
> My work is being conducted on an AMD Geode LX800, and my running  
> kernel is 2.6.22 from debian. I downloaded the kernel source to /usr/ 
> src, and applied the patch with on caveat, I had to manually add the  
> ocf to to crypto/Kconfig file. With that there, I was able to select  
> the modules in the ncurses make menuconfig, but they would not build.  

What were the errors ?

> I was able to build them via the following process:
> 
> make -C /usr/src/linux-source-2.6.22/ M=`pwd` modules
> 
> issued in the crypto/ocf folder. The ocf and cryptosoft modules  
> insert fine.
> 
> Thanks for this great work and any pointers you can share!

See how we go with the above,  but we'll sort it out for sure ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] SafeXcel 1141

[David M. <Dav...@se...>]

Jivin Nawang Chhetan lays it down ...
> Hi David,
>                I just tried the simple ocf-bench test program with
> SafeXcel 1141 card. But all the operations fail.
> I am attaching a tar ball which contains following three files:
> 1. lsmod.txt
> 2. lspci.txt
> 3. ocfbench-dmesg.txt
> with respective details.
> 
> Please have a look at them.

It is possible that ocf-bench is not calling into OCF with parameters
that will work with the safenet.  Pretty sure the error 22 will be an
EINVAL.  Check your errno.h

Try running cryptotest from user space or "openssl speed" as they are
safe.  If that works I'll look at what could be wrong with ocf-bench.
Examples of running the apps are on:

	http://ocf-linux.sourceforge.net/benchmarks.html

Cheers,
Davidm

> On 9/5/07, David McCullough <Dav...@se...> wrote:
> >
> > Jivin Nawang Chhetan lays it down ...
> > > Hi David,
> > >                I am trying to run "bench-ocf" with safe.ko . I dont
> > > see any debug messages( I insert the modules with debug messages
> > > enabled).  Seems even though open-ssl does all the stuff mentioned in
> > > the script "bench-ocf", 1141 card is not used. Can you give me some
> > > directions here ?
> >
> > Send me the output of:
> >
> >         lsmod
> >
> > If you want to be sure only the safenet driver is used,  make sure that
> > you do not load cryptosoft or any other crypto driver.  Just load:
> >
> >         ocf
> >         safe
> >         cryptodev
> >
> > Cheers,
> > Davidm
> >
> > > On 9/5/07, David McCullough <Dav...@se...> wrote:
> > > >
> > > > Jivin Nawang Chhetan lays it down ...
> > > > > Hi David,
> > > > >                I was testing OCF with SafeXcel 1141 card. Just wanted
> > > > > to know which version of the 1141 card you tested OCF with i.e. REV1
> > > > > or REV1.1.
> > > >
> > > > I think I have used both as I had to work around a bug in version1 IIRC.
> > > > I have also used the 1741.
> > > >
> > > > Note that none of these were cards,  but PCI chips on an embedded board,
> > > > but they look like cards ;-)
> > > >
> > > > Cheers,
> > > > Davidm
> > > >
> > > > --
> > > > 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
> >



-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: [Ocf-linux-users] SafeXcel 1141

[Nawang C. <naw...@gm...>]

Hi David,
               I just tried the simple ocf-bench test program with
SafeXcel 1141 card. But all the operations fail.
I am attaching a tar ball which contains following three files:
1. lsmod.txt
2. lspci.txt
3. ocfbench-dmesg.txt
with respective details.

Please have a look at them.

Thanks a lot.



On 9/5/07, David McCullough <Dav...@se...> wrote:
>
> Jivin Nawang Chhetan lays it down ...
> > Hi David,
> >                I am trying to run "bench-ocf" with safe.ko . I dont
> > see any debug messages( I insert the modules with debug messages
> > enabled).  Seems even though open-ssl does all the stuff mentioned in
> > the script "bench-ocf", 1141 card is not used. Can you give me some
> > directions here ?
>
> Send me the output of:
>
>         lsmod
>
> If you want to be sure only the safenet driver is used,  make sure that
> you do not load cryptosoft or any other crypto driver.  Just load:
>
>         ocf
>         safe
>         cryptodev
>
> Cheers,
> Davidm
>
> > On 9/5/07, David McCullough <Dav...@se...> wrote:
> > >
> > > Jivin Nawang Chhetan lays it down ...
> > > > Hi David,
> > > >                I was testing OCF with SafeXcel 1141 card. Just wanted
> > > > to know which version of the 1141 card you tested OCF with i.e. REV1
> > > > or REV1.1.
> > >
> > > I think I have used both as I had to work around a bug in version1 IIRC.
> > > I have also used the 1741.
> > >
> > > Note that none of these were cards,  but PCI chips on an embedded board,
> > > but they look like cards ;-)
> > >
> > > Cheers,
> > > Davidm
> > >
> > > --
> > > 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
>

Re: [Ocf-linux-users] About OCF Linux

[David M. <Dav...@se...>]

Jivin Carl Zhu lays it down ...
> Still have the same problem, I try to use 2.1.1 now, but the buildutil
> directory have no envirment file.
> 
> I am waiting for buildutil directry file now.
> 
> Thanks for your help, after I get the file and still have problem, I will
> contact you.

Ok.

> BTW,can you give me some OCF document? I still have intrest with it's API to
> Linux and Openswan.

There is no documentation other than the code abd what is referenced on
the website at:

	http://ocf-linux.sourceforge.net/links.html

Cheers,
Davidm

> 2007/9/5, David McCullough <Dav...@se...>:
> >
> >
> > Jivin Carl Zhu lays it down ...
> > > Sorry!!!!
> > >
> > > I have found I am using 3.5 now.
> > > So this problem may related to this?
> >
> > May,  don't worry about the ipsec_alg_cryptoapi.c,  it looks ok.
> > Do a clean and full rebuild:
> >
> >        patch your tree if you haven't
> >        make clean
> >        make oldconfig
> >                (answer yes to appropriate OCF questions)
> >        make dep
> >        make
> >
> > If you get errors send them to me so I can see what is failing,
> >
> > Cheers,
> > Davidm
> >
> > > 2007/9/5, David McCullough <Dav...@se...>:
> > > >
> > > >
> > > > Which snapgear version do you have,  this patch was for snapgear 3.4
> > > >
> > > > Jivin Carl Zhu lays it down ...
> > > > > I have checked your patch file.
> > > > >
> > > > > One file can't be patched and I have found it seems that we use
> > > > different
> > > > > file?
> > > > >
> > > > > The file is:snapgear\openswan\linux\net\ipsec\ipsec_alg_cryptoapi.c
> > > > > I attached it, can you check it why?
> > > > >
> > > > >
> > > > > 2007/9/4, David McCullough <Dav...@se...>:
> > > > > >
> > > > > >
> > > > > > Have a try with the attached patch.
> > > > > > I would normally use CSR 1.4 with 2.4 kernels.
> > > > > > There are a few things missing from the snapgear-3.4 tree to get
> > this
> > > > > > going and I have just managed to get another user running,  so it
> > can
> > > > be
> > > > > > done.  This patch seems to finish it off :-)
> > > > > >
> > > > > > Jivin carl zhu lays it down ...
> > > > > > > I still have the same result....
> > > > > > >
> > > > > > > I think I may need redownload the snapgear code and use CSR2.1.1
> > ,
> > > > Does
> > > > > > this
> > > > > > > will solve the problem?
> > > > > > >
> > > > > > >
> > > > > > > On 9/3/07, David McCullough <
> > Dav...@se...>
> > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Jivin carl zhu lays it down ...
> > > > > > > > > Hi David,
> > > > > > > > >
> > > > > > > > >  Sorry to bother you again.
> > > > > > > > >
> > > > > > > > > I have tried your suggestions but faced complie error(in
> > > > error.txt
> > > > > > ),I
> > > > > > > > also
> > > > > > > > > attached what I changed in config.in.rar
> > > > > > > >
> > > > > > > > You should build ipsec as a module when using OCF as a
> > module,  as
> > > > > > ipsec
> > > > > > > > with OCF support enabled relies on OCF being present.  In the
> > > > snapgear
> > > > > > > > build env,  ocf is always a module,  so ipsec needs to be a
> > > > module.
> > > > > > > >
> > > > > > > > Do the following:
> > > > > > > >
> > > > > > > >        make linux-2.4.x_clean
> > > > > > > >
> > > > > > > > edit snapgear/linux-2.4.x/.config
> > > > > > > >
> > > > > > > >        change CONFIG_KLIPS_OCF=y to CONFIG_KLIPS_OCF=m
> > > > > > > >
> > > > > > > > run
> > > > > > > >
> > > > > > > >        make oldconfig
> > > > > > > >        make dep
> > > > > > > >        make
> > > > > > > >
> > > > > > > > See how that goes :-)
> > > > > > > >
> > > > > > > > > After check the ocf/README, I find this information:
> > > > > > > > >
> > > > > > > > >     * make sure that cryptodev.h (from ocf-linux.tar.gz) is
> > > > > > installed as
> > > > > > > > >       crypto/cryptodev.h in an include directory that is
> > used
> > > > for
> > > > > > > > building
> > > > > > > > >       applications for your platform.  For example on a host
> > > > system
> > > > > > that
> > > > > > > > >       might be:
> > > > > > > > >
> > > > > > > > >               /usr/include/crypto/cryptodev.h
> > > > > > > > >
> > > > > > > > > Now, I just change the
> > > > > > snapgear\openswan\linux\net\ipsec\ipsec_ocf.h's
> > > > > > > > > cryptodev.h to correct path. Does this not right? How I need
> > to
> > > > do?
> > > > > > > >
> > > > > > > > The addition of the:
> > > > > > > >
> > > > > > > >        -I$(ROOTDIR)/modules/ocf
> > > > > > > >
> > > > > > > > in the snapgear/linux-2.4.x/net/ipsec/Makefile file should
> > have
> > > > been
> > > > > > > > enough to fix and include errors.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Davidm
> > > > > > > >
> > > > > > > > > On 9/3/07, David McCullough <
> > > > Dav...@se...>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Carl,
> > > > > > > > > >
> > > > > > > > > > Ok,  there are some bits missing from the openswan in your
> > > > source
> > > > > > tree
> > > > > > > > > > when using snapgear-3.4.
> > > > > > > > > >
> > > > > > > > > >        edit snapgear/linux-2.4.x/net/ipsec/Makefile, add
> > the
> > > > > > following
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > >        first instance of EXTRA_CFLAGS:
> > > > > > > > > >
> > > > > > > > > >                -I$(ROOTDIR)/modules/ocf
> > > > > > > > > >
> > > > > > > > > >        edit
> > > > > > snapgear/openswan/linux/net/ipsec/Config.in.os2_4,  add
> > > > > > > > the
> > > > > > > > > >        following line after the CONFIG_KLIPS_DEBUG line
> > near
> > > > the
> > > > > > end.
> > > > > > > > > >
> > > > > > > > > >                bool '   IPsec: OCF HW Acceleration
> > support'
> > > > > > > > > > CONFIG_KLIPS_OCF
> > > > > > > > > >
> > > > > > > > > > That should get you going.  To rebuild do:
> > > > > > > > > >
> > > > > > > > > >        make clean
> > > > > > > > > >        make oldconfig
> > > > > > > > > >                (answer y to KLIPS_OCF)
> > > > > > > > > >        make dep
> > > > > > > > > >        make
> > > > > > > > > >
> > > > > > > > > > See if that fixes it,  if not let me know and I sort it
> > out,
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > Davidm
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Jivin carl zhu lays it down ...
> > > > > > > > > > > here you are, I have attached.
> > > > > > > > > > >
> > > > > > > > > > > On 8/31/07, David McCullough <
> > > > > > Dav...@se...>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Jivin carl zhu lays it down ...
> > > > > > > > > > > > > Hi David,
> > > > > > > > > > > > >
> > > > > > > > > > > > >     Glad to find you response so quickly.:)
> > > > > > > > > > > > >     Do you work for Snapgear?
> > > > > > > > > > > >
> > > > > > > > > > > > Yes.
> > > > > > > > > > > >
> > > > > > > > > > > > > I use snapgear v3.4 and ixp csr 1.4 with
> > > > > > > > > > > >
> > > > > > > > > > > > That is what we use.
> > > > > > > > > > > >
> > > > > > > > > > > > > crypto to build the code. My device is ADI Coyote
> > like.
> > > > > > > > > > > > >     I just get the code and patch the driver to let
> > it
> > > > use
> > > > > > > > > > > > ethernet/crypto.
> > > > > > > > > > > >
> > > > > > > > > > > > Did you use the snapgear CSR patch ?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
> > > > > > > > > > > >
> > > > > > > > > > > > Do you do a make config and enable OCF and the
> > appropriate
> > > > > > modules
> > > > > > > > ?
> > > > > > > > > > > >
> > > > > > > > > > > > > Then I get such performance.(openswan + linux2.4.x)
> > > > > > > > > > > >
> > > > > > > > > > > > So are you now getting full performance or not ?
> > > > > > > > > > > >
> > > > > > > > > > > > If not,  send me a copy these files and I should be
> > able
> > > > to
> > > > > > sort
> > > > > > > > it
> > > > > > > > > > out.
> > > > > > > > > > > >
> > > > > > > > > > > >        snapgear/linux-2.4.x/.config
> > > > > > > > > > > >        snapgear/modules/.config
> > > > > > > > > > > >        snapgear/config/.config
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers.
> > > > > > > > > > > > Davidm
> > > > > > > > > > > >
> > > > > > > > > > > > > On 8/31/07, David McCullough <
> > > > > > > > Dav...@se...>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Jivin carl zhu lays it down ...
> > > > > > > > > > > > > > > Hi David,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    I have got your OCF linux code, but I have
> > some
> > > > > > question
> > > > > > > > > > about
> > > > > > > > > > > > it.
> > > > > > > > > > > > > > > because source forge's mail list seems no one to
> > > > answer.
> > > > > > I
> > > > > > > > send
> > > > > > > > > > the
> > > > > > > > > > > > mail
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > you.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I have not seen any mailing list mails or
> > "pending"
> > > > > > > > messages.  Are
> > > > > > > > > > you
> > > > > > > > > > > > > > sending to the correct address ?  You should
> > subscribe
> > > > > > before
> > > > > > > > > > mailing
> > > > > > > > > > > > > > to get a better response time.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >   the questions are:
> > > > > > > > > > > > > > >   1, I use ocf-bench, get such result:
> > > > > > > > > > > > > > > Using /lib/modules/2.4.32-uc0/kernel/ocf/ocf-
> > bench.o
> > > > > > > > > > > > > > > Crypto Speed tests
> > > > > > > > > > > > > > > OCF: testing ...
> > > > > > > > > > > > > > > OCF: 1044 requests of 1500 bytes in 17 jiffies
> > > > > > > > > > > > > > > IXP: testing ...
> > > > > > > > > > > > > > > IXP: 1044 requests of 1500 bytes in 13 jiffies
> > > > > > > > > > > > > > >     lsmod's result:
> > > > > > > > > > > > > > >     Module                  Size  Used by
> > > > > > > > > > > > > > > ixp4xx                  5672   0 (unused)
> > > > > > > > > > > > > > > cryptodev               5868   0 (unused)
> > > > > > > > > > > > > > > ocf                    15616   0 [ixp4xx
> > cryptodev]
> > > > > > > > > > > > > > > ixp425_eth             16700   2
> > > > > > > > > > > > > > > ixp400                412032   0 [ixp4xx
> > ixp425_eth]
> > > > > > > > > > > > > > >    But I use openswan to build the VPN, the tcp
> > > > > > throughput
> > > > > > > > will
> > > > > > > > > > be 3
> > > > > > > > > > > > > > Mbps,
> > > > > > > > > > > > > > > if not use VPN, the throughput will be 70Mbps.
> > > > > > > > > > > > > > >    I dont know why? I think I can get 40-50Mbps
> > in
> > > > > > VPN...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On an IXP you should get from 38-45Mbps depening
> > on
> > > > clock
> > > > > > > > speed
> > > > > > > > > > etc.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3Mbps is slow even for software crypto.  Make sure
> > you
> > > > do
> > > > > > not
> > > > > > > > have
> > > > > > > > > > > > > > cryptosoft loaded.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  2, Due to problem 1, I think the root cause may
> > > > > > happened on
> > > > > > > > OCF
> > > > > > > > > > > > crypto
> > > > > > > > > > > > > > API
> > > > > > > > > > > > > > > with Openswan, but I can't find any document to
> > > > discuss
> > > > > > it.
> > > > > > > > Do
> > > > > > > > > > you
> > > > > > > > > > > > have
> > > > > > > > > > > > > > > some?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Most likely you have openswan configured
> > > > > > incorrectly.  Check
> > > > > > > > that
> > > > > > > > > > > > > > CONFIG_KLIPS_OCF is enabled in the kernel build.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Run "cryptotest" and check the throughput.  If
> > > > everything
> > > > > > look
> > > > > > > > > > > > > > accelerated,  then you need to work out what is
> > wrong
> > > > with
> > > > > > > > your
> > > > > > > > > > > > openswan
> > > > > > > > > > > > > > build/compile that is not enabled OCF support.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > Davidm
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > David McCullough,
> > > > dav...@se...,
> > > > > > > > Ph:+61
> > > > > > > > > > > > > > 734352815
> > > > > > > > > > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > > > > > > > > > http://www.cyberguard.com
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > David McCullough,
> > dav...@se...,
> > > > > > Ph:+61
> > > > > > > > > > > > 734352815
> > > > > > > > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > > > > > > > http://www.cyberguard.com
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > David McCullough,  dav...@se...,
> > > > Ph:+61
> > > > > > > > > > 734352815
> > > > > > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > > > > > http://www.cyberguard.com
> > > > > > > > > >
> > > > > > > >
> > > > > > > > > make CFLAGS="-D__KERNEL__ -I/home/carl_zhu/snapgear/linux-
> > 2.4.x
> > > > > > /include  -Wall
> > > > > > > > -Wstrict-prototypes -Wno-trigraphs -O -fno-strict-aliasing
> > > > -fno-common
> > > > > > -Uarm
> > > > > > > > -fno-common -pipe -mapcs-32 -D__LINUX_ARM_ARCH__=5
> > -mcpu=xscale
> > > > > > > > -mtune=xscale -malignment-traps -msoft-float -Uarm "
> > > > > > > > -C  /home/carl_zhu/snapgear/modules
> > > > > > > > > make[2]: Entering directory
> > `/home/carl_zhu/snapgear/modules'
> > > > > > > > > make all_targets
> > > > > > > > > make[3]: Entering directory
> > `/home/carl_zhu/snapgear/modules'
> > > > > > > > > make[3]: Nothing to be done for `all_targets'.
> > > > > > > > > make[3]: Leaving directory `/home/carl_zhu/snapgear/modules'
> > > > > > > > > make[2]: Leaving directory `/home/carl_zhu/snapgear/modules'
> > > > > > > > > arm-linux-ld -EB -p -X -T arch/arm/vmlinux.lds
> > > > arch/arm/kernel/head-
> > > > > > > > armv.o arch/arm/kernel/init_task.o init/main.o init/version.o
> > > > > > > > init/do_mounts.o \
> > > > > > > > >         --start-group \
> > > > > > > > >         arch/arm/kernel/kernel.o arch/arm/mm/mm.o
> > > > > > > > arch/arm/mach-ixp425/ixp425.o kernel/kernel.o mm/mm.o fs/fs.o
> > > > > > ipc/ipc.o \
> > > > > > > > >          drivers/char/char.o drivers/serial/serial.o
> > > > > > > > drivers/block/block.o drivers/misc/misc.o drivers/net/net.o
> > > > > > > > drivers/pci/driver.o drivers/mtd/mtdlink.o
> > drivers/media/media.o
> > > > > > > > crypto/crypto.o \
> > > > > > > > >         net/network.o \
> > > > > > > > >         arch/arm/nwfpe/math-emu.o arch/arm/lib/lib.a
> > > > > > > > /home/carl_zhu/snapgear/linux-2.4.x/lib/lib.a \
> > > > > > > > >         --end-group \
> > > > > > > > >         -o vmlinux
> > > > > > > > > net/network.o: In function `ipsec_ocf_sa_init':
> > > > > > > > > sysctl_net.c:(.text+0x8a264): undefined reference to
> > > > > > `crypto_newsession'
> > > > > > > > > sysctl_net.c:(.text+0x8a284): undefined reference to
> > > > > > `crypto_newsession'
> > > > > > > > > sysctl_net.c:(.text+0x8a2a4): undefined reference to
> > > > > > `crypto_newsession'
> > > > > > > > > net/network.o: In function `ipsec_ocf_sa_free':
> > > > > > > > > sysctl_net.c:(.text+0x8a35c): undefined reference to
> > > > > > > > `crypto_freesession'
> > > > > > > > > net/network.o: In function `ipsec_ocf_rcv_cb':
> > > > > > > > > sysctl_net.c:(.text+0x8a4b4): undefined reference to
> > > > > > `crypto_freereq'
> > > > > > > > > net/network.o: In function `ipsec_ocf_rcv':
> > > > > > > > > sysctl_net.c:(.text+0x8a60c): undefined reference to
> > > > `crypto_getreq'
> > > > > > > > > sysctl_net.c:(.text+0x8a884): undefined reference to
> > > > > > `crypto_dispatch'
> > > > > > > > > net/network.o: In function `ipsec_ocf_xmit_cb':
> > > > > > > > > sysctl_net.c:(.text+0x8a98c): undefined reference to
> > > > > > `crypto_freereq'
> > > > > > > > > net/network.o: In function `ipsec_ocf_xmit':
> > > > > > > > > sysctl_net.c:(.text+0x8aae0): undefined reference to
> > > > `crypto_getreq'
> > > > > > > > > sysctl_net.c:(.text+0x8ad2c): undefined reference to
> > > > > > `crypto_dispatch'
> > > > > > > > > net/network.o: In function `ipsec_ocf_check_alg':
> > > > > > > > > sysctl_net.c:(.text+0x8adb4): undefined reference to
> > > > > > `crypto_newsession'
> > > > > > > > > sysctl_net.c:(.text+0x8ade8): undefined reference to
> > > > > > > > `crypto_freesession'
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > David McCullough,  dav...@se...,
> > Ph:+61
> > > > > > > > 734352815
> > > > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > > > http://www.cyberguard.com
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > David McCullough,  dav...@se...,   Ph:+61
> > > > > > 734352815
> > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > http://www.cyberguard.com
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > David McCullough,  dav...@se...,   Ph:+61
> > > > 734352815
> > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > http://www.cyberguard.com
> > > >
> >
> > --
> > David McCullough,  dav...@se...,   Ph:+61
> > 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org
> > http://www.cyberguard.com
> >

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

[Ocf-linux-users] OCF/OpenSwan tunnel crashes

[Ronan M. <ron...@gm...>]

Hello,

I seem to be having some problems with setting OpenSwan (2.4.9) up on
OCF(20070727) (using the lastest openSwan patch) and then up setting a VPN
tunnel up.

I have a RHEL5 system using a 2.6.18 kernel.

I can setup a host to host connection and the tunnel works fine with pings,
scp and ftp all working through the tunnel for both cryptosoft and my
hardware accelerator.

My problems arise when I try to setup  the two hosts as gateways. When I
setup a system where packets are coming from somewhere else on the network
and are allowed to pass through the VPN (via the connection details in
ipsec.conf) I get system crashes for cryptosoft and my hardware driver ( I
can get no ouput log files :( ).

>From what I have read on other forums some kind of race condition in OCF
could be causing this. Has anyone else seen these kind of issues. There was
a recommendation to try setting the USE_CBIMM flag to zero in ipsec_ocf.c
which would disable immediate callbacks. This may resolve an appartently
know race condition between the network stack and OCF! Is this true. What
impact on performance would this action have

-- 
Regards,
Ronan

[Ocf-linux-users] Race Condition in OCF

[Ronan M. <ron...@gm...>]

Hello,

I seem to be having some problems with setting OpenSwan (2.4.9) up on
OCF(20070727) (using the lastest openSwan patch) and then up setting a VPN
tunnel up.

I have a RHEL5 system using a 2.6.18 kernel.

I can setup a host to host connection and the tunnel works fine with pings,
scp and ftp all working through the tunnel for both cryptosoft and my
hardware accelerator.

My problems arise when I try to setup  the two hosts as gateways. When I
setup a system where packets are coming from somewhere else on the network
and are allowed to pass through the VPN (via the connection details in
ipsec.conf) I get system crashes for cryptosoft and my hardware driver ( I
can get no ouput log files :( ).

>From what I have read on other forums some kind of race condition in OCF
could be causing this. Has anyone else seen these kind of issues. There was
a recommendation to try setting the USE_CBIMM flag to zero in ipsec_ocf.c
which would disable immediate callbacks. This may resolve an appartently
know race condition between the network stack and OCF! Is this true. What
impact on performance would this action have

-- 
Regards,
Ronan

Re: [Ocf-linux-users] OCF's ixp4xx freeze on 2.6.18-rt7

[Tomasz R. <tro...@pr...>]

Hi,

I have checked another thing. Some time ago we've been using kernel 
2.6.12 and 2.0 version of intel's ixp400 access lib with crypto.
I have downloaded the sources from that time and made a build with the 
latest ocf.
I run the openssl to test if it freezes but it worked perfectly.
Then I have updated the access lib to version 2.3.1 and ethernet driver 
1.6 and made another image. This time the freeze occured.
So it seems that something in ixp400 access library newer that 2.0 that 
causes the freeze. It seems that this is not the hardware or kernel issue.

Regards,
Tomasz

David McCullough napisa?(a):
> Jivin Tomasz Rostanski lays it down ...
>> Hi,
>>
>>>> I have checked the latest ixp400 access lib (2.4) and ixp_400 ethernet 
>>>> driver (1.7). I didn't use the Intel patches for crypto initialization 
>>>> in ixp400_eth.
>>>> The result is still the same - the device freezes when I run openssl or 
>>>> ssh.
>>>> I'm having microcode compiled in driver - load it from file to 
>>>> /dev/ixNpe, so I have recompiled it and load the microcode from file but 
>>>> this didn't make any difference.
>>> Are you using the "crypto version" of the access library ?
>> Yes, I'm using the crypto version of the library.
>>
>>>> Could this issue be related with the hardware? I'm using the AirTegrity 
>>>> box which was designed completely by them and not uses redboot 
>>>> bootloader but their own one. Could it be the reason of the problem I'm 
>>>> having?
>>> No,  we do the same,  it has no bearing on how the NPE's do their thing.
>>>
>>> Are you loading the correct NPE code (with crypto support etc).
>> Normally I have NPE code compiled in the sources. I'm using the version 
>> with crypto support so it should be ok.
> 
> ok.
> 
>>>> I'll give a try on Gateworks GW2347 and see if it will be working as it 
>>>> should or not.
>> Ok, I have a problem with initialization crypto on the gw2347 - the message:
>> "ixpCryptoAccCtxRegister failed 6" appears when I run openssl - I have 
> 
> Thats sounds weird.  It sounds like the crypto isn't working properly
> for some reason.
> 
> ixpCryptoAccCtxRegister doesn't need much to work.
> 
>> checked and the ixp4xx module when loading returns the error that cannot 
>> initialize crypto.
> 
> That is ok,  if the network driver init's the crypto then you will get
> this error since we cannot tell that it has been done,  yet it returns a
> fail if it is already initted.
> 
> Might be worth checking the details of the error.
> 
> Cheers,
> Davidm
> 
>>>> David McCullough napisa?(a):
>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>> Hi,
>>>>>>
>>>>>>> Which access library version are you using ?
>>>>>> The full name is ixp400accesslibrarywithcrypto-2.3.1
>>>>> Ok,  not sure we have tested OCF with version 2.3 of the access lib.
>>>>> It is part of our tree so I will try it.
>>>>>
>>>>> Not sure you mentioned which sources you are using,  but the
>>>>> uClinux-dist or SnapGear dists have very good IXP425 support
>>>>> and less patching ;-)
>>>>>
>>>>>>> Can you load ocf, cryptodev and ixp4xx all with debug enabled:
>>>>>>>
>>>>>>> 	modprobe ocf crypto_debug=1
>>>>>>> 	modprobe cryptodev cryptodev_debug=1
>>>>>>> 	modprobe ixp4xx ixp_debug=1
>>>>>>>
>>>>>>> The run the test, capture all the console output and send me a copy
>>>>>>> for reference.
>>>>>> The output is attached (ocf.log).
>>>>> Ok,  I will try and get some time on it in the next day or so, thanks.
>>>>>
>>>>> Actually,  just had a quick look,  I think the access lib is blowing the
>>>>> stack.  It is renowned for doing this.
>>>>>
>>>>> If you can try increasing the kernel stack size to 8K if it isn't
>>>>> already it might help.
>>>>>
>>>>> Otherwise,  you may find the info to fix it in our access lib patch:
>>>>>
>>>>> 	http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
>>>>>
>>>>> Or perhaps try the Snapgear/uClinux-dist if you have time.  We have all
>>>>> these sort or problems sorted already ;-)
>>>>>
>>>>>>> Have you tried turning off preemption ?  I don't think I have ever
>>>>>>> tested with that.
>>>>>> Yes, I have tried but didn't help :(
>>>>> Oh well,  looks like a real bug then ;-)
>>>>>
>>>>> Cheers,
>>>>> Davidm
>>>>>
>>>>>>>> David McCullough napisa?(a):
>>>>>>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I tried using ixp4xx module for hardware crypto on my ixp425 device 
>>>>>>>>>> with kernel 2.6.18-rt7 (PREEMPT_DESKTOP). I'm using ixp400 access 
>>>>>>>>>> library with crypto in version 2.3.1 and ixp400_eth driver in 
>>>>>>>>>> version 1.6 (with Intel's patch for OCF support - 
>>>>>>>>>> http://downloadcenter.intel.com/detail_desc.aspx?ProductID=2100&DwnldID=11266&agr=Y).
>>>>>>>>>>
>>>>>>>>>> I'm loading the modules like described in Intel readme:
>>>>>>>>>> mknod /dev/crypto c 10 70
>>>>>>>>>> mknod -m 666 /dev/ixNpe c 241 0
>>>>>>>>>> modprobe ixp400 >/dev/null 2>/dev/null
>>>>>>>>>> modprobe ixp400_eth >/dev/null 2>/dev/null
>>>>>>>>>> modprobe ocf
>>>>>>>>>> modprobe cryptodev
>>>>>>>>>> modprobe ixp4xx ixp_init_crypto=0
>>>>>>>>>>
>>>>>>>>>> Then when I run the: openssl speed -elapsed -evp des-ede3-cbc -cpu 
>>>>>>>>>> -engine cryptodev the device hangs (I'm using openssl-0.9.8a 
>>>>>>>>>> patched for OCF). The same happend when I tried to connect from the 
>>>>>>>>>> device using ssh.
>>>>>>>>>> I have enabled debugging and saw that the debugging from 
>>>>>>>>>> ixp_q_process is the last one displayed. So I have started adding 
>>>>>>>>>> some debug messages to that function and found that the hand 
>>>>>>>>>> appears after the following code:
>>>>>>>>>> if (IX_CRYPTO_ACC_STATUS_SUCCESS == status)
>>>>>>>>>> 	return;
>>>>>>>>>> So I have changed return to goto done and check what will happen - 
>>>>>>>>>> this time the openssl didn't hang and did it's work. But the ssh is 
>>>>>>>>>> not working - displays evp_crypt: EVP_Cipher failed and exits.
>>>>>>>>>>
>>>>>>>>>> I have tried the cryptosoft module instead of ixp4xx and this one 
>>>>>>>>>> works without any problems, so it seems that some problem exists in 
>>>>>>>>>> ixp4xx module.
>>>>>>>>>>
>>>>>>>>>> Do you have any clue what could be wrong? I'm almost sure that 
>>>>>>>>>> someday on older kernel (2.6.12) I got ixp4xx working without 
>>>>>>>>>> problems.
>>>>>>>>> You might want to try incorporating the latest code from the 
>>>>>>>>> sourceforge
>>>>>>>>> site.  I haven't seen a like up like you describe on the ixp for a 
>>>>>>>>> long
>>>>>>>>> time and I don't know exactly everything that is in the Intel 
>>>>>>>>> patches.
>>>>>>>>>
>>>>>>>>> Try out the latest download at:
>>>>>>>>>
>>>>>>>>> 	ocf-linux.sourceforge.net
>>>>>>>>>
>>>>>>>>> and then it will be much easier for me to help you.  I run IXP boards
>>>>>>>>> here and can easily try some things,
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Davidm
>>>>>>>>>
> 

Re: [Ocf-linux-users] SafeXcel 1141

[David M. <Dav...@se...>]

Jivin Nawang Chhetan lays it down ...
> Hi David,
>                I am trying to run "bench-ocf" with safe.ko . I dont
> see any debug messages( I insert the modules with debug messages
> enabled).  Seems even though open-ssl does all the stuff mentioned in
> the script "bench-ocf", 1141 card is not used. Can you give me some
> directions here ?

Send me the output of:

	lsmod

If you want to be sure only the safenet driver is used,  make sure that
you do not load cryptosoft or any other crypto driver.  Just load:

	ocf
	safe
	cryptodev

Cheers,
Davidm

> On 9/5/07, David McCullough <Dav...@se...> wrote:
> >
> > Jivin Nawang Chhetan lays it down ...
> > > Hi David,
> > >                I was testing OCF with SafeXcel 1141 card. Just wanted
> > > to know which version of the 1141 card you tested OCF with i.e. REV1
> > > or REV1.1.
> >
> > I think I have used both as I had to work around a bug in version1 IIRC.
> > I have also used the 1741.
> >
> > Note that none of these were cards,  but PCI chips on an embedded board,
> > but they look like cards ;-)
> >
> > Cheers,
> > Davidm
> >
> > --
> > 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

Re: [Ocf-linux-users] SafeXcel 1141

[Nawang C. <naw...@gm...>]

Hi David,
               I am trying to run "bench-ocf" with safe.ko . I dont
see any debug messages( I insert the modules with debug messages
enabled).  Seems even though open-ssl does all the stuff mentioned in
the script "bench-ocf", 1141 card is not used. Can you give me some
directions here ?



On 9/5/07, David McCullough <Dav...@se...> wrote:
>
> Jivin Nawang Chhetan lays it down ...
> > Hi David,
> >                I was testing OCF with SafeXcel 1141 card. Just wanted
> > to know which version of the 1141 card you tested OCF with i.e. REV1
> > or REV1.1.
>
> I think I have used both as I had to work around a bug in version1 IIRC.
> I have also used the 1741.
>
> Note that none of these were cards,  but PCI chips on an embedded board,
> but they look like cards ;-)
>
> Cheers,
> Davidm
>
> --
> David McCullough,  dav...@se...,   Ph:+61 734352815
> Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com
>


-- 
Nawang Chhetan
Software Engineer
SafeNet India.

Re: [Ocf-linux-users] SafeXcel 1141

[David M. <Dav...@se...>]

Jivin Nawang Chhetan lays it down ...
> Hi David,
>                I was testing OCF with SafeXcel 1141 card. Just wanted
> to know which version of the 1141 card you tested OCF with i.e. REV1
> or REV1.1.

I think I have used both as I had to work around a bug in version1 IIRC.
I have also used the 1741.

Note that none of these were cards,  but PCI chips on an embedded board,
but they look like cards ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

[Ocf-linux-users] SafeXcel 1141

[Nawang C. <naw...@gm...>]

Hi David,
               I was testing OCF with SafeXcel 1141 card. Just wanted
to know which version of the 1141 card you tested OCF with i.e. REV1
or REV1.1.


-- 
Nawang Chhetan
Software Engineer
SafeNet India.

Re: [Ocf-linux-users] About OCF Linux

[David M. <Dav...@se...>]

Jivin carl zhu lays it down ...
> Hi David,
> 
>  Sorry to bother you again.
> 
> I have tried your suggestions but faced complie error(in error.txt),I also
> attached what I changed in config.in.rar

You should build ipsec as a module when using OCF as a module,  as ipsec
with OCF support enabled relies on OCF being present.  In the snapgear
build env,  ocf is always a module,  so ipsec needs to be a module.

Do the following:

	make linux-2.4.x_clean

edit snapgear/linux-2.4.x/.config

	change CONFIG_KLIPS_OCF=y to CONFIG_KLIPS_OCF=m

run

	make oldconfig
	make dep
	make

See how that goes :-)

> After check the ocf/README, I find this information:
> 
>     * make sure that cryptodev.h (from ocf-linux.tar.gz) is installed as
>       crypto/cryptodev.h in an include directory that is used for building
>       applications for your platform.  For example on a host system that
>       might be:
> 
>               /usr/include/crypto/cryptodev.h
> 
> Now, I just change the snapgear\openswan\linux\net\ipsec\ipsec_ocf.h's
> cryptodev.h to correct path. Does this not right? How I need to do?

The addition of the:
	
	-I$(ROOTDIR)/modules/ocf

in the snapgear/linux-2.4.x/net/ipsec/Makefile file should have been
enough to fix and include errors.

Cheers,
Davidm

> On 9/3/07, David McCullough <Dav...@se...> wrote:
> >
> >
> > Hi Carl,
> >
> > Ok,  there are some bits missing from the openswan in your source tree
> > when using snapgear-3.4.
> >
> >        edit snapgear/linux-2.4.x/net/ipsec/Makefile, add the following to
> > the
> >        first instance of EXTRA_CFLAGS:
> >
> >                -I$(ROOTDIR)/modules/ocf
> >
> >        edit snapgear/openswan/linux/net/ipsec/Config.in.os2_4,  add the
> >        following line after the CONFIG_KLIPS_DEBUG line near the end.
> >
> >                bool '   IPsec: OCF HW Acceleration support'
> > CONFIG_KLIPS_OCF
> >
> > That should get you going.  To rebuild do:
> >
> >        make clean
> >        make oldconfig
> >                (answer y to KLIPS_OCF)
> >        make dep
> >        make
> >
> > See if that fixes it,  if not let me know and I sort it out,
> >
> > Cheers,
> > Davidm
> >
> >
> > Jivin carl zhu lays it down ...
> > > here you are, I have attached.
> > >
> > > On 8/31/07, David McCullough <Dav...@se...>
> > wrote:
> > > >
> > > >
> > > > Jivin carl zhu lays it down ...
> > > > > Hi David,
> > > > >
> > > > >     Glad to find you response so quickly.:)
> > > > >     Do you work for Snapgear?
> > > >
> > > > Yes.
> > > >
> > > > > I use snapgear v3.4 and ixp csr 1.4 with
> > > >
> > > > That is what we use.
> > > >
> > > > > crypto to build the code. My device is ADI Coyote like.
> > > > >     I just get the code and patch the driver to let it use
> > > > ethernet/crypto.
> > > >
> > > > Did you use the snapgear CSR patch ?
> > > >
> > > >
> > > > http://ftp.snapgear.org/pub/snapgear/src/snapgear-modules-20061012.sh
> > > >
> > > > Do you do a make config and enable OCF and the appropriate modules ?
> > > >
> > > > > Then I get such performance.(openswan + linux2.4.x)
> > > >
> > > > So are you now getting full performance or not ?
> > > >
> > > > If not,  send me a copy these files and I should be able to sort it
> > out.
> > > >
> > > >        snapgear/linux-2.4.x/.config
> > > >        snapgear/modules/.config
> > > >        snapgear/config/.config
> > > >
> > > > Cheers.
> > > > Davidm
> > > >
> > > > > On 8/31/07, David McCullough <Dav...@se...>
> > > > wrote:
> > > > > >
> > > > > >
> > > > > > Jivin carl zhu lays it down ...
> > > > > > > Hi David,
> > > > > > >
> > > > > > >    I have got your OCF linux code, but I have some question
> > about
> > > > it.
> > > > > > > because source forge's mail list seems no one to answer. I send
> > the
> > > > mail
> > > > > > to
> > > > > > > you.
> > > > > >
> > > > > > I have not seen any mailing list mails or "pending" messages.  Are
> > you
> > > > > > sending to the correct address ?  You should subscribe before
> > mailing
> > > > > > to get a better response time.
> > > > > >
> > > > > > >   the questions are:
> > > > > > >   1, I use ocf-bench, get such result:
> > > > > > > Using /lib/modules/2.4.32-uc0/kernel/ocf/ocf-bench.o
> > > > > > > Crypto Speed tests
> > > > > > > OCF: testing ...
> > > > > > > OCF: 1044 requests of 1500 bytes in 17 jiffies
> > > > > > > IXP: testing ...
> > > > > > > IXP: 1044 requests of 1500 bytes in 13 jiffies
> > > > > > >     lsmod's result:
> > > > > > >     Module                  Size  Used by
> > > > > > > ixp4xx                  5672   0 (unused)
> > > > > > > cryptodev               5868   0 (unused)
> > > > > > > ocf                    15616   0 [ixp4xx cryptodev]
> > > > > > > ixp425_eth             16700   2
> > > > > > > ixp400                412032   0 [ixp4xx ixp425_eth]
> > > > > > >    But I use openswan to build the VPN, the tcp throughput will
> > be 3
> > > > > > Mbps,
> > > > > > > if not use VPN, the throughput will be 70Mbps.
> > > > > > >    I dont know why? I think I can get 40-50Mbps in VPN...
> > > > > >
> > > > > > On an IXP you should get from 38-45Mbps depening on clock speed
> > etc.
> > > > > >
> > > > > > 3Mbps is slow even for software crypto.  Make sure you do not have
> > > > > > cryptosoft loaded.
> > > > > >
> > > > > > >  2, Due to problem 1, I think the root cause may happened on OCF
> > > > crypto
> > > > > > API
> > > > > > > with Openswan, but I can't find any document to discuss it. Do
> > you
> > > > have
> > > > > > > some?
> > > > > >
> > > > > > Most likely you have openswan configured incorrectly.  Check that
> > > > > > CONFIG_KLIPS_OCF is enabled in the kernel build.
> > > > > >
> > > > > > Run "cryptotest" and check the throughput.  If everything look
> > > > > > accelerated,  then you need to work out what is wrong with your
> > > > openswan
> > > > > > build/compile that is not enabled OCF support.
> > > > > >
> > > > > > Cheers,
> > > > > > Davidm
> > > > > >
> > > > > > --
> > > > > > David McCullough,  dav...@se...,   Ph:+61
> > > > > > 734352815
> > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > http://www.cyberguard.com
> > > > > >
> > > >
> > > > --
> > > > David McCullough,  dav...@se...,   Ph:+61
> > > > 734352815
> > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > http://www.cyberguard.com
> > > >
> >
> >
> >
> > --
> > David McCullough,  dav...@se...,   Ph:+61
> > 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org
> > http://www.cyberguard.com
> >

> make CFLAGS="-D__KERNEL__ -I/home/carl_zhu/snapgear/linux-2.4.x/include  -Wall -Wstrict-prototypes -Wno-trigraphs -O -fno-strict-aliasing -fno-common -Uarm -fno-common -pipe -mapcs-32 -D__LINUX_ARM_ARCH__=5 -mcpu=xscale -mtune=xscale -malignment-traps -msoft-float -Uarm " -C  /home/carl_zhu/snapgear/modules
> make[2]: Entering directory `/home/carl_zhu/snapgear/modules'
> make all_targets
> make[3]: Entering directory `/home/carl_zhu/snapgear/modules'
> make[3]: Nothing to be done for `all_targets'.
> make[3]: Leaving directory `/home/carl_zhu/snapgear/modules'
> make[2]: Leaving directory `/home/carl_zhu/snapgear/modules'
> arm-linux-ld -EB -p -X -T arch/arm/vmlinux.lds arch/arm/kernel/head-armv.o arch/arm/kernel/init_task.o init/main.o init/version.o init/do_mounts.o \
>         --start-group \
>         arch/arm/kernel/kernel.o arch/arm/mm/mm.o arch/arm/mach-ixp425/ixp425.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
>          drivers/char/char.o drivers/serial/serial.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/pci/driver.o drivers/mtd/mtdlink.o drivers/media/media.o crypto/crypto.o \
>         net/network.o \
>         arch/arm/nwfpe/math-emu.o arch/arm/lib/lib.a /home/carl_zhu/snapgear/linux-2.4.x/lib/lib.a \
>         --end-group \
>         -o vmlinux
> net/network.o: In function `ipsec_ocf_sa_init':
> sysctl_net.c:(.text+0x8a264): undefined reference to `crypto_newsession'
> sysctl_net.c:(.text+0x8a284): undefined reference to `crypto_newsession'
> sysctl_net.c:(.text+0x8a2a4): undefined reference to `crypto_newsession'
> net/network.o: In function `ipsec_ocf_sa_free':
> sysctl_net.c:(.text+0x8a35c): undefined reference to `crypto_freesession'
> net/network.o: In function `ipsec_ocf_rcv_cb':
> sysctl_net.c:(.text+0x8a4b4): undefined reference to `crypto_freereq'
> net/network.o: In function `ipsec_ocf_rcv':
> sysctl_net.c:(.text+0x8a60c): undefined reference to `crypto_getreq'
> sysctl_net.c:(.text+0x8a884): undefined reference to `crypto_dispatch'
> net/network.o: In function `ipsec_ocf_xmit_cb':
> sysctl_net.c:(.text+0x8a98c): undefined reference to `crypto_freereq'
> net/network.o: In function `ipsec_ocf_xmit':
> sysctl_net.c:(.text+0x8aae0): undefined reference to `crypto_getreq'
> sysctl_net.c:(.text+0x8ad2c): undefined reference to `crypto_dispatch'
> net/network.o: In function `ipsec_ocf_check_alg':
> sysctl_net.c:(.text+0x8adb4): undefined reference to `crypto_newsession'
> sysctl_net.c:(.text+0x8ade8): undefined reference to `crypto_freesession'


-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com