Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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 `ret_from_intr' arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' make: *** [.tmp_vmlinux1] Error 1 ~/linux-2.6.15$ For a .config I started with the stock Ubuntu 2.6.12-10-686 config file and then took the defaults for all the oldconfig questions. Suggestions? You get to keep both pieces ? ;-) FWIW, the kernel was still running on my soekris 4801 til just now. (I rebooted) Most of that time it was without its NFS root fs; my laptop was unconnected. It was doing *no* work of any kind tho. Not that this helps... Im trying a kernel build on my sony laptop pentium M. differnt config than yours, but fuller than the soekris. Its running now, Im typing on it. wifi card works too ! Ive attached my working config - might get you going. pls report back what made your config not work, once you find it. :: ipipe/Linux :: Priority=100, Id=0x irq0-15: accepted irq32: grabbed, virtual :: ipipe/version :: 1.1-01 FWIW, I diffed the 14 patch against mine, was puzzled at the large textual diffs. Guessed that it was a file ordering diff in the tar, and then forgot to mention this at send. This seems kinda odd, since Im running linux. Phillipe, are you running BSD ? /ducks Are you creating patches from an fs other than ext3 ? That could explain the ordering. If not, Im stumped. Maybe its an svn thing, they have a berkley-db-as-fs dont they ? hth, jimc Also, FWIW, Ive been reading LKML, and it appears that Ingo Molnar's Mutex patches have turned the corner with Linux. Theyre not in, and Ive got no crystal ball, but I suspect they will get into 17 or 16 a good writeup for the regular folks (like me) on this list is here: http://lwn.net/Articles/164380/ config.gz Description: GNU Zip compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm kirjoitti: 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, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Additionally, there's also a Linux bug, which might cause corruption in 2.6.14 PREEMPT: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9f232a125bf86b0dae09f8ea4a0553535cf6b658 For solid performance that should also be applied on top of the I-pipe patch. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka 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 it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. Just tried. At least svn r380 compiled and worked fine for me. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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 `ret_from_intr' arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' make: *** [.tmp_vmlinux1] Error 1 ~/linux-2.6.15$ For a .config I started with the stock Ubuntu 2.6.12-10-686 config file and then took the defaults for all the oldconfig questions. Suggestions? You get to keep both pieces ? ;-) FWIW, the kernel was still running on my soekris 4801 til just now. (I rebooted) Most of that time it was without its NFS root fs; my laptop was unconnected. It was doing *no* work of any kind tho. Not that this helps... Im trying a kernel build on my sony laptop pentium M. differnt config than yours, but fuller than the soekris. Its running now, Im typing on it. wifi card works too ! Ive attached my working config - might get you going. pls report back what made your config not work, once you find it. :: ipipe/Linux :: Priority=100, Id=0x irq0-15: accepted irq32: grabbed, virtual :: ipipe/version :: 1.1-01 FWIW, I diffed the 14 patch against mine, was puzzled at the large textual diffs. Guessed that it was a file ordering diff in the tar, and then forgot to mention this at send. This seems kinda odd, since Im running linux. Phillipe, are you running BSD ? /ducks Well, sometimes this idea surfaces in the back of my head when I'm waiting for large disk I/O to complete over 2.6. And when it finally does, this operation leaves me as breathless as my hard drive... Are you creating patches from an fs other than ext3 ? That could explain the ordering. If not, Im stumped. Maybe its an svn thing, they have a berkley-db-as-fs dont they ? Yes they do, but this is unrelated to the apparently funky internal layout of my patches. It's just that I now have all Adeos ports over 2.6 in a single Linux tree (but the blackfin one which is uClinux-based), and each and every arch-specific patch is just extracted by an automated script from the original multi-arch patch. The way each individual per-arch patch is (re-)composed does not depend on the fs then. hth, jimc Also, FWIW, Ive been reading LKML, and it appears that Ingo Molnar's Mutex patches have turned the corner with Linux. Theyre not in, and Ive got no crystal ball, but I suspect they will get into 17 or 16 The real meat we are waiting for is the priority inheritance mechanism so that the ownership property of mutexes is leveraged to do something sensible against the inversion priorities that plague the vanilla kernel, and this particular piece is going to be harder to push forward (kind of asbestos underware everyone!). This said, Ingo Molnar said that he would progressively distill the PREEMPT_RT infrastructure into the mainline kernel, and so far, he succeeded quite well doing so. Remarkable chess player ;o) However, I must admit that from the Adeos maintenance POV, those changes all over the map that took place since 2.6.11 or so are making the job quite more complex. a good writeup for the regular folks (like me) on this list is here: http://lwn.net/Articles/164380/ Nice piece, indeed. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [PATCH] latency tracer update
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 unterminated trace on a different machine. So, no need
to hurry with the merge (not the review! ;) ), I will publish a second
revision first.
And here comes this revision finally. Should apply (almost) cleanly
against latest ipipe versions. Additionally to the changes of the first
revision this one addresses the following topics:
o fix trace overrun handling
o report IRQ number to tracer on IRQ entry/exit
o fix virtually leaking IRQs-off in __ipipe_unstall_iret_root()
o fix another potential NMI race
o really trace the maximum IRQs-off time, not the maximum time of
consecutive IRQs-off times (that scenario will soon be addressed
instead in the latency benchmark tool = resetfreeze the maximum
latency from the user's point of view)
...and it turned out that the existing functions were no sufficient for
this. So here comes an add-on patch to update3:
o allow ipipe_trace_{frozen|max}_reset from every context
(well, at least give it a try and just fail on locked traces)
o mark border between valid and invalid trace points
o show invalid points border
Apply order:
ipipe_tracer.update3
ipipe_tracer.update3-1
Merged in 1.1-03, with the appropriate tracer patch. Thanks.
The front-end to the first change, a modified latency+timerbench will
get committed to Xenomai soon. It already works nicely, automatically
creating a freeze of the maximum latency turn the benchmark perceives.
Jan
--- linux-2.6.14.3/kernel/ipipe/tracer.c.orig 2006-01-06 11:13:41.0
+0100
+++ linux-2.6.14.3/kernel/ipipe/tracer.c2006-01-06 20:11:10.0
+0100
@@ -134,10 +134,14 @@ __ipipe_migrate_pre_trace(struct ipipe_t
int i;
new_tp-trace_pos = pre_trace+1;
+
for (i = new_tp-trace_pos; i 0; i--)
memcpy(new_tp-point[WRAP_POINT_NO(new_tp-trace_pos-i)],
old_tp-point[WRAP_POINT_NO(old_pos-i)],
sizeof(struct ipipe_trace_point));
+
+ /* mark the end (i.e. the point before point[0]) invalid */
+ new_tp-point[IPIPE_TRACE_POINTS-1].eip = 0;
}
static notrace struct ipipe_trace_path *
@@ -436,21 +440,23 @@ void notrace ipipe_trace_special(unsigne
}
EXPORT_SYMBOL(ipipe_trace_special);
-void ipipe_trace_max_reset(void)
+int ipipe_trace_max_reset(void)
{
int cpu_id;
unsigned long flags;
struct ipipe_trace_path *path;
+ int ret = 0;
- /* only allowed from root domain (we sync with /proc routines) */
- if (ipipe_current_domain != ipipe_root_domain)
- return;
-
- down(out_mutex);
flags = __ipipe_global_path_lock();
for_each_cpu(cpu_id) {
path = trace_paths[cpu_id][max_path[cpu_id]];
+
+ if (path-dump_lock) {
+ ret = -EBUSY;
+ break;
+ }
+
path-begin = -1;
path-end = -1;
path-trace_pos = 0;
@@ -458,25 +464,28 @@ void ipipe_trace_max_reset(void)
}
__ipipe_global_path_unlock(flags);
- up(out_mutex);
+
+ return ret;
}
EXPORT_SYMBOL(ipipe_trace_max_reset);
-void ipipe_trace_frozen_reset(void)
+int ipipe_trace_frozen_reset(void)
{
int cpu_id;
unsigned long flags;
struct ipipe_trace_path *path;
+ int ret = 0;
- /* only allowed from root domain (we sync with /proc routines) */
- if (ipipe_current_domain != ipipe_root_domain)
- return;
-
- down(out_mutex);
flags = __ipipe_global_path_lock();
for_each_cpu(cpu_id) {
path = trace_paths[cpu_id][frozen_path[cpu_id]];
+
+ if (path-dump_lock) {
+ ret = -EBUSY;
+ break;
+ }
+
path-begin = -1;
path-end = -1;
path-trace_pos = 0;
@@ -484,7 +493,8 @@ void ipipe_trace_frozen_reset(void)
}
__ipipe_global_path_unlock(flags);
- up(out_mutex);
+
+ return ret;
}
EXPORT_SYMBOL(ipipe_trace_frozen_reset);
@@ -684,8 +694,10 @@ static int __ipipe_prtrace_show(struct s
unsigned long long abs_delta;
struct ipipe_trace_point *point = p;
- if (!point-eip)
+ if (!point-eip) {
+ seq_puts(m, -invalid-\n);
return 0;
+ }
/* ipipe_tsc2us works on unsigned = handle sign separately */
delta = point-timestamp -
@@ -749,7 +761,10 @@ static ssize_t
__ipipe_max_reset(struct file *file, const char __user *pbuffer,
size_t count, loff_t *data)
{
+ down(out_mutex);
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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, the wrong FPU
state might be saved to the task. The attached patch should fix this. I
couldn't try it on most recent Xenomai trunk, because latency wouldn't
build anymore. However, I see no reason it shouldn't work. All thee
having trouble with X and Xenomai, give this a shot.
Merged in r383, thanks.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/system.h
xenomai-devel/include/asm-powerpc/system.h
--- xenomai/include/asm-powerpc/system.h2006-01-06 15:55:19.0
+0200
+++ xenomai-devel/include/asm-powerpc/system.h 2006-01-06 16:44:53.0
+0200
@@ -55,6 +55,7 @@
rthal_fpenv_t fpuenv __attribute__ ((aligned (16)));
rthal_fpenv_t *fpup; /* Pointer to the FPU backup area */
struct task_struct *user_fpu_owner;
+unsigned long user_fpu_owner_prev_msr;
/* Pointer the the FPU owner in userspace:
- NULL for RT K threads,
- last_task_used_math for Linux US threads (only current or NULL when
MP)
@@ -368,7 +369,10 @@
rthal_save_fpu(tcb-fpup);
if(tcb-user_fpu_owner tcb-user_fpu_owner-thread.regs)
+{
+tcb-user_fpu_owner_prev_msr =
tcb-user_fpu_owner-thread.regs-msr;
tcb-user_fpu_owner-thread.regs-msr = ~MSR_FP;
+}
}
#endif /* CONFIG_XENO_HW_FPU */
@@ -383,7 +387,13 @@
{
rthal_restore_fpu(tcb-fpup);
-if(tcb-user_fpu_owner tcb-user_fpu_owner-thread.regs)
+ /* Note: Only enable FP in MSR, if it was enabled when we saved the
+* fpu state. We might have preempted Linux when it had disabled FP
+ * for the thread, but not yet set last_task_used_math to NULL
+ */
+if(tcb-user_fpu_owner
+ tcb-user_fpu_owner-thread.regs
+ ((tcb-user_fpu_owner_prev_msr MSR_FP) != 0))
tcb-user_fpu_owner-thread.regs-msr |= MSR_FP;
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] move RTDM headers
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 installed. Successfully
built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against
it without problems (x86, PPC is currently being fixed by Wolfgang).
Please apply/move the involved headers and run bootstrap.
Applied, thanks.
Jan
Index: include/rtdm/device.h
===
--- include/rtdm/device.h (Revision 380)
+++ include/rtdm/device.h (Arbeitskopie)
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_DEVICE_H
-#define _RTDM_DEVICE_H
-
-#include xenomai/nucleus/pod.h
-#include xenomai/rtdm/rtdm_driver.h
-#include linux/sem.h
-
-
-#define DEF_DEVNAME_HASHTAB_SIZE256 /* entries in name hash table */
-#define DEF_PROTO_HASHTAB_SIZE 256 /* entries in protocol hash table */
-
-
-extern struct semaphore nrt_dev_lock;
-extern xnlock_t rt_dev_lock;
-
-extern unsigned int devname_hashtab_size;
-extern unsigned int protocol_hashtab_size;
-
-extern struct list_head *rtdm_named_devices;
-extern struct list_head *rtdm_protocol_devices;
-
-
-int rtdm_no_support(void);
-
-struct rtdm_device *get_named_device(const char *name);
-struct rtdm_device *get_protocol_device(int protocol_family, int socket_type);
-
-static inline void rtdm_dereference_device(struct rtdm_device *device)
-{
-atomic_dec(device-reserved.refcount);
-}
-
-int __init rtdm_dev_init(void);
-
-static inline void rtdm_dev_cleanup(void)
-{
-kfree(rtdm_named_devices);
-kfree(rtdm_protocol_devices);
-}
-
-#endif /* _RTDM_DEVICE_H */
Index: include/rtdm/Makefile.am
===
--- include/rtdm/Makefile.am(Revision 380)
+++ include/rtdm/Makefile.am(Arbeitskopie)
@@ -1,11 +1,10 @@
includedir = $(prefix)/include/rtdm
+noinst_HEADERS = \
+ syscall.h
+
include_HEADERS = \
- core.h \
- device.h \
- proc.h \
rtdm.h \
rtdm_driver.h \
rtserial.h \
- syscall.h \
rtbenchmark.h
Index: include/rtdm/proc.h
===
--- include/rtdm/proc.h (Revision 380)
+++ include/rtdm/proc.h (Arbeitskopie)
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_PROC_H
-#define _RTDM_PROC_H
-
-extern struct proc_dir_entry *rtdm_proc_root;
-
-
-int rtdm_proc_register_device(struct rtdm_device* device);
-
-int __init rtdm_proc_init(void);
-
-void rtdm_proc_cleanup(void);
-
-#endif /* _RTDM_PROC_H */
Index: include/rtdm/core.h
===
--- include/rtdm/core.h (Revision 380)
+++ include/rtdm/core.h (Arbeitskopie)
@@ -1,52 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at
[Xenomai-core] Re: [PATCH] move RTDM headers
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] move RTDM headers
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 installed. Successfully
built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against
it without problems (x86, PPC is currently being fixed by Wolfgang).
Please apply/move the involved headers and run bootstrap.
This one broke the build here:
--
CC kernel/xenomai/skins/rtdm/core.o
kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory
kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory
--
Additionally, it's a really very bad idea to start including things like
core.h removing the rtdm/ prefix, while other include files like
nucleus/core.h exist. For the sake of readability, I'm going to revert
this particular change at least.
Jan
Index: include/rtdm/device.h
===
--- include/rtdm/device.h (Revision 380)
+++ include/rtdm/device.h (Arbeitskopie)
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_DEVICE_H
-#define _RTDM_DEVICE_H
-
-#include xenomai/nucleus/pod.h
-#include xenomai/rtdm/rtdm_driver.h
-#include linux/sem.h
-
-
-#define DEF_DEVNAME_HASHTAB_SIZE256 /* entries in name hash table */
-#define DEF_PROTO_HASHTAB_SIZE 256 /* entries in protocol hash table */
-
-
-extern struct semaphore nrt_dev_lock;
-extern xnlock_t rt_dev_lock;
-
-extern unsigned int devname_hashtab_size;
-extern unsigned int protocol_hashtab_size;
-
-extern struct list_head *rtdm_named_devices;
-extern struct list_head *rtdm_protocol_devices;
-
-
-int rtdm_no_support(void);
-
-struct rtdm_device *get_named_device(const char *name);
-struct rtdm_device *get_protocol_device(int protocol_family, int socket_type);
-
-static inline void rtdm_dereference_device(struct rtdm_device *device)
-{
-atomic_dec(device-reserved.refcount);
-}
-
-int __init rtdm_dev_init(void);
-
-static inline void rtdm_dev_cleanup(void)
-{
-kfree(rtdm_named_devices);
-kfree(rtdm_protocol_devices);
-}
-
-#endif /* _RTDM_DEVICE_H */
Index: include/rtdm/Makefile.am
===
--- include/rtdm/Makefile.am(Revision 380)
+++ include/rtdm/Makefile.am(Arbeitskopie)
@@ -1,11 +1,10 @@
includedir = $(prefix)/include/rtdm
+noinst_HEADERS = \
+ syscall.h
+
include_HEADERS = \
- core.h \
- device.h \
- proc.h \
rtdm.h \
rtdm_driver.h \
rtserial.h \
- syscall.h \
rtbenchmark.h
Index: include/rtdm/proc.h
===
--- include/rtdm/proc.h (Revision 380)
+++ include/rtdm/proc.h (Arbeitskopie)
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_PROC_H
-#define _RTDM_PROC_H
-
-extern struct proc_dir_entry *rtdm_proc_root;
-
-
-int rtdm_proc_register_device(struct rtdm_device* device);
-
-int __init rtdm_proc_init(void);
-
-void rtdm_proc_cleanup(void);
-
-#endif /* _RTDM_PROC_H */
Index: include/rtdm/core.h
[Xenomai-core] Re: [PATCH] move RTDM headers
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 for building Xenomai itself, thus it will not be installed. Successfully built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against it without problems (x86, PPC is currently being fixed by Wolfgang). Please apply/move the involved headers and run bootstrap. This one broke the build here: -- CC kernel/xenomai/skins/rtdm/core.o kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory -- Updated your repos? As you forgot to apply the moving, I also got problems and applied my local versions of core.h, device.h, and proc.h, also removing the three from their previous location. The problem is that the patch does not recreate those files in ksrc/skin/rtdm, but only deletes them from include/rtdm. Additionally, it's a really very bad idea to start including things like core.h removing the rtdm/ prefix, while other include files like nucleus/core.h exist. For the sake of readability, I'm going to revert this particular change at least. That's why I use #include core.h, which -for me- clearly states: Pick the local one! Nope, it states pick the first one you find outside of the system dirs depending on the order of the directories listed by -I in your Makefile, which is quite different, and leads to all sort of braindamage issues if you happen to screw up your CFLAGS in your Makefile. You will now have to tweak the Makefiles again... That's ok, I will do that. The prefix rule is enforced everywhere for internal headers so that nobody gets mad trying to find why the wrong one is included, and the best way not to depend on -I pecularities is to avoid playing with them in the first place. Additionally, this leaves no doubt about which header you wanted to include, regardless of the sanity of your Makefile. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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 it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Merged in r383, thanks. On a related note, how do you think patches to Linux kernel that don't fit into I-pipe should be handled? Put into patches directory separately? There are now at least two instances for 2.6.14/ppc: the fpu bug that I already posted on this thread and the ppc64 UP building bug that effectively makes impossible to build I-pipe 2.6.14 for UP on ppc64. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Known limitations are: (...) - for an unknown reason, xenomai modules are built every time prepare-kernel.sh is run ; The reason for this limitation is that prepare-kernel.sh remove directories before re-creating them and before creating symbolic links. The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. -- Gilles Chanteperdrix. xeno-build-kernel.diff Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] reset tracer after timer calibration
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. Actually, there is another noise source: rthal_timer_request() for the APIC case. But I think we should let this one alone as the user may trigger millisecond latencies by accidentally restarting the timer while some external-IRQ-driven device still depends on low latencies. In that case, the tracer can provide helpful hints. Therefore, in order to get useful information after starting the timer, one always have to run echo /proc/ipipe/trace/max first. Well, if we move the timer start to some module init or whatever phase also for the native skin, we should reconsider this exclusion. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] move RTDM headers
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 there. The latter is still only needed for building Xenomai itself, thus it will not be installed. Successfully built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against it without problems (x86, PPC is currently being fixed by Wolfgang). Please apply/move the involved headers and run bootstrap. This one broke the build here: -- CC kernel/xenomai/skins/rtdm/core.o kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory -- Updated your repos? As you forgot to apply the moving, I also got problems and applied my local versions of core.h, device.h, and proc.h, also removing the three from their previous location. The problem is that the patch does not recreate those files in ksrc/skin/rtdm, but only deletes them from include/rtdm. Oops, indeed. I was sure svn diff will include locally added files in the output, but it didn't -- ah, my svn version is too old! :) Additionally, it's a really very bad idea to start including things like core.h removing the rtdm/ prefix, while other include files like nucleus/core.h exist. For the sake of readability, I'm going to revert this particular change at least. That's why I use #include core.h, which -for me- clearly states: Pick the local one! Nope, it states pick the first one you find outside of the system dirs depending on the order of the directories listed by -I in your Makefile, which is quite different, and leads to all sort of braindamage issues if you happen to screw up your CFLAGS in your Makefile. #include file.h - start searching for file.h in that place you found the file containing this statement. Likely one can overwrite this behaviour with some strange gcc flags. -I- for instance, which bluntly cancels the above behaviour. One sometimes may have to make extensive use of it to work around funky include directory layouts some applications have; early versions of the simulator had even needed this to somewhat control which portion of the include space was picked. You will now have to tweak the Makefiles again... That's ok, I will do that. The prefix rule is enforced everywhere for internal headers so that nobody gets mad trying to find why the wrong one is included, and the best way not to depend on -I pecularities is to avoid playing with them in the first place. Additionally, this leaves no doubt about which header you wanted to include, regardless of the sanity of your Makefile. Ok, it's a matter of taste, and if you like to keep it this way for all skins, I'm fine with it. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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 it should be cleared. If the task
happens to hit one of the codepaths that save FPU state if MSR_FP
is set, the wrong FPU state might be saved to the task. The
attached patch should fix this. I couldn't try it on most recent
Xenomai trunk, because latency wouldn't build anymore. However, I
see no reason it shouldn't work. All thee having trouble with X and
Xenomai, give this a shot.
Merged in r383, thanks.
On a related note, how do you think patches to Linux kernel that
don't fit into I-pipe should be handled? Put into patches directory
separately? There are now at least two instances for 2.6.14/ppc: the
fpu bug that I already posted on this thread and the ppc64 UP
building bug that effectively makes impossible to build I-pipe 2.6.14
for UP on ppc64.
I'm going to put those patches on GNA, so that people can access to
them easily. I'm going to add a fix for x86 too, which is needed at
least on one of my boxen since 2.6.13 to make the PCI setup correct
again.
Is this patch still the right one to fix the UP build on ppc64?
http://patchwork.ozlabs.org/linuxppc64/patchcontent?id=3178
Yep. That makes it build. But catenate it with the following and it'll
boot, too ;)
Ah! Great release. Mm, do we need another one in order to use it on a
console shell, or should we only telnet to the G5 and look at the syslog
for bash output? :o
-- Heikki Lindholm
diff -Nru linux-2.6.14/arch/ppc64/kernel/prom.c
linux-2.6.14-dev/arch/ppc64/kernel/prom.c
--- linux-2.6.14/arch/ppc64/kernel/prom.c 2005-10-28 03:02:08.0
+0300
+++ linux-2.6.14-dev/arch/ppc64/kernel/prom.c 2005-11-06 14:14:07.0
+0200
@@ -1019,6 +1019,7 @@
*/
boot_cpuid_phys = initial_boot_params-boot_cpuid_phys;
boot_cpuid = 0;
+ set_hard_smp_processor_id(boot_cpuid, boot_cpuid_phys);
} else {
/* Check if it's the boot-cpu, set it's hw index in paca now */
if (get_flat_dt_prop(node, linux,boot-cpu, NULL) != NULL) {
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] reset tracer after timer calibration
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 case. But I think we should let this one alone as the user may trigger millisecond latencies by accidentally restarting the timer while some external-IRQ-driven device still depends on low latencies. In that case, the tracer can provide helpful hints. Therefore, in order to get useful information after starting the timer, one always have to run echo /proc/ipipe/trace/max first. Well, if we move the timer start to some module init or whatever phase also for the native skin, we should reconsider this exclusion. We will do that right after -rc2, which is close now. Jan and *with* the attachement... Index: ChangeLog === --- ChangeLog (Revision 388) +++ ChangeLog (Arbeitskopie) @@ -7,6 +7,8 @@ src/testsuite/latency/latency.c: Add re-freeze support and make use of it to back-trace always the max latency during benchmarks. + * ksrc/arch/i386/hal.c: reset tracer after timer calibration. + 2006-01-07 Heikki Lindholm [EMAIL PROTECTED] * include/asm-powerpc/system.h: Fix FPU preemption bug. Index: ksrc/arch/i386/hal.c === --- ksrc/arch/i386/hal.c(Revision 386) +++ ksrc/arch/i386/hal.c(Arbeitskopie) @@ -61,6 +61,9 @@ #endif /* CONFIG_X86_LOCAL_APIC */ #include asm/xenomai/hal.h #include stdarg.h +#ifdef CONFIG_IPIPE_TRACE +#include linux/ipipe_trace.h +#endif /* CONFIG_IPIPE_TRACE */ extern struct desc_struct idt_table[]; @@ -177,6 +180,11 @@ rthal_critical_exit(flags); +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +/* reset the max trace, it contains the excessive calibration now */ +ipipe_trace_max_reset(); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + return rthal_imuldiv(dt,10,RTHAL_CPU_FREQ); } @@ -345,6 +353,11 @@ rthal_critical_exit(flags); +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +/* reset the max trace, it contains the excessive calibration now */ +ipipe_trace_max_reset(); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + return rthal_imuldiv(dt,10,RTHAL_CPU_FREQ); } -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process: you prepare and build the kernel + the userspace stuff again in one step?. But you still have to configure both parts separately. The question for me is now if this simplifies the situation expecially for beginners. So far, the separation was clearly visible, now it /may/ become blurred (but I'm not a beginner...). Can you provide a rough comparision of the workflows? Sorry, but I'm too lazy, I mean busy to give it a try. configure --enable-linux-build make xconfig make install If you already have a .config file, the make xconfig step becomes optional. Note that the --enable-linux-build flag is optional too. The simplification is mainly for developping xenomai itself, not for its users. Because with the current scheme, after some modifications, you have to recompile and reinstall both the kernel-space modules and user-space libraries. If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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 anyone is interested in looking at my config (stock Ubuntu with defaults taken on all new oldconfig questions), I am attaching it here. You may want to try this one: http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.1-03.patch -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process: you prepare and build the kernel + the userspace stuff again in one step?. But you still have to configure both parts separately. The question for me is now if this simplifies the situation expecially for beginners. So far, the separation was clearly visible, now it /may/ become blurred (but I'm not a beginner...). Can you provide a rough comparision of the workflows? Sorry, but I'm too lazy, I mean busy to give it a try. configure --enable-linux-build make xconfig make install I'm starting to like this! If you already have a .config file, the make xconfig step becomes optional. Note that the --enable-linux-build flag is optional too. The simplification is mainly for developping xenomai itself, not for its users. Because with the current scheme, after some modifications, you have to recompile and reinstall both the kernel-space modules and user-space libraries. If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. Hmm, what about this: Instead of leaving some (probably empty) xenomai-prepared in the kernel tree, better create an xenomai-uninstall script in the same place. It a) can serve as an indication for a prepared kernel and b) can be used to upgrade that tree by first running it and then applying the usual steps on the kernel again. I often forget to save my old adeos patch before updating the xenomai tree, thus I will then have to download the old patch again, reverse-apply it, and can finally run the prepare script for the update. Automating this would be REALLY, REALLY GREAT! Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Two patches for the documentation
Hi xeno.sim.patch contains some clarification on how to build the xenoscope. (GCC 3.4 worked for me on a x86 system, but with a lot of warnings, that fwritable is deprecated) xeno.patch is a shorter way how to cross-compile using the CROSS_COMPILE variable. It worked for me without any problems for my board. Also contains a hint to use O=../a-build-dir to compile the linux kernel. Best regards -- Niklaus Giger Index: README.INSTALL === --- README.INSTALL (Revision 392) +++ README.INSTALL (Arbeitskopie) @@ -150,20 +150,22 @@ needed, but if you do not use it, configure emit a warning, which may be confusing. +The easiest way to build a GNU cross-compiler might involve using Dan Kegel +crosstools found at http://kegel.com/crosstool. + Since cross-compiling requires specific tools, such tools are generally prefixed with the host architecture name; for example, a compiler for the power PC -architecture may be named powerpc-linux-gcc. +architecture may be named powerpc-405-linux-gnu-gcc. -When this prefix contains the name of the architecture, you may pass this prefix -to the --host option of configure. For example, if you type : -configure --host=powerpc-linux - -configure will automatically use powerpc-linux- as a prefix too all compilation +configure will automatically use powerpc-405-linux-gnu- as a prefix too all compilation tools names and deduce the architecture name. If configure is unable to deduce the architecture name from this prefix, you will have to manually pass the name of all compilation tools on configure command line. As in: -configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +It might be a good idea to put all the output into a differen build directory +as to build from from linux source several targets. For each target add +O=../build-target to each make invocation. +configure CROSS_COMPILE=powerpc-405-linux-gnu- For more details: http://sourceware.org/autobook/autobook/autobook_264.html#SEC264 @@ -204,16 +206,18 @@ 2.2 Building for the PowerPC architecture A typical cross-compilation setup, in order to build Xenomai for a -82xx-based system: +PowerPC-405-based system: $ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ --linux=$linux_tree $ cd $linux_tree -$ make xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make bzImage modules # then install as needed +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +# select the kernel and Xenomai options +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules +# then install as needed $ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +$ $xenomai_root/configure CROSS_COMPILE=powerpc-405-linux-gnu- $ make install 2.3 Building for the IPF Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + +You will need the libelf, libpng, tcl8.x/tk8.x and tix81 _development packages_ in order to build the simulator and its companion tools. For instance, on Debian systems, you will need to install libelfg0-dev, libpng2-dev, tcl8.3-dev, tk8.3-dev and tix41-dev (any ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Problems cross-compiling for PPC405
Hi I just upgraded to revision 392 of xenomai and got the following error trying to compile the linux 2.6.14 kernel CC kernel/xenomai/nucleus/heap.o /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1017:1: pasting , and args does not give a valid preprocessing token /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c: In function `xnheap_mount': /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: `args' undeclared (first use in this function) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: (Each undeclared identifier is reported only once /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: for each function it appears in.) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: warning: too many arguments for format make[4]: *** [kernel/xenomai/nucleus/heap.o] Fehler 1 make[3]: *** [kernel/xenomai/nucleus] Fehler 2 make[2]: *** [kernel/xenomai] Fehler 2 make[1]: *** [kernel] Fehler 2 I am using GCC 3.4.4. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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 `ret_from_intr' arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' make: *** [.tmp_vmlinux1] Error 1 ~/linux-2.6.15$ For a .config I started with the stock Ubuntu 2.6.12-10-686 config file and then took the defaults for all the oldconfig questions. Suggestions? You get to keep both pieces ? ;-) FWIW, the kernel was still running on my soekris 4801 til just now. (I rebooted) Most of that time it was without its NFS root fs; my laptop was unconnected. It was doing *no* work of any kind tho. Not that this helps... Im trying a kernel build on my sony laptop pentium M. differnt config than yours, but fuller than the soekris. Its running now, Im typing on it. wifi card works too ! Ive attached my working config - might get you going. pls report back what made your config not work, once you find it. :: ipipe/Linux :: Priority=100, Id=0x irq0-15: accepted irq32: grabbed, virtual :: ipipe/version :: 1.1-01 FWIW, I diffed the 14 patch against mine, was puzzled at the large textual diffs. Guessed that it was a file ordering diff in the tar, and then forgot to mention this at send. This seems kinda odd, since Im running linux. Phillipe, are you running BSD ? /ducks Are you creating patches from an fs other than ext3 ? That could explain the ordering. If not, Im stumped. Maybe its an svn thing, they have a berkley-db-as-fs dont they ? hth, jimc Also, FWIW, Ive been reading LKML, and it appears that Ingo Molnar's Mutex patches have turned the corner with Linux. Theyre not in, and Ive got no crystal ball, but I suspect they will get into 17 or 16 a good writeup for the regular folks (like me) on this list is here: http://lwn.net/Articles/164380/ config.gz Description: GNU Zip compressed data
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm kirjoitti: 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, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Additionally, there's also a Linux bug, which might cause corruption in 2.6.14 PREEMPT: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9f232a125bf86b0dae09f8ea4a0553535cf6b658 For solid performance that should also be applied on top of the I-pipe patch. -- Heikki Lindholm
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka 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 it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. Just tried. At least svn r380 compiled and worked fine for me. -- Heikki Lindholm
[Xenomai-core] [PATCH] move RTDM headers
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 installed. Successfully
built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against
it without problems (x86, PPC is currently being fixed by Wolfgang).
Please apply/move the involved headers and run bootstrap.
Jan
Index: include/rtdm/device.h
===
--- include/rtdm/device.h (Revision 380)
+++ include/rtdm/device.h (Arbeitskopie)
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_DEVICE_H
-#define _RTDM_DEVICE_H
-
-#include xenomai/nucleus/pod.h
-#include xenomai/rtdm/rtdm_driver.h
-#include linux/sem.h
-
-
-#define DEF_DEVNAME_HASHTAB_SIZE256 /* entries in name hash table */
-#define DEF_PROTO_HASHTAB_SIZE 256 /* entries in protocol hash table */
-
-
-extern struct semaphore nrt_dev_lock;
-extern xnlock_t rt_dev_lock;
-
-extern unsigned int devname_hashtab_size;
-extern unsigned int protocol_hashtab_size;
-
-extern struct list_head *rtdm_named_devices;
-extern struct list_head *rtdm_protocol_devices;
-
-
-int rtdm_no_support(void);
-
-struct rtdm_device *get_named_device(const char *name);
-struct rtdm_device *get_protocol_device(int protocol_family, int socket_type);
-
-static inline void rtdm_dereference_device(struct rtdm_device *device)
-{
-atomic_dec(device-reserved.refcount);
-}
-
-int __init rtdm_dev_init(void);
-
-static inline void rtdm_dev_cleanup(void)
-{
-kfree(rtdm_named_devices);
-kfree(rtdm_protocol_devices);
-}
-
-#endif /* _RTDM_DEVICE_H */
Index: include/rtdm/Makefile.am
===
--- include/rtdm/Makefile.am (Revision 380)
+++ include/rtdm/Makefile.am (Arbeitskopie)
@@ -1,11 +1,10 @@
includedir = $(prefix)/include/rtdm
+noinst_HEADERS = \
+ syscall.h
+
include_HEADERS = \
- core.h \
- device.h \
- proc.h \
rtdm.h \
rtdm_driver.h \
rtserial.h \
- syscall.h \
rtbenchmark.h
Index: include/rtdm/proc.h
===
--- include/rtdm/proc.h (Revision 380)
+++ include/rtdm/proc.h (Arbeitskopie)
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_PROC_H
-#define _RTDM_PROC_H
-
-extern struct proc_dir_entry *rtdm_proc_root;
-
-
-int rtdm_proc_register_device(struct rtdm_device* device);
-
-int __init rtdm_proc_init(void);
-
-void rtdm_proc_cleanup(void);
-
-#endif /* _RTDM_PROC_H */
Index: include/rtdm/core.h
===
--- include/rtdm/core.h (Revision 380)
+++ include/rtdm/core.h (Arbeitskopie)
@@ -1,52 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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, the wrong FPU
state might be saved to the task. The attached patch should fix this. I
couldn't try it on most recent Xenomai trunk, because latency wouldn't
build anymore. However, I see no reason it shouldn't work. All thee
having trouble with X and Xenomai, give this a shot.
Merged in r383, thanks.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/system.h
xenomai-devel/include/asm-powerpc/system.h
--- xenomai/include/asm-powerpc/system.h2006-01-06 15:55:19.0
+0200
+++ xenomai-devel/include/asm-powerpc/system.h 2006-01-06 16:44:53.0
+0200
@@ -55,6 +55,7 @@
rthal_fpenv_t fpuenv __attribute__ ((aligned (16)));
rthal_fpenv_t *fpup; /* Pointer to the FPU backup area */
struct task_struct *user_fpu_owner;
+unsigned long user_fpu_owner_prev_msr;
/* Pointer the the FPU owner in userspace:
- NULL for RT K threads,
- last_task_used_math for Linux US threads (only current or NULL when
MP)
@@ -368,7 +369,10 @@
rthal_save_fpu(tcb-fpup);
if(tcb-user_fpu_owner tcb-user_fpu_owner-thread.regs)
+{
+tcb-user_fpu_owner_prev_msr =
tcb-user_fpu_owner-thread.regs-msr;
tcb-user_fpu_owner-thread.regs-msr = ~MSR_FP;
+}
}
#endif /* CONFIG_XENO_HW_FPU */
@@ -383,7 +387,13 @@
{
rthal_restore_fpu(tcb-fpup);
-if(tcb-user_fpu_owner tcb-user_fpu_owner-thread.regs)
+ /* Note: Only enable FP in MSR, if it was enabled when we saved the
+* fpu state. We might have preempted Linux when it had disabled FP
+ * for the thread, but not yet set last_task_used_math to NULL
+ */
+if(tcb-user_fpu_owner
+ tcb-user_fpu_owner-thread.regs
+ ((tcb-user_fpu_owner_prev_msr MSR_FP) != 0))
tcb-user_fpu_owner-thread.regs-msr |= MSR_FP;
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
Re: [Xenomai-core] Re: [PATCH] latency tracer update
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 unterminated trace on a different machine. So, no need
to hurry with the merge (not the review! ;) ), I will publish a second
revision first.
And here comes this revision finally. Should apply (almost) cleanly
against latest ipipe versions. Additionally to the changes of the first
revision this one addresses the following topics:
o fix trace overrun handling
o report IRQ number to tracer on IRQ entry/exit
o fix virtually leaking IRQs-off in __ipipe_unstall_iret_root()
o fix another potential NMI race
o really trace the maximum IRQs-off time, not the maximum time of
consecutive IRQs-off times (that scenario will soon be addressed
instead in the latency benchmark tool = resetfreeze the maximum
latency from the user's point of view)
...and it turned out that the existing functions were no sufficient for
this. So here comes an add-on patch to update3:
o allow ipipe_trace_{frozen|max}_reset from every context
(well, at least give it a try and just fail on locked traces)
o mark border between valid and invalid trace points
o show invalid points border
Apply order:
ipipe_tracer.update3
ipipe_tracer.update3-1
Merged in 1.1-03, with the appropriate tracer patch. Thanks.
The front-end to the first change, a modified latency+timerbench will
get committed to Xenomai soon. It already works nicely, automatically
creating a freeze of the maximum latency turn the benchmark perceives.
Jan
--- linux-2.6.14.3/kernel/ipipe/tracer.c.orig 2006-01-06 11:13:41.0
+0100
+++ linux-2.6.14.3/kernel/ipipe/tracer.c2006-01-06 20:11:10.0
+0100
@@ -134,10 +134,14 @@ __ipipe_migrate_pre_trace(struct ipipe_t
int i;
new_tp-trace_pos = pre_trace+1;
+
for (i = new_tp-trace_pos; i 0; i--)
memcpy(new_tp-point[WRAP_POINT_NO(new_tp-trace_pos-i)],
old_tp-point[WRAP_POINT_NO(old_pos-i)],
sizeof(struct ipipe_trace_point));
+
+ /* mark the end (i.e. the point before point[0]) invalid */
+ new_tp-point[IPIPE_TRACE_POINTS-1].eip = 0;
}
static notrace struct ipipe_trace_path *
@@ -436,21 +440,23 @@ void notrace ipipe_trace_special(unsigne
}
EXPORT_SYMBOL(ipipe_trace_special);
-void ipipe_trace_max_reset(void)
+int ipipe_trace_max_reset(void)
{
int cpu_id;
unsigned long flags;
struct ipipe_trace_path *path;
+ int ret = 0;
- /* only allowed from root domain (we sync with /proc routines) */
- if (ipipe_current_domain != ipipe_root_domain)
- return;
-
- down(out_mutex);
flags = __ipipe_global_path_lock();
for_each_cpu(cpu_id) {
path = trace_paths[cpu_id][max_path[cpu_id]];
+
+ if (path-dump_lock) {
+ ret = -EBUSY;
+ break;
+ }
+
path-begin = -1;
path-end = -1;
path-trace_pos = 0;
@@ -458,25 +464,28 @@ void ipipe_trace_max_reset(void)
}
__ipipe_global_path_unlock(flags);
- up(out_mutex);
+
+ return ret;
}
EXPORT_SYMBOL(ipipe_trace_max_reset);
-void ipipe_trace_frozen_reset(void)
+int ipipe_trace_frozen_reset(void)
{
int cpu_id;
unsigned long flags;
struct ipipe_trace_path *path;
+ int ret = 0;
- /* only allowed from root domain (we sync with /proc routines) */
- if (ipipe_current_domain != ipipe_root_domain)
- return;
-
- down(out_mutex);
flags = __ipipe_global_path_lock();
for_each_cpu(cpu_id) {
path = trace_paths[cpu_id][frozen_path[cpu_id]];
+
+ if (path-dump_lock) {
+ ret = -EBUSY;
+ break;
+ }
+
path-begin = -1;
path-end = -1;
path-trace_pos = 0;
@@ -484,7 +493,8 @@ void ipipe_trace_frozen_reset(void)
}
__ipipe_global_path_unlock(flags);
- up(out_mutex);
+
+ return ret;
}
EXPORT_SYMBOL(ipipe_trace_frozen_reset);
@@ -684,8 +694,10 @@ static int __ipipe_prtrace_show(struct s
unsigned long long abs_delta;
struct ipipe_trace_point *point = p;
- if (!point-eip)
+ if (!point-eip) {
+ seq_puts(m, -invalid-\n);
return 0;
+ }
/* ipipe_tsc2us works on unsigned = handle sign separately */
delta = point-timestamp -
@@ -749,7 +761,10 @@ static ssize_t
__ipipe_max_reset(struct file *file, const char __user *pbuffer,
size_t count, loff_t *data)
{
+ down(out_mutex);
[Xenomai-core] Re: [PATCH] move RTDM headers
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 installed. Successfully
built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against
it without problems (x86, PPC is currently being fixed by Wolfgang).
Please apply/move the involved headers and run bootstrap.
Applied, thanks.
Jan
Index: include/rtdm/device.h
===
--- include/rtdm/device.h (Revision 380)
+++ include/rtdm/device.h (Arbeitskopie)
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_DEVICE_H
-#define _RTDM_DEVICE_H
-
-#include xenomai/nucleus/pod.h
-#include xenomai/rtdm/rtdm_driver.h
-#include linux/sem.h
-
-
-#define DEF_DEVNAME_HASHTAB_SIZE256 /* entries in name hash table */
-#define DEF_PROTO_HASHTAB_SIZE 256 /* entries in protocol hash table */
-
-
-extern struct semaphore nrt_dev_lock;
-extern xnlock_t rt_dev_lock;
-
-extern unsigned int devname_hashtab_size;
-extern unsigned int protocol_hashtab_size;
-
-extern struct list_head *rtdm_named_devices;
-extern struct list_head *rtdm_protocol_devices;
-
-
-int rtdm_no_support(void);
-
-struct rtdm_device *get_named_device(const char *name);
-struct rtdm_device *get_protocol_device(int protocol_family, int socket_type);
-
-static inline void rtdm_dereference_device(struct rtdm_device *device)
-{
-atomic_dec(device-reserved.refcount);
-}
-
-int __init rtdm_dev_init(void);
-
-static inline void rtdm_dev_cleanup(void)
-{
-kfree(rtdm_named_devices);
-kfree(rtdm_protocol_devices);
-}
-
-#endif /* _RTDM_DEVICE_H */
Index: include/rtdm/Makefile.am
===
--- include/rtdm/Makefile.am(Revision 380)
+++ include/rtdm/Makefile.am(Arbeitskopie)
@@ -1,11 +1,10 @@
includedir = $(prefix)/include/rtdm
+noinst_HEADERS = \
+ syscall.h
+
include_HEADERS = \
- core.h \
- device.h \
- proc.h \
rtdm.h \
rtdm_driver.h \
rtserial.h \
- syscall.h \
rtbenchmark.h
Index: include/rtdm/proc.h
===
--- include/rtdm/proc.h (Revision 380)
+++ include/rtdm/proc.h (Arbeitskopie)
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_PROC_H
-#define _RTDM_PROC_H
-
-extern struct proc_dir_entry *rtdm_proc_root;
-
-
-int rtdm_proc_register_device(struct rtdm_device* device);
-
-int __init rtdm_proc_init(void);
-
-void rtdm_proc_cleanup(void);
-
-#endif /* _RTDM_PROC_H */
Index: include/rtdm/core.h
===
--- include/rtdm/core.h (Revision 380)
+++ include/rtdm/core.h (Arbeitskopie)
@@ -1,52 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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 anyone is interested in looking at my config (stock Ubuntu with defaults taken on all new oldconfig questions), I am attaching it here. Thanks, -kb # # Automatically generated make config: don't edit # Linux kernel version: 2.6.15 # Fri Jan 6 15:57:32 2006 # CONFIG_X86_32=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_LBD=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_IPIPE=y # CONFIG_IPIPE_STATS is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m CONFIG_X86_MCE_P4THERMAL=y CONFIG_TOSHIBA=m CONFIG_I8K=m CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_SLEEP_PROC_SLEEP=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_HOTKEY=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m
[Xenomai-core] Re: [PATCH] move RTDM headers
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 installed. Successfully
built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against
it without problems (x86, PPC is currently being fixed by Wolfgang).
Please apply/move the involved headers and run bootstrap.
This one broke the build here:
--
CC kernel/xenomai/skins/rtdm/core.o
kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory
kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory
--
Additionally, it's a really very bad idea to start including things like
core.h removing the rtdm/ prefix, while other include files like
nucleus/core.h exist. For the sake of readability, I'm going to revert
this particular change at least.
Jan
Index: include/rtdm/device.h
===
--- include/rtdm/device.h (Revision 380)
+++ include/rtdm/device.h (Arbeitskopie)
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_DEVICE_H
-#define _RTDM_DEVICE_H
-
-#include xenomai/nucleus/pod.h
-#include xenomai/rtdm/rtdm_driver.h
-#include linux/sem.h
-
-
-#define DEF_DEVNAME_HASHTAB_SIZE256 /* entries in name hash table */
-#define DEF_PROTO_HASHTAB_SIZE 256 /* entries in protocol hash table */
-
-
-extern struct semaphore nrt_dev_lock;
-extern xnlock_t rt_dev_lock;
-
-extern unsigned int devname_hashtab_size;
-extern unsigned int protocol_hashtab_size;
-
-extern struct list_head *rtdm_named_devices;
-extern struct list_head *rtdm_protocol_devices;
-
-
-int rtdm_no_support(void);
-
-struct rtdm_device *get_named_device(const char *name);
-struct rtdm_device *get_protocol_device(int protocol_family, int socket_type);
-
-static inline void rtdm_dereference_device(struct rtdm_device *device)
-{
-atomic_dec(device-reserved.refcount);
-}
-
-int __init rtdm_dev_init(void);
-
-static inline void rtdm_dev_cleanup(void)
-{
-kfree(rtdm_named_devices);
-kfree(rtdm_protocol_devices);
-}
-
-#endif /* _RTDM_DEVICE_H */
Index: include/rtdm/Makefile.am
===
--- include/rtdm/Makefile.am(Revision 380)
+++ include/rtdm/Makefile.am(Arbeitskopie)
@@ -1,11 +1,10 @@
includedir = $(prefix)/include/rtdm
+noinst_HEADERS = \
+ syscall.h
+
include_HEADERS = \
- core.h \
- device.h \
- proc.h \
rtdm.h \
rtdm_driver.h \
rtserial.h \
- syscall.h \
rtbenchmark.h
Index: include/rtdm/proc.h
===
--- include/rtdm/proc.h (Revision 380)
+++ include/rtdm/proc.h (Arbeitskopie)
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED].
- * Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED].
- *
- * Xenomai is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Xenomai is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with Xenomai; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef _RTDM_PROC_H
-#define _RTDM_PROC_H
-
-extern struct proc_dir_entry *rtdm_proc_root;
-
-
-int rtdm_proc_register_device(struct rtdm_device* device);
-
-int __init rtdm_proc_init(void);
-
-void rtdm_proc_cleanup(void);
-
-#endif /* _RTDM_PROC_H */
Index: include/rtdm/core.h
[Xenomai-core] Re: [PATCH] move RTDM headers
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 for building Xenomai itself, thus it will not be installed. Successfully built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against it without problems (x86, PPC is currently being fixed by Wolfgang). Please apply/move the involved headers and run bootstrap. This one broke the build here: -- CC kernel/xenomai/skins/rtdm/core.o kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory -- Updated your repos? As you forgot to apply the moving, I also got problems and applied my local versions of core.h, device.h, and proc.h, also removing the three from their previous location. Additionally, it's a really very bad idea to start including things like core.h removing the rtdm/ prefix, while other include files like nucleus/core.h exist. For the sake of readability, I'm going to revert this particular change at least. That's why I use #include core.h, which -for me- clearly states: Pick the local one! You will now have to tweak the Makefiles again... Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Re: [PATCH] move RTDM headers
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 for building Xenomai itself, thus it will not be installed. Successfully built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against it without problems (x86, PPC is currently being fixed by Wolfgang). Please apply/move the involved headers and run bootstrap. This one broke the build here: -- CC kernel/xenomai/skins/rtdm/core.o kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory -- Updated your repos? As you forgot to apply the moving, I also got problems and applied my local versions of core.h, device.h, and proc.h, also removing the three from their previous location. The problem is that the patch does not recreate those files in ksrc/skin/rtdm, but only deletes them from include/rtdm. Additionally, it's a really very bad idea to start including things like core.h removing the rtdm/ prefix, while other include files like nucleus/core.h exist. For the sake of readability, I'm going to revert this particular change at least. That's why I use #include core.h, which -for me- clearly states: Pick the local one! Nope, it states pick the first one you find outside of the system dirs depending on the order of the directories listed by -I in your Makefile, which is quite different, and leads to all sort of braindamage issues if you happen to screw up your CFLAGS in your Makefile. You will now have to tweak the Makefiles again... That's ok, I will do that. The prefix rule is enforced everywhere for internal headers so that nobody gets mad trying to find why the wrong one is included, and the best way not to depend on -I pecularities is to avoid playing with them in the first place. Additionally, this leaves no doubt about which header you wanted to include, regardless of the sanity of your Makefile. Jan -- Philippe.
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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 it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Merged in r383, thanks. On a related note, how do you think patches to Linux kernel that don't fit into I-pipe should be handled? Put into patches directory separately? There are now at least two instances for 2.6.14/ppc: the fpu bug that I already posted on this thread and the ppc64 UP building bug that effectively makes impossible to build I-pipe 2.6.14 for UP on ppc64. -- Heikki Lindholm
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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 it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Merged in r383, thanks. On a related note, how do you think patches to Linux kernel that don't fit into I-pipe should be handled? Put into patches directory separately? There are now at least two instances for 2.6.14/ppc: the fpu bug that I already posted on this thread and the ppc64 UP building bug that effectively makes impossible to build I-pipe 2.6.14 for UP on ppc64. I'm going to put those patches on GNA, so that people can access to them easily. I'm going to add a fix for x86 too, which is needed at least on one of my boxen since 2.6.13 to make the PCI setup correct again. Is this patch still the right one to fix the UP build on ppc64? http://patchwork.ozlabs.org/linuxppc64/patchcontent?id=3178 -- Heikki Lindholm -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Known limitations are: (...) - for an unknown reason, xenomai modules are built every time prepare-kernel.sh is run ; The reason for this limitation is that prepare-kernel.sh remove directories before re-creating them and before creating symbolic links. The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. -- Gilles Chanteperdrix. xeno-build-kernel.diff Description: Binary data
[Xenomai-core] [PATCH] reset tracer after timer calibration
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. Actually, there is another noise source: rthal_timer_request() for the APIC case. But I think we should let this one alone as the user may trigger millisecond latencies by accidentally restarting the timer while some external-IRQ-driven device still depends on low latencies. In that case, the tracer can provide helpful hints. Therefore, in order to get useful information after starting the timer, one always have to run echo /proc/ipipe/trace/max first. Well, if we move the timer start to some module init or whatever phase also for the native skin, we should reconsider this exclusion. Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Re: [PATCH] move RTDM headers
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 there. The latter is still only needed for building Xenomai itself, thus it will not be installed. Successfully built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN against it without problems (x86, PPC is currently being fixed by Wolfgang). Please apply/move the involved headers and run bootstrap. This one broke the build here: -- CC kernel/xenomai/skins/rtdm/core.o kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or directory kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or directory -- Updated your repos? As you forgot to apply the moving, I also got problems and applied my local versions of core.h, device.h, and proc.h, also removing the three from their previous location. The problem is that the patch does not recreate those files in ksrc/skin/rtdm, but only deletes them from include/rtdm. Oops, indeed. I was sure svn diff will include locally added files in the output, but it didn't -- ah, my svn version is too old! :) Additionally, it's a really very bad idea to start including things like core.h removing the rtdm/ prefix, while other include files like nucleus/core.h exist. For the sake of readability, I'm going to revert this particular change at least. That's why I use #include core.h, which -for me- clearly states: Pick the local one! Nope, it states pick the first one you find outside of the system dirs depending on the order of the directories listed by -I in your Makefile, which is quite different, and leads to all sort of braindamage issues if you happen to screw up your CFLAGS in your Makefile. #include file.h - start searching for file.h in that place you found the file containing this statement. Likely one can overwrite this behaviour with some strange gcc flags. -I- for instance, which bluntly cancels the above behaviour. One sometimes may have to make extensive use of it to work around funky include directory layouts some applications have; early versions of the simulator had even needed this to somewhat control which portion of the include space was picked. You will now have to tweak the Makefiles again... That's ok, I will do that. The prefix rule is enforced everywhere for internal headers so that nobody gets mad trying to find why the wrong one is included, and the best way not to depend on -I pecularities is to avoid playing with them in the first place. Additionally, this leaves no doubt about which header you wanted to include, regardless of the sanity of your Makefile. Ok, it's a matter of taste, and if you like to keep it this way for all skins, I'm fine with it. Jan -- Philippe.
[Xenomai-core] Re: [PATCH] reset tracer after timer calibration
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. Actually, there is another noise source: rthal_timer_request() for the APIC case. But I think we should let this one alone as the user may trigger millisecond latencies by accidentally restarting the timer while some external-IRQ-driven device still depends on low latencies. In that case, the tracer can provide helpful hints. Therefore, in order to get useful information after starting the timer, one always have to run echo /proc/ipipe/trace/max first. Well, if we move the timer start to some module init or whatever phase also for the native skin, we should reconsider this exclusion. Jan and *with* the attachement... Index: ChangeLog === --- ChangeLog (Revision 388) +++ ChangeLog (Arbeitskopie) @@ -7,6 +7,8 @@ src/testsuite/latency/latency.c: Add re-freeze support and make use of it to back-trace always the max latency during benchmarks. + * ksrc/arch/i386/hal.c: reset tracer after timer calibration. + 2006-01-07 Heikki Lindholm [EMAIL PROTECTED] * include/asm-powerpc/system.h: Fix FPU preemption bug. Index: ksrc/arch/i386/hal.c === --- ksrc/arch/i386/hal.c (Revision 386) +++ ksrc/arch/i386/hal.c (Arbeitskopie) @@ -61,6 +61,9 @@ #endif /* CONFIG_X86_LOCAL_APIC */ #include asm/xenomai/hal.h #include stdarg.h +#ifdef CONFIG_IPIPE_TRACE +#include linux/ipipe_trace.h +#endif /* CONFIG_IPIPE_TRACE */ extern struct desc_struct idt_table[]; @@ -177,6 +180,11 @@ rthal_critical_exit(flags); +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +/* reset the max trace, it contains the excessive calibration now */ +ipipe_trace_max_reset(); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + return rthal_imuldiv(dt,10,RTHAL_CPU_FREQ); } @@ -345,6 +353,11 @@ rthal_critical_exit(flags); +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +/* reset the max trace, it contains the excessive calibration now */ +ipipe_trace_max_reset(); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + return rthal_imuldiv(dt,10,RTHAL_CPU_FREQ); } signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
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 it should be cleared. If the task
happens to hit one of the codepaths that save FPU state if MSR_FP
is set, the wrong FPU state might be saved to the task. The
attached patch should fix this. I couldn't try it on most recent
Xenomai trunk, because latency wouldn't build anymore. However, I
see no reason it shouldn't work. All thee having trouble with X and
Xenomai, give this a shot.
Merged in r383, thanks.
On a related note, how do you think patches to Linux kernel that
don't fit into I-pipe should be handled? Put into patches directory
separately? There are now at least two instances for 2.6.14/ppc: the
fpu bug that I already posted on this thread and the ppc64 UP
building bug that effectively makes impossible to build I-pipe 2.6.14
for UP on ppc64.
I'm going to put those patches on GNA, so that people can access to
them easily. I'm going to add a fix for x86 too, which is needed at
least on one of my boxen since 2.6.13 to make the PCI setup correct
again.
Is this patch still the right one to fix the UP build on ppc64?
http://patchwork.ozlabs.org/linuxppc64/patchcontent?id=3178
Yep. That makes it build. But catenate it with the following and it'll
boot, too ;)
Ah! Great release. Mm, do we need another one in order to use it on a
console shell, or should we only telnet to the G5 and look at the syslog
for bash output? :o
-- Heikki Lindholm
diff -Nru linux-2.6.14/arch/ppc64/kernel/prom.c
linux-2.6.14-dev/arch/ppc64/kernel/prom.c
--- linux-2.6.14/arch/ppc64/kernel/prom.c 2005-10-28 03:02:08.0
+0300
+++ linux-2.6.14-dev/arch/ppc64/kernel/prom.c 2005-11-06 14:14:07.0
+0200
@@ -1019,6 +1019,7 @@
*/
boot_cpuid_phys = initial_boot_params-boot_cpuid_phys;
boot_cpuid = 0;
+ set_hard_smp_processor_id(boot_cpuid, boot_cpuid_phys);
} else {
/* Check if it's the boot-cpu, set it's hw index in paca now */
if (get_flat_dt_prop(node, linux,boot-cpu, NULL) != NULL) {
--
Philippe.
[Xenomai-core] Re: [PATCH] reset tracer after timer calibration
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 case. But I think we should let this one alone as the user may trigger millisecond latencies by accidentally restarting the timer while some external-IRQ-driven device still depends on low latencies. In that case, the tracer can provide helpful hints. Therefore, in order to get useful information after starting the timer, one always have to run echo /proc/ipipe/trace/max first. Well, if we move the timer start to some module init or whatever phase also for the native skin, we should reconsider this exclusion. We will do that right after -rc2, which is close now. Jan and *with* the attachement... Index: ChangeLog === --- ChangeLog (Revision 388) +++ ChangeLog (Arbeitskopie) @@ -7,6 +7,8 @@ src/testsuite/latency/latency.c: Add re-freeze support and make use of it to back-trace always the max latency during benchmarks. + * ksrc/arch/i386/hal.c: reset tracer after timer calibration. + 2006-01-07 Heikki Lindholm [EMAIL PROTECTED] * include/asm-powerpc/system.h: Fix FPU preemption bug. Index: ksrc/arch/i386/hal.c === --- ksrc/arch/i386/hal.c(Revision 386) +++ ksrc/arch/i386/hal.c(Arbeitskopie) @@ -61,6 +61,9 @@ #endif /* CONFIG_X86_LOCAL_APIC */ #include asm/xenomai/hal.h #include stdarg.h +#ifdef CONFIG_IPIPE_TRACE +#include linux/ipipe_trace.h +#endif /* CONFIG_IPIPE_TRACE */ extern struct desc_struct idt_table[]; @@ -177,6 +180,11 @@ rthal_critical_exit(flags); +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +/* reset the max trace, it contains the excessive calibration now */ +ipipe_trace_max_reset(); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + return rthal_imuldiv(dt,10,RTHAL_CPU_FREQ); } @@ -345,6 +353,11 @@ rthal_critical_exit(flags); +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +/* reset the max trace, it contains the excessive calibration now */ +ipipe_trace_max_reset(); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + return rthal_imuldiv(dt,10,RTHAL_CPU_FREQ); } -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process: you prepare and build the kernel + the userspace stuff again in one step?. But you still have to configure both parts separately. The question for me is now if this simplifies the situation expecially for beginners. So far, the separation was clearly visible, now it /may/ become blurred (but I'm not a beginner...). Can you provide a rough comparision of the workflows? Sorry, but I'm too lazy, I mean busy to give it a try. configure --enable-linux-build make xconfig make install I'm starting to like this! If you already have a .config file, the make xconfig step becomes optional. Note that the --enable-linux-build flag is optional too. The simplification is mainly for developping xenomai itself, not for its users. Because with the current scheme, after some modifications, you have to recompile and reinstall both the kernel-space modules and user-space libraries. If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. Hmm, what about this: Instead of leaving some (probably empty) xenomai-prepared in the kernel tree, better create an xenomai-uninstall script in the same place. It a) can serve as an indication for a prepared kernel and b) can be used to upgrade that tree by first running it and then applying the usual steps on the kernel again. I often forget to save my old adeos patch before updating the xenomai tree, thus I will then have to download the old patch again, reverse-apply it, and can finally run the prepare script for the update. Automating this would be REALLY, REALLY GREAT! Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Two patches for the documentation
Hi xeno.sim.patch contains some clarification on how to build the xenoscope. (GCC 3.4 worked for me on a x86 system, but with a lot of warnings, that fwritable is deprecated) xeno.patch is a shorter way how to cross-compile using the CROSS_COMPILE variable. It worked for me without any problems for my board. Also contains a hint to use O=../a-build-dir to compile the linux kernel. Best regards -- Niklaus Giger Index: README.INSTALL === --- README.INSTALL (Revision 392) +++ README.INSTALL (Arbeitskopie) @@ -150,20 +150,22 @@ needed, but if you do not use it, configure emit a warning, which may be confusing. +The easiest way to build a GNU cross-compiler might involve using Dan Kegel +crosstools found at http://kegel.com/crosstool. + Since cross-compiling requires specific tools, such tools are generally prefixed with the host architecture name; for example, a compiler for the power PC -architecture may be named powerpc-linux-gcc. +architecture may be named powerpc-405-linux-gnu-gcc. -When this prefix contains the name of the architecture, you may pass this prefix -to the --host option of configure. For example, if you type : -configure --host=powerpc-linux - -configure will automatically use powerpc-linux- as a prefix too all compilation +configure will automatically use powerpc-405-linux-gnu- as a prefix too all compilation tools names and deduce the architecture name. If configure is unable to deduce the architecture name from this prefix, you will have to manually pass the name of all compilation tools on configure command line. As in: -configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +It might be a good idea to put all the output into a differen build directory +as to build from from linux source several targets. For each target add +O=../build-target to each make invocation. +configure CROSS_COMPILE=powerpc-405-linux-gnu- For more details: http://sourceware.org/autobook/autobook/autobook_264.html#SEC264 @@ -204,16 +206,18 @@ 2.2 Building for the PowerPC architecture A typical cross-compilation setup, in order to build Xenomai for a -82xx-based system: +PowerPC-405-based system: $ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ --linux=$linux_tree $ cd $linux_tree -$ make xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make bzImage modules # then install as needed +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +# select the kernel and Xenomai options +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules +# then install as needed $ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +$ $xenomai_root/configure CROSS_COMPILE=powerpc-405-linux-gnu- $ make install 2.3 Building for the IPF Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + +You will need the libelf, libpng, tcl8.x/tk8.x and tix81 _development packages_ in order to build the simulator and its companion tools. For instance, on Debian systems, you will need to install libelfg0-dev, libpng2-dev, tcl8.3-dev, tk8.3-dev and tix41-dev (any
[Xenomai-core] Problems cross-compiling for PPC405
Hi I just upgraded to revision 392 of xenomai and got the following error trying to compile the linux 2.6.14 kernel CC kernel/xenomai/nucleus/heap.o /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1017:1: pasting , and args does not give a valid preprocessing token /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c: In function `xnheap_mount': /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: `args' undeclared (first use in this function) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: (Each undeclared identifier is reported only once /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: for each function it appears in.) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: warning: too many arguments for format make[4]: *** [kernel/xenomai/nucleus/heap.o] Fehler 1 make[3]: *** [kernel/xenomai/nucleus] Fehler 2 make[2]: *** [kernel/xenomai] Fehler 2 make[1]: *** [kernel] Fehler 2 I am using GCC 3.4.4. Best regards -- Niklaus Giger
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Jan Kiszka wrote: If you let configure select the proper adeos patch, you are warned when the adeos patch changed in the source directory (after an svn update, for example), and just have to type: rm linux/.xenomai-prepared (Ok, this step is a bit awkward, we may find something better) make install And a new kernel will be built and installed, using the new adeos patch and the same .config. Hmm, what about this: Instead of leaving some (probably empty) xenomai-prepared in the kernel tree, better create an xenomai-uninstall script in the same place. It a) can serve as an indication for a prepared kernel and b) can be used to upgrade that tree by first running it and then applying the usual steps on the kernel again. I often forget to save my old adeos patch before updating the xenomai tree, thus I will then have to download the old patch again, reverse-apply it, and can finally run the prepare script for the update. Automating this would be REALLY, REALLY GREAT! The current approach try and achieve a similar goal by first copying (it is not a real copy, only symbolic links to the source tree, a bit like lndir would do) an unpatched kernel in Xenomai build tree, and preparing it there. This way, when compilation with a new patch is needed, there is no need to unprepare the kernel, only erase, copy again and prepare the fresh copy, using the new patch. And that is what the current patch automates. unpreparing seems harder. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Problems cross-compiling for PPC405
Niklaus Giger wrote: Hi I just upgraded to revision 392 of xenomai and got the following error trying to compile the linux 2.6.14 kernel CC kernel/xenomai/nucleus/heap.o /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1017:1: pasting , and args does not give a valid preprocessing token r393 fixes this. Thanks. /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c: In function `xnheap_mount': /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: `args' undeclared (first use in this function) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: (Each undeclared identifier is reported only once /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: for each function it appears in.) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: warning: too many arguments for format make[4]: *** [kernel/xenomai/nucleus/heap.o] Fehler 1 make[3]: *** [kernel/xenomai/nucleus] Fehler 2 make[2]: *** [kernel/xenomai] Fehler 2 make[1]: *** [kernel] Fehler 2 I am using GCC 3.4.4. Best regards -- Philippe.
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Jim Cromie wrote: Philippe Gerum wrote: You may want to try this one: http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.1-03.patch although Im not surprised, I feel like telling someone, [EMAIL PROTECTED] ~]$ uname -a Linux harpo.jimc.earth 2.6.15-ipipe-103-sony #1 Sat Jan 7 13:54:09 MST 2006 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]$ is NFS root for .. soekris:~# uname -a Linux soekris 2.6.15-ipipe-103-sk #3 Sat Jan 7 13:42:06 MST 2006 i586 GNU/Linux soekris:~# soekris:~# df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.42.1:/nfshost/soekris 20158372 14249292 4885080 75% / tmpfs63268 0 63268 0% /dev/shm /dev/hda1 484602268767190813 59% /mnt/flash 192.168.42.1:/boot20158400 14249312 4885088 75% /boot 192.168.42.1:/lib/modules 20158400 14249312 4885088 75% /lib/modules 192.168.42.1:/media/cdrecorder 20158400 14249312 4885088 75% /mnt/cd 192.168.42.1:/home20158400 14249312 4885088 75% /home 192.168.42.1:/mnt/dilbert 15638816 11716256 3128128 79% /mnt/dilbert 192.168.42.1:/usr/xenomai 20158400 14249312 4885088 75% /usr/xenomai 192.168.42.1:/home/jimc/dilbert/pirt 15638816 11716256 3128128 79% /mnt/pirt woohoo! I just diffed my-1.01 and real-1.03, it looks like I missed a bunch of these: - spin_unlock_irqrestore(ioapic_lock, flags); + spin_unlock_irqrestore_hw(ioapic_lock, flags); did I get lucky ? or is it cuz Im not SMP ? The additional hw locking is to make 100% sure that built-in Adeos domains pushed above Linux could call the related routines even during the kernel init phase. Since the I-pipe is enabled quite early during this process, I've decided to play extra safe here. or cuz my sony has no APIC (as distinct from ACPI) ? do any PCs have an APIC, or is that something for servers / hi-end or embedded ? It has become the norm for desktops, Intel CPU(s) of hi-end boxen have one especially SMP since it works with the IO-APIC for routing interrupts among other things. Still not the norm for embedded AFAIK, this will possibly evolve the same way over time too. BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1ff4 (usable) BIOS-e820: 1ff4 - 1ff5 (ACPI data) BIOS-e820: 1ff5 - 2000 (ACPI NVS) 511MB LOWMEM available. On node 0 totalpages: 130880 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126784 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI present. ACPI: RSDP (v000 SONY ) @ 0x000f53f0 ACPI: RSDT (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff4 ACPI: FADT (v002 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff40200 ACPI: OEMB (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff50040 ACPI: DSDT (v001 SONY F1 0x20040323 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 3000 (gap: 2000:e000) Built 1 zonelists Kernel command line: ro root=LABEL=/ Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1694.791 MHz processor. Using pmtmr for high-res timesource I-pipe 1.1-03: pipeline enabled. BTW, what happened to 1.01 and 1.02 ? There were three critical changes to merge for starting 1.1; one at a time, -03 has ended the series. tia jimc -- Philippe.
