On Fri, Nov 21, 2014 at 10:21 PM, Emre Can Kucukoglu <eca...@gmail.com>
wrote:

> Hi,
>
> I'm trying to analyze the overall and realtime performance of an
> preempt_rt patched Android kernel on Pandaboard.
> To achieve this, i modified the matching (linux kernel version match)
> preempt_rt patch.
>
> My android linux kernel version is 3.0.8.
>
> After successfully patching, I modified the configuration w/
> panda_defconfig and then according to preeempt_rt source
> <https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Configuration_and_Compilation>,
> full preemption is opened, high res timer is closed.
> Building is also done successfully. However while booting process, I'm
> getting
>
> BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
>

normally this means you called "might_sleep()" or any other blocking
functions (eg, most kernel memory allocation functions) inside the context
of spin locked area.   for example, your code:

+static inline void rt_spin_lock_fastlock(struct rt_mutex *lock,
+                                        void  (*slowfn)(struct rt_mutex
*lock))
+{
+       might_sleep();
+
+       if (likely(rt_mutex_cmpxchg(lock, NULL, current)))
+               rt_mutex_deadlock_account_lock(lock, current);
+       else
+               slowfn(lock);
+}

Not sure if there is any voluntary preemption embedded inside
"might_sleep()" or not, if there is, then the CPU can be scheduled out of
execution (it called "might_resched()", put on the waiting queue, and
another kernel threads continues the execution, ie, this function itself
can "sleep".


>
> After digging in a while, i realize that problem can be about basically
> from function call order. source
> <http://permalink.gmane.org/gmane.linux.rt.user/11691>.
>
>
the reason why spinlocks does not allow "sleeping" function to be called
within its context is because if there is a chance of wrong order of
locking/unlocking called, then you may ended up with a permanent deadlock,
and the nature of spinlock is that the CPU will keep looping for the lock
to be freed, resulting in CPU utilization goes into 100% and cannot be
preempted.


> Unfortunately, I still don't know the exact reason of this error, and how
> to fix it.
>
> Can anybody share own experience with me, to lead the way.
>
> Thanks.
>
> Emre Can Kucukoglu.
>
> *sources:*
> My android kernel source: *https://github.com/dlandoll/android_kernel_omap.git
> <https://github.com/dlandoll/android_kernel_omap.git> --branch=branch
> "android-omap-cm-panda-3.0"*
> *booting.log*: my booting debug outputs.
> *preempt_rt-on-android-3.0.8.tar.gz*: difference of my modified
> preempt_rt 3.0.8-rt23 patch from main preempt_rt 3.0.8-rt23.
>
> I have changed the following patches from preempt_rt 3.0.8-rt23:
> - arm-allow-irq-threading.patch
> - arm-raw_lock-conversions.patch
> - hwlatdetect.patch
> - rt-mutex-add-sleeping-spinlocks-support.patch
> - sched-use-schedule-preempt-disabled.patch
> - set-the-command-name-of-the-idle-tasks-in-smp-kernels-v3.patch
>
> Also did not apply these patches from preempt_rt 3.0.8-rt23:
> - arm-smp-online-fix.patch
> - plist-remove-spinlock-types-dependency.patch
>
> --




-- 
Regards,
Peter Teoh

-- 
-- 
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel
--- 
You received this message because you are subscribed to the Google Groups 
"Android Linux Kernel Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-kernel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to