All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: qemu-devel@nongnu.org, KVM mailing list <kvm@vger.kernel.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	aliguori@us.ibm.com
Subject: Problems with e1000 network card on qemu.git
Date: Thu, 23 Sep 2010 08:58:43 -0300	[thread overview]
Message-ID: <1285243123.2619.28.camel@freedom> (raw)

Hi folks:

As most of you might know, we run some daily sanity and functional tests
with both qemu-kvm.git and qemu.git. I decided to write asking for help
with regards to what it appears to be a problem with the e1000 nw card
(the default). Here is a list of what it fails pretty much every day for
qemu.git:

1) Problems logging into guest with e1000 card

kvm.qemu-git.RHEL.5.5.i386.e1000.boot                                                        FAIL  Could not log into guest 'vm1'                       
kvm.qemu-git.RHEL.5.5.i386.e1000.reboot                                                      FAIL  Could not log into guest 'vm1'                       
kvm.qemu-git.RHEL.5.5.i386.e1000.shutdown                                                    FAIL  Could not log into guest 'vm1'                       

^ At first I thought this was some sort of intermittent, harmless
problem, but it reproduces fairly frequently, thing that pretty much
doesn't happen with virtio. 

kvm.qemu-git.RHEL.5.5.i386.virtio_net.boot	GOOD	completed successfully
kvm.qemu-git.RHEL.5.5.i386.virtio_net.reboot	GOOD	completed successfully
kvm.qemu-git.RHEL.5.5.i386.virtio_net.shutdown	GOOD	completed successfully

Looking at test logs and screenshots the only thing that I found
abnormal was:

2010-09-23 05:51:02: EXT3-fs: recovery complete.
2010-09-23 05:51:02: EXT3-fs: mounted filesystem with ordered data mode.
2010-09-23 05:51:05: type=1404 audit(1285235453.446:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
2010-09-23 05:51:06: type=1403 audit(1285235454.059:3): policy loaded auid=4294967295 ses=4294967295
2010-09-23 05:53:16: hdc: drive_cmd: status=0x41 { DriveReady Error }
2010-09-23 05:53:16: hdc: drive_cmd: error=0x04 { AbortedCommand }
2010-09-23 05:53:16: ide: failed opcode was: 0xec

^ Serial logs for the RHEL5.5 guest. If someone wants the full serial
log, please let me know.

2) Qemu dies during unattended install

kvm.qemu-git.RHEL.5.5.x86_64.e1000.unattended_install.cdrom                                  ERROR Guest died before end of OS install 

^ This is the bug

https://bugs.launchpad.net/qemu/+bug/588955

Which is, according to preliminary investigation done, a bug on the
slirp code. IMHO, we really need to start looking into those issues,
even because e1000 is the default network card.

Cheers,

Lucas


WARNING: multiple messages have this Message-ID (diff)
From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: qemu-devel@nongnu.org, KVM mailing list <kvm@vger.kernel.org>
Cc: aliguori@us.ibm.com, Marcelo Tosatti <mtosatti@redhat.com>,
	Avi Kivity <avi@redhat.com>
Subject: [Qemu-devel] Problems with e1000 network card on qemu.git
Date: Thu, 23 Sep 2010 08:58:43 -0300	[thread overview]
Message-ID: <1285243123.2619.28.camel@freedom> (raw)

Hi folks:

As most of you might know, we run some daily sanity and functional tests
with both qemu-kvm.git and qemu.git. I decided to write asking for help
with regards to what it appears to be a problem with the e1000 nw card
(the default). Here is a list of what it fails pretty much every day for
qemu.git:

1) Problems logging into guest with e1000 card

kvm.qemu-git.RHEL.5.5.i386.e1000.boot                                                        FAIL  Could not log into guest 'vm1'                       
kvm.qemu-git.RHEL.5.5.i386.e1000.reboot                                                      FAIL  Could not log into guest 'vm1'                       
kvm.qemu-git.RHEL.5.5.i386.e1000.shutdown                                                    FAIL  Could not log into guest 'vm1'                       

^ At first I thought this was some sort of intermittent, harmless
problem, but it reproduces fairly frequently, thing that pretty much
doesn't happen with virtio. 

kvm.qemu-git.RHEL.5.5.i386.virtio_net.boot	GOOD	completed successfully
kvm.qemu-git.RHEL.5.5.i386.virtio_net.reboot	GOOD	completed successfully
kvm.qemu-git.RHEL.5.5.i386.virtio_net.shutdown	GOOD	completed successfully

Looking at test logs and screenshots the only thing that I found
abnormal was:

2010-09-23 05:51:02: EXT3-fs: recovery complete.
2010-09-23 05:51:02: EXT3-fs: mounted filesystem with ordered data mode.
2010-09-23 05:51:05: type=1404 audit(1285235453.446:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
2010-09-23 05:51:06: type=1403 audit(1285235454.059:3): policy loaded auid=4294967295 ses=4294967295
2010-09-23 05:53:16: hdc: drive_cmd: status=0x41 { DriveReady Error }
2010-09-23 05:53:16: hdc: drive_cmd: error=0x04 { AbortedCommand }
2010-09-23 05:53:16: ide: failed opcode was: 0xec

^ Serial logs for the RHEL5.5 guest. If someone wants the full serial
log, please let me know.

2) Qemu dies during unattended install

kvm.qemu-git.RHEL.5.5.x86_64.e1000.unattended_install.cdrom                                  ERROR Guest died before end of OS install 

^ This is the bug

https://bugs.launchpad.net/qemu/+bug/588955

Which is, according to preliminary investigation done, a bug on the
slirp code. IMHO, we really need to start looking into those issues,
even because e1000 is the default network card.

Cheers,

Lucas

             reply	other threads:[~2010-09-23 11:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-23 11:58 Lucas Meneghel Rodrigues [this message]
2010-09-23 11:58 ` [Qemu-devel] Problems with e1000 network card on qemu.git Lucas Meneghel Rodrigues

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1285243123.2619.28.camel@freedom \
    --to=lmr@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.