In message <E1ERaHu-0002NH-00@smeg.dsg.stanford.edu>Jonathan Stone writes
>
>In message <20051016193507.GA2806@panix.com>, Thor Lancelot Simon writes:
>
>>I've been working on the Hifn crypto driver recently and have noticed
>>something startling: in a kernel with pseudo-device crypto and options
>>FAST_IPSEC, after the system has been running for a short while, all
>>crypto requests fail.
>
>How many device contexts are you allocating?  If (dim) memory serves,
>the driver knows only about the lowest-common-denominator.  I beleive
>the Soekris cards have external SRAM which could, in principle, be
>used for additional contexts; but the driver doesn't support that.

specifically, that'd be the "return (ENOMEM);" in hifn_newsession(),
around line 1991 in netbsd-3 source.  Can you instrument that if()
branch (with printf()s or whatever) and let me know what you see?

If it's not obvious, each IPsec SA will consume a context, in addition
to each contexts allocated via userspace ioctl()s to /dev/crypto.

... did I ever commit that draft mannage I had kicking around for review?


 
>I know that at one point I exhausted the hardware-supported contexts,
>when talking to hundedrs of IPsec peers. That was using my own private
>mutant kernel (before I committed my port of Fast-IPSec), so I guess
>it's possilbe that fallback to software crypto never worked, or
>(less likely) got broken when other people reworked the OCF APIs.
>
>
>>This causes ssh to not work (since openssl uses /dev/crypto if present)
>>and it causes IPsec to not work, since encryption of every packet fails.
>>
>>So, it seems like the RNG now works, but nothing else does.  Has anyone
>>else had better luck with this driver?  I'm using two different 7955
>>cards.