diff options
Diffstat (limited to 'results/classifier/deepseek-2/output/device')
881 files changed, 18632 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2/output/device/1004050 b/results/classifier/deepseek-2/output/device/1004050 new file mode 100644 index 000000000..a0e0bb8c7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1004050 @@ -0,0 +1,17 @@ + +qemu-system-ppc64 by default has non-working keyboard + +Compile qemu from git and do: + + ./ppc64-softmmu/qemu-system-ppc64 + +(ie. no parameters). It boots to an OpenBIOS prompt. However the keyboard doesn't work. After ~10 keypresses, qemu just says: + +usb-kbd: warning: key event queue full +usb-kbd: warning: key event queue full +usb-kbd: warning: key event queue full +usb-kbd: warning: key event queue full + +There is no indication inside the guest that OpenBIOS is seeing keyboard events. + +Also there's no indication of what type of keyboard devices are available, nor what we should use. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1013241 b/results/classifier/deepseek-2/output/device/1013241 new file mode 100644 index 000000000..6756f0cc5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1013241 @@ -0,0 +1,27 @@ + +qemu-system-ppc64 hanging occasionally in disk writes + +I found last week that qemu-system-ppc64 (from git) hangs occasionally +under load, and I have a reproducer for it now. Unfortunately the +reproducer really takes a long time to run -- usually I can get a hang +in under 12 hours. + +Here is the reproducer case: + + https://lists.fedoraproject.org/pipermail/ppc/2012-June/001698.html + +Notes: + +(1) Verified by one other person (other than me). Happens on both + ppc64 and x86-64 host. + +(2) Happens with both Fedora guest kernel 3.3.4-5.fc17.ppc64 and kernel + 3.5.0 that I compiled myself. The test case above contains 3.3.4-5. + +(3) Seems to be a problem in qemu, not the guest. The reason I think + this is because I tried to capture a backtrace of the hang using + remote gdb, but gdb just hung when trying to connect to qemu + (gdb connects fine before the bug happens). + +(4) Judging by guest messages, appears to be happening when writing + to the disk. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1013691 b/results/classifier/deepseek-2/output/device/1013691 new file mode 100644 index 000000000..6f4668f91 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1013691 @@ -0,0 +1,15 @@ + +ppc64 + virtio-scsi: only first scsi disk shows up in the guest + +When adding two virtio-scsi targets to a single guest, only the first +disk is seen inside the guest. For some unknown reason the guest +doesn't enumerate the second disk. + +For full qemu-system-ppc64 command line and 'dmesg' output, see: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02430.html + +I have also tried this with Linus's git tree (3.5.0-rc2+ at time of writing), +same thing. + +In both cases I'm using qemu from git. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1014 b/results/classifier/deepseek-2/output/device/1014 new file mode 100644 index 000000000..04c0b9ae0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1014 @@ -0,0 +1,4 @@ + +Make -chardev, -serial and others accept stderr like they accept stdio +Additional information: +It's not clear what should happen when the guest tries to read from (instead of write to) the character device. On the other hand, I don't think the specific behavior matters very much. diff --git a/results/classifier/deepseek-2/output/device/1014099 b/results/classifier/deepseek-2/output/device/1014099 new file mode 100644 index 000000000..98979f070 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1014099 @@ -0,0 +1,8 @@ + +hw/esp.c does not properly deal with TEST_UNIT_READY in NetBSD/sparc + +The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN but dma disabled sometimes (early during bus enumeration). This is fine, as the command will not produce nor consume any data, and works on real hardware. + +However, the qemu emulation does not allow this (for reasons I don't understand). + +The change below fixes the problem. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1014681 b/results/classifier/deepseek-2/output/device/1014681 new file mode 100644 index 000000000..7ac3964f5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1014681 @@ -0,0 +1,35 @@ + +BSOD with newer host kernels (x64) and W2k8S guest (x64) + +Hallo, I attempted to move virtual machines from one host to another but got stuck with Windows-BSODs on the target host. The host-side console message is "virtio_ioport_write: unexpected address 0x13 value 0x1". Eventually there are overlaps to bug #990364, but I'm not sure. + +Host machine: 2x Opteron 4238 a 6 cores, 32GB RAM, Linux x86_64 +Guest machine(s): Windows 2008 Server R2 x64 + +I tried different combinations of component versions, but only kernel 2.6.34 could run the guests (but has other difficulties): + +host kernel Qemu-KVM paravirtualization guest paravirt driver +============================================= +2.6.34 1.0.1 virtio 0.1.15 ok + 0.1.22 ok + 0.1.prewhql ok + git 20120615 virtio 0.1.15 ok + 0.1.22 ok + 0.1.prewhql ok +============================================= +2.6.39 1.0.1 virtio 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD +3.0.3 1.0.1 virtio 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD +3.3.8 1.0.1 virtio 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD + virtio-pci 0.1.15 BSOD +3.4.2 1.0.1 virtio 0.1.15 BSOD + 0.1.prewhql BSOD + virtio-pci 0.1.15 BSOD + git 20120615 virtio 0.1.15 BSOD + 0.1.prewhql BSOD + virtio-pci 0.1.15 BSOD +============================================= + +Run arguments are attached. Minidump follows immediately. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1015 b/results/classifier/deepseek-2/output/device/1015 new file mode 100644 index 000000000..be3717b13 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1015 @@ -0,0 +1,2 @@ + +qemu-7.0 there is no device "hostdev0" defined diff --git a/results/classifier/deepseek-2/output/device/1018 b/results/classifier/deepseek-2/output/device/1018 new file mode 100644 index 000000000..8635b71f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1018 @@ -0,0 +1,24 @@ + +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/deepseek-2/output/device/1026176 b/results/classifier/deepseek-2/output/device/1026176 new file mode 100644 index 000000000..c163b6955 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1026176 @@ -0,0 +1,22 @@ + +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, \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1030 b/results/classifier/deepseek-2/output/device/1030 new file mode 100644 index 000000000..112d9e6f2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1030 @@ -0,0 +1,2 @@ + +Property 'rv32-riscv-cpu.x-v' not found diff --git a/results/classifier/deepseek-2/output/device/1031955 b/results/classifier/deepseek-2/output/device/1031955 new file mode 100644 index 000000000..3b05d4286 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1031955 @@ -0,0 +1,36 @@ + +qemu-system-arm -M lm3s811evb fails + +I am trying out examples from StellarisWare. + +When I try the uart_echo example, that initially tries to talk to the +display, I get this: + + $ .../qemu-1.1.1/bin/qemu-system-arm -M lm3s811evb -kernel uart_echo/gcc/uart_echo.bin + qemu: hardware error: strllaris_i2c_read: Bad offset 0xfc0 + + CPU #0: + R00=00000001 R01=005b8d80 R02=00061a80 R03=007a11ff + R04=40020000 R05=005b8d80 R06=00000002 R07=00000000 + R08=00000000 R09=00000000 R10=00000000 R11=00000000 + R12=00000000 R13=200000d4 R14=00000995 R15=000009cc + PSR=20000173 --C- T svc32 + Aborted + +The example is located in boards/ek-lm3s811/uart_echo in the +StellarisWare distribution. + +With the latest from git: + + $ .../qemu-git/qemu/bin/qemu-system-arm -M lm3s811evb -kernel uart_echo/gcc/uart_echo.bin + qemu-system-arm: hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. + +This however seems to be reported already (Bug #1028260). + +Both versions compiled from sources: + + ./configure --target-list=arm-linux-user,arm-softmmu,armeb-linux-user --enable-sdl --prefix=/path/to/... + +Running Ubunti 10.04 with Linux 2.6.32-40-generic-pae. + +/Lars \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1038136 b/results/classifier/deepseek-2/output/device/1038136 new file mode 100644 index 000000000..5b7c2a1fc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1038136 @@ -0,0 +1,9 @@ + +lack of keycode 89 for br-abnt2 keyboards + +qemu-kvm-1.1.1 +host system: slackware64-13.37 +Bug detailed description: +Independent of Guest OS nothing happens when keycode 89 is pressed. +If you select option "-k pt-br" at qemu commandline you get keycode 89 but there is no more keycode 26 (dead_acute dead_grave) and keycode 51 fails on "less" sign. +If you have a numeric keyboard you can use its "slash" key but there is no means to use the question mark, causing discomfort when you are scripting or programming. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1047470 b/results/classifier/deepseek-2/output/device/1047470 new file mode 100644 index 000000000..07d46bef2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1047470 @@ -0,0 +1,60 @@ + +qemu/kvm hangs reading from serial console + +This is for a qemu-kvm running on RHEL 5, so it's pretty old, +but i think the problem still exists in 1.2 + +We have conman running on our hosts, connecting to the +kvm/qemu's using + virsh console +which just opens up the console /dev/pts/slave that qemu +opens up when run with options + -nographic + -serial mon:pty + +Sometimes virsh console exits and then qemu locks up. +My guess is that something like this happens: + +virsh console exits +qemu does a select() on /dev/ptmx (and other FDs) +select() returns the FD of /dev/ptmx in the read-fdset +qemu does a read() +read() returns -1 (EIO) +qemu does other stuff for a while +select() ... /dev/ptmx +read() .. EIO +other stuff +select() ... read() ... select() ... read() ... select() +conman starts a new virsh console that connects +qemu does a read() +read() blocks b/c there is now a writer on the tty slave + +So i don't see any way around this, given the sorta rudi- +mentary semantics of TTY IO on Linux (not that i know of +any platform that does it better ... ?), except ... + +maybe qemu should + fcntl(master_fd, F_SETFL, flags | O_NONBLOCK) +in qemu-char.c:qemu_char_open_pty() +and be prepared to handle E_WOULDBLOCK|E_AGAIN in +qemu-char.c:fd_chr_read() ... ? + +--buck + +[*] i think, b/c in the old version we are running, sometimes + the guest spits out the + ^] + character to its console, and virsh console reads it and + doesn't check to see if its from stdin or the pty and exits, + which, i think, can be fixed like this: + +--- libvirt-0.8.2/tools/console.c.ctrl_close_bracket_handling_fix 2012-09-06 10:30:43.606997191 -0400 ++++ libvirt-0.8.2/tools/console.c 2012-09-06 10:34:52.154000464 -0400 +@@ -155,6 +155,7 @@ int vshRunConsole(const char *tty) { + + /* Quit if end of file, or we got the Ctrl-] key */ + if (!got || ++ fds[i].fd == STDIN_FILENO && + (got == 1 && + buf[0] == CTRL_CLOSE_BRACKET)) + goto done; \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1049 b/results/classifier/deepseek-2/output/device/1049 new file mode 100644 index 000000000..ede7a14e0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1049 @@ -0,0 +1,2 @@ + +Have DeviceRealize return boolean indicating error diff --git a/results/classifier/deepseek-2/output/device/1055090 b/results/classifier/deepseek-2/output/device/1055090 new file mode 100644 index 000000000..e5f057db2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1055090 @@ -0,0 +1,22 @@ + +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 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1062220 b/results/classifier/deepseek-2/output/device/1062220 new file mode 100644 index 000000000..1eded393f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1062220 @@ -0,0 +1,29 @@ + +qemu-system-arm crashed with SIGABRT in cpu_abort() + +-kernel u-boot.bin + +ProblemType: Crash +DistroRelease: Ubuntu 12.10 +Package: qemu-system 1.2.0-2012.09-0ubuntu1 +ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1 +Uname: Linux 3.5.0-10-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.6.1-0ubuntu1 +Architecture: amd64 +CrashCounter: 1 +Date: Fri Oct 5 19:30:23 2012 +ExecutablePath: /usr/bin/qemu-system-arm +InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110804) +ProcCmdline: qemu-system-arm -M versatilepb -kernel u-boot.bin +Signal: 6 +SourcePackage: qemu-linaro +StacktraceTop: + raise () from /lib/x86_64-linux-gnu/libc.so.6 + abort () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () + ?? () + ?? () +Title: qemu-system-arm crashed with SIGABRT in raise() +UpgradeStatus: Upgraded to quantal on 2012-08-11 (54 days ago) +UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1070762 b/results/classifier/deepseek-2/output/device/1070762 new file mode 100644 index 000000000..46c7d6221 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1070762 @@ -0,0 +1,38 @@ + +savevm fails with inserted CD, "Device '%s' is writable but does not support snapshots." + +Hi, + +yesterday unfortunately a customer reported a failed snapshot of his VM. Going through the logfile I discovered: + +"Device 'ide1-cd0' is writable but does not support snapshots" + +this is with qemu-1.2.0 and 1.0.1 at least... + +Why writeable? +Even if I specify "-drive ...,readonly=on,snapshot=off" to qemu the monitor-command sees the CD-ROM-device as being writeable?! + +Somewhere I saw a "hint" for blockdev.c: +=== snip === + +--- /tmp/blockdev.c 2012-10-24 11:37:10.000000000 +0200 ++++ blockdev.c 2012-10-24 11:37:17.000000000 +0200 +@@ -551,6 +551,7 @@ + case IF_XEN: + case IF_NONE: + dinfo->media_cd = media == MEDIA_CDROM; ++ dinfo->bdrv->read_only = 1; + break; + case IF_SD: + case IF_FLOPPY: + +=== snap === + +after installing with this small patch applied it works, so insert CD, savevm <somename> succeeds. +This should be fixed at all correct places, and the tags "readonly=on,snapshot=off" should do it, too. Or even just work after specifying a drive being a CD-rom should do the trick ;-) + +Another "bad habit" is, that the ISO/DVD-file has to be writeable to be changed? + +Thnx for attention and regards, + +Oliver. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1071 b/results/classifier/deepseek-2/output/device/1071 new file mode 100644 index 000000000..70d6fdaa5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1071 @@ -0,0 +1,13 @@ + +Cannot passthrough two network devices (Mellanox ConnectX-3) to VM. +Description of problem: +Cannot passthrough two network devices (Mellanox ConnectX-3) to VM. + +It generated me an error: +[ 6322.674602] genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:05:00.0)) vs. 00000000 (vfio-intx(0000:88:00.0)) + +Passthrough only one device to VM goes well. +Steps to reproduce: +1. Add a first passthrough network device. +2. Add a second passthrough network device. +3. Run VM. diff --git a/results/classifier/deepseek-2/output/device/1073952 b/results/classifier/deepseek-2/output/device/1073952 new file mode 100644 index 000000000..dc633607e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1073952 @@ -0,0 +1,29 @@ + +data sent to serial interface gets truncated after 64kb + +When sending more than 64kb of data to the serial interface in a short timespan, the data seems to disappear. + +I tested it with the latest release (qemu-kvm-1.2.0-rc2.tar.gz) where the bug still occurs. I stumbled upon it when I upraged my qemu version. The bug did not occur in the last version i had (0.12.5). + +You can reproduce it as follows: + +1. Start a dd or cat command in one terminal and pipe the output to a netcat. The testfile has to be larger than 64kb. I used one that had 93kb and did contain only ascii text. + + $ dd if=<TESTFILE> | nc -l 127.0.0.1 65432 + or + $ cat <TESTFILE> | nc -l 127.0.0.1 65432 + +2. Start a qemu and let the first serial port connect to the listening netcat. I suppose that the testsystem can be any system that does not read from the serial port on its own (e.g. during boot process). I used a self compiled minimal linux. + + $ qemu -cdrom <TESTSYSTEM> -serial tcp:127.0.0.1:65432 + +3. When the testsystem is booted, read from the serial device and write it to a file. + + $ dd if=/dev/ttyS0 of=/tmp/testFile + or + $ cat /dev/ttyS0 > /tmp/testFile + + +The result in almost all of my testruns is, that the /tmp/testFile does only has the size of 64kb. The rest of the data vanished. In some cases the file was slightly bigger (65kb or 67kb) but allways under 70kb. The complete file (93kb) was not trasmitted in any of the runs. + +I hope my explanation is exactly enough for you to reproduce it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1076 b/results/classifier/deepseek-2/output/device/1076 new file mode 100644 index 000000000..0dc6f6da1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1076 @@ -0,0 +1,13 @@ + +AC97+DirectSound only polls for audio every 10ms with no way to change it +Description of problem: +The AC97 device emulation, at least in combination with the DirectSound backend, only polls for audio every 10ms, meaning that DMA interrupts are received at a maximum frequency of 100Hz. This applies regardless of how large the buffers in the AC97's buffer list are, meaning that if one buffer takes less than 10ms to play, glitches can be heard with no possible mitigations on the host system. + +I came across this when fiddling with Serenity's own latencies in the AC97 driver and userland mixer. As soon as less than 512-sample buffers are used, audio becomes glitchy. Based on timing tests, kernel and userland processing of audio combined takes less than 200μs for one buffer, while the lowest average rate that DMA interrupts are received at is almost exactly 10ms. + +No changes to the dsound latency option, as listed [here](https://www.qemu.org/docs/master/system/invocation.html?highlight=dsound), made any difference; I tried as low as 2ms: `-audiodev dsound,id=snd0,latency=2000`. As far as I can tell there are no IRQ- or latency-related options for the AC97 emulation. +Steps to reproduce: +1. Use SerenityOS as of the above commit. +2. Before building, include an audio file in Base/home/anon; most ordinary FLAC, WAV and MP3 files created without options with ffmpeg should work. +3. Boot Serenity in QEMU on Windows without any special run configuration. +4. Play the audio file with `aplay <filename>`, hear glitches. diff --git a/results/classifier/deepseek-2/output/device/1077708 b/results/classifier/deepseek-2/output/device/1077708 new file mode 100644 index 000000000..5aeafd5a3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1077708 @@ -0,0 +1,17 @@ + +Video capture from webcam with USB passthrough freezes + +QEMU version: 1.2.0 +Graphics: Spice +Guest: Windows 7 32-bit +Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) + +I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. + +The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. + +I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. + +Command line: + +/usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1077838 b/results/classifier/deepseek-2/output/device/1077838 new file mode 100644 index 000000000..2655ad110 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1077838 @@ -0,0 +1,31 @@ + +qemu-nbd -r -c taints device for subsequent usage, even after -d + +Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind - subsequent connections get marked readonly. + +This is on quantal, haven't checked precise or raring. + +To demonstrate: +# use one image +qemu-img create -f qcow2 /tmp/1.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +sudo qemu-nbd -d /dev/nbd2 +# use a second one on the same nbd device, shows that reuse works: +qemu-img create -f qcow2 /tmp/2.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +sudo qemu-nbd -d /dev/nbd2 +# connect an image in read only mode +sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2 +sudo dumpe2fs /dev/nbd2 | head -n 3 +sudo qemu-nbd -d /dev/nbd2 +# now try to reuse in read-write mode again: +qemu-img create -f qcow2 /tmp/3.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +# here it goes boom: +mke2fs 1.42.5 (29-Jul-2012) +/dev/nbd2: Operation not permitted while setting up superblock +# still need to cleanup +sudo qemu-nbd -d /dev/nbd2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1086782 b/results/classifier/deepseek-2/output/device/1086782 new file mode 100644 index 000000000..e09b850c6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1086782 @@ -0,0 +1,85 @@ + +HPET time drift windows 7 64bits guest + +Using latest qemu-kvm (1.2.0), time drift (clock slow in guest) in Windows 7 64 bits guest when HPET is enabled (default). +Disabling HPET (-no-hpet) solves the time drift. + +UsePlatformClock enable/disable doesn't make a difference in the guest. +bcdedit /set useplatformclock true + +Using driftfix slew doesn't make a difference too. + + +# qemu-system-x86_64 --version +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +Kernel is 3.6.8: +# uname -a +Linux pulsar 3.6.8 #1 SMP Sat Dec 1 16:26:10 CET 2012 x86_64 x86_64 x86_64 GNU/Linux + +TSC is stable in the host: +=== +# cat /sys/devices/system/clocksource/clocksource0/current_clocksource +tsc + +Dmesg: +[ 0.000000] hpet clockevent registered +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2660.096 MHz processor +[ 0.001002] Calibrating delay loop (skipped), value calculated using timer frequency.. 5320.19 BogoMIPS (lpj=2660096) +[ 0.001138] pid_max: default: 32768 minimum: 301 +... +[ 1.492019] tsc: Refined TSC clocksource calibration: 2659.973 MHz +[ 1.492093] Switching to clocksource tsc + + +CPUinfo, constant_tsc: +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2667.000 +cache size : 2048 KB +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority +bogomips : 5320.19 + +# grep -i hpet .config +CONFIG_HPET_TIMER=y +CONFIG_HPET_EMULATE_RTC=y +CONFIG_HPET=y +# CONFIG_HPET_MMAP is not set +=== + +Qemu command line: +/usr/bin/qemu-system-x86_64 -drive file=/dev/vol0/KVMORION01,cache=none,aio=native,if=virtio \ + -drive file=/dev/vol0/KVMORION02,cache=none,aio=native,if=virtio \ + -cpu host \ + -m 2048 \ + -smp 4,maxcpus=4,cores=4,threads=1,sockets=1 \ + -rtc base=localtime,driftfix=slew \ + -vnc 10.124.241.211:0,password -k es \ + -monitor telnet:localhost:37200,server,nowait \ + -netdev tap,id=kvmorion,ifname=kvmorion,script=/etc/qemu-ifup-br0,downscript=/etc/qemu-ifdown-br0 \ + -device virtio-net-pci,netdev=kvmorion,id=virtio-nic0,mac=02:85:64:02:c2:aa \ + -device virtio-balloon-pci,id=balloon0 \ + -boot menu=on \ + -pidfile /var/run/kvmorion.pid \ + -daemonize + +Using 1 CPU doesn't make a difference. +Only workaround is disabling hpet (-no-hpet) + +Sample time drift in guest: +>ntpdate -q 10.124.241.211 + 5 Dec 13:36:06 ntpdate[3464]: Raised to realtime priority class +server 10.124.241.211, stratum 2, offset 3.694184, delay 0.02551 + 5 Dec 13:36:12 ntpdate[3464]: step time server 10.124.241.211 offset 3.694184 s +ec + +>ntpdate -q 10.124.241.211 + 5 Dec 13:52:02 ntpdate[1964]: Raised to realtime priority class +server 10.124.241.211, stratum 2, offset 4.719968, delay 0.02554 + 5 Dec 13:52:08 ntpdate[1964]: step time server 10.124.241.211 offset 4.719968 s +ec \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1087114 b/results/classifier/deepseek-2/output/device/1087114 new file mode 100644 index 000000000..cc26b6032 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1087114 @@ -0,0 +1,45 @@ + +assertion "QLIST_EMPTY(&bs->tracked_requests)" failed + +QEMU 1.3.0 on OpenBSD now crashes with an error as shown below and the command line params do not seem to matter. + +assertion "QLIST_EMPTY(&bs->tracked_requests)" failed: file "block.c", line 1220, function "bdrv_drain_all" + +#1 0x0000030d1bce24aa in abort () at /usr/src/lib/libc/stdlib/abort.c:70 + p = (struct atexit *) 0x30d11897000 + mask = 4294967263 + cleanup_called = 1 +#2 0x0000030d1bc5ff44 in __assert2 (file=Variable "file" is not available. +) at /usr/src/lib/libc/gen/assert.c:52 +No locals. +#3 0x0000030b0d383a03 in bdrv_drain_all () at block.c:1220 + bs = (BlockDriverState *) 0x30d13f3b630 + busy = false + __func__ = "bdrv_drain_all" +#4 0x0000030b0d43acfc in bmdma_cmd_writeb (bm=0x30d0f5f56a8, val=8) at hw/ide/pci.c:312 + __func__ = "bmdma_cmd_writeb" +#5 0x0000030b0d43b450 in bmdma_write (opaque=0x30d0f5f56a8, addr=0, val=8, size=1) at hw/ide/piix.c:76 + bm = (BMDMAState *) 0x30d0f5f56a8 +#6 0x0000030b0d5c2ce6 in memory_region_write_accessor (opaque=0x30d0f5f57d0, addr=0, value=0x30d18c288f0, size=1, shift=0, mask=255) + at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:334 + mr = (MemoryRegion *) 0x30d0f5f57d0 + tmp = 8 +#7 0x0000030b0d5c2dc5 in access_with_adjusted_size (addr=0, value=0x30d18c288f0, size=1, access_size_min=1, access_size_max=4, + access=0x30b0d5c2c6b <memory_region_write_accessor>, opaque=0x30d0f5f57d0) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:364 + access_mask = 255 + access_size = 1 + i = 0 +#8 0x0000030b0d5c3222 in memory_region_iorange_write (iorange=0x30d1d5e7400, offset=0, width=1, data=8) + at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:439 + mrio = (MemoryRegionIORange *) 0x30d1d5e7400 + mr = (MemoryRegion *) 0x30d0f5f57d0 + __func__ = "memory_region_iorange_write" +#9 0x0000030b0d5c019a in ioport_writeb_thunk (opaque=0x30d1d5e7400, addr=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:212 + ioport = (IORange *) 0x30d1d5e7400 +#10 0x0000030b0d5bfb65 in ioport_write (index=0, address=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:83 + func = (IOPortWriteFunc *) 0x30b0d5c0148 <ioport_writeb_thunk> + default_func = {0x30b0d5bfbbc <default_ioport_writeb>, 0x30b0d5bfc61 <default_ioport_writew>, 0x30b0d5bfd0c <default_ioport_writel>} +#11 0x0000030b0d5c0704 in cpu_outb (addr=49216, val=8 '\b') at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:289 +No locals. +#12 0x0000030b0d6067dd in helper_outb (port=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/target-i386/misc_helper.c:72 +No locals. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1088617 b/results/classifier/deepseek-2/output/device/1088617 new file mode 100644 index 000000000..6100a9f25 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1088617 @@ -0,0 +1,15 @@ + +qemu-system-mipsel save/restore broken + +Save and restore on mipsel seems to be broken (tested with commit 1c97e303d4ea80a2691334b0febe87a50660f99d). To reproduce: + +1. Download debian_squeeze_mipsel_standard.qcow2 and vmlinux-2.6.32-5-4kc-malta from from http://people.debian.org/~aurel32/qemu/mipsel/ + +2. Boot the system. I had to ^D past a Bus error in fsck, which may be another bug (haven't investigated). The command line used was: +qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda debian_squeeze_mipsel_standard.qcow2 -append "root=/dev/sda1 console=tty0" -k en-us -vnc :0 + +3. Once the system is booted, go to the monitor and do "savevm booted". Then quit. + +4. Re-run qemu-system-mipsel again with "-loadvm booted". The guest system comes back but is hung (the monitor remains responsive, however). + +I also captured a debug log, which is attached. The immediate cause of the freeze seems to be that it's stuck in a loop repeatedly handling the same page fault over and over. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1089006 b/results/classifier/deepseek-2/output/device/1089006 new file mode 100644 index 000000000..15b39558c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1089006 @@ -0,0 +1,12 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1090 b/results/classifier/deepseek-2/output/device/1090 new file mode 100644 index 000000000..94d1dae6c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1090 @@ -0,0 +1,16 @@ + +can't create rocker device because setting device array properties on the command line is broken +Description of problem: +it does not accept the prop_array parameter: + +``` +qemu-system-x86_64 -enable-kvm -m 1g -cpu host -netdev socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0 +qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found +``` +Steps to reproduce: +1. just run the command +Additional information: +the latest qemu i find working is 6.1.1... if you start a fedora vm and `dnf install kernel-modules-internal` then the rocker ports appear and work properly... + +thanks, +cs diff --git a/results/classifier/deepseek-2/output/device/1090558 b/results/classifier/deepseek-2/output/device/1090558 new file mode 100644 index 000000000..24c36816d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1090558 @@ -0,0 +1,10 @@ + +hw/mc146818: error reading RTC_HOURS_ALARM + +get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly. + +- Bit 7 must be masked before conversion from BCD. +- Care must be taken to check the don't care condition before masking. +- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done in convert_hour()). + +Seen in commit e376a788ae130454ad5e797f60cb70d0308babb6. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1090604 b/results/classifier/deepseek-2/output/device/1090604 new file mode 100644 index 000000000..a92ab6da8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1090604 @@ -0,0 +1,12 @@ + +RFE: Implement support for SMBIOS Type 41 structures + +This was originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=669955 + +""" +Please extend the existing support for SMBIOS in qemu to add a capability to provide "Onboard Devices Extended Information" (Type 41). Not only is this replacing one of the existing types, but it also provides a mapping between devices and physical system chassis locations. But there is no physical chassis! Right. However, this doesn't mean you don't want to tell the guest OS which virtual (e.g. network) interface is which. You can do that, if you implement this extension that is already going into real hardware, and likely other VMs too. + +See also page 117 of the v2.7 of the SMBIOS spec. + +FWIW, VMware ESX and Workstation expose their PCI NICs in the PCI IRQ Routing Table. Kind of odd the first time you see it with biosdevname, as your NIC becomes pci3#1, but that's "correct" from a BIOS perspective. :-) +""" \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1093360 b/results/classifier/deepseek-2/output/device/1093360 new file mode 100644 index 000000000..9167dc552 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1093360 @@ -0,0 +1,14 @@ + +files on microsoft iso images mounted to qemu VM get stripped from Version info. E.G. Microsoft UAG installation fails + +QEMU 0.9.0-0.14.1 +KVM 60-88-0.14.1 +there is a reference for a root cause, why installation of Microsoft UAG fails. +http://blogs.technet.com/b/isablog/archive/2010/07/13/another-tmg-2010-installation-failure-with-error-0x80070643.aspx + +when checking available information on the mounted UAG ISO in my qemu machine, I realized simliar reduced information. +this was found: +using AQEMU 0.8.2 of 2011.07.27 + +using QEMU 0.9.0-0.14.1 and KVM 60-88-0.14.1 +in an KVM managed machine \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1096713 b/results/classifier/deepseek-2/output/device/1096713 new file mode 100644 index 000000000..297d78c4c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1096713 @@ -0,0 +1,9 @@ + +qemu 1.3.0: Windows XP crashes when reconizing the USB keyboard + +I'm trying to use the usb tablet and the usb keyboard as follows: +./qemu-system-i386 -device pci-ohci -device usb-tablet -device usb-kbd +or +./qemu-system-i386 -device ich9-usb-ehci1 -device ich9-usb-uhci1 -device usb-tablet -device ich9-usb-uhci2 -device usb-kbd + +While Windows XP works fine if I only use the tablet but not the keyboard, it crashed with a BSOD when I use both keyboard and tablet. It crashed during the detection of the keyboard. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1096714 b/results/classifier/deepseek-2/output/device/1096714 new file mode 100644 index 000000000..18650b126 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1096714 @@ -0,0 +1,11 @@ + +qemu 1.3.0: usb devices shouldn't have same vendor/product ID and same serial + +Boot Windows XP with +./qemu-system-i386 -device pci-ohci -device usb-tablet +and then with +./qemu-system-i386 -device pci-ohci -device usb-kbd + +and you will notice, that the usb keyboard is not detected. In fact, Windows XP detects the usb tablet and loads the driver for the tablet instead of the driver for the keyboard. + +The problem seems to be, that vendor and product ID and even the seriel of both the usb tablet and the usb keyboard are the same as an lsusb reveiles. Hence, Windows XP doesn't detect when you replace the tablet by a keyboard and vice versa. I didn't check other USB devices, but it seems a bad idea to me to have devices with the same vendor/product Id. I'm not aware, whether it is sufficient to change the seriel numbers of the devices. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1101210 b/results/classifier/deepseek-2/output/device/1101210 new file mode 100644 index 000000000..25d394060 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1101210 @@ -0,0 +1,10 @@ + +qemu 1.4.2: usb keyboard not fully working + +When using the usb keyboard, I can't type the | character. I'm using german keyboard layout (de) on the host and inside the guest. As a guest OS, I use Linux (e.g. a recent KNOPPIX cd). To obtain the | character on a german keyboard, I need to press AltGr + the < or > key, i.e. the key right to the left shift. + +The qemu command line is something like this: +./qemu-system-i386 -device pci-ohci -device usb-kbd +I also tried +./qemu-system-i386 -usb -usbdevice keyboard +with the same effect. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1104 b/results/classifier/deepseek-2/output/device/1104 new file mode 100644 index 000000000..b538feabf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1104 @@ -0,0 +1,2 @@ + +PAN support for AArch32 diff --git a/results/classifier/deepseek-2/output/device/1106 b/results/classifier/deepseek-2/output/device/1106 new file mode 100644 index 000000000..f23359182 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1106 @@ -0,0 +1,10 @@ + +undefined address access cause failure +Description of problem: +Hi, +I used serial device as below: +qemu/hw/char/serial.c +It defines only support 8 registers address space(offset 0x00-0x32). And in guest os, the hardware is synopsys dw_apb_uart which is compatible with 16550. +when it access low 8 registers, it works ok. but it may access high address(0x8c) which serial.c not defined, then fail occur. + +Is there anyway to handle this, access address which device not defined, expect it no handle, but not cause system crash. like read is zero and write ignore. diff --git a/results/classifier/deepseek-2/output/device/1110 b/results/classifier/deepseek-2/output/device/1110 new file mode 100644 index 000000000..319b3f77e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1110 @@ -0,0 +1,4 @@ + +Add vhost-user-gpu support for cross architecture emulation +Additional information: +host:Android 12 with Linux kernel 4.14.186+ diff --git a/results/classifier/deepseek-2/output/device/1112 b/results/classifier/deepseek-2/output/device/1112 new file mode 100644 index 000000000..4247c522a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1112 @@ -0,0 +1,2 @@ + +Heap-overflow in scsi_disk_emulate_write_same diff --git a/results/classifier/deepseek-2/output/device/1114 b/results/classifier/deepseek-2/output/device/1114 new file mode 100644 index 000000000..b82724956 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1114 @@ -0,0 +1,2 @@ + +Non-deterministic hang in libvfio-user:functional/test-client-server test causing timeout in CentOS 8 CI job diff --git a/results/classifier/deepseek-2/output/device/112 b/results/classifier/deepseek-2/output/device/112 new file mode 100644 index 000000000..fc225b7a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/112 @@ -0,0 +1,2 @@ + +setting unsupported timeout for i6300esb watchdog causes hw reset diff --git a/results/classifier/deepseek-2/output/device/1126 b/results/classifier/deepseek-2/output/device/1126 new file mode 100644 index 000000000..eae3e9d23 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1126 @@ -0,0 +1,9 @@ + +qemu-system-mipsel freezes for nanoMIPS in the semihosting mode +Description of problem: +In the current git master branch (SHA: 7b17a1a8) there is a problem with qemu-system-mipsel when trying to execute a simple hello.elf program in the semihosting mode for the nanoMIPS architecture. I.e. after executing the following command the terminal freezes: + ``` + $ ./qemu-system-mipsel -cpu I7200 -semihosting -nographic -kernel hello.elf + ``` +hello.elf file is generated using the nanoMIPS GNU Toolchain (https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases). +The program regularly terminates with QEMU emulator version 6.0.1. diff --git a/results/classifier/deepseek-2/output/device/1130 b/results/classifier/deepseek-2/output/device/1130 new file mode 100644 index 000000000..e401968c3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1130 @@ -0,0 +1,30 @@ + +error on run qemu-system-aarch64 -icount shift=1,align=off,sleep=on -smp 2 +Description of problem: +This issue happen with the most recent version. +* Compile parameters: +``` +./configure --target-list=aarch64-softmmu --prefix=pwd/release --disable-werror --enable-lto --enable-capstone --enable-system --enable-fdt --disable-xen --disable-kvm --enable-plugins +``` +* run： +``` +qemu-system-aarch64 -nographic -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 2 -vnc :2 -m 4080 -kernel /home/yuzy/mywork/linux/linux-5.15.30/arch/arm64/boot/Image.gz -initrd /home/yuzy/mywork/build/rootfs.cpio.gz +``` +* error occurred： +``` +** +ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Aborted (core dumped) +``` +Steps to reproduce: +1. run qemu-system-aarch64 -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 2 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz +2. it will assertion failed: (qemu_mutex_iothread_locked()) +Additional information: +The following two situations are good： +``` +qemu-system-aarch64 -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 1 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz +``` +``` +qemu-system-aarch64 -machine virt -cpu cortex-a57 -smp 2 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz +``` +I assume the issues are: gic diff --git a/results/classifier/deepseek-2/output/device/1134 b/results/classifier/deepseek-2/output/device/1134 new file mode 100644 index 000000000..ec3e9136a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1134 @@ -0,0 +1,4 @@ + +Make ivshmem more generic not only a PCI device +Additional information: +It will also benefit from making it more portable, see https://gitlab.com/qemu-project/qemu/-/issues/666 diff --git a/results/classifier/deepseek-2/output/device/1139 b/results/classifier/deepseek-2/output/device/1139 new file mode 100644 index 000000000..4a0c9a6ff --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1139 @@ -0,0 +1,79 @@ + +block/nbd.c and drive backup to a remote nbd server +Description of problem: +Good afternoon! + +I trying to copy attached drive content to remote NBD server via drive-backup QMP method. I'he tested two very similar ways but with very different performance. First is a backuping to exported NBD at another server. Second way is a backuping to same server but with connecting to /dev/nbd*. + +Exporting qcow2 via nbd: +``` +(nbd) ~ # qemu-nbd -p 12345 -x backup --cache=none --aio=native --persistent -f qcow2 backup.qcow2 + +(qemu) ~ # qemu-img info nbd://10.0.0.1:12345/backup +image: nbd://10.0.0.1:12345/backup +file format: raw +virtual size: 10 GiB (10737418240 bytes) +disk size: unavailable +``` + +Starting drive backuping via QMP: + +``` +{ + "execute": "drive-backup", + "arguments": { + "device": "disk", + "sync": "full", + "target": "nbd://10.0.0.1:12345/backup", + "mode": "existing" + } +} +``` + +With process starting qemu notifying about warning: + +> warning: The target block device doesn't provide information about the block size and it doesn't have a backing file. The default block size of 65536 bytes is used. If the actual block size of the target exceeds this default, the backup may be unusable + +And backup process is limited by speed around 30MBps, watched by iotop + + +Second way to creating backup + +Exporting qcow2 via nbd: +``` +(nbd) ~ # qemu-nbd -p 12345 -x backup --cache=none --aio=native --persistent -f qcow2 backup.qcow2 +``` + +``` +(qemu) ~ # qemu-img info nbd://10.0.0.1:12345/backup +image: nbd://10.0.0.1:12345/backup +file format: raw +virtual size: 10 GiB (10737418240 bytes) +disk size: unavailable +(qemu) ~ # qemu-nbd -c /dev/nbd0 nbd://10.0.0.1:12345/backup +(qemu) ~ # qemu-img info /dev/nbd0 +image: /dev/nbd0 +file format: raw +virtual size: 10 GiB (10737418240 bytes) +disk size: 0 B +``` + +Starting drive backuping via QMP to local nbd device: + +``` +{ + "execute": "drive-backup", + "arguments": { + "device": "disk", + "sync": "full", + "target": "/dev/nbd0", + "mode": "existing" + } +} +``` + +Backup process started without previous warning, and speed limited around 100MBps (network limit) + +So I have question: how I can get same performance without connection network device to local block nbd device at the qemu host? + +Kind regards diff --git a/results/classifier/deepseek-2/output/device/116 b/results/classifier/deepseek-2/output/device/116 new file mode 100644 index 000000000..78dda4b99 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/116 @@ -0,0 +1,2 @@ + +qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974 diff --git a/results/classifier/deepseek-2/output/device/1162227 b/results/classifier/deepseek-2/output/device/1162227 new file mode 100644 index 000000000..6a030f02c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1162227 @@ -0,0 +1,17 @@ + +Mouse works badly when connecting to host via vnc + +Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. +Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. + +I saw this bug in the following configurations: +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: +qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda +* A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow + +Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". + +Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1162644 b/results/classifier/deepseek-2/output/device/1162644 new file mode 100644 index 000000000..6f611f37b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1162644 @@ -0,0 +1,91 @@ + +qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base() + +Description: +When QEMU tries to boot with a usb 3.0 tablet (xhci) on a Raring ringtail box (QEMU package1.4.0+dfsg-1expubuntu4) it will crash soon afterwards: + +qemu-system-x86_64: /build/buildd/qemu-1.4.0+dfsg/hw/usb/core.c:552: usb_packet_setup: Assertion `p->iov.iov != ((void *)0)' failed. + +Component: +qemu-system -> 1.4.0+dfsg-1expubuntu4 + +Ubuntu Version: + +Description: Ubuntu Raring Ringtail (development branch) +Release: 13.04 + +Steps to reproduce it: + +I met this bug while running the virt-test suite + +https://github.com/autotest/virt-test + +Instructions to install and run it can be seen on the README file + +https://github.com/autotest/virt-test#readme + +After the suite is set, it can be reproduced on a raring (13.04) simply by running: + +./run -t qemu --tests usb.usb_reboot.usb_tablet.xhci + +Command line: + +23:52:42 INFO | Running qemu command (reformatted): +/usr/bin/kvm \ + -S \ + -name 'virt-tests-vm1' \ + -nodefaults \ + -chardev socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130331-233911-ndvUEvrV,server,nowait \ + -mon chardev=hmp_id_hmp1,mode=readline \ + -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-serial,chardev=serial_id_serial1 \ + -chardev socket,id=seabioslog_id_20130331-233911-ndvUEvrV,path=/tmp/seabios-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-debugcon,chardev=seabioslog_id_20130331-233911-ndvUEvrV,iobase=0x402 \ + -device ich9-usb-uhci1,id=usb1 \ + -device nec-usb-xhci,id=usbtest \ + -drive file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0 \ + -device virtio-blk-pci,drive=virtio0,bootindex=1 \ + -device virtio-net-pci,netdev=idumV1TE,mac='9a:c0:c1:c2:c3:c4',id='idmN7iHv' \ + -netdev user,id=idumV1TE,hostfwd=tcp::5000-:22 \ + -m 1024 \ + -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \ + -cpu 'SandyBridge' \ + -M pc \ + -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ + -device usb-tablet,id=usb-testdev,bus=usbtest.0,port=1 \ + -vnc :0 \ + -vga std \ + -rtc base=utc,clock=host,driftfix=none \ + -boot order=cdn,once=c,menu=off \ + -enable-kvm + +ProblemType: Crash +DistroRelease: Ubuntu 13.04 +Package: qemu-system-x86 1.4.0+dfsg-1expubuntu4 +ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 +Uname: Linux 3.8.0-15-generic x86_64 +ApportVersion: 2.9.2-0ubuntu5 +Architecture: amd64 +Date: Sun Mar 31 23:52:46 2013 +EcryptfsInUse: Yes +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-03-31 (0 days ago) +InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) +MarkForUpload: True +ProcEnviron: + TERM=dumb + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +Signal: 6 +SourcePackage: qemu +StacktraceTop: + raise () from /lib/x86_64-linux-gnu/libc.so.6 + abort () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () from /lib/x86_64-linux-gnu/libc.so.6 + __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () +Title: qemu-system-x86_64 crashed with SIGABRT in raise() +UpgradeStatus: Upgraded to raring on 2013-03-31 (0 days ago) +UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1164 b/results/classifier/deepseek-2/output/device/1164 new file mode 100644 index 000000000..4f7b5d913 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1164 @@ -0,0 +1,18 @@ + +q35: incorrect values for PCIEXBAR masks +Description of problem: +https://lore.kernel.org/all/1fded151ce5ecbf7010427871b908000b2aba9ee.1520867956.git.x1917x@gmail.com/ + +In function [mch_update_pciexbar](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/q35.c#L295) + +There are two small issues in PCIEXBAR address mask handling: +- wrong bit positions for address mask bits (see PCIEXBAR description + in Q35 datasheet) +- incorrect usage of 64ADR_MASK + +Due to this, attempting to write a valid PCIEXBAR address may cause it to +shift to another address, causing memory layout corruption where emulated +MMIO regions may overlap real (passed through) MMIO ranges. Fix this +by providing correct values. +Additional information: +Q35 datasheet: https://www.intel.com/Assets/PDF/datasheet/316966.pdf ( 5.1.16 PCIEXBAR—PCI Express* Register Range Base Address ) diff --git a/results/classifier/deepseek-2/output/device/1168 b/results/classifier/deepseek-2/output/device/1168 new file mode 100644 index 000000000..1f5c37a1f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1168 @@ -0,0 +1,14 @@ + +ivshmem: ivshmem-doorbell can't notify the MSI-X interrupt on Arm64 guest +Description of problem: +I init several qemu-kvm VMs on my arm64 host, which is a NVIDIA Xavier board. I want to use qemu's ivshmem-doorbell to build a sync shared memory communition with its MSI-X interrupt mechanism. I init the ivshmem-server and ivshmem-client on the host first, after then init the guests. The visul PCI-e device named "Inter-VM shared memory" can be successfully seen in my guests with command "lspci". +I write a driver for this pci-e device to request and handle the MSI-X interrupts, which init well in the guest and can ring or receive from an interrupt vector on other peerID with the driver's IOCTL interface, the peer that receive vector in my environment is the ivshmem-client. However, when i use the ivshmem-client command "int" to ring my guest , the guest can't receive the msi-x interrupt notification. +Steps to reproduce: +1. init ivshmem-server on the host, with command "ivshmem-server -l 4M -M fg-doorbell -n 8 -F -v". +2. init ivshmem-client on the host, with command "ivshmem-client -v". +3. init the qemu-kvm VM . +4. init the driver with "insmod" in guest to request the msi-x interrupt, while "cat /proc/interrupts" shows the interrupt request successfully! +5. on host, ivshmem-client use command "int 1 0" to ring the guest's interrupt trigger, however ,nothing happened. +Additional information: +I am fully sure that there is no problem about the driver I wrote for the pci-e inter-VM shared memory device, for i has tested that the driver works on my X86 PC, where I deployed qemu-x86 VMs and the driver can work well in X86 guests with the inshmem-doorbell mechanism. The ivshmem-client work on host can notify the guest to trigger the correct msix-x interrupt. +Therefore, I digged the msi-x interrupt structure and use devmem tool to write the data to the messageAddress manually, which can correctly trigger the msi-x interrupt in my arm64 guest in the Xavier board, meaning the msi-x interrupt is OK in the guest. So I doubt maybe there is any issue on the ivshmem-doorbell mechanism that ring a interrupt vector in the guset of qemu-aarch64. diff --git a/results/classifier/deepseek-2/output/device/1173490 b/results/classifier/deepseek-2/output/device/1173490 new file mode 100644 index 000000000..5ea58f0dd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1173490 @@ -0,0 +1,21 @@ + +virtio net adapter driver with kvm slow on winxp + +# lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 12.04.1 LTS +Release: 12.04 +Codename: precise + +#virsh version +Compiled against library: libvirt 1.0.4 +Using library: libvirt 1.0.4 +Using API: QEMU 1.0.4 +Running hypervisor: QEMU 1.2.0 + +windows xp clean install with spice-guest-tools-0.52.exe from + http://spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.52.exe + +it comes very slow , and the Interrupts process got very high cpu usage(above 60%). +when i switch the net adapter from virtio to default(rtl8139) ,it works well. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1174 b/results/classifier/deepseek-2/output/device/1174 new file mode 100644 index 000000000..dc783fac8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1174 @@ -0,0 +1,14 @@ + +aspeed: Fix first byte in I2C old register mode slave receive +Description of problem: +The first byte of data received through the Aspeed I2C slave controller through the old-register mode (specifically byte-buffered, not pool buffered or DMA buffered) is incorrect. It should be the 8-bit I2C slave address for the transfer, which will be the 7-bit I2C slave address of the I2C controller shifted left 1, and 1 or 0 for the lowest bit (is-slave-to-master-transfer, or is-master-to-slave-transfer). +Steps to reproduce: +You could use the simulated I2C slave EEPROM https://docs.kernel.org/i2c/slave-eeprom-backend.html, but you need another I2C model to send data to it. + +Alternatively, you can take this downstream patch and run the qtest in it. It has a test case for slave-mode rx in old-register mode: + +https://github.com/facebook/openbmc/blob/helium/common/recipes-devtools/qemu/qemu/0008-hw-misc-Add-byte-by-byte-i2c-network-device.patch +Additional information: +I already created the fix, it's pretty simple, I submitted it to the mailing list and Klaus (the author of that section of the Aspeed I2C controller) reviewed it. https://lore.kernel.org/qemu-devel/20220820225712.713209-1-peter@pjd.dev/#t + +This is relatively critical fix, but since slave-mode I2C is not widely used at this point, it's probably fine to ship with this bug. My team uses the master branch for everything anyways. diff --git a/results/classifier/deepseek-2/output/device/1175 b/results/classifier/deepseek-2/output/device/1175 new file mode 100644 index 000000000..f3c73441f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1175 @@ -0,0 +1,9 @@ + +Crash / Assert in VVFAT.c while installaling WinXP from QEMU 7.0 running in Raspberry OS +Description of problem: +- Windows XP installation crashes QEMU with : +qemu-system-i386: ../block/vvfat.c:103: array_get: Assertion `index < array->next' failed. +Steps to reproduce: +Use command line above and run WindowsXP installation +Additional information: +Execution also leads to many "Invalid file name" being reported by QEMU diff --git a/results/classifier/deepseek-2/output/device/1175513 b/results/classifier/deepseek-2/output/device/1175513 new file mode 100644 index 000000000..e8557ccd0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1175513 @@ -0,0 +1,12 @@ + +Qemu 1.5-git gpu clock control doesn`t work after guest reboot + +I run qemu from git with such command: + +qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 -cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on -device vfio-pci,host=02:00.0,x-vga=on \ +-enable-kvm -monitor stdio -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device intel-hda -device hda-duplex \ +-drive file='/home/<user>/qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \ +-drive file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \ +-spice port=5930,disable-ticketing + +Before guest (Windows 7) reboot, videocard works in 3D mode with full frequency. But after reboot videocard works in 3D only with powersafe frequency. Then I must reboot host for recover gpu clock control. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1176 b/results/classifier/deepseek-2/output/device/1176 new file mode 100644 index 000000000..749fb33ec --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1176 @@ -0,0 +1,8 @@ + +VVFAT :rw writes from guest (ReactOS, windowsXP) not visible by host +Description of problem: +As described in https://jira.reactos.org/browse/CORE-18327 +While ./LMS is mounted as a :rw VVFAT drive, guest OS (ReactOS) is able to read files BUT when files are "written" from the guest, they are not visible on host side. +QEMU execution is also massively polluted by "invalid file name" messages coming from https://git.qemu.org/?p=qemu.git;a=blob_plain;f=block/vvfat.c;hb=HEAD (but this is not specific to the use with ReactOS, as this is also observed with other guest : WXP, ...) + +See attached screenshot showing WXPSP3 as guest with file created in VVFAT drive while guest misses the newly created file. diff --git a/results/classifier/deepseek-2/output/device/118 b/results/classifier/deepseek-2/output/device/118 new file mode 100644 index 000000000..e50eb4e1c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/118 @@ -0,0 +1,2 @@ + +USB device 1.1 not correctly passedthru from Linux host to Windows guest diff --git a/results/classifier/deepseek-2/output/device/1181796 b/results/classifier/deepseek-2/output/device/1181796 new file mode 100644 index 000000000..09e596667 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1181796 @@ -0,0 +1,10 @@ + +Qemu locks up when incoming serial fills up + +I'm using Windows, I'm not sure if this happens on Linux, but for all I know it does. To repro, fire up any image (ideally one that does almost nothing, and doesn't read the serial port), and use the option "-serial pipe:mypipe". Then use Putty or something else to connect to that named pipe so Qemu starts up. Now start typing into Putty. For a VM image that never reads the serial port, upon typing the 16th character Qemu stops executing instructions in the guest (as evidenced either by being unable to step in gdb, seeing that "info registers" in the monitor always reports the same value, or just by observing that the guest is hung). For OS images that do regularly read the serial port, this may require pasting >16 bytes into Putty at once. This occurs with more than just Putty, use anything that can write at a named pipe. + +I would have expected that bytes get dropped, or even more ideally blocked at the sender's side of the named pipe. I would not expect that the entire VM stops. You seem to be able to unwedge the VM by switching to the monitor and running "i /1c 0x3f8" until you've pulled enough out of buffer that it's happy to run again. Interestingly, all bytes seem to come through (more than just the 16) when read from the monitor. + +I haven't been able to get a source environment set up, but I have tried a few of the Windows binaries. This repros in 1.4.1, 1.3.0, 1.2, and 1.0, the most recent build I found that did not have this behavior was 0.15.0. + +Maybe I'm missing something very obvious, and if so, I apologize in advance. I'm also happy to create an OS image that highlights this problem if it would help. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1185888 b/results/classifier/deepseek-2/output/device/1185888 new file mode 100644 index 000000000..30ada1ea8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1185888 @@ -0,0 +1,26 @@ + +-device nec-usb-xhci (usb 3) breaks VM snapshots + +Enabling the USB 3.0 controller apparently breaks "live" snapshotting. + +To reproduce: + + $ qemu-system-x86_64 -device nec-usb-xhci vm.qcow2 + +then, at the Monitor: + + (qemu) savevm + Error -22 while writing VM + (qemu) + +Instead, if I remove -device nec-usb-xhci from the cmdline, everything works fine. + +Some QEMU and OS info: + + $ qemu-system-x86_64 -version + QEMU emulator version 1.5.0, Copyright (c) 2003-2008 Fabrice Bellard + + $ uname -a + Linux localhost 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux + +The same also happens with 1.4.2. All compiled from source, not Debiabn package (btw, this *also* happens with distro packages/older versions). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1186303 b/results/classifier/deepseek-2/output/device/1186303 new file mode 100644 index 000000000..3f329d01e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1186303 @@ -0,0 +1,23 @@ + +virtual fat do not working in qemu 1.5.0 + +Guest : windows Seven / XP +Qemu version : 1.5.0 +cmd line : +-drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on +generated by libvirt : + +<disk type='dir' device='floppy'> + <driver name='qemu' type='fat'/> + <source dir='/mnt/vdisk/diskconf/TEST003/'/> + <target dev='fda' bus='fdc'/> + <readonly/> + <alias name='fdc0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + +works with qemu <= 1.4.1 + +with qemu 1.5.0 , guest does not see the floppy content. + +Regards \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1187529 b/results/classifier/deepseek-2/output/device/1187529 new file mode 100644 index 000000000..065f91fbf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1187529 @@ -0,0 +1,12 @@ + +Devices on PCI bridge stop working when live-migrated + +qemu version: 1.4.50 (0ca5aa4f4c4a8bcc73988dd52a536241d35e5223) +host: x86_64, Linux 3.6.10 (Fedora 17) +client: x86_64 Centos 6.3 (doesn't matter, really) + +If a device, e.g. an lsi53c895a, is on a pci-bridge, after migration, the device stops working (e.g., commands like "poweroff" +get an Input/Output error. Fails under either xen or kvm. If "top" was running, some cpus go to ~100% wait. + +Sample KVM invocation line: +qemu-system-x86_64 -machine type=pc,accel=kvm -m 4096 -device pci-bridgemsi=on,chassis_nr=1,id=pciBridge1.0,addr=0x11.0 -device lsi53c895a,id=sas,bus=pciBridge1.0,addr=0x1.0x0 -drive if=none,id=disk0,file=/path/to/disk/image -device scsi-disk,bus=sas.0,scsi-id=0,drive=disk0 -vnc 127.0.0.1:0,to=99 -serial pty -boot order=cda -smp 4,maxcpus=4 -monitor vc \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1188018 b/results/classifier/deepseek-2/output/device/1188018 new file mode 100644 index 000000000..e2e0c5731 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1188018 @@ -0,0 +1,6 @@ + +qemu monitor does not suppot rbd "savevm" command + +1. I used ceph rbd as my block device, /usr/local/bin/qemu-system-x86_64 -drive format=rbd,file=rbd:rbd/sles.img:rbd_cache=true,cache=writeback -boot c -m 1024 -enable-kvm -vnc 0.0.0.0:0 -monitor stdio + +2. when in monitor command line "savevm", it reports "Error -95 while writing VM" in the monitor \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1188991 b/results/classifier/deepseek-2/output/device/1188991 new file mode 100644 index 000000000..7b8c79df7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1188991 @@ -0,0 +1,61 @@ + +Unable to do serial communication using -chardev tty + + + +Im running an Linux Image (kernel 3.2.8) for beagleboard-xm on QEMU's 1.4.0 emulator. + + +What I want to do is to have a communication between guest and host across serial the 4 differents ttyO present on the guest. QEMU offer facilities to redirect the trafic to some device in the host side. + +The command that I use to lauch QEMU is : + + sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -see -device usb-kbd -chardev tty,id=mytty,path=/dev/ttyS0 + +As it says in the QEMU's manual -chardev is suppose to connect to a local tty device at the path given + +My problem goes like this: + +At the guest kernel boot I'm able to see that my UART where enabled + + [ 2.682040] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled + [ 2.777947] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 + [ 2.794967] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 + [ 2.814942] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 + [ 2.966825] console [ttyO2] enabled + [ 2.984777] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3 + +In fact, when I go see in to /proc/tty/driver and I do a cat on OMAP-SERIAL Im able to see this serinfo:1.0 driver revision: + + 0: uart:OMAP UART0 mmio:0x4806A000 irq:72 tx:0 rx:0 CTS|DSR|CD + 1: uart:OMAP UART1 mmio:0x4806C000 irq:73 tx:0 rx:0 CTS|DSR|CD + 2: uart:OMAP UART2 mmio:0x49020000 irq:74 tx:268 rx:37 RTS|CTS|DTR|DSR|CD + 3: uart:OMAP UART3 mmio:0x49042000 irq:80 tx:0 rx:0 CTS|DSR|CD + +I know that ttyO2 is working because my console is been redirected to it. The thing is that doing a set serial on any of the ttyO I get the following message: + + [root@enu driver]# setserial -a /dev/ttyO0 + /dev/ttyO0, Line 0, UART: undefined, Port: 0x0000, IRQ: 72 + Baud_base: 3000000, close_delay: 50, divisor: 0 + closing_wait: 3000 + Flags: spd_normal + +The same goes with ttyO2. I tryed to set some sethings to any of the ttyO with setserial but I always get the same message: + + [root@enu ~]# setserial /dev/ttyO0 uart 8250 + setserial: can't set serial info: Invalid argument + [root@enu ~]# setserial /dev/ttyO0 port 0x4806a000 + setserial: can't set serial info: Invalid argument + +basicly I want to establish a serial communication between a guest and a host, but the serial ports on the guest side aren't well configured. + +When I open ttyS0 with minicom on the host side and do on the guest side + + echo "test" > /dev/ttyO0 + +The host recives nothing. + +Anyone can tell me how I could remove tty modules on the guest side and try to insert it again to see if the setup resets properly or give me any advice on how to solve this problem. Plus if anyone has already tryed doing this kind on serial communication I would like to here from you. + +Thank, +Francisco \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1191 b/results/classifier/deepseek-2/output/device/1191 new file mode 100644 index 000000000..c13787afd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1191 @@ -0,0 +1,10 @@ + +AC97+CoreAudio no audio when out frequency not 44,1KHz & always forces host to use 44,1KHz (or less if frequency not supported) +Description of problem: +AC97+CoreAudio outputs no audio when output frequency not 44,1KHz. Also always forces host to use 44,1KHz (or less if frequency not supported on host output) +Steps to reproduce: +1. Boot any OS with (only) AC97 audio on macOS +2. Attempt to play audio with output frequency in guest set to 48KHz +3. Observe lack of output +Additional information: +I'm using QEMU to test a Custom OS written by me, but this shouldn't be a code issue on our side, rather an issue with QEMU itself, if this is mistaken, please inform us. diff --git a/results/classifier/deepseek-2/output/device/1191326 b/results/classifier/deepseek-2/output/device/1191326 new file mode 100644 index 000000000..1d941c08f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1191326 @@ -0,0 +1,16 @@ + +QNX 4 doesn't boot on qemu >= 1.3 + + +I am using virtual machine with QNX4 operating system installed on it. I updated my qemu from version +to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I try to use any newer version +(1.3, 1.4, 1.5) QNX4 doesn't boot. I tried on windows and linux ubuntu hosts - effects are the same. + +When virtual machine boots qnx bootloader loads and starts operating system. In the next step +qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem starts when operating system +tries mount partition - an error occur and qnx stop booting procedure: + +mount -p "No bios signature in partition sector on /dev/hd0" + +I have tried install qnx from cdrom but it seems that there is the same problem. QNX installer boot from +cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next step of installation procedure. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1193 b/results/classifier/deepseek-2/output/device/1193 new file mode 100644 index 000000000..f560436b7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1193 @@ -0,0 +1,17 @@ + +io_uring / iothread regression 7.1.0 +Description of problem: +After upgrading to 7.1.0, some of my libvirt VM's failed to boot. I have narrowed down the issue to the combination of: + +- io_uring +- iothread +Steps to reproduce: +1. set up a VM with iothread and io_uring +2. try to boot and watch it "hang" +Additional information: +Here's the relevant command line from the libvirt log: +``` +-blockdev '{"driver":"file","filename":"/mnt/data/VMs/Arch-Linux-x86_64-basic.qcow2","aio":"io_uring","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 '{"driver":"virtio-blk-pci","iothread":"iothread1","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1 }' \ +``` diff --git a/results/classifier/deepseek-2/output/device/1194 b/results/classifier/deepseek-2/output/device/1194 new file mode 100644 index 000000000..4b5f7136f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1194 @@ -0,0 +1,16 @@ + +Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom" +Description of problem: +After executing the below command inside adb shell +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ + +I am getting the below error +"qemu-system-aarch64: Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom"" +Steps to reproduce: +1. adb Push qemu-system-aarch64 inside system/bin +2. Run +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ +Additional information: +Kindly help me to proceed further diff --git a/results/classifier/deepseek-2/output/device/1194954 b/results/classifier/deepseek-2/output/device/1194954 new file mode 100644 index 000000000..8ca7e71e3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1194954 @@ -0,0 +1,4 @@ + +Windows 95 guest reboots itself on qemu 1.5.0 & 1.5.50 (GIT) + +When I begin to run a Windows 95 guest on these releases of qemu, it reboots itself more times without my permission (eg. without shutting it down properly), and when I'm installing Netscape 4.08 at, for example, 46% or 75%, it still reboots itself without completing the installation of the web browser. Is this an issue of main-loop.c? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1196145 b/results/classifier/deepseek-2/output/device/1196145 new file mode 100644 index 000000000..45db9129d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1196145 @@ -0,0 +1,19 @@ + +usb-host: hostaddr=0XX is parsed as octal number + +when doing + +device_add usb-host,hostaddr=010 + +taking 010 in the format of both lsusb or udev, qemu parses an octal number and assumes hostaddr=8. +(i used a 2.0 device on the ehci.0 bus) +at least to me that is confusing. + +also: + +when adding a non-existent usb device (bogus hostaddr), the following is created according to 'usb info': + + Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device + +in usb_qdev_init(): +usb_claim_port is called but usb_device_init does not report an error and thus usb_release_port is not called. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1198350 b/results/classifier/deepseek-2/output/device/1198350 new file mode 100644 index 000000000..3a0bbd632 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1198350 @@ -0,0 +1,46 @@ + +USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument + +Host Gentoo linux 32bit +Guest Windows XP SP3 +qemu 1.4.2 and +qemu fresh get clone and build 2013-07-04 (version1.5.50) +qemu command line + +qemu-system-i386 -enable-kvm localtime -m 2047 -boot d /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb -device usb-ehci,id=ehci -usbdevice host:1493:19 + +The device I am trying to use with the guest is an interface for the Suunto Ambit 2 GPS watch which has no linux support. + +When the USB device is plugged in qemu reports to the command line: + +USBDEVFS_DISCONNECT: Invalid argument +Invalid argument + +dmesg shows + +[237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci +[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 +[237755.582781] usb 2-1.5: config 1 has no interface number 0 +[237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019 +[237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[237755.583633] usb 2-1.5: Product: Ambit +[237755.583634] usb 2-1.5: Manufacturer: Suunto +[237755.583636] usb 2-1.5: SerialNumber: CE83095110000700 +[237756.584937] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci +[237756.832658] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci +[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use + +In the windows guest Device Manager a HID device is listed but nothing else happens, no found new hardware dialog or the Suunto software (which is sitting there waiting) is not triggered as it should be. + +I have tried successfully with several other devices (flash drive, mouse, printer and video capture device). Because this device pretends to be an HID device my kernel's hid-generic driver was picking it up first until I modified hid-core.c to ignore this vendorid/productid. But still no joy. + +I'm guessing it has something to do with the the dmesg lines: + +[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 +[237755.582781] usb 2-1.5: config 1 has no interface number 0 + +But read that these warnings are not important though I don't get them for other devices. Nor do I get: + +[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use + +I've done alot of searching and I've run out of ideas. Any help would be great. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1200212 b/results/classifier/deepseek-2/output/device/1200212 new file mode 100644 index 000000000..8393ea51d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1200212 @@ -0,0 +1,15 @@ + +qemu-system-arm aborts in lsi_soft_reset + +Qemu compiled from master branch (fetched on 11th Jul 2013, qemu-system-arm -version prints "QEMU emulator version 1.5.50, Copyright (c) 2003-2008 Fabrice Bellard") running on OSX 10.6.8 crashes during Debian 7.1 netboot installation with error: "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." + +Steps to reproduce: + +1. Get kernel and initrd from http://ftp.debian.org/debian/dists/Debian7.1/main/installer-armel/20130613/images/versatile/netboot/ . +2. Create a hard disk image with qemu-img: qemu-img create -f qcow2 debian.qcow2 2G. +3. Run arm-softmmu/qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4-versatile \ + -initrd initrd-3.2.0-4-versatile-netboot -drive file=debian.qcow2,index=0,if=scsi,media=disk \ + -append "console=ttyAMA0" -nographic -net user,hostfwd=tcp:127.0.0.1:22080-:80,vlan=0 \ + -net nic,vlan=0 -smp 1,cores=4 + +The installation should proceed past partition setup and start downloading packages onto hard disk. After several tries I've never got past 31% with the package downloads before getting Abort trap with "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." message. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1207228 b/results/classifier/deepseek-2/output/device/1207228 new file mode 100644 index 000000000..876f09453 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1207228 @@ -0,0 +1,14 @@ + +Qemu (trunk code) crashes when using --soundhw all option in ioport.c + +After not building qemu (git version) for about 3 weeks, I've done it again this morning. + +With up-to-date trunk code, I got this error on start, when using --soundhw all option + +$ qemu-system-i386 -soundhw all +qemu-system-i386: /home/fred/Téléchargements/logs/qemu-git/src/qemu/ioport.c:240: portio_list_add: Assertion `pio->offset >= off_last' failed. +Abandon (core dumped) + +And if I use only soundhw with one or more options, it doesn't crash. + +Tell me what you'll need to fix this bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1219234 b/results/classifier/deepseek-2/output/device/1219234 new file mode 100644 index 000000000..0d3e6bd47 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1219234 @@ -0,0 +1,15 @@ + +-device ide-hd will assign bus with with no free units + +Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118 + +./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb +qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units +qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed. +qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized + +If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. + +This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct. + +I know -device is the 'build it yourself' approach so I understand if this is WONTFIX. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1220 b/results/classifier/deepseek-2/output/device/1220 new file mode 100644 index 000000000..0c7c9d8a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1220 @@ -0,0 +1,17 @@ + +when migrate,I unplugged the disk, why can't I force cancel the job task use qmp +Description of problem: +when migrate,I unplugged the disk,the block job will hung,but why can't I force cancel the job task +Steps to reproduce: +1.migrate a guset to another host with non-share disk (iscsi) + +2.unplug the disk + +3.then force cancel the block job task + + +but it not work,the cancle handle is not work + + + + diff --git a/results/classifier/deepseek-2/output/device/1222034 b/results/classifier/deepseek-2/output/device/1222034 new file mode 100644 index 000000000..6d84b913f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1222034 @@ -0,0 +1,20 @@ + +QEMU + SPICE + AUDIO = FAILURE + +Hello it's my first time doing this, since the major round of timer/block changes in August I have not been able to have audio working in any guest with the spice protocol. + +64 bit linux , AMD SVM, IOMMUv1 M5A99X EVO R2.0 + + +Example command line: + +qemu-system-x86_64 -m 1024 -cdrom /common/stor8/torrents/Sabayon_Linux_DAILY_x86_Xfce.iso -soundhw hda -vga qxl -spice port=5999,addr=0.0.0.0,disable-ticketing -enable-kvm + + + +Any time the guest tries to access the emulated hardware it will hang for a very long period of time and play no audio through spice. + +This issue does not happen with the 1.6.0 release. + + +If you are unable to replicate this I will go to the trouble of getting the race message that happens in the guest but I am assuming at this point that my configuration is not exotic and it should be very easy to see the issue. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1223467 b/results/classifier/deepseek-2/output/device/1223467 new file mode 100644 index 000000000..68730f60e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1223467 @@ -0,0 +1,23 @@ + +Unable to use USB as hda in Windows + +I built qemu 1.6.0 from source in MinGW (and all dependents not available with mingw-get) +The command line: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L pc-bios +or +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L pc-bios +(or the *w.exe equivalents) +reports in stderr.txt: +qemu-system-i386.exe: -hda \\.\PhysicalDrive1: Block protocol 'host_device' doesn't support the option 'filename' +qemu-system-i386.exe: -hda \\.\PhysicalDrive1: could not open disk image \\.\PhysicalDrive1: Invalid argument + +I have also found this bug in 1.5 but not in 1.4 + +Some Help: +The code in Qemu is a bit beyond me at 1am, but I was able to determine the root cause seems to be that block.c is becoming confused about referring to a file but not having a file name. I have been able to work around this by changing line 860 of block.c from: "if (qdict_size(options) != 0) {" to "if (qdict_size(options) != 0 && !is_windows_drive(filename)) {" + +But I don't think this is a good solution (it is assuming that nothing else could be wrong), and I can't be sure that I'm not masking some real issue. + +FWIW; Build is on XP, but execution is on Win7. + +Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1223477 b/results/classifier/deepseek-2/output/device/1223477 new file mode 100644 index 000000000..48b1cf6cf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1223477 @@ -0,0 +1,31 @@ + +Unable to read USB filesystems with EFI Bios + +Preamble and version: +With respect to my fix for using USB devices as -hda mentioned in bug 1223467 +Using Qemu 1.6.0 with OVMF r11337-alpha (Qemu is built from Source, OVMF is pre built) + +Command: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 + +Fault: +The EFI Shell is able to detect the hda block device, report its capacity and usage; +but it sees no files or directories on the device. + +Similar commands: +I have also seen the same with +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 +and +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-x64 + +Investigations: +I tried very small (500MB) and very large (32 GB) USB devices with no difference. +I re-built several versions of Qemu in an identical build environment, and found that: +Qemu 1.2.2 and before, all the above commands work and the EFI boot loader is called. +Qemu 1.3.0-rc0 and after do not work and the USB device appears blank. +I'm reporting the bug here and not with OVMF because older versions of Qemu with the same OVMF bios work perfectly. + +In all cases using '-L pc-bios' works perfectly. +In all cases using an image of the USB device works. + +Thanks \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1225187 b/results/classifier/deepseek-2/output/device/1225187 new file mode 100644 index 000000000..37eeface0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1225187 @@ -0,0 +1,13 @@ + +qemu hangs in windows 7 host with -serial pipe:windbg + +Execution line: +qemu-system-i386.exe -m 512 c:\Disks\Qemu_XP_en.vhd -serial pipe:windbg + +It waits for the pipe. +Execute windbg +c:\WINDDK\7600.16385.1\Debuggers\windbg.exe -k com:pipe,port=\\.\pipe\windbg,resets=0,reconnect + +GUI black screen shown. QEMU hangs. + +qemu v1.5.3 (c0b1a7e207094dba0b37a892b41fe4cab3195e44). MinGW built. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1226 b/results/classifier/deepseek-2/output/device/1226 new file mode 100644 index 000000000..94e0b3778 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1226 @@ -0,0 +1,26 @@ + +wheel-axis=false does not get applied at hardware init stage +Description of problem: +`-device virtio-tablet,id=touch0,wheel-axis=false` does not get applied at initalization stage, causing android to see it and treat the device as a pointer instead of a tablet. it seems to look for the prop at init stage, I have verified that this is an issue by fixing it with a quick hack below. ~~setting `-device virtio-tablet,id=touch0,wheel-axis=true` will still work fine and cause android to pick it up as a pointer again~~ + + +EDIT: It does not seem to work actually. if set when the default is set to false +Steps to reproduce: +1. Boot android based VM +2. test an app that forces touch only over pointer +Additional information: +``` +diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c +index a7a244a95d..3175f9c7d5 100644 +--- a/hw/input/virtio-input-hid.c ++++ b/hw/input/virtio-input-hid.c +@@ -477,7 +477,7 @@ static struct virtio_input_config virtio_tablet_config_v2[] = { + }; + + static Property virtio_tablet_properties[] = { +- DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true), ++ DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, false), + DEFINE_PROP_END_OF_LIST(), + }; + +``` diff --git a/results/classifier/deepseek-2/output/device/1228 b/results/classifier/deepseek-2/output/device/1228 new file mode 100644 index 000000000..83ac503a8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1228 @@ -0,0 +1,44 @@ + +-display curses only recognizes escape characters if pressed very quickly +Description of problem: +The system start and runs perfectly fine, but when I try to exit the escape commands does not seem to work. + +I have tried all the ones from here: +https://www.qemu.org/docs/master/system/keys.html +https://www.qemu.org/docs/master/system/mux-chardev.html + +When using the graphical display, the escape characters works as expected but when using -display curses, they do not. +Steps to reproduce: +1. Start qemu with the command provided +2. Try to exit using ctrl + x a - Not working +3. Try to exit using alt + 2 - Not working + +The same issues occurs when running qemu on a Linux machine (Ubunt) via Visual Studio Code / ssh. + +I'm guessing this is a macOS specific issue or maybe something to do with my Locale (sv-SE). +Additional information: +Linux 0.01 build: +https://github.com/mariuz/linux-0.01 + +**Tests using showkey** + +Alt + 2 from mobile ssh client (Terminus) -> Ubuntu machine +``` +^[2 27 0033 0x1b + 50 0062 0x32 +``` + +Option + 2 from macOS Terminal + ssh -> Ubuntu machine +``` +@ 64 0100 0x40 +``` + +Esc + 2 from macOS Terminal + ssh -> Ubuntu machine +``` +^[ 27 0033 0x1b +2 50 0062 0x32 +``` + +**Update** + +It seems to work if I press ESC + 2 at exactly the same time. diff --git a/results/classifier/deepseek-2/output/device/1230232 b/results/classifier/deepseek-2/output/device/1230232 new file mode 100644 index 000000000..5b4b461f1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1230232 @@ -0,0 +1,34 @@ + +mac99 does not find mac os x 10.4 dvd + +Hi there, + +I've compiled qemu 1.6.0 and ripped my Mac OS X 10.4 dvd to iso format. +Now I'm trying to get qemu to boot the dvd and install the OS with: + +qemu-system-ppc64 -M mac99 -m 256 -cdrom ./tiger.iso -boot d -sdl -display sdl -net nic -net user -prom-env 'boot-args=-v' -cpu G4 -hda ./tiger.img + +It shows the grey apple logo for a few seconds and then I get the following boot prompt: +------------------------------------------------- +standard timeslicing quantum is 10000 us +vm_page_bootstrap: 60198 free pages +mig_table_max_displ = 70 +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. + +using 655 buffer headers and 655 cluster IO buffer headers +ApplePlatformExpert::getGMTTimeOfDay can not provide time of day RTC did not show up +Security auditing service present +BSM auditing present +disabled +rooting via boot-uuid from /chosen: 8ABB5AFF-FC7A-310A-9BFE-8A263F654562 +Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResource +Match</key><string ID="2">boot-uuid-media</string></dict> +Still waiting for root device +Still waiting for root device +Still waiting for root device +Still waiting for root device +Still waiting for root device +------------------------------------------------- + +It keeps repeating the "Still waiting for root device" ? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1234 b/results/classifier/deepseek-2/output/device/1234 new file mode 100644 index 000000000..c7351fcd4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1234 @@ -0,0 +1,4 @@ + +Migration: Device state not saved for msmouse/chardevs +Additional information: +This missing feature was discovered while fixing msmouse here: https://patchew.org/QEMU/20220908173120.16779-1-arwed.meyer@gmx.de/20220908173120.16779-2-arwed.meyer@gmx.de/ diff --git a/results/classifier/deepseek-2/output/device/1237 b/results/classifier/deepseek-2/output/device/1237 new file mode 100644 index 000000000..5ccfd4df6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1237 @@ -0,0 +1,2 @@ + +after OS upgrade usb-redir connection broken during migration and qemu-kvm: terminating on signal 15 diff --git a/results/classifier/deepseek-2/output/device/1237625 b/results/classifier/deepseek-2/output/device/1237625 new file mode 100644 index 000000000..9ff3d0402 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1237625 @@ -0,0 +1,49 @@ + +Cannot read serial from /sys/bus/usb/devices/ + +After an update to qemu 1.6 I can't start any of my images. Qemu always crashs. I tried it with root and as a normal user... Here are some log entries I get: + +Type: Warning Num: 85 +Date: 2013.10.09 23:48:46 549 +Sender: bool System_Info::Scan_USB_Sys( QList<VM_USB> &list ) +Message: Cannot read serial from /sys/bus/usb/devices/ + +Type: Debug Num: 86 +Date: 2013.10.09 23:48:46 553 +Sender: void Virtual_Machine::QEMU_Started() +Message: QEMU Start + +Type: Debug Num: 87 +Date: 2013.10.09 23:48:46 554 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: Begin + +Type: Debug Num: 88 +Date: 2013.10.09 23:48:46 554 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: End + +Type: Debug Num: 89 +Date: 2013.10.09 23:48:46 575 +Sender: void Virtual_Machine::QEMU_Started() +Message: emit Loading_Complete() + +Type: Debug Num: 90 +Date: 2013.10.09 23:48:47 470 +Sender: void Virtual_Machine::QEMU_Finished( int exitCode, QProcess::ExitStatus exitStatus ) +Message: QEMU Finished + +Type: Debug Num: 91 +Date: 2013.10.09 23:48:47 470 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: Begin + +Type: Debug Num: 92 +Date: 2013.10.09 23:48:47 470 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: End + +Type: Error Num: 93 +Date: 2013.10.09 23:48:47 498 +Sender: QEMU Crashed! +Message: \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/124 b/results/classifier/deepseek-2/output/device/124 new file mode 100644 index 000000000..56deeaa47 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/124 @@ -0,0 +1,2 @@ + +SIGSEGV when reading ARM GIC registers through GDB stub diff --git a/results/classifier/deepseek-2/output/device/1242765 b/results/classifier/deepseek-2/output/device/1242765 new file mode 100644 index 000000000..2431ee923 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1242765 @@ -0,0 +1,70 @@ + +USB passthrough to Windows 7 guest fails with error -110, hangs + +Description of problem: + +Using a Sandisk Cruzer Fit 16GB USB thumb drive. +Using virt-manager on Fedora 19 host, and Windows 7 32 bit guest. + +I set up a USB2 controller on Windows 7 guest in virt-manager. Windows sees the USB drive and can open the file manager and correctly show the files. I can copy a file from the thumb drive to the Fedora desktop, and then play the file on the desktop. However, any attempt to open a file directly on the thumb drive (example, play an MP3 using Windows Media Player) results in guest hang and host kernel messages: + + +Oct 19 21:15:35 localhost kernel: [187592.977839] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:40 localhost kernel: [187598.065274] usb 1-1.3: device descriptor read/all, error -110 +Oct 19 21:15:40 localhost kernel: [187598.138167] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:56 localhost kernel: [187613.218119] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.399275] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.573355] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:16 localhost kernel: [187633.587778] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.702244] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.876201] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:26 localhost kernel: [187643.890642] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.005071] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.106188] usb 1-1.3: USB disconnect, device number 13 +Oct 19 21:16:31 localhost kernel: [187649.178969] usb 1-1.3: new high-speed USB device number 14 using ehci-pci +Oct 19 21:16:47 localhost kernel: [187664.258945] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.440092] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.614194] usb 1-1.3: new high-speed USB device number 15 using ehci-pci +Oct 19 21:17:17 localhost kernel: [187694.694148] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187709.875297] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187710.049386] usb 1-1.3: new high-speed USB device number 16 using ehci-pci +Oct 19 21:17:37 localhost kernel: [187715.063803] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:17:41 localhost kernel: [187719.005453] usb 1-1.3: device descriptor read/8, error -71 + +After that -71 error, the thumb drive completely disappears from the host, as if it is powered down. + +I read that -110 is supposedly a power issue. I can play media files directly from the thumb drive on the host, so the power seems fine on the host. + + +How reproducible: +always + + +Steps to reproduce: +1. use virt-manager, create a Windows 7 32 bit guest +2. in virt-manager, set Controller USB to USB2 +3. on host, insert Sandisk Cruser Fit thumb drive FAT32 format, with an MP3 file on it +4. in virt-manager, add a USB passthrough device and assign it to thumb drive +5. boot Windows 7 guest +6. verify that Windows 7 can see the thumb drive +7. use Windows Media Player to play MP3 + +Actual results: +guest hangs, then host powers off thumb drive + +Expected results: +The MP3 file should play :) + + +Additional info: + +Fedora 19 + +Installed Packages +qemu-common.x86_64 2:1.4.2-11.fc19 @updates +qemu-guest-agent.x86_64 2:1.4.2-11.fc19 @updates +qemu-img.x86_64 2:1.4.2-11.fc19 @updates +qemu-kvm.x86_64 2:1.4.2-11.fc19 @updates +qemu-system-x86.x86_64 2:1.4.2-11.fc19 @updates +virt-manager.noarch 0.10.0-3.fc19 @updates +kernel.x86_64 3.11.1-200.fc19 @updates \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1248469 b/results/classifier/deepseek-2/output/device/1248469 new file mode 100644 index 000000000..8a37a402d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1248469 @@ -0,0 +1,4 @@ + +qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit + +boot windows 7 32bit guest with -readconfig q35-chipset.cfg paramter,in guest's device manager,there's a device 3420 not work,it shows error "This device cannot find enough free resources that it can use(code 12)". \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1250 b/results/classifier/deepseek-2/output/device/1250 new file mode 100644 index 000000000..fe78e6c84 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1250 @@ -0,0 +1,4 @@ + +[RFE] on windows, attach any storport disk directly, not just physicaldrives +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1256122 b/results/classifier/deepseek-2/output/device/1256122 new file mode 100644 index 000000000..175f44344 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1256122 @@ -0,0 +1,23 @@ + +vfio bug with all no VGA card + +Hello, + +I whant to report to you a realy big bug. + +vfio passthrough work only with VGA card ! When i try to use vfio with any other PCI or PCI-E card it does not work. + +When i use vfio for VGA i can reboot (or shutdown and start again) my VM with out problem, but for any other PCI card the VM refuse to reboot. + +In dmesg i have this error : + +dmar: DRHD: handling fault status reg 2 +dmar: DMAR:[DMA Read] Request device [xx:xx.x] fault addr 2affde000 +DMAR:[fault reason 06] PTE Read access is not set + +and some time the same but for Write and not Read. + +I found a kind of work around but it's ugly. Just detach your devices from vfio, re-atach to his normal driver and bind again to vfio. + +For information i use an Asrock Z87 Extrem 6 with a CoreI5 4570S +My kernel is 3.12 and Qemu is 1.7-rc0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1257334 b/results/classifier/deepseek-2/output/device/1257334 new file mode 100644 index 000000000..463091c21 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1257334 @@ -0,0 +1,4 @@ + +diffuse handling of image creation from another path + +see attachement! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1267520 b/results/classifier/deepseek-2/output/device/1267520 new file mode 100644 index 000000000..2ba4176ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1267520 @@ -0,0 +1,6 @@ + +Keyboard input not working when the "-k en-us" argument is specified. + +This bug occurs on qemu compiled with i386_softmmu and x86-64_softmmu on linux kernel 3.5.0. +Whenever I run qemu (both i386 and x86_64) to use the en-us language (even though it is the default), I get "Warning: no scancode found for keysym X" (X is an integer). +In the disk image I need qemu to run, I had a shell set up. The shell doesn't register keyboard input when the '-k en-us' command line argument is set when running qemu. I did not have this problem with earlier versions of qemu. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1268596 b/results/classifier/deepseek-2/output/device/1268596 new file mode 100644 index 000000000..651822943 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1268596 @@ -0,0 +1,25 @@ + +Compilation Error: hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function + +Qemu git-cloned from mo. 13.01.14 (ca. 13:00 GMT), Version 1.7.50 + + +#git clone git://git.qemu-project.org/qemu.git +# cd qemu; git submodule update --init dtc +#./configure --disable-xen --enable-kvm +...No Errors... + +#CC="ccache gcc" make -j8 +.... + GEN qemu.1 + Signing optionrom/kvmvapic.bin + GEN qemu-img.1 + CC qapi-types.o +hw/virtio/dataplane/vring.c: In function ‘vring_pop’: +hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function [-Werror=uninitialized] +cc1: all warnings being treated as errors +make: *** [hw/virtio/dataplane/vring.o] Error 1 +make: *** Waiting for unfinished jobs.... + + +Thx. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1268671 b/results/classifier/deepseek-2/output/device/1268671 new file mode 100644 index 000000000..3d0ec29ea --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1268671 @@ -0,0 +1,45 @@ + +CentOS guest crashing due to assertion failure in qemu-char.c + +Here is the log in /var/log/libvirt/qemu/centos_heavy.log + +qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/qemu-char.c:630: io_watch_poll_finalize: Assertion `iwp->src == ((void *)0)' failed. +2014-01-13 16:50:31.576+0000: shutting down + +The code it's failing the assertion on has an interesting comment: + + static void io_watch_poll_finalize(GSource *source) + { + /* Due to a glib bug, removing the last reference to a source + * inside a finalize callback causes recursive locking (and a + * deadlock). This is not a problem inside other callbacks, + * including dispatch callbacks, so we call io_remove_watch_poll + * to remove this source. A t this point, iwp->src must + * be NULL, or we would leak it. + * + * This would be solved much more elegantly by child sources, + * but we support older glib versions that do not have them. + */ + IOWatchPoll *iwp = io_watch_poll_from_source(source); + assert(iwp->src == NULL); + } + +------ +CPU Info: + +http://pastebin.com/U7MrzFxK + +-------- + +Relevant RPM versions: + +qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64 +libvirt-0.10.2-29.el6_5.2.x86_64 + +-------- + +Domain config: + +http://pastebin.com/Nf2VsER8 + +(Note the use of the vmchannels; I believe this is playing a part in this crash) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1269628 b/results/classifier/deepseek-2/output/device/1269628 new file mode 100644 index 000000000..e7a6eb85c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1269628 @@ -0,0 +1,6 @@ + +Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation + +In order to allow windows guests (and soon, linux guests) which are TCG OPAL 2 aware to perform disk encryption in a native fashion with hardware acceleration, please add TCG OPAL 2 emulation to the VIRTIO driver. + +Encryption should occur at the host level using any cryptographic facilities available to the host, for example AES-NI, Cryptography Hardware, underlying block device cryptography support where available or any other cryptography facility that may be developed and implemented in the future. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1276879 b/results/classifier/deepseek-2/output/device/1276879 new file mode 100644 index 000000000..c8c1dbb94 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1276879 @@ -0,0 +1,17 @@ + +lots of dma command 10, 14 not supported + +Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. +In the terminal that started QEMU, there are a lot of + dma: command 10 not supported +and + dma: command 14 not supported +messages. When the installation of NeXTSTEP gets to +'preparing disk for nextstep installation', there are a lot +of messages that ATA command c5 failed and other info. +The result is a failed installation. + +Is this a bug in QEMU? Is there a workaround, e.g. by +disabling DMA altogether? + +thank you \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1280521 b/results/classifier/deepseek-2/output/device/1280521 new file mode 100644 index 000000000..dac9c108c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1280521 @@ -0,0 +1,4 @@ + +Plan 9 can't use GUI well emulating a RTL8139 card + +The OS Plan 9 from Bell Labs runs fine in QEMU/KVM for the most part buy is unable to boot its GUI when emulating a RTL8139 WiFi card. I hear someone was able to get it working under a Windows XP host but I can't seem to do it under a Gentoo host. If you have any idea what may be doing this I would love to hear it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1284 b/results/classifier/deepseek-2/output/device/1284 new file mode 100644 index 000000000..054788250 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1284 @@ -0,0 +1,15 @@ + +macOS QXL VGA not available +Description of problem: +``` +qemu-system-aarch64: QXL VGA not available +``` +``` +qemu-system-aarch64: -device qxl-vga: 'qxl-vga' is not a valid device model name +``` +Steps to reproduce: +1. Build QEMU on macOS with SPICE support (meson) +2. Run commands listed above +3. Observe QXL not working +Additional information: +I'm wiring up QEMU SPICE support on Darwin for Nixpkgs. The same issue can be observed in macports qemu builds with spice. Could this be a packaging issue? diff --git a/results/classifier/deepseek-2/output/device/1284874 b/results/classifier/deepseek-2/output/device/1284874 new file mode 100644 index 000000000..480cd0b64 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1284874 @@ -0,0 +1,31 @@ + +Guest hangs during option rom loading with certain cards + +With a Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet card, device assignment does not work. The guest hangs during option rom execution. Moreover, if an attempt is made to quit qemu when the guest is in the hung state, the card gets into an inoperable state. Only a powercycle then, restores the card back into working order, just unloading/loading the driver does not help. + +Qemu version - 1.6.2 or current master +Distribution - FC19 +Kernel Version - 3.12.9-201.fc19.x86_64 + +Details of the card - + # ethtool -i p2p2 +driver: bnx2x +version: 1.78.17-0 +firmware-version: bc 7.8.22 +bus-info: 0000:08:00.1 +supports-statistics: yes +supports-test: yes +supports-eeprom-access: yes +supports-register-dump: yes +supports-priv-flags: yes + +The output of lspci when the card is broken - +03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev ff) (prog-if ff) + !!! Unknown header type 7f + Kernel driver in use: bnx2x +00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + +I will post if I get a chance to try out a newer than 7.8.22 for the option rom and see if this issue is fixed. However it appears we need to have a unified approach to automatically avoid loading the rom based on certain criteria. Manually, looking out for fixes to firmware and hard coding decisions based on those is neither desirable nor easy to maintain. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1288 b/results/classifier/deepseek-2/output/device/1288 new file mode 100644 index 000000000..37ac4c0d5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1288 @@ -0,0 +1,10 @@ + +GPU passing through guest crashes +Description of problem: +First and foremost, I don't know if this is a QEMU, KVM or GPU driver issue. +I began emailing libvirt project and they advised me to contact you, then KVM and then GPU driver developer(NVIDIA). +Host is crashing from time to time. I have guest's kernel dumps(~2GB each). +Steps to reproduce: +Unfortunately, I don't have steps to reproduce. +Additional information: +I'm aware I'm not running the latest qmeu version but I'm willing to install developer version and try to reproduce or test patch if developer requires it. diff --git a/results/classifier/deepseek-2/output/device/1292037 b/results/classifier/deepseek-2/output/device/1292037 new file mode 100644 index 000000000..8dca55437 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1292037 @@ -0,0 +1,15 @@ + +Solaris 10 x86 guest crashes qemu with -icount 1 option + +Commit: f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git + +Solaris image: Solaris 10 x86 (32 bit) + +command: ./i386-softmmu/qemu-system-i386 -hda <image-file> -m 2G -icount 1 -monitor stdio + +Crashes saying: +qemu: Fatal: Raised interrupt while not in I/O function + +Host: +ubuntu x86_64 3.2.0-56 generic +intel xeon E5649 @ 2.53GHz \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1294 b/results/classifier/deepseek-2/output/device/1294 new file mode 100644 index 000000000..64ba4532a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1294 @@ -0,0 +1,2 @@ + +pflash size check appears to be incompatible with OVMF on x86 diff --git a/results/classifier/deepseek-2/output/device/1295587 b/results/classifier/deepseek-2/output/device/1295587 new file mode 100644 index 000000000..38d781474 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1295587 @@ -0,0 +1,20 @@ + +Temporal freeze and slowdown while using emulated sb16 + +I have been carrying around this bug since previous versions and on different machines: When I use the -soundhw sb16 option, while playing any sound on the virtual machine it freezes and loops the last bit of such sound effect for 1-2 minutes, then goes back to normal speed. + +Console shows: + + sb16: warning: command 0xf9,1 is not truly understood yet + sb16: warning: command 0xf9,1 is not truly understood yet +(...) +main-loop: WARNING: I/O thread spun for 1000 iterations + +-One of my emulated machines is Windows 3.11: I managed to overrun this bug by switching from the local 1.5 version of the sound blaster driver to the 1.0, although since I updated qemu it freezes that machine, so I can't test if it still works. + +I am using the 1.7.90 version, but I suffered this bug for over one year + +this bug happens anytime I use the -soundhw sb16 switch, but the full command I am using in this specific case is: + + +qemu-system-i386 -localtime -cpu pentium -m 32 -display sdl -vga cirrus -hda c.img -cdrom win95stuff.iso -net nic,model=ne2k_pci -net user -soundhw sb16 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1298 b/results/classifier/deepseek-2/output/device/1298 new file mode 100644 index 000000000..d7c21c277 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1298 @@ -0,0 +1,16 @@ + +virtio-pmem not working on microvm: virtio-pmem missing request data +Description of problem: +When using micorvm, qemu does not "connect" the memory backend mem1 with the pmem device. + +When using the first command is executed, qemu shows the following starts message: +``` +qemu-system-x86_64: virtio-pmem missing request data +``` + +and the kernel outputs following messages: +``` +[ 0.043871] nd_pmem namespace0.0: could not reserve region [mem 0x00000000-0x001fffff] +[ 0.043923] IPI shorthand broadcast: enabled +[ 0.044022] nd_pmem: probe of namespace0.0 failed with error -16 +``` diff --git a/results/classifier/deepseek-2/output/device/1300 b/results/classifier/deepseek-2/output/device/1300 new file mode 100644 index 000000000..69ba14387 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1300 @@ -0,0 +1,12 @@ + +Build failure when configuring CONFIG_VHOST_USER_FS/CONFIG_VIRTIO +Description of problem: +Attempting to configure CONFIG_VHOST_USER_FS or CONFIG_VIRTIO results in a build failure. Complete build log (with configure output) is attached. +Steps to reproduce: +1. Add `CONFIG_VIRTIO` and `CONFIG_VHOST_USER_FS` (`y` *or* `n`) to `configs/devices/x86_64-softmmu/gentoo.mak` (done via the [ebuild](https://github.com/gentoo/gentoo/blob/master/app-emulation/qemu/qemu-7.1.0.ebuild)) +2. Configure with `--with-devices-x86_64=gentoo` +3. Attempt building +Additional information: +[build.log](/uploads/72fc1284f5245d9384e521d3b1c65953/build.log) + +Reported downstream [here](https://bugs.gentoo.org/873190). diff --git a/results/classifier/deepseek-2/output/device/1306818 b/results/classifier/deepseek-2/output/device/1306818 new file mode 100644 index 000000000..d18ff66af --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1306818 @@ -0,0 +1,44 @@ + +resetting moder register in opencores_eth.c code (ethernet IP core specification code) + +Hi, I would like to report a possible error in the code qemu/hw/net/opencores_eth.c + +The corresponding data sheet : http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf + + +In the code, there is a function open_eth_moder_host_write. + +static void open_eth_moder_host_write(OpenEthState *s, uint32_t val) +{ + uint32_t set = val & ~s->regs[MODER]; + + if (set & MODER_RST) { + open_eth_reset(s); + } + + s->regs[MODER] = val; + + if (set & MODER_RXEN) { + s->rx_desc = s->regs[TX_BD_NUM]; + open_eth_notify_can_receive(s); + } + if (set & MODER_TXEN) { + s->tx_desc = 0; + open_eth_check_start_xmit(s); + } +} + +This piece of code is executed when MODER (Mode Register) resister is command to updated to ‘val’. + +In case of reset, as you can see, if the MODER_RST bit (0x800) bit is set && the old MODER_RST bit (0x800) of MODER register is clear, the code falls into the if(set & MODER_RST) branch. Then, it calls open_eth_reset(s), which does “s->regs[MODER] = 0xa000;”. Now, the MODER register is reset to 0xa000. Page 9 of the data sheet (http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf) specifies the reset value of the moder is 0000A000h. So far, the code works fine. +Then, the open_eth_moder_host_write function does not end but executes but executes “s->regs[MODER] = val;” line. Now, the MODER register is not 0xa000 any more. +In fact, since the MODER_RST bit of ‘val’ is 1, now the MODER_RST bit of the MODER register becomes 1 as well. Suppose one somehow calls this open_eth_moder_host_write again with val = MODER_RST with purpose of resetting again. Since the MODER_RST bit is 1, (set = val & ~s->regs[MODER]) & MODER_RST is zero. So after this, resetting again is not possible. + +Hence, I doubt the function’s correctness here. I think it could be better if the function changes to : + + if (set & MODER_RST) { + open_eth_reset(s); + return; + } + +Please let me know if I am correct. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1307281 b/results/classifier/deepseek-2/output/device/1307281 new file mode 100644 index 000000000..2ba6a7d88 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1307281 @@ -0,0 +1,11 @@ + +qemu crash with assertion in usb_packet_complete_one + +qemu release verison: 1.7.1 +guest os : win7 32bits +qemu cmdline: +/usr/bin/qemu-system-x86_64 -name hch_test -S -machine pc-i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=12,threads=2 -uuid 5ad433c9-e490-42f3-b365-c30d756fbd70 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hch_test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/opt/cvm/hch_test/hch_test.inst,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/data/hugedisk/hch_test/hch_test_share.add,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f2:05:b7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/hch_test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -spice port=5903,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0 + +i use spice to connect to vm and utilize usb redirection. i plug a u-disk into a remote computer and start copy a big file (3G+) to u-disk and qemu was crashed in the middle of the transmission. + +i check the qemu log and found this log: "qemu-system-x86_64: hw/usb/core.c:438: usb_packet_complete_one: Assertion `p->stream || ((&ep->queue)->tqh_first) == p' failed". this crash can be reproduced every time. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1311 b/results/classifier/deepseek-2/output/device/1311 new file mode 100644 index 000000000..eacffe78b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1311 @@ -0,0 +1,2 @@ + +riscv-qemu can't record interrupt diff --git a/results/classifier/deepseek-2/output/device/1314857 b/results/classifier/deepseek-2/output/device/1314857 new file mode 100644 index 000000000..bc359352d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1314857 @@ -0,0 +1,20 @@ + +seg fault in ivshmem when using ioeventfd=on + +When launching qemu with the ivshmem device and the nahanni guest server there is segmentation fault in the setup_ioeventfds function of ivshmem.c. If the ioeventfd=on flag is set the pci_ivshmem_init will call setup_ioeventfds at line 668. This function relies on the 'peers' member of the server info which is not allocated until line 669. + +To reproduce you will need the nahanni guest server code. The driver code is not needed. You will also need a qcow2 or other bootable image to use for launching qemu. The error occurs before the actual image launch. + +Start the nahanni ivshmem server with a small global memory space ( although the bug is not allocation specific ) +ivshmem -m 1 -n 2 -p /tmp/ivshmem_socket + +Next launch qemu with initialization for the ivshmem device. +qemu-system-x86_64 -hda test_iso.qcow2 -localtime -boot c -chardev socket,path="/tmp/ivshmem_socket",id=ivshmem_socket -device ivshmem,chardev=ivshmem_socket,size=1,ioeventfd=on + +If gdb is used the following error is recorded: +Program received signal SIGSEGV, Segmentation fault. +0x000055555579dd52 in setup_ioeventfds (s=0x555556619580) + at /home/genes/work/ubuntu/qemu-kvm-1.0+noroms/hw/ivshmem.c:367 +367 for (j = 0; j < s->peers[i].nb_eventfds; j++) { +(gdb) print s->peers +$2 = (Peer *) 0x0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1318 b/results/classifier/deepseek-2/output/device/1318 new file mode 100644 index 000000000..7581c4404 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1318 @@ -0,0 +1,20 @@ + +vsock device fails with "qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)" when queue_reset=true +Description of problem: +Immediately after guest vsock driver initialize, qemu prints error messages. I'm not able to connect to the guest with vsock: + +``` +[ 0.654463] Run /init as init process +[ 0.679778] NET: Registered PF_VSOCK protocol family +qemu-system-x86_64: vhost_set_features failed: Operation not supported (95) +qemu-system-x86_64: Error starting vhost: 95 +ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 +# +``` +Steps to reproduce: +1. Clone `git://passt.top/passt` +2. In `passt/test`, run `make mbuto.img` +3. Run `qemu-system-x86_64 -enable-kvm -m 2048 -kernel KERNEL -initrd mbuto.img -nographic -serial stdio -nodefaults -append "console=ttyS0" -device vhost-vsock-pci,guest-cid=31415,queue_reset=true` replacing KERNEL with the host kernel image. +Additional information: +- Problem goes away if `queue_reset=false`, which means it goes away with default options prior to `69e1c14aa222` ("virtio: core: vq reset feature negotation support") +- Occurs both with and without KVM diff --git a/results/classifier/deepseek-2/output/device/1320360 b/results/classifier/deepseek-2/output/device/1320360 new file mode 100644 index 000000000..9db58e311 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1320360 @@ -0,0 +1,18 @@ + +usb passthrough not working anymore + +Hi, + +I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but starting with qemu 2.0.0 passthrough stop working. I can still add the usb device but when I start the guest following message appears: + +"unable to execute QEMU command 'device_add': 'usb-host' is not a valid device model name" + +Then the guest will not start. + +I try it with different usb devices (iphone, stick, hdd), always the same error. + +Are there any news / hints about this ? + +Regards + +Martin \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1321684 b/results/classifier/deepseek-2/output/device/1321684 new file mode 100644 index 000000000..2d8ecb847 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1321684 @@ -0,0 +1,47 @@ + +block_stream command stalls + +block_stream command stalls near finishing. +I tried 1.7.1, 2.0.0 and the master versions. All of them stalled. +But the 1.1.2 could finish the job. + +Here is how to reproduce it: + +$ sudo $QEMU \ +-enable-kvm -cpu qemu64 -m 1024 \ +-monitor stdio \ +-drive file=./i1,if=none,id=drive_0,cache=none,aio=native -device virtio-blk-pci,drive=drive_0,bus=pci.0,addr=0x5 \ + +QEMU 2.0.50 monitor - type 'help' for more information +(qemu) VNC server running on `127.0.0.1:5900' +(qemu) snapshot_blkdev drive_0 s1 +Formatting 's1', fmt=qcow2 size=26843545600 backing_file='./i1' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off +(qemu) block_stream drive_0 +(qemu) info block-jobs +Streaming device drive_0: Completed 400818176 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 904396800 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 23401070592 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 26513768448 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) main-loop: WARNING: I/O thread spun for 1000 iterations +info block-jobs +Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed limit 0 bytes/s + +#### here, the progress stopped at 26841513984 #### + + +$ qemu-img info i1 +image: i1 +file format: qcow2 +virtual size: 25G (26843545600 bytes) +disk size: 1.0G +cluster_size: 2097152 +Format specific information: + compat: 1.1 + lazy refcounts: false \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1326 b/results/classifier/deepseek-2/output/device/1326 new file mode 100644 index 000000000..9d874fc57 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1326 @@ -0,0 +1,59 @@ + +qemu-system-aarch64: piix3 or ehci usb controller and usb kbd don't work +Description of problem: +the usb device initialization failed in vm, and can not input in vnc console + +message for virtual machine: + +``` +root@localhost ~]# dmesg | grep -i usb +[ 0.925798] ACPI: bus type USB registered +[ 0.927204] usbcore: registered new interface driver usbfs +[ 0.928980] usbcore: registered new interface driver hub +[ 0.930746] usbcore: registered new device driver usb +[ 2.329004] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 2.332659] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 2.336069] uhci_hcd: USB Universal Host Controller Interface driver +[ 2.342659] uhci_hcd 0000:02:02.0: new USB bus registered, assigned bus number 1 +[ 2.348905] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.18 +[ 2.352268] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 2.354598] usb usb1: Product: UHCI Host Controller +[ 2.356194] usb usb1: Manufacturer: Linux 4.18.0-305.3.1.el8.aarch64 uhci_hcd +[ 2.358474] usb usb1: SerialNumber: 0000:02:02.0 +[ 2.360228] hub 1-0:1.0: USB hub found +[ 2.363347] usbcore: registered new interface driver usbserial_generic +[ 2.365456] usbserial: USB Serial support registered for generic +[ 2.384154] usbcore: registered new interface driver usbhid +[ 2.385962] usbhid: USB HID core driver +[ 2.730277] usb 1-1: new full-speed USB device number 2 using uhci_hcd +[ 18.509908] usb 1-1: device descriptor read/64, error -110 +[ 34.509908] usb 1-1: device descriptor read/64, error -110 +[ 34.779906] usb 1-1: new full-speed USB device number 3 using uhci_hcd +[ 50.509910] usb 1-1: device descriptor read/64, error -110 +[ 66.509907] usb 1-1: device descriptor read/64, error -110 +[ 66.629982] usb usb1-port1: attempt power cycle +[ 67.119904] usb 1-1: new full-speed USB device number 4 using uhci_hcd +[ 78.079921] usb 1-1: device not accepting address 4, error -110 +[ 78.229962] usb 1-1: new full-speed USB device number 5 using uhci_hcd +[ 89.079917] usb 1-1: device not accepting address 5, error -110 +[ 89.082006] usb usb1-port1: unable to enumerate USB device +[ 89.229908] usb 1-2: new full-speed USB device number 6 using uhci_hcd +[ 105.009910] usb 1-2: device descriptor read/64, error -110 +[ 121.009910] usb 1-2: device descriptor read/64, error -110 +[ 121.279907] usb 1-2: new full-speed USB device number 7 using uhci_hcd +[ 137.009910] usb 1-2: device descriptor read/64, error -110 +[ 153.009925] usb 1-2: device descriptor read/64, error -110 +[ 153.129984] usb usb1-port2: attempt power cycle +[ 153.619917] usb 1-2: new full-speed USB device number 8 using uhci_hcd +[ 164.579912] usb 1-2: device not accepting address 8, error -110 +[ 164.729913] usb 1-2: new full-speed USB device number 9 using uhci_hcd +[ 175.329921] usb 1-2: device not accepting address 9, error -110 +[ 175.331973] usb usb1-port2: unable to enumerate USB device +``` +Steps to reproduce: +1. ./configure +2. make -j60 +3.virsh create vm.xml +[vm.xml](/uploads/9f946b3637f68c9cd029dfb650f5bd57/vm.xml) +Additional information: +the commit "1c2cb7e0b3" cause the problem, but i don't know the reason diff --git a/results/classifier/deepseek-2/output/device/133 b/results/classifier/deepseek-2/output/device/133 new file mode 100644 index 000000000..e2b3e6e90 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/133 @@ -0,0 +1,2 @@ + +Chardev websocket might not support pasting more than a few chars diff --git a/results/classifier/deepseek-2/output/device/1333 b/results/classifier/deepseek-2/output/device/1333 new file mode 100644 index 000000000..9cba570e3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1333 @@ -0,0 +1,12 @@ + +vhost-user-test qos-test fails on s390x host +Description of problem: +The qos-test is now definitely failing in the ubuntu-20.04-s390x-all CI job. See https://gitlab.com/qemu-project/qemu/-/jobs/3363173491 , then click on "Complete Raw" to see the full log. Quoting: + +``` +ERROR:../tests/qtest/vhost-user-test.c:248:wait_for_fds: assertion failed: (s->fds_num) +** +ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child process (/arm/virt/virtio-mmio/virtio-bus/vhost-user-gpio-device/vhost-user-gpio/vhost-user-gpio-tests/read-guest-mem/memfile/subprocess [274051]) failed unexpectedly + +(test program exited with status code -6) +``` diff --git a/results/classifier/deepseek-2/output/device/1333216 b/results/classifier/deepseek-2/output/device/1333216 new file mode 100644 index 000000000..502061970 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1333216 @@ -0,0 +1,37 @@ + +Xen 4.4 with qemu 1.6.2 VGA passthru NVIDIA + +Hi! + +Please, give me an advice. + +I try use VGA passthough NVidia k40 on SuperMicro Server, but server is having error. +My Xen is using qemu (a9e8aeb3755bccb7b51174adcf4a3fc427e0d147)2.0.0 + +My VirtualMachine is have config: +device_model_version = "qemu-xen" +device_model_override = "/opt/sources/qemu-a9e8aeb/x86_64-softmmu/qemu-system-x86_64" + +When I start VM: +dmesg +[ 0.906181] pci 0000:00:05.0: BAR 1: can't assign mem pref (size 0x100000000) +[ 0.906187] pci 0000:00:05.0: BAR 1: trying firmware assignment [mem 0x100000000-0x1ffffffff 64bit pref] +[ 0.906193] pci 0000:00:05.0: BAR 1: assigned [mem 0x100000000-0x1ffffffff 64bit pref] +and lspci -s 00:05.0 -vvv + Region 0: Memory at 85000000 (32-bit, non-prefetchable) [size=16M] + Region 1: Memory at 100000000 (64-bit, prefetchable) [size=4G] + Region 3: Memory at 82000000 (64-bit, prefetchable) [size=32M] + +Why? + +This is message in DOM0: +lspci -s 03:00.0 -vvv +.... +Region 0: Memory at de000000 (32-bit, non-prefetchable) [size=16M] +Region 1: Memory at 5800000000 (64-bit, prefetchable) [size=16G] +Region 3: Memory at 5c00000000 (64-bit, prefetchable) [size=32M] + + +Why Qemu don`t mapping BAR1? +Thanks! +Regards! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1334397 b/results/classifier/deepseek-2/output/device/1334397 new file mode 100644 index 000000000..349d8fa11 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1334397 @@ -0,0 +1,9 @@ + +cmos RTC alarms no longer wake system from suspend + +Running QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), booting Linux kernels with qemu-system-x86_64 and qemu-system-i386, I no longer see the system resume from suspend when an RTC alarm is set. + +My simple test application can be found here: +https://github.com/johnstultz-work/timetests/blob/master/alarmtimer-suspend.c + +Previously this worked w/ QEMU 1.5 (bascially up until I upgraded from Ubuntu 13.10 to Ubuntu 14.04, which came with 2.0). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1336123 b/results/classifier/deepseek-2/output/device/1336123 new file mode 100644 index 000000000..86bbfff7e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1336123 @@ -0,0 +1,12 @@ + +bad switch, segfault in hw/pci-host/bonito.c bonito_readl + +http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci-host/bonito.c;h=56292adb03cd1a9873c2c9e5a0b2978fd0572214;hb=master#l301 + +The switch statement is error-prone, since two branches return the same result. + +Segfault reproducing steps: +1. make a Linux kernel(for example 3.16.0-rc2) with fuloong2e_defconfig +2. use 'qemu-system-mips64el -machine fulong2e' to boot the vmlinux + +qemu versions tried: 2.0.0, 1.6.2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1338957 b/results/classifier/deepseek-2/output/device/1338957 new file mode 100644 index 000000000..e7eff4ef2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1338957 @@ -0,0 +1,12 @@ + +RFE: add an event to report block devices watermark + +Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query-blockstats output. + +Rationale for the RFE +Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images. +In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded. + +In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor +using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios +with hunderds of VM are becoming not unusual. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1342 b/results/classifier/deepseek-2/output/device/1342 new file mode 100644 index 000000000..7af9e0440 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1342 @@ -0,0 +1,25 @@ + +Default machine setting of force-legacy=true causes problems for any modern VirtIO device using MMIO +Description of problem: +The default causes problems if you enable any non-legacy VirtIO device which has the VIRTIO_F_VERSION_1 feature bit will not properly read all feature bits. This is because reading VIRTIO_MMIO_VERSION returns VIRT_VERSION_LEGACY which in turn results in the driver not reading all feature bits, e.g. the qtest access: + +``` +static uint64_t qvirtio_mmio_get_features(QVirtioDevice *d) +{ + QVirtioMMIODevice *dev = container_of(d, QVirtioMMIODevice, vdev); + uint64_t lo; + uint64_t hi = 0; + + qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 0); + lo = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES); + + if (dev->version >= 2) { + qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 1); + hi = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES); + } + + return (hi << 32) | lo; +} +``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1352179 b/results/classifier/deepseek-2/output/device/1352179 new file mode 100644 index 000000000..711634661 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1352179 @@ -0,0 +1,29 @@ + +could not open disk image + +After restart the server it's show this error: + +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +qemu-kvm: -drive file=/var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk: No such file or directory + +the disk info show + qemu-img info disk +image: disk +file format: qcow2 +virtual size: 100G (107374182400 bytes) +disk size: 22G +cluster_size: 65536 +backing file: /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f + +but this file (backing file : /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f) is empty. +And all the instances cant't find the disk image + +We use CentOS release 6.5 (64bit) +kernel version : 2.6.32-431.11.2.el6.x86_64 +qemu-kvm-0.12.1.2-2.415.el6_5.10.x86_64 + +virsh version +Compiled against library: libvirt 0.10.2 +Using library: libvirt 0.10.2 +Using API: QEMU 0.10.2 +Running hypervisor: QEMU 0.12.1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1352465 b/results/classifier/deepseek-2/output/device/1352465 new file mode 100644 index 000000000..b746158f7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1352465 @@ -0,0 +1,8 @@ + +Can't install virtio block drivers during Windows setup + +Hi! +Apparently there's no way to install the virtio block drivers during Windows setup, as they're simply not recognized by the installer when it looks for them on the CD drive. +The only way to setup virtio block drivers is to first install Windows on a IDE drive, then add a dummy virtio disk, then load the drivers and swap the two disks. +I'm using virtio-win-0.1-81.iso. I can confirm the issue with Windows Server 2012 R2 and Windows 7 Professional, 64 bit. +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1353456 b/results/classifier/deepseek-2/output/device/1353456 new file mode 100644 index 000000000..71edaee3a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1353456 @@ -0,0 +1,18 @@ + +qemu-io: Failure on a qcow2 image with the fuzzed refcount table + +'qemu-io -c write' and 'qemu-io -c aio_write' crashes on a qcow2 image with a fuzzed refcount table. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.file in the same directory + 3. Execute + qemu-io copy.img -c write 279552 322560 + or + qemu-io copy.img -c aio_write 836608 166400 + +Result: qemu-io was killed by SIGIOT with the reason: + +qemu-io: block/qcow2-cluster.c:1291: qcow2_alloc_cluster_offset: Assertion `*host_offset != 0' failed. + +qemu.git HEAD 69f87f713069f1f \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1354 b/results/classifier/deepseek-2/output/device/1354 new file mode 100644 index 000000000..d812fdaf1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1354 @@ -0,0 +1,2 @@ + +-device usb-tablet not working on android guest. diff --git a/results/classifier/deepseek-2/output/device/1354279 b/results/classifier/deepseek-2/output/device/1354279 new file mode 100644 index 000000000..10fb86319 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1354279 @@ -0,0 +1,53 @@ + +The guest will be destroyed after hot remove the VF from the guest. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:9f6226a762c7ae02f6a23a3d4fc552dafa57ea23 +qemu.git Commit:5a7348045091a2bc15d85bb177e5956aa6114e5a +Host Kernel Version:3.16.0-rc1 +Hardware:Romley_EP, Ivytown_EP,Haswell_EP + + +Bug detailed description: +-------------------------- +hot add the VF to the guest, then hot remove the VF from the guest, the guest will be destroyed. + +note: +1. when hot add the VF with vfio, the hot remove the VF from the guest, the guest works fine. +2. this shoule be a qemu bug: +kvm + qemu = result +9f6226a7 + 5a734804 = bad +9f6226a7 + 9f862687 = good + + + +Reproduce steps: +---------------- +1. create guest +qemu-system-x86_64 --enable-kvm -m 1024 -smp 4 -net none rhel6u5.qcow -monitor pty +2. hot add the vf to guest +echo "device_add pci-assign,host=05:10.0,id=nic" >/dev/pts/x +cat /dev/pts/x +3. hot remove the VF froem guest +echo "device_del nic" >/dev/pts/x + +Current result: +---------------- +the guest willl be destroyed after hot remove the VF from the guest + +Expected result: +---------------- +the guest works fine after hot remove the VF from the guest + + +Basic root-causing log: +---------------------- +[root@vt-snb9 qemu.git]# qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none rhel6u5.qcow -monitor pty +VNC server running on `::1:5900' +** +ERROR:qom/object.c:725:object_unref: assertion failed: (obj->ref > 0) +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1356 b/results/classifier/deepseek-2/output/device/1356 new file mode 100644 index 000000000..dae7eacb2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1356 @@ -0,0 +1,18 @@ + +"-set device" doesn't work with device specified in json +Description of problem: +The above QEMU command line results in: +``` +qemu-system-x86_64: -set device.ua-igd.x-igd-gms=1: there is no device "ua-igd" defined +``` +While the following command works: +``` +qemu-system-x86_64 -accel kvm -m 8192 -nodefaults -display none -net none -device vfio-pci,host=0000:00:02.0,id=ua-igd -set device.ua-igd.x-igd-gms=1 +``` +libvirt has moved to the json device specification, therefore I can no longer associate use a <qemu:commandline> section to set driver options for a specific device with this broken id association. +Steps to reproduce: +1. Create a device with an ID and use -set device.$ID to set a driver option for the device +2. Note failure when using json device format vs legacy device specification +3. Profit +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1366 b/results/classifier/deepseek-2/output/device/1366 new file mode 100644 index 000000000..322ee709d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1366 @@ -0,0 +1,85 @@ + +Data inconsistency on LVM logical volume mounted as partition on ubuntu guest, when the written file's size is equal or greater than 27G. +Description of problem: +On the guest, writing a 27Gib file or larger result in inconsistent file checksum upon subsequent read. +Steps to reproduce: +**On the host** + +0. Create a LVM logical volume on a Linux RAID 1 (with 1 disk only) + +``` + --- Logical volume --- + LV Path /dev/davidahw2-vg4/lv0 + LV Name lv0 + VG Name davidahw2-vg4 + LV UUID 5FbDcl-eSDe-7cXL-22tj-Lg6O-79AL-4Gq7gx + LV Write Access read/write + LV Creation host, time davida-hw2, 2021-12-06 16:45:00 +0800 + LV Status available + # open 1 + LV Size <7.28 TiB + Current LE 1907688 + Segments 1 + Allocation inherit + Read ahead sectors auto + - currently set to 256 + Block device 253:4 + + --- Segments --- + Logical extents 0 to 1907687: + Type linear + Physical volume /dev/md4 + Physical extents 0 to 1907687 +``` + +1. Format the logical volume as ext4 + +``` +mkfs -t ext4 /dev/davidahw2-vg4/lv0 +``` + +2. Create a libvirt x86 64bits Ubuntu 22.04 machine mounting a LVM logical volume + +``` +<controller type='scsi' index='1' model='virtio-scsi'><driver queues='8' iothread='2'/></controller> + + +<disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/davidahw2-vg4/lv0'/> + <target dev='sdd' bus='scsi'/> + <blockio logical_block_size='512' physical_block_size='4096'/> + <address type='drive' controller='1' bus='0' target='1' unit='0'/> +</disk> +``` + + +**On the guest** + +3. Mount libvirt/qemu provided block device /dev/sdd as ext4 partition + +``` +mount /dev/sdd /mnt/test +``` + +4. Write **27G file** or larger **on the guest** causing the **2nd checksum to be different** + +``` +sync; head -c 27G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +8d3b4b263961d2c510390f99879be89b4b9134dc588139ede75573be1590115b myfile +a8e886b3c39d9b4721e582c5e2ca25c76ff6561750ac6dc7aa7e70404661d1cf myfile <== ERROR: Inconsistent checksum +``` + +5. Write **26G file** or larger **on the guest** and **both checksum are the same** + +``` +sync; head -c 26G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile <== CORRECT: Consistent checksum +``` + +**Important**: +- With the VM shutdown, the same commands on the same mounted ext4 partition **on the host** has consistent checksum every time for file sizes from 20G to 40G. +- The disk has no sign of failure (no badblocks reported to the filesystem, MD raid reports a healthy raid setup, smart reports on error) +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1367 b/results/classifier/deepseek-2/output/device/1367 new file mode 100644 index 000000000..69e1dcfc6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1367 @@ -0,0 +1,6 @@ + +Support MMIO devices in VFIO +Additional information: +- https://lore.kernel.org/qemu-devel/cover.1667542066.git.john.g.johnson@oracle.com/ +- https://github.com/nutanix/libvfio-user +- It also *somewhat* related to supporting non-PCI devices in `ivshmem`: https://gitlab.com/qemu-project/qemu/-/issues/1134 diff --git a/results/classifier/deepseek-2/output/device/1367365 b/results/classifier/deepseek-2/output/device/1367365 new file mode 100644 index 000000000..22b30a8ba --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1367365 @@ -0,0 +1,10 @@ + +qemu-img fixed vhd issues + +qemu-img returns fixed vhd images file format to be raw. + +This happens because only the header is seeked for image signatures when getting the image format. In fact, unlike dynamic vhd images, differencing vhds don't have the footer copied in the header. + +An easy fix would be to just search the last 512B for the 'conectix' signature. + +Also, the fixed vhds created by qemu-img seem to be corrupted from Powershell POV. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1368178 b/results/classifier/deepseek-2/output/device/1368178 new file mode 100644 index 000000000..278cfc5ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1368178 @@ -0,0 +1,26 @@ + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 + +A fresh installation of Windows Millennium Edition (Windows ME, WinME) as guest OS on qemu interprets qemu's videocards as Number Nine Imagine 128 with the consequence, that + +1. It is impossible to change color depth. +2. WinME uses the i128.drv Driver that is shipped with WinMe. +3. Forcing WinME to use other drivers has no effect. + + +It also doesn't matter what option for -vga was given to QEMU at command line. +cirrus, std, vmware, qxl etc. all have no effect, the videocard detected by Windows Me stays at Number Nine Imagine 128. + +Even selecting another driver in WinME and forcing WinME to use drivers such as the Cirrus Logic 5446 PCI driver has no effect. + +I also want to mention, that the BIOS isn't detected by WinME properly. +The device manager of WinME shows errors with the Plug & Play BIOS driver BIOS.vxd. + + +That is the QEMU Version: + +# qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard + +And this was the complete command line, that was given: +# sudo /usr/bin/qemu-system-i386 -hda WinME_QEMU.img -cdrom drivers.iso -boot c -no-acpi -no-hpet -soundhw sb16 -net nic -cpu pentium3 -m 256 -vga cirrus \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1368204 b/results/classifier/deepseek-2/output/device/1368204 new file mode 100644 index 000000000..ff183e09d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1368204 @@ -0,0 +1,16 @@ + +WinME isn't able to detect QEMU's cdrom drive and other hard drives automatically + +On a fresh installation of Windows Millennium (WinME) in qemu, Windows Me isn't able to find the CD-ROM drive or additional hard drives other than -hda at first place. + +Only if i add manually an IDE controller driver in Windows ME's device manager, the CD-ROM inserted in QEMU is found. +Thus an IDE controller isn't found automatically either. + +This shouldn't be the case. On normal real hardware, Windows ME would find at least one IDE or SCSI controller. + +The command line that was used is the following: +sudo /usr/bin/qemu-system-i386 -hda WinME_QEMU.img -cdrom drivers.iso -boot c -no-acpi -no-hpet -soundhw sb16 -net nic -cpu pentium3 -m 256 -vga cirrus + +qemu's version is: +qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1373362 b/results/classifier/deepseek-2/output/device/1373362 new file mode 100644 index 000000000..38a3991ba --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1373362 @@ -0,0 +1,28 @@ + +qemu-2.1.1 i386-softmmu compile error: q35_dsdt_applesmc_sta undeclared + +I try to compile qemu-2.1.1 (Gentoo/x86), but the i386-softmmu fails to compile: + + CPP i386-softmmu/q35-acpi-dsdt.dsl.i.orig + ACPI_PREPROCESS i386-softmmu/q35-acpi-dsdt.dsl.i + IASL i386-softmmu/q35-acpi-dsdt.dsl.i + ACPI_EXTRACT i386-softmmu/q35-acpi-dsdt.off + CAT i386-softmmu/hw/i386/q35-acpi-dsdt.hex + CC i386-softmmu/hw/i386/acpi-build.o +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c: In function 'acpi_get_dsdt': +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c:119:24: error: 'q35_dsdt_applesmc_sta' undeclared (first use in this function) + applesmc_sta = q35_dsdt_applesmc_sta; + ^ +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c:119:24: note: each undeclared identifier is reported only once for each function it appears in +make[1]: *** [hw/i386/acpi-build.o] Error 1 +make: *** [subdir-i386-softmmu] Error 2 + +Something seems to go wrong when generating the file i386-softmmu/hw/i386/q35-acpi-dsdt.hex: + +# grep -r q35_dsdt_applesmc_sta ../ +../softmmu-build/x86_64-softmmu/q35-acpi-dsdt.dsl.i:/* ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta */ +../softmmu-build/x86_64-softmmu/q35-acpi-dsdt.dsl.i.orig: ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta +../softmmu-build/i386-softmmu/q35-acpi-dsdt.dsl.i:/* ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta */ +../softmmu-build/i386-softmmu/q35-acpi-dsdt.dsl.i.orig: ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta +../hw/i386/acpi-build.c: applesmc_sta = q35_dsdt_applesmc_sta; +../hw/i386/q35-acpi-dsdt.dsl:#define DSDT_APPLESMC_STA q35_dsdt_applesmc_sta \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1378407 b/results/classifier/deepseek-2/output/device/1378407 new file mode 100644 index 000000000..c6acf687e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1378407 @@ -0,0 +1,6 @@ + +[feature request] Partition table wrapper for single-filesystem images + +Suppose you have a single filesystem image. It would be nice if QEMU could generate a virtual partition table for it and make it available to the guest as a partitioned disk. Otherwise you have to use workarounds like this: wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID + +It should be relatively easy to do on top of existing vvfat code. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1380 b/results/classifier/deepseek-2/output/device/1380 new file mode 100644 index 000000000..6b889d7c6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1380 @@ -0,0 +1,5 @@ + +vdagent is not working properly after live migration +Additional information: +when validating on windows server 2016 Datacenter Evaluation, i found that if vdagent process or vdservice is restarted, copy/paste from host to guest or reverse will work again. i am wondering if we should send something(eg, a event?) to guest to let it reopen the port after live migration? + diff --git a/results/classifier/deepseek-2/output/device/1381879 b/results/classifier/deepseek-2/output/device/1381879 new file mode 100644 index 000000000..56fc25aaf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1381879 @@ -0,0 +1,34 @@ + +can not run vm with a serial port + +environment: +server: centOS 6.5, 3.14.19, x86_64 +qemu-kvm: QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard +qemu-system-x86_64 :QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard +virt-manager: 0.9.0 + +VM: centOS 6.5, 3.12.30, x86_64 + +reproduce step: +1. add serial device +2. select device type: unix socket + device parameters: path=/dev/ttyS0 + mode=client mode(connect) +3. run the VM + +phenomenon: +Error starting domain: internal error process exited while connecting to monitor: qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: socket bind failed: Address already in use +qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: chardev: opening backend "socket" failed + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup + self._backend.create() + File "/usr/lib64/python2.6/site-packages/libvirt.py", line 678, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error process exited while connecting to monitor: qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: socket bind failed: Address already in use +qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: chardev: opening backend "socket" failed \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1384 b/results/classifier/deepseek-2/output/device/1384 new file mode 100644 index 000000000..bb6e6fdc6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1384 @@ -0,0 +1,2 @@ + +Update libvfio-user to latest upstream diff --git a/results/classifier/deepseek-2/output/device/1386478 b/results/classifier/deepseek-2/output/device/1386478 new file mode 100644 index 000000000..a0ef5c745 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1386478 @@ -0,0 +1,6 @@ + +PS/2 keyboard returns incorrect scan code for F7 to guest + +Using qemu 2.1 as supplied in Debian jessie, the F7 scan code (scan set 2) is being returned by qemu to the guest as 0x02, and not the correct value of 0x83. (I assume 0x83 is correct, given that I cannot locate any scan set 2 charts that use any other value for F7. Including those published by Microsoft.) + +I see the map in hw/input/ps2.c ps2_raw_keycode[] using the correct values, starting at F1: 5, 6, 4, 12 (0x0C). 3. 11 (0x0B), 2, 10 (0x0A), 1, 9, ... but nowhere in that map do I see 131 (0x83). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1390 b/results/classifier/deepseek-2/output/device/1390 new file mode 100644 index 000000000..32e2bb4ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1390 @@ -0,0 +1,2 @@ + +Any plans for P5020 P5040 CPUs? diff --git a/results/classifier/deepseek-2/output/device/1390520 b/results/classifier/deepseek-2/output/device/1390520 new file mode 100644 index 000000000..de9d0591b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1390520 @@ -0,0 +1,27 @@ + +virtual machine fails to start with connected audio cd + +when connecting a data cd with a virtual machine (IDE CDROM 1), the virtual machine starts up and the data cd is accessable (for example to install software package or drivers), +but connecting an audio cd the following error appears: + +------------------------------------------------------------------------------------------------------------------------------- +cannot read header '/dev/sr0': Input/output error + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/details.py", line 2530, in _change_config_helper + func(*args) + File "/usr/share/virt-manager/virtManager/domain.py", line 850, in hotplug_storage_media + self.attach_device(devobj) + File "/usr/share/virt-manager/virtManager/domain.py", line 798, in attach_device + self._backend.attachDevice(devxml) + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 493, in attachDevice + if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) +libvirtError: cannot read header '/dev/sr0': Input/output error +---------------------------------------------------------------------------------------------------------------------------- + +Description: Ubuntu 14.04.1 LTS +Release: 14.04 + +qemu: + Installiert: 2.0.0+dfsg-2ubuntu1.6 + Installationskandidat: 2.0.0+dfsg-2ubuntu1.6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1391 b/results/classifier/deepseek-2/output/device/1391 new file mode 100644 index 000000000..6dbfe010d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1391 @@ -0,0 +1,29 @@ + +virtio-blk: BDRV_REQ_REGISTERED_BUF optimization hint crashes on macOS +Description of problem: +When using QEMU 7.2.0 on macOS with the virtio-blk drive, the process will exit and QMP shows a `BLOCK_IO_ERROR` event. This appears to be caused by this line: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/block/virtio-blk.c#L405 introduced in https://gitlab.com/qemu-project/qemu/-/commit/baf422684d73c7bf38e2c18815e18d44fcf395b6 + +Commenting that line out fixes the issue. +Steps to reproduce: +1. Run the QEMU command above with a Ubuntu 22.04 server ISO image. +2. Follow the installer and try to get to the end. +3. The process will crash before you can finish installing. +Additional information: +Following event appears on QMP: +``` +{ + data = { + action = report; + device = "drive437EC806-41A4-4CCE-A747-713352E7C27C"; + "node-name" = "#block785"; + nospace = 0; + operation = write; + reason = "Invalid argument"; + }; + event = "BLOCK_IO_ERROR"; + timestamp = { + microseconds = 808474; + seconds = 1671867673; + }; +} +``` diff --git a/results/classifier/deepseek-2/output/device/1392 b/results/classifier/deepseek-2/output/device/1392 new file mode 100644 index 000000000..75609cde8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1392 @@ -0,0 +1,15 @@ + +qemu 7.2.0 almalinux 9.1 guest vda io error +Description of problem: +after update the qemu from 7.1.0 to 7.2.0 guest almalinux 9.1 have disk io error ,log : +```log +Dec 24 00:17:39 rlh1 kernel: I/O error, dev vda, sector 109770720 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 +Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359840 +Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770776 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 +Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359896 +Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770832 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 +``` + +then I switch back to version 7.1.0 it work as normal +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1392504 b/results/classifier/deepseek-2/output/device/1392504 new file mode 100644 index 000000000..08867cb5b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1392504 @@ -0,0 +1,4 @@ + +libvirt not relabeling devices on USB Passthrough + +After upgrading from Ubuntu 14.04 to Ubuntu 14.10 USB passthrough in QEMU (version is now 2.1.0 - Debian2.1+dfsg-4ubuntu6.1) is not working any more. Already tried to remove and attach the USB devices. I use 1 USB2 HDD + 1 USB3 HDD to a virtual linux machine; 1 USB2 HDD to a virual FNAS machine and a USB 2camera to virtual Win7 machine. All these devices are not working any more. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1393 b/results/classifier/deepseek-2/output/device/1393 new file mode 100644 index 000000000..85cd7cb3c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1393 @@ -0,0 +1,66 @@ + +Abort in audio_calloc() of ac97 +Description of problem: +Section 5.10.2 of the AC97 specification (https://hands.com/~lkcl/ac97_r23.pdf) +shows the feasibility to support for rates other than 48kHZ. Specifically, +AC97_PCM_Front_DAC_Rate (reg 2Ch) should be from 8kHZ to 48kHZ. + + +An adversary can leverage this to crash QEMU. + +A nornal 48kHZ setting is like this. + +``` +ac97_realize + open_voice + as->freq = 0xbb80 # 0xbb80=48000 + AUD_open_out + audio_pcm_create_voice_pair_out (sw is NULL) + audio_pcm_sw_init_out + sw->info.freq = as->freq (in audio_pcm_init_info()) + sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq + samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out()) +``` + +A non-48kHZ setting is like this. Since `as->freq` is too small, `sw->ratio` is +too large. Finally, `samples` is zero, failing the audio_calloc() in +audio_pcm_sw_alloc_resources_out(). + +``` +nam_writew + open_voice + as->freq = 0x6 + AUD_open_out + audio_pcm_sw_init_out (sw is not NULL) + sw->info.freq = as->freq (in audio_pcm_init_info()) + sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq + samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out()) + audio_calloc(.., samples, ) (in audio_pcm_sw_alloc_resources_out()) +``` +Steps to reproduce: +1. download the prepared rootfs and the image. + + https://drive.google.com/file/d/1IfVCvn76HY-Eb4AZU7yvuyPzM3QC1q10/view?usp=sharing + https://drive.google.com/file/d/1JN6JgvOSI5aSLIdTEFKiskKbrGWFo0BO/view?usp=sharing + +2. run the following script. + +``` bash +QEMU_PATH=../../../qemu-devel/build/x86_64-softmmu/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -device ac97,audiodev=snd0 -audiodev none,id=snd0 \ + -nographic +``` + +3. with spawned shell (the user is root and the password is empty), run +`ac97-00`. +Additional information: +In the latest QEMU, this issue was generally fixed by 12f4abf6a245c43d8411577fd400373c85f08c6b and 0cbc8bd4694f32687bf47c6da48efa48fac35fd2 that remove abort() from the source code. Even though, I still plan to send a +patch so that the warning about the invalid freq will be gone. diff --git a/results/classifier/deepseek-2/output/device/1393440 b/results/classifier/deepseek-2/output/device/1393440 new file mode 100644 index 000000000..c642e0cca --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1393440 @@ -0,0 +1,18 @@ + +pcie.c:148: possible error in OR expression ? + +[qemu/hw/pci/pcie.c:148] -> [qemu/hw/pci/pcie.c:148]: (style) Same expression on both sides of '|'. + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_URD | PCI_EXP_DEVSTA_URD); + +I am guessing that something like + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD); + +was intended. + +I used static analyser cppcheck to find this bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1399943 b/results/classifier/deepseek-2/output/device/1399943 new file mode 100644 index 000000000..1e8cf2c65 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1399943 @@ -0,0 +1,29 @@ + +qemu-system-sparc loses serial console data on EAGAIN + +When running a guest OS with a serial console under +"qemu-system-sparc -nographic", parts of the serial console output +are sometimes lost. + +This happens when a write() to standard output by qemu returns EAGAIN, +as may be the case when the guest is generating console output faster +than the tty (or pty/pipe/socket, etc.) connected to qemu's standard +output accepts it. The bug affects all releases of qemu since 1.5, +which was the first version to set stdout to O_NONBLOCK mode. Version +1.4.2 and earlier work correctly. + +To reproduce the bug, you will need a guest OS configured with a +serial console, and a host with a slow tty. The attached shell script +"sparc-test.sh" does this by using Aboriginal Linux as the serial +console guest, and a pty controlled by a Python script and the +"pexpect" Python module as the slow tty. A "seq" command is sent +to the guest to generate 100,000 lines of output containing sequential +integers, and the output is checked for gaps. The script limits the +tty output rate by occasionally sleeping for 1/10 of a second. + +This bug was originally reported against qemu-system-i386 as +bug #1335444, and has since been fixed in qemu-system-i386, +but remains in qemu-system-sparc as of today's git sources +(d00e6cddc220de993573dfb5fd160ac72ccd49ab). I am opening +this separate bug for the sparc case because I was asked +to do so by Paolo Bonzini in #1335444. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1403 b/results/classifier/deepseek-2/output/device/1403 new file mode 100644 index 000000000..3732da147 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1403 @@ -0,0 +1,2 @@ + +qemu 7.2: test-io-channel-command fails sporadically diff --git a/results/classifier/deepseek-2/output/device/1404 b/results/classifier/deepseek-2/output/device/1404 new file mode 100644 index 000000000..8209ea850 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1404 @@ -0,0 +1,15 @@ + +qemu-7.2: virtio-blk-pci I/O errors with detect-zeroes=unmap +Description of problem: +Since upgrading from qemu-7.1 to qemu-7.2 I have seen many anomalies with VMs that use the virtio-blk-pci device for the root filesystem and the `detect-zeroes=unmap` option, typically in the form of I/O errors or huge decreases in read/write performance. This has been observed for both pre-existing Linux & Windows systems using the QCOW2 disk format, and a freshly created Linux system. + +* For an existing x86_64 Windows-10 guest system, hosted on Debian-11, the guest system takes many minutes to boot and Task Manager shows the virtual disk showing read/write latencies measured in seconds rather than milliseconds. +* Attempts to create a new x86_64 Debian-11 guest on a Debian-11 host produce an input/output error when trying to partition the QCOW2 hard disk /dev/vda (as per attached screenshot)  +* Using a pre-existing Debian-11 guest that works perfectly with qemu-7.1, fails to format a basic ext3 /dev/loop filesystem when this guest is booted with qemu-7.2, giving `mke2fs: Input/output error while writing out and closing file system` +Steps to reproduce: +(installer error) +1. Create fresh QCOW2 image: `qemu-img create -f qcow2 deb11.img 8G` +2. Run standard Debian-11 installer from ISO image and virtio-blk-pci drive and options `-drive if=none,media=disk,id=drive0,file=deb11.img,cache=writeback,discard=unmap,detect-zeroes=unmap` +3. Use default options with "guided partitioning" +Additional information: +I'm not aware of any changes to the setup of my system that would account for these problems, and have successfully tried many similar experiments with QEMU version up to and including version 7.1. Obviously, I'm hoping there's some trivial configuration error I've overlooked in qemu-7.2 - any suggestions would be much appreciated. diff --git a/results/classifier/deepseek-2/output/device/1404610 b/results/classifier/deepseek-2/output/device/1404610 new file mode 100644 index 000000000..ff555bbc3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1404610 @@ -0,0 +1,12 @@ + +[feature request] HP300 m68k system? + +QEMU seems to support nothing (specific) that 4.4BSD was targeted to...would be useful to have a complete emulator for a full HP300 to run the binary dist from McKusick's CD set. + +Devices that'd be needed: +* 68020, 68030, or 68040 (How much of these are already present? Not sure if there was a non-standard MMU/FPU...but there was definitely a slightly-uncommon bus used for some peripherals) +* Networking was lance I am pretty sure...at least the onboard one. +* SCSI (Probably a standard chip as used EVERYWHERE ELSE..not sure off hand) +* Framebuffers optional, serial is sufficient for basic booting of 4.4. + +Tape/disk can also be done via HP-IB...but SCSI would probably be easier unless extra peripherals were required (some serial stuff.) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1407454 b/results/classifier/deepseek-2/output/device/1407454 new file mode 100644 index 000000000..afd5e5346 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1407454 @@ -0,0 +1,31 @@ + +assertion failed when using "-usb" option + +SUMMARY: +---------- +Description: Latest 'master' makes it impossible to use "-usb" command line on any target +Host platform: Linux x86-64 +Guest platform: probably all (at least x86-64, i386, arm and ppc) + +REPRODUCE: +---------- +How to reproduce: +1. Run the following command: +$ qemu-system-x86_64 -usb + +Expected result: +Starting virtual machine with empty configuration + +Actual result: +Qemu crashes with following message: + +qemu-system-x86_64: /home/mplucinski/Developer/Open_Source/qemu/qemu.git/util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. +Aborted + +MORE INFORMATION: +---------- +Same happens when trying to run other target, e.g. +$ qemu-system-i386 -usb +$ qemu-system-arm -machine kmz -usb + +First commit where the issue occurs (bisection result): 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1407808 b/results/classifier/deepseek-2/output/device/1407808 new file mode 100644 index 000000000..f855ee5e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1407808 @@ -0,0 +1,10 @@ + +virtual console gives strange response to ANSI DSR + +With "-serial vc" (which is the default), qemu make strange responses to the ANSI DSR escape sequence (\033[6n) which can confuse guests. + +Terminal emulators supporting the ANSI escape sequences usually support the "Device Status Report" escape sequence, \033[6n, to which as a response the terminal injects as input the response \033[n;mR, containing the current cursor position. An application running in the guest can use this escape sequence to, for example, figure out the size of the terminal it is running under, which can be useful as the guest has no other standard way to figure out a "size" for the serial port. + +Unfortunately, it seems that qemu when run with "-serial vc" (which appears to be the default), when qemu gets the \033[6n escape sequence on the serial port, it just responds with a single \033, and that's it! This can confuse an application, could concievably assume that a terminal either supports this escape sequence and injects the correct response (\033[n;mR), or doesn't support it and injects absolutely nothing as input - but not something in between. + +This caused a problem on one shell implementation on OSv that tried to figure out the terminal's size, and had to work around this unexpected behavior (see https://github.com/cloudius-systems/osv/commit/b79223584be40459861d1c12e1cb67e3e49e2a12). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1410 b/results/classifier/deepseek-2/output/device/1410 new file mode 100644 index 000000000..d383d0c4d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1410 @@ -0,0 +1,15 @@ + +system_powerdown only works once +Description of problem: +When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume. The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path. + +There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either. +Steps to reproduce: + +1. Boot a guest configured to sleep when it receives a power button event +2. `system_powerdown` from the monitor to tell it to sleep +3. `info status` to verify that it is suspended +4. Wake the guest, either with `system_wakeup` or moving the mouse or something +5. `system_powerdown` has no effect +Additional information: +This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough. diff --git a/results/classifier/deepseek-2/output/device/1413 b/results/classifier/deepseek-2/output/device/1413 new file mode 100644 index 000000000..e910af286 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1413 @@ -0,0 +1,23 @@ + +I tried to use qemu-nbd in the shell script, but it seems that qemu-nbd has some delay. +Description of problem: + +Steps to reproduce: +1. +``` +cat ~/test.sh +#!/bin/bash +qemu-nbd -c /dev/nbd0 $1 +mount -t ntfs3 -o uid=1000,gid=1000 /dev/disk/by-label/OS /mnt/OS +``` +2. +``` +sudo ~/test.sh ~/VM/win7_i386.qcow2 +mount: /mnt/OS: special device /dev/disk/by-label/OS does not exist. + dmesg(1) may have more information after failed mount system call. + +``` +Additional information: +But when I added a one-second delay between qemu-nbd and mount commands, the problem was solved. + +The qemu-img convert command also has a similar problem. It seems that these commands have a certain delay. Is this in line with expectations? diff --git a/results/classifier/deepseek-2/output/device/1422285 b/results/classifier/deepseek-2/output/device/1422285 new file mode 100644 index 000000000..4caf6dadf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1422285 @@ -0,0 +1,55 @@ + +The guest will be destroyed when hot plug the VF to guest for the second time. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):linux +kvm.git Commit: 6557bada461afeaa920a189fae2cff7c8fdce39f +qemu.kvm Commit: cd2d5541271f1934345d8ca42f5fafff1744eee7 +Host Kernel Version:3.19.0-rc3 +Hardware:Haswell_EP,Ivytown_EP + + +Bug detailed description: +-------------------------- +create guest , then hot plug the VF to the guest for the second time, the guest will be destroyed. + +note: +1. hot plug the device to guest with vfio, the guest works fine +2.this should be a qemu bug: +kvm + qemu = result +6557bada + cd2d5541 = bad +6557bada + a805ca54 = good + + +Reproduce steps: +---------------- +1. qemu-system-x86_64 -enable-kvm -m 2G -net none -monitor pty rhel6u5.qcow +2. echo "device_add pci-assign,host=03:10.1,id=nic" >/dev/pts/2 +3. cat /dev/pts/2 & +4. echo "device_del nic" >/dev/pts/2 +5. echo "device_add pci-assign,host=03:10.0,id=nic" >/dev/pts/2 + +Current result: +---------------- +guest will be destroyed when hot plug the vf to guest for the second time. + +Expected result: +---------------- +guest works fine when hot plug the vf to guest for the second time + +Basic root-causing log: +---------------------- +[root@vt-hsw2 cathy]# qemu-system-x86_64 -enable-kvm -m 2G -net none -monitor pty rhel6u5.qcow +char device redirected to /dev/pts/2 (label compat_monitor0) +Segmentation fault (core dumped) + + +some dmesg log: + +pci-stub 0000:03:10.1: kvm deassign device +pci-stub 0000:03:10.1: enabling device (0000 -> 0002) +qemu-system-x86[9894]: segfault at 0 ip (null) sp 00007fa73df0cae8 error 14 +pci-stub 0000:03:10.1: kvm assign device \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1423668 b/results/classifier/deepseek-2/output/device/1423668 new file mode 100644 index 000000000..38d493c09 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1423668 @@ -0,0 +1,12 @@ + +Unable to set scsi drive serial if it contains spaces. + +I am virtualzing a physical server for which I need to set the SCSI/SATA drive serial. It is comprised of 12 " " spaces then 8 letter/digits. If I exclude the spaces, the drive serial is not accurate. If I include the spaces I get the following error. + +error: Failed to start domain test1 +error: internal error: driver serial ' ABCD1234' contains unsafe characters + +virsh edit +Centos 7.0 +3.19.0-1.el7.elrepo.x86_64 +QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-60.el7.centos.7), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1426593 b/results/classifier/deepseek-2/output/device/1426593 new file mode 100644 index 000000000..4876e7968 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1426593 @@ -0,0 +1,9 @@ + +linux-user: doesn't handle guest setting its memory ulimit very small + +using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested. +i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it + +building coreutils hangs on "checking whether printf survives out-of-memory conditions" + +i have not had time to dig into the build system to isolate the test yet, there were old reports of this bug but i can no longer find them on google. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1428958 b/results/classifier/deepseek-2/output/device/1428958 new file mode 100644 index 000000000..60dce689c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1428958 @@ -0,0 +1,66 @@ + +random IO errors / data corruption in VMs (created and executed via virt-manager) + +I have recurring problems with VM installation and usage - data on VM disk gets corrupted at some point and it causes all sorts of problems - sometimes I cannot even install base system, other times some .so files are corrupt after isntallation, etc - totally random. +I use virt-manager to create and run VMs. I have also tried creating VMs via virt-install, result is identical. +If I use VirtualBox I have no such problems. +My OS is Fedora 20 upgraded to 21, qemu and libvirt are installed from Fedora official repos. + +Here's an example qemu command-line: +/usr/bin/qemu-system-x86_64 +-machine accel=kvm +-name fuel +-S +-machine pc-i440fx-2.1,accel=kvm,usb=off +-cpu SandyBridge,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme +-m 3142 +-realtime mlock=off +-smp 2,sockets=2,cores=1,threads=1 +-uuid 27693a46-7a50-4a3c-bcaf-bf061ba469ed +-no-user-config +-nodefaults +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fuel.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control +-rtc base=utc,driftfix=slew +-global kvm-pit.lost_tick_policy=discard +-no-hpet +-no-shutdown +-boot menu=on,strict=on +-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 +-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 +-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 +-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 +-device lsi,id=scsi0,bus=pci.0,addr=0xa +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 +-drive file=/home/virtual-disks/fuel.vdi,if=none,id=drive-virtio-disk0,format=vdi +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +-drive file=/home/dsutyagin/Downloads/iso/MirantisOpenStack-6.0.iso,if=none,id=drive-scsi0-0-0,readonly=on,format=raw +-device scsi-cd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0,bootindex=2 +-netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:42:2d,bus=pci.0,addr=0x3 +-netdev tap,fd=25,id=hostnet1,vhost=on,vhostfd=26 +-device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:a4:8c:ef,bus=pci.0,addr=0x4 +-chardev pty,id=charserial0 +-device isa-serial,chardev=charserial0,id=serial0 +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fuel.org.qemu.guest_agent.0,server,nowait +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 +-chardev spicevmc,id=charchannel1,name=vdagent +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 +-device usb-tablet,id=input0 +-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 +-device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 +-chardev spicevmc,id=charredir0,name=usbredir +-device usb-redir,chardev=charredir0,id=redir0 +-chardev spicevmc,id=charredir1,name=usbredir +-device usb-redir,chardev=charredir1,id=redir1 +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 +-msg timestamp=on + +If this is not a bug, I'd be happy if you help me fix this problem. I am sorry if this is not the proper place to post such a problem. + +qemu-system-x86_64 --version +QEMU emulator version 2.1.3 (qemu-2.1.3-2.fc21), Copyright (c) 2003-2008 Fabrice Bellard + +qemu-kvm --version +QEMU emulator version 2.1.3 (qemu-2.1.3-2.fc21), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/143 b/results/classifier/deepseek-2/output/device/143 new file mode 100644 index 000000000..630104961 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/143 @@ -0,0 +1,2 @@ + +xhci HCIVERSION register read emulation incorrectly handled diff --git a/results/classifier/deepseek-2/output/device/1435973 b/results/classifier/deepseek-2/output/device/1435973 new file mode 100644 index 000000000..3e0a8a27c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1435973 @@ -0,0 +1,61 @@ + +Qemu crash when a guest linux issues specific scsi command via ioctl(SG_IO) with SCSI disk emulation. + +As of git revision 362ca922eea03240916287a8a6267801ab095d12, when guest linux issues specifit scsi command, qemu crashes. + +To reproduce. + +1. launch qemu with scsi emulatoin +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi +2. issues scsi command via ioctl(SG_IO) on guest linux. like below. + +------------------------- +struct request_sense sens; +struct sg_io_hdr sg; +unsigned char cdb[6]; +unsigned char buf[127]; + +memset( &sens, 0, sizeof(sens) ); +memset(&sg, 0, sizeof(sg)); +memset(cdb, 0, sizeof(cdb)); +memset(buf, 0, sizeof(buf)); + +// qemu crash!!! +cdb[0] = 0xff; + +sg.dxferp = buf; +sg.dxfer_len = sizeof(buf); +sg.dxfer_direction = SG_DXFER_FROM_DEV; +sg.flags = 0; +sg.interface_id = 'S'; +sg.cmdp = cdb; +sg.cmd_len = sizeof( cdb ); +sg.sbp = (unsigned char*)&sens; +sg.mx_sb_len = sizeof( sens ); + +ioctl( fd, SG_IO, &sg ); +------------------------- + +I think cause is below code. + +scsi-bus.c L1239 +int scsi_req_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf) +{ + int rc; + + cmd->lba = -1; + cmd->len = scsi_cdb_length(buf); + ... + memcpy(cmd->buf, buf, cmd->len); +} + +scsi_cdb_length(buf) returns -1 when buf[0] is unexpected value. +Then memcpy(cmd->buf, buf, 4294967295); is executed and crash. + +Environment +Qemu: git revision 362ca922eea03240916287a8a6267801ab095d12 +Guest: linux kernel 3.18.4 + buildroot +Host: Windows 7 64bit + +Thanks, +hiroaki \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1437970 b/results/classifier/deepseek-2/output/device/1437970 new file mode 100644 index 000000000..da497c220 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1437970 @@ -0,0 +1,45 @@ + +qemu-system-x86_64 - two mouse pointers & fast scrolling problem + +Hello, + +System Specs + +Host: +-------- +Slackware 14.1 x86_64 +Openbox 3.5.2 +tint2 panel (svn version) +Nvidia GTX660M +nvidia-driver-346.35 +Screen: 17" @1920x1080@60Hz + + +Guest +--------- +Slackware 14.1 x86_64 +XFce 4.10 +Screen 17" @1920x1080 +xf86-video-vmware 13.0.1 + +QEMU 2.2.1 + +I start Slackware in QEMU using 'Zoom To Fit' when it first boots up and I log into X, at this point I notice the mouse shows with 2 pointers and when I move the mouse around, shows as trails, but it's actually a second pointer that appears under the first. + +If I use 'Ctrl Alt F' and go into full screen mode the mouse gets corrected and only appears as one pointer and no pointer under the second one when moving around. So this mouse problem only appears the first time I log into X with 'Zoom To Fit'. + +Also if log in instead as 'Full Screen' I do not see the issue, as well as if I log in 'Full Screen' and change back to 'Zoom To Fit' it does not happen. + +I also noticed that if I scroll with the mouse wheel very fast while, as an example, in any application and wanting to move quickly around, the mouse ends up moving me instead to another virtual desktop, XFce by default uses 4. If I just scroll slowly nothing happens, it's only when moving the mouse wheel quickly that the focus gets taken off the application for some reason and put on the desktop and moves you. + +Command line options: +-------------------------------- +qemu-system-x86_64 -rtc base=localtime Slackware\ 14.1\ x64.img -m 4096 --enable-kvm -smp 2 -vga vmware -usbdevice tablet + +I wanted to use -usbdevice tablet to have seamless mouse movement back and forth from Host to Guest without having to Grab... + +If I remove '-usbdevice tablet' and log into X the frst time as 'Zoom To Fit' I see two mouse pointers, but as soon as I click the desktop and the mouse is grabbed the second one goes away and when I move the mouse there is only one pointer. + +Also without the optiion '-usbdevice tablet' and I move the scroll wheel quickly the mouse stays focused on the application and it doesn't move the desktop. + +Please see the attached screen shots, qemu_1.jpg shows 2 mouse pointers when I first log into X and qemu_2.jpg shows when I'm staying in 'Zoom To Fit' mode and moving the mouse around, with a pointer under the pointer. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/144 b/results/classifier/deepseek-2/output/device/144 new file mode 100644 index 000000000..21388e8ec --- /dev/null +++ b/results/classifier/deepseek-2/output/device/144 @@ -0,0 +1,2 @@ + +Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up diff --git a/results/classifier/deepseek-2/output/device/1440843 b/results/classifier/deepseek-2/output/device/1440843 new file mode 100644 index 000000000..17b3eba21 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1440843 @@ -0,0 +1,15 @@ + +Guest WinXP crashes when trying to use a USB spectrometer + +I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: + +1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" +2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" +3. command line parameter "-usbdevice host:2457:1030 +4. command line parameter "-usbdevice host:3.25" +5. qemu console command "usb_add host:2457:1030" +5. qemu console command "usb_add host:3.25" + +From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. + +I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1442 b/results/classifier/deepseek-2/output/device/1442 new file mode 100644 index 000000000..ebffc707d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1442 @@ -0,0 +1,2 @@ + +RISC-V qemu, get cpu tick diff --git a/results/classifier/deepseek-2/output/device/1445633 b/results/classifier/deepseek-2/output/device/1445633 new file mode 100644 index 000000000..7a24462f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1445633 @@ -0,0 +1,14 @@ + +Creating a passthrough USB device causes excessive CPU usage in the guest + +My host machine is a Lenovo X1 Carbon (3rd gen) laptop running 64-bit Ubuntu Linux 14.04. My guest machine is running 64-bit Ubuntu Linux 12.04. My QEMU was compiled moments ago from the git repository, and it says its version is: +qemu-x86_64 version 2.2.93, Copyright (c) 2003-2008 Fabrice Bellard + +My issue is that when I create a passthrough for a USB host device to the guest, it causes qemu's CPU utilization on the host to increase significantly and stay there. After the passthrough is created, qemu's CPU usage in top hovers between 20% and 30% (evenly spread across CPUs). In virt-manager's CPU usage chart, it shows the guest's CPU usage growing from 0% to about 5%, although running "top" in the guest does not show an increase in CPU usage. These usage levels drop back down to normal (0 to 1%) only after I physically unplug the device or remove the passthrough mapping. + +It doesn't seem to matter what the device is. I have tested it using: +A Realtek rtl8192cu-based 802.11n adapter +An HP optical mouse +A Samsung Galaxy S5 phone + +The behavior is the same regardless of device, and they otherwise seem to work properly in the guest machine. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1451 b/results/classifier/deepseek-2/output/device/1451 new file mode 100644 index 000000000..879b366ab --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1451 @@ -0,0 +1,2 @@ + +Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed. diff --git a/results/classifier/deepseek-2/output/device/1453025 b/results/classifier/deepseek-2/output/device/1453025 new file mode 100644 index 000000000..426d65b02 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1453025 @@ -0,0 +1,16 @@ + +remote usb3.0 redir failed, when guest os has more than one vcpus + +I was testing usb3.0 redirection, it worked fine with one vcpu. +But when I set vcpu to a number greater than one, the redirection failed. + +Host and guest are Fedora 20 and Windows 7. +Client is remote-viwer. + +version: qemu 2.3.0 libvirt 1.2.15 spice 0.12.5 + +libvirt xml: + +<vcpu placement='static'>2</vcpu> +<controller type='usb' index='0' model='nec-xhci'> +</controller> \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1457 b/results/classifier/deepseek-2/output/device/1457 new file mode 100644 index 000000000..19cbbd917 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1457 @@ -0,0 +1,2 @@ + +ide: assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. diff --git a/results/classifier/deepseek-2/output/device/1458 b/results/classifier/deepseek-2/output/device/1458 new file mode 100644 index 000000000..899edb3ba --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1458 @@ -0,0 +1,28 @@ + +ns16550a reg-shift incorrect for qemu-system-riscv64 +Description of problem: +Missing reg-shift 0 on the ns16550n in qemu-system-riscv64 creates an impossible assumption case. +Steps to reproduce: +1. qemu-system-riscv64 -M virt,dumpdtb=dtb +2. dtc dtb | less + + serial@10000000 { + interrupts = <0x0a>; + interrupt-parent = <0x03>; + clock-frequency = "\08@"; + reg = <0x00 0x10000000 0x00 0x100>; + compatible = "ns16550a"; + }; + +Generally, ns16550a has a default reg-shift of 0 on x86,x86_64 for compatibility reasons. All other architectures have an assumed reg-shift of 2 (or having the reg-shift assumption overridden by fdt providing a reg-shift property) + +Beyond the above, anything non-standard is assumed to be specified by the "reg-shift" property fdt. + +qemu-system-riscv64 seems to "assume" a reg-shift of 0. Other riscv64 devices don't supply "reg-shift" (SiFive Unmatched) and "assume" 2. +The above means driver writers don't actually know what to "assume" on riscv64 ns16550a when no reg-shift is present. + + +Essentially, qemu-system-riscv64 needs to do one of the following: + +* If serial ns16550a with a uart reg-shift of 0 is intentional, qemu needs to advertise the deviance via "reg-shift 0" +* If serial ns16550a with a uart reg-shift of 0 is unintentional, it needs updated to 2 so drivers can assume 2 on riscv64. diff --git a/results/classifier/deepseek-2/output/device/1460 b/results/classifier/deepseek-2/output/device/1460 new file mode 100644 index 000000000..dcf6aea3f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1460 @@ -0,0 +1,6 @@ + +block_load fails if last block is included in snapshot and block device isn't multiple of BLK_MIG_BLOCK_SIZE +Description of problem: +The `block_load` function in `migration/block.c` has a bug where `blk_pwrite` or `blk_pwrite_zeroes` always write `cluster_size` bytes. If the underlying device is not a multiple of `BLK_MIG_BLOCK_SIZE`, the write will fail with -EIO when trying to write past the end of the device, as `blk_check_byte_request` checks the length of the device. + +This can be fixed by ensuring that `cur_addr` + write length passed to `blk_pwrite`/`blk_pwrite_zeroes` never exceeds the total length of the block device. diff --git a/results/classifier/deepseek-2/output/device/1465 b/results/classifier/deepseek-2/output/device/1465 new file mode 100644 index 000000000..73617f41f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1465 @@ -0,0 +1,2 @@ + +MBR/Partition table corruption/loss , probably related to virtual sata disks and backup diff --git a/results/classifier/deepseek-2/output/device/1468 b/results/classifier/deepseek-2/output/device/1468 new file mode 100644 index 000000000..792e37a22 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1468 @@ -0,0 +1,7 @@ + +qemu hangs on white windows when connecting to virtual port using -serial option when using Windows OS +Description of problem: +I was trying to connect windbg with a qemu vm. +First I try using named pipes but all the tutorials I found online result in the qemu windows not even showing. So I give up and trying to use virtual COMs to connect the qemu machine with windbg over serial port. So I created using professional Virtual come driver a link between COM2 and COM4. Now I run qemu with -serial COM2 and I do not run windbg than it run correctly and no problem is present. As soon as I run windbg qemu hangs at startup just after the main window is created. The qemu window remains white and windows shows the normal "The application is not responding". It's like the program is in a infinite loop situation. +Also I noted that If I run qemu and not windbg as soon as the other COM port is connected qemu would stop working and remain frozed. Again showing the "The application is not responding". +If instead of qemu I use other "commercial" software with the same setup (of course there I could use named pipes anyway) I can connect windbg with the machine and do the debug session. diff --git a/results/classifier/deepseek-2/output/device/147 b/results/classifier/deepseek-2/output/device/147 new file mode 100644 index 000000000..1ba41df59 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/147 @@ -0,0 +1,2 @@ + +Interacting with NetBSD serial console boot blocks no longer works diff --git a/results/classifier/deepseek-2/output/device/1470536 b/results/classifier/deepseek-2/output/device/1470536 new file mode 100644 index 000000000..26cd71c5f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1470536 @@ -0,0 +1,13 @@ + +qemu-img incorrectly prints "qemu-img: Host floppy pass-through is deprecated" + +qemu-img incorrectly prints this warning when you use /dev/fd/<NN> to pass in file descriptors. A simple way to demonstrate this uses bash process substitution, so the following will only work if you are using bash as your shell: + +$ qemu-img info <( cat /dev/null ) +qemu-img: Host floppy pass-through is deprecated +Support for it will be removed in a future release. +qemu-img: Could not open '/dev/fd/63': Could not refresh total sector count: Illegal seek + +The root cause is a bug in block/raw-posix.c:floppy_probe_device() where it thinks anything starting with /dev/fd is a floppy drive, which is not the case here: + +http://git.qemu.org/?p=qemu.git;a=blob;f=block/raw-posix.c;h=cbe6574bf4da90a124436a40422dce3667da71e6;hb=HEAD#l2425 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1472 b/results/classifier/deepseek-2/output/device/1472 new file mode 100644 index 000000000..046aecdb7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1472 @@ -0,0 +1,6 @@ + +Parameter 'sgx-epc.0.node' is unexpected +Description of problem: +qemu-system-x86_64: Parameter 'sgx-epc.0.node' is unexpected +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1476183 b/results/classifier/deepseek-2/output/device/1476183 new file mode 100644 index 000000000..ee693c080 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1476183 @@ -0,0 +1,18 @@ + +can not create 4 serial port on window (guest os) + +qemu ver: 2.1.2-Latest + +guest os: window 7 64bit with 2 cpu + +problem: when qemu start with 4 serial port, on linux(rhel 7) guest os, /dev/ttyS0-4 is work fine. but on window 7 guest os, only show com1,com2 in device manager, how to get com3 & com4 ? + +qemu cmd: + -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0 + -device isa-serial,chardev=charserial0,id=serial0 + -chardev spiceport,id=charserial1,name=org.qemu.console.serial.1 + -device isa-serial,chardev=charserial1,id=serial1 + -chardev spiceport,id=charserial2,name=org.qemu.console.serial.2 + -device isa-serial,chardev=charserial2,id=serial2 + -chardev spiceport,id=charserial3,name=org.qemu.console.serial.3 + -device isa-serial,chardev=charserial3,id=serial3 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1481750 b/results/classifier/deepseek-2/output/device/1481750 new file mode 100644 index 000000000..9029b3f91 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1481750 @@ -0,0 +1,19 @@ + +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' \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1483 b/results/classifier/deepseek-2/output/device/1483 new file mode 100644 index 000000000..33219fd25 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1483 @@ -0,0 +1,2 @@ + +Failed to mount pmem device in qemu diff --git a/results/classifier/deepseek-2/output/device/1485 b/results/classifier/deepseek-2/output/device/1485 new file mode 100644 index 000000000..677a6230d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1485 @@ -0,0 +1,13 @@ + +hw/at24c : not support 1 byte-address with eeprom size less than 256 byte +Description of problem: +I created the new platform base on aspeed/fuji, +that uses the virtual eeprom (at24c), some eeprom used 24c02, which size 256 bytes. +but when using /hw/at24c.c, the result will not same the real device. +Steps to reproduce: +1. create a machine with EEPROM size less then or equal 256 bytes +2. start the qemu +3. use i2cget/i2cset/i2cdump to write and display eeprom data +Additional information: +I fixed and validated, refer +https://gitlab.com/ssinprem/qemu/-/tree/at24c-1-byte-address-mode diff --git a/results/classifier/deepseek-2/output/device/1486768 b/results/classifier/deepseek-2/output/device/1486768 new file mode 100644 index 000000000..892666378 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1486768 @@ -0,0 +1,18 @@ + +BlackMagic USB3 video capture returns only blank frames in Windows (xHCI issue) + +Hi, + +I've got an Intensity Shuttle USB3; it's a HDMI video capture card. It doesn't have any Linux drivers, so I'm trying to get it to work in a Windows 10 guest inside QEMU. I'm running latest git as of today (2015-08-20). I use this command line: + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -device nec-usb-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x1edb,productid=0xbd3b -usbdevice tablet + +(I will add that the seemingly logical “host:1edb:bd3b,bus=xhci.0” did _not_ add the device at all. I don't know why, probably some parser issue?) + +The card is properly detected, and the driver thinks everything is fine, running on the virtualized USB3 host and all. Looking at usbmon, there's lots of isochronous frames during capture, and they reach the host (looking at USBpcap on the Windows 10 side). However, the driver refuses to capture any video—all frames become black in all applications I try (well, Media Express seems to hardly store any frames at all in the .avi). However, audio is captured without a hitch. Curiously enough, no dropped frames are reported. There's no sign of CPU shortage; both host and guest seem to be happy around 20% of one core. + +I am fairly certain this is an issue with the xHCI driver in QEMU, because if I give it the entire USB controller via VT-d, it works flawlessly, with video and all. For reference, here's the associated command line I use for that (after I've unbound it from the Linux system): + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -usbdevice tablet -device pci-assign,host=00:14.0 + +I can get USB pcap logs from both sides if you want, but they are huge (gigabytes) since the data rate is so high. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1488363 b/results/classifier/deepseek-2/output/device/1488363 new file mode 100644 index 000000000..c62957e80 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1488363 @@ -0,0 +1,54 @@ + +qemu 2.4.0 hangs using vfio for pci passthrough of graphics card + +2.3.0 (manjaro distro package) works fine. 2.4.0 (manjaro or the arch vanilla one) hangs on the SeaBIOS screen when saying "Press F12 for boot menu". All tested with the same hardware, OS, command and configuration. It also starts without the GPU passed through, even with the USB passed through. I am using the latest SeaBIOS 1.8.2. + +The release notes say: + VFIO + Support for resetting AMD Bonaire and Hawaii GPUs + Platform device passthrough support for Calxeda xgmac devices + +So maybe something there broke it. + +I am using the arch qemu 2.4.0 PKGBUILD (modified to have make -j8 and removed iscsi, gluster, ceph, etc.), which uses vanilla sources and no patches. https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qemu + +I am not using a frontend. I am using a script I wrote that generates the command below. + +Guest OS here would be 64 bit windows 7, but it didn't start so that's not relevant. Also a Manjaro Linux VM won't start. + +CPU is AMD FX-8150; board is Gigabyte GA-990FXA-UD5 (990FX chipset). + +full command line (without the \ after each line) is: + +qemu-system-x86_64 + -enable-kvm + -M q35 + -m 3584 + -cpu host + -boot c + -smp 7,sockets=1,cores=7,threads=1 + -vga none + -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 + -device vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom + -device vfio-pci,host=00:14.2,bus=pcie.0 + -device vfio-pci,host=00:16.0,bus=root.1 + -device vfio-pci,host=00:16.2,bus=root.1 + -usb + -device ahci,bus=pcie.0,id=ahci + -drive file=/dev/data/vm1,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on + -drive media=cdrom,id=cdrom,index=5,media=cdrom + -netdev type=tap,id=net0,ifname=tap-vm1 + -device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05 + -monitor stdio + -boot menu=on + + +$ lspci -nn | grep -E "04:00.0|00:14.2|00:16.0|00:16.2" +00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) +00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] +00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] +04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X] [1002:6658] + + +Also I have this one that also hangs: +05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba] \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1490 b/results/classifier/deepseek-2/output/device/1490 new file mode 100644 index 000000000..a5f4493e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1490 @@ -0,0 +1,62 @@ + +Keystrokes for F13-24 are not forwarded by an evdev input device +Description of problem: +Currently, keystrokes for F13-F24 are not forwarded by an evdev input device. +Steps to reproduce: +``` +/usr/bin/qemu-system-x86_64 \ +-name guest=win10,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-11-win10/master-key.aes"}' \ +-machine pc-q35-7.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \ +-m 4096 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=4,threads=1 \ +-uuid ca2e9d01-6e02-4aa7-9feb-7846499f7d8a \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.1","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/tmp/win10.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 '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":2}' \ +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' \ +-audiodev '{"id":"audio1","driver":"spice"}' \ +-spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ +-device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.2","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +``` + +This is probably not a minimal example, but I didn't know how to generate one. I think the only relevant lines are these: +``` +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' +``` diff --git a/results/classifier/deepseek-2/output/device/1490886 b/results/classifier/deepseek-2/output/device/1490886 new file mode 100644 index 000000000..f5161294f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1490886 @@ -0,0 +1,33 @@ + +spice-qemu-char.c Assert + +spice-qemu-char.c:173: spice_chr_add_watch: Assertion `cond == G_IO_OUT' failed. +I trace the code virtio-console.c: +ret = qemu_chr_fe_write(vcon->chr, buf, len); + trace_virtio_console_flush_buf(port->id, len, ret); + + if (ret < len) { + VirtIOSerialPortClass *k = VIRTIO_SERIAL_PORT_GET_CLASS(port); + + /* + * Ideally we'd get a better error code than just -1, but + * that's what the chardev interface gives us right now. If + * we had a finer-grained message, like -EPIPE, we could close + * this connection. + */ + if (ret < 0) + ret = 0; + if (!k->is_console) { + virtio_serial_throttle_port(port, true); + if (!vcon->watch) { + vcon->watch = qemu_chr_fe_add_watch(vcon->chr, + G_IO_OUT|G_IO_HUP, + chr_write_unblocked, vcon); + } + } + } +and spice-qemu-char.c in function:spice_chr_add_watch +assert(cond == G_IO_OUT); +so run in this code,will trigger this assert. + +My qemu version is 2.3.0 and spice-server version is 0.12.5 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1499908 b/results/classifier/deepseek-2/output/device/1499908 new file mode 100644 index 000000000..4558c42b6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1499908 @@ -0,0 +1,56 @@ + +hda sound capture broken with VNC + +QEmu is being used to run the Wine conformance tests in Windows virtual machines. Wine's conformance tests check the behavior of various Windows APIs and verify that they behave as expected. One of the tests checks the behavior of the mmdevapi sound capture APIs. This test works fine on real hardware and also works fine in various QEmu VMs but fails in some others. Further investigation showed that: + + * The mmdevapi:capture tests work on the two Vista VMs. Those use the ac97 sound card and are configured for VNC access to the VM. + + * The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an hda sound card and are configured for VNC access to the VM (so '-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0'). + + * Furthermore configuring the VM for Spice access fixes the mmdevapi:capture test (so replacing -vnc with '-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'), this even if no client connects to the VM. + +So in effect the -spice and -vnc options change the behavior of the sound device. + +To reproduce this bug: +1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt). +2. Set it up for access using VNC. +3. Copy the attached mmdevapi_test.exe file to it. (*) +4. Run the tests as follows: + mmdevapi_test.exe capture + +If you see these 'Test Failed' lines then the bug is still present: + +capture.c:586: Returned latency: 5.8050 ms +capture.c:178: Test failed: Position 1015 expected 0 +capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked: 448 +capture.c:228: Test failed: Position 2167 expected 1463 +capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames locked: 448 +capture.c:256: Test failed: Position 2167 expected 1463 +capture.c:292: GetBufferSize 21996 period size 448 +capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames locked: 448 +capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996 +capture.c:313: Test failed: Position 4215 gap 2304 +capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames locked: 448 +capture.c:333: Test failed: Position 5303 expected 4663 +capture.c:334: Test failed: flags 1 +capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames locked: 448 +capture.c:358: Test failed: Position 7351 expected 5111 +capture.c:359: Test failed: flags 1 + +In case it helps, here is the source of mmdevapi_test.exe: +https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178 + + +So far I have confirmed that this bug is present in QEmu as shipped in the following Debian packages: + * qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 + linux-image-3.16.0-4-amd64 3.16.7-ckt11-1+deb8u3 + * qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1 + + +(*) As alternatives to using the attached binary you can: +- Compile it from Wine's source. See: + https://source.winehq.org/git/wine.git/ + +- Or download the latest WineTest binary from https://test.winehq.org/builds/winetest-latest.exe + And extract the mmdevapi_test.exe from there: + winetest.exe -x tests + tests\mmdevapi_test.exe capture \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1500175 b/results/classifier/deepseek-2/output/device/1500175 new file mode 100644 index 000000000..1d964fd2b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1500175 @@ -0,0 +1,38 @@ + +unable to init msix vectors + +Using the latest stable (2.4.0.1) and earlier releases (at least down to 2.3.1), I am unable to run a qemu-system-arm virtualization on a Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. + +Command line: + +qemu-system-arm -device virtio-net,netdev=user.0 -drive file=pack,if=virtio,cache=writeback,discard=ignore -netdev user,id=user.0,hostfwd=tcp::3499-:22 -cdrom /opt/node-4.1.0/packer/2015-05-05-raspbian-wheezy.img -m 512M -boot once=d -vnc 0.0.0.0:87 -name packer-qemu -machine type=versatilepb -nographic + +Output: + +qemu-system-arm: -device virtio-net,netdev=user.0: unable to init msix vectors to 3 +qemu-system-arm: -drive file=pack,if=virtio,cache=writeback,discard=ignore: unable to init msix vectors to 2 +qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000 + +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=10000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +FPSCR: 00000000 +[1] 1322 abort qemu-system-arm -device virtio-net,netdev=user.0 -drive -netdev -cdrom -m \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1502613 b/results/classifier/deepseek-2/output/device/1502613 new file mode 100644 index 000000000..a62956284 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1502613 @@ -0,0 +1,8 @@ + +[Feature Request] Battery Status / Virtual Battery + +When using virtualization on notebooks heavily then virtual machines do not realize that they're running on a notebook device causing high power consumption because they're not switching into a optimized "laptop mode". This leads to the circumstance that they are trying to do things like defragmentation / virtus scan / etc. while the host is still running on batteries. + +So it would be great if QEMU / KVM would have support for emulating "Virtual Batteries" to guests causing them to enable power-saving options like disabling specific services / devices / file operations automatically by OS. + +Optionally a great feature would be to set virtual battery's status manually. For example: Current charge rate / charging / discharging / ... \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1504 b/results/classifier/deepseek-2/output/device/1504 new file mode 100644 index 000000000..62f69d282 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1504 @@ -0,0 +1,2 @@ + +Implement Synopsys DesignWare PCI-I2C adapter model diff --git a/results/classifier/deepseek-2/output/device/1509336 b/results/classifier/deepseek-2/output/device/1509336 new file mode 100644 index 000000000..cd1ac79cc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1509336 @@ -0,0 +1,54 @@ + +USB passthru not work with Mac OS X El Capitan + +QEMU emulator version 2.4.50 with kernel kvm module from linux kernel 3.16.0 or 4.2.3 + +Since upgrading from Yosemite to El Capitan - USB passthru does not work. Note USB passthru worked perfectly with Maverick and Yosemite. I attempt to use different USB hosts. I found a patch for widows xp that had similar problem the patch was applied in 2012. Note NO problems with USB passthru with windows or linux clients. If it matters the devices that I am trying to passthru USB are smartcard reader and webcam. The devices are present in El Capitan but do not function. + +These are the massages from loading the VM (El Capitan). The first two lines are from the clover bootloader. The ehci warnings are generated when loading Mac Os X El Capitan. + +QEMU 2.4.50 monitor - type 'help' for more information +### These messages below started when using the clover bootloader and occur when loading El Capitan, Maverick or Yosemite. +### The bootloader is Clover version 3292 +(qemu) ehci: PERIODIC list base register set while periodic schedule + is enabled and HC is enabled +ehci: ASYNC list address register set while async schedule + is enabled and HC is enabled + +#### Below are errors when the guest host (El Capitan) is loading from qemu monitor. The messages below only occur when loading El Capitan. +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC + +This is the errors from the guest os - Mac Os X - El Capitan +000000.580358 AppleUSBLegacyRoot@: AppleUSBLegacyRoot::init: enabling legacy matching +000001.803455 AppleUSBEHCIPCI@fd000000: AppleUSBEHCI::WaitForAsyncSchedule: USBC +MD (0x00080020) and USBSTS (0x00001000) did not synchronize + +the following qemu command has worked flawlessly with Yosemite and Maverick. +qemu-system-x86_64 -enable-kvm -m 4096 -cpu core2duo -machine q35 \ +-bios /usr/local/share/qemu/bios.bin \ +-name "El Capitan" \ +-mem-path /hugetlbfs \ +-rtc base=utc,clock=vm,driftfix=slew \ +-balloon none \ +-parallel none \ +-smp 4,sockets=1,cores=2,threads=2 \ +-boot menu=on \ +-usb -device usb-kbd -device usb-mouse \ +-device usb-host,vendorid=0x0455,productid=0x0777 \ +-vga std \ +-monitor stdio \ +-device isa-applesmc,osk="youknowwhatitis" \ +-smbios type=2 \ +-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \ +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-device e1000-82545em,netdev=hub0port0,id=mac_vnet0,mac=62:64:44:34:64:54 \ +-netdev bridge,id=hub0port0,br=br0,helper=/usr/local/libexec/qemu-bridge-helper \ +-device ide-drive,bus=ide.0,drive=elcapitan \ +-drive id=elcapitan,format=qcow2,if=none,file=./iElCapitan.qcow2 + +If anything else I can do to debug the problem please let me know. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/151 b/results/classifier/deepseek-2/output/device/151 new file mode 100644 index 000000000..187408f7b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/151 @@ -0,0 +1,2 @@ + +virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit diff --git a/results/classifier/deepseek-2/output/device/1511887 b/results/classifier/deepseek-2/output/device/1511887 new file mode 100644 index 000000000..70478d922 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1511887 @@ -0,0 +1,35 @@ + +USB device 1.1 not correctly passedthru from Linux host to Windows guest + +I have USB Digital Oscilloscope which works great on pure Windows machine but not work on virtualized one. I tried passthru the device from my Debian Jessie (64bit) host machine to Windows 7 (32bit) guest machine but unfortunately it does not work very well. It looks that device is passed thru so Windows machine knows about new device and loads HID device driver for it but the device driver failed to start the device and details of an error provided by device manager is "This device cannot start" Code 10. + +Installed Qemu version: 2.1+dfsg-12+deb8u4 0 + +USB device spec: Dynon Instruments ELAB-080, USB 1.1 + +On linux host computer +--------------------------- +lsusb identify it as: +Bus 003 Device 009: ID 13a3:0001 + +lsusb -t identify it as: +/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M + |__ Port 1: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 12M + +This is how I started my Windows guest machine +------------------------------------------------------ +kvm -cpu host \ + -m 2048MiB \ + -hda test.vdi \ + -ctrl-grab \ + -parallel /dev/parport0 \ + -usbdevice host:13a3:0001 + +...also instead of last line I tried this one: + -device usb-host,vendorid=0x13a3,productid=0x0001 + +none of them help to properly handle my device inside guest machine. + +Only one time the Windows guest machine properly start the device so software for that oscilloscope can identify the Oscilloscope and measure for a while but unfortunately after I guess 5 seconds of measurement the device was disconnected from Windows and never start working again even after couple of restarts of guest machine even after plug and unplug it's USB cable and power cable. + +I searched for a solution or some clues to get it work but none of my searching over the internet was successful. Because device works on pure Windows but not work on virtualized one, I think there is a problem with handling not standard USB devices (like sticks, keyboards, mouses etc.) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1518969 b/results/classifier/deepseek-2/output/device/1518969 new file mode 100644 index 000000000..b1a630a16 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1518969 @@ -0,0 +1,29 @@ + +Instance of QEMU doesn't unplug virtio scsi disk after device_del and drive_del commands + +device_del and drive_del commands don't cause virtio disk detaching + +Steps to reproduce: +1. Run instance + +2. Attach virtio scsi disk + +3. Reboot instance + +4. Immediately after reboot detach disk with QEMU commands: +device_del +drive_del + +Expected result: +Disk should be detached anyway + +Actual: +Domain info contains attached disk even after waiting long period of time(5 min in my case). + +Additional info: +QEMU process: +root 29010 42.6 1.9 562036 61272 ? Rl 03:42 0:01 /usr/bin/qemu-system-x86_64 -name instance-00000069 -S -machine pc-i440fx-trusty,accel=tcg,usb=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid d2418536-2547-4740-96b5-0d4f1d74b9f3 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=1fd8f69a-909b-4ed1-aae9-4fc9318fc622,uuid=d2418536-2547-4740-96b5-0d4f1d74b9f3,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000069.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/kernel -initrd /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/ramdisk -append root=/dev/vda console=tty0 console=ttyS0 no_timer_check -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk.config,if=none,id=drive-ide0-1-1,readonly=on,format=raw,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=18,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:1a:10:3d,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +QEMU version: +qemu-system-x86_64 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.19), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1519 b/results/classifier/deepseek-2/output/device/1519 new file mode 100644 index 000000000..f5a8e2f93 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1519 @@ -0,0 +1,13 @@ + +audio recording not working on qemu +Description of problem: +QEMU fails to record audio from the guest even when the device options hda-duplex and hda-micro options are used. Tried using the other available audio backends (alsa and sdl) but recording on the guest still fails +Steps to reproduce: +1. run the qemu command line above with any of the available audio backends +2. record audio on the guest +3. arecord -vv -d 5 recordng.wav +4. there's an attempt to record but it hangs +5. play recorded audio, there's no output +6. aplay recordng.wav +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1521 b/results/classifier/deepseek-2/output/device/1521 new file mode 100644 index 000000000..bb83f38e5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1521 @@ -0,0 +1,2 @@ + +USB HID not using the keycodemapdb and thus lacking new entries diff --git a/results/classifier/deepseek-2/output/device/1522 b/results/classifier/deepseek-2/output/device/1522 new file mode 100644 index 000000000..940036348 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1522 @@ -0,0 +1,41 @@ + +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/deepseek-2/output/device/1523 b/results/classifier/deepseek-2/output/device/1523 new file mode 100644 index 000000000..baf49ff7a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1523 @@ -0,0 +1,2 @@ + +Tricore: no interrupts emulation diff --git a/results/classifier/deepseek-2/output/device/1523246 b/results/classifier/deepseek-2/output/device/1523246 new file mode 100644 index 000000000..0918f4fdf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1523246 @@ -0,0 +1,16 @@ + +Virtio-blk does not support TRIM + +When model=virtio is used, TRIM is not supported. + +# mount -o discard /dev/vda4 /mnt +# mount | tail -1 +/dev/vda4 on /mnt type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) +# fstrim /mnt/ +fstrim: /mnt/: the discard operation is not supported + +Booting without model=virtio allows using TRIM (in Windows as well). + +Full QEMU line: + +qemu-system-x86_64 -enable-kvm -cpu host -bios /usr/share/ovmf/ovmf_x64.bin -smp 2 -m 7G -vga qxl -usbdevice tablet -net nic,model=virtio -net user -drive discard=unmap,detect-zeroes=unmap,cache=none,file=vms/win10.hd.img.vmdk,format=vmdk,if=virtio \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1525 b/results/classifier/deepseek-2/output/device/1525 new file mode 100644 index 000000000..dfaad84c0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1525 @@ -0,0 +1,79 @@ + +Wrong initial value of stack pointer on AVR devices +Description of problem: +The initial value of stack pointer of AVR MCUs should be RAMEND (address of the end of their RAM), but QEMU initialize them to 0. + +`qemu-system-avr -machine help` lists 4 flavors of MCUs which are ATmega168, ATmega2560, ATmega1280, ATmega328P. According to their datasheets, the stack pointer should be initialized as follows on reset. + +- [ATmega168](https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=12): RAMEND (which is 0x04FF) +- [ATmega2560 and ATmega1280](https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf#page=15): RAMEND (which is 0x21FF) +- [ATmega328P](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#page=22): RAMEND (which is 0x08FF) +Steps to reproduce: +1. Assemble the assembly code below: `avrasm2 -fI test.asm` + + ```asm + ;; test.asm + .INCLUDE "m328Pdef.inc" + + .EQU F_CPU = 16000000 + .EQU BAUD_RATE = 9600 + .EQU PRESCALE = (F_CPU / (16 * BAUD_RATE)) - 1 + + .CSEG + start: + ;; initialize USART (serial port) + LDI R16, LOW(PRESCALE) + LDI R17, HIGH(PRESCALE) + STS UBRR0L, R16 + STS UBRR0H, R17 + LDI R16, (1 << RXEN0) | (1 << TXEN0) + STS UCSR0B, R16 + + ;; Get stack pointer low byte and print it in ASCII + IN R16, SPL + LDI R17, 0x30 + ADD R16, R17 + print1: + LDS r17, UCSR0A + SBRS r17, UDRE0 + RJMP print1 + STS UDR0, r16 + + ;; Get stack pointer high byte and print it in ASCII + IN R16, SPH + LDI R17, 0x30 + ADD R16, R17 + print2: + LDS r17, UCSR0A + SBRS r17, UDRE0 + RJMP print2 + STS UDR0, r16 + + end: + RJMP end + ``` + +2. Convert it to bin file: `avr-objcopy --input-target=ihex --output-target=binary test.hex test.bin` + +3. Run it with QEMU: `qemu-system-avr -machine uno -bios test.bin -serial stdio` + +This should print 00 which means that the stack pointer is initialized to 0. +Additional information: +I examined the source code and I think that editing the function `avr_cpu_reset_hold` in `/target/avr/cpu.c` might fix this issue. This is my first time seeing QEMU source code, so I might be wrong, though. + +```c +// in /target/avr/cpu.c line 70 +static void avr_cpu_reset_hold(Object *obj) +{ + // ... + + env->rampD = 0; + env->rampX = 0; + env->rampY = 0; + env->rampZ = 0; + env->eind = 0; + env->sp = 0; // <-- change this value in accordance with board type? + + //... +} +``` diff --git a/results/classifier/deepseek-2/output/device/1526 b/results/classifier/deepseek-2/output/device/1526 new file mode 100644 index 000000000..fd608d380 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1526 @@ -0,0 +1,2 @@ + +hw/vfio/trace-events incorrect format diff --git a/results/classifier/deepseek-2/output/device/1529449 b/results/classifier/deepseek-2/output/device/1529449 new file mode 100644 index 000000000..78dd37eae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1529449 @@ -0,0 +1,4 @@ + +serial is required for -device nvme + +I am not exactly sure if this is a bug, but I don't see why the option "serial" is required for -device nvme like drive. Truth is it seem to accept random string as its value anyway, if that's the case, couldn't qemu just generate one for it when it's not specified? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1529859 b/results/classifier/deepseek-2/output/device/1529859 new file mode 100644 index 000000000..38d0dea05 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1529859 @@ -0,0 +1,49 @@ + +qemu 2.5.0 ivshmem segfault with msi=off option + +Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev socket,path=/tmp/ivshmem_socket,id=ivshmemid" + +Causes segfault because, s->msi_vectors is not initialized and s->msi_vectors == 0. + +Does ivshmem exactly need this line ? : + +s->msi_vectors[vector].pdev = pdev; + +It makes no sence for me. + +Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault + +--- + hw/misc/ivshmem.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +index f73f0c2..2087d5e 100644 +--- a/hw/misc/ivshmem.c ++++ b/hw/misc/ivshmem.c +@@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * + int eventfd = event_notifier_get_fd(n); + CharDriverState *chr; + +- s->msi_vectors[vector].pdev = pdev; +- + chr = qemu_chr_open_eventfd(eventfd); + + if (chr == NULL) { +@@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) + } + + if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +- msix_uninit_exclusive_bar(dev); ++ msix_uninit_exclusive_bar(dev); + } +- +- g_free(s->msi_vectors); ++ ++ if(s->msi_vectors) ++ g_free(s->msi_vectors); + } + + static bool test_msix(void *opaque, int version_id) +-- +2.3.6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1530035 b/results/classifier/deepseek-2/output/device/1530035 new file mode 100644 index 000000000..785ce5ee5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1530035 @@ -0,0 +1,24 @@ + +usb-host: ATI Technologies, Inc. TV Wonder acts as a different device if used + +Title says it all. If you try to use the "ATI Technologies, Inc. TV Wonder" USB 1.1 TV Tuner for passthrough under any OS that has drivers for the device, the usb-host driver will confuse itself and give the device a new PID number for Linux. + +Tested on ReactOS and Windows XP with stable QEMU package from pacman on Arch Linux. + +Commands used: sudo qemu-system-x86_64 -enable-kvm -hda ~/QEMU/hd/winxp.img -usb -device usb-host,hostbus=2,hostaddr=3 -vga vmware + +Before starting qemu-kvm, lsusb reports: +[ +Bus 002 Device 003: ID 0528:7561 ATI Technologies, Inc. TV Wonder +] + +After starting qemu-kvm, usb-host and lsusb report: +[ +libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/003: No such file or directory + +The device in Bus 2, Device 3 is gone and it appears as this instead: +Bus 002 Device 005: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) D-Link V100 +] + +This weird effect only lasts until you unplug the TV Wonder. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1530278 b/results/classifier/deepseek-2/output/device/1530278 new file mode 100644 index 000000000..3b2fce91b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1530278 @@ -0,0 +1,13 @@ + +vhost-user: can not detach chardev which is used by vhost-user backend + +I launch a VM which use vhost-user netdevice as follows.When detach the netdevice in qemu monitor, the chardevice which used by the netdevice also should be deatched.The netdevice can be detached sucessfully.But the chardevice failed when it was being detaching. +Full command line : +qemu-system-x86_64 \ +-cpu host -boot c -hda /home/lining/ubuntu_12_04.img -snapshot -m 2048 -smp 2 \ +--enable-kvm -name "client1" -vnc :1 \ +-object memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem \ +-chardev socket,id=chr1,path=/opt/network/ovdk/bin/vhost-user \ +-netdev vhost-user,id=net12,chardev=chr1,ifname=port80, vhostforce \ +-device virtio-net-pci,netdev=net12,mac=00:00:00:00:00:01,\ +csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off,any_layout=off \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1539 b/results/classifier/deepseek-2/output/device/1539 new file mode 100644 index 000000000..60f38c1e7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1539 @@ -0,0 +1,4 @@ + +Support for SPC58NH92C5 +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1543057 b/results/classifier/deepseek-2/output/device/1543057 new file mode 100644 index 000000000..1ac4a8920 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1543057 @@ -0,0 +1,17 @@ + +Warnings are treated as errors + +System: Ubuntu 14.04, 32bit +Kernel: 3.13.0-55-generic +Qemu: v. 2.2.50 + +Error msg: + +hw/acpi/pcihp.c: In function ‘acpi_pcihp_pc_no_hotplug’: +hw/acpi/pcihp.c:117:34: error: ‘PCIDevice’ has no member named ‘qdev’ + return (pc->is_bridge && !dev->qdev.hotplugged) || !dc->hotpluggable; + ^ +hw/acpi/pcihp.c:118:1: error: control reaches end of non-void function [-Werror=return-type] + } + ^ +cc1: all warnings being treated as errors \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1544524 b/results/classifier/deepseek-2/output/device/1544524 new file mode 100644 index 000000000..5166298a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1544524 @@ -0,0 +1,23 @@ + +"info chardev" not showing the real port in use + +With Qemu 2.1.2 +============== +pharidos@uks2:~/work/tplaf/☸ qemu-system-x86_64 -hda /space/pharidos/Disks/Blank_disk.qcow2 -serial telnet::0,server,nowait -nographic +QEMU 2.1.2 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=telnet:0.0.0.0:44189,server <====<<< serial console is using port 44189 +compat_monitor0: filename=stdio +(qemu) + + +With Qemu 2.5.0 +============== +pharidos@kvm:~/$ qemu-system-x86_64 -hda /space/pharidos/Disks/Blank_disk.qcow2 -serial telnet::0,server,nowait -nographic +QEMU 2.5.0 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=disconnected:telnet::0,server <====<<< serial console port not shown +compat_monitor0: filename=stdio +(qemu) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1550743 b/results/classifier/deepseek-2/output/device/1550743 new file mode 100644 index 000000000..c2d819b4a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1550743 @@ -0,0 +1,27 @@ + +connect low speed host devices to qemu ehci does not work + +$ qemu-system-i386 -hda my_x86.img -device ich9-usb-ehci1,id=ehci -device usb-host,vendorid=0x045e,productid=0x071d -serial stdio +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) + +Which is obviously wrong. The ehci specification states: + +Low-speed device, release ownership of port <= Table 2-16. + +Table 2-6: + +Number of Companion Controller (N_CC). This field indicates the number of +companion controllers associated with this USB 2.0 host controller. +A zero in this field indicates there are no companion host controllers. Port-ownership +hand-off is not supported. Only high-speed devices are supported on the host controller +root ports. +A value larger than zero in this field indicates there are companion USB 1.1 host +controller(s). Port-ownership hand-offs are supported. High, Full- and Low-speed +devices are supported on the host controller root ports. + +Which is not longer true, as for example skylake and baytrail offers a dual usb stack of ehci and xhci. In that case, EHCI handles the low speed device as well. + +brgds, +Bert \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1563 b/results/classifier/deepseek-2/output/device/1563 new file mode 100644 index 000000000..d6b8bee80 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1563 @@ -0,0 +1,4 @@ + +lsi53c895a: DMA reentrancy issue leads to stack overflow (CVE-2023-0330) +Description of problem: +See https://bugzilla.redhat.com/show_bug.cgi?id=2160151. diff --git a/results/classifier/deepseek-2/output/device/1568621 b/results/classifier/deepseek-2/output/device/1568621 new file mode 100644 index 000000000..7b96ff35a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1568621 @@ -0,0 +1,19 @@ + +input-linux misdetects Logitech keyboard as a mouse + +The new input-linux.c code misdetects my Logitech K350 keyboard as a mouse. The bug is in the input_linux_complete function. The evdev for this keyboard returns an "evtmap" with the EV_REL bit set. Full evtmap is 0x0012001F. Using a different keyboard everything works as intended, so my configuration and setup are correct otherwise. + + +Suggestion: + +I suggest adding an object property called something like "type" where the user can specify what the device type is manually. This K350 keyboard shows that "evtmap" cannot be used to reliably detect the device type. Since specifying the device type manually is not an undue burden, perhaps it should be a required option and there should be no autodetection? + + +System: + +Arch linux, using qemu-git AUR package installed 20160409. + + +Command line: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/sbin/qemu-system-x86_64 -name win10,debug-threads=on -S -machine pc-i440fx-2.4,accel=kvm,usb=off,vmport=off -cpu host,kvm=off -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 -m 8196 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 58623778-9d9d-4d30-8ec0-b37e12a30fdc -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-17-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/var/lib/libvirt/images/ISOs/Win10_1511_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/ISOs/virtio-win-0.1.112.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sda,format=raw,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:70:8a:db,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=d4:be:d9:56:2e:35,bus=pci.0,addr=0x9 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device vfio-pci,host=04:00.0,id=hostdev0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object input-linux,id=kbd1,evdev=/dev/input/event19,grab_all=on -object input-linux,id=kbb2,evdev=/dev/input/event2 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1569 b/results/classifier/deepseek-2/output/device/1569 new file mode 100644 index 000000000..4cbcf1bb4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1569 @@ -0,0 +1,28 @@ + +NVMe FS operations hang after suspending and resuming both guest and host +Description of problem: +Hello and thank you for your work on QEMU! + +Using the NVMe driver with my Seagate FireCuda 530 2TB M.2 works fine until I encounter this problem, which is reliably reproducible for me. + +When I suspend the guest and then suspend (s2idle) my host all is well until I resume the guest (manually with `virsh dompmwakeup $VMNAME`, after the host has resumed). Although the guest resumes and is interactive, it seems that anything involving filesystem operations hang forever and do not return. + +Suspending and resuming the Linux guest seems to work perfectly if I don't suspend/resume the host. + +Ultimately what I'm wanting to do is share the drive between VMs with qemu-storage-daemon. I can reproduce the problem in that scenario in much the same way. Using PCI passthrough with the same VM and device works fine and doesn't exhibit this problem. + +Hopefully that's clear enough - let me know if there's anything else I can provide. +Steps to reproduce: +1. Create a VM with a dedicated NVMe disk. +2. Boot an ISO and install to the disk. +3. Verify that suspend and resume works when not suspending the host. +4. Suspend the guest. +5. Suspend the host. +6. Wake the host. +7. Wake the guest. +8. Try just about anything that isn't likely already cached somewhere: `du -s /etc`. +Additional information: +I've attached the libvirt domain XML[1] and libvirtd debug logs for QEMU[2] ("1:qemu") that covers suspending the guest & host, resuming host & guest and doing something to cause a hang. I tried to leave enough time afterwards for any timeout to occur. + +1. [nvme-voidlinux.xml](/uploads/1dea47af096ce58175f7aa526eca455e/nvme-voidlinux.xml) +2. [nvme-qemu-debug.log](/uploads/42d3bed456a795069023a61d38fa5ccd/nvme-qemu-debug.log) diff --git a/results/classifier/deepseek-2/output/device/157 b/results/classifier/deepseek-2/output/device/157 new file mode 100644 index 000000000..0031d62bf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/157 @@ -0,0 +1,2 @@ + +Xbox One controller USB passthrough disconnections and stops diff --git a/results/classifier/deepseek-2/output/device/1572959 b/results/classifier/deepseek-2/output/device/1572959 new file mode 100644 index 000000000..284e74707 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1572959 @@ -0,0 +1,8 @@ + +bcm2835_property: inconsistent values when both setting and querying the framebuffer + +As the framebuffer settings are copied into the result message before it is reconfigured, inconsistent behavior can happen when, for instance, you set with a single message the width, height, and depth, and ask at the same time to allocate the buffer and get the pitch and the size. + +In this case, the reported pitch and size would be incorrect as they were computed with the initial values of width, height and depth, not the ones the client requested. + +Attached is a patch also sent to the qemu-devel mailing list. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1575 b/results/classifier/deepseek-2/output/device/1575 new file mode 100644 index 000000000..3f8c0b8c2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1575 @@ -0,0 +1,2 @@ + +how to implement a heterogeneous machine(several sysbus/mem map)? diff --git a/results/classifier/deepseek-2/output/device/1575561 b/results/classifier/deepseek-2/output/device/1575561 new file mode 100644 index 000000000..a2b9c2ac0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1575561 @@ -0,0 +1,7 @@ + +config qemu virtio_queue_size to 1024，create vm boot from network failed + +config qemu virtio_queue_size to 1024，create vm boot from network failed。 +in the vm vncviewer，see the error log： +“ERROR queue size 1024 > 256 +could not open net0: no such file or directory" \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1576 b/results/classifier/deepseek-2/output/device/1576 new file mode 100644 index 000000000..831118dc9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1576 @@ -0,0 +1,29 @@ + +Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails +Description of problem: +Loading the VM state fails with: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load pcie-root-port:parent_obj.parent_obj.parent_obj +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:1c.0/pcie-root-port' +qemu-system-x86_64: Error -22 while loading VM state +``` +Steps to reproduce: +Used the following script with the first argument being a build directory of v8.0.0-rc2 and the second a build directory of v7.2.0 +``` +#!/bin/bash +rm /tmp/disk.qcow2 +args=" + -device pcie-root-port,multifunction=on,bus=pcie.0,addr=1c.0,port=1,chassis=1 + -machine type=pc-q35-7.2" +$1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G +$1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF +{"execute": "qmp_capabilities"} +{"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } +{"execute": "quit"} +EOF +$2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap +``` +Additional information: +Bisecting shows that 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") is the first bad commit. diff --git a/results/classifier/deepseek-2/output/device/1576347 b/results/classifier/deepseek-2/output/device/1576347 new file mode 100644 index 000000000..33697e392 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1576347 @@ -0,0 +1,27 @@ + +Only one NVMe device is usable in Windows (10) guest + +Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +QEMU version: 2.5.0 + +Kernel: 4.5.1 (Arch Linux) + +When there are two NVMe devices specified, only the second one will be usable in Windows. The following error is shown under "Device status" of the failed NVMe controller in Device Manager: + +"This device cannot start. (Code 10) + +The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect." + +The only thing seems suspicious to me is that the nvme emulation in qemu does not have WWN/EUI-64 set for the devices, though I have no idea at all whether that is mandatory: + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1577 b/results/classifier/deepseek-2/output/device/1577 new file mode 100644 index 000000000..5bad61870 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1577 @@ -0,0 +1,85 @@ + +device_del return is already in the process of unplug frequently +Description of problem: +recently we update qemu 6.1.1 to qemu 7.1.0, and run into an issue with the following error: + +command '{ "execute": "device_del", "arguments": { "id": "virtio-diskX" } }' for VM "id" failed ({ "return": {"class": "GenericError", "desc": "Device virtio-diskX is already in the process of unplug"} }). + +The issue is reproducible. With a few seconds delay before hot-unplug, hot-unplug just works fine. + +After a few digging, we found that the commit 9323f892b39 may incur the issue. +------------------ + failover: fix unplug pending detection + + Failover needs to detect the end of the PCI unplug to start migration + after the VFIO card has been unplugged. + + To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in + pcie_unplug_device(). + + But since + 17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") + we have switched to ACPI unplug and these functions are not called anymore + and the flag not set. So failover migration is not able to detect if card + is really unplugged and acts as it's done as soon as it's started. So it + doesn't wait the end of the unplug to start the migration. We don't see any + problem when we test that because ACPI unplug is faster than PCIe native + hotplug and when the migration really starts the unplug operation is + already done. + + See c000a9bd06ea ("pci: mark device having guest unplug request pending") + a99c4da9fc2a ("pci: mark devices partially unplugged") + + Signed-off-by: Laurent Vivier <lvivier@redhat.com> + Reviewed-by: Ani Sinha <ani@anisinha.ca> + Message-Id: <20211118133225.324937-4-lvivier@redhat.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +------------------ +The purpose is for detecting the end of the PCI device hot-unplug. However, we feel the error confusing. How is it possible that a disk "is already in the process of unplug" during the first hot-unplug attempt? So far as I know, the issue was also encountered by libvirt, but they simply ignored it: + + https://bugzilla.redhat.com/show_bug.cgi?id=1878659 + +Hence, a question is: should we have the line below in acpi_pcihp_device_unplug_request_cb()? + + pdev->qdev.pending_deleted_event = true; + +It would be great if you as the author could give us a few hints. + +Thank you very much for your reply! + +Sincerely, + +Yu Zhang @ Compute Platform IONOS + + +The issue is reproducible in our own stack, which is not quite easy to describe in a few command lines. We simplified it a bit by a script instead. Although it's not able to reproduce, it could be somewhat helpful to understand the issue. + +``` +#!/bin/bash + +HOME=~ +QEMU=$HOME/qemu/bin/qemu-system-x86_64 +DISK1=$HOME/img/disk1.qcow2 +DISK4=$HOME/img/disk4.qcow2 +DISK5=$HOME/img/disk5.qcow2 + +$QEMU \ + -cpu host -enable-kvm -m 2048 -smp 2 \ + -object iothread,id=iothread1 \ + -drive file=$DISK1,if=none,id=drive-virtio-disk1,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,iothread=iothread1,num-queues=1,discard=on,id=virtio-disk1 \ + -object iothread,id=iothread4 \ + -drive file=$DISK4,if=none,id=drive-virtio-disk4,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk4,iothread=iothread4,num-queues=1,discard=on,id=virtio-disk4 \ + -object iothread,id=iothread5 \ + -drive file=$DISK5,if=none,id=drive-virtio-disk5,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk5,iothread=iothread5,num-queues=1,discard=on,id=virtio-disk5 \ + -qmp unix:./qmp-sock,server,nowait & + +sleep 5 + +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock``` +Additional information: +Possible workaround: https://lore.kernel.org/qemu-devel/20230403131833-mutt-send-email-mst@kernel.org/T/#t diff --git a/results/classifier/deepseek-2/output/device/1579306 b/results/classifier/deepseek-2/output/device/1579306 new file mode 100644 index 000000000..f362925f9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1579306 @@ -0,0 +1,15 @@ + +usb-uas does not work in Windows (10) guest + +When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest: + +"The device cannot start. (Code 10) + +{Operation Failed} +The requested operation was unsuccessful" + +If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well: + +"qemu-system-x86_64: usb_uas_handle_control: unhandled control request" + +If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1579645 b/results/classifier/deepseek-2/output/device/1579645 new file mode 100644 index 000000000..225cee382 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1579645 @@ -0,0 +1,13 @@ + + [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97" + +Environment: + +when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below: +"audio: Could no init “oss” audio driver.", +then login the guest and try run audio, no sound output. +Reproduce: +1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img] + xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure +2. it will show "audio: Could no init “oss” audio driver". +3. login in guest, it can detect audio device, but actually it is not working. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/158 b/results/classifier/deepseek-2/output/device/158 new file mode 100644 index 000000000..ea3549712 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/158 @@ -0,0 +1,2 @@ + +qemu system emulator crashed when using xhci usb controller diff --git a/results/classifier/deepseek-2/output/device/1580459 b/results/classifier/deepseek-2/output/device/1580459 new file mode 100644 index 000000000..b1b3dccfa --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1580459 @@ -0,0 +1,16 @@ + +Windows (10?) guest freezes entire host on shutdown if using PCI passthrough + +Problem: after leaving a Windows VM that uses PCI passthrough (as we do for gaming graphics cards, sound cards, and in my case, a USB card) running for some amount of time between 1 and 2 hours (it's not consistent with exactly how long), and for any amount of time longer than that, shutting down that guest will, right as it finishes shutting down, freeze the host computer, making it require a hard reboot. Unbinding (or in the other user's case, unbinding and THEN binding) any PCI device in sysfs, even one that has nothing to do with the VM, also has the same effect as shutting down the VM (if the VM has been running long enough). So, it's probably an issue related to unbinding and binding PCI devices. + +There's a lot of info on this problem over at https://bbs.archlinux.org/viewtopic.php?id=206050 +Here's a better-organized list of main details: +-at least 2 confirmed victims of this bug; 2 (including me) have provided lots of info in the link +-I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific) +-issue affects my Windows 10 guest and others' Windows guests, but not my Arch Linux guest (the others don't have non-Windows guests to test) +-I'm using libvirt but the other user is not, so it's not an issue with libvirt +-It seems to be version non-specific, too. I first noticed it at, or when testing versions still had the issue at (whichever version is lower), Linux 4.1 and qemu 2.4.0. It still persists in all releases of both since, including the newest ones. +-I can't track down exactly what package downgrade can fix it, as downgrading further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying changes such as downgrading ncurses, meaning I don't know whether it's a bug in QEMU, the Linux kernel, or some weird seemingly unrelated thing. +-According to the other user, "graphics intensive gameplay (GTA V) can cause the crash to happen sooner," as soon as "15 minutes" +-Also, "bringing up a second passthrough VM with separate hardware will cause the same crash," and "bringing up another VM before the two-hour mark will not result in a crash," further cementing that it's triggered by the un/binding of PCI devices. +-This is NOT related to the very similar bug that can be worked around by not passing through the HDMI device or sound card. Even when we removed all traces of any sort of sound card from the VM, it still had the same behavior. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1580586 b/results/classifier/deepseek-2/output/device/1580586 new file mode 100644 index 000000000..9ee90a15f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1580586 @@ -0,0 +1,10 @@ + +Qemu WinXP SP3 second loadvm freezes Guest OS + +Using Qemu-system-i386 to run WinXP SP3 with the following command line: + +qemu-system-i386 -hda qcow2/windowsxp_32bits_dd.qcow2 -m 1024 -net user,smb=/shared -vga std -net nic,model=rtl8139 -rtc base=localtime,clock=vm -s -snapshot + +savevm works fine, and the first loadvm to the snapshot works properly, but the next ones will all freeze the guest OS. + +First I thought it was due to the clock but adding the rtc options did not fix it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1581308 b/results/classifier/deepseek-2/output/device/1581308 new file mode 100644 index 000000000..7fd95c237 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1581308 @@ -0,0 +1,17 @@ + +ohci doesn't check the 'num-ports' property + +command: +qemu-system-x86_64 -m 1024 -enable-kvm /root/centos6.img -enable-kvm -device pci-ohci,num-ports=100,masterbus=1 + +The ohci doesn't check the 'num-ports' property and would case an out-of-bands write,crash the qemu process. + + ohci->num_ports = num_ports; + if (masterbus) { + USBPort *ports[OHCI_MAX_PORTS]; + for(i = 0; i < num_ports; i++) { + ports[i] = &ohci->rhport[i].port; + } + +The version of qemu is 2.6.0 release from +http://wiki.qemu-project.org/download/qemu-2.6.0.tar.bz2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1583 b/results/classifier/deepseek-2/output/device/1583 new file mode 100644 index 000000000..02675e09d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1583 @@ -0,0 +1,20 @@ + +SGX Device mapping is not listed into QEMU KVM +Description of problem: +I want to run SGX into QEMU VM, the vm is up and running but SGX device mappings are not listed there. I also looked in dmesg | grep sgx and it returned "There are zero epc section" + +I have upgraded the libvirt to 8.6.0 because of below issue +https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1982896 + +I tried with libvirt-8.0.0 but it did not help + +I have attached the xml, please let me know why sgx mappings are not showing inside VM +Steps to reproduce: +1. Create a Ubuntu 20.04 VM with SGX mapping +Additional information: +Please let me know if any other logs are required + + + + +[ubuntu20.04.xml](/uploads/2609abc31db08e04cc3e3dbf923cd8d7/ubuntu20.04.xml) diff --git a/results/classifier/deepseek-2/output/device/1583421 b/results/classifier/deepseek-2/output/device/1583421 new file mode 100644 index 000000000..152ea1689 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1583421 @@ -0,0 +1,8 @@ + +Please provide an option to print the default hardware configuration as command-line options, to make -nodefaults easier to use + +For full customization of the default set of hardware qemu supports, a user can pass -nodefaults and then manually specify each device they want. Many specific options document what they translate to in terms of the full configuration model; however, the defaults for any given platform don't. + +I'd love to have documentation of the default hardware configuration, in terms of qemu command-line options, to make it easy to run qemu -nodefaults, paste in the default command-line, and edit it. + +As this varies by emulated machine, perhaps qemu could have a command-line option to print a specific machine (e.g. pc-i440fx-2.5) in the form of qemu command-line options? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1585433 b/results/classifier/deepseek-2/output/device/1585433 new file mode 100644 index 000000000..9ec7006d3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1585433 @@ -0,0 +1,11 @@ + +if docker-volume-size of baymodel lessthan 3, bay cann't create + +magnum is running on centos7, + + +magnum baymodel-create --name k8sbaymodel5 --image-id fedora-23-atomic-20160405 --keypair-id testkey --external-network-id public --dns-nameserver 8.8.8.8 --flavor-id m1.small --coe kubernetes --docker-volume-size 5 + +magnum bay-create --name k8sbay5 --baymodel k8sbaymodel5 --node-count 1 + +Execute the above command can get a completed bay,but when docker-volume-size is 1 or 2,the status of bay is FAILED. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1585971 b/results/classifier/deepseek-2/output/device/1585971 new file mode 100644 index 000000000..c0857bb1e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1585971 @@ -0,0 +1,21 @@ + +Host system crashes on qemu with DMA remapping + +Hy, + +the host system crashes completely, when i try to pass an physical device without boot option intel_iommu=on set. In older kernel versions you didn't have to pass that option. + +I wonder if this can be easily checked by asking iommu state, avoiding a crash of the complete system. + +My data: +cpu model: Intel(R) Core(TM) i7 CPU +qemu version: 2.4.1-r2 +kernel version: 4.1.2 x86_64 +command line: +qemu-system-x86_64 -enable-kvm -drive file=/vms/prod/fw/fw.iso,if=virtio,format=raw -drive file=/vms/prod/fw/swap,if=virtio,format=raw -drive file=/vms/prod/fw/fwdata.iso,if=virtio,format=raw -m 512 -nographic -kernel /data/kernels/vmlinuz-2.6.36-gentoo-r8 -append "root=/dev/vda console=ttyS0 earlyprintk=serial" -net nic,model=virtio,macaddr=DE:AD:BE:EF:2D:AD -net tap,ifname=tapfw0,script=/etc/qemu/qemu-ifup -device pci-assign,host=03:00.0 + +There are also more detailed informations (if needed) here: +https://forums.gentoo.org/viewtopic-p-7923976.html + +Thanks, +Antonios. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1586611 b/results/classifier/deepseek-2/output/device/1586611 new file mode 100644 index 000000000..bad3d5bf9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1586611 @@ -0,0 +1,14 @@ + +usb-hub can not be detached when detach usb device from VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1586613 b/results/classifier/deepseek-2/output/device/1586613 new file mode 100644 index 000000000..395e2f0a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1586613 @@ -0,0 +1,14 @@ + +usb-hub can not be detached when detach usbdevice VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1587065 b/results/classifier/deepseek-2/output/device/1587065 new file mode 100644 index 000000000..18b6ac449 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1587065 @@ -0,0 +1,51 @@ + +btrfs qemu-ga - multiple mounts block fsfreeze + +Having two mounts of the same device makes fsfreeze through qemu-ga impossible. +root@CmsrvMTA:/# mount -l | grep /dev/vda2 +/dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@) +/dev/vda2 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home) + +Having two mounts is rather common with btrfs, so the feature fsfreeze is unusable on these systems. + + +Below more information about how we encountered this issue... + +Message send to <email address hidden>: + +Message 1: +---------- +I use external snapshots to backup my guests. I use the 'quiesce' option to flush and frees the guest file system with the qemu guest agent. + +With the exeption of one guest, this procedure works fine. On the 'unwilling' guest, I get this error message: +"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy" + +I don't think this is not some sort of time-out error, because activation of the fsfreeze and the error message happen immediately after each other: + +$ grep qemu-ga syslog.1 +May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called + +This is the only entry of the qemu guest agent in syslog. + +$ sudo virsh version +Compiled against library: libvirt 1.3.1 +Using library: libvirt 1.3.1 +Gebruikte API: QEMU 1.3.1 +Draaiende hypervisor: QEMU 2.5.0 + +$ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}' +{"return":{"version":"2.5.0", ... ,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true}, ... } + +For making an external snapshot, I use this command: +$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic --quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1 + +Piece of reply 1: +----------------- +I have encountered this before. Some operating systems + may have bind-mounts that let a device appear multiple times in the mount list. Unfortunately the guest agent is not smart enough to consider a device that has been frozen as succesfull and keep going. This causes this specific error. + +Piece of reply 2: +----------------- +Ok, that seems to be it. + +I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on two separate sub volumes. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1587970 b/results/classifier/deepseek-2/output/device/1587970 new file mode 100644 index 000000000..ff2dc2c71 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1587970 @@ -0,0 +1,6 @@ + +QEMU Crashes when attaching USB 3.00 devices to xhci bus + +Using qemu 2.6 with a windows7 32-bit VM, if I plug a USB 3.0 memory stick in to a USB 3.0 port, then pass it through to the VM via the monitor (device_add usb-host,bus=xhci.0,hostbus=xx,hostaddr=xx,id=stick1) then qemu asserts and dies - I have seen 2 different asserts one is from the xchi module - Assertion `intr->er_full, and one is in core.c (line 400 I IIRCC) with "Assertion dev->state == 3 failed" +Tried to work around by only passing in an ehci controller to the VM, but then if I attach a usb 3.0 memory stick to that it doesn't work in windows. +I have made sure the xhci drivers in the windows VM are up to date, latest version of SeaBios etc, but at the moment, I have had to disable xhci in my system bios and just use ehci for everything. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1592336 b/results/classifier/deepseek-2/output/device/1592336 new file mode 100644 index 000000000..3620f7456 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1592336 @@ -0,0 +1,28 @@ + +mouse is defunct when grabbed + +I run qemu as follows: +qemu-system-x86_64 -machine accel=kvm -k en-us -smp 4 -m 2371 -usb \ + -device virtio-rng-pci \ + -drive file=/home/new/suse-fact.img,format=raw,discard=unmap,if=none,id=hd + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -soundhw hda \ + -net user,tftp=/home/xslaby/tftp,bootfile=/pxelinux.0,hostfwd=tcp::2222-:22,hostfwd=tcp::3632-:3632 -net nic,model=virtio \ + -serial pty -balloon virtio -vga virtio -display gtk,gl=on + +When I run X server with icewm inside the machine, the cursor works until I grab the mous with ctrl-alt-g. Then the cursor dismissed and the mouse is defunct. + +I also tried -usbdevice mouse and -usbdevice tablet with the same result. + +I have these versions of qemu packages: +qemu-2.6.0-470.2.x86_64 +qemu-ipxe-1.0.0-470.2.noarch +qemu-ksm-2.6.0-470.2.x86_64 +qemu-kvm-2.6.0-470.2.x86_64 +qemu-ovmf-x86_64-2015+git1462940744.321151f-2.1.noarch +qemu-ppc-2.6.0-470.2.x86_64 +qemu-seabios-1.9.1-470.2.noarch +qemu-sgabios-8-470.2.noarch +qemu-tools-2.6.0-470.2.x86_64 +qemu-vgabios-1.9.1-470.2.noarch +qemu-x86-2.6.0-470.2.x86_64 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1596832 b/results/classifier/deepseek-2/output/device/1596832 new file mode 100644 index 000000000..e2d4858f4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1596832 @@ -0,0 +1,56 @@ + +e500 -bios/-kernel broken with big images + +This is tested using qemu 2.4.1, but it looks like the code qemu/hw/ppc/e500.c has not changed since. This looks like the source of the problem: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3812c71ffaa2cf733c3087792b859fef30b7545f + + +What works: +---------- + +Basic invocation qemu-system-ppc -machine ppce500 -monitor stdio -bios u-boot.e500 works, I get the uboot prompt and this: + +(qemu) info roms +addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500" +addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500" + + +Passing u-boot.e500 image as kernel (-bios u-boot.e500 -kernel u-boot.e500) appears to work, $qemu_kernel_addr is filled in, though (as expected) uboot complains about the image format. + +(qemu) info roms +addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500" +addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500" +addr=0000000002000000 size=0x054e8c mem=ram name=".../qemu/share/qemu/u-boot.e500 + + + +What doesn't work: +----------------- + +However, once I try to load a big image (>=32 MiB), uboot doesn't even show anything: + +qemu-system-ppc -machine ppce500 -monitor stdio -bios u-boot.e500 -kernel boot/vmlinux -m 1024 + +(qemu) info roms +addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500" +addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500" +addr=0000000002000000 size=0x27aeedc mem=ram name="boot/vmlinux" + +... +(gdb) bt +#0 0x00f2efcc in ?? () +#1 0x00f31554 in ?? () +#2 0x00f03f4c in ?? () +#3 0x00f04458 in ?? () +#4 0x00f028dc in ?? () +#5 0x00f01080 in ?? () + + + +The thing is, this used to work +- before the commit, where I'd just pass the image as -kernel option, and it booted. + + +If I do that now (w/o the -bios option, using the exact same image), the kernel gets loaded twice, only at different addresses (the cause is obvious from the commit), causing overlap error: + +qemu-system-ppc -machine ppce500 -monitor stdio -kernel boot/vmlinux -m 1024 +QEMU 2.4.1 monitor - type 'help' for more information +(qemu) rom: requested regions overlap (rom boot/vmlinux. free=0x00000000027492fc, addr=0x0000000002000000) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1597 b/results/classifier/deepseek-2/output/device/1597 new file mode 100644 index 000000000..937f22489 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1597 @@ -0,0 +1,57 @@ + +Intel Arc A-Series GPUs VFIO passthrough no video out +Description of problem: +Once the VM is booted, the screen goes blank. +Steps to reproduce: +1. Passthough any Intel Arc A (Alchemist) series video card. +2. Boot VM. +3. Screen goes blank. +Additional information: +I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I start the VM that issue presents itself. + + + +kernel command line: + +``` +amd_iommu=on iommu=pt rd.driver.pre=vfio-pci pci=realloc iommu=1 i915.force_probe=* + +``` + +startup script: + +``` +#!/bin/bash +# Helpful to read output when debugging +set -x + +# Load the config file with our environmental variables +source "/etc/libvirt/hooks/kvm.conf" +source "/etc/libvirt/hooks/vmPreBootSetup" + +cpuPerf + +# Stop your display manager. If you're on kde it'll be sddm.service. Gnome users should use 'killall gdm-x-session' instead +systemctl stop gdm.service + +# Unbind VTconsoles +echo 0 > /sys/class/vtconsole/vtcon0/bind +echo 0 > /sys/class/vtconsole/vtcon1/bind + +# Avoid a race condition by waiting a couple of seconds. This can be calibrated to be shorter or longer if required for your system +sleep 2 + +modprobe -r drm_buddy intel_gtt video drm_display_helper cec ttm i915 + +# Unbind the GPU from display driver +virsh nodedev-detach $VIRSH_GPU_VIDEO +virsh nodedev-detach $VIRSH_GPU_AUDIO + +# Load VFIO kernel module +modprobe vfio +modprobe vfio_pci +modprobe vfio_iommu_type1 + +sleep 5s ; systemctl restart connman.service + +``` diff --git a/results/classifier/deepseek-2/output/device/1598 b/results/classifier/deepseek-2/output/device/1598 new file mode 100644 index 000000000..8a7e6734b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1598 @@ -0,0 +1,59 @@ + +vfio-pci - Intel Arc DG2 - host errors +Description of problem: +The host continues to respond (slowly) after the VM is shutdown. Speeds back up to normal after about an hour. However, a reboot is required to get the host to operate normally. + +When shutting down the VM, the host starts to display the following messages in dmesg: + +[Thu Apr 13 01:30:47 2023] vfio-pci 0000:18:00.0: not ready 1023ms after FLR; waiting +[Thu Apr 13 01:30:49 2023] vfio-pci 0000:18:00.0: not ready 2047ms after FLR; waiting +[Thu Apr 13 01:30:52 2023] vfio-pci 0000:18:00.0: not ready 4095ms after FLR; waiting +[Thu Apr 13 01:30:57 2023] vfio-pci 0000:18:00.0: not ready 8191ms after FLR; waiting +[Thu Apr 13 01:31:06 2023] vfio-pci 0000:18:00.0: not ready 16383ms after FLR; waiting +[Thu Apr 13 01:31:25 2023] vfio-pci 0000:18:00.0: not ready 32767ms after FLR; waiting +[Thu Apr 13 01:31:59 2023] vfio-pci 0000:18:00.0: not ready 65535ms after FLR; giving up +[Thu Apr 13 01:32:11 2023] vfio-pci 0000:18:00.0: not ready 1023ms after bus reset; waiting +[Thu Apr 13 01:32:13 2023] vfio-pci 0000:18:00.0: not ready 2047ms after bus reset; waiting +[Thu Apr 13 01:32:16 2023] vfio-pci 0000:18:00.0: not ready 4095ms after bus reset; waiting +[Thu Apr 13 01:32:21 2023] vfio-pci 0000:18:00.0: not ready 8191ms after bus reset; waiting +[Thu Apr 13 01:32:31 2023] vfio-pci 0000:18:00.0: not ready 16383ms after bus reset; waiting +[Thu Apr 13 01:32:48 2023] vfio-pci 0000:18:00.0: not ready 32767ms after bus reset; waiting +[Thu Apr 13 01:33:22 2023] vfio-pci 0000:18:00.0: not ready 65535ms after bus reset; giving up +Steps to reproduce: +1. Shutdown VM. +Additional information: +I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I shutdown the VM that issue presents itself. + +revert.sh + +``` +#!/bin/bash +set -x + +systemctl reboot # to workaround host lockup on shutdown + +# Load the config file with our environmental variables +source "/etc/libvirt/hooks/kvm.conf" +source "/etc/libvirt/hooks/vmPreBootSetup" + +cpuSchedutil + +# Unload VFIO-PCI Kernel Driver +modprobe -r vfio_pci +modprobe -r vfio_iommu_type1 +modprobe -r vfio + +# Re-Bind GPU to our display drivers +virsh nodedev-reattach $VIRSH_GPU_VIDEO +virsh nodedev-reattach $VIRSH_GPU_AUDIO + +#modprobe drm_buddy intel_gtt video drm_display_helper cec ttm i915 + +# Restart Display Manager +systemctl restart sddm.service +``` + + + +Full dmesg log: +[vfio_13_april_2023.txt](/uploads/5d5b642595c53cabb3c3608c07d59eb3/vfio_13_april_2023.txt) diff --git a/results/classifier/deepseek-2/output/device/1600563 b/results/classifier/deepseek-2/output/device/1600563 new file mode 100644 index 000000000..3eda2d382 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1600563 @@ -0,0 +1,17 @@ + +min_io_size is currently limited to size uint16_t + +I am using LVM VGs on MD-raid1 for hosting my KVM volumes. On the host, a VG looks like this: + +Disk /dev/vm/vol202a: 60 GiB, 64424509440 bytes, 125829120 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 131072 bytes / 131072 bytes + +In order to replicate the block device characteristics in the guest, I am using the following extra parameters: + +-set device.scsi0-0-0-0.logical_block_size=512 +-set device.scsi0-0-0-0.physical_block_size=4096 +-set device.scsi0-0-0-0.min_io_size=131072 + +This doesn't work as qemu complains that min_io_size needs to be of type uint16_t. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1603693 b/results/classifier/deepseek-2/output/device/1603693 new file mode 100644 index 000000000..de99632ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1603693 @@ -0,0 +1,78 @@ + +Disks in mptsas1068 scsi controller not seen by linux + +When using the mptsas1068 scsi controller, linux detects the controller itself but not the drives attached to it. Freebsd works. Using a different controller with linux works. VMware with linux works. + +qemu 2.6.50 (v2.6.0-1925-g6b92bbf) +seabios rel-1.9.0-139-gae3f78f (master branch, required for mptsas1068 support) + +Test script, loosely based off what libvirt runs and the libvirt tests that Paolo Bonzini wrote [1] + +##################### +iso=archlinux-2016.07.01-dual.iso +#iso=FreeBSD-10.3-RELEASE-amd64-bootonly.iso +device=mptsas1068 +#device=lsi + +img=empty.img +qemu-img create -f qcow2 $img 1G + +/usr/bin/qemu-system-x86_64 \ +-enable-kvm \ +-m 1024 \ +-boot menu=on \ +-device $device,id=scsi0,bus=pci.0,addr=0x9 \ +-drive file=$img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 \ +-drive file=$iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 +##################### + +The ISOs can be downloaded from [2] and [3]. + +After booting linux, do "lsblk". /dev/sda should exist. + +After booting freebsd, do "geom disk list". A da0 / "QEMU QEMU HARDDISK" should be mentioned. + +With device=mptsas1068 this fails in linux. + +With device=lsi line it works in both. + +With VMWare and a linux VM (opensuse 10.1, kernel 2.6.18) which only loads modules for mptsas1068, this works. + +I also reproduced this with the debian 8.5 netinstall image, but it insists in making you pick a driver from a list of modules when it fails to mount it, instead of dropping to a shell. + +Arch linux dmesg output snippet (full output attached as arch-linux-dmesg.txt): + +##################### +root@archiso ~ # dmesg | grep -i -e mpt -e scsi -e ioc0 +[ 0.000000] Linux version 4.6.3-1-ARCH (builduser@tobias) (gcc version 6.1.1 20160602 (GCC) ) #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 +[ 0.000000] Normal empty +[ 0.000000] Preemptible hierarchical RCU implementation. +[ 1.879616] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 1.951581] SCSI subsystem initialized +[ 1.957113] Fusion MPT base driver 3.04.20 +[ 1.957618] Fusion MPT SAS Host driver 3.04.20 +[ 2.281773] scsi host0: ata_piix +[ 2.285372] scsi host1: ata_piix +[ 2.305803] mptbase: ioc0: Initiating bringup +[ 2.363555] ioc0: LSISAS1068 A0: Capabilities={Initiator} +[ 2.444390] scsi 0:0:1:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +[ 2.500572] scsi host2: ioc0: LSISAS1068 A0, FwRev=01329200h, Ports=8, MaxQ=128, IRQ=11 +[ 2.507024] sr 0:0:1:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[ 2.507274] sr 0:0:1:0: Attached scsi CD-ROM sr0 +##################### + +The controller itself is detected, the disk isn't. + +An early version of this patch [4] said that it was only tested with FreeBSD: + +>Tested with FreeBSD for now. The previous version (before the +>configuration page rewrite) worked with RHEL and Windows guests as well. +> +>TODO: write qtest for (at least) config pages, test Linux and Windows. + +[1]: https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=fc922eb2080a3fa7b24bc8a8b0aabfd394480143 +[2]: https://www.archlinux.org/download +[3]: https://www.freebsd.org/where.html +[4]: https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06475.html \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1603779 b/results/classifier/deepseek-2/output/device/1603779 new file mode 100644 index 000000000..cc91da43a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1603779 @@ -0,0 +1,19 @@ + +AC97 can allocate ~500MB of host RAM + +While working with qtest test cases generated via fuzzing with QEMU 2.5.0, I discovered some odd behavior for the AC97 virtual device with qemu-system-i386. If AC97_MIC_ADC_RATE is set to the value of 1, the QEMU process allocates over 500MB of additional host RAM. You probably would not normally notice this on a modern PC, except that I was using a "ulimit" command to restrict the maximum amount of virtual memory allowed for the QEMU process, so the process would crash with a SIGTRAP (signal 5) on the failed memory allocation. + +My minimized qtest code to reproduce the issue is: + +static void test_crash(void) +{ + uint64_t barsize; + dev = get_device(); + + dev_base[0] = qpci_iomap(dev, 0, &barsize); + dev_base[1] = qpci_iomap(dev, 1, &barsize); + qpci_device_enable(dev); + qpci_io_writew(dev, dev_base[0]+0x32, 0x00000001); +} + +I ran a "ulimit -sv 650000" command and then launched the tests/ac97-test binary with this crash test case included in it. I can then see the QEMU process crash on an allocation of 722538464 bytes. I can gradually increase the ulimit memory limit to ~1200000 and then no longer see the issue, hence my estimate of 500 MB of RAM allocated by the device. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1608802 b/results/classifier/deepseek-2/output/device/1608802 new file mode 100644 index 000000000..3fbfeace2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1608802 @@ -0,0 +1,50 @@ + +READ_DMA (0xC8) command does not work correctly + +The QEMU PC emulation of DMA does not behave like real hardware or other virtualization software. + +From the original bug report (Benjamin David Lunt): + + Back to the READ_DMA command, it is my conclusion that the + READ_DMA command, more precisely, the BUS Master part of QEMU is + in error. The tests that people have done to see if it works, is + probably the guest finding out that DMA doesn't work and defaulting + to PIO, but since the read was successful visually to the user, the + user assumed the READ_DMA command works, where the guest actually + defaulted back to PIO transfers without notice. + + My code works on real hardware (numerous machines), Bochs, and Oracle's + Virtual Box. + + ... + + I have a small test suite, zipped and included at: + www.fysnet.net/temp/c8bug.zip + + Within this zip file is a.img. This is a freeDOS bootable + floppy. Emulate it with QEMU and then at the DOS prompt, run + c8bug.exe. + + It will say that the drive is not ready. + "Drive never became ready" + (along with a few other lines of text) + + The source for this test suite is also included. + c8bug.c is the c source code + c8bug.h is the header file + ctype.h is a quick way to get 'bit8u' type defines + timer.h is a delay routine from another project I have + (The base IO addresses are assumed and set at the top of c8bug.c) + (compiled with DJGPP for DPMI) + + q.bat is my command line for QEMU + + On all other machines and VirtualBox, the controller is ready + for me to receive the sector data. + "Drive is ready to transmit data..." + + However, in QEMU, the controller never becomes ready. + "Drive never became ready" + +The bug was reported for QEMU for Windows, but I can confirm that QEMU for Linux also shows that +behaviour, while VirtualBox works. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1614 b/results/classifier/deepseek-2/output/device/1614 new file mode 100644 index 000000000..1d1d04f1e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1614 @@ -0,0 +1,2 @@ + +Add option to chardev pty for setting a named link to the allocated pty diff --git a/results/classifier/deepseek-2/output/device/1618 b/results/classifier/deepseek-2/output/device/1618 new file mode 100644 index 000000000..71749a939 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1618 @@ -0,0 +1,14 @@ + +intel-hda: SD_STS different behavior for byte write vs. word write +Description of problem: +The Intel HDA SD_STS register is accessible two different ways in QEMU: either it's the top 8 bits of a 32-bit access +or it's directly accessible as a byte. +On reads, the register behavior for SD_STS is identical whether accessed as a 32-bit read or an 8-bit read. +On writes, the behavior is different; when written to as an 8-bit write, the BCIS, FIFOE, and DESE bits implement the documented HDA behavior of RW1C (writing a 1 to a bit clears it). When written to as the top 8 bits of a 32-bit write, writing a 1 to a bit sets the bit -- so an attempt to clear a status bit instead unconditionally sets the status bit. +Steps to reproduce: +1. Write 32 bits at SD_CTL address with bit 27 set (FIFOE). This should clear FIFOE, but does not. +2. Read back SD_STS (SD_CTL address + 3) as a byte. The FIFOE bit will be set. +3. Write 8 bits at SD_STS address with bit 3 set (FIFOE). This should clear FIFOE, and it does. +4. Read back SD_STS as a byte. The FIFOE bit will be cleared. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1618265 b/results/classifier/deepseek-2/output/device/1618265 new file mode 100644 index 000000000..30c203892 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1618265 @@ -0,0 +1,4 @@ + +Loading virtio-input-host-pci drivers before boot? To allow using passthrough devices in grub and other preboot menus? + +Currently virtio-input devices cannot be used before the kernel loads. This is not really a full bug but it would be much more useful if you can use the keyboard+mouse this way. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1618431 b/results/classifier/deepseek-2/output/device/1618431 new file mode 100644 index 000000000..52065e0aa --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1618431 @@ -0,0 +1,66 @@ + +windows hangs after live migration with virtio + +Several of our users reported problems with windows machines hanging +after live migrations. The common denominator _seems_ to be virtio +devices. +I've managed to reproduce this reliably on a windows 10 (+ +virtio-win-0.1.118) guest, always within 1 to 5 migrations, with a +virtio-scsi hard drive and a virtio-net network device. (When I +replace the virtio-net device with an e1000 it takes 10 or more +migrations, and without virtio devices I have not (yet) been able to +reproduce this problem. I also could not reproduce this with a linux +guest. Also spice seems to improve the situation, but doesn't solve +it completely). + +I've tested quite a few tags from qemu-git (v2.2.0 through v2.6.1, +and 2.6.1 with the patches mentioned on qemu-stable by Peter Lieven) +and the behavior is the same everywhere. + +The reproducibility seems to be somewhat dependent on the host +hardware, which makes investigating this issue that much harder. + +Symptoms: +After the migration the windows graphics stack just hangs. +Background processes are still running (eg. after installing an ssh +server I could still login and get a command prompt after the hang was +triggered... not that I'd know what to do with that on a windows +machine...) - commands which need no GUI access work, the rest just +hangs there on the command line, too. +It's also capable of responding to an NMI sent via the qemu monitor: +it then seems to "recover" and manages to show the blue sad-face +screen that something happened, reboots successfully and is usable +again without restarting the qemu process in between. +From there whole the process can be repeated. + +Here's what our command line usually looks like: + +/usr/bin/qemu -daemonize \ + -enable-kvm \ + -chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait -mon chardev=qmp,mode=control \ + -pidfile /var/run/qemu-server/101.pid \ + -smbios type=1,uuid=07fc916e-24c2-4eef-9827-4ab4026501d4 \ + -name win10 \ + -smp 6,sockets=1,cores=6,maxcpus=6 \ + -nodefaults \ + -boot menu=on,strict=on,reboot-timeout=1000 \ + -vga std \ + -vnc unix:/var/run/qemu-server/101.vnc \ + -no-hpet \ + -cpu kvm64,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce \ + -m 2048 \ + -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f \ + -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e \ + -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 \ + -device usb-tablet,id=tablet,bus=uhci.0,port=1 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ + -iscsi initiator-name=iqn.1993-08.org.debian:01:1ba48d46fb8 \ + -drive if=none,id=drive-ide0,media=cdrom,aio=threads \ + -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=200 \ + -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 \ + -drive file=/mnt/pve/data1/images/101/vm-101-disk-1.qcow2,if=none,id=drive-scsi0,cache=writeback,discard=on,format=qcow2,aio=threads,detect-zeroes=unmap \ + -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100 \ + -netdev type=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on \ + -device virtio-net-pci,mac=F2:2B:20:37:E6:D7,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 \ + -rtc driftfix=slew,base=localtime \ + -global kvm-pit.lost_tick_policy=discard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1622582 b/results/classifier/deepseek-2/output/device/1622582 new file mode 100644 index 000000000..c5665da10 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1622582 @@ -0,0 +1,37 @@ + +Can't install Windows 7 with q35 (SATA) + +I'm trying to install Windows 7 on a q35 machine on a "SATA disk". If I use q35 the installation is extremely slow. With extremely slow I mean, that the first few minutes (10-15 minutes) on the second installation step (copying files to disk) nothing happens. Than there is some progress, maybe until 9% and than there is "silence" for another 10 minutes or so. Therefore I used iotop (with --only option) in order to see, if there are any disk operations. But as I mentioned, only a few times qemu writes something to disk (with about < 1M/s). But most of the time there is nothing from qemu. Therefore the installation lasts over an hour. But even worse, after installation I can't boot Windows. Windows-Start-Manager tells me, that windows couldn't be loaded because the kernel is missing or corrupt (Status 0xc0000221, File: \Windows\system32\ntoskrnl.exe). If I use IDE on q35 or pc-i440fx-2.6 everything works fine. There is a continuous installation progress and iotop shows continuous disk writes with max 30M/s (but also 5M/s and other values...). + +I've tried qemu 2.6.0, 2.6.1 and 2.7.0 (all versions from git). + +My host machine: +Ubuntu 14.04.5 LTS +3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux +Intel(R) Core(TM) i5-3470 CPU +16 GB RAM + + +I used the following commands: + +"Standard" command +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -hda win7_qemu_standard_q35.qcow2 -cdrom win7proX64.iso -boot order=d + +I think by using -hda sata will be used?!? + +With explicit ahci: +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -drive file=win7_qemu_standard_q35.qcow2,media=disk,if=none,id=sata-disk -device ich9-ahci,id=ahci -device ide-drive,drive=sata-disk,bus=ahci.0 -drive file=win7proX64.iso,media=cdrom,if=none,id=sata-cdrom -device ide-cd,drive=sata-cdrom,bus=ahci.1 -boot order=d + +I don't know if this is totally correct, because it's a little bit weird that I have to use ide-drive on a ich9 bus. + +Without kvm there is a continious disk write with 100 K/s - 5 M/s (works only with qemu 2.7.0, otherwise I get a 0x000000D1 bluescreen on the setup start screen): +qemu-system-x86_64 -m 2048 -machine q35 -cpu IvyBridge -hda win7_qemu_standard_q35.qcow2 -cdrom win7proX64.iso -boot order=d + +But with all three commands the installed Windows is not working, because always the same error occurs: windows couldn't be loaded because kernel is missing or corrupt + +Interestingly both commands ("standard" command and with explicit ahci) works very well with a Windows 10 installation. + +In my opinion it's a "SATA problem", because if I use e.g. piix4-ide instead of ich9-ahci it works: +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -drive file=win7_qemu_standard_q35.qcow2,media=disk,if=none,id=ide-disk -device piix4-ide,id=ide -device ide-drive,drive=ide-disk,bus=ide.0 -drive file=win7proX64.iso,media=cdrom,if=none,id=ide-cdrom -device ide-cd,drive=ide-cdrom,bus=ide.1 -boot order=d + +With this command there is a continuous disk write and the installation is bootable. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1623998 b/results/classifier/deepseek-2/output/device/1623998 new file mode 100644 index 000000000..b6f578a2b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1623998 @@ -0,0 +1,13 @@ + +pulseaudio Invalid argument error + +When using qemu-system-ppc on Ubuntu Mate 15 with the usb audio card, I see these error messages: + +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument + +No audio plays. When an attempt is made, QEMU seems to freeze for a moment. + +I use "-device usb-audio" to add the usb sound card. This issue is present in both emulation and KVM mode. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1624726 b/results/classifier/deepseek-2/output/device/1624726 new file mode 100644 index 000000000..02a46c7a8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1624726 @@ -0,0 +1,30 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1625 b/results/classifier/deepseek-2/output/device/1625 new file mode 100644 index 000000000..ce5a8cefc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1625 @@ -0,0 +1,14 @@ + +[7.2.0] Qemu process hang with `defunct` when using `-blockdev` json property which file doesn't exists +Description of problem: +When using `throttle` and `throttle-group` to apply block device QOS, +there is something wrong with check file exists validation. +In upper commands, if the file which located `/mnt/b3b8dfb5-0a7c-4285-81d8-2bf8d33a3297/32c55f5a-96d1-4af4-a149-c95fd6652e3e/b016af76-f6b1-4614-b29a-78917924e55e` doesn't exist, it just hang with `defunct` process. + +Steps to reproduce: +1. Start Guest with upper command. +2. Hanged with defunct process +3. +Additional information: + +- With GDB stack, i can find `no such file` error, but process don't exit diff --git a/results/classifier/deepseek-2/output/device/1625216 b/results/classifier/deepseek-2/output/device/1625216 new file mode 100644 index 000000000..5bf49f9b2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1625216 @@ -0,0 +1,72 @@ + +memory writes via gdb don't work for memory mapped hardware + +When I remote-debug a qemu-guest and attempt to write to a memory mapped location, the +write-handler for the concerned device will not be called. All write-requiests from +gdb are delegated to cpu_physical_memory_write_rom(...). a function that writes to the +underlying ram-block. + +I believe requests to memory mapped hardware should be delegated to +address_space_rw(). + +example: +;; a memory mapped device. No effect, the write-handler is not called +(gdb) set *0xfff3c000 = 48 + +;; a ram or rom-block. Thos works. The value is changed. +(gdb) set *0x100000 = 48 + + +---------------------------------------- + +Here's my suggested patch. As noted in the comment, it could perhaps be +improved for the (rare) case when the write-request from gdb spans multiple +memory regions. + +$ git diff 85bc2a15121e8bcd9f15eb75794a1eacca9d84bd HEAD ../exec.c +diff --git a/exec.c b/exec.c +index c4f9036..45ef896 100644 +--- a/exec.c ++++ b/exec.c +@@ -3676,6 +3676,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + int l; + hwaddr phys_addr; + target_ulong page; ++ bool is_memcpy_access; + + while (len > 0) { + int asidx; +@@ -3691,13 +3692,32 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (l > len) + l = len; + phys_addr += (addr & ~TARGET_PAGE_MASK); ++ + if (is_write) { ++ /* if ram/rom region we access the memory ++ via memcpy instead of via the cpu */ ++ hwaddr mr_len, addr1; ++ AddressSpace *as = cpu->cpu_ases[asidx].as; ++ MemoryRegion *mr = address_space_translate(as, phys_addr, &addr1, &mr_len, is_write); ++ is_memcpy_access = memory_region_is_ram(mr) || memory_region_is_romd(mr); ++ if(mr_len < len) { ++ /* TODO, mimic more of the loop over mr chunks as ++ done in cpu_physical_memory_write_internal */ ++ printf("warning: we dont know whether all bytes " ++ "to be written are ram/rom or io\n"); ++ } ++ } ++ else { ++ is_memcpy_access = false; ++ } ++ ++ if (is_write && is_memcpy_access) { + cpu_physical_memory_write_rom(cpu->cpu_ases[asidx].as, + phys_addr, buf, l); + } else { + address_space_rw(cpu->cpu_ases[asidx].as, phys_addr, + MEMTXATTRS_UNSPECIFIED, +- buf, l, 0); ++ buf, l, is_write); + } + len -= l; + buf += l; \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1626207 b/results/classifier/deepseek-2/output/device/1626207 new file mode 100644 index 000000000..567050e5f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1626207 @@ -0,0 +1,46 @@ + +-device usb-host failing with usbip_vudc-vhdi_hcd gadget + +I must admit that I do not know if this is a Qemu or a Kernel issue, but I try reporting here: + +When I try to forward a copy of my USB mouse that I made with the new virtual USB device controller in kernel 4.7 I get the following in my log: +[ +0.703256] usb 1-4: reset full-speed USB device number 3 using xhci_hcd +[ +1.020776] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855013] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.859052] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.857000] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.000141] usb 7-3: USB disconnect, device number 10 +[ +0.153056] usb 1-4: reset full-speed USB device number 3 using xhci_hcd +[ +0.703746] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855001] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855006] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855005] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.000009] usb usb7-port3: unable to enumerate USB device + +the commands I use for makeing the virtual device are(after making a copy of the report description of my real mouse in /root/usb/kingston_report_desc): + mkdir /sys/kernel/config/usb_gadget/winmouse + cd /sys/kernel/config/usb_gadget/winmouse + echo "0x047d" > idVendor + echo "0x1020" > idProduct + mkdir strings/0x409 + echo 2016 > strings/0x409/serialnumber + echo Kensington > strings/0x409/manufacturer + echo "Kensington Expert Mouse" > strings/0x409/product + mkdir configs/c.1 + mkdir configs/c.1/strings/0x409 + mkdir functions/hid.usb2 + echo 2 > functions/hid.usb2/protocol + echo 1 > functions/hid.usb2/subclass + echo 4 > functions/hid.usb2/report_length + cat /root/usb/kingston_report_desc > functions/hid.usb2/report_desc + echo 0xa0 > configs/c.1/bmAttributes + echo 100 > configs/c.1/MaxPower + + ln -s functions/hid.usb2 configs/c.1 + echo usbip-vudc.2 > UDC + + usbip attach -r localhost -d usbip-vudc.2 + +The virtual mouse then shows up as Bus7,Dev10 and I use the option -device usb-host,hostbus=7,hostaddr=10,id=hostdev6,bus=usb.0,port=2 in Qemu to attach it. + +This is Qemu 2.7.0 on kernel 4.7.4 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1630723 b/results/classifier/deepseek-2/output/device/1630723 new file mode 100644 index 000000000..5bcb0bc70 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1630723 @@ -0,0 +1,7 @@ + +UART writes to netduino2/stm32f205-soc disappear + +Writes to UART 2 and 3 disappear. As a sanity check I put printf statements in the function stm32f2xx_usart_write in qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed text sent to UART1 and UART4 are sent to that function while text sent to UART 2 and 3 are not. I assume writes to all 4 need to make it to that function for emulations to operate correctly. + +Example code that writes to all 4 UARTs/USARTs (does not contain the printf statements mention above): +https://github.com/skintigh/baremetal_netduino2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1634069 b/results/classifier/deepseek-2/output/device/1634069 new file mode 100644 index 000000000..a690ea2c6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1634069 @@ -0,0 +1,6 @@ + +Exclude keys from grab + +Feature request: pressing every time a shortcut to release grab for switching windows/desktops is pretty annoying, especially for users of tiling WMs. + +QEMU have to have a way to specify keys or shortcuts (possibly something like "everything with the specified modifier key"), which would not be intercepted. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1637693 b/results/classifier/deepseek-2/output/device/1637693 new file mode 100644 index 000000000..d26c09156 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1637693 @@ -0,0 +1,8 @@ + +QEMU not able to create vm with pflash and UEFI bios + +Running Fedora 24 with the virt-preview repo on QEMU Version 2.7.0 and libvirt version 2.2.0. Tried to install a windows 10 vm with the OVMF bios and this error happens every time, it didnt happen when using the stable version of qemu for fedora 24. + +libvirtError: internal error: qemu unexpectedly closed the monitor: 2016-10-29T04:07:29.678518Z qemu-system-x86_64: -drive file=/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on: oversized backing file, pflash segments cannot be mapped under 00000000ff800000 + +Any ideas? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1637974 b/results/classifier/deepseek-2/output/device/1637974 new file mode 100644 index 000000000..f13403fb6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1637974 @@ -0,0 +1,49 @@ + +dead code in pl080 functions + +pl080 is arm dma controller virtual device. +source code path: hw/dma/pl080.c +I find there are two same dead code in pl080_read and pl080_write, +Here's the code, comments are my opinion: +========================= +240 static uint64_t pl080_read(void *opaque, hwaddr offset, +241 unsigned size) +242 { +243 PL080State *s = (PL080State *)opaque; +244 uint32_t i; +245 uint32_t mask; +246 +247 if (offset >= 0xfe0 && offset < 0x1000) { +248 if (s->nchannels == 8) { +249 return pl080_id[(offset - 0xfe0) >> 2]; +250 } else { +251 return pl081_id[(offset - 0xfe0) >> 2]; +252 } +253 } +254 if (offset >= 0x100 && offset < 0x200) { //// here offset is limited in 0x100~0x200 +255 i = (offset & 0xe0) >> 5; +256 if (i >= s->nchannels) +257 goto bad_offset; +258 switch (offset >> 2) { //// then here, offset>>2 is in range 64~128 +259 case 0: /* SrcAddr */ //// while the switch case is 0,1,2,3,4, +260 return s->chan[i].src; //// so, NONE of the switch case would be selected ! +261 case 1: /* DestAddr */ //// this switch is A DEAD CODE, it is contradictory with if. +262 return s->chan[i].dest; +263 case 2: /* LLI */ +264 return s->chan[i].lli; +265 case 3: /* Control */ +266 return s->chan[i].ctrl; +267 case 4: /* Configuration */ +268 return s->chan[i].conf; +269 default: +270 goto bad_offset; +271 } +272 } + ..................................... +============================================= + +I guess, switch statement should like this : +switch((offset-0x100)>>2) +{ +... +} \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1639 b/results/classifier/deepseek-2/output/device/1639 new file mode 100644 index 000000000..818f97ad9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1639 @@ -0,0 +1,2 @@ + +No supported machine for loongson-3A4000 mips64el diff --git a/results/classifier/deepseek-2/output/device/1639322 b/results/classifier/deepseek-2/output/device/1639322 new file mode 100644 index 000000000..e993a75e1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1639322 @@ -0,0 +1,12 @@ + +pasting into ppc64 serial console kills qemu + +- run qemu-system-ppc64 +- when X window appears press Ctrl+Alt+3 +- paste any text longer than 16 characters + + +qemu-system-ppc64: /home/abuild/rpmbuild/BUILD/qemu-2.6.1/hw/char/spapr_vty.c:40: vty_receive: Assertion `(dev->in - dev->out) < 16' failed. +Aborted (core dumped) + +Broken in SUSE Leap 42.2 and git 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1639791 b/results/classifier/deepseek-2/output/device/1639791 new file mode 100644 index 000000000..25bb8b59b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1639791 @@ -0,0 +1,24 @@ + +early virtio console output is lost + +This is broken in git and reportedly in 2.5 through 2.7. + +Running a Linux kernel which includes a testsuite in initrd sometimes produces no output. + +Reportedly the console is sometimes not open when the early userspace tries to log output resulting in either the testsuite terminating early or not writing the output. + +Workaround patch is here: + +https://git.zx2c4.com/WireGuard/commit/?id=d2de8b0862a7fbb51a7f2f958d58f0efe4648259 + +reportedly you would get -EBADF there when no output is generated. + +Also this reportedly happens with virtio console only, not virtio serial port. + +It seems that the author of said testsuite did not report the problem so I write it down so it does not get lost. + +test (in bash): + +n=0 ; while [ $n -lt 100 ] && grep -m 1 -F "WireGuard Test Suite on Linux 4.8.6" <( /opt/qemu/bin/qemu-system-x86_64 -nodefaults -nographic -machine q35,accel=kvm -cpu host -smp 2 -m 64M -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -device virtio-serial,max_ports=2 -chardev stdio,id=stdio -device virtconsole,chardev=stdio -chardev file,id=status,path=result.txt -device virtserialport,chardev=status -monitor none -kernel wireguard-testing-harness-bzImage-e87cb2a7-145c-4985-907f-17e81fae329b -append "console=hvc0 initcall_debug=1 loglevel=7" ) ; do echo $n ; n=$(expr $n + 1) ; pkill -f wireguard ; done + +This typically does 10-20 iterations but sometimes tens of iterations run without issue. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1639983 b/results/classifier/deepseek-2/output/device/1639983 new file mode 100644 index 000000000..793c75774 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1639983 @@ -0,0 +1,22 @@ + +e1000 EEPROM have bad checksum + +I am using qemu-system-i386 to emulate FreeDOS with e1000 nic card. + +I am using Intel PRODOS v.19.0 (latest version with E1000ODI.COM file). +E1000ODI.COM v.5.07 (140116) + +http://pclosmag.com/html/issues/201208/page11.html +Suggest that v.4.75 (120212) was/is working. +Oldest PRODOS available version seems now 18.5 (June 2013) which I have not tested yet. + +When running it, it detect: Slot 18, IRQ 11, Port C000. + +But complains: +EEPROM checksum was incorrect. + +Contact your services network supplier for a replacement. + +paul@paul89473:~$ qemu-system-i386 --version +QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu5), Copyright (c) 2003-2008 Fabrice Bellard +paul@paul89473:~$ \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1640 b/results/classifier/deepseek-2/output/device/1640 new file mode 100644 index 000000000..c13345f56 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1640 @@ -0,0 +1,26 @@ + +aarch64: usb_mtp_get_data: Assertion `(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed +Description of problem: +When attempting to write to an MTP device in QEMU 8.0.0 on arm64, QEMU will crash at runtime with the following error: +`qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.` + +This was observed in Nixpkgs where we use QEMU to provide automated testing of MTP devices for GVFS and jmtpfs, the full log for that test run that crashes due to this QEMU regression on arm64 is available here https://hydra.nixos.org/build/218858556/nixlog/1 +Steps to reproduce: +1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0 +2. Mount the MTP device using something like: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + dd if=/dev/urandom of=./mtpDevice/file + ``` +4. Observe that QEMU will crash when trying to write to the device, like this: + ``` + client # 10+0 records in + client # 10+0 records out + client # 10485760 bytes (10 MB, 10 MiB) copied, 0.0318363 s, 329 MB/s + client # qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.error + ``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1643342 b/results/classifier/deepseek-2/output/device/1643342 new file mode 100644 index 000000000..899cbbccd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1643342 @@ -0,0 +1,26 @@ + +not able to passthrough mouse / keyboard + +After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: + +qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' + +This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error) +I use the following script: + + +qemu-system-x86_64 \ +-enable-kvm \ +-m 16392 \ +-cpu host,kvm=off \ +-smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ +-usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ +-vga none \ +-device vfio-pci,host=01:00.0,multifunction=on \ +-device vfio-pci,host=01:00.1 \ +-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ +-drive if=pflash,format=raw,file=/tmp/my_vars.fd \ +-device virtio-scsi-pci,id=scsi \ +-drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ +-drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ +-drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1645 b/results/classifier/deepseek-2/output/device/1645 new file mode 100644 index 000000000..9a347a06d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1645 @@ -0,0 +1,9 @@ + +qemu error `hotplug memory" error="QMP command failed: a used vhost backend has no free memory slots left"` +Description of problem: +When I create a Qemu VM with 8 Gpus and hot-plugging memory, this will return the error QMP command failed: a used vhost backend has no free memory slots left. I read some source file https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost-user.c#L2077, and debug show u->user->memory_slots is 32, but this https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c#L62 used_memslots is bigger than u->user->memory_slots. `u->user->memory_slots` is defined 32 by https://gitlab.com/qemu-project/qemu/-/blob/master/subprojects/libvhost-user/libvhost-user.h#L37, but I also see VHOST_USER_MAX_RAM_SLOTS defined 512 under x86 architecture. Can I improve `u->user->memory_slots` by any way? +Steps to reproduce: +1.crate kata containers with 8 Gpus +2.kata containers return error +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1646 b/results/classifier/deepseek-2/output/device/1646 new file mode 100644 index 000000000..30003bb0c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1646 @@ -0,0 +1,62 @@ + +fstrim dont work after live migrate +Description of problem: +We have use lvm thin pool and after live migration non-shared storage fstrim cannot free data usage Data% without reboot, after reboot fstim work fine + +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-aotz-- 30.00g pool 99.35 + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":0}]}} + +virsh shutdown p639937 +Domain 'p639937' is being shutdown + +virsh start p639937 +Domain 'p639937' started + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":29178654720}]}} + +lvs|grep p639937 + p639937 vm Vwi-aotz-- 30.00g pool 9.58 +``` + +On source host before migration: +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-a-tz-- 30.00g pool 9.48 +``` + +migration script +``` +SSH_OPTS='-o StrictHostKeyChecking=no -o PasswordAuthentication=no ' +MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +ssh $SSH_OPTS $HOST -t "[ -b /dev/vm/$ACCT ] || /usr/sbin/lvcreate -V${SIZE}G -T vm/pool -n$ACCT" || f_print_err "Error: creation lvm" +virsh migrate $MIGR_OPTS $ACCT qemu+ssh://$SERV/system tcp://local.$SERV/ || f_print_err "Error on step: virsh migrate" +echo "Waiting for trim start..." +sleep 10 +ssh $SSH_OPTS $HOST -t "/usr/bin/virsh qemu-agent-command $ACCT --timeout 60 '{\"execute\":\"guest-fstrim\"}' >/dev/null 2>&1" +``` + +Disc config: +``` + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> + <source dev='/dev/vm/p639937'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <iotune> + <write_bytes_sec>104857600</write_bytes_sec> + <write_bytes_sec_max>524288000</write_bytes_sec_max> + <write_bytes_sec_max_length>120</write_bytes_sec_max_length> + </iotune> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> +``` + +Sometimes trimming working after migration, bit this is very rare. +We have try rescanning disc, drop caches on vm after migration, but didnt help. + +Inside vm's ext4 fs and almalinux 8/ubuntu 20+/debian 10-11 diff --git a/results/classifier/deepseek-2/output/device/1646610 b/results/classifier/deepseek-2/output/device/1646610 new file mode 100644 index 000000000..5df7101e6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1646610 @@ -0,0 +1,71 @@ + +"Assertion `!r->req.sg' failed." during live migration with VirtIO + +We've hit this issue twice so far, but don't have an obvious repro yet. It's pretty rare for us to hit it but I'm still trying so I can get a core and backtrace. The guest was Windows running a constant workload. We were using VirtIO SCSI drivers in both cases. + +In both cases we hit the assert here: + +hw/scsi/scsi-generic.c: + +static void scsi_generic_save_request(QEMUFile *f, SCSIRequest *req) +{ + SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req); + + qemu_put_sbe32s(f, &r->buflen); + if (r->buflen && r->req.cmd.mode == SCSI_XFER_TO_DEV) { +*** assert(!r->req.sg); + qemu_put_buffer(f, r->buf, r->req.cmd.xfer); + } +} + +From code inspection, it seems that this will always happen if scsi_req_enqueue_internal in hw/scsi/scsi-bus.c is ever invoked. + +static void scsi_req_enqueue_internal(SCSIRequest *req) +{ + assert(!req->enqueued); + scsi_req_ref(req); + if (req->bus->info->get_sg_list) { + req->sg = req->bus->info->get_sg_list(req); + } else { + req->sg = NULL; + } + req->enqueued = true; + QTAILQ_INSERT_TAIL(&req->dev->requests, req, next); +} + +req->bus->info->get_sg_list will return &req->qsgl for a virtio-scsi bus since it's a method stored on the SCSIBusInfo struct. I didn't see anything that would clear the req->sg if scsi_req_enqueue_internal is called at least once. + +I think this can only happen if scsi_dma_restart_bh in hw/scsi/scsi-bus.c is called. The only other location I see scsi_req_enqueue_internal is on the load side for the destination of a migration. + +static void scsi_dma_restart_bh(void *opaque) +{ + SCSIDevice *s = opaque; + SCSIRequest *req, *next; + + qemu_bh_delete(s->bh); + s->bh = NULL; + + QTAILQ_FOREACH_SAFE(req, &s->requests, next, next) { + scsi_req_ref(req); + if (req->retry) { + req->retry = false; + switch (req->cmd.mode) { + case SCSI_XFER_FROM_DEV: + case SCSI_XFER_TO_DEV: + scsi_req_continue(req); + break; + case SCSI_XFER_NONE: + scsi_req_dequeue(req); + scsi_req_enqueue(req); // *** this calls scsi_req_enqueue_internal + break; + } + } + scsi_req_unref(req); + } +} + +Finally when put_scsi_requests is called for migration, it seems like it will call both virtio_scsi_save_request (from bus->info->save_request) and scsi_generic_save_request (from req->ops->save_request) and trigger the assert. + +I searched for a bit, but didn't find anyone else reporting this. Has anyone else seen this? It seems to me like that assert should check that the sg list is empty instead of checking that it exists. Is this an appropriate assessment? Assuming I find a repro, I'll try to test this solution. + +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1648726 b/results/classifier/deepseek-2/output/device/1648726 new file mode 100644 index 000000000..1ff27d8dc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1648726 @@ -0,0 +1,21 @@ + +[usb-host] Passthrough of UAS devices fails with Windows (10) guests + +Split off from #1579306 as this is a distinct issue. + +Physical USB storage devices that support the UAS protocol do not work correctly when passed through to Windows guests (I've only tested this with Windows 10 x64, build 1607). + +Passing through such a device results in the older BOT/MSC protocol being used: + +<See attachment win10-uas-fail.png> + +Using the same domain configuration with a Linux guest (tested with SystemRescueCD 4.8.0) works correctly: + +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + + +In both cases, the VM was launched via libvirt, which generated the following command line: + +/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1651 b/results/classifier/deepseek-2/output/device/1651 new file mode 100644 index 000000000..48180d22c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1651 @@ -0,0 +1,2 @@ + +bcm2835 timer jumps to max delay diff --git a/results/classifier/deepseek-2/output/device/1654 b/results/classifier/deepseek-2/output/device/1654 new file mode 100644 index 000000000..77d43a005 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1654 @@ -0,0 +1,82 @@ + +Memory out of bounds access vulnerability when guest accesses Block Limits information of SCSI devices +Description of problem: +When a guest uses a Linux kernel version 5.19 or higher and uses an scsi device, there will be a memory access violation, which can be clearly seen when ASAN is turned on. + +**reason：** +Linux kernel 5.19 merge commit： + +https://github.com/torvalds/linux/commit/c92a6b5d63359dd6d2ce6ea88ecd8e31dd769f6b + +The Linux kernel will first issue a header request to obtain the VPD length before obtaining the VPD information. The BUF for obtaining the VPD length is less than 8 bytes. However, QEMU regards the header for obtaining the VPD length as obtaining all VPD information, and a memory access violation occurs when writing information to BUF. + +The specific memory out of bounds information is as follows: +==12430==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! + +==12430==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: +0x7fffebc1d000; bottom 0x7f61115ee000; size: 0x009eda62f000 (682268749824) + +False positive error reports may follow + +==12430==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200024d858 at pc 0x55767513791c bp 0x7f6111fcddc0 sp 0x7f6111fcddb0 + +WRITE of size 4 at 0x60200024d858 thread T0 + + #0 0x55767513791b in stl_he_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 + + #1 0x55767513791b in stl_be_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:464 + + #2 0x55767513791b in scsi_handle_inquiry_reply hw/scsi/scsi-generic.c:173 + + #3 0x55767513791b in scsi_read_complete hw/scsi/scsi-generic.c:318 + + #4 0x55767545d7c6 in blk_aio_complete block/block-backend.c:1425 + + #5 0x557675544d79 in coroutine_trampoline util/coroutine-ucontext.c:115 + + #6 0x7f611b9f14df (/lib/x86_64-linux-gnu/libc.so.6+0x5b4df) + +0x60200024d858 is located 4 bytes to the right of 4-byte region [0x60200024d850,0x60200024d854) + +allocated by thread T0 here: + + #0 0x557674a987f2 in malloc (/sf/bin/qemu-system-x86_64+0x7827f2) + + #1 0x7f6120141d41 in g_malloc (/usr/lib/libglib256-2.0.so.0+0x61d41) + + #2 0x557675137bb4 in scsi_send_command hw/scsi/scsi-generic.c:459 + + #3 0x55767513e902 in scsi_req_enqueue hw/scsi/scsi-bus.c:836 + + #4 0x557674c5f26e in virtio_scsi_handle_cmd_req_submit /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:589 + + #5 0x557674c5f26e in virtio_scsi_handle_cmd_vq /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:634 + + #6 0x557674c61089 in virtio_scsi_data_plane_handle_cmd /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi-dataplane.c:60 + + #7 0x557674c9a520 in virtio_queue_notify_aio_vq /root/hci/qemu/qemu-5.0.0/hw/virtio/virtio.c:2338 + + #8 0x55767552c7c4 in aio_dispatch_handler util/aio-posix.c:328 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 stl_he_p +Steps to reproduce: +1. QEMU Enable ASAN +2. Use a guest with a Linux kernel version greater than 5.19 and mount an scsi physical device +3. Upon startup, memory out of bounds access can be detected +Additional information: +At present, I have made some simple modifications, but I am not sure if this is the best solution and can serve as a reference. + +Make a judgment on buflen, ignore the header information issued by the Linux kernel, and write the VPD information when issuing the actual instruction to obtain VPD information. + +hw/scsi/scsi-generic.c:scsi_handle_inquiry_reply + +``` +if (r->buflen >= 12) { + stl_be_p(&r->buf[8], max_transfer); +} +if (r->buflen >= 16){ + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); +} +``` diff --git a/results/classifier/deepseek-2/output/device/1656234 b/results/classifier/deepseek-2/output/device/1656234 new file mode 100644 index 000000000..6cdbf633a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1656234 @@ -0,0 +1,38 @@ + +Qemu core dumped if using virtio-net + +System Environment +======= +Qemu commit/branch: e92fbc75 +Host OS: RHEL7.2 ia32e +Host Kernel: 4.9.0 +Guest OS: RHEL7.2 ia32e +Guest Kernel: 4.9.0 + +Bug detailed description +======= +While create a kvm guest using virtio-net, the qemu will core dump with showing "Aborted (core dumped)". +Reproduce Steps +============== +create a guest: +qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:49:be:24 -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/ia32e_rhel7u2_kvm.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -serial file:serial.log + +Current Result: +============== + +qemu-system-x86_64: /workspace/ia32e/nightly/kvm-next-20170105-ef85b6-e92fbc/kvm/qemu/hw/virtio/virtio.c:214: virtio_queue_set_notification: Assertion `vq->notification_disabled > 0' failed. +Aborted (core dumped) + +add info +======== +[root@hsw-ep2 Desktop]# dmesg |grep -v virbr0 |tail -n 10 +[ 1760.265000] device tap0 left promiscuous mode +[ 1879.148642] device tap0 entered promiscuous mode +[ 1885.213702] kvm [14186]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 1912.258783] device tap0 left promiscuous mode +[ 1995.972267] device tap0 entered promiscuous mode +[ 2001.990207] kvm [14335]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 2024.703072] device tap0 left promiscuous mode +[ 2145.374239] device tap0 entered promiscuous mode +[ 2151.409948] kvm [14541]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 2178.281446] device tap0 left promiscuous mode \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1657 b/results/classifier/deepseek-2/output/device/1657 new file mode 100644 index 000000000..601845607 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1657 @@ -0,0 +1,34 @@ + +Unable to use ide hard drive when using xlnx-zcu102 board +Description of problem: +I have only recently started using qemu and am reading content related to ahci. When I started QEMU using the above command line (I did not specify the Linux kernel because I only wanted to see which devices were initialized on the motherboard), I found the following devices in the device tree: + ``` +dev: sysbus-ahci, id "" + +gpio-out "sysbus-irq" 1 + +num-ports = 2 (0x2) + +mmio 00000000fd0c0000/0000000000001000 + +bus: ide.1 + +type IDE + +bus: ide.0 + +type IDE + ``` + +I think this is similar to the ICH9 ahci device, so I tried to mount an IDE hard drive（using command line：-drive file=./testide.img）but failed. QEMU shows + ``` +qemu-system-aarch64: -drive file=./ testide.img: machine type does not support if=ide,bus=0,unit=0 + ``` +So if the ide bus generated by sysbus ahci cannot mount a hard drive, what device should it mount? +It will be grateful if anyone can answer this question. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1658506 b/results/classifier/deepseek-2/output/device/1658506 new file mode 100644 index 000000000..a82e95856 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1658506 @@ -0,0 +1,12 @@ + +qemu/hw/intc/arm_gicv3_cpuif.c:2433: bad expression ? + +qemu/hw/intc/arm_gicv3_cpuif.c:2433]: (style) Expression '(X & 0x2000000000000000) == 0x1' is always false. + +Source code is + + ((lr & ICH_LR_EL2_HW) == 1 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Maybe better code + + ((lr & ICH_LR_EL2_HW) != 0 || (lr & ICH_LR_EL2_EOI) == 0)) { \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1661758 b/results/classifier/deepseek-2/output/device/1661758 new file mode 100644 index 000000000..194baf3b5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1661758 @@ -0,0 +1,118 @@ + +qemu-nbd causes data corruption in VDI-format disk images + +Hi, + +This is a duplicate of #1422307. I can't figure out a way to re-open +it--the status of "Fix Released" is changeable only by a project +maintainer or bug supervisor--so I'm opening a new bug to make sure +this gets looked at again. + +qemu-nbd will sometimes corrupt VDI disk images. The bug was thought +to be fixed in commit f0ab6f109630940146cbaf47d0cd99993ddba824, but +I'm able to reproduce it in both that commit and in the latest commit +(a951316b8a5c3c63254f20a826afeed940dd4cba). I just needed to run more +iterations of the test. It's possible that it was partially fixed, or +that the added serialization made it harder to catch this +non-deterministic bug, but the same symptoms persist: data corruption +of VDI-format disk images. + +This affects at least qemu-nbd. I haven't tried reproducing the issue +with qemu proper or qemu-img, but the original bug report suggests +that the bug in the common VDI backend may corrupt data written by +those programs. + +Please let me know if I can provide any further information or help +with testing. Thank you very much for looking into this! + +Test procedure +************** + +The procedure used is the one given by Max Reitz (xanclic) in the +original bug report, comment 3 +(https://bugs.launchpad.net/qemu/+bug/1422307/comments/3), in the +section "VDI and NBD over /dev/nbd0", but with up to 1000 iterations +instead of 10: + + $ cd ~/qemu-origfix-f0ab6f1/bin + $ dd if=/dev/urandom of=blob.raw bs=1M count=64 + 64+0 records in + 64+0 records out + 67108864 bytes (67 MB) copied, 4.36475 s, 15.4 MB/s + $ sudo sh -c 'for i in $(seq 0 999); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; ./qemu-nbd -c /dev/nbd0 test.vdi; sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo "done"' +27a66c3a8ac2cf06f2c925968ea9e964 test1.raw +2da9bf169041a7c2bd144c4ab3a29aea test2.raw +64 failed +done + +I've run this process a handful of times, and I've seen it take as +little as 10 iterations and as many as 161 (taking 32 minutes in the +latter case). Please be patient. Putting the images on tmpfs will +probably help it go faster, and I have successfully reproduced the +issue on tmpfs in addition to ext4. + +Nothing different was needed to reproduce the issue in a directory +containing a build of the latest commit. It still takes somewhere +around 1-200 iterations to find, in my testing. + +Build procedure +*************** + + $ git clone git://git.qemu-project.org/qemu.git + [omitted] + $ git clone qemu qemu-origfix-f0ab6f1 + Cloning into 'qemu-origfix-f0ab6f1'... + done. + $ cd qemu-origfix-f0ab6f1 + $ git checkout f0ab6f109630940146cbaf47d0cd99993ddba824 + Note: checking out 'f0ab6f109630940146cbaf47d0cd99993ddba824'. + + You are in 'detached HEAD' state. You can look around, make experimental + changes and commit them, and you can discard any commits you make in this + state without impacting any branches by performing another checkout. + + If you want to create a new branch to retain commits you create, you may + do so (now or later) by using -b with the checkout command again. Example: + + git checkout -b new_branch_name + + HEAD is now at f0ab6f1... block/vdi: Add locking for parallel requests + $ mkdir bin + $ cd bin + $ script -c'time (../configure --enable-debug --target-list=x86_64-softmmu && make -j6; echo "result: $?")' + Script started, file is typescript + [omitted; the build typescript is attached separately] + LINK x86_64-softmmu/qemu-system-x86_64 + result: 0 + + real 1m5.733s + user 2m3.904s + sys 0m13.828s + Script done, file is typescript + +Nothing different was done when building the latest commit (besides +cloning to a different directory, and not running `git checkout`). + +Environment +*********** + + * Machine: x86_64 + + * Hypervisor: Xen 4.4 (Debian package xen-hypervisor-4.4-amd64, + version 4.4.1-9+deb8u8) + + * A Xen domU (guest) for building QEMU and reproducing the issue. + All testing was done within the virtual machine for convenience + and access to better hardware than what I have for my development + machine (I expected the build to take much longer than it really + does). + + - x86_64 architecture with six VCPUs and 1.2 GiB RAM allocated, + operating in HVM (fully virtualized) mode. + + - Distribution: Debian 8.7 Jessie amd64 + + - Kernel: Linux 3.16.0 x86_64 (Debian package + linux-image-3.16.0-4-amd64, version 3.16.39-1) + + - Compiler: GCC 4.9.2 (Debian package gcc-4.9, version 4.9.2-10) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1667613 b/results/classifier/deepseek-2/output/device/1667613 new file mode 100644 index 000000000..87740b068 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1667613 @@ -0,0 +1,15 @@ + +Qemu 2.8 on PPC64 issue with input + +Hi devs, +on my PPC64 machine if i start qemu with gtk,gl=on or with sdl,gl=on i have issue with pointer and keyboard. pratically not input at all. +This issue is present in tgc and in kvm + +without gl=on option in kvm with mate as guest i have the input device work in the beginning but after some time the usb goes "unplugged" (i see this message on the serial log of qemu usb unplugged) and the keyboard and mouse dont work. + +On Debian jessie kvm i dont have input working at all. + +my machine is a G5 quad with Fedora 25 PPC64 + +thanks +Luigi \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1674114 b/results/classifier/deepseek-2/output/device/1674114 new file mode 100644 index 000000000..503ead4e1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1674114 @@ -0,0 +1,28 @@ + +Bad sectors when using MS-DOS 6.22 + +When I try to install DOS 6.22 in QEMU, I get many disk errors when the virtual disk is beeing partionized and formatted. When I later do a SCANDISK, I can see many bad sectors and file errors. + +I have tested this with the following disk formats: qcow2, vmdk, raw. + +I tested this on Windows 7 with the following command line and QEMU version: +qemu-system-i386 -name "Windows 3.11 WfW" -machine isapc -cpu 486 -boot order=adc -m 32 -soundhw sb16 -hda disk1.qcow2 -vga cirrus + +qemu-system-i386 --version +QEMU emulator version 2.8.50 (v2.8.0-12557-g0bd1f6b1b2-dirty) +Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +I then did a test with the linux version of qemu, which gave me the same results. +Command line: qemu-system-i386 -name "Windows 3.11 WfW" -machine isapc -cpu 486 -boot order=adc -m 32 -soundhw sb16 -hda disk1.qcow2 -vga cirrus -monitor stdout +Version: qemu-system-i386 --version +QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c) 2003-2008 Fabrice Bellard + +I also checked the disk image with qemu-img, with no results: + +No errors were found on the image. +7986/8000 = 99.83% allocated, 0.20% fragmented, 0.00% compressed clusters +Image end offset: 523698176 + +Because I got the error with two different versions of QEMU, I think this is a general problem and not related to a specific distribution. + +I have attached a zip file with screenshots of SCANDISK, which shows the disk errors. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1675332 b/results/classifier/deepseek-2/output/device/1675332 new file mode 100644 index 000000000..5179b4cc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1675332 @@ -0,0 +1,4 @@ + +qemu-system crashes when use sheepdog driver + +Already solved. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1675333 b/results/classifier/deepseek-2/output/device/1675333 new file mode 100644 index 000000000..5179b4cc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1675333 @@ -0,0 +1,4 @@ + +qemu-system crashes when use sheepdog driver + +Already solved. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1677247 b/results/classifier/deepseek-2/output/device/1677247 new file mode 100644 index 000000000..aefd4f58f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1677247 @@ -0,0 +1,13 @@ + +QEMU e500 kvm no video and kernel crashing in virtios modules + +Hi, +i been attached the log of my issue on Qoriq e5500 +when i start qemu-system-ppc64 -cpu e5500 -M ppce500 --enable-kvm -device virtio-gpu-pci --nodefaults -display gtk and so and so . i have crashes in virtio modules in the VM and continue traces on the host machine. +If is needed more for investigating ask freely . + +Note: i use my selfmade kernel this machine dont have a distro kenels and official kernels. + + +Ciao +Luigi \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1677492 b/results/classifier/deepseek-2/output/device/1677492 new file mode 100644 index 000000000..3b2ddbe18 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1677492 @@ -0,0 +1,11 @@ + +block_set_io_throttle complaints Need exactly one of 'device' and 'id' + +All of sudden, after a qemu update, block_set_io_throttle does not work anymore. + +Full command to QEMU monitor -- + +(qemu) block_set_io_throttle db 0 0 0 0 0 0 +Need exactly one of 'device' and 'id' + +The help text still point to the same old syntax, which no longer works. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/168 b/results/classifier/deepseek-2/output/device/168 new file mode 100644 index 000000000..0d89d65f5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/168 @@ -0,0 +1,2 @@ + +ivshmem PCI device exposes wrong endianness on ppc64le diff --git a/results/classifier/deepseek-2/output/device/1680679 b/results/classifier/deepseek-2/output/device/1680679 new file mode 100644 index 000000000..46640b1fc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1680679 @@ -0,0 +1,80 @@ + +qemu cannot run twice + +After using qemu with gpu passthrough and then shutting down windows 7 properly I cannot boot windows 7 a second time. +Only a full reboot of linux fixes this issue. +Qemu appears to corrupt something in linux when exiting. +I get no error messages but windows 7 never finishes booting during the 2nd try. +Apparently I do try to run vfiobind each time the script is run. +Wondering if rerunning vfiobind can cause an issue? + + +My specs: +----------------------------------------------------------------------------------------- +System: Host: GT70-2PE Kernel: 4.5.4-040504-generic x86_64 (64 bit gcc: 5.3.1) + Desktop: Cinnamon 3.2.7 (Gtk 3.18.9) Distro: Linux Mint 18.1 Serena +Machine: Mobo: Micro-Star model: MS-1763 v: REV:0.C Bios: American Megatrends v: E1763IMS.51B date: 01/29/2015 +CPU: Quad core Intel Core i7-4810MQ (-HT-MCP-) cache: 6144 KB + flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 22347 + clock speeds: max: 2801 MHz 1: 2801 MHz 2: 2801 MHz 3: 2801 MHz 4: 2801 MHz 5: 2801 MHz 6: 2801 MHz + 7: 2801 MHz 8: 2801 MHz +Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0 + Card-2: NVIDIA GK104M [GeForce GTX 880M] bus-ID: 01:00.0 + Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) + Resolution: 1920x1080@60.02hz, 1920x1080@60.00hz + GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 12.0.6 Direct Rendering: Yes + + +My script: +------------------------------------------------------------------------------------------- +#!/bin/bash + +cd ~/qemu +sudo ./up.sh tap0 + +configfile=~/qemu/vfio-pci1.cfg + +vfiobind() { + dev="$1" + vendor=$(cat /sys/bus/pci/devices/$dev/vendor) + device=$(cat /sys/bus/pci/devices/$dev/device) + if [ -e /sys/bus/pci/devices/$dev/driver ]; then + echo $dev > /sys/bus/pci/devices/$dev/driver/unbind + fi + echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id + +} + +modprobe vfio-pci + +cat $configfile | while read line;do + echo $line | grep ^# >/dev/null 2>&1 && continue + vfiobind $line +done + +sudo qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host,kvm=off \ +-smp 8,sockets=1,cores=4,threads=2 \ +-bios /usr/share/seabios/bios.bin \ +-serial none \ +-parallel none \ +-vga none \ +-m 4G \ +-mem-path /run/hugepages/kvm \ +-mem-prealloc \ +-balloon none \ +-rtc clock=host,base=localtime \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=/home/dad/qemu/windows7.img \ +-drive file=/home/dad/1TB-Backup/Iso/SP1ForWin7.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ +-net nic -net tap,ifname=tap0,script=no,downscript=no \ +-usbdevice host:413c:a503 \ +-usbdevice host:13fe:3100 \ +-usbdevice host:0bc2:ab21 \ +-boot menu=on \ +-boot order=c + +sudo ./down.sh tap0 + +exit 0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1681398 b/results/classifier/deepseek-2/output/device/1681398 new file mode 100644 index 000000000..1f1a714c0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1681398 @@ -0,0 +1,11 @@ + +hw/core: segmentation fault + +Reproducer: + $i386-softmmu/qemu-system-i386 -S -machine isapc,accel=tcg -device amd-iommu +Segmentation fault (core dumped) + +Partial bt: +#0 bus_add_child (child=0x555556d4e520, bus=0x0) at hw/core/qdev.c:88 +#1 qdev_set_parent_bus (dev=0x555556d4e520, bus=bus@entry=0x0) +at hw/core/qdev.c:119 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1681404 b/results/classifier/deepseek-2/output/device/1681404 new file mode 100644 index 000000000..f03da6610 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1681404 @@ -0,0 +1,9 @@ + +hw/ppc: Aborted (core dumped) + +Reproducable: +$ ./ppc64-softmmu/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge + + +qemu/hw/ppc/spapr_pci.c:1567:spapr_phb_realize: Object 0x55bda99744a0 is not an instance of type spapr-machine +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1681439 b/results/classifier/deepseek-2/output/device/1681439 new file mode 100644 index 000000000..64123f5d2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1681439 @@ -0,0 +1,36 @@ + +dma_blk_cb leaks memory map handles on misaligned IO + +Since upgrading to QEMU 2.8.0, my Windows 7 64-bit virtual machines +started crashing due to the assertion quoted in the summary failing. +The assertion in question was added by commit 9972354856 ("block: add +BDS field to count in-flight requests"). My tests show that setting +discard=unmap is needed to reproduce the issue. Speaking of +reproduction, it is a bit flaky, because I have been unable to come up +with specific instructions that would allow the issue to be triggered +outside of my environment, but I do have a semi-sane way of testing that +appears to depend on a specific initial state of data on the underlying +storage volume, actions taken within the VM and waiting for about 20 +minutes. + +Here is the shortest QEMU command line that I managed to reproduce the +bug with: + + qemu-system-x86_64 \ + -machine pc-i440fx-2.7,accel=kvm \ + -m 3072 \ + -drive file=/dev/lvm/qemu,format=raw,if=ide,discard=unmap \ + -netdev tap,id=hostnet0,ifname=tap0,script=no,downscript=no,vhost=on \ + -device virtio-net-pci,netdev=hostnet0 \ + -vnc :0 + +The underlying storage (/dev/lvm/qemu) is a thin LVM snapshot. + +QEMU was compiled using: + + ./configure --python=/usr/bin/python2.7 --target-list=x86_64-softmmu + make -j3 + +My virtualization environment is not really a critical one and +reproduction is not that much of a hassle, so if you need me to gather +further diagnostic information or test patches, I will be happy to help. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1681688 b/results/classifier/deepseek-2/output/device/1681688 new file mode 100644 index 000000000..428bc19bb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1681688 @@ -0,0 +1,14 @@ + +qemu live migration failed + +qemu live migration failed + +the dest qemu report this error. + +Receiving block device images +Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. + +this bug is caused by this patch: +http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a + +rollback this commit, the problem solved. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1688231 b/results/classifier/deepseek-2/output/device/1688231 new file mode 100644 index 000000000..662873c0b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1688231 @@ -0,0 +1,32 @@ + +[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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1689003 b/results/classifier/deepseek-2/output/device/1689003 new file mode 100644 index 000000000..87b4d3e37 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1689003 @@ -0,0 +1,14 @@ + +USB passthrough should not fail if SET CONFIGURATION fails + +QEMU's USB passthrough was not working for my new smartphone. + +While analyzing the problem, I found out that a SET CONFIGURATION Request was NACKed by the USB device (probably because a SET CONFIGURATION request was already sent from the host to the device). + +So I wrote a simple program to fake a successful call to libusb_set_configuration and did an LD_PRELOAD on this program before starting qemu, and it worked. + +Looking at QEMU's code in host-libusb.c, I can see that QEMU does not try to claim the interface if its call to libusb_set_configuration fails. + +I think QEMU should try to claim the device anyway even if libusb_set_configuration fails. + +I did my tests against QEMU 2.6.2, but as I can see from the source code, this problem should happen on all versions. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1691 b/results/classifier/deepseek-2/output/device/1691 new file mode 100644 index 000000000..d7f21336d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1691 @@ -0,0 +1,11 @@ + +QEMU's NVMe emulator behaving not standard compliant +Description of problem: +QEMU's NVMe emulator behaves slightly non-conformant to the standard. +For one, in the CAP.CSS register, bits 0, 6 and 7 are set. Bit 7 indicates that the NVMe Controller does not support any I/O Command Set, while bit 6 is set when the NVMe Controller supports one or more I/O Command Sets (see Figure 36 of the NVM Express® Base Specification, Revision 2.0c). This is obviously contradictory and only bit 6 (and 0) should be set. These bits are configured in hw/nvme/ctrl.c:8250. +The NVMe emulator also checks whether the values of CC.IOSQES and CC.IOCQES are within the allowed range when the controller is enabled by setting CC.EN to 1. However this check should not be performed yet, as the allowed range can only be discovered after the controller is enabled, by submitting the Identify Command. This command reports the valid range in the Identify Controller Data Structure, however it requires the controller to be enabled which in turn would, at least in the current version, require valid values in CC.IOSQES and CC.IOCQES. The NVMe emulator also uses the values configured in CC.IOSQES and IO.IOCQES for the Admin Queues which, from what I understand, should not be the case. Only the I/O Queues should use these values. These checks are done in hw/nvme/ctrl.c:7199f. In the same function the values are already used to initialize the controllers cqe_size and sqe_size which should also happen at a later time. +Steps to reproduce: +1. Start any virtual machine with a NVMe Controller attached. +2. Read the value of CAP.CSS (located in BAR0 of the PCIe NVMe Controller). This value will be contradictory. +3. Follow the initialization procedure as described in section 3.5.1 of the NVM Express® Base Specification, Revision 2.0c. Do not set the values of CC.IOSQES and CC.IOCQES. +4. The NVMe Controller will fail to enable when setting CC.EN to 1 by setting CC.CFS to 1 and reporting the respective trace event (pci_nvme_err_startfail_cqent_too_small and variations). diff --git a/results/classifier/deepseek-2/output/device/1691379 b/results/classifier/deepseek-2/output/device/1691379 new file mode 100644 index 000000000..45589310f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1691379 @@ -0,0 +1,46 @@ + +NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el. + +I successfully installed the NetBSD evbmips64el port on gxemul but was unable to install it on qemu. Trying to boot it on qemu takes me to the 'db>' prompt. Here's the output and backtrace: + +panic: pcib_isa_intr_string: bogus isa irq 0x0 +kernel: breakpoint trap +Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x4: jr ra + bdslot: nop +db> bt +0xffffffff805977f0: cpu_Debugger+4 (63061,90000000180003f8,6,ffffffff804c2290) ra ffffffff8030acd0 sz 0 +0xffffffff805977f0: vpanic+158 (63061,90000000180003f8,6,ffffffff804c2290) ra ffffffff8030ad7c sz 64 +0xffffffff80597830: panic+34 (63061,ffffffff803d65b0,0,40) ra ffffffff80109784 sz 96 +0xffffffff80597890: pcib_isa_intr_string+6c (63061,ffffffff803d65b0,0,40) ra ffffffff80149bfc sz 16 +0xffffffff805978a0: uhci_pci_attach+16c (63061,ffffffff803d65b0,0,40) ra ffffffff802f0400 sz 176 +0xffffffff80597950: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,40) ra ffffffff802f053c sz 64 +0xffffffff80597990: config_found_sm_loc+5c (63061,ffffffff803d65b0,0,40) ra ffffffff80121354 sz 64 +0xffffffff805979d0: pci_probe_device+524 (63061,ffffffff803d65b0,0,0) ra ffffffff80121548 sz 288 +0xffffffff80597af0: pci_enumerate_bus+1d0 (63061,ffffffff803d65b0,0,0) ra ffffffff8012167c sz 160 +0xffffffff80597b90: pcirescan+5c (63061,ffffffff803d65b0,0,0) ra ffffffff801218c4 sz 32 +0xffffffff80597bb0: pciattach+19c (63061,ffffffff803d65b0,0,0) ra ffffffff802f0400 sz 80 +0xffffffff80597c00: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,0) ra ffffffff802f053c sz 64 +0xffffffff80597c40: config_found_sm_loc+5c (63061,ffffffff803d65b0,0,0) ra ffffffff80108934 sz 64 +0xffffffff80597c80: gt_attach+7c (63061,ffffffff803d65b0,0,0) ra ffffffff802f0400 sz 112 +0xffffffff80597cf0: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,0) ra ffffffff802f053c sz 64 +0xffffffff80597d30: config_found_sm_loc+5c (63061,ffffffff803d65b0,0,0) ra ffffffff801086ac sz 64 +0xffffffff80597d70: mainbus_attach+dc (63061,ffffffff803d65b0,0,0) ra ffffffff802f0400 sz 96 +0xffffffff80597dd0: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,0) ra ffffffff80104bf8 sz 64 +0xffffffff80597e10: cpu_configure+28 (63061,ffffffff803d65b0,0,0) ra ffffffff803d5f30 sz 16 +0xffffffff80597e20: main+3a0 (63061,ffffffff803d65b0,0,0) ra ffffffff801000dc sz 128 +0xffffffff80597ea0: kernel_text+dc (63061,ffffffff803d65b0,0,0) ra 0 sz 0 +User-level: pid 0.1 + +Here's the command that I used: + +Build evbmips64el from source and then launch it from qemu (replace the paths relative to your system): + +qemu-system-mips64el -cdrom /extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71-evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel /extra/evbmips64/releasedir/evbmips/installation/netbsd-INSTALL_MALTA64 -nographic -M malta + +(I've decompressed the kernel) + +Here's the output for qemu-system-mips64el --version : + +QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +This doesn't look like a NetBSD bug. I've attached a screenshot of the working installation using gxemul in the attachments. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1693050 b/results/classifier/deepseek-2/output/device/1693050 new file mode 100644 index 000000000..218c32317 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1693050 @@ -0,0 +1,12 @@ + +xhci HCIVERSION register read emulation incorrectly handled + +We had an illumos user trying to run illumos in QEMU 2.9.0 with the qemu-xhci device enabled. Note, that while this was discovered against QEMU 2.9.0, from my current read of the HEAD, it is still present. The illumos bug at https://www.illumos.org/issues/8173 has additional information on how the user invoked qemu. While investigating the problem we found that the illumos driver was reading a version of 0x0000 when reading the HCIVERSION register from qemu. + +In the illumos driver we're performing a 16-bit read of the version register at offset 0x2. From looking around at other OSes, while Linux performs a 4 byte read at offset 0x0 and masks out the version, others that care about the version are doing a two byte read, though not all actually act on the version and some just discard the information. + +The user who hit this was able to enable tracing (note the tracing file is attached to the illumos bug linked previously) and we hit the unimplemented register read with offset 0x2 at http://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l2960. The xhci register specifies today that its allowed for users to do 1-4 byte reads; however, that it implements only four byte reads in its implementation (http://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3333). Hence why when we read the HCIVERSION register at offset 0x2, it isn't handled in xhci_cap_read() which then returns zeros. + +From digging into this, I think that we're coming into memory_region_dispatch_read() and then memory_region_dispatch_read1(). However, I don't see anything in either the general memory region logic or in the xhci_cap_read() function that would deal with adjusting the offset that we're reading at and then masking it off again. While the access_with_adjusted_size() attempts to deal with this, it never adjusts the hardware address that's passed in to be a multiple of the implementation defined offset that I can see. I suspect that the FIXME at line 582 (http://git.qemu.org/?p=qemu.git;a=blob;f=memory.c;hb=HEAD#l582) and the implementation in the xhci code is the crux of the problem. + +For the time being we're working around this in the illumos driver, but I wanted to point this out such that it might be helpful for other systems which are assuming that they can do the two byte read like on hardware. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1699628 b/results/classifier/deepseek-2/output/device/1699628 new file mode 100644 index 000000000..5993d9da8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1699628 @@ -0,0 +1,18 @@ + +Direct Sound Audio does not stop + +The Bug: +DirectSound Audio does not stop because dsound_ctl_out does not end up calling IDirectSoundBuffer_Stop. This is due to a bug in dsound_get_status_out where the status flags returned from IDirectSoundBuffer_GetStatus are compared with DSERR_BUFFERLOST (an error code) rather than DSBSTATUS_BUFFERLOST (a status flag). The status is actually (DSBSTATUS_LOOPING | DSBSTATUS_PLAYING) and one of those flags happens to be set in the DSERR_BUFFERLOST value. As a result, dsound_get_status_out returns -1 and dsound_ctl_out exits before calling IDirectSoundBuffer_Stop. + +The Fix: +A simple replacement of DSERR_BUFFERLOST with DSBSTATUS_BUFFERLOST in dsound_get_status_out. +Should be: "if (*statusp & DSBSTATUS_BUFFERLOST) {" + +Version Information: +I was able to produce this bug in Qemu 2.9.0 and with the latest source pulled from git://git.qemu-project.org/qemu.git (commit 8dfaf23ae1). I was able to verify my suggested fix with the latest source. + +Guest OS: +Discovered running Minoca OS v0.4 (www.github.com/minoca/os). Images at https://www.minocacorp.com/download/nightlies/latest-x86. The Qemu test images I tried (http://wiki.qemu.org/Testing/System_Images) didn't have an easy sound setup (was looking for 'aplay' or similar). + +Qemu Command Line: +./qemu-system-x86_64.exe -m 512 -hda pc.img -smp 4 -usbdevice keyboard -device intel-hda -device hda-duplex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1702621 b/results/classifier/deepseek-2/output/device/1702621 new file mode 100644 index 000000000..d4915bb09 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1702621 @@ -0,0 +1,35 @@ + +colo: secondary vm crash during loadvm + +Following document 'COLO-FT.txt', I test colo feature on my hosts. It seems goes well. But after a while the secondary vm crash. The stack is as follows: +#0 0x00007f191456dc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007f1914571028 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x00007f1914566bf6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007f1914566ca2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +#5 0x0000564154a07cdb in qbus_reset_one (bus=0x564156760d10, opaque=0x0) at hw/core/qdev.c:319 +#6 0x0000564154a0d721 in qbus_walk_children (bus=0x564156760d10, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:68 +#7 0x0000564154a08b4d in qdev_walk_children (dev=0x56415675f2b0, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/qdev.c:617 +#8 0x0000564154a0d6e5 in qbus_walk_children (bus=0x564156594d30, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:59 +#9 0x0000564154a07df5 in qbus_reset_all (bus=0x564156594d30) at hw/core/qdev.c:336 +#10 0x0000564154a07e3a in qbus_reset_all_fn (opaque=0x564156594d30) at hw/core/qdev.c:342 +#11 0x0000564154a0e222 in qemu_devices_reset () at hw/core/reset.c:69 +#12 0x00005641548b3b47 in pc_machine_reset () at /vms/git/qemu/hw/i386/pc.c:2234 +#13 0x0000564154972ca7 in qemu_system_reset (report=false) at vl.c:1697 +#14 0x0000564154b9d007 in colo_process_incoming_thread (opaque=0x5641553c1280) at migration/colo.c:617 +#15 0x00007f1914907184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#16 0x00007f1914634bed in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +(gdb) frame 4 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +warning: Source file is more recent than executable. +311 assert(bus->irq_count[i] == 0); +(gdb) ^CQuit +(gdb) p bus->irq_count[i] +$1 = -1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1706058 b/results/classifier/deepseek-2/output/device/1706058 new file mode 100644 index 000000000..f45431e76 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1706058 @@ -0,0 +1,27 @@ + +Windows VM crashes when restoring from file if balloon stats polling is enabled + +[Impact] + + * Windows VMs BSOD when restoring from QEMUfile or during live migration if the virtio balloon stats polling is enabled. + +[Test Case] + + * Install a Windows VM with virtio balloon drivers + * Start the VM and enable stats polling [1] + * Save the VM to savefile [2] + * Restore the VM [3] + * Enable stats polling [1] and VM will BSOD + +QMP examples: + [1] {"execute":"qom-set","arguments":{"path":"//machine/i440fx/pci.0/child[7]","property":"guest-stats-polling-interval","value":10}} + [2] {"execute": "migrate", "arguments": {"uri":"exec:gzip -c > /storage/cases/VM/savefiles/testVM3save.gz"}} + [3] {"execute":"migrate-incoming","arguments":{"uri":"exec:gzip -c -d /storage/cases/VM/savefiles/testVM3save.gz"}} + +[Other Info] + + * This has been fixed upstream with commit 4a1e48becab81020adfb74b22c76a595f2d02a01 + +[Regression Potential] + + * \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1707587 b/results/classifier/deepseek-2/output/device/1707587 new file mode 100644 index 000000000..62a9e7d06 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1707587 @@ -0,0 +1,9 @@ + +Read certificate from USB key failed + +QEMU release version: qemu-2.9.0 +VM operation system: win7 32bit + +I have an usb key which can be redirected and recognized in VM. However, it is failed to get the certificate when using the official application for this usb key. What's more, the whole app is stalled untill this usb key detached from VM. + +As I researched, this usb key uses interrupt transfers when application trying to read certificate from it. Problem is that some certificate data abandoned by "usbredir_stop_interrupt_receiving" and "usbredir_stop_ep". The two functions use "usbredir_free_bufpq" to clear the buffered usb packets, even the certificate remain in the bufpq. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1708551 b/results/classifier/deepseek-2/output/device/1708551 new file mode 100644 index 000000000..acf6b9421 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1708551 @@ -0,0 +1,18 @@ + +macOS Guest Reading USB 3.0 Bus as USB 2.0 + +Description: +I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes. + +Parameters: +QEMU release version: 2.10.0-rc0 +Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)] +Command Line: https://pastebin.com/pBSYbrW1 +Host: Arch Linux +Guest: macOS v10.12.6 +Guest System Info: https://pastebin.com/U1Tihxei + +Notes: +1. Observed sometime after late-May-early-June of this year. + +2. Due to [a defect in qemu v2.8 which affected GTK users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent change to macOS' booting process conflicting with qemu v2.9](https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as -rc1 fails to load OVMF right now). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1713 b/results/classifier/deepseek-2/output/device/1713 new file mode 100644 index 000000000..67c25a0e9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1713 @@ -0,0 +1,41 @@ + +hw/input/hid.c - Add Support for More Than Five Mouse Buttons in QEMU for evdev? +Additional information: +Sure enough, there appear to only be five buttons defined. + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/input/hid.c#L113 + +```c +[INPUT_BUTTON_LEFT] = 0x01, +[INPUT_BUTTON_RIGHT] = 0x02, +[INPUT_BUTTON_MIDDLE] = 0x04, +[INPUT_BUTTON_SIDE] = 0x08, +[INPUT_BUTTON_EXTRA] = 0x10, +``` + + +At this point, the existing naming schema cannot be continued... might I suggest: + +```c +[INPUT_BUTTON_SIX] = 0x??, +[INPUT_BUTTON_SEVEN] = 0x??, +[INPUT_BUTTON_EIGHT] = 0x??, +[INPUT_BUTTON_NINE] = 0x??, +[INPUT_BUTTON_TEN] = 0x??, +[INPUT_BUTTON_ELEVEN] = 0x??, +[INPUT_BUTTON_TWELVE] = 0x??, +``` +Although, I'm not sure if 12 buttons is future-proofed enough. + +I should also note that I found this post which states that there's no more space left in PS2 emulation, so I don't know if that would cause a conflict. +"ps/2 emulation looks like there are no unused bits for more buttons. Possibly we have to extend the usb mouse emulation for that." +https://listman.redhat.com/archives/vfio-users/2016-January/001596.html + +Unfortunately, I have never written a patch. I'm not even sure how I would apply a patch in Unraid, other than overwriting the bin file. So if this is ever fixed, I would simply hope that one day a new version of QEMU would get up-streamed into a new version of Unraid. + +So, here I am humbly asking for support. I don't know if it's as simple as just adding new definitions... and I have no idea what hex value to assign them. + +*edit* I also failed to get a temporary workaround to work by remapping the mouse buttons in the host VM using xmodmap using this command: + +`xmodmap -e "pointer = 1 12 3 4 5 6 7 8 9 10 11 2" &` +I tried saving `pointer = 1 12 3 4 5 6 7 8 9 10 11 2` in the host VM's root folder in .Xmodmap, but it did not propogate to guest VMs. The buttons were still their original mapping and running the xmod command had no effect. diff --git a/results/classifier/deepseek-2/output/device/1714538 b/results/classifier/deepseek-2/output/device/1714538 new file mode 100644 index 000000000..ae24fdf69 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1714538 @@ -0,0 +1,4 @@ + +Support for Raspberry Pi 3 Model B + +The raspberry pi 3 B uses a 64-bit instruction set. It would be useful if qemu could emulate the boardn \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1715296 b/results/classifier/deepseek-2/output/device/1715296 new file mode 100644 index 000000000..82deb6625 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1715296 @@ -0,0 +1,17 @@ + +qemu: invalid serial port configuration + +The tty_serial_init() function sets the port c_oflags as follows: +tty.c_oflag |= OPOST not clearing ONLCR, ONLRET and others. +The result is that the postprocess output is enabled and host translates 0xa (LF) to 0xd 0xa (CR LF) which breaks the binary transmissions on serial port even if you set the port to raw mode (no matters if on host and/or guest). +The issue has been reported 11 years ago on qemu-devel mailing list: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +There was also a FreeBSD patch including the fix: +https://lists.freebsd.org/pipermail/freebsd-ports/2006-October/036390.html + +I think the correct port configuration is: +tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL); +tty.c_oflag &= ~OPOST; + +In such case the host will perform no output processing and will pass the data as is. +And the guest will be able to configure input/output processing exactly as it wants. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1716132 b/results/classifier/deepseek-2/output/device/1716132 new file mode 100644 index 000000000..f38fb9088 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1716132 @@ -0,0 +1,21 @@ + +Win 10 bitlocker won't initialise pass-through TPM + +All stock Ubuntu Zesty, Win10Pro KVM guest configured with OVMF and Q35. My host has an ASRock Z97 Extreme 6 board with a TPM header which is populated with v1.2 complaint device. + +Testing in my host the TPM device is function, I can tpm_takeownership and tpm_clear successfully and similar testing by passing the device through to a linux guest also succeeds. + +However using Bitlocker in Windows 10 Pro release 1703 Windows advises it cannot "Prepare" the device which I take to mean it cannot take ownership of it. I believe this to be related to Windows inability to view the TCG Event Log which is evidenced in the below 2 screencaps, however I'm no expert. + +https://s26.postimg.org/vter35eh5/Screenshot_20170907_114644.png +https://s26.postimg.org/klo854qyx/Screenshot_20170909_143841.png + +I've also tested the scenario with qemu 2.10 which provided the exact same results. The only difference in the test setup is that I had to make the guest boot with SeaBios instead of OVMF. (Windows wouldn't boot with OVMF with the boot manager giving me an error pointing to a BCD issue. Researching this it seemed related to an old ACPI problem, I believe this unrelated to my TPM issue so will do more research and raise a separate bug for this if needed.) + +Happy to provide further configurations and build logs as necessary so please advise me what is needed. + +Lastly for background reading. I've been trying to get TPM passthrough working with Windows for a long time now and have hit several different issues which I believe have been addressed by both code maturity in Qemu but also in Windows releases. An earlier bug report can be found here (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1615722) which concludes advising me to raise this new/separate issue. + +Thanks in advance, + +Kelvin \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1718 b/results/classifier/deepseek-2/output/device/1718 new file mode 100644 index 000000000..e010299ac --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1718 @@ -0,0 +1,48 @@ + +Strange throttle-group test results +Description of problem: +I have a question about throttle-group test results. + +I did a test to limit IO by applying THROTTLE-GROUP and the expected result is not what I expected + +The setup environment looks like this throttle-group to x-iops-total=500, x-bps-total=524288000 and throttling vdb, benchmarked with fio command + +``` +# mount -t xfs /dev/vdb1 /mnt/disk + +# fio --direct=1 --bs=1M --iodepth=128 --rw=read --size=1G --numjobs=1 --runtime=600 --time_based --name=/mnt/disk/fio-file --ioengine=libaio --output=/mnt/disk/read-1M +``` + +When I test with a --bs value of 1M, I get 500Mib throughput. + + + +When I test with a --bs value of 2m, I don't get 500Mibs but 332Mibs throughput. +``` +fio --direct=1 --bs=2M --iodepth=128 --rw=read --size=1G --numjobs=1 --runtime=600 --time_based --name=/mnt/disk/fio-file --ioengine=libaio --output=/mnt/disk/read-2M +``` + + + +If I set the qemu x-iops-total value to 1500 and the fio --bs value to 2M test again, I get 500Mib throughput. + + + + +To summarize, here is the Test result. + +| fio bs | qemu x-iops-total | qemu x-bps-total | Result iops |Result throughput +| ------ | ------ |------ |------ |------ | +| 2M | 1500 | 524288000 | 250 | 500 | +| **2M** |**500** | **524288000** | **166** | **332** | +| 1M | 1500 | 524288000 | 500 | 500 | +| 1M | 500. | 524288000 | 500 | 500 | + + +When the --bs value is 2M and the x-iops-total value is 500, the throughput should be 500, but it is not, so I don't know what the problem is. + +If there is anything I missed, please let me know. +Steps to reproduce: +1. Apply throttle-group to vdb and start the VM +2. mount vdb1 +3. test fio diff --git a/results/classifier/deepseek-2/output/device/1718118 b/results/classifier/deepseek-2/output/device/1718118 new file mode 100644 index 000000000..2ef3107b7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1718118 @@ -0,0 +1,26 @@ + +qemu crashes with hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) + +Qemu crashes with error "hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev)" when memory hotplug and hotunplug was done continuously. + +Steps to re-produce: +1. git clone (today's i.e 19th Sept) +2. Bring up ppc64le guest with memory hotplug capabilities ( I used libvirt xml to do this). +3. And do continuous memory hotplug and unplug using the following memory xml (mem_hp_8g.xml) +<memory model='dimm'> +<target> +<size unit='KiB'>8388608</size> +<node>1</node> +</target> +</memory> +4. Run the following +for i in `seq 1 100`; do virsh attach-device nrs mem_hp_8g.xml --live; virsh detach-device nrs mem_hp_8g.xml --live; done +5. Guest will crash +6. Following is from qemu log + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-ppc64 -name guest=nrs,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-nrs/master-key.aes -machine pseries-2.10,accel=kvm,usb=off,dump-guest-core=off -m size=8388608k,slots=256,maxmem=419430400k -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -numa node,nodeid=1,cpus=2-3,mem=4096 -uuid d7987973-2467-43ff-b8d2-acefc6ac59e5 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-19-nrs/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/nasastry/pegas-1.0-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:89:8a:8b,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -s -msg timestamp=on +2017-09-19 06:59:07.878+0000: Domain id=19 is tainted: custom-argv +2017-09-19T06:59:07.918273Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/5 (label charserial0) +** +ERROR:/home/nasastry/qemu/hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) +2017-09-19 06:59:51.428+0000: shutting down, reason=crashed \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1719689 b/results/classifier/deepseek-2/output/device/1719689 new file mode 100644 index 000000000..7bcc49268 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1719689 @@ -0,0 +1,15 @@ + +[feature request] add flag to treat warnings as errors + +Since booting could potentially take a lot of time and warnings are likely to indicate that something is wrong, it would be useful to have a command line flag which would abort the boot if there are any warnings. + +An example might be network configuration. The following output most likely indicates that there is something the user has to fix before starting and being able to use the guest os. + +Warning: hub port hub0port0 has no peer +Warning: vlan 0 with no nics +Warning: netdev hub0port0 has no peer +Warning: requested NIC (anonymous, model vitrio-net-device) was not created (not supported by this machine?) + +Ideally, there would be an option the user could pass which would cause qemu to print these warnings then exit, rather than boot the kernel. + +Alternatively, or additionally, a dry run option would be helpful for the same purpose: making sure qemu get to the booting the kernel stage with everything in working order so that you do not have to wait for the kernel to boot and then shut down while debugging things like networking (things which can be debugged (at least partially) without booting, or trying to boot, the guest os). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1720 b/results/classifier/deepseek-2/output/device/1720 new file mode 100644 index 000000000..f1c5d2dbc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1720 @@ -0,0 +1,41 @@ + +Problems in mapping memory regions in multiple machines using GPEX pci-host +Description of problem: +Multiple machines use the GPEX pci-host model. This model forsees 3 MMIO regions: +1. ECAM space +2. MMIO space +3. IO space + +In the different machines, aliases to the 3 memory regions are created which are then mapped onto the sysbus. + +For the ARM virt machine for example following calls are happening: + + ecam_alias = g_new0(MemoryRegion, 1); + ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0); + memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam", ecam_reg, 0, size_ecam); + memory_region_add_subregion(get_system_memory(), base_ecam, ecam_alias); + + mmio_alias = g_new0(MemoryRegion, 1); + mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1); + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +We now add a generic PCIe root port (gen_pcie_root_port.c) on the PCIBus exposed by the GPEX device: + + pci_create_simple(PCI_HOST_BRIDGE(dev)->bus, -1, "pcie-root-port"); + +This device contains an MSI-x table which is accessible via BAR 0. + +However, if we try to access this space we always get 0xFFFFFFFF as a return value on reads because the memory regions are not correctly mapped IMO. + +If we again look at the mapping of the MMIO space: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +The alias is created to the MMIO region in the GPEX device, at offset base_mmio. Afterwards the memory region alias is mapped onto the sysbus at offset base_mmio. To me it seems that the offset is incorrect in creating the alias and should be 0 instead: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, 0, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +With this change the above scenario (accessing the MSI-x table of the generic PCIe root port) is working. I'm not sure if this is the correct fix for this problem and how to cope with e.g. high MMIO regions (as are also present in the virt machine). diff --git a/results/classifier/deepseek-2/output/device/1720971 b/results/classifier/deepseek-2/output/device/1720971 new file mode 100644 index 000000000..3d89ec32a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1720971 @@ -0,0 +1,14 @@ + +qemu/hw/block/onenand.c:522: strange if statement ? + +[qemu/hw/block/onenand.c:523]: (warning) Opposite inner 'if' condition leads to a dead code block. + +Source code is + + for (b = 0; b < s->blocks; b ++) { + if (b >= s->blocks) { + s->status |= ONEN_ERR_CMD; + break; + } + +Inner if condition will never be true. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1721187 b/results/classifier/deepseek-2/output/device/1721187 new file mode 100644 index 000000000..19f3dc716 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1721187 @@ -0,0 +1,18 @@ + +install Centos7 or fedora27 on qemu on windows8.1 + +Hello, +I have tried to install CentOs or Fedora27 on my Windows8 using QEMU. I work on notepad with 4GB. +Unfortunatly, my touchpad nor my usb-mouse are not recognise on the graphical installation of CentOs and Fedora installation. So, I cannot install them. +Here are the commands I use for installation : + +qemu-img create -f qcow2 fedora27b2_hd.qcow2 80G + +qemu-system-x86_64 -k fr -hda fedora27b2_hd.qcow2 -cdrom Fedora-Workstation-Live-x86_64-27_Beta-1.5.iso -m 512 -boot d + +I have tried to add the option : -device usb-mouse but, I got the error message that no 'usb-bus' found for the usb-mouse device. + +What is wrong ? QEMU or my installation command ? + +Thank, BRgds, +Laurent \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1721222 b/results/classifier/deepseek-2/output/device/1721222 new file mode 100644 index 000000000..ef0b0775e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1721222 @@ -0,0 +1,16 @@ + +qemu crashes with Assertion `fdctrl->dma' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + + +INFO: running test case: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine powernv,accel=tcg -device isa-fdc +CRITICAL: failed: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine powernv,accel=tcg -device isa-fdc +CRITICAL: log: qemu-system-ppc64: hw/block/fdc.c:2703: isabus_fdc_realize: Assertion `fdctrl->dma' failed. +CRITICAL: exit code: -6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1721224 b/results/classifier/deepseek-2/output/device/1721224 new file mode 100644 index 000000000..78cb184f9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1721224 @@ -0,0 +1,15 @@ + +qemu crashes with Assertion `!bus->dma[0] && !bus->dma[1]' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + +INFO: running test case: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine prep,accel=tcg -device i82374 +CRITICAL: failed: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine prep,accel=tcg -device i82374 +CRITICAL: log: qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion `!bus->dma[0] && !bus->dma[1]' failed. +CRITICAL: exit code: -6 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1722857 b/results/classifier/deepseek-2/output/device/1722857 new file mode 100644 index 000000000..4c4b08a5b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1722857 @@ -0,0 +1,6 @@ + +Missing PCI "programming interface" ID emulation for USB host controllers + +Qemu doesn't currently emulate the correct value of the "register level programming interface" field in the PCI config space of USB host controllers. As a result, some guest operating systems (most notably Windows) fail to load e.g. generic xHCI drivers, and instead ask for a vendor-specific driver, which may not be always available. + +Example: "-device nec-usb-xhci" emulates a Renesas (formerly NEC) uPD720202 xHCI controller. However, in the PCI config space, it shows us as class 0C, subclass 03, prog-if 00 (UHCI) where as the real uPD720202 (and all real xHCI controllers) have prog-if 30 (xHCI). A Windows guest booted with this option will not recognize devices attached to the XHCI controller unless drivers from Renesas are manually installed first, even though recent Windows versions include a generic xHCI driver that works perfectly well with real uPD720202 hardware. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1731 b/results/classifier/deepseek-2/output/device/1731 new file mode 100644 index 000000000..c0453f3d1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1731 @@ -0,0 +1,13 @@ + +i440fx ide cdrom pathological slow on early win10 install screen +Description of problem: +if you choose i440fx virtual hardware (default in proxmox) for windows 10 instead of q35 , from power on to the windows boot logo is 10 times slower. you need to wait more then 1m45s on my hardware until the blinking cursor in the upper left goes away and the blue windows bootlogo appears. that leads to false assumption, that your setup hangs. + +what's causing this slownewss? + +is implementation really that bad? + +i did compare read performance of ide, sata and scsi cdrom in linux vm and cannot observe such a big difference. + +see +https://forum.proxmox.com/threads/win10-installation-pathological-slowness-with-i440fx-ide-cdrom.129351/ diff --git a/results/classifier/deepseek-2/output/device/1731347 b/results/classifier/deepseek-2/output/device/1731347 new file mode 100644 index 000000000..1d3fafd6a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1731347 @@ -0,0 +1,31 @@ + +VFIO Passthrough of SAS2008-based HBA card fails on E3-1225v3 due to failed DMA mapping (-14) + +There is a bug preventing multiple people with my combination of hardware from using PCI passthrough. I am not actually sure whether the bug is in kernel/kvm, vfio or qemu, however, as qemu is the highest-level of these, I am reporting the bug here as you will likely know better where the origin of the bug may be found. + +When attempting to pass through this device to a KVM using VFIO, this results in error -14 (Bad Address): + +# qemu-system-x86_64 -enable-kvm -m 10G -net none -monitor stdio -serial +# none -parallel none -vnc :1 -device vfio-pci,host=1:00.0 -S +QEMU 2.9.1 monitor - type 'help' for more information +(qemu) c +(qemu) qemu-system-x86_64: VFIO_MAP_DMA: -14 +qemu-system-x86_64: vfio_dma_map(0x7f548f0a1fc0, 0xfebd0000, 0x2000, 0x7f54a909d000) = -14 (Bad address) +qemu: hardware error: vfio: DMA mapping failed, unable to continue + +See also: +https://bugzilla.proxmox.com/show_bug.cgi?id=1556 +https://www.redhat.com/archives/vfio-users/2016-May/msg00088.html + +This has occurred on Proxmox (Proxmox and Debian packages, Ubuntu kernel), Ubuntu, +and pure Debian packages and kernel on Proxmox. However, this error +reportedly does NOT occur for: + +- different distributions(!) (Fedora 24, 25) +- different HBA cards (SAS2308, SAS3008) +- different CPU (E3-1220v5) + +I would be thankful for any input and I'll be happy to provide any further info necessary. This is my first time delving this deep into anything close to the kernel. + +Thanks and best regards, +Johannes Falke \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1731588 b/results/classifier/deepseek-2/output/device/1731588 new file mode 100644 index 000000000..0c9cf616d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1731588 @@ -0,0 +1,14 @@ + +qemu-system-arm black screen and keyboard not detected + +Hi guys, + +I try to emulate FreeRTOS with this guide : http://wiki.csie.ncku.edu.tw/embedded/Lab32 +But, the keys on my keyboard are not taken into account. + - Command line : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -semihosting +If I try to add usb flag with : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -usb -device usb-host,hostbus=1,hostaddr=1 -show-curso +I obtain this message "qemu-system-arm: -device usb-host,hostbus=1,hostaddr=1: 'usb-host' is not a valid device model name" + +My second option is try with the latest version of qemu with this command line : "qemu-system-arm -M lm3s6965evb -monitor stdio -kernel build/main.bin -semihosting" but I obtain a black screen. + +Could someone guide me on this problem ? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1733720 b/results/classifier/deepseek-2/output/device/1733720 new file mode 100644 index 000000000..1b9faada6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1733720 @@ -0,0 +1,56 @@ + +raspi2 with multiple CPU's #1 + +Greetings, + +I am running a small program for raspi2 (from http://wiki.osdev.org/ARM_RaspberryPi_Tutorial_C). + +This code writes "Hello World", but the output ir repeated 4 times. + +My thought was that this is emulating a 4 cpu core system. + +However, when I check the MPIDR registed for CPU number, it always returns 1. + +I git cloned github.com/qemu/qemu.git, made & installed on Acer ARM CB5-311 under Crouton/ubuntu. + + +./qemu.sh +1111 + +Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> uname -a +Linux localhost 3.10.18 #1 SMP Mon Nov 13 16:34:10 PST 2017 armv7l armv7l armv7l GNU/Linux + +Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> qemu-system-arm --version +QEMU emulator version 2.10.91 (v2.11.0-rc1-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +===== +static inline uint32_t read_mpdir(void) +{ + uint32_t id; + + asm volatile("mrc p15, 0, %[id], c0, c0, 0 @ read MIDR\n\t" + : [id] "=r" (id)); + return id; +} +====== +void kernel_main(uint32_t r0, uint32_t r1, uint32_t atags) +{ + // Declare as unused + (void) r0; + (void) r1; + (void) atags; + + uint32_t cpu_id; + + cpu_id = read_mpdir() & 0x03; + + uart_putc( "01234"[cpu_id] ); /* output is "1111" */ + + if (cpu_id == 0) { /* code never executes 8^( */ } + +====== qemu.sh +qemu-system-arm -m 256 -M raspi2 -no-reboot -serial stdio -kernel myos.elf + +Thanks much, +-KenD \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1736376 b/results/classifier/deepseek-2/output/device/1736376 new file mode 100644 index 000000000..0e626a2d4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1736376 @@ -0,0 +1,11 @@ + +CVE-2017-7471 repeated? + +In the hw/9pfs/9p-proxy.c file I can see the following which is changed because of CVE-2017-7471 in the hw/9pfs/9p-local.c. I might be wrong but I guess that should be changed as well. + +if(dir_path){ +v9fs_path_sprintf(target,"%s/%s",dir_path->data,name); +} +else{ +v9fs_path_sprintf(target,"%s",name); +} \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1740887 b/results/classifier/deepseek-2/output/device/1740887 new file mode 100644 index 000000000..5a37f744a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1740887 @@ -0,0 +1,17 @@ + +qemu-system-arm & qemu-system-aarch64 for windows crash at start + +In Windows 7 64 bit (both 32 & 64 bit QEMU emulator version 2.11.0 (v2.11.0-11693-g21057c841e-dirty)). + +With arguments: + +qemu-system-arm.exe -M raspi2 + +It crashes and reports: + +ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/qom/object.c:176:type_get_parent: assertion failed: (type->parent_type != NULL) + +Same goes for qemu-system-aarch64.exe or with -M raspi argument. + +Have a nice day, +f. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1743191 b/results/classifier/deepseek-2/output/device/1743191 new file mode 100644 index 000000000..a38739fbd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1743191 @@ -0,0 +1,42 @@ + +Interacting with NetBSD serial console boot blocks no longer works + +The NetBSD boot blocks display a menu allowing the user to make a +selection using the keyboard. For example, when booting a NetBSD +installation CD-ROM, the menu looks like this: + + 1. Install NetBSD + 2. Install NetBSD (no ACPI) + 3. Install NetBSD (no ACPI, no SMP) + 4. Drop to boot prompt + + Choose an option; RETURN for default; SPACE to stop countdown. + Option 1 will be chosen in 30 seconds. + +When booting NetBSD in a recent qemu using an emulated serial console, +making this menu selection no longer works: when you type the selected +number, the keyboard input is ignored, and the 30-second countdown +continues. In older versions of qemu, it works. + +To reproduce the problem, run: + + wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso + qemu-system-x86_64 -nographic -cdrom boot-com.iso + +During the 30-second countdown, press 4 + +Expected behavior: The countdown stops and you get a ">" prompt + +Incorrect behavior: The countdown continues + +There may also be some corruption of the terminal output; for example, +"Option 1 will be chosen in 30 seconds" may be displayed as "Option 1 +will be chosen in p0 seconds". + +Using bisection, I have determined that the problem appeared with qemu +commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was +updated to 1.11 prerelease, and the problem is still there as of +commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac. The host operating +system used for the tests was Debian 9 x86_64. + +Credit for discovering this bug goes to Paul Goyette. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1743337 b/results/classifier/deepseek-2/output/device/1743337 new file mode 100644 index 000000000..afe1e8ab8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1743337 @@ -0,0 +1,5 @@ + +OS/2 Warp 4 HPFS corruption + +How to reproduce: +Install OS/2 Warp 4 onto HPFS-formatted partition. After reboot there will be messages about "missing" files and OS2.INI not found. Chkdsk C: complains about FS corruption. Nothing changes evwn after fixing errors and next reboot. If you install OS/2 onto FAT partition instead, everything will be OK. I also tried booting images with OS/2 pre-installed through VBOX with same results. Is that HPFS driver or QEMU fault? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1744654 b/results/classifier/deepseek-2/output/device/1744654 new file mode 100644 index 000000000..fb19f9b47 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1744654 @@ -0,0 +1,4 @@ + +commit: 4fe6d78 "virtio: postpone the execution of event_notifier_cleanup function" will cause vhost-user device crash + +The new commit: 4fe6d78 break the existing vhost-user devices, such as vhost-user-scsi/blk and vhost-vsocks when exit the host driver, kvm_io_ioeventfd_del will hit the abort(). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1745 b/results/classifier/deepseek-2/output/device/1745 new file mode 100644 index 000000000..83268a713 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1745 @@ -0,0 +1,68 @@ + +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/deepseek-2/output/device/1745354 b/results/classifier/deepseek-2/output/device/1745354 new file mode 100644 index 000000000..0277c7e46 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1745354 @@ -0,0 +1,13 @@ + +CDOS ps/2 mouse problem + +Qemu v2.10.2 (also tested with 2.11.0) +Host OS : CentOS 7 x86_64 (1708) +Guest OS : Concurrent DOS 386 3.0 (with GEM) + +There is my launch command : +/usr/local/bin/qemu-system-i386 -m 4m -cpu 486 -hda /home/my_user/HDD.img -vga std + +When I'm launching the guest, it is not responding after focusing in the viewer. I think this is due to the ps/2 emulation because when I add "-usb -device usb-mouse" in my command I don't have this issue (but in this case, mouse is not supported by CDOS). + +I tested with an older version of Qemu (0.11) which uses the Bochs bios (instead of SeaBios in newer versions), and I don't have this issue either. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1746 b/results/classifier/deepseek-2/output/device/1746 new file mode 100644 index 000000000..f68b5d186 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1746 @@ -0,0 +1,4 @@ + +PIC32 support in QEMU +Additional information: +There is a fork of an older version of QEMU that includes running a PIC32 microcontoller in QEMU hosted [here](https://github.com/sergev/qemu), however, it is very outdated. diff --git a/results/classifier/deepseek-2/output/device/1747056 b/results/classifier/deepseek-2/output/device/1747056 new file mode 100644 index 000000000..55a830b37 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1747056 @@ -0,0 +1,26 @@ + +FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine + +I was installing MS-Dos 6.22 + Windows 3.11 in preparation for running Microsoft Bob, and noticed that when they try to perform a reboot, they just get stuck. The console cursor stays flashing on/off, but the DOS prompt no longer responds to input. + +It is fairly easy to reproduce, even FreeDOS is impacted - download the FreeDOS bootable CDROM image, then + +$ qemu-img create demo.img 100MB + +$ qemu-system-x86_64 -machine isapc -cdrom ~/Downloads/FD12CD.iso -hda demo.img -monitor stdio + +Wait for the installer to startup, and then in the monitor console run + + sendkey ctrl-alt-delete + +It will fail to reboot + +Testing shows this is a regression from QEMU 2.8.0 onwards, and git bisect further narrowed it down to a SEABIOS update + +commit 6e99f5741ff1b408ea76e6caf2bd4f76df4060e9 (HEAD, tag: pull-seabios-20161027-2, tag: pull-seabios-20161027-1, refs/bisect/bad) +Author: Gerd Hoffmann <email address hidden> +Date: Thu Oct 27 16:42:28 2016 +0200 + + seabios: update to 1.10.0 release. + +Note that this seems particular to the "isapc" machine type - with the "pc" machine type, reboot still works \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1747393 b/results/classifier/deepseek-2/output/device/1747393 new file mode 100644 index 000000000..2986c7f23 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1747393 @@ -0,0 +1,4 @@ + +nvme is missing support for NVME_ADM_CMD_ASYNC_EV_REQ + +NVME_ADM_CMD_ASYNC_EV_REQ is required by specification but apparently we will be responded by error when this command is used. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1748434 b/results/classifier/deepseek-2/output/device/1748434 new file mode 100644 index 000000000..b24760c72 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1748434 @@ -0,0 +1,8 @@ + +Possibly wrong GICv3 behavior when secure enabled + +I an tried arm-aarch64 interrupt routing to EL3, by SCR_EL3.FIQ=1. First I am started QEMU with secure=on and GICv3 support. +I programmed secure and non-secure timers and set-up appropriate interrupts.Secure timer to be GRP1_Secure and non-secure timer to be GRP1_NonSecure. ICC_PMR = 0xff. Then I switched CPU to EL1. +With that setup no interrupt was delivered to PE. GIC interface showed that non secure IRQ is pending. ICC_PMR read at EL1 returns 0 (shall return value ((PMR_(el3) << 1) & 0xff) according to GIC specification. +Than I tried to increase interrupt priority mask - so I set ICC_PMR = 0x7f (at EL3). Then I read at EL1 ICC_PMR=0xfe - (is shall be 0). With this setup IRQ of secure timer was taken at EL3, non secure timer didn't rise IRQ (as it is masked by PMR). +I dig to qemu code and see wrong condition in file arm_gicv3_cpuif.c in function icc_pmr_read(). This behavior is opposite of ARM specification. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1749223 b/results/classifier/deepseek-2/output/device/1749223 new file mode 100644 index 000000000..d852bc28a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1749223 @@ -0,0 +1,17 @@ + +mouse offset or invisible wall 2.11.0-3 + +(There was another post, I'm not sure if it is related though. Also not sure if it's Arch related, I wouldn't be surprised as I normally use Gentoo and have less problems with Gentoo.) + + +qemu-system-x86_64 -enable-kvm -M q35 -cpu host -m 8192 -vga vmware -smp 4,sockets=1,cores=4,threads=1 -drive file=/path/to/my.img,if=virtio -soundhw ac97 -usb -monitor unix:/tmp/qemu-mon,server,nowait -usb --usbdevice host:0000:ffff -device vfio-pci,host=00:00.0 -alt-grab & + + + +When I grab the mouse in/out of the VM I tend to get an "invisible wall" half of the time. +I can push past if I fling the mouse through it but not if I slowly keep moving down. + +The direction always seems to be down when I hit a wall (so a Y offset? maybe?) +This has been happening since at least version 2.10. + +Not sure if "-alt-grab" has anything to do with it, that'd be my first guess. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1753 b/results/classifier/deepseek-2/output/device/1753 new file mode 100644 index 000000000..b1032dff9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1753 @@ -0,0 +1,4 @@ + +Does the qemu have luks2 support? +Description of problem: +Does the qemu have luks2 support? diff --git a/results/classifier/deepseek-2/output/device/1753186 b/results/classifier/deepseek-2/output/device/1753186 new file mode 100644 index 000000000..21c60b05b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1753186 @@ -0,0 +1,17 @@ + +qemu-nbd: always first snapshot loaded from VDI images with snapshots + +When mounting a virtual box disk image of a VM with snapshots, always the state of the first snapshot is shown. + +How to reproduce: +1. Create a new VirtualBox VM or use an existing one, while choosing VDI as the disk image format. +2. Create a snapshot of the VM. +3. Modify the file system from within the VM enough that differences to the snapshotted version are apparent. +4. Create another snapshot. +5. Shut down the VM. +6. Mount the partition from the disk image with `qemu-nbd -c /dev/nbd0 /path/to/disk.vdi; mount /dev/nbd0pX /mnt` + +Expected result: The mounted disk image shall represent the latest state of the VM +Actual result: The mounted disk image represents the VM state at the first snapshot + +version information: qemu-nbd-2.11.1(openSUSE Tumbleweed) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1753309 b/results/classifier/deepseek-2/output/device/1753309 new file mode 100644 index 000000000..fefb82a60 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1753309 @@ -0,0 +1,57 @@ + +Ethernet interrupt vectors for sabrelite machine are defined backwards + +The sabrelite machine model used by qemu-system-arm is based on the Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet controller which is supported in QEMU using the imx_fec.c module (actually called imx.enet for this model.) + +The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for the imx.enet device like this: + +#define FSL_IMX6_ENET_MAC_1588_IRQ 118 +#define FSL_IMX6_ENET_MAC_IRQ 119 + +However, this is backwards. The reference manual for the i.MX6D/Q devices can be found here: + +https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf + +On page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary, it shows the following: + +150 ENET +MAC 0 IRQ, Logical OR of: +MAC 0 Periodic Timer Overflow +MAC 0 Time Stamp Available +MAC 0 Time Stamp Available +MAC 0 Time Stamp Available +MAC 0 Payload Receive Error +MAC 0 Transmit FIFO Underrun +MAC 0 Collision Retry Limit +MAC 0 Late Collision +MAC 0 Ethernet Bus Error +MAC 0 MII Data Transfer Done +MAC 0 Receive Buffer Done +MAC 0 Receive Frame Done +MAC 0 Transmit Buffer Done +MAC 0 Transmit Frame Done +MAC 0 Graceful Stop +MAC 0 Babbling Transmit Error +MAC 0 Babbling Receive Error +MAC 0 Wakeup Request [synchronous] + +151 ENET +MAC 0 1588 Timer interrupt [synchronous] request + +Note: +150 - 32 == 118 +151 - 32 == 119 + +In other words, the vector definitions in the fsl-imx6.h file are reversed. The correct definition is: + +#define FSL_IMX6_ENET_MAC_IRQ 118 +#define FSL_IMX6_ENET_MAC_1588_IRQ 119 + +I tested the sabrelite simulation using VxWorks 7 (which supports the SabreLite board) and found that while I was able to send and receive packet data via the simulated ethernet interface, the VxWorks i.MX6 ethernet driver failed to receive any interrupts. When I corrected the interrupt vector definitions as shown above and recompiled QEMU, everything worked as expected. I was able to exchange ICMP packets with the simulated target and telnet to/from the VxWorks instance running in the virtual machine. I used the tap interface for this. + +As a workaround I was also able to make the ethernet work by modifying the VxWorks imx6q-sabrelite.dts file to change the ethernet interrupt property from 150 to 151. + +This problem was observed with the following environment: + +Host: FreeBSD/amd64 11.1-RELEASE +QEMU version: 2.11.0 and 2.11.1 built from source code \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1753314 b/results/classifier/deepseek-2/output/device/1753314 new file mode 100644 index 000000000..e596ef8ce --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1753314 @@ -0,0 +1,14 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1754 b/results/classifier/deepseek-2/output/device/1754 new file mode 100644 index 000000000..4e6bf0e17 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1754 @@ -0,0 +1,17 @@ + +QEMU wrongly requires SD card sizes to be a power of two +Description of problem: +QEMU arbitrarily requires SD card sizes to be a power of 2. However, this behavior does not match the real world, and I am unable to pass a *physical* SD card into the guest operating system. +``` +$ sudo qemu-system-aarch64 -M raspi2b -drive file=/dev/mmcblk0,if=sd,format=raw +qemu-system-aarch64: Invalid SD card size: 29.7 GiB +SD card size has to be a power of 2, e.g. 32 GiB. +You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +(note that this will lose data if you make the image smaller than it currently is). +``` +Steps to reproduce: +1. Insert a physical SD card into your host system and make a note of its device name. It will be something like `/dev/mmcblk0` +2. Attempt to start a guest OS with the SD card attached. See the command above. +3. You will get an error saying that the card size is not a power of two. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1756728 b/results/classifier/deepseek-2/output/device/1756728 new file mode 100644 index 000000000..c32f374d5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1756728 @@ -0,0 +1,17 @@ + +virtio-scsi virtio-scsi-single and virtio-blk on raw image, games are not starting + +Using virtio-scsi / vitro-scsi-sing and vitro-blk on a ZFS/raw image, most Assassin's Creed (Origin especially) games are not starting (uPlay), it seems related to some check or commands applications are doing on the disk drive that fails to respond. + +Workaround has been found by creating a VHD volume, mounting it and installing games on it. + +On a side note, application like HDDScan, CrystalDiskInfo returns nothing regarding disk drives. + +Guest: +Windows 10 (build 1709) + +Host: +$ kvm --version +QEMU emulator version 2.9.1 pve-qemu-kvm_2.9.1-9 +$ uname -a +Linux xxxx 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1759 b/results/classifier/deepseek-2/output/device/1759 new file mode 100644 index 000000000..a511548e7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1759 @@ -0,0 +1,11 @@ + +qemu-system-i386 error during install windows 95/98 +Description of problem: +Installation of the Windows starts but when Windows 95 is supposed to copy files it failes like:  +Installation of Windows 98 failes like:  +Steps to reproduce: +1. get boot floppy & install cd for windows 95 +2. create hard drive C image +3. try to install Windows 95 +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1759338 b/results/classifier/deepseek-2/output/device/1759338 new file mode 100644 index 000000000..1c5fccc87 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1759338 @@ -0,0 +1,44 @@ + +qemu-system-sparc w/ SS-20 ROM does not add processors + +When booting a SPARCstation-20 with the original ROM, qemu does not set the number of processors in a way that this ROM can understand it, and the ROM always reports only 1 processor installed: + + + ~/qemu /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu "TI SuperSparc 60" -smp 2 -nographic + +Power-ON Reset + + + + + SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95) + + +CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache + +CPU_#1 ******* NOT installed ******* +CPU_#2 ******* NOT installed ******* +CPU_#3 ******* NOT installed ******* + + <<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = 00000008) + + +... + +Cpu #0 TI,TMS390Z50 +Cpu #1 Nothing there +Cpu #2 Nothing there +Cpu #3 Nothing there + +... + +SPARCstation 20 (1 X 390Z50), No Keyboard +ROM Rev. 2.25, 128 MB memory installed, Serial #1193046. +Ethernet address 52:54:0:12:34:56, Host ID: 72123456. + + + + +(It is necessary use SS-20 since it is the only sun4m model that supports 512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) + +When booting with OpenBIOS I can't seem to boot any version of Solaris though I had heard this did work. Solaris 8 and 9 do work nicely with this ROM, but I am opening this to see if it is possible to fix this to allow the original OBP ROM to see multiple processors. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1759492 b/results/classifier/deepseek-2/output/device/1759492 new file mode 100644 index 000000000..f5c0e7348 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1759492 @@ -0,0 +1,15 @@ + +suspend/resume is not supported for vm with tpm device + +I have used libvirt with qemu to create a vm with tpm device, when I suspend the vm and resume it, libvirt will +raise error: +libvirtError: internal error: process exited while connecting to monitor: Enter char_pty_open +I find some materials: +https://wiki.qemu.org/Features/TPM +https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg05355.html +They present qemu haven't supported tpm suspend/resume, Does someone have any advice on how to resolve the problem? + +qemu version: 2.10.2 +vm image version: centos 7.2 + +Thanks \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1759522 b/results/classifier/deepseek-2/output/device/1759522 new file mode 100644 index 000000000..f148216fb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1759522 @@ -0,0 +1,57 @@ + +windows qemu-img create vpc/vhdx error + +On windows, using qemu-img (version 2.11.90) to create vpc/vhdx virtual disk tends to fail. Here's the way to reproduce: + +1. Install qemu-w64-setup-20180321.exe + +2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create a vhdx: + Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size` is incorrect): + image: disk.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 1.4M + cluster_size: 8388608 + +4. On Windows 10 (V1709), double click disk.vhdx gives an error: + Make sure the file is in an NTFS volume and isn't in a compressed folder or volume. + + Using Disk Management -> Action -> Attach VHD gives an error: + The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and uneccrypted and must not be sparse. + +Comparison with Windows 10 created VHDX: + +1. Using Disk Management -> Action -> Create VHD: + File name: win.vhdx + Virtual hard disk size: 512MB + Virtual hard disk format: VHDX + Virtual hard disk type: Fixed size + +2. Detach VHDX + +3. Execute `qemu-img info win.vhdx` gives the result: + image: win.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 516M + cluster_size: 33554432 + +Comparison with qemu-img under Ubuntu: + +1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2004-2008 Fabrice Bellard + +2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M + Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. qemu-img info lin.vhdx + image: lin.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 520M + cluster_size: 8388608 + +4. Load lin.vhdx under Windows 10 is ok + +The same thing happens on `vpc` format with or without `oformat=fixed`, it seems that windows version of qemu-img has some incorrect operation? My guess is that windows version of qemu-img doesn't handle the description field of vpc/vhdx, which leads to an incorrect `disk size` field. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/176 b/results/classifier/deepseek-2/output/device/176 new file mode 100644 index 000000000..0994c005a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/176 @@ -0,0 +1,2 @@ + +virtual machine cpu soft lockup when qemu attach disk diff --git a/results/classifier/deepseek-2/output/device/1760176 b/results/classifier/deepseek-2/output/device/1760176 new file mode 100644 index 000000000..2655675a9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1760176 @@ -0,0 +1,6 @@ + +optical drive doesn't open in Lubuntu 18.04 on '12 MacPro + +Running an install to HD of Lubuntu 18.04 and after running update/upgrade this morning now the optical drive door doesn't respond to keyboard "eject" key on a Mac keyboard for '12 MacPro . . . . I tried to use "xfburn" to get the door to open, nothing seems to get it to work that I know of. Yesterday there was no issue . . . . Tried to run "apt -f install" and it showed some old kernels to "autoremove" . . . which I did; didn't try to reboot into old kernel to test, perhaps now old kernel is gone? + +F \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1760262 b/results/classifier/deepseek-2/output/device/1760262 new file mode 100644 index 000000000..5a5bd43cc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1760262 @@ -0,0 +1,32 @@ + +cmsdk-apb-uart doesn't appear to clear interrupt flags + +I have been writing a small operating system and using QEMU emulating the mps2-an385 board for some of my testing. + +During development of the uart driver I observed some odd behaviour with the TX interrupt -- writing a '1' to bit 0 of the INTCLEAR register doesn't clear the TX interrupt flag, and the interrupt fires continuously. + +It's possible that I have an error somewhere in my code, but after inspecting the QEMU source it does appear to be a QEMU bug. I applied the following patch and it solved my issue: + +From 9875839c144fa60a3772f16ae44d32685f9328aa Mon Sep 17 00:00:00 2001 +From: Patrick Oppenlander <email address hidden> +Date: Sat, 31 Mar 2018 15:10:28 +1100 +Subject: [PATCH] hw/char/cmsdk-apb-uart: fix clearing of interrupt flags + +--- + hw/char/cmsdk-apb-uart.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c +index 1ad1e14295..64991bd9d7 100644 +--- a/hw/char/cmsdk-apb-uart.c ++++ b/hw/char/cmsdk-apb-uart.c +@@ -274,6 +274,7 @@ static void uart_write(void *opaque, hwaddr offset, uint64_t value, + * is then reflected into the intstatus value by the update function). + */ + s->state &= ~(value & (R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); ++ s->intstatus &= ~(value & ~(R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); + cmsdk_apb_uart_update(s); + break; + case A_BAUDDIV: +-- +2.16.2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1761 b/results/classifier/deepseek-2/output/device/1761 new file mode 100644 index 000000000..b83a9a617 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1761 @@ -0,0 +1,2 @@ + +vexpress-a9 board maps both RAM and flash at address 0 diff --git a/results/classifier/deepseek-2/output/device/1761798 b/results/classifier/deepseek-2/output/device/1761798 new file mode 100644 index 000000000..a55aad840 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1761798 @@ -0,0 +1,28 @@ + +live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8" + +Seen here: + +http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-00000002.txt.gz + +2018-04-05T21:48:38.205752Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on: char device redirected to /dev/pts/0 (label charserial0) +warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +2018-04-05T21:48:43.153268Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8 +2018-04-05T21:48:43.153288Z qemu-system-x86_64: Failed to load virtio-blk:virtio +2018-04-05T21:48:43.153292Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +2018-04-05T21:48:43.153347Z qemu-system-x86_64: load of migration failed: Operation not permitted +2018-04-05 21:48:43.198+0000: shutting down, reason=crashed + +And in the n-cpu logs on the other host: + +http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/screen-n-cpu.txt.gz#_Apr_05_21_48_43_257541 + +There is a related Red Hat bug: + +https://bugzilla.redhat.com/show_bug.cgi?id=1450524 + +The CI job failures are at present using the Pike UCA: + +ii libvirt-bin 3.6.0-1ubuntu6.2~cloud0 + +ii qemu-system-x86 1:2.10+dfsg-0ubuntu3.5~cloud0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1762707 b/results/classifier/deepseek-2/output/device/1762707 new file mode 100644 index 000000000..1e608b423 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1762707 @@ -0,0 +1,17 @@ + +VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem + +Is there any known conflict between VFIO passthrough device and virtio-balloon? + +The VM has: +1. 4GB system memory +2. one VFIO passthrough device which supports high address memory DMA and uses GFP_HIGHUSER pages. +3. Memory balloon device with 4GB target. + +When setting the memory balloon target to 1GB and 4GB in loop during runtime (I used the command "virsh qemu-monitor-command debian --hmp --cmd balloon 1024"), the VFIO device DMA randomly gets failure. + +More clues: +1. configure 2GB system memory (no highmem) VM, no issue with similar operations +2. setting the memory balloon to higher like 8GB, no issue with similar operations + +I'm also trying to narrow down this issue. It's appreciated for that you guys may share some thoughts. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1764 b/results/classifier/deepseek-2/output/device/1764 new file mode 100644 index 000000000..d3d7a0dfb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1764 @@ -0,0 +1,2 @@ + +lsusb fails with qemu-system-x86_64 command (qemu-system-x86 package) diff --git a/results/classifier/deepseek-2/output/device/1766904 b/results/classifier/deepseek-2/output/device/1766904 new file mode 100644 index 000000000..7def98bec --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1766904 @@ -0,0 +1,17 @@ + +Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg + +After upgrading from qemu 2.10.0+dfsg-2 to 2.12~rc3+dfsg-2 (on debian sid host), centos 7 guest started to show freezes and ata errors in dmesg during hdd workloads with writing many small files and repeated fsyncs. + +Host kernel 4.15.0-3-amd64. +Guest kernel 3.10.0-693.21.1.el7.x86_64 (slightly older guest kernel was tested too with same result). + +Script that reproduces the bug (first run usualy goes smooth, second and later runs result in dmesg errors and freezes): + +http://paste.debian.net/hidden/472fb220/ + +Sample of error messages in guest dmesg: + +http://paste.debian.net/hidden/8219e234/ + +A workaround that I am using right now: I have detached this SATA storage and reattached the same .qcow2 file as SCSI - this has fixed the issue for me. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1767 b/results/classifier/deepseek-2/output/device/1767 new file mode 100644 index 000000000..cb1bc0fb3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1767 @@ -0,0 +1,4 @@ + +Add iphone emulated device +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1767200 b/results/classifier/deepseek-2/output/device/1767200 new file mode 100644 index 000000000..04a7e8e2d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1767200 @@ -0,0 +1,10 @@ + +Kernel Panic Unable to mount root fs on unknown-block(31,3) + +Using the latest qemu: +qemu-system-arm.exe -kernel C:\Users\a\Downloads\kernel-qemu-4.4.34-jessie -cpu arm1176 -m 256 -machine versatilepb -cdrom C:\Users\a\Downloads\picore-9.0.3.img + +Gives error: +Kernel Panic Unable to mount root fs on unknown-block(31,3) + +I have tried different ARMv6 ARMv7 images/kernels with the same result. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1769067 b/results/classifier/deepseek-2/output/device/1769067 new file mode 100644 index 000000000..8336e398f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1769067 @@ -0,0 +1,4 @@ + +virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit + +When negotiating virtio-net feature bits, the device ignores the absence of the VIRTIO_NET_F_CTRL_VQ bit in driver feature bits and provides three virtqueues, including the control virtqueue, even though the driver is expecting only the receive and transmit virtqueues. Looking into the source code, it appears it always assumes the presence of the control virtqueue, violating thus the VIRTIO version 1.0 specification. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1769189 b/results/classifier/deepseek-2/output/device/1769189 new file mode 100644 index 000000000..4e4dfc5e6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1769189 @@ -0,0 +1,11 @@ + +Issue with qemu 2.12.0 + SATA + +(first reported here: https://bugzilla.tianocore.org/show_bug.cgi?id=949 ) + +I had a Windows 10 VM running perfectly fine with OVMF UEFI, since I upgraded to qemu 2.12, the guests hangs for a couple of minutes, works for a few seconds, and hangs again, etc. By "hang" I mean it doesn't freeze, but it looks like it's waiting on IO or something, I can move the mouse but everything needing disk access is unresponsive. + +What doesn't work: qemu 2.12 with OVMF +What works: using BIOS or downgrading qemu to 2.11.1. + +Platform is arch linux 4.16.7 on skylake, I have attached the vm xml file. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1771042 b/results/classifier/deepseek-2/output/device/1771042 new file mode 100644 index 000000000..f659fd8eb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1771042 @@ -0,0 +1,15 @@ + +dataplane interrupt handler doesn't support msi + +hw/block/dataplane/virtio-blk.c commit 1010cadf62332017648abee0d7a3dc7f2eef9632 + +in the function notify_guest_bh, the function virtio_notify_irqfd is called +to deliver the interrupt corresponding to the vq + +however, without the dataplane, hw/block/virtio_blk_req_complete calls +virtio_notify to deliver the interrupt (immediately). this goes though +a slightly more involved path that calls virtio_pci_notify which includes +a case to handle msi interrupts. + +so, msi interrupts with block devices aren't serviced when using dataplane +batching. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1772 b/results/classifier/deepseek-2/output/device/1772 new file mode 100644 index 000000000..e101ad05e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1772 @@ -0,0 +1,13 @@ + +MPS2 AN521 has the wrong number of MPU region defined +Description of problem: +The AN521 is integrating SSE-200 on the MPS2+ FPGA prototyping board. +The current implementation in qemu behaves as though there are 16MPU regions when it really only has 8, as describes as `MPU_NS` and `MPU_S` core configuration parameters in the SSE-200's [Techincal Reference Manual](https://developer.arm.com/documentation/101104/0200/functional-description/cpu-elements/cortex-m33-configurations?lang=en). +Steps to reproduce: +1. Prepare your Zephyr dev environment +2. fix `boards/arm/mps2_an521/mps2_an521.dts` to set `arm,num-mpu-regions` to the appropriate value of 8. +3. build a Zephyr test such as `west build -p -b mps2_an521 -T tests/kernel/interrupt/arch.interrupt` +4. run `qemu-system-arm -machine mps2-an521 -chardev stdio,id=con,mux=on -serial chardev:con -kernel ./build/zephyr/zephyr.elf` +Additional information: +With matching MPU region number in QEMU and Zephyr's DTS, the application shows the test suite's progress & outcome. +If there's a mismatch, the application will enter a fault and not display the expected traces. diff --git a/results/classifier/deepseek-2/output/device/1772075 b/results/classifier/deepseek-2/output/device/1772075 new file mode 100644 index 000000000..219327ef1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1772075 @@ -0,0 +1,13 @@ + +Segmentation fault on aarch64 vm at powerdown + +OS Arch Linux +x86_64 +qemu version: 2.12 + +cmdline: +qemu-system-aarch64 -nographic -cpu cortex-a57 -m 2048 -M virt,gic_version=3 -machine virtualization=true -bios /usr/share/ovmf/AARCH64/QEMU_EFI.fd -drive file=fat:rw:/opt/simonpiemu/kernels/rpi-3,if=none,format=raw,cache=none,id=hd0 -device virtio-blk-device,drive=hd0 -drive file=/home/morfeo/.simonpi/sd-arch-rpi-3-qemu.img,if=none,format=raw,cache=none,id=hd1 -device virtio-blk-device,drive=hd1 -kernel /opt/simonpiemu/kernels/rpi-3/Image -append "root=/dev/vda2 fstab=no rootfstype=ext4 rw console=ttyAMA0" -initrd /home/morfeo/.simonpi/rpi-3/boot/initramfs-linux.img -device virtio-net-device,mac=52:54:26:11:72:9b,netdev=net0 -netdev tap,id=net0,ifname=rasp-tap0,script=no,downscript=no + +error: + +qemu-system-aarch64: /build/qemu/src/qemu-2.12.0/block.c:3375: bdrv_close_all: Assertion `QTAILQ_EMPTY(&all_bdrv_states)' failed. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1772086 b/results/classifier/deepseek-2/output/device/1772086 new file mode 100644 index 000000000..1ad95bc05 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1772086 @@ -0,0 +1,4 @@ + +malformed serial data being sent from guest + +When sending data through serial from guest each time 0x0A byte is sent 0x0D is sent before it. For example, when sending {0x29, 0x0A} on the other end I receive {0x29, 0x0D, 0x0A}. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1777232 b/results/classifier/deepseek-2/output/device/1777232 new file mode 100644 index 000000000..186fbd8f3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1777232 @@ -0,0 +1,11 @@ + +NVME fails on big writes + +NVME Compliance test 8:3.3.0 tries to write and read back big chunks of pages. Currently, on the latest QEMU operation of size 1024 blocks will fail when device is backed by a file. + +NVME specification has several types of data transfers from guests, one of the is the PRP list (Physical Region Page List). PRP is a list of entries pointing to pages to be written. The list it self resides in a single or multiple pages. + +NVME device maps the PRP list into QEMUSGList which will be me mapped into linux IO vectors. Finally, when the file driver will write the changes, it uses the posix pwritev, which fails if the number of vectors exceeds the maximum. + + +NVME Compliance - https://github.com/nvmecompliance/tnvme/wiki \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1777235 b/results/classifier/deepseek-2/output/device/1777235 new file mode 100644 index 000000000..8d23de14a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1777235 @@ -0,0 +1,4 @@ + +NVME is missing support for Get Log Page command + +"Get Log Page" is a mandatory admin command by the specification (NVMe 1.2, Section 5, Figure 40) currently not implemented by device. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1777315 b/results/classifier/deepseek-2/output/device/1777315 new file mode 100644 index 000000000..a0c325f89 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1777315 @@ -0,0 +1,73 @@ + +IDE short PRDT abort + +Hi, +QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0 + +run the program in qemu-2.12.0: +#define _GNU_SOURCE +#include <endian.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <fcntl.h> +#include <stdio.h> +#include <string.h> +#include <sys/stat.h> +#include <stdint.h> +#include <string.h> + +static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2) +{ + if (a0 == 0xc || a0 == 0xb) { + char buf[128]; + sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2); + return open(buf, O_RDWR, 0); + } else { + char buf[1024]; + char* hash; +strncpy(buf, (char*)a0, sizeof(buf) - 1); + buf[sizeof(buf) - 1] = 0; + while ((hash = strchr(buf, '#'))) { + *hash = '0' + (char)(a1 % 10); + a1 /= 10; + } + return open(buf, a2, 0); + } +} + +uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; +void loop() +{ + long res = 0; +memcpy((void*)0x20000000, "/dev/sg#", 9); + res = syz_open_dev(0x20000000, 0, 2); + if (res != -1) + r[0] = res; + res = syscall(__NR_dup2, r[0], r[0]); + if (res != -1) + r[1] = res; +*(uint8_t*)0x20000ec0 = 0; +*(uint8_t*)0x20000ec1 = 0; +*(uint8_t*)0x20000ec2 = 0; +*(uint8_t*)0x20000ec3 = 0; +*(uint32_t*)0x20000ec8 = 0; +*(uint8_t*)0x20000ed8 = 0; +*(uint8_t*)0x20000ed9 = 0; +*(uint8_t*)0x20000eda = 0; +*(uint8_t*)0x20000edb = 0; +memcpy((void*)0x20000ee0, "\x9c\x4d\xe7\xd5\x0a\x62\x43\xa7\x77\x53\x67\xb3", 12); + syscall(__NR_write, r[1], 0x20000ec0, 0x323); +} + +int main() +{ + syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); + loop(); + return 0; +} +this will crash qemu, output information: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + + +Thanks +owl337 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1777777 b/results/classifier/deepseek-2/output/device/1777777 new file mode 100644 index 000000000..46c891baa --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1777777 @@ -0,0 +1,12 @@ + +arm9 clock pending (SP804) + +Hello all, + +I'm using the versatilepb board and the timer Interrupt Mask Status register (offset 0x14 of the SP804) does not seem to be working properly on the latest qemu-2.12. I tried on the 2.5 (i believe this is the mainstream version that comes with Linux) and it works perfectly. + +What happens is that the pending bit does not seem to be set in some scenarios. In my case, I see the timer value decreasing to 0 and then being reset to the reload value and neither does the interrupt is triggered nor the pending bit is set. + +I believe this is a matter of timing since in the "long" run the system eventually catches up (after a few microseconds). + +Thank you \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1779017 b/results/classifier/deepseek-2/output/device/1779017 new file mode 100644 index 000000000..9fadf1a33 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1779017 @@ -0,0 +1,44 @@ + +qemu-system-arm: crashes raspian kernels with divide-by-zero + +While trying to boot a arm kernel for a raspi2 machine (kernel7-4.9.41-stretch.img in my case, but applies to other versions, too) the kernel crash with a division by zero. The output on the sreial console is: +[ 10.022377] [<8011d344>] (__warn) from [<8011d42c>] (warn_slowpath_null+0x30/0x38) +[ 10.024726] [<8011d42c>] (warn_slowpath_null) from [<804da378>] (uart_get_baud_rate+0xf8/0x160) + +... + +[ 10.094933] Hardware name: BCM2835 +[ 10.101507] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24) +[ 10.105413] [<8010c058>] (show_stack) from [<80455f84>] (dump_stack+0xd4/0x118) +[ 10.140268] [<80455f84>] (dump_stack) from [<8010bed4>] (__div0+0x24/0x28) +[ 10.143065] [<8010bed4>] (__div0) from [<8045498c>] (Ldiv0+0x8/0x14) +[ 10.145553] [<8045498c>] (Ldiv0) from [<804e5538>] (pl011_set_termios+0x9c/0x37c) +[ 10.148017] [<804e5538>] (pl011_set_termios) from [<804da954>] (uart_change_speed+0x40/0xfc) +[ 10.185887] [<804da954>] (uart_change_speed) from [<804ddedc>] (uart_startup.part.3+0xa4/0x13c) +[ 10.222187] [<804ddedc>] (uart_startup.part.3) from [<804ddfcc>] (uart_port_activate+0x58/0x64) +[ 10.226014] [<804ddfcc>] (uart_port_activate) from [<804c93b8>] (tty_port_open+0xa0/0xe0) +[ 10.228398] [<804c93b8>] (tty_port_open) from [<804dce64>] (uart_open+0x40/0x48) +[ 10.264254] [<804dce64>] (uart_open) from [<804c1d70>] (tty_open+0xc0/0x678) +[ 10.266697] [<804c1d70>] (tty_open) from [<802753f0>] (chrdev_open+0xe0/0x1a0) +[ 10.269049] [<802753f0>] (chrdev_open) from [<8026d964>] (do_dentry_open+0x1f4/0x314) +[ 10.271620] [<8026d964>] (do_dentry_open) from [<8026ec00>] (vfs_open+0x60/0x8c) +[ 10.275245] [<8026ec00>] (vfs_open) from [<8027f39c>] (path_openat+0x2bc/0x1040) +[ 10.312827] [<8027f39c>] (path_openat) from [<80281040>] (do_filp_open+0x70/0xd4) +[ 10.317860] [<80281040>] (do_filp_open) from [<8026efd8>] (do_sys_open+0x120/0x1d0) +[ 10.320370] [<8026efd8>] (do_sys_open) from [<8026f0b4>] (SyS_open+0x2c/0x30) +[ 10.357033] [<8026f0b4>] (SyS_open) from [<801080c0>] (ret_fast_syscall+0x0/0x1c) + +Tracking that down in the linux kernel source, it looks like somehow uart_get_baud_rate() returns 0. + +The same kernel could be booted without problem with qemu version 2.11. +Trying to bisecting the issue revealed commit @d9f8bbd8eb4e95db97cf02bd03af86a3d606f4f1 as the culprit. + +Commandline to run was: +qemu-system-arm -M raspi2 \ + -kernel "$KERNEL" \ + -m 1024 \ + -d guest_errors,unimp \ + -dtb bcm2709-rpi-2-b.dtb \ + -drive file="$IMG,if=sd,format=raw" + +Distribution is SuSE tumbleweed (x86_64, kernel 4.17.2), but same problem also happens with a freshly compiled qemu from git repository. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1779120 b/results/classifier/deepseek-2/output/device/1779120 new file mode 100644 index 000000000..c4c34abb0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1779120 @@ -0,0 +1,19 @@ + +disk missing in the guest contingently when hotplug several virtio scsi disks consecutively + +Hi, I found a bug that disk missing (not all disks missing ) in the guest contingently when hotplug several virtio scsi disks consecutively. After rebooting the guest,the missing disks appear again. + +The guest is centos7.3 running on a centos7.3 host and the scsi controllers are configed with iothread. The scsi controller xml is below: + + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='26'/> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + + +If the scsi controllers are configed without iothread, disks are all can be seen in the guest when hotplug several virtio scsi disks consecutively. + +I think the biggest difference between them is that scsi controllers with iothread call virtio_notify_irqfd to notify guest and scsi controllers without + +iothread call virtio_notify instead. What make it difference? Will interrupts are lost when call virtio_notify_irqfd due to race condition for some unknow reasons? Maybe guys more familiar with scsi dataplane can help. Thanks for your reply! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1782107 b/results/classifier/deepseek-2/output/device/1782107 new file mode 100644 index 000000000..8969181b5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1782107 @@ -0,0 +1,12 @@ + +Random errors when emulating armv7 and using dh + +Howdy, +I'm encountering random errors when using qemu to cross-package my project using dh. In previous iterations of my project it would only fail once every two attempts. Now it fails every time. + +Example error included. + + + +If you'd like to try and replicate this error, a version of my project is publicly available with simple instructions on how to package it (using qemu) here: +https://github.com/Nadav-Ruskin/configsite \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1785972 b/results/classifier/deepseek-2/output/device/1785972 new file mode 100644 index 000000000..62e32a0bc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1785972 @@ -0,0 +1,49 @@ + +v3.0.0-rc4: VM fails to start after vcpuhotunplug, managedsave sequence + +VM fails to start after vcpu hot un-plug, managedsave sequence + +Host info: +Kernel: 4.18.0-rc8-00002-g1236568ee3cb + +qemu: commit 6ad90805383e6d04b3ff49681b8519a48c9f4410 (HEAD -> master, tag: v3.0.0-rc4) +QEMU emulator version 2.12.94 (v3.0.0-rc4-dirty) + +libvirt: commit 087de2f5a3dffb27d2eeb0c50a86d5d6984e5a5e (HEAD -> master) +libvirtd (libvirt) 4.6.0 + +Guest Kernel: 4.18.0-rc8-00002-g1236568ee3cb + + +Steps to reproduce: +1. Start a guest(VM) with 2 current , 4 max vcpus +virsh start vm1 +Domain vm1 started + +2. Hotplug 2 vcpus +virsh setvcpus vm1 4 --live + +3. Hot unplug 2 vcpus +virsh setvcpus vm1 2 --live + +4. Managedsave the VM +virsh managedsave vm1 + +Domain vm1 state saved by libvirt + +5. Start the VM ---Fails to start +virsh start vm1 + +error: Failed to start domain avocado-vt-vm1 +error: internal error: qemu unexpectedly closed the monitor: 2018-08-08T06:27:53.853818Z qemu: Unknown savevm section or instance 'spapr_cpu' 2 +2018-08-08T06:27:53.854949Z qemu: load of migration failed: Invalid argument + + + +Testcase: +avocado run libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug --vt-type libvirt --vt-extra-params emulator_path=/usr/share/avocado-plugins-vt/bin/qemu create_vm_libvirt=yes kill_vm_libvirt=yes env_cleanup=yes smp=8 backup_image_before_testing=no libvirt_controller=virtio-scsi scsi_hba=virtio-scsi-pci drive_format=scsi-hd use_os_variant=no restore_image_after_testing=no vga=none display=nographic kernel=/home/kvmci/linux/vmlinux kernel_args='root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' take_regular_screendumps=no --vt-guest-os JeOS.27.ppc64le +JOB ID : 1f869477ad87e7d7e7e7777f631ae08965f41a74 +JOB LOG : /root/avocado/job-results/job-2018-08-08T02.42-1f86947/job.log + (1/1) type_specific.io-github-autotest-libvirt.libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug: ERROR (91.58 s) +RESULTS : PASS 0 | ERROR 1 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 +JOB TIME : 95.89 s \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1786343 b/results/classifier/deepseek-2/output/device/1786343 new file mode 100644 index 000000000..29dffe10b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1786343 @@ -0,0 +1,37 @@ + +QEMU v3.0.0-rc4 configure fails with --enable-mpath on CentOS 7.5 + +QEMU v3.0.0-rc4 configure fails with --enable-mpath on CentOS 7.5. + +After commit b3f1c8c413bc83e4a2cc7a63e4eddf9fe6449052 "qemu-pr-helper: use new +libmultipath API", QEMU started using new libmultipath API, which is not +available on CentOS 7.5. Reverting this commit, configure passes. + +Steps to reproduce (fails on x86_64 and ppc64le architectures): + + $ git clone git://git.qemu.org/qemu.git + $ mkdir -p qemu/build && cd qemu/build + $ ../configure --enable-mpath + ERROR: Multipath requires libmpathpersist devel + + $ rpm -qa | grep device-mapper | sort + device-mapper-1.02.146-4.el7.ppc64le + device-mapper-devel-1.02.146-4.el7.ppc64le + device-mapper-libs-1.02.146-4.el7.ppc64le + device-mapper-multipath-0.4.9-119.el7.ppc64le + device-mapper-multipath-devel-0.4.9-119.el7.ppc64le + device-mapper-multipath-libs-0.4.9-119.el7.ppc64le + +Snippet from config.log: + + funcs: do_compiler do_cc compile_prog main + lines: 92 125 3580 0 + cc -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -Wno-missing-braces -I/usr/include/p11-kit-1 -I/usr/include/libpng15 -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g -ludev -lmultipath -lmpathpersist + config-temp/qemu-conf.c: In function ‘main’: + config-temp/qemu-conf.c:15:5: error: too few arguments to function ‘mpath_lib_init’ + multipath_conf = mpath_lib_init(); + ^ + In file included from config-temp/qemu-conf.c:2:0: + /usr/include/mpath_persist.h:179:12: note: declared here + extern int mpath_lib_init (struct udev *udev); + ^ \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/179 b/results/classifier/deepseek-2/output/device/179 new file mode 100644 index 000000000..27a36a640 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/179 @@ -0,0 +1,2 @@ + +qemu guest crashes on spice client USB redirected device removal diff --git a/results/classifier/deepseek-2/output/device/1790975 b/results/classifier/deepseek-2/output/device/1790975 new file mode 100644 index 000000000..38214d2d7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1790975 @@ -0,0 +1,18 @@ + +Default arm virt machine broken + +This occurs on qemu_v3.0.0 but not on qemu_v2.12.2 (built from qemu_v3.0.0 tag on github) + +Symptom: You'll see something like this in the kernel output: + +[ 1.285210] OF: PCI: host bridge /pcie@10000000 ranges: +[ 1.286246] OF: PCI: IO 0x3eff0000..0x3effffff -> 0x00000000 +[ 1.287061] OF: PCI: MEM 0x10000000..0x3efeffff -> 0x10000000 +[ 1.287820] OF: PCI: MEM 0x8000000000..0xffffffffff -> 0x8000000000 +[ 1.289312] pci-host-generic 4010000000.pcie: can't claim ECAM area [mem 0x10000000-0x1fffffff]: address conflict with /pcie@10000000 [mem 0x10000000-0x3efeffff] +[ 1.290984] pci-host-generic: probe of 4010000000.pcie failed with error -16 + + +Qemu Command Line: qemu-system-arm -machine virt -m 1024M -kernel zImage -serial stdio + +I can post my zImage if anyone has problems reproducing with their own zImage. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1791947 b/results/classifier/deepseek-2/output/device/1791947 new file mode 100644 index 000000000..0623dc004 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1791947 @@ -0,0 +1,15 @@ + +isochronous usb device forwarding with windows 10 and xhci freezes + +When I try to forward isochronous usb devices (webcam, HID-Audio) into the VM the devices work for a few minutes then the device stops working and stays that way until a VM reboot or a windows driver reload. +It does not matter if I use qemu-xhci or nec-xhci. +I can gather more information, if its helpful! + +Windows build: +windows 10 pro 1803 jun 2018 + +Qemu command line: +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-win10/master-key.aes -machine pc-q35-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Skylake-Client-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,ssbd=on,xsaves=on,pdpe1gb=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 38b1258e-fea4-41fe-9e21-07c426c5b2b2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device qemu-xhci,id=usb,bus=pci.3,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 -drive file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/en_windows_10_multiple_editions_version_1803_jun_2018.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:33:11,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -msg timestamp=on + +Cheers, +Florian \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1792523 b/results/classifier/deepseek-2/output/device/1792523 new file mode 100644 index 000000000..dc0d0fd93 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1792523 @@ -0,0 +1,51 @@ + +usb passthrough not resetting on host after vm shutdown if started with -daemonize + +Below is the full Qemu command used to launch the VM. Have been using this same setup since Qemu 2.12, plus a couple of cherry picked patch commits fixing ide-hd and e1000e in Windows guests. Both sets of patches have now been merged to 3.0, so decided to update to 3.0. + +The VM launches and runs fine, but after shutting down, the usb devices that are passed through from the host (keyboard, mouse) do not work until unplugged and plugged in again. Have narrowed this down to the -daemonize -pidfile arguments.. if those lines are removed, usb devices work in the host again right away after VM shutdown. + +CPU: Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz +OS: Linux dev 4.18.6-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 5 11:54:09 UTC 2018 x86_64 GNU/Linux + +Thank you for looking into this! + + +#!/usr/bin/env bash + +echo vfio-pci > /sys/bus/pci/devices/0000:04:00.0/driver_override +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers/vfio-pci/bind +echo > /sys/bus/pci/devices/0000:04:00.0/driver_override + +/usr/bin/qemu-system-x86_64 \ +-name winnt \ +-daemonize \ +-pidfile /run/vms/qemu/winnt.pid \ +-boot menu=on \ +-drive if=pflash,format=raw,readonly,file=/opt/vms/qemu/machines/ovmf_code_patched.fd \ +-drive if=pflash,format=raw,file=/opt/vms/qemu/machines/winnt/ovmf_vars_patched.fd \ +-machine pc-q35-3.0,accel=kvm \ +-nodefaults \ +-cpu host,kvm=off,hv_vendor_id=RedHat,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff \ +-accel kvm \ +-smp 4,sockets=1,cores=4,threads=1 \ +-m 16G \ +-nic bridge,br=br0,mac=52:54:00:12:34:77,model=e1000e \ +-device vfio-pci,host=01:00.0,multifunction=on \ +-device vfio-pci,host=01:00.1 \ +-vga none \ +-display none \ +-monitor none \ +-blockdev raw,node-name=ide-hd.0,cache.direct=on,discard=unmap,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_181265803048 \ +-device ide-hd,drive=ide-hd.0,bus=ide.0,rotation_rate=1 \ +-blockdev raw,node-name=ide-hd.1,cache.direct=on,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-TOSHIBA_HDWE160_X746K8ZTF56D-part1 \ +-device ide-hd,drive=ide-hd.1,bus=ide.1 \ +-device vfio-pci,host=04:00.0 \ +-device qemu-xhci \ +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers_probe \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1793016 b/results/classifier/deepseek-2/output/device/1793016 new file mode 100644 index 000000000..78607e628 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1793016 @@ -0,0 +1,23 @@ + +vmdk to cqow2 invalid VMDK image descriptor + +Greetings, + +CentOS 7.5.1804 +Linux 3.10.0-862.11.6.el7.x86_64 +qemu-img version 3.0.50 (v3.0.0-614-g19b599f) + +When trying to convert a vmdk flat file to qcow2 format, I get the following error message: +qemu-img: Could not open './sk-R12-flat.vmdk': invalid VMDK image descriptor + +The command line used is +root@s11kvm:/home/goinfre> qemu-img convert -f vmdk -O qcow2 ./sk-R12-flat.vmdk ./sk-R12-flat.qcow2 + + +"file sk-R12-flat.vmdk" returns: +sk-R12-flat.vmdk: x86 boot sector; +GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x40, GRUB version 0.97; +partition 1: ID=0x63, active, starthead 1, startsector 63, 16002 sectors; +partition 2: ID=0x83, starthead 0, startsector 16065, 3084480 sectors; +partition 3: ID=0x83, starthead 0, startsector 3100545, 3084480 sectors; +partition 4: ID=0x5, starthead 0, startsector 6185025, 161581770 sectors, code offset 0x48 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1793275 b/results/classifier/deepseek-2/output/device/1793275 new file mode 100644 index 000000000..dcce123f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1793275 @@ -0,0 +1,27 @@ + +Hosts fail to start after update to QEMU 3.0 + +Host OS: Archlinux +Host Architecture: AMD64 +Guest OS: FreeBSD-11.2 (x2) and Archlinux (x1) +Guest Architecture: AMD64 + +I have been using QEMU 2.x without issue for a number of years but since updating to QEMU 3.0 my guests do not complete startup. + +FreeBSD 11.2 guest failure symptom: +The two FreeBSD-11.2 guests output repeated messages of "unexpected cache type 4". This appears to be an internal error message and I've not found any instances of it through Google search. + +Archlinux guest failure symptom: +The single Archlinux guest gets no further than the message "uncompressing initial ramdisk". + +The guests are started by a qemu-kvm invokation. No virtual machine managers are used. The command lines used (from ps awx) to launch the VMs are: + +[neil@optimus ~]$ ps awx |grep qemu + 1492 ? Sl 3:19 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps1.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps1,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_1 -net nic,macaddr=52:54:AD:86:64:00,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.2:23,server,nowait -vnc 192.168.0.1:0 + 1510 ? Sl 0:54 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps2.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps2,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name Archlinux -net nic,macaddr=52:54:AD:86:64:01,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.3:23,server,nowait -vnc 192.168.0.1:1 + 1529 ? Sl 3:07 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps3.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps3,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_2 -net nic,macaddr=52:54:AD:86:64:02,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.4:23,server,nowait -vnc 192.168.0.1:2 + +The VMs were installed to LVM volumes on the host machine (hence the /dev/system/vpsN device names). Networking is over a Linux tap interface connected to a VDE2 virtual network switch. + +Currently working version of QEMU: qemu-headless 2.12.1-1 +Failing version of QEMU: qemu-headless-3.0.0-1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1793635 b/results/classifier/deepseek-2/output/device/1793635 new file mode 100644 index 000000000..4f4782eb3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1793635 @@ -0,0 +1,7 @@ + +Using pflash with u-boot,when CONFIG_SYS_FLASH_USE_BUFFER_WRITE were defined,envirment args won't be able to save correctly + +Generated a u-boot image with qemu_arm_defconfig,did some modification to qemu-arm.h. +Before added "CONFIG_SYS_FLASH_USE_BUFFER_WRITE",call saveenv in u-boot command line can save the envirment but painful slow. + +after added it,seems the action took no time,but the data won't be saved correctly,reset the board to boot again(i'd waited a while to reset the board) ,the u-boot will tell you enviremnt checksum mismatch,using the default. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1794 b/results/classifier/deepseek-2/output/device/1794 new file mode 100644 index 000000000..4e5d2e0fe --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1794 @@ -0,0 +1,28 @@ + +Virtio-GPU doesn't fill Response data for cursor queue +Description of problem: +Implementation of virtio-gpu in Qemu is likely not fill Response header in cursor commands. + +Inside the virtio 1.2 specification, document said: +``` +VIRTIO_GPU_CMD_UPDATE_CURSOR + Update cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA. + Full cursor update. Cursor will be loaded from the specified resource_id and will be moved to pos. The driver must + transfer the cursor into the resource beforehand (using control queue commands) and make sure the commands to fill + the resource are actually processed (using fencing). + +VIRTIO_GPU_CMD_MOVE_CURSOR + Move cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA. + Move cursor to the place specified in pos. The other fields are not used and will be ignored by the device. +``` +The cursor commands do have a response like control commands. + +But in [hw/display/virtio-gpu.c#L1136](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu.c#L1136), QEMU doesn't care anything about response, just fetching command and execute. + +It this a Implementation compromise or I missing something in the specification? +Steps to reproduce: +1. Write any kernel that using virtio-gpu. +2. Run on qemu. +3. No response on cursor command. +Additional information: +Specification: [virtio-v1.2-cs01.html](https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007) diff --git a/results/classifier/deepseek-2/output/device/1794187 b/results/classifier/deepseek-2/output/device/1794187 new file mode 100644 index 000000000..4c0097fe7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1794187 @@ -0,0 +1,15 @@ + +improve error message, when using raspi3 and RAM>4G + +Running `qemu-system-aarch64 image-aarch64.iso --machine raspi3 -m 8G` prints this error message: + +``` +Unexpected error in visit_type_uintN() at /builddir/build/BUILD/qemu-3.0.0/qapi/qapi-visit-core.c:164: +qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t +``` + +The problem is, that you musn't use more than 4 GB RAM for machine raspi3. As it took me some time to figure that out, I'd be glad, if you can print better error message, like you do, when using more than 4 CPU cores with machine raspi3: + +``` +Invalid SMP CPUs 8. The max CPUs supported by machine 'raspi3' is 4 +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1794202 b/results/classifier/deepseek-2/output/device/1794202 new file mode 100644 index 000000000..53e6f8517 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1794202 @@ -0,0 +1,4 @@ + +Trying to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." + +When I try to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." Command ran in the command-line: "C:\Program Files\qemu\qemu-system-ppc" -L pc-bios -boot d -M mac99,via=pmu -m 512 -hda "C:\Users\*****\Downloads\macosx105\MacOSHDD.qcow2" -cdrom "C:\Users\*****\Downloads\macosx105\osx leopard install.iso" -netdev user,id=mynet0 -device sungem,netdev=mynet0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1794950 b/results/classifier/deepseek-2/output/device/1794950 new file mode 100644 index 000000000..86376be38 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1794950 @@ -0,0 +1,84 @@ + +qemu hangs when guest is using linux kernel 4.16+ + +I have been using qemu on daily basis 5+ years in order to do btrfs development and testing and it always worked perfectly, until I upgraded the linux kernel of the guests to 4.16. With 4.16+ kernels, when running all the fstests (previously called xfstests), the qemu process hangs (console unresponsive, can't ping or ssh the guest anymore, etc) and stays in a state Sl+ according to 'ps'. + +This happens on two different physical machines, one running openSUSE tumbleweed (which I don't access at the moment to check kernel version) and another running xubuntu (tried kernels 4.15.0-32-generic and vanilla 4.18.0). Using any kernel from 4.16 to 4.19-rc5 in the guests (they use different debian versions) makes qemu hang running the fstests suite (after about 30 to 40 minutes, either at test generic/299 or test generic/451). + +I tried different qemu versions, 2.11.2, 2.12.1 and 3.0.0, and it happens with all of them (all built from the sources available at https://www.qemu.org/download/#source). + +I built 3.0.0 with debug enabled, using the following parameters for 'configure': + +--prefix=/home/fdmanana/qemu-3.0.0 --enable-tools --enable-linux-aio --enable-kvm --enable-vnc --enable-vnc-png --enable-debug --extra-cflags="-O0 -g3 -fno-omit-frame-pointer" + +And captured a coredump of the qemu process, available at: + +https://www.dropbox.com/s/d1tlsimahykwhla/core_dump_debug.tar.xz?dl=0 + +the stack traces of all threads, for a quick look: + +https://friendpaste.com/zqkz2pD0WgSdeSKITHPDf + +qemu is being invoked with the following script: + +#!/bin/bash -x + +sudo modprobe tun +sudo modprobe kvm +sudo modprobe kvm-intel + +sudo tunctl -t tap5 -u fdmanana +sudo ifconfig tap5 up +sudo brctl addif br0 tap5 + +sudo umount /mnt/tmp5 +sudo mkdir -p /mnt/tmp5 +sudo mount -t tmpfs -o size=14G tmpfs /mnt/tmp5 +for ((i = 2; i <= 7; i++)); do + sudo qemu-img create -f qcow2 /mnt/tmp5/disk$i 13G +done +sudo chown fdmanana /mnt/tmp5/disk* + +qemu-system-x86_64 -m 4G \ + -device virtio-scsi-pci \ + -boot c \ +\ + -drive if=none,file=debian5.qcow2,cache=none,aio=native,cache.direct=on,format=qcow2,id=drive0,discard=on \ + -device scsi-hd,drive=drive0,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk2,cache=writeback,format=qcow2,id=drive1,discard=on \ + -device scsi-hd,drive=drive1,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk3,cache=writeback,format=qcow2,id=drive2,discard=on \ + -device scsi-hd,drive=drive2,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk4,cache=writeback,format=qcow2,id=drive3,discard=on \ + -device scsi-hd,drive=drive3,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk5,cache=writeback,format=qcow2,id=drive4,discard=on \ + -device scsi-hd,drive=drive4,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk6,cache=writeback,format=qcow2,id=drive5,discard=on \ + -device scsi-hd,drive=drive5,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk7,cache=writeback,format=qcow2,id=drive6,discard=on \ + -device scsi-hd,drive=drive6,bus=scsi.0 \ +\ + -drive if=none,file=disk8,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive7,discard=on \ + -device scsi-hd,drive=drive7,bus=scsi.0 \ +\ + -drive if=none,file=disk9,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive8,discard=on \ + -device scsi-hd,drive=drive8,bus=scsi.0 \ +\ + -drive if=none,file=disk10,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive9,discard=on \ + -device scsi-hd,drive=drive9,bus=scsi.0 \ +\ + -net nic,macaddr=52:54:00:12:34:fa -net tap,ifname=tap5,script=no,downscript=no \ + -rtc base=localtime -enable-kvm -machine accel=kvm -smp 4 -cpu host \ + -k pt -serial tcp:127.0.0.1:9997 -display vnc=:5 + + + +Is there anything else I can provided to help debug this? + +Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1795527 b/results/classifier/deepseek-2/output/device/1795527 new file mode 100644 index 000000000..451c5b4b8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1795527 @@ -0,0 +1,68 @@ + +Malformed audio and video output stuttering after upgrade to QEMU 3.0 + +My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened kernel, running a few KVM guests with varying OSes and configurations managed through a Libvirt stack. + +Among these guests I have two Windows 10 VMs with VGA passthrough and PulseAudio-backed virtual audio devices. + +After upgrading to QEMU 3.0.0, both of the Win10 guests started showing corrupted audio output in the form of unnatural reproduction speed and occasional but consistently misplaced audio fragments originating from what seems to be a circular buffer wrapping over itself (misbehaviour detected by starting some games with known OSTs and dialogues: soundtracks sound accelerated and past dialogue lines start replaying middle-sentence until the next line starts playing). + +In addition, the video output of the malfunctioning VMs regularly stutters roughly twice a second for a fraction of a second (sync'ed with the suspected buffer wrapping and especially pronounced during not-pre-rendered cutscenes), toghether with mouse freezes that look like actual input misses more than simple lack of screen refreshes. + + +The issue was succesfully reproduced without the managing stack, directly with the following command line, on the most capable Windows guest: + + QEMU_AUDIO_DRV=pa + QEMU_PA_SERVER=127.0.0.1 + /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \ + -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \ + -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off \ + -drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \ + -m 5120 \ + -realtime mlock=off \ + -smp 3,sockets=1,cores=3,threads=1 \ + -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \ + -display none \ + -no-user-config \ + -nodefaults \ + -rtc base=localtime,driftfix=slew \ + -global kvm-pit.lost_tick_policy=delay \ + -no-hpet \ + -no-shutdown \ + -global PIIX4_PM.disable_s3=1 \ + -global PIIX4_PM.disable_s4=1 \ + -boot strict=on \ + -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \ + -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \ + -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \ + -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \ + -device ahci,id=sata0,bus=pci.0,addr=0x9 \ + -drive file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native \ + -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on \ + -drive file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \ + -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \ + -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \ + -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ + -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \ + -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \ + -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \ + -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ + -msg timestamp=on + + +By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" with "pc-i440fx-2.11" (basically reverting the config changes I needed to do in order to update the domain definitions), the stuttering seems to disappear (or at least becomes negligible) and the audio output, despite becoming incredibly distorted, is consistent in every other way, with in-order dialogues and (perceived) correct tempo. + + +In order to exclude eventual misconfigurations in the host's audio processing pipeline, I proceeded to update the domain definition's codepath of another guest running Ubuntu 18.04 with a completely different hardware configuration (no video card passthrough and no PulseAudio backconnection, just a plain emulated VirtIO display and Spice audio device). + +The audio issue presented itself again in the form of slightly sped up audio playback from Internet videos interleaved with occasional "quenches" of playing speed. +Stutters are difficult to detect because of the poor refresh rate of the emulated VGA adapter, but I wouldn't be surprised to find them here too (actually, I *think* I sensed them, but I'm not sure enough to assess their existence). + +Once again, by reverting to the old 2.11 directive everything is back to normal. + + + +Given the fact that no official upgrade directives regarding required sampling rate, period or sheduling adjustments were stated or handed-out to administrators, I decided to report this behaviour as a bug. +I hope this is the appropriate channel and that I didn't annoy anyone (this is my first proper bug report, please forgive me for any innaccuracy). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1798434 b/results/classifier/deepseek-2/output/device/1798434 new file mode 100644 index 000000000..385c454fc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1798434 @@ -0,0 +1,6 @@ + +[Feature Request] Automatic device configuration discovery + +Would it be possible to have a script that enumerates the device tree of a Linux host and generates a qemu command line that would recreate it under emulation? The user would have to customize the arguments (for instance to point to disk image files), but it would take a lot of the guesswork out. + +Similarly, is there information that can be gleaned from the kernel build config that would help with configuration? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1799919 b/results/classifier/deepseek-2/output/device/1799919 new file mode 100644 index 000000000..9e4ece285 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1799919 @@ -0,0 +1,14 @@ + +IDE HDD emulation random read/write errors + +I unfortunately can’t give more tracks other than how to reproduce the bug, especially that the bug occurs randomly. + +Basically, I’m trying to install DOS 6.22 on an emulated ISA machine, and it fails, DOS complaining about read or write error on drive C. Repeating the operation multiple time, I see it occurs at random stage, sometime even before it partitions the drive, sometime when it formats the drive, sometime when it copies the files from the floppy to the drive. + +To test it, unpack the attached archive and execute `./run` from the extracted directory. The archive contains three raw floppy images for installing DOS 6.22, and a Bourne Shell script which invokes QEmu. Just press enter at any installation stage, the bug may occurs at any stage. + +I tried with `cache=none` to be sure it’s not a cache issue, but its the same whatever the cache policy is. + +Version and environment: using QEmu 3.0 on Ubuntu 16.04 on a 32 bits DELL Inspiron 9400 (not an emulation, that’s my real laptop). + +For why I’m using QEmu for this: the installation proceeds with not error in VirtualBox, but I wanted to use QEmu to have a serial mouse which is not available with QEmu and to have finer control over the machine configuration ; VirtualBox although good, is more limited in that regard. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1801674 b/results/classifier/deepseek-2/output/device/1801674 new file mode 100644 index 000000000..d3b1ad828 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1801674 @@ -0,0 +1,53 @@ + +Ubuntu16.04 LTS - PCI Pass Through in Ubuntu KVM 16.04.x must use QEMU with DDW support from PPA (Documentation) + +== Comment: #0 - Siraj M. Ismail <email address hidden> - 2016-10-05 11:35:38 == +---Problem Description--- + +Customer running PCI pass through with 16.04.1 KVM and with the stock QEMU packages will hit a DI if they do not update to the QEMU packages with DDW support. The packages are in PPA for customers to download, and test has verified the fix. The details are in Bugzilla 144123. + +---uname output--- +Ubuntu 16.04.1 with 4.4.0 Kernel + +Machine Type = 8247-22L + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + Run guest with adapters assigned via PCI PT, The guest will start having DI issues as soon as I/O started on the Pass Through adapter. + +Contact Information = <email address hidden> + +---Patches Installed--- +QEMU was updated from 2.5 version to 2.6.1 with patches for DDW support, can be found at PPA location : +https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw + +Userspace tool common name: QEMU + +Documentation version: N/A + +The userspace tool has the following bit modes: N/A + +Userspace rpm: N/A + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. + +== Comment: #5 - Leonardo Augusto Guimaraes Garcia <email address hidden> - 2017-04-25 16:23:57 == +I would rephrase to: + +------------------------------- + +Under KVM recommendations + +PCI passthrough recommendations + +If you are running PCI passthrough with 16.04.x KVM and with the stock QEMU package, update to the QEMU package that have DDW support. If you do not update the package, you will hit data integrity issues as soon as I/O is started on the adapter. + +The package is available at: https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw + +------------------------------- \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1802 b/results/classifier/deepseek-2/output/device/1802 new file mode 100644 index 000000000..d5f766dd9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1802 @@ -0,0 +1,10 @@ + +windows serial COM PollingFunc don't sleep if guest uart can't write +Description of problem: +If two or more characters are sent from the host to the guest via Windows Com/Serial, everything freezes. +Steps to reproduce: +1. +2. +3. +Additional information: +I fix it in qemu/chardev/char-win.c see attached file diff --git a/results/classifier/deepseek-2/output/device/1804 b/results/classifier/deepseek-2/output/device/1804 new file mode 100644 index 000000000..9d080cddb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1804 @@ -0,0 +1,12 @@ + +Virtual Machines Do Not Recognize Mouse 5 and 6 +Description of problem: +Trying to click the mouse buttons 5 and 6 to go forwards and backwards in Firefox does not work. It seems that those buttons are not recognized by the virtual machine. Tested with both `libvirt` and `aqemu`. Though `libvirt` testing was done on a Fedora host a few months prior. + +Running Fedora 38 VM in virtualbox does not have this problem, the guest recognizes button 5 and 6, going forwards and backwards in Firefox. +Steps to reproduce: +1. Install aqemu or libvirt on Debian 12 +2. Create a Fedora 38 Guest machine +3. Open Firefox and navigate to a few pages, then try to go backwards and forwards in history using the mouse buttons. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1806114 b/results/classifier/deepseek-2/output/device/1806114 new file mode 100644 index 000000000..f111b7c20 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1806114 @@ -0,0 +1,30 @@ + +Reading sectors from floppy with BIOS INT 13h is broken + +I'm developing a game bootable from a floppy disk, written in i386 assembly. I found out it doesn't work on newer QEMU versions. I managed to isolate the issue and it seems that there's a problem with handling of BIOS interrupt 13h when it comes to reading disk sectors (AH=02). + +I've written a simple test in assembly. It simply accesses four different floppy disk sectors and prints out the strings they contain. The problem is, the two latter strings don't show up at all nor the BIOS interrupt returns an error (CF set). I've attached the code to this bug report. I use following commands to compile it and run: + +$ nasm disk-test.asm -o disk-test.bin +$ qemu-system-i386 -boot a -fda disk-test.bin + +After running, the expected output is: + + I am a test string from boot sector + C:H:S 0:0:2 - Hello + C:H:S 0:0:3 - there! + C:H:S 0:1:4 - In QEMU you can't + C:H:S 1:0:5 - see these two lines! :( + +while the actual output is: + + I am a test string from boot sector + C:H:S 0:0:2 - Hello + C:H:S 0:0:3 - there! + + +So far, I found this problem in the current QEMU version for Ubuntu 18.04 (Debian 1:2.11+dfsg-1ubuntu7.8), as well as in the 3.1.0-rc3 and 2.12.1 versions, available on the www.qemu.org website. Thus, the issue doesn't seem to be very recent. + +To be sure, I ran the program on my other machine with older QEMU version (Debian 2.0.0+dfsg-2ubuntu1.43) and on my RaspberryPi 2 (Debian 1.1.2+dfsg-6+deb7u25) and everything works as expected there. It also works well in VirtualBox. + +I hope these information are useful to you, however, I feel like this bug may be more related to Seabios. If so, please let me know and I will report it somewhere else. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1806824 b/results/classifier/deepseek-2/output/device/1806824 new file mode 100644 index 000000000..36e699547 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1806824 @@ -0,0 +1,10 @@ + +SIE-200 (TrustZone) MPC: BLK_MAX returns an incorrect value + +Version: +$ qemu-system-arm --version +QEMU emulator version 3.0.92 (v3.1.0-rc2-31-gd522fba244) + +Arm SIE-200 Technical Reference Manual describes that BLK_MAX indicates the maximum value of "block based index register" (BLK_IDX). For example, the value 1 would indicate that BLK_IDX can be 0 or 1. According to my experiments, the AN505 FPGA image apparently follows this behavior. + +In the current implementation of QEMU, it appears to indicate the number of possible values for BLK_IDX, i.e., one plus the value it's supposed to return. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1809075 b/results/classifier/deepseek-2/output/device/1809075 new file mode 100644 index 000000000..36f1c1d9d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1809075 @@ -0,0 +1,32 @@ + +Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel + +Whenever capslock is pressed on host, both capslock keycode(0x3a 0xba) and capslock LED keycode(0xfa 0xfa) would be sent to the ps2 keycode stream. + +However, capslock LED is handled by another thread, confirmed by tracing `ps2_write_keyboard` with gdb. The keycode of casplock LED might divide + +For example, I sent AaBb but got ABa. I was using vncdotool, so it equals sending `capslock a capslock a capslock b capslock b`. In ps2_queue, I was expecting `3a fa fa ba 1e 9e 3a fa fa ba 1e 9e 3a fa fa ba 30 b0 3a fa fa ba 30 b0`. But actually once in a while, it might not receive such streams. In one case I got `3a fa fa ba 1e 9e 3a ba 1e fa fa 9e 3a ba 30 b0 3a ba 30 b0 fa fa` + +In this specific example, `a` was lost because LED keycode 'jumps in' its keycode. Kernel event device receives below streams +``` +# /dev/input/event receives what is sent from ps2_queue +# I use cap_1 to show capslock key down +cap_1 led caps_0, # 0x3a 0xfa 0xfa 0xba +a_1 a_0 # 0x1e 0x9e +caps_1 caps_0 # 0x3a 0xba +led # 0x1e 0xfa 0xfa 0x1e (we lost `a` here) +caps_1 caps_0 # 0x3a 0xba +b_1 led b_0 # 0x30 0xfa 0xfa 0xb0 +caps_1 caps_0 # 0x3a 0xba +led b_1 b_0 # 0xfa 0xfa 0x30 0xb0 +``` + +I made sure kernel receives the correct key stream as the qemu ps2_queue sends using /proc, ftrace and dynamic_debug. I explained the details in this [post](https://medium.com/@alapha23/quick-peek-into-kernel-land-keyboard-events-handling-with-ftrace-and-dynamic-debug-24a790056d5a) + +So it seems to be a concurrency issue. + +A hacky path on my mind is to skip all `0xfa` in ps2_queue. But I'm not sure if capslock LED is the only stink bug to our ps2 keycode queue as I've seen other keycodes handled by `ps2_write_keyboard` sent to ps2 queue. + +Another solution might be a memory barrier or a lock. Making key down and key up atomic will prevent another thread modifying the ps2 queue unwantedly. + +What do you think? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1809546 b/results/classifier/deepseek-2/output/device/1809546 new file mode 100644 index 000000000..f02d92551 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1809546 @@ -0,0 +1,45 @@ + +Writing a byte to a pl011 SFR overwrites the whole SFR + +The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. + +I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. + +Given: + +pl011_addr: .word 0x10009000 + +The following snippet will be problematic: + + ldr r3, pl011_addr + ldrb r2, [r3, #0x38] // IMSC + mov r2, #0 + orr r2, r2, #0x10 // R2 == 0x10 + strb r2, [r3, #0x38] // Whole word reads correctly after this + ldrb r2, [r3, #0x39] + mov r2, #0 + strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as well + +After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000010 + +After the second strb instruction, the write to 0x10009039 clears the entire word: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000000 + +QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: + +qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio + +Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: + + ldr r3, pl011_addr + mov r2, #0x10 + str r2, [r3, #0x38] + +Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. + +I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1809665 b/results/classifier/deepseek-2/output/device/1809665 new file mode 100644 index 000000000..a2530ec04 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1809665 @@ -0,0 +1,31 @@ + +Xbox One controller USB passthrough disconnections and stops + +I can't properly passthrough my Xbox One controller to a virtual machine; it causes USB disconnections on the host, ultimately preventing it to work (at all) on the guest + +I've seen a few other cases reported in other websites, which show the same symptoms: + +- https://www.reddit.com/r/VFIO/comments/97dhbw/qemu_w10_xbox_one_controller +- https://unix.stackexchange.com/questions/452751/how-can-i-pass-through-an-xbox-one-controller-to-a-windows-vm-on-ubuntu + +This is sample: + + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again + libusb: error [_get_usbfs_fd] libusb couldn't open USB device + /dev/bus/usb/003/016: No such file or directory + +I think this is a quite long-standing issue, as I've been experiencing through several versions, including the current one (3.1). + +I can reproduce this 100% of the times, on multiple host O/S distributions (the current one being based on Ubuntu 18.04 x86-64). + +I compile QEMU directly from source, and execute it via commandline; the command is very long, however, the relevant part is standard (I think): + + -usb \ + -device usb-tablet \ + -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ + +The guest is Windows 10 64bit. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1809684 b/results/classifier/deepseek-2/output/device/1809684 new file mode 100644 index 000000000..43387b211 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1809684 @@ -0,0 +1,27 @@ + +amdgpu passthrough on POWER9 (ppc64el) not working + +When attempting to pass a Vega 56 GPU to a virtualized guest using QEMU 3.1 on ppc64el (POWER9), the guest is unable to initialize the GPU. Further digging reveals the driver attempting to allocate a large BAR, which then fails: + +[ 6.058544] [drm] PCI I/O BAR is not found. +<snip uninteresting bits> +[ 6.679193] amdgpu 0000:00:03.0: BAR 2: releasing [mem 0x210400000000-0x2104001fffff pref] +[ 6.679306] amdgpu 0000:00:03.0: BAR 0: releasing [mem 0x210200000000-0x2103ffffffff pref] +[ 6.679361] amdgpu 0000:00:03.0: BAR 0: no space for [mem size 0x200000000 pref] +[ 6.679403] amdgpu 0000:00:03.0: BAR 0: failed to assign [mem size 0x200000000 pref] +[ 6.679444] amdgpu 0000:00:03.0: BAR 2: assigned [mem 0x200080200000-0x2000803fffff pref] +[ 6.681420] amdgpu 0000:00:03.0: VRAM: 8176M 0x000000F400000000 - 0x000000F5FEFFFFFF (8176M used) +[ 6.681507] amdgpu 0000:00:03.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF +[ 6.681594] amdgpu 0000:00:03.0: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF +[ 6.681653] [drm] Detected VRAM RAM=8176M, BAR=0M +[ 6.681688] [drm] RAM width 2048bits HBM +[ 6.681885] [TTM] Zone kernel: Available graphics memory: 4176288 kiB +[ 6.681978] [TTM] Zone dma32: Available graphics memory: 2097152 kiB +[ 6.682043] [TTM] Initializing pool allocator +[ 6.682159] [drm] amdgpu: 8176M of VRAM memory ready +[ 6.682249] [drm] amdgpu: 6117M of GTT memory ready. +[ 6.682387] [drm] GART: num cpu pages 8192, num gpu pages 131072 +[ 6.682466] amdgpu 0000:00:03.0: (-22) kernel bo map failed +[ 6.682539] [drm:amdgpu_device_init [amdgpu]] *ERROR* amdgpu_vram_scratch_init failed -22 +[ 6.682592] amdgpu 0000:00:03.0: amdgpu_device_ip_init failed +[ 6.682636] amdgpu 0000:00:03.0: Fatal error during GPU init \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1810975 b/results/classifier/deepseek-2/output/device/1810975 new file mode 100644 index 000000000..51e8e03ef --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1810975 @@ -0,0 +1,25 @@ + +qemu crashes when using "host" smartcard + +Hello, + +When starting qemu 3.1 (via libvirt) with an "host" smartcard defined, it crashes with: + + + Stack trace of thread 15264: + #0 0x00007f17029ae5f7 __GI___getpriority (libc.so.6) + #1 0x00007f170254ae18 _pt_root (libnspr4.so) + #2 0x00007f1702a86fa3 start_thread (libpthread.so.0) + #3 0x00007f17029b789f __clone (libc.so.6) + + Stack trace of thread 15210: + #0 0x00007f17029b7891 __clone (libc.so.6) + #1 0x0000000000000000 n/a (n/a) + + +Command line: + +qemu-system-x86_64 -enable-kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-win10/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-IBRS,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,ssbd=on,xsaveopt=on,pdpe1gb=on,abm=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 2109c1d6-edb0-4e2e-bd6a-cd7e38d303f2 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -device usb-ccid,id=ccid0,bus=usb.0,port=4 -drive file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1 -drive if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=28,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:b4:0f:cc,bus=pci.0,addr=0x3 -device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=0,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917007 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1811 b/results/classifier/deepseek-2/output/device/1811 new file mode 100644 index 000000000..9252b50f8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1811 @@ -0,0 +1,37 @@ + +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/deepseek-2/output/device/1811543 b/results/classifier/deepseek-2/output/device/1811543 new file mode 100644 index 000000000..5fb1811b5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1811543 @@ -0,0 +1,73 @@ + +virtio-scsi gives improper discard sysfs entries + +Apologies if this is just an inherent part of paravirtualization that should be expected. + +In my host, I have an LVM thin pool with chunk_size 128MB. Within it, I have a thin volume "tmp". In the host: + +# fdisk -l /dev/lvm/tmp +Disk /dev/lvm/tmp: 256 MiB, 268435456 bytes, 524288 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 262144 bytes / 134217728 bytes +Disklabel type: gpt +Disk identifier: BAE3154E-6E85-F642-8129-BAD7B58B2775 + +Device Start End Sectors Size Type +/dev/lvm/tmp1 2048 524254 522207 255M Linux filesystem + +$ lsblk +... + └─lvm-tmp 254:13 0 256M 0 lvm + └─lvm-tmp1 254:14 0 255M 0 part + +$ cat /sys/dev/block/254:13/discard_alignment +0 +$ cat /sys/dev/block/254:13/queue/discard_granularity +134217728 +$ cat /sys/dev/block/254:13/queue/discard_max_bytes +17179869184 +$ cat /sys/dev/block/254:13/queue/discard_max_hw_bytes +0 +$ cat /sys/dev/block/254:13/queue/discard_zeroes_data +0 + +$ cat /sys/dev/block/254:14/discard_alignment +133169152 +$ cat /sys/dev/block/254:14/queue/discard_granularity +134217728 +$ cat /sys/dev/block/254:14/queue/discard_max_bytes +17179869184 +$ cat /sys/dev/block/254:14/queue/discard_max_hw_bytes +0 +$ cat /sys/dev/block/254:14/queue/discard_zeroes_data +0 + +If this is given to QEMU using virtio-scsi: + + -device virtio-scsi-pci,id=scsi1 \ + -drive driver=raw,node-name=hdb,file=/dev/lvm/tmp,if=none,discard=unmap,id=hd2 \ + -device scsi-hd,drive=hd2,bootindex=1 \ + +Then incorrect values are given: + +$ lsblk +... +sdb 8:16 0 256M 0 disk +└─sdb1 8:17 0 255M 0 part /mnt + +$ cat /sys/dev/block/8:16/discard_alignment +0 +$ cat /sys/dev/block/8:16/queue/discard_granularity +4096 +$ cat /sys/dev/block/8:16/queue/discard_max_bytes +1073741824 +$ cat /sys/dev/block/8:16/queue/discard_max_hw_bytes +1073741824 +$ cat /sys/dev/block/8:16/queue/discard_zeroes_data +0 + +$ cat /sys/dev/block/8:17/discard_alignment +133169152 + +And, there isn't even a /sys/dev/block/8:17/queue direcotry. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1811653 b/results/classifier/deepseek-2/output/device/1811653 new file mode 100644 index 000000000..5f93fbc9d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1811653 @@ -0,0 +1,42 @@ + +usbredir slow when multi bulk packet per second + +QEMU Ver: all version +Client: virt-viewer by spice +Guest VM: win7 +Bug description: + Use Qemu 2.1 or later with usbredir, When I redirect a bulk usb-device from virt-viewer client, +the bulk-usb-device driver or app in GuestVM will send 50 bulk-urb per times. + In VM, using the usblyzer to monitor the usb packet, it show these 50 bulk-urb packet send in 1ms, +But in the QEMU VM log, It shows as below +========================= +2019-01-14T08:27:26.096809Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.105680Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.108219Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.116742Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.119242Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.129851Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.132349Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.141248Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.144932Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.154035Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +========================= + + It shows that the bulk packet is single thread send and recv, per bulk packet will use 10-20ms, all 50 bulk-packets will use 500~1000ms, so the in the VM, bulk-urb will timeout always! + + How to send the bulk packet by multithread to speedup the bulk-urb send and recv, for example: +------------ + bulk-out ep 86 stream 0 len 49152 id xxxx1 + bulk-out ep 86 stream 0 len 49152 id xxxx2 + bulk-out ep 86 stream 0 len 49152 id xxxx3 + bulk-out ep 86 stream 0 len 49152 id xxxx4 + bulk-out ... + bulk-out ep 86 stream 0 len 49152 id xxxx50 +... + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx1 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx2 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx3 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx4 + bulk-out ... + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx50 +------------ \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1811758 b/results/classifier/deepseek-2/output/device/1811758 new file mode 100644 index 000000000..40ff77177 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1811758 @@ -0,0 +1,6 @@ + +virtio-rng backend should use getentropy() syscall when available + +According to https://wiki.qemu.org/Features/VirtIORNG the default backend for `virtio-rng-pci` is `/dev/random`. Alternately, the user can point it to a different backend file, like `/dev/urandom`. + +However, both of these files have suboptimal behavior in one way or another, as documented in `random(7)`. Instead, the default behavior should be to pull the requested octets from the `getrandom()` system call, if available, called with no flags set. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1815 b/results/classifier/deepseek-2/output/device/1815 new file mode 100644 index 000000000..1ce6f2771 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1815 @@ -0,0 +1,83 @@ + +Null pointer access in nvme_directive_receive() +Description of problem: +Got an access within null pointer error when fuzzing nvme. +Steps to reproduce: +Minimized reproducer for the error: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 \ +-nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device \ +nvme,drive=disk0,serial=1 -qtest /dev/null -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +write 0xe0000024 0x4 0x040002 +write 0xe0000014 0x4 0x61004600 +write 0xe0001000 0x1 0x04 +write 0x0 0x1 0x1a +write 0x4 0x1 0x01 +write 0x2c 0x1 0x01 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +[I 0.000000] OPENED +[R +0.025407] outl 0xcf8 0x80000810 +[S +0.025443] OK +OK +[R +0.025456] outl 0xcfc 0xe0000000 +[S +0.025470] OK +OK +[R +0.025476] outl 0xcf8 0x80000804 +[S +0.025483] OK +OK +[R +0.025489] outw 0xcfc 0x06 +[S +0.025934] OK +OK +[R +0.025946] write 0xe0000024 0x4 0x040002 +[S +0.025958] OK +OK +[R +0.025964] write 0xe0000014 0x4 0x61004600 +[S +0.025988] OK +OK +[R +0.026025] write 0xe0001000 0x1 0x04 +[S +0.026041] OK +OK +[R +0.026048] write 0x0 0x1 0x1a +[S +0.026256] OK +OK +[R +0.026268] write 0x4 0x1 0x01 +[S +0.026279] OK +OK +[R +0.026292] write 0x2c 0x1 0x01 +[S +0.026303] OK +OK +../hw/nvme/ctrl.c:6890:29: runtime error: member access within null pointer of type 'NvmeEnduranceGroup' (aka 'struct NvmeEnduranceGroup') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/nvme/ctrl.c:6890:29 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==1085476==ERROR: AddressSanitizer: SEGV on unknown address 0x000000001fc8 (pc 0x56306b765ebf bp 0x7ffff17fd890 sp 0x7ffff17f6a00 T0) +==1085476==The signal is caused by a READ memory access. + #0 0x56306b765ebf in nvme_directive_receive ../hw/nvme/ctrl.c:6890:33 + #1 0x56306b765ebf in nvme_admin_cmd ../hw/nvme/ctrl.c:6958:16 + #2 0x56306b765ebf in nvme_process_sq ../hw/nvme/ctrl.c:7015:13 + #3 0x56306cda2c3b in aio_bh_call ../util/async.c:169:5 + #4 0x56306cda3384 in aio_bh_poll ../util/async.c:216:13 + #5 0x56306cd3f15b in aio_dispatch ../util/aio-posix.c:423:5 + #6 0x56306cda72da in aio_ctx_dispatch ../util/async.c:358:5 + #7 0x7fa321cc417c in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5217c) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561) + #8 0x56306cda840f in glib_pollfds_poll ../util/main-loop.c:290:9 + #9 0x56306cda840f in os_host_main_loop_wait ../util/main-loop.c:313:5 + #10 0x56306cda840f in main_loop_wait ../util/main-loop.c:592:11 + #11 0x56306bd17f76 in qemu_main_loop ../softmmu/runstate.c:732:9 + #12 0x56306c721835 in qemu_default_main ../softmmu/main.c:37:14 + #13 0x7fa320aeb082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #14 0x56306af0309d in _start (./qemu-system-x86_64+0x1e9109d) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV ../hw/nvme/ctrl.c:6890:33 in nvme_directive_receive +``` diff --git a/results/classifier/deepseek-2/output/device/1815413 b/results/classifier/deepseek-2/output/device/1815413 new file mode 100644 index 000000000..4a6c130e4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1815413 @@ -0,0 +1,28 @@ + +compile with vhost-vsock support on osx + +compiling latest (3.1.0) on osx 10.14.3 with --enable-vhost-vsock and target = x86_64-softmmu results in compile errors: + +Undefined symbols for architecture x86_64: + "_vhost_dev_cleanup", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + _vhost_vsock_device_unrealize in vhost-vsock.o + "_vhost_dev_disable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_enable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_init", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + "_vhost_dev_start", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_stop", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_virtqueue_mask", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + _vhost_vsock_guest_notifier_mask in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_mask) + "_vhost_virtqueue_pending", referenced from: + _vhost_vsock_guest_notifier_pending in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_pending) +ld: symbol(s) not found for architecture x86_64 +clang: error: linker command failed with exit code 1 (use -v to see invocation) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1815445 b/results/classifier/deepseek-2/output/device/1815445 new file mode 100644 index 000000000..0d010e6c0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1815445 @@ -0,0 +1,16 @@ + +change and eject commands are not working on an overlay + +From qemu monitor, 'change' and 'eject' commands are not working on a CD overlay. +'info block' returns: + cd0-overlay0: /home/guillaume/test/cd0-overlay0 (qcow2) + Attached to: cd0-device + Removable device: not locked, tray closed + Cache mode: writeback, ignore flushes + Backing file: /home/guillaume/test.iso (chain depth: 1) + +But 'eject cd0-overlay0' returns: + Device 'cd0-overlay0' not found +I also tried 'cd0-device' and 'cd0'. + +Same problem with 'change' command. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1815721 b/results/classifier/deepseek-2/output/device/1815721 new file mode 100644 index 000000000..fb90cd58a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1815721 @@ -0,0 +1,15 @@ + +RISC-V PLIC enable interrupt for multicore + +Hello all, + +There is a bug in Qemu related to the enabling of external interrupts for multicores (Virt machine). + +After correcting Qemu as described in #1815078 (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable interrupts for core 1 at address 0x0C00_2080 we don't seem to be able to trigger an external interrupt (e.g. UART0). + +This works perfectly for core 0, but fore core 1 it does not work at all. I assume that given bug #1815078 does not enable any external interrupt then this feature has not been tested. I tried to look at the qemu source code but with no luck so far. + +I guess the problem is related to function parse_hart_config (in sfive_plic.c) that initializes incorrectly the plic->addr_config[addrid].hartid, which is later on read in sifive_plic_update. But this is a guess. + +Best regards, +Pharos team \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1815993 b/results/classifier/deepseek-2/output/device/1815993 new file mode 100644 index 000000000..813d57bc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1815993 @@ -0,0 +1,30 @@ + +drive-backup with iscsi will cause vm disk no response + +virsh qemu-monitor-command ${DOMAIN} '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.100:3260/iqn.2019-01.com.iaas/0" } }' + +When the drive-backup is running, I manually crash the iscsi server（or interrupt network, eg. iptables -j DROP）. + +Then after less than 1 minute： +virsh qemu-monitor-command ${DOMAIN} --pretty '{ "execute": "query-block" }' will block and no any response, until timeout. This is still excusable. +But, the disk（drive-virtio-disk0）will occur the same situation：in vm os, the disk will block and no any response. + +In other words, when qemu and iscsi-server lose contact, It will cause the vm unable. + +--- +Host: centos 7.5 +qemu version: ovirt-4.2（qemu-2.12.0） +qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +iscsi： +yum -y install targetcli python-rtslib +systemctl start target +systemctl enable target + +targetcli /iscsi create iqn.2019-01.com.iaas + +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 + +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.100 3260 +targetcli /backstores/fileio create testfile1 /backup/file1 2G +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/testfile1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1816052 b/results/classifier/deepseek-2/output/device/1816052 new file mode 100644 index 000000000..b37e4d611 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1816052 @@ -0,0 +1,72 @@ + +qemu system emulator fails to start if no sound card is present on host + +A plain build from git master at 81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host, with no options passed to configure. + +Trying to launch QEMU on a host with no audio card present: + +# ls /dev/snd/ +seq timer + +It will fail to initialize alsa and abort startup: + +# qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso -m 4000 -vnc 0.0.0.0:1 +ALSA lib confmisc.c:767:(parse_card) cannot find card '0' +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory +ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory +ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory +ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or directory +ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default +alsa: Could not initialize DAC +alsa: Failed to open `default': +alsa: Reason: No such file or directory +ALSA lib confmisc.c:767:(parse_card) cannot find card '0' +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory +ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory +ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory +ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or directory +ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default +alsa: Could not initialize DAC +alsa: Failed to open `default': +alsa: Reason: No such file or directory +init fail +audio: Failed to create voice `pcspk' +qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing audio voice failed + + +git bisect blames this change: + + + commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad) + Author: Gerd Hoffmann <email address hidden> + Date: Thu Jan 24 12:20:55 2019 +0100 + + audio: probe audio drivers by default + + Add the drivers listed in audio_possible_drivers to audio_drv_list, + using the try-* variants. That way the probable drivers are compiled by + default if possible. + + Additioal tweaks: + linux: reorder to: pa alsa sdl oss. + *bsd: drop pa. + + Signed-off-by: Gerd Hoffmann <email address hidden> + Message-id: <email address hidden> + + +This changed our probe order: + + Linux) + - audio_drv_list="oss" + + audio_drv_list="try-pa try-alsa try-sdl oss" + +After some debugging I can see that 'audio_init' successfully initializes the alsa driver. + +When the pcspk devices goes to AUD_open_out though, the alsa driver fails spewing the above text to stderr and thus causes QEMU to fail. + +This looks very much like the ALSA driver in QEMU is broken - audio_init() should not have succeeded unless the ALSA driver knew it could later succesfully honour AUD_open_out. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1816189 b/results/classifier/deepseek-2/output/device/1816189 new file mode 100644 index 000000000..2bb5aad8f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1816189 @@ -0,0 +1,27 @@ + +Unable to create or revert snapshots + +With an update to Qemu (3.1.x) I am unable to revert snapshots using virt-manager or virsh. Virtual Machines existing before the update seem to function properly. It is only after creating a new machine that snapshots are misbehaving. I tested spinning up vms of tumbleweed, leap15, and ubuntu 18.04. Each of them had the following issues: + +- With the machine running, live reversions act like they apply, but no changes are actually made. +- With the machine paused, reversion also does not apply. +- With the machine turned off, reversion is not possible. Virsh is unable to find the snapshot, and virt-manager errors out with: + +Error running snapshot 'FreshInstall': internal error: qemu unexpectedly closed the monitor: 2019-01-15T19:19:46.020247Z qemu-system-x86_64: Device 'drive-virtio-disk0' does not have the requested snapshot 'FreshInstall' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1105, in revert_to_snapshot + self._backend.revertToSnapshot(snap.get_backend()) + File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2024, in revertToSnapshot + if ret == -1: raise libvirtError ('virDomainRevertToSnapshot() failed', dom=self) + +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-01-15T19:19:46.020247Z qemu-system-x86_64: Device 'drive-virtio-disk0' does not have the requested snapshot 'FreshInstall' + +After doing some digging, the error occurs because of the following commit: +d98f26073bebddcd3da0ba1b86c3a34e840c0fb8 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1816614 b/results/classifier/deepseek-2/output/device/1816614 new file mode 100644 index 000000000..a3c871371 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1816614 @@ -0,0 +1,24 @@ + +error: static assertion failed: "arm generic timer needs __Int128 defined" + +Hi, + +Accordingly to the instruction from https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842060/QEMU we have downloaded the Xilinx QEMU and tried to build it on Ubuntu 16.04.5 32Bit OS. We have done all the following steps from the instruction: +$ git clone git://github.com/Xilinx/qemu.git +$ cd qemu +$ git submodule update --init dtc +$ ./configure --target-list="aarch64-softmmu,microblazeel-softmmu" --enable-fdt --disable-kvm --disable-xen +$ make +and we have got the error during the compilation: +/home/qemu/include/qemu/int128.h:168:1: error: static assertion failed: "arm generic timer needs __Int128 defined" + _Static_assert(0, "arm generic timer needs __Int128 defined"); + ^ +/home/qemu/rules.mak:66: recipe for target 'stubs/qmp_pc_dimm.o' failed + +Could you please help to solve this issue. + +Last commit: commit 0b2f6a40631acd7e0cf789ea86b188d76c11149d + +Thanks, +Best Regards, +Piotr \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1816805 b/results/classifier/deepseek-2/output/device/1816805 new file mode 100644 index 000000000..47a020d26 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1816805 @@ -0,0 +1,13 @@ + +Cannot create cdrom device with open tray and cache option + +When trying to create cdrom device with open tray and either of "cache" or "discard" options specified, I get the following error: + +qemu-system-x86_64: -drive if=none,id=drive-ide0-0-0,readonly=on,cache=writeback,discard=unmap,throttling.iops-total=900: Must specify either driver or file + +This bug essentially forbids live migration of VMs with open cdrom trays. + +I was able to find the same bug at RedHat: +https://bugzilla.redhat.com/show_bug.cgi?id=1338638 + +The bug was encountered in versions 2.5 and 2.11. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1817525 b/results/classifier/deepseek-2/output/device/1817525 new file mode 100644 index 000000000..f736b8457 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1817525 @@ -0,0 +1,79 @@ + +qemu fails to compile on gcc 9 "block/nvme.c:209:22: error: taking address of packed member of 'struct <anonymous>' may result in an unaligned pointer value [-Werror=address-of-packed-member]" + +Issue: +Qemu compilation fails with below error on ppc64le host with gcc 9, repo(https://github.com/dgibson/qemu.git), branch(ppc-for-4.0), Commit (0483e90393bac8546a1fbc95ab912a1e78e92b00) + + CHK version_gen.h + CC block/nvme.o +block/nvme.c: In function ‘nvme_create_queue_pair’: +block/nvme.c:209:22: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 209 | q->sq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale]; + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +block/nvme.c:216:22: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 216 | q->cq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale + 1]; + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/usr/share/avocado-plugins-vt/build/qemu/rules.mak:69: block/nvme.o] Error 1 + + + +$git commit: +commit 0483e90393bac8546a1fbc95ab912a1e78e92b00 (HEAD -> ppc-for-4.0) +Author: Thomas Huth <email address hidden> +Date: Thu Feb 21 12:24:48 2019 +0100 + + hw/ppc: Use object_initialize_child for correct reference counting + + Both functions, object_initialize() and object_property_add_child() increase + the reference counter of the new object, so one of the references has to be + dropped afterwards to get the reference counting right. Otherwise the child + object will not be properly cleaned up when the parent gets destroyed. + Thus let's use now object_initialize_child() instead to get the reference + counting here right. + + Suggested-by: Eduardo Habkost <email address hidden> + Signed-off-by: Thomas Huth <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Cédric Le Goater <email address hidden> + Signed-off-by: David Gibson <email address hidden> + + +Note: Same commit on a different ppc64le host with gcc(8.1.1 20180712) compile without any issue. + +Env: + +Power8 + +#lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 160 +On-line CPU(s) list: 0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152 +Off-line CPU(s) list: 1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79,81-87,89-95,97-103,105-111,113-119,121-127,129-135,137-143,145-151,153-159 +Thread(s) per core: 1 +Core(s) per socket: 5 +Socket(s): 4 +NUMA node(s): 4 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8E (raw), altivec supported +CPU max MHz: 3690.0000 +CPU min MHz: 2061.0000 +L1d cache: 64K +L1i cache: 32K +L2 cache: 512K +L3 cache: 8192K +NUMA node0 CPU(s): 0,8,16,24,32 +NUMA node1 CPU(s): 40,48,56,64,72 +NUMA node16 CPU(s): 80,88,96,104,112 +NUMA node17 CPU(s): 120,128,136,144,152 + +# gcc --version +gcc (GCC) 9.0.1 20190209 (Red Hat 9.0.1-0.4) +Copyright (C) 2019 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +# uname -r +5.0.0-rc7-ge50585e89 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/182 b/results/classifier/deepseek-2/output/device/182 new file mode 100644 index 000000000..a06833881 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/182 @@ -0,0 +1,2 @@ + +qemu-xhci device should detect if libusb host supports streams diff --git a/results/classifier/deepseek-2/output/device/1821054 b/results/classifier/deepseek-2/output/device/1821054 new file mode 100644 index 000000000..cfdd77620 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1821054 @@ -0,0 +1,5 @@ + +qemu segfault error when using pcie to dual pci adapter + +All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor" +I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1823169 b/results/classifier/deepseek-2/output/device/1823169 new file mode 100644 index 000000000..661ba2fc5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1823169 @@ -0,0 +1,6 @@ + +qemu displays message "Setup failed, please check external storage is available and has enough room." + +I tried to launch the Android app PokerStarsFR, and after it began initialization, the launch failed with the above error. I'm running qemu on a Dell XPS 13 (9370) laptop running Ubuntu 16.04 LTS. The standard apps launch OK, but this one does not. I had downloaded it from the PokerStars site https://www.pokerstars.fr/en/poker/download/android/. + +I am running qemu version 2.5.0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1824744 b/results/classifier/deepseek-2/output/device/1824744 new file mode 100644 index 000000000..5a746ce70 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1824744 @@ -0,0 +1,8 @@ + +ivshmem PCI device exposes wrong endianness on ppc64le + +On a ppc64le host with a ppc64le guest running on QEMU 3.1.0 when an ivshmem device is used, the ivshmem device appears to expose the wrong endianness for the values in BAR 0. + +For example, when the guest is assigned an ivshmem device ID of 1, the IVPosition register (u32, offset 8 in BAR 0) returns 0x1000000 instead of 0x1. I tested on an x86_64 machine and the IVPosition reads 0x1 as expected. + +It seems possible that there's a ppc64*==bigendian assumption somewhere that is erroneously affecting ppc64le. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1826 b/results/classifier/deepseek-2/output/device/1826 new file mode 100644 index 000000000..dac49f637 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1826 @@ -0,0 +1,30 @@ + +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/deepseek-2/output/device/1826422 b/results/classifier/deepseek-2/output/device/1826422 new file mode 100644 index 000000000..250a26f88 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1826422 @@ -0,0 +1,50 @@ + +Regression: QEMU 4.0 hangs the host (*bisect included*) + +The commit b2fc91db84470a78f8e93f5b5f913c17188792c8 seemingly introduced a regression on my system. + +When I start QEMU, the guest and the host hang (I need a hard reset to get back to a working system), before anything shows on the guest. + +I use QEMU with GPU passthrough (which worked perfectly until the commit above). This is the command I use: + +``` +/path/to/qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 10240 + -vga none + -rtc base=localtime + -serial none + -parallel none + -usb + -device usb-tablet + -device vfio-pci,host=01:00.0,multifunction=on + -device vfio-pci,host=01:00.1 + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device usb-host,vendorid=<vid>,productid=<pid> + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/guest.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user,smb=/path/to/shared +``` + +If I run QEMU without GPU passthrough, it runs fine. + +Some details about my system: + +- O/S: Mint 19.1 x86-64 (it's based on Ubuntu 18.04) +- Kernel: 4.15 +- `configure` options: `--target-list=x86_64-softmmu --enable-gtk --enable-spice --audio-drv-list=pa` +- EDK2 version: 1a734ed85fda71630c795832e6d24ea560caf739 (20/Apr/2019) +- CPU: i7-6700k +- Motherboard: ASRock Z170 Gaming-ITX/ac +- VGA: Gigabyte GTX 960 Mini-ITX \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1828272 b/results/classifier/deepseek-2/output/device/1828272 new file mode 100644 index 000000000..935b5a47b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1828272 @@ -0,0 +1,22 @@ + +4.0 breaks keyboard autorepeat in guests with xserver + +Description: +In a linux/bsd guest within X, pressing and holding a key for a short time causes an endless repeat of that key in the guest. The release of the key gets ignored. +Example 1: pressing and holding 'a' for a few seconds results in typing of 'aaaaaaaaaaaa...' endlessly. +Example 2: pressing and holding 'Backspace' for a few seconds results in deleting all your previously typed text. + +It doesn't happen within a VT in the guest. It also doesn't happen with guests that run windows, reactos or haiku for example. + +The problem goes away, when disabling xorgs autorepeat function via "xset -r" in the host. +Normally, this setting should not have any effect on the guest, since it has it's own autorepeat setting. So there is some conflict here. + +Steps to reproduce: +Start any linux/bsd guest system with xserver, open a terminal, press and hold a key for a short time: Look how it gets typed endlessly (Try a few times if it doesn't happen immediately). +The easiest way is to run a linux live cd, like this (Link to example iso :http://download.grml.org/grml64-full_2018.12.iso) +$ qemu-system-x86_64 -enable-kvm -m 512 -boot d -cdrom grml64-full_2018.12.iso + + +Qemu version info: +QEMU emulator version 4.0.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1828508 b/results/classifier/deepseek-2/output/device/1828508 new file mode 100644 index 000000000..309864c62 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1828508 @@ -0,0 +1,25 @@ + +qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" + +Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a Windows 10 machine. + +Converting a VHD to VMDK. +qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk" + +I have also tried: +qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk" + +Attaching the VMDK to a VM in VMware produces the following error when powering on. + +Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. +Target: MyVM1 +vCenter Server: VCENTER +Error Stack +An error was received from the ESX host while powering on VM MyVM1. +Failed to start the virtual machine. +Module DevicePowerOn power on failed. +Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' +Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. + + +If I do not specify the adapter type, it creates an IDE VMDK which works perfectly. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1829498 b/results/classifier/deepseek-2/output/device/1829498 new file mode 100644 index 000000000..579d92143 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1829498 @@ -0,0 +1,18 @@ + +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) :) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/183 b/results/classifier/deepseek-2/output/device/183 new file mode 100644 index 000000000..d78fabed7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/183 @@ -0,0 +1,2 @@ + +Cannot use usb-host on Mac OS diff --git a/results/classifier/deepseek-2/output/device/1831 b/results/classifier/deepseek-2/output/device/1831 new file mode 100644 index 000000000..6c6c4e5fb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1831 @@ -0,0 +1,2 @@ + +qemu-system-m68k: ../hw/scsi/scsi-disk.c:557: scsi_write_data: Assertion `r->req.aiocb == NULL' failed. diff --git a/results/classifier/deepseek-2/output/device/1833661 b/results/classifier/deepseek-2/output/device/1833661 new file mode 100644 index 000000000..cd583dcd7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1833661 @@ -0,0 +1,20 @@ + +Linux kernel oops on Malta board while accessing pflash + +commit 33d609990621dea6c7d056c86f707b8811320ac1 + +While running tests/acceptance/linux_ssh_mips_malta.py, the big-endian tests fail: + + physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 + Intel/Sharp Extended Query Table at 0x0031 + Using buffer write method + Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 + Creating 3 MTD partitions on "physmap-flash.0": + 0x000000000000-0x000000100000 : "YAMON" + 0x000000100000-0x0000003e0000 : "User FS" + 0x0000003e0000-0x000000400000 : "Board Config" + CPU 0 Unable to handle kernel paging request at virtual address 00000014 + +The 64-bit test fails with: + + CPU 0 Unable to handle kernel paging request at virtual address 0000000000000028 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1834113 b/results/classifier/deepseek-2/output/device/1834113 new file mode 100644 index 000000000..eaa61252b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1834113 @@ -0,0 +1,48 @@ + +QEMU touchpad input erratic after wakeup from sleep + +Using Ubuntu host and guest. Normally the touchpad works great. Within the last few days, suddenly, apparently after a wake from sleep, the touchpad will behave erratically. For example, it will take two clicks to select something, and when moving the cursor it will act as though it is dragging even with the button not clicked. + +A reboot fixes the issue temporarily. + +ProblemType: Bug +DistroRelease: Ubuntu 19.04 +Package: qemu 1:3.1+dfsg-2ubuntu3.1 +Uname: Linux 5.1.14-050114-generic x86_64 +ApportVersion: 2.20.10-0ubuntu27 +Architecture: amd64 +CurrentDesktop: ubuntu:GNOME +Date: Mon Jun 24 20:55:44 2019 +Dependencies: + +EcryptfsInUse: Yes +InstallationDate: Installed on 2019-02-20 (124 days ago) +InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 +Lsusb: + Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 001 Device 002: ID 8087:0025 Intel Corp. + Bus 001 Device 003: ID 0c45:671d Microdia + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +MachineType: Dell Inc. Precision 5530 +ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.1.14-050114-generic root=UUID=18e8777c-1764-41e4-a19f-62476055de23 ro mem_sleep_default=deep mem_sleep_default=deep acpi_rev_override=1 scsi_mod.use_blk_mq=1 nouveau.modeset=0 nouveau.runpm=0 nouveau.blacklist=1 acpi_backlight=none acpi_osi=Linux acpi_osi=! +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 04/26/2019 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: 1.10.1 +dmi.board.name: 0FP2W2 +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 10 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvr1.10.1:bd04/26/2019:svnDellInc.:pnPrecision5530:pvr:rvnDellInc.:rn0FP2W2:rvrA00:cvnDellInc.:ct10:cvr: +dmi.product.family: Precision +dmi.product.name: Precision 5530 +dmi.product.sku: 087D +dmi.sys.vendor: Dell Inc. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1835827 b/results/classifier/deepseek-2/output/device/1835827 new file mode 100644 index 000000000..aa433bb41 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1835827 @@ -0,0 +1,6 @@ + +HTIF symbols no longer recognized by RISC-V spike board + +Tested commit: f34edbc760b0f689deddd175fc08732ecb46665f + +I belive this was introduced in 0ac24d56c5e7d32423ea78ac58a06b444d1df04d when the spike's load_kernel() was moved to riscv_load_kernel() which no longer included htif_symbol_callback(). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1836855 b/results/classifier/deepseek-2/output/device/1836855 new file mode 100644 index 000000000..432bc34f7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1836855 @@ -0,0 +1,33 @@ + +virtio_scsi_ctx_check failed when detach virtio_scsi disk + +I found a problem that virtio_scsi_ctx_check failed when detaching virtio_scsi disk. The bt is below: + +(gdb) bt +#0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +#1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +#2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +#5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +#6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +#7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +#8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +#9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +#10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +#11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +#12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +#13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +#14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 + +assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. + +I think this patch (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) introduce this problem. + +commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back to main AioContext on unplug. It set the AioContext of + +SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContext. Is this a bug? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1839060 b/results/classifier/deepseek-2/output/device/1839060 new file mode 100644 index 000000000..3fa363b50 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1839060 @@ -0,0 +1,19 @@ + +HDA device non functional in Windows 10 1903 + +I made the update to 1903, and the HDA device stopped working. + +The driver says the device is working correctly, but it does not. +When I try to open the Windows sound configuration, the dialog hangs and never shows it's content. + +Several people reported this back in May: + +https://windowsreport.com/windows-10-v1903-ich6-ich9-virtio/ + +I can confirm I have exactly the same problem. + +Host is Arch Linux, current (5.2.5) kernel, QEMU 4.0. + +I enabled HDA debug output and compared an older, working Windows version to 1903, but could not see the difference. The driver seems to issue the same verbs. + +I am happy to provide additional information if needed. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1839807 b/results/classifier/deepseek-2/output/device/1839807 new file mode 100644 index 000000000..70fe83c66 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1839807 @@ -0,0 +1,49 @@ + +Snapshots freeze guest Sabrelite IMX.6 board + +Hello, + +I'm trying to take and restore a snapshot with the whole system state of the Sabrelite IMX.6 board running on QEMU with commands savevm/loadvm. +It seems that I am able to take a snapshot but loading the snapshot fails. + +For comparison I checked out snapshots on 32bit ARM Virt with Debian as well as on the Versatilepb board with a bare metal application and it works fine. +The problem occurs only with that one particular board. + +My environment is: +Ubuntu 18.04 +QEMU 3.0.1 (I see the same issue in QEMU 4.0.0 as well) +The kernel and device tree used for the board was 5.1.14 version from kernel.org + +The file system was build from imx_v6_v7_defconfig config in buildroot as and sd card image. + +Problem: + +Loading snapshot stops the whole machine and it's impossible to resume it. + +Steps to reproduce problem: + +1. I converted the sdcard.img built from the buildroot to qcow2 using command qemu-img convert -f raw -O qcow2 sdcard.img sdcard.qcow2, since the raw doesn't support snapshots. + +2. I start QEMU with a command +./arm-softmmu/qemu-system-arm -m 512 -M sabrelite -kernel zImage -append "rootfstype=ext4 root=/dev/mmcblk2p2 rw rootwait" -rtc base=localtime,clock=vm -dtb imx6dl-sabresd.dtb -drive file=sdcard.qcow2,index=2,format=qcow2,id=mycard -device sd-card,drive=mycard -nographic -net nic -net user + +3. I run a simple program which print characters to the console in the background and add some files in user directory, to differ from original image. + +4. I switch to QEMU monitor, and type “savevm <name>”. +When I type “info snapshots”, the snapshot is listed. +So I assume it was saved correctly. + +5. Then I switch back to Linux console from monitor, remove the added files and stop the background printing process. + +6. I switch back to monitor and I'm trying now to load the snapshot by “loadvm <name>” command. + +That’s where the problem occurs. QEMU stops and I can't switch back from monitor to Linux. +Typing “cont” doesn’t help. +It seems like the simulation has freezed. CPU usage on my Laptop machine equals 100% until I exit QEMU. + + +What’s interesting when I exit the QEMU and then start it again the Linux boots and after it reaches the command prompt I can see the files which were removed after saving the snapshot. + +It looks like loading the snapshots works for restoring disk space but it fails for restoring the running processes. + +Due to the answer on QEMU mailing list (https://lists.nongnu.org/archive/html/qemu-discuss/2019-08/msg00016.html) it is QEMUs bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1841 b/results/classifier/deepseek-2/output/device/1841 new file mode 100644 index 000000000..793049fc3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1841 @@ -0,0 +1,13 @@ + +qemu version with 7.2.5 or earlier than 7.2.5 with nvme disk has I/O QID 22 timeout, Aborting errors +Description of problem: +When I use the 7.2.5 version of qemu or versions earlier than 7.2.5 to compile and start the virtual machine, the machine has an nvme disk which is SAMSUNG MZQL23T8HCLS-00B7C and passed through by VFIO. When i use fio to perform pressure test on the nvme disk in vm, dmesg shows message like this nvme nvme0: I/O QID 22 timeout, Aborting, the picture below shows its details. Howerver, when i use 8.0.0 version of qemu to compile and start vm, and using fio to perform pressure test on the nvme disk in vm, it does not have the problem like that. I have using different kernel version, however, the probelem persists, so i think this is not a kernel issue, but a qemu problem. + + +if the irqbalance is running in vm, the problem happens very often, however if the irqbalance is stopped, the problem disappear. + + +Steps to reproduce: +1. using the 7.2.5 or versions earlier than 7.2.5 and start vm which has an nvme disk +2. the nvme disk is passed through by VFIO +3. using FIO to perform pressure test on the nvme disk in vm diff --git a/results/classifier/deepseek-2/output/device/1842530 b/results/classifier/deepseek-2/output/device/1842530 new file mode 100644 index 000000000..0d3dc0ccc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1842530 @@ -0,0 +1,62 @@ + +ich6 and ich9 sound card has noisy（murmur） + +[root@localhost1 qemu]# lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 6 +On-line CPU(s) list: 0-5 +Thread(s) per core: 1 +Core(s) per socket: 6 +Socket(s): 1 +NUMA node(s): 1 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 158 +Model name: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz +Stepping: 10 +CPU MHz: 899.951 +CPU max MHz: 4000.0000 +CPU min MHz: 800.0000 +BogoMIPS: 5616.00 +Virtualization: VT-x +L1d cache: 32K +L1i cache: 32K +L2 cache: 256K +L3 cache: 9216K +NUMA node0 CPU(s): 0-5 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp spec_ctrl intel_stibp flush_l1d + + +[root@localhost1 qemu]# lsb_release -a +LSB Version: :core-4.1-amd64:core-4.1-noarch +Distributor ID: CentOS +Description: CentOS Linux release 7.6.1810 (Core) +Release: 7.6.1810 +Codename: Core + +Installed as Virtualization Server (qemuV1.5)； +create win7-32 or 64 GuestOS by virt-manager，and select default sound card ich6； + +<graphics type='spice' autoport='yes'> + <listen type='address'/> + <image compression='off'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + + +but obvious noise found when login guest os to play music. :( + +And the problem remains after I update qemu to 2.12.0-18 , 3.1.0 &etc. + + +[root@localhost1 qemu]# /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 3.1.0 +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1842774 b/results/classifier/deepseek-2/output/device/1842774 new file mode 100644 index 000000000..e5c8627bb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1842774 @@ -0,0 +1,4 @@ + +Enhanced Hardware Support - Finalize Naming + +This feature request will provide the final naming of the next machine \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1842787 b/results/classifier/deepseek-2/output/device/1842787 new file mode 100644 index 000000000..1c8fe8f4c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1842787 @@ -0,0 +1,82 @@ + +Writes permanently hang with very heavy I/O on virtio-scsi - worse on virtio-blk + +Up to date Arch Linux on host and guest. linux 5.2.11. QEMU 4.1.0. Full command line at bottom. + +Host gives QEMU two thin LVM volumes. The first is the root filesystem, and the second is for heavy I/O, on a Samsung 970 Evo 1TB. + +When maxing out the I/O on the second virtual block device using virtio-blk, I often get a "lockup" in about an hour or two. From the advise of iggy in IRC, I switched over to virtio-scsi. It ran perfectly for a few days, but then "locked up" in the same way. + +By "lockup", I mean writes to the second virtual block device permanently hang. I can read files from it, but even "touch foo" never times out, cannot be "kill -9"'ed, and is stuck in uninterruptible sleep. + +When this happens, writes to the first virtual block device with the root filesystem are fine, so the O/S itself remains responsive. + +The second virtual block device uses BTRFS. But, I have also tried XFS and reproduced the issue. + +In guest, when this starts, it starts logging "task X blocked for more than Y seconds". Below is an example of one of these. At this point, anything that is or does in the future write to this block device gets stuck in uninterruptible sleep. + +----- + +INFO: task kcompactd:232 blocked for more than 860 seconds. + Not tained 5.2.11-1 #1 +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this messae. +kcompactd0 D 0 232 2 0x80004000 +Call Trace: + ? __schedule+0x27f/0x6d0 + schedule+0x3d/0xc0 + io_schedule+0x12/0x40 + __lock_page+0x14a/0x250 + ? add_to_page_cache_lru+0xe0/0xe0 + migrate_pages+0x803/0xb70 + ? isolate_migratepages_block+0x9f0/0x9f0 + ? __reset_isolation_suitable+0x110/0x110 + compact_zone+0x6a2/0xd30 + kcompactd_do_work+0x134/0x260 + ? kvm_clock_read+0x14/0x30 + ? kvm_sched_clock_read+0x5/0x10 + kcompactd+0xd3/0x220 + ? wait_woken+0x80/0x80 + kthread+0xfd/0x130 + ? kcompactd_do_work+0x260/0x260 + ? kthread_park+0x80/0x80 + ret_from_fork+0x35/0x40 + +----- + +In guest, there are no other dmesg/journalctl entries other than "task...blocked". + +On host, there are no dmesg/journalctl entries whatsoever. Everything else in host continues to work fine, including other QEMU VM's on the same underlying SSD (but obviously different lvm volumes.) + +I understand there might not be enough to go on here, and I also understand it's possible this isn't a QEMU bug. Happy to run given commands or patches to help diagnose what's going on here. + +I'm now running a custom compiled QEMU 4.1.0, with debug symbols, so I can get a meaningful backtrace from the host point of view. + +----- + +/usr/bin/qemu-system-x86_64 + -name arch,process=qemu:arch + -no-user-config + -nodefaults + -nographic + -uuid 0528162b-2371-41d5-b8da-233fe61b6458 + -pidfile /tmp/0528162b-2371-41d5-b8da-233fe61b6458.pid + -machine q35,accel=kvm,vmport=off,dump-guest-core=off + -cpu SandyBridge-IBRS + -smp cpus=24,cores=12,threads=1,sockets=2 + -m 24G + -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd + -drive if=pflash,format=raw,readonly,file=/var/qemu/0528162b-2371-41d5-b8da-233fe61b6458.fd + -monitor telnet:localhost:8000,server,nowait,nodelay + -spice unix,addr=/tmp/0528162b-2371-41d5-b8da-233fe61b6458.sock,disable-ticketing + -device ioh3420,id=pcie.1,bus=pcie.0,slot=0 + -device virtio-vga,bus=pcie.1,addr=0 + -usbdevice tablet + -netdev bridge,id=network0,br=br0 + -device virtio-net-pci,netdev=network0,mac=02:37:de:79:19:09,bus=pcie.0,addr=3 + -device virtio-scsi-pci,id=scsi1 + -drive driver=raw,node-name=hd0,file=/dev/lvm/arch_root,if=none,discard=unmap + -device scsi-hd,drive=hd0,bootindex=1 + -drive driver=raw,node-name=hd1,file=/dev/lvm/arch_nvme,if=none,discard=unmap + -device scsi-hd,drive=hd1,bootindex=2 + +----- \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1843 b/results/classifier/deepseek-2/output/device/1843 new file mode 100644 index 000000000..c9e2d50ca --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1843 @@ -0,0 +1,16 @@ + +Multitouch - GTK: Tapping 3 points or more at too close in interval causes all points to be lost +Description of problem: +When using the new multitouch input device, if you use three or more fingers within two rapid interval, the all finger inputs get dropped. +Steps to reproduce: +ANDROID +1. Download and install BlissOS +2. Swipe with two fingers +3. try multitouch debug app + +FEDORA +1. Load fedora +2. install wev +3. try touch 3 or more points +Additional information: +Not sure what logs are relevant diff --git a/results/classifier/deepseek-2/output/device/1843711 b/results/classifier/deepseek-2/output/device/1843711 new file mode 100644 index 000000000..e23e49a1a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1843711 @@ -0,0 +1,12 @@ + +qemu-xhci device should detect if libusb host supports streams + +When using USB passthrough with the qemu-xhci (and nec-usb-xhci), streams are enabled by default, but if the host xHCI controller doesn't support them, it will trigger hard-to-debug UAS guest errors. + +This should be possible to detect since the kernel returns ENOSYS (errno 38) when xhci host controller does not support streams: + libusb: error [do_streams_ioctl] streams-ioctl failed error -1 errno 38 + qemu: libusb_alloc_streams: -99 [OTHER] + +Maybe libusb should return a dedicated error instead of LIBUSB_ERROR_OTHER in this case, but qemu does not handle any other error code anyway. + +Just trying to enable streams before enabling them in qemu should do it. I don't know if it should be done in hcd-xhci.c, host-libusb.c or elsewhere, but this would be detectable at launch instead of a static option true/false, maybe a ternary with auto would be better. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1845580 b/results/classifier/deepseek-2/output/device/1845580 new file mode 100644 index 000000000..603396038 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1845580 @@ -0,0 +1,10 @@ + +issue with QEMU on Raspberry Pi failing to access CDROM + +I am trying to access the CDROM (iso) from QEMU using FreeDOS and I get an error when doing a directory for: + +i can boot from the iso but if i exit to access the files from the CDROM ISO i get the attached error. + +I believe there is an issue with the QEMU for the Raspberry Pi. + +I am using a Raspberry Pi3 with the latest full Raspbian Buster load \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1846451 b/results/classifier/deepseek-2/output/device/1846451 new file mode 100644 index 000000000..fa423ffa5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1846451 @@ -0,0 +1,19 @@ + +K800 keyboard no longer works when attached to a VM + +I use Logitech K800 keyboard which is connected to a PC through Logitech unifying receiver. In order to control my windows VM i attach unifying receiver USB device to a VM using "virsh attach-device VM-Name ./device.xml". Device ID as seen in lsusb is 046d:c52b. + +As of v4.1.0 keyboard no longer works when attached to a windows VM. When attached receiver is still at least partially functional. Logitech pairing utility properly displays paired keyboard, pressing buttons on the keyboard shows changing indicator icon in pairing utility. Pairing and unpairing works. Pressing keys however fails to register any key presses. + +Downgrading to v4.0.0 fixes the issue. + +device.xml used to attach USB device: +``` +<hostdev mode='subsystem' type='usb'> + <source> + <vendor id='0x046d'/> + <product id='0xc52b'/> + </source> +</hostdev> + +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1847793 b/results/classifier/deepseek-2/output/device/1847793 new file mode 100644 index 000000000..c1c224e11 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1847793 @@ -0,0 +1,46 @@ + +qemu 4.1.0 - Corrupt guest filesystem after new vm install + +When I install a new vm with qemu 4.1.0 all the guest filesystems are corrupt. The first boot from the install dvd iso is ok and the installer work fine. But the guest system hangs after the installer finishes and I reboot the guest. I can see the grub boot menue but the system cannot load the initramfs. + +Testet with: +- RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and / partition) +Guided install with the graphical installer, no lvm selected. +- Debian Stable/Buster (Debian uses ext4 for / and /home partition) +Guidet install with the graphical installer and default options. + +Used commandline to create the vm disk image: +qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G + +Used qemu commandline for vm installation: +#!/bin/sh +# vmtest10 Installation +# +/usr/bin/qemu-system-x86_64 -cpu SandyBridge-IBRS \ + -soundhw hda \ + -M q35 \ + -k de \ + -vga qxl \ + -machine accel=kvm \ + -m 4096 \ + -display gtk \ + -drive file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom \ + -drive file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback \ + -boot once=d,menu=off \ + -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \ + -netdev bridge,br=br0,id=vlan0 \ + -rtc base=localtime \ + -name "vmtest10" \ + -usb -device usb-tablet \ + -spice disable-ticketing \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent $* + +Host OS: +Archlinux (last updated at 10.10.2019) +Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux +No libvirt in use. + + +With qemu 4.0.0 it works fine without any errors. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1847861 b/results/classifier/deepseek-2/output/device/1847861 new file mode 100644 index 000000000..99a418c2c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1847861 @@ -0,0 +1,31 @@ + +Guest stuttering under high disk IO (virtio) + +Performing io intensive tasks on virtualized Windows causes the system to visually stutter. I can often reproduce the problem by running fio on windows: + +fio --randrepeat=1 --ioengine=windowsaio --direct=1 --gtod_reduce=1 --name=test --filename=\\.\PhysicalDrive0 --bs=4k --iodepth=128 --size=4G --readwrite=randread + +While the fio command is running, moving the mouse pointer will be be laggy. The stuttering does not appear with iodepth <= 32 . The stuttering also manifests while playing games, the music and video pauses for a fraction of second in a playable but disturbing way. + +Here are my system specs: + +Host OS: archlinux +Guest OS: Windows 10 Enterprise +qemu version: qemu-git 8:v4.1.0.r1378.g98b2e3c9ab-1 (from AUR, compiled with -march=native) +CPU: AMD Ryzen Threadripper 1900X 8-Core Processor +Huge Pages: vm.nr_hugepages=4128 +Disk: nvme type=raw, io=threads bus=virtio +GPU (passthrough): Radeon RX 570 + +Here are some fio test results on my windows guest: + +[size=512M,iodepth=1 -> min=30k,avg=31k,stddev=508] +[size=2G,iodepth=8 -> min=203k,avg=207k,stddev=2.3k] +[size=2G,iodepth=16 -> min=320k,avg=330k,stddev=4.3k] +[size=4G,iodepth=32 -> min=300k,avg=310k,stddev=4.8k] +[size=4G,iodepth=64 -> min=278k,avg=366k,stddev=68.6k] -> STUTTER +[size=4G,iodepth=64 -> min=358k,avg=428k,stddev=52.6k] -> STUTTER +[size=4G,iodepth=128 -> min=92k,avg=217k,stddev=185k] -> STUTTER +[size=4G,iodepth=128 -> min=241k,avg=257k,stddev=14k] -> same config as above, but no stuttering + +The min and avg values are the bandwidth values reported in KB/s by fio. You can see that, when the stuttering occurs, the stardard deviation is high and the minimum bandwidth is way below the average. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1848231 b/results/classifier/deepseek-2/output/device/1848231 new file mode 100644 index 000000000..75086ee56 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1848231 @@ -0,0 +1,18 @@ + +serial/parallel character devices created for the none-machine + +The none-machine can not be started unless using "-serial null": + +qemu-system-x86_64 -machine none -nographic -monitor stdio +QEMU 3.1.1 monitor - type 'help' for more information +(qemu) qemu-system-x86_64: cannot use stdio by multiple character devices +qemu-system-x86_64: could not connect serial device to character backend 'stdio' +$ + +$ qemu-system-mips -machine none -nographic -serial null -monitor stdio +QEMU 4.1.50 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +compat_monitor0: filename=stdio +serial0: filename=null +(qemu) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1849 b/results/classifier/deepseek-2/output/device/1849 new file mode 100644 index 000000000..8a7de2cc0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1849 @@ -0,0 +1,72 @@ + +Problems with building riscv Linux using qemu on wsl2 +Description of problem: +execute: + +`qemu-system-riscv64 -M virt -m 256M -nographic -kernel /home/ysc/test/linux-6.1.46/arch/riscv/boot/Image -drive file=rootfs.img,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -append "root=/dev/vda rw console=ttyS0"` + +**appear:** + +OpenSBI + +/ \_\_ \\ / **_| \_ \_ | | | | | \_\_ \__\_ \_ \_\_ | (_**\_ | |_) || | | | | | '\_ \\ / \_ \\ '\_ \\ \__\_ | \_ \< | | | |\*\*| | |_) | \_\_/ | | |) | |) || | \_\_**/| .**/ \_\*\*|_| |_|**_/|\___\_/_**| | | |\_| + +Platform Name : riscv-virtio,qemu + +Platform Features : medeleg Platform HART Count : 1 + +Platform IPI Device : aclint-mswi + +Platform Timer Device : aclint-mtimer @ 10000000Hz + +Platform Console Device : uart8250 Platform HSM Device : --- + +Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test + +Firmware Base : 0x80000000 + +Firmware Size : 252 KB + +Runtime SBI Version : 0.3 + +Domain0 Name : root + +Domain0 Boot HART : 0 + +Domain0 HARTs : 0\* + +Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I) + +Domain0 Region01 : 0x0000000080000000-0x000000008003ffff () + +Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X) + +Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x000000008f000000 + +Domain0 Next Mode : S-mode Domain0 SysReset : yes + +Boot HART ID : 0 + +Boot HART Domain : root + +Boot HART ISA : rv64imafdcsuh + +Boot HART Features : scounteren,mcounteren,time + +Boot HART PMP Count : 16 + +Boot HART PMP Granularity : 4 + +Boot HART PMP Address Bits: 54 + +Boot HART MHPM Count : 0 + +Boot HART MIDELEG : 0x0000000000001666 + +Boot HART MEDELEG : 0x0000000000f0b509 + +When I run qemu, it's stuck here +Steps to reproduce: +1. Build the kernel file using Linux-6.1.46 +2. Use busbox to build rootfs +3. run qemu diff --git a/results/classifier/deepseek-2/output/device/1849894 b/results/classifier/deepseek-2/output/device/1849894 new file mode 100644 index 000000000..9b2d77700 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1849894 @@ -0,0 +1,45 @@ + +hw/scsi/scsi-disk.c line 2554 allocation overflow + +When compiling qemu from git master (at commit 03bf012e523ecdf047ac56b2057950247256064d ) on Linux amd64, with gcc-9 9.2.1 , and using `-march=native -flto`, during linking of most target binaries, compiler does detect an issue with allocation in scsi_disk_new_request_dump and aborts compilation. + + +make[1]: Entering directory '/home/user/qemu/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory '/home/user/qemu/slirp' +nm: stats64.o: no symbols + LINK aarch64-softmmu/qemu-system-aarch64 +In function ‘scsi_disk_new_request_dump’, + inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2580:9, + inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2564:21: +hw/scsi/scsi-disk.c:2554:19: error: argument 1 value ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] +hw/scsi/scsi-disk.c: In function ‘scsi_new_request’: +/usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function ‘g_malloc’ declared here + 78 | gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1); + | ^ +lto1: all warnings being treated as errors +lto-wrapper: fatal error: c++ returned 1 exit status +compilation terminated. +/usr/bin/ld: error: lto-wrapper failed +collect2: error: ld returned 1 exit status + + + +same happens for most other targets: alpha-softmmu/qemu-system-alpha arm-softmmu/qemu-system-arm hppa-softmmu/qemu-system-hppa i386-softmmu/qemu-system-i386 lm32-softmmu/qemu-system-lm32 mips-softmmu/qemu-system-mips mips64-softmmu/qemu-system-mips64 mips64el-softmmu/qemu-system-mips64el mipsel-softmmu/qemu-system-mipsel ppc-softmmu/qemu-system-ppc ppc64-softmmu/qemu-system-ppc64 riscv32-softmmu/qemu-system-riscv32 riscv64-softmmu/qemu-system-riscv64 s390x-softmmu/qemu-system-s390x sh4-softmmu/qemu-system-sh4 sh4eb-softmmu/qemu-system-sh4eb sparc-softmmu/qemu-system-sparc sparc64-softmmu/qemu-system-sparc64 x86_64-softmmu/qemu-system-x86_64 xtensa-softmmu/qemu-system-xtensa xtensaeb-softmmu/qemu-system-xtensaeb + +Notice -softmmu being a common factor here. + + + +The size of the allocation for the temporary buffer for dumping using snprintf is determined based on the size of the buffer via call to scsi_cdb_length. I believe the heavy inlining and constant propagation makes scsi_cdb_length return -1, so len = -1. Then allocation size is 5*len + 1, or -4. Which overflows to 2^64 - 4 or so. + +The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5) is not 0, 1, 2, 4 or 5. + +However, I can't find out how gcc figures out that buf[0] is not one of these variables. To me looking at this function, compiler should not know anything about buf[0]. + +I tried following the chain of calls back, including devirtualize alloc_req, and I found scsi_device_alloc_req calling these alloc_req callbacks, but it is itself called from scsi_req_new, which is called in get_scsi_requests , just after buf is filled from QEMUFile using qemu_get_buffer, which ultimately goes even further into read paths, which there might be many AFAIK. + + + + +glib2 version 2.62.1-1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1850570 b/results/classifier/deepseek-2/output/device/1850570 new file mode 100644 index 000000000..5b4e34018 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1850570 @@ -0,0 +1,38 @@ + +Cannot use usb-host on Mac OS + +Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives these errors and the drive does not show up. Also, when Qemu is starting the drive ejects and remounts twice. Qemu built with ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl --disable-cocoa --enable-sdl-image. + +qemu-system-i386 image.qcow -usb -device usb-kbd -device usb-host,vendorid=0x0781,productid=0x5571 +libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1851547 b/results/classifier/deepseek-2/output/device/1851547 new file mode 100644 index 000000000..087a9807f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1851547 @@ -0,0 +1,21 @@ + +qemu 4 crashes with this parameter attached -usb -device usb-host,hostbus=1,hostaddr=7 \ + +Hello. + +qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to 19.10 and qemu from 3 to 4,as you can see below. what can I do ? + +root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot-OS-HSP2.sh + +----> qemu-system-x86_64: /build/qemu-UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev != NULL" non riuscita. + +./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu-system-x86_64 -enable-kvm -m 16000 -cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none -device vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device vfio-pci,host=01:00.1,bus=pcie.0 -device vfio-pci,host=01:00.2,bus=pcie.0 -device vfio-pci,host=01:00.3,bus=pcie.0 -usb -device usb-host,hostbus=1,hostaddr=7 -drive if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2 -device ich9-ahci,id=sata -drive id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2' -device ide-hd,bus=sata.2,drive=Clover -device ide-hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide-hd,bus=sata.4,drive=BsdHDD -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio + +It seems that this line is not good anymore (it worked with qemu 3.x) : + +-usb -device usb-host,hostbus=1,hostaddr=7 \ + +when I removed it,it works. But I need that. With what can I change it ? You can reproduce that upgrading ubuntu 19.04 to 19.10 because in that way also qemu will be upgraded from 3 to 4. These are the packages that I'm using : + +root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version +QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1851552 b/results/classifier/deepseek-2/output/device/1851552 new file mode 100644 index 000000000..e0156b978 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1851552 @@ -0,0 +1,16 @@ + +since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is unable to boot up on openstack instance + +Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +Tried to boot up the instance via horizon dashboard without success. +Nova flow works perfect. +When access to console I discovered that the boot process stuck in the middle. +[[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +[[0;1;33mDEPEND[0m] Dependency failed for /mnt. +[[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +It receives IP but looks like not get configured at time. +since ubuntu 18 there is netplan feature managing the network interfaces +please advise. + +more details as follow: +https://bugs.launchpad.net/networking-calico/+bug/1851548 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1851664 b/results/classifier/deepseek-2/output/device/1851664 new file mode 100644 index 000000000..9a81514ef --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1851664 @@ -0,0 +1,7 @@ + +qemu-system-x86_64: "VFIO_MAP_DMA : -28" error when we attache 6 VF's to guest machine + +We are trying to attach 6 VF's to the guest machine on 4.1.1 qemu emulator. +We are observing "VFIO_MAP_DMA : -28" error. + +We are using w-bits=48 bits while lunching VM. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1851972 b/results/classifier/deepseek-2/output/device/1851972 new file mode 100644 index 000000000..4e764352e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1851972 @@ -0,0 +1,60 @@ + +pc-q35-4.1 and AMD Navi 5700/XT incompatible + +Hello, + +I am not sure if this qualifies as a "bug"; it is be more of an unknown issue with default settings. However, since the default value of q35 default_kernel_irqchip_split was changed seemingly due to similar user feedback, I thought this was important to share.. + +AMD Navi 5700/XT vfio-pci passthrough seems incompatible with one/multiple settings in pc-q35-3.1 and higher. The workaround for me is that pc-q35-3.0 still works fine passing through the GPU and official drivers can load/install fine. + +The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest do work; the monitor displays the desktop in a 800x600 resolution and things are rendered fine.. so the basic functionality of the card seems fine with pc-q35-4.1. + +But attempting to use the official open source AMD driver with the card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on the Windows 1903 guest immediately during driver install. + +I do not see any errors in Qemu command output.. did not investigate other logs or KVM etc, because I am not sure what to look for or how to go about it. Also not sure which combination of the latest q35 default settings are valid combinations to try either, because it seems that multiple things have changed related to pcie-root-port defaults and other machine options. I am happy to run tests and provide feedback if that helps identify the issue. + +I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host with AMD Navi reset pci quirk patch applied. + +My working Qemu command line is this: + +QEMU_AUDIO_DRV=pa \ +QEMU_PA_SERVER=/run/user/1000/pulse/native \ +/usr/bin/qemu-system-x86_64 \ +-name windows \ +-m 16g \ +-accel kvm \ +-machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \ +-blockdev node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \ +-blockdev node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \ +-boot menu=on \ +-global kvm-pit.lost_tick_policy=discard \ +-no-hpet \ +-rtc base=utc,clock=host,driftfix=slew \ +-cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \ +-smp sockets=1,cores=4,threads=1 \ +-nodefaults \ +-netdev bridge,br=br0,id=net0 \ +-device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \ +-device virtio-scsi-pci \ +-blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \ +-device scsi-hd,drive=disk0,rotation_rate=1 \ +-blockdev raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw \ +-device scsi-hd,drive=disk1,rotation_rate=1 \ +-drive index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso \ +-drive index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso \ +-device ich9-intel-hda,addr=1b.0 \ +-device hda-output \ +-monitor stdio \ +-display none \ +-vga none \ +-device pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on \ +-device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \ +-device x3130-upstream,bus=pcierp0,id=pcieu0 \ +-device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \ +-device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \ +-device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \ +-device qemu-xhci,addr=1d.0 \ +-device usb-host,vendorid=0x258a,productid=0x0001 \ +-device usb-host,vendorid=0x1bcf,productid=0x0005 ; + +Thank you! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1853898 b/results/classifier/deepseek-2/output/device/1853898 new file mode 100644 index 000000000..6c9884053 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1853898 @@ -0,0 +1,25 @@ + +qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed. + +While experimenting with blkdebug I can consistently hit this assertion in lsi53c895a.c. + +Using locally built from master, commit: 2061735ff09f9d5e67c501a96227b470e7de69b1 + +Steps to reproduce + +$ qemu-img create -f raw empty.raw 8G +$ sudo losetup -f --show empty.raw +$ sudo mkfs.ext3 /dev/loop0 +$ sudo losetup -D + +$ cat blkdebug.conf +[inject-error] +event = "read_aio" +errno = "5" + +$ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic user,ipv6=off,model=e1000,hostfwd=tcp::2222-:22,net=172.16.0.0/255.255.255.0 -device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678 -drive if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw -cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk + +Initiate install from cdrom ISO image results in: + +qemu-system-x86_64: /builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed. +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1856 b/results/classifier/deepseek-2/output/device/1856 new file mode 100644 index 000000000..abe68a337 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1856 @@ -0,0 +1,14 @@ + +Replay got stuck with consecutive hardware interrupts coming +Description of problem: +I recorded bin file using **_rr=record_** command line. But it got stuck when replaying this record bin file. The icount number would never change after stucking if I typed _**info replay**_ with qmp command line. + +I found that the following instructions should be a sequence of consecutive hardware interrupts after stucking once checking the trace log of +both replay and record log using _**-d in_asm,int**_. +Steps to reproduce: +1.pulling from remote which the newest commit ID is 156618d9ea67f2f2e31d9dedd97f2dcccbe6808c +2.emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3.using **_rr=record_** to make replay file and tracing guest code and interrupts using _**-d in_asm,int**_ +4.replaying the previous file and also tracing guest code and interrupts +Additional information: +# diff --git a/results/classifier/deepseek-2/output/device/1856724 b/results/classifier/deepseek-2/output/device/1856724 new file mode 100644 index 000000000..3ab599f31 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1856724 @@ -0,0 +1,19 @@ + +SB.PCI0.SMB0 device drivers unavailable + +QEMU 4.2 introduces new device with this code: + +static void build_smb0(Aml *table, I2CBus *smbus, int devnr, int func) +{ + Aml *scope = aml_scope("_SB.PCI0"); + Aml *dev = aml_device("SMB0"); + + aml_append(dev, aml_name_decl("_HID", aml_eisaid("APP0005"))); + aml_append(dev, aml_name_decl("_ADR", aml_int(devnr << 16 | func))); + build_acpi_ipmi_devices(dev, BUS(smbus), "\\_SB.PCI0.SMB0"); + aml_append(scope, dev); + aml_append(table, scope); +} + +It is detected by Windows 10 as 'Unknown Device' and there is no driver available. +Please provide a working Windows driver or give ability to disable this device. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1856834 b/results/classifier/deepseek-2/output/device/1856834 new file mode 100644 index 000000000..6abf437e0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1856834 @@ -0,0 +1,28 @@ + +PCI broken in qemu ppc e500 in v2.12.0 and other versions + +The same qemu -M mpc... command that works on qemu-system-ppc version 2.8.0 freezes guest on bootup and shows error for qemu-system-ppc version 4.2.0release and 4.19dirtygit: + +qemu-system-ppc: virtio-blk failed to set guest notifier (-24), ensure -accel kvm is set. +qemu-system-ppc: virtio_bus_start_ioeventfd: failed. Fallback to userspace (slower). + +ends/freezes at: +nbd: registered device at major 43 + vda: + +I'm using -drive file=/home/me/rawimage.dd,if=virtio and works fine in version 2.8.0 installed with apt-get install (Ubuntu 17.04) and also with 2.8.0 official release from git/github that I compiled/built myself. But both of the newer releases fail on the same exact machine same config. + +I also noticed that qemu-2.8.0 was fine with mtd but the newer ones I tried weren't, ie gave +qemu-system-ppc: -drive if=mtd: machine type does not support if=mtd,bus=0,unit=0 +(but I removed -drive if=mtd since wasn't using it anyway) + +I also tried on windows but I think virtio doesn't work on windows hosts at all? On windows host it fails the same way, even version 2.12 as well as 4.1.10... + +used: +./configure --prefix=/opt/... --enable-fdt --enable-kvm --enable-debug + +(basically all steps the same on same exact system same config, yet 2.8.0 works fine whether apt-get installed or built from source while the others I built, 4.19/4.2.0 or 2.12/4.1.10(win) don't.) + +In case newer qemu versions act weird on various kernels, I did try with both vmlinuz-4.10.0-19-generic and vmlinuz-4.13.12-041312-generic (I didn't compile them but I can provide config-..files) +tx + ecs \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1858 b/results/classifier/deepseek-2/output/device/1858 new file mode 100644 index 000000000..655b7ad25 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1858 @@ -0,0 +1,11 @@ + +Block device read operation misses one byte(8 bit) per chip per SPI transaction +Description of problem: +Block device Micron m25qu02gcbb (hw/block/m25p80.c) is emulated by the two -drive files. For block device read operation, device driver from Windriver vxWorks issues SPI commands. For read SPI command( 0x6b ) from device driver, there is a data length to be read is specified. For each SPI command call, m25p80_transfer8(SSISlave *ss, uint32_t tx) from hw/block/m25p80.c is called and read byte is returned to guest OS. It is observed that for more than one sequential SPI read commmands, first byte from the next read block is not returned back to guest OS. Traces within m25p80.c shows that all the data bytes are read however, first byte from the next read block is missing at guest OS. + +drive file content: 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 +SPI read command is set to read 4 bytes in one transaction, two transactions are needed from guest OS to read the entire data. +trace_m25p80_read_byte() shows that all bytes are read at m25p80_transfer8() call. +At guest OS following is received: 0x0 0x1 0x2 0x3 0x5 0x6 0x7 0x8 (Missing first byte of the second transaction, 0x4) +Additional information: +Windriver is a proprietary OS so I can't attach the .bin files. However, any other guest OS should be able to demostrate this behavior. guest OS device driver is reading without errors on an actual Micron QSPI device. diff --git a/results/classifier/deepseek-2/output/device/1859021 b/results/classifier/deepseek-2/output/device/1859021 new file mode 100644 index 000000000..3d7c05387 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1859021 @@ -0,0 +1,33 @@ + +qemu-system-aarch64 (tcg): cval + voff overflow not handled, causes qemu to hang + +The Armv8 architecture reference manual states that for any timer set (e.g. CNTP* and CNTV*), the condition for such timer to generate an interrupt (if enabled & unmasked) is: + +CVAL <= CNT(P/V)CT + +Although this is arguably sloppy coding, I have seen code that is therefore assuming it can set CVAL to a very high value (e.g. UINT64_MAX) and leave the interrupt enabled in CTL, and never get the interrupt. + +On latest master commit as the time of writing, there is an integer overflow in target/arm/helper.c gt_recalc_timer affecting the virtual timer when the interrupt is enabled in CTL: + + /* Next transition is when we hit cval */ + nexttick = gt->cval + offset; + +When this overflow happens, I notice that qemu is no longer responsive and that I have to SIGKILL the process: + - qemu takes nearly all the cpu time of the cores it is running on (e.g. 50% cpu usage if running on half the cores) and is completely unresponsive + - no guest interrupt (reported via -d int) is generated + +Here the minimal code example to reproduce the issue: + + mov x0, #1 + msr cntvoff_el2, x0 + mov x0, #-1 + msr cntv_cval_el0, x0 + mov x0, #1 + msr cntv_ctl_el0, x0 // interrupt generation enabled, not masked; qemu will start to hang here + +Options used: +-nographic -machine virt,virtualization=on,gic-version=2,accel=tcg -cpu cortex-a57 +-smp 4 -m 1024 -kernel whatever.elf -d unimp,guest_errors,int -semihosting-config enable,target=native +-serial mon:stdio + +Version used: 4.2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1859359 b/results/classifier/deepseek-2/output/device/1859359 new file mode 100644 index 000000000..5def46baf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1859359 @@ -0,0 +1,28 @@ + +xHCI and event ring handling + +I believe that the Event Ring handling in QEMU is not correct. For example, an Event Ring may have multiple segments. However, the code in xhci_write_event() (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l645), starting with line 668, seems to only support a single segment. + +Also, QEMU is sending a spurious interrupt after the Guest writes to the ERDP register due to the fact that the address written does not match the current index. This is because the index is incremented after sending the event. The xHCI specification states in section 5.5.2.3.3 "When software finishes processing an Event TRB, it will write the address of that Event TRB to the ERDP." + +Since xhci_write_event() has already incremented the index pointer (intr->er_ep_idx), the check at line 3098 (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3090) no longer is valid. + +I have not studied QEMU's code enough yet to offer a patch. However, this should be a simple fix. + +intr->er_ep_idx++; +if (intr->er_ep_idx >= intr->er_table[intr->er_segment].er_size) { + intr->er_ep_idx = 0; + intr->er_segment++; + if (intr->er_segment >= intr->er_table_size) { + intr->er_segment = 0; + intr->er_pcs = !intr->er_pcs; + } +} + +Being sure to incorporate this new segment member into the above code (possibly as shown) as well as change the lines at 665 to use the new segment member of the structure, and of course in the initialization portion of the event ring. + +As for the spurious interrupt at line 3101, a new member will need to be added to the code to keep track of the last inserted ED (TRB) into the Event Ring and then of course checking against this new member, not the now newly incremented member. + +I have sent an email to the author listed at the top of the file as well, not sure if this is proper bug reporting etiquette or not. + +Thank you. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1859418 b/results/classifier/deepseek-2/output/device/1859418 new file mode 100644 index 000000000..7f7a488b1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1859418 @@ -0,0 +1,27 @@ + +disk driver with iothread setting hangs live migrations + +Per report raised at https://bugzilla.redhat.com/show_bug.cgi?id=1790093 + +Description of problem: + +A disk driver definition using iothread parameter causes live migration with copy storage to hang during or just before the final ram sync stage. + +Interestingly, having the scsi controller as a separate iothread does not trigger the issue. + +Version-Release number of selected component (if applicable): + +I can reproduce this on centos7 with qemu-ev and with centos 8: + +qemu-kvm-ev-2.12.0-33.1.el7_7.4.x86_64 +qemu-kvm-2.12.0-65.module_el8.0.0+189+f9babebb.5.x86_64 + +Steps to Reproduce: +1. Create a definition with 1 iothread on the disk image: + + <driver name='qemu' type='qcow2' iothread='1' /> + +2. Issue a live migrate request like: virsh migrate --live --copy-storage-all vm qemu+tcp://remote/system +3. Live migrate on source copies storage and then hangs at 80-99%, I guess during the ram copy phase. + +Keeping exactly the same config but without the iothread on the disk driver has successful migrations every time. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1859916 b/results/classifier/deepseek-2/output/device/1859916 new file mode 100644 index 000000000..f3e28f48e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1859916 @@ -0,0 +1,53 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1860759 b/results/classifier/deepseek-2/output/device/1860759 new file mode 100644 index 000000000..b0315315c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1860759 @@ -0,0 +1,16 @@ + +[REGRESSION] option `-snapshot` ignored with blockdev + +After upgrade of qemu 3.1.0 → 4.2.0 I found that running with libvirt doesn't honor `-snapshot` option anymore. I.e. disk images get modified. +Using `-hda` option honors `-snapshot` + +So I made a test case without libvirt. Testcase using 4.2.0: + +> qemu -hda tmp-16G.img -cdrom regular-rescue-latest-x86_64.iso -m 2G + +This works fine and tmp-16G.img stays unmodified. + +But: +> /usr/bin/qemu-system-x86_64 -name guest=test-linux,debug-threads=on -S -machine pc-i440fx-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,xsaveopt=on,pdpe1gb=on,abm=on -m 2048 -overcommit mem-lock=off -smp 3,sockets=3,cores=1,threads=1 -uuid d32a9191-f51d-4fae-a419-b73d85b49198 -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/regular-rescue-latest-x86_64.iso\",\"node-name\":\"libvirt-2-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-2-format\",\"read-only\":true,\"driver\":\"raw\",\"file\":\"libvirt-2-storage\"} -device ide-cd,bus=ide.0,unit=0,drive=libvirt-2-format,id=ide0-0-0,bootindex=1 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/tmp-2G.img\",\"node-name\":\"libvirt-1-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-1-format\",\"read-only\":false,\"driver\":\"qcow2\",\"file\":\"libvirt-1-storage\",\"backing\":null} -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-1-format,id=virtio-disk0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:d8:29,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -snapshot -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +This modifies tmp-16G.img. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1861692 b/results/classifier/deepseek-2/output/device/1861692 new file mode 100644 index 000000000..f97aefbc2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1861692 @@ -0,0 +1,4 @@ + +wavcapture does not record silence + +Using setup described in https://bugs.launchpad.net/qemu/+bug/1861677 a wav file is generated with all the silences stripped out. IOW silence frames are not recorded. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1862619 b/results/classifier/deepseek-2/output/device/1862619 new file mode 100644 index 000000000..417e398b0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1862619 @@ -0,0 +1,15 @@ + +"-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 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1863333 b/results/classifier/deepseek-2/output/device/1863333 new file mode 100644 index 000000000..86a346db7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1863333 @@ -0,0 +1,73 @@ + +Assigning NVMe disk to a domain causes VFIO_MAP_DMA errors + +I'm seeing some errors when assigning my NVMe disk to qemu. This is the full command line: + + +/home/zippy/work/qemu/qemu.git/x86_64-softmmu/qemu-system-x86_64 \ +-name guest=fedora,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-fedora/master-key.aes \ +-machine pc-i440fx-4.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m size=4194304k,slots=16,maxmem=1099511627776k \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=2,threads=2 \ +-object iothread,id=iothread1 \ +-object iothread,id=iothread2 \ +-object iothread,id=iothread3 \ +-object iothread,id=iothread4 \ +-mem-prealloc \ +-mem-path /hugepages2M/libvirt/qemu/2-fedora \ +-numa node,nodeid=0,cpus=0,mem=4096 \ +-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=31,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-global PIIX4_PM.disable_s3=0 \ +-global PIIX4_PM.disable_s4=0 \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/fedora.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-2-storage","backing":null}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1 \ +-blockdev '{"driver":"nvme","device":"0000:02:00.0","namespace":1,"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}' \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=libvirt-1-format,id=virtio-disk0 \ +-netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 \ +-device virtio-net-pci,host_mtu=9000,netdev=hostnet0,id=net0,mac=52:54:00:a4:6f:91,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,fd=35,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on \ +-device virtio-vga,id=video0,virgl=on,max_outputs=1,bus=pci.0,addr=0x2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on + +And these are the errors I see: + +2020-02-14T09:06:18.183167Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument +2020-02-14T09:10:49.753767Z qemu-system-x86_64: VFIO_MAP_DMA failed: Cannot allocate memory +2020-02-14T09:11:04.530344Z qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device +2020-02-14T09:11:04.531087Z qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device +2020-02-14T09:11:04.531230Z qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device + + +I'm doing nothing with the disk inside the guest, but: + + # dd if=/dev/vda of=/dev/null status=progress + +(the disk appears as /dev/vda in the guest). Surprisingly, I do not see these errors when I use the traditional PCI assignment (-device vfio-pci). My versions of kernel and qemu: + +moe ~ # uname -r +5.4.15-gentoo +moe ~ # /home/zippy/work/qemu/qemu.git/x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 4.2.50 (v4.2.0-1439-g5d6542bea7-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1863441 b/results/classifier/deepseek-2/output/device/1863441 new file mode 100644 index 000000000..ef2727482 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1863441 @@ -0,0 +1,9 @@ + +cmd_mode_sense always reports 0x70, no CDROM present + +cmd_mode_sense + https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/atapi.c;hb=refs/heads/master#l852 +always reports 0x70 in byte 2 returned, indicating no CD-ROM present. + +If CD-ROM is present, should report 0x01 (or 0x11). +If CD-ROM absent, should report 0x70. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1863710 b/results/classifier/deepseek-2/output/device/1863710 new file mode 100644 index 000000000..9f6cce5b5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1863710 @@ -0,0 +1,10 @@ + +qemu 4.2 does not process discard(trim) commands + +I'm using Arch Linux with qemu 4.2 and blktrace to monitor discard commands as they are sent to the hardware. Blktrace shows nothing as the VM is trimming the SSDs. + +I downgraded to qemu 4.1.1 and blktrace shows lots of discard commands as the VM is trimming. + +Kernel version is 5.5.4. + +Attached is the libvirt xml. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1865626 b/results/classifier/deepseek-2/output/device/1865626 new file mode 100644 index 000000000..c323ed5ee --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1865626 @@ -0,0 +1,26 @@ + +s390x guest hang when ipl boot from a mdev dasd + +qemu latest +kernel 5.3.18 + +I am using a passthrough dasd as boot device, the installment looks fine and gets into reboot process. However VM could not boot and just hang as below after that. I have been checking on "s390: vfio-ccw dasd ipl support" series right now but no clue yet. Could anyone take a look for it? Thanks. + + + +s390vsw188:~ # bash test.sh +LOADPARM=[ ] +executing ccw chain at : 0x0000000000000018 +executing ccw chain at : 0x000000000000e000 + +2020-03-01T06:24:56.879314Z qemu-system-s390x: warning: vfio-ccw (devno fe.0.0000): PFCH flag forced + + + +s390zp12:~ # cat test.sh +/root/qemu/s390x-softmmu/qemu-system-s390x \ +-machine s390-ccw-virtio,accel=kvm \ +-nographic \ +-bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \ +-device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,,devno=fe.0.0000,bootindex=1 \ +-global vfio-ccw.force-orb-pfch=yes \ \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1866 b/results/classifier/deepseek-2/output/device/1866 new file mode 100644 index 000000000..dbabc986b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1866 @@ -0,0 +1,2 @@ + +mips/mip64 virtio broken on master (and 8.1.0 with tcg fix) diff --git a/results/classifier/deepseek-2/output/device/1866792 b/results/classifier/deepseek-2/output/device/1866792 new file mode 100644 index 000000000..ac69a5675 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1866792 @@ -0,0 +1,62 @@ + +formating vdi-disk over nbd fails + +Hi, +after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd partitioning works fine, but the system hangs up during formating with mkfs.ext4. + +Same procedure with qcow2-image works fine +Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + + +----------------- +#! /bin/sh + +qemu-img create -f qcow2 ~/test.qcow2 32G +#qemu-img version 4.1.1 (qemu-4.1.1-1.fc31) + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd2 ~/test.qcow2 +#qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31) + +parted -s /dev/nbd2 "mklabel gpt" +parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd2 "p" + +mkfs.ext4 /dev/nbd2p1 +#Format hangs up due to IO errors. +#Tested on Fedora 31, kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_qcow2 + +mount /dev/nbd2p1 /mnt/test_qcow2 +df -H + +------------------- +#! /bin/sh + +qemu-img create -f vdi ~/test.vdi 32G + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd4 ~/test.vdi + +parted -s /dev/nbd4 "mklabel gpt" +parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd4 "p" + +mkfs.ext4 /dev/nbd4p1 +#Format hangs up due to IO errors +#Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_vdi + +mount /dev/nbd4p1 /mnt/test_vdi +df -H +---------------------- + + +Kind regards + Eilert + +PS.: There may be a connection to this bug: + +#1661758 qemu-nbd causes data corruption in VDI-format disk images \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1867519 b/results/classifier/deepseek-2/output/device/1867519 new file mode 100644 index 000000000..ba1b3fc41 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1867519 @@ -0,0 +1,48 @@ + +qemu 4.2 segfaults on VF detach + +After updating Ubuntu 20.04 to the Beta version, we get the following error and the virtual machines stucks when detaching PCI devices using virsh command: + +Error: +error: Failed to detach device from /tmp/vf_interface_attached.xml +error: internal error: End of file from qemu monitor + +steps to reproduce: + 1. create a VM over Ubuntu 20.04 (5.4.0-14-generic) + 2. attach PCI device to this VM (Mellanox VF for example) + 3. try to detaching the PCI device using virsh command: + a. create a pci interface xml file: + + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address type='pci' domain='0x0000' bus='0x11' slot='0x00' function='0x2' /> + </source> + </hostdev> + + b. #virsh detach-device <VM-Doman-name> <pci interface xml file> + + + +- Ubuntu release: + Description: Ubuntu Focal Fossa (development branch) + Release: 20.04 + +- Package ver: + libvirt0: + Installed: 6.0.0-0ubuntu3 + Candidate: 6.0.0-0ubuntu5 + Version table: + 6.0.0-0ubuntu5 500 + 500 http://il.archive.ubuntu.com/ubuntu focal/main amd64 Packages + *** 6.0.0-0ubuntu3 100 + 100 /var/lib/dpkg/status + +- What you expected to happen: + PCI device detached without any errors. + +- What happened instead: + getting the errors above and he VM stuck + +additional info: +after downgrading the libvirt0 package and all the dependent packages to 5.4 the previous, version, seems that the issue disappeared \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1868116 b/results/classifier/deepseek-2/output/device/1868116 new file mode 100644 index 000000000..df47d2fdd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1868116 @@ -0,0 +1,44 @@ + +QEMU monitor no longer works + +It was observed that the QEMU console (normally accessible using Ctrl+Alt+2) accepts no input, so it can't be used. This is being problematic because there are cases where it's required to send commands to the guest, or key combinations that the host would grab (as Ctrl-Alt-F1 or Alt-F4). + +ProblemType: Bug +DistroRelease: Ubuntu 20.04 +Package: qemu 1:4.2-3ubuntu2 +Uname: Linux 5.6.0-rc6+ x86_64 +ApportVersion: 2.20.11-0ubuntu20 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Thu Mar 19 12:16:31 2020 +Dependencies: + +InstallationDate: Installed on 2017-06-13 (1009 days ago) +InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + qemu-system-x86 Sl+ 1000 1000 34275 25235 29.2 qemu-system-x86_64 -m 4G -cpu Skylake-Client -device virtio-vga,virgl=true,xres=1280,yres=720 -accel kvm -device nec-usb-xhci -serial vc -serial stdio -hda /home/usuario/Sistemas/androidx86.img -display gtk,gl=on -device usb-audio + kvm-nx-lpage-re S 0 0 34284 2 0.0 [kvm-nx-lpage-re] + kvm-pit/34275 S 0 0 34286 2 0.0 [kvm-pit/34275] +MachineType: LENOVO 80UG +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc6+ root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet ro kvm.ignore_msrs=1 kvm.report_ignored_msrs=0 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 i915.enable_gvt=1 i915.fastboot=1 cgroup_enable=memory swapaccount=1 zswap.enabled=1 zswap.zpool=z3fold resume=UUID=a82e38a0-8d20-49dd-9cbd-de7216b589fc log_buf_len=16M usbhid.quirks=0x0079:0x0006:0x100000 config_scsi_mq_default=y scsi_mod.use_blk_mq=1 mtrr_gran_size=64M mtrr_chunk_size=64M nbd.nbds_max=2 nbd.max_part=63 +SourcePackage: qemu +UpgradeStatus: Upgraded to focal on 2019-12-22 (87 days ago) +dmi.bios.date: 08/09/2018 +dmi.bios.vendor: LENOVO +dmi.bios.version: 0XCN45WW +dmi.board.asset.tag: NO Asset Tag +dmi.board.name: Toronto 4A2 +dmi.board.vendor: LENOVO +dmi.board.version: SDK0J40679 WIN +dmi.chassis.asset.tag: NO Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo ideapad 310-14ISK +dmi.modalias: dmi:bvnLENOVO:bvr0XCN45WW:bd08/09/2018:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK: +dmi.product.family: IDEAPAD +dmi.product.name: 80UG +dmi.product.sku: LENOVO_MT_80UG_BU_idea_FM_Lenovo ideapad 310-14ISK +dmi.product.version: Lenovo ideapad 310-14ISK +dmi.sys.vendor: LENOVO +mtime.conffile..etc.apport.crashdb.conf: 2019-08-29T08:39:36.787240 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1868617 b/results/classifier/deepseek-2/output/device/1868617 new file mode 100644 index 000000000..a6251231a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1868617 @@ -0,0 +1,16 @@ + +multiseat: route different spice tablet events to distinct vdagents + +docs/multiseat.txt says: + +> Note on spice: Spice handles multihead just fine. But it can't do +> multiseat. For tablet events the event source is sent to the spice +> agent. But qemu can't figure it, so it can't do input routing. +> Fixing this needs a new or extended input interface between +> libspice-server and qemu. For keyboard events it is even worse: The +> event source isn't included in the spice protocol, so the wire +> protocol must be extended to support this. + +I'm not sure exactly what "can't figure it" means, but it looks to me like qemu can't route incoming tablet events from a spice client to distinct vdagent channels. + +I think this part of the process can be fixed within qemu. I've reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to address the issues with the keyboard interface at the protocol level. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1869006 b/results/classifier/deepseek-2/output/device/1869006 new file mode 100644 index 000000000..16af7178e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1869006 @@ -0,0 +1,26 @@ + +PCIe cards passthrough to TCG guest works on 2GB of guest memory but fails on 4GB (vfio_dma_map invalid arg) + +During one meeting coworker asked "did someone tried to passthrough PCIe card to other arch guest?" and I decided to check it. + +Plugged SATA and USB3 controllers into spare slots on mainboard and started playing. On 1GB VM instance it worked (both cold- and hot-plugged). On 4GB one it did not: + +Błąd podczas uruchamiania domeny: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup + self._backend.create() + File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1234, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + + +I played with memory and 3054 MB is maximum value possible to boot VM with coldplugged host PCIe cards. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1869426 b/results/classifier/deepseek-2/output/device/1869426 new file mode 100644 index 000000000..7bf48dd78 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1869426 @@ -0,0 +1,35 @@ + +5.0rc0->4.2 serial migraiton + +Migrating from 5.0rc0->4.2 with pc-q35-4.2 we get an error: + +Unknown savevm section or instance 'serial' 1 + +dumping the migration streams it looks like 5.0 is duplicating the serial migration data: + + "serial (26)": { + "divider": "0x000c", + "rbr": "0x00", + "ier": "0x00", + "iir": "0x01", + "lcr": "0x00", + "mcr": "0x00", + "lsr": "0x60", + "msr": "0xb0", + "scr": "0x00", + "fcr_vmstate": "0x00" + }, + "serial (27)": { + "state": { + "divider": "0x000c", + "rbr": "0x00", + "ier": "0x00", + "iir": "0x01", + "lcr": "0x00", + "mcr": "0x00", + "lsr": "0x60", + "msr": "0xb0", + "scr": "0x00", + "fcr_vmstate": "0x00" + } + }, \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1871270 b/results/classifier/deepseek-2/output/device/1871270 new file mode 100644 index 000000000..9e556c3d0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1871270 @@ -0,0 +1,35 @@ + +[Feature Request] add usbredir device reset blacklist options support to allow macOS guest to iOS device usbredir + +Description of problem: +Currently, when a iOS device is redirected to a macOS VM, it falls into a reset-not-found loop. +Version-Release number of selected component (if applicable): +latest +How reproducible: +100% +Steps to Reproduce: + + +Connect an iOS device to Ubuntu 18.04.2 LTS (I believe it is the same for any distro.) + + +Connect virt-manager/virt-viewer to a macOS VM through SPICE (I am using OSX 10.15 Catalina) + + +Attempt to redirect the iOS device (iPad in my case) to the VM through usb redirection. + + +Actual results: +For any odd number of attempt, the guest macOS will send a reset to the iOS device which causes the host to reset the USB connection in the host side. In the UI, it will be displayed as a successful connection for a few seconds before it disconnects. After this, the iOS device will reconnect itself, but via a different device name /dev/bus/usb/x/y+1. +For any even number of attempt, when I select the iOS device in the virt-manager/virt-viewer UI, the connection will not success and instead a LIBUSB_ERROR_NOT_FOUND error will be provided. Then the UI will reload and get the new device name of the iOS device, falling into the behavior of the aforementioned odd number of attempt. +Expected results: +The macOS detects the iOS device and connects to it happily. +Additional info: +It seems that this bug has been first identified as in https://bugs.freedesktop.org/show_bug.cgi?id=100149, for a Samsung Android device, which the developers of SPICE applied a hotfix in https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirhost/usbredirhost.c#L147. However, there were no settings available for users to fix it. +A similar bug that also consists of a macOS guest/iOS device pair, but instead of being usbredir, is usb-host, has been identified and patched in https://github.com/qemu/qemu/commit/ba4c735b4fc74e309ce4b2551d258e442ef513a5, which is further modified into https://github.com/qemu/qemu/blame/146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8/hw/usb/host-libusb.c#L1486. Following such patch, I have attempted to apply such patch at host-side in https://github.com/michaellee8/qemu/blob/master/hw/usb/redirect.c (not correctly formatted currently, pls ignore it atm), however I discovered that this is not enough since it is also a SPICE issue, which resolves to virt-manager/virt-viewer. +This is probably a cross-project issue between qemu, spice (usbredir) and virt-manager/virt-viewer, which would some effort to coordinate a solution. However a working solution for this problem would probably benefits a lot of users whom relies on connecting a mobile device into a VM, for purposes like easier mobile development. Considering the report for the Samsung Android Device on a PC use case, such issue is probably cross-OS/cross-device. + +cross-references: +- https://bugzilla.redhat.com/show_bug.cgi?id=1821518 +- https://bugzilla.redhat.com/show_bug.cgi?id=1821517 +- https://gitlab.freedesktop.org/spice/usbredir/-/issues/10 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1873338 b/results/classifier/deepseek-2/output/device/1873338 new file mode 100644 index 000000000..172403d3d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1873338 @@ -0,0 +1,6 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1873769 b/results/classifier/deepseek-2/output/device/1873769 new file mode 100644 index 000000000..60b8c2119 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1873769 @@ -0,0 +1,12 @@ + +SB16 audio playback freezes emulation in Windows 95 guest + +- QEMU 4.2.93 (v5.0.0-rc3) built from latest git master 20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and launched on same Windows 10 + +- Launched using "qemu-system-i386.exe -drive format=raw,file=hdd-2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom Windows_95.iso -boot c" + +- I have attached video screen capture of the issue + +--- + +I decided to make my first ever QEMU build after encountering the dsound issues using the latest 4.2.0 binary from https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound playback is working correctly, however the whole Windows 95 UI freezes while sound is playing. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1875080 b/results/classifier/deepseek-2/output/device/1875080 new file mode 100644 index 000000000..12550863a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1875080 @@ -0,0 +1,10 @@ + +USB host device data transfer with control endpoint + +QEMU emulator version 4.2.0 +Host -> Arch Linux kernel version: 5.4.34-1-lts +Guest -> Various Linux Distros + +I sent a control message with data through endpoint zero. +On the other side message is received with all fields correct except data buffer. +I've tested the data field inside guest with usbmon and data field was correct but after packet leaved qemu, data filed is lost. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1877418 b/results/classifier/deepseek-2/output/device/1877418 new file mode 100644 index 000000000..48cadfe05 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1877418 @@ -0,0 +1,7 @@ + +qemu-nbd freezes access to VDI file + +Mounted Oracle Virtualbox .vdi drive, which has GTP+BTRFS: +sudo qemu-nbd -c /dev/nbd0 /storage/btrfs.vdi + +Then I am operating on the btrfs filesystem and suddenly it freezes. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1878136 b/results/classifier/deepseek-2/output/device/1878136 new file mode 100644 index 000000000..59ce188cf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1878136 @@ -0,0 +1,45 @@ + + Assertion failures in ati_reg_read_offs/ati_reg_write_offs + +Hello, +While fuzzing, I found inputs that trigger assertion failures in +ati_reg_read_offs/ati_reg_write_offs + +uint32_t extract32(uint32_t, int, int): Assertion `start >= 0 && length > 0 && length <= 32 - start' failed + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555556e760c0 <str> "start >= 0 && length > 0 && length <= 32 - start", file=0x555556e76120 <str> "/home/alxndr/Development/qemu/include/qemu/bitops.h", line=0x12c, function=0x555556e76180 <__PRETTY_FUNCTION__.extract32> "uint32_t extract32(uint32_t, int, int)") at assert.c:101 +#4 0x000055555653d8a7 in ati_mm_read (opaque=<optimized out>, addr=0x1a, size=<optimized out>) at /home/alxndr/Development/qemu/include/qemu/log-for-trace.h:29 +#5 0x000055555653c825 in ati_mm_read (opaque=<optimized out>, addr=0x4, size=<optimized out>) at /home/alxndr/Development/qemu/hw/display/ati.c:289 +#6 0x000055555601446e in memory_region_read_accessor (mr=0x63100004dc20, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:434 +#7 0x0000555556001a70 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x63100004dc20, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#8 0x0000555556001a70 in memory_region_dispatch_read1 (mr=0x63100004dc20, addr=0x4, pval=<optimized out>, size=0x4, attrs=...) at /home/alxndr/Development/qemu/memory.c:1396 + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000004 0x1 0x1a +readq 0xe2000000 +EOF + +Similarly for ati_reg_write_offs: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000000 0x8 0x6a00000000006a00 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1878253 b/results/classifier/deepseek-2/output/device/1878253 new file mode 100644 index 000000000..f118e5c5c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1878253 @@ -0,0 +1,57 @@ + +null-ptr dereference in address_space_to_flatview through ide + +Hello, +While fuzzing, I found an input that triggers a null-ptr dereference in +address_space_to_flatview through ide: + +==31699==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x55e0f562bafd bp 0x7ffee92355b0 sp 0x7ffee92354e0 T0) +==31699==The signal is caused by a READ memory access. +==31699==Hint: address points to the zero page. + #0 0x55e0f562bafd in address_space_to_flatview /home/alxndr/Development/qemu/include/exec/memory.h:693:12 + #1 0x55e0f562bafd in address_space_write /home/alxndr/Development/qemu/exec.c:3267:14 + #2 0x55e0f562dd9c in address_space_unmap /home/alxndr/Development/qemu/exec.c:3592:9 + #3 0x55e0f5ab8277 in dma_memory_unmap /home/alxndr/Development/qemu/include/sysemu/dma.h:145:5 + #4 0x55e0f5ab8277 in dma_blk_unmap /home/alxndr/Development/qemu/dma-helpers.c:104:9 + #5 0x55e0f5ab8277 in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:139:5 + #6 0x55e0f617a6b8 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1398:9 + #7 0x55e0f617a6b8 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1408:5 + #8 0x55e0f6355efb in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #9 0x55e0f6355efb in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #10 0x55e0f63608ce in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #11 0x55e0f635799a in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #12 0x7f16e85d69ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #13 0x55e0f635e384 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #14 0x55e0f635e384 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #15 0x55e0f635e384 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #16 0x55e0f593d676 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #17 0x55e0f6267c6a in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #18 0x7f16e7186e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #19 0x55e0f55727b9 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x9027b9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/include/exec/memory.h:693:12 in address_space_to_flatview + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc -nographic -drive file=null-co://,if=ide,cache=writeback,format=raw -nodefaults -display none -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80000920 +outl 0xcfc 0xc001 +outl 0xcf8 0x80000924 +outl 0xcf8 0x80000904 +outw 0xcfc 0x7 +outb 0x1f7 0xc8 +outw 0x3f6 0xe784 +outw 0x3f6 0xeb01 +outb 0xc005 0x21 +write 0x2103 0x1 0x4e +outb 0xc000 0x1b +outw 0x1f7 0xff35 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc -nographic -drive file=null-co://,if=ide,cache=writeback,format=raw -nodefaults -display none -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1878255 b/results/classifier/deepseek-2/output/device/1878255 new file mode 100644 index 000000000..c3ba43c52 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1878255 @@ -0,0 +1,39 @@ + +Assertion failure in bdrv_aio_cancel, through ide + +Hello, +While fuzzing, I found an input that triggers an assertion failure in bdrv_aio_cancel, through ide: + +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x0000555556a8d396 in bdrv_aio_cancel (acb=0x607000061290) at /home/alxndr/Development/qemu/block/io.c:2746 +#3 0x0000555556a58525 in blk_aio_cancel (acb=0x2) at /home/alxndr/Development/qemu/block/block-backend.c:1540 +#4 0x0000555556552f5b in ide_reset (s=<optimized out>) at /home/alxndr/Development/qemu/hw/ide/core.c:1318 +#5 0x0000555556552aeb in ide_bus_reset (bus=0x62d000017398) at /home/alxndr/Development/qemu/hw/ide/core.c:2422 +#6 0x0000555556579ba5 in ahci_reset_port (s=<optimized out>, port=<optimized out>) at /home/alxndr/Development/qemu/hw/ide/ahci.c:650 +#7 0x000055555657bd8d in ahci_port_write (s=0x61e000014d70, port=0x2, offset=<optimized out>, val=0x10) at /home/alxndr/Development/qemu/hw/ide/ahci.c:360 +#8 0x000055555657bd8d in ahci_mem_write (opaque=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/ide/ahci.c:513 +#9 0x00005555560028d7 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#10 0x0000555556002280 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x61e000014da0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#11 0x0000555556002280 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x10, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#12 0x0000555555f171d4 in flatview_write_continue (fv=<optimized out>, addr=0xe106c22c, attrs=..., ptr=<optimized out>, len=0x1, addr1=0x7fffffffb8d0, l=<optimized out>, mr=0x61e000014da0) at /home/alxndr/Development/qemu/exec.c:3137 +#13 0x0000555555f0fb98 in flatview_write (fv=0x60600003b180, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe106c000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0x0 0x3 0x2780e7 +write 0xe106c22c 0xd 0x1130c218021130c218021130c2 +write 0xe106c218 0x15 0x110010110010110010110010110010110010110010 +EOF + +I also attached the commands to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1879 b/results/classifier/deepseek-2/output/device/1879 new file mode 100644 index 000000000..5cab46b98 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1879 @@ -0,0 +1,10 @@ + +ARM Cortex-A15 Emulation Not Working +Description of problem: +I want to make a VM with Windows RT 8.1 but it fails because it can't find a file for the to-emulate ARM CPU. +Steps to reproduce: +1. Use virt-manager to make a VM with the ARM architecture. +2. Make sure the emulated CPU is an ARM Cortex-A15. +3. Try installing and making the VM, it will fail with the error. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1880 b/results/classifier/deepseek-2/output/device/1880 new file mode 100644 index 000000000..32ffa9113 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1880 @@ -0,0 +1,14 @@ + +CXL Mem enable error +Description of problem: +During the process of booting, the following info indicate that the CXL Mem is not enabled. +``` +Media not active (-16) +probe of mem0 failed with error -16 +``` +Steps to reproduce: +1. Compile Linux kernel v5.18 as shown in the QEMU doc +2. Run the above-mentioned script +3. Check the booting script +Additional information: +Could you give me some hints of how to operate on the CXL device properly? Thanks a lot. diff --git a/results/classifier/deepseek-2/output/device/1880424 b/results/classifier/deepseek-2/output/device/1880424 new file mode 100644 index 000000000..7aa5c317f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1880424 @@ -0,0 +1,41 @@ + +I/O write make imx_epit_reset() crash + +libFuzzer found: + +qemu-fuzz-arm: hw/core/ptimer.c:377: void ptimer_transaction_begin(ptimer_state *): Assertion `!s->in_transaction' failed. +==6041== ERROR: libFuzzer: deadly signal + #8 0x7fcaba320565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x563b46f91637 in ptimer_transaction_begin (qemu-fuzz-arm+0x1af1637) + #10 0x563b476cc4c6 in imx_epit_reset (qemu-fuzz-arm+0x222c4c6) + #11 0x563b476cd004 in imx_epit_write (qemu-fuzz-arm+0x222d004) + #12 0x563b46582377 in memory_region_write_accessor (qemu-fuzz-arm+0x10e2377) + #13 0x563b46581ee3 in access_with_adjusted_size (qemu-fuzz-arm+0x10e1ee3) + #14 0x563b46580a83 in memory_region_dispatch_write (qemu-fuzz-arm+0x10e0a83) + #15 0x563b463c5022 in flatview_write_continue (qemu-fuzz-arm+0xf25022) + #16 0x563b463b4ea2 in flatview_write (qemu-fuzz-arm+0xf14ea2) + #17 0x563b463b49d4 in address_space_write (qemu-fuzz-arm+0xf149d4) + +Reproducer: + +qemu-system-arm -M kzm -display none -S -qtest stdio << 'EOF' +writel 0x53f94000 0x110000 +EOF + +qemu-system-arm: hw/core/ptimer.c:377: ptimer_transaction_begin: Assertion `!s->in_transaction' failed. +Aborted (core dumped) + +(gdb) bt +#1 0x00007f4aa4daa895 in abort () at /lib64/libc.so.6 +#2 0x00007f4aa4daa769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f4aa4db8566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x000055ee85400164 in ptimer_transaction_begin (s=0x55ee873bc4c0) at hw/core/ptimer.c:377 +#5 0x000055ee855c7936 in imx_epit_reset (dev=0x55ee871725c0) at hw/timer/imx_epit.c:111 +#6 0x000055ee855c7d1b in imx_epit_write (opaque=0x55ee871725c0, offset=0, value=1114112, size=4) at hw/timer/imx_epit.c:209 +#7 0x000055ee8513db85 in memory_region_write_accessor (mr=0x55ee871728f0, addr=0, value=0x7fff3012d6f8, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:483 +#8 0x000055ee8513dd96 in access_with_adjusted_size (addr=0, value=0x7fff3012d6f8, size=4, access_size_min=1, access_size_max=4, access_fn= + 0x55ee8513daa2 <memory_region_write_accessor>, mr=0x55ee871728f0, attrs=...) at memory.c:545 +#9 0x000055ee85140cbd in memory_region_dispatch_write (mr=0x55ee871728f0, addr=0, data=1114112, op=MO_32, attrs=...) at memory.c:1477 +#10 0x000055ee850deba5 in flatview_write_continue (fv=0x55ee87181bd0, addr=1408843776, attrs=..., ptr=0x7fff3012d900, len=4, addr1=0, l=4, mr=0x55ee871728f0) at exec.c:3147 +#11 0x000055ee850decf3 in flatview_write (fv=0x55ee87181bd0, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3190 +#12 0x000055ee850df05d in address_space_write (as=0x55ee8730a560, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3289 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1880822 b/results/classifier/deepseek-2/output/device/1880822 new file mode 100644 index 000000000..85063613f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1880822 @@ -0,0 +1,4 @@ + +CVE-2020-13253 QEMU: sd: OOB access could crash the guest resulting in DoS + +An out-of-bounds read access issue was found in the SD Memory Card emulator of the QEMU. It occurs while performing block write commands via sdhci_write(), if a guest user has sent 'address' which is OOB of 's->wp_groups'. A guest user/process may use this flaw to crash the QEMU process resulting in DoS. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1881231 b/results/classifier/deepseek-2/output/device/1881231 new file mode 100644 index 000000000..ba97c8a94 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1881231 @@ -0,0 +1,32 @@ + +colo: Can not recover colo after svm failover twice + +Hi Expert, +x-blockdev-change met some error, during testing colo + +Host os: +CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm and remove the nbd child from the quorum to wait for recover + type those commands on primary vm console: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} +3. recover colo +4. kill secondary vm again after recover colo and type same commands as step 2: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} + but the first command got error + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} +{"error": {"class": "GenericError", "desc": "Node 'colo-disk0' does not have child 'children.1'"}} + +according to https://www.qemu.org/docs/master/qemu-qmp-ref.html +Command: x-blockdev-change +Dynamically reconfigure the block driver state graph. It can be used to add, remove, insert or replace a graph node. Currently only the Quorum driver implements this feature to add or remove its child. This is useful to fix a broken quorum child. + +It seems x-blockdev-change not worked as expected. + +Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1882350 b/results/classifier/deepseek-2/output/device/1882350 new file mode 100644 index 000000000..55a52cb51 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1882350 @@ -0,0 +1,37 @@ + +it always create sdx device when I configure ide device with hdx name + +I have configured 2 ide disks with name starting with hd, but when the vm boots up, it shows disks whose name starting with sd. + +1. ide disks in vm xml: + + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/data3_raw.qcow2'/> + <target dev='hdc' bus='ide'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/data2.qcow2'/> + <target dev='hdb' bus='ide'/> + </disk> + + +2. in VM: + +sda 8:0 0 2G 0 disk +sdb 8:16 0 1G 0 disk + + +3. from vm.log: + +le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev t + + +4. rpm info: (I got the same issue on 2 diff envs) +(1) env1 +qemu-kvm-1.5.3-105 +libvirt-3.2.0-14.el7 +(2) env2 +libvirt-5.9.0-1.el8 +qemu-4.1.0-1.el8 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1882787 b/results/classifier/deepseek-2/output/device/1882787 new file mode 100644 index 000000000..7310ae0eb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1882787 @@ -0,0 +1,59 @@ + +AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut + +There was a change in https://github.com/qemu/qemu/commit/571a8c522e0095239598347ac0add93337c1e0bf#diff-230ab01fa7fb1668a1e9183241115cb0R1852-R1853 (audio/audio.c) which breaks audio output on devices which have multiple software voices on the same hardware voice. + +When multiple software voices use the same hardware voice, then setting a volume / mute for any of the software voices, will affect all other software voices, too. + +I'm not sure if such a use-case exists in QEMU; however, it does exist in my fork. +It's also easy to see that this is a bug in the QEMU audio subsystem. + +The API (and broken function) for this is: + +``` + void AUD_set_volume_out (SWVoiceOut *sw, int mute, uint8_t lvol, uint8_t rvol) +``` + +So this is supposed to modify the SWVoiceOut. + +However, if the backend supports `pcm_ops->volume_out` this does not work as expected. It's always as if you had called: + +``` + void AUD_set_volume_out (HWVoiceOut *hw, int mute, uint8_t lvol, uint8_t rvol) +``` + +*(Note how this modifies the hardware voice)* + + +In my specific use case, I have 2 outputs (digital and analog audio on AC97), and I want to mute the digital audio output, but I still need to keep the voice activated for timing. +However, if I mute the digital audio SWVoiceOut, it will also affect the other SWVoiceOut (for analog audio) on the same HWVoiceOut. + +--- + +Old code - if the hardware supports volume changes, it will receive the software voice which should be modified, so changes can be restricted to that one voice: + +``` + HWVoiceOut *hw = sw->hw; + [...] + if (hw->pcm_ops->ctl_out) { + hw->pcm_ops->ctl_out (hw, VOICE_VOLUME, sw); + } +``` + +New code - the hardware backend will have no way to differentiate software voices; so any change will affect all voices. The volume which was set last on any sw voice will set a global volume / mute for all voices on the hardware backend: + +``` + HWVoiceOut *hw = sw->hw; + [...] + if (hw->pcm_ops->volume_out) { + hw->pcm_ops->volume_out(hw, &sw->vol); + } +``` + +The old interface was already broken with some (all?) backends, because they ignored the software voice, but at least the design made sense. +However, the new design is fundamentally broken because it doesn't even tell the backend which voice is supposed to be modified. + +--- + +Bug was introduced in cecc1e79bf9ad9a0e2d3ce513d4f71792a0985f6 +The affected code was touched since then, but still remains in 49ee11555262a256afec592dfed7c5902d5eefd2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1883729 b/results/classifier/deepseek-2/output/device/1883729 new file mode 100644 index 000000000..3677507f3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1883729 @@ -0,0 +1,16 @@ + +xhci_find_stream: Assertion `streamid != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1883732 b/results/classifier/deepseek-2/output/device/1883732 new file mode 100644 index 000000000..1cdb445a4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1883732 @@ -0,0 +1,16 @@ + +xhci_kick_epctx: Assertion `ring->dequeue != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1883733 b/results/classifier/deepseek-2/output/device/1883733 new file mode 100644 index 000000000..6962952a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1883733 @@ -0,0 +1,16 @@ + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1884169 b/results/classifier/deepseek-2/output/device/1884169 new file mode 100644 index 000000000..534de920b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1884169 @@ -0,0 +1,6 @@ + +There is no option group 'fsdev' for OSX + +When I try to use -fsoption on OSX I receive this error: + +-fsdev local,security_model=mapped,id=fsdev0,path=devel/dmos-example: There is no option group 'fsdev' \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1884684 b/results/classifier/deepseek-2/output/device/1884684 new file mode 100644 index 000000000..f46c1eb87 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1884684 @@ -0,0 +1,40 @@ + +QEMU 5.0: Guest VM hangs/freeze when unplugging USB device + +Setup: + +Host: Debian/SID, Kernel 5.6, QEMU 5.0 +Guest: Windows 10 VM with PCI and USB device passthrough. + +Problem: Guest VM suddenly hangs when pulling USB device out from the Host. + +Observations: + - Issue appears to be related to QEMU 5.0 + - It started after an upgrade to QEMU 5.0. + - Downgrading only QEMU on multiple systems fixes the issue. + + - Issue is very reproducible. + - Most of the time within a few attempts of pulling/reconnecting the device. + - Issue happens with multiple devices (I did try standard HID devices, a webcam and an x-ray sensor). + + - Guest just hangs. + - Display output remains on last frame shown. + - Ping to Guest immediately stops working. + - Logs in the Guest stop logging immediately. + + - Host is fine and thinks the Guest is fine. + - Guest continues to show as running in "virsh list". + - No suspicious entries in the QEMU logs. + - No suspicious entries in Host syslogs/messages. + - Host can can kill guest "virsh destroy" and respawn fine. + + - Issue seems widespread. + - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 for both Windows and Linux guests (First version that uses QEMU 5.0) + +https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/ +https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/ +https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/ + +I'd be more than happy any debugs that might be helpful. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1884693 b/results/classifier/deepseek-2/output/device/1884693 new file mode 100644 index 000000000..92b47a53f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1884693 @@ -0,0 +1,56 @@ + +Assertion failure in address_space_unmap through ahci_map_clb_address + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe1068000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0xe1068304 0x1 0x21 +write 0xe1068318 0x1 0x21 +write 0xe1068384 0x1 0x21 +write 0xe1068398 0x2 0x21 +EOF + +Stack trace: +#0 0x55bfabfe9ea0 in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +#1 0x55bfabfc8ef9 in __sanitizer_print_stack_trace (build/i386-softmmu/qemu-fuzz-i386+0x7b7ef9) +#2 0x55bfabfaf933 in fuzzer::PrintStackTrace() FuzzerUtil.cpp:210:5 +#3 0x7f88df76110f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1410f) +#4 0x7f88df5a4760 in __libc_signal_restore_set /build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10 +#5 0x7f88df5a4760 in raise /build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7f88df58e55a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7 +#7 0x7f88df58e42e in __assert_fail_base /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:92:3 +#8 0x7f88df59d091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +#9 0x55bfabff7182 in address_space_unmap exec.c:3602:9 +#10 0x55bfac4a452f in dma_memory_unmap include/sysemu/dma.h:148:5 +#11 0x55bfac4a452f in map_page hw/ide/ahci.c:254:9 +#12 0x55bfac4a1f98 in ahci_map_clb_address hw/ide/ahci.c:748:5 +#13 0x55bfac4a1f98 in ahci_cond_start_engines hw/ide/ahci.c:276:14 +#14 0x55bfac4a074e in ahci_port_write hw/ide/ahci.c:339:9 +#15 0x55bfac4a074e in ahci_mem_write hw/ide/ahci.c:513:9 +#16 0x55bfac0e0dc2 in memory_region_write_accessor memory.c:483:5 +#17 0x55bfac0e0bde in access_with_adjusted_size memory.c:544:18 +#18 0x55bfac0e0917 in memory_region_dispatch_write memory.c +#19 0x55bfabffa4fd in flatview_write_continue exec.c:3146:23 +#20 0x55bfabff569b in flatview_write exec.c:3186:14 +#21 0x55bfabff569b in address_space_write exec.c:3280:18 +#22 0x55bfac8982a9 in op_write_pattern tests/qtest/fuzz/general_fuzz.c:407:5 +#23 0x55bfac897749 in general_fuzz tests/qtest/fuzz/general_fuzz.c:481:17 +#24 0x55bfac8930a2 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:136:5 +#25 0x55bfabfb0e68 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:558:15 +#26 0x55bfabfb0485 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) FuzzerLoop.cpp:470:3 +#27 0x55bfabfb18a1 in fuzzer::Fuzzer::MutateAndTestOne() FuzzerLoop.cpp:701:19 +#28 0x55bfabfb2305 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:837:5 +#29 0x55bfabfa2018 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:846:6 +#30 0x55bfabfb8722 in main FuzzerMain.cpp:19:10 +#31 0x7f88df58fe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +#32 0x55bfabf97869 in _start (build/i386-softmmu/qemu-fuzz-i386+0x786869) + +The same error can be triggered through ahci_map_fis_address @ hw/ide/ahci.c:721:5 +Found with generic device fuzzer: https://<email address hidden>/ + +Please let me know if I can provide any further info. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1884831 b/results/classifier/deepseek-2/output/device/1884831 new file mode 100644 index 000000000..fa87312da --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1884831 @@ -0,0 +1,22 @@ + +qemu-nbd fails to discard bigger chunks + +This report is moved from systemd to here: +https://github.com/systemd/systemd/issues/16242 + +A qemu-nbd device reports that it can discard a lot of bytes: + +cat /sys/block/nbd0/queue/discard_max_bytes +2199023255040 + +And indeed, discard works with small images: + +$ qemu-img create -f qcow2 /tmp/image.img 2M +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 + +but not for bigger ones (still smaller than discard_max_bytes): + +$ qemu-img create -f qcow2 /tmp/image.img 5G +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1885 b/results/classifier/deepseek-2/output/device/1885 new file mode 100644 index 000000000..8714aed37 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1885 @@ -0,0 +1,25 @@ + +mipsel malta machine is broken in avocado console tests +Description of problem: +As noted in #1884 we see failures of the boot_linux_console.py test. Unlikely other avocado failures, these ones are consistent and reproduce locally with 100% success + +``` +./configure --target-list=mipsel-softmmu +make -j 20 +cd build +./pyvenv/bin/python3 -B -m avocado --show=app run --job-results-dir=./tests/results -t arch:mipsel --failfast tests/avocado/boot_linux_console.py:BootLinuxConsole.test_mips_malta32el_nanomips_4k +``` + +This test will reliably fail with a timeout waiting for console output. + +Attempting to run the QEMU command manually + +``` +$ ./qemu-system-mipsel -display none -vga none -machine malta -chardev stdio,id=console -serial chardev:console -cpu I7200 -no-reboot -kernel /home/berrange/src/virt/qemu/build/tests/results/job-2023-09-13T17.14-77de093/test-results/tmp_dir520smana/1-tests_avocado_boot_linux_console.py_BootLinuxConsole.test_mips_malta32el_nanomips_4kkernel -append 'printk.time=0 mem=256m@@0x0 console=ttyS0' +``` + +results in no serial console output at all. + +IMHO either the MIPS malta machine has had a regression, or the kernel we're downloading for testing has had a regression. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1887641 b/results/classifier/deepseek-2/output/device/1887641 new file mode 100644 index 000000000..4d5b7c7db --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1887641 @@ -0,0 +1,8 @@ + +PCI bus not available for hda + +I'm trying to boot Mac OS 9.2.2 image in order to install it on a qcow disk image. I'm using Linux Mint MATE 20 and QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.3). When I boot, I've got this error message and boot fails : + +$ /usr/bin/qemu-system-ppc -monitor stdio -soundhw hda -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -drive file="/home/david/.aqemu/iMacG3_hard_disk_HDA.img",if=ide,index=0 -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 +QEMU 4.2.0 monitor - type 'help' for more information +(qemu) qemu-system-ppc: PCI bus not available for hda \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1887745 b/results/classifier/deepseek-2/output/device/1887745 new file mode 100644 index 000000000..2b1646183 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1887745 @@ -0,0 +1,26 @@ + +call-method block-size failed with error ffffffdf + +I start Debian 10 PowerPC version in QEMU with this command : + +/usr/bin/qemu-system-ppc -monitor stdio -M mac99 -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -hda /home/david/Documents/Informatique et téléphone/Documentation informatique/Macintosh/Debian_10_LXDE -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 + +GRUB menu appears. Then, I choose "Default install", the screen is cleaned and "Loading..." appears. But after, nothing happens and I've got this error message : + +C>> annot manage 'undefined' PCI device type '<NULL>': +>> 1af4 1009 (0 2 0) + +>> ============================================================= +>> OpenBIOS 1.1 [Mar 12 2020 14:02] +>> Configuration device id QEMU version 1 machine id 1 +>> CPUs: 1 +>> Memory: 512M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,G4 +milliseconds isn't unique. +>> switching to new context: +>> call-method block-size failed with error ffffffdf +>> call-method block-size failed with error ffffffdf + + +I found this post, I don't know if it could help... : https://lists.gnu.org/archive/html/grub ... 00001.html \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1888417 b/results/classifier/deepseek-2/output/device/1888417 new file mode 100644 index 000000000..ccfcea242 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1888417 @@ -0,0 +1,6 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1888663 b/results/classifier/deepseek-2/output/device/1888663 new file mode 100644 index 000000000..76ac36475 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1888663 @@ -0,0 +1,14 @@ + +msmouse not recognized in guest + +The msmouse option for emulating a serial mouse does not seem to work in a DOS guest. + +I'm on Windows 10 X64, I have tried launching qemu (commit d0cc248164961a7ba9d43806feffd76f9f6d7f41 but also way older) with: +./qemu-system-i386 -serial msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device pci-serial,chardev=msmouse -chardev msmouse,id=msmouse -fda mousetest.img + +Then I boot FreeDOS (but regular DOS shows same behavior), start the CuteMouse driver and force the scan of a serial mouse with CTM /S. +The mouse is never found. With other drivers (in the attachment), the mouse is probably not found but the driver is installed anyway, but it does not work (there's a MOUSETST in the same floppy; it works iwth CTM and PS/2 mouse emulation). + +Using a serial port sniffer inside the guest, it would seem that data is indeed transmitted. Setting a few printf in msmouse.c also confirms that the mouse gets initilized and starts transmitting data. However, it does not work... \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1889 b/results/classifier/deepseek-2/output/device/1889 new file mode 100644 index 000000000..2095036d8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1889 @@ -0,0 +1,48 @@ + +IO delays on live migration lv initialization +Description of problem: +Hi, + +When I live migrate a VM via Proxmox and the destination is an LVM thin pool I see that at the start of copying the disk it's first initialized. + +This leads the thin volume to be directly 100% allocated which needs to be discarded afterwards. Not ideal but .... + +The more annoying thing is that this initialization step used 100% of disk IO. In iotop I see it writing over 1000MB/sec. The nasty side effect is that other VM's on that host are negatively affected. It's not completely locked up, I can ssh in and look around, but storage intensive things see more delay. With e.g. http requests timing out. And even a simple ls command could take 10+ seconds which is normally instant. + + +I've previously reported it on the [proxmox forum](https://forum.proxmox.com/threads/io-delays-on-live-migration-lv-initialization.132296/#post-582050) but the call was made that this is behavior from Qemu. + +> The zeroing happens, because of what QEMU does when the discard option is enabled: + + +When I disable discard for the VM disk I can see that it's not pre-initialized during migration, but not having that defeats the purpose of having an lvm thin pool. + +For the (disk) migration itself I can set a bandwidth limit ... could we do something similar for initialization? + + +Even better would be to not initialize at all when using LVM thin. As far as I understand it the new blocks allocated by lvm thin should always be empty. +Steps to reproduce: +1. Migrate a vm with a large disk +2. look in iotop on the new host, would be see more write IO then the network could handle.. just before the disk content is transferred. +3. look in another VM on the destination host, reading from disk would be significantly slower then normal. +Additional information: +An example VM config +``` +agent: 1,fstrim_cloned_disks=1 +balloon: 512 +bootdisk: scsi0 +cores: 6 +ide2: none,media=cdrom +memory: 8196 +name: ... +net0: virtio=...,bridge=... +numa: 0 +onboot: 1 +ostype: l26 +scsi0: thin_pool_hwraid:vm-301-disk-0,discard=on,format=raw,size=16192M +scsi1: thin_pool_hwraid:vm-301-disk-1,discard=on,format=raw,size=26G +scsihw: virtio-scsi-pci +serial0: socket +smbios1: uuid=... +sockets: 1 +``` diff --git a/results/classifier/deepseek-2/output/device/1890152 b/results/classifier/deepseek-2/output/device/1890152 new file mode 100644 index 000000000..28711b6b8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1890152 @@ -0,0 +1,56 @@ + +malloc 0xff0000030 bytes with vmxnet3 + +Hello, +This reproducer causes vmxnet3 to malloc 0xff0000030 bytes + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x3e 0x1 0x05 +write 0x28 0x1 0xe1 +write 0x29 0x1 0xfe +write 0x2a 0x1 0xff +write 0x2b 0x1 0xff +write 0x2c 0x1 0xff +write 0x2d 0x1 0xff +write 0x2e 0x1 0xff +write 0x2f 0x1 0xff +write 0x31c 0x1 0xff +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + + + +================================================================= +==25727==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0xff0000030 bytes + #0 0x56476a43731d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/i386-softmmu/qemu-system-i386+0x2bba31d) + #1 0x7fca345a8500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x56476c616312 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1504:5 + #3 0x56476c6101ba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #4 0x56476c60d30f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #5 0x56476b11d383 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #6 0x56476b11c827 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x56476b11a446 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #8 0x56476a4cb696 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x56476a4b3eb6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x56476a4b39d7 in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x56476b1c4614 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #12 0x56476b1bbc18 in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x56476b1ba8a5 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x56476e063f03 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x56476e064087 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x56476e078373 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x56476e1cc734 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7fca345a2897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + + +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1890311 b/results/classifier/deepseek-2/output/device/1890311 new file mode 100644 index 000000000..d411d86fe --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1890311 @@ -0,0 +1,51 @@ + +Segfault in cpu_physical_memory_set_dirty_range on hppa + artist + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf810049f 0x85000000000000 +writew 0xf8118001 0x14 +writeq 0xf81005fb 0x5c00006418001832 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb40000 (pc 0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0) +==10793==The signal is caused by a READ memory access. + + #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13 + #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x5577f4c04873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23 + #6 0x5577f429a866 in flatview_write /exec.c:3216:14 + #7 0x5577f429a387 in address_space_write /exec.c:3308:18 + #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x5577f72c9474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f93ea531897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x5577f7301261 in main /softmmu/main.c:49:5 + #21 0x7f93e90b7e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x5577f41a5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==10793==ABORTING + + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1890333 b/results/classifier/deepseek-2/output/device/1890333 new file mode 100644 index 000000000..f58d60e19 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1890333 @@ -0,0 +1,24 @@ + +[OSS-Fuzz] Issue 26797: qemu:qemu-fuzz-i386-target-generic-fuzz-virtio-blk: ASSERT: addr < cache->len && 2 <= cache->len - addr + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001001 +outl 0xcfc 0x6574c1ff +outl 0xcf8 0x8000100e +outl 0xcfc 0xefe5e1e +outl 0xe86 0x3aff9090 +outl 0xe84 0x3aff9090 +outl 0xe8e 0xe +EOF + +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +Aborted + +I can trigger similar assertions with other VIRTIO devices, as-well. +I reported this at some point in Message-ID: <email address hidden> but never created a Launchpad issue... +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1890360 b/results/classifier/deepseek-2/output/device/1890360 new file mode 100644 index 000000000..9e670c156 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1890360 @@ -0,0 +1,71 @@ + +Assertion failure in address_space_unmap through virtio-blk + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc001 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xc006 0x3aff9090 +outl 0xcf8 0x8000100e +outl 0xcfc 0x41005e1e +write 0x3b00002 0x1 0x5e +write 0x3b00004 0x1 0x5e +write 0x3aff5e6 0x1 0x11 +write 0x3aff5eb 0x1 0xc6 +write 0x3aff5ec 0x1 0xc6 +write 0x7 0x1 0xff +write 0x8 0x1 0xfb +write 0xc 0x1 0x11 +write 0xe 0x1 0x5e +write 0x5e8 0x1 0x11 +write 0x5ec 0x1 0xc6 +outl 0x410e 0x10e +EOF + + +qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +==789== ERROR: libFuzzer: deadly signal + #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 in address_space_unmap /exec.c:3623:9 + #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 + #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 + #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 + #13 in virtqueue_push /hw/virtio/virtio.c:917:5 + #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 + #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 + #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 + #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 + #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 + #19 in aio_dispatch_handler /util/aio-posix.c:328:9 + #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 + #21 in aio_dispatch /util/aio-posix.c:381:5 + #22 in aio_ctx_dispatch /util/async.c:306:5 + #23 in g_main_context_dispatch + + +With -trace virtio\* + +... +[S +0.099667] OK +[R +0.099681] write 0x5ec 0x1 0xc6 +OK +[S +0.099690] OK +[R +0.099700] outl 0x410e 0x10e +29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +OK +[S +0.099833] OK +29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. + + +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1890775 b/results/classifier/deepseek-2/output/device/1890775 new file mode 100644 index 000000000..f13f69e62 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1890775 @@ -0,0 +1,15 @@ + +Aten USB to Serial bridge does not work with qemu under Windows 10 + +I would like to use MSDOS 6.22 with qemu (unfortunatelly lot of our test programs has been written in dos). +I tried to connect two laptop by RS232 port, one of the machine have a built-in serial port and run with native MSDOS 6.22 with 4.0 norton commander. Another machine have only USB ports and i try to use a new Aten USB to Serial device. Ok. Has been started qemu with -serial and -chardev parameters, at startup appear a window with serial port setting such as baud rate, start bit, etc... + +Quemu has been satrted succeeded but serial port cannot be used becouse was nothing activited on usb serial adapter :( + +I tried same configuration with VirtualBox and everything was worked fine (serial connection was estabiled and copied several files from one machine into another machine), seems to be the emulated serial port has been worked fine. + +I would like to use qemu, i just thougt qemu is better, simple and faster... + +Exists solution or is this a qemu bug? + +Thank you! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1891830 b/results/classifier/deepseek-2/output/device/1891830 new file mode 100644 index 000000000..0c8f6e68a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1891830 @@ -0,0 +1,35 @@ + +msmouse serial mouse emulation broken? No id byte sent on reset + +I took a shot at getting Windows 1.01 working. It doesn't support a PS/2 mouse out-of-the-box but does support MS serial mice. It doesn't seem to detect qemu's emulated msmouse. + +When I run this command: + +> qemu-system-i386 -nodefaults -hda my_windows1_hd.qcow2 -vga std -serial msmouse -trace enable='serial*' -icount shift=10,align=on + +I get this output (edited): + +251908@1597626456.800452:serial_ioport_write write addr 0x04 val 0x01 +251908@1597626456.800460:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.800462:serial_ioport_read read addr 0x00 val 0x00 + +[snip] + +251908@1597626456.961641:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961642:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961644:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961647:serial_ioport_write write addr 0x04 val 0x0b +251908@1597626456.961648:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961684:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961685:serial_ioport_read read addr 0x05 val 0x60 + +[snip] + +251908@1597626457.045894:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045895:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045897:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045932:serial_ioport_read read addr 0x00 val 0x00 + +The write of 0x01 and then 0x0b to reg 0x04 is the guest turning the RTS line off then on. A real mouse will respond to this by sending 0x4d, which is how the guest detects the mouse. + +Reproducible in current stable-4.2 and 5.0 (debian's build). I am able to get the guest to use a real passed-through serial mouse (with a minor hack, separate bug filed for this) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1892 b/results/classifier/deepseek-2/output/device/1892 new file mode 100644 index 000000000..dabb94e17 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1892 @@ -0,0 +1,34 @@ + +docs/system/devices/cxl.rst suggests qemu-system-aarch64 command lines which fail with "Property 'virt-8.2-machine.cxl' not found" +Description of problem: +When trying to run qemu-system-aarch64 with "-M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max", get the following problem: +"qemu-system-aarch64: Property 'virt-8.2-machine.cxl' not found". Do I need to compile the QEMU with specific option? +Steps to reproduce: +1. Compile QEMU with "./config" "make -j6" +2. Compile Linux +``` +#!/bin/bash + +KERNEL_PATH=/users/LiuQun/linux/arch/arm64/boot/Image +DISK_IMG=/users/LiuQun/ARM_img/disk-image-22.04-server-arm64.img + +./build/qemu-system-aarch64 \ +-M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \ +-bios /users/LiuQun/ARM_img/QEMU_EFI.fd \ +-kernel $KERNEL_PATH \ +-drive file=$DISK_IMG,format=raw,if=none,id=drive-sata0-0-0 \ +-device virtio-blk-device,drive=drive-sata0-0-0 \ +-append "console=ttyAMA0 root=/dev/vda1 rdinit=/init acpi=off" \ +-object memory-backend-file,id=cxl-mem1,share=on,mem-path=cxl-window1,size=512M \ +-object memory-backend-file,id=cxl-label1,share=on,mem-path=cxl-label1,size=1K \ +-object memory-backend-file,id=cxl-label2,share=on,mem-path=cxl-label2,size=1K \ +-device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,window-base[0]=0x4c00000000,memdev[0]=cxl-mem1 \ +-device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0,port=0 \ +-device cxl-rp,id=rp1,bus=cxl.0,addr=1.0,chassis=0,slot=1,port=1 \ +-device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M,lsa=cxl-label1 \ +-device cxl-type3,bus=rp1,memdev=cxl-mem1,id=cxl-pmem1,size=256M,lsa=cxl-label2 \ +-nographic + +``` +Additional information: +The same problem happens with QEMU 8.1 diff --git a/results/classifier/deepseek-2/output/device/1892581 b/results/classifier/deepseek-2/output/device/1892581 new file mode 100644 index 000000000..e904367e8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1892581 @@ -0,0 +1,43 @@ + +QEMU 5.1 no longer says anything about inaccessible devices + +Previously, with QEMU 5.0.0 running a VM with the following command: + +$ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio + +Would display something like the following: + +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. + +With insufficient permissions. + +QEMU 5.1.0 no longer displays anything. + +I did a git bisect and this is the result: + +[diego@thinkpad qemu]$ git bisect bad +9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit +commit 9f815e83e983d247a3cd67579d2d9c1765adc644 +Author: Gerd Hoffmann <email address hidden> +Date: Fri Jun 5 14:59:52 2020 +0200 + + usb: add hostdevice property to usb-host + + The new property allows to specify usb host device name. Uses standard + qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) + and file descriptor passing can be used. + + Requires libusb 1.0.23 or newer. The hostdevice property is only + present in case qemu is compiled against a new enough library version, + so the presence of the property can be used for feature detection. + + Signed-off-by: Gerd Hoffmann <email address hidden> + Message-Id: <email address hidden> + + hw/usb/host-libusb.c | 75 ++++++++++++++++++++++++++++++++++++++++++---------- + hw/usb/trace-events | 1 + + 2 files changed, 62 insertions(+), 14 deletions(-) +[diego@thinkpad qemu]$ \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1892761 b/results/classifier/deepseek-2/output/device/1892761 new file mode 100644 index 000000000..ece5485a4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1892761 @@ -0,0 +1,11 @@ + +Heap-use-after-free through double-fetch in ehci + +Hello, +I don't have a qtest reproducer for this crash because it involves a DMA double-fetch, and I don't think we can reproduce those with qtest. + +Instead, I attached the pseudo-qtest trace produced by the fuzzer, along with some trace events. +The lines annotated with [DMA] are write commands that were triggered by a callback from a DMA read by the device. The lines annotated with [DOUBLE-FETCH] are DMA accesses that hit the same address more than once (possible double-fetches). + +I am still thinking of nicer ways of presenting this trace and providing a reproducer. +-Alex \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1893 b/results/classifier/deepseek-2/output/device/1893 new file mode 100644 index 000000000..941f49f12 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1893 @@ -0,0 +1,14 @@ + +assert on savevm +Description of problem: + +Steps to reproduce: +1. launch as above (n.b. qemu-img command: qemu-img create -f qcow2 rootfs.qcow2 60G +2. from qemu monitor: savevm test +3. On stderr + +``` +Assertion failed: (qemu_get_current_aio_context() == qemu_get_aio_context()), function bdrv_poll_co, file block-gen.h, line 43. +``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1893634 b/results/classifier/deepseek-2/output/device/1893634 new file mode 100644 index 000000000..b91759e77 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1893634 @@ -0,0 +1,11 @@ + +blk_get_max_transfer() works only with sg + +blk_get_max_transfer() is supposed to be able to get the max_sectors queue limit of the scsi device on the host side and is used in both scsi-generic.c (for scsi-generic and scsi-block) and scsi-disk.c (for scsi-hd) to set/change the max_xfer_len (and opt_xfer_len in the case of scsi-generic). + +However, it only works with the sg driver in doing so. It cannot get the queue limit with the sd driver and simply returns MAX_INT. + +qemu version 5.1.0 +kernel version 5.8.5 + +Btw, is there a particular reason that it doesn't MIN_NON_ZERO against the original max_xfer_len: https://github.com/qemu/qemu/blob/v5.1.0/hw/scsi/scsi-generic.c#L172? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1894 b/results/classifier/deepseek-2/output/device/1894 new file mode 100644 index 000000000..7e3313dff --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1894 @@ -0,0 +1,12 @@ + +Can't emulate audio with OpenCore Mac OS X 10.7 +Description of problem: +OpenCore wants me to use `AppleALC`, but to use _that_, I need the layout ID of the motherboard or something and I'm not sure how I'd do that since it's a QEMU VM. All I want to do is have some audio :( + +So, how can I emulate audio with AppleALC + OpenCore/how can I get a layout ID that'll give me audio on a QEMU VM? Do note that I am using UTM (https://getutm.app/) (UTM uses QEMU and is basically a QEMU frontend). +Steps to reproduce: +1. Set up OpenCore and install Mac OS X 10.7 +2. Copy across a .mp3 file +3. iTunes fails to play it due to no audio drivers/audio outputs +Additional information: +N/A diff --git a/results/classifier/deepseek-2/output/device/1894071 b/results/classifier/deepseek-2/output/device/1894071 new file mode 100644 index 000000000..0c87287b9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1894071 @@ -0,0 +1,20 @@ + +qemu-i386-static ioctl return -14 (Bad Address) + +I use qemu-i386-static on 64 bit ARM.But I don't know how to solve some problems. +First I added some ioctl operations. +Then I tried to do some DRM operations like test.c. +This is successful when I use qemu-x86_64-static,but it failed when I use qemu-i386-static. +I can get some strace info like this: + +403 openat(AT_FDCWD,"/dev/dri/card0",O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4 +403 ioctl(4,DRM_IOCTL_GET_CAP,{1,0}) = 0 ({1,1}) +403 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0,0,0,0,0,0,0,0,0,0,0,0}) = 0 ({0,0,0,0,0,2,2,2,0,16384,0,16384}) +403 brk(NULL) = 0x40006000 +403 brk(0x40027000) = 0x40027000 +403 brk(0x40028000) = 0x40028000 +403 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0,1073766816,1073766832,1073766848,0,2,2,2,0,16384,0,16384}) = -1 errno=14 (Bad address) + +And there are similar errors in other self driven operations. +I want to know if it is QEMU's problem, so I hope to get some help. +Thank you! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1894617 b/results/classifier/deepseek-2/output/device/1894617 new file mode 100644 index 000000000..635bce2c9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1894617 @@ -0,0 +1,24 @@ + +qemu-i386 mmap but offset greater than 32 bits + +I don't know if it's a problem, but I did, and it bothered me for a long time. +When I use qemu-i386 and interact with the video card device,an error has occurred: + +18534 ioctl(4,DRM_IOCTL_MODE_GETENCODER,{39,0,0,0,0}) = 0 ({39,4,34,3,0}) +18534 ioctl(4,DRM_IOCTL_MODE_CREATE_DUMB,{1080,1920,32,0,0,0,0}) = 0 ({1080,1920,32,0,1,7680,8294400}) +18534 ioctl(4,DRM_IOCTL_MODE_ADDFB,{0,1920,1080,7680,32,24,1}) = 0 ({66,1920,1080,7680,32,24,1}) +18534 ioctl(4,DRM_IOCTL_MODE_MAP_DUMB,{1,0,0}) = 0 ({1,0,5543018496}) +18534 mmap2(NULL,8294400,PROT_READ|PROT_WRITE,MAP_SHARED,4,0x14a63c) = -1 errno=22 (Invalid argument) + +"5543018496" is the offset through ioctl() and it is "0x14a63c000". +In qemu： +ret = target_mmap(arg1, arg2, arg3, + target_to_host_bitmask(arg4, mmap_flags_tbl), + arg5, arg6 << MMAP_SHIFT); + +The type of "arg6" is ulong.When use qemu-i386, arg6 can't be set to "0x14a63c000".So it's wrong for my program. + +I want to find a good way to deal with this kind of problem, but I'm not very familiar with QEMU， +so I came to ask how to deal with this problem. + +Thank you！ \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1895895 b/results/classifier/deepseek-2/output/device/1895895 new file mode 100644 index 000000000..36db7a607 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1895895 @@ -0,0 +1,30 @@ + +Attaching SD-Card to specific SD-Bus Sabrelite (ARM) + +Currently, I am looking for a method of attaching an sd-card to a specific bus as opposed to defaulting to the first. + +QEMU Version: 5.0.0 +Specifically trying to use qemu-system-arm binary + + +Running an "info qtree" shows the output seen in the attached image. I have attempted multiple different combinations of arguments to attempt to get the sd-card to appear on the FOURTH sd-bus but no luck. The machine type being used is Sabrelite. It should be noted that I was able to PATCH QEMU to achieve the result I expected but I had hoped this functionality was already available and did not require modification to QEMU itself. + + +For reference, this is the patch that was made to source to allow the card to attach to a specific bus. After the change was made, an sd-card could be attached to a bus with the following flags: + +-drive file=sdcard.img,format=raw,id=mycard -device sd-card,drive=mycard,bus=sd-bus.0 + + +diff qemu-5.1.0.orig/hw/sd/sdhci.c qemu-5.1.0/hw/sd/sdhci.c +1311a1312,1314 +> static int index=0; +> char name[64]; +> sprintf(name, "sd-bus.%d", index++); +1313c1316 +< TYPE_SDHCI_BUS, DEVICE(s), "sd-bus"); +--- +> TYPE_SDHCI_BUS, DEVICE(s), name); + + + +If there is a way to attach an sd-card to the specific bus that does NOT require this change, I'd appreciate it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1896317 b/results/classifier/deepseek-2/output/device/1896317 new file mode 100644 index 000000000..f6105c560 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1896317 @@ -0,0 +1,58 @@ + +ioapic: UndefinedBehaviorSanitizer starting qemu-system-i386 + +As of commit 053a4177817: + +$ ./configure --enable-sanitizers --disable-kvm + +$ make qemu-system-i386 + +$ ./build/i386-softmmu/qemu-system-i386 +include/exec/memory.h:688:12: runtime error: member access within null pointer of type 'AddressSpace' (aka 'struct AddressSpace') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/exec/memory.h:688:12 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==249513==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x55955d7f8c4f bp 0x7fff10f3cff0 sp 0x7fff10f3cf20 T0) +==249513==The signal is caused by a READ memory access. +==249513==Hint: address points to the zero page. + #0 0x55955d7f8c4f in address_space_to_flatview include/exec/memory.h:688:12 + #1 0x55955d8003d2 in address_space_translate include/exec/memory.h:2286:31 + #2 0x55955d8315f3 in address_space_stl_internal memory_ldst.c.inc:312:10 + #3 0x55955d831cd1 in address_space_stl_le memory_ldst.c.inc:353:5 + #4 0x55955d7ef2e1 in stl_le_phys include/exec/memory_ldst_phys.h.inc:103:5 + #5 0x55955d7ed299 in ioapic_service hw/intc/ioapic.c:138:17 + #6 0x55955d7f0e30 in ioapic_set_irq hw/intc/ioapic.c:186:17 + #7 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #8 0x55955d0409e6 in gsi_handler hw/i386/x86.c:583:5 + #9 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #10 0x55955ca539c9 in hpet_handle_legacy_irq hw/timer/hpet.c:724:13 + #11 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #12 0x55955ce7a695 in pit_irq_timer_update hw/timer/i8254.c:264:5 + #13 0x55955ce7a1d8 in pit_irq_control hw/timer/i8254.c:306:9 + #14 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #15 0x55955ca52276 in hpet_reset hw/timer/hpet.c:707:5 + #16 0x55955e342e91 in device_transitional_reset hw/core/qdev.c:1114:9 + #17 0x55955e345cfc in resettable_phase_hold hw/core/resettable.c:182:13 + #18 0x55955e31c1e5 in bus_reset_child_foreach hw/core/bus.c:94:9 + #19 0x55955e348a58 in resettable_child_foreach hw/core/resettable.c:96:9 + #20 0x55955e34596f in resettable_phase_hold hw/core/resettable.c:173:5 + #21 0x55955e344a72 in resettable_assert_reset hw/core/resettable.c:60:5 + #22 0x55955e344919 in resettable_reset hw/core/resettable.c:45:5 + #23 0x55955e3473e9 in resettable_cold_reset_fn hw/core/resettable.c:269:5 + #24 0x55955e344898 in qemu_devices_reset hw/core/reset.c:69:9 + #25 0x55955d05c5b0 in pc_machine_reset hw/i386/pc.c:1632:5 + #26 0x55955d55ab84 in qemu_system_reset softmmu/vl.c:1403:9 + #27 0x55955d56816d in qemu_init softmmu/vl.c:4458:5 + #28 0x55955bc13609 in main softmmu/main.c:49:5 + #29 0x7f3baad20041 in __libc_start_main (/lib64/libc.so.6+0x27041) + #30 0x55955bb398ed in _start (build-sanitizer/qemu-system-i386+0x1b3d8ed) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV include/exec/memory.h:688:12 in address_space_to_flatview + +Comment and stl_le_phys() added in commit cb135f59b80: + /* No matter whether IR is enabled, we translate + * the IOAPIC message into a MSI one, and its + * address space will decide whether we need a + * translation. */ + stl_le_phys(ioapic_as, info.addr, info.data); \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1897 b/results/classifier/deepseek-2/output/device/1897 new file mode 100644 index 000000000..df39c5fc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1897 @@ -0,0 +1,22 @@ + +npcm7xx_timer-test.c is unreliable +Description of problem: +Sometimes npcm7xx_timer-test fails intermittently: +https://gitlab.com/qemu-project/qemu/-/jobs/5121787250 + +``` +38/96 qemu:qtest+qtest-arm / qtest-arm/npcm7xx_timer-test ERROR 0.95s exit status 1 +>>> QTEST_QEMU_BINARY=./qemu-system-arm QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=103 /builds/qemu-project/qemu/build/tests/qtest/npcm7xx_timer-test --tap -k +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +** +ERROR:../tests/qtest/npcm7xx_timer-test.c:475:test_periodic_interrupt: assertion failed (tim_read(td, TISR) == tim_timer_bit(td)): (0x00000000 == 0x00000004) +** +ERROR:../tests/qtest/npcm7xx_timer-test.c:476:test_periodic_interrupt: 'qtest_get_irq(global_qtest, tim_timer_irq(td))' should be TRUE +(test program exited with status code 1) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +When I reran the CI job, it passed. + +Please investigate why this test is unreliable and fix it. Thanks! diff --git a/results/classifier/deepseek-2/output/device/1897568 b/results/classifier/deepseek-2/output/device/1897568 new file mode 100644 index 000000000..1e3385333 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1897568 @@ -0,0 +1,11 @@ + +Strange keyboard behaviour in Vim editor + + +I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a problem with the keyboard in the Vim editor. The arrow keys jump over a line, as if you had typed the key twice. PgUp and PgDn are likewise affected. Other applications are not affected, unless you shell out from Vim. + +The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've tried without it and it doesn't make a difference. + +I don't get this keyboard behaviour in the exact same VM under VMware Player or Bochs. + +-Albert. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1897680 b/results/classifier/deepseek-2/output/device/1897680 new file mode 100644 index 000000000..96886bc44 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1897680 @@ -0,0 +1,15 @@ + +memory address over 0x2000_7ffc is not accessible in mps2-an505 + +I currently run qemu with the following options +`qemu-system-aarch64 -machine mps2-an505 -cpu cortex-m33 -m 16` + +For some reason, memory address over 0x2000_7ffc is not accessible. +It can be tested in gdb as follow. + +(gdb) x/x 0x20007ffc +0x20007ffc: 0x00000000 +(gdb) x/x 0x20007ffd +0x20007ffd: Cannot access memory at address 0x20007ffd +(gdb) x/x 0x20008000 +0x20008000: Cannot access memory at address 0x20008000 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1900 b/results/classifier/deepseek-2/output/device/1900 new file mode 100644 index 000000000..a5625f66a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1900 @@ -0,0 +1,2 @@ + +8.1.0-r1: segfault at get_zones_wp() at ../block/file-posix.c:1337 diff --git a/results/classifier/deepseek-2/output/device/1900122 b/results/classifier/deepseek-2/output/device/1900122 new file mode 100644 index 000000000..6efacb979 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1900122 @@ -0,0 +1,111 @@ + +Unsupported ioctl: cmd=0xffffffff80685600 when accessing /dev/video* in aarch64 guest + +**Description:** +Any attempt to work with video in aarch64 architecture emulated on x86_64 leads currently to the error "Function not implemented". For example: + +``` +# v4l2-ctl -l --verbose +Failed to open /dev/video0: Function not implemented + +root@12dd9b6fcfcb:/# ll /dev/video* +crw-rw---- 1 root video 81, 0 Oct 16 09:23 /dev/video0 +crw-rw---- 1 root video 81, 1 Oct 16 09:23 /dev/video1 + +``` + +**Steps to reproduce the issue:** + +I have a following setup: + +Host Hardware: x86_64 equipped with a webcam (tried different webcams) +Host OS: Ubuntu 20.04.1 + +Guest Architecture: aarch64 +Guest OS: Ubuntu 20.04 (also tried 16.x and 18.x) + +Emulation: quemu-user-static (also tried binfmt) + +Guest OS is running via Docker + QEMU + +``` +➜ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 +enabled +interpreter /usr/bin/qemu-aarch64-static +flags: F +offset 0 +magic 7f454c460201010000000000000000000200b700 +mask ffffffffffffff00fffffffffffffffffeffffff +``` + +**Results received:** +see desrciption. + +**Environment:** + +<!-- The host architecture is available for only x86_64 --> +* QEMU version: (if you can know it): + +ipxe-qemu-256k-compat-efi-roms/focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/focal-updates,now 1.0.0+git-20190109.133f4c4-0ubuntu3.2 all [installed,automatic] +qemu-block-extra/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-kvm/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] +qemu-system-common/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-system-data/focal-updates,now 1:4.2-3ubuntu6.7 all [installed,automatic] +qemu-system-gui/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-system-x86/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-user-binfmt/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-user/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] +qemu-utils/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] + +* Container application: Docker + +**Output of `docker version`, `podman version` or `singularity version`** + +``` +➜ docker version +Client: Docker Engine - Community + Version: 20.10.0-beta1 + API version: 1.40 + Go version: go1.13.15 + Git commit: ac365d7 + Built: Tue Oct 13 18:15:22 2020 + OS/Arch: linux/amd64 + Context: default + Experimental: true + +Server: Docker Engine - Community + Engine: + Version: 19.03.13 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.15 + Git commit: 4484c46d9d + Built: Wed Sep 16 17:01:20 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.4.1 + GitCommit: c623d1b36f09f8ef6536a057bd658b3aa8632828 + runc: + Version: 1.0.0-rc92 + GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff + docker-init: + Version: 0.18.0 + GitCommit: fec3683 + +``` + +Guest aarch64 runs in privileged mode: + +`docker run --privileged --device=/dev/video0:/dev/video0 --env DISPLAY=unix$DISPLAY -v $XAUTH:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix -it --rm arm64v8/ubuntu:20.04 bash` + +**Additional information:** +I tried also binfmt way to register emulators. The output of `v4l-ctl` was a little bit different: + +``` +# v4l2-ctl -l +Unsupported ioctl: cmd=0xffffffff80685600 +Failed to open /dev/video0: Function not implemented + +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1900918 b/results/classifier/deepseek-2/output/device/1900918 new file mode 100644 index 000000000..a65a40ae4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1900918 @@ -0,0 +1,15 @@ + +PXB devices + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1900919 b/results/classifier/deepseek-2/output/device/1900919 new file mode 100644 index 000000000..ce2fd9d88 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1900919 @@ -0,0 +1,15 @@ + +PXB selected as root bus incorrectly + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1901440 b/results/classifier/deepseek-2/output/device/1901440 new file mode 100644 index 000000000..8c132cf50 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1901440 @@ -0,0 +1,18 @@ + +Instability in IVSHMEM after updating QEMU 4.2 -> 5.0 + +Updating Ubuntu from 20.08 to 20.10 which updates QEMU from 4.2 to 5.0 results in the virtual machines freezing when the IVSHMEM interface is active. This workstation typically runs several windows 10 virtual machines that are accessed locally: two using the spice viewer and one that uses an passthrough assigned GPU accessed through a viewer called Looking Glass. Looking Glass uses the IVSHMEM device interface to pass captured frames from the windows virtual machine to the linux host for display by a viewer application. + +This workstation was 100% stable under Ubuntu 20.08 (QEMU 4.2). It handled a variety of heavy loads all day it never froze or crashed. It became unstable under Ubuntu 20.10 (QEMU 5.0), seemingly triggered by high levels of SHM activity. I was able to reliably reproduce the problem when playing a video in the looking-glass vm while playing another video in a spice vm. Other scenarios would also trigger this problem less reliably, but this video playback scenario would trigger it after 3-5 minutes of playback. + +The result of this new instability would manifest itself by all running vms on the host freezing but the host was not visibly effected. I could find no warnings or errors in any relevant system or QEMU logs. It wasn't just spice, when I accessed the gpu-passthru vm via directly assigned devices it was frozen, still outputting video of the last frame before the crash. All vms would have to be force-shutdown and the host rebooted to regain vm functionality. Just forcing shutdown and restarting a vm would result in showing 'running' status but it would be frozen and inaccessible until system reboot. + +I suspect this is a QEMU host / kernel error for several reasons: Having to reboot the host, insensitivity to VM changes including virtio-win version, etc. I suspect it's related to IVSHMEM due to the correlation of the freeze to the looking-glass related activity. + +This might be kernel / PCIe / power management related in some way. While experimenting to troubleshoot this issue I was able to trigger the error more quickly by disabling PCIe power management in the BIOS. + +The system was 100% stable under QEMU 5.0 when not running the looking-glass vm, quite stable when the looking-glass vm was idle or lightly used, but appeared increasingly unstable as SHM activity increased. + +Sorry if this is a bit anecdotal, this is my work machine and unfortunately today I was forced to rollback restore to Ubuntu 20.08 (QEMU 4.2) from backup so I can work on Monday. The system returned to 100% stability after returning to 20.08. + +If requested I can restore the Ubuntu 20.10 snapshot to reproduce & gather information as directed. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1901532 b/results/classifier/deepseek-2/output/device/1901532 new file mode 100644 index 000000000..0f6017176 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1901532 @@ -0,0 +1,20 @@ + +Assertion failure `mr != NULL' failed through usb-ehci + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ehci. + +This was found in version 5.0.1 (stable-5.0). + +-------- + +qemu-system-i386: src/qemu-repro/exec.c:3581: address_space_unmap: Assertion `mr != NULL' failed. +[1] 14721 abort src/qemu-repro/build/i386-softmmu/qemu-system-i386 + + +To reproduce the assertion failure, please run the QEMU with following command line. + +``` +$ qemu-system-i386 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -m 512 -drive if=none,id=stick,file=./usbdisk.img -device usb-ehci,id=ehci -device usb-storage,bus=ehci.0,drive=stick +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1902306 b/results/classifier/deepseek-2/output/device/1902306 new file mode 100644 index 000000000..d36e248ed --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1902306 @@ -0,0 +1,11 @@ + +Allow setting usb storage device ID parameters + +Some stubborn software requires certain VID/PID/Serial to authenticate and refuses to start in emulation. This poses a problem with unsupported programs which often require keeping an ancient hardware praying that the USB stick will not die before the (often defunct) company making it. + +Virtualizing such environment is desired. However, QEMU doesn't allow setting VID/PID/Serial/Name of emulated USB devices, but instead uses hardcoded values: https://github.com/qemu/qemu/blob/c99fa56b95a72f6debd50a280561895d078ae020/hw/usb/dev-storage.c#L95 + +This request (including a patch) was already made in 2015 on the list but never got any response: https://lists.nongnu.org/archive/html/qemu-discuss/2015-07/msg00072.html + + +WDYT of adding such functionality? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1903752 b/results/classifier/deepseek-2/output/device/1903752 new file mode 100644 index 000000000..f51cc5b26 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1903752 @@ -0,0 +1,11 @@ + +qemu-system-avr error: qemu-system-avr: execution left flash memory + +I compiled QEMU 5.1 from source with target avr-softmmu. Running demo.elf from https://github.com/seharris/qemu-avr-tests/blob/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf (linked from https://www.qemu.org/docs/master/system/target-avr.html) yields the following error: + +$ ./qemu-5.1.0/avr-softmmu/qemu-system-avr -machine mega2560 -bios demo.elf +VNC server running on 127.0.0.1:5900 +qemu-system-avr: execution left flash memory +Aborted (core dumped) + +I compiled QEMU on Ubuntu Server 20.10 with gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1904490 b/results/classifier/deepseek-2/output/device/1904490 new file mode 100644 index 000000000..1cdf921dd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1904490 @@ -0,0 +1,25 @@ + +intel-hda: valid registers are unknown + +According to HDA specification, "3.1.2 General Register Behaviors and Access Requirements": + +"All controller registers must be addressable as byte, Word, and Dword quantities." + +But e.g. if you try the following to reset and enable the CORB, assuming es:esi contains the base MMIO address of the controller, + + es or [esi+4bh], byte 80h ; reset CORB +corbresetloop: + es test [esi+4bh], byte 80h ; is HW done resetting yet? + jnz corbreset1ok ; yes, bit is now 1 + hlt ; wait a little bit + jmp corbresetloop ; and check again +corbreset1ok: + es and [esi+4bh], byte 7fh ; clear the bit + +It will hang indefinitely because the bit never gets set, and if you enable debug output of the controller with "-device intel-hda,debug=1", you will see infinitely the line "unknown register, addr 0x4b" output. The same code on a real hardware (I tried with ICH7M) works fine, as it should according to the spec. + +Host/guest/version does not matter (I am writing own drivers) --- as of right now, latest version still has this code: + +https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c + +which seems to emit "unknown register" message in intel_hda_reg_find(), and this function does not take into account range of addresses that each register occupies. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1904652 b/results/classifier/deepseek-2/output/device/1904652 new file mode 100644 index 000000000..1961c42a8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1904652 @@ -0,0 +1,51 @@ + +Assertion failure in usb-ohci + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ohci. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + +-------- + +``` + +Program terminated with signal SIGABRT, Aborted. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7f34d0411440 (LWP 9418))] +gdb-peda$ bt +#0 0x00007f34c8d4ef47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f34c8d508b1 in __GI_abort () at abort.c:79 +#2 0x000055d3a2081844 in ohci_frame_boundary (opaque=0x55d3a4ecdaf0) at ../hw/usb/hcd-ohci.c:1297 +#3 0x000055d3a25be155 in timerlist_run_timers (timer_list=0x55d3a3fd9840) at ../util/qemu-timer.c:574 +#4 0x000055d3a25beaba in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#5 0x000055d3a25beaba in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#6 0x000055d3a25e69a1 in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531 +#7 0x000055d3a2433972 in qemu_main_loop () at ../softmmu/vl.c:1678 +#8 0x000055d3a1d0969b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, + argv@entry=0x7ffc6de722a8, envp=<optimized out>) at ../softmmu/main.c:50 +#9 0x00007f34c8d31b97 in __libc_start_main (main= + 0x55d3a1d09690 <main>, argc=0x15, argv=0x7ffc6de722a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc6de72298) at ../csu/libc-start.c:310 +#10 0x000055d3a1d095aa in _start () +``` + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` +[Terminal 1] + +$ qemu-system-i386 -m 512 -drive file=./fs.img,index=1,media=disk,format=raw -drive file=./hyfuzz.img,index=0,media=disk,format=raw -drive if=none,id=stick,file=./usbdisk.img,format=raw -device pci-ohci,id=usb -device usb-storage,bus=usb.0,drive=stick + +[Terminal 2] + +$ ./repro_log ./fs.img ./pci-ohci + +``` + +Please let me know if I can provide any further info. +-Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1905226 b/results/classifier/deepseek-2/output/device/1905226 new file mode 100644 index 000000000..336f9841f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1905226 @@ -0,0 +1,16 @@ + +intel-hda: stream reset bits are broken + +From HD audio spec, section 3.3.35: + +"Stream Reset (SRST): Writing a 1 causes the corresponding stream to be reset. [...] After the stream hardware has completed sequencing into the reset state, it will report a 1 in this bit. Software must read a 1 from this bit to verify that the stream is in reset. Writing a 0 causes the corresponding stream to exit reset. When the stream hardware is ready to begin operation, it will report a 0 in this bit. Software must read a 0 from this bit before accessing any of the stream registers." + +So to reset a stream I set the bit, but it never reads back as 1 so the driver either times out or will hang forever waiting for it to become 1. I looked into why this happens and found that as of the latest version (8110fa1), in function intel_hda_set_st_ctl() of the https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c, + + if (st->ctl & 0x01) { + /* reset */ + dprint(d, 1, "st #%d: reset\n", reg->stream); + st->ctl = SD_STS_FIFO_READY << 24; + } + +This causes the bit to immediately become set to 0 even if I write a 1, and clearly does not meet the spec. I checked behaviour of real hardware and it works as expected, i.e. I see the bit will become 1 and 0 when I write to it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1905297 b/results/classifier/deepseek-2/output/device/1905297 new file mode 100644 index 000000000..7d21a61fd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1905297 @@ -0,0 +1,30 @@ + +Zynq7000 UART clock reset initialization + +Hello, + +we have come across a strange behavior in the Zynq7000 model of Qemu that seems to have been introduced between 5.0.0 and 5.1.0. + + +The reset values of the SLCR register, in particular those for UART_CLK_CTRL, are such that +the UARTs should find functional clocks. Up to 5.0.0 this was also the behavior that was +implemented in QEMU. + +Starting in 5.1.0, we found that - despite correct reset values [1] - the UARTs are non-functional +upon reset. Some investigation revealed that the cause for that is that the corresponding +clocks are not properly initialized. + +Between 5.0.0 and 5.1.0, there are three commits that touch the Zynq UART clocks [2]. The last of them [3] triggers the faulty behavior. + +Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We surmise that the +underlying device release issue runs much deeper, so it is only meant to identify the issue. + + + +[1] hw/misc/zynq_slcr.c + static void zynq_slcr_reset_init(Object *obj, ResetType type) + s->regs[R_UART_CLK_CTRL] = 0x00003F03; +[2] 38867cb7ec90..5b49a34c6800 +[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) + Author: Damien Hedde <email address hidden> + Date: Mon Apr 6 15:52:50 2020 +0200 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1905444 b/results/classifier/deepseek-2/output/device/1905444 new file mode 100644 index 000000000..8dc62a199 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1905444 @@ -0,0 +1,47 @@ + +[OSS-Fuzz] Issue 27796 in oss-fuzz: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci: Stack-overflow in address_space_stl_internal + + affects qemu + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27796 + +=== Reproducer (build with --enable-sanitizers) === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-qtest-log none -qtest stdio +outl 0xcf8 0x80000803 +outw 0xcfc 0x5e46 +outl 0xcf8 0x80000810 +outl 0xcfc 0xff5a5e46 +write 0xff5a5020 0x6 0xffffffff0b70 +outl 0xcf8 0x80000893 +outb 0xcfc 0x93 +writel 0xff5a7000 0xff5a5020 +write 0xff5a700c 0x4 0x0c0c2e58 +write 0xff5a4040 0x4 0x00d26001 +write 0xff5a4044 0x4 0x0000030 +EOF + +=== Stack Trace === +==50473==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe3ec97e28 (pc 0x55e292eac159 bp 0x7ffe3ec98670 sp 0x7ffe3ec97e30 T0) +#0 0x55e292eac159 in __asan_memcpy (u-system-i386+0x2a0e159) +#1 0x55e2944bc04e in flatview_do_translate softmmu/physmem.c:513:12 +#2 0x55e2944dbe90 in flatview_translate softmmu/physmem.c:563:15 +#3 0x55e2944dbe90 in address_space_translate include/exec/memory.h:2362:12 +#4 0x55e2944dbe90 in address_space_stl_internal memory_ldst.c.inc:316:10 +#5 0x55e29393d2a0 in xhci_intr_update hw/usb/hcd-xhci.c:554:13 +#6 0x55e29393efb9 in xhci_runtime_write hw/usb/hcd-xhci.c:3032:9 +#7 0x55e294230428 in memory_region_write_accessor softmmu/memory.c:484:5 +#8 0x55e29422fe63 in access_with_adjusted_size softmmu/memory.c:545:18 +#9 0x55e29422f6fc in memory_region_dispatch_write softmmu/memory.c +#10 0x55e2944dc03c in address_space_stl_internal memory_ldst.c.inc:319:13 +#11 0x55e29393d2a0 in xhci_intr_update hw/usb/hcd-xhci.c:554:13 +#12 0x55e29393efb9 in xhci_runtime_write hw/usb/hcd-xhci.c:3032:9 +#13 0x55e294230428 in memory_region_write_accessor softmmu/memory.c:484:5 +#14 0x55e29422fe63 in access_with_adjusted_size softmmu/memory.c:545:18 +#15 0x55e29422f6fc in memory_region_dispatch_write softmmu/memory.c +#16 0x55e2944dc03c in address_space_stl_internal memory_ldst.c.inc:319:13 +#17 0x55e29393d2a0 in xhci_intr_update hw/usb/hcd-xhci.c:554:13 +#18 0x55e29393efb9 in xhci_runtime_write hw/usb/hcd-xhci.c:3032:9 diff --git a/results/classifier/deepseek-2/output/device/1906155 b/results/classifier/deepseek-2/output/device/1906155 new file mode 100644 index 000000000..25623b617 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1906155 @@ -0,0 +1,14 @@ + +USB Passthrough Fails on Start, Needs domain Reset + +Hi, + +I am seeing (consistently = always), USB Passthrough for my Logitech Keyboard and Mouse ... they don't work / no response on domain (VM) startup. After a reset of the VM they then work - but why are they "dead" on initial startup of the VM? Is this a known issue? + +Running, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +And if it makes a difference, this is a macOS guest (on a Linux host). + +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1906181 b/results/classifier/deepseek-2/output/device/1906181 new file mode 100644 index 000000000..2c93a49fe --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1906181 @@ -0,0 +1,14 @@ + +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 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1906184 b/results/classifier/deepseek-2/output/device/1906184 new file mode 100644 index 000000000..971a0466b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1906184 @@ -0,0 +1,29 @@ + +Lots of stuttering/crackling in guest sound + +When listening to music (e.g. with VLC) or watching Youtube on the guest, there's lots of stuttering and crackling in the sound. + + +Tested with the following QEMU start commands: + +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 + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk + + +If I use the following command (QXL graphics, "remote" access via SPICE over unix socket), stuttering is not completely gone but MUCH less annoying: + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing + +and this command for accessing the VM: +remote-viewer spice+unix:///tmp/vm_spice.socket + + + +Guest: Kubuntu 20.04 64-bit (live), but occurs with many other as well +Host: Arch Linux, with KDE desktop +CPU: Intel Xeon E3-1230v2 (4 cores + hyperthreading) +RAM: 16 GB +GPU: Nvidia GTX 980 Ti \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1906295 b/results/classifier/deepseek-2/output/device/1906295 new file mode 100644 index 000000000..fea03b49e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1906295 @@ -0,0 +1,12 @@ + +Implementation of exclusive monitor in ARM + +Hi + +I refer to the implementation of exclusive monitor in ARM32. For instruction like STREX Rx,Ry,[Rz], we need to check whether the address [Rz] is in exclusive state. If not, we set the value Rx as 1 without doing the store operation. However, I noticed that QEMU will not check whether the address that Rz points to is a legal address or not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU will set Rx as 1 and continue to execute the following instructions. + +However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. +Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1906463 b/results/classifier/deepseek-2/output/device/1906463 new file mode 100644 index 000000000..f0b3696a7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1906463 @@ -0,0 +1,19 @@ + +"-device help" does not report all devices + +-device help doesn't report all devices. +E.g., devices that are instantiated by a board don't get printed in part because they don't exist when "-device help" is processed. As an experiment I deferred processing of "-device help" as long as possible and some devices were still not printed, so there's more going on here. + +QEMU commit hash: 944fdc5e27a5b5adbb765891e8e70e88ba9a00ec + +Repro: +$ configure --target-list=arm-softmmu +$ make +$ ./qemu-system-arm -device help | grep npcm7xx +<empty> + +I'd expect to see things like npcm7xx-rng in the output. + +I can imagine enumerating board-provided devices is a challenge. +Still, it'd be really nice if "-device help" printed them, and having +"-device $driver,help" work as well. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1907042 b/results/classifier/deepseek-2/output/device/1907042 new file mode 100644 index 000000000..2b75b21d9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1907042 @@ -0,0 +1,37 @@ + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed + +Hello, + +An assertion failure was found in hw/usb/core.c:727 in latest version 5.2.0. + +Reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 -trace usb\* + +Backtrace is as follows: +#0 0x00007f13fff14438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f13fff1603a in __GI_abort () at abort.c:89 +#2 0x00007f13fff0cbe7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=file@entry=0x55f97745f6c0 "../hw/usb/core.c", line=line@entry=727, function=function@entry=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:92 +#3 0x00007f13fff0cc92 in __GI___assert_fail (assertion=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x55f97745f6c0 "../hw/usb/core.c", line=727, function=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:101 +#4 0x000055f975bfc9b2 in usb_ep_get (dev=0x62300000c500, pid=45, ep=1) at ../hw/usb/core.c:727 +#5 0x000055f975f945db in ohci_service_td (ohci=0x6270000191f0, ed=0x7ffcd9308410) at ../hw/usb/hcd-ohci.c:1044 +#6 0x000055f975f95d5e in ohci_service_ed_list (ohci=0x6270000191f0, head=857580576, completion=0) at ../hw/usb/hcd-ohci.c:1200 +#7 0x000055f975f9656d in ohci_process_lists (ohci=0x6270000191f0, completion=0) at ../hw/usb/hcd-ohci.c:1238 +#8 0x000055f975f9725c in ohci_frame_boundary (opaque=0x6270000191f0) at ../hw/usb/hcd-ohci.c:1281 +#9 0x000055f977212494 in timerlist_run_timers (timer_list=0x60b00005b060) at ../util/qemu-timer.c:574 +#10 0x000055f9772126db in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#11 0x000055f977212fde in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#12 0x000055f9772d5717 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531 +#13 0x000055f97695100c in qemu_main_loop () at ../softmmu/vl.c:1677 +#14 0x000055f9758f7601 in main (argc=16, argv=0x7ffcd9308888, envp=0x7ffcd9308910) at ../softmmu/main.c:50 +#15 0x00007f13ffeff840 in __libc_start_main (main=0x55f9758f75b0 <main>, argc=16, argv=0x7ffcd9308888, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd9308878) at ../csu/libc-start.c:291 +#16 0x000055f9758f74a9 in _start () + + +The poc is attached. + +Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1907427 b/results/classifier/deepseek-2/output/device/1907427 new file mode 100644 index 000000000..e3960b633 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1907427 @@ -0,0 +1,13 @@ + +Build on sparc64 fails with "undefined reference to `fdt_check_full'" + +Trying to build QEMU on sparc64 fails with: + +[4648/8435] c++ -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o libcommon.fa.p/hw_input_vhost-user-input.c.o libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o libcommon.fa.p/hw_display_sm501.c.o libcommon.fa.p/hw_net_rocker_rocker_world.c.o libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o libcommon.fa.p/migration_global_state.c.o libcommon.fa.p/backends_rng-random.c.o libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/hw_core_qdev-properties-system.c.o libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o libcommon.fa.p/audio_audio_legacy.c.o +(...) +libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong libmigration.fa -Wl,--start-group libqemuutil.a contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa @block.syms @qemu.syms /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so /usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm /usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so /usr/lib/sparc64-linux-gnu/libslirp.so /usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so @block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so /usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug /usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle -lstdc++ -Wl,--end-group +/usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function `h_update_dt': +./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to `fdt_check_full' +collect2: error: ld returned 1 exit status + +Full build log available at: https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc64&ver=1%3A5.2%2Bdfsg-1&stamp=1607502300&raw=0 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1907497 b/results/classifier/deepseek-2/output/device/1907497 new file mode 100644 index 000000000..425cf1085 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1907497 @@ -0,0 +1,59 @@ + +[OSS-Fuzz] Issue 28435 qemu:qemu-fuzz-i386-target-generic-fuzz-intel-hda: Stack-overflow in ldl_le_dma + + affects qemu + +=== Reproducer (build with --enable-sanitizers) === + +cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +-device intel-hda,id=hda0 -device hda-output,bus=hda0.0 \ +-device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 \ +-qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0xffff +write 0x0 0x1 0x12 +write 0x2 0x1 0x2f +outl 0xcf8 0x80000811 +outl 0xcfc 0x5a6a4406 +write 0x6a44005a 0x1 0x11 +write 0x6a44005c 0x1 0x3f +write 0x6a442050 0x4 0x0000446a +write 0x6a44204a 0x1 0xf3 +write 0x6a44204c 0x1 0xff +writeq 0x6a44005a 0x17b3f0011 +write 0x6a442050 0x4 0x0000446a +write 0x6a44204a 0x1 0xf3 +write 0x6a44204c 0x1 0xff +EOF + +=== Stack Trace === +==411958==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcaeb8bc88 (pc 0x55c7c9dc1159 bp 0x7ffcaeb8c4d0 sp 0x7ffcaeb8bc90 T0) + #0 0x55c7c9dc1159 in __asan_memcpy (u-system-i386+0x2a13159) + #1 0x55c7cb2a457e in flatview_do_translate softmmu/physmem.c:513:12 + #2 0x55c7cb2bdab0 in flatview_translate softmmu/physmem.c:563:15 + #3 0x55c7cb2bdab0 in flatview_read softmmu/physmem.c:2861:10 + #4 0x55c7cb2bdab0 in address_space_read_full softmmu/physmem.c:2875:18 + #5 0x55c7caaec937 in dma_memory_rw_relaxed include/sysemu/dma.h:87:18 + #6 0x55c7caaec937 in dma_memory_rw include/sysemu/dma.h:110:12 + #7 0x55c7caaec937 in dma_memory_read include/sysemu/dma.h:116:12 + #8 0x55c7caaec937 in ldl_le_dma include/sysemu/dma.h:179:1 + #9 0x55c7caaec937 in ldl_le_pci_dma include/hw/pci/pci.h:816:1 + #10 0x55c7caaec937 in intel_hda_corb_run hw/audio/intel-hda.c:338:16 + #11 0x55c7cb2e7198 in memory_region_write_accessor softmmu/memory.c:491:5 + #12 0x55c7cb2e6bd3 in access_with_adjusted_size softmmu/memory.c:552:18 + #13 0x55c7cb2e646c in memory_region_dispatch_write softmmu/memory.c + #14 0x55c7cb2c8445 in flatview_write_continue softmmu/physmem.c:2759:23 + #15 0x55c7cb2bdfb8 in flatview_write softmmu/physmem.c:2799:14 + #16 0x55c7cb2bdfb8 in address_space_write softmmu/physmem.c:2891:18 + #17 0x55c7caae2c54 in dma_memory_rw_relaxed include/sysemu/dma.h:87:18 + #18 0x55c7caae2c54 in dma_memory_rw include/sysemu/dma.h:110:12 + #19 0x55c7caae2c54 in dma_memory_write include/sysemu/dma.h:122:12 + #20 0x55c7caae2c54 in stl_le_dma include/sysemu/dma.h:179:1 + #21 0x55c7caae2c54 in stl_le_pci_dma include/hw/pci/pci.h:816:1 + #22 0x55c7caae2c54 in intel_hda_response hw/audio/intel-hda.c:370:5 + #23 0x55c7caaeca00 in intel_hda_corb_run hw/audio/intel-hda.c:342:9 + #24 0x55c7cb2e7198 in memory_region_write_accessor softmmu/memory.c:491:5 +... + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28435 + diff --git a/results/classifier/deepseek-2/output/device/1907776 b/results/classifier/deepseek-2/output/device/1907776 new file mode 100644 index 000000000..f1c04397a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1907776 @@ -0,0 +1,21 @@ + +Mounting VFat drive yields error messages. + +Mounting a virtual Fat drive results in error messages (see attached image). + +* https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +The "drive" is however mounted, and as a test, saving a text file to the drive is successfully stored in the directory `/tmp`, which can be read after shutdown of Qemu. + + Archlinux 5.9.11-arch2-1 (64-bit) + qemu-headless 5.1.0-3 + + qemu-system-x86_64 -boot order=d -name test \ + -enable-kvm -m 2G -cpu host -k sv \ + -daemonize \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \ + -drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \ + -vnc :1 \ + -cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \ + -drive format=raw,index=0,media=disk,file=~/vm/qemu.raw \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1907926 b/results/classifier/deepseek-2/output/device/1907926 new file mode 100644 index 000000000..219c72daf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1907926 @@ -0,0 +1,6 @@ + +Implement TPM2 configuration for emulators that provide TCP interface + +swtpm provides several interfaces for its emulated device: unix socket (can be used by qemu), chardev. swtpm also provides TCP interface for the device which is very convenient for testing as it does not require root permissions. + +It would be very useful to have QEMU to work with TPM devices emulated via TCP. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1908062 b/results/classifier/deepseek-2/output/device/1908062 new file mode 100644 index 000000000..fa6b01665 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1908062 @@ -0,0 +1,73 @@ + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again + +When I was fuzzing virtio-vga device of the latest QEMU (1758428, Dec 12, built with --enable-sanitizers --enable-fuzzing), an assertion failed in include/exec/memory_ldst_cached.h.inc. + +--[ Reproducer + +cat << EOF | ./build/i386-softmmu/qemu-system-i386 -machine accel=qtest \ +-machine q35 -display none -nodefaults -device virtio-vga -qtest stdio +outl 0xcf8 0x8000081c +outb 0xcfc 0xc3 +outl 0xcf8 0x80000804 +outb 0xcfc 0x06 +write 0xc300001024 0x2 0x0040 +write 0xc300001028 0x1 0x5a +write 0xc30000101c 0x1 0x01 +writel 0xc30000100c 0x20000000 +write 0xc300001016 0x3 0x80a080 +write 0xc300003002 0x1 0x80 +write 0x5c 0x1 0x10 +EOF + +--[ Output + +==35337==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 1607946348.442865] OPENED +[R +0.059305] outl 0xcf8 0x8000081c +OK +[S +0.059326] OK +[R +0.059338] outb 0xcfc 0xc3 +OK +[S +0.059355] OK +[R +0.059363] outl 0xcf8 0x80000804 +OK +[S +0.059369] OK +[R +0.059381] outb 0xcfc 0x06 +OK +[S +0.061094] OK +[R +0.061107] write 0xc300001024 0x2 0x0040 +OK +[S +0.061120] OK +[R +0.061127] write 0xc300001028 0x1 0x5a +OK +[S +0.061135] OK +[R +0.061142] write 0xc30000101c 0x1 0x01 +OK +[S +0.061158] OK +[R +0.061167] writel 0xc30000100c 0x20000000 +OK +[S +0.061212] OK +[R +0.061222] write 0xc300001016 0x3 0x80a080 +OK +[S +0.061231] OK +[R +0.061238] write 0xc300003002 0x1 0x80 +OK +[S +0.061247] OK +[R +0.061253] write 0x5c 0x1 0x10 +OK +[S +0.061403] OK +qemu-system-i386: /home/qiuhao/hack/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + +--[ Environment + +Ubuntu 20.04.1 5.4.0-58-generic x86_64 +clang: 10.0.0-4ubuntu1 +glibc: 2.31-0ubuntu9.1 +libglib2.0-dev: 2.64.3-1~ubuntu20.04.1 + +--[ Note + +Alexander Bulekov found the same assertion failure on 2020-08-04, https://bugs.launchpad.net/qemu/+bug/1890333, and it had been fixed in commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1. + +Fam Zheng found the same assertion failure on 2018-09-29, https://bugs.launchpad.net/qemu/+bug/1795148, and it had been fixed in commit db812c4073c77c8a64db8d6663b3416a587c7b4a. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1908450 b/results/classifier/deepseek-2/output/device/1908450 new file mode 100644 index 000000000..6ab43f86c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1908450 @@ -0,0 +1,47 @@ + +ide/core.c ATA Major Version reporting incorrect + +@@ -165,7 +165,7 @@ static void ide_identify(IDEState *s) + put_le16(p + 76, (1 << 8)); + } + + put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ +- put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ ++ put_le16(p + 80, ((1 << 6) | (1 << 5) (1 << 4) (1 << 3)); /* ata3 -> ata6 supported */ + put_le16(p + 81, 0x16); /* conforms to ata5 */ + /* 14=NOP supported, 5=WCACHE supported, 0=SMART supported */ + put_le16(p + 82, (1 << 14) | (1 << 5) | 1); + + +This field Major Version Number field is presently reporting support for ATA-4 through ATA-7. +Bitfield[80] is defined in the ATA-6 specification below. + +0xF0 = (1<<7) | (1<<6) | (1 << 5) | (1 << 4) // 4-7 - current settings +0x78 = (1<<6) | (1<<5) | (1 << 4) | (1 << 3) // 3-6 - new settings + +Either the comment is wrong, or the field is wrong. If the field is wrong it can cause errors in drivers that check support vs conformity. This will not break most guests, since the conformity field is set to ATA-5. + +I'm not sure whether this component supports ATA-7, but since it's commented as if it supports up through 6, correcting the field assignment seems more correct. + +ATA/ATAPI-6 Specification +https://web.archive.org/web/20200124094822/https://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf + +Page 116 +80 - M Major version number +0000h or FFFFh = device does not report version +F 15 Reserved +F 14 Reserved for ATA/ATAPI-14 +F 13 Reserved for ATA/ATAPI-13 +F 12 Reserved for ATA/ATAPI-12 +F 11 Reserved for ATA/ATAPI-11 +F 10 Reserved for ATA/ATAPI-10 +F 9 Reserved for ATA/ATAPI-9 +F 8 Reserved for ATA/ATAPI-8 +F 7 Reserved for ATA/ATAPI-7 +F 6 1 = supports ATA/ATAPI-6 +F 5 1 = supports ATA/ATAPI-5 +F 4 1 = supports ATA/ATAPI-4 +F 3 1 = supports ATA-3 +X 2 Obsolete +X 1 Obsolete +F 0 Reserved \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1908832 b/results/classifier/deepseek-2/output/device/1908832 new file mode 100644 index 000000000..a12cabfdb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1908832 @@ -0,0 +1,63 @@ + +jack audio dev produces no sound + +Hi, + +I'm testing the new jack audiodev backend in my +laptop. The host system is gentoo, using the +ebuild for qemu 5.1.0-r2, and I'm using jack +use flag globally in the system so any ebuild +that have support for jack should be build with +it. The jack setup reportedly works as I use it +with firefox, and mumble with no trouble. When +I launch the following script, I see the vm +connects to jack: + +/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \ + -cpu host -smp 2,cores=2,threads=1 \ + -m 4G -L /usr/share/qemu \ + -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ + -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \ + -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent \ + -device nec-usb-xhci,id=usb \ + -device usb-host,vendorid=0x04ca,productid=0x708e \ + -device usb-host,vendorid=0x1050,productid=0x0407 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev1 \ + -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev2 \ + -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev3 \ + -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio + +Output of vm initialization: + +jack: JACK output configured for 48000Hz (1024 samples) +jack: JACK input configured for 48000Hz (1024 samples) +gl_version 46 - core profile enabled +GLSL feature level 430 + +Though executing any application that uses sound, +for instance, any youtube video through browser, +I listen nothing. By executing pkill jackd, and +launching the same script replacing the audiodev +line for the following: + + -audiodev id=alsa,driver=alsa -device ich9-intel-hda -device hda-duplex,audiodev=alsa \ + +The audio works, and I can listen to music, or +any other kind of application, though I cannot +listen anything else in the host. + +The guest is a simple debian testing(bullseye) +system with plasma desktop, using pulseaudio, +nothing fancy. + +Thanks! + +José \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1909261 b/results/classifier/deepseek-2/output/device/1909261 new file mode 100644 index 000000000..3ef357cf9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1909261 @@ -0,0 +1,36 @@ + +[OSS-Fuzz] Issue 28929 xhci: ASSERT: xfer->packet.status != USB_RET_NAK + +=== Reproducer === + +./qemu-system-i386 -m 512M -machine q35,accel=qtest \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-bot -device usb-storage,drive=disk0 \ +-chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid \ +-device usb-ccid -device usb-kbd -device usb-mouse \ +-device usb-serial,chardev=cd1 -device usb-tablet \ +-device usb-wacom-tablet -device usb-audio \ +-qtest stdio -nographic -nodefaults < attachment + +=== Stack Trace === +#0 raise +#1 abort +#2 libc.so.6 +#3 __assert_fail +#4 xhci_kick_epctx /src/qemu/hw/usb/hcd-xhci.c:1865:13 +#5 xhci_ep_kick_timer /src/qemu/hw/usb/hcd-xhci.c:1034:5 +#6 timerlist_run_timers /src/qemu/util/qemu-timer.c:574:9 +#7 qemu_clock_run_timers /src/qemu/util/qemu-timer.c:588:12 +#8 qtest_clock_warp /src/qemu/softmmu/qtest.c:356:9 +#9 qtest_process_command /src/qemu/softmmu/qtest.c:752:9 +#10 qtest_process_inbuf /src/qemu/softmmu/qtest.c:797:9 +#11 qtest_server_inproc_recv /src/qemu/softmmu/qtest.c:904:9 +#12 send_wrapper /src/qemu/tests/qtest/libqtest.c:1390:5 +#13 qtest_sendf /src/qemu/tests/qtest/libqtest.c:438:5 +#14 qtest_clock_step_next /src/qemu/tests/qtest/libqtest.c:912:5 +#15 op_clock_step /src/qemu/tests/qtest/fuzz/generic_fuzz.c:574:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28929 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1910586 b/results/classifier/deepseek-2/output/device/1910586 new file mode 100644 index 000000000..8018a01b6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1910586 @@ -0,0 +1,46 @@ + +SD card size constraint conceptually wrong + +The patch discussed here: +https://<email address hidden>/msg720833.html +introduces an artificial size constraint for SD cards +that has no relation to reality. + +I'm trying to use an _actual_ **physical** SD card, +and qemu tells me its size is "invalid". + +Something here appears to be conceptually wrong. + +-------------------------------------------------- +# fdisk -l /dev/sdg +Disk /dev/sdg: 14.84 GiB, 15931539456 bytes, 31116288 sectors +Disk model: USB SD Reader +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: dos +Disk identifier: 0x7a0c8bb0 + +Device Boot Start End Sectors Size Id Type +/dev/sdg1 2048 524287 522240 255M c W95 FAT32 (LBA) +/dev/sdg2 524288 31116287 30592000 14.6G 83 Linux +# qemu-system-aarch64 -M raspi3 -m 1G -kernel vmlinuz-5.4.79-v8 -dtb bcm2837-rpi-3-b-plus.dtb -append console=ttyAMA0\ root=/dev/mmcblk0p2\ rw -nographic -serial mon:stdio -drive file=/dev/sdg,format=raw +qemu-system-aarch64: Invalid SD card size: 14.8 GiB +SD card size has to be a power of 2, e.g. 16 GiB. +You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +(note that this will lose data if you make the image smaller than it currently is). +-------------------------------------------------- + +The same invocation with a dump of the actual image +resized to match qemu's odd expectations works fine. + + +This is on QEMU 5.2.0, as evidenced by the following: +-------------------------------------------------- +# qemu-system-aarch64 -version +QEMU emulator version 5.2.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +-------------------------------------------------- + +Is there a simple workaround that disables this rather +arbitrary constraint? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1910603 b/results/classifier/deepseek-2/output/device/1910603 new file mode 100644 index 000000000..f524d7f9c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1910603 @@ -0,0 +1,45 @@ + +[OSS-Fuzz] Issue 29174 sb16: Abrt in audio_bug + +=== Reproducer === +cat << EOF | ../build-system/qemu-system-i386 \ +-machine q35 -device sb16,audiodev=snd0 \ +-audiodev none,id=snd0 -nographic -nodefaults \ +-qtest stdio +outw 0x22c 0x41 +outb 0x22c 0x0 +outw 0x22c 0x1004 +outw 0x22c 0x1c +EOF + +=== Stack Trace === +A bug was just triggered in audio_calloc +Save all your work and restart without audio +I am sorry +Context: +Aborted + +#0 raise +#1 abort +#2 audio_bug /src/qemu/audio/audio.c:119:9 +#3 audio_calloc /src/qemu/audio/audio.c:154:9 +#4 audio_pcm_sw_alloc_resources_out /src/qemu/audio/audio_template.h:116:15 +#5 audio_pcm_sw_init_out /src/qemu/audio/audio_template.h:175:11 +#6 audio_pcm_create_voice_pair_out /src/qemu/audio/audio_template.h:410:9 +#7 AUD_open_out /src/qemu/audio/audio_template.h:503:14 +#8 continue_dma8 /src/qemu/hw/audio/sb16.c:216:20 +#9 dma_cmd8 /src/qemu/hw/audio/sb16.c:276:5 +#10 command /src/qemu/hw/audio/sb16.c:0 +#11 dsp_write /src/qemu/hw/audio/sb16.c:949:13 +#12 portio_write /src/qemu/softmmu/ioport.c:205:13 +#13 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#14 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#15 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#16 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#17 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#18 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#19 cpu_outw /src/qemu/softmmu/ioport.c:70:5 + + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29174 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1911188 b/results/classifier/deepseek-2/output/device/1911188 new file mode 100644 index 000000000..72a2ddb57 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1911188 @@ -0,0 +1,15 @@ + +qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument + +QEMU emulator version 4.2.1 (qemu-4.2.1-1.fc32) on Fedora 32. + +When writing a script to start qemu automatically, I ran into a very confusing error message due to a bug in my script and had trouble understanding it. I isolated the problem to the following: + +$ qemu-system-x86_64 "" +qemu-system-x86_64: Initialization of device ide-hd failed: Device needs media, but drive is empty + +As you can see, running qemu with an empty argument prints a seemingly random and unrelated error message about an ide-hd device, and the program immediately exits with code 1. This happens when an empty argument appears anywhere in the arguments list, always causing the program to immediately die with this error. + +This is a simply baffling message to be encountering when the problem is really an empty argument. + +Expected behaviour: Either flatly ignore the empty argument, or at most trigger a warning (eg, "warning: saw empty argument"). It should not at all prevent the program from running. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1912846 b/results/classifier/deepseek-2/output/device/1912846 new file mode 100644 index 000000000..ec91bf4c7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1912846 @@ -0,0 +1,18 @@ + +Assertion hit on hot-unplugging virtio iommu enabled device + +From commit ("2d24a646 device-core: use RCU for +list of children of a bus") an assertion is hit when +removing a device, since mr->listeners are not properly +removed. To reproduce: + +/home/qemu/build/x86_64-softmmu/qemu-system-x86_64 -qmp tcp:0:4444,server,nowait ... \ + -netdev tap,id=hostnet0,vhostforce=on,vhost=on \ + -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:14:18:cc,bus=pci.1,addr=0x0,iommu_platform=on,ats=on + +In QMP: +{'execute': 'qmp_capabilities'} +{"execute": "device_del", "arguments": {"id": "net0"} } + +And crash: +../softmmu/memory.c:2818: do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1912857 b/results/classifier/deepseek-2/output/device/1912857 new file mode 100644 index 000000000..a5a199875 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1912857 @@ -0,0 +1,12 @@ + +virtio-serial blocks hostfwd ssh on windows 10 host + +qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=n1 --> WORKS - meaning I can ssh into the vm via port 2222 + +qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm + +Not only does the port 2222 work, but I am not able to perform any serial transfer on port 55298 as well. + +Host: Windows 10 +Guest: archlinux +QEMU version 5.2 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1913344 b/results/classifier/deepseek-2/output/device/1913344 new file mode 100644 index 000000000..34335f88b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1913344 @@ -0,0 +1,10 @@ + + Exynos4210 UART peripheral data loss + +Currently the Exynos4210 UART (hw/char/exynos4210_uart.c) incorrectly reports however many empty bytes are available in the FIFO when queried for receive capacity. However this peripheral supports a polled mode where only a single byte can be submitted at a time and the FIFO is unused, meaning that in polled mode data is lost since it's written into the FIFO and the polling code in FIFO disabled mode only returns the value in the RX data register. + +Even worse, potentially enabling the FIFO without a FIFO reset will create a weird situation where data is already in the FIFO whenever data came in faster than the polling could pick it up (which is basically always). + +This change obscured the issue in https://bugs.launchpad.net/qemu/+bug/1913341, which instead presented as strange data loss until I locally resolved this issue. + +I have a patch ready for the bug and will submit it later today, I'm just filing for clarity. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1913667 b/results/classifier/deepseek-2/output/device/1913667 new file mode 100644 index 000000000..03f08dc2b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1913667 @@ -0,0 +1,37 @@ + +FPE in npcm7xx_clk_update_pll + +I've been working on integrating the generic-fuzzer with ARM machines on OSS-Fuzz so we can fuzz devices on architectures beyond i386 devices. Since I saw that there is some active development for the Nuvoton machines, I thought it might be useful to fuzz the NPCM750 machine + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf080100c 0x4 0x00 +write 0xf080100c 0x4 0x00 +EOF + +Trace: +../hw/misc/npcm7xx_clk.c:131:14: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_clk.c:131:14 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717855==ERROR: AddressSanitizer: FPE on unknown address 0x5619201fcd8c (pc 0x5619201fcd8c bp 0x7ffc94214e50 sp 0x7ffc94214e30 T0) +#0 0x5619201fcd8c in npcm7xx_clk_update_pll /hw/misc/npcm7xx_clk.c:131:14 +#1 0x5619201ff5dc in npcm7xx_clk_write /hw/misc/npcm7xx_clk.c:799:13 +#2 0x5619214781fe in memory_region_write_accessor /softmmu/memory.c:491:5 +#3 0x561921477bfb in access_with_adjusted_size /softmmu/memory.c:552:18 +#4 0x561921477467 in memory_region_dispatch_write /softmmu/memory.c +#5 0x561921807ffb in flatview_write_continue /softmmu/physmem.c:2759:23 +#6 0x5619217fd71b in flatview_write /softmmu/physmem.c:2799:14 +#7 0x5619217fd71b in address_space_write /softmmu/physmem.c:2891:18 +#8 0x561921465eee in qtest_process_command /softmmu/qtest.c:539:13 +#9 0x561921462b97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#10 0x561921cb3286 in fd_chr_read /chardev/char-fd.c:68:9 +#11 0x7f4ad283baae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#12 0x56192230e363 in glib_pollfds_poll /util/main-loop.c:232:9 +#13 0x56192230e363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#14 0x56192230e363 in main_loop_wait /util/main-loop.c:531:11 +#15 0x5619213c9599 in qemu_main_loop /softmmu/runstate.c:721:9 +#16 0x56191f6561fd in main /softmmu/main.c:50:5 +#17 0x7f4ad22e0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#18 0x56191f5a9bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1913917 b/results/classifier/deepseek-2/output/device/1913917 new file mode 100644 index 000000000..6731a4fa0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1913917 @@ -0,0 +1,35 @@ + +aarch64-virt: heap-use-after-free in gic_dist_writeb + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +writel 0x8000f00 0x5affaf +write 0x8000eff 0x1 0x0 +EOF + +Stacktrace: +../hw/intc/arm_gic.c:1419:17: runtime error: index 3068 out of bounds for type 'gic_irq_state [1020]' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1419:17 in +================================================================= +==641550==ERROR: AddressSanitizer: heap-use-after-free on address 0x629000023a85 at pc 0x55b5dfb0fbf8 bp 0x7fff95cb5870 sp 0x7fff95cb5868 +WRITE of size 1 at 0x629000023a85 thread T0 + #0 0x55b5dfb0fbf7 in gic_dist_writeb /home/alxndr/Development/qemu/build/../hw/intc/arm_gic.c:1419:17 + #1 0x55b5dfb061e2 in gic_dist_write /home/alxndr/Development/qemu/build/../hw/intc/arm_gic.c + #2 0x55b5e0809ef4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:511:12 + #3 0x55b5e0808bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #4 0x55b5e0808467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #5 0x55b5e0b98ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #6 0x55b5e0b8e71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #7 0x55b5e0b8e71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #8 0x55b5e07fad35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 + #9 0x55b5e07f3b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #10 0x55b5e1044286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #11 0x7fa997b30aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #12 0x55b5e169f363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #13 0x55b5e169f363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #14 0x55b5e169f363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #15 0x55b5e075a599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #16 0x55b5de9e71fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #17 0x7fa9975d5cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #18 0x55b5de93abc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1913926 b/results/classifier/deepseek-2/output/device/1913926 new file mode 100644 index 000000000..219d7250b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1913926 @@ -0,0 +1,30 @@ + +[QEMU User-Mode] Mesa Fails To Load RadeonSI Driver When In Docker Image + +# System Details +AMD Ryzen 7 3700U +Ubuntu 20.04 Focal Focus + +# Dockerfile + +FROM arm32v7/debian:bullseye + +RUN apt-get update && apt-get install -y mesa-utils + +ENTRYPOINT glxgears + +# Instructions For Reproduction +1. Install Docker +2. Build Docker Image: docker build --tag mesa-arm-test . +3. Run: docker run -v /tmp/.X11-unix:/tmp/.X11-unix --device /dev/dri:/dev/dri -e "DISPLAY=${DISPLAY}" mesa-arm-test + +The Output Is: + +amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-38) +amdgpu: amdgpu_device_initialize failed. +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +libGL error: failed to get magic +libGL error: failed to load driver: radeonsi + +It then appears to run using software rendering. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1914535 b/results/classifier/deepseek-2/output/device/1914535 new file mode 100644 index 000000000..febe66ce7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1914535 @@ -0,0 +1,6 @@ + +PL110 8-bit mode is not emulated correctly + +When the emulated pl110/pl111 is switched programmatically to 8-bit color depth mode, the display is drawn green and blue, but the real PL110 displays grayscale in 8-bit mode. + +The bug appears in qemu-system-arm version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8) and qemu-system-arm version 5.2.50 (v5.2.0-1579-g99ae0cd90d). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1916501 b/results/classifier/deepseek-2/output/device/1916501 new file mode 100644 index 000000000..8b2e5a3e7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1916501 @@ -0,0 +1,31 @@ + +qemu-img convert segfaults with specific URL + +Using what is currently the latest git: (commit 00d8ba9e0d62ea1c7459c25aeabf9c8bb7659462, Date: Sun Feb 21 19:52:58 2021 +0000) + +$ ./build/qemu-img convert -f qcow2 -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img out.img +Segmentation fault (core dumped) + + +Backtrace for convenience: +qemu: qemu_mutex_lock_impl: Invalid argument + +Thread 1 "qemu-img" received signal SIGABRT, Aborted. +0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +#1 0x00007ffff77ae8a4 in abort () from /lib64/libc.so.6 +#2 0x00005555556705b2 in error_exit (err=<optimized out>, msg=msg@entry=0x5555556b69a0 <__func__.31> "qemu_mutex_lock_impl") at ../util/qemu-thread-posix.c:37 +#3 0x0000555555670945 in qemu_mutex_lock_impl (mutex=0x555555ae3758, file=0x5555556827a2 "../block/curl.c", line=406) at ../util/qemu-thread-posix.c:81 +#4 0x000055555559a05b in curl_multi_do (arg=0x555555aad2a0) at ../block/curl.c:406 +#5 0x000055555566193a in aio_dispatch_handler (ctx=ctx@entry=0x555555737790, node=0x555555b14150) at ../util/aio-posix.c:329 +#6 0x0000555555662072 in aio_dispatch_handlers (ctx=0x555555737790) at ../util/aio-posix.c:372 +#7 aio_dispatch (ctx=0x555555737790) at ../util/aio-posix.c:382 +#8 0x000055555564442e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:306 +#9 0x00007ffff7cfda9f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#10 0x000055555566f2c8 in glib_pollfds_poll () at ../util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=4397000000) at ../util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:531 +#13 0x0000555555581edd in convert_do_copy (s=0x7fffffffd3a0) at ../qemu-img.c:2139 +#14 img_convert (argc=<optimized out>, argv=<optimized out>) at ../qemu-img.c:2738 +#15 0x00005555555783b1 in main (argc=7, argv=<optimized out>) at ../qemu-img.c:5536 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1917394 b/results/classifier/deepseek-2/output/device/1917394 new file mode 100644 index 000000000..919e4b2e3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1917394 @@ -0,0 +1,40 @@ + +command lspci does not show the IVSHMEM device + +qeum version: +QEMU emulator version 4.2.1 + +I met a problem when I tried to use IVSHMEM. Command lspci does not show the IVSHMEM device. +Below is the configuration from my side: + +1. guest vm xml configuration. + <shmem name='ivshmem'> + <model type='ivshmem-plain'/> + <size unit='M'>2</size> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> + </shmem> + +2. after the booting up and I found the qemu commandline ideedly have the device option: +ps aux | grep ivshmem + /usr/bin/qemu-system-x86_64 + .......(ignore other options) +-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 + +3. lspci command not shown the device. + +4. lshw command indeedly show the device: + +*-memory UNCLAIMED + description: RAM memory + product: Inter-VM shared memory + vendor: Red Hat, Inc. + physical id: 10 + bus info: pci@0000:00:10.0 + version: 01 + width: 64 bits + clock: 33MHz (30.3ns) + configuration: latency=0 + resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff + +My host and vm os is ubuntu 20.04 and version is: +#49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1920013 b/results/classifier/deepseek-2/output/device/1920013 new file mode 100644 index 000000000..6ce87a40c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1920013 @@ -0,0 +1,20 @@ + +Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest + +Attempting to pass through a PCIe device from a ppc64le host to an x86_64 guest with QEMU v5.2.0-3031-g571d413b5d (built from git master) fails with the following error: + + include/exec/memory.h:43:IOMMU_MEMORY_REGION: Object 0x10438eb00 is not an instance of type qemu:iommu-memory-region + +To reproduce this issue, simply run the following command on a POWER9 system: + + qemu-system-x86_64 -machine q35 -device vfio-pci,host=$DBSF + +Where $DBSF is a domain:bus:slot.function PCIe device address. + +This also fails with QEMU 3.1.0 (from Debian Buster), so I assume this has never worked. Helpfully, the error message it prints seems to indicate where the problem is: + + hw/vfio/spapr.c:147:vfio_spapr_create_window: Object 0x164473510 is not an instance of type qemu:iommu-memory-region + +My kernel (Linux v5.8.0 plus some small unrelated patches) is built with the page size set to 4k, so this issue shouldn't be due to a page size mismatch. And as I stated earlier, my host arch is ppc64le, so it shouldn't be an endianness issue, either. + +I assume this should be possible (in theory) since I've seen reports of others getting PCIe passthrough working with aarch64 guests on x86_64 hosts, but of course that (passthrough to weird guest arch on x86) is somewhat the opposite of what I'm trying to do (passthrough to x86 on weird host arch) so I don't know for sure. If it is possible, I'm willing to develop a fix myself, but I'm almost completely unfamiliar with QEMU's internals so if anyone has any advice on where to start I'd greatly appreciate it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1921061 b/results/classifier/deepseek-2/output/device/1921061 new file mode 100644 index 000000000..f5458463f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1921061 @@ -0,0 +1,8 @@ + +Corsair iCUE Install Fails, qemu VM Reboots + +Hi, + +I had this working before, but in the latest version of QEMU (built from master), when I try to install Corsair iCUE, and it gets to the driver install point => my Windows 10 VM just reboots! I would be happy to capture logs, but ... what logs exist for an uncontrolled reboot? Thinking they are lost in the reboot :-(. + +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1921635 b/results/classifier/deepseek-2/output/device/1921635 new file mode 100644 index 000000000..081b4a051 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1921635 @@ -0,0 +1,35 @@ + +ESP SCSI adapter not working with DOS ASPI drivers + +I have been trying to install the DOS ASPI drivers for the ESP scsi card. Both in am53c974 and dc390 modes. Neither works but they don't work in different ways. + +The following things appear to be problematic: + +* The am53c974 should work with the PcSCSI drivers (AMSIDA.SYS) but the ASPI driver never manages to get past initializing the card. The VM never continues. +* The dc390 ASPI driver fares a little better. The ASPI driver loads and is semi-functional but the drivers for the peripherals don't work. + - ASPI.SYS (creative name) loads + - TRMDISK.SYS fails to load when a cd-drive is attached and will crashs scanning the scsi-id where the cd drive is attached + - TRMDISK.SYS loads without a CD drive attached but fails to read any scsi-hd devices attached. The TFDISK.EXE formatter crashes. + - TRMCD.SYS loads, but can not detect any CD drives. + +The various permutations: +am53c974 hang on ASPI driver load: (CD only attached) + +~/src/qemu/build/qemu-system-i386 -m 64 -device am53c974,id=scsi0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda am53c974_aspi.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 crash because of CDROM attachment and loading TRMDISK.SYS (Only CD attached) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, but TRMDISK.SYS not working (TFDISK.EXE will crash) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0,logical_block_size=512 -drive file=small.qcow2,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, TRMDISK.SYS not loaded, only TRMCD.SYS. CDROM not detected +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_cd.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +All of these tests were done on 7b9a3c9f94bcac23c534bc9f42a9e914b433b299 as well as the 'esp-next' branch found here: https://github.com/mcayland/qemu/tree/esp-next + +The bios file is a seabios master with all int13 support disabled. With it enabled even less works but I figured this would be a seabios bug and not a qemu one. + +The actual iso and qcow2 files used don't appear the matter. the 'small.qcow2' is an empty drive of 100MB. I have also tried other ISOs in the CD drives, or even not put any cd in the drives with the same results. + +I will attach all of the above images. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1922252 b/results/classifier/deepseek-2/output/device/1922252 new file mode 100644 index 000000000..876c4bc0e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1922252 @@ -0,0 +1,8 @@ + +[feature request] webcam support + +Please + +I am impatient to get something as "-device usb-webcam" to share dynamically the webcam between host and guest. + +Thanks \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1922325 b/results/classifier/deepseek-2/output/device/1922325 new file mode 100644 index 000000000..74cd68791 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1922325 @@ -0,0 +1,24 @@ + +s390x-virtio-gpu-ccw module unnecessary? + +Hi + +Test building latest 6.0.0 release candidate on x86_64 host. A new module has appeared: + +/usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so + +Unless I'm missing something obvious, it would appear to be only useful on s390x platform. + +Why would I need this? For me it doesn't seem to do much: + +$ nm -D /usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so + w __cxa_finalize + w __gmon_start__ + w _ITM_deregisterTMCloneTable + w _ITM_registerTMCloneTable +00000000000010f0 T qemu_module_dummy +0000000000001100 T qemu_stamp_0d4aa0592256528f9885a56f182883665e60f8ec + +Bug or ... ? + +Thanks \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1922391 b/results/classifier/deepseek-2/output/device/1922391 new file mode 100644 index 000000000..c2166c5a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1922391 @@ -0,0 +1,57 @@ + +qemu-system-ppc assertion "!mr->container" failed + +Hi, + +I'm trying to run the NetBSD/macppc 8.2 installer (which is 32-bit ppc) in qemu-system-ppc +version 5.2.0, and I'm hitting this assertion failure quite a bit into the "unpacking sets" +part of the installation procedure, unpacking from the install iso image. + +Qemu is run on a NetBSD/amd64 9.1 host system. The stack backtrace from the core file is + +Program terminated with signal SIGABRT, Aborted. +#0 0x000078859a36791a in _lwp_kill () from /usr/lib/libc.so.12 +[Current thread is 1 (process 1)] +(gdb) where +#0 0x000078859a36791a in _lwp_kill () from /usr/lib/libc.so.12 +#1 0x000078859a3671ca in abort () from /usr/lib/libc.so.12 +#2 0x000078859a2a8507 in __assert13 () from /usr/lib/libc.so.12 +#3 0x000000015a3c19c0 in memory_region_finalize () +#4 0x000000015a3fef1c in object_unref () +#5 0x000000015a3feee6 in object_unref () +#6 0x000000015a374154 in address_space_unmap () +#7 0x000000015a276551 in pmac_ide_atapi_transfer_cb () +#8 0x000000015a150a59 in dma_blk_cb () +#9 0x000000015a46a1c7 in blk_aio_complete () +#10 0x000000015a5a617d in coroutine_trampoline () +#11 0x000078859a264150 in ?? () from /usr/lib/libc.so.12 +Backtrace stopped: Cannot access memory at address 0x7884894ff000 +(gdb) + +I start qemu with this small script: + +--- +#!/bin/sh + +MEM=3g +qemu-system-ppc \ + -M mac99,via=pmu \ + -m $MEM \ + -nographic \ + -drive id=hda,format=raw,file=disk.img \ + -L pc-bios \ + -netdev user,id=net0,hostfwd=tcp::2223-:22,ipv6=off \ + -net nic,model=rtl8139,netdev=net0 \ + -boot d \ + -cdrom NetBSD-8.2-macppc.iso +--- + +and boot the install kernel with "boot cd:ofwboot.xcf". If someone wants +to replicate this I can provide more detailed instructions to repeat the +procedure I used to start the install. + +Any hints about what more to look for? + +Regards, + +- Håvard \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1922611 b/results/classifier/deepseek-2/output/device/1922611 new file mode 100644 index 000000000..4a7a9e1cd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1922611 @@ -0,0 +1,44 @@ + +Acceptance Tests: migration fails on sparc target + +QEMU fails migration when using a sparc target. + +This cab be verified/reproduced with the `tests/acceptance/migration.py` test. Running it with: + + $ make check-venv + $ ./tests/venv/bin/avocado --show=test run -p qemu_bin=./qemu-system-sparc tests/acceptance/migration.py:Migration.test_migration_with_tcp_localhost + +Right after a QMP `query-migrate` is executed, communication with the monitor is lost: + +>>> {'execute': 'query-migrate'} +<<< {'timestamp': {'seconds': 1617667984, 'microseconds': 330282}, 'event': 'STOP'} +<<< {'return': {'blocked': False, 'status': 'completed', 'setup-time': 0, 'downtime': 1, 'total-time': 15, 'ram': {'total': 135274496, 'postcopy-requests': 0, 'dirty-sync-count': 2, 'multifd-bytes': 0, 'pages-per-second': 0, 'page-size': 4096, 'remaining': 0, 'mbps': 301.2234666666667, 'transferred': 528703, 'duplicate': 33202, 'dirty-pages-rate': 0, 'skipped': 0, 'normal-bytes': 229376, 'normal': 56}}} +>>> {'execute': 'query-migrate'} + +Reproduced traceback from: /var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/core/test.py:756 +Traceback (most recent call last): + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 80, in test_migration_with_tcp_localhost + self.do_migrate(dest_uri) + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 69, in do_migrate + self.assert_migration(source_vm, dest_vm) + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 41, in assert_migration + args=(dst_vm,)) + File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/utils/wait.py", line 34, in wait_for + output = func(*args, **kwargs) + File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 31, in migration_finished + return vm.command('query-migrate')['status'] in ('completed', 'failed') + File "/home/cleber/src/qemu/python/qemu/machine.py", line 572, in command + return self._qmp.command(cmd, **qmp_args) + File "/home/cleber/src/qemu/python/qemu/qmp.py", line 284, in command + ret = self.cmd(cmd, kwds) + File "/home/cleber/src/qemu/python/qemu/qmp.py", line 278, in cmd + return self.cmd_obj(qmp_cmd) + File "/home/cleber/src/qemu/python/qemu/qmp.py", line 256, in cmd_obj + self.__sock.sendall(json.dumps(qmp_cmd).encode('utf-8')) +BrokenPipeError: [Errno 32] Broken pipe + +The qemu-system-sparc binary outputs: + + qemu-system-sparc: warning: nic lance.0 has no peer + qemu-system-sparc: Missing section footer for sysbusespscsi + qemu-system-sparc: load of migration failed: Invalid argument \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1923663 b/results/classifier/deepseek-2/output/device/1923663 new file mode 100644 index 000000000..4cdc78d45 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1923663 @@ -0,0 +1,20 @@ + +Can't(?) disable default floppy drive any more in qemu 6.0 + +There's a documented change in qemu 6.0: + +https://qemu-project.gitlab.io/qemu/system/removed-features.html#floppy-controllers-drive-properties-removed-in-6-0 + +where you can't configure floppy controller device properties with -global any more. However, there's a thing you could do with the old parameter which I can't figure out a way to do with the documented replacement. openQA passed exactly this argument: + +-global isa-fdc.driveA= + +and that has the effect of removing/disabling the default floppy drive/controller. If you just run `qemu-system-i686` (no other args) you'll see the VM briefly try to boot from a floppy drive; if you run `qemu-system-i686 -global isa-fdc.driveA=` (with an earlier version of qemu, obviously) you'll see it does not do so. + +I can't see a way to do this with `-device floppy`. Going by the docs, the equivalent should be: + +-device floppy,unit=0,drive= + +but that does not seem to have the same effect. If you run `qemu-system-i686 -device floppy,unit=0,drive=`, it still tries to boot from a floppy drive. + +I see there's a -nodefaults option that disables *all* default devices, but I don't think that's what we want here either. We might want the other default devices, we just don't want the floppy drive. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1924738 b/results/classifier/deepseek-2/output/device/1924738 new file mode 100644 index 000000000..03e9ba15f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1924738 @@ -0,0 +1,27 @@ + +Failed to restore domain - error load load virtio-balloon:virtio + +I noticed a domain restore error on my virtual machines. +I can't reproduce the error on a test virtual machine. + +sudo virsh save linux2020 /var/lib/libvirt/qemu/save/linux2020.save +Domain 'linux2020' saved to /var/lib/libvirt/qemu/save/linux2020.save + +sudo virsh restore /var/lib/libvirt/qemu/save/linux2020.save +error: Failed to restore domain from /var/lib/libvirt/qemu/save/linux2020.save +error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'server' deprecated +Please use server=on instead +qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'nowait' deprecated +Please use wait=off instead +qemu-system-x86_64: -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on: warning: short-form boolean option 'disable-ticketing' deprecated +Please use disable-ticketing=on instead +2021-04-16T09:47:15.037700Z qemu-system-x86_64: VQ 0 size 0x80 < last_avail_idx 0x0 - used_idx 0xcccc +2021-04-16T09:47:15.037737Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2021-04-16T09:47:15.037744Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-balloon' +2021-04-16T09:47:15.037849Z qemu-system-x86_64: load of migration failed: Operation not permitted + +If in the machine configuration replace +<type arch="x86_64" machine="pc-i440fx-5.1">hvm</type> +to +<type arch="x86_64" machine="pc-i440fx-5.0">hvm</type> +the virtual machine is recovering normally \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1925 b/results/classifier/deepseek-2/output/device/1925 new file mode 100644 index 000000000..536873e1b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1925 @@ -0,0 +1,12 @@ + +RISC-V 64 System Emulator fdt imporperly created after machine init is done +Description of problem: +In commit 49554856 the creation of FDT is moved to `virt_machine_done()` +However, adding guest loader device requires the presence of fdt at `hw/core/guest-loader.c:50` when the fdt ptr is still 0x0. +Thus adding of guest loader device will fail. +Steps to reproduce: +1. Compile Qemu with riscv64 system emulator target +2. Compile Xen hypervisor platform (not necessary) +3. Instruct Qemu start with virt machine and any valid guest-loader device specification. +Additional information: +Commit that changes order of fdt creation: 49554856f0b6f622ab6afdcc275d4ab2ecb3625c diff --git a/results/classifier/deepseek-2/output/device/1925109 b/results/classifier/deepseek-2/output/device/1925109 new file mode 100644 index 000000000..3c63a8844 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1925109 @@ -0,0 +1,18 @@ + +usbredirparser: bulk transfer length exceeds limits + +2021-04-20T01:26:36.662244Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:26:36.662276Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +2021-04-20T01:26:57.670412Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:26:57.670445Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +2021-04-20T01:37:01.920613Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:37:01.920624Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +host: +Linux version 5.11.15-arch1-2 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 +guest: +win10 20H2 +usb device: +Bus 002 Device 007: ID 0781:55ab SanDisk Corp. SanDisk 3.2Gen1 +size 250G + +https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirparser/usbredirparser.c#L32 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1925496 b/results/classifier/deepseek-2/output/device/1925496 new file mode 100644 index 000000000..9c2e8616c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1925496 @@ -0,0 +1,65 @@ + +nvme disk cannot be hotplugged after removal + +Hello, + +When I try to re-add an nvme disk shortly after removing it, I get an error about duplicate ID. + +See the following commands to reproduce. This happens consistently on all VMs that I tested: + + +attach +========== + +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; +$VAR1 = { + 'execute' => 'device_add', + 'arguments' => { + 'serial' => 'nvme1', + 'drive' => 'drive-nvme1', + 'driver' => 'nvme', + 'id' => 'nvme1' + } + }; + + +detach +=========== +$VAR1 = { + 'arguments' => { + 'id' => 'nvme1' + }, + 'execute' => 'device_del' + }; +$VAR1 = { + 'execute' => 'human-monitor-command', + 'arguments' => { + 'command-line' => 'drive_del drive-nvme1' + } + }; + +reattach +=========== +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; + + +and I get: +"Duplicate ID 'drive-nvme1' for drive" + +although it does not show up in query-block or query-pci anymore after the first detach. + + +Is this a bug or am I missing something? Please advise. + +Best regards, +Oguz \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1925966 b/results/classifier/deepseek-2/output/device/1925966 new file mode 100644 index 000000000..dfdc1a830 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1925966 @@ -0,0 +1,34 @@ + +Win10 guest freezes randomly + +In addition to bug #1916775, my Win10 Home guest freezes randomly and infrequently. Unlike bug +#1916775, this is unrecoverable and I see on the host (Debian 4.19.171-2) via iotop that all disk IO has stopped. My only recourse is a hard reset of the guest. + +My setup uses PCI-pass-through graphics (GTX 1650), host cpu (Ryzen 7 3800XT). It seems to occur more frequently when I plug in 3 monitors rather than 2 into the pass-through graphics card. It occurs whether or not I use the qcow disk drive. + +qemu-system-x86_64 + -cpu host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy + -smp 8 + -rtc clock=host,base=localtime + -machine type=q35,accel=kvm,kernel_irqchip=on + -enable-kvm + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd + -m 32G + -usb + -device usb-tablet + -vga none + -serial none + -parallel none + -boot cd + -nographic + -device usb-host,vendorid=0x045e,productid=0x00db + -device usb-host,vendorid=0x1bcf,productid=0x0005 + -drive id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2 + -drive id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv + -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on + -device vfio-pci,host=09:00.1,addr=0x02.0x1 + -device vfio-pci,host=09:00.2,addr=0x02.0x2 + -device vfio-pci,host=09:00.3,addr=0x02.0x3 + -netdev tap,id=netid,ifname=taplan,script=no,downscript=no + -device e1000,netdev=netid,mac=52:54:00:01:02:03 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1926111 b/results/classifier/deepseek-2/output/device/1926111 new file mode 100644 index 000000000..ce2fcfe95 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1926111 @@ -0,0 +1,86 @@ + +Assertion `tx_queue_idx <= s->txq_num' failed in vmxnet3_io_bar0_write + +=== Stacktrace === + +qemu-fuzz-i386: ../hw/net/vmxnet3.c:1096: void vmxnet3_io_bar0_write(void *, hwaddr, uint64_t, unsigned int): Assertion `tx_queue_idx <= s->txq_num' failed. +==602353== ERROR: libFuzzer: deadly signal +#5 0x7fe4b93a7ce0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7fe4b9391536 in abort stdlib/abort.c:79:7 +#7 0x7fe4b939140e in __assert_fail_base assert/assert.c:92:3 +#8 0x7fe4b93a0661 in __assert_fail assert/assert.c:101:3 +#9 0x563e6cf5ebb5 in vmxnet3_io_bar0_write hw/net/vmxnet3.c:1096:9 +#10 0x563e6eefdb00 in memory_region_write_accessor softmmu/memory.c:491:5 +#11 0x563e6eefcfdd in access_with_adjusted_size softmmu/memory.c:552:18 +#12 0x563e6eefac90 in memory_region_dispatch_write softmmu/memory.c:1502:16 +#13 0x563e6e834e16 in flatview_write_continue softmmu/physmem.c:2746:23 +#14 0x563e6e81cd38 in flatview_write softmmu/physmem.c:2786:14 +#15 0x563e6e81c868 in address_space_write softmmu/physmem.c:2878:18 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -machine q35 -nodefaults -device vmxnet3,netdev=net0 -netdev \ +user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000814 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xcf8 0x80000815 +outl 0xcfc 0xffff00b5 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0xff00b020 0x4 0x0000feca +write 0xe0000630 0x1 0x00 +EOF + + +=== Testcase === + +/* + * Autogenerated Fuzzer Test Case + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +static void test_fuzz(void) { + QTestState *s = qtest_init(" -display none , -m 512M -machine q35 -nodefaults " + "-device vmxnet3,netdev=net0 -netdev user,id=net0"); + qtest_outl(s, 0xcf8, 0x80000810); + qtest_outl(s, 0xcfc, 0xe0000000); + qtest_outl(s, 0xcf8, 0x80000814); + qtest_outl(s, 0xcf8, 0x80000804); + qtest_outw(s, 0xcfc, 0x7); + qtest_outl(s, 0xcf8, 0x80000815); + qtest_outl(s, 0xcfc, 0xffff00b5); + qtest_bufwrite(s, 0x0, "\xe1", 0x1); + qtest_bufwrite(s, 0x1, "\xfe", 0x1); + qtest_bufwrite(s, 0x2, "\xbe", 0x1); + qtest_bufwrite(s, 0x3, "\xba", 0x1); + qtest_bufwrite(s, 0xff00b020, "\x00\x00\xfe\xca", 0x4); + qtest_bufwrite(s, 0xe0000630, "\x00", 0x1); + qtest_quit(s); +} +int main(int argc, char **argv) { + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + +=== OSS-Fuzz Report === +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33603 +https://oss-fuzz.com/testcase?key=6071483232288768 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1926231 b/results/classifier/deepseek-2/output/device/1926231 new file mode 100644 index 000000000..e05b65fe7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1926231 @@ -0,0 +1,38 @@ + +SCSI passthrough of SATA cdrom -> errors & performance issues + +qemu 5.0, compiled from git + +I am passing through a SATA cdrom via SCSI passthrough, with this libvirt XML: + + <hostdev mode='subsystem' type='scsi' managed='no' sgio='unfiltered' rawio='yes'> + <source> + <adapter name='scsi_host3'/> + <address bus='0' target='0' unit='0'/> + </source> + <alias name='hostdev0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </hostdev> + +It seems to mostly work, I have written discs with it, except I am getting errors that cause reads to take about 5x as long as they should, under certain circumstances. It appears to be based on the guest's read block size. + +I found that if on the guest I run, say `dd if=$some_large_file bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much is being read by a factor of about 2. Also many kernel messages like this happen on the guest: + +[ 190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s +[ 190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command [current] +[ 190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated +[ 190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00 00 80 00 +[ 190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 + +If I change to bs=131072 the errors stop and performance is normal. + +(262144 happens to be the block size ultimately used by md5sum, which is how I got here) + +I also ran strace on the qemu process while it was happening, and noticed SG_IO calls like this: + +21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0, dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +[etc] + +I suspect qemu is the culprit because I have tried a 4.19 guest kernel as well as a 5.9 one, with the same result. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/1927408 b/results/classifier/deepseek-2/output/device/1927408 new file mode 100644 index 000000000..7c8efa815 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1927408 @@ -0,0 +1,49 @@ + +USB Ethernet device (RNDIS) does not work on several tested operating systems + +The USB ethernet device does not work on most versions of operating systems I have tested. For each operating system the command to use this device was: -netdev user,id=mynet1 -device usb-net,netdev=mynet1. + + +Windows 2000 (qemu-system-i386): +- failed to load a driver for the device + + +Windows 7 (qemu-system-x86_64): +- Did not find a driver +- Followed the directions here: https://developer.toradex.com/knowledge-base/how-to-install-microsoft-rndis-driver-for-windows-7 +-- The device failed to start with error 10. +- Did see this message in the terminal on the host: +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa + + +Mac OS 10.4.11 (qemu-system-ppc): +- It actually works. +- did see these messages in the terminal on the host: +usbnet: failed control transaction: request 0x2143 value 0x1c index 0x0 length 0x0 +usbnet: failed control transaction: request 0x2143 value 0x1e index 0x0 length 0x0 + + +Mac OS 10.8.5 (qemu-system-x86_64): +- Fails to obtain IP address using DHCP. +- The Network pane does say the device is connected. +- A self-assigned IP address is given: 169.254.186.53. +-- It still did not work +- Did see this message in the terminal of the host: +usbnet: failed control transaction: request 0x2143 value 0x1c index 0x0 length 0x0 +usbnet: failed control transaction: request 0x2143 value 0x1e index 0x0 length 0x0 + + +Mac OS 10.2.3 (qemu-system-ppc): +- Did not appear to detect the USB NIC. Did not see it in the network pane. +- Apple System Profiler does see this device. +- Saw this message in there terminal of the host: qemu-system-ppc: Slirp: Failed to send packet, ret: -1 + + +Mac OS 9.2 (qemu-system-ppc): +- Apple System Profiler does show the device connected. +- The Tcp/ip control panel did not detect this device. + + +My guess is this device is buggy. If anyone has any tips or suggestions please let me know. + +Thank you. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/193 b/results/classifier/deepseek-2/output/device/193 new file mode 100644 index 000000000..037a50209 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/193 @@ -0,0 +1,2 @@ + +piix crashes on mips when using multiple cpus diff --git a/results/classifier/deepseek-2/output/device/1933 b/results/classifier/deepseek-2/output/device/1933 new file mode 100644 index 000000000..8fbadd312 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1933 @@ -0,0 +1,42 @@ + +qemu 8.1.1 and 7.2.6 live migration with qcow2 attached to vm using postcopy crashes +Description of problem: +Live migrating a vm with a qcow2 disk attached using postcopy will cause vm to crash during migration. +Steps to reproduce: +1. Create a generic vm and attach a qcow2 file to the vm. +<disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/var/lib/libvirt/images/jlow2.qcow2'/> + <target dev='vda' bus='virtio'/> + <boot order='1'/> +</disk> + +2. virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error --postcopy --postcopy-after-precopy --timeout 1 --timeout-postcopy qemu+tcp://10.18.64.118/system + +vm will start migrating and then pause on the source and be shut down on the target once migration switches to postcopy + +Migration: [33.08 %]error: internal error: QEMU unexpectedly closed the monitor (vm='jlow2'): 2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable +2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable +qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed. + + +Logs from source + +2023-10-12 06:23:43.412+0000: initiating migration + +2023-10-12T06:23:44.362392Z qemu-system-x86_64: failed to save SaveStateEntry with id(name): 3(ram): -5 + +2023-10-12T06:23:44.362485Z qemu-system-x86_64: Detected IO failure for postcopy. Migration paused. + +Logs from target + +2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable + +2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable + +qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed. +2023-10-12 06:23:44.408+0000: shutting down, reason=failed + +If postcopy is disabled with command below, migration will succeed: + +virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error qemu+tcp://10.18.64.118/system diff --git a/results/classifier/deepseek-2/output/device/1935 b/results/classifier/deepseek-2/output/device/1935 new file mode 100644 index 000000000..f04fb102a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1935 @@ -0,0 +1,6 @@ + +migrate problem when add SCSI reservations with iSCSI backed disks +Description of problem: +When performing migrations with QEMU using iSCSI as the backend, it's common for the migration to start successfully. However, in scenarios where Persistent Reservations are added in the guest, the target host, under the precopy mode, preempts the Persistent Reservations right from the beginning, causing migration issues. Is there a way to control the Persistent Reservations lock within QEMU at an appropriate time, ensuring that it's only preempted during the switchover phase？ + +Isn't libiscsi thread-safe? Can multiple threads operate on Persistent Reservations lock simultaneously? diff --git a/results/classifier/deepseek-2/output/device/1938 b/results/classifier/deepseek-2/output/device/1938 new file mode 100644 index 000000000..92f2494f2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1938 @@ -0,0 +1,37 @@ + +[ARM/PL011] Wrong UART register spacing reported in DBG2/SPCR +Description of problem: +QEMU reports the UART address on aarch64 (for PL011 UART) via the ACPI DBG2 and SPCR tables using the ACPI GAS structure. According to MSFT documentation at https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table: + +> * The Register Bit Width field contains the register stride and must be a power of 2 that is at least as large as the access size. On 32-bit platforms this value cannot exceed 32. On 64-bit platforms this value cannot exceed 64. +> * The Access Size field is used to determine whether byte, WORD, DWORD, or QWORD accesses are to be used. QWORD accesses are only valid on 64-bit architectures. + +For the PL011, the MMIO registers are: +* spaced 4 bytes apart; therefore the reported bit width should be 32 instead of 8. +* 16 bits wide; therefore the access width should be 2 instead of 1. + +In other words: +``` +diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c +index 6b674231c2..cd284676d7 100644 +--- a/hw/arm/virt-acpi-build.c ++++ b/hw/arm/virt-acpi-build.c +@@ -482,7 +482,7 @@ build_spcr(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) + build_append_int_noprefix(table_data, 3, 1); /* ARM PL011 UART */ + build_append_int_noprefix(table_data, 0, 3); /* Reserved */ + /* Base Address */ +- build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1, ++ build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2, + vms->memmap[VIRT_UART].base); + /* Interrupt Type */ + build_append_int_noprefix(table_data, +@@ -673,7 +673,7 @@ build_dbg2(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) + build_append_int_noprefix(table_data, 34, 2); + + /* BaseAddressRegister[] */ +- build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1, ++ build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2, + vms->memmap[VIRT_UART].base); + + /* AddressSize[] */ +``` diff --git a/results/classifier/deepseek-2/output/device/1940 b/results/classifier/deepseek-2/output/device/1940 new file mode 100644 index 000000000..84c91f546 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1940 @@ -0,0 +1,21 @@ + +Saving vm with shared folder results in Error: State blocked by non-migratable device '000.../vhost-user-fs' +Description of problem: +Saving a vm with savevm in the QEMU Monitor with a shared folder causes the following error message: +`Error: State blocked by non-migratable device '0000:00:05.0/vhost-user-fs'` +Steps to reproduce: +1. Get an qcow2 image that can boot (not sure if working qcow2 image is actually needed) +2. Start virtiofsd with this /usr/libexec/virtiofsd --socket-path=/tmp/virtiofs_socket -o source=/path/to/share +3. Run qemu-system-x86_64 -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem -smp 2 -hda image.qcow2 -vga qxl -virtfs local,path=/path/to/share,mount_tag=share,security_model=passthrough,id=virtiofs -chardev socket,id=char0,path=/tmp/virtiofs_socket -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=share +4. Let the image boot and/or go into the QEMU monitor. +5. type savevm testvm +6. See error. +Additional information: +This happens with both the legacy virtio-fs and the rust version. + +According to the first reply to https://gitlab.com/virtio-fs/virtiofsd/-/issues/81 there needs to be "a lot of changes not only in virtiofsd but also in the rust-vmm crates and qemu (and maybe in the vhost-user protocol)" so I'm reporting this here in the hopes it will speed something up. + +I followed the following to get virtiofsd working with command line QEMU: +https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system + +This is blocking our migration from VirtualBox because it doesn't have problems like this. The least I need is a work around or alternative shared filesystem. We are trying to avoid networked shares. diff --git a/results/classifier/deepseek-2/output/device/1943 b/results/classifier/deepseek-2/output/device/1943 new file mode 100644 index 000000000..ffa17b072 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1943 @@ -0,0 +1,25 @@ + +Weird error trying to autodetect CHS disk geometry +Description of problem: +Error: "SSD Read Error" + +Something about the contents of the disk causes qemu to wildly misdetect the disk geometry. +This disk started as a blank disk, and had a FAT filesystem written to it from inside it; thus +writing the detected geometry to the disk. And this caused the detected geometry to change to +something nonsensical. +Steps to reproduce: +1. Unpack the attached [hd.bz2](/uploads/53f5bb00cdd563223bea1f7a0f86fe1c/hd.bz2) to hd.img +2. Run qemu -hda hd.img +3. Observe error +Additional information: +The following command appears to fix the problem; however it is wrong: + +qemu -drive if=none,id=dr,file=hd.img -device ide-hd,drive=dr,cyls=1023,heads=16,secs=63 + +The problem with this command is this command yields only 504MB instead of the 512MB the +disk is actually formatted to be. CHS translation should be enabled on this disk but won't +be with this command. + +This command was copied essentially blindly from "Removed features" because that's what comes +up for a google search for "qemu specify geometry" and I don't understand the command well +enough to correct it. diff --git a/results/classifier/deepseek-2/output/device/1978 b/results/classifier/deepseek-2/output/device/1978 new file mode 100644 index 000000000..7d314a0ab --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1978 @@ -0,0 +1,6 @@ + +sifive_e : erroneous CLINT frequency +Description of problem: +CLINT's `mtime` updates at a clock frequency of [10 MHz](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/riscv/sifive_e.c?ref_type=heads#L228), whereas [SiFive documentation](https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf?_gl=1*w2ieef*_ga*MTcyNDI2MjM0Ny4xNjk2ODcwNTM3*_ga_T369JS7J9N*MTY5Njg3MDUzNy4xLjAuMTY5Njg3MDUzNy42MC4wLjA.) shows that its clock frequency is 32.768 kHz (i.e., the RTC clock). + +This difference leads to unexpected timing behavior. Due to the difference, it can even trigger multiple nested interrupts as the IRQ routine is not able to return before a new timer interrupt is triggered. diff --git a/results/classifier/deepseek-2/output/device/198 b/results/classifier/deepseek-2/output/device/198 new file mode 100644 index 000000000..36929353c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/198 @@ -0,0 +1,2 @@ + +USB Ethernet device (RNDIS) does not work on several tested operating systems diff --git a/results/classifier/deepseek-2/output/device/1982 b/results/classifier/deepseek-2/output/device/1982 new file mode 100644 index 000000000..fae16127c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1982 @@ -0,0 +1,10 @@ + +PS/2 mouse and keyboard not disabled when adding USB devices +Description of problem: +Documentation (such as https://www.qemu.org/docs/master/system/qemu-manpage.html or https://www.qemu.org/docs/master/system/devices/usb.html) says that enabling a USB keyboard or mouse (or tablet) will disable the PS/2 equivalent, but it seems both are present instead. +Steps to reproduce: +1. Pass a `-usbdevice` or `-device` option to QEMU. +2. Boot Haiku. +3. Find two identical devices in Preferences > Input, both `Extended PS/2 Mouse 1` and `USB Tablet 1`, as well as `AT Keyboard 1` and `USB Keyboard 1`. +Additional information: +The content of /var/log/syslog, which shows discovery of PS/2 devices: [syslog.zst](/uploads/7ed067538c94edfdbaf35ec92a422c68/syslog.zst) diff --git a/results/classifier/deepseek-2/output/device/1986 b/results/classifier/deepseek-2/output/device/1986 new file mode 100644 index 000000000..29e1146ac --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1986 @@ -0,0 +1,15 @@ + +windows install fails with error 0x80070001 +Description of problem: +I have a windows vm executed via libvirt, I run it on a physical drive passing it into the guest. when I pass it via sata pt and try to install windows 11 on it, the install fails with error 0x80070001. I had an installation there which resulted with periodic bosd when sata pt was used. +if I pass the /dev node, I don't get the errors but the performance is horrible due to high hdd usage +I've tested the same setup with ubuntu, doing read and write to the device of multiple GB (200GB~), no issue at all. +I've opened an issue at virtio-win and it was closed claiming it is a sata pt issue after trying latest virtio-win. +Steps to reproduce: +1. define a sata virtio controller +2. pass a physical sata drive to the guest attached to the sata controller define in step 1 +3. define a windows iso as cdrom +4. try to install windows on the device +Additional information: +[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt) +[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt) diff --git a/results/classifier/deepseek-2/output/device/1991 b/results/classifier/deepseek-2/output/device/1991 new file mode 100644 index 000000000..cef788223 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1991 @@ -0,0 +1,65 @@ + +error "hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached" in qemu-system-hppa +Description of problem: +The installation phase terminates with a failed assertion in qemu: +``` +... +Rebooting the system +reboot: Restarting system +SeaBIOS wants SYSTEM RESET. +*************************** +** +ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached +Bail out! ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached +Aborted (core dumped) +``` +Steps to reproduce: +``` +PATH=$HOME/inst-qemu/8.2.0-rc0/bin:$PATH +``` + +Create empty disk: +``` +qemu-img create -f qcow2 t2sde.qcow2 10G +``` + +Pull kernel and initrd out of the installation CD: +``` +sudo mount -r -t iso9660 -o loop t2-23.6-hppa-minimal-desktop-gcc-glibc.iso /mnt +mkdir boot-for-install +cp -p /mnt/boot/* boot-for-install/ +sudo umount /mnt +``` + +Run installer: +``` +machine_args="-M C3700 -m 256" +disk_args="-drive file=t2sde.qcow2,format=qcow2,id=hd0" +net_args="" +#display_args="-monitor stdio -display gtk" +display_args="-nographic" +common_args="$machine_args $disk_args $net_args $display_args" +qemu-system-hppa $common_args \ + -kernel boot-for-install/vmlinux-6.3.7-t2 -initrd boot-for-install/initrd-6.3.7-t2 \ + -drive file=t2-23.6-hppa-minimal-desktop-gcc-glibc.iso,if=scsi,bus=0,unit=2,media=cdrom +``` + +``` +Serial terminal: <Enter> or console +# install +Partition: + fdisk + n p 1 <Enter> <Enter> + w +On /dev/sda1: Create filesystem of type ext3 with mount point / +Install the system +Full install (all packages). +Keyboard: us +Root password: t2 +Time zone: Europe/Berlin +Locale: -- +Finally: <Back> +Then: <Exit> +``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/1997 b/results/classifier/deepseek-2/output/device/1997 new file mode 100644 index 000000000..7714543c5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1997 @@ -0,0 +1,21 @@ + +Disk corruption on ARM64 (Apple Silicon) Linux VMs +Description of problem: +aarch64 Linux VMs will encounter disk corruption if they're set up with a filesystem that will notice it when it happens, e.g. BTRFS. This seems to be across the board with products, including Apple Hypervisor Framework, or just QEMU, so it very well might be an aarch64 Linux bug. +Steps to reproduce: +1. Install an aarch64 Linux VM using BTRFS as the root filesystem. ZFS might recognize silent corruption readily as well. +2. Run `stress-ng --iomix 4` +3. Check your `dmesg` and/or `btrfs check --force <device>` to check for filesystem corruption. +Additional information: +This is discussed in two other tickets, but I'm hoping to get more attention to the problem here. +[https://github.com/lima-vm/lima/issues/1957](https://github.com/lima-vm/lima/issues/1957) +[](https://github.com/utmapp/UTM/issues/4840) + + + + + +I can't seem to figure out how to upload images, but you can probably get to the image that I'm trying to share somehow... + + +``` diff --git a/results/classifier/deepseek-2/output/device/1998 b/results/classifier/deepseek-2/output/device/1998 new file mode 100644 index 000000000..7849f2057 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/1998 @@ -0,0 +1,28 @@ + +acpihp does not work with some common guest kernels +Description of problem: +for pc-q35 6.1, 7.2, any guest kernel with `ACPI: Core revision` < 20230331, can not hot plug the nvidia GPUs. +So basically only guest kernel >= 6.5 can make it work so far. +But majority of server kernels are still at 4.18, 5.x. I wonder if it possible to be fixed? +I also don't know is this qemu bug? bios bug? or actually ACPIA's bug? + +journal -k report error like following: +``` +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: no space for [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: failed to assign [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 6: assigned [mem 0x81800000-0x8187ffff pref] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 5: assigned [io 0xa000-0xa07f] +Nov 11 17:53:00 VMTEST kernel: nvidia 0000:08:00.0: enabling device (0000 -> 0003) +Nov 11 17:53:00 VMTEST kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: + NVRM: BAR0 is 0M @ 0x0 (PCI:0000:08:00.0) +Nov 11 17:53:00 VMTEST kernel: nvidia: probe of 0000:08:00.0 failed with error -1 +``` +Steps to reproduce: +1. run the instance as I described above +2. in qemu monitor: device_add vfio-pci,host=0000:06:00.0,id=gpu0,bus=pci.8 +3. login to the vm console then nvidia-smi to see the failure + +workaround: +`ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off` to disable the acpihp then pciehp can make it work. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2001 b/results/classifier/deepseek-2/output/device/2001 new file mode 100644 index 000000000..991397d1f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2001 @@ -0,0 +1,44 @@ + +qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster. +Description of problem: +qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster. +Steps to reproduce: +create raw and qcow2 disk + +1. qemu-img create -f raw lvm_volume_1.raw 12G +2. qemu-img create -f qcow2 lvm_volume_1.qcow2 12G + + install a centos OS + +3. qemu-system-x86_64 -m 4096 -drive file=lvm_volume_1.qcow2,format=qcow2,index=0 -nographic -cdrom CentOS-8.3.2011-x86_64-dvd1.iso -vnc :25 + + convert the qcow2 OS disk to q raw OS disk + +4. qemu-img convert -f qcow2 -O raw ./lvm_volume_1.qcow2 ./lvm_volume_1.raw + + create a qemu-rbd process + +5. qemu-nbd --fork -x node1 -p 1238 rbd:cephpool- test/volume_1:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx + + boot the raw OS disk + +6. qemu-system-x86_64 -hda ./lvm_volume_1.raw -m 4096 -smp 4 -vnc :25 -monitor stdio + + migrate the raw OS disk to a ceph volume + +7. drive_mirror -n -f #block125 nbd:localhost:1238:exportname=node1 raw + + check the rbd volume USED size in ceph cluster + "rbd du cephpool-test/volume_1" + the ceph rbd volume PROVISION and USED are the same size + + convert the raw OS disk to a ceph volume + +8. qemu-img convert -n -f raw -O raw ./lvm_volume_1.raw rbd:cephpool- +test/volume_2:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx + + check the rbd volume USED size in ceph cluster + "rbd du cephpool-test/volume_2" + the ceph rbd volume PROVISION and USED are different PROVISION > USED +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2008 b/results/classifier/deepseek-2/output/device/2008 new file mode 100644 index 000000000..fa367dd47 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2008 @@ -0,0 +1,13 @@ + +querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry +Description of problem: +Querying the UUID in Powershell with +`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID` +will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present. + +Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part. + +It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS. +Additional information: +Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths): +https://forum.proxmox.com/threads/136942/ diff --git a/results/classifier/deepseek-2/output/device/2014 b/results/classifier/deepseek-2/output/device/2014 new file mode 100644 index 000000000..2485e1358 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2014 @@ -0,0 +1,54 @@ + +virtio: bounce.in_use==true in virtqueue_map_desc() +Description of problem: + +Steps to reproduce: +1. Build EDK II (edk2-stable202311) for riscv64 +2. Build UEFI SCT (commit 81dfa8d53d4290) for riscv64 +3. Run the UEFI SCT +4. Observe the message "qemu: virtio: bogus descriptor or out of resources" after which the execution stalls. + +The full procedure is described in https://github.com/xypron/sct_release_test + +To save time you can call `sct -u` and select only test 'MediaAccessTest\\BlockIOProtocolTest'. Run it with `F9`. +Additional information: +virtqueue_map_desc() may be called for a large buffers size `sz`. It will then call dma_memory_map() multiple times in a loop. In address_space_map() `bounce.in_use` is set to `true` on the first call. Each subsequent call is bound to fail. + +To verify this is the cause I applied the following diff: + +```plaintext +diff --git a/system/physmem.c b/system/physmem.c +index a63853a7bc..12b3c2f828 100644 +--- a/system/physmem.c ++++ b/system/physmem.c +@@ -3151,12 +3151,16 @@ void *address_space_map(AddressSpace *as, + + if (!memory_access_is_direct(mr, is_write)) { + if (qatomic_xchg(&bounce.in_use, true)) { ++ fprintf(stderr, "bounce.in_use in address_space_map\n"); ++ + *plen = 0; + return NULL; + } + /* Avoid unbounded allocations */ + l = MIN(l, TARGET_PAGE_SIZE); + bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, l); ++ if (!bounce.buffer) ++ fprintf(stderr, "Out of memory in address_space_map\n"); + bounce.addr = addr; + bounce.len = l; +``` + +and saw this output: + +```plaintext +Logfile: "\sct\Log\MediaAccessTest\BlockIOProtocolTest0\ReadBlocks_Conf_0_0_8261 +59D3-04A5-4CCE-8431-344707A8B57A.log" +Test Started: 12/02/23 08:43a +------------------------------------------------------------ +Current Device: Acpi(PNP0A03,0)/Pci(3|0) +Bounce.in_use in address_space_map +qemu: virtio: bogus descriptor or out of resources +``` + +See related bug #850. diff --git a/results/classifier/deepseek-2/output/device/2018 b/results/classifier/deepseek-2/output/device/2018 new file mode 100644 index 000000000..ebbf18b6d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2018 @@ -0,0 +1,19 @@ + +QEMU would not start when trying to create two UFS host controllers +Description of problem: +This issue is reported by Akinobu Mita. +https://lore.kernel.org/qemu-devel/20231204150543.48252-1-akinobu.mita@gmail.com/ + +> QEMU would not start when trying to create two UFS host controllers and a UFS logical unit for each with the following options: +> +> -device ufs,id=bus0 \ +> -device ufs-lu,drive=drive1,bus=bus0,lun=0 \ +> -device ufs,id=bus1 \ +> -device ufs-lu,drive=drive2,bus=bus1,lun=0 \ +> +> This is because the same ID string ("0:0:0/scsi-disk") is generated +> for both UFS logical units. +> +> To fix this issue, prepend the parent pci device's path to make +> the ID string unique. +> ("0000:00:03.0/0:0:0/scsi-disk" and "0000:00:04.0/0:0:0/scsi-disk") diff --git a/results/classifier/deepseek-2/output/device/2020 b/results/classifier/deepseek-2/output/device/2020 new file mode 100644 index 000000000..3edb41c88 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2020 @@ -0,0 +1,12 @@ + +qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed. +Description of problem: +VM just crashed, likely because of a time / NTP change +``` +qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed. +2023-12-04 15:51:40.571+0000: shutting down, reason=crashed +``` +Steps to reproduce: +1. N/A + +/label ~"kind::Bug" diff --git a/results/classifier/deepseek-2/output/device/2025 b/results/classifier/deepseek-2/output/device/2025 new file mode 100644 index 000000000..7e98dbaac --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2025 @@ -0,0 +1,27 @@ + +Can't make the touchscreen work in Windows VM, device virtio-multitouch-pci not starting +Description of problem: +I tried the multitouch on qemu 8, by adding "-device virtio-multitouch-pci" to the qemu cmd line +I could make the multitouch work for an Ubuntu VM, but not for a Windows VM +Last version of Virtio drivers are installed in Windows. + +Here are the issues i can see in windows : + + +Windows Events of virtio input driver device : + +``` +Device PCI\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\3&2411e6fe&0&18 had a problem starting. +Driver Name: oem7.inf +Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da} +Service: VirtioInput +Lower Filters: +Upper Filters: +Problem: 0xA +Problem Status: 0xC000009A +``` +Qemu didnt produce any logs regarding this PCI + +Do I miss something ? + +Thanks for your help diff --git a/results/classifier/deepseek-2/output/device/2031 b/results/classifier/deepseek-2/output/device/2031 new file mode 100644 index 000000000..42cb4285d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2031 @@ -0,0 +1,14 @@ + +Redundant comparison +Description of problem: +The result of the function `qdev_get_hotplug_handler` is always __NULL__. That is why the comparison in the line №502 is redundant: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/qdev.c#L501 + +This code will never be executed: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/qdev.c#L502-L507 + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Voronin. diff --git a/results/classifier/deepseek-2/output/device/2033 b/results/classifier/deepseek-2/output/device/2033 new file mode 100644 index 000000000..fe19e7f2e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2033 @@ -0,0 +1,2 @@ + +goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL diff --git a/results/classifier/deepseek-2/output/device/2046 b/results/classifier/deepseek-2/output/device/2046 new file mode 100644 index 000000000..cf68bd136 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2046 @@ -0,0 +1,2 @@ + +live migration error : qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm diff --git a/results/classifier/deepseek-2/output/device/2049 b/results/classifier/deepseek-2/output/device/2049 new file mode 100644 index 000000000..35147b7dc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2049 @@ -0,0 +1,12 @@ + +drive-mirror RBD thin +Description of problem: +I found that this problem was first discovered in 2014. There was a post +[2014 bug description](https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01231.html )、 +[2014 patch](https://patchwork.ozlabs.org/project/qemu-devel/patch/1433747185-16797-2-git-send-email-famz@redhat.com/) +mentioning this bug. +The patch in the post said that this problem had been solved, but after trying and asking, I found that the problem had not been solved. +Later, I saw this problem in the [2017 bug description](https://forum.proxmox.com/threads/drive-mirror-rbd-thin.33250/#post-613502) forum and it was said that there was a patch to fix it, but it was not. +I tried the latest qemu version and found that this problem has not been solved. +Additional information: +nbd is normal, but rbd is wrong！ diff --git a/results/classifier/deepseek-2/output/device/2053 b/results/classifier/deepseek-2/output/device/2053 new file mode 100644 index 000000000..f69512375 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2053 @@ -0,0 +1,2 @@ + +virtio is broken in qemu-system-arm diff --git a/results/classifier/deepseek-2/output/device/2061 b/results/classifier/deepseek-2/output/device/2061 new file mode 100644 index 000000000..45e343737 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2061 @@ -0,0 +1,14 @@ + +Regression: QEMU 8.2.0 VFIO GPU guests cannot reboot due to improper reset +Description of problem: +Prior to QEMU 8.2.0 (i.e. 8.1.4), rebooting the guest with VFIO GPU passed through would result in a proper reboot. +After updating to QEMU 8.2.0, rebooting the guest results in a black screen due to improper reset behaviour. +I was able to narrow this down to commit #3d779ab. Compiling and running with commit #0bddd88 results in the correct behaviour. +That is, the GPU properly resets on guest reboot and boots successfully to Windows. +Steps to reproduce: +1. Update to QEMU 8.2.0 +2. Boot Windows 11 23H2 +3. Reboot +4. Notice a black screen +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2066 b/results/classifier/deepseek-2/output/device/2066 new file mode 100644 index 000000000..a7fb9267d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2066 @@ -0,0 +1,2 @@ + +Feature Request: UART 8250 Support in QEMU Virt Machine for aarch64 diff --git a/results/classifier/deepseek-2/output/device/2075 b/results/classifier/deepseek-2/output/device/2075 new file mode 100644 index 000000000..8ba561f4e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2075 @@ -0,0 +1,11 @@ + +QGA guest-get-fsinfo can not return windows dynamic volumes +Description of problem: +Install qemu-ga (newest version) in Windows, create multiple dynamic volumes（containing multiple disks）, + + +get them information via guest-get-fsinfo, but guest-get-fsinfo does not return the the dynamic volume. +Steps to reproduce: +virsh qemu-agent-command {domain} --pretty '{ "execute": "guest-get-fsinfo" }' +Additional information: +Please see if this bug can be fixed by [qga-win: Fix guest-get-fsinfo multi-disks collection](https://patchew.org/QEMU/20231227071540.4035803-1-peng.ji@smartx.com/) diff --git a/results/classifier/deepseek-2/output/device/2081 b/results/classifier/deepseek-2/output/device/2081 new file mode 100644 index 000000000..120a753ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2081 @@ -0,0 +1,10 @@ + +[OHCI] OHCI_CC_DEVICENOTRESPONDING not set when transferring to a disconnected device +Description of problem: +If a USB device is disconnected and is cleaned up by qemu, subsequent transfers to that device address are ignored. On a real OHCI controller `OHCI_CC_DEVICENOTRESPONDING` bit is set and is reported as an error to the host. + +qemu attempts to set it here https://github.com/qemu/qemu/blob/ffd454c67e38cc6df792733ebc5d967eee28ac0d/hw/usb/hcd-ohci.c#L795 which would work fine on a valid device handle. + +However this check https://github.com/qemu/qemu/blob/ffd454c67e38cc6df792733ebc5d967eee28ac0d/hw/usb/hcd-ohci.c#L975 leaves early if no device handle is found so the error code is never set. + +Fix is to set `OHCI_CC_DEVICENOTRESPONDING` if `ohci_find_device` fails before returning. diff --git a/results/classifier/deepseek-2/output/device/2086 b/results/classifier/deepseek-2/output/device/2086 new file mode 100644 index 000000000..a266a3551 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2086 @@ -0,0 +1,16 @@ + +qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" on ESXi +Description of problem: +Trying to start the VM using vmdk converted with qemu-img fails with + +Failed to start the virtual machine. +Module DevicePowerOn power on failed. +Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' +Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. +Steps to reproduce: +1. Convert booting OS (in both Qemu and VMWare with the help of drivers) to vmdk +2. Push vmdk file to ESXi datastore +3. Try to boot + +Additional information: +ESXi seem to use a specific implementation of vmdk, with a *name*.vmdk file being the descriptor of the virtual disk and a *name*-flat.vmdk. diff --git a/results/classifier/deepseek-2/output/device/2093 b/results/classifier/deepseek-2/output/device/2093 new file mode 100644 index 000000000..666e2ff53 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2093 @@ -0,0 +1,4 @@ + +m68k: virt: Add command to virt-ctrl device to pause cpu until an interrupt happens +Additional information: +I'm working on how to implement this myself. Any hints would be great. diff --git a/results/classifier/deepseek-2/output/device/2114 b/results/classifier/deepseek-2/output/device/2114 new file mode 100644 index 000000000..0b8dbc9ea --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2114 @@ -0,0 +1,2 @@ + +hw/char/riscv_htif.c and hw/char/sifive_uart call qemu_chr_fe_write() and ignore return value diff --git a/results/classifier/deepseek-2/output/device/2117 b/results/classifier/deepseek-2/output/device/2117 new file mode 100644 index 000000000..0568f7132 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2117 @@ -0,0 +1,28 @@ + +Unraid, Ubuntu, 9P/virtio and memory issues +Description of problem: +I am running an Ubuntu VM on Unraid - which is using Qemu. I am exposing my shares through "9p Mode" to the VM. + +The logs shows: +-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/mnt/user/backup \ +-device '{"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"backup","bus":"pci.1","addr":"0x0"}' \ + +Inside Ubuntu, I mount the exposed shares like this: + +sudo mount -t 9p -o trans=virtio "backup" /media/share/backup + +I have a script that uses rsync to sync the files from these mounted shares onto an internal disk drive. + +The issues that I am facing, is that rsync sometimes reports "cannot allocate memory": + +rsync: [sender] readdir("/media/share/backup/myfolder"): Cannot allocate memory (12) + +There are "ten thousands" of files in that folder hierarchy, but there are plenty of memory available on the VM (many GBs), so that is no issue. The next time I run the job, it might go through as normal. But I would like to get rid of these issues. + +The question is: Is there some kind of memory allocation/limit to the virtio/9p as well? If yes - is there some way to increase it to avoid these errors? +Steps to reproduce: +1. Mount as shown +2. Run rsync on folder with lots of files +3. See error +Additional information: +N/A diff --git a/results/classifier/deepseek-2/output/device/2121 b/results/classifier/deepseek-2/output/device/2121 new file mode 100644 index 000000000..cac3673e8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2121 @@ -0,0 +1,2 @@ + +tests/qtest/ahci-test.c:89:verify_state: assertion failed (ahci_fingerprint == ahci->fingerprint): (0xe0000000 == 0x29228086) diff --git a/results/classifier/deepseek-2/output/device/2126 b/results/classifier/deepseek-2/output/device/2126 new file mode 100644 index 000000000..6468eb672 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2126 @@ -0,0 +1,2 @@ + +iotest-144 sometimes fails due to minor reordering of output diff --git a/results/classifier/deepseek-2/output/device/2178 b/results/classifier/deepseek-2/output/device/2178 new file mode 100644 index 000000000..568a98fc0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2178 @@ -0,0 +1,18 @@ + +USB passthrough on Apple Silicon is unusable +Description of problem: +I can't get USB passthrough to work sufficiently well with wifi modems such as the RTL8187L or Atheros AR 9271. + +I only use the VM as a router since the host OS doesn't have drivers for any external wifi modems. This is a setup I've used flawlessly many times in the past with other VMs on x86 platforms for many years, but with ARM it's been one fail after another. Parallels does work with the exact same host and guest, but fails in the networking area (plus it's expensive and overkill for something this simple). I mention this because I know the guest drivers work 100% with a different VM. +Steps to reproduce: +1. Run any Linux on QEMU on any Apple Silicon mac +2. Attempt to use a Atheros AR 9271 USB device +3. Various fails including + a) USB device not showing up (lsusb) + b) device shows up and Linux attempts to attach driver, but fails (lsmod shows driver loaded but no interface listed on iwconfig) + c) interface shows up (never got the Atheros this far, but RealTek does) but the interface is slow, corrupts data, etc. + d) after re-attaching several times it will eventually stop attaching at all requiring a MacOS system reboot, which is really annoying for my workflow. + +It's basically non-functional for me. Atheros is 100% non-functional and RealTek 10% works (well enough to *sometimes* connect to the AP, but usually craps the bed if you try to do anything as simple as run a dhcp client to fetch the IP). + +If anyone knows of any other Linux ARM on Mac ARM vm solutions that allow USB passthrough please let me know. Unfortunately, VirtualBox os currently not one of them. diff --git a/results/classifier/deepseek-2/output/device/2185 b/results/classifier/deepseek-2/output/device/2185 new file mode 100644 index 000000000..f9513e773 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2185 @@ -0,0 +1,2 @@ + +spapr watchdog should honour watchdog-set-action etc monitor commands diff --git a/results/classifier/deepseek-2/output/device/2186 b/results/classifier/deepseek-2/output/device/2186 new file mode 100644 index 000000000..a93726187 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2186 @@ -0,0 +1,35 @@ + +riscv virt pflash0 writes not supported +Description of problem: +I am using GDB to debug some Firmware related stuff. At some point in the execution my BIOS/Firmware writes into some global variable (at 0x2000525C) inside the .bss section which is linked to be inside the memory mapped pflash0. But when I step forward with GDB to the exact location where the store instruction (sw) is executed, QEMU prints the following: +``` +pflash_write: Unimplemented flash cmd sequence (offset 000000000000525c, wcycle 0x0 cmd 0x0 value 0x1) +``` +According to the top of `hw/block/pflash_cfi01.c` Flash writes are supported. I was also under the impression that the flash is memory mapped, but maybe that is not true? I am probably missing something here so it would be nice if someone could point me in the right direction. I would also gladly contribute if there is something missing in the riscv virt target. + +I made a simple program to more easily reproduce this: +``` +.section .text +.global _start +_start: + lui a5, 0x20000 + li a4, 5 + sw a4, 24(a5) + +``` +results in QEMU error msg: +``` +pflash_write: Unimplemented flash cmd sequence (offset 0000000000000018, wcycle 0x0 cmd 0x0 value 0x5) +``` +Steps to reproduce: +1. compile above assembly program like this: +``` +riscv64-unknown-elf-gcc -nostdlib -O0 bios.S +riscv64-unknown-elf-objcopy -O binary a.out +truncate -s 33554432 a.out +``` +2. start QEMU like this: +``` +qemu-system-riscv64 -M virt -bios none -drive if=pflash,format=raw,unit=0,file=a.out -nographic -d unimp +``` +3. notice the error message printed by QEMU diff --git a/results/classifier/deepseek-2/output/device/2199 b/results/classifier/deepseek-2/output/device/2199 new file mode 100644 index 000000000..ac0ccac9c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2199 @@ -0,0 +1,13 @@ + +QEMU8 not working properly for Win9x guest +Description of problem: +Cannot boot to Win9x desktop. Enter safe mode of Win9x, then open C:\Windows\system\iosubsys, then rename drvwq117.vxd to drvwq117.vxd.bak, this problem solved.<br /> +Sound card and network card not found in Win9x Device Manager.<br /> +Cannot change resolution in Win9x Control Panel, this will cause "RUNDLL32 program error". + +We found that Plug-and-Play (\$PNP) and PCI IRQ Routing (\$PIR) functions of SeaBIOS are buggy for Win9x guest. +Steps to reproduce: +1.Install Win98 RTM on QEMU8, it cannot boot to Win98 desktop.<br /> +2.Install WinME on QEMU8, it will stuck on "copying files". +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/221 b/results/classifier/deepseek-2/output/device/221 new file mode 100644 index 000000000..148a4a9e4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/221 @@ -0,0 +1,2 @@ + +piix crashes on mips when accessing acpi-pci-hotplug diff --git a/results/classifier/deepseek-2/output/device/2211 b/results/classifier/deepseek-2/output/device/2211 new file mode 100644 index 000000000..032c6d728 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2211 @@ -0,0 +1,28 @@ + +Live Migration Issue - get_pci_config_device: Bad config data +Description of problem: +Hello everybody, +recently i have updated my environment from QEMU 7.1 (Build based from Upstream Code) to QEMU 7.2 (Build based from Upstream Code). +Since the patching went very well, i noticed that Live Migrations are not possible anymore. +It looks like that the Migration Process itself is running fine, but at the moment where QEMU wants to get the VM back live on the destination node, it crashes with the following error: + +``` +internal error: qemu unexpectedly closed the monitor: 2024-03-06T16:05:46.118520Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x34 read: c8 device: dc cmask: ff wmask: 0 w1cmask:0 +2024-03-06T16:05:46.118804Z qemu-system-x86_64: Failed to load PCIDevice:config +2024-03-06T16:05:46.118813Z qemu-system-x86_64: Failed to load virtio-rng:virtio +2024-03-06T16:05:46.118821Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.5:00.0/virtio-rng' +2024-03-06T16:05:46.120947Z qemu-system-x86_64: load of migration failed: Invalid argument +``` + +If i would stop/start the instance in question, live migration is back working. +This let me think that this might be an issue caused by the VM emulation process isn't running with the latest source of QEMU 7.2? + +Could someone please help me to figure out how i could resolve this issue to unblock the live migration capability without restarting all of my instances? +Steps to reproduce: +1. Prepare to Test Systems + - SOURCE = Install with QEMU 7.1 + - DESTINATION = Install with QEMU 7.2 +2. Start an example VM instance on the SOURCE +3. Update QEMU to 7.2 on the SOURCE +4. Start Live Migration from SOURCE to DESTINATION. +5. Error should be raised like mentioned above diff --git a/results/classifier/deepseek-2/output/device/2212 b/results/classifier/deepseek-2/output/device/2212 new file mode 100644 index 000000000..287836caa --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2212 @@ -0,0 +1,18 @@ + +"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/deepseek-2/output/device/2213 b/results/classifier/deepseek-2/output/device/2213 new file mode 100644 index 000000000..1bd2b31d7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2213 @@ -0,0 +1,16 @@ + +QEMU fails with duplicate SaveStateEntry when using two legacy virtio input devices +Description of problem: +QEMU bails out when it is started with two virtio-input devices running in legacy virtio mode, using two different transports (like PCI and CCW on s390x). +Steps to reproduce: +``` +qemu-system-s390x -M s390-ccw-virtio-2.6 -cpu max -nographic -device virtio-multitouch-pci -device virtio-tablet-ccw +``` +fails with: +``` +qemu-system-s390x: -device virtio-tablet-ccw: savevm_state_handler_insert: Detected duplicate SaveStateEntry: id=virtio-input, instance_id=0x0 +``` +Additional information: +The problem does *not* occur if using modern virtio devices (which automatically happens for -M s390-ccw-virtio-2.7 and newer) or if using virtio-input devices with the same transport (e.g. two PCI devices instead of one PCI and one CCW). + +Also note that the problem only occurs since QEMU 8.1 since older versions did not check for duplicate SaveStateEntries (see commit caa91b3c44cdb2d2921e25 ). diff --git a/results/classifier/deepseek-2/output/device/2218 b/results/classifier/deepseek-2/output/device/2218 new file mode 100644 index 000000000..b7d3bca30 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2218 @@ -0,0 +1,13 @@ + +MIDI playback issue on Windows 98 / 2000 / XP guest +Description of problem: +In Windows 98 / 2000 / XP guest, playback MIDI using Windows Media Player will cause audio slow. + +In Windows 98 / 2000 / XP guest, playback MP3 or WMA or WAV using Windows Media Player is works OK. +Steps to reproduce: +1. In Windows XP guest, open C:\WINDOWS\Media\Flourish.mid using Windows Media Player. +2. In Windows XP guest, open C:\WINDOWS\System32\OOBE\images\title.wma using Windows Media Player. +3. In Windows 98 guest, open C:\WINDOWS\Media\Passport.mid using Windows Media Player. +4. In Windows 98 guest, open C:\WINDOWS\Application Data\Microsoft\WELCOME\WELCOM98.WAV using Windows Media Player. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2227 b/results/classifier/deepseek-2/output/device/2227 new file mode 100644 index 000000000..fd2541734 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2227 @@ -0,0 +1,37 @@ + +Crash when using the ast2600-a3 device with the "virt" aarch64 machine +Description of problem: +QEMU crashes with a segmentation fault when trying to use the "ast2600-a3" device with the "virt" machine. +Steps to reproduce: +1. Run ``./qemu-system-aarch64 -display none -machine virt -device ast2600-a3`` +Additional information: +Backtrace indicates that it is crashing in the aspeed_soc_ast2600_realize() function: + +``` +#0 memory_region_update_container_subregions (subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2637 +#1 memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2661 +#2 0x0000555555d1bd40 in aspeed_soc_ast2600_realize (dev=<optimized out>, errp=0x7fffffffd870) at ../../devel/qemu/hw/arm/aspeed_ast2600.c:301 +#3 0x0000555555ff26ab in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:510 +#4 0x0000555555ff6edd in property_set_bool (obj=0x555558c4b360, v=<optimized out>, name=<optimized out>, opaque=0x555557cd5b50, errp=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:2358 +#5 0x0000555555ffa25b in object_property_set (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", v=v@entry=0x555558ce0650, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:1472 +#6 0x0000555555ffdb9f in object_property_set_qobject + (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=0x555558cdf270, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/qom-qobject.c:28 +#7 0x0000555555ffa8c4 in object_property_set_bool (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=true, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:1541 +#8 0x0000555555ff319c in qdev_realize (dev=dev@entry=0x555558c4b360, bus=bus@entry=0x0, errp=errp@entry=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:292 +#9 0x0000555555c11be3 in qdev_device_add_from_qdict (opts=opts@entry=0x555558c4a2d0, from_json=from_json@entry=false, errp=0x7fffffffda00, errp@entry=0x55555725b478 <error_fatal>) + at ../../devel/qemu/system/qdev-monitor.c:718 +#10 0x0000555555c12051 in qdev_device_add (opts=0x555557cd2a10, errp=errp@entry=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/qdev-monitor.c:737 +#11 0x0000555555c1720f in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/vl.c:1200 +#12 0x00005555561a29c1 in qemu_opts_foreach + (list=<optimized out>, func=func@entry=0x555555c17200 <device_init_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x55555725b478 <error_fatal>) + at ../../devel/qemu/util/qemu-option.c:1135 +#13 0x0000555555c19aea in qemu_create_cli_devices () at ../../devel/qemu/system/vl.c:2637 +#14 qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2705 +#15 0x0000555555c1d67f in qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2699 +#16 qemu_init (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/vl.c:3736 +#17 0x00005555558f6f59 in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:47 +``` diff --git a/results/classifier/deepseek-2/output/device/2228 b/results/classifier/deepseek-2/output/device/2228 new file mode 100644 index 000000000..e02cc1e2c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2228 @@ -0,0 +1,9 @@ + +hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed +Description of problem: +It's quite easy to trigger the assertion ``hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed`` +Steps to reproduce: +Run one of the following command lines: +1. ``./qemu-system-aarch64 -display none -machine qcom-dc-scm-v1-bmc -device max1111`` +2. ``./qemu-system-aarch64 -display none -machine fby35-bmc -device max1110`` +3. ``./qemu-system-aarch64 -display none -machine yosemitev2-bmc -device corgi-ssp`` diff --git a/results/classifier/deepseek-2/output/device/2240 b/results/classifier/deepseek-2/output/device/2240 new file mode 100644 index 000000000..5fd10d7ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2240 @@ -0,0 +1,5 @@ + +Please provide useful defaults for machine and cpu +Additional information: +See https://bugs.debian.org/1040212 and https://salsa.debian.org/helmutg/debvm/-/issues/15 for the preceding discussion and +https://salsa.debian.org/helmutg/debvm/-/blob/main/bin/debvm-run and https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/80 for the used machine and cpu values. diff --git a/results/classifier/deepseek-2/output/device/2260 b/results/classifier/deepseek-2/output/device/2260 new file mode 100644 index 000000000..319cad9b3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2260 @@ -0,0 +1,26 @@ + +Storage device missing/Not recognized by driver (regression) +Description of problem: +Installation CD boots but can not find any storage/harddrive to install to. +This works in qemu 8.2.2, so it seems like a regression. +Steps to reproduce: +1. +2. +3. +Get virtio iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/ + +Install swtpm like: brew install swtpm + +Use CrystalFetch from https://docs.getutm.app/guides/windows/ to download Windows ISO. + +Create storage: qemu-img create -f qcow2 Win11.qcow2 80G + +dd if=/dev/zero of=vars-pflash.raw bs=1M count=64 + +start tpm like: /opt/homebrew/bin/swtpm socket --tpm2 --tpmstate dir=/Users/jonas/qw11arm/mytpm --ctrl type=unixio,path=/Users/jonas/qw11arm/mytpm/swtpm-sock + +start qemu like: \~/qemu/qemu/build/qemu-system-aarch64 --machine virt,virtualization=on --cpu neoverse-n1 --monitor stdio -smp cpus=4,sockets=1,cores=4,threads=1 -m 5G -device nec-usb-xhci -device qemu-xhci -device usb-kbd -device usb-tablet -device usb-storage,drive=windows,serial=windows -drive if=none,id=windows,format=raw,media=cdrom,file=/Users/jonas/ISOs/22631.2861.231204-0538.23H2_NI_RELEASE_SVC_REFRESH_CLIENTCONSUMER_RET_A64FRE_en-us.iso,readonly=on -device virtio-scsi -device scsi-hd,drive=boot,serial=boot -drive if=none,id=boot,format=qcow2,file=./Win11.qcow2 -drive if=pflash,format=raw,unit=0,file=/Users/jonas/qemu/qemu/build/pc-bios/edk2-aarch64-code.fd,readonly=on -drive file=vars-pflash.raw,format=raw,if=pflash,unit=1 -chardev socket,id=chrtpm,path=/Users/jonas/qw11arm/mytpm/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0 --display cocoa -rtc base=localtime -device ramfb -boot menu=on -device usb-storage,drive=virtio,serial=virtio -drive if=none,id=virtio,format=raw,media=cdrom,file=/Users/jonas/Downloads/virtio-win-0.1.240.iso,readonly=on -nic user,model=virtio-net-pci,mac=52:54:98:76:54:32 + +Adjust paths and be ready to bypass windows checks as described on https://docs.getutm.app/guides/windows/#this-pc-cant-run-windows-11 +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2269 b/results/classifier/deepseek-2/output/device/2269 new file mode 100644 index 000000000..067b118e8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2269 @@ -0,0 +1,42 @@ + +RISC-V exit via sifive_test does not work in scripts with -serial stdio +Description of problem: + +Steps to reproduce: +1. Create assembly file `hello.s`: +```as +.section .text +.globl _start +_start: csrr t0, mhartid + bnez t0, _start + li t0, 0x100000 + li t1, 0x5555 + sw t1, 0(t0) +halt: j halt +``` +2. Create linker script `link.ld`: +```ld +OUTPUT_ARCH( "riscv" ) +ENTRY(_start) +SECTIONS +{ + . = 0x80000000; +} +``` +3. Create runner script `./run.sh` (don't forget to `chmod +x`) +```sh +#!/usr/bin/env bash +timeout 10 qemu-system-riscv64 -M virt -display none -serial stdio -bios none -kernel hello +``` +4. Compile into executable: +```sh +riscv64-unknown-elf-gcc -c -mcmodel=medany -fvisibility=hidden -nostartfiles -march=rv64g -mabi=lp64 -o hello.o hello.s +riscv64-unknown-elf-ld hello.o -nostdlib -T link.ld -o hello +``` +5. Dot-source the script - it will immediately exit cleanly +6. Execute the script - it will timeout with exit code 124 +7. Execute the script with redirected stdin, e.g. `./run.sh < ./run.sh` or `echo | ./run.sh` - it will immediately exit cleanly +Additional information: +This issue happens only with `-serial stdio`. Using `chardev:file` or `chardev:null` does not reproduce the issue. Process substitution like `<(echo 'test')` does not seem to work. `cat | ./run.sh` will wait until any line is send, then exit cleanly. This is mainly an issue when using helper test scripts which want to interact with user, as proper CI/UT would redirect serial anyways. + +I have noticed similar behavior with other RISC-V UART device - when running from scripts, there is no output, as if QEMU was waiting for something, even if there is only UART TX, not RX. It does not matter if I actually type in anything or not. diff --git a/results/classifier/deepseek-2/output/device/2271 b/results/classifier/deepseek-2/output/device/2271 new file mode 100644 index 000000000..10d7d2df9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2271 @@ -0,0 +1,17 @@ + +pci passthrough fails from aarch64 to amd64 guest +Description of problem: +**PCIe device Pass-thru from aarch64 host to amd64 guest fails with the below** + +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: VFIO_MAP_DMA failed: Invalid argument +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: vfio 0003:06:00.0: failed to setup container for group 25: memory listener initialization failed: Region pc.ram: vfio_dma_map(0xba4058207210, 0x100000, 0xbff00000, 0xeba70a300000) = -22 (Invalid argument) + +pass-thru with same command line syntax works correctly if the guest is aarch64 (qemu-system-aarch64). + +AMD64 guest VM otherwise works correctly if -device vfio-pci is not used. + +libvirt / virtmanager fail for aarch64 host -> amd64 guest as well. +Steps to reproduce: +1. Unbind pass-thru device from host. +2. Attach pass-thru device to vfio-pci +3. Execute qemu-system-amd64 as above. diff --git a/results/classifier/deepseek-2/output/device/2272 b/results/classifier/deepseek-2/output/device/2272 new file mode 100644 index 000000000..f649d55bc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2272 @@ -0,0 +1,22 @@ + +Memory leak in the virtual device applesmc +Description of problem: +In the function _qdev_applesmc_isa_reset_, the device mallocs the _AppleSMCData_ but does not free them, causing a memory leak. + +The following log reveals it: + +``` +==1029295==ERROR: LeakSanitizer: detected memory leaksDirect leak of 80 byte(s) in 2 object(s) allocated from: +#0 0x5574dc600a82 in __interceptor_calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 +#1 0x7f4919b22c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) +#2 0x5574dcdb0dfe in qdev_applesmc_isa_reset qemu/hw/misc/applesmc.c:285:5 +#3 0x5574de30e099 in resettable_phase_hold qemu/hw/core/resettable.c +#4 0x5574de2ef753 in bus_reset_child_foreach qemu/hw/core/bus.c:97:13 +#5 0x5574de30dcfe in resettable_child_foreach qemu/hw/core/resettable.c:96:9 +#6 0x5574de30dcfe in resettable_phase_hold qemu/hw/core/resettable.c:173:5 +#7 0x5574de3059b3 in device_reset_child_foreach qemu/hw/core/qdev.c:276:9 +``` +Steps to reproduce: +1. Build qemu with the sanitizer +2. Boot the Linux kernel with the above command line. +3. Stop the qemu process diff --git a/results/classifier/deepseek-2/output/device/2274 b/results/classifier/deepseek-2/output/device/2274 new file mode 100644 index 000000000..81bfa5b70 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2274 @@ -0,0 +1,44 @@ + +Assertion failuer in cryptodev_builtin_close_session() +Description of problem: +In the function _cryptodev_builtin_close_session(),_ an assertation happened: + +``` +qemu-fuzz-x86_64: qemu/backends/cryptodev-builtin.c:430: int cryptodev_builtin_close_session(CryptoDevBackend *, uint64_t, uint32_t, CryptoDevCompletionFunc, void *): Assertion `session_id < MAX_NUM_SESSIONS && builtin->sessions[session_id]' failed. +==1256139== ERROR: libFuzzer: deadly signal + #9 0x71acb8c2871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x71acb8c39e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x5af7f624b12b in cryptodev_builtin_close_session qemu/backends/cryptodev-builtin.c:430:5 + #12 0x5af7f60b2860 in virtio_crypto_handle_close_session qemu/hw/virtio/virtio-crypto.c:262:12 + #13 0x5af7f60b2860 in virtio_crypto_handle_ctrl qemu/hw/virtio/virtio-crypto.c:423:19 +``` + +The user could send an invalid session_id to trigger this assertion. +Steps to reproduce: +Here's a simple PoC: + +``` +cat << EOF | qemu-system-x86_64 -display none\ + -machine accel=qtest -m 512M -machine q35 -nodefaults -object \ +cryptodev-backend-builtin,id=cryptodev0 -device \ +virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0008000 +write 0x10800e 0x1 0x01 +write 0xe0008016 0x1 0x01 +write 0xe0008020 0x4 0x00801000 +write 0xe0008028 0x4 0x00c01000 +write 0xe000801c 0x1 0x01 +write 0x110000 0x1 0x05 +write 0x110001 0x1 0x04 +write 0x108002 0x1 0x11 +write 0x108008 0x1 0x48 +write 0x10800c 0x1 0x01 +write 0x108018 0x1 0x10 +write 0x10801c 0x1 0x02 +write 0x10c002 0x1 0x01 +write 0xe000b005 0x1 0x00 +EOF +``` diff --git a/results/classifier/deepseek-2/output/device/2283 b/results/classifier/deepseek-2/output/device/2283 new file mode 100644 index 000000000..88c58f546 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2283 @@ -0,0 +1,34 @@ + +memory leak in virtio-crypto +Description of problem: +The following log reveals it: + +``` +==1878896==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 48 byte(s) in 1 object(s) allocated from: + #0 0x5646565ec262 in __interceptor_calloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 + #1 0x7f591ec3bc50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x564659227db7 in error_setg_internal qemu/util/error.c:105:5 + #3 0x56465794ad35 in cryptodev_builtin_operation qemu/backends/cryptodev-builtin.c:557:9 + #4 0x5646579550b5 in cryptodev_backend_operation qemu/backends/cryptodev.c:180:16 + #5 0x564657953640 in cryptodev_backend_crypto_operation qemu/backends/cryptodev.c:289:12 + #6 0x56465773a647 in virtio_crypto_handle_request qemu/hw/virtio/virtio-crypto.c:911:19 + #7 0x5646577386a0 in virtio_crypto_handle_dataq qemu/hw/virtio/virtio-crypto.c:938:13 + #8 0x564657734f87 in virtio_crypto_dataq_bh qemu/hw/virtio/virtio-crypto.c:963:9 + #9 0x56465928a6b1 in aio_bh_call qemu/util/async.c:171:5 + #10 0x56465928b58c in aio_bh_poll qemu/util/async.c:218:13 + #11 0x5646591eb398 in aio_dispatch qemu/util/aio-posix.c:423:5 + #12 0x5646592919ce in aio_ctx_dispatch qemu/util/async.c:360:5 + #13 0x7f591ec32d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + +Indirect leak of 36 byte(s) in 1 object(s) allocated from: + #0 0x5646565ec0cd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 + #1 0x7f591e488157 in __vasprintf_internal libio/./libio/vasprintf.c:71:30 +``` +Steps to reproduce: +``` +qemu-system-x86_64 -display none -machine accel=qtest -m 512M -machine q35 -nodefaults -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio < /tmp/reproducer +``` + +[reproducer](/uploads/e0161b0d482bc5dac08929d51e70e7fc/reproducer) diff --git a/results/classifier/deepseek-2/output/device/2289 b/results/classifier/deepseek-2/output/device/2289 new file mode 100644 index 000000000..a26b00732 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2289 @@ -0,0 +1,2 @@ + +virtio-blk not work in freebsd guest with qemu>=7.0.0 diff --git a/results/classifier/deepseek-2/output/device/2306 b/results/classifier/deepseek-2/output/device/2306 new file mode 100644 index 000000000..b02392b72 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2306 @@ -0,0 +1,2 @@ + +A bug of ptimer that the freq can't set more than 1000M diff --git a/results/classifier/deepseek-2/output/device/2308 b/results/classifier/deepseek-2/output/device/2308 new file mode 100644 index 000000000..f576dccb3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2308 @@ -0,0 +1,80 @@ + +QEMU Windows COM port setup dialog always invoked and fails if none is available (USB or virtual serial port hardware) +Description of problem: +The Windows backend serial port in `chardev/char-win.c` always calls `CommConfigDialog()`. This should display a COM port configuration dialog which does (and can) not persist the COM port settings. If the COM port does not support this action (see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-commconfigdialoga) then the function fails. +Steps to reproduce: +1. Currently not possible with QEMU releases as QEMU does not recognize extended COM port specifications like `\\.\COM19` or `\\.\CNCA0` +Additional information: +See https://support.microsoft.com/en-gb/topic/howto-specify-serial-ports-larger-than-com9-db9078a5-b7b6-bf00-240f-f749ebfd913e for details on COM port filenames. + +I have a patch which 'fixes' this problem by setting the nominated COM port to defaults of `115200,8,N,0` which seems perfectly sensible in 2024. Please contact me for more details. A git diff shown below (with extensive error reporting) + +N.B. Markodown will destroy formatting! + +``` +diff --git a/chardev/char-win.c b/chardev/char-win.c +index d4fb44c4dc..a05896ffe9 100644 +--- a/chardev/char-win.c ++++ b/chardev/char-win.c +@@ -96,12 +96,24 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp) + s->file = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0, NULL, + OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0); + if (s->file == INVALID_HANDLE_VALUE) { ++ { ++ char buffer[1024] = { 0 }; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename); ++ OutputDebugString(buffer); ++ } + error_setg_win32(errp, GetLastError(), "Failed CreateFile"); + s->file = NULL; + goto fail; + } + + if (!SetupComm(s->file, NRECVBUF, NSENDBUF)) { ++ { ++ char buffer[1024] = { 0 }; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename); ++ OutputDebugString(buffer); ++ } + error_setg(errp, "Failed SetupComm"); + goto fail; + } +@@ -110,9 +122,31 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp) + size = sizeof(COMMCONFIG); + GetDefaultCommConfig(filename, &comcfg, &size); + comcfg.dcb.DCBlength = sizeof(DCB); +- CommConfigDialog(filename, NULL, &comcfg); +- ++#if 1 ++ // JME hardwire. There seems to be no mechanism to simply specify serial port options ++ comcfg.dcb.BaudRate = 115200; ++ comcfg.dcb.Parity = NOPARITY; ++ comcfg.dcb.StopBits = ONESTOPBIT; ++ comcfg.dcb.ByteSize = 8; ++#else ++ { ++ BOOL ret = CommConfigDialog(filename, NULL, &comcfg); ++ if (!ret) ++ { ++ char buffer[1024] = { 0 }; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename); ++ OutputDebugString(buffer); ++ } ++ } ++#endif + if (!SetCommState(s->file, &comcfg.dcb)) { ++ { ++ char buffer[1024]={0}; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer,1024,"%s(%d) Error: %d 0x%x %s\r\n",__FILE__,__LINE__,dw,dw, filename); ++ OutputDebugString(buffer); ++ } + error_setg(errp, "Failed SetCommState"); + goto fail; + } +``` + +/label ~"kind::Bug" diff --git a/results/classifier/deepseek-2/output/device/2310 b/results/classifier/deepseek-2/output/device/2310 new file mode 100644 index 000000000..8f6cd6998 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2310 @@ -0,0 +1,2 @@ + +Virtio devices not working diff --git a/results/classifier/deepseek-2/output/device/2330 b/results/classifier/deepseek-2/output/device/2330 new file mode 100644 index 000000000..963beb566 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2330 @@ -0,0 +1,74 @@ + +acpi-erst: divide by zero in make_erst_storage_header() +Description of problem: +When we gives `0` to `record_size` for `acpi-erst` device, below code may triggers divide-by-zero. + +```c +static void make_erst_storage_header(ERSTDeviceState *s) + ... + header->magic = cpu_to_le64(ERST_STORE_MAGIC); + header->record_size = cpu_to_le32(s->default_record_size); + header->version = cpu_to_le16(0x0100); + header->reserved = cpu_to_le16(0x0000); + + /* Compute mapsize */ + mapsz = s->storage_size / s->default_record_size; // devide-by-zero occurs +``` + +`acpi-erst` device refuses invalid value for `record_size` and does appropriate condition check in `check_erst_backend_storage()`, but this check is placed before the function triggering the error when `header->magic` is 0. + +```c +static void check_erst_backend_storage(ERSTDeviceState *s, Error **errp) + ... + /* + * Check if header is uninitialized; HostMemoryBackend inits to 0 + */ + if (le64_to_cpu(header->magic) == 0UL) { + make_erst_storage_header(s); + } + + /* Validity check record_size */ + record_size = le32_to_cpu(header->record_size); + if (!( + (record_size) && /* non zero */ + (record_size >= UEFI_CPER_RECORD_MIN_SIZE) && + (((record_size - 1) & record_size) == 0) && /* is power of 2 */ + (record_size >= 4096) /* PAGE_SIZE */ + )) { + error_setg(errp, "ERST record_size %u is invalid", record_size); + return; + } +``` +Steps to reproduce: +1. make sure `acpi-erst.backing` doesn't exist in current folder. +2. run qemu command. +```bash +./build/qemu-system-i386 -object memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x10000,share=on -device acpi-erst,memdev=erstnvram,record_size=0 +``` +Additional information: +I built qemu from source code with `--enable-sanitizers`, and backtrace is as follows: +```bash +AddressSanitizer:DEADLYSIGNAL +================================================================= +==401519==ERROR: AddressSanitizer: FPE on unknown address 0x55bd0616fd53 (pc 0x55bd0616fd53 bp 0x61f000000e80 sp 0x7fffd16e5d90 T0) + #0 0x55bd0616fd53 in make_erst_storage_header /home/xxx/qemu/build/../hw/acpi/erst.c:401 + #1 0x55bd0616fd53 in check_erst_backend_storage /home/xxx/qemu/build/../hw/acpi/erst.c:431 + #2 0x55bd0616fd53 in erst_realizefn /home/xxx/qemu/build/../hw/acpi/erst.c:973 + #3 0x55bd06268426 in pci_qdev_realize /home/xxx/qemu/build/../hw/pci/pci.c:2093 + #4 0x55bd06557629 in device_set_realized /home/xxx/qemu/build/../hw/core/qdev.c:510 + #5 0x55bd0655ecc8 in property_set_bool /home/xxx/qemu/build/../qom/object.c:2362 + #6 0x55bd0655cec4 in object_property_set /home/xxx/qemu/build/../qom/object.c:1471 + #7 0x55bd06560dec in object_property_set_qobject /home/xxx/qemu/build/../qom/qom-qobject.c:28 + #8 0x55bd0655d30a in object_property_set_bool /home/xxx/qemu/build/../qom/object.c:1541 + #9 0x55bd0632f8cf in qdev_device_add_from_qdict /home/xxx/qemu/build/../system/qdev-monitor.c:719 + #10 0x55bd0632fc91 in qdev_device_add /home/xxx/qemu/build/../system/qdev-monitor.c:738 + #11 0x55bd0633ae7e in device_init_func /home/xxx/qemu/build/../system/vl.c:1203 + #12 0x55bd066e7a50 in qemu_opts_foreach /home/xxx/qemu/build/../util/qemu-option.c:1135 + #13 0x55bd06335421 in qemu_create_cli_devices /home/xxx/qemu/build/../system/vl.c:2640 + #14 0x55bd06335421 in qmp_x_exit_preconfig /home/xxx/qemu/build/../system/vl.c:2709 + #15 0x55bd06338f42 in qemu_init /home/xxx/qemu/build/../system/vl.c:3742 + #16 0x55bd06553e35 in main /home/xxx/qemu/build/../system/main.c:47 + #17 0x7efcdb919d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #18 0x7efcdb919e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #19 0x55bd060ecb24 in _start (/home/xxx/qemu/build/qemu-system-i386+0x32db24) +``` diff --git a/results/classifier/deepseek-2/output/device/2341 b/results/classifier/deepseek-2/output/device/2341 new file mode 100644 index 000000000..b19f1c899 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2341 @@ -0,0 +1,33 @@ + +IVSHMEM device doesn't work for sharing memory with virtiofsd +Description of problem: +Trying to share a folder on the host to the guest with `virtiofsd` using the `ivshmem-plain` device doesn't work (for memory sharing), while using a NUMA node (with `-numa node,memdev=mem`) works just fine. +Steps to reproduce: +1. Install `virtiofsd` +2. Run `/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir=$HOME --cache always` as a regular user (or with another shared directory, it doesn't matter) +3. Run QEMU with the aforementioned command line as a regular user +4. Wait a bit for the OS to load and `virtiofsd` should error out +Additional information: +`virtiofsd` logs: +``` +[2024-05-09T19:49:15Z WARN virtiofsd::sandbox] Couldn't set the process uid as root: -1 +[2024-05-09T19:49:15Z WARN virtiofsd::sandbox] Couldn't set the process gid as root: -1 +[2024-05-09T19:49:15Z INFO virtiofsd] Waiting for vhost-user socket connection... +[2024-05-09T19:49:16Z INFO virtiofsd] Client connected, servicing requests +[2024-05-09T19:49:22Z ERROR virtiofsd] Waiting for daemon failed: HandleRequest(ReqHandlerError(Custom { kind: Other, error: MissingMemoryMapping })) +``` + +QEMU logs (after virtiofsd errors out and exits): +``` +qemu: Failed to read msg header. Read -1 instead of 12. Original request 0. +qemu: Failed to write msg. Wrote -1 instead of 20. +qemu: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu: Failed to set msg fds. +qemu: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu: Error starting vhost: 5 +qemu: Failed to set msg fds. +qemu: vhost_set_vring_call failed 22 +qemu: Failed to set msg fds. +qemu: vhost_set_vring_call failed 22 +qemu: Unexpected end-of-file before all data were read +``` diff --git a/results/classifier/deepseek-2/output/device/2342 b/results/classifier/deepseek-2/output/device/2342 new file mode 100644 index 000000000..4b5f2c9bb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2342 @@ -0,0 +1,2 @@ + +DEREF_OF_NULL.RET in qdev-clock.c diff --git a/results/classifier/deepseek-2/output/device/2350 b/results/classifier/deepseek-2/output/device/2350 new file mode 100644 index 000000000..a5d625d42 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2350 @@ -0,0 +1,15 @@ + +Incorrect RNG_CTRL and RNG_DATA_OUTPUT register offets for Aspeed AST2600 A3 +Description of problem: +hw/misc/aspeed_scu.c has the following lines: + +#define AST2600_RNG_CTRL TO_REG(0x524) +#define AST2600_RNG_DATA TO_REG(0x540) + +The Datasheet for the AST2600 A3 lists the offsets as 0x520 for RNG_CTRL and 0x524 for RNG_DATA. I can confirm that these addresses are correct on the hardware. I don't know if the offsets changed from a previous revision, but since qemu fills the SILICON_REV register with the AST2600_A3_SILICON_REV value for the AST2600, it makes sense to me that it would use the A3 register offsets. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2357 b/results/classifier/deepseek-2/output/device/2357 new file mode 100644 index 000000000..065002d47 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2357 @@ -0,0 +1,19 @@ + +assert in dwc2 +Description of problem: +The following log reveals it: + +``` +ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached +Bail out! ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached +Aborted +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-aarch64 -display \ +none -machine accel=qtest, -m 512M -machine raspi2b -m 1G -nodefaults \ +-usb -drive file=null-co://,if=none,format=raw,id=disk0 -device \ +usb-storage,port=1,drive=disk0 -qtest stdio +readl 0x3f980dfb +EOF +``` diff --git a/results/classifier/deepseek-2/output/device/2359 b/results/classifier/deepseek-2/output/device/2359 new file mode 100644 index 000000000..f9423ad15 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2359 @@ -0,0 +1,33 @@ + +assert in virtio-iommu +Description of problem: +The following log reveals it: + +``` +qemu-system-x86_64: qemu/hw/virtio/virtio-iommu.c:821: void virtio_iommu_handle_command(VirtIODevice *, VirtQueue *): Assertion `sz == output_size' failed. +Aborted +``` +Steps to reproduce: +``` +cat << EOF | \qemu-system-x86_64 \ +-display none -machine accel=qtest -m 512M -machine q35 -nodefaults \ +-device virtio-iommu -qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0004000 +write 0x10000e 0x1 0x01 +write 0xe0004020 0x4 0x00001000 +write 0xe0004028 0x4 0x00101000 +write 0xe000401c 0x1 0x01 +write 0x106000 0x1 0x05 +write 0x100001 0x1 0x60 +write 0x100002 0x1 0x10 +write 0x100009 0x1 0x04 +write 0x10000c 0x1 0x01 +write 0x100018 0x1 0x04 +write 0x10001c 0x1 0x02 +write 0x101003 0x1 0x01 +write 0xe0007001 0x1 0x00 +EOF +``` diff --git a/results/classifier/deepseek-2/output/device/236 b/results/classifier/deepseek-2/output/device/236 new file mode 100644 index 000000000..bbb84b258 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/236 @@ -0,0 +1,2 @@ + +CPU fetch from unpopulated ROM on reset diff --git a/results/classifier/deepseek-2/output/device/2388 b/results/classifier/deepseek-2/output/device/2388 new file mode 100644 index 000000000..d25c6df93 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2388 @@ -0,0 +1,18 @@ + +NVMe SQ processing gets stuck when IO queue size is small (for example 4) +Steps to reproduce: +1. Get OSv repo with the NVMe driver and build OSv with the 'Hello World' example: +``` +git clone https://github.com/wkozaczuk/osv.git +cd osv +git checkout nvme_refined +git submodule update --init --recursive +./scripts/setup.py +./scripts/build image=native-example fs=zfs -j$(nproc) +``` +2. Run OSv with NVme on and point to your version of QEMU built with tracing enabled: +``` +./scripts/run.py --qemu-path /home/wkozaczuk/projects/qemu/build/qemu-system-x86_64 --nics=0 --nvme -c 1 --pass-arg "--trace pci_nvme_*" +``` +Additional information: +I am adding both full QEMU logs with NVMe tracing enabled and diff of my changes to QEMU code to add extra logging. diff --git a/results/classifier/deepseek-2/output/device/2395 b/results/classifier/deepseek-2/output/device/2395 new file mode 100644 index 000000000..d01430ec9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2395 @@ -0,0 +1,61 @@ + +qemu-system-x86_64: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed when paused vm migrating (with shared storage) from dest to src host +Description of problem: +We are doing migration tests with share storage (nfs) as follows: +First, we pause the virtual machine using the 'virsh suspend'command, then migrate the virtual machine to the destination host by 'virsh migrate' command, and there is no problem. After the migration is complete, the virtual machine remains paused on the destination host. However, when we migrate the virtual machine back to the original host, an assertion error is triggered on the current host（dest host）: + +``` +705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed +``` + +and virsh migrate commant return error: +``` +**virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe +Migration: [ 98 %]error: operation failed: domain is not running** +``` +Steps to reproduce: +1. We create an vm with shareable storage and then paused vm in source host: + ``` + virsh create test.xml running + virsh suspend test paused + ``` +2. Migrate vm to the destination host: + ``virsh migrate test qemu+tcp://dest_ip/system tcp://dest_ip --live --verbose --unsafe`` +3. In destination host，vm is paused. +4. Migrate vm back to the source host，and then migration failed and assert error in qemu log in destination host: + ``` + virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe + Migration: [ 98 %]error: operation failed: domain is not running + ``` + ``` + 705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & + BDRV_O_INACTIVE)' failed. + 706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed + ``` +Additional information: +1) src -----> dest + ``` +migration_thread() + migration_completion + global_state_store() + vm_stop_force_state(RUN_STATE_FINISH_MIGRATE) + qemu_savevm_state_complete_precopy_nop_iterable() + bdrv_inactivate_all () + bdrv_inactivate_recurse() + bs->open_flags |= BDRV_O_INACTIVE; (BDRV_O_INACTIVE=0x0800) +``` + +2) dest -----> src +``` +migration_thread() + qemu_savevm_state_complete_precopy_non_iterable() + bdrv_inactivate_all () + bdrv_inactivate_recurse() + assert(!(bs->open_flags & BDRV_O_INACTIVE)); Assert and Crash +``` + + +I'm not sure how to address this issue. If QEMU does not support such a migration, a gentler way would be to directly report an error and exit, just like what did in migrate_prepare function， instead of crash qemu. + +If you have any ideas, please let me know, thanks. diff --git a/results/classifier/deepseek-2/output/device/2399 b/results/classifier/deepseek-2/output/device/2399 new file mode 100644 index 000000000..29d3271ec --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2399 @@ -0,0 +1,28 @@ + +division by zero in ide +Description of problem: +The following log reveals it: + +``` +../hw/ide/core.c:659:26: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/core.c:659:26 in AddressSanitizer:DEADLYSIGNAL ================================================================= +==4104568==ERROR：AddressSanitizer：FPE on unknown address 0x559d996a7ec3 (pc 0x559d996a7ec3 bp 0x7ffdcf109da0 sp 0x7ffdcf109a40 T0) +#0 0x559d996a7ec3 in ide_set_sector qemu/hw/ide/core.c:659:26 +#1 0x559d996c8dee in ide_sector_read_cb qemu/hw/ide/core.c:786:5 +#2 0x559d996aa50a in ide_buffered_readv_cb qemu/hw/ide/core.c:684:9 +#3 0x559d9b499289 in blk_aio_complete qemu/block/block-backend.c:1555:9 +#4 0x559d9b4891af in blk_aio_complete_bh qemu/block/block-backend.c:1565:5 +#5 0x559d9bbef6b1 in aio_bh_call qemu/util/async.c:171:5 +#6 0x559d9bbf058c in aio_bh_poll qemu/util/async.c:218:13 +#7 0x559d9bb58a28 in aio_dispatch qemu/util/aio-posix.c:423:5 +#8 0x559d9bbf69ce in aio_ctx_dispatch qemu/util/async.c:360:5 +#9 0x7f51fbc77d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0) +0x55d3a.+0x55d3a) +#10 0x559d9bbfa229 in glib_pollfds_poll qemu/util/main-loop.c:287:9 +#11 0x559d9bbf8b63 in os_host_main_loop_wait qemu/util/main-loop.c:310:5 +#12 0x559d9bbf872c in main_loop_wait qemu/util/main-loop.c:589:11 +#13 0x559d9a2640e7 in qemu_main_loop qemu/system/runstate.c:796:9 +#14 0x559d9b1dcaec in qemu_default_main qemu/system/main.c:37:14 +#15 0x559d9b1dcb37 in main qemu/system/main.c:48:12 +#16 0x7f51fb229d8f in __libc_start_call_main csu/.../sysdeps/nptl/libc_start_call_main.h:58:16 +#17 0x7f51fb229e3f in __libc_start_main csu/../csu/libc-start.c:392:3 #18 0x559d98f20ed4 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x1f93ed4) +``` diff --git a/results/classifier/deepseek-2/output/device/241119 b/results/classifier/deepseek-2/output/device/241119 new file mode 100644 index 000000000..3e1c4a52a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/241119 @@ -0,0 +1,20 @@ + +usb_add of a Creative ZEN unrecognized in guest + +Binary package hint: kvm + +This happens when I add my Creative ZEN to a virtual machine running XP. The device is recognised well at first and drivers are installed correctly. But when trying to connect windows crashes with the classic blue screen It complains about something like usbohci.sys, I can't read well because it crashes too fast. +I have also tried with another virtual machine running Vista, same results. +Any help would be really appreciated! + +I'm using the module kvm-amd with Ubuntu 8.04 + +The USB device has the following ID: 041e:4157 Creative Technology, Ltd + +kvm: + Installed: 1:62+dfsg-0ubuntu7 + Candidate: 1:62+dfsg-0ubuntu7 + Version table: + *** 1:62+dfsg-0ubuntu7 0 + 500 http://archive.ubuntu.com hardy/main Packages + 100 /var/lib/dpkg/status \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/2415 b/results/classifier/deepseek-2/output/device/2415 new file mode 100644 index 000000000..b0fd0beb4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2415 @@ -0,0 +1,54 @@ + +Assertion `r->req.aiocb == NULL' in am53c974 device +Description of problem: +The following log reveals it: + +``` +qemu-truman-x86_64-4467afcc: qemu/hw/scsi/scsi-disk.c:558: void scsi_write_data(SCSIRequest *): Assertion `r->req.aiocb == NULL' failed. +==2957464== ERROR: libFuzzer: deadly signal + #0 0x55e76f00e911 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55e76ef88fb8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 + #2 0x55e76ef6d1b3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 + #3 0x7f83d604251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) + #4 0x7f83d60969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7f83d60969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7f83d60969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7f83d6042475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7f83d60287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7f83d602871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7f83d6039e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x55e76fbb55a5 in scsi_write_data qemu/hw/scsi/scsi-disk.c:558:5 + #12 0x55e76fb95a1f in scsi_req_continue qemu/hw/scsi/scsi-bus.c + #13 0x55e76fbfe0cc in esp_do_dma qemu/hw/scsi/esp.c + #14 0x55e76fc0be39 in handle_ti qemu/hw/scsi/esp.c:1104:9 + #15 0x55e76fc042f6 in esp_run_cmd qemu/hw/scsi/esp.c:1186:9 + #16 0x55e76fc042f6 in esp_reg_write qemu/hw/scsi/esp.c:1304:9 + #17 0x55e76fc1329b in esp_pci_io_write qemu/hw/scsi/esp-pci.c:248:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none\ +-machine accel=qtest, -m 512M -device am53c974,id=scsi -device \ +scsi-hd,drive=disk0 -drive id=disk0,if=none,file=null-co://,format=raw \ +-nodefaults -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc03e 0x030000 +outl 0xc009 0xc1000000 +outl 0xc008 0x8a +outl 0xc00d 0x0 +outl 0xc009 0x00 +outl 0xc00c 0x11 +outl 0xc00d 0x0 +outl 0xc00d 0x00 +outl 0xc00d 0x0 +outw 0xc00f 0x00 +outb 0xc00d 0x0 +outl 0xc00d 0x0 +outl 0xc009 0x41000000 +outb 0xc00c 0x90 +outl 0xc00d 0x0 +EOF +``` diff --git a/results/classifier/deepseek-2/output/device/2428 b/results/classifier/deepseek-2/output/device/2428 new file mode 100644 index 000000000..9fd572fb8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2428 @@ -0,0 +1,30 @@ + +Null-pointer-dereference in ufs +Description of problem: +The following log reveals it: + +``` +../hw/ufs/ufs.c:740:13: runtime error: member access within null pointer of type 'UfsSq' (aka 'struct UfsSq') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ufs/ufs.c:740:13 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==848760==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x6220e29edfce bp 0x7fffea0c6cf0 sp 0x7fffea0c6c40 T0) +==848760==The signal is caused by a READ memory access. +==848760==Hint: address points to the zero page. + #0 0x6220e29edfce in ufs_mcq_process_db hw/ufs/ufs.c:740:9 + #1 0x6220e29dc10f in ufs_write_mcq_op_reg hw/ufs/ufs.c:758:13 + #2 0x6220e29d85c6 in ufs_mmio_write hw/ufs/ufs.c:813:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 \ +-display none -machine accel=qtest, -m 512M -M q35 -nodefaults -drive \ +file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \ +ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x02 +write 0xe0001004 0x1 0x01 +EOF +``` diff --git a/results/classifier/deepseek-2/output/device/2437 b/results/classifier/deepseek-2/output/device/2437 new file mode 100644 index 000000000..a30f3243b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2437 @@ -0,0 +1,38 @@ + +qm terminal VMID return "Inappropriate ioctl for device" when spawned by an another process +Description of problem: +as i dont want to mess with vnc i want to use qm terminal to interact with my vms and it doesnt work im currently using nodejs as a test heres the code if anybody wanna try it +```js +import { spawn } from "child_process"; +var child = spawn('qm', ["terminal", "100"]); + +child.stdout.setEncoding('utf8'); +child.stdin.setDefaultEncoding("utf8"); +child.stdout.on('data', function (data) { + console.log('stdout: ' + data.trim()); +}); + +child.stderr.setEncoding('utf8'); +child.stderr.on('data', function (data) { + console.log('stderr: ' + data.trim()); +}); + +child.on('close', function (code) { + console.log('closing code: ' + code); +}); + +setInterval(() => { + child.stdin.write("\n"); +}, 5000); +``` +its just spawning qm terminal and sending return every 5 seconds + +it seems to start but crash + +"Inappropriate ioctl for device" + +{width=478 height=48} + +maybe its not the place to put that but i have no clue so here am i + +At least i tryed spawning something else my code is working diff --git a/results/classifier/deepseek-2/output/device/2449 b/results/classifier/deepseek-2/output/device/2449 new file mode 100644 index 000000000..3bf685580 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2449 @@ -0,0 +1,2 @@ + +How to extract FIS (personal question) diff --git a/results/classifier/deepseek-2/output/device/2454 b/results/classifier/deepseek-2/output/device/2454 new file mode 100644 index 000000000..66641b272 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2454 @@ -0,0 +1,9 @@ + +sd: assertion in sd_read_byte() +Description of problem: +The following log reveals it: + +``` +ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached +Bail out! ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached Aborted (core dumped) +``` diff --git a/results/classifier/deepseek-2/output/device/2455 b/results/classifier/deepseek-2/output/device/2455 new file mode 100644 index 000000000..6babaf10e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2455 @@ -0,0 +1,9 @@ + +sdhci: assertion in sdhci_read_dataport() +Description of problem: +The following log reveals it: + +``` +qemu-system-x86_64: qemu/hw/sd/sdhci.c:476: uint32_t sdhci_read_dataport(SDHCIState *, unsigned int): Assertion `s->data_count < s->buf_maxsz' failed. +Aborted (core dumped) +``` diff --git a/results/classifier/deepseek-2/output/device/2462 b/results/classifier/deepseek-2/output/device/2462 new file mode 100644 index 000000000..69d791d3b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2462 @@ -0,0 +1,40 @@ + +QEMU SIFIVE reading from stdin hangs +Description of problem: +I have a simple test program (C and ASM) that reads from stdin. When i was using the qemu provided by Ubuntu, QEMU emulator version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.5), my test was working, and was able to read bytes from stdin. + +Using the latest Qemu from git, breaks my test. I can still print, but now reading hangs, like its always waiting for input but never getting it. + +My guess is that this commit breaks my code: +https://github.com/qemu/qemu/commit/6ee7ba1b8a10bd8eb1d3b918eaaf9f832a51adb4 + +Before the above commit, `qemu_chr_fe_set_handlers` was being called, and that is what allowed the default behavior of reading from stdin is on by default? + +from sifive_uart.c +``` + qemu_chr_fe_set_handlers(&s->chr, sifive_uart_can_rx, sifive_uart_rx, + sifive_uart_event, sifive_uart_be_change, s, + NULL, true); +``` +Steps to reproduce: +1. compile simple C program that calls `read` reading a single byte from stdin +2. do not initialize UART options +3. run in QEMU, send input, hangs. +Additional information: +Other examples online, like riscv-probe, use a uart init function like below: +``` +static void sifive_uart_init() +{ + uart = (int *)(void *)getauxval(SIFIVE_UART0_CTRL_ADDR); + uint32_t uart_freq = getauxval(UART0_CLOCK_FREQ); + uint32_t baud_rate = getauxval(UART0_BAUD_RATE); + uint32_t divisor = uart_freq / baud_rate - 1; + uart[UART_REG_DIV] = divisor; + uart[UART_REG_TXCTRL] = UART_TXEN; + uart[UART_REG_RXCTRL] = UART_RXEN; + uart[UART_REG_IE] = 0; +} +``` + +However, when I was using QEMU 8.0.4, i did not have to write a function like above to init UART, because stdin and stdout were working out of the box. +Below is my C and ASM: diff --git a/results/classifier/deepseek-2/output/device/2467 b/results/classifier/deepseek-2/output/device/2467 new file mode 100644 index 000000000..dc0665578 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2467 @@ -0,0 +1,32 @@ + +OpenSBI 1.5 packaged in QEMU 9.0.50 fails to support poweroff with 'spike' board +Steps to reproduce: +Build upstream U-Boot: + +- git clone https://source.denx.de/u-boot/u-boot.git +- cd u-boot +- make qemu-riscv64_smode_defconfig +- CROSS_COMPILE=riscv64-linux-gnu- make + +Run U-Boot and execute poweroff command + +- qemu-system-riscv64 -kernel u-boot.bin +- poweroff + +Poweroff fails. + +When building upstream OpenSBI v1.5 with + +- git clone https://github.com/riscv-software-src/opensbi.git +- cd opensbi +- git reset --hard v1.5 +- CROSS_COMPILE=riscv64-linux-gnu- make PLATFORM=generic + +and then running + +- qemu-system-riscv64 -bios fw_dynamic.bin -kernel u-boot.bin +- poweroff + +poweroff succeeds. + +Please, distribute an unpatched OpenSBI v1.5 with QEMU. diff --git a/results/classifier/deepseek-2/output/device/2470 b/results/classifier/deepseek-2/output/device/2470 new file mode 100644 index 000000000..8bae3794e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2470 @@ -0,0 +1,32 @@ + +qemu-system-mipsel regression, Linux generated with Buildroot does not boot anymore +Description of problem: +Buildroot Toolchain Builders try to release a new version. See a message from Thomas Petazzoni with the remaining issues: +https://lore.kernel.org/buildroot/20240730223542.273693e5@windsurf/T/#u + +All toolchains generate a system that fails to boot: + +Run /sbin/init as init process +process '/bin/busybox' started with executable stack +Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 + +The interesting thing is that those images boot fine with Qemu v8.2.6, +but they fail to boot with Qemu v9.0.2. + +I tracked it down to this commit: +commit 4e999bf4197ae3dc58b7092260f98146920a7469 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Sun Jan 28 15:58:52 2024 +1000 + + target/mips: Pass ptw_mmu_idx down from mips_cpu_tlb_fill + + Rather than adjust env->hflags so that the value computed + by cpu_mmu_index() changes, compute the mmu_idx that we + want directly and pass it down. + + Introduce symbolic constants for MMU_{KERNEL,ERL}_IDX. + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + +Unfortunately just reverting this commit in 9.0.2 does not help, Qemu segfaults on Linux Kernel boot then. diff --git a/results/classifier/deepseek-2/output/device/2471 b/results/classifier/deepseek-2/output/device/2471 new file mode 100644 index 000000000..73d44c912 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2471 @@ -0,0 +1,2 @@ + +error handling in of_dpa_cmd_add_acl() diff --git a/results/classifier/deepseek-2/output/device/2472 b/results/classifier/deepseek-2/output/device/2472 new file mode 100644 index 000000000..a52d2abf9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2472 @@ -0,0 +1,2 @@ + +optimize nvme_directive_receive() function diff --git a/results/classifier/deepseek-2/output/device/2478 b/results/classifier/deepseek-2/output/device/2478 new file mode 100644 index 000000000..9ddd49a91 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2478 @@ -0,0 +1,19 @@ + +STM32F1 STM32VLDicovery board: incorrect clock register setting +Description of problem: +The execution of the program hangs when testing, from libopencm3 clock initialization, the status of the clock in ``rcc_wait_for_osc_ready()``. This function https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/f1/rcc.c#L366 loops until the bit stating that the oscillator is stabilized is set. I am unable to find in qemu this bit being set upon clock initialization, which I believe is an hardware emulation shortcoming. Commenting this line in libopencm3 allows for the emulation to complete correctly, but I believe the error lies in the hardware emulation and not in the libopencm3 test. Reading the status of ``RCC_CR`` from ``gdb-multiarch`` probing the QEMU internal state returns 0, leading to the failure of the test at https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/f1/rcc.c#L353 + +See https://www.st.com/resource/en/reference_manual/rm0008-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf for the expected behavior of this register content on page 99/1136 +``` +7.3.1 Clock control register (RCC_CR) + +Bit 17 HSERDY: External high-speed clock ready flag +Set by hardware to indicate that the HSE oscillator is stable. This bit needs 6 cycles of the +HSE oscillator clock to fall down after HSEON reset. +0: HSE oscillator not ready +1: HSE oscillator ready +``` +Steps to reproduce: +1. git clone --recursive https://github.com/libopencm3/libopencm3-examples +2. make +3. qemu-system-arm -M stm32vldiscovery -nographic -serial mon:stdio -kernel examples/stm32/f1/stm32vl-discovery/usart/usart.elf diff --git a/results/classifier/deepseek-2/output/device/2484 b/results/classifier/deepseek-2/output/device/2484 new file mode 100644 index 000000000..c56914151 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2484 @@ -0,0 +1,2 @@ + +Confusing query-gic-capabilities output in --without-default-devices config diff --git a/results/classifier/deepseek-2/output/device/2513 b/results/classifier/deepseek-2/output/device/2513 new file mode 100644 index 000000000..c2668019e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2513 @@ -0,0 +1,14 @@ + +CXL Device Missing PCI_CAP_ID_PM (01h) in CAP List Implementation According to PCIe SPEC +Description of problem: +- The lack of **PCI_CAP_ID_PM (01h)** will not cause any crash or error when running QEMU, but it is violated to the PCIe SPEC. +- When some vendors test the power management capability (e.g., Linux Runtime PM), they must manually implement this CAP list to support the D1/D2/D3_Hot d-states changes. +- We don't see any PCI_CAP_ID_PM (01h) in the CXL rootport or endpoint + + {width=349 height=474} + + +# +Steps to reproduce: +1. Run the qemu-system-x86 (See QEMU command line) +2. sudo lspci -xxx diff --git a/results/classifier/deepseek-2/output/device/2521 b/results/classifier/deepseek-2/output/device/2521 new file mode 100644 index 000000000..cabb294d3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2521 @@ -0,0 +1,17 @@ + +USB Passthrough Improper Remote Wakeup +Description of problem: +I am doing research with Linux Power Management interactions with USB devices. Which is why I would like to be able to wake a qemu vm from suspend with a passed through USB device. The first issue is that remote wakeup from usb devices do not wake the vm at all when running in -nographic mode (issuing system_wakeup from a qemu monitor shell will wake it though). When running with a GUI it is possible to wake the vm from a usb device as well as the qemu monitor shell but both will result in the GUI screen being black afterwards. It is still possible to use the vm though. Finally, waking the vm with a usb device is only possible when a valid usb device is passed through in the qemu launch command line. But interestingly the usb device specified to be passed through will only wakeup the vm if it is unplugged and plugged back in during the suspend. All other usb devices can wakeup the vm normally even though they are not passed through. It is not clear to me what is going on here and why other devices not being passed through to qemu can wake the vm. Note I have also enabled the /sys/bus/usb/devices/usb#/power/wakeup file and have manually unsuppressed the remote_wakeup flag in the source code to enable the /sys/bus/usb/devices/#-#/power/wakeup files to be generated but it has not affected anything. +Steps to reproduce: +I have tested this issue with multiple kernel versions (6.10, 6.10-rc4, 6.6.43) as well as custom and generic kernel configs and different debian images so these do not seem to be the problem. But here is a detailed description of the exact setup I am currently using: + +1. Download linux-6.10-rc4 source and configure with syzkaller fuzzing config https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-usb.config +2. Set CONFIG_KCOV_INSTRUMENT_ALL to off (breaks suspend/resume in vm) and create bzImage +2. Create a debian bookworm image with syzkaller script https://github.com/google/syzkaller/blob/master/tools/create-image.sh +3. Download and build Qemu from source (see attached for detailed configuration and dependencies) +4. Attach a usb keyboard and mouse +5. Choose one device to pass through via command line +6. Try waking the vm with nographic and graphic mode using the usb devices +Additional information: +[configuration_output.txt](/uploads/f7d3487dab65deef40bd0e110b64a573/configuration_output.txt) +[gui_wakeup_log.txt](/uploads/72b192a88d587eced4bb4032307307e5/gui_wakeup_log.txt) diff --git a/results/classifier/deepseek-2/output/device/2534 b/results/classifier/deepseek-2/output/device/2534 new file mode 100644 index 000000000..85f20e430 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2534 @@ -0,0 +1,11 @@ + +Solaris cannot be power offed with system_powerdown on qemu-system-sparc +Description of problem: +When a `system_powerdown` is done in the QEMU Monitor, nothing happens. Also happens with `qemu-system-sparc.exe` version 9.1.0-rc3, that is, it's not fixed in newer versions. Looking at [sun4m.c](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/sparc/sun4m.c#L451) code, it registers a system_powerdown handler, but it's not working. +Steps to reproduce: +1. Start the machine with the command line above and wait for the complete OS initialization +2. Open the machine monitor +3. Do a `system_powerdown` command +4. Nothing will happen +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2538 b/results/classifier/deepseek-2/output/device/2538 new file mode 100644 index 000000000..e9c3536c6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2538 @@ -0,0 +1,27 @@ + +qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed. +Description of problem: +Cannot enter the loongarch64 UEFI shell due to the error below: +qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed. +Steps to reproduce: +1.follow the steps to create an empty loongarch64 uefi bare metal. +2.Click start the installation +3.Then the error occurs. +Additional information: +``` +qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, 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 695, in start_install + domain = self._create_guest( + ^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/lib64/python3.12/site-packages/libvirt.py", line 4545, in createXML + raise libvirtError('virDomainCreateXML() failed') +``` diff --git a/results/classifier/deepseek-2/output/device/2549 b/results/classifier/deepseek-2/output/device/2549 new file mode 100644 index 000000000..cda127962 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2549 @@ -0,0 +1,4 @@ + +qemu-system-arm, ast2400-a1, The ECC_TEST_CTRL register of aspeed_2400_sdmc_write is not implemented +Additional information: +The ast2400-a1 has a few more memory test modes compared to the ast2500-a2 (1xxb in 8:6 and 11b in 2:1), but I think it should be enough to always return a test pass result. diff --git a/results/classifier/deepseek-2/output/device/2551 b/results/classifier/deepseek-2/output/device/2551 new file mode 100644 index 000000000..0847254f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2551 @@ -0,0 +1,14 @@ + +RTC time could run slow 3s than host time when clock=vm & base=UTC +Description of problem: +When start qemu with `-rtc base=utc,clock=vm`, sometime guest time can slower 3s than host. There's no problem (also didn't be noticed) as we often start ntp service, who will adjust our system time. But let's talk about if we havn't enable NTP service(for example system just booted) + +After inspect into the code, i found that there are two problem we should think about: +# +Steps to reproduce: +1. start vm with `-rtc base=utc,clock=vm` +2. disable NTP (OS specific)`systemctl disable --now ntpd;systemctl disable --now ntpdate` +3. reboot in the guest +4. after guest started, compare guest time with host time(at the same time) `date +'%F %T.%3N'` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2561 b/results/classifier/deepseek-2/output/device/2561 new file mode 100644 index 000000000..e0d6a19b1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2561 @@ -0,0 +1,40 @@ + +Sound doesnt work on debian guest + debian host using Pipewire +Description of problem: +There is no sound on Debian Stable VM. Im using SPICE for audio redirection. +Steps to reproduce: +1. Download debian stable ISO (12 atm) +2. Install it on your KVM +3. Make sure your host and your guest are using pipewire (check https://wiki.debian.org/PipeWire#Installation) +4. No sound is transmitted to the host. +Additional information: +- I have tried switching SPICE to something else like ALSA, but it will result in hanging of the video page similar to this video: + +https://github.com/QubesOS/qubes-issues/issues/1698#issuecomment-1031376517 + +- Tried to use direct pipewire, but resulted into error: + +``` +Error starting domain: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package? + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + ^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup + self._backend.create() + File "/usr/lib/python3/dist-packages/libvirt.py", line 1379, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package? +``` + +Yes i have installed "qemu-system-gui" but still got the same message. + + +Debian XML with SPICE: + +[Debian-XML.txt](/uploads/66e09b37f672b49f8f0a0a01d3c6a6b2/Debian-XML.txt) diff --git a/results/classifier/deepseek-2/output/device/2576 b/results/classifier/deepseek-2/output/device/2576 new file mode 100644 index 000000000..bc6952560 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2576 @@ -0,0 +1,2 @@ + +virtio-balloon: Assertion `mrs.mr' failed. diff --git a/results/classifier/deepseek-2/output/device/2583 b/results/classifier/deepseek-2/output/device/2583 new file mode 100644 index 000000000..af52c2f1a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2583 @@ -0,0 +1,26 @@ + +libvfio-user.so.0 missing in /lib/x86_64-linux-gnu/ in fresh install of 9.1.50 +Description of problem: +Library libvfio-user.so.0 is missing from /lib/x86_64-linux-gnu. qemu-system-x86_64 does not start due to missing library. + +```` +root@jpbdeb:~# ls -al /usr/local/bin/qemu-system-x86_64 +-rwxr-xr-x 1 root root 81734576 Sep 21 21:48 /usr/local/bin/qemu-system-x86_64 +root@jpbdeb:~# ldd /usr/local/bin/qemu-system-x86_64 + linux-vdso.so.1 (0x00007fff511de000) + libvfio-user.so.0 => not found + libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f73eba33000) + libxenctrl.so.4.17 => /lib/x86_64-linux-gnu/libxenctrl.so.4.17 (0x00007f73eba09000) + libxenstore.so.4 => /lib/x86_64-linux-gnu/libxenstore.so.4 (0x00007f73eb9fe000) + libxenforeignmemory.so.1 => /lib/x86_64-linux-gnu/libxenforeignmemory.so.1 (0x00007f73eb9f9000) + ... +```` +Steps to reproduce: +1. Fresh OS install, including all packages necessary to build from source. +2. Download source from gitlab and proceed with documented build instructions. +3. make install +4. Attempt to run /usr/local/bin/qemu-system-x86_64 fails, due to missing library. +Additional information: +Adding the link to the library that exists in /usr/lib/x86_64-linux-gnu resolves the issue: + +(as root) ln -s /usr/local/lib/x86_64-linux-gnu/libvfio-user.so.0 /lib/x86_64-linux-gnu/libvfio-user.so.0 diff --git a/results/classifier/deepseek-2/output/device/259 b/results/classifier/deepseek-2/output/device/259 new file mode 100644 index 000000000..9a8420913 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/259 @@ -0,0 +1,2 @@ + +dma_blk_cb leaks memory map handles on misaligned IO diff --git a/results/classifier/deepseek-2/output/device/2591 b/results/classifier/deepseek-2/output/device/2591 new file mode 100644 index 000000000..0817f60a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2591 @@ -0,0 +1,2 @@ + +Black screen and DTB errors while trying to emulate the kernel of the RaspiOS (based on Debian Bookworm) using the parameter -machine raspi4b diff --git a/results/classifier/deepseek-2/output/device/2609 b/results/classifier/deepseek-2/output/device/2609 new file mode 100644 index 000000000..4beba3f1c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2609 @@ -0,0 +1,12 @@ + +Blue screen in Windows XP +Description of problem: +When starting the installation of Windows XP when using a virtioblk device you immediately get a bluescreen: `STOP: 0x000000A5 (0x00000002, 0x8A1A6008, 0xE1018808, 0x8A1B7F00)`. I think this happens even before it loads the SATA drivers that are slipstreamed in the ISO. + +After a lot of Googling about this error 0x000000A5 I found some posts suggesting that changing the machine type from `q35` to `pc-q35-2.10` solves the issue. And it worked. Anything above 2.10 (for example 2.11) and the bluescreens return. + +So I always used this solution, but in QEMU 9.1.0 it warns that `pc-q35-2.10` will be removed soon. This would mean there is no way anymore to install XP to a SATA disk unattendly. +Steps to reproduce: +1. Use a virtioblk disk and SATA drivers +2. Start the Windows XP installer +3. Bluescreen will appear diff --git a/results/classifier/deepseek-2/output/device/2615 b/results/classifier/deepseek-2/output/device/2615 new file mode 100644 index 000000000..f1bc89346 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2615 @@ -0,0 +1,11 @@ + +tpm_emulator: the qemu process will be blocked while receiving an unexpected ctrl command's response from the swtpm +Description of problem: +When the swtpm sends the unexpected ctrl command's repsonse to the qemu process, the qemu will be blocked. When we use the gdb to attach the qemu process, we will find out that the qemu process is blocked in `recv_msg` function. +Steps to reproduce: +1.The QEMU process sends a `CMD_GET_TPMESTABLISHED` control command to the swtpm. +2.If the swtpm is not currently active (`tpm_running` is false), it responds to the QEMU process with an err_not_running message, which has a fixed size of 4 bytes. +(Reference: https://github.com/stefanberger/swtpm/blob/master/src/swtpm/ctrlchannel.c#L938) +3. However, the QEMU process expects to receive a valid response (ptm_est est) of 8 bytes. Consequently, the QEMU process will be blocked in the recv_msg function if the response does not match the expected format. +Additional information: +After analysing the source codes in `tpm_emulator.c`, we found that qemu does not process the unexpected ctrol command response from the swtpm correctly (e.g. `CMD_GET_TPMESTABLISHED`). The qemu would be blocked in this function if it received unexpected response from the swtpm (https://gitlab.com/qemu-project/qemu/-/blob/3e9f48bcdabe57f8f90cf19f01bbbf3c86937267/backends/tpm/tpm_emulator.c#L140). diff --git a/results/classifier/deepseek-2/output/device/2616 b/results/classifier/deepseek-2/output/device/2616 new file mode 100644 index 000000000..c3a6400af --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2616 @@ -0,0 +1,12 @@ + +crashout on any storage operation on SCO OpenServer 6 +Description of problem: +it's hard to exactly pinpoint what's wrong, but apparently it's a known issue. whenever i attempt to install or boot the OS, i get one of the two outcomes: with KVM it's a halt-and-catch-fire, getting stuck in an eternal loop of I/O errors and failed interrupts, with TCG at the very least the drivers get loaded and the installation disk is mounted, contrary to the emulated hard drive. connecting either drive to SCSI made HBA act like it's not there at all, and using the standard AHCI/IDE controllers leads to the result presented in the picture in one of the sections below, and, as mentioned earlier, this stage only happens with TCG. there's a 9:1 shot (on Q35, on PIIX3/PIIX4 it'll always either throw this exception or fail to initialise the CD-ROM) of it either screaming about a power failure right as it's ready to format the drive or it just installing. +Steps to reproduce: +1. download the old OpenServer 6 VM image/ISO from the SCO/Xinuos server. +2. attach it in your config. +3. go through initial setup stages (eg. entering a licence or deferring from such). +4. wait for the disk initialisation to begin. +Additional information: + + diff --git a/results/classifier/deepseek-2/output/device/2625 b/results/classifier/deepseek-2/output/device/2625 new file mode 100644 index 000000000..0bda855a9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2625 @@ -0,0 +1,84 @@ + +Adding TPM support for ARM SBSA-Ref machine +Additional information: +Here is a proposed change where a new memory region is added to the machine initialization routine: + +```diff +diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c +index e3195d5449..84bc7d9adb 100644 +--- a/hw/arm/sbsa-ref.c ++++ b/hw/arm/sbsa-ref.c +@@ -28,6 +28,8 @@ + #include "sysemu/numa.h" + #include "sysemu/runstate.h" + #include "sysemu/sysemu.h" ++#include "sysemu/tpm.h" ++#include "sysemu/tpm_backend.h" + #include "exec/hwaddr.h" + #include "kvm_arm.h" + #include "hw/arm/boot.h" +@@ -94,6 +96,7 @@ enum { + SBSA_SECURE_MEM, + SBSA_AHCI, + SBSA_XHCI, ++ SBSA_TPM, + }; + + struct SBSAMachineState { +@@ -132,6 +135,7 @@ static const MemMapEntry sbsa_ref_memmap[] = { + /* Space here reserved for more SMMUs */ + [SBSA_AHCI] = { 0x60100000, 0x00010000 }, + [SBSA_XHCI] = { 0x60110000, 0x00010000 }, ++ [SBSA_TPM] = { 0x60120000, 0x00010000 }, + /* Space here reserved for other devices */ + [SBSA_PCIE_PIO] = { 0x7fff0000, 0x00010000 }, + /* 32-bit address PCIE MMIO space */ +@@ -629,6 +633,24 @@ static void create_smmu(const SBSAMachineState *sms, PCIBus *bus) + } + } + ++static void create_tpm(SBSAMachineState *sbsa, PCIBus *bus) ++{ ++ Error *errp = NULL; ++ DeviceState *dev; ++ ++ TPMBackend *be = qemu_find_tpm_be("tpm0"); ++ if (be == NULL) { ++ error_report("Couldn't find tmp0 backend"); ++ return; ++ } ++ ++ dev = qdev_new(TYPE_TPM_TIS_SYSBUS); ++ object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp); ++ object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp); ++ sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal); ++ sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, sbsa_ref_memmap[SBSA_TPM].base); ++} ++ + static void create_pcie(SBSAMachineState *sms) + { + hwaddr base_ecam = sbsa_ref_memmap[SBSA_PCIE_ECAM].base; +@@ -686,6 +708,8 @@ static void create_pcie(SBSAMachineState *sms) + pci_create_simple(pci->bus, -1, "bochs-display"); + + create_smmu(sms, pci->bus); ++ ++ create_tpm(sms, pci->bus); + } + + static void *sbsa_ref_dtb(const struct arm_boot_info *binfo, int *fdt_size) +``` + +With such, the tpm can get used when setting the TPM base address to be 0x60120000 with the following launching command: + +```bash +qemu-system-aarch64 -machine sbsa-ref,gic-version=3,acpi=off \ + -cpu host -m 4G \ + -nographic -accel kvm \ + -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ + -tpmdev emulator,id=tpm0,chardev=chrtpm \ + -device virtio-blk-pci,drive=drv0 \ + -drive format=qcow2,file=hda.qcow2,if=none,id=drv0 \ + -drive if=pflash,format=raw,file=flash0.img,readonly=on \ + -drive if=pflash,format=raw,file=flash1.img +``` diff --git a/results/classifier/deepseek-2/output/device/2631 b/results/classifier/deepseek-2/output/device/2631 new file mode 100644 index 000000000..5c94da5a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2631 @@ -0,0 +1,82 @@ + +qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Description of problem: +While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality. +Steps to reproduce: +Here is qtest reproducer: +```bash +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +``` + +and execution log: +``` +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +[I 0.000001] OPENED +[R +0.067760] outl 0xcf8 0x80001020 +[S +0.067795] OK +OK +[R +0.067821] outl 0xcfc 0xe0800000 +[S +0.067959] OK +OK +[R +0.067993] outl 0xcf8 0x80001004 +[S +0.068005] OK +OK +[R +0.068020] outw 0xcfc 0x02 +[S +0.068520] OK +OK +[R +0.068554] write 0xe0800010 0x4 0x6100 +qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Aborted +``` + +If you need more information, let me know so I can discuss more about this issue. +Additional information: +```c +int msix_init(PCIDevice *dev, unsigned short nentries, + MemoryRegion *table_bar, uint8_t table_bar_nr, + unsigned table_offset, MemoryRegion *pba_bar, + uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos, + Error **errp); +int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries, + uint8_t bar_nr, Error **errp); +``` + +`msix_init` accepts `nentries` as `unsigned short` type. + +```c +static void virtio_pci_device_plugged(DeviceState *d, Error **errp): + + ... + + if (proxy->nvectors) { + int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors, + proxy->msix_bar_idx, NULL); + if (err) { + /* Notice when a system that supports MSIx can't initialize it */ + if (err != -ENOTSUP) { + warn_report("unable to init msix vectors to %" PRIu32, + proxy->nvectors); + } + proxy->nvectors = 0; + } + } +``` + +When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`. +This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash. + +While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration. diff --git a/results/classifier/deepseek-2/output/device/2635 b/results/classifier/deepseek-2/output/device/2635 new file mode 100644 index 000000000..376db2eca --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2635 @@ -0,0 +1,13 @@ + +A use-after-free bug in pflash_cfi01 snapshot implementation +Description of problem: +The flash snapshot restore does not function correctly. Basically when you use “if=pflash,format=raw,unit=0,file=OVMF_VAR.fd", it crashes when trying to restore a snapshot. + +The root cause is: + +1. In system/runstate.c, function vm_state_notify loops through vm_change_state_head list and calls the callback function for each entry. +2. One of the callback function pointer points to function postload_update_cb in hw/block/pflash_cfi01.c. +3. In function postload_update_cb, it calls qemu_del_vm_change_state_handler in which the entry element memory is freed. +4. Note that, it is still running in the loop, the entry will be visited and get executed, the function pointer may point to a wide memory. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2636 b/results/classifier/deepseek-2/output/device/2636 new file mode 100644 index 000000000..dd1425d73 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2636 @@ -0,0 +1,2 @@ + +ast2600 fails to run u-boot diff --git a/results/classifier/deepseek-2/output/device/2645 b/results/classifier/deepseek-2/output/device/2645 new file mode 100644 index 000000000..39e8896e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2645 @@ -0,0 +1,24 @@ + +Failed shutdown during record with `ide-hd` disk. +Description of problem: +Running `shutdown -h now` on the guest with an `ide-hd` disk during a recording results in a long wait, followed by a BMDMA error. +Steps to reproduce: +1. Install Ubuntu Server guest OS and create disk snapshot +1. Reboot and log in: `qemu-system-x86_64 -hda ubuntu_snapshot.qcow2 -m 2g -net none -monitor stdio` +2. Take a snapshot: `savevm loggedin` +3. Start recording from VM snapshot: `./qemu/build/qemu-system-x86_64 -icount shift=auto,rr=record,rrfile=ubuntu_shutdown.bin -drive file=ubuntu_snapshot.qcow2,if=none,id=img-direct -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device ide-hd,drive=img-blkreplay -loadvm loggedin -net none -m 2g` +4. Run `shutdown -h now` in guest +5. Wait (~5-10 mins) +6. Observe BMDMA error (see below) +Additional information: +``` +ata1.00: exeption Emask 0x0 SAct 0.0 SErr 0.0 action 0x6 +ata1.00: BMDMA stat 0x5 +ata1.00: failed command: READ DMA +ata1.00: cmd c8/xx:xx:xx:xx:xx/xx:xx:xx:xx:xx/xx tag - dma 4096 in + res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) +ata1.00: revalidation failed (errno=-2) +... +``` + +Note: Running the same command on a guest with a `virtio` disk results in further progress, but still does not shut down (stuck on `[ OK ] Stopped Create final runtime dir for shutdown pivot root.`) diff --git a/results/classifier/deepseek-2/output/device/2651 b/results/classifier/deepseek-2/output/device/2651 new file mode 100644 index 000000000..cf847b634 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2651 @@ -0,0 +1,9 @@ + +MPC5553/MPC5554 Emulation (information request) +Additional information: +If it is not planned, I'll most likely start educating myself on this project to try and patch it in as it's a need that is quite important for me. +I'll try not to waste your time and read as much as I can about your guidelines. +Would you advise me against trying to do this? +I'd like to know how hard you think this will be. + +DISCLAIMER : I am still very much a newbie in embedded systems, I'm only in the first year of my master's degree in embedded systems. diff --git a/results/classifier/deepseek-2/output/device/2655 b/results/classifier/deepseek-2/output/device/2655 new file mode 100644 index 000000000..cd9d010c1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2655 @@ -0,0 +1,40 @@ + +A problem in target/riscv/vector_helper.c: vext_ldff() +Description of problem: +I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c: +``` +static inline void +vext_ldff(...) +{ +... + for (i = env->vstart; i < env->vl; i++) { +... + if (i == 0) { + probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD); + } else { +... + flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD, + mmu_index, true, &host, 0); +... + if (flags & ~TLB_WATCHPOINT) { + vl = i; + goto ProbeSuccess; + } +... + } + } +ProbeSuccess: +... +} +``` +If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist. + +In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? + +This problem occurred in both linux-user mode and full-system mode. + +Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions. +Steps to reproduce: +1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests. +2. Write a plugin to add memory callbacks. +3. Observe the behavior of the function. diff --git a/results/classifier/deepseek-2/output/device/2656 b/results/classifier/deepseek-2/output/device/2656 new file mode 100644 index 000000000..df9a94cf4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2656 @@ -0,0 +1,2 @@ + +impossible to specify pauth-impdef=on when specifying multiple accelerators diff --git a/results/classifier/deepseek-2/output/device/2659 b/results/classifier/deepseek-2/output/device/2659 new file mode 100644 index 000000000..60e6b4e19 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2659 @@ -0,0 +1,2 @@ + +msys2-64bit test-aio intermittent CI failure with "test_timer_schedule: assertion failed: (aio_poll(ctx, true)) FAIL" diff --git a/results/classifier/deepseek-2/output/device/268 b/results/classifier/deepseek-2/output/device/268 new file mode 100644 index 000000000..799e8e95a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/268 @@ -0,0 +1,2 @@ + +arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N") diff --git a/results/classifier/deepseek-2/output/device/2689 b/results/classifier/deepseek-2/output/device/2689 new file mode 100644 index 000000000..9d84d5f70 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2689 @@ -0,0 +1,2 @@ + +arm64be tuxrun test is sometimes failing with I/O errors diff --git a/results/classifier/deepseek-2/output/device/2691 b/results/classifier/deepseek-2/output/device/2691 new file mode 100644 index 000000000..1e7a39b6d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2691 @@ -0,0 +1,28 @@ + +Renesas: test_rx_gdbsim.py test sometime timeouts +Description of problem: +```make check-functional``` runs sometime fail with : + +``` +160/164 qemu:func-thorough+func-rx-thorough+thorough / func-rx-rx_gdbsim TIMEOUT 90.03s killed by signal 15 SIGTERM +``` +Steps to reproduce: +1. ./configure --target-list=rx-softmmu +2. make -j 20 +3. while [ 1 ]; do PYTHONPATH=python:tests/functional QEMU_TEST_QEMU_BINARY=build/qemu-system-rx build/pyvenv/bin/python3 tests/functional/test_rx_gdbsim.py ; done + +It hangs after a few iterations. +Additional information: +The test console log file contains: + ``` +... +2024-11-19 11:03:04,123: Run /bin/sh as init process +2024-11-19 11:03:04,136: +2024-11-19 11:03:04,137: Sash command shell (version 1.1.1) +2024-11-19 11:03:04,137: +2024-11-19 11:03:04,145: />sh-sci 88240.serial: overrun error +2024-11-19 11:03:04,150: sh-sci 88240.serial: frame error +2024-11-19 11:03:04,156: sh-sci 88240.serial: parity error + ``` + +These errors appear to reflect some problems in the renesas_sci model. diff --git a/results/classifier/deepseek-2/output/device/2695 b/results/classifier/deepseek-2/output/device/2695 new file mode 100644 index 000000000..00d169469 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2695 @@ -0,0 +1,4 @@ + +how to onboard fw_cfg to other machines +Additional information: +Would it be doable for other machines actually? I didn't dig deeper into this device to understand, but I guess it is connected to the VM somehow and it has some memory mapped to the OS? diff --git a/results/classifier/deepseek-2/output/device/2702 b/results/classifier/deepseek-2/output/device/2702 new file mode 100644 index 000000000..21c006415 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2702 @@ -0,0 +1,54 @@ + +qtest-arm/sse-timer-test sometimes fails on s390x host +Description of problem: +The sse-timer-test sometimes fails on the s390x runner in Travis, see: + +https://app.travis-ci.com/github/huth/qemu/jobs/628508770#L6337 : + +``` +>>> G_TEST_DBUS_DAEMON=/home/travis/build/huth/qemu/tests/dbus-vmstate-daemon.sh MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 PYTHON=/home/travis/build/huth/qemu/build/pyvenv/bin/python3 MALLOC_PERTURB_=165 QTEST_QEMU_BINARY=./qemu-system-arm /home/travis/build/huth/qemu/build/tests/qtest/sse-timer-test --tap -k + +▶ 70/287 ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) ERROR + + 70/287 qemu:qtest+qtest-arm / qtest-arm/sse-timer-test ERROR 0.71s killed by signal 6 SIGABRT + +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― + +stderr: + +** + +ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) + +(test program exited with status code -6) + +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +https://app.travis-ci.com/github/huth/qemu/jobs/628373181#L6336 : + +``` +>>> G_TEST_DBUS_DAEMON=/home/travis/build/huth/qemu/tests/dbus-vmstate-daemon.sh PYTHON=/home/travis/build/huth/qemu/build/pyvenv/bin/python3 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 QTEST_QEMU_BINARY=./qemu-system-arm MALLOC_PERTURB_=250 MESON_TEST_ITERATION=1 /home/travis/build/huth/qemu/build/tests/qtest/sse-timer-test --tap -k + +▶ 70/287 ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) ERROR + + 70/287 qemu:qtest+qtest-arm / qtest-arm/sse-timer-test ERROR 0.95s killed by signal 6 SIGABRT + +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― + +stderr: + +** + +ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) + +(test program exited with status code -6) + +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` +Steps to reproduce: +1. Run the QEMU CI on Travis +Additional information: +It seems to be a new or intermittent problem, two weeks ago it was still working fine: + +https://app.travis-ci.com/github/huth/qemu/jobs/627999506#L6325 diff --git a/results/classifier/deepseek-2/output/device/2703 b/results/classifier/deepseek-2/output/device/2703 new file mode 100644 index 000000000..8e28cf7b0 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2703 @@ -0,0 +1,41 @@ + +ptimer period sporadically too long +Description of problem: +A ptimer in a custom device with a frequency of 10kHz is sporadically called after more than 100,000ns in virtual time have elapsed. + +With a icount shift of 4 or 5 this happens almost everytime before the linux guest can even finish booting. + +With a shift of 0 this happens very rarely, but it does occur from time to time. +Steps to reproduce: +1. setup a ptimer with a frequency of 10kHz and assert that the time passed between callbacks is exactly 100,000ns +2. run +3. wait for boom +Additional information: +``` +// Timer setup +ptimer_transaction_begin(state->timer); + +ptimer_set_freq(state->timer, 10000); +ptimer_run(state->timer, 0); + +ptimer_transaction_commit(state->timer); +``` +``` +// timer callback +int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); +static int64_t last = 0; +if (last > 0) +{ + if (now - last != 100000) + { + fprintf(stderr, "error tick %ld after %ld is incorrect: %ld\n", now, last, now - last); + assert(0); + } +} +last = now; +``` + +``` +error tick 47867503135 after 47867400000 is incorrect: 103135 +qemu-system-x86_64: ../...file.c:119: timer_callback: Assertion `0' failed. +``` diff --git a/results/classifier/deepseek-2/output/device/2705 b/results/classifier/deepseek-2/output/device/2705 new file mode 100644 index 000000000..5a0cf932e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2705 @@ -0,0 +1,18 @@ + +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/deepseek-2/output/device/2707 b/results/classifier/deepseek-2/output/device/2707 new file mode 100644 index 000000000..fd9950041 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2707 @@ -0,0 +1,11 @@ + +virtio-balloon crashes in a object assert when querying stats +Description of problem: +Fetch virtio-balloon stats will crash a QEMU crash with assert failures +Steps to reproduce: +1. ./qemu-system-x86_64 -device virtio-balloon,id=balloon -qmp qmp.sock +2. Connect to qmp.sock +3. Issue 'qom-get path=/machine/peripheral/balloon property=guest-stats' +4. QEMU go boom! +Additional information: +This is a regression caused by commit 0d2eeef77a33315187df8519491a900bde4a3d83, which failed to update `balloon_stat_names` with the new stats names, causing code to try to add a QDict entry with a NULL key. diff --git a/results/classifier/deepseek-2/output/device/2714 b/results/classifier/deepseek-2/output/device/2714 new file mode 100644 index 000000000..8d1cf46d6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2714 @@ -0,0 +1,8 @@ + +Potential memory leak in virtio-crytpto +Description of problem: +There is a potential memory leak while using virtio-crypto with vhost-user backend. + +The problem is due to misuse of error_setg in [backends/cryptodev-vhost-user.c#L284](https://gitlab.com/qemu-project/qemu/-/blob/master/backends/cryptodev-vhost-user.c#L284). After invoking error_setg(&local_error, ...), current procedure should not return without freeing err object pointed by local_error. + +The same problem occured in cryptodev-builtin, which has been discussed in #2283 and fixed in f6abce29cc4afa0445cb3b29a265a114ac9fa744. The same fixes should be applied to cryptodev-vhost-user. diff --git a/results/classifier/deepseek-2/output/device/2716 b/results/classifier/deepseek-2/output/device/2716 new file mode 100644 index 000000000..c4d96df8f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2716 @@ -0,0 +1,8 @@ + +migrate incoming with fd transfer issue +Steps to reproduce: +1. +2. +3. +Additional information: +# diff --git a/results/classifier/deepseek-2/output/device/272 b/results/classifier/deepseek-2/output/device/272 new file mode 100644 index 000000000..a022fdd51 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/272 @@ -0,0 +1,2 @@ + +QEMU: block/vvfat driver issues diff --git a/results/classifier/deepseek-2/output/device/2722 b/results/classifier/deepseek-2/output/device/2722 new file mode 100644 index 000000000..cdca55c21 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2722 @@ -0,0 +1,49 @@ + +TLB Invalidation time out on i915 SR-IOV passthrough +Description of problem: +Hello, + +I tried to use SR-IOV on i915 driver freshly available on the [LTS intel kernel](https://github.com/intel/linux-intel-lts) with this [kernel version ](https://github.com/intel/linux-intel-lts/tree/lts-v6.6.34-linux-240626T131354Z) for pci passthrough purpose. +After setting up SR-IOV (kernel compilation, kernel cmdline, vfio-pci driver attribution to the new pci..) + I've got my two new pci. + +``` +00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +DeviceName: Onboard IGD + +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: i915 + +00:02.1 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: vfio-pci + +00:02.2 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: vfio-pci +``` +I gave one of those pci to my VM with this qemu cmdline: +``` +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-passthrough,hv-vendor-id=IrisXE +... +-device vfio-pci-nohotplug,host=0000:00:02.1,id=hostdev0,bus=pci.4,addr=0x0 +``` +Sometimes it working properly when I start the qemu cmdline but most of the time I've got those kernel errors and a GPU hang: +``` + kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + .... + kernel Fence expiration time out i915-0000:00:02.0:renderThread22381:6e0! + kernel i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.13.1 + kernel i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 + kernel i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads + kernel i915 0000:00:02.0: [drm] GT0: GUC: submission enabled + kernel i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled + kernel [ 2730.991019] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dfbfff, in renderThread [22381] + kernel [ 2730.991084] i915 0000:00:02.0: [drm] renderThread22381 context reset due to GPU hang +``` +It mostly appears when Qemu is starting.. + +Any help would be appreciate, thanks a lot diff --git a/results/classifier/deepseek-2/output/device/273 b/results/classifier/deepseek-2/output/device/273 new file mode 100644 index 000000000..87e259188 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/273 @@ -0,0 +1,2 @@ + +xhci_find_stream: Assertion `streamid != 0' failed. diff --git a/results/classifier/deepseek-2/output/device/2732 b/results/classifier/deepseek-2/output/device/2732 new file mode 100644 index 000000000..1e08947ff --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2732 @@ -0,0 +1,40 @@ + +Segmentation fault with PCI GPU +Description of problem: +Upon attempting to launch the virtual machine, Qemu crashes with Segfault. The issue only occurs it's launched with a passthrough GPU with the vfio driver. It is an Nvidia RTX 3060 GPU. The VM boots fine without the GPU PCI device added. +Steps to reproduce: +1. Create a VM with the GPU PCI device added +2. Attempt to boot it +3. virt-manager will display: "libvirt.libvirtError: internal error: QEMU unexpectedly closed the monitor" +Additional information: +GDB backtrace: +``` +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +Downloading 116.51 K source file /usr/src/debug/qemu/build/../qemu-9.1.2/system/memory.c +memory_region_update_container_subregions () at ../qemu-9.1.2/system/memory.c:2616 +2616 QTAILQ_FOREACH(other, &mr->subregions, subregions_link) { +(gdb) bt +#0 memory_region_update_container_subregions () at ../qemu-9.1.2/system/memory.c:2616 +#1 memory_region_add_subregion_common () at ../qemu-9.1.2/system/memory.c:2640 +#2 0x0000555555ade66a in memory_region_add_subregion_overlap () at ../qemu-9.1.2/system/memory.c:2657 +#3 vfio_probe_nvidia_bar0_quirk () at ../qemu-9.1.2/hw/vfio/pci-quirks.c:966 +#4 vfio_bar_quirk_setup () at ../qemu-9.1.2/hw/vfio/pci-quirks.c:1259 +#5 0x0000555555ae8212 in vfio_realize () at ../qemu-9.1.2/hw/vfio/pci.c:3133 +#6 0x000055555586c3ab in pci_qdev_realize () at ../qemu-9.1.2/hw/pci/pci.c:2097 +#7 0x0000555555b924f3 in device_set_realized () at ../qemu-9.1.2/hw/core/qdev.c:510 +#8 0x0000555555b9c37f in property_set_bool () at ../qemu-9.1.2/qom/object.c:2354 +#9 0x0000555555b9a21a in object_property_set () at ../qemu-9.1.2/qom/object.c:1463 +#10 0x0000555555b9abbf in object_property_set_qobject () at ../qemu-9.1.2/qom/qom-qobject.c:28 +#11 object_property_set_bool () at ../qemu-9.1.2/qom/object.c:1533 +#12 0x000055555594dafb in qdev_device_add_from_qdict () at ../qemu-9.1.2/system/qdev-monitor.c:719 +#13 0x00005555559586f1 in qemu_create_cli_devices () at ../qemu-9.1.2/system/vl.c:2664 +#14 qmp_x_exit_preconfig () at ../qemu-9.1.2/system/vl.c:2721 +#15 0x0000555555962396 in qemu_init () at ../qemu-9.1.2/system/vl.c:3766 +#16 0x00005555556d2abd in main () at ../qemu-9.1.2/system/main.c:47 +``` + +dmesg: +``` +[ 4846.200960] qemu-system-x86[26518]: segfault at b8 ip 00006149e75a64e6 sp 00007fff4c85fbe0 error 4 in qemu-system-x86_64[5c24e6,6149e7155000+72c000] likely on CPU 4 (core 4, socket 0) +[ 4846.200968] Code: 2e 01 83 c0 01 89 05 0d cd 2e 01 48 8b 43 40 48 85 c0 74 16 ba 01 00 00 00 f0 0f c1 50 18 81 fa fe ff ff 7f 0f 87 c4 00 00 00 <49> 8b 84 24 b8 00 00 00 48 85 c0 74 55 8b 93 b0 00 00 00 eb 11 0f +``` diff --git a/results/classifier/deepseek-2/output/device/2733 b/results/classifier/deepseek-2/output/device/2733 new file mode 100644 index 000000000..c442c0d11 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2733 @@ -0,0 +1,13 @@ + +-machine raspi4b won't dump dtb +Description of problem: +the raspi4b machine won't dump tdb +Steps to reproduce: +``` +$ qemu-system-aarch64 -machine virt -machine dumpdtb=p.dmp +qemu-system-aarch64: info: dtb dumped to p.dmp. Exiting. +$ qemu-system-aarch64 -machine raspi4b -machine dumpdtb=p.dmp +``` +notice no dtb is dumped for the raspi4b machine +Additional information: +see also https://gitlab.com/qemu-project/qemu/-/issues/2729 diff --git a/results/classifier/deepseek-2/output/device/2734 b/results/classifier/deepseek-2/output/device/2734 new file mode 100644 index 000000000..c744c6099 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2734 @@ -0,0 +1,25 @@ + +many aarch64 machines exit with "fatal: Lockup: can't escalate 3 to HardFault" +Description of problem: +`-machine netduino2` and `-machine microbit` and many others dump core +Steps to reproduce: +``` +qemu-system-aarch64 -machine netduino2 +qemu-system-aarch64 -machine microbit +... +$ for x in microbit netduino2 b-l475e-iot01a emcraft-sf2 fby35-bmc lm3s6965evb lm3s811evb musca-a musca-b1 netduinoplus2 olimex-stm32-h405 stm32vldiscovery +do qemu-system-aarch64 -machine $x +done +``` +and all the `mps2-*` machines all result in +``` +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) + +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000 +XPSR=40000003 -Z-- A handler +FPSCR: 00000000 +Aborted (core dumped) +``` diff --git a/results/classifier/deepseek-2/output/device/2765 b/results/classifier/deepseek-2/output/device/2765 new file mode 100644 index 000000000..a6c26d69f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2765 @@ -0,0 +1,2 @@ + +InputMethodKit warnings on macOS Sequoia diff --git a/results/classifier/deepseek-2/output/device/2776 b/results/classifier/deepseek-2/output/device/2776 new file mode 100644 index 000000000..8e1dc3e66 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2776 @@ -0,0 +1,2 @@ + +OHCI: Incorrectly reports an overrun error diff --git a/results/classifier/deepseek-2/output/device/2777 b/results/classifier/deepseek-2/output/device/2777 new file mode 100644 index 000000000..d39ddb68e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2777 @@ -0,0 +1,60 @@ + +Assert failure in ahci-hd device +Description of problem: +Assert + +``` +qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed. +``` +can be triggered with some qtest commands. This was found by fuzzing. +Steps to reproduce: +Command: + +``` +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device ide-hd,drive=disk0 -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0x0 0x1 0x27 +write 0x1 0x1 0x80 +write 0x2 0x1 0x25 +write 0xe00003b8 0x1 0x02 +write 0xe0000398 0x1 0x01 +EOF +``` + +Results in + +``` +[I 0.000001] OPENED +[R +0.076075] outl 0xcf8 0x8000fa24 +[S +0.076165] OK +OK +[R +0.076198] outl 0xcfc 0xe0000000 +[S +0.076242] OK +OK +[R +0.076320] outl 0xcf8 0x8000fa04 +[S +0.076344] OK +OK +[R +0.076379] outw 0xcfc 0x06 +[S +0.077676] OK +OK +[R +0.077760] write 0x0 0x1 0x27 +[S +0.079429] OK +OK +[R +0.079552] write 0x1 0x1 0x80 +[S +0.079592] OK +OK +[R +0.079618] write 0x2 0x1 0x25 +[S +0.079645] OK +OK +[R +0.079669] write 0xe00003b8 0x1 0x02 +[S +0.079709] OK +OK +[R +0.079733] write 0xe0000398 0x1 0x01 +qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed. +Aborted +``` +Additional information: +Maybe we can just `goto eot;` instead of assert? diff --git a/results/classifier/deepseek-2/output/device/278 b/results/classifier/deepseek-2/output/device/278 new file mode 100644 index 000000000..541327844 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/278 @@ -0,0 +1,2 @@ + +jack audio dev produces no sound diff --git a/results/classifier/deepseek-2/output/device/2787 b/results/classifier/deepseek-2/output/device/2787 new file mode 100644 index 000000000..e151e5e4e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2787 @@ -0,0 +1,14 @@ + +Opentitan timer layout incorrect +Description of problem: +It looks as if some of the timer register offsets here are incorrect: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L37 + +Compare with: + +https://opentitan.org/book/hw/ip/rv_timer/doc/registers.html + +I suspect they're out of date. The documentation link on line 7 is not working anymore - the current documentation URL for Opentitan is the one just given. + +It might also make sense to rename this file `opentitan_timer.c`, instead of `ibex_timer.c`. The timer is an Opentitan hardware IP block, rather than a feature of the Ibex CPU. diff --git a/results/classifier/deepseek-2/output/device/2796 b/results/classifier/deepseek-2/output/device/2796 new file mode 100644 index 000000000..d3933b161 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2796 @@ -0,0 +1,8 @@ + +Opentitan Timer ignores COMPARE_UPPER0/COMPARE_LOWER0 +Description of problem: +In a bare metal application, running on an emulated Opentitan board, if you set a timer interrupt threshold by writing to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before writing to `rv_timer.CTRL` to start the timer, then the interrupt does not fire. If you write to the `COMPARE_*` registers *after* starting the timer by writing to `CTRL`, then the interrupt fires correctly. + +I think the explanation is that [ibex_timer_update_irqs](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L61) has an early return if `rv_timer.CTRL` is not set. As a result, although writes to `COMPARE_*` always call `ibex_timer_update_irqs`, they don't have their intended side-effects before `CTRL` is unset. +Steps to reproduce: +Write to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before you have set `rv_timer.CTRL`. Observe that no timer interrupt occurs. diff --git a/results/classifier/deepseek-2/output/device/2797 b/results/classifier/deepseek-2/output/device/2797 new file mode 100644 index 000000000..77c786460 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2797 @@ -0,0 +1,4 @@ + +arm/raspi.c - incease memory limit +Additional information: +I can attempt to make a PR that increases this limit, but not sure if others would find it useful. diff --git a/results/classifier/deepseek-2/output/device/2798 b/results/classifier/deepseek-2/output/device/2798 new file mode 100644 index 000000000..d1fac6710 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2798 @@ -0,0 +1,39 @@ + +Cannot disconnect Split VMDK +Description of problem: +I used to mount VDI with qemu-nbd and it worked, I could mount/unmount many times. Since VDI was 400 GB, I converted to Split2G VMDK. +In addition to file.vmdk, there are file-s001.vmdk, file-s002.vmdk..file-s201.vmdk +With that, I can mount, but disconnect does not work. Tried also with `blockdev`, did not help, not sure if that is needed. +I know that with LV deactivation of volume group is needed before disconnect. Not aware if there is equivalent with Split VMDK. +Cannot say if issue in qemu-nbd or qemu vmdk driver. +Experienced in qemu 6.2.0 and also when upgraded to 9.0.2. May try later with master that seems to build 9.2.50. +Steps to reproduce: +1. sudo modprobe nbd max_part=4 && sudo qemu-nbd -f vmdk -c /dev/nbd1 file.vmdk && sudo mount /dev/nbd1p1 /mnt/vmdk +2. sudo umount -l /mnt/vmdk && sleep 2 && sudo blockdev --flushbufs /dev/nbd1 && sleep 2 && sudo qemu-nbd -dv /dev/nbd1 +3. lsblk # see still nbd1 +Additional information: +``` +[ 424.020397] block nbd1: NBD_DISCONNECT +[ 424.020417] block nbd1: Disconnected due to user request. +[ 424.020420] block nbd1: shutting down sockets +[ 424.024278] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 +[ 424.024318] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 424.024327] Buffer I/O error on dev nbd1, logical block 105308592, async page read +[ 424.028202] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 +[ 424.028229] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 424.028233] Buffer I/O error on dev nbd1, logical block 0, async page read +[ 424.028249] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 424.028252] Buffer I/O error on dev nbd1, logical block 0, async page read +-- +[ 548.931610] block nbd1: NBD_DISCONNECT +[ 548.931620] block nbd1: Send disconnect failed -32 +[ 548.935594] blk_print_req_error: 6 callbacks suppressed +[ 548.935598] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 +[ 548.935634] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 548.935642] buffer_io_error: 2 callbacks suppressed +[ 548.935644] Buffer I/O error on dev nbd1, logical block 105308592, async page read +[ 548.940187] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 +[ 548.940211] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 548.940215] Buffer I/O error on dev nbd1, logical block 0, async page read +[ 548.940230] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +``` diff --git a/results/classifier/deepseek-2/output/device/2801 b/results/classifier/deepseek-2/output/device/2801 new file mode 100644 index 000000000..66739dec1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2801 @@ -0,0 +1,2 @@ + +Implement Raspberry PI Zero 2 W. diff --git a/results/classifier/deepseek-2/output/device/2805 b/results/classifier/deepseek-2/output/device/2805 new file mode 100644 index 000000000..4d15b9aa9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2805 @@ -0,0 +1,23 @@ + +vhost-device-snd does not report correctly the device conf size +Description of problem: +The vhost-user-snd frontend is incorrectly reporting the size of the device configuration space, which should be based on the features exposed by the device. For example, the `controls` field in the `virtio_snd_config` structure is optional and should only be included in the configuration size if the `VIRTIO_SND_F_CTLS` feature has been negotiated. + +This issue became apparent after commit `ab0c7fb2`, where `virtio_snd_config` was updated to include the `controls` field. The vhost-user-snd frontend, relying on this structure, started expecting `sizeof(virtio_snd_config)` when communicating with the backend, regardless of whether the `VIRTIO_SND_F_CTLS` feature was negotiated. As a result, any backend reporting a smaller configuration size—for example, one that does not support controls—cannot communicate with the frontend. We observed this problem in the vhost-device-sound rust-vmm device, which we partially fixed [here](https://github.com/rust-vmm/vhost-device/commit/8e7b7109316e1027548bc91cfcbb4b096b032c24). + +This behavior is incorrect because the configuration size should depend on the negotiated features. + +I am currently working on patch to fix this. +Steps to reproduce: +1. Run vhost-device-sound +```bash + cargo run --bin vhost-device-sound -- --socket=/tmp/vhost-sound.socket --backend=pipewire +``` +2. Run QEMU with the parameters above +3. In the guest run: +```bash +root@syzkaller:~# aplay /usr/share/sounds/alsa/Front_Left.wav +aplay: main:830: audio open error: No such file or directory +``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2826 b/results/classifier/deepseek-2/output/device/2826 new file mode 100644 index 000000000..e57cb4908 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2826 @@ -0,0 +1,10 @@ + +The host PCI bridge disappeared on the big endian MIPS Malta machine +Description of problem: +The tests/avocado/linux_ssh_mips_malta.py test currently fails for the big endian machines. It tries to check for the PCI host bridge with ``lspci -d 11ab:4620``, but that does not show the expected output anymore -- it looks like the host bridge cannot be correctly discovered by the guest Linux kernel anymore. +Steps to reproduce: +1. Get the kernel and disk image from https://people.debian.org/~aurel32/qemu/mips/ +2. Boot the guest as described above. +3. lspci -d 11ab:4620 +Additional information: +This used to work fine before commit 145e2198d749ec09a405f1607a9932499b76f1eb , so this rework likely introduced the bug. Looking at the code that got removed there, I could see an additional check ``phb->config_reg & 0x00fff800`` that is not present in the new code anymore, so the space for the host bridge itself likely should not get swapped. Reverting 3d85c7c15fc7ce986cf1a8e73da1217228f35685 and 145e2198d749ec09a405f1607a9932499b76f1eb seems to fix the problem (at least on little endian hosts). diff --git a/results/classifier/deepseek-2/output/device/2833 b/results/classifier/deepseek-2/output/device/2833 new file mode 100644 index 000000000..738c7f84f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2833 @@ -0,0 +1,20 @@ + +Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET +Description of problem: +In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says: +> Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field. +> +> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0. + + +> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values. + +In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows. + +The HPET should show that it works with more than just IRQ 2. +Steps to reproduce: +1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859 +2. `nix develop` +3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2843 b/results/classifier/deepseek-2/output/device/2843 new file mode 100644 index 000000000..34530f0a4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2843 @@ -0,0 +1,34 @@ + +Strange stdin/out <-> console issue (paste problem) . May be char-win-stdio.c bug. +Description of problem: +I was trying to execute QEMU with VM from command line(shell) and work inside a VM within that initial console. All goes well except... pasting from clipboard. Pastings from clipboard are truncated to somewhat less (no more) then a terminal width (in columns). + +I understand that it seems to be far from QEMU but I tried different terminals/shells/guest systems with the same result. The only things remain the same - QEMU. +Steps to reproduce: +In Windows open a console (shell). Run QEMU with guest serial attached to QEMU stdio. Try to paste some text. Pasted text will be truncated to 15-35 characters. Before QEMU run and after QEMU exit text pasted normally. +Additional information: +- Shell probed: **cmd**, **powershell** +- Terminals probed: **Windows Terminal**, **Alacritty**, **Wezterm**, **Windows Terminal Preview** +- Guest probed: **Alpine Linux**, **FreeBSD** +- Setting inside guest probed: various terminal speed/options via **stty** +- QEMU arguments probed: from **-nographics** to manually define **-chardev/-serial** with/without **-mon**. + +Finally I gave up. But want to mention that there are may be bug in source. When I tried to study source to find a hint for my issue I found that (char-win-stdio.c, line 162): +``` +is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0; + stdio->dwOldMode = dwMode; + + if (is_console) { +``` + +Documentation of **GetConsoleMode** function says: +``` +Return value: + +If the function succeeds, the return value is nonzero. +If the function fails, the return value is zero. +``` + +If understand correctly **is_console** will always be _true_. It will be _false_ only in case of invalid **stdio->hStdIn**. + +I don't how this is related to my issue just put here all info I have in hope of resolving. diff --git a/results/classifier/deepseek-2/output/device/2845 b/results/classifier/deepseek-2/output/device/2845 new file mode 100644 index 000000000..d3a69f831 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2845 @@ -0,0 +1,33 @@ + +memory leak in virtio-pci devices +Description of problem: +The Use-After-Free bug mentioned by #2440 **has not been solved**, but the same crash is not reproducable in the later versions. After reviewing the code, I found an initiailized address space `proxy->modern_cfg_mem_as` introduced by [`55fa4be`](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html "Inspect Commit Details") in `virtio_pci@hw/virtio/virtio-pci.c` will not be destroyed if the later realization is failed. +This will cause memory leak of the device object, which has unused reference and will not be destroyed. + +Relative Code in `virtio_pci_realize@virtio-pci.c`: + +```c +/* subclasses can enforce modern, so do this unconditionally */ +memory_region_init(&proxy->modern_bar, OBJECT(proxy), "virtio-pci", + /* PCI BAR regions must be powers of 2 */ + pow2ceil(proxy->notify.offset + proxy->notify.size)); + +address_space_init(&proxy->modern_cfg_mem_as, &proxy->modern_bar, + "virtio-pci-cfg-mem-as"); + +if (proxy->disable_legacy == ON_OFF_AUTO_AUTO) { + proxy->disable_legacy = pcie_port ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF; +} +``` +Steps to reproduce: +```bash +cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0 +device_add virtio-net,failover=on,bus=br1,id=dev0 +quit +EOF +``` + +**This will cause UAF report in version `9.0.2`, but will not in `9.2.0`,** despite the bug still existing in code. +Additional information: +For ASAN report, please refer to #2440. diff --git a/results/classifier/deepseek-2/output/device/2858 b/results/classifier/deepseek-2/output/device/2858 new file mode 100644 index 000000000..69a66ed8b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2858 @@ -0,0 +1,2 @@ + +QEMU Command Not Working diff --git a/results/classifier/deepseek-2/output/device/2861 b/results/classifier/deepseek-2/output/device/2861 new file mode 100644 index 000000000..db29d569c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2861 @@ -0,0 +1,8 @@ + +hw/pci-host/designware.c incorrect write to DESIGNWARE_PCIE_ATU_UPPER_TARGET register +Description of problem: +I think this is a obvious bug + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/designware.c?ref_type=heads#L374 + +Write to register DESIGNWARE_PCIE_ATU_UPPER_TARGET, val should be shifted left to update upper 32 bit part. diff --git a/results/classifier/deepseek-2/output/device/2863 b/results/classifier/deepseek-2/output/device/2863 new file mode 100644 index 000000000..fce71c26e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2863 @@ -0,0 +1,2 @@ + +Invalid read reason: rejected diff --git a/results/classifier/deepseek-2/output/device/2867 b/results/classifier/deepseek-2/output/device/2867 new file mode 100644 index 000000000..ae06cb5bb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2867 @@ -0,0 +1,14 @@ + +qemu:block / io-qcow2-161 fails non-deterministically +Description of problem: +The test suite failed non-deterministically with failure: +``` +729/838 qemu:block / io-qcow2-161 ERROR 2.08s exit status 1 +``` +Steps to reproduce: +1. guix time-machine --commit=d706c1b -- build qemu +2. or git clone, build and run `make check -j32 V=1` +Additional information: +[qemu-9.1.3-io-qcow2-041-failure-build-log.txt](/uploads/077f61d9dd1a26bcd351c0995009131c/qemu-9.1.3-io-qcow2-041-failure-build-log.txt) + +[testlog.txt](/uploads/0b0244a337f2175bdba9e258c778481d/testlog.txt) diff --git a/results/classifier/deepseek-2/output/device/2872 b/results/classifier/deepseek-2/output/device/2872 new file mode 100644 index 000000000..fb1e55bc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2872 @@ -0,0 +1,2 @@ + +hw/net: Parameter 'driver' expects a pluggable device type diff --git a/results/classifier/deepseek-2/output/device/2873 b/results/classifier/deepseek-2/output/device/2873 new file mode 100644 index 000000000..11a0256d5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2873 @@ -0,0 +1,10 @@ + +[chardev] In case of stdin redirection, SYS_READC semihost call will block in the chardev backend when EOF is reached. +Description of problem: +The previous command hangs, EOF is not detected. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2880 b/results/classifier/deepseek-2/output/device/2880 new file mode 100644 index 000000000..9bdb6dc3a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2880 @@ -0,0 +1,4 @@ + +how to migrate storage live for the vm with vhostuser disk +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/2889 b/results/classifier/deepseek-2/output/device/2889 new file mode 100644 index 000000000..8c3425d51 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2889 @@ -0,0 +1,23 @@ + +mouse does not work in pass in +Description of problem: +I have this script to start qemu that passes in my mouse, keyboard and xbox controler. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do work. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move. Here is the script: +Steps to reproduce: +1. run the script above with the right variables. +2. Move your mouse in the screen. It will not move the pointer. +Additional information: +I am using thees patches in qemu but it does not work in vanilla ether: +https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/ + +and this in the kernel (6.14.0): +https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83 + +I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0. + +I am runing mint on my host and arch on my guest. on my host I have virglrenderer on and on my guest I installed the pacman package lib32-vulkan-virtio and vulkan-virtio. + +If it helps I can remove the pass throws and insted use: + +-usbdevice tablet -usbdevice mouse -usbdevice keyboard +or +-device virtio-mouse -device virtio-keyboard -device virtio-tablet diff --git a/results/classifier/deepseek-2/output/device/2890 b/results/classifier/deepseek-2/output/device/2890 new file mode 100644 index 000000000..0cbe31efd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2890 @@ -0,0 +1,2 @@ + +RFE: Individual ON_SHUTDOWN diff --git a/results/classifier/deepseek-2/output/device/2911 b/results/classifier/deepseek-2/output/device/2911 new file mode 100644 index 000000000..5d53d5bbb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2911 @@ -0,0 +1,66 @@ + +G5/970 emulation not complete enough for OSX ? +Description of problem: +Leopard image that boots on G4 does not boot on G5 +Steps to reproduce: +1. Find preinstalled hdd image on Archive.org: MacOSLeopard.img +2. Try to boot it like above with -cpu 970, or 970FX +3. Observe early hang +Additional information: +``` +cpus[0] = 0x7f794b3e3040 0x7f794b3e5bc0 +cpus[1] = 0x7f794afe3ec0 0x7f794afe6a40 +Trying to write invalid spr 276 (0x114) at 00000000000b6634 +Trying to read invalid spr 277 (0x115) at 00000000000b6638 +Trying to read invalid spr 276 (0x114) at 00000000000b663c +Trying to write invalid spr 277 (0x115) at 00000000000b6658 +Trying to write invalid spr 276 (0x114) at 00000000000b665c +Trying to read invalid spr 276 (0x114) at 00000000000b6660 +Trying to write invalid spr 277 (0x115) at 00000000000b670c +Trying to write invalid spr 276 (0x114) at 00000000000b6710 +Trying to read invalid spr 276 (0x114) at 00000000000b6714 +invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000000 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008 + +last lin repeats infinitely. +``` + +from my email to qemu-ppc list: + +SPR 304 was already in target/ppc/cpu_init.c + +but sadly after adding those it still dies early :( + +I looked at + +IBM PowerPC 970FX RISC Microprocessor 11.6 SCOM Facility + +but whole thing a bit more complex than pair of regs. + +==== + +11.6.1 Processor Core SCOM SPR Access Each processor (core) has two special purpose registers (SPRs) used to access the SCOM interface: SCOMC and SCOMD. SCOMC and SCOMD are both 64-bit read/write SPRs and are used for SCOM Control and SCOM Data respectively. The interface is implemented as a direct connection to the parallel-to-serial converter, which handles the arbitration between the core and service processor. + +11.6.2 Operating System Protocol to Access SCOM SPRs In the PowerPC 970FX, SCOMC and SCOMD are complete operations. They do not require a software protocol in order to function properly except to disable external (asynchronous) interrupts. Software must check the error bits after performing an SCOMC to ensure that the command successfully completed. Table 11-14 Operating System Code to Access SCOM outlines a general software protocol for using these registers. + +==== + +Low level asm init for OSX XNU kernel seems to live at + +https://github.com/apple-oss-distributions/xnu/blob/xnu-1228/osfmk/ppc/start.s diff --git a/results/classifier/deepseek-2/output/device/2937 b/results/classifier/deepseek-2/output/device/2937 new file mode 100644 index 000000000..72696765e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2937 @@ -0,0 +1,2 @@ + +Request for Assistance: Properly Emulating USB Devices in QEMU for Custom USB Driver Testing diff --git a/results/classifier/deepseek-2/output/device/2939 b/results/classifier/deepseek-2/output/device/2939 new file mode 100644 index 000000000..a386877c7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2939 @@ -0,0 +1,2 @@ + +Add m68k board name called Macintosh llci diff --git a/results/classifier/deepseek-2/output/device/2945 b/results/classifier/deepseek-2/output/device/2945 new file mode 100644 index 000000000..bdb7378f2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2945 @@ -0,0 +1,30 @@ + +Commit da954d0e introduces a regression on sifive_unleashed when booting from SD card +Description of problem: +In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the sifive_unleashed target was failing to boot from SD card in our tests (we also test via SPI and this is fine). I have bisected the problem down to commit [da954d0e ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")](https://gitlab.com/qemu-project/qemu/-/commit/da954d0e32444f122a41c24948d4d1c718bf66d4). + +When running QEMU we see the following output in the failure case as the only output: +``` +U-Boot SPL 2025.07-rc1-00033-gad60d9792896 (May 01 2025 - 17:08:34 +0000) +Trying to boot from MMC1 +spl: mmc init failed with error: -110 +Error: -110 +SPL: failed to boot from all boot devices +# +Steps to reproduce: +1. wget -O - https://github.com/pengutronix/genimage/releases/download/v14/genimage-14.tar.xz | tar -C /tmp -xJ ; cd /tmp/genimage-14 +2. ./configure && make -j$(nproc) +3. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot +4. wget -O - https://github.com/riscv-software-src/opensbi/releases/download/v1.3.1/opensbi-1.3.1-rv-bin.tar.xz | tar -C /tmp -xJ +5. export OPENSBI=/tmp/opensbi-1.3.1-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin +6. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- sifive_unleashed_defconfig +7. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- -sj$(nproc) +8. mkdir -p root +9. cp /tmp/sifive_unleashed/spl/u-boot-spl.bin . +10. cp /tmp/sifive_unleashed/u-boot.itb . +11. rm -rf tmp +12. genimage --inputpath . --config board/sifive/unleashed/genimage_sdcard.cfg +13. cp images/sdcard.img /tmp/sifive_unleashed/ +14. qemu-system-riscv64 -smp 5 -m 8G -nographic -M sifive_u,msel=11 -bios /tmp/sifive_unleashed/spl/u-boot-spl.bin -drive file=/tmp/sifive_unleashed/sdcard.img,format=raw,if=sd +Additional information: +The genimage tool is required for making the disk images used here. If building everything here is too much, I can provide the U-Boot binaries needed here out of band. diff --git a/results/classifier/deepseek-2/output/device/2947 b/results/classifier/deepseek-2/output/device/2947 new file mode 100644 index 000000000..272da182b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2947 @@ -0,0 +1,11 @@ + +Tablet-like mouse under Linux guest even if no -device usb-tablet is specified +Description of problem: +Arch Linux guest has absolute mouse tracking even when there is `-nodefaults` and no -device usb-tablet is provided. The guest does not have qemu guest agent installed. This is the unwanted behavior. The expected behavior is that it has a separate mouse pointer under guest, like with Windows guest. +Steps to reproduce: +1. Install guest operating system +2. Install gnome metapackage and enable GDM +3. Reboot +4. GDM has absolute mouse tracking and the mouse gets captured automatically, without having to click on the window or pressing Ctrl+Alt+G +Additional information: +[journalctl](/uploads/356952b8e2454c98e76ad82b700c518e/journalctl) diff --git a/results/classifier/deepseek-2/output/device/2953 b/results/classifier/deepseek-2/output/device/2953 new file mode 100644 index 000000000..a010d6de5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2953 @@ -0,0 +1,67 @@ + +"DMAR: DRHD: handling fault status reg 2" with vfio on kernel 6.13.11-200.fc41.x86_64, works with 6.13.9-200.fc41.x86_64 +Description of problem: +Since kernel 6.13.11-200.fc41.x86_64, I cannot use VFIO to pass an NVIDIA GeForce GTX 1070 card to a Windows guest. The same setup works just fine in 6.13.9-200.fc41.x86_64. The issue symptoms are the same regardless if I use kernel command line arguments to isolate cpus or not. + +Symptoms: +- qemu logs show: +``` +2025-05-07T09:59:49.957891Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.1, no available reset mechanism. +2025-05-07T09:59:49.958444Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.0, no available reset mechanism. +2025-05-07T09:59:49.959119Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.1, no available reset mechanism. +2025-05-07T09:59:49.959635Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.0, no available reset mechanism. +``` +- in dmesg I see: +``` +kernel: DMAR: DRHD: handling fault status reg 2 +kernel: DMAR: [INTR-REMAP] Request device [36:00.0] fault index 0x50 [fault reason 0x22] Present field in the IRTE entry is clear +``` +- the VM hangs at boot (please see the notes below (*)). +Steps to reproduce: +Boot the same libvirt domain in kernel 6.13.9-200.fc41.x86_64 (works) and any other more recent kernel (>= 6.13.11-200.fc41.x86_64). +Additional information: +(*) Note that in a working kernel, the boot process is in any case finicky, and it shows these phases: +1. tianocore logo shows, and one single cpu is fully utilized by the guest +2. slowly, the loader find the Windows bootloader, and prints a message that it is loading and running it +3. some time passes, while cpus seem idle +4. finally the spinning wheel of the Windows bootloader appears + +Phase 1-3 can take anywhere from 0 to 60 seconds, in an apparently random manner. + +When running on the faulty kernels, it seems that the virtual machine gets stuck in phase 1, and I must use `virsh destroy` to interrupt it. + +lspci output: +``` +-[0000:00]-+-00.0 Intel Corporation Tiger Lake-UP3/H35 4 cores Host Bridge/DRAM Registers + +-02.0 Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] + +-04.0 Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant + +-06.0-[01]----00.0 Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 + +-07.0-[02-33]-- + +-0a.0 Intel Corporation Tigerlake Telemetry Aggregator Driver + +-0d.0 Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller + +-0d.2 Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 + +-14.0 Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller + +-14.2 Intel Corporation Tiger Lake-LP Shared SRAM + +-15.0 Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 + +-15.1 Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 + +-15.2 Intel Corporation Tiger Lake-LP Serial IO I2C Controller #2 + +-16.0 Intel Corporation Tiger Lake-LP Management Engine Interface + +-1c.0-[34]----00.0 Intel Corporation Wi-Fi 6 AX200 + +-1c.5-[35]----00.0 Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader + +-1d.0-[36]--+-00.0 NVIDIA Corporation GP104 [GeForce GTX 1070] + | \-00.1 NVIDIA Corporation GP104 High Definition Audio Controller + +-1f.0 Intel Corporation Tiger Lake-LP LPC Controller + +-1f.3 Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller + +-1f.4 Intel Corporation Tiger Lake-LP SMBus Controller + \-1f.5 Intel Corporation Tiger Lake-LP SPI Controller +``` + +kernel command line arguments (optimized with cpu isolation): +``` +intel_pstate=per_cpu_perf_limits rd.driver.blacklist=nouveau modprobe.blacklist=nouveau module_blacklist=nouveau default_hugepagesz=1G hugepagesz=1G hugepages=13 i2c_i801.disable_features=0x10 rd.driver.pre=vfio_pci,vfio,vfio_iommu_type1 vfio-pci.ids=10de:1b81,10de:10f0 modprobe.blacklist=xpad systemd.unit=multi-user.target systemd.wants=bluetooth.service isolcpus=domain,managed_irq,1-3,5-7 rcu_nocbs=1-3,5-7 irqaffinity=0,4 nospectre_v2 +``` + +kernel command line arguments (without cpu isolation, same symptoms): +``` +intel_pstate=per_cpu_perf_limits rd.driver.blacklist=nouveau modprobe.blacklist=nouveau module_blacklist=nouveau default_hugepagesz=1G hugepagesz=1G hugepages=13 rd.driver.pre=vfio_pci,vfio,vfio_iommu_type1 vfio-pci.ids=10de:1b81,10de:10f0 modprobe.blacklist=xpad systemd.unit=multi-user.target systemd.wants=bluetooth.service +``` diff --git a/results/classifier/deepseek-2/output/device/2954 b/results/classifier/deepseek-2/output/device/2954 new file mode 100644 index 000000000..3de2dbb88 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2954 @@ -0,0 +1,20 @@ + +SD card is not visible by UEFI +Description of problem: +SD card is not visible by OVMF UEFI, so it's not possible to boot from it: +``` +UEFI Interactive Shell v2.2 +EDK II +UEFI v2.70 (EDK II, 0x00010000) +Mapping table + BLK0: Alias(s): + PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0) +Press ESC in 1 seconds to skip startup.nsh or any other key to continue. +Shell> +``` +It is visible by SeaBIOS though, if we remove the OVMF part from the commandline: +``` +qemu-system-x86_64 -device sdhci-pci -drive if=none,file=Fedora-IoT-ostree-41-20241027.0.x86_64.iso,format=raw,id=MMC1 -device sd-card,drive=MMC1 +``` + +@philmd diff --git a/results/classifier/deepseek-2/output/device/2955 b/results/classifier/deepseek-2/output/device/2955 new file mode 100644 index 000000000..2444aa9bb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2955 @@ -0,0 +1,2 @@ + +Mellanox IRQs Still Showing In Host OS After Passthrough diff --git a/results/classifier/deepseek-2/output/device/2958 b/results/classifier/deepseek-2/output/device/2958 new file mode 100644 index 000000000..b693a1081 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2958 @@ -0,0 +1,19 @@ + +Vvfat crashes in WinXP-64 installation. +Description of problem: + +Steps to reproduce: +1. Download ISO (see above) +2. Set up qemu +3. Run command above + +Termux output: +qemu-system-x86_64: Slirp: Failed to send packet, ret: -1 [repeated] + +../block/vvfat.c:105: void *array_get(array_t *, unsigned int): assertion "index < array->next" failed +Aborted +~ $ +Additional information: +This was extremely annoying because the total abort occurs far into the installation, while setting up the network. The devices (presumably including the vvfat) had been installed OK. The XP installation can be restarted without the CD but starts at the beginning, needing location, passwords, licence key etc. all over again! I have XP64 installed now, without vvfat which is a marvellously convenient way of transferring files. + +BTW "vfat" usually means extended FAT, handling files over 4GB but vvfat does not. Can you fix that? diff --git a/results/classifier/deepseek-2/output/device/2961 b/results/classifier/deepseek-2/output/device/2961 new file mode 100644 index 000000000..2a7759782 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2961 @@ -0,0 +1,32 @@ + +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/deepseek-2/output/device/2963 b/results/classifier/deepseek-2/output/device/2963 new file mode 100644 index 000000000..b62bbb500 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2963 @@ -0,0 +1,25 @@ + +QEMU crash with `qemu_mutex_unlock_impl: Operation not permitted` during block device operations +Description of problem: +We got a crash when I use a blockdev-add command while a blockdev-backup operation was nearly complete. The crash does not reproduce consistently. + +This message was printed in the QEMU debug log. +`qemu: qemu_mutex_unlock_impl: Operation not permitted` + +We also collected a coredump at the time of the crash. but, when analyzing the coredump using gdb, the call stack only shows ?? for all frames, making it difficult to diagnose the root cause. + +so I have two main questions: + +1. Under what circumstances does `qemu_mutex_unlock_impl: Operation not permitted` occur? +Is there any known cause or workaround for this kind of crash? + +2. What should be done to ensure that the call stack in a coredump is visible? +Are there specific build flags or debug symbol requirements we should be aware of? +We built QEMU with --enable-debug, but the call stack still shows only ?? in gdb when analyzing the core dump. +Steps to reproduce: +1. Start a VM with block devices configured. +2. Begin a blockdev-backup operation. +3. Near the completion of the blockdev-backup, issue a blockdev-add command for another device. +4. Observe a crash. (The crash does not reproduce consistently) +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/297 b/results/classifier/deepseek-2/output/device/297 new file mode 100644 index 000000000..5db334c1b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/297 @@ -0,0 +1,2 @@ + +SD card size constraint conceptually wrong diff --git a/results/classifier/deepseek-2/output/device/2985 b/results/classifier/deepseek-2/output/device/2985 new file mode 100644 index 000000000..94f855b1a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/2985 @@ -0,0 +1,9 @@ + +throttle group limit feature request for discard +Additional information: +- Need to add particular options in [ThrottleGroupProperties](https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html#object-QMP-block-core.ThrottleGroupProperties) which like this +```txt +x-discard-iops-total +x-discard-iops-total-max +.... +``` diff --git a/results/classifier/deepseek-2/output/device/305 b/results/classifier/deepseek-2/output/device/305 new file mode 100644 index 000000000..cb6c2fe63 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/305 @@ -0,0 +1,2 @@ + +assertion failure in lsi53c810 emulator diff --git a/results/classifier/deepseek-2/output/device/307 b/results/classifier/deepseek-2/output/device/307 new file mode 100644 index 000000000..f579fdc4a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/307 @@ -0,0 +1,2 @@ + +qemu may freeze during drive-mirroring on fragmented FS diff --git a/results/classifier/deepseek-2/output/device/317 b/results/classifier/deepseek-2/output/device/317 new file mode 100644 index 000000000..de35fc7ba --- /dev/null +++ b/results/classifier/deepseek-2/output/device/317 @@ -0,0 +1,2 @@ + +synchronous abort on accessing unused I/O ports on aarch64 diff --git a/results/classifier/deepseek-2/output/device/320 b/results/classifier/deepseek-2/output/device/320 new file mode 100644 index 000000000..bad639ff5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/320 @@ -0,0 +1,2 @@ + +Corsair iCUE Install Fails, qemu VM Reboots diff --git a/results/classifier/deepseek-2/output/device/322 b/results/classifier/deepseek-2/output/device/322 new file mode 100644 index 000000000..713f35a1f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/322 @@ -0,0 +1,2 @@ + +Can't(?) disable default floppy drive any more in qemu 6.0 diff --git a/results/classifier/deepseek-2/output/device/327 b/results/classifier/deepseek-2/output/device/327 new file mode 100644 index 000000000..dec95417e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/327 @@ -0,0 +1,2 @@ + +Storage | Two decimal digits precision diff --git a/results/classifier/deepseek-2/output/device/332 b/results/classifier/deepseek-2/output/device/332 new file mode 100644 index 000000000..2d4daa811 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/332 @@ -0,0 +1,2 @@ + +VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash diff --git a/results/classifier/deepseek-2/output/device/341 b/results/classifier/deepseek-2/output/device/341 new file mode 100644 index 000000000..48906eb1b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/341 @@ -0,0 +1,2 @@ + +Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer diff --git a/results/classifier/deepseek-2/output/device/346 b/results/classifier/deepseek-2/output/device/346 new file mode 100644 index 000000000..1a80dcbd5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/346 @@ -0,0 +1,2 @@ + +Guest refuses to accept keyboard input when accelerated with WHPX diff --git a/results/classifier/deepseek-2/output/device/350 b/results/classifier/deepseek-2/output/device/350 new file mode 100644 index 000000000..32cc923e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/350 @@ -0,0 +1,2 @@ + +lsisas1068 not supported (for VMDK manipulation) diff --git a/results/classifier/deepseek-2/output/device/360 b/results/classifier/deepseek-2/output/device/360 new file mode 100644 index 000000000..eb4719bf9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/360 @@ -0,0 +1,2 @@ + +load_helper() do_unaligned_access path doesn't return correct result with MMIO diff --git a/results/classifier/deepseek-2/output/device/383 b/results/classifier/deepseek-2/output/device/383 new file mode 100644 index 000000000..5b2dd9e41 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/383 @@ -0,0 +1,2 @@ + +virtio-gpu: heap-buffer-overflow in virtio_gpu_disable_scanout diff --git a/results/classifier/deepseek-2/output/device/386 b/results/classifier/deepseek-2/output/device/386 new file mode 100644 index 000000000..902afece8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/386 @@ -0,0 +1,2 @@ + +raspi0 machine has incorrect memory mapping for devices diff --git a/results/classifier/deepseek-2/output/device/388 b/results/classifier/deepseek-2/output/device/388 new file mode 100644 index 000000000..b983d3dfa --- /dev/null +++ b/results/classifier/deepseek-2/output/device/388 @@ -0,0 +1,2 @@ + +Can not pass hw device names as alsa input and output devices diff --git a/results/classifier/deepseek-2/output/device/391 b/results/classifier/deepseek-2/output/device/391 new file mode 100644 index 000000000..32fc4fc86 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/391 @@ -0,0 +1,2 @@ + +Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest diff --git a/results/classifier/deepseek-2/output/device/392 b/results/classifier/deepseek-2/output/device/392 new file mode 100644 index 000000000..27797eaa5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/392 @@ -0,0 +1,2 @@ + +`-hda` and `-drive` differ with respect to path handling diff --git a/results/classifier/deepseek-2/output/device/399 b/results/classifier/deepseek-2/output/device/399 new file mode 100644 index 000000000..6556b74ec --- /dev/null +++ b/results/classifier/deepseek-2/output/device/399 @@ -0,0 +1,2 @@ + +drive-backup job hangs in a 'paused' state after unsuccessful first attempt diff --git a/results/classifier/deepseek-2/output/device/401 b/results/classifier/deepseek-2/output/device/401 new file mode 100644 index 000000000..47c6366c5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/401 @@ -0,0 +1,2 @@ + +Wishlist: nvme-ns: allow specifying eui-64 diff --git a/results/classifier/deepseek-2/output/device/403 b/results/classifier/deepseek-2/output/device/403 new file mode 100644 index 000000000..db4f31f80 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/403 @@ -0,0 +1,2 @@ + +MTE false positives for unaligned accesses diff --git a/results/classifier/deepseek-2/output/device/406 b/results/classifier/deepseek-2/output/device/406 new file mode 100644 index 000000000..0e08895fe --- /dev/null +++ b/results/classifier/deepseek-2/output/device/406 @@ -0,0 +1,2 @@ + +vhost-user net device sends SET_VRING_ENABLE before feature negotiation diff --git a/results/classifier/deepseek-2/output/device/411 b/results/classifier/deepseek-2/output/device/411 new file mode 100644 index 000000000..ec2411e42 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/411 @@ -0,0 +1,2 @@ + +Abort when runs into unsupported AUXCommand in xlnx_dp_aux_set_command diff --git a/results/classifier/deepseek-2/output/device/413 b/results/classifier/deepseek-2/output/device/413 new file mode 100644 index 000000000..1e60a7b7b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/413 @@ -0,0 +1,2 @@ + +Error handling: Audit callers of load_image_targphys, get_image_size, event_notifier_init, msix_init diff --git a/results/classifier/deepseek-2/output/device/421 b/results/classifier/deepseek-2/output/device/421 new file mode 100644 index 000000000..c9f9f00a6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/421 @@ -0,0 +1,2 @@ + +Please clarify what network card is available with qemu-system-sparc64 diff --git a/results/classifier/deepseek-2/output/device/424450 b/results/classifier/deepseek-2/output/device/424450 new file mode 100644 index 000000000..4b650fe92 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/424450 @@ -0,0 +1,15 @@ + +FDC reset should reset the MSR + +I believe that the MSR resgister should also be reset to zero on a software reset. All of the FDC hardware I have does this. +The current code leaves the MSR as 0x80, which means that the controller is ready for a write. The controller should not +be ready for a write while in reset. + +fdc.c Line 899 + /* Reset */ + if (!(value & FD_DOR_nRESET)) { + + fdctrl->msr = 0x00; + if (fdctrl->dor & FD_DOR_nRESET) { + FLOPPY_DPRINTF("controller enter RESET state\n"); + } + } else { \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/433 b/results/classifier/deepseek-2/output/device/433 new file mode 100644 index 000000000..508f60099 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/433 @@ -0,0 +1,2 @@ + +chardev: Windows stdio eats characters diff --git a/results/classifier/deepseek-2/output/device/437 b/results/classifier/deepseek-2/output/device/437 new file mode 100644 index 000000000..9ca6e7902 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/437 @@ -0,0 +1,2 @@ + +[AHCI] crash when running a GNU/Hurd guest diff --git a/results/classifier/deepseek-2/output/device/450 b/results/classifier/deepseek-2/output/device/450 new file mode 100644 index 000000000..a2467243b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/450 @@ -0,0 +1,2 @@ + +sdhci: Assertion wpnum < sd->wpgrps_size failed diff --git a/results/classifier/deepseek-2/output/device/451 b/results/classifier/deepseek-2/output/device/451 new file mode 100644 index 000000000..7f2f5ec1d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/451 @@ -0,0 +1,2 @@ + +sdhci: Heap-buffer-overflow in sdhci_read_dataport diff --git a/results/classifier/deepseek-2/output/device/455 b/results/classifier/deepseek-2/output/device/455 new file mode 100644 index 000000000..8ae320c4e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/455 @@ -0,0 +1,35 @@ + +Pressing special keys (specially ctrl) sticks the key or makes it repeat the next key until ESC or Ctrl is pressed. +Description of problem: +Well, I'm using it in a daily basis, since it is my VM to isolate the environment for work. + +It was compiled from source for _jack_ support, the only thing that I cared about. I'll be honest : I don't remember the special parameters, nothing unusual though. I'm not in the need for _rt_ kernels. + +When I press `Ctrl` and sometimes when I press other special keys, one of the three options occur : +1. It repeats all the keys pressed next, like if I was pressing it for a long time. + - Example : `a` turns into `aaaaaaaaaaaaaaa...`(continues) + - It repeats until I press `Esc` or `Ctrl` again. +1. `Ctrl` continues as pressed and everything I type occurs with `Ctrl`. + - Example : `a` turns into `Ctrl-A` + - Probably caused by the previous option. +1. It does what is expected, like `Ctrl-C` +Steps to reproduce: +1. Run the specified config. +1. Test `Ctrl-C` + `Ctrl-V` using text editors. + - I think that using a graphical one is faster to see it happening. + - Examples + - Atom + - Eclipse + - Kate + - VsCode + - It also occurred using a _pty_ but since I generally use the _middle-mouse-button_ with _ptys_. + - I'm not aware of the frequency that it happens. + - It also occurs with the mouse (`Ctrl-mouseclick`). + - For example: instead of going to a _Firefox_'s tab, it selects it. + +I don't know any other step here, the use case is trivial coding. +Additional information: +- I have already tried to disable "keyboard repeat" in config. + - At first it seems to work but the `Ctrl` key can get stuck like in the description and then I'm unable to get out of it (everything is sent as if it was with `Ctrl`) without pressing `Ctrl`+`ESC`. I have no idea of why. + - The problem seems to occur less frequently. +- It also happened before setting up `qemu-guest-agent`. diff --git a/results/classifier/deepseek-2/output/device/461 b/results/classifier/deepseek-2/output/device/461 new file mode 100644 index 000000000..70f9afd5b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/461 @@ -0,0 +1,2 @@ + +What's your plan of Raspberry 3/3B/4B diff --git a/results/classifier/deepseek-2/output/device/462 b/results/classifier/deepseek-2/output/device/462 new file mode 100644 index 000000000..15f21b1bd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/462 @@ -0,0 +1,44 @@ + +mirror: the block-job-cancel command can put qemu to the endless error loop +Description of problem: +If the destination VM will crash (or network is down) right before the completion of the block device mirroring job (`block-job-cancel`), then there will be a possibility to put QEMU in the error loop. +Steps to reproduce: +1. Run both QEMU VMs: source + target. +2. On the target side prepare NBD server for blockdev mirroring process by using QMP commands similar to the one below: +``` +{"execute": "nbd-server-start", "arguments": { "addr": { "data": { "host": "::", "port": "49153" }, "type": "inet" } } } +{ "execute": "nbd-server-add", "arguments": { "device": "drive_main01", "writable": true } } +``` +3. On the source side, prepare VM for the migration and start driver mirror job: +``` +{"execute":"migrate-set-capabilities","arguments":{"capabilities":[{"capability":"pause-before-switchover","state":true}]}} +{ "execute": "drive-mirror", "arguments": { "device": "drive_main01", "mode": "existing", "job-id": "job0", "target": "nbd:127.0.0.1:49153:exportname=drive_main01", "sync": "top", "on-source-error": "stop", "on-target-error": "stop", "format": "raw", "speed": 0 } } +``` +4. On the source side wait for the `BLOCK_JOB_READY` event: +``` +{"timestamp": {"seconds": 1625586327, "microseconds": 833805}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 21474836480, "offset": 21474836480, "speed": 0, "type": "mirror"}} +``` +5. Start migration on the source side: +``` +{ "execute": "migrate", "arguments": { "uri": "tcp:127.0.0.1:8091" } } +``` +6. Wait for the `pre-switchover` state of the migration: +``` +{ "execute": "query-migrate" } +{"return": {"expected-downtime": 300, "status": "pre-switchover", "setup-time": 3, "total-time": 11343, "ram": {"total": 8725020672, "postcopy-requests": 0, "dirty-sync-count": 2, "multifd-bytes": 0, "pages-per-second": 39550, "page-size": 4096, "remaining": 2871296, "mbps": 1073.7734399999999, "transferred": 963647065, "duplicate": 1899491, "dirty-pages-rate": 84, "skipped": 0, "normal-bytes": 944705536, "normal": 230641}}} +``` +7. Kill target QEMU to reproduce an issue. +8. Cancel the job on the source side: +``` +{ "execute": "block-job-cancel", "arguments": { "device": "job0" } } +``` + +Got the endless errror loop: +``` +... +{"timestamp": {"seconds": 1625586487, "microseconds": 413847}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413865}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413885}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +... +``` +Source qemu could be stopped only by using SIGKILL. diff --git a/results/classifier/deepseek-2/output/device/464 b/results/classifier/deepseek-2/output/device/464 new file mode 100644 index 000000000..683788ede --- /dev/null +++ b/results/classifier/deepseek-2/output/device/464 @@ -0,0 +1,2 @@ + +The virtio disk shows offline when try to install windows version v6.0.5 diff --git a/results/classifier/deepseek-2/output/device/469 b/results/classifier/deepseek-2/output/device/469 new file mode 100644 index 000000000..235d1ebca --- /dev/null +++ b/results/classifier/deepseek-2/output/device/469 @@ -0,0 +1,2 @@ + +SB16 audio playback freezes emulation in Windows 95 guest diff --git a/results/classifier/deepseek-2/output/device/471 b/results/classifier/deepseek-2/output/device/471 new file mode 100644 index 000000000..33dea7ec2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/471 @@ -0,0 +1,65 @@ + +Clipboard sharing with `qemu_vdagent` does not work with SDL backend +Description of problem: +Clipboard sharing doesn't work: qemu does not send clipboard-grab messages when selecting on the host, nor does it respond to clipboard-grab messages from the guest. +Steps to reproduce: +1. Start QEMU with `qemu_vdagent` and `-display sdl` +2. Try to copy on the host or the guest +3. Observe that the clipboard is not shared +Additional information: +It appears as though `vdagent_clipboard_notify` function is not called. + +Logs: + +With SDL: +``` +vdagent_open +vdagent_recv_chunk size 28 +vdagent_recv_msg msg announce-capabilities, size 8 +vdagent_peer_cap cap mouse-state +vdagent_peer_cap cap monitors-config +vdagent_peer_cap cap reply +vdagent_peer_cap cap clipboard-by-demand +vdagent_peer_cap cap clipboard-selection +vdagent_peer_cap cap sparse-monitors-config +vdagent_peer_cap cap guest-lineend-lf +vdagent_peer_cap cap max-clipboard +vdagent_peer_cap cap audio-volume-sync +vdagent_send msg announce-capabilities +# tried to copy on host -- nothing happens here. +# trying to copy on guest: +vdagent_recv_chunk size 28 +vdagent_recv_msg msg clipboard-grab, size 8 +vdagent_cb_grab_selection selection clipboard +vdagent_cb_grab_type type text +# no response sent +``` +With GTK: +``` +vdagent_open +vdagent_recv_chunk size 28 +vdagent_recv_msg msg announce-capabilities, size 8 +vdagent_peer_cap cap mouse-state +vdagent_peer_cap cap monitors-config +vdagent_peer_cap cap reply +vdagent_peer_cap cap clipboard-by-demand +vdagent_peer_cap cap clipboard-selection +vdagent_peer_cap cap sparse-monitors-config +vdagent_peer_cap cap guest-lineend-lf +vdagent_peer_cap cap max-clipboard +vdagent_peer_cap cap audio-volume-sync +vdagent_send msg announce-capabilities +# trying to copy on host: +vdagent_send msg clipboard-grab +vdagent_recv_chunk size 28 +vdagent_recv_msg msg clipboard-request, size 8 +vdagent_send msg clipboard +vdagent_recv_chunk size 28 +# trying to copy on guest: +vdagent_recv_msg msg clipboard-grab, size 8 +vdagent_cb_grab_selection selection clipboard +vdagent_cb_grab_type type text +vdagent_send msg clipboard-request +vdagent_recv_chunk size 29 +vdagent_recv_msg msg clipboard, size 9 +``` diff --git a/results/classifier/deepseek-2/output/device/472 b/results/classifier/deepseek-2/output/device/472 new file mode 100644 index 000000000..e23af16ff --- /dev/null +++ b/results/classifier/deepseek-2/output/device/472 @@ -0,0 +1,2 @@ + +Device trees should specify `clock-frequency` property for `/cpus/cpu*` nodes diff --git a/results/classifier/deepseek-2/output/device/484 b/results/classifier/deepseek-2/output/device/484 new file mode 100644 index 000000000..dd59c4960 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/484 @@ -0,0 +1,2 @@ + +6.1 Regression: machine pflash parsing diff --git a/results/classifier/deepseek-2/output/device/485 b/results/classifier/deepseek-2/output/device/485 new file mode 100644 index 000000000..d55466553 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/485 @@ -0,0 +1,2 @@ + +Failed to restore domain - error load load virtio-balloon:virtio diff --git a/results/classifier/deepseek-2/output/device/486 b/results/classifier/deepseek-2/output/device/486 new file mode 100644 index 000000000..91698c087 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/486 @@ -0,0 +1,2 @@ + +/dev/input/mouse0: is not an evdev device diff --git a/results/classifier/deepseek-2/output/device/487 b/results/classifier/deepseek-2/output/device/487 new file mode 100644 index 000000000..af52b25f7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/487 @@ -0,0 +1,2 @@ + +sdhci: out of bounds read on sd->sd_status diff --git a/results/classifier/deepseek-2/output/device/488 b/results/classifier/deepseek-2/output/device/488 new file mode 100644 index 000000000..30fb397c4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/488 @@ -0,0 +1,31 @@ + +[git]Virt-Manager cannot start any previously created virtual machine with Qemu commit bd306cfe: 'spicevmc' is not a valid char driver name +Description of problem: +With qemu built on commit bd306cfe, I'm unable to start a previously created VM. + +Because of both bug #463 and #474 I was blocked from building qemu from git for something like a week or so. My last built and working Qemu is based on commit 9bef7ea9d9. + +Doing a git bissect won't be an easy task :( +Steps to reproduce: +1. Build qemu using commit bd306cfe +2. Launch Virt-Manager +3. Try to launch a previously created VM or try to boot a new one. +Additional information: +Every single time I tried to launch a VM, I get a dialog box with this error message: + +``` +Error starting domain: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name +``` diff --git a/results/classifier/deepseek-2/output/device/492 b/results/classifier/deepseek-2/output/device/492 new file mode 100644 index 000000000..44bfceaab --- /dev/null +++ b/results/classifier/deepseek-2/output/device/492 @@ -0,0 +1,28 @@ + +[git] "qemu-system-x86_64: Parameter 'drive' is missing" when I tried to launch an existing VM in Virt-Manager. +Description of problem: +This bug is related in some way to bug #488. + +I cannot start an existing virtual machine using qemu-git. +Additional information: +``` +internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing + +``` + +My last working build was made using commit 9bef7ea9. Using Peter Maydell commits as milestone, I noticed commit 9aef0954 was the first showing the bug. + +I'll try to do bisect between these two commits and report asap. There is about 40 commits to verify. diff --git a/results/classifier/deepseek-2/output/device/493 b/results/classifier/deepseek-2/output/device/493 new file mode 100644 index 000000000..3d15113cb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/493 @@ -0,0 +1,8 @@ + +RISC-V: Setting mtimecmp to -1 immediately triggers an interrupt +Description of problem: +When setting mtimecmp to -1, which should set a timer infinitely far in the future, a timer interrupt is triggered immediately. This happens for most values over 2^61. It is the same for both 32-bit and 64-bit, and for M-mode writing to mtimecmp directly and S-mode using OpenSBI. + +I have looked through the source code, and the problem is in the function `sifive_clint_write_mtimecmp`, in the file `/hw/intc/sifive_clint.c`. First, the muldiv64 multiplies diff with 100, causing an overflow (at least for -M virt, other machines might use a different timebase_freq). Then, the unsigned `next` is passed to `timer_mod`, which takes a signed integer. In `timer_mod_ns_locked` the value is set to `MAX(next, 0)`, which means that if the MSB of `next` was set, the interrupt happens immediately. This means that it is impossible to set timers more than 2^63 nanoseconds in the future. + +This problem basically only affects programs which disable timer interrupts by setting the next one infinitely far in the future. However, the SBI doc specifically says that this is a valid approach, so it should be supported. Using the MSB doesn't work without changing code functionality in QEMU, but it should be sufficient to cap `next` at the maximum signed value. diff --git a/results/classifier/deepseek-2/output/device/498417 b/results/classifier/deepseek-2/output/device/498417 new file mode 100644 index 000000000..586c5db61 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/498417 @@ -0,0 +1,15 @@ + +cache=writeback on disk image doesn't do write-back + +I noticed that qemu seems to have poor disk performance. Here's a test that has miserable performance but which should be really fast: + +- Configure qemu to use the disk image with cache=writeback +- Configure a 2GiB Linux VM on an 8GiB Linux host +- In the VM, write a 4GiB file (dd if=/dev/zero of=/tmp/x bs=4K count=1M) +- In the VM, read it back (dd if=/tmp/x of=/dev/null bs=4K count=1M) + +With writeback, the whole file should end up in the host pagecache. So when I read it back, there should be no I/O to the real disk, and it should be really fast. Instead, I see disk activity through the duration of the test, and the performance is roughly the native hard disk throughput (somewhat slower). + +I'm using version 0.11.1, and this is my command line: + +qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -enable-kvm & \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/51 b/results/classifier/deepseek-2/output/device/51 new file mode 100644 index 000000000..4e8d87b4b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/51 @@ -0,0 +1,2 @@ + +Linux kernel oops on Malta board while accessing pflash diff --git a/results/classifier/deepseek-2/output/device/510 b/results/classifier/deepseek-2/output/device/510 new file mode 100644 index 000000000..13f5f6e3a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/510 @@ -0,0 +1,2 @@ + +QEMU registers support on x64 diff --git a/results/classifier/deepseek-2/output/device/511 b/results/classifier/deepseek-2/output/device/511 new file mode 100644 index 000000000..28a2b44c3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/511 @@ -0,0 +1,2 @@ + +usbredirparser: bulk transfer length exceeds limits (can't use any USB storage) diff --git a/results/classifier/deepseek-2/output/device/521 b/results/classifier/deepseek-2/output/device/521 new file mode 100644 index 000000000..965c7379b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/521 @@ -0,0 +1,2 @@ + +Assert mr != NULL through megaraid diff --git a/results/classifier/deepseek-2/output/device/526 b/results/classifier/deepseek-2/output/device/526 new file mode 100644 index 000000000..2ddfc4998 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/526 @@ -0,0 +1,16 @@ + +MacBook German Keyboard <> and ^° Key not working +Description of problem: +Using a German keyboard on my 2018 MacBook Pro I can't type the <> Key or the ^ Key. +When pressing the <> Key it gets interpreted as the ^ Key, the ^ Key is dead. + +Problem is not caused by the guest system, Ubuntu VMs also can't type <>. (Ubuntu VMs ran inside UTM, which internally uses QEMU. https://mac.getutm.app/ ) + +VirtualBox maps the <> Key and ^ Key correctly. +Steps to reproduce: +0. Use a MacBook with a German Keyboard +1. Install TempleOS +2. Install German Keyboard Layout from https://github.com/Rion96/GKey (mount the ISO as a CD Drive) +3. Every key works except for <> and ^. +Additional information: +Doing the same steps in VirtualBox results in <> and ^ working, so it must be a QEMU error. diff --git a/results/classifier/deepseek-2/output/device/529 b/results/classifier/deepseek-2/output/device/529 new file mode 100644 index 000000000..8dd11faae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/529 @@ -0,0 +1,5 @@ + +qemu-system-riscv64 hard lockup on non-stdio serial output +Additional information: +u-boot pre-compiled firmware: (directory contains all git revisions, build flags, etc) +https://github.com/haiku/firmware/tree/master/u-boot/riscv64/qemu diff --git a/results/classifier/deepseek-2/output/device/531 b/results/classifier/deepseek-2/output/device/531 new file mode 100644 index 000000000..78b866323 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/531 @@ -0,0 +1,2 @@ + +Replace DMA processing in I/O handlers by asynchronous BH diff --git a/results/classifier/deepseek-2/output/device/536 b/results/classifier/deepseek-2/output/device/536 new file mode 100644 index 000000000..fe8c81e6a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/536 @@ -0,0 +1,2 @@ + +Null-ptr dereference in ich9_apm_ctrl_changed diff --git a/results/classifier/deepseek-2/output/device/54 b/results/classifier/deepseek-2/output/device/54 new file mode 100644 index 000000000..981a91342 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/54 @@ -0,0 +1,2 @@ + +Attaching SD-Card to specific SD-Bus Sabrelite (ARM) diff --git a/results/classifier/deepseek-2/output/device/540 b/results/classifier/deepseek-2/output/device/540 new file mode 100644 index 000000000..0c642bde3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/540 @@ -0,0 +1,2 @@ + +Heap-use-after-free in usb_packet_unmap through xhci diff --git a/results/classifier/deepseek-2/output/device/541 b/results/classifier/deepseek-2/output/device/541 new file mode 100644 index 000000000..13f200783 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/541 @@ -0,0 +1,2 @@ + +Heap-use-after-free through ehci_flush_qh diff --git a/results/classifier/deepseek-2/output/device/542 b/results/classifier/deepseek-2/output/device/542 new file mode 100644 index 000000000..f121e57f6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/542 @@ -0,0 +1,2 @@ + +Stack-overflow in ldl_le_dma through intel-hda (CVE-2021-3611) diff --git a/results/classifier/deepseek-2/output/device/543 b/results/classifier/deepseek-2/output/device/543 new file mode 100644 index 000000000..fc16546bf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/543 @@ -0,0 +1,2 @@ + +virtio-blk: ASSERT: !s->dataplane_started diff --git a/results/classifier/deepseek-2/output/device/545089 b/results/classifier/deepseek-2/output/device/545089 new file mode 100644 index 000000000..3bbc2ae02 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/545089 @@ -0,0 +1,18 @@ + +qemu-img should be able to create scsi based vmdk images + +qemu-img can create vmdk disk images. These are always created as "ide" disks; that is, the paramter ddb.adapterType is set to "ide" in the .vmdk file. + +I needed to create a scsi style vmdk image, in which ddb.adapterType is set to "lsilogic". + +The attached patch (against qemu-0.12.3) allows me to convert a raw image into a scsi vmdk image: + + qemu-img convert -O vmdk -o scsi rootfs.raw rootfs.vmdk + +The "scsi" option works also for the "create" command. + +I hope very much that this change can be rolled into qemu. + +best, + +Seb James \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/546 b/results/classifier/deepseek-2/output/device/546 new file mode 100644 index 000000000..9dcd64bd7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/546 @@ -0,0 +1,2 @@ + +Global-buffer-overflow in mode_sense_page diff --git a/results/classifier/deepseek-2/output/device/548 b/results/classifier/deepseek-2/output/device/548 new file mode 100644 index 000000000..cacc63bc6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/548 @@ -0,0 +1,2 @@ + +Null-ptr dereference in megasas_finish_dcmd diff --git a/results/classifier/deepseek-2/output/device/549 b/results/classifier/deepseek-2/output/device/549 new file mode 100644 index 000000000..490d5576c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/549 @@ -0,0 +1,2 @@ + +FPE in npcm7xx_clk_update_pll diff --git a/results/classifier/deepseek-2/output/device/552 b/results/classifier/deepseek-2/output/device/552 new file mode 100644 index 000000000..6759da169 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/552 @@ -0,0 +1,2 @@ + +assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed diff --git a/results/classifier/deepseek-2/output/device/556 b/results/classifier/deepseek-2/output/device/556 new file mode 100644 index 000000000..295f2a760 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/556 @@ -0,0 +1,20 @@ + +Fix DMA MMIO reentrancy issues +Additional information: +List of `DMA reentrancy` issues (usually found by [fuzzer](https://gitlab.com/qemu-project/qemu/-/issues?label_name[]=Fuzzer)): +- #62 (AHCI) +- #84, #305, #552 (SCSI) +- #451, #1282 (SDHCI) +- #540 (xHCI) +- #541 (EHCI) +- #542 (HDA) +- #557 (pcnet) +- #782 (NVMe) +- [eepro100](https://lore.kernel.org/qemu-devel/20210218140629.373646-1-ppandit@redhat.com/) +- #827 (virtio-blk) +- #1171 (tulip) +- #1543 (e1000e) +- #1563 (lsi53c895a) + + +Usually coredump backtrace includes multiple calls to `access_with_adjusted_size()` from the Memory API. diff --git a/results/classifier/deepseek-2/output/device/56 b/results/classifier/deepseek-2/output/device/56 new file mode 100644 index 000000000..04711447c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/56 @@ -0,0 +1,2 @@ + +Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused] diff --git a/results/classifier/deepseek-2/output/device/57 b/results/classifier/deepseek-2/output/device/57 new file mode 100644 index 000000000..bc91142df --- /dev/null +++ b/results/classifier/deepseek-2/output/device/57 @@ -0,0 +1,2 @@ + +IDE short PRDT abort diff --git a/results/classifier/deepseek-2/output/device/570 b/results/classifier/deepseek-2/output/device/570 new file mode 100644 index 000000000..59b809d6b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/570 @@ -0,0 +1,2 @@ + +linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined diff --git a/results/classifier/deepseek-2/output/device/583 b/results/classifier/deepseek-2/output/device/583 new file mode 100644 index 000000000..df77f3b46 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/583 @@ -0,0 +1,2 @@ + +Last cylinder of CHS disk image is not declared as accessible in image diff --git a/results/classifier/deepseek-2/output/device/584146 b/results/classifier/deepseek-2/output/device/584146 new file mode 100644 index 000000000..b75719cd3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/584146 @@ -0,0 +1,8 @@ + +Virtual fat breaks with -snapshot + +When using fat emulation together with snapshot, qemu fails to find the directory for the fat "filesystem". + +See Debian bug#504049, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504049 and discussion on qemu-devel with Kevin Wolf, http://marc.info/?t=126850802800001 for details. + +There's a workaround for this bug: when using full path for fat:/dir/name it works. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/588688 b/results/classifier/deepseek-2/output/device/588688 new file mode 100644 index 000000000..579f8e3e4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/588688 @@ -0,0 +1,8 @@ + +Hard disk images are supporting ATAPI commands. They should fail. + +When using a hard disk image (qcow, qcow2, vdi, vmdk, bochs), the emulated device can be a CD-ROM and support ATAPI commands. + +These commands fails in real hard disks and these images are not prepared to handle optical disk formats, they should fail also. + +Only images able to handle that formats (dmg, raw, host) should work with ATAPI commands and CD-ROM devices. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/588693 b/results/classifier/deepseek-2/output/device/588693 new file mode 100644 index 000000000..dc84617c2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/588693 @@ -0,0 +1,4 @@ + +CD-ROM devices always return a one session, one track TOC + +CD-ROM devices always return a one session, one track TOC, no matter if it is using ioctl's with the host or DMG images (both able of having multi track, multi session discs). \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/59 b/results/classifier/deepseek-2/output/device/59 new file mode 100644 index 000000000..4b41be5b9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/59 @@ -0,0 +1,2 @@ + +ide/core.c ATA Major Version reporting incorrect diff --git a/results/classifier/deepseek-2/output/device/591666 b/results/classifier/deepseek-2/output/device/591666 new file mode 100644 index 000000000..e574391a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/591666 @@ -0,0 +1,19 @@ + +broken "pci_add auto storage" + +Doing: +(qemu) pci_add auto storage file=/dev/ram0,if=virtio +Results in: +OK domain 0, bus 0, slot 5, function 0 + +However no device is actually added to the guest. +QEMU: Latest git code (June 9) from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git +(seems to be broken from 0.12.1.2) +KVM: Compiled from git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git +checked out (refs/remotes/origin/stable-2.6.32) + +Both guest and host are Ubuntu 9.10 with 2.6.32 kernel. +Guest kernel has ACPI enabled (specifically, the PCI slot detection driver) + +Guest executed with the following parameters: + -boot c -drive file=/home/eranr/kvm_images/ubuntu-9.10-2.6.32-perf.img,if=ide,boot=on -m 4096 -net nic,model=virtio -net tap,ifname=qtap0,script=no -vnc :0 -smp 1,cores=1,threads=0 -monitor tcp:localhost:6001,server,nowait \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/597 b/results/classifier/deepseek-2/output/device/597 new file mode 100644 index 000000000..a8e41745c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/597 @@ -0,0 +1,20 @@ + +sunhme sometimes causes the VM to hang forever +Description of problem: +When using sunhme, sometimes on receiving traffic (and doing disk IO?) it will get slower and slower until it becomes entirely unresponsive, which does not happen on the real hardware I have sitting next to me (Sun Netra T1, running the same OS+kernel, though not the same image) + +virtio-net-pci does not, so far, demonstrate the problem, and neither does just sending a lot of traffic out over the sunhme interface, so it appears to require receiving or some more complex interaction. + +It doesn't always happen immediately, it sometimes takes a couple of tries with the command, but when it does, it's gone. + +Output logged to console below. +Steps to reproduce: +1. Log into VM (rich/omgqemu) +2. sudo apt clean;sudo apt update; +3. If it doesn't lock up the VM, repeat step 2 a few times. +Additional information: +Disk image can be found [here](https://www.dropbox.com/s/0oosyf7xej44v9n/sunhme_repro_disk.tgz?dl=0) (tarred in the hope that it does something reasonable with sparseness) + +Console output can be found [here](https://www.dropbox.com/s/t1wxx41vzv8p3l6/sunhme%20sadness.txt?dl=0) + +Ah yes, [the initrd and vmlinux](https://www.dropbox.com/s/t7i4gs7poqaeanz/oops_boot.tgz?dl=0) would help, wouldn't they, though I imagine the ones in the VM itself would boot... diff --git a/results/classifier/deepseek-2/output/device/602544 b/results/classifier/deepseek-2/output/device/602544 new file mode 100644 index 000000000..123e04d04 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/602544 @@ -0,0 +1,7 @@ + +[Feature request] Please implement ATA TRIM command + +Modern linuxes can use ATA TRIM command on block devices. It will be very nice if qemu translates this request to underlying block driver. + +1. So, if I use RAW image (on my case - lvm partition), TRIM inside qemu should do TRIM command on my readl HDD +2. In the future, TRIM command inside qemu will free space inside qcow images. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/604 b/results/classifier/deepseek-2/output/device/604 new file mode 100644 index 000000000..8dd699c9c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/604 @@ -0,0 +1,2 @@ + +QEMU crashes with "-global driver=isa-fdc" diff --git a/results/classifier/deepseek-2/output/device/612452 b/results/classifier/deepseek-2/output/device/612452 new file mode 100644 index 000000000..e258652de --- /dev/null +++ b/results/classifier/deepseek-2/output/device/612452 @@ -0,0 +1,16 @@ + +Problems with the number of serial ports for more than two + +qemu --version +QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard + +Command line: + +qemu -serial null -serial null -serial file:test1 hd.img + +Error: + +isa irq 4 already assigned + +echo $? +1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/613529 b/results/classifier/deepseek-2/output/device/613529 new file mode 100644 index 000000000..d6c2b8162 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/613529 @@ -0,0 +1,14 @@ + +qemu does not accept regular disk geometry + +Hi, + +I am currently hunting a strange bug in qemu/kvm: + +I am using an lvm logical volume as a virtual hard disk for a virtual machine. + +I use fdisk or parted to create a partition table and partitions, kpartx to generate the device entries for the partitions, then install linux on ext3/ext4 with grub or msdos filesystem with syslinux. + +But then, in most cases even the boot process fails or behaves strangely, sometimes even mounting the file system in the virtual machine fails. It seems as if there is a problem with the virtual disk geometry. The problem does not seem to occur if I reboot the host system after creating the partition table on the logical volume. I guess the linux kernel needs to learn the disk geometry by reboot. A blkdev --rereadpt does not work on lvm volumes. + +The first approach to test/fix the problem would be to pass the disk geometry to qemu/lvm with the -drive option. Unfortunately, qemu/kvm does not accept the default geometry with 255 heads and 63 sectors. Seems to limit the number of heads to 16, thus limiting the disk size. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/615 b/results/classifier/deepseek-2/output/device/615 new file mode 100644 index 000000000..7af4d4fa1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/615 @@ -0,0 +1,11 @@ + +Not sure if this is a qemu issue but SD card is not correctly read. blk_update_request: I/O error on Manjaro libvirt OS. +Description of problem: + +Steps to reproduce: +1. Run vagrant command line +2. Start console in virt-manager +3. Add USB SD card reader device with SD card. +4. Go back to console +Additional information: +I've bought a new SD card reader and SD card, tried it on other ports and the problem persists. diff --git a/results/classifier/deepseek-2/output/device/62 b/results/classifier/deepseek-2/output/device/62 new file mode 100644 index 000000000..f0abb0b4f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/62 @@ -0,0 +1,2 @@ + +[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines diff --git a/results/classifier/deepseek-2/output/device/628082 b/results/classifier/deepseek-2/output/device/628082 new file mode 100644 index 000000000..f2657a338 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/628082 @@ -0,0 +1,8 @@ + +nl-be keymap is wrong + +As mentioned on https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/429965 as well as the kvm mailinglist (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/14413), the nl-be keymap does not work. The number keys above the regular keys (non-numeric keypad numbers) as well as vital keys such as slash, backslash, dash, ... are not working. + +The nl-be keymap that is presented in the above URLs (and also attached to this bug) does work properly. + +Would it be possible to include this keymap rather than the current one? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/638 b/results/classifier/deepseek-2/output/device/638 new file mode 100644 index 000000000..f7428ac50 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/638 @@ -0,0 +1,14 @@ + +exynos4210_uart.c: SIGSEGV when loadvm +Description of problem: +Line 619 of hw/char/exynos4210_uart.c cast the object incorrectly. + +The function will be called with Exynos4210UartFIFO as opaque because it is set as `vmstate_exynos4210_uart_fifo.post_load` + +# +Steps to reproduce: +1. Create a VM with exynos4210_uart +2. savevm +3. loadvm +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/639 b/results/classifier/deepseek-2/output/device/639 new file mode 100644 index 000000000..5cec4f679 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/639 @@ -0,0 +1,2 @@ + +Crash using riscv.shakti.cclass.soc device diff --git a/results/classifier/deepseek-2/output/device/641 b/results/classifier/deepseek-2/output/device/641 new file mode 100644 index 000000000..2edd3f360 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/641 @@ -0,0 +1,2 @@ + +6.1.0 introduces regression in q35, unable to add more than 15 pcie-root-ports diff --git a/results/classifier/deepseek-2/output/device/648 b/results/classifier/deepseek-2/output/device/648 new file mode 100644 index 000000000..efc6a8a8c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/648 @@ -0,0 +1,2 @@ + +util/vfio-helpers: misaligned address for struct vfio_iova_range, which requires 8 byte alignment diff --git a/results/classifier/deepseek-2/output/device/65 b/results/classifier/deepseek-2/output/device/65 new file mode 100644 index 000000000..db2cad3ab --- /dev/null +++ b/results/classifier/deepseek-2/output/device/65 @@ -0,0 +1,2 @@ + +Assigning NVMe disk to a domain causes VFIO_MAP_DMA errors diff --git a/results/classifier/deepseek-2/output/device/656 b/results/classifier/deepseek-2/output/device/656 new file mode 100644 index 000000000..e9b415999 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/656 @@ -0,0 +1,8 @@ + +qemu-system-arm sabrelite does not use sd card +Description of problem: +I have build qemu from source. Furthermore I build Uboot from source following [this Link](https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html). With the provided command lines I am able to create and image and start the sabrelite board and see Uboot console Output. The problem I am facing is, that I am not able to interact with the provided tmp.img. + +I was also using the -driver option instead of the -blockdev option, but did not get any different results with that. +Additional information: +I provide the console output in the attached file. [console.out](/uploads/996b8c07310ec3b008477e3e70a2e629/console.out) diff --git a/results/classifier/deepseek-2/output/device/657329 b/results/classifier/deepseek-2/output/device/657329 new file mode 100644 index 000000000..c03853abf --- /dev/null +++ b/results/classifier/deepseek-2/output/device/657329 @@ -0,0 +1,48 @@ + +APIC unusable on QEMU + +The APIC is unusable with QEMU using x86-64 system emulation. Problem exists in the latest stable QEMU 0.12.5 as well as the latest git head. I am using Mac OS X 10.6, 64-bit version of QEMU. + +The QEMU binary was configured with: + + ./configure --target-list=i386-softmmu,x86_64-softmmubck-i-search: conf_ + +Problem is that the hw/apic.c file (as well as a few other naughty files) rely on the cpu_single_env global - which is set to NULL in cpu-exec.c. + +Below is a test reading the local APIC version register: + +Before taking it out: + +(qemu) xp 0xfee00030 +00000000fee00030: 0x00000000 +(qemu) + +After: + +(qemu) xp 0xfee00030 +00000000fee00030: 0x00050011 +(qemu) + +Quick fix below. I don't know if there are any side effects with this, if this is OK maybe we can fix it like this for the stable versions and fix the HEAD to not rely on the cpu_single_env global. + +diff --git a/cpu-exec.c b/cpu-exec.c +index dbdfdcc..3e966d7 100644 +--- a/cpu-exec.c ++++ b/cpu-exec.c +@@ -674,7 +674,17 @@ int cpu_exec(CPUState *env1) + env = (void *) saved_env_reg; + + /* fail safe : never use cpu_single_env outside cpu_exec() */ ++#warning fixup devices which rely on this ++#if 0 ++ /* ++ * Hello. This is wrapped around an #if 0 ... #endif because that's ++ * what should happen. However, certain naughty devices (like the APIC ++ * for instance, and a few others), access this global variable. ++ * ++ * So this is here for now ... until we fix up those devices. ++ */ + cpu_single_env = NULL; ++#endif + return ret; + } \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/659 b/results/classifier/deepseek-2/output/device/659 new file mode 100644 index 000000000..fa85c7a55 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/659 @@ -0,0 +1,42 @@ + +Qemu6 regression causing disabled usb controller upon usbredir device_add +Description of problem: +I'm encountering a nagging issue with usbredir and a windows guest, but although I did pinpoint the commit that caused the issue, I have a hard time understanding it. + +The issue occurs when two usbredir devices are added to a guest windows vm (any vm installed from the official iso will reproduce the issue). When the second device is added, the UHCI usb controller is disabled by windows with an error code 43 (can be seen with in the usb adapters section of the device manager). +Steps to reproduce: +1. take/create an intalled windows image and run it with `qemu-system-x86_64 -M pc -cpu host,hv_time,hv_synic,hv_stimer,hv_vpindex -enable-kvm -m 4096 -device piix3-usb-uhci,id=uhci -qmp tcp:127.0.0.1:4444,server=on,wait=off,ipv4 -drive <disk-parameters> --snapshot` (snapshot not necessary but useful for multiples testing to avoid side effects as the usb status sometime lingers after a shutdown, not sure why) +2. Open windows device manager +3. add devices via [this qmp python script](/uploads/5f2f9240dce1b55ceb148b32f3d6073c/qmp-usb-adds.py) +Additional information: +The commit causing the issue (everything works well when reverting it) is 7bed89958bfbf40df9ca681cefbdca63abdde39d : device_core: use `drain_call_rcu` in in `qmp_device_add`. + +I narrowed the problem to the unlock of the iothread: the minimum `drain_call_rcu` code that still reproduce the issue is: + +```c +void drain_call_rcu(void) +{ + bool locked = qemu_mutex_iothread_locked(); + if (locked) { + qemu_mutex_unlock_iothread(); + } + usleep(50000); // time spent draining the rcu on a few slow cases. + + if (locked) { + qemu_mutex_lock_iothread(); + } +} +``` + +About the qemu command line: The hv parameters are needed to trigger the issue I do not know why. + +I tried to find what was able to take advantage of the free iothread lock, but the only thing I got so far is that the iothread lock is not taken during the first drain (from the first device add), but is taken many times during the second drain by physmem's IOs (from kvm-accel, but at this point, I'm a bit lost). + +I'm looking for pointers as to what could trigger the issue in order to narrow it down, as, so far, I do not understand exactly what causes the regression. +I am unsure of how this would even transcribe in a linux vm so i didn't try to reproduce the issue with one. + +With the attached [reproduction python script](/uploads/5f2f9240dce1b55ceb148b32f3d6073c/qmp-usb-adds.py), the issue triggers nearly 100% of the time. + +Note 1: Related to #650 as the commit causing the regression is the same, although the cause is probably different since the rcu is not implied. + +Note 2: This is a restranscription of [this ml report](https://lore.kernel.org/qemu-devel/20210930134844.f4kh72vpeknr2vmk@gmail.com/) as i wasn't aware, the correct way to report issue was through gitlab now. diff --git a/results/classifier/deepseek-2/output/device/66 b/results/classifier/deepseek-2/output/device/66 new file mode 100644 index 000000000..0ea2fec9a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/66 @@ -0,0 +1,2 @@ + +-hda FAT:. limited to 504MBytes diff --git a/results/classifier/deepseek-2/output/device/660 b/results/classifier/deepseek-2/output/device/660 new file mode 100644 index 000000000..5450e69da --- /dev/null +++ b/results/classifier/deepseek-2/output/device/660 @@ -0,0 +1,10 @@ + +User emulation does not use host GPU +Description of problem: + +Steps to reproduce: +1. Make a Arch Linux chroot (though any Linux system should work) on Linux +2. run `glxinfo | grep OpenGL +3. It's using llvmpipe, not whatever GPU/driver that the hosts use +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/660060 b/results/classifier/deepseek-2/output/device/660060 new file mode 100644 index 000000000..5e6a04e72 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/660060 @@ -0,0 +1,33 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/662 b/results/classifier/deepseek-2/output/device/662 new file mode 100644 index 000000000..1c95b55ef --- /dev/null +++ b/results/classifier/deepseek-2/output/device/662 @@ -0,0 +1,12 @@ + +Assertion `!s->do_cmd' failed in am53c974 emulator +Description of problem: + +Steps to reproduce: +``` +1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +2.make -j12 +3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img +``` +Additional information: +# diff --git a/results/classifier/deepseek-2/output/device/663 b/results/classifier/deepseek-2/output/device/663 new file mode 100644 index 000000000..57815c9d8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/663 @@ -0,0 +1,12 @@ + +Assertion `r->req.aiocb == NULL' in am53c974 emulator +Description of problem: + +Steps to reproduce: +``` +1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +2.make -j12 +3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img +``` +Additional information: +# diff --git a/results/classifier/deepseek-2/output/device/666 b/results/classifier/deepseek-2/output/device/666 new file mode 100644 index 000000000..2341cb70f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/666 @@ -0,0 +1,8 @@ + +ivshmem-plain cannot be used on non-Linux hosts +Additional information: +I would like to propose this patch as-is on the mailing list (the trivial one?) as soon as I figure patch submission out fully: + +https://github.com/fredldotme/qemu/commit/e929b8db8078aede6df7b02d8c0b71d1e2d6afcb + +It's just `#ifdef`ing out doorbell support on non-Linux builds which seems to be enough for basic functionality. diff --git a/results/classifier/deepseek-2/output/device/669 b/results/classifier/deepseek-2/output/device/669 new file mode 100644 index 000000000..e72adddc8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/669 @@ -0,0 +1,24 @@ + +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/deepseek-2/output/device/670769 b/results/classifier/deepseek-2/output/device/670769 new file mode 100644 index 000000000..ececb2b5d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/670769 @@ -0,0 +1,15 @@ + +CDROM size not updated when changing image files + +I'm using qemu 13.0 with a plain Linux kernel using the ata_piix driver as the guest, and an initrd that starts a shell. When changing the image in the monitor and reading from the CDROM in the guest, the size is not updated. I'm using LInux 2.6.32.24 +as the host and I've tested 2.6.32.24, 2.6.35, and 2.6.36 as guests. Both host and guest are 64-bit. Here is the command used to start the guest using the initrd: + +./x86_64-softmmu/qemu-system-x86_64 -cdrom /spare2/cd1.img -kernel /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu core2duo + +Additional info on this bug can be found here: http://marc.info/?l=kvm&m=128746013906820&w=2. Note: this is how I discovered +the bug, using 32-bit Slackware install CDs. + +I'm attaching the initrd I used in my tests: I created two different-sized fake CDROM images by dd'ing from /dev/zero. In my tests, +cd1.img is smaller that cd2.img. In the monitor I executed 'change ide1-cd0 /spare2/cd2.img' to load the new image. I checked +the size by cat'ing /sys/block/sr0/size in the guest after reading the CDROM. Reading the CDROM was done by typing +'dd if=/dev/sr0 of=/dev/null bs=512 count=3' \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/674740 b/results/classifier/deepseek-2/output/device/674740 new file mode 100644 index 000000000..1a0de206e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/674740 @@ -0,0 +1,16 @@ + +qemu segfaults when security_model=none using virtio-9p-pci driver + +qemu version: 0.13 +commit-id: 6ed912999d6ef636a5be5ccb266d7d3c0f0310b4 + +example invocation: +$ qemu -virtfs local,path=/tmp,security_model=none,mount_tag=mmm r.img +one of the following must be specified as thesecurity option: + security_model=passthrough + security_model=mapped +Segmentation fault + +Patch is attached. Also attached is a patch that addes the space between 'the' and 'security' in 'thesecurity'. + +Does not affect trunk. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/678 b/results/classifier/deepseek-2/output/device/678 new file mode 100644 index 000000000..814dbd185 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/678 @@ -0,0 +1,48 @@ + +eject (monitor command) not work for blockdev cdrom +Description of problem: +cdrom1 device work fine, all files reads, but when i whant to eject CD-ROM disk from device by telnet monitor, it not work. +Steps to reproduce: +1. Connect to monitor with +``` +telnet 127.0.0.1 9100 +(QEMU 5.2.0 monitor - type 'help' for more information) +``` + +2. Show block devices +``` +info block +cdrom1-format: /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only) + Attached to: cdrom1 + Removable device: not locked, tray closed + Cache mode: writeback +``` + +3. Send eject commands +``` +eject cdrom1 +Error: Device 'cdrom1' not found +eject cdrom1-format +Error: Device 'cdrom1-format' not found +eject cdrom1-storage +Error: Device 'cdrom1-storage' not found +``` +Additional information: +When i run qemu with next lines (replace -blockdev to -drive): +``` +-device ide-cd,bus=ide.1,drive=cdrom1,id=idecd1,bootindex=2 +-drive if=none,id=cdrom1,media=cdrom,readonly=on,file="/mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso" +``` + +eject cdrom1 command work fine + +``` +info block +cdrom1 (#block133): /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only) + Attached to: idecd1 + Removable device: not locked, tray closed + Cache mode: writeback +eject cdrom1 +``` + +Also i found a similar bug description on this link https://bugs.launchpad.net/qemu/+bug/1799766 diff --git a/results/classifier/deepseek-2/output/device/680 b/results/classifier/deepseek-2/output/device/680 new file mode 100644 index 000000000..7c29baabb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/680 @@ -0,0 +1,2 @@ + +multi-threaded qemu instance and pci bar diff --git a/results/classifier/deepseek-2/output/device/684 b/results/classifier/deepseek-2/output/device/684 new file mode 100644 index 000000000..07b361bba --- /dev/null +++ b/results/classifier/deepseek-2/output/device/684 @@ -0,0 +1,2 @@ + +xHCI Port Status Change Event at port powered diff --git a/results/classifier/deepseek-2/output/device/685096 b/results/classifier/deepseek-2/output/device/685096 new file mode 100644 index 000000000..a1898a500 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/685096 @@ -0,0 +1,16 @@ + +USB Passthrough not working for Windows 7 guest + +USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. + +The device appears in the device manager of Windows 7, but with "Error code 10: device cannot start". I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. + +I am trying this with the latest git-pull of QEMU-KVM. + +The command line to launch qemu-kvm for win7 is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 + +The command line to launch qemu-kvm for winxp is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 + +Any help is appreciated. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/697510 b/results/classifier/deepseek-2/output/device/697510 new file mode 100644 index 000000000..cb277d72c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/697510 @@ -0,0 +1,34 @@ + +Machine shut off after tons of lsi_scsi: error: MSG IN data too long + +The problem mostly happens during our backup, syslog does not have any problematic messages. + +Host is Ubuntu 10.10 x86 64 bits +Guest is Windows 2003 Server 32 bits +Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. +Using SCSI the machine shuts off and I get tons of message on stdout; + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 3500 -smp 4,sockets=4,cores=1,threads=1 -name BMSRV0101 -uuid 6ccbb5fa-5880-a1ab-3b7a-fb7ccc7c8ccf -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/BMSRV0101.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/vgUbuntu/vmBMSRV0101,if=none,id=drive-scsi0-0-0,boot=on,format=raw -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:5d:7b:07,bus=pci.0,addr=0x3 -net tap,fd=63,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device usb-host,hostbus=002,hostaddr=005,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +char device redirected to /dev/pts/0 +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +husb: open device 2.5 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 2.5 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 + +lsi_scsi: error: Unimplemented message 0x00 +(x8) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: Unimplemented message 0x00 +(x760) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: MSG IN data too long +kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: Assertion `s->current' failed. + + +I can include minidump file if needed. +I am currently using IDE and it seems OK. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/703 b/results/classifier/deepseek-2/output/device/703 new file mode 100644 index 000000000..2beed929f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/703 @@ -0,0 +1,18 @@ + +Resizable BAR (ReBAR) support on VFIO +Additional information: +Currently `vfio_add_ext_cap()` doesn't pass ReBAR support option to VFIO. + +There was a report that removing the line you see below makes it boot, but the system is not stable. +Needs investigation. + +[https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089](https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089) +``` switch (cap_id) { + case 0: /* kernel masked capability */ + case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */ + case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */ + case PCI_EXT_CAP_ID_REBAR: /* Can't expose read-only */ + trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next); +``` + +[Discussion link](https://forum.level1techs.com/t/smart-access-memory-vs-qemu-kvm/169447) diff --git a/results/classifier/deepseek-2/output/device/706 b/results/classifier/deepseek-2/output/device/706 new file mode 100644 index 000000000..071f551e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/706 @@ -0,0 +1,39 @@ + +NVMe End-to-End Data Protection +Description of problem: +When activating end-to-end data protection inside qemu NVMe virtual namespace, guest can not read or write anything to discovered /dev/nvme0n1. Guest kernel has NVMe support compiled-in, when booting i get the following messages related to emulated nvme pi-enabled drive inside guest: + +``` +[ 0.661260] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.663774] Buffer I/O error on dev nvme0n1, logical block 1, async page read +[ 0.665043] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.666976] Buffer I/O error on dev nvme0n1, logical block 0, async page read +[ 0.676702] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.678664] Buffer I/O error on dev nvme0n1, logical block 0, async page read +[ 0.679923] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.681811] Buffer I/O error on dev nvme0n1, logical block 1, async page read +[ 0.683544] nvme0n1: unable to read partition table +``` + +Same when trying to read anything: + +``` +/ # dd bs=512 count=1 skip=0 if=/dev/nvme0n1 iflag=direct +[ 432.017616] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 +[ 432.020596] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 432.023530] Buffer I/O error on dev nvme0n1, logical block 0, async page read +[ 432.025345] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 432.028289] Buffer I/O error on dev nvme0n1, logical block 1, async page read +dd: /dev/nvme0n1: Input/output error +``` + +And write: + +``` +/ # dd bs=512 count=1 if=output.dat of=/dev/nvme0n1 +[ 597.679455] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +dd: error writing '/dev/nvme0n1': Input/output error +1+0 records in +0+0 records out +0 bytes (0B) copied, 0.003864 seconds, 0B/s +``` diff --git a/results/classifier/deepseek-2/output/device/707 b/results/classifier/deepseek-2/output/device/707 new file mode 100644 index 000000000..9a1ce823e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/707 @@ -0,0 +1,63 @@ + +The QEMU emulator incorrectly interprets the contents of the SLIC table. See attached image. +Description of problem: +The QEMU emulator incorrectly interprets the contents of the SLIC table. + +The SLIC table read on pure hardware and in a virtual machine in the fedora 34 and 35: + + +Steps to reproduce: +Steps to Reproduce: + +1. Install Fedora 34 + +2. Install virtualization group: + + dnf group install virtualization + +4. Place SLIC binary image(slic.bin) into the direcrory /var/lib/libvirt/images + +3. Create Virtual Machine with Virtual Machine Manager. + +4. Modify xml description of virtual machine: + `... + <os> + ... + <acpi> + <table type='slic'>/var/lib/libvirt/images/slic.bin</table> + </acpi> + </os> + ...` + +5. Install Microsoft Windows 7 64-bit into Virtual machine. + +6. Place sertificate into Windows 7. + +7. Run with admin rights: + + slmgr.vbs /ilc <sertificate> + slmgr.vbs /ipk <key> + +8. Windows 7 will be activated ! + +9. Save Virtual Machine Image and it's xml description anywere. + +10. Install Fedora 35 + +11. Install virtualization group. + +12. Place saved Virtual Machine Image and slic.bin into the directory /var/lib/libvirt/images/ + +13. Register virtual machine: + + virsh -c qemu:///system define <xml_file> + +15. Run virtual machine - Windows 7 will lose it activation. +Additional information: +Fedora 34 has: + kernel-5.14.15-200.fc34.x86_64, qemu-system-x86-5.2.0-8.fc34.x86_64 + +Fedora 35 has: + kernel-5.14.15-300.fc35.x86_64, qemu-system-x86-6.1.0-9.fc35.x86_64 + +Slick Binary Image: [slic.bin](/uploads/da94a96516c3dbe52803fb84738f434c/slic.bin) diff --git a/results/classifier/deepseek-2/output/device/71 b/results/classifier/deepseek-2/output/device/71 new file mode 100644 index 000000000..707b4eb53 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/71 @@ -0,0 +1,2 @@ + +AC97 can allocate ~500MB of host RAM diff --git a/results/classifier/deepseek-2/output/device/712337 b/results/classifier/deepseek-2/output/device/712337 new file mode 100644 index 000000000..bee7638bb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/712337 @@ -0,0 +1,43 @@ + +connecthon basic test5 failed with qemu 0.14 on Virtfs path in guest + +connecthon basic test named test5 is failing with bigfile write failed bad address on .L passthru and .L mapped Virtfs path in guest. with fedora12 + +Bug is with latest qemu-0.14.0-rc0 + +connecthon tarball /root/project_CI/client/tests/connecthon/cthon04.tgz +02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 ERROR| [stderr] ./test5: (/root/mount3/test2011-02-0311:55) 'bigfile' write failed : Bad address +02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 ERROR| Test failed: Command <./runtests -N 100 -b -t /root/mount3/test2011-02-0311:55> failed, rc=1, Command returned non-zero exit status +02/03 08:55:09 INFO |kvm_subpro:0880| * Command: +02/03 08:55:09 INFO |kvm_subpro:0880| ./runtests -N 100 -b -t /root/mount3/test2011-02-0311:55 +02/03 08:55:09 INFO |kvm_subpro:0880| Exit status: 1 +02/03 08:55:09 INFO |kvm_subpro:0880| Duration: 0 +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| stdout: +02/03 08:55:09 INFO |kvm_subpro:0880| ... Pass 1 ... +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| Starting BASIC tests: test directory /root/mount3/test2011-02-0311:55 (arg: -t) +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test1: File and directory creation test +02/03 08:55:09 INFO |kvm_subpro:0880| created 155 files 62 directories 5 levels deep in 0.6 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test1 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test2: File and directory removal test +02/03 08:55:09 INFO |kvm_subpro:0880| removed 155 files 62 directories 5 levels deep in 0.4 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test2 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test3: lookups across mount point +02/03 08:55:09 INFO |kvm_subpro:0880| 500 getcwd and stat calls in 0.0 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test3 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test4: setattr, getattr, and lookup +02/03 08:55:09 INFO |kvm_subpro:0880| 1000 chmods and stats on 10 files in 0.24 seconds +02/03 08:55:09 INFO |kvm_subpro:0880| ./test4 ok. +02/03 08:55:09 INFO |kvm_subpro:0880| +02/03 08:55:09 INFO |kvm_subpro:0880| ./test5: read and write +02/03 08:55:09 INFO |kvm_subpro:0880| basic tests failed +02/03 08:55:09 INFO |kvm_subpro:0880| stderr: +02/03 08:55:09 INFO |kvm_subpro:0880| ./test5: (/root/mount3/test2011-02-0311:55) 'bigfile' write failed : Bad address +02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 INFO | Test finished after 1 iterations. +02/03 08:55:10 INFO |kvm_subpro:0880| 11:55:09 ERROR| child process failed +02/03 08:55:10 INFO |kvm_subpro:0880| 11:55:09 INFO | FAIL connecthon.itera-pass-dotl-100-test-bt connecthon.itera-pass-dotl-100-test-bt timestamp=1296752109 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/716 b/results/classifier/deepseek-2/output/device/716 new file mode 100644 index 000000000..68e4a502d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/716 @@ -0,0 +1,4 @@ + +using "-device scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/deepseek-2/output/device/717 b/results/classifier/deepseek-2/output/device/717 new file mode 100644 index 000000000..6f791c3a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/717 @@ -0,0 +1,4 @@ + +using the "scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/deepseek-2/output/device/720 b/results/classifier/deepseek-2/output/device/720 new file mode 100644 index 000000000..0cb5e9148 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/720 @@ -0,0 +1,2 @@ + +The state of parameter DeviceState *dev in function spapr_get_fw_dev_path of PPC /spapr.c may cause a null pointer reference. diff --git a/results/classifier/deepseek-2/output/device/721659 b/results/classifier/deepseek-2/output/device/721659 new file mode 100644 index 000000000..56f229c24 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/721659 @@ -0,0 +1,17 @@ + +qemu-kvm-0.13.0 doesn't pass USB devices to the VM + +I have the bug, similar to this one: +https://bugzilla.redhat.com/show_bug.cgi?id=583108 +but under gentoo + +When I add parameters -usb -usbdevice host:4348:5584, I see the following lines in console: + +husb: config #1 need -1 +USBDEVFS_DISCONNECT: No route to host +husb: open device 2.11 +(...many repetitions of three above lines...) + +All parameters (2.11) are verified with lsusb at host computer - parameters are correct + +Error description is very confusing - I don't know what to check, what "config #1" mean, which route should be checked and how to check it. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/721825 b/results/classifier/deepseek-2/output/device/721825 new file mode 100644 index 000000000..d30b66c3e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/721825 @@ -0,0 +1,77 @@ + +VDI block driver bugs + +Chunqiang Tang reports the following issues with the VDI block driver, these are present in QEMU 0.14: + +"Bug 1. The most serious bug is caused by race condition in updating a new +bmap entry in memory and on disk. Considering the following operation +sequence. + O1: VM issues a write to sector X + O2: VDI allocates a new bmap entry and updates in-memory s->bmap + O3: VDI writes data to disk + O4: The disk I/O for writing sector X fails + O5: VDI reports error to VM and returns. + +Note that the bmap entry is updated in memory, but not persisted on disk. +Now consider another write that immediately follows: + P1: VM issues a write to sector X+1, which locates in the same block as +the previously used sector X. + P2: s->bmap already has one entry for the block, and hence VDI writes +data directly without persisting the new s->bmap entry on disk. + P3: The write disk I/O succeeds + P4: VDI report success to VM, but the bitmap entry is still not +persisted on disk. + +Now suppose the VM powers off gracefully (i.e., the QEMU process quits) +and reboots. The second write to sector X+1, which is reported as finished +successfully, is simply lost, because the corresponding in-memory s->bmap +entry is never persisted on disk. This is exactly what FVD's testing tool +discovers. After the block device is closed and then re-opened, disk +content verification fails. + +This is just one example of the problem. Race condition plus host crash +also causes problems. Consider another example below. + Q1: VM issues a write to sector X + Q2: VDI allocates a new bmap entry and updates in-memory s->bmap + Q3: VDI writes sector X to disk and waits for the callback + Q4: VM issues a write to another sector X+1, which is in the same block +as sector X. + Q5: VDI sees the bitmap entry in s->bmap is already allocated, and +writes sector X+1 to disk. + Q6: Write to sector X+1 finishes, and VDI's callback is invoked. + Q7: VDI acknowledges to the VM the completion of writing sector X+1 + Q8: After observing the completion of writing sector X+1, VM issues a +flush to ensure that sector X+1 is persisted on disk. + Q9: VDI finishes the flush and acknowledge the completion of the +operation. + Q10: ... (some other arbitrary operations, but the disk I/O for writing +sector X is still not finished....) + Q11: The host crashes + +Now the new bitmap entry is not persisted on disk, while both writing to +sector X+1 and the flush has been acknowledged as finished. Sector X+1 is +lost, which is a corruption. This problem exists even if it uses O_DSYNC. +The root cause of the problem is that, if a request updates in-memory +s->bmap, another request that sees this update assumes that the update is +already persisted on disk, which is not. + +Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are +several cases of the code below on failure handling path without setting +error return code, which mistakenly reports failure as success. This +mistake is caught by FVD when doing image content validation. + if (acb->hd_aiocb == NULL) { + /* missing ret = -EIO; */ + goto done; + } + +Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, +vdi_aio_cancel does not perform a complete clean up and there are several +related bugs. First, memory buffer is not freed, acb->orig_buf and +acb->block_buffer. Second, acb->bh is not cancelled. Third, +vdi_aio_setup() does not initialize acb->bh to NULL so that when a request +acb is cancelled and then later reused for another request, its acb->bh != +NULL and the new request fails in vdi_schedule_bh(). This is caught by +FVD's testing tool, when it observes that no I/O failure is injected but +VDI reports a failed I/O request, which indicates a bug in the driver." + +http://permalink.gmane.org/gmane.comp.emulators.qemu/94340 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/727134 b/results/classifier/deepseek-2/output/device/727134 new file mode 100644 index 000000000..fdfce7517 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/727134 @@ -0,0 +1,4 @@ + +pci-stub.o: In function `do_pci_info':0.14.0 compile problem + +Please see this build log. I didn't compile thq qemu-kvm on Mandriva Cooker and haven't any idea. I'm the qemu maintainer on Mandriva. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/733 b/results/classifier/deepseek-2/output/device/733 new file mode 100644 index 000000000..6fa610a68 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/733 @@ -0,0 +1,34 @@ + +Qemu Adventcalendar 2020 ELKS fails to run with error "qemu-system-x86_64: at most one isa-vga device is permitted" +Description of problem: +Running ELKS from Qemu Advent calendar results in: +qemu-system-x86_64: at most one isa-vga device is permitted +Steps to reproduce: +(with ELKS) +1. Untar https://download.qemu.org/qemu-6.2.0-rc0.tar.xz +1. Build qemu-system-x86_64 +2. Download https://www.qemu-advent-calendar.org/2020/download/day23.tar.gz +3. Execute ELKS as described in run.sh +Additional information: +A git bisect was performed to identify the culprit commit: +``` +qemu$ git bisect good +binäre Suche: danach noch 1 Commit zum Testen übrig (ungefähr 1 Schritt) +[2b3a98255c90d8d2f9f87a73eb33371961508517] hw/display/xlnx_dp: fix an out-of-bounds read in xlnx_dp_read + +qemu$ ./configure --target-list=x86_64-softmmu --disable-linux-user && make -j2 + +qemu$ build/qemu-system-x86_64 -machine isapc -vga std +qemu-system-x86_64: at most one isa-vga device is permitted + +qemu$ git bisect bad +binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 0 Schritte) +[7852a77f598635a67a222b6c1463c8b46098aed2] vga: don't abort when adding a duplicate isa-vga device + +qemu$ cat .git/refs/bisect/bad +2b3a98255c90d8d2f9f87a73eb33371961508517 + +qemu$ git status +HEAD losgelöst bei 7852a77f59 + +``` diff --git a/results/classifier/deepseek-2/output/device/739 b/results/classifier/deepseek-2/output/device/739 new file mode 100644 index 000000000..8ed611db4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/739 @@ -0,0 +1,18 @@ + +qemu option -snapshot not work for blockdev disk +Description of problem: +If disk image configured with a -blockdev option, option -snapshot not work: all changes write to disk image instead of temporary files. +Steps to reproduce: +1. Run qemu guest with -blockdev disk image file and -snapshot options +2. Create file test.txt on guest disk +3. Power off guest +4. Run qemu guest again +5. File test.txt present on guest disk +Additional information: +When i replace -blockdev options to legacy -drive option +``` +-snapshot +-drive if=none,id=ssd1-format,media=disk,cache=none,aio=native,discard=unmap,detect-zeroes=unmap,format=qcow2,file=images/windows21h2.qcow2 +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=ssd1-format,id=scsi0-0-0-0,write-cache=on,bootindex=1 +``` +-snapshot option work fine diff --git a/results/classifier/deepseek-2/output/device/740895 b/results/classifier/deepseek-2/output/device/740895 new file mode 100644 index 000000000..00c60955a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/740895 @@ -0,0 +1,65 @@ + +qemu freeze when loading msdos with EMM386.EXE NOEMS HIGHSCAN + +Qemu version used : 0.11.2 and 0.14.0 +Guest : Ms-Dos 6.2 +Host : Ubuntu 10.04 with 2.6.32-29-generic SMP i686 +Starting Qemu with command : qemu -hda dos.img -cpu 486 -m 16 + +When I start msDos under Qemu with the option (in CONFIG.SYS) +DEVICE=C:\DOS\EMM386.EXE NOEMS HIGHSCAN +the guest freeze. +If I remove "HIGHSCAN" system is booting (but my software is not working). + +The whole thing is working on a real computer with a 486 with 16Mb ram or a PII. + +"HIGHSCAN switch allows EMM386.EXE to map expanded memory pages or upper memory blocks (UMBs) over portions of the upper memory area (UMA) used by system read-only memory " from http://support.microsoft.com/kb/96522/en-us + +I add some traces inside "default_ioport_read" in ioport.c, but I don't see any access to F000h-F7FFh like said in ms help. + +Before the system hung, there is access to dma1, dma page register and dma2 : + +inb : 0087 00 +outb: 000c 00 +inb : 0000 00 +inb : 0000 00 +inb : 0001 00 +inb : 0001 00 +inb : 0083 00 +outb: 000c 00 +inb : 0002 00 +inb : 0002 00 +inb : 0003 00 +inb : 0003 00 +inb : 0081 00 +outb: 000c 00 +inb : 0004 00 +inb : 0004 00 +inb : 0005 00 +inb : 0005 00 +inb : 0082 00 +outb: 000c 00 +inb : 0006 00 +inb : 0006 00 +inb : 0007 00 +inb : 0007 00 +inb : 008b 00 +outb: 00d8 00 +inb : 00c4 00 +inb : 00c4 00 +inb : 00c6 00 +inb : 00c6 00 +inb : 0089 00 +outb: 00d8 00 +inb : 00c8 00 +inb : 00c8 00 +inb : 00ca 00 +inb : 00ca 00 +inb : 008a 00 +outb: 00d8 00 +inb : 00cc 00 +inb : 00cc 00 +inb : 00ce 00 +inb : 00ce 00 +outb: 000c 00 +outb: 00d8 00 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/752 b/results/classifier/deepseek-2/output/device/752 new file mode 100644 index 000000000..83f7300ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/752 @@ -0,0 +1,14 @@ + +vmmouse device gets attached twice, one without i8042 associated +Description of problem: +I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too. + +[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is: + +* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time +* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler +* obviously, a crash because ISAKBDDevice should never be null +Steps to reproduce: +1. Load VMware mouse driver +2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading) +3. Crash diff --git a/results/classifier/deepseek-2/output/device/757 b/results/classifier/deepseek-2/output/device/757 new file mode 100644 index 000000000..e9f82d7f4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/757 @@ -0,0 +1,2 @@ + +intel-hda: stream reset bits are broken diff --git a/results/classifier/deepseek-2/output/device/764 b/results/classifier/deepseek-2/output/device/764 new file mode 100644 index 000000000..b4ba66722 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/764 @@ -0,0 +1,46 @@ + +qemu-system-x86 crash (reason: use after free in socket_reconnect_timeout when reconnecting vhost-user dev) +Description of problem: +(gdb) bt<br/> +#0 0x00007f205976b78b in raise () from /usr/lib64/libc.so.6<br/> +#1 0x00007f205976cab1 in abort () from /usr/lib64/libc.so.6<br/> +#2 0x00007f205976404a in ?? () from /usr/lib64/libc.so.6<br/> +#3 0x00007f20597640c2 in __assert_fail () from /usr/lib64/libc.so.6<br/> +#4 0x00007f20594ea556 in **qemu_mutex_lock_impl**(mutex=<optimized out>, file=<optimized out>, line=<optimized out>)<br/> +#5 0x00007f205957a4ef in **socket_reconnect_timeout** (opaque=<optimized out>)<br/> +#6 0x00007f205993b68d in ?? () from /usr/lib64/libglib-2.0.so.0<br/> +#7 0x00007f205993aba4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0<br/> +#8 0x00007f20594e5d49 in glib_pollfds_poll () at /usr/src/debug/qemu-4.1.0-666.x86_64/util/main-loop.c:218<br/> +#9 0x00007f20594e5dc2 in os_host_main_loop_wait (timeout=<optimized out>)<br/> +#10 0x00007f20594e5f5d in main_loop_wait (nonblocking=nonblocking@entry=0)<br/> +... ...<br/> +#14 0x0000560919e13180 in main (argc=80, argv=0x7ffebc1d0598, envp=0x7ffebc1d0820)<br/> + +at the moment, chr had be free by hot unplug vhost-user dev<br/> + +I think the bug cause reason as following:<br/> +1. when vhost-user dev is connecting state, io-task-worker thread will try call tcp_chr_connect_client_async <br/> + again and again to reconnect.<br/> +2. if reconnect fail, io-task-worker thread will switch to main-thread to handle error, and main-thread will <br/> +call qemu_chr_socket_restart_timer again to reconnect again. <br/> + +3. But, if a hot unplug operation insert to main-thread before io-task-worker switch to main-thread,<br/> + the qemu_chr_socket_restart_timer->socket_reconnect_timeout process will use the released chardev and <br/> + trigger qemu crash + +in short, the primary cause of this bug is io-task-worker reconnect process and <br/> +main-thread hot unplug vhost-user-dev process in a race.<br/> +Steps to reproduce: +1. in qio_task_thread_worker func, add sleep in the following position: <br/> +  task->thread->completion = g_idle_source_new(); <br/> +  g_source_set_callback(task->thread->completion,<br/> + qio_task_thread_result, task, NULL);<br/> +  **sleep(8);**<br/> +  g_source_attach(task->thread->completion,<br/> + task->thread->context);<br/> +  g_source_unref(task->thread->completion); <br/> +2. kill spdk proces or dpdk process, qemu will reconnect to the disconnected vhost-user dev of spdk or dpdk <br/> +3. hot unplug the disconnected vhost-user dev when reconnect logic goto upper sleep position <br/> +4. qemu_chr_socket_restart_timer will use the chr after free, and trigger qemu crash +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/764252 b/results/classifier/deepseek-2/output/device/764252 new file mode 100644 index 000000000..68b91a4a8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/764252 @@ -0,0 +1,4 @@ + +wishlist: kirkwood support + +This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/77 b/results/classifier/deepseek-2/output/device/77 new file mode 100644 index 000000000..d4d9ecfa5 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/77 @@ -0,0 +1,2 @@ + +msmouse not recognized in guest diff --git a/results/classifier/deepseek-2/output/device/772275 b/results/classifier/deepseek-2/output/device/772275 new file mode 100644 index 000000000..104674228 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/772275 @@ -0,0 +1,29 @@ + +qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging + +Hi, + +I'm a proxmox distrib user, + +I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. + +after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. + +e1000 driver working fine. + +revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. + +i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + +i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 + +i'm not the only proxmox user ,more users reports here : + +http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-drivers-for-Windows-and-latest-PVE-1.8 + +i've also see that a slackware user with winxp guest has the same problem + +http://www.spinics.net/lists/kvm/msg51089.html + + +I can help to debug if it's possible to have logs somewhere ..... \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/775 b/results/classifier/deepseek-2/output/device/775 new file mode 100644 index 000000000..7b8e995a8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/775 @@ -0,0 +1,5 @@ + +Backup always use Microsoft VSS-FULL Option and breaks other Backups +Additional information: +MS VSS-Options +[https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type](https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type) diff --git a/results/classifier/deepseek-2/output/device/778 b/results/classifier/deepseek-2/output/device/778 new file mode 100644 index 000000000..8c291c476 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/778 @@ -0,0 +1,2 @@ + +heap-buffer-overflow in megasas_sgl_get_len diff --git a/results/classifier/deepseek-2/output/device/778032 b/results/classifier/deepseek-2/output/device/778032 new file mode 100644 index 000000000..93fe2783d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/778032 @@ -0,0 +1,71 @@ + +qemu spinning on serial port writes + +As originally found at http://<email address hidden>/msg08745.html from 3 years ago! + +Basically qemu seizes up in the event that the file descriptor for its emulated serial port has a full buffer, i.e. write() returns EAGAIN. For me, this happened when the serial port was being directed through a UNIX socket, with a default-sized 4KB buffer. Just the normal output from a Linux kernel boot caused it to seize up, and stop the main emulation / select loop. + +My suggestion is to remove the detection of EAGAIN in qemu-char.c:521, so that if the buffer is full, KVM discards the byte(s) it was trying to write. This is a surely better outcome than the process spinning forever. + +I will submit a separate patch to control the buffer sizes when creating UNIX sockets, which will help allow slow-reading processes to tune things so that they don't miss any output. + +Additionally, in the context of a hosted environment, if the -serial option is used, this could be a small security issue. An untrusted user of a guest system, knowing their serial output is going via a small buffer, could spew output to their /dev/ttyS0 at a rate fast enough to trigger this bug and eat a CPU core on the host. + +To quote David S. Ahern's original bug report (mine was the same, only with the latest version from git, so line numbers may have changed - my suggested fix above is accurate though): + +I am trying to redirect a guest's boot output through the host's serial +port. Shortly after launching qemu, the main thread is spinning on: + +write(9, "0", 1) = -1 EAGAIN (Resource temporarily unavailable) + +fd 9 is the serial port, ttyS0. + + +The backtrace for the thread is: + +#0 0x00002ac3433f8c0b in write () from /lib64/libpthread.so.0 +#1 0x0000000000475df9 in send_all (fd=9, buf=<value optimized out>, +len1=1) at qemu-char.c:477 +#2 0x000000000043a102 in serial_xmit (opaque=<value optimized out>) at +/root/kvm-81/qemu/hw/serial.c:311 +#3 0x000000000043a591 in serial_ioport_write (opaque=0x14971790, +addr=<value optimized out>, val=48) + at /root/kvm-81/qemu/hw/serial.c:366 +#4 0x00000000410eeedc in ?? () +#5 0x0000000000129000 in ?? () +#6 0x0000000014821fa0 in ?? () +#7 0x0000000000000007 in ?? () +#8 0x00000000004a54c5 in tlb_set_page_exec (env=0x10ab4, +vaddr=46912496956816, paddr=1, prot=-1, mmu_idx=0, is_softmmu=1) + at /root/kvm-81/qemu/exec.c:388 +#9 0x0000000000512f3b in tlb_fill (addr=345446292, is_write=1, +mmu_idx=-1, retaddr=0x0) + at /root/kvm-81/qemu/target-i386/op_helper.c:4690 +#10 0x00000000004a6bd2 in __ldb_cmmu (addr=9, mmu_idx=0) at +/root/kvm-81/qemu/softmmu_template.h:135 +#11 0x00000000004a879b in cpu_x86_exec (env1=<value optimized out>) at +/root/kvm-81/qemu/cpu-exec.c:628 +#12 0x000000000040ba29 in main (argc=12, argv=0x7fff67f7a398) at +/root/kvm-81/qemu/vl.c:3816 + +send_all() invokes unix_write() which by design is not breaking out on +EAGAIN. + +The following command is enough to show the problem: + +qemu-system-x86_64 -m 256 -smp 1 -no-kvm \ + -drivefile=/dev/cciss/c0d0,if=scsi,cache=off,boot=on \ + -vnc :1 -serial /dev/ttyS0 + + +The guest is running RHEL3 with the parameter 'console=ttyS0' added to +grub.conf; the problem appears to be with qemu, so I would expect it to +show with any linux guest. This particular host is running RHEL5.2 with +kvm-81, but I have also seen the problem with Fedora-9 as the host OS. + +Yes, the serial port of the server is connected to another system via a +null modem. If I change the serial argument to '-serial udp::4555' and +use 'nc -u -l localhost 4555 > /dev/ttyS0' I see the guest's boot +output show up on the second system as expected. I'd prefer to be able +to use the serial port connection directly without nc as a proxy. +Suggestions? \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/779151 b/results/classifier/deepseek-2/output/device/779151 new file mode 100644 index 000000000..aff3771b4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/779151 @@ -0,0 +1,17 @@ + +qemu-nbd crash during using with chroot + +I use qemu-nbd to mount my image. And after some times, qemu-nbd crashes and so the chroot freeze. + +ps aux | grep qemu : +root 2223 0.0 0.0 9776 548 ? Ss 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2224 0.0 0.0 10800 544 ? D 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2227 0.0 0.0 0 0 ? Z 18:03 0:00 [qemu-nbd] <defunct> +root 2357 0.0 0.0 5212 768 pts/0 D+ 18:07 0:00 grep qemu + +mount : +/dev/nbd0p1 on /chroots/test/amd64 type ext3 (rw,errors=remount-ro,commit=0) +/dev on /chroots/test/amd64/dev type devtmpfs (rw,mode=0755) +/dev/pts on /chroots/test/amd64/dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) +/proc on /chroots/test/amd64/proc type proc (rw) +/sys on /chroots/test/amd64/sys type sysfs (rw,noexec,nosuid,nodev) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/78 b/results/classifier/deepseek-2/output/device/78 new file mode 100644 index 000000000..c126a0d26 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/78 @@ -0,0 +1,2 @@ + +msmouse serial mouse emulation broken? No id byte sent on reset diff --git a/results/classifier/deepseek-2/output/device/782 b/results/classifier/deepseek-2/output/device/782 new file mode 100644 index 000000000..a2669b182 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/782 @@ -0,0 +1,6 @@ + +nvme: DMA reentrancy issue leads to use-after-free (CVE-2021-3929) +Description of problem: +A DMA reentrancy issue was found in the NVM Express Controller (NVMe) emulation. Functions dma_buf_write() or dma_buf_read() in hw/nvme/ctrl.c:nvme_tx() can be called without checking if the destination region overlaps with device's MMIO. This is similar to CVE-2021-3750 (https://gitlab.com/qemu-project/qemu/-/issues/541) and, just like it, when the reentrancy write triggers the reset function nvme_ctrl_reset(), data structs will be freed leading to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host. + +This issue was reported by Qiuhao Li. diff --git a/results/classifier/deepseek-2/output/device/783 b/results/classifier/deepseek-2/output/device/783 new file mode 100644 index 000000000..7a0113c9e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/783 @@ -0,0 +1,4 @@ + +risc-v: provide CPU without MMU +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/786208 b/results/classifier/deepseek-2/output/device/786208 new file mode 100644 index 000000000..c9f96e5eb --- /dev/null +++ b/results/classifier/deepseek-2/output/device/786208 @@ -0,0 +1,10 @@ + +Missing checks for non-existent device in ide_exec_cmd + +Several calls in the ide_exec_cmd handler are missing checks for (!s->bs) or similar, resulting in NULL pointer dereferences, divide-by-zero, or possibly other badness if the guest performs operations on a non-existent IDE master. + +For example, the WIN_READ_NATIVE_MAX command does a 'ide_set_sector(s, s->nb_sectors - 1);', which does 'cyl = sector_num / (s->heads * s->sectors);', which will fail with a divide-by-zero if heads = sectors = 0. + +And WIN_MULTREAD also does not check for s->bs, but does a 'ide_sector_read(s);', which will do 'bdrv_read(s->bs, sector_num, s->io_buffer, n);' on a NULL s->bs, leading to a segfault. + +I do not *believe* that a malicious guest can do anything more than cause a crash with these bugs. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/786209 b/results/classifier/deepseek-2/output/device/786209 new file mode 100644 index 000000000..05ee4967d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/786209 @@ -0,0 +1,8 @@ + +Information leak in IDE core + +When the DRQ_STAT bit is set, the IDE core permits both data reads and data writes, regardless of whether the current transfer was initiated as a read or write. + +Furthermore, the IO buffer is allocated via a qemu_memalign but not initialized or cleared at device creation. + +This potentially leaks uninitialized host memory into the guest, if, before doing anything else to an IDE device, the guest begins a write transaction (e.g. WIN_WRITE), but then *reads* from the IO port instead of writing to it. The IDE core will happily return the uninitialized contents of the buffer to the guest, potentially leaking offsets that could be used as part of an attack to get around ASLR. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/786211 b/results/classifier/deepseek-2/output/device/786211 new file mode 100644 index 000000000..d078b9ad9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/786211 @@ -0,0 +1,4 @@ + +Missing checks for valid, writable, firmware in fw_cfg_write + +The `fw_cfg_write` function in the firmware emulation is missing checks to ensure that the firmware being written is (a) a valid index, and (b) writable. This can lead to a segmentation fault and potentially (in the case of writing to FW_CFG_INVALID), memory corruption, although the attacker has fairly limited control over whether and what corruption is possible. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/800 b/results/classifier/deepseek-2/output/device/800 new file mode 100644 index 000000000..1d4f654d8 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/800 @@ -0,0 +1,26 @@ + +Cannot write to MTP Devices in Qemu 6.0.0+ +Description of problem: +QEMU versions above 6.0.0 are no longer able to write to MTP devices, the kernel prints a warning which is unique to versions above 6.0.0: +``` +usb-mtp: file monitoring init failed: File monitoring not available on this platform is just warning +``` +Steps to reproduce: +1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0 +2. Mount the MTP device using something: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + touch mtpDevice/test + ``` +4. Observe that you will get an input/output error when trying to write to the device, like this: + ``` + vm-test-run-mtp> client: must succeed: /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh >&2 + vm-test-run-mtp> client # Device 0 (VID=46f4 and PID=0004) is a QEMU Virtual MTP. + vm-test-run-mtp> client # qemu-system-x86_64: usb-mtp: file monitoring init failed: File monitoring not available on this platform + vm-test-run-mtp> client # /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh: line 4: phone/tmp/testFile: Input/output error + ``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/802 b/results/classifier/deepseek-2/output/device/802 new file mode 100644 index 000000000..dc9179d65 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/802 @@ -0,0 +1,27 @@ + +Devices created using '-device' JSON syntax don't emit DEVICE_DELETED when unplugged +Description of problem: +Run the following sequence: + +``` + $ ./qemu-system-x86_64 -qmp stdio \ + -device '{"driver": "virtio-mouse-pci", "id": "dev0"}' \ + -device virtio-mouse-pci,id=dev1 +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 6}, "package": "v6.2.0-105-g7494244ffc-dirty"}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev0"} } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev1"} } +{"return": {}} +{ "execute": "system_reset" } +{"return": {}} +{"timestamp": {"seconds": 1641385071, "microseconds": 120178}, "event": "RESET", "data": {"guest": false, "reason": "host-qmp-system-reset"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121431}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev1/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121684}, "event": "DEVICE_DELETED", "data": {"device": "dev1", "path": "/machine/peripheral/dev1"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 122297}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev0/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 198581}, "event": "RESET", "data": {"guest": true, "reason": "guest-reset"}} + + ``` + +Notice the lack of a "DEVICE_DELETED" event with path "/machine/peripheral/dev0" - the device created with JSON syntax diff --git a/results/classifier/deepseek-2/output/device/804 b/results/classifier/deepseek-2/output/device/804 new file mode 100644 index 000000000..40bd67f6b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/804 @@ -0,0 +1,10 @@ + +savevm - QXL preventing save +Description of problem: +Attempting to savevm with a QXL VGA device attached causes the error "pre-save failed: qxl" to appear. +Steps to reproduce: +1. Start a QEMU instance with a QXL device +2. Attempt to savevm +3. See error +Additional information: + diff --git a/results/classifier/deepseek-2/output/device/804517 b/results/classifier/deepseek-2/output/device/804517 new file mode 100644 index 000000000..1aac5d252 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/804517 @@ -0,0 +1,45 @@ + +qemu crashes on Darwin in qemu_iohandler_poll + +I have an issue when I try to run qemu-system-arm on Mac OS X. +Sometime between 1 and 15 secs after qemu is started it crashes +as shown bellow. + +Same thing on linux host works fine. + +Is anybody else experiencing this? +Any Hints? + +Thanks, + +Damjan + + + +(gdb) run +Starting program: /opt/arm-qemu/bin/qemu-system-arm -M verdex -pflash flash.img -nographic -monitor null -m 289 +Reading symbols for shared libraries .++++++++++++++........................................................................................ done +pxa2xx_clkpwr_write: CPU frequency change attempt + + +U-Boot 1.2.0 (May 10 2008 - 21:17:19) - PXA270@400 MHz - 1604 + +*** Welcome to Gumstix *** + +DRAM: 256 MB +Flash: 32 MB +Using default environment + +Hit any key to stop autoboot: 1 +Program received signal EXC_BAD_ACCESS, Could not access memory. +Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5fbfed30 +0x00007fff5fbfed30 in ?? () +(gdb) +(gdb) bt +#0 0x00007fff5fbfed30 in ?? () +#1 0x00000001000c26f4 in qemu_iohandler_poll () +#2 0x00000001001975ae in main_loop_wait () +#3 0x00000001001976e2 in main_loop () +#4 0x000000010019bfbc in qemu_main () +#5 0x00000001000d63a5 in main () +(gdb) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/810588 b/results/classifier/deepseek-2/output/device/810588 new file mode 100644 index 000000000..ed515774b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/810588 @@ -0,0 +1,6 @@ + +Unexpected crash of qemu-kvm with SCSI disk emulation. + +Virual machine with MS windows 2003 installed on the virtual scsi disk (-drive file=/my/path/myimage.qcow2.img,boot=on,if=scsi,media=disk,bus=0,unit=1) unexpectedly crashes without core dump. When the image is connected as an ide disk (-hda ) vm flies normally. +Qemu-kvm version: 0.12.5 +Os/distr.: Debian squeeze, x86_64 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/811 b/results/classifier/deepseek-2/output/device/811 new file mode 100644 index 000000000..774f17f56 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/811 @@ -0,0 +1,2 @@ + +qemu_irq_split() callers should use TYPE_SPLIT_IRQ device instead diff --git a/results/classifier/deepseek-2/output/device/811683 b/results/classifier/deepseek-2/output/device/811683 new file mode 100644 index 000000000..a8ffc4b0d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/811683 @@ -0,0 +1,25 @@ + +7400,7410,7450 cpus vector have wrong exception prefix at reset + +I have a proprietary ROM implementing system calls that are executed via the 'SC' instruction. + +I use qemu-0.14.1, + +qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel + +That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found that the emulator jumps to 0x00000c00 instead of 0xfff00c00. +Probably this is due to a wrong setting in target-ppc/translate_init.c: + +init_excp_604() correctly sets env->hreset_vector=0xfff00000UL; + +but + +init_excp_7400() says env->hreset_vector=0x00000000UL; + +which seems wrong. (the 7400 manual says a hard-reset jumps initializes the +prefix to 0xfff00000.) + +Likewise, init_excp_7450() (and probably other, related CPUs) are wrong. + +Indeed, when I change the value in init_excp_7400() to 0xfff00000UL then +everything works as expected for me. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/813546 b/results/classifier/deepseek-2/output/device/813546 new file mode 100644 index 000000000..21a251f90 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/813546 @@ -0,0 +1,6 @@ + +option to disable PS/2 mouse + +Adds an option to disable the PS/2 mouse. + +This is useful to work around bugs in PS/2 drivers in some system or testing system without a PS/2 mouse present. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/818673 b/results/classifier/deepseek-2/output/device/818673 new file mode 100644 index 000000000..768109f43 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/818673 @@ -0,0 +1,9 @@ + +virtio: trying to map MMIO memory + +Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +Qemu is started as such: +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/820 b/results/classifier/deepseek-2/output/device/820 new file mode 100644 index 000000000..ef02daa1c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/820 @@ -0,0 +1,14 @@ + +Hang During Initramfs +Description of problem: +[Hang During Initramfs](https://wiki.archlinux.org/title/QEMU#Hang_during_VM_initramfs) +Is this still not fixed? I hang at startup. Previously I tried WIN11 and it booted fine. +Steps to reproduce: +1. Download Windows10 ISO +2. qemu-img create -f raw Windows10 15G +3. qemu-system-x86_64 -cdrom Win10.iso -boot order=d -drive file=Windows10,format=raw -m 4G +Additional information: + + + +`-enable-kvm` works but i removed it to slow down a bit to see what is going on. diff --git a/results/classifier/deepseek-2/output/device/821078 b/results/classifier/deepseek-2/output/device/821078 new file mode 100644 index 000000000..8e1b857c7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/821078 @@ -0,0 +1,14 @@ + +virtio-serial-bus: Unexpected port id + +With qemu-kvm-0.15.0-rc1 virtio-serial-bus reports an error, and windows vdagent can not start. qemu-0.15.0-rc1 behaves as expected, ie vdagent runs in the guest, mouse passes seamlessly between spicec and host and copy/paste works between guest and host. +qemu-kvm has been configured with +./configure --target-list=x86_64-softmmu --disable-curses --disable-curl --audio-drv-list=alsa --audio-card-list=sb16,ac97,hda --enable-vnc-thread --disable-bluez --enable-vhost-net --enable-spice +and is started with +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,aio=native -m 1536 -name WinXP -net nic,model -net user -localtime -usb -vga qxl -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio + +I've also tried start qemu like +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio +and observed the same results. + +the host runs 2.6.39.4 vanilla kernel. the guest uses the most recent virtio-serial, vga-qxl and vdagent from spice-space.org \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/822 b/results/classifier/deepseek-2/output/device/822 new file mode 100644 index 000000000..27255772a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/822 @@ -0,0 +1,17 @@ + +hw/ppc/vof.c:1033: undefined reference to `fdt_get_max_phandle' in qemu-6.1.1, qemu-6.2.0 +Description of problem: +Compilation of the source code of 6.1.1 and 6.2.0 fails in the qemu-system-ppc target ath the linking stage. Specifically the error in both cases is +usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: libqemu-ppc-softmmu.fa.p/hw_ppc_vof.c.o: in function `vof_build_dt': +/home/silviu/qemu-work/qemu-6.1.1/build/../hw/ppc/vof.c:1033: undefined reference to `fdt_get_max_phandle' + +(same error for 6.2.0) + +This system has qemu-5.2.0 installed, which is the default for Funtoo currently. There were no compilation errors with 5.2.0. +gcc is version 9.2.0 +Steps to reproduce: +1. download qemu-6.1.1.tar.xz/qemu-6.2.0.tar.xz and uncompress +2. configure +3. make[error.txt](/uploads/c9a987870eff85e586ddb29a113f64a7/error.txt) +Additional information: +the final part of the build log attached as text diff --git a/results/classifier/deepseek-2/output/device/822408 b/results/classifier/deepseek-2/output/device/822408 new file mode 100644 index 000000000..4353ec203 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/822408 @@ -0,0 +1,46 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/830 b/results/classifier/deepseek-2/output/device/830 new file mode 100644 index 000000000..8972a2441 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/830 @@ -0,0 +1,2 @@ + +QEMU aarch64 support for Windows TPM driver (TIS, CRB interfaces) diff --git a/results/classifier/deepseek-2/output/device/839790 b/results/classifier/deepseek-2/output/device/839790 new file mode 100644 index 000000000..22da71472 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/839790 @@ -0,0 +1,18 @@ + +-usbdevice tablet broken on win XP client + +I'm using the qemu-kvm package from arch (not the qemu package), and on prior versions of qemu-kvm I was able to use -usbdevide tablet without problems. The absolute mouse position is great... With current version of qemu-kvm, when I use -usbdevice tablet, I got no mouse at all. As my client is windows XP, it's not good to try do anything without mouse, :-) + +I searched in current bugs, and didn't find any bug which subject included "tablet", so I'm submitting this bug... + +Current qemu-kvm package in arch I'm using is: + +% pacman -Ss qemu-kvm +extra/qemu-kvm 0.15.0-2 [installed] + Latest KVM QEMU is a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation. + +Please notice I do not get any error, just the mouse broken... + +thanks, + +Javier. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/84 b/results/classifier/deepseek-2/output/device/84 new file mode 100644 index 000000000..c3ac9f4dd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/84 @@ -0,0 +1,2 @@ + +Machine shut off after tons of lsi_scsi: error: MSG IN data too long diff --git a/results/classifier/deepseek-2/output/device/849 b/results/classifier/deepseek-2/output/device/849 new file mode 100644 index 000000000..6b698990d --- /dev/null +++ b/results/classifier/deepseek-2/output/device/849 @@ -0,0 +1,23 @@ + +High mouse polling rate stutters some applications +Description of problem: +There are couple of instances where moving the mouse would slow down some applications, especially for games + +https://www.reddit.com/r/VFIO/comments/ect3sd/having_an_issue_with_my_vm_where_games_stutter/ + +https://www.reddit.com/r/VFIO/comments/n9hwtg/game_fps_drop_on_mouse_input/ + +https://www.reddit.com/r/VFIO/comments/ln1uwb/evdev_mouse_passthrough_with_1000hz_mouse_causes/ + +https://www.reddit.com/r/VFIO/comments/se92rq/looking_for_advice_on_poor_gpu_passthrough/ + +I myself included, is impacted by this mysterious issue, I'm not pretty sure whether this is related to VFIO or QEMU or both, but I'm definitely sure this is a kind of regression in between since I had no such issue before. +Steps to reproduce: +1. Do a GPU passthrough +2. Get a mouse capable of outputting high polling rate like 1000Hz, usually they are categorized as gaming mouses +3. Start any 3D applications, including stuff like Unreal Engine 4 Editor or any games +4. See mysterious stuttering +Additional information: +I'm using an AMD Ryzen 7 3700X CPU as the host, but I have made scripts that pins CPU to the VM to get better performance speculatively by putting the threads on the same CCX to minimize memory latency as much as possible. This alleviated some terrible lag, but not by much. (like 11 FPS to 20 FPS if you move your mouse which is still crappy compared to 90+ FPS when static) + +I suspect there is something wrong with the USB subsystem. diff --git a/results/classifier/deepseek-2/output/device/877498 b/results/classifier/deepseek-2/output/device/877498 new file mode 100644 index 000000000..b4040d94b --- /dev/null +++ b/results/classifier/deepseek-2/output/device/877498 @@ -0,0 +1,4 @@ + +qemu does not pass sector size from physical devices to virtual devices + +When passing a physical disk (i.e. a multipathed fcal volume in my case) with a 4k sector size as raw image to qemu (-drive file=/dev/mapper/hartebeest-sys,if=none,id=drive-virtio-disk0,boot=on,format=raw), the resulting virtual device has a sector size of 512b, rendering the partition table unusable! \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/878 b/results/classifier/deepseek-2/output/device/878 new file mode 100644 index 000000000..584d9f1f4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/878 @@ -0,0 +1,43 @@ + +Can't bind PCI device behind a PCI bridge (No such device) +Description of problem: +Qemu fails to assign the device with : +``` +qemu-system-x86_64: -device vfio-pci,host=3b:00.0: vfio 0000:3b:00.0: error getting device from group 72: No such device +Verify all devices in group 72 are bound to vfio-<bus> or pci-stub and not already in use +``` + +Looking at strace, we can see that the device is behind a PCI bridge: +``` +lstat("/sys", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 +lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci/devices/0000:3b:00.0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 +readlink("/sys/bus/pci/devices/0000:3b:00.0", "../../../devices/pci0000:3a/0000"..., 4095) = 53 +lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 +readlink("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", "../../../../bus/pci", 4095) = 19 +lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +ioctl(14, VFIO_GROUP_GET_DEVICE_FD, 0x56267b3b1320) = -1 ENODEV (No such device) +``` + +The issue is that the PCI bridge `0000:3a:02.0`, is used by "pcieport" kernel driver and not "vfio-pci". +After manually unbinding the PCI bridge from it's driver and binding it to vfio-pci qemu successfully attaches it to the VM. + +I saw online that qemu is suposed to automaticly unbind devices from the host, make them available to the VM and restore them to their previous state once the VM is shutdown. +This is not happening here. +Steps to reproduce: +1. Have a PCI device behind a PCI bridge +2. Launch a VM with the PCI device attached +3. Observe similar error messages +Additional information: +After reading [kernel vfio doc](https://www.kernel.org/doc/html/latest/driver-api/vfio.html#vfio-usage-example), I can see that `ls -l /sys/bus/pci/devices/0000:3b:00.0/iommu_group/devices` was supposed to list the PCI bridge, but it is not the case for me. + +I could only notice the presence of the bridge by looking in the `/sys/bus/pci/devices/0000:3b:00.0` symlink. + +Maybe qemu misses it because of that ? diff --git a/results/classifier/deepseek-2/output/device/884401 b/results/classifier/deepseek-2/output/device/884401 new file mode 100644 index 000000000..153b6f46e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/884401 @@ -0,0 +1,56 @@ + +PCI Passthrough for Digium TCE400P Codec Card Not working + +trying to use a Digium TCE400P Codec card on a Virtual instance using the following information: + +lspci <enter> + +02:08.0 Ethernet controller: Digium, Inc. Wildcard TCE400P transcoder base card (rev 11) + +lspci -n <enter> + +02:08.0 0200: d161:8004 (rev 11) + +virsh nodedev-list | grep pci + +pci_0000_02_08_0 + +printf %x 02 +2 + +printf %x 08 +8 + +printf %x 0 +0 + +bus='0x02' +slot='0x08' +function='0x0' + +# virsh edit vmanager +<hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0x02' slot='0x08' function='0x0'/> + </source> +</hostdev> + +I have SELINUX disabled at this time. + +virsh start vmanager I get the following error message: + +[root@twins qemu]# virsh start vmanager +error: Failed to start domain vmanager +error: internal error Process exited while reading console log output: char device redirected to /dev/pts/2 +Unable to assign device: PCI region 1 at address 0xdf1fe000 has size 0x400, which is not a multiple of 4K +qemu-kvm: -device pci-assign,host=02:08.0,id=hostdev0,configfd=23,bus=pci.0,addr=0x6: Device 'pci-assign' could not be initialized + + + +Version Numbers: + +[root@twins qemu]# yum list | grep qemu +gpxe-roms-qemu.noarch 0.9.7-6.3.el6_0.1 @updates +qemu-img.x86_64 2:0.12.1.2-2.113.el6_0.8 @updates +qemu-kvm.x86_64 2:0.12.1.2-2.113.el6_0.8 @updates +qemu-kvm-tools.x86_64 2:0.12.1.2-2.113.el6_0.8 updates \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/893367 b/results/classifier/deepseek-2/output/device/893367 new file mode 100644 index 000000000..945822d56 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/893367 @@ -0,0 +1,11 @@ + +HPET supports only one IRQ + +The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CPUs and each timer block can be driven by a different IRQ. + +TIMER: HPET at fed00000 -> 0xbf500000. +TIMER: HPET vendor 8086 revision 01: LEGACY 64BIT +TIMER: HPET: cap 8086a201 config 0 period 10000000 +TIMER: HPET Timer[0]: config 30 int 4 +TIMER: HPET Timer[1]: config 30 int 4 +TIMER: HPET Timer[2]: config 30 int 4 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/895 b/results/classifier/deepseek-2/output/device/895 new file mode 100644 index 000000000..2d66bbda7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/895 @@ -0,0 +1,39 @@ + +can't find table device while call qemu_input_is_absolute function +Description of problem: +vnc service can‘t run with mouse absolute mode +Steps to reproduce: +1.create a virtual machine with vnc service via virt-manager. + +2.delete mouse and table device if exists. + +3.add table devices first,next add mouse device. + +4.gdb attach corresponding qemu thread, run command +print "%d",qemu_input_is_absolute() +display function return false ,so I can't use mouse with absolute mode. +Additional information: +code in qemu_input_is_absolute() is +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_REL | INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +qemu_input_find_handler function find a handler INPUT_EVENT_MASK_REL or INPUT_EVENT_MASK_ABS,but just compare with INPUT_EVENT_MASK_ABS, +I think it should be +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +thanks for your help. diff --git a/results/classifier/deepseek-2/output/device/897466 b/results/classifier/deepseek-2/output/device/897466 new file mode 100644 index 000000000..e15e03043 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/897466 @@ -0,0 +1,22 @@ + +UHCI Host Controller no longer present with -usb + +If on an up to date 12.04 install and I start a VM with: +$ qemu -m 192 -serial none -chardev null,id=chardevmon -pidfile /tmp/pid -daemonize -nographic -monitor tcp:127.0.0.1:4444,server,nowait -net user,hostfwd=tcp:127.0.0.1:4422-:22 -usb -rtc base=utc -name qatest-vm -uuid ded3a46b-bb60-43f4-8113-d041aeb93cdf -hda libvirt/qatest/qatest.qcow2 + +Then use the 'info usbhost' in the monitor, I get: +$ echo 'info usbhost' | nc -q 1 127.0.0.1 4444 +(qemu) info usbhost +husb: using sys file-system with /dev/bus/usb +$ + +In Oneiric and eariler, 'info usbhost' would should a UHCI Host Controller. Eg: +$ qemu -m 192 -serial none -chardev null,id=chardevmon -pidfile /tmp/pid -daemonize -nographic -monitor tcp:127.0.0.1:4444,server,nowait -net user,hostfwd=tcp:127.0.0.1:4422-:22 -usb -rtc base=utc -name qatest-vm -uuid ded3a46b-bb60-43f4-8113-d041aeb93cdf -hda libvirt/qatest/qatest.qcow2 +echo 'info usbhost' | nc -q 1 127.0.0.1 4444 +QEMU 0.14.1 monitor - type 'help' for more information +(qemu) info usbhost +husb: using sys file-system with /dev/bus/usb + Device 1.1, speed 12 Mb/s + Hub: USB device 1d6b:0001, UHCI Host Controller + +This breaks QRT/scripts/test-qemu.py and appears to be a regression, but I am not sure if it is a 3.2 kernel issue or a 0.14.1 vs 0.15 issue. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/904617 b/results/classifier/deepseek-2/output/device/904617 new file mode 100644 index 000000000..a29b87c4c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/904617 @@ -0,0 +1,16 @@ + +device_add usb-hub causes segfault in qemu-1.0 + +When calling the command + +(qemu) device_add usb-hub,bus=usb.0,port=4 + +qemu replies + +Error: usb port 4 (bus usb.0) not found (in use?) + +Then qemu crashes with a segfault: + +[ 1546.177627] qemu-system-x86[1710]: segfault at 0 ip b75d3f8b sp bfddb0b0 error 6 in qemu-system-x86_64[b7488000+2e2000] + +Maybe it might be related to the docs/usb2.txt where UHCI has only 2 ports. But a mistake in the port number should not cause qemu to crash \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/905 b/results/classifier/deepseek-2/output/device/905 new file mode 100644 index 000000000..7a6ed2c6a --- /dev/null +++ b/results/classifier/deepseek-2/output/device/905 @@ -0,0 +1,2 @@ + +Null-ptr dereference in blk_bs diff --git a/results/classifier/deepseek-2/output/device/906804 b/results/classifier/deepseek-2/output/device/906804 new file mode 100644 index 000000000..64c02caca --- /dev/null +++ b/results/classifier/deepseek-2/output/device/906804 @@ -0,0 +1,42 @@ + +SIGSEGV using sheepdog + +While doing a mkfs on a Sheepdog volume attached inside a VM, qemu-kvm segfaults: + + +Program received signal SIGSEGV, Segmentation fault. +aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 +784 /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c: No such file or directory. + in /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c +(gdb) bt +#0 aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 +#1 0x00007effed02b7bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/coroutine-ucontext.c:125 +#2 0x00007effe89e4d60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007fff90ed7fd0 in ?? () +#4 0x0000000000000000 in ?? () +(gdb) bt full +#0 aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 + rsp = {proto_ver = 8 '\b', opcode = 8 '\b', flags = 61231, epoch = 32511, id = 4023393600, data_length = 32511, result = 4022027568, copies = 32511, pad = {3902624371, 32511, 4022027680, 32511, 4022027680, 32511}} + s = <optimized out> + fd = <optimized out> + aio_req = <optimized out> + acb = <optimized out> + idx = 139637703787936 +#1 0x00007effed02b7bb in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/coroutine-ucontext.c:125 + self = 0x7effefbb45a0 + co = 0x7effefbb45a0 +#2 0x00007effe89e4d60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +No symbol table info available. +#3 0x00007fff90ed7fd0 in ?? () +No symbol table info available. +#4 0x0000000000000000 in ?? () +No symbol table info available. +(gdb) info threads + Id Target Id Frame + 12 Thread 0x7eff4d3ea700 (LWP 10461) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 11 Thread 0x7eff4c3e8700 (LWP 10460) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 9 Thread 0x7eff49be3700 (LWP 10442) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 8 Thread 0x7eff4a3e4700 (LWP 10441) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 7 Thread 0x7eff493e2700 (LWP 10440) "kvm" 0x00007effe8d3264b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 + 6 Thread 0x7effd2741700 (LWP 10270) "kvm" 0x00007effe8a71407 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6 +* 1 Thread 0x7effecf39900 (LWP 10267) "kvm" aio_read_response (opaque=0x0) at /build/buildd-qemu-kvm_1.0+dfsg-2-amd64-V1Rh0p/qemu-kvm-1.0+dfsg/block/sheepdog.c:784 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/912983 b/results/classifier/deepseek-2/output/device/912983 new file mode 100644 index 000000000..bebc3d628 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/912983 @@ -0,0 +1,45 @@ + +Unable to install OS/2 Warp v3 past disk 2 + +To whom it may concern, + +As you may (or may not) be aware, QEMU is currently unable to readily install OS/2 Warp v3 (OS2W3) when asked for Installation Diskette 2 (http://www.claunia.com/qemu/objectManager.php?sClass=version&iId=132&iTestingId=138). + +QEMU 0.8.2 is the last known (to me) release to successfully install OS2W3. QEMU version 1.0 and the latest development version (as of 2012-01-05) have been verified not to work. + +A 'git bisect' reveals the issue was introduced during a migration to new removable media handling prior to the QEMU 0.9.0 release: + + There are only 'skip'ped commits left to test. + The first bad commit could be any of: + 66c6ef7678939f2119eb649074babf5d5b2666f6 + ea185bbda732dae6b6a5a44699f90c83e21f1494 + 19cb37389f4641d48803f0c5d72708749cbcf318 + We cannot bisect more! + +For testing, the 'qcow' hard drive format was chosen due to QEMU 0.8.2 not having 'qcow2': + + $ qemu -M isapc -m 8 -localtime -soundhw sb16 -hda os2.qcow -fda install.img -boot a + +Of note, the ISA-only PC (isapc) was needed for QEMU 0.8.2 to 0.9.0. Otherwise QEMU hangs on start-up. Later versions of QEMU, segmentation fault when attempting to use '-M isapc' though boot correctly when using the default PC machine. + + +The currently preferred method to install OS2W3 is to use another application (such as VirtualBox or VMWare), using a QEMU compatible disk image format. Once installed, QEMU can then run OS2W3; which it does phenomenally well. + +However, I've identified a way to install OS2W3 exclusively with QEMU, which may also shed additional light on the issue. + +1. Using a relatively new QEMU (I'm on 0.11.1), install OS2W3 as you normally would on to a 'qcow2' hard drive. +2. When Installation Diskette 2 is reached, save a VM snapshot. +3. Quit QEMU and re-run, loading the VM state *with* the Installation Diskette 2 image in the floppy drive. + $ qemu -m 8 -localtime -soundhw sb16 -hda os2.qcow2 -fda disk2.img -loadvm install +The installation process will then continue as normal. + +This same method can be used once OS2W3 continues installing from it's GUI. Installation Diskette 7 experiences the same issue of not being recognised when inserted. + +Of note, as an unrelated issue, I was unable to save VM snapshots in QEMU 1.0 or later. + + +Thank you for a fantastic emulator. + + +cheers, +multitude \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/917 b/results/classifier/deepseek-2/output/device/917 new file mode 100644 index 000000000..d04e28010 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/917 @@ -0,0 +1,2 @@ + +FireWire Device Passthrough? diff --git a/results/classifier/deepseek-2/output/device/924 b/results/classifier/deepseek-2/output/device/924 new file mode 100644 index 000000000..53933f305 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/924 @@ -0,0 +1,2 @@ + +AHCI IRQ lost running Fedora on SBSA-ref diff --git a/results/classifier/deepseek-2/output/device/924943 b/results/classifier/deepseek-2/output/device/924943 new file mode 100644 index 000000000..569b9cf6e --- /dev/null +++ b/results/classifier/deepseek-2/output/device/924943 @@ -0,0 +1,15 @@ + +usb-host devices given by command line are routed incomplete to the guest + +affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches (older versions not tested) +affected guests: linux, windows +test hardware: standard usb key (or any other piece of USB hardware) that works perfectly when plugged in after guest bootup + +Several Sequences have been tested: +- start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -device usb-host,bus=ehci.0 +- start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S (to not start up the guest directly) + at the console prompt: "device_add usb-host" then "c" to start the guest. + +For the linux guest, I get a usb device listed and detected as /dev/sdb when plugging it in at runtime. At startup linux does NOT detect it. +For the windows guest, I get a usb device listed and detected as "removable media" when plugging it in at runtime. At startup Windows does detect "something" that is listed in the device manager as Generic Mass Storage device, but with a yellow exclamation mark and there is no removable media listed in Explorer + +If you need further testings, just let me know. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/925 b/results/classifier/deepseek-2/output/device/925 new file mode 100644 index 000000000..e242effc4 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/925 @@ -0,0 +1,19 @@ + +AArch64 SVE2 LD/ST instructions segfault on MMIO addresses +Description of problem: +During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state: +``` +(gdb) p $x17 +$1 = 0xffffffe2 +(gdb) p $z26.s.u +$2 = {0x0 <repeats 16 times>} +(gdb) p $p2 +$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0} +``` +QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device. +Additional information: +A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices. + +<details><summary>Reproducer seed for my future self</summary> +S6008340160849309262|Q|cd4t|pq|w5|lK124 +</details> diff --git a/results/classifier/deepseek-2/output/device/932487 b/results/classifier/deepseek-2/output/device/932487 new file mode 100644 index 000000000..3400aa4e3 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/932487 @@ -0,0 +1,57 @@ + +win32: git rev 59f971d crashes when accessing disk (coroutine issue) + +Host: XP SP3 / Vista SP2 + +configure commandline: ./configure --target-list="i386-softmmu" --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable-linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags="-O0 -pipe" + +gcc -v: +Using built-in specs. +Target: mingw32 +Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' +Thread model: win32 +gcc version 4.3.3 (4.3.3-tdm-1 mingw32) + +gdb output: +C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk +GNU gdb (GDB) 7.3 +Copyright (C) 2011 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "mingw32". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +done. +(gdb) r +Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk +[New Thread 2472.0x8e0] +[New Thread 2472.0xdc4] +[New Thread 2472.0x8f0] + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 2472.0x8f0] +0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +(gdb) bt +#0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +#1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, + action=COROUTINE_YIELD) at coroutine-win32.c:48 +#2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) + at qemu-coroutine.c:31 +#3 0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>, + buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335 +#4 0x00486e39 in ide_sector_read (s=0x1bbdaa0) + at C:/msys/home/User/qemu/hw/ide/core.c:480 +#5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7, + width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 +#6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32) + at C:/msys/home/User/qemu/ioport.c:211 +#7 0x005496cf in ioport_write (data=<optimized out>, + address=<optimized out>, index=<optimized out>) + at C:/msys/home/User/qemu/ioport.c:82 +#8 cpu_outb (addr=2147340288, val=0 '\000') + at C:/msys/home/User/qemu/ioport.c:274 +#9 0x022c0397 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/932490 b/results/classifier/deepseek-2/output/device/932490 new file mode 100644 index 000000000..3df3958b1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/932490 @@ -0,0 +1,10 @@ + +Qemu fails on -fda /dev/fd0 when no medium is present + +# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +# qemu-system-x86_64 -fda /dev/fd0 +qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No such device or address + +Starting with a medium (floppy disk) inserted, then removing or changing the medium works fine. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/933 b/results/classifier/deepseek-2/output/device/933 new file mode 100644 index 000000000..76042956f --- /dev/null +++ b/results/classifier/deepseek-2/output/device/933 @@ -0,0 +1,27 @@ + +Changing CD ROM medium sometimes fails with 'Tray of device is not open' +Description of problem: +QEMU reports that a CD ROM tray is not open when exchanging media: +`unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'ide0-1-0' is not open` + +We see the issue in upstream libvirt integration tests. However, this issue is a race and the reproducibility rate is <15%. +Steps to reproduce: +On the high level this is what we do: +1. eject medium that the machine was started with +2. insert a different medium into the CD ROM + +Translating the above to QEMU QMP commands this is what the test exercises: +1. blockdev-open-tray +2. blockdev-remove-medium +3. blockdev-del +4. blockdev-close-tray +5. blockdev-open-tray +6. blockdev-remove-medium +7. blockdev-add +8. blockdev-insert-medium <<< This is where the test fails +9. blockdev-close-tray +Additional information: +I bisected the code (3 times just to be sure since it's a race) and the following commit fell out of it: +55adb3c45620c31f29978f209e2a44a08d34e2da + +I'm attaching QEMU trace events and a bunch of libvirt test logs (good and bad for comparison). If you think of anything else I should provide in order to help with the issue analysis, please let me know what other option should be turned on.[qemu_traces.tar.gz](/uploads/32e48c92efce3484e552df063795af4d/qemu_traces.tar.gz) diff --git a/results/classifier/deepseek-2/output/device/938552 b/results/classifier/deepseek-2/output/device/938552 new file mode 100644 index 000000000..e5f732438 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/938552 @@ -0,0 +1,24 @@ + +ENH: Inherit ptys, useful output from -serial pty + +When controlling a qemu instance from another program, it'd be very useful to be able to have qemu inherit pseudo-tty file descriptors so they could just be specified on the command line. + +It's possible to allocate a pty pair in the master program before forking and exec'ing qemu and have qemu use that pty, but it's a bit painful. The master program must call ptsname(...) on the fd of the slave side and insert the path to the pty device node into qemu's command line. This doesn't work well in many scripting languages which lack a ptsname() call; a Linux-specific hack like readlink() of /proc/self/fd/[slave-fd] is necessary. + +If qemu accepted file descriptors for serial I/O this would all be a lot more flexible, and it wouldn't be limited to ptys either. Just accept a new format for "-serial" like "-serial fd:7" and have the parent program not set that FD to close-on-exec. + +None of this would be as necessary if qemu's "-serial pty" option was fully functional. Unfortunately, it doesn't provide any information to associate the created PTY(s) with their qemu devices, so it's hard to know which serial port is which, which the monitor device is, etc. See, eg: + +$ qemu -serial pty -serial pty -monitor pty +char device redirected to /dev/pts/6 +char device redirected to /dev/pts/7 +char device redirected to /dev/pts/8 + +... which is which? Are they allocated in the order they're specified on the command line? Nope, because /dev/pts/6 is the monitor in this case. With more than one device using "pty" a lot of guesswork is involved. + +If you're using "-monitor stdio" you can issue an "info chardev" and parse that to find out what everything else is connected to, but this shouldn't really be necessary. Ideally the device names would be printed when a port is redirected to a pty, eg: + +$ qemu -serial pty -serial pty -monitor pty +char device compat_monitor0 redirected to /dev/pts/6 +char device serial0 redirected to /dev/pts/7 +char device serial1 redirected to /dev/pts/8 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/940 b/results/classifier/deepseek-2/output/device/940 new file mode 100644 index 000000000..bdf7122dd --- /dev/null +++ b/results/classifier/deepseek-2/output/device/940 @@ -0,0 +1,2 @@ + +"analyze-migration.py -m" does not appear to account for the pci-hole diff --git a/results/classifier/deepseek-2/output/device/941 b/results/classifier/deepseek-2/output/device/941 new file mode 100644 index 000000000..dbaff0f97 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/941 @@ -0,0 +1,42 @@ + +qemu-img cannot repair a qcow2 in an LV because size is mis-detected when qcow2 is on an LV +Description of problem: +This is RHEV with Tb's of VMs which need to be repaired due to a datacenter-wide (the real datacenter) power outage. + +Each of these VMs are on individual LVs but qemu-img check fails to perform repairs: + + +``` +ERROR cluster 24481205 refcount=0 reference=1 +ERROR cluster 24481206 refcount=0 reference=1 +Rebuilding refcount structure +ERROR writing refblock: No space left on device <============ +qemu-img: Check failed: No space left on device +``` + +Running qemu-img check or info on the LV (/dev/dm-*) works well but repairs cannot be completed: + +``` +# qemu-img info /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc +image: /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc +file format: qcow2 +virtual size: 1.5 TiB (1649267441664 bytes) +disk size: 0 B <================================ +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: true + refcount bits: 16 + corrupt: false + extended l2: false +``` +Steps to reproduce: +1. Have a damaged VM with its qcow2 in an LV +2. run 'qemu-img check <device>' verify that it properly detects the blocks which need fixing. +3. run 'qemu-img check -r all <device>', it exits with 'no space left on device´ after a few seconds. +Additional information: +https://bugzilla.redhat.com/show_bug.cgi?id=1519071 + + +Here is one example: diff --git a/results/classifier/deepseek-2/output/device/946043 b/results/classifier/deepseek-2/output/device/946043 new file mode 100644 index 000000000..42568d4e2 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/946043 @@ -0,0 +1,13 @@ + +Serial Named Pipe Unrecognized Windows 7 + +I created a named pipe serial hardware and supplied '/tmp/debug' which I created using mkfifo + +This is the snippet from ps -aux +-chardev pipe,id=charserial0,path=/tmp/debug -device isa-serial,chardev=charserial0,id=serial0 + +failure@ubuntu1:~$ ls -al /tmp/debug* +prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug +prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug.in + +However inside the Windows 7 guest (even after a restart) nothing is recognized. Even after going through the add legacy hardware motions it's still not picked up. \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/955 b/results/classifier/deepseek-2/output/device/955 new file mode 100644 index 000000000..37db0d955 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/955 @@ -0,0 +1,2 @@ + +support multiple UARTs in qemu-riscv-virt by default diff --git a/results/classifier/deepseek-2/output/device/959992 b/results/classifier/deepseek-2/output/device/959992 new file mode 100644 index 000000000..327560846 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/959992 @@ -0,0 +1,44 @@ + +segfault in apic_report_irq_delivered when booting tinycore_3.3.iso + +it git head (33cf629) sometimes it segfaults in apic_report_irq_delivered() and backtrace is looping in apic_update_irq(#3-#4) + +Log: +C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -cdrom tinycore_3.3.iso +GNU gdb (GDB) 7.3 +Copyright (C) 2011 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "mingw32". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +done. +(gdb) r +Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -cdrom tinycore_3.3.iso +[New Thread 9012.0x2348] +[New Thread 9012.0x2860] +[New Thread 9012.0x2b64] + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 9012.0x2b64] +0x0053cde8 in apic_report_irq_delivered (delivered=0) + at C:/msys/home/User/qemu/hw/apic_common.c:110 +110 { +(gdb) bt +#0 0x0053cde8 in apic_report_irq_delivered (delivered=0) + at C:/msys/home/User/qemu/hw/apic_common.c:110 +#1 0x0053b9eb in apic_set_irq (s=0x1d7aff8, vector_num=<optimized out>, + trigger_mode=0) at C:/msys/home/User/qemu/hw/apic.c:390 +#2 0x0053b990 in apic_update_irq (s=0x1d7aff8) + at C:/msys/home/User/qemu/hw/apic.c:376 +#3 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367 +#4 0x0053b990 in apic_update_irq (s=0x1d7aff8) + at C:/msys/home/User/qemu/hw/apic.c:376 +#5 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367 +#6 0x0053b990 in apic_update_irq (s=0x1d7aff8) + at C:/msys/home/User/qemu/hw/apic.c:376 +#7 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367 +... \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/960378 b/results/classifier/deepseek-2/output/device/960378 new file mode 100644 index 000000000..7213b8fa6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/960378 @@ -0,0 +1,46 @@ + +OSX 10.7 build failure + +qemu-1.0.1 +./configure --cc=/usr/bin/gcc --disable-darwin-user --disable-bsd-user --disable-guest-agent + + + + + CC bitops.o + CC migration-exec.o + CC migration-unix.o + CC migration-fd.o + CC audio/audio.o + CC audio/noaudio.o + CC audio/wavaudio.o + CC audio/mixeng.o + CC audio/coreaudio.o +audio/coreaudio.c: In function ‘isPlaying’: +audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c: In function ‘coreaudio_init_out’: +audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270) +audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) +audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) +audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419) +audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) +audio/coreaudio.c: In function ‘coreaudio_fini_out’: +audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) + CC audio/wavcapture.o + CC ui/keymaps.o + OBJC ui/cocoa.o +In file included from /System/Library/Frameworks/Security.framework/Headers/Security.h:24, + from /System/Library/Frameworks/Foundation.framework/Headers/NSURLCredential.h:9, + from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:70, + from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, + from ui/cocoa.m:25: +/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:73: error: conflicting types for ‘uint16’ +/Users/marty/extern/qemu-1.0.1/fpu/softfloat.h:60: error: previous declaration of ‘uint16’ was here +ui/cocoa.m: In function ‘-[QemuCocoaAppController applicationDidFinishLaunching:]’: +ui/cocoa.m:773: warning: ‘beginSheetForDirectory:file:types:modalForWindow:modalDelegate:didEndSelector:contextInfo:’ is deprecated (declared at /System/Library/Frameworks/AppKit.framework/Headers/NSOpenPanel.h:49) +ui/cocoa.m: In function ‘-[QemuCocoaAppController openPanelDidEnd:returnCode:contextInfo:]’: +ui/cocoa.m:810: warning: ‘filename’ is deprecated (declared at /System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:276) +make: *** [ui/cocoa.o] Error 1 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/961757 b/results/classifier/deepseek-2/output/device/961757 new file mode 100644 index 000000000..5f694a4bc --- /dev/null +++ b/results/classifier/deepseek-2/output/device/961757 @@ -0,0 +1,20 @@ + +wrong error for blockdev-snapshot-sync + +From Laszlo Ersek: + +>> + proto_drv = bdrv_find_protocol(snapshot_file); +>> if (!proto_drv) { +>> - qerror_report(QERR_INVALID_BLOCK_FORMAT, format); +>> - ret = -1; +>> - goto out; +>> + error_set(errp, QERR_INVALID_BLOCK_FORMAT, format); +>> + return; +>> } +> +> I don't understand the logic here (based on the error message). We +> specified "format" for the case when a completely new snapshot file has +> to be created. If the file exists already, then bdrv_find_protocol() +> tries to find the driver for it. If that fails, then we must report an +> error indeed, but instead of referring to "format", we'd have to report +> the "scheme" from the beginning of "snapshot_file". \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/965 b/results/classifier/deepseek-2/output/device/965 new file mode 100644 index 000000000..3b89ff4c6 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/965 @@ -0,0 +1,2 @@ + +Creating a NVME disk using qemu in the Host not in the VM diff --git a/results/classifier/deepseek-2/output/device/97 b/results/classifier/deepseek-2/output/device/97 new file mode 100644 index 000000000..e152c09e7 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/97 @@ -0,0 +1,2 @@ + +-serial tcp should hang up when DTR goes low diff --git a/results/classifier/deepseek-2/output/device/972 b/results/classifier/deepseek-2/output/device/972 new file mode 100644 index 000000000..6563d09ae --- /dev/null +++ b/results/classifier/deepseek-2/output/device/972 @@ -0,0 +1,2 @@ + +LSI SCSI Use After Free (CVE-2022-0216) diff --git a/results/classifier/deepseek-2/output/device/98 b/results/classifier/deepseek-2/output/device/98 new file mode 100644 index 000000000..ac4293ce9 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/98 @@ -0,0 +1,2 @@ + +Curses Keyboard Broken On OS X diff --git a/results/classifier/deepseek-2/output/device/990 b/results/classifier/deepseek-2/output/device/990 new file mode 100644 index 000000000..93f234c04 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/990 @@ -0,0 +1,2 @@ + +support for vIOMMU and vSR-IOV together in L1 as virtual machine diff --git a/results/classifier/deepseek-2/output/device/990364 b/results/classifier/deepseek-2/output/device/990364 new file mode 100644 index 000000000..9792fe36c --- /dev/null +++ b/results/classifier/deepseek-2/output/device/990364 @@ -0,0 +1,19 @@ + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +Hello! I have: + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +on config: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" + +with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +qemu drivers are virtio-win-0.1-22.iso +kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +qemu 0.12.3+noroms-0ubuntu9.18 \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/device/997 b/results/classifier/deepseek-2/output/device/997 new file mode 100644 index 000000000..19130d2b1 --- /dev/null +++ b/results/classifier/deepseek-2/output/device/997 @@ -0,0 +1,18 @@ + +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) |