This also uncovers very interesting design decisions like the copying of
mutexes and condition vars depending on recursive locks that were
previously hidden by shady c function calls..
We have perfectly good c++11 versions for all of that.
While we're at it, also use the initialization list for the other (still
copy constructable) vectors, which cleans up the radio interfaces.
Change-Id: Idc9e3b1144c5b93f5dad2f8e0e30f1058477aa52
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I8ba71ab9ccde4ba25151ecbeb2a323f706b57d43
This is only useful if the rf path delays the signal by at least one
frame, and therefore a fairly experimental command that might be removed
or reworked in the future and should not be relied upon.
Change-Id: I29964acffad5bad4f5bcad7f631e435a72979c46
The type used to represent a thread ID is implementation
specific, and may be an opaqe structure, making it unsuitable to be
printed by standard means. Let's use osmo_gettid() instead.
Change-Id: Iaa4d0eaf52b901fff06cc67f8dd8b61ac6084911
Related: OS#5032
new libosmocore osmo-trx already depends on does support printing thread
ID as prefix to all messages (confgiurable through VTY), so there's no
use in printing it in osmo-trx unconditionally.
Moreover, The type used to represent a thread ID is implementation
specific, and may be an opaqe structure, making it unsuitable to be
printed by standard means, so in any case we should be better printing
system's TID instead.
Related: OS#5032
Change-Id: Ie98a21246230c946afc47f4f5b9c6618eefde494
The API was moved to libosmocore, let's use it instead of defining our
own here with all the complexity in build system involved.
Depends: libosmocore.git Change-Id Id7534beeb22fcd50813dab76dd68818e2ff87ec2
Related: OS#5027
Change-Id: I19e32fbc47bd88a668e0c912e89b001b0f8831dd
A wrapper function with better support already exists in debug.c and
announced in debug.h. Let's use that one instead.
Related: OS#5027
Change-Id: I2ccf94f95a531d5873da2a4681cf89cbc5b31422
vty_cmd_string_from_valstr() expands the given 'struct value_string'
sequentionally, so the order of entries in both filler_{types,docs}
shall match (regardless of the value assigned).
Change-Id: Ieb3bbc4fb30f303c47555ca77d03a9e965bc72b5
Do not use 'extended' because it's not the same 11-bit Access Burst,
as it was assumed before. Add missing docs for 'enable'/'disable'.
Change-Id: I80b5a584e554eb7cc2416017b10fee032202b372
Dummy bursts have nothing to do with A5/x encryption, and I see
no reason why (and how?!?) would using that filler type break
encryption in osmo-bts-trx. I asked the author of this code
back in August 2020 [1], and so far didn't get any response.
[1] https://lists.osmocom.org/pipermail/openbsc/2020-August/013208.html
Change-Id: Iae513d7acbb8ef682e1744ac8726cbd6ece8bd87
Prior to this patch, osmo-trx relied totally on proper VTY configuration
being set in "rssi-offset" together with the RxGain set through TRXC in
order to provide correct Uplink RSSI measurements to bts-trx.
With this patch, RSSI is now by default calculated (in LMS and UHD
backends) based on the currently set RxGain, by providing empirically
discovered values. Still, for backward compatibility, the old
"rssi-offset" command will overwrite completely the per-default
calculated rssi offset.
A new optional parameter "relative" is added at the end of the
"rssi-offset" VTY command to flag the value as relative to the newly
per-default calculated value. This way specific setups (like adding a
LNA / RF fronted) can still be expressed while still keeping the
automatic per-default offset.
Related: OS#4468
Change-Id: I8ef78fd20c22c60d61bfb18d80a4a36df4fd6c20
There is no point in checking basic stuff ten thousand times per second
since the sizes never change, so it's enough to enable the
checks/assertions for unoptimized (debug) builds.
This significantly decreases branch mispredictions.
Change-Id: Iebd9e91b3c7f37f2dc646d3017c45139977e4d15
Using the new libosmovty features allow for:
* Setting different cpu-affinity masks for each thread in the process,
both at startup through .cfg file as well as changing it at runtime.
* Unified VTY interface to change the scheduling policy of the process
inherited by all osmocom processes enabling the feature.
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: I3798603779b88ea37da03033cf7737a6e4751d6e
Since there's now a rate counter, we can drop log level for those events
which can be bursty and hence print lots of output in short periods of
time, which may affect performance. This way setting them to INFO it's
enough to avoid getting them in stderr unless explicitly configured by
the user (for instance to debug stuff), while still allowing a good
enough level to be enabled for other targets such as gsmtap.
Related: OS#4679
Change-Id: I000f7112e35ac68d3d922444f78468b1ea74cbba
This way i most usual rate_ctr related internal logging is disabled by default
(notice), and it can b eeasily enabled by switching the category to info
or debug.
Change-Id: Id6c36432da7e7ce673c585bcae6772a695028ec5
This ones together with rate counters already available in lower layers
allows to understand better the source of the problem with stalled tx
bursts.
Change-Id: Ia34f7e7d780ad1e12f24638a07f05fe91f2afea5
This allows checking if there's timing issues on the downlink side
between osmo-bts-trx and osmo-trx. This counter is useful to find
information about osmo-bts-trx 'fn-advance' setting, since this counter
basically counts if burstrs from it arrived too late to osmo-trx.
Change-Id: Id6df00da81f6d6884f4dddc5a2c4b354dca3af97
RadioInterface ones will be added in next commit, so let's differentiate
the structs required for each one.
Change-Id: Ib0e142a1dd4bedefdb4c5f15c34132da872c0975
For instance, use in VTY:
"ctr-error-threshold tx_underruns 5 per-second"
If the condition becomes true (eg 5 underruns happened in one sec), the
statement inside OSMO_MAX would become -1, but it was being handled as
an unsigned when doing the OSMO_MAX internal comparison. As a result,
OSMO_MAX((unsigned)-1, 1) was returning -1 (unsigned) stored in
threshold_timer_sched_secs which then became and int -1, which was
handled by osmo_timer_schedule as a 0, hence having an immediate
trigerring all the time.
While at it, make threshold_timer_sched_secs unsigned since it doesn't
make sense to have it as signed anyway.
Change-Id: I6ea3d64dff189a5bc924e72d846e02d50536a8ea
The log category DDEV ueses LOGL_INFO as debug level. This is too
verbose, lets use LOGL_NOTICE instead
Change-Id: I56d45ce5c3f55574491ffa6e4d902d6ba7499d46
Related: OS#2577
Under armv7l arch, size_t is actually an unsigned int and not a long
unsigned int, and compiler errors:
CommonLibs/debug.h:28:24: error: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 8 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
Change-Id: I7f6ded5a984570b5267916d6c84eb7d019db73a8
Using %lu for pthread_t was wrong on armv7l arch. Even worse, according
to pthread_self() man page, pthread_t cannot be assumed to be of a simple
type and hence printable:
"""
POSIX.1 allows an implementation wide freedom in choosing the type used
to represent a thread ID; for example, representation using either an
arithmetic type or a structure is permitted.
"""
Let's use gettid() instead. According to glibc documentation:
"""
The pid_t data type is a signed integer type which is capable of
representing a process ID. In the GNU C Library, this is an int.
"""
It may not be the same on other libc's though, so let's better cast to a
long int just in case.
Accordign to gettid() man, the libc function was only added recently
during glibc 2.30, however the system call has been around for quite
some time (linux 2.4.11). Let's accomodate use udner non-glibc or older
versions of it by having a direct syscall fallback.
Change-Id: I40265fd4c62e550014ba3ff3335ca053c5bc01f2
Add an enum containing each supported device type (LimeSDR-USB,
LimeSDR-Mini and LimeNet-Micro) plus "unknown", to leave some room for
yet-to-come devices to run with some generic parameters without
rebuilding osmo-trx.
Each device type is assigned a dev_desc structure, and all of them are
put in HashMap, similar to what's already done in UHDDevice.cpp.
Device type is infered from string provided by LMS_GetDeviceInfo(), as
it was already done before in several places. From now on, we only need
to parse the string once since we store the device type after first
during open time.
Later on, more fields will be moved to device-type specific structure,
such as Tx timing offset, clock rate, etc.
Change-Id: I7658615787c5bc41c365bab9c11733b701ac2ae5
Make sure old configs using "logging level lms <level>" are still accepted.
Initialization order of VTY componenets need to be resorted since newly
introduced command requires logging VTY node to be already setup
beforehand.
Change-Id: Ia195a74a62a8a3dd6267fb1359acaa5628208d8e
Take the chance to clean up logging lines in this file:
* Use LOGCHAN in more places where chan is useful
* Replace inherited (old osmo-trx) categories such as WARNING with
osmocom ones.
Change-Id: Ic8c218f050f35d48046ccf1561fb0bfc505d4f63
In the command line options time, filler table/filer burts settings
were a bit difficult to undertand because the number of one-letter
settings was limited. Now, with VTY configuration, there is no reason
to keep it so difficult.
Also, after the previous commit it was no longer posible to enable
random 8-PSK filler bursts. With this patch you can configure all
supported filler bursts in a simple and logical way.
Change-Id: I752eb2c1162d084e8769181f2fcd6c0877663448
The EGPRS switch in the VTY config enables 8-PSK burst detection on
uplink. Enabling it shouldn't turn on filler bursts.
Change-Id: I2786c768e038b769a80c8b78fe58cfa09eb322a9
Since libosmocore Id7711893b34263baacac6caf4d489467053131bb, a new API
log_enable_multithread() is available which takes care of protecting
logging infrastructure from us (and actually does it correctly since we
cannot protect internal libosmocore structures from osmo-trx).
Let's drop all mutex related code from osmo-trx logging infra and simply
rely on libosmocore's.
Related: OS#4088
Change-Id: I519d0f30bce871005ca26b90177ea4aa4839360a