[Xenomai-core] Heads up: Xenomai port over x86_64 has started

[Xenomai-core] Heads up: Xenomai port over x86_64 has started

[Philippe Gerum]

Ok, no more distant rumblings about x86_64: a Xenomai port to this
architecture has officially started. A preliminary version of the I-pipe
for x86_64 is now available, which I'm going to use to port the Xenomai
core.

Thanks to Paul Corner for ironing the /proc support, and also for his
help in testing the beast.

http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86_64-1.0-00.patch

-- 
Philippe.

[Xenomai-core] Re: Heads up: Xenomai port over x86_64 has started

[Philippe Gerum]

On Wed, 2007-01-31 at 01:58 +0100, Philippe Gerum wrote:
> Ok, no more distant rumblings about x86_64: a Xenomai port to this
> architecture has officially started. A preliminary version of the I-pipe
> for x86_64 is now available, which I'm going to use to port the Xenomai
> core.

Here we are. The following revised I-pipe patch is stable enough to run
the Xenomai trunk/ on a 4-way Opteron, and on qemu-x86_64 0.8.2 too:
http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86_64-1.0-02.patch

The status of the Xenomai/x86_64 port is as follows:

- real-time support in user-space is mostly ok, except the FPU
management over the Xenomai domain which is broken beyond all
recognition. Gilles, as already discussed, I won't resist to let you
bang your head on this wall instead of mine, because 1) this will allow
me to switch to the pending issues people have raised on the lists so
far, 2) I'm fundamentally evil, 3) the fact that you once did dare
rewriting the FPU support for Xenomai/x86 clearly shows that you do have
some masochistic tendencies anyway.
- real-time support in kernel space is ok (except if you plan to use the
FPU in real-time context over kernel modules, that is).
- the I-pipe tracer is available. I used it as my preferred tool for
debugging when the bugs did not involve switching power off. There might
be issues I did not notice regarding the information reported by the
tracing sub-system, so please Jan, have a look at the beast.

To sum up, the testsuite passes properly, except switchtest ATM, since
the FPU is heavily involved there.

General note: this is _preliminary_ support, don't ever think about
using this in production right now. This said, things looks promising,
and I eventually learnt to like this port. If anyone as some results to
share with us after having tried this preliminary work, he will be most
welcome.

-- 
Philippe.

[Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > On Wed, 2007-01-31 at 01:58 +0100, Philippe Gerum wrote:
 > > Ok, no more distant rumblings about x86_64: a Xenomai port to this
 > > architecture has officially started. A preliminary version of the I-pipe
 > > for x86_64 is now available, which I'm going to use to port the Xenomai
 > > core.
 > 
 > Here we are. The following revised I-pipe patch is stable enough to run
 > the Xenomai trunk/ on a 4-way Opteron, and on qemu-x86_64 0.8.2 too:
 > http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86_64-1.0-02.patch
 > 
 > The status of the Xenomai/x86_64 port is as follows:
 > 
 > - real-time support in user-space is mostly ok, except the FPU
 > management over the Xenomai domain which is broken beyond all
 > recognition. Gilles, as already discussed, I won't resist to let you
 > bang your head on this wall instead of mine, because 1) this will allow
 > me to switch to the pending issues people have raised on the lists so
 > far, 2) I'm fundamentally evil, 3) the fact that you once did dare
 > rewriting the FPU support for Xenomai/x86 clearly shows that you do have
 > some masochistic tendencies anyway.

Ok, I will do it. Do you have an URL of a datasheet at hand (since the
x86 code does not work, there must be some difference) ?
By the way, there is a change that I made to the i386 context switching
routine which I think you should make to the x86_64 one: mark all
register as output registers, this prevent the compiler from considering
that the value of a particular register survived the context
switch.

-- 


					    Gilles Chanteperdrix.

[Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Philippe Gerum]

On Fri, 2007-02-23 at 21:01 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Wed, 2007-01-31 at 01:58 +0100, Philippe Gerum wrote:
>  > > Ok, no more distant rumblings about x86_64: a Xenomai port to this
>  > > architecture has officially started. A preliminary version of the I-pipe
>  > > for x86_64 is now available, which I'm going to use to port the Xenomai
>  > > core.
>  > 
>  > Here we are. The following revised I-pipe patch is stable enough to run
>  > the Xenomai trunk/ on a 4-way Opteron, and on qemu-x86_64 0.8.2 too:
>  > http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86_64-1.0-02.patch
>  > 
>  > The status of the Xenomai/x86_64 port is as follows:
>  > 
>  > - real-time support in user-space is mostly ok, except the FPU
>  > management over the Xenomai domain which is broken beyond all
>  > recognition. Gilles, as already discussed, I won't resist to let you
>  > bang your head on this wall instead of mine, because 1) this will allow
>  > me to switch to the pending issues people have raised on the lists so
>  > far, 2) I'm fundamentally evil, 3) the fact that you once did dare
>  > rewriting the FPU support for Xenomai/x86 clearly shows that you do have
>  > some masochistic tendencies anyway.
> 
> Ok, I will do it. Do you have an URL of a datasheet at hand (since the
> x86 code does not work, there must be some difference) ?

AFAICS, you still have an i387 to deal with. I would rather suspect an
issue with some revised logic in the regular task switching code.
Sidenote: the Xenomai/x86_64 switch code eliminates the "switch-to-self"
issue we discussed recently for x86, and I noticed this would break our
x86 FPU logic doing so, so maybe there is something to dig here. I'll
check this asap.

> By the way, there is a change that I made to the i386 context switching
> routine which I think you should make to the x86_64 one: mark all
> register as output registers, this prevent the compiler from considering
> that the value of a particular register survived the context
> switch.
> 

Indeed, my clobber list won't help for input registers. Will fix.

-- 
Philippe.

[Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Paul]

Hi Gilles

On Friday 23 February 2007 20:01, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Wed, 2007-01-31 at 01:58 +0100, Philippe Gerum wrote:
>  > > Ok, no more distant rumblings about x86_64: a Xenomai port to this
>  > > architecture has officially started. A preliminary version of the
>  > > I-pipe for x86_64 is now available, which I'm going to use to port the
>  > > Xenomai core.
>  >
>  > Here we are. The following revised I-pipe patch is stable enough to run
>  > the Xenomai trunk/ on a 4-way Opteron, and on qemu-x86_64 0.8.2 too:
>  > http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86
>  >_64-1.0-02.patch
>  >
>  > The status of the Xenomai/x86_64 port is as follows:
>  >
>  > - real-time support in user-space is mostly ok, except the FPU
>  > management over the Xenomai domain which is broken beyond all
>  > recognition. Gilles, as already discussed, I won't resist to let you
>  > bang your head on this wall instead of mine, because 1) this will allow
>  > me to switch to the pending issues people have raised on the lists so
>  > far, 2) I'm fundamentally evil, 3) the fact that you once did dare
>  > rewriting the FPU support for Xenomai/x86 clearly shows that you do have
>  > some masochistic tendencies anyway.
>
> Ok, I will do it. Do you have an URL of a datasheet at hand (since the
> x86 code does not work, there must be some difference) ?

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html 
has links for assorted low level docs - Vol.5 should cover the area in 
question.

> By the way, there is a change that I made to the i386 context switching
> routine which I think you should make to the x86_64 one: mark all
> register as output registers, this prevent the compiler from considering
> that the value of a particular register survived the context
> switch.


Regards, Paul.

[Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Gilles Chanteperdrix]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 2074 bytes --]

Philippe Gerum wrote:
 > On Fri, 2007-02-23 at 21:01 +0100, Gilles Chanteperdrix wrote:
 > > Philippe Gerum wrote:
 > >  > On Wed, 2007-01-31 at 01:58 +0100, Philippe Gerum wrote:
 > >  > > Ok, no more distant rumblings about x86_64: a Xenomai port to this
 > >  > > architecture has officially started. A preliminary version of the I-pipe
 > >  > > for x86_64 is now available, which I'm going to use to port the Xenomai
 > >  > > core.
 > >  > 
 > >  > Here we are. The following revised I-pipe patch is stable enough to run
 > >  > the Xenomai trunk/ on a 4-way Opteron, and on qemu-x86_64 0.8.2 too:
 > >  > http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86_64-1.0-02.patch
 > >  > 
 > >  > The status of the Xenomai/x86_64 port is as follows:
 > >  > 
 > >  > - real-time support in user-space is mostly ok, except the FPU
 > >  > management over the Xenomai domain which is broken beyond all
 > >  > recognition. Gilles, as already discussed, I won't resist to let you
 > >  > bang your head on this wall instead of mine, because 1) this will allow
 > >  > me to switch to the pending issues people have raised on the lists so
 > >  > far, 2) I'm fundamentally evil, 3) the fact that you once did dare
 > >  > rewriting the FPU support for Xenomai/x86 clearly shows that you do have
 > >  > some masochistic tendencies anyway.
 > > 
 > > Ok, I will do it. Do you have an URL of a datasheet at hand (since the
 > > x86 code does not work, there must be some difference) ?
 > 
 > AFAICS, you still have an i387 to deal with. I would rather suspect an
 > issue with some revised logic in the regular task switching code.
 > Sidenote: the Xenomai/x86_64 switch code eliminates the "switch-to-self"
 > issue we discussed recently for x86, and I noticed this would break our
 > x86 FPU logic doing so, so maybe there is something to dig here. I'll
 > check this asap.

I got switchtest to work on x86 without the "switch-to-self" switch,
both with and without fxsr, could you try the following patch on 
x86_64 ?

-- 


					    Gilles Chanteperdrix.

[-- Attachment #2: xeno-x86_64-fpu-switch.patch --]
[-- Type: text/plain, Size: 417 bytes --]

Index: include/asm-x86_64/bits/pod.h
===================================================================
--- include/asm-x86_64/bits/pod.h	(revision 2226)
+++ include/asm-x86_64/bits/pod.h	(working copy)
@@ -302,8 +302,10 @@
 		if (tcb->cr0_ts)
 			return;
 
-		xnarch_restore_fpu(tcb);
-		return;
+		if (!(task_thread_info(task)->status & TS_USEDFPU)) {
+			xnarch_restore_fpu(tcb);
+			return;
+		}
 	}
 
 	clts();

[Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Philippe Gerum]

On Sat, 2007-02-24 at 21:37 +0100, Gilles Chanteperdrix wrote:
>  > > 
>  > > Ok, I will do it. Do you have an URL of a datasheet at hand (since the
>  > > x86 code does not work, there must be some difference) ?
>  > 
>  > AFAICS, you still have an i387 to deal with. I would rather suspect an
>  > issue with some revised logic in the regular task switching code.
>  > Sidenote: the Xenomai/x86_64 switch code eliminates the "switch-to-self"
>  > issue we discussed recently for x86, and I noticed this would break our
>  > x86 FPU logic doing so, so maybe there is something to dig here. I'll
>  > check this asap.
> 
> I got switchtest to work on x86 without the "switch-to-self" switch,
> both with and without fxsr, could you try the following patch on 
> x86_64 ?

Eh, that's a strike, thanks. The switchtest now works smoothly with this
patch applied. Added to the fact that I've just fixed the CONFIG_SMP
+CONFIG_PREEMPT issue [1], what remains to get a fully functional
preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE,
and we should be done.

>From that point, the rest is about chasing latency spots if any, and
solve still-to-be-raised issues.

[1]
http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86_64-1.0-03.patch

-- 
Philippe.

Re: [Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Paul]

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


Hi Philippe

On Saturday 24 February 2007 22:46, Philippe Gerum wrote:
> Added to the fact that I've just fixed the CONFIG_SMP
> +CONFIG_PREEMPT issue [1], what remains to get a fully functional
> preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE,
> and we should be done.

If CONFIG_PREEMPT is not enabled, the kernel compile fails with:

arch/x86_64/kernel/built-in.o: In function `__ipipe_preempt_schedule_irq':
arch/x86_64/kernel/ipipe.c:471: undefined reference to `preempt_schedule_irq'
make[1]: *** [.tmp_vmlinux1] Error 1
make[1]: Leaving directory `/var/tmp/linux-2.6.19.3'
make: *** [debian/stamp-build-kernel] Error 2

The attached patch addresses the problem..


Regards, Paul.





[-- Attachment #2: config_preempt.diff --]
[-- Type: text/x-diff, Size: 958 bytes --]

diff -uwpr linux-2.6.19.3-orig/arch/x86_64/kernel/ipipe.c linux-2.6.19.3/arch/x86_64/kernel/ipipe.c
--- linux-2.6.19.3-orig/arch/x86_64/kernel/ipipe.c	2007-02-24 23:36:04.000000000 +0000
+++ linux-2.6.19.3/arch/x86_64/kernel/ipipe.c	2007-02-24 23:58:07.000000000 +0000
@@ -44,7 +44,9 @@
 #include <asm/ipi.h>
 #include <asm/mach_apic.h>
 
+#ifdef CONFIG_PREEMPT
 asmlinkage void preempt_schedule_irq(void);
+#endif
 
 struct pt_regs __ipipe_tick_regs[IPIPE_NR_CPUS];
 
@@ -450,6 +452,7 @@ static inline void __fixup_if(struct pt_
 	ipipe_put_cpu(flags);
 }
 
+#ifdef CONFIG_PREEMPT
 /*  Check the stall bit of the root domain to make sure the existing
     preemption opportunity upon in-kernel resumption could be
     exploited. In case a rescheduling could take place, the root stage
@@ -475,6 +478,7 @@ asmlinkage int __ipipe_preempt_schedule_
 
 	return 1;
 }
+#endif /* CONFIG_PREEMPT */
 
 asmlinkage int __ipipe_syscall_root(struct pt_regs *regs)
 {

Re: [Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Paul]

On Sunday 25 February 2007 00:15, Paul wrote:
> Hi Philippe
>
> On Saturday 24 February 2007 22:46, Philippe Gerum wrote:
> > Added to the fact that I've just fixed the CONFIG_SMP
> > +CONFIG_PREEMPT issue [1], what remains to get a fully functional
> > preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE,
> > and we should be done.
>
> If CONFIG_PREEMPT is not enabled, the kernel compile fails with:
>
> arch/x86_64/kernel/built-in.o: In function `__ipipe_preempt_schedule_irq':
> arch/x86_64/kernel/ipipe.c:471: undefined reference to
> `preempt_schedule_irq' make[1]: *** [.tmp_vmlinux1] Error 1
> make[1]: Leaving directory `/var/tmp/linux-2.6.19.3'
> make: *** [debian/stamp-build-kernel] Error 2
>
> The attached patch addresses the problem..

Scrub that - It exposes another problem in thunk.S which I missed...


Regards, Paul.

Re: [Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started

[Philippe Gerum]

On Sun, 2007-02-25 at 00:18 +0000, Paul wrote:
> On Sunday 25 February 2007 00:15, Paul wrote:
> > Hi Philippe
> >
> > On Saturday 24 February 2007 22:46, Philippe Gerum wrote:
> > > Added to the fact that I've just fixed the CONFIG_SMP
> > > +CONFIG_PREEMPT issue [1], what remains to get a fully functional
> > > preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE,
> > > and we should be done.
> >
> > If CONFIG_PREEMPT is not enabled, the kernel compile fails with:
> >
> > arch/x86_64/kernel/built-in.o: In function `__ipipe_preempt_schedule_irq':
> > arch/x86_64/kernel/ipipe.c:471: undefined reference to
> > `preempt_schedule_irq' make[1]: *** [.tmp_vmlinux1] Error 1
> > make[1]: Leaving directory `/var/tmp/linux-2.6.19.3'
> > make: *** [debian/stamp-build-kernel] Error 2
> >
> > The attached patch addresses the problem..
> 
> Scrub that - It exposes another problem in thunk.S which I missed...
> 
> 

Thanks. 1.0-04 should fix both issues.

> Regards, Paul.
-- 
Philippe.