diff options
Diffstat (limited to '')
62 files changed, 6284 insertions, 0 deletions
diff --git a/results/classifier/108/other/183 b/results/classifier/108/other/183 new file mode 100644 index 00000000..5d73d7cd --- /dev/null +++ b/results/classifier/108/other/183 @@ -0,0 +1,16 @@ +device: 0.759 +permissions: 0.591 +performance: 0.534 +network: 0.531 +semantic: 0.425 +other: 0.414 +graphic: 0.407 +PID: 0.262 +debug: 0.229 +files: 0.163 +boot: 0.118 +vnc: 0.069 +socket: 0.056 +KVM: 0.010 + +Cannot use usb-host on Mac OS diff --git a/results/classifier/108/other/1830031 b/results/classifier/108/other/1830031 new file mode 100644 index 00000000..6385f206 --- /dev/null +++ b/results/classifier/108/other/1830031 @@ -0,0 +1,113 @@ +permissions: 0.917 +device: 0.914 +semantic: 0.904 +other: 0.890 +graphic: 0.879 +PID: 0.876 +performance: 0.869 +files: 0.855 +debug: 0.853 +socket: 0.833 +network: 0.802 +vnc: 0.793 +boot: 0.791 +KVM: 0.785 + +fatal error: float32nan on QEmu 3.1 + +Docker throws float32nan errors when running alpine container on a CentOS 7.6 ppc64le Distro VM, when using Fedora 30 Host qemu 3.1. I Compiled qemu 2.11.2 on the Fedora 30 and using this qemu-system-ppc64 we don't see the error. Even using qemu 3.1 and machine 2.11 we still get the same issue. + +Nothing changed on the OS level on the two runs. just the qemu-system-ppc64 used to run the virtual machine. + + Docker on CentOS 7: docker.ppc64le 2:1.13.1-96 + +Running with qemu 2.11.2 behavior and machine 2.11: +[root@machine ~]# /usr/local/bin/qemu-system-ppc64 -version +QEMU emulator version 2.11.2(qemu-2.11.2-5.fc30) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +[root@powericp ~]# docker run -i -t alpine /bin/sh +/ # exit +[root@powericp ~]# uname -a +Linux powericp 3.10.0-957.12.2.el7.ppc64le #1 SMP Tue May 14 22:24:22 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux +[root@powericp ~]# docker version +Client: + Version: 1.13.1 + API version: 1.26 + Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.ppc64le + Go version: go1.10.3 + Git commit: b2f74b2/1.13.1 + Built: Wed May 1 15:05:41 2019 + OS/Arch: linux/ppc64le +… +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 +################################################################################################# +#Running with qemu3.1 +################################################################################################# +[root@machine ~]# qemu-system-ppc64 -version +QEMU emulator version 3.1.0 (qemu-3.1.0-8.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +[root@powericp ~]# docker run -i -t alpine /bin/sh +/usr/bin/docker-current: Error response from daemon: oci runtime error: error running hook: exit status 4, stdout: , stderr: fatal error: float32nan +runtime: panic before malloc heap initialized + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +panic during panic + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +stack trace unavailable. +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 + + +strace attached. + + + +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/108/other/1830415 b/results/classifier/108/other/1830415 new file mode 100644 index 00000000..e7754d59 --- /dev/null +++ b/results/classifier/108/other/1830415 @@ -0,0 +1,34 @@ +files: 0.646 +graphic: 0.569 +semantic: 0.512 +device: 0.505 +performance: 0.495 +other: 0.344 +network: 0.288 +boot: 0.247 +vnc: 0.215 +PID: 0.203 +socket: 0.195 +debug: 0.169 +permissions: 0.133 +KVM: 0.071 + +linux-user elf loader issue + +all versions up to 4.0 (I didn't test others) +file affected linux-user/elfload.c +function load_elf_image + +if (phdr[i].p_type == PT_LOAD) { + +- abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; ++ abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; + if (a < loaddr) { + loaddr = a; + +To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above. + +Have you got a test case? The check-tcg tests all pass and they are statically linked elfs. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1830821 b/results/classifier/108/other/1830821 new file mode 100644 index 00000000..a74e8662 --- /dev/null +++ b/results/classifier/108/other/1830821 @@ -0,0 +1,49 @@ +KVM: 0.819 +device: 0.514 +graphic: 0.514 +network: 0.458 +performance: 0.446 +semantic: 0.411 +socket: 0.398 +permissions: 0.366 +vnc: 0.361 +boot: 0.345 +PID: 0.285 +files: 0.263 +debug: 0.164 +other: 0.160 + +Expose ARCH_CAP_MDS_NO in guest + +Description: + +MDS_NO is bit 5 of ARCH_CAPABILITIES. Expose this bit to guest. + +Target Qemu: 4.1 + +The specific upstream commit is 20140a82c67467f53814ca197403d5e1b561a5e5 and is incorporated into qemu 1:3.1+dfsg-2ubuntu3.1 in disco-security (19.04) and 1:3.1+dfsg-2ubuntu4 in eoan-proposed. For backporting to cosmic and older, I believe it requires the infrastructure to support IA32_ARCH_CAPABILITIES in place. + +This is done upstream, no need for the upstream bug task. +For Ubuntu I'll update the tasks to match the statement of sbeattie. +There are discussions to reconsider some of the backports, but unfortunately the IA32_ARCH_CAPABILITIES infrastructure is a rather big set of changes. + +This effort, if done, would be done together with: + +https://bugs.launchpad.net/intel/+bug/1828495 + +Please read comments: + +https://bugs.launchpad.net/intel/+bug/1828495/comments/8 + +and + +https://bugs.launchpad.net/intel/+bug/1828495/comments/10 + +I'm marking this bug as a duplicate of LP: #1828495 since both are asking for mitigations pass-through to i386 kvm guests and I'm preparing a fix for both simultaneously. + +Commit: + +https://bugs.launchpad.net/intel/+bug/1828495/comments/42 + +Addresses exactly this bug fix. + diff --git a/results/classifier/108/other/1830864 b/results/classifier/108/other/1830864 new file mode 100644 index 00000000..4feb44fe --- /dev/null +++ b/results/classifier/108/other/1830864 @@ -0,0 +1,103 @@ +performance: 0.754 +other: 0.741 +boot: 0.738 +device: 0.735 +permissions: 0.728 +semantic: 0.721 +graphic: 0.663 +vnc: 0.660 +KVM: 0.644 +debug: 0.642 +socket: 0.623 +PID: 0.612 +network: 0.595 +files: 0.555 + +Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(&cpu_->isar); })' failed + +The following assertion: + + assert(no_aa32 || cpu_isar_feature(arm_div, cpu)); + +introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some +asserts on aarch32 support", 2018-11-02), fails for me. I intended to +launch a 32-bit ARM guest (with KVM acceleration) on my AArch64 host +(APM Mustang A3). + +Libvirt generated the following QEMU command line: + +> LC_ALL=C \ +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +> QEMU_AUDIO_DRV=none \ +> /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \ +> -name guest=f28.32bit,debug-threads=on \ +> -S \ +> -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-f28.32bit/master-key.aes \ +> -machine virt-4.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \ +> -cpu host,aarch64=off \ +> -drive file=/root/QEMU_EFI.fd.padded,if=pflash,format=raw,unit=0,readonly=on \ +> -drive file=/var/lib/libvirt/qemu/nvram/f28.32bit_VARS.fd,if=pflash,format=raw,unit=1 \ +> -m 8192 \ +> -realtime mlock=off \ +> -smp 8,sockets=8,cores=1,threads=1 \ +> -uuid d525042e-1b37-4058-86ca-c6a2086e8485 \ +> -no-user-config \ +> -nodefaults \ +> -chardev socket,id=charmonitor,fd=27,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 qemu-xhci,id=usb,bus=pci.1,addr=0x0 \ +> -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x0 \ +> -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +> -drive file=/var/lib/libvirt/images/f28.32bit.root.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap \ +> -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,write-cache=on \ +> -drive file=/var/lib/libvirt/images/f28.32bit.home.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,werror=enospc,cache=writeback,discard=unmap \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,write-cache=on \ +> -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 \ +> -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:d1:c8,bus=pci.4,addr=0x0,romfile= \ +> -chardev pty,id=charserial0 \ +> -serial chardev:charserial0 \ +> -chardev socket,id=charchannel0,fd=31,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,bus=usb.0,port=1 \ +> -device usb-kbd,id=input1,bus=usb.0,port=2 \ +> -vnc 127.0.0.1:0 \ +> -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.5,addr=0x0 \ +> -object rng-random,id=objrng0,filename=/dev/urandom \ +> -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.6,addr=0x0 \ +> -msg timestamp=on + +and then I got: + +> qemu-system-aarch64: /root/src/upstream/qemu/target/arm/cpu.c:986: +> arm_cpu_realizefn: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); +> isar_feature_arm_div(&cpu_->isar); })' failed. + +QEMU was built at commit 8dc7fd56dd4f ("Merge remote-tracking branch +'remotes/philmd-gitlab/tags/fw_cfg-20190523-pull-request' into staging", +2019-05-23). + +(Originally reported on the mailing list in the following thread: +<http://<email address hidden>>.) + +This happens because: + * the host kernel is older than 4.15 and does not expose ID registers to userspace via the KVM_GET_ONE_REG ioctl + * our fallback set of ID register values in target/arm/kvm64.c kvm_arm_get_host_cpu_features() is extremely minimalist + * the consistency checks on ID register values in arm_cpu_realizefn() are made unconditionally, rather than only if we're using TCG + +https://patchwork.ozlabs.org/patch/1133724/ is a fix for this which takes the approach of only asserting if we're using TCG, since that's really the case we're guarding for problems with and the only one that's a bug in QEMU (as opposed to an issue with the host kernel or host CPU). + + +Fix for this is in git and will be in 4.1.0. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8f4821d77e465bc + diff --git a/results/classifier/108/other/1830872 b/results/classifier/108/other/1830872 new file mode 100644 index 00000000..1cf4135b --- /dev/null +++ b/results/classifier/108/other/1830872 @@ -0,0 +1,614 @@ +other: 0.741 +permissions: 0.738 +vnc: 0.722 +KVM: 0.677 +debug: 0.676 +performance: 0.674 +semantic: 0.670 +graphic: 0.668 +PID: 0.665 +device: 0.664 +boot: 0.623 +network: 0.606 +socket: 0.594 +files: 0.521 + +AARCH64 to ARMv7 mistranslation in TCG + +The following guest code: + + https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S + +implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI +Development Kit II) library function. (CopyMem() basically has memmove() +semantics, to provide a standard C analog here.) The relevant functions +are InternalMemCopyMem() and __memcpy(). + +When TCG translates this aarch64 code to x86_64, everything works fine. + +When TCG translates this aarch64 code to ARMv7, the destination area of +the translated CopyMem() function becomes corrupted -- it differs from +the intended source contents. Namely, in every 4096 byte block, the +8-byte word at offset 4032 (0xFC0) is zeroed out in the destination, +instead of receiving the intended source value. + +I'm attaching two hexdumps of the same destination area: + +- "good.txt" is a hexdump of the destination area when CopyMem() was + translated to x86_64, + +- "bad.txt" is a hexdump of the destination area when CopyMem() was + translated to ARMv7. + +In order to assist with the analysis of this issue, I disassembled the +aarch64 binary with "objdump". Please find the listing in +"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at +hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180. + +And, I ran the guest on the ARMv7 host with "-d +in_asm,op,op_opt,op_ind,out_asm". Please find the log in +"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached. + +The TBs that correspond to (parts of) the InternalMemCopyMem() and +__memcpy() functions are scattered over the TCG log file, but the offset +between the "nice" disassembly from "DxeCore.objdump", and the in-RAM +TBs in the TCG log, can be determined from the fact that there is a +single prfm instruction in the entire binary. The instruction's offset +is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy() +function --, and its RAM address is 0x472d2180 in the TCG log. Thus the +difference (= the load address of DxeCore.efi) is 0x472a7000. + +QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch +'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21). + +The reproducer command line is (on an ARMv7 host): + + qemu-system-aarch64 \ + -display none \ + -machine virt,accel=tcg \ + -nodefaults \ + -nographic \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \ + -cpu cortex-a57 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline \ + -serial chardev:char0 + +The apparent symptom is an assertion failure *in the guest*, such as + +> ASSERT [DxeCore] +> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090): +> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength + +but that is only a (distant) consequence of the CopyMem() +mistranslation, and resultant destination area corruption. + +Originally reported in the following two mailing list messages: +- http://<email address hidden> +- http://<email address hidden> + + + +Possibly related: +[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html + +(qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when QEMU is built for i686) + +Note to self: try to reprodouce the present issue with QEMU built at eed5664238ea^ -- this LP has originally been filed about the tree at a4f667b67149, and that commit contains eed5664238ea. So checking at eed5664238ea^ might reveal a difference. + + +Laszlo Ersek (Red Hat) <email address hidden> writes: + +> Possibly related: +> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html +> +> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when +> QEMU is built for i686) +> +> Note to self: try to reprodouce the present issue with QEMU built at +> eed5664238ea^ -- this LP has originally been filed about the tree at +> a4f667b67149, and that commit contains eed5664238ea. So checking at +> eed5664238ea^ might reveal a difference. + +Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough +cases. + +-- +Alex Bennée + + + +Alex Bennée <email address hidden> writes: + +> Laszlo Ersek (Red Hat) <email address hidden> writes: +> +>> Possibly related: +>> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html +>> +>> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when +>> QEMU is built for i686) +>> +>> Note to self: try to reprodouce the present issue with QEMU built at +>> eed5664238ea^ -- this LP has originally been filed about the tree at +>> a4f667b67149, and that commit contains eed5664238ea. So checking at +>> eed5664238ea^ might reveal a difference. +> +> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough +> cases. + +Actually I do see something with i386 host running the aarch64 memory +test (although so far not with a armv7 host): + + ./qemu-system-aarch64 -monitor none -display none -M virt -cpu max -display none -semihosting -kernel tests/memory + +Gives: + + Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249, 248, 255Test complete: FAILED + +-- +Alex Bennée + + +When running on 32 bit TCG backends a wide unaligned load ends up +truncating data before returning to the guest. We specifically have +the return type as uint64_t to avoid any premature truncation so we +should use the same for the interim types. + +Hopefully fixes #1830872 + +Signed-off-by: Alex Bennée <email address hidden> +--- + accel/tcg/cputlb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +index cdcc3771020..b796ab1cbea 100644 +--- a/accel/tcg/cputlb.c ++++ b/accel/tcg/cputlb.c +@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, + && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 + >= TARGET_PAGE_SIZE)) { + target_ulong addr1, addr2; +- tcg_target_ulong r1, r2; ++ uint64_t r1, r2; + unsigned shift; + do_unaligned_access: + addr1 = addr & ~(size - 1); +-- +2.20.1 + + + +I confirm that QEMU works fine (for the use case originally reported in this LP ticket) when built at commit a6ae23831b, i.e. at the parent of eed5664238ea. + +В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а): +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); + +Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug is separate from #1830872 ? + +I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler .. +probably x86-64 testing on i686 requires either docker (I don't have this +) or 'real' cross-compiler (build with glibc support). + + +Sorry the patch in comment #5 wasn't visible when I wrote what would end up as comment #6. I'll test the patch later. Thanks! + +I managed to tweak the memory test enough to detect the failure on aarch64-on-armv7 and I the attached patch fixes it. Could you please double check with your test case? + +В сообщении от Monday 03 June 2019 18:51:40 Alex Bennée написал(а): +> I managed to tweak the memory test enough to detect the failure on +> aarch64-on-armv7 and I the attached patch fixes it. Could you please +> double check with your test case? +> + + +Hm, I manually applied path from LP(git diff disliked copypasted patch), +so for now git diff in qemu tree shows: + +diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +index cdcc377102..b796ab1cbe 100644 +--- a/accel/tcg/cputlb.c ++++ b/accel/tcg/cputlb.c +@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, + && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 + >= TARGET_PAGE_SIZE)) { + target_ulong addr1, addr2; +- tcg_target_ulong r1, r2; ++ uint64_t r1, r2; + unsigned shift; + do_unaligned_access: + addr1 = addr & ~(size - 1); +lines 1-13/13 (END) + +--------- + +but x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg +still hangs at 'booting the kernel" (it decompress OK) + +I make distclean'ed source tree and reconfigured it: + ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg --cross-cc-x86_64="/opt/kgcc64/bin/x86_64-unknown-linux-gnu-gcc-6.5.0" + +next, make -j 5 and test. + +Hm. + +I tried debug switches, it seems to hang a bit differently for two runs: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg -nographic -d in_asm,op,op_opt,op_ind,out_asm + +===================== + +IN: +0xffffffff810e8a63: 48 83 c3 64 addq $0x64, %rbx +0xffffffff810e8a67: eb c2 jmp 0xffffffff810e8a2b + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a63 0000000000000000 + movi_i32 tmp2,$0x64 + movi_i32 tmp3,$0x0 + mov_i32 tmp0,rbx_0 + mov_i32 tmp1,rbx_1 + add2_i32 tmp0,tmp1,tmp0,tmp1,tmp2,tmp3 + mov_i32 rbx_0,tmp0 + mov_i32 rbx_1,tmp1 + mov_i32 cc_src_0,tmp2 + mov_i32 cc_src_1,tmp3 + mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a67 0000000000000009 + movi_i32 cc_op,$0x9 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a2b + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c080 + set_label $L0 + exit_tb $0xf2f1c083 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a63 0000000000000000 + movi_i32 tmp2,$0x64 pref=0xff + movi_i32 tmp3,$0x0 pref=0xff + add2_i32 tmp0,tmp1,rbx_0,rbx_1,tmp2,tmp3 dead: 2 3 pref=0xff,0xff + mov_i32 rbx_0,tmp0 sync: 0 dead: 1 pref=0xff + mov_i32 rbx_1,tmp1 sync: 0 dead: 1 pref=0xff + mov_i32 cc_src_0,tmp2 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_src_1,tmp3 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_0,rbx_0 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_1,rbx_1 sync: 0 dead: 0 1 pref=0xff + discard cc_src2_0 pref=0xff + discard cc_src2_1 pref=0xff + discard cc_op pref=0xff mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a55 0000000000000021 + movi_i32 cc_op,$0x21 + movi_i32 tmp20,$0x0 + movi_i32 tmp21,$0x0 + brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a57 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c180 + set_label $L1 + goto_tb $0x1 + movi_i32 tmp6,$0x810e8a63 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c181 + set_label $L0 + exit_tb $0xf2f1c183 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a4c 0000000000000000 + + ---- ffffffff810e8a52 0000000000000000 + movi_i32 tmp1,$0x0 pref=0xff + movi_i32 tmp0,$0x64 pref=0xff + mov_i32 r14_0,tmp0 sync: 0 dead: 1 pref=0xf8 + mov_i32 r14_1,tmp1 sync: 0 dead: 1 pref=0xf8 + call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op sync: 0 1 dead: 0 1 2 3 4 5 6 7 8 pref=none,none + mov_i32 cc_dst_0,r14_0 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_1,r14_1 sync: 0 dead: 0 1 pref=0xffУбито + +(killed by me) + +================== + +IN: +0xffffffff810e8a61: eb ef jmp 0xffffffff810e8a52 + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a61 0000000000000000 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a52 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f22900 + set_label $L0 + exit_tb $0xf2f22903 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a61 0000000000000000 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a52 pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f22900 + set_label $L0 + exit_tb $0xf2f22903 + +OUT: [size=56] +0xf2f22980: 8b 5d f0 movl -0x10(%ebp), %ebx +0xf2f22983: 85 db testl %ebx, %ebx +0xf2f22985: 0f 8c 23 00 00 00 jl 0xf2f229ae +0xf2f2298b: e9 00 00 00 00 jmp 0xf2f22990 +0xf2f22990: c7 85 80 00 00 00 52 8a movl $0x810e8a52, 0x80(%ebp) +0xf2f22998: 0e 81 +0xf2f2299a: c7 85 84 00 00 00 ff ff movl $0xffffffff, 0x84(%ebp) +0xf2f229a2: ff ff +0xf2f229a4: b8 00 29 f2 f2 movl $0xf2f22900, %eax +0xf2f229a9: e9 69 46 c9 ff jmp 0xf2bb7017 +0xf2f229ae: b8 03 29 f2 f2 movl $0xf2f22903, %eax +0xf2f229b3: e9 5f 46 c9 ff jmp 0xf2bb7017 + +---------------- +IN: +0xffffffff810e8a52: 49 ff ce decq %r14 +0xffffffff810e8a55: 74 0c je 0xffffffff810e8a63 + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a52 0000000000000000 + mov_i32 tmp0,r14_0 + mov_i32 tmp1,r14_1 + mov_i32 tmp0,r14_0 + mov_i32 tmp1,r14_1 + movi_i32 tmp20,$0xffffffff + movi_i32 tmp21,$0xffffffff + add2_i32 tmp0,tmp1,tmp0,tmp1,tmp20,tmp21 + mov_i32 r14_0,tmp0 + mov_i32 r14_1,tmp1 + call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op + mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a55 0000000000000021 mov_i32 cc_dst_0,r14_0 sync: 0 dead: 1 pref=0xff + mov_i32 cc_dst_1,r14_1 sync: 0 dead: 1 pref=0xff + discard cc_src2_0 pref=0xff + discard cc_src2_1 pref=0xff + discard cc_op pref=0xff + + ---- ffffffff810e8a55 0000000000000021 + movi_i32 cc_op,$0x21 sync: 0 dead: 0 pref=0xff + movi_i32 tmp20,$0x0 pref=0xff + movi_i32 tmp21,$0x0 pref=0xff + brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1 dead: 0 1 2 3 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a57 pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f229c0 + set_label $L1 + goto_tb $0x1 + movi_i32 tmp6,$0x810e8a63 pref=0xff movi_i32 cc_op,$0x9 sync: 0 dead: 0 pref=0xff + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a2b pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f22b40 + set_label $L0 + exit_tb $0xf2f22b43 + +OUT: [size=116] +0xf2f22bc0: 8b 5d f0 movl -0x10(%ebp), %ebx +0xf2f22bc3: 85 db testl %ebx, %ebx +0xf2f22bc5: 0f 8c 5f 00 00 00 jl 0xf2f22c2a +0xf2f22bcb: 8b 5d 18 movl 0x18(%ebp), %ebx +0xf2f22bce: 8b 75 1c movl 0x1c(%ebp), %esi +0xf2f22bd1: 83 c3 64 addl $0x64, %ebx +0xf2f22bd4: 83 d6 00 adcl $0, %esi +0xf2f22bd7: 89 5d 18 movl %ebx, 0x18(%ebp) +Убито + +============================= + +try kernel I use (it works with qemu compiiled under 64-bit Slackware, and also with kvm on 32-bit x86) + +sha256sum /boot/bzImage-4.12.0-x64 +b4183376de17e8ea7a25094b7a526e99bcb8339b8703090684c93e0e0a50d284 /boot/bzImage-4.12.0-x64 + + +(+Igor) + +On 06/03/19 17:01, Alex Bennée wrote: +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); +> + +Applied on top of commit ad88e4252f09c2956b99c90de39e95bab2e8e7af: + +Tested-by: Laszlo Ersek <email address hidden> + +Thanks! +Laszlo + + + +Andrew Randrianasulu <email address hidden> writes: + +> В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а): +>> When running on 32 bit TCG backends a wide unaligned load ends up +>> truncating data before returning to the guest. We specifically have +>> the return type as uint64_t to avoid any premature truncation so we +>> should use the same for the interim types. +>> +>> Hopefully fixes #1830872 +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> accel/tcg/cputlb.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +>> index cdcc3771020..b796ab1cbea 100644 +>> --- a/accel/tcg/cputlb.c +>> +++ b/accel/tcg/cputlb.c +>> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +>> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +>> >= TARGET_PAGE_SIZE)) { +>> target_ulong addr1, addr2; +>> - tcg_target_ulong r1, r2; +>> + uint64_t r1, r2; +>> unsigned shift; +>> do_unaligned_access: +>> addr1 = addr & ~(size - 1); +> +> Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my +> bug is separate from #1830872 ? + +I think you've hit two - one of which we have just fixed. With my +expanded memory test on i386 I'm seeing a hang but it's ok @ +pull-demacro-softmmu-100519-1. Unfortunately bisecting through the slirp +move and other i386 Werror stuff is proving painful. + +> +> I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler .. +> probably x86-64 testing on i686 requires either docker (I don't have this +> ) or 'real' cross-compiler (build with glibc support). + + +-- +Alex Bennée + + +On Mon, 3 Jun 2019 16:01:20 +0100 +Alex Bennée <email address hidden> wrote: + +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> + +Fixes arm/virt bios-tables-test for me, so + +Tested-by: Igor Mammedov <email address hidden> + +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c79b288513587e960b + diff --git a/results/classifier/108/other/1831 b/results/classifier/108/other/1831 new file mode 100644 index 00000000..134aba16 --- /dev/null +++ b/results/classifier/108/other/1831 @@ -0,0 +1,16 @@ +device: 0.751 +performance: 0.641 +socket: 0.617 +debug: 0.491 +graphic: 0.472 +permissions: 0.398 +vnc: 0.317 +semantic: 0.252 +other: 0.200 +PID: 0.177 +boot: 0.153 +network: 0.085 +KVM: 0.082 +files: 0.012 + +qemu-system-m68k: ../hw/scsi/scsi-disk.c:557: scsi_write_data: Assertion `r->req.aiocb == NULL' failed. diff --git a/results/classifier/108/other/1831225 b/results/classifier/108/other/1831225 new file mode 100644 index 00000000..47217066 --- /dev/null +++ b/results/classifier/108/other/1831225 @@ -0,0 +1,508 @@ +permissions: 0.821 +other: 0.801 +device: 0.781 +graphic: 0.770 +vnc: 0.769 +debug: 0.767 +performance: 0.765 +files: 0.742 +socket: 0.723 +semantic: 0.720 +boot: 0.719 +KVM: 0.712 +PID: 0.704 +network: 0.607 + +guest migration 100% cpu freeze bug + +# Investigate migration cpu hog(100%) bug + +I have some issues when migrating from kernel 4.14.63 running qemu 2.11.2 to kernel 4.19.43 running qemu 2.11.2. +The hypervisors are running on debian jessie with libvirt v5.3.0. +Linux, libvirt and qemu are all custom compiled. + +I migrated around 10.000 vms and every once in a while a vm is stuck at 100% cpu after what we can see right now is that the target hypervisor runs on linux 4.19.53. This happened with 4 vms so far. It is not that easy to debug, we found this out pretty quickly because we are running monitoring on frozen vms after migrations. + +Last year we were having the same "kind of" bug https://bugs.launchpad.net/qemu/+bug/1775555 when trying to upgrade qemu 2.6 to 2.11. +This bug was fixed after applying the following patch: http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00820.html + +This patch is still applied as you can see because of the available pre_load var on the kvmclock_vmsd struct: +(gdb) ptype kvmclock_vmsd +type = const struct VMStateDescription { + const char *name; + int unmigratable; + int version_id; + int minimum_version_id; + int minimum_version_id_old; + MigrationPriority priority; + LoadStateHandler *load_state_old; + int (*pre_load)(void *); + int (*post_load)(void *, int); + int (*pre_save)(void *); + _Bool (*needed)(void *); + VMStateField *fields; + const VMStateDescription **subsections; +} + +I attached gdb to a vcpu thread of one stuck vm, and a bt showed the following info: +Thread 4 (Thread 0x7f3a431a4700 (LWP 37799)): +#0 0x00007f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84 +#1 0x000055d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fca78d0, type=type@entry=44672) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050 +#2 0x000055d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fca78d0) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887 +#3 0x000055d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fca78d0) at /home/dbosschieter/src/qemu-pkg/src/cpus.c:1136 +#4 0x00007f3a579ba4a4 in start_thread (arg=0x7f3a431a4700) at pthread_create.c:456 +#5 0x00007f3a576fcd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +Thread 3 (Thread 0x7f3a439a5700 (LWP 37798)): +#0 0x00007f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84 +#1 0x000055d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fc5cbb0, type=type@entry=44672) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050 +#2 0x000055d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fc5cbb0) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887 +#3 0x000055d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fc5cbb0) at /home/dbosschieter/src/qemu-pkg/src/cpus.c:1136 +#4 0x00007f3a579ba4a4 in start_thread (arg=0x7f3a439a5700) at pthread_create.c:456 +#5 0x00007f3a576fcd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +The ioctl call is a ioctl(18, KVM_RUN and it looks like it is looping inside the vm itself. + +I saved the state of the VM (with `virsh save`) after I found it was hanging on its vcpu threads. Then I restored this vm on a test environment running the same kernel, QEMU and libvirt version). After the restore the VM still was haning at 100% cpu usage on all the vcpus. +I tried to use the perf kvm guest option to trace the guest vm with a copy of the kernel, modules and kallsyms files from inside the guest vm and I got to the following perf stat: + + Event Total %Total CurAvg/s + kvm_entry 5198993 23.1 277007 + kvm_exit 5198976 23.1 277006 + kvm_apic 1732103 7.7 92289 + kvm_msr 1732101 7.7 92289 + kvm_inj_virq 1731904 7.7 92278 + kvm_eoi 1731900 7.7 92278 + kvm_apic_accept_irq 1731900 7.7 92278 + kvm_hv_timer_state 1731780 7.7 92274 + kvm_pv_eoi 1731701 7.7 92267 + kvm_ple_window 36 0.0 2 + Total 22521394 1199967 + +We tried to run the crash tool against a dump of guest vm memory and that gave us the following backtrace: +crash> bt +PID: 0 TASK: ffffffff81610040 CPU: 0 COMMAND: "swapper/0" + [exception RIP: native_read_tsc+2] + RIP: ffffffff810146a9 RSP: ffff88003fc03df0 RFLAGS: 00000046 + RAX: 000000008762c0fa RBX: ffff88003fc13680 RCX: 0000000000000001 + RDX: 0000000000fe4871 RSI: 0000000000000000 RDI: ffff88003fc13603 + RBP: 000000000003052c R8: 0000000000000200 R9: ffffffff8169b180 + R10: 0000000000000020 R11: 0000000000000005 R12: 006a33290b40455c + R13: 00000000df1fd292 R14: 000000002ca284ff R15: 00fe485f3febe21a + CS: 0010 SS: 0018 + #0 [ffff88003fc03df0] pvclock_clocksource_read at ffffffff8102cbb3 + #1 [ffff88003fc03e40] kvm_clock_read at ffffffff8102c2c9 + #2 [ffff88003fc03e50] timekeeping_get_ns at ffffffff810691b0 + #3 [ffff88003fc03e60] ktime_get at ffffffff810695c8 + #4 [ffff88003fc03e90] sched_rt_period_timer at ffffffff8103e4f5 + #5 [ffff88003fc03ee0] __run_hrtimer at ffffffff810652d3 + #6 [ffff88003fc03f20] hrtimer_interrupt at ffffffff81065abd + #7 [ffff88003fc03f90] smp_apic_timer_interrupt at ffffffff81024ba8 + #8 [ffff88003fc03fb0] apic_timer_interrupt at ffffffff813587e2 +--- <IRQ stack> --- + #9 [ffffffff81601e98] apic_timer_interrupt at ffffffff813587e2 + [exception RIP: native_safe_halt+2] + RIP: ffffffff8102c360 RSP: ffffffff81601f40 RFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffffffff81601fd8 RCX: 00000000ffffffff + RDX: 00000000ffffffff RSI: 0000000000000000 RDI: 0000000000000001 + RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000000 + R10: 0000000000000020 R11: 0000000000000005 R12: ffffffff816f5d80 + R13: ffffffffffffffff R14: 000000000008c800 R15: 0000000000000000 + ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018 +#10 [ffffffff81601f40] default_idle at ffffffff81014c35 +#11 [ffffffff81601f50] cpu_idle at ffffffff8100d258 + +So it seems like the vm is reading its clock constantly trying to catch up some time after the migration. + +Last time it was a bug that was only triggered on newer Gold cpu hardware, but this time we also see this coming back on older Intel E5 cpus we tried to reproduce with a migrate loop of 3 days times between kernel 4.14.63 and 4.19.43 but this gave us no results. + +The vms were running ubuntu 14.04, centos 7, debian 7, debian 8 these vms are running linux kernel 3.*. + +The thing is that we are out of ideas for reproducing this, it seems like it the same kind of bug we are hitting, just like last time the vm is basically only trying to read the clock. Perhaps we can try to read the clock data and also try to read what the guest is actually waiting for, which value of the counter does it want to reach. + +I am not sure how to pinpoint the cause of this issue, I would like some help and possible some extra tips on debugging. +We are able to read the guests kernel which makes it a bit easier to debug, reproducing and finding the source of the problem is still something we are trying to figure out. + +A virsh dumpxml of one of the guests: + +<domain type='kvm' id='15'> + <name>vps12</name> + <uuid>xxxxxxxx-953c-d629-1276-00000616xxxx</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <numatune> + <memory mode='interleave' nodeset='0-1'/> + </numatune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> + <boot dev='hd'/> + <boot dev='network'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Westmere</model> + <topology sockets='1' cores='2' threads='1'/> + <feature policy='require' name='vme'/> + <feature policy='require' name='pclmuldq'/> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + </cpu> + <clock offset='utc'> + <timer name='hpet' present='yes'/> + </clock> + <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='/var/local/mnt/vps/vps12/vps12.raw'/> + <backingStore/> + <target dev='hda' bus='virtio'/> + <iotune> + <read_bytes_sec>734003200</read_bytes_sec> + <write_bytes_sec>576716800</write_bytes_sec> + <read_iops_sec>3500</read_iops_sec> + <write_iops_sec>2500</write_iops_sec> + </iotune> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <interface type='bridge'> + <mac address='xx:xx:xx:xx:xx:xx'/> + <source bridge='brxx'/> + <target dev='vxxxx'/> + <model type='virtio'/> + <filterref filter='firewall-vps12'/> + <link state='up'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'> + <alias name='input0'/> + </input> + <input type='tablet' bus='usb'> + <alias name='input1'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <sound model='es1370'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+997:+998</label> + <imagelabel>+997:+998</imagelabel> + </seclabel> +</domain> + + +Hi Dion, + Since you've got a crash dump, can you check the dmesg in the guest to see if there's any messages? + + +Hi Alan, + + +Dmesg shows nothing special: +[29891577.708544] IPv6 addrconf: prefix with wrong length 48 +[29891580.650637] IPv6 addrconf: prefix with wrong length 48 +[29891582.013656] IPv6 addrconf: prefix with wrong length 48 +[29891583.753246] IPv6 addrconf: prefix with wrong length 48 +[29891585.397941] IPv6 addrconf: prefix with wrong length 48 +[29891587.031141] IPv6 addrconf: prefix with wrong length 48 +[29891588.991541] IPv6 addrconf: prefix with wrong length 48 +[29891590.162395] IPv6 addrconf: prefix with wrong length 48 +[29891592.681133] IPv6 addrconf: prefix with wrong length 48 +[29891593.418342] IPv6 addrconf: prefix with wrong length 48 +[29891596.491791] IPv6 addrconf: prefix with wrong length 48 +[29891597.262282] IPv6 addrconf: prefix with wrong length 48 +[29891600.116510] IPv6 addrconf: prefix with wrong length 48 +[29891600.987599] IPv6 addrconf: prefix with wrong length 48 +[29891603.954923] IPv6 addrconf: prefix with wrong length 48 +[29891604.554989] IPv6 addrconf: prefix with wrong length 48 +[29891607.641694] IPv6 addrconf: prefix with wrong length 48 +[29891607.855495] IPv6 addrconf: prefix with wrong length 48 +[29891611.128803] IPv6 addrconf: prefix with wrong length 48 +[29891611.293230] IPv6 addrconf: prefix with wrong length 48 +[29891615.011260] IPv6 addrconf: prefix with wrong length 48 +[29891615.182883] IPv6 addrconf: prefix with wrong length 48 +[29891618.577801] IPv6 addrconf: prefix with wrong length 48 +[29891619.146512] IPv6 addrconf: prefix with wrong length 48 +[29891622.250595] IPv6 addrconf: prefix with wrong length 48 +[29891623.051844] IPv6 addrconf: prefix with wrong length 48 +[29891625.642684] IPv6 addrconf: prefix with wrong length 48 +[29891626.457455] IPv6 addrconf: prefix with wrong length 48 + +Crash shows me the uptime though which doesn't seem right: + DATE: Tue Nov 29 18:55:46 2603 + UPTIME: 106751 days, 23:55:03 +Not sure if this is related to the amount of kvm clock calls. + +Interesting; I'd seen something similar - in rh https://bugzilla.redhat.com/show_bug.cgi?id=1538078 +and as well as the bogus date we'd had lots of log messages of the form: + + CE: lapic increasing min_delta_ns to <very big number> nsec + + +we were reckoning the clock jumped a bit during the migrate, and then triggered an old guest kernel bug, https://bugzilla.redhat.com/show_bug.cgi?id=1183773 - and we'd only ever triggered it on older distros (rhel6 etc), and think we backported two newer kernel patches: + +commit 80a05b9ffa7dc13f6693902dd8999a2b61a3a0d7 +Author: Thomas Gleixner <email address hidden> +Date: Fri Mar 12 17:34:14 2010 +0100 + + clockevents: Sanitize min_delta_ns adjustment and prevent overflows + +and: +commit d1748302f70be7469809809283fe164156a34231 +Author: Martin Schwidefsky <email address hidden> +Date: Tue Aug 23 15:29:42 2011 +0200 + + clockevents: Make minimum delay adjustments configurable + +but if you're getting that symptom on a RHEL7 / newer than 2011 kernel then I'm worried that there's another case. + +This was a very difficult to reproduce last time I looked at the rh bz's above - the slightest change anywhere and it would go away. + + +Is there a way that we can check that it indeed is the case that the clock jumped a bit, we can try to read some kernel variables. +We just got another hung guest's crash dump working, this vm also shows a weird uptime + DATE: Fri Dec 23 09:06:16 2603 + UPTIME: 106752 days, 00:10:35 + +Till now we have only see this happening on guests with linux kernel 3.*. + +Again dmesg shows nothing. + +The only way this has yet happened was when the target hypervisor kernel was 4.19. +So it seems that something changed over there, the only thing is it not quite a small diff ;) between 4.14 and 4.19. And because it only happens once every couple of thousand migrations with unknown conditions makes it a hard to bisect this. +Source hypervisor kernel could be 4.14 and 4.19. + +If the clock did jump during the migration, is there something that we could do about that on source/target hypervisor, with a libvirt xml change, etc, to prevent it I mean. + +It seems like the patch is applied to the guests source kernel. + +crash> clock_event_device +struct clock_event_device { + void (*event_handler)(struct clock_event_device *); + int (*set_next_event)(unsigned long, struct clock_event_device *); + int (*set_next_ktime)(ktime_t, struct clock_event_device *); + ktime_t next_event; + u64 max_delta_ns; + u64 min_delta_ns; + u32 mult; + u32 shift; + enum clock_event_mode mode; + unsigned int features; + unsigned long retries; + void (*broadcast)(const struct cpumask *); + void (*set_mode)(enum clock_event_mode, struct clock_event_device *); + void (*suspend)(struct clock_event_device *); + void (*resume)(struct clock_event_device *); + unsigned long min_delta_ticks; + unsigned long max_delta_ticks; + const char *name; + int rating; + int irq; + const struct cpumask *cpumask; + struct list_head list; + struct module *owner; +} +SIZE: 0xc0 +crash> clockevents_program_min_delta +clockevents_program_min_delta = $2 = + {int (struct clock_event_device *)} 0xffffffff810daa20 <clockevents_program_min_delta> + + +You say it's only happened since 4.19 - that's possible - but since this bug is so tricky to trigger it's also possible that any slight change in 4.19. + +You could try disabling kvm_clock? + +Dave + +Hi, + +i suffer fro this bug too (or very similar) on 4.15.0-50-generic, without the patch mentionned earlier (i use this patch last year to migrate from previous qemu version). + +Jean-Philippe + +Hi Jean, + +Could you elaborate, is it the qemu patch that you applied and didn't apply that to the current qem u version you are running? + +Could you try to get a crash dump from a frozen vm working, see if you get the same kind of backtrace in there. + +Which specific qemu version are you running, which cpu are you migrating from/to, which kernel version are you running from/to? + +Could you dump the xml in this comment section from a defined guest that was frozen? + +Dion + +Hi David, + +I have digged further into our issue and we have seen issues only when migrating from servers that have a different tsc frequency. + +Example: +Source (kernel 4.14.63) +[ 2.068227] tsc: Refined TSC clocksource calibration: 2593.906 MHz +[ 2.068373] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563bf907c6, max_idle_ns: 440795319401 ns +[ 4.908200] clocksource: Switched to clocksource tsc + +Destination (kernel 4.19.43): +[ 0.000000] tsc: Detected 2600.000 MHz processor +[ 3.647553] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x257a3c3232d, max_idle_ns: 440795236700 ns +[ 4.421582] clocksource: Switched to clocksource tsc-early +[ 5.747791] tsc: Refined TSC clocksource calibration: 2593.904 MHz +[ 5.747952] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563bd843df, max_idle_ns: 440795257314 ns +[ 5.748261] clocksource: Switched to clocksource tsc + +Source (kernel 4.19.43): +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2199.852 MHz processor +[ 4.041367] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb5a71147a, max_idle_ns: 440795225528 ns +[ 4.504477] clocksource: Switched to clocksource tsc-early +[ 6.231559] tsc: Refined TSC clocksource calibration: 2200.002 MHz +[ 6.231718] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1fb634b8814, max_idle_ns: 440795202126 ns +[ 6.801999] clocksource: Switched to clocksource tsc + +Destionation (kernel 4.19.43): +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2394.538 MHz processor +[ 5.486287] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x22840fdedc8, max_idle_ns: 440795293830 ns +[ 6.182944] clocksource: Switched to clocksource tsc-early +[ 7.596489] tsc: Refined TSC clocksource calibration: 2394.454 MHz +[ 7.596641] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2283c0783fd, max_idle_ns: 440795301468 ns +[ 9.316929] clocksource: Switched to clocksource tsc + +Source (kernel 4.14.63): +[ 2.068227] tsc: Refined TSC clocksource calibration: 2593.906 MHz +[ 2.068373] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563bf907c6, max_idle_ns: 440795319401 ns +[ 4.908200] clocksource: Switched to clocksource tsc + +Destination (kernel 4.19.43): +[ 0.000000] tsc: Detected 2600.000 MHz processor +[ 3.661033] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x257a3c3232d, max_idle_ns: 440795236700 ns +[ 4.435033] clocksource: Switched to clocksource tsc-early +[ 5.761251] tsc: Refined TSC clocksource calibration: 2593.905 MHz +[ 5.761412] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563be32fd6, max_idle_ns: 440795226961 ns +[ 5.761731] clocksource: Switched to clocksource tsc + +And what I have seen from reading a bit about time keeping(https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt) and counters and the virtualisation of it, is that it is pretty difficult to get right, so it is already amazing that it goes alright most of the times. + +When diffing I stumbled upon this: https://lore.kernel.org/patchwork/patch/866471/ +And I was thinking about reverting those changes and then try another 10k of migrations see if that makes any difference as we still are not able to reproduce the issue. + +I could also try to prefer migrations from similiar refined TSC clocksource calibration HZes don't, which I would rather not do but I think I understand why having the exact same frequency is prefered, what is your thought on this matter? + +Disabling kvm-clock is not really an option as we don't want to restart and login on all of the running vms. + +Dion + +An update on our further research. We tried bumping the hypervisor kernel form 4.19.43 to 4.19.50 which included the following patch, which we hoped to be related to our issue: + +https://<email address hidden>/#t + +Sadly after a few thousand migrations we encountered two freezes again, and halted further migrations. Again the affected VMs seem to run pre-4.x kernels and all but one freezes occurred with Gold 6126 CPUs. + +While analyzing memory dumps of the VMs with the crash utility we found a peculiar similarity. They all seem to have jumped ~584 years, which led me to this bug report from 2011: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/805341 . Does this provide any insight into what the issue might be on host-level? + +It is very well possible that the issue lies in the guest kernel, but as the service we provide is unmanaged we have no control over it. + +Could you try running the guests without the TSC_DEADLINE CPUID flag set? + +This round we built 4.19.55, disabled the kvm_intel.preemption_timer parameter and ensured kvm.lapic_timer_advance_ns is 0, as advised by Paolo Bonzini. Sadly, yet again we encountered a freeze. + +Any other suggestions? + +Hi, this is an update after some extended tests and a fallback migration to 4.14. + +After doing another >10k migrations we are sure to say that we also encounter this issue on kernel 4.14. +We migrate vpses from servers in serial (one after the other) mode. And we notice that on some servers we encounter multiple freezes within a short period. These cases often occur in succession from the same source hypervisor, which for most (if not all) we've seen has a Gold CPU. So it seems like we are facing the same issue we were facing before in https://bugs.launchpad.net/qemu/+bug/1775555 + +The thing is though, we applied the patches that supposedly "fixed" it last time, except that right now it seems like the issue is still there and that after applying the previous patch we are still having issues running on the same kernel with the same qemu version (v2.11.2). + +Are there any other changes lately that could perhaps have fixed it which are worth trying? +We noticed that some pre migration checks were added to libvirt which would let the migration go into error if there are any severe mismatches between 2 hypervisor (hardware/kernel) configurations. + +We could try to run that and see if these throw more errors which could point us into some direction, is this something that you would recommend? + + +We have found a vm that recovered from a freeze and it seems like it has jumped in time. +Below I have pasted a dump of tty1, it is ocr'd though so some characters could have been misinterpreted. + +hild +[13198552.767867] le-rss:010 Killed process 10374 (crop) total,r,4376400, anon-rss,018, tl [13230065.246354] lid Out of memory: Kill process 2009 Icron) score 1 or sacrifice c [13230065.251227] le-rss:OkB Killed process 19050 (cron) total-am:437040B, anon-r=0,42, fi [13230065.378536] Out of memory: Kill process 2003 (cron) score 1 or sacrifice 1132 Killed process 19622 Icron) total-vM:4376400, anon-rss:018, fi +le-rss:OkB +[14071563.261117] Out of memory: Kill process 2083 (cron) score 1 or sacrifice child +[14071563.263500] Killed process 20260 (cron) total-vM:4376400, anon-rss:000, fi le-rss:OkB +[9223372037.903009] BUG: soft lockup - CPU#0 stuck for 4281394478s! [screen:4843] +[9223372037.983809] Stack: +[9223372037.983809] +[9223372037.903009] Call Trace: +[9223372037.983809] <IRQ> +[922337203].983809] <EOI> Code: 83 c4 58 5b 5d c9 90 90 to Of al 9e 19 c0 c9 9c 50 66 .6 90 66 90 c9 57 9E .6 90 c9 f0 BO 67 00 66 66 90 66 90 fd c9 40 c7 07 c9 fa 66 00 00 00 66 90 00 40 66 66 c7 47 90 c9 fb 66 66 90 00 066: + +This is VM is running Debian 7, it was approximately frozen for around 2 hours and 25 minutes before spinning back into action. + +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. + +Hi Thomas, + +We are still seeing this every once in a while. I can definitely tell you that it is connected to older Linux Guest kernels and we have not been able to identify a specific version which would make searching for a fix commit a bit easier. + +We are going to upgrade all our host kernels to 5.4 after which we will upgrade to a newer version of QEMU, temporarily working around this issue by selecting a specific set of hardware for migrations of older guest kernels. + +As time goes by the issue becomes less important as there will be less 3.* linux guest kernels running on our platform, but at the time of writing this is a significant amount. + +The guest kernels that we came across already had this patch applied: https://bugzilla.redhat.com/show_bug.cgi?id=1183773 + + +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/223 + + diff --git a/results/classifier/108/other/1831354 b/results/classifier/108/other/1831354 new file mode 100644 index 00000000..c42ffd0b --- /dev/null +++ b/results/classifier/108/other/1831354 @@ -0,0 +1,44 @@ +device: 0.795 +performance: 0.680 +graphic: 0.632 +network: 0.493 +PID: 0.475 +boot: 0.421 +vnc: 0.358 +debug: 0.330 +semantic: 0.328 +other: 0.305 +permissions: 0.288 +socket: 0.212 +files: 0.172 +KVM: 0.171 + +unable to read symlinks when mounting 9p filesystem with security_model=mapped + +I am trying to use clang that is mounted from a 9p filesystem that has the options + -fsdev local,id=virtfs3,path=/clang,security_model=mapped-file -device virtio-9p-pci,fsdev=virtfs3,mount_tag=clang + +clang has symlinks to clang-9. eg /clang/clang/bin/clang is a symlink that points to clang-9 in the current directory. + +the clang filesystem is on a bind mount point on /clang/clang on the host and this is mapped to the same place on the guest. If I have the same virtfs mount point with the security_model=none I don't have this problem. + +On the host: readlink clang +clang-9 + +and guest: + +ls: cannot read symbolic link 'clang': No such file or directory +lrwxrwxrwx 1 root root 7 May 30 02:21 clang + +readlink clang + +returns nothing. + + +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/173 + + diff --git a/results/classifier/108/other/1831362 b/results/classifier/108/other/1831362 new file mode 100644 index 00000000..71f788c6 --- /dev/null +++ b/results/classifier/108/other/1831362 @@ -0,0 +1,51 @@ +device: 0.752 +graphic: 0.672 +vnc: 0.442 +other: 0.388 +performance: 0.335 +semantic: 0.316 +socket: 0.262 +network: 0.184 +boot: 0.179 +PID: 0.167 +permissions: 0.137 +debug: 0.088 +files: 0.050 +KVM: 0.032 + +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/108/other/1831477 b/results/classifier/108/other/1831477 new file mode 100644 index 00000000..c9b86995 --- /dev/null +++ b/results/classifier/108/other/1831477 @@ -0,0 +1,36 @@ +device: 0.883 +graphic: 0.844 +network: 0.841 +socket: 0.799 +vnc: 0.798 +PID: 0.755 +files: 0.747 +semantic: 0.656 +boot: 0.613 +permissions: 0.603 +KVM: 0.474 +performance: 0.455 +debug: 0.422 +other: 0.393 + +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/108/other/1831486 b/results/classifier/108/other/1831486 new file mode 100644 index 00000000..5f601ef2 --- /dev/null +++ b/results/classifier/108/other/1831486 @@ -0,0 +1,61 @@ +other: 0.903 +permissions: 0.859 +performance: 0.821 +graphic: 0.821 +semantic: 0.820 +KVM: 0.808 +files: 0.800 +debug: 0.790 +device: 0.777 +socket: 0.776 +PID: 0.763 +network: 0.755 +vnc: 0.732 +boot: 0.699 + +qmp monitor deadlock (with spice events for ex) + +If an event is emitted during monitor_flush_locked() it will deadlock. + +Thread 1 (Thread 0x7f14f1854000 (LWP 7245)): +#0 0x00007f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0 +#1 0x00007f14fc2fedc9 in pthread_mutex_lock () at /lib64/libpthread.so.0 +#2 0x000055de60e19327 in qemu_mutex_lock_impl (mutex=0x55de61859e58, file=0x55de60f1a640 "/home/elmarco/src/qq/monitor.c", line=438) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66 +#3 0x000055de6085c5af in monitor_puts (mon=0x55de61859d30, str=0x55de62a61d30 "{\"timestamp\": {\"seconds\": 1559585795, \"microseconds\": 508720}, \"event\": \"SPICE_DISCONNECTED\", \"data\": {\"server\": {\"port\": \"/tmp/.9IW52Z/spice.sock\", \"family\": \"unix\", \"host\": \"localhost\"}, \"client\": {"...) at /home/elmarco/src/qq/monitor.c:438 +#4 0x000055de6085c85a in qmp_send_response (mon=0x55de61859d30, rsp=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:493 +#5 0x000055de6085c8ee in monitor_qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:521 +#6 0x000055de6085c9ea in monitor_qapi_event_queue_no_reenter (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:546 +#7 0x000055de6085cd7a in qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:621 +#8 0x000055de60e04bc3 in qapi_event_send_spice_disconnected (server=0x55de61ee7b30, client=0x55de620c9090) at qapi/qapi-events-ui.c:101 +#9 0x000055de60c84381 in channel_event (event=3, info=0x55de6222f4c0) at /home/elmarco/src/qq/ui/spice-core.c:234 +#10 0x00007f14fc70ba3b in reds_handle_channel_event (reds=<optimized out>, event=3, info=0x55de6222f4c0) at reds.c:318 +#11 0x00007f14fc6f407b in main_dispatcher_self_handle_channel_event (info=0x55de6222f4c0, event=3, self=0x55de61a5b0b0) at main-dispatcher.c:191 +#12 0x00007f14fc6f407b in main_dispatcher_channel_event (self=0x55de61a5b0b0, event=event@entry=3, info=0x55de6222f4c0) at main-dispatcher.c:191 +#13 0x00007f14fc713cf3 in red_stream_push_channel_event (s=s@entry=0x55de6222f400, event=event@entry=3) at red-stream.c:416 +#14 0x00007f14fc713d2b in red_stream_free (s=0x55de6222f400) at red-stream.c:390 +#15 0x00007f14fc6fa67c in red_channel_client_finalize (object=0x55de62511360) at red-channel-client.c:347 +#16 0x00007f14fe4cfcf0 in g_object_unref () at /lib64/libgobject-2.0.so.0 +#17 0x00007f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at red-channel-client.c:1340 +#18 0x00007f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at red-channel-client.c:1303 +#19 0x00007f14fc6cd479 in red_char_device_send_msg_to_client (client=<optimized out>, msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307 +#20 0x00007f14fc6cd479 in red_char_device_send_msg_to_clients (msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307 +#21 0x00007f14fc6cd479 in red_char_device_read_from_device (dev=0x55de61a5b3b0) at char-device.c:355 +#22 0x000055de60a27dba in spice_chr_write (chr=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at /home/elmarco/src/qq/chardev/spice.c:201 +#23 0x000055de60d89e29 in qemu_chr_write_buffer (s=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, offset=0x7ffcd5e1a860, write_all=false) at /home/elmarco/src/qq/chardev/char.c:113 +#24 0x000055de60d89f96 in qemu_chr_write (s=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, write_all=false) at /home/elmarco/src/qq/chardev/char.c:148 +#25 0x000055de60d8cf78 in qemu_chr_fe_write (be=0x55de61859d30, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at /home/elmarco/src/qq/chardev/char-fe.c:42 +#26 0x000055de6085c40f in monitor_flush_locked (mon=0x55de61859d30) at /home/elmarco/src/qq/monitor.c:404 +#27 0x000055de6085c614 in monitor_puts (mon=0x55de61859d30, str=0x55de622f6a40 "{\"return\": {}, \"id\": 2}\n") at /home/elmarco/src/qq/monitor.c:446 +#28 0x000055de6085c85a in qmp_send_response (mon=0x55de61859d30, rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:493 +#29 0x000055de60865902 in monitor_qmp_respond (mon=0x55de61859d30, rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:4128 +#30 0x000055de60865a19 in monitor_qmp_dispatch (mon=0x55de61859d30, req=0x55de622ec000) at /home/elmarco/src/qq/monitor.c:4157 +#31 0x000055de60865ce2 in monitor_qmp_bh_dispatcher (data=0x0) at /home/elmarco/src/qq/monitor.c:4224 + + +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/175 + + diff --git a/results/classifier/108/other/1831750 b/results/classifier/108/other/1831750 new file mode 100644 index 00000000..1830ae78 --- /dev/null +++ b/results/classifier/108/other/1831750 @@ -0,0 +1,94 @@ +KVM: 0.727 +vnc: 0.693 +other: 0.662 +graphic: 0.646 +device: 0.611 +network: 0.605 +permissions: 0.597 +debug: 0.594 +performance: 0.579 +files: 0.559 +semantic: 0.556 +boot: 0.532 +socket: 0.515 +PID: 0.498 + +virtual machine cpu soft lockup when qemu attach disk + +Hi, I found a problem that virtual machine cpu soft lockup when I attach a disk to the vm in the case that + +backend storage network has a large delay or IO pressure is too large. + +1) The disk xml which I attached is: + + <disk type='block' device='lun' rawio='yes'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/mapper/360022a11000c1e0a0787c23a000001cb'/> + <backingStore/> + <target dev='sdb' bus='scsi'/> + <alias name='scsi0-0-1-0'/> + <address type='drive' controller='0' bus='0' target='1' unit='0'/> + </disk> + +2) The bt of qemu main thread: + +#0 0x0000ffff9d78402c in pread64 () from /lib64/libpthread.so.0 +#1 0x0000aaaace3357d8 in pread64 (__offset=0, __nbytes=4096, __buf=0xaaaad47a5200, __fd=202) at /usr/include/bits/unistd.h:99 +#2 raw_is_io_aligned (fd=fd@entry=202, buf=buf@entry=0xaaaad47a5200, len=len@entry=4096) at block/raw_posix.c:294 +#3 0x0000aaaace33597c in raw_probe_alignment (bs=bs@entry=0xaaaad32ea920, fd=202, errp=errp@entry=0xfffffef7a330) at block/raw_posix.c:349 +#4 0x0000aaaace335a48 in raw_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330) at block/raw_posix.c:811 +#5 0x0000aaaace3404b0 in bdrv_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330, errp@entry=0xfffffef7a360) at block/io.c:122 +#6 0x0000aaaace340504 in bdrv_refresh_limits (bs=bs@entry=0xaaaad09ce800, errp=errp@entry=0xfffffef7a3b0) at block/io.c:97 +#7 0x0000aaaace2eb9f0 in bdrv_open_common (bs=bs@entry=0xaaaad09ce800, file=file@entry=0xaaaad0e89800, options=<optimized out>, errp=errp@entry=0xfffffef7a450) +at block.c:1194 +#8 0x0000aaaace2eedec in bdrv_open_inherit (filename=<optimized out>, filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", +reference=reference@entry=0x0, options=<optimized out>, options@entry=0xaaaad3d0f4b0, flags=<optimized out>, flags@entry=128, parent=parent@entry=0x0, +child_role=child_role@entry=0x0, errp=errp@entry=0xfffffef7a710) at block.c:1895 +#9 0x0000aaaace2ef510 in bdrv_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0, +options=options@entry=0xaaaad3d0f4b0, flags=flags@entry=128, errp=errp@entry=0xfffffef7a710) at block.c:1979 +#10 0x0000aaaace331ef0 in blk_new_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0, +options=options@entry=0xaaaad3d0f4b0, flags=128, errp=errp@entry=0xfffffef7a710) at block/block_backend.c:213 +#11 0x0000aaaace0da1f4 in blockdev_init (file=file@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", bs_opts=bs_opts@entry=0xaaaad3d0f4b0, +errp=errp@entry=0xfffffef7a710) at blockdev.c:603 +#12 0x0000aaaace0dc478 in drive_new (all_opts=all_opts@entry=0xaaaad4dc31d0, block_default_type=<optimized out>) at blockdev.c:1116 +#13 0x0000aaaace0e3ee0 in add_init_drive ( +optstr=optstr@entry=0xaaaad0872ec0 "file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native") +at device_hotplug.c:46 +#14 0x0000aaaace0e3f78 in hmp_drive_add (mon=0xfffffef7a810, qdict=0xaaaad0c8f000) at device_hotplug.c:67 +#15 0x0000aaaacdf7d688 in handle_hmp_command (mon=0xfffffef7a810, cmdline=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3199 +#16 0x0000aaaacdf7d778 in qmp_human_monitor_command ( +command_line=0xaaaacfc8e3c0 "drive_add dummy file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native", +has_cpu_index=false, cpu_index=0, errp=errp@entry=0xfffffef7a968) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:660 +#17 0x0000aaaace0fdb30 in qmp_marshal_human_monitor_command (args=<optimized out>, ret=0xfffffef7a9e0, errp=0xfffffef7a9d8) at qmp-marshal.c:2223 +#18 0x0000aaaace3b6ad0 in do_qmp_dispatch (request=<optimized out>, errp=0xfffffef7aa20, errp@entry=0xfffffef7aa40) at qapi/qmp_dispatch.c:115 +#19 0x0000aaaace3b6d58 in qmp_dispatch (request=<optimized out>) at qapi/qmp_dispatch.c:142 +#20 0x0000aaaacdf79398 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4010 +#21 0x0000aaaace3bd6c0 in json_message_process_token (lexer=0xaaaacf834c80, input=<optimized out>, type=JSON_RCURLY, x=214, y=274) at qobject/json_streamer.c:105 +#22 0x0000aaaace3f3d4c in json_lexer_feed_char (lexer=lexer@entry=0xaaaacf834c80, ch=<optimized out>, flush=flush@entry=false) at qobject/json_lexer.c:319 +#23 0x0000aaaace3f3e6c in json_lexer_feed (lexer=0xaaaacf834c80, buffer=<optimized out>, size=<optimized out>) at qobject/json_lexer.c:369 +#24 0x0000aaaacdf77c64 in monitor_qmp_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4040 +#25 0x0000aaaace0eab18 in tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=0xaaaacf90b280) at qemu_char.c:3260 +#26 0x0000ffff9dadf200 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#27 0x0000aaaace3c4a00 in glib_pollfds_poll () at util/main_loop.c:230 +--Type <RET> for more, q to quit, c to continue without paging-- +#28 0x0000aaaace3c4a88 in os_host_main_loop_wait (timeout=<optimized out>) at util/main_loop.c:278 +#29 0x0000aaaace3c4bf0 in main_loop_wait (nonblocking=<optimized out>) at util/main_loop.c:534 +#30 0x0000aaaace0f5d08 in main_loop () at vl.c:2120 +#31 0x0000aaaacdf3a770 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:5017 + + +From the bt we can see, when do qmp sush as drive_add, qemu main thread locks the qemu_global_mutex and do pread in raw_probe_alignmen. Pread is a synchronous operation. If backend storage network has a large delay or IO pressure is too large, the pread operation will not return for a long time, which make vcpu thread can't acquire qemu_global_mutex for a long time and make the vcpu thread unable to be scheduled for a long time. So virtual machine cpu soft lockup happened. + + +I thank qemu main thread should not hold qemu_global_mutex for a long time when do qmp that involving IO synchronous operation sush pread , ioctl, etc. + +Do you have any solutions or good ideas about it? Thanks for your reply! + + +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/176 + + diff --git a/results/classifier/108/other/1832 b/results/classifier/108/other/1832 new file mode 100644 index 00000000..3c665df3 --- /dev/null +++ b/results/classifier/108/other/1832 @@ -0,0 +1,16 @@ +performance: 0.650 +device: 0.531 +other: 0.430 +semantic: 0.341 +graphic: 0.265 +PID: 0.122 +vnc: 0.104 +boot: 0.104 +permissions: 0.083 +network: 0.067 +socket: 0.027 +KVM: 0.018 +debug: 0.017 +files: 0.005 + +i386 test registers are not handled diff --git a/results/classifier/108/other/1832250 b/results/classifier/108/other/1832250 new file mode 100644 index 00000000..9137b705 --- /dev/null +++ b/results/classifier/108/other/1832250 @@ -0,0 +1,77 @@ +permissions: 0.883 +other: 0.877 +vnc: 0.844 +graphic: 0.828 +performance: 0.814 +semantic: 0.808 +files: 0.801 +debug: 0.797 +PID: 0.793 +socket: 0.788 +device: 0.785 +KVM: 0.760 +network: 0.737 +boot: 0.699 + +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/108/other/1832353 b/results/classifier/108/other/1832353 new file mode 100644 index 00000000..ed873234 --- /dev/null +++ b/results/classifier/108/other/1832353 @@ -0,0 +1,72 @@ +device: 0.784 +files: 0.699 +permissions: 0.625 +network: 0.621 +PID: 0.618 +debug: 0.601 +other: 0.595 +graphic: 0.592 +socket: 0.586 +vnc: 0.569 +performance: 0.567 +semantic: 0.511 +boot: 0.470 +KVM: 0.245 + +cpu_exec: Assertion !have_mmap_lock() failed + +Hi, + +I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: + +qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. + +including with master qemu as of today. + +I'm attaching a tarball containing: +qemu-assert: +cmd lib proc_ptr_51.exe + +qemu-assert/lib: +ld-linux-armhf.so.3 libc.so.6 libgcc_s.so.1 libgfortran.so.5 libm.so.6 + +where cmd is the basic command used to launch the test & reproduce the failure. + +Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts. + + + +What version of qemu where you running? My HEAD is failing in a different way. + +It's fairly recent: +qemu-arm version 4.0.50 (v4.0.0-1215-ga578cdf-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf +Merge: 19735c8 43b3952 +Author: Peter Maydell <email address hidden> +Date: Mon Jun 10 16:09:19 2019 +0100 + + Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190610' into staging + + Move softmmu tlb into CPUNegativeOffsetState + +configured with: +--target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-debug + +Confirmed. The exact failure mode depends on debugging enabled or not. + +The test case is "buggy" in the sense that it makes a call to a NULL +function pointer, and the failure happens while trying to translate +the instructions at address 0. + +That said, the correct behaviour for QEMU is a SIGSEGV delivered to +the guest, not an assertion failure. + +The fix for this bug is now in master and will be in QEMU 4.1. + + +See series: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02189.html + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=52ba13f042714c4086416 + diff --git a/results/classifier/108/other/1832422 b/results/classifier/108/other/1832422 new file mode 100644 index 00000000..fce77f96 --- /dev/null +++ b/results/classifier/108/other/1832422 @@ -0,0 +1,35 @@ +device: 0.667 +performance: 0.561 +network: 0.510 +socket: 0.486 +files: 0.473 +graphic: 0.457 +semantic: 0.453 +vnc: 0.413 +permissions: 0.389 +boot: 0.294 +other: 0.278 +PID: 0.268 +debug: 0.226 +KVM: 0.224 + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. + + + + +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/184 + + diff --git a/results/classifier/108/other/1832535 b/results/classifier/108/other/1832535 new file mode 100644 index 00000000..cac085da --- /dev/null +++ b/results/classifier/108/other/1832535 @@ -0,0 +1,40 @@ +graphic: 0.618 +device: 0.461 +semantic: 0.421 +other: 0.331 +debug: 0.320 +socket: 0.287 +network: 0.285 +performance: 0.279 +boot: 0.261 +vnc: 0.244 +PID: 0.234 +files: 0.119 +KVM: 0.105 +permissions: 0.105 + +[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/108/other/1832914 b/results/classifier/108/other/1832914 new file mode 100644 index 00000000..5f9095a2 --- /dev/null +++ b/results/classifier/108/other/1832914 @@ -0,0 +1,30 @@ +device: 0.874 +semantic: 0.783 +files: 0.733 +graphic: 0.731 +PID: 0.603 +network: 0.566 +performance: 0.563 +debug: 0.545 +permissions: 0.536 +boot: 0.523 +other: 0.459 +socket: 0.420 +vnc: 0.347 +KVM: 0.267 + +Wrong error log when drive is specified qcow but qcow2 image file used. + +On archlinux qemu version 4.0.0 when I type: + +$ qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ... + +I get this output in stderr + +qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...: Unsupported qcow version 3 + +image.qcow2 is a qcow2 image created by qemu-img. error states that problem is with lack support with qcow3 format but real problem is that foramt=qcow is wrong option. + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=197bfa7da7c8eeb39aa5 + diff --git a/results/classifier/108/other/1833 b/results/classifier/108/other/1833 new file mode 100644 index 00000000..aebdc3ee --- /dev/null +++ b/results/classifier/108/other/1833 @@ -0,0 +1,99 @@ +graphic: 0.848 +semantic: 0.810 +other: 0.750 +permissions: 0.719 +debug: 0.677 +device: 0.643 +performance: 0.595 +PID: 0.558 +socket: 0.524 +vnc: 0.518 +KVM: 0.460 +network: 0.431 +boot: 0.429 +files: 0.429 + +ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element +Description of problem: +QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits. + +This seems to be a simple issue; I tracked it down to: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382 + +Updating that `+ 1` to a `+ 8` fixes the problem. +Steps to reproduce: +```c +#include <stdio.h> +#include <stdint.h> +#include <string.h> + +void st1q_sme_copy_test(uint8_t* src, uint8_t* dest) { + asm volatile( + "smstart sm\n" + "smstart za\n" + "ptrue p0.b\n" + "mov x12, xzr\n" + "ld1q {za0h.q[w12, 0]}, p0/z, %0\n" + "st1q {za0h.q[w12, 0]}, p0, %1\n" + "smstop za\n" + "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0"); +} + +void print_first_128(uint8_t* data) { + putchar('['); + for (int i = 0; i < 16; i++) { + printf("%02d", data[i]); + if (i != 15) + printf(", "); + } + printf("]\n"); +} + +int main() { + _Alignas(16) uint8_t dest[512] = { }; + _Alignas(16) uint8_t src[512] = { }; + for (int i = 0; i < sizeof(src); i++) + src[i] = i; + puts("Before"); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); + st1q_sme_copy_test(src, dest); + puts("\nAfter "); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); +} +``` + +Compile with (requires at least clang ~14, tested with clang 16):<br/> +`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` + +Run with:<br/> +`qemu-aarch64 -cpu max,sme=on ./qemu_repro` + +It's expected just to copy from `src` to `dest` and output: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +``` + +But currently outputs: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00] +``` +Additional information: +N/A diff --git a/results/classifier/108/other/1833048 b/results/classifier/108/other/1833048 new file mode 100644 index 00000000..e90615e0 --- /dev/null +++ b/results/classifier/108/other/1833048 @@ -0,0 +1,39 @@ +graphic: 0.824 +other: 0.809 +files: 0.732 +device: 0.727 +semantic: 0.652 +performance: 0.639 +PID: 0.530 +permissions: 0.502 +network: 0.489 +socket: 0.432 +KVM: 0.431 +vnc: 0.427 +boot: 0.425 +debug: 0.387 + +Guest Agent get-fsinfo doesn't show ZFS volumes + +Calling get-fsinfo on a virtual machine does not include ZFS volumes. Calling on a system with a single ZFS disk (ZFS as root fs) simply returns '[]', if other disks exist on the guest it only shows these. + +Expected behaviour: Show file system details like with other fs formats. + +Tried with debian stretch default qemu-guest-agent package and v4.0.0 from git, compiled locally - result is the same. +Host is using QEMU 3.0.1, but that shouldn't matter, right? + +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/108/other/1833053 b/results/classifier/108/other/1833053 new file mode 100644 index 00000000..4af6a812 --- /dev/null +++ b/results/classifier/108/other/1833053 @@ -0,0 +1,68 @@ +KVM: 0.841 +vnc: 0.840 +permissions: 0.801 +boot: 0.799 +other: 0.793 +device: 0.776 +graphic: 0.771 +performance: 0.760 +network: 0.754 +semantic: 0.731 +debug: 0.684 +socket: 0.637 +files: 0.632 +PID: 0.610 + +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/108/other/1833204 b/results/classifier/108/other/1833204 new file mode 100644 index 00000000..dee07cfa --- /dev/null +++ b/results/classifier/108/other/1833204 @@ -0,0 +1,139 @@ +KVM: 0.860 +other: 0.851 +vnc: 0.827 +device: 0.769 +graphic: 0.739 +performance: 0.739 +permissions: 0.730 +semantic: 0.727 +boot: 0.690 +debug: 0.689 +socket: 0.655 +files: 0.632 +network: 0.629 +PID: 0.621 + +VM failed to start in nested virtualization with error "KVM: entry failed, hardware error 0x0" + +Hi, + +I have 3 ubuntu nodes provisioned by IaaS. +Then I tried to launch VM again in my ubuntu nodes. +It's a little strange that VM could be started successfully in two nodes. +And always failed in one nodes with error "KVM: entry failed, hardware error 0x0". + +When using virsh to resume the VM, it failed with following error, +virsh # list + Id Name State +---------------------------------- + 1 default_vm-cirros paused + +virsh # resume default_vm-cirros +error: Failed to resume domain default_vm-cirros +error: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + + +The detailed log from /var/log/libvirt/qemu/default_vm-cirros.log is as below. +``` +2019-06-18 09:55:52.397+0000: starting up libvirt version: 5.0.0, package: 1.fc28 (Unknown, 2019-01-22-08:04:34, 64723eea657e48d296e6beb0b1be9c4c), qemu version: 3.1.0qemu-3.1.0-4.fc28, kernel: 4.15.0-47-generic, hostname: vm-cirros +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ +HOME=/root \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=default_vm-cirros,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_vm-cirros/master-key.aes \ +-machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,mpx=on,avx512f=on,avx512cd=on,ssbd=on,xsaveopt=on,abm=on,invpcid=off \ +-m 489 \ +-realtime mlock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-object iothread,id=iothread1 \ +-uuid 0d2a2043-41c0-59c3-9b17-025022203668 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=22,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-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-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 virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \ +-drive file=/var/run/kubevirt-ephemeral-disks/container-disk-data/default/vm-cirros/disk_containerdisk/disk-image.raw,format=raw,if=none,id=drive-ua-containerdisk,cache=none \ +-device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-ua-containerdisk,id=ua-containerdisk,bootindex=1,write-cache=on \ +-drive file=/var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-cirros/noCloud.iso,format=raw,if=none,id=drive-ua-cloudinitdisk,cache=none \ +-device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-ua-cloudinitdisk,id=ua-cloudinitdisk,write-cache=on \ +-netdev tap,fd=24,id=hostua-default,vhost=on,vhostfd=25 \ +-device virtio-net-pci,host_mtu=1430,netdev=hostua-default,id=ua-default,mac=16:57:38:cd:57:cb,bus=pci.1,addr=0x0 \ +-chardev socket,id=charserial0,fd=26,server,nowait \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,fd=27,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-vnc vnc=unix:/var/run/kubevirt-private/3b22a138-91af-11e9-af36-0016ac101123/virt-vnc \ +-device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +KVM: entry failed, hardware error 0x0 +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306d2 +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 14 f5 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 +``` + +Ubuntu node version as follow, +cat /etc/os-release +NAME="Ubuntu" +VERSION="18.04.2 LTS (Bionic Beaver)" +ID=ubuntu +ID_LIKE=debian +PRETTY_NAME="Ubuntu 18.04.2 LTS" +VERSION_ID="18.04" +HOME_URL="https://www.ubuntu.com/" +SUPPORT_URL="https://help.ubuntu.com/" +BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" +PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" +VERSION_CODENAME=bionic +UBUNTU_CODENAME=bionic + +Output of `uname -a` is: +4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux + + + +Any additional information needed, please let me know. +Thx. + +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/108/other/1833661 b/results/classifier/108/other/1833661 new file mode 100644 index 00000000..452e9cb1 --- /dev/null +++ b/results/classifier/108/other/1833661 @@ -0,0 +1,172 @@ +other: 0.882 +semantic: 0.874 +permissions: 0.853 +graphic: 0.848 +performance: 0.819 +device: 0.811 +KVM: 0.786 +PID: 0.781 +debug: 0.766 +socket: 0.716 +vnc: 0.709 +files: 0.707 +network: 0.705 +boot: 0.692 + +Linux kernel oops on Malta board while accessing pflash + +commit 33d609990621dea6c7d056c86f707b8811320ac1 + +While running tests/acceptance/linux_ssh_mips_malta.py, the big-endian tests fail: + + physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 + Intel/Sharp Extended Query Table at 0x0031 + Using buffer write method + Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 + Creating 3 MTD partitions on "physmap-flash.0": + 0x000000000000-0x000000100000 : "YAMON" + 0x000000100000-0x0000003e0000 : "User FS" + 0x0000003e0000-0x000000400000 : "Board Config" + CPU 0 Unable to handle kernel paging request at virtual address 00000014 + +The 64-bit test fails with: + + CPU 0 Unable to handle kernel paging request at virtual address 0000000000000028 + +Relevant 32-bit output: + +tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta32eb_kernel3_2_0 + +[ 34.968000] Using buffer write method +[ 38.324000] Searching for RedBoot partition table in physmap-flash.0 at offset 0x3f0000 +[ 38.328000] No RedBoot partition table detected in physmap-flash.0 +[ 39.032000] Creating 3 MTD partitions on "physmap-flash.0": +[ 39.032000] 0x000000000000-0x000000100000 : "YAMON" +[ 39.052000] 0x000000100000-0x0000003e0000 : "User FS" +[ 39.068000] 0x0000003e0000-0x000000400000 : "Board Config" +[ 40.924000] CPU 0 Unable to handle kernel paging request at virtual address 00000014, epc == c0203278, ra == c0203254 +[ 40.932000] Oops[#1]: +[ 40.932000] Cpu 0 +[ 40.932000] $ 0 : 00000000 1000a400 00000000 00000001 +[ 40.932000] $ 4 : c012f590 00000001 00000000 7fffffff +[ 40.932000] $ 8 : 8fbcbfe0 0000a400 00000000 8fae0000 +[ 40.932000] $12 : 74646368 00000001 806c0078 61720053 +[ 40.932000] $16 : 8fb38000 8fba63c0 c0200000 00000001 +[ 40.932000] $20 : 00000000 c0205074 8020953c 7fac45e4 +[ 40.932000] $24 : 00000003 80338058 +[ 40.932000] $28 : 8fbca000 8fbcbcd0 00000008 c0203254 +[ 40.932000] Hi : 00000009 +[ 40.932000] Lo : 85d47900 +[ 40.932000] epc : c0203278 mtd_open+0x94/0x1d0 [mtdchar] +[ 40.932000] Not tainted +[ 40.932000] ra : c0203254 mtd_open+0x70/0x1d0 [mtdchar] +[ 40.932000] Status: 1000a403 KERNEL EXL IE +[ 40.932000] Cause : 10800008 +[ 40.932000] BadVA : 00000014 +[ 40.932000] PrId : 00019300 (MIPS 24Kc) +[ 40.932000] Modules linked in: mtdchar(+) redboot cfi_cmdset_0001 cfi_probe cfi_util gen_probe sg evdev uhci_hcd ehci_hcd physmap map_funcs chipreg usbcore mtd psmouse sr_mod i2c_piix4 i2c_core cdrom serio_raw usb_common +[ 40.932000] Process mtd_probe (pid: 268, threadinfo=8fbca000, task=8fbbda88, tls=774b0490) +[ 40.932000] Stack : 00000000 8e9b9470 8fba63c0 8e9b9470 802094b0 8e9ad980 8e9b9470 8fba63c0 +[ 40.932000] 8e9ad980 802095d4 00000000 00000000 00000000 7fac45e4 00000003 8033768c +[ 40.932000] 8fba63c0 8f5a7518 8f811c80 8e9b9470 802094b0 00000000 00000000 7fac45e4 +[ 40.932000] 00000008 80202bb4 8fbcbe14 8fbcbe68 8fbcbdc0 8f4f4498 8f811c80 8fbcbe70 +[ 40.932000] 8fa29140 8fbcbe68 8e9b9470 00000024 00000000 00000000 00000005 7fac45e4 +[ 40.932000] ... +[ 40.932000] Call Trace: +[ 40.932000] [<c0203278>] mtd_open+0x94/0x1d0 [mtdchar] +[ 40.932000] [<802095d4>] chrdev_open+0x124/0x250 +[ 40.932000] [<80202bb4>] __dentry_open+0x27c/0x3d8 +[ 40.932000] [<8020400c>] nameidata_to_filp+0x64/0x78 +[ 40.932000] [<80214160>] do_last.isra.17+0x3a4/0x81c +[ 40.932000] [<802146d4>] path_openat+0xc0/0x4c4 +[ 40.932000] [<80214bf0>] do_filp_open+0x3c/0xac +[ 40.932000] [<80204134>] do_sys_open+0x114/0x200 +[ 40.932000] [<8010a9d0>] stack_done+0x20/0x40 +[ 40.932000] +[ 40.932000] +[ 40.932000] Code: 3c02c013 3c02c020 8c425070 <8c440014> 3c028022 2442eef4 0040f809 02602821 10400043 +[ 40.956000] ---[ end trace e666aa8cbfdf5c7f ]--- +udevd[192]: 'mtd_probe /dev/.tmp-char-90:3' +[hang] + +Relevant 64-bit output: + +tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta64eb_kernel3_2_0 + +[ 0.000000] Initializing cgroup subsys cpuset +[ 0.000000] Initializing cgroup subsys cpu +[ 0.000000] Linux version 3.2.0-4-5kc-malta (<email address hidden>) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 Debian 3.2.51-1 +[ 0.000000] bootconsole [early0] enabled +[ 0.000000] CPU revision is: 000182a0 (MIPS 20Kc) +[ 0.000000] FPU revision is: 000f8200 +[ 0.000000] Checking for the multiply/shift bug... no. +[ 0.000000] Checking for the daddiu bug... no. +[ 0.000000] Determined physical RAM map: +[ 0.000000] memory: 0000000000001000 @ 0000000000000000 (reserved) +[ 0.000000] memory: 00000000000ef000 @ 0000000000001000 (ROM data) +[ 0.000000] memory: 0000000000748000 @ 00000000000f0000 (reserved) +[ 0.000000] memory: 00000000077c7000 @ 0000000000838000 (usable) +[ 0.000000] Wasting 117824 bytes for tracking 2104 unused pages +[ 0.000000] Initrd not found or empty - disabling initrd +[ 0.000000] Kernel command line: printk.time=0 console=ttyS0 root=/dev/sda1 +[...] +Freeing prom memory: 956k freed +Freeing unused kernel memory: 244k freed + +INIT: version 2.88 booting + +Using makefile-style concurrent boot in runlevel S. +physmap platform flash device: 00400000 at 1e000000 +sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[...] +sd 0:0:0:0: Attached scsi generic sg0 type 0 +sr 1:0:0:0: Attached scsi generic sg1 type 5 +physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 +input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input1 +Intel/Sharp Extended Query Table at 0x0031 +Using buffer write method +Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 +Creating 3 MTD partitions on "physmap-flash.0": +0x000000000000-0x000000100000 : "YAMON" +0x000000100000-0x0000003e0000 : "User FS" +0x0000003e0000-0x000000400000 : "Board Config" +CPU 0 Unable to handle kernel paging request at virtual address 0000000000000028, epc == ffffffffc00f9234, ra == ffffffffc00f9210 + +When running tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta64el_kernel3_2_0, I'm getting in roughly 8% of executions: + +2019-09-18 22:37:43,665 linux_ssh_mips_m L0065 DEBUG| Intel/Sharp Extended Query Table at 0x0031 +2019-09-18 22:37:43,668 linux_ssh_mips_m L0065 DEBUG| Using buffer write method +2019-09-18 22:37:45,722 linux_ssh_mips_m L0065 DEBUG| Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 +2019-09-18 22:37:46,287 linux_ssh_mips_m L0065 DEBUG| ESC[?25lESC[?1cESC7Creating 3 MTD partitions on "physmap-flash.0": +2019-09-18 22:37:46,287 linux_ssh_mips_m L0065 DEBUG| 0x000000000000-0x000000100000 : "YAMON" +2019-09-18 22:37:46,314 linux_ssh_mips_m L0065 DEBUG| 0x000000100000-0x0000003e0000 : "User FS" +2019-09-18 22:37:46,319 linux_ssh_mips_m L0065 DEBUG| 0x0000003e0000-0x000000400000 : "Board Config" +2019-09-18 22:37:47,260 linux_ssh_mips_m L0065 DEBUG| ESC[1G[ESC[32m ok ESC[39;49mCPU 0 Unable to handle kernel paging request at virtual address +0000000000000028, epc == ffffffffc00ed234, ra == ffffffffc00ed210 +2019-09-18 22:37:47,262 linux_ssh_mips_m L0065 DEBUG| Oops[#1]: + + +And when running tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta32eb_kernel3_2_0: + +2019-09-19 00:02:47,151 linux_ssh_mips_m L0065 DEBUG| Searching for RedBoot partition table in physmap-flash.0 at offset 0x3f0000 +2019-09-19 00:02:47,154 linux_ssh_mips_m L0065 DEBUG| No RedBoot partition table detected in physmap-flash.0 +2019-09-19 00:02:47,847 linux_ssh_mips_m L0065 DEBUG| Creating 3 MTD partitions on "physmap-flash.0": +2019-09-19 00:02:47,850 linux_ssh_mips_m L0065 DEBUG| 0x000000000000-0x000000100000 : "YAMON" +2019-09-19 00:02:47,875 linux_ssh_mips_m L0065 DEBUG| 0x000000100000-0x0000003e0000 : "User FS" +2019-09-19 00:02:47,875 linux_ssh_mips_m L0065 DEBUG| 0x0000003e0000-0x000000400000 : "Board Config" +2019-09-19 00:02:48,792 linux_ssh_mips_m L0065 DEBUG| ESC[?25lESC[?1cESC7CPU 0 Unable to handle kernel paging request at virtual address 00000014, + epc == c0205278, ra == c0205254 +2019-09-19 00:02:48,794 linux_ssh_mips_m L0065 DEBUG| Oops[#1]: + +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/51 + + diff --git a/results/classifier/108/other/1833668 b/results/classifier/108/other/1833668 new file mode 100644 index 00000000..5d65d2f2 --- /dev/null +++ b/results/classifier/108/other/1833668 @@ -0,0 +1,66 @@ +other: 0.960 +performance: 0.953 +debug: 0.924 +files: 0.902 +semantic: 0.871 +graphic: 0.868 +PID: 0.867 +device: 0.831 +permissions: 0.830 +socket: 0.806 +network: 0.793 +vnc: 0.719 +KVM: 0.694 +boot: 0.655 + +linux-user: Unable to run ARM binaries on Aarch64 + +Download a ARM package from https://packages.debian.org/sid/busybox-static + +Here tested with: busybox-static_1.30.1-4_armel.deb + +$ file busybox.armel +busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14) + +$ qemu-aarch64 busybox.armel +busybox.armel: Invalid ELF image for this architecture + +$ qemu-aarch64 -cpu cortex-a7 busybox.armel +unable to find CPU model 'cortex-a7' + +Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1, +while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty: + +$ gdb -q aarch64-linux-user/qemu-aarch64 +(gdb) p aarch64_cpus +$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72", + initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}} +(gdb) p arm_cpus +$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}} + +Of course. There's a separate qemu-arm executable for that. + +Le 25/06/2019 à 16:43, Richard Henderson a écrit : +> Of course. There's a separate qemu-arm executable for that. + +On some other architectures (like ppc/ppc64) the idea is the 64bit +version supports also all 32bit versions CPUs. + +I think it's why this bug has been opened. + + +On 6/25/19 5:27 PM, Laurent Vivier wrote: +> Le 25/06/2019 à 16:43, Richard Henderson a écrit : +>> Of course. There's a separate qemu-arm executable for that. +> +> On some other architectures (like ppc/ppc64) the idea is the 64bit +> version supports also all 32bit versions CPUs. +> +> I think it's why this bug has been opened. + +At any rate the error message could be more explicit, to avoid confusion. + + diff --git a/results/classifier/108/other/1833871 b/results/classifier/108/other/1833871 new file mode 100644 index 00000000..948a99ff --- /dev/null +++ b/results/classifier/108/other/1833871 @@ -0,0 +1,36 @@ +graphic: 0.781 +device: 0.773 +semantic: 0.732 +files: 0.709 +vnc: 0.704 +other: 0.698 +performance: 0.679 +network: 0.637 +socket: 0.634 +permissions: 0.634 +PID: 0.500 +debug: 0.423 +boot: 0.359 +KVM: 0.306 + +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/108/other/1834 b/results/classifier/108/other/1834 new file mode 100644 index 00000000..1a3cd70b --- /dev/null +++ b/results/classifier/108/other/1834 @@ -0,0 +1,199 @@ +semantic: 0.842 +other: 0.832 +device: 0.802 +permissions: 0.802 +debug: 0.800 +PID: 0.796 +boot: 0.772 +network: 0.728 +performance: 0.721 +vnc: 0.707 +graphic: 0.707 +KVM: 0.698 +socket: 0.681 +files: 0.517 + +qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed. +Description of problem: + +Steps to reproduce: +1. Run qemu using the provided command line +2. linux kernel boot and qemu crashes at pci bus scan step +3. +Additional information: +``` +SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org +iPXE (http://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+3EFD0CE0+3EF30CE0 CA00 +iPXE (http://ipxe.org) 00:05.0 CB00 PCI2.10 PnP PMM+3EF1FCE0 3EF30CE0 CB00 +Booting from ROM... +[ 0.000000] Linux version 6.1.38-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230620) #1 SMP PREEMPT_DYNAMIC Thu Jul 6 18:52:54 UTC 2023 +[ 0.000000] Command line: console=ttyS0 +[ 0.000000] x86/fpu: x87 FPU will use FXSAVE +[ 0.000000] signal: max sigframe size: 1040 +[ 0.000000] 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-0x000000003ffdefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000003ffdf000-0x000000003fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 3.0.0 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 0.000000] last_pfn = 0x3ffdf max_arch_pfn = 0x400000000 +[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.000000] found SMP MP-table at [mem 0x000f5b80-0x000f5b8f] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F59A0 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000003FFE238A 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000003FFE217A 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000003FFE0040 00213A (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000003FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000003FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000003FFE22EE 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: MCFG 0x000000003FFE2326 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: WAET 0x000000003FFE2362 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: Reserving FACP table memory at [mem 0x3ffe217a-0x3ffe226d] +[ 0.000000] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe2179] +[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f] +[ 0.000000] ACPI: Reserving APIC table memory at [mem 0x3ffe226e-0x3ffe22ed] +[ 0.000000] ACPI: Reserving HPET table memory at [mem 0x3ffe22ee-0x3ffe2325] +[ 0.000000] ACPI: Reserving MCFG table memory at [mem 0x3ffe2326-0x3ffe2361] +[ 0.000000] ACPI: Reserving WAET table memory at [mem 0x3ffe2362-0x3ffe2389] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000003ffdefff] +[ 0.000000] Normal empty +[ 0.000000] Device 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-0x000000003ffdefff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000003ffdefff] +[ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA: 97 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA32: 33 pages in unavailable ranges +[ 0.000000] ACPI: PM-Timer IO Port: 0x608 +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 32, 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: Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs +[ 0.000000] [mem 0x40000000-0xafffffff] available for PCI devices +[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 +[ 0.000000] percpu: Embedded 52 pages/cpu s173288 r8192 d31512 u1048576 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 257759 +[ 0.000000] Kernel command line: console=ttyS0 +[ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off +[ 0.000000] Memory: 1002116K/1048052K available (12294K kernel code, 1469K rwdata, 2600K rodata, 1488K init, 2040K bss, 45680K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 31276 entries in 123 pages +[ 0.000000] ftrace: allocated 123 pages with 6 groups +[ 0.000000] ftrace: allocating 31276 entries in 123 pages +[ 0.000000] ftrace: allocated 123 pages with 6 groups +[ 0.000000] Dynamic Preempt: none +[ 0.000000] rcu: Preemptible hierarchical RCU implementation. +[ 0.000000] rcu: RCU event tracing is enabled. +[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2. +[ 0.000000] Trampoline variant of Tasks RCU enabled. +[ 0.000000] Rude variant of Tasks RCU enabled. +[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. +[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16 +[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 0.000000] Console: colour VGA+ 80x25 +[ 0.000000] printk: console [ttyS0] enabled +[ 0.000000] ACPI: Core revision 20220331 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.020000] APIC: Switch to symmetric I/O mode setup +[ 0.040000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.120000] tsc: Unable to calibrate against PIT +[ 0.120000] tsc: using HPET reference calibration +[ 0.120000] tsc: Detected 2299.960 MHz processor +[ 0.001362] tsc: Marking TSC unstable due to TSCs unsynchronized +[ 0.002851] Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.92 BogoMIPS (lpj=22999600) +[ 0.004441] pid_max: default: 32768 minimum: 301 +[ 0.019780] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.020332] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.078474] process: using AMD E400 aware idle routine +[ 0.079221] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.079631] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.081092] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.082698] Spectre V2 : Mitigation: Retpolines +[ 0.083053] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.083616] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT +[ 0.348864] Freeing SMP alternatives memory: 32K +[ 0.514732] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +[ 0.536546] cblist_init_generic: Setting adjustable number of callback queues. +[ 0.537604] cblist_init_generic: Setting shift to 1 and lim to 1. +[ 0.538995] cblist_init_generic: Setting shift to 1 and lim to 1. +[ 0.541338] Performance Events: PMU not available due to virtualization, using software events only. +[ 0.548504] rcu: Hierarchical SRCU implementation. +[ 0.548986] rcu: Max phase no-delay instances is 1000. +[ 0.563842] smp: Bringing up secondary CPUs ... +[ 0.583950] x86: Booting SMP configuration: +[ 0.584395] .... node #0, CPUs: #1 +[ 0.802667] smp: Brought up 1 node, 2 CPUs +[ 0.803300] smpboot: Max logical packages: 1 +[ 0.803821] smpboot: Total of 2 processors activated (9202.49 BogoMIPS) +[ 0.864556] devtmpfs: initialized +[ 0.897545] x86/mm: Memory block size: 128MB +[ 0.936982] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.938878] futex hash table entries: 512 (order: 3, 32768 bytes, linear) +[ 0.980994] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 1.004001] thermal_sys: Registered thermal governor 'step_wise' +[ 1.004143] thermal_sys: Registered thermal governor 'user_space' +[ 1.009528] cpuidle: using governor menu +[ 1.022723] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 1.043717] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 1.050546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 1.060576] PCI: Using configuration type 1 for base access +[ 1.074215] mtrr: your CPUs had inconsistent fixed MTRR settings +[ 1.075157] mtrr: your CPUs had inconsistent variable MTRR settings +[ 1.076043] mtrr: your CPUs had inconsistent MTRRdefType settings +[ 1.076840] mtrr: probably your BIOS does not setup all CPUs. +[ 1.077612] mtrr: corrected configuration. +[ 1.453630] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages +[ 1.454286] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page +[ 1.467152] raid6: skipped pq benchmark and selected sse2x4 +[ 1.467152] raid6: using intx1 recovery algorithm +[ 1.485004] ACPI: Added _OSI(Module Device) +[ 1.485539] ACPI: Added _OSI(Processor Device) +[ 1.485909] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 1.486309] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.578101] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.670966] ACPI: Interpreter enabled +[ 1.676848] ACPI: PM: (supports S0 S3 S5) +[ 1.677404] ACPI: Using IOAPIC for interrupt routing +[ 1.683268] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 1.684107] PCI: Using E820 reservations for host bridge windows +[ 1.691382] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 1.828171] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 1.831923] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] +[ 1.839401] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC] +[ 1.843631] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability] +[ 1.867627] PCI host bridge to bus 0000:00 +[ 1.868866] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 1.870044] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 1.870572] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 1.871151] pci_bus 0000:00: root bus resource [mem 0x40000000-0xafffffff window] +[ 1.871719] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 1.872269] pci_bus 0000:00: root bus resource [mem 0x100000000-0x8ffffffff window] +[ 1.873668] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 1.880983] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 1.898659] pci 0000:00:01.0: [1234:1111] type 00 class 0x030000 +qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed. +``` diff --git a/results/classifier/108/other/1835466 b/results/classifier/108/other/1835466 new file mode 100644 index 00000000..12ae7eb9 --- /dev/null +++ b/results/classifier/108/other/1835466 @@ -0,0 +1,265 @@ +KVM: 0.872 +vnc: 0.850 +other: 0.824 +debug: 0.747 +performance: 0.746 +graphic: 0.737 +device: 0.732 +permissions: 0.722 +semantic: 0.702 +files: 0.696 +socket: 0.687 +network: 0.676 +PID: 0.673 +boot: 0.633 + +qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?) + +After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release tarball), I'm seeing a (reproducible) crash related to audio subsystem. + +I recompiled qemu with debugging options and got it to crash under gdb: + +Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted. +0x00007ffff52e420b in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff52e420b in raise () at /lib64/libc.so.6 +#1 0x00007ffff52c6524 in abort () at /lib64/libc.so.6 +#2 0x000000000041ec33 in audio_get_pdo_in (dev=<optimized out>) at audio/audio_template.h:328 +#3 0x00000000005d0123 in AUD_open_in + (card=0x7ffdde98dbc8, sw=0x7ffff17444e0, name=0x999d80 "adc", callback_opaque=callback_opaque@entry=0x7ffdde98fd58, callback_fn=0x610940 <hda_audio_input_cb>, as=as@entry=0x7ffdde98fd84) at audio/audio_template.h:434 +#4 0x000000000060fe2e in hda_audio_setup (st=0x7ffdde98fd58) at hw/audio/hda-codec.c:490 +#5 0x000000000061051b in hda_audio_command (hda=0x7ffdde98db40, nid=4, data=<optimized out>) at hw/audio/hda-codec.c:590 +#6 0x000000000060ea20 in intel_hda_send_command (d=d@entry=0x7ffff0a2fc00, verb=verb@entry=4341777) at hw/audio/intel-hda.c:301 +#7 0x000000000060ebbe in intel_hda_corb_run (d=<optimized out>) at hw/audio/intel-hda.c:336 +#8 0x000000000060ebbe in intel_hda_corb_run (d=0x7ffff0a2fc00) at hw/audio/intel-hda.c:305 +#9 0x0000000000495b99 in memory_region_write_accessor + (mr=mr@entry=0x7ffff0a307a0, addr=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, shift=<optimized out>, mask=mask@entry=65535, attrs=...) + at memory.c:502 +#10 0x000000000049448e in access_with_adjusted_size + (addr=addr@entry=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x495b10 <memory_region_write_accessor>, mr=0x7ffff0a307a0, attrs=...) at memory.c:568 +#11 0x00000000004974f3 in memory_region_dispatch_write (mr=mr@entry=0x7ffff0a307a0, addr=72, data=<optimized out>, size=2, attrs=attrs@entry=...) + at memory.c:1496 +#12 0x000000000042afbc in flatview_write_continue + (fv=fv@entry=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x7ffff0a307a0) at exec.c:3279 +#13 0x000000000042b1d6 in flatview_write + (fv=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2) + at exec.c:3318 +#14 0x000000000042e2a6 in address_space_write + (as=0xfc5080 <address_space_memory>, addr=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=2) + at exec.c:3408 +#15 0x000000000042e33a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., + attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=<optimized out>, is_write=<optimized out>) at exec.c:3419 +#16 0x00000000004ac3c6 in kvm_cpu_exec (cpu=cpu@entry=0x7ffff0a81140) at accel/kvm/kvm-all.c:2034 +#17 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=0x7ffff0a81140) at cpus.c:1281 +#18 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x7ffff0a81140) at cpus.c:1254 +#19 0x000000000089d0eb in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:502 +#20 0x00007ffff549319c in start_thread () at /lib64/libpthread.so.0 +#21 0x00007ffff53ba4af in clone () at /lib64/libc.so.6 + + +After some poking around, I think there's something overwriting dev->driver so this switch(dev->driver) statement falls through to abort(): https://git.qemu.org/?p=qemu.git;a=blob;f=audio/audio_template.h;h=1232bb54db0e7073e60e3ccb72c1ed72cf5e3831;hb=131b9a05705636086699df15d4a6d328bb2585e8#l304 + + +Here's why I think so: + +$ export QEMU_AUDIO_DRV=pa +$ gdb /usr/bin/qemu-system-x86_64 +(gdb) b qpa_audio_init +Breakpoint 1 at 0x79bcb0: file audio/paaudio.c, line 831. +(gdb) b audio_get_pdo_in +Breakpoint 2 at 0x5ce320: file audio/audio_template.h, line 304. +(gdb) run -enable-kvm -cpu Nehalem -machine q35 -device intel-iommu -name Workstation -smp 4 -m 8G -soundhw hda -rtc base=localtime -drive file=workstation-disk0.qcow2,if=virtio,format=qcow2 -drive file=workstation-disk1.qcow2,if=virtio,format=qcow2 -net nic,model=virtio,macaddr=aa:bb:cc:dd:ee:ff -net tap,ifname=tap42 -monitor telnet:127.0.0.1:7043,server,nowait -pidfile workstation.pid -vga qxl -global qxl-vga.vgamem_mb=64 -device usb-ehci,id=ehci -device usb-host,vendorid=0x1390,productid=0x5454,bus=ehci.0 -device usb-host,vendorid=0x054c,bus=ehci.0 -device usb-tablet -device nec-usb-xhci,id=xhci -device usb-host,vendorid=0x10c4,productid=0x888e,bus=xhci.0 + +Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831 +(gdb) p (*dev)->driver +$1 = AUDIODEV_DRIVER_PA +(gdb) p/d AUDIODEV_DRIVER_PA +$2 = 5 +(gdb) cont +Continuing. +[Thread 0x7ffff09ff700 (LWP 4078) exited] +audio: warning: Using timer based audio emulation +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$3 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$4 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$5 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. +[New Thread 0x7ffff09ff700 (LWP 4483)] +[New Thread 0x7ffddcdff700 (LWP 4489)] +[New Thread 0x7ffddbdff700 (LWP 4490)] +[New Thread 0x7ffddb1ff700 (LWP 4491)] +[New Thread 0x7ffdd2dff700 (LWP 4494)] +[New Thread 0x7ffdd25fe700 (LWP 4495)] +[New Thread 0x7ffdd1dfd700 (LWP 4497)] +[New Thread 0x7ffdda5ff700 (LWP 4500)] +[New Thread 0x7ffdcedff700 (LWP 4501)] +qemu-system-x86_64: warning: guest updated active QH +[Switching to Thread 0x7fffef7ff700 (LWP 4097)] + +Thread 4 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$6 = 176 + + +For what it's worth, guest is Fedora 29, host is a Slackware system with qemu compiled (manually) with these options: + +CFLAGS="-O2 -fPIC" \ +CXXFLAGS="-O2 -fPIC" \ +./configure \ + --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var \ + --enable-gtk \ + --enable-system \ + --enable-kvm \ + --enable-virtfs \ + --enable-sdl \ + --enable-gnutls \ + --enable-curses \ + --enable-virtfs \ + --enable-curl \ + --enable-linux-aio \ + --enable-vhost-net \ + --enable-spice \ + --enable-libusb \ + --enable-usb-redir \ + --enable-lzo \ + --enable-bzip2 \ + --enable-libssh2 \ + --enable-numa \ + --enable-jemalloc \ + --enable-opengl \ + --audio-drv-list=alsa,oss,sdl,pa \ + --enable-vnc --enable-vnc-sasl --enable-vnc-png --enable-vnc-jpeg \ + --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user,arm-softmmu,arm-linux-user,armeb-linux-user,sparc64-softmmu,sparc-softmmu,sparc32plus-linux-user,sparc64-linux-user \ + --enable-debug --extra-cflags="-g3" --extra-ldflags="-g3" --disable-strip --disable-pie # For debugging only + +Can you set a watchpoint for (*dev)->driver and see where it fires? + +My gdb-fu isn't great - does the following help? + + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 audio/audio_template.h: No such file or directory. +(gdb) print (*dev)->driver +$1 = AUDIODEV_DRIVER_PA +(gdb) watch *0x7ffff161b6a0 +Hardware watchpoint 4: *0x7ffff161b6a0 +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831 +831 audio/paaudio.c: No such file or directory. +(gdb) cont +Continuing. +audio: warning: Using timer based audio emulation + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 audio/audio_template.h: No such file or directory. +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) p (*dev)->driver +$2 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. +[New Thread 0x7ffff09ff700 (LWP 6438)] +[New Thread 0x7ffddcdff700 (LWP 6439)] + +Thread 1 "qemu-system-x86" hit Hardware watchpoint 4: *0x7ffff161b6a0 + +Old value = -486628296 +New value = 0 +0x00007ffff5422cf0 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff5422cf0 in __memset_avx2_unaligned_erms () at /lib64/libc.so.6 +#1 0x00007ffff580cee3 in calloc () at /usr/lib64/libjemalloc.so.2 +#2 0x00007ffff7ac9db1 in g_malloc0 () at /usr/lib64/libglib-2.0.so.0 +#3 0x00007ffff7bc7cc9 in () at /usr/lib64/libgobject-2.0.so.0 +#4 0x00007ffff7bca8b8 in g_type_register_static () at /usr/lib64/libgobject-2.0.so.0 +#5 0x00007ffff7bca94d in g_type_register_static_simple () at /usr/lib64/libgobject-2.0.so.0 +#6 0x00007ffff7040e3a in () at /usr/lib64/libgtk-3.so.0 +#7 0x00007ffff7043865 in gtk_icon_theme_get_type () at /usr/lib64/libgtk-3.so.0 +#8 0x00007ffff7043889 in gtk_icon_theme_new () at /usr/lib64/libgtk-3.so.0 +#9 0x00007ffff7043aa5 in gtk_icon_theme_get_for_screen () at /usr/lib64/libgtk-3.so.0 +#10 0x00000000007a0df3 in gtk_display_init (ds=<optimized out>, opts=0xfe7ae0 <dpy>) at ui/gtk.c:2200 +#11 0x0000000000423dd8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4532 +(gdb) +(gdb) cont +Continuing. +[Thread 0x7ffddcdff700 (LWP 6439) exited] + +Thread 1 "qemu-system-x86" hit Hardware watchpoint 4: *0x7ffff161b6a0 + +Old value = 0 +New value = -245161264 +0x00007ffff7bc7de1 in ?? () from /usr/lib64/libgobject-2.0.so.0 +(gdb) cont +Continuing. +[New Thread 0x7ffddcdff700 (LWP 6507)] +[New Thread 0x7ffddbbff700 (LWP 6508)] +[New Thread 0x7ffdd85ff700 (LWP 6509)] +[New Thread 0x7ffdd25ff700 (LWP 6510)] +[New Thread 0x7ffdd1dfe700 (LWP 6511)] +[New Thread 0x7ffdd15fd700 (LWP 6512)] +[New Thread 0x7ffddaafa700 (LWP 6513)] +[New Thread 0x7ffdce7ff700 (LWP 6514)] +[New Thread 0x7ffdcdbff700 (LWP 6515)] +qemu-system-x86_64: warning: guest updated active QH +[Switching to Thread 0x7fffee9ff700 (LWP 6340)] + +Thread 5 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) print (*dev)->driver +$3 = 176 + + +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/108/other/1835477 b/results/classifier/108/other/1835477 new file mode 100644 index 00000000..5e0c73f8 --- /dev/null +++ b/results/classifier/108/other/1835477 @@ -0,0 +1,29 @@ +graphic: 0.865 +device: 0.840 +other: 0.795 +semantic: 0.683 +performance: 0.651 +boot: 0.644 +vnc: 0.486 +PID: 0.468 +socket: 0.442 +permissions: 0.438 +debug: 0.370 +network: 0.370 +files: 0.350 +KVM: 0.082 + +Converting qcow2 to vmdk on MacOSX results in a non-bootable image + +When using qemu-img convert -O vmdk with version 3.1.0 or 4.0.0 on OSX (10.14.3) with a qcow2 image (https://cloud-images.ubuntu.com/bionic/20190703/bionic-server-cloudimg-amd64.img), the resulting image is not bootable. + +Running the same command on Ubuntu 18.04 results in a bootable image as expected + +Try the solutions in 1828508 ( -o adapter_type=lsilogic,subformat=monolithicFlat) 1776920 ( -S 0 ) do not work either + +What other steps can I take to troubleshoot? + +Does the problem happen only when the image is on APFS? when the destination is on APFS? Neither? Try to see if it's the filesystem. Use OSX to convert images on a non-APFS formatted external drive to see if that improves your luck. + +I'm assuming this is a duplicate of 1776920 which is still open because we have no OSX developers willing or able to debug this problem. + diff --git a/results/classifier/108/other/1835693 b/results/classifier/108/other/1835693 new file mode 100644 index 00000000..2301bfb9 --- /dev/null +++ b/results/classifier/108/other/1835693 @@ -0,0 +1,39 @@ +graphic: 0.870 +device: 0.644 +boot: 0.491 +files: 0.459 +semantic: 0.422 +PID: 0.418 +other: 0.344 +socket: 0.322 +performance: 0.298 +network: 0.280 +debug: 0.248 +permissions: 0.228 +vnc: 0.220 +KVM: 0.008 + +s390x binaries segfault + +Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host. + +$ cat hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ s390x-linux-gnu-g++ -o hello hello.cpp + +$ qemu-s390x-static hello +Segmentation fault + +Does "make check-tcg" work in this case? It works for me here. + +Which QEMU version are you using here? Can you reproduce this issue with the latest upstream QEMU ? ... otherwise, please report this issue to the Debian bug tracker instead. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1835729 b/results/classifier/108/other/1835729 new file mode 100644 index 00000000..ae076b86 --- /dev/null +++ b/results/classifier/108/other/1835729 @@ -0,0 +1,42 @@ +graphic: 0.807 +device: 0.671 +other: 0.628 +performance: 0.552 +semantic: 0.527 +network: 0.435 +socket: 0.394 +permissions: 0.393 +debug: 0.376 +files: 0.353 +PID: 0.345 +boot: 0.323 +vnc: 0.291 +KVM: 0.122 + +GTK display does not support host scale factor + +In the GNOME desktop environment, for HiDPI displays there is support to upscale everything. + +This can be set in "System Settings -> Displays -> Scale". + +I believe this affects GDK in the same way as setting the "GDK_SCALE" environment variable does. + +When launching `qemu-system-x86_64 ... -display gtk`, this scale factor seems to get lost; the result is that the host window is upscaled and doubled in size, while the guest appears only in the bottom left corner of the UI. + + + +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/108/other/1835793 b/results/classifier/108/other/1835793 new file mode 100644 index 00000000..6517b512 --- /dev/null +++ b/results/classifier/108/other/1835793 @@ -0,0 +1,36 @@ +debug: 0.806 +graphic: 0.705 +device: 0.644 +semantic: 0.616 +performance: 0.570 +other: 0.559 +network: 0.430 +socket: 0.406 +vnc: 0.395 +permissions: 0.371 +PID: 0.343 +boot: 0.326 +files: 0.307 +KVM: 0.174 + +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/108/other/1835827 b/results/classifier/108/other/1835827 new file mode 100644 index 00000000..f4ca77c5 --- /dev/null +++ b/results/classifier/108/other/1835827 @@ -0,0 +1,30 @@ +device: 0.833 +graphic: 0.829 +network: 0.711 +socket: 0.591 +vnc: 0.580 +semantic: 0.531 +files: 0.459 +permissions: 0.388 +performance: 0.340 +boot: 0.328 +PID: 0.306 +debug: 0.237 +KVM: 0.166 +other: 0.145 + +HTIF symbols no longer recognized by RISC-V spike board + +Tested commit: f34edbc760b0f689deddd175fc08732ecb46665f + +I belive this was introduced in 0ac24d56c5e7d32423ea78ac58a06b444d1df04d when the spike's load_kernel() was moved to riscv_load_kernel() which no longer included htif_symbol_callback(). + +I think you are right. Would you like to write a patch to fix the issue? + +No, patch sign-off requires a legal name. + +Ok, I'll add it to my to do list then + +Patch has been included in QEMU v4.2: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6478dd745dca49d632 + diff --git a/results/classifier/108/other/1835865 b/results/classifier/108/other/1835865 new file mode 100644 index 00000000..734b639f --- /dev/null +++ b/results/classifier/108/other/1835865 @@ -0,0 +1,85 @@ +other: 0.763 +KVM: 0.722 +device: 0.698 +graphic: 0.697 +permissions: 0.694 +vnc: 0.692 +semantic: 0.687 +network: 0.683 +performance: 0.683 +socket: 0.676 +files: 0.674 +boot: 0.665 +debug: 0.660 +PID: 0.649 + +piix crashes on mips when accessing acpi-pci-hotplug + +$ qemu-system-mips --version +QEMU emulator version 4.0.50 (v4.0.0-1975-gf34edbc760) + +$ qemu-system-mips -machine malta -bios /dev/null -nodefaults -monitor stdio -S +(qemu) o 0xaf00 0 +qemu-system-mips: hw/acpi/cpu.c:197: cpu_hotplug_hw_init: Assertion `mc->possible_cpu_arch_ids' failed. +Aborted (core dumped) + +(gdb) bt +#0 0x00007f6fd748957f in raise () at /lib64/libc.so.6 +#1 0x00007f6fd7473895 in abort () at /lib64/libc.so.6 +#2 0x00007f6fd7473769 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007f6fd7481a26 in .annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x00005646d58ca7bd in cpu_hotplug_hw_init (as=0x5646d6ae3300, owner=0x5646d6fd5b10, state=0x5646d6fd7a30, base_addr=44800) at hw/acpi/cpu.c:197 +#5 0x00005646d58c5284 in acpi_switch_to_modern_cphp (gpe_cpu=0x5646d6fd7910, cpuhp_state=0x5646d6fd7a30, io_port=44800) at hw/acpi/cpu_hotplug.c:107 +#6 0x00005646d58c3431 in piix4_set_cpu_hotplug_legacy (obj=0x5646d6fd5b10, value=false, errp=0x5646d61cdb28 <error_abort>) at hw/acpi/piix4.c:617 +#7 0x00005646d5b00c70 in property_set_bool (obj=0x5646d6fd5b10, v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", opaque=0x5646d707d110, errp=0x5646d61cdb28 <error_abort>) at qom/object.c:2076 +#8 0x00005646d5afeee6 in object_property_set (obj=0x5646d6fd5b10, v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 <error_abort>) at qom/object.c:1268 +#9 0x00005646d5b01fb8 in object_property_set_qobject (obj=0x5646d6fd5b10, value=0x5646d75b5450, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 <error_abort>) at qom/qom-qobject.c:26 +#10 0x00005646d5aff1cb in object_property_set_bool (obj=0x5646d6fd5b10, value=false, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 <error_abort>) at qom/object.c:1334 +#11 0x00005646d58c4fce in cpu_status_write (opaque=0x5646d6fd7910, addr=0, data=0, size=1) at hw/acpi/cpu_hotplug.c:44 +#12 0x00005646d569c707 in memory_region_write_accessor (mr=0x5646d6fd7920, addr=0, value=0x7ffc18053068, size=1, shift=0, mask=255, attrs=...) at memory.c:503 +#13 0x00005646d569c917 in access_with_adjusted_size (addr=0, value=0x7ffc18053068, size=1, access_size_min=1, access_size_max=4, access_fn=0x5646d569c61e <memory_region_write_accessor>, mr=0x5646d6fd7920, attrs=...) + at memory.c:569 +#14 0x00005646d569f8f3 in memory_region_dispatch_write (mr=0x5646d6fd7920, addr=0, data=0, size=1, attrs=...) at memory.c:1497 +#15 0x00005646d563e5c5 in flatview_write_continue (fv=0x5646d751b000, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4, addr1=0, l=1, mr=0x5646d6fd7920) at exec.c:3324 +#16 0x00005646d563e70a in flatview_write (fv=0x5646d751b000, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3363 +#17 0x00005646d563ea0f in address_space_write (as=0x5646d618abc0 <address_space_io>, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3453 +#18 0x00005646d5696ee5 in cpu_outl (addr=44800, val=0) at ioport.c:80 +#19 0x00005646d57585d0 in hmp_ioport_write (mon=0x5646d6bc70e0, qdict=0x5646d6cf7140) at monitor/misc.c:1058 +#20 0x00005646d5a77b99 in handle_hmp_command (mon=0x5646d6bc70e0, cmdline=0x5646d6bc2542 "0xaf00 0") at monitor/hmp.c:1082 +#21 0x00005646d5a7540a in monitor_command_cb (opaque=0x5646d6bc70e0, cmdline=0x5646d6bc2540 "o 0xaf00 0", readline_opaque=0x0) at monitor/hmp.c:47 +#22 0x00005646d5c71450 in readline_handle_byte (rs=0x5646d6bc2540, ch=13) at util/readline.c:408 +#23 0x00005646d5a7858f in monitor_read (opaque=0x5646d6bc70e0, buf=0x7ffc180533d0 "\rtc\327FV", size=1) at monitor/hmp.c:1312 +#24 0x00005646d5bc8d17 in qemu_chr_be_write_impl (s=0x5646d6add000, buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:177 +#25 0x00005646d5bc8d7b in qemu_chr_be_write (s=0x5646d6add000, buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:189 +#26 0x00005646d5bcb6bf in fd_chr_read (chan=0x5646d6a80d60, cond=G_IO_IN, opaque=0x5646d6add000) at chardev/char-fd.c:68 +#27 0x00005646d5bec485 in qio_channel_fd_source_dispatch (source=0x5646d765a480, callback=0x5646d5bcb561 <fd_chr_read>, user_data=0x5646d6add000) at io/channel-watch.c:84 +#28 0x00007f6fd9c1606d in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#29 0x00005646d5c5323a in glib_pollfds_poll () at util/main-loop.c:213 +#30 0x00005646d5c532b4 in os_host_main_loop_wait (timeout=29821719) at util/main-loop.c:236 +#31 0x00005646d5c533b9 in main_loop_wait (nonblocking=0) at util/main-loop.c:512 +#32 0x00005646d581d1a1 in main_loop () at vl.c:1791 +#33 0x00005646d582485f in main (argc=11, argv=0x7ffc18054868, envp=0x7ffc180548c8) at vl.c:4473 + +Philippe, is this fixed with your piix improvenents? Thanks, A. @philmd + +As this is an ACPI bug, adding the acpi tag. + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg06080.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. + + +Bug has been moved to the new issue tracker here: +https://gitlab.com/qemu-project/qemu/-/issues/221 + diff --git a/results/classifier/108/other/1836 b/results/classifier/108/other/1836 new file mode 100644 index 00000000..3c0aa5b2 --- /dev/null +++ b/results/classifier/108/other/1836 @@ -0,0 +1,16 @@ +other: 0.914 +device: 0.646 +performance: 0.554 +graphic: 0.447 +boot: 0.441 +semantic: 0.398 +network: 0.226 +permissions: 0.218 +debug: 0.145 +vnc: 0.132 +socket: 0.089 +files: 0.054 +PID: 0.011 +KVM: 0.005 + +AIX no longer boots diff --git a/results/classifier/108/other/1836078 b/results/classifier/108/other/1836078 new file mode 100644 index 00000000..a5ec2ed4 --- /dev/null +++ b/results/classifier/108/other/1836078 @@ -0,0 +1,252 @@ +permissions: 0.900 +other: 0.860 +semantic: 0.835 +graphic: 0.815 +debug: 0.787 +device: 0.784 +performance: 0.783 +PID: 0.757 +socket: 0.712 +network: 0.678 +vnc: 0.672 +boot: 0.663 +files: 0.645 +KVM: 0.626 + +Regressions on arm-linux-gnueabihf 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. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabihf +--with-cpu cortex-a57 +--with-fpu crypto-neon-fp-armv8 + +Thanks + + + +I bisected the failure for all but the IEEE6 test to: + +commit 602f6e42cfbfe9278be34e9b91d2ceb695837e02 +Author: Peter Maydell <email address hidden> +Date: Thu Feb 28 10:55:16 2019 +0000 + + target/arm: Use MVFR1 feature bits to gate A32/T32 FP16 instructions + + Instead of gating the A32/T32 FP16 conversion instructions on + the ARM_FEATURE_VFP_FP16 flag, switch to our new approach of + looking at ID register bits. In this case MVFR1 fields FPHP + and SIMDHP indicate the presence of these insns. + + This change doesn't alter behaviour for any of our CPUs. + + Signed-off-by: Peter Maydell <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + + +The IEEE6 test comes down to: + +commit a15945d98d3a3390c3da344d1b47218e91e49d8b +Author: Peter Maydell <email address hidden> +Date: Tue Feb 5 16:52:42 2019 +0000 + + target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI + + The {IOE, DZE, OFE, UFE, IXE, IDE} bits in the FPSCR/FPCR are for + enabling trapped IEEE floating point exceptions (where IEEE exception + conditions cause a CPU exception rather than updating the FPSR status + bits). QEMU doesn't implement this (and nor does the hardware we're + modelling), but for implementations which don't implement trapped + exception handling these control bits are supposed to be RAZ/WI. + This allows guest code to test for whether the feature is present + by trying to write to the bit and checking whether it sticks. + + QEMU is incorrectly making these bits read as written. Make them + RAZ/WI as the architecture requires. + + In particular this was causing problems for the NetBSD automatic + test suite. + + Reported-by: Martin Husemann <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + + + +In the ieee6 test case it is attempting to write OFE, bit [10] which: + + This bit is RW only if the implementation supports the trapping of floating-point exceptions. In an implementation that does not support floating-point exception trapping, this bit is RAZ/WI. + + When this bit is RW, it applies only to floating-point operations. Advanced SIMD operations always use untrapped floating-point exception handling in AArch32 state + +This might be a broken test. + +When we converted to using feature bits in 602f6e42cfbf we missed out +the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +-cpu max configurations. This caused a regression in the GCC test +suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +Signed-off-by: Alex Bennée <email address hidden> +--- + target/arm/cpu.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/target/arm/cpu.c b/target/arm/cpu.c +index e75a64a25a..0a0a202fe3 100644 +--- a/target/arm/cpu.c ++++ b/target/arm/cpu.c +@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) + t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); + cpu->isar.id_isar6 = t; + ++ t = cpu->isar.mvfr1; ++ t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.2 FP16 */ ++ cpu->isar.mvfr1 = t; ++ + t = cpu->isar.mvfr2; + t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */ + t = FIELD_DP32(t, MVFR2, FPMISC, 4); /* FP MaxNum */ +-- +2.20.1 + + + + +Richard Henderson <email address hidden> writes: + +> On 7/10/19 7:24 PM, Alex Bennée wrote: +>> When we converted to using feature bits in 602f6e42cfbf we missed out +>> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +>> -cpu max configurations. This caused a regression in the GCC test +>> suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP. +>> +>> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> target/arm/cpu.c | 4 ++++ +>> 1 file changed, 4 insertions(+) +>> +>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c +>> index e75a64a25a..0a0a202fe3 100644 +>> --- a/target/arm/cpu.c +>> +++ b/target/arm/cpu.c +>> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) +>> t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); +>> cpu->isar.id_isar6 = t; +>> +>> + t = cpu->isar.mvfr1; +>> + t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.2 FP16 */ +> +> The comment is wrong. This is not full v8.2 FP16 support (which would be value +> 3, plus a change to SIMDHP), but v8.0 support for double<->half +> conversions. + +Good catch - will fix in v2. +> +> Otherwise, +> Reviewed-by: Richard Henderson <email address hidden> +> +> +> r~ + + +-- +Alex Bennée + + +When we converted to using feature bits in 602f6e42cfbf we missed out +the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +-cpu max configurations. This caused a regression in the GCC test +suite. Fix this by setting the appropriate bits in mvfr1.FPHP to +report ARMv8-A with FP support (but not ARMv8.2-FP16). + +Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +--- + target/arm/cpu.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/target/arm/cpu.c b/target/arm/cpu.c +index e75a64a25a..ad164a773b 100644 +--- a/target/arm/cpu.c ++++ b/target/arm/cpu.c +@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) + t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); + cpu->isar.id_isar6 = t; + ++ t = cpu->isar.mvfr1; ++ t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.0 FP support */ ++ cpu->isar.mvfr1 = t; ++ + t = cpu->isar.mvfr2; + t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */ + t = FIELD_DP32(t, MVFR2, FPMISC, 4); /* FP MaxNum */ +-- +2.20.1 + + + +On Thu, 11 Jul 2019 at 11:37, Alex Bennée <email address hidden> wrote: +> +> When we converted to using feature bits in 602f6e42cfbf we missed out +> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +> -cpu max configurations. This caused a regression in the GCC test +> suite. Fix this by setting the appropriate bits in mvfr1.FPHP to +> report ARMv8-A with FP support (but not ARMv8.2-FP16). +> +> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +> Signed-off-by: Alex Bennée <email address hidden> +> Reviewed-by: Richard Henderson <email address hidden> +> --- +> target/arm/cpu.c | 4 ++++ +> 1 file changed, 4 insertions(+) +> +> diff --git a/target/arm/cpu.c b/target/arm/cpu.c +> index e75a64a25a..ad164a773b 100644 +> --- a/target/arm/cpu.c +> +++ b/target/arm/cpu.c +> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) +> t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); +> cpu->isar.id_isar6 = t; +> +> + t = cpu->isar.mvfr1; +> + t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.0 FP support */ +> + cpu->isar.mvfr1 = t; +> + +> t = cpu->isar.mvfr2; +> t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */ +> t = FIELD_DP32(t, MVFR2, FPMISC, 4); /* FP MaxNum */ +> -- +> 2.20.1 + + + +Applied to target-arm.next, thanks. + +-- PMM + + +I confirm this patch fixes the problem I reported. +Thanks! + +I think the ieee6 test is due to a broken runtime: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=45b1a243b81a7c9ae562 + diff --git a/results/classifier/108/other/1836136 b/results/classifier/108/other/1836136 new file mode 100644 index 00000000..5e92608c --- /dev/null +++ b/results/classifier/108/other/1836136 @@ -0,0 +1,27 @@ +boot: 0.751 +device: 0.646 +graphic: 0.590 +semantic: 0.424 +other: 0.345 +socket: 0.293 +files: 0.201 +PID: 0.153 +permissions: 0.112 +network: 0.099 +debug: 0.091 +vnc: 0.082 +performance: 0.055 +KVM: 0.010 + +u-boot: any plans to update u-boot to v2019.07 + +Just want to pulse about the plan to update u-boot binary to latest v2019.07. + +Are there any notable bugfixes or new features that this would get us for the two platforms where we ship a u-boot binary ? + + +[Expired for QEMU because there has been no activity for 60 days.] + +As it happens, in April 2021 commit 335b6389374a53e0 bumped our u-boot rom to v2021.04 to fix a PCI issue. + + diff --git a/results/classifier/108/other/1836192 b/results/classifier/108/other/1836192 new file mode 100644 index 00000000..fd92f9f4 --- /dev/null +++ b/results/classifier/108/other/1836192 @@ -0,0 +1,50 @@ +other: 0.793 +device: 0.784 +debug: 0.773 +performance: 0.771 +files: 0.763 +PID: 0.734 +boot: 0.695 +semantic: 0.685 +network: 0.682 +permissions: 0.651 +vnc: 0.638 +graphic: 0.634 +socket: 0.593 +KVM: 0.524 + +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/108/other/1836430 b/results/classifier/108/other/1836430 new file mode 100644 index 00000000..2f7879cb --- /dev/null +++ b/results/classifier/108/other/1836430 @@ -0,0 +1,32 @@ +graphic: 0.770 +device: 0.520 +performance: 0.508 +semantic: 0.475 +socket: 0.321 +vnc: 0.313 +network: 0.286 +files: 0.284 +other: 0.281 +permissions: 0.224 +PID: 0.216 +KVM: 0.191 +boot: 0.189 +debug: 0.161 + +Can't install on Windows 10 + +Latest release (20190712) 64-bit doesn't install: + +The setup seems to work fine at first and actually extract all the files needed for qemu in the correct location, but after it has done that, it proceeds to delete every file and leaves no trace of qemu except the installation folder. +The setup then finishes and notifies the user that it has been installed succesfully. + +I downloaded the previous release and it installs correctly. + +I just ran the installer from: + + https://qemu.weilnetz.de/w64/qemu-w64-setup-20190713.exe + +on a Win10 VM and it successfully installed and I checked for the files in Program Files and they were all there. Can you re-test with the latest installer please? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1836451 b/results/classifier/108/other/1836451 new file mode 100644 index 00000000..b87d833b --- /dev/null +++ b/results/classifier/108/other/1836451 @@ -0,0 +1,38 @@ +device: 0.891 +graphic: 0.700 +PID: 0.665 +network: 0.600 +socket: 0.581 +other: 0.539 +semantic: 0.498 +files: 0.479 +vnc: 0.462 +boot: 0.419 +performance: 0.388 +debug: 0.362 +permissions: 0.306 +KVM: 0.260 + +'make info' fails due to errors in qemu-tech.texi + +git tag: v4.1.0-rc0 +host: Fedora 29, x86_64 + +$ make info +make[1]: Entering directory 'qemu/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory 'qemu/slirp' + GEN docs/version.texi + GEN qemu-options.texi + GEN qemu-monitor.texi + GEN qemu-img-cmds.texi + GEN qemu-monitor-info.texi + GEN qemu-doc.info +qemu/qemu-tech.texi:6: @menu reference to nonexistent node `Translator Internals' +qemu/qemu-tech.texi:7: @menu reference to nonexistent node `QEMU compared to other emulators' +qemu/qemu-tech.texi:9: @menu reference to nonexistent node `Bibliography' +Makefile:960: recipe for target 'qemu-doc.info' failed +make: *** [qemu-doc.info] Error 1 + +Fixed by commit 32481687e1a262. + diff --git a/results/classifier/108/other/1836501 b/results/classifier/108/other/1836501 new file mode 100644 index 00000000..04eba70e --- /dev/null +++ b/results/classifier/108/other/1836501 @@ -0,0 +1,141 @@ +semantic: 0.949 +other: 0.945 +graphic: 0.923 +permissions: 0.912 +debug: 0.891 +performance: 0.890 +device: 0.888 +PID: 0.826 +boot: 0.819 +files: 0.769 +socket: 0.717 +KVM: 0.695 +network: 0.631 +vnc: 0.619 + +cpu_address_space_init fails with assertion + +qemu-system-arm does not start with version >= 2.6 and KVM enabled. + + cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' failed. + +Hardware is Odroid XU4 with Exynos with 4.9.61+ Tested with Debian Stretch (9) or Buster (10). + +Without KVM it is running fine but slow. I'm operating Debian Jessie with qemu 2.1 for a long time with KVM virtualization working flawlessly. When I upgraded to Stretch I ran into the trouble described before. I tried Debian Stretch and Buster with all Kernels provided by the Board manufacturer (Hardkernel). + +It seems to be related to the feature introduced in Version 2.6: +https://wiki.qemu.org/ChangeLog/2.6 +- Support for a separate EL3 address space + +KVM is enabled, so I assume the adress space index asidx to be causing the assert to fail. + +dmesg | grep -i KVM +[ 0.741714] kvm [1]: 8-bit VMID +[ 0.741721] kvm [1]: IDMAP page: 40201000 +[ 0.741729] kvm [1]: HYP VA range: c0000000:ffffffff +[ 0.742543] kvm [1]: Hyp mode initialized successfully +[ 0.742600] kvm [1]: vgic-v2@10484000 +[ 0.742924] kvm [1]: vgic interrupt IRQ16 +[ 0.742943] kvm [1]: virtual timer IRQ60 + +Full command line is: +qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -cpu host -enable-kvm -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic + +Is there anything to do to understand, if this is a hardware related failure or probably just a missing parameter? + +Regards + +Lutz + +2.6 is now very old -- can you check whether this is still a problem with a more recent QEMU version, please? + +The command line you're using should in theory work, but vexpress-a15 + KVM is a bit of an obscure combination -- most people who want to use virtualization use the 'virt' machine, which supports more RAM and has PCI, unlike the vexpress-a15 board. So it's possible we broke it by accident and didn't notice. + + +Oh, I've just noticed -- we default to enabling EL3 on this board (like the hardware), which won't work with KVM, so if you want KVM you need to disable EL3 with the command line option -machine secure=off + + +We do check for the incompatible option combination in hw/arm/virt.c: + if (vms->secure) { + if (kvm_enabled()) { + error_report("mach-virt: KVM does not support Security extensions"); + exit(1); + } + +we just don't have anything equivalent in vexpress.c. We should probably put something in target/arm/cpu.c so we don't have to modify every board. + + +Thank you for the quick and complete investigation. I'll follow your suggestions and will reply any succecss in the next days. I checked the source of the vexpress and found the assert, but wasn't clever enough to compare it to another board. + +I would support the idea of checking the incompatible parameter pairing in common code. + +I've now tested this with both current head-of-git and with the Debian stretch 2.8.1 qemu-system-arm and I can't reproduce this. We automatically don't enable the EL3 feature if we're using KVM, so a guest runs and sees a non-secure only CPU, without needing to manually add -machine secure=off to the command line. Perhaps we fixed it between 2.6 and 2.8 ? + + +My test setup is now Debian Buster with qemu-system-arm 3.1 and a host with KVM-enabled Kernel 4.9.61 on Odroid XU4. + +Following results: +-------- +qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic -enable-kvm + +Still not working as above, so it doesn't seem to be fixed for 3.1. +-------- +qemu-system-arm -M vexpress-a15,secure=off -smp 2 -m 512 -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic -enable-kvm + +No errors but no output at all, can switch to qemu monitor, but don't know if system is running +-------- +Option 1 and Option 2 both start the Debian installer as expected WITHOUT the parameter -enable-kvm + + +I did also tests with the virt board as recommended. With the parameter -enable-kvm none of the different virt-* boards did output anything to the console, without KVM the virt-boards did start. + +virt-2.6 and virt-2.7 did boot into the installer without KVM. + +Any more recent version (2.8, 2.9, 2.10, 3.0 and 3.1) returned + +"Unable to handle kernel paging request at virtual address 0109ed30" (address is changing) + +during the init process. With different guest memory sizes the paging error occurred at a different init step. + +Conclusion: +1) EL3 feature does still seem to be enabled in qemu 3.1 (Debian) even for KVM-enabled guests. +2) Any recommendation for a support forum to discuss my trouble with the missing console output when enabling KVM and the paging problems with the recent virt boards outside this bug report? + +UPDATE: Kernel page handling seems to be related to the -smp 2 parameter. Any number > 1 leads to the paging error while omitting the parameter lead to a running system (without KVM). + +I can boot a KVM guest (either with the debian stretch qemu-system-arm 2.8.1, or with a head-of-upstream-git QEMU), which wouldn't work with EL3 enabled, so I'm not sure what is going wrong for you. To try to debug this further you'd need to build QEMU from source and start running it under the debugger to see what exactly is going on and why it's hitting that assertion. + +I would be tempted to try a newer kernel to see if that helped. (My working setup is using the debian stretch stock "4.9.0-0.bpo.9-armmp-lpae #1 SMP Debian 4.9.168-1+deb9u3~deb8u1 (2019-06-17)", but in general 4.9 is fairly elderly now.) + +For forums to talk about this kind of thing you might also try the qemu-arm mailing list (https://lists.nongnu.org/mailman/listinfo/qemu-arm) or qemu-devel itself (generally best to cc qemu-devel on qemu-arm emails anyway, lots of people don't subscribe to the per-architecture lists). + + +I'm marking this bug 'incomplete' since as in comment #8 I was unable to reproduce, and I'm no longer sure how the assert could be being hit. If you can provide repro instructions and images that work on current head-of-git I can investigate. + + +[Expired for QEMU because there has been no activity for 60 days.] + +I am having a similar problem. I want to use KVM on jetson nano and boot Raspbian Buster 32bit OS with native machine emulation. + +Run into a similar problem. I used latest QEMU. + + +When I use gdb i see that the assert line uses: + + /* KVM cannot currently support multiple address spaces. */ + assert(asidx == 0 || !kvm_enabled()); + +the asidx is 1. So since KVM is not supporting multiple addresses spaces that the Raspi3 requires the assertion occurs. + +I wonder what the workaround could be for this + + + + +> I want to use KVM on jetson nano and boot Raspbian Buster 32bit OS with native machine emulation. + +The raspi machine doesn't support KVM. You can choose either (1) boot on a board model which does support KVM, which basically means "virt", or (2) use emulation, not KVM. + +If all you care about is running a fairly generic Linux userspace then option 1 will probably be good enough. + + diff --git a/results/classifier/108/other/1836537 b/results/classifier/108/other/1836537 new file mode 100644 index 00000000..f6ec1c00 --- /dev/null +++ b/results/classifier/108/other/1836537 @@ -0,0 +1,29 @@ +other: 0.917 +device: 0.874 +network: 0.776 +graphic: 0.708 +socket: 0.650 +semantic: 0.622 +boot: 0.614 +vnc: 0.608 +performance: 0.552 +permissions: 0.517 +KVM: 0.475 +PID: 0.472 +files: 0.369 +debug: 0.361 + +Kconfig-related options not shown in ./configure --help + +tag: v4.1.0-rc0 + +I notice these options not documented by '--help': + + --with-default-devices) default_devices="yes" + --without-default-devices) default_devices="no" + +We might have other options not documented too. + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/c035c8d6f54 + diff --git a/results/classifier/108/other/1836762 b/results/classifier/108/other/1836762 new file mode 100644 index 00000000..66567d3b --- /dev/null +++ b/results/classifier/108/other/1836762 @@ -0,0 +1,166 @@ +graphic: 0.808 +KVM: 0.753 +other: 0.744 +permissions: 0.693 +vnc: 0.693 +device: 0.679 +debug: 0.606 +PID: 0.600 +performance: 0.577 +files: 0.574 +socket: 0.571 +boot: 0.535 +semantic: 0.505 +network: 0.440 + +Many leaks from qemu_spice_create_update + +tag: v4.1.0-rc0 + +Compiled with --enable-sanitizers + +$ qemu-system-x86_64 -device qxl-vga ... +[guest exits calling 'hlt'] +==20452==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 167616 byte(s) in 582 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Direct leak of 5184 byte(s) in 18 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Direct leak of 2560 byte(s) in 4 object(s) allocated from: + #0 0x561146f2cb46 in realloc (x86_64-softmmu/qemu-system-x86_64+0x1824b46) + #1 0x7f73ac04c420 (/lib64/libfontconfig.so.1+0x21420) + +Direct leak of 22 byte(s) in 1 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73ae781953 in XGetAtomName (/lib64/libX11.so.6+0x2a953) + +Indirect leak of 54936 byte(s) in 510 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5) + #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 30720 byte(s) in 23 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5) + #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 8288 byte(s) in 259 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73ac0385af (/lib64/libfontconfig.so.1+0xd5af) + +Indirect leak of 4068 byte(s) in 303 object(s) allocated from: + #0 0x561146e78f40 in __interceptor_strdup (x86_64-softmmu/qemu-system-x86_64+0x1770f40) + #1 0x7f73ac04bc44 in FcValueSave (/lib64/libfontconfig.so.1+0x20c44) + +Indirect leak of 2336 byte(s) in 73 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73ac04c9cc (/lib64/libfontconfig.so.1+0x219cc) + +Indirect leak of 1536 byte(s) in 48 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73ac04bf0c (/lib64/libfontconfig.so.1+0x20f0c) + +Indirect leak of 1440 byte(s) in 5 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 1440 byte(s) in 5 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 384 byte(s) in 12 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73ac04bd9e (/lib64/libfontconfig.so.1+0x20d9e) + +Indirect leak of 96 byte(s) in 2 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73ac045e51 in FcLangSetCreate (/lib64/libfontconfig.so.1+0x1ae51) + +SUMMARY: AddressSanitizer: 280628 byte(s) leaked in 1847 allocation(s). + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/231 + + diff --git a/results/classifier/108/other/1837049 b/results/classifier/108/other/1837049 new file mode 100644 index 00000000..a8498ded --- /dev/null +++ b/results/classifier/108/other/1837049 @@ -0,0 +1,199 @@ +device: 0.865 +other: 0.853 +debug: 0.846 +performance: 0.839 +graphic: 0.839 +permissions: 0.826 +socket: 0.822 +PID: 0.812 +semantic: 0.808 +boot: 0.794 +files: 0.791 +network: 0.781 +vnc: 0.773 +KVM: 0.761 + +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/108/other/1837094 b/results/classifier/108/other/1837094 new file mode 100644 index 00000000..741c981b --- /dev/null +++ b/results/classifier/108/other/1837094 @@ -0,0 +1,48 @@ +device: 0.780 +network: 0.733 +semantic: 0.679 +graphic: 0.677 +socket: 0.620 +PID: 0.620 +debug: 0.553 +files: 0.544 +other: 0.543 +permissions: 0.542 +vnc: 0.531 +KVM: 0.530 +boot: 0.492 +performance: 0.380 + +UndefinedBehaviorSanitizer crash around slirp::ip_reass() + +tag: v4.1.0-rc1 + +./configure --enable-sanitizers --extra-cflags=-O1 + +==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000008 (pc 0x00000046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130) +==26130==The signal is caused by a WRITE memory access. +==26130==Hint: address points to the zero page. + #0 0x0000561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55 + #1 0x0000561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9 + #2 0x0000561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18 + +I only had access to the last packet which isn't the culprit, I'm now seeing how to log the network traffic of the guest to provide more useful information. + +Recent libslirp patch 126c04ac (explained in e0be8043) changed ip_reass(), so this bug might be fixed. + +https://gitlab.freedesktop.org/slirp/libslirp/commit/126c04ac +https://gitlab.freedesktop.org/slirp/libslirp/commit/e0be8043 + +And + +https://gitlab.freedesktop.org/slirp/libslirp/commit/d203c81b + +I apologize for not understanding this bug was a security issue, and not insisting on it. + +It has been fixed in SLiRP by "Fix use-afte-free in ip_reass() (CVE-2020-1983)": +https://gitlab.freedesktop.org/slirp/libslirp/commit/9bd6c591 + +And in QEMU by commit 7769c23774 "slirp: update to fix CVE-2020-1983". + +Fixed in QEMU release v5.0.0 + diff --git a/results/classifier/108/other/1837218 b/results/classifier/108/other/1837218 new file mode 100644 index 00000000..461fb0c5 --- /dev/null +++ b/results/classifier/108/other/1837218 @@ -0,0 +1,56 @@ +other: 0.852 +semantic: 0.833 +graphic: 0.733 +device: 0.729 +performance: 0.714 +debug: 0.711 +permissions: 0.661 +PID: 0.661 +KVM: 0.651 +vnc: 0.605 +network: 0.573 +boot: 0.567 +socket: 0.523 +files: 0.486 + +qemu segfaults after spice update with bochs-display + +Description: + +qemu segfaults after latest spice update with bochs-display. Downgrading spice solves the issue. Switching to qxl-vga and/or virtio-gpu also works even with new spice. + +Additional info: +* package version(s) + +spice 0.14.2-1 +qemu-headless 4.0.0-3 + +* config and/or log files etc. + +pf@defiant:~ » /mnt/vms/02-archlinux/start.sh +/mnt/vms/02-archlinux/start.sh: line 41: 13501 Segmentation fault (core dumped) qemu-system-x86_64 -name "${NAME}" -display none -spice ipv4,addr=127.0.0.1,port=270${ID},disable-ticketing,disable-copy-paste,disable-agent-file-xfer,agent-mouse=off -serial mon:telnet:127.0.0.1:280${ID},server,nowait,nodelay -gdb tcp::260${ID} -nodefaults -machine q35,accel=kvm -cpu max -smp cores=${CPU},threads=1,sockets=1 -m ${MEM} -drive if=pflash,format=raw,readonly,file="${BIOS}" -drive if=pflash,format=raw,file="${VARS}" -device virtio-rng -device bochs-display -device virtio-keyboard -netdev bridge,id=bridge.0,br=vm0 -device virtio-net,mac=${_MAC}:01,netdev=bridge.0,mq=on,vectors=${_VECTORS} -fsdev local,id="${NAME}",path="${SHARED}",security_model=mapped,writeout=immediate -device virtio-9p-pci,fsdev="${NAME}",mount_tag="shared" -device virtio-scsi,id=scsi,num_queues=${CPU},vectors=${_VECTORS} -device scsi-hd,drive=hd1 -drive if=none,media=disk,id=hd1,file="${DISK1}",format=raw,cache=directsync,discard=unmap,detect-zeroes=unmap -device scsi-hd,drive=hd2 -drive if=none,media=disk,id=hd2,file="${DISK2}",format=raw,cache=directsync,discard=unmap,detect-zeroes=unmap -device scsi-cd,drive=cd1 -drive if=none,media=cdrom,id=cd1,file="${CDROM1}",format=raw,cache=directsync + +Steps to reproduce: + +Update spice, launch a VM like the above and observe a segfault. + +Arc Linux report: https://bugs.archlinux.org/task/63229 + +I've built qemu v4.1.0-rc1 with debug symbols, but got no luck in reproducing this. + +I've also built qemu v4.0.0 with debug info, and the issue is not reproducible with such a build. + +Stack trace w/o debug symbols: + +#0 0x000055b7d9f96a49 address_space_dispatch_free (qemu-system-x86_64) +#1 0x000055b7d9ff1169 n/a (qemu-system-x86_64) +#2 0x000055b7da40126c n/a (qemu-system-x86_64) +#3 0x000055b7da3ef121 n/a (qemu-system-x86_64) +#4 0x00007f257e69e57f start_thread (libpthread.so.0) +#5 0x00007f257e5ce0e3 __clone (libc.so.6) + +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 issue is not experienced any more. + diff --git a/results/classifier/108/other/1837347 b/results/classifier/108/other/1837347 new file mode 100644 index 00000000..79486a3e --- /dev/null +++ b/results/classifier/108/other/1837347 @@ -0,0 +1,65 @@ +other: 0.875 +permissions: 0.767 +files: 0.735 +boot: 0.700 +device: 0.697 +performance: 0.689 +graphic: 0.678 +semantic: 0.643 +network: 0.628 +PID: 0.588 +socket: 0.567 +vnc: 0.483 +debug: 0.467 +KVM: 0.402 + +guest userspace process core dump after raspi2 kernel boot + +Host info: +========== +x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site) + +Guest info: +=========== +ARM7l, Raspbian OS off the main raspberry pi site + +QEMU command: +============= +qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb bootpart/bcm2709-rpi-2-b.dtb -drive file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio + +kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following commands: + +guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1 +><fs> copy-out / bootpart/ +><fs> quit + +Output: +======= + +https://pastebin.com/fL1eXhV0 + +References: +=========== +https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ +https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/ + + +The core dump error can occur at both times, before logging in and after logging in, in this case I have given the output after logging in to show the initial processes running. + +Also please let me know if I using any kernel flags incorrectly + +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/108/other/1837851 b/results/classifier/108/other/1837851 new file mode 100644 index 00000000..4bedd46f --- /dev/null +++ b/results/classifier/108/other/1837851 @@ -0,0 +1,42 @@ +device: 0.754 +other: 0.752 +KVM: 0.743 +performance: 0.710 +graphic: 0.691 +semantic: 0.603 +files: 0.572 +network: 0.537 +permissions: 0.505 +socket: 0.503 +debug: 0.468 +boot: 0.466 +vnc: 0.453 +PID: 0.446 + +hv-tlbflush malfunctions on Intel host CPUs with neither EPT nor VPID (qemu-kvm) + +Enabling hv-tlbflush on older hosts using Intel CPUs supporting VT-x but neither EPT nor VPID will lead to bluescreens on the guest. + +It seems KVM only checks if EPT is available, and if it isn't it forcibly uses VPID. If that's *also* not available, it defaults to basically a no-op hypercall, though windows is expecting the TLB to be flushed. + +hv-tlbflush is pretty useless on machines not supporting these extensions anyway (only reasonably fix I can see would be to flush the *entire* TLB on tlbflush hypercall in KVM (i.e. a kernel fix), but that would remove any performance benefits), so I would suggest some kind of preliminary check and warning/error if hv-tlbflush is specified on such a host. + +All CPUs mentioned in this thread[0] are confirmed to be affected by the bug, and I have successfully reproduced it on an Intel Core2Duo E8500. + +[0] https://forum.proxmox.com/threads/windows-guest-bluescreen-with-proxmox-6.56053/ + +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/108/other/1837909 b/results/classifier/108/other/1837909 new file mode 100644 index 00000000..25c32113 --- /dev/null +++ b/results/classifier/108/other/1837909 @@ -0,0 +1,145 @@ +other: 0.937 +debug: 0.933 +semantic: 0.922 +graphic: 0.914 +network: 0.907 +performance: 0.903 +permissions: 0.895 +device: 0.886 +PID: 0.864 +boot: 0.849 +socket: 0.849 +vnc: 0.838 +files: 0.828 +KVM: 0.824 + +test-char fails if host has no network interfaces + +# ./tests/test-char +# random seed: R02S8602535bf831a74bca571d8c416d8161 +1..34 +# Start of char tests +... +ok 12 /char/websocket +# Start of stdio tests +# End of stdio tests +# Start of socket tests +# Start of server tests +# Start of mainloop tests +Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: +# +# address resolution failed for 127.0.0.1:42275: Name or service not known +# + +Aborted (core dumped) + + +# ip a +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever + + +This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available + +This host setup may seem niche, but it is what the 'mock' RPM build tool has by default. In Fedora we run the test suite during the RPM build, so the failing test causes a bit of pain for certain workflows + +This should be addressed by: https://<email address hidden>/ + +On 7/25/19 4:20 PM, Cole Robinson wrote: +> Public bug reported: +> +> # ./tests/test-char +> # random seed: R02S8602535bf831a74bca571d8c416d8161 +> 1..34 +> # Start of char tests +> ... +> ok 12 /char/websocket +> # Start of stdio tests +> # End of stdio tests +> # Start of socket tests +> # Start of server tests +> # Start of mainloop tests +> Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: +> # +> # address resolution failed for 127.0.0.1:42275: Name or service not known +> # +> +> Aborted (core dumped) +> +> +> # ip a +> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 +> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 +> inet 127.0.0.1/8 scope host lo +> valid_lft forever preferred_lft forever +> inet6 ::1/128 scope host +> valid_lft forever preferred_lft forever +> +> +> This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available + +GETADDRINFO(3) + + If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 + addresses are returned in the list pointed to by res only if + the local system has at least one IPv4 address configured, and + IPv6 addresses are returned only if the local system has at + least one IPv6 address configured. The loopback address is not + considered for this case as valid as a configured address. + This flag is useful on, for example, IPv4-only systems, to + ensure that getaddrinfo() does not return IPv6 socket addresses + that would always fail in connect(2) or bind(2). + +I'm a little confused, and I don't feel fluent enough with English to be +sure that "only if A and only if B" is equivalent to "requires (A or +B)". Maybe the man page should use 'or' instead of 'and' here... + +> This host setup may seem niche, but it is what the 'mock' RPM build tool +> has by default. In Fedora we run the test suite during the RPM build, so +> the failing test causes a bit of pain for certain workflows + +Would this diff snippet help? + +-- >8 -- +diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c +index a5092dbd12..9ad775270d 100644 +--- a/util/qemu-sockets.c ++++ b/util/qemu-sockets.c +@@ -417,7 +417,7 @@ static struct addrinfo +*inet_parse_connect_saddr(InetSocketAddress *saddr, + ai.ai_flags &= ~AI_V4MAPPED; + rc = getaddrinfo(saddr->host, saddr->port, &ai, &res); + } +- if (rc != 0) { ++ if (rc and rc != EAI_NONAME) { + error_setg(errp, "address resolution failed for %s:%s: %s", + saddr->host, saddr->port, gai_strerror(rc)); + return NULL; +--- + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + +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/108/other/1838 b/results/classifier/108/other/1838 new file mode 100644 index 00000000..19be0fc8 --- /dev/null +++ b/results/classifier/108/other/1838 @@ -0,0 +1,16 @@ +device: 0.766 +performance: 0.578 +network: 0.341 +graphic: 0.263 +permissions: 0.232 +semantic: 0.189 +debug: 0.164 +socket: 0.141 +boot: 0.103 +files: 0.082 +other: 0.047 +vnc: 0.039 +PID: 0.027 +KVM: 0.005 + +Win9x on qemu 8.0.3 - Impossible to launch a win32 app diff --git a/results/classifier/108/other/1838066 b/results/classifier/108/other/1838066 new file mode 100644 index 00000000..b4f842e5 --- /dev/null +++ b/results/classifier/108/other/1838066 @@ -0,0 +1,83 @@ +debug: 0.877 +PID: 0.839 +graphic: 0.834 +socket: 0.817 +permissions: 0.806 +network: 0.773 +other: 0.770 +performance: 0.768 +device: 0.760 +semantic: 0.756 +vnc: 0.712 +boot: 0.679 +files: 0.661 +KVM: 0.641 + +unexpected error: raw_reconfigure_getfd(): qemu-system-x86_64: Could not reopen file + + Unexpected error in raw_reconfigure_getfd() at block/file-posix.c:923: + qemu-system-x86_64: Could not reopen file: Permission denied + Aborted + +Is what i sometimes (only) get, mostly for Linux guests i'd say (Arch just a few moments ago). +This is on CRUX-Linux, thus a self-compiled qemu 4.0.0 with default recipe, without special compiler flags (-O2 -march=x86-64 -pipe) on an Intel i5 laptop. +But what i do is running this via sudo: + + sudo='sudo --preserve-env=VMNAME,VMADDR' runas='-runas vm -chroot .' + fi + + VMADDR=$addr VMNAME=$vmname + export VMADDR VMNAME + eval exec $sudo qemu-system-x86_64 -name $vmname $runas \ + $host $accel $display $net $vmcustom $vmimg $redir + +the last run ends up like (via sudo) + + qemu-system-x86_64 -name arch-2019 -runas vm -chroot . -cpu host -m size=1984 -smp cpus=2 -enable-kvm -accel accel=kvm,thread=multi -display curses -net nic,netdev=net0,macaddr=.. -netdev tap,id=net0,script=./.ifup.sh,downscript=./.ifdown.sh,ifname=vm_arch-2019 + +vm is a user effectively living in the chroot only without any rights anywhere. +Hope this helps, thanks a lot for qemu!! + +Hi, + +Can you retry with any 4.1 release candidate (like 4.1.0-rc2)? (Or wait for the 4.1.0 release in hopefully about a week?) The error message sounds like it should be fixed by https://lists.nongnu.org/archive/html/qemu-block/2019-05/msg00775.html . + +Though I have no idea why you would hit that if you didn’t add any block devices. + + +Max + +Hello! + +Max Reitz wrote in <156422889569.6195.8735825632650411110.malone@soybean\ +.canonical.com>: + |Hi, + | + |Can you retry with any 4.1 release candidate (like 4.1.0-rc2)? (Or wait + |for the 4.1.0 release in hopefully about a week?) The error message + |sounds like it should be fixed by https://lists.nongnu.org/archive/html + |/qemu-block/2019-05/msg00775.html . + +Ok? Great news, i will wait until then, it does not really hurt +me (i do not even see it when now setting up a new VM with debug +and thus -display enabled). + +Thanks!! + + |Though I have no idea why you would hit that if you didn’t add any block + |devices. + +Was missing a line in the ps output, i see. +Yeah, sorry. ^_^ +A nice weekend if at all possible i wish! + +--steffen +| +|Der Kragenbaer, The moon bear, +|der holt sich munter he cheerfully and one by one +|einen nach dem anderen runter wa.ks himself off +|(By Robert Gernhardt) + + +Assuming this has been fixed according to Max' comment. If not, please re-open. + diff --git a/results/classifier/108/other/1838277 b/results/classifier/108/other/1838277 new file mode 100644 index 00000000..3c789114 --- /dev/null +++ b/results/classifier/108/other/1838277 @@ -0,0 +1,222 @@ +permissions: 0.669 +other: 0.637 +boot: 0.609 +device: 0.565 +KVM: 0.557 +debug: 0.536 +vnc: 0.531 +network: 0.525 +files: 0.517 +semantic: 0.506 +performance: 0.500 +PID: 0.477 +graphic: 0.436 +socket: 0.418 + +qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher + +Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). + +With the following code and shell commands: + +test.s: + +.text +mov x0, #0x60000000 +msr vbar_el2, x0 +dsb sy +isb sy + +$ aarch64-none-elf-as test.s -o test.o +$ aarch64-none-elf-objcopy -S -O binary test.o test.bin +$ qemu-system-aarch64 -nographic -machine virt,virtualization=on -cpu cortex-a57 -kernel test.bin -s -S + +vbar_el2 is still 0 after the code, instead of being the expected 0x60000000. (see screenshot). + +This regression doesn't seem to happen for vbar_el1 & virtualization=off. + + + +Err, my bad. The following code does seem to work fine (somehow?), but the bug in my code is currently being caused by a JIT failure in mov sp, x8 (aligned value), causing a crash (with the same version considerations). + +If you can provide a repro case for that I'll have a look... + +Right, so basically I was working on https://github.com/Atmosphere-NX/Atmosphere/tree/hyp/thermosphere (make PLATFORM=qemu qemudbg). This uses Arm Trusted Firmware. + +While gdb now reports $VBAR_EL2 correctly (as opposed to what the title says), I observed the following effects: + +- at least before I fixed a bug in my exception handlers, I needed to add this JIT workaround I found by accident: https://github.com/Atmosphere-NX/Atmosphere/blob/hyp/thermosphere/src/start.s#L62 to get to main. Otherwise mov sp, x8 (with x8 aligned) crashed for no reason. + +- VBAR_EL2 is/was loaded before msr VBAR_EL2, x8 despite data and instruction barriers + +- From 3.1 onwards (or after 2.11): VBAR_EL2 is correctly reported (p $VBAR_EL2 gives $1 = 0x60001000 as exepected, and the read value of PSTATE is 0x3c5) but **QEMU acts as if VBAR_EL2 was 0** depending on crash site (but still reports it correctly when jumping to 0+0x200) (there's a __builtin_trap() call in function main) + +Attached elf and binary & built Arm TF build. Run flags: -nographic -machine virt,secure=on,virtualization=on,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable,target=native -serial mon:stdio + +For me that test binary seems to work (with a QEMU built from upstream git commit 893dc8300c80e3dc32f3) : at least it boots and prints various messages ending with "Hello from Thermosphere!". + + +If you want me to investigate whatever the issue with 'mov sp, x8' crashing is you'll need to provide a binary that demonstrates that problem, not one with a workaround in it. + + +> For me that test binary seems to work (with a QEMU built from upstream git commit 893dc8300c80e3dc32f3) : at least it boots and prints various messages ending with "Hello from Thermosphere!" + +my bad, I wasn't precise enough. Right now, test binary should display a crash dump (=> exceptions.c) following __builtin_trap() but doesn't. + +Here is what happens: + +Expected behavior: code steps into $VBAR_EL2+0x200, $VBAR_EL2 being reported to be its expected value +Actual behavior: code steps into 0+0x200 + +(gdb) disas +Dump of assembler code for function main: + 0x00000000600000e8 <+0>: ldr w1, [x18, #16] + 0x00000000600000ec <+4>: str x30, [sp, #-16]! + 0x00000000600000f0 <+8>: cbnz w1, 0x60000110 <main+40> + 0x00000000600000f4 <+12>: mov w0, #0xc200 // #49664 + 0x00000000600000f8 <+16>: movk w0, #0x1, lsl #16 + 0x00000000600000fc <+20>: bl 0x60000d10 <uartInit> + 0x0000000060000100 <+24>: adrp x0, 0x60001000 <unknown_exception> + 0x0000000060000104 <+28>: add x0, x0, #0x8be + 0x0000000060000108 <+32>: bl 0x60000128 <serialLog> +=> 0x000000006000010c <+36>: brk #0x3e8 + 0x0000000060000110 <+40>: adrp x0, 0x60001000 <unknown_exception> + 0x0000000060000114 <+44>: add x0, x0, #0x8d8 + 0x0000000060000118 <+48>: bl 0x60000128 <serialLog> + 0x000000006000011c <+52>: mov w0, #0x0 // #0 + 0x0000000060000120 <+56>: ldr x30, [sp], #16 + 0x0000000060000124 <+60>: ret +End of assembler dump. +(gdb) stepi +^C +Thread 1 received signal SIGINT, Interrupt. +0x0000000000000200 in ?? () +(gdb) p $VBAR_EL2 +$10 = 0x60001000 + + +For the x20/mov sp, x8 crash, it happens on the previous commit, 511a9d86cd2de93f3a9956d248e54e46a89eabb9 (build attached). + +Workaround, not in the build, is to comment out start.s:45 (but not line 43). This time it goes into my exception handlers even before I set vbar_el2. + +Only one target "core" is on when the code runs. + +Can you please provide clear and exact reproduction instructions and binaries for whatever the bugs you think you're seeing are? Bear in mind that I know nothing at all about your guest binary or how it is supposed to behave, and I am not going to build versions of your binary from source. If I need to look at things via the gdb interface, give exact sequences of gdb commands I need to use to reproduce the behaviour and say what you were expecting the behaviour to be. + + +Sure. + +* For both: extract the archive in the same folder, chmod to it & run + +qemu-system-aarch64 -nographic -machine virt,secure=on,virtualization=on,gic-version=2 -cpu cortex-a57 -smp 2 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable,target=native -serial mon:stdio -s -S + +* In another terminal window, same folder: + +aarch64-none-elf-gdb thermosphere.elf + +* while in GDB: + +target remote :1234 + +This .elf corresponds to bl33.bin which runs in EL2 (the other binary files are Arm Trusted Firmware). + +=================== + +For https://bugs.launchpad.net/qemu/+bug/1838277/+attachment/5279996/+files/example.zip: + +* in GDB: + +b *0x6000010C + +* GDB should report it placed a breakpoint in main.c, line 11 (this is on a brk instruction). Then: + +continue +disas + +* Here you should see => 0x000000006000010c <+36>: brk #0x3e8 + +* Notice VBAR_EL2 has a valid, non-zero value: + +p $VBAR_EL2 + +* gdb reports: $1 = 0x60001000 + +* Step the instruction, the control-C: + +stepi + +__Expected behavior__: qemu should have jumped to 0x60001000+0x200 +__Actual behavior__: qemu jumps to 0+0x200 + + +==================== + +Erratum: there was an issue in example #2, which was a bug on my part. Above regression still stands + +ie. there's x20 being wrongly used in start.s in some places, meaning #8 can be discarded, but this does not explain the vbar_el2 bug (the repro steps for which are above). + +qemu *did* correctly jump to 0x60001200 (synchronous exception from same EL with vbar_el2=0x60001000) in version 2.11, but not anymore. + +s/pstate is 0x3c5/pstate is whatever | 0x3c9, ie. qemu correctly reports the code is executing as EL2h + +Your example_x20_mov_sp_x8 binary performs an illegal-exception-return because it does an eret from EL2 to EL1 without having set HCR_EL2.RW to 1. That means that the CPU will continue execution from the exception-return "link address" in ELR_EL2 (and remain in EL2). That is 0, because we just loaded it from address +0x1938 in the binary, which is all-zeroes. Attempting to execute from 0x0 in EL2 triggers a prefetch abort which is taken to EL2 at entry point 0x60001200 (which is where we expect to enter given that VBAR_EL2 is 0x60001000 and this is a synchronous exception to the current EL). The earlier "mov sp, x8" seems to have executed as expected and the SP at the 'eret' is 0x60002ff0. + +This seems to me to be correct execution of a buggy guest binary. + +Note that if you are trying to debug this via the gdbstub you may be being misled by a bug in our handling of "single step" -- if you single step an instruction and it causes an exception (eg it is a load from a bad address) then instead of stopping execution at the exception-entry-point, we will execute one instruction at the exception-entry-point and then stop after that. So you get back control in gdb one instruction later than you expect. + + +Thanks for your repro instructions of comment #10. Something weird is indeed going on: the -d int logging reports: + +Taking exception 7 [Breakpoint] +...from EL2 to EL1 +...with ESR 0x3c/0xf20003e8 +...with ELR 0x6000010c +...to EL1 PC 0x200 PSTATE 0x3c5 + +but an exception should *never* get taken from a higher to a lower exception level. I will investigate further. + + +As I said, you should have ignored example_x20_mov_sp_x8 totally -- this was a bug on my end, which I fixed. + +What about https://bugs.launchpad.net/qemu/+bug/1838277/+attachment/5279996/+files/example.zip, the steps for which are in #10? This one does not return from exception, and executes a brk instruction in function main. It is supposed to jump to 0x60001200 but doesn't (does on version 2.11). The instruction following the brk is valid (adrp) & the instruction at 0x60001200 is mrs x18, esr_el2. + +Sorry, didn't saw #14 when I was posting #15. + +Thank you again for your patience. + +This bug is specific to our handling of the 'brk' insn (and other debug exceptions within the guest like singlestep or watchpoints or breakpoints) at EL2, so you can work around it for the moment by avoiding using hardcoded brk insns in your EL2 code. + + +To be precise, as I was doing my own investigation, this only happens when *both* the following hold: + +- a breakpoint instruction is executed in EL2 (as you mentionned). +- ELD is EL1. This does **not** happen **if ELD is EL2**, after setting e.g. MDCR_EL2.TDE to 1. + +As mentionned above, it's a regression in implementing "AArch64 Self-hosted Debug, D2.3 Routing debug exceptions". + +I'm not familiar with QEMU's codebase enough & I haven't tested the code below, but I think: + +raise_exception(env, EXCP_BKPT, syndrome, arm_debug_target_el(env)); + +should be replaced with something along the lines of: + +int debug_el = arm_debug_target_el(env); +int current_el = arm_current_el(env); +raise_exception(env, EXCP_BKPT, syndrome, debug_el >= current_el ? debug_el : current_el); + + +Just sent a patch out for review which I think should fix this: +https://<email address hidden>/ + + +Thanks a lot for the patch! + +Just nitpicking here, but commit message and in particular wiki changelog message (in 4.1/Planning) make it seem it was only an EL2 issue. I think it was also affecting EL3 (patch fixes both, anyway). + +The fix for this is now in git and will be in the 4.1.0 release. + + +Fix included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=987a23224218fa3bb + diff --git a/results/classifier/108/other/1838465 b/results/classifier/108/other/1838465 new file mode 100644 index 00000000..fdf50530 --- /dev/null +++ b/results/classifier/108/other/1838465 @@ -0,0 +1,48 @@ +device: 0.779 +boot: 0.718 +performance: 0.691 +graphic: 0.598 +other: 0.597 +PID: 0.509 +network: 0.474 +socket: 0.471 +files: 0.469 +permissions: 0.455 +debug: 0.407 +vnc: 0.405 +semantic: 0.321 +KVM: 0.184 + +qemu-system-x86_64 kernel panic 30% of the time starting up VM + +I have created a Fedora Core 5 x86_64 VM image. When I run the image using QEMU on Windows the VM hangs while loading the kernel about 30% of the time. I am trying to use this VM with a CI software, looking at the history the build failed 27 out of 79 attempts. QEMU 3.0.0 is installed on the CI machine. I have tried using the exact same image using QEMU on Linux (Ubuntu) and found the image boot successful every time (40+ attempts). The VM image is fairly old it was created using QEMU 0.11.1. + +I have tried multiple versions on QEMU on windows; 0.11.1, 2.12.1, and 3.0.0 all of them fail randomly. I can reproduce the issue on several different Windows 10 computers. + +The command I am using to start the VM is “qemu-system-x86_64.exe -cpu qemu64 -smp cores=2 -device e1000,netdev=net0 -boot menu=off -m 1G -drive `"file=C:\qimages\Fedora-Core-5-x64.qcow2,index=0,media=disk`" -snapshot -netdev user,id=net0,hostfwd=tcp::10022-:22” + +I can provide the qcow image but it is somewhat large coming it at 4.15GB so I’m not sure what would be the best way to transfer it. + + + +Is this using TCG (i.e. emulation) rather than Hyper V virtualisation? + +There are problems reliable booting the VM using TCG, HAXM, and Hyper-V. TCG fails the least often. Attached is a pic of the error using HAXM, a lot of "BUG: soft lockup detect on CPU#x!". + +I tried to add logging but nothing ever shows up in the log file. I tried adding "-d cpu,guest_errors -D E:\log.txt" to the command but the log file is always empty. + +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/108/other/1838475 b/results/classifier/108/other/1838475 new file mode 100644 index 00000000..57e59301 --- /dev/null +++ b/results/classifier/108/other/1838475 @@ -0,0 +1,50 @@ +semantic: 0.780 +device: 0.738 +socket: 0.693 +performance: 0.686 +network: 0.620 +vnc: 0.608 +permissions: 0.603 +other: 0.602 +debug: 0.567 +files: 0.544 +PID: 0.543 +graphic: 0.542 +boot: 0.517 +KVM: 0.343 + +qemu-system-arm exits when cortex-m4 floating point used and irq occurs + +qemu-system-arm exits with + +"...Secure UsageFault with CFSR.NOCP because NSACR.CP10 prevents stacking FP regs +...taking pending nonsecure exception 3 +Taking exception 7 [Breakpoint] +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)" + +when emulating Cortex-m4, executing at least 1 floating point instruction, and then an irq (e.g. sys tick) occurring. + +CPACR.CP10 and CPACR.CP11 are set to 0x3 respectively prior to executing the fp instructions. + +NOTE: NSACR does not appear to be a cortex m4 register. + +Attached is a simplified elf to repro the issue. + +The qemu command line is: "qemu-system-arm --gdb tcp::1234 -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel QemuExitWhenUsingFPAndIRQOccurs.elf -d int" + + + +I think this patch should fix this bug: + +https://<email address hidden>/ + + +I confirm that this fixes the issue above. + +Thank you for your help! It is much appreciated. + +Now fixed in git master; will be in the imminent 4.1 release. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=02ac2f7f613b47f6a5b3 + diff --git a/results/classifier/108/other/1838569 b/results/classifier/108/other/1838569 new file mode 100644 index 00000000..c4c46242 --- /dev/null +++ b/results/classifier/108/other/1838569 @@ -0,0 +1,113 @@ +KVM: 0.691 +performance: 0.628 +device: 0.625 +graphic: 0.602 +vnc: 0.592 +permissions: 0.575 +network: 0.570 +boot: 0.564 +other: 0.532 +files: 0.507 +semantic: 0.478 +PID: 0.465 +socket: 0.451 +debug: 0.428 + +virtio-balloon change breaks post 4.0 upgrade + +We upgraded the libvirt UCA packages from 3.6 to 4.0 as part of a queens upgrade and noticed that +virtio-ballon is broken when instances live migrate (started with a prior 3.6 version) with: + + +2019-07-24T06:46:49.487109Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control +2019-07-24T06:47:22.187749Z qemu-system-x86_64: VQ 2 size 0x80 < last_avail_idx 0xb57 - used_idx 0xb59 +2019-07-24T06:47:22.187768Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2019-07-24T06:47:22.187771Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' +2019-07-24T06:47:22.188194Z qemu-system-x86_64: load of migration failed: Operation not permitted +2019-07-24 06:47:22.430+0000: shutting down, reason=failed + +This seem to be the exact problem as reported by https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02228.html + +Listed the packages which changed: + +Start-Date: 2019-07-06 06:40:55 +Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install libvirt-bin python-libvirt qemu qemu-utils qemu-system qemu-system-arm qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-system-misc qemu-block-extra qemu-utils qemu-user qemu-kvm +Install: librdmacm1:amd64 (17.1-1ubuntu0.1~cloud0, automatic), libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.10~cloud0, automatic), ipxe-qemu-256k-compat-efi-roms:amd64 (1.0.0+git-20150424.a25a16d-0ubuntu2~cloud0, automatic) +Upgrade: qemu-system-mips:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-misc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-ppc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), python-libvirt:amd64 (3.5.0-1build1~cloud0, 4.0.0-1~cloud0), qemu-system-x86:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-clients:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-user:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-bin:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-utils:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon-system:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-sparc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-user-binfmt:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-kvm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt0:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-arm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-block-extra:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-common:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0) +End-Date: 2019-07-06 06:41:08 + +At this point the instances would have to be hard rebooted or stopped/started to fix the issue for future live migration attemps + +Hi Bjoern, + I don't think this is the same bug as the one you reference; that's a config space disagreement, not a virtio queue disagreeement. + +It almost feels like the old 4a1e48becab81020adfb74b22c76a595f2d02a01 stats migration fix; but that went in with 2.8 so shouldn't be a problem going 2.10 to 2.11 + + +In regard to "similar bugs" it sounds more like [1] to me. +Which was around needing [2]. + +But just like the commit David mentioned is in 2.8 this one is in since 2.6 (and backported). + +[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389 +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=4eae2a657d1ff5ada56eb9b4966eae0eff333b0b + +Status changed to 'Confirmed' because the bug affects multiple users. + +With recent release of OpenStack Train this issue reappears... + +Upgrading from Stein to Train will require all VMs to be hard-rebooted to be migrated as a final step because Live Migration fails with: + +Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd[1545]: Unable to read from monitor: Connection reset by peer +Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd[1545]: internal error: qemu unexpectedly closed the monitor: 2019-10-17T10:28:42.981201Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0 + 2019-10-17T10:28:42.981250Z qemu-system-x86_64: Failed to load PCIDevice:config + 2019-10-17T10:28:42.981263Z qemu-system-x86_64: Failed to load virtio-balloon:virtio + 2019-10-17T10:28:42.981272Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' + 2019-10-17T10:28:42.981391Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable + 2019-10-17T10:28:42.983157Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable + 2019-10-17T10:28:42.983672Z qemu-system-x86_64: load of migration failed: Invalid argument + + +Dnaiel: That's a different problem; 'Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0'; so should probably be a separate bug. + +I'd bet on this being the one fixed by 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +> I'd bet on this being the one fixed by +> 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +But wasn't the breakage this fixes only added in qemu 4.0? +He reports his change is from qemu 2.10 to 2.11. + +Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has +something backported that makes the Ubuntu 2.11 being affected by it. +I checked the Delta but there was nothing related backported that I +could identify. + +But I agree, that first of all this should be a new bug instead of +reviving the old one here. + + +> I'd bet on this being the one fixed by +> 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +But wasn't the breakage this fixes only added in qemu 4.0? +He reports his change is from qemu 2.10 to 2.11. + +Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has +something backported that makes the Ubuntu 2.11 being affected by it. +I checked the Delta but there was nothing related backported that I +could identify. + +But I agree, that first of all this should be a new bug instead of +reviving the old one here. + +P.S. this will race as I sent the same via mail :-/, but I need to extend. + +I have now realized that the later report (comment #4) is about Openstack Train which at least on Ubuntu would come with qemu 4.0 - and since 2bbadb08 was released only with 4.1 that would be an open issue. + + +I forked that new discussion into https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497 +Please follow there and leave this bug here to the originally reported error signature. + +It seems the fix is comitted with https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497. Closing this issue + diff --git a/results/classifier/108/other/1838703 b/results/classifier/108/other/1838703 new file mode 100644 index 00000000..2cbcfec9 --- /dev/null +++ b/results/classifier/108/other/1838703 @@ -0,0 +1,56 @@ +files: 0.889 +other: 0.813 +device: 0.758 +semantic: 0.730 +socket: 0.633 +PID: 0.618 +vnc: 0.575 +graphic: 0.548 +permissions: 0.515 +network: 0.515 +boot: 0.491 +performance: 0.484 +debug: 0.329 +KVM: 0.276 + +Makefile BUG in edk2 firmware install 4.1.0-rc3 + +DESTDIR installs end up with wrong paths in JSON files installed to $prefix/share/qemu/firmware. For example, the file: + + 50-edk2-x86_64-secure.json + +ends up incorrectly with: + + "filename": "/build/qemu/pkg/qemu/usr/share/qemu/edk2-x86_64-secure-code.fd", + +instead of the correct: + + "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd", + +Related to commit 26ce90fde5c. + +What distribution/version are you using? + +I'm on Arch, but that shouldn't matter. It's a clear bug in the Makefile. + +I note that Fedora doesn't ship these blobs as they're provide by separate edk2 package. + +Attached patch fixes it for me. + +The same issue was reported and patched on qemu-devel by Olaf Hering two months ago. The patch received three Reviewed-by tags, but nobody bothered to queue it. + +[Qemu-devel] [PATCH v1] Makefile: remove DESTDIR from firmware file cont + +The thread is split over two months, hence two links below, into the mailing list archive: +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07093.html +https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg00690.html + +Patchew link: +https://<email address hidden>/ + +There shouldn't be a need to post a new patch, just for someone to pick up what's been posted already. + +Phil: "get_maintainer.pl" reports no official owners for the root Makefile, but you come out on top as commit-signer (26/70). Can you pick this one up, please? Thanks! + +Fixed in commit 177cd674d620 ("Makefile: remove DESTDIR from firmware file content", 2019-08-03), part of v4.1.0-rc4. + diff --git a/results/classifier/108/other/1838913 b/results/classifier/108/other/1838913 new file mode 100644 index 00000000..49d105ca --- /dev/null +++ b/results/classifier/108/other/1838913 @@ -0,0 +1,66 @@ +graphic: 0.625 +device: 0.590 +semantic: 0.587 +performance: 0.513 +debug: 0.508 +socket: 0.466 +files: 0.443 +other: 0.356 +vnc: 0.352 +permissions: 0.347 +network: 0.346 +boot: 0.312 +PID: 0.259 +KVM: 0.219 + +Single-step exceptions incorrectly routed to EL1 when ELD is EL2 (TDE = 1) (qemu version 3.1) + +Hi, + +I've been encountering issues with QEMU 3.1 when trying to single-step EL1 code, with ELD = EL2 (MDCR_EL2.TDE = 1). I could test with latest commit in a few hours, if you want. + +EL1 is Aarch64. + +These happen as soon as MDSCR_EL1.SS is set to 1 and ERET is executed: + +1) Single-step exceptions are generated even if they should not be (SPSR_EL2.SS = 0) + +2) Single-step exceptions are routed to EL1 + +Exception return from AArch64 EL2 to AArch64 EL1 PC 0x4000005c +Taking exception 1 [Undefined Instruction] +...from EL1 to EL1 +...with ESR 0x32/0xca000022 +...with ELR 0x4000005c +...to EL1 PC 0x200 PSTATE 0x3c5 + +EC 0x32 (0b110010) is Exception_SoftwareStepLowerEl. + +You can find enclosed minimal code (and resulting .elf) for reproduction. + +qemu-system-aarch64 -nographic -machine virt,virtualization=on -d unimp,int -cpu cortex-a57 -kernel test_hyp.elf + + + +Yes, we're directing single-step exceptions to the wrong EL. (I think this is probably a hangover from the fact that we implemented singlestep at about the same time or before we properly implemented EL2 support, so we haven't shaken out all the "assumes debug EL is EL1" assumptions still.) + + +I've just submitted this patchset: +https://<email address hidden>/ + +which I think should fix this bug. With those changes, the test image takes a single-step exception to EL2, and then (because there's no code at the exception entry point) takes a series of EL2-to-EL2 undef exceptions, which I think is expected and correct behaviour. + + +Thanks for the patch! + +I tested it with more complex code, it seems to work fine (and fixes the bug), e.g. with an infinite loop of 2 instructions: + +Single-step exeception ELR = 0x0000000060100000, ISV = 1, EX = 0 +Single-step exeception ELR = 0x0000000060100004, ISV = 1, EX = 0 +(and so on) + +(I haven't been able to test load-exclusive instructions yet but I don't see why it would fail for EL2 specifically, anyway) + +This is fixed in master by commit 8bd587c1066f445 which will be in the 4.2 release. + + diff --git a/results/classifier/108/other/1838946 b/results/classifier/108/other/1838946 new file mode 100644 index 00000000..0f69c241 --- /dev/null +++ b/results/classifier/108/other/1838946 @@ -0,0 +1,636 @@ +other: 0.899 +permissions: 0.866 +graphic: 0.848 +network: 0.831 +device: 0.824 +vnc: 0.813 +KVM: 0.811 +performance: 0.809 +debug: 0.807 +files: 0.792 +socket: 0.784 +semantic: 0.782 +boot: 0.779 +PID: 0.778 + +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/108/other/1839 b/results/classifier/108/other/1839 new file mode 100644 index 00000000..b6d2f5a2 --- /dev/null +++ b/results/classifier/108/other/1839 @@ -0,0 +1,56 @@ +device: 0.874 +boot: 0.751 +KVM: 0.669 +graphic: 0.606 +network: 0.588 +semantic: 0.540 +other: 0.484 +vnc: 0.483 +debug: 0.476 +PID: 0.459 +performance: 0.450 +socket: 0.411 +permissions: 0.164 +files: 0.016 + +command line option (fw_cfg) not being treated as opaque and generates error "short-form boolean option 'x' deprecated" +Description of problem: +I'm trying to run qemu with `fw_cfg` arguments. With a full example I am trying to provide an ignition configuration a flatcar VM using a 'string' parameter which is JSON (rather than a file parameter). + +Running qemu with command line options where the fields have arbitrary data that should be opaque to qemu are being interpreted and cause the command line argument parsing the fail. I have tried putting quotes and double quotes around various parts of the command without success. + + +Sorry, but I haven't tested this with latest (v8.1.0.rc4 / v8.0.4) + +Examples: + +```# qemu-system-x86_64 -fw_cfg name=z,string=a,b +qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated +Please use b=on instead +qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b' +``` + +Single quotes around the `string` value: +``` +# qemu-system-x86_64 -fw_cfg name=z,string='a,b' +qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated +Please use b=on instead +qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b' +``` + +Double quotes around the `string` value +``` +# qemu-system-x86_64 -fw_cfg name=z,string="a,b" +qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated +Please use b=on instead +qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b' + +``` + +Double quotes around the whole `fw_cfg` option value: +``` +# qemu-system-x86_64 -fw_cfg "name=z,string=a,b" +qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated +Please use b=on instead +qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b' +``` diff --git a/results/classifier/108/other/1839294 b/results/classifier/108/other/1839294 new file mode 100644 index 00000000..eb2a073b --- /dev/null +++ b/results/classifier/108/other/1839294 @@ -0,0 +1,42 @@ +graphic: 0.865 +files: 0.821 +device: 0.720 +semantic: 0.671 +performance: 0.595 +other: 0.575 +socket: 0.448 +network: 0.401 +permissions: 0.384 +vnc: 0.376 +PID: 0.356 +boot: 0.268 +debug: 0.200 +KVM: 0.182 + +Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation + +This happens on Windows 10 with the latest installer for 64 bit Windows: qemu-w64-setup-20190807.exe + +On install it will create the files and go through all the typical functions of installing the software, at the very end step it will then delete all files the installer created. + +I looked for logs to see when was going on so I ran the installation in Sandboxie and was able to retain all the installed files but I couldn't find a log for the installer. + +Here is a screenshot of it deleting all the files at the end of the process. + +https://imgur.com/BWiTA38 + +If goes too fast for me to see what is written in the text console otherwise I would post more information but this is all I have. It does not give any error or any other information at completion. + +This error does not occur in the earlier release: qemu-w64-setup-20190731.exe + + + +I hit the same error in my azure pipelines script that uses `choco install qemu`. While it worked with qemu-w64-setup-20190731.exe, the `C:\Program Files\qemu` directory is empty with qemu-w64-setup-20190807.exe. + +We can forget this one if nothing happens from now on; however, this problem might have a rare but systemic problem. We can always wait and see if this problem is ever duplicated. In which case there is at least a commonality to the bug. + +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/108/other/1839325 b/results/classifier/108/other/1839325 new file mode 100644 index 00000000..1a70cfe3 --- /dev/null +++ b/results/classifier/108/other/1839325 @@ -0,0 +1,115 @@ +other: 0.959 +vnc: 0.937 +permissions: 0.936 +performance: 0.928 +debug: 0.923 +KVM: 0.921 +network: 0.917 +graphic: 0.914 +semantic: 0.914 +socket: 0.909 +device: 0.908 +boot: 0.890 +PID: 0.888 +files: 0.860 + +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/108/other/1839807 b/results/classifier/108/other/1839807 new file mode 100644 index 00000000..58ed2d27 --- /dev/null +++ b/results/classifier/108/other/1839807 @@ -0,0 +1,122 @@ +debug: 0.776 +graphic: 0.714 +files: 0.652 +PID: 0.627 +vnc: 0.605 +boot: 0.598 +device: 0.590 +network: 0.589 +semantic: 0.587 +permissions: 0.576 +performance: 0.566 +KVM: 0.566 +other: 0.564 +socket: 0.294 + +Snapshots freeze guest Sabrelite IMX.6 board + +Hello, + +I'm trying to take and restore a snapshot with the whole system state of the Sabrelite IMX.6 board running on QEMU with commands savevm/loadvm. +It seems that I am able to take a snapshot but loading the snapshot fails. + +For comparison I checked out snapshots on 32bit ARM Virt with Debian as well as on the Versatilepb board with a bare metal application and it works fine. +The problem occurs only with that one particular board. + +My environment is: +Ubuntu 18.04 +QEMU 3.0.1 (I see the same issue in QEMU 4.0.0 as well) +The kernel and device tree used for the board was 5.1.14 version from kernel.org + +The file system was build from imx_v6_v7_defconfig config in buildroot as and sd card image. + +Problem: + +Loading snapshot stops the whole machine and it's impossible to resume it. + +Steps to reproduce problem: + +1. I converted the sdcard.img built from the buildroot to qcow2 using command qemu-img convert -f raw -O qcow2 sdcard.img sdcard.qcow2, since the raw doesn't support snapshots. + +2. I start QEMU with a command +./arm-softmmu/qemu-system-arm -m 512 -M sabrelite -kernel zImage -append "rootfstype=ext4 root=/dev/mmcblk2p2 rw rootwait" -rtc base=localtime,clock=vm -dtb imx6dl-sabresd.dtb -drive file=sdcard.qcow2,index=2,format=qcow2,id=mycard -device sd-card,drive=mycard -nographic -net nic -net user + +3. I run a simple program which print characters to the console in the background and add some files in user directory, to differ from original image. + +4. I switch to QEMU monitor, and type “savevm <name>”. +When I type “info snapshots”, the snapshot is listed. +So I assume it was saved correctly. + +5. Then I switch back to Linux console from monitor, remove the added files and stop the background printing process. + +6. I switch back to monitor and I'm trying now to load the snapshot by “loadvm <name>” command. + +That’s where the problem occurs. QEMU stops and I can't switch back from monitor to Linux. +Typing “cont” doesn’t help. +It seems like the simulation has freezed. CPU usage on my Laptop machine equals 100% until I exit QEMU. + + +What’s interesting when I exit the QEMU and then start it again the Linux boots and after it reaches the command prompt I can see the files which were removed after saving the snapshot. + +It looks like loading the snapshots works for restoring disk space but it fails for restoring the running processes. + +Due to the answer on QEMU mailing list (https://lists.nongnu.org/archive/html/qemu-discuss/2019-08/msg00016.html) it is QEMUs bug. + +The underlying cause of this is that we're not migrating the Secure banked cp15 register contents. So boards which don't enable TrustZone or where the guest runs in the NonSecure state (like the virt board, etc) can save/restore fine, but since the imx6 happens to run the guest in the Secure state it gets hit by the bug and its MMU setup etc is completely broken on restore. + +This is a bug I knew about (I mentioned it in LP:1739378 comment #5), but I've forgotten the detail of why it happens and don't seem to have written it down, so I'm going to have to think it through again... + + +Hello again, + +I have tried to disable TrustZone using argument mentioned in comment #5 by changing -M sabrelite to -M sabrelite,secure=off, but I get error "qemu-system-arm: Property '.secure' not found". It works with virt though. Is there any other way to disable it? + +Thank you, +... + +That property doesn't exist for the sabrelite board, it's only on some of the others like vexpress or virt. + + +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.] + +Save/restore with TrustZone enabled is stil broken. + + + +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/467 + + |