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 branch, but took the liberty to change
On 2011-06-20 21:51, Gilles Chanteperdrix wrote:
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
On 2011-06-20 19:46, Gilles Chanteperdrix wrote:
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
On 2011-06-20 22:52, Gilles Chanteperdrix wrote:
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
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: 7203b1a66ca0825d5bcda1c3abab9ca048177914
URL
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 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
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 PM, Jan Kiszka wrote:
On 2011-06-17 18:53
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.
That would be against the purpose of the XNTICK
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 handlers, we should skip the XNHTICK replay
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 PM, Jan Kiszka wrote:
On 2011-06-17 20:55
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 PM, Jan Kiszka wrote:
On 2011-06-18 14:56
On 2011-06-18 17:01, Gilles Chanteperdrix wrote:
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
point. Note that this introduces a tiny imprecision in the
accounting.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
This is also 2.5 material.
ksrc/nucleus/intr.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/ksrc/nucleus/intr.c b/ksrc
an interrupt handler, so better emulate an
IRQ context inside xntbase_tick by setting XNINIRQ.
This patch only affects users of xntbase_tick, ie. psos, vrtx and the
vxworks skin.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
If my analysis is correct, this is also 2.5 material.
ksrc
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 this assumption: xnpod_schedule invoked from
On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
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
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 task
and CPU they entered
On 2011-06-17 13:26, Gilles Chanteperdrix wrote:
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
On 2011-06-17 13:58, Philippe Gerum wrote:
On Fri, 2011-06-17 at 13:03 +0200, Jan Kiszka wrote:
On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
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
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:
XENO_BUGON(NUCLEUS, xnthread_get_rescnt(lastowner) 0);
RT threads do not balance their lock and
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
xnsynch_release triggers for RT threads
On 2011-05-31 18:50, Gilles Chanteperdrix wrote:
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
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 shortcomings of the
in-kernel lock usage
On 2011-05-31 19:58, Gilles Chanteperdrix wrote:
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
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 PM, Jan Kiszka wrote:
On 2011-05-24 16:03
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 PM, Jan Kiszka wrote:
On 2011-05-25 13:58
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 the list reversal patch, then the sys_ppd
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 an idea how to get that info to the delete
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 PM, Jan Kiszka wrote:
On 2011-05-24 14:30
On 2011-05-24 06:31, Gilles Chanteperdrix wrote:
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
On 2011-05-24 12:41, Gilles Chanteperdrix wrote:
On 05/24/2011 12:36 PM, Jan Kiszka wrote:
On 2011-05-24 11:58, Gilles Chanteperdrix wrote:
On 05/24/2011 11:36 AM, Jan Kiszka wrote:
On 2011-05-24 11:32, Gilles Chanteperdrix wrote:
On 05/24/2011 11:13 AM, Jan Kiszka wrote:
On 2011-05-24 06:31
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 the list reversal patch, then the sys_ppd
is the first in the list. So, we can, in the function ppd_remove_mm,
start by removing all
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
Jan Kiszka (1):
native: Fix msendq fastlock
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 code in Xenomai 2.6.x, disabling the feature
for 2.6.38 kernels and above in 2.5.x.
Comments
On 2011-04-29 20:38, Gilles Chanteperdrix wrote:
GIT version control wrote:
Module: xenomai-jki
Branch: for-upstream
Commit: 852c130d16410a597536c39d06b6abd1c9c6c822
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=852c130d16410a597536c39d06b6abd1c9c6c822
Author: Jan Kiszka
The following changes since commit 985cf80d202f97e32ae45957f2bfca764e3eb243:
nios2: fix pipeline patch for 2.6.35-mmu -- take #2 (2011-04-29 11:34:11
+0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
x86: Fix return type
The following changes since commit cf683ac01817bb19ae5429df4ca9e0e57d78b5b1:
arm: clean-up context switch (2011-04-16 12:47:50 +0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
vfile: Fix NULL pointer exception
On 2011-04-12 15:31, Jesper Christensen wrote:
I have managed to print the stack of a faulting thread:
Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at
nip=0xb911f940, lr=0xb911f940, r1=0xaf2c4580 after exception #1792
Xenomai: dumping stack at af2c4600
Xenomai:
On 2011-04-12 16:09, Jesper Christensen wrote:
Speaking of rtpc, could there be a race condition when using a
rtdm_lock_t to synchronize between a linux thread and a xenomai thread?
Without seeing at some code, I can't comment on this meaningfully.
Jan
--
Siemens AG, Corporate Technology, CT
On 2011-04-12 16:21, Jesper Christensen wrote:
There you go:
---
#include linux/module.h
#include linux/kernel.h
#include linux/list.h
#include linux/workqueue.h
#include rtnet_rtpc.h
#include up.h
On 2011-04-11 08:59, Jesper Christensen wrote:
There you go.
Even better would be individual patches (one for each topic) so that we
can more easily review/merge your improvements into RTnet. If you are
not familiar with this process, maybe you can convince Richard to do the
break-up... :)
On 2011-03-21 13:48, krishna m wrote:
Date: Thu, 17 Mar 2011 09:30:37 +0100
From: jan.kis...@siemens.com
To: gilles.chanteperd...@xenomai.org; krishnamurth...@hotmail.com
CC: xenomai-core@gna.org
Subject: Re: MSI support in Xenomai
On 2011-03-16 14:26, Gilles Chanteperdrix
On 2011-03-22 16:55, krishna m wrote:
Date: Tue, 22 Mar 2011 13:13:16 +0100
From: jan.kis...@siemens.com
To: krishnamurth...@hotmail.com
CC: gilles.chanteperd...@xenomai.org; xenomai-core@gna.org
Subject: Re: MSI support in Xenomai
On 2011-03-21 13:48, krishna m wrote:
On 2011-03-16 14:26, Gilles Chanteperdrix wrote:
krishna m wrote:
Hi All, I wanted to know if the latest Xenomai [Version
xenomai-2.5.6] supports MSI interrupts. I am using the adeos Patch
[version adeos-ipipe-2.6.37-x86-2.9-00] and corresponding Linux
kernel [version: linux-2.6.37]. I have
Hi,
in reply to the CfP for this year's Real-Time Linux Workshop, Richard
raised the question of another co-located Xenomai User Meeting [1].
Given that the last meeting was already in 2009 and we all appear to be
fairly busy, but more in the background, it might indeed be worth
taking this
Required for NULL.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/rtdm/rtdm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/rtdm/rtdm.h b/include/rtdm/rtdm.h
index 1e6e41e..d907f08 100644
--- a/include/rtdm/rtdm.h
+++ b/include/rtdm/rtdm.h
See TROUBLESHOOTING for explanation.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
TROUBLESHOOTING |4
scripts/Kconfig.frag |9 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/TROUBLESHOOTING b/TROUBLESHOOTING
index 4d84a79..e8d4b53 100644
Am 14.01.2011 15:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
See TROUBLESHOOTING for explanation.
Ok. Please update the wiki too.
Done.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Am 03.01.2011 11:32, Wolfgang Grandegger wrote:
Hi Gilles,
the attached patch fixes the issue.
Nothing critical, but I think we should consistently wrap the other way
around
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,36)
#define platform_device of_device
#endif
and update the users to the
Am 05.01.2011 21:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.01.2011 11:32, Wolfgang Grandegger wrote:
Hi Gilles,
the attached patch fixes the issue.
Nothing critical, but I think we should consistently wrap the other way
around
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,36
Asking the user to provide a temp directory for --outpatch and not
cleaning it up after completion is error-prone. Instead, generate such a
directory automatically and also remove it again when done.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
scripts/prepare-kernel.sh | 14
Am 11.11.2010 16:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I just hope we finally converge over a solution. Looks like all
possibilities have been explored now. A few more comments on this one:
It probably makes sense to group the status bits accordingly (both their
values
Am 07.11.2010 09:31, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts to do so here:
http://sisyphus.hd.free.fr/~gilles
Am 07.11.2010 10:57, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 07.11.2010 09:31, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch
Am 07.11.2010 11:03, Philippe Gerum wrote:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead of going back to the old way.
You can find the patch which attempts
Am 07.11.2010 11:12, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 07.11.2010 11:03, Philippe Gerum wrote:
On Sun, 2010-11-07 at 09:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Anyway, after some thoughts, I think we are going to try and make the
current situation work instead
Am 06.11.2010 23:49, Philippe Gerum wrote:
On Sat, 2010-11-06 at 21:37 +0100, Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka
Am 04.11.2010 01:13, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11
Am 04.11.2010 09:45, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 04.11.2010 01:13, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not only for the remote
reschedule case BTW).
Ok, let
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always be (not only
Am 04.11.2010 14:18, Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again.
Unlocked
if need-resched
Am 04.11.2010 15:53, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 04.11.2010 14:18, Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It is, I've reviewed the code today.
This commit was followed by several others to fix
the fix. You know how things
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with ftrace
on (after 2 hours, where it previously failed after maximum 23 minutes).
My
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off.
That is not enough.
It is, I've reviewed the code today
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test program, still runs with ftrace
on (after 2
Am 05.11.2010 00:46, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders
Am 03.11.2010 12:50, Jan Kiszka wrote:
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote
Am 03.11.2010 13:07, Anders Blomdell wrote:
On 2010-11-03 12.55, Jan Kiszka wrote:
Am 03.11.2010 12:50, Jan Kiszka wrote:
Am 03.11.2010 12:44, Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include
Am 03.11.2010 21:41, Philippe Gerum wrote:
On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include
Am 03.11.2010 23:03, Jan Kiszka wrote:
Am 03.11.2010 21:41, Philippe Gerum wrote:
On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different story). This may
fix the race:
Err, nonsense. As we manipulate xnsched::status also
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do in other cases where this is no need - different story). This may
fix
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we not not always use atomic ops for manipulating status bits (but
we do
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11, Jan Kiszka wrote:
Am 03.11.2010 23:03, Jan Kiszka wrote:
But we
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 03.11.2010 23:11
Am 28.10.2010 21:34, Philippe Gerum wrote:
On Thu, 2010-10-28 at 21:15 +0200, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles,
I happened to come across rthal_mark_irq_disabled/enabled on arm. On
first glance, it looks like these helpers manipulate irq_desc::status
non-atomically, i.e
Am 29.10.2010 10:27, Philippe Gerum wrote:
On Fri, 2010-10-29 at 09:00 +0200, Jan Kiszka wrote:
Am 28.10.2010 21:34, Philippe Gerum wrote:
On Thu, 2010-10-28 at 21:15 +0200, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles,
I happened to come across rthal_mark_irq_disabled/enabled
Am 29.10.2010 14:00, Philippe Gerum wrote:
On Fri, 2010-10-29 at 11:05 +0200, Jan Kiszka wrote:
Am 29.10.2010 10:27, Philippe Gerum wrote:
On Fri, 2010-10-29 at 09:00 +0200, Jan Kiszka wrote:
Am 28.10.2010 21:34, Philippe Gerum wrote:
On Thu, 2010-10-28 at 21:15 +0200, Gilles Chanteperdrix
Am 29.10.2010 14:58, Philippe Gerum wrote:
On Fri, 2010-10-29 at 14:46 +0200, Philippe Gerum wrote:
On Fri, 2010-10-29 at 14:09 +0200, Jan Kiszka wrote:
Am 29.10.2010 14:00, Philippe Gerum wrote:
On Fri, 2010-10-29 at 11:05 +0200, Jan Kiszka wrote:
Am 29.10.2010 10:27, Philippe Gerum wrote
Am 29.10.2010 19:42, Anders Blomdell wrote:
Jan Kiszka wrote:
Please provide the full kernel log, ideally also with the I-pipe tracer
(with panic tracing) enabled.
Will reconfigure/recompile and do that, with full kernel log do you
mean all
bootup info?
That's best to avoid missing some
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm
experincing occasionally weird behaviour.
Versions of things:
linux-2.6.34.5
xenomai-2.5.5.2
rtnet-39f7fcf
The
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying to use rt_eepro100, for sending raw ethernet packets,
but I'm
experincing occasionally weird behaviour.
Versions
Am 28.10.2010 17:05, Anders Blomdell wrote:
Current results:
1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after
some time:
BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540
Process raw_test (pid: 2924, ti=f18bc000 task=f1bdab00 task.ti=f18bc000)
I-pipe domain
Am 28.10.2010 17:18, Anders Blomdell wrote:
On 2010-10-28 17.09, Jan Kiszka wrote:
Am 28.10.2010 17:05, Anders Blomdell wrote:
Current results:
1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after
some time:
BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540
Process
Gilles,
I happened to come across rthal_mark_irq_disabled/enabled on arm. On
first glance, it looks like these helpers manipulate irq_desc::status
non-atomically, i.e. without holding irq_desc::lock. Isn't this fragile?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence
Hi,
for the past days, I had a look at the issue of classic MSIs (ie. not
MSI-X) under non-Linux I-pipe domains. Actually, the path that matters
most, IRQ delivery, is perfectly OK as is: just a simple ack on the APIC
and a NOP on completion.
Problematic are IRQ enable/disable (which
Hi,
here are the early results of my experiments on enabling ftrace and also
perf for use under Xenomai. Things work quite well so far, at least on
x86-64 which allows access to current and current_thread_info from
arbitrary contexts.
My primary goal was event tracing via ftrace, and this is the
Am 14.10.2010 21:26, Wolfgang Grandegger wrote:
On 10/14/2010 09:03 PM, Jan Kiszka wrote:
Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
Hi Jan,
On 10/14/2010 07:55 PM, Jan Kiszka wrote:
Am 14.10.2010 18:16, Philippe Gerum wrote:
On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
Am
Am 15.10.2010 14:47, Wolfgang Grandegger wrote:
On 10/15/2010 01:07 PM, Wolfgang Grandegger wrote:
On 10/15/2010 08:39 AM, Jan Kiszka wrote:
Am 14.10.2010 21:26, Wolfgang Grandegger wrote:
On 10/14/2010 09:03 PM, Jan Kiszka wrote:
Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
Hi Jan
Am 14.10.2010 17:42, Philippe Gerum wrote:
On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
Philippe,
irqbench does not inherently depend on a third I-pipe domain. It is a
useful testcase, the only in our portfolio that targets a peripheral
device use case. In fact, it was only
Am 14.10.2010 18:16, Philippe Gerum wrote:
On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
Am 14.10.2010 17:42, Philippe Gerum wrote:
On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
Philippe,
irqbench does not inherently depend on a third I-pipe domain. It is a
useful testcase
The following changes since commit 36a0e05a86d0cd19311cd33ae9da8618cc4d0c55:
posix: fix regression in clock_gettime (HOST_RT introduction) (2010-10-08
17:41:03 +0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (3):
Re-enable
Am 09.10.2010 12:58, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
The following changes since commit 36a0e05a86d0cd19311cd33ae9da8618cc4d0c55:
posix: fix regression in clock_gettime (HOST_RT introduction) (2010-10-08
17:41:03 +0200)
are available in the git repository at:
git
Philippe,
irqbench does not inherently depend on a third I-pipe domain. It is a
useful testcase, the only in our portfolio that targets a peripheral
device use case. In fact, it was only of the first test cases for Native
RTDM IIRC.
Please revert the removal and then cut out only the few parts
Am 09.10.2010 15:29, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Philippe,
irqbench does not inherently depend on a third I-pipe domain.
Yes, but it inherently depends on x86 too.
Not by design, just by missing contributions to add a few more I/O bindings.
Jan
signature.asc
, otherwise
no changes:
- SMI PCI-ID fix (2.5.x already has a similar version)
- a minor cleanup for rtipc
- fixes for /proc/xenomai/rtdm/{named_devices,protocol_devices} output
Jan Kiszka (8):
rt_print: Properly return printed length
RTDM: Plug race between proc_read_dev_info and device
101 - 200 of 2091 matches
Mail list logo
