This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 599034 has been marked as a duplicate of this bug. ***
in kernel-2.6.18-203.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
*** Bug 588997 has been marked as a duplicate of this bug. ***
*** Bug 584310 has been marked as a duplicate of this bug. ***
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Red Hat Enterprise Linux 5.4 SMP guests running on the Red Hat Enterprise Virtualization Hypervisor may have experienced inconsistent time, such as the clock driftingbackwards. This could have caused some applications to become unresponsive.
Can I add that this fix description doesn't match what I experienced at all: the *kernel* hogged 100% cpu and the guest was as good as unusable: no attempts to connect by any method, console or otherwise, worked.
Glauber, Could you please check the Technical Note for this bug to ensure it matches the conditions and fix? Thank you, Silas
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Red Hat Enterprise Linux 5.4 SMP guests running on the Red Hat Enterprise Virtualization Hypervisor may have experienced inconsistent time, such as the clock driftingbackwards. This could have caused some applications to become unresponsive.+Red Hat Enterprise Linux 5.4 SMP guests running on the Red Hat Enterprise Virtualization Hypervisor may have experienced inconsistent time, such as the clock drifting backwards. This could have caused some applications to become unresponsive.
comment #16: Sure, but unfortunately, problems that are generated by time drifts are unpredictable at best. comment #18: driftingbackwards => drifting backwards, otherwise, ok.
Fixed "driftingbackwards" earlier in the Tech Notes field. Thanks for the response; leaving note as-is.
*** Bug 587150 has been marked as a duplicate of this bug. ***
*** Bug 523471 has been marked as a duplicate of this bug. ***
*** Bug 619311 has been marked as a duplicate of this bug. ***
Running gettimeofday for 32hours .No find timedrift. Host kernel: #uname -r 2.6.18-230.el5 Guest Kernel: 2.6.18-231.el5 Result =============+=======+===== 64bitrhel5.6 | amd | pass 64bitrhel5.6 | Intel | pass 32bitrhel5.6 | amd | pass 32bitrhel5.6 | Intel | pass =========================== CLI /usr/libexec/qemu-kvm -drive file=/root/RHEL-server-5.6-32.raw,if=virtio,boot=on,format=raw -no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 2 -m 2G -net nic,model=virtio,macaddr=20:20:20:11:23:5f,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -name 64 -monitor stdio -vnc :10 -no-kvm-pit-reinjection /usr/libexec/qemu-kvm -drive file=/root/RHEL-Server-5.6-64.qcow2,if=virtio,boot=on -no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 2 -m 2G -net nic,model=virtio,macaddr=20:20:20:11:23:51,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -name 64 -monitor stdio -vnc :9 -no-kvm-pit-reinjection /usr/libexec/qemu-kvm -drive file=/root/RHEL-server-5.6-32.raw,if=virtio,boot=on,format=raw -no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 2 -m 2G -net nic,model=virtio,macaddr=20:20:20:11:23:5f,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -name 64 -monitor stdio -vnc :10 -no-kvm-pit-reinjection /usr/libexec/qemu-kvm -drive file=/root/RHEL-Server-5.6-64.qcow2,if=virtio,boot=on -no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 2 -m 2G -net nic,model=virtio,macaddr=20:20:20:11:23:51,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -name 64 -monitor stdio -vnc :9 -no-kvm-pit-reinjection Steps: 1.Boot a rhel5.6 guest 2.Run #./gettimeofday inside guest 3.All guests current clock source is kvm-clock AMD HOST cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9600B Quad-Core Processor stepping : 3 cpu MHz : 1200.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc pni cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy altmovcr8 abm sse4a misalignsse 3dnowprefetch osvw bogomips : 4587.49 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [8] Intel HOST #cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz stepping : 5 cpu MHz : 1596.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm bogomips : 5333.67 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html