date:20060112

Re: [Xenomai-core] latency kernel part fixed

2006-01-12 Thread Wolfgang Grandegger


Philippe Gerum wrote:

Jan Kiszka wrote:


Gilles Chanteperdrix wrote:


Philippe Gerum wrote:
 Gilles Chanteperdrix wrote:
  Philippe Gerum wrote:
Likely not this time (keep it cold anyway, who knows); I 
strongly suspect a bug in xnarch_switch_to() for all archs but 
x86
Now that you are talking about it, I may be the one who owes 
a beer to
  everyone by first having put a bug in ia64 context-switch code... 
If I
  am not wrong, the bug should be observed on ia64 too. 
Unfortunately, I
  am unable to compile my ia64 kernel right now, so I wrote a patch 
for

  power PC, and would be glad if some power PC owner could try it.
Nope, same lockup with hybrid scheduling.

The latency -t 1 crash may be observed on ia64 too.

But it does not seem to be due to the bug I was suspecting in context
switch code.




What about the PPC world? I saw some SVN commits claiming to fix this
(also for blackfin) - but there was no Hey, it's fixed now! on the
mailing list.



Ok... Hey, it's fixed now!

Hybrid scheduling (kernel and user-space Xeno threads combination) has 
been fixed for ppc32, ppc64, ia64 and the Blackfin. Issue fixed on the 
ARM port to come too. Some tests remain to be conducted on the ppc64 
though. The rest has already been validated. Fixes are available from 
the SVN trunk/.


This said, here is my next Xmas wishlist I'd really appreciate you guys 
anticipate from, say 11 months and a couple of weeks: if you have any of 
the above archs, please run both the kernel and user-space latency tests 
on such hw:


OK, I will do tests on a few PowerPC boards (4xx, 8xx, 8260).

Basically, this boils down to building Jan's timerbench test into the 
kernel or as a separate module, then run the following tests on the said 
kernel:


$ sudo ./latency -t0
$ sudo ./latency -t1
$ sudo ./latency -t2

Special note to the ppc32 people: I would be interested in having your 
feedback about switching on the ALTIVEC and SPE supports at kernel 
level, on platforms that do not have those beasts, and see if all tests 
survive this.


In any case, I'm eventually going to warn about such configurations at 
the very least, since relying on FTR fixups right in the middle of the 
fast path for all context switches is kind of, mmh, silly?! 
Nevertheless, knowing about the result might be important in the future.


TIA,




___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Stelian Pop



Le 12 janv. 06 à 10:12, Philippe Gerum a écrit :



Hi Wolfgang,

Wolfgang Grandegger wrote:

Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S  
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:

 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist



Ok, thanks for the info. I'm going to fix and check the 2.4/ppc  
port today.


2.6/ppc build fails in the same way. Correcting it to linux/asm- 
offsets.h fixes fixes it.


Stelian.


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Philippe Gerum


Stelian Pop wrote:


Le 12 janv. 06 à 10:12, Philippe Gerum a écrit :



Hi Wolfgang,

Wolfgang Grandegger wrote:


Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S  
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:

 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist



Ok, thanks for the info. I'm going to fix and check the 2.4/ppc  port 
today.



2.6/ppc build fails in the same way. Correcting it to linux/asm- 
offsets.h fixes fixes it.




Forgot that pre-2.6.14 versions include asm/offsets.h, while post- ones now 
include asm/asm-offsets. Ok, will fix. Thanks.



Stelian.





--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Philippe Gerum


Stelian Pop wrote:


Le 12 janv. 06 à 10:12, Philippe Gerum a écrit :



Hi Wolfgang,

Wolfgang Grandegger wrote:


Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S  
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:

 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist



Ok, thanks for the info. I'm going to fix and check the 2.4/ppc  port 
today.



2.6/ppc build fails in the same way. Correcting it to linux/asm- 
offsets.h fixes fixes it.




Fixed.


Stelian.





--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Philippe Gerum


Wolfgang Grandegger wrote:

Hi Philippe,

I just realized that recent changes in ksrc/arch/powerpc/switch.S have 
broken the build of Xenomai with linuxppc_2_4_devel on PPC:


 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist



Fixed.

For the time being, I will stick with an older version for testing RTnet 
(where I'm currently debugging floating point used in kernel errors on 
the MPC8260),


Thanks.

Wolfgang.




--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] latency kernel part crashes on ppc64

2006-01-12 Thread Gilles Chanteperdrix

Jan Kiszka wrote:
  Gilles Chanteperdrix wrote:
   But it does not seem to be due to the bug I was suspecting in context
   switch code.
   
  
  What about the PPC world? I saw some SVN commits claiming to fix this
  (also for blackfin) - but there was no Hey, it's fixed now! on the
  mailing list.

Actually, the bug I suspected was the real cause of trouble on
ia64. But, if you look at Philippe's commit, you will see that there
were a couple of other bugs (probably all my work) on this architecture,
hence my previous, wrong, claim.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] [PATCH] Fix ppc64 thread switching

2006-01-12 Thread Heikki Lindholm

Add some polish, eg. make it work, for the recent thread switching 
changes for the ppc64.


-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/hal.h 
xenomai-devel/include/asm-powerpc/hal.h
--- xenomai/include/asm-powerpc/hal.h   2006-01-11 11:55:17.0 +0200
+++ xenomai-devel/include/asm-powerpc/hal.h 2006-01-12 15:29:03.0 
+0200
@@ -165,8 +165,14 @@
 
 #define RTHAL_SWITCH_FRAME_SIZE  (STACK_FRAME_OVERHEAD + sizeof(struct 
pt_regs))
 
+#ifdef CONFIG_PPC64
+asmlinkage void rthal_thread_switch(struct thread_struct *prev,
+   struct thread_struct *next,
+   int kernel_thread);
+#else /* !CONFIG_PPC64 */
 asmlinkage void rthal_thread_switch(struct thread_struct *prev,
struct thread_struct *next);
+#endif /* CONFIG_PPC64 */
 
 asmlinkage void rthal_thread_trampoline(void);
 
diff -Nru xenomai/include/asm-powerpc/system.h 
xenomai-devel/include/asm-powerpc/system.h
--- xenomai/include/asm-powerpc/system.h2006-01-11 11:55:17.0 
+0200
+++ xenomai-devel/include/asm-powerpc/system.h  2006-01-12 15:35:31.0 
+0200
@@ -239,8 +239,13 @@
 #endif /* CONFIG_PPC64 */
}
 
+#ifdef CONFIG_PPC64
+rthal_thread_switch(out_tcb-tsp, in_tcb-tsp, 
+   in_tcb-user_task == NULL ? 1 : 0);
+#else /* !CONFIG_PPC64 */
 rthal_thread_switch(out_tcb-tsp, in_tcb-tsp);
-
+#endif /* CONFIG_PPC64 */
+
 barrier();
 }
 
@@ -299,12 +304,23 @@
 ksp = (unsigned long *)((unsigned long)tcb-stackbase + tcb-stacksize - 
RTHAL_SWITCH_FRAME_SIZE - 32);
 childregs = (struct pt_regs *)ksp;
 memset(childregs,0,sizeof(*childregs));
-childregs-nip = (unsigned long)rthal_thread_trampoline;
+childregs-nip = ((unsigned long *)rthal_thread_trampoline)[0];
+childregs-gpr[2] = ((unsigned long *)rthal_thread_trampoline)[1];
 childregs-gpr[14] = flags  ~(MSR_EE | MSR_FP);
 childregs-gpr[15] = ((unsigned long *)xnarch_thread_trampoline)[0]; /* 
lr = entry addr. */
 childregs-gpr[16] = ((unsigned long *)xnarch_thread_trampoline)[1]; /* 
r2 = TOC base. */
 childregs-gpr[17] = (unsigned long)tcb;
 tcb-ts.ksp = (unsigned long)childregs - STACK_FRAME_OVERHEAD;
+if (cpu_has_feature(CPU_FTR_SLB)) { /* from process.c/copy_thread */
+   unsigned long sp_vsid = get_kernel_vsid(tcb-ts.ksp);
+   
+   sp_vsid = SLB_VSID_SHIFT;
+   sp_vsid |= SLB_VSID_KERNEL;
+   if (cpu_has_feature(CPU_FTR_16M_PAGE))
+   sp_vsid |= SLB_VSID_L;
+   
+   tcb-ts.ksp_vsid = sp_vsid;
+}
 #else /* !CONFIG_PPC64 */
 ksp = (unsigned long *)((unsigned long)tcb-stackbase + tcb-stacksize - 
RTHAL_SWITCH_FRAME_SIZE - 4);
 childregs = (struct pt_regs *)ksp;
@@ -415,7 +431,7 @@
 tcb-user_task = NULL;
 tcb-active_task = NULL;
 tcb-tsp = tcb-ts;
-/* Note: .pgdir(ppc32)/.VSID(ppc64) == NULL for a Xenomai kthread. */
+/* Note: .pgdir(ppc32) == NULL for a Xenomai kthread. */
 memset(tcb-ts,0,sizeof(tcb-ts));
 #ifdef CONFIG_XENO_HW_FPU
 tcb-user_fpu_owner = NULL;
diff -Nru xenomai/ksrc/arch/powerpc/switch_64.S 
xenomai-devel/ksrc/arch/powerpc/switch_64.S
--- xenomai/ksrc/arch/powerpc/switch_64.S   2006-01-11 11:55:22.0 
+0200
+++ xenomai-devel/ksrc/arch/powerpc/switch_64.S 2006-01-12 15:30:18.0 
+0200
@@ -33,7 +33,7 @@
 #include asm/mmu.h
 
 /*
- * void rthal_thread_switch(struct thread_struct *prev, struct thread_struct 
*next)
+ * void rthal_thread_switch(struct thread_struct *prev, struct thread_struct 
*next, int kernel_thread)
  */
.align  7
 _GLOBAL(rthal_thread_switch)
@@ -68,17 +68,12 @@
 
ld  r8,KSP(r4)  /* new stack pointer */
 
-   lwz r0,KSP_VSID(r4)
-cmpwi   r0, 0
-bne+ change_current
-   mr  r1,r8   /* start using new stack pointer */
-   b same_current
+   cmpwi   cr5,r5,0/* is it a kernel thread */
+bne-   cr5,10f /* if so, don't touch 'current' */
 
-change_current:
-   
addir6,r4,-THREAD   /* Convert THREAD to 'current' */
std r6,PACACURRENT(r13) /* Set new 'current' */
-
+10:
 BEGIN_FTR_SECTION
clrrdi  r6,r8,28/* get its ESID */
clrrdi  r9,r1,28/* get current sp ESID */
@@ -98,16 +93,16 @@
 
 2:
 END_FTR_SECTION_IFSET(CPU_FTR_SLB)
+   bne-cr5,11f /* kernel thread: don't touch 'current' */
clrrdi  r7,r8,THREAD_SHIFT  /* base of new stack */
/* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
   because we don't need to leave the 288-byte ABI gap at the
   top of the kernel stack. */
addir7,r7,THREAD_SIZE-SWITCH_FRAME_SIZE
-
-   mr  r1,r8   /* start using new stack pointer */
std r7,PACAKSAVE(r13)
-
-same_current:
+   
+11:
+   mr  r1,r8   /* start using new

[Xenomai-core] Re: [PATCH] Fix ppc64 thread switching

2006-01-12 Thread Philippe Gerum


Heikki Lindholm wrote:
Add some polish, eg. make it work, for the recent thread switching 
changes for the ppc64.




Applied, thanks.


-- Heikki Lindholm




diff -Nru xenomai/include/asm-powerpc/hal.h 
xenomai-devel/include/asm-powerpc/hal.h
--- xenomai/include/asm-powerpc/hal.h   2006-01-11 11:55:17.0 +0200
+++ xenomai-devel/include/asm-powerpc/hal.h 2006-01-12 15:29:03.0 
+0200
@@ -165,8 +165,14 @@
 
 #define RTHAL_SWITCH_FRAME_SIZE  (STACK_FRAME_OVERHEAD + sizeof(struct pt_regs))
 
+#ifdef CONFIG_PPC64

+asmlinkage void rthal_thread_switch(struct thread_struct *prev,
+   struct thread_struct *next,
+   int kernel_thread);
+#else /* !CONFIG_PPC64 */
 asmlinkage void rthal_thread_switch(struct thread_struct *prev,
struct thread_struct *next);
+#endif /* CONFIG_PPC64 */
 
 asmlinkage void rthal_thread_trampoline(void);
 
diff -Nru xenomai/include/asm-powerpc/system.h xenomai-devel/include/asm-powerpc/system.h

--- xenomai/include/asm-powerpc/system.h2006-01-11 11:55:17.0 
+0200
+++ xenomai-devel/include/asm-powerpc/system.h  2006-01-12 15:35:31.0 
+0200
@@ -239,8 +239,13 @@
 #endif /* CONFIG_PPC64 */
}
 
+#ifdef CONFIG_PPC64
+rthal_thread_switch(out_tcb-tsp, in_tcb-tsp, 
+		in_tcb-user_task == NULL ? 1 : 0);

+#else /* !CONFIG_PPC64 */
 rthal_thread_switch(out_tcb-tsp, in_tcb-tsp);
-
+#endif /* CONFIG_PPC64 */
+
 barrier();

 }
 
@@ -299,12 +304,23 @@

 ksp = (unsigned long *)((unsigned long)tcb-stackbase + tcb-stacksize - 
RTHAL_SWITCH_FRAME_SIZE - 32);
 childregs = (struct pt_regs *)ksp;
 memset(childregs,0,sizeof(*childregs));
-childregs-nip = (unsigned long)rthal_thread_trampoline;
+childregs-nip = ((unsigned long *)rthal_thread_trampoline)[0];
+childregs-gpr[2] = ((unsigned long *)rthal_thread_trampoline)[1];
 childregs-gpr[14] = flags  ~(MSR_EE | MSR_FP);
 childregs-gpr[15] = ((unsigned long *)xnarch_thread_trampoline)[0]; /* 
lr = entry addr. */
 childregs-gpr[16] = ((unsigned long *)xnarch_thread_trampoline)[1]; /* 
r2 = TOC base. */
 childregs-gpr[17] = (unsigned long)tcb;
 tcb-ts.ksp = (unsigned long)childregs - STACK_FRAME_OVERHEAD;
+if (cpu_has_feature(CPU_FTR_SLB)) { /* from process.c/copy_thread */
+   unsigned long sp_vsid = get_kernel_vsid(tcb-ts.ksp);
+	
+	sp_vsid = SLB_VSID_SHIFT;

+   sp_vsid |= SLB_VSID_KERNEL;
+   if (cpu_has_feature(CPU_FTR_16M_PAGE))
+   sp_vsid |= SLB_VSID_L;
+	
+	tcb-ts.ksp_vsid = sp_vsid;

+}
 #else /* !CONFIG_PPC64 */
 ksp = (unsigned long *)((unsigned long)tcb-stackbase + tcb-stacksize - 
RTHAL_SWITCH_FRAME_SIZE - 4);
 childregs = (struct pt_regs *)ksp;
@@ -415,7 +431,7 @@
 tcb-user_task = NULL;
 tcb-active_task = NULL;
 tcb-tsp = tcb-ts;
-/* Note: .pgdir(ppc32)/.VSID(ppc64) == NULL for a Xenomai kthread. */
+/* Note: .pgdir(ppc32) == NULL for a Xenomai kthread. */
 memset(tcb-ts,0,sizeof(tcb-ts));
 #ifdef CONFIG_XENO_HW_FPU
 tcb-user_fpu_owner = NULL;
diff -Nru xenomai/ksrc/arch/powerpc/switch_64.S 
xenomai-devel/ksrc/arch/powerpc/switch_64.S
--- xenomai/ksrc/arch/powerpc/switch_64.S   2006-01-11 11:55:22.0 
+0200
+++ xenomai-devel/ksrc/arch/powerpc/switch_64.S 2006-01-12 15:30:18.0 
+0200
@@ -33,7 +33,7 @@
 #include asm/mmu.h
 
 /*

- * void rthal_thread_switch(struct thread_struct *prev, struct thread_struct 
*next)
+ * void rthal_thread_switch(struct thread_struct *prev, struct thread_struct 
*next, int kernel_thread)
  */
.align  7
 _GLOBAL(rthal_thread_switch)
@@ -68,17 +68,12 @@
 
 	ld	r8,KSP(r4)	/* new stack pointer */
 
-	lwz	r0,KSP_VSID(r4)

-cmpwi   r0, 0
-bne+ change_current
-   mr  r1,r8   /* start using new stack pointer */
-   b same_current
+   cmpwi   cr5,r5,0/* is it a kernel thread */
+bne-   cr5,10f /* if so, don't touch 'current' */
 
-change_current:

-   
addir6,r4,-THREAD   /* Convert THREAD to 'current' */
std r6,PACACURRENT(r13) /* Set new 'current' */
-
+10:
 BEGIN_FTR_SECTION
clrrdi  r6,r8,28/* get its ESID */
clrrdi  r9,r1,28/* get current sp ESID */
@@ -98,16 +93,16 @@
 
 2:

 END_FTR_SECTION_IFSET(CPU_FTR_SLB)
+   bne-cr5,11f /* kernel thread: don't touch 'current' */
clrrdi  r7,r8,THREAD_SHIFT  /* base of new stack */
/* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
   because we don't need to leave the 288-byte ABI gap at the
   top of the kernel stack. */
addir7,r7,THREAD_SIZE-SWITCH_FRAME_SIZE
-
-   mr  r1,r8   /* start using new stack pointer */
std r7,PACAKSAVE(r13)
-
-same_current:

[Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Wolfgang Grandegger


Philippe Gerum wrote:

Wolfgang Grandegger wrote:


Hi Philippe,

I just realized that recent changes in ksrc/arch/powerpc/switch.S have 
broken the build of Xenomai with linuxppc_2_4_devel on PPC:


 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist



Fixed.


Thanks. Attached is a little patch fixing a build problem with Linux 
2.6.14 for PowerPC (ocotea, AMCC 440GX). But I'm not sure when exactly 
the change happened.


For the time being, I will stick with an older version for testing 
RTnet (where I'm currently debugging floating point used in kernel 
errors on the MPC8260),


Thanks.

Wolfgang.






+ diff -u linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1 linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h
--- linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1	2006-01-12 16:13:28.95807 +0100
+++ linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h	2006-01-12 16:56:08.623129271 +0100
@@ -150,7 +150,7 @@
 /* Device registration */
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,13)
 #define DECLARE_DEVCLASS(clname) struct class *clname
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,15)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,14)
 #define wrap_class_device_create class_device_create
 #else /*  2.6.15 */
 #define wrap_class_device_create(c,p,dt,dv,fmt,args...) class_device_create(c,dt,dv,fmt , ##args)
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] latency kernel part fixed

2006-01-12 Thread Philippe Gerum


Jan Kiszka wrote:

Gilles Chanteperdrix wrote:


Philippe Gerum wrote:
 Gilles Chanteperdrix wrote:
  Philippe Gerum wrote:
Likely not this time (keep it cold anyway, who knows); I strongly suspect a bug in 
xnarch_switch_to() for all archs but x86
  
  Now that you are talking about it, I may be the one who owes a beer to

  everyone by first having put a bug in ia64 context-switch code... If I
  am not wrong, the bug should be observed on ia64 too. Unfortunately, I
  am unable to compile my ia64 kernel right now, so I wrote a patch for
  power PC, and would be glad if some power PC owner could try it.
  
 
 Nope, same lockup with hybrid scheduling.


The latency -t 1 crash may be observed on ia64 too.

But it does not seem to be due to the bug I was suspecting in context
switch code.




What about the PPC world? I saw some SVN commits claiming to fix this
(also for blackfin) - but there was no Hey, it's fixed now! on the
mailing list.



Ok... Hey, it's fixed now!

Hybrid scheduling (kernel and user-space Xeno threads combination) has been fixed 
for ppc32, ppc64, ia64 and the Blackfin. Issue fixed on the ARM port to come too. 
Some tests remain to be conducted on the ppc64 though. The rest has already been 
validated. Fixes are available from the SVN trunk/.


This said, here is my next Xmas wishlist I'd really appreciate you guys anticipate 
from, say 11 months and a couple of weeks: if you have any of the above archs, 
please run both the kernel and user-space latency tests on such hw:


Basically, this boils down to building Jan's timerbench test into the kernel or as 
a separate module, then run the following tests on the said kernel:


$ sudo ./latency -t0
$ sudo ./latency -t1
$ sudo ./latency -t2

Special note to the ppc32 people: I would be interested in having your feedback 
about switching on the ALTIVEC and SPE supports at kernel level, on platforms that 
do not have those beasts, and see if all tests survive this.


In any case, I'm eventually going to warn about such configurations at the very 
least, since relying on FTR fixups right in the middle of the fast path for all 
context switches is kind of, mmh, silly?! Nevertheless, knowing about the result 
might be important in the future.


TIA,

--

Philippe.

[Xenomai-core] Xenomai broken on Linux 2.4

2006-01-12 Thread Wolfgang Grandegger


Hi Philippe,

I just realized that recent changes in ksrc/arch/powerpc/switch.S have 
broken the build of Xenomai with linuxppc_2_4_devel on PPC:


 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist

For the time being, I will stick with an older version for testing RTnet 
(where I'm currently debugging floating point used in kernel errors on 
the MPC8260),


Thanks.

Wolfgang.

Re: [Xenomai-core] latency kernel part crashes on ppc64

2006-01-12 Thread Gilles Chanteperdrix

Jan Kiszka wrote:
  Gilles Chanteperdrix wrote:
   But it does not seem to be due to the bug I was suspecting in context
   switch code.
   
  
  What about the PPC world? I saw some SVN commits claiming to fix this
  (also for blackfin) - but there was no Hey, it's fixed now! on the
  mailing list.

Actually, the bug I suspected was the real cause of trouble on
ia64. But, if you look at Philippe's commit, you will see that there
were a couple of other bugs (probably all my work) on this architecture,
hence my previous, wrong, claim.

-- 


Gilles Chanteperdrix.

[Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Wolfgang Grandegger


Philippe Gerum wrote:

Wolfgang Grandegger wrote:


Philippe Gerum wrote:


Wolfgang Grandegger wrote:


Hi Philippe,

I just realized that recent changes in ksrc/arch/powerpc/switch.S 
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:


 #include asm/offsets.h does not exist
 Symbols like SAVE_NVGPRS do not exist



Fixed.




Thanks. Attached is a little patch fixing a build problem with Linux 
2.6.14 for PowerPC (ocotea, AMCC 440GX). But I'm not sure when exactly 
the change happened.




Looks like specific to 2.6.14-DENX (kernel.org shows the additional 
parent parameter only starting with 2.6.15).
http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=blobdiff;h=a9e72ac3fb9fd066ebc5607bd28cfdd4ba8f010e;hp=95d607a48f06edd22c6be64e0feaf74d1aa63467;hb=3692e2d8099f19a4d1ff95df94cc82b394f86931;f=include/linux/device.h 



We likely need to find a way to specifically identify this tree.


Well, our 2.6 tree is based on the offical 2.6 tree. Don't know where 
the difference come from. Maybe Wolfgang can help (he is now on CC).




For the time being, I will stick with an older version for testing 
RTnet (where I'm currently debugging floating point used in kernel 
errors on the MPC8260),


Thanks.

Wolfgang.









+ diff -u 
linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1 
linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h
--- linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1
2006-01-12 16:13:28.95807 +0100
+++ linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h
2006-01-12 16:56:08.623129271 +0100

@@ -150,7 +150,7 @@
 /* Device registration */
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,13)
 #define DECLARE_DEVCLASS(clname) struct class *clname
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,15)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,14)
 #define wrap_class_device_create class_device_create
 #else /*  2.6.15 */
 #define wrap_class_device_create(c,p,dt,dv,fmt,args...) 
class_device_create(c,dt,dv,fmt , ##args)

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

2006-01-12 Thread Philippe Gerum


Wolfgang Denk wrote:

In message [EMAIL PROTECTED] you wrote:

Well, our 2.6 tree is based on the offical 2.6 tree. Don't know where 
the difference come from. Maybe Wolfgang can help (he is now on CC).



I'm subscribed, too.

We added some patches (especially 4xx network driver related) to  our
tree long before they were accepted and merged into Linus' tree.

Does this answer the question? [Or what exactly is the problem?]



We try to find a way to wrap class_device_create properly depending on the kernel 
version Xeno is compiled against. The parent device class argument in this call 
(2nd in order) seems to show up in 2.6.15 for kernel.org, but 2.6.14-denx-git has 
it too. So we have a problem relying on the version sublevel.



Best regards,

Wolfgang Denk




--

Philippe.

Re: [Xenomai-core] latency kernel part fixed

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

[Xenomai-core] Re: Xenomai broken on Linux 2.4

Re: [Xenomai-core] latency kernel part crashes on ppc64

[Xenomai-core] [PATCH] Fix ppc64 thread switching

[Xenomai-core] Re: [PATCH] Fix ppc64 thread switching

[Xenomai-core] Re: Xenomai broken on Linux 2.4

[Xenomai-core] latency kernel part fixed

[Xenomai-core] Xenomai broken on Linux 2.4

Re: [Xenomai-core] latency kernel part crashes on ppc64

[Xenomai-core] Re: Xenomai broken on Linux 2.4

Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4

14 matches

Site Navigation

Mail list logo

Footer information