Description of problem: The GTK-VNC widget used by virt-manager/virt-viewer, uses Cairo for rendering the pixmap to its window. When rendering, it will optionally apply a scaling factor to enlarge/shrink the VNC desktop above/below its natural size. Since upgrading from F11 to F12, rendering the VNC desktop pixmap with scaling factor is incredibly slow. eg when switching virt-viewer to fullscreen mode, it will take 15-20 seconds to render the whole page, I can see each individual scan line being drawn very slowly, and Xorg has pegged the CPU at 100%. After Xorg has finally finished rendering the pixmap, it'll often dump the following to its log file, which seems to suggest that its doing software rendering, rather than hardware accelerated. [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c] 1: /usr/bin/Xorg (mieqEnqueue+0x1b7) [0x80e51a7] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xd4) [0x80bf8a4] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x17e000+0x3172) [0x181172] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x17e000+0x3466) [0x181466] 5: /usr/bin/Xorg (0x8047000+0x6b1f0) [0x80b21f0] 6: /usr/bin/Xorg (0x8047000+0x11ed24) [0x8165d24] 7: (vdso) (__kernel_sigreturn+0x0) [0x536400] 8: /usr/lib/libpixman-1.so.0 (0xd02000+0x57aa) [0xd077aa] 9: /usr/lib/libpixman-1.so.0 (0xd02000+0x4119f) [0xd4319f] 10: /usr/lib/libpixman-1.so.0 (0xd02000+0x1477a) [0xd1677a] 11: /usr/lib/libpixman-1.so.0 (0xd02000+0x39d50) [0xd3bd50] 12: /usr/lib/libpixman-1.so.0 (0xd02000+0x41a7a) [0xd43a7a] 13: /usr/lib/libpixman-1.so.0 (0xd02000+0x42c9b) [0xd44c9b] 14: /usr/lib/libpixman-1.so.0 (0xd02000+0x399f4) [0xd3b9f4] 15: /usr/lib/libpixman-1.so.0 (0xd02000+0x152f4) [0xd172f4] 16: /usr/lib/libpixman-1.so.0 (0xd02000+0x3b9af) [0xd3d9af] 17: /usr/lib/libpixman-1.so.0 (0xd02000+0x152f4) [0xd172f4] 18: /usr/lib/libpixman-1.so.0 (0xd02000+0x46df4) [0xd48df4] 19: /usr/lib/libpixman-1.so.0 (0xd02000+0x152f4) [0xd172f4] 20: /usr/lib/libpixman-1.so.0 (0xd02000+0x4d5ca) [0xd4f5ca] 21: /usr/lib/libpixman-1.so.0 (0xd02000+0x152f4) [0xd172f4] 22: /usr/lib/libpixman-1.so.0 (pixman_image_composite+0x177) [0xd3c847] 23: /usr/lib/xorg/modules/libfb.so (fbComposite+0x170) [0x173d70] 24: /usr/lib/xorg/modules/libexa.so (0xefe000+0xfa5b) [0xf0da5b] 25: /usr/lib/xorg/modules/libexa.so (0xefe000+0xd11e) [0xf0b11e] 26: /usr/bin/Xorg (0x8047000+0xd4a07) [0x811ba07] 27: /usr/bin/Xorg (CompositePicture+0x290) [0x810eef0] 28: /usr/bin/Xorg (0x8047000+0xce125) [0x8115125] 29: /usr/bin/Xorg (0x8047000+0xcacb4) [0x8111cb4] 30: /usr/bin/Xorg (0x8047000+0x271f7) [0x806e1f7] 31: /usr/bin/Xorg (0x8047000+0x1b8c5) [0x80628c5] 32: /lib/libc.so.6 (__libc_start_main+0xe6) [0x239bb6] 33: /usr/bin/Xorg (0x8047000+0x1b4b1) [0x80624b1] If I reboot and add 'nomodeset' to grub kernel command line, then scaled rendering will be done at expected, very fast, speeds on a par with F11, so it appears the problem is only present with KMS. I do not have any /etc/Xorg/xorg.conf file, so it should be using the driver defaults for everything Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.i686 xorg-x11-server-Xorg-1.7.1-7.fc12.i686 kernel 2.6.31.5-127.fc12.i686.PAE How reproducible: Only when booted with KMS active. Steps to Reproduce: 1. Start a guest virtual machine with libvirt 2. Run 'virt-viewer GUESTNAME' 3. Select menu View -> Full Screen Actual results: Switches to fullscreen and takes 20 seconds to draw the screen Expected results: No noticeable delay when drawing Additional info: I will attach log files, etc....
Created attachment 370124 [details] lspci -vv output
Created attachment 370125 [details] lspci -vvn output
Created attachment 370126 [details] dmesg when using KMS
Created attachment 370127 [details] xdpyinfo when using KMS
Created attachment 370128 [details] Xorg.0.log when using KMS
Created attachment 370129 [details] dmesg when booted with 'nomodeset'
Created attachment 370130 [details] xdpyinfo when booted with 'nomodeset'
Created attachment 370131 [details] Xorg.0.log when booted with 'nomodeset'
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I am observing the same behaviour on my Thinkpad T60 with an ATI Radeon Mobility X1400. With KMS enabled virt-viewer is working fine in window mode but becomes extremely slow when switching to fullscreen. Without KMS (adding 'nomodeset' to the kernel) both, window and fullscreen mode, are working fine.
Improving summary. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers [This triage is part of collective effort done by students of University of Rijeka Department of Informatics.]
This looks like the same issue as these upstream bugs: https://bugs.freedesktop.org/show_bug.cgi?id=27139 https://bugs.freedesktop.org/show_bug.cgi?id=28670
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.