From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4DFB869F.9080006@domain.hid> Date: Fri, 17 Jun 2011 18:53:51 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : nucleus: Fix interrupt handler tails List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xenomai core 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 > 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? -- Gilles.