diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/267 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2670 | 59 | ||||
| -rw-r--r-- | results/classifier/108/other/2671 | 32 | ||||
| -rw-r--r-- | results/classifier/108/other/2672 | 35 | ||||
| -rw-r--r-- | results/classifier/108/other/2673 | 20 | ||||
| -rw-r--r-- | results/classifier/108/other/2675 | 26 | ||||
| -rw-r--r-- | results/classifier/108/other/2676 | 22 | ||||
| -rw-r--r-- | results/classifier/108/other/2678 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/2679 | 16 |
9 files changed, 250 insertions, 0 deletions
diff --git a/results/classifier/108/other/267 b/results/classifier/108/other/267 new file mode 100644 index 00000000..7b153307 --- /dev/null +++ b/results/classifier/108/other/267 @@ -0,0 +1,16 @@ +device: 0.784 +network: 0.592 +graphic: 0.488 +performance: 0.433 +semantic: 0.329 +permissions: 0.231 +boot: 0.213 +vnc: 0.176 +other: 0.175 +socket: 0.156 +debug: 0.147 +files: 0.109 +PID: 0.056 +KVM: 0.024 + +qemu-x86_64 segment prefixes error diff --git a/results/classifier/108/other/2670 b/results/classifier/108/other/2670 new file mode 100644 index 00000000..adbe3042 --- /dev/null +++ b/results/classifier/108/other/2670 @@ -0,0 +1,59 @@ +permissions: 0.916 +network: 0.911 +vnc: 0.821 +files: 0.816 +device: 0.812 +PID: 0.800 +performance: 0.754 +socket: 0.742 +boot: 0.712 +graphic: 0.685 +semantic: 0.590 +other: 0.569 +debug: 0.545 +KVM: 0.439 + +The virglrenderer depency causes qemu native recipe building to fail for NXP QEMU +Description of problem: +nativesdk-qemu-8.2.2.imx-r0 do_compile: oe_runmake failed +... + [87/4472] Compiling C object libcommon.fa.p/hw_display_virtio-gpu.c.o +| FAILED: libcommon.fa.p/hw_display_virtio-gpu.c.o +... + ../hw/display/virtio-gpu.c:36:10: fatal error: virglrenderer.h: No such file or directory +| 36 | #include <virglrenderer.h> +| | ^~~~~~~~~~~~~~~~~ +| compilation terminated. + +This issue was originally exposed after updating Yocto release to Scarthgap + +https://lists.yoctoproject.org/g/yocto/topic/building_sdk_fails_after/109275322 + +which seems to relate to commit https://github.com/nxp-imx/imx-qemu/commit/628105edbd816458dbf154a128cc3dd3ac809c7e that seemingly induces dependency to virglrenderer.h for virtio_gpu driver. + +Enabling opengl in our Distribution features is not a solution because that pulls in VGA graphics dependencies to our target binaries and we have no graphics hardware on our system. I have tried to disable the virglrenderer through QEMU build configuration but that does not fix the issue. +Steps to reproduce: +1. Clone NXP BSP Scarthgap +``` +$ mkdir nxp-bsp +$ cd nxp-bsp +nxp-bsp$ repo init -u https://github.com/nxp-imx/imx-manifest -b scarthgap -m imx-6.6.36-2.1.0.xml +nxp-bsp$ repo sync +``` + +2. Remove opengl from `fsl-imx-xwayland` DISTRO_FEATURES + +``` +sources/meta-imx/meta-imx-sdk/conf/distro/fsl-imx-wayland.conf: +... ++DISTRO_FEATURES:remove = "opengl " +... +``` + +3. Build qemu-native_8.2.2.imx + +``` +$ bitbake qemu-native_8.2.2.imx +``` +Additional information: + diff --git a/results/classifier/108/other/2671 b/results/classifier/108/other/2671 new file mode 100644 index 00000000..d50b6faf --- /dev/null +++ b/results/classifier/108/other/2671 @@ -0,0 +1,32 @@ +graphic: 0.819 +device: 0.393 +boot: 0.197 +vnc: 0.170 +semantic: 0.115 +network: 0.073 +debug: 0.071 +permissions: 0.063 +files: 0.050 +other: 0.034 +PID: 0.032 +performance: 0.032 +socket: 0.031 +KVM: 0.002 + +[Virtio-GPU Venus] I compiled virglrenderer with Venus support on 1.1.0,but could not boot QEMU with virtio-gpu Venus +Description of problem: +When I tried to use virtio-gpu-gl with venus=true like the template,it shows: +{width=1251 height=75} +But I have already compile virglrenderer using: + meson setup build \ + -Dvenus=true \ + -Drender-server=true \ + -Drender-server-worker=thread \ + -Dbuildtype=release \ + -Dprefix=${INSTDIR} + +and run QEMU with designated environment variables,but it still cannot boot,but if I use QEMU-8.0 with Venus-v17 patch and it works😭 +Steps to reproduce: +Just use "-device virtio-gpu-gl,hostmem=4G,blob=true,venus=true" and it will show the problem +Additional information: +No diff --git a/results/classifier/108/other/2672 b/results/classifier/108/other/2672 new file mode 100644 index 00000000..70b93654 --- /dev/null +++ b/results/classifier/108/other/2672 @@ -0,0 +1,35 @@ +graphic: 0.901 +device: 0.714 +performance: 0.602 +vnc: 0.423 +permissions: 0.384 +files: 0.361 +socket: 0.247 +boot: 0.240 +PID: 0.222 +semantic: 0.216 +network: 0.205 +debug: 0.187 +other: 0.148 +KVM: 0.040 + +Skipping a jal instruction in riscv64 baremetal emulation +Description of problem: +The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception: + +``` +0x80006070: 00200513 addi a0,zero,2 +0x80006074: 89cff0ef jal ra,-3940 # 0x80005110 + +---------------- +IN: _Z15int_switch_modehh +0x80006078: 0000 illegal + +---------------- +IN: mtvec_table +0x8000e600: 64d0406f j 20044 # 0x8001344c +``` +Steps to reproduce: +1. Execute the same binary with QEMU. +Additional information: + diff --git a/results/classifier/108/other/2673 b/results/classifier/108/other/2673 new file mode 100644 index 00000000..21f32745 --- /dev/null +++ b/results/classifier/108/other/2673 @@ -0,0 +1,20 @@ +graphic: 0.914 +device: 0.704 +semantic: 0.624 +socket: 0.495 +performance: 0.446 +network: 0.380 +files: 0.318 +permissions: 0.310 +other: 0.262 +PID: 0.163 +vnc: 0.141 +KVM: 0.135 +boot: 0.092 +debug: 0.092 + +qemu-system-riscv32 does not pass official riscv-tests +Description of problem: +I run riscv-tests using the above command and find qemu raises Illegalinstruction when `sret` in the machine mode.Therefore qemu cannot pass the rv32ui-v-and test. +Additional information: +The tests https://github.com/riscv-software-src/riscv-tests diff --git a/results/classifier/108/other/2675 b/results/classifier/108/other/2675 new file mode 100644 index 00000000..d686896f --- /dev/null +++ b/results/classifier/108/other/2675 @@ -0,0 +1,26 @@ +graphic: 0.903 +device: 0.883 +debug: 0.833 +semantic: 0.582 +performance: 0.545 +PID: 0.431 +vnc: 0.427 +socket: 0.306 +boot: 0.220 +files: 0.215 +permissions: 0.213 +network: 0.211 +other: 0.169 +KVM: 0.001 + +q800 machine is broken when compiling with --enable-cfi +Description of problem: +When compiling QEMU that is configured like this: +``` + .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang +``` +the q800 machine crashes with an illegal exception on the host very early, somewhere during q800_machine_init() +Steps to reproduce: +1. .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang +2. make qemu-system-m68k +3. ./qemu-system-m68k -M q800 diff --git a/results/classifier/108/other/2676 b/results/classifier/108/other/2676 new file mode 100644 index 00000000..64120410 --- /dev/null +++ b/results/classifier/108/other/2676 @@ -0,0 +1,22 @@ +graphic: 0.799 +device: 0.733 +vnc: 0.654 +other: 0.651 +socket: 0.633 +network: 0.557 +files: 0.506 +PID: 0.503 +debug: 0.496 +semantic: 0.477 +performance: 0.476 +permissions: 0.413 +boot: 0.345 +KVM: 0.122 + +GTK+ UI has serious problems on macOS hosts +Description of problem: +The GTK+ UI simply does not work on macOS at this stage. One major reason is that there does not appear to be any regular polling of the (macOS) UI event loop. The Cocoa back-end for GTK [sets a custom event polling function in GLib's event handler](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads#L1089) but Qemu never actually calls GLib/GTK's event polling. + +Thanks to @bonzini for discovering this as part of a [discussion on a patch generalising runloop event handling on macOS](https://patchew.org/QEMU/20241113142343.40832-1-phil@philjordan.eu/20241113142343.40832-2-phil@philjordan.eu/#CABgObfat1JwiBFNKHK6wwMkW5kgaqZfKJa=rW._5F9VvEdMWJR75A@mail.gmail.com). + +There is also a reasonable chance that QEMU might not reliably call GTK+ functions from the main thread (thread 0), which causes problems when GTK then calls through to the native Cocoa APIs which must be called from thread 0. diff --git a/results/classifier/108/other/2678 b/results/classifier/108/other/2678 new file mode 100644 index 00000000..80bef13e --- /dev/null +++ b/results/classifier/108/other/2678 @@ -0,0 +1,24 @@ +socket: 0.758 +network: 0.732 +device: 0.640 +graphic: 0.573 +debug: 0.433 +boot: 0.374 +performance: 0.337 +PID: 0.286 +files: 0.268 +KVM: 0.246 +vnc: 0.211 +semantic: 0.121 +permissions: 0.079 +other: 0.017 + +virsh blockcommit failed, however the snapshot was merged into base successfully. +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/108/other/2679 b/results/classifier/108/other/2679 new file mode 100644 index 00000000..1a43957d --- /dev/null +++ b/results/classifier/108/other/2679 @@ -0,0 +1,16 @@ +device: 0.844 +performance: 0.615 +graphic: 0.423 +semantic: 0.370 +other: 0.320 +network: 0.285 +socket: 0.146 +boot: 0.123 +PID: 0.105 +files: 0.090 +permissions: 0.067 +debug: 0.043 +vnc: 0.038 +KVM: 0.002 + +TCX emulation missing 1152x900 mode |