Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
shows a strange behavior: In Kernel mode (-t1) the latencys
constantly linear decrease. See attached plot
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
shows a strange behavior: In Kernel mode (-t1) the latencys
constantly linear
On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
On Wed, Apr 2, 2008 at 4:56 PM, Fillod Stephane
[EMAIL PROTECTED] wrote:
Hi,
Here's attached a patch working around a glibcism. It is necessary
for uClib environment. The patch is against Xenomai 2.4.3.
Already fixed in trunk, forgot to apply the patch to the v2.4.x
branch. Note that your
On Wed, Apr 2, 2008 at 5:02 PM, Tomas Kalibera [EMAIL PROTECTED] wrote:
OK, no change with this patch compared to the previous situation. The
system boots, but hangs without a stacktrace when I run my Xenomai task.
SysRq is blocked, now even SysRq-kill did not work, only SysRq-boot did.
Are
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
shows a strange behavior: In Kernel mode (-t1) the latencys
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2,
Gilles Chanteperdrix wrote:
[...]
Already fixed in trunk, forgot to apply the patch to the v2.4.x
branch. Note that your patch is slightly incorrect:
- it runs strstr in an uninitialized string;
- the result on platforms without _CS_GNU_LIBPTHREAD_VERSION is
linuxthreads == 0 whereas we
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
I talked with Sebastian Smolorz about this and he builds his own
independent kernel-config to
Hmm, I checked again and did not find a mistake in the experiment
(neither using the old binary nor old sources). I'm doing a clean build
from scratch again, so that we can be absolutely sure. I can then run
memtest on the machine...
Tomas
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
Tomas
Gilles Chanteperdrix wrote:
On Wed, Apr 2,
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
Tomas
But...
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
You aren't using gcc-4.2
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
permission denied
Tomas Kalibera wrote:
Gilles Chanteperdrix wrote:
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at
Gilles Chanteperdrix wrote:
Of course, we are looking for all bugs. But please tell me: do you get
the lock-up even before fork is called ? If not, could you verify that
at least some Xenomai programs run correctly, for instance latency ?
The lock up with patch 5 happens before fork is
17 matches
Mail list logo