6 Jan
2019
6 Jan
'19
4:30 p.m.
Hello Gentlemen, ( and Ladies also of course )
Here is again a small Monologue from me, with an attempt to fix a bug....
My osmo-trx-lms is not stable, and I have reported it's strange behaviour.
Some things made me think of memory corruption, and when I found that
one thread
was logging a single letter "L" suspicion increased....
I have rebuilt the debian package from source, and tried to have a look
at the log message print,
but failed to place a breakpoint in LMSDevice.cpp:102 with meaningful
result, typically gdb
could not retrieve general registers....again, memory corruption??
However, after numerous tries I managed to "continue" the correct number
of times to hit exactly
the right instance of the breakpoint, without trx-lms giving up due to
timeouts,
and here is a bt when this happens:
(gdb) bt
#0 lms_log_callback (lvl=<optimized out>, msg=0xb415353c "L") at
LMSDevice.cpp:102
#1 0xb6d0c6c8 in lime::log(lime::LogLevel, char const*, std::__va_list)
() from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1
#2 0xb6d26b22 in ?? () from
/usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1
#3 0xb6d299f6 in ?? () from
/usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1
#4 0xb6c75a6a in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#5 0xb6fab5e8 in start_thread () from
/lib/arm-linux-gnueabihf/libpthread.so.0
#6 0xb6aee4fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Last line: corrupt stack ??
Since I have had very little reaction, I deduce that most of you
developers do NOT use my particular make of CPU,
so this might be related to the Armbian ( Debian 9 ) I am running on
this particular hardware. I am using the armhf
variety of the source.
Next step for me is rebuilding LimeSuite from source to get debugging
info, so that backtraces etc. become more meaningful.
The thinking here is that the subtle error in logging has a more general
cause, and that memory corruption surely prevents
the program to operate stable and as intended....
Best Regards,
Gullik
On 2019-01-05 21:54, Gullik Webjorn wrote:
Well, we just have to find out what is happening. I
have currently
built the trx-lms from source, so
once I can figure out how to build with debug....without breaking
everything....
In the mean time:
<0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002
<0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not
match statically set feature: 0 != 1. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does
not match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not
match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via
OML does not match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via
OML does not match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via
OML does not match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via
OML does not match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via
OML does not match statically set feature: 1 != 0. Please fix.
<0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is
unreported
Yes, it would be nice to fix, I imagine this is a configuration
mismatch, where should these be set, and using what keywords?
This also indicates a problem, but I am to much a beginner to realize
its importance.....
<0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on
ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY
not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0015> input/ipaccess.c:248 Sign link vanished, dead socket
Is it because BSC and BTS are out of sync over their A-if ? As a
consequence of trx restart ??
Regards,
Gullik
On 2019-01-05 12:02, Gullik Webjorn wrote:
> I have found an interesting log entry, I cannot see where it is
> called...
>
> Sat Jan 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386
> [tid=3070102608] chan 0: Setting TX gain to 73 dB
> Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102
> [tid=3021294672] L
> Sat Jan 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039
> [tid=3012840528] ClockInterface: sending IND CLOCK 920402
>
> the message of a single L seems a little cryptic, and I have not
> found it's origin......
>
> Gullik
>