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.seCpuinfo: root at orangepizero:~# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 120.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 there are 4 of these.....so multithreading makes sense.....load 85% / 400% htop looks nice.... On 2019-01-11 20:58, Vadim Yanitskiy wrote: > Hi, > >> Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 >> osmo-trx-uhd_0.4.0.124 unstable after 5-120 minutes. > Have you tried to compile OsmoTRX with NEON SMID? > See both --with-neon and --with-neon-vfpv4 configure options. > Before doing that, make sure that your CPU does support them. > This can be checked using 'cat /proc/cpuinfo'. > > Also, could you please clarify, what do you mean by 'unstable'? After 5 to 120 minutes (random) the trx goes into this loop behaviour: Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69514 (underrun 0:2524734 vs 4:2524732) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.01 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69515 (underrun 7:2524745 vs 0:2524744) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.09 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.09 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.12 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.12 sec. Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69516 (underrun 4:2524757 vs 7:2524755) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.15 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.15 sec. ^Csignal 2 received shutting down ---THIS is myself stopping the transceiver. Fri Jan 11 22:00:15 2019 DMAIN <0000> osmo-trx.cpp:435 [tid=3070163440] Shutting down transceiver... Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:307 [tid=3070163440] Stopping the transceiver Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:320 [tid=3070163440] Stopping the device Fri Jan 11 22:00:16 2019 DMAIN <0000> Transceiver.cpp:333 [tid=3070163440] Transceiver stopped Restarting it goes back to proper operation, for x minutes, then it hits this situation. I have seen it recover back to normal once or twice, but often it loops forever as above. Since stopping / starting it corrects the problem, it seems the internal fail-safe mechanizm does not work properly. Some times it exits, i.e. stops by itself. I will get a fingerprint of that... Note I am running the "same build" trx on both systems however I could swap the SDR's to find out if the problem stays with the platform or the sdr device and its particular driver code. > >> Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 >> (built from latest source ) relatively stable. > Most likely, because the CPU does support SSE instructions. > Please note that they aren't supported on ARM. Yes, this is clear to me, and I will verify compile switches for the Arm cpu. >> Incoming and outgoing calls OK. PSTN access OK. Sometimes fails >> with "communication error" as displayed on Nokia, > Please attach the logs and PCAP traces. I will try to catch relevant info, but it requires "babysitting", to catch, however I can run gdb of course... > > With best regards, > Vadim Yanitskiy. Thanks for your comments, Regards, Gullik