From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <52838180.7070701@xenomai.org> Date: Wed, 13 Nov 2013 14:41:20 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <528290CE.1030002@xenomai.org> <52837DD0.1050405@siemens.com> In-Reply-To: <52837DD0.1050405@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] issues with debugging enabled List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Xenomai On 11/13/2013 02:25 PM, Jan Kiszka wrote: > On 2013-11-12 21:34, Gilles Chanteperdrix wrote: >> >> Hi, >> >> for a change, I ran the xeno-regression-test with a lot of debugging and >> options known to having caused problems in the past and found two issues: >> >> on x86 SMP, with full dynticks and debugging enabled (preemptible kernel >> debugging, mutex, spinlocks, and sleep inside spinlocks), I get the >> series of warnings at the end of the mail. > > We are currently facing crashes inside __switch_to, FPU related > (non-existing save area). Probably the issue solved by this patch: http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=9b3320eef67e3f118f96065c8c2584b715710d94 > Once that is sorted out, we can have a look at > that scenario as well. Do you have the .config online somewhere? http://sisyphus.hd.free.fr/~gilles/config-nestor >> on ARM, when a fault occurs, the fault ode is entered with hardware irqs >> off (this is a recent change in the mainline kernel, this code used to >> be executed with hardware irqs on), so I do: >> >> ipipe_stall_root(); >> hard_local_irq_enabled(); >> >> But the context checking does not like that. >> >> Any idea how to fix these? > > Only ARM's SMP version of ipipe_stall_root() contains > ipipe_stall_root(), UP and at least x86 do not have this. I understand > that it makes sense to deny this call over non-root, but as it is about > fixing up imbalances in the pipeline state, ipipe_stall_root() is likely > not the best choice. What about open-coding the relevant check for the > domain? Maybe it also works to push the check to the end of > ipipe_stall_root, i.e. after fixing up the pipeline state. I have to run again the test and check what really happens, because like Philippe said, it may be that I am using ipipe_stall_root() when entering this code over non root context, and that would be incorrect. I have to report the trap to the pipeline first so as to give a chance to Xenomai to relax the thread, then enable irqs over root. -- Gilles.