From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 19:39:53 +0200 Subject: restructure results --- results/classifier/014/vnc/11357571 | 74 ------------------------------------- 1 file changed, 74 deletions(-) delete mode 100644 results/classifier/014/vnc/11357571 (limited to 'results/classifier/014/vnc') diff --git a/results/classifier/014/vnc/11357571 b/results/classifier/014/vnc/11357571 deleted file mode 100644 index c821f311..00000000 --- a/results/classifier/014/vnc/11357571 +++ /dev/null @@ -1,74 +0,0 @@ -vnc: 0.950 -graphic: 0.915 -performance: 0.806 -device: 0.763 -network: 0.705 -semantic: 0.694 -PID: 0.681 -ppc: 0.632 -peripherals: 0.629 -socket: 0.600 -operating system: 0.594 -debug: 0.572 -boot: 0.571 -architecture: 0.568 -risc-v: 0.550 -x86: 0.534 -i386: 0.520 -permissions: 0.517 -KVM: 0.516 -mistranslation: 0.516 -hypervisor: 0.508 -VMM: 0.505 -kernel: 0.480 -TCG: 0.462 -register: 0.454 -files: 0.453 -user-level: 0.433 -arm: 0.405 -assembly: 0.389 -alpha: 0.379 -virtual: 0.376 - -[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 ? - -- cgit 1.4.1