RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-14 Thread Ren, Yongjie 
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Wednesday, June 13, 2012 6:33 PM
 To: Ren, Yongjie
 Cc: Marcelo Tosatti; Stefan Hajnoczi; Avi Kivity; kvm@vger.kernel.org; Liu,
 RongrongX; Anthony Liguori
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 Am 13.06.2012 12:28, schrieb Ren, Yongjie:
  -Original Message-
  From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
  Sent: Wednesday, June 13, 2012 7:25 AM
  To: Kevin Wolf
  Cc: Stefan Hajnoczi; Ren, Yongjie; Avi Kivity; kvm@vger.kernel.org; Liu,
  RongrongX; Anthony Liguori
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  On Tue, Jun 12, 2012 at 09:45:16AM +0200, Kevin Wolf wrote:
  Am 12.06.2012 03:52, schrieb Marcelo Tosatti:
  On Thu, Jun 07, 2012 at 01:13:50PM +0100, Stefan Hajnoczi wrote:
  The 1st bad commit in your attached list is abc551bd
  More detailed info:
  171d2f2249a360d7d623130d3aa991418c53716d   good
  fd453a24166e36a3d376c9bc221e520e3ee425afgood
  abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
  823ccf41509baa197dd6a3bef63837a6cf101ad8 bad
 
  Thanks, this points to the qcow2 v3 changes. Let's try to find the
  exact
  culprit. I have rebased the qcow2 patches on top of that good
  merge
  (fd453a24). Please apply the attached mbox on top of this
 merge:
 
  git checkout fd453a24
  git am qcow2v3.mbox
 
  You can then start a git bisect between your new HEAD and
  fd453a24.
 
  Another thing you could try is if reverting e82dabd and bef0fd59
  fixes
  the problem for you.
 
  After reverting bef0fd59, it can work fine.
 
  I'm unable to reproduce this with qemu-kvm.git/master
  (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
  3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.
 The
  RHEL 6
  guest boots without any issues.  My host kernel is Linux 3.2
 (Debian
  3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.
 
  Since the guest sees a disk read error, it may be useful to add
  printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why
  the
  disk read is failing.
 
  Any news on this problem?
 
  We're still waiting for the test results with Jan's timer fix.
 
  OK, Ren, can you please retest with qemu-kvm.git master? TIA.
 
  Yes, I re-tested with latest qemu-kvm.git master branch (commit:
 0a948cbb).
  I found the qcow2 image 'disk error' issue can't be reproduced in latest
 tree.
  And, I can still reproduce it against commit e54f008e (May 9) as I
 reported for this bug.
  Any recent patch has been checked in to fix this issue?
  Maybe, Jan's kvm: i8254: Fix conversion of in-kernel to userspace
 state?
 
 Yes, this is what we expected to fix the problem. If you like to verify,
 you can try applying only this patch on top of the broken commit e54f008e.
 
Confirmed. Jan's patch kvm: i8254: Fix conversion of in-kernel to userspace 
state fixed the following issue.
https://bugs.launchpad.net/qemu/+bug/1002121

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-13 Thread Ren, Yongjie 
 -Original Message-
 From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
 Sent: Wednesday, June 13, 2012 7:25 AM
 To: Kevin Wolf
 Cc: Stefan Hajnoczi; Ren, Yongjie; Avi Kivity; kvm@vger.kernel.org; Liu,
 RongrongX; Anthony Liguori
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 On Tue, Jun 12, 2012 at 09:45:16AM +0200, Kevin Wolf wrote:
  Am 12.06.2012 03:52, schrieb Marcelo Tosatti:
   On Thu, Jun 07, 2012 at 01:13:50PM +0100, Stefan Hajnoczi wrote:
   The 1st bad commit in your attached list is abc551bd
   More detailed info:
   171d2f2249a360d7d623130d3aa991418c53716d   good
   fd453a24166e36a3d376c9bc221e520e3ee425afgood
   abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
   823ccf41509baa197dd6a3bef63837a6cf101ad8 bad
  
   Thanks, this points to the qcow2 v3 changes. Let's try to find the
 exact
   culprit. I have rebased the qcow2 patches on top of that good
 merge
   (fd453a24). Please apply the attached mbox on top of this merge:
  
   git checkout fd453a24
   git am qcow2v3.mbox
  
   You can then start a git bisect between your new HEAD and
 fd453a24.
  
   Another thing you could try is if reverting e82dabd and bef0fd59
 fixes
   the problem for you.
  
   After reverting bef0fd59, it can work fine.
  
   I'm unable to reproduce this with qemu-kvm.git/master
   (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
   3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.  The
 RHEL 6
   guest boots without any issues.  My host kernel is Linux 3.2 (Debian
   3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.
  
   Since the guest sees a disk read error, it may be useful to add
   printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why
 the
   disk read is failing.
  
   Any news on this problem?
 
  We're still waiting for the test results with Jan's timer fix.
 
 OK, Ren, can you please retest with qemu-kvm.git master? TIA.
 
Yes, I re-tested with latest qemu-kvm.git master branch (commit: 0a948cbb).
I found the qcow2 image 'disk error' issue can't be reproduced in latest tree.
And, I can still reproduce it against commit e54f008e (May 9) as I reported for 
this bug.
Any recent patch has been checked in to fix this issue?
Maybe, Jan's kvm: i8254: Fix conversion of in-kernel to userspace state?

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-13 Thread Kevin Wolf 
Am 13.06.2012 12:28, schrieb Ren, Yongjie:
 -Original Message-
 From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
 Sent: Wednesday, June 13, 2012 7:25 AM
 To: Kevin Wolf
 Cc: Stefan Hajnoczi; Ren, Yongjie; Avi Kivity; kvm@vger.kernel.org; Liu,
 RongrongX; Anthony Liguori
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 On Tue, Jun 12, 2012 at 09:45:16AM +0200, Kevin Wolf wrote:
 Am 12.06.2012 03:52, schrieb Marcelo Tosatti:
 On Thu, Jun 07, 2012 at 01:13:50PM +0100, Stefan Hajnoczi wrote:
 The 1st bad commit in your attached list is abc551bd
 More detailed info:
 171d2f2249a360d7d623130d3aa991418c53716d   good
 fd453a24166e36a3d376c9bc221e520e3ee425afgood
 abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
 823ccf41509baa197dd6a3bef63837a6cf101ad8 bad

 Thanks, this points to the qcow2 v3 changes. Let's try to find the
 exact
 culprit. I have rebased the qcow2 patches on top of that good
 merge
 (fd453a24). Please apply the attached mbox on top of this merge:

 git checkout fd453a24
 git am qcow2v3.mbox

 You can then start a git bisect between your new HEAD and
 fd453a24.

 Another thing you could try is if reverting e82dabd and bef0fd59
 fixes
 the problem for you.

 After reverting bef0fd59, it can work fine.

 I'm unable to reproduce this with qemu-kvm.git/master
 (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
 3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.  The
 RHEL 6
 guest boots without any issues.  My host kernel is Linux 3.2 (Debian
 3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.

 Since the guest sees a disk read error, it may be useful to add
 printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why
 the
 disk read is failing.

 Any news on this problem?

 We're still waiting for the test results with Jan's timer fix.

 OK, Ren, can you please retest with qemu-kvm.git master? TIA.

 Yes, I re-tested with latest qemu-kvm.git master branch (commit: 0a948cbb).
 I found the qcow2 image 'disk error' issue can't be reproduced in latest tree.
 And, I can still reproduce it against commit e54f008e (May 9) as I reported 
 for this bug.
 Any recent patch has been checked in to fix this issue?
 Maybe, Jan's kvm: i8254: Fix conversion of in-kernel to userspace state?

Yes, this is what we expected to fix the problem. If you like to verify,
you can try applying only this patch on top of the broken commit e54f008e.

Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-12 Thread Kevin Wolf 
Am 12.06.2012 03:52, schrieb Marcelo Tosatti:
 On Thu, Jun 07, 2012 at 01:13:50PM +0100, Stefan Hajnoczi wrote:
 The 1st bad commit in your attached list is abc551bd
 More detailed info:
 171d2f2249a360d7d623130d3aa991418c53716d   good
 fd453a24166e36a3d376c9bc221e520e3ee425afgood
 abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
 823ccf41509baa197dd6a3bef63837a6cf101ad8 bad

 Thanks, this points to the qcow2 v3 changes. Let's try to find the exact
 culprit. I have rebased the qcow2 patches on top of that good merge
 (fd453a24). Please apply the attached mbox on top of this merge:

 git checkout fd453a24
 git am qcow2v3.mbox

 You can then start a git bisect between your new HEAD and fd453a24.

 Another thing you could try is if reverting e82dabd and bef0fd59 fixes
 the problem for you.

 After reverting bef0fd59, it can work fine.

 I'm unable to reproduce this with qemu-kvm.git/master
 (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
 3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.  The RHEL 6
 guest boots without any issues.  My host kernel is Linux 3.2 (Debian
 3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.

 Since the guest sees a disk read error, it may be useful to add
 printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why the
 disk read is failing.
 
 Any news on this problem? 

We're still waiting for the test results with Jan's timer fix.

But, Marcelo, you mentioned that you can reproduce it, too. Maybe you
can give it a try?

Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-12 Thread Marcelo Tosatti 
On Tue, Jun 12, 2012 at 09:45:16AM +0200, Kevin Wolf wrote:
 Am 12.06.2012 03:52, schrieb Marcelo Tosatti:
  On Thu, Jun 07, 2012 at 01:13:50PM +0100, Stefan Hajnoczi wrote:
  The 1st bad commit in your attached list is abc551bd
  More detailed info:
  171d2f2249a360d7d623130d3aa991418c53716d   good
  fd453a24166e36a3d376c9bc221e520e3ee425afgood
  abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
  823ccf41509baa197dd6a3bef63837a6cf101ad8 bad
 
  Thanks, this points to the qcow2 v3 changes. Let's try to find the exact
  culprit. I have rebased the qcow2 patches on top of that good merge
  (fd453a24). Please apply the attached mbox on top of this merge:
 
  git checkout fd453a24
  git am qcow2v3.mbox
 
  You can then start a git bisect between your new HEAD and fd453a24.
 
  Another thing you could try is if reverting e82dabd and bef0fd59 fixes
  the problem for you.
 
  After reverting bef0fd59, it can work fine.
 
  I'm unable to reproduce this with qemu-kvm.git/master
  (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
  3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.  The RHEL 6
  guest boots without any issues.  My host kernel is Linux 3.2 (Debian
  3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.
 
  Since the guest sees a disk read error, it may be useful to add
  printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why the
  disk read is failing.
  
  Any news on this problem? 
 
 We're still waiting for the test results with Jan's timer fix.

OK, Ren, can you please retest with qemu-kvm.git master? TIA.

 
 But, Marcelo, you mentioned that you can reproduce it, too. Maybe you
 can give it a try?
 
 Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-11 Thread Marcelo Tosatti 
On Thu, Jun 07, 2012 at 01:13:50PM +0100, Stefan Hajnoczi wrote:
   The 1st bad commit in your attached list is abc551bd
   More detailed info:
   171d2f2249a360d7d623130d3aa991418c53716d       good
   fd453a24166e36a3d376c9bc221e520e3ee425af        good
   abc551bd456cf0407fa798395d83dc5aa35f6dbb         bad
   823ccf41509baa197dd6a3bef63837a6cf101ad8         bad
  
   Thanks, this points to the qcow2 v3 changes. Let's try to find the exact
   culprit. I have rebased the qcow2 patches on top of that good merge
   (fd453a24). Please apply the attached mbox on top of this merge:
  
   git checkout fd453a24
   git am qcow2v3.mbox
  
   You can then start a git bisect between your new HEAD and fd453a24.
 
  Another thing you could try is if reverting e82dabd and bef0fd59 fixes
  the problem for you.
 
  After reverting bef0fd59, it can work fine.
 
 I'm unable to reproduce this with qemu-kvm.git/master
 (18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
 3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.  The RHEL 6
 guest boots without any issues.  My host kernel is Linux 3.2 (Debian
 3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.
 
 Since the guest sees a disk read error, it may be useful to add
 printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why the
 disk read is failing.

Any news on this problem? 


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-07 Thread Stefan Hajnoczi 
On Wed, Jun 6, 2012 at 3:17 AM, Ren, Yongjie yongjie@intel.com wrote:
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, June 04, 2012 9:51 PM
 To: Ren, Yongjie
 Cc: Marcelo Tosatti; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 Am 01.06.2012 10:31, schrieb Kevin Wolf:
  Am 01.06.2012 09:57, schrieb Ren, Yongjie:
  -Original Message-
  From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
  Sent: Thursday, May 31, 2012 4:28 AM
  To: Ren, Yongjie
  Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
  -Original Message-
  From: Kevin Wolf [mailto:kw...@redhat.com]
  Sent: Monday, May 21, 2012 11:30 PM
  To: Ren, Yongjie
  Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  Am 21.05.2012 11:45, schrieb Ren, Yongjie:
  -Original Message-
  From: Kevin Wolf [mailto:kw...@redhat.com]
  Sent: Monday, May 21, 2012 5:05 PM
  To: Avi Kivity
  Cc: Ren, Yongjie; kvm@vger.kernel.org
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  Am 21.05.2012 10:27, schrieb Avi Kivity:
  On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
  Hi All,
 
  This is KVM upstream test result against kvm.git
  51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
  3.4.0-rc7,
  and qemu-kvm.git
 a1fce560c0e5f287ed65d2aaadb3e59578aaa983.
 
  We found 1 new bug and 1 bug got fixed in the past two weeks.
 
  New issue (1):
  1. disk error when guest boot up via qcow2 image
    https://bugs.launchpad.net/qemu/+bug/1002121
    -- Should be a regression on qemu-kvm.
 
 
  Kevin, is this the known regression in qcow2 or something new?
 
  If the commit ID is right, it must be something new. The
 regression
  that
  Marcelo found was fixed in 54e68143.
 
  Yes, it's right. This should be a new regression.
  I looked at the comment of 54e68143, and found it was not related
  the
  issue I reported.
 
  The Launchpad bug refers to commit e54f008ef, which doesn't
  include
  this
  fix indeed. So was the test repeated with a more current
 qemu-kvm
  version after filing the bug in Launchpad, or is the commit ID in
 this
  mail wrong?
 
  Latest commit 3fd9fedb in qemu-kvm master tree still has this
 issue.
  And, the commit ID provided in Launchpad is correct.
 
  Can you please check if the bug exists in upstream qemu.git as well?
 
  This bug doesn't exist on upstream qemu.git with latest commit:
  fd4567d9.
  So, it should only exists on qemu-kvm tree.
 
  Please bisect manually (not using git bisect), with the attached list of
  commits. These are the qemu - qemu-kvm merge commits in the
 range
  described as bad/good.
 
  The 1st bad commit in your attached list is abc551bd
  More detailed info:
  171d2f2249a360d7d623130d3aa991418c53716d       good
  fd453a24166e36a3d376c9bc221e520e3ee425af        good
  abc551bd456cf0407fa798395d83dc5aa35f6dbb         bad
  823ccf41509baa197dd6a3bef63837a6cf101ad8         bad
 
  Thanks, this points to the qcow2 v3 changes. Let's try to find the exact
  culprit. I have rebased the qcow2 patches on top of that good merge
  (fd453a24). Please apply the attached mbox on top of this merge:
 
  git checkout fd453a24
  git am qcow2v3.mbox
 
  You can then start a git bisect between your new HEAD and fd453a24.

 Another thing you could try is if reverting e82dabd and bef0fd59 fixes
 the problem for you.

 After reverting bef0fd59, it can work fine.

I'm unable to reproduce this with qemu-kvm.git/master
(18b012756fd041556764dfa2bb1f307b6923fb71) or the commit you
3fd9fedb9fae4517d93d76e93a2924559cacf2f6 reported as bad.  The RHEL 6
guest boots without any issues.  My host kernel is Linux 3.2 (Debian
3.2.0-2-amd64).  The guest is Linux 2.6.32-71.el6.

Since the guest sees a disk read error, it may be useful to add
printfs to hw/ide/core.c:ide_sector_read_cb().  Let's find out why the
disk read is failing.

Stefan
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-05 Thread Ren, Yongjie 
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, June 04, 2012 9:51 PM
 To: Ren, Yongjie
 Cc: Marcelo Tosatti; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 Am 01.06.2012 10:31, schrieb Kevin Wolf:
  Am 01.06.2012 09:57, schrieb Ren, Yongjie:
  -Original Message-
  From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
  Sent: Thursday, May 31, 2012 4:28 AM
  To: Ren, Yongjie
  Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
  -Original Message-
  From: Kevin Wolf [mailto:kw...@redhat.com]
  Sent: Monday, May 21, 2012 11:30 PM
  To: Ren, Yongjie
  Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  Am 21.05.2012 11:45, schrieb Ren, Yongjie:
  -Original Message-
  From: Kevin Wolf [mailto:kw...@redhat.com]
  Sent: Monday, May 21, 2012 5:05 PM
  To: Avi Kivity
  Cc: Ren, Yongjie; kvm@vger.kernel.org
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  Am 21.05.2012 10:27, schrieb Avi Kivity:
  On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
  Hi All,
 
  This is KVM upstream test result against kvm.git
  51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
  3.4.0-rc7,
  and qemu-kvm.git
 a1fce560c0e5f287ed65d2aaadb3e59578aaa983.
 
  We found 1 new bug and 1 bug got fixed in the past two weeks.
 
  New issue (1):
  1. disk error when guest boot up via qcow2 image
https://bugs.launchpad.net/qemu/+bug/1002121
-- Should be a regression on qemu-kvm.
 
 
  Kevin, is this the known regression in qcow2 or something new?
 
  If the commit ID is right, it must be something new. The
 regression
  that
  Marcelo found was fixed in 54e68143.
 
  Yes, it's right. This should be a new regression.
  I looked at the comment of 54e68143, and found it was not related
  the
  issue I reported.
 
  The Launchpad bug refers to commit e54f008ef, which doesn't
  include
  this
  fix indeed. So was the test repeated with a more current
 qemu-kvm
  version after filing the bug in Launchpad, or is the commit ID in
 this
  mail wrong?
 
  Latest commit 3fd9fedb in qemu-kvm master tree still has this
 issue.
  And, the commit ID provided in Launchpad is correct.
 
  Can you please check if the bug exists in upstream qemu.git as well?
 
  This bug doesn't exist on upstream qemu.git with latest commit:
  fd4567d9.
  So, it should only exists on qemu-kvm tree.
 
  Please bisect manually (not using git bisect), with the attached list of
  commits. These are the qemu - qemu-kvm merge commits in the
 range
  described as bad/good.
 
  The 1st bad commit in your attached list is abc551bd
  More detailed info:
  171d2f2249a360d7d623130d3aa991418c53716d   good
  fd453a24166e36a3d376c9bc221e520e3ee425afgood
  abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
  823ccf41509baa197dd6a3bef63837a6cf101ad8 bad
 
  Thanks, this points to the qcow2 v3 changes. Let's try to find the exact
  culprit. I have rebased the qcow2 patches on top of that good merge
  (fd453a24). Please apply the attached mbox on top of this merge:
 
  git checkout fd453a24
  git am qcow2v3.mbox
 
  You can then start a git bisect between your new HEAD and fd453a24.
 
 Another thing you could try is if reverting e82dabd and bef0fd59 fixes
 the problem for you.
 
After reverting bef0fd59, it can work fine.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-04 Thread Kevin Wolf 
Am 01.06.2012 10:31, schrieb Kevin Wolf:
 Am 01.06.2012 09:57, schrieb Ren, Yongjie:
 -Original Message-
 From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
 Sent: Thursday, May 31, 2012 4:28 AM
 To: Ren, Yongjie
 Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 11:30 PM
 To: Ren, Yongjie
 Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 Am 21.05.2012 11:45, schrieb Ren, Yongjie:
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 5:05 PM
 To: Avi Kivity
 Cc: Ren, Yongjie; kvm@vger.kernel.org
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 Am 21.05.2012 10:27, schrieb Avi Kivity:
 On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
 Hi All,

 This is KVM upstream test result against kvm.git
 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
 3.4.0-rc7,
 and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.

 We found 1 new bug and 1 bug got fixed in the past two weeks.

 New issue (1):
 1. disk error when guest boot up via qcow2 image
   https://bugs.launchpad.net/qemu/+bug/1002121
   -- Should be a regression on qemu-kvm.


 Kevin, is this the known regression in qcow2 or something new?

 If the commit ID is right, it must be something new. The regression
 that
 Marcelo found was fixed in 54e68143.

 Yes, it's right. This should be a new regression.
 I looked at the comment of 54e68143, and found it was not related
 the
 issue I reported.

 The Launchpad bug refers to commit e54f008ef, which doesn't
 include
 this
 fix indeed. So was the test repeated with a more current qemu-kvm
 version after filing the bug in Launchpad, or is the commit ID in this
 mail wrong?

 Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
 And, the commit ID provided in Launchpad is correct.

 Can you please check if the bug exists in upstream qemu.git as well?

 This bug doesn't exist on upstream qemu.git with latest commit:
 fd4567d9.
 So, it should only exists on qemu-kvm tree.

 Please bisect manually (not using git bisect), with the attached list of
 commits. These are the qemu - qemu-kvm merge commits in the range
 described as bad/good.

 The 1st bad commit in your attached list is abc551bd
 More detailed info:
 171d2f2249a360d7d623130d3aa991418c53716d   good
 fd453a24166e36a3d376c9bc221e520e3ee425afgood
 abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
 823ccf41509baa197dd6a3bef63837a6cf101ad8 bad
 
 Thanks, this points to the qcow2 v3 changes. Let's try to find the exact
 culprit. I have rebased the qcow2 patches on top of that good merge
 (fd453a24). Please apply the attached mbox on top of this merge:
 
 git checkout fd453a24
 git am qcow2v3.mbox
 
 You can then start a git bisect between your new HEAD and fd453a24.

Another thing you could try is if reverting e82dabd and bef0fd59 fixes
the problem for you.

Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-01 Thread Ren, Yongjie 
 -Original Message-
 From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
 Sent: Thursday, May 31, 2012 4:28 AM
 To: Ren, Yongjie
 Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
   -Original Message-
   From: Kevin Wolf [mailto:kw...@redhat.com]
   Sent: Monday, May 21, 2012 11:30 PM
   To: Ren, Yongjie
   Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
   Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
   a1fce560...
  
   Am 21.05.2012 11:45, schrieb Ren, Yongjie:
-Original Message-
From: Kevin Wolf [mailto:kw...@redhat.com]
Sent: Monday, May 21, 2012 5:05 PM
To: Avi Kivity
Cc: Ren, Yongjie; kvm@vger.kernel.org
Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
a1fce560...
   
Am 21.05.2012 10:27, schrieb Avi Kivity:
On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
Hi All,
   
This is KVM upstream test result against kvm.git
51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
   3.4.0-rc7,
and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.
   
We found 1 new bug and 1 bug got fixed in the past two weeks.
   
New issue (1):
1. disk error when guest boot up via qcow2 image
  https://bugs.launchpad.net/qemu/+bug/1002121
  -- Should be a regression on qemu-kvm.
   
   
Kevin, is this the known regression in qcow2 or something new?
   
If the commit ID is right, it must be something new. The regression
 that
Marcelo found was fixed in 54e68143.
   
Yes, it's right. This should be a new regression.
I looked at the comment of 54e68143, and found it was not related
 the
   issue I reported.
   
The Launchpad bug refers to commit e54f008ef, which doesn't
 include
   this
fix indeed. So was the test repeated with a more current qemu-kvm
version after filing the bug in Launchpad, or is the commit ID in this
mail wrong?
   
Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
And, the commit ID provided in Launchpad is correct.
  
   Can you please check if the bug exists in upstream qemu.git as well?
  
  This bug doesn't exist on upstream qemu.git with latest commit:
 fd4567d9.
  So, it should only exists on qemu-kvm tree.
 
 Please bisect manually (not using git bisect), with the attached list of
 commits. These are the qemu - qemu-kvm merge commits in the range
 described as bad/good.

The 1st bad commit in your attached list is abc551bd
More detailed info:
171d2f2249a360d7d623130d3aa991418c53716d   good
fd453a24166e36a3d376c9bc221e520e3ee425afgood
abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
823ccf41509baa197dd6a3bef63837a6cf101ad8 bad

-Jay
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-01 Thread Ren, Yongjie 
 -Original Message-
 From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
 Sent: Thursday, May 31, 2012 4:30 AM
 To: Ren, Yongjie
 Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
   
Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
And, the commit ID provided in Launchpad is correct.
  
   Can you please check if the bug exists in upstream qemu.git as well?
  
  This bug doesn't exist on upstream qemu.git with latest commit:
 fd4567d9.
  So, it should only exists on qemu-kvm tree.
 
 What do you mean by If you press some key to continue, after being
 automatically repaired, the guest can boot up. exactly?
 
I mean if I press keys to continue, the system will repair the disk 
automatically.
After the check or reparation, the guest will boot up.

 That the error is seen once and after pressing a key it disappears?
 
Yes, it appears only once. 
After the reparation, I don't meet the issue on the same qcow2 image.

   In any case, it would be helpful to bisect the problem.
  
   Kevin

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-06-01 Thread Jan Kiszka 
On 2012-06-01 09:57, Ren, Yongjie wrote:
 -Original Message-
 From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
 Sent: Thursday, May 31, 2012 4:28 AM
 To: Ren, Yongjie
 Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 11:30 PM
 To: Ren, Yongjie
 Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 Am 21.05.2012 11:45, schrieb Ren, Yongjie:
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 5:05 PM
 To: Avi Kivity
 Cc: Ren, Yongjie; kvm@vger.kernel.org
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 Am 21.05.2012 10:27, schrieb Avi Kivity:
 On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
 Hi All,

 This is KVM upstream test result against kvm.git
 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
 3.4.0-rc7,
 and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.

 We found 1 new bug and 1 bug got fixed in the past two weeks.

 New issue (1):
 1. disk error when guest boot up via qcow2 image
   https://bugs.launchpad.net/qemu/+bug/1002121
   -- Should be a regression on qemu-kvm.


 Kevin, is this the known regression in qcow2 or something new?

 If the commit ID is right, it must be something new. The regression
 that
 Marcelo found was fixed in 54e68143.

 Yes, it's right. This should be a new regression.
 I looked at the comment of 54e68143, and found it was not related
 the
 issue I reported.

 The Launchpad bug refers to commit e54f008ef, which doesn't
 include
 this
 fix indeed. So was the test repeated with a more current qemu-kvm
 version after filing the bug in Launchpad, or is the commit ID in this
 mail wrong?

 Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
 And, the commit ID provided in Launchpad is correct.

 Can you please check if the bug exists in upstream qemu.git as well?

 This bug doesn't exist on upstream qemu.git with latest commit:
 fd4567d9.
 So, it should only exists on qemu-kvm tree.

 Please bisect manually (not using git bisect), with the attached list of
 commits. These are the qemu - qemu-kvm merge commits in the range
 described as bad/good.

 The 1st bad commit in your attached list is abc551bd
 More detailed info:
 171d2f2249a360d7d623130d3aa991418c53716d   good
 fd453a24166e36a3d376c9bc221e520e3ee425afgood
 abc551bd456cf0407fa798395d83dc5aa35f6dbb bad
 823ccf41509baa197dd6a3bef63837a6cf101ad8 bad

That's strange. There are no obvious block-related diffs between, e.g.,
upstream a75bfc5fdda8b87ff969d68e020ffdf1008751b1 and qemu-kvm's
abc551bd456cf0407fa798395d83dc5aa35f6dbb merge.

Does the issue also show up with -no-kvm-irqchip in qemu-kvm or with
-machine accel=kvm,kernel_irqchip=on in upstream or with qemu-kvm's
uq/master branch? I suspect some actually unrelated difference in
qemu-kvm causes an upstream bug to become visible.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-30 Thread Marcelo Tosatti 
On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
  -Original Message-
  From: Kevin Wolf [mailto:kw...@redhat.com]
  Sent: Monday, May 21, 2012 11:30 PM
  To: Ren, Yongjie
  Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
  
  Am 21.05.2012 11:45, schrieb Ren, Yongjie:
   -Original Message-
   From: Kevin Wolf [mailto:kw...@redhat.com]
   Sent: Monday, May 21, 2012 5:05 PM
   To: Avi Kivity
   Cc: Ren, Yongjie; kvm@vger.kernel.org
   Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
   a1fce560...
  
   Am 21.05.2012 10:27, schrieb Avi Kivity:
   On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
   Hi All,
  
   This is KVM upstream test result against kvm.git
   51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
  3.4.0-rc7,
   and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.
  
   We found 1 new bug and 1 bug got fixed in the past two weeks.
  
   New issue (1):
   1. disk error when guest boot up via qcow2 image
 https://bugs.launchpad.net/qemu/+bug/1002121
 -- Should be a regression on qemu-kvm.
  
  
   Kevin, is this the known regression in qcow2 or something new?
  
   If the commit ID is right, it must be something new. The regression that
   Marcelo found was fixed in 54e68143.
  
   Yes, it's right. This should be a new regression.
   I looked at the comment of 54e68143, and found it was not related the
  issue I reported.
  
   The Launchpad bug refers to commit e54f008ef, which doesn't include
  this
   fix indeed. So was the test repeated with a more current qemu-kvm
   version after filing the bug in Launchpad, or is the commit ID in this
   mail wrong?
  
   Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
   And, the commit ID provided in Launchpad is correct.
  
  Can you please check if the bug exists in upstream qemu.git as well?
  
 This bug doesn't exist on upstream qemu.git with latest commit: fd4567d9.
 So, it should only exists on qemu-kvm tree.

Please bisect manually (not using git bisect), with the attached list of 
commits. These are the qemu - qemu-kvm merge commits in the range
described as bad/good.

4a808cd6ff25fa3d7f019dc56f9369c48c415645
87e51f4e6a5c07f336709d824fe7fe9e60c8f730
aa7159eea0f1f45c56235e77f40229d0d02c0384
9d81ede5d772c95c503f834a6c7ddc78c827209b
c63457f3ebfb494d5a3968dfbe84971f3a3fc7b6
69bbfba89575ee0665dee605901184c69ab8e6db
d0151e10d7e0d784fab1b7c895d0704ae0dee7d7
968fcfb5edc564ae5736251bb984a02caf2cfbf2
6c3937ec0b2ce7fbfd5c762c9aeb7aefd54c75ae
171d2f2249a360d7d623130d3aa991418c53716d
fd453a24166e36a3d376c9bc221e520e3ee425af
abc551bd456cf0407fa798395d83dc5aa35f6dbb
823ccf41509baa197dd6a3bef63837a6cf101ad8
be833bc6c2dc40929d1c815b8cbe26c2d9e6dc03
f2b8514f43036f948658cdcddd3c3428245adcac

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-30 Thread Marcelo Tosatti 
On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote:
  
   Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
   And, the commit ID provided in Launchpad is correct.
  
  Can you please check if the bug exists in upstream qemu.git as well?
  
 This bug doesn't exist on upstream qemu.git with latest commit: fd4567d9.
 So, it should only exists on qemu-kvm tree.

What do you mean by If you press some key to continue, after being
automatically repaired, the guest can boot up. exactly?

That the error is seen once and after pressing a key it disappears?

  In any case, it would be helpful to bisect the problem.
  
  Kevin
 N?r??yb?X??ǧv?^?)޺{.n?+h????ܨ}???Ơz?j:+v???zZ+??+zf???h???~i???z??w??)ߢf
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-22 Thread Ren, Yongjie 
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 11:30 PM
 To: Ren, Yongjie
 Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 Am 21.05.2012 11:45, schrieb Ren, Yongjie:
  -Original Message-
  From: Kevin Wolf [mailto:kw...@redhat.com]
  Sent: Monday, May 21, 2012 5:05 PM
  To: Avi Kivity
  Cc: Ren, Yongjie; kvm@vger.kernel.org
  Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
  a1fce560...
 
  Am 21.05.2012 10:27, schrieb Avi Kivity:
  On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
  Hi All,
 
  This is KVM upstream test result against kvm.git
  51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel
 3.4.0-rc7,
  and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.
 
  We found 1 new bug and 1 bug got fixed in the past two weeks.
 
  New issue (1):
  1. disk error when guest boot up via qcow2 image
https://bugs.launchpad.net/qemu/+bug/1002121
-- Should be a regression on qemu-kvm.
 
 
  Kevin, is this the known regression in qcow2 or something new?
 
  If the commit ID is right, it must be something new. The regression that
  Marcelo found was fixed in 54e68143.
 
  Yes, it's right. This should be a new regression.
  I looked at the comment of 54e68143, and found it was not related the
 issue I reported.
 
  The Launchpad bug refers to commit e54f008ef, which doesn't include
 this
  fix indeed. So was the test repeated with a more current qemu-kvm
  version after filing the bug in Launchpad, or is the commit ID in this
  mail wrong?
 
  Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
  And, the commit ID provided in Launchpad is correct.
 
 Can you please check if the bug exists in upstream qemu.git as well?
 
This bug doesn't exist on upstream qemu.git with latest commit: fd4567d9.
So, it should only exists on qemu-kvm tree.

 In any case, it would be helpful to bisect the problem.
 
 Kevin
N�r��yb�X��ǧv�^�)޺{.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-21 Thread Avi Kivity 
On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
 Hi All,

 This is KVM upstream test result against kvm.git 
 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel 3.4.0-rc7, and 
 qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.

 We found 1 new bug and 1 bug got fixed in the past two weeks. 

 New issue (1):
 1. disk error when guest boot up via qcow2 image
   https://bugs.launchpad.net/qemu/+bug/1002121
   -- Should be a regression on qemu-kvm.


Kevin, is this the known regression in qcow2 or something new?

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-21 Thread Kevin Wolf 
Am 21.05.2012 10:27, schrieb Avi Kivity:
 On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
 Hi All,

 This is KVM upstream test result against kvm.git 
 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel 3.4.0-rc7, and 
 qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.

 We found 1 new bug and 1 bug got fixed in the past two weeks. 

 New issue (1):
 1. disk error when guest boot up via qcow2 image
   https://bugs.launchpad.net/qemu/+bug/1002121
   -- Should be a regression on qemu-kvm.

 
 Kevin, is this the known regression in qcow2 or something new?

If the commit ID is right, it must be something new. The regression that
Marcelo found was fixed in 54e68143.

The Launchpad bug refers to commit e54f008ef, which doesn't include this
fix indeed. So was the test repeated with a more current qemu-kvm
version after filing the bug in Launchpad, or is the commit ID in this
mail wrong?

If the bug does still exist in current master, it would be helpful to
bisect it.

Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-21 Thread Ren, Yongjie 
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 5:05 PM
 To: Avi Kivity
 Cc: Ren, Yongjie; kvm@vger.kernel.org
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...
 
 Am 21.05.2012 10:27, schrieb Avi Kivity:
  On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
  Hi All,
 
  This is KVM upstream test result against kvm.git
 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel 3.4.0-rc7,
 and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.
 
  We found 1 new bug and 1 bug got fixed in the past two weeks.
 
  New issue (1):
  1. disk error when guest boot up via qcow2 image
https://bugs.launchpad.net/qemu/+bug/1002121
-- Should be a regression on qemu-kvm.
 
 
  Kevin, is this the known regression in qcow2 or something new?
 
 If the commit ID is right, it must be something new. The regression that
 Marcelo found was fixed in 54e68143.
 
Yes, it's right. This should be a new regression.
I looked at the comment of 54e68143, and found it was not related the issue I 
reported.

 The Launchpad bug refers to commit e54f008ef, which doesn't include this
 fix indeed. So was the test repeated with a more current qemu-kvm
 version after filing the bug in Launchpad, or is the commit ID in this
 mail wrong?
 
Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
And, the commit ID provided in Launchpad is correct.

 If the bug does still exist in current master, it would be helpful to
 bisect it.
 
 Kevin

Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...

2012-05-21 Thread Kevin Wolf 
Am 21.05.2012 11:45, schrieb Ren, Yongjie:
 -Original Message-
 From: Kevin Wolf [mailto:kw...@redhat.com]
 Sent: Monday, May 21, 2012 5:05 PM
 To: Avi Kivity
 Cc: Ren, Yongjie; kvm@vger.kernel.org
 Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu
 a1fce560...

 Am 21.05.2012 10:27, schrieb Avi Kivity:
 On 05/21/2012 06:34 AM, Ren, Yongjie wrote:
 Hi All,

 This is KVM upstream test result against kvm.git
 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel 3.4.0-rc7,
 and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983.

 We found 1 new bug and 1 bug got fixed in the past two weeks.

 New issue (1):
 1. disk error when guest boot up via qcow2 image
   https://bugs.launchpad.net/qemu/+bug/1002121
   -- Should be a regression on qemu-kvm.


 Kevin, is this the known regression in qcow2 or something new?

 If the commit ID is right, it must be something new. The regression that
 Marcelo found was fixed in 54e68143.

 Yes, it's right. This should be a new regression.
 I looked at the comment of 54e68143, and found it was not related the issue I 
 reported.
 
 The Launchpad bug refers to commit e54f008ef, which doesn't include this
 fix indeed. So was the test repeated with a more current qemu-kvm
 version after filing the bug in Launchpad, or is the commit ID in this
 mail wrong?

 Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.
 And, the commit ID provided in Launchpad is correct.

Can you please check if the bug exists in upstream qemu.git as well?

In any case, it would be helpful to bisect the problem.

Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html