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.
during the PDU packing it could happen that a new SDU segment
was added but the resulting larger header was so big that not even
a single byte of the new PDU could be added. because this
corner case wasn't handled correctly an invalid PDU was transmitted.
the solution is to revert the addition of the new SDU.