Attention is currently required from: neels, laforge.
8 comments:
Patchset:
Thanks for the confidence boost. […]
Done
Patchset:
Hi Neels,
The feedback was really helpful. I think the patch is looking more like what you have in mind now.
I am fighting a new handover test failure. Apologies for the silly question but how can I even see what is going on there? I see the expout and testsuite.log files but they don't offer any detail other than pointing out which test failed. Currently, I only know that test_max_ta.ho_vty is the failing sub-test. Obviously I'm missing something basic in the Osmo dev env / work cycle.
Many thanks again,
-Michael
File include/osmocom/bsc/gsm_data.h:
Patch Set #13, Line 771: struct osmo_time_cc timekeeper;
here is your problem: the lchan is completely cleared out every time an lchan is activated / unused. […]
Thanks! I'm understanding the lifecycle better now.
File src/osmo-bsc/gsm_data.c:
Patch Set #13, Line 354: !&lchan->activate.timekeeper
a) the address of a struct member is *always* non-NULL. […]
Done
File src/osmo-bsc/lchan_fsm.c:
Patch Set #13, Line 226: lchan->activate.timekeeper = (struct osmo_time_cc){
also you probably want to do this only once during lchan allocation, i.e. […]
Done
Patch Set #13, Line 228: .gran_usec = 1*1000000,
if you want milliseconds, 1000 is your factor. […]
Changed to milliseconds and changed forget_sum_usec to 1 to discard remainders.
Patch Set #13, Line 237: /* TMP HACK: this fixes "make check" handover tests... */
yeah because you re-init the lost state after lchan_reset().
Done
Patch Set #13, Line 558: if (&lchan->activate.timekeeper) {
this condition is never false, as above. simply set the the flag without condition.
The check has been changed. I think it's still necessary as there isn't any sanity checking in osmo_time_cc_set_flag itself and not all lchans will have a timer attached.
To view, visit change 27081. To unsubscribe, or for help writing mail filters, visit settings.