[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [PATCH v7 00/73] per-CPU locks
From: |
Richard Henderson |
Subject: |
Re: [qemu-s390x] [PATCH v7 00/73] per-CPU locks |
Date: |
Wed, 6 Mar 2019 11:40:57 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
On 3/4/19 10:17 AM, Emilio G. Cota wrote:
> v6: https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07650.html
>
> All patches in the series have reviews now. Thanks everyone!
>
> I've tested all patches with `make check-qtest -j' for all targets.
> The series is checkpatch-clean (just some warnings about __COVERITY__).
>
> You can fetch the series from:
> https://github.com/cota/qemu/tree/cpu-lock-v7
Having fixed the OSX build errors, Peter reported to me a hang on the x86_64
bios-tables-test with an arm32 host. I have been able to replicate this.
(gdb) info thr
Id Target Id Frame
1 Thread 0xb35a72e0 (LWP 10966) "qemu-system-x86" 0xb606d138 in
pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
2 Thread 0xb35a3d30 (LWP 10967) "qemu-system-x86" 0xb5fe70fc in syscall ()
from /usr/lib/libc.so.6
3 Thread 0xa07fed30 (LWP 10968) "qemu-system-x86" 0xb5fe0688 in poll ()
from /usr/lib/libc.so.6
* 4 Thread 0x9fdfed30 (LWP 10969) "qemu-system-x86" 0xb606d138 in
pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
(gdb) thr 1
[Switching to thread 1 (Thread 0xb35a72e0 (LWP 10966))]
#0 0xb606d138 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
(gdb) where
#0 0xb606d138 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
#1 0x009a66a4 in qemu_cond_wait_impl (address@hidden,
mutex=0xcad4c8 <qemu_global_mutex>,
address@hidden "/home/rth/qemu/qemu/cpus-common.c",
address@hidden) at /home/rth/qemu/qemu/util/qemu-thread-posix.c:161
#2 0x00692378 in run_on_cpu (address@hidden, func=<optimized out>,
data=...) at /home/rth/qemu/qemu/cpus-common.c:166
#3 0x00604c18 in vapic_enable_tpr_reporting (enable=<optimized out>)
at /home/rth/qemu/qemu/hw/i386/kvmvapic.c:507
#4 0x00710160 in qdev_reset_one (dev=<optimized out>, opaque=<optimized out>)
at /home/rth/qemu/qemu/hw/core/qdev.c:250
(gdb) thr 4
[Switching to thread 4 (Thread 0x9fdfed30 (LWP 10969))]
#0 0xb606d138 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
(gdb) where
#0 0xb606d138 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
#1 0x009a66a4 in qemu_cond_wait_impl (cond=0x1692ed8,
mutex=0xcad4c8 <qemu_global_mutex>,
address@hidden "/home/rth/qemu/qemu/cpus.c",
address@hidden) at /home/rth/qemu/qemu/util/qemu-thread-posix.c:161
#2 0x00553070 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>)
at /home/rth/qemu/qemu/cpus.c:1647
#3 0x009a5f20 in qemu_thread_start (args=<optimized out>)
at /home/rth/qemu/qemu/util/qemu-thread-posix.c:502
I had hoped that I would have been able to reproduce this on another host by
forcing rr mode. But so far no luck.
Thoughts?
r~
- [qemu-s390x] [PATCH v7 00/73] per-CPU locks, Emilio G. Cota, 2019/03/04
- [qemu-s390x] [PATCH v7 36/73] s390x: use cpu_reset_interrupt, Emilio G. Cota, 2019/03/04
- [qemu-s390x] [PATCH v7 25/73] s390x: convert to cpu_halted, Emilio G. Cota, 2019/03/04
- [qemu-s390x] [PATCH v7 52/73] s390x: convert to cpu_interrupt_request, Emilio G. Cota, 2019/03/04
- [qemu-s390x] [PATCH v7 65/73] s390x: convert to cpu_has_work_with_iothread_lock, Emilio G. Cota, 2019/03/04
- Re: [qemu-s390x] [PATCH v7 00/73] per-CPU locks, Alex Bennée, 2019/03/05
- Re: [qemu-s390x] [PATCH v7 00/73] per-CPU locks,
Richard Henderson <=