On Fri, Jan 15, 2016 at 4:25 PM, Alex Bennée <alex.ben...@linaro.org> wrote: > > alvise rigo <a.r...@virtualopensystems.com> writes: > >> On Fri, Jan 15, 2016 at 3:51 PM, Alex Bennée <alex.ben...@linaro.org> wrote: >>> >>> alvise rigo <a.r...@virtualopensystems.com> writes: >>> >>>> This problem could be related to a missing multi-threaded aware >>>> translation of the atomic instructions. >>>> I'm working on this missing piece, probably the next week I will >>>> publish something. >>> >>> Maybe. We still have Fred's: >>> >>> Use atomic cmpxchg to atomically check the exclusive value in a STREX >>> >>> Which I think papers over the cracks for both arm and aarch64 in MTTCG >>> while not being as correct as your work. >> >> Keep in mind that Linux on arm64 uses the LDXP/STXP instructions that >> exist solely in aarch64. >> These instructions are purely emulated now and can potentially write >> 128 bits of data in a non-atomic fashion. > > Sure, but I doubt they are the reason for this hang as the kernel > doesn't use them.
The kernel does use them for __cmpxchg_double in arch/arm64/include/asm/atomic_ll_sc.h. In any case, the normal exclusive instructions are also emulated in target-arm/translate-a64.c. alvise > >> >> Regards, >> alvise >> >>> >>>> >>>> Regards, >>>> alvise >>>> >>>> On Fri, Jan 15, 2016 at 3:24 PM, Pranith Kumar <bobby.pr...@gmail.com> >>>> wrote: >>>>> Hi Alex, >>>>> >>>>> On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée <alex.ben...@linaro.org> >>>>> wrote: >>>>>> Can you try this branch: >>>>>> >>>>>> >>>>>> https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks-r1 >>>>>> >>>>>> I think I've caught all the things likely to screw up addressing. >>>>>> >>>>> >>>>> I tried this branch and the boot hangs like follows: >>>>> >>>>> [ 2.001083] random: systemd-udevd urandom read with 1 bits of entropy >>>>> available >>>>> main-loop: WARNING: I/O thread spun for 1000 iterations >>>>> [ 23.778970] INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected >>>>> by 0, t=2102 jiffies, g=-165, c=-166, q=83) >>> >>> This is just saying the kernel has been waiting for a while and nothing >>> has happened. >>> >>>>> I will try to debug and see where it is hanging. >>> >>> If we knew what the kernel was waiting for that would be useful to know. >>> >>>>> >>>>> Thanks! >>>>> -- >>>>> Pranith >>> >>> >>> -- >>> Alex Bennée > > > -- > Alex Bennée