[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1770724] Re: e1000 takes a long time (2 seconds) to set link ready
From: |
Thomas Huth |
Subject: |
[Bug 1770724] Re: e1000 takes a long time (2 seconds) to set link ready |
Date: |
Sat, 14 Nov 2020 06:38:19 -0000 |
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state
back to "New" within the next 60 days, otherwise this report will be marked as
"Expired". Or mark it as "Fix Released" if the problem has been solved with a
newer version of QEMU already. Thank you and sorry for the inconvenience.
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1770724
Title:
e1000 takes a long time (2 seconds) to set link ready
Status in QEMU:
Incomplete
Bug description:
When a VM is booted with e1000 NIC, it takes a long time (2 seconds)
for the guest to bring up the link. This can be seen in the following
dmesg messages:
[ 4.899773] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 6.889165] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
[ 6.891372] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
The first message happens when the guest calls to ifup eth0; ifup does
not hold control until the link is established. The guest I am using
(cirros 0.4.0) then starts udhcpc DHCP client that issues a DHCP
request, then waits for 60 seconds for reply, then repeats the DHCP
request. When the first request is sent, the link is not ready yet, so
the frame is lost; when the second request is sent, the link is up and
DHCP lease is received.
If I use different NICs (e1000e, virtio, rtl*), there are no dmesg
messages, and the very first DHCP request correctly reaches outside
and results in a lease acquired.
The qemu version I am using is 2.10.1 from Fedora 27. I tried to
reproduce with runtime from Fedora 29 that includes 2.12 but I have
different issues there that block me from reproducing the original
issue (there, I get kernel traces, irq interrupt errors, and no
network link at all).
For the record, the qemu in question is started by kubevirt inside a
docker container with Fedora 27 based image.
===============================
The command line of qemu is as follows:
27404 ? Sl 0:10 /usr/bin/qemu-system-x86_64 -machine
accel=kvm -name guest=default_ovm-cirros,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1
-default_ovm-cirros/master-key.aes -machine
pc-q35-2.10,accel=kvm,usb=off,dump-guest-core=off -m 62 -realtime
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
8769fdbe-d957-5567-bd71-114ba0eb4811 -no-user-config -nodefaults
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1
-default_ovm-cirros/monitor.sock,server,nowait -mon
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
-no-acpi -boot strict=on -device
i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-
bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-
port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2
-device pcie-root-
port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device
pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2
-device pcie-root-
port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device
pcie-root-port,port=0x14,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x4
-device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive
file=/var/run/libvirt/kubevirt-ephemeral-disk/registry-disk-
data/default/ovm-cirros/disk_registryvolume/disk-
image.raw,format=raw,if=none,id=drive-virtio-disk0 -device virtio-blk-
pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-
disk0,bootindex=1 -drive file=/var/run/libvirt/kubevirt-ephemeral-disk
/cloud-init-data/default/ovm-cirros/noCloud.iso,format=raw,if=none,id
=drive-virtio-disk1 -device virtio-blk-
pci,scsi=off,bus=pci.5,addr=0x0,drive=drive-virtio-disk1,id=virtio-
disk1 -netdev tap,fd=23,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=0a:58:0a:f4:01:e1,bus=pci.2,addr=0x1
-chardev socket,id=charserial0,path=/var/run/kubevirt-private/default
/ovm-cirros/virt-serial0,server,nowait -device isa-
serial,chardev=charserial0,id=serial0 -vnc vnc=unix:/var/run/kubevirt-
private/default/ovm-cirros/virt-vnc -device
VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 -device virtio-balloon-
pci,id=balloon0,bus=pci.6,addr=0x0 -msg timestamp=on
============================
Hypervisor versions of interest:
[vagrant@node02 ~]$ sudo docker exec -it $(sudo docker ps | grep
virt-launcher-ovm-cirros | grep entrypoint | awk -e '{print $1}') rpm -qa |
grep 'qemu\|libvirt'
qemu-block-curl-2.10.1-2.fc27.x86_64
qemu-block-ssh-2.10.1-2.fc27.x86_64
qemu-block-nfs-2.10.1-2.fc27.x86_64
qemu-system-x86-core-2.10.1-2.fc27.x86_64
libvirt-daemon-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-disk-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-mpath-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-zfs-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-nwfilter-3.7.0-4.fc27.x86_64
qemu-img-2.10.1-2.fc27.x86_64
qemu-common-2.10.1-2.fc27.x86_64
qemu-block-dmg-2.10.1-2.fc27.x86_64
qemu-block-rbd-2.10.1-2.fc27.x86_64
qemu-system-x86-2.10.1-2.fc27.x86_64
libvirt-libs-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-core-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-qemu-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-gluster-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-logical-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-rbd-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-sheepdog-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-nodedev-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-secret-3.7.0-4.fc27.x86_64
libvirt-client-3.7.0-4.fc27.x86_64
ipxe-roms-qemu-20161108-2.gitb991c67.fc26.noarch
qemu-block-gluster-2.10.1-2.fc27.x86_64
qemu-block-iscsi-2.10.1-2.fc27.x86_64
qemu-kvm-2.10.1-2.fc27.x86_64
libvirt-daemon-driver-network-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-iscsi-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-storage-scsi-3.7.0-4.fc27.x86_64
libvirt-daemon-driver-interface-3.7.0-4.fc27.x86_64
libvirt-daemon-kvm-3.7.0-4.fc27.x86_64
[vagrant@node02 ~]$ uname -a
Linux node02 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
[vagrant@node02 ~]$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
=============================
Guest:
$ uname -a
Linux ovm-cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016
x86_64 GNU/Linux
=============================
Bug trackers for other projects:
- cirros: https://bugs.launchpad.net/cirros/+bug/1768955
- kubevirt: https://github.com/kubevirt/kubevirt/issues/936
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1770724/+subscriptions
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug 1770724] Re: e1000 takes a long time (2 seconds) to set link ready,
Thomas Huth <=