diff options
Diffstat (limited to 'results/classifier/118/permissions/1879425')
| -rw-r--r-- | results/classifier/118/permissions/1879425 | 95 |
1 files changed, 95 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/1879425 b/results/classifier/118/permissions/1879425 new file mode 100644 index 00000000..44aeb5e7 --- /dev/null +++ b/results/classifier/118/permissions/1879425 @@ -0,0 +1,95 @@ +permissions: 0.963 +graphic: 0.941 +semantic: 0.938 +mistranslation: 0.923 +debug: 0.910 +user-level: 0.900 +register: 0.898 +risc-v: 0.888 +assembly: 0.887 +ppc: 0.863 +performance: 0.853 +socket: 0.850 +arm: 0.849 +PID: 0.846 +device: 0.845 +peripherals: 0.842 +vnc: 0.838 +virtual: 0.829 +architecture: 0.823 +hypervisor: 0.789 +files: 0.785 +VMM: 0.782 +TCG: 0.773 +network: 0.744 +boot: 0.707 +KVM: 0.666 +kernel: 0.621 +x86: 0.377 +i386: 0.264 + +The thread of "CPU 0 /KVM" keeping 99.9%CPU + +Hi Expert: + +The VM is hung here after (2, or 3, or 5 and the longest time is 10 hours) by qemu-kvm. +Notes: +for VM: + OS: RHEL 7.6 + CPU: 1 + MEM:4G +For qemu-kvm: + 1) version: + /usr/libexec/qemu-kvm -version + QEMU emulator version 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.4.1) + 2) once the issue is occurred, the CPU of "CPU0 /KVM" is more than 99% by com "top -p VM_pro_ID" + PID UDER PR NI RES S % CPU %MEM TIME+ COMMAND +872067 qemu 20 0 1.6g R 99.9 0.6 37:08.87 CPU 0/KVM + 3) use "pstack 493307" and below is function trace +Thread 1 (Thread 0x7f2572e73040 (LWP 872067)): +#0 0x00007f256cad8fcf in ppoll () from /lib64/libc.so.6 +#1 0x000055ff34bdf4a9 in qemu_poll_ns () +#2 0x000055ff34be02a8 in main_loop_wait () +#3 0x000055ff348bfb1a in main () + 4) use strace "strace -tt -ff -p 872067 -o cfx" and below log keep printing +21:24:02.977833 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 0}, NULL, 8) = 0 (Timeout) +21:24:02.977918 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 911447}, NULL, 8) = 0 (Timeout) +21:24:02.978945 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 0}, NULL, 8) = 0 (Timeout) +Therefore, I think the thread "CPU 0/KVM" is in tight loop. + 5) use reset can recover this issue. however, it will reoccurred again. +Current work around is increase one CPU for this VM, then issue is gone. + +thanks +Cliff + +one changes: +Guest VM is Red Hat Enterprise Linux 8.1 (Ootpa). +there is no issue once guest VM is RHEL7.6. + +Appreciate any comments or clues + + +Can you try with a newer version of CentOS? I think there should be newer versions of qemu-kvm-ev available, so maybe the problem is gone there. +Otherwise, please either try to reproduce this problem with upstream QEMU, or report it to the CentOS bug tracker (https://bugs.centos.org/), since we do not provide support for distribution builds in the upstream QEMU project here. + +Hi Thomas, +Do you have any quick suggestion before report it on CentOS? + +thanks +Cliff + + + +I think you should definitely try a newer version if available - otherwise they'll likely refuse to help you, too (nobody wants to debug old versions when bugs are already fixed in newer ones) + +Got it! +BTW, you can confirm this is bug for qemu-kvm, right? + +thank you! +Cliff + +Add the ticket link in centos +https://bugs.centos.org/view.php?id=17385 + +[Expired for QEMU because there has been no activity for 60 days.] + |