[riot-devel] Odd problems with xtimer

Michael Andersen michael at steelcode.com
Wed Feb 24 22:13:14 CET 2016


I did actually put a check in, and break and get back the details. I put
the stacktrace on an issue:

https://github.com/RIOT-OS/RIOT/issues/4841

I have not made a reproducer because I've been pretty busy, but also
because if the problem is due to the network stack, it might be hard to
reproduce without all the other chatty nodes around sending ND, RPL and UDP
traffic.

On Wed, Feb 24, 2016 at 1:09 PM, malo <malo at 25cmsquare.io> wrote:

> Hello Michael,
>
> this is ugly hack indeed...
> could you rather add some check into the _add_timer functions, put
> breakpoint there and send the backtrace back?
>
> Anyway majority of the authors are probably still in the list, so
> everybody just scratch the top of the head and tries to remember if setting
> timer from two threads somewhere?
>
> wbr
> malo
>
>
> On 24 February 2016 at 21:02, Michael Andersen <michael at steelcode.com>
> wrote:
>
>>
>>>
>>> Would you be willing to share this hack with us? Maybe it gives us more
>>> insights.
>>>
>>>
>> Sure! Here is what I did:
>>
>> This is the "lightweight" remove
>> +int _xtimer_ensure_remove(xtimer_t *timer)
>> +{
>> +  int res = 0;
>> +  if (timer_list_head == timer) {
>> +      uint32_t next;
>> +      timer_list_head = timer->next;
>> +      if (timer_list_head) {
>> +          next = timer_list_head->target - XTIMER_OVERHEAD;
>> +      }
>> +      else {
>> +          next = _lltimer_mask(0xFFFFFFFF);
>> +      }
>> +      _lltimer_set(next);
>> +  }
>> +  else {
>> +      res = _remove_timer_from_list(&timer_list_head, timer) ||
>> +          _remove_timer_from_list(&overflow_list_head, timer) ||
>> +          _remove_timer_from_list(&long_list_head, timer);
>> +  }
>> +
>> +  return res;
>> +}
>>
>> And then I call it from these two places inside the existing critical
>> sections:
>>
>> @@ -104,6 +106,7 @@ void _xtimer_set64(xtimer_t *timer, uint32_t offset,
>> uint32_t long_offset)
>>          }
>>
>>          int state = disableIRQ();
>> +        _xtimer_ensure_remove(timer);
>>          _add_timer_to_long_list(&long_list_head, timer);
>>          restoreIRQ(state);
>>          DEBUG("xtimer_set64(): added longterm timer (long_target=%"
>> PRIu32 " target=%" PRIu32 ")\n",
>> @@ -179,6 +182,7 @@ int _xtimer_set_absolute(xtimer_t *timer, uint32_t
>> target)
>>      }
>>
>>      unsigned state = disableIRQ();
>> +    _xtimer_ensure_remove(timer);
>>      if ( !_this_high_period(target) ) {
>>          DEBUG("xtimer_set_absolute(): the timer doesn't fit into the
>> low-level timer's mask.\n");
>>          _add_timer_to_long_list(&long_list_head, timer);
>>
>> I then ran it for a week without problems (previously it would definitely
>> crash within two hours). It's a bad hack though because we spend the effort
>> to remove the timer earlier in the call chain so I really don't want to
>> duplicate that work. Also, from my understanding, the timer should never
>> actually be there so I don't like hiding the fact that somewhere else
>> someone is doing something ugly.
>>
>>
>>> Cheers,
>>> Oleg
>>> --
>>> panic("This never returns");
>>>         linux-2.6.6/kernel/power/swsusp.c
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20160224/34ed95a9/attachment.html>


More information about the devel mailing list