Thread: Re: [Ocf-linux-users] PD: OCF's ixp4xx freeze on 2.6.18-rt7
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users
|
From: Tomasz R. <tro...@pr...> - 2007-10-16 13:12:01
|
Hi David,
Do you made any progress?
Regards,
Tomasz
> -----Wiadomość oryginalna-----
> > Od: David McCullough [mailto:Dav...@se...]
> > Wysłano: Pt 2007-09-28 15:25
> > Do: Rostanski, Tomasz
> > DW: ocf...@li...
> > Temat: Re: OCF's ixp4xx freeze on 2.6.18-rt7
> >
> >
> > Jivin Tomasz Rostanski lays it down ...
>> > > David,
>> > >
>>> > > >The latest I can try with easily is 2.3. Do you have that ?
>> > >
>> > > We've been using version 2.3 but the OCF wasn't working too.
Some time
>> > > ago we have moved to the version 2.4 because we have found it
working
>> > > faster that the 2.3 (or maybe I have configured it better).
> >
> > :-)
> >
>> > > I know the version 3.0 is released so I would like to try it
too. It
>> > > should have the ethernet driver written better, so perhaps
someday I
>> > > would need to go to 3.0.
> >
> > Check the release notes for 3.0, ixp42x has been dropped, ixp43x and
> > ixp46x are still supported. Looks like 2.4 is the last for the
> > ixp420/425.
> >
>>> > > >I believe we have 2.4 going into our tree very soon now (week
or so)
>>> > > >so I can try it then.
>> > >
>> > > Ok, so please let me know how would it work then.
> >
> > Once it's in I'll let you know,
> >
> > Cheers,
> > Davidm
> >
>>>> > > >>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
>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>
>>> > > >
>> > >
> >
> > --
> > David McCullough, dav...@se..., Ph:+61
734352815
> > Secure Computing - SnapGear http://www.uCdot.org
http://www.cyberguard.com
> >
> >
> >
|
|
From: David M. <Dav...@se...> - 2007-10-19 05:37:18
|
Jivin Tomasz Rostanski lays it down ...
> Hi David,
>
> Do you made any progress?
Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and
ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed
works fine (although throughput seems to be down).
The driver is at least processing requests ok.
Are you installing the correct NPE code with something like:
cat /etc/IxNpeMicrocode.dat >/dev/ixNpe
Cheers,
Davidm
> > -----Wiadomość oryginalna-----
> > > Od: David McCullough [mailto:Dav...@se...]
> > > Wysłano: Pt 2007-09-28 15:25
> > > Do: Rostanski, Tomasz
> > > DW: ocf...@li...
> > > Temat: Re: OCF's ixp4xx freeze on 2.6.18-rt7
> > >
> > >
> > > Jivin Tomasz Rostanski lays it down ...
> >> > > David,
> >> > >
> >>> > > >The latest I can try with easily is 2.3. Do you have that ?
> >> > >
> >> > > We've been using version 2.3 but the OCF wasn't working too.
> Some time
> >> > > ago we have moved to the version 2.4 because we have found it
> working
> >> > > faster that the 2.3 (or maybe I have configured it better).
> > >
> > > :-)
> > >
> >> > > I know the version 3.0 is released so I would like to try it
> too. It
> >> > > should have the ethernet driver written better, so perhaps
> someday I
> >> > > would need to go to 3.0.
> > >
> > > Check the release notes for 3.0, ixp42x has been dropped, ixp43x and
> > > ixp46x are still supported. Looks like 2.4 is the last for the
> > > ixp420/425.
> > >
> >>> > > >I believe we have 2.4 going into our tree very soon now (week
> or so)
> >>> > > >so I can try it then.
> >> > >
> >> > > Ok, so please let me know how would it work then.
> > >
> > > Once it's in I'll let you know,
> > >
> > > Cheers,
> > > Davidm
> > >
> >>>> > > >>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
> >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>
> >>> > > >
> >> > >
> > >
> > > --
> > > 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
|
|
From: Tomasz R. <tro...@pr...> - 2007-10-19 06:28:24
|
Hi David,
> Jivin Tomasz Rostanski lays it down ...
>> Hi David,
>>
>> Do you made any progress?
>
> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and
> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed
> works fine (although throughput seems to be down).
>
> The driver is at least processing requests ok.
>
> Are you installing the correct NPE code with something like:
>
> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe
I have NPE code compiled in. I have also made a build without compiling
it in, the result was the same.
Tomasz
>>> -----Wiadomość oryginalna-----
>>>> Od: David McCullough [mailto:Dav...@se...]
>>>> Wysłano: Pt 2007-09-28 15:25
>>>> Do: Rostanski, Tomasz
>>>> DW: ocf...@li...
>>>> Temat: Re: OCF's ixp4xx freeze on 2.6.18-rt7
>>>>
>>>>
>>>> Jivin Tomasz Rostanski lays it down ...
>>>>>> David,
>>>>>>
>>>>>>>> The latest I can try with easily is 2.3. Do you have that ?
>>>>>> We've been using version 2.3 but the OCF wasn't working too.
>> Some time
>>>>>> ago we have moved to the version 2.4 because we have found it
>> working
>>>>>> faster that the 2.3 (or maybe I have configured it better).
>>>> :-)
>>>>
>>>>>> I know the version 3.0 is released so I would like to try it
>> too. It
>>>>>> should have the ethernet driver written better, so perhaps
>> someday I
>>>>>> would need to go to 3.0.
>>>> Check the release notes for 3.0, ixp42x has been dropped, ixp43x and
>>>> ixp46x are still supported. Looks like 2.4 is the last for the
>>>> ixp420/425.
>>>>
>>>>>>>> I believe we have 2.4 going into our tree very soon now (week
>> or so)
>>>>>>>> so I can try it then.
>>>>>> Ok, so please let me know how would it work then.
>>>> Once it's in I'll let you know,
>>>>
>>>> Cheers,
>>>> Davidm
>>>>
>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> --
>>>> David McCullough, dav...@se..., Ph:+61
>> 734352815
>>>> Secure Computing - SnapGear http://www.uCdot.org
>> http://www.cyberguard.com
>>>>
>>>>
>
|
|
From: David M. <Dav...@se...> - 2007-10-23 22:10:49
|
Jivin Tomasz Rostanski lays it down ... > Hi David, > >Jivin Tomasz Rostanski lays it down ... > >>Hi David, > >> > >>Do you made any progress? > > > >Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and > >ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed > >works fine (although throughput seems to be down). > > > >The driver is at least processing requests ok. > > > >Are you installing the correct NPE code with something like: > > > > cat /etc/IxNpeMicrocode.dat >/dev/ixNpe > > I have NPE code compiled in. I have also made a build without compiling > it in, the result was the same. We have an updated patch for CSR-2.4 at: http://www.snapgear.org/snapgear/downloads.html might be something in there that helps you. I am effectively running SG Linux 3.5 on my IXP425's with that access lib patch applied, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Tomasz R. <tro...@pr...> - 2007-10-24 07:41:09
|
Hi David, > Jivin Tomasz Rostanski lays it down ... >> Hi David, >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>> >>>> Do you made any progress? >>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>> works fine (although throughput seems to be down). >>> >>> The driver is at least processing requests ok. >>> >>> Are you installing the correct NPE code with something like: >>> >>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >> I have NPE code compiled in. I have also made a build without compiling >> it in, the result was the same. > > We have an updated patch for CSR-2.4 at: > > http://www.snapgear.org/snapgear/downloads.html > > might be something in there that helps you. I am effectively running SG > Linux 3.5 on my IXP425's with that access lib patch applied, I have imported this patch (not everything I need) to our trunk and checked with the OCF 20070727 and... is working! Thank you for your help. Tomasz |
|
From: David M. <Dav...@se...> - 2007-10-24 10:37:55
|
Jivin Tomasz Rostanski lays it down ... > Hi David, > > >Jivin Tomasz Rostanski lays it down ... > >>Hi David, > >>>Jivin Tomasz Rostanski lays it down ... > >>>>Hi David, > >>>> > >>>>Do you made any progress? > >>>Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and > >>>ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed > >>>works fine (although throughput seems to be down). > >>> > >>>The driver is at least processing requests ok. > >>> > >>>Are you installing the correct NPE code with something like: > >>> > >>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe > >>I have NPE code compiled in. I have also made a build without compiling > >>it in, the result was the same. > > > >We have an updated patch for CSR-2.4 at: > > > > http://www.snapgear.org/snapgear/downloads.html > > > >might be something in there that helps you. I am effectively running SG > >Linux 3.5 on my IXP425's with that access lib patch applied, > > > I have imported this patch (not everything I need) to our trunk and > checked with the OCF 20070727 and... is working! > Thank you for your help. No problems, glad it worked ;-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Tomasz R. <tro...@pr...> - 2007-10-26 12:24:42
|
David, > Jivin Tomasz Rostanski lays it down ... >> Hi David, >> >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>>> Jivin Tomasz Rostanski lays it down ... >>>>>> Hi David, >>>>>> >>>>>> Do you made any progress? >>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>> works fine (although throughput seems to be down). >>>>> >>>>> The driver is at least processing requests ok. >>>>> >>>>> Are you installing the correct NPE code with something like: >>>>> >>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>> I have NPE code compiled in. I have also made a build without compiling >>>> it in, the result was the same. >>> We have an updated patch for CSR-2.4 at: >>> >>> http://www.snapgear.org/snapgear/downloads.html >>> >>> might be something in there that helps you. I am effectively running SG >>> Linux 3.5 on my IXP425's with that access lib patch applied, >> >> I have imported this patch (not everything I need) to our trunk and >> checked with the OCF 20070727 and... is working! >> Thank you for your help. > > No problems, glad it worked ;-) But now I have a problems with openssh. When I run first "openssl speed -evp des -elapsed -engine cryptodev" I got: # ssh 192.168.0.10 [ 151.390000] ixp_newsession() [ 151.400000] ixp_freesession() [ 151.400000] ixp_newsession() [ 151.400000] ixp_freesession() [ 151.410000] ixp_newsession() [ 151.410000] ixp_freesession() [ 151.410000] ixp_newsession() [ 151.420000] ixp_freesession() [ 151.440000] ixp_newsession() [ 151.440000] ixp_freesession() [ 151.450000] ixp_newsession() [ 151.450000] ixp_freesession() [ 151.450000] ixp_newsession() [ 151.460000] ixp_freesession() [ 151.460000] ixp_newsession() [ 151.460000] ixp_freesession() [ 151.470000] ixp_newsession() [ 151.470000] ixp_freesession() [ 151.470000] ixp_newsession() [ 151.470000] ixp_freesession() [ 151.480000] ixp_newsession() [ 151.480000] ixp_freesession() [ 151.480000] ixp_newsession() [ 151.490000] ixp_freesession() The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. [ 153.270000] ixp_newsession() [ 153.270000] ixp_newsession() [ 153.280000] ixp_process() [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) [ 153.280000] ixp_process_pending(c3575400) [ 153.290000] ixp_process_pending in while [ 153.290000] ixp_q_process(c28949e0) evp_crypt: EVP_Cipher failed [ 153.300000] ixp_freesession() [ 153.300000] ixp_freesession() but when I run ssh without running openssl speed before I got the freeze in ixp_q_process. Do you use some patch for ssh too? I found some patches which adds some openssl engine initialization to ssh but it won't helped. Tomasz |
|
From: Tomasz R. <tro...@pr...> - 2007-11-09 10:13:17
|
David, > David, > >> Jivin Tomasz Rostanski lays it down ... >>> Hi David, >>> >>>> Jivin Tomasz Rostanski lays it down ... >>>>> Hi David, >>>>>> Jivin Tomasz Rostanski lays it down ... >>>>>>> Hi David, >>>>>>> >>>>>>> Do you made any progress? >>>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>>> works fine (although throughput seems to be down). >>>>>> >>>>>> The driver is at least processing requests ok. >>>>>> >>>>>> Are you installing the correct NPE code with something like: >>>>>> >>>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>>> I have NPE code compiled in. I have also made a build without >>>>> compiling it in, the result was the same. >>>> We have an updated patch for CSR-2.4 at: >>>> >>>> http://www.snapgear.org/snapgear/downloads.html >>>> >>>> might be something in there that helps you. I am effectively >>>> running SG >>>> Linux 3.5 on my IXP425's with that access lib patch applied, >>> >>> I have imported this patch (not everything I need) to our trunk and >>> checked with the OCF 20070727 and... is working! >>> Thank you for your help. >> >> No problems, glad it worked ;-) > > But now I have a problems with openssh. > > When I run first "openssl speed -evp des -elapsed -engine cryptodev" > > I got: > > # ssh 192.168.0.10 > [ 151.390000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.400000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.410000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.420000] ixp_freesession() > [ 151.440000] ixp_newsession() > [ 151.440000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.450000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.460000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.480000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.490000] ixp_freesession() > The authenticity of host '192.168.0.10 (192.168.0.10)' can't be > established. > RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. > [ 153.270000] ixp_newsession() > [ 153.270000] ixp_newsession() > [ 153.280000] ixp_process() > [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) > [ 153.280000] ixp_process_pending(c3575400) > [ 153.290000] ixp_process_pending in while > [ 153.290000] ixp_q_process(c28949e0) > evp_crypt: EVP_Cipher failed > [ 153.300000] ixp_freesession() > [ 153.300000] ixp_freesession() > > but when I run ssh without running openssl speed before I got the freeze > in ixp_q_process. > > Do you use some patch for ssh too? I found some patches which adds some > openssl engine initialization to ssh but it won't helped. I have used the cryptosoft module with the debugging enabled instead of ixp4xx and ssh worked. So it seems that there is still some problem with the ixp4xx module... Tomasz |
|
From: David M. <Dav...@se...> - 2007-11-09 10:50:07
|
Jivin Tomasz Rostanski lays it down ... ... > >The authenticity of host '192.168.0.10 (192.168.0.10)' can't be > >established. > >RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. > >Are you sure you want to continue connecting (yes/no)? yes > >Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. > >[ 153.270000] ixp_newsession() > >[ 153.270000] ixp_newsession() > >[ 153.280000] ixp_process() > >[ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) > >[ 153.280000] ixp_process_pending(c3575400) > >[ 153.290000] ixp_process_pending in while > >[ 153.290000] ixp_q_process(c28949e0) > >evp_crypt: EVP_Cipher failed > >[ 153.300000] ixp_freesession() > >[ 153.300000] ixp_freesession() > > > >but when I run ssh without running openssl speed before I got the freeze > >in ixp_q_process. > > > >Do you use some patch for ssh too? I found some patches which adds some > > openssl engine initialization to ssh but it won't helped. > > I have used the cryptosoft module with the debugging enabled instead of > ixp4xx and ssh worked. So it seems that there is still some problem with > the ixp4xx module... Good test, did you double check that cryptosoft was doing the work by enabling debug ? I have just finished cleaning up the 2.6.23 support, so I should have a chance to test ssh next week, just bug me if I don't ;-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Tomasz R. <tro...@pr...> - 2007-11-09 11:22:37
|
David, > Jivin Tomasz Rostanski lays it down ... > ... >>> The authenticity of host '192.168.0.10 (192.168.0.10)' can't be >>> established. >>> RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. >>> Are you sure you want to continue connecting (yes/no)? yes >>> Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. >>> [ 153.270000] ixp_newsession() >>> [ 153.270000] ixp_newsession() >>> [ 153.280000] ixp_process() >>> [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) >>> [ 153.280000] ixp_process_pending(c3575400) >>> [ 153.290000] ixp_process_pending in while >>> [ 153.290000] ixp_q_process(c28949e0) >>> evp_crypt: EVP_Cipher failed >>> [ 153.300000] ixp_freesession() >>> [ 153.300000] ixp_freesession() >>> >>> but when I run ssh without running openssl speed before I got the freeze >>> in ixp_q_process. >>> >>> Do you use some patch for ssh too? I found some patches which adds some >>> openssl engine initialization to ssh but it won't helped. >> I have used the cryptosoft module with the debugging enabled instead of >> ixp4xx and ssh worked. So it seems that there is still some problem with >> the ixp4xx module... > > Good test, did you double check that cryptosoft was doing the work by > enabling debug ? Yes. > I have just finished cleaning up the 2.6.23 support, so I should have a > chance to test ssh next week, just bug me if I don't ;-) I will do ;) Tomasz |
|
From: David M. <Dav...@se...> - 2007-12-14 00:35:15
|
Jivin Tomasz Rostanski lays it down ... > David, > > >Jivin Tomasz Rostanski lays it down ... > >>Hi David, > >> > >>>Jivin Tomasz Rostanski lays it down ... > >>>>Hi David, > >>>>>Jivin Tomasz Rostanski lays it down ... > >>>>>>Hi David, > >>>>>> > >>>>>>Do you made any progress? > >>>>>Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and > >>>>>ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed > >>>>>works fine (although throughput seems to be down). > >>>>> > >>>>>The driver is at least processing requests ok. > >>>>> > >>>>>Are you installing the correct NPE code with something like: > >>>>> > >>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe > >>>>I have NPE code compiled in. I have also made a build without compiling > >>>>it in, the result was the same. > >>>We have an updated patch for CSR-2.4 at: > >>> > >>> http://www.snapgear.org/snapgear/downloads.html > >>> > >>>might be something in there that helps you. I am effectively running SG > >>>Linux 3.5 on my IXP425's with that access lib patch applied, > >> > >>I have imported this patch (not everything I need) to our trunk and > >>checked with the OCF 20070727 and... is working! > >>Thank you for your help. > > > >No problems, glad it worked ;-) > > But now I have a problems with openssh. > > When I run first "openssl speed -evp des -elapsed -engine cryptodev" > > I got: > > # ssh 192.168.0.10 > [ 151.390000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.400000] ixp_newsession() > [ 151.400000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.410000] ixp_freesession() > [ 151.410000] ixp_newsession() > [ 151.420000] ixp_freesession() > [ 151.440000] ixp_newsession() > [ 151.440000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.450000] ixp_freesession() > [ 151.450000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.460000] ixp_newsession() > [ 151.460000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.470000] ixp_newsession() > [ 151.470000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.480000] ixp_freesession() > [ 151.480000] ixp_newsession() > [ 151.490000] ixp_freesession() > The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. > RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. > [ 153.270000] ixp_newsession() > [ 153.270000] ixp_newsession() > [ 153.280000] ixp_process() > [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) > [ 153.280000] ixp_process_pending(c3575400) > [ 153.290000] ixp_process_pending in while > [ 153.290000] ixp_q_process(c28949e0) > evp_crypt: EVP_Cipher failed > [ 153.300000] ixp_freesession() > [ 153.300000] ixp_freesession() > > but when I run ssh without running openssl speed before I got the freeze > in ixp_q_process. > > Do you use some patch for ssh too? I found some patches which adds some > openssl engine initialization to ssh but it won't helped. Sorry I took so long to get back to you on this. I have just gone through the above sequences here and ssh works fine for me in both cases. I am not getting the "evp_crypt: EVP_Cipher failed" error either. I tried both into my ixp and out of the ixp board. Which versions of openssl/openssh are you using ? Not that it should really matter. I am running with CSR 2.4 and 0.9.8g (I've updated) and ssh 4.7p1, probably also updated, but no patches are needed for ssh IIRC. I don't see any ixp_perform_cb, to me this says the ixp crypto is not happy still. Does the "openssl speed" test give you numbers comparable to that on the ocf-linux web page benchmarks section ? If not it sounds like the crypto is just not working, which comes back to the correct NPE code or the call to ixCryptoAccInit failing. Perhaps add some debug to that code to make sure he crypto engine is started correctly. Look for a kernel message: ixCryptoAccInit failed, assuming already initialised! when loading the ixp4xx driver, if you get that investigate further ;-) I should have a new version out today (famous last words). It might be good to try it out and see if there has been any improvements. Quite a lot of potential locking/sleeping and other bus have been fixed and you may be just hitting one of those. Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Tomasz R. <tro...@pr...> - 2007-12-17 09:40:53
|
Hi David, David McCullough pisze: > Jivin Tomasz Rostanski lays it down ... >> David, >> >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>> >>>>> Jivin Tomasz Rostanski lays it down ... >>>>>> Hi David, >>>>>>> Jivin Tomasz Rostanski lays it down ... >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Do you made any progress? >>>>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>>>> works fine (although throughput seems to be down). >>>>>>> >>>>>>> The driver is at least processing requests ok. >>>>>>> >>>>>>> Are you installing the correct NPE code with something like: >>>>>>> >>>>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>>>> I have NPE code compiled in. I have also made a build without compiling >>>>>> it in, the result was the same. >>>>> We have an updated patch for CSR-2.4 at: >>>>> >>>>> http://www.snapgear.org/snapgear/downloads.html >>>>> >>>>> might be something in there that helps you. I am effectively running SG >>>>> Linux 3.5 on my IXP425's with that access lib patch applied, >>>> I have imported this patch (not everything I need) to our trunk and >>>> checked with the OCF 20070727 and... is working! >>>> Thank you for your help. >>> No problems, glad it worked ;-) >> But now I have a problems with openssh. >> >> When I run first "openssl speed -evp des -elapsed -engine cryptodev" >> >> I got: >> >> # ssh 192.168.0.10 >> [ 151.390000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.400000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.410000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.420000] ixp_freesession() >> [ 151.440000] ixp_newsession() >> [ 151.440000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.450000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.460000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.480000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.490000] ixp_freesession() >> The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. >> RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. >> Are you sure you want to continue connecting (yes/no)? yes >> Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. >> [ 153.270000] ixp_newsession() >> [ 153.270000] ixp_newsession() >> [ 153.280000] ixp_process() >> [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) >> [ 153.280000] ixp_process_pending(c3575400) >> [ 153.290000] ixp_process_pending in while >> [ 153.290000] ixp_q_process(c28949e0) >> evp_crypt: EVP_Cipher failed >> [ 153.300000] ixp_freesession() >> [ 153.300000] ixp_freesession() >> >> but when I run ssh without running openssl speed before I got the freeze >> in ixp_q_process. >> >> Do you use some patch for ssh too? I found some patches which adds some >> openssl engine initialization to ssh but it won't helped. > > Sorry I took so long to get back to you on this. > > I have just gone through the above sequences here and ssh works fine for > me in both cases. I am not getting the "evp_crypt: EVP_Cipher failed" > error either. I tried both into my ixp and out of the ixp board. > > Which versions of openssl/openssh are you using ? Not that it should > really matter. I am running with CSR 2.4 and 0.9.8g (I've updated) and > ssh 4.7p1, probably also updated, but no patches are needed for ssh > IIRC. > > I don't see any ixp_perform_cb, to me this says the ixp crypto is not > happy still. Does the "openssl speed" test give you numbers comparable > to that on the ocf-linux web page benchmarks section ? If not it sounds > like the crypto is just not working, which comes back to the correct > NPE code or the call to ixCryptoAccInit failing. Perhaps add some debug > to that code to make sure he crypto engine is started correctly. Look > for a kernel message: > > ixCryptoAccInit failed, assuming already initialised! > > when loading the ixp4xx driver, if you get that investigate further ;-) > > I should have a new version out today (famous last words). It might be > good to try it out and see if there has been any improvements. Quite a > lot of potential locking/sleeping and other bus have been fixed and you > may be just hitting one of those. I gave a try and... the openssl speed hangs. The cryptodev stays forever in do {...} while ((crp->crp_flags & CRYPTO_F_DONE) == 0) loop. The ixp driver ends ixp_proces_pending but never call crypto_done() function (with ixp->ixp_q having only one element). The initialization of crypto engine seems to be ok. Tomasz |
|
From: Tomasz R. <tro...@pr...> - 2007-12-28 08:27:39
|
Hi David, David McCullough wrote: > Jivin Tomasz Rostanski lays it down ... >> David, >> >>> Jivin Tomasz Rostanski lays it down ... >>>> Hi David, >>>> >>>>> Jivin Tomasz Rostanski lays it down ... >>>>>> Hi David, >>>>>>> Jivin Tomasz Rostanski lays it down ... >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Do you made any progress? >>>>>>> Yep, sorry for the delay, just ran it up on 2.6.23 using CSR2.4 and >>>>>>> ocf. Seems to be ok. Haven't tried ipsec yet, but openssl speed >>>>>>> works fine (although throughput seems to be down). >>>>>>> >>>>>>> The driver is at least processing requests ok. >>>>>>> >>>>>>> Are you installing the correct NPE code with something like: >>>>>>> >>>>>>> cat /etc/IxNpeMicrocode.dat >/dev/ixNpe >>>>>> I have NPE code compiled in. I have also made a build without compiling >>>>>> it in, the result was the same. >>>>> We have an updated patch for CSR-2.4 at: >>>>> >>>>> http://www.snapgear.org/snapgear/downloads.html >>>>> >>>>> might be something in there that helps you. I am effectively running SG >>>>> Linux 3.5 on my IXP425's with that access lib patch applied, >>>> I have imported this patch (not everything I need) to our trunk and >>>> checked with the OCF 20070727 and... is working! >>>> Thank you for your help. >>> No problems, glad it worked ;-) >> But now I have a problems with openssh. >> >> When I run first "openssl speed -evp des -elapsed -engine cryptodev" >> >> I got: >> >> # ssh 192.168.0.10 >> [ 151.390000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.400000] ixp_newsession() >> [ 151.400000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.410000] ixp_freesession() >> [ 151.410000] ixp_newsession() >> [ 151.420000] ixp_freesession() >> [ 151.440000] ixp_newsession() >> [ 151.440000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.450000] ixp_freesession() >> [ 151.450000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.460000] ixp_newsession() >> [ 151.460000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.470000] ixp_newsession() >> [ 151.470000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.480000] ixp_freesession() >> [ 151.480000] ixp_newsession() >> [ 151.490000] ixp_freesession() >> The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established. >> RSA key fingerprint is 4d:4c:97:d9:0b:48:35:f4:5d:e5:3b:1a:55:ff:87:57. >> Are you sure you want to continue connecting (yes/no)? yes >> Warning: Permanently added '192.168.0.10' (RSA) to the list of known hosts. >> [ 153.270000] ixp_newsession() >> [ 153.270000] ixp_newsession() >> [ 153.280000] ixp_process() >> [ 153.280000] ixp_register_cb(-1031187288, 00000000, 0) >> [ 153.280000] ixp_process_pending(c3575400) >> [ 153.290000] ixp_process_pending in while >> [ 153.290000] ixp_q_process(c28949e0) >> evp_crypt: EVP_Cipher failed >> [ 153.300000] ixp_freesession() >> [ 153.300000] ixp_freesession() >> >> but when I run ssh without running openssl speed before I got the freeze >> in ixp_q_process. >> >> Do you use some patch for ssh too? I found some patches which adds some >> openssl engine initialization to ssh but it won't helped. > > Sorry I took so long to get back to you on this. > > I have just gone through the above sequences here and ssh works fine for > me in both cases. I am not getting the "evp_crypt: EVP_Cipher failed" > error either. I tried both into my ixp and out of the ixp board. > > Which versions of openssl/openssh are you using ? Not that it should > really matter. I am running with CSR 2.4 and 0.9.8g (I've updated) and > ssh 4.7p1, probably also updated, but no patches are needed for ssh > IIRC. > > I don't see any ixp_perform_cb, to me this says the ixp crypto is not > happy still. Does the "openssl speed" test give you numbers comparable > to that on the ocf-linux web page benchmarks section ? If not it sounds > like the crypto is just not working, which comes back to the correct > NPE code or the call to ixCryptoAccInit failing. Perhaps add some debug > to that code to make sure he crypto engine is started correctly. Look > for a kernel message: > > ixCryptoAccInit failed, assuming already initialised! > > when loading the ixp4xx driver, if you get that investigate further ;-) > > I should have a new version out today (famous last words). It might be > good to try it out and see if there has been any improvements. Quite a > lot of potential locking/sleeping and other bus have been fixed and you > may be just hitting one of those. I have used the latest version but got the same. However I have finally found out what causes the freezes for me. It's something in ixp400_eth driver. When I use the driver in version 1.4 with ixp400 access lib 2.4 the crypto works. When I use driver in version 1.6 or 1.7 it freezes. I also made a test and use ixp400_eth 1.6 with ixp400 access lib 2.0 and get the freeze (1.4 works perfect). So it seems that the problem is being caused by something in ixp400_eth driver. Unfortunately the number of changes between 1.4 and 1.6 is huge and I don't have the driver in version 1.5 to check it so it will be difficult to find out what causes problem :( As soon as I track it down I let you know what was wrong. Regards, Tomasz |
|
From: David M. <Dav...@se...> - 2007-12-28 09:15:54
|
Jivin Tomasz Rostanski lays it down ... ... > >I should have a new version out today (famous last words). It might be > >good to try it out and see if there has been any improvements. Quite a > >lot of potential locking/sleeping and other bus have been fixed and you > >may be just hitting one of those. > > I have used the latest version but got the same. However I have finally > found out what causes the freezes for me. It's something in ixp400_eth > driver. When I use the driver in version 1.4 with ixp400 access lib 2.4 > the crypto works. When I use driver in version 1.6 or 1.7 it freezes. I > also made a test and use ixp400_eth 1.6 with ixp400 access lib 2.0 and > get the freeze (1.4 works perfect). > So it seems that the problem is being caused by something in ixp400_eth > driver. > Unfortunately the number of changes between 1.4 and 1.6 is huge and I > don't have the driver in version 1.5 to check it so it will be difficult > to find out what causes problem :( As soon as I track it down I let you > know what was wrong. Hmm, at least it's a start. Sorry I took so long to reply, I was on leave since the release went out (Good timing I know ;-) Let us know how you go, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X