This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
fixeria gerrit-no-reply at lists.osmocom.orgHello pespin, neels, laforge, Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmocom-bb/+/19201 to look at the new patch set (#5). Change subject: trxcon/scheduler: check TDMA frame order, drop out of order bursts ...................................................................... trxcon/scheduler: check TDMA frame order, drop out of order bursts When running together with fake_trx.py (mostly used back-end), it is currently possible that Downlink bursts are received in a wrong order if more than one transceiver is configured (multi-trx mode). This is how it looks like: DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0 DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0 DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632) so here a burst with TDMA fn=633 was received earlier than a burst with TDMA fn=632. The burst loss detection logic considered the latter one as lost, and substituted it with a dummy burst. When finally the out-of-order burst with TDMA fn=632 was received, we got the large number of allegedly elapsed frames: ((632 + 2715648) - 633) % 2715648 == 2715647 Given that late bursts get substituted, the best thing we can do is to reject them and log an error. Passing them to the logical channel handler (again) might lead to undefined behaviour. Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772 Related: OS#4658, OS#4546 --- M src/host/trxcon/sched_trx.c 1 file changed, 26 insertions(+), 5 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmocom-bb refs/changes/01/19201/5 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/19201 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772 Gerrit-Change-Number: 19201 Gerrit-PatchSet: 5 Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de> Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: pespin <pespin at sysmocom.de> Gerrit-MessageType: newpatchset -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200712/7048bad5/attachment.htm>