sysmobts_vty.c: In function 'activate_lchan':
sysmobts_vty.c:373:3: warning: implicit declaration of function 'lchan_activate' [-Wimplicit-function-declaration]
sysmobts_vty.c:375:3: warning: implicit declaration of function 'lchan_deactivate' [-Wimplicit-function-declaration]
eeprom.c: In function 'eeprom_ReadEthAddr':
eeprom.c:305:5: warning: pointer targets in passing argument 3 of 'eeprom_read' differ in signedness [-Wpointer-sign]
eeprom.c:260:12: note: expected 'char *' but argument is of type 'uint8_t *'
Instead of calling oml_mo_state_chg() [which transmits OML STATE CHG]
during bts_init(), we use a new oml_mo_state_init() function which
simply sets the state.
This should fix:
calib_file.c: In function 'calib_eeprom_read':
calib_file.c:262: error: 'SuperFemto_SetRxCalibTblReq_t' undeclared (first use in this function)
calib_file.c:262: error: (Each undeclared identifier is reported only once
calib_file.c:262: error: for each function it appears in.)
This should fix:
calib_file.c: In function 'calib_fixup_rx':
calib_file.c:148: error: 'SuperFemto_SetRxCalibTblReq_t' undeclared (first use in this function)
calib_file.c:148: error: (Each undeclared identifier is reported only once
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3f. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.
These should have been ExecStopPost from the beginning. Currently
they reset the firmware while the software is starting. Reload
the DSP and FPGA firmware.
In case there is no transmitter the S counter might never be decreased.
This means that no radio link timeout will not be sent and the lchan will
remain open forever. There are several ways to resolve this.
The first would be to use the MphTimeInd and after each multiframe check
if there has been a SACCH message for the open lchan's. This could be
similar to the trx_meas_check_compute.
I decided to change fBFILevel to always receive SACCH frames and move
the code down to the PDTCH/PACCH handling and update the comment.
In most cases there are multiple messages ready to be read from
the queue and it is more efficient to read them in one go instead
of going through the select again.
Attempt to write multiple primitives at the same time instead of
the select/write, select/write that is currently done. The queue
size is big enough to hold several entries at the same time and it
is unlikely we get the -EAGAIN from the kernel driver.
The writev code works by assuming that each element in the queue
has the same size. This is not verified by the code and if this
assumption breaks at some point the code will drop primitives or
send some twice.
Make sure the l1msg is always freed in the callback. There were
several error conditions were the msgb would not have been freed,
in the case of the calib data and the system information the message
was not freed even in normal condition.
I will modify this code to __use a msgb. This allows to re-use
the allocated msgb across read operations.
The lapdm/lapd_core code needs to keep a history of messages sent.
This history is not freed when lapdm_channel_reset is called and
the init code will just allocate a new array. This means there is
a memory leak on every released channel every time it is released.
On v2D (and later) hardware, the calibration data can be read directly
from the EEPROM and doesn't have to be read from files.
If there is no trx-calib-path set in the VTY, we will read from EEPROM.
When not specifying a config path, then saving the running config
it would end up as "(null)" and then leads to an error like this:
<0006> calib_file.c:147 Failed to open '(null)/calib_rxu_850.cfg' for calibration data.
Add a NULL check to avoid this issue when writing the config file.
the armv5 can do 32bit/16bit reads only from the aligned address
use tlv.h macro to copy data to local variable
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
When not reading quick enough from the queue we will get a bogus
response which will lead to marking the lchan as broken and to
clear the sapi queue. The sapi_queue_dispatch was checking if the
queue was empty before calling the callback but not taking into
account that it might have been flushed.
Stop processing if the queue was empty before calling the callback
or if it is empty after the callback.
Backtrace:
#0 0x4eb1f1cc in raise () from /lib/libc.so.6
#1 0x4eb22f48 in abort () from /lib/libc.so.6
#2 0x4ecc2cb8 in talloc_abort (reason=<optimized out>) at talloc.c:167
#3 0x4ecbc854 in talloc_abort_unknown_value () at talloc.c:180
#4 0x4ecc6bc8 in talloc_chunk_from_ptr (ptr=0x4ec2d494) at talloc.c:192
#5 _talloc_free (ptr=0x4ec2d494) at talloc.c:517
#6 talloc_free (ptr=0x4ec2d494) at talloc.c:990
#7 0x0000f294 in sapi_queue_exeute (lchan=0x402414a0) at oml.c:528
#8 0x0000f2d4 in sapi_queue_send (lchan=0x402414a0) at oml.c:542
#9 0x0000f3e0 in sapi_queue_dispatch (lchan=0x402414a0, status=-4) at oml.c:565
#10 0x000114d0 in lchan_deact_compl_cb (trx=0x4021e038, l1_msg=0x7e690) at oml.c:1269
#11 0x0000d70c in l1if_handle_l1prim (wq=1, fl1h=0x607c8, msg=0x7e690) at l1_if.c:938
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.
Currently msgb_free is calling talloc_free but we might introduce
a msgb pool in the future. So make sure to use the designated free
method for the msgb.
On some system (e.g. ubuntu) libosmovty must precede libosmocore
otherwise we get undefined reference errors while linking.
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
In case the channel is not active we can omit the external requests
to modify it. For the channel modification the higher level is already
acking it and for the ciphering it is probably too late to do anything.
There are three new commands. There are two markers and a deactivate
command. The markers are used to wait until all previous commands are
executed and then to decide if the SAPI needs to be released at all.
When asked to release the SACCH the marker will be queued, then on
execution of the marker the SACCH in Up-/Downlink will be released.
For the RF Channel Release we use another marker, when the marker is
executed we check all the SAPIs we want to release. It is possible that
the queue looks like this:
(SACCH_REL_MARKER is done) REL_MARKER, SACCH DEACT, SACCH DEACT
This could happen if a BSC sends SACCH Deactivate and RF Channel Release
at the same time. We deal with issue by changing the SAPI state to the
REL_REQ state and check_sapi_release will not ask for another release. So
after the execution the queue will look like this:
SACCH DEACT, FACCH DEACT, TCHF DEACT..
This code does not check that all allocated SAPIs are released. The
lchan_deactivate_sapis could be changed to go through all sapis_dl
and sapis_ul to fix that.
The normal flow should now be:
1.) lchan_deactivate
2.) Check if the queue is empty then go to 4
3.) REL_MARKER is executed and lchan_deactivate_sapis is called
4.) For all SAPIs to be released, check if they are allocated and
then schedule a CMD_DEACTIVATE. If there is an error remember
something went wrong but continue.
5.) Once all commands are executed send the channel release ack.
For the release markers we need to be careful as they might not schedule
any work. E.g. if the BSC sends two SACCH DEACTIVATE the second marker
will not generate any release requests and we should proceed with the
next command. Make sapi_queue_command return 1 in case the command has
been directly executed. So a queue like SACCH_REL_MARKER, LOGCH will
result in LOGCH, SACCH DEACT Rx, SACCH DEACT Tx but a 0 will be returned
and the sapi_queue_next will then call sapi_queue_exeute again.
NITB has been modified to trigger these corner cases more easily.
* Do not send IMM.ASSIGNMENT for some timeslots to go through the
error path
* Issue multile SACCH deactivates in the normal release mode
* Send rsl_chan_mode_modify_req before the SACCH DEACT and also when
the RLL is being released.
Put all SAPI requests into a queue and handle them one after another.
Begin with the channel activation. Once the queue is empty the channel
activate will be sent. For the BCCH activation we do not want to send
a channel activation message and this is why we set the lchan->state
to NONE.
One change is that we do not attempt to call the ciphering routines on
the BCCH anymore.
This change is necessary to fix issues with LCHANs staying open and being
marked as broken by the BSC and will help in implementing handover support
as this requires a re-configuration of the lchan on the fly.
If the shutdown timer is already running do not deactivate the RF and
do not close the trx. This is addressing another instance of the following
warning:
[ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle
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.
In case that the counter S reached 0, it will stay 0. Subsequent received
good and bad SACCH frames must not cause to trigger radio link failure
again. Once the BSC has been indicated about link failure, it will release
channel.
The counting of S has been moved to a seperate function.
This patch will ensure that the link failure is indicated only once. But
even if the link failure would be sent multiple times, the BSC should
ignore it. The BSC releases the channel and may only reuse it after confirm
from BTS. (There cannot be any link failure indications after confirm of
channel release.)
The allowed timeout value range is 4..64, as defined in TS 05.08, so if the
BSC sends an attribute with value out of range or other failure criterion,
the Set BTS Attributes message is NACKed.
Chapter 5.2 applies to MS procedure, but 5.3 (BSS procedure) defines no
exact criterion, so I decided to use the procedure equivalent to MS.
The criterion is based on a counter S, which is initialized to a preset
RADIO_LINK_TIMEOUT, which can be configured via VTY. Whenever a received
SACCH block is bad, S is counted down by one. If SACCH block is
successfully decoded, S is counted up by two, but never above initial
RADIO_LINK_TIMEOUT value. If S reaches 0, an RSL Connection Failure
Indication with cause RF Radio Link Failure is sent to BSC, which then
aborts channel.
Use link timeout value from BSC via OML attribute.
How to test:
- Set "debug" for "meas" logging.
- Start silent call to an attached mobile.
- Remove battery from mobile or shield mobile.
- Watch S count down.
Holger Hans Peter Freyther
Harald Welte
Alexander Huemer