[Qemu-devel] [Bug 1736655] Re: 2k3/xp guests w/virtio-net randomly DHCP fail on boot

[ChristianEhrhardt]

Hi Patrick,
thank you so much for the report and your help to make Ubuntu better.
Also for all the bisecting that is very helpful.

While backporting the change itself would be very trivial we need to
find what the final solution has to be first.

I checked latest upstream which is about to release 2.11 these days and there 
was not related change.
- no revert to this commit
- no other major disabling/fixes for ioeventfd in these cases

That would imply that this is an issue unknown to upstream - and that means 
that we need to make it known there to not end up carrying a Delta forever and 
deriving more and more.
So we should bring it up there and find a solution for everyone.

First of all let me try if I can reproduce it over here, then we can decide on 
next steps.
Very likely one of them would be to report it to upstream as well - which since 
you have a great bug description already they track Launchpad I can easily do 
for you by adding a bug Task.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1736655

Title:
  2k3/xp guests w/virtio-net randomly DHCP fail on boot

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Incomplete

Bug description:
  Host:
  Debian GNU/Linux 9 with Linux 4.13.0-0.bpo.1-amd64
  QEMU 2.10.1

  Guest:
  Windows 2003 Standard SP2 (x64)
  Windows XP SP3 (i386)

  QEMU command line:
  http://cfp.vim-cn.com/cbdF3

  Description:
  After upgrading from QEMU 2.8 to 2.10.1, my Windows 2003 x64 and Windows XP 
guests with "virtio-net-pci" NIC would randomly fail to aquire DHCP address on 
boot. When it fails, cycle disable/enable the connection in Control Panel could 
make it connect successfully. As an immediate workaround, I switched to the 
RTL8139 NIC which works fine. Further investigation showed that manually 
reverting commit '4a3f03ba8dbf53fce36d0c1dd5d0cc0f340fe5f3' on top of 2.10.1 
"fixed" the problem.

  Here are the bisect test results:
  git branch 97cd965: 17 boots, 5 failures  (Feb 18)
  git branch 77424a4: 27 boots, 0 failure   (Jan 09)
  git branch c25d97c: 7 boots, 2 failures   (Feb 01)
  git branch 4a3f03b: 25 boots, 8 failures  (Jan 19)
  git branch 39f099e: 60 boots, 0 failure   (Jan 18)
  2.10.1 with revert: 194 boots, 0 failure
  2.10.1 without revert: 30 boots, 4 failures

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1736655/+subscriptions