Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Richard Cochran wrote:
>>> On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
>>>> To help debugging this, please run the kernel which crashes with I-pipe
>>>> enabled, without Xenomai, and the attached test, in order to see if the
>>>> tsc behaves correctly.
>>> Getting back to this, I did try the test program with ipipe 2.6.35 but
>>> without xenomai. It seems to run fine. But I only ran it for a few
>>> minutes. The exact version was ipipe-126.96.36.199-arm-1.18-01 plus endian
>>> fix, and I attached the config.
>>> I enabled the *third* #if-elif-else case thinking it to be the correct
>>> one to test. (see below)
>> Yes, that was the correct thing to do. I assumed that when you enabled
>> Xenomai, the system was running, and that it frozen when you started a
>> Xenomai application. Which is not your case at all.
>>> So, assuming I got that right, then the new tsc code passes the test.
>>> Next I'll try to get some better information about the freeze. Any
>>> other ideas?
>> We have only one commit to inspect, that should not be so hard. Next
>> thing to try is to see what changed in the other parts of this commit.
>> We should look at the interrupt handler, ipipe_mach_set_dec,
>> ipipe_mach_release_timer to see what change had such an effect. I will
>> try to reorder the functions to have a more readable diff. You can also
>> check if we pass the rthal_calibrate_timer function.
> Hi Richard,
> I am currently running some benchmarks on an AT91SAM9263 board, to see
> whether we have some performance regression.
The FCSE support in the I-pipe patch for Linux 2.6.30 needs this
Otherwise you get segmentation faults when exceeding the 95 processes limit.
Xenomai-core mailing list