Bug 1281674 - [kernel] network broken in virtual machines - error message 'virbr0: set_features() failed (-1); ..' -
[kernel] network broken in virtual machines - error message 'virbr0: set_feat...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-13 00:52 EST by Joachim Frieben
Modified: 2015-11-19 09:36 EST (History)
9 users (show)

See Also:
Fixed In Version: kernel-4.4.0-0.rc1.git0.1.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-19 09:36:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
potential fix (3.25 KB, patch)
2015-11-13 15:47 EST, Laura Abbott
no flags Details | Diff

  None (edit)
Description Joachim Frieben 2015-11-13 00:52:12 EST
Description of problem:
Virtual network devices in recent 4.4.x development kernel do not work. Accordingly, no network is available in virtual machines.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot fully updated development system.

Actual results:
Command 'dmesg' reveals error messages related to virtual network devices like virbr0 and tap0 which read

    "virbr0: set_features() failed (-1); .." .

Network is broken in virtual machines.

Expected results:
No kernel errors and functional virtual network devices.

Additional info:
Downgrade to kernel 4.3.x restores normal behaviour.
Comment 1 Kevin Fenzi 2015-11-13 15:10:32 EST
I'm seeing this here also with tun devices... they seem to come up and connect, but no tcp/udp passes. (ICMP seems to however). 

[  331.110565] tun0: set_features() failed (-1); wanted 0x00000080000048c1, left 0x00000080001b48c9
Comment 2 Laura Abbott 2015-11-13 15:47 EST
Created attachment 1093852 [details]
potential fix

There is a thread about this upstream, can you try the following test patch that was proposed?
Comment 3 Joachim Frieben 2015-11-13 17:14:31 EST
Issue still present for kernel-4.4.0-0.rc0.git9.1.fc24.
Comment 4 Kevin Fenzi 2015-11-13 17:23:03 EST
I just tried http://koji.fedoraproject.org/koji/taskinfo?taskID=11824289 with the potential fix and it seems to fix it up here. ;)
Comment 5 Joachim Frieben 2015-11-13 17:56:46 EST
(In reply to Kevin Fenzi from comment #4)
Weird, I have just retrieved and installed kernel-4.4.0-0.rc0.git9.1.fc24 a 2nd time and now, it actually resolves the issue.
Comment 6 Kevin Fenzi 2015-11-13 18:01:59 EST
Which one? The scratch build from comment 4? or the official one? they are named the same, but the scratch build has the patch added.
Comment 7 Joachim Frieben 2015-11-13 22:09:54 EST
(In reply to Kevin Fenzi from comment #6)
Right, it is the scratch build from comment 4, maybe I messed it up with the normal build when downloading for the first time.
Comment 8 Joachim Frieben 2015-11-14 00:35:28 EST
(In reply to Kevin Fenzi from comment #6)
The situation is the following: when Laura had informed me about her scratch build, I had already downloaded, installed and negatively tested the latest kernel build kernel-4.4.0-0.rc0.git9.1.fc24 from

    https://kojipkgs.fedoraproject.org//work/tasks/2431/11822431 .

After your reply, I downloaded kernel-4.4.0-0.rc0.git9.1.fc24 again but this time from

    https://kojipkgs.fedoraproject.org//work/tasks/4292/11824292 ,

and indeed, this build does solve the reported kernel error for me which is perfectly consistent. I suppose that the next regular build will eventually include the patch.
Comment 9 Laura Abbott 2015-11-16 18:17:25 EST
The patch has been included in the rawhide kernel. I haven't heard anything from upstream despite mentioning that the patch worked.

Note You need to log in before you can comment on or make changes to this bug.