Alright, I couldn't reproduce this yet, I'm running same test case in a 24 cores box and causing lots of context switches and CPU migrations in parallel (trying to exhaust the logic).
Will let this running for sometime to check. Unfortunately this can be related QEMU AIO BH locking/primitives and cache coherency in the HW in question (which I got specs from: https://en.wikichip.org/wiki/hisilicon/kunpeng/hi1616): l1$ size 8 MiB l1d$ size 4 MiB l1i$ size 4 MiB l2$ size 32 MiB l3$ size 64 MiB like for example when having 2 threads in different NUMA domains, or some other situation. I can't simulate the same since I have a SOC with: Cortex-A53 MPCore 24cores, L1 I/D=32KB/32KB L2 =256KB L3 =4MB and I'm not even close to L1/L2/L3 cache numbers from D06 =o). Just got a note that I'll be able to reproduce this in the real HW, will get back soon with real gdb debugging. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1805256 Title: qemu-img hangs on high core count ARM system To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1805256/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
