[Xenomai-core] RE : New patch for Freescale i.MX21 (csb535fs)
Hi Philippe, We have performed some test with the patch and everything is OK. We got the same latencies than before; we're now investigating what is the cause of some occasional peaks to 40-50 us. Daniel Message d'origine De: Philippe Gerum [mailto:[EMAIL PROTECTED] Date: lun. 05.06.2006 13:46 À: ROSSIER Daniel Cc: xenomai-core@gna.org Objet : Re: New patch for Freescale i.MX21 (csb535fs) Hi, Here is a candidate Adeos patch for the imx21 board. It applies on top of 2.6.14 + generic IMX21 patch + vanilla Adeos 2.6.14-1.3-04 patch. Since I don't have this hw at hand, It would be nice that you try this patch on your board when time allows and let me know if everything works as expected. TIA, -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Add fptest for powerpc
This adds powerpc version of fptest.h. It just stores and loads the raw
integer into/from FPU registers without converting to proper IEEE form.
Converting would have added unneccessary complexity. As a side note, the
ppc barfs on the test with 1000 != 10. :I
-- hl
diff -Nru xenomai.orig/include/asm-powerpc/fptest.h
xenomai/include/asm-powerpc/fptest.h
--- xenomai.orig/include/asm-powerpc/fptest.h 2006-06-10 10:29:29.335736000
+
+++ xenomai/include/asm-powerpc/fptest.h2006-06-10 16:12:09.395132000
+
@@ -10,11 +10,94 @@
static inline void fp_regs_set(unsigned val)
{
+ uint64_t fpval = val;
+ __asm__ __volatile__(lfd 0, %0\n
+ fmr 1, 0\n
+ fmr 2, 0\n
+ fmr 3, 0\n
+ fmr 4, 0\n
+ fmr 5, 0\n
+ fmr 6, 0\n
+ fmr 7, 0\n
+ fmr 8, 0\n
+ fmr 9, 0\n
+ fmr 10, 0\n
+ fmr 11, 0\n
+ fmr 12, 0\n
+ fmr 13, 0\n
+ fmr 14, 0\n
+ fmr 15, 0\n
+ fmr 16, 0\n
+ fmr 17, 0\n
+ fmr 18, 0\n
+ fmr 19, 0\n
+ fmr 20, 0\n
+ fmr 21, 0\n
+ fmr 22, 0\n
+ fmr 23, 0\n
+ fmr 24, 0\n
+ fmr 25, 0\n
+ fmr 26, 0\n
+ fmr 27, 0\n
+ fmr 28, 0\n
+ fmr 29, 0\n
+ fmr 30, 0\n
+ fmr 31, 0\n
+ :
+ : m (fpval));
}
+#define FPTEST_REGVAL(n) { \
+ uint64_t t; \
+ __asm__ __volatile__( stfd #n , %0 : =m (t));\
+ e[n] = (unsigned)t; \
+ }
+
static inline int fp_regs_check(unsigned val)
{
-return 0;
+ unsigned i, failed = 0;
+ uint32_t e[32];
+
+ FPTEST_REGVAL(0);
+ FPTEST_REGVAL(1);
+ FPTEST_REGVAL(2);
+ FPTEST_REGVAL(3);
+ FPTEST_REGVAL(4);
+ FPTEST_REGVAL(5);
+ FPTEST_REGVAL(6);
+ FPTEST_REGVAL(7);
+ FPTEST_REGVAL(8);
+ FPTEST_REGVAL(9);
+ FPTEST_REGVAL(10);
+ FPTEST_REGVAL(11);
+ FPTEST_REGVAL(12);
+ FPTEST_REGVAL(13);
+ FPTEST_REGVAL(14);
+ FPTEST_REGVAL(15);
+ FPTEST_REGVAL(16);
+ FPTEST_REGVAL(17);
+ FPTEST_REGVAL(18);
+ FPTEST_REGVAL(19);
+ FPTEST_REGVAL(20);
+ FPTEST_REGVAL(21);
+ FPTEST_REGVAL(22);
+ FPTEST_REGVAL(23);
+ FPTEST_REGVAL(24);
+ FPTEST_REGVAL(25);
+ FPTEST_REGVAL(26);
+ FPTEST_REGVAL(27);
+ FPTEST_REGVAL(28);
+ FPTEST_REGVAL(29);
+ FPTEST_REGVAL(30);
+ FPTEST_REGVAL(31);
+
+ for (i = 0; i 32; i++)
+ if (e[i] != val) {
+ printk(r%d: %u != %u\n, i, e[i], val);
+ failed = 1;
+ }
+
+ return failed;
}
#endif /* FPTEST_H */
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add fptest for powerpc
Heikki Lindholm wrote: This adds powerpc version of fptest.h. It just stores and loads the raw integer into/from FPU registers without converting to proper IEEE form. Converting would have added unneccessary complexity. As a side note, the ppc barfs on the test with 1000 != 10. :I Ok, this test tool is far from being user-friendly :-) Just to be sure, I have tested the latest revision on x86 and it still runs fine, so I guess there really is a bug in power pc fpu switching code. Now, if we decode a bit, the integer passed to fp_regs_set and fp_regs_check are 1000 * iterations + task_index, so 1000 is task 0, iteration 1 10 is task 10, iteration 0. It means that task 10 after returning from its first context switch, is getting the context of task 0 before its second context switch. Now the thing to try is to reduce the number of threads involved, since by default there are 23 threads, so you should add a printk for each context switch in the kernel driver (and now that I think about it this printk should be activable with an ioctl), and try and reduce the list of threads by removing threads which do not appear between the serie of switches from task 0 to task 10. The correspondance between the task numbers and their type is not easy, but /proc/xenomai/sched and switch --help should help... Task 0 is the idle taks, an ordinary Linux task Task 10 is of type rtup_ufpp here, which means that it is a real-time task in primary mode using the FPU in primary mode. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Revision 1182 broke compiling PPC
Hi Philippe Your change seems to be broken (at least on PPC). In http://ngiger.dyndns.org/buildbot/hcu3/builds/71/step-mk_xeno/0 you will notice near the end gcc -DHAVE_CONFIG_H -I. -I../../../../../build/xenomai/src/skins/vrtx -I../../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__IN_XENO__ -Wstrict-prototypes -I../../../../../build/xenomai/include -MT libvrtx_la-task.lo -MD -MP -MF .deps/libvrtx_la-task.Tpo -c ../../../../../build/xenomai/src/skins/vrtx/task.c -fPIC -DPIC -o .libs/libvrtx_la-task.o ../../../../../build/xenomai/src/skins/vrtx/task.c:250:21: error: macro XENOMAI_SKINCALL1 requires 3 arguments, but only 2 given ../../../../../build/xenomai/src/skins/vrtx/task.c: In function 'sc_delay': ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: 'XENOMAI_SKINCALL1' undeclared (first use in this function) ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: (Each undeclared identifier is reported only once ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: for each function it appears in.) make[4]: *** [libvrtx_la-task.lo] Error 1 make[4]: Leaving directory `/mnt/data.ng/buildslave/buildbot/quick-hcu3/build/hcu/src/skins/vrtx' Could you please take a look at it? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add fptest for powerpc
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: This adds powerpc version of fptest.h. It just stores and loads the raw integer into/from FPU registers without converting to proper IEEE form. Converting would have added unneccessary complexity. As a side note, the ppc barfs on the test with 1000 != 10. :I Ok, this test tool is far from being user-friendly :-) Just to be sure, I have tested the latest revision on x86 and it still runs fine, so I guess there really is a bug in power pc fpu switching code. Now, if we decode a bit, the integer passed to fp_regs_set and fp_regs_check are 1000 * iterations + task_index, so 1000 is task 0, iteration 1 10 is task 10, iteration 0. It means that task 10 after returning from its first context switch, is getting the context of task 0 before its second context switch. Now the thing to try is to reduce the number of threads involved, since by default there are 23 threads, so you should add a printk for each context switch in the kernel driver (and now that I think about it this printk should be activable with an ioctl), and try and reduce the list of threads by removing threads which do not appear between the serie of switches from task 0 to task 10. The correspondance between the task numbers and their type is not easy, but /proc/xenomai/sched and switch --help should help... Task 0 is the idle taks, an ordinary Linux task Task 10 is of type rtup_ufpp here, which means that it is a real-time task in primary mode using the FPU in primary mode. I probably don't have time for debugging for some days now, but if any of the code goes through sigreturn path, it might be a kernel bug that's fixed in 2.6.16. -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Revision 1182 broke compiling PPC
Niklaus Giger wrote: Hi Philippe Your change seems to be broken (at least on PPC). In http://ngiger.dyndns.org/buildbot/hcu3/builds/71/step-mk_xeno/0 you will notice near the end gcc -DHAVE_CONFIG_H -I. -I../../../../../build/xenomai/src/skins/vrtx -I../../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__IN_XENO__ -Wstrict-prototypes -I../../../../../build/xenomai/include -MT libvrtx_la-task.lo -MD -MP -MF .deps/libvrtx_la-task.Tpo -c ../../../../../build/xenomai/src/skins/vrtx/task.c -fPIC -DPIC -o .libs/libvrtx_la-task.o ../../../../../build/xenomai/src/skins/vrtx/task.c:250:21: error: macro XENOMAI_SKINCALL1 requires 3 arguments, but only 2 given ../../../../../build/xenomai/src/skins/vrtx/task.c: In function 'sc_delay': ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: 'XENOMAI_SKINCALL1' undeclared (first use in this function) ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: (Each undeclared identifier is reported only once ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: for each function it appears in.) make[4]: *** [libvrtx_la-task.lo] Error 1 make[4]: Leaving directory `/mnt/data.ng/buildslave/buildbot/quick-hcu3/build/hcu/src/skins/vrtx' Could you please take a look at it? Fixed by 1187, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] fix breakage by #1185
Jan Kiszka wrote:
Hi,
I guess this is more like what check-in #1185 wanted to achieve:
--- src/skins/vrtx/task.c (Revision 1186)
+++ src/skins/vrtx/task.c (Arbeitskopie)
@@ -247,5 +247,6 @@ void sc_unlock (void)
void sc_delay (long timeout)
{
XENOMAI_SKINCALL1(__vrtx_muxid,
- __vrtx_delay);
+ __vrtx_delay,
+ timeout);
}
Jan
PS: Is this distribution of sc_delay() intended: src/skins/vrtx/task.c
vs. ksrc/skins/vrtx/time.c?
Not really, but I will reorganize this stuff as work progresses on the
VRTX skin.
___
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] kgdb/x86 over I-pipe
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Hi Jan,
Based on your previous work, here is a set of patches coupling KGDB and
the I-pipe. Basically, I've attempted to shrink the extra patches needed
against the original KGDB + I-pipe ones to the bare minimum. This has
been obtained by having the I-pipe provide ipipe_current_safe(), and
drastically reduce the amount of fiddling with smp_processor_id().
The key difference with the former implementation is that a domain (e.g.
Xenomai) is now expected to tell the I-pipe when it's switching to a
non-Linux stack, and the I-pipe makes good use of this information to
return the proper current value when asked to through
ipipe_safe_current() from the KGDB code. The issue of swapping
This looks nice.
smp_processor_id() with ipipe_processor_id() has been addressed the hard
way: smp_processor_id() is simply defined as ipipe_processor_id() when
CONFIG_IPIPE and CONFIG_KGDB are both enabled in include/linux/smp.h.
This approach was actually used during the old Adeos times when pipeline
domain had their own separate stack. I take for granted that the CPU
penalty taken in doing this is perfectly acceptable, since well, we are
debugging after all.
There is only one drawback: we will not be able to debug
smp_processor_id-related bugs in ipipe/Xenomai anymore...
Good point. Here is an updated patch.
Nope that's not the point I meant. I was referring to bugs like the
missing smp_processor_id patch in asm-i386/mmu_context.h. Your way makes
such problems disappear once you switch on the debugger. Remember that
we spotted the mmu_context issue via kgdb.
The attached kgdb-ipipe patch (which also updates to kgdb-CVS head)
addresses maintenance and smp-safeness by redefining the involved
services only per source file, not kernel-wide. What's do you think
about this approach?
I'm also posting two fixes for ipipe itself to 1) make kgdb work over
SMP and 2) fix a compiler warning.
This version works fine for me, at least in qemu. I tried to check SMP
as well, but qemu obviously lacks support for NMIs raised via IPI, and
this is used by kgdb to sync all CPUs on debugging events (vanilla kgdb
suffers too).
Jan
Index: linux/kernel/kgdb.c
===
--- linux.orig/kernel/kgdb.c
+++ linux/kernel/kgdb.c
@@ -49,6 +49,15 @@
#include linux/console.h
#include asm/byteorder.h
+#if defined(CONFIG_KGDB) defined(CONFIG_IPIPE)
+#undef smp_processor_id
+#undef local_irq_save
+#undef local_irq_restore
+#define smp_processor_idipipe_processor_id
+#define local_irq_save local_irq_save_hw
+#define local_irq_restore local_irq_restore_hw
+#endif
+
extern int pid_max;
extern int pidhash_init_done;
@@ -743,7 +752,7 @@ static void kgdb_wait(struct pt_regs *re
local_irq_save(flags);
processor = smp_processor_id();
kgdb_info[processor].debuggerinfo = regs;
- kgdb_info[processor].task = current;
+ kgdb_info[processor].task = ipipe_safe_current();
atomic_set(procindebug[processor], 1);
atomic_set(kgdb_sync_softlockup[smp_processor_id()], 1);
@@ -884,8 +893,8 @@ int kgdb_deactivate_sw_breakpoints(void)
kgdb_break[i].saved_instr)))
return error;
- if (CACHE_FLUSH_IS_SAFE current-mm
-addr TASK_SIZE)
+ if (CACHE_FLUSH_IS_SAFE ipipe_safe_current() == current
+current-mm addr TASK_SIZE)
flush_cache_range(current-mm-mmap_cache,
addr, addr + BREAK_INSTR_SIZE);
else if (CACHE_FLUSH_IS_SAFE)
@@ -1069,7 +1078,7 @@ int kgdb_handle_exception(int ex_vector,
goto kgdb_restore;
kgdb_info[processor].debuggerinfo = linux_regs;
- kgdb_info[processor].task = current;
+ kgdb_info[processor].task = ipipe_safe_current();
kgdb_disable_hw_debug(linux_regs);
@@ -1121,7 +1130,8 @@ int kgdb_handle_exception(int ex_vector,
*ptr++ = hexchars[(signo 4) % 16];
*ptr++ = hexchars[signo % 16];
ptr += strlen(strcpy(ptr, thread:));
- int_to_threadref(thref, shadow_pid(current-pid));
+ int_to_threadref(thref,
+ shadow_pid(ipipe_safe_current()-pid));
ptr = pack_threadid(ptr, thref);
*ptr++ = ';';
@@ -1213,7 +1223,8 @@ int kgdb_handle_exception(int ex_vector,
kgdb_hex2mem(remcom_in_buffer[1], (char *)gdb_regs,
NUMREGBYTES);
- if (kgdb_usethread kgdb_usethread != current)
+ if (kgdb_usethread
+ kgdb_usethread != ipipe_safe_current())
error_packet(remcom_out_buffer, -EINVAL);
else {
gdb_regs_to_regs(gdb_regs, linux_regs);
@@ -1334,7 +1345,8 @@ int kgdb_handle_exception(int ex_vector,
/* Current thread id */
strcpy(remcom_out_buffer, QC);
-threadid = shadow_pid(current-pid);
+threadid =
+ shadow_pid(ipipe_safe_current()-pid);
int_to_threadref(thref, threadid);
pack_threadid(remcom_out_buffer + 2, thref);
@@ -1488,7 +1500,8 @@ int kgdb_handle_exception(int ex_vector,
break;
case 'c':
case 's':
- if (kgdb_contthread
