On 2012-06-01 19:16, Gilles Chanteperdrix wrote:
Hi,
with the current tip of xenomai 2.6 branch, the sigdebug test testing
the mayday code ends up with a segfault on x86_32. I tried to have a
look at it, but could not really understand what happens: the register
on return from the syscall
On 2012-06-04 13:16, Philippe Gerum wrote:
On 06/01/2012 08:05 PM, Gilles Chanteperdrix wrote:
On 06/01/2012 07:28 PM, Jan Kiszka wrote:
On 2012-06-01 19:16, Gilles Chanteperdrix wrote:
Hi,
with the current tip of xenomai 2.6 branch, the sigdebug test testing
the mayday code ends up
On 2012-06-13 10:49, Gilles Chanteperdrix wrote:
On 06/13/2012 10:32 AM, mohammad khalid shaik wrote:
Thanks for your quick reply. I have one more question. whether kgdb setup
which is handy to debug the linux kernel can be used to debug xenomai?
From recent posts:
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-x86/bits/pod_64.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-x86/bits/pod_64.h b/include/asm-x86/bits/pod_64.h
index 00b2438..546a4fa 100644
--- a/include/asm-x86/bits/pod_64.h
+++ b
On 2012-07-17 17:00, Wolfgang Grandegger wrote:
On 07/17/2012 04:57 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
Typical PCI devices have many sources of interrupts (some level, some edge
triggered) normally all routed through PIN A.
AFAIC, PCI interrupts are *always* level sensitive.
More
On 2012-07-19 15:17, Kyle Maroney wrote:
Congratulations on the recent release of Xenomai 2.6.1. We are excited
about the recent move to the ipipe core series and 3.x kernel patches
becoming available for the x86 architecture.
I have been able to successfully patch the vanilla kernel
On 2012-07-19 19:07, Kyle Maroney wrote:
On 07/19/2012 09:33 AM, Jan Kiszka wrote:
On 2012-07-19 15:17, Kyle Maroney wrote:
Congratulations on the recent release of Xenomai 2.6.1. We are excited
about the recent move to the ipipe core series and 3.x kernel patches
becoming available
On 2012-07-27 15:04, Frederik Bayart wrote:
I'm running Xenomai 2.6.0 on Linux 2.6.38
I have a dual core processor.
When I run a busywait loop on cpu 0 (see source in attachment), I
can't do anything anymore on the computer although cpu 1 is almost
entirely idle. I can't interrupt the
On 2012-09-16 00:26, Gilles Chanteperdrix wrote:
On 09/11/2012 05:56 PM, Gernot Hillier wrote:
Hi there!
While testing ipipe-core3.2 on an SMP x86 machine, I found a reproducible
kernel BUG after some seconds after starting irqbalance:
[ cut here ]
kernel BUG at
On 2012-09-14 17:01, Franz Engel wrote:
Hi,
I've a little problem. I'm using the rtnet.h-header and the following
function:
ret = recvfrom ( ethernetConnection.sock, recBuffer, sizeof ( recBuffer ),0,
( struct sockaddr * ) ethernetConnection.dest_addr,destlen );
I compiled the
On 2012-09-17 08:30, Gilles Chanteperdrix wrote:
Hi,
looking at x86 latencies, I found that what was taking long on my atom
was masking the fasteoi interrupts at IO-APIC level. So, I experimented
an idea: masking at LAPIC level instead of IO-APIC, by using the task
priority register. This
On 2012-09-17 10:07, Gilles Chanteperdrix wrote:
On 09/17/2012 09:43 AM, Jan Kiszka wrote:
On 2012-09-17 08:30, Gilles Chanteperdrix wrote:
Hi,
looking at x86 latencies, I found that what was taking long on my atom
was masking the fasteoi interrupts at IO-APIC level. So, I experimented
On 2012-09-17 14:21, Gilles Chanteperdrix wrote:
On 09/17/2012 10:18 AM, Jan Kiszka wrote:
On 2012-09-17 10:07, Gilles Chanteperdrix wrote:
On 09/17/2012 09:43 AM, Jan Kiszka wrote:
On 2012-09-17 08:30, Gilles Chanteperdrix wrote:
Hi,
looking at x86 latencies, I found that what was taking
:42 AM, Jan Kiszka wrote:
On 2012-09-17 11:29, Gilles Chanteperdrix wrote:
On 09/17/2012 11:07 AM, Jan Kiszka wrote:
On 2012-09-17 10:32, Gilles Chanteperdrix wrote:
On 09/17/2012 10:18 AM, Jan Kiszka wrote:
On 2012-09-17 10:07, Gilles Chanteperdrix wrote:
On 09/17/2012 09:43 AM, Jan Kiszka
On 2012-09-17 16:02, Gilles Chanteperdrix wrote:
On 09/17/2012 03:54 PM, Jan Kiszka wrote:
On 2012-09-17 15:46, Gilles Chanteperdrix wrote:
On 09/17/2012 02:27 PM, Jan Kiszka wrote:
On 2012-09-17 14:15, Henri Roosen wrote:
On Mon, Sep 17, 2012 at 1:14 PM, Gilles Chanteperdrix
On 2012-09-17 19:46, Gilles Chanteperdrix wrote:
ipipe_end is a nop when called from primary domain, yes, but this is not
very different from edge irqs. Also, fasteoi become a bit like MSI: in
the same way as we can not mask MSI from primary domain, we should not
mask IO-APIC fasteoi irqs,
On 2012-09-17 20:08, Gilles Chanteperdrix wrote:
On 09/17/2012 08:05 PM, Jan Kiszka wrote:
On 2012-09-17 19:46, Gilles Chanteperdrix wrote:
ipipe_end is a nop when called from primary domain, yes, but this is not
very different from edge irqs. Also, fasteoi become a bit like MSI
On 2012-09-17 20:12, Jan Kiszka wrote:
On 2012-09-17 20:08, Gilles Chanteperdrix wrote:
On 09/17/2012 08:05 PM, Jan Kiszka wrote:
On 2012-09-17 19:46, Gilles Chanteperdrix wrote:
ipipe_end is a nop when called from primary domain, yes, but this is not
very different from edge irqs. Also
On 2012-09-17 20:16, Gilles Chanteperdrix wrote:
On 09/17/2012 08:15 PM, Jan Kiszka wrote:
On 2012-09-17 20:12, Jan Kiszka wrote:
On 2012-09-17 20:08, Gilles Chanteperdrix wrote:
On 09/17/2012 08:05 PM, Jan Kiszka wrote:
On 2012-09-17 19:46, Gilles Chanteperdrix wrote:
ipipe_end is a nop
On 2012-09-17 20:37, Gilles Chanteperdrix wrote:
On 09/17/2012 08:29 PM, Jan Kiszka wrote:
On 2012-09-17 20:18, Gilles Chanteperdrix wrote:
On 09/17/2012 08:15 PM, Jan Kiszka wrote:
On 2012-09-17 20:12, Jan Kiszka wrote:
On 2012-09-17 20:08, Gilles Chanteperdrix wrote:
On 09/17/2012 08:05
On 2012-09-17 23:50, Gilles Chanteperdrix wrote:
On 09/17/2012 08:54 PM, Jan Kiszka wrote:
On 2012-09-17 20:37, Gilles Chanteperdrix wrote:
On 09/17/2012 08:29 PM, Jan Kiszka wrote:
On 2012-09-17 20:18, Gilles Chanteperdrix wrote:
On 09/17/2012 08:15 PM, Jan Kiszka wrote:
On 2012-09-17
On 2012-09-17 10:13, Gilles Chanteperdrix wrote:
On 09/16/2012 10:50 AM, Philippe Gerum wrote:
On 09/16/2012 12:26 AM, Gilles Chanteperdrix wrote:
On 09/11/2012 05:56 PM, Gernot Hillier wrote:
Hi there!
While testing ipipe-core3.2 on an SMP x86 machine, I found a reproducible
kernel BUG
On 2012-09-18 19:28, Gilles Chanteperdrix wrote:
On 09/18/2012 07:25 PM, Jan Kiszka wrote:
On 2012-09-17 10:13, Gilles Chanteperdrix wrote:
On 09/16/2012 10:50 AM, Philippe Gerum wrote:
On 09/16/2012 12:26 AM, Gilles Chanteperdrix wrote:
On 09/11/2012 05:56 PM, Gernot Hillier wrote:
Hi
On 2012-09-18 20:31, Gilles Chanteperdrix wrote:
On 09/18/2012 08:25 PM, Jan Kiszka wrote:
On 2012-09-18 19:28, Gilles Chanteperdrix wrote:
On 09/18/2012 07:25 PM, Jan Kiszka wrote:
On 2012-09-17 10:13, Gilles Chanteperdrix wrote:
On 09/16/2012 10:50 AM, Philippe Gerum wrote:
On 09/16/2012
On 2012-09-18 21:01, Gilles Chanteperdrix wrote:
On 09/18/2012 08:55 PM, Jan Kiszka wrote:
On 2012-09-18 20:31, Gilles Chanteperdrix wrote:
On 09/18/2012 08:25 PM, Jan Kiszka wrote:
On 2012-09-18 19:28, Gilles Chanteperdrix wrote:
On 09/18/2012 07:25 PM, Jan Kiszka wrote:
On 2012-09-17 10
On 2012-09-18 21:05, Gilles Chanteperdrix wrote:
On 09/18/2012 08:55 PM, Jan Kiszka wrote:
On 2012-09-18 20:31, Gilles Chanteperdrix wrote:
On 09/18/2012 08:25 PM, Jan Kiszka wrote:
On 2012-09-18 19:28, Gilles Chanteperdrix wrote:
On 09/18/2012 07:25 PM, Jan Kiszka wrote:
On 2012-09-17 10
On 2012-09-18 21:12, Gilles Chanteperdrix wrote:
On 09/18/2012 09:10 PM, Jan Kiszka wrote:
On 2012-09-18 21:05, Gilles Chanteperdrix wrote:
rah, vectors_limit is not needed at all. I do not see which look you are
talking about.
cfg = irq_cfg(irq
On 2012-09-18 21:22, Gilles Chanteperdrix wrote:
On 09/18/2012 09:18 PM, Jan Kiszka wrote:
On 2012-09-18 21:12, Gilles Chanteperdrix wrote:
On 09/18/2012 09:10 PM, Jan Kiszka wrote:
On 2012-09-18 21:05, Gilles Chanteperdrix wrote:
rah, vectors_limit is not needed at all. I do not see which
On 2012-09-19 16:28, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
for (vector = 0; vector NR_VECTORS; ++vector) {
+/* I-pipe requires initialized vector_irq for system vectors */
+if (test_bit(vector, used_vectors))
+continue
On 2012-09-20 12:49, Philippe Gerum wrote:
On 09/20/2012 12:37 PM, Jan Kiszka wrote:
This reverts commit 073ff1e8045d0311b8cf390687c0ba3619681672.
Both service are NOT just root-only services. E.g., rtdm_irq_request
requires by specification support also over non-Linux contexts.
Nack. We
On 2012-09-20 12:57, Jan Kiszka wrote:
On 2012-09-20 12:56, Jan Kiszka wrote:
On 2012-09-20 12:49, Philippe Gerum wrote:
On 09/20/2012 12:37 PM, Jan Kiszka wrote:
This reverts commit 073ff1e8045d0311b8cf390687c0ba3619681672.
Both service are NOT just root-only services. E.g
On 2012-09-20 13:15, Jan Kiszka wrote:
Sorry, three bugs:
- in the RTDM spec as it always allowed rtdm_irq_request over RT task
contexts
Changing the spec and adding a runtime check will likely be no issue. No
sane driver should have made use of that option. I will file a patch
of rtdm_irq_enable/disable over
interrupt context for supported IRQ types. Therefore, clarify the
documentation of those functions that even more extreme care has to be
applied when relying on them.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/rtdm/rtdm_driver.h |1 +
ksrc/skins
On 2012-09-20 15:01, Gilles Chanteperdrix wrote:
On 09/20/2012 01:15 PM, Jan Kiszka wrote:
On 2012-09-20 12:57, Jan Kiszka wrote:
On 2012-09-20 12:56, Jan Kiszka wrote:
On 2012-09-20 12:49, Philippe Gerum wrote:
On 09/20/2012 12:37 PM, Jan Kiszka wrote:
This reverts commit
On 2012-09-20 15:10, Philippe Gerum wrote:
On 09/20/2012 01:15 PM, Jan Kiszka wrote:
On 2012-09-20 12:57, Jan Kiszka wrote:
On 2012-09-20 12:56, Jan Kiszka wrote:
On 2012-09-20 12:49, Philippe Gerum wrote:
On 09/20/2012 12:37 PM, Jan Kiszka wrote:
This reverts commit
On 2012-09-20 16:12, Gilles Chanteperdrix wrote:
On 09/20/2012 03:15 PM, Jan Kiszka wrote:
On 2012-09-20 15:01, Gilles Chanteperdrix wrote:
On 09/20/2012 01:15 PM, Jan Kiszka wrote:
On 2012-09-20 12:57, Jan Kiszka wrote:
On 2012-09-20 12:56, Jan Kiszka wrote:
On 2012-09-20 12:49, Philippe
On 2012-09-20 17:16, Philippe Gerum wrote:
On 09/20/2012 05:07 PM, Jan Kiszka wrote:
On 2012-09-20 16:05, Philippe Gerum wrote:
In this light, let's remove those checks nevertheless.
Enabling/disabling the IRQ are separate calls, and those should be
instrumented as those cause the restriction
On 2012-10-10 09:51, Gilles Chanteperdrix wrote:
On 10/10/2012 09:38 AM, Thierry Bultel wrote:
Hi Gilles,
Many thanks,
The first patch does not work, the second does.
I think the reason for 1st patch why is that in rtcan_virt, we have
rtdm_lock_get_irqsave(rtcan_recv_list_lock, lock_ctx);
On 2012-10-10 10:04, Gilles Chanteperdrix wrote:
On 10/10/2012 09:56 AM, Jan Kiszka wrote:
On 2012-10-10 09:51, Gilles Chanteperdrix wrote:
On 10/10/2012 09:38 AM, Thierry Bultel wrote:
Hi Gilles,
Many thanks,
The first patch does not work, the second does.
I think the reason for 1st patch
On 2012-10-10 10:58, Gilles Chanteperdrix wrote:
On 10/10/2012 10:10 AM, Jan Kiszka wrote:
On 2012-10-10 10:04, Gilles Chanteperdrix wrote:
On 10/10/2012 09:56 AM, Jan Kiszka wrote:
On 2012-10-10 09:51, Gilles Chanteperdrix wrote:
On 10/10/2012 09:38 AM, Thierry Bultel wrote:
Hi Gilles
On 2012-10-04 15:26, Gilles Chanteperdrix wrote:
On 10/04/2012 02:58 PM, Thierry Bultel wrote:
Le 04/10/2012 14:36, Gilles Chanteperdrix a écrit :
On 10/04/2012 02:15 PM, Thierry Bultel wrote:
Hi,
The existing rtcan_virt driver simulates a single CAN bus, on which are
N devices.
Sending to
On 2012-10-11 10:20, Philippe Gerum wrote:
On 10/11/2012 10:19 AM, Gilles Chanteperdrix wrote:
On 10/11/2012 10:15 AM, Philippe Gerum wrote:
On 10/11/2012 08:22 AM, Gilles Chanteperdrix wrote:
In a context where callbacks are called with spinlocks held, it is not
possible for drivers
All users of this lock are supposed to run over Linux context already.
Moreover, latest I-pipe patches complain that ipipe_virtualize_irq is
called with the Xenomai domain stalled. So convert this lock to a
sleeping Linux variant to avoid that alarm.
Signed-off-by: Jan Kiszka jan.kis
On 2012-10-17 13:22, Gilles Chanteperdrix wrote:
On 10/17/2012 01:20 PM, Jan Kiszka wrote:
Just like the Linux version does, let our RT Flexcan driver depend on
CONFIG_HAVE_CAN_FLEXCAN so that it can only be selected on platforms
that actually support it.
Do all old kernels for CPUs
On 2012-10-18 06:37, Gilles Chanteperdrix wrote:
On 10/17/2012 01:19 PM, Jan Kiszka wrote:
All users of this lock are supposed to run over Linux context already.
Moreover, latest I-pipe patches complain that ipipe_virtualize_irq is
called with the Xenomai domain stalled. So convert this lock
On 2012-10-18 08:21, Gilles Chanteperdrix wrote:
On 10/18/2012 08:11 AM, Jan Kiszka wrote:
On 2012-10-18 06:37, Gilles Chanteperdrix wrote:
On 10/17/2012 01:19 PM, Jan Kiszka wrote:
All users of this lock are supposed to run over Linux context already.
Moreover, latest I-pipe patches
.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v2:
- Improved commit message, no code changes
ksrc/nucleus/intr.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/ksrc/nucleus/intr.c b/ksrc/nucleus/intr.c
index c75fcac..4747de1
On 2012-10-22 09:19, Wolfgang Grandegger wrote:
On 10/21/2012 08:19 PM, David Butterworth wrote:
Hi all,
Is anyone working on drivers for a 4-channel CAN card? and what
EtherCAT drivers are currently available?
I never heard of EtherCAT with CAN? It normally uses Ethernet network
Hi Stefan,
On 2012-11-21 10:27, Stefan Roese wrote:
Hi Jan,
On 11/21/2012 09:24 AM, Jan Kiszka wrote:
On 2012-11-21 08:10, stefan.ro...@gmail.com wrote:
From: Stefan Roese s...@denx.de
This patch adds support for the RTDM LPB (LocalPlusBus) FIFO driver
for the MPC5200. It will be used
On 2012-11-22 17:55, Michael Pustylnik wrote:
Although you can use mutexes in this order, why would you want to do that?
Logically, unlocking mutex1 would mean finishing some operation started when
mutex1 was locked. If as a part of the operation you locked mutex2 and
haven't unlocked it
On 2012-11-27 14:46, Gilles Chanteperdrix wrote:
On 11/23/2012 12:15 PM, Jan Kiszka wrote:
On 2012-11-22 17:55, Michael Pustylnik wrote:
Although you can use mutexes in this order, why would you want to do that?
Logically, unlocking mutex1 would mean finishing some operation started
when
On 2012-12-07 09:18, Henri Roosen wrote:
On Thu, Dec 6, 2012 at 7:25 PM, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.orgmailto:gilles.chanteperd...@xenomai.org
wrote:
On 12/06/2012 05:35 PM, Henri Roosen wrote:
On Thu, Dec 6, 2012 at 12:23 PM, Henri Roosen
The following changes since commit ac565906d56ced004f39bc38a751466b2b5242ae:
ipipe-2.6.38.8-x86-2.11-02 (2012-03-17 11:09:18 +0100)
are available in the git repository at:
git://git.kiszka.org/ipipe queues/2.6.38-x86
Jan Kiszka (3):
ipipe: Factor out ipipe_pin_vma
ipipe: Pin
to avoid minor faults.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
mm/mprotect.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 3f234b3..af5da94 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -224,6 +224,24
Will be used for pinning during mprotect as well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/linux/ipipe.h |1 +
mm/memory.c | 43 +--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/include/linux/ipipe.h
-off-by: Jan Kiszka jan.kis...@siemens.com
---
kernel/irq/chip.c |2 +-
kernel/irq/manage.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b79ec1d..aeb8cc1 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -878,7
On 2012-12-15 20:16, Gilles Chanteperdrix wrote:
On 12/15/2012 11:03 PM, Wolfgang Mauerer wrote:
Hi Gilles,
On 15/12/2012 22:24, Gilles Chanteperdrix wrote:
I see some (recent) activity on this git repository:
https://github.com/siemens/ipipe/commits/core-3.5_for-upstream
In what state
On 2012-09-25 15:19, Wolfgang Mauerer wrote:
Don't left-shift further than the bit-width of the
shifted type allows. In this particular constellation,
this leads to selecting CPUs that are not specified in
supported_cpus_arg on systems with more than 32 cores.
Signed-off-by: Wolfgang
On 2013-01-02 17:35, Jeff Webb wrote:
On 01/01/2013 05:13 AM, Gilles Chanteperdrix wrote:
On 01/01/2013 05:09 AM, jeff.w...@nta-inc.net wrote:
When I try to open an RTDM serial device under Xenomai-2.6.2/Linux 3.4.6
(Ubuntu 12.04), the call appears to succeed, but I get the following
output
Hi,
this may involve some refactoring of the HAL and a bit of I-pipe, so I
better ask first:
Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the
same values when called on different CPUs. Therefore, It should rather
be called XNARCH_THIS_CPU_TIMER_IRQ now.
Looking at its
statistics and convert
intrlock to a sleeping Linux variant to avoid the alarm. And to simplify
some code paths.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
This revealed the broken usage of XNARCH_TIMER_IRQ by xnintr_query_next.
A similar issue was visible in format_irq_proc even before
On 2013-01-02 21:25, Jeff Webb wrote:
On 01/02/2013 12:07 PM, Jan Kiszka wrote:
Conceptually, all users of this lock are supposed to run over Linux
context already. Moreover, latest I-pipe patches complain that
ipipe_virtualize_irq is called with the Xenomai domain stalled which
invalidates
statistics and convert
intrlock to a sleeping Linux variant to avoid the alarm. And to simplify
some code paths.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v3:
- Fix OPT_STATS-less build
include/nucleus/intr.h |4 ++
ksrc/nucleus/intr.c| 84
On 2013-01-03 16:16, Gilles Chanteperdrix wrote:
On 01/02/2013 06:43 PM, Jan Kiszka wrote:
Hi,
this may involve some refactoring of the HAL and a bit of I-pipe, so I
better ask first:
Not sure when it changed, but XNARCH_TIMER_IRQ may no longer return the
same values when called
On 2013-01-03 17:27, Philippe Gerum wrote:
On 01/03/2013 04:44 PM, Jan Kiszka wrote:
On 2013-01-03 16:16, Gilles Chanteperdrix wrote:
On 01/02/2013 06:43 PM, Jan Kiszka wrote:
Hi,
this may involve some refactoring of the HAL and a bit of I-pipe, so I
better ask first:
Not sure when
On 2013-01-03 18:34, Philippe Gerum wrote:
On 01/03/2013 06:25 PM, Jan Kiszka wrote:
On 2013-01-03 17:27, Philippe Gerum wrote:
On 01/03/2013 04:44 PM, Jan Kiszka wrote:
On 2013-01-03 16:16, Gilles Chanteperdrix wrote:
On 01/02/2013 06:43 PM, Jan Kiszka wrote:
Hi,
this may involve some
On 2013-01-04 11:01, Philippe Gerum wrote:
On 01/03/2013 06:57 PM, Jan Kiszka wrote:
On 2013-01-03 18:34, Philippe Gerum wrote:
On 01/03/2013 06:25 PM, Jan Kiszka wrote:
On 2013-01-03 17:27, Philippe Gerum wrote:
On 01/03/2013 04:44 PM, Jan Kiszka wrote:
On 2013-01-03 16:16, Gilles
On 2013-01-04 11:32, Philippe Gerum wrote:
On 01/04/2013 11:16 AM, Jan Kiszka wrote:
On 2013-01-04 11:01, Philippe Gerum wrote:
On 01/03/2013 06:57 PM, Jan Kiszka wrote:
On 2013-01-03 18:34, Philippe Gerum wrote:
On 01/03/2013 06:25 PM, Jan Kiszka wrote:
On 2013-01-03 17:27, Philippe Gerum
On 2013-01-04 12:33, Philippe Gerum wrote:
On 01/04/2013 12:22 PM, Jan Kiszka wrote:
On 2013-01-04 11:32, Philippe Gerum wrote:
On 01/04/2013 11:16 AM, Jan Kiszka wrote:
On 2013-01-04 11:01, Philippe Gerum wrote:
On 01/03/2013 06:57 PM, Jan Kiszka wrote:
On 2013-01-03 18:34, Philippe Gerum
On 2013-01-06 11:14, Philippe Gerum wrote:
On 01/03/2013 03:09 PM, Jan Kiszka wrote:
+static struct xnvfile_lock_ops vfile_stat_lockops = {
+.get = xnintr_get_query_lock,
+.put = xnintr_put_query_lock,
+};
+
static struct xnvfile_snapshot stat_vfile = {
.privsz = sizeof
On 2013-01-06 11:55, Jan Kiszka wrote:
On 2013-01-06 11:14, Philippe Gerum wrote:
On 01/03/2013 03:09 PM, Jan Kiszka wrote:
+static struct xnvfile_lock_ops vfile_stat_lockops = {
+ .get = xnintr_get_query_lock,
+ .put = xnintr_put_query_lock,
+};
+
static struct xnvfile_snapshot
On 2013-01-06 14:55, Gilles Chanteperdrix wrote:
On 01/06/2013 12:03 PM, Jan Kiszka wrote:
On 2013-01-06 11:55, Jan Kiszka wrote:
On 2013-01-06 11:14, Philippe Gerum wrote:
On 01/03/2013 03:09 PM, Jan Kiszka wrote:
+static struct xnvfile_lock_ops vfile_stat_lockops = {
+ .get
On 2013-01-06 15:26, Gilles Chanteperdrix wrote:
On 01/06/2013 03:20 PM, Jan Kiszka wrote:
On 2013-01-06 14:55, Gilles Chanteperdrix wrote:
On 01/06/2013 12:03 PM, Jan Kiszka wrote:
On 2013-01-06 11:55, Jan Kiszka wrote:
On 2013-01-06 11:14, Philippe Gerum wrote:
On 01/03/2013 03:09 PM
On 2013-01-06 16:09, Gilles Chanteperdrix wrote:
If you prefer to skip the warning in ipipe, then I will send a
corresponding patch. The lock conversion is still necessary for forge,
though.
There are other ways around, ipipe_virtualize_irq is already a wrapper
used only by 2.6, so we can
On 2013-01-06 16:15, Gilles Chanteperdrix wrote:
On 01/06/2013 04:11 PM, Jan Kiszka wrote:
On 2013-01-06 16:09, Gilles Chanteperdrix wrote:
If you prefer to skip the warning in ipipe, then I will send a
corresponding patch. The lock conversion is still necessary for forge,
though
On 2013-01-06 17:08, Gilles Chanteperdrix wrote:
On 01/04/2013 01:54 PM, Philippe Gerum wrote:
On 01/04/2013 12:46 PM, Jan Kiszka wrote:
On 2013-01-04 12:33, Philippe Gerum wrote:
On 01/04/2013 12:22 PM, Jan Kiszka wrote:
On 2013-01-04 11:32, Philippe Gerum wrote:
On 01/04/2013 11:16 AM
On 2013-01-07 00:11, Gilles Chanteperdrix wrote:
On 01/07/2013 12:02 AM, Jan Kiszka wrote:
Splitting /proc is not a good idea from the usability POV. The whole
point of showing the load of IRQs in /stat is to have all information in
one place (percentages sum up to 100...).
I've pushed
performing access-enabling mprotect on a locked memory region of a
real-time process.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
mm/memory.c | 79 ---
mm/mlock.c | 18 +
2 files changed, 18 insertions(+), 79 deletions
On 2013-01-08 12:12, Mariusz Janiak wrote:
Hi GIlles,
As you suggested, I have prepared simple test case that demonstrate how
Xenomai is utilized by OROCOS. This test case behaves exactly the same like
helloword example. Scheduler is chosen before any mutex are processed, so in
my
On 2013-01-08 20:43, Gilles Chanteperdrix wrote:
On 01/08/2013 12:12 PM, Mariusz Janiak wrote:
Hi GIlles,
As you suggested, I have prepared simple test case that demonstrate how
Xenomai is utilized by OROCOS. This test case behaves exactly the same like
helloword example. Scheduler is
On 2013-01-08 22:06, Jan Kiszka wrote:
On 2013-01-08 20:43, Gilles Chanteperdrix wrote:
On 01/08/2013 12:12 PM, Mariusz Janiak wrote:
Hi GIlles,
As you suggested, I have prepared simple test case that demonstrate how
Xenomai is utilized by OROCOS. This test case behaves exactly the same
On 2013-01-08 22:06, Jan Kiszka wrote:
On 2013-01-08 20:43, Gilles Chanteperdrix wrote:
On 01/08/2013 12:12 PM, Mariusz Janiak wrote:
Hi GIlles,
As you suggested, I have prepared simple test case that demonstrate how
Xenomai is utilized by OROCOS. This test case behaves exactly the same
Only remove files from the target directory of patch_link if they are
missing in Xenomai AND are actually symbolic links. This is required
when merging Xenomai directories into non-empty kernel dirs.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
This is not required for the current patch
From acc3c57390d275a1b28d66f1ec88c85e0f8c0890 Mon Sep 17 00:00:00 2001
From: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
Date: Sat, 29 Dec 2012 17:48:20 +0100
Subject: [PATCH] x86/ipipe: restore warning with AMD erratum
---
arch/x86/kernel/apic/apic.c | 16 ++--
1
On 2013-01-11 08:37, Jan Kiszka wrote:
From acc3c57390d275a1b28d66f1ec88c85e0f8c0890 Mon Sep 17 00:00:00 2001
From: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
Date: Sat, 29 Dec 2012 17:48:20 +0100
Subject: [PATCH] x86/ipipe: restore warning with AMD erratum
---
arch/x86/kernel
On 2013-01-11 08:49, Gilles Chanteperdrix wrote:
On 01/11/2013 08:45 AM, Jan Kiszka wrote:
On 2013-01-11 08:37, Jan Kiszka wrote:
From acc3c57390d275a1b28d66f1ec88c85e0f8c0890 Mon Sep 17 00:00:00 2001
From: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
Date: Sat, 29 Dec 2012 17:48
On 2013-01-11 19:13, Jan Kiszka wrote:
Hi,
at
git://git.xenomai.org/ipipe-jki for-upstream/3.5
I've lined up our current x86 queue for I-pipe core-3.5. We are not yet
fully done with testing, I'd specifically like to give x86-32 a final
kick, so this is just a heads-up.
Yep
On 2013-01-12 03:39, Gilles Chanteperdrix wrote:
On 01/11/2013 07:13 PM, Jan Kiszka wrote:
x86/ipipe: Disallow transparent huge pages when I-pipe is active
# if you copy a distro .config, this can bite you... (we need to account for
THP later)
What is wrong with transparent huge
=45aca4239b6e5c772a12962bcdbe75435f4ffec2
Author: Jan Kiszka jan.kis...@siemens.com
Date: Thu Jan 10 14:29:14 2013 +0100
configure: Report defaults for smp/x86-sep/x86-tsc in help output
why only the x86 options? The option defaults have never been documented
in configure help string, but in README.INSTALL (I just fixed
On 2013-01-13 12:50, Gilles Chanteperdrix wrote:
On 01/13/2013 12:17 PM, Jan Kiszka wrote:
On 2013-01-12 18:12, Gilles Chanteperdrix wrote:
On 01/09/2013 02:47 PM, Jan Kiszka wrote:
Only remove files from the target directory of patch_link if they are
missing in Xenomai AND are actually
On 2013-01-12 18:59, Gilles Chanteperdrix wrote:
On 01/12/2013 06:45 PM, Jan Kiszka wrote:
On 2013-01-12 18:35, Gilles Chanteperdrix wrote:
On 01/11/2013 08:45 AM, Jan Kiszka wrote:
On 2013-01-11 08:37, Jan Kiszka wrote:
From acc3c57390d275a1b28d66f1ec88c85e0f8c0890 Mon Sep 17 00:00:00
On 2013-01-12 19:43, Gilles Chanteperdrix wrote:
On 01/09/2013 02:30 PM, Jan Kiszka wrote:
On 2013-01-08 22:06, Jan Kiszka wrote:
On 2013-01-08 20:43, Gilles Chanteperdrix wrote:
On 01/08/2013 12:12 PM, Mariusz Janiak wrote:
Hi GIlles,
As you suggested, I have prepared simple test case
On 2013-01-13 13:29, Jan Kiszka wrote:
On 2013-01-12 19:43, Gilles Chanteperdrix wrote:
On 01/09/2013 02:30 PM, Jan Kiszka wrote:
On 2013-01-08 22:06, Jan Kiszka wrote:
On 2013-01-08 20:43, Gilles Chanteperdrix wrote:
On 01/08/2013 12:12 PM, Mariusz Janiak wrote:
Hi GIlles,
As you
On 2013-01-14 12:57, Gilles Chanteperdrix wrote:
On 01/14/2013 05:47 AM, John Morris wrote:
On 01/13/2013 01:41 PM, Gilles Chanteperdrix wrote:
On 01/13/2013 08:14 PM, John Morris wrote:
Hi Gilles and Jan,
Note change of thread subject. I'm starting to get confused.
On 01/13/2013 06:16
On 2013-01-14 09:29, Michael Haberler wrote:
Hi,
thanks to patience on this list we were able to build linuxcnc such that it
runs on Xenomai, besides RT-PREEMPT, vanilla kernels (in a simulator/non-RT
mode) and RTAI
I'm planning to adapt linuxcnc such that a universal binary can be
On 2013-01-14 13:00, Jan Kiszka wrote:
On 2013-01-14 12:57, Gilles Chanteperdrix wrote:
On 01/14/2013 05:47 AM, John Morris wrote:
On 01/13/2013 01:41 PM, Gilles Chanteperdrix wrote:
On 01/13/2013 08:14 PM, John Morris wrote:
Hi Gilles and Jan,
Note change of thread subject. I'm starting
On 2013-01-11 19:38, Jan Kiszka wrote:
On 2013-01-11 19:13, Jan Kiszka wrote:
Hi,
at
git://git.xenomai.org/ipipe-jki for-upstream/3.5
I've lined up our current x86 queue for I-pipe core-3.5. We are not yet
fully done with testing, I'd specifically like to give x86-32 a final
kick, so
On 2013-01-14 20:15, Gilles Chanteperdrix wrote:
On 01/14/2013 08:13 PM, Jan Kiszka wrote:
On 2013-01-14 19:50, Gilles Chanteperdrix wrote:
On 01/14/2013 01:00 PM, Jan Kiszka wrote:
On 2013-01-13 20:41, Gilles Chanteperdrix wrote:
On 01/13/2013 08:14 PM, John Morris wrote:
Hi Gilles
On 2013-01-15 08:48, Gilles Chanteperdrix wrote:
Hi Jan,
we have a build failure on 2.4 kernels with the changes made in intr.c
for the correct display in /proc, it seems the bool type is not
available for these kernels.
On 2013-01-14 21:39, Gilles Chanteperdrix wrote:
Done, also note that my current work is the for-core-3.5.7 branch, not
the for-core-3.5 branch.
Both branches point to the same commit ATM. I suppose you didn't push
the new for-core-3.5.7 version yet. Once done, I'll rebase my stuff on top.
Jan
1 - 100 of 3501 matches
Mail list logo
