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/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deHi Ruben,
> Most of the openbsc packages are now up-to-date in Debian! :
> https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org
Nice!
I'd like to mention a detail, recently I tried to build osmo-iuh on a freshly
installed Debian 9 machine, and it gets a segfault in gcc. Do you hit this when
building packages?
Thanks!
~N
On Mon, Nov 12, 2018 at 10:35:28PM +0100, Ruben Undheim wrote:
> Hi,
>
>
> , but there are a few failing builds on some officially supported
> Debian architectures (mostly failing test suites):
>
> osmo-bsc:
> - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=mips&ver=1.2.1-1&stamp=1542052520&raw=0)
> ("gsm0408" and many "handover" tests failing)
I rebuilt repositories matching osmo-bsc version 1.2.1 as indicated here; was a
bit hard until I disabled Werror as well as the address sanitizer.
Comparing the output...
Quite early up in the test, a measurement report is simulated, and on mips, it
is interpreted as two neighbors, while there should be only one neighbor.
Should be:
- Sending measurement report from mobile #0 (rxlev=30, rxqual=6)
* Neighbor cell #0, actual BTS 1 (rxlev=40)
DRSL abis_rsl.c:1538 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0
DMEAS abis_rsl.c:1409 [(bts=0,trx=0,ts=1,ss=0)] MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-110dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR=-22dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-80dBm RXL-SUB-dl=-80dBm RXQ-FULL-dl=6 RXQ-SUB-dl=6 NUM_NEIGH=1
DMEAS abis_rsl.c:1442 IDX=0 ARFCN=871 BSIC=63 => -70 dBm
DHODEC handover_decision_2.c:1131 (lchan 0.010 TCH/F) (subscr unknown) MEASUREMENT REPORT (1 neighbors)
DHODEC handover_decision_2.c:1136 (lchan 0.010 TCH/F) (subscr unknown) 0: arfcn=871 bsic=63 neigh_idx=0 rxlev=40 flags=0
DHODEC handover_decision_2.c:291 (lchan 0.010 TCH/F) (subscr unknown) neigh 871 new in report rxlev=40 last_seen_nr=0
mips gets:
- Sending measurement report from mobile #0 (rxlev=30, rxqual=6)
* Neighbor cell #0, actual BTS 1 (rxlev=40)
DRSL abis_rsl.c:1538 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0
DMEAS abis_rsl.c:1409 [(bts=0,trx=0,ts=1,ss=0)] MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-110dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR=-22dBm L1_FPC=0 L1_TA=0 DTXu NOT VALID NUM_NEIGH=2
DMEAS abis_rsl.c:1442 IDX=28 ARFCN=0 BSIC=0 => -77 dBm
DMEAS abis_rsl.c:1442 IDX=0 ARFCN=871 BSIC=0 => -96 dBm
DHODEC handover_decision_2.c:1131 (lchan 0.010 TCH/F) (subscr unknown) MEASUREMENT REPORT (2 neighbors)
DHODEC handover_decision_2.c:1136 (lchan 0.010 TCH/F) (subscr unknown) 0: arfcn=0 bsic=0 neigh_idx=28 rxlev=33 flags=0
DHODEC handover_decision_2.c:1136 (lchan 0.010 TCH/F) (subscr unknown) 1: arfcn=871 bsic=0 neigh_idx=0 rxlev=14 flags=0
DHODEC handover_decision_2.c:291 (lchan 0.010 TCH/F) (subscr unknown) neigh 0 new in report rxlev=33 last_seen_nr=0
DHODEC handover_decision_2.c:291 (lchan 0.010 TCH/F) (subscr unknown) neigh 871 new in report rxlev=14 last_seen_nr=0
On mips the report is misinterpreted with wildly wrong values; actually starts
with "DTXu NOT VALID", continues with the bsic and rxlev... I wonder why that
happens.
Either handover_test.c encodes it non-portably, or the decoding has a problem.
handover_test.c encodes a measurement report using struct gsm48_meas_res, which
has sub-byte ints. It is known that these need #ifdef shims to swap the
positions for big-endian vs. little-endian, which this struct does *not* have.
This mips is big endian, right? Then that would be the issue.
Unfortunately I can't test on mips, is there any way that we can easily test a
patch on such an arch?
Also, if we fix this on current master, then that doesn't help osmo-bsc v 1.2.1
using libosmocore 0.11.0. We don't have a backporting process at Osmocom. Yet.
Maybe it will just be broken until we package more recent versions?
There are numerous other packed structs in
libosmocore/include/osmocom/gsm/protocol/gsm_04_08.h with sub-byte ints that
lack the BIG_ENDIAN shims.
https://osmocom.org/issues/3693
I don't have a fix yet, let's discuss how a fix would help debian builds as
asked above...
And whether we really need to support big endian...?
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20181114/58c2ad94/attachment.bin>