On Wed, Nov 14, 2018 at 07:06:22PM +0100, Ruben Undheim wrote:
segfault in gcc really!? I have not seen it, but I
have only built it
in Debian 10.
yes, in osmo-iuh.
we are left with the failures for osmo-msc on mips64el
and mipsel (the
low-endian variants of mips). So the test "msc_vlr_test_gsm_ciph" is failing.
Does this tell you anything?
Interesting, the only difference is:
-- ERROR sending ciphering mode command: rc=-95
+- ERROR sending ciphering mode command: rc=-122
i.e. a mismatching rc gets returned. It's not an error with any practical
effect.
Aha, could it simply be that the errno are defined differently on this
platform? It should be -95 == -ENOTSUP, while we get -122.
Weirdly enough, I don't see this line printed at all in my current
msc_vlr_test_gsm_ciph output. Ah, I know, because A5/3 was fixed, hence we see
no error anymore, since 3117b701c8d4645215896c459d6c608358a0a51b
There has been no release after that yet.
If you want to stay with that old revision, try branch neels/mipsel of
osmo-msc, which I've just pushed, with this patch:
http://git.osmocom.org/osmo-msc/commit/?h=neels/mipsel&id=d655d10e98c39…
Or otherwise wait for Pau's release and rather use those latest revisions.
As long as we know what the fix is, we can backport
the fix wherever we want.
sure, I forgot the deb packaged patches.
Maybe the trick is to just start going over all
structs in libosmocore
I thought about scripting it, because editing manually takes forever and is
error prone.
Interesting. I did not know about this way of viewing
the patches,
although I am behind most of the patches. Please just pull back
whatever you find useful.
Ideally, the patch author goes on to submit it on
gerrit.osmocom.org :)
~N