diff options
Diffstat (limited to 'results/classifier/111/review/11357571')
| -rw-r--r-- | results/classifier/111/review/11357571 | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/results/classifier/111/review/11357571 b/results/classifier/111/review/11357571 new file mode 100644 index 00000000..3de4e2f4 --- /dev/null +++ b/results/classifier/111/review/11357571 @@ -0,0 +1,71 @@ +vnc: 0.171 +graphic: 0.152 +semantic: 0.127 +other: 0.123 +device: 0.077 +PID: 0.056 +performance: 0.049 +boot: 0.047 +permissions: 0.041 +network: 0.038 +debug: 0.036 +socket: 0.033 +files: 0.026 +KVM: 0.025 +debug: 0.506 +vnc: 0.213 +network: 0.123 +graphic: 0.046 +boot: 0.022 +performance: 0.020 +other: 0.016 +files: 0.014 +PID: 0.010 +device: 0.008 +socket: 0.006 +semantic: 0.005 +KVM: 0.005 +permissions: 0.005 + +[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 ? + |