From owner-freebsd-net@freebsd.org Sat Dec 14 05:33:43 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 60D5C1E2445 for ; Sat, 14 Dec 2019 05:33:43 +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 47Zbml1y4Qz40H1 for ; Sat, 14 Dec 2019 05:33:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 40EF81E2444; Sat, 14 Dec 2019 05:33:43 +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 3F9331E2443 for ; Sat, 14 Dec 2019 05:33:43 +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 47Zbml0q9Fz40Gy for ; Sat, 14 Dec 2019 05:33:43 +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 F1BF22004E for ; Sat, 14 Dec 2019 05:33:42 +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 xBE5XgSS042074 for ; Sat, 14 Dec 2019 05:33:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xBE5Xg8m042071 for net@FreeBSD.org; Sat, 14 Dec 2019 05:33:42 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: Sat, 14 Dec 2019 05:33:37 +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: artem@viklenko.net 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: cc 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: Sat, 14 Dec 2019 05:33:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D166724 Artem Viklenko changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |artem@viklenko.net --- Comment #41 from Artem Viklenko --- My story.. also had this issue. Two my home routers run 11.3-RELEASE-p5 amd64 and have realtek nics like th= is one: re0 pnpinfo vendor=3D0x10ec device=3D0x8168 subvendor=3D0x1458 subdevice=3D0xe000 class=3D0x020000 at slot=3D0 function=3D0 dbsf=3Dpci0:1:= 0:0 handle=3D\_SB_.PCI0.RP01.PXSX Interrupt request lines: 258 pcib1 I/O port window: 0xe000-0xe0ff pcib1 memory window: 0xd0700000-0xd0703fff 0xd0704000-0xd0704fff I switched to Realtek's driver. But still have wtchdog timeouts. After some Googling I found duscussion about issues with jumbo buffers. After cheking = this idea I found confirmation - after some time (depending on traffic rate/amou= nt) memory became fragmented and requests to 9k buffers fails. Now I use 1.95 driver from vendor but with very-very dirty hack. I've repla= ced Jumbo_Frame_9k with value 3072. So now re driver use only 4k buffers. I'm ok with MTU of 1500 (this change limits max MTU). But now it is stable = and no watchdog timeouts. And no more failures on buffers: artem@gate$ vmstat -z | grep buf mbuf_packet: 256, 2362080, 2, 1265, 9732282, 0, 0 mbuf: 256, 2362080, 514, 1789,17068586803, 0, 0 mbuf_cluster: 2048, 369076, 1267, 21, 531078, 0, 0 mbuf_jumbo_page: 4096, 184537, 513, 263,7618134369, 0, 0 mbuf_jumbo_9k: 9216, 54677, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 30756, 0, 0, 0, 0, 0 I know it is stupid trick but at least it works. :) Hope it can help. --=20 You are receiving this mail because: You are on the CC list for the bug.=