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
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I3a3ff56cb2d740a33731ecfdf76aa32606872883
Fixes: OS#4865
Otherwise these logging lines end up in the automatically generated
XML VTY reference (stdout), so this breaks further XML processing.
Change-Id: I8e0fd728d406e2452c9c0ddad5bce5f6b17fab42
Related: SYS#4937, SYS#4910
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
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: I34dd36183e013ab005f39b235c4ab561590befb7
Related: SYS#4937, OS#1601
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
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_READ symbol when
copy-pasting somewhere else.
Change-Id: I868baf575b77c448b3115701e70d439de89b0fb3
There is no need to have n threads handle n ctrl sockets, since they all
will immediately respond to commands, so handle them from the existing
main osmo select loop.
Care must be taken to ensure that calls from within the command handler
do not block, or at least don't block too long, which currently is the
case.
Change-Id: I642a34451e1825eafecf71a902df916ccee7944c
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
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
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
Otherwise, it could happen that underrun events are lost:
TxLower (isUnderrun): RxLower (pullBuffer):
read(underrun)
read(underrun)
write(underrun, |val) [maybe underrun becomes TRUE]
write(underrun, false)
Similary, it could happen the other direction if atomic was only applied
to isUnderrun:
TxLower (isUnderrun): RxLower (pullBuffer):
read(underrun) -> true
read(underrun)-> true
write(underrun, false)
write(underrun, true|val) where val=false
So in here isUnderrun would return true twice while it should only
return one.
Change-Id: I684e0a5d2a9583a161d5a6593559b3a9e7cd57e3
Since osmo-trx it's a big multithreaded process and shutdown sequence
can be complex, better use stderr to log signal received events to make
sure log is outputted straigh away and not buffered. In general stdout
is usually line-buffered, but buffering strategy can be more
conservative if output is for instance redirected to a file.
Change-Id: I70ba86919d1f7df41ef3db4916317d27697a025c
The callback actually belongs there, since it's the code/thread in main the one
actually in charge of stopping everything. It simplifies current code,
and more important, allows for new clients of this signal to use it.
This callback will also be used in forthcoming commits by code
controlling rate_ctr thresholds to stop the process if the VTY
configured threshold is used.
Change-Id: Id4159e64225c6606fef34a74b24f37c3a071aceb
Introduce a unified implementation-agnostic interface for radioDevice to
signal SDR error counters to upper layers and manage them.
This patch only implements counters for osmo-trx-lms (other devices will
show all counters unchanged during time).
Sample use through VTY:
"""
OsmoTRX> show rate-counters
osmo-trx statistics 0:
device:rx_underruns: 0 (0/s 0/m 0/h 0/d) Number of Rx underruns
device:rx_overruns: 0 (0/s 0/m 0/h 0/d) Number of Rx overruns
device:tx_underruns: 0 (0/s 0/m 0/h 0/d) Number of Tx underruns
device:rx_drop_events: 4 (0/s 2/m 3/h 0/d) Number of times Rx samples were dropped by HW
device:rx_drop_samples: 513 (0/s 196/m 425/h 0/d) Number of Rx samples dropped by HW
"""
Change-Id: I78b158141697e5714d04db8b9ccc96f31f34f439
We haven't even released any tagged version of libosmocore yet which
includes support for the renamed OSMO_FD_READ constant. Let's avoid
any breakage and use the new constants only with considerable delay,
at the very least only when released libosmocore versions provide it.
Change-Id: Idb57077b2a4b2a71dd5d75a24ded8bb5887da188
Maximum number of carriers is fixed to 3 channels on a single
physical RF channel in multi-ARFCN mode. For some reason, it
was limited to 5.
Let's fix this, and also follow this limitation in the
following VTY command handlers:
- cfg_multi_arfcn_cmd,
- cfg_chan_cmd.
Change-Id: I66a1462f368458afd313ee6f0bc0abc496dde817
This should avoid prolematic scenarios where different signal handlers
are running on different thread in parallel. Furthermore, we make sure
those signals are always run by main loop thread.
Change-Id: I9b9d9793be9af11dbe433e0ce09b7ac57a3bdfb5
Recently a blocked osmo-trx process was found after ending SIGTERM to
it.
Apparently one thread was handling SIGTERM and calling fprintf()
(grabbing libc lock) while another thread was handling another signal
and also grabbing similar lock. Both thread looked deadlocked there.
Probably this change doesn't fix the block on its own, but at least
simplifies scenarios inside signal ctx which can go wrong.
Change-Id: If91621913b8b03d8a0f4c863be0b0d479f97e8a1
Since I838c21db29c54f1924dd478c2b34b46b70aab2cd we have both TS1
and TS2 synch. sequences, in addition to "default" TS0. Let's
finally introduce the VTY configuration parameter, that can
be used to toggle optional detection of both TS1 and TS2.
Note: we keep this optional because of potentially bad impact on
performance. There's no point in paying the performance penalty
unless upper levels (BTS, PCU) actually make use of it.
Change-Id: I1aee998d83b06692d76a83f79748f9129a2547e8
Related: OS#3054
Make the "opt" argument const. This function will also be used by
LMSDevice.cpp in a follow-up commit.
Related: OS#3654
Change-Id: If3f0f682ca453c2b0a06175ec9626567932cfce6
Makes osmo-trx-* more consistent with other Osmocom programs, and
allows an unified test for not having "UNKNOWN" in --version.
Related: OS#3578
Change-Id: I90cf01d972aa10b48c59b67a1e7f82a4255ef526
Transceiver::stop() can only be called from either CTRL iface thread or
from main thread (running osmocom loop). That's because stop attempts to
cancel and then join all the other threads, which would then lock if
attempting to stop from some of them.
As a result, the best option is to indicate to the user of the
transceiver option (osmo-trx.cpp) to stop it in a correct fashion by
destroying the object from the main thread.
Change-Id: Iac1d2dbe2328e735db2d4b933cb67b1af1babca1
Parameter -l to set the terminal logging levle was removed in
3da1f8352e, but afterwards it was decided
to keep the cmd line options for a bit more to easy migration to VTY
cfg.
The command line no longer accepts keywords ("DEBUG", "INFO", etc.) but
log level numbers, due to libosmocore APIs log_parse_level and
log_level_str being marked as deprecated and for internal use only.
Keep in mind the log level is overridden by VTY cfg if any line sets log
levels for log stderr in there.
Explicit cast to unsigned int for loglvel is issued to avoid iostream
printing it as a char.
Change-Id: I91c35ecded177b7976045d9b693855adb9e18f8a
Existing cmd line options are kept for a while to give people some time
to move to use VTY cfg. All new cfg options should be set only through
VTY. VTY options take preference (override) over cmd line options.
Deprecated options are removed from help message to dissuade users from
keep using them.
Steps to drop cmd line options in the future:
- Drop comma_delimited_to_vector, print_deprecated
- Drop all options in handle_options marked with print_deprecated.
- Set "-c" param to do the same as "-C", to keep compatibility with old
param and still use same naming as all other osmocom projects.
- Remove the hack in main() to set 1 channel implicitly by default.
Change-Id: Ib8de1a5da4b3c0b6a49e00033f616e1d66656adf
At this stage, osmo-trx still uses the cmdline parameters top run the
device, but it is already able to parse all the same parameters from a
cfg file through the VTY and filling a trx_ctx structure which will be
later used to drive the device. Device config can be printed in the VTY
with "show trx".
Change-Id: Ie084c1b30b63f91c6e7640832ec1797d9e813832
We still need an intermediate class Logger due to osmo-trx being
multi-threaded and requiring to have a lock to use libosmocore, which is
not thread safe.
Change-Id: I30baac89f53e927f8699d0586b43cccf88ecd493
Up to this point, the logging system, vty and ctrl are initialized and
can be used fine, though they don't have a lot of use yet.
Depends on libosmocore Change-Id Ib79cdb62d45d8c78445c7b064e58eb7e9faeccf9
Related: OS#2184
Change-Id: I08982c37b4f873966304b3cfb38a10ee86eb3dad
This feature is currently not being used, so let's drop it to make it
easier to integrate into libosmocore logging system in the future.
Change-Id: I8282745ef0282d41599eaf94fe460a1d29b18e2a
Some devices have different Rx or Tx ports with different RF characteristics.
For instance LimeSDR has H (High), L (Low) and W (Wide) band Rx ports,
each of one being more suitable to a specific range of frequencies.
In case one wants to support several GSM bands, the best option is to
use the WideBand port and connect the antenna physically to that port in
the board. Then the firmware must be instructed ro read from that port.
Support for Rx/Tx port configuration is already in there for all the
layers (Limesuite, SoapySDR, SoapyUHD, UHD), but we are missing the
required bits in osmo-trx to make use of the available UHD API. This
commit addresses it.
Before this patch, the Rx/Tx paths configured could be changed by means
of the LimeSuiteGUI app, but after running osmo-trx, the values were
changed to the default ones.
One can now start using osmo-trx with 1 channel and specific Rx/Tx ports
by using for instance: osmo-trx -c 1 -y BAND1 -z LNAW
Default behaviour if no specific path or an empry path is passed ("") is
to do the same as preiously, ie. nothing by not calling the
set{T,R}xAntenna APIs.
One can also configure only specific channels, for instance to configure
only the first Tx channel and the second Rx channel:
osmo-trx -c 2 -y BAND1, -z ,LNAW
Change-Id: I1735e6ab05a05b0312d6d679b16ebd4a2260fa23
Oliver Smith
Vadim Yanitskiy
Pau Espin
Vadim Yanitskiy
Philipp Maier
Eric Wild
Harald Welte