diff options
Diffstat (limited to 'results/classifier/deepseek-r1:14b/output/vnc')
49 files changed, 887 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1089005 b/results/classifier/deepseek-r1:14b/output/vnc/1089005 new file mode 100644 index 000000000..f8155ec6b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1089005 @@ -0,0 +1,21 @@ + +Qemu does not shutdown with vnc enabled on OS X + +I am running OS X 10.8.2 and Qemu 1.3.50 from your git repository. + +Running + + qemu-system-i386 <image> + +works fine. I can quit the process using ctrl-c. + +When I try to use + + qemu-system-i386 -vnc :<port> <image> + +ctrl-c does nothing and I have to kill the process trough the activity monitor. +Furthermore terminating the process from my java program does not work either. +I have also posted a question on Stackoverflow: http://stackoverflow.com/questions/13798367/qemu-does-not-shutdown-with-vnc-enabled-on-os-x + +Thanks +Leander \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1099403 b/results/classifier/deepseek-r1:14b/output/vnc/1099403 new file mode 100644 index 000000000..5bcf6b38a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1099403 @@ -0,0 +1,10 @@ + +High CPU utilization in vnc mode + +We start a gentoo guest using ./x86-64-softmmu/qemu-x86-64 -hda <disk>.qcow2 -vnc :6. + +Then we start a vncviewer session to this guest from a remote computer. In this session, we start a video. After starting the video, the CPU utilization of the guest (the qemu-x86-64 process) increases to about 90%. The high CPU utilization persists even after closing the vncviewer session. + +However, the CPU usage while running a video inside a gentoo guest (without a remote computer connecting via vncviewer) is only 20-30%. So we suspect the high CPU usage to be due to the vncserver code running inside QEMU which has to do a lot of work to send the framebuffer updates to the client. + +My question is why does the usage not decrease when the remote vncviewer is disconnected? On simple computers (no virtual guests), the CPU usage of vncserver decreases drastically when the vncviewer client is disconnected. Why does this not happen in the vncserver provided by QEMU (through -vnc :6). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1158 b/results/classifier/deepseek-r1:14b/output/vnc/1158 new file mode 100644 index 000000000..cc635463f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1158 @@ -0,0 +1,2 @@ + +Error in setting VNC password diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1414222 b/results/classifier/deepseek-r1:14b/output/vnc/1414222 new file mode 100644 index 000000000..3741f982f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1414222 @@ -0,0 +1,21 @@ + +qemu-system-i386: -vnc localhost:0,to=99,id=default: Invalid parameter 'to' + +git-bisect pints to: + +4db14629c38611061fc19ec6927405923de84f08 is the first bad commit +commit 4db14629c38611061fc19ec6927405923de84f08 +Author: Gerd Hoffmann <email address hidden> +Date: Tue Sep 16 12:33:03 2014 +0200 + + vnc: switch to QemuOpts, allow multiple servers + + This patch switches vnc over to QemuOpts, and it (more or less + as side effect) allows multiple vnc server instances. + + Signed-off-by: Gerd Hoffmann <email address hidden> + +:040000 040000 70020c79b463eaff4b91c8c7f985240d1d1914f0 354a3a125e7b82a1699ce4e0cfc5055662bd3466 M include +:100644 100644 0b4f131936052ed6062ba4b2b9434da0c2cce959 963305c26917a930f37d916df66b319d6558d281 M qmp.c +:040000 040000 e7933d52124ae48100893eed8e14cbe46f80b936 30fa5966f5c8362d6db6730a7091bbde7780d4d8 M ui +:100644 100644 9fb32c13df1c14daf8304184c6503d16bff7afce 983259bc9f7064b446da358a316a31a31731a223 M vl.c \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1455912 b/results/classifier/deepseek-r1:14b/output/vnc/1455912 new file mode 100644 index 000000000..528a5e290 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1455912 @@ -0,0 +1,12 @@ + +vnc websocket option not properly parsed when running on commandline + +All of my vms are started with a simple script on the command line. +Starting with Qemu 2.3.0, the option "-vnc host:port,websocket" is no longer working. + +Previously if I said listen on Tor:17,websocket it would function correctly. Now it's kicking an error: + + +qemu-system-x86_64: -vnc tor:17,websocket: Failed to start VNC server on `(null)': address resolution failed for tor:on: Servname not supported for ai_socktype + +The error leads me to believe it's not parsing the command line options for the "vnc" option correctly. If I leave off ",websocket" it works correctly. I've even tried, replacing the hostname with an IP address, and using the alternate form " -display vnc=tor:17,webscoket". It reports the same error. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1486278 b/results/classifier/deepseek-r1:14b/output/vnc/1486278 new file mode 100644 index 000000000..c0632d7ce --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1486278 @@ -0,0 +1,18 @@ + +'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 +.... \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1502884 b/results/classifier/deepseek-r1:14b/output/vnc/1502884 new file mode 100644 index 000000000..0c43728a8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1502884 @@ -0,0 +1,15 @@ + +Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option! + +Hi, + +A big issue when using QEMU's VNC server (VNC KVM) is that, when there's a network lag, unintended keypresses go through to the QEMU guest VM. + +This is frequently "enter" keypresses, causing all kinds of unintended consequences in the VM. So basically it's extremely dangerous. + +This is because the VNC protocol's keyboard interaction is implemented in terms of key down - key up events, making the server's keyboard autorepeat kick in when it should not. + + +For this reason, it would be great if QEMU's VNC server part would be enhanced with an option such that when a VNC protocol key down is received, then locally that is treated as one single keypress only (I don't know how that should be implemented but I guess either as an immediate key down - key up sequence locally, or key down + key up after say 0.05 seconds), instead of waiting for the key up event from the VNC client. + +Thanks! \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1548 b/results/classifier/deepseek-r1:14b/output/vnc/1548 new file mode 100644 index 000000000..1718db82a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1548 @@ -0,0 +1,39 @@ + +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/deepseek-r1:14b/output/vnc/1586194 b/results/classifier/deepseek-r1:14b/output/vnc/1586194 new file mode 100644 index 000000000..14c2b0207 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1586194 @@ -0,0 +1,47 @@ + +VNC reverse broken in qemu 2.6.0 + +Hi all, + +I recently tried to upgrade from Qemu 2.4.1 to 2.6.0, but found some problems with VNC reverse connections. + +1) In "-vnc 172.16.1.3:5902,reverse" used to mean "connect to port 5902" + That seems to have changed changed since 2.4.1, the thing after the IP address is now interpreted + as a display number. If that change was intentional, the man-page needs to be fixed. + +2) After subtracting 5900 from that port number (-vnc 172.16.1.3:2,reverse), I ran into a segfault. + +---8<--- +Program received signal SIGSEGV, Segmentation fault. +qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7fffffffe118) at io/channel-socket.c:33 +33 return socket_sockaddr_to_address(&ioc->localAddr, +(gdb) bt +#0 qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7fffffffe118) at io/channel-socket.c:33 +#1 0x000055555594c0f5 in vnc_init_basic_info_from_server_addr (errp=0x7fffffffe118, info=0x555558f35990, + ioc=<optimized out>) at ui/vnc.c:146 +#2 vnc_server_info_get (vd=0x7fffecc4b010) at ui/vnc.c:223 +#3 0x000055555595192a in vnc_qmp_event (vs=0x555558f41f30, vs=0x555558f41f30, event=QAPI_EVENT_VNC_CONNECTED) + at ui/vnc.c:279 +#4 vnc_connect (vd=vd@entry=0x7fffecc4b010, sioc=sioc@entry=0x555558f34c00, skipauth=skipauth@entry=false, + websocket=websocket@entry=false) at ui/vnc.c:2994 +#5 0x00005555559520d8 in vnc_display_open (id=id@entry=0x555556437650 "default", errp=errp@entry=0x7fffffffe228) + at ui/vnc.c:3773 +#6 0x0000555555952fd3 in vnc_init_func (opaque=<optimized out>, opts=<optimized out>, errp=<optimized out>) + at ui/vnc.c:3868 +#7 0x0000555555a011da in qemu_opts_foreach (list=<optimized out>, func=0x555555952fa0 <vnc_init_func>, opaque=0x0, + errp=0x0) at util/qemu-option.c:1116 +#8 0x00005555556dcfbe in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4592 +--->8--- + +A git bisect shows that this happens since + +---8<--- +commit 98481bfcd661daa3c160cc87a297b0e60a307788 +Author: Eric Blake <email address hidden> +Date: Mon Oct 26 16:34:45 2015 -0600 + + vnc: Hoist allocation of VncBasicInfo to callers +--->8--- + +TIA + Andi \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1589272 b/results/classifier/deepseek-r1:14b/output/vnc/1589272 new file mode 100644 index 000000000..800036de5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1589272 @@ -0,0 +1,81 @@ + +qemu-system-x86_64: There is no option group 'vnc' + +build qemu from git (6b3532b20b787cbd697a68b383232f5c3b39bd1e) + +with this options: + +./configure \ + --python=/usr/bin/python2 \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user \ + --audio-drv-list='pa alsa' \ + --enable-linux-aio \ + --enable-seccomp \ + --enable-tpm \ + --enable-modules \ + --disable-sdl \ + --disable-gtk \ + --disable-spice \ + --disable-rbd \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-smartcard \ + --disable-glusterfs \ + --disable-docs \ + --disable-vnc{,-sasl,-jpeg,-png} \ + --disable-guest-agent + +i get: + +└───╼ qemu-system-x86_64 +qemu-system-x86_64: There is no option group 'vnc' +Segment Fault (core dumped) + +└───╼ coredumpctl info 12932 + PID: 12932 (qemu-system-x86) + UID: 1000 (sl1pkn07) + GID: 100 (users) + Signal: 11 (SEGV) + Timestamp: dom 2016-06-05 18:05:51 CEST (17s ago) + Command Line: qemu-system-x86_64 + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /user.slice/user-1000.slice/session-c1.scope + Unit: session-c1.scope + Slice: user-1000.slice + Session: c1 + Owner UID: 1000 (sl1pkn07) + Boot ID: 5b205159fa6b4c25946fad7087bd366f + Machine ID: c20ee0c57658685bfedf50384b0e3ec0 + Hostname: sL1pKn07 + Coredump: /var/lib/systemd/coredump/core.qemu-system-x86.1000.5b205159fa6b4c25946fad7087bd366f.12932.1465142751000000000000.lz4 + Message: Process 12932 (qemu-system-x86) of user 1000 dumped core. + + Stack trace of thread 12932: + #0 0x000055b269c2e245 qemu_opts_foreach (qemu-system-x86_64) + #1 0x000055b2698fb6b5 main (qemu-system-x86_64) + #2 0x00007fafc4e5a741 __libc_start_main (libc.so.6) + #3 0x000055b269900eb9 _start (qemu-system-x86_64) + + Stack trace of thread 12934: + #0 0x00007fafc51e80af pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) + #1 0x000055b269c21b19 qemu_cond_wait (qemu-system-x86_64) + #2 0x000055b26992bff4 qemu_tcg_cpu_thread_fn (qemu-system-x86_64) + #3 0x00007fafc51e2484 start_thread (libpthread.so.0) + #4 0x00007fafc4f216dd __clone (libc.so.6) + + Stack trace of thread 12933: + #0 0x00007fafc51eaebc __lll_lock_wait (libpthread.so.0) + #1 0x00007fafc51e4b45 pthread_mutex_lock (libpthread.so.0) + #2 0x000055b269c21a39 qemu_mutex_lock (qemu-system-x86_64) + #3 0x000055b26992bf51 qemu_mutex_lock_iothread (qemu-system-x86_64) + #4 0x000055b269c30430 call_rcu_thread (qemu-system-x86_64) + #5 0x00007fafc51e2484 start_thread (libpthread.so.0) + #6 0x00007fafc4f216dd __clone (libc.so.6) + +builded with GCC 6.1.1 + +greetings \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1637447 b/results/classifier/deepseek-r1:14b/output/vnc/1637447 new file mode 100644 index 000000000..6fdaceb07 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1637447 @@ -0,0 +1,13 @@ + +VNC/RFB: QEMU reports incorrect name (length) + +If the name of a machine (as set with the -name argument) has a length longer than 1024, (RFB) VNC clients will not receive a correct RFB ServerInit message. + +I suspect this is the problem: + +https://github.com/qemu/qemu/blob/master/ui/vnc.c#L2463 + +The return value of snprintf is used as the value for the name-length field in the ServerInit message. +This is problematic for names that were truncated to 1024, as the length will now be bigger than the actual name. + +I think a quick fix would be to simply report min(size,1024) to the client... \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1653 b/results/classifier/deepseek-r1:14b/output/vnc/1653 new file mode 100644 index 000000000..751a0d3ef --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1653 @@ -0,0 +1,21 @@ + +qemu uses uefi to install the redhad6.0 VM, use the vnc connect it which is stuck +Description of problem: +I want to use uefi(udk2-->ovmf.fd) to install redhad6.0, but after I enter uefi and start up, I cannot use vnc to connect to it,The screen is black or often stuck, nor can I use the console of other pages, or it is a special slow to be able to use it. It's sure that the virtual machine is not crash. Anad the same operation is normal for redhad6.1 systems. +Steps to reproduce: +1.compile udk2 generate ovmf.fd +compile config: + +make -C BaseTools/Source/C + +./OvmfPkg/build.sh -D DEBUG_ON_SERIAL_PORT=true + + +2.run qemu with "-bios /bin/OVMF.fd" + + +3.use vnc to connet it + + + +The screen is stuck can't handle it. diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1661176 b/results/classifier/deepseek-r1:14b/output/vnc/1661176 new file mode 100644 index 000000000..219921d82 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1661176 @@ -0,0 +1,5 @@ + +[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. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1665789 b/results/classifier/deepseek-r1:14b/output/vnc/1665789 new file mode 100644 index 000000000..a1982d999 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1665789 @@ -0,0 +1,8 @@ + +More resolutions for vga displays + +Would it be possible to add more resolutions for vga displays (which I am accessing via vnc instead of spice)? In particular: + +- 1080 wide x 1920 high (rotate 1920 x 1080 screen) + +- 1920 wide x 1080 + 1980 high (1920 x 1080 screen on top of 1600 x 900 screen) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1665791 b/results/classifier/deepseek-r1:14b/output/vnc/1665791 new file mode 100644 index 000000000..7251150c4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1665791 @@ -0,0 +1,4 @@ + +Multiple displays each attached to a separate vnc connection + +Would it be possible to create two displays in qemu (for windows 10) with each accessible by a separate vnc connection? I think this already exists for spice (and I would like it because vnc works better for me than does spice) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1670377 b/results/classifier/deepseek-r1:14b/output/vnc/1670377 new file mode 100644 index 000000000..96b13a672 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1670377 @@ -0,0 +1,38 @@ + + VNC: short read for zlre data/RDR EndOfStream + +In openQA we have a custom VNC client (https://github.com/os-autoinst/os-autoinst/tree/master/consoles), which connects to QEMU guest and from there performs actions (sends keys, handles pointer, ...). We have several backends (https://github.com/os-autoinst/os-autoinst/tree/master/backend). With qemu backend we start QEMU guest *locally* on openQA worker which connects to it via VNC and sends commands. That works fine. + +However, with svirt backend we start QEMU on a KVM or Xen host and then connect to it remotely from openQA worker - the guest and worker are different systems. In this scenario fairly often happens that while system operates in Grub2, QEMU stops sending data via VNC: + +... +15:24:15.5341 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:50 called testapi::send_key +15:24:15.5342 27074 <<< testapi::send_key(key='c') +15:24:15.7361 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:51 called testapi::type_string +15:24:15.7362 27074 <<< testapi::type_string(string='gfxmode=1024x768; terminal_output console; terminal_output gfxterm +', max_interval=250, wait_screen_changes=0) +15:24:22.2243 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:53 called testapi::send_key +15:24:22.2244 27074 <<< testapi::send_key(key='esc') +15:24:22.4255 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:79 called testapi::send_key +15:24:22.4256 27074 <<< testapi::send_key(key='e') +15:24:22.6264 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.6265 27074 <<< testapi::send_key(key='down') +15:24:22.8273 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.8274 27074 <<< testapi::send_key(key='down') +15:24:23.0282 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:23.0283 27074 <<< testapi::send_key(key='down') +DIE short read for zlre data 107132 - 995002 at /usr/lib/os-autoinst/consoles/VNC.pm line 978. + + at /usr/lib/os-autoinst/backend/baseclass.pm line 73. +... + +My observation is that it happens only while in Grub, when resolution happened a short while ago. See attached video and log. + +Prior to QEMU 2.8.0 I was able to reproduce a similar issue with vncviewer. I started QEMU with SLES JeOS image pressed several times a 'down' key in Grub and vncviewer (Tiger VNC 1.6.0 from openSUSE Leap 42.2) crashed with rdr::EndOfStream exception. This does not happen with QEMU 2.8.0, but I am still able to reproduce similar issue via openQA. + +/usr/bin/qemu-system-x86_64 -name guest=openQA-SUT-20,debug-threads=on -S -machine pc-i440fx-2.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 87535fc1-e693-41b9-813e-834d6fc4cb5a -no-user-config -nodefaults -rtc base=utc -no-reboot -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/openQA-SUT-20.img,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:12:34:56,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-tablet-pci,id=input0,bus=pci.0,addr=0x6 -device virtio-keyboard-pci,id=input1,bus=pci.0,addr=0x7 -vnc 0.0.0.0:20,share=force-shared -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on -monitor stdio + +Host: openSUSE Leap 42.2 x86_64 KVM or Xen on x86_64 Intel with QEMU 2.6.0. +Guest: Leap 42.2. + +I can't reproduce the problem with QEMU 2.5.0, but I can with any QEMU version from 2.6 RC1 on. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/170 b/results/classifier/deepseek-r1:14b/output/vnc/170 new file mode 100644 index 000000000..76efcdf1b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/170 @@ -0,0 +1,2 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1715186 b/results/classifier/deepseek-r1:14b/output/vnc/1715186 new file mode 100644 index 000000000..dc62c31bc --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1715186 @@ -0,0 +1,13 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1717414 b/results/classifier/deepseek-r1:14b/output/vnc/1717414 new file mode 100644 index 000000000..b86ecbd9d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1717414 @@ -0,0 +1,27 @@ + +Sending certain keysyms results in wrong symbol input + +I develop bVNC, an Android VNC client. I noticed that when I connect to qemu VMs that have a VNC console, Keysyms that are usually sent over with SHIFT modifier when connecting from a PC have wrong symbols typed within the VM. A very short list of examples: + +exclam 33 0x0021 + +results in "1" typed in the VM. + +at 64 0x0040 + +results in "2" + +plus 43 0x002b + +results in "=" + +asterisk 42 0x002a + +results in "8" + +On Android, KEYCODEs that correspond to the above keysyms do not come with SHIFT metastate. Therefore, the keysyms that they correspond to are not sent over with any modifiers and must just work. + +The issue was reproduced with bVNC and RealVNC viewers connecting to many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The qemu version that comes with oVirt 4.1 is 2.6.0, commit hash bfc766d38e1fae5767d43845c15c79ac8fa6d6af. + +Sincerely, +iordan \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1732671 b/results/classifier/deepseek-r1:14b/output/vnc/1732671 new file mode 100644 index 000000000..098fa7341 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1732671 @@ -0,0 +1,10 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1738283 b/results/classifier/deepseek-r1:14b/output/vnc/1738283 new file mode 100644 index 000000000..885cb8544 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1738283 @@ -0,0 +1,12 @@ + +'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC + +If I start QEMU 2.11 (from https://build.opensuse.org/package/show/Virtualization/qemu) VM with VNC, I am unable to type following three characters: 'less than' (<), 'more than' (>), and 'pipe' (|) on en_US QWERTY keyboard. Other characters work fine. QEMu version 2.10.1 worked fine. + +/usr/bin/qemu-kvm -m 2048 -cpu kvm64 -drive media=cdrom,if=none,id=cd0,format=raw,file=OI-hipster-minimal-20171031.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -vnc :91,share=force-shared + +The ISO can be downloaded here: https://www.openindiana.org/download/ + +Also tried Fedora-Server-dvd-x86_64-25-1.3.iso and it's the same situation. + +If I run the same command without '-vnc :91,share=force-shared', everything works just fine. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1795100 b/results/classifier/deepseek-r1:14b/output/vnc/1795100 new file mode 100644 index 000000000..8cd784053 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1795100 @@ -0,0 +1,33 @@ + +VNC unix-domain socket unlink()ed prematurely + +With qemu 3.0.0 (I don't believe this happened with previous +versions), if I tell it `-vnc unix:/path/to/vnc.sock`, qemu will +unlink() that file when the first client disconnects, meaning that +once I disconnect, I can't ever reconnect without restarting the VM. + +A stupid testcase demonstrating the issue: + +In terminal A: + + $ qemu-system-x86_64 -vnc unix:$PWD/vnc.sock + +In terminal B: + + $ ls vnc.sock + vnc.sock + $ socat STDIO UNIX-CONNECT:vnc.sock <<<'' + RFB 003.008 + $ ls vnc.sock + ls: cannot access 'vnc.sock': No such file or directory + +I have determined that the offending unlink() call is the one in +io/channel-socket.c:qio_channel_socket_close(). That call was first +introduced in commit d66f78e1eaa832f73c771d9df1b606fe75d52a50, which +first appeared in version 3.0.0. + +This type of premature unlink() does not happen on monitor.sock with +`-monitor unix:/path/to/monitor.sock,server,nowait`. + +I am not familiar enough with the QIO subsystem to suggest a fix that +fixes VNC, but preserves the QMP fix targeted in the offending commit. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1802465 b/results/classifier/deepseek-r1:14b/output/vnc/1802465 new file mode 100644 index 000000000..cdb9ace58 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1802465 @@ -0,0 +1,28 @@ + +typing string via VNC is unreliable + +QEMU version is 3.0.0 + +# Description + +The problem is that, when typing string through VNC, it can be unreliable -- sometimes some key strokes get skipped, sometimes get swapped, sometimes get repeated. There's no problem when typing through VNC on physical hardware. + +# Steps to reproduce + +1. Launch virtual machine by: + + qemu-kvm -display vnc=:1 -m 2048 opensuse-leap-15.qcow2 + +2. Connect to VNC by: + + vncviewer -Shared :5901 + +3. Simulate a series of key strokes by "vncdotool" [1]: + + vncdotool -s 127.0.0.1::5901 typefile strings_to_be_typed.txt + +4. Usually after a few hundred keys are typed, something goes wrong. + +I attached a screenshot that it mistypes " hello" to "h ello". + +[1] https://github.com/sibson/vncdotool \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1809252 b/results/classifier/deepseek-r1:14b/output/vnc/1809252 new file mode 100644 index 000000000..64d1769f9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1809252 @@ -0,0 +1,8 @@ + +Password authentication in FIPS-compliant mode + +The documentation states, that: + +"The VNC protocol has limited support for password based authentication. (...) Password authentication is not supported when operating in FIPS 140-2 compliance mode as it requires the use of the DES cipher." + +Would it be possible for qemu to use a different cipher and re-enable password as an option in VNC console? Is there a technical reason for not using a stronger cipher? \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1828207 b/results/classifier/deepseek-r1:14b/output/vnc/1828207 new file mode 100644 index 000000000..131d5bdf2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1828207 @@ -0,0 +1,7 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server + +In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on. +Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability. + +Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1849644 b/results/classifier/deepseek-r1:14b/output/vnc/1849644 new file mode 100644 index 000000000..096ddacf6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1849644 @@ -0,0 +1,14 @@ + +QEMU VNC websocket proxy requires non-standard 'binary' subprotocol + +When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version. + +When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect. + +One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior. + +Looking at the code in "io/channel-websock.c" it seems it's quite hard-coded to binary: + +Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c + +This code has to be made more dynamic, and shouldn't require binary. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1858623 b/results/classifier/deepseek-r1:14b/output/vnc/1858623 new file mode 100644 index 000000000..971eea27d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1858623 @@ -0,0 +1,15 @@ + +VNC outputs garbage in zlib mode + +TL;DR: When QEMU is launched with VNC as the output and viewed with a client that defaults to zlib VNC encoding, the resulting output tends to accumulate artifacts. + +Reproduction: +Launch QEMU (tried with versions 4.2.0 and 4.1.0 on Linux 64bit) with -vnc 0.0.0.0:0 +Connect to it with a VNC client that allows you to select encoding, i.e. UltraVNC. +Set encoding to zlib (type 6), 32bit color. +As screen content changes it starts accumulating artifacts. Almost certain to appear if you open-close windows over a pattern. +Does not seem to depend on guest used, but easier to reproduce with a GUI. + +Looks like this: https://orbides.org/img/vnc.png + +It appears to be a deflate glitch of some sort - all of the bad pixels are generated by length/distance codes. Can't narrow it down any more. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1894818 b/results/classifier/deepseek-r1:14b/output/vnc/1894818 new file mode 100644 index 000000000..7f4c2d7f4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1894818 @@ -0,0 +1,20 @@ + +COLO's guest VNC client hang after failover + +Hello, + +After setting up COLO's primary and secondary VMs, +I installed the vncserver and xrdp (apt install tightvncserver xrdp) inside the VM. + +I access the VM from another PC via VNC/RDP client, and everything is OK. +Then, kill the primary VM and issue the failover commands. + +The expected result is that the VNC/RDP client can resume after failover. +But in my test, the VNC client's screen hangs and cannot be recovered no longer. + +BTW, it works well after killing SVM. + +Thanks. + +Regards, +Derek \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/1895219 b/results/classifier/deepseek-r1:14b/output/vnc/1895219 new file mode 100644 index 000000000..eb24ec0fb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/1895219 @@ -0,0 +1,12 @@ + +qemu git -vnc fails due to missing en-us keymap + +If trying to run qemu with -vnc :0, it will fail with: +./qemu-system-x86_64 -vnc :2 +qemu-system-x86_64: -vnc :2: could not read keymap file: 'en-us' + +share/keymaps is missing en-us keymap and only has sl and sv, confirmed previous stable versions had en-us. + +Tried with multiple targets, on arm64 and amd64 + +Git commit hash: 9435a8b3dd35f1f926f1b9127e8a906217a5518a (head) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/2492 b/results/classifier/deepseek-r1:14b/output/vnc/2492 new file mode 100644 index 000000000..21a5975b7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/2492 @@ -0,0 +1,21 @@ + +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/deepseek-r1:14b/output/vnc/2608 b/results/classifier/deepseek-r1:14b/output/vnc/2608 new file mode 100644 index 000000000..b354fd614 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/2608 @@ -0,0 +1,10 @@ + +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/deepseek-r1:14b/output/vnc/2668 b/results/classifier/deepseek-r1:14b/output/vnc/2668 new file mode 100644 index 000000000..de13500b5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/2668 @@ -0,0 +1,4 @@ + +h.264 encoding/compression support +Additional information: +noVNC now support h.264 decoding. diff --git a/results/classifier/deepseek-r1:14b/output/vnc/2836 b/results/classifier/deepseek-r1:14b/output/vnc/2836 new file mode 100644 index 000000000..0047f32b3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/2836 @@ -0,0 +1,44 @@ + +readconfig with [vnc] only causes assertion failure +Description of problem: +Given test.config containing +``` +[vnc] +``` + +``` +$ qemu-system-amd64 -readconfig test.config +qemu-system-amd64: ui/vnc.c:4294: vnc_init_func: Assertion `id' failed. +Aborted +``` + + +``` +(gdb) bt +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) + at ./nptl/pthread_kill.c:44 +#1 0x00007ffff68f3e2f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:78 +#2 0x00007ffff689fd02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007ffff68884f0 in __GI_abort () at ./stdlib/abort.c:79 +#4 0x00007ffff6888418 in __assert_fail_base (fmt=0x7ffff6a0cca0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55555608eef6 "id", file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294, + function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:96 +#5 0x00007ffff6898612 in __assert_fail (assertion=assertion@entry=0x55555608eef6 "id", + file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294, + function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:105 +#6 0x0000555555a03adb in vnc_init_func (opaque=<optimized out>, opts=<optimized out>, + errp=0x5555570db038 <error_fatal>) at ui/vnc.c:4294 +#7 0x0000555556037b31 in qemu_opts_foreach (list=<optimized out>, func=0x555555a039f0 <vnc_init_func>, + opaque=opaque@entry=0x0, errp=errp@entry=0x5555570db038 <error_fatal>) at util/qemu-option.c:1135 +#8 0x0000555555c41eff in qemu_init_displays () at system/vl.c:2619 +#9 qemu_init (argc=<optimized out>, argv=<optimized out>) at system/vl.c:3762 +#10 0x00005555559e1c0d in main (argc=<optimized out>, argv=<optimized out>) at system/main.c:47 +``` + +https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L4294 + +Passing an invalid value to id results in `qemu-system-amd64: -readconfig test.config: Parameter 'id' expects an identifier +Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.` so perhaps a missing value should cause a similar error? + + +PS: Where's the documentation for `-readconfig`? diff --git a/results/classifier/deepseek-r1:14b/output/vnc/2949 b/results/classifier/deepseek-r1:14b/output/vnc/2949 new file mode 100644 index 000000000..08655c508 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/2949 @@ -0,0 +1,18 @@ + +VNC: virtio-gpu outputs not displayed by VNC client +Description of problem: +When combining virtio-gpu multiple outputs with VNC display, only output 0 is enabled. +Additional output are enabled when VNC client sent SetDesktopSize command. + +The following statement assumes that all displays (gtk, sdl) are disabled except VNC: + +# +Steps to reproduce: +1. Start Qemu +2. Start a VNC client on 5900 +3. Start the second VNC client on 5901 +Additional information: +The state of an output is controlled by the [enabled_output_bitmask](https://gitlab.com/qemu-project/qemu/-/blob/master/include/hw/virtio/virtio-gpu.h#L158) which is initialized to `1` at [device realization](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L204), thus VNC0 is always enabled. + +Other devices will set this parameter during inititliazation by calling [dpy_set_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/console.c#L754) which schedules a call to [virtio_gpu_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L89). However VNC calls this function only when handling [VNC_MSG_CLIENT_SET_DESKTOP_SIZE](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L2607) client command.\ +If the client does not support this command or never changes the size of the default window, the respective display will remain disabled. diff --git a/results/classifier/deepseek-r1:14b/output/vnc/351 b/results/classifier/deepseek-r1:14b/output/vnc/351 new file mode 100644 index 000000000..2c0d18650 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/351 @@ -0,0 +1,2 @@ + +German keyboard vnc issue diff --git a/results/classifier/deepseek-r1:14b/output/vnc/397212 b/results/classifier/deepseek-r1:14b/output/vnc/397212 new file mode 100644 index 000000000..fdf2a33cd --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/397212 @@ -0,0 +1,10 @@ + +Scrolling artifacts on some guests + +Screen doesn't refresh properly when scrolling (see the attachment). + +The behavior is seen on RHEL 4.8 and SLES 11, but not on RHEL 5.3. However, on RHEL5.3, scrolling is very sluggish. It seems to be a trade-off between quick movement and frequent / accurate refreshing. + +Command line: + +qemu-system-x86_64 -m 2048 -drive file=/scratch/images/SLES-11-GMC-x86_64.raw -net nic,vlan=0,macaddr=DE:AD:BE:EF:88:95,model=rtl8139 -net tap -vnc :40 -boot cd -monitor stdio -smp 4 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/498039 b/results/classifier/deepseek-r1:14b/output/vnc/498039 new file mode 100644 index 000000000..8255a5380 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/498039 @@ -0,0 +1,10 @@ + +No copy/paste with VNC display with Windows guest + +There is no copy/paste functionality between a Windows guest and the VNC client. This is a significant usability problem. + +One work-around is to run VNC inside of the guest. But that appears to have more overhead than qemu's VNC display. + +Obviously, qemu's VNC display is just a display device and knows absolutely nothing about the Windows clipboard. Thus, to interface with the guest's clipboard would require a helper app running in the guest that can hook into qemu. This would probably be the best solution. + +There are probably not a lot of qemu developers interested in trying to write the helper app. Not exactly an interesting job. But since it is a significant usability problem, and many users would see this as a major oversight, I suggest leaving this bug open long-term as a hint so that some volunteer later looking for something to do might take pity on everyone and write this helper app. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/595 b/results/classifier/deepseek-r1:14b/output/vnc/595 new file mode 100644 index 000000000..56fb2e687 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/595 @@ -0,0 +1,12 @@ + +QEMU VNC mouse doesn't move in tablet mode os9 +Description of problem: +What I am trying to do is have a headless os9 running in QEMU on ubuntu and use the native vnc support in QEMU to access the screen. That is setup and works as expected but the mouse only works in ps/2 mode and that is clearly very undesirable (mouse is never lined up). I set it up in tablet mode and when I am in the QEMU window on the host the mouse works perfect (I added tablet mode to os9 with: https://github.com/kanjitalk755/macos9-usb-tablet). That same tablet mode results in the mouse not moving at all over vnc, if I ctrl+alt 2 and switch the mouse type from tablet mode it starts working again but not lined up at all as expected, cant get to any buttons on edges. Is there anyone in here that ran into this? Am I the only one using QEMU VNC? + +Iv thought about running a vnc application on the vm itself but performance was meh at best. Any tips would be worth a lot to me, its a sin to say but I am trying to adapt this into a production environment... + +Upon further investigation this seems to be a issue on Linux. I am testing the QEMU on windows and its working as expected over VNC. That is to say if QEMU is running on a windows host, it just works over vnc with tablet mode. So what could be causing Linux version to not work? I did compile it from source, are there any configure flags I am missing? I am trying to run it on Ubuntu server 21.04 +Steps to reproduce: +1.add vnc option to parameters +2.enable tablet mode and install driver in os9 +3.connect to vnc and mouse doesn't move diff --git a/results/classifier/deepseek-r1:14b/output/vnc/667791 b/results/classifier/deepseek-r1:14b/output/vnc/667791 new file mode 100644 index 000000000..485ccf92e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/667791 @@ -0,0 +1,40 @@ + +Cygwin build fails due to ui/vnc-etc-tight.c + +Configure: +./configure \ +--prefix="./install/bin/" \ +--interp-prefix="./install/bin-%M/" \ +--cc="gcc -mno-cygwin" \ +--host-cc="gcc" \ +--disable-sdl \ +--enable-system \ +--disable-user \ +--disable-linux-user \ +--disable-darwin-user \ +--disable-bsd-user \ +--disable-xen \ +--disable-brlapi \ +--disable-vnc-tls \ +--disable-vnc-sasl \ +--disable-vnc-jpeg \ +--disable-vnc-png \ +--disable-vnc-thread \ +--disable-curses \ +--disable-curl \ +--disable-bluez \ +--disable-kvm \ +--disable-nptl \ +--disable-vde \ +--disable-vhost-net + +Versions of software +Cygwin 1.7 +GNU Make 3.81 +GCC 3.4.4 (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a) +QEMU 0.13.0 + +Result: +Function tight_detect_smooth_image24(...) uses "uint" type, that appears to be not defined in this scope. Prepending this function with +typedef unsigned int uint; +fixes build. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/759 b/results/classifier/deepseek-r1:14b/output/vnc/759 new file mode 100644 index 000000000..351929e2b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/759 @@ -0,0 +1,13 @@ + +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/deepseek-r1:14b/output/vnc/772358 b/results/classifier/deepseek-r1:14b/output/vnc/772358 new file mode 100644 index 000000000..d063d0ed1 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/772358 @@ -0,0 +1,23 @@ + +VNC working depends on command line options order + +OS: Ubuntu 10.04.2, amd64 +Pkg version: 0.12.3+noroms-0ubuntu9.5 + +if -nographic option is specified before -vnc, vnc works, if vice-versa, it does not. I have been told (thanks, mjt), that -nographic is supposed to disable any graphic output, including vnc, so possibly it's a documentation bug: + +- kvm man page talks about -nographic disabling SDL , not VNC. While it might be the same to you, it was not to me and my colleagues + +- if -vnc and -nographic are conflicting, perhaps kvm should error out or at least warn + +- monitor console's message on "change vnc 127.0.0.1:1" command: "Could not start server on 127.0.0.1:1" is not helpful either + +- order of the options should not matter + +Example: (VNC works) + +/usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm-ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -nographic -daemonize -vnc 127.0.0.1:1 -pidfile /var/run/kvm/1 + +Example: (VNC does not work, also confuses terminal): + +/usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm-ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -vnc 127.0.0.1:1 -nographic -daemonize -pidfile /var/run/kvm/1 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/806656 b/results/classifier/deepseek-r1:14b/output/vnc/806656 new file mode 100644 index 000000000..d69e144c3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/806656 @@ -0,0 +1,8 @@ + +Tight PNG VNC encoding is sent even when --disable-vnc-png is set + +This bug exists in 0.14.1 and also in 9312805d33e8b (Jun 17, 2011) in the master git repo. + +The "Tight PNG" encoding is a derivative of the "Tight" encoding that replaces zlib encoded rects with PNG encoded data instead. However, when the "Tight PNG" encoding is disabled (--disable-vnc-png), the server will send frame buffer updates that are marked as "Tight PNG" but in fact contain zlib encoded regions (i.e. it's really "tight" protocol). + +The "Tight PNG" encoding should only be used when --enable-vnc-png is set. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/807 b/results/classifier/deepseek-r1:14b/output/vnc/807 new file mode 100644 index 000000000..79eef675b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/807 @@ -0,0 +1,19 @@ + +TigerVNC client to built-in VNC server causes VM to crash/freeze +Description of problem: +Connecting to the built-in VNC server via TigerVNC upon disconnect the whole VM process freezes/crashes. The process continues to exist but does not respond to any network connection and the monitor socket is dead too. Killing it with TERM doesn't work. + +Using tigervnc-viewer 1.10.1+dfsg-3 (Ubuntu 20.04) with default options like `vncviwer localhost:0` +Steps to reproduce: +* `qemu-system-x86_64 -vnc 127.0.0.1:0` + * Connect to built-in VNC server via TigerVNC + * Keep the VNC connection open and wait some period of time (usually 5-10 minutes is enough though sometimes hours) then disconnect/reconnect VNC. If the reconnect succeeds then wait again for a period of time then disconnect and try again until failure. Often just connecting and disconnecting to the VNC once is enough to make the VM eventually crash/freeze even if running only in the background but this is less reproducible. + * Observe VM is no longer responsive to anything + +If TigerVNC is never connected/disconnected from the VM then this doesn't happen. +Additional information: +Note due to the nature of this issue it might be hard to reproduce for unknown reasons. The VM always eventually freezes though. The qemu process has no output when it freezes. + +As far as I can tell connecting to the built-in VNC server via `gvncviwer` seems to be OK and doesn't cause an issue (?). I'm not sure about other VNC clients (eg. TurboVNC). + +I am connecting to the VNC server from a completely different machine than the host via SSH port redirection (the host is headless). Not sure if that matters. diff --git a/results/classifier/deepseek-r1:14b/output/vnc/824074 b/results/classifier/deepseek-r1:14b/output/vnc/824074 new file mode 100644 index 000000000..4e1de2704 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/824074 @@ -0,0 +1,6 @@ + +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 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/88 b/results/classifier/deepseek-r1:14b/output/vnc/88 new file mode 100644 index 000000000..8556c7bbe --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/88 @@ -0,0 +1,2 @@ + +VNC server does not work with Mac Screen Sharing diff --git a/results/classifier/deepseek-r1:14b/output/vnc/925405 b/results/classifier/deepseek-r1:14b/output/vnc/925405 new file mode 100644 index 000000000..b438a8999 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/925405 @@ -0,0 +1,19 @@ + +VNC server does not work with Mac Screen Sharing + +When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. + +I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. + +It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. + +Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. + +Background info: + +Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: + +* At a terminal, by typing "open vnc://hostname:tcp_port" +* From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port + +Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/974229 b/results/classifier/deepseek-r1:14b/output/vnc/974229 new file mode 100644 index 000000000..da181b91e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/974229 @@ -0,0 +1,50 @@ + +qemu-kvm-1.0: segfault using vnc-console => not threadsafe! + +after failure using qemu-kvm-0.14.1 I've tried v1.0, but there's a problem if compiled with vnc-thread-support: + +Program received signal SIGSEGV, Segmentation fault. +0x0000000000000000 in ?? () +(gdb) bt +#0 0x0000000000000000 in ?? () +#1 0x00007f3ac48ca10a in qemu_iohandler_poll (readfds=0x7fff12379ac0, writefds=0x7fff12379b40, xfds=0x7fff12379bc0, ret=3) + at iohandler.c:124 +#2 0x00007f3ac4964387 in main_loop_wait (nonblocking=0) at main-loop.c:463 +#3 0x00007f3ac4958fb1 in main_loop () at /opt/workspace/oneiric64/qemu-kvm-1.0/vl.c:1482 +#4 0x00007f3ac495e1ec in main (argc=68, argv=0x7fff1237a088, envp=0x7fff1237a2b0) + at /opt/workspace/oneiric64/qemu-kvm-1.0/vl.c:3523 +(gdb) up +#1 0x00007f3ac48ca10a in qemu_iohandler_poll (readfds=0x7fff12379ac0, writefds=0x7fff12379b40, xfds=0x7fff12379bc0, ret=3) + at iohandler.c:124 +124 ioh->fd_write(ioh->opaque); + +(gdb) print *ioh +$4 = {fd = 29, fd_read_poll = 0, fd_read = 0x7f3ac49de158 <vnc_client_read>, fd_write = 0, deleted = 0, + opaque = 0x7f3ac7978d50, next = {le_next = 0x7f3ac6add2e0, le_prev = 0x7f3ac52bde90}} + + +ok, how could that happen? +loooking deeper at the code and backtraces shows, that iohandler.c:124 is called within the main-loop, while iohandler.c:77 is called within the vnc-thread-loop + +mmmh, but where the hell is the threadsafe-locking of the ioh-structure???? + +I didn't found anything... + +the resetting in line 77 is called from vnc_client_write_plain(), where following code can be found: + +=================== + if (vs->output.offset == 0) { + qemu_set_fd_handler2(vs->csock, NULL, vnc_client_read, NULL, vs); + } +=================== + +why should the function-ptrs should be zeroed? + +further tracing shows, that the vnc-thread sometimes seems to exits normally and a new one is started (I haven't verified that), but this would be a reason for zeroing function-ptrs, which may point to code inside the thread, which will exit... + +but why should this be done? and why there's no threadsafe-modification of the structure? + +well: disabling vnc-thread at configure-state leads into a normal running machine, but threading would be nice here... + +so a quick fix could be, to drop the call above and make the vnc-thread staying for the whole session, but I don't know all mechanisms of vnc-support within kvm. +but a better solution would be usage of clean locking-mechanisms \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/vnc/981 b/results/classifier/deepseek-r1:14b/output/vnc/981 new file mode 100644 index 000000000..0f2e910d1 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/981 @@ -0,0 +1,11 @@ + +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 + ``` diff --git a/results/classifier/deepseek-r1:14b/output/vnc/994412 b/results/classifier/deepseek-r1:14b/output/vnc/994412 new file mode 100644 index 000000000..c35a641c0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/vnc/994412 @@ -0,0 +1,9 @@ + +reverse vnc to unix domain sockets does not work + +I tried to connect to a unix domain socket, but failed. + +$ qemu -vnc unix:/tmp/my.sock,reverse +connect(unix:/tmp/my.sock,reverse): No such file or directory + +I guess it is because unix_connect does not remove characters after first comma. \ No newline at end of file |