Re: [Xenomai] "inconsistent lock state" on boot-up

[Jan Kiszka <jan.kiszka@siemens.com>]

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