All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Xenomai-core] Xenomai on Xscale (Linux 2.6.20)
@ 2007-10-24 14:55 ROSSIER Daniel
  2007-10-24 15:30 ` Philippe Gerum
  2007-10-24 15:56 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 23+ messages in thread
From: ROSSIER Daniel @ 2007-10-24 14:55 UTC (permalink / raw)
  To: jan.kiszka; +Cc: xenomai

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


Hi all,

I've found a bug in arch/arm/xenomai/switch.S which solved the problem below. It actually comes from the iWMMXT (Intel Wireless MMX) coprocessor which is an extension of the ARM core in Xscale processor (and of course which is not available in the AT91 series ;-).

When a thread switch occurs, rthal_thread_switch(in arch/arm/xenomai/switch.S) is called to perform switching of registers and stacks between threads. The PXA version must also perform a switch of MMX registers by invoking iwmmxt_task_switch(in arch/arm/kernel/iwmmxt.S). This is done in rthal_task_switch() as well.

However, between Linux 2.6.15 and Linux 2.6.20, the general scheme of low-level task switching procedure changed a little bit: it is now relying on a call chain notifier-based mechanism. Therefore, the iwmmxt_task_switch() function has been updated since the function is called now from the notifier, and not directly from  __switch_to() as in 2.6.15. And the ipipe (ARM) patch did not take into account that.. and it fails. 

So, as a first workaround, I simply duplicated the iwmmxt_task_switch() function making the version (from 2.6.15) proprietary to ipipe by renaming to iwmmxt_task_switch_from_ipipe(), and modified arch/arm/xenomai/switch.S accordingly (be careful, switch.S is a symlink and actually belongs to Xenomai tree (ksrc/arch/arm).

It seems to work so far, but further tests are needed (and will be done).

I attached a patch to be applied in the (xenomai-patched) Linux tree.
(Linux 2.6.20, xenomai from today svn). 


Daniel


On Mon, 2007-10-22 at 19:07 +0200, Jan Kiszka wrote:
Patrick wrote:
> > Please ignore my first wrong mail ;-)
> > 
> >  
> > 
> > Hi,
> > 
> >  
> > 
> > I am trying to found the bug in xenomai for PXA270 machine (xenomai 2.3.4,
> > ipipe 1.7-06 and kernel 2.6.20).
> > 
> >  
> > 
> > I have localised that the problem is coming when rt_task_create call
> > __ipipe_restore_pipeline_head (called by xnlock_put_irq_restore) in
> > ipipe/core.c.
> > 
> > I think that the problem is the call to __clear_bit(IPIPE_STALL_FLAG,
> > &head->cpudata[cpuid].status); 
> 
> Is it the operation itself or the effect on cpudata.status? I mean, can
> you safely do a __clear_bit followed by a __set_bit, which would rule
> out an invalid memory access?
> 
> > 
> > If I don't execute this function on the rt_task_create the system doesn't
> > freeze (but my application doesn't work correctly).
> > 
> >  
> > 
> > I don't know what the problem is. Do you have an idea or a suggestion?
> 
> At least /me is lacking a full picture. So I would suggest, in order to
> ease the understanding of your scenario for everyone, to
> 
>  a) post your modification in form of a patch (diff -up).
>  b) catch the problematic execution path with the ipipe tracer - now
>     that it no longer fails lethally. Just put an ipipe_trace_freeze at
>     a point that is unique and close to the hot spot (e.g. after
>     rt_task_create.
> 
> Jan
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ipipe_iwmmxt.patch --]
[-- Type: text/x-patch; name="ipipe_iwmmxt.patch", Size: 1757 bytes --]

diff -Naur ../linux-2.6.20-col-xenomai.orig/arch/arm/kernel/iwmmxt.S ./arch/arm/kernel/iwmmxt.S
--- ../linux-2.6.20-col-xenomai.orig/arch/arm/kernel/iwmmxt.S	2007-10-24 15:24:54.000000000 +0200
+++ ./arch/arm/kernel/iwmmxt.S	2007-10-24 14:22:51.000000000 +0200
@@ -293,6 +293,25 @@
 	mrc	p15, 0, r1, c2, c0, 0
 	sub	pc, lr, r1, lsr #32		@ cpwait and return
 
+ENTRY(iwmmxt_task_switch_from_ipipe)
+
+	mrc	p15, 0, r4, c15, c1, 0
+	tst	r4, #0x3			@ CP0 and CP1 accessible?
+	bne	1f				@ yes: block them for next task
+
+	ldr	r5, =concan_owner
+	add	r6, r2, #(TI_IWMMXT_STATE - TI_CPU_DOMAIN) @ get next task Concan save area
+	ldr	r5, [r5]			@ get current Concan owner
+	teq	r5, r6				@ next task owns it?
+	movne	pc, lr				@ no: leave Concan disabled
+
+1:	eor	r4, r4, #3			@ flip Concan access
+	mcr	p15, 0, r4, c15, c1, 0
+
+	mrc	p15, 0, r4, c2, c0, 0
+	sub	pc, lr, r4, lsr #32		@ cpwait and return
+
+
 /*
  * Remove Concan ownership of given task
  *
diff -Naur ../linux-2.6.20-col-xenomai.orig/arch/arm/xenomai/switch.S ./arch/arm/xenomai/switch.S
--- ../linux-2.6.20-col-xenomai.orig/arch/arm/xenomai/switch.S	2007-10-24 14:25:59.000000000 +0200
+++ ./arch/arm/xenomai/switch.S	2007-10-24 14:57:49.000000000 +0200
@@ -59,6 +59,9 @@
     add     ip, r1, #TI_CPU_SAVE
     ldr     r3, [r2, #TI_TP_VALUE]
     stmia   ip!, {r4 - sl, fp, sp, lr}      @ Store most regs on stack
     ldr     r6, [r2, #TI_CPU_DOMAIN]!
 #if __LINUX_ARM_ARCH__ >= 6
 #ifdef CONFIG_CPU_MPCORE
@@ -86,7 +89,7 @@
     VFPFMXR FPEXC, r4
 #endif
 #if defined(CONFIG_IWMMXT)
-    bl      iwmmxt_task_switch
+    bl      iwmmxt_task_switch_from_ipipe
 #elif defined(CONFIG_CPU_XSCALE)
     add     r4, r2, #40                     @ cpu_context_save->extra
     ldmib   r4, {r4, r5}


^ permalink raw reply	[flat|nested] 23+ messages in thread
* [Xenomai-core] Xenomai on Xscale (Linux 2.6.20)
@ 2007-10-22 16:53 Patrick
  2007-10-22 17:07 ` Jan Kiszka
  2007-10-22 19:36 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 23+ messages in thread
From: Patrick @ 2007-10-22 16:53 UTC (permalink / raw)
  To: xenomai

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

Please ignore my first wrong mail ;-)

 

Hi,

 

I am trying to found the bug in xenomai for PXA270 machine (xenomai 2.3.4,
ipipe 1.7-06 and kernel 2.6.20).

 

I have localised that the problem is coming when rt_task_create call
__ipipe_restore_pipeline_head (called by xnlock_put_irq_restore) in
ipipe/core.c.

I think that the problem is the call to __clear_bit(IPIPE_STALL_FLAG,
&head->cpudata[cpuid].status); 

If I don't execute this function on the rt_task_create the system doesn't
freeze (but my application doesn't work correctly).

 

I don't know what the problem is. Do you have an idea or a suggestion?

 

Thanks

 

Patrick


[-- Attachment #2: Type: text/html, Size: 4747 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [Xenomai-core] Xenomai on Xscale (Linux 2.6.20)
@ 2007-10-11 16:35 ROSSIER Daniel
  2007-10-11 17:00 ` Philippe Gerum
  2007-10-11 17:02 ` Jan Kiszka
  0 siblings, 2 replies; 23+ messages in thread
From: ROSSIER Daniel @ 2007-10-11 16:35 UTC (permalink / raw)
  To: xenomai


Hi everyone,

I'm taking over the original thread from Patrick concerning the port of
Xenomai on Xscale with Linux 2.6.20. Briefly summarized, the boot
process actually freezes after a while right after the nucleus has been
started.

I've investigated the issue over the last hours, and I came up with the
following conclusion: it seems that the problem is due to a endless loop
in do_gettimeofday in arch/arm/kernel/time.c. Here is the code:

"...
do {
		seq = read_seqbegin_irqsave(&xtime_lock, flags);
		usec = system_timer->offset();
		sec = xtime.tv_sec;
		usec += xtime.tv_nsec / 1000;
	} while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
..."

If I remove the do { } while loop with the call to
read_seqbegin_irqsave(), then the boot process is going ahead (I got a
suspicious error like "I-pipe: Detected illicit call from domain
'Xenomai' " but it might well be normal with such a modification.

I checked with the code from a 2.6.15 kernel, and it is basically the
same structure.

Any idea about the cause of this problem?

I checked the timer IRQs and other pipeline activity, and everything
seems to be OK. By the way, if I disable the nucleus, Linux is working
properly (timer not being stolen by I-pipe).

Thanks in advance for any help.

Cheers
Daniel


^ permalink raw reply	[flat|nested] 23+ messages in thread
end of thread, other threads:[~2007-12-03 14:36 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-24 14:55 [Xenomai-core] Xenomai on Xscale (Linux 2.6.20) ROSSIER Daniel
2007-10-24 15:30 ` Philippe Gerum
2007-10-24 16:25   ` Gilles Chanteperdrix
2007-10-24 16:45     ` Philippe Gerum
2007-12-03 11:56       ` linux
2007-12-03 13:09         ` Gilles Chanteperdrix
2007-12-03 14:36         ` Patrick
2007-10-24 15:56 ` Gilles Chanteperdrix
  -- strict thread matches above, loose matches on Subject: below --
2007-10-22 16:53 Patrick
2007-10-22 17:07 ` Jan Kiszka
2007-10-22 19:36 ` Gilles Chanteperdrix
2007-10-11 16:35 ROSSIER Daniel
2007-10-11 17:00 ` Philippe Gerum
2007-10-12 12:28   ` Daniel Rossier
2007-10-12 12:43     ` Gilles Chanteperdrix
2007-10-11 17:02 ` Jan Kiszka
2007-10-12 11:48   ` Daniel Rossier
2007-10-12 12:34     ` Gilles Chanteperdrix
2007-10-12 12:46       ` Daniel Rossier
2007-10-12 13:14         ` Gilles Chanteperdrix
2007-10-13 15:34           ` ROSSIER Daniel
2007-10-13 17:06             ` Gilles Chanteperdrix
2007-10-22 16:38           ` Patrick

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.