Description of problem: The guest is a flesh installed,and then kernel is updated to the latest 5.4-z (-164.2.1) version. i386 guest works fine,while x86_64 guest cost about 8 minutes before the desktop come up again. Version-Release number of selected component (if applicable): kvm-83-105.el5_4.7 kvm-83-105.el5_4.9 How reproducible: 100% Steps to Reproduce: 1.start RHEL5u4 x86_64 guest : /usr/libexec/qemu-kvm -m 1024 -smp 2 -drive file=/data/images/t77/08-5u4.64.raw,if=ide -net nic,model=e1000,macaddr=00:01:02:58:5F:04 -net tap -monitor stdio -vnc :2 -no-kvm-pit-reinjection -rtc-td-hack -notify all -boot c -name 5u4-64 -uuid 791f094e-1530-48c4-a062-b094903d4f71 2. echo disk > /sys/power/state 3. Use the cli in step1 to start guest again. Actual results: Expected results: Additional info: Guest: [root@dhcp-66-70-36 ~]# df -kh Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 8.8G 2.8G 5.6G 34% / /dev/hda1 99M 35M 60M 37% /boot tmpfs 502M 0 502M 0% /dev/shm dmesg in guest: Disabling non-boot CPUs ... CPU 1 is now offline SMP alternatives: switching to UP code CPU1 is down Stopping tasks: =================================================================================================================================| Shrinking memory... done (25561 pages freed) ACPI: PCI interrupt for device 0000:00:03.0 disabled swsusp: Need to copy 123069 pages PM: Writing back config space on device 0000:00:03.0 at offset 3 (was 10, writing 4010) ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKC] -> GSI 11 (level, high) -> IRQ 11 pnp: Failed to activate device 00:02. e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX pnp: Failed to activate device 00:03. pnp: Failed to activate device 00:05. pnp: Failed to activate device 00:06. Restarting tasks... done Enabling non-boot CPUs ... SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 5320.93 BogoMIPS (lpj=2660468) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K QEMU Virtual CPU version 0.9.1 stepping 03 kvm-clock: cpu 1, msr 0:157da81, secondary cpu clock CPU1 is up Host CPU: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz stepping : 10 cpu MHz : 2659.997 cache size : 3072 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 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 lm constant_tsc pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips : 5319.93 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Can you please retest on newer kvm-83-142 ?
I believe this is the same problem as BZ 539521.
I can't reproduce this issue, because I can't even put the machine to disk. What I get is this: Stopping tasks: ================================================================================== stopping tasks timed out after 120 seconds (1 tasks remaining): khungtaskd Restarting tasks...<6> Strange, khungtaskd not stopped However, by code inspection, I have a slight idea of what's going on. I am brewing a new scratch build that will be ready shortly at: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2214588
Ok... according to Gleb, that was an unrelated regression introduced in 5.5 So I am building another rpm ontop of 5.4.z To be ready shortly. Here it is: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2215204
repeat 10 times, can not reproduce with new built package. guest: rhel5.4-x86_64 1. can access network after resume. 2. can edit files after resume. CLI: /usr/libexec/qemu-kvm -drive file=/root/rhel5.4-64-ide.bak,if=ide -no-hpet -rtc-td-hack -smp 8 -m 4G -uuid `uuidgen` -net nic,model=e1000,macaddr=00:A6:78:FA:0D:95,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -boot c -vnc :6 -monitor stdio -name 5.4-64 -no-kvm-pit-reinjection
*** This bug has been marked as a duplicate of bug 539521 ***