Re: [Xenomai-core] [RFC][patch] per-process data.

2006-05-09 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > > Gilles Chanteperdrix wrote: > > > These patches are not ready for inclusion, they are not tested > > > yet. > > > > The attached versions are tested. I still wonder if handling this in > > shadow.c is t

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

2006-05-09 Thread Philippe Gerum
Jan Kiszka wrote: BTW, this reminds me the ask for a merging plan of the kgdb support for ipipe - this bug was tracked down via kgdb... It's queued with some changes planned (specifically removing any Xenomai-specifics from the patch). -- Philippe. ___

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

2006-05-09 Thread Jan Kiszka
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > BTW, this reminds me the ask for a merging plan of the kgdb support for > > ipipe - this bug was tracked down via kgdb... > > There are some issues with the kgdb patch: > - it does not work if the nucleus is compiled as a module, because it >

Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

2006-05-09 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > BTW, this reminds me the ask for a merging plan of the kgdb support for > ipipe - this bug was tracked down via kgdb... There are some issues with the kgdb patch: - it does not work if the nucleus is compiled as a module, because it uses xnpod_current_thread() - it does not

[Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

2006-05-09 Thread Jan Kiszka
Hi, originally, I was hunting some mutex issue (still on it, report will follow soon). But due to a typo I revealed some nasty clean-up issue of current trunk (2.1.x seems to contain the same code). Try to create two tasks like this: rt_task_spawn(&task1, "task1", 0, 20, 0, task1_fnc, 0);

Re: [Xenomai-core] [RFC][patch] per-process data.

2006-05-09 Thread Gilles Chanteperdrix
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > > Gilles Chanteperdrix wrote: > > > These patches are not ready for inclusion, they are not tested > > > yet. > > > > The attached versions are tested. I still wonder if handling this in > > shadow.c is the right solution, or if there

Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)

2006-05-09 Thread Philippe Gerum
ROSSIER Daniel wrote: Hi Philippe, Any chance to see our work integrated within an official distribution? Are you still reviewing the code? It's reviewed and mostly ok, except the "poll mode" boot parameter which is not there (i.e. adding a static compilation option is not the way to go).

RE: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)

2006-05-09 Thread ROSSIER Daniel
Hi Philippe, Any chance to see our work integrated within an official distribution? Are you still reviewing the code? Thanks for your feedback Daniel > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De > la part de ROSSIER Daniel > Envoyé : mardi, 25. avril 200

[Xenomai-core] Xenomai v2.1.1

2006-05-09 Thread Philippe Gerum
This is the first maintenance release of the v2.1.x branch [1]. The short log follows: [blackfin] Major kernel update to uClinux 2.6.16. Port over the BF537 board [2] sponsored by Analog Devices. [i386] Fix FPU context restore after a domain migration. [nucleus] Optimize feature selection for

[Xenomai-core] Xenomai v2.2-rc1

2006-05-09 Thread Philippe Gerum
Here is the first candidate release [1] of the 2.2 series. Updates, fixes and hopefully improvements have taken place all over the map. Added features mainly concern the VxWorks skin and the Adeos support (2.4/2.6, all architectures). Direct invocation of the VxWorks emulation services running i