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/.
Pau Espin Pedrol gerrit-no-reply at lists.osmocom.orgPatch Set 1: > I was alsmost sure this introduces a flaw in the logic, but after > pondering a few minutes, in the end found it to be correct indeed > :) > > Still I'm wondering, what is the cause for submitting the POWEROFF > twice in the first place, is it possible to fix the logic at the > cause instead of filtering out the error later? I didn't look in detail because the issue I was investigating was taking my concerns, but basically from what I recall in osmo-bts-trx log, I think osmo-bts-trx sends the first POWEROFF at startup in case it is connected to stop it from emiting while not configured. Then, when BSC connects to BTS and configures it (OML), apparently it first powers it off in order to configure it. I cannot confirm now since I don't have the setup now here, and anyway I'd need to spend some time to verify all this. > > Also we're now filtering any message that occurs twice, is the > strcmp sufficient to ensure that the two commands are indeed > redundant? Could it be the same cmd string with differing > arguments, and we end up filtering out important commands now? > The strcmp should be sufficient because the cmd string field already contain the parameters. -- To view, visit https://gerrit.osmocom.org/5237 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib6a5e7bfac8bc5e1b372da6a1f801c07a3d5ebb7 Gerrit-PatchSet: 1 Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-HasComments: No