https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-06-26T14:37:47ZOpen Source Mobile CommunicationsOsmoTRX - Bug #4622: Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-trx after osmo-bts-trx proper restarthttps://osmocom.org/issues/4622?journal_id=189602020-06-26T14:37:47ZHoernchen
<ul></ul><p>I'm a bit suprised this works at all, since the internal state is kept on stop/poweroff, so the smpl_buf keep their timestamps, which means that at least for the IPC backend a restart where the other side resets the timestamps (as expected) does not work. In this case it works as long as the timeout until it restarts is not long enough for the timestamp to wrap, so the data is still "newer".</p>
<p>Obviious question here: do we want to support start/stop without restarting osmo-trx? In that case the state needs to be reset upon stopping.</p> OsmoTRX - Bug #4622: Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-trx after osmo-bts-trx proper restarthttps://osmocom.org/issues/4622?journal_id=189612020-06-26T14:59:11ZHoernchen
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoTRX - Bug #4622: Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-trx after osmo-bts-trx proper restarthttps://osmocom.org/issues/4622?journal_id=189622020-06-26T15:03:45Zpespin
<ul></ul><p>Yes we should support it. I'm happy if you want to take care about this one since you already seem to found the issue.</p>
<p>bear in mind the issue was found with osmo-trx-uhd, but I guess it affects other backends too.</p> OsmoTRX - Bug #4622: Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-trx after osmo-bts-trx proper restarthttps://osmocom.org/issues/4622?journal_id=189842020-06-30T12:01:53Zfixeria
<ul></ul><p>Huh, this may be related to a similar thing I saw with fake_trx.py [1]:</p>
<pre>
2020-06-30 07:45:56 [DEBUG] ctrl_if_trx.py:123 (BTS@172.18.9.20:5700) Recv POWEROFF cmd
2020-06-30 07:45:56 [INFO] ctrl_if_trx.py:125 (BTS@172.18.9.20:5700) Stopping transceiver...
2020-06-30 07:45:56 [INFO] transceiver.py:257 Stopping clock generator
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=0 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=1 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=2 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=3 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=4 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=5 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=6 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2197 tn=7 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=0 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=1 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=2 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=3 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=4 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=5 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=6 bl=148 pwr=0), but transceiver is not running => dropping...
2020-06-30 07:45:56 [WARNING] transceiver.py:269 (BTS@172.18.9.20:5700) RX TRXD message (ver=1 fn=2198 tn=7 bl=148 pwr=0), but transceiver is not running => dropping...
</pre>
<p>so osmo-bts-trx keeps scheduling and sending Downlink bursts even after sending TRXC POWEROFF command.<br />Probably, until the response is received from transceiver.</p>
<p>[1] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/938/artifact/logs/fake_trx/fake_trx.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/938/artifact/logs/fake_trx/fake_trx.log</a></p> OsmoTRX - Bug #4622: Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-trx after osmo-bts-trx proper restarthttps://osmocom.org/issues/4622?journal_id=190502020-07-06T11:57:46Zpespin
<ul><li><strong>Assignee</strong> changed from <i>pespin</i> to <i>Hoernchen</i></li></ul>