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: this
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, Philippe Gerum wrote:
On Tue, 2011-09-06 at 13
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 Chanteperdrix wrote:
On 09/06/2011 03
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
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;
-
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/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?
I
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 to
On 08/30/2011 01:00 AM, Alexis Berlemont wrote:
Hi,
On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org 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?
Yes. in my
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 ATM, but [1] is still an open bug - a bug that affects
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 about time we release Xenomai 2.6.0. Has anyone anything
pending (maybe Alex)? Should we
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 to avoid choosing eax, and eax
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 and it is
probably better
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 (this
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 the same
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 xenomai services do not: latency hangs right after
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 xenomai services do not: latency hangs right after
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.38.8 and xenomai-head with gcc-4.6. The obtained
kernel boots fine
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?
--
Gilles
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
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/2011 16:42, Gilles Chanteperdrix ha scritto
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 ++-
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/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);
+}
gcc for ARM chokes here: it says that NULL can
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
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_gettime
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 an idea
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), programs fail with -ENOSYS
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 the task
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 2011-07-12 19:38, Gilles Chanteperdrix wrote:
On 07/12/2011 07:34
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:
xnlock_put_irqrestore(nklock, s
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 2011-07-12 19:31, Gilles Chanteperdrix wrote:
On 07/12/2011 02:57
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 2011-07-11 21:51, Gilles Chanteperdrix wrote:
On 07/11/2011 09:16
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 2011-07-11 22:02, Gilles Chanteperdrix wrote:
On 07/11/2011 09:59
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 2011-07-11 22:02, Gilles Chanteperdrix wrote:
On 07/11/2011 09:59
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 2011-07-11 22:09, Gilles Chanteperdrix wrote:
On 07/11/2011 10:06
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 2011-07-12 08:41, Gilles Chanteperdrix wrote:
On 07/11/2011 10:12
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 2011-07-12 12:59, Gilles Chanteperdrix wrote:
On 07/12/2011 09:22
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 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 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();
}
@@ -1036,6 +1043,7 @@ redo:
* to process
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 as
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/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
task_struct *p)
magic
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 07/08/2011 06:29 PM, GIT version control wrote:
@@ -2528,6 +2534,22
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-07-11 21:10, Jan Kiszka wrote:
On 2011-07-11 20:53, Gilles
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 as
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), programs fail with -ENOSYS
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 the
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
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 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. Then we need to
delete the core
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 which
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
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit
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 jan.kis...@siemens.com
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 2011-06-23 11:05, Gilles Chanteperdrix wrote:
On 06/23/2011 09:38
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:
I am working on this ppd cleanup issue again, I am asking
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:
+#ifdef CONFIG_XENO_FASTSYNCH
+if (xeno_get_current
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();
+while (old != buffer)
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:
I am working on this ppd cleanup issue again, I am asking
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
+ !(xeno_get_current_mode() XNRELAX) buf_pool_get()) {
+ struct
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:
+#ifdef CONFIG_XENO_FASTSYNCH
+if (xeno_get_current
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 wrote:
On 06/23/2011 11:37 AM, Jan Kiszka
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:
I am working on this ppd cleanup issue again, I am asking
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. I
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 desire to avoid wasting resources by forcing all stacks into memory
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 a complete removal
of the NMI latency watchdog
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 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 commit about xntbase_tick
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 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 bit
(replacing the commit concerning unlocked
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 2011-06-19 17:41, Gilles Chanteperdrix wrote:
Merged your whole
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 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
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 no guarantee
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.
The problem is that when the ppd
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 2011-06-18 14:09, Gilles Chanteperdrix wrote:
On 06/18/2011 12:21
On 06/18/2011 12:21 PM, Jan Kiszka wrote:
On 2011-06-17 20:55, Gilles Chanteperdrix wrote:
On 06/17/2011 07:03 PM, Jan Kiszka wrote:
On 2011-06-17 18:53, Gilles Chanteperdrix wrote:
On 06/17/2011 04:38 PM, GIT version control wrote:
Module: xenomai-jki
Branch: for-upstream
Commit
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 2011-06-18 14:09, Gilles Chanteperdrix wrote:
On 06/18/2011 12:21 PM, Jan Kiszka wrote:
On 2011-06-17 20:55, Gilles Chanteperdrix wrote:
On 06/17/2011 07:03
On 06/18/2011 03:16 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:
Maybe in the irq handlers, we should skip the XNHTICK replay, when
current_domain is root_domain
On 06/18/2011 03:47 PM, Jan Kiszka wrote:
On 2011-06-18 15:40, Gilles Chanteperdrix wrote:
On 06/18/2011 03:16 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:
Maybe in the irq
On 06/18/2011 04:06 PM, Jan Kiszka wrote:
On 2011-06-18 16:01, Gilles Chanteperdrix wrote:
On 06/18/2011 03:47 PM, Jan Kiszka wrote:
On 2011-06-18 15:40, Gilles Chanteperdrix wrote:
On 06/18/2011 03:16 PM, Jan Kiszka wrote:
On 2011-06-18 15:12, Gilles Chanteperdrix wrote:
On 06/18/2011 03:07
On 06/18/2011 03:58 PM, GIT version control wrote:
Module: xenomai-jki
Branch: for-upstream
Commit: 97de95fdb166d731081f08e157674742f24a243b
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=97de95fdb166d731081f08e157674742f24a243b
Author: Jan Kiszka jan.kis...@siemens.com
On 06/17/2011 11:26 AM, Jan Kiszka wrote:
Our current interrupt handlers assume that they leave over the same task
and CPU they entered. But CONFIG_XENO_HW_UNLOCKED_SWITCH and commit
f6af9b831c broke this assumption: xnpod_schedule invoked from the
handler tail can now actually trigger a
On 06/17/2011 11:27 AM, Jan Kiszka wrote:
Based on code inspection, it looks like a timer handler triggering a
reschedule in the path xntbase_tick - xntimer_tick_aperiodic /
xntimer_tick_periodic_inner - handler can cause problems, e.g. a
reschedule before all expired timers were processed.
On 06/17/2011 01:03 PM, Jan Kiszka wrote:
On 2011-06-17 12:55, Gilles Chanteperdrix wrote:
On 06/17/2011 11:26 AM, Jan Kiszka wrote:
Our current interrupt handlers assume that they leave over the same task
and CPU they entered. But CONFIG_XENO_HW_UNLOCKED_SWITCH and commit
f6af9b831c broke
On 06/17/2011 01:22 PM, Jan Kiszka wrote:
On 2011-06-17 13:06, Gilles Chanteperdrix wrote:
On 06/17/2011 01:03 PM, Jan Kiszka wrote:
On 2011-06-17 12:55, Gilles Chanteperdrix wrote:
On 06/17/2011 11:26 AM, Jan Kiszka wrote:
Our current interrupt handlers assume that they leave over the same
On 06/17/2011 04:38 PM, GIT version control wrote:
Module: xenomai-jki
Branch: for-upstream
Commit: 7203b1a66ca0825d5bcda1c3abab9ca048177914
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=7203b1a66ca0825d5bcda1c3abab9ca048177914
Author: Jan Kiszka jan.kis...@siemens.com
On 06/14/2011 01:59 PM, Roberto Bielli wrote:
Here is the example and the command.
RT_TASK pippo;
RT_TASK pluto;
void test1()
{
int err;
err = rt_task_delete(pippo );
if( err != 0 )
printf(error task delete\n);
}
int main (int argc, char *argv[])
{
On 06/09/2011 06:43 PM, Roberto Bielli wrote:
Hi,
the function rt_task_delete goes in segmentation fault.
this is the environment:
- kernel 2.6.31.8 arm marvell (test custom porting)
- xenomai 2.5.5.1
Have you tried xenomai 2.5.6 ?
- the code:
int main (int argc, char *argv[])
{
On 05/31/2011 06:29 PM, Philippe Gerum wrote:
On Tue, 2011-05-31 at 13:37 +0200, Jan Kiszka wrote:
Hi Philippe,
enabling XENO_OPT_DEBUG_NUCLEUS reveals some shortcomings of the
in-kernel lock usage tracking via xnthread_t::hrescnt. This BUGON in
xnsynch_release triggers for RT threads:
On 05/31/2011 06:38 PM, Jan Kiszka wrote:
On 2011-05-31 18:29, Philippe Gerum wrote:
On Tue, 2011-05-31 at 13:37 +0200, Jan Kiszka wrote:
Hi Philippe,
enabling XENO_OPT_DEBUG_NUCLEUS reveals some shortcomings of the
in-kernel lock usage tracking via xnthread_t::hrescnt. This BUGON in
On 05/31/2011 07:06 PM, Jan Kiszka wrote:
On 2011-05-31 18:58, Philippe Gerum wrote:
On Tue, 2011-05-31 at 18:38 +0200, Jan Kiszka wrote:
On 2011-05-31 18:29, Philippe Gerum wrote:
On Tue, 2011-05-31 at 13:37 +0200, Jan Kiszka wrote:
Hi Philippe,
enabling XENO_OPT_DEBUG_NUCLEUS reveals some
On 05/26/2011 09:18 AM, Jan Kiszka wrote:
On 2011-05-25 20:48, Gilles Chanteperdrix wrote:
On 05/25/2011 02:22 PM, Jan Kiszka wrote:
On 2011-05-25 14:19, Gilles Chanteperdrix wrote:
On 05/25/2011 02:12 PM, Jan Kiszka wrote:
On 2011-05-25 13:58, Gilles Chanteperdrix wrote:
On 05/25/2011 01:20
On 05/26/2011 09:37 AM, Jan Kiszka wrote:
On 2011-05-26 09:29, Gilles Chanteperdrix wrote:
On 05/26/2011 09:18 AM, Jan Kiszka wrote:
On 2011-05-25 20:48, Gilles Chanteperdrix wrote:
On 05/25/2011 02:22 PM, Jan Kiszka wrote:
On 2011-05-25 14:19, Gilles Chanteperdrix wrote:
On 05/25/2011 02:12
On 05/25/2011 01:20 PM, Jan Kiszka wrote:
On 2011-05-24 16:03, Gilles Chanteperdrix wrote:
On 05/24/2011 03:52 PM, Jan Kiszka wrote:
On 2011-05-24 14:30, Gilles Chanteperdrix wrote:
Do you already have an idea how to get that info to the delete hook
function?
Yes. We start by not applying
On 05/25/2011 02:12 PM, Jan Kiszka wrote:
On 2011-05-25 13:58, Gilles Chanteperdrix wrote:
On 05/25/2011 01:20 PM, Jan Kiszka wrote:
On 2011-05-24 16:03, Gilles Chanteperdrix wrote:
On 05/24/2011 03:52 PM, Jan Kiszka wrote:
On 2011-05-24 14:30, Gilles Chanteperdrix wrote:
Do you already have
On 05/25/2011 02:22 PM, Jan Kiszka wrote:
On 2011-05-25 14:19, Gilles Chanteperdrix wrote:
On 05/25/2011 02:12 PM, Jan Kiszka wrote:
On 2011-05-25 13:58, Gilles Chanteperdrix wrote:
On 05/25/2011 01:20 PM, Jan Kiszka wrote:
On 2011-05-24 16:03, Gilles Chanteperdrix wrote:
On 05/24/2011 03:52
101 - 200 of 1571 matches
Mail list logo
