From owner-freebsd-net@freebsd.org Wed Sep 25 14:43:54 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C685D129346 for ; Wed, 25 Sep 2019 14:43:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46dgmV4yf7z40L2 for ; Wed, 25 Sep 2019 14:43:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AA2EC129345; Wed, 25 Sep 2019 14:43:54 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9F52129344 for ; Wed, 25 Sep 2019 14:43:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46dgmV42jsz40L1 for ; Wed, 25 Sep 2019 14:43:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6F517193AC for ; Wed, 25 Sep 2019 14:43:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x8PEhsDD061275 for ; Wed, 25 Sep 2019 14:43:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x8PEhs2c061274 for net@FreeBSD.org; Wed, 25 Sep 2019 14:43:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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. Date: Wed, 25 Sep 2019 14:43:54 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 14:43:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240658 --- Comment #9 from Harald Schmalzbauer --- 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.=