diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/gemma3:12b/device/157 | 2 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1572 | 2 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1572959 | 8 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1576 | 29 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1576347 | 27 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1577 | 85 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1579306 | 15 |
7 files changed, 168 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/device/157 b/results/classifier/gemma3:12b/device/157 new file mode 100644 index 00000000..0031d62b --- /dev/null +++ b/results/classifier/gemma3:12b/device/157 @@ -0,0 +1,2 @@ + +Xbox One controller USB passthrough disconnections and stops diff --git a/results/classifier/gemma3:12b/device/1572 b/results/classifier/gemma3:12b/device/1572 new file mode 100644 index 00000000..2f651111 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1572 @@ -0,0 +1,2 @@ + +Assertion !rss_info->enabled failed in e1000e_write_lgcy_rx_descr diff --git a/results/classifier/gemma3:12b/device/1572959 b/results/classifier/gemma3:12b/device/1572959 new file mode 100644 index 00000000..284e7470 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1572959 @@ -0,0 +1,8 @@ + +bcm2835_property: inconsistent values when both setting and querying the framebuffer + +As the framebuffer settings are copied into the result message before it is reconfigured, inconsistent behavior can happen when, for instance, you set with a single message the width, height, and depth, and ask at the same time to allocate the buffer and get the pitch and the size. + +In this case, the reported pitch and size would be incorrect as they were computed with the initial values of width, height and depth, not the ones the client requested. + +Attached is a patch also sent to the qemu-devel mailing list. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1576 b/results/classifier/gemma3:12b/device/1576 new file mode 100644 index 00000000..831118dc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1576 @@ -0,0 +1,29 @@ + +Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails +Description of problem: +Loading the VM state fails with: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load pcie-root-port:parent_obj.parent_obj.parent_obj +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:1c.0/pcie-root-port' +qemu-system-x86_64: Error -22 while loading VM state +``` +Steps to reproduce: +Used the following script with the first argument being a build directory of v8.0.0-rc2 and the second a build directory of v7.2.0 +``` +#!/bin/bash +rm /tmp/disk.qcow2 +args=" + -device pcie-root-port,multifunction=on,bus=pcie.0,addr=1c.0,port=1,chassis=1 + -machine type=pc-q35-7.2" +$1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G +$1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF +{"execute": "qmp_capabilities"} +{"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } +{"execute": "quit"} +EOF +$2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap +``` +Additional information: +Bisecting shows that 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") is the first bad commit. diff --git a/results/classifier/gemma3:12b/device/1576347 b/results/classifier/gemma3:12b/device/1576347 new file mode 100644 index 00000000..33697e39 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1576347 @@ -0,0 +1,27 @@ + +Only one NVMe device is usable in Windows (10) guest + +Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +QEMU version: 2.5.0 + +Kernel: 4.5.1 (Arch Linux) + +When there are two NVMe devices specified, only the second one will be usable in Windows. The following error is shown under "Device status" of the failed NVMe controller in Device Manager: + +"This device cannot start. (Code 10) + +The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect." + +The only thing seems suspicious to me is that the nvme emulation in qemu does not have WWN/EUI-64 set for the devices, though I have no idea at all whether that is mandatory: + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1577 b/results/classifier/gemma3:12b/device/1577 new file mode 100644 index 00000000..5bad6187 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1577 @@ -0,0 +1,85 @@ + +device_del return is already in the process of unplug frequently +Description of problem: +recently we update qemu 6.1.1 to qemu 7.1.0, and run into an issue with the following error: + +command '{ "execute": "device_del", "arguments": { "id": "virtio-diskX" } }' for VM "id" failed ({ "return": {"class": "GenericError", "desc": "Device virtio-diskX is already in the process of unplug"} }). + +The issue is reproducible. With a few seconds delay before hot-unplug, hot-unplug just works fine. + +After a few digging, we found that the commit 9323f892b39 may incur the issue. +------------------ + failover: fix unplug pending detection + + Failover needs to detect the end of the PCI unplug to start migration + after the VFIO card has been unplugged. + + To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in + pcie_unplug_device(). + + But since + 17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") + we have switched to ACPI unplug and these functions are not called anymore + and the flag not set. So failover migration is not able to detect if card + is really unplugged and acts as it's done as soon as it's started. So it + doesn't wait the end of the unplug to start the migration. We don't see any + problem when we test that because ACPI unplug is faster than PCIe native + hotplug and when the migration really starts the unplug operation is + already done. + + See c000a9bd06ea ("pci: mark device having guest unplug request pending") + a99c4da9fc2a ("pci: mark devices partially unplugged") + + Signed-off-by: Laurent Vivier <lvivier@redhat.com> + Reviewed-by: Ani Sinha <ani@anisinha.ca> + Message-Id: <20211118133225.324937-4-lvivier@redhat.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +------------------ +The purpose is for detecting the end of the PCI device hot-unplug. However, we feel the error confusing. How is it possible that a disk "is already in the process of unplug" during the first hot-unplug attempt? So far as I know, the issue was also encountered by libvirt, but they simply ignored it: + + https://bugzilla.redhat.com/show_bug.cgi?id=1878659 + +Hence, a question is: should we have the line below in acpi_pcihp_device_unplug_request_cb()? + + pdev->qdev.pending_deleted_event = true; + +It would be great if you as the author could give us a few hints. + +Thank you very much for your reply! + +Sincerely, + +Yu Zhang @ Compute Platform IONOS + + +The issue is reproducible in our own stack, which is not quite easy to describe in a few command lines. We simplified it a bit by a script instead. Although it's not able to reproduce, it could be somewhat helpful to understand the issue. + +``` +#!/bin/bash + +HOME=~ +QEMU=$HOME/qemu/bin/qemu-system-x86_64 +DISK1=$HOME/img/disk1.qcow2 +DISK4=$HOME/img/disk4.qcow2 +DISK5=$HOME/img/disk5.qcow2 + +$QEMU \ + -cpu host -enable-kvm -m 2048 -smp 2 \ + -object iothread,id=iothread1 \ + -drive file=$DISK1,if=none,id=drive-virtio-disk1,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,iothread=iothread1,num-queues=1,discard=on,id=virtio-disk1 \ + -object iothread,id=iothread4 \ + -drive file=$DISK4,if=none,id=drive-virtio-disk4,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk4,iothread=iothread4,num-queues=1,discard=on,id=virtio-disk4 \ + -object iothread,id=iothread5 \ + -drive file=$DISK5,if=none,id=drive-virtio-disk5,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk5,iothread=iothread5,num-queues=1,discard=on,id=virtio-disk5 \ + -qmp unix:./qmp-sock,server,nowait & + +sleep 5 + +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock``` +Additional information: +Possible workaround: https://lore.kernel.org/qemu-devel/20230403131833-mutt-send-email-mst@kernel.org/T/#t diff --git a/results/classifier/gemma3:12b/device/1579306 b/results/classifier/gemma3:12b/device/1579306 new file mode 100644 index 00000000..f362925f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1579306 @@ -0,0 +1,15 @@ + +usb-uas does not work in Windows (10) guest + +When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest: + +"The device cannot start. (Code 10) + +{Operation Failed} +The requested operation was unsuccessful" + +If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well: + +"qemu-system-x86_64: usb_uas_handle_control: unhandled control request" + +If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side. \ No newline at end of file |