<big><big>Hi,<br>
    <br>
We have Linux running on our ARM Cortex-a9 (SMP) based platform.<br>
Test setup : Linux-2.6.35<br>
GLIBC : 2.11.<br>
    <br>
Test Scenario : We observed with our User application that the system is
 getting hanged at some point of time while keep doing power reset (with some delay).<br>
    <br>
1. Earlier we applied "Add PI/robust mutexes support for SMP kernels" to have PI-futex support on our kernel.</big></big><br><big><big> <a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017374.html" target="_blank">http://lists.infradead.org/<b style="color:black;background-color:#ffff66">pi</b>permail/linux-<b style="color:black;background-color:#ffff66">arm</b>-kernel/2010-June/017374.html</a><br>
 <br>
2. Found a problem while using pthread_mutex_lock, and it seems like at 
error occurrence, the status of mutex management data is getting 
corrupted.<br>
The error part of libpthread source (glibc-2.11/nptl/pthread_mutex_lock.c)is pasted below<br>
      <font color="#3333ff">  /* Check whether we already hold the mutex.  */<br>
        if (__builtin_expect ((oldval & FUTEX_TID_MASK) == id, 0))<br>
          {<br>
            if (kind == PTHREAD_MUTEX_ERRORCHECK_NP)<br>
              {<br>
                THREAD_SETMEM (THREAD_SELF, robust_head.list_op_pending, NULL);<br>
                <br>
                IMA_RESETLOG(0xA0,oldval,id,mutex->__data.__owner,0x3)        //err point code 03<br>
                return EDEADLK;<br>
              }</font><br>
 <br>
at this point the value of</big></big> <big><big><font color="#3333ff">mutex->__data.__owner <font color="#000000">becomes 0 or some other value</font></font></big></big>.<br>
<br>
<big><big>



        
        3. So we decided to apply Catalin's patch ie "ARM: Remove the domain 
switching on ARMv6k/v7 CPUs"  from "<a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/016997.html">http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/016997.html</a>". But there is some confusion in using this
 patch as it is because our system has TLS_REG so the macro 
CPU_USE_DOMAIN automatically get disabled.</big></big> <big><big>And with this patch we observe different behavior of the system.</big></big><br>
<br>
<big><big>4. Our concern here is do you have any patch related to User Ro Kernel Ro alone so that we can try it out that patch.</big></big> <br>
<br>
<big><big>Any valuable feedback will help us to solve this issue.<br>
    <br>
Thanks & Regards,<br>
A. Mydeen.</big></big>