with ZMQ RF, we've seen the radio returning -1 and traced
the issue down to the ringbuffer.
in fact, pthread_cond_timedwait() returned 22 (EINVAL) indicating
a wrong timeout value. The issue was likely an overflow
in the timespec parameter. This patch checks for the return
value of pthread_cond_timedwait() and also calculates the
nanosecond wrap around for the timespec
amarisoft flags an RF error and exits after not receiving samples
for the radio. Running with ZMQ in the RFCI, the UE sometimes needs more
time to start up due to slow processing and no fftw wisdom file and
then Amarisoft eNB times out. This gives the whole process a little
bit more time. Should we still find it too short we may increase
it further.
This lock was removed in 1cbf7eac because it was considered unneeded.
However, as can be seen in issue #1503, we need to protect the access
to rx_window, for example.
Issue #1503 shows a stack trace where a PHY worker generates a status PDU.
While holding the mutex to access rx_window, the stack thread on the
other hand, happily accesses the rx_window member without acquiring
the lock. This commit protects all handle_*() functions in write_pdu().
This reverts commit 1cbf7eac04.
instead of logging PDU received from below, and SDU that is forwarded
to above, only log the PDU in rx in info mode.
The next layer will do the same and log the PDU received (which is the SDU coming from here)
so there is now loss of information in the logs.
* check Pcell has configured Scells when entering function
* log if UE doesn't support CA (only if scells are configured)
* log info about CA activation only after all checks have passed
* fix typo
reducing the sync queue len to 1 caused an issue when the
PHY was locking the mutex while trying to push a TTI event
on the stack.
instead of signaling the new TTI within the PHY, we now do it outside
in the DUT (after releasing the PHY mutex)
apply same change that we've done on the eNB also on the UE
to avoid the PHY processing TTIs faster than the stack.
Without that, we see lots of those in the logs:
...
08:39:17.580325 [STCK] [W] Detected slow task processing (sync_queue_len=7).
...
before entering RRC idle, after receiving a RRC connection release for example,
we need to wait until the RLC for SRB1 or SRB2 have been flushed, i.e.
the RLC has acknowledged the reception of the message.
Previously we have only waited for SRB1 but the message can also be received on SRB2
and in this case both bearers need to be checked.
The method is now streamlined to check both SRBs and is also used when
checking the msg transmission of an detach request.
Here is the test output with the fix disabled:
13:47:42.679774 [RLC_UM_1] [D] MAC opportunity - 14 bytes
13:47:42.679784 [RLC_UM_1] [D] pdu_space=14, head_len=2
13:47:42.679790 [RLC_UM_1] [D] adding new SDU segment - 10 bytes of 10 remaining
13:47:42.679834 [RLC_UM_1] [D] Complete SDU scheduled for tx. Stack latency: 0 us
13:47:42.679909 [RLC_UM_1] [D] pdu_space=4, head_len=2
13:47:42.679922 [RLC_UM_1] [D] adding new SDU segment - 0 bytes of 10 remaining
13:47:42.679928 [RLC_UM_1] [I] Tx PDU SN=0 (14 B)
13:47:42.679974 [RLC_UM_1] [D] vt_us = 1
The test checks the correct packing and of the two PDUs at the end.
Andre Puschmann
Francisco Paisana
Xavier Arteaga
Pedro Alvarez
Ismael Gomez
Daniel Willmann