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.
RSL CHAN ACT contains a MS_POWER IE which is intended to be used as the
initial power level for the MS, before the UL power control loop is
starting.
In our case, if ul_power_target != 0, then the DSP takes care of power
control. If ul_power_target == 0, then we instruct the phone to
constantly use the value specified by the BSC in the MS_POWER IE.
FIXME: Actually implement a proper power control algoritihm inside
osmo-bts so we don't have to rely on the DSP implementation.
In case opening a calibration file is failing an error will will be
logged, the caller and implementation were inconsistent about the API
version that is supported for the calibration data, attempt to make
the cut-off at 2.4.0.
Issue the RfDeactivate.REQ before sending the MphClose.REQ. Ideally
we would issue MphClose.REQ after the RfDeactivate.CNF but this is
not possible right now.
The current approach makes the following warning of the DSP go away
on shutdown. This was tested with my E71 and an active silent-call
using a SDCCH.
DSP Warning:
[ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle
* Simplify the callback signature. The trx is now the first argument.
* Embed the calibration data into the femtol1_hdl.
Tests:
* All commits are compile tested
* All commits bring up the radio (without using calibration data)
* Calibration data loading has been tested with the merge
* All commits allow a IMSI Attach and a MO Call (to an invalid unknown
number). All channels are freed after this. It has been tested with
the E71.
The TxPower handled used to call the requestion function without
a callback. In that case the msgb is leaked. The code still allows
the callback to be NULL so we will just delete the message in that
case.
All users (but the gsm_compl) of the l1if_req_compl use it with
is_system_primitive=1. We can now remove this parameter from the
method. Introduce _l1if_req_compl that will insert the item into
the queue for us.
l1if_gsm_req_compl everyone is passing the trx as data pointer right
now, remove it from the request procedure right now as it can be
deducted from the femtol1_hdl.
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.
If the CRCX does not indicate the remote IP address, then we still were
binding to 0.0.0.0 and used that address successively in the CRCX_ACK.
As a workaround, we now use the source IP address of the RTP socket,
assuming that the outbound routes to BSC and the MGW are identical.
This is of course not always true, but I don't think there are any
better alternatives...
Nicolas J. Bouliane
Alexander Huemer
Harald Welte