diff options
Diffstat (limited to 'results/classifier/zero-shot/105/boot')
133 files changed, 10373 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/boot/1018 b/results/classifier/zero-shot/105/boot/1018 new file mode 100644 index 000000000..950f342ca --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1018 @@ -0,0 +1,36 @@ +instruction: 0.940 +boot: 0.934 +device: 0.929 +graphic: 0.852 +semantic: 0.755 +assembly: 0.742 +vnc: 0.722 +socket: 0.554 +mistranslation: 0.462 +other: 0.436 +KVM: 0.411 +network: 0.375 + +virtio-scsi-pci with iothread results in 100% CPU in qemu 7.0.0 +Description of problem: +Top reports constant 100% host CPU usage by `qemu-system-x86`. I have narrowed the issue down to the following section of the config: +``` + -object iothread,id=t0 \ + -device virtio-scsi-pci,iothread=t0,num_queues=4 \ +``` +If this is replaced by +``` + -device virtio-scsi-pci \ +``` +Then CPU usage is normal (near 0%). + +This problem doesn't appear with qemu 6.2.0 where CPU usage is near 0% even with iothread in the qemu options. +Steps to reproduce: +1. Download Kubuntu 22.04 LTS ISO (https://cdimage.ubuntu.com/kubuntu/releases/22.04/release/kubuntu-22.04-desktop-amd64.iso), +2. Create a root virtual drive for the guest with 'qemu-img create -f qcow2 -o cluster_size=4k kubuntu.img 256G', +3. Start the guest with the config given above, +4. Connect to the guest (using spicy for example, password 'p'), select "try kubuntu" in grub menu AND later in the GUI, let it boot to plasma desktop, monitor host CPU usage using 'top'. + +(there could be a faster way to reproduce it) +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/1021649 b/results/classifier/zero-shot/105/boot/1021649 new file mode 100644 index 000000000..89196e2cc --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1021649 @@ -0,0 +1,125 @@ +boot: 0.928 +device: 0.909 +assembly: 0.902 +vnc: 0.894 +other: 0.890 +graphic: 0.888 +instruction: 0.867 +mistranslation: 0.865 +socket: 0.859 +semantic: 0.857 +network: 0.834 +KVM: 0.827 + +qemu 1.1.0 waits for a keypress at boot + +qemu 1.1.0 waits for a keypress at boot. Please don't ever do this. + +Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard. + +Removing -nographic fixes the problem. + +Using virtio-scsi instead of virtio-blk fixes the problem. + + + +Also affects upstream qemu from git. + +Using -device sga fixes the problem, but also means I cannot see what it's trying to wait for. + +I don't see this problem. Are you sure you're not using the bios from Fedora? Perhaps it's configured incorrectly. + +Yes, I tested it again and it does look like it's loading a Fedora ROM. Dammit ... + +This is a bit more interesting. I've got a bugreport in debian about the same thing, and verified it in debian qemu-kvm package - indeed, with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without an extra keypress, but only when kernel_irqchip is enabled. Ie, the following requires keypress: + + qemu -machine pc,accel=kvm,kernel_irqchip=on -nographics + qemu-kvm -nographics + +and the following does not: + + qemu -machine pc,accel=kvm -nographics + qemu-kvm -no-kvm-irqchip -nographics + +Thanks, + +/mjt + + +Well that's very interesting because one of the patches we have added in Fedora is: + +http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=0001-qemu-kvm-Add-missing-default-machine-options.patch;h=e785a708d0bf0861c2f0f1777b8cc477d12fe145;hb=HEAD + +when the guest is waiting for the keypress, it is sitting in KVM_RUN ioctl and eating 100% CPU. When enabling Seabios debugging, the last lines before the stall is this: + +Returned 57344 bytes of ZoneHigh +e820 map has 7 items: + 0: 0000000000000000 - 000000000009dc00 = 1 RAM + 1: 000000000009dc00 - 00000000000a0000 = 2 RESERVED + 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED + 3: 0000000000100000 - 000000001fffe000 = 1 RAM + 4: 000000001fffe000 - 0000000020000000 = 2 RESERVED + 5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED + 6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED +enter handle_19: + NULL +Booting from Hard Disk... +_ + + +So far it only happens when "booting" from a VIRTIO hard disk. With IDE disk it boots fine. + +So, in order for it to actually stall, + + qemu -machine pc,accel=kvm,kernel_irqchip=on -drive file=foo,if=virtio -nographics + +is needed. + +Thanks, + +/mjt + + +Jamie Heilman (the debian bug #680719 reporter) bisected this issue to this commit: + +7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit +commit 7c7db75576bd5a31508208f153c5aada64b2c8df +Author: Stefano Stabellini <email address hidden> +Date: Fri Apr 13 19:35:04 2012 +0100 + + main_loop_wait: block indefinitely + + - remove qemu_calculate_timeout; + + - explicitly size timeout to uint32_t; + + - introduce slirp_update_timeout; + + - pass NULL as timeout argument to select in case timeout is the maximum + value; + + Signed-off-by: Stefano Stabellini <email address hidden> + Acked-by: Paul Brook <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + + +I encountered the same thing and created a patch that fixes the problem for me. + +This is not a real fix. All i have done is the following: +- Clone the repo. +- Get a reverse diff for the commit in question "git diff 7c7db75..4ffd16f >foo1.patch". +- Try to apply this on master "patch <foo1.patch" and skip all files that could not be found. +- And finally do a "git diff >remove-7c7db75.patch" + +As i am a gentoo user i applied this patch within my ebuild and + +This is definitely a wrong way to "fix" this issue. + +The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828 fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to the select() arguments), but I and Avi disagreed on whether ioeventfd=off works. :) + +Jamie/Richard/Georg, can you test your respective reproducers without any patch but with -global virtio-blk-pci.ioeventfd=off? + +Can this issue still be reproduced with the latest version of QEMU, or can we close this bug nowadays? + +No this refers to a very old version of qemu. This bug should be closed. + diff --git a/results/classifier/zero-shot/105/boot/1026176 b/results/classifier/zero-shot/105/boot/1026176 new file mode 100644 index 000000000..08c40bb92 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1026176 @@ -0,0 +1,39 @@ +boot: 0.806 +mistranslation: 0.748 +device: 0.746 +semantic: 0.662 +graphic: 0.636 +instruction: 0.601 +other: 0.556 +network: 0.395 +assembly: 0.358 +vnc: 0.275 +socket: 0.262 +KVM: 0.197 + +unable to boot squashfs through mtd device + +Hi, + +I have built latest qemu archive qemu-1.1.1 to be sure of up to date source code. +I have then built buildroot squashfs image, which can be used correctly with cmdline like: + +qemu-system-i386 -m 64 -k fr -boot c -kernel images/bzImage -drive if=ide,file=images/rootfs.squashfs -append "root=/dev/sda" + +Then I wanted to modify cmdline to use real MTD device, like: + +qemu-system-i386 -m 64 -k fr -boot c -kernel images/bzImage -drive if=mtd,file=images/rootfs.squashfs -append "root=/dev/mtdblock0". + +But nothing was good under kernel. +Even if mtd0 is reported through qemu interface (Ctrl Alt+2), no device can be found under kernel even if all drivers are built to use it. + +Is this feature okay on qemu-1.1.1 ?? +did I do mistake in my cmdline?? + +thank you for your help. +regards, + +Triaging old bug tickets... QEMU 1.1 is pretty much outdated, can we close this bug nowadays? Can you still reproduce the issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1055090 b/results/classifier/zero-shot/105/boot/1055090 new file mode 100644 index 000000000..8747d12a9 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1055090 @@ -0,0 +1,39 @@ +boot: 0.930 +instruction: 0.762 +device: 0.754 +network: 0.672 +socket: 0.585 +semantic: 0.556 +vnc: 0.541 +graphic: 0.515 +mistranslation: 0.355 +assembly: 0.345 +other: 0.334 +KVM: 0.055 + +esp error: NetBSD/sparc on qemu-system-sparc + +On qemu-1.2.0's qemu-system-sparc, NetBSD/sparc (32bit) 5.1.2 and 6.0_RC2 generates the following NetBSD's errors. + +esp0: !TC on DATA XFER [intr 18, stat 82, step 4] prevphase 2, resid 0 +esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0 + +On qemu-0.15.1's qemu-system-sparc, NetBSD/sparc 5.1.2 and 6.0_RC2 works fine. + +To reproduce with NetBSD/sparc 6.0_RC2, run + +% qemu-system-sparc -M SS-20 -m 265M -hda NetBSD-sparc-6.0_RC2.qed -nographic -cdrom NetBSD-6.0_RC2-sparc.iso -boot d + +and try to install NetBSD. You can get above errors when newfs command is invoked. +I can reporduce this problem on NetBSD/i386 (32bit) and NetBSD/amd64(64bit; x86_64) host OSes. + +NetBSD-6.0_RC2-sparc.iso is here, +ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0_RC2/images/NetBSD-6.0_RC2-sparc.iso + +NetBSD-sparc-6.0_RC2.qed is created with +% qemu-img create -f qed NetBSD-sparc-6.0_RC2.qed 3G + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU (and NetBSD)? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1074 b/results/classifier/zero-shot/105/boot/1074 new file mode 100644 index 000000000..377511f39 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1074 @@ -0,0 +1,31 @@ +boot: 0.701 +graphic: 0.671 +device: 0.660 +instruction: 0.545 +semantic: 0.543 +other: 0.525 +vnc: 0.376 +network: 0.347 +socket: 0.336 +mistranslation: 0.198 +KVM: 0.171 +assembly: 0.083 + +File under symlink gets corrupted when directory is mounted as FAT32 drive +Description of problem: +When mouting a directory as a FAT32 drive, the symlinked BOOTx64.EFI inside gets corrupted after booting it. +Steps to reproduce: +1. mkdir -p fat_dir/EFI/BOOT/ +2. ln -s BOOTx64.EFI fat_dir/EFI/BOOT/BOOTx64.EFI +3. md5sum BOOTx64.EFI +4. Run qemu with arguments like above. +5. md5sum BOOTx64.EFI should print out different hash, confirming corruption. +Additional information: +[BOOTx64.EFI](/uploads/d0a6e899ec9331461179f8dc82fbc421/BOOTx64.EFI) + +The issue was not visible on earlier versions, but I don't know which one exactly was it.\ +I can only say, it was still working in April and it was possible that I was using Fedora 36 Beta. + +Copying the file instead of using a symlink can be used as a workaround. + +The binary should print some debug stuff, like avaliable memory regions and end with an infinite halt-loop. diff --git a/results/classifier/zero-shot/105/boot/1089006 b/results/classifier/zero-shot/105/boot/1089006 new file mode 100644 index 000000000..196ad5035 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1089006 @@ -0,0 +1,198 @@ +boot: 0.870 +mistranslation: 0.866 +other: 0.862 +device: 0.850 +KVM: 0.847 +instruction: 0.843 +graphic: 0.838 +assembly: 0.832 +network: 0.828 +semantic: 0.828 +vnc: 0.812 +socket: 0.810 + +Qemu scrambles order of eth devices in vm + +HV = 12.04 LTS plus libvirt 1.0x +VM = 12.04 LTS + +On the HV there are 12 eth interfaces which we make available to the VM. We have 4 10G virtual function interfaces, and 8 1G conventionally bridged interfaces. No matter what order we present the interfaces in the xml file, they come up in eth0-eth11 order on the VM as follows: ( the interfcaes do work, once you figure out which is which) + +eth0-eth7 not in order as compoared to the bridges on the HV (interfaces file) or compared to the xml file for the VM, or compared to the bus numbers. MAC addresses are random. +eth8-eth11 show up in the VM in order of PCU bus numbers just as you'd expect, always after the bridged interfaces. + +Consulting the libvirt mailing list, the developer says they present the list in bus order to qemu, but qemu scrambles that order. That appears to me too, to be the case. + +There is really no such concept as "NIC order" at the hardware level in QEMU. NIC naming order is something that operating systems invent according to some policy they have. As far as libvirt & QEMU are concerned, you only have control over the PCI device slot numbering. The operating system may choose to number NICs based on their PCI device slot number, or something else entirely. Further after an OS has been booted once, they often record the original mapping of MAC <-> NIC names, so even if you change the PCI slot ordering on later boots, the naming won't change. + +Thank you Daniel. +I understand what you say and agree. However when presented with a mapping and an order by libvirt, shouldn't the order be preserved by default? If the OS scrambles it, then fine, not your problem... + +Are we on the right track here, is there some way to control the order as presented by Qemu when the VM's OS boots? + +If its at all helpful to understand the issue, here is our current proposed workaround: +=start 32 fresh VMs, each with 8 bridged connections and 4 82599 virtual connections= +take one generic xml file +qemu-img one default disk image +examine the HV's lspci output to find out bus numbering for the 82599 virtuals +add correct bus numbering in xml file +virsh create the xml to get randomized MAC addresses ( better ways to do this...) +save xml again +shutdown VM +> heres where the workaround occurs < +mount VM +write to /etc/udev/rules.d file to capture MAC vs PCI numbering in order of presentation for booting +etc etc + +For the benefit of 1) others and 2) me when I forget how this works- + +I did find a solution in formatting the xml file. + +If you leave the vnets out completely, see file below, the generic xml file will cooperate with libvirt and qemu and +order the VM's eth devices as they are ordered on the hypervisor. + +(note: the macvtap entries seen below may also not be needed, sound and usb not tested) + +## sample xml file for libvirt 1.0.0 showing some bridges and some SRIOV ports too ## + +<domain type='kvm' id='1'> + <name>sample</name> + <hostname>sample</hostname> + <memory unit='KiB'>524288</memory> + <currentMemory unit='KiB'>524288</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc-1.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <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='qcow2'/> + <source file='/var/lib/libvirt/images/oa4-vm-sample-cli.qcow2'/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0'> + <alias name='usb0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <source bridge='br4'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br5'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br6'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br7'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br8'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br9'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br10'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br11'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br250'/> + <model type='virtio'/> + </interface> + <interface type='hostdev'> + <source dev='eth0' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x0'/> + </source> + <target dev='macvtap1'/> + <model type='virtio'/> + </interface> + <interface type='hostdev'> + <source dev='eth1' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x1'/> + </source> + <target dev='macvtap1'/> + <model type='virtio'/> + </interface> + <interface type='hostdev'> + <source dev='eth2' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x16' slot='0x10' function='0x0'/> + </source> + <target dev='macvtap0'/> + </interface> + <interface type='hostdev'> + <source dev='eth3' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x16' slot='0x10' function='0x1'/> + </source> + <target dev='macvtap0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/1'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/1'> + <source path='/dev/pts/1'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <sound model='ich6'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <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='none'/> +</domain> + + +On 12/12/2012 11:59 AM, john fisher wrote: +> +> Are we on the right track here, is there some way to control the order +> as presented by Qemu when the VM's OS boots? +> + +-- +John Fisher + + + +Is there still something left to do here, or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1101 b/results/classifier/zero-shot/105/boot/1101 new file mode 100644 index 000000000..5009bd8cb --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1101 @@ -0,0 +1,25 @@ +boot: 0.918 +device: 0.886 +graphic: 0.777 +semantic: 0.724 +instruction: 0.562 +mistranslation: 0.514 +socket: 0.477 +vnc: 0.420 +network: 0.385 +assembly: 0.272 +other: 0.183 +KVM: 0.154 + +QEMU 7.0.0 corrupts VHDX and VHD (VPC) files on write. +Description of problem: +QEMU writes to VHDX and VHD (VPC) files produce a corrupt/non-compliant image. +QEMU appears to be able to read VHDX and VHD images correctly. + +This problem manifests in at least two cases +1. When attaching a VHDX/VHD file to a QEMU machine. A previously working OS image created using the Hyper-V and imaging tools boots properly, but writes that normally occur in the running VM are not written out correctly. The image will fail to boot the next time due to corruption. +2. Image conversion operations *TO* VHDX/VHD fail. (note that QEMU correctly converts *FROM* VHDX/VHD assuming a well formed input image). This implies that reads to VHDX/VHD are OK, but writes to VHDX/VHD are NOT OK. +Steps to reproduce: +1. See Above. +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/1119281 b/results/classifier/zero-shot/105/boot/1119281 new file mode 100644 index 000000000..3f9abd2d6 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1119281 @@ -0,0 +1,826 @@ +boot: 0.962 +semantic: 0.950 +assembly: 0.948 +other: 0.948 +device: 0.944 +network: 0.940 +socket: 0.935 +instruction: 0.930 +graphic: 0.913 +KVM: 0.890 +vnc: 0.888 +mistranslation: 0.796 + +The virtio network device breaks UuidCreateSequential() + +UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue. + +Here is the software I have tested this with: + * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) + * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. + + +Here is how to test for this issue: +* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. + +* Boot the guest and copy the uuidtest.exe file (see attachement) to it + +* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below: + + Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 + +* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0. + + UuidCreateSequential() returned 0 + uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} + Got a version 1 UUID + The UUID does not contain a non-multicast MAC address + +* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be. + +* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address. + + +(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +(2) Best do it with a single card to avoid confusion over which is the primary one. +(3) If the first byte of the address is odd then this is a multicast address. + https://en.wikipedia.org/wiki/MAC_address#Address_details + + + +On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote: +> Public bug reported: +> +> UuidCreateSequential() usually creates version 1 UUIDs (1) which means +> they contain the main network card's MAC address. However when using a +> virtio network card and driver the UUIDs contain random data instead of +> the guest's MAC address. Changing the network card to either the default +> rtl8139 one or the e1000 one fixes the issue. + +CCing Yan and Vadim, who work on the virtio-win drivers. + +> +> Here is the software I have tested this with: +> * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) +> * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ +> * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. +> +> +> Here is how to test for this issue: +> * Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. +> +> * Boot the guest and copy the uuidtest.exe file (see attachement) to it +> +> * On the command line, type 'ipconfig /all'. Give you the correct +> network card's MAC address on a line like the one below: +> +> Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 +> +> * Run uuidtest.exe. It will show the VM returning a UUID with the wrong +> MAC address, and quite possibly even a multicast MAC address! (3). In +> the example below 'f75292c62787' should have been the MAC address. Note +> that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY +> for virtio cards but that on Windows 7 it returns 0. +> +> UuidCreateSequential() returned 0 +> uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} +> Got a version 1 UUID +> The UUID does not contain a non-multicast MAC address +> +> * Reboot and notice uuidtest.exe now reports a different value where the +> MAC address should be. +> +> * Shut down the VM and switch the network card to rtl8139, install the +> drivers, run uuidtest.exe and notice that the last group of digits +> finally contains the correct MAC address. +> +> +> (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +> (2) Best do it with a single card to avoid confusion over which is the primary one. +> (3) If the first byte of the address is odd then this is a multicast address. +> https://en.wikipedia.org/wiki/MAC_address#Address_details +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "Test executable and source" +> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2 + + +On Mon, Feb 11, 2013 at 11:13 AM, Stefan Hajnoczi <email address hidden>wrote: + +> On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote: +> > Public bug reported: +> > +> > UuidCreateSequential() usually creates version 1 UUIDs (1) which means +> > they contain the main network card's MAC address. However when using a +> > virtio network card and driver the UUIDs contain random data instead of +> > the guest's MAC address. Changing the network card to either the default +> > rtl8139 one or the e1000 one fixes the issue. +> +> CCing Yan and Vadim, who work on the virtio-win drivers. +> +> > +> > Here is the software I have tested this with: +> > * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and +> Experimental respectively) +> > * The 0.1-49 and 0.1-52 Windows virtio drivers from +> https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ +> > * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. +> > +> > +> > Here is how to test for this issue: +> > * Set up a Windows guest with a single network card(2), a virtio one and +> install the corresponding driver. +> > +> > * Boot the guest and copy the uuidtest.exe file (see attachement) to it +> > +> > * On the command line, type 'ipconfig /all'. Give you the correct +> > network card's MAC address on a line like the one below: +> > +> > Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 +> > +> > * Run uuidtest.exe. It will show the VM returning a UUID with the wrong +> > MAC address, and quite possibly even a multicast MAC address! (3). In +> > the example below 'f75292c62787' should have been the MAC address. Note +> > that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY +> > for virtio cards but that on Windows 7 it returns 0. +> > +> > UuidCreateSequential() returned 0 +> > uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} +> > Got a version 1 UUID +> > The UUID does not contain a non-multicast MAC address +> > +> > * Reboot and notice uuidtest.exe now reports a different value where the +> > MAC address should be. +> > +> > * Shut down the VM and switch the network card to rtl8139, install the +> > drivers, run uuidtest.exe and notice that the last group of digits +> > finally contains the correct MAC address. +> > +> > +> > (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +> > (2) Best do it with a single card to avoid confusion over which is the +> primary one. +> > (3) If the first byte of the address is odd then this is a multicast +> address. +> > https://en.wikipedia.org/wiki/MAC_address#Address_details +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > ** Attachment added: "Test executable and source" +> > +> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2 +> + + +I did a quick check for this issue. First off all +while UuidCreateSequential should use mac address, there is no indication +that it must do it. And as we don't have source code for Rpcrt4.lib it is +hard to estimated what should be the exact behavior of this function (I can +use reactos source code - but we cannot count on it). +What I see from our debug trace that there are no OID calls to NIC while +using this function to get our current or permanent MAC address. And we +know that those OIDs work well: a. because you see correct MAC using +ipconfig of getmac (also is verified by Red Hat QE during manual functional +tests). b. We pass WHQL tests that set valid and invalid mac addresses +automatically and tests for correct behavior. So UuidCreateSequential +either takes this value from somewhere in registry or generates it by some +other mean. + +I can try and assume how it should work using ReactOS code. +From reactos UuidCreateSequential: +http://doxygen.reactos.org/df/def/rpcdce_8h_a884acec185f2f0a999a8375cd04f61c9.html +It will use GetAdaptersInfo. I ran the code in the MS documentation +http://msdn.microsoft.com/en-us/library/windows/desktop/aa365917(v=vs.85).aspx- +and once again the mac address of virtio adapter is correct. + + +Might be related: +http://support.microsoft.com/kb/981080?wa=wsignin1.0 +http://support.microsoft.com/kb/2569646 + + +Best regards, +Yan. + + +This bug is still present in QEM 1.6.0 (qemu-system-x86 1.6.0+dfsg-1) and/or Virtio 0.1-65. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + + + + + +The issue is still there in 2023. +Well since XP's source code had been leaked. I've gone through the source code and may have found the cause. + +Nowadays UuidCreateSequential should use MAC address when available. +Here I quoted from the link below: +"For security reasons, UuidCreate was modified so that it no longer uses a machine's MAC address to generate UUIDs. UuidCreateSequential was introduced to allow creation of UUIDs using the MAC address of a machine's Ethernet card." +https://learn.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidcreatesequential + +Now let take a look at XP's code: +UuidCreateSequential() in dceuuid.cxx: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/rpc/runtime/mtrt/dceuuid.cxx#L122 + +RPC_STATUS RPC_ENTRY +UuidCreateSequential ( + OUT UUID PAPI * Uuid + ) +/*++ + +Routine Description: + + This routine will create a new UUID (or GUID) which is unique in + time and space. We will try to guarantee that the UUID (or GUID) + we generate is unique in time and space. This means that this + routine may fail if we can not generate one which we can guarantee + is unique in time and space. + +Arguments: + + Uuid - Returns the generated UUID (or GUID). + +Return Value: + + RPC_S_OK - The operation completed successfully. + + RPC_S_UUID_NO_ADDRESS - We were unable to obtain the ethernet or + token ring address for this machine. + + RPC_S_UUID_LOCAL_ONLY - On NT & Chicago if we can't get a + network address. This is a warning to the user, the + UUID is still valid, it just may not be unique on other machines. + + RPC_S_OUT_OF_MEMORY - Returned as needed. +--*/ +{ + RPC_UUID_GENERATE PAPI * RpcUuid = (RPC_UUID_GENERATE PAPI *) Uuid; + RPC_STATUS Status = RPC_S_OK; + static DWORD LastTickCount = 0; + + InitializeIfNecessary(); + + if (GetTickCount()-LastTickCount > MAX_CACHED_UUID_TIME) + { + UuidCachedValues.AllocatedCount = 0; + LastTickCount = GetTickCount(); + } + + ULARGE_INTEGER Time; + long Delta; + + for(;;) + { + Time.QuadPart = UuidCachedValues.Time.QuadPart; + + // Copy the static info into the UUID. We can't do this later + // because the clock sequence could be updated by another thread. + + *(unsigned long *)&RpcUuid->ClockSeqHiAndReserved = + *(unsigned long *)&UuidCachedValues.ClockSeqHiAndReserved; + *(unsigned long *)&RpcUuid->NodeId[2] = + *(unsigned long *)&UuidCachedValues.NodeId[2]; + + Delta = InterlockedDecrement(&UuidCachedValues.AllocatedCount); + + if (Time.QuadPart != UuidCachedValues.Time.QuadPart) + { + // If our captured time doesn't match the cache then another + // thread already took the lock and updated the cache. We'll + // just loop and try again. + continue; + } + + if (Delta >= 0) + { + break; + } + + // + // Allocate block of Uuids. + // + + Status = UuidGetValues( &UuidCachedValues ); + if (Status == RPC_S_OK) + { + UuidCacheValid = CACHE_VALID; + } + else + { + UuidCacheValid = CACHE_LOCAL_ONLY; + } + + if (Status != RPC_S_OK + && Status != RPC_S_UUID_LOCAL_ONLY) + { +#ifdef DEBUGRPC + if (Status != RPC_S_OUT_OF_MEMORY) + PrintToDebugger("RPC: UuidGetValues returned or raised: %x\n", Status); +#endif + ASSERT( (Status == RPC_S_OUT_OF_MEMORY) ); + + + return Status; + } + + // Loop + } + + + Time.QuadPart -= Delta; + + RpcUuid->TimeLow = (unsigned long) Time.LowPart; + RpcUuid->TimeMid = (unsigned short) (Time.HighPart & 0x0000FFFF); + RpcUuid->TimeHiAndVersion = (unsigned short) + (( (unsigned short)(Time.HighPart >> 16) + & RPC_UUID_TIME_HIGH_MASK) | RPC_UUID_VERSION); + + ASSERT( Status == RPC_S_OK + || Status == RPC_S_UUID_LOCAL_ONLY); + + if (UuidCacheValid == CACHE_LOCAL_ONLY) + { + return RPC_S_UUID_LOCAL_ONLY; + } + + return(Status); +} + +UuidGetValues() in uuidsup.cxx: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/rpc/runtime/mtrt/uuidsup.cxx#L43 + +UuidGetValues( + OUT UUID_CACHED_VALUES_STRUCT __RPC_FAR *Values + ) +/*++ + +Routine Description: + + This routine allocates a block of uuids for UuidCreate to handout. + +Arguments: + + Values - Set to contain everything needed to allocate a block of uuids. + The following fields will be updated here: + + NextTimeLow - Together with LastTimeLow, this denotes the boundaries + of a block of Uuids. The values between NextTimeLow + and LastTimeLow are used in a sequence of Uuids returned + by UuidCreate(). + + LastTimeLow - See NextTimeLow. + + ClockSequence - Clock sequence field in the uuid. This is changed + when the clock is set backward. + +Return Value: + + RPC_S_OK - We successfully allocated a block of uuids. + + RPC_S_OUT_OF_MEMORY - As needed. +--*/ +{ + NTSTATUS NtStatus; + ULARGE_INTEGER Time; + ULONG Range; + ULONG Sequence; + int Tries = 0; + + do { + NtStatus = NtAllocateUuids(&Time, &Range, &Sequence, (char *) &Values->NodeId[0]); + + if (NtStatus == STATUS_RETRY) + { + Sleep(1); + } + + Tries++; + + if (Tries == 20) + { +#ifdef DEBUGRPC + PrintToDebugger("Rpc: NtAllocateUuids retried 20 times!\n"); + ASSERT(Tries < 20); +#endif + NtStatus = STATUS_UNSUCCESSFUL; + } + + } while(NtStatus == STATUS_RETRY); + + if (!NT_SUCCESS(NtStatus)) + { + return(RPC_S_OUT_OF_MEMORY); + } + + // NtAllocateUuids keeps time in SYSTEM_TIME format which is 100ns ticks since + // Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582. + + // 17 Days in Oct + 30 (Nov) + 31 (Dec) + 18 years and 5 leap days. + + Time.QuadPart += (unsigned __int64) (1000*1000*10) // seconds + * (unsigned __int64) (60 * 60 * 24) // days + * (unsigned __int64) (17+30+31+365*18+5); // # of days + + ASSERT(Range); + + Values->ClockSeqHiAndReserved = + RPC_UUID_RESERVED | (((unsigned char) (Sequence >> 8)) + & (unsigned char) RPC_UUID_CLOCK_SEQ_HI_MASK); + + Values->ClockSeqLow = (unsigned char) (Sequence & 0x00FF); + + // The order of these assignments is important + + Values->Time.QuadPart = Time.QuadPart + (Range - 1); + Values->AllocatedCount = Range; + + if ((Values->NodeId[0] & 0x80) == 0) + { + return(RPC_S_OK); + } + + return (RPC_S_UUID_LOCAL_ONLY); +} + + +NtAllocateUuids() in uuid.c: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/base/ntos/ex/uuid.c#L545 + +/*++ + +Copyright (c) 1994-1997 Microsoft Corporation + +Module Name: + + uuid.c + +Abstract: + + This module implements the core time and sequence number allocation + for UUIDs (exposed to user mode), as well as complete UUID + creation (exposed to kernel mode only). + + (e.g. RPC Runtime) (e.g. NTFS) + | | + V V + NtAllocateUuids ExUuidCreate + | | + V V + | ExpUuidGetValues + | | + | | + +------> ExpAllocateUuids <----+ +NTSTATUS +NtAllocateUuids ( + OUT PULARGE_INTEGER Time, + OUT PULONG Range, + OUT PULONG Sequence, + OUT PCHAR Seed + ) + +/*++ + +Routine Description: + + This function reserves a range of time for the caller(s) to use for + handing out Uuids. As far a possible the same range of time and + sequence number will never be given out. + + (It's possible to reboot 2^14-1 times and set the clock backwards and then + call this allocator and get a duplicate. Since only the low 14bits of the + sequence number are used in a real uuid.) + +Arguments: + + Time - Supplies the address of a variable that will receive the + start time (SYSTEMTIME format) of the range of time reserved. + + Range - Supplies the address of a variable that will receive the + number of ticks (100ns) reserved after the value in Time. + The range reserved is *Time to (*Time + *Range - 1). + + Sequence - Supplies the address of a variable that will receive + the time sequence number. This value is used with the associated + range of time to prevent problems with clocks going backwards. + + Seed - Pointer to a 6 byte buffer. The current seed is written into this buffer. + +Return Value: + + STATUS_SUCCESS is returned if the service is successfully executed. + + STATUS_RETRY is returned if we're unable to reserve a range of + UUIDs. This may (?) occur if system clock hasn't advanced + and the allocator is out of cached values. + + STATUS_ACCESS_VIOLATION is returned if the output parameter for the + UUID cannot be written. + + STATUS_UNSUCCESSFUL is returned if some other service reports + an error, most likly the registery. + +--*/ + +{ + + KPROCESSOR_MODE PreviousMode; + NTSTATUS Status; + + LARGE_INTEGER OutputTime; + ULONG OutputRange; + ULONG OutputSequence; + PKTHREAD CurrentThread; + + PAGED_CODE(); + + // + // Establish an exception handler and attempt to write the output + // arguments. If the write attempt fails, then return + // the exception code as the service status. Otherwise return success + // as the service status. + // + + try { + + // + // Get previous processor mode and probe arguments if necessary. + // + + PreviousMode = KeGetPreviousMode(); + if (PreviousMode != KernelMode) { + ProbeForWriteSmallStructure((PVOID)Time, sizeof(LARGE_INTEGER), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Range, sizeof(ULONG), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Sequence, sizeof(ULONG), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Seed, SEED_SIZE, sizeof(CHAR)); + } + } except (ExSystemExceptionFilter()) { + return GetExceptionCode(); + } + + // Take the lock, because we're about to update the UUID cache. + CurrentThread = KeGetCurrentThread (); + KeEnterCriticalRegionThread(CurrentThread); + ExAcquireFastMutexUnsafe(&ExpUuidLock); + + // Get the sequence number and a range of times that can + // be used in UUID-generation. + + Status = ExpAllocateUuids( &OutputTime, &OutputRange, &OutputSequence ); + + if( !NT_SUCCESS(Status) ) { + ExReleaseFastMutexUnsafe(&ExpUuidLock); + KeLeaveCriticalRegionThread(CurrentThread); + return( Status ); + } + + // If necessary, save the sequence number. If there's an error, + // we'll just leave it marked as dirty, and retry on some future call. + + ExpUuidSaveSequenceNumberIf(); + + // Release the lock + ExReleaseFastMutexUnsafe(&ExpUuidLock); + KeLeaveCriticalRegionThread(CurrentThread); + + // + // Attempt to store the result of this call into the output parameters. + // This is done within an exception handler in case output parameters + // are now invalid. + // + + try { + Time->QuadPart = OutputTime.QuadPart; + *Range = OutputRange; + *Sequence = OutputSequence; + RtlCopyMemory((PVOID) Seed, &ExpUuidCachedValues.NodeId[0], SEED_SIZE); + } except (ExSystemExceptionFilter()) { + return GetExceptionCode(); + } + + return(STATUS_SUCCESS); +} + + +NTSTATUS +NtSetUuidSeed ( + IN PCHAR Seed + ) +/*++ + +Routine Description: + + This routine is used to set the seed used for UUID generation. The seed + will be set by RPCSS at startup and each time a card is replaced. + +Arguments: + + Seed - Pointer to a six byte buffer + +Return Value: + + STATUS_SUCCESS is returned if the service is successfully executed. + + STATUS_ACCESS_DENIED If caller doesn't have the permissions to make this call. + You need to be logged on as Local System in order to call this API. + + STATUS_ACCESS_VIOLATION is returned if the Seed could not be read. + +--*/ +{ + NTSTATUS Status; + LUID AuthenticationId; + SECURITY_SUBJECT_CONTEXT SubjectContext; + LUID SystemLuid = SYSTEM_LUID; + BOOLEAN CapturedSubjectContext = FALSE; + + PAGED_CODE(); + + ASSERT(KeGetPreviousMode() != KernelMode); + + try { + // + // Check if the caller has the appropriate permission + // + SeCaptureSubjectContext(&SubjectContext); + CapturedSubjectContext = TRUE; + + Status = SeQueryAuthenticationIdToken( + SeQuerySubjectContextToken(&SubjectContext), + &AuthenticationId); + if (!NT_SUCCESS(Status)) { + ExRaiseStatus(Status); + } + + if (RtlCompareMemory(&AuthenticationId, &SystemLuid, sizeof(LUID)) != sizeof(LUID)) { + ExRaiseStatus(STATUS_ACCESS_DENIED); + } + + // + // Store the UUID seed + // + ProbeForReadSmallStructure(Seed, SEED_SIZE, sizeof(CHAR)); + RtlCopyMemory(&ExpUuidCachedValues.NodeId[0], Seed, SEED_SIZE); + + if ((Seed[0] & 0x80) == 0) + { + // If the high bit is not set the NodeId is a valid IEEE 802 + // address and should be globally unique. + ExpUuidCacheValid = CACHE_VALID; + } + else + { + ExpUuidCacheValid = CACHE_LOCAL_ONLY; + } + + Status = STATUS_SUCCESS; + } + except (EXCEPTION_EXECUTE_HANDLER) { + Status = GetExceptionCode(); + } + + if (CapturedSubjectContext) { + SeReleaseSubjectContext( &SubjectContext ); + } + + return Status; +} + + + +start.cxx: + +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/ole32/dcomss/wrapper/start.cxx#L282C23-L282C41 + +/*++ + +Copyright (c) 1995 Microsoft Corporation + +Module Name: + + Start.c + +Abstract: + + Process init and service controller interaction for dcomss.exe + +Author: + + Mario Goertzel [MarioGo] + +Revision History: + + MarioGo 06-14-95 Cloned from the old endpoint mapper. + MazharM 10-12.98 Add pnp stuff + TarunA 12-11-98 Removed pnpmngr.h + a-sergiv 25-08-99 Defined gC2Security for process-wide use + +--*/ +DealWithDeviceEvent() +/*++ +Function Name: DealWithDeviceEvent + +Parameters: + +Description: + +Returns: + +--*/ +{ + UCHAR MacAddress[8]; + NTSTATUS NtStatus; + + if (getMacAddress(&MacAddress[0])) + { + NtStatus = NtSetUuidSeed((PCHAR) &MacAddress[0]); + } + else + { + CookupNodeId(&MacAddress[0]); + + ASSERT(MacAddress[0] & 0x80); + + NtStatus = NtSetUuidSeed((PCHAR) &MacAddress[0]); + } + + if (!NT_SUCCESS(NtStatus)) + { + #if DBG + DbgPrint("NtSetUuidSeed failed\n", NtStatus); + #endif + } + +#if !defined(SPX_IPX_OFF) + UpdateSap( SAP_CTRL_UPDATE_ADDRESS ); +#endif +} + + +getMacAddress ( + PUCHAR pMacAddress + ) +/*++ +Function Name:getMacAddress + +Parameters: + +Description: + +Returns: + +--*/ +{ + int i; + UINT fStatus; + int Size = 1024*5; + PNDIS_ENUM_INTF Interfaces; + UCHAR OidVendData[16]; + + Interfaces = (PNDIS_ENUM_INTF) I_RpcAllocate (Size); + if (Interfaces == 0) + { + return FALSE; + } + + if (NdisEnumerateInterfaces(Interfaces, Size)) + { + UINT i; + + for (i = 0; i < Interfaces->TotalInterfaces; i++) + { + PUNICODE_STRING pDeviceName= &(Interfaces->Interface[i].DeviceName); + UCHAR PermMacAddr[6]; + + fStatus = NdisQueryHwAddress(pDeviceName, pMacAddress, PermMacAddr, &OidVendData[0]); + if (fStatus && (OidVendData[0] != 0xFF + || OidVendData[1] != 0xFF + || OidVendData[2] != 0xFF)) + { + I_RpcFree (Interfaces); + + return TRUE; + } + } + } + + I_RpcFree (Interfaces); + + return FALSE; +} + +As we can see in DealWithDeviceEvent() which is realted to UuidCreateSequential(it use the seed as the last 48 bits of uuid), the it calls getMacAddress to obtain MAC address. If OidVendorData's first 6 bytes is 0xff, the function will fail, casing a random value generated rather than the mac of our adapter. So I guess its related to the virtio implementation. But I can't identify where the OidVendData is defined. So I think I should file an issue to virtio dev teams too. + +For those encountered this problem: +This is not a bug. Instead, it is the exepected behaviour. +Refer to: +https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1017 + diff --git a/results/classifier/zero-shot/105/boot/1129957 b/results/classifier/zero-shot/105/boot/1129957 new file mode 100644 index 000000000..49b25c3d5 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1129957 @@ -0,0 +1,66 @@ +boot: 0.818 +graphic: 0.755 +device: 0.678 +vnc: 0.658 +semantic: 0.449 +instruction: 0.436 +socket: 0.404 +network: 0.381 +other: 0.330 +mistranslation: 0.253 +assembly: 0.212 +KVM: 0.130 + +Performance issue running quest image on qemu compiled for Win32 platform + +I'm seeing performance issues when booting a guest image on qemu 1.4.0 compiled for the Win32 platform. +The same image boots a lot faster on the same computer running qemu/linux on Fedora via VmWare, and even running the Win32 exectuable via Wine performs better than running qemu natively on Win32. + +Although I'm not the author of the image, it is located here: +http://people.freebsd.org/~wpaul/qemu/vxworks.img + +All testing has been done on QEMU 1.4.0. + +I'm also attaching a couple of gprof logs. For these I have disabled ssp in qemu by removing "-fstack-protector-all" and "-D_FORTIFY_SOURCE=2" from the qemu configure script. + +qemu-perf-linux.txt +================ +Machine - Windows XP - VmWare - Fedora - QEMU + +qemu-perf-win32.txt +================= +Machine - Windows XP - QEMU + +qemu-perf-wine.txt +================ +Machine - Windows XP - VmWare - Fedora - Wine - QEMU + + + + + + + +For linux, the build is done by the native Fedora 18 gcc, 4.7.2 +For Win32, the build is done by Fedora 18's mingw compiler, 4.7.2 + +Configuration for Win32 (from config.log): +# Configured with: './configure' '--disable-guest-agent' '--disable-vnc' '--disable-werror' '--extra-cflags=-pg' '--extra-ldflags=-pg' '--target-list=i386-softmmu' '--cross-prefix=i686-w64-mingw32-' + +NOTE: debug is not enabled, since it breaks current QEMU build (undefined references to 'ffs') + +Configuration for Linux (from config.log): +# Configured with: './configure' '--disable-guest-agent' '--disable-vnc' '--disable-werror' '--extra-cflags=-pg' '--extra-ldflags=-pg' '--target-list=i386-softmmu' '--enable-debug' '--enable-kvm' + +NOTE: although I pass --enable-kvm to configure, I haven't passed it to qemu when running the executables + +Commandline for running on Win32 (started from a Cygwin terminal) and also with Fedora+Wine: +./qemu/i386-softmmu/qemu-system-i386w.exe -L qemu/pc-bios/ vxworks.img + +Commandline for running on Fedora: +./qemu/i386-softmmu/qemu-system-i386 -L qemu/pc-bios/ vxworks.img + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and the latest version of MinGW? Do you also see the problem with the builds from https://qemu.weilnetz.de/ ? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1131 b/results/classifier/zero-shot/105/boot/1131 new file mode 100644 index 000000000..479b1143d --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1131 @@ -0,0 +1,33 @@ +boot: 0.842 +device: 0.804 +graphic: 0.703 +instruction: 0.647 +vnc: 0.634 +socket: 0.569 +network: 0.531 +semantic: 0.508 +other: 0.375 +KVM: 0.344 +mistranslation: 0.250 +assembly: 0.222 + +Multiboot: could not move values from provided mmap to another address directly. +Description of problem: +When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots. +```c +xxx = mmap->addr; +``` + +When moving with volatile, everything works well: +```c +volatile unsigned long long addr = mmap->addr; +xxx = addr; +``` +Steps to reproduce: +1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32) +2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c) +3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here. +4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again. +5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly. +Additional information: +# diff --git a/results/classifier/zero-shot/105/boot/1212402 b/results/classifier/zero-shot/105/boot/1212402 new file mode 100644 index 000000000..586e4f8c5 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1212402 @@ -0,0 +1,173 @@ +boot: 0.981 +other: 0.977 +semantic: 0.976 +instruction: 0.974 +device: 0.969 +assembly: 0.969 +graphic: 0.967 +socket: 0.957 +KVM: 0.952 +vnc: 0.943 +mistranslation: 0.938 +network: 0.910 + +Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu Precise AMD64 kernel 3.8.0 + +When I compile QEMU from GIT and run it with './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU screen stays black. (Everything else in the GTK UI is responsive though, I can use the QEMU console as well.) +I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel Core2 Duo P9500. + +With bisecting, I found this commit caused the problem: + +235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit +commit 235e8982ad393e5611cb892df54881c872eea9e1 +Author: Jordan Justen <email address hidden> +Date: Wed May 29 01:27:26 2013 -0700 + + kvm: support using KVM_MEM_READONLY flag for regions + + For readonly memory regions and rom devices in romd_mode, + we make use of the KVM_MEM_READONLY. A slot that uses + KVM_MEM_READONLY can be read from and code can execute from the + region, but writes will exit to qemu. + + For rom devices with !romd_mode, we force the slot to be + removed so reads or writes to the region will exit to qemu. + (Note that a memory region in this state is not executable + within kvm.) + + v7: + * Update for readable => romd_mode rename (5f9a5ea1) + + Signed-off-by: Jordan Justen <email address hidden> + Reviewed-by: Xiao Guangrong <email address hidden> (v4) + Reviewed-by: Paolo Bonzini <email address hidden> (v5) + Message-id: <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +:100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c + +We have discussed this issue in this mail: +http://<email address hidden>/msg174932.html (VM can +not boot after commit 235e898) + +You can upgrade your kernel to 3.9.x to work around. + + +On Thu, Aug 15, 2013 at 3:23 AM, Julius Schwartzenberg < +<email address hidden>> wrote: + +> Public bug reported: +> +> When I compile QEMU from GIT and run it with +> './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU +> screen stays black. (Everything else in the GTK UI is responsive though, I +> can use the QEMU console as well.) +> I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel Core2 +> Duo P9500. +> +> With bisecting, I found this commit caused the problem: +> +> 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit +> commit 235e8982ad393e5611cb892df54881c872eea9e1 +> Author: Jordan Justen <email address hidden> +> Date: Wed May 29 01:27:26 2013 -0700 +> +> kvm: support using KVM_MEM_READONLY flag for regions +> +> For readonly memory regions and rom devices in romd_mode, +> we make use of the KVM_MEM_READONLY. A slot that uses +> KVM_MEM_READONLY can be read from and code can execute from the +> region, but writes will exit to qemu. +> +> For rom devices with !romd_mode, we force the slot to be +> removed so reads or writes to the region will exit to qemu. +> (Note that a memory region in this state is not executable +> within kvm.) +> +> v7: +> * Update for readable => romd_mode rename (5f9a5ea1) +> +> Signed-off-by: Jordan Justen <email address hidden> +> Reviewed-by: Xiao Guangrong <email address hidden> (v4) +> Reviewed-by: Paolo Bonzini <email address hidden> (v5) +> Message-id: +> <email address hidden> +> Signed-off-by: Anthony Liguori <email address hidden> +> +> :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 +> 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1212402 +> +> Title: +> Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu +> Precise AMD64 kernel 3.8.0 +> +> Status in QEMU: +> New +> +> Bug description: +> When I compile QEMU from GIT and run it with +> './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU +> screen stays black. (Everything else in the GTK UI is responsive though, I +> can use the QEMU console as well.) +> I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel +> Core2 Duo P9500. +> +> With bisecting, I found this commit caused the problem: +> +> 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit +> commit 235e8982ad393e5611cb892df54881c872eea9e1 +> Author: Jordan Justen <email address hidden> +> Date: Wed May 29 01:27:26 2013 -0700 +> +> kvm: support using KVM_MEM_READONLY flag for regions +> +> For readonly memory regions and rom devices in romd_mode, +> we make use of the KVM_MEM_READONLY. A slot that uses +> KVM_MEM_READONLY can be read from and code can execute from the +> region, but writes will exit to qemu. +> +> For rom devices with !romd_mode, we force the slot to be +> removed so reads or writes to the region will exit to qemu. +> (Note that a memory region in this state is not executable +> within kvm.) +> +> v7: +> * Update for readable => romd_mode rename (5f9a5ea1) +> +> Signed-off-by: Jordan Justen <email address hidden> +> Reviewed-by: Xiao Guangrong <email address hidden> (v4) +> Reviewed-by: Paolo Bonzini <email address hidden> (v5) +> Message-id: +> <email address hidden> +> Signed-off-by: Anthony Liguori <email address hidden> +> +> :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 +> 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1212402/+subscriptions +> +> + + +-- +Best Regards, + +Dunrong Huang + +Homepage: http://mathslinux.org + + +It seems reverting this exact commit also works around the problem. I have attached a patch against current head. + +According to comment #1, this has been fixed with kernel 3.9, so setting the status to "Fix released" now. + diff --git a/results/classifier/zero-shot/105/boot/1221797 b/results/classifier/zero-shot/105/boot/1221797 new file mode 100644 index 000000000..b0de6bbda --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1221797 @@ -0,0 +1,56 @@ +boot: 0.852 +instruction: 0.818 +other: 0.787 +semantic: 0.744 +KVM: 0.742 +mistranslation: 0.741 +device: 0.688 +graphic: 0.639 +vnc: 0.636 +network: 0.572 +socket: 0.549 +assembly: 0.432 + +virt-install gets stuck during downloading install.img + +I have tried to install CentOS 6.4 using the latest version of all kvm related tools. My problem is that I get stuck at arround 20% during the download of the file install.img. Everything before that works just fine. + +I am using the following commands to install to server: +virt-install \ + -n test \ + -r 1024 \ + --disk path=/var/kvm/images/test.img,size=25 \ + --vcpus=1 \ + --os-type linux \ + --os-variant=rhel6 \ + --network bridge=br2 \ + --nographics \ + --location='http://mirror.netcologne.de/centos/6.4/os/x86_64' \ + --extra-args='console=tty0 console=ttyS0,115200n8 serial' \ + +I have checked that my server is ready for virtualization. + +If you need any further information I am happy to provide them + +Patrick Gramsl + +I guess it could be a problem with the mirror you are using. Have you tried using a different mirror. Following is what I tried and I was able to boot centos + +virt-install \ +-n test \ +-r 1024 \ +--disk path=/tmp/test.img,size=3 \ +--vcpus=1 \ +--os-type linux \ +--os-variant=rhel6 \ +--network bridge=virbr0 \ +--nographics --location='http://centos.mirror.net.in/centos/6.4/os/x86_64' \ +--extra-args='console=tty0 console=ttyS0,115200n8 serial' + +Sorry yes of course I have tried a different mirror but I think that the problem was with my server installation because even my mail server was not working correctly I will update this comment as soon as I have new information. + +@Shivakumar: +Thank you for your help anyway + +This is not a QEMU bug ... for virt-install related problems, please see https://virt-manager.org/bugs/ instead. + diff --git a/results/classifier/zero-shot/105/boot/1256548 b/results/classifier/zero-shot/105/boot/1256548 new file mode 100644 index 000000000..bfd836864 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1256548 @@ -0,0 +1,29 @@ +boot: 0.868 +device: 0.800 +graphic: 0.648 +network: 0.573 +instruction: 0.568 +socket: 0.539 +vnc: 0.487 +mistranslation: 0.422 +other: 0.416 +semantic: 0.415 +assembly: 0.192 +KVM: 0.010 + +qemu windows guest issues + +Ive noticed the following in the latest qemu build on mingw 64bit for windows + +older guests like windows 9* no longer boot they mostly just bsod its been this way for ages same with 32bit builds +xp 64bit and other 64bit windows guests no longer work and havent for ages same with 32bit builds +xp 32bit guest doesent work under 64bit builds but they work on 32bit builds + +are the issues with the coroutine stuff on windows builds being worked on? id gladly test patches + +just a few observations is all :) + +Which exact version of QEMU did you use? Does this problem still occur with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1273944 b/results/classifier/zero-shot/105/boot/1273944 new file mode 100644 index 000000000..854f598f6 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1273944 @@ -0,0 +1,73 @@ +boot: 0.935 +graphic: 0.873 +mistranslation: 0.793 +device: 0.760 +semantic: 0.745 +instruction: 0.739 +other: 0.683 +network: 0.571 +socket: 0.514 +vnc: 0.409 +assembly: 0.372 +KVM: 0.334 + +multiboot header has 0 in mem_upper field + +When booting a multiboot image,. mem_upper is now always zero. + +To test, build qemu from current git head, then do + cd tests/multiboot + ./run_test.sh + +You will see the test fail. In each case mem_upper is 0k. + +git-bisect says the bad commit is 0169c511554cb0014a00290b0d3d26c31a49818f in qemu.git + +This change fixes it. + +diff --git a/exec.c b/exec.c +index 2435d9e..b387d28 100644 +--- a/exec.c ++++ b/exec.c +@@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block, + } + + /* MAP_POPULATE silently ignores failures */ +- for (i = 0; i < (memory/hpagesize); i++) { ++ for (i = 0; i < (memory/hpagesize)-1; i++) { + memset(area + (hpagesize*i), 0, 1); + } + +peterc@Diprotodon:/usr/src/qemu/tests/m + +>>>>> "Peter" == Peter Chubb <email address hidden> writes: +This change fixes it. + +> diff --git a/exec.c b/exec.c +> index 2435d9e..b387d28 100644 +> --- a/exec.c +> +++ b/exec.c +> @@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block, +> } +> +> /* MAP_POPULATE silently ignores failures */ +> - for (i = 0; i < (memory/hpagesize); i++) { +> + for (i = 0; i < (memory/hpagesize)-1; i++) { +> memset(area + (hpagesize*i), 0, 1); +> } + +I don't know why this fixes the issue. Hence, no signed-off-by line, etc. + +My guess is that the memset zeros something it shouldn't off the end of +the array (but that doesn't make sense to me!) + +Peter C +-- +Dr Peter Chubb peter.chubb AT nicta.com.au +http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA + + +tests/multiboot seems to work with current git again, so I assume this issue has been fixed? Or is there something left to do? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1280 b/results/classifier/zero-shot/105/boot/1280 new file mode 100644 index 000000000..9555fe770 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1280 @@ -0,0 +1,21 @@ +boot: 0.866 +device: 0.835 +instruction: 0.791 +network: 0.741 +graphic: 0.694 +semantic: 0.678 +vnc: 0.602 +socket: 0.542 +mistranslation: 0.333 +other: 0.204 +assembly: 0.075 +KVM: 0.054 + +qemu-system-arm 7.1 can not boot my cortex-m55 image +Steps to reproduce: +``` +1.qemu-system-arm -cpu cortex-m55 -machine mps3-an547 -nographic -vga none -monitor none -semihosting -semihosting-config enable=on,target=native -kernel qemu_simu.elf +2.arm-none-eabi-gdb -ex "target extended-remote localhost:1234" qemu_simu.elf +``` +Additional information: +[qemu_simu.tar.gz](/uploads/b8b3bf0f4868fdbb22b19027f685b4f0/qemu_simu.tar.gz) diff --git a/results/classifier/zero-shot/105/boot/1285508 b/results/classifier/zero-shot/105/boot/1285508 new file mode 100644 index 000000000..0d90f5a1d --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1285508 @@ -0,0 +1,53 @@ +boot: 0.831 +device: 0.755 +graphic: 0.707 +mistranslation: 0.700 +semantic: 0.675 +instruction: 0.645 +other: 0.486 +vnc: 0.372 +network: 0.344 +KVM: 0.317 +socket: 0.305 +assembly: 0.093 + +[ppa 2.0~git-20140225] mouse cursor invisible with Ubuntu live system + +As requested on u-devel@, I tested QEMU 2.0~git-20140225.aa0d1f4-0ubuntu2 from ppa:ubuntu-virt/candidate. This has a regression with the mouse cursor. + +I downloaded the current Ubuntu Desktop trusty beta-1 amd64 image, and booted it in QEMU: + + $ kvm -m 2048 -cdrom trusty-desktop-amd64.iso + +This boots fine, but in the desktop I don't see any mouse cursor. + +Interestingly this only happens with sdl. Using vga it works fine. + +It also works fine in qxl/spice (qemu ... -spice disable-ticketing,port=5930; spicy -h localhost -p 5930). + +i have the same, I don't see any mouse cursor. System is working. + +Host: Ubuntu release 14.04 x86_64 +Gast: Ubuntu release 14.04 x86_64 + +Graphic: GeForce GTX 650 Ti BOOST/PCIe/SSE2 +Driver: nvidia 331.38 + + + +there are my terminal commands: + +$ qemu-img create -f qcow2 BOOTSYSTEM.img 10G +$ qemu-system-x86_64 -enable-kvm -hda BOOTSYSTEM.img -cdrom /dev/cdrom -boot d -m 1024 + + +I still regularly get this. The workaround is to open a terminal, which causes the cursor shape to change. Once that is done, the cursor stays visible. + +Hi Martin, + +when you get this, I assume that is with the standard trusty or utopic package? + +I ask because the subject says 'ppa' - i'd like to remove that. + +It's actually fine for me with current utopic's 2.1+dfsg-2ubuntu2. I tested both the default graphics card as well as "-vga vmware". + diff --git a/results/classifier/zero-shot/105/boot/1289898 b/results/classifier/zero-shot/105/boot/1289898 new file mode 100644 index 000000000..3e60f04aa --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1289898 @@ -0,0 +1,130 @@ +boot: 0.977 +socket: 0.976 +semantic: 0.973 +graphic: 0.970 +network: 0.966 +device: 0.962 +instruction: 0.951 +assembly: 0.949 +vnc: 0.942 +mistranslation: 0.939 +other: 0.939 +KVM: 0.899 + +qemu-system-ppc64 easily cause file corruption + +the qemu-system-ppc64 is used to run Fedora-19 on RHEL 5.3. +Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: + +* using scp to transfer a tar.bz file from the RHEL 5.3 host to the Fedora-19 PPC VM, found the size is correct, but the content is corrupted from the middle of the 80+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. + +Correction, the qemu-system-ppc64 is running a VM for RHEL5.9 for PPC, not fedora-19. + +Hi, any chance you could try the latest snapshot from git? It has a lot of PPC64 changes. Also, please pass your QEMU command line. + +I used the following way to start the VM: + +#!/bin/bash +ifconfig -a|grep tap0 >/dev/null 2>&1 || qemu-ifup tap0 + +qemu-system-ppc64 -hda ppcrhel5.img -cpu POWER7 -machine type=pseries,usb=off -m 768 -nographic -net nic -net tap,ifname=tap0,script=no +qemu-ifdown tap0 + +I found a CentOS 6.4 machine which has QEMU 1.5.3, and copied the ppcrhel5.img to that machine, and tested, found it's reliable, and no such file and filesystem easy corruption issue. So, it's the 1.6.2 and 1.7.0 have the problem. + +I can't test from git: on one box with git, it failed for the pixman missing. and the RHEL 5.3 doesn't have git. + +On 10 March 2014 10:00, wzis <email address hidden> wrote: +> I can't test from git: on one box with git, it failed for the pixman +> missing + +Did you try the git submodule command that configure +suggests when it can't find pixman? That will pull +in and build a local copy of pixman for QEMU. + +thanks +-- PMM + + +Also, RHEL5 does have git in the EPEL repository. + +On my RHEL 5.3 box, there are too many problems to get git work. And on the CentOS 6.4 it has many problem to get pixman, so I just can't test the latest qemu unless you also put the pixman in as 1.7.0 does. + +> Date: Mon, 10 Mar 2014 10:53:48 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1289898] Re: qemu-system-ppc64 easily cause file corruption +> +> Also, RHEL5 does have git in the EPEL repository. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1289898 +> +> Title: +> qemu-system-ppc64 easily cause file corruption +> +> Status in QEMU: +> New +> +> Bug description: +> the qemu-system-ppc64 is used to run RHEL5.9 for IBM Power on RHEL 5.3. +> Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: +> +> * using scp to transfer a tar.bz file from the RHEL 5.3 host to the RHEL 5.9 PPC VM, found the size is correct, but the content is corrupted from the middle of the 90+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +> The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1289898/+subscriptions + + +Yes, I tried that, but it failed due to some php component missing. + +> Date: Mon, 10 Mar 2014 10:45:34 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 1289898] Re: qemu-system-ppc64 easily cause file corruption +> +> On 10 March 2014 10:00, wzis <email address hidden> wrote: +> > I can't test from git: on one box with git, it failed for the pixman +> > missing +> +> Did you try the git submodule command that configure +> suggests when it can't find pixman? That will pull +> in and build a local copy of pixman for QEMU. +> +> thanks +> -- PMM +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1289898 +> +> Title: +> qemu-system-ppc64 easily cause file corruption +> +> Status in QEMU: +> New +> +> Bug description: +> the qemu-system-ppc64 is used to run RHEL5.9 for IBM Power on RHEL 5.3. +> Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: +> +> * using scp to transfer a tar.bz file from the RHEL 5.3 host to the RHEL 5.9 PPC VM, found the size is correct, but the content is corrupted from the middle of the 90+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +> The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1289898/+subscriptions + + +and lots of dependency issue . + +After got qemu 2.3.0, I tested on CentOS6.6, the qemu-system-ppc64 also causes filesystem corruption for the big endian RHEL5.9 for power. So this should confirm the qemu for ppc has bug from at least 1.7 onward. + +And seems no developer cares about this issue. + +Is this the same issue as bug https://bugs.launchpad.net/qemu/+bug/1463812 ? If so, I think we should close one of the two tickets - no need to track an issue twice. + diff --git a/results/classifier/zero-shot/105/boot/1290558 b/results/classifier/zero-shot/105/boot/1290558 new file mode 100644 index 000000000..6a90d31b9 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1290558 @@ -0,0 +1,212 @@ +boot: 0.955 +device: 0.931 +graphic: 0.927 +socket: 0.925 +other: 0.925 +assembly: 0.915 +semantic: 0.899 +instruction: 0.893 +vnc: 0.863 +network: 0.836 +mistranslation: 0.827 +KVM: 0.826 + +color issue (ppc as guest) + +Hi, + +on my qemu 1.6.1 -- installed via fink on host Mac OS X 10.8 -- guest PowerPc with Mac OS X 10.4 from original install disk, boots fine but I observe a color issue exactly as described here: +http://virtuallyfun.superglobalmegacorp.com/?p=3197 +http://virtuallyfun.superglobalmegacorp.com/?p=3189 + +Has the problem been reported and/or fixed already? Is any workaround known or has one been suggested? +I apologize for a "fuzzy" problem description, but I am not an expert user. You may get in touch with me directly at <email address hidden> + +Thanks, +Joe. + +Hi Joe, + +Thanks for the bug report. A few things to try: + +- Can you confirm that you see the same color issue when booting a Darwin ISO such as darwinppc-602.iso? +- Do you still see the same the issue with QEMU git master as 1.6 is fairly old now? + +Using the Darwin image above, I do not see the color issue in the above posts on my Linux x86-64 machine. If it is still present for you, you'll need to give more information about the libraries used to build your QEMU and your host (perhaps it is something specific to OS X and/or your build environment?). + + +ATB, + +Mark. + + +Hi Mark, + +thank you for taking some time! + +a) +Yes, the color issue is exactly the same for qemu 1.6.0 with darwinppc-602.cdr from https://opensource.apple.com/static/iso/ +command used: + +qemu-system-ppc -snapshot -L -hda /Users/joe/darwinppc-602.cdr -g 1280x1024x32 + +I have tried some additional options like the g3beige but without effect; maybe I haven't tried all of them yet… + +The color seems to be wrong right from the very first apperance of the opening guest window, even before anything is (visibly) beeing booted. The color depth changes the way in which colors are off: +32: boot screen deep yellow at first, colors mixed up in always the same consistent way, otherwise system seems to be fully usable. +24, 16: bright yellow at first, then funny distorted apple logo screen, than unreadible, text(?) in same color as background… +8: somewhat normal at first but turns into extremly unusable greyscale later on, feels more like bad 4bit. +Please let me know if you can reproduce that or if I should take a screen move for example. + +b) +I would need some help installing a newer version of qemu than 1.6.0. For 1.6.0, I got the attached info file which shows all dependencies to compile and install easily via fink. ( http://www.finkproject.org ) Can you provide something similar for qemu 2.0.0rc0 or tell me where/how to get it? Or alternatively, do you see any outdated (even for 1.6.0) dependencies in that info file that could account for that error? Then, would simply rebuilding help? +Again, I am guessing what might be involved outside qemu, but I am NOT an expert an any of that. + +Thank you very much for your help! + +Best, +Joe. + + + + + +On 12.03.2014, at 08:37, Mark Cave-Ayland <email address hidden> wrote: + +> Hi Joe, +> +> Thanks for the bug report. A few things to try: +> +> - Can you confirm that you see the same color issue when booting a Darwin ISO such as darwinppc-602.iso? +> - Do you still see the same the issue with QEMU git master as 1.6 is fairly old now? +> +> Using the Darwin image above, I do not see the color issue in the above +> posts on my Linux x86-64 machine. If it is still present for you, you'll +> need to give more information about the libraries used to build your +> QEMU and your host (perhaps it is something specific to OS X and/or your +> build environment?). +> +> +> ATB, +> +> Mark. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1290558 +> +> Title: +> color issue (ppc as guest) +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> on my qemu 1.6.1 -- installed via fink on host Mac OS X 10.8 -- guest PowerPc with Mac OS X 10.4 from original install disk, boots fine but I observe a color issue exactly as described here: +> http://virtuallyfun.superglobalmegacorp.com/?p=3197 +> http://virtuallyfun.superglobalmegacorp.com/?p=3189 +> +> Has the problem been reported and/or fixed already? Is any workaround known or has one been suggested? +> I apologize for a "fuzzy" problem description, but I am not an expert user. You may get in touch with me directly at <email address hidden> +> +> Thanks, +> Joe. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1290558/+subscriptions + + + +Hi Joe, + +Thanks for confirming that you still see the issue with the ISO above. From what you're saying, it seems that the problem is apparent on OS X which means I am definitely unable to recreate it here. Since other OS X QEMU users would likely have noticed the bug, I think it may be something related to the build environment. + +My suspicion would lie with the libraries used to build QEMU, particularly pixman which is the low-level graphics library used. Do you know whether the pixman submodule from git.qemu.org was used, or whether it was sourced from somewhere else? Unfortunately as I don't use OS X myself it's going to be difficult for me to help you further with the build unless it's just general advice about building QEMU. + + +HTH, + +Mark. + + +Hi Mark, + +It still seems to me that the problem is somewhere *within* the qemu tree but specific to all MacOSX hosts, and not to my individual build environment. I have done some further research and I found for example +http://www.emaculation.com/doku.php/ppc-osx-on-qemu-for-osx +It lists my exact problem at the bottom of the page under "known issues". (Known to whom, if it seems not to have reached the qemu team yet). It is also present under OSX 10.9.2, which I tried today. + +Also I've tried out the latest builds from qemu.org with the same results. qemu-system-ppc --version returns 1.7.90 (though I downloaded 2.0.0 rc0) +Interestingly, using qemu-system-ppc64 instead produces the correct colors at the very start of the booting, though of course it doesn't get anywhere else since MacOSX 10.4 and 10.5 are both still 32 bit kernels as far as I know. However, that is at least an indicator that the problem may not be the build environment because that environment was exactly the same for qemu-system-ppc and qemu-system-ppc64 + +Thanks for your efforts, I appreciate it! +Joe. + + +On 27.03.2014, at 01:16, Mark Cave-Ayland <email address hidden> wrote: + +> Hi Joe, +> +> Thanks for confirming that you still see the issue with the ISO above. +> From what you're saying, it seems that the problem is apparent on OS X +> which means I am definitely unable to recreate it here. Since other OS X +> QEMU users would likely have noticed the bug, I think it may be +> something related to the build environment. +> +> My suspicion would lie with the libraries used to build QEMU, +> particularly pixman which is the low-level graphics library used. Do you +> know whether the pixman submodule from git.qemu.org was used, or whether +> it was sourced from somewhere else? Unfortunately as I don't use OS X +> myself it's going to be difficult for me to help you further with the +> build unless it's just general advice about building QEMU. +> +> +> HTH, +> +> Mark. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1290558 +> +> Title: +> color issue (ppc as guest) +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> on my qemu 1.6.1 -- installed via fink on host Mac OS X 10.8 -- guest PowerPc with Mac OS X 10.4 from original install disk, boots fine but I observe a color issue exactly as described here: +> http://virtuallyfun.superglobalmegacorp.com/?p=3197 +> http://virtuallyfun.superglobalmegacorp.com/?p=3189 +> +> Has the problem been reported and/or fixed already? Is any workaround known or has one been suggested? +> I apologize for a "fuzzy" problem description, but I am not an expert user. You may get in touch with me directly at <email address hidden> +> +> Thanks, +> Joe. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1290558/+subscriptions + + + +Hi Joe, + +Sorry for the delay with this - have had quite a lot on recently. Just to reiterate what I mentioned above, can you rebuild with pixman as a git submodule and see if that makes a difference? Otherwise configure may pick up a different (older) version of pixman on the system which may have bugs. You can confirm which version is being used by the executable by using ldd on the command line. + +Also with your current build does 8-bit colour work correctly, e.g. use -g 1024x768x8 on the command line? + + +ATB, + +Mark. + + +This problem was fixed in early 2015. Mac OS 9 and Mac OS X both display the correct colors. + diff --git a/results/classifier/zero-shot/105/boot/1314667 b/results/classifier/zero-shot/105/boot/1314667 new file mode 100644 index 000000000..d7230ee82 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1314667 @@ -0,0 +1,126 @@ +boot: 0.826 +device: 0.822 +mistranslation: 0.814 +other: 0.811 +socket: 0.810 +instruction: 0.791 +assembly: 0.773 +semantic: 0.750 +vnc: 0.724 +graphic: 0.683 +network: 0.675 +KVM: 0.673 + +PMPrebUSB - appcrash of qemu in Win-7-64bit + +I am not sure if this issue is a bug of qemu or by Win-7. +I want to test in advance with QEMU the ability if my USB-Rescue-Drive is +booting correctly. I have Win-7-64 and run qemu v.o.15.1.0 out of the installed RMPrepUSB v.2.1.719 +program. The settings for the preparation of my USB drive were FAT32 boot as +HD, bootloader WinPE/Win-7/Vista, set for running iso-files directly in %_ISO +\MAINMENU\Hiren’sBootCD.iso. When I run Qemu I get the messages in the cmd starting window it says: + +Administrator: RMPrepUSB QEMU Launcher +************************************** +EXECUTING "C:\Program Files (x86)\RMPrepUSB\qemu\STARTFROMUSB.cmd" +DRIVE NUMBER=3 +MEMORY SIZE=1000 +HARD DISK IMAGE=harddisk.img +NOWRITE= +Found OS=VISTA_OR_LATER +Sending command Start_VM.exe 3 500 qemu.exe -L . -name "RMPrepUSB Emulation +Session RAM=1000MB VirtualHDD=harddisk.i +lt+LCtrl)" -boot c -m 1000 -drive file=\\. +\PhysicalDrive3,if=ide,index=0,media=disk -hdb harddisk.img to shell... + +Win-7: in the second window appears: +*********************************** +-->qemu funktioniert nicht mehr +Problemsignatur: + Problemereignisname: APPCRASH + Anwendungsname: qemu.exe + Anwendungsversion: 0.15.1.0 + Anwendungszeitstempel: 4f478c16 + Fehlermodulname: qemu.exe + Fehlermodulversion: 0.15.1.0 + Fehlermodulzeitstempel: 4f478c16 + Ausnahmecode: 40000015 + Ausnahmeoffset: 00053b06 + Betriebsystemversion: 6.1.7601.2.1.0.256.48 + Gebietsschema-ID: 1031 + Zusatzinformation 1: bf8d + Zusatzinformation 2: bf8d49108a2e5a0707fc48438e01652a + Zusatzinformation 3: b0f1 + Zusatzinformation 4: b0f155b0f1de9c5eb22bd6d100737cbe + +If somebody can understand that behaviour I appreciate everybodies help. Thank you with regards +H.O. + +The QEMU used in RMPrepUSB is 32-bit only - it won't run 64-bit programs. Normally, Windows will just display an error message saying it needs a 64-bit system. Use Virtual Box for 64-bit OS testing and DavidB's Virtual Machine USB Boot application - see www.rmprepusb.com Tutorial #4 + +Hello, +thank you for answering very fast. But in Google is advertised +/"//RMPrepUSB/ <http://www.rmprepusb.com/> + + + www.rmprepusb.com/Diese Seite übersetzen + <http://translate.google.com/translate?hl=de&sl=en&u=http://www.rmprepusb.com/&prev=/search%3Fq%3DRMPrepUSB%2B64%2Bbit%2Bqemu%26hl%3Dde%26biw%3D905%26bih%3D508> + +Rating for /rmprepusb/.com .... 32-bit and /64/-/bit/ versions are fully +supported. ... 2 /RMPrepUSB/ Help form screenshot (includes F11 = Run +/QEMU/ emulator, and ... +Download <http://www.rmprepusb.com/documents/release-2-0> - Latest +RMPrepUSB versions +<http://www.rmprepusb.com/documents/rmprepusb-beta-versions> +- Easy2Boot +<http://www.rmprepusb.com/tutorials/72---easyboot---a-grubdos-multiboot-drive-that-is-easy-to-maintain/e2bv1> +- 47 - How to install Windows +<http://www.rmprepusb.com/tutorials/win7onusb>" +is that correct and valid or not? Fully supported means to me, that qemu +should work too on Win-7-64bit.. Or why does RMPrepUSB +<http://www.rmprepusb.com/documents/rmprepusb-beta-versions> not change +this at times of XP-64 bit, Vista-64 bit, Win-7 64 bit, Win-8 64bit, +Win-8.1 64bit. Thank you with kind regards +H.Ohlerth + + + + + +Am 30.04.2014 20:55, schrieb Steve Si: +> The QEMU used in RMPrepUSB is 32-bit only - it won't run 64-bit +> programs. Normally, Windows will just display an error message saying it +> needs a 64-bit system. Use Virtual Box for 64-bit OS testing and +> DavidB's Virtual Machine USB Boot application - see www.rmprepusb.com +> Tutorial #4 +> + + + +RMPrepUSB will run ON 32-bit and 64-bit Operating Systems. +That is not the same thing as QEMU will run a 64-bit Operating System. +There is a 64-bit version of QEMU but it is very buggy and won't even boot a 64-bit Vista/7 WinPE, so it is not included. +As I said, normally when booting a 64-bit OS under QEMU, you will see a Windows message saying that the system is not a 64-bit system. For some reason you are not seeing this on your system. + + +Hello Steve, I had a lot of trouble over the weekend building a +sufficiently working bootable "USB-Rescue-Drive". I summed it up in an +attached Word-Dokument and I am sure, you have the knowledge to solve +my problems. For your detailed help I will expect with lots of kind regards + +H.Ohlerth + + +Am 01.05.2014 10:40, schrieb Steve Si: +> RMPrepUSB will run ON 32-bit and 64-bit Operating Systems. +> That is not the same thing as QEMU will run a 64-bit Operating System. +> There is a 64-bit version of QEMU but it is very buggy and won't even boot a 64-bit Vista/7 WinPE, so it is not included. +> As I said, normally when booting a 64-bit OS under QEMU, you will see a Windows message saying that the system is not a 64-bit system. For some reason you are not seeing this on your system. +> + + + +Looking through old bug tickets... can you still reproduce this issue with the latest (64-bit) 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/zero-shot/105/boot/1320 b/results/classifier/zero-shot/105/boot/1320 new file mode 100644 index 000000000..cd7ce17b3 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1320 @@ -0,0 +1,25 @@ +boot: 0.915 +device: 0.912 +instruction: 0.891 +graphic: 0.890 +network: 0.819 +vnc: 0.767 +semantic: 0.673 +assembly: 0.614 +mistranslation: 0.614 +socket: 0.600 +other: 0.342 +KVM: 0.247 + +qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin" +Description of problem: +qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin" +Steps to reproduce: +1. wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.79.tar.xz +2. sudo apt-get install crossbuild-essential-riscv64 +3. make ARCH=riscv defconfig && make ARCH=riscv menuconfig +4. make -j4 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- +5. trucate -s 128G rootfs.img && mkfs.ext4 rootfs.img +6. sudo mount -o loop ./rootfs.img /mnt +7. debootstrap --arch=riscv64 focal /mnt +8. qemu-system-riscv64 -machine virt -bios default -m 512M -kernel ./linux-5.15.79/arch/riscv/boot/Image -drive file=./rootfs.img,format=raw diff --git a/results/classifier/zero-shot/105/boot/1348 b/results/classifier/zero-shot/105/boot/1348 new file mode 100644 index 000000000..7132efe4e --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1348 @@ -0,0 +1,14 @@ +boot: 0.860 +device: 0.790 +network: 0.524 +graphic: 0.402 +vnc: 0.249 +instruction: 0.187 +semantic: 0.157 +socket: 0.131 +mistranslation: 0.082 +other: 0.076 +assembly: 0.017 +KVM: 0.001 + +WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as #1115 https://gitlab.com/qemu-project/qemu/-/issues/1115 ) diff --git a/results/classifier/zero-shot/105/boot/1426472 b/results/classifier/zero-shot/105/boot/1426472 new file mode 100644 index 000000000..d25dd3f54 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1426472 @@ -0,0 +1,51 @@ +boot: 0.579 +graphic: 0.565 +device: 0.387 +instruction: 0.250 +semantic: 0.199 +socket: 0.174 +other: 0.138 +vnc: 0.118 +network: 0.111 +mistranslation: 0.111 +assembly: 0.026 +KVM: 0.018 + +Recent regression: segfault on startup with -snapshot + +As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu segfaults on startup when I try to boot a hard disk image with the -snapshot option. + +To reproduce: + + wget http://wiki.qemu.org/download/linux-0.2.img.bz2 + bunzip2 linux-0.2.img.bz2 + qemu-system-i386 -hda linux-0.2.img -snapshot + +When I run this, qemu-system-i386 crashes with a segmentation fault. This is on a Debian 7 amd64 host. + +git bisect implicates the following commit: + +commit a464982499b2f637f6699e3d03e0a9d2e0b5288b +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 11 17:15:18 2015 +0100 + + rcu: run RCU callbacks under the BQL + + This needs to go away sooner or later, but one complication is the + complex VFIO data structures that are modified in instance_finalize. + Take a shortcut for now. + + Reviewed-by: Michael Roth <email address hidden> + Tested-by: Michael Roth <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +I believe this was resolved in: + +commit 6b49809c597331803ea941eadda813e5bb4e8fe2 +Author: Paolo Bonzini <email address hidden> +Date: Fri Feb 27 19:58:23 2015 +0100 + + cpus: fix deadlock and segfault in qemu_mutex_lock_iothread + +The problem cannot be reproduced in qemu.git/master (fc85cf4a8199a657fdfd5fb902f1835973406454). + diff --git a/results/classifier/zero-shot/105/boot/1481750 b/results/classifier/zero-shot/105/boot/1481750 new file mode 100644 index 000000000..710433010 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1481750 @@ -0,0 +1,49 @@ +boot: 0.876 +instruction: 0.837 +graphic: 0.818 +device: 0.788 +other: 0.715 +mistranslation: 0.712 +semantic: 0.646 +network: 0.582 +vnc: 0.535 +socket: 0.515 +KVM: 0.440 +assembly: 0.355 + +qemu-system-ppc hangs when running -M ppce500 -bios u-boot.e500 + +On recent qemu versions (tested on locally built versions 2.3.50 and 2.3.93) +the command below causes qemu to hang before the u-boot command prompt is reached. +However in an older version (2.2.1) the u-boot bootprompt is reached and can be typed into, +so apparenly something has broken along the way. + + +ppc-softmmu/qemu-system-ppc -d guest_errors -d in_asm -M ppce500 -nographic -bios pc-bios/u-boot.e500 + + +From the -d in_asm argument you can compare the runs and the 2.2.1 version +outputs a lot more. + +------ +- I use the unmodified u-boot.e500 that is inlcuded with each respective version. +- when building qemu my configure paramters were in all three cases : +'./configure' '--target-list=ppc-softmmu,arm-softmmu' '--audio-drv-list=' '--enable-debug' + +It is not qemu that hangs. +The u-boot.e500 software falls into an eternal loop at the addresses 0x00f1f964 to 0x00f1f94c +due to the registers r9 and r10 (both) being 0x0 in the newer versions and 0x40 in the working 2.2.1 version. + +Howerver, those values ought to have originated from the qemu environment somehow. + +Looks like this has been broken by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6b4e5f4795b2591fd91bea671e3e22e08fd0e75 +("PPC: e500: Move CCSR and MMIO space to upper end of address space") + +Problem should now be fixed with this commit: +http://git.qemu-project.org/?p=qemu.git;a=commit;h=d4574435a6530bbd96ae130eddfe5b676f91367a +Please test, and close this bug if it is working now. + +Yes, It works fine now. Thanks! +I cannot find an option to close this bug, perhaps I'm not authorized to do it? + diff --git a/results/classifier/zero-shot/105/boot/1488212 b/results/classifier/zero-shot/105/boot/1488212 new file mode 100644 index 000000000..5a67ec67a --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1488212 @@ -0,0 +1,29 @@ +boot: 0.800 +graphic: 0.765 +vnc: 0.730 +device: 0.726 +KVM: 0.670 +instruction: 0.618 +socket: 0.571 +network: 0.519 +mistranslation: 0.479 +semantic: 0.374 +other: 0.326 +assembly: 0.081 + +16bit appcrash on W2K8 32bit and Vista 32bit guests + +16 bit appcrash on 32bit windows 2008 and Vista guest. Used git bisect and determined the problem has occurred since vgabios update included in commit 6eefccc0bb9c34051b1e21880fc3a1c1c8686edd in qemu.git. Using a vgabios before this commit works. + +To reproduce boot a Vista or Windows 2008 guest and start a command window. In the command window type command.com . Notice ntvdm appcrash. + + +qemu-system-x86_64 -name eccovm9 -M pc-i440fx-2.1 -cpu SandyBridge -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 -usb -drive file=/home/libvirt/images/eccovm9.img,if=none,id=drive-virtio-disk0,format=raw,cache=directsync -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus + +qemu-system-x86_64 -version +QEMU emulator version 2.4.50, Copyright (c) 2003-2008 Fabrice Bellard + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1505062 b/results/classifier/zero-shot/105/boot/1505062 new file mode 100644 index 000000000..d92438008 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1505062 @@ -0,0 +1,37 @@ +boot: 0.801 +device: 0.798 +graphic: 0.720 +instruction: 0.623 +other: 0.616 +mistranslation: 0.565 +semantic: 0.495 +KVM: 0.482 +socket: 0.434 +network: 0.426 +vnc: 0.326 +assembly: 0.175 + +Regression: QEMU 2.4 on Linux 4.2 fails to init display with SMM enabled + +QEMU version: 2.4, also tested b37686f (2015-10-09 12:18:13 +0100) not working. Requires KVM and SDL, possibly others. +Kernel version: 4.1 working, 4.2 not working. +Architecture: x86_64 +Target: x86_64, also tested i386 not working. + +Step 0: Install versions listed above. +Step 1: Run "qemu-system-$TARGET -enable-kvm" +Step 2: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.3" +Step 3: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.4" +Step 4: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.3,smm=on" +Step 5: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.4,smm=off" +Step 6: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.3" +Step 7: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.4" +Step 8: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.3,smm=on" +Step 9: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.4,smm=off" + +Expected behavior: All 8 invocations result in an rectangular SDL window showing a framebuffer showing failure to locate a boot device. + +Actual behavior: Invocations corresponding to steps 2, 4, 5, 6, 8, and 9 (i.e. those using 2.4 and *not* smm=off) behave as expected, however those in steps 1, 3, and 7 result in a square black SDL window with no text. Note that step 1 is more or less the "default configuration" for QEMU with KVM. + +fixed in linux + diff --git a/results/classifier/zero-shot/105/boot/1516 b/results/classifier/zero-shot/105/boot/1516 new file mode 100644 index 000000000..3327f45f4 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1516 @@ -0,0 +1,52 @@ +boot: 0.931 +instruction: 0.873 +device: 0.819 +graphic: 0.754 +semantic: 0.729 +vnc: 0.610 +mistranslation: 0.470 +network: 0.424 +socket: 0.388 +KVM: 0.366 +assembly: 0.281 +other: 0.225 + +QEMU does not reload kernel image on guest reboot (direct kernel boot) +Description of problem: +I am using virtiofs as root filesystem with QEMU direct kernel boot. The kernel is loaded from the guests directory structure that is exported from the host. + +The problem is that QEMU does not reload the kernel image file from disk during a guest reboot. This means it is not possible to update the kernel from inside the guest and do a simple reboot to load it. A full power cycle of the guest is required to load the updated kernel image. +Steps to reproduce: +1. Migrate a Linux guest to virtiofs as root fs. +2. Enable QEMU direct kernel boot and point to guest's kernel in the exported root filesystem. +3. Boot. +4. Update the kernel inside the guest. Overwrite the existing kernel image +5. Issue `reboot` inside the guest. +6. When the guest reboots, the old kernel is still booted, even though the image file was overwritten. +7. Issue `poweroff` inside the guest. +8. Issue `virsh start <guest-vm>` +9. Now the new kernel image is booted. +Additional information: +XML: +``` +<type arch='x86_64' machine='pc-q35-7.0'>hvm</type> + <kernel>/media/vm/libvirt/images/alpine-q/root/boot/vmlinuz-virt</kernel> + <initrd>/media/vm/libvirt/images/alpine-q/root/boot/initramfs-virt</initrd> + <cmdline>rootfstype=virtiofs root=root rw</cmdline> + <boot dev='hd'/> + <bootmenu enable='no'/> + </os> + +... + + <filesystem type='mount' accessmode='passthrough'> + <driver type='virtiofs'/> + <binary path='/usr/libexec/virtiofsd' xattr='on'> + <cache mode='always'/> + <lock posix='on' flock='on'/> + </binary> + <source dir='/media/vm/libvirt/images/alpine-q/root'/> + <target dir='root'/> + <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> + </filesystem> +``` diff --git a/results/classifier/zero-shot/105/boot/1522 b/results/classifier/zero-shot/105/boot/1522 new file mode 100644 index 000000000..0b783b968 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1522 @@ -0,0 +1,53 @@ +boot: 0.906 +graphic: 0.882 +device: 0.856 +mistranslation: 0.782 +vnc: 0.782 +semantic: 0.770 +instruction: 0.730 +socket: 0.686 +other: 0.595 +assembly: 0.370 +network: 0.322 +KVM: 0.054 + +Floppy controller returns the wrong thing for multitrack reads which span tracks +Description of problem: +I've just discovered that the Minix 1 and 2 operating systems no longer boot on qemu. + +Investigation reveals the following: + +- when Minix reads a 1024-byte block from disk, it issues a two-sector multitrack read to the FDC. +- if the FDC runs out of sectors when it's on head 0, it automatically switches to head 1 (this is correct). +- if the FDC runs out of sectors when it's on head 1, it stops the transfer (which is what is supposed to happen). + +What qemu does for the latter case is that it will automatically seek to the next track and switch to head 0. It then sets the SEEK COMPLETE bit in the status register. Minix sees this but isn't expecting it, because this shouldn't be emitted for reads and writes, and fails thinking it's an error. + +For example, here's the logging for such a transfer: + +``` +FLOPPY: Start transfer at 0 1 4f 11 (2878) +FLOPPY: direction=1 (1024 - 10240) +FLOPPY: copy 512 bytes (1024 0 10240) 0 pos 1 4f (17-0x00000b3e 0x00167c00) +FLOPPY: seek to next sector (1 4f 11 => 2878) <--- reads the last sector of head 1 track 0x4f +FLOPPY: copy 512 bytes (1024 512 10240) 0 pos 1 4f (18-0x00000b3f 0x00167e00) +FLOPPY: seek to next sector (1 4f 12 => 2879) <--- attempt to move to the next sector, which fails +FLOPPY: seek to next track (0 50 01 => 2879) <--- moved to next track, which shouldn't happen +FLOPPY: end transfer 1024 1024 10240 +FLOPPY: transfer status: 00 00 00 (20) <--- status report +``` + +Transfer status 20 is the SEEK COMPLETE bit. For a normal head switch, that should be 04 (with the NOW ON HEAD 1 bit set). + +For reference, see page 5-13 of the uPD765 datasheet here: https://www.cpcwiki.eu/imgs/f/f3/UPD765_Datasheet_OCRed.pdf It says: + +> IF MT is high, a multitrack operation is performed. +> If MT = 1 after finishing read/write operation on side 0, +> FDC will automatically start command searching for sector +> 1 on side 1 +Steps to reproduce: +1. `qemu-system-i386 --fda images/minix-2.0-root-720kB.img` +2. Press = to boot. +3. Observe the 'Unrecoverable Read` errors as the ramdisk is loaded. (The system will still boot, but will then crash if you try to do anything due to a corrupt ramdisk.) + +[minix-2.0-root-720kB.img.bz2](/uploads/77d34db96f353d92cdb2d01928b8fc01/minix-2.0-root-720kB.img.bz2) diff --git a/results/classifier/zero-shot/105/boot/1534978 b/results/classifier/zero-shot/105/boot/1534978 new file mode 100644 index 000000000..c32e528ef --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1534978 @@ -0,0 +1,39 @@ +boot: 0.868 +device: 0.777 +graphic: 0.680 +instruction: 0.668 +socket: 0.629 +semantic: 0.613 +vnc: 0.581 +network: 0.563 +other: 0.549 +mistranslation: 0.493 +KVM: 0.391 +assembly: 0.272 + +Windows command line -name cannot use = sign + +Windows command line: + +qemu.exe -L . -name "32-bit Emulation Session RAM=500MB" -boot c -m 500 -drive file=\\.\PhysicalDrive2 + +This fails to run. +If I remove the = sign in the -name quoted string it runs OK. + +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. + + +Cannot reproduce in recent version - please close. + +Thanks for checking! Closing now. + diff --git a/results/classifier/zero-shot/105/boot/1587535 b/results/classifier/zero-shot/105/boot/1587535 new file mode 100644 index 000000000..f3075fa74 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1587535 @@ -0,0 +1,52 @@ +boot: 0.860 +instruction: 0.817 +semantic: 0.774 +graphic: 0.759 +device: 0.758 +mistranslation: 0.724 +network: 0.668 +socket: 0.667 +assembly: 0.579 +other: 0.571 +vnc: 0.499 +KVM: 0.486 + +Incorrect MAS1_TSIZE_SHIFT in ppce500_spin.c causes incorrectly sized TLB. + +When e500 PPC is booted multi-core, the non-boot cores are started via +the spin table. ppce500_spin.c:spin_kick() calls +mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but +the created TLB entry is only 256KB. + +The root cause is that the function computing the size of the TLB +entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined +by latter PPC cores, specifically n to the power of FOUR * 1KB. The +result is then used by mmubooke_create_initial_mapping using +MAS1_TSIZE_SHIFT, but MAS1_TSIZE_SHIFT is defined assuming TLB entries +are n to the power of TWO * 1KB. I.e., a difference of shift=7 or +shift=8. + +Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since +the macro is used elsewhere. + +Removing the ">>1" from: + +> static inline hwaddr booke206_page_size_to_tlb(uint64_t size) +> { +> return ctz32(size >> 10) >> 1; + +and adding an appropriate comment is what I used as a work around: + +> static inline hwaddr booke206_page_size_to_tlb(uint64_t size) +> { +> // resulting size is based on MAS1_TSIZE_SHIFT=7 TLB size. +> return ctz32(size >> 10); + +Patch accepted. + +Commit title is: + +Eliminate redundant and incorrect function booke206_page_size_to_tlb + +Patch had been released with QEMU 2.7 + diff --git a/results/classifier/zero-shot/105/boot/1589 b/results/classifier/zero-shot/105/boot/1589 new file mode 100644 index 000000000..ac0696696 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1589 @@ -0,0 +1,23 @@ +boot: 0.943 +device: 0.873 +instruction: 0.811 +graphic: 0.775 +semantic: 0.619 +other: 0.585 +mistranslation: 0.541 +vnc: 0.449 +socket: 0.260 +network: 0.184 +assembly: 0.059 +KVM: 0.035 + +Crash when using qemu 8.0.0 version tcg mode +Description of problem: +Can I no longer use qemu in tcg mode? +When operating in tcg mode in all versions of 8.0.0, a crash occurs on the booting screen and the window closes (the window stops responding before closing). +Steps to reproduce: +1. Run qemu with -accel tcg option +2. enter the boot screen +3. The screen freezes and the window closes after a few seconds (at which point it becomes unresponsive) +Additional information: +I have not checked whether the same symptom occurs in Linux, and it occurs in all versions of 8.0.0 for Windows. diff --git a/results/classifier/zero-shot/105/boot/1589153 b/results/classifier/zero-shot/105/boot/1589153 new file mode 100644 index 000000000..652fb91c5 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1589153 @@ -0,0 +1,62 @@ +boot: 0.924 +socket: 0.868 +device: 0.827 +instruction: 0.779 +KVM: 0.767 +mistranslation: 0.756 +semantic: 0.740 +graphic: 0.713 +network: 0.704 +vnc: 0.674 +other: 0.603 +assembly: 0.514 + +qemu-system-x86_64 version 2.5.0 freezes during windows 7 installation in lubuntu 16.04 + +Hi! + +I have been using qemu - kvm for several years in different versions of ubuntu (lubuntu). I am trying to migrate from 15.04 to 16.04 and am having a problem. In particular, on my machine (a samsung series 9 with dual core i7 processor and 8gb ram) the following commands worked in 15.04 but do not work in 15.10 and 16.04. FYI, I tested them on a clean machine, where I have created a 60GB image file in its own partition.. In particular, I am using the command to start installing windows 7 and it works in a clean install of 15.04 (yesterday) but not in 15.10 (yesterday) or 16.04 (the day before). I do not get any error messages in my xterminal when running this and do not know how to check for windows error messages. By not working I mean that after loading files it gets to a windows screen and then stays there forever. + +The command lines used to invoke qemu is: +echo "*** Installing windows 7 virtual machine - Step 2" + + +echo "*** Try command for slow mouse" +export SDL_VIDEO_X11_DGAMOUSE=0 + +sudo qemu-system-x86_64 \ + -enable-kvm \ + -machine pc,accel=kvm \ + -cdrom /home/Archives/Software/OperatingSystems.Windows7HP.64/Windows7HP64_Install.iso \ + -boot d \ + -net nic,macaddr=56:44:45:30:31:34 \ + -net user \ + -cpu host \ + -vga qxl \ + -spice port=5900,disable-ticketing \ + -uuid 8373c3d6-1e6c-f022-38e2-b94e6e14e170 \ + -smp cpus=2,maxcpus=3 \ + -m 6144 \ + -name DrPhilSS9AWin7VM \ + -hda /mnt/Windows7Image/Windows7Guest.img \ + -localtime \ + -k en-us \ + -usb \ + -usbdevice tablet& +sleep 10 +spicy --host 127.0.0.1 --port 5900 + +Have a similar issue though on Ubuntu 14.04 (4.2.0-36-generic #42~14.04.1-Ubuntu) + +We use an automated appliance build process, to create qemu/KVM appliances. + +Ever since qemu 2.0.0+dfsg-2ubuntu1.24 security update, we are getting the same issue as mentioned above (Windows 7 Installation CD - X17-24281.iso, hangs after loading files). + +We had to pin to 2.0.0+dfsg-2ubuntu1.22 to resolve the issue. + + + +Please see http://ubuntuforums.org/showthread.php?t=2325843&p=13499322#post13499322 for a similar discussion and for a workaround. But please note that to the best I can tell it is still a bug. + +Phil + diff --git a/results/classifier/zero-shot/105/boot/1589257 b/results/classifier/zero-shot/105/boot/1589257 new file mode 100644 index 000000000..f33c3cef9 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1589257 @@ -0,0 +1,34 @@ +boot: 0.913 +network: 0.876 +device: 0.826 +instruction: 0.706 +graphic: 0.652 +mistranslation: 0.585 +vnc: 0.546 +other: 0.488 +semantic: 0.473 +socket: 0.411 +assembly: 0.221 +KVM: 0.127 + +Boot with OVMF extremely slow to bootloader + +I have used Arch Linux in the past with the same version (2.5.0), the exact same OVMF code and vars, and the exact same VM settings with no issues. Now with Ubuntu, I am having the issue where boot up until Windows takes about 10x longer. Every CPU thread/core allocated gets used 100% while this is happening. After that, everything operates as normal. There is no abnormal logs produced by qemu, or I don't know how to debug. + +Here are my settings: + +Host: +Ubuntu 16.04 +Qemu 2.5.0 +Relevant configs attached + +Guest: +Windows 10 +VirtIO raw disk image +VirtIO network +Typical VGA passthrough setup, everything operating normally + + + +I've solved the problem by using the ovmf package in apt instead of the firmware I've had before. Apparently, the older firmware was only compatible with an older kernel, and a newer kernel with the older firmware would cause the issue. + diff --git a/results/classifier/zero-shot/105/boot/1595 b/results/classifier/zero-shot/105/boot/1595 new file mode 100644 index 000000000..e187c65c6 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1595 @@ -0,0 +1,42 @@ +boot: 0.910 +graphic: 0.880 +device: 0.822 +other: 0.820 +KVM: 0.796 +instruction: 0.751 +semantic: 0.659 +vnc: 0.585 +socket: 0.584 +network: 0.399 +mistranslation: 0.337 +assembly: 0.316 + +CPU boot sometimes fails on big.LITTLE CPUs with varying cache sizes +Description of problem: +The RK3588 SoC has three core clusters; one with A55 cores, and the other two have A76 cores. The big cores have more L2 cache than the little cores, so the value of `CCSIDR` depends on the core that it is read from. + +In `write_list_to_kvmstate`, QEMU attempts to use `KVM_SET_ONE_REG` with an ID for `KVM_REG_ARM_DEMUX_ID_CCSIDR`, trying to set `CCSIDR` to a previously read value. + +Normally, that works fine, but if the host kernel has moved QEMU from one core cluster to the other, then the value will be different and `demux_c15_set` will return `EINVAL`, causing the entire `arm_set_cpu_on` to fail, and the guest kernel to print an error. + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/sys_regs.c?h=v6.2#n2827 + +I tried changing the condition for the `ok = false` line in `write_list_to_kvmstate` to `ret && r.id >> 8 != 0x60200000001100`. This causes all CPUs to initialize correctly in the guest, but obviously that's a hack. + +I assume that `CCSIDR` not being uniform across all CPUs means that the guest's copy of `CCSIDR` may be wrong, and so cache maintenance operations may not act on the entire cache. I do not know whether that could actually cause problems. Will QEMU need to find the maximum cache size across all CPUs and present that to guests? +Steps to reproduce: +On a SoC where big and little cores have different cache sizes (e.g. RK3588): + +```text +$ qemu-system-aarch64 -M virt -accel kvm -cpu host -smp 4 -nographic -kernel arch/arm64/boot/Image -append quiet +[ 0.001399][ T1] psci: failed to boot CPU1 (-22) +[ 0.001407][ T1] CPU1: failed to boot: -22 +[ 0.001685][ T1] psci: failed to boot CPU2 (-22) +[ 0.001691][ T1] CPU2: failed to boot: -22 +[ 0.001809][ T1] psci: failed to boot CPU3 (-22) +[ 0.001814][ T1] CPU3: failed to boot: -22 +``` + +The error is not always printed, because it depends on which core cluster the processes are scheduled on. + +Using `taskset -c 0-3` or `taskset -c 4-7` to force QEMU to stick to the little or big cores respectively makes the bug not reproduce. diff --git a/results/classifier/zero-shot/105/boot/1605045 b/results/classifier/zero-shot/105/boot/1605045 new file mode 100644 index 000000000..0bce76c13 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1605045 @@ -0,0 +1,29 @@ +boot: 0.858 +semantic: 0.835 +graphic: 0.820 +instruction: 0.742 +device: 0.731 +mistranslation: 0.680 +other: 0.662 +assembly: 0.576 +network: 0.511 +vnc: 0.489 +socket: 0.478 +KVM: 0.262 + +input-linux enter key stuck and/or broken + +Using new input-linux evdev passthrough feature of qemu (qemu 2.6.0) causes enter key to be stuck down after executing a shell script to launch qemu guest, resulting in repeated new lines in terminal. After a certain point of guest boot, the enter key is no longer pressed. However, at least under Gnome on Wayland, when pressing both left+right Ctrl keys to return keyboard back to the host, the enter key no longer functions. The enter key continues to function when control is under the guest, but never returns to functionality in the host until a reboot is performed. + +To further clarify: when keyboard control is under the host, enter key does not work while all other keys seem to work normally. When control of keyboard is under guest, all keys work normally including the enter key under the guest. This seems to be related to the enter key being stuck pressed after hitting enter to initially execute qemu / guest launch. + +I would also like to add: after performing a shutdown in the guest OS, qemu terminates as normal and keyboard control is automatically passed back to the host. However, the enter key continues to not function until the host is restarted. + +I can confirm this bug on Linux 4.7.1 with QEMU 2.6.0. A workaround is to change to a different TTY and then back to the X display, which fixes the enter key for the rest of the QEMU session. + +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/zero-shot/105/boot/1624726 b/results/classifier/zero-shot/105/boot/1624726 new file mode 100644 index 000000000..07939635c --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1624726 @@ -0,0 +1,53 @@ +boot: 0.775 +graphic: 0.763 +mistranslation: 0.757 +instruction: 0.710 +socket: 0.660 +network: 0.638 +semantic: 0.606 +device: 0.588 +other: 0.488 +KVM: 0.485 +vnc: 0.451 +assembly: 0.295 + +Integrator/CP regression after QOM'ification of integratorcp.c + +The following command line no longer works (i.e. the guest does not boot) with QEMU 2.7.0: + + qemu-system-arm -M integratorcp -m 128M -kernel HelenOS-0.6.0-arm32-integratorcp.boot + +The HelenOS image can be downloaded here: + + http://www.helenos.org/releases/HelenOS-0.6.0-arm32-integratorcp.boot + +I did git bisect and came to this revision: + +a1f42e0c9abc1028a8bb8686dbb3749fcd2d18e8 is the first bad commit +commit a1f42e0c9abc1028a8bb8686dbb3749fcd2d18e8 +Author: xiaoqiang.zhao <zxq_yx_007@163.com> +Date: Mon Mar 7 15:05:44 2016 +0800 + + hw/arm: QOM'ify integratorcp.c + + * Drop the use of old SysBus init function and use instance_init + * Remove the empty 'icp_pic_class_init' from Typeinfo + + Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + +:040000 040000 b73418ea3fb69ed72438776e78786456fe4c414c b483e8579037fdae7d136b2f4ada3147bdde92f1 M hw + +Upon closer inspection, I discovered that for some reason s->memsz in integratorcm_init() is zero. In the last good revision, this value was 128. As a temporary workaround, hardcoding it to this expected value fixes the problem. + +Turns out integratorcm_init() depends on the memsz property being already set, but that unfortunately is not the case as setting of memsz depends on integratorcm_init() having completed: + + dev = qdev_create(NULL, TYPE_INTEGRATOR_CM); <= calls integratorcm_init(), needs memsz + qdev_prop_set_uint32(dev, "memsz", ram_size >> 20); <= memsz set here, needs dev + + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e9d9ee234f852026d58 +... and been released with QEMU version 2.8 + diff --git a/results/classifier/zero-shot/105/boot/1638 b/results/classifier/zero-shot/105/boot/1638 new file mode 100644 index 000000000..439580ba0 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1638 @@ -0,0 +1,32 @@ +boot: 0.903 +graphic: 0.873 +instruction: 0.844 +device: 0.787 +other: 0.702 +semantic: 0.614 +vnc: 0.427 +KVM: 0.389 +mistranslation: 0.316 +network: 0.289 +socket: 0.267 +assembly: 0.099 + +BUG: Segmentation fault when -object memory-backend-file use readonly=on, prealloc=on together +Description of problem: +Segmentation Fault while booting VM. +Steps to reproduce: +1. set qemu boot params to `-object memory-backend-file,id=mem1,readonly=on,prealloc=on,mem-path=<any-img-file>,size=4G` +2. +3. +Additional information: +It might not be a bug, probably a feature. +The reason of this segfault is: +readonly would mmap the backend file using PROT_READ, make it readonly, +but the prealloc=on would touch_pages the memory mmaped by the file. +SO the segfault happens. + +But there is no docs about this segfault condition (the readonly and prealloc cannot be used together.) + +And maybe there is a way to solve this problem, I think. +Use mmap the memory backend file to PROT_READ|PROT_WRITE at the beginnning, after touch_pages, then mprotect the memory. +change the prot to readonly if required. diff --git a/results/classifier/zero-shot/105/boot/1652286 b/results/classifier/zero-shot/105/boot/1652286 new file mode 100644 index 000000000..2dd3487cf --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1652286 @@ -0,0 +1,51 @@ +boot: 0.921 +device: 0.807 +instruction: 0.785 +graphic: 0.782 +semantic: 0.730 +network: 0.721 +socket: 0.696 +vnc: 0.540 +assembly: 0.475 +other: 0.466 +mistranslation: 0.423 +KVM: 0.289 + +QEMU manpages provoke man(1) "can't break line" warnings + +I noticed when I ran 'man qemu' for version 2.8.0 I am getting this back at the terminal; + + +<standard input>:1674: warning [p 1, 188.5i, div `an-div', 0.2i]: can't break line +<standard input>:1677: warning [p 1, 188.8i, div `an-div', 0.2i]: can't break line + +This still reproduces with current QEMU: + +$ man -l build/qemu.1 >/dev/null +<standard input>:248: warning [p 3, 6.8i, div `an-div', 0.2i]: can't break line +<standard input>:376: warning [p 5, 2.5i, div `an-div', 0.2i]: can't break line +<standard input>:667: warning [p 8, 9.7i, div `an-div', 0.2i]: can't break line + +(and so on for more warnings) + +'man' produces these warnings when the input has a line which it is unable to cleanly line-break to fit in the output terminal (and so the number of warnings you get depends on the width of the terminal you're using). For instance this line: +.IP "\fB\-boot [order=\fR\fIdrives\fR\fB][,once=\fR\fIdrives\fR\fB][,menu=on|off][,splash=\fR\fIsp_name\fR\fB][,splash\-time=\fR\fIsp_time\fR\fB][, + +has no spaces in the whole of the part after "-boot" so it will typically not line break cleanly. + +Ideally we would fix this by arranging to have the groff output include '\:' zero-width break points between the ']' and '[' in this kind of long line so that it knew where to wrap. But I don't know if this is easy/possible with how we're generating the manpages at the moment. + +In any case the warning is harmless and the hard-wrapped lines are not too unreadable, so this is a minor issue. + + +Still happens with the new Sphinx-generated manpages, for exactly the same reason. + + + +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/214 + + diff --git a/results/classifier/zero-shot/105/boot/1688231 b/results/classifier/zero-shot/105/boot/1688231 new file mode 100644 index 000000000..69cd009bd --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1688231 @@ -0,0 +1,85 @@ +boot: 0.941 +other: 0.927 +instruction: 0.912 +graphic: 0.908 +device: 0.902 +assembly: 0.896 +semantic: 0.892 +socket: 0.876 +mistranslation: 0.852 +vnc: 0.826 +network: 0.821 +KVM: 0.814 + +[Qemu-ppc] sendkey is not working for any of the keystrokes + +sendkey option is not working for any of the keystrokes in ppc64le, + +Qemu version: +# qemu-img --version +qemu-img version 2.9.50 (v2.9.0-303-g81b2d5c-dirty) + +Qemu command line: +# qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 4G,slots=32,maxmem=32G -smp 16,maxcpus=32 -device virtio-blk-pci,drive=rootdisk -drive file=/var/lib/libvirt/images/f25-upstream-ppc64le.qcow2,if=none,cache=none,format=qcow2,id=rootdisk -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -redir tcp:2000::22 + +Guest booted successfully and logged in +Fedora 25 (Twenty Five) +Kernel 4.11.0-rc4 on an ppc64le (hvc0) + +atest-guest login: updatedb (5582) used greatest stack depth: 9568 bytes left +root +Password: +Last login: Mon Mar 27 01:57:51 on hvc0 +[root@atest-guest ~]# + +Qemu monitor: +# telnet 127.0.0.1 1234 +Trying 127.0.0.1... +Connected to 127.0.0.1. +Escape character is '^]'. +QEMU 2.9.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey ret + +But from the console, I couldn't observe the keystroke a or return. + +I see this happening in ppc64le and x86_64 with QEMU v2.11.0-1684-ga6e0344fa0. The keystrokes are being sent to tty1: + +in x86_64: + +./v2.11.0-1684-ga6e0344fa0/bin/qemu-system-x86_64 -enable-kvm -m 512 -kernel vmlinuz -initrd initramfs.img -chardev serial,id=s1,path=/dev/pts/10 -mon chardev=s1 -qmp tcp:localhost:4444,server,nowait -vga none -nographic -append "console=ttyS0 i8042.debug" + +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey b +(qemu) sendkey c +(qemu) sendkey ret + +# cat /dev/tty1 +abc + +--- +same thing with input-send-event: + +{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "a" } } }]} +{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ret" } } }]} + +# cat /dev/tty1 +abc +a + + +I'm not sure what is the expected behavior when using two input sources in this way (serial line + PS/2 keyboard). I'm inclined to say that the keys should indeed not be seen in the serial console. + +Yes, you are right: sendkey does not send keys to the serial console. I had a chat with Peter last year about it in the IRC where the explained: + +<danielhb> hey! quick question: is the 'sendkey' monitor command supposed to send the key presses to the serial console of the guest when running with -nographics ? The command works fine with VGA/VNC graphics but the serial console doesn't show the character key being sent by the command +<pm215> no, 'sendkey' sends a key to whatever physical keyboard is currently being emulated, regardless of what is being done with serial devices +<danielhb> pm215, I 've debugged the code and saw that the scancodes are being sent to the emulated keyboard via sendkey. I just wondered why the serial console doesn't show the keysyms but the VGA does +<pm215> because keyboards don't plug into serial terminals +<pm215> this is like having a server with a PC keyboard plugged into it and also a serial port which you're using as the serial terminal +<pm215> pressing a key on the PC keyboard doesn't do anything to the serial terminal +<danielhb> pm215, that makes sense, haven't thought of that. thanks! + +Given that the bug report was created around a wrong assumption, this should be closed. + diff --git a/results/classifier/zero-shot/105/boot/1689 b/results/classifier/zero-shot/105/boot/1689 new file mode 100644 index 000000000..49047d880 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1689 @@ -0,0 +1,24 @@ +mistranslation: 0.968 +boot: 0.943 +device: 0.890 +graphic: 0.882 +other: 0.873 +semantic: 0.851 +instruction: 0.838 +network: 0.560 +vnc: 0.547 +socket: 0.305 +assembly: 0.287 +KVM: 0.270 + +memory backend file unnecessarily requires write permission while it is only mapped privately +Description of problem: +One day I wanted to boot the machine with physical memory initialized with a file, in a copy-on-write style. That is why I tried out `-mem-path` and `-object memory-backend-file`. Actually `-mem-path` already works if not considering that qemu dislikes the backing file being readonly and requires it to be writeable even when only private mappings are used here. + +I sadly found out that when using memory-backend-file, and when `share=off`, if `readonly=on`, then file is `open`ed with `O_RDONLY` and mmap prot is `PROT_READ`; if `readonly=off`, then the file is `open`ed with `O_RDWR` and mmap prot is `PROT_READ|PROT_WRITE`. I want `O_RDONLY` and `PROT_READ|PROT_WRITE` but I cannot find it anywhere. + +In my opinion, expected behavior should be that if `share=off`, the file can already be opened with `O_RDONLY` no matter what prot the mmap is. That is how linux `MAP_PRIVATE` works - basically copy on write. When I only need copy on write for the content of file, why do I require write permission for it? + +Now I cannot find a setup that opens the file with `fd=open(*, O_RDONLY)` and mmap it with `mmap(*, *, PROT_READ|PROT_WRITE, MAP_PRIVATE|*, fd, *)`. + +Tell me if I misunderstood linux (for example certain file behave differently if one open with O_RDONLY and this behavior is necessary) or qemu or other posix systems where copy-on-write does not work like this. diff --git a/results/classifier/zero-shot/105/boot/1694808 b/results/classifier/zero-shot/105/boot/1694808 new file mode 100644 index 000000000..7f577f201 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1694808 @@ -0,0 +1,56 @@ +boot: 0.648 +device: 0.610 +socket: 0.507 +vnc: 0.471 +semantic: 0.451 +instruction: 0.412 +other: 0.361 +KVM: 0.357 +network: 0.316 +mistranslation: 0.299 +graphic: 0.291 +assembly: 0.110 + +Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up + +Using qemu-kvm as shipped with Ubuntu 16.04, I cannot get a passed-through USB Host Keyboard to work at boot-up using the Q35 platform. + +My minimal example to verify this bug is the following: + + qemu-system-x86_64 -M q35 -m 128 -cdrom mini.iso -usb -usbdevice host:04ca:005a -vnc :1 -display none + +Using a noname USB Keyboard with ID 04ca:005a and the Ubuntu 16.04 NetBoot mini.iso, I can see the boot screen of the Ubuntu ISO through VNC, but pressing the arrow keys doesn't do anything. + +By taking out the "-M q35" parameter, QEMU switches to the traditional i440FX system. The passed-through USB Host Keyboard works there, but the old platform is no option for me. + +Have you tried whether it works with the latest upstream version of QEMU (currently version 2.9) - since you've marked this as upstream QEMU problem, too? + +Thanks Thomas, definitely worth to check. +@Colin - if you want a quick and easy short with qemu 2.8 you can try [1]. + +[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive + +Same problem with qemu 2.8 from Ubuntu Cloud Archive. +Is that enough to consider the bug highly likely in latest upstream version too? I don't have a QEMU build system at hand right now.. + +Doesn't happen when adding another UHCI controller and explicitly connecting the keyboard to it, like: -device vt82c686b-usb-uhci,id=myusb -device usb-host,bus=myusb.0,hostbus=3,hostaddr=2 + +Is QEMU just incorrectly connecting my full-speed USB keyboard to USB 2.0 EHCI instead of USB 1.x UHCI? +Or is SeaBIOS lacking support for anything involving USB 2.0 controllers, even simple HID devices? + +Hi, + +Seeing this same thing! And I'm on Ubuntu 20.10, so pretty current :-). vt82c686b-usb-uhci doesn't seem to be accessible any more, but trying qemu-xhci => no joy, still have to reset the VM after each startup, to get the keyboard and mouse working. + +Is this expected? + +Thanks! + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/144 + + diff --git a/results/classifier/zero-shot/105/boot/1696 b/results/classifier/zero-shot/105/boot/1696 new file mode 100644 index 000000000..83dba8b3b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1696 @@ -0,0 +1,52 @@ +boot: 0.708 +instruction: 0.682 +device: 0.664 +graphic: 0.480 +semantic: 0.428 +vnc: 0.318 +network: 0.315 +socket: 0.296 +other: 0.264 +assembly: 0.096 +KVM: 0.073 +mistranslation: 0.050 + +Linux kernel hangs rarely when booting on the latest qemu +Description of problem: +(Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2213346) + +In Fedora we have noticed that the latest Linux kernel (rarely) hangs when booting +on the latest qemu. It hangs after printing: + +``` +[ 0.070120] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.070120] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.070120] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.070120] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.070120] Spectre V2 : Mitigation: Retpolines +[ 0.070120] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.070120] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT +[ 0.070120] Spectre V2 : Enabling Speculation Barrier for firmware calls +[ 0.070120] RETBleed: Mitigation: untrained return thunk +[ 0.070120] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.070120] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl +[ 0.070120] Freeing SMP alternatives memory: 48K +``` + +The next line which would be printed (if it didn't hang) is: + +``` +[ 0.070794] smpboot: CPU0: AMD Ryzen 9 3900X 12-Core Processor (family: 0x17, model: 0x71, stepping: 0x0) +``` + +We've seen this hang on both AMD and Intel. It probably happens one in every 300 boots. +Steps to reproduce: +By far the easiest way to reproduce this is to just run guestfish in a loop: + +``` +$ while guestfish -a /dev/null -v run >& /tmp/log; do echo -n . ; done +``` +Additional information: +The full qemu command is rather long but you can find it in this log file: + +https://bugzilla-attachments.redhat.com/attachment.cgi?id=1969620 diff --git a/results/classifier/zero-shot/105/boot/1718719 b/results/classifier/zero-shot/105/boot/1718719 new file mode 100644 index 000000000..d382ac10f --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1718719 @@ -0,0 +1,147 @@ +boot: 0.940 +instruction: 0.937 +semantic: 0.928 +device: 0.914 +mistranslation: 0.912 +other: 0.906 +assembly: 0.887 +graphic: 0.881 +vnc: 0.847 +network: 0.838 +KVM: 0.824 +socket: 0.763 + +qemu can't capture keys properly under wayland + +This appears to be different than the previous similar bugs; patches do look to be applied to use libinput in the wayland case. Still: + +unknown keycodes `(unnamed)', please report to <email address hidden> + +I am using qemu-system-x86 1:2.10+dfsg-0ubuntu1 + +Many key inputs work correctly, but at boot the system will not properly catch the arrow keys, the above error shows up immediately after hitting Esc (for instance) to get to the boot menu. Booting from CD onto a daily Ubuntu desktop image, I can't navigate the splash menu. + +The same works correctly through virt-manager (which uses spice AFAICT, but wayland tends to crash when running virt-manager), and things work if I switch my session to Xorg rather than wayland. + +Hi Mathieu, +thanks for the report but since we are up-to-date with qemu and I can't find an obvious breakage we might have introduced for this, this should go to qmeu-upstream in this case. + +Furthermore are these actually two issues?: +#1 - wayland crashes under spice + more of a wayland bug then I'd expect, but upstream qemu + might have heard of it and have good pointers +#2 - new qemu does not recognize keys correctly with the default (SDL I'd think) frontend? + That is worth to report upstream qemu for sure. + +I added an upstream qemu (and a wayland) task and you can help them to recreate in case they have questions on how exactly to do so. + +I wanted to write steps to reproduce, which should be as simple as: +$ wget http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso +$ qemu-system-x86_64 -m 512 -boot d -cdrom artful-desktop-amd64.iso + +But that works for me as seen in the attached video. +@Mathieu - can you elaborate how to trigger the missing key issue? + +Hi! I am running Artful on my X1 Carbon Gen3. + +I downloaded the Ubuntu Server Artful final beta and attempt to do an install with the following qemu cli: + +$ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -boot d -hda vdisk.img -cdrom artful-server-amd64.iso -monitor stdio + +Trying to use the arrow key at the first menu does not work and errors with the unknown keycodes error. However, if I issue the `sendkey down` command from the qemu CLI it works as expected. + + +So it is likely a wayland <-> SDL thing. +@Desktop Team could you take alook into this - the repro steps in c#2 are pretty easy I'd think but none of us would know where in the UI stack to look for. + +Upstream bug is probably https://bugs.freedesktop.org/show_bug.cgi?id=102475 ? + +Now the question is should the patch be dropped or wait for a fix from upstream. I'm leaning towards the first option, since artful is about to be released. + +is the patch providing any user visible improvement? if not it would probably make sense to delay including it to next cycle + +Actually, this bug would affect current 1.19-branch too since the patches are backported there as well. You can test ppa:canonical-x/x-staging to verify, which has xorg-server from current stable branch. + +Status changed to 'Confirmed' because the bug affects multiple users. + +The Ubuntu maintainer backported the recent change to add keyboard grabbing to xwayland, with that change the keyboard arrow keys stop working in kvm + +Can you please elaborate of what exactly has been backported and the resulting patches? + +Which Wayland compositor do you use? + +It's worth noting that the xwayland patches in themselves won't make a difference *unless* the Wayland compositor implements the corresponding protocol, and I am aware of none for now (the patch for mutter is still pending). + +The Ubuntu diff is +http://launchpadlibrarian.net/334552966/xorg-server_2%3A1.19.3-1ubuntu3_2%3A1.19.3-1ubuntu4.diff.gz + +it looks like the backported commits are + +xwayland-pointer-confine.diff ++d5e2f271ad93e50 xwayland: Remove two unused proc pointers. ++ca17f3e9fd3b59f xwayland: Lock the pointer if it is confined and has no cursor ++513e3bd3870fdb8 xwayland: Update root window size when desktop size changes ++fafdb0cc9697eb5 xwayland: "Accept" confineTo on InputOnly windows ++c217fcb4c4640ff xwayland: Allow pointer warp on root/None window + +xwayland-add-grab-protocol-support.diff +https://cgit.freedesktop.org/xorg/xserver/commit/?id=0a448d133 + +Ubuntu doesn't have any compositor change, it's standard GNOME 3.24 so there is must be something wrong and it does make a difference without implementing the protocole. + +Note that reverting 0a448d133 does fix the issue + +Tried reproducing the issue with the arrow keys using the current Xwayland from master with mutter/gnome-shell from master, using qemu-kvm with SDL backend (-display sdl) but failedto reproduce, all keys (including the arrow keys) work fine in the guest. + +Created attachment 133910 +Test patch + +Can you try the attached patch (this is for testing purpose *only*) and report back if that makes any difference? + +With this patch, if the compositor has no support for Xwayland keyboard grab protocol as you said you haven't in Ubuntu, Xwayland won't set up its grab handler at all. + +the patch doesn't seem to make a difference + +Well, what this patch does is disabling any specific grab handler if the Xwayland grab protocol is not available, by postponing the setup of those handler until Xwayland can bind to the relevant interface as advertised by the compositor. + +If the compositor doesn't support the Xwayland grab protocol, then all those routines are not "enabled" in Xwayland, I don't see how they could break anything if not used... + +Unfortunately, we cannot tell whether or not the compositor supports the Xwayland grab protocol using something like weston-info because, for security reasons, the compositor will (should) only advertiset he given protocl to Xwayland alone and hide it to any other client. + +So, if that patch makes no difference, it means that: + + - The Wayland compositor claim to support Xwayland grab protocol but is buggy and doesn't send all key events as expected + + - Or the problem is completely unrelated to this patch. + +So next step for you is to: + + - Check the actual patches applied to mutter in Ubuntu + - Check what happens at the protocol level + +To do so, yo can use the envvar WAYLAND_DEBUG prior to start gnome-shell (which will spawn Xwayland) so that we can tell what globals are listed in the wl_registry and see if "zwp_xwayland_keyboard_grab_manager_v1" is one of them. + +e.g., from a console: + + $ WAYLAND_DEBUG=1 dbus-run-session -- gnome-shell --display-server --wayland |& tee ~/wayland-debug.log + +The wl_registry globals will be listed at the beginning of the log so that should be enough to tell if the compositor claims to be supporting "zwp_xwayland_keyboard_grab_manager_v1". + +Then, you can start qemu-kvm as usual and try to press the keys that do not work, those will be captured in the log as well, so we can tell if the compositor sends those key events to the client (Xwayland, in which case the problem lies in Xwayland) or not (in which case the problem lies in the compositor). + +Please attach the "wayland-debug.log" to this bugzilla once you've performed those tests (but make sure you don't type any sensitive data in any application while the log is being captured as any key event will be logged). + +the issue isn't there when using your debug command but it begins in that session if gsd-media-keys is started... I'm calling it a week now but I'm going to poke to it a bit more on monday + +-- GitLab Migration Automatic Message -- + +This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. + +You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/706. + +upstream can't reproduce this bug, so I wonder if the backport was incomplete and it's fixed in the current release (1.20.8), could you test again? + +Is there still an issue left here for upstream QEMU? + +Since there wasn't a reply to my question since more than half a year, I'm assuming that this does not affect upstream QEMU anymore. Thus I'm removing upstream QEMU from this ticket now. + diff --git a/results/classifier/zero-shot/105/boot/1732177 b/results/classifier/zero-shot/105/boot/1732177 new file mode 100644 index 000000000..4d9515252 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1732177 @@ -0,0 +1,23 @@ +boot: 0.697 +device: 0.674 +graphic: 0.587 +instruction: 0.565 +socket: 0.560 +other: 0.515 +mistranslation: 0.489 +network: 0.464 +semantic: 0.419 +vnc: 0.198 +assembly: 0.113 +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/zero-shot/105/boot/1734474 b/results/classifier/zero-shot/105/boot/1734474 new file mode 100644 index 000000000..d1bb421dc --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1734474 @@ -0,0 +1,72 @@ +boot: 0.640 +device: 0.525 +socket: 0.522 +semantic: 0.484 +other: 0.427 +vnc: 0.351 +instruction: 0.330 +graphic: 0.282 +mistranslation: 0.270 +network: 0.245 +KVM: 0.160 +assembly: 0.083 + +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/zero-shot/105/boot/1745 b/results/classifier/zero-shot/105/boot/1745 new file mode 100644 index 000000000..7d2a8e9d1 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1745 @@ -0,0 +1,80 @@ +boot: 0.935 +device: 0.921 +instruction: 0.721 +graphic: 0.710 +network: 0.689 +socket: 0.689 +vnc: 0.515 +KVM: 0.492 +semantic: 0.486 +mistranslation: 0.468 +assembly: 0.283 +other: 0.232 + +qemu-system-sparc64 v8.0.2 failed to read the file system. +Steps to reproduce: +1. Run qemu-system-sparc64 with the following command line. + `qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2` +2. The system will report a issue "Could not open option rom 'pflash0': No such file or directory" +3. Then, enter the boot command on the boot loader. +4. The command failed with following message. +``` +Boot device: vdisk File and args: +Bad magic number in disk label +Can't open disk label package + +Can't open boot device +``` +Additional information: +``` +$ qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2 +Could not open option rom 'pflash0': No such file or directory +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +Bad magic number in disk label +Can't open disk label package + +Can't open boot device + +ok +``` + +It works fine with the previous qemu-system-sparc64 version. + +``` +$ qemu-7.2.3/build/qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54. +FCode UFS Reader 1.12 00/07/17 15:48:16. +Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot +Loading: /platform/sun4v/ufsboot +SunOS Release 5.10 Version Generic_118822-23 64-bit +Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Hostname: unknown + +unknown console login: +``` diff --git a/results/classifier/zero-shot/105/boot/1748296 b/results/classifier/zero-shot/105/boot/1748296 new file mode 100644 index 000000000..cab7dadc5 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1748296 @@ -0,0 +1,95 @@ +boot: 0.673 +device: 0.671 +semantic: 0.667 +other: 0.644 +instruction: 0.641 +mistranslation: 0.640 +network: 0.584 +graphic: 0.581 +assembly: 0.566 +KVM: 0.560 +socket: 0.552 +vnc: 0.462 + +TCG throws Invalid Opcode when executing x86 BMI shlx instruction + +I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. + +The code executes correctly and passes the test under KVM. + +I have created a complete repro here: https://github.com/doug65536/qemu-bmibug + +The makefile has the following utility targets: + +debug-kvm: Build and run the VM using KVM and wait for gdbstub attach + +run: Run the test case with TCG, make fails if the test fails. (It will fail) + +run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) + +debug: Build and run the VM with TCG and wait for GDB attach + +attach-gdb: Run GDB and attach to KVM gdbstub + +The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. + +You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. + +I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. + +I hit this today on QEMU head. The problem appears to crop up when: + + 1. Decoding a VEX instruction (see [1]) that uses the 0x66 mandatory + prefix; and + + 2. The OSFXSR bit in CR4 is clear (that is, SSE is disabled) + +This means that x86_64 instructions such as: + + c4 e2 f9 f7 c0 shlxq %rax, %rax, %rax + +fail. Similar instructions the use a different mandatory prefix +(such as `shrxq`, which uses prefix 0xf2) work fine. + +Most operating systems presumably set the OSFXSR bit fairly early on, which I +guess is why this problem isn't likely to be seen except in low-level or early +boot code. + +The culprit appears to be the block of code in `gen_sse` [2]: + + if (is_xmm + && !(s->flags & HF_OSFXSR_MASK) + && ((b != 0x38 && b != 0x3a) || (s->prefix & PREFIX_DATA))) { + goto unknown_op; + } + +Removing the check `... || (s->prefix & DATA_DATA)` causes QEMU to correctly +translate the instruction, and allows doug16k's test above to pass. + +I must confess, I'm not clear what this clause was testing for. My best guess +is that early code (e.g. 4242b1bd8ac) required it to avoid accessing invalid +opcode tables, but we seem to be handling that more gracefully today (e.g. +[3]), so I suspect it is no longer needed. + +[1]: https://wiki.osdev.org/X86-64_Instruction_Encoding#VEX.2FXOP_opcodes +[2]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3078 +[3]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3696-L3700 + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +Ah, never mind, posted the text before seeing that it still affects people in 2021 ... so I'm not changing this bug to "Incomplete". Sorry for the noise. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/51909241d26fe6fe18a + diff --git a/results/classifier/zero-shot/105/boot/1753314 b/results/classifier/zero-shot/105/boot/1753314 new file mode 100644 index 000000000..7e971c7ab --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1753314 @@ -0,0 +1,67 @@ +assembly: 0.986 +boot: 0.985 +other: 0.984 +semantic: 0.983 +mistranslation: 0.982 +socket: 0.980 +instruction: 0.979 +device: 0.976 +graphic: 0.975 +vnc: 0.971 +KVM: 0.954 +network: 0.900 + +UART in sabrelite machine simulation doesn't work with VxWorks 7 + +The imx_serial.c driver currently implements only partial support for the i.MX6 UART hardware. In particular, it does not implement support for the Transmit Complete Interrupt Enable bit in the UCR4 register. The VxWorks 7 i.MX6 serial driver depends on the behavior of this bit in actual hardware in order to send characters through the UART correctly. The result is that with the current machine model, VxWorks will boot and run in QEMU but it's unable to print any characters to the console serial port. + +I have produced a small patch for the imx_serial.c module to make it nominally functional with VxWorks 7. It works well enough to allow the boot banner to appear and for the user to interact with the target shell. + +I'm not submitting this as a patch to the development list as I'm not fully certain it complies with the hardware spec and doesn't break any other functionality. I would prefer if the maintainer (or someone) reviewed it for any issues/refinements first. + +I'm attaching the patch to this bug report. A copy can also be obtained from: + +http://people.freebsd.org/~wpaul/qemu/imx_serial.zip + +This patch was generated against QEMU 2.11.0 but also works with QEMU 2.11.1. + + + +Hi. Thanks for this patch. I've had a quick look at it against the imx datasheet, and here are my comments: + +* Firstly, we can't do anything with this patch without a Signed-off-by: line from you. In QEMU's process this is how people submitting code state that you're legally OK to contribute the code under QEMU's license and for it to go into QEMU. + + * Secondly, it would be very helpful if you could send patches as a simple patch format, rather than as a zipfile, and to the QEMU mailing list. https://wiki.qemu.org/Contribute/SubmitAPatch has our guidelines on this. + + * Simply adding a new VMSTATE_UINT32() field will break migration. It's better to put the new field into its own vmstate subsection so that this doesn't happen; see docs/devel/migration.rst. If we don't care about cross-version migration we could just bump the version_id/minimum_version_id fields. + + * If you run scripts/checkpatch.pl over your patch it should warn you about minor coding style issues. For instance we prefer all if() statements to use {}, even if there's only one line in them. + + * Your change to imx_update() does this: ++ if (s->ucr4 & UCR4_TXEN) ++ flags |= USR1_TRDY; + +but that isn't what the spec says UCR4_TXEN does; it says we raise an interrupt only if UCR4_TXEN and USR2_TXDC are both high. + + * the imx_update() function is already rather confused in how it handles the 'flags' variable, and this change extends that confusion. The function is trying to treat 'flags' as a single set of interrupt flag bits, but the device doesn't actually have a single unified set of interrupt flags like that, they're spread over UTS and USR1 and USR2. The code as it is looks odd -- should USR1.TXMPTYEN == 0 really suppress USR1_TRDY interrupts ? I suspect this is a bug, and we should also clean things up to make 'flags' be a bool. + + +As I said before: + +"I'm not submitting this as a patch to the development list as I'm not fully certain it complies with the hardware spec and doesn't break any other functionality." + +What I'm trying to say here is that while I may have been able to cobble together a hack to make the UART nominally compatible with VxWorks, I do not understand the hardware or QEMU well enough to really fix this the right way. Even with my hack, every once in a while when printing lots of data on the console, the output from the UART will stall unless I press a key on the serial port, and I don't know why it does that. I did try to investigate it a little but wasn't able to make much progress. (My suspicion is that it has something to do with the fact that the imx_serial module doesn't implement FIFO support, but even if that's true I don't know how to fix it.) + +Even so, I figured it was still worth it to attach my changes to the bug report so that somebody who is better at this than me could use it as a starting point, and so that anybody else who might want to experiment with VxWorks using the QEMU sabrelite machine model wouldn't be totally stuck like I was. + +In short, the changes I made are good enough for my own needs (the output stalls don't happen often enough to really bother me), but they're not a fully debugged fix. That's why I filed a bug report instead of just submitting a patch in the first place: I wanted somebody sexier than me to create a fully debugged fix. + +That's fine; Andrey Smirnov has taken your patch as a basis for a more cleaned-up set of changes: +http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04608.html +http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04609.html +What we would like from you is a Signed-off-by: line to say that you're happy for us to do that, please. (If you have a chance to test that it works for you that would also be great.) + + +Now fixed in git master, should be in 2.12. + + diff --git a/results/classifier/zero-shot/105/boot/1754656 b/results/classifier/zero-shot/105/boot/1754656 new file mode 100644 index 000000000..9f85354e5 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1754656 @@ -0,0 +1,187 @@ +boot: 0.847 +device: 0.844 +assembly: 0.838 +instruction: 0.829 +semantic: 0.829 +other: 0.827 +mistranslation: 0.803 +KVM: 0.779 +vnc: 0.778 +graphic: 0.739 +network: 0.731 +socket: 0.701 + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM + +Version: + +QEMU emulator version 2.11.1 + +Introduction: + +This is call for action to get attention of somebody in QEMU project/organization, who is capable of actually doing something about this pressing issue. This might be TLDR for some, but that's only because of the complexity of the issue. Please read this with open mind. + +Problem: + +As QEMU users, we need (it is a requirement) to have some mechanism in place, to somehow convert simple POSIX signal sent form host, into graceful ACPI shutdown of the guest. This signal, due various historical reasons and daemon design, must be SIGTERM foremost. + +Status quo: + +After wading through mailing lists and bug tracker I concluded that this is "political" problem and I am in search of somebody, a "politician" within QEMU project, who will help us reach conclusion to this problem. + +First I will present analysis of the situation, and then propose some suggestions for solutions. + +Even then, any of these proposals might be, potentially, seen as problematic in eyes of QEMU maintainers, developers, dictators, long term users or their dogs. + +That's why we need somebody willing, "higher up the chain" or whatever, to orchestrate discussion so that we can actually reach consensus in the matter, solution that is acceptable to **everyone**. + +Analysis: + +Each QEMU emulated virtual machine (vm), running in the host system, is represented by single qemu-* process (followed by several threads). Thus for all intents and purposes, any such instantiated vm, must be seen as it's own, separate, daemon. + +I repeat running qemu-* vm **is a daemon**. + +QEMU provides incredible IO redirection capabilities, so we don't need to get into issues of logging, console and monitor redirections and such, as this is already a (perfectly) solved problem. + +What we cannot currently do, at least easily, reliably and simply, is to shutdown guest gracefully from "outside". + +That is not a problem for those of us, who use some kind of higher level orchestrator (I think one of them is virsh, but this is not important in this matter) that takes care of this by communicating with QEMU directly (I guess this is done by sending commands to internal monitor by pipe (or socket) held open by mentioned orchestrator). + +However it is a problem for those of us, who run qemu-* processes bare or supervised. + +Let's say I, as administrator, want to implement vm instance as supervised service. +I can use any supervisor for that, systemd even. Let us not get into into supervisor wars. + +At basic level almost all supervisors are similar. Supervisor usually is yet another process, that "leads" the qemu-* one. + +In case of systemd it is PID1, but in case of other supervision schemes, like daemontools, runit, s6 or nosh, it is separate '*supervise' process instead. + +When such supervisor is tearing down the service, "leading"/supervising, parent will send SIGTERM to it's child qemu-* process. + +This behaviour is almost universal among all supervisors. This due the fact, that it is customary for daemons to cease all operations and exit cleanly when receiving SGITERM signal. If daemon child fails to exit within configurable timeframe, supervisor deals with it by the means of SIGKILL. + +As such, one would expect, similarly, for qemu-* process to send ACPI shutdown event to guest internally (roughly equivalent to 'system_powerdown' monitor command) on SIGTERM reception. + +But this is not what happens! + +Instead, qemu-* just flushes pending IO and kills the guest instantly. + +Then, on next vm "boot", guest detects this as power failure event, and performs fsck checks and other things, it is supposed to do in case of power failure. We are not mentioning possible data loss that might have happened due to this behavior, either. + +Some supervisors (like systemd for example) might provide feature to change "termiante operations" signal to something else like SIGTERM, but that is not universal supervisor feature by any means. Default action for any proper daemon is to cleanly terminate on SIGTERM. + +That is why we need ability to somehow instruct QEMU to **always** perform graceful ACPI shutdown on SIGTERM. + +Potential reply to this bug saying that one should send 'system_powerdown' over monitor connection won't fly! + +As it is not always possible (nor required) to hook into supervisor's signal processing (main reason being intentional supervisor simplicity in search of extreme reliability, and de facto standardized behavior of daemons to exit cleanly on SIGTERM). + +More over, in situations like machine reboot, most supervisors won't play around with signal remapping, they will simply send out SIGTERM to all supervised processes. We want our qemu-* instances to come up undamaged from such action (on next host reboot) and not have them stuck in fscks (or worse - ending up damaged) . + +If this can be extended further, inside QEMU, with internal signal to action remapping, the better, but supporting graceful shutdown on SIGTERM is hard requirement. + +Proposed solutions: + +0. modify QEMU so that it emits ACPI shutdown event equivalent to 'system_powerdown' monitor command by default + - this seems to be a "no go", with backwards compat. and "current users expectations" + cited as the reasons + - I won't go into a fact that QEMU changed option handling without BOLD notice few times + +1. add single switch '-graceful-shutdown-on-sgiterm' + - this was rejected when person tried to submit patch implementing something similar + to what I am requesting, only bound to SIGHUP + - that person (implementing graceful poweroff on SIGHUP) was wrong, almost no + supervision scheme in existence sends out SIGHUP on service termination request, + although all supervisors are able to send out SIGHUP when instructed + - in daemons SIGHUP is usually reserved for "daemon reload" which can be interpreted + like "reboot" in QEMU context + - if we see qemu-* proces for what it is, a daemon, it must react properly to SIGTERM foremost + +2. add ability to map internal monitor action commands to few signals like SIGTERM, SIGHUP, SIGINTR, SIGUSR1, SIGUSR2, SIGALARM etc + - this seems like best solution to me, that allows us to satisfy both + backwards compat. and "current users" requirement, yet allows us + to use qemu-* with proper supervision, and it even adds something extra + (I know some of these signals are used internally by QEMU) + - QEMU already has options parsing infrastructure in place to handle this nicely, something like: + : -signal SIGTERM,monitorcommand=system_powerdown -signal SIGHUP,monitorcommand=system_reset + would be great in this case + +3. add ability to map signals to executable scripts + - with this scheme QEMU would spawn child on signal reception, and this + script would then be used to perform the action + - this solution is most complex, most convoluted and most "flexible" + - for example with definition like this: + : -signal SIGTERM,script=signals/sigterm + qemu would perform this sequence of tasks: + - on SIGTERM qemu-* would spawn child script ./signals/sigterm + - this script would then pull out monitor fd descriptor from some kind of fd holder + - would write 'system_powerdown' command into monitor fd and terminate + - qemu-* would then read the command from monitor + - qemu-* would then interpret read-in command and gracefully terminate + - option parsing infrastructure is in place and QEMU is able to spawn and reap it's own children + which is proven by network up/down scripts + + +Of these, it seems that 0. and 1. are simplest to implement, yet "politically" unimplementable. + +More over QEMU people seem to be hard set on SIGTERM meaning "killing unresponsive guest". + +2. seems like most reasonable proposal that has potential to make everyone happy. It is also most reliable because internal QEMU command dispatch would have least chances to fail. + +3. is most flexible and can also be combined with 2. Reliability wise, there is slight chance signal handling script will fail to execute, leaving qemu-* at the mercy of supervisor (timeouted SIGKILL). + +Both 2 and 3 should probably provide configurable timeout after which QEMU would perform default action (eg. as it does now). + +Conclusion: + +I hope QEMU project members understand severity of the issue and are open to listed solutions. It might be that proposed solutions don't match QEMU project "spirit" perfectly. If so, I urge people capable of resolving this, to propose their versions. + +The fact is, that with proliferation of systemd, popularity of alternative supervisors is on the rise as well, but even under systemd, unintuitive handling of SIGTERM by bare QEMU processes is a problem. + +Further Reading: + +https://patchwork.kernel.org/patch/9626293/ + + - Daniel P. Berrange says: + "Because QEMU already designate that as doing an immediate stop - ie it'll + allow QEMU block layer to flush pending I/O, but it will not wait for the + guest to shutdown. If we change that behaviour we'll break anyone who + is already relying on SIGHUP - qemu might never exit at all if the guest + ignores the ACPI request" + + - this behaviour is incorrect if we perceive qemu-* process as daemon, proper, + yet it is, supposedly, entrenched in QEMU userbase + - signals remapping capability would allow us to keep the "old" behavior for entrenched users + while it would allow administrators and orchestrator writers to select signal disposition + they actually need + +https://bugs.launchpad.net/qemu/+bug/1217339 +and +https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html + + - on my QEMU version of 2.11.1 SIGTERM just kills the guest without proper shutdown + - although thread says exit is graceful + - dicussion is problematic in several ways: + - SIGTERM is not intended to "terminate unresponsive guest" eg "terminate daemon uncleanly" + in any sane daemon in existence + - it means "terminate gracefully" + - if "terminate unresponsive guest" was true meaning of SIGTERM, databases like + mariadb or postgers would kill themselves on SIGTERM, leaving data in + inconsistent state, which they, of course, do not! + - some kind of "signal tapping" similar to "port tapping" is suggested + - this is non-obvious and error prone and nonstandard (no normal supervisor + will play such signal tapping games) + - signal remapping makes more sense in this regard + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + + +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/148 + + diff --git a/results/classifier/zero-shot/105/boot/1756538 b/results/classifier/zero-shot/105/boot/1756538 new file mode 100644 index 000000000..474397dc1 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1756538 @@ -0,0 +1,38 @@ +boot: 0.871 +other: 0.858 +graphic: 0.855 +device: 0.841 +semantic: 0.827 +KVM: 0.737 +instruction: 0.733 +mistranslation: 0.655 +network: 0.473 +assembly: 0.461 +vnc: 0.447 +socket: 0.421 + +Minimal Ubuntu vs. Debian differences + +I'm using Qemu on Ubuntu (minimal) and Debian (minimal) on Android (Arch64) via Linux Deploy to run Windows guests. Here's a few issues I encountered: + +1) Qemu on (minimal) Debian 9 and Ubuntu cannot run Windows 7-10 guests (only Windows XP and below) because there's a black screen after the boot menu. Qemu on Debian 10, however, can run Windows 7. Incidentally, these distros run on the host in bios compatibility mode instead of UEFI. Ubuntu Desktop (full distro) on other hosts does not display the black screen when running Qemu. + +2) Qemu on Debian 9-10 (minimal) does not display fullscreen - but Ubuntu minimal does display full-screen. + +3) Qemu on Limbo PC Emulator and on Debian 9-10 only run windows guests at 1 GHz using the default Qemu CPU, but Ubuntu runs windows guests at 2 GHz using the default Qemu CPU. + +4) Enable KVM doesn't work, and virtualization isn't detected through Limbo PC Emulator and minimal Linux distros running on Android - perhaps is a problem with running Linux distros via Linux Deploy using Chroot on Android (not so much a Qemu-KVM issue) and failing to detect ARMv8-A CPUs that are indeed capable of virtualization. + +Can anyone explain these differences? I believe they are all using the latest versions of Qemu. + +One more: Qemu on Debian 9-10 minimal requires -show cursor command to use the mouse inside a windows guest, but with Qemu on Ubuntu minimal the cursor is controllable by default. Again, this is all within the context of an Android/Arm8/Linux minimal/Chroot-based host. + +Qemu Virtual CPU is capping at 1 GHz for version 2.5+ and 2 GHz for version 2.4 + +I tested qemu32 and qemu64. This is strange because my ARMv8-a CPU is 2.4 GHz. + +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/zero-shot/105/boot/1797262 b/results/classifier/zero-shot/105/boot/1797262 new file mode 100644 index 000000000..98a556267 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1797262 @@ -0,0 +1,54 @@ +boot: 0.583 +device: 0.570 +graphic: 0.491 +semantic: 0.446 +socket: 0.426 +instruction: 0.324 +mistranslation: 0.313 +other: 0.286 +network: 0.278 +vnc: 0.222 +KVM: 0.088 +assembly: 0.073 + +qemu arm no longer able to boot RPI Kernels + +Since RPi Kernel 1.20170427, qemu is no longer able to emulate the Rasberry Pi, as the linux kernel is complaining about timing issues. + +Old kernel output - https://pastebin.com/wvkneNNF +New kernel output - https://pastebin.com/QTwgCkV2 + +Note that the actual error is caused by the kernel being unable to get the timing source for the mmc (Line 160), which causes an unable-to-mount-root panic. There are other issues with the serial port returning an invalid speed, which displays a divide-by-zero error, which is PROBABLY a symptom of the same root cause. + +This is simple to replicate - The last working kernel is available here: + +https://github.com/raspberrypi/firmware/tree/1.20170405/boot + +Download kernel7 and the dtb, and try to boot with (for example) + +qemu-system-aarch64 -M raspi2 -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -serial stdio -sd noobs.img -append "root=/dev/mmcblk0p2 init=/bin/bash" + +This works, and boots successfully. + +However, if you replace the kernel7.img and dtb with ones taken from https://github.com/raspberrypi/firmware/tree/1.20170427/boot it will NOT boot because of various clock timing issues (as in the second paste) + +Isn't this likely due to the newer kernel accessing hardware we are not emulating properly? + +On 19 October 2018 at 12:59, Alex Bennée <email address hidden> wrote: +> Isn't this likely due to the newer kernel accessing hardware we are not +> emulating properly? + +Yes, it will be the missing cprman emulation. There was another +bug/thread on this recently. + +thanks +-- PMM + + +latest series posted: +https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00191.html + +Should be now fixed by commits 74de7145fd6..83ad4695478 (CPRMAN model added). + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/105/boot/1811 b/results/classifier/zero-shot/105/boot/1811 new file mode 100644 index 000000000..8cb47700b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1811 @@ -0,0 +1,49 @@ +boot: 0.909 +graphic: 0.805 +device: 0.690 +semantic: 0.626 +other: 0.528 +vnc: 0.509 +instruction: 0.455 +network: 0.417 +socket: 0.409 +assembly: 0.340 +mistranslation: 0.150 +KVM: 0.125 + +ppc serial appears to have a maximum ratio of output to input, hides output and only writes it on subsequent input(?!) +Description of problem: +When pasting in large chunks of text, the echo is partial, but completes with subsequent writes (and is drained when the writes are small). Sorry this is really stupid, see video. + +(also, when booting, the console stops at +``` +Building dt strings... +Building dt structure... +Device tree strings 0x00000000062c0000 -> 0x00000000062c0b90 +Device tree struct 0x00000000062d0000 -> 0x00000000062e0000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000002000000 ... +Linux ppc64le +#1 SMP Debian 6. +``` +and then continues with more messages from just after the dot: +``` +Linux ppc64le +#1 SMP Debian 6.[ 15.683156] vio vio: uevent: failed to send synthetic uevent: -19 +vio: Failed to write 'add' to '/sys/devices/vio/uevent', ignoring: No such device +/dev/vda2: clean, 17371/987360 files, 345018/3942144 blocks +``` +) +Steps to reproduce: +1. `cat > /dev/null` +2. paste in a couple solid lines +3. observe that the echo completed mid-line +4. paste in a couple more solid lines +5. observe that the echo includes the end of the first few lines, and the start of the second set +6. ^D +7. observe that with every key input into the shell, you get a few bytes back, and those bytes are the tail-end of the second set of lines +8. when the echo buffer is drained, it's drained +Additional information: +Demo video: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1041707;filename=2023-07-21+17-59-25.mp4;msg=5 + +Downstream bug: https://bugs.debian.org/1041707 diff --git a/results/classifier/zero-shot/105/boot/1823998 b/results/classifier/zero-shot/105/boot/1823998 new file mode 100644 index 000000000..791fa75e0 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1823998 @@ -0,0 +1,35 @@ +boot: 0.796 +device: 0.775 +instruction: 0.647 +network: 0.616 +socket: 0.582 +mistranslation: 0.530 +semantic: 0.506 +other: 0.459 +graphic: 0.451 +vnc: 0.429 +KVM: 0.379 +assembly: 0.265 + +qemu-system-aarch64: support kernels bigger than 128MiB + +Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd. + +This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure. + +Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at: + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68 + +It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel. + +I've submitted a patchset which I think should fix this, but if you could test that it actually does handle large images correctly that would be great. + +https://<email address hidden>/ + + +Changes now in master, will be in 4.1. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5e6dbe1e8cbbe4b6f74 + diff --git a/results/classifier/zero-shot/105/boot/1826 b/results/classifier/zero-shot/105/boot/1826 new file mode 100644 index 000000000..8b272f907 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1826 @@ -0,0 +1,42 @@ +boot: 0.967 +graphic: 0.938 +instruction: 0.938 +device: 0.894 +other: 0.853 +semantic: 0.791 +vnc: 0.675 +assembly: 0.645 +mistranslation: 0.565 +KVM: 0.532 +network: 0.514 +socket: 0.459 + +Segfault in memory_region_dispatch_write() +Description of problem: +Several possible outcomes +- Kernel freeze and rcu lockup messages. +- segfault + +For segfault, using gdb. +``` +in memory_region_dispatch_write (mr=mr@entry=0x130013001300013, addr=addr@entry=176, data=dat@entry=0, op=op@entry=M0_42, attrs=...) at ../../softwmmu/memory.c:1515 +1515 if (mr->alias) { + +in memory_region_dispatch_write( .. as above...) +in io_writex(env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, mmu_idx=mmu_idx@entry=0, val=0, addr=addr@entry=18446744073699049648, retaddr=retaddr@entry=140736023420498, op=MO_32) at ../../accel/tcg/cputlb.c:1448 +in do_st_mmio_leN (env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, val_le=<optmized out>, val_le@entry=0, addr=addr@entry=18446744073699049648, size=size@entry=4, mmu_idx=mmu_idx@entry=0, ra=140736023420498) at ../../accel/tcg/cputlb.c:2755 +in do_st_4 (ra=<optmized_out>, memop=<optimized out> mmu_idx=0, val=0, p=0x7ffff529c140, env=0x555556a84320) at ../../accel/tcg/cputbl.c:2921 +do_st4_mmu (env=0x555556a84320, addr=<optimized out> val=<optmized out>, oi=<otpmized out> ra=140736023420498) at ../../accel/tcg/cputlb.c:3006 +in code_gen_buffer() +in cpu_tb_exec(..) //getting lazy on typing as seems unlikely anything useful beyond here. +in cpu_loop_exec_tb() +cpu_exec_loop +in cpu_exec_setjmp() +in cpu_exec() +in tcg_cpus_exec() +``` +Steps to reproduce: +1. Boot. +2. Use gdb to grab back trace after segfault. +Additional information: +Seems to segfault mid way through PCI enumeration in the kernel. Which device seems to vary between runs. diff --git a/results/classifier/zero-shot/105/boot/1829498 b/results/classifier/zero-shot/105/boot/1829498 new file mode 100644 index 000000000..d45974fc1 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1829498 @@ -0,0 +1,62 @@ +boot: 0.638 +graphic: 0.549 +device: 0.523 +semantic: 0.470 +other: 0.468 +instruction: 0.354 +mistranslation: 0.314 +assembly: 0.235 +socket: 0.168 +vnc: 0.166 +network: 0.098 +KVM: 0.056 + +window 8 stuck during boot on Qemu + +Description of problem: +I've got windows 8 image(64 bit), installed on Qemu(x86-64_softmmu) and then i'm trying to boot/shutdown it in the same Qemu configuration. Windows 8 has feature - when you click "Shutdown" in UI, windows 8 doesn't actually power off, it goes to "Suspend to disc" ACPI state. After shutdown, i'm trying to boot it again, but it stucks during boot. + +I've discovered, that it hangs when windows 8 writes to AHCI's command register, AHCI triggers irq, but windows 8 sends EOI, don't accessing AHCI register,so irq line stills in high state, and irq will be injected again and again, while windows will send EOI on each AHCI interrupt. Strange thing is that it happens only on TCG mode or +with option "kernel-irqchip=off/split", with "kernel-irqchip=on" everything works ok(windows 8 accesses AHCI register and line goes to low state). + +Version-Release number of selected component (if applicable): +Qemu revision: d8276573da58e8ce78dab8c46dd660efd664bcb7 + + +Steps to Reproduce: +1. Install Windows 8 on QEMU(qemu command line: "-enable-kvm -m 1G -hda <image> -serial stdio -cpu core2duo -machine q35,kernel-irqchip=off" +2. Click shutdown in UI. +3. Try to boot again(it will stuck) +4. Kill Qemu and boot again, it will boot, now go to 2) :) + +What host kernel are you using? This sounds like a bug we used to have in KVM a while ago. Maybe it's back. + +The same problem was also alleviated by a guest driver update, are you using the initial release of Windows 8? + + + +My host kernel is 4.15.0-47. Windows 8 version is 6.3.9600. About KVM, i've got same problem in TCG mode. + +Drats, okay. I will investigate. (I can always hope for the easy answer...) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/436 + + diff --git a/results/classifier/zero-shot/105/boot/1831115 b/results/classifier/zero-shot/105/boot/1831115 new file mode 100644 index 000000000..ac2d25b2a --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1831115 @@ -0,0 +1,163 @@ +boot: 0.588 +mistranslation: 0.583 +device: 0.543 +KVM: 0.537 +vnc: 0.506 +other: 0.483 +instruction: 0.427 +graphic: 0.406 +network: 0.337 +socket: 0.328 +semantic: 0.288 +assembly: 0.276 + +qemu 4.0.0 on aarch64: uefi firmware oversize + +I'd like to enable uefi in my virtual machine, however qemu is always showing the same error: qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes +It's clearly impossible to fit a uefi firmware into 786432 bytes. + +Environment: qemu-system-aarch64 with kvm on an amlogic s905d aarch64 dev board, running archlinuxarm, qemu in the repository is compiled with https://download.qemu.org/qemu-4.0.0.tar.xz + +(My AAVMF_CODE.fd and AAVMF_VARS.fd are extracted from debian package qemu-efi-aarch64 0~20181115.85588389-3) + +Below is my libvirt log. + +2019-05-30 15:07:44.216+0000: starting up libvirt version: 5.3.0, qemu version: 4.0.0, kernel: 4.19.46-1-ARCH, hostname: jerry-n1.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-debiantesting \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-aarch64 \ +-name guest=debiantesting,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-debiantesting/master-key.aes \ +-machine virt-4.0,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \ +-cpu host \ +-drive file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1 \ +-m 1024 \ +-overcommit mem-lock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 508d100a-b4e5-4199-9ff9-ac6d40fe2896 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-reboot \ +-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,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.3,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \ +-drive file=/mnt/hddp1/jerry/libvirt/aarch64-images/debiantesting.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 \ +-drive file=/mnt/hddp1/jerry/libvirt/aarch64-iso/debian-testing-arm64-netinst.iso,format=raw,if=none,id=drive-scsi0-0-0-1,readonly=on \ +-device scsi-cd,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 \ +-netdev tap,fd=27,id=hostnet0 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d5:28:6d,bus=pci.1,addr=0x0 \ +-chardev pty,id=charserial0 \ +-serial chardev:charserial0 \ +-chardev socket,id=charchannel0,fd=28,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-object rng-random,id=objrng0,filename=/dev/urandom \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.5,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2019-05-30 15:07:44.216+0000: Domain id=2 is tainted: host-cpu +char device redirected to /dev/pts/2 (label charserial0) +2019-05-30T15:07:46.701125Z qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes +2019-05-30 15:07:46.779+0000: shutting down, reason=failed +(END) + +# /etc/libvirt/qemu.conf +nvram = [ + "/opt/ovmf/aarch64/AAVMF_CODE.fd:/opt/ovmf/aarch64/AAVMF_VARS.fd" +] + +This is a bug in the debian package that you mention. The 2MB firmware executable (QEMU_EFI.fd) and the 768KB varstore template (QEMU_VARS.fd) that the edk2 ArmVirtQemu platform build produces cannot be passed directly to QEMU. Both files have to be padded to 64MB first. The padding is generally done in the distro-specific package (RPM, DEB etc) build script. + +(If this report mentioned Ubuntu, we could simply re-classify the bug within Launchpad. However, Debian is tracked at bugs.debian.org, so I'll have to close the present issue as Invalid. Please open a bug at bugs.debian.org.) + +Note that starting with version 4.1, upstream QEMU too will bundle firmware binaries from the edk2 project. See https://wiki.qemu.org/ChangeLog/4.1#Miscellaneous + + +[jerry@jerry-n1 aarch64]$ du -b * +67108864 AAVMF_CODE.fd +67108864 AAVMF_VARS.fd +67108864 QEMU_EFI.fd +67108864 QEMU_VARS.fd + +2097152 QEMU_EFI.fd.orig +786432 QEMU_VARS.fd.orig + + +Both files have been padded to 64MB. (if padding means filling it with /dev/zero) + +QEMU_EFI.fd and QEMU_VARS.fd are built by myself according to https://wiki.linaro.org/LEG/UEFIforQEMU. With the self-built formware, I'm getting almost the same error: qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes + + +I'm quite sure that debian has done the padding procedure https://salsa.debian.org/qemu-team/edk2/blob/debian/debian/rules#L82 + + +Jerry <email address hidden> writes: + +> [jerry@jerry-n1 aarch64]$ du -b * +> 67108864 AAVMF_CODE.fd +> 67108864 AAVMF_VARS.fd +> 67108864 QEMU_EFI.fd +> 67108864 QEMU_VARS.fd +> +> 2097152 QEMU_EFI.fd.orig +> 786432 QEMU_VARS.fd.orig +> +> +> Both files have been padded to 64MB. (if padding means filling it with +> /dev/zero) + +You can use: + + truncate -s 64m /path/to/blob + +> +> QEMU_EFI.fd and QEMU_VARS.fd are built by myself according to +> https://wiki.linaro.org/LEG/UEFIforQEMU. With the self-built formware, +> I'm getting almost the same error: qemu-system-aarch64: Initialization +> of device cfi.pflash01 failed: device requires 67108864 bytes, block +> backend provides 786432 bytes + +Are you sure your libvirt invocation is properly pointing at your new +re-sized blobs? WFM here on master: + + ./aarch64-softmmu/qemu-system-aarch64 -cpu max -machine type=virt,virtualization=on -display none -m 4096 -serial mon:stdio -netdev user,id=unet,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=unet -device virtio-scsi-pci -blockdev driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-buster-arm64 -device scsi-hd,drive=hd -bios /usr/share/AAVMF/AAVMF_CODE.fd + +Where: + +ls -l /usr/share/AAVMF/* +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF32_CODE.fd +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF32_VARS.fd +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF_CODE.fd +-rw-r--r-- 1 root root 67108864 Mar 16 00:37 /usr/share/AAVMF/AAVMF_VARS.fd + +-- +Alex Bennée + + +I just noticed that it was a libvirt bug that caused the error. + +-drive file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1 \ + +debiantesting_VARS.fd was never removed or replaced after its first creation since the installation errored out. I deleted this file manually and everything is fine now. + +Sorry for your inconvenience. + diff --git a/results/classifier/zero-shot/105/boot/1835694 b/results/classifier/zero-shot/105/boot/1835694 new file mode 100644 index 000000000..3df81eff4 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1835694 @@ -0,0 +1,419 @@ +boot: 0.966 +assembly: 0.956 +network: 0.955 +mistranslation: 0.954 +graphic: 0.953 +semantic: 0.948 +device: 0.946 +instruction: 0.940 +other: 0.937 +socket: 0.921 +KVM: 0.896 +vnc: 0.893 + +hardware-based time keeping + +Hi all, + +I hope you're all doing well. + +As i was looking for a solution for a particular problem in Qemu/KVM +virtualization. + +My issue is that I have a virtual machine that runs well in VMware and when +I migrated that to Qemu/KVM-enabled environment, it didn't work! I figured +out that under VMware hypervisor, VMware supplies CPU TSC and Performance +Counters values to the guest VM with the option +"monitor_control.pseudo_perfctr = TRUE" set the vmx configuration file, +Ref.: https://www.vmware.com/pdf/vmware_timekeeping.pdf + +My question is, is there any similar option in Qemu/KVM-enabled environment +that I can use to get my VM working the same way as in the VMware +environment? + +I almost tried all options in Qemu with regards to CPU but no avail. + +To elaborate more, the VM I'm trying to port under Qemu/KVM environment is +a an old version of Cisco virtual ASA Firewall. The VM image is actually +meant to be run under VMware ESXi and with that +"*monitor_control.pseudo_perfctr += TRUE*" option it can also run in Vware Workstation as well. *Yes, this +option that makes it run under VMware and if it's removed from the +configuration vmx file then the VM boots half way and crashes the same way +it crashes under Qemu*. That dictates it's the option in interest that +needs to be found in Qemu/KVM. I have a copy of this VM in the below link +in case you would like to try its behavior in under VMware. I downloaded it +from a youtube previously to test it out: + +https://drive.google.com/open?id=1SEXws18hoj2sWGk8iFqqH8RpBZsBNpRH + +Once you power on the VM you can telnet to 127.0.0.1 on port 3000 to see +the boot process. If you remove that option i mentioned to you and boot the +VM again you'll see the crashing in process. + + +I've converted that vmdk disk images into Qemu disks "qcow2" format and i +ran them using the below command line on Ubuntu: + +/opt/qemu/bin/qemu-system-x86_64 -L -nographic -device +e1000-82545em,netdev=net0,mac=50:00:00:6a:00:00 -netdev +tap,id=net0,ifname=vunl0_33_0,script=no -device +e1000-82545em,netdev=net1,mac=50:00:00:6a:00:01 -netdev +tap,id=net1,ifname=vunl0_33_1,script=no -device +e1000-82545em,netdev=net2,mac=50:00:00:6a:00:02 -netdev +tap,id=net2,ifname=vunl0_33_2,script=no -device +e1000-82545em,netdev=net3,mac=50:00:00:6a:00:03 -netdev +tap,id=net3,ifname=vunl0_33_3,script=no -machine type=pc-1.0 *-cpu +host,migratable=off,invtsc=on,pmu=on* -m 4096 -hda hda.qcow2 -hdb hdb.qcow2 +-serial telnet:0.0.0.0:3000,server,nowait -monitor +tcp:127.0.0.1:42379,server,nowait +-nographic -display none -enable-kvm + + +Once you power on the VM you can telnet to xx.xx.xx.xx 3000 (where the xx +IP is the Ubuntu machine IP) to see the crashing in process. You may need +to wait for a while for the status messages to appear in the terminal +window. + +I assume it's a cpu issue because in page 9 of the Vmware pdf reference +file; it says there are machine instructions become available when this +option "*monitor_control.pseudo_perfctr = TRUE*" is enabled: + +The following machine instructions then become available: + +Instruction Time Value Returned +rdpmc 0x10000 Physical host TSC +rdpmc 0x10001 Elapsed real time in ns +rdpmc 0x10002 Elapsed apparent time in ns + +Therefore, I used many of the Qemu cpu options such as these: + +-cpu host,migratable=no,+invtsc (ref: https://wiki.qemu.org/ChangeLog/2.1) +-cpu host, tsc-frequency=xxxx (ref: https://lists.gnu.org/archive/ +html/qemu-devel/2017-01/msg03555.html) + -cpu host,migratable=off,invtsc=true,pmu=true + +Not sure if i'm hitting the wrong option! + +The log I'm getting when the VM boots up looks like the following crash +happens at the blue colored log: + +---------------------------------------------------------------------------------------------------------------------------- +Loading... + +Starting image verification +Hash Computation: 100% Done! +Computed Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +Get key records from key storage: Primary, key_store_type: 2 +Embedded Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +The digital signature of the running image verified successfully +Processor memory 3183296512, Reserved memory: 0 + +Total NICs found: 4 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 6 index 03 MAC: 5000.006a.0003 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 5 index 02 MAC: 5000.006a.0002 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 4 index 01 MAC: 5000.006a.0001 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 3 index 00 MAC: 5000.006a.0000 + +Thread Name: lina_flash_init_thread +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x0000000000422152 +2: 0x0000000000424331 +3: 0x00000000015874a9 +4: 0x00007ffffecd55f0 +5: 0x0000000000558d85 +6: 0x00000000008f5a2b +7: 0x00000000008fd361 +8: 0x0000000000428a15 +Stack dump: base:0x00007fff4056f2e0 size:178, active:178 + entries above '==': return PC preceded by input parameters + entries below '==': local variables followed by saved regs + '==Fn': stack frame n, contains next stack frame + '*': stack pointer at crash + rdi rsi rdx rcx r8 r9 : Arguments 1 through 6 to leaf function + For example: + 0x00007fffeeeeef00: 0x0000000000000009 : arg9 + 0x00007fffeeeeeefc: 0x0000000000000008 : arg8 + 0x00007fffeeeeeef8: 0x0000000000000007 : arg7 + 0x00007fffeeeeeef4: 0x0000000000000abc : return PC + 0x00007fffeeeeeef0: 0x00007fffeeeeef20 ==F2: stack frame F2 + 0x00007fffeeeeeeec: 0x0000000000000def : local variable + 0x00007fffeeeeeee8: 0x0000000000000123 : local variable or saved reg + 0x00007fffeeeeeee4: 0x0000000000000456 : local variable or saved reg + 0x00007fffeeeeeee0: 0x0000000000000789 : local variable or saved reg +0x00007fff4056f870: 0x00007fff4056f7e0 +0x00007fff4056f868: 0x0000000000000000 +0x00007fff4056f860: 0x00000038a11c0123 +0x00007fff4056f858: 0x0000000000000083 +0x00007fff4056f850: 0x00007fff16a864c8 +0x00007fff4056f848: 0x0000000000000000 +0x00007fff4056f840: 0x00000000a11ccdef +0x00007fff4056f838-0x00007fff4056f808: 0x0000000000000000 +0x00007fff4056f800: 0x0000000000429867 +0x00007fff4056f7f8: 0x00007fff4056f860 +0x00007fff4056f7f0: 0x00007fff40567100 +0x00007fff4056f7e8: 0x0000000000000000 +0x00007fff4056f7e0: 0x00000030a11c0123 +0x00007fff4056f7d8: 0x0000000000000083 +0x00007fff4056f7d0: 0x00007fff16a864c8 +0x00007fff4056f7c8: 0x0000000000000000 +0x00007fff4056f7c0: 0x00000000a11ccdef +0x00007fff4056f7b8: 0x0fffffff0fffffff +0x00007fff4056f7b0-0x00007fff4056f7a8: 0x0000000000000000 +0x00007fff4056f7a0: 0x00000000062cc8a0 +0x00007fff4056f798: 0x0000000000000000 +0x00007fff4056f790: 0x00007fff4056f6e0 +0x00007fff4056f788: 0x00007fff4056f758 +0x00007fff4056f780: 0x0000000000000000 +0x00007fff4056f778: 0x00007fff3ff48620 +0x00007fff4056f770-0x00007fff4056f730: 0x0000000000000000 +0x00007fff4056f728: 0x0000000004d14940 +0x00007fff4056f720: 0x000000000041d690 +0x00007fff4056f718: 0x0000000002777640 +0x00007fff4056f710: 0x0000000200010010 +0x00007fff4056f708: 0x0000000006c17d40 +0x00007fff4056f700: 0x00007fff4056f6e0 +0x00007fff4056f6f8: 0x00007fff40150e80 +0x00007fff4056f6f0: 0x000000000638e598 +0x00007fff4056f6e8: 0x00007fff3ff48620 +0x00007fff4056f6e0: 0x00007fff4056f778 +0x00007fff4056f6d8: 0x00000000deadfeed +0x00007fff4056f6d0-0x00007fff4056f6c8: 0x0000000000000000 +0x00007fff4056f6c0: 0x000000000041e1f6 +0x00007fff4056f6b8: 0x00007fff40571fd0 +0x00007fff4056f6b0: 0x00007fff40560cf0 +0x00007fff4056f6a8: 0x0000000000000000 +0x00007fff4056f6a0: 0x000000f0a11c0123 +0x00007fff4056f698: 0x0000000000000143 +0x00007fff4056f690: 0x00007fff16a864c8 +0x00007fff4056f688: 0x0000000000000000 +0x00007fff4056f680: 0x00000000a11ccdef +0x00007fff4056f678-0x00007fff4056f660: 0x0000000000000000 ==F5 +0x00007fff4056f658: 0x000000009abcdef0 +0x00007fff4056f650-0x00007fff4056f5b8: 0x123456789abcdef0 +0x00007fff4056f5b0: 0x0000000000428a01 +0x00007fff4056f5a8: 0x00007fff4056f570 +0x00007fff4056f5a0-0x00007fff4056f590: 0x0000000000000000 +0x00007fff4056f588: 0xffffffffffffdf98 +0x00007fff4056f580: 0x00007fff4056f670 +0x00007fff4056f578: 0x00007fff3ff48370 +0x00007fff4056f570: 0x0000000000000000 +0x00007fff4056f568: 0x0000000000428a15 +0x00007fff4056f560: 0x00007fff4056f670 ==F4 +0x00007fff4056f558: 0x00000000008fd361 +0x00007fff4056f550: 0x00007fff4056f560 ==F3 +0x00007fff4056f548: 0x00000000008f5a2b +0x00007fff4056f540: 0x00007fff4056f550 ==F2 +0x00007fff4056f538: 0x0000000000000000 +0x00007fff4056f530: 0xffffffffffffdf98 +0x00007fff4056f528: 0x00007fff3ff48370 +0x00007fff4056f520: 0x00000000008fba90 +0x00007fff4056f518: 0x00000000008fb908 +0x00007fff4056f510: 0x00007fff4056f550 +0x00007fff4056f508: 0x00000000008fb87e +0x00007fff4056f500: 0x00007fff4056f510 +0x00007fff4056f4f8: 0x0000000000000000 +0x00007fff4056f4f0: 0xffffffffffffdf98 +0x00007fff4056f4e8: 0x0000000000558d85 +0x00007fff4056f4e0: 0x00007fff4056f540 ==F1 +0x00007fff4056f4d8-0x00007fff4056f4d0: 0x0000000000000000 +0x00007fff4056f4c8: 0x0000000000000001 +0x00007fff4056f4c0-0x00007fff4056f4b8: 0x00000000062ebfc0 +0x00007fff4056f4b0: 0x0000000000000000 * +0x00007fff4056f4a8: 0x00000000008fd973 +0x00007fff4056f4a0: 0x00007fff4056f4d0 +0x00007fff4056f498: 0x00007fff40563908 +0x00007fff4056f490: 0x00007fff4056f4d0 +0x00007fff4056f488: 0x00000000009d4b01 +0x00007fff4056f480: 0x00007fff4056f4a0 +0x00007fff4056f478-0x00007fff4056f470: 0x0000000000000000 +0x00007fff4056f468: 0x00007fff418d6390 +0x00007fff4056f460: 0x0000000000000000 +0x00007fff4056f458: 0x000000000201b9f8 +0x00007fff4056f450: 0x00007fff4056f480 +0x00007fff4056f448: 0x00007fff40563908 +0x00007fff4056f440: 0x0000000000000001 +0x00007fff4056f438: 0x00007fff405619a0 +0x00007fff4056f430: 0x00007fff40563908 +0x00007fff4056f428: 0x0000000000000001 +0x00007fff4056f420: 0x0000000000000000 +0x00007fff4056f418: 0x0000000001627125 +0x00007fff4056f410: 0x00007fff4056f450 +0x00007fff4056f408: 0x00007fff3fa8b010 +0x00007fff4056f400: 0x00007fff46505845 +0x00007fff4056f3f8-0x00007fff4056f3c8: 0x0000000000000000 +0x00007fff4056f3c0: 0x0000000000000003 +0x00007fff4056f3b8-0x00007fff4056f3a8: 0x0000000000000000 +0x00007fff4056f3a0: 0x0000000000000240 +0x00007fff4056f398: 0x0000000000000003 +0x00007fff4056f390: 0x0000024446505853 +0x00007fff4056f388-0x00007fff4056f310: 0x0000000000000000 +0x00007fff4056f308: 0x424b7e25fece8fc2 +0x00007fff4056f300: 0x2cc4f98473045e95 +0x00007fff4056f2f8: 0x18fa9b6c57ca0e78 +0x00007fff4056f2f0: 0x081e2a254ab96aa4 +0x00007fff4056f2e8: 0x0000000300000000 + +Begin to dump crashinfo to flash.... + +core0: An internal error occurred. Specifically, a programming assertion +was +violated. Copy the error message exactly as it appears, and get the +output of the show version command and the contents of the configuration +file. Then call your technical support representative. + +assertion "_vf_mode_init" failed: file "vf_api.c", line 136 +core0 same core snap_count=1 signo=6 RIP=7ffffecd43fb + + +----------------------------------------------- +Traceback output aborted. +Flushing first exception frame: +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 +Nested traceback attempted via signal, from: +Abort: Unknown + r8 0x000000000000003c + r9 0x0000000005097a27 + r10 0x00007fff4056de28 + r11 0x0000000000003206 + r12 0x0000000000000001 + r13 0x00007fff4056df80 + r14 0x0000000000000000 + r15 0x0000000000000006 + rdi 0x0000000000000008 + rsi 0x00007fff4056df80 + rbp 0x00007fff4056dfc0 + rbx 0x00007fff29f6b780 + rdx 0x0000000000000010 + rax 0x0000000000000010 + rcx 0xffffffffffffffff + rsp 0x00007fff4056df50 + rip 0x00007ffffecd43fb + eflags 0x0000000000003206 + csgsfs 0x1234000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x00000000004221f8 +2: 0x000000000042226d +3: 0x0000000001587076 +4: 0x00007ffffecd55f0 +5: 0x00000000015820a0 +6: 0x000000000212d482 +7: 0x000000000139f304 +8: 0x000000000213f315 +9: 0x0000000001460873 +10: 0x0000000001488625 +11: 0x0000000000423e7a +12: 0x00000000004244dc +13: 0x00000000015874a9 +14: 0x00007ffffecd55f0 +15: 0x0000000000558d85 +16: 0x00000000008f5a2b +17: 0x00000000008fd361 +18: 0x0000000000428a15 +----------------------------------------------- +Process shutdown finished +Rebooting..... + +Thanks in advance for your help! :) + +Regards, +Abdullah Alhaddad + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +not resolved + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/180 + + diff --git a/results/classifier/zero-shot/105/boot/1836136 b/results/classifier/zero-shot/105/boot/1836136 new file mode 100644 index 000000000..cf7f3562d --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1836136 @@ -0,0 +1,25 @@ +boot: 0.751 +device: 0.646 +mistranslation: 0.628 +graphic: 0.590 +semantic: 0.424 +instruction: 0.402 +other: 0.345 +socket: 0.293 +network: 0.099 +vnc: 0.082 +assembly: 0.056 +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/zero-shot/105/boot/1838390 b/results/classifier/zero-shot/105/boot/1838390 new file mode 100644 index 000000000..88bc591bf --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1838390 @@ -0,0 +1,97 @@ +boot: 0.983 +other: 0.981 +instruction: 0.976 +network: 0.974 +graphic: 0.974 +vnc: 0.974 +device: 0.973 +socket: 0.972 +semantic: 0.971 +assembly: 0.969 +KVM: 0.959 +mistranslation: 0.949 + +vmx_write_mem: mmu_gva_to_gpa failed when using hvf + +Installed qemu 4.0.0 by homebrew, used below commands: + +1. qemu-img create -f raw arch-vm.img 100G +2. qemu-system-x86_64 -show-cursor -only-migratable -nodefaults -boot order=d -cdrom archlinux-2019.07.01-x86_64.iso -cpu host -device virtio-keyboard -device virtio-mouse -device virtio-tablet -drive file=arch-vm.img,format=raw,if=virtio -m 4096 -machine q35,accel=hvf,vmport=off -nic user,ipv6=off,model=virtio -smp 4,sockets=1,cores=2,threads=2 -soundhw hda -vga virtio + +Displayed bootloader menu successfully, select "Boot Arch Linux" then crashed with message: vmx_write_mem: mmu_gva_to_gpa ffff91953b540000 failed. + +Use tcg accelerator has no problem but very slow. + +See attachment for full crash report. + + + +Also happens to me on a freshly built Qemu master (tip 23919ddfd561). +MBP15,2 OSX 10.14.6 + +Qemu command line: +qemu/x86_64-softmmu/qemu-system-x86_64 -cpu host -accel hvf -m 4G -smp 8 -vga std -nographic -vnc :1 -netdev user,id=net0 -device e1000e,netdev=net0 buster.qcow + +Guest works fine until I try to build a linux-stable tree with "make -j8". + +Ubuntu 18.04 VM crashes after login. Works when the RAM is 4 Gb. Posting this here as the error message looked very similar. + +qemu-system-x86_64 -m 6G -vga virtio -show-cursor -usb -device usb-tablet -enable-kvm -drive file=~/QEMU/ubuntu-desktop-18.04.qcow2,if=virtio -accel hvf -cpu host + +Crashed with below message +vmx_write_mem: mmu_gva_to_gpa ffff97ccb8dbe000 failed +Abort trap: 6 + +Crash report + +I think I was able to fix this crash by specifying the exact host model for the cpu argument. + +1. Determine the CPU type of the host machine. + +$ sysctl -a | grep machdep.cpu.brand_string +machdep.cpu.brand_string: Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz + +2. Find the matching CPU model supported by QEMU. + +$ qemu-system-x86_64 -cpu help + + +This CPU corresponds to "x86 Haswell-v4" in this instance. + +3. Substitute the CPU model in the QEMU command. + +$ qemu-system-x86_64 -cpu Haswell-v4 ... + +Related StackOverflow question: https://stackoverflow.com/q/60231203/9835303 + +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.] + +It still happens to me when I try to run Haiku builds on my macos 10.14. +* QEMU emulator version 7.0.0 + +Command line: +qemu-system-x86_64 -machine q35,accel=hvf -cpu host -smp 4 -m 2048 -vga vmware -boot menu=on -drive file="haiku-minimum.mmc",if=none,format=raw,id=x0 -device ide-hd,drive=x0,bus=ide.0 -usb -device qemu-xhci,id=xhci -device usb-mouse -device usb-kbd -serial stdio -rtc clock=vm,base=localtime + +Output: +[ipro1000] (em) Link is up 1000 Mbps Full Duplex +framebuffer: init_hardware() +vmx_write_mem: mmu_gva_to_gpa ffffffff853b3000 failed +[1] 82284 abort qemu-system-x86_64 -machine q35,accel=hvf -cpu host -smp 4 -m 2048 -vga vmwar + +Haiku boots most of the way and crashes when trying to show desktop. Same happens with -vga virtio and with -vga option completely removed. + + + diff --git a/results/classifier/zero-shot/105/boot/1838658 b/results/classifier/zero-shot/105/boot/1838658 new file mode 100644 index 000000000..4013b2900 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1838658 @@ -0,0 +1,177 @@ +boot: 0.576 +graphic: 0.564 +network: 0.512 +other: 0.500 +assembly: 0.473 +semantic: 0.410 +device: 0.406 +instruction: 0.400 +vnc: 0.337 +socket: 0.328 +mistranslation: 0.292 +KVM: 0.280 + +qemu 4.0.0 broken by glib update + +In brief, an install CD will successfully boot with qemu 4.0.0 built with glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I tracked it down to glib's GHashTable improvements. qemu is happy with a glib built from +``` + git checkout -f 2.60.4 + git revert --no-edit 86c6f7e2b..3bed8a13b + git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159 + git revert --no-edit 603fb5958..d3074a748 + git revert --no-edit 0b45ddc55..0600dd322 +``` +When the GHashTable improvements were committed, there was already a preemptive note about any breakage being due to using private implementation details, hence mentioning it here rather than with glib. + +For the full saga, see: http://gnats.netbsd.org/54310 + +Fedora 30 has been shipping glib2 2.60.0 through to 2.60.5 and QEMU in general has been working normally AFAICT. + +From the netbsd bug report it looks like the reproducer was demoed using the sparc emulator - is that the only QEMU arch that is affected ? + +The test image that the netbsd bug points to no longer exists. + +If I pick the image currently available: + + http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.99.2-sparc.iso + +And launch it in a QEMU built from today's GIT master, on Fedora 30 with glib2 2.60.5, NetBSD successfully boots and launches the installer... + + +$ ~/usr/qemu-git/bin/qemu-system-sparc -drive file=NetBSD-9.99.2-sparc.img,format=raw,media=disk,snapshot=off -cdrom /var/lib/libvirt/images/NetBSD-9.99.2-sparc.iso -boot d -nographic +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Jul 1 2019 17:08 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 65536 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +switching to new context: +>> NetBSD/sparc Secondary Boot, Revision 1.15 (Thu Aug 1 22:23:16 UTC 2019) +Booting netbsd +3375564+96668=0x34ffe0 +OBP version 3, revision 2.25 (plugin rev 2) +[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, +[ 1.0000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, +[ 1.0000000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. +[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993 +[ 1.0000000] The Regents of the University of California. All rights reserved. + +[ 1.0000000] NetBSD 9.99.2 (INSTALL) #0: Thu Aug 1 22:23:16 UTC 2019 +[ 1.0000000] <email address hidden>:/usr/src/sys/arch/sparc/compile/INSTALL +[ 1.0000000] total memory = 111 MB +[ 1.0000000] avail memory = 106 MB +[ 1.0000000] bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +[ 1.0000000] mainbus0 (root): SUNW,SPARCstation-5: hostid 80123456 +[ 1.0000000] cpu0 at mainbus0: FMI,MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU +[ 1.0000000] cpu0: 16K instruction (32 b/l), 8K data (16 b/l), 512K external (32 b/l): cache enabled +[ 1.0000000] obio0 at mainbus0 +[ 1.0000000] clock0 at obio0 slot 0 offset 0x200000: mk48t08 +[ 1.0000000] timer0 at obio0 slot 0 offset 0xd00000: delay constant 201, frequency = 2000000 Hz +[ 1.0000050] zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6 +[ 1.0000050] zstty0 at zs0 channel 0 (console i/o) +[ 1.0000050] zstty1 at zs0 channel 1 +[ 1.0000050] zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6 +[ 1.0000050] zstty2 at zs1 channel 0 +[ 1.0000050] kbd0 at zstty2 +[ 1.0000050] zstty3 at zs1 channel 1 +[ 1.0000050] ms0 at zstty3 +[ 1.0000050] wsmouse0 at ms0 mux 0 +[ 1.0000050] fdc0 at obio0 slot 0 offset 0x400000 level 11 softpri 4: chip 82077 +[ 1.0000050] fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec +[ 1.0000050] auxreg0 at obio0 slot 0 offset 0x900000 +[ 1.0000050] power0 at obio0 slot 0 offset 0x910000 level 2 +[ 1.0000050] slavioconfig at obio0 slot 0 offset 0x800000 not configured +[ 1.0000050] iommu0 at mainbus0 addr 0x10000000: version 0x5/0x0, page-size 4096, range 64MB +[ 1.0000050] sbus0 at iommu0: clock = 21.250 MHz +[ 1.0000050] dma0 at sbus0 slot 5 offset 0x8400000: DMA rev 2 +[ 1.0000050] esp0 at dma0 slot 5 offset 0x8800000 level 4: ESP200, 40MHz, SCSI ID 7 +[ 1.0000050] scsibus0 at esp0: 8 targets, 8 luns per target +[ 1.0000050] ledma0 at sbus0 slot 5 offset 0x8400010: DMA rev 2 +[ 1.0000050] le0 at ledma0 slot 5 offset 0x8c00000 level 6: address 52:54:00:12:34:56 +[ 1.0000050] le0: 8 receive buffers, 2 transmit buffers +[ 1.0000050] tcx0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9) (8-bit only TCX) +[ 1.0000050] tcx0: SUNW,tcx, 1024 x 768 +[ 1.0000050] tcx0: id 0, rev 0, sense 0 +[ 1.0000050] tcx0: attached to /dev/fb0 +[ 1.0000050] wsdisplay1 at tcx0 kbdmux 1 +[ 1.0000050] SUNW,CS4231 at sbus0 slot 4 offset 0xc000000 level 5 (ipl 9) not configured +[ 1.0000050] power-management at sbus0 slot 4 offset 0xa000000 not configured +[ 1.0000050] scsibus0: waiting 2 seconds for devices to settle... +[ 1.0000050] wskbd0 at kbd0 mux 1 +[ 3.4705415] sd0 at scsibus0 target 0 lun 0: <QEMU, QEMU HARDDISK, 2.5+> disk fixed +[ 3.4805320] sd0: 2048 MB, 4161 cyl, 16 head, 63 sec, 512 bytes/sect x 4194304 sectors +[ 3.4805320] cd0 at scsibus0 target 2 lun 0: <QEMU, QEMU CD-ROM, 2.5+> cdrom removable +[ 4.4805570] kbd0: reset failed +[ 4.5705505] root on md0a dumps on md0b +[ 4.5805965] root file system type: ffs +[ 4.5805965] kern.module.path=/stand/sparc/9.99.2/modules +Welcome to the NetBSD/sparc microroot setup utility. + +We've just completed the first stage of a two-stage procedure to load a +fully functional NetBSD installation environment on your machine. In the +second stage which is to follow now, a set of additional installation +utilities must be load from your NetBSD/sparc installation medium. + +This procedure supports one of the following media: + +1) cdrom +2) tape +3) floppy + +Installation medium to load the additional utilities from: + + +Can you confirm that you can still reproduce the original problem using QEMU git master, and latest NetBSD ISO image. + + +> From the netbsd bug report it looks like the reproducer was demoed +> using the sparc emulator - is that the only QEMU arch that is affected ? + +Only one arch is affected, but it's sparc64, not sparc. + + +> The test image that the netbsd bug points to no longer exists. + +Please try this one instead: + + https://www.gson.org/bugs/qemu/NetBSD-8.99.47-sparc64.iso + +I just verified that this image works for reproducing the bug. + + + +Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64. + +I've now tested QEMU git master with that sparc64 ISO and qemu-system-sparc64. + +I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type. + +So looks like there's some further variable involved beyond just the glib update - perhaps something about the host OS is combining with the glib update to trigger it. + + +> So looks like there's some further variable involved beyond just the +> glib update - perhaps something about the host OS is combining with +> the glib update to trigger it. + +Agreed - I just retested using a Fedora 30 instance on EC2, with +glib2-2.60.1-2.fc30.x86_64, and was also unable to reproduce the +issue there. + + +The linked NetBSD bug report http://gnats.netbsd.org/54310 now has confirmation that this crash was the result of a memory corruption bug in QEMU which happened to manifest with the newer glib version. That bug is fixed in QEMU master in commit ef905eff421c5a06a01 which will be in the 5.2 release, so we can mark this as 'fix committed'. + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/105/boot/1840920 b/results/classifier/zero-shot/105/boot/1840920 new file mode 100644 index 000000000..c3d608ab4 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1840920 @@ -0,0 +1,27 @@ +mistranslation: 0.998 +boot: 0.933 +vnc: 0.931 +device: 0.873 +graphic: 0.711 +instruction: 0.631 +semantic: 0.613 +network: 0.515 +socket: 0.333 +other: 0.317 +assembly: 0.215 +KVM: 0.057 + +changelog 4.1 krenel typo + +The changelog for 4.1 subsection Arm has a typo (krenel --> kernel) +https://wiki.qemu.org/ChangeLog/4.1#Arm + +At the following line: +The i.mx7 PCI controller emulation has been improved so it can boot current Linux krenels + +it should be: +The i.mx7 PCI controller emulation has been improved so it can boot current Linux kernels + +Thanks for this report -- I've just updated the changelog page to fix the typo. + + diff --git a/results/classifier/zero-shot/105/boot/1853429 b/results/classifier/zero-shot/105/boot/1853429 new file mode 100644 index 000000000..823c621e8 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1853429 @@ -0,0 +1,41 @@ +boot: 0.772 +device: 0.746 +other: 0.670 +graphic: 0.650 +network: 0.545 +vnc: 0.529 +semantic: 0.528 +mistranslation: 0.525 +instruction: 0.523 +KVM: 0.520 +socket: 0.483 +assembly: 0.242 + +qemu-kvm on aarch64 attach volume failed when vm is booting + +I use libvirt and qemu-kvm on aarch64 platform to attach volume to a booting vm，when the system of vm has not boot up, attach volume will be failed, after vm system booting up, attach volume can be successful. + +libvirt: 4.5.0 +qemu : 2.12.0 + +console log and qemu command of vm is in attachment. + + + + + +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/zero-shot/105/boot/1859106 b/results/classifier/zero-shot/105/boot/1859106 new file mode 100644 index 000000000..6d80dbdb9 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1859106 @@ -0,0 +1,65 @@ +boot: 0.915 +device: 0.872 +graphic: 0.840 +other: 0.735 +socket: 0.649 +semantic: 0.637 +vnc: 0.615 +instruction: 0.591 +mistranslation: 0.544 +network: 0.532 +KVM: 0.358 +assembly: 0.318 + +4.2 regression: ReactOS crashes on boot + +In QEMU 4.1.x and earlier, ReactOS can successfully boot, but starting with 4.2, it fails, instead coming up with an error "The video driver failed to initialize." + +This happens regardless of VM configuration (even -M pc-i440fx-4.1) and it works well with older versions of QEMU. bisecting QEMU to find the first bad commit reveals 0221d73ce6a8e075adaa0a35a6ef853d2652b855 as the culprit, which is updating the seabios version; perhaps this bug belongs there, but I don't know the appropriate avenue (it seems seabios is a subproject of QEMU anyway?). + +I should add, ReactOS can be downloaded from here: https://reactos.org/download + +The LiveCD is sufficient to see the problem. + +Possibly related thread: +"Do we need a cpu with TSC support to run SeaBIOS?" +https://<email address hidden>/msg11726.html + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +This is still a problem with qemu 1:4.2-3ubuntu6.16 on 20.04, and can be reproduced with: + +curl -LO https://freefr.dl.sourceforge.net/project/reactos/ReactOS/0.4.13/ReactOS-0.4.13-live.zip +unzip ReactOS-0.4.13-live.zip +qemu-system-x86_64 -cdrom ReactOS-0.4.13-Live.iso -boot d -usb -device usb-tablet +[Pick "LiveCD" in the boot menu] + +Which gives the error shown in the attached screenshot. + +I've changed the Status back to New. + + +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/475 + + +As a workaround, I have extracted bios.bin and vgabios-stdvga.bin from http://launchpadlibrarian.net/318981898/seabios_1.10.2-1ubuntu1_all.deb, passing -bios bios.bin to qemu and making sure vgabios-stdvga.bin is in the current working directory when running qemu in order for it to be used (seems like there is no command line option for qemu to specify the VGA bios). + +@th-huth Aha, thanks! + diff --git a/results/classifier/zero-shot/105/boot/1859254 b/results/classifier/zero-shot/105/boot/1859254 new file mode 100644 index 000000000..82b382d4b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1859254 @@ -0,0 +1,73 @@ +boot: 0.689 +graphic: 0.683 +device: 0.546 +network: 0.520 +vnc: 0.517 +socket: 0.514 +other: 0.409 +instruction: 0.401 +semantic: 0.396 +mistranslation: 0.294 +assembly: 0.228 +KVM: 0.095 + +host window size does not change when guest video screen size changes while moving host window + +When QEMU is emulating a legacy text mode, then switches to a VESA mode, if you happen to be moving the host window while the switch is made, the host window never changes size. The emulated size does, but the host window doesn't. + +For example, at Legacy boot up, the screen mode is mode 03 at 80x25. Then when the GUEST OS changes the screen to a VESA mode, say 1024x768x16, normally the host window will change to that size to accommodate the new emulated screen size. + +However, if you happen to be moving the host window at the time of the screen mode change, the host window doesn't change in size to accommodate the new screen size. + +I am using: + QEMU for Windows, version 4.1.0-11789 + Host: Windows 10 (latest updates) + Emulating: Intel x64, Legacy BIOS +Command line: +"c:\program files\qemu\qemu-system-x86_64.exe" -m 256 -drive file=C:\fysos64.img,format=raw,if=ide,media=disk,index=0 -parallel file:para.txt -boot c -d guest_errors -vga std -smp cpus=4 -rtc base=localtime,clock=host,driftfix=slew -net none -monitor stdio + +I tried different -vga settings: + -vga std + -vga cirrus + -vga vmware +Each did the same thing. + +[ Side note (possible error in documentation): +[ at: https://qemu.weilnetz.de/doc/qemu-doc.html#SVGA-graphic-modes-support +[ end of 2.16.2.1 +[ (option -std-vga) +[ possibly should be +[ (option -vga std) + +If you need an image to test with, I have been using www.fysnet.net/temp/fysos64.zip (2meg zipped/10meg raw). It starts in Legacy BIOS/Hardware mode 3, then switches to VESA 1024x768x16 within a few seconds, so be ready to move the HOST window when the mode changes. + +I do not have a Linux box to test with, so unknown if this is only an issue with the Windows version or not. + +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 still exists, therefore I have marked as 'new' per your request. + +Using latest version of QEMU for Windows (from https://qemu.weilnetz.de/) still does not adjust the host window size if a quest size changes while the host window is being moved. + +Thank you, +Ben + + +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/226 + + diff --git a/results/classifier/zero-shot/105/boot/1859916 b/results/classifier/zero-shot/105/boot/1859916 new file mode 100644 index 000000000..eeb3f0b26 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1859916 @@ -0,0 +1,79 @@ +boot: 0.689 +device: 0.681 +graphic: 0.675 +network: 0.655 +instruction: 0.623 +vnc: 0.619 +other: 0.592 +semantic: 0.591 +socket: 0.581 +assembly: 0.571 +mistranslation: 0.474 +KVM: 0.375 + +coreaudio not working on MacOS + +OS: MacOS Catalina 10.15.2 + +qemu-system-x86_64 -version +QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Qemu install via brew: brew install qemu + +--- + +I use following to install Ubuntu 18.04 desktop successfully:- + +IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso +IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 +MAC_ADDR=xx:xx:xx:xx:xx:xx + +qemu-system-x86_64 \ +-no-user-config -nodefaults \ +-show-cursor \ +-name u64d01 \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host -smp 4 -m 2048 \ +-overcommit mem-lock=off \ +-overcommit cpu-pm=off \ +-rtc base=utc,clock=host \ +\ +-device virtio-tablet-pci \ +-device virtio-vga \ +\ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ +\ +-device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +\ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0,out.buffer-count=10000 \ +\ +-cdrom $IMG_CD + +Removing the last -cdrom line Ubuntu desktop boot up and everything work perfectly except the audio. + +I test with wav audio driver by replacing the -audiodev line as follow, which save the client audio to a wave file, like below and it work perfectly: + +-audiodev wav,id=snd0,path=$HOME/qemu.wav + +I start the vm, open firefox and play a few video, then shutdown the vm. Then I can play the qemu.wav file and all the audio was recorded there. + +However, I can't get audio directly with coreaudio. + +First thing to check is whether you have any other audio applications installed, since there seems to be a long running issue whereby other applications can prevent QEMU from being able to output audio. See https://www.emaculation.com/forum/viewtopic.php?f=34&t=8848&sid=1e5fab3a08347beb3b344be0f953221e&start=150#p60978 for a discussion on this. + +Secondly does QEMU 4.1 audio work? There has been a report on list that there is an issue caused by conversion to the new backend audio APIs in 4.2 here: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg02142.html. + + +I am not using any audio enhancing software. + +I start trying qemu + Ubuntu Desktop a few weeks ago and put all configurations together last week, so I never try coreaudio on 4.1. + +I recently test it again, coreaudio is working on 4.1.1, 4.2 and 5rc1 on MacOS. + +It is working now. Tested with 4.1.1, 4.2 and 5rc1. + diff --git a/results/classifier/zero-shot/105/boot/1860742 b/results/classifier/zero-shot/105/boot/1860742 new file mode 100644 index 000000000..32461a223 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1860742 @@ -0,0 +1,75 @@ +boot: 0.589 +device: 0.575 +socket: 0.468 +graphic: 0.374 +assembly: 0.366 +other: 0.354 +semantic: 0.336 +vnc: 0.292 +mistranslation: 0.252 +network: 0.213 +instruction: 0.180 +KVM: 0.137 + +xv6 Bootloop + +Qemu Version: 4.2.0 + +Launch command: +qemu-system-x86_64 -nographic -drive file=fs.img,index=1,media=disk,format=raw -drive file=xv6.img,index=0,media=disk,format=raw -smp 2 -m 512 + +How to reproduce? +1.) Use/install latest release of qemu (4.2.0 at time of writing) + +2.) Download, build, and run xv6 (a simple os designed for learning operating systems fundamentals) + +cd /tmp +git clone https://github.com/mit-pdos/xv6-public.git +cd xv6-public +make qemu-nox + +3.) Qemu should now bootloop (seem to try to boot but then just repeat). This is what it looks like below before it repeats: + +SeaBIOS (version ?-20191223_100556-anatol) + +iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+1FF92A50+1FEF2A50 CA00 + +Booting from Hard Disk.. + + + +Host: Arch Linux - Kernel version: 5.4.13 +Guest: xv6 (https://github.com/mit-pdos/xv6-public) + +Suspicion: + +When I was using qemu 2.11.1 inside docker, the xv6 os booted with no problem. I am thinking that something changed between Qemu 2.11.1 and Qemu 4.2.0 which is now causing boot problems. + +Also in my ubuntu 19.10 system. + +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. + + +Still seems to be an issue for me. + +Qemu Version 5.2.0 +Arch Linux 5.11.16-arch1-1 + + +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/192 + + diff --git a/results/classifier/zero-shot/105/boot/1862110 b/results/classifier/zero-shot/105/boot/1862110 new file mode 100644 index 000000000..4e7054a5a --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1862110 @@ -0,0 +1,111 @@ +boot: 0.765 +other: 0.735 +network: 0.650 +device: 0.648 +mistranslation: 0.634 +semantic: 0.599 +socket: 0.593 +graphic: 0.592 +KVM: 0.559 +vnc: 0.539 +instruction: 0.521 +assembly: 0.446 + +qemu in script is not parsing properly + +Bug Report: +>>qemu-system-x86_64 --version: QEMU emulator version 4.2.0 +>>Arch-linux version 2020.02.01 +I was following a tutorial on how to make a windows vm and i have encountered and issue in the settings of my script I have listed below. + +The commented code directly above the uncommented qemu instance would boot the Windows screen but the issue arises when I try to reach the same code block under the commented setting lines which takes me to the default SeaBIOS loader. + + +#!/bin/bash + +vmname="windows10vm" + +if ps -ef | grep qemu-system-x86_64 | grep -q multifunction=on; then +echo "A passthrough VM is already running." & +exit 1 + +else + +# use pulseaudio + +export QEMU_AUDIO_DRV=pa +export QEMU_PA_SAMPLES=8192 +export QEMU_AUDIO_TIMER_PERIOD=99 +export QEMU_PA_SERVER=/run/user/1000/pulse/native + +cp /usr/share/ovmf/x64/OVMF_VARS.fd /tmp/my_vars.fd + +#qemu-system-x86_64 \ +#-drive id=disk0,if=virtio,cache=none,format=raw,file=.../IMGs/win.img \ +#-drive file=.../ISOs/Win10_1909_English_x64.iso,index=1,media=cdrom \ + +qemu-system-x86_64 \ + +#-name $vmname,process=$vmname \ +#-machine type=q35,accel=kvm \ +#-cpu host,kvm=off \ +#-smp 4,sockets=1,cores=3,threads=1 \ +#-m 8G \ +#-balloon none \ +#-rtc clock=host,base=localtime \ +#-vga none \ +#-nographic \ +#-serial none \ +#-parallel none \ +#-soundhw hda \ +#-usb \ +#-device usb-host,vendorid=...,productid=... \ +#-device usb-host,vendorid=...,productid=... \ +#-device vfio-pci,host=...,multifunction=on \ +#-device vfio-pci,host=... \ +#-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_VARS.fd \ +#-drive if=pflash,format=raw,file=/tmp/my_vars.fd \ +#-boot order= dc \ + +-drive id=disk0,if=virtio,cache=none,format=raw,file=.../IMGs/win.img \ +-drive file=.../ISOs/Win10_1909_English_x64.iso,index=1,media=cdrom \ +-drive file=.../ISOs/virtio-0.1.171.iso,index=2,media=cdrom \ + +#-netdev type=tap,id=net0,ifname=vmtap0,vhost=on \ +#-device virtio-net-pci,netdev=net0,mac=... \ + +exit 0 + +fi + +EDIT: The backslash under the ovmf setting was commented + +Your script is broken, you cannot mix continued lines, blank lines, and comments. Take for instance this example: + +--- +#!/bin/bash + +echo Hello \ +World + +echo Hello \ + +World + +echo Hello \ + +# Earth + +World +--- + +Which results in: + +$ ./hello.sh +Hello World +Hello +./hello.sh: line 8: World: command not found +Hello +./hello.sh: line 14: World: command not found + + diff --git a/results/classifier/zero-shot/105/boot/1862619 b/results/classifier/zero-shot/105/boot/1862619 new file mode 100644 index 000000000..a70f1d1bf --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1862619 @@ -0,0 +1,94 @@ +boot: 0.800 +device: 0.768 +graphic: 0.766 +semantic: 0.752 +instruction: 0.728 +network: 0.708 +vnc: 0.698 +assembly: 0.677 +other: 0.620 +socket: 0.534 +KVM: 0.469 +mistranslation: 0.380 + +"-serial telnet::xxxx,server" causes "Device 'serial0' is in use" + +I start qemu version 4.2.50 in a first terminal : + +$ sudo ./qemu-system-hppa -boot d -serial telnet::4441,server -drive if=scsi,bus=0,index=6,file=./hpux.img,format=raw -serial mon:stdio -D /tmp/foo -nographic -m 512 -d nochain -cdrom ./HPUX_9.05_Installation_Disc_S700.iso -D /tmp/foo -net nic,model=tulip -net tap + +qemu-system-hppa: -serial telnet::4441,server: info: QEMU waiting for connection on: disconnected:telnet:0.0.0.0:4441,server + +In another terminal, I launch "telnet localhost 4441" + +And in the qemu window I have the following error: + +Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:220: +qemu-system-hppa: Device 'serial0' is in use + +Try top put "-serial mon:stdio" before "-serial telnet::4441,server" + + +Effectively, no more error ! +Now, my hppa machine is booted on its installation support for HP-UX 10.20, et I am connected with telnet in an other terminal. I don't know what I must enter now (on a real machine, the installation starts automatically, if I remember well what I did in 1990 !) + +If I use an installation support HP-UX 11.00, the installation starts automatically. Then, it finds no disk for installation, but I will work on the drive option of qemu to resolve this trouble. +Thanks a lot for your help ! + +I would observe that it would be much better if the order of the -serial arguments did not matter so much. I know gcc has the same sort of madness (for instance), but it sure isn't intuitive. + +But in my case, when you do the -serial things out of order, you end up with a segfault. +That can't be the intended behavior. + +Yes, a segfault is definitely a bug. Can you give instructions to reproduce that (full command line, any necessary images) ? The example originally reported in this bug doesn't seem to be a segfault. + +I'm now using qemu-system-hppa version 5.2.50, and I can put "-serial mon: stdio" before or after "-serial telnet :: 4441, server" without a problem. + +#qemu-system-hppa --version +QEMU emulator version 5.2.50 (v5.2.0-1300-g0e32462630) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +For me, no more bug. + +Ok, since you said that there is no more bug, I'm closing this issue now. + +Reporting again. Compiled QEMU from the latest stable Git: + +QEMU emulator version 6.2.50 (v6.2.0-529-gfb084237a3) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +Exactly as original post, if I place -serial telnet::4441,server ahead of -serial mon,stdio on the command line, it dumps core and aborts. + +if I flip them, it runs... BUT! The vm console output appears in the terminal where I launched qemu, I get no output in the telnet session. That's backwards. I have no access to the qemu console and can't issue commands to do things like change the CDROM. + +full command startup script (this one works but output doesn't happen where I expect) + +#!/bin/sh +CDROM="-cdrom HP-UX-OE-1.iso" +QEMU=/home/ascott/Documents/hpux/qemu/qemu/build/qemu-system-hppa +IMAGE=/home/ascott/Documents/hpux/hpux.img +$QEMU -boot d -serial mon:stdio -serial telnet::4441,server -drive if=scsi,bus=0,index=6,file=$IMAGE,format=raw -nographic -m 512 -d nochain $CDROM -net nic,model=tulip -net user + +This one dumps core with the serial0 error from the originla post: + +#!/bin/sh +CDROM="-cdrom HP-UX-OE-1.iso" +QEMU=/home/ascott/Documents/hpux/qemu/qemu/build/qemu-system-hppa +IMAGE=/home/ascott/Documents/hpux/hpux.img +$QEMU -boot d -serial telnet::4441,server -serial mon:stdio -drive if=scsi,bus=0,index=6,file=$IMAGE,format=raw -nographic -m 512 -d nochain $CDROM -net nic,model=tulip -net user + +ascott@vmhost01:~/Documents/hpux$ sh ./install-hpux.sh +qemu-system-hppa: -serial telnet::4441,server: info: QEMU waiting for connection on: disconnected:telnet:0.0.0.0:4441,server=on +Unexpected error in qemu_chr_fe_init() at ../chardev/char-fe.c:220: +qemu-system-hppa: Device 'serial0' is in use +Aborted (core dumped) + + + + + + + + +Hi Andrew! The QEMU project does not use this bug tracker anymore - could you please open a new issue here: https://gitlab.com/qemu-project/qemu/-/issues - Thanks! + diff --git a/results/classifier/zero-shot/105/boot/1863508 b/results/classifier/zero-shot/105/boot/1863508 new file mode 100644 index 000000000..51dae171c --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1863508 @@ -0,0 +1,52 @@ +boot: 0.943 +instruction: 0.931 +device: 0.914 +socket: 0.894 +network: 0.892 +graphic: 0.891 +semantic: 0.886 +mistranslation: 0.885 +vnc: 0.831 +other: 0.752 +KVM: 0.732 +assembly: 0.653 + +qemu-system-arm stops with SIGSEGV in helper_gvec_eq16 + +Segmentation fault when trying to start FreeBSD-arm system with qemu-system-arm (version 4.1.1 on Fedora 31) + +Commandline: +gdb -q --args /bin/qemu-system-arm \ + -name FreeBSD12,debug-threads=on \ + -m 1536 -machine virt -smp 2 \ + -M virt,highmem=off -serial mon:stdio -monitor telnet::45452,server,nowait \ + -machine virt,accel=tcg,usb=off,dump-guest-core=off,gic-version=2 \ + -overcommit mem-lock=off -no-reboot -device virtio-rng-device \ + -bios u-boot-qemu.bin \ + -drive file=FreeBSD-12.1-RELEASE-arm-armv7-CUBIEBOARD2.img,if=none,id=drive0,format=raw \ + -device ich9-ahci,id=ahci -device ide-drive,drive=drive0,bus=ahci.0 + +Results: +.... +Mounting local filesystems:. + +Thread 4 "CPU 1/TCG" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffcedfe700 (LWP 53608)] +0x00005555558d9332 in helper_gvec_eq16 (d=0x5555566748d8, a=0x5555566748e0, b=0x5555566748d0, desc=0) at /usr/src/debug/qemu-4.1.1-1.fc31.x86_64/accel/tcg/tcg-runtime-gvec.c:948 +948 DO_CMP2(16) + +Tested different versions of qemu. qemu-3.0.1 worked, but qemu-3.1.1 failed with the same error. + +I infer from the traceback that your host does not support AVX1. + +Fix posted: +http://patchwork.ozlabs.org/patch/1238946/ + +Yes, the CPU is of the last generation without AVX. + +And yes, the patch worked for me. Thank you! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=43d1ccd2a02f + + diff --git a/results/classifier/zero-shot/105/boot/1872644 b/results/classifier/zero-shot/105/boot/1872644 new file mode 100644 index 000000000..cf0f7a35e --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1872644 @@ -0,0 +1,72 @@ +boot: 0.754 +device: 0.728 +instruction: 0.697 +network: 0.662 +mistranslation: 0.662 +graphic: 0.659 +socket: 0.607 +other: 0.606 +assembly: 0.555 +semantic: 0.499 +vnc: 0.431 +KVM: 0.238 + +MacOS host qemu-system-x86_64 -cpu host not working + +MacOS: 10.15.4 +uname -a: Linux door 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I am using qemu on mac host, with ubuntu client. + +I used to have "-cpu host" in my qemu command as follow:- + +qemu-system-x86_64 \ +-no-user-config \ +-nodefaults \ +-name u64d01 \ +-show-cursor \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host \ +-m 8192M \ +-smp 4 \ +-rtc base=utc,clock=host \ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=/Users/js/code/vm/qemu/u64d01.qcow2,if=none,format=qcow2 \ +-device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +-device virtio-tablet-pci \ +-device virtio-vga \ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0 + +Base on log of one of the vm, it was definitely working on 2020-01-17(base on journal inside vm), with qemu 4.2.0, which I installed with brew. + +The only way to make it work is to remove "-cpu host". + +Already tried with 4.1.1, 4.2 and 5.0rc2. Same result. + +To reproduce, try above with a Ubuntu 18.04 installation cd. Client will crash during kernel loading. + + + +I found that things were unstable unless the following were also added +-cpu Nehalem,-rdtscp +(the CPU can be higher than Nehalem but obviously your host CPU actually has to be equal or greater too) + +-rdtscp is a known issue that has since been workedaround (see bug #1894836 ). + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1873338 b/results/classifier/zero-shot/105/boot/1873338 new file mode 100644 index 000000000..1fe756e98 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1873338 @@ -0,0 +1,84 @@ +boot: 0.908 +semantic: 0.902 +graphic: 0.899 +assembly: 0.892 +instruction: 0.892 +other: 0.890 +device: 0.887 +vnc: 0.873 +mistranslation: 0.863 +socket: 0.832 +network: 0.784 +KVM: 0.742 + +Dos on the fly CD image replacement is not Working with DOS + +Im not able to exchange CD image on the fly (needed for some games). I messed with command like - in console(ATL+CRTL+2) eject ide1-cd0 and change ide-cd0 D:/Games/!Emulators/Dos-QEMU/ISOs/TestChangeISO.iso , but system so never able to find new CD data.. simply drive so empty.. but when i reboot virtual machine, new change image is now working. + + Qemu 4.2. + +Does this work with other guests, like Windows 95/98 as far as you can tell? Is it only a problem in DOS? What exact version of DOS are you seeing the problem with? + +I tried Win98 virtual machine here its working fine, without reboot. + + Im using MS-DOS 7.1 - integrated within and Win9x and classic MSDEX or SHSUCDX drivers for CD-ROM, but o dpmt thing that it matters. + +I think I need a bit more detail, I'm sorry. Can you explain to me the full environment you are seeing the problem in? + +Host: Windows? Linux? what version? If Linux, what kernel version? +Guest: what's the version of the guest you are running? Windows98, or a version of DOS directly? +Command-line: What's the QEMU command line you used? An exact command line helps. + +If it works OK in Windows98 but you are using a version of DOS embedded in Windows98, can you describe exactly the circumstance in which you are seeing stale CDROM data, with steps on how to reproduce? + +When it "doesn't work", can you explain the exact behavior you are seeing, in which application(s)? + + + +Host: I tried both Windows (10 64bit 19.09) and Linux host (Mint 19.3 64bit, kernel 5.40) system it really doesnt matters. + +Guest: Windows 98 - has integrated MS-DOS 7.1 you can boot into it through boot menu, which could be set by meditation of MSDOS.SYS, but you can install MS-DOS 7.1 Standalone too, without Windows, its the same. + https://winworldpc.com/product/ms-dos/7x + What DOS is after set up through Autoexec.bat and config.sys files. + Using DOS 7.1 make sense, because its most modern and supporting FAT32 file system. + + There is Qemu starting line i doubt that it will help, you can simulate problem with any DOS machine. +qemu-system-i386.exe ^ +-m 64 ^ +-hda HDDs\MS-DOS-Systen-5G.vmdk ^ +-hdb HDDs\DosData20G.vmdk ^ +-vga cirrus ^ +-soundhw sb16,adlib,pcspk ^ +-net nic,model=rtl8139 ^ +-net tap,ifname=TAP ^ +-cdrom Isos\dos71cd.iso ^ +-k en-us + + With Windows 98 - i run just commands in monitor.. open my computer and open cd drive - content of cd is changed.. its the same as in all later OSes XP- to Win10. Its working as expected. + + DOS - i boot into dos with cd drive driver enabled (lest say MSCDEX).. i run monitor, change cd image.. a trying to access it lets say that is drive E.. So i write "E:" <ENTER> to command line. I get error that drive is not accessible.. (command line should be switched to E:\ and here i should be able use "dir" to get list of files) but when i reboot machine, i see new exchange cd content.. so its at least somehow working. + Problem is that some games and programs require change cd on the fly, so reboot is not solution. + + You can simulate right behavior with Vmware or Virtualbox machine. + + Is you are not familar with MS-DOS, here are command to autoexec and config for enable use of cd-rom drive: +https://superuser.com/questions/778716/install-a-cd-rom-driver-on-ms-dos + + Problem is probably that present version of cd exchange simulation code is not good enough / compatible for MSCDEX or SHSUCDX DOS CD-ROM drivers.. to make same action as is exchange cd on physical computer. + + Windows 98 and later are using other drivers for it of course.. + +[Expired for QEMU because there has been no activity for 60 days.] + +Its not incomplete. i gave lots of info. + +You need to reset the state from Incomplete to New after you've provided the information. + + +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/206 + + diff --git a/results/classifier/zero-shot/105/boot/1874264 b/results/classifier/zero-shot/105/boot/1874264 new file mode 100644 index 000000000..e25df8512 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1874264 @@ -0,0 +1,423 @@ +semantic: 0.986 +boot: 0.982 +device: 0.982 +assembly: 0.982 +graphic: 0.981 +other: 0.980 +network: 0.977 +mistranslation: 0.976 +instruction: 0.974 +socket: 0.973 +vnc: 0.971 +KVM: 0.964 + +AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 4.2.93 (v5.0.0-rc3-8-g3119154db0-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER9" \ + -M pseries \ + -cpu POWER9 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs +processing splpar characteristic: HostThrs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Starqemu-system-ppc64: OS terminated: 888 102 700 C20 + + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER8" \ + -M pseries \ + -cpu POWER8 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs +processing splpar characteristic: HostThrs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Star** +ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 2.11.2 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER9" \ + -M pseries,cap-htm=off \ + -cpu POWER9 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Star +0539 +0811 +0539 +0812 +0708 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +078c +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +078c +0539 +2071 +0539 +2073 +0539 +25b3vscsi_send_capabilities: capabilities size mismatch ! +VSCSI: Unknown MAD type 09 + +0539 +0538 +0539 +0591 +0539 +0538 +0539 +0538 +0539 +25b0 +0539 + +0511 +0551 +0517 +0517 +0517 +0517 +0553 +0517 +0517 +0538 +0539 +0538 +0539 +270b +0539 +0538 +0539 +2070 +0539 +0538 +0539 +0811 +0539 +0811 +0539 +0812 +0708 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +078c +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +078c +04ee +078c +0727 +0727 +2071 +2072 +2072 +2071 +0539 +25b3 +0539 +25b5 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0581 +0539 +0538 +0539 +7000 +0539 +0538 +0539 +0538 +0539 +0538 +0581 +0581 +0539 +0538 +0539 +25b0 +0539 +0538 +0539 +0538 +0539 +0731 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +2028 +0539 +0538 +0539 + +0c33 +Saving Base Customize Data to boot disk +Starting the sync daemon +Starting the error daemon + +System initialization completed. +TE=OFF +CHKEXEC=OFF +CHKSHLIB=OFF +CHKSCRIPT=OFF +CHKKERNEXT=OFF +STOP_UNTRUSTD=OFF +STOP_ON_CHKFAIL=OFF +LOCK_KERN_POLICIES=OFF +TSD_FILES_LOCK=OFF +TSD_LOCK=OFF +TEP=OFF +TLP=OFF +Successfully updated the Kernel Authorization Table. +Successfully updated the Kernel Role Table. +Successfully updated the Kernel Command Table. +Successfully updated the Kernel Device Table. +Successfully updated the Kernel Object Domain Table. +Successfully updated the Kernel Domains Table. +Successfully updated the Kernel RBAC log level. +Successfully updated the Kernel RBAC log level. +OPERATIONAL MODE Security Flags +ROOT : ENABLED +TRACEAUTH : DISABLED +System runtime mode is now OPERATIONAL MODE. +Setting tunable parameters...complete +Checking for srcmstr active...complete +Starting tcpip daemons: +0513-059 The sendmail Subsystem has been started. Subsystem PID is 4456846. +0513-059 The syslogd Subsystem has been started. Subsystem PID is 4522382. +0513-059 The portmap Subsystem has been started. Subsystem PID is 4194776. +0513-059 The inetd Subsystem has been started. Subsystem PID is 4129230. +0513-059 The snmpmibd Subsystem has been started. Subsystem PID is 4325672. +Finished starting tcpip daemons. + + +AIX Version 7 +Copyright IBM Corporation, 1982, 2019. +Console login: root +root's Password: + +******************************************************************************* +* * +* * +* Welcome to AIX Version 7.2! * +* * +* * +* Please see the README file in /usr/lpp/bos for information pertinent to * +* this release of the AIX Operating System. * +* * +* * +******************************************************************************* +Last login: Wed Apr 22 07:21:19 EDT 2020 on /dev/vty0 + +root@aix-ppc64# oslevel -s +7200-04-01-1939 +root@aix-ppc64# + +Did this ever work before? AFAIK AIX was never really running on QEMU... + +Hi, Thomas. Yes! Of course I had it working beautifully before, with only a minor issue executing a small number of XCOFF binaries, that is why I specified the QEMU version (2.11.2) AIX last worked with in the title of this bug. + +Check it out: + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 2.11.2 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +kens@LAPTOP-JN77KAC2$ ssh -p9018 localhost +Last login: Thu May 6 10:06:55 EDT 2021 on ssh from 10.0.2.2 +******************************************************************************* +* * +* * +* Welcome to AIX Version 7.2! * +* * +* * +* Please see the README file in /usr/lpp/bos for information pertinent to * +* this release of the AIX Operating System. * +* * +* * +******************************************************************************* +kens@aix-ppc64$ lsattr -El sys0 -a modelname +modelname IBM pSeries (emulated by qemu) Machine name False + +kens@aix-ppc64$ lsattr -El proc0 +frequency 1000000000 Processor Speed False +smt_enabled false Processor SMT enabled False +smt_threads 1 Processor SMT threads False +state enable Processor state False +type PowerPC_POWER9 Processor type False + + + +Pretty cool, right? + +Something changed after 2.11.2 that broke something in the tcg cpu execution emulation. + +This is the error I get when I try to boot AIX in any QEMU version > 2.11.2: + +ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/269 + + diff --git a/results/classifier/zero-shot/105/boot/1879590 b/results/classifier/zero-shot/105/boot/1879590 new file mode 100644 index 000000000..0176e7619 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1879590 @@ -0,0 +1,86 @@ +boot: 0.878 +network: 0.863 +other: 0.787 +instruction: 0.753 +graphic: 0.739 +device: 0.698 +socket: 0.670 +mistranslation: 0.652 +semantic: 0.599 +vnc: 0.482 +assembly: 0.429 +KVM: 0.274 + +Using qemu-system-sparc64 no network interface seems to exist + +Using boot command: + +qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2 + +After I log into solaris system I see no network devices other than the loopback device. +All the docs I can see suggest it should come up with a default network device that allows communication via the hosts network. Host is ubuntu 64bit. + +root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + +dladm show-link +ifconfig -a + + + +ok boot +Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54. +FCode UFS Reader 1.12 00/07/17 15:48:16. +Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot +Loading: /platform/sun4v/ufsboot +SunOS Release 5.10 Version Generic_118822-23 64-bit +Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Hostname: unknown + +unknown console login: root +Last login: Wed Feb 8 09:01:28 on console +Sun Microsystems Inc. SunOS 5.10 Generic January 2005 +# dladm show-link +# ifconfig -a +lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 + inet 127.0.0.1 netmask ff000000 + +Unfortunately it's been a while and no one has added the proper support to qemu yet, see comments at: +http://tyom.blogspot.com/2016/10/qemu-sun4vniagara-target-went-public.html +Apparently the niagara PCI adapter has to be implemented and the firmware recompiled to enable it. + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1883593 b/results/classifier/zero-shot/105/boot/1883593 new file mode 100644 index 000000000..ff5a5f5ee --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1883593 @@ -0,0 +1,67 @@ +boot: 0.695 +instruction: 0.643 +other: 0.618 +semantic: 0.611 +device: 0.601 +vnc: 0.549 +graphic: 0.527 +socket: 0.475 +network: 0.460 +assembly: 0.354 +mistranslation: 0.279 +KVM: 0.080 + +Windows XP takes much longer to boot in TCG mode since 5.0 + +Since upgrading from 4.2 to 5.0, a Windows XP VM takes much longer to boot. + +It hangs about three minutes on "welcome" screen with the blue background, while previously the total boot time was less than a minute. + +The issue only happens in TCG mode (not with KVM) and also happens with the current master which includes the uring patches (7d3660e7). + +I can reproduce this issue with a clean XP install with no flags other than `-m 2G`. After booting, the performance seems to be normal. + +Are you able to bisect between 4.2 and 5.0 and identify what introduces the slow down? + +Bisecting showed that this is the bad commit: + + b55f54bc965607c45b5010a107a792ba333ba654 exec: flush CPU TB cache in breakpoint_invalidate + +And I can indeed confirm that this commit is much slower than the previous one, e18e5501d8ac692d32657a3e1ef545b14e72b730. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + + +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/404 + + diff --git a/results/classifier/zero-shot/105/boot/1888417 b/results/classifier/zero-shot/105/boot/1888417 new file mode 100644 index 000000000..c865e2bfc --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1888417 @@ -0,0 +1,50 @@ +boot: 0.863 +vnc: 0.850 +device: 0.780 +graphic: 0.773 +other: 0.762 +instruction: 0.689 +semantic: 0.676 +mistranslation: 0.594 +socket: 0.590 +network: 0.543 +KVM: 0.405 +assembly: 0.340 + +Latest QEMU git build on Arch linux causes PCI Passthrough host to hang on guest reboot. + +Current Arch linux release, up-to-date as of 7/21/2020. + +Running a windows 7 virtual machine (also happens with windows 10, possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is attempted to be restarted, either through the guest interface, or by libvirt's gui interface "Virtual Machine Manager", it hangs in a "paused" state once the VM shutsdown, and just before the reboot can take place. A force-stop of the VM allows the VM to be properly booted without any disk error checks, alluding to a clean shutdown, but failed reboot. The VM can be properly shutdown using the guests shutdown function, or the libvirt manager shutdown, without any hangs. Reverting to Arch stable build QEMU 5.0.0-7 fixes the issue. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1890290 b/results/classifier/zero-shot/105/boot/1890290 new file mode 100644 index 000000000..521d2f792 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1890290 @@ -0,0 +1,151 @@ +boot: 0.975 +network: 0.973 +device: 0.972 +instruction: 0.972 +other: 0.971 +assembly: 0.970 +semantic: 0.969 +socket: 0.969 +graphic: 0.968 +KVM: 0.968 +vnc: 0.958 +mistranslation: 0.926 + +PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual,kernel-irqchip=on - `KVM is too old to support ic-mode=dual,kernel-irqchip=on` + +Env: +HW: Power 9 DD2.3 +Host L0: 5.8.0-rc5-g8ba4ffcd8 +Qemu: 5.0.50 (v5.0.0-533-gdebe78ce14) +Libvirt: 6.4.0 +L1: 5.8.0-rc5-ge9919e11e +qemu_version': '5.0.50 (v5.1.0-rc2-dirty) +libvirt_version': '6.4.0' +L2: 5.8.0-rc7-g6ba1b005f + + +1. boot a L2 KVM guest with `ic-mode=dual,kernel-irqchip=on` + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=2,t +hreads=4 --import --nographics --serial pty --memballoon model=virtio --disk path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=virtio,size=10,format=qcow2 --network +=bridge=virbr0,model=virtio,mac=52:54:00:e6:fe:f6 --mac=52:54:00:e6:fe:f6 --boot emulator=/usr/share/avocado-plugins-vt/bin/qemu,kernel=/tmp/linux/vmlinux,kernel_args="root=/de +v/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole --qemu-commandline=" -M pseries,ic-mode=dual,kernel-irqchip=on" + + +ERROR internal error: process exited while connecting to monitor: 2020-08-04T11:12:53.304482Z qemu: KVM is too old to support ic-mode=dual,kernel-irqchip=on + + + + +Qemu Log: +``` +/usr/share/avocado-plugins-vt/bin/qemu \ +-name guest=vm1,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-vm1/master-key.aes \ +-machine pseries-5.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu POWER9 \ +-m 8192 \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,cores=2,threads=4 \ +-uuid 20a3351b-2776-4e75-9059-c070fe3dd44b \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=34,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-kernel /tmp/linux/vmlinux \ +-append 'root=/dev/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0' \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \ +-blockdev '{"driver":"file","filename":"/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1 \ +-netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:fe:f6,bus=pci.0,addr=0x1 \ +-chardev pty,id=charserial0 \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-chardev socket,id=charchannel0,fd=39,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ +-M pseries,ic-mode=dual,kernel-irqchip=on \ +-msg timestamp=on +2020-08-04 11:12:53.169+0000: Domain id=5 is tainted: custom-argv +2020-08-04 11:12:53.179+0000: 11120: info : libvirt version: 6.4.0, package: 1.fc31 (Unknown, 2020-06-02-05:09:40, ltc-wspoon4.aus.stglabs.ibm.com) +2020-08-04 11:12:53.179+0000: 11120: info : hostname: atest-guest +2020-08-04 11:12:53.179+0000: 11120: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x7fff0c117c40 +char device redirected to /dev/pts/0 (label charserial0) +2020-08-04T11:12:53.304482Z qemu: KVM is too old to support ic-mode=dual,kernel-irqchip=on +2020-08-04 11:12:53.694+0000: shutting down, reason=failed +``` + +This is currently expected because the L2 KVM guest uses the historical KVM XICS device (not the XICS-on-XIVE one) and this can be only created once during the VM lifetime for the moment. + +This is a limitation in KVM, that can be addressed in several ways: +1) change the historical KVM XICS device to implement the release() method instead of destroy(), so that userspace can close() and re-create the device multiple times during the VM lifetime, as we have already done in KVM XIVE and KVM XICS-on-XIVE for powernv +2) have the KVM XICS-on-XIVE device to work under pseries + +I already have a tentative patch for 1) and I guess 2) would be part of a more global work to supporting nested KVM XIVE. + +But it is definitely not an issue in QEMU. + + +As per this the table https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#kvm-negotiation + +reported qemu error msg "KVM is too old to support ic-mode=dual,kernel-irqchip=on" indicates the +guest os is legacy, but that's not the case here, whereas kernel levels are near upstream which has support for xive. + +My understanding of the env I used as below + +Level | XIVE KVM support | XIVE support(in kernel or emulation) +-------------------------------------------------- + L0 | Yes | Yes + L1 | No | Yes(booted with irqchip: in-kernel) + L2 | No | Yes + +So, ideally when a L2 guest is started with ic-mode=dual,kernel-irqchip=on, we should have seen below error +(2) QEMU fails with ``kernel_irqchip requested but unavailable: + IRQ_XIVE capability must be present for KVM`` + +but we actually saw the reported one, which is misleading. + + + +this section of table in particular, https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#no-xive-support-in-kvm + +Hmm... the documentation might need an update. I'll have a look. + +Posted a patch to the list. + +http://patchwork.ozlabs.org/project<email address hidden>/ + +Satheesh, + +Can you please review and test ? + + +@Greg, + +Thanks for the patch, I see it already got applied into 5.2, tested and works fine, + +# git log -2 --oneline +1972794 (HEAD -> master) spapr: Clarify error and documentation for broken KVM XICS +e1d322c (grafted, tag: v5.1.0-rc3, origin/master, origin/HEAD) Update version for v5.1.0-rc3 release + + + +# /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=8,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:5c:f1:fe --mac=52:54:00:5c:f1:fe --boot emulator=/home/qemu/ppc64-softmmu/qemu-system-ppc64,kernel=/boot/vmlinuz-5.8.0-rc5-ge9919e11e,kernel_args="root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole --qemu-commandline=" -M pseries,ic-mode=dual,kernel-irqchip=on";virsh console vm1 + +Starting install... +ERROR internal error: process exited while connecting to monitor: 2020-08-07T07:05:38.633057Z qemu-system-ppc64: KVM is incompatible with ic-mode=dual,kernel-irqchip=on +This can happen with an old KVM or in a KVM nested guest. +Try without kernel-irqchip or with kernel-irqchip=off. + +Regards, +-Satheesh + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/105/boot/1896754 b/results/classifier/zero-shot/105/boot/1896754 new file mode 100644 index 000000000..ec3b70a84 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1896754 @@ -0,0 +1,53 @@ +boot: 0.745 +instruction: 0.728 +other: 0.709 +graphic: 0.611 +semantic: 0.609 +device: 0.579 +network: 0.543 +socket: 0.504 +mistranslation: 0.496 +vnc: 0.400 +assembly: 0.302 +KVM: 0.281 + +Performance degradation for WinXP boot time after b55f54bc + +Qemu 5.1 loads Windows XP in TCG mode 5-6 times slower (~2 minutes) than 4.2 (25 seconds), I git bisected it, and it appears that commit b55f54bc965607c45b5010a107a792ba333ba654 causes this issue. Probably similar to an older fixed bug https://bugs.launchpad.net/qemu/+bug/1672383 + +Command line is trivial: qemu-system-x86_64 -nodefaults -vga std -m 4096M -hda WinXP.qcow2 -monitor stdio -snapshot + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Ticket has been moved here (thanks, Maksim!): +https://gitlab.com/qemu-project/qemu/-/issues/286 +Thus closing this one at Launchpad now. + diff --git a/results/classifier/zero-shot/105/boot/1906181 b/results/classifier/zero-shot/105/boot/1906181 new file mode 100644 index 000000000..fe25bf4f9 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1906181 @@ -0,0 +1,59 @@ +boot: 0.933 +graphic: 0.914 +other: 0.882 +instruction: 0.770 +device: 0.747 +KVM: 0.667 +semantic: 0.611 +vnc: 0.548 +mistranslation: 0.528 +network: 0.525 +assembly: 0.480 +socket: 0.397 + +Mouse starts jumping wildly on guest desktop + +Sometimes mouse goes completely crazy and starts jumping around the guest desktop by itself and becomes completely unusable. + +This does not happen on every boot, only sometimes. It may be caused by some input combination but I haven't yet found any specific cause. It happens soon after the desktop has been loaded and rebooting seems to be the only way to resolve the situation. + + +Guest: Kubuntu 20.04 64-bit (live), with KDE desktop +Host: Arch Linux, with KDE desktop +QEMU version: 5.1.0 + +QEMU start command: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/1910 b/results/classifier/zero-shot/105/boot/1910 new file mode 100644 index 000000000..685c0ef07 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1910 @@ -0,0 +1,75 @@ +boot: 0.829 +device: 0.678 +socket: 0.657 +network: 0.595 +instruction: 0.589 +vnc: 0.551 +semantic: 0.529 +graphic: 0.529 +KVM: 0.380 +mistranslation: 0.363 +other: 0.315 +assembly: 0.168 + +Signal handlers in x86_64 userspace have wrongly aligned stack +Description of problem: +Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause. + +```plaintext +> qemu-x86_64 /usr/bin/ruby -e '`true`' +-e:1: [BUG] Segmentation fault at 0x0000000000000000 +ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu] + +-- Control frame information ----------------------------------------------- +c:0003 p:---- s:0011 e:000010 CFUNC :` +c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] +c:0001 p:0000 s:0003 E:0015b0 DUMMY [FINISH] + +-- Ruby level backtrace information ---------------------------------------- +-e:1:in `<main>' +-e:1:in ``' + +-- Machine register context ------------------------------------------------ + RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98 + RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000 + RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000 + R8: 0x00002aaaab2aaa50 R9: 0x0000000000000050 R10: 0x0000000000000008 + R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310 + R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246 + +-- C level backtrace information ------------------------------------------- +``` + +```plaintext +(gdb) x/i $pc +=> 0x2aaaab50f98a: movaps %xmm0,(%rsp) +(gdb) p/x $rsp +$3 = 0x2aaaab2a9998 +``` +Steps to reproduce: +1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'``` +Additional information: +The x86_64 psABI says: + +> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point. + +However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`. + +The relevant kernel code: + +https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123 + +```plaintext + sp -= frame_size; + + if (ia32_frame) + /* + * Align the stack pointer according to the i386 ABI, + * i.e. so that on function entry ((sp + 4) & 15) == 0. + */ + sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4; + else + sp = round_down(sp, FRAME_ALIGNMENT) - 8; +``` + +CC @lvivier @bonzini @rth7680 diff --git a/results/classifier/zero-shot/105/boot/1914117 b/results/classifier/zero-shot/105/boot/1914117 new file mode 100644 index 000000000..5ec902dd4 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1914117 @@ -0,0 +1,449 @@ +semantic: 0.968 +boot: 0.962 +network: 0.961 +other: 0.960 +graphic: 0.956 +device: 0.956 +instruction: 0.955 +assembly: 0.953 +vnc: 0.907 +mistranslation: 0.894 +socket: 0.872 +KVM: 0.769 + +Short files returned via FTP on Qemu with various architectures and OSes + + +Qemu 5.2 on Mac OS X Big Sur. + +I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +Still getting the same problem,. + +On the following architectures: +arm64, amd64 and sometimes i386 running NetBSD host OS; +i386 running OpenBSD host OS: + +I have seen a consistent problem with FTP returning short files. The file will be a couple of bytes too short. I do not believe this is a problem with the OS. Downloading the perl source code from CPAN does not work properly, nor does downloading bind from isc. I've tried this on different architectures as above. + +(Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My gut feel is there is something not right on the Mac OS version of Qemu or a bug in 5.2 - obviously in the network layer somewhere. If you have anything you want me to try, please let me know - happy to help get a resolution.) + +Please provide more information: How did you compile QEMU? Which version did you exactly use? And most important: How do you *run* QEMU? System emulation? User mode? What kind of FTP are you doing?? + +Apologies. + + +Host OS is Big Sur Mac OS X latest - with Xcode latest. Qemu is 5.2 - tar ball directly from the website. + +- Compile Qemu on Mac OS/Big Sur - completely stock build : install Ninja, mkdir build && cd build && ../configure && make && make install +- But also the issue is with the binary in home-brew (e.g. brew install Qemu) - both methods get me to the same problem. + +* Installed NetBSD/amd64 or i386 or OpenBSD/i386. +Qemu-image create -f raw image 10G +qmu-system-ARCH -m 256M -hda image -cdrom “netbsd.iso” -boot d -net user -net nic + +(For i386 & amd64 I tend to add -nographic for the installer) + +* Run the image: +Qmu-system-ARCH -m 256M -hda $IMAGE -net user -net nic + +Also NetBSD/arm64 has the issue using their image. +qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 4 -m 4g \ + -drive if=none,file=netbsd-disk-arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -bios QEMU_EFI.fd -nographic + +* The issue seems to be downloading large files. +In the host OS two files that seem to tickle the bug often are: + +* ftp -a http://cpan.pair.com/src/5.0/perl-5.32.1.tar.xz +On NetBSD this file seems to be one byte shorter than it should be. On arm64 is was several bytes shorter. + +* ftp -a ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Also seems to tickle the bug + +I saw this while trying to use pkgsrc on NetBSD. Saw this on Amd64, i386 and arm64. Tried OpenBSD to rule out NetBSD as the problem. OpenBSD/i386 sees the same issue (ftp returns short read and file is a couple of bytes smaller). + +The screenshot is from amd64 - a fresh boot this morning running on a fairly idle host. + +Kind regards +Chris + + +Apologies. + + +Host OS is Big Sur Mac OS X latest - with Xcode latest. Qemu is 5.2 - tar ball directly from the website. + +- Compile Qemu on Mac OS/Big Sur - completely stock build : install Ninja, mkdir build && cd build && ../configure && make && make install +- But also the issue is with the binary in home-brew (e.g. brew install Qemu) - both methods get me to the same problem. + +* Installed NetBSD/amd64 or i386 or OpenBSD/i386. +Qemu-image create -f raw image 10G +qmu-system-ARCH -m 256M -hda image -cdrom “netbsd.iso” -boot d -net user -net nic + +(For i386 & amd64 I tend to add -nographic for the installer) + +* Run the image: +Qmu-system-ARCH -m 256M -hda $IMAGE -net user -net nic + +Also NetBSD/arm64 has the issue using their image. +qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 4 -m 4g \ + -drive if=none,file=netbsd-disk-arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -bios QEMU_EFI.fd -nographic + +* The issue seems to be downloading large files. +In the host OS two files that seem to tickle the bug often are: + +* ftp -a http://cpan.pair.com/src/5.0/perl-5.32.1.tar.xz +On NetBSD this file seems to be one byte shorter than it should be. On arm64 is was several bytes shorter. + +* ftp -a ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Also seems to tickle the bug + + + +I saw this while trying to use pkgsrc on NetBSD. Saw this on Amd64, i386 and arm64. Tried OpenBSD to rule out NetBSD as the problem. OpenBSD/i386 sees the same issue (ftp returns short read and file is a couple of bytes smaller). + +The screenshot is from amd64 - a fresh boot this morning running on a fairly idle host. + +Kind regards +Chris + +> On 2 Feb 2021, at 05:24, Thomas Huth <email address hidden> wrote: +> +> Please provide more information: How did you compile QEMU? Which version +> did you exactly use? And most important: How do you *run* QEMU? System +> emulation? User mode? What kind of FTP are you doing?? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions + + + +Some more info. + +This evening I've tried some more things. + +Qemu 5.2/Mac OS X Catalina (Qemu from home-brew) + +Host OS - OpenBSD/i386 +1. Booted with + +2. Booted with +qemu-system-i386 -m 256M -hda openbsd-disk-i386.img -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 + +With both ftp'ed ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Both were short and did not match the find at ISC. + +See attached. SHA1 should be 1bfb5725c85fd9dffe868d8e826a1f8c0de509cc + + +First boot in previous comment was with: +qemu-system-i386 -m 256M -hda openbsd-disk-i386.img -net user -net nic + +I've spent some more time on this. +I've tcpdump'ed the connection whilst doing the download (via both HTTP & FTP). + +In the last data packet, the last byte that is missing on the filesystem is in the packet, but the packet has the urgent bit set with the urgent pointer the same as the length of the packet. + +I'm not sure but this might cause the client app to discard part of the packet? +Unclear. + +Also I've build Qemu 4.2.1 on MacOS X/Big Sur - I'm seeing the same issue on FreeBSD/amd64. +This bug might be related: +https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237441 + + +The more I look at this, the more I think it may be a macOS bug underneath. + +I've tested OpenBSD as a guest on a Debian AWS instance running 4.2.1 - all is fine. +I've tested OpenBSD as a guest on a FreeBSD AWS instance running whatever is in ports and all is fine. + +Also others are having trouble: +https://twitter.com/astr0baby/status/1354952352713887754 +Mac OS on M1 silicon with Free and NetBSD as guest OS. + + +This is NOT a fix but we can get working FTPs again with this patch - narrowing into where the problem is. Looks like the behaviour of this code is different on macOS to other OSes. + +--- slirp.c.orig 2021-02-08 21:05:20.000000000 +0000 ++++ slirp.c 2021-02-10 11:00:00.000000000 +0000 +@@ -621,18 +621,7 @@ + * This will soread as well, so no need to + * test for SLIRP_POLL_IN below if this succeeds + */ +- if (revents & SLIRP_POLL_PRI) { +- ret = sorecvoob(so); +- if (ret < 0) { +- /* Socket error might have resulted in the socket being +- * removed, do not try to do anything more with it. */ +- continue; +- } +- } +- /* +- * Check sockets for reading +- */ +- else if (revents & ++ if (revents & + (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { + /* + * Check for incoming connections + +ok - one of my friends has written a test program. we will provide a writeup tomorrow, but basically towards the end of a stream both HUP & PRI are getting set on a poll call (on Mac) which means the code above would be invoked - on other platforms these aren't see. Better explanation & more details to follow tomorrow. + + +Writeup as promised. + +Symptom: +-------- +Qemu on Mac OS X - both Catalina and Big Sur. +The issue occurs in both 5.2 and 4.2* branches of Qemu. + +Applications such as ftp that read large amounts of data from the network +may ignore valid data due to the Urgent flag being set on packets in the +stream. + +- Install a Unix VM (e.g. NetBSD, OpenBSD, etc) on Qemu using Mac OS X. +- Try to FTP a large file, such as + ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz + and you will be one byte short (not just this file, it's just an ex). + +Synopsis: +--------- +- On inspection, the urgent flag is being set on the last packet of data +- As a result data is missing and is not received by the client app + because it is considered out of band. +- poll() on Mac OS X has different behaviour to other Unices. +- towards the end of a stream, PRI and HUP are sent (whereas on FreeBSD + and others it is not) +- as a result of PRI, the slirp library used in Qemu for the user + network interface adds an urgent bit to the relevant packets + +To see the different behaviour, we setup a server to serve a large file +and wrote a client to receive it, using poll() and dumping information about the flags. + +Here is FreeBSD - the IN flag is set throughout. + +ec2-user@freebsd:~/polltest $ ./a.out -w -P lXXX.net +Resolving lXXX.net: trying XXX.XXX.XXX.XXX... OK +FD 3 ready: POLLIN +Read 1024 byte(s) +FD 3 ready: POLLIN +Read 1024 total byte(s) +[snipped] + +FD 3 ready: POLLIN +Read 102400 total byte(s) +ec2-user@freebsd:~/polltest $ + +Here is Mac OS X (Big Sur). You can see at the end of the stream, +both PRI & HUP are set. + +Resolving lXXX.net: trying XXX.XXX.XXX.XXX .. OK +FD 5 ready: POLLIN +Read 1024 byte(s) +[Snipped] + +FD 5 ready: POLLIN +Read 416 byte(s) +FD 5 ready: POLLIN POLLPRI POLLHUP +Hangup on FD 5 +Read 160 byte(s) +FD 5 ready: POLLIN POLLPRI POLLHUP +Hangup on FD 5 +Read 102400 total byte(s) + +Towards a fix: +-------------- +The following patch removes the symptom simply by ignoring these flags. +This is not necessarily the final answer, but we have run with this patch +for a couple of days and haven't seen any negative behaviour. + +diff -ru qemu-5.2.0/slirp/src/slirp.c qemu-5.2.0-wrk/slirp/src/slirp.c +--- qemu-5.2.0/slirp/src/slirp.c 2021-02-10 11:02:07.000000000 +0000 ++++ qemu-5.2.0-wrk/slirp/src/slirp.c 2021-02-10 13:07:17.000000000 +0000 +@@ -23,7 +23,7 @@ + * THE SOFTWARE. + */ + #include "slirp.h" +- ++#define IGNOREPOLLPRI + + #ifndef _WIN32 + #include <net/if.h> +@@ -621,6 +621,8 @@ + * This will soread as well, so no need to + * test for SLIRP_POLL_IN below if this succeeds + */ ++ ++#ifndef IGNOREPOLLPRI + if (revents & SLIRP_POLL_PRI) { + ret = sorecvoob(so); + if (ret < 0) { +@@ -633,6 +635,9 @@ + * Check sockets for reading + */ + else if (revents & ++#else ++ if (revents & ++#endif + (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { + /* + * Check for incoming connections + + +Adam Chappell figured most of this out (because a. he is (mostly) cleverer than me, b. he didn't sell his copy of Stevens UNIX Network Programming like I did in the 00s). + +Maybe related: +https://bugs.launchpad.net/qemu/+bug/1916344 +(and https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 ) + +libslirp now has a workaround for this in slirp.c. + +Could we close this ticket now if there is a workaround in libslirp now? + +If it’s included in qemu when one downloads the sources I’m happy. + +Sent from my iPhone + +> On 15 May 2021, at 11:55, Thomas Huth <email address hidden> wrote: +> +> Could we close this ticket now if there is a workaround in libslirp now? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions + + +slirp has been updated for QEMU 6.1-rc2, so this should be fixed in the latest 6.1 release candidate. If you've got some spare minutes, could you please check whether it's working for you now in 6.1-rc4 ? + +I tested Qemu 6.1 (MacOS using brew to install) with guest OS NetBSD/i386. The bind distribution file downloaded fine by FTP. +Libslurp has a workaround for MacOS and it looks like its gone in. +I think this one can be closed. +Sorry for the delay +Kind regards +Chris + + +> On 25 Aug 2021, at 08:18, Thomas Huth <email address hidden> wrote: +> +> ** Changed in: qemu +> Status: Fix Committed => Fix Released +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions +> + + + diff --git a/results/classifier/zero-shot/105/boot/1921280 b/results/classifier/zero-shot/105/boot/1921280 new file mode 100644 index 000000000..803c45344 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/1921280 @@ -0,0 +1,53 @@ +boot: 0.902 +graphic: 0.823 +other: 0.796 +device: 0.785 +instruction: 0.677 +mistranslation: 0.661 +semantic: 0.617 +network: 0.581 +vnc: 0.552 +socket: 0.445 +assembly: 0.307 +KVM: 0.277 + +OpenIndiana stuck in boot loop when using hvf + +I'm using QEMU version 5.2.0 on macOS, and running the "OpenIndiana Hipster 2020.10 Text Install DVD (64-bit x86)" ISO: + +qemu-system-x86_64 -cdrom ~/Downloads/OI-hipster-text-20201031.iso -m 2048 -accel hvf -cpu host + +It gets to "Booting...", stays there for a bit, and then restarts. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/2034 b/results/classifier/zero-shot/105/boot/2034 new file mode 100644 index 000000000..cff1cc598 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2034 @@ -0,0 +1,21 @@ +boot: 0.958 +graphic: 0.935 +device: 0.794 +semantic: 0.723 +instruction: 0.693 +socket: 0.602 +network: 0.490 +vnc: 0.473 +mistranslation: 0.450 +KVM: 0.308 +other: 0.163 +assembly: 0.130 + +ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +Description of problem: +``` +cat boot.log +aarch64>** +aarch64>ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +aarch64>Bail out! ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +``` diff --git a/results/classifier/zero-shot/105/boot/2183 b/results/classifier/zero-shot/105/boot/2183 new file mode 100644 index 000000000..989917f70 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2183 @@ -0,0 +1,33 @@ +boot: 0.916 +instruction: 0.852 +graphic: 0.830 +device: 0.789 +semantic: 0.758 +other: 0.505 +vnc: 0.499 +socket: 0.431 +network: 0.298 +KVM: 0.251 +assembly: 0.145 +mistranslation: 0.116 + +aarch-64 emulation much slower since release 8.1.5 (issue also present on 8.2.1) +Description of problem: +Since QEMU 8.1.5 our aarch64 based emulation got much slower. We use a linux 5.4 kernel which we cross-compile with the ARM toolchain. Things that are noticable: +- Boot time got a lot longer +- All memory accesses seem to take 3x longer (can be verified by e.g. executing below script, address does not matter): +``` +date +for i in $(seq 0 1000); do + devmem 0x200000000 2>/dev/null +done +date +``` +Steps to reproduce: +Just boot an ARM based kernel on the virt machine and execute above script. +Additional information: +I've tried reproducing the issue on the master branch. There the issue is not present. It only seems to be present on releases 8.1.5 and 8.2.1. + +I've narrowed the problem down to following commit on the 8.2 branch (@bonzini): ef74024b76bf285e247add8538c11cb3c7399a1a accel/tcg: Revert mapping of PCREL translation block to multiple virtual addresses. + +Let me know if any other information / tests are required. diff --git a/results/classifier/zero-shot/105/boot/2193 b/results/classifier/zero-shot/105/boot/2193 new file mode 100644 index 000000000..443fc9e96 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2193 @@ -0,0 +1,43 @@ +boot: 0.937 +graphic: 0.929 +other: 0.891 +device: 0.818 +instruction: 0.813 +mistranslation: 0.728 +network: 0.614 +semantic: 0.610 +vnc: 0.580 +assembly: 0.562 +KVM: 0.489 +socket: 0.431 + +qemu-system-mips64el 70 times slower than qemu -ppc64, -riscv64, -s390x +Description of problem: +I installed Debian 12 inside a `qemu-system-mips64el` virtual machine. The performances are awfully slow, roughly 70 times slower than other qemu targets on the same host, namely ppc64, riscv64, s390x. + +The idea is to recompile and test an open source project on various platforms. + +Using a command such as `time make path/to/bin/file.o`, I compiled one single source file on the host and within qemu for various targets. The same source file, inside the same project, is used in all cases. + +The results are shown below (the "x" number between parentheses is the time factor compared to the compilation on the host). + +- Host (native): 0m1.316s +- qemu-system-ppc64: 0m31.622s (x24) +- qemu-system-riscv64: 0m40.691s (x31) +- qemu-system-s390x: 0m43.459s (x33) +- qemu-system-mips64el: 48m33.587s (x2214) + +The compilation of the same source is 24 to 33 times slower on the first three emulated targets, compared to the same compilation on the host, which is understandable. However, the same compilation on the mips64el target is 2214 time slower than the host, roughly 70 times slower than other emulated targets. + +Why do we have such a tremendous difference between qemu mips64el and other targets? +Additional information: +For reference, here are the other qemu to boot the other targets. Guest OS are Debian 12 or Ubuntu 22. +``` +qemu-system-ppc64 -smp 8 -m 8192 -nographic ... +qemu-system-riscv64 -machine virt -smp 8 -m 8192 -nographic ... +qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic ... +``` + +The other targets use `-smp 8` while qemu-system-mips64el does not support smp. However, the test compiles one single source file and does not (or marginally) use more than one CPU. + +Arguably, each compilation addresses a different target, uses a different backend, and the compilation time is not necessarily identical. OK, but 70 times slower seems way too much for this. diff --git a/results/classifier/zero-shot/105/boot/2212 b/results/classifier/zero-shot/105/boot/2212 new file mode 100644 index 000000000..12bd3e401 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2212 @@ -0,0 +1,30 @@ +boot: 0.958 +graphic: 0.904 +device: 0.898 +vnc: 0.852 +instruction: 0.804 +socket: 0.800 +semantic: 0.742 +network: 0.656 +KVM: 0.315 +mistranslation: 0.278 +assembly: 0.194 +other: 0.174 + +"pci_hp_register failed with error -16" was found in Guest when launching VM with pci-bridge and "-machine q35" +Description of problem: +Host and guest config file configuration: + CONFIG_HOTPLUG_PCI_CPCI=y + CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m + CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m + CONFIG_HOTPLUG_PCI_SHPC=y +Use this configuration kernel to boot QEMU, with the QEMU parameter "-machine q35 -device pci-bridge,id=bridge0,chassis_nr=1". After the guest boot, dmesg will display "shpchp 0000:00:04.0: pci_hp_register failed with error -16". +Steps to reproduce: +1.Boot QEMU + +2.Check dmesg in VM +Additional information: +Error log: +[root@localhost ~]# dmesg | grep pci_hp_register +[ 0.723893] shpchp 0000:00:04.0: pci_hp_register failed with error -16 +[dmesg.log](/uploads/8ce302f996255544b4327d27ea4ac555/dmesg.log) diff --git a/results/classifier/zero-shot/105/boot/2337 b/results/classifier/zero-shot/105/boot/2337 new file mode 100644 index 000000000..3c3cb76ad --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2337 @@ -0,0 +1,75 @@ +boot: 0.988 +socket: 0.986 +instruction: 0.982 +device: 0.978 +graphic: 0.971 +semantic: 0.968 +vnc: 0.939 +network: 0.936 +assembly: 0.879 +mistranslation: 0.807 +other: 0.651 +KVM: 0.545 + +Os boot issues on 9p filesystem due to unix domain sockets open failure +Description of problem: +Unix filesystem API is broken, unix domain socket special files return an error at open() +Steps to reproduce: +Simple script. Tries to use netcat to get data through a local unix domain socket file +``` +#!/bin/bash + +# Cleanup target dir +[ -d ./target ] && rm -rf target +mkdir target + +# Add configuration updates +mkdir -p ./target/etc/initramfs-tools/ +echo 9p >> ./target/etc/initramfs-tools/modules +echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules + +# Add the test script +cat > ./target/test_init << EOF +#!/bin/bash + +echo "Test for unix domain sockets" + +nc -Ul /socket & +sleep 1 +echo "Sockets work" | nc -UN /socket || echo "Sockets fail" + +echo o > /proc/sysrq-trigger +sleep 999 +EOF +chmod 700 ./target/test_init + +# Create an Ubuntu 23.10 around it +echo "Creating Ubuntu target OS" +debootstrap --variant=minbase\ + --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \ + --exclude=man,bash-completion \ + mantic ./target > /dev/null || exit 1 + +# Run the test in 9p forwarded filesystem +echo "Running OS in qemu" +qemu-system-s390x \ + -m 8192 \ + -smp 4 \ + -nodefaults -nographic -no-reboot -no-user-config \ + -kernel ./target/boot/vmlinuz \ + -initrd ./target/boot/initrd.img \ + -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \ + -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \ + -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \ + -device virtio-serial-ccw -device sclpconsole,chardev=console \ + -chardev stdio,id=console,signal=off +``` +Additional information: +Test output: +``` +Test for unix domain sockets +qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory) +nc: No such device or address +nc: /socket: No such file or directory +Sockets fail +``` diff --git a/results/classifier/zero-shot/105/boot/2343 b/results/classifier/zero-shot/105/boot/2343 new file mode 100644 index 000000000..c0752b32b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2343 @@ -0,0 +1,44 @@ +boot: 0.896 +instruction: 0.883 +device: 0.859 +socket: 0.837 +graphic: 0.827 +semantic: 0.810 +vnc: 0.758 +network: 0.711 +KVM: 0.645 +other: 0.643 +assembly: 0.581 +mistranslation: 0.468 + +pflash write timeout u-boot@qemu-system-aarch64 +Description of problem: +Emulating the write into flash of environment variables within U-boot is not possible anymore. This works natively in Fedora 39 which has the 8.1.3 qemu version. Stopped working after transitioning to Fedora 40 which currently comes with 8.2.2, also doesn't work with Debian 12 which has 7.2.9. + +The write fails with the following message: + +``` +=> saveenv +Saving Environment to Flash... Un-Protected 2 sectors +Erasing Flash... +.. done +Erased 2 sectors +Writing to Flash... pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +Flash buffer write timeout at address 4000000 data ffffffffb64f6361 +Timeout writing to Flash +Protected 2 sectors +Failed (1) +``` +Steps to reproduce: +1. Download or build u-boot for aarch64 qemu. You can extract from u-boot-qemu debian package https://packages.debian.org/unstable/u-boot-qemu . +2. `truncate -s 64m varstore.img` +3. `qemu-system-aarch64 -machine virt -cpu cortex-a35 -nographic -smp 2 -m 1G -bios u-boot.bin -drive if=pflash,format=raw,file=varstore.img,readonly=off,index=1 -d guest_errors,unimp` +Additional information: +After building versions 8.1.3 and 8.1.4 I found both were working fine regartheless the host OS, the issue was introduced in 8.1.5. +After inspecting commits history I drop the following commit [hw/pflash: implement update buffer for block writes (hash:fcc79f2e09550b0461792491965fe202ed2219ae)](https://gitlab.com/qemu-project/qemu/-/commit/fcc79f2e09550b0461792491965fe202ed2219ae) rebuilt and the issue was gone. +I then recheck all non working versions and both versions 8.2.2 and 7.2.9 also have this commit, this explains why it also doesn't work. +I attached a trace running with v8.1.5 and v8.1.5 with drop commit. +[v8.1.5.log](/uploads/04aa0e24e1e16f6bdf29a6e6be587ba1/v8.1.5.log) +[v8.1.5-drop-fcc79f2e.log](/uploads/206fe958ab78c12542fda3764df978da/v8.1.5-drop-fcc79f2e.log) diff --git a/results/classifier/zero-shot/105/boot/2360 b/results/classifier/zero-shot/105/boot/2360 new file mode 100644 index 000000000..d257c81e3 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2360 @@ -0,0 +1,43 @@ +boot: 0.835 +device: 0.721 +socket: 0.534 +vnc: 0.503 +graphic: 0.492 +instruction: 0.491 +network: 0.438 +semantic: 0.347 +other: 0.312 +mistranslation: 0.294 +KVM: 0.175 +assembly: 0.145 + +qemu-system-m68k: double mmu fault +Description of problem: +Shutting down Mac OS 7.5.3 after boot from CD image results in a double MMU fault. +qemu: fatal: DOUBLE MMU FAULT + +D0 = 00000008 A0 = 22152a78 F0 = 7fff ffffffffffffffff ( nan)\ +D1 = 40810000 A1 = 0000c190 F1 = 7fff ffffffffffffffff ( nan)\ +D2 = 00010490 A2 = 000207a0 F2 = 7fff ffffffffffffffff ( nan)\ +D3 = 0002befe A3 = a88879d0 F3 = 7fff ffffffffffffffff ( nan)\ +D4 = db6d0000 A4 = 00041a86 F4 = 7fff ffffffffffffffff ( nan)\ +D5 = 00000000 A5 = 39ec4080 F5 = 7fff ffffffffffffffff ( nan)\ +D6 = 00000001 A6 = 00053178 F6 = 7fff ffffffffffffffff ( nan)\ +D7 = 07b6d258 A7 = 00000004 F7 = 7fff ffffffffffffffff ( nan)\ + +PC = 97f87008 SR = 2210 T:0 I:2 SI X---- \ +FPSR = 00000000 ---- \ +FPCR = 0000 X RN \ +A7(MSP) = 00000000 A7(USP) = 00000000 ->A7(ISP) = 00000004 \ +VBR = 0x00000000 \ +SFC = 0 DFC 5 \ +SSW 00000505 TCR 0000c000 URP 00000000 SRP 07fffa00 \ +DTTR0/1: f900c060/807fc040 ITTR0/1: f900c060/807fc040 \ +MMUSR 00000000, fault at fffffffc \ +Steps to reproduce: +1. Boot from CD image +2. Choose Shut down from the Special menu +Additional information: +Reproducing requires a quadra 800 rom file.\ +A CD image (f.e. SYSTEM_7-5-3-RETAIL.ISO) can be obtained here: https://macintoshgarden.org/apps/macintosh-os-755 \ +Also see here: https://gitlab.com/qemu-project/qemu/-/issues/2249 diff --git a/results/classifier/zero-shot/105/boot/2400 b/results/classifier/zero-shot/105/boot/2400 new file mode 100644 index 000000000..8f846688e --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2400 @@ -0,0 +1,56 @@ +boot: 0.916 +device: 0.871 +instruction: 0.849 +graphic: 0.840 +semantic: 0.832 +mistranslation: 0.829 +socket: 0.657 +network: 0.653 +KVM: 0.555 +other: 0.506 +vnc: 0.436 +assembly: 0.282 + +Qemu fails to boot snapshot image if its header is qcow2 but its payload and backing image extension are luks +Description of problem: +Qemu fails to recognize snapshot image E:\\test_snapshot.qcow2 saying Volume is not in LUKS format + +You need three commands to reproduce: + +`qemu-img create -f luks --object secret,id=sec0,data=123 -o key-secret=sec0 E:\test.luks 1G` + +`qemu-img create --object secret,id=sec0,data=123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 -b E:\test.luks -F luks E:\test_snapshot.qcow2` + +`qemu-system-x86_64 -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0 -object secret,id=sec0,data=123` + +This error is printed: + +`qemu-system-x86_64: -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0: Volume is not in LUKS format` + +But fourth command shows that payload of `E:\test_snapshot.qcow2` has LUKS format: + +`qemu-img info E:\test_snapshot.qcow2` + +\[output\] + +```bash +virtual size: 1 GiB (1073741824 bytes) +disk size: 2.25 MiB +encrypted: yes +cluster_size: 65536 +backing file: E:\test.luks +backing file format: luks +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + encrypt: + ivgen alg: plain64 + detached header: false + hash alg: sha256 + cipher alg: aes-256 + uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + format: luks + cipher mode: xts ... +``` diff --git a/results/classifier/zero-shot/105/boot/2557 b/results/classifier/zero-shot/105/boot/2557 new file mode 100644 index 000000000..de2b644e4 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2557 @@ -0,0 +1,14 @@ +boot: 0.627 +graphic: 0.480 +vnc: 0.293 +mistranslation: 0.262 +instruction: 0.223 +KVM: 0.197 +other: 0.130 +device: 0.122 +semantic: 0.081 +network: 0.037 +assembly: 0.036 +socket: 0.003 + +balloon size startup parameter needed diff --git a/results/classifier/zero-shot/105/boot/2585 b/results/classifier/zero-shot/105/boot/2585 new file mode 100644 index 000000000..69cc8eb75 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2585 @@ -0,0 +1,20 @@ +boot: 0.828 +device: 0.822 +instruction: 0.819 +other: 0.817 +network: 0.725 +mistranslation: 0.718 +socket: 0.614 +graphic: 0.603 +semantic: 0.548 +vnc: 0.504 +assembly: 0.248 +KVM: 0.196 + +qemu-system-arm highmem support broken with TCG +Additional information: +I initially bisected this to commit 39a1fd25287f ("target/arm: Fix handling of LPAE block descriptors"), which introduced an identical bug by masking the wrong address bits due to a type mismatch, but this was in turn fixed by commit c2360eaa0262 ("target/arm: Fix qemu-system-arm handling of LPAE block descriptors for highmem"). The bug resurfaced between qemu-7.1.0 and qemu-7.2.0 after commit f3639a64f602 ("target/arm: Use softmmu tlbs for page table walking"), but may be caused by the preceding 4a35855682ce ("target/arm: Plumb debug into S1Translate") which fails to boot for an unrelated reason. + +I reproduced this on qemu-7.2 as shipped by Debian as well as on qemu-9.1 (built locally). + +Part of this problem appeared to be hidden by the 'highmem=on' argument not having the intended effect during parts of the bisection, which I worked around by overriding the 'pa_bits' variable in machvirt_init(). diff --git a/results/classifier/zero-shot/105/boot/2620 b/results/classifier/zero-shot/105/boot/2620 new file mode 100644 index 000000000..85b5def3e --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2620 @@ -0,0 +1,22 @@ +boot: 0.923 +device: 0.907 +instruction: 0.851 +graphic: 0.795 +vnc: 0.771 +socket: 0.596 +mistranslation: 0.517 +semantic: 0.399 +network: 0.313 +other: 0.104 +KVM: 0.097 +assembly: 0.089 + +Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc +Description of problem: + +Steps to reproduce: +1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO. Works on real Sparcstation 5, 10, or 20 +2.Start OS install +3. +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/2699 b/results/classifier/zero-shot/105/boot/2699 new file mode 100644 index 000000000..c9c37f5b6 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2699 @@ -0,0 +1,31 @@ +boot: 0.978 +vnc: 0.943 +device: 0.925 +instruction: 0.923 +graphic: 0.874 +KVM: 0.757 +socket: 0.748 +network: 0.579 +semantic: 0.451 +mistranslation: 0.372 +other: 0.252 +assembly: 0.212 + +kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9) +Description of problem: +QEMU 9.1.91 monitor - type 'help' for more information +(qemu) kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9) +test.sh: line 14: 105283 Aborted (core dumped) /usr/local/bin/qemu-system-x86_64 -M q35 -m 8G -smp 8 -cpu host -enable-kvm -device VGA,bus=pcie.0,addr=0x2 -drive file=//home/fedora-38.qcow2,media=disk,if=virtio -device virtio-net-pci,mac=00:11:22:33:44:00,netdev=id8cxFGH,id=idaFLYjy,bus=pcie.0,addr=0x7 -netdev tap,id=id8cxFGH,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -vnc :0 -monitor stdio -qmp tcp:0:5555,server,nowait +Steps to reproduce: +1. Boot a guest +2. set_link false nic and set_link true nic + +{"execute": "qmp_capabilities"} +{"return": {}} +{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": false}} +{"return": {}} +{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": true}} + +3. Guest hit qemu core dump +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/2705 b/results/classifier/zero-shot/105/boot/2705 new file mode 100644 index 000000000..5c60bb7ea --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2705 @@ -0,0 +1,30 @@ +boot: 0.931 +device: 0.926 +instruction: 0.881 +vnc: 0.865 +other: 0.853 +semantic: 0.851 +graphic: 0.845 +mistranslation: 0.726 +socket: 0.687 +KVM: 0.519 +assembly: 0.499 +network: 0.411 + +USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X) +Steps to reproduce: +1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above. +2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off` +3. Boot macOS. + +USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable. + + +While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection: + + * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.) + * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2. + * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped. + * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references. + +It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup. diff --git a/results/classifier/zero-shot/105/boot/2739 b/results/classifier/zero-shot/105/boot/2739 new file mode 100644 index 000000000..f598aada1 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2739 @@ -0,0 +1,16 @@ +boot: 0.854 +device: 0.823 +instruction: 0.723 +graphic: 0.709 +other: 0.457 +semantic: 0.372 +mistranslation: 0.359 +socket: 0.333 +vnc: 0.244 +network: 0.137 +assembly: 0.077 +KVM: 0.020 + +Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation +Additional information: +This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups. diff --git a/results/classifier/zero-shot/105/boot/2754 b/results/classifier/zero-shot/105/boot/2754 new file mode 100644 index 000000000..20475cf08 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2754 @@ -0,0 +1,39 @@ +instruction: 0.971 +boot: 0.963 +vnc: 0.958 +network: 0.957 +device: 0.947 +socket: 0.944 +graphic: 0.932 +semantic: 0.736 +assembly: 0.665 +mistranslation: 0.624 +other: 0.609 +KVM: 0.309 + +Virt-manager using QEMU exit in flash and return an I/O Error when attempting to create an loongarch64 QEMU virtual machine +Description of problem: +Cannot complete the installation:'Enter the end of the file when reading data:I/O Error' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper + callback(asyncjob, *args, **kwargs) + ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install + installer.start_install(guest, meter=meter) + ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 726, in start_install + domain = self._create_guest( + guest, meter, initial_xml, final_xml, + doboot, transient) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + File "/usr/lib64/python3.13/site-packages/libvirt.py", line 4545, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: 'Enter the end of the file when reading data:I/O Error' +Steps to reproduce: +1.Click to create loongarch64 virtual machine using virt-manager +2.Configure all arguments of virtual machine +3.Then click start installation,then the error occurs. +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/2782 b/results/classifier/zero-shot/105/boot/2782 new file mode 100644 index 000000000..43f3e558b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2782 @@ -0,0 +1,23 @@ +boot: 0.845 +instruction: 0.826 +device: 0.742 +graphic: 0.630 +semantic: 0.443 +mistranslation: 0.287 +socket: 0.253 +vnc: 0.250 +other: 0.235 +network: 0.156 +assembly: 0.039 +KVM: 0.024 + +WHPX won't enable x86_64v3 level instructions +Description of problem: +x86_64v3 support is not available inside guest +Steps to reproduce: +1. Boot the image +2. Open terminal +3. Run `/lib64/ld-linux-x86-64.so.2 --help` and check which levels are available in the output +4. Or run `/lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep isa` and check `isa_1` value (expected 7 for v3 (3 bits being set)) +Additional information: +Due to this some Linux distribution, like Centos Stream 10, will not be able to boot with WHPX acceleration enabled. diff --git a/results/classifier/zero-shot/105/boot/2788 b/results/classifier/zero-shot/105/boot/2788 new file mode 100644 index 000000000..77aed78b2 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2788 @@ -0,0 +1,26 @@ +boot: 0.939 +device: 0.922 +other: 0.911 +semantic: 0.908 +instruction: 0.824 +graphic: 0.787 +mistranslation: 0.728 +vnc: 0.646 +KVM: 0.603 +socket: 0.549 +network: 0.444 +assembly: 0.369 + +[solved] input mouse and keyboard not working on a distro +Description of problem: +The distro work but does not take input from either keyboard or mouse. +At the boot menu (syslinux) where I have to choose the boot mode the keyboard works, but it stops working when the desktop has booted. +The distro is not blocked I can tell by observing that the clock in the panel keeps running and if I click in the qemu menubar on machine > power down, the distro correctly performs the shutdown procedure. +I have tried other distributions (porteus and tinycore) and both do not have this problem. +I also tried using as -display vnc and sdl but I have the same problem. +I am using a [portable version of qemu](https://gitlab.com/qemu-project/qemu/-/issues/new) but I also tried with the repository version having the same problem. +Steps to reproduce: +Simply boot the virtual machine with the distro, in my case with the portable qemu version: +./QEMU-git-x86_64.AppImage qemu-system-x86_64 -m 512 -enable-kvm -boot d -cdrom ./Nemesis-v25.01-XFCE-x86_64.iso +Additional information: +I am not expert in qemu, if you need some more data I can try to produce it diff --git a/results/classifier/zero-shot/105/boot/2810 b/results/classifier/zero-shot/105/boot/2810 new file mode 100644 index 000000000..6122d346f --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2810 @@ -0,0 +1,14 @@ +boot: 0.801 +device: 0.789 +graphic: 0.407 +instruction: 0.387 +mistranslation: 0.240 +semantic: 0.172 +network: 0.075 +assembly: 0.028 +socket: 0.015 +vnc: 0.013 +other: 0.004 +KVM: 0.004 + +Boot zboot images on riscv64 and loogarch64 diff --git a/results/classifier/zero-shot/105/boot/2863 b/results/classifier/zero-shot/105/boot/2863 new file mode 100644 index 000000000..eeb97c7dc --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2863 @@ -0,0 +1,14 @@ +mistranslation: 0.971 +boot: 0.954 +other: 0.709 +vnc: 0.653 +semantic: 0.573 +device: 0.573 +KVM: 0.477 +network: 0.448 +socket: 0.367 +graphic: 0.343 +assembly: 0.248 +instruction: 0.075 + +Invalid read reason: rejected diff --git a/results/classifier/zero-shot/105/boot/2957 b/results/classifier/zero-shot/105/boot/2957 new file mode 100644 index 000000000..b77a00e66 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2957 @@ -0,0 +1,41 @@ +boot: 0.932 +device: 0.899 +vnc: 0.877 +other: 0.862 +instruction: 0.824 +graphic: 0.778 +socket: 0.704 +semantic: 0.661 +mistranslation: 0.652 +network: 0.623 +KVM: 0.344 +assembly: 0.231 + +qemu-system-riscv32: Some ROM regions are overlapping +Description of problem: +Booting the image produces: +``` +qemu-system-riscv32: Some ROM regions are overlapping +These ROM regions might have been loaded by direct user request or by default. +They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. +Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. + +The following two regions overlap (in the memory address space): + output/images/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000278cc) + mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028) +``` +Steps to reproduce: +1. `make qemu_riscv32_virt_defconfig` +2. `make` +3. `qemu-system-riscv32 \ +-M virt -nographic \ +-bios output/images/fw_jump.elf \ +-kernel output/images/Image \ +-append "root=/dev/vda ro" \ +-drive file=output/images/rootfs.ext2,format=raw,id=hd0 \ +-device virtio-blk-device,drive=hd0 \ +-netdev user,id=net0 -device virtio-net-device,netdev=net0` +Additional information: +Changing `-bios output/images/fw_jump.elf` to `-bios output/images/fw_jump.bin` or `-bios output/images/fw_dynamic.bin` resolves the issue. + +Similar issue observed elsewhere, e.g. here [https://github.com/riscv-software-src/opensbi/issues/372](https://github.com/riscv-software-src/opensbi/issues/372) diff --git a/results/classifier/zero-shot/105/boot/2959 b/results/classifier/zero-shot/105/boot/2959 new file mode 100644 index 000000000..9b69ed1b2 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2959 @@ -0,0 +1,90 @@ +boot: 0.949 +assembly: 0.936 +instruction: 0.890 +graphic: 0.838 +device: 0.835 +mistranslation: 0.735 +semantic: 0.733 +other: 0.690 +vnc: 0.618 +socket: 0.608 +network: 0.474 +KVM: 0.265 + +int 0x10 teletype output cuts final character in custom MBR on QEMU (i386 real mode) +Description of problem: +When using QEMU to test a custom bootloader in 16-bit real mode (i386), the BIOS interrupt `int 0x10` with AH=0x0E (teletype output) fails to display the last character of the printed message. For example, printing `"hello"` only renders `"hell"`. + +This happens only with this exact combination: + +real mode `int 0x10` teletype output + +message ends with `13, 10, 0` + +`QEMU` output cuts off the last character consistently + +All buffer and code logic has been verified to be correct. The same code, when run on Bochs or physical hardware, prints properly. +Steps to reproduce: +1.Assemble the following boot.asm: +```nasm +[org 0x7C00] +[BITS 16] + +_start: + cli + xor ax, ax + mov ds, ax + mov es, ax + mov ss, ax + mov sp, 0x7C00 + + mov si, msg + call print + + hlt + jmp $ + +print: + pusha +.loop: + lodsb + or al, al + jz .done + mov ah, 0x0E + int 0x10 + jmp .loop +.done: + popa + ret + +msg db 'hello', 13, 10, 0 +times 510 - ($ - $$) db 0 +dw 0xAA55 +``` + +2. Compile and run: +```bash +$ nasm -f bin boot.asm -o boot.img +$ qemu-system-i386 -nographic -boot a -drive format=raw,file=boot.img,index=0,if=floppy +``` + +3. Output will be: +```text +Booting from Floppy... +hell +``` +Expected output: +```text +Booting from Floppy... +hello +``` +Additional information: +- Adding padding (extra 13, 10) does not solve the problem. + +- Confirmed that boot.img includes all bytes (xxd dump is correct). + +- Tested on multiple machines with same QEMU version. + +- May relate to VGA character output buffer not flushing after last INT 0x10? + +- This makes QEMU inaccurate for BIOS-level debugging of bootloaders. diff --git a/results/classifier/zero-shot/105/boot/2961 b/results/classifier/zero-shot/105/boot/2961 new file mode 100644 index 000000000..68d0dbc93 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2961 @@ -0,0 +1,44 @@ +boot: 0.674 +semantic: 0.583 +device: 0.547 +instruction: 0.526 +socket: 0.391 +graphic: 0.331 +other: 0.308 +vnc: 0.229 +mistranslation: 0.207 +assembly: 0.192 +network: 0.180 +KVM: 0.088 + +isapc: RTC refactor caused regression in qemu>=8.2 (broke Xenix, maybe others) +Description of problem: +I've been playing a bit with retro UNIXes and wanted to try a Xenix install. + +There are several webpages giving hints for installing Xenix under old versions of QEMU. The good news: most of the workarounds and tweaks they mention seem to be no longer needed. Starting with a Homebrew-supplied qemu 10.0.0 on my laptop I was able to do a basic install _without_ having to tweak the floppy geometry or anything like that. + +The bad news: once the install was complete and I tried to reboot from the harddrive it hangs at the... +``` +Boot +: +``` +...prompt. It doesn't respond to any keystrokes at this point. This prompt is printed by the second-stage loader (called `/boot` on the Xenix filesystem) which is a real-mode 8086 binary. + +To debug this further I moved to a more familiar Linux developer environment and found that the qemu that is stock with Debian 12.10 (7.2.15) did *not* exhibit the same problem! + +I manually bisected through the released versions and found that it definitely broke some time in the 8.2 release cycle: 8.1.5 worked, 8.2.0rc0 did not. I then did a git checkout and started building qemu, using `git bisect` to find the guilty commit. + +Soon I came across 56b1f50e3c101bfe5f52bac73de0e88438de11bd from @shentey -- a change which moved connecting the RTC's ISA interrupt from `pc_basic_device_init()` down into `*_realize()` when a Southbridge is configured. I was able to confirm that before this commit I could boot, but after it I could not. + +I verified using gdb that `pc_basic_device_init()` is being called but the functions that the initialization had moved to were not (or at least weren't called *yet*). So after this change this RTC irq wasn't being wired up, which apparently broke the second-stage Xenix loader. + +I then went back to git tip and found that reverting the 56b1f50e3c1 commit was enough to fix the problem there as well. + +I don't know enough about the qemu internals to judge whether the original change made sense. Therefore, I won't claim that reverting it is the correct approach to fix the bug. However, it did work for me. + +The Southbridge code has been reorged a little since 8.2 but the functional revert is still pretty straightfoward. Here is the diff I used: +[revert-56b1f50e3c1.patch](/uploads/573754b8af3d7ddb97d5f973cb0003db/revert-56b1f50e3c1.patch) +Steps to reproduce: +1. Install Xenix 2.3.4 from https://archive.org/details/sco-xenix-386-and-extras +2. After some enjoyable floppy juggling, be amazed at how smoothly the install went +3. Try to boot from the harddrive afterwards and weep diff --git a/results/classifier/zero-shot/105/boot/2984 b/results/classifier/zero-shot/105/boot/2984 new file mode 100644 index 000000000..87a7b8ccb --- /dev/null +++ b/results/classifier/zero-shot/105/boot/2984 @@ -0,0 +1,66 @@ +boot: 0.357 +mistranslation: 0.341 +device: 0.335 +instruction: 0.333 +vnc: 0.327 +semantic: 0.298 +network: 0.267 +other: 0.255 +graphic: 0.242 +KVM: 0.223 +socket: 0.207 +assembly: 0.182 + +CPU hotplug crashed the guest when using virt-type as qemu! +Description of problem: +Guest is getting crashing and getting into shutoff state when I am trying to hotplug much more cpus than present in the host! This is happening only when i give virt-type as qemu. +Additional information: +Tried reproducing while attaching gdb shows below backtrace which happened after hotplugging 249 CPUs in TCG mode: + +``` +Thread 261 "CPU 249/TCG" received signal SIGABRT, Aborted. +[Switching to Thread 0x7ff97c00ea20 (LWP 51567)] +0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +(gdb) bt +#0 0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#1 0x00007fff84c46ba0 in raise () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#2 0x00007fff84c29354 in abort () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#3 0x00007fff850f1e30 in g_assertion_message () from target:/lib64/libglib-2.0.so.0 +#4 0x00007fff850f1ebc in g_assertion_message_expr () from target:/lib64/libglib-2.0.so.0 +#5 0x00000001376c6f00 in tcg_region_initial_alloc__locked (s=0x7fff7c000f30) at ../tcg/region.c:396 +#6 0x00000001376c6fa8 in tcg_region_initial_alloc (s=0x7fff7c000f30) at ../tcg/region.c:402 +#7 0x00000001376dae08 in tcg_register_thread () at ../tcg/tcg.c:1011 +#8 0x000000013768b7e4 in mttcg_cpu_thread_fn (arg=0x143e884f0) at ../accel/tcg/tcg-accel-ops-mttcg.c:77 +#9 0x0000000137bbb2d0 in qemu_thread_start (args=0x143b4aff0) at ../util/qemu-thread-posix.c:542 +#10 0x00007fff84ca9be0 in start_thread () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +#11 0x00007fff84d4ef3c in __clone3 () from target:/lib64/glibc-hwcaps/power10/libc.so.6 +(gdb) +``` + +which points to below code: + +``` +/* + * Perform a context's first region allocation. + * This function does _not_ increment region.agg_size_full. + */ +static void tcg_region_initial_alloc__locked(TCGContext *s) +{ + bool err = tcg_region_alloc__locked(s); + g_assert(!err); +} +``` + +Here, tcg_region_alloc__locked returns true on failure when max region allocation is reached and therefore intentionally asserted as TCG can't proceed without it. + +``` +static bool tcg_region_alloc__locked(TCGContext *s) +{ + if (region.current == region.n) { + return true; + } + tcg_region_assign(s, region.current); + region.current++; + return false; +} +``` diff --git a/results/classifier/zero-shot/105/boot/436 b/results/classifier/zero-shot/105/boot/436 new file mode 100644 index 000000000..7cdc42a30 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/436 @@ -0,0 +1,14 @@ +boot: 0.979 +device: 0.908 +graphic: 0.599 +mistranslation: 0.287 +semantic: 0.281 +vnc: 0.256 +other: 0.256 +network: 0.218 +instruction: 0.090 +socket: 0.078 +assembly: 0.013 +KVM: 0.004 + +window 8 stuck during boot on Qemu diff --git a/results/classifier/zero-shot/105/boot/475 b/results/classifier/zero-shot/105/boot/475 new file mode 100644 index 000000000..f2882aa0d --- /dev/null +++ b/results/classifier/zero-shot/105/boot/475 @@ -0,0 +1,14 @@ +boot: 0.938 +device: 0.875 +graphic: 0.622 +network: 0.464 +semantic: 0.456 +mistranslation: 0.419 +vnc: 0.386 +socket: 0.264 +other: 0.177 +instruction: 0.169 +assembly: 0.090 +KVM: 0.001 + +4.2 regression: ReactOS crashes on boot diff --git a/results/classifier/zero-shot/105/boot/499 b/results/classifier/zero-shot/105/boot/499 new file mode 100644 index 000000000..e1ba38959 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/499 @@ -0,0 +1,14 @@ +boot: 0.869 +device: 0.824 +network: 0.617 +instruction: 0.435 +graphic: 0.386 +semantic: 0.297 +other: 0.233 +vnc: 0.185 +mistranslation: 0.116 +socket: 0.077 +KVM: 0.024 +assembly: 0.004 + +booting a linux guest with qemu-system-sparc with icount enabled hangs diff --git a/results/classifier/zero-shot/105/boot/51610399 b/results/classifier/zero-shot/105/boot/51610399 new file mode 100644 index 000000000..6bcd4697f --- /dev/null +++ b/results/classifier/zero-shot/105/boot/51610399 @@ -0,0 +1,316 @@ +boot: 0.986 +graphic: 0.986 +assembly: 0.985 +instruction: 0.985 +other: 0.985 +semantic: 0.984 +device: 0.984 +mistranslation: 0.983 +socket: 0.978 +KVM: 0.975 +vnc: 0.974 +network: 0.973 + +[BUG][powerpc] KVM Guest Boot Failure – Hangs at "Booting Linux via __start()” + +Bug Description: +Encountering a boot failure when launching a KVM guest with +qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor +crashes. +Reproduction Steps: +# qemu-system-ppc64 --version +QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f) +Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers +# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine +pseries,accel=kvm \ +-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \ + -device virtio-scsi-pci,id=scsi \ +-drive +file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2 +\ +-device scsi-hd,drive=drive0,bus=scsi.0 \ + -netdev bridge,id=net0,br=virbr0 \ + -device virtio-net-pci,netdev=net0 \ + -serial pty \ + -device virtio-balloon-pci \ + -cpu host +QEMU 9.2.50 monitor - type 'help' for more information +char device redirected to /dev/pts/2 (label serial0) +(qemu) +(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but +unavailable: IRQ_XIVE capability must be present for KVM +Falling back to kernel-irqchip=off +** Qemu Hang + +(In another ssh session) +# screen /dev/pts/2 +Preparing to boot Linux version 6.10.4-200.fc40.ppc64le +(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801 +(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11 +15:20:17 UTC 2024 +Detected machine type: 0000000000000101 +command line: +BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le +root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +Calling ibm,client-architecture-support... done +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000008200000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000800000000 + rmo_top : 0000000030000000 + ram_top : 0000000800000000 +instantiating rtas at 0x000000002fff0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x0000000008210000 -> 0x0000000008210bd0 +Device tree struct 0x0000000008220000 -> 0x0000000008230000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000000440000 ... +** Guest Console Hang + + +Git Bisect: +Performing git bisect points to the following patch: +# git bisect bad +e8291ec16da80566c121c68d9112be458954d90b is the first bad commit +commit e8291ec16da80566c121c68d9112be458954d90b (HEAD) +Author: Nicholas Piggin <npiggin@gmail.com> +Date: Thu Dec 19 13:40:31 2024 +1000 + + target/ppc: fix timebase register reset state +(H)DEC and PURR get reset before icount does, which causes them to +be +skewed and not match the init state. This can cause replay to not +match the recorded trace exactly. For DEC and HDEC this is usually +not +noticable since they tend to get programmed before affecting the + target machine. PURR has been observed to cause replay bugs when + running Linux. + + Fix this by resetting using a time of 0. + + Message-ID: <20241219034035.1826173-2-npiggin@gmail.com> + Signed-off-by: Nicholas Piggin <npiggin@gmail.com> + + hw/ppc/ppc.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + + +Reverting the patch helps boot the guest. +Thanks, +Misbah Anjum N + +Thanks for the report. + +Tricky problem. A secondary CPU is hanging before it is started by the +primary via rtas call. + +That secondary keeps calling kvm_cpu_exec(), which keeps exiting out +early with EXCP_HLT because kvm_arch_process_async_events() returns +true because that cpu has ->halted=1. That just goes around he run +loop because there is an interrupt pending (DEC). + +So it never runs. It also never releases the BQL, and another CPU, +the primary which is actually supposed to be running, is stuck in +spapr_set_all_lpcrs() in run_on_cpu() waiting for the BQL. + +This patch just exposes the bug I think, by causing the interrupt. +although I'm not quite sure why it's okay previously (-ve decrementer +values should be causing a timer exception too). The timer exception +should not be taken as an interrupt by those secondary CPUs, and it +doesn't because it is masked, until set_all_lpcrs sets an LPCR value +that enables powersave wakeup on decrementer interrupt. + +The start_powered_off sate just sets ->halted, which makes it look +like a powersaving state. Logically I think it's not the same thing +as far as spapr goes. I don't know why start_powered_off only sets +->halted, and not ->stop/stopped as well. + +Not sure how best to solve it cleanly. I'll send a revert if I can't +get something working soon. + +Thanks, +Nick + +On Tue Mar 18, 2025 at 7:09 AM AEST, misanjum wrote: +> +Bug Description: +> +Encountering a boot failure when launching a KVM guest with +> +qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor +> +crashes. +> +> +> +Reproduction Steps: +> +# qemu-system-ppc64 --version +> +QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f) +> +Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers +> +> +# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine +> +pseries,accel=kvm \ +> +-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \ +> +-device virtio-scsi-pci,id=scsi \ +> +-drive +> +file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2 +> +> +\ +> +-device scsi-hd,drive=drive0,bus=scsi.0 \ +> +-netdev bridge,id=net0,br=virbr0 \ +> +-device virtio-net-pci,netdev=net0 \ +> +-serial pty \ +> +-device virtio-balloon-pci \ +> +-cpu host +> +QEMU 9.2.50 monitor - type 'help' for more information +> +char device redirected to /dev/pts/2 (label serial0) +> +(qemu) +> +(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but +> +unavailable: IRQ_XIVE capability must be present for KVM +> +Falling back to kernel-irqchip=off +> +** Qemu Hang +> +> +(In another ssh session) +> +# screen /dev/pts/2 +> +Preparing to boot Linux version 6.10.4-200.fc40.ppc64le +> +(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801 +> +(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11 +> +15:20:17 UTC 2024 +> +Detected machine type: 0000000000000101 +> +command line: +> +BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le +> +root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M +> +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +> +Calling ibm,client-architecture-support... done +> +memory layout at init: +> +memory_limit : 0000000000000000 (16 MB aligned) +> +alloc_bottom : 0000000008200000 +> +alloc_top : 0000000030000000 +> +alloc_top_hi : 0000000800000000 +> +rmo_top : 0000000030000000 +> +ram_top : 0000000800000000 +> +instantiating rtas at 0x000000002fff0000... done +> +prom_hold_cpus: skipped +> +copying OF device tree... +> +Building dt strings... +> +Building dt structure... +> +Device tree strings 0x0000000008210000 -> 0x0000000008210bd0 +> +Device tree struct 0x0000000008220000 -> 0x0000000008230000 +> +Quiescing Open Firmware ... +> +Booting Linux via __start() @ 0x0000000000440000 ... +> +** Guest Console Hang +> +> +> +Git Bisect: +> +Performing git bisect points to the following patch: +> +# git bisect bad +> +e8291ec16da80566c121c68d9112be458954d90b is the first bad commit +> +commit e8291ec16da80566c121c68d9112be458954d90b (HEAD) +> +Author: Nicholas Piggin <npiggin@gmail.com> +> +Date: Thu Dec 19 13:40:31 2024 +1000 +> +> +target/ppc: fix timebase register reset state +> +> +(H)DEC and PURR get reset before icount does, which causes them to +> +be +> +skewed and not match the init state. This can cause replay to not +> +match the recorded trace exactly. For DEC and HDEC this is usually +> +not +> +noticable since they tend to get programmed before affecting the +> +target machine. PURR has been observed to cause replay bugs when +> +running Linux. +> +> +Fix this by resetting using a time of 0. +> +> +Message-ID: <20241219034035.1826173-2-npiggin@gmail.com> +> +Signed-off-by: Nicholas Piggin <npiggin@gmail.com> +> +> +hw/ppc/ppc.c | 11 ++++++++--- +> +1 file changed, 8 insertions(+), 3 deletions(-) +> +> +> +Reverting the patch helps boot the guest. +> +Thanks, +> +Misbah Anjum N + diff --git a/results/classifier/zero-shot/105/boot/586175 b/results/classifier/zero-shot/105/boot/586175 new file mode 100644 index 000000000..ee5e85a1a --- /dev/null +++ b/results/classifier/zero-shot/105/boot/586175 @@ -0,0 +1,460 @@ +boot: 0.951 +device: 0.951 +graphic: 0.949 +other: 0.949 +instruction: 0.948 +assembly: 0.946 +vnc: 0.945 +socket: 0.944 +semantic: 0.944 +mistranslation: 0.943 +KVM: 0.939 +network: 0.936 + +Windows XP/2003 doesn't boot + +Hello everyone, + +my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. +If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. + +I'm using libvirt, but even by a simple +> qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on +it won't boot. Qemu hangs at the message "Booting from Hard Disk..." + +I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue. + +There's a fedora rawhide bug about this as well: + +https://bugzilla.redhat.com/show_bug.cgi?id=579348 + +Which points to a qemu-devel posting talking about disk geometry confusion: + +http://article.gmane.org/gmane.comp.emulators.qemu/66135 + +Can someone try to reproduce this without ,boot=on? + +It's possible that extboot is screwing up the disk geometry. + +I don't have any problem using TCG. + +Tested with Windows XP Home Update in 0.12.4 and Windows 2003 Enterprise Server in 0.12.3. + +It's a very strange bug. + +Starting qemu without boot=on results in the same dilemma. + +But: I've used a .vdi image (because qcow2 is terribly slow). +Just now I tried a raw image. Now I can boot neither directly from the image nor with the install cd. Both ways boot finally NTLDR, but now the loader has a problem with the drive. (I don't know how this message is called in the english version, but the german version says: "An error occurred while reading the drive. Restart with Ctrl+Alt+Del.") + +Now I'll try to install Windows Server 2008 R2... + +Can someone post the exact qemu command line that gets generated so we can test without libvirt? + +Do you mean, I should try to install and boot Win2k3 without libvirt? + +If I install Windows through libvirt and boot it with a simple command line like +> qemu-kvm -hda /someimage.img -enable-kvm +it doesn't boot. + +It's in fact this bug, just like Cole meant: +https://bugzilla.redhat.com/show_bug.cgi?id=579348 + +Also interesting, if I use a raw image instead of a vdi image, the workaround (booting the install cd and let it hand over to the installed windows) doesn't work anymore. + +Now I'll set up another machine with gentoo and try all combinations of image file types, Windozes (< NT 6.0) and qemu options and I'll report the results. + +It sounds like this is an existing image that you can't boot from. I can create a new 2k3 VM with upstream qemu and boot it again after install with no issues. So I'm wondering if you can also do this. If so, then something happened to your existing image (maybe some sort of corruption of the boot sector ?). + +I can reproduce with qemu-kvm 0.12.4 like the original reporter. I cannot reproduce with qemu-kvm upstream, qemu stable, or qemu upstream. So boot=on could be the culprit. Libvirt generated command line: + +LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -S -M pc-0.12 -no-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name winxp_test -uuid 634dff56-8c5a-fdbb-b5fc-091bcf78e586 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/winxp_test.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -drive file=/var/lib/libvirt/images/winxp_test.img,if=none,id=drive-ide0-0-0,boot=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/mnt/data/media/win_xp_sp3_32.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device rtl8139,vlan=0,id=net0,mac=52:54:00:ac:e8:ca,bus=pci.0,addr=0x4 -net tap,fd=20,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 + +Markus has a patch internally against an older qemu-kvm release that apparently fixes the issue, however the upstream code is different so it doesn't cleanly apply. Maybe this will give someone a hint for a proper upstream solution: + + hw/pc.c | 4 ++++ + 1 files changed, 4 insertions(+), 0 deletions(-) + +diff --git a/hw/pc.c b/hw/pc.c +index d142282..c60a79a 100644 +--- a/hw/pc.c ++++ b/hw/pc.c +@@ -271,12 +271,16 @@ static void cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size, + */ + for (i = 0; i < 4; i++) { + char id[32]; ++ int cylinders, heads, secs; + + if (hd_table[i]) + continue; + snprintf(id, sizeof(id), "drive-ide0-%d-%d", + i / MAX_IDE_DEVS, i % MAX_IDE_DEVS); + hd_table[i] = drive_get_by_id(id); ++ if (hd_table[i]) { ++ bdrv_guess_geometry(hd_table[i]->bdrv, &cylinders, &heads, &secs); ++ } + } + + /* various important CMOS locations needed by PC/Bochs bios */ + + + +Long time no post, i tried to install Win2k3 through RIS/PXE this time. I still get the same error at boot time: "A disk read error occurred. Press Ctrl + Alt + Del to restart". + +Neither the Win2k3 install source nor the VirtIO drivers are defective. Something's just wrong with QEMU. + +Currently qemu.git is able to compile itself properly, so I'll check it out. Without libvirt (because it can't parse "qemu-kvm-devel" as version string :/ https://bugzilla.redhat.com/show_bug.cgi?id=609741 ) + +Ran into this problem today with fresh Windows 2003 R2 install on a IDE boot drive. Because the CD-ROM boot bypasses this problem the install completes just fine, until I tell it to boot from the hard disk (via libvirt). + +Latest available packages from Debian testing; + +qemu 0.12.4+dfsg-3 +qemu-kvm 0.12.4+dfsg-1 +qemu-system 0.12.4+dfsg-3 +qemu-user 0.12.4+dfsg-3 +qemu-utils 0.12.4+dfsg-3 +seabios 0.5.1-3 + +The only thing I've been able to find so far is an odd character in the SeaBIOS string when booting from the hard disk, which isn't there when booting from the CD-ROM image. + +I agree to #10. Today I installed qemu-kvm-0.12.4-r3 and I still can't boot Windows XP/2003 without booting the install cd at first. + +But now: After I tried to boot the Windows installation I get the same odd char in the screen as described by #10. Plus, I can install Windows without problems, but it doesn't boot AFTER the setup, whether I use IDE or VirtIO as hard disk bus. + +Ergo: Booting from install cd, the setup copies the files on the hard disk, reboot, booting from hard disk, the setup installs Windows, reboot, and then: it hangs. Seems to be an BIOS issue. + +P.S.: Of course I can't boot Windows XP/2003 from a VirtIO drive at all, because the install cd only checks the IDE bus for an existing Windows installation... + +I'm not sure all experience the same as me, but it may be worth having a look at the workaround I found, described here : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579166#17 + +Hth. + +I have to correct myself. + +Booting from Windows XP/2003 after the first reboot of the Windows setup is still impossible (without booting from the install CD at first). + +I tried both the command line used by libvirt and the following one: + +> qemu-kvm -hda thisfile -cdrom thatfile -boot c + +Also, I tested these command lines on qemu-kvm-0.12.4, qemu-kvm-0.12.4-r3 and qemu.git with SeaBIOS 0.5.1, 0.6.0 and seabios.git respectively. Windows always hangs at boot time. (But Windows Server 2008 R2 boots up. I assume Windows 7 and Vista will do fine as well.) + +I have this problem as well. I'm installing using a slightly different situation -- I'm restoring a WinXP/Win2k3 backup that was made with fsarchiver -- but essentially I run across the same issue namely that boot fails when mbr tries to boot the first partition. In my case I use install-mbr from the mbr package but have also tried to install the windows mbr from the boot cd without success. Here are the steps I've taken and the partial fix I've discovered. + +First, let me say that these steps worked perfectly in 9.10. In fact, I can move the raw image from 9.10 to 10.04 and boot it without problem. That was initially how I got these restores to work; I installed on a Karmic laptop and moved the raw image to Lucid. + +Install Notes: + +Install Procedure (for karmic or lucid): + +1. boot system to image to rescuecd and backup xp or win2k3 using fsarchiver: + fsarchiver savefs /some/remote/location/win.fsa /dev/sda1 +2. on kvm host create restore disk: + lvcreate -L10GB -n win vg +3. boot virt with rescuecd + kvm -m 1024 -cdrom rescuecd.iso -hda /dev/vg/win -boot d +3. partition disk (entire disk, one partition, active): + fdisk /dev/sda + commands: o n p 1 [] [] t 7 a 1 w +4. restore archive: + fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 +5. install mbr: + install-mbr /dev/sda +6. halt virt and reboot to image: + kvm -m 1024 -hda /dev/vg/win + +At this point, the image will boot in 9.10. But following the same steps in lucid it will hang after the mbr boots the first partition. + +I tried everything I could think of and all the different steps found on the web including repairing the mbr changing disk types and boot options to no avail. What was odd for me is that the resulting image created on karmic would boot on lucid which indicated to me that once the install was completed successfully whatever kvm was doing didn't matter -- it was just the creation of the mbr or file system in the kvm boot that was at fault. + +My next step at this point was to install hexedit and compare the two resulting images. Specifically, the mbr at the beginning of the disk and the ntfs partition starting at sector 63. On the net there is some talk about changing 0x7E1A to 'FF' -- which is supposed to indicate disk geometry of the ntfs partition. There were three values that were different at this point in the ntfs file region -- 0x8E18, 0x7E1A, and 0x7E1C. The first two did not seem to have any effect. But changing 0x7E1C to the value of '3F' would result in the image booting properly. Evidently this is the part of the NTFS file system that records the starting sector of the partition. This change successfully booted all my test cases restores with a single partition. + +OK, so at this point I backtracked and did just steps 1-4 on both Karmic and Lucid but instead of booting to a rescuecd in the virt I used kpartx to mount the raw file system: + +1. make backup + fsarchiver savefs win.fsa /dev/sda1 +2. create disk + lvcreate -L10GB -n win vg +3. partition + fdisk /dev/vg/win +4. mount to loop, restore, detach + kpartx -av /dev/vg/win + fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 + kpartx -dv /dev/loop0 +5. install mbr + install-mbr /dev/vg/win + +At this point, unfortunately, these steps will not boot on either karmic or lucid -- the boot section of the ntfs partition does not seem to write correctly (0x8E18, 0x7E1A, and 0x7E1C are all '00'). However, if you change 0x7E1C to '3F', these resulting images will boot fine: + +6. after hexedit, boot, success + kvm -m 1024 -hda /dev/vg/win + +Hope this helps track down this issue. My feeling here is that this is not an issue with the mbr but rather the creation of the ntfs file system. And it does seem that the disk geometry presented by the version of kvm in lucid is different enough from karmic to cause the ntfs file system incorrectly write sector 0x7E1C thus causing the resulting image to hang at boot. + + +I am struggling with the same problem with a WIndows 2003 install under virt-manager/virsh The byte at 7e1c was already set to 3F. hexediting the byte at offset 7e1a to FF allowed the system to boot OK. + + + +I'm getting the same error with restoring an Acronis based image to KVM on Scientific Linux 5.4. The image is known good, and I just tested to physical hardware and it boots fine. I hope this can be fixed... + +How are people hex editing the disk? + +I run into the same problem, but the workaround regarding editing the number of heads in the ntfs partition boot sector did it for me. Little Howto: + +Asume: A raw complete harddisc image within a bootable NTFS partition with XP or 2k3 on it + +Incident: when using these image with kvm based qemu, the system wan't boot anymore + +solution: + +1) set up the whole discimage as a loop device +- losetup /dev/loop0 /path/to/my/diskimage.raw + +2) let kpartx create drive mappings for all partitions within the loop device +- kpartx -a /dev/loop0 + +3) you need to know on which partition your NTFS partition resides +- fdisk -l /dev/loop0 + +4) use the right partition mapping with hex-edit (eg. partition 1) +- hexedit /dev/mapper/loop0p1 + +5) look on hex position 0x1a, for the count of heads NTFS asumes +- in hexedit type enter and then 1A + +6) change the value to 0xFF +- in hexedit type FF + +7) save and exit hexedit +- press Ctrl+X to end + +8) remove the partition mappings +- kpartx -d /dev/loop0 + +9) remove loop device +- losetup -d /dev/loop0 + +Hope that helps + +Cheers Andreas + +Great solution Andreas, it worked for a Win2k image which I could only boot previously using an iso from http://www.resoo.org/docs/ntldr/files/ + +However, I have a w7 image that I have never managed to boot, apart from its installation cd image using virt-install + +20Gb w7 image: + +# losetup /dev/loop0 /vm/w7.img; kpartx -a /dev/loop0 +# fdisk -l /dev/loop0 + +Disk /dev/loop0: 21.5 GB, 21474836480 bytes +255 heads, 63 sectors/track, 2610 cylinders +Units = cylinders of 16065 * 512 = 8225280 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disk identifier: 0xaf12c11f + + Device Boot Start End Blocks Id System +/dev/loop0p1 * 1 13 102400 7 HPFS/NTFS +Partition 1 does not end on cylinder boundary. +/dev/loop0p2 13 2611 20867072 7 HPFS/NTFS +Partition 2 does not end on cylinder boundary. + +# hexedit /dev/mapper/loop0p1 +00000000 EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 00 00 00 00 00 F8 00 00 3F 00 10 00 00 08 00 00 .R.NTFS .............?....... +00000020 00 00 00 00 80 00 80 00 FF 1F 03 00 00 00 00 00 55 21 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................U!.............. + + +# hexedit /dev/mapper/loop0p2 +00000000 EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 00 00 00 00 00 F8 00 00 3F 00 10 00 00 28 03 00 .R.NTFS .............?....(.. +00000020 00 00 00 00 80 00 80 00 FF CF 7C 02 00 00 00 00 00 00 0C 00 00 00 00 00 02 00 00 00 00 00 00 00 ..........|..................... + + +# kpartx -d /dev/loop0; losetup -d /dev/loop0 + +I changed location 0x1a to 0xFF on one or other or both partitions and it still will not boot in virt-manager. + +Cheers, +Andy. + +Hi Andy + +When i look at your w7 partition table output, then there seems to be a problem with start/end cylinders. + +Your first partitions last cylinder is 13, but also the start cylinder of your second partition is 13. two partitions should not share the same cylinder/sector! Something seems to be messed up. + +I would create a loop device and then use a deep scan with "testdisk" on that loop device. May be it's possible to correct the wrong entrys in the partition table. + +Cheers Andreas + +I had the same problem. + +I.ve tried with VirtualBox and KVM: Win Xp SP3 hang on the same point (mup.sys when "safe mode")... +Both has the same problem I believe the libvirt maybe the cause. + +So I use "Raw Access" with VirtualBox that solved my problem.... + +00:00:01.385 [/Devices/piix3ide/0/LUN#0/AttachedDriver/Config/] (level 6) +00:00:01.385 Format <string> = "VMDK" (cb=5) +00:00:01.385 Path <string> = "/home/jtloni/.VirtualBox/HardDisks/xp3.vmdk" (cb=45) + +hope will help.. + +Andreas, + +The program that created the disk image seems confused, but it worked for creating a VM for FC11. +Windows install seems to run fine, until wanting to boot from the drive it created. +I don't know what creates the drive image and geometry, but it is broken. + +I think this is what I used to create the VM, but I have messed around with so many configurations and methods, I'm not sure what is what anymore. + +virt-install --connect qemu:///system -n w7 -r 2048 --vcpus=2 \ +--disk path=/vm/w7.img,size=20,sparse=false,format=qcow2 \ +-c /vm/w7cd.iso --vnc --noautoconsole \ +--os-type windows --os-variant win7 --accelerate --network=bridge:br0 --hvm + +How many thousands of people have struggled with this and also got nowhere? +It just looks like the virt-install developers have not tasted their own dogfood! + +LVM is supposed to be easy - just select vm image and boot, but the more +I read about VMs, kvm, qemu, virtualbox, virsh etc, the more confused I get on how they +relate to each other. + +testdisk reports this: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 (wtf ??) + + Partition Start End Size in sectors + 1 * HPFS - NTFS 2048 206847 204800 [System Reserved] + 2 P HPFS - NTFS 206848 41940991 41734144 + + +Select 1: +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 1 * HPFS - NTFS 2048 206847 204800 [System Reserved] + +Boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Backup boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Sectors are identical. + +A valid NTFS Boot sector must be present in order to access +any data; even if the partition is not bootable. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + + +Rebuild BS: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 1 * HPFS - NTFS 2048 206847 204800 [System Reserved] + +filesystem size 204800 204800 +sectors_per_cluster 8 8 +mft_lcn 8533 8533 +mftmirr_lcn 2 2 +clusters_per_mft_record -10 -10 +clusters_per_index_record 1 1 +Extrapolated boot sector and current boot sector are different. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Q + +Select 2: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 2 P HPFS - NTFS 206848 41940991 41734144 + +Boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Backup boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Sectors are identical. + +A valid NTFS Boot sector must be present in order to access +any data; even if the partition is not bootable. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rebuild BS: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 2 P HPFS - NTFS 206848 41940991 41734144 + +filesystem size 41734144 41734144 +sectors_per_cluster 8 8 +mft_lcn 786432 786432 +mftmirr_lcn 2 2 +clusters_per_mft_record -10 -10 +clusters_per_index_record 1 1 +Extrapolated boot sector and current boot sector are different. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It looks a mess. + + + + +This appears to be fixed in 0.13-tobe by this patch: +http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg00152.html +(hence it's "fix released" in debian which now has 0.13 in experimental). + +(and it is also filed agains debian qemu-kvm package, not just qemu -- http://bugs.debian.org/588739 ) + +This is fixed by a backport of the mentioned patchset to stable-0.12 branch, in qemu git tree, see http://git.savannah.gnu.org/gitweb/?p=qemu.git;a=commit;h=6394bd0e05441c363ebb73597c74c951378810e6 + +This bug is annoying. I don't know who patched what but: + +1. I finally was able (with version 0.12.5) to set up a WinXP installation which is able to boot on its own. + +2. But this works only with IDE, if I try to use VirtIO I still can't boot the installation. + +3. I just updated from 0.12.5 to 0.12.5-r1 and again I can't boot the WinXP installation on IDE. + +What the hell are you doing? + +I don't know what's wrong but qemu-kvm works with Windows Vista and above much better than with Windows XP atm. Windows Server 2008 boots on it's own even with the non-signed viostor drivers. + +P.S.: I just read the link posted by Michael. + +I have also to mention that this boot problem not only appears by using the -drive parameter, even the good old -hda got this bug. + +I've also tried to correct some funny offsets in the NTFS header, but all offsets were already set to the right values. And it doesn't boot at all. + +Does anyone else has similar problem? With 0.12.4 I were able to repeat it. With 0.12.5 all winxp and win2003 installations, existing and new, just work with either -drive or -hda or with virtio... + +This bug was fixed in the package qemu-kvm - 0.12.5+noroms-0ubuntu6 + +--------------- +qemu-kvm (0.12.5+noroms-0ubuntu6) maverick; urgency=low + + * debian/fix-CMOS-info-for-drives-defined-with--device.patch: make sure + the CMOS knows about the correct geometry so Windows XP installs + properly. (LP: #586175) + -- Marc Deslauriers <email address hidden> Wed, 15 Sep 2010 19:48:15 -0400 + +In qemu-kvm-0.12.5-r1 Windows XP/2003 is booting fine on IDE, but it hangs directly after the first reboot of the Windows setup if you try to install it on a viostor drive. Windows Vista and higher never had any problems in any version of qemu-kvm with any drive (IDE and viostor)... + +I'm using the binaries of viostor-1.11.1, which I got from this site: http://www.linux-kvm.com/content/latest-windows-virtio-drivers + +virtio disk is entrely different story, unrelated to this issue. + diff --git a/results/classifier/zero-shot/105/boot/587 b/results/classifier/zero-shot/105/boot/587 new file mode 100644 index 000000000..203b10268 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/587 @@ -0,0 +1,14 @@ +boot: 0.915 +device: 0.817 +graphic: 0.674 +vnc: 0.512 +network: 0.418 +semantic: 0.384 +instruction: 0.344 +KVM: 0.330 +other: 0.271 +socket: 0.195 +mistranslation: 0.164 +assembly: 0.004 + +qemu show no error but the virtual machine stuck in boot (GPU passthrough) diff --git a/results/classifier/zero-shot/105/boot/60339453 b/results/classifier/zero-shot/105/boot/60339453 new file mode 100644 index 000000000..df0cfc206 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/60339453 @@ -0,0 +1,69 @@ +boot: 0.782 +other: 0.776 +instruction: 0.713 +device: 0.706 +mistranslation: 0.699 +network: 0.682 +vnc: 0.680 +graphic: 0.671 +KVM: 0.669 +semantic: 0.662 +socket: 0.607 +assembly: 0.486 + +[BUG] scsi: vmw_pvscsi: Boot hangs during scsi under qemu, post commit e662502b3a78 + +Hi, + +Commit e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length"), +and its backports to stable trees, makes kernel hang during boot, when +ran as a VM under qemu with following parameters: + + -drive file=$DISKFILE,if=none,id=sda + -device pvscsi + -device scsi-hd,bus=scsi.0,drive=sda + +Diving deeper, commit e662502b3a78 + + @@ -585,7 +585,13 @@ static void pvscsi_complete_request(struct +pvscsi_adapter *adapter, + case BTSTAT_SUCCESS: + + /* + + * Commands like INQUIRY may transfer less data than + + * requested by the initiator via bufflen. Set residual + + * count to make upper layer aware of the actual amount + + * of data returned. + + */ + + scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen); + +assumes 'e->dataLen' is properly armed with actual num of bytes +transferred; alas qemu's hw/scsi/vmw_pvscsi.c never arms the 'dataLen' +field of the completion descriptor (kept zero). + +As a result, the residual count is set as the *entire* 'scsi_bufflen' of a +good transfer, which makes upper scsi layers repeatedly ignore this +valid transfer. + +Not properly arming 'dataLen' seems as an oversight in qemu, which needs +to be fixed. + +However, since kernels with commit e662502b3a78 (and backports) now fail +to boot under qemu's "-device pvscsi", a suggested workaround is to set +the residual count *only* if 'e->dataLen' is armed, e.g: + + @@ -588,7 +588,8 @@ static void pvscsi_complete_request(struct pvscsi_adapter +*adapter, + * count to make upper layer aware of the actual +amount + * of data returned. + */ + - scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen); + + if (e->dataLen) + + scsi_set_resid(cmd, scsi_bufflen(cmd) - +e->dataLen); + +in order to make kernels boot on old qemu binaries. + +Best, +Shmulik + diff --git a/results/classifier/zero-shot/105/boot/622 b/results/classifier/zero-shot/105/boot/622 new file mode 100644 index 000000000..f8e6483a8 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/622 @@ -0,0 +1,14 @@ +boot: 0.962 +device: 0.940 +other: 0.738 +graphic: 0.566 +network: 0.304 +mistranslation: 0.286 +socket: 0.272 +semantic: 0.244 +vnc: 0.206 +assembly: 0.190 +instruction: 0.146 +KVM: 0.001 + +Mac OS X Cheetah Virtual Machine booting back into Mac OS 9 for no reason diff --git a/results/classifier/zero-shot/105/boot/627982 b/results/classifier/zero-shot/105/boot/627982 new file mode 100644 index 000000000..15dd58cf1 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/627982 @@ -0,0 +1,44 @@ +boot: 0.935 +mistranslation: 0.866 +semantic: 0.724 +device: 0.688 +other: 0.670 +instruction: 0.635 +graphic: 0.579 +network: 0.463 +socket: 0.410 +vnc: 0.408 +assembly: 0.311 +KVM: 0.279 + +linux 2.6.35 hangs with -no-acpi + +Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance the Debian kernel: + +qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 + +There is no output except just "Booting the kernel" + + On 09/01/2010 01:54 PM, Samuel thibault wrote: +> Public bug reported: +> +> Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance +> the Debian kernel: +> +> qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 +> +> There is no output except just "Booting the kernel" +> + +Is this a kernel regression? A qemu regression? What do 'info +registers' and 'x/20i $eip' show? + +You know better than this. + +-- +I have a truly marvellous patch that fixes the bug which this +signature is too narrow to contain. + + +Since kernel 2.6.35 is pretty much outdated nowadays, I think we can close this bug now (Feel free to re-open it if necessary). + diff --git a/results/classifier/zero-shot/105/boot/660060 b/results/classifier/zero-shot/105/boot/660060 new file mode 100644 index 000000000..038c5fdbc --- /dev/null +++ b/results/classifier/zero-shot/105/boot/660060 @@ -0,0 +1,52 @@ +boot: 0.358 +device: 0.263 +socket: 0.217 +other: 0.215 +semantic: 0.213 +mistranslation: 0.170 +vnc: 0.119 +KVM: 0.118 +network: 0.080 +instruction: 0.076 +assembly: 0.067 +graphic: 0.065 + +virtio block read errors + +Context : +- Gentoo Linux distribution on host and guests. +- qemu-kvm-0.12.5-r1 +- 2.6.34-gentoo-r11 host kernel +- 2.6.29-gentoo-r5 guest kernels +- VM boots from and uses a single virtio block device. + +On the old kvm bugtracker there was a discussion about a bug with virtio block devices : +http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2933400&group_id=180599 +I was affected (user gyver in the above discussion) and believed that the problem was fully solved : we had the read error problems on 4 physical hosts . I migrated 3 of the 4 hosts to Gentoo's qemu-kvm-0.12.5-r1 which fixed the problems and allowed us to use virtio block devices instead of emulated PIIX. + +It seems there's a corner case left or another bug with similar consequences. + +I just used a maintenance window on the last physical host (one hard disk switched for repair in a RAID1 array) to migrate the ancient kvm-85 (which worked for us with virtio) to 0.12.5. The read errors in virtio block mode came back instantly. + +We have 3 VMs on this 4th host, 2 are x86, 1 is x86_64. All of them try to boot from a virtio block device and fail to do so with Gentoo's qemu-kvm-0.12.5-r1. They report read errors on /dev/vda and remount the root fs read-only. Reconfiguring them to use emulated PIIX works. There's something interesting about PIIX mode that I'm not sure I've seen before though: there are errors reported by the ATA stack during the boot and the guest kernels switch to PIO after resetting the ide0 interface. More on that later. + +Booting all these VMs works properly with Gentoo's 0.11.1-r1 with virtio block. + +Two details that might help : +1/ +We use DRBD devices for all our virtual disks (on all 4 physical hosts), + +2/ +The "failing" host has different hardware, main differences : +- Core2 Duo architecture instead of Core i7, +- hardware RAID controller: a 3ware 8006-2LP with two SATA disks in RAID-1 mode instead of plain AHCI SATA controllers and software raid 1. +Currently the controller on the "failing" host is rebuilding the array after we switched a failing disk with a brand new one. Although there's no read error on the physical host as far as its kernel is concerned, read performance is suffering : 5MB/s top from the guest point of view with 0.11.1-r1 and virtio block with a dd if=/dev/vda (only one VM running and host idle to avoid interferences other than the RAID rebuild), ... + +This poor read performance might explain the problem we saw in the guest kernel with PIIX emulation on qemu-kvm-0.12.5-r1 (slow reads might be confused with buggy DMA transfers explaining the PIO fallback). We didn't have time to test PIIX emulation after the RAID array was fully synchronized but can do on request. + +Triaging old bug tickets ... can you still recreate this issue with the latest version of QEMU, or can we close this bug nowadays? + +You can close this bug: it has been fixed long ago. + +Thanks for your response! So I'm closing this ticket now... + diff --git a/results/classifier/zero-shot/105/boot/669 b/results/classifier/zero-shot/105/boot/669 new file mode 100644 index 000000000..27b920970 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/669 @@ -0,0 +1,36 @@ +boot: 0.961 +device: 0.925 +graphic: 0.904 +instruction: 0.853 +network: 0.779 +socket: 0.754 +vnc: 0.751 +other: 0.746 +KVM: 0.733 +assembly: 0.729 +mistranslation: 0.627 +semantic: 0.614 + +QEMU Segmentation fault - UnRaid 9.3.2 when passing nvidia k620 GPU inserted into Lenovo x3550 M5 server +Description of problem: +When I pass the following GPU to any Virtual Machine: +IOMMU group 33:[10de:13bb] 81:00.0 VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K620] (rev a2) +I receive this error as soon as i try to boot the VM (any OS). + +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: enabling device (0140 -> 0141) +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258 +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +**Oct 13 03:06:12 MyUnraid-1U kernel: qemu-system-x86[6080]: segfault at a8 ip 00005618620c812a sp 00007ffc610531b0 error 4 in qemu-system-x86_64[561861fbb000+51d000] +Oct 13 03:06:12 MyUnraid-1U kernel: Code: ef ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 e8 4e de ff ff 48 89 df e8 16 e9 ff ff <48> 8b 85 a8 00 00 00 48 85 c0 74 52 8b 93 a0 00 00 00 eb 0e 66 90** +Oct 13 03:06:13 MyUnraid-1U avahi-daemon[3536]: Interface vnet0.IPv6 no longer relevant for mDNS. + +This is one example of W10 VM: +In attach my VM template + +[VM_example.txt](/uploads/428ca5a10ef3338d5d408583fc552b25/VM_example.txt) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/688052 b/results/classifier/zero-shot/105/boot/688052 new file mode 100644 index 000000000..20fb8d3ac --- /dev/null +++ b/results/classifier/zero-shot/105/boot/688052 @@ -0,0 +1,58 @@ +boot: 0.664 +KVM: 0.647 +instruction: 0.627 +device: 0.618 +mistranslation: 0.559 +semantic: 0.532 +network: 0.523 +other: 0.488 +socket: 0.476 +graphic: 0.450 +vnc: 0.387 +assembly: 0.218 + +usb does not work 0.13.0 + +Hi all, I'm using both, debian lenny and debian squeeze. +I installed qemu-kvm (0.12.5) form debian repository but I got problem trying to pass a host usb device to the guest. + +I compiled so the latest stable version (0.13.0) hoping that the problem was fixed. +It didn't help, the error I get is always: + +usb_create: no bus specified, using "usb.0" for "usb-host" + +The command I use is + +qemu-system-x86_64 -hda lenny_amd64_vergine.qcow2 -usbdevice host:002.007 -boot order=c + +On internet I found this, it might help: +http://<email address hidden>/msg38795.html + +The guest is a simple debian lenny with 2.6.26 kernel. + + +I tried also to download the qemu development version but the download get interruped + +git clone http://git.qemu.org/qemu.git +Cloning into qemu... +error: Failed connect to git.qemu.org:80; No such file or directory (curl_result = 7, http_code = 0, sha1 = 62d76a25fe741bdaf1157f0edaf50a7772541db6) +error: Unable to find 62d76a25fe741bdaf1157f0edaf50a7772541db6 under http://git.qemu.org/qemu.git + +I attach more info about the host machine I'm testing on. + + + +Thanks for the report. + +For the second part, you need to clone using the git protocol (git clone git://git.qemu.org/qemu.git +as shown in http://wiki.qemu.org/Download#Latest_Source_Code). The http bit appears broken for now. + +I'm not sure about the first part yet - certainly trying a more recent release would be useful to know. + +the correct syntax is +-usb -device usb-host,vendorid=x,productid=y + +at leats on my app-emulation/qemu-kvm-1.0-r2 + +QEMU 0.13.0 is quite outdated - and I assume that USB passthrough should be working fine with the latest version, so I'm closing this bug ticket now. If you still have problems with the latest version of QEMU, feel free to open it again (or create a new bug ticket instead). + diff --git a/results/classifier/zero-shot/105/boot/692570 b/results/classifier/zero-shot/105/boot/692570 new file mode 100644 index 000000000..df66f64fb --- /dev/null +++ b/results/classifier/zero-shot/105/boot/692570 @@ -0,0 +1,124 @@ +boot: 0.993 +semantic: 0.992 +socket: 0.992 +assembly: 0.990 +device: 0.989 +other: 0.988 +instruction: 0.987 +graphic: 0.986 +mistranslation: 0.985 +vnc: 0.984 +network: 0.968 +KVM: 0.961 + +APIC Latency causing BSOD. + +I have a Proxmox Server with the following specs: + +Version: + +pve-manager: 1.7-10 (pve-manager/1.7/5323) +running kernel: 2.6.32-4-pve +proxmox-ve-2.6.32: 1.7-28 +pve-kernel-2.6.32-4-pve: 2.6.32-28 +qemu-server: 1.1-25 +pve-firmware: 1.0-9 +libpve-storage-perl: 1.0-16 +vncterm: 0.9-2 +vzctl: 3.0.24-1pve4 +vzdump: 1.2-9 +vzprocps: 2.0.11-1dso2 +vzquota: 3.0.11-1 +pve-qemu-kvm: 0.13.0-2 +ksm-control-daemon: 1.0-4 + +VM Configuration: + +name: TS64 +ide2: none,media=cdrom +bootdisk: ide0 +ostype: w2k3 +ide0: data:vm-104-disk-1 +memory: 10240 +sockets: 1 +vlan0: virtio=C6:4C:B3:BB:AD:67 +onboot: 1 +cores: 4 +boot: cad +freeze: 0 +cpuunits: 1000 +acpi: 1 +kvm: 1 + +CPU 2x Xeon Quad Core E5620 2.4GHZ Processors: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz +stepping : 2 +cpu MHz : 2400.323 +cache size : 12288 KB +physical id : 0 +siblings : 8 +core id : 9 +cpu cores : 4 +apicid : 19 +initial apicid : 19 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid +bogomips : 4800.19 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +Performance: + +CPU BOGOMIPS: 76803.21 +REGEX/SECOND: 850066 +HD SIZE: 33.96 GB (/dev/mapper/pve-root) +BUFFERED READS: 333.03 MB/sec +AVERAGE SEEK TIME: 6.10 ms +FSYNCS/SECOND: 2948.85 +DNS EXT: 131.42 ms +DNS INT: 1.28 ms + +I've been successfully running 2 Windows 2003 32-Bit Standard Edition Servers on this server for over a month now. Both were migrations from actual physical servers. However, I've continued to receive random crashes on a Windows 2003 64-bit standard edition running terminal services, which was a fresh install. The server runs fine for hours under a decent load (20 users) and then will crash with a 3B bug check code (System_Service_Exception). I opened a ticket with Microsoft and submitted multiple memory dumps and their engineers suggested the following: + +Dump Analyses Result: +=================== + +What happened is that the OS initiated an APIC /software interrupt. This is handled by the APIC in real hardware. In your Virtual Environment case where you are using Linux based VM – Proxmox, the VM implementation somehow has to make it happen on a virtual machine with the same latency in the virtual APIC. The problem is that there is a latency between when it was initiated and when it happened. + + +Below are the details for understanding the process or concept of APIC interrupts: + +What the Local APIC Is +The Local APIC (LAPIC) is a circuit that is part of the CPU chip. It contains these basic elements: +A mechanism for generating +1. interrupts +2. A mechanism for accepting interrupts +3. A timer + +If you have a multiprocessor system, the APIC's are wired together so they can communicate. So the LAPIC on CPU 0 can communicate with the LAPIC on CPU 1, etc. + + +What the IO APIC Is + +This is a separate chip that is wired to the Local APIC's so it can forward interrupts on to the CPU chips. It is programmed similar to the 8259's but has more flexibility. +It is wired to the same bus as the Local APIC's so it can communicate with them. + +Note:- In our scenario, it’s all Virtualized interrupts or calls because of hypervisor in picture and thus we need to contact the VM application vendor to get a check of this latency issue in APIC interrupt. +------------------------------------------------End of Message---------------------------------- + + + +Their engineers are saying that there is a latency issue with APIC. I'm not exactly sure how this can be corrected. Is this a known issue and is their a solution to this problem. I love Proxmox, but my main reason for using it was to upgrade my terminal server to better hardware, while leveraging it for other virtual machines as well. The forum administrator for Proxmox, suggested I bring this issue to your attention. + +Since there hasn't been an answer to this within the last years, it looks like nobody here knows about Proxmox problems. So let's close this ticket... + diff --git a/results/classifier/zero-shot/105/boot/700276 b/results/classifier/zero-shot/105/boot/700276 new file mode 100644 index 000000000..7e55d136a --- /dev/null +++ b/results/classifier/zero-shot/105/boot/700276 @@ -0,0 +1,49 @@ +boot: 0.556 +graphic: 0.532 +instruction: 0.522 +device: 0.391 +semantic: 0.382 +mistranslation: 0.246 +socket: 0.219 +other: 0.183 +vnc: 0.162 +network: 0.117 +assembly: 0.074 +KVM: 0.026 + +QEMU crashed when GDB request a big size variable information + +Hello, +My host is Fedora 13. My QEMU version is 0.13.0, I use QEMU with GDB to debug Linux kernel(Version 2.6.36.2). + +I use QEMU like this:"qemu -s -S -kernel build/arch/i386/boot/bzImage -hda /dev/zero" +When GDB connected with QEMU, and use gdb command print to look big size variable, the qemu is crash down. for example, when I look a task_struct variable 'init_task'(print init_task ), the qemu produce the below message and exit. + +*** stack smashing detected ***: qemu terminated +======= Backtrace: ========= +/lib/libc.so.6(__fortify_fail+0x4d)[0x78a31d] +/lib/libc.so.6[0x78a2ca] +qemu[0x8059e21] +qemu[0x805a0cf] +qemu[0x80d12a1] +qemu[0x8189cb8] +qemu[0x818c3b0] +/lib/libc.so.6(__libc_start_main+0xe6)[0x6a8cc6] +............... +adbf7000-adbf8000 rw-p 00000000 00:00 0 +adbf8000-ae3f8000 rw-p 00000000 00:00 0 +ae3f8000-ae742000 rw-p 00000000 00:00 0 +ae742000-ae762000 rw-p 00000000 00:00 0 +ae762000-ae764000 rw-p 00000000 00:00 0 +ae764000-ae784000 rw-p 00000000 00:00 0 +ae784000-ae786000 rw-p 00000000 00:00 0 +ae786000-b6786000 rw-p 00000000 00:00 0 +b6786000-b7894000 rw-p 00000000 00:00 0 +b78aa000-b78ab000 rw-p 00000000 00:00 0 +bfe95000-bfeaa000 rw-p 00000000 00:00 0 [stack] +已放弃 (core dumped) + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/708 b/results/classifier/zero-shot/105/boot/708 new file mode 100644 index 000000000..2ff9b3e7f --- /dev/null +++ b/results/classifier/zero-shot/105/boot/708 @@ -0,0 +1,23 @@ +boot: 0.915 +device: 0.839 +graphic: 0.802 +semantic: 0.699 +instruction: 0.572 +vnc: 0.524 +network: 0.458 +other: 0.420 +socket: 0.266 +mistranslation: 0.241 +KVM: 0.161 +assembly: 0.113 + +some TPM related files are missing in sysfs when enable passthrough TPM +Description of problem: +When enable passthrough TPM, there are some files in sysfs are missing, like description, uid file. +under the host linux, we have those file in it: +root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat description +TPM 2.0 Device +root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat uid +1 +Steps to reproduce: +after boot into system, check sysfs, there is no description and uid file in /sys/class/tpm/tpm0/device/firmware_node diff --git a/results/classifier/zero-shot/105/boot/744856 b/results/classifier/zero-shot/105/boot/744856 new file mode 100644 index 000000000..cf3a8265e --- /dev/null +++ b/results/classifier/zero-shot/105/boot/744856 @@ -0,0 +1,28 @@ +boot: 0.893 +KVM: 0.853 +device: 0.826 +graphic: 0.669 +vnc: 0.615 +instruction: 0.603 +mistranslation: 0.547 +semantic: 0.502 +other: 0.404 +network: 0.324 +socket: 0.294 +assembly: 0.202 + +can't boot when using more than 6 disks since qemu-kvm-0.13 + +It's not possible to pass more than 6 disks to a guest since qemu-kvm-0.13 (also tested with 0.14). +If I pass more than 6 disks (as shown below) the machine complains that their is no bootable disk, + +The problem occurs with virtio and without virtio. + +eg. + +/usr/bin/qemu-system-x86_64 --enable-kvm -boot c -drive file=/dev/vgr5/fs-01,if=virtio -drive file=/dev/vgr5/fs-01_srv_workspace,if=virtio -drive file=/dev/vgr5/fs-01_srv_media,if=virtio -drive file=/dev/vgr5/fs-01_srv_company,if=virtio -drive file=/dev/vgr5/fs-01_srv_tmp,if=virtio -drive file=/dev/vgr5/fs-01_srv_download,if=virtio -drive file=/dev/vgr5/fs-01_srv_share,if=virtio -drive file=/dev/vgr5/fs-01_srv_backup,if=virtio -drive file=/dev/vgr5/fs-01_srv_private,if=virtio -drive file=/dev/vgr5/fs-01_srv_build,if=virtio -drive file=/dev/vgr5/fs-01_srv_dev,if=virtio -drive file=/dev/vgr5/fs-01_srv_backup2,if=virtio -drive file=/dev/vgr5/fs-01_srv_ftp,if=virtio -cpu qemu64 -smp 2 -m 4G -append root=/dev/vda -usbdevice tablet -net nic,macaddr=90:e6:ba:9d:00:0,model=e1000 -net tap,ifname=tap0,script=/usr/sbin/qemu-ifup,downscript=/usr/sbin/qemu-ifdown -monitor unix:/var/run/kvm/fs-01/monitor,server,nowait -pidfile /var/run/kvm/fs-01/pid -k de -kernel /srv/kvm/kernel/linux-2.6.38-gentoo -append root=/dev/vda -vnc :0 -name fs-01,process=fs-01 -vga std + +Triaging old bug tickets... QEMU 0.13 and 0.14 are pretty outdated nowadays, can you still reproduce this behavior with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/786 b/results/classifier/zero-shot/105/boot/786 new file mode 100644 index 000000000..349b4dbb1 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/786 @@ -0,0 +1,30 @@ +boot: 0.769 +device: 0.611 +graphic: 0.459 +semantic: 0.326 +network: 0.273 +socket: 0.226 +vnc: 0.221 +instruction: 0.210 +mistranslation: 0.198 +KVM: 0.099 +other: 0.075 +assembly: 0.058 + +assert in qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) +Description of problem: +assert and crash when -acpitable argument is used. Specifically, the argument was "-acpitable file=my_file.bin" which causes the assert and crash. + +The other arguments, I hope, are not critical. In brief, I'm using secure boot (with ovmf_code.secboot.fd), and a sw tpm as well. But hopefully these are not relevant. + +The assert with -acpitable is a regression since it worked with version 6.1.0 + +The actual error message in qemu 6.2.0 is + +qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/797 b/results/classifier/zero-shot/105/boot/797 new file mode 100644 index 000000000..191157c05 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/797 @@ -0,0 +1,22 @@ +boot: 0.943 +graphic: 0.938 +device: 0.884 +instruction: 0.847 +semantic: 0.493 +mistranslation: 0.457 +socket: 0.307 +vnc: 0.252 +other: 0.241 +network: 0.236 +assembly: 0.100 +KVM: 0.015 + +ARM64 hvf fails to boot Windows 11 on 6.2.0 +Description of problem: +On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner"). +Steps to reproduce: +1. `brew install qemu` +2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64 +3. Run command from above. +Additional information: + diff --git a/results/classifier/zero-shot/105/boot/808737 b/results/classifier/zero-shot/105/boot/808737 new file mode 100644 index 000000000..4a8d53f57 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/808737 @@ -0,0 +1,138 @@ +boot: 0.970 +semantic: 0.967 +other: 0.965 +device: 0.961 +socket: 0.958 +assembly: 0.954 +instruction: 0.943 +vnc: 0.939 +graphic: 0.933 +mistranslation: 0.885 +network: 0.881 +KVM: 0.852 + +No option to load additional binary files from command line in QEMU + +There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. + +On Mon, Jul 11, 2011 at 12:41 PM, Anup Patel <email address hidden> wrote: +> Public bug reported: +> +> There is no command line option like -kerner, or -initrd to load an +> arbitrary binary file to a RAM location when launching QEMU. + +It depends on your target (e.g. qemu-system-x86_64) but you can load +your own code as a bzImage or multiboot binary. Both formats are +documented: +http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/x86/boot.txt +http://www.gnu.org/software/grub/manual/multiboot/multiboot.html + +The problem with loading binary code is that you quickly want some +options (is this real mode or protected mode code?, what address to +load at?, are there any modules/initrd extras elsewhere in memory?). +That's basically what multiboot is for. + +Does multiboot do what you need? If not, please be more specific and +describe your target machine and use case. + +Stefan + + +I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my case I have to load hypervisor elf as kernel and there and number of other binaries like flattened device tree binary for hypervisor configuration, guest kernel binary, guest ramdisk, etc. + +Currently, I am developing it for Realview PB-A8 board. For loading the above specified images I have to hack QEMU in hw/arm_boot.c, which is not a good solution. + +In general, I will encounter similar problem for any other architecture too. + +What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU. +(Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if) + +I believe this option can be very handy for OS development and/or firmware development which require multiple binaries. + +Do you think multiboot is suitable for scenario ?? + +--Anup + +Just to add to my use case. + +Currently, to load a test binary called "arm_test.bin.patched" i have hacked QEMU in the following manner: + +diff --git a/hw/arm_boot.c b/hw/arm_boot.c +index bfac982..e4873d4 100644 +--- a/hw/arm_boot.c ++++ b/hw/arm_boot.c +@@ -280,6 +280,13 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) + info->smp_loader_start); + } + info->initrd_size = initrd_size; ++ } else { ++ initrd_size = load_image_targphys("arm_test.bin", 0x100000, 0x1000000); ++ if (initrd_size < 0) { ++ fprintf(stderr, "qemu: could not load arm test code '%s'\n", ++ "arm_test.bin"); ++ exit(1); ++ } + } + info->is_linux = is_linux; + +--Anup + +On Mon, Jul 11, 2011 at 3:14 PM, Anup Patel <email address hidden> wrote: +> I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my +> case I have to load hypervisor elf as kernel and there and number of +> other binaries like flattened device tree binary for hypervisor +> configuration, guest kernel binary, guest ramdisk, etc. +> +> Currently, I am developing it for Realview PB-A8 board. For loading the +> above specified images I have to hack QEMU in hw/arm_boot.c, which is +> not a good solution. +> +> In general, I will encounter similar problem for any other architecture +> too. +> +> What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU. +> (Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if) +> +> I believe this option can be very handy for OS development and/or +> firmware development which require multiple binaries. +> +> Do you think multiboot is suitable for scenario ?? + +Doesn't arm_boot.c already load an arbitrary binary when the image is +neither a kernel ELF or uboot image? I don't know the arm_boot.c +details but skimming the source shows it already does +load_image_targphys(). + +Stefan + + +On 11 July 2011 16:23, Stefan Hajnoczi <email address hidden> wrote: +> Doesn't arm_boot.c already load an arbitrary binary when the image is +> neither a kernel ELF or uboot image? I don't know the arm_boot.c +> details but skimming the source shows it already does +> load_image_targphys(). + +The assumption is that an ELF image is a random raw binary, +and a non-ELF image is an actual kernel. I hate this and +would much rather we had a more generic way of saying "look, +just load this ELF file into physical memory please" (and +that -kernel always treated its argument as an actual kernel, +but that would break backwards compatibility :-() + +-- PMM + + +I understand that we should not change -kernel option for backwards compatibility, that's why I suggest some new option for loading arbitrary binary file (not necessarily ELF file). This option would just mean: "Just blindly load the given file to the given physical address". We can also pass this options multiple times in command line to load different files. + +I don't know if such an option would create problems in any other part of QEMU. Is it possible to have such an option in QEMU ? + +This problem has been bugging me since a year now so, it will be a great help if we can have it. + +Thanks, +--Anup + +I think this problem should be fixed with the new generic loader device: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e481a1f6 + +Released with version 2.8 + diff --git a/results/classifier/zero-shot/105/boot/822408 b/results/classifier/zero-shot/105/boot/822408 new file mode 100644 index 000000000..7f2a9f64b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/822408 @@ -0,0 +1,83 @@ +boot: 0.932 +device: 0.896 +instruction: 0.893 +semantic: 0.850 +other: 0.842 +graphic: 0.834 +mistranslation: 0.808 +network: 0.773 +socket: 0.773 +assembly: 0.711 +vnc: 0.600 +KVM: 0.438 + +Unable to access disk image on mipsel host + +Something is wrong with hard disk images on MIPSel host. + +The host system is mips64el (Loongson cpu, Linux 2.6.39, eglibc 2.13) +Tried Qemu 0.14.1 and 0.15.0-rc2, both compiled with GCC 4.6.0. + +First I was trying to install WinXP (i386-softmmu). +Starting install, create partition, format (either quick and full), seems to complete, boom the error: + +" +Setup was unable to format the partition. The disk may be damaged. Make sure the drive is switched on and properly connected to your computer. If the disk is a SCSI disk, make sure your SCSI devices are properly terminated. Consult your computer manual or SCSI adapter documentation for more information. + +You must select a different partition for Windows XP. +To continue, press ENTER. +" + +This happens with both raw and qcow2 image format. +Tried 10Gb image, tried 16Gb one - no difference. + +On a x86 host, that formatting makes the image (qcow2) grow to about 81 Mb by the time it reaches 100% formatted (quick), but on mipsel it grows to 0.8Mb at the same time and the error appears. + +I tried the same installing of Windows in Qemu on x86 host and copied over the completed image. +In that case it starts loading, but in the middle of the animation there is an error: + +" +STOP: c0000221 Unknown Hard Error +\Systemroot\System32\ntdll.dll +" +(or HAL.dll) + +So, i tried linux-0.2.img.bz2 from the Qemu site, and that fails too. +Thus it's the minimal bug reproduction thing. + +During boot there are multiple errors like: +" +hda: dma_intr: status=0x41 { DriveReady Error } +hda: dma_intr: error=0x04 { DriveStatusError } +hda: Failed opcode was: unknown +" + +It booted and kind of worked, there were weird glitches in every program. +Unusable. + +Summarily, that suggest some error in hard disk emulation or back storage, specific either to MIPSel or non-x86 hosts. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +Well, that's a blast from the past. +Still have the MIPS laptop in question (Lemote Yeeloong 8101b), got it running. + +Built Qemu 0.14.1, the bug is replicated as before. +Built Qemu 2.9.0, the bug is still replicated as before (but qemu is now about 100x slower for some reason). + +So it would appear that whatever the problem is, it never got solved in the last 5 years. + +Raw image (linux-0.2.img.bz2), can't quite test on WinXP any more since it's awfully slow. +Still gives the same kinds of errors: +hda: dma_intr: status=0x41 { DriveReady Error } +hda: dma_intr: error=0x04 { DriveStatusError } +hda: Failed opcode was: unknown + +Built with ./configure --target-list=i386-softmmu + + +Triage-wise, both the laptop, the company and the CPU architecture lost the test of time and are at best collector's items these days, so unless the bug can be replicated on some modern MIPS system it's not worth bothering with. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/830833 b/results/classifier/zero-shot/105/boot/830833 new file mode 100644 index 000000000..ff4b64b3b --- /dev/null +++ b/results/classifier/zero-shot/105/boot/830833 @@ -0,0 +1,127 @@ +assembly: 0.937 +boot: 0.929 +graphic: 0.929 +instruction: 0.926 +semantic: 0.924 +socket: 0.915 +other: 0.904 +device: 0.904 +vnc: 0.863 +network: 0.863 +KVM: 0.794 +mistranslation: 0.788 + +sparc emulators fail to boot + +The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with this error: + +Configuration device id QEMU version 1 machine id 32 +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 + Type 'help' for detailed information +Trying disk... +Unhandled Exception 0x0000002a +PC = 0xffd10bdc NPC = 0xffd10be0 +Stopping execution + +On Mon, Aug 22, 2011 at 3:19 AM, Nigel Horne <email address hidden> wrote: +> Public bug reported: +> +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with +> this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution + +This was a bug in OpenBIOS, fixed in r1047. Maybe I should update the +image for QEMU. + +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/830833 +> +> Title: +> sparc emulators fail to boot +> +> Status in QEMU: +> New +> +> Bug description: +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels +> with this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions +> +> + + +Please do update the binary openbios images for QEMU, it would be a great help!! + +On Wed, Sep 28, 2011 at 8:22 PM, <email address hidden> +<email address hidden> wrote: +> Please do update the binary openbios images for QEMU, it would be a +> great help!! + +Updated, please test. + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/830833 +> +> Title: +> sparc emulators fail to boot +> +> Status in QEMU: +> New +> +> Bug description: +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels +> with this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions +> +> + + +Should be fixed according to the comments from blueswirl ==> setting status to "Fix Released" + diff --git a/results/classifier/zero-shot/105/boot/836 b/results/classifier/zero-shot/105/boot/836 new file mode 100644 index 000000000..6e8eada7a --- /dev/null +++ b/results/classifier/zero-shot/105/boot/836 @@ -0,0 +1,98 @@ +boot: 0.904 +graphic: 0.899 +instruction: 0.898 +device: 0.832 +socket: 0.754 +network: 0.731 +semantic: 0.638 +vnc: 0.624 +assembly: 0.613 +KVM: 0.552 +mistranslation: 0.520 +other: 0.332 + +qemu-riscv32: Syscall LSEEK returns -14 (EFAULT) +Description of problem: +The lseek() system call returns -14 (EFAULT) if the file descriptor is correct, +which it should never do (According to the lseek(2) man page). + +Here is some demonstrative code: +``` +/* System Call numbers, according to https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h */ +.set SYS_OPENAT, 0x38 +.set SYS_CLOSE, 0x39 +.set SYS_LSEEK, 0x3e +.set SYS_READ, 0x3f +.set SYS_WRITE, 0x40 +.set SYS_EXIT, 0x5d + +.set SEEK_CUR, 1 + +/* According to https://elixir.bootlin.com/linux/v5.16.2/C/ident/AT_FDCWD */ +.set AT_FDCWD, (-100) + +.section .text +.global _start +_start: + +/* Open the file with SYS_OPENAT, because SYS_OPEN does not exist on riscv32 for some reason. + Effectively: + s0 = open(argv[1], 0, 0644); */ +li a7, SYS_OPENAT +li a0, AT_FDCWD +lw a1, 8(sp) +li a2, 0 +li a3, 0644 +ecall + +/* Error checking. This succeeds. */ +blt a0, zero, unrelated_error + +mv s0, a0 + +/* The broken lseek() call. + Same also happens no matter the position in the file. + Effectively: + lseek(s0, 0, SEEK_CUR); */ +li a7, SYS_LSEEK +mv a0, s0 +li a1, 0 +li a2, SEEK_CUR +ecall + +/* XXX: lseek() returns -14 */ +blt a0, zero, lseek_error + +/* Close the file. */ +li a7, SYS_CLOSE +mv a0, s0 +ecall + +/* Error checking. This also succeeds. */ +blt a0, zero, unrelated_error + +/* exit(0); */ +li a7, SYS_EXIT +li a0, 0 +ecall + +/* exit(-return_value); */ +lseek_error: +li a7, SYS_EXIT +sub a0, zero, a0 +ecall + +unrelated_error: +li a7, SYS_EXIT +li a0, 128 +ecall +``` +Steps to reproduce: +1. riscv32-unknown-linux-gnu-as test.s -o test.o +2. riscv32-unknown-linux-gnu-ld test.o +3. qemu-riscv32 ./a.out test +4. echo $? # This returns 14 +Additional information: +Complete test setup: + +[test.tgz](/uploads/af68c9a5236628a9c6f31f2ce94e2f04/test.tgz) diff --git a/results/classifier/zero-shot/105/boot/87 b/results/classifier/zero-shot/105/boot/87 new file mode 100644 index 000000000..07f07ff56 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/87 @@ -0,0 +1,14 @@ +boot: 0.960 +device: 0.925 +mistranslation: 0.811 +other: 0.770 +semantic: 0.599 +graphic: 0.539 +KVM: 0.505 +network: 0.312 +vnc: 0.308 +instruction: 0.223 +socket: 0.184 +assembly: 0.118 + +doesn't clear screen on boot diff --git a/results/classifier/zero-shot/105/boot/886 b/results/classifier/zero-shot/105/boot/886 new file mode 100644 index 000000000..7bedb2513 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/886 @@ -0,0 +1,29 @@ +boot: 0.951 +device: 0.935 +graphic: 0.880 +instruction: 0.839 +vnc: 0.662 +semantic: 0.584 +socket: 0.581 +mistranslation: 0.453 +network: 0.444 +other: 0.148 +KVM: 0.095 +assembly: 0.040 + +OpenIndiana panics when using -accel hvf +Description of problem: +OpenIndiana panics on boot. + +``` +Loading unix... +Loading /platform/i86pc/amd64/boot_archive... +Loading /platform/i86pc/amd64/boot_archive.hash... +Booting... +OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit + +panic[cpu0]/thread=fffffffffbc49060: +``` +Steps to reproduce: +1. Run given command +2. Wait diff --git a/results/classifier/zero-shot/105/boot/888016 b/results/classifier/zero-shot/105/boot/888016 new file mode 100644 index 000000000..214a7af67 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/888016 @@ -0,0 +1,38 @@ +boot: 0.769 +instruction: 0.657 +graphic: 0.649 +device: 0.637 +mistranslation: 0.316 +other: 0.281 +semantic: 0.267 +vnc: 0.250 +network: 0.250 +socket: 0.147 +KVM: 0.109 +assembly: 0.053 + +RHEL 6.1 guest fails to boot with vhost + +Tried to boot 6.1 guest on hs22 blade with/without vhost enabled. + +With vhost enabled, guest aborted with core dump. + +installed guest with autotest. +Command : +/usr/local/bin/qemu-system-x86_64 -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-20111108-193209-fc6O',server,nowait -serial unix:'/tmp/serial-20111108-193209-fc6O',server,nowait -drive file='/home/pradeep/autotest/client/tests/kvm/images/rhel6.1-64.qed',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=idQhUaOc,mac='9a:b7:ea:c9:0e:0d',id='idVR6XQz' -netdev tap,id=idQhUaOc,vhost=on,script=/home/pradeep/qemu-ifup-latest -m 1024 -smp 8 -vnc :0 -monitor stdio +QEMU 0.15.91 monitor - type 'help' for more information +(qemu) Aborted (core dumped) + + +host: + +2.6.32-214 +m/c: hs22 +vhost modules are loaded. + +i hits this issue on host: 3.1.0+ also + +Can you still reproduce this problem with the latest version of QEMU from http://qemu-project.org/Download and recent host and guest Linux kernels? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/105/boot/899961 b/results/classifier/zero-shot/105/boot/899961 new file mode 100644 index 000000000..91299a8a0 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/899961 @@ -0,0 +1,170 @@ +boot: 0.893 +other: 0.888 +device: 0.849 +KVM: 0.847 +instruction: 0.844 +socket: 0.832 +vnc: 0.831 +semantic: 0.822 +graphic: 0.818 +mistranslation: 0.812 +assembly: 0.810 +network: 0.783 + +qemu/kvm locks up when run 32bit userspace with 64bit kernel + +Applies to both qemu and qemu-kvm 1.0, but only when kernel is 64bit and userspace is 32bit, on x86. Did not happen with previous released versions, such as 0.15. Not all guests triggers this issue - so far, only (32bit) windows 7 guest shows it, but does that quite reliable: first boot of an old guest with new qemu (or qemu-kvm), windows finds a new CPU and suggests rebooting - hit "Reboot" and in a few seconds it will be locked up (including the monitor), with 100% CPU usage. Killable with -9. + +Actually after trying to do lots of experiments and finally a git bisection, it turned out that the issue only affects qemu-kvm, not upstream qemu. Bisection between qemu-kvm 0.15.0 and 1.0 lead to this commit: + +commit 145e11e840500e04a4d0a624918bb17596be19e9 +Merge: ce967f6 b195043 +Author: Avi Kivity <email address hidden> +Date: Wed Aug 10 12:06:58 2011 +0300 + + Merge commit 'b195043003d90ea4027ea01cc7a6c974ac915108' into upstream-merge + + * commit 'b195043003d90ea4027ea01cc7a6c974ac915108': (130 commits) + ... + +After which I'm stuck... ;) + +And some more info. Debugging with gdb shows this: + +(gdb) info threads + Id Target Id Frame + 2 Thread 0xf6d4eb70 (LWP 28697) "qemu-system-x86" 0xf7711425 in __kernel_vsyscall () +* 1 Thread 0xf6f50700 (LWP 28694) "qemu-system-x86" 0xf7711425 in __kernel_vsyscall () +(gdb) bt +#0 0xf7711425 in __kernel_vsyscall () +#1 0xf76d620a in __pthread_cond_wait (cond=0x840fa60, mutex=0x89e82f0) + at pthread_cond_wait.c:153 +#2 0x080e8bb5 in qemu_cond_wait (cond=0x840fa60, mutex=0x89e82f0) + at /build/kvm/git/qemu-thread-posix.c:113 +#3 0x08050c2e in run_on_cpu (env=0x9466460, + func=0x8083ad0 <do_kvm_cpu_synchronize_state>, data=0x9466460) + at /build/kvm/git/cpus.c:715 +#4 0x08083b63 in kvm_cpu_synchronize_state (env=0x9466460) + at /build/kvm/git/kvm-all.c:927 +#5 0x0804faaa in cpu_synchronize_state (env=0x9466460) + at /build/kvm/git/kvm.h:173 +#6 0x0804fc3a in cpu_synchronize_all_states () at /build/kvm/git/cpus.c:94 +#7 0x080647ec in main_loop () at /build/kvm/git/vl.c:1421 +#8 0x0806974d in main (argc=17, argv=0xff996e04, envp=0xff996e4c) + at /build/kvm/git/vl.c:3395 +(gdb) frame 2 +#2 0x080e8bb5 in qemu_cond_wait (cond=0x840fa60, mutex=0x89e82f0) + at /build/kvm/git/qemu-thread-posix.c:113 +113 err = pthread_cond_wait(&cond->cond, &mutex->lock); +(gdb) +(gdb) thread 2 +[Switching to thread 2 (Thread 0xf6d4eb70 (LWP 28697))] +#0 0xf7711425 in __kernel_vsyscall () +(gdb) bt +#0 0xf7711425 in __kernel_vsyscall () +#1 0xf727ac89 in ioctl () at ../sysdeps/unix/syscall-template.S:82 +#2 0x08084004 in kvm_vcpu_ioctl (env=0x9466460, type=44672) + at /build/kvm/git/kvm-all.c:1090 +#3 0x08083cd8 in kvm_cpu_exec (env=0x9466460) at /build/kvm/git/kvm-all.c:976 +#4 0x08050f44 in qemu_kvm_cpu_thread_fn (arg=0x9466460) + at /build/kvm/git/cpus.c:806 +#5 0xf76d1c39 in start_thread (arg=0xf6d4eb70) at pthread_create.c:304 +#6 0xf728296e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 +Backtrace stopped: Not enough registers or memory available to unwind further + +which is not entirely interesting, but: + +when exiting gdb (I attached it to a running process), the whole thing unfreezes and continue its work as usual, if no lockup ever occured -- ie, it is enough to attach gdb to a locked up process and quit gdb - enough to unfreeze it. Also, when running under gdb, the lockup does not occur - I can reboot the guest at will any times, it all goes fine. Once gdb is detached, reboot immediately results in a lockup again - which - again - can be "cured" by attaching and detaching gdb to the process. + +And one more correction for the original report. When locked up, it does NOT use 100% CPU - CPU is 100% _idle_. + +On 12/04/2011 07:45 PM, Michael Tokarev wrote: +> Actually after trying to do lots of experiments and finally a git +> bisection, it turned out that the issue only affects qemu-kvm, not +> upstream qemu. Bisection between qemu-kvm 0.15.0 and 1.0 lead to this +> commit: +> +> commit 145e11e840500e04a4d0a624918bb17596be19e9 +> Merge: ce967f6 b195043 +> Author: Avi Kivity <email address hidden> +> Date: Wed Aug 10 12:06:58 2011 +0300 +> +> Merge commit 'b195043003d90ea4027ea01cc7a6c974ac915108' into upstream-merge +> +> * commit 'b195043003d90ea4027ea01cc7a6c974ac915108': (130 commits) +> ... +> +> After which I'm stuck... ;) +> + +32-on-64 doesn't build on Fedora due to glib2-devel.i686 conflicting +with its x86_64 cousin, so I can't reproduce this. Can you try +bisecting this further? + +$ git tag M b195043003d90ea4027ea01cc7a6c974ac915108 +$ git bisect start M M^ +... +$ git merge --no-commit M^ +[build and test] +$ git merge --abort (or git checkout -f) +$ git bisect [good|bad] + +if it happens that M^2 was the bad commit, you'll get a merge conflict. +In that case do + +$ git merge --abort +$ git merge M + +(you'll just be testing M again, but it's good to verify) + +-- +error compiling committee.c: too many arguments to function + + + +I tried bisecting it today, again. I think you did mean 145e11e840500e04a4d0a624918bb17596be19e9 as the "M" point (the large merge), not b195043003d90ea4027ea01cc7a6c974ac915108 (which is the first commit in that merge) ;) Actually I did the same already, just didn't post to the bugreport. But anyway. + +The first bad commit inside the merge which shows the bad behavour is: + +commit 68d100e905453ebbeea8e915f4f18a2bd4339fe8 +Author: Kevin Wolf <email address hidden> +Date: Thu Jun 30 17:42:09 2011 +0200 + + qcow2: Use coroutines + +Note: the issue happens only with qcow2 being in use so far, directly or indirectly with -snapshot. + +Also note that it only happens within kvm tree, ie: + + git checkout 68d100e905453ebbeea8e915f4f18a2bd4339fe8 + git merge --no-commit 145e11e840500e04a4d0a624918bb17596be19e9^ # the pre-merge point + +I tried to debug it further but without much success. + +I'm attaching an strace the above source (with a few debug fprintf(stderr)s added into qcow2 source around lock/unlock calls) running winXP guest from point where I hit "Reboot" button and up to the point where it stalls. Search for "qcow2: mutex_unlock" from the _end_ of the file. + +What I also observed is -- it looks like it merely loses an interrupt somewere, it is enough to Ctrl+Z/fg it or to attach/detach strace to the process for it to "unstuck" and continue executing. Attaching gdb also makes it unstuck as demonstrated initially. + +This qcow2 commit may actually be innocent: it just started using coroutines, and that's where the bug/problem might be, say, 64bit kernel gets confused by the process switching stack for example? I dunno. + +Note again that switching to alternative coroutine implementations makes the issue go away. Ie, it only happens with mkcontext&Co coroutine implementation, and the commit which git bisect found to be "guilty" is the one which makes usage of coroutines. + + +After some more digging I found out that qemu also has this very issue, but it happens a bit differently. In particular, this very same winXP test guest freezes in upstream qemu with -enable-kvm on _shutdown_, not on restart. In qemu-kvm it happens on restart but not on shutdown. + +And bisecting plain qemu leads to this commit: + +commit 12d4536f7d911b6d87a766ad7300482ea663cea2 +Author: Anthony Liguori <email address hidden> +Date: Mon Aug 22 08:24:58 2011 -0500 + + main: force enabling of I/O thread + +As far as I remember, qemu-kvm always had iothread enabled, that's why the bug initially was only reproducible on qemu-kvm. + +Forgot to mention: tcg appears to be unaffected - so far anyway. + +The bug in Debian has been marked as "Fix released", so I assume this has been fixed in upstream QEMU, too? Or is there still anything left to do here? + +Since the debian bug has been marked as fixed and there wasn't any response to the question in my last comment, I assume this has been fixed in upstream QEMU, too. So closing this ticket accordingly... + diff --git a/results/classifier/zero-shot/105/boot/907 b/results/classifier/zero-shot/105/boot/907 new file mode 100644 index 000000000..d8a245073 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/907 @@ -0,0 +1,20 @@ +boot: 0.881 +instruction: 0.829 +graphic: 0.767 +device: 0.736 +other: 0.674 +mistranslation: 0.663 +network: 0.556 +socket: 0.419 +semantic: 0.407 +vnc: 0.207 +KVM: 0.136 +assembly: 0.103 + +qemu-system-x86_64 -blockdev fails with "CURL: Error opening file" when supplied url of ISO file +Steps to reproduce: +1. Run: qemu-system-x86_64 -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true + +The command returns error: qemu-system-x86_64: -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true,discard=unmap: CURL: Error opening file: +Additional information: +This bug is not present in qemu 6.1.0, it surfaced with an update to 6.2.0 diff --git a/results/classifier/zero-shot/105/boot/973 b/results/classifier/zero-shot/105/boot/973 new file mode 100644 index 000000000..8e64f0699 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/973 @@ -0,0 +1,32 @@ +boot: 0.822 +device: 0.798 +instruction: 0.679 +graphic: 0.675 +semantic: 0.642 +network: 0.567 +vnc: 0.419 +other: 0.286 +socket: 0.240 +mistranslation: 0.202 +KVM: 0.128 +assembly: 0.060 + +qemu 6.2 memory leak when failed to boot and infinitely reboot +Description of problem: +qemu allocates tons of memory (very likely memory leak) in certain (rare) cases. + +When I misconfigured qemu so that I have run a bigger linux kernel within insufficient memory (for example 8M bzImage while 16M ram and no hdd), the kernel will obviously fail to boot. In this case qemu will reboot (likely the linux kernel reboots). However reboot does not solve the problem, causing qemu to repeatedly reboot. + +Memory usage of qemu raises sharply in the progress. +Steps to reproduce: +1. Get any linux kernel (tested with 5.15.33) +2. Run the kernel on qemu, with memory smaller than necessary +Additional information: +A reproducing dockerfile: +``` +FROM alpine:3.15 + +RUN apk add qemu-system-x86_64 linux-virt + +CMD ["/usr/bin/qemu-system-x86_64", "-kernel", "/boot/vmlinuz-virt", "-nographic", "-net", "none", "-m", "16M"] +``` diff --git a/results/classifier/zero-shot/105/boot/985 b/results/classifier/zero-shot/105/boot/985 new file mode 100644 index 000000000..196bbdfb0 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/985 @@ -0,0 +1,72 @@ +boot: 0.719 +network: 0.700 +other: 0.600 +device: 0.594 +graphic: 0.573 +instruction: 0.538 +semantic: 0.404 +mistranslation: 0.331 +assembly: 0.316 +socket: 0.199 +vnc: 0.083 +KVM: 0.058 + +pkg_add is working very slow on NetBSD +Description of problem: +pkg_add is working very slow, it installs one package in ~30 minutes although network speed is normal. +Steps to reproduce: +1. `wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/images/NetBSD-9.2-amd64.iso` +2. `qemu-img create -f qcow2 disk.qcow2 15G` +3. Install +``` +qemu-system-x86_64 -m 2048 -enable-kvm \ + -drive if=virtio,file=disk.qcow2,format=qcow2 \ + -netdev user,id=mynet0,hostfwd=tcp::7722-:22 \ + -device e1000,netdev=mynet0 \ + -cdrom NetBSD-9.2-amd64.iso +``` + # Installation steps + - 1) Boot Normally + - a) Installation messages in English + - a) unchanged + - a) Install NetBSD to hard disk + - b) Yes + - a) 15G + - a) GPT + - a) This is the correct geometry + - b) Use default partition sizes + - x) Partition sizes are ok + - b) Yes + - a) Use BIOS console + - b) Installation without X11 + - a) CD-ROM / DVD / install image media + - Hit enter to continue + - a) configure network (Select defaults here, perform autoconf) + - x) Finished configuring + - Hit enter to continue + - x) Exit Install System + - Close QEMU +4. Run +``` + qemu-system-x86_64 -m 2048 \ + -drive if=virtio,file=disk.qcow2,format=qcow2 \ + -enable-kvm \ + -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:7722-:22 \ + -device e1000,netdev=mynet0 +``` +5. Login as root +6. In NetBSD +``` +export PKG_PATH="http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r)/All/" && \ +pkg_add pkgin + +``` +You should see that each of the package's installation takes ~30 minutes. +Additional information: +NetBSD 9.2 is also tested in Debian 11 with 'QEMU 6.2.0' and encountered same slowness. + +NetBSD 7.1 and 8.1 are tested on openSUSE Tumbleweed and encountered same slowness. + +OpenBSD's pkg_add is working correctly. + +I am not sure if it will help but Virtualbox(at least 6.1) is working correctly. diff --git a/results/classifier/zero-shot/105/boot/997 b/results/classifier/zero-shot/105/boot/997 new file mode 100644 index 000000000..a6e80f9a3 --- /dev/null +++ b/results/classifier/zero-shot/105/boot/997 @@ -0,0 +1,30 @@ +boot: 0.873 +device: 0.846 +instruction: 0.791 +graphic: 0.705 +semantic: 0.678 +vnc: 0.662 +network: 0.568 +other: 0.449 +mistranslation: 0.425 +socket: 0.372 +assembly: 0.304 +KVM: 0.204 + +Iothread is stuck at 100% CPU usage with virtio-scsi on QEMU 7.0.0 +Description of problem: +Starting with QEMU 7.0.0, the iothread associated attached to a virtio-scsi controller is stuck at 100% CPU usage. Bisected to: https://gitlab.com/qemu-project/qemu/-/commit/826cc32423db2a99d184dbf4f507c737d7e7a4ae + +- Works as expected without the iothread +- No issue with virtio-blk + iothread +- Same behavior regardless of io=threads/native/io_uring +- Same behavior with default vs increased queue count +- The issue is triggered when the guest OS initializes the virtio driver +Steps to reproduce: +1. Add virtio-scsi controller with iothread +2. Boot VM +3. Check per-thread CPU usage such as in htop +Additional information: +[fedora.log](/uploads/776fbf8e5b823d0ab326946684ef9022/fedora.log) + +[fedora.xml](/uploads/54879e5adfb227ddef79d382e86fc608/fedora.xml) |