On 05/30/2013 03:12 PM, Stéphane ANCELOT wrote:
> On 30/05/2013 13:38, Gilles Chanteperdrix wrote:
>> On 05/30/2013 09:03 AM, Stéphane ANCELOT wrote:
>>
>>> Hi,
>>>
>>> I have got some problems with an architecture, and 2 realtime tasks.
>>>
>>> The realtime is not always respected.
>>
>> Hi,
>>
>> a few things to check:
>>
>> Would there be any involuntary mode switches? See rt_task_set_mode or
>> pthread_set_mode_np documentation to enable debug.
> There is not any involuntary mode switches in the xenomai application.
>
> The buggy architecture is celeron M:
>
> Intel® 910GMLE / ICH6M chipsets
>
> the same disk application, if setted up in the following architecture,
> has no problem:
> Intel® 852GM and ICH4 chipset
>
> Are you able to reproduce the problem with the latency test? You can
> launch several instances in parallel, if you absolutely need several
> task. If yes, then probably the easiest solution is to enable the I-pipe
> tracer, then run the latency test with the -f argument.
>
> I have read more documentation in kernel tracing, and it seems I won't
> need lttng, but it looks like only kernel tracing would be enough ?
>
> I have not managed to reproduce it with a single instance of latency
> test. (and I have no problem using a single rt task...) . I will try 2
> instances.
>
> One more thing that is surprising : I monitored the tasks delay using
> clock_gettime() , the software does not watch any big lag !!! ...but it
> is visible in the scopemeter using com port signals (up to 300us
> possible !!!!) ....
I would say it means that the tsc (and APIC) stop during some idle
states of the system. I suppose you have CONFIG_CPU_IDLE turned off?
Could you try booting with nohlt or idle=poll ?
>
> I also was thinking about a problem with the high res. timers, I tried
> the HPET timers, but this has not helped.
I do not believe Xenomai is able to use the HPET timers with Linux 2.6.34.
>
>>> This is a very strange problem in this architecture, since it happens
>>> statically almost every three reboots...
>>>
>>> It looks like there is something in the kernel / or setted up by bios
>>> that is happening and locks the task switching context.
>>
>> Ok, so if it has a bios, it is an x86. Which version of the I-pipe patch
>> and Xenomai are you using? Can not it be an SMI issue, have you tried
>> the SMI workaround?
>
>
> yes, I have tried disabling SMI, but in anyway it fails as follow:
>
> Xenomai: SMI-enabled chipset found
> Xenomai: SMI workaround failed!
Ok then, your BIOS vendor does not want you to disable the SMI global
bit, have you tried other bits?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
