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
'drifting_latencys_in_k
On Tue, Apr 1, 2008 at 11:23 PM, Tomas Kalibera <[EMAIL PROTECTED]> wrote:
> OK, I got rid of old patches and applied only this check (attached). Now,
> the kernel boots. When I run my Xenomai app, the kernel locks up, without
> writing anything to console.
>
> I tried to get some info via SysRq k
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 atta
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
>>> consta
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
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
Hi,
Here's attached a patch working around a glibcism. It is necessary
for uClib environment. The patch is against Xenomai 2.4.3.
Cheers
--
Stephane
posix-skin-glibcism.patch
Description: posix-skin-glibcism.patch
___
Xenomai-core mailing list
Xenom
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 y
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.
Sebastian Smolorz wrote:
> 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,
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 (-t
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. Run
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 r
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
>>
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.
>
> Tom
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 gc
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.
permissio
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 http://www.cs.purdue.edu/~tkaliber/crash, the
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 http://www.cs.purdue.edu/~tkaliber/crash, the
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:
> 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
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 c
24 matches
Mail list logo
