Re: [Xenomai-help] [Ethercatmaster-users] EML conflict with RTCAN? low_level_input framebuilding failed.

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Roland Tollenaar wrote:
> Hi,
> 
>> Check the /proc output again, there should be also RTnet's stack manager
>> at prio 98. Maybe that is too low for your scenario and causes prio
>> inversions (note: every incoming Ethernet frame goes through its hands).
>> Try lowering the prio of your rt_task1 beneath 98.
> 
> Thanks. This seems to have made a big improvement. I have so far not
> once detected the scope to loose lock on the sawtooth when the
> index_check in eml is still disabled. Before lowering the priority of my
> task (to 97) I could still invoke what I suspect to be a latency spike.
> 
> If the index_check is enabled I now mostly have less problems too. There
> is a chance in start-up of the application that there is a latency spike
> and then the warning kicks in. Due to the fact that the shift is
> permanent, the error is persistent and this then destabilizes the
> sawtooth a bit.

Hmm, this doesn't convince me yet. Such skews during startup may as well
be triggered by unusual load during runtime (non-RT activity or new RT
components). Did you put your system under adequate non-RT load as well
while measuring the outputs?

> 
> I will keep the check disabled but for the EML chaps I do think this is
> a point of interest. I would be very interested how this index shift
> occurs and why it is persistent after occurring once.
> 
> Sorry for the pragmatic qualifications here but in the end its the
> stability of the outputs that will determine the behaviour of the
> machine so its not a bad way to assess the software. :)

A problem isn't solved until it is also understood.

> 
>> If the problem persists (or your _really_ want to understand what
>> happens), you could try to put an xntrace_user_freeze(0, 1) before the
>> line which emits that EML warning, turn on the I-pipe tracer, set a
>> large back_trace_points value (a few thousand), enable verbose mode, and
>> grab what /proc/ipipe/trace/frozen reports after the hick-up. See [1]
>> for more howtos.
> 
> Done this before so it should not be a problem. Don't think it is

In that case, I would even more suggest to collect the data, maybe now
about the fragile startup case.

> necessary quite yet as the behaviour at the moment looks good.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]