restructure results

1 files changed, 0 insertions, 74 deletions

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 ?
-