On 1/16/20 11:40 PM, Per Jessen wrote:
Wild guess - on boot-up, any chance the bridge is being started before 'eno1' is up? That must be what you're thinking too, hence the attempt to delay?
Could this theory be proven by leaving the bridge in manual start mode and then starting manually once the system is up?
I've found a workaround. not clear yet if it's a fix. still suspect a race ... In this case, the SM mobo's eth port (eno1) is 'e1000' class, 25: PCI 19.0: 0200 Ethernet controller ... Hardware Class: network Device Name: "Intel i217V #1" Model: "Intel Ethernet Connection I217-LM" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x153a "Ethernet Connection I217-LM" SubVendor: pci 0x15d9 "Super Micro Computer Inc" SubDevice: pci 0x153a Revision: 0x05 Driver: "e1000e" Driver Modules: "e1000e" Device File: eno1 ... digging around, I found an ~ 5yr-old issue, https://serverfault.com/questions/616485/e1000e-reset-adapter-unexpectedly-d... per that post, and some other related info, I added /etc/sysconfig/network/ifcfg-eno1 ... + POST_UP_SCRIPT="wicked:/etc/sysconfig/network/scripts/ethtool.loc" where, conditionally/explicitly, for real/physical interfaces (IFACE == eno1, NOT br0), /etc/sysconfig/network/scripts/ethtool.loc ... + ethtool -K ${IFACE} rx off tx off sg off tso off ufo off gso off gro off lro off rxvlan off txvlan off rxhash off now, on reboot -- after a dozen or so attempts -- there's no more br0 functional intermittency; it's up/functional each & every time and, dmesg | egrep "br0|bridge" | grep -v "pci 0000" [ 2.600285] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 2.689167] PCI host bridge to bus 0000:00 [ 30.759526] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 31.616612] br0: port 1(eno1) entered blocking state [ 31.616614] br0: port 1(eno1) entered disabled state [ 36.378775] br0: port 1(eno1) entered blocking state [ 36.378776] br0: port 1(eno1) entered listening state [ 40.440309] br0: port 1(eno1) entered learning state [ 44.536333] br0: port 1(eno1) entered forwarding state [ 44.536349] br0: topology change detected, propagating [ 44.536503] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready no more trace of that^^ "Could not generate persistent MAC address for br0: No such file or directory" error. ( side note: I _do_ have lsmod | grep br_netfilter br_netfilter 28672 0 bridge 208896 1 br_netfilter not clear whether the br_netfilter msg is a problem; suspect it's just a still noisy info/warn ) so, this^ worked to rm the error; atm, I'm not clear why ... or why it 'suddenly' manifested perhaps default ethtool setting attempts were incorrectly made on the br0 itfc? causing a (now sufficient) race cond? dunno. i've some concern that i've masked -- not fixed -- the problem, so will need to keep an eye on this awhile. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org