From owner-freebsd-net@freebsd.org Mon Sep 3 14:33:14 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A949CFEBA43 for ; Mon, 3 Sep 2018 14:33:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 430648709E for ; Mon, 3 Sep 2018 14:33:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 07D26FEBA42; Mon, 3 Sep 2018 14:33:14 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA0C3FEBA41 for ; Mon, 3 Sep 2018 14:33:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 639A487099 for ; Mon, 3 Sep 2018 14:33:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C2F6120783 for ; Mon, 3 Sep 2018 14:33:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w83EXC8W064216 for ; Mon, 3 Sep 2018 14:33:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w83EXCA6064215 for net@FreeBSD.org; Mon, 3 Sep 2018 14:33:12 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 166724] [re] if_re watchdog timeout Date: Mon, 03 Sep 2018 14:33:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: zjk7@wp.pl X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: yongari@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.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 14:33:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D166724 --- Comment #34 from zjk --- A. After longer tests - I must cancel the previous optimistic news. We are talking about the 11.2-RELEASE + 1.93-realtek driver: 1. Suspensions, computer stops - still occur. They are only shorter - though still cumbersome.=20 See attachment above. Generally at the beginning the interface works quickly, after some time it slows down and shows signs of loss. 2. There are still messages about the interface suspension. Because I use l= agg it looks like this: + [20445] re1: Interface stopped DISTRIBUTING, possible flapping + [48114] re0: Interface stopped DISTRIBUTING, possible flapping B. Regarding Alex's statements. This is a real problem. Of course, the "watchdog timeout" message itself is not harmful. The important thing is that the message in the function follows the reset a= nd re-initialisation of the interface - this unfortunately results in the loss= or partial destruction of transmitted files / frames (which unfortunately I ha= ve experienced many times). The application of version 1.93-1.94: is therefore of such a improvement t= hat not only does the message disappear (commented out from function - as Alex correctly writes), but the files are not damaged during the transmission (y= et to be checked!). Version 11.2-RELEASE - for me it certainly generates hundreds of messages "watchdog timeout" - but today I do not know if it prevents damage or loss = of transmitted data (to be checked).=20 I see: /* Cancel pending I/O and free all RX/TX buffers. */ re_stop(sc); /* Put controller into known state. */ re_reset(sc); It means: drop, loss transmitted information. C. However, I will not agree with Alex that it is good. Perhaps it is good = for a laptop, too little for the server. It is still terrible. D. Test 11.2 + 1.94 - I have not started yet. --=20 You are receiving this mail because: You are on the CC list for the bug.=