Harald is right and that the code is generally not ready
for inclusion. I fell victim of trying to finish it while
the code is not ready at all. It is better to re-introduce
the patches in a smaller and more tested way.
The right way would have been a branch were ready things
are split-off the main/wip commit until everything is ready.
Revert "sysmobts: Have a common prefix for the enum"
This reverts commit 44980347f3.
Revert "utils: Used the enum manuf_type_id in the parameter of add_manufacturer_id_label"
This reverts commit 7d36e5ed46.
Revert "utils: Classify the OML message using the return type"
This reverts commit afee0b7929.
Revert "sysmobts: Do not access out of bound string"
This reverts commit f5f41e8051.
Revert "sysmobts: Separate IPA and OML check into two methods"
This reverts commit 13a224063d.
Revert "screenrc: osmobts-mgr now needs a config file"
This reverts commit 0a1699ff8a.
Revert "make sure osmobts-mgr.cfg file is included in tarballs"
This reverts commit 14c60b425f.
Revert "sysmobts-mgr: Add VTY support for configuring it"
This reverts commit c5fedd24c9.
Revert "sysmobts: Add beginnings of an OML router and create Failure Messages in the sysmobts-manager"
This reverts commit c6ab90b270.
Launch the sysmobts-mgr as well. It will monitor the temperature
but it will not update the eeprom or act on any of the data. On
top of that it will respond to ipaccess-find messages making it
more easy to find the device.
The PCU is not capable of cleaning up properly. For now simply
exit the PCU in case the sysmobts has exited. This requires
osmo-pcu a30f47613abb7c22a26d534d66e478265a8c2c09 or later.
For the sysmoBTS 2050 this appears to have a different sign. We can't
test this with NWL right now so we will need to see if this is a case
of ping/pong.
These should have been ExecStopPost from the beginning. Currently
they reset the firmware while the software is starting. Reload
the DSP and FPGA firmware.
The latency to respond to a PH-READY_TO_SEND.ind may not be higher
than 18ms. Currently we are using nice to increase our priority but
for a heavily loaded cell this is not enough. Add an option to enable
realtime scheduling and use it in the screenrc.
Linux offers two realtime scheduling classes these are SCHED_FIFO
and SCHED_RR. For SCHED_FIFO the process is running as long as possible
(potentially taking all the CPU and never yielding it), for SCHED_RR
the process can still be pre-empted at the end of the timeslice.
Using SCHED_RR appears to be the more safe option as a run-a-way
sysmobts process will not be able to take all the CPU time.
For a very loaded cell we also require to use readv/writev to allow
writing multiple primitives in one syscall.
Make the script mostly unkillable due to OOM and make sure that the
process has a score of zero. Wait 10 seconds before re-launching.
The combination of ( && exec ) & appears to save one sub-process. The
script has been tested with bash and busybox's ash.
AGCH is reported as part of the PCH because we are not searching
for the BS-AG-BLKS-RES inside the SI3 and do not use MphConfigReq
to change this setting.
We only need to run this once and we know the clock error. In case it
is 0/0 we know that we didn't receive one of the two clocks. This could
be because the GPS doesn't have a fix. I accidently pushed this code into
the master branch and it is too late to rebase.
We need to read the Layer1 message queues fast enough, switch on
realtime processing for that. Move the firmware init after the
process execution to have some time for the firmware to reload
before the application sysmobts is restarted.
Migrate the LED and firmware reloading into a systemd service. This
makes the respawn and screen obsolete as it will be done with systemd
and the journal script.
This starts sysmobts-remote and dumps the documentation about the
VTY to the doc/ directory.
$ ./contrib/dump_docs.py
this writes doc/vty_reference.xml
From our header files v2.4 onwards, we include some macros that allow us
to do compile-time checks for the API header version. As older headers
don't have those macros, we have to fall back to assume it will be v2.2
It has been tested with the OCXO and the network listen mode of the
firmware. For other sources we are not required to synchronize to
the network and the tool needs to be adjusted.
Once we get RF-ACTIVATE.conf from L1, we now enable the corresponding
LED. We also switch it off on RF-DEACTIVATE.conf. We do _not_ switch
it off when osmo-bts crashes or terminates before RF-DEACTIVATE.conf.
The latter is intentional, as RF may very well still be active at that
point. The re-spawning script will re-set the DSP and therby turn off
the RF and then disable the LED.
A better solution might be to do all this in the kernel driver for the
DSP.
Holger Hans Peter Freyther
Harald Welte