Re: [Xenomai] Context switching kernel tracing

["Stéphane ANCELOT" <sancelot@free.fr>]

Hi,


The SMI is the source of my problems. the global SMI bit in the ICH6 can 
not be disabled .

However, I used a 32 bits mask trying to disable any bits and managed to 
reduce the latency (worst : 15us )


refer to paragraph 10.8.3.12 for ICH6 chipset :
http://www.intel.com/content/www/us/en/io/io-controller-hub-6-datasheet.html



Regards,
Steph

On 30/05/2013 20:19, Gilles Chanteperdrix wrote:
> 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?
>