Changes
#11570 (Jun 22, 2026, 7:58:09 AM)
struct gsm_bts: drop unused ms_max_power
Change-Id: I0b02015db8b8e670eaff40c578f0474d9be9bb45
Change-Id: I0b02015db8b8e670eaff40c578f0474d9be9bb45
tests/meas: remove unused 'delta'
gcc 16.1.1 emits a -Wunused-but-set-variable warning.
Change-Id: I2540d701743caefb4bf54bb5b4ebe683d3257071
gcc 16.1.1 emits a -Wunused-but-set-variable warning.
Change-Id: I2540d701743caefb4bf54bb5b4ebe683d3257071
common: track whether gsm_time has been initialized
l1sap_info_time_ind() used 'bts->gsm_time.fn != 0' as a proxy for
"we have a previous frame number to diff against". This is unreliable:
Fn=0 is a _valid_ frame number, recurring on every hyperframe wrap.
If gsm_time.fn happened to be 0 and the next time indication jumped
forward by more than one frame, the real gap was silently swallowed.
It also gave no clean way to suppress the bogus "Invalid condition
detected: Frame difference is ..." message that appears when the PHY
(re)starts its TDMA frame number (e.g. from 0) on bring-up.
Introduce an explicit 'bts->gsm_time_valid' flag instead:
* l1sap_info_time_ind() treats the first indication of an epoch as
having no gap (frames_expired = 0): no warning, no RACH-slot
accounting;
* the flag is cleared in st_op_disabled_notinstalled_on_enter(), so
each BTS bring-up starts a fresh clock epoch regardless of which
FN the PHY reports first.
Change-Id: I7022b0ad084a0c224f7e8c04aca0648915b1a1c6
AI-Assisted: yes (Claude)
Related: OS#7020
l1sap_info_time_ind() used 'bts->gsm_time.fn != 0' as a proxy for
"we have a previous frame number to diff against". This is unreliable:
Fn=0 is a _valid_ frame number, recurring on every hyperframe wrap.
If gsm_time.fn happened to be 0 and the next time indication jumped
forward by more than one frame, the real gap was silently swallowed.
It also gave no clean way to suppress the bogus "Invalid condition
detected: Frame difference is ..." message that appears when the PHY
(re)starts its TDMA frame number (e.g. from 0) on bring-up.
Introduce an explicit 'bts->gsm_time_valid' flag instead:
* l1sap_info_time_ind() treats the first indication of an epoch as
having no gap (frames_expired = 0): no warning, no RACH-slot
accounting;
* the flag is cleared in st_op_disabled_notinstalled_on_enter(), so
each BTS bring-up starts a fresh clock epoch regardless of which
FN the PHY reports first.
Change-Id: I7022b0ad084a0c224f7e8c04aca0648915b1a1c6
AI-Assisted: yes (Claude)
Related: OS#7020
osmo-bts-trx: shut down on stale clock indication from transceiver
We expect the transceiver to be a reliable, monotonic clock source.
If it reports an FN far behind our local timer (elapsed_fn < 0) while
far more wall-clock time elapsed than its FN advance accounts for,
its clock has likely stalled and the indication carries a stale frame
number. Acting on it drags the scheduler backwards and re-transmits
already-sent TDMA frames, corrupting lchan-internal state(s).
Detect this and shut down the process, same rationale as the existing
"PC clock skew too high" check in trx_fn_timer_cb().
Change-Id: If787ab7ed70aa2dcb0389ceb58620c2302c3431a
AI-Assisted: yes (Claude)
Related: OS#7020, OS#6794
We expect the transceiver to be a reliable, monotonic clock source.
If it reports an FN far behind our local timer (elapsed_fn < 0) while
far more wall-clock time elapsed than its FN advance accounts for,
its clock has likely stalled and the indication carries a stale frame
number. Acting on it drags the scheduler backwards and re-transmits
already-sent TDMA frames, corrupting lchan-internal state(s).
Detect this and shut down the process, same rationale as the existing
"PC clock skew too high" check in trx_fn_timer_cb().
Change-Id: If787ab7ed70aa2dcb0389ceb58620c2302c3431a
AI-Assisted: yes (Claude)
Related: OS#7020, OS#6794