Hallo,
as this discussion could be of interest to other people I continue it here.
On 04/12/2011 07:58 PM, Philippe Gerum wrote:
On Tue, 2011-04-12 at 17:01 +0200, Martin Elshuber wrote:
Hallo Mr. Gerum!
First, thx for the answer of the ADEOS list
thx for investing a lot of time in the NIOS
Le 14/04/2011 12:52, Martin Elshuber a écrit :
Hallo,
Hi Martin,
as this discussion could be of interest to other people I continue it
here.
On 04/12/2011 07:58 PM, Philippe Gerum wrote:
On Tue, 2011-04-12 at 17:01 +0200, Martin Elshuber wrote:
Hallo Mr. Gerum!
First, thx for the answer
Actually i have been running with CONFIG_XENO_HW_UNLOCKED_SWITCH the
whole time and i also raised the stack size from 4k to 8k. I do however
think there could be some fishyness in entry_32.S. In
transfer_to_handler SPRN_SPRG3 is used to check for stack overflow (at
least in my kernel 2.6.29.6),
On Thu, 2011-04-14 at 15:46 +0200, Jesper Christensen wrote:
Actually i have been running with CONFIG_XENO_HW_UNLOCKED_SWITCH the
whole time
You mean enabled?
and i also raised the stack size from 4k to 8k. I do however
think there could be some fishyness in entry_32.S. In
On 2011-04-14 16:09, Philippe Gerum wrote:
On Thu, 2011-04-14 at 15:46 +0200, Jesper Christensen wrote:
Actually i have been running with CONFIG_XENO_HW_UNLOCKED_SWITCH the
whole time
You mean enabled?
Disabled, sorry.
and i also raised the stack size from 4k to 8k. I do
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
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
Not only that. The aim of the test is to trigger the worst case path. I
suspect you can not trigger it with a 10 minutes tests. As you probably
remember, I was once running Xenomai on IXP465, and the latency with
Xenomai 2.4
