Created attachment 890304 [details] screen-capture showing the issue Description of problem: kernel crashes Version-Release number of selected component (if applicable): 3.13.10-200.fc20.x86_64 How reproducible: all the time. I can upload my virtual machine to your server. I took a screen-capture from the crash Steps to Reproduce: 1.create a macvlan interface in host 2.assign it to libvirt-container 3.start the container Actual results: kernel crash Expected results: it should work Additional info: please contact me email if you want me to upload the entire Hyper-V virtual machine
Created attachment 890305 [details] livirt virtual machine xml I defined a new interface eth1 in the host, as macvlan type, linked to eth0. The host works perfectly. Then I added 13 devices on a LXC libvirt container.
An interface defined as <interface type='direct'> will create a new macvtap interface that is linked to the physical device specified in the <source> element of the interface. Normally, the source would be a true physical device, although I have heard that people have had success specifying a bridge device instead. If I'm following your description correctly, what you are doing is manually creating a macvlan device named eth1 that is linked to physical eth0, then creating a container with a macvtap (direct) network device that is linked to eth1: <interface type='direct'> <mac address='00:16:3e:22:91:00'/> <source dev='eth1' mode='bridge'/> </interface> I would be very surprised if that *did* work :-) Instead, you should specify the name of the physical ethernet device in the libvirt config: <interface type='direct'> <mac address='00:16:3e:22:91:00'/> <source dev='eth0' mode='bridge'/> </interface> I believe this will give you the results you're looking for. That said, I'd say that such a simple misconfiguration shouldn't result in a crashed host kernel. I'm reassigning to kernel, and Cc'ing Michael Tsirkin, as he is one person I know who understands macvtap very well, so may better be able to understand what to do with this report.
Created attachment 890520 [details] I followed your instructions and it crashed again I did follow the instructions provided, and it crashed again.
Just to verify - your domain definition now has replaced "eth1" in all 13 interfaces with "eth0" and eth0 is the hardware device on the host, correct? I just setup a simplistic lxc domain (init is set as /bin/sh and I haven't created a custom root fs) with 13 direct interfaces linked to my host's ethernet on an F20 host running kernel-3.14.1 and don't see this problem in a rudimentary test (start the domain, login to its console, ifconfig up the interface and ssh from there to another machine), so either it's something that was fixed between kernel 3.13-10 and 3.14.1 (seems unlikely but could be possible), or something that your container is doing is causing a particular type of traffic to be sent that triggers the crash (recently I had encountered a problem where STP packets sent out a macvtap interface would cause a kernel hang - Bug 1025770 - that bug is long fixed, but is an example of how a particular kind of traffic could be required to reproduce a bug). Could you try 1) creating a basic container with just /bin/sh and the 13 interfaces, and/or 2) removing functionality from your existing config until the crash goes away (or it may be quicker to go in the other direction :-). Either of those could get us closer to being able to independently reproduce the crash, which would likely make it much easier to fix.
Clarification a) My container is not doing anything, since the crash happens when it starts. It never does start. The crash comes right after typing "virsh start mycontainer" b) The container is full Fedora 20,an Operating System container, not an application container. There is no reason to attach 12 network interfaces to an application container. I suggest that you install hyper-v on any windows 8 machine, even in a laptop, and then you download the virtual machine from my ftp, so you may reproduce it. Meanwhile I can give you RDP access to the hyper-V box and you may see it. I stopped using both versions of the virtual machine and kept them as samples of the problem. Please contact me via email for further steps.
The kernel panic trace in the screen capture is not complete, so I can't say with 100% certainty, but I believe I can reproduce the same problem In first shell # ip link add link eth0 macvlan0 type macvlan In a second shell session # unshare --net /bin/sh sh-4.2# Lookup the PID of this new namespaced shell Now back in first shell do # ip link set macvlan0 netns <THE-PID> # kill -9 <THE-PID> Now again try to create the macvlan device # ip link add link eth0 macvlan0 type macvlan Segmentation fault And dmesg will show a panic containing this telling string [ 115.998916] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/virtio0/net/eth0/upper_macvlan0' The file /devices/pci0000:00/0000:00:03.0/virtio0/net/eth0/upper_macvlan0 should have been deleted at the 'kill -9' step when the namespace went away, however, the kernel left it dangling around. I see the panic with kernel-3.13.10-200.fc20.x86_64 It I upgrade to kernel-3.14.1-200.fc20.x86_64 then the panic goes away, and I get # ip link add link eth0 macvlan0 type macvlan RTNETLINK answers: File exists which is better but clearly still broken cleanup in some way because the sysfs file is getting left around forever
(In reply to Daniel Berrange from comment #6) > It I upgrade to kernel-3.14.1-200.fc20.x86_64 then the panic goes away, and > I get > > # ip link add link eth0 macvlan0 type macvlan > RTNETLINK answers: File exists > > which is better but clearly still broken cleanup in some way because the > sysfs file is getting left around forever It seems my test case was not quite correct - I had a sleep process running as a child of the unshare process which I wasn't killing off. IOW, I believe 3.14.1 kernel works correctly and solves this bug.
How do I install from yum kernel-3.14.1-200.fc20.x86_64 on Fedora 20?
I don't think it is in the updates yet, so I installed RPMs taken directly from the build system archive: http://kojipkgs.fedoraproject.org/packages/kernel/3.14.1/200.fc20/x86_64/
I confirm that this kernel does not crash in any scenario. This kernel should be pushed to updates ASAP. One question: is there any advantage, performance wise, in using the "direct" mode versus a bridge, inside an LXC libvirt container? My app moves UDP by the hundreds of megabits.
yes - bridge mode tends to flood multicast packets to all vlans
The current kernel 3.14.2 also has issues with LXC. [ 3798.345926] WARNING: CPU: 11 PID: 6963 at /home/apw/COD/linux/fs/sysfs/dir.c:52 sysfs_warn_dup+0x91/0xb0() [ 3798.345928] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:05.0/0000:02:00.1/net/eth1/upper_eth0' [ 3798.345930] Modules linked in: macvlan veth xt_conntrack ipt_REJECT ip6_tables ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables dm_crypt gpio_ich dcdbas intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 bnep rfcomm lrw gf128mul psmouse glue_helper bluetooth ablk_helper cryptd 6lowpan_iphc serio_raw joydev ipmi_si i7core_edac acpi_power_meter edac_core lpc_ich mac_hid parport_pc ppdev lp parport ses enclosure hid_generic usbhid hid usb_storage bnx2 megaraid_sas wmi [ 3798.345989] CPU: 11 PID: 6963 Comm: lxc-start Not tainted 3.14.2-031402-generic #201404262053 [ 3798.345991] Hardware name: Dell Inc. PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013 [ 3798.345993] 0000000000000034 ffff885fc4c0b5f8 ffffffff8175505c 0000000000000007 [ 3798.346002] ffff885fc4c0b648 ffff885fc4c0b638 ffffffff8106cb5c ffff883fd02c44b0 [ 3798.346008] ffff887fd2b03000 ffff887fd2b03000 ffff883fd02c44b0 0000000000000001 [ 3798.346014] Call Trace: [ 3798.346025] [<ffffffff8175505c>] dump_stack+0x46/0x58 [ 3798.346033] [<ffffffff8106cb5c>] warn_slowpath_common+0x8c/0xc0 [ 3798.346037] [<ffffffff8106cc46>] warn_slowpath_fmt+0x46/0x50 [ 3798.346044] [<ffffffff8137c750>] ? strlcat+0x60/0x80 [ 3798.346047] [<ffffffff81245d41>] sysfs_warn_dup+0x91/0xb0 [ 3798.346051] [<ffffffff812460c0>] sysfs_do_create_link_sd.isra.2+0xd0/0xe0 [ 3798.346054] [<ffffffff812460f5>] sysfs_create_link+0x25/0x50 [ 3798.346060] [<ffffffff816497b8>] netdev_adjacent_sysfs_add+0x58/0x70 [ 3798.346068] [<ffffffff816502d4>] netdev_adjacent_rename_links+0xa4/0xc0 [ 3798.346071] [<ffffffff816503c3>] dev_change_name+0xd3/0x240 [ 3798.346078] [<ffffffff8165e24b>] do_setlink+0x72b/0x790 [ 3798.346082] [<ffffffff8165fffc>] rtnl_newlink+0x48c/0x6a0 [ 3798.346085] [<ffffffff8165fc61>] ? rtnl_newlink+0xf1/0x6a0 [ 3798.346093] [<ffffffff811694a3>] ? get_page_from_freelist+0x443/0x630 [ 3798.346099] [<ffffffff8116db00>] ? __pagevec_lru_add_fn+0x220/0x220 [ 3798.346102] [<ffffffff8165fa85>] rtnetlink_rcv_msg+0x165/0x250 [ 3798.346108] [<ffffffff8163d337>] ? __alloc_skb+0x87/0x2a0 [ 3798.346112] [<ffffffff8165f920>] ? __rtnl_unlock+0x20/0x20 [ 3798.346120] [<ffffffff8167ce59>] netlink_rcv_skb+0xa9/0xd0 [ 3798.346123] [<ffffffff8165cba5>] rtnetlink_rcv+0x25/0x40 [ 3798.346127] [<ffffffff8167c3b8>] netlink_unicast+0x128/0x1d0 [ 3798.346130] [<ffffffff8167caf4>] netlink_sendmsg+0x364/0x440 [ 3798.346138] [<ffffffff8163478f>] sock_sendmsg+0xaf/0xc0 [ 3798.346146] [<ffffffff81188cb9>] ? __do_fault+0x409/0x500 [ 3798.346150] [<ffffffff81634e9c>] ___sys_sendmsg+0x3ac/0x3c0 [ 3798.346155] [<ffffffff8118d173>] ? handle_mm_fault+0xb3/0x160 [ 3798.346160] [<ffffffff8176619c>] ? __do_page_fault+0x28c/0x550 [ 3798.346165] [<ffffffff8111df5c>] ? acct_account_cputime+0x1c/0x20 [ 3798.346171] [<ffffffff810a66b9>] ? account_user_time+0x99/0xb0 [ 3798.346175] [<ffffffff810a6d3d>] ? vtime_account_user+0x5d/0x70 [ 3798.346183] [<ffffffff811ed6f3>] ? __fdget+0x13/0x20 [ 3798.346187] [<ffffffff816358b9>] __sys_sendmsg+0x49/0x90 [ 3798.346190] [<ffffffff81635919>] SyS_sendmsg+0x19/0x20 [ 3798.346197] [<ffffffff8176b6bf>] tracesys+0xe1/0xe6 [ 3798.346199] ---[ end trace 99513b106fc1cfe0 ]---
I know exactly what is going on, or so I imagine. The kernel goes into a crisis when you use a NAT like vibr0, but the box is multi-homed. The network inside the container does not work. You may ping the default gateway, at the same host, but packets are never transferred to the internet. If there was only one NIC, it would work. I was just doing that. Finally, I changed to a "direct" network model, and it does work fine. Since 100% of servers are multi-homed, this kernel cannot be used for business, in this scenario.
keeps crashing, kernel 3.15.0-031500rc4-generic [22764.519947] device veth474FT5 entered promiscuous mode [22764.520072] br23: port 2(veth474FT5) entered forwarding state [22764.520077] br23: port 2(veth474FT5) entered forwarding state [22764.524266] br23: port 2(veth474FT5) entered disabled state [22764.626571] ------------[ cut here ]------------ [22764.626584] WARNING: CPU: 18 PID: 17836 at /home/apw/COD/linux/fs/sysfs/dir.c:31 sysfs_warn_dup+0x6f/0x90() [22764.626586] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:05.0/0000:02:00.1/net/eth1/upper_eth1' [22764.626588] Modules linked in: veth vhost_net vhost macvtap xt_conntrack ipt_REJECT ip6_tables ebtable_nat ebtables macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc dm_crypt gpio_ich dcdbas intel_powerclamp coretemp kvm_intel bnep kvm rfcomm crct10dif_pclmul crc32_pclmul bluetooth ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper psmouse ablk_helper cryptd serio_raw joydev i7core_edac ipmi_si acpi_power_meter mac_hid lpc_ich edac_core parport_pc ppdev lp parport binfmt_misc ses enclosure hid_generic usbhid usb_storage hid bnx2 megaraid_sas wmi [22764.626645] CPU: 18 PID: 17836 Comm: lxc-start Tainted: G W 3.15.0-031500rc4-generic #201405042135 [22764.626647] Hardware name: Dell Inc. PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013 [22764.626650] 000000000000001f ffff883d2f66b5e8 ffffffff81756be4 0000000000000007 [22764.626652] ffff883d2f66b638 ffff883d2f66b628 ffffffff8106b89c ffff883d2f66b628 [22764.626655] ffff885d59985000 ffff883d2f66b721 ffff887fcfc457e0 0000000000000001 [22764.626657] Call Trace: [22764.626669] [<ffffffff81756be4>] dump_stack+0x46/0x58 [22764.626674] [<ffffffff8106b89c>] warn_slowpath_common+0x8c/0xc0 [22764.626676] [<ffffffff8106b986>] warn_slowpath_fmt+0x46/0x50 [22764.626684] [<ffffffff81242085>] ? kernfs_path+0x55/0x70 [22764.626686] [<ffffffff8124511f>] sysfs_warn_dup+0x6f/0x90 [22764.626689] [<ffffffff812454d0>] sysfs_do_create_link_sd.isra.2+0xd0/0xe0 [22764.626692] [<ffffffff81245505>] sysfs_create_link+0x25/0x50 [22764.626699] [<ffffffff81649458>] netdev_adjacent_sysfs_add+0x58/0x70 [22764.626703] [<ffffffff8164ff14>] netdev_adjacent_rename_links+0xa4/0xc0 [22764.626705] [<ffffffff81650003>] dev_change_name+0xd3/0x240 [22764.626712] [<ffffffff8165deeb>] do_setlink+0x72b/0x790 [22764.626715] [<ffffffff8165fccc>] rtnl_newlink+0x48c/0x6a0 [22764.626717] [<ffffffff8165f931>] ? rtnl_newlink+0xf1/0x6a0 [22764.626725] [<ffffffff81165503>] ? get_page_from_freelist+0x3b3/0x630 [22764.626732] [<ffffffff8163c200>] ? skb_unlink+0x40/0x70 [22764.626736] [<ffffffff81679227>] ? __netlink_sendskb+0x67/0x130 [22764.626738] [<ffffffff8165f755>] rtnetlink_rcv_msg+0x165/0x250 [22764.626742] [<ffffffff8163d0c7>] ? __alloc_skb+0x87/0x2a0 [22764.626745] [<ffffffff8165f5f0>] ? __rtnl_unlock+0x20/0x20 [22764.626749] [<ffffffff8167d189>] netlink_rcv_skb+0xa9/0xd0 [22764.626752] [<ffffffff8165c845>] rtnetlink_rcv+0x25/0x40 [22764.626754] [<ffffffff8167c6e8>] netlink_unicast+0x128/0x1d0 [22764.626756] [<ffffffff8167ce24>] netlink_sendmsg+0x364/0x440 [22764.626761] [<ffffffff816347af>] sock_sendmsg+0xaf/0xc0 [22764.626763] [<ffffffff81634565>] ? sock_recvmsg+0xc5/0xe0 [22764.626767] [<ffffffff8165a4e6>] ? neigh_changeaddr+0x46/0x60 [22764.626773] [<ffffffff816bd44f>] ? inetdev_event+0x2f/0x330 [22764.626775] [<ffffffff81634c5c>] ___sys_sendmsg+0x3ac/0x3c0 [22764.626778] [<ffffffff8167b3c3>] ? netlink_table_ungrab+0x33/0x40 [22764.626780] [<ffffffff8167b527>] ? netlink_insert+0x157/0x250 [22764.626786] [<ffffffff810b3533>] ? __wake_up+0x53/0x70 [22764.626792] [<ffffffff8111a98c>] ? acct_account_cputime+0x1c/0x20 [22764.626794] [<ffffffff8111a98c>] ? acct_account_cputime+0x1c/0x20 [22764.626800] [<ffffffff810a39c9>] ? account_user_time+0x99/0xb0 [22764.626802] [<ffffffff810a3ffd>] ? vtime_account_user+0x5d/0x70 [22764.626809] [<ffffffff811e9203>] ? __fdget+0x13/0x20 [22764.626812] [<ffffffff81635679>] __sys_sendmsg+0x49/0x90 [22764.626814] [<ffffffff816356d9>] SyS_sendmsg+0x19/0x20 [22764.626818] [<ffffffff8176d03f>] tracesys+0xe1/0xe6 [22764.626820] ---[ end trace d76b026d2c9d54c2 ]--- [22764.643029] br23: port 2(veth474FT5) entered forwarding state [22764.643043] br23: port 2(veth474FT5) entered forwarding state
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The kernel has plenty of bugs 3.15.0-031500rc4-generic if version 3.15 is buggy, 3.14.200 is also buggy. The issue is LXC. When you reboot a container with a macvlan interface, the old one, before the reboot, does not disappear, or maybe is the veth interface,don't know. My LXC containers have both a macvlan interface and also a bridged interface. For example: lxc.network.type = veth lxc.network.flags = up lxc.network.link = br20 lxc.network.hwaddr = 92:ea:2b:24:e0:27 lxc.network.ipv4 = 0.0.0.0/24 lxc.network.type=macvlan lxc.network.macvlan.mode=bridge lxc.network.link=eth1 lxc.network.flags=up lxc.network.hwaddr = 00:16:3e:08:92:20 lxc.network.ipv4 = 0.0.0.0/25 The issue happens when I reboot a container from inside, typing "reboot". The host does not crash, but dmesg shows this message. In this case, my container was attached to the wrong bridge, br29. I corrected the configuration and rebooted the container, but I am not sure if the right bridge got really used o not. [587895.800092] ------------[ cut here ]------------ [587895.800112] WARNING: CPU: 71 PID: 5756 at /home/apw/COD/linux/fs/sysfs/dir.c:31 sysfs_warn_dup+0x6f/0x90() [587895.800115] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:05.0/0000:02:00.1/net/eth1/upper_eth1' [587895.800117] Modules linked in: nfsd auth_rpcgss nfs_acl lockd sunrpc veth vhost_net vhost macvtap xt_conntrack ipt_REJECT ip6_tables ebtable_nat ebtables macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc dm_crypt gpio_ich dcdbas intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul bnep glue_helper rfcomm ablk_helper bluetooth cryptd serio_raw joydev i7core_edac ipmi_si acpi_power_meter mac_hid lpc_ich edac_core parport_pc ppdev lp parport binfmt_misc ses enclosure hid_generic usbhid psmouse hid usb_storage megaraid_sas bnx2 wmi [587895.800198] CPU: 71 PID: 5756 Comm: lxc-start Tainted: G W 3.15.0-031500rc4-generic #201405042135 [587895.800201] Hardware name: Dell Inc. PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013 [587895.800204] 000000000000001f ffff881b962a55e8 ffffffff81756be4 0000000000000007 [587895.800207] ffff881b962a5638 ffff881b962a5628 ffffffff8106b89c ffff881b962a5628 [587895.800211] ffff887fd267d000 ffff881b962a5721 ffff881fd07947e0 0000000000000001 [587895.800215] Call Trace: [587895.800228] [<ffffffff81756be4>] dump_stack+0x46/0x58 [587895.800235] [<ffffffff8106b89c>] warn_slowpath_common+0x8c/0xc0 [587895.800238] [<ffffffff8106b986>] warn_slowpath_fmt+0x46/0x50 [587895.800248] [<ffffffff81242085>] ? kernfs_path+0x55/0x70 [587895.800251] [<ffffffff8124511f>] sysfs_warn_dup+0x6f/0x90 [587895.800256] [<ffffffff812454d0>] sysfs_do_create_link_sd.isra.2+0xd0/0xe0 [587895.800259] [<ffffffff81245505>] sysfs_create_link+0x25/0x50 [587895.800268] [<ffffffff81649458>] netdev_adjacent_sysfs_add+0x58/0x70 [587895.800274] [<ffffffff8164ff14>] netdev_adjacent_rename_links+0xa4/0xc0 [587895.800278] [<ffffffff81650003>] dev_change_name+0xd3/0x240 [587895.800287] [<ffffffff8165deeb>] do_setlink+0x72b/0x790 [587895.800291] [<ffffffff8165fccc>] rtnl_newlink+0x48c/0x6a0 [587895.800295] [<ffffffff8165f931>] ? rtnl_newlink+0xf1/0x6a0 [587895.800304] [<ffffffff81165503>] ? get_page_from_freelist+0x3b3/0x630 [587895.800315] [<ffffffff8109da46>] ? ttwu_do_activate.constprop.107+0x66/0x70 [587895.800319] [<ffffffff8165f755>] rtnetlink_rcv_msg+0x165/0x250 [587895.800328] [<ffffffff8163d0c7>] ? __alloc_skb+0x87/0x2a0 [587895.800332] [<ffffffff8165f5f0>] ? __rtnl_unlock+0x20/0x20 [587895.800338] [<ffffffff8167d189>] netlink_rcv_skb+0xa9/0xd0 [587895.800342] [<ffffffff8165c845>] rtnetlink_rcv+0x25/0x40 [587895.800344] [<ffffffff8167c6e8>] netlink_unicast+0x128/0x1d0 [587895.800347] [<ffffffff8167ce24>] netlink_sendmsg+0x364/0x440 [587895.800354] [<ffffffff816347af>] sock_sendmsg+0xaf/0xc0 [587895.800356] [<ffffffff81634565>] ? sock_recvmsg+0xc5/0xe0 [587895.800360] [<ffffffff8165a4e6>] ? neigh_changeaddr+0x46/0x60 [587895.800366] [<ffffffff816bd44f>] ? inetdev_event+0x2f/0x330 [587895.800369] [<ffffffff81634c5c>] ___sys_sendmsg+0x3ac/0x3c0 [587895.800371] [<ffffffff8167b3c3>] ? netlink_table_ungrab+0x33/0x40 [587895.800373] [<ffffffff8167b527>] ? netlink_insert+0x157/0x250 [587895.800379] [<ffffffff810b3533>] ? __wake_up+0x53/0x70 [587895.800385] [<ffffffff8111a98c>] ? acct_account_cputime+0x1c/0x20 [587895.800387] [<ffffffff8111a98c>] ? acct_account_cputime+0x1c/0x20 [587895.800392] [<ffffffff810a39c9>] ? account_user_time+0x99/0xb0 [587895.800395] [<ffffffff810a3ffd>] ? vtime_account_user+0x5d/0x70 [587895.800403] [<ffffffff811e9203>] ? __fdget+0x13/0x20 [587895.800406] [<ffffffff81635679>] __sys_sendmsg+0x49/0x90 [587895.800408] [<ffffffff816356d9>] SyS_sendmsg+0x19/0x20 [587895.800414] [<ffffffff8176d03f>] tracesys+0xe1/0xe6 [587895.800416] ---[ end trace 55c46677bf01913b ]--- [587916.413185] br29: port 5(vethLXCDV4) entered disabled state [587916.535958] br29: port 5(vethLXCDV4) entered disabled state [587916.540988] device vethLXCDV4 left promiscuous mode [587916.541002] br29: port 5(vethLXCDV4) entered disabled state [587916.549984] device vethIMYJ96 entered promiscuous mode [587916.550103] br29: port 5(vethIMYJ96) entered forwarding state [587916.550109] br29: port 5(vethIMYJ96) entered forwarding state
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
We are actually seeing this as well on CentOS as well.