diff options
Diffstat (limited to 'results/classifier/zero-shot/108/vnc')
27 files changed, 1294 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/vnc/11357571 b/results/classifier/zero-shot/108/vnc/11357571 new file mode 100644 index 000000000..a01adc18f --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/11357571 @@ -0,0 +1,57 @@ +vnc: 0.950 +graphic: 0.915 +performance: 0.806 +device: 0.763 +network: 0.705 +semantic: 0.694 +other: 0.687 +PID: 0.681 +socket: 0.600 +debug: 0.572 +boot: 0.571 +permissions: 0.517 +KVM: 0.516 +files: 0.453 + +[Qemu-devel] [BUG] VNC: client won't send FramebufferUpdateRequest if job in flight is aborted + +Hi Gerd, Daniel. + +We noticed that if VncSharePolicy was configured with +VNC_SHARE_POLICY_FORCE_SHARED mode and +multiple vnc clients opened vnc connections, some clients could go blank screen +at high probability. +This problem can be reproduced when we regularly reboot suse12sp3 in graphic +mode both +with RealVNC and noVNC client. + +Then we dig into it and find out that some clients go blank screen because they +don't +send FramebufferUpdateRequest any more. One step further, we notice that each +time +the job in flight is aborted one client go blank screen. + +The bug is triggered in the following procedure. +Guest reboot => graphic mode switch => graphic_hw_update => vga_update_display +=> vga_draw_graphic (full_update = 1) => dpy_gfx_replace_surface => +vnc_dpy_switch => +vnc_abort_display_jobs (client may have job in flight) => job removed from the +queue +If one client has vnc job in flight, *vnc_abort_display_jobs* will wait until +its job is abandoned. +This behavior is done in vnc_worker_thread_loop when 'if (job->vs->ioc == NULL +|| job->vs->abort == true)' +branch is taken. + +As we can see, *vnc_abort_display_jobs* is intended to do some optimization to +avoid unnecessary client update. +But if client sends FramebufferUpdateRequest for some graphic area and its +FramebufferUpdate response job +is abandoned, the client may wait for the response and never send new +FramebufferUpdateRequest, which may +case the client go blank screen forever. + +So I am wondering whether we should drop the *vnc_abort_display_jobs* +optimization or do some trick here +to push the client to send new FramebufferUpdateRequest. Do you have any idea ? + diff --git a/results/classifier/zero-shot/108/vnc/1246990 b/results/classifier/zero-shot/108/vnc/1246990 new file mode 100644 index 000000000..e1f1b10f5 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1246990 @@ -0,0 +1,68 @@ +vnc: 0.936 +semantic: 0.931 +permissions: 0.928 +graphic: 0.917 +other: 0.913 +network: 0.909 +debug: 0.906 +PID: 0.904 +device: 0.904 +socket: 0.902 +files: 0.886 +performance: 0.881 +boot: 0.872 +KVM: 0.854 + +[qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Rjsupplicant is an authentication client of Campus Network in most universities in China. Its Linux version has only x86 and amd64 version. + +On linux: + +./qemu-x86_64 is compiled from latest qemu 1.6.1, with ./configure options: --enable-debug --target-list=x86_64-linux-user . Compiler is gcc version 4.7.3 (Debian 4.7.3-4) + +$ sudo ./qemu-x86_64 ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +$ sudo gdb ./qemu-x86_64 +(gdb) r ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +(gdb) where +#0 0x00005555559c21bd in static_code_gen_buffer () +#1 0x00005555555b74d5 in cpu_tb_exec (cpu=0x555557972580, tb_ptr=0x5555559c2190 <static_code_gen_buffer+819792> "A\213n\250\205\355\017\205\257") + at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:56 +#2 0x00005555555b817d in cpu_x86_exec (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:631 +#3 0x00005555555d997a in cpu_loop (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/main.c:283 +#4 0x00005555555eca6b in clone_func (arg=0x7fffffffc1d0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/syscall.c:4266 +#5 0x00007ffff71bfe0e in start_thread (arg=0x7ffff7f04700) at pthread_create.c:311 +#6 0x00007ffff6ef493d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 + +$ file rjsupplicant +rjsupplicant: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped + +$ uname -r +3.10-2-amd64 + + +And it can be run on Linux amd64 successfully. + +Though I don't have the source code of rjsupplicant, so I don't have further information. + +`qemu-x86_64 -strace ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_qemu.log + + +The binary is available to download at http://ge.tt/6pgG1tw/v/0 + + + +and, `strace ./rjsuuplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_native.log + +I'm not sure x86*-linux-user targets are being tested at all. Last time I checked, x86-64 variant crashed left and right to the point of being completely unusable... + +The backtrace indicates that this is a multithreaded application. These won't work reliably under qemu-user : they tend to crash, as you have found. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/vnc/1339 b/results/classifier/zero-shot/108/vnc/1339 new file mode 100644 index 000000000..55a4a9575 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1339 @@ -0,0 +1,31 @@ +vnc: 0.948 +device: 0.931 +socket: 0.857 +graphic: 0.827 +network: 0.820 +PID: 0.809 +files: 0.719 +permissions: 0.668 +performance: 0.583 +debug: 0.558 +boot: 0.487 +semantic: 0.476 +KVM: 0.423 +other: 0.273 + +RVV vfncvt.rtz.x.f.w Assertion failed +Description of problem: +when execute +``` +vsetvli t0, x0, e16, m1 +vfncvt.rtz.x.f.w v0, v4 +``` +report error: + +qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped) +Steps to reproduce: +1. write the code +2. compile +3. excute +Additional information: + diff --git a/results/classifier/zero-shot/108/vnc/1354279 b/results/classifier/zero-shot/108/vnc/1354279 new file mode 100644 index 000000000..dc3cc9932 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1354279 @@ -0,0 +1,85 @@ +vnc: 0.938 +graphic: 0.874 +KVM: 0.867 +network: 0.863 +performance: 0.826 +socket: 0.819 +device: 0.818 +PID: 0.727 +semantic: 0.663 +debug: 0.647 +permissions: 0.618 +boot: 0.439 +files: 0.423 +other: 0.194 + +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) + +the first bad commit is: +commit 22a893e4f55344f96e1aafc66f5fedc491a5ca97 +Author: Paolo Bonzini <email address hidden> +Date: Wed Jun 11 10:58:06 2014 +0200 + + memory: MemoryRegion: replace owner field with QOM parent + + The two are now the same. + + Reviewed-by: Peter Crosthwaite <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +test on Ivytown_EP +kvm.git + qemu.git: c77dcacb_0e4a7737 +kernel version: 3.16.0 +after hot remove the VF from the guest, the guest works fine. + diff --git a/results/classifier/zero-shot/108/vnc/1391942 b/results/classifier/zero-shot/108/vnc/1391942 new file mode 100644 index 000000000..10d30050e --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1391942 @@ -0,0 +1,72 @@ +vnc: 0.974 +debug: 0.915 +network: 0.915 +semantic: 0.911 +device: 0.902 +other: 0.900 +performance: 0.898 +PID: 0.889 +permissions: 0.885 +files: 0.885 +graphic: 0.831 +socket: 0.805 +KVM: 0.762 +boot: 0.675 + +Unnecessary events option of the trace argument with UST backend + +When running configure with the --enable-trace-backends=ust option the user should not have to specify a the "events" and "file" options because they are not used with that tracing framework. + +Right now, in order the use this option the need to specify a dummy events file. + +This fails: +$> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace -m 512 +qemu-system-x86_64: -trace -m: Invalid parameter '-m' + +This works: +$> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace events=dummy-events.txt -m 512 +VNC server running on `127.0.0.1:5900' + +I am using version: +$> qemu-system-x86_64 --version +QEMU emulator version 2.1.90, Copyright (c) 2003-2008 Fabrice Bellard + +On Wed, Nov 12, 2014 at 04:01:38PM -0000, Francis Deslauriers wrote: +> When running configure with the --enable-trace-backends=ust option and compiling. +> The user should not have to specify a the "events" and "file" options because they are not used with that tracing framework. +> +> Right now, in order the use this option the need to specify a dummy +> events file. +> +> This fails: +> $> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace -m 512 +> qemu-system-x86_64: -trace -m: Invalid parameter '-m' +> +> This works: +> $> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace events=dummy-events.txt -m 512 +> VNC server running on `127.0.0.1:5900' +> +> I am using version: +> $> qemu-system-x86_64 --version +> QEMU emulator version 2.1.90, Copyright (c) 2003-2008 Fabrice Bellard + +What happens when you pass no -trace option? + +Stefan + + +It works without the -trace option. + +Want I meant with this post is that the "events" argument of the "-trace" option has no effect in the case of using LTTng UST as the tracing backend because the events are enabled from the LTTng tracer itself. + +Is there some way I can make an argument optional or conditional to a tracing framework? + +Thanks, + +Francis + +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/zero-shot/108/vnc/1453612 b/results/classifier/zero-shot/108/vnc/1453612 new file mode 100644 index 000000000..3e224c10c --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1453612 @@ -0,0 +1,36 @@ +vnc: 0.963 +other: 0.708 +graphic: 0.690 +device: 0.683 +socket: 0.658 +network: 0.550 +performance: 0.513 +permissions: 0.405 +PID: 0.376 +semantic: 0.357 +files: 0.357 +debug: 0.350 +boot: 0.279 +KVM: 0.141 + +set_password command of monitor has poor feedback on failure + +running `set_password vnc NkkmEz5icvTAGo6MECzBVEUxP` in qemu monitor started with `-monitor stdio` gives feedback `Could not set password` which is unhelpful because it doesn't specify the reason of the failure. + +experienced with 2.3.0 + +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 please 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/zero-shot/108/vnc/1486278 b/results/classifier/zero-shot/108/vnc/1486278 new file mode 100644 index 000000000..b98d88e25 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1486278 @@ -0,0 +1,38 @@ +vnc: 0.982 +permissions: 0.927 +device: 0.896 +network: 0.879 +socket: 0.844 +graphic: 0.802 +PID: 0.707 +performance: 0.677 +semantic: 0.657 +debug: 0.555 +other: 0.485 +boot: 0.455 +KVM: 0.308 +files: 0.257 + +'info vnc' monitor command does not show websocket information + +Steps to reproduce^ +1. run + qemu-system-x86_64 -vnc 0.0.0.0:1,websocket=5701 -nographic -monitor stdio + +2. then type + (qemu) info vnc +3. see + address: 0.0.0.0:5901 + auth: none +Client: none + +There is no information about websocket parameters, but 'netstat -nltp' shows me: + ... +tcp 0 0 0.0.0.0:5701 0.0.0.0:* LISTEN 27073/qemu-system-x +.... + +I think this has been fixed in QEMU v2.10.0 with this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0a9667ecdb6d7da90a2ef64 + +Thanks! This is presumed fixed in Ubuntu also then, since 18.04 onwards shipped a qemu version higher than 2.10.0. If this is wrong, please reopen. + diff --git a/results/classifier/zero-shot/108/vnc/1548 b/results/classifier/zero-shot/108/vnc/1548 new file mode 100644 index 000000000..ec1fe82f5 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1548 @@ -0,0 +1,53 @@ +vnc: 0.948 +device: 0.723 +graphic: 0.609 +semantic: 0.603 +PID: 0.594 +socket: 0.573 +other: 0.556 +debug: 0.504 +network: 0.443 +performance: 0.278 +files: 0.179 +boot: 0.171 +permissions: 0.168 +KVM: 0.101 + +8.0.0rc0 Regression: vnc fails with Segmentation fault +Description of problem: +On connecting with `gvncviewer localhost:05` the qemu process fails with +``` +Segmentation fault +``` +`gvncviewer localhost:05` prints +``` +Connected to server +Error: Server closed the connection +Disconnected from server +``` +Steps to reproduce: +1. Enter `qemu-system-x86_64 -m 1536 -display vnc=:05 -k de -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first terminal +2. Enter `gvncviewer localhost:05` in second terminal +Additional information: +Final output of `git bisect`: +``` +385ac97f8fad0e6980c5dfea71132d5ecfb16608 is the first bad commit +commit 385ac97f8fad0e6980c5dfea71132d5ecfb16608 +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Tue Jan 17 15:24:40 2023 +0400 + + ui: keep current cursor with QemuConsole + + Keeping the current cursor around is useful, not only for VNC, but for + other displays. Let's move it down, see the following patches for other + usages. + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> + + include/ui/console.h | 1 + + ui/console.c | 8 ++++++++ + ui/vnc.c | 7 ++----- + ui/vnc.h | 1 - + 4 files changed, 11 insertions(+), 6 deletions(-) +``` diff --git a/results/classifier/zero-shot/108/vnc/1661176 b/results/classifier/zero-shot/108/vnc/1661176 new file mode 100644 index 000000000..75fc88e2d --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1661176 @@ -0,0 +1,24 @@ +vnc: 0.961 +network: 0.861 +device: 0.814 +graphic: 0.761 +performance: 0.753 +other: 0.700 +semantic: 0.633 +socket: 0.401 +PID: 0.319 +debug: 0.290 +permissions: 0.248 +boot: 0.201 +files: 0.098 +KVM: 0.091 + +[2.8.0] Under VNC CTRL-ALT-2 doesn't get to the monitor + +With version 2.6.2 I could access the monitor via VNC by pressing CTRL-ALT-2, while CTRL-ALT-3 brought me to the "serial0 console". CTRL-ALT-1 brought me back to the VGA console. +Since 2.8.0 CTRL-ALT-2 brings me to the "serial0 console" and CTRL-ALT-3 to the "parallel0 console". The monitor is not available any more, to any CTRL-ALT-1stROW. + +Can you still reproduce your issue with the latest version of QEMU (currently v4.2.0)? Please also always add the way how you launched QEMU (ie. the command line parameters) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/vnc/1686 b/results/classifier/zero-shot/108/vnc/1686 new file mode 100644 index 000000000..22d02b645 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1686 @@ -0,0 +1,58 @@ +vnc: 0.986 +boot: 0.961 +performance: 0.943 +device: 0.930 +graphic: 0.904 +network: 0.837 +PID: 0.825 +KVM: 0.818 +permissions: 0.704 +socket: 0.699 +debug: 0.653 +semantic: 0.619 +files: 0.514 +other: 0.263 + +VPS does not boots with CPU Model QEMU64 or KVM64 +Description of problem: + +Steps to reproduce: +1. Boot the VPS using AlmaLinux 9 ISO / image and it boots to kernel panic +Additional information: +VNC shows this message : + +[ 1.749935] do_exit.cold+0x14/0x9f + +[1.7502581 do_group_exit+0x33/0xa0 + +1.7506001 _x64_sys_exit_group+0x14/0x20 + +1.7510081 do_syscall 64+0x5c/0x90 + +[1.751361] ? syscall_exit_to_user_mode+0x12/0x30 + +[1.7517911 ? do_syscall_64+0x69/0x90 + +[1.752131] ? do_user_addr_fault+0x1d8/0x698 + +[1.7525091 ? exc_page_fault+0x62/0x150 1.752896] entry_SYSCALL_64_after_hwframe+ +0x63/0xcd + +[1.753612] RIP: 0033:0x7fb0e95b62d1 + +[ 1.7539561 Code: c3 of 1f 84 00 00 00 00 00 f3 Of le fa be e7 00 00 00 ba 3c 00 00 00 eb Od 89 de Of 05 48 3d 00 fe ff ff 77 1c f4 89 fe of 05 <48> 3d 00 fe ff ff 76 e7 f7 d8 89 05 ff fe 00 00 eb dd of 1f 44 00 + +[ 1.755047] RSP: 002b:00007ffe484df 288 EFLAGS: 00000246 ORIG_RAX: 00000000000 + +000e7 + +[ 1.755590] RAX: fffff ffffda RBX: 00007fb0e95b0f30 RCX: 00007fb0e95b62d1 1.756100] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 000000000000007f + +[1.756565] RBP: 00007ffe484df410 R08: 00007ffe484dedf9 R09: 0000000000000000 + +[ 1.757034] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007fb0e958f000 + +[ 1.7574981 R13: 0000002300000007 R14: 0000000000000007 R15: 00007ffe484df420 + +[ 1.7579921 Kernel Offset: 0x3aa00000 from Oxffffffff81000000 (relocation ran ge: 0xffffffff80000000-0xffffffffbfffffff) + +[ 1.7589051---[ end Kernel panic code=0x00007f00 --- not syncing: Attempted to kill init! exit diff --git a/results/classifier/zero-shot/108/vnc/1715186 b/results/classifier/zero-shot/108/vnc/1715186 new file mode 100644 index 000000000..580dc5b83 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1715186 @@ -0,0 +1,67 @@ +vnc: 0.970 +socket: 0.959 +debug: 0.934 +performance: 0.839 +network: 0.826 +other: 0.822 +device: 0.760 +graphic: 0.752 +semantic: 0.732 +KVM: 0.673 +PID: 0.608 +permissions: 0.596 +files: 0.572 +boot: 0.537 + +websockets: Improve error messages + +Since 2.9 / 07e95cd529af345fdeea230913f68eff5b925bb6 , whenever the VNC websocket server finds an error with the incoming connection request, it just closes the socket with no further information. + +This makes figuring out what's wrong with the request nearly impossible. + +I would be nice if: + +* HTTP 400 were returned to the client, with an appropriate error message +* Maybe something written to the log as well? + +Currently, I'm resorting to looking at my request and the websocket source and hoping I can figure out what's wrong. + +At very least we should also use 404 if given a invalid path + +Will be included for 2.11 in + +commit 3a3f8705962c8c8a47a9b981ffd5aab7274ad508 +Author: Daniel P. Berrange <email address hidden> +Date: Wed Sep 6 11:38:36 2017 +0100 + + io: include full error message in websocket handshake trace + + When the websocket handshake fails it is useful to log the real + error message via the trace points for debugging purposes. + + Fixes bug: #1715186 + + Reviewed-by: Philippe Mathieu-Daudé <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + +commit f69a8bde29354493ff8aea64cc9cb3b531d16337 +Author: Daniel P. Berrange <email address hidden> +Date: Wed Sep 6 11:33:17 2017 +0100 + + io: send proper HTTP response for websocket errors + + When any error occurs while processing the websockets handshake, + QEMU just terminates the connection abruptly. This is in violation + of the HTTP specs and does not help the client understand what they + did wrong. This is particularly bad when the client gives the wrong + path, as a "404 Not Found" would be very helpful. + + Refactor the handshake code so that it always sends a response to + the client unless there was an I/O error. + + Fixes bug: #1715186 + + Reviewed-by: Philippe Mathieu-Daudé <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + + diff --git a/results/classifier/zero-shot/108/vnc/1732671 b/results/classifier/zero-shot/108/vnc/1732671 new file mode 100644 index 000000000..77714600d --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1732671 @@ -0,0 +1,33 @@ +vnc: 0.964 +network: 0.888 +socket: 0.871 +device: 0.785 +other: 0.703 +semantic: 0.682 +graphic: 0.678 +performance: 0.575 +files: 0.509 +permissions: 0.434 +PID: 0.434 +debug: 0.381 +KVM: 0.378 +boot: 0.365 + +vnc websocket compatibility issue + +WebSocket support in VNC should allow access from VNC client through upgraded WebSocket connection. This feature is not working in IE 11/Edge with noVNC HTML5 client, in contrast to that in Firefox/Safari, etc. + +The reason that IE 11/Edge fails to accept the connection upgrade is that the value equality of the `Upgrade` header field is checked in a strict case-sensitive manner in QEMU side, however, the IE/Edge does not send the exactly same string value `websocket` but a capital letter `W` instead. + +Defined in section 4.2.1 of rfc6455, the upgrade header field shall be treated case-insensitively. + +A patch shall be made in `io/channel-websock.c`, converting the value of upgrade string to lowercase before comparison is made with QIO_CHANNEL_WEBSOCK_UPGRADE_WEBSOCKET, to allow case-insensitive comparison in the process. + +Which version of QEMU did you test this against ? It should be fixed in current GIT master AFAIK + +I think it should have been fixed in 33badfd. + +Sorry for the noise. + +No problem, it is a valid bug report, since we've not actually released the fix yet, so changing status. + diff --git a/results/classifier/zero-shot/108/vnc/1752646 b/results/classifier/zero-shot/108/vnc/1752646 new file mode 100644 index 000000000..f3f0101d2 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1752646 @@ -0,0 +1,43 @@ +vnc: 0.938 +graphic: 0.866 +performance: 0.815 +device: 0.814 +network: 0.790 +other: 0.781 +files: 0.677 +semantic: 0.668 +permissions: 0.601 +PID: 0.490 +debug: 0.421 +boot: 0.413 +socket: 0.387 +KVM: 0.131 + +Freezing VNC screen on some the UEFI framebuffer applications + +Hi folks! + +I use TianCore (UEFI) formware on the qemu (master version last commit a6e0344). +When kernel/linux is start, it using UEFI Framebuffer. Then I run UEFI application (which writes directly to the framebuffer) my VNS screen is freezing. Then I restart vnclient I see only one frame. + +When I run application, I getting in the file hw/display/vga.c on function 'vga_ioport_write' some commands, it change "s->ar_index" from 0x20 -> 0x10 + +In the function vga_update_display: +1751 if (!(s->ar_index & 0x20)) { +1752 graphic_mode = GMODE_BLANK; +1753 } else { + +And I got GMODE_BLANK mode. If I patch it: +1751 if (0) { + +my VNC not freezing. + +From "Hardware Level VGA and SVGA Video Programming Information Page" I saw, what ar_index is 0x3C0 (Attribute Controller Data Write Register), 0x20(5-bit) is PAS -- Palette Address Source + +If there is a output via the UEFI framebuffer, does the difference have a PAS or not? Why do we need to pause the output if the PAS is exposed? Especially when the application outputs via framebuffer. + +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/zero-shot/108/vnc/1816819 b/results/classifier/zero-shot/108/vnc/1816819 new file mode 100644 index 000000000..784b06977 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1816819 @@ -0,0 +1,75 @@ +vnc: 0.985 +socket: 0.984 +network: 0.980 +device: 0.963 +performance: 0.947 +PID: 0.938 +files: 0.915 +other: 0.913 +graphic: 0.912 +debug: 0.904 +permissions: 0.897 +KVM: 0.878 +boot: 0.872 +semantic: 0.814 + +Chardev websocket stops listening after first connection disconnects + +Using qemu option: + -chardev socket,id=websock0,websocket,port=13042,host=127.0.0.1,server,nowait -serial chardev:websock0 + +To have a websocket listening chardev. After the first connection disconnects (that does a full websocket handshake), subsequent connections aren't accepted. See below for a reproducing session kindly provided by Daniel: + +$ telnet localhost 13042 +Trying ::1... +telnet: connect to address ::1: Connection refused +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +GET / HTTP/1.1 +Upgrade: websocket +Connection: Upgrade +Host: localhost:%s +Origin: http://localhost +Sec-WebSocket-Key: o9JHNiS3/0/0zYE1wa3yIw== +Sec-WebSocket-Version: 13 +Sec-WebSocket-Protocol: binary + +HTTP/1.1 101 Switching Protocols +Server: QEMU VNC +Date: Wed, 20 Feb 2019 16:52:04 GMT +Upgrade: websocket +Connection: Upgrade +Sec-WebSocket-Accept: b3DnPh7O8hyYE5sIjQxl/c1J+S8= +Sec-WebSocket-Protocol: binary + +sfsd +�&�only binary frames may be fragmentedConnection closed by foreign host. + +$ telnet localhost 13042 +Trying ::1... +telnet: connect to address ::1: Connection refused +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +GET / HTTP/1.1 +Upgrade: websocket +Connection: Upgrade +Host: localhost:%s +Origin: http://localhost +Sec-WebSocket-Key: o9JHNiS3/0/0zYE1wa3yIw== +Sec-WebSocket-Version: 13 +Sec-WebSocket-Protocol: binary + + + +...no response..... + +Patch proposed + +https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg05556.html + +I can confirm that this patch fixes the issue. I can now reconnect after a client has disconnected. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=dd154c4d9f48a44ad24e1 + diff --git a/results/classifier/zero-shot/108/vnc/1923861 b/results/classifier/zero-shot/108/vnc/1923861 new file mode 100644 index 000000000..1014976be --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1923861 @@ -0,0 +1,167 @@ +vnc: 0.945 +debug: 0.942 +performance: 0.933 +PID: 0.928 +permissions: 0.922 +device: 0.911 +files: 0.910 +socket: 0.907 +graphic: 0.903 +other: 0.899 +KVM: 0.881 +semantic: 0.876 +boot: 0.852 +network: 0.844 + +Hardfault when accessing FPSCR register + +QEMU release version: v6.0.0-rc2 + +command line: +qemu-system-arm -machine mps3-an547 -nographic -kernel <my_project>.elf -semihosting -semihosting-config enable=on,target=native + +host operating system: Linux ISCNR90TMR1S 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +guest operating system: none (bare metal) + +Observation: +I am simulating embedded firmware for a Cortex-M55 device, using MPS3-AN547 machine. In the startup code I am accessing the FPSCR core register: + + unsigned int fpscr =__get_FPSCR(); + fpscr = fpscr & (~FPU_FPDSCR_AHP_Msk); + __set_FPSCR(fpscr); + +where the register access functions __get_FPSCR() and __set_FPSCR(fpscr) are taken from CMSIS_5 at ./CMSIS/Core/include/cmsis_gcc.h + +I observe hardfaults upon __get_FPSCR() and __set_FPSCR(fpscr). The same startup code works fine on the Arm Corstone-300 FVP. + +Does your code enable the FPU (via the CPACR and, if running in NonSecure) the NSACR? If not then a fault is exactly what you should expect. (I believe the FVP has a non-standard behaviour where it will enable the FPU by default even though real hardware does not behave that way.) + + +Yes, I think I did: + + SCB->NSACR |= (3U << 10U); /* enable Non-secure access to CP10 and CP11 coprocessors */ + __DSB(); + __ISB(); + + SCB->CPACR |= ((3U << 10U*2U) | /* enable CP10 Full Access */ + (3U << 11U*2U) ); /* enable CP11 Full Access */ + __DSB(); + __ISB(); + +But I get a NOCP (no coprocessor) hard fault. + +Does the qemu mps3-an547 model contain the FPU by default or do I have to select it via the command line? +Is there an example code / test case included in the qemu database where I can lookup the usage of mps3-an547 + FPU? + +Do you have a guest binary and QEMU commandline I can use to reproduce the issue ? + + +Command line is +qemu-system-arm -machine mps3-an547 -nographic -kernel test.elf -semihosting -semihosting-config enable=on,target=native + +Binary is attached. It does + +int main(int argc, char* argv[]) +{ + SCB->NSACR |= (3U << 10U); /* enable Non-secure access to CP10 and CP11 coprocessors */ + __DSB(); + __ISB(); + + SCB->CPACR |= ((3U << 10U*2U) | /* enable CP10 Full Access */ + (3U << 11U*2U) ); /* enable CP11 Full Access */ + __DSB(); + __ISB(); + +// enable DL branch cache + #define CCR (*((volatile unsigned int *)0xE000ED14)) + #define CCR_DL (1 << 19) + CCR |= CCR_DL; + __ISB(); + + uint32_t result; + __asm volatile ("VMRS %0, fpscr" : "=r" (result) ); // <-- NOCP hardfault + printf("fpscr = 0x%08lx\r\n", result); + __asm volatile ("VMRS %0, mvfr0" : "=r" (result) ); + printf("mvfr0 = 0x%08lx\r\n", result); + __asm volatile ("VMRS %0, mvfr1" : "=r" (result) ); + printf("mvfr1 = 0x%08lx\r\n", result); + __asm volatile ("VMRS %0, mvfr2" : "=r" (result) ); + printf("mvfr2 = 0x%08lx\r\n", result); + + exit(0); +} + +Thank you for your help! + + +Thanks. This is a bug in the AN547 model -- we were accidentally turning off the FPU. I'll write a patch. + +NB that with that bug fixed your code then hits an UNDEF trying to do: + 0x00000996: eef7 1a10 vmrs r1, mvfr0 + +Only A-profile CPUs have MVFR0 accessible via the vmrs instruction. For M-profile this register is memory-mapped, at 0xE000EF40. + + +The bug fix for the QEMU part of this is +https://<email address hidden>/ + + +Thanks for the fix. I applied it and +1. yes, the hard fault when reading FPSCR is gone. +2. yes, I also see the UNDEF. Note that on the Corstone-300 MPS3-AN547 FVP I can access mvfr0 via vmrs. + +I changed the vmrs to ldr. Now I can read the registers. The values differ from what the FVP tells me: +fpscr = 0x00000000 (qemu-system-arm) - 0x00040000 (Corstone FVP) +mvfr0 = 0x10110021 - 0x10110221 +mvfr1 = 0x11000011 - 0x12100211 +mvfr2 = 0x00000040 - 0x00000040 + +Using the FPU for some simple calculations + + volatile int nom_i, den_i; + nom_i = 7; + den_i = 3; + volatile float nom_f, den_f, div_f; + nom_f = (float)nom_i; + den_f = (float)den_i; + div_f = nom_f / den_f; + printf("%e / %f = %f\r\n", nom_f, den_f, div_f); + +I run into another UNDEF when executing + vcvt.f64.f32 d6, s12 + +Again, the FVP can execute the same elf. I attached it. Maybe you can have another look. + +Some of those ID register differences are expected; some I'm surprised by. The differences are: + * no MVE (expected, we don't implement it yet) + * no double-precision + * no FP16 + +So the missing double-precision is why your vcvt UNDEFs. Those last two ought to be present, but something is squashing them; I will investigate. + +The FPSCR difference is that we aren't reporting FPSCR.LTPSIZE for some reason -- that's a bug too. + + +I changed the compile options to single precision, only. Then, my small FP example works. Ok for my purposes, I don't need double. + +But I would need MVE. Are there any plans to implement MVE? + +Oops -- we were giving the AN547 a Cortex-M33 rather than the -M55 it ought to have :-( + +Yes, MVE is next on my todo list; it will probably be in 6.2, or maybe 7.0 depending how long it takes to implement it all. + + +https://<email address hidden>/ should fix the "not actually an M55" bug which will then give you the double-precision and FP16 (and the right FPSCR value). + + +I tried your fix. Yes, the fpscr and mvfr0/1/2 values do match the FVP, now (except for the MVE bit which is explained above). + +Thx for the updates. + +These fixes are now in master and will be in rc4 and the eventual 6.0 release. + + +https://gitlab.com/qemu-project/qemu/-/commit/330ef14e6e749919c5c +https://gitlab.com/qemu-project/qemu/-/commit/1df0878cff267128393 + diff --git a/results/classifier/zero-shot/108/vnc/1988 b/results/classifier/zero-shot/108/vnc/1988 new file mode 100644 index 000000000..11cd31b1d --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/1988 @@ -0,0 +1,41 @@ +vnc: 0.920 +graphic: 0.901 +network: 0.837 +device: 0.829 +PID: 0.740 +semantic: 0.714 +files: 0.687 +debug: 0.654 +socket: 0.585 +other: 0.541 +performance: 0.479 +boot: 0.435 +permissions: 0.433 +KVM: 0.165 + +8.2.0rc0 Regression: '-display vnc' opens gtk display as well +Description of problem: +A VNC display is requested, but a GTK frontend is opened as well. A VNC client is able to connect. +Steps to reproduce: +1. /configure --enable-fdt=internal --target-list=x86_64-softmmu +2. make +3. build/qemu-system-x86_64 -display vnc=:05 -k de +Additional information: +git bisect finally shows +``` +484629fc8141eaa257f961b5e5e310a1bbd0f1a2 is the first bad commit +commit 484629fc8141eaa257f961b5e5e310a1bbd0f1a2 +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Wed Oct 25 17:21:17 2023 +0400 + + vl: simplify display_remote logic + + Bump the display_remote variable when the -vnc option is parsed, just + like -spice. + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Thomas Huth <thuth@redhat.com> + + system/vl.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) +``` diff --git a/results/classifier/zero-shot/108/vnc/2001 b/results/classifier/zero-shot/108/vnc/2001 new file mode 100644 index 000000000..fc90163ee --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/2001 @@ -0,0 +1,58 @@ +vnc: 0.929 +device: 0.924 +network: 0.880 +boot: 0.877 +performance: 0.835 +PID: 0.829 +graphic: 0.824 +files: 0.776 +KVM: 0.732 +socket: 0.724 +permissions: 0.650 +debug: 0.592 +semantic: 0.496 +other: 0.483 + +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/zero-shot/108/vnc/2171 b/results/classifier/zero-shot/108/vnc/2171 new file mode 100644 index 000000000..d1a442e5a --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/2171 @@ -0,0 +1,40 @@ +vnc: 0.961 +device: 0.954 +graphic: 0.949 +PID: 0.909 +socket: 0.854 +semantic: 0.698 +files: 0.694 +debug: 0.677 +performance: 0.645 +boot: 0.644 +other: 0.502 +network: 0.457 +KVM: 0.434 +permissions: 0.319 + +VPS Disk space over use +Description of problem: +\# qemu-img info -U v1001-dluw9EHRDbmMd8fQ-CACjC7FWnMhISeDM.qcow2 + +file format: qcow2 + +virtual size: 800G (858993459200 bytes) + +disk size: **812G** + +cluster_size: 65536 + +Format specific information: + +compat: 1.1 + +lazy refcounts: false + +refcount bits: 16 + +corrupt: false + +Disk size is using beyond the Virtual size. + +How is that even possible ? diff --git a/results/classifier/zero-shot/108/vnc/2492 b/results/classifier/zero-shot/108/vnc/2492 new file mode 100644 index 000000000..7f6a4cd47 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/2492 @@ -0,0 +1,35 @@ +vnc: 0.973 +device: 0.852 +network: 0.803 +PID: 0.785 +graphic: 0.730 +socket: 0.711 +semantic: 0.657 +debug: 0.639 +performance: 0.524 +files: 0.506 +permissions: 0.467 +other: 0.365 +boot: 0.334 +KVM: 0.026 + +Unable to disable gvnc dependency during build +Description of problem: +The qtest tests will pick up a copy of gvnc if it happens to be installed and there does not appear +to be any way of disabling the dependency to ensure a reproducible build. We tripped over this in +bulk builds on OpenBSD. +Steps to reproduce: +1. Install gvnc +2. Build QEMU +Additional information: +From tests/qtest/meson.build + +``` +if vnc.found() + gvnc = dependency('gvnc-1.0', method: 'pkg-config', required: false) + if gvnc.found() + qtests += {'vnc-display-test': [gvnc]} + qtests_generic += [ 'vnc-display-test' ] + endif +endif +``` diff --git a/results/classifier/zero-shot/108/vnc/2608 b/results/classifier/zero-shot/108/vnc/2608 new file mode 100644 index 000000000..278f6ed1d --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/2608 @@ -0,0 +1,24 @@ +vnc: 0.981 +network: 0.972 +device: 0.925 +graphic: 0.895 +performance: 0.789 +boot: 0.707 +semantic: 0.641 +socket: 0.579 +debug: 0.577 +PID: 0.443 +other: 0.354 +permissions: 0.249 +files: 0.210 +KVM: 0.007 + +Black screen in Windows XP +Description of problem: +When starting the installation of Windows XP (or Windows 2003) the screen in VNC stays black while the installer is in text-mode. During the second half of the installation, where it switches to graphical GUI, the display becomes visible again. + +This problem never happened on 9.0.1 and below, so is a regression in 9.1.0 +Steps to reproduce: +1. Start the Windows XP installer +2. Connect to VNC +3. Screen stays black diff --git a/results/classifier/zero-shot/108/vnc/2646 b/results/classifier/zero-shot/108/vnc/2646 new file mode 100644 index 000000000..fdb9c5148 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/2646 @@ -0,0 +1,40 @@ +vnc: 0.923 +device: 0.919 +boot: 0.840 +PID: 0.812 +permissions: 0.810 +performance: 0.764 +files: 0.695 +socket: 0.680 +graphic: 0.668 +semantic: 0.594 +network: 0.536 +other: 0.494 +debug: 0.488 +KVM: 0.382 + +osx 10.6.8 guest on x86-64 macos 10.12 host can't boot on HVF, boots on tcg +Description of problem: +for some reason HVF acceleration does not work with mac-on-mac. Haiku beta5 (x64), win10 x64, Debian netinstall 12.7.0 - all works. +Steps to reproduce: +``` +1. get 10.6.8 image from archive.org +2. bin/qemu-system-x86_64 -device isa-applesmc,osk="well_known_string" -usb -M pc-q35-2.11 -device usb-kbd -device usb-tablet -m 1536 -smp 1 -cpu Penryn,vendor=GenuineIntel,+ssse3,+sse4.1,+sse4.2 -L /opt/local/share/qemu -device ac97 -vnc :3 --no-reboot -accel hvf -boot c -bios usr/share/edk2-ovmf-x64/OVMF_CODE.fd -hda osx-10.6-xcode-compressed-efi.qcow2 -d unimp +audio: Could not create a backend for voice `ac97.pi' +audio: Could not create a backend for voice `ac97.mc' +audio: Could not create a backend for voice `ac97.pi' +audio: Could not create a backend for voice `ac97.mc' +ahci: IRQ#0 level:1 +ahci: IRQ#0 level:1 + +{many more of those} +``` +and at this point qemu quits. + +without --no-reboot it reboots + +tried both UEFI boot (using https://github.com/khronokernel/khronokernel.github.io/blob/master/Binaries/OpenCore/EFI-LEGACY.img.zip?raw=true , currently integrated into hdd image) and Clover-5160-X64.iso + +if I remove -accel hvf and replace it with accel tcg guest boots. + +i tried to capture moment when it reboots on video but I can't catch anything :( diff --git a/results/classifier/zero-shot/108/vnc/351 b/results/classifier/zero-shot/108/vnc/351 new file mode 100644 index 000000000..07234b4fb --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/351 @@ -0,0 +1,16 @@ +vnc: 0.949 +performance: 0.740 +device: 0.685 +debug: 0.628 +network: 0.450 +graphic: 0.266 +semantic: 0.219 +boot: 0.168 +other: 0.136 +KVM: 0.063 +PID: 0.046 +permissions: 0.028 +socket: 0.005 +files: 0.005 + +German keyboard vnc issue diff --git a/results/classifier/zero-shot/108/vnc/759 b/results/classifier/zero-shot/108/vnc/759 new file mode 100644 index 000000000..5e1f560e1 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/759 @@ -0,0 +1,27 @@ +vnc: 0.947 +graphic: 0.889 +device: 0.874 +network: 0.863 +performance: 0.704 +semantic: 0.683 +permissions: 0.683 +PID: 0.537 +files: 0.408 +boot: 0.359 +debug: 0.312 +socket: 0.286 +KVM: 0.254 +other: 0.219 + +Copy&Paste does not work on VNC +Description of problem: +Cannot copy&paste between host and guest when vnc is used (gtk works fine). +Steps to reproduce: +1. Build qemu 6.2-rc2 using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek +``` +2. Run the above qemu command using vnc server. Connect to the VM desktop using `vncviewer :5900` where vncviewer is downloaded from [here](https://www.realvnc.com/en/connect/download/viewer/). +3. Try to copy and paste something in the terminal between host and guest. It doesn't work. +Additional information: +I'm following [this article](https://www.kraxel.org/blog/2021/05/qemu-cut-paste/) which says copy&paste is supported on vnc. diff --git a/results/classifier/zero-shot/108/vnc/772 b/results/classifier/zero-shot/108/vnc/772 new file mode 100644 index 000000000..e7ab1400a --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/772 @@ -0,0 +1,27 @@ +vnc: 0.939 +graphic: 0.910 +device: 0.881 +KVM: 0.875 +permissions: 0.832 +semantic: 0.808 +PID: 0.741 +boot: 0.680 +files: 0.669 +debug: 0.663 +performance: 0.639 +socket: 0.586 +network: 0.546 +other: 0.265 + +Pop!_OS 20.10 host + RHEL 8.5 guest = Oh no! Something has gone wrong. +Description of problem: +Whenever starting the Qemu VM, there is an error covering the whole desktop "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please log out and try again." After clicking the "Log Out" button and waiting for hours, the guest RHEL may or may not recover, based on your luck and other qemu options used. +Steps to reproduce: +1. Build qemu using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek +``` +2. Install Red Hat Enterprise Linux 8.5 in qemu +3. Run qemu using the above command line. +Additional information: + diff --git a/results/classifier/zero-shot/108/vnc/779 b/results/classifier/zero-shot/108/vnc/779 new file mode 100644 index 000000000..802cbf6bd --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/779 @@ -0,0 +1,28 @@ +vnc: 0.961 +socket: 0.953 +network: 0.919 +graphic: 0.868 +device: 0.841 +debug: 0.704 +boot: 0.638 +PID: 0.585 +semantic: 0.578 +performance: 0.506 +KVM: 0.494 +permissions: 0.313 +files: 0.107 +other: 0.096 + +VNC server not work +Description of problem: +I've created a sandbox guest with kata containers. The VM started successfully, but vnc server not listen unix socket. + +`root@bootstrap02:~# netstat -anp | grep 1989153` +`unix 3 [ ] STREAM CONNECTED 369610592 1989153/qemu-system /run/vc/vm/bash/qmp.sock` +`root@bootstrap02:~# lsof -p 1989153 | grep unix` +`qemu-syst 1989153 root 108u unix 0xffff912740d3b800 0t0 369610592 /run/vc/vm/bash/qmp.sock type=STREAM` +Steps to reproduce: +1.Create Linux sandbox guest VM +2.connect vnc server +Additional information: + diff --git a/results/classifier/zero-shot/108/vnc/824074 b/results/classifier/zero-shot/108/vnc/824074 new file mode 100644 index 000000000..6fc39b3dd --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/824074 @@ -0,0 +1,26 @@ +vnc: 0.981 +network: 0.767 +graphic: 0.760 +device: 0.756 +other: 0.523 +socket: 0.484 +semantic: 0.413 +performance: 0.394 +boot: 0.261 +debug: 0.260 +PID: 0.251 +files: 0.240 +permissions: 0.200 +KVM: 0.146 + +Provide runtime option to expose the supported list of keymaps for vnc + +As discussed in the ganeti group[1], I'm opening this bug to request that qemu provides a runtime command or switch to list the supported keymaps for vnc. + + [1] - http://groups.google.com/group/ganeti/browse_thread/thread/dd524f5311d8d79e + +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/zero-shot/108/vnc/981 b/results/classifier/zero-shot/108/vnc/981 new file mode 100644 index 000000000..9887d0981 --- /dev/null +++ b/results/classifier/zero-shot/108/vnc/981 @@ -0,0 +1,25 @@ +vnc: 0.925 +graphic: 0.899 +socket: 0.878 +network: 0.797 +device: 0.770 +semantic: 0.500 +debug: 0.323 +other: 0.213 +PID: 0.203 +performance: 0.183 +boot: 0.178 +files: 0.140 +permissions: 0.131 +KVM: 0.005 + +VNC UNIX sockets are not deleted +Description of problem: +After exiting QEMU a unix VNC socket file is left behind. Upon termination I would expect it to remove the socket file like it does for example with a monitor unix socket. +Steps to reproduce: +``` + rm -f foo.socket + qemu-system-x86_64 -vnc unix:foo.socket + # Exit QEMU + ls foo.socket + ``` |