From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <546A2C50.3060204@siemens.com> Date: Mon, 17 Nov 2014 18:11:44 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20141110201409.GS17476@sisyphus.hd.free.fr> <54611D4E.6090308@web.de> <20141110202326.GU17476@sisyphus.hd.free.fr> <54612002.6010102@web.de> <20141110203747.GV17476@sisyphus.hd.free.fr> <5461232E.5000006@web.de> <20141110205512.GW17476@sisyphus.hd.free.fr> <20141110215846.GX17476@sisyphus.hd.free.fr> <20141112172738.GD17476@sisyphus.hd.free.fr> <546A26C0.1050309@siemens.com> <20141117165924.GM26613@sisyphus.hd.free.fr> In-Reply-To: <20141117165924.GM26613@sisyphus.hd.free.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] "inconsistent lock state" on boot-up List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" On 2014-11-17 17:59, Gilles Chanteperdrix wrote: > On Mon, Nov 17, 2014 at 05:48:00PM +0100, Jan Kiszka wrote: >> On 2014-11-12 18:27, Gilles Chanteperdrix wrote: >>> We do not need trace_hardirqs_on and trace_hardirqs_off for the >>> particular case of IRQs: they are already handled by >>> __ipipe_do_sync_stage. >> >> That was the key: Simply disabling the instrumentations in the >> CONFIG_IPIPE removes all lock state inconsistencies, at least this far: >> >> diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S >> index d32f8bd..d8e0b2c 100644 >> --- a/arch/arm/kernel/entry-header.S >> +++ b/arch/arm/kernel/entry-header.S >> @@ -195,7 +195,7 @@ >> #ifdef CONFIG_IPIPE_DEBUG_INTERNAL >> bl __ipipe_bugon_irqs_enabled >> #endif >> -#ifdef CONFIG_TRACE_IRQFLAGS >> +#if defined(CONFIG_TRACE_IRQFLAGS) && !defined(CONFIG_IPIPE) >> @ The parent context IRQs must have been enabled to get here in >> @ the first place, so there's no point checking the PSR I bit. >> bl trace_hardirqs_on >> @@ -203,7 +203,7 @@ >> .else >> @ IRQs off again before pulling preserved data off the stack >> disable_irq_notrace >> -#ifdef CONFIG_TRACE_IRQFLAGS >> +#if defined(CONFIG_TRACE_IRQFLAGS) && !defined(CONFIG_IPIPE) >> tst \rpsr, #PSR_I_BIT >> bleq trace_hardirqs_on >> tst \rpsr, #PSR_I_BIT >> >> Will send a patch. > > Will this work for other paths in entry.S, such as exceptions or > syscalls? Do they all come along that code? Then we need to differentiate, likely via a separate macro parameter. Just noticed that there is also svc_enter, and that should be handled in the same way. And it's likely also shared across the board. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux