This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Gullik Webjorn gullik.webjorn at corevalue.seA small update from Sweden,
I have built LimeSuite and osmo-trx-lms from source, this time on a
Intel Atom, i386 distribution.
I have redirected the bts - trx ip addresses, and yes, I could briefly
see the beacon, and i managed
to get two phones on the network, though not stable.
However, I can see the exact behaviour of the osmo-trx-lms as on the
armhf kit, i.e. the logging of
a single L like this...
Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L
I have not verified that the reason is exactly the same yet, since I
don't have debug environment
on the 386 yet, but the symptom is exactly the same, with strange length
packets and a lot of
packet flushing, all probably related to recovering synch.
This reduces the previously assumed probability that the problem lies in
hardware or hardware related
software (armbian Linux) , but actually is a memory problem within
osmo-trx (lms)
What is relatively easy is to move the B100 to the "new" platform, and
try to isolate the problem
with regards to uhd device vs. lms device, so I will do that test and
report back.
Regards,
Gullik
On 2019-01-06 16:30, Gullik Webjorn wrote:
> 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
>>>