diff options
Diffstat (limited to 'results/classifier/118/all/1836855')
| -rw-r--r-- | results/classifier/118/all/1836855 | 182 |
1 files changed, 182 insertions, 0 deletions
diff --git a/results/classifier/118/all/1836855 b/results/classifier/118/all/1836855 new file mode 100644 index 000000000..f6f8f93b7 --- /dev/null +++ b/results/classifier/118/all/1836855 @@ -0,0 +1,182 @@ +permissions: 0.965 +debug: 0.960 +assembly: 0.959 +semantic: 0.957 +user-level: 0.957 +arm: 0.952 +PID: 0.950 +graphic: 0.950 +socket: 0.945 +register: 0.940 +architecture: 0.933 +boot: 0.931 +virtual: 0.931 +mistranslation: 0.929 +vnc: 0.927 +performance: 0.925 +kernel: 0.924 +risc-v: 0.921 +hypervisor: 0.920 +VMM: 0.915 +device: 0.914 +files: 0.905 +x86: 0.903 +KVM: 0.900 +i386: 0.896 +TCG: 0.893 +peripherals: 0.881 +network: 0.878 +ppc: 0.876 + +virtio_scsi_ctx_check failed when detach virtio_scsi disk + +I found a problem that virtio_scsi_ctx_check failed when detaching virtio_scsi disk. The bt is below: + +(gdb) bt +#0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +#1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +#2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +#5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +#6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +#7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +#8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +#9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +#10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +#11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +#12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +#13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +#14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 + +assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. + +I think this patch (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) introduce this problem. + +commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back to main AioContext on unplug. It set the AioContext of + +SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContext. Is this a bug? + +On Wed, Jul 17, 2019 at 08:20:35AM -0000, 贞贵李 wrote: +> Public bug reported: +> +> I found a problem that virtio_scsi_ctx_check failed when detaching +> virtio_scsi disk. The bt is below: +> +> (gdb) bt +> #0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +> #1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +> #2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +> #3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +> #4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +> #5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +> #6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +> #7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +> #8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +> #9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +> #10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +> #11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +> #12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +> #13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +> #14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 +> +> assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. +> +> I think this patch +> (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) +> introduce this problem. +> +> commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back +> to main AioContext on unplug. It set the AioContext of +> +> SCSIDevice to the main AioContex, but s->ctx is still the iothread +> AioContext. Is this a bug? + +The backtrace shows that virtqueue processing is happening in the +IOThread. This is expected so now the question is why the +BlockBackend's AioContext is the main AioContext. + +Can you share steps for reproducing this bug? + +Thanks! + +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1836855 +> +> Title: +> virtio_scsi_ctx_check failed when detach virtio_scsi disk +> +> Status in QEMU: +> New +> +> Bug description: +> I found a problem that virtio_scsi_ctx_check failed when detaching +> virtio_scsi disk. The bt is below: +> +> (gdb) bt +> #0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +> #1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +> #2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +> #3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +> #4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +> #5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +> #6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +> #7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +> #8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +> #9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +> #10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +> #11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +> #12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +> #13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +> #14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 +> +> assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. +> +> I think this patch +> (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) +> introduce this problem. +> +> commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend +> back to main AioContext on unplug. It set the AioContext of +> +> SCSIDevice to the main AioContex, but s->ctx is still the iothread +> AioContext. Is this a bug? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1836855/+subscriptions +> + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |