diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/all/1708 | 97 | ||||
| -rw-r--r-- | results/classifier/118/all/1708442 | 367 | ||||
| -rw-r--r-- | results/classifier/118/all/1708551 | 172 | ||||
| -rw-r--r-- | results/classifier/118/all/1708617 | 64 |
4 files changed, 700 insertions, 0 deletions
diff --git a/results/classifier/118/all/1708 b/results/classifier/118/all/1708 new file mode 100644 index 00000000..fd5b9049 --- /dev/null +++ b/results/classifier/118/all/1708 @@ -0,0 +1,97 @@ +permissions: 0.970 +architecture: 0.959 +arm: 0.958 +performance: 0.956 +register: 0.956 +device: 0.955 +debug: 0.952 +files: 0.943 +graphic: 0.943 +PID: 0.939 +user-level: 0.938 +assembly: 0.936 +risc-v: 0.935 +semantic: 0.933 +virtual: 0.926 +vnc: 0.918 +VMM: 0.914 +kernel: 0.906 +mistranslation: 0.900 +ppc: 0.895 +peripherals: 0.891 +x86: 0.881 +i386: 0.879 +TCG: 0.879 +boot: 0.876 +network: 0.876 +KVM: 0.870 +hypervisor: 0.868 +socket: 0.838 + +RISCV: Illegal instruction delegated to VS mode sets the wrong vscause value +Description of problem: +When delegating an illegal instruction exception caused in VS-mode to VS-mode, the vscause value for an illegal instruction is set incorrectly. + +Steps to reproduce: +1. Delegate 2(,6,10) in medeleg and hedeleg. +2. Enter VS-mode +3. Cause an illegal instruction fault, cause 6 can't happen in QEMU since there is misaligned support and 10 can't be delegated to VS mode. +4. The (v)scause CSR is then set to 1, i.e. instruction access fault which isn't correct. + +I have located the issue in the code @ cpu_helper.c:1703 +``` +if ((cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` + +The if statement should include a check for the async otherwise the cause shouldn't be altered. The patch I propose is simply to **and** the current statement with async. +``` +if (async & (cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` +Additional information: +Log where the incorrect cause is set. Note this line: `DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0` +``` +TRACE: [src/hart_ctrl.c:35] STARTING CPU 0 +TRACE: [src/page_tables.c:343] Setting up page tables between 0x80000000 -> 0x81c00000 +TRACE: [src/page_tables.c:359] Setting up page tables between 0x81c01000 -> 0x81c02000 +TRACE: [src/page_tables.c:374] Setting up page tables for UART 0x10000000 +TRACE: [src/page_tables.c:386] Setting up page tables for CLINT 0x2000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x24000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28001000 +TRACE: [src/main.c:32] STARTING HYPERVISOR TESTS +DEBUG: [src/util_fn.c:1175] pmpcfg0 = 0x00000000000f000f +DEBUG: [src/util_fn.c:1176] pmpcfg2 = 0x0000000000000000 +PMP Entry : 0 +Low Address : 0x0 +High Address : 0x81c00000 +Address Range : 0x0 - 0x81c00000 +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +PMP Entry : 2 +Low Address : 0x82000000 +High Address : 0xfffffffffffffffc +Address Range : 0x82000000 - 0xfffffffffffffffc +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +DEBUG: [src/trap_trigger.c: 85] Switching mode to VS +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x00000000800062a4, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 102] Illegal instruction exception: MEPC = 0x800062a4, MTVAL = 0x0 +TRACE: [src/util_fn.c:374] Done switching mode +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x0000000080008850, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0 +ERROR: [src/trap_handling.c:158] The following assert failed: mask_cause == cause2check +mask_cause = 0x1 diff --git a/results/classifier/118/all/1708442 b/results/classifier/118/all/1708442 new file mode 100644 index 00000000..bdb2550c --- /dev/null +++ b/results/classifier/118/all/1708442 @@ -0,0 +1,367 @@ +device: 0.925 +user-level: 0.921 +register: 0.915 +performance: 0.898 +permissions: 0.897 +debug: 0.897 +graphic: 0.895 +virtual: 0.890 +files: 0.883 +mistranslation: 0.879 +hypervisor: 0.877 +ppc: 0.875 +architecture: 0.875 +TCG: 0.874 +KVM: 0.871 +arm: 0.869 +risc-v: 0.867 +x86: 0.861 +semantic: 0.860 +assembly: 0.860 +vnc: 0.847 +VMM: 0.845 +PID: 0.838 +socket: 0.827 +peripherals: 0.827 +boot: 0.816 +i386: 0.803 +network: 0.796 +kernel: 0.784 + +Crash(assert) during reading image from http url through qemu-nbd + +Description: +During reading image from nbd device mounted by qemu-nbd server with url backend I/O error happens +"blk_update_request: I/O error, dev nbd0, sector 42117" dmesg. After some investigation I found that qemu-nbd server aborts in aio_co_enter() assert in util/async.c:468. + + +Steps to reproduce: + +1) sudo go run qemu-nbd-bug-report/qemu-nbd-bug.go (see qemu-nbd-bug-report.tar.gz) + +or try directly + +1) qemu-nbd -c /dev/nbd0 -r -v --aio=native -f qcow2 json:{"file.driver":"http","file.url":"http://localhost:9666/image","file.readahead":3276800 +2) try read whole nbd device while error in dmesg appears x + +Versions: + +1) qemu built from sources(/configure --target-list=x86_64-softmmu --disable-user --enable-curl --enable-linux-aio --enable-virtfs --enable-debug --disable-pie +, top commit 5619c179057e24195ff19c8fe6d6a6cbcb16ed28): + +qemu-nbd -v +qemu-nbd 2.9.90 (v2.10.0-rc0-67-g5619c17) + +2) libcurl(built from sources, top commit 1767adf4399bb3be29121435e1bb1cc2bc05f7bf): + +curl -V +curl 7.55.0-DEV (Linux) libcurl/7.55.0-DEV OpenSSL/1.0.2g zlib/1.2.8 + + +Backtrace: +(gdb) bt +#0 0x00007f7131426428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f713142802a in __GI_abort () at abort.c:89 +#2 0x00007f713141ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x54c924 "self != co", + file=file@entry=0x54c871 "util/async.c", line=line@entry=468, + function=function@entry=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:92 +#3 0x00007f713141ec82 in __GI___assert_fail (assertion=0x54c924 "self != co", file=0x54c871 "util/async.c", line=468, + function=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:101 +#4 0x00000000004fe6a2 in aio_co_enter (ctx=0xf0ddb0, co=0xf14650) at util/async.c:468 +#5 0x00000000004fe637 in aio_co_wake (co=0xf14650) at util/async.c:456 +#6 0x0000000000495c8a in curl_read_cb (ptr=0xf566d9, size=1, nmemb=16135, opaque=0xf1cb90) at block/curl.c:275 +#7 0x00007f713242ac24 in Curl_client_chop_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +#8 0x00007f713242ae03 in Curl_client_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +#9 0x00007f713244e1cf in readwrite_data () from /usr/lib/x86_64-linux-gnu/libcurl.so +#10 0x00007f713244eb6f in Curl_readwrite () from /usr/lib/x86_64-linux-gnu/libcurl.so +#11 0x00007f713245c1bb in multi_runsingle () from /usr/lib/x86_64-linux-gnu/libcurl.so +#12 0x00007f713245d819 in multi_socket () from /usr/lib/x86_64-linux-gnu/libcurl.so +#13 0x00007f713245e067 in curl_multi_socket_action () from /usr/lib/x86_64-linux-gnu/libcurl.so +#14 0x0000000000497555 in curl_setup_preadv (bs=0xf16820, acb=0x7f712d379860) at block/curl.c:918 +#15 0x00000000004975fb in curl_co_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/curl.c:935 +#16 0x000000000047730f in bdrv_driver_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/io.c:836 +#17 0x0000000000477c1f in bdrv_aligned_preadv (child=0xf1be20, req=0x7f712d379a60, offset=6556160, bytes=512, align=1, + qiov=0x7f712d379b40, flags=0) at block/io.c:1086 +#18 0x0000000000478109 in bdrv_co_preadv (child=0xf1be20, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/io.c:1180 +#19 0x0000000000437498 in qcow2_co_preadv (bs=0xf0fdc0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/qcow2.c:1812 +#20 0x000000000047730f in bdrv_driver_preadv (bs=0xf0fdc0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/io.c:836 +#21 0x0000000000477c1f in bdrv_aligned_preadv (child=0xf1c0d0, req=0x7f712d379d30, offset=21563904, bytes=512, align=1, + qiov=0x7f712d379e80, flags=0) at block/io.c:1086 +#22 0x0000000000478109 in bdrv_co_preadv (child=0xf1c0d0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/io.c:1180 +#23 0x00000000004645ad in blk_co_preadv (blk=0xf1be90, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) + at block/block-backend.c:991 +#24 0x00000000004646fa in blk_read_entry (opaque=0x7f712d379ea0) at block/block-backend.c:1038 +#25 0x000000000046481c in blk_prw (blk=0xf1be90, offset=21563904, +---Type <return> to continue, or q <return> to quit--- + buf=0xf7f000 "2,NV\241t!\ti\312\vp\364\017Kl*\354\021\a\177\021\260\b\027\212\347\027\004\322\nG\340b\\\306pG\332\313\060\341;\002\360\063L\240\027T \211\341\305\022АE\230\356DǮ}\211\bx\016\a\b\313\350\316\064.\017\372\032-R\376z\261\263\350|cQ<\016S_L\340A\221\366~L#\001+\271\204\065~\327\023\027I\211\343\361\276zT$4\336\273ˏ\353ʪ\234\016_Z|TMk\"\370\002\363~\334\332.\a\375\265mӌ{/%\304֎\374sF<E\371\031o&\202\217\226\276>I\356\302\375F\340\332\324\021\202\232>\026\261\233\303tv\023\304\006\243\037\062BϏ\b\324rs\360'"..., bytes=512, co_entry=0x4646aa <blk_read_entry>, flags=0) at block/block-backend.c:1074 +#26 0x0000000000464f81 in blk_pread (blk=0xf1be90, offset=21563904, buf=0xf7f000, count=512) at block/block-backend.c:1227 +#27 0x00000000004906cb in nbd_trip (opaque=0xf5a940) at nbd/server.c:1380 +#28 0x000000000051c0a5 in coroutine_trampoline (i0=15812176, i1=0) at util/coroutine-ucontext.c:79 +#29 0x00007f713143b5d0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#30 0x00007f712d47a770 in ?? () +#31 0x0000000000000000 in ?? () +Backtrace stopped: Cannot access memory at address 0x7f712d37a000 + + + +On 08/03/2017 07:12 AM, Andrey Smetanin wrote: +> Public bug reported: +> +> Description: +> During reading image from nbd device mounted by qemu-nbd server with url backend I/O error happens +> "blk_update_request: I/O error, dev nbd0, sector 42117" dmesg. After some investigation I found that qemu-nbd server aborts in aio_co_enter() assert in util/async.c:468. +> + +Based on the backtrace, this looks to be a bug in the block/curl.c +driver, rather than the nbd/ or block/nbd.c code. If I'm right, it +should be possible to reproduce the crash using qemu-io directly on the +curl path, rather than adding the extra layer of an nbd client reading +through qemu-nbd (then again, having the qemu-nbd layer may be what is +allowing multiple parallel requests to hit the curl driver at once, +while qemu-io is not quite as easy to provoke into performing +complicated access patterns). + +> +> Steps to reproduce: +> +> 1) sudo go run qemu-nbd-bug-report/qemu-nbd-bug.go (see qemu-nbd-bug- +> report.tar.gz) +> +> or try directly +> +> 1) qemu-nbd -c /dev/nbd0 -r -v --aio=native -f qcow2 json:{"file.driver":"http","file.url":"http://localhost:9666/image","file.readahead":3276800 + +Presumably, you've got something serving the file at port 9666? + +> 2) try read whole nbd device while error in dmesg appears x +> +> Versions: +> +> 1) qemu built from sources(/configure --target-list=x86_64-softmmu --disable-user --enable-curl --enable-linux-aio --enable-virtfs --enable-debug --disable-pie +> , top commit 5619c179057e24195ff19c8fe6d6a6cbcb16ed28): +> +> qemu-nbd -v +> qemu-nbd 2.9.90 (v2.10.0-rc0-67-g5619c17) +> +> 2) libcurl(built from sources, top commit +> 1767adf4399bb3be29121435e1bb1cc2bc05f7bf): +> +> curl -V +> curl 7.55.0-DEV (Linux) libcurl/7.55.0-DEV OpenSSL/1.0.2g zlib/1.2.8 +> +> +> Backtrace: +> (gdb) bt +> #0 0x00007f7131426428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +> #1 0x00007f713142802a in __GI_abort () at abort.c:89 +> #2 0x00007f713141ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x54c924 "self != co", +> file=file@entry=0x54c871 "util/async.c", line=line@entry=468, +> function=function@entry=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:92 +> #3 0x00007f713141ec82 in __GI___assert_fail (assertion=0x54c924 "self != co", file=0x54c871 "util/async.c", line=468, +> function=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:101 +> #4 0x00000000004fe6a2 in aio_co_enter (ctx=0xf0ddb0, co=0xf14650) at util/async.c:468 +> #5 0x00000000004fe637 in aio_co_wake (co=0xf14650) at util/async.c:456 +> #6 0x0000000000495c8a in curl_read_cb (ptr=0xf566d9, size=1, nmemb=16135, opaque=0xf1cb90) at block/curl.c:275 +> #7 0x00007f713242ac24 in Curl_client_chop_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #8 0x00007f713242ae03 in Curl_client_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #9 0x00007f713244e1cf in readwrite_data () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #10 0x00007f713244eb6f in Curl_readwrite () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #11 0x00007f713245c1bb in multi_runsingle () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #12 0x00007f713245d819 in multi_socket () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #13 0x00007f713245e067 in curl_multi_socket_action () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #14 0x0000000000497555 in curl_setup_preadv (bs=0xf16820, acb=0x7f712d379860) at block/curl.c:918 +> #15 0x00000000004975fb in curl_co_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/curl.c:935 + +The backtrace is definitely pointing at curl as being the problem. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +03.08.2017, 17:01, "Eric Blake" <email address hidden>: +> On 08/03/2017 07:12 AM, Andrey Smetanin wrote: +>> Public bug reported: +>> +>> Description: +>> During reading image from nbd device mounted by qemu-nbd server with url backend I/O error happens +>> "blk_update_request: I/O error, dev nbd0, sector 42117" dmesg. After some investigation I found that qemu-nbd server aborts in aio_co_enter() assert in util/async.c:468. +> +> Based on the backtrace, this looks to be a bug in the block/curl.c +> driver, rather than the nbd/ or block/nbd.c code. If I'm right, it +> should be possible to reproduce the crash using qemu-io directly on the +> curl path, rather than adding the extra layer of an nbd client reading +> through qemu-nbd (then again, having the qemu-nbd layer may be what is +> allowing multiple parallel requests to hit the curl driver at once, +> while qemu-io is not quite as easy to provoke into performing +> complicated access patterns). +> +>> Steps to reproduce: +>> +>> 1) sudo go run qemu-nbd-bug-report/qemu-nbd-bug.go (see qemu-nbd-bug- +>> report.tar.gz) +>> +>> or try directly +>> +>> 1) qemu-nbd -c /dev/nbd0 -r -v --aio=native -f qcow2 json:{"file.driver":"http","file.url":"http://localhost:9666/image","file.readahead":3276800 +> +> Presumably, you've got something serving the file at port 9666? +Yes, you are right. I'm using qemu-nbd-bug.go(see qemu-nbd-bug-report.tar.gz) script which does it. +> +>> 2) try read whole nbd device while error in dmesg appears x +>> +>> Versions: +>> +>> 1) qemu built from sources(/configure --target-list=x86_64-softmmu --disable-user --enable-curl --enable-linux-aio --enable-virtfs --enable-debug --disable-pie +>> , top commit 5619c179057e24195ff19c8fe6d6a6cbcb16ed28): +>> +>> qemu-nbd -v +>> qemu-nbd 2.9.90 (v2.10.0-rc0-67-g5619c17) +>> +>> 2) libcurl(built from sources, top commit +>> 1767adf4399bb3be29121435e1bb1cc2bc05f7bf): +>> +>> curl -V +>> curl 7.55.0-DEV (Linux) libcurl/7.55.0-DEV OpenSSL/1.0.2g zlib/1.2.8 +>> +>> Backtrace: +>> (gdb) bt +>> #0 0x00007f7131426428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +>> #1 0x00007f713142802a in __GI_abort () at abort.c:89 +>> #2 0x00007f713141ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x54c924 "self != co", +>> file=file@entry=0x54c871 "util/async.c", line=line@entry=468, +>> function=function@entry=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:92 +>> #3 0x00007f713141ec82 in __GI___assert_fail (assertion=0x54c924 "self != co", file=0x54c871 "util/async.c", line=468, +>> function=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:101 +>> #4 0x00000000004fe6a2 in aio_co_enter (ctx=0xf0ddb0, co=0xf14650) at util/async.c:468 +>> #5 0x00000000004fe637 in aio_co_wake (co=0xf14650) at util/async.c:456 +>> #6 0x0000000000495c8a in curl_read_cb (ptr=0xf566d9, size=1, nmemb=16135, opaque=0xf1cb90) at block/curl.c:275 +>> #7 0x00007f713242ac24 in Curl_client_chop_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #8 0x00007f713242ae03 in Curl_client_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #9 0x00007f713244e1cf in readwrite_data () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #10 0x00007f713244eb6f in Curl_readwrite () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #11 0x00007f713245c1bb in multi_runsingle () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #12 0x00007f713245d819 in multi_socket () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #13 0x00007f713245e067 in curl_multi_socket_action () from /usr/lib/x86_64-linux-gnu/libcurl.so +>> #14 0x0000000000497555 in curl_setup_preadv (bs=0xf16820, acb=0x7f712d379860) at block/curl.c:918 +>> #15 0x00000000004975fb in curl_co_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/curl.c:935 +> +> The backtrace is definitely pointing at curl as being the problem. +> +> -- +> Eric Blake, Principal Software Engineer +> Red Hat, Inc. +1-919-301-3266 +> Virtualization: qemu.org | libvirt.org +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1708442 +> +> Title: +> Crash(assert) during reading image from http url through qemu-nbd +> +> Status in QEMU: +> New +> +> Bug description: +> Description: +> During reading image from nbd device mounted by qemu-nbd server with url backend I/O error happens +> "blk_update_request: I/O error, dev nbd0, sector 42117" dmesg. After some investigation I found that qemu-nbd server aborts in aio_co_enter() assert in util/async.c:468. +> +> Steps to reproduce: +> +> 1) sudo go run qemu-nbd-bug-report/qemu-nbd-bug.go (see qemu-nbd-bug- +> report.tar.gz) +> +> or try directly +> +> 1) qemu-nbd -c /dev/nbd0 -r -v --aio=native -f qcow2 json:{"file.driver":"http","file.url":"http://localhost:9666/image","file.readahead":3276800 +> 2) try read whole nbd device while error "blk_update_request: I/O error, dev nbd0, sector 42117" appears in dmesg +> +> Versions: +> +> 1) qemu built from sources(/configure --target-list=x86_64-softmmu --disable-user --enable-curl --enable-linux-aio --enable-virtfs --enable-debug --disable-pie +> , top commit 5619c179057e24195ff19c8fe6d6a6cbcb16ed28): +> +> qemu-nbd -v +> qemu-nbd 2.9.90 (v2.10.0-rc0-67-g5619c17) +> +> 2) libcurl(built from sources, top commit +> 1767adf4399bb3be29121435e1bb1cc2bc05f7bf): +> +> curl -V +> curl 7.55.0-DEV (Linux) libcurl/7.55.0-DEV OpenSSL/1.0.2g zlib/1.2.8 +> +> Backtrace: +> (gdb) bt +> #0 0x00007f7131426428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +> #1 0x00007f713142802a in __GI_abort () at abort.c:89 +> #2 0x00007f713141ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x54c924 "self != co", +> file=file@entry=0x54c871 "util/async.c", line=line@entry=468, +> function=function@entry=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:92 +> #3 0x00007f713141ec82 in __GI___assert_fail (assertion=0x54c924 "self != co", file=0x54c871 "util/async.c", line=468, +> function=0x54c980 <__PRETTY_FUNCTION__.24766> "aio_co_enter") at assert.c:101 +> #4 0x00000000004fe6a2 in aio_co_enter (ctx=0xf0ddb0, co=0xf14650) at util/async.c:468 +> #5 0x00000000004fe637 in aio_co_wake (co=0xf14650) at util/async.c:456 +> #6 0x0000000000495c8a in curl_read_cb (ptr=0xf566d9, size=1, nmemb=16135, opaque=0xf1cb90) at block/curl.c:275 +> #7 0x00007f713242ac24 in Curl_client_chop_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #8 0x00007f713242ae03 in Curl_client_write () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #9 0x00007f713244e1cf in readwrite_data () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #10 0x00007f713244eb6f in Curl_readwrite () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #11 0x00007f713245c1bb in multi_runsingle () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #12 0x00007f713245d819 in multi_socket () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #13 0x00007f713245e067 in curl_multi_socket_action () from /usr/lib/x86_64-linux-gnu/libcurl.so +> #14 0x0000000000497555 in curl_setup_preadv (bs=0xf16820, acb=0x7f712d379860) at block/curl.c:918 +> #15 0x00000000004975fb in curl_co_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/curl.c:935 +> #16 0x000000000047730f in bdrv_driver_preadv (bs=0xf16820, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/io.c:836 +> #17 0x0000000000477c1f in bdrv_aligned_preadv (child=0xf1be20, req=0x7f712d379a60, offset=6556160, bytes=512, align=1, +> qiov=0x7f712d379b40, flags=0) at block/io.c:1086 +> #18 0x0000000000478109 in bdrv_co_preadv (child=0xf1be20, offset=6556160, bytes=512, qiov=0x7f712d379b40, flags=0) at block/io.c:1180 +> #19 0x0000000000437498 in qcow2_co_preadv (bs=0xf0fdc0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) +> at block/qcow2.c:1812 +> #20 0x000000000047730f in bdrv_driver_preadv (bs=0xf0fdc0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) +> at block/io.c:836 +> #21 0x0000000000477c1f in bdrv_aligned_preadv (child=0xf1c0d0, req=0x7f712d379d30, offset=21563904, bytes=512, align=1, +> qiov=0x7f712d379e80, flags=0) at block/io.c:1086 +> #22 0x0000000000478109 in bdrv_co_preadv (child=0xf1c0d0, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) +> at block/io.c:1180 +> #23 0x00000000004645ad in blk_co_preadv (blk=0xf1be90, offset=21563904, bytes=512, qiov=0x7f712d379e80, flags=0) +> at block/block-backend.c:991 +> #24 0x00000000004646fa in blk_read_entry (opaque=0x7f712d379ea0) at block/block-backend.c:1038 +> #25 0x000000000046481c in blk_prw (blk=0xf1be90, offset=21563904, +> ---Type <return> to continue, or q <return> to quit--- +> buf=0xf7f000 "2,NV\241t!\ti\312\vp\364\017Kl*\354\021\a\177\021\260\b\027\212\347\027\004\322\nG\340b\\\306pG\332\313\060\341;\002\360\063L\240\027T \211\341\305\022АE\230\356DǮ}\211\bx\016\a\b\313\350\316\064.\017\372\032-R\376z\261\263\350|cQ<\016S_L\340A\221\366~L#\001+\271\204\065~\327\023\027I\211\343\361\276zT$4\336\273ˏ\353ʪ\234\016_Z|TMk\"\370\002\363~\334\332.\a\375\265mӌ{/%\304֎\374sF<E\371\031o&\202\217\226\276>I\356\302\375F\340\332\324\021\202\232>\026\261\233\303tv\023\304\006\243\037\062BϏ\b\324rs\360'"..., bytes=512, co_entry=0x4646aa <blk_read_entry>, flags=0) at block/block-backend.c:1074 +> #26 0x0000000000464f81 in blk_pread (blk=0xf1be90, offset=21563904, buf=0xf7f000, count=512) at block/block-backend.c:1227 +> #27 0x00000000004906cb in nbd_trip (opaque=0xf5a940) at nbd/server.c:1380 +> #28 0x000000000051c0a5 in coroutine_trampoline (i0=15812176, i1=0) at util/coroutine-ucontext.c:79 +> #29 0x00007f713143b5d0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +> #30 0x00007f712d47a770 in ?? () +> #31 0x0000000000000000 in ?? () +> Backtrace stopped: Cannot access memory at address 0x7f712d37a000 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1708442/+subscriptions + + +I've build qemu-nbd-bug.go into binary qemu-nbd-bug (go build qemu-nbd-bug.go), so to reproduce bug anyone may try: +0) ensure image.img exists in current folder. image.img may be copied from "Qemu-nbd core dump and script to reproduce " attachment. +1) sudo ./qemu-nbd-bug +2) wait while binary aborting(panicking) +3) check dmesg for error like "blk_update_request: I/O error, dev nbd0, sector 42117" +4) check qemu-nbd core dump (since it's aborting due to assert in aio_co_enter(), util/async.c:468). + +I've attached patch which resolves bug, but actually it's just workaround and may be not unsafe, because it's just ignore assert. + +ping + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/all/1708551 b/results/classifier/118/all/1708551 new file mode 100644 index 00000000..22e00352 --- /dev/null +++ b/results/classifier/118/all/1708551 @@ -0,0 +1,172 @@ +PID: 0.955 +architecture: 0.945 +permissions: 0.940 +graphic: 0.940 +arm: 0.939 +socket: 0.934 +user-level: 0.934 +boot: 0.934 +register: 0.929 +device: 0.929 +performance: 0.928 +assembly: 0.924 +network: 0.923 +virtual: 0.923 +semantic: 0.918 +files: 0.917 +debug: 0.916 +risc-v: 0.914 +peripherals: 0.910 +vnc: 0.899 +hypervisor: 0.898 +KVM: 0.896 +ppc: 0.887 +kernel: 0.875 +x86: 0.868 +TCG: 0.853 +mistranslation: 0.846 +VMM: 0.838 +i386: 0.718 + +macOS Guest Reading USB 3.0 Bus as USB 2.0 + +Description: +I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes. + +Parameters: +QEMU release version: 2.10.0-rc0 +Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)] +Command Line: https://pastebin.com/pBSYbrW1 +Host: Arch Linux +Guest: macOS v10.12.6 +Guest System Info: https://pastebin.com/U1Tihxei + +Notes: +1. Observed sometime after late-May-early-June of this year. + +2. Due to [a defect in qemu v2.8 which affected GTK users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent change to macOS' booting process conflicting with qemu v2.9](https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as -rc1 fails to load OVMF right now). + +Could you please try to run QEMU without the "-usb" option here? "-usb" automatically creates an EHCI and UHCI controller on the q35 machine, so that might be the reason that your USB devices get connected as USB 2.0 instead. + +Doing so returns: +`qemu-system-x86_64: -device usb-tablet,bus=usb-bus.0: Bus 'usb-bus.0' not found` + +> On Aug 4, 2017, at 2:31 AM, Thomas Huth <email address hidden> wrote: +> +> Could you please try to run QEMU without the "-usb" option here? "-usb" +> automatically creates an EHCI and UHCI controller on the q35 machine, so +> that might be the reason that your USB devices get connected as USB 2.0 +> instead. +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1708551 +> +> Title: +> macOS Guest Reading USB 3.0 Bus as USB 2.0 +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Description: +> I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes. +> +> Parameters: +> QEMU release version: 2.10.0-rc0 +> Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)] +> Command Line: https://pastebin.com/pBSYbrW1 +> Host: Arch Linux +> Guest: macOS v10.12.6 +> Guest System Info: https://pastebin.com/U1Tihxei +> +> Notes: +> 1. Observed sometime after late-May-early-June of this year. +> +> 2. Due to [a defect in qemu v2.8 which affected GTK +> users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent +> change to macOS' booting process conflicting with qemu +> v2.9](https://lists.nongnu.org/archive/html/qemu- +> devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as +> -rc1 fails to load OVMF right now). +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1708551/+subscriptions + + +Then simply omit the "bus=usb-bus.0" here - the devices then should be put onto the XHCI bus automatically. + +Removing the `bus=usb-bus.0` param from everything, [as shown here](https://pastebin.com/x0Cp70XD), boots fine; but completely breaks mouse functionality. To mitigate, i tried passing through a Logitech mousepad I own--in similar fashion to the iPhone; but Host complained about permissions & `libusb` requiring "write access to USB device nodes". + +FWIW, I vaguely recall the `usb-tablet` parameter being "a whole thing" with virtual macOS; however, I'll need to check my records to refresh my memory. + + +> On Aug 4, 2017, at 11:29 AM, Thomas Huth <email address hidden> wrote: +> +> Then simply omit the "bus=usb-bus.0" here - the devices then should be +> put onto the XHCI bus automatically. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1708551 +> +> Title: +> macOS Guest Reading USB 3.0 Bus as USB 2.0 +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Description: +> I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes. +> +> Parameters: +> QEMU release version: 2.10.0-rc0 +> Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)] +> Command Line: https://pastebin.com/pBSYbrW1 +> Host: Arch Linux +> Guest: macOS v10.12.6 +> Guest System Info: https://pastebin.com/U1Tihxei +> +> Notes: +> 1. Observed sometime after late-May-early-June of this year. +> +> 2. Due to [a defect in qemu v2.8 which affected GTK +> users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent +> change to macOS' booting process conflicting with qemu +> v2.9](https://lists.nongnu.org/archive/html/qemu- +> devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as +> -rc1 fails to load OVMF right now). +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1708551/+subscriptions + + +Ok, could you maybe try something like this instead: + + qemu-system-x86_64 ... -usb \ + -device qemu-xhci,id=xhci \ + -device usb-tablet,bus=usb-bus.0 \ + -device usb-kbd,bus=usb-bus.0 \ + -device usb-host,bus=xhci.0,vendorid=0x05ac,productid=0x12a8 + +i.e. use "bus=xhci.0" for the usb-host device? + +In doing so, the device is now unseen by the system. + + +xhci doesn't work with macos because macos has a white list of supported xhci controllers and ignores the xhci adapters emulated by qemu. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/146 + + diff --git a/results/classifier/118/all/1708617 b/results/classifier/118/all/1708617 new file mode 100644 index 00000000..c263043d --- /dev/null +++ b/results/classifier/118/all/1708617 @@ -0,0 +1,64 @@ +user-level: 0.944 +vnc: 0.925 +mistranslation: 0.917 +assembly: 0.912 +architecture: 0.910 +risc-v: 0.909 +debug: 0.908 +permissions: 0.906 +x86: 0.904 +virtual: 0.902 +network: 0.901 +register: 0.900 +graphic: 0.898 +device: 0.896 +arm: 0.896 +semantic: 0.893 +socket: 0.889 +kernel: 0.888 +performance: 0.887 +PID: 0.887 +KVM: 0.883 +ppc: 0.881 +files: 0.881 +hypervisor: 0.880 +boot: 0.874 +peripherals: 0.871 +TCG: 0.866 +i386: 0.864 +VMM: 0.850 + +qemu2.9 meet a question using reconnect about ovs+dpdk + +env: +qemu-2.9 +dpdk-16.11 +ovs-2.6.1 +host os:Linux compute 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux +guest os is same with host + +1. ovs service is normal +2. start 2 qemu vm, using vhostuser port as server +taskset 0x3f qemu-system-x86_64 -cpu host -smp 2,cores=2 -drive file=$QCOW2_IMAGE -m 4096M --enable-kvm -name $VM_NAME -nographic -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0,server -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6 -nographic -vnc :0 +qemu-system-x86_64: -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0,server: QEMU waiting for connection on: disconnected:unix:/usr/local/var/run/openvswitch/dpdkvhostuser0,server + +taskset 0x3f qemu-system-x86_64 -cpu host -smp 2,cores=2 -drive file=$QCOW2_IMAGE -m 4096M --enable-kvm -name $VM_NAME -nographic -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0,server -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6 -nographic -vnc :0 +qemu-system-x86_64: -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0,server: QEMU waiting for connection on: disconnected:unix:/usr/local/var/run/openvswitch/dpdkvhostuser1,server + +3. add br and vhostuser port as client +ovs-vsctl add-br br1 -- set bridge br1 datapath_type=netdev +ovs-vsctl add-port br1 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuserclient options:vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostuser0" +ovs-vsctl add-port br1 dpdkvhostuser1 -- set Interface dpdkvhostuser1 type=dpdkvhostuserclient options:vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostuser1" + +4. ping between 2 vm is ok +5. restart ovs process + systemctl restart openvswitch + +6. there is a question ping between 2 vm error + +7. change qemu from 2.9 to 2.7, everything become ok + +ooking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? And what is a "question ping between 2 vm error" ? + +[Expired for QEMU because there has been no activity for 60 days.] + |