Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - process stuck in pthread_mutex_lock 6.4.0 M7 armv6 : (3 Items)
   
process stuck in pthread_mutex_lock 6.4.0 M7 armv6  
Hello

I am trying to run io-usb on  an omap2420 (arm6) under 6.4.0 m7 and it is getting stuck (and hogging the cpu) inside a 
pthread_mutex_lock(). Getting a core file with dumper shows that one of the threads is spinning in arm6 specific code in
  _mux_smp_cmpxchg(). 


separate dumps report pc: 
pc             0x103024c        0x103024c <_mux_smp_cmpxchg+44>
pc             0x1030254        0x1030254 <_mux_smp_cmpxchg+52>
pc             0x103024c        0x103024c <_mux_smp_cmpxchg+44>

disassemble:
Dump of assembler code for function _mux_smp_cmpxchg:
0x01030220 <_mux_smp_cmpxchg+0>:        push    {r10, lr}
0x01030224 <_mux_smp_cmpxchg+4>:        ldr     r10, [pc, #92]  ; 0x1030288 <_mux_smp_cmpxchg+104>
0x01030228 <_mux_smp_cmpxchg+8>:        ldr     r12, [pc, #92]  ; 0x103028c <_mux_smp_cmpxchg+108>
0x0103022c <_mux_smp_cmpxchg+12>:       add     r10, pc, r10
0x01030230 <_mux_smp_cmpxchg+16>:       ldr     r12, [r10, r12]
0x01030234 <_mux_smp_cmpxchg+20>:       ldr     r12, [r12]
0x01030238 <_mux_smp_cmpxchg+24>:       tst     r12, #2 ; 0x2
0x0103023c <_mux_smp_cmpxchg+28>:       beq     0x1030264 <_mux_smp_cmpxchg+68>
0x01030240 <_mux_smp_cmpxchg+32>:       mcr     15, 0, r0, cr7, cr10, {5}
0x01030244 <_mux_smp_cmpxchg+36>:       mov     r12, r0
0x01030248 <_mux_smp_cmpxchg+40>:       ldrex   r0, [r12]
0x0103024c <_mux_smp_cmpxchg+44>:       teq     r0, r1
0x01030250 <_mux_smp_cmpxchg+48>:       strexeq r3, r2, [r12]
0x01030254 <_mux_smp_cmpxchg+52>:       teqeq   r3, #1  ; 0x1
0x01030258 <_mux_smp_cmpxchg+56>:       beq     0x1030248 <_mux_smp_cmpxchg+40>
0x0103025c <_mux_smp_cmpxchg+60>:       mcr     15, 0, r0, cr7, cr10, {5}
0x01030260 <_mux_smp_cmpxchg+64>:       pop     {r10, pc}
0x01030264 <_mux_smp_cmpxchg+68>:       add     r12, pc, #4     ; 0x4
0x01030268 <_mux_smp_cmpxchg+72>:       add     lr, pc, #12     ; 0xc
0x0103026c <_mux_smp_cmpxchg+76>:       sub     sp, sp, #1      ; 0x1
0x01030270 <_mux_smp_cmpxchg+80>:       ldr     r3, [r0]
0x01030274 <_mux_smp_cmpxchg+84>:       teq     r3, r1
0x01030278 <_mux_smp_cmpxchg+88>:       streq   r2, [r0]
0x0103027c <_mux_smp_cmpxchg+92>:       add     sp, sp, #1      ; 0x1
0x01030280 <_mux_smp_cmpxchg+96>:       mov     r0, r3
0x01030284 <_mux_smp_cmpxchg+100>:      pop     {r10, pc}
0x01030288 <_mux_smp_cmpxchg+104>:      andeq   r0, r4, r8, ror #19
0x0103028c <_mux_smp_cmpxchg+108>:      strheq  r0, [r0], -r4
End of assembler dump.






Re: process stuck in pthread_mutex_lock 6.4.0 M7 armv6  
Just to follow up - it looks like the problem was that the mutex was allocated in un-cached memory ... perhaps from a 
mmap_device_memory() call with the PROT_NOCACHE flag, but I am not too sure.  
Re: process stuck in pthread_mutex_lock 6.4.0 M7 armv6  
Hmm. The ARM ARM (DDI 0100I page A-52) lists some
restrictions on ldrex/strex usage. One of these is that
they "shall only be used on memory with the Normal
attribute".

PROT_NOCACHE sets up mappings with the Strongly
Ordered memory attribute (TEX/C/B=000/0/0) to
enforce strongly ordered access as required for I/O
registers etc. since mmap doesn't supply sufficient information to indicate whether the PROT_NOCACHE is
for device memory or uncached normal memory.
These require different TEX/C/B encodings, and in
addition, require memory barriers to be used when
it is necessary to enforce ordering.

The instructions used for memory barriers will cause
undefined instruction exceptions on pre-ARMv6
so can only be used in code that executes in a
privileged cpu mode, so it seemed using Strongly
Ordered memory would provide the simplest way to
maintain user space binary code compatibility for
ARMv4, ARMv5 and ARMv6.

I'll have to confirm what the behaviour for ldrex/strex
should be for the ARM1136 for Strongly Ordered
memory.

    Sunil.