The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (3):
Append missing newline to rt_[f
On 2012-04-04 15:02, Gilles Chanteperdrix wrote:
On 04/04/2012 02:56 PM, Jan Kiszka wrote:
The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
are available in the git repository at:
git
On 2012-04-04 15:23, Gilles Chanteperdrix wrote:
On 04/04/2012 03:12 PM, Jan Kiszka wrote:
On 2012-04-04 15:02, Gilles Chanteperdrix wrote:
On 04/04/2012 02:56 PM, Jan Kiszka wrote:
The following changes since commit
0ef2410a2c9cf7102dead861241bd2d9957e4433:
Mask signals
Author: Jan Kiszka jan.kis...@siemens.com
Date: Fri Mar 30 18:06:27 2012 +0200
Add regression test for mprotect on pinned memory
This tests both the original issue of mprotect reintroducing COW pages
to Xenomai processes as well as the recently fixed zero page corruption.
Signed-off
On 2012-03-22 17:37, Roberto Bielli wrote:
I explain better the problem.
I want to use ethernet driver raw without using all the abstract layer
(tcp, socket etc)
and my xenomai application must link to the raw driver without enter in
secondary mode.
Have i change the driver
On 2012-03-23 12:18, Roberto Bielli wrote:
Hi Jan,
i want to send and receive custom raw packets over ethernet.
is it possibile with RTnet or it sends only rtnet packets ?
Thanks for your response.
RTnet is modular, and if you use the stack a sketched, you are free to
define the payload
On 2012-03-21 17:48, Roberto Bielli wrote:
Hi,
i want to use xenomai for sending standard tcp/ip packets.
Is it possible to rewrite the ethernet driver for xenomai without using
rtnet ?
Or if i use rtnet is there a way to send standard tcp packet instead
rtnet packets ?
Is the TCP/IP
This fixes build setups like '../configure'.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index c0a7d17..0bdced8 100644
--- a/configure.in
+++ b/configure.in
@@ -547,7
On 2012-02-07 17:18, Gilles Chanteperdrix wrote:
On 02/03/2012 03:50 PM, Jan Kiszka wrote:
-Werror-implicit-function-declaration is not compatible with C++, and
also decisions about -Wall and -pipe should be left to the application.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Had
On 2012-02-07 17:19, Gilles Chanteperdrix wrote:
On 02/01/2012 09:21 PM, Gilles Chanteperdrix wrote:
On 02/01/2012 04:50 PM, Jan Kiszka wrote:
On 2012-02-01 16:38, Gilles Chanteperdrix wrote:
On 02/01/2012 04:25 PM, Jan Kiszka wrote:
On 2012-02-01 16:17, Gilles Chanteperdrix wrote:
On 02/01
On 2012-02-07 17:28, Gilles Chanteperdrix wrote:
This causes a -L/usr/lib to be added on the link-edit command line,
which causes the link to fail by finding /usr/lib/libpthread.so instead
of the cross-compiler one, and fail.
How does libxenomai.la look like? Is it different from a native
-Werror-implicit-function-declaration is not compatible with C++, and
also decisions about -Wall and -pipe should be left to the application.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure.in | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git
On 2012-02-01 16:17, Gilles Chanteperdrix wrote:
On 02/01/2012 03:37 PM, Jan Kiszka wrote:
Hi,
don't remember anymore: Is there any subtle reason that prevent a
change like
diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am
index 39eaaed..4cc8859 100644
--- a/src
On 2012-01-25 19:05, Jan Kiszka wrote:
On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
On 01/25/2012 06:10 PM, Jan Kiszka wrote:
On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
On 01/25/2012 05:52 PM, Jan Kiszka wrote:
On 2012-01-25 17:47, Jan Kiszka wrote:
On 2012-01-25 17:35, Gilles
On 2012-01-26 12:20, Philippe Gerum wrote:
On 01/26/2012 11:36 AM, Jan Kiszka wrote:
On 2012-01-25 19:05, Jan Kiszka wrote:
On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
On 01/25/2012 06:10 PM, Jan Kiszka wrote:
On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
On 01/25/2012 05:52 PM, Jan
On 2012-01-26 13:56, Jan Kiszka wrote:
To trigger the enforced task termination without leaving any broken
states behind, there is one option: rt_task_spin. Surprisingly for me,
it actually spins in the kernel, thus triggers the second level if
waiting long enough. I wonder, though
On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
On 01/26/2012 11:36 AM, Jan Kiszka wrote:
On 2012-01-25 19:05, Jan Kiszka wrote:
On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
On 01/25/2012 06:10 PM, Jan Kiszka wrote:
On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
On 01/25/2012 05:52 PM
On 2012-01-26 15:36, Jan Kiszka wrote:
Regarding testability of the second watchdog state: We could add a
syscall to sigtest_module e.g which has the current rt_timer_spin
semantics.
Do you think this makes sense? Or some other testing driver?
Then I would go that direction.
Jan
--
Siemens
On 2012-01-26 16:52, Gilles Chanteperdrix wrote:
On 01/26/2012 04:06 PM, Jan Kiszka wrote:
On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
On 01/26/2012 11:36 AM, Jan Kiszka wrote:
On 2012-01-25 19:05, Jan Kiszka wrote:
On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
On 01/25/2012 06:10 PM
The code structures on x86 were broken as the compiler aligned the
internal layout. The same may have happened on blackfin. Fix it by
applying a packed tag on the enclosing structures.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Haven't checked Xenomai 3 yet, it may be affected as well
We had two regressions in this code recently. So test all 6 possible
SIGDEBUG reasons, or 5 if the watchdog is not available.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
src/testsuite/unit/Makefile.am | 16 +++-
src/testsuite/unit/sigdebug.c | 233
On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
On 01/25/2012 05:21 PM, Jan Kiszka wrote:
We had two regressions in this code recently. So test all 6 possible
SIGDEBUG reasons, or 5 if the watchdog is not available.
Ok for this test, with a few remarks:
- this is a regression test, so
On 2012-01-25 17:47, Jan Kiszka wrote:
On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
On 01/25/2012 05:21 PM, Jan Kiszka wrote:
We had two regressions in this code recently. So test all 6 possible
SIGDEBUG reasons, or 5 if the watchdog is not available.
Ok for this test, with a few remarks
On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
On 01/25/2012 06:10 PM, Jan Kiszka wrote:
On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
On 01/25/2012 05:52 PM, Jan Kiszka wrote:
On 2012-01-25 17:47, Jan Kiszka wrote:
On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
On 01/25/2012 05:21 PM
Fix a logic inversion introduced by b75cec1938. This both allows the
relaxed-owner check to work again and prevents that we enter an endless
signal storm if XNSWREP happens to be set already at this point (as seen
in the field).
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/nucleus
On 2011-10-14 13:20, Jan Kiszka wrote:
The following changes since commit 31bdadef9018de586bc3fe8de0f37b62b2507785:
testsuite: fix regression tests location (2011-10-14 01:46:08 +0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan
The following changes since commit 31bdadef9018de586bc3fe8de0f37b62b2507785:
testsuite: fix regression tests location (2011-10-14 01:46:08 +0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (2):
nucleus: Privatize
On 2011-10-14 14:35, Gilles Chanteperdrix wrote:
On 10/14/2011 01:20 PM, Jan Kiszka wrote:
The following changes since commit 31bdadef9018de586bc3fe8de0f37b62b2507785:
testsuite: fix regression tests location (2011-10-14 01:46:08 +0200)
are available in the git repository at:
git
On 2011-09-28 10:16, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 07:25:07PM +0200, Jan Kiszka wrote:
It manages buffers for you, provides NIC drivers and interfaces to
either build the higher protocol layers in the kernel or in user space.
That's the mission, but I would not exclude
On 2011-09-26 13:41, Richard Cochran wrote:
On Fri, Sep 23, 2011 at 03:50:42PM +0200, Jan Kiszka wrote:
On 2011-09-23 13:02, Richard Cochran wrote:
This patch adds a class driver for raw Ethernet drivers under
Xenomai. The goal is to support industrial protocols such as EtherCAT
and IEC 61850
On 2011-09-27 14:01, Richard Cochran wrote:
Again, every MAC driver needs to be tastefully and wisely adapted. I
don't necessarily need to avoid coalescing. The goal (for me) is *not*
to provide deterministic Ethernet performance. Instead the RT packets
should just be delivered ASAP.
This is
On 2011-09-27 17:10, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 02:20:43PM +0200, Jan Kiszka wrote:
On 2011-09-27 14:01, Richard Cochran wrote:
Again, every MAC driver needs to be tastefully and wisely adapted. I
don't necessarily need to avoid coalescing. The goal (for me
On 2011-09-27 18:05, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 05:16:09PM +0200, Jan Kiszka wrote:
On 2011-09-27 17:10, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 02:20:43PM +0200, Jan Kiszka wrote:
On 2011-09-27 14:01, Richard Cochran wrote:
Again, every MAC driver needs
On 2011-09-27 18:26, Jan Kiszka wrote:
I was simply hoping to collect some new ideas how to address the driver
maintenance issue in a better way but without dropping key features
needed for RT networking. Something like let's add generic RT channels
to Linux upstream drivers and then only
On 2011-09-27 19:00, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 06:26:44PM +0200, Jan Kiszka wrote:
On 2011-09-27 18:05, Richard Cochran wrote:
That's a common misunderstanding: RTnet is a networking stack with many
_optional_ components (like RTmac, RTcfg etc.). I would bet that it's
On 2011-09-27 19:04, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 06:30:00PM +0200, Jan Kiszka wrote:
On 2011-09-27 18:26, Jan Kiszka wrote:
I was simply hoping to collect some new ideas how to address the driver
maintenance issue in a better way but without dropping key features
needed
On 2011-09-23 13:02, Richard Cochran wrote:
This patch adds a class driver for raw Ethernet drivers under
Xenomai. The goal is to support industrial protocols such as EtherCAT
and IEC 61850, where the stack is a user space program needing
direct access at the packet level. The class driver
On 2011-09-23 15:58, Jean-Michel Hautbois wrote:
2011/9/23 Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
On 09/23/2011 11:49 AM, Jean-Michel Hautbois wrote:
OK, I have more traces (a few :)) :
I meant the I-pipe tracer alone. The I-pipe tracer intead of other
ftrace tracers.
On 2011-09-18 16:02, Philippe Gerum wrote:
On Fri, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
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
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, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
On 09/11/2011 04:29 PM, Jan Kiszka
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, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote
On 2011-09-18 17:18, Gilles Chanteperdrix wrote:
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, 2011-09-16
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.
Looks like we don't support this at all ATM:
do_setsched_event ignores events that enabled SCHED_OTHER, and the
XNOTHER flag is only set on
On 2011-09-11 12:50, 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.
Looks like we don't support this at all ATM:
do_setsched_event ignores events that enabled SCHED_OTHER
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 switching from real-time policy to SCHED_OTHER.
Doing this while holding a mutex looks invalid
On 2011-09-04 07:10, rainbow wrote:
Sorry to reply so late, I did a test about install ftrace on xenomai. the
following is my procedure:
#git://git.xenomai.org/xenomai-jki.git queues/ftrace
#git://git.kiszka.org/ipipe-2.6 queues/2.6.35-x86-trace
#cd queues/ftrace
#git checkout -b
On 2011-09-04 13:49, rainbow wrote:
you mean I use remotes/origin/queues/2.6.37-x86 branch and use the ipipe
patch for 2.6.37 then install them on x86_64, the ftrace can work?I will
have a try, thank you!
Use the 2.6.35-x86-trace, it already contains the ipipe patch, and build
it for x86-64.
On 2011-09-04 14:21, rainbow wrote:
Is the ipipe patch the same as patch like
adeos-ipipe-2.6.37.6-x86-2.9-02.patch,
Except that the trace branch is for 2.6.35, yes. More precisely it is
now the same, I just pushed the latest version that includes two more
backported ipipe fixes.
I know the
On 2011-09-04 15:16, rainbow wrote:
2011/9/4 Jan Kiszka jan.kis...@web.de
On 2011-09-04 14:21, rainbow wrote:
Is the ipipe patch the same as patch like
adeos-ipipe-2.6.37.6-x86-2.9-02.patch,
Except that the trace branch is for 2.6.35, yes. More precisely it is
now the same, I just pushed
On 2011-09-03 04:52, rainbow wrote:
hi,all,I want to use ftrace in xenomai-2.5.6,but when I use git://
git.kiszka.org/ipipe.git queues/2.6.35-x86-trace to get the linux
kernel,there is no option about xenomai or ipipe . If I want to patch the
xenomai patch,there are some problem. How should I
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 the ABI.
Jan
[1]
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 release an -rc first?
No patches ATM
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 not be converted to a
va_list, however
On 2011-07-31 19:46, Gilles Chanteperdrix wrote:
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 2011-07-28 18:56, Jan Kiszka wrote:
On 2011-07-27 20:49, Gilles Chanteperdrix wrote:
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 2011-07-27 20:44, Gilles Chanteperdrix wrote:
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
On 2011-07-27 20:49, Gilles Chanteperdrix wrote:
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
On 2011-07-28 18:56, Jan Kiszka wrote:
On 2011-07-27 20:49, Gilles Chanteperdrix wrote:
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 2011-07-26 13:54, zenati wrote:
Dear,
I'm trying to debug Xenomai kernel with GDB and Qemu.
QEMU in emulation or KVM mode?
So, I launch
Xenomai in Qemu and make it waiting for GDB. Then I start GDB and
connect them to Qemu, make breakpoint at the desired function to debug
and start
On 2011-07-27 18:13, zenati wrote:
On 07/27/2011 02:12 PM, Jan Kiszka wrote:
On 2011-07-27 14:01, zenati wrote:
On 07/27/2011 11:23 AM, Jan Kiszka wrote:
On 2011-07-26 13:54, zenati wrote:
Dear,
I'm trying to debug Xenomai kernel with GDB and Qemu.
QEMU in emulation or KVM mode?
I'm
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_ATOMICSWITCH set. So the
deletion race can indeed be
Hi Philippe,
trying to decouple the PREEMPT-RT gatekeeper wakeup path from XNATOMIC
(to fix the remaining races there), I wondered why we need a waitqueue
here at all.
What about an approach like below, i.e. waking up the gatekeeper
directly via wake_up_process? That could even be called from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-07-15 15:10, Jan Kiszka wrote:
But... right now it looks like we found our primary regression:
nucleus/shadow: shorten the uninterruptible path to secondary mode.
It opens a short windows during relax where the migrated task may be
active
On 2011-07-16 10:52, Philippe Gerum wrote:
On Sat, 2011-07-16 at 10:13 +0200, Jan Kiszka wrote:
On 2011-07-15 15:10, Jan Kiszka wrote:
But... right now it looks like we found our primary regression:
nucleus/shadow: shorten the uninterruptible path to secondary mode.
It opens a short windows
On 2011-07-16 11:56, Philippe Gerum wrote:
On Sat, 2011-07-16 at 11:15 +0200, Jan Kiszka wrote:
On 2011-07-16 10:52, Philippe Gerum wrote:
On Sat, 2011-07-16 at 10:13 +0200, Jan Kiszka wrote:
On 2011-07-15 15:10, Jan Kiszka wrote:
But... right now it looks like we found our primary regression
On 2011-07-15 14:30, Gilles Chanteperdrix wrote:
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
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 PM, Jan Kiszka wrote:
On 2011-07-12 19:31
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 PM, 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 PM, Jan Kiszka wrote:
On 2011-07-11 21:51
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 PM, Jan Kiszka wrote:
On 2011-07-11 22:02
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 PM, Jan Kiszka wrote:
On 2011-07-11 22:09
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 AM, Jan Kiszka wrote:
On 2011-07-12 08:41
On 2011-07-12 13:26, Gilles Chanteperdrix wrote:
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
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.
Specifically as I still have an obscure crash
On 2011-07-12 14:06, Gilles Chanteperdrix wrote:
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
On 2011-07-12 17:48, Philippe Gerum wrote:
On Tue, 2011-07-12 at 14:57 +0200, Jan Kiszka wrote:
On 2011-07-12 14:13, Jan Kiszka wrote:
On 2011-07-12 14:06, Gilles Chanteperdrix wrote:
On 07/12/2011 01:58 PM, Jan Kiszka wrote:
On 2011-07-12 13:56, Jan Kiszka wrote:
However, this parallel
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 this signal anyway
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);
xnpod_schedule
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 = xnthread_get_magic(thread);
xnlock_get_irqsave(nklock, s);
+
+gksched =
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 = xnthread_get_magic(thread);
xnlock_get_irqsave
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 @@ static inline void do_taskexit_event
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 Chanteperdrix wrote:
On 07/08/2011 06:29 PM
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 PM, Jan Kiszka wrote:
On 2011-07-11 21:10
Fix a build warning at this chance as well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Applies on top of xenomai-gch.git gch/u_mode
ksrc/skins/native/task.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/ksrc/skins/native/task.c b/ksrc/skins/native
, avoid a use-after-release of the fastlock object in
__task_delete_hook.
This fixes heap corruptions when running out of resources.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Applies on top of xenomai-gch.git gch/u_mode
ksrc/skins/native/syscall.c |4 ++-
ksrc/skins/native/task.c
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 thread when fastlock allocation failed
Author: Jan Kiszka jan.kis...@siemens.com
Date: Tue Jun 28 22:10:07 2011 +0200
nucleus: Allow drop_u_mode syscall from any context
xnshadow_sys_drop_u_mode already checks if the caller is a shadow. It
does that without issuing a warning message if the check fails - in
contrast
On 2011-06-29 09:25, Gilles Chanteperdrix wrote:
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
Hi Gilles,
dynamic printf backend selection is a suboptimal idea when you want
chronological output (not that uncommon during debugging). The native
printf may actually hit the screen (or the log file) before some earlier
queued rt_printf message because the dump thread is busy or has a lower
On 2011-06-28 22:48, Jan Kiszka wrote:
Hi Gilles,
dynamic printf backend selection is a suboptimal idea when you want
chronological output (not that uncommon during debugging). The native
printf may actually hit the screen (or the log file) before some earlier
queued rt_printf message
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 AM, Jan Kiszka wrote:
+#ifdef
On 2011-06-22 23:55, Gilles Chanteperdrix wrote:
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
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 print_buffer *old;
+
+ old
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 for help to
find a fix in -head for all
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 think this should be possible using
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?
I've the requirement on my table to provide
On 2011-06-22 12:56, Gilles Chanteperdrix wrote:
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
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).
What makes splmax() redundant for the unlocked
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 for help to
find a fix in -head for all cases where the sys_ppd is needed during
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 context switches with comments
changes only
1 - 100 of 2092 matches
Mail list logo
