[Xenomai-core] [PATCH] Add fptest for powerpc

[Xenomai-core] [PATCH] Add fptest for powerpc

[Heikki Lindholm]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

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

[-- Attachment #2: xenomai-060610-ppc-fptest.patch --]
[-- Type: text/plain, Size: 2045 bytes --]

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 +0000
+++ xenomai/include/asm-powerpc/fptest.h	2006-06-10 16:12:09.395132000 +0000
@@ -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 */

Re: [Xenomai-core] [PATCH] Add fptest for powerpc

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] [PATCH] Add fptest for powerpc

[Heikki Lindholm]

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

Re: [Xenomai-core] [PATCH] Add fptest for powerpc

[Gilles Chanteperdrix]

Heikki Lindholm wrote:
 > > 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.

Anyway, the patch is applied, thanks.

-- 


					    Gilles Chanteperdrix.