Hi Philippe,

Back at work. See inline replies below.


> > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > > bits that prevent most alignment faults from triggering a secondary 
> > > > > mode
> > > > > switch. Andreas told me this works like a charm on 83xx, and I did not
> > > > > see any issue on 52xx, 85xx or 86xx either.
> > > > >
> > > >
> > > > Can I get a version of that patch for testing? Is it in your git
> > > > repository?
> > >
> > > I just pushed this commit to my remote tree (ipipe-2.6.30-powerpc
> > > branch); it should appear in a few hours once mirrored (cron job).
> > >
> >
> > I finally had a chance to test the ipipe-2.6.30-powerpc version
> > from the git repository. Unfortunately, I noticed that our application
> > dies after some time and that this behaviour is related to that
> > alignment patch (if I take it out everything runs fine for > 2 days).
> >
> > Currently I'm investigating the reasons for that crash. It has
> > something to do with floating point registers not being restored
> > properly. Our alignment exceptions are mainly triggered by accesses
> > to unaligned floating point data.
> 
> Does it work any better with this patch in?

I applied that patch but unfortunately our application still dies. I included
an application with with you (hopefully) can reproduce the problem 
which we are seeing. Our system is a MPC8360 with 2.6.30, ipipe 2.7,
xenomai 2.4.9.1.

Here are the steps:

1) apply ipipe with alignment patch, recompile kernel
2) comile test1.c (attached) with: 
        gcc -Wall -O2 `xeno-config --xeno-cflags` \
                                `xeno-config --xeno-ldflags` \
                                 -l native -l rtdk  -o test1 test1.c
3) Start test1 in one shell
4) Open a second shell and start 'switchbench'

Just when 'switchbench' is running, I get the following
output from my test application:
...
Missmatch: 0xfff8000082064000
Missmatch: 0xfff8000082064000
Missmatch: 0xfff8000082064000
Missmatch: 0xfff8000082064000 
...

It seems that test1 is interrupted right between
the lfd and stfd and the floating point regs aren't
restored properly.

Just a side note: I had to add assembly code to my
C program to force an alignment exception. gcc seems
to be smart enough to avoid unaligned access. g++
on the other hand (especially g++ 3.3.6 which we are 
using) seems to generate assembly code which causes
alignment exceptions. So it seems that it's really g++'s 
fault. We also discovered that our g++ generates buggy 
floating point assembly code when compiling with the 
-O2 or -Os option. Currently, we compile our application
with -msoft-float to avoid those issues which has the
nice side effect that we also don't get alignment exceptions
anymore.

Many thanks,
Andreas


> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 32cc3df..a04a5e3 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -80,7 +80,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
>                  * FPU, and then when we get scheduled again we would store
>                  * bogus values for the remaining FP registers.
>                  */
> -               ipipe_preempt_disable(flags);
> +               if (ipipe_root_domain_p)
> +                       preempt_disable();
> +               local_irq_save_hw_cond(flags);
>                 if (tsk->thread.regs->msr & MSR_FP) {
>  #ifdef CONFIG_SMP
>                         /*
> @@ -94,7 +96,9 @@ void flush_fp_to_thread(struct task_struct *tsk)
>  #endif
>                         giveup_fpu(tsk);
>                 }
> -               ipipe_preempt_enable(flags);
> +               local_irq_restore_hw_cond(flags);
> +               if (ipipe_root_domain_p)
> +                       preempt_enable();
>         }
>  }
/* vim: set ts = 4: */
#include <sys/mman.h>
#include <unistd.h>
#include <signal.h>
#include <string.h>
#include <stdarg.h>
#include <rtdk.h>
#include <native/task.h>

typedef struct msg {
	unsigned char id;
	union {
		unsigned long long raw;
		struct {
			unsigned short val1;
			unsigned long val2;
			unsigned short val3;
		} __attribute__((packed));
	};
} __attribute__((packed)) msg_t;

static RT_TASK task;
static msg_t msg;

int main(void)
{
	int err;

	mlockall(MCL_CURRENT|MCL_FUTURE);
	rt_print_auto_init(1);

	err = rt_task_shadow(&task, "main", 3, 0);
	if(!err) {
		/* Fill the message */
		msg.id = 0xFF;
		msg.val1 = 0x1234;
		msg.val2 = 0x56789ABC;
		msg.val3 = 0xDEF0;

		while(1) {
			double save;
			unsigned long long out = 0;

			/* Force an alignment exception
			   by accessing unaligned floating
			   point data (lfd 0,1(%2)). */
			__asm__ __volatile__(
			"stfd 0,%0   # save contents of f0 \n\t"
			"lfd 0,1(%2) # unaligned access \n\t"
			"stfd 0,%1   # store data in 'out' \n\t"
			"lfd 0,%0    # restore contents of f0 \n\t" 
			: "=m"(save), "=m"(out)
			: "r"(&msg)
			);

			if( out != msg.raw )
				rt_printf("Missmatch: 0x%llx\n", out);

			rt_task_sleep(100000ULL);
		}
	}
	return err;
}

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

Reply via email to