Bug 512656
Summary: | CallTrace in RHEL5 (64bit) guest after migration with large vcpu number (8) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | lihuang <lihuang> |
Component: | kvm | Assignee: | Glauber Costa <gcosta> |
Status: | CLOSED DUPLICATE | QA Contact: | Lawrence Lim <llim> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.4 | CC: | mtosatti, ovirt-maint, shuang, tburke, tools-bugs, virt-maint, ykaul |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | RHEVH | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-07-21 09:01:25 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
lihuang
2009-07-20 08:11:12 UTC
Does the host has >= 8 cpus (it is a must)? In addition, I suspect it might be timing issue caused by tsc source clock in the guest. What's `cat /sys/devices/system/clocksource/clocksource0/current_clocksource` ? (In reply to comment #1) > Does the host has >= 8 cpus (it is a must)? yes . Host has 16 cpu ( refer to the Host cpu info ). and Additional info: Can not reproduce the problem with rhel3u9 rhel4u8 Can not reproduce the problem with rhel5 32 bit Can not reproduce the problem with *-smp 2* also the calltrace is not shown before migration. > > In addition, I suspect it might be timing issue caused by tsc source clock in > the guest. What's `cat > /sys/devices/system/clocksource/clocksource0/current_clocksource` ? jiffies ( same as the host ) lihuang, Is the guest VM otherwise operating correctly on the migration destination ? (In reply to comment #4) > lihuang, > > Is the guest VM otherwise operating correctly on the migration destination ? Yes. (but after migration, I only checked the network and output of dmesg. then I quit the vm. so maybe it is unlikely to find other issue..., anyway,network is ok, and basic operation on guest desktop is ok ) OK, so its probably just a spurious warning. This problem should be fixed by Zach's timer work. (In reply to comment #6) > OK, so its probably just a spurious warning. This problem should be fixed > by Zach's timer work. good to know , the kvm is more and more stronger :) BTW ,it is a existed bug,right ? what's the id ? Thanks . lihuang, I remember it was mentioned on other BZs, but i'm unable to find it. Maybe it is not that harmless. There is the possibility that one of the vcpus is in fact, not running. lihuang, here's an easy way to confirm that: run this command in the guest prior to migration: $ for i in $(seq 0 7); do (taskset -c $i yes >/dev/null &) ; done after the migration: $ top press 1 (will show all cpus on top) If every cpu is running close to 100 % most of the time, then it is a harmless message. If one or more of them is not getting its share, then we're facing a more serious problem. (In reply to comment #9) > Maybe it is not that harmless. > > There is the possibility that one of the vcpus is in fact, not running. > > lihuang, here's an easy way to confirm that: > > run this command in the guest prior to migration: > > $ for i in $(seq 0 7); do (taskset -c $i yes >/dev/null &) ; done > > after the migration: > > $ top > press 1 (will show all cpus on top) > > If every cpu is running close to 100 % most of the time, then it is a harmless > message. If one or more of them is not getting its share, then we're facing a > more serious problem. Yes . every cpu is close to 100% (95%~98%) Since we all think that it's the clock issue. I close it as a dup of the original issue. *** This bug has been marked as a duplicate of bug 481013 *** |