Bug #5338
openLMSDevice.cpp:261 Power parameters requested before Tx Frequency was set! Providing band 900 by default...
0%
Description
Posting in osmo-bts as I assume it is an osmo-bts issue, although it is observed with osmo-trx-lms as I don't currently have any other TRX hardware.
How to reproduce:
Bring up a BTS with osmo-trx-lms
such as:
while [ 0 ] ; do sleep 1; sudo osmo-trx-lms -C osmo-trx-lms.cfg; done
# osmo-bts doesn't exit anymore, put it it a loop anyway: while [ 0 ] ; do sleep 1; osmo-bts-trx -c osmo-bts-trx.cfg ; done
Once the BTS is up, drop it from the BSC:
drop bts connection X oml
The bts will ramp the power down, then finally issue RFMUTE then start to bring it up again:
A bunch of stuff will happen here, that may or may not depend on the config, but the point is that eventually we get to:
Sun Dec 5 14:42:06 2021 DTRXDUL FATAL <0004> Transceiver.cpp:1309 Something went wrong in thread RxLower, requesting stop Sun Dec 5 14:42:06 2021 DTRXCTRL INFO <0002> Transceiver.cpp:1031 [chan=0] response is 'RSP POWERON 0' Sun Dec 5 14:42:06 2021 DDEV INFO <0005> LMSDevice.cpp:159 Closing LMS device
osmo-trx-lms exits and the shell restarts it:
Then we will see:
Sun Dec 5 14:42:09 2021 DTRXCTRL INFO <0002> Transceiver.cpp:877 [chan=0] command is 'POWERON' Sun Dec 5 14:42:09 2021 DDEV INFO <0005> LMSDevice.cpp:390 starting LMS... Sun Dec 5 14:42:09 2021 DDEV ERROR <0005> LMSDevice.cpp:261 Power parameters requested before Tx Frequency was set! Providing band 900 by default...
ad infinitum...
Also if the sleep in the TRX loop is increased to say 5 seconds, then when osmo-trx-lms starts again, the BTS
has logged Shutting down BTS, exit 1, reason: No clock since TRX was started. and now needs manual intervention.
In this state, dropping the BTS just results in:
BTS_SHUTDOWN(bts0)[0x5618af2268f0]{WAIT_RAMP_DOWN_COMPL}: BTS is already being shutdown.
I now have to CTRL-QUIT the osmo-bts-trx process or killall -[3|9] osmo-bts-trx or somesuch :(
I could attach entire logs/configs et al, but I'd be very surprised if this is not 100% reproducible.
Updated by fixeria over 2 years ago
I can confirm that I experienced a similar behavior:
- osmo-trx-lms needs to be restarted every time I restart osmo-bts-trx,
- osmo-trx-uhd runs stable across osmo-bts-trx restarts.
So to me this looks more like a problem of osmo-trx-lms and the issue should be moved to OsmoTRX.