Re: [Xenomai] a question about ADEOS

2012-06-04 Thread ali hagigat
Much appreciates for the replies. if you look at the following page: http://home.gna.org/adeos/doc/api/globals.html You can see some functions like adeos_alloc_irq() or adeos_alloc_ptdkey(). But if you patch the linux kernel with the adeos patch, these functions do not exist. On Wed, May 30,

[Xenomai] adeos-ipipe-3.0.13-arm-1.18-09.patch broken

2012-06-04 Thread George Pontis
This recently released patch appears to be broken with regard to patching arch/arm/mach-at91/at91sam9g45.c. The first section of the patch should be applied to around line 32 in similar fashion to the patch for the other micros in the family. However, it is being applied to an entirely different s

Re: [Xenomai] "illegal instruction", then "rt_task_start()" error -38 (on a 486/no fpu)

2012-06-04 Thread xenophile
On 06/04/12 21:28, Gilles Chanteperdrix wrote: On 06/04/2012 09:26 PM, Marc Le Douarain wrote: Hello, I've some difficulties to run Xenomai with a little 'hello' example (that create/start a task) on a target 486 processor (without fpu). I successfully compiled the Linux kernel 2.6.38.8 with a

Re: [Xenomai] "illegal instruction", then "rt_task_start()" error -38 (on a 486/no fpu)

2012-06-04 Thread Gilles Chanteperdrix
On 06/04/2012 09:26 PM, Marc Le Douarain wrote: > Hello, > > I've some difficulties to run Xenomai with a little 'hello' example > (that create/start a task) > on a target 486 processor (without fpu). > > I successfully compiled the Linux kernel 2.6.38.8 with > adeos-ipipe-2.6.38.8-x86-2.11-02.

Re: [Xenomai] "illegal instruction", then "rt_task_start()" error -38 (on a 486/no fpu)

2012-06-04 Thread Gilles Chanteperdrix
On 06/04/2012 09:26 PM, Marc Le Douarain wrote: > Hello, > > I've some difficulties to run Xenomai with a little 'hello' example > (that create/start a task) > on a target 486 processor (without fpu). > > I successfully compiled the Linux kernel 2.6.38.8 with > adeos-ipipe-2.6.38.8-x86-2.11-02.

[Xenomai] "illegal instruction", then "rt_task_start()" error -38 (on a 486/no fpu)

2012-06-04 Thread Marc Le Douarain
Hello, I've some difficulties to run Xenomai with a little 'hello' example (that create/start a task) on a target 486 processor (without fpu). I successfully compiled the Linux kernel 2.6.38.8 with adeos-ipipe-2.6.38.8-x86-2.11-02.patch (Xenomai version is 2.5.6) (modify file xenomai-2.5.6/in

Re: [Xenomai] question on host tick processing

2012-06-04 Thread Gilles Chanteperdrix
On 06/04/2012 03:30 PM, abhri wrote: > Hi, > I have a doubt regarding host tick propagation. I understand that host > tick will be relayed when XNHTICK bit is set and there is a domain > migration to root. In case there is large delay to change domain from > primary to secondary how is the host

Re: [Xenomai] hal patch for 3.2 kernel

2012-06-04 Thread Philippe Gerum
On 06/04/2012 03:39 PM, Moses McKnight wrote: Hi, I am looking at trying to port the latest x86 ipipe patch to kernel version 3.2.18, but before I get too far, has any work been done on that or a kernel newer than 2.6.38.8? If so is it about to be released? I don't want or have time to duplicate

[Xenomai] hal patch for 3.2 kernel

2012-06-04 Thread Moses McKnight
Hi, I am looking at trying to port the latest x86 ipipe patch to kernel version 3.2.18, but before I get too far, has any work been done on that or a kernel newer than 2.6.38.8? If so is it about to be released? I don't want or have time to duplicate someone else's work. Thanks, Moses ___

[Xenomai] question on host tick processing

2012-06-04 Thread abhri
Hi, I have a doubt regarding host tick propagation. I understand that host tick will be relayed when XNHTICK bit is set and there is a domain migration to root. In case there is large delay to change domain from primary to secondary how is the host tick corrected when relayed next. Is there an

Re: [Xenomai] x86_32 mayday

2012-06-04 Thread Gilles Chanteperdrix
On 06/04/2012 01:16 PM, Philippe Gerum wrote: > On 06/01/2012 08:05 PM, Gilles Chanteperdrix wrote: >> On 06/01/2012 07:28 PM, Jan Kiszka wrote: >>> On 2012-06-01 19:16, Gilles Chanteperdrix wrote: Hi, with the current tip of xenomai 2.6 branch, the "sigdebug" test testing

Re: [Xenomai] x86_32 mayday

2012-06-04 Thread Jan Kiszka
On 2012-06-04 13:16, Philippe Gerum wrote: > On 06/01/2012 08:05 PM, Gilles Chanteperdrix wrote: >> On 06/01/2012 07:28 PM, Jan Kiszka wrote: >>> On 2012-06-01 19:16, Gilles Chanteperdrix wrote: Hi, with the current tip of xenomai 2.6 branch, the "sigdebug" test testing the

Re: [Xenomai] x86_32 mayday

2012-06-04 Thread Philippe Gerum
On 06/01/2012 08:05 PM, Gilles Chanteperdrix wrote: On 06/01/2012 07:28 PM, Jan Kiszka wrote: On 2012-06-01 19:16, Gilles Chanteperdrix wrote: Hi, with the current tip of xenomai 2.6 branch, the "sigdebug" test testing the "mayday" code ends up with a segfault on x86_32. I tried to have a loo

Re: [Xenomai] TCP communication problem

2012-06-04 Thread Philippe Gerum
On 06/04/2012 12:03 PM, Gilles Chanteperdrix wrote: On 06/04/2012 11:53 AM, Philippe Gerum wrote: On 06/04/2012 11:33 AM, Frederik Bayart wrote: Dietmar, thanks for hint. Indeed, I noticed that the number of bytes sent != bytes to send. If I wrap the send in a while lus, the problem is solved.

Re: [Xenomai] TCP communication problem

2012-06-04 Thread Gilles Chanteperdrix
On 06/04/2012 11:53 AM, Philippe Gerum wrote: > On 06/04/2012 11:33 AM, Frederik Bayart wrote: >> Dietmar, thanks for hint. Indeed, I noticed that the number of bytes >> sent != bytes to send. >> If I wrap the send in a while lus, the problem is solved. >> >> Does anyone have a suggestion how to de

Re: [Xenomai] TCP communication problem

2012-06-04 Thread Philippe Gerum
On 06/04/2012 11:33 AM, Frederik Bayart wrote: Dietmar, thanks for hint. Indeed, I noticed that the number of bytes sent != bytes to send. If I wrap the send in a while lus, the problem is solved. Does anyone have a suggestion how to detect the interrupting signal (SIG_ALL doesn't exist) Use

Re: [Xenomai] TCP communication problem

2012-06-04 Thread Frederik Bayart
Dietmar, thanks for hint. Indeed, I noticed that the number of bytes sent != bytes to send. If I wrap the send in a while lus, the problem is solved. Does anyone have a suggestion how to detect the interrupting signal (SIG_ALL doesn't exist) Frederik On 31 May 2012 11:54, wrote: > Hallo, > > F