On 09/18/2011 04:43 PM, Bertold Van den Bergh wrote:
> Hello,
>
> Thanks for the reply. The timer register has the following layout: bit
> 0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking
> at the code this cannot work so I added an extra field to indicate the
> shift after ap
On 09/18/2011 05:24 PM, Jan Kiszka wrote:
> On 2011-09-18 17:18, Gilles Chanteperdrix wrote:
>> What about:
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index 21cc191..7fe44a1 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/
On 09/18/2011 05:13 PM, Jan Kiszka wrote:
> On 2011-09-18 17:11, Jan Kiszka wrote:
>> On 2011-09-18 17:10, Philippe Gerum wrote:
>>> On Sun, 2011-09-18 at 16:34 +0200, Jan Kiszka wrote:
>>>> On 2011-09-18 16:02, Philippe Gerum wrote:
>>>>> On Fri, 20
On 09/18/2011 04:43 PM, Bertold Van den Bergh wrote:
> Hello,
>
> Thanks for the reply. The timer register has the following layout: bit
> 0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking
> at the code this cannot work so I added an extra field to indicate the
> shift after ap
On 09/17/2011 05:15 PM, Bertold Van den Bergh wrote:
> Hello,
>
> I am trying to port Xenomai to the freescale stmp3xxx cpu (I.MX233).
>
> I added TSC code from plat-s3c24xx as this processor also uses a 16
> bit downcounter based timer. I run the system tick counter and the TSC
> freerunning cou
On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
> On 09/11/2011 04:29 PM, Jan Kiszka wrote:
>> On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
>>> On 09/11/2011 12:50 PM, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> just looked into the hresc
On 09/11/2011 04:29 PM, Jan Kiszka wrote:
> On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
>> On 09/11/2011 12:50 PM, Jan Kiszka wrote:
>>> Hi all,
>>>
>>> just looked into the hrescnt issue again, specifically the corner case
>>> of a shadow thread s
On 09/12/2011 11:08 AM, Gilles Chanteperdrix wrote:
> On 09/12/2011 10:27 AM, varname wrote:
>> Trying to use pkg-config with 2.6.0-rc2 results in the following error
>> message:
>>
>>Variable 'pc_sysrootdir' not defined in
>>
On 09/12/2011 10:27 AM, varname wrote:
> Trying to use pkg-config with 2.6.0-rc2 results in the following error
> message:
>
>Variable 'pc_sysrootdir' not defined in
> '/home/test/usr/xenomai-2.6.0-rc2/lib/pkgconfig/libxenomai_posix.pc'
>
> Same behaviour in rc1.
>
> Removing ${pc_sysrootd
Hi,
here comes xenomai v2.6.0-rc2:
http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc2.tar.bz2
New since -rc1 are:
- the latest upgrades of analogy, including support for NI 660x and NI 670x
- build and run-time fixes for powerpc
Known remaining issues:
- mscan driver not building on mpc5
On 09/11/2011 12:50 PM, Jan Kiszka wrote:
> Hi all,
>
> just looked into the hrescnt issue again, specifically the corner case
> of a shadow thread switching from real-time policy to SCHED_OTHER.
Doing this while holding a mutex looks invalid. If we do not do it, the
current code is valid.
--
On 09/06/2011 11:15 PM, Philippe Gerum wrote:
> On Tue, 2011-09-06 at 20:19 +0200, Gilles Chanteperdrix wrote:
>> On 09/06/2011 05:10 PM, Philippe Gerum wrote:
>>> On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote:
>>>> On Tue, 2011-09-06 at 16:53 +0200, Phil
On 09/06/2011 08:19 PM, Gilles Chanteperdrix wrote:
> On 09/06/2011 05:10 PM, Philippe Gerum wrote:
>> On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote:
>>> On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote:
>>>> On Tue, 2011-09-06 at 16:19 +0200, Gilles
On 09/06/2011 05:10 PM, Philippe Gerum wrote:
> On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote:
>> On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote:
>>> On Tue, 2011-09-06 at 16:19 +0200, Gilles Chanteperdrix wrote:
>>>> On 09/06/2011 03:27 PM, Phil
On 09/04/2011 11:43 PM, Alexis Berlemont wrote:
> The following changes since commit fa167ed2f2d9ce569968d801796f7e760772e97b:
>
> doc: regenerate (2011-09-04 21:48:41 +0200)
>
> are available in the git repository at:
> ssh+git://git.xenomai.org/xenomai-abe.git analogy
Just a small remark:
On 09/06/2011 03:27 PM, Philippe Gerum wrote:
> On Tue, 2011-09-06 at 13:31 +0200, Gilles Chanteperdrix wrote:
>> On 09/04/2011 10:52 PM, Gilles Chanteperdrix wrote:
>>>
>>> Hi,
>>>
>>> The first release candidate for the 2.6.0 version may be dow
On 09/04/2011 11:43 PM, Alexis Berlemont wrote:
> The following changes since commit fa167ed2f2d9ce569968d801796f7e760772e97b:
>
> doc: regenerate (2011-09-04 21:48:41 +0200)
>
> are available in the git repository at:
> ssh+git://git.xenomai.org/xenomai-abe.git analogy
Pulled thanks, this w
On 09/04/2011 10:52 PM, Gilles Chanteperdrix wrote:
>
> Hi,
>
> The first release candidate for the 2.6.0 version may be downloaded here:
>
> http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc1.tar.bz2
Hi,
currently 2.6.0-rc1 fails to build on 2.4 kernel, with error
On 09/05/2011 07:14 PM, Henri Roosen wrote:
> Hi Gilles,
>
> Unfortunately I didn't find the time to test this release yet. I'm
> just wondering if there is a fix for this problem in the 2.6.0
> release: https://mail.gna.org/public/xenomai-core/2011-05/msg00028.html
This one is fixed, a bit diffe
Hi,
The first release candidate for the 2.6.0 version may be downloaded here:
http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc1.tar.bz2
This version fixes a few issues in the 2.5.x branch which required
breaking the ABI:
- user-space heap mapping;
- user-space access to thread mode;
- g
On 08/31/2011 09:26 AM, Roberto Bielli wrote:
> Hi,
>
> i explain better. if i don't use rt_task_join i remove the flag
> T_JOINABLE, so i wait the task termination with a rt_task_create that
> return -EEXIST.
The only way to wait for a thread to have freed all resources (notably
its stack) is
On 08/31/2011 08:57 AM, Roberto Bielli wrote:
> Hi,
>
> if i don't want to use rt_task_join to wait termination on a task,
Then do not create the task with the T_JOINABLE flag.
> is it
> correct to use rt_task_create and wait until the return value is
> different from -EEXIST after a deletion?
On 08/31/2011 08:52 AM, Roberto Bielli wrote:
> Hi,
>
> it's ok to call rt_task_inquire after the task is deleted or the rt_task
> handle is invalid after a rt_task_delete ?
The rt_task handle is invalid after rt_task_delete, the only thing which
will work is rt_task_join if the task was created
On 08/30/2011 01:00 AM, Alexis Berlemont wrote:
> Hi,
>
> On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix
> wrote:
>>
>> Hi,
>>
>> I think it is about time we release Xenomai 2.6.0. Has anyone anything
>> pending (maybe Alex)? Should we release
On 08/26/2011 08:19 PM, Jan Kiszka wrote:
> On 2011-08-26 20:07, Gilles Chanteperdrix wrote:
>> On 08/26/2011 03:05 PM, Jan Kiszka wrote:
>>> On 2011-08-26 14:34, Gilles Chanteperdrix wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think it is abo
On 08/26/2011 03:05 PM, Jan Kiszka wrote:
> On 2011-08-26 14:34, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> I think it is about time we release Xenomai 2.6.0. Has anyone anything
>> pending (maybe Alex)? Should we release an -rc first?
>
> No patches AT
Hi,
I think it is about time we release Xenomai 2.6.0. Has anyone anything
pending (maybe Alex)? Should we release an -rc first?
Thanks in advance for your input.
--
Gilles.
___
Xenomai-core mailing list
X
Daniele Nicolodi wrote:
> On 12/08/11 10:18, Daniele Nicolodi wrote:
>> On 12/08/11 01:18, Gilles Chanteperdrix wrote:
>>> The following patch seems to do the trick. It makes the assumption that
>>> when compiling with -fomit-frame-pointer, we have one more register
Daniele Nicolodi wrote:
> On 12/08/11 01:18, Gilles Chanteperdrix wrote:
>> The following patch seems to do the trick. It makes the assumption that
>> when compiling with -fomit-frame-pointer, we have one more register, so
>> the "R" constraint will always be able
On 08/11/2011 10:52 PM, Gilles Chanteperdrix wrote:
> On 08/11/2011 07:31 PM, Gilles Chanteperdrix wrote:
>> On 08/11/2011 07:21 PM, Roland Stigge wrote:
>>> Hi,
>>>
>>> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote:
>>>> I compiled linux 2.6.
On 08/11/2011 07:31 PM, Gilles Chanteperdrix wrote:
> On 08/11/2011 07:21 PM, Roland Stigge wrote:
>> Hi,
>>
>> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote:
>>> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained
>>> kernel boots fine but
On 08/11/2011 08:42 PM, Daniele Nicolodi wrote:
> On 11/08/11 19:22, Gilles Chanteperdrix wrote:
>
>> Please try and find the point in the latency test where the hang happens
>> (it probably happens when calling a xenomai service, so, not
>> sched_setscheduler
On 08/11/2011 07:31 PM, Gilles Chanteperdrix wrote:
> On 08/11/2011 07:21 PM, Roland Stigge wrote:
>> Hi,
>>
>> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote:
>>> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained
>>> kernel boots fine but
On 08/11/2011 07:21 PM, Roland Stigge wrote:
> Hi,
>
> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote:
>> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained
>> kernel boots fine but xenomai services do not: latency hangs right after
>> the sched_setscheduler system call. With th
On 08/11/2011 04:48 PM, Daniele Nicolodi wrote:
> On 11/08/11 13:43, Daniele Nicolodi wrote:
>> I submitted the debian bug, beside what is the cause of the problem,
>> binaries compiled with gcc-4.6 are not usable, but binaries compiled
>> with gcc-4.4 are. I'm compiling xenomai-head right now (thi
On 08/11/2011 12:59 PM, Roland Stigge wrote:
> Hi,
>
> I remember the recent gcc 4.6 issue on this list, but unfortunately,
> didn't have much time for attention. Now, it found its way to the Debian
> package: http://bugs.debian.org/637425
>
> I wonder if it is a compiler bug or Xenomai's.
It lo
On 08/10/2011 09:24 PM, Gilles Chanteperdrix wrote:
>
> Hi,
>
> the mutex-torture-native test is currently broken -head. The regression
> seems to be due to commit 167ad3c5f6d322d8e2cf310e837c3f54056d7ba6
>
> It means that condvars are probably currently broken on -head
Hi,
the mutex-torture-native test is currently broken -head. The regression
seems to be due to commit 167ad3c5f6d322d8e2cf310e837c3f54056d7ba6
It means that condvars are probably currently broken on -head and it is
probably better to revert that commit for the time being.
--
On 08/09/2011 02:51 PM, Daniele Nicolodi wrote:
> Hello,
>
> I'm compiling xenomai-head on i386 debian/testing. I found that the file
> src/skins/posix/wrappers.c is missing an include of signal.h for the
> definition of pthread_kill().
Fixed, thanks.
--
On 08/01/2011 10:20 PM, Gilles Chanteperdrix wrote:
> And add the count of used bytes to the xnheap_desc structure. This allows
> for checking for leaks in unit tests.
> ---
No comments?
--
And add the count of used bytes to the xnheap_desc structure. This allows
for checking for leaks in unit tests.
---
include/asm-generic/syscall.h |2 +-
include/nucleus/heap.h|7 +++
ksrc/nucleus/shadow.c | 31 ++-
src/skins/common/sem_heap
On 08/01/2011 05:18 PM, Roberto Bielli wrote:
> Hi,
>
> i send the source files with the initialization.
> In the file apgs.c there is the main procedure that call the function
> InitRTEnv() that initialize all.
>
> Thanks a lot
>
> Best regards
>
> Il 01/08
On 08/01/2011 12:04 PM, Roberto Bielli wrote:
> Hi,
>
> i see a big problem in xenomai. Aftear a certain number of task deletion
> (rt_task_delete) and re-create task
> the RT_TASK descriptors that i have in my application don't match with
> the correct task.
Could you show us the code which in
On 07/31/2011 07:42 PM, Jan Kiszka wrote:
> On 2011-07-31 19:21, Gilles Chanteperdrix wrote:
>> On 07/31/2011 06:49 PM, GIT version control wrote:
>>> +int rt_puts(const char *s)
>>> +{
>>> + return print_to_buffer(stdout, 0, RT_PRINT_MODE_PUTS, s, NULL);
>
On 07/31/2011 06:49 PM, GIT version control wrote:
> +int rt_puts(const char *s)
> +{
> + return print_to_buffer(stdout, 0, RT_PRINT_MODE_PUTS, s, NULL);
> +}
gcc for ARM chokes here: it says that NULL can not be converted to a
va_list, however I try it.
--
On 07/20/2011 06:58 PM, Roberto Bielli wrote:
> Hi,
>
> i have little questions.
> 1 .A GDB breakpoint in a xenomai task switch to secodary mode the task
> or the entire application ?
> 2. when i run the application that is halted on a breakpoint, when the
> xenomai scheduler enter to restore th
On 07/26/2011 02:09 PM, Daniele Nicolodi wrote:
> On 11/07/11 20:43, Gilles Chanteperdrix wrote:
>> On 07/07/2011 11:47 PM, Anders Blomdell wrote:
>>> When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
>>> 20110530 (Red Hat 4.6.0-9) (GCC)
On 07/26/2011 09:36 AM, zenati wrote:
> Dear,
>
> I'm developping the skin Arinc 653 for Xenomai. I'm trying to run
> process with my skin but I have an exception :
>
> Xenomai: suspending kernel thread d8824c40 ('�') at 0xb76dbdfc after
> exception #14
>
> What is the exception 14 ? Have you
On 07/22/2011 05:04 PM, Jan Kiszka wrote:
> Hi Gilles,
>
> pulling assert_context.c into the common libxenomai created a problem
> around picking the right __wrap_clock_gettime. As libpthread_rt depends
> on libxenomai, the latter is loaded first and defines the debug version
> of __wrap_clock_get
On 07/19/2011 08:44 AM, Jan Kiszka wrote:
> Hi,
>
> I've just uploaded my upstream queue that mostly deals with the various
> races I found in the domain migration code.
>
> One of my concerns raised earlier turned out to be for no reason: We do
> not allow Linux to wake up a task that has TASK_A
On 07/14/2011 10:57 PM, Jan Kiszka wrote:
> On 2011-07-13 21:12, Gilles Chanteperdrix wrote:
>> On 07/13/2011 09:04 PM, Jan Kiszka wrote:
>>> On 2011-07-13 20:39, Gilles Chanteperdrix wrote:
>>>> On 07/12/2011 07:43 PM, Jan Kiszka wrote:
>>>>> On
On 07/13/2011 09:04 PM, Jan Kiszka wrote:
> On 2011-07-13 20:39, Gilles Chanteperdrix wrote:
>> On 07/12/2011 07:43 PM, Jan Kiszka wrote:
>>> On 2011-07-12 19:38, Gilles Chanteperdrix wrote:
>>>> On 07/12/2011 07:34 PM, Jan Kiszka wrote:
>>>>> On
On 07/12/2011 07:43 PM, Jan Kiszka wrote:
> On 2011-07-12 19:38, Gilles Chanteperdrix wrote:
>> On 07/12/2011 07:34 PM, Jan Kiszka wrote:
>>> On 2011-07-12 19:31, Gilles Chanteperdrix wrote:
>>>> On 07/12/2011 02:57 PM, Jan Kiszka wrote:
>>>>>
On 07/12/2011 07:34 PM, Jan Kiszka wrote:
> On 2011-07-12 19:31, Gilles Chanteperdrix wrote:
>> On 07/12/2011 02:57 PM, Jan Kiszka wrote:
>>> xnlock_put_irqrestore(&nklock, s);
>>> xnpod_schedule();
>>>
On 07/12/2011 02:57 PM, Jan Kiszka wrote:
> xnlock_put_irqrestore(&nklock, s);
> xnpod_schedule();
> }
> @@ -1036,6 +1043,7 @@ redo:
>* to process this signal anyway.
>*/
> if (rthal_current_domain == rthal_root_domain)
On 07/12/2011 01:58 PM, Jan Kiszka wrote:
> On 2011-07-12 13:56, Jan Kiszka wrote:
>> However, this parallel unsynchronized execution of the gatekeeper and
>> its target thread leaves an increasingly bad feeling on my side. Did we
>> really catch all corner cases now? I wouldn't guarantee that yet.
On 07/12/2011 01:29 PM, Jan Kiszka wrote:
>> I find all this complicated for a very small corner-case, so, I keep
>> looking for a simpler solution. Let us try something else.
>
> It's rather the contrary: this solution is straightforward IMHO.
>
>>
>> If the thread is woken up for whatever reaso
On 07/12/2011 01:10 PM, Jan Kiszka wrote:
> On 2011-07-12 13:08, Gilles Chanteperdrix wrote:
>> On 07/12/2011 01:06 PM, Jan Kiszka wrote:
>>> On 2011-07-12 13:04, Gilles Chanteperdrix wrote:
>>>> On 07/12/2011 01:00 PM, Jan Kiszka wrote:
>>>>> On
On 07/12/2011 01:06 PM, Jan Kiszka wrote:
> On 2011-07-12 13:04, Gilles Chanteperdrix wrote:
>> On 07/12/2011 01:00 PM, Jan Kiszka wrote:
>>> On 2011-07-12 12:59, Gilles Chanteperdrix wrote:
>>>> On 07/12/2011 09:22 AM, Jan Kiszka wrote:
>>>>> On
On 07/12/2011 01:00 PM, Jan Kiszka wrote:
> On 2011-07-12 12:59, Gilles Chanteperdrix wrote:
>> On 07/12/2011 09:22 AM, Jan Kiszka wrote:
>>> On 2011-07-12 08:41, Gilles Chanteperdrix wrote:
>>>> On 07/11/2011 10:12 PM, Jan Kiszka wrote:
>>>>> On
On 07/12/2011 09:22 AM, Jan Kiszka wrote:
> On 2011-07-12 08:41, Gilles Chanteperdrix wrote:
>> On 07/11/2011 10:12 PM, Jan Kiszka wrote:
>>> On 2011-07-11 22:09, Gilles Chanteperdrix wrote:
>>>> On 07/11/2011 10:06 PM, Jan Kiszka wrote:
>>>>> On
On 07/12/2011 09:22 AM, Jan Kiszka wrote:
> On 2011-07-12 08:41, Gilles Chanteperdrix wrote:
>> On 07/11/2011 10:12 PM, Jan Kiszka wrote:
>>> On 2011-07-11 22:09, Gilles Chanteperdrix wrote:
>>>> On 07/11/2011 10:06 PM, Jan Kiszka wrote:
>>>>> On
On 07/11/2011 10:12 PM, Jan Kiszka wrote:
> On 2011-07-11 22:09, Gilles Chanteperdrix wrote:
>> On 07/11/2011 10:06 PM, Jan Kiszka wrote:
>>> On 2011-07-11 22:02, Gilles Chanteperdrix wrote:
>>>> On 07/11/2011 09:59 PM, Jan Kiszka wrote:
>>>>> On
On 07/11/2011 10:06 PM, Jan Kiszka wrote:
> On 2011-07-11 22:02, Gilles Chanteperdrix wrote:
>> On 07/11/2011 09:59 PM, Jan Kiszka wrote:
>>> On 2011-07-11 21:51, Gilles Chanteperdrix wrote:
>>>> On 07/11/2011 09:16 PM, Jan Kiszka wrote:
>>>>> On 2011-
On 07/11/2011 09:59 PM, Jan Kiszka wrote:
> On 2011-07-11 21:51, Gilles Chanteperdrix wrote:
>> On 07/11/2011 09:16 PM, Jan Kiszka wrote:
>>> On 2011-07-11 21:10, Jan Kiszka wrote:
>>>> On 2011-07-11 20:53, Gilles Chanteperdrix wrote:
>>>>> On 0
On 07/11/2011 09:16 PM, Jan Kiszka wrote:
> On 2011-07-11 21:10, Jan Kiszka wrote:
>> On 2011-07-11 20:53, Gilles Chanteperdrix wrote:
>>> On 07/08/2011 06:29 PM, GIT version control wrote:
>>>> @@ -2528,6 +2534,22 @@ static inline void do_taskexit_event(struct
>
On 07/08/2011 06:29 PM, GIT version control wrote:
> @@ -2528,6 +2534,22 @@ static inline void do_taskexit_event(struct
> task_struct *p)
> magic = xnthread_get_magic(thread);
>
> xnlock_get_irqsave(&nklock, s);
> +
> + gksched = thread->gksched;
> + if (gksched) {
> +
On 07/07/2011 11:47 PM, Anders Blomdell wrote:
> When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
> 20110530 (Red Hat 4.6.0-9) (GCC)", programs fail with -ENOSYS in
> rt_task_shadow. If compiled with "gcc version 4.5.1 20100924 (Red Hat
> 4.5.1-4) (GCC)" everything works
On 07/08/2011 04:06 PM, Anders Blomdell wrote:
> On 07/08/2011 02:41 PM, Gilles Chanteperdrix wrote:
>> On 07/07/2011 11:47 PM, Anders Blomdell wrote:
>>> When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
>>> 20110530 (Red Hat 4.6.0-9) (GCC)
On 07/07/2011 11:47 PM, Anders Blomdell wrote:
> When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
> 20110530 (Red Hat 4.6.0-9) (GCC)", programs fail with -ENOSYS in
> rt_task_shadow. If compiled with "gcc version 4.5.1 20100924 (Red Hat
> 4.5.1-4) (GCC)" everything works
Hi,
I already asked this question, but I can not find the answer in the
archives. I would like to provide access to the posix skin symbols
without --wrap. For this, we would add a prefix or suffix to each
symbol. Does anybody remember the prefix/suffix we decided to use?
Thanks.
--
On 07/06/2011 03:10 PM, zenati wrote:
> No I don't implement any handler, but there isn't a handler by default?
> I don't see any handler of signals in the sources of others skins. it
> means that I have to implement a handler in source of the test?
We do not understand your issue, you do not un
On 07/06/2011 02:22 PM, zenati wrote:
> Dear,
>
> I have implement a first version of the skin Arinc 653. However, I match
> one bug. Each time I execute a test I have implemented (Hello world
> test). The process display "Hello world!" but don't return and even if I
> do control-z or control-c
On 06/30/2011 01:32 PM, Jan Kiszka wrote:
> On 2011-06-30 13:09, Gilles Chanteperdrix wrote:
>> On 06/30/2011 11:36 AM, Jan Kiszka wrote:
>>> When creating of a shadow task fails, rt_task_create has to free the
>>> task object consistently, not only on registry errors.
On 06/30/2011 11:36 AM, Jan Kiszka wrote:
> When creating of a shadow task fails, rt_task_create has to free the
> task object consistently, not only on registry errors. Then we need to
> delete the core thread when fastlock allocation failed. Moreover, fix a
> double free of the fastlock object wh
On 06/29/2011 09:06 AM, Jan Kiszka wrote:
> On 2011-06-28 23:29, Gilles Chanteperdrix wrote:
>> On 06/28/2011 11:01 PM, GIT version control wrote:
>>> Module: xenomai-jki
>>> Branch: for-upstream
>>> Commit: 5597470d84584846875e8a35309e6302c768addf
>&g
On 06/28/2011 11:01 PM, GIT version control wrote:
> Module: xenomai-jki
> Branch: for-upstream
> Commit: 5597470d84584846875e8a35309e6302c768addf
> URL:
> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=5597470d84584846875e8a35309e6302c768addf
>
> Author: Jan Kiszka
> Date: Tue Jun 28
On 06/27/2011 08:32 AM, Jan Kiszka wrote:
> On 2011-06-24 21:58, Gilles Chanteperdrix wrote:
>> On 06/23/2011 01:36 PM, Jan Kiszka wrote:
>>> On 2011-06-23 13:29, Gilles Chanteperdrix wrote:
>>>> On 06/23/2011 11:09 AM, Jan Kiszka wrote:
>>>>> On
On 06/23/2011 01:36 PM, Jan Kiszka wrote:
> On 2011-06-23 13:29, Gilles Chanteperdrix wrote:
>> On 06/23/2011 11:09 AM, Jan Kiszka wrote:
>>> On 2011-06-23 11:05, Gilles Chanteperdrix wrote:
>>>> On 06/23/2011 09:38 AM, Jan Kiszka wrote:
>>>>>>
On 06/23/2011 11:37 AM, Jan Kiszka wrote:
> On 2011-06-20 19:07, Jan Kiszka wrote:
>> On 2011-06-19 15:00, Gilles Chanteperdrix wrote:
>>> On 06/19/2011 01:17 PM, Gilles Chanteperdrix wrote:
>>>> On 06/19/2011 12:14 PM, Gilles Chanteperdrix wrote:
>>>>>
On 06/23/2011 11:37 AM, Jan Kiszka wrote:
> On 2011-06-20 19:07, Jan Kiszka wrote:
>> On 2011-06-19 15:00, Gilles Chanteperdrix wrote:
>>> On 06/19/2011 01:17 PM, Gilles Chanteperdrix wrote:
>>>> On 06/19/2011 12:14 PM, Gilles Chanteperdrix wrote:
>>>>>
On 06/23/2011 08:24 PM, Philippe Gerum wrote:
> On Thu, 2011-06-23 at 20:13 +0200, Philippe Gerum wrote:
>> On Thu, 2011-06-23 at 19:32 +0200, Gilles Chanteperdrix wrote:
>>> On 06/23/2011 01:15 PM, Jan Kiszka wrote:
>>>> On 2011-06-23 13:11, Gilles Chanteperdrix wr
On 06/23/2011 01:15 PM, Jan Kiszka wrote:
> On 2011-06-23 13:11, Gilles Chanteperdrix wrote:
>> On 06/23/2011 11:37 AM, Jan Kiszka wrote:
>>> On 2011-06-20 19:07, Jan Kiszka wrote:
>>>> On 2011-06-19 15:00, Gilles Chanteperdrix wrote:
>>>>> On 06
On 06/23/2011 01:36 PM, Jan Kiszka wrote:
> On 2011-06-23 13:29, Gilles Chanteperdrix wrote:
>> On 06/23/2011 11:09 AM, Jan Kiszka wrote:
>>> On 2011-06-23 11:05, Gilles Chanteperdrix wrote:
>>>> On 06/23/2011 09:38 AM, Jan Kiszka wrote:
>>>>>>
On 06/23/2011 11:09 AM, Jan Kiszka wrote:
> On 2011-06-23 11:05, Gilles Chanteperdrix wrote:
>> On 06/23/2011 09:38 AM, Jan Kiszka wrote:
>>>> +#ifdef CONFIG_XENO_FASTSYNCH
>>>> + if (xeno_get_current() != XN_NO_HANDLE &&
>>>> +
On 06/23/2011 11:37 AM, Jan Kiszka wrote:
> On 2011-06-20 19:07, Jan Kiszka wrote:
>> On 2011-06-19 15:00, Gilles Chanteperdrix wrote:
>>> On 06/19/2011 01:17 PM, Gilles Chanteperdrix wrote:
>>>> On 06/19/2011 12:14 PM, Gilles Chanteperdrix wrote:
>>>>>
On 06/23/2011 09:38 AM, Jan Kiszka wrote:
>> +#ifdef CONFIG_XENO_FASTSYNCH
>> +if (xeno_get_current() != XN_NO_HANDLE &&
>> +!(xeno_get_current_mode() & XNRELAX) && buf_pool_get()) {
>> +struct print_buffer *old;
>> +
>> +old = buf_pool_get();
>> +whi
Hi,
I would like to better integrate rtdk and the posix skin by forcibly
wrapping the calls to malloc/free and also wrap printf to call
rt_printf.
However, currently, rt_printf can not really be used as a drop-in
replacement of printf:
- it is necessary to call rt_printf_auto_init, we can do
On 05/19/2011 10:29 PM, Philippe Gerum wrote:
> On Thu, 2011-05-19 at 20:36 +0200, Jan Kiszka wrote:
>> On 2011-05-19 20:15, Gilles Chanteperdrix wrote:
>>> On 05/19/2011 03:58 PM, Philippe Gerum wrote:
>>>> For this reason, I'm considering issuing a patch for
On 06/22/2011 12:55 PM, Jan Kiszka wrote:
> On 2011-06-22 12:36, Gilles Chanteperdrix wrote:
>> On 06/22/2011 11:26 AM, Jan Kiszka wrote:
>>> Hi Gilles,
>>>
>>> do you remember reasons for only pre-faulting the main thread's stack?
>>> The desir
On 06/22/2011 11:26 AM, Jan Kiszka wrote:
> Hi Gilles,
>
> do you remember reasons for only pre-faulting the main thread's stack?
> The desire to avoid wasting resources by forcing all stacks into memory?
>
> I've the requirement on my table to provide a generic solution of all
> shadow threads.
On 06/20/2011 10:41 PM, Jan Kiszka wrote:
> xnarch_switch_to is the central entry point for everyone. It may decide
> to branch to switch_to or __switch_to, or it simply handles all on its
> own - that's depending on the arch.
No, the Linux kernel does not know anything about xnarch_switch_to, so
On 06/20/2011 09:41 PM, Jan Kiszka wrote:
> On 2011-06-20 21:41, Gilles Chanteperdrix wrote:
>> On 06/20/2011 09:38 PM, Jan Kiszka wrote:
>>> On 2011-06-20 19:33, Gilles Chanteperdrix wrote:
>>>> On 06/20/2011 06:43 PM, Jan Kiszka wrote:
>>>>> On
On 06/20/2011 09:38 PM, Jan Kiszka wrote:
> On 2011-06-20 19:33, Gilles Chanteperdrix wrote:
>> On 06/20/2011 06:43 PM, Jan Kiszka wrote:
>>> On 2011-06-19 17:41, Gilles Chanteperdrix wrote:
>>>> Merged your whole branch, but took the liberty to change it a
On 06/20/2011 07:07 PM, Jan Kiszka wrote:
>> static inline void do_cleanup_event(struct mm_struct *mm)
>> {
>> +struct task_struct *p = current;
>> +struct mm_struct *old;
>> +
>> +old = xnshadow_mm(p);
>> +xnshadow_mmptd(p) = mm;
>> +
>> ppd_remove_mm(mm, &detach_ppd);
>> +
On 06/20/2011 06:43 PM, Jan Kiszka wrote:
> On 2011-06-19 17:41, Gilles Chanteperdrix wrote:
>> Merged your whole branch, but took the liberty to change it a bit
>> (replacing the commit concerning unlocked context switches with comments
>> changes only, and changing the comm
On 06/18/2011 03:58 PM, Jan Kiszka wrote:
> On 2011-06-18 15:12, Gilles Chanteperdrix wrote:
>> On 06/18/2011 03:07 PM, Jan Kiszka wrote:
>>> On 2011-06-18 14:56, Gilles Chanteperdrix wrote:
>>>> On 06/18/2011 02:10 PM, Jan Kiszka wrote:
>>>>> On
On 06/19/2011 01:17 PM, Gilles Chanteperdrix wrote:
> On 06/19/2011 12:14 PM, Gilles Chanteperdrix wrote:
>> I am working on this ppd cleanup issue again, I am asking for help to
>> find a fix in -head for all cases where the sys_ppd is needed during
>> some cleanup.
>>
On 06/19/2011 12:14 PM, Gilles Chanteperdrix wrote:
> I am working on this ppd cleanup issue again, I am asking for help to
> find a fix in -head for all cases where the sys_ppd is needed during
> some cleanup.
>
> The problem is that when the ppd cleanup is invoked:
> - we have
On 05/23/2011 03:53 PM, Jan Kiszka wrote:
> The following changes since commit aec30a2543afa18fa7832deee85e187b0faeb1f0:
>
> xeno-test: fix reference to @XENO_TEST_DIR@ (2011-05-15 21:20:41 +0200)
>
> are available in the git repository at:
> git://git.xenomai.org/xenomai-jki.git for-upstream
101 - 200 of 2013 matches
Mail list logo
