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
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
b
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
<>
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 wi
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 cipher
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
+++ b/crypto/incl
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 wrote:
>
>
> On 18/07/13 21:25, Michael Jerris wrote:
>> If that fixed it.. then
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 wor
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 wrote:
> You're using the legacy crypto implementati
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 differen
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
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 PM
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
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 e
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 fee
15 matches
Mail list logo
