Hello Steven,
 Do you recognise these warnings? I do not know (yet) if these are ARM

 specific...
  CC      kernel/rtmutex.o

 kernel/rtmutex.c: In function 'rt_write_fastlock':

 kernel/rtmutex.c:1582: warning: initialization makes pointer from

 integer without a cast

 kernel/rtmutex.c: In function 'rt_write_fasttrylock':

 kernel/rtmutex.c:1622: warning: initialization makes pointer from

 integer without a cast
 If so, do you have a fix for it?
 Regards,
 Remy

--

Remy,
Can you see if this helps,
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
---

 kernel/rtmutex.c |    6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.24.7-rt9/kernel/rtmutex.c

===================================================================

--- linux-2.6.24.7-rt9.orig/kernel/rtmutex.c	2008-05-20 17:11:29.000000000 -0400

+++ linux-2.6.24.7-rt9/kernel/rtmutex.c	2008-05-20 17:13:18.000000000 -0400

@@ -1577,7 +1577,7 @@ rt_write_fastlock(struct rw_mutex *rwm,

 		  void fastcall (*slowfn)(struct rw_mutex *rwm, int mtx),

 		  int mtx)

 {

-	unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;

+	struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);
 	if (likely(rt_rwlock_cmpxchg(rwm, NULL, val)))

 		rt_mutex_deadlock_account_lock(&rwm->mutex, current);

@@ -1617,7 +1617,7 @@ static inline int

 rt_write_fasttrylock(struct rw_mutex *rwm,

 		     int fastcall (*slowfn)(struct rw_mutex *rwm, int mtx), int mtx)

 {

-	unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;

+	struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);
 	if (likely(rt_rwlock_cmpxchg(rwm, NULL, val))) {

 		rt_mutex_deadlock_account_lock(&rwm->mutex, current);

@@ -1902,7 +1902,7 @@ rt_write_fastunlock(struct rw_mutex *rwm

 					    int mtx),

 		    int mtx)

 {

-	unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;

+	struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);
 	WARN_ON(rt_rwlock_owner(rwm) != current);

 	if (likely(rt_rwlock_cmpxchg(rwm, (struct task_struct *)val, NULL)))

--

Yes, this helps. Looks a little weird to add bitmasks to pointers, but

I understand why it has been done here.

BTW: I notice that you already has put it in -rt9.
And some other positive news: 2.6.24.7-rt9 compiles and boots

perfectly on ARM at91sam9261. (There are still a few other warnings,

but these are not RT related)
Now I understood your hint in some other mail, and I am going to take

a look at ftrace for ARM. Just for the fun of it...

I hope it is not too intrusive for these ARM cores (old implementation

was...), these Atmel cores are just not that fast as the common X86's.
Kind Regards,
Remy
--

If you feel brave, take a crack at the DYNAMIC_FTRACE. It's been done for

x86 (both 32 and 64 bit), PPC (also both 32 and 64 bit) as well as

Sparc64.
The dynamic ftrace is self modifying code, that will start off having

mcount simply call a nop. Then later it will change that to call a

"record_ip" function. A daemon is kicked off to change all the IPs that

are called into NOPs. When tracing is enabled, all the NOPs are converted

into calls to the trace function.
Dynamic ftrace also adds a "set_filter_function" in the /debugfs/tracing

directory that lets you echo in function names, and only those functions

will enable have tracing enabled.
All this helps tremendously in tracing performance and normal bootup. One

thing that you need to understand though. That daemon needs to call

kstop_machine to do the modifications. The daemon wakes up once a second,

checks to see if there is any new functions that have been recorded. If

not, then it simply goes back to sleep. But if there are new functions,

then it calls kstopmachine. This daemon stops when tracing is enabled, but

can cause unsuspecting latencies when tracing is disabled.
I'll probably add a something to disable the daemon just before firing off

init if PREEMPT_RT is enabled.
Any questions on porting ftrace, feel free to ask.
Cheers,
-- Steve
--

Ah, I guess ARM is a bit more critical of chpxchg than x86 is.
I'll add a patch for 2.6.24.7-rt9 (which I plan on releasing soon). It

will have some minor clean ups.
-- Steve
--