[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1384892] Re: RTL8168 NIC VFIO not working anymore sinc

From: Thorsten Kohfeldt
Subject: [Qemu-devel] [Bug 1384892] Re: RTL8168 NIC VFIO not working anymore since QEMU 2.1
Date: Thu, 16 Jul 2015 05:53:56 -0000

I made some time for limited testing.
The released V2.1 puts the vfio-ed RTL8168 into a zombie state when running an 
IPFire VM, which requires a subsequent POWER cycle in order to let mii-tools 
show anything else than 'no link' (i.e. to get the LED back on). Pushing the 
reset button on the x64 metal was NOT enough.

Then I binary-patched my V2.1 qemu x64 executable so it compares against
a 'wrong' PCI ID inside vfio_probe_rtl8168_bar2_window_quirk() (to
confirm comment #3). Yes, that made it work again.

Further patch-attempts towards comment #10 all ended up in RTL zombie
state (even though the IPFire VM was otherwise responsive). Each time a
power cycle was required to get the RTL back alive.

Could there be a general problem because the RTL must be usable in MSI-X mode 
for Windows and in in MSI mode for Linux ?
Maybe a cmdline switch should be added to activate the quirk just when MSI-X is 
intended ?

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  RTL8168 NIC VFIO not working anymore since QEMU 2.1

Status in QEMU:

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 
  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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]