This is the sequence of events that preceedes a failure in osmo-trx-lime. Before this event everything looks normal, and sometimes I can see the messages relating to phones selecting this bts. But, then I get many hundreds of fail messages, overfilling the terminal buffer. I managed to catch ONE event, it follows....at 17:53:26...... Fri Jan 4 17:53:22 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2012824 Fri Jan 4 17:53:23 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013041 Fri Jan 4 17:53:24 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013257 Fri Jan 4 17:53:25 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013474 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331871c got 3318b18 (3318b18) diff=3fc Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 33190e0 got 3320c64 (3320c64) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 3319aa4 got 3321628 (3321628) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331a468 got 3321fec (3321fec) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331ae2c got 33229b0 (33229b0) di after this, possibly 30 seconds later ?? the BTS restarts ?? and the trx synchronizes up, config is done, and log starts logging IND CLOCK every second... then this same event happens.....and we have a loop..... This is on an orange PI Zero, arm, so maybe not visible on your platforms..... Gullik

Yes, I just spotted that bug report #3339, and one thing that is similar to a completely other system is the USB2 vs USB3, which is the only type available on the Opi Z. Regards, Gullik

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

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 >>

Hello Gullik, It's known issue that LimeSDR is not stable as a PHY for OsmoTRX. I wouldn't expect any miracles, trying it on different hardware, until the problem is investigated and the fix is merged. AFAIK, this message comes from the LMS driver, and it means that you're sending TX samples too [L]ate. Most likely, your CPU is too slow. However, you can play with the real-time priority. I've never seen such messages with LimeSDR though. With best regards, Vadim Yanitskiy.