Bug 516769 - Got "Guest moved used index from 6479 to 25579" during restart of rhel5.4 with virtio block after performing suspend to disk.
Got "Guest moved used index from 6479 to 25579" during restart of rhel5.4 wit...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.4
All Linux
high Severity high
: rc
: ---
Assigned To: Kevin Wolf
Lawrence Lim
: Reopened
: 657182 (view as bug list)
Depends On:
Blocks: Rhel5KvmTier3 542378 582519
  Show dependency treegraph
 
Reported: 2009-08-11 09:10 EDT by Miya Chen
Modified: 2014-03-25 21:00 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Guests cannot presently use suspend to disk options with the para-virtualized block drivers. Presently, some required functionality for suspending is missing both in the driver and the device layers.
Story Points: ---
Clone Of:
: 542378 582519 (view as bug list)
Environment:
Last Closed: 2010-11-25 04:47:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miya Chen 2009-08-11 09:10:23 EDT
Description of problem:
After performing suspend to disk to rhel5.4, boot guest with same cmd, got error "Guest moved used index from 6479 to 25579" and qemu quit.

Version-Release number of selected component (if applicable):
83-105

How reproducible:
100%

Steps to Reproduce:
1.boot guest by;
/usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -drive file=rhel-5.4-64-block.raw,if=virtio,boot=on -cpu qemu64,+sse2 -m 8G -smp 8 -net nic,macaddr=20:20:20:90:80:65,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:80:66,model=e1000,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -vnc :5&
2.#cd /sys/power/
3.#echo disk > state
4.after suspend finish, restart guest by the same cmd.

  
Actual results:
# Guest moved used index from 6479 to 25579
[1]+  Exit 1                  /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -drive file=rhel-5.4-64-block.raw,if=virtio,boot=on -cpu qemu64,+sse2 -m 8G -smp 8 -net nic,macaddr=20:20:20:90:80:65,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:80:66,model=e1000,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -vnc :5

Expected results:


Additional info:
rhel5.4 with ide block does not have this problem.
Comment 1 Qunfang Zhang 2009-08-12 03:47:53 EDT
This bug can be reproduced on kvm-83-83 and kvm-83-94
Comment 2 Mark McLoughlin 2009-08-18 04:04:34 EDT
bug #497504 had a similar error
Comment 4 Yaniv Kaul 2009-09-07 03:57:10 EDT
Also happened to me:
KVM 112, Windows 2008 R2, with 2 vCPUs, after resume, with virtio-net (and IDE).
Raised severity and priority a bit.
Comment 5 Dor Laor 2009-09-08 05:20:26 EDT
Yan and Yuri analysed it as an issue of missing device reset call when the pci status register sets its RST bit.
Comment 6 Dor Laor 2009-09-16 05:29:21 EDT
We posted kvm rpm to Yaniv. Any news?
Comment 8 Yan Vugenfirer 2009-09-16 05:36:30 EDT
(In reply to comment #6)
> We posted kvm rpm to Yaniv. Any news?  

The guest is no longer crashes.
But there are test hangs in the device path verified with PNP test. Probably our driver bug.
Comment 9 Dor Laor 2009-09-21 07:47:35 EDT

*** This bug has been marked as a duplicate of bug 521829 ***
Comment 10 Yan Vugenfirer 2009-09-21 07:58:32 EDT
Not sure that this bug is duplicated. The symptom seams the same as for https://bugzilla.redhat.com/show_bug.cgi?id=521829 but I think it worth checking if the solution also applicable here
Comment 11 Michael S. Tsirkin 2009-09-22 12:35:05 EDT
(In reply to comment #5)
> Yan and Yuri analysed it as an issue of missing device reset call when the pci
> status register sets its RST bit.  

AFAIK PCI status does not have a reset bit.
Yan, Yuri, please document your findings somewhere.
Comment 13 Yan Vugenfirer 2009-09-23 05:27:01 EDT
(In reply to comment #11)
> (In reply to comment #5)
> > Yan and Yuri analysed it as an issue of missing device reset call when the pci
> > status register sets its RST bit.  
> 
> AFAIK PCI status does not have a reset bit.
> Yan, Yuri, please document your findings somewhere.  

We never said it was RST bit , it is probably Dor's mistake when he described the bug.

As you also can see from the sources we are talking about command register  and bus master bit (0x04 D:2)
Comment 14 Michael S. Tsirkin 2009-09-23 05:42:35 EDT
Could you please document your findings here?
Do you see a value written into the device control register?
What is this value?


Also, Yaniv reports that with new drivers and fixed
qemu memory corruption bug, the issue does not happen anymore.
Do you still think there's an issue that needs to be fixed?
If yes, could you check what happens with the control register write after qemu is fixed, please?
Comment 15 Michael S. Tsirkin 2009-09-23 05:44:34 EDT
(In reply to comment #4)
> Also happened to me:
> KVM 112, Windows 2008 R2, with 2 vCPUs, after resume, with virtio-net (and
> IDE).
> Raised severity and priority a bit.  

Seems like an unrelated issue.
Comment 16 Michael S. Tsirkin 2009-09-23 06:36:09 EDT
Could this be tested with new patch from
https://bugzilla.redhat.com/show_bug.cgi?id=524557
?
If does not help, can also try testing with old patch
from same bug, just as an additional datapoint.
Comment 17 Gleb Natapov 2009-09-23 06:44:30 EDT
This bug has no any connection or similarity to 524557. The is likely bug in virtio-blk guest driver WRT suspend (bug report states that the problem doesn't happen with IDE, but it will be good to reproduce without virtio-net to completely rule it out). Somebody familiar with guest driver should look at it.
Comment 18 Gleb Natapov 2009-09-23 06:50:33 EDT
can you retest with virtio-disk but without virtio-net?
Comment 19 Miya Chen 2009-09-23 07:24:56 EDT
(In reply to comment #18)
> can you retest with virtio-disk but without virtio-net?  

retest with virtio block but without virtio-net in kvm-83-105.el5_4.4, this problem can be reproduced.

cmd:
Steps to Reproduce:
1.boot guest by;
/usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -drive
file=rhel-5.4-64-block.raw,if=virtio,boot=on -cpu qemu64,+sse2 -m 8G -smp 4
-net nic,macaddr=20:20:20:11:44:99,model=e1000,vlan=0 -net
tap,script=/etc/qemu-ifup,vlan=0 -vnc :5&
2.#cd /sys/power/
3.#echo disk > state
4.after suspend finish, restart guest by the same cmd.


Actual results:
# Guest moved used index from 5627 to 0
Comment 20 Dor Laor 2009-10-01 09:09:40 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Suspend to disk of guest with virtio block does not work. Some logic is missing both in the driver and the device layers
Comment 21 Yaniv Kaul 2009-10-06 11:17:06 EDT
Dor, we are talking here about:
1. *Internal* guest suspend to disk - not QEMU's migration to file, right?
2. With all virtio devices? I've had something similar with Win2K8 and virtio-net - or is it a different issue?

We need to be more clear on the release notes.
Comment 22 Michael S. Tsirkin 2009-10-06 11:20:36 EDT
Yaniv, yes.
Comment 23 Christopher Curran 2009-10-22 21:31:37 EDT
Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1 @@
-Suspend to disk of guest with virtio block does not work. Some logic is missing both in the driver and the device layers+Guests cannot presently use suspend to disk options with the para-virtualized block drivers. Presently, some required functionality for suspending is missing both in the driver and the device layers.
Comment 28 Kevin Wolf 2010-12-01 03:42:57 EST
*** Bug 657182 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.