On 20/07/13 02:06, John Foley wrote:
Hi Daniel,
Thanks for the guest access to your sparc 64 system. The problem with
stat_driver is intermittent. The attached patch appears to resolve the
problem, can you confirm using your view? It looks like the nonce value
is never initialized to
On 19/07/13 01:39, John Foley wrote:
With respect to the master branch, you should be able to avoid the patch
and compile with -DFORCE_64BIT_ALIGN. The patch provides no value in
the master branch.
The version I am testing is the Debian git master, it is the same as
master on github but with
Yes, a guest account on your sparc system would be helpful. Your
observations are curious. I'm interested learning what's happening here.
On 07/19/2013 05:16 AM, Daniel Pocock wrote:
and patch ID 2002
attachment: foleyj.vcf
Hi Daniel,
Thanks for the guest access to your sparc 64 system. The problem with
stat_driver is intermittent. The attached patch appears to resolve the
problem, can you confirm using your view? It looks like the nonce value
is never initialized to zero. This intermittently results in garbage
On 18/07/13 17:26, John Foley wrote:
We've seen BUS errors on some platforms. I'm not confident the
following patch was ever pushed back to libsrtp. There's a chance this
may resolve the problem on sparc. Unfortunately I don't have a sparc
system to try this myself.
Thanks for this
Further observation: the feature-openssl branch from git does not have
the bus error, test cases run successfully on SPARC
On 18/07/13 19:34, Daniel Pocock wrote:
On 18/07/13 17:26, John Foley wrote:
We've seen BUS errors on some platforms. I'm not confident the
following patch was ever
I should clarify this better. The legacy crypto is still in the
branch. It's pulled out depending on how you've configured the
library. Can you provide the ./configure options you used to build the
library?
On 07/18/2013 02:12 PM, John Foley wrote:
Which test case was failing? It's possible
Which test case was failing? It's possible the test case is no longer
included in the feature-openssl branch. I pulled out all the legacy
crypto and math from libsrtp in that branch. Have you confirmed the
failing test case is still run under the feature-openssl branch?
On 07/18/2013 01:42
On 18/07/13 20:17, John Foley wrote:
I should clarify this better. The legacy crypto is still in the
branch. It's pulled out depending on how you've configured the
library. Can you provide the ./configure options you used to build
the library?
I just ran
./configure make runtest
This
You're using the legacy crypto implementation with that configuration.
OpenSSL is not in the picture.
Looking at the diffs between master and feature-openssl, there's not
much jumping out at me that would have resolved the problem. There are
some changes to the Makefile. The only other
If that fixed it.. then the issue is the missing def for FORCE_64BIT_ALIGN.
Also of note, that pad shouldn't be there anymore after algorithm was added I
suspect, as it always serves the same purpose.
On Jul 18, 2013, at 3:10 PM, John Foley fol...@cisco.com wrote:
You're using the legacy
On 18/07/13 21:25, Michael Jerris wrote:
If that fixed it.. then the issue is the missing def for FORCE_64BIT_ALIGN.
Also of note, that pad shouldn't be there anymore after algorithm was added I
suspect, as it always serves the same purpose.
Ok, I've just manually checked that it works
If you don't remove that block from the code after that other var was added… it
will cause this error to come back on that branch now that you've forced the
64bit align
On Jul 18, 2013, at 5:42 PM, Daniel Pocock dan...@pocock.com.au wrote:
On 18/07/13 21:25, Michael Jerris wrote:
If that
On 18/07/13 23:46, Michael Jerris wrote:
If you don't remove that block from the code after that other var was added…
it will cause this error to come back on that branch now that you've forced
the 64bit align
Ok, patching it like this:
--- a/crypto/include/cipher.h
+++
With respect to the master branch, you should be able to avoid the patch
and compile with -DFORCE_64BIT_ALIGN. The patch provides no value in
the master branch.
I'll need to address this problem in the openssl-feature branch. There
should be no need to force the 64-bit alignment when the
15 matches
Mail list logo
