diff options
Diffstat (limited to '')
29 files changed, 1586 insertions, 0 deletions
diff --git a/results/classifier/108/other/173 b/results/classifier/108/other/173 new file mode 100644 index 000000000..3a4a6bfed --- /dev/null +++ b/results/classifier/108/other/173 @@ -0,0 +1,16 @@ +device: 0.903 +debug: 0.826 +performance: 0.804 +network: 0.732 +boot: 0.626 +PID: 0.384 +graphic: 0.376 +other: 0.306 +semantic: 0.287 +vnc: 0.271 +socket: 0.239 +files: 0.235 +permissions: 0.179 +KVM: 0.008 + +unable to read symlinks when mounting 9p filesystem with security_model=mapped diff --git a/results/classifier/108/other/1730 b/results/classifier/108/other/1730 new file mode 100644 index 000000000..29f4bf64b --- /dev/null +++ b/results/classifier/108/other/1730 @@ -0,0 +1,31 @@ +graphic: 0.889 +vnc: 0.835 +device: 0.823 +boot: 0.789 +performance: 0.773 +semantic: 0.646 +other: 0.484 +permissions: 0.451 +network: 0.430 +debug: 0.338 +PID: 0.315 +files: 0.246 +socket: 0.180 +KVM: 0.134 + +Virtual console in GTK input uses wrong color for dark gray +Description of problem: +The virtual console in the GTK window uses black to draw dark gray text. This becomes unintelligible if drawing on black background. +Steps to reproduce: +1. Boot any distro to shell prompt with `-serial vc`. +2. Switch to serial console in QEMU GTK window (Ctrl+Alt+3). +4. Run `echo -e "\e[1;30mDark Greay\e[m"`. +5. Output is black on black. + +or + +1. `qemu-system-x86_64 -bios /usr/share/edk2/x64/OVMF.fd` +2. Enter EFI internal shell +3. `cls 0 8` +4. Run `help cls` and observe correct colors in VGA window. +5. Switch to serial console and observe black on black colors. diff --git a/results/classifier/108/other/1730099 b/results/classifier/108/other/1730099 new file mode 100644 index 000000000..f62f8b02d --- /dev/null +++ b/results/classifier/108/other/1730099 @@ -0,0 +1,29 @@ +performance: 0.889 +device: 0.885 +network: 0.845 +vnc: 0.665 +other: 0.656 +graphic: 0.626 +socket: 0.608 +permissions: 0.604 +semantic: 0.555 +debug: 0.440 +boot: 0.436 +PID: 0.415 +KVM: 0.358 +files: 0.326 + +Sometimes, when not touching the SDL window, the guest freezes + +I often just run some development guest machine, and leave its SDL window on a workspace I don’t touch, and only interact with it via TCP. + +And sometimes, the guest just freezes. + +After it gets the focus back, it comes back to life (starts responding via network). + +QEMU release version: 2.8.1.1 + +Which version of SDL are you using? SDL 1.2 or SDL 2.0? If you were using 1.2, could you please try 2.0 instead? Support for SDL 1.2 has been removed now. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1730101 b/results/classifier/108/other/1730101 new file mode 100644 index 000000000..79c923345 --- /dev/null +++ b/results/classifier/108/other/1730101 @@ -0,0 +1,25 @@ +device: 0.893 +performance: 0.827 +boot: 0.815 +graphic: 0.810 +other: 0.669 +semantic: 0.623 +network: 0.512 +permissions: 0.505 +PID: 0.429 +socket: 0.415 +vnc: 0.411 +debug: 0.401 +files: 0.319 +KVM: 0.047 + +The guest is only starting after its SDL window gets focus + +I’m using i3wm and have workspace assigning rules that make QEMU’s SDL window be assigned to a workspace I don’t really switch to. + +When I run start a guest machine, its SDL window is moved to that workspace (I never see it); but the machine freezes after displaying that black window. It only starts booting after I switch to the workspace and view the window. + +Which version of SDL have you been using here? SDL 1.2 or SDL 2.0? If you were using 1.2, could you please try with 2.0 instead? Support for 1.2 has been removed now. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1731277 b/results/classifier/108/other/1731277 new file mode 100644 index 000000000..e99e6a8aa --- /dev/null +++ b/results/classifier/108/other/1731277 @@ -0,0 +1,56 @@ +graphic: 0.822 +other: 0.776 +device: 0.748 +semantic: 0.696 +files: 0.659 +performance: 0.643 +permissions: 0.590 +socket: 0.568 +PID: 0.561 +vnc: 0.535 +debug: 0.525 +network: 0.469 +KVM: 0.391 +boot: 0.355 + +Provide target specific qemu man pages + +Right now, all qemu target binaries (qemu-system-...) share the same man page. + +The current man page is primarily focused on x86, and therefore the information given is entirely wrong for e.g. arm, powerpc or s390x. + +NAME + qemu-doc - QEMU Emulator User Documentation + +SYNOPSIS + qemu-system-i386 [options] [disk_image] + +DESCRIPTION + The QEMU PC System emulator simulates the following peripherals: + + - i440FX host PCI bridge and PIIX3 PCI to ISA bridge + + - Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non + standard modes). + + - PS/2 mouse and keyboard + + - 2 PCI IDE interfaces with hard disk and CD-ROM support + + - Floppy disk + +... + +We should have target specific man pages, with the common options/settings factored out, so they are included in all target specific man pages. + +"man qemu-system-s390x" should give s390x specific (+common) information and "man qemu-system-x86_64" should contain x86 specific (+common) information. + +I'm kind of hoping that moving to Sphinx for our docs toolchain will allow us to for instance have the board specific information in doc comments in each board source file, which could then be automatically assembled into the right documentation. The current manpages are autobuilt from the monolithic qemu-doc.texi, which is woefully out of date in many areas... + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1731588 b/results/classifier/108/other/1731588 new file mode 100644 index 000000000..171f62d33 --- /dev/null +++ b/results/classifier/108/other/1731588 @@ -0,0 +1,37 @@ +graphic: 0.912 +device: 0.859 +other: 0.755 +performance: 0.676 +semantic: 0.651 +network: 0.465 +permissions: 0.435 +PID: 0.400 +vnc: 0.387 +debug: 0.364 +socket: 0.349 +boot: 0.348 +files: 0.298 +KVM: 0.067 + +qemu-system-arm black screen and keyboard not detected + +Hi guys, + +I try to emulate FreeRTOS with this guide : http://wiki.csie.ncku.edu.tw/embedded/Lab32 +But, the keys on my keyboard are not taken into account. + - Command line : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -semihosting +If I try to add usb flag with : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -usb -device usb-host,hostbus=1,hostaddr=1 -show-curso +I obtain this message "qemu-system-arm: -device usb-host,hostbus=1,hostaddr=1: 'usb-host' is not a valid device model name" + +My second option is try with the latest version of qemu with this command line : "qemu-system-arm -M lm3s6965evb -monitor stdio -kernel build/main.bin -semihosting" but I obtain a black screen. + +Could someone guide me on this problem ? + +"stm32-p103" is not a board model supported by upstream QEMU. Presumably you're using a fork of QEMU -- you should ask whoever is responsible for that fork about it. + + +For the second command line -- is the binary you're trying to run built for the stellaris board model you're trying to run it on? If it's the same binary you tried to use with the stm32 board model then I wouldn't expect it to work. You need to build a binary that targets the board model you run with. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1731957 b/results/classifier/108/other/1731957 new file mode 100644 index 000000000..5551c9365 --- /dev/null +++ b/results/classifier/108/other/1731957 @@ -0,0 +1,58 @@ +KVM: 0.705 +debug: 0.684 +performance: 0.676 +vnc: 0.675 +other: 0.672 +permissions: 0.670 +network: 0.668 +socket: 0.661 +files: 0.661 +boot: 0.658 +graphic: 0.651 +device: 0.644 +PID: 0.634 +semantic: 0.630 + +qemu-kvm exits with console permission problems + +# rpm -qa | grep qemu +qemu-img-ev-2.9.0-16.el7_4.8.1.x86_64 +qemu-kvm-ev-2.9.0-16.el7_4.8.1.x86_64 +ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch +libvirt-daemon-driver-qemu-3.2.0-14.el7_4.3.x86_64 +qemu-kvm-common-ev-2.9.0-16.el7_4.8.1.x86_64 + +qemu.conf: +stdio_handler = "file" + +libvirtd runs as root with '/usr/sbin/libvirtd --listen' + +we run openstack, it creates an instance like this: + +2017-11-13 15:17:14.143+0000: starting up libvirt version: 3.2.0, package: 14.el7_4.3 (Unknown, 2017-09-05-02:55:29, x86-ol7-builder +-02.us.oracle.com), qemu version: 2.9.0(qemu-kvm-ev-2.9.0-16.el7_4.8.1), hostname: compute6 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/root QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=instance-00000016,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-00000016/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,xsaveopt=on,abm=on,invpcid=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=de115ee2-a86f-432d-96fe-bec91b0a5748,uuid=48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-00000016/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot + strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:bf:f5:40,bus=pci.0,addr=0x3 -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83 +a2ffdf/console.log,logappend=off -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg +timestamp=on + +With older qemu like 2.5 or 2.6 console log belongs to qemu:qemu and the process starts successfully. +With 2.9 it fails and console.log is left root:root : + +2017-11-13 15:17:14.173+0000: 26010: debug : qemuProcessHook:2738 : Hook complete ret=0 +2017-11-13 15:17:14.173+0000: 26010: debug : virExec:699 : Done hook 0 +2017-11-13 15:17:14.173+0000: 26010: debug : virExec:736 : Setting child uid:gid to 42427:42427 with caps 0 +2017-11-13 15:17:14.173+0000: 26010: debug : virCommandHandshakeChild:435 : Notifying parent for handshake start on 29 +2017-11-13 15:17:14.173+0000: 26010: debug : virCommandHandshakeChild:443 : Waiting on parent for handshake complete on 30 +2017-11-13 15:17:14.192+0000: 26010: debug : virFileClose:110 : Closed fd 29 +2017-11-13 15:17:14.192+0000: 26010: debug : virFileClose:110 : Closed fd 30 +2017-11-13 15:17:14.192+0000: 26010: debug : virCommandHandshakeChild:463 : Handshake with parent is done +2017-11-13T15:17:14.232713Z qemu-kvm: -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/console.log,logappend=off: Unable to open logfile /var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/console.log: Permission denied +2017-11-13 15:17:14.321+0000: shutting down, reason=failed + +These might be helpful or related: +- https://bugzilla.redhat.com/show_bug.cgi?id=1499800 +- https://bugzilla.redhat.com/show_bug.cgi?id=1501957 + +Sounds like this is/was rather an issue with libvirt or openstack, but certainly not qemu. If the problem still persists, please report it to those projects first. Thanks! + diff --git a/results/classifier/108/other/1732177 b/results/classifier/108/other/1732177 new file mode 100644 index 000000000..ab997c4f0 --- /dev/null +++ b/results/classifier/108/other/1732177 @@ -0,0 +1,25 @@ +boot: 0.697 +device: 0.674 +performance: 0.662 +graphic: 0.587 +socket: 0.560 +other: 0.515 +network: 0.464 +semantic: 0.419 +debug: 0.249 +vnc: 0.198 +PID: 0.166 +permissions: 0.141 +files: 0.134 +KVM: 0.015 + +SBSA ACS test freezes inside qemu-system-aarch64 + +In an effort to get Windows 10 for ARM64 (which is supposed to boot on SBSA/SBBR-compliant platforms) to boot inside qemu, I tried to run the SBSA ACS test suite. I used the UEFI image from the latest Linaro snapshot, and built the SBSA ACS UEFI application from https://github.com/ARM-software/sbsa-acs myself using a Linaro aarch64 compiler. + +Test #8 causes an infinite exception loop, as the exception vectors themselves somehow become inaccessible, and accessing them triggers another exception to be handled by the same vector. (With some older Linaro UEFI images, the hard lockup is avoided, and the SBSA UEFI app crashes instead.) If I disable that test, the testsuite locks up in other tests in very similar ways. We aren't even able to get a pass/fail score from the app because of this. + +Which version of QEMU did you test? Does it work better with the latest version of QEMU now? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1732679 b/results/classifier/108/other/1732679 new file mode 100644 index 000000000..fd7bbfa12 --- /dev/null +++ b/results/classifier/108/other/1732679 @@ -0,0 +1,111 @@ +other: 0.974 +permissions: 0.945 +graphic: 0.937 +semantic: 0.916 +vnc: 0.910 +device: 0.879 +debug: 0.862 +PID: 0.859 +socket: 0.833 +boot: 0.820 +network: 0.817 +performance: 0.795 +files: 0.790 +KVM: 0.774 + +Cisco NX-OSv 9k crashes during boot with qemu 2.10.1(Debian 1:2.10.0+dfsg-2) and ovmf 0~20161202.7bbe0b3e-1 + +Ubuntu 17.04 +qemu 2.10.1(Debian 1:2.10.0+dfsg-2) +gns3 2.0.3 +NX-OSv 9k 7.0.3.I6.1 + +- No such issue with previous qemu 2.8.x +- the issue does not seem to come from the debian packaging +- the issue does not seem to come from GNS3 either, as confirmed by Jeremy Grossmann at https://github.com/GNS3/gns3-server/issues/1193#issuecomment-344240460 + +Either some parameters usage have changed (for instance -bios) (which would make qemu not backwards compatible) or there is an issue with qemu itself. +The configuration parameters are: +``` + "compute_id": "local", + "console": 2010, + "console_type": "telnet", + "first_port_name": "mgmt0", + "height": 48, + "label": { + "rotation": 0, + "style": "font-family: TypeWriter;font-size: 10.0;font-weight: bold;fill: #000000;fill-opacity: 1.0;", + "text": "NX_OSv_9k_Spine_31", + "x": -54, + "y": -25 + }, + "name": "NX_OSv_9k_Spine_31", + "node_id": "8d01119a-0adc-41bc-950b-c5639db7708c", + "node_type": "qemu", + "port_name_format": "Ethernet1/{port1}", + "port_segment_size": 0, + "properties": { + "acpi_shutdown": false, + "adapter_type": "e1000", + "adapters": 10, + "bios_image": "", + "bios_image_md5sum": null, + "boot_priority": "c", + "cdrom_image": "", + "cdrom_image_md5sum": null, + "cpu_throttling": 0, + "cpus": 2, + "hda_disk_image": "NX-OSv-9k-7.0.3.I6.1.free.qcow2", + "hda_disk_image_md5sum": "18bb991b814a508d1190575f99deed99", + "hda_disk_interface": "ide", + "hdb_disk_image": "", + "hdb_disk_image_md5sum": null, + "hdb_disk_interface": "ide", + "hdc_disk_image": "", + "hdc_disk_image_md5sum": null, + "hdc_disk_interface": "ide", + "hdd_disk_image": "", + "hdd_disk_image_md5sum": null, + "hdd_disk_interface": "ide", + "initrd": "", + "initrd_md5sum": null, + "kernel_command_line": "", + "kernel_image": "", + "kernel_image_md5sum": null, + "legacy_networking": false, + "mac_address": "00:07:00:03:16:01", + "options": "-nographic -enable-kvm -cpu host -machine q35 -smp cpus=2 -bios /usr/share/ovmf/OVMF.fd", + "platform": "x86_64", + "process_priority": "normal", + "qemu_path": "/usr/bin/qemu-system-x86_64", + "ram": 6144, + "usage": "" +``` + +The logs are: +- [execution log](https://github.com/GNS3/gns3-server/files/1381651/qemu.log.txt) +- [terminal log](https://github.com/GNS3/gns3-server/files/1381660/terminal.log.txt) + +With the latest qemu, I can boot: +- Cisco IOSv 15.6(2)T +- Cisco IOSv-L2 15.2(20170321:233949) +- Cisco CSR 1000v 16.5.1b +- Cisco ASAv 9.6(2) + +The major difference with NX-OSv 9k is the bios parameter: ```-bios /usr/share/ovmf/OVMF.fd```: +``` +ll /usr/share/ovmf/OVMF.fd +-rw-r--r-- 1 root root 2097152 Dec 9 2016 /usr/share/ovmf/OVMF.fd +``` +A normal boot log with qemu 2.8.1 is available [here](https://github.com/GNS3/gns3-server/files/1381729/terminal.log.2.8.txt) + +Highlighting the differences: qemu 2.8.1 on the left, qemu 2.10.1 on the right hand side with the same boot parameters + + +Actually, this issue is solved with a fresher ovmf package than the one shipped by default with Ubuntu 17.04 (0~20161202.7bbe0b3e-1). + +This issue should be closed. + + +Closing, according to the previous comment. + diff --git a/results/classifier/108/other/1733 b/results/classifier/108/other/1733 new file mode 100644 index 000000000..1e99f3d8e --- /dev/null +++ b/results/classifier/108/other/1733 @@ -0,0 +1,18 @@ +device: 0.866 +performance: 0.725 +network: 0.556 +graphic: 0.439 +debug: 0.323 +vnc: 0.293 +boot: 0.263 +semantic: 0.258 +KVM: 0.177 +other: 0.115 +PID: 0.096 +socket: 0.091 +permissions: 0.077 +files: 0.068 + +[riscv-pmp]: PMP_is_locked function has redundant top pmp check +Additional information: + diff --git a/results/classifier/108/other/1734 b/results/classifier/108/other/1734 new file mode 100644 index 000000000..500192732 --- /dev/null +++ b/results/classifier/108/other/1734 @@ -0,0 +1,31 @@ +files: 0.890 +performance: 0.856 +device: 0.768 +other: 0.647 +graphic: 0.625 +semantic: 0.498 +PID: 0.483 +network: 0.470 +boot: 0.468 +permissions: 0.447 +socket: 0.438 +vnc: 0.437 +debug: 0.341 +KVM: 0.133 + +mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version +Description of problem: +Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. + +I created a repo with a readme, and a simple application that you can use to demonstrate the problem: +https://github.com/mwales/qemu_mmap_test + +Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. +Steps to reproduce: +1. Compile test application that mmaps entire files +2. Create 5 256MB test files +3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. +Additional information: +Lots of details on my github writeup and a demo of the bug in question. + +It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. diff --git a/results/classifier/108/other/1734474 b/results/classifier/108/other/1734474 new file mode 100644 index 000000000..d340ec052 --- /dev/null +++ b/results/classifier/108/other/1734474 @@ -0,0 +1,74 @@ +boot: 0.640 +device: 0.525 +socket: 0.522 +semantic: 0.484 +performance: 0.472 +other: 0.427 +PID: 0.370 +vnc: 0.351 +files: 0.330 +permissions: 0.285 +graphic: 0.282 +network: 0.245 +debug: 0.223 +KVM: 0.160 + +Maemo does not boot on emulated N800 + +I start QEMU with qemu-system-arm-m 130 -M n800 -kernel zImage.1 -mtdblock maemo.img -append "root=/dev/mtdblock3 rootfstype=jffs2" +On QEMU 1.2.0 see "NOKIA" logo and then desktop appears, but on 1.5.0 and newer (including latest versions) I see only white screen and no signs of life. Was this caused by regression or any syntax change? + +UPD: Maemo will boot on the second attempt if I reset the emulator manually. + +That's a regression, but unfortunately the n800 boards aren't really maintained (I don't have any test images to hand, and the hardware is long-gone these days). You could try a git bisect to see what commit broke, if you want to investigate. + + +Oops, I should have asked for the image to reproduce with back in 2017 when this bug was first filed :-( I don't suppose you still have it ? + + +It's available here: https://4pda.ru/forum/index.php?showtopic=870847 + +Thanks. I can confirm that there's been a regression since 1.2.0 that's still not fixed in master. + + +Bisection thinks commit cb5ef3fa1871522a08 is the cause. + + +This change on current head-of-git, which is effectively just reverting the logic-change part of commit cb5ef3fa1871522a08, is sufficient to allow the n800 image to boot again. +But that commit was trying to fix a bug, so we probably need to look more carefully at the logic rather than just reverting it... + +diff --git a/hw/misc/tmp105.c b/hw/misc/tmp105.c +index b47120492a..1813477268 100644 +--- a/hw/misc/tmp105.c ++++ b/hw/misc/tmp105.c +@@ -161,14 +161,12 @@ static int tmp105_tx(I2CSlave *i2c, uint8_t data) + { + TMP105State *s = TMP105(i2c); + +- if (s->len == 0) { ++ if (!s->len++) { + s->pointer = data; +- s->len++; + } else { + if (s->len <= 2) { + s->buf[s->len - 1] = data; + } +- s->len++; + tmp105_write(s); + } + + + +Should be fixed by this patch series: +https://<email address hidden>/ + +Commit cb5ef3fa1871522a08 is correct -- it just exposed an underlying bug in the TMP105 temperature sensor device. + + +Fixed in v5.2.0? +ab135622cf4 ("tmp105: Correct handling of temperature limit checks") +e1919889ef7 ("hw/misc/tmp105: reset the T_low and T_High registers") + + +Yes, I think we can close this now. + diff --git a/results/classifier/108/other/1734792 b/results/classifier/108/other/1734792 new file mode 100644 index 000000000..6d5fb28f0 --- /dev/null +++ b/results/classifier/108/other/1734792 @@ -0,0 +1,35 @@ +device: 0.885 +graphic: 0.751 +performance: 0.725 +semantic: 0.634 +network: 0.555 +other: 0.484 +boot: 0.432 +permissions: 0.429 +debug: 0.392 +socket: 0.376 +PID: 0.357 +vnc: 0.321 +files: 0.310 +KVM: 0.049 + +linux-user mode does not support memfd_create syscall + +qemu-x86_66 GIT HEAD fails on a userspace application that requires memfd_create with: + +"qemu: Unsupported syscall: 319". + +memfd_create support needs to be implemented in QEMU. + +Not only qemu-x86_64, but also: + +qemu-aarch64 => qemu: Unsupported syscall: 279 +qemu-arm => qemu: Unsupported syscall: 385 +qemu-mips => qemu: Unsupported syscall: 4354 +qemu-mips64 => qemu: Unsupported syscall: 5314 +qemu-powerpc => qemu: Unsupported syscall: 360 +qemu-powerpc64 => qemu: Unsupported syscall: 360 + +9bdfa4d23f43 linux-user: add memfd_create + + diff --git a/results/classifier/108/other/1735 b/results/classifier/108/other/1735 new file mode 100644 index 000000000..dffc6f508 --- /dev/null +++ b/results/classifier/108/other/1735 @@ -0,0 +1,44 @@ +permissions: 0.894 +vnc: 0.643 +PID: 0.609 +network: 0.415 +device: 0.391 +performance: 0.377 +graphic: 0.338 +socket: 0.293 +other: 0.290 +KVM: 0.288 +boot: 0.219 +debug: 0.216 +files: 0.214 +semantic: 0.168 + +[riscv-pmp] Pmp_hart_has_privs local variable name easily misunderstood +Additional information: +```c +// int => bool +static int pmp_is_in_range(CPURISCVState *env, int pmp_index, + target_ulong addr); + +bool pmp_hart_has_privs(CPURISCVState *env, target_ulong addr, + target_ulong size, pmp_priv_t privs, + pmp_priv_t *allowed_privs, target_ulong mode) +{ + int i = 0; + int pmp_size = 0; + // easily misunderstood local variable + target_ulong s = 0; + target_ulong e = 0; + + for (i = 0; i < MAX_RISCV_PMPS; i++) { + s = pmp_is_in_range(env, i, addr); + e = pmp_is_in_range(env, i, addr + pmp_size - 1); + + /* partially inside */ + if ((s + e) == 1) { + + } + + /* fully inside */ + if ((s + e) == 2) { +``` diff --git a/results/classifier/108/other/1735049 b/results/classifier/108/other/1735049 new file mode 100644 index 000000000..77a76e489 --- /dev/null +++ b/results/classifier/108/other/1735049 @@ -0,0 +1,68 @@ +semantic: 0.816 +graphic: 0.750 +performance: 0.725 +other: 0.722 +device: 0.692 +files: 0.593 +permissions: 0.476 +vnc: 0.470 +socket: 0.434 +boot: 0.411 +PID: 0.401 +network: 0.350 +debug: 0.332 +KVM: 0.263 + +Need MTTCG support for x86 guests + +MTTCG support is notably absent for x86_64 guests. The last Wiki update on MTTCG was back in 2015, and I am having some difficulty determining the current status of the underlying requirements to enable this feature on x86 hosts. + +For instance, has support for strong-on-weak memory consistency been added into QEMU GIT at this point? + +Thanks! + +Patches are now on the list to enable MTTCG for i386 and x86_64 guests. See v2 here: + +https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00237.html + +I'm hoping these patches will be in the next QEMU release. + +Regarding your last question: +> For instance, has support for strong-on-weak memory consistency been added into QEMU GIT at this point? + +Yes, TCG inserts the appropriate barriers around memory accesses since commit b32dc3370a ("tcg: Implement implicit ordering semantics", 2017-09-05) + + + +This feature is in QEMU v3.1, which was released today. + +See the discussion linked below that says that strong on weak is not actually fully supported yet. + +Is that discussion correct? + +=== + +In short they explained to me that since the host arm64 is a weaker memory order than the guest x86 they disabled mttcg because if they would implement it would slow everything down but the good news is that if the guest is the same memory order it is not disabled and if it is weaker memory order it is not disabled also. + +https://github.com/utmapp/UTM/issues/257#issuecomment-612675960 + +=== + +Right, that's what I figured from the code. So basically the launchpad comment was incorrect. There is no MTTCG support for x86 on ARM64. + +https://github.com/utmapp/UTM/issues/257#issuecomment-612689011 + +Looks like support for this was not fully added; my apologies for closing this bug too early. + +Adding full support for strong-on-weak emulation would be simple, at least when it comes to memory ordering. The slowdown would be huge though, see Figure 12 in http://www.cs.columbia.edu/~cota/pubs/cota_cgo17.pdf (i.e. ~2x hmean overhead for SPEC). + +The good news is that with hardware support this overhead is ~0 (see SAO in that figure). + +The other feature that is not yet implemented in upstream QEMU is the correct emulation of LL/SC, although for most code out there this shouldn't be an issue in practice given that most parallel code relies on cmpxchg, not on LL/SC pairs. + +I'm reopening this bug an Cc'ing a few people who are more familiar with the current code than I am in case I missed anything. + +OK, looks like I cannot reopen the bug, probably because the bug tracker moved to gitlab. + +If you care about this feature, please file a bug over there: https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/108/other/1735082 b/results/classifier/108/other/1735082 new file mode 100644 index 000000000..d46b0a897 --- /dev/null +++ b/results/classifier/108/other/1735082 @@ -0,0 +1,44 @@ +vnc: 0.740 +device: 0.647 +network: 0.623 +other: 0.546 +graphic: 0.481 +files: 0.432 +semantic: 0.425 +permissions: 0.398 +socket: 0.384 +performance: 0.362 +PID: 0.334 +KVM: 0.308 +boot: 0.296 +debug: 0.176 + +NVME pass through in th eguest VM + +Hi Qemu Team + +i am new in qemu and trying for nvme pass through .. +for that i used below git repo for nvme + +https://github.com/famz/qemu/tree/nvme + +and trying to launch the VM by below qemu command .. + +/usr/local/bin/qemu-system-x86_64 -name sl7.0 -m 1024 -object memory-backend-file,id=mem,size=1G,mem-path=/dev/hugepages,share=on -nographic -no-user-config -nodefaults -serial mon:telnet:localhost:7704,server,nowait -monitor mon:telnet:localhost:8804,server,nowait -numa node,memdev=mem -drive file=/home/qemu/qcows,format=qcow2,if=none,id=disk -device ide-hd,drive=disk,bootindex=0 -drive file=nvme://0000:d8:00.0,if=none,id=drive0 -device virtio-blk,drive=drive0,id=virtio0 --enable-kvm + +i am getting kernel panic and not proceed further..please help + +PS:- our guest VM version is + +Scientific Linux 7.0 (Nitrogen) +Kernel 3.10.0-123.el7.x86_64 on an x86_64 + +Regards +Nitin + + + +Can you reproduce the problem with the latest official upstream version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1735653 b/results/classifier/108/other/1735653 new file mode 100644 index 000000000..8d2139e48 --- /dev/null +++ b/results/classifier/108/other/1735653 @@ -0,0 +1,64 @@ +device: 0.901 +graphic: 0.844 +boot: 0.811 +debug: 0.753 +other: 0.731 +performance: 0.641 +socket: 0.636 +semantic: 0.627 +network: 0.625 +permissions: 0.612 +PID: 0.547 +files: 0.470 +vnc: 0.385 +KVM: 0.211 + +qemu aarch64 cannot boot linux kernel v4.6+ + +Hi, +I tested the latest qemu-system-aarch64 cannot boot linux mainline kernel since v4.6 from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. + +Environment info: +# host + ubuntu 16.04 +# qemu + Master branch from git://git.qemu.org/qemu.git, and now the HEAD is c11d61271b9e6e7a1f0479ef1ca8fb55fa457a62. +# build command + ./configure --target-list=aarch64-softmmu + make +# qemu commmand + qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -smp 4 -m 1024 -nographic -s -kernel ~/workspace/linux/arch/arm64/boot/Image -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::2222-:22 + +Error info: + No error prompted, actually no any log which means I couldn't see the usually kernel boot message. + +Debug info: + I did a git bisect on linux, and found with this kernel commit, qemu failed to boot. Parent of 406e308770a92bd33995b2e5b681e86358328bb0 can boot. + commit 406e308770a92bd33995b2e5b681e86358328bb0 + Author: James Morse <email address hidden> + Date: Fri Feb 5 14:58:47 2016 +0000 + + arm64: add ARMv8.2 id_aa64mmfr2 boiler plate + + ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the + cpu feature boiler plate used by the actual features in later patches. + + Signed-off-by: James Morse <email address hidden> + Reviewed-by: Suzuki K Poulose <email address hidden> + Signed-off-by: Catalin Marinas <email address hidden> + The main change in the patch is to add reg_id_aa64mmfr2 in to arch/arm64/include/asm/cpu.h, so might it be any struct change not included in qemu? + +Can you please help check how to fix it? + +Thanks + +- Joey + +This bug was fixed in QEMU commit e20d84c1407d43d, back in 2016. Are you sure you're running the version of QEMU which you've just built, and not the installed system one (which is likely to be older)? Your command line suggests you're running the system one. The newly built binary will be ./aarch64-softmmu/qemu-system-aarch64 in the build directory (and you can check using the --version option what binary you're running). + + +Thanks Peter, +I repeat the step again and it indeed succeed for v4.9 kernel, So I think the ./aarch64-softmmu/qemu-system-aarch64 should be the issue. The case can be closed now. + +Thanks again. + diff --git a/results/classifier/108/other/1736 b/results/classifier/108/other/1736 new file mode 100644 index 000000000..ad42489b1 --- /dev/null +++ b/results/classifier/108/other/1736 @@ -0,0 +1,82 @@ +other: 0.979 +graphic: 0.926 +debug: 0.919 +permissions: 0.907 +semantic: 0.900 +files: 0.893 +performance: 0.854 +device: 0.852 +PID: 0.844 +socket: 0.790 +boot: 0.787 +vnc: 0.780 +KVM: 0.731 +network: 0.729 + +Invalid guest addr in debug output +Description of problem: +When using QEMU 7.1.0 the log file for the first translation block (not starting at 0) looks like this: +(Note the `guest addr 0x00010000`) +``` +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=47] + -- guest addr 0x00010000 + tb prologue +0x7f95a8000300: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7f95a8000303: 85 db testl %ebx, %ebx +0x7f95a8000305: 0f 8c 18 00 00 00 jl 0x7f95a8000323 + -- guest addr 0x00010020 +0x7f95a800030b: e9 00 00 00 00 jmp 0x7f95a8000310 +0x7f95a8000310: c7 45 3c 3c 00 01 00 movl $0x1003c, 0x3c(%rbp) +0x7f95a8000317: 48 8d 05 22 ff ff ff leaq -0xde(%rip), %rax +0x7f95a800031e: e9 f5 fc ff ff jmp 0x7f95a8000018 +0x7f95a8000323: 48 8d 05 19 ff ff ff leaq -0xe7(%rip), %rax +0x7f95a800032a: e9 e9 fc ff ff jmp 0x7f95a8000018 +``` + +For QEMU 7.2.0 and higher: +(Note the `guest addr` is only the page offset.) +``` +Trace 0: 0x7fe434000100 [00000400/00000000/00000020/ff200000] +---------------- +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=52] + -- guest addr 0x00000000 + tb prologue +0x7fe434000340: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7fe434000343: 85 db testl %ebx, %ebx +0x7fe434000345: 0f 8c 1d 00 00 00 jl 0x7fe434000368 + -- guest addr 0x00000020 +0x7fe43400034b: 8b 5d 3c movl 0x3c(%rbp), %ebx +0x7fe43400034e: 83 c3 3c addl $0x3c, %ebx +0x7fe434000351: 89 5d 3c movl %ebx, 0x3c(%rbp) +0x7fe434000354: 66 66 90 nop +0x7fe434000357: e9 00 00 00 00 jmp 0x7fe43400035c +0x7fe43400035c: 48 8d 05 1d ff ff ff leaq -0xe3(%rip), %rax +0x7fe434000363: e9 b0 fc ff ff jmp 0x7fe434000018 +0x7fe434000368: 48 8d 05 14 ff ff ff leaq -0xec(%rip), %rax +0x7fe43400036f: e9 a4 fc ff ff jmp 0x7fe434000018 +``` +Steps to reproduce: +1. Run the provided command line for any kernel / system image. (likely other architectures are affected as well) +2. Look into the debug log. +Additional information: +While looking if this was already reported I found #1528 and #1697 which could potentially caused by this. It might as well be just an oversight in the debug output. diff --git a/results/classifier/108/other/1736042 b/results/classifier/108/other/1736042 new file mode 100644 index 000000000..8816c1fa1 --- /dev/null +++ b/results/classifier/108/other/1736042 @@ -0,0 +1,55 @@ +debug: 0.899 +graphic: 0.809 +performance: 0.794 +other: 0.780 +semantic: 0.715 +KVM: 0.655 +boot: 0.516 +device: 0.508 +files: 0.498 +permissions: 0.349 +network: 0.329 +socket: 0.280 +PID: 0.262 +vnc: 0.213 + +qemu-system-x86_64 does not boot image reliably + +Booting image as root user with following command works randomly. + +./qemu-system-x86_64 -enable-kvm -curses -smp cpus=4 -m 8192 /root/ructfe2917_g.qcow2 + +Most of the time it ends up on "800x600 Graphic mode"(been stuck there even for 4 hours before killed), but 1 out of ~20 it boots image correctly(and instantly). + +This is visible in v2.5.0 build from sources, v2.5.0 from Ubuntu Xenial and v2.1.2 from Debian Jessie. + +The image in question was converted from vmdk using: + +qemu-img convert -O qcow2 file.vmdk file.qcow2 + +The image contains Ubuntu with grub. + +I can provide debug logs, but will need guidance how to enable them(and what logs are necessary). + +As a side note, it seems that booting is more certain after connecting(or mounting) partition using qemu-nbd/mount. + +Please always use the latest version of QEMU (currently v2.10, soon v2.11) when reporting bugs to the upstream QEMU project - we don't support old versions like v2.5 any more. So I guess you wanted to report a bug agains v2.5 in Ubuntu instead and I changed the target of this bug accordingly. + +I want a fix ;) and I do expect qemu to get it faster then Ubuntu. +So I set up Ubuntu Zesty(to fullfill dependencies) and build qemu: +QEMU emulator version 2.10.1 (v2.10.1-dirty) +and... it's still there. + +Can you tell me how and what logs to provide? + +And it still happens on: + +QEMU emulator version 2.10.93 (v2.11.0-rc3-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +This looks not a QEMU bug to me. You may drop "-curses" first, and run again. Once get inside, change grub file(/etc/default/grub) by uncomment GRUB_TERMINAL=console. It should work then. If still not, then blacklist vga16fb and add "fbcon=map:99 text" in grub command line. Remember to run update-grub after change configure file. + +Have you ever tried the suggestions from Liang Yan ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1736655 b/results/classifier/108/other/1736655 new file mode 100644 index 000000000..9ddb81eee --- /dev/null +++ b/results/classifier/108/other/1736655 @@ -0,0 +1,90 @@ +permissions: 0.877 +network: 0.844 +semantic: 0.841 +debug: 0.834 +device: 0.822 +other: 0.821 +performance: 0.812 +vnc: 0.797 +boot: 0.797 +KVM: 0.784 +graphic: 0.782 +files: 0.778 +PID: 0.776 +socket: 0.713 + +2k3/xp guests w/virtio-net randomly DHCP fail on boot + +Host: +Debian GNU/Linux 9 with Linux 4.13.0-0.bpo.1-amd64 +QEMU 2.10.1 + +Guest: +Windows 2003 Standard SP2 (x64) +Windows XP SP3 (i386) + +QEMU command line: +http://cfp.vim-cn.com/cbdF3 + +Description: +After upgrading from QEMU 2.8 to 2.10.1, my Windows 2003 x64 and Windows XP guests with "virtio-net-pci" NIC would randomly fail to aquire DHCP address on boot. When it fails, cycle disable/enable the connection in Control Panel could make it connect successfully. As an immediate workaround, I switched to the RTL8139 NIC which works fine. Further investigation showed that manually reverting commit '4a3f03ba8dbf53fce36d0c1dd5d0cc0f340fe5f3' on top of 2.10.1 "fixed" the problem. + +Here are the test results: +git branch 4a3f03b: 25 boots, 8 failures +git branch 39f099e: 60 boots, 0 failure +2.10.1 with revert: 194 boots, 0 failure + +Hi Patrick, +thank you so much for the report and your help to make Ubuntu better. +Also for all the bisecting that is very helpful. + +While backporting the change itself would be very trivial we need to find what the final solution has to be first. + +I checked latest upstream which is about to release 2.11 these days and there was not related change. +- no revert to this commit +- no other major disabling/fixes for ioeventfd in these cases + +That would imply that this is an issue unknown to upstream - and that means that we need to make it known there to not end up carrying a Delta forever and deriving more and more. +So we should bring it up there and find a solution for everyone. + +First of all let me try if I can reproduce it over here, then we can decide on next steps. +Very likely one of them would be to report it to upstream as well - which since you have a great bug description already they track Launchpad I can easily do for you by adding a bug Task. + +Well I see you already opened it against upstream - sorry (too early for me) - great. +Adding an Ubuntu task then to track potential fixes to take eventually. + +I wanted an XP guest testbed anyway for some time, so this was the perfect reason to create one. +# virtio drivers from [1] and otherwise a "normal" virt-manager setup of a winxp sp3 (32bit) guest + +- Modified to use virtio for net +- Modified to have the virtio drivers as floppy +- Installed virtio drivers for network afer base install + +So after that I assume I'm at the same stage you are. +- WinXP Guest +- Virtio Driver for network +- Host provides DHCP to a bridged network + +I set that to a rebot loop and checked the internet connection through the dhcp virtiop net after reboot. This worked through 10 reboots without an issue, but then IIRC with vhost ioeventfd was on all the time. + +I realized the change identified by you should only make a differenc on non-vhost virtio-net. +But libvirt will make use of vhost automatically if available, so I set the interface to use driver qemu explicitly. + +Another 10 reboots without issue - the virtio version is of 7/19/2017 version 51.75.104.14100 +There must be something more to your case, so please if you have more info how to trigger the case let us know. + +I really think I have the same case you were describing as affected by the change you identified: +$ virsh qemu-monitor-command --hmp winxp 'info network' +net0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:ce:ca:72 + \ hostnet0: index=0,type=tap,fd=26 +Here from qtree on the device [2] ioeventfd is on. + +Could you try and run it with vhost and see if this changes behavior it for you? + +[1]: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_amd64.vfd +[2]: http://paste.ubuntu.com/26123654/ + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1737882 b/results/classifier/108/other/1737882 new file mode 100644 index 000000000..a717768a9 --- /dev/null +++ b/results/classifier/108/other/1737882 @@ -0,0 +1,23 @@ +device: 0.814 +boot: 0.779 +other: 0.699 +graphic: 0.651 +network: 0.595 +permissions: 0.574 +performance: 0.573 +semantic: 0.548 +socket: 0.496 +files: 0.394 +debug: 0.358 +PID: 0.317 +vnc: 0.308 +KVM: 0.030 + +QEMU Zaurus cannot boot 2.4.x kernels + +I tried akita and spitz machines. +4.x, 3.x and 2.6.x kernels boot OK, but when I try to pass any 2.4.x, qemu crashes with "Trying to execute code outside RAM or ROM at 0x00800000". + +Thanks for the bug report. Unfortunately the akita and spitz models are pretty much unmaintained these days, so if this is important to you you'll need to investigate the cause of the problem yourself, especially given that more recent kernels work. + + diff --git a/results/classifier/108/other/1737883 b/results/classifier/108/other/1737883 new file mode 100644 index 000000000..c62783b79 --- /dev/null +++ b/results/classifier/108/other/1737883 @@ -0,0 +1,26 @@ +device: 0.765 +graphic: 0.765 +other: 0.733 +performance: 0.658 +network: 0.604 +vnc: 0.601 +boot: 0.590 +semantic: 0.519 +socket: 0.480 +debug: 0.403 +PID: 0.348 +permissions: 0.303 +files: 0.246 +KVM: 0.014 + +Cannot boot FreeBSD on versatilepb machine + +I know some years ago it was possible to boot FreeBSD in QEMU versatilepb machine +https://kernelnomicon.org/?p=229 (you can download image and kernel using web.archive.org) +Now when I try to do that I get only black screen with no output even in QEMU console. +I also added -global versatile_pci.broken-irq-mapping=1, but this seem to have no effect. + +What version did this last work on? What version have you tested that failed? Have you tried the latest QEMU HEAD build? What was the full command line of your invocation? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1738202 b/results/classifier/108/other/1738202 new file mode 100644 index 000000000..a7d1c45f6 --- /dev/null +++ b/results/classifier/108/other/1738202 @@ -0,0 +1,65 @@ +graphic: 0.882 +other: 0.851 +performance: 0.780 +files: 0.770 +semantic: 0.759 +socket: 0.755 +permissions: 0.739 +debug: 0.739 +device: 0.705 +network: 0.693 +PID: 0.677 +vnc: 0.623 +boot: 0.607 +KVM: 0.449 + +qemu 2.11 segfaults on elf file that worked with qemu2.7 + +running on cygwin in Windows 7 + +QEMU 2.10.93 segfaults: +$ /opt/qemu2.11/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +Segmentation fault + +where QEMU 2.7.0 worked: +$ /opt/qemu2.7/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +------------ CUnit_MFWso_Cycle_f1 ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFWso_Cycle_f1 + Test: MFWso_Cycle_f1() ... passed + Test: MFWso_GetPhysicalStateData() ... passed + Test: MFWso_GetOutputData() ... passed + Test: MFWso_GetSafeChannelOK() ... passed + +--Run Summary: Type Total Ran Passed Failed + suites 1 1 n/a 0 + tests 4 4 4 0 + asserts 54 54 54 0 + +---------------------------------------- + +Omitting the -cpu parameter results (for both versions) to hang of qemu (no output, no end, full cpu load). + + + +Your command line is badly broken: "-M integratorcp" requests a model of an integratorcp board, but "-cpu cortex-m4" tries to put an M-profile CPU in it, which is not something that board can support. In particular the resulting system model will have no NVIC in it. This only worked by accident in previous versions of QEMU. + +Ideally we should have better cpu-model compatibility checking in the board models, in which case we could print a message saying "CPU type cortex-m4 is not compatible with the integratorcp board" rather than crashing. + +If you omit -cpu you'll get the default CPU type for the board, which is an arm926. That's a sensible board+cpu combination but presumably your guest code is not built to run on that hardware, which will be why it just falls over. ("QEMU prints no output" often means "guest code has crashed or gone into an infinite loop", rather than a QEMU bug.) + +If your code needs to run on an M-profile CPU then you'll need to pick one of the M-profile board models. As of 2.11 those are lm3s6965evb, lm3s811evb, mps2-an385, mps2-an511, netduino2. + + +Thanks Peter for this information! + +I guess our code was tweaked to run with this options a long time ago - so I will have to do some investigations to get it working with a valid NVIC... + +As of writing I remember having a similar issue some time ago (which I now found to have resulted in Bug 1636126). +Sorry for not remembering this before! + diff --git a/results/classifier/108/other/1738434 b/results/classifier/108/other/1738434 new file mode 100644 index 000000000..7441ffb6c --- /dev/null +++ b/results/classifier/108/other/1738434 @@ -0,0 +1,52 @@ +socket: 0.767 +graphic: 0.763 +device: 0.757 +performance: 0.735 +network: 0.680 +vnc: 0.670 +debug: 0.661 +PID: 0.647 +files: 0.647 +other: 0.625 +permissions: 0.592 +semantic: 0.586 +KVM: 0.558 +boot: 0.530 + +CALL FWORD PTR [ESP] handled incorrectly + +To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: + + push 33h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: + + push 23h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +0x23 is a default 32-bit selector for 32-bit processes running under WoW64. + +Environment: +QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img +Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 +Host OS: Windows 10 x64 version 1703 build 15063.786 + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1738545 b/results/classifier/108/other/1738545 new file mode 100644 index 000000000..6e3eafcb4 --- /dev/null +++ b/results/classifier/108/other/1738545 @@ -0,0 +1,64 @@ +semantic: 0.656 +other: 0.631 +graphic: 0.565 +debug: 0.548 +performance: 0.429 +files: 0.363 +device: 0.311 +PID: 0.280 +vnc: 0.261 +network: 0.235 +boot: 0.229 +permissions: 0.204 +socket: 0.197 +KVM: 0.136 + +Go binaries panic with "mmap errno 9" on qemu-user + +Go binaries panic with "mmap errno 9" on qemu-user. + +root@nofan:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} +root@nofan:/# gccgo-7 hello.go -o hello +root@nofan:/# ./hello +mmap errno 9 +fatal error: mmap + +runtime stack: +mmap errno 9 +fatal error: mmap +panic during panic + +runtime stack: +mmap errno 9 +fatal error: mmap +stack trace unavailable +root@nofan:/# + +Tested with qemu from git master with Debian unstable for armel. + +Same binaries work fine on real hardware. + +With current QEMU (and in particular with 4.1.0 rc3 or later with commit 5bfce0b74fbd5d5308 that fixes sigaltstack) go binaries work OK. I think we must have fixed this mmap issue at some point between when this bug was reported and now (or possibly the go runtime was made a bit more forgiving of QEMU's eccentricities). + + +Oh, that's interesting. I will verify this and if it indeed works, I will enable Go binaries for sh4 in Debian. + +Thanks a lot for the update! + +I haven't tested sh4 specifically, but arm (subject of this bug report) definitely works, as does arm64. + + +I can confirm that the issue has been resolved on arm. Unfortunately, on sh4, the Go binaries are still crashing, albeit differently now. I verified that they work fine on real sh4 hardware. + +Could you file a separate bug for the sh4 case, then, please (with repro instructions)? + + +I'm marking this bug as "fix released" now since the Arm problem has been fixed. If there is something else to do for sh4, please open a new bug as suggested by Peter. + diff --git a/results/classifier/108/other/1738767 b/results/classifier/108/other/1738767 new file mode 100644 index 000000000..cf6e87bf6 --- /dev/null +++ b/results/classifier/108/other/1738767 @@ -0,0 +1,43 @@ +graphic: 0.769 +device: 0.733 +semantic: 0.718 +files: 0.669 +other: 0.661 +socket: 0.635 +network: 0.632 +performance: 0.625 +vnc: 0.505 +PID: 0.503 +permissions: 0.488 +boot: 0.470 +debug: 0.366 +KVM: 0.308 + +Cannot build QEMU on RHEL6 because of MAP_HUGETLB + +Hello, +I've just downloaded qemu-2.11.0 sources and I wanted to build QEMU on RHEL6 x86_64, for various targets, amonst which arm-linux-user. + +The build fails because /usr/include/bits/mman.h does not define MAP_HUGETLB. + +I think it is needed since commit 541e16904. + +I'm not sure if RHEL6 is still supported by QEMU? If so, can you fix this problem? + +Thanks + +I think we can close this bug: the build fails on RHEL6.4, but succeeded on RHEL6.7. + +Probably related to: https://access.redhat.com/solutions/320613 + +This was fixed by the distro updating their glibc-headers pakcage: + +* Tue Jul 23 2013 Alexandre Oliva <email address hidden> - 2.12-1.119 +- Add MAP_HUGETLB and MAP_STACK support (#916986). +- Update translation for stale file handle error (#970776). + +The build works in the current centos6 docker image and has been confirmed to build on later RHEL6 (RHEL6.7). + +OK, since we work on more recent RHEL6 and the submitter is happy with that, let's close this bug as WONTFIX. + + diff --git a/results/classifier/108/other/1738771 b/results/classifier/108/other/1738771 new file mode 100644 index 000000000..a43348dba --- /dev/null +++ b/results/classifier/108/other/1738771 @@ -0,0 +1,38 @@ +device: 0.847 +files: 0.723 +performance: 0.646 +permissions: 0.616 +socket: 0.606 +semantic: 0.604 +graphic: 0.574 +network: 0.559 +other: 0.554 +PID: 0.514 +vnc: 0.495 +boot: 0.472 +debug: 0.277 +KVM: 0.134 + +qemu user does not provide AT_SECURE auxiliary vector entry + +When executing an android native binary using qemu in user mode, the program fail with the message + +FATAL: kernel did not supply AT_SECURE + +Android uses bionic libc.The linker requires that AT_SECURE is provided in the auxiliary vector, but qemu does not provide the entry. + +The issue can be reproduced using the commands: + +mkdir -p /tmp/android/system +cd /tmp/android +curl -O https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip +unzip sysimg_x86-21_r15.zip +mount -o loop x86/system.img system +qemu-i386 -L /tmp/android/ system/bin/ls + + +I've provided a patch (https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix the issue, but it was not reviewed yet. + +A patch to add AT_SECURE went in and was released in QEMU 2.12. + + diff --git a/results/classifier/108/other/1739371 b/results/classifier/108/other/1739371 new file mode 100644 index 000000000..16626a3b3 --- /dev/null +++ b/results/classifier/108/other/1739371 @@ -0,0 +1,210 @@ +vnc: 0.912 +debug: 0.902 +KVM: 0.894 +other: 0.889 +permissions: 0.889 +graphic: 0.888 +device: 0.865 +boot: 0.856 +semantic: 0.854 +performance: 0.836 +socket: 0.823 +files: 0.816 +PID: 0.805 +network: 0.794 + +qemu-system-arm snapshot loadvm core dumped + +Ubuntu Qemu is crashing trying to restore saved snapshot in qemu-system-arm. +I've tried different guests kernels, but I wasn't lucky with any of them. + +The guest vm boots and I can use it normally. The issue is when I save the snapshot using "savevm Base0", "quit" and then I restore that snapshot using "-loadvm Base0" from the cmd line. + +The only difference I've noticed is tweaking the guest memory: +* With -m 512 or 1024 it crashes as you can see below. +* With -m 2048 it doesn't crash, it restores the vm and I can see the screen as it was, but the OS is halted. And it's not just the keyboard. I've tried saving the snapshot while it's booting with lot of lines being printed on screen and after restoring it, the OS is frozen. + +I also tried limiting the guest kernel memory using the mem parameter (mem=2048M) and disabling the kernel address space randomization (nokaslr) with the same results. + +OS: Ubuntu 16.04.3 LTS (xenial) + +$ qemu-system-arm --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2003-2008 Fabrice Bellard + +$ qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 512 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb -loadvm Base0 +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument +qemu: fatal: Trying to execute code outside RAM or ROM at 0xc0321568 + +R00=00000001 R01=00000000 R02=00000000 R03=c0321560 +R04=c1500000 R05=c150529c R06=c1505234 R07=c14384d0 +R08=00000000 R09=00000000 R10=c1501f50 R11=c1501f3c +R12=c1501f40 R13=c1501f30 R14=c030a184 R15=c0321568 +PSR=60070093 -ZC- A S svc32 +s00=6374652f s01=636f6c2f d00=636f6c2f6374652f +s02=7273752f s03=6962732f d01=6962732f7273752f +s04=6e612f6e s05=6f726361 d02=6f7263616e612f6e +s06=7c7c206e s07=63202820 d03=632028207c7c206e +s08=202f2064 s09=72202626 d04=72202626202f2064 +s10=702d6e75 s11=73747261 d05=73747261702d6e75 +s12=722d2d20 s13=726f7065 d06=726f7065722d2d20 +s14=652f2074 s15=632f6374 d07=632f6374652f2074 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +Aborted (core dumped) + +As I said above, the same happens when -m 1024 is used. + +I have a different issue when I use the qemu git master version, but I'm submiting a different ticket for that. + +Cheers, +Gus + +I suspect this is the same underlying state save/restore bug as your other LP:1739378 -- it's just that since 2.5.0 we've improved the error reporting for cases where the incoming migration state doesn't match what we're expecting, so we report an error message rather than just mangling the simulation state and causing the guest to crash on restart. + + +Thanks Peter for your prompt response. + +I wonder if you have any plan of fixing it. Also if there is any workaround. + +Is the bug limited to arm? Is there any main ticket where I can follow the +progress of this issue? + +On Thu., 21 Dec. 2017, 2:50 am Peter Maydell, <email address hidden> +wrote: + +> I suspect this is the same underlying state save/restore bug as your +> other LP:1739378 -- it's just that since 2.5.0 we've improved the error +> reporting for cases where the incoming migration state doesn't match +> what we're expecting, so we report an error message rather than just +> mangling the simulation state and causing the guest to crash on restart. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1739371 +> +> Title: +> qemu-system-arm snapshot loadvm core dumped +> +> Status in QEMU: +> New +> +> Bug description: +> Ubuntu Qemu is crashing trying to restore saved snapshot in +> qemu-system-arm. +> I've tried different guests kernels, but I wasn't lucky with any of them. +> +> The guest vm boots and I can use it normally. The issue is when I save +> the snapshot using "savevm Base0", "quit" and then I restore that +> snapshot using "-loadvm Base0" from the cmd line. +> +> The only difference I've noticed is tweaking the guest memory: +> * With -m 512 or 1024 it crashes as you can see below. +> * With -m 2048 it doesn't crash, it restores the vm and I can see the +> screen as it was, but the OS is halted. And it's not just the keyboard. +> I've tried saving the snapshot while it's booting with lot of lines being +> printed on screen and after restoring it, the OS is frozen. +> +> I also tried limiting the guest kernel memory using the mem parameter +> (mem=2048M) and disabling the kernel address space randomization +> (nokaslr) with the same results. +> +> OS: Ubuntu 16.04.3 LTS (xenial) +> +> $ qemu-system-arm --version +> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright +> (c) 2003-2008 Fabrice Bellard +> +> $ qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd +> kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 512 -append +> 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb +> device-tree/vexpress-v2p-ca15-tc1.dtb -loadvm Base0 +> pulseaudio: set_sink_input_volume() failed +> pulseaudio: Reason: Invalid argument +> pulseaudio: set_sink_input_mute() failed +> pulseaudio: Reason: Invalid argument +> qemu: fatal: Trying to execute code outside RAM or ROM at 0xc0321568 +> +> R00=00000001 R01=00000000 R02=00000000 R03=c0321560 +> R04=c1500000 R05=c150529c R06=c1505234 R07=c14384d0 +> R08=00000000 R09=00000000 R10=c1501f50 R11=c1501f3c +> R12=c1501f40 R13=c1501f30 R14=c030a184 R15=c0321568 +> PSR=60070093 -ZC- A S svc32 +> s00=6374652f s01=636f6c2f d00=636f6c2f6374652f +> s02=7273752f s03=6962732f d01=6962732f7273752f +> s04=6e612f6e s05=6f726361 d02=6f7263616e612f6e +> s06=7c7c206e s07=63202820 d03=632028207c7c206e +> s08=202f2064 s09=72202626 d04=72202626202f2064 +> s10=702d6e75 s11=73747261 d05=73747261702d6e75 +> s12=722d2d20 s13=726f7065 d06=726f7065722d2d20 +> s14=652f2074 s15=632f6374 d07=632f6374652f2074 +> s16=00000000 s17=00000000 d08=0000000000000000 +> s18=00000000 s19=00000000 d09=0000000000000000 +> s20=00000000 s21=00000000 d10=0000000000000000 +> s22=00000000 s23=00000000 d11=0000000000000000 +> s24=00000000 s25=00000000 d12=0000000000000000 +> s26=00000000 s27=00000000 d13=0000000000000000 +> s28=00000000 s29=00000000 d14=0000000000000000 +> s30=00000000 s31=00000000 d15=0000000000000000 +> s32=00000000 s33=00000000 d16=0000000000000000 +> s34=00000000 s35=00000000 d17=0000000000000000 +> s36=00000000 s37=00000000 d18=0000000000000000 +> s38=00000000 s39=00000000 d19=0000000000000000 +> s40=00000000 s41=00000000 d20=0000000000000000 +> s42=00000000 s43=00000000 d21=0000000000000000 +> s44=00000000 s45=00000000 d22=0000000000000000 +> s46=00000000 s47=00000000 d23=0000000000000000 +> s48=00000000 s49=00000000 d24=0000000000000000 +> s50=00000000 s51=00000000 d25=0000000000000000 +> s52=00000000 s53=00000000 d26=0000000000000000 +> s54=00000000 s55=00000000 d27=0000000000000000 +> s56=00000000 s57=00000000 d28=0000000000000000 +> s58=00000000 s59=00000000 d29=0000000000000000 +> s60=00000000 s61=00000000 d30=0000000000000000 +> s62=00000000 s63=00000000 d31=0000000000000000 +> FPSCR: 00000000 +> Aborted (core dumped) +> +> As I said above, the same happens when -m 1024 is used. +> +> I have a different issue when I use the qemu git master version, but +> I'm submiting a different ticket for that. +> +> Cheers, +> Gus +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1739371/+subscriptions +> + + +I'm going to close this bug as a duplicate of #1739378 (as noted in my earlier comment). + + + diff --git a/results/classifier/108/other/1739413 b/results/classifier/108/other/1739413 new file mode 100644 index 000000000..fb0caa44a --- /dev/null +++ b/results/classifier/108/other/1739413 @@ -0,0 +1,72 @@ +graphic: 0.770 +performance: 0.670 +semantic: 0.622 +socket: 0.595 +device: 0.594 +PID: 0.573 +files: 0.533 +other: 0.499 +permissions: 0.472 +network: 0.464 +vnc: 0.460 +boot: 0.396 +KVM: 0.352 +debug: 0.319 + +Hotplugged vcpu does not guarantee cpu compat mode(power8) on power9 host + +./ppc64-softmmu/qemu-system-ppc64 -version +QEMU emulator version 2.11.50 (v2.11.0-254-gaf35267) + +1. Boot a power8 compat mode guest power9 HW. +./ppc64-softmmu/qemu-system-ppc64 -machine pseries,accel=kvm,max-cpu-compat=power8 -m 4096 /home/sath/images/guest.qcow2 -smp 1,maxcpus=2 -serial /dev/pts/8 -monitor stdio -vga none -nographic +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) + +2. Check for cpuinfo + +# cat /proc/cpuinfo +processor : 0 +cpu : POWER8 (architected), altivec supported +clock : 2200.000000MHz +revision : 2.1 (pvr 004e 1201) + +timebase : 512000000 +platform : pSeries +model : IBM pSeries (emulated by qemu) +machine : CHRP IBM pSeries (emulated by qemu) +MMU : Hash + + +3. Run a small program invoking isa v3.0 instruction, it should complain 'Illegal instruction' as it is a power8 compat guest +# cat 1.c +#include <stdio.h> +void main() + { + asm volatile (".long 0x7c0005e6"); + } +# ./a.out +[ 59.352795] a.out[1741]: unhandled signal 4 at 0000000010000600 nip 0000000010000600 lr 00007fffb4da5080 code 1 +Illegal instruction + +4. Hotplug a vcpu +(qemu) device_add host-spapr-cpu-core,id=core1,core-id=1 +(qemu) info cpus +* CPU #0: nip=0xc0000000000de42c thread_id=113110 + CPU #1: nip=0xc0000000000de42c thread_id=113348 + +5. Try running the same program in the hotplugged vcpu and it does not complain as 'Illegal instruction' + +#taskset -c 1 ./a.out ----------------------NOK +# + +# taskset -c 0 ./a.out +[ 356.618031] a.out[1755]: unhandled signal 4 at 0000000010000600 nip 0000000010000600 lr 00007fffae7f5080 code 1 +Illegal instruction + +Upstream patch from David Gibson @ https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00587.html + +David's patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=51f84465dd985fc21589b2e + + |