Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Richard Cochran wrote:
> On Fri, Apr 22, 2011 at 07:55:35AM +0200, Gilles Chanteperdrix wrote:
>> I also had a look at the culprit patch, reducing it to the bare minimum
>> (no useless whitespace changes and no function moves), and it boils down
>> to only two differences:
>> 1- the fact that we use the "generic" clocksource created by
>> ipipe_tsc_register, which probably has a shift of 25 or 26 bits instead
>> of the 20 bits shift of the original clocksource, and returns a 64 bits
>> value instead of 32 bits.
>> 2- the fact that the tsc update is done with hardware irqs off in the
>> original patch.
> 
> Thanks for looking into this for me. I tried the patch, but the
> result is the same as before:
> 
> - Kernel freezes immediately if xenomai is not a module.
> 
> - If xenomai is a module, the nucleus loads, but the first skin module
>   freezes the machine.
> 
> I will take a closer look next week to see if I can find out at least
> where the freeze happens.

Ok. It means that rthal_calibrate_timer works, the system freezes when
Xenomai steals the timer. However, since the ipipe_mach_set_dec,
ipipe_mach_release_timer code did not change, it does not really make
sense. But in order to trace the issue, you should probably trace the
calls to ipipe_mach_set_dec/ipipe_mach_acktimer to see which one is the
last before the freeze.

On my side, I have run benches on at91sam9263, but am not done yet,
though yet I have not found a lot of differences in latencies between
2.4.10 and 2.5.6.

Which version of the I-pipe patch were you running with 2.4.10?

-- 
                                                                Gilles.