diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
| commit | d0c85e36e4de67af628d54e9ab577cc3fad7796a (patch) | |
| tree | f8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/deepseek-2-tmp/output/device | |
| parent | 7f4364274750eb8cb39a3e7493132fca1c01232e (diff) | |
| download | emulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz emulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip | |
add deepseek and gemma results
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/device')
698 files changed, 0 insertions, 15915 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/device/1004050 b/results/classifier/deepseek-2-tmp/output/device/1004050 deleted file mode 100644 index a0e0bb8c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1004050 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1013241 b/results/classifier/deepseek-2-tmp/output/device/1013241 deleted file mode 100644 index 6756f0cc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1013241 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1013691 b/results/classifier/deepseek-2-tmp/output/device/1013691 deleted file mode 100644 index 6f4668f9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1013691 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1014099 b/results/classifier/deepseek-2-tmp/output/device/1014099 deleted file mode 100644 index 98979f07..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1014099 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1014681 b/results/classifier/deepseek-2-tmp/output/device/1014681 deleted file mode 100644 index 7ac3964f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1014681 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1015 b/results/classifier/deepseek-2-tmp/output/device/1015 deleted file mode 100644 index be3717b1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1015 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu-7.0 there is no device "hostdev0" defined diff --git a/results/classifier/deepseek-2-tmp/output/device/1018 b/results/classifier/deepseek-2-tmp/output/device/1018 deleted file mode 100644 index 8635b71f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1018 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/1026176 b/results/classifier/deepseek-2-tmp/output/device/1026176 deleted file mode 100644 index c163b695..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1026176 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/1031955 b/results/classifier/deepseek-2-tmp/output/device/1031955 deleted file mode 100644 index 3b05d428..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1031955 +++ /dev/null @@ -1,36 +0,0 @@ - -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-tmp/output/device/1038136 b/results/classifier/deepseek-2-tmp/output/device/1038136 deleted file mode 100644 index 5b7c2a1f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1038136 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1047470 b/results/classifier/deepseek-2-tmp/output/device/1047470 deleted file mode 100644 index 07d46bef..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1047470 +++ /dev/null @@ -1,60 +0,0 @@ - -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-tmp/output/device/1049 b/results/classifier/deepseek-2-tmp/output/device/1049 deleted file mode 100644 index ede7a14e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1049 +++ /dev/null @@ -1,2 +0,0 @@ - -Have DeviceRealize return boolean indicating error diff --git a/results/classifier/deepseek-2-tmp/output/device/1055090 b/results/classifier/deepseek-2-tmp/output/device/1055090 deleted file mode 100644 index e5f057db..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1055090 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/1062220 b/results/classifier/deepseek-2-tmp/output/device/1062220 deleted file mode 100644 index 1eded393..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1062220 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1070762 b/results/classifier/deepseek-2-tmp/output/device/1070762 deleted file mode 100644 index 46c7d622..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1070762 +++ /dev/null @@ -1,38 +0,0 @@ - -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-tmp/output/device/1071 b/results/classifier/deepseek-2-tmp/output/device/1071 deleted file mode 100644 index 70d6fdaa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1071 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1073952 b/results/classifier/deepseek-2-tmp/output/device/1073952 deleted file mode 100644 index dc633607..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1073952 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1076 b/results/classifier/deepseek-2-tmp/output/device/1076 deleted file mode 100644 index 0dc6f6da..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1076 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1077708 b/results/classifier/deepseek-2-tmp/output/device/1077708 deleted file mode 100644 index 5aeafd5a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1077708 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1077838 b/results/classifier/deepseek-2-tmp/output/device/1077838 deleted file mode 100644 index 2655ad11..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1077838 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1086782 b/results/classifier/deepseek-2-tmp/output/device/1086782 deleted file mode 100644 index e09b850c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1086782 +++ /dev/null @@ -1,85 +0,0 @@ - -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-tmp/output/device/1087114 b/results/classifier/deepseek-2-tmp/output/device/1087114 deleted file mode 100644 index cc26b603..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1087114 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/1088617 b/results/classifier/deepseek-2-tmp/output/device/1088617 deleted file mode 100644 index 6100a9f2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1088617 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1089006 b/results/classifier/deepseek-2-tmp/output/device/1089006 deleted file mode 100644 index 15b39558..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1089006 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1090 b/results/classifier/deepseek-2-tmp/output/device/1090 deleted file mode 100644 index 94d1dae6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1090 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1090558 b/results/classifier/deepseek-2-tmp/output/device/1090558 deleted file mode 100644 index 24c36816..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1090558 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1090604 b/results/classifier/deepseek-2-tmp/output/device/1090604 deleted file mode 100644 index a92ab6da..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1090604 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1093360 b/results/classifier/deepseek-2-tmp/output/device/1093360 deleted file mode 100644 index 9167dc55..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1093360 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1096713 b/results/classifier/deepseek-2-tmp/output/device/1096713 deleted file mode 100644 index 297d78c4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1096713 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1096714 b/results/classifier/deepseek-2-tmp/output/device/1096714 deleted file mode 100644 index 18650b12..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1096714 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1101210 b/results/classifier/deepseek-2-tmp/output/device/1101210 deleted file mode 100644 index 25d39406..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1101210 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1106 b/results/classifier/deepseek-2-tmp/output/device/1106 deleted file mode 100644 index f2335918..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1106 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1110 b/results/classifier/deepseek-2-tmp/output/device/1110 deleted file mode 100644 index 319b3f77..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1110 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1112 b/results/classifier/deepseek-2-tmp/output/device/1112 deleted file mode 100644 index 4247c522..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1112 +++ /dev/null @@ -1,2 +0,0 @@ - -Heap-overflow in scsi_disk_emulate_write_same diff --git a/results/classifier/deepseek-2-tmp/output/device/112 b/results/classifier/deepseek-2-tmp/output/device/112 deleted file mode 100644 index fc225b7a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/112 +++ /dev/null @@ -1,2 +0,0 @@ - -setting unsupported timeout for i6300esb watchdog causes hw reset diff --git a/results/classifier/deepseek-2-tmp/output/device/1134 b/results/classifier/deepseek-2-tmp/output/device/1134 deleted file mode 100644 index ec3e9136..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1134 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1139 b/results/classifier/deepseek-2-tmp/output/device/1139 deleted file mode 100644 index 4a0c9a6f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1139 +++ /dev/null @@ -1,79 +0,0 @@ - -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-tmp/output/device/1162227 b/results/classifier/deepseek-2-tmp/output/device/1162227 deleted file mode 100644 index 6a030f02..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1162227 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1162644 b/results/classifier/deepseek-2-tmp/output/device/1162644 deleted file mode 100644 index 6f611f37..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1162644 +++ /dev/null @@ -1,91 +0,0 @@ - -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-tmp/output/device/1168 b/results/classifier/deepseek-2-tmp/output/device/1168 deleted file mode 100644 index 1f5c37a1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1168 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1173490 b/results/classifier/deepseek-2-tmp/output/device/1173490 deleted file mode 100644 index 5ea58f0d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1173490 +++ /dev/null @@ -1,21 +0,0 @@ - -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-tmp/output/device/1174 b/results/classifier/deepseek-2-tmp/output/device/1174 deleted file mode 100644 index dc783fac..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1174 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1175 b/results/classifier/deepseek-2-tmp/output/device/1175 deleted file mode 100644 index f3c73441..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1175 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1175513 b/results/classifier/deepseek-2-tmp/output/device/1175513 deleted file mode 100644 index e8557ccd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1175513 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1176 b/results/classifier/deepseek-2-tmp/output/device/1176 deleted file mode 100644 index 749fb33e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1176 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/118 b/results/classifier/deepseek-2-tmp/output/device/118 deleted file mode 100644 index e50eb4e1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/118 +++ /dev/null @@ -1,2 +0,0 @@ - -USB device 1.1 not correctly passedthru from Linux host to Windows guest diff --git a/results/classifier/deepseek-2-tmp/output/device/1181796 b/results/classifier/deepseek-2-tmp/output/device/1181796 deleted file mode 100644 index 09e59666..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1181796 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1185888 b/results/classifier/deepseek-2-tmp/output/device/1185888 deleted file mode 100644 index 30ada1ea..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1185888 +++ /dev/null @@ -1,26 +0,0 @@ - --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-tmp/output/device/1186303 b/results/classifier/deepseek-2-tmp/output/device/1186303 deleted file mode 100644 index 3f329d01..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1186303 +++ /dev/null @@ -1,23 +0,0 @@ - -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-tmp/output/device/1187529 b/results/classifier/deepseek-2-tmp/output/device/1187529 deleted file mode 100644 index 065f91fb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1187529 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1188018 b/results/classifier/deepseek-2-tmp/output/device/1188018 deleted file mode 100644 index e2e0c573..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1188018 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1188991 b/results/classifier/deepseek-2-tmp/output/device/1188991 deleted file mode 100644 index 7b8c79df..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1188991 +++ /dev/null @@ -1,61 +0,0 @@ - -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-tmp/output/device/1191 b/results/classifier/deepseek-2-tmp/output/device/1191 deleted file mode 100644 index c13787af..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1191 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1191326 b/results/classifier/deepseek-2-tmp/output/device/1191326 deleted file mode 100644 index 1d941c08..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1191326 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1193 b/results/classifier/deepseek-2-tmp/output/device/1193 deleted file mode 100644 index f560436b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1193 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1194954 b/results/classifier/deepseek-2-tmp/output/device/1194954 deleted file mode 100644 index 8ca7e71e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1194954 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1196145 b/results/classifier/deepseek-2-tmp/output/device/1196145 deleted file mode 100644 index 45db9129..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1196145 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1198350 b/results/classifier/deepseek-2-tmp/output/device/1198350 deleted file mode 100644 index 3a0bbd63..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1198350 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/1200212 b/results/classifier/deepseek-2-tmp/output/device/1200212 deleted file mode 100644 index 8393ea51..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1200212 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1207228 b/results/classifier/deepseek-2-tmp/output/device/1207228 deleted file mode 100644 index 876f0945..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1207228 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1219234 b/results/classifier/deepseek-2-tmp/output/device/1219234 deleted file mode 100644 index 0d3e6bd4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1219234 +++ /dev/null @@ -1,15 +0,0 @@ - --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-tmp/output/device/1220 b/results/classifier/deepseek-2-tmp/output/device/1220 deleted file mode 100644 index 0c7c9d8a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1220 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1222034 b/results/classifier/deepseek-2-tmp/output/device/1222034 deleted file mode 100644 index 6d84b913..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1222034 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1223467 b/results/classifier/deepseek-2-tmp/output/device/1223467 deleted file mode 100644 index 68730f60..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1223467 +++ /dev/null @@ -1,23 +0,0 @@ - -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-tmp/output/device/1223477 b/results/classifier/deepseek-2-tmp/output/device/1223477 deleted file mode 100644 index 48b1cf6c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1223477 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1225187 b/results/classifier/deepseek-2-tmp/output/device/1225187 deleted file mode 100644 index 37eeface..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1225187 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1226 b/results/classifier/deepseek-2-tmp/output/device/1226 deleted file mode 100644 index 94e0b377..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1226 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1230232 b/results/classifier/deepseek-2-tmp/output/device/1230232 deleted file mode 100644 index 5b4b461f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1230232 +++ /dev/null @@ -1,34 +0,0 @@ - -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-tmp/output/device/1234 b/results/classifier/deepseek-2-tmp/output/device/1234 deleted file mode 100644 index c7351fcd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1234 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1237 b/results/classifier/deepseek-2-tmp/output/device/1237 deleted file mode 100644 index 5ccfd4df..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1237 +++ /dev/null @@ -1,2 +0,0 @@ - -after OS upgrade usb-redir connection broken during migration and qemu-kvm: terminating on signal 15 diff --git a/results/classifier/deepseek-2-tmp/output/device/1237625 b/results/classifier/deepseek-2-tmp/output/device/1237625 deleted file mode 100644 index 9ff3d040..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1237625 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/1242765 b/results/classifier/deepseek-2-tmp/output/device/1242765 deleted file mode 100644 index 2431ee92..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1242765 +++ /dev/null @@ -1,70 +0,0 @@ - -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-tmp/output/device/1248469 b/results/classifier/deepseek-2-tmp/output/device/1248469 deleted file mode 100644 index 8a37a402..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1248469 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1250 b/results/classifier/deepseek-2-tmp/output/device/1250 deleted file mode 100644 index fe78e6c8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1250 +++ /dev/null @@ -1,4 +0,0 @@ - -[RFE] on windows, attach any storport disk directly, not just physicaldrives -Additional information: - diff --git a/results/classifier/deepseek-2-tmp/output/device/1256122 b/results/classifier/deepseek-2-tmp/output/device/1256122 deleted file mode 100644 index 175f4434..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1256122 +++ /dev/null @@ -1,23 +0,0 @@ - -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-tmp/output/device/1257334 b/results/classifier/deepseek-2-tmp/output/device/1257334 deleted file mode 100644 index 463091c2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1257334 +++ /dev/null @@ -1,4 +0,0 @@ - -diffuse handling of image creation from another path - -see attachement! \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/device/1267520 b/results/classifier/deepseek-2-tmp/output/device/1267520 deleted file mode 100644 index 2ba4176a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1267520 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1268596 b/results/classifier/deepseek-2-tmp/output/device/1268596 deleted file mode 100644 index 65182294..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1268596 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1268671 b/results/classifier/deepseek-2-tmp/output/device/1268671 deleted file mode 100644 index 3d0ec29e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1268671 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/1269628 b/results/classifier/deepseek-2-tmp/output/device/1269628 deleted file mode 100644 index e7a6eb85..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1269628 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1276879 b/results/classifier/deepseek-2-tmp/output/device/1276879 deleted file mode 100644 index c8c1dbb9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1276879 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1280521 b/results/classifier/deepseek-2-tmp/output/device/1280521 deleted file mode 100644 index dac9c108..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1280521 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1284874 b/results/classifier/deepseek-2-tmp/output/device/1284874 deleted file mode 100644 index 480cd0b6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1284874 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1288 b/results/classifier/deepseek-2-tmp/output/device/1288 deleted file mode 100644 index 37ac4c0d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1288 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1292037 b/results/classifier/deepseek-2-tmp/output/device/1292037 deleted file mode 100644 index 8dca5543..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1292037 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1294 b/results/classifier/deepseek-2-tmp/output/device/1294 deleted file mode 100644 index 64ba4532..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1294 +++ /dev/null @@ -1,2 +0,0 @@ - -pflash size check appears to be incompatible with OVMF on x86 diff --git a/results/classifier/deepseek-2-tmp/output/device/1295587 b/results/classifier/deepseek-2-tmp/output/device/1295587 deleted file mode 100644 index 38d78147..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1295587 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1300 b/results/classifier/deepseek-2-tmp/output/device/1300 deleted file mode 100644 index 69ba1438..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1300 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1306818 b/results/classifier/deepseek-2-tmp/output/device/1306818 deleted file mode 100644 index d18ff66a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1306818 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/1307281 b/results/classifier/deepseek-2-tmp/output/device/1307281 deleted file mode 100644 index 2ba6a7d8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1307281 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1311 b/results/classifier/deepseek-2-tmp/output/device/1311 deleted file mode 100644 index eacffe78..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1311 +++ /dev/null @@ -1,2 +0,0 @@ - -riscv-qemu can't record interrupt diff --git a/results/classifier/deepseek-2-tmp/output/device/1314857 b/results/classifier/deepseek-2-tmp/output/device/1314857 deleted file mode 100644 index bc359352..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1314857 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1318 b/results/classifier/deepseek-2-tmp/output/device/1318 deleted file mode 100644 index 7581c440..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1318 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1320360 b/results/classifier/deepseek-2-tmp/output/device/1320360 deleted file mode 100644 index 9db58e31..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1320360 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1321684 b/results/classifier/deepseek-2-tmp/output/device/1321684 deleted file mode 100644 index 2d8ecb84..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1321684 +++ /dev/null @@ -1,47 +0,0 @@ - -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-tmp/output/device/133 b/results/classifier/deepseek-2-tmp/output/device/133 deleted file mode 100644 index e2b3e6e9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/133 +++ /dev/null @@ -1,2 +0,0 @@ - -Chardev websocket might not support pasting more than a few chars diff --git a/results/classifier/deepseek-2-tmp/output/device/1333216 b/results/classifier/deepseek-2-tmp/output/device/1333216 deleted file mode 100644 index 50206197..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1333216 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/1334397 b/results/classifier/deepseek-2-tmp/output/device/1334397 deleted file mode 100644 index 349d8fa1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1334397 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1336123 b/results/classifier/deepseek-2-tmp/output/device/1336123 deleted file mode 100644 index 86bbfff7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1336123 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1338957 b/results/classifier/deepseek-2-tmp/output/device/1338957 deleted file mode 100644 index e7eff4ef..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1338957 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1342 b/results/classifier/deepseek-2-tmp/output/device/1342 deleted file mode 100644 index 7af9e044..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1342 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1352179 b/results/classifier/deepseek-2-tmp/output/device/1352179 deleted file mode 100644 index 71163466..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1352179 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1352465 b/results/classifier/deepseek-2-tmp/output/device/1352465 deleted file mode 100644 index b746158f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1352465 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1353456 b/results/classifier/deepseek-2-tmp/output/device/1353456 deleted file mode 100644 index 71edaee3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1353456 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1354 b/results/classifier/deepseek-2-tmp/output/device/1354 deleted file mode 100644 index d812fdaf..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1354 +++ /dev/null @@ -1,2 +0,0 @@ - --device usb-tablet not working on android guest. diff --git a/results/classifier/deepseek-2-tmp/output/device/1354279 b/results/classifier/deepseek-2-tmp/output/device/1354279 deleted file mode 100644 index 10fb8631..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1354279 +++ /dev/null @@ -1,53 +0,0 @@ - -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-tmp/output/device/1356 b/results/classifier/deepseek-2-tmp/output/device/1356 deleted file mode 100644 index dae7eacb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1356 +++ /dev/null @@ -1,18 +0,0 @@ - -"-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-tmp/output/device/1366 b/results/classifier/deepseek-2-tmp/output/device/1366 deleted file mode 100644 index 322ee709..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1366 +++ /dev/null @@ -1,85 +0,0 @@ - -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-tmp/output/device/1367365 b/results/classifier/deepseek-2-tmp/output/device/1367365 deleted file mode 100644 index 22b30a8b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1367365 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1368178 b/results/classifier/deepseek-2-tmp/output/device/1368178 deleted file mode 100644 index 278cfc5a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1368178 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1368204 b/results/classifier/deepseek-2-tmp/output/device/1368204 deleted file mode 100644 index ff183e09..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1368204 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1373362 b/results/classifier/deepseek-2-tmp/output/device/1373362 deleted file mode 100644 index 38a3991b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1373362 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1378407 b/results/classifier/deepseek-2-tmp/output/device/1378407 deleted file mode 100644 index c6acf687..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1378407 +++ /dev/null @@ -1,6 +0,0 @@ - -[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-tmp/output/device/1380 b/results/classifier/deepseek-2-tmp/output/device/1380 deleted file mode 100644 index 6b889d7c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1380 +++ /dev/null @@ -1,5 +0,0 @@ - -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-tmp/output/device/1381879 b/results/classifier/deepseek-2-tmp/output/device/1381879 deleted file mode 100644 index 56fc25aa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1381879 +++ /dev/null @@ -1,34 +0,0 @@ - -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-tmp/output/device/1386478 b/results/classifier/deepseek-2-tmp/output/device/1386478 deleted file mode 100644 index a0ef5c74..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1386478 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1390520 b/results/classifier/deepseek-2-tmp/output/device/1390520 deleted file mode 100644 index de9d0591..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1390520 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1391 b/results/classifier/deepseek-2-tmp/output/device/1391 deleted file mode 100644 index 6dbfe010..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1391 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1392 b/results/classifier/deepseek-2-tmp/output/device/1392 deleted file mode 100644 index 75609cde..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1392 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1392504 b/results/classifier/deepseek-2-tmp/output/device/1392504 deleted file mode 100644 index 08867cb5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1392504 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1393 b/results/classifier/deepseek-2-tmp/output/device/1393 deleted file mode 100644 index 85cd7cb3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1393 +++ /dev/null @@ -1,66 +0,0 @@ - -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-tmp/output/device/1393440 b/results/classifier/deepseek-2-tmp/output/device/1393440 deleted file mode 100644 index c642e0cc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1393440 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1399943 b/results/classifier/deepseek-2-tmp/output/device/1399943 deleted file mode 100644 index 1e8cf2c6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1399943 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1403 b/results/classifier/deepseek-2-tmp/output/device/1403 deleted file mode 100644 index 3732da14..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1403 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu 7.2: test-io-channel-command fails sporadically diff --git a/results/classifier/deepseek-2-tmp/output/device/1404 b/results/classifier/deepseek-2-tmp/output/device/1404 deleted file mode 100644 index 8209ea85..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1404 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1404610 b/results/classifier/deepseek-2-tmp/output/device/1404610 deleted file mode 100644 index ff555bbc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1404610 +++ /dev/null @@ -1,12 +0,0 @@ - -[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-tmp/output/device/1407454 b/results/classifier/deepseek-2-tmp/output/device/1407454 deleted file mode 100644 index afd5e534..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1407454 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1407808 b/results/classifier/deepseek-2-tmp/output/device/1407808 deleted file mode 100644 index f855ee5e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1407808 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1413 b/results/classifier/deepseek-2-tmp/output/device/1413 deleted file mode 100644 index e910af28..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1413 +++ /dev/null @@ -1,23 +0,0 @@ - -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-tmp/output/device/1422285 b/results/classifier/deepseek-2-tmp/output/device/1422285 deleted file mode 100644 index 4caf6dad..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1422285 +++ /dev/null @@ -1,55 +0,0 @@ - -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-tmp/output/device/1423668 b/results/classifier/deepseek-2-tmp/output/device/1423668 deleted file mode 100644 index 38d493c0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1423668 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1426593 b/results/classifier/deepseek-2-tmp/output/device/1426593 deleted file mode 100644 index 4876e796..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1426593 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1428958 b/results/classifier/deepseek-2-tmp/output/device/1428958 deleted file mode 100644 index 60dce689..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1428958 +++ /dev/null @@ -1,66 +0,0 @@ - -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-tmp/output/device/143 b/results/classifier/deepseek-2-tmp/output/device/143 deleted file mode 100644 index 63010496..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/143 +++ /dev/null @@ -1,2 +0,0 @@ - -xhci HCIVERSION register read emulation incorrectly handled diff --git a/results/classifier/deepseek-2-tmp/output/device/1435973 b/results/classifier/deepseek-2-tmp/output/device/1435973 deleted file mode 100644 index 3e0a8a27..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1435973 +++ /dev/null @@ -1,61 +0,0 @@ - -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-tmp/output/device/1437970 b/results/classifier/deepseek-2-tmp/output/device/1437970 deleted file mode 100644 index da497c22..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1437970 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/144 b/results/classifier/deepseek-2-tmp/output/device/144 deleted file mode 100644 index 21388e8e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/144 +++ /dev/null @@ -1,2 +0,0 @@ - -Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up diff --git a/results/classifier/deepseek-2-tmp/output/device/1440843 b/results/classifier/deepseek-2-tmp/output/device/1440843 deleted file mode 100644 index 17b3eba2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1440843 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1442 b/results/classifier/deepseek-2-tmp/output/device/1442 deleted file mode 100644 index ebffc707..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1442 +++ /dev/null @@ -1,2 +0,0 @@ - -RISC-V qemu, get cpu tick diff --git a/results/classifier/deepseek-2-tmp/output/device/1445633 b/results/classifier/deepseek-2-tmp/output/device/1445633 deleted file mode 100644 index 7a24462f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1445633 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1451 b/results/classifier/deepseek-2-tmp/output/device/1451 deleted file mode 100644 index 879b366a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1451 +++ /dev/null @@ -1,2 +0,0 @@ - -Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed. diff --git a/results/classifier/deepseek-2-tmp/output/device/1453025 b/results/classifier/deepseek-2-tmp/output/device/1453025 deleted file mode 100644 index 426d65b0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1453025 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1457 b/results/classifier/deepseek-2-tmp/output/device/1457 deleted file mode 100644 index 19cbbd91..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1457 +++ /dev/null @@ -1,2 +0,0 @@ - -ide: assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. diff --git a/results/classifier/deepseek-2-tmp/output/device/1458 b/results/classifier/deepseek-2-tmp/output/device/1458 deleted file mode 100644 index 899edb3b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1458 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1460 b/results/classifier/deepseek-2-tmp/output/device/1460 deleted file mode 100644 index dcf6aea3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1460 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1465 b/results/classifier/deepseek-2-tmp/output/device/1465 deleted file mode 100644 index 73617f41..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1465 +++ /dev/null @@ -1,2 +0,0 @@ - -MBR/Partition table corruption/loss , probably related to virtual sata disks and backup diff --git a/results/classifier/deepseek-2-tmp/output/device/1468 b/results/classifier/deepseek-2-tmp/output/device/1468 deleted file mode 100644 index 792e37a2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1468 +++ /dev/null @@ -1,7 +0,0 @@ - -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-tmp/output/device/147 b/results/classifier/deepseek-2-tmp/output/device/147 deleted file mode 100644 index 1ba41df5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/147 +++ /dev/null @@ -1,2 +0,0 @@ - -Interacting with NetBSD serial console boot blocks no longer works diff --git a/results/classifier/deepseek-2-tmp/output/device/1470536 b/results/classifier/deepseek-2-tmp/output/device/1470536 deleted file mode 100644 index 26cd71c5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1470536 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1476183 b/results/classifier/deepseek-2-tmp/output/device/1476183 deleted file mode 100644 index ee693c08..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1476183 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1481750 b/results/classifier/deepseek-2-tmp/output/device/1481750 deleted file mode 100644 index 9029b3f9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1481750 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1483 b/results/classifier/deepseek-2-tmp/output/device/1483 deleted file mode 100644 index 33219fd2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1483 +++ /dev/null @@ -1,2 +0,0 @@ - -Failed to mount pmem device in qemu diff --git a/results/classifier/deepseek-2-tmp/output/device/1486768 b/results/classifier/deepseek-2-tmp/output/device/1486768 deleted file mode 100644 index 89266637..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1486768 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1488363 b/results/classifier/deepseek-2-tmp/output/device/1488363 deleted file mode 100644 index c62957e8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1488363 +++ /dev/null @@ -1,54 +0,0 @@ - -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-tmp/output/device/1490 b/results/classifier/deepseek-2-tmp/output/device/1490 deleted file mode 100644 index a5f4493e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1490 +++ /dev/null @@ -1,62 +0,0 @@ - -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-tmp/output/device/1490886 b/results/classifier/deepseek-2-tmp/output/device/1490886 deleted file mode 100644 index f5161294..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1490886 +++ /dev/null @@ -1,33 +0,0 @@ - -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-tmp/output/device/1499908 b/results/classifier/deepseek-2-tmp/output/device/1499908 deleted file mode 100644 index 4558c42b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1499908 +++ /dev/null @@ -1,56 +0,0 @@ - -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-tmp/output/device/1500175 b/results/classifier/deepseek-2-tmp/output/device/1500175 deleted file mode 100644 index 1d964fd2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1500175 +++ /dev/null @@ -1,38 +0,0 @@ - -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-tmp/output/device/1502613 b/results/classifier/deepseek-2-tmp/output/device/1502613 deleted file mode 100644 index a6295628..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1502613 +++ /dev/null @@ -1,8 +0,0 @@ - -[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-tmp/output/device/1504 b/results/classifier/deepseek-2-tmp/output/device/1504 deleted file mode 100644 index 62f69d28..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1504 +++ /dev/null @@ -1,2 +0,0 @@ - -Implement Synopsys DesignWare PCI-I2C adapter model diff --git a/results/classifier/deepseek-2-tmp/output/device/1509336 b/results/classifier/deepseek-2-tmp/output/device/1509336 deleted file mode 100644 index cd1ac79c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1509336 +++ /dev/null @@ -1,54 +0,0 @@ - -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-tmp/output/device/1511887 b/results/classifier/deepseek-2-tmp/output/device/1511887 deleted file mode 100644 index 70478d92..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1511887 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1518969 b/results/classifier/deepseek-2-tmp/output/device/1518969 deleted file mode 100644 index b1a630a1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1518969 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1519 b/results/classifier/deepseek-2-tmp/output/device/1519 deleted file mode 100644 index f5a8e2f9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1519 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1521 b/results/classifier/deepseek-2-tmp/output/device/1521 deleted file mode 100644 index bb83f38e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1521 +++ /dev/null @@ -1,2 +0,0 @@ - -USB HID not using the keycodemapdb and thus lacking new entries diff --git a/results/classifier/deepseek-2-tmp/output/device/1522 b/results/classifier/deepseek-2-tmp/output/device/1522 deleted file mode 100644 index 94003634..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1522 +++ /dev/null @@ -1,41 +0,0 @@ - -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-tmp/output/device/1523246 b/results/classifier/deepseek-2-tmp/output/device/1523246 deleted file mode 100644 index 0918f4fd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1523246 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1526 b/results/classifier/deepseek-2-tmp/output/device/1526 deleted file mode 100644 index fd608d38..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1526 +++ /dev/null @@ -1,2 +0,0 @@ - -hw/vfio/trace-events incorrect format diff --git a/results/classifier/deepseek-2-tmp/output/device/1529449 b/results/classifier/deepseek-2-tmp/output/device/1529449 deleted file mode 100644 index 78dd37ea..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1529449 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1529859 b/results/classifier/deepseek-2-tmp/output/device/1529859 deleted file mode 100644 index 38d0dea0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1529859 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/1530035 b/results/classifier/deepseek-2-tmp/output/device/1530035 deleted file mode 100644 index 785ce5ee..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1530035 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/1530278 b/results/classifier/deepseek-2-tmp/output/device/1530278 deleted file mode 100644 index 3b2fce91..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1530278 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1543057 b/results/classifier/deepseek-2-tmp/output/device/1543057 deleted file mode 100644 index 1ac4a892..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1543057 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1544524 b/results/classifier/deepseek-2-tmp/output/device/1544524 deleted file mode 100644 index 5166298a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1544524 +++ /dev/null @@ -1,23 +0,0 @@ - -"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-tmp/output/device/1550743 b/results/classifier/deepseek-2-tmp/output/device/1550743 deleted file mode 100644 index c2d819b4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1550743 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1563 b/results/classifier/deepseek-2-tmp/output/device/1563 deleted file mode 100644 index d6b8bee8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1563 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1568621 b/results/classifier/deepseek-2-tmp/output/device/1568621 deleted file mode 100644 index 7b96ff35..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1568621 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1569 b/results/classifier/deepseek-2-tmp/output/device/1569 deleted file mode 100644 index 4cbcf1bb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1569 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/157 b/results/classifier/deepseek-2-tmp/output/device/157 deleted file mode 100644 index 0031d62b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/157 +++ /dev/null @@ -1,2 +0,0 @@ - -Xbox One controller USB passthrough disconnections and stops diff --git a/results/classifier/deepseek-2-tmp/output/device/1572959 b/results/classifier/deepseek-2-tmp/output/device/1572959 deleted file mode 100644 index 284e7470..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1572959 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1575561 b/results/classifier/deepseek-2-tmp/output/device/1575561 deleted file mode 100644 index a2b9c2ac..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1575561 +++ /dev/null @@ -1,7 +0,0 @@ - -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-tmp/output/device/1576 b/results/classifier/deepseek-2-tmp/output/device/1576 deleted file mode 100644 index 831118dc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1576 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1576347 b/results/classifier/deepseek-2-tmp/output/device/1576347 deleted file mode 100644 index 33697e39..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1576347 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1577 b/results/classifier/deepseek-2-tmp/output/device/1577 deleted file mode 100644 index 5bad6187..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1577 +++ /dev/null @@ -1,85 +0,0 @@ - -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-tmp/output/device/1579306 b/results/classifier/deepseek-2-tmp/output/device/1579306 deleted file mode 100644 index f362925f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1579306 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1579645 b/results/classifier/deepseek-2-tmp/output/device/1579645 deleted file mode 100644 index 225cee38..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1579645 +++ /dev/null @@ -1,13 +0,0 @@ - - [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-tmp/output/device/158 b/results/classifier/deepseek-2-tmp/output/device/158 deleted file mode 100644 index ea354971..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/158 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu system emulator crashed when using xhci usb controller diff --git a/results/classifier/deepseek-2-tmp/output/device/1580459 b/results/classifier/deepseek-2-tmp/output/device/1580459 deleted file mode 100644 index b1b3dccf..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1580459 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1580586 b/results/classifier/deepseek-2-tmp/output/device/1580586 deleted file mode 100644 index 9ee90a15..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1580586 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1581308 b/results/classifier/deepseek-2-tmp/output/device/1581308 deleted file mode 100644 index 7fd95c23..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1581308 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1583 b/results/classifier/deepseek-2-tmp/output/device/1583 deleted file mode 100644 index 02675e09..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1583 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1583421 b/results/classifier/deepseek-2-tmp/output/device/1583421 deleted file mode 100644 index 152ea168..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1583421 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1585433 b/results/classifier/deepseek-2-tmp/output/device/1585433 deleted file mode 100644 index 9ec7006d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1585433 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1585971 b/results/classifier/deepseek-2-tmp/output/device/1585971 deleted file mode 100644 index c0857bb1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1585971 +++ /dev/null @@ -1,21 +0,0 @@ - -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-tmp/output/device/1586611 b/results/classifier/deepseek-2-tmp/output/device/1586611 deleted file mode 100644 index bad3d5bf..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1586611 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1586613 b/results/classifier/deepseek-2-tmp/output/device/1586613 deleted file mode 100644 index 395e2f0a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1586613 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1587065 b/results/classifier/deepseek-2-tmp/output/device/1587065 deleted file mode 100644 index 18b6ac44..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1587065 +++ /dev/null @@ -1,51 +0,0 @@ - -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-tmp/output/device/1587970 b/results/classifier/deepseek-2-tmp/output/device/1587970 deleted file mode 100644 index ff2dc2c7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1587970 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1592336 b/results/classifier/deepseek-2-tmp/output/device/1592336 deleted file mode 100644 index 3620f745..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1592336 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1596832 b/results/classifier/deepseek-2-tmp/output/device/1596832 deleted file mode 100644 index e2d4858f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1596832 +++ /dev/null @@ -1,56 +0,0 @@ - -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-tmp/output/device/1597 b/results/classifier/deepseek-2-tmp/output/device/1597 deleted file mode 100644 index 937f2248..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1597 +++ /dev/null @@ -1,57 +0,0 @@ - -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-tmp/output/device/1598 b/results/classifier/deepseek-2-tmp/output/device/1598 deleted file mode 100644 index 8a7e6734..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1598 +++ /dev/null @@ -1,59 +0,0 @@ - -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-tmp/output/device/1600563 b/results/classifier/deepseek-2-tmp/output/device/1600563 deleted file mode 100644 index 3eda2d38..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1600563 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1603693 b/results/classifier/deepseek-2-tmp/output/device/1603693 deleted file mode 100644 index de99632a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1603693 +++ /dev/null @@ -1,78 +0,0 @@ - -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-tmp/output/device/1603779 b/results/classifier/deepseek-2-tmp/output/device/1603779 deleted file mode 100644 index cc91da43..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1603779 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1608802 b/results/classifier/deepseek-2-tmp/output/device/1608802 deleted file mode 100644 index 3fbfeace..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1608802 +++ /dev/null @@ -1,50 +0,0 @@ - -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-tmp/output/device/1614 b/results/classifier/deepseek-2-tmp/output/device/1614 deleted file mode 100644 index 1d1d04f1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1614 +++ /dev/null @@ -1,2 +0,0 @@ - -Add option to chardev pty for setting a named link to the allocated pty diff --git a/results/classifier/deepseek-2-tmp/output/device/1618265 b/results/classifier/deepseek-2-tmp/output/device/1618265 deleted file mode 100644 index 30c20389..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1618265 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1618431 b/results/classifier/deepseek-2-tmp/output/device/1618431 deleted file mode 100644 index 52065e0a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1618431 +++ /dev/null @@ -1,66 +0,0 @@ - -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-tmp/output/device/1622582 b/results/classifier/deepseek-2-tmp/output/device/1622582 deleted file mode 100644 index c5665da1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1622582 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/1623998 b/results/classifier/deepseek-2-tmp/output/device/1623998 deleted file mode 100644 index b6f578a2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1623998 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1624726 b/results/classifier/deepseek-2-tmp/output/device/1624726 deleted file mode 100644 index 02a46c7a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1624726 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/1625 b/results/classifier/deepseek-2-tmp/output/device/1625 deleted file mode 100644 index ce5a8cef..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1625 +++ /dev/null @@ -1,14 +0,0 @@ - -[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-tmp/output/device/1625216 b/results/classifier/deepseek-2-tmp/output/device/1625216 deleted file mode 100644 index 5bf49f9b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1625216 +++ /dev/null @@ -1,72 +0,0 @@ - -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-tmp/output/device/1626207 b/results/classifier/deepseek-2-tmp/output/device/1626207 deleted file mode 100644 index 567050e5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1626207 +++ /dev/null @@ -1,46 +0,0 @@ - --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-tmp/output/device/1630723 b/results/classifier/deepseek-2-tmp/output/device/1630723 deleted file mode 100644 index 5bcb0bc7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1630723 +++ /dev/null @@ -1,7 +0,0 @@ - -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-tmp/output/device/1634069 b/results/classifier/deepseek-2-tmp/output/device/1634069 deleted file mode 100644 index a690ea2c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1634069 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1637693 b/results/classifier/deepseek-2-tmp/output/device/1637693 deleted file mode 100644 index d26c0915..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1637693 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1637974 b/results/classifier/deepseek-2-tmp/output/device/1637974 deleted file mode 100644 index f13403fb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1637974 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/1639322 b/results/classifier/deepseek-2-tmp/output/device/1639322 deleted file mode 100644 index e993a75e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1639322 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1639791 b/results/classifier/deepseek-2-tmp/output/device/1639791 deleted file mode 100644 index 25bb8b59..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1639791 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/1639983 b/results/classifier/deepseek-2-tmp/output/device/1639983 deleted file mode 100644 index 793c7577..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1639983 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/1643342 b/results/classifier/deepseek-2-tmp/output/device/1643342 deleted file mode 100644 index 899cbbcc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1643342 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1645 b/results/classifier/deepseek-2-tmp/output/device/1645 deleted file mode 100644 index 9a347a06..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1645 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1646 b/results/classifier/deepseek-2-tmp/output/device/1646 deleted file mode 100644 index 30003bb0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1646 +++ /dev/null @@ -1,62 +0,0 @@ - -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-tmp/output/device/1646610 b/results/classifier/deepseek-2-tmp/output/device/1646610 deleted file mode 100644 index 5df7101e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1646610 +++ /dev/null @@ -1,71 +0,0 @@ - -"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-tmp/output/device/1648726 b/results/classifier/deepseek-2-tmp/output/device/1648726 deleted file mode 100644 index 1ff27d8d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1648726 +++ /dev/null @@ -1,21 +0,0 @@ - -[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-tmp/output/device/1654 b/results/classifier/deepseek-2-tmp/output/device/1654 deleted file mode 100644 index 77d43a00..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1654 +++ /dev/null @@ -1,82 +0,0 @@ - -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-tmp/output/device/1656234 b/results/classifier/deepseek-2-tmp/output/device/1656234 deleted file mode 100644 index 6cdbf633..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1656234 +++ /dev/null @@ -1,38 +0,0 @@ - -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-tmp/output/device/1658506 b/results/classifier/deepseek-2-tmp/output/device/1658506 deleted file mode 100644 index a82e9585..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1658506 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1661758 b/results/classifier/deepseek-2-tmp/output/device/1661758 deleted file mode 100644 index 194baf3b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1661758 +++ /dev/null @@ -1,118 +0,0 @@ - -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-tmp/output/device/1667613 b/results/classifier/deepseek-2-tmp/output/device/1667613 deleted file mode 100644 index 87740b06..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1667613 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1674114 b/results/classifier/deepseek-2-tmp/output/device/1674114 deleted file mode 100644 index 503ead4e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1674114 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1675332 b/results/classifier/deepseek-2-tmp/output/device/1675332 deleted file mode 100644 index 5179b4cc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1675332 +++ /dev/null @@ -1,4 +0,0 @@ - -qemu-system crashes when use sheepdog driver - -Already solved. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/device/1675333 b/results/classifier/deepseek-2-tmp/output/device/1675333 deleted file mode 100644 index 5179b4cc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1675333 +++ /dev/null @@ -1,4 +0,0 @@ - -qemu-system crashes when use sheepdog driver - -Already solved. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/device/1677247 b/results/classifier/deepseek-2-tmp/output/device/1677247 deleted file mode 100644 index aefd4f58..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1677247 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1677492 b/results/classifier/deepseek-2-tmp/output/device/1677492 deleted file mode 100644 index 3b2ddbe1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1677492 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1680679 b/results/classifier/deepseek-2-tmp/output/device/1680679 deleted file mode 100644 index 46640b1f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1680679 +++ /dev/null @@ -1,80 +0,0 @@ - -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-tmp/output/device/1681398 b/results/classifier/deepseek-2-tmp/output/device/1681398 deleted file mode 100644 index 1f1a714c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1681398 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1681404 b/results/classifier/deepseek-2-tmp/output/device/1681404 deleted file mode 100644 index f03da661..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1681404 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1681439 b/results/classifier/deepseek-2-tmp/output/device/1681439 deleted file mode 100644 index 64123f5d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1681439 +++ /dev/null @@ -1,36 +0,0 @@ - -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-tmp/output/device/1681688 b/results/classifier/deepseek-2-tmp/output/device/1681688 deleted file mode 100644 index 428bc19b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1681688 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1688231 b/results/classifier/deepseek-2-tmp/output/device/1688231 deleted file mode 100644 index 662873c0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1688231 +++ /dev/null @@ -1,32 +0,0 @@ - -[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-tmp/output/device/1689003 b/results/classifier/deepseek-2-tmp/output/device/1689003 deleted file mode 100644 index 87b4d3e3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1689003 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1691 b/results/classifier/deepseek-2-tmp/output/device/1691 deleted file mode 100644 index d7f21336..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1691 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1691379 b/results/classifier/deepseek-2-tmp/output/device/1691379 deleted file mode 100644 index 45589310..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1691379 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/1693050 b/results/classifier/deepseek-2-tmp/output/device/1693050 deleted file mode 100644 index 218c3231..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1693050 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1699628 b/results/classifier/deepseek-2-tmp/output/device/1699628 deleted file mode 100644 index 5993d9da..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1699628 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1702621 b/results/classifier/deepseek-2-tmp/output/device/1702621 deleted file mode 100644 index d4915bb0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1702621 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1706058 b/results/classifier/deepseek-2-tmp/output/device/1706058 deleted file mode 100644 index f45431e7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1706058 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1707587 b/results/classifier/deepseek-2-tmp/output/device/1707587 deleted file mode 100644 index 62a9e7d0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1707587 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1708551 b/results/classifier/deepseek-2-tmp/output/device/1708551 deleted file mode 100644 index acf6b942..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1708551 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1713 b/results/classifier/deepseek-2-tmp/output/device/1713 deleted file mode 100644 index 67c25a0e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1713 +++ /dev/null @@ -1,41 +0,0 @@ - -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-tmp/output/device/1714538 b/results/classifier/deepseek-2-tmp/output/device/1714538 deleted file mode 100644 index ae24fdf6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1714538 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1715296 b/results/classifier/deepseek-2-tmp/output/device/1715296 deleted file mode 100644 index 82deb662..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1715296 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1716132 b/results/classifier/deepseek-2-tmp/output/device/1716132 deleted file mode 100644 index f38fb908..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1716132 +++ /dev/null @@ -1,21 +0,0 @@ - -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-tmp/output/device/1718118 b/results/classifier/deepseek-2-tmp/output/device/1718118 deleted file mode 100644 index 2ef3107b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1718118 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1719689 b/results/classifier/deepseek-2-tmp/output/device/1719689 deleted file mode 100644 index 7bcc4926..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1719689 +++ /dev/null @@ -1,15 +0,0 @@ - -[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-tmp/output/device/1720971 b/results/classifier/deepseek-2-tmp/output/device/1720971 deleted file mode 100644 index 3d89ec32..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1720971 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1721187 b/results/classifier/deepseek-2-tmp/output/device/1721187 deleted file mode 100644 index 19f3dc71..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1721187 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1721222 b/results/classifier/deepseek-2-tmp/output/device/1721222 deleted file mode 100644 index ef0b0775..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1721222 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1721224 b/results/classifier/deepseek-2-tmp/output/device/1721224 deleted file mode 100644 index 78cb184f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1721224 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1722857 b/results/classifier/deepseek-2-tmp/output/device/1722857 deleted file mode 100644 index 4c4b08a5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1722857 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1731 b/results/classifier/deepseek-2-tmp/output/device/1731 deleted file mode 100644 index c0453f3d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1731 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1731347 b/results/classifier/deepseek-2-tmp/output/device/1731347 deleted file mode 100644 index 1d3fafd6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1731347 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1731588 b/results/classifier/deepseek-2-tmp/output/device/1731588 deleted file mode 100644 index 0c9cf616..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1731588 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1733720 b/results/classifier/deepseek-2-tmp/output/device/1733720 deleted file mode 100644 index 1b9faada..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1733720 +++ /dev/null @@ -1,56 +0,0 @@ - -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-tmp/output/device/1736376 b/results/classifier/deepseek-2-tmp/output/device/1736376 deleted file mode 100644 index 0e626a2d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1736376 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1740887 b/results/classifier/deepseek-2-tmp/output/device/1740887 deleted file mode 100644 index 5a37f744..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1740887 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1743191 b/results/classifier/deepseek-2-tmp/output/device/1743191 deleted file mode 100644 index a38739fb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1743191 +++ /dev/null @@ -1,42 +0,0 @@ - -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-tmp/output/device/1743337 b/results/classifier/deepseek-2-tmp/output/device/1743337 deleted file mode 100644 index afe1e8ab..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1743337 +++ /dev/null @@ -1,5 +0,0 @@ - -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-tmp/output/device/1744654 b/results/classifier/deepseek-2-tmp/output/device/1744654 deleted file mode 100644 index fb19f9b4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1744654 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1745354 b/results/classifier/deepseek-2-tmp/output/device/1745354 deleted file mode 100644 index 0277c7e4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1745354 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1746 b/results/classifier/deepseek-2-tmp/output/device/1746 deleted file mode 100644 index f68b5d18..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1746 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1747056 b/results/classifier/deepseek-2-tmp/output/device/1747056 deleted file mode 100644 index 55a830b3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1747056 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1747393 b/results/classifier/deepseek-2-tmp/output/device/1747393 deleted file mode 100644 index 2986c7f2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1747393 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1748434 b/results/classifier/deepseek-2-tmp/output/device/1748434 deleted file mode 100644 index b24760c7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1748434 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1749223 b/results/classifier/deepseek-2-tmp/output/device/1749223 deleted file mode 100644 index d852bc28..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1749223 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1753 b/results/classifier/deepseek-2-tmp/output/device/1753 deleted file mode 100644 index b1032dff..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1753 +++ /dev/null @@ -1,4 +0,0 @@ - -Does the qemu have luks2 support? -Description of problem: -Does the qemu have luks2 support? diff --git a/results/classifier/deepseek-2-tmp/output/device/1753186 b/results/classifier/deepseek-2-tmp/output/device/1753186 deleted file mode 100644 index 21c60b05..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1753186 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1753309 b/results/classifier/deepseek-2-tmp/output/device/1753309 deleted file mode 100644 index fefb82a6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1753309 +++ /dev/null @@ -1,57 +0,0 @@ - -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-tmp/output/device/1753314 b/results/classifier/deepseek-2-tmp/output/device/1753314 deleted file mode 100644 index e596ef8c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1753314 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1754 b/results/classifier/deepseek-2-tmp/output/device/1754 deleted file mode 100644 index 4e6bf0e1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1754 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1756728 b/results/classifier/deepseek-2-tmp/output/device/1756728 deleted file mode 100644 index c32f374d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1756728 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1759 b/results/classifier/deepseek-2-tmp/output/device/1759 deleted file mode 100644 index a511548e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1759 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1759338 b/results/classifier/deepseek-2-tmp/output/device/1759338 deleted file mode 100644 index 1c5fccc8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1759338 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/1759492 b/results/classifier/deepseek-2-tmp/output/device/1759492 deleted file mode 100644 index f5c0e734..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1759492 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1759522 b/results/classifier/deepseek-2-tmp/output/device/1759522 deleted file mode 100644 index f148216f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1759522 +++ /dev/null @@ -1,57 +0,0 @@ - -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-tmp/output/device/176 b/results/classifier/deepseek-2-tmp/output/device/176 deleted file mode 100644 index 0994c005..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/176 +++ /dev/null @@ -1,2 +0,0 @@ - -virtual machine cpu soft lockup when qemu attach disk diff --git a/results/classifier/deepseek-2-tmp/output/device/1760176 b/results/classifier/deepseek-2-tmp/output/device/1760176 deleted file mode 100644 index 2655675a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1760176 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1760262 b/results/classifier/deepseek-2-tmp/output/device/1760262 deleted file mode 100644 index 5a5bd43c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1760262 +++ /dev/null @@ -1,32 +0,0 @@ - -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-tmp/output/device/1761798 b/results/classifier/deepseek-2-tmp/output/device/1761798 deleted file mode 100644 index a55aad84..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1761798 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1762707 b/results/classifier/deepseek-2-tmp/output/device/1762707 deleted file mode 100644 index 1e608b42..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1762707 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1764 b/results/classifier/deepseek-2-tmp/output/device/1764 deleted file mode 100644 index d3d7a0df..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1764 +++ /dev/null @@ -1,2 +0,0 @@ - -lsusb fails with qemu-system-x86_64 command (qemu-system-x86 package) diff --git a/results/classifier/deepseek-2-tmp/output/device/1766904 b/results/classifier/deepseek-2-tmp/output/device/1766904 deleted file mode 100644 index 7def98be..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1766904 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/1767 b/results/classifier/deepseek-2-tmp/output/device/1767 deleted file mode 100644 index cb1bc0fb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1767 +++ /dev/null @@ -1,4 +0,0 @@ - -Add iphone emulated device -Additional information: - diff --git a/results/classifier/deepseek-2-tmp/output/device/1767200 b/results/classifier/deepseek-2-tmp/output/device/1767200 deleted file mode 100644 index 04a7e8e2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1767200 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1769067 b/results/classifier/deepseek-2-tmp/output/device/1769067 deleted file mode 100644 index 8336e398..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1769067 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1769189 b/results/classifier/deepseek-2-tmp/output/device/1769189 deleted file mode 100644 index 4e4dfc5e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1769189 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1771042 b/results/classifier/deepseek-2-tmp/output/device/1771042 deleted file mode 100644 index f659fd8e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1771042 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1772075 b/results/classifier/deepseek-2-tmp/output/device/1772075 deleted file mode 100644 index 219327ef..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1772075 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1772086 b/results/classifier/deepseek-2-tmp/output/device/1772086 deleted file mode 100644 index 1ad95bc0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1772086 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1777232 b/results/classifier/deepseek-2-tmp/output/device/1777232 deleted file mode 100644 index 186fbd8f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1777232 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1777235 b/results/classifier/deepseek-2-tmp/output/device/1777235 deleted file mode 100644 index 8d23de14..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1777235 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1777315 b/results/classifier/deepseek-2-tmp/output/device/1777315 deleted file mode 100644 index a0c325f8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1777315 +++ /dev/null @@ -1,73 +0,0 @@ - -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-tmp/output/device/1777777 b/results/classifier/deepseek-2-tmp/output/device/1777777 deleted file mode 100644 index 46c891ba..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1777777 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1779017 b/results/classifier/deepseek-2-tmp/output/device/1779017 deleted file mode 100644 index 9fadf1a3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1779017 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/1779120 b/results/classifier/deepseek-2-tmp/output/device/1779120 deleted file mode 100644 index c4c34abb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1779120 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1782107 b/results/classifier/deepseek-2-tmp/output/device/1782107 deleted file mode 100644 index 8969181b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1782107 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1785972 b/results/classifier/deepseek-2-tmp/output/device/1785972 deleted file mode 100644 index 62e32a0b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1785972 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/1786343 b/results/classifier/deepseek-2-tmp/output/device/1786343 deleted file mode 100644 index 29dffe10..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1786343 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/179 b/results/classifier/deepseek-2-tmp/output/device/179 deleted file mode 100644 index 27a36a64..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/179 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu guest crashes on spice client USB redirected device removal diff --git a/results/classifier/deepseek-2-tmp/output/device/1790975 b/results/classifier/deepseek-2-tmp/output/device/1790975 deleted file mode 100644 index 38214d2d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1790975 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1791947 b/results/classifier/deepseek-2-tmp/output/device/1791947 deleted file mode 100644 index 0623dc00..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1791947 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1792523 b/results/classifier/deepseek-2-tmp/output/device/1792523 deleted file mode 100644 index dc0d0fd9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1792523 +++ /dev/null @@ -1,51 +0,0 @@ - -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-tmp/output/device/1793016 b/results/classifier/deepseek-2-tmp/output/device/1793016 deleted file mode 100644 index 78607e62..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1793016 +++ /dev/null @@ -1,23 +0,0 @@ - -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-tmp/output/device/1793275 b/results/classifier/deepseek-2-tmp/output/device/1793275 deleted file mode 100644 index dcce123f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1793275 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1793635 b/results/classifier/deepseek-2-tmp/output/device/1793635 deleted file mode 100644 index 4f4782eb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1793635 +++ /dev/null @@ -1,7 +0,0 @@ - -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-tmp/output/device/1794 b/results/classifier/deepseek-2-tmp/output/device/1794 deleted file mode 100644 index 4e5d2e0f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1794 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1794187 b/results/classifier/deepseek-2-tmp/output/device/1794187 deleted file mode 100644 index 4c0097fe..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1794187 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1794202 b/results/classifier/deepseek-2-tmp/output/device/1794202 deleted file mode 100644 index 53e6f851..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1794202 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1794950 b/results/classifier/deepseek-2-tmp/output/device/1794950 deleted file mode 100644 index 86376be3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1794950 +++ /dev/null @@ -1,84 +0,0 @@ - -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-tmp/output/device/1795527 b/results/classifier/deepseek-2-tmp/output/device/1795527 deleted file mode 100644 index 451c5b4b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1795527 +++ /dev/null @@ -1,68 +0,0 @@ - -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-tmp/output/device/1798434 b/results/classifier/deepseek-2-tmp/output/device/1798434 deleted file mode 100644 index 385c454f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1798434 +++ /dev/null @@ -1,6 +0,0 @@ - -[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-tmp/output/device/1799919 b/results/classifier/deepseek-2-tmp/output/device/1799919 deleted file mode 100644 index 9e4ece28..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1799919 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1801674 b/results/classifier/deepseek-2-tmp/output/device/1801674 deleted file mode 100644 index d3b1ad82..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1801674 +++ /dev/null @@ -1,53 +0,0 @@ - -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-tmp/output/device/1806114 b/results/classifier/deepseek-2-tmp/output/device/1806114 deleted file mode 100644 index f111b7c2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1806114 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/1806824 b/results/classifier/deepseek-2-tmp/output/device/1806824 deleted file mode 100644 index 36e69954..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1806824 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1809075 b/results/classifier/deepseek-2-tmp/output/device/1809075 deleted file mode 100644 index 36f1c1d9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1809075 +++ /dev/null @@ -1,32 +0,0 @@ - -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-tmp/output/device/1809546 b/results/classifier/deepseek-2-tmp/output/device/1809546 deleted file mode 100644 index f02d9255..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1809546 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/1809665 b/results/classifier/deepseek-2-tmp/output/device/1809665 deleted file mode 100644 index a2530ec0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1809665 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1809684 b/results/classifier/deepseek-2-tmp/output/device/1809684 deleted file mode 100644 index 43387b21..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1809684 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1810975 b/results/classifier/deepseek-2-tmp/output/device/1810975 deleted file mode 100644 index 51e8e03e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1810975 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1811 b/results/classifier/deepseek-2-tmp/output/device/1811 deleted file mode 100644 index 9252b50f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1811 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/1811543 b/results/classifier/deepseek-2-tmp/output/device/1811543 deleted file mode 100644 index 5fb1811b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1811543 +++ /dev/null @@ -1,73 +0,0 @@ - -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-tmp/output/device/1811653 b/results/classifier/deepseek-2-tmp/output/device/1811653 deleted file mode 100644 index 5f93fbc9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1811653 +++ /dev/null @@ -1,42 +0,0 @@ - -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-tmp/output/device/1811758 b/results/classifier/deepseek-2-tmp/output/device/1811758 deleted file mode 100644 index 40ff7717..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1811758 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1815 b/results/classifier/deepseek-2-tmp/output/device/1815 deleted file mode 100644 index 1ce6f277..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1815 +++ /dev/null @@ -1,83 +0,0 @@ - -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-tmp/output/device/1815413 b/results/classifier/deepseek-2-tmp/output/device/1815413 deleted file mode 100644 index 4a6c130e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1815413 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1815445 b/results/classifier/deepseek-2-tmp/output/device/1815445 deleted file mode 100644 index 0d010e6c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1815445 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1815721 b/results/classifier/deepseek-2-tmp/output/device/1815721 deleted file mode 100644 index fb90cd58..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1815721 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1815993 b/results/classifier/deepseek-2-tmp/output/device/1815993 deleted file mode 100644 index 813d57bc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1815993 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/1816052 b/results/classifier/deepseek-2-tmp/output/device/1816052 deleted file mode 100644 index b37e4d61..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1816052 +++ /dev/null @@ -1,72 +0,0 @@ - -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-tmp/output/device/1816189 b/results/classifier/deepseek-2-tmp/output/device/1816189 deleted file mode 100644 index 2bb5aad8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1816189 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1816614 b/results/classifier/deepseek-2-tmp/output/device/1816614 deleted file mode 100644 index a3c87137..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1816614 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/1816805 b/results/classifier/deepseek-2-tmp/output/device/1816805 deleted file mode 100644 index 47a020d2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1816805 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1817525 b/results/classifier/deepseek-2-tmp/output/device/1817525 deleted file mode 100644 index f736b845..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1817525 +++ /dev/null @@ -1,79 +0,0 @@ - -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-tmp/output/device/182 b/results/classifier/deepseek-2-tmp/output/device/182 deleted file mode 100644 index a0683388..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/182 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu-xhci device should detect if libusb host supports streams diff --git a/results/classifier/deepseek-2-tmp/output/device/1821054 b/results/classifier/deepseek-2-tmp/output/device/1821054 deleted file mode 100644 index cfdd7762..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1821054 +++ /dev/null @@ -1,5 +0,0 @@ - -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-tmp/output/device/1823169 b/results/classifier/deepseek-2-tmp/output/device/1823169 deleted file mode 100644 index 661ba2fc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1823169 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1824744 b/results/classifier/deepseek-2-tmp/output/device/1824744 deleted file mode 100644 index 5a746ce7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1824744 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1826422 b/results/classifier/deepseek-2-tmp/output/device/1826422 deleted file mode 100644 index 250a26f8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1826422 +++ /dev/null @@ -1,50 +0,0 @@ - -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-tmp/output/device/1828272 b/results/classifier/deepseek-2-tmp/output/device/1828272 deleted file mode 100644 index 935b5a47..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1828272 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/1828508 b/results/classifier/deepseek-2-tmp/output/device/1828508 deleted file mode 100644 index 309864c6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1828508 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1829498 b/results/classifier/deepseek-2-tmp/output/device/1829498 deleted file mode 100644 index 579d9214..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1829498 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/183 b/results/classifier/deepseek-2-tmp/output/device/183 deleted file mode 100644 index d78fabed..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/183 +++ /dev/null @@ -1,2 +0,0 @@ - -Cannot use usb-host on Mac OS diff --git a/results/classifier/deepseek-2-tmp/output/device/1833661 b/results/classifier/deepseek-2-tmp/output/device/1833661 deleted file mode 100644 index cd583dcd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1833661 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1834113 b/results/classifier/deepseek-2-tmp/output/device/1834113 deleted file mode 100644 index eaa61252..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1834113 +++ /dev/null @@ -1,48 +0,0 @@ - -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-tmp/output/device/1835827 b/results/classifier/deepseek-2-tmp/output/device/1835827 deleted file mode 100644 index aa433bb4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1835827 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1836855 b/results/classifier/deepseek-2-tmp/output/device/1836855 deleted file mode 100644 index 432bc34f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1836855 +++ /dev/null @@ -1,33 +0,0 @@ - -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-tmp/output/device/1839060 b/results/classifier/deepseek-2-tmp/output/device/1839060 deleted file mode 100644 index 3fa363b5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1839060 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1839807 b/results/classifier/deepseek-2-tmp/output/device/1839807 deleted file mode 100644 index 70fe83c6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1839807 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/1842530 b/results/classifier/deepseek-2-tmp/output/device/1842530 deleted file mode 100644 index 0d3dc0cc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1842530 +++ /dev/null @@ -1,62 +0,0 @@ - -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-tmp/output/device/1842774 b/results/classifier/deepseek-2-tmp/output/device/1842774 deleted file mode 100644 index e5c8627b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1842774 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1842787 b/results/classifier/deepseek-2-tmp/output/device/1842787 deleted file mode 100644 index 1c8fe8f4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1842787 +++ /dev/null @@ -1,82 +0,0 @@ - -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-tmp/output/device/1843 b/results/classifier/deepseek-2-tmp/output/device/1843 deleted file mode 100644 index c9e2d50c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1843 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1843711 b/results/classifier/deepseek-2-tmp/output/device/1843711 deleted file mode 100644 index e23e49a1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1843711 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1845580 b/results/classifier/deepseek-2-tmp/output/device/1845580 deleted file mode 100644 index 60339603..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1845580 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1846451 b/results/classifier/deepseek-2-tmp/output/device/1846451 deleted file mode 100644 index fa423ffa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1846451 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1847793 b/results/classifier/deepseek-2-tmp/output/device/1847793 deleted file mode 100644 index c1c224e1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1847793 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/1847861 b/results/classifier/deepseek-2-tmp/output/device/1847861 deleted file mode 100644 index 99a418c2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1847861 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1848231 b/results/classifier/deepseek-2-tmp/output/device/1848231 deleted file mode 100644 index 75086ee5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1848231 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1849 b/results/classifier/deepseek-2-tmp/output/device/1849 deleted file mode 100644 index 8a7de2cc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1849 +++ /dev/null @@ -1,72 +0,0 @@ - -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-tmp/output/device/1849894 b/results/classifier/deepseek-2-tmp/output/device/1849894 deleted file mode 100644 index 9b2d7770..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1849894 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/1850570 b/results/classifier/deepseek-2-tmp/output/device/1850570 deleted file mode 100644 index 5b4e3401..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1850570 +++ /dev/null @@ -1,38 +0,0 @@ - -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-tmp/output/device/1851547 b/results/classifier/deepseek-2-tmp/output/device/1851547 deleted file mode 100644 index 087a9807..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1851547 +++ /dev/null @@ -1,21 +0,0 @@ - -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-tmp/output/device/1851552 b/results/classifier/deepseek-2-tmp/output/device/1851552 deleted file mode 100644 index e0156b97..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1851552 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1851664 b/results/classifier/deepseek-2-tmp/output/device/1851664 deleted file mode 100644 index 9a81514e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1851664 +++ /dev/null @@ -1,7 +0,0 @@ - -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-tmp/output/device/1851972 b/results/classifier/deepseek-2-tmp/output/device/1851972 deleted file mode 100644 index 4e764352..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1851972 +++ /dev/null @@ -1,60 +0,0 @@ - -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-tmp/output/device/1853898 b/results/classifier/deepseek-2-tmp/output/device/1853898 deleted file mode 100644 index 6c988405..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1853898 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1856 b/results/classifier/deepseek-2-tmp/output/device/1856 deleted file mode 100644 index abe68a33..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1856 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1856724 b/results/classifier/deepseek-2-tmp/output/device/1856724 deleted file mode 100644 index 3ab599f3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1856724 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/1856834 b/results/classifier/deepseek-2-tmp/output/device/1856834 deleted file mode 100644 index 6abf437e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1856834 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1859021 b/results/classifier/deepseek-2-tmp/output/device/1859021 deleted file mode 100644 index 3d7c0538..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1859021 +++ /dev/null @@ -1,33 +0,0 @@ - -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-tmp/output/device/1859359 b/results/classifier/deepseek-2-tmp/output/device/1859359 deleted file mode 100644 index 5def46ba..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1859359 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/1859418 b/results/classifier/deepseek-2-tmp/output/device/1859418 deleted file mode 100644 index 7f7a488b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1859418 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1859916 b/results/classifier/deepseek-2-tmp/output/device/1859916 deleted file mode 100644 index f3e28f48..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1859916 +++ /dev/null @@ -1,53 +0,0 @@ - -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-tmp/output/device/1860759 b/results/classifier/deepseek-2-tmp/output/device/1860759 deleted file mode 100644 index b0315315..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1860759 +++ /dev/null @@ -1,16 +0,0 @@ - -[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-tmp/output/device/1861692 b/results/classifier/deepseek-2-tmp/output/device/1861692 deleted file mode 100644 index f97aefbc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1861692 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1862619 b/results/classifier/deepseek-2-tmp/output/device/1862619 deleted file mode 100644 index 417e398b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1862619 +++ /dev/null @@ -1,15 +0,0 @@ - -"-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-tmp/output/device/1863333 b/results/classifier/deepseek-2-tmp/output/device/1863333 deleted file mode 100644 index 86a346db..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1863333 +++ /dev/null @@ -1,73 +0,0 @@ - -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-tmp/output/device/1863441 b/results/classifier/deepseek-2-tmp/output/device/1863441 deleted file mode 100644 index ef272748..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1863441 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/1863710 b/results/classifier/deepseek-2-tmp/output/device/1863710 deleted file mode 100644 index 9f6cce5b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1863710 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1865626 b/results/classifier/deepseek-2-tmp/output/device/1865626 deleted file mode 100644 index c323ed5e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1865626 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1866 b/results/classifier/deepseek-2-tmp/output/device/1866 deleted file mode 100644 index dbabc986..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1866 +++ /dev/null @@ -1,2 +0,0 @@ - -mips/mip64 virtio broken on master (and 8.1.0 with tcg fix) diff --git a/results/classifier/deepseek-2-tmp/output/device/1866792 b/results/classifier/deepseek-2-tmp/output/device/1866792 deleted file mode 100644 index ac69a567..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1866792 +++ /dev/null @@ -1,62 +0,0 @@ - -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-tmp/output/device/1867519 b/results/classifier/deepseek-2-tmp/output/device/1867519 deleted file mode 100644 index ba1b3fc4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1867519 +++ /dev/null @@ -1,48 +0,0 @@ - -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-tmp/output/device/1868116 b/results/classifier/deepseek-2-tmp/output/device/1868116 deleted file mode 100644 index df47d2fd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1868116 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/1868617 b/results/classifier/deepseek-2-tmp/output/device/1868617 deleted file mode 100644 index a6251231..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1868617 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1869006 b/results/classifier/deepseek-2-tmp/output/device/1869006 deleted file mode 100644 index 16af7178..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1869006 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1869426 b/results/classifier/deepseek-2-tmp/output/device/1869426 deleted file mode 100644 index 7bf48dd7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1869426 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1871270 b/results/classifier/deepseek-2-tmp/output/device/1871270 deleted file mode 100644 index 9e556c3d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1871270 +++ /dev/null @@ -1,35 +0,0 @@ - -[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-tmp/output/device/1873338 b/results/classifier/deepseek-2-tmp/output/device/1873338 deleted file mode 100644 index 172403d3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1873338 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1873769 b/results/classifier/deepseek-2-tmp/output/device/1873769 deleted file mode 100644 index 60b8c211..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1873769 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1875080 b/results/classifier/deepseek-2-tmp/output/device/1875080 deleted file mode 100644 index 12550863..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1875080 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/1877418 b/results/classifier/deepseek-2-tmp/output/device/1877418 deleted file mode 100644 index 48cadfe0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1877418 +++ /dev/null @@ -1,7 +0,0 @@ - -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-tmp/output/device/1878136 b/results/classifier/deepseek-2-tmp/output/device/1878136 deleted file mode 100644 index 59ce188c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1878136 +++ /dev/null @@ -1,45 +0,0 @@ - - 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-tmp/output/device/1878253 b/results/classifier/deepseek-2-tmp/output/device/1878253 deleted file mode 100644 index f118e5c5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1878253 +++ /dev/null @@ -1,57 +0,0 @@ - -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-tmp/output/device/1878255 b/results/classifier/deepseek-2-tmp/output/device/1878255 deleted file mode 100644 index c3ba43c5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1878255 +++ /dev/null @@ -1,39 +0,0 @@ - -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-tmp/output/device/1880 b/results/classifier/deepseek-2-tmp/output/device/1880 deleted file mode 100644 index 32ffa911..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1880 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1880424 b/results/classifier/deepseek-2-tmp/output/device/1880424 deleted file mode 100644 index 7aa5c317..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1880424 +++ /dev/null @@ -1,41 +0,0 @@ - -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-tmp/output/device/1880822 b/results/classifier/deepseek-2-tmp/output/device/1880822 deleted file mode 100644 index 85063613..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1880822 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/1881231 b/results/classifier/deepseek-2-tmp/output/device/1881231 deleted file mode 100644 index ba97c8a9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1881231 +++ /dev/null @@ -1,32 +0,0 @@ - -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-tmp/output/device/1882350 b/results/classifier/deepseek-2-tmp/output/device/1882350 deleted file mode 100644 index 55a52cb5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1882350 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/1882787 b/results/classifier/deepseek-2-tmp/output/device/1882787 deleted file mode 100644 index 7310ae0e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1882787 +++ /dev/null @@ -1,59 +0,0 @@ - -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-tmp/output/device/1883729 b/results/classifier/deepseek-2-tmp/output/device/1883729 deleted file mode 100644 index 3677507f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1883729 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1883732 b/results/classifier/deepseek-2-tmp/output/device/1883732 deleted file mode 100644 index 1cdb445a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1883732 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1883733 b/results/classifier/deepseek-2-tmp/output/device/1883733 deleted file mode 100644 index 6962952a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1883733 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1884169 b/results/classifier/deepseek-2-tmp/output/device/1884169 deleted file mode 100644 index 534de920..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1884169 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1884684 b/results/classifier/deepseek-2-tmp/output/device/1884684 deleted file mode 100644 index f46c1eb8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1884684 +++ /dev/null @@ -1,40 +0,0 @@ - -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-tmp/output/device/1884693 b/results/classifier/deepseek-2-tmp/output/device/1884693 deleted file mode 100644 index 92b47a53..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1884693 +++ /dev/null @@ -1,56 +0,0 @@ - -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-tmp/output/device/1884831 b/results/classifier/deepseek-2-tmp/output/device/1884831 deleted file mode 100644 index fa87312d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1884831 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/1885 b/results/classifier/deepseek-2-tmp/output/device/1885 deleted file mode 100644 index 8714aed3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1885 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1887641 b/results/classifier/deepseek-2-tmp/output/device/1887641 deleted file mode 100644 index 4d5b7c7d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1887641 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1887745 b/results/classifier/deepseek-2-tmp/output/device/1887745 deleted file mode 100644 index 2b164618..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1887745 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/1888417 b/results/classifier/deepseek-2-tmp/output/device/1888417 deleted file mode 100644 index ccfcea24..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1888417 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1888663 b/results/classifier/deepseek-2-tmp/output/device/1888663 deleted file mode 100644 index 76ac3647..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1888663 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1889 b/results/classifier/deepseek-2-tmp/output/device/1889 deleted file mode 100644 index 2095036d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1889 +++ /dev/null @@ -1,48 +0,0 @@ - -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-tmp/output/device/1890152 b/results/classifier/deepseek-2-tmp/output/device/1890152 deleted file mode 100644 index 28711b6b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1890152 +++ /dev/null @@ -1,56 +0,0 @@ - -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-tmp/output/device/1890311 b/results/classifier/deepseek-2-tmp/output/device/1890311 deleted file mode 100644 index d411d86f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1890311 +++ /dev/null @@ -1,51 +0,0 @@ - -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-tmp/output/device/1890333 b/results/classifier/deepseek-2-tmp/output/device/1890333 deleted file mode 100644 index f58d60e1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1890333 +++ /dev/null @@ -1,24 +0,0 @@ - -[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-tmp/output/device/1890360 b/results/classifier/deepseek-2-tmp/output/device/1890360 deleted file mode 100644 index 9e670c15..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1890360 +++ /dev/null @@ -1,71 +0,0 @@ - -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-tmp/output/device/1890775 b/results/classifier/deepseek-2-tmp/output/device/1890775 deleted file mode 100644 index f13f69e6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1890775 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1891830 b/results/classifier/deepseek-2-tmp/output/device/1891830 deleted file mode 100644 index 0c8f6e68..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1891830 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1892 b/results/classifier/deepseek-2-tmp/output/device/1892 deleted file mode 100644 index dabb94e1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1892 +++ /dev/null @@ -1,34 +0,0 @@ - -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-tmp/output/device/1892581 b/results/classifier/deepseek-2-tmp/output/device/1892581 deleted file mode 100644 index e904367e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1892581 +++ /dev/null @@ -1,43 +0,0 @@ - -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-tmp/output/device/1892761 b/results/classifier/deepseek-2-tmp/output/device/1892761 deleted file mode 100644 index ece5485a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1892761 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1893 b/results/classifier/deepseek-2-tmp/output/device/1893 deleted file mode 100644 index 941f49f1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1893 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1893634 b/results/classifier/deepseek-2-tmp/output/device/1893634 deleted file mode 100644 index b91759e7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1893634 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1894 b/results/classifier/deepseek-2-tmp/output/device/1894 deleted file mode 100644 index 7e3313df..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1894 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1894071 b/results/classifier/deepseek-2-tmp/output/device/1894071 deleted file mode 100644 index 0c87287b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1894071 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1894617 b/results/classifier/deepseek-2-tmp/output/device/1894617 deleted file mode 100644 index 635bce2c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1894617 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/1895895 b/results/classifier/deepseek-2-tmp/output/device/1895895 deleted file mode 100644 index 36db7a60..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1895895 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/1896317 b/results/classifier/deepseek-2-tmp/output/device/1896317 deleted file mode 100644 index f6105c56..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1896317 +++ /dev/null @@ -1,58 +0,0 @@ - -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-tmp/output/device/1897568 b/results/classifier/deepseek-2-tmp/output/device/1897568 deleted file mode 100644 index 1e338533..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1897568 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1897680 b/results/classifier/deepseek-2-tmp/output/device/1897680 deleted file mode 100644 index 96886bc4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1897680 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1900 b/results/classifier/deepseek-2-tmp/output/device/1900 deleted file mode 100644 index a5625f66..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1900 +++ /dev/null @@ -1,2 +0,0 @@ - -8.1.0-r1: segfault at get_zones_wp() at ../block/file-posix.c:1337 diff --git a/results/classifier/deepseek-2-tmp/output/device/1900122 b/results/classifier/deepseek-2-tmp/output/device/1900122 deleted file mode 100644 index 6efacb97..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1900122 +++ /dev/null @@ -1,111 +0,0 @@ - -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-tmp/output/device/1900918 b/results/classifier/deepseek-2-tmp/output/device/1900918 deleted file mode 100644 index a65a40ae..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1900918 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1900919 b/results/classifier/deepseek-2-tmp/output/device/1900919 deleted file mode 100644 index ce2fd9d8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1900919 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1901440 b/results/classifier/deepseek-2-tmp/output/device/1901440 deleted file mode 100644 index 8c132cf5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1901440 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1901532 b/results/classifier/deepseek-2-tmp/output/device/1901532 deleted file mode 100644 index 0f601717..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1901532 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1902306 b/results/classifier/deepseek-2-tmp/output/device/1902306 deleted file mode 100644 index d36e248e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1902306 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1903752 b/results/classifier/deepseek-2-tmp/output/device/1903752 deleted file mode 100644 index f51cc5b2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1903752 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/1904490 b/results/classifier/deepseek-2-tmp/output/device/1904490 deleted file mode 100644 index 1cdf921d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1904490 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1904652 b/results/classifier/deepseek-2-tmp/output/device/1904652 deleted file mode 100644 index 1961c42a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1904652 +++ /dev/null @@ -1,51 +0,0 @@ - -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-tmp/output/device/1905226 b/results/classifier/deepseek-2-tmp/output/device/1905226 deleted file mode 100644 index 336f9841..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1905226 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/1905297 b/results/classifier/deepseek-2-tmp/output/device/1905297 deleted file mode 100644 index 7d21a61f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1905297 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/1905444 b/results/classifier/deepseek-2-tmp/output/device/1905444 deleted file mode 100644 index 8dc62a19..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1905444 +++ /dev/null @@ -1,47 +0,0 @@ - -[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-tmp/output/device/1906155 b/results/classifier/deepseek-2-tmp/output/device/1906155 deleted file mode 100644 index 25623b61..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1906155 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1906181 b/results/classifier/deepseek-2-tmp/output/device/1906181 deleted file mode 100644 index 2c93a49f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1906181 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/1906184 b/results/classifier/deepseek-2-tmp/output/device/1906184 deleted file mode 100644 index 971a0466..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1906184 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/1906295 b/results/classifier/deepseek-2-tmp/output/device/1906295 deleted file mode 100644 index fea03b49..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1906295 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1906463 b/results/classifier/deepseek-2-tmp/output/device/1906463 deleted file mode 100644 index f0b3696a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1906463 +++ /dev/null @@ -1,19 +0,0 @@ - -"-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-tmp/output/device/1907042 b/results/classifier/deepseek-2-tmp/output/device/1907042 deleted file mode 100644 index 2b75b21d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1907042 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/1907427 b/results/classifier/deepseek-2-tmp/output/device/1907427 deleted file mode 100644 index e3960b63..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1907427 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/1907497 b/results/classifier/deepseek-2-tmp/output/device/1907497 deleted file mode 100644 index 425cf108..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1907497 +++ /dev/null @@ -1,59 +0,0 @@ - -[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-tmp/output/device/1907776 b/results/classifier/deepseek-2-tmp/output/device/1907776 deleted file mode 100644 index f1c04397..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1907776 +++ /dev/null @@ -1,21 +0,0 @@ - -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-tmp/output/device/1907926 b/results/classifier/deepseek-2-tmp/output/device/1907926 deleted file mode 100644 index 219c72da..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1907926 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1908062 b/results/classifier/deepseek-2-tmp/output/device/1908062 deleted file mode 100644 index fa6b0166..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1908062 +++ /dev/null @@ -1,73 +0,0 @@ - -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-tmp/output/device/1908450 b/results/classifier/deepseek-2-tmp/output/device/1908450 deleted file mode 100644 index 6ab43f86..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1908450 +++ /dev/null @@ -1,47 +0,0 @@ - -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-tmp/output/device/1908832 b/results/classifier/deepseek-2-tmp/output/device/1908832 deleted file mode 100644 index a12cabfd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1908832 +++ /dev/null @@ -1,63 +0,0 @@ - -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-tmp/output/device/1909261 b/results/classifier/deepseek-2-tmp/output/device/1909261 deleted file mode 100644 index 3ef357cf..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1909261 +++ /dev/null @@ -1,36 +0,0 @@ - -[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-tmp/output/device/1910586 b/results/classifier/deepseek-2-tmp/output/device/1910586 deleted file mode 100644 index 8018a01b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1910586 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/1910603 b/results/classifier/deepseek-2-tmp/output/device/1910603 deleted file mode 100644 index f524d7f9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1910603 +++ /dev/null @@ -1,45 +0,0 @@ - -[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-tmp/output/device/1911188 b/results/classifier/deepseek-2-tmp/output/device/1911188 deleted file mode 100644 index 72a2ddb5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1911188 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/1912846 b/results/classifier/deepseek-2-tmp/output/device/1912846 deleted file mode 100644 index ec91bf4c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1912846 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1912857 b/results/classifier/deepseek-2-tmp/output/device/1912857 deleted file mode 100644 index a5a19987..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1912857 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/1913344 b/results/classifier/deepseek-2-tmp/output/device/1913344 deleted file mode 100644 index 34335f88..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1913344 +++ /dev/null @@ -1,10 +0,0 @@ - - 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-tmp/output/device/1913667 b/results/classifier/deepseek-2-tmp/output/device/1913667 deleted file mode 100644 index 03f08dc2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1913667 +++ /dev/null @@ -1,37 +0,0 @@ - -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-tmp/output/device/1913917 b/results/classifier/deepseek-2-tmp/output/device/1913917 deleted file mode 100644 index 6731a4fa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1913917 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1913926 b/results/classifier/deepseek-2-tmp/output/device/1913926 deleted file mode 100644 index 219d7250..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1913926 +++ /dev/null @@ -1,30 +0,0 @@ - -[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-tmp/output/device/1914535 b/results/classifier/deepseek-2-tmp/output/device/1914535 deleted file mode 100644 index febe66ce..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1914535 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1916501 b/results/classifier/deepseek-2-tmp/output/device/1916501 deleted file mode 100644 index 8b2e5a3e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1916501 +++ /dev/null @@ -1,31 +0,0 @@ - -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-tmp/output/device/1917394 b/results/classifier/deepseek-2-tmp/output/device/1917394 deleted file mode 100644 index 919e4b2e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1917394 +++ /dev/null @@ -1,40 +0,0 @@ - -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-tmp/output/device/1920013 b/results/classifier/deepseek-2-tmp/output/device/1920013 deleted file mode 100644 index 6ce87a40..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1920013 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1921061 b/results/classifier/deepseek-2-tmp/output/device/1921061 deleted file mode 100644 index f5458463..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1921061 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/1921635 b/results/classifier/deepseek-2-tmp/output/device/1921635 deleted file mode 100644 index 081b4a05..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1921635 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/1922252 b/results/classifier/deepseek-2-tmp/output/device/1922252 deleted file mode 100644 index 876c4bc0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1922252 +++ /dev/null @@ -1,8 +0,0 @@ - -[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-tmp/output/device/1922325 b/results/classifier/deepseek-2-tmp/output/device/1922325 deleted file mode 100644 index 74cd6879..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1922325 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/1922391 b/results/classifier/deepseek-2-tmp/output/device/1922391 deleted file mode 100644 index c2166c5a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1922391 +++ /dev/null @@ -1,57 +0,0 @@ - -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-tmp/output/device/1922611 b/results/classifier/deepseek-2-tmp/output/device/1922611 deleted file mode 100644 index 4a7a9e1c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1922611 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/1923663 b/results/classifier/deepseek-2-tmp/output/device/1923663 deleted file mode 100644 index 4cdc78d4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1923663 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/1924738 b/results/classifier/deepseek-2-tmp/output/device/1924738 deleted file mode 100644 index 03e9ba15..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1924738 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/1925109 b/results/classifier/deepseek-2-tmp/output/device/1925109 deleted file mode 100644 index 3c63a884..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1925109 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/1925496 b/results/classifier/deepseek-2-tmp/output/device/1925496 deleted file mode 100644 index 9c2e8616..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1925496 +++ /dev/null @@ -1,65 +0,0 @@ - -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-tmp/output/device/1925966 b/results/classifier/deepseek-2-tmp/output/device/1925966 deleted file mode 100644 index dfdc1a83..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1925966 +++ /dev/null @@ -1,34 +0,0 @@ - -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-tmp/output/device/1926111 b/results/classifier/deepseek-2-tmp/output/device/1926111 deleted file mode 100644 index ce2fcfe9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1926111 +++ /dev/null @@ -1,86 +0,0 @@ - -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-tmp/output/device/1926231 b/results/classifier/deepseek-2-tmp/output/device/1926231 deleted file mode 100644 index e05b65fe..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1926231 +++ /dev/null @@ -1,38 +0,0 @@ - -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-tmp/output/device/1927408 b/results/classifier/deepseek-2-tmp/output/device/1927408 deleted file mode 100644 index 7c8efa81..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1927408 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/1933 b/results/classifier/deepseek-2-tmp/output/device/1933 deleted file mode 100644 index 8fbadd31..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1933 +++ /dev/null @@ -1,42 +0,0 @@ - -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-tmp/output/device/1935 b/results/classifier/deepseek-2-tmp/output/device/1935 deleted file mode 100644 index f04fb102..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1935 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/1940 b/results/classifier/deepseek-2-tmp/output/device/1940 deleted file mode 100644 index 84c91f54..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1940 +++ /dev/null @@ -1,21 +0,0 @@ - -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-tmp/output/device/1943 b/results/classifier/deepseek-2-tmp/output/device/1943 deleted file mode 100644 index ffa17b07..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1943 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/1982 b/results/classifier/deepseek-2-tmp/output/device/1982 deleted file mode 100644 index fae16127..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/1982 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/2001 b/results/classifier/deepseek-2-tmp/output/device/2001 deleted file mode 100644 index 991397d1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2001 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/2018 b/results/classifier/deepseek-2-tmp/output/device/2018 deleted file mode 100644 index ebbf18b6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2018 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/2025 b/results/classifier/deepseek-2-tmp/output/device/2025 deleted file mode 100644 index 7e98dbaa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2025 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/2031 b/results/classifier/deepseek-2-tmp/output/device/2031 deleted file mode 100644 index 42cb4285..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2031 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/2033 b/results/classifier/deepseek-2-tmp/output/device/2033 deleted file mode 100644 index fe19e7f2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2033 +++ /dev/null @@ -1,2 +0,0 @@ - -goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL diff --git a/results/classifier/deepseek-2-tmp/output/device/2046 b/results/classifier/deepseek-2-tmp/output/device/2046 deleted file mode 100644 index cf68bd13..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2046 +++ /dev/null @@ -1,2 +0,0 @@ - -live migration error : qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm diff --git a/results/classifier/deepseek-2-tmp/output/device/2049 b/results/classifier/deepseek-2-tmp/output/device/2049 deleted file mode 100644 index 35147b7d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2049 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/2061 b/results/classifier/deepseek-2-tmp/output/device/2061 deleted file mode 100644 index 45e34373..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2061 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/2075 b/results/classifier/deepseek-2-tmp/output/device/2075 deleted file mode 100644 index 8ba561f4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2075 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/2081 b/results/classifier/deepseek-2-tmp/output/device/2081 deleted file mode 100644 index 120a753a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2081 +++ /dev/null @@ -1,10 +0,0 @@ - -[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-tmp/output/device/2086 b/results/classifier/deepseek-2-tmp/output/device/2086 deleted file mode 100644 index a266a355..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2086 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/2117 b/results/classifier/deepseek-2-tmp/output/device/2117 deleted file mode 100644 index 0568f713..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2117 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/2126 b/results/classifier/deepseek-2-tmp/output/device/2126 deleted file mode 100644 index 6468eb67..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2126 +++ /dev/null @@ -1,2 +0,0 @@ - -iotest-144 sometimes fails due to minor reordering of output diff --git a/results/classifier/deepseek-2-tmp/output/device/2178 b/results/classifier/deepseek-2-tmp/output/device/2178 deleted file mode 100644 index 568a98fc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2178 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/2186 b/results/classifier/deepseek-2-tmp/output/device/2186 deleted file mode 100644 index a9372618..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2186 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/2211 b/results/classifier/deepseek-2-tmp/output/device/2211 deleted file mode 100644 index 032c6d72..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2211 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/2212 b/results/classifier/deepseek-2-tmp/output/device/2212 deleted file mode 100644 index 287836ca..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2212 +++ /dev/null @@ -1,18 +0,0 @@ - -"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-tmp/output/device/2240 b/results/classifier/deepseek-2-tmp/output/device/2240 deleted file mode 100644 index 5fd10d7a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2240 +++ /dev/null @@ -1,5 +0,0 @@ - -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-tmp/output/device/2272 b/results/classifier/deepseek-2-tmp/output/device/2272 deleted file mode 100644 index f649d55b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2272 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/2306 b/results/classifier/deepseek-2-tmp/output/device/2306 deleted file mode 100644 index b02392b7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2306 +++ /dev/null @@ -1,2 +0,0 @@ - -A bug of ptimer that the freq can't set more than 1000M diff --git a/results/classifier/deepseek-2-tmp/output/device/2308 b/results/classifier/deepseek-2-tmp/output/device/2308 deleted file mode 100644 index f576dccb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2308 +++ /dev/null @@ -1,80 +0,0 @@ - -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-tmp/output/device/2342 b/results/classifier/deepseek-2-tmp/output/device/2342 deleted file mode 100644 index 4b5f2c9b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2342 +++ /dev/null @@ -1,2 +0,0 @@ - -DEREF_OF_NULL.RET in qdev-clock.c diff --git a/results/classifier/deepseek-2-tmp/output/device/2350 b/results/classifier/deepseek-2-tmp/output/device/2350 deleted file mode 100644 index a5d625d4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2350 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/2357 b/results/classifier/deepseek-2-tmp/output/device/2357 deleted file mode 100644 index 065002d4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2357 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/2359 b/results/classifier/deepseek-2-tmp/output/device/2359 deleted file mode 100644 index f9423ad1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2359 +++ /dev/null @@ -1,33 +0,0 @@ - -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-tmp/output/device/2388 b/results/classifier/deepseek-2-tmp/output/device/2388 deleted file mode 100644 index d25c6df9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2388 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/2395 b/results/classifier/deepseek-2-tmp/output/device/2395 deleted file mode 100644 index d01430ec..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2395 +++ /dev/null @@ -1,61 +0,0 @@ - -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-tmp/output/device/2399 b/results/classifier/deepseek-2-tmp/output/device/2399 deleted file mode 100644 index 29d3271e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2399 +++ /dev/null @@ -1,28 +0,0 @@ - -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-tmp/output/device/241119 b/results/classifier/deepseek-2-tmp/output/device/241119 deleted file mode 100644 index 3e1c4a52..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/241119 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/2415 b/results/classifier/deepseek-2-tmp/output/device/2415 deleted file mode 100644 index b0fd0beb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2415 +++ /dev/null @@ -1,54 +0,0 @@ - -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-tmp/output/device/2428 b/results/classifier/deepseek-2-tmp/output/device/2428 deleted file mode 100644 index 9fd572fb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2428 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/2449 b/results/classifier/deepseek-2-tmp/output/device/2449 deleted file mode 100644 index 3bf68558..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2449 +++ /dev/null @@ -1,2 +0,0 @@ - -How to extract FIS (personal question) diff --git a/results/classifier/deepseek-2-tmp/output/device/2455 b/results/classifier/deepseek-2-tmp/output/device/2455 deleted file mode 100644 index 6babaf10..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2455 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/2471 b/results/classifier/deepseek-2-tmp/output/device/2471 deleted file mode 100644 index 73d44c91..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2471 +++ /dev/null @@ -1,2 +0,0 @@ - -error handling in of_dpa_cmd_add_acl() diff --git a/results/classifier/deepseek-2-tmp/output/device/2513 b/results/classifier/deepseek-2-tmp/output/device/2513 deleted file mode 100644 index c2668019..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2513 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/2521 b/results/classifier/deepseek-2-tmp/output/device/2521 deleted file mode 100644 index cabb294d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2521 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/2561 b/results/classifier/deepseek-2-tmp/output/device/2561 deleted file mode 100644 index e0d6a19b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2561 +++ /dev/null @@ -1,40 +0,0 @@ - -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-tmp/output/device/2576 b/results/classifier/deepseek-2-tmp/output/device/2576 deleted file mode 100644 index bc695256..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2576 +++ /dev/null @@ -1,2 +0,0 @@ - -virtio-balloon: Assertion `mrs.mr' failed. diff --git a/results/classifier/deepseek-2-tmp/output/device/259 b/results/classifier/deepseek-2-tmp/output/device/259 deleted file mode 100644 index 9a842091..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/259 +++ /dev/null @@ -1,2 +0,0 @@ - -dma_blk_cb leaks memory map handles on misaligned IO diff --git a/results/classifier/deepseek-2-tmp/output/device/2615 b/results/classifier/deepseek-2-tmp/output/device/2615 deleted file mode 100644 index f1bc8934..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2615 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/2635 b/results/classifier/deepseek-2-tmp/output/device/2635 deleted file mode 100644 index 376db2ec..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2635 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/2645 b/results/classifier/deepseek-2-tmp/output/device/2645 deleted file mode 100644 index 39e8896e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2645 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/2651 b/results/classifier/deepseek-2-tmp/output/device/2651 deleted file mode 100644 index cf847b63..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2651 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/2659 b/results/classifier/deepseek-2-tmp/output/device/2659 deleted file mode 100644 index 60e6b4e1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2659 +++ /dev/null @@ -1,2 +0,0 @@ - -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-tmp/output/device/2703 b/results/classifier/deepseek-2-tmp/output/device/2703 deleted file mode 100644 index 8e28cf7b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2703 +++ /dev/null @@ -1,41 +0,0 @@ - -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-tmp/output/device/2705 b/results/classifier/deepseek-2-tmp/output/device/2705 deleted file mode 100644 index 5a0cf932..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2705 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/2707 b/results/classifier/deepseek-2-tmp/output/device/2707 deleted file mode 100644 index fd995004..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2707 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/2714 b/results/classifier/deepseek-2-tmp/output/device/2714 deleted file mode 100644 index 8d1cf46d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2714 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/2716 b/results/classifier/deepseek-2-tmp/output/device/2716 deleted file mode 100644 index c4d96df8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2716 +++ /dev/null @@ -1,8 +0,0 @@ - -migrate incoming with fd transfer issue -Steps to reproduce: -1. -2. -3. -Additional information: -# diff --git a/results/classifier/deepseek-2-tmp/output/device/272 b/results/classifier/deepseek-2-tmp/output/device/272 deleted file mode 100644 index a022fdd5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/272 +++ /dev/null @@ -1,2 +0,0 @@ - -QEMU: block/vvfat driver issues diff --git a/results/classifier/deepseek-2-tmp/output/device/2722 b/results/classifier/deepseek-2-tmp/output/device/2722 deleted file mode 100644 index cdca55c2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2722 +++ /dev/null @@ -1,49 +0,0 @@ - -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-tmp/output/device/2732 b/results/classifier/deepseek-2-tmp/output/device/2732 deleted file mode 100644 index 1e08947f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2732 +++ /dev/null @@ -1,40 +0,0 @@ - -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-tmp/output/device/2765 b/results/classifier/deepseek-2-tmp/output/device/2765 deleted file mode 100644 index a6c26d69..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2765 +++ /dev/null @@ -1,2 +0,0 @@ - -InputMethodKit warnings on macOS Sequoia diff --git a/results/classifier/deepseek-2-tmp/output/device/2777 b/results/classifier/deepseek-2-tmp/output/device/2777 deleted file mode 100644 index d39ddb68..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2777 +++ /dev/null @@ -1,60 +0,0 @@ - -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-tmp/output/device/278 b/results/classifier/deepseek-2-tmp/output/device/278 deleted file mode 100644 index 54132784..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/278 +++ /dev/null @@ -1,2 +0,0 @@ - -jack audio dev produces no sound diff --git a/results/classifier/deepseek-2-tmp/output/device/2801 b/results/classifier/deepseek-2-tmp/output/device/2801 deleted file mode 100644 index 66739dec..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2801 +++ /dev/null @@ -1,2 +0,0 @@ - -Implement Raspberry PI Zero 2 W. diff --git a/results/classifier/deepseek-2-tmp/output/device/2805 b/results/classifier/deepseek-2-tmp/output/device/2805 deleted file mode 100644 index 4d15b9aa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2805 +++ /dev/null @@ -1,23 +0,0 @@ - -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-tmp/output/device/2843 b/results/classifier/deepseek-2-tmp/output/device/2843 deleted file mode 100644 index 34530f0a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2843 +++ /dev/null @@ -1,34 +0,0 @@ - -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-tmp/output/device/2845 b/results/classifier/deepseek-2-tmp/output/device/2845 deleted file mode 100644 index d3a69f83..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2845 +++ /dev/null @@ -1,33 +0,0 @@ - -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-tmp/output/device/2863 b/results/classifier/deepseek-2-tmp/output/device/2863 deleted file mode 100644 index fce71c26..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2863 +++ /dev/null @@ -1,2 +0,0 @@ - -Invalid read reason: rejected diff --git a/results/classifier/deepseek-2-tmp/output/device/2872 b/results/classifier/deepseek-2-tmp/output/device/2872 deleted file mode 100644 index fb1e55bc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2872 +++ /dev/null @@ -1,2 +0,0 @@ - -hw/net: Parameter 'driver' expects a pluggable device type diff --git a/results/classifier/deepseek-2-tmp/output/device/2880 b/results/classifier/deepseek-2-tmp/output/device/2880 deleted file mode 100644 index 9bdb6dc3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2880 +++ /dev/null @@ -1,4 +0,0 @@ - -how to migrate storage live for the vm with vhostuser disk -Additional information: - diff --git a/results/classifier/deepseek-2-tmp/output/device/2937 b/results/classifier/deepseek-2-tmp/output/device/2937 deleted file mode 100644 index 72696765..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2937 +++ /dev/null @@ -1,2 +0,0 @@ - -Request for Assistance: Properly Emulating USB Devices in QEMU for Custom USB Driver Testing diff --git a/results/classifier/deepseek-2-tmp/output/device/2939 b/results/classifier/deepseek-2-tmp/output/device/2939 deleted file mode 100644 index a386877c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2939 +++ /dev/null @@ -1,2 +0,0 @@ - -Add m68k board name called Macintosh llci diff --git a/results/classifier/deepseek-2-tmp/output/device/2945 b/results/classifier/deepseek-2-tmp/output/device/2945 deleted file mode 100644 index bdb7378f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2945 +++ /dev/null @@ -1,30 +0,0 @@ - -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-tmp/output/device/2947 b/results/classifier/deepseek-2-tmp/output/device/2947 deleted file mode 100644 index 272da182..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2947 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/2953 b/results/classifier/deepseek-2-tmp/output/device/2953 deleted file mode 100644 index a010d6de..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2953 +++ /dev/null @@ -1,67 +0,0 @@ - -"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-tmp/output/device/2963 b/results/classifier/deepseek-2-tmp/output/device/2963 deleted file mode 100644 index b62bbb50..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2963 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/2985 b/results/classifier/deepseek-2-tmp/output/device/2985 deleted file mode 100644 index 94f855b1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/2985 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/305 b/results/classifier/deepseek-2-tmp/output/device/305 deleted file mode 100644 index cb6c2fe6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/305 +++ /dev/null @@ -1,2 +0,0 @@ - -assertion failure in lsi53c810 emulator diff --git a/results/classifier/deepseek-2-tmp/output/device/307 b/results/classifier/deepseek-2-tmp/output/device/307 deleted file mode 100644 index f579fdc4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/307 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu may freeze during drive-mirroring on fragmented FS diff --git a/results/classifier/deepseek-2-tmp/output/device/327 b/results/classifier/deepseek-2-tmp/output/device/327 deleted file mode 100644 index dec95417..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/327 +++ /dev/null @@ -1,2 +0,0 @@ - -Storage | Two decimal digits precision diff --git a/results/classifier/deepseek-2-tmp/output/device/332 b/results/classifier/deepseek-2-tmp/output/device/332 deleted file mode 100644 index 2d4daa81..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/332 +++ /dev/null @@ -1,2 +0,0 @@ - -VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash diff --git a/results/classifier/deepseek-2-tmp/output/device/350 b/results/classifier/deepseek-2-tmp/output/device/350 deleted file mode 100644 index 32cc923e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/350 +++ /dev/null @@ -1,2 +0,0 @@ - -lsisas1068 not supported (for VMDK manipulation) diff --git a/results/classifier/deepseek-2-tmp/output/device/360 b/results/classifier/deepseek-2-tmp/output/device/360 deleted file mode 100644 index eb4719bf..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/360 +++ /dev/null @@ -1,2 +0,0 @@ - -load_helper() do_unaligned_access path doesn't return correct result with MMIO diff --git a/results/classifier/deepseek-2-tmp/output/device/388 b/results/classifier/deepseek-2-tmp/output/device/388 deleted file mode 100644 index b983d3df..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/388 +++ /dev/null @@ -1,2 +0,0 @@ - -Can not pass hw device names as alsa input and output devices diff --git a/results/classifier/deepseek-2-tmp/output/device/392 b/results/classifier/deepseek-2-tmp/output/device/392 deleted file mode 100644 index 27797eaa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/392 +++ /dev/null @@ -1,2 +0,0 @@ - -`-hda` and `-drive` differ with respect to path handling diff --git a/results/classifier/deepseek-2-tmp/output/device/399 b/results/classifier/deepseek-2-tmp/output/device/399 deleted file mode 100644 index 6556b74e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/399 +++ /dev/null @@ -1,2 +0,0 @@ - -drive-backup job hangs in a 'paused' state after unsuccessful first attempt diff --git a/results/classifier/deepseek-2-tmp/output/device/401 b/results/classifier/deepseek-2-tmp/output/device/401 deleted file mode 100644 index 47c6366c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/401 +++ /dev/null @@ -1,2 +0,0 @@ - -Wishlist: nvme-ns: allow specifying eui-64 diff --git a/results/classifier/deepseek-2-tmp/output/device/406 b/results/classifier/deepseek-2-tmp/output/device/406 deleted file mode 100644 index 0e08895f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/406 +++ /dev/null @@ -1,2 +0,0 @@ - -vhost-user net device sends SET_VRING_ENABLE before feature negotiation diff --git a/results/classifier/deepseek-2-tmp/output/device/413 b/results/classifier/deepseek-2-tmp/output/device/413 deleted file mode 100644 index 1e60a7b7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/413 +++ /dev/null @@ -1,2 +0,0 @@ - -Error handling: Audit callers of load_image_targphys, get_image_size, event_notifier_init, msix_init diff --git a/results/classifier/deepseek-2-tmp/output/device/424450 b/results/classifier/deepseek-2-tmp/output/device/424450 deleted file mode 100644 index 4b650fe9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/424450 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/433 b/results/classifier/deepseek-2-tmp/output/device/433 deleted file mode 100644 index 508f6009..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/433 +++ /dev/null @@ -1,2 +0,0 @@ - -chardev: Windows stdio eats characters diff --git a/results/classifier/deepseek-2-tmp/output/device/450 b/results/classifier/deepseek-2-tmp/output/device/450 deleted file mode 100644 index a2467243..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/450 +++ /dev/null @@ -1,2 +0,0 @@ - -sdhci: Assertion wpnum < sd->wpgrps_size failed diff --git a/results/classifier/deepseek-2-tmp/output/device/451 b/results/classifier/deepseek-2-tmp/output/device/451 deleted file mode 100644 index 7f2f5ec1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/451 +++ /dev/null @@ -1,2 +0,0 @@ - -sdhci: Heap-buffer-overflow in sdhci_read_dataport diff --git a/results/classifier/deepseek-2-tmp/output/device/455 b/results/classifier/deepseek-2-tmp/output/device/455 deleted file mode 100644 index 8ae320c4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/455 +++ /dev/null @@ -1,35 +0,0 @@ - -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-tmp/output/device/462 b/results/classifier/deepseek-2-tmp/output/device/462 deleted file mode 100644 index 15f21b1b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/462 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/464 b/results/classifier/deepseek-2-tmp/output/device/464 deleted file mode 100644 index 683788ed..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/464 +++ /dev/null @@ -1,2 +0,0 @@ - -The virtio disk shows offline when try to install windows version v6.0.5 diff --git a/results/classifier/deepseek-2-tmp/output/device/469 b/results/classifier/deepseek-2-tmp/output/device/469 deleted file mode 100644 index 235d1ebc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/469 +++ /dev/null @@ -1,2 +0,0 @@ - -SB16 audio playback freezes emulation in Windows 95 guest diff --git a/results/classifier/deepseek-2-tmp/output/device/471 b/results/classifier/deepseek-2-tmp/output/device/471 deleted file mode 100644 index 33dea7ec..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/471 +++ /dev/null @@ -1,65 +0,0 @@ - -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-tmp/output/device/484 b/results/classifier/deepseek-2-tmp/output/device/484 deleted file mode 100644 index dd59c496..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/484 +++ /dev/null @@ -1,2 +0,0 @@ - -6.1 Regression: machine pflash parsing diff --git a/results/classifier/deepseek-2-tmp/output/device/485 b/results/classifier/deepseek-2-tmp/output/device/485 deleted file mode 100644 index d5546655..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/485 +++ /dev/null @@ -1,2 +0,0 @@ - -Failed to restore domain - error load load virtio-balloon:virtio diff --git a/results/classifier/deepseek-2-tmp/output/device/486 b/results/classifier/deepseek-2-tmp/output/device/486 deleted file mode 100644 index 91698c08..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/486 +++ /dev/null @@ -1,2 +0,0 @@ - -/dev/input/mouse0: is not an evdev device diff --git a/results/classifier/deepseek-2-tmp/output/device/487 b/results/classifier/deepseek-2-tmp/output/device/487 deleted file mode 100644 index af52b25f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/487 +++ /dev/null @@ -1,2 +0,0 @@ - -sdhci: out of bounds read on sd->sd_status diff --git a/results/classifier/deepseek-2-tmp/output/device/492 b/results/classifier/deepseek-2-tmp/output/device/492 deleted file mode 100644 index 44bfceaa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/492 +++ /dev/null @@ -1,28 +0,0 @@ - -[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-tmp/output/device/498417 b/results/classifier/deepseek-2-tmp/output/device/498417 deleted file mode 100644 index 586c5db6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/498417 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/521 b/results/classifier/deepseek-2-tmp/output/device/521 deleted file mode 100644 index 965c7379..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/521 +++ /dev/null @@ -1,2 +0,0 @@ - -Assert mr != NULL through megaraid diff --git a/results/classifier/deepseek-2-tmp/output/device/526 b/results/classifier/deepseek-2-tmp/output/device/526 deleted file mode 100644 index 2ddfc499..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/526 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/531 b/results/classifier/deepseek-2-tmp/output/device/531 deleted file mode 100644 index 78b86632..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/531 +++ /dev/null @@ -1,2 +0,0 @@ - -Replace DMA processing in I/O handlers by asynchronous BH diff --git a/results/classifier/deepseek-2-tmp/output/device/541 b/results/classifier/deepseek-2-tmp/output/device/541 deleted file mode 100644 index 13f20078..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/541 +++ /dev/null @@ -1,2 +0,0 @@ - -Heap-use-after-free through ehci_flush_qh diff --git a/results/classifier/deepseek-2-tmp/output/device/542 b/results/classifier/deepseek-2-tmp/output/device/542 deleted file mode 100644 index f121e57f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/542 +++ /dev/null @@ -1,2 +0,0 @@ - -Stack-overflow in ldl_le_dma through intel-hda (CVE-2021-3611) diff --git a/results/classifier/deepseek-2-tmp/output/device/543 b/results/classifier/deepseek-2-tmp/output/device/543 deleted file mode 100644 index fc16546b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/543 +++ /dev/null @@ -1,2 +0,0 @@ - -virtio-blk: ASSERT: !s->dataplane_started diff --git a/results/classifier/deepseek-2-tmp/output/device/545089 b/results/classifier/deepseek-2-tmp/output/device/545089 deleted file mode 100644 index 3bbc2ae0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/545089 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/546 b/results/classifier/deepseek-2-tmp/output/device/546 deleted file mode 100644 index 9dcd64bd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/546 +++ /dev/null @@ -1,2 +0,0 @@ - -Global-buffer-overflow in mode_sense_page diff --git a/results/classifier/deepseek-2-tmp/output/device/548 b/results/classifier/deepseek-2-tmp/output/device/548 deleted file mode 100644 index cacc63bc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/548 +++ /dev/null @@ -1,2 +0,0 @@ - -Null-ptr dereference in megasas_finish_dcmd diff --git a/results/classifier/deepseek-2-tmp/output/device/552 b/results/classifier/deepseek-2-tmp/output/device/552 deleted file mode 100644 index 6759da16..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/552 +++ /dev/null @@ -1,2 +0,0 @@ - -assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed diff --git a/results/classifier/deepseek-2-tmp/output/device/556 b/results/classifier/deepseek-2-tmp/output/device/556 deleted file mode 100644 index 295f2a76..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/556 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/56 b/results/classifier/deepseek-2-tmp/output/device/56 deleted file mode 100644 index 04711447..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/56 +++ /dev/null @@ -1,2 +0,0 @@ - -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-tmp/output/device/583 b/results/classifier/deepseek-2-tmp/output/device/583 deleted file mode 100644 index df77f3b4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/583 +++ /dev/null @@ -1,2 +0,0 @@ - -Last cylinder of CHS disk image is not declared as accessible in image diff --git a/results/classifier/deepseek-2-tmp/output/device/584146 b/results/classifier/deepseek-2-tmp/output/device/584146 deleted file mode 100644 index b75719cd..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/584146 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/588688 b/results/classifier/deepseek-2-tmp/output/device/588688 deleted file mode 100644 index 579f8e3e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/588688 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/588693 b/results/classifier/deepseek-2-tmp/output/device/588693 deleted file mode 100644 index dc84617c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/588693 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/59 b/results/classifier/deepseek-2-tmp/output/device/59 deleted file mode 100644 index 4b41be5b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/59 +++ /dev/null @@ -1,2 +0,0 @@ - -ide/core.c ATA Major Version reporting incorrect diff --git a/results/classifier/deepseek-2-tmp/output/device/591666 b/results/classifier/deepseek-2-tmp/output/device/591666 deleted file mode 100644 index e574391a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/591666 +++ /dev/null @@ -1,19 +0,0 @@ - -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-tmp/output/device/602544 b/results/classifier/deepseek-2-tmp/output/device/602544 deleted file mode 100644 index 123e04d0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/602544 +++ /dev/null @@ -1,7 +0,0 @@ - -[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-tmp/output/device/604 b/results/classifier/deepseek-2-tmp/output/device/604 deleted file mode 100644 index 8dd699c9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/604 +++ /dev/null @@ -1,2 +0,0 @@ - -QEMU crashes with "-global driver=isa-fdc" diff --git a/results/classifier/deepseek-2-tmp/output/device/612452 b/results/classifier/deepseek-2-tmp/output/device/612452 deleted file mode 100644 index e258652d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/612452 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/613529 b/results/classifier/deepseek-2-tmp/output/device/613529 deleted file mode 100644 index d6c2b816..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/613529 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/62 b/results/classifier/deepseek-2-tmp/output/device/62 deleted file mode 100644 index f0abb0b4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/62 +++ /dev/null @@ -1,2 +0,0 @@ - -[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines diff --git a/results/classifier/deepseek-2-tmp/output/device/628082 b/results/classifier/deepseek-2-tmp/output/device/628082 deleted file mode 100644 index f2657a33..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/628082 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/648 b/results/classifier/deepseek-2-tmp/output/device/648 deleted file mode 100644 index efc6a8a8..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/648 +++ /dev/null @@ -1,2 +0,0 @@ - -util/vfio-helpers: misaligned address for struct vfio_iova_range, which requires 8 byte alignment diff --git a/results/classifier/deepseek-2-tmp/output/device/657329 b/results/classifier/deepseek-2-tmp/output/device/657329 deleted file mode 100644 index c03853ab..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/657329 +++ /dev/null @@ -1,48 +0,0 @@ - -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-tmp/output/device/659 b/results/classifier/deepseek-2-tmp/output/device/659 deleted file mode 100644 index fa85c7a5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/659 +++ /dev/null @@ -1,42 +0,0 @@ - -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-tmp/output/device/66 b/results/classifier/deepseek-2-tmp/output/device/66 deleted file mode 100644 index 0ea2fec9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/66 +++ /dev/null @@ -1,2 +0,0 @@ - --hda FAT:. limited to 504MBytes diff --git a/results/classifier/deepseek-2-tmp/output/device/660 b/results/classifier/deepseek-2-tmp/output/device/660 deleted file mode 100644 index 5450e69d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/660 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/660060 b/results/classifier/deepseek-2-tmp/output/device/660060 deleted file mode 100644 index 5e6a04e7..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/660060 +++ /dev/null @@ -1,33 +0,0 @@ - -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-tmp/output/device/663 b/results/classifier/deepseek-2-tmp/output/device/663 deleted file mode 100644 index 57815c9d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/663 +++ /dev/null @@ -1,12 +0,0 @@ - -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-tmp/output/device/666 b/results/classifier/deepseek-2-tmp/output/device/666 deleted file mode 100644 index 2341cb70..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/666 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/669 b/results/classifier/deepseek-2-tmp/output/device/669 deleted file mode 100644 index e72adddc..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/669 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/670769 b/results/classifier/deepseek-2-tmp/output/device/670769 deleted file mode 100644 index ececb2b5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/670769 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/674740 b/results/classifier/deepseek-2-tmp/output/device/674740 deleted file mode 100644 index 1a0de206..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/674740 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/678 b/results/classifier/deepseek-2-tmp/output/device/678 deleted file mode 100644 index 814dbd18..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/678 +++ /dev/null @@ -1,48 +0,0 @@ - -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-tmp/output/device/680 b/results/classifier/deepseek-2-tmp/output/device/680 deleted file mode 100644 index 7c29baab..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/680 +++ /dev/null @@ -1,2 +0,0 @@ - -multi-threaded qemu instance and pci bar diff --git a/results/classifier/deepseek-2-tmp/output/device/684 b/results/classifier/deepseek-2-tmp/output/device/684 deleted file mode 100644 index 07b361bb..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/684 +++ /dev/null @@ -1,2 +0,0 @@ - -xHCI Port Status Change Event at port powered diff --git a/results/classifier/deepseek-2-tmp/output/device/685096 b/results/classifier/deepseek-2-tmp/output/device/685096 deleted file mode 100644 index a1898a50..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/685096 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/697510 b/results/classifier/deepseek-2-tmp/output/device/697510 deleted file mode 100644 index cb277d72..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/697510 +++ /dev/null @@ -1,34 +0,0 @@ - -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-tmp/output/device/703 b/results/classifier/deepseek-2-tmp/output/device/703 deleted file mode 100644 index 2beed929..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/703 +++ /dev/null @@ -1,18 +0,0 @@ - -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-tmp/output/device/707 b/results/classifier/deepseek-2-tmp/output/device/707 deleted file mode 100644 index 9a1ce823..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/707 +++ /dev/null @@ -1,63 +0,0 @@ - -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-tmp/output/device/712337 b/results/classifier/deepseek-2-tmp/output/device/712337 deleted file mode 100644 index bee7638b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/712337 +++ /dev/null @@ -1,43 +0,0 @@ - -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-tmp/output/device/716 b/results/classifier/deepseek-2-tmp/output/device/716 deleted file mode 100644 index 68e4a502..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/716 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/721659 b/results/classifier/deepseek-2-tmp/output/device/721659 deleted file mode 100644 index 56f229c2..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/721659 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/721825 b/results/classifier/deepseek-2-tmp/output/device/721825 deleted file mode 100644 index d30b66c3..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/721825 +++ /dev/null @@ -1,77 +0,0 @@ - -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-tmp/output/device/727134 b/results/classifier/deepseek-2-tmp/output/device/727134 deleted file mode 100644 index fdfce751..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/727134 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/740895 b/results/classifier/deepseek-2-tmp/output/device/740895 deleted file mode 100644 index 00c60955..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/740895 +++ /dev/null @@ -1,65 +0,0 @@ - -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-tmp/output/device/764 b/results/classifier/deepseek-2-tmp/output/device/764 deleted file mode 100644 index b4ba6672..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/764 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/764252 b/results/classifier/deepseek-2-tmp/output/device/764252 deleted file mode 100644 index 68b91a4a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/764252 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/772275 b/results/classifier/deepseek-2-tmp/output/device/772275 deleted file mode 100644 index 10467422..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/772275 +++ /dev/null @@ -1,29 +0,0 @@ - -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-tmp/output/device/775 b/results/classifier/deepseek-2-tmp/output/device/775 deleted file mode 100644 index 7b8e995a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/775 +++ /dev/null @@ -1,5 +0,0 @@ - -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-tmp/output/device/778 b/results/classifier/deepseek-2-tmp/output/device/778 deleted file mode 100644 index 8c291c47..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/778 +++ /dev/null @@ -1,2 +0,0 @@ - -heap-buffer-overflow in megasas_sgl_get_len diff --git a/results/classifier/deepseek-2-tmp/output/device/778032 b/results/classifier/deepseek-2-tmp/output/device/778032 deleted file mode 100644 index 93fe2783..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/778032 +++ /dev/null @@ -1,71 +0,0 @@ - -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-tmp/output/device/779151 b/results/classifier/deepseek-2-tmp/output/device/779151 deleted file mode 100644 index aff3771b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/779151 +++ /dev/null @@ -1,17 +0,0 @@ - -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-tmp/output/device/782 b/results/classifier/deepseek-2-tmp/output/device/782 deleted file mode 100644 index a2669b18..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/782 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/786208 b/results/classifier/deepseek-2-tmp/output/device/786208 deleted file mode 100644 index c9f96e5e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/786208 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/786209 b/results/classifier/deepseek-2-tmp/output/device/786209 deleted file mode 100644 index 05ee4967..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/786209 +++ /dev/null @@ -1,8 +0,0 @@ - -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-tmp/output/device/786211 b/results/classifier/deepseek-2-tmp/output/device/786211 deleted file mode 100644 index d078b9ad..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/786211 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/800 b/results/classifier/deepseek-2-tmp/output/device/800 deleted file mode 100644 index 1d4f654d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/800 +++ /dev/null @@ -1,26 +0,0 @@ - -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-tmp/output/device/802 b/results/classifier/deepseek-2-tmp/output/device/802 deleted file mode 100644 index dc9179d6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/802 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/804517 b/results/classifier/deepseek-2-tmp/output/device/804517 deleted file mode 100644 index 1aac5d25..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/804517 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/810588 b/results/classifier/deepseek-2-tmp/output/device/810588 deleted file mode 100644 index ed515774..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/810588 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/811 b/results/classifier/deepseek-2-tmp/output/device/811 deleted file mode 100644 index 774f17f5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/811 +++ /dev/null @@ -1,2 +0,0 @@ - -qemu_irq_split() callers should use TYPE_SPLIT_IRQ device instead diff --git a/results/classifier/deepseek-2-tmp/output/device/811683 b/results/classifier/deepseek-2-tmp/output/device/811683 deleted file mode 100644 index a8ffc4b0..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/811683 +++ /dev/null @@ -1,25 +0,0 @@ - -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-tmp/output/device/813546 b/results/classifier/deepseek-2-tmp/output/device/813546 deleted file mode 100644 index 21a251f9..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/813546 +++ /dev/null @@ -1,6 +0,0 @@ - -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-tmp/output/device/818673 b/results/classifier/deepseek-2-tmp/output/device/818673 deleted file mode 100644 index 768109f4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/818673 +++ /dev/null @@ -1,9 +0,0 @@ - -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-tmp/output/device/820 b/results/classifier/deepseek-2-tmp/output/device/820 deleted file mode 100644 index ef02daa1..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/820 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/821078 b/results/classifier/deepseek-2-tmp/output/device/821078 deleted file mode 100644 index 8e1b857c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/821078 +++ /dev/null @@ -1,14 +0,0 @@ - -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-tmp/output/device/822408 b/results/classifier/deepseek-2-tmp/output/device/822408 deleted file mode 100644 index 4353ec20..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/822408 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/830 b/results/classifier/deepseek-2-tmp/output/device/830 deleted file mode 100644 index 8972a244..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/830 +++ /dev/null @@ -1,2 +0,0 @@ - -QEMU aarch64 support for Windows TPM driver (TIS, CRB interfaces) diff --git a/results/classifier/deepseek-2-tmp/output/device/839790 b/results/classifier/deepseek-2-tmp/output/device/839790 deleted file mode 100644 index 22da7147..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/839790 +++ /dev/null @@ -1,18 +0,0 @@ - --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-tmp/output/device/84 b/results/classifier/deepseek-2-tmp/output/device/84 deleted file mode 100644 index c3ac9f4d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/84 +++ /dev/null @@ -1,2 +0,0 @@ - -Machine shut off after tons of lsi_scsi: error: MSG IN data too long diff --git a/results/classifier/deepseek-2-tmp/output/device/877498 b/results/classifier/deepseek-2-tmp/output/device/877498 deleted file mode 100644 index b4040d94..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/877498 +++ /dev/null @@ -1,4 +0,0 @@ - -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-tmp/output/device/878 b/results/classifier/deepseek-2-tmp/output/device/878 deleted file mode 100644 index 584d9f1f..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/878 +++ /dev/null @@ -1,43 +0,0 @@ - -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-tmp/output/device/884401 b/results/classifier/deepseek-2-tmp/output/device/884401 deleted file mode 100644 index 153b6f46..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/884401 +++ /dev/null @@ -1,56 +0,0 @@ - -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-tmp/output/device/893367 b/results/classifier/deepseek-2-tmp/output/device/893367 deleted file mode 100644 index 945822d5..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/893367 +++ /dev/null @@ -1,11 +0,0 @@ - -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-tmp/output/device/895 b/results/classifier/deepseek-2-tmp/output/device/895 deleted file mode 100644 index 2d66bbda..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/895 +++ /dev/null @@ -1,39 +0,0 @@ - -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-tmp/output/device/897466 b/results/classifier/deepseek-2-tmp/output/device/897466 deleted file mode 100644 index e15e0304..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/897466 +++ /dev/null @@ -1,22 +0,0 @@ - -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-tmp/output/device/904617 b/results/classifier/deepseek-2-tmp/output/device/904617 deleted file mode 100644 index a29b87c4..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/904617 +++ /dev/null @@ -1,16 +0,0 @@ - -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-tmp/output/device/905 b/results/classifier/deepseek-2-tmp/output/device/905 deleted file mode 100644 index 7a6ed2c6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/905 +++ /dev/null @@ -1,2 +0,0 @@ - -Null-ptr dereference in blk_bs diff --git a/results/classifier/deepseek-2-tmp/output/device/906804 b/results/classifier/deepseek-2-tmp/output/device/906804 deleted file mode 100644 index 64c02cac..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/906804 +++ /dev/null @@ -1,42 +0,0 @@ - -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-tmp/output/device/912983 b/results/classifier/deepseek-2-tmp/output/device/912983 deleted file mode 100644 index bebc3d62..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/912983 +++ /dev/null @@ -1,45 +0,0 @@ - -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-tmp/output/device/924943 b/results/classifier/deepseek-2-tmp/output/device/924943 deleted file mode 100644 index 569b9cf6..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/924943 +++ /dev/null @@ -1,15 +0,0 @@ - -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-tmp/output/device/932487 b/results/classifier/deepseek-2-tmp/output/device/932487 deleted file mode 100644 index 3400aa4e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/932487 +++ /dev/null @@ -1,57 +0,0 @@ - -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-tmp/output/device/932490 b/results/classifier/deepseek-2-tmp/output/device/932490 deleted file mode 100644 index 3df3958b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/932490 +++ /dev/null @@ -1,10 +0,0 @@ - -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-tmp/output/device/933 b/results/classifier/deepseek-2-tmp/output/device/933 deleted file mode 100644 index 76042956..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/933 +++ /dev/null @@ -1,27 +0,0 @@ - -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-tmp/output/device/938552 b/results/classifier/deepseek-2-tmp/output/device/938552 deleted file mode 100644 index e5f73243..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/938552 +++ /dev/null @@ -1,24 +0,0 @@ - -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-tmp/output/device/940 b/results/classifier/deepseek-2-tmp/output/device/940 deleted file mode 100644 index bdf7122d..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/940 +++ /dev/null @@ -1,2 +0,0 @@ - -"analyze-migration.py -m" does not appear to account for the pci-hole diff --git a/results/classifier/deepseek-2-tmp/output/device/946043 b/results/classifier/deepseek-2-tmp/output/device/946043 deleted file mode 100644 index 42568d4e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/946043 +++ /dev/null @@ -1,13 +0,0 @@ - -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-tmp/output/device/959992 b/results/classifier/deepseek-2-tmp/output/device/959992 deleted file mode 100644 index 32756084..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/959992 +++ /dev/null @@ -1,44 +0,0 @@ - -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-tmp/output/device/960378 b/results/classifier/deepseek-2-tmp/output/device/960378 deleted file mode 100644 index 7213b8fa..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/960378 +++ /dev/null @@ -1,46 +0,0 @@ - -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-tmp/output/device/961757 b/results/classifier/deepseek-2-tmp/output/device/961757 deleted file mode 100644 index 5f694a4b..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/961757 +++ /dev/null @@ -1,20 +0,0 @@ - -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-tmp/output/device/965 b/results/classifier/deepseek-2-tmp/output/device/965 deleted file mode 100644 index 3b89ff4c..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/965 +++ /dev/null @@ -1,2 +0,0 @@ - -Creating a NVME disk using qemu in the Host not in the VM diff --git a/results/classifier/deepseek-2-tmp/output/device/97 b/results/classifier/deepseek-2-tmp/output/device/97 deleted file mode 100644 index e152c09e..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/97 +++ /dev/null @@ -1,2 +0,0 @@ - --serial tcp should hang up when DTR goes low diff --git a/results/classifier/deepseek-2-tmp/output/device/972 b/results/classifier/deepseek-2-tmp/output/device/972 deleted file mode 100644 index 6563d09a..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/972 +++ /dev/null @@ -1,2 +0,0 @@ - -LSI SCSI Use After Free (CVE-2022-0216) diff --git a/results/classifier/deepseek-2-tmp/output/device/990364 b/results/classifier/deepseek-2-tmp/output/device/990364 deleted file mode 100644 index 9792fe36..00000000 --- a/results/classifier/deepseek-2-tmp/output/device/990364 +++ /dev/null @@ -1,19 +0,0 @@ - -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 |