diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/none/1802 | 39 | ||||
| -rw-r--r-- | results/classifier/118/none/1802150 | 92 | ||||
| -rw-r--r-- | results/classifier/118/none/1802915 | 71 |
3 files changed, 202 insertions, 0 deletions
diff --git a/results/classifier/118/none/1802 b/results/classifier/118/none/1802 new file mode 100644 index 00000000..db7354c1 --- /dev/null +++ b/results/classifier/118/none/1802 @@ -0,0 +1,39 @@ +device: 0.790 +ppc: 0.687 +arm: 0.633 +graphic: 0.537 +socket: 0.488 +permissions: 0.470 +files: 0.458 +performance: 0.449 +register: 0.445 +network: 0.422 +vnc: 0.411 +architecture: 0.406 +semantic: 0.395 +boot: 0.302 +debug: 0.279 +VMM: 0.216 +PID: 0.202 +risc-v: 0.174 +peripherals: 0.152 +TCG: 0.144 +i386: 0.099 +hypervisor: 0.083 +user-level: 0.080 +mistranslation: 0.080 +KVM: 0.065 +x86: 0.056 +virtual: 0.035 +kernel: 0.020 +assembly: 0.015 + +windows serial COM PollingFunc don't sleep if guest uart can't write +Description of problem: +If two or more characters are sent from the host to the guest via Windows Com/Serial, everything freezes. +Steps to reproduce: +1. +2. +3. +Additional information: +I fix it in qemu/chardev/char-win.c see attached file diff --git a/results/classifier/118/none/1802150 b/results/classifier/118/none/1802150 new file mode 100644 index 00000000..aaca4571 --- /dev/null +++ b/results/classifier/118/none/1802150 @@ -0,0 +1,92 @@ +device: 0.617 +graphic: 0.526 +virtual: 0.492 +socket: 0.378 +semantic: 0.363 +performance: 0.342 +ppc: 0.318 +mistranslation: 0.299 +hypervisor: 0.282 +VMM: 0.282 +architecture: 0.258 +network: 0.256 +boot: 0.254 +kernel: 0.231 +PID: 0.205 +KVM: 0.199 +vnc: 0.197 +i386: 0.174 +register: 0.172 +risc-v: 0.156 +TCG: 0.155 +arm: 0.149 +x86: 0.144 +permissions: 0.104 +assembly: 0.098 +peripherals: 0.090 +files: 0.077 +debug: 0.068 +user-level: 0.062 + +Guest undefined when destroyed on host after migration + +After a live migration, guest VMs are being undefined from the host they were migrated to after shutdown. I have experienced this at two (2) separate locations on more than one hardware configuration. This happens when utilizing virt-manager to view current allocations on hosts, and virsh on the CLI to migrate guests. When the guest is migrated from one host to another, no errors are thrown, and only lose 1 packet from infinite ping. Shutting guest down *from* the guest OS results in the Guest VM being undefined on the residing host, and XML config lost. If needed, I can provide a recorded session of this happening. + +Thanks, + Dan + +This is the QEMU bug tracker here ... Can you also reproduce such an issue with plain QEMU? If not, could you please report this to the virt-manager project first? See https://virt-manager.org/bugs/#report for details. + +Also, can you please include the libvirt logs for the VM, they're typically in /var/log/libvirt/VMNAME.log + +This was done with virsh on the cli - not through virt-manager. Virt +manager was only used to see the visual residence of the vm. The exact +command is below: + + +virsh migrate 79fdd9dd-068b-41cc-b97b-d0f9d8e9df84 --desturi +qemu+ssh://kvmadmin@192.168.0.84/system + +after migrating, shutting down the guest vm results in destruction of vm +(undefined) + + +Thanks, + Dan + + +On 11/07/2018 02:33 PM, Thomas Huth wrote: +> This is the QEMU bug tracker here ... Can you also reproduce such an +> issue with plain QEMU? If not, could you please report this to the virt- +> manager project first? See https://virt-manager.org/bugs/#report for +> details. +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +The logs for the VM that gets undefined are no longer available. + + +Thanks, + Dan + + +On 11/12/2018 01:26 PM, Dr. David Alan Gilbert wrote: +> Also, can you please include the libvirt logs for the VM, they're +> typically in /var/log/libvirt/VMNAME.log +> + + + +Dan: + Rereading your description I think this might be worth discussing on the libvirt mailing list/bug trackers instead. + I *think* what you're saying is the migration works fine, the only problem is that after you shutdown the VM it disappears. + My understanding (although I'm more qemu than libvirt) is that you need to pass --persistent to the virsh migrate command to get it to stick on the destination. However, I'd expected that without --persistent it would have still existed on the source after shutdown. + + Given that big long VM name, is it being managed by some higher level thing rather than directly? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/none/1802915 b/results/classifier/118/none/1802915 new file mode 100644 index 00000000..12d98ef4 --- /dev/null +++ b/results/classifier/118/none/1802915 @@ -0,0 +1,71 @@ +performance: 0.422 +graphic: 0.362 +semantic: 0.333 +mistranslation: 0.303 +device: 0.275 +user-level: 0.203 +socket: 0.201 +PID: 0.191 +register: 0.190 +debug: 0.184 +vnc: 0.172 +risc-v: 0.161 +architecture: 0.142 +ppc: 0.136 +files: 0.135 +permissions: 0.131 +boot: 0.120 +network: 0.115 +arm: 0.109 +virtual: 0.100 +hypervisor: 0.090 +peripherals: 0.090 +VMM: 0.085 +TCG: 0.081 +x86: 0.079 +assembly: 0.070 +kernel: 0.070 +i386: 0.063 +KVM: 0.062 + +GTK display refresh rate is throttled + +Guest OS running with GL enabled GTK display shows a reduced refresh rate, e.g. moving cursor around with iGVT-g DMA Buf. + +It seems that a default refresh interval GUI_REFRESH_INTERVAL_DEFAULT (30ms) is defined in include/ui/console.h, throttling the display refresh rate at 33Hz. + +To correct this throttle issue, a shorter interval should be applied to display change listener or the default value should be used. + + + +Slow motion clips for host/guest were uploaded as attachments. + +Instead of changing the value, I think there should be a function that determines the ideal "GUI_REFRESH_INTERVAL_DEFAULT" value, with the option to override it. That way, monitor greater than 60 Hz can also benefit. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +The bug is still here. + +People are simply modifying the code and recompiling.. It only needs to change the code cap from 30ms (10 years old cap) to 16ms, and we got a smooth gui capable of gaming. + +Please, don't ignore us. Recompiling qemu only for one number is very annoying. + +The ticket has been re-opened here: + + https://gitlab.com/qemu-project/qemu/-/issues/700 + +... so let's keep this one here closed, please. + |