Re: [Xenomai-core] [BUG] scheduling order of dying shadow threads

2005-11-08 Thread Sebastian Smolorz
On Tue, 8 Nov 2005, Philippe Gerum wrote: > Jan Kiszka wrote: > > Hi Philippe, > > > > I think this one is for you: ;) > > > > Sebastian got almost mad with his CAN driver while tracing a strange > > scheduling behaviour during shadow thread deletion for several days(!) - > > and I was right on th

[Xenomai-core] Ambiguity in description about rt_task_delete()

2005-11-09 Thread Sebastian Smolorz
Hi, I just stumbled across an ambiguity in the documentation for rt_task_delete() in the native skin. One could think that this function can only be called from userspace if it is a RT task because of "This service can be called from: ... User-space task (switches to primary mode)" But this is o

[Xenomai-core] RT pipes

2005-11-09 Thread Sebastian Smolorz
Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-

Re: [Xenomai-core] RT pipes

2005-11-09 Thread Sebastian Smolorz
On Wed, 9 Nov 2005, Philippe Gerum wrote: > Philippe Gerum wrote: > > Sebastian Smolorz wrote: > > > >> Hi, > >> > >> I've spotted a -- in my view -- strange behaviour of RT pipes in the > >> native skin. The scenario is as follows: > >

[Xenomai-core] Patch for RTDM recvmsg bug

2005-11-10 Thread Sebastian Smolorz
Hi, here's a patch for a bug in skins/rtdm/syscall.c. The msghdr was not copied to user space upon completion of a recvmsg() call if the return value was not equal to zero. But recvmsg shall return the length of the message in bytes (according to IEEE Std 1003.1). I have the permission from Jan t

[Xenomai-core] Announce: RTDM CAN Device Profile and Driver

2005-11-17 Thread Sebastian Smolorz
Hello list, as a result of a student research project of mine (kind of bachelor thesis), here is a CAN device profile for RTDM including a driver for the SJA1000-based eNET PHYTEC card. See RT-Add-On-Repository at the University of Hannover: http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddo

Re: [Xenomai-core] [pipe.c] hairy synchronization -> "flush the output queue upon closure"

2005-11-18 Thread Sebastian Smolorz
> Hi, > > I failed to find the original message from Sebastian that led to the > following change: > > - > 2005-11-09 Philippe Gerum <[EMAIL PROTECTED]> > > * nucleus/pipe.c (xnpipe_disconnect): Flush the output queue > upon closure

[Xenomai-core] [PATCH] Small doc fix for rtbenchmark.h

2006-03-08 Thread Sebastian Smolorz
Hi Jan, here is a fix for the following doxygen warning: xenomai/include/rtdm/rtbenchmark.h:146: Warning: end of file while inside a group Sebastian --- xenomai/include/rtdm/rtbenchmark.h 2006-03-09 01:13:40.0 +0100 +++ rtbenchmark.h 2006-03-09 01:13:24.0 +0100 @@ -138,6 +138,7

Re: [Xenomai-core] [BUG] scheduling order of dying shadow threads

2005-11-08 Thread Sebastian Smolorz
On Tue, 8 Nov 2005, Philippe Gerum wrote: > Jan Kiszka wrote: > > Hi Philippe, > > > > I think this one is for you: ;) > > > > Sebastian got almost mad with his CAN driver while tracing a strange > > scheduling behaviour during shadow thread deletion for several days(!) - > > and I was right on th

[Xenomai-core] Ambiguity in description about rt_task_delete()

2005-11-09 Thread Sebastian Smolorz
Hi, I just stumbled across an ambiguity in the documentation for rt_task_delete() in the native skin. One could think that this function can only be called from userspace if it is a RT task because of "This service can be called from: ... User-space task (switches to primary mode)" But this is o

[Xenomai-core] RT pipes

2005-11-09 Thread Sebastian Smolorz
Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-

Re: [Xenomai-core] RT pipes

2005-11-09 Thread Sebastian Smolorz
On Wed, 9 Nov 2005, Philippe Gerum wrote: > Philippe Gerum wrote: > > Sebastian Smolorz wrote: > > > >> Hi, > >> > >> I've spotted a -- in my view -- strange behaviour of RT pipes in the > >> native skin. The scenario is as follows: > >

[Xenomai-core] Patch for RTDM recvmsg bug

2005-11-10 Thread Sebastian Smolorz
Hi, here's a patch for a bug in skins/rtdm/syscall.c. The msghdr was not copied to user space upon completion of a recvmsg() call if the return value was not equal to zero. But recvmsg shall return the length of the message in bytes (according to IEEE Std 1003.1). I have the permission from Jan t

[Xenomai-core] Announce: RTDM CAN Device Profile and Driver

2005-11-17 Thread Sebastian Smolorz
Hello list, as a result of a student research project of mine (kind of bachelor thesis), here is a CAN device profile for RTDM including a driver for the SJA1000-based eNET PHYTEC card. See RT-Add-On-Repository at the University of Hannover: http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddo

Re: [Xenomai-core] [pipe.c] hairy synchronization -> "flush the output queue upon closure"

2005-11-18 Thread Sebastian Smolorz
> Hi, > > I failed to find the original message from Sebastian that led to the > following change: > > - > 2005-11-09 Philippe Gerum <[EMAIL PROTECTED]> > > * nucleus/pipe.c (xnpipe_disconnect): Flush the output queue > upon closure

[Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded

2005-10-12 Thread Sebastian Smolorz
Hi, today I discovered a bug after having tried to load the Xenomai RTDM skin. I've attached a patch which should correct the problem. Sebastian--- xenomai/skins/rtdm/proc.c 2005-10-12 16:58:48.0 +0200 +++ proc.c 2005-10-12 17:00:59.0 +0200 @@ -285,7 +285,7 @@ int __init rt

Re: [Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded

2005-10-12 Thread Sebastian Smolorz
On Wed, 12 Oct 2005, Philippe Gerum wrote: > Sebastian Smolorz wrote: > > Hi, > > > > today I discovered a bug after having tried to load the Xenomai RTDM skin. > > I've attached a patch which should correct the problem. ... and if we want to have a clean rem

[Xenomai-core] Strange behaviour of RTDM CAN driver

2006-05-16 Thread Sebastian Smolorz
Hello all, the following is a really nasty problem I am trying to solve for months now. I really hope that someone on the list knows the solution. As you may remember some months ago I announced a RTDM CAN driver for SJA1000 based cards (see https://mail.gna.org/public/xenomai-core/2005-11/msg

Re: [Xenomai-core] Strange behaviour of RTDM CAN driver

2006-05-16 Thread Sebastian Smolorz
Hello Ulrich! On Tue, 16 May 2006 [EMAIL PROTECTED] wrote: > I don't know your hardware, but i think it's a not a hardware problem. > Your desctription sounds more than a compiler optimization problem. > > Ok, this is your READ_REG definition, > > /** Read access to a register of the SJA1000 CAN

Re: [Xenomai-core] Strange behaviour of RTDM CAN driver

2006-05-16 Thread Sebastian Smolorz
Hello Philippe, on Tue, 16 May 2006, Philippe Gerum wrote: > It would be interesting to know how Adeos is asked to deal with such > interrupt upon receipt, e.g. does it relay it to Linux? In the init_module routine the driver calls rtdm_irq_request() with flags RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_

Re: [Xenomai-core] Strange behaviour of RTDM CAN driver

2006-05-24 Thread Sebastian Smolorz
> On Tue, 16 May 2006 [EMAIL PROTECTED] wrote: > > I don't know your hardware, but i think it's a not a hardware problem. > > Your desctription sounds more than a compiler optimization problem. > > > > Ok, this is your READ_REG definition, > > > > /** Read access to a register of the SJA1000 CAN c

Re: [Xenomai-core] Strange behaviour of RTDM CAN driver

2006-05-24 Thread Sebastian Smolorz
Hello Philippe, I've got the results from Roland now. > > Interestingly, the driver does not show the above behaviour with all > > interrupt numbers. E.g. with interrupt number 12 the driver gets no > > interrupt at all. Now IRQ 12 works ... > > Some technical details: > > - Linux Kernel 2.6.1

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Sebastian Smolorz
Jan Kiszka wrote: > the current representation of timeouts and timestamps in RTDM device > profiles is inconsistent. I would welcome a consistent time value representation above all RTDM profiles, too. > In the serial profile we use [u]int64_t > directly, the CAN profile defines its own types c

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > The possibility of redefinition was not the main goal here. As you > > mentioned it would be problematic. No, I introduced nanosecs_abs_t and > > nanosecs_rel_t because they are more intuitive and more "speaking" to

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > Jan Kiszka wrote: > >> Sebastian Smolorz wrote: > >>> The possibility of redefinition was not the main goal here. As you > >>> mentioned it would be problematic. No, I introduced nanosecs_abs_t and

[Xenomai-core] I-pipe patch for ARM S3C24xx

2006-10-20 Thread Sebastian Smolorz
.c 2006-10-18 15:17:25.0 +0200 @@ -3,6 +3,8 @@ * Copyright (c) 2003,2004 Simtec Electronics * Ben Dooks <[EMAIL PROTECTED]> * + * Copyright (C) 2006 Sebastian Smolorz <[EMAIL PROTECTED]>, emlix GmbH + * * This program is free software; you can redistribute it and/or modify

Re: [Xenomai-core] I-pipe patch for ARM S3C24xx

2006-10-24 Thread Sebastian Smolorz
> Hi all, > > I'm currently working on porting I-pipe to the ARM S3C24xx. The patch is > attached, it must be applied after the shipped > adeos-ipipe-2.6.15-arm-1.5-01.patch. Unfortunately, there is still a severe > bug somewhere. I built Xenomai as modules. When I try to modprobe > xeno_native, th

[Xenomai-core] [PATCH] Missing ; in include/asm-arm/calibration.h

2006-10-25 Thread Sebastian Smolorz
Hi, on my quest to find the bug in the I-pipe patch for the S3C24xx (got the root of the problem now, information will soon follow) I detected a missing semicolon in xenomai/include/asm-arm/calibration.h. See attachment. Sebastian Index: xenomai-svn/include/asm-arm/calibration.h ===

Re: [Xenomai-core] I-pipe patch for ARM S3C24xx

2006-10-27 Thread Sebastian Smolorz
-3,6 +3,8 @@ * Copyright (c) 2003,2004 Simtec Electronics * Ben Dooks <[EMAIL PROTECTED]> * + * Copyright (C) 2006 Sebastian Smolorz <[EMAIL PROTECTED]>, emlix GmbH + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public L

Re: [Xenomai-core] I-pipe patch for ARM S3C24xx

2006-10-30 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: > > Sebastian Smolorz wrote: > >> Hi, > >> > >> here comes version 2 of the I-pipe patch for the S3C24xx ARM. The > >> reported problem is solved, the timer works as expected as far as I > &g

[Xenomai-core] I-pipe patch for ARM S3C24xx (v4)

2006-11-09 Thread Sebastian Smolorz
Hi all, now that the teething problems of my I-pipe port to the S3C24xx are cured (hopefully ...) I'm going to iterate it to v4. We've established a project homepage for that port http://opensource.emlix.com/ipipe-s3c24xx/ in order to concentrate the source code and information at one point. Pro

Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)

2006-11-09 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > However, there is one disturbing issue. When I execute > > > > dd if=/dev/zero of=/dev/null > > > > and the latency test in userspace with a period not less than 150 us the > > worst case latency is about 220 u

Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)

2006-11-10 Thread Sebastian Smolorz
Am Freitag, 10. November 2006 11:14 schrieb Gilles Chanteperdrix: > Sebastian Smolorz wrote: > > Hi all, > > > > now that the teething problems of my I-pipe port to the S3C24xx are cured > > (hopefully ...) I'm going to iterate it to v4. We've established

[Xenomai-core] [PATCH] Missing include when compiling an ipiped Linux kernel with CONFIG_PREEMPT for ARM

2006-11-10 Thread Sebastian Smolorz
Hi, here comes a fix for I-pipe for ARM. Without it the kernel refuses to compile when configured with CONFIG_PREEMPT. Sebastian --- linux-2.6.15-ipipe.orig/include/asm-arm/ipipe.h 2006-11-08 16:44:02.0 +0100 +++ linux-2.6.15-ipipe.work/include/asm-arm/ipipe.h 2006-11-10 12:12:44.000

[Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

2006-11-13 Thread Sebastian Smolorz
Hi, here's a proposal for a minor change in the I-pipe implementation for ARM. Since it is required for my S3C24xx patch not to call __ipipe_mach_set_dec directly when the timer is released by the Xenomai domain I suggest the following changes. The patch comprises the necessary modifications fo

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

2006-11-15 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > Sebastian Smolorz wrote: > > Hi, > > > > here's a proposal for a minor change in the I-pipe implementation for > > ARM. Since it is required for my S3C24xx patch not to call > > __ipipe_mach_set_dec directly when the timer i

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

2006-11-15 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > Sebastian Smolorz wrote: > > Gilles Chanteperdrix wrote: > >>Sebastian Smolorz wrote: > >>>Hi, > >>> > >>>here's a proposal for a minor change in the I-pipe implementation for > >>>ARM. Since it

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

2006-11-15 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > Sebastian Smolorz wrote: > > Gilles Chanteperdrix wrote: > >>You can avoid this problem by adding LATCH or > >>__ipipe_mach_ticks_per_jiffy to the current value of the match register > >>in the timer interrupt, as it is d

[Xenomai-core] Typo in latest svn revision

2006-11-16 Thread Sebastian Smolorz
Hello Philippe, there was a typo in your latest check-in. -- Sebastian Index: ksrc/nucleus/heap.c === --- ksrc/nucleus/heap.c (Revision 1840) +++ ksrc/nucleus/heap.c (Arbeitskopie) @@ -1138,7 +1138,7 @@ int xnheap_destroy_mapped(xnhe

[Xenomai-core] Re: [Adeos-main] Latency trace on ARM

2006-12-18 Thread Sebastian Smolorz
.S --- linux-2.6.15-ipipe.orig/arch/arm/kernel/ipipe-mcount.S 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.15-ipipe/arch/arm/kernel/ipipe-mcount.S 2006-12-04 09:46:30.0 +0100 @@ -0,0 +1,40 @@ +/* + * linux/arch/arm/kernel/ipipe-mcount.S + * + * Copyright (C) 2006 Sebastian Smolor

Re: [Xenomai-core] Re: [Adeos-main] Latency trace on ARM

2006-12-18 Thread Sebastian Smolorz
Philippe Gerum wrote: > On Mon, 2006-12-18 at 17:04 +0100, Sebastian Smolorz wrote: > > Jan Kiszka wrote: > > > If you have anything more pending, please post soon, Gilles is > > > collecting the ARM stuff for Xenomai 2.3. > > > > Attached are all patches t

[Xenomai-core] Re: adeos-ipipe-2.6.15-arm-1.5-03.patch

2006-12-22 Thread Sebastian Smolorz
Philippe Gerum wrote: > On Fri, 2006-12-22 at 11:58 +0100, Sebastian Smolorz wrote: > > Hi Philippe and Gilles, > > > > the updated I-pipe patch for ARM which was checked-in yesterday is not > > complete. Some files are missing e.g. entry-header.S or > > mach-inte

Re: [Xenomai-core] Support for 2.6.19

2007-01-04 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > Detlef Vollmann wrote: > > Hello, > > > > the x86 branch supports kernel 2.6.19, but the ARM branch only supports > > 2.6.15. Is there a specific reason for this? > > Does anybody have a feeling what would be needed to be changed > > for 2.6.19 support? > > I guess th

Re: [Xenomai-core] Re: RT-CAN tx_sem

2007-02-15 Thread Sebastian Smolorz
Jan Kiszka wrote: > I don't think that the sem state > should be used for encoding the CAN device state towards potential senders. Why not? -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: iovec overwriting by CAN stack

2007-03-30 Thread Sebastian Smolorz
Jan Kiszka wrote: > Wolfgang Grandegger wrote: > > Jan Kiszka wrote: > >> Hi Wolfgang, > >> > >> it's late, so I may have misread somecode, but don't you "update" the > >> iovec descriptors a user passes on send/recvmsg on return (namely > >> iovec_len)? I received some complaints about this /wrt t

[Xenomai-core] Re: iovec overwriting by CAN stack

2007-03-30 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > Jan Kiszka wrote: > >> Wolfgang Grandegger wrote: > >>> Jan Kiszka wrote: > >>>> Hi Wolfgang, > >>>> > >>>> it's late, so I may have misread somecode, but don

[Xenomai-core] Xenomai website problem?

2007-04-02 Thread Sebastian Smolorz
Hi, is there a problem with the Xenomai website or did I try to access it in the middle of an update cycle of mediawiki? -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: iovec overwriting by CAN stack

2007-04-02 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > Jan Kiszka wrote: > >> Sebastian Smolorz wrote: > >>> Jan Kiszka wrote: > >>>> Wolfgang Grandegger wrote: > >>>>> Jan Kiszka wrote: > >>>>>> Hi Wolfgang

Re: [Xenomai-core] iovec overwriting by CAN stack

2007-04-10 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > Jan Kiszka wrote: > >> > >> So, unless we find some reason why we _must_ modify user's iovec, either > >> for send or receive, I would say: kill the user copy-back and work in > >> both case (kern

[Xenomai-core] Wrong example code in Native-API-Tour

2007-04-10 Thread Sebastian Smolorz
Hello Philippe, on page 21 of Native-API-Tour-rev-C.pdf one gets the impression that rt_intr_wait() returns 0 on success. However, it returns a positive value in this case (as the API description states it right). -- Sebastian ___ Xenomai-core maili

Re: [Xenomai-core] Xenomai @ Hannover Messe 2007

2007-04-17 Thread Sebastian Smolorz
Hi, Stéphane ANCELOT wrote: > Hi, > I will go there on Friday, it would be glad if we could meet us. > > Talking about our works with xenomai and our work about possible > integration of xenomai with realtime industrial ethernet > (ethercat/powerlink/profinet...) > > I would be interested in meeti

[Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters

2007-07-20 Thread Sebastian Smolorz
Pop * + * Copyright (C) 2007 Sebastian Smolorz <[EMAIL PROTECTED]> + * Support for TSC emulation in user space for decrementing counters + * * Xenomai is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published * by th

Re: [Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters

2007-07-20 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > On 7/20/07, Sebastian Smolorz <[EMAIL PROTECTED]> wrote: > > Hi, > > > > here comes my patch for user space tsc emulation for decrementing > > counters. I had to extend the __xn_tscinfo structure because the counter > > valu

Re: [Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters

2007-07-20 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > On 7/20/07, Sebastian Smolorz <[EMAIL PROTECTED]> wrote: > > Hi, > > > > here comes my patch for user space tsc emulation for decrementing > > counters. I had to extend the __xn_tscinfo structure because the counter > > valu

Re: [Xenomai-core] [RFC] Fast Context Switch Extension for ARM Linux

2007-09-26 Thread Sebastian Smolorz
whichever is preferred. Regards, Sebastian -- Dipl.-Ing. Sebastian Smolorz, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055 Sitz der Gesellschaft: Göttingen, Amts

Re: [Xenomai-core] [RFC] Fast Context Switch Extension for ARM Linux

2007-09-28 Thread Sebastian Smolorz
Richard Cochran wrote: > > -Original Message- From: Sebastian Smolorz > > Sent: Wednesday, September 26, 2007 11:28 AM > > > > We consider to set up a git repository so that you and all > > interested people will be able to clone from it. If anyone feels >

Re: [Xenomai-core] Cross compiling for ARM

2007-10-13 Thread Sebastian Smolorz
Hi Jan, Jan Kiszka wrote: > in order to build Xenomai's userland with a toolchain that is prefixed > with "armv5l-linux-", I had to patch configure.in like this > > Index: configure.in > === > --- configure.in (Revision 3050) > +

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-02 Thread Sebastian Smolorz
space first, no drift appeared over time. If latency was run in kernel space (with the reported ngeative drift) a following latency test in user space showed also negative values but with no additional drift over time. >> I talked with Sebastian Smolorz about this and he builds his own

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-02 Thread Sebastian Smolorz
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 >> >

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-02 Thread Sebastian Smolorz
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

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-02 Thread Sebastian Smolorz
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 r

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-02 Thread Sebastian Smolorz
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: >> >>&

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-03 Thread Sebastian Smolorz
Jan Kiszka wrote: Sebastian Smolorz wrote: 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 talk

Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

2008-04-04 Thread Sebastian Smolorz
Jan Kiszka wrote: > Sebastian Smolorz wrote: >> Jan Kiszka wrote: >>> This patch may do the trick: it uses the inverted tsc-to-ns function >>> instead of the frequency-based one. Be warned, it is totally untested >>> inside Xenomai, I just ran it in a user

[Xenomai-core] Xenomai at Hannover Messe 2008

2008-04-17 Thread Sebastian Smolorz
25, E02. If you are interested in Xenomai and autonomous service robots don't hesitate to drop by our booth. -- Dipl.-Ing. Sebastian Smolorz Institute for Systems Engineering, Real-Time Systems Group (RTS) Appelstraße 9A, D-30167 Hannover phone +49 511 762-3974 / fax +49 511 762-4012

[Xenomai-core] revision 3882 breaks compilation of xenomai

2008-05-26 Thread Sebastian Smolorz
Hello Gilles, with your last commit: Fix compilation with ucLibc I cannot build xenomai userland any more (at least when taking glibc). cyclictest fails with the following error: ../../skins/posix/.libs/libpthread_rt.so: undefined reference to `likely' ../../skins/posix/.libs/libpthread_rt.so:

Re: [Xenomai-core] revision 3882 breaks compilation of xenomai

2008-05-26 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > On Mon, May 26, 2008 at 5:44 PM, Sebastian Smolorz > <[EMAIL PROTECTED]> wrote: >> Hello Gilles, >> >> with your last commit: >> Fix compilation with ucLibc >> >> I cannot build xenomai userland any more (at least

[Xenomai-core] [PATCH] rt_pipe_receive documentation

2008-05-27 Thread Sebastian Smolorz
kopie) @@ -1,3 +1,9 @@ +2008-05-27 Sebastian Smolorz <[EMAIL PROTECTED]> + + * ksrc/skins/native/pipe.c (rt_pipe_receive): Fix documentation + for the return values of the function. -EIDRM is no valid return + value any more. + 2008-05-25 Wolfgang Grandegger <[E

[Xenomai-core] CAN filter issues

2008-10-27 Thread Sebastian Smolorz
Hi Wolfgang, we currently face an issue regarding the filtering of CAN messages since Xenomai 2.4. It was introduced in rev. 2202 (I know it is long ago but the problem popped up last week). The line in question is http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtcan_raw_fil

Re: [Xenomai-core] [PATCH] RT-Socket-CAN: correct bug with filter registration

2008-10-29 Thread Sebastian Smolorz
Wolfgang Grandegger wrote: > Hi Jan and Sebastian, > > attached is the patch fixing the filter problem. I'm going to apply it > to the trunk as well if there are no complaints. No complaints from my side. > > Wolfgang. > > Index: ChangeLog >

[Xenomai-core] [PATCH] Correct error handling in rtcan_ixxat_pci.c if card has wrong sub_sys_id

2009-03-10 Thread Sebastian Smolorz
Hi, the subject says it all. The patch is only compile-tested. -- Sebastian Index: ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c === --- ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c (Revision 4679) +++ ksrc/drivers/can/sja1000/rtcan_ixx

[Xenomai-core] [BUG] [xenomai-head] xeno_posix.ko cannot be built

2009-06-22 Thread Sebastian Smolorz
Hi Philippe, with latest head it is not possible to build the POSIX skin as module. It gives: ERROR: "xnarch_divrem_billion" [kernel/xenomai/skins/posix/xeno_posix.ko] undefined! Obviously an EXPORT_SYMBOL(xnarch_divrem_billion); is missing. -- Sebastian _

Re: [Xenomai-core] [BUG] [xenomai-head] xeno_posix.ko cannot be built

2009-06-22 Thread Sebastian Smolorz
Gilles Chanteperdrix wrote: > Sebastian Smolorz wrote: > > Hi Philippe, > > > > with latest head it is not possible to build the POSIX skin as module. > > It gives: > > > > ERROR: "xnarch_divrem_billion" > > [kernel/xenomai/ski

[Xenomai-core] [PATCH] rtcan: Add support for CAN PCI cards from ESD

2009-09-08 Thread Sebastian Smolorz
Matthias Fuchs. Signed-off-by: Sebastian Smolorz -- ksrc/drivers/can/sja1000/Kconfig | 11 + ksrc/drivers/can/sja1000/Makefile|7 + ksrc/drivers/can/sja1000/rtcan_esd_pci.c | 354 ++ 3 files changed, 372 insertions(+), 0 deletions(-) diff --git

[Xenomai-core] [PATCH] can: Free I/O region when unloading the xeno_can_isa.ko driver

2009-11-23 Thread Sebastian Smolorz
can: Free I/O region when unloading the xeno_can_isa.ko driver Signed-off-by: Sebastian Smolorz diff --git a/ksrc/drivers/can/sja1000/rtcan_isa.c b/ksrc/drivers/can/sja1000/rtcan_isa.c index 6debb16..ec32393 100644 --- a/ksrc/drivers/can/sja1000/rtcan_isa.c +++ b/ksrc/drivers/can/sja1000

Re: [Xenomai-core] [PATCH] rtcan: add rtcan_plx_pci driver

2010-05-18 Thread Sebastian Smolorz
Pavel Cheblakov wrote: > This is a general driver for cards based on PLX90xx PCI-bridges. > It supports following cards: > - Adlink PCI-7841/cPCI-7841 card (http://www.adlinktech.com/) > - Adlink PCI-7841/cPCI-7841 SE card > - esd CAN-PCI/CPCI/PCI104/200 (http://www.esd.eu/) > - esd CAN-PCI/PMC

Re: [Xenomai-core] [PATCH] rtcan: add rtcan_plx_pci driver

2010-05-18 Thread Sebastian Smolorz
Hi Wolfgang, Wolfgang Grandegger wrote: > On 05/18/2010 01:42 PM, Sebastian Smolorz wrote: > > Pavel Cheblakov wrote: > >> This is a general driver for cards based on PLX90xx PCI-bridges. > >> It supports following cards: > >> - Adlink PCI-7841/cPCI-

Re: [Xenomai-core] [PATCH] rtcan: add rtcan_plx_pci driver

2010-05-18 Thread Sebastian Smolorz
Wolfgang Grandegger wrote: > On 05/18/2010 02:29 PM, Sebastian Smolorz wrote: > > Hi Wolfgang, > > > > Wolfgang Grandegger wrote: > >> On 05/18/2010 01:42 PM, Sebastian Smolorz wrote: > >>> Pavel Cheblakov wrote: > >>>> This is a general

[Xenomai-core] Bug in Linux kernel 2.6.37 blocks xenomai threads

2011-04-04 Thread Sebastian Smolorz
Hi, there is a bug in kernel 2.6.37 (fixed in 2.6.37.1, see commit 1cdc65e1400d863f28af868ee1e645485b04f5ed) which blocks RT threads during creation. They stick to a certain CPU core for a certain amount of time (sometimes minutes ...) before they are migrated to the proper core and run as exp