Jan Kiszka wrote:
Hi,
someone ;) complained about this statement regarding
rtdm_task_busy_sleep. I think he is right.
Applied, thanks.
--- drvlib.c(revision 44)
+++ drvlib.c(working copy)
@@ -335,7 +335,7 @@
* - Kernel-based task
* - User-space task (RT, non-RT)
*
- *
Resending here since this is a general project issue.
Original Message
Subject: Re: [Xenomai-help] timeout in native API calls (cond, sem,
mutex, etc).
Date: Fri, 21 Oct 2005 18:45:59 +0200
From: Philippe Gerum [EMAIL PROTECTED]
Organization: Xenomai
To: Jan Kiszka
Jan Kiszka wrote:
Fixes gcc-4 warnings.
Applied, thanks.
Jan
Index: testsuite/latency/latency.c
===
--- testsuite/latency/latency.c (revision 54)
+++
FYI, I have uploaded the initial release of Adeos for the Blackfin architecture:
http://download.gna.org/adeos/patches/v2.6/adeos/bfin/adeos-ipipe-uc-2.6.12-bfin-1.0-00.patch
It is based on the 2.6.12 kernel found in the uClinux-2005R3 distribution, and
tested on a BF533 eval board.
Germain Olivier wrote:
At the beginning of October I've posted on the RTAI mailing list a
question about the development of additional scheduler for RTAI/Fusion.
About the pluggable scheduler infrastructure, can you give more details on
what you expect ?
An implementation in the nucleus that
Heikki Lindholm wrote:
Merge 32- and 64-bit powerpc architectures into a common powerpc arch in
anticipation of the similar merge happening in linux kernel (possible in
2.6.15). Amount of shared code between 32- and 64-bit ppc is substantial
and I don't see anything changing that. These
Fillod Stephane wrote:
Hi,
The adeos-ipipe-2.6.13-ppc-1.0-03.patch file in Xenomai-2.0 dist appears
to be broken. The unified diff format is wrong on
include/asm-ppc/ipipe.h,
which breaks include/asm-ppc/mmu_context.h. I've found the problem while
applying the patch on a Linux 2.6.13 kernel.
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
just to avoid that this issue got lost during the migration to Xenomai:
It's still not possible to compile a C++ POSIX program with CFLAGS
obtained via xeno-config --posix-ldflags
Romain Lenglet wrote:
- A kernel option that causes Xenomai (or Adeos) to blatantly
malfunction or even crash is a freaking BUG, and should be
reported asap to the Xenomai-core list or the Adeos-main list.
IOW, there is no such thing as options allowed to crash your
box with Adeos/Xenomai
Dmitry Adamushko wrote:
Hi Jan,
I have some code hanging around here which implements IRQ sharing at
skin level for an experimental in-house development over Xenomai. The
code is smart enough to register an IRQ sharing trampoline handler only
in case sharing is actually practiced for
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi all,
and another patch: This one changes the rtserial API so that the baud
rate can now be provided as an integer instead of the previous low-level
encoded value. The baud base of a device is provided as module parameter
to the driver on insmod. Turned
Sebastian Smolorz wrote:
Hi,
here's a patch for a bug in skins/rtdm/syscall.c. The msghdr was not
copied to user space upon completion of a recvmsg() call if the return
value was not equal to zero. But recvmsg shall return the length of the
message in bytes (according to IEEE Std 1003.1).
Jan Kiszka wrote:
Hi,
just to bring this topic in mind again: what is currently preventing to
activate Bruno's nice page as the main Xenomai site? I see no
significant features lacking, fine-tuning can still be done later. This
project deserves a more representative portal than the Gna site! ;)
Ignacio García Pérez wrote:
Hi,
The subject says it all.
Fixed, thanks.
PS: please send patches when possible, it's faster to handle for me and less
likely to be forgotten in my job queue. TIA,
Nacho.
___
Xenomai-core mailing list
Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a case,
for a new client old messages are just irrelevant. And xnpipe_release()
cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler() and xnpipe_close_handler() be called
Philippe Gerum wrote:
Dmitry Adamushko wrote:
yep, it's a problem since data may be client-dependent. In such a
case, for a new client old messages are just irrelevant. And
xnpipe_release() cleans up the queus but, well, does it too earlier.
so,
1) should xnpipe_open_handler
Ignacio García Pérez wrote:
I had a first contact with the new build system. I really really don't
like the fact it touches my kernel source tree. Besides adeos, I like to
keep the kernel source independent of xenomai, because that tree is
shared for other projects.
At that point, I would
Heikki Lindholm wrote:
Xenomai 2.1:
- Add ppc64 I-pipe kernel support
Applied, thanks.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/system.h
xenomai-devel/include/asm-powerpc/system.h
---
Marco Cavallini wrote:
Hi,
with fusion-0.9.1 and VxWorks skin
I am testing the creation of 255 different tasks each with a different
priority
level from 0 to 254.
I am facing to a problem creating more than 12 tasks with taskSpawn
after creating 12 tasks the program fails into thread.c
in
Jan Kiszka wrote:
Hi,
this is basically the last version of my rt_pipe_create-ext patch to add
private, user-resizeable heaps to native pipes. Joerg has tested this
patch successfully under the 2.1 trunk, and I added a ChangeLog snippet.
Attached both 2.0.x and 2.1.x patches - please apply at
Andrea Iudiciani wrote:
Hi all, hi Paolo,
I would like to know if is scheduled the porting of Xenomai to
PPC-based platform and, if the answer is affermative, when.
I'm very interested about that.
best regards,
It's already there:
Jan Kiszka wrote:
Hi,
some fixes related to warnings when you switch on Xenomai's NMI watchdog.
Applied, thanks.
Jan
Index: include/asm-i386/system.h
Panagiotis Issaris wrote:
Hi,
I'm also having issues compiling the latest Xenomai tree.
Mm, dot-config would be great. TIA,
On 11/25/05, *Ignacio García Pérez* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi,
I dunno what's changed, but I updated my xenomai snapshot to
Jan Kiszka wrote:
Hi,
as I'm lazy, er busy, I'm pushing this idea into public instead of
hacking a patch on my own: wouldn't it be nice to have something like
the latency backtrace of PREEMPT_RT also in Xenomai?
Yes; we would had saved a lot of time with a precise debug
instrumentation in
Panagiotis Issaris wrote:
Hi Jan,
On 11/28/05, *Jan Kiszka* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
...
reference to `__raw_read_unlock'
kernel/built-in.o: In function `schedule_event':
/usr/local/src/linux-2.6.14/kernel/xenomai/nucleus/shadow.c:152:
Kiszka [EMAIL PROTECTED]
+
+ * ksrc/arch/i386/smi.c: Remove __initdata from rthal_smi_pci_tbl
+ to make table persistent.
+
+ * ksrc/nucleus/module.c (__xeno_sys_exit): Reorder proc-fs
+ cleanup to avoid stalled entries.
+
2005-11-29 Philippe Gerum [EMAIL PROTECTED
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
trying to set up a serial console now).
(rtdm_task_join_nrt): Clarify doc.
+
2005-11-30 Philippe Gerum [EMAIL PROTECTED]
* ksrc/nucleus/pod.c (xnpod_delete_thread): Prevent double-deletion.
@@ -10,7 +14,7 @@
* ksrc/arch/powerpc/patches: Upgrade to Adeos
2.4.25-denx-0.9-04, 2.6.10-ppc64-r3.patch.
-2005-11-30 Ignacio García Pérez
Heikki Lindholm wrote:
Add SMP timer support code for the powerpc arch in Xenomai 2.1. Still a
bit rough, but I'll clean it up as I go. Compiled and tested on G5 UP,
SMP (I-pipe 2.6.14 0.9-02) and G4 UP (I-pipe 2.6.14 1.0-07). Doesn't
seem to break anything. On a G5, SMP seems to bring a
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
I happened to stumble over this comment[1]. It made me curious,
especially as it is not totally correct (the loop is executed in
IRQ-off
context, thus it *is* timecritical
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
I happened to stumble over this comment[1]. It made me curious,
especially as it is not totally correct (the loop is executed in
IRQ
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
trying to set up a serial
Philippe Gerum wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi,
this tiny patch exports the NMI watchdog's threshold as module parameter
debug_maxlat of xeno_hal. This means that one can either override the
value via a kernel parameter or in sysfs/modules/xeno_hal/parameters
Jan Kiszka wrote:
Hi,
these are two typo fixes for the serial driver. One of them should have
broken kernel 2.4 compilation for this driver, the other is cosmetic
Applied, thanks.
Jan
PS: What about this splnone in gatekeeper_thread(), BTW. Still needed?
Nope. Fixed.
---
Jan Kiszka wrote:
Philippe Gerum wrote:
...
Fixed. The cause was related to the thread migration routine to
primary mode (xnshadow_harden), which would spuriously call the Linux
rescheduling procedure from the primary domain under certain
circumstances. This bug only triggers on preemptible
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
...
Fixed. The cause was related to the thread migration routine to
primary mode (xnshadow_harden), which would spuriously call the Linux
rescheduling procedure from the primary domain under certain
Here is v2.0.2. This is mainly a bug fix release, which includes the
patches contributed during the last six weeks.
Few changes, but all over the place:
- RTDM fixes and updates
- 16550 driver fixes
- nucleus fixes (message pipes and shadow management mainly)
- VxWorks errno fix
-
Jan Kiszka wrote:
Hi all,
this is fully working proposal how to re-enable in-kernel timer latency
benchmarks.
More precisely, it adds a new RTDM device rtbenchmarkX (and also a
new RTDM class) which can execute either a kernel task or timer
periodically. The benchmark device generates all the
Jan Kiszka wrote:
Hi,
as suggested in an earlier mail, here is a patch that - as I think -
improves the behaviour of librtdm. It will let applications start even
if the kernel services of RTDM are not available. Instead, -ENODEV or
-EAFNOSUPPORT will be returned in this case when the user tries
Hi Dmitry,
Dmitry Adamushko wrote:
Hi everybody,
the enclosed patches (the first version, hence it's still raw) are
supposed to build the basis needed on the ipipe layer for adding
support of real-time shared interrupts. As a side effect, the
irq_trampoline() layer has been eliminated and the
Hi Jan,
Jan Kiszka wrote:
Hi all,
as a late Christmas gift I would like to roll out a probably quite
useful instrumentation tool:
This is the PREEMPT_RT-inspired I-pipe tracing service!
The core ipipe_trace.patch-v4 should apply cleanly against 2.6.14
kernels with ipipe-1.0-12, the
Jan Kiszka wrote:
Hi Philippe,
this is a revised version of the tracer patch, addressing your concerns
hopefully in the right way. Changes since the previous release:
* move __ipipe_init_trace_proc() declaration to linux/ipipe.h
* define __BUILTIN_RETURN_ADDRESSx in linux/ipipe.h unless some
Hannes Mayer wrote:
Hi Jan!
Jan Kiszka wrote:
Hannes Mayer wrote:
I checked out xeno.trunk just a few minutes ago.
With kernel 2.4.32, kernel compilation fails with this:
mq.c: In function `mq_notify':
mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function)
mq.c:475: error:
Jan Kiszka wrote:
Jan Kiszka wrote:
--- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig2005-11-24
23:10:21.0 +0100
+++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
Hannes Mayer wrote:
Jan Kiszka wrote:
[...]
Yea, maybe that periodic timer mode is not compiled in and
rt_timer_start fails in your original example. I think it's off by
default now.
Yeah, got it! Sorry for not supplying error code earlier!
In Xeno source:
int xnpod_start_timer (u_long
Jan Kiszka wrote:
Hi,
this patches fixes the hint a user sees when trying to start some
RT-application without the related core service being available. Might
be frustrating for a newbie if the suggested command fails...
Applied, thanks.
Jan
Jan Kiszka wrote:
Stefan Kisdaroczi wrote:
Hi,
cant the timer be started by default ?
The current state (2.0.1) seems to lead to the following scenario:
1) Every app calls rt_timer_start()
2) If you call rt_timer_stop you can hurt other rt-apps, so dont
call it
3) As some apps dont stop
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
I happened to stumble over this comment[1]. It made me curious,
especially as it is not totally correct
I've just rolled out two patches, the first issue of the 1.1 series for
x86, and the accompanying tracer patch contributed by Jan Kiszka and
Luotao Fu. With the latter patch, the I-pipe shall trace the longest
stalled path of the domain with the highest priority. Apply them in that
order:
Jan Kiszka wrote:
Philippe Gerum wrote:
I've just rolled out two patches, the first issue of the 1.1 series for
x86, and the accompanying tracer patch contributed by Jan Kiszka and
Luotao Fu. With the latter patch, the I-pipe shall trace the longest
stalled path of the domain with the highest
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
I've just rolled out two patches, the first issue of the 1.1 series for
x86, and the accompanying tracer patch contributed by Jan Kiszka and
Luotao Fu. With the latter patch, the I-pipe shall trace the longest
stalled path
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
I've just rolled out two patches, the first issue of the 1.1 series for
x86, and the accompanying tracer patch contributed by Jan Kiszka and
Luotao Fu. With the latter patch, the I-pipe shall trace
Dmitry Adamushko wrote:
Hi everybody,
I have got a few synch-related problems while adding the code for
supporting the rt shared irqs to
the nucleus layer. But at first let's take a look at some adeos code
that, well, possibly has the
same problem.
let's say the primary domain is
So new that the paint is still wet, here is the first candidate release
of the upcoming 2.1 series. The major changes since v2.0.x are as follows:
* New build system which allows to compile Xenomai statically into the
kernel image, and ensures proper decoupling between kernel and
user-space
Jan Kiszka wrote:
Hi again,
I would like to remind of the following three patches:
* rtdm-excl-dev.patch - RTDM fix for bug in opening of exclusive
devices (both 2.0 and 2.1)
Merged.
* rtdm-nrt-close.patch - don't permit RTDM devices without NRT closure
handlers
Merged.
*
Jan Kiszka wrote:
Happy New Year everyone!
Hope you all survived the turn of the year without complications. ;)
Nearly buried alive in patches, but this is hardly a complication.
I would like to start with a new patch round. The first one is a revised
and extended version of the earlier
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
I've just rolled out two patches, the first issue of the 1.1 series
for
x86, and the accompanying tracer patch contributed by Jan Kiszka and
Luotao Fu
Jan Kiszka wrote:
Hi again,
here comes the first update of the new latency tracer.
arch/i386/kernel/entry.S | 27 +++
arch/i386/kernel/ipipe-root.c |4
include/asm-i386/system.h | 70 +
include/linux/ipipe_trace.h |3
kernel/ipipe/Kconfig | 18 ++
Hi Jim,
Jim Cromie wrote:
hi Phillipe, everyone,
happy 06 !
Bugfree 06? Nah, just kidding...
Out of curiosity, I applied adeos-ipipe-2.6.14-i386-1.1-01.patch on top
of 15.
the rejects were small, and simple enough looking, that even
a lazy sod like myself might manually fix them, so I
Dmitry Adamushko wrote:
err... I have to orginize some issues next few days so I'll be out of my
notebook. Then I'll finilize the ipipe-irq-related patch so to be ready
for the .01 version.
Meanwhile, I have finished merging the shared IRQ infrastructure into
the Adeos codebase for all
Wolfgang Grandegger wrote:
Hallo,
when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I
stumbeld over the following problem:
In linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h there is
defined:
#define ulong i
#define uint i
This makes trouble when a
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But this raised the question to me again if we really need the xenomai
prefix for all the skin headers /from within xenomai/. Why not doing the
same linking dance for the other skins as well? Or do you also prefer
Jan Kiszka wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But this raised the question to me again if we really need the
xenomai
prefix for all the skin headers /from within xenomai/. Why not
doing the
same linking dance for the other
Jim Cromie wrote:
Kent Borg wrote:
Jim Cromie posted a patch attempt for 2.6.15 (yeah!), and the patch
applied, but it doesn't compile for me:
[...]
LD init/built-in.o
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage':
: undefined reference to
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
...
Meanwhile I found a solution for the described unterminated trace (put
an explicite trace_end at the end of __ipipe_unstall_iret_root),
included the irq number in the begin/end report, and stumbled over some
other remaining
Heikki Lindholm wrote:
Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but
not yet set last_task_used_math to NULL. As a result the tasks MSR_FP
will get set, although it should be cleared. If the task happens to hit
one of the codepaths that save FPU state if MSR_FP is set,
Jan Kiszka wrote:
Hi Philippe,
this patches cleans up the include/rtdm folder by moving internal
headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two
profile headers, and syscall.h there. The latter is still only needed
for building Xenomai itself, thus it will not be
Jan Kiszka wrote:
Additionally, I compiled latest RTnet SVN against
it without problems (x86, PPC is currently being fixed by Wolfgang).
Btw, the moduleparams/ulong/uint issue in the 2.4 wrappers that showed
up with RTNet has been fixed in Xenomai's trunk too. Normally.
--
Philippe.
Jan Kiszka wrote:
Hi Philippe,
this patches cleans up the include/rtdm folder by moving internal
headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two
profile headers, and syscall.h there. The latter is still only needed
for building Xenomai itself, thus it will not be
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi Philippe,
this patches cleans up the include/rtdm folder by moving internal
headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two
profile headers, and syscall.h there. The latter is still only needed
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi Philippe,
this patches cleans up the include/rtdm folder by moving internal
headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two
profile headers, and syscall.h
Heikki Lindholm wrote:
Philippe Gerum kirjoitti:
Heikki Lindholm wrote:
Philippe Gerum kirjoitti:
Heikki Lindholm wrote:
Xenomai might preempt linux when linux has cleared a tasks MSR_FP,
but not yet set last_task_used_math to NULL. As a result the tasks
MSR_FP will get set, although
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
this patch is to reset the maximum IRQs-off path after timer calibration
(will get flooded otherwise). If you have no concerns, please apply.
Applied, thanks.
Actually, there is another noise source: rthal_timer_request() for the
APIC
Kent Borg wrote:
On Sat, Jan 07, 2006 at 12:52:23AM -0700, Jim Cromie wrote:
You get to keep both pieces ? ;-)
Cool!
Ive attached my working config - might get you going. pls report
back what made your config not work, once you find it.
I'm looking at it now. In the meantime, if
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
attached is a patch of Xenomai trunk build system to allow building
Linux kernel as part of Xenomai build process. This way, typing make
install builds and installs the Linux kernel, kernel
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The current approach is to use the sources of the running kernel if the
only option specified is --enable-linux-build. Do you mean you find this
feature superfluous ?
If $enableval is y
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The current approach is to use the sources of the running kernel if
the
only option specified is --enable-linux-build. Do you mean you find
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Likely not this time (keep it cold anyway, who knows); I strongly suspect a bug in
xnarch_switch_to() for all archs but x86
Now that you are talking about it, I may be the one who owes a beer to
everyone by first having put a bug in ia64
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Likely not this time (keep it cold anyway, who knows); I strongly suspect a bug in
xnarch_switch_to() for all archs but x86
Now that you are talking about
Stelian Pop wrote:
Le 12 janv. 06 à 10:12, Philippe Gerum a écrit :
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include asm/offsets.h does
Stelian Pop wrote:
Le 12 janv. 06 à 10:12, Philippe Gerum a écrit :
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include asm/offsets.h does
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S have
broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include asm/offsets.h does not exist
Symbols like SAVE_NVGPRS do not exist
Fixed.
For the time being, I will stick
Heikki Lindholm wrote:
Add some polish, eg. make it work, for the recent thread switching
changes for the ppc64.
Applied, thanks.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/hal.h
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion. Although I'm
willing to supply you with stresstests, I would nevertheless like to learn
more from task migration as this debugging session
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion.
Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
more from task migration
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion.
Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
more from task migration
Anders Blomdell wrote:
Philippe Gerum wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next
interrupt gets generated before the previous one has finished)
[ 42.543765] [c00c2008
Jan Kiszka wrote:
Dmitry Adamushko wrote:
snip
To achieve this,
1) xnintr_t should be extended with a name field;
2) rt_intr_create() should contain a name argument and not use
auto-generation (as irqN) any more.
Ok, sounds reasonable. This said, since this change would alter the
-devel/ksrc/arch/powerpc/fpu_64.S
--- xenomai/ksrc/arch/powerpc/fpu_64.S 2005-11-18 20:55:24.0 +0200
+++ xenomai-devel/ksrc/arch/powerpc/fpu_64.S1970-01-01 02:00:00.0
+0200
@@ -1,71 +0,0 @@
-/*
- * Copyright (C) 2001,2002,2003,2004 Philippe Gerum.
- *
- * 64-bit PowerPC adoption
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Hi,
For your review, here is an attempt to factor arithmetic routines in
asm-generic/hal.h.
And with the blackfin architecture...
Applied, thanks.
Hi,
Stefan Kisdaroczi wrote:
Hi all,
as a reminder (userspace, native skin, shared heap) [1]:
API documentation: If the heap is shared, this value can be either zero, or
the same value given to rt_heap_create().
This is not true. As the heapsize gets altered in rt_heap_create for page size
Jeroen Van den Keybus wrote:
And now, Ladies and Gentlemen, with the patches attached.
I've installed both patches and the problem seems to have disappeared.
I'll try it on another machine tomorrow, too. Meanwhile: thanks very
much for the assistance !
Actually, the effort you made
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in
the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is
more obvious. On non-PPC archs it would translate to *_irq_enable.
I
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi Philippe,
this patch tries to clarify where to solve SMI-related latencies. Or
should we even mention the kconfig path?
The name of the config switch involved should be enough, I guess.
What about this? Please apply if it's
Hannes Mayer wrote:
Ciao Philippe!
Philippe Gerum wrote:
[...]
Clearly not, it is still on the project's agenda, but PREEMPT_RT has
been too much of a moving target recently, not to speak of the vanilla
2.6 kernel itself.
Recently ? As for Kernel 2.6 there has always been too much
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA -
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the support
Philippe Gerum wrote:
Philippe Gerum wrote:
Anders Blomdell wrote:
When trying to run Xenomai on PowerPC with OpenPIC, I have (finally)
found that interrupt latency is much improved with the following patch:
--- arch/ppc/syslib/open_pic.c~ 2006-01-08 03:15:24.0 +0100
+++ arch/ppc
1 - 100 of 1458 matches
Mail list logo
