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
next 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.