All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thorsten Kohfeldt <thorsten.kohfeldt@gmx.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1384892] Re: RTL8168 NIC VFIO not working anymore since QEMU 2.1
Date: Fri, 24 Jun 2016 07:15:03 -0000	[thread overview]
Message-ID: <576CDDF7.2040702@gmx.de> (raw)
In-Reply-To: 20160622111056.22171.10037.malone@soybean.canonical.com

Current QEMU code is quite different now.
When I tested last (with QEMU 2.4) the problem still existed.
I had quite a discussion with Alex up to and around end of 2015,
but unfortunately since then I just did not have any spare time to
convince Alex to accept what I call 'the real fix', a series of patches.
I also could not test QEMU2.5 yet, but it does not *look* like it 
contains any additional fix towards the problem.

Just a hint about the 'underlying' problem:
Several subtypes of that card hang up DURING loading the assigned 
firmware, as QEMU does not correctly map all required i/o areas
for supporting the firmware load (unless i/o mmap is disabled).
The cards need to be power cycled then, reset is not enough.
The correct mapping cannot really be derived from looking at the
Linux driver code - it is rather to be deduced from access traces.

If a firmware is NOT accessible, the card doesn't hang,
but also it is running 'unpatched' i.e. might expose bugs that the
hardware designer/manufacturer has detected and fixed via firmware.

A better workaround is disabling i/o mmap when VFIO-attaching the card.
This is supported by newer QEMU versions.

So no,
the problem is not fixed yet,
but yes,
I guess you can close this bug if you feel like it.

Regards

Am 22.06.2016 um 13:10 schrieb T. Huth:
> Alex' patch has been included here:
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=69970fcef937bddd7f745
> ... so I assume this ticket could be closed now?

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

Title:
  RTL8168 NIC VFIO not working anymore since QEMU 2.1

Status in QEMU:
  New

Bug description:
  After upgrading QEMU from 2.0 to 2.1 (and libiscsi from 1.7.0 to 1.12 as a dependency) my two RTL8168 NICs stopped working.
  The NICs do not respond to any command and even the LEDs on the network connection turn off, a few seconds after the VM started.
  To get them back running I had to downgrade to 2.0 and restart the system.
  Unfortunately, I have no clue what to do or how to debug this problem since there are no specific errors logged.
  I tried two different VMs: Debian Wheezy and IPFire (see attachment for further details).
  The QEMU 2.1 changelog states "Support for RTL8168 NICs." so there were some major changes done, I guess.

  On the IPFire guest the kernel log shows many of these lines:
  r8169 0000:00:07.0 green1: rtl_eriar_cond == 1 (loop: 100, delay: 100)
  r8169 0000:00:07.0 green1: rtl_phy_reset_cond == 1 (loop: 100, delay: 1)

  On the Debian guest there is only:
  r8169 0000:00:07.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw into memory
  r8169 0000:00:07.0: lan0: link down
  ADDRCONF(NETDEV_UP): lan0: link is not ready

  The commandline for IPFire can be seen in the attachment. It is the same for Debian.
  There are also the complete kernel logs for the working (2.0) and non-working (2.1) cases.

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

  reply	other threads:[~2016-06-24  7:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23 19:42 [Qemu-devel] [Bug 1384892] [NEW] RTL8168 NIC VFIO not working anymore since QEMU 2.1 Florian Wickert
2014-10-23 22:55 ` [Qemu-devel] [Bug 1384892] " Alex Williamson
2014-10-24  9:53 ` Florian Wickert
2014-11-06 23:18 ` Alex Williamson
2014-11-06 23:20 ` Alex Williamson
2015-07-13 17:35 ` Thorsten Kohfeldt
2015-07-13 19:01 ` Thorsten Kohfeldt
2015-07-13 19:38 ` Florian Wickert
2015-07-14  2:21 ` Alex Williamson
2015-07-15  5:40 ` Thorsten Kohfeldt
2015-07-16  5:53 ` Thorsten Kohfeldt
2015-07-16 15:35 ` Alex Williamson
2016-06-22 11:10 ` T. Huth
2016-06-24  7:15   ` Thorsten Kohfeldt [this message]
2016-10-28  1:40   ` Thorsten Kohfeldt
2017-09-15 14:24 ` Thomas Huth

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=576CDDF7.2040702@gmx.de \
    --to=thorsten.kohfeldt@gmx.de \
    --cc=1384892@bugs.launchpad.net \
    --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.