Description of problem: When enter grub of the guest, the interface responses very slow Version-Release number of selected component (if applicable): Host kernel: 3.10.0-201.el7.ppc64 Guest kernel: 3.10.0-195.el7.ppc64/3.10.0-196.ael7a.ppc64le qemu-kvm: qemu-img-rhev-2.1.2-14.el7.ppc64 qemu-kvm-tools-rhev-2.1.2-14.el7.ppc64 qemu-kvm-common-rhev-2.1.2-14.el7.ppc64 qemu-kvm-rhev-2.1.2-14.el7.ppc64 qemu-kvm-rhev-debuginfo-2.1.2-14.el7.ppc64 How reproducible: 100% Steps to Reproduce: 1. Define and start a guest with virsh command 2. After the guest boot up, reboot the guest to enter its grub interface 3. Try to type some words Actual results: In step2, it would take a while before the grub screen refresh the whole info In step3, after type the words, the curser would move right and left in the line before it could find its right position Expected results: In step2, The grub srceen could refresh the whole info in a minute In step3, after type any words, the curser could move correctly Additional info:
The bug also exists on power system, the software versions are as follows: Host kernel: 3.10.53-2020.1.pkvm2_1_1.49.ppc64 Qemu kvm: qemu-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-debuginfo-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-common-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-kvm-tools-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-img-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-kvm-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-system-x86-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-system-ppc-2.0.0-2.1.pkvm2_1_1.20.40.ppc64
------- Comment From fnovak.com 2015-02-06 13:07 EDT------- reverse mirror of RHBZ 1170937 - [Power KVM] Grub interface of guest response slow
What method are you using to access the VM's console? Is it graphical or text?
(In reply to David Gibson from comment #4) > What method are you using to access the VM's console? Is it graphical or > text? That's text.
Since this occurs on a RHEL host too, cloning to RHEL bug 1212256.
A possible solution for this problem is described here: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-May/129286.html
------- Comment From KURZGREG.com 2015-05-29 07:35 EDT------- The final patchset was applied today to the upstream repository (URLs below): https://github.com/aik/SLOF/commit/57ca8e04b426aed43d51eb67805abd5eb9c4449f which reads "fbuffer: simplify address computations in fb8-toggle-cursor" https://github.com/aik/SLOF/commit/4c7a70f0619534f5870d4043f1751259046db02f which reads "fbuffer: introduce the invert-region helper" https://github.com/aik/SLOF/commit/99c534ecc7a8566bd9ca6346915d9ac1bfacae1e which reads "fbuffer: introduce the invert-region-x helper" Cheers.
Gu Nini, to be able to fully reproduce and verify the fix for this issue, I think I need the XML definition of the guest where you discovered this problem. Could you please attach it to this bug ticket (i.e. the output of "virsh dumpxml ...")?
(In reply to Gu Nini from comment #5) > (In reply to David Gibson from comment #4) > > What method are you using to access the VM's console? Is it graphical or > > text? > > That's text. I assume that you you're using VNC to view the console of the guest? Or did you use "virsh console ..." to see it in your normal terminal window?
Created attachment 1031738 [details] virsh_dumpxml-Bz1170937
(In reply to Thomas Huth from comment #11) > (In reply to Gu Nini from comment #5) > > (In reply to David Gibson from comment #4) > > > What method are you using to access the VM's console? Is it graphical or > > > text? > > > > That's text. > > I assume that you you're using VNC to view the console of the guest? Or did > you use "virsh console ..." to see it in your normal terminal window? Yes, I have been using the VNC connection. For the xml definition needed in comment 10, please refer to the attachment in comment 12.
Ok, thanks for the information ... Now I am pretty sure that Greg Kurz's patches are the right fix for this problem (since these are about a fix in the firmware graphics card driver - which would not apply if you had used "virsh console ..." instead)
------- Comment From KURZGREG.com 2015-05-29 09:54 EDT------- (In reply to comment #12) > (In reply to Thomas Huth from comment #11) > > (In reply to Gu Nini from comment #5) > > > (In reply to David Gibson from comment #4) > > > > What method are you using to access the VM's console? Is it graphical or > > > > text? > > > > > > That's text. > > I assume that you you're using VNC to view the console of the guest? Or did > > you use "virsh console ..." to see it in your normal terminal window? > Yes, I have been using the VNC connection. > For the xml definition needed in comment 10, please refer to the attachment > in comment 12. FWIW, a much simpler reproducer is: qemu-system-ppc64 -enable-kvm -vnc :66 -cdrom /any/distro/install/iso
IBM, We're now in the process of fixing this on the RHEL side by applying Greg Kurz' patches. You should do the same if you're not already. For reference, the commits you need from Alexey's SLOF tree are: 57ca8e0 fbuffer: simplify address computations in fb8-toggle-cursor 4c7a70f fbuffer: introduce the invert-region helper 99c534e fbuffer: introduce the invert-region-x helper
I think this has been fixed in the latest version of pkvm, at least SLOF-0.1.git20150601-1.1.pkvm2_1_1.12 seems to contain the "invert-region-x" fix. So is it OK to close this ticket now?
Gu Nini, could you please check whether the latest version is working better now?
(In reply to Thomas Huth from comment #18) > Gu Nini, could you please check whether the latest version is working better > now? Thomas, This bug had been originally reported on ppc64 host; while it was copied to ppc64le host with bz 1212256, which was verified/closed after bisecting another 2 bugs bz 1237052(verified/closed) and bz 1248448(new). Thus, should we still check it on ppc64 host?
Since BZ 1212256 has already been verified/closed, and ppc64le is now our main architecture for RHEV, I think it should be OK to close this bug directly. So I'm closing it as "EOL" now - if anybody disagrees, please feel free to open this ticket again (e.g. in case we need more detailed testing).