diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1792 | 96 | ||||
| -rw-r--r-- | results/classifier/108/other/1792193 | 60 | ||||
| -rw-r--r-- | results/classifier/108/other/1792523 | 92 | ||||
| -rw-r--r-- | results/classifier/108/other/1792659 | 67 |
4 files changed, 315 insertions, 0 deletions
diff --git a/results/classifier/108/other/1792 b/results/classifier/108/other/1792 new file mode 100644 index 00000000..58e9a699 --- /dev/null +++ b/results/classifier/108/other/1792 @@ -0,0 +1,96 @@ +permissions: 0.827 +other: 0.708 +debug: 0.680 +network: 0.671 +socket: 0.654 +files: 0.647 +PID: 0.645 +device: 0.636 +boot: 0.631 +KVM: 0.627 +semantic: 0.615 +performance: 0.615 +vnc: 0.612 +graphic: 0.560 + +qemu-8.1-rc1 and rc0 fail build. 8.0 is fine +Description of problem: +Build error with 8.1.0-rc0 and 8.1.0-rc1. +Build of 8.0.3 works correctly, using the same build configuration. +Steps to reproduce: +1. Run configure as below in logs +2.`/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3 -m ensurepip --upgrade --default-pip` +3. +Additional information: +``` +$ s/build qemu:host +CLEAN qemu + * Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc0 ... + * Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/qa_checks/qemu-* ... +UNPACK qemu +BUILD qemu (host) + TOOLCHAIN configure +Executing (host): /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/configure --bindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin --extra-cflags=-I/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/include --extra-ldflags=-L/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --libexecdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --localstatedir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/var --prefix=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain --sbindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/sbin --sysconfdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/etc --enable-tools --enable-malloc=system --disable-attr --disable-auth-pam --disable-install-blobs --disable-capstone --disable-curl --disable-debug-info --disable-debug-mutex --disable-debug-tcg --disable-docs --disable-gcrypt --disable-gnutls --disable-system --disable-user --disable-vnc --disable-werror --disable-xkbcommon --disable-zstd +python determined to be '/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin/python3' +python version: Python 3.11.4 +mkvenv: Creating non-isolated virtual environment at 'pyvenv' +mkvenv subprocess failed: +cmd: ['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip'] +returncode: 1 +========== stdout ========== +Looking in links: /tmp/tmpio395oka +Processing /tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl +Processing /tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl +Installing collected packages: setuptools, pip +ERROR: Exception: +Traceback (most recent call last): + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/base_command.py", line 169, in exc_logging_wrapper + status = run_func(*args) + ^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/req_command.py", line 248, in wrapper + return func(self, options, args) + ^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/commands/install.py", line 449, in run + installed = install_given_reqs( + ^^^^^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/__init__.py", line 72, in install_given_reqs + requirement.install( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/req_install.py", line 800, in install + install_wheel( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 731, in install_wheel + _install_wheel( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 620, in _install_wheel + assert os.path.exists(pyc_path) +AssertionError +Traceback (most recent call last): + File "<frozen runpy>", line 198, in _run_module_as_main + File "<frozen runpy>", line 88, in _run_code + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__main__.py", line 5, in <module> + sys.exit(ensurepip._main()) + ^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 286, in _main + return _bootstrap( + ^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 202, in _bootstrap + return _run_pip([*args, *_PACKAGE_NAMES], additional_paths) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 103, in _run_pip + return subprocess.run(cmd, check=True).returncode + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/subprocess.py", line 571, in run + raise CalledProcessError(retcode, process.args, +subprocess.CalledProcessError: Command '['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-W', 'ignore::DeprecationWarning', '-c', '\nimport runpy\nimport sys\nsys.path = [\'/tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl\', \'/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl\'] + sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\', \'--no-index\', \'--find-links\', \'/tmp/tmpio395oka\', \'--upgrade\', \'setuptools\', \'pip\']\nrunpy.run_module("pip", run_name="__main__", alter_sys=True)\n']' returned non-zero exit status 2. + +============================ + +*** Ouch! *** + +VENV creation subprocess failed. + + + +ERROR: python venv creation failed + +FAILURE: s/build qemu:host during configure_host (default) + +``` diff --git a/results/classifier/108/other/1792193 b/results/classifier/108/other/1792193 new file mode 100644 index 00000000..3a361593 --- /dev/null +++ b/results/classifier/108/other/1792193 @@ -0,0 +1,60 @@ +graphic: 0.819 +device: 0.766 +debug: 0.754 +semantic: 0.721 +performance: 0.668 +files: 0.663 +KVM: 0.584 +permissions: 0.563 +vnc: 0.530 +other: 0.527 +PID: 0.508 +boot: 0.453 +network: 0.414 +socket: 0.411 + +AMD Athlon(tm) X2 Dual-Core QL-64 bug + +I upgrade my qemu 2.12.0-2 => 3.0.0-1. After that I can't load virtual machine with "-cpu host" option. Full command line is +qemu-system-x86_64 \ + -monitor stdio \ + -enable-kvm \ + -cpu host \ + -smp cpus=2 \ + -m 1G \ + -vga virtio \ + -display gtk,gl=on \ + -soundhw ac97 \ + -drive file=/ehdd/qemu/arch_hw_12_08_2018/arch_shrinked.raw,format=raw,if=virtio +I have Arch Linux on virtual machine. When I start QEMU, GRUB tries to load initial ramdisk and stops. System doesn't load. If I try to start virtual machine with "-cpu athlon" option then get the same bug. +I downgrade back to qemu 2.12.0-2 and virtual machine works fine, system loads. +My processor is AMD Athlon(tm) X2 Dual-Core QL-64. + +Hi Kirill, + That's a bit tricky to debug; could you build qemu from git and try and bisect between 2.12.0 and 3.0 to see which commit broke it? + +Yes I could, but it rebuilds too long. I will report results later, when find broke commit. + +I try to bisect git version. When I run git bisect bad v3.0.0 it says: +Bisecting: 1298 revisions left to test after this (roughly 10 steps) +error: Your local changes to the following files would be overwritten by checkout: + configure + po/bg.po + po/de_DE.po + po/fr_FR.po + po/hu.po + po/it.po + po/messages.po + po/tr.po + po/zh_CN.po +Please commit your changes or stash them before you switch branches. +Aborting +Something is wrong, isn't it? + +I can't do bisect, but I have installed qemu version 3.0.50 (v3.0.0-614-g19b599f766-dirty) from git and this works fine. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1792523 b/results/classifier/108/other/1792523 new file mode 100644 index 00000000..d582adef --- /dev/null +++ b/results/classifier/108/other/1792523 @@ -0,0 +1,92 @@ +KVM: 0.903 +boot: 0.863 +permissions: 0.858 +performance: 0.853 +other: 0.849 +device: 0.831 +graphic: 0.828 +vnc: 0.826 +network: 0.817 +debug: 0.817 +files: 0.804 +PID: 0.789 +semantic: 0.781 +socket: 0.772 + +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 + +To clarify, are the problematic USB passthrough devices these: + +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +or this: + +-device vfio-pci,host=04:00.0 \ + +Without knowing what the vfio-pci devices are (assuming 1:00.x is GPU+audio), I don't know if passthrough is being used as a colloquial for device assignment or if the issue is really with the usb-host devices. + +The usb-host devices have the problem. + +It does not seem to matter if 1 or all 3 are specified.. I had thought maybe only one of them was causing the issue.. but all of them are affected if '-daemonize' is specified at startup. + +Correct, the vfio-pci device 1:00.x is an Nvidia GPU+audio, and 4:00.0 is an Asmedia USB controller. + +But all of the vfio arguments and binding parts of this script can be removed, and replaced with '-vga std -display gtk' arguments, and the host has the same behavior of not regaining control of the usb-host devices until they are unplugged and plugged back in after the VM shuts down. + +No messages appear in dmesg or any stdout from Qemu related to errors or USB that stand out to me as a problem.. I am happy to try any suggestions to further narrow down the cause. + +Thanks for replying! + +I tested this again on the latest Qemu and Linux kernel and cannot reproduce it anymore, so this can be closed now.. + diff --git a/results/classifier/108/other/1792659 b/results/classifier/108/other/1792659 new file mode 100644 index 00000000..5c9e0eb7 --- /dev/null +++ b/results/classifier/108/other/1792659 @@ -0,0 +1,67 @@ +graphic: 0.664 +semantic: 0.650 +device: 0.625 +performance: 0.596 +socket: 0.581 +other: 0.580 +PID: 0.578 +debug: 0.535 +permissions: 0.526 +vnc: 0.488 +network: 0.484 +files: 0.446 +boot: 0.417 +KVM: 0.335 + +watchpoints might not properly stop execution at the right address + +This bug has been tested with the latest development tree (19b599f7664b2ebfd0f405fb79c14dd241557452). + +I am using qemu-system-i386 with the gdbserver stub. I set a watchpoint on some address. When the watchpoint is hit, it will be reported by gdb, but it might happen that eip points to the wrong address (execution has not properly stopped when the watchpoint was hit). + +The setup I used to reproduce it is quite complex, but I believe I have found the cause of the bug, so I will describe that. + +The check_watchpoint() function sets cflags_next_tb in order to force the execution of only one instruction, and then exits the current tb. It then expects to be called again after that one instruction is executed, the watchpoint is hit and it is reported to gdb. + +The problem is that another interrupt might have been generated around the same time as the watchpoint. If the interrupt changes eip and execution goes on in another address, the value of cflags_next_tb will be spoiled. When we come back from the interrupt to the address where the watchpoint is hit, it is possible that a tb with multiple instructions is been executed, and therefore eip points to the wrong address, ahead of where it should be. + +In my case, the order is as follows: +* i8259 generates an IRQ + - cpu->interrupt_request contains both CPU_INTERRUPT_TGT_EXT_1 and CPU_INTERRUPT_HARD +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with CPU_INTERRUPT_TGT_EXT_1 + - execution continues +* I am exactly at the instruction where the watchpoint is hit. + - check_watchpoint() is called and cflags_next_tb is set to force the execution of only one instruction. + - execution breaks out of the loop with siglongjmp() +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with the IRQ. eip is changed and cflags_next_tb is spoiled + - execution continues at the IRQ + +[...] +* The kernel finishes dealing with the IRQ + +* I am back at the instruction where the watchpoint is hit. + - A tb is created and executed with two instructions instead of one + - eip is now ahead of the instruction that hit the watchpoint +* cpu_handle_interrupt() is called + - it deals with CPU_INTERRUPT_DEBUG + - the watchpoint is reported by gdb, but with the wrong eip. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +I can follow the logic here and agree there's a bug. + +It would be nice if there were a reproducer, to verify +that the bug is actually fixed, but I can make a stab +at it without. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/245 + + |