On 06/17/2011 04:38 PM, GIT version control wrote:
> Module: xenomai-jki
> Branch: for-upstream
> Commit: 7203b1a66ca0825d5bcda1c3abab9ca048177914
> URL:    
> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=7203b1a66ca0825d5bcda1c3abab9ca048177914
> Author: Jan Kiszka <jan.kis...@siemens.com>
> Date:   Fri Jun 17 09:46:19 2011 +0200
> nucleus: Fix interrupt handler tails
> Our current interrupt handlers assume that they leave over the same task
> and CPU they entered. But commit f6af9b831c broke this assumption:
> xnpod_schedule invoked from the handler tail can now actually trigger a
> domain migration, and that can also include a CPU migration. This causes
> subtle corruptions as invalid xnstat_exectime_t objects may be restored
> and - even worse - we may improperly flush XNHTICK of the old CPU,
> leaving Linux timer-wise dead there (as happened to us).
> Fix this by moving XNHTICK replay and exectime accounting before the
> scheduling point. Note that this introduces a tiny imprecision in the
> accounting.

I am not sure I understand why moving the XNHTICK replay is needed: if
we switch to secondary mode, the HTICK is handled by xnpod_schedule
anyway, or am I missing something?


Xenomai-core mailing list

Reply via email to