Date: Wed, 25 Sep 2019 14:43:54 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240658] iflib: if_igb(4) and some if_em(4) devices don't recognize/report carrier loss. Message-ID: <bug-240658-7501-GsTot9exot@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-240658-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-240658-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240658 --- Comment #9 from Harald Schmalzbauer <bugzilla.freebsd@omnilan.de> --- Update: The link-state-change issue doesn't affect _configured_ interfaces, so the = fix in https://reviews.freebsd.org/D21769 is most likely perfectly valid. I guess the remaining issue is by design. As long as the interface was never configured, state change only works once= in one direction -> recorded as active. If I have the interface configured before or afterwards, connection change/= loss will be recognized. But not for unconfigured interfaces. So the issue has no production influencing effects. It's might just caus confusion on systems with (cold) standby interfaces, since the admin might assume there's a link active and searches all switches unsuccessfully for t= hat link=E2=80=A6 During this test I saw that assigning an IP address to an already link-established em(4) or igb(4) interface, causes loss/interruption of the establisehd ethernet link. Don't know if this is desired=E2=80=A6 Guess these facts are related and as long as the internal steps configuring= a em/igb(4) (or probably iflib generic?) NIC stay as they are, it won't be possible to catch the link state loss with unconfigured/cold-stanby interfa= ces, right? Thanks, -Harry(In reply to John Delano from comment #7) --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240658-7501-GsTot9exot>