Hi all,
Could anyone advise me which solution should I look for feeding the
LimeSDR mini with external clock GPSDO locked?
Btw, which you think it's a better option for a home brew BTS: the
LimeSDR mini with external clock plus an intel mini-pc, or the LimeNet mini?
Cheers,
Rafael Diniz
Looking at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/…
looks quite horrible since build 357.
However, with my own manual tests, all of those pass.
It looks like most of those failures are sporadic, and I cannot reproduce them.
I am not sure how to find out what is going there, I can just say that osmo-bsc
looks quite stable AFAICT and that it seems to be non-determinism / timing in
the ttcn3 and/or system load causing the failures.
~N
I think here is a bug:
char *osmo_quote_str_c(const void *ctx, const char *str, int in_len)
{
char *buf = talloc_size(ctx, OSMO_MAX(in_len+2, 32));
if (!buf)
return NULL;
return osmo_quote_str_buf2(buf, 32, str, in_len);
}
We may allocate more than 32 bytes (see OSMO_MAX()) but still allow to write
only 32 bytes?
Looks like the allocated len should be stored in a local variable to pass to
osmo_quote_str_buf2().
And if I'm right, what is the 32 for? At least 32??
~N
Dear all,
as you can see at
https://jenkins.osmocom.org/jenkins/job/ttcn3-bsc-test-sccplite/test_result…
there has been a large increase in test failures of the SCCPlite related tests in
osmo-bsc over the last two builds/tests.
Does anyone know what kind of changes they made which could have impacted the
relted behavior?
We don't see any such failures on AoIP, leading me to suspect that some changes
were tested only for AoIP but not for SCCPlite?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
