On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
> On 06/17/2011 11:27 AM, Jan Kiszka wrote:
>> Based on code inspection, it looks like a timer handler triggering a
>> reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
>> xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
>> reschedule before all expired timers were processed. The timer core is
>> usually run atomically from an interrupt handler, so better emulate an
>> IRQ context inside xntbase_tick by setting XNINIRQ.
> I do not understand this one either: if we are inside
> xntimer_tick_aperiodic, XNINIRQ is already set.
Not if you come via xntbase_tick, called by the mentioned skins also
outside a timer IRQ (at least based on my understanding of that skin
APIs). But I might be wrong, I just came across this while checking for
potentially invalid cached xnpod_current_sched values.
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list