Created attachment 372486 [details] suspend to disk Description of problem: Call trace error display when resume from suspend to disk (ide block) Version-Release number of selected component (if applicable): kvm-83-135.el5 How reproducible: most of time Steps to Reproduce: 1. install vm with if=ide /usr/libexec/qemu-kvm -drive file=rhel5.4-64.qcow2,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 n -vnc :16 -monitor stdio -name 5.4-64 -no-kvm-pit-reinjection 2. boot vm /usr/libexec/qemu-kvm -drive file=rhel5.4-64.qcow2,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 :16 -monitor stdio -name 5.4-64 -no-kvm-pit-reinjection 3. # echo > disk /sys/power/state 4. Resume vm again after suspend Actual results: Call trace error display, guest can not resume successfully. Expected results: Additional info: 1. guest rhel5.4-64 with 2.6.18-164.6.1.el5 kernel 2. host processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping : 4 cpu MHz : 2668.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 fpu : yes 3. attach the error
Test on real HW (with same amount cpus) several times please.
Why was this bug moved to MODIFIED without any comment indicating why, and which version fixes it?
Could you please follow up Comment #2?
work well on real HW with 8 cpus, 12G mem, scsi block. 1. # echo disk > /sys/power/state 2. can access network after resume, firefox, gedit still work after resume. 3. repeat 10 times. 4. host kernel: 2.6.18-164.6.1.el5 5. cpu: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping : 4 cpu MHz : 1600.000 cache size : 8192 KB
During suspend to disk block subsystem plays major role. Do you happen to have ide HW to test with? Not necessary 8 cpus, 2 may be enough.
(In reply to comment #5) > work well on real HW with 8 cpus, 12G mem, scsi block. Check the block again, it's ide block.
(In reply to comment #7) > (In reply to comment #5) > > work well on real HW with 8 cpus, 12G mem, scsi block. > > Check the block again, it's ide block. ide or sata? I doubt you'll find 8 cpu box with ide disk.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > work well on real HW with 8 cpus, 12G mem, scsi block. > > > > Check the block again, it's ide block. > > ide or sata? I doubt you'll find 8 cpu box with ide disk. No need to do real HW testing. I found out that disabling kvm clock solves the problem. Unfortunately no-kvmclock kernel option does not take any effect so I had to disable kvm clock in qemu for testing. Glauber can you look at this?
sidenote: no-kvmclock does not work on x86_64 RHEL5 because the option parsing for that is done too late in the game. You'd have to pass clock=<something> (like pmtimer or tsc) in the command line. 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
*** Bug 527927 has been marked as a duplicate of this bug. ***
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-2010-0178.html