From mboxrd@z Thu Jan 1 00:00:00 1970 References: <560AB34B.5020300@xenomai.org> <560AB938.8090905@xenomai.org> From: Philippe Gerum Message-ID: <561568AE.30109@xenomai.org> Date: Wed, 7 Oct 2015 20:47:10 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Interrupt latency close to 1ms on powerpc Xenomai 2.6.4 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "PRADHAN, MAKARAND (RC-CA)" , "Xenomai@xenomai.org" On 10/07/2015 04:25 PM, PRADHAN, MAKARAND (RC-CA) wrote: > Hi All, > > On further experimentation, I still feel that rt_intr_enable may be causing my user space int handler to jump into secondary domain. > rt_intr_enable() is a secondary domain call, it cannot execute over the primary domain simply because the infrastructure shared with the regular kernel that might be involved to enable/disable IRQs requires this. The nucleus forcibly relaxes the calling thread for this reason. So the behavior you observe is not a bug, it is actually the intent and requirement for carrying out such request. Check ksrc/native/syscall.c:4152, this call is tagged as "lostage", meaning that it shall run from the lowest pipeline domain stage, i.e. linux. This is the reason why handling interrupt top-halves in userland is a bad idea, and also the reason why the RT_INTR support has completely disappeared from 3.x's Alchemy API (formerly know as 2.x's "native" API), in favor of a UIO-like model called UDD, standing for "user-space device driver". There, top-halves must live in kernel space, and bottom-halves may live in userland, which is the only sane and safe way to handle interrupts from the latter. The rationale for this change is stated here: http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#irqhandling -- Philippe.