From nobody Mon Aug 2 01:58:52 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 03EC412D2486 for ; Mon, 2 Aug 2021 01:59:03 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GdLlT5Z1Mz4Z9B; Mon, 2 Aug 2021 01:59:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 1721wqb4026306 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Aug 2021 18:58:52 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 1721wq6q026305; Sun, 1 Aug 2021 18:58:52 -0700 (PDT) (envelope-from jmg) Date: Sun, 1 Aug 2021 18:58:52 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org Cc: erj@FreeBSD.org Subject: igb fc (aka flowcontrol) issue... Message-ID: <20210802015852.GF41029@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, erj@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 01 Aug 2021 18:58:52 -0700 (PDT) X-Rspamd-Queue-Id: 4GdLlT5Z1Mz4Z9B X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.22 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.58)[0.584]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I have a dual port igb card: igb0: port 0x2020-0x203f mem 0xd1020000-0xd103ffff,0xd0c00000-0xd0ffffff,0xd1044000-0xd1047fff irq 17 at device 0.0 on pci3 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: Using 4 RX queues 4 TX queues igb0: Using MSI-X interrupts with 5 vectors igb0: Ethernet address: xxxx igb0: netmap queues/slots: TX 4/1024, RX 4/1024 igb1: port 0x2000-0x201f mem 0xd1000000-0xd101ffff,0xd0800000-0xd0bfffff,0xd1040000-0xd1043fff irq 18 at device 0.1 on pci3 igb1: Using 1024 TX descriptors and 1024 RX descriptors igb1: Using 4 RX queues 4 TX queues igb1: Using MSI-X interrupts with 5 vectors igb1: Ethernet address: xxxx igb1: netmap queues/slots: TX 4/1024, RX 4/1024 And I have observed an issue with it when adjusting flow control, it seems to adjust both ports at the same time: # sysctl dev.igb.0.fc dev.igb.0.fc: 3 # sysctl dev.igb.1.fc dev.igb.1.fc: 3 # sysctl dev.igb.0.fc=0 dev.igb.0.fc: 3 -> 0 # sysctl dev.igb.1.fc dev.igb.1.fc: 0 Is this correct behavior? Also, the fc sysctl is not documented, I propose the following: diff --git a/share/man/man4/em.4 b/share/man/man4/em.4 index a1fa22c..bad82e9 100644 --- a/share/man/man4/em.4 +++ b/share/man/man4/em.4 @@ -265,6 +265,26 @@ If is non-zero, this tunable limits the maximum delay in which a transmit interrupt is generated. .El +.Sh SYSCTL VARIABLES +The following variable is availabel: +.Bl -tag -width "dev.em.X.fc" +.It Va dev.em.X.fc +This sysctl sets the flow control for the card (this means both ports +on a dual port card). The values are as follows: +.Bl -tag -width "XX" -offset "XXXX" -compact +.It 0 +Disabled +.It 1 +Process received pause frames, do not transmit them. +.It 2 +Send pause frames, but to not process received frames. +.It 3 +Process and send pause frames. +.It 4 +No software override, use EEPROM configuration. +.El +.El +Note: That the variable is available for igb as well. .Sh FILES .Bl -tag -width /dev/led/em* .It Pa /dev/led/em* -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon Aug 2 04:10:41 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2020312D8AEF for ; Mon, 2 Aug 2021 04:11:02 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GdPgn1PfPz4j6P for ; Mon, 2 Aug 2021 04:11:01 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by mail-lf1-f44.google.com with SMTP id a26so31251326lfr.11 for ; Sun, 01 Aug 2021 21:11:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5fODCknY2v7P3jse2LzBcmelkEVs+a4y+3YsVRZXaCI=; b=gDyAsg6b8/8ZdLUtM+FNF4OD9wJhpL3TcM6+ugEo8Inl9LcOPAofXX3OvHWK7LJeR1 Fdm6d67SNnJvJQdbMMROGUpXIeRyqRlPXfKIAxjgk2Nk8uICI08L185TS23RuSN1bpuv 0ZSLsr9hroaBYooJIDSONpIejzqDpcLl7Ys8TWMU9zxfzJD35axliaC/CfytLUedCTXh 1G1QwNEMN+Aa08u7p3zdbLMTcLZy0IEA7urYqadwwroGWwG4RX32PjLbvh7xMIYIZNgk sHZycqJS5KqvqiOC1UQN8h2mT92OhTQfqn3jCJaUg2zqlAbpF3fH7eOg3GIZILsjdj9e 6buQ== X-Gm-Message-State: AOAM530euiDPKV/+8ar8+FGo1o7Wlxk4J8EQJlgi5Gxhk8lAwollkNuL S0VAffKN92QH2rTC+dL97++djiszBaE= X-Google-Smtp-Source: ABdhPJzNGSbfICw2qj9DJkWZa4TGGvXFpb/uURoeHPmo/VRcmRMPe7Xe/sgAgZO1PDotuK2wKq78Tw== X-Received: by 2002:ac2:54b0:: with SMTP id w16mr6763438lfk.577.1627877453692; Sun, 01 Aug 2021 21:10:53 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id f2sm743716ljq.131.2021.08.01.21.10.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Aug 2021 21:10:52 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id z2so31374367lft.1 for ; Sun, 01 Aug 2021 21:10:52 -0700 (PDT) X-Received: by 2002:a05:6512:218e:: with SMTP id b14mr10890719lft.178.1627877452424; Sun, 01 Aug 2021 21:10:52 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: <20210802015852.GF41029@funkthat.com> In-Reply-To: <20210802015852.GF41029@funkthat.com> From: Eric Joyner Date: Sun, 1 Aug 2021 21:10:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: igb fc (aka flowcontrol) issue... To: freebsd-net@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004a38d105c88bc136" X-Rspamd-Queue-Id: 4GdPgn1PfPz4j6P X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ricera10@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=ricera10@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.99)[-0.991]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.44:from,209.85.167.51:received]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[erj@freebsd.org,ricera10@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.44:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[erj@freebsd.org,ricera10@gmail.com]; MAILMAN_DEST(0.00)[freebsd-net] X-ThisMailContainsUnwantedMimeParts: Y --0000000000004a38d105c88bc136 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 1, 2021 at 6:59 PM John-Mark Gurney wrote: > I have a dual port igb card: > igb0: port 0x2020-0x203f mem > 0xd1020000-0xd103ffff,0xd0c00000-0xd0ffffff,0xd1044000-0xd1047fff irq 17 at > device 0.0 on pci3 > igb0: Using 1024 TX descriptors and 1024 RX descriptors > igb0: Using 4 RX queues 4 TX queues > igb0: Using MSI-X interrupts with 5 vectors > igb0: Ethernet address: xxxx > igb0: netmap queues/slots: TX 4/1024, RX 4/1024 > igb1: port 0x2000-0x201f mem > 0xd1000000-0xd101ffff,0xd0800000-0xd0bfffff,0xd1040000-0xd1043fff irq 18 at > device 0.1 on pci3 > igb1: Using 1024 TX descriptors and 1024 RX descriptors > igb1: Using 4 RX queues 4 TX queues > igb1: Using MSI-X interrupts with 5 vectors > igb1: Ethernet address: xxxx > igb1: netmap queues/slots: TX 4/1024, RX 4/1024 > > And I have observed an issue with it when adjusting flow control, it > seems to adjust both ports at the same time: > # sysctl dev.igb.0.fc > dev.igb.0.fc: 3 > # sysctl dev.igb.1.fc > dev.igb.1.fc: 3 > # sysctl dev.igb.0.fc=0 > dev.igb.0.fc: 3 -> 0 > # sysctl dev.igb.1.fc > dev.igb.1.fc: 0 > > Is this correct behavior? > > Also, the fc sysctl is not documented, I propose the following: > diff --git a/share/man/man4/em.4 b/share/man/man4/em.4 > index a1fa22c..bad82e9 100644 > --- a/share/man/man4/em.4 > +++ b/share/man/man4/em.4 > @@ -265,6 +265,26 @@ If > is non-zero, this tunable limits the maximum delay in which a transmit > interrupt is generated. > .El > +.Sh SYSCTL VARIABLES > +The following variable is availabel: > +.Bl -tag -width "dev.em.X.fc" > +.It Va dev.em.X.fc > +This sysctl sets the flow control for the card (this means both ports > +on a dual port card). The values are as follows: > +.Bl -tag -width "XX" -offset "XXXX" -compact > +.It 0 > +Disabled > +.It 1 > +Process received pause frames, do not transmit them. > +.It 2 > +Send pause frames, but to not process received frames. > +.It 3 > +Process and send pause frames. > +.It 4 > +No software override, use EEPROM configuration. > +.El > +.El > +Note: That the variable is available for igb as well. > .Sh FILES > .Bl -tag -width /dev/led/em* > .It Pa /dev/led/em* > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > I was looking at the hardware specs to see a mention of it, but I didn't find anything. But looking at the code, I do see that in if_em.c's em_set_flowcntl(), the value "input" used in the output of the sysctl is a "static int". So it seems like if you set the value to 0, you're going to read 0 from it, even on the second port. That looks like a bug that needs to be fixed. And for the man page, that sysctl doesn't accept "4" as a valid value (unless you're going to add that?). I wouldn't put that flow control sets the value for both ports on the card, either. But otherwise, that seems reasonable to me. - Eric --0000000000004a38d105c88bc136-- From nobody Mon Aug 2 05:00:33 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4512812DB85D; Mon, 2 Aug 2021 05:00:51 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GdQnG2rTSz4lqb; Mon, 2 Aug 2021 05:00:50 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-vs1-xe2e.google.com with SMTP id b138so2716868vsd.2; Sun, 01 Aug 2021 22:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3ieoG6gKGpCkMBAgvFtW/eLW+fMelEQ83MQ4BUXn9Vk=; b=UgLx6Ttt3szOm+bZU8CXZkVm9kG0CP1f41D8vACAe32ZN1am4GaSSeBztLSroZP6CZ BhPdb8awD+Dl5NybbD8HzaNfFi8AY6EWxNWGArLrT3k6nBmv1WTTu9mTMP5T5D+XJ0Oc edH5O5cyUnjsPAxPvll6Q3FkeKpcM77cL8QRF7t0AZ5BMNB4pr26C+G6EO6drcZ1JeNO UMu8iwhRHsszDnayqFCDbc0/ruDJP0+zjlXrB0S1/XdQLU63BayZxCSnYzhHM93gxGFC 7ZDHNI0OIz30RICwFwgCmdRmRlL/TFUsj+Jf4319CRppkucoIfVFCP93rJxfEhoE2n2y /9Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3ieoG6gKGpCkMBAgvFtW/eLW+fMelEQ83MQ4BUXn9Vk=; b=QBBMSg5KTQY5QrlQUbXoEmdscIXDzvqkjvi7CeLM7nWKXMnn/HrCxiPMGrVi7Ta4DM hy40yhd5PX6bK/ipnf3RYJcvRhzOLA3Ik0jgTaMcXVzat5eQqaX1IbaKiSrvS4bly4I4 JqbU4HdpF2/q4Mx9iD6MrRyPvRXyFPSyQHLdr0aFtpKxvX4zTMGoOE8xZ8/IdBMFVlcd tt9/Zi/Xk3gtZCaIDYW1AkBH8mHwMnoC5HcgK15/aiYRFDNPp+yfRQnyoZYsYSKNvKek RLRz+eycTmum0Y+taxNgbAGk8o6xZYK6vC6jOR/G0L63QzXE38pz3W7/9HtmVcJQY1ux FIig== X-Gm-Message-State: AOAM530zJj88LREy9RbA9bCprsgAxmLUdXA/WiRvt03TXWfwozPvMjdJ /G+oGeQKT6zLaTDcM+9aXBWzP0AJBQYr/cY2EnKN2EXAnIBr92Nh X-Google-Smtp-Source: ABdhPJxMKM9/wL1wn7hCp68ozJno0vOzWZAu16L/w3/cbbNM1ItSq6xgmkc5RSJL50JSr+EDYbcsOFTT6CwUp7WFcoY= X-Received: by 2002:a05:6102:c48:: with SMTP id y8mr8273996vss.14.1627880443886; Sun, 01 Aug 2021 22:00:43 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 2 Aug 2021 08:00:33 +0300 Message-ID: Subject: Wired Memory Increasing about 500MBytes per day To: FreeBSD Net , freebsd-stable Content-Type: multipart/alternative; boundary="0000000000009844c605c88c737b" X-Rspamd-Queue-Id: 4GdQnG2rTSz4lqb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=UgLx6Ttt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::e2e as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-3.34 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:~,2:~]; R_MIXED_CHARSET(0.56)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net,freebsd-stable] X-ThisMailContainsUnwantedMimeParts: Y --0000000000009844c605c88c737b Content-Type: text/plain; charset="UTF-8" Hello, I'm using FreeBSD stable/12 0f97f2a1857a96563792f0d873b11a16ff9f818c (Jul 25) built. pf, ipfw and ipsec options are built with kernel. The server is used as firewall that squid and snort3 (daq - netmap) is running. I saw that, wired memory is increasing every day. It's about 500MBytes per day. I'm checking vmstat and top (sorted by res), I couldn't find what is consuming the wired memory. How can I find that which process or which part of kernel is consuming the wired memory ? # first a few lines of top last pid: 61147; load averages: 3.83, 3.92, 4.02 up 3+14:09:57 07:53:44 4294 threads: 42 running, 4153 sleeping, 99 waiting CPU: 3.1% user, 0.0% nice, 10.4% system, 0.0% interrupt, 86.5% idle Mem: 3074M Active, 11G Inact, 11G Wired, 1572M Buf, 101G Free ARC: 3764M Total, 1385M MFU, 2144M MRU, 2666K Anon, 19M Header, 213M Other 3243M Compressed, 3510M Uncompressed, 1.08:1 Ratio # vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM dev queue 5 1K - 5 64 scsi_da 0 0K - 388 32,256 UART 3 3K - 3 16,1024 USB 43 87K - 78 16,32,128,256,512,1024,2048,4096,16384,32768 USBdev 31 4K - 53 32,64,128,256,512,4096 SCSI ENC 26 133K - 67266 16,64,512,1024,2048,32768,65536 nvlist 282 26K - 52522369 16,32,64,128,256,2048,4096,8192 vtbuf 24 1968K - 46 4096 vt 11 6K - 11 512 acpiintr 1 1K - 1 64 DEVFS3 194 49K - 269 256 DEVFS1 146 73K - 217 512 DEVFS_RULE 56 27K - 56 64,512 DEVFS 15 1K - 20 16,32,128 DEVFSP 529 34K - 748886191 64 nullfs_hash 1 16384K - 1 nullfs_node 27 2K - 34 64 nullfs_mount 10 1K - 11 32 pfs_nodes 20 10K - 20 512 tmpfs mount 3 1K - 3 128 tmpfs name 4791 116K - 18569 16,32,64,128 GEOM 357 54K - 3904 16,32,64,128,256,512,1024,2048,4096,8192,16384 raid_data 0 0K - 612 32,128,256 isadev 7 1K - 7 128 acpica 16568 1655K - 738465 16,32,64,128,256,512,1024,2048,4096 acpitask 1 64K - 1 65536 acpisem 24 3K - 24 128 cdev 4 1K - 4 256 filedesc 367 2390K - 4457314 16,32,64,128,256,512,4096,8192,16384,32768,65536 sigio 17 2K - 415 64 filecaps 6 1K - 90314 16,32,64 kdtrace 4829 1110K - 15580812 64,256 kenv 148 14K - 148 16,32,64,128,8192 kqueue 1176 726K - 25696080 64,128,256,512,2048,4096,8192,16384,32768 proc-args 634 46K - 6581654 16,32,64,128,256 hhook 34 7K - 51 32,256 ithread 449 73K - 455 32,128,256 prison 11 5K - 12 16,32,4096 KTRACE 100 13K - 100 128 evdev 3 3K - 7 1024 linker 481 505K - 633 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 lockf 39 5K - 7173761 64,128 loginclass 3 1K - 8 64 devbuf 19975 49482K - 38585 16,32,64,128,256,512,1024,2048,4096,8192,16384,65536 temp 4192 173K - 75602914 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 module 537 68K - 538 128 mtx_pool 2 72K - 2 8192,65536 osd 14 1K - 129800 16,32,64,128,256 pmchooks 1 1K - 1 128 pmc 2 1K - 2 64 session 93 12K - 437777 128 proc 2 256K - 2 subproc 1468 2561K - 6842581 512,4096 cred 1869 468K - 2482324 256 plimit 83 21K - 827841 256 uidinfo 14 34K - 17233 128,32768 ix 42 117K - 42 512,1024,2048,4096 sysctl 1 1K - 2408297 32,64 sysctloid 15990 820K - 16624 16,32,64,128,256 sysctltmp 0 0K - 5790925 16,64,256,1024 acpidev 179 12K - 179 64 CAM SIM 6 2K - 6 256 tidhash 1 256K - 1 callout 33 9352K - 33 umtx 10204 1276K - 10204 128 p1003.1b 1 1K - 1 16 bus 2040 231K - 341181 16,32,64,128,256,512,1024,4096 bus-sc 202 1751K - 72634 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 devstat 20 41K - 20 32,4096 eventhandler 169 14K - 170 64,128 firmware 26 2K - 26 16,32,128 gtaskqueue 198 44K - 198 16,32,256,8192 kobj 332 1328K - 1289 4096 Per-cpu 1 1K - 1 32 CAM XPT 42 4K - 1443 16,32,64,128,256,512,1024,2048,65536 rman 408 48K - 816 16,32,128 sbuf 1 1K - 839349 16,32,64,128,256,512,2048,4096,8192,16384,32768,65536 toponodes 84 11K - 84 128 CAM DEV 9 18K - 520 2048 taskqueue 648 74K - 942 16,32,64,128,256,512 terminal 11 3K - 11 256 Unitno 65 4K - 3793393 32,64 vmem 4 2368K - 12 4096,8192,16384,32768,65536 ioctlops 0 0K - 2234885 256,512,1024,2048,4096 select 2671 334K - 2671 128 iov 0 0K - 248581529 16,64,128,256,512,1024,4096 msg 4 204K - 4 4096,8192,65536 sem 4 106K - 4 2048,4096 shm 14 58K - 282515 2048,32768 tty 14 14K - 24 1024 pts 1 1K - 11 256 mbuf_tag 0 0K - 339649313 32,64 shmfd 34 23K - 21424 64,256,1024,8192 soname 78 7K - 49413750 16,32,64,128 pcb 990 4460K - 669045 16,32,64,128,1024,2048,8192 kbdmux 6 22K - 8 16,512,1024,2048,16384 acl 0 0K - 124531 4096 vfscache 4 32961K - 4 256,65536 cl_savebuf 0 0K - 247 64 vfs_hash 1 16384K - 1 vnodes 1 1K - 1 256 mount 261 13K - 61165 16,32,64,128,256,1024 statfs 0 0K - 3613124 4096 LED 4 1K - 4 16,128 vnodemarker 0 0K - 214729 512 fadvise 0 0K - 137 32 chacha20random 1 8K - 1 8192 BPF 2535 25717K - 2247023944 16,64,128,256,512,2048,4096 ifdescr 1 1K - 1 16 ifnet 513 1027K - 1482 64,128,256,512,1024,2048,4096 ifaddr 5117 1388K - 15096 16,32,64,128,256,512,2048,4096 ether_multi 13633 1089K - 40471 16,32,64,128 clone 38 5K - 55 128 epair 2 1K - 4 128 ipsec 6 2K - 9 256 lltable 37732 18363K - 246041 256,512 tun 7 1K - 11 32,256 vlan 2864 359K - 38902 64,128,256 iflib 314 3652K - 338 32,64,256,512,1024,4096,8192,16384,32768 routetbl 12731 3113K - 247870 32,64,128,256,512,8192 vnet 2 1K - 3 64 vnet_data 2 384K - 3 vnet_data_free 1 1K - 1 32 igmp 511 64K - 1479 128 in_multi 487 122K - 1446 256 ip_moptions 0 0K - 6 64 encap_export_host 18 1K - 18 32,64 mroutetbl 8 53K - 12 256,2048,8192,16384 sctp_a_it 0 0K - 6133 16 sctp_vrf 2 1K - 3 64 sctp_ifa 1572 197K - 6888 128 sctp_ifn 487 61K - 6888 128 sctp_iter 0 0K - 6133 256 tfo_ccache 2 256K - 3 hostcache 2 64K - 3 32768 LRO 48 960K - 48 8192,32768 tcpfunc 1 1K - 1 64 syncache 2 1088K - 3 in6_multi 4880 686K - 14475 32,256 ip6_moptions 0 0K - 1 32 mld 497 63K - 1461 128 ip6ndp 983 153K - 4354 64,256 inpcbpolicy 6117 192K - 952852053 32 secasvar 8 4K - 1390 256,1024 sahead 8 4K - 1052 256,1024 ipsecpolicy 56 16K - 1530 256,1024 ipsecrequest 44 6K - 1516 128 ipsec-misc 51 2K - 8317 16,32 ipsec-saq 4 4K - 152 256,1024 ipsec-reg 2 1K - 2 32 dummynet 10 2069K - 13 512,1024 dummynet 8 3K - 10 256,512 IpFw/IpAcct 94 2428K - 1721 16,32,64,128,256,512,1024,2048,4096,8192 ipfw_tbl 3 1K - 267 128 pfsync 4 65K - 6 512,32768 pf_temp 0 0K - 10651 32,64 pf_hash 14 23056K - 21 2048 pf_ifnet 543 140K - 30387 128,256,2048 pf_rule 6475 9594K - 70452 128,2048 pf_osfp 2382 245K - 7146 64,128 pf_table 1647 3294K - 56328 2048 linux 5 1K - 6 16,64 linuxcurrent 2 1K - 2 64,256 crypto 58 43K - 3734 128,512,1024,4096 xform 0 0K - 145609856 64 pagedep 1 2048K - 4 256 inodedep 1 16384K - 6 512 bmsafemap 1 8K - 5 256,8192 newblk 1 32768K - 4 256 freeblks 0 0K - 1 128 freefile 0 0K - 1 64 diradd 0 0K - 8 128 mkdir 0 0K - 4 128 dirrem 0 0K - 5 128 newdirblk 0 0K - 2 64 freework 1 1K - 2 16,128 sbdep 0 0K - 3 64 savedino 0 0K - 4 256 softdep 1 1K - 1 512 ufs_dirhash 600 113K - 1164 16,32,64,128,256,512 ufs_mount 9 50K - 68 512,4096,8192 UMAHash 61 9148K - 155 512,1024,2048,4096,8192,16384,32768,65536 md_disk 17 5K - 17 32,4096 md_sectors 16 64K - 16 4096 rpc 1 4K - 1 4096 fpukern_ctx 32 32K - 32 1024 memdesc 1 4K - 1 4096 pci_link 16 2K - 16 64,128 CAM CCB 0 0K - 47838681 2048 mrsasbuf 949 2860K - 951 32,128,256,2048,8192 CAM path 13 1K - 7263 32 CAM periph 10 3K - 541 16,32,64,128,256 netmap 262944 1126176K - 262944 acpi_perf 32 16K - 32 512 sr_iov 6 3K - 6 512 apmdev 1 1K - 1 128 madt_table 0 0K - 2 256,4096 CAM I/O Scheduler 2 1K - 2 128 entropy 1 1K - 5527116 32,4096 intr 4 484K - 4 65536 io_apic 3 6K - 3 2048 local_apic 1 32K - 1 32768 CAM queue 14 52K - 1551 16,32,64,128,256,512,1024,2048,4096,16384 MCA 65 21K - 65 128,256,512 cpus 2 1K - 2 128 msi 87 11K - 87 128 nexusdev 6 1K - 6 16 scsi_cd 0 0K - 8 16 kstat_data 12 1K - 12 64 solaris 366461 463423K - 2105003083 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 sfs_nodes 6 3K - 6 512 aesni_data 2 3K - 2 256,2048 ioat 16 7168K - 16 disc 1 1K - 2 16 gre 5 1K - 5 64,128 netgraph_msg 0 0K - 5 64,128,256 netgraph_hook 0 0K - 2 128 netgraph_node 7 2K - 11 128,256 netgraph_path 0 0K - 4 16 netgraph_sock 6 1K - 9 32,128 netgraph_mppc 0 0K - 2 1024,65536 eli data 35 4K - 865337 64,256,1024,2048,4096,8192,16384,32768,65536 Regards, --0000000000009844c605c88c737b-- From nobody Mon Aug 2 17:51:46 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3740211FFFD9 for ; Mon, 2 Aug 2021 17:51:59 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gdlv23Yw8z4lC3 for ; Mon, 2 Aug 2021 17:51:58 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-yb1-xb33.google.com with SMTP id j77so27805702ybj.3 for ; Mon, 02 Aug 2021 10:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=39e90cbd7Ren02DfBrq3whWKO/7fbURyrZYC/qL9tFY=; b=Q6geustkr245IUUvP21PDOfxMSUajxSKgn9Kal0JQYF5n4f11EVm7wGIqwA036d5yz y3ClvEJCm98z+Q2ALZ2ogi8mZpgXf4B9hlZhaltKnSY32TY8GFt7Rgl0etEUWpP184Rh FK/yXPYKs3fvmedhDP3rs93BLGXNtldXtCnSg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=39e90cbd7Ren02DfBrq3whWKO/7fbURyrZYC/qL9tFY=; b=AhR6fChX8hwM8/FTTpHMBV5Xc9Jj5HRuJb+nCDPVeCFsfsBHYhDmr2sDNyD6g9A2bp 9NeelLThs8+BT5Oec3PII6ioXANFqAwlzGXnXfA9SW+SjothUu01qb997DFyznckZFoF hIv5emfj/6Pz+XfT/OUQK2XjAw3CuIraktQ0ysFdctm/duO/ld7lYC7dUxWGYX6dND3W zlYtHwbOlN2iozDJDd0R4Vrax0sB8GkPlMv4Mdua0WSjDgjUd9pWHMUfXLK8mrzT1za7 sfuKczPv5ij/fj+mAVfZ6kshB0fgg93QN077bJ59A5wATUIvEfzFq1ZTWyAWUhmJUUNk OQGQ== X-Gm-Message-State: AOAM533dSJTqvGRRpjR93r7U7Jk5CybEoUMSPx28kNBED8mnGiLJp6vg sw/zyJwO36Ydo/DJw1FyHz9bNGAJvvM97RN0rR7/ZxAoyloiFg== X-Google-Smtp-Source: ABdhPJyLyQt2KSIiWbxXw5YZO89wToD8W9LTgYPP22PqFZ3Apd0XrkbDXx+YpaliQY4s8Jv+dTAuIYu+OTaQWNZak/4= X-Received: by 2002:a25:ba10:: with SMTP id t16mr22068553ybg.87.1627926717747; Mon, 02 Aug 2021 10:51:57 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 From: Kevin Bowling Date: Mon, 2 Aug 2021 10:51:46 -0700 Message-ID: Subject: igb(4) and VLAN issue? To: FreeBSD Net Cc: Franco Fichtner Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Gdlv23Yw8z4lC3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=kev009.com header.s=google header.b=Q6geustk; dmarc=none; spf=pass (mx1.freebsd.org: domain of kevin.bowling@kev009.com designates 2607:f8b0:4864:20::b33 as permitted sender) smtp.mailfrom=kevin.bowling@kev009.com X-Spamd-Result: default: False [-0.95 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-0.86)[-0.860]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[kev009.com]; NEURAL_SPAM_MEDIUM(0.21)[0.209]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[kev009.com:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b33:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[kev009.com:s=google]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I caught wind that an igb(4) commit I've done to main and that has been in stable/12 for a few months seems to be causing a regression on opnsense. The commit in question is https://cgit.freebsd.org/src/commit/?id=eea55de7b10808b86277d7fdbed2d05d3c6db1b2 The report is at: https://forum.opnsense.org/index.php?topic=23867.0 I haven't heard of this issue elsewhere and cannot replicate it on my I210s running main. I've gone over the code changes line by line several times and verified all the logic and register writes and it all looks correct to my understanding. The only hypothesis I have at the moment is it may be some subtle timing issue since VLAN changes unnecessarily restart the interface on e1000 until I push in a work in progress to stop doing that. I'd like to see the output of all the processes or at least the process configuring the VLANs to see where it is stuck. Franco, do you have the ability to 'control+t' there or otherwise set up a break into a debugger? Stacktraces would be a great start but a core and a kernel may be necessary if it isn't obvious. Regards, Kevin From nobody Mon Aug 2 18:53:46 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B159D12B43CE for ; Mon, 2 Aug 2021 18:53:48 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GdnGN3SzNz4pvJ; Mon, 2 Aug 2021 18:53:48 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 172IrkHC062217 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Aug 2021 11:53:46 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 172IrkJ0062216; Mon, 2 Aug 2021 11:53:46 -0700 (PDT) (envelope-from jmg) Date: Mon, 2 Aug 2021 11:53:46 -0700 From: John-Mark Gurney To: Eric Joyner Cc: freebsd-net@freebsd.org Subject: Re: igb fc (aka flowcontrol) issue... Message-ID: <20210802185346.GG41029@funkthat.com> Mail-Followup-To: Eric Joyner , freebsd-net@freebsd.org References: <20210802015852.GF41029@funkthat.com> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 02 Aug 2021 11:53:46 -0700 (PDT) X-Rspamd-Queue-Id: 4GdnGN3SzNz4pvJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Eric Joyner wrote this message on Sun, Aug 01, 2021 at 21:10 -0700: > On Sun, Aug 1, 2021 at 6:59 PM John-Mark Gurney wrote: > > > I have a dual port igb card: > > igb0: port 0x2020-0x203f mem > > 0xd1020000-0xd103ffff,0xd0c00000-0xd0ffffff,0xd1044000-0xd1047fff irq 17 at > > device 0.0 on pci3 > > igb0: Using 1024 TX descriptors and 1024 RX descriptors > > igb0: Using 4 RX queues 4 TX queues > > igb0: Using MSI-X interrupts with 5 vectors > > igb0: Ethernet address: xxxx > > igb0: netmap queues/slots: TX 4/1024, RX 4/1024 > > igb1: port 0x2000-0x201f mem > > 0xd1000000-0xd101ffff,0xd0800000-0xd0bfffff,0xd1040000-0xd1043fff irq 18 at > > device 0.1 on pci3 > > igb1: Using 1024 TX descriptors and 1024 RX descriptors > > igb1: Using 4 RX queues 4 TX queues > > igb1: Using MSI-X interrupts with 5 vectors > > igb1: Ethernet address: xxxx > > igb1: netmap queues/slots: TX 4/1024, RX 4/1024 > > > > And I have observed an issue with it when adjusting flow control, it > > seems to adjust both ports at the same time: > > # sysctl dev.igb.0.fc > > dev.igb.0.fc: 3 > > # sysctl dev.igb.1.fc > > dev.igb.1.fc: 3 > > # sysctl dev.igb.0.fc=0 > > dev.igb.0.fc: 3 -> 0 > > # sysctl dev.igb.1.fc > > dev.igb.1.fc: 0 > > > > Is this correct behavior? > > > > Also, the fc sysctl is not documented, I propose the following: > > diff --git a/share/man/man4/em.4 b/share/man/man4/em.4 > > index a1fa22c..bad82e9 100644 > > --- a/share/man/man4/em.4 > > +++ b/share/man/man4/em.4 > > @@ -265,6 +265,26 @@ If > > is non-zero, this tunable limits the maximum delay in which a transmit > > interrupt is generated. > > .El > > +.Sh SYSCTL VARIABLES > > +The following variable is availabel: > > +.Bl -tag -width "dev.em.X.fc" > > +.It Va dev.em.X.fc > > +This sysctl sets the flow control for the card (this means both ports > > +on a dual port card). The values are as follows: > > +.Bl -tag -width "XX" -offset "XXXX" -compact > > +.It 0 > > +Disabled > > +.It 1 > > +Process received pause frames, do not transmit them. > > +.It 2 > > +Send pause frames, but to not process received frames. > > +.It 3 > > +Process and send pause frames. > > +.It 4 > > +No software override, use EEPROM configuration. > > +.El > > +.El > > +Note: That the variable is available for igb as well. > > .Sh FILES > > .Bl -tag -width /dev/led/em* > > .It Pa /dev/led/em* > > I was looking at the hardware specs to see a mention of it, but I didn't > find anything. But looking at the code, I do see that in if_em.c's > em_set_flowcntl(), the value "input" used in the output of the sysctl is a > "static int". So it seems like if you set the value to 0, you're going to > read 0 from it, even on the second port. That looks like a bug that needs > to be fixed. Yeah, it looks like reading the status of the flowcontrol doesn't work. It just reads whatever was last set. change intput to: int input; input = adapter->fc; does fix the sysctl problem of reading. But, it does appear that adapter->fc does not get initalized anywhere, which means reading it won't be correct until it's set the first time. And even then, it's initalized to 0, so if you first set it to zero, it won't change anything, because it doesn't have the correct state in the var, and only does the set if the value changed... So w/o additional work, you have to turn it on first, before you can turn if off... > And for the man page, that sysctl doesn't accept "4" as a valid value > (unless you're going to add that?). I wouldn't put that flow control sets > the value for both ports on the card, either. But otherwise, that seems > reasonable to me. Well, I was just going by the comment in e1000_phy.c: * other: No software override. The flow control configuration * in the EEPROM is used. and I picked 4 for other. But now that I look at the code, the code doesn't implement that case. I'll drop that case then. I added that note because that was the observed behavior... I'll drop it as it's been tracked down to a sysctl implemention bug. (I wanted the patch to be what I was going to commit so there wasn't confusion.) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Aug 3 06:38:17 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7026E12B8113; Tue, 3 Aug 2021 06:38:28 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward101p.mail.yandex.net (forward101p.mail.yandex.net [77.88.28.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gf4vQ5gqfz4q63; Tue, 3 Aug 2021 06:38:26 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from sas1-a14f288d3203.qloud-c.yandex.net (sas1-a14f288d3203.qloud-c.yandex.net [IPv6:2a02:6b8:c08:1190:0:640:a14f:288d]) by forward101p.mail.yandex.net (Yandex) with ESMTP id C40683280DED; Tue, 3 Aug 2021 09:38:18 +0300 (MSK) Received: from sas8-b61c542d7279.qloud-c.yandex.net (sas8-b61c542d7279.qloud-c.yandex.net [2a02:6b8:c1b:2912:0:640:b61c:542d]) by sas1-a14f288d3203.qloud-c.yandex.net (mxback/Yandex) with ESMTP id I5otk0kQMT-cIIqs066; Tue, 03 Aug 2021 09:38:18 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1627972698; bh=DS70CxQAQmhZ4B5l5fs66WLXQ17M8HiH4FKNO2CsMbo=; h=In-Reply-To:References:Date:Message-ID:From:To:Subject; b=JmyAsBPvSDlEWybhMdJD0gKjaBcmUjJxZff0sBSOECfgfwo+mt2hztTohNknXwTU4 DkpCvtvRY8oo7IdpDeW5irImWSU3Go+cInBDZquf2UjScxdI/hKXLXqCMVrPOfyyZa +LHXlnSZHsAL7mX5bHG1MdK5s+wWeKOfbrmZPesc= Received: by sas8-b61c542d7279.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 4GQUnT2KsP-cIPWf0l2; Tue, 03 Aug 2021 09:38:18 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: Wired Memory Increasing about 500MBytes per day To: =?UTF-8?Q?=c3=96zkan_KIRIK?= , FreeBSD Net , freebsd-stable References: From: "Andrey V. Elsukov" Message-ID: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> Date: Tue, 3 Aug 2021 09:38:17 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KpCTlTbhCMEmAGAxKd1YDvPe1tKHJVH9y" X-Rspamd-Queue-Id: 4Gf4vQ5gqfz4q63 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=JmyAsBPv; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 77.88.28.101 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-6.10 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[77.88.28.101:from]; FREEMAIL_FROM(0.00)[yandex.ru]; R_SPF_ALLOW(-0.20)[+ip4:77.88.0.0/18]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yandex.ru:+]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:77.88.0.0/18, country:RU]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KpCTlTbhCMEmAGAxKd1YDvPe1tKHJVH9y Content-Type: multipart/mixed; boundary="KQwQjiTBexmmApN3q6SMpi5ONenDMLJJK"; protected-headers="v1" From: "Andrey V. Elsukov" To: =?UTF-8?Q?=c3=96zkan_KIRIK?= , FreeBSD Net , freebsd-stable Message-ID: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> Subject: Re: Wired Memory Increasing about 500MBytes per day References: In-Reply-To: --KQwQjiTBexmmApN3q6SMpi5ONenDMLJJK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 02.08.2021 08:00, =C3=96zkan KIRIK =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hello, >=20 > I'm using FreeBSD stable/12 0f97f2a1857a96563792f0d873b11a16ff9f818c (J= ul > 25) built. > pf, ipfw and ipsec options are built with kernel. The server is used as= > firewall that squid and snort3 (daq - netmap) is running. >=20 > I saw that, wired memory is increasing every day. It's about 500MBytes = per > day. I'm checking vmstat and top (sorted by res), I couldn't find what = is > consuming the wired memory. >=20 > How can I find that which process or which part of kernel is consuming = the > wired memory ? Hi, We noticed the same problem, I'm not sure the exact version, but you can check the output: # vmstat -z | egrep "ITEM|pgcache" The page cache grows until lowmem is not reached. Then it automatically cleans and begins to grow again. --=20 WBR, Andrey V. Elsukov --KQwQjiTBexmmApN3q6SMpi5ONenDMLJJK-- --KpCTlTbhCMEmAGAxKd1YDvPe1tKHJVH9y Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB4BAABCAAjFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAmEI5FkFAwAAAAAACgkQAcXqBBDIoXo/ Twf3bsTjIKLk3tDEvrR+x3qa2fCozPBAqQlI9DED5Y0ZKqdWDxBQgsS9Dh6UgFPfSIRQkxaag/lU JjYAMcMsXrU9Vk/HyXQve4ALCrDW51NmqETUim2hkq7aPqtkCeCLtKk+vCRN9pcA5lRokaL76Pxw hA5MVDBRe/Z0hgsOE1yHi+OIiwB0Jx7z8ORkVPy2igpXKDXK0nsrDm7h5MqAtcwdZNFz3rcIOrFF jfo70Vi+U3nH71KKLwBMTKbOb6qAfnskNC8pgRUc3l2aW5MWPyVVq7iO4PUs1wCrRbfMfmPc3T85 s5zPWm1B6aiDjx7crxKyPtW6NcJXWErhSoka+Nv6 =88TS -----END PGP SIGNATURE----- --KpCTlTbhCMEmAGAxKd1YDvPe1tKHJVH9y-- From nobody Tue Aug 3 08:40:38 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BBBB412DA3A5; Tue, 3 Aug 2021 08:40:55 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gf7cl4HW9z3G2y; Tue, 3 Aug 2021 08:40:55 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-vk1-xa32.google.com with SMTP id o2so1082062vkb.4; Tue, 03 Aug 2021 01:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dbmrDkRq12LsXFyZ6N94myzrDVnUKYj2AsolF1klX2U=; b=DL7MG0hH9vHVEB2NeDjNPm2aQ6tvgUlcTtIWVNK+c+LpmjhmCEibrkvuNHhZQ8Ikqh JQ9A7tcXwUnIxAYb6t/LsFHKxNJv15HrSYjJh+GUhwzStcFXW9FUiWTbgLZo40AzQg6i 7j4QmpALrc7abNy291Xe2XPStVlDBMS7lWsaZgvqf9YbFNNjszbKMHqIcMRAvLp0Tbhy 7ggRW9YtL3VR8OPgfYmb1YGsD8HlPDu7CVFBYMZCZt4nG01pXSK1rD1afI4x4jHGTdCu zF1gQ1ONx9rvpI6VBXhmfgIaXocq93u/VRVXP/pbBOqgoDcAW8R3kwnQn0aUN0dGnvr5 7iiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dbmrDkRq12LsXFyZ6N94myzrDVnUKYj2AsolF1klX2U=; b=l3bLwIZd07RrM5MsgpCJZsG0jR88OeJIXwJhLscW7Ab4SSCLvwOcAfOF3Q1OTfRA32 BPz2anyBmagN/AMxrDYNgbxyI4sjDVAlu9KEJIPjsvAAIXylyMxj0JpUBKZPQmbBvVvT PsBN9PNO8AgBFf88TxMS88e6/SxSog35YYO05TeznaEDVf5+Cf6UnpFu9eCsmZwy8SnS aMZKHbk8l9YvF6KjFWNBmjMmmtVbXk5BlBlFBeVCnHodfEVGfaOuaQs0fE6DbJXTCLJa VYTiTXXJyaw8dGKCOO4r78zIUjfy6qOQCx81gawlj4gGa7MKHL57yXtMNThYWUmQZEqx ndyg== X-Gm-Message-State: AOAM531Zk4yDbOIKYfNcuzSeDHOPR+w7zPzUD84fGdlpeWgOKDVSf+cn cA/jYn/6XxAyqowH2l0n3S7XoRUH9ix8WVn38fI= X-Google-Smtp-Source: ABdhPJzlcWXeY0+sfRC0bBu2FKf5Ax3oct+AauWCvZU09v7lKBEy/ZojbeP/8f97yk+0ZKYe2zBie69eHVoUKGst0+0= X-Received: by 2002:a1f:27cb:: with SMTP id n194mr3812093vkn.10.1627980048750; Tue, 03 Aug 2021 01:40:48 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> In-Reply-To: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Tue, 3 Aug 2021 11:40:38 +0300 Message-ID: Subject: Re: Wired Memory Increasing about 500MBytes per day To: "Andrey V. Elsukov" Cc: FreeBSD Net , freebsd-stable Content-Type: multipart/alternative; boundary="00000000000081dc0805c8a3a4cb" X-Rspamd-Queue-Id: 4Gf7cl4HW9z3G2y X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000081dc0805c8a3a4cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Andrey, There is no line that contains the expression "pgcache". I wonder that, what is the unit of USED column in vmstat -z output ? Is the size of allocated memory USED * SIZE bytes or USED bytes? Best regards Full output is below: # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 248, 0, 319, 11, 359, 0, 0 UMA Zones: 4560, 0, 336, 0, 376, 0, 0 UMA Slabs: 80, 0, 1169247, 53, 1699393, 0, 0 UMA Hash: 256, 0, 54, 66, 118, 0, 0 4 Bucket: 32, 0, 5921, 25454, 6151897,41078, 0 6 Bucket: 48, 0, 4673, 8026, 732085,20928, 0 8 Bucket: 64, 0, 479, 9937, 419289, 27, 0 12 Bucket: 96, 0, 710, 11180, 1250497, 0, 0 16 Bucket: 128, 0, 2582, 5819, 1785201, 1, 0 32 Bucket: 256, 0, 4633, 5012, 2195286, 36, 0 64 Bucket: 512, 0, 13125, 3267, 5701310,9620, 0 128 Bucket: 1024, 0, 3334, 11242, 4554012,346379, 0 256 Bucket: 2048, 0, 8660, 8440,20970638,173535, 0 vmem: 1856, 0, 5, 1, 5, 0, 0 vmem btag: 56, 0, 330495, 13571, 461111,2424, 0 VM OBJECT: 256, 0, 168447, 9798,369781693, 0, 0 RADIX NODE: 144, 0, 436035, 33441,2901117593, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 120, 0, 39, 1215, 50, 0, 0 MAP ENTRY: 120, 0, 90901, 99905,2208250219, 0, 0 VMSPACE: 2560, 0, 490, 373, 9289416, 0, 0 fakepg: 104, 0, 86332, 2132, 332434, 0, 0 64 pcpu: 8, 0, 142484, 51052,7062995842, 0, 0 mt_stats_zone: 64, 0, 466, 1326, 466, 0, 0 mt_zone: 24, 0, 466, 1371, 466, 0, 0 16: 16, 0, 208830, 9289,272077367, 0, 0 32: 32, 0, 48286, 194464,2109722462, 0, 0 64: 64, 0, 107071, 76387,2375363883, 0, 0 128: 128, 0, 70403, 9980,644411569, 0, 0 256: 256, 0, 45534, 92706,364555548, 0, 0 512: 512, 0, 71594, 31246,1121480580, 0, 0 1024: 1024, 0, 2185, 5295,13869658, 0, 0 2048: 2048, 0, 7746, 5946,841931150, 0, 0 4096: 4096, 0, 11727, 1098,2051928729, 0, 0 8192: 8192, 0, 190, 1127, 1030363, 0, 0 16384: 16384, 0, 342, 374, 3018731, 0, 0 32768: 32768, 0, 95, 240, 37167, 0, 0 65536: 65536, 0, 22, 237, 3510242, 0, 0 SLEEPQUEUE: 80, 0, 5387, 1991, 5387, 0, 0 kenv: 258, 0, 0, 930, 31479, 0, 0 Files: 80, 0, 11109, 5141,2664152238, 0, 0 filedesc0: 1104, 0, 580, 554, 9289505, 0, 0 rangeset pctrie nodes: 144, 0, 0, 0, 0, 0, 0 TURNSTILE: 136, 0, 5387, 1033, 5387, 0, 0 rl_entry: 40, 0, 3805, 4295, 3805, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 umtx_shm: 88, 0, 0, 0, 0, 0, 0 PROC: 1328, 0, 579, 609, 9289504, 0, 0 PGRP: 88, 0, 139, 4766, 854732, 0, 0 THREAD: 1840, 0, 5017, 369, 2528920, 0, 0 cpuset: 104, 0, 83, 9124,10129425, 0, 0 domainset: 40, 0, 0, 10664,10128542, 0, 0 mbuf_packet: 256, 52258575, 44, 11088,1852136666, 0, = 0 mbuf: 256, 52258575, 17706, 76162,67690430068, 0, 0 mbuf_cluster: 2048, 4194304, 28613, 69253,9891367484, 0, 0 mbuf_jumbo_page: 4096, 4194304, 58, 6942,137882987, 0, 0 mbuf_jumbo_9k: 9216, 4194304, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 4194304, 0, 0, 0, 0, 0 epoch_record pcpu: 256, 0, 4, 60, 4, 0, 0 ttyinq: 160, 0, 345, 1255, 1260, 0, 0 ttyoutq: 256, 0, 181, 1229, 661, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 g_bio: 376, 0, 0, 7240,242269396, 0, 0 nvme_request: 128, 0, 0, 0, 0, 0, 0 linux_dma_pctrie: 144, 0, 0, 0, 0, 0, 0 linux_dma_object: 24, 0, 0, 0, 0, 0, 0 cryptop: 128, 0, 0, 3875,223334488, 0, 0 cryptodesc: 120, 0, 0, 3894,446668976, 0, 0 crypto_session: 32, 0, 52, 6573, 1658, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 10126,19754313, 0, 0 VNODE: 480, 0, 214648, 20600, 1718597, 0, 0 VNODEPOLL: 120, 0, 577, 2426, 583, 0, 0 BUF TRIE: 144, 0, 5630, 100318, 218154, 0, 0 NAMEI: 1024, 0, 0, 588,1653146904, 0, 0 rentr: 24, 0, 0, 6346, 60, 0, 0 S VFS Cache: 108, 0, 235197, 18063, 2651588, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 32648, 17116, 582649, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 592, 0, 0, 0, 0, 0, 0 TMPFS dirent: 64, 0, 4440, 7712, 19999, 0, 0 TMPFS node: 232, 0, 4443, 2034, 19973, 0, 0 DIRHASH: 1024, 0, 722, 266, 1186, 0, 0 AIO: 208, 0, 0, 0, 0, 0, 0 AIOP: 32, 0, 0, 0, 0, 0, 0 AIOCB: 752, 0, 0, 0, 0, 0, 0 AIOLIO: 280, 0, 0, 0, 0, 0, 0 Mountpoints: 2744, 0, 20, 37, 38, 0, 0 pipe: 760, 0, 901, 519, 8706755, 0, 0 range_seg_cache: 72, 0, 66491, 22719,74165680, 0, 0 zio_cache: 1064, 0, 72, 11907,592560580, 0, 0 zio_link_cache: 48, 0, 0, 15687,357212950, 0, 0 zio_buf_512: 512, 0, 77411, 24661,11199087, 0, 0 zio_data_buf_512: 512, 0, 1174, 5266, 1436149, 0, 0 zio_buf_1024: 1024, 0, 3212, 1672,12780522, 0, 0 zio_data_buf_1024: 1024, 0, 52, 6112, 373117, 0, 0 zio_buf_1536: 1536, 0, 1455, 1097, 4976011, 0, 0 zio_data_buf_1536: 1536, 0, 28, 3266, 289325, 0, 0 zio_buf_2048: 2048, 0, 618, 352, 8691140, 0, 0 zio_data_buf_2048: 2048, 0, 163, 2059, 269746, 0, 0 zio_buf_2560: 2560, 0, 581, 396, 3094742, 0, 0 zio_data_buf_2560: 2560, 0, 93, 1185, 167722, 0, 0 zio_buf_3072: 3072, 0, 556, 494, 2840559, 0, 0 zio_data_buf_3072: 3072, 0, 34, 1090, 159095, 0, 0 zio_buf_3584: 3584, 0, 947, 709, 1490250, 0, 0 zio_data_buf_3584: 3584, 0, 20, 715, 224546, 0, 0 zio_buf_4096: 4096, 0, 166, 1303,13023905, 0, 0 zio_data_buf_4096: 4096, 0, 16, 599, 154265, 0, 0 zio_buf_5120: 5120, 0, 1, 140, 1345926, 0, 0 zio_data_buf_5120: 5120, 0, 1, 970, 242653, 0, 0 zio_buf_6144: 6144, 0, 0, 52, 1213631, 0, 0 zio_data_buf_6144: 6144, 0, 1, 285, 216486, 0, 0 zio_buf_7168: 7168, 0, 0, 47, 607077, 0, 0 zio_data_buf_7168: 7168, 0, 0, 237, 202376, 0, 0 zio_buf_8192: 8192, 0, 0, 130, 844604, 0, 0 zio_data_buf_8192: 8192, 0, 6, 624, 617273, 0, 0 zio_buf_10240: 10240, 0, 0, 123, 1373328, 0, 0 zio_data_buf_10240: 10240, 0, 0, 283, 350411, 0, 0 zio_buf_12288: 12288, 0, 0, 46, 858299, 0, 0 zio_data_buf_12288: 12288, 0, 0, 208, 323037, 0, 0 zio_buf_14336: 14336, 0, 0, 120, 428576, 0, 0 zio_data_buf_14336: 14336, 0, 1, 216, 305149, 0, 0 zio_buf_16384: 16384, 0, 9653, 2525,20964516, 0, 0 zio_data_buf_16384: 16384, 0, 9, 176, 456835, 0, 0 zio_buf_20480: 20480, 0, 0, 119, 795267, 0, 0 zio_data_buf_20480: 20480, 0, 0, 164, 483075, 0, 0 zio_buf_24576: 24576, 0, 0, 46, 429295, 0, 0 zio_data_buf_24576: 24576, 0, 3, 123, 594582, 0, 0 zio_buf_28672: 28672, 0, 0, 118, 262110, 0, 0 zio_data_buf_28672: 28672, 0, 0, 110, 364518, 0, 0 zio_buf_32768: 32768, 0, 0, 118, 394929, 0, 0 zio_data_buf_32768: 32768, 0, 5, 103, 381180, 0, 0 zio_buf_40960: 40960, 0, 0, 57, 2657377, 0, 0 zio_data_buf_40960: 40960, 0, 10, 103, 584120, 0, 0 zio_buf_49152: 49152, 0, 0, 114, 408783, 0, 0 zio_data_buf_49152: 49152, 0, 3, 74, 464573, 0, 0 zio_buf_57344: 57344, 0, 0, 46, 167327, 0, 0 zio_data_buf_57344: 57344, 0, 4, 70, 373816, 0, 0 zio_buf_65536: 65536, 0, 0, 47, 257894, 0, 0 zio_data_buf_65536: 65536, 0, 4, 59, 302051, 0, 0 zio_buf_81920: 81920, 0, 1, 132, 955338, 0, 0 zio_data_buf_81920: 81920, 0, 3, 77, 450696, 0, 0 zio_buf_98304: 98304, 0, 0, 44, 121696, 0, 0 zio_data_buf_98304: 98304, 0, 4, 73, 346558, 0, 0 zio_buf_114688: 114688, 0, 0, 57, 1137288, 0, 0 zio_data_buf_114688: 114688, 0, 2, 67, 280633, 0, 0 zio_buf_131072: 131072, 0, 150, 977, 8454261, 0, 0 zio_data_buf_131072: 131072, 0, 947, 8269, 7147735, 0, 0 zio_buf_163840: 163840, 0, 0, 43, 59952, 0, 0 zio_data_buf_163840: 163840, 0, 0, 0, 0, 0, 0 zio_buf_196608: 196608, 0, 0, 42, 24411, 0, 0 zio_data_buf_196608: 196608, 0, 0, 0, 0, 0, 0 zio_buf_229376: 229376, 0, 0, 44, 43421, 0, 0 zio_data_buf_229376: 229376, 0, 0, 0, 0, 0, 0 zio_buf_262144: 262144, 0, 0, 114, 528339, 0, 0 zio_data_buf_262144: 262144, 0, 0, 0, 0, 0, 0 zio_buf_327680: 327680, 0, 0, 42, 10491, 0, 0 zio_data_buf_327680: 327680, 0, 0, 0, 0, 0, 0 zio_buf_393216: 393216, 0, 0, 46, 222631, 0, 0 zio_data_buf_393216: 393216, 0, 0, 0, 0, 0, 0 zio_buf_458752: 458752, 0, 0, 40, 2759, 0, 0 zio_data_buf_458752: 458752, 0, 0, 0, 0, 0, 0 zio_buf_524288: 524288, 0, 0, 44, 123813, 0, 0 zio_data_buf_524288: 524288, 0, 0, 0, 0, 0, 0 zio_buf_655360: 655360, 0, 0, 43, 67660, 0, 0 zio_data_buf_655360: 655360, 0, 0, 0, 0, 0, 0 zio_buf_786432: 786432, 0, 0, 43, 41466, 0, 0 zio_data_buf_786432: 786432, 0, 0, 0, 0, 0, 0 zio_buf_917504: 917504, 0, 0, 41, 27428, 0, 0 zio_data_buf_917504: 917504, 0, 0, 0, 0, 0, 0 zio_buf_1048576: 1048576, 0, 0, 122, 136239, 0, 0 zio_data_buf_1048576: 1048576, 0, 0, 0, 0, 0, 0 zio_buf_1310720: 1310720, 0, 0, 0, 0, 0, 0 zio_data_buf_1310720: 1310720, 0, 0, 0, 0, 0, 0 zio_buf_1572864: 1572864, 0, 0, 0, 0, 0, 0 zio_data_buf_1572864: 1572864, 0, 0, 0, 0, 0, 0 zio_buf_1835008: 1835008, 0, 0, 0, 0, 0, 0 zio_data_buf_1835008: 1835008, 0, 0, 0, 0, 0, 0 zio_buf_2097152: 2097152, 0, 0, 0, 0, 0, 0 zio_data_buf_2097152: 2097152, 0, 0, 0, 0, 0, 0 zio_buf_2621440: 2621440, 0, 0, 0, 0, 0, 0 zio_data_buf_2621440: 2621440, 0, 0, 0, 0, 0, 0 zio_buf_3145728: 3145728, 0, 0, 0, 0, 0, 0 zio_data_buf_3145728: 3145728, 0, 0, 0, 0, 0, 0 zio_buf_3670016: 3670016, 0, 0, 0, 0, 0, 0 zio_data_buf_3670016: 3670016, 0, 0, 0, 0, 0, 0 zio_buf_4194304: 4194304, 0, 0, 0, 0, 0, 0 zio_data_buf_4194304: 4194304, 0, 0, 0, 0, 0, 0 zio_buf_5242880: 5242880, 0, 0, 0, 0, 0, 0 zio_data_buf_5242880: 5242880, 0, 0, 0, 0, 0, 0 zio_buf_6291456: 6291456, 0, 0, 0, 0, 0, 0 zio_data_buf_6291456: 6291456, 0, 0, 0, 0, 0, 0 zio_buf_7340032: 7340032, 0, 0, 0, 0, 0, 0 zio_data_buf_7340032: 7340032, 0, 0, 0, 0, 0, 0 zio_buf_8388608: 8388608, 0, 0, 0, 0, 0, 0 zio_data_buf_8388608: 8388608, 0, 0, 0, 0, 0, 0 zio_buf_10485760: 10485760, 0, 0, 0, 0, 0, 0 zio_data_buf_10485760: 10485760, 0, 0, 0, 0, 0, = 0 zio_buf_12582912: 12582912, 0, 0, 0, 0, 0, 0 zio_data_buf_12582912: 12582912, 0, 0, 0, 0, 0, = 0 zio_buf_14680064: 14680064, 0, 0, 0, 0, 0, 0 zio_data_buf_14680064: 14680064, 0, 0, 0, 0, 0, = 0 zio_buf_16777216: 16777216, 0, 0, 0, 0, 0, 0 zio_data_buf_16777216: 16777216, 0, 0, 0, 0, 0, = 0 lz4_ctx: 16384, 0, 0, 503,36019118, 0, 0 abd_chunk: 4096, 0, 876778, 136943,362609205, 0, 0 sa_cache: 144, 0, 72760, 21740, 1463848, 0, 0 dnode_t: 736, 0, 248894, 476, 882132, 0, 0 arc_buf_hdr_t_full: 256, 0, 77080, 24200,17401584, 0, 0 arc_buf_hdr_t_l2only: 96, 0, 0, 0, 0, 0, 0 arc_buf_t: 64, 0, 10860, 21566,19786749, 0, 0 dmu_buf_impl_t: 240, 0, 83832, 37096,12772494, 0, 0 zil_lwb_cache: 320, 0, 12, 1848, 3352551, 0, 0 zil_zcw_cache: 80, 0, 0, 4500, 3376111, 0, 0 sio_cache: 128, 0, 0, 0, 0, 0, 0 zfs_znode_cache: 288, 0, 72760, 20684, 1463848, 0, 0 procdesc: 136, 0, 0, 493, 12, 0, 0 ksiginfo: 112, 0, 1142, 5368, 1505245, 0, 0 itimer: 352, 0, 0, 0, 0, 0, 0 KNOTE: 160, 0, 5940, 4585,903598090, 0, 0 socket: 872, 4188668, 7375, 2101,1284993007, 0, 0 unpcb: 256, 4188675, 658, 3137, 6017512, 0, 0 IPsec SA lft_c: 16, 0, 20, 7148, 2440, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 4188672, 1966, 192586,1276089120, 0, 0 udpcb: 32, 4188750, 1966, 10034,1276089120, 0, 0 tcp_inpcb: 488, 4188672, 4769, 2639, 2844329, 0, 0 tcpcb: 984, 4188668, 4738, 1166, 2844329, 0, 0 tcptw: 88, 50040, 31, 4244, 1142771, 0, 0 syncache: 168, 409607, 0, 2576, 1711535, 0, 0 hostcache: 96, 15375, 2982, 4521, 119241, 0, 0 sackhole: 32, 0, 5, 6370, 1481420, 0, 0 tfo: 4, 0, 0, 0, 0, 0, 0 tfo_ccache_entries: 80, 0, 0, 0, 0, 0, 0 tcpreass: 48, 262197, 0, 10126, 82900, 0, 0 sctp_ep: 1280, 4188669, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 7885, 7629, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 4188672, 0, 0, 0, 0, 0 ripcb: 488, 4188672, 0, 816, 1297, 0, 0 rtentry: 208, 0, 3255, 1210, 10261, 0, 0 pf mtags: 48, 0, 9, 24310,749080996, 0, 0 pf tags: 104, 0, 135, 397, 146, 0, 0 pf states: 304, 10000003, 80811, 681327,480229109, 0, 0 pf state keys: 88, 0, 111211, 663284,543304602, 0, 0 pf source nodes: 136, 100021, 4290, 2728, 2820231, 0, 0 pf table entry counters: 64, 0, 0, 0, 0, 0, = 0 pf table entries: 160, 2000000, 51780, 48870, 258685, 0, 0 pf frags: 256, 0, 0, 2325,68167738, 0, 0 pf frag entries: 40, 1000000, 0, 9900,136389653, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 IPFW counters: 16, 0, 5, 1787, 469, 0, 0 IPFW dynamic states data: 88, 16425, 0, 0, 0, 0, 0 IPFW parent dynamic states: 32, 4125, 0, 0, 0, 0, 0 IPFW IPv4 dynamic states: 40, 0, 0, 0, 0, 0, 0 IPFW IPv6 dynamic states: 72, 0, 0, 0, 0, 0, 0 divcb: 488, 4188672, 0, 0, 0, 0, 0 bridge_rtnode: 88, 0, 0, 0, 0, 0, 0 selfd: 64, 0, 3711, 10735,6515034986, 0, 0 swpctrie: 144, 16330842, 0, 0, 0, 0, 0 swblk: 136, 16330828, 0, 0, 0, 0, 0 FFS inode: 160, 0, 137291, 1384, 234507, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 137291, 1369, 234502, 0, 0 NetGraph items: 72, 65565, 0, 155, 7, 0, 0 NetGraph data items: 72, 65565, 0, 155, 4, 0, 0 NAT64LSN hosts: 88, 0, 0, 0, 0, 0, 0 NAT64LSN portgroup chunks: 256, 0, 0, 0, 0, 0, 0 NAT64LSN portgroups: 32, 0, 0, 0, 0, 0, 0 NAT64LSN links: 24, 0, 0, 0, 0, 0, 0 NAT64LSN states: 4096, 0, 0, 0, 0, 0, 0 NAT64LSN jobs: 112, 0, 0, 0, 0, 0, 0 md0: 512, 0, 571, 69, 571, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 4188672, 0, 904, 40446, 0, 0 udpcb: 32, 4188750, 0, 7875, 40446, 0, 0 tcp_inpcb: 488, 4188672, 3, 85, 3, 0, 0 tcpcb: 984, 4188668, 3, 37, 3, 0, 0 tcptw: 88, 50040, 0, 0, 0, 0, 0 syncache: 168, 409607, 0, 0, 0, 0, 0 hostcache: 96, 15375, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 tfo: 4, 0, 0, 0, 0, 0, 0 tfo_ccache_entries: 80, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 4188669, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 830, 6, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 4188672, 0, 0, 0, 0, 0 divcb: 488, 4188672, 0, 0, 0, 0, 0 ripcb: 488, 4188672, 0, 0, 0, 0, 0 rtentry: 208, 0, 118, 205, 118, 0, 0 pf tags: 104, 0, 1, 151, 1, 0, 0 pf states: 304, 1000012, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entry counters: 64, 0, 0, 0, 0, 0, = 0 pf table entries: 160, 2000000, 27, 173, 52, 0, 0 pf frags: 256, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 100000, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 IPFW counters: 16, 0, 1, 255, 1, 0, 0 IPFW dynamic states data: 88, 16425, 0, 0, 0, 0, 0 IPFW parent dynamic states: 32, 4125, 0, 0, 0, 0, 0 IPFW IPv4 dynamic states: 40, 0, 0, 0, 0, 0, 0 IPFW IPv6 dynamic states: 72, 0, 0, 0, 0, 0, 0 bridge_rtnode: 88, 0, 0, 0, 0, 0, 0 On Tue, Aug 3, 2021 at 9:38 AM Andrey V. Elsukov wrote: > 02.08.2021 08:00, =C3=96zkan KIRIK =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Hello, > > > > I'm using FreeBSD stable/12 0f97f2a1857a96563792f0d873b11a16ff9f818c (J= ul > > 25) built. > > pf, ipfw and ipsec options are built with kernel. The server is used as > > firewall that squid and snort3 (daq - netmap) is running. > > > > I saw that, wired memory is increasing every day. It's about 500MBytes > per > > day. I'm checking vmstat and top (sorted by res), I couldn't find what = is > > consuming the wired memory. > > > > How can I find that which process or which part of kernel is consuming > the > > wired memory ? > > Hi, > > We noticed the same problem, I'm not sure the exact version, but you can > check the output: > # vmstat -z | egrep "ITEM|pgcache" > > The page cache grows until lowmem is not reached. Then it automatically > cleans and begins to grow again. > > -- > WBR, Andrey V. Elsukov > > --00000000000081dc0805c8a3a4cb-- From nobody Tue Aug 3 10:32:22 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6946C10F9A37; Tue, 3 Aug 2021 10:32:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward105p.mail.yandex.net (forward105p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfB5Y1BdNz3hg0; Tue, 3 Aug 2021 10:32:32 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward101q.mail.yandex.net (forward101q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb98]) by forward105p.mail.yandex.net (Yandex) with ESMTP id C67684D41CB4; Tue, 3 Aug 2021 13:32:23 +0300 (MSK) Received: from vla1-836988b2d41f.qloud-c.yandex.net (vla1-836988b2d41f.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:3890:0:640:8369:88b2]) by forward101q.mail.yandex.net (Yandex) with ESMTP id C1FE3CF40007; Tue, 3 Aug 2021 13:32:23 +0300 (MSK) Received: from vla5-47b3f4751bc4.qloud-c.yandex.net (vla5-47b3f4751bc4.qloud-c.yandex.net [2a02:6b8:c18:3508:0:640:47b3:f475]) by vla1-836988b2d41f.qloud-c.yandex.net (mxback/Yandex) with ESMTP id ibFw7svalH-WNIKnQNK; Tue, 03 Aug 2021 13:32:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1627986743; bh=/sfMD7pn9zauh8q4YFk3Ya0/S0I1TjWmnLox+lYl8u4=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=gcE+rHlG3ZSo0I1bPv5e0igA5YbZBsrSuLbgWDXRLtF7wexU+8Z2ufRauyzgiJ4Jd fl/BppCxDjnKPaavBPCwXChvCMV4S+2JDHjwUI5tgUl5uWqDA3tUQQYq7uV8roEhNV SFlGcktX/OegwpFwGuLtkxEgW64/xpTOS4hsDb8k= Received: by vla5-47b3f4751bc4.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id OWaphhN7SU-WNj0XPng; Tue, 03 Aug 2021 13:32:23 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: Wired Memory Increasing about 500MBytes per day To: =?UTF-8?Q?=c3=96zkan_KIRIK?= Cc: FreeBSD Net , freebsd-stable References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> From: "Andrey V. Elsukov" Message-ID: <6ad4bcef-974e-603d-1e3f-eb9539002b10@yandex.ru> Date: Tue, 3 Aug 2021 13:32:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xUWMPSiJlPlbhqWrqiRFzEgqaOQdRWDGU" X-Rspamd-Queue-Id: 4GfB5Y1BdNz3hg0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xUWMPSiJlPlbhqWrqiRFzEgqaOQdRWDGU Content-Type: multipart/mixed; boundary="DwvkKqe7hXJDTb6qO6XWpoLUYOvRDYJxp"; protected-headers="v1" From: "Andrey V. Elsukov" To: =?UTF-8?Q?=c3=96zkan_KIRIK?= Cc: FreeBSD Net , freebsd-stable Message-ID: <6ad4bcef-974e-603d-1e3f-eb9539002b10@yandex.ru> Subject: Re: Wired Memory Increasing about 500MBytes per day References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> In-Reply-To: --DwvkKqe7hXJDTb6qO6XWpoLUYOvRDYJxp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 03.08.2021 11:40, =C3=96zkan KIRIK =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Thank you Andrey, >=20 > There is no line that contains the expression "pgcache". Probably, it is only on 13+. > I wonder that, what is the unit of USED column in vmstat -z output ? > Is the size of allocated memory USED * SIZE bytes or USED bytes? Yes, USED is the number of entries with SIZE bytes each. --=20 WBR, Andrey V. Elsukov --DwvkKqe7hXJDTb6qO6XWpoLUYOvRDYJxp-- --xUWMPSiJlPlbhqWrqiRFzEgqaOQdRWDGU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAmEJGzYFAwAAAAAACgkQAcXqBBDIoXrw 9wf+J2imlr12EWzm3f9cMP97r2IE6zK86OZVDAMKmMpBd8KTLkhBeN7vf3PiaTSx+KLDCHTNXn3H UnOP3Hsi2Lc2nT07Tk4V1+I+4bxr+kYy18Gdydb1Ub+IWVM/QXVy3LNKKQBksmXy5MwjO3sGAuRU ZoCqdbMBxvmxSB+HCMEosn5juhwsK241e4+c5TCV4ibV7did+bNvvtaT1hakk0Z9T1NqGn2H7qMp unrJl+ufQtv57HdRS+9xme8uITNXM+hyu6A6glSuOtNRvLm/HMUY/8+6P5MYjcG7pQ4xFOWacUuz s9WroQZdTz8t90rQvDpjG4ZUsc70RGu2HYzDnSZsNg== =nRwX -----END PGP SIGNATURE----- --xUWMPSiJlPlbhqWrqiRFzEgqaOQdRWDGU-- From nobody Tue Aug 3 13:10:45 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0278011FCDC9 for ; Tue, 3 Aug 2021 13:10:45 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfFc46QlYz3w4L for ; Tue, 3 Aug 2021 13:10:44 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C4FFE13C1C for ; Tue, 3 Aug 2021 13:10:44 +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 173DAin3001594 for ; Tue, 3 Aug 2021 13:10:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 173DAi4G001593 for net@FreeBSD.org; Tue, 3 Aug 2021 13:10:44 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 256882] cc(4): Panic on DELL R630 with Chelsio T62100-SO-CR) lagg0 and vlans in VNET jails (VNET): ip_tryforward / ip_findroute Date: Tue, 03 Aug 2021 13:10:45 +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: 13.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: konrad.kreciwilk@korbank.pl X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: melifaro@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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256882 --- Comment #7 from Konrad --- I applied the patch. I will send you feedback in a few days --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Aug 3 13:47:13 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD35012D9BB5; Tue, 3 Aug 2021 13:47:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfGQ94K96z4VP7; Tue, 3 Aug 2021 13:47:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id h10so13952801qth.5; Tue, 03 Aug 2021 06:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=pWRyDEXI9ta6X9SsIJ7NlKZaCSItKV4GjqxstcIRsps=; b=QrJj4Gk1S+LqqwCOIy10M7u1sWsYS80KqX4hrUIUUtUhtQ/BdQhqEQMiwzNVcFQJyK 0hZs7K27pdPvfDl8s4cvcpVDlckCsqOG9M5kfqu2uOkA+K4jLDwBPmXuoHG8oYAPaduR CxXk9AIUSRIUWUxD8zUqTTAMzAg+LGHTfW5XJza4FCaDXFTtyVIP6RCMw39bCIu24/z+ yvW7nL75XopNmY9MzCDw8a0DNYABX0322bJ8wi0XoEiSjc8AnjlIptw8zei3zn5eb52m YTYJOjJRVabO9hSFBY99t/YgPIn9W+u78+AvTW42VX1dkhINtzGJkL8EvVBDmYOj9Xs8 58nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=pWRyDEXI9ta6X9SsIJ7NlKZaCSItKV4GjqxstcIRsps=; b=tKt4jQq2rYZX6X1cDgXQYy7J0tyyaw2j9ziGvL6p06tXzspV/o/mphE4DwrlTHAUjV GLsrqdXTYDNwedvHLxm1Gz8BZpR+ssjwLgE58uvm0EO9X2p0pCeUbX6znjDbFTkbuW+A TJv+0HNlprUs6lQIO2+CGwN4icuA40Rn8GW0GPJvdpXDZvNSWX/4tmhHtbwPMkQZC0F0 ntoPhca/uz34L8uGgRAm8FbkWsROdjMI4VRsUDhfVnqpOKZUTGENzQApnJt3Klesg7C6 a9r0+DBZIeONl7SQaWHzAS8LciHFF97/HClvXv9cWiiOfZjQGn6XOHaGyeDIlFAPm5cb gSeg== X-Gm-Message-State: AOAM530WdhoDInR31xxlQzIFsawuUBCbHieXPx8FfjVysbV5oNCn1Oyz tcNjdwWGaZFlSHF9VMikz0s= X-Google-Smtp-Source: ABdhPJy8blrxm/OPzRX/6lCoWyvoy4CJlKJCtQ6cLyXW3SyM0TSkkM07WlgD1TdafpfIG1WHXJUEbg== X-Received: by 2002:a05:622a:1a9f:: with SMTP id s31mr18500579qtc.151.1627998433201; Tue, 03 Aug 2021 06:47:13 -0700 (PDT) Received: from nuc ([142.126.162.193]) by smtp.gmail.com with ESMTPSA id x7sm7643200qki.102.2021.08.03.06.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Aug 2021 06:47:12 -0700 (PDT) Date: Tue, 3 Aug 2021 09:47:13 -0400 From: Mark Johnston To: "Andrey V. Elsukov" Cc: =?iso-8859-1?Q?=D6zkan?= KIRIK , FreeBSD Net , freebsd-stable Subject: Re: Wired Memory Increasing about 500MBytes per day Message-ID: References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> X-Rspamd-Queue-Id: 4GfGQ94K96z4VP7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Tue, Aug 03, 2021 at 09:38:17AM +0300, Andrey V. Elsukov wrote: > 02.08.2021 08:00, Özkan KIRIK пишет: > > Hello, > > > > I'm using FreeBSD stable/12 0f97f2a1857a96563792f0d873b11a16ff9f818c (Jul > > 25) built. > > pf, ipfw and ipsec options are built with kernel. The server is used as > > firewall that squid and snort3 (daq - netmap) is running. > > > > I saw that, wired memory is increasing every day. It's about 500MBytes per > > day. I'm checking vmstat and top (sorted by res), I couldn't find what is > > consuming the wired memory. > > > > How can I find that which process or which part of kernel is consuming the > > wired memory ? > > Hi, > > We noticed the same problem, I'm not sure the exact version, but you can > check the output: > # vmstat -z | egrep "ITEM|pgcache" > > The page cache grows until lowmem is not reached. Then it automatically > cleans and begins to grow again. The pgcache zones simply provide a per-CPU cache and allocator for physical page frames. The sizes of the caches are bounded. The numbers of "used" items from the pgcache zones do not really tell you anything since those pages may be allocated for any number of purposes, including for other UMA zones. For instance, if ZFS allocates a buffer page from its ABD UMA zone, and that zone's caches are empty, UMA may allocate a new slab using uma_small_alloc() -> vm_page_alloc() -> pgcache zone. So if there is some wired page leak, the pgcache zones are probably not directly responsible. From nobody Tue Aug 3 13:59:34 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8265012DB905; Tue, 3 Aug 2021 13:59:40 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward105p.mail.yandex.net (forward105p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfGhX157Kz4Xb5; Tue, 3 Aug 2021 13:59:40 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from iva1-6891ef6bb416.qloud-c.yandex.net (iva1-6891ef6bb416.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:929a:0:640:6891:ef6b]) by forward105p.mail.yandex.net (Yandex) with ESMTP id A4A024D421D8; Tue, 3 Aug 2021 16:59:35 +0300 (MSK) Received: from iva5-057a0d1fbbd8.qloud-c.yandex.net (iva5-057a0d1fbbd8.qloud-c.yandex.net [2a02:6b8:c0c:7f1c:0:640:57a:d1f]) by iva1-6891ef6bb416.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 0gunElhaBe-xZICEbxc; Tue, 03 Aug 2021 16:59:35 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1627999175; bh=QZnMxJlWPbGQzgWWmYzAleC3/Kbcq1Mtsn9vTDWdZOY=; h=In-Reply-To:Message-ID:Subject:From:Date:References:To:Cc; b=ed/YVQ/gm0TmCbLKR6l11fH0nj12xeR7l093ayNuIAtLIme2cgcn3x5Lf3mJ7o1mk 58uIgCNFF23qqi3Es+vdEN5qBCcI0hJBa3QTbjzo+RgzBtSx+V+DHfg24tFCxGmNsx KeFZCUyGZfyacqmTaj85TIJV1ZJN1ua9ddytikwE= Received: by iva5-057a0d1fbbd8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 44Vvc2SS4r-xY3Km1aH; Tue, 03 Aug 2021 16:59:35 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) To: Mark Johnston Cc: =?UTF-8?Q?=c3=96zkan_KIRIK?= , FreeBSD Net , freebsd-stable References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> From: "Andrey V. Elsukov" Subject: Re: Wired Memory Increasing about 500MBytes per day Message-ID: <35e9249e-37f7-3ff8-23c5-a22d8b909f09@yandex.ru> Date: Tue, 3 Aug 2021 16:59:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AyljISCoKMiz299w3FED5YVd1ZGjCksFl" X-Rspamd-Queue-Id: 4GfGhX157Kz4Xb5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AyljISCoKMiz299w3FED5YVd1ZGjCksFl Content-Type: multipart/mixed; boundary="ONABrLSmCq904Ths9Cl9WpnnbYBsOT961"; protected-headers="v1" From: "Andrey V. Elsukov" To: Mark Johnston Cc: =?UTF-8?Q?=c3=96zkan_KIRIK?= , FreeBSD Net , freebsd-stable Message-ID: <35e9249e-37f7-3ff8-23c5-a22d8b909f09@yandex.ru> Subject: Re: Wired Memory Increasing about 500MBytes per day References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> In-Reply-To: --ONABrLSmCq904Ths9Cl9WpnnbYBsOT961 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 03.08.2021 16:47, Mark Johnston =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> We noticed the same problem, I'm not sure the exact version, but you c= an >> check the output: >> # vmstat -z | egrep "ITEM|pgcache" >> >> The page cache grows until lowmem is not reached. Then it automaticall= y >> cleans and begins to grow again. >=20 > The pgcache zones simply provide a per-CPU cache and allocator for > physical page frames. The sizes of the caches are bounded. The number= s > of "used" items from the pgcache zones do not really tell you anything > since those pages may be allocated for any number of purposes, includin= g > for other UMA zones. For instance, if ZFS allocates a buffer page from= > its ABD UMA zone, and that zone's caches are empty, UMA may allocate a > new slab using uma_small_alloc() -> vm_page_alloc() -> pgcache zone. >=20 > So if there is some wired page leak, the pgcache zones are probably not= > directly responsible. We don't see any leaks, but our monitoring shows that "free" memory migrates to "wired" and only these zones are grow. So, we have on the graphs linear growing of wired memory over 7 days. When free memory reaches ~4% all returns to normal, and then again linear growing for 7 days. And pgcache zones reset their number of USED items to low value. This is on the server with 256G RAM. E.g. This is when 9% of free memory left: $ vmstat -z | egrep "ITEM|pgcache" ITEM SIZE LIMIT USED FREE REQ FAILSLEEP XDOMAIN vm pgcache: 4096, 0, 5225, 139, 412976, 0, 0, 0 vm pgcache: 4096, 0,28381269, 77,190108006, 24, 0, 0 vm pgcache: 4096, 0, 166358, 11523,1684567513,3054, 0, 0 vm pgcache: 4096, 0,29548679, 576,780034183,1730, 0, 0 $ bc >>> 5225+28381269+166358+29548679 58101531 >>> 58101531*4096/1024/1024/1024 221 >>> This is when lowmem triggered: % vmstat -z | egrep "ITEM|pgcache" ITEM SIZE LIMIT USED FREE REQ FAILSLEEP XDOMAIN vm pgcache: 4096, 0, 5336, 337, 410052, 0, 0, 0 vm pgcache: 4096, 0, 3126129, 117,56689945, 24, 0, 0 vm pgcache: 4096, 0, 49771, 3910,413657845,1828, 0, 0 vm pgcache: 4096, 0, 4249924, 706,224519238, 562, 0, 0 % bc >>> 5336+3126129+49771+4249924 7431160 >>> 7431160*4096/1024/1024/1024 28 >>> Look at the graph: https://imgur.com/yhqK1p8.png --=20 WBR, Andrey V. Elsukov --ONABrLSmCq904Ths9Cl9WpnnbYBsOT961-- --AyljISCoKMiz299w3FED5YVd1ZGjCksFl Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAmEJS8YFAwAAAAAACgkQAcXqBBDIoXrY Bgf+Ix+x4QzmAJ7KGDeB7icUWNfbXHlnklFTchXMaqAbr0QngrXm2BGhLx8bPX/r8WryvgJGv+xk gk2u6hHJdvjiYoF6pd3GOj2CxL/GM6qdweHI0G1iDz/2EbJnmEbH0gEdDNawqEXUx6+IzogzES+a wLwVweVYeQGMLBxg/5SjzCl/GlSCeaKwVZRnlybhhr2gMRQh6S40bNsSxi6sl1Bbgzhb/XF4eZUG EHlcbKT0/4+m3MW2QC697I7z9Kf96R7YG0K0zjJGkgrjds0fMQsvV1TKgwtAZ9B2dvXK9qyAfLBx RW8RimbrxoUpGq4pM0ceW33iKjroUlnr246zJCm6gQ== =2Ei0 -----END PGP SIGNATURE----- --AyljISCoKMiz299w3FED5YVd1ZGjCksFl-- From nobody Tue Aug 3 14:30:38 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 52AFB12DE531; Tue, 3 Aug 2021 14:30:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfHNN1fNNz4cSl; Tue, 3 Aug 2021 14:30:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82f.google.com with SMTP id l24so14059665qtj.4; Tue, 03 Aug 2021 07:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=1M5fQDgkCEFNwsznOMTBmNzq/CgEBTJM5Dxyj0+urYY=; b=bWo+jelDhTilbtTqARRM9YkAWPliiDlZhqe9R0NcVaXxFtjQ/XVIXTzU60Onr6mS3v YYvLUpGZq13udovaFV5vO2kGm4JeEoE1M6GiHfLJoWrf34yso9Exzd7AJ7MZ2uGFB1cd zyMCjZzt5ElwSI05OFggxK8FBGfnrn3Ikd4rTCZpm/GkiOzo2tyzRid11o9mwBp1W3Zi qA48f4WExhVqyIg/4sw7hsAPj5xwBvVfJzY7tFOGSeWp0XpslfbXcDV76AFJULfMS/T1 njI4Y3T2Z5LzwLpw851d3AwB9u+tYyg1cHNfM2CAlANgEnfJ6A/XbLbcJYGCjBmK8r5l O7tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=1M5fQDgkCEFNwsznOMTBmNzq/CgEBTJM5Dxyj0+urYY=; b=SUNJgg6VMFXrV2LDC4iupPZzDXnWT0u16cGBiVfDvr3n18xKjFNMg3iKkRON+smHMr SdaPalie7RIJ2IYZf6cdIlCMmQ0o+HUjdtLv+9Ex4QVyzW/+qVkpaK3FFtFBaNuurqiV 3NWc3MKCJXswRy7AGJZZs6NGzkJDlRZb8YPXfviW4tzaTDpMEzCJhiJ5UrqeNArGnRMb cw+oco81WZ/Ppqz8HOWoaLgmX6CjCYVdARzCZPPs3w1yEzLOUSl/XDF63jd+Mhz59V8m Okx7S02JG5/PMZoKTWMAyOwCMFSXqKmSVAMn45HttuCj5Ffhi/zMk6Gy9ID3aGTZx+ZQ RxwQ== X-Gm-Message-State: AOAM533kC4SQks3q2TX631mh68b2ZunSEwYqhNtMvkWyeaPg0lXWJs9y bPjpm7bvsSbfwK2T0iRBswQ= X-Google-Smtp-Source: ABdhPJxNfl6yVgq8dxHie8bFKvV6sj8nZm65OoLg7vG6yIQetMGerppUupzyYf0YlD/pIyqpalqhdw== X-Received: by 2002:a05:622a:14ce:: with SMTP id u14mr18659018qtx.208.1628001037852; Tue, 03 Aug 2021 07:30:37 -0700 (PDT) Received: from nuc ([142.126.162.193]) by smtp.gmail.com with ESMTPSA id j2sm6105912qtn.46.2021.08.03.07.30.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Aug 2021 07:30:37 -0700 (PDT) Date: Tue, 3 Aug 2021 10:30:38 -0400 From: Mark Johnston To: "Andrey V. Elsukov" Cc: =?iso-8859-1?Q?=D6zkan?= KIRIK , FreeBSD Net , freebsd-stable Subject: Re: Wired Memory Increasing about 500MBytes per day Message-ID: References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> <35e9249e-37f7-3ff8-23c5-a22d8b909f09@yandex.ru> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <35e9249e-37f7-3ff8-23c5-a22d8b909f09@yandex.ru> X-Rspamd-Queue-Id: 4GfHNN1fNNz4cSl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Tue, Aug 03, 2021 at 04:59:34PM +0300, Andrey V. Elsukov wrote: > 03.08.2021 16:47, Mark Johnston пишет: > >> We noticed the same problem, I'm not sure the exact version, but you can > >> check the output: > >> # vmstat -z | egrep "ITEM|pgcache" > >> > >> The page cache grows until lowmem is not reached. Then it automatically > >> cleans and begins to grow again. > > > > The pgcache zones simply provide a per-CPU cache and allocator for > > physical page frames. The sizes of the caches are bounded. The numbers > > of "used" items from the pgcache zones do not really tell you anything > > since those pages may be allocated for any number of purposes, including > > for other UMA zones. For instance, if ZFS allocates a buffer page from > > its ABD UMA zone, and that zone's caches are empty, UMA may allocate a > > new slab using uma_small_alloc() -> vm_page_alloc() -> pgcache zone. > > > > So if there is some wired page leak, the pgcache zones are probably not > > directly responsible. > > We don't see any leaks, but our monitoring shows that "free" memory > migrates to "wired" and only these zones are grow. How are you measuring this? USED or USED+FREE? > So, we have on the > graphs linear growing of wired memory over 7 days. When free memory > reaches ~4% all returns to normal, and then again linear growing for 7 > days. And pgcache zones reset their number of USED items to low value. > This is on the server with 256G RAM. > > E.g. This is when 9% of free memory left: > > $ vmstat -z | egrep "ITEM|pgcache" > ITEM SIZE LIMIT USED FREE REQ > FAILSLEEP XDOMAIN > vm pgcache: 4096, 0, 5225, 139, 412976, 0, > 0, 0 > vm pgcache: 4096, 0,28381269, 77,190108006, 24, > 0, 0 > vm pgcache: 4096, 0, 166358, 11523,1684567513,3054, > 0, 0 > vm pgcache: 4096, 0,29548679, 576,780034183,1730, > 0, 0 > $ bc > >>> 5225+28381269+166358+29548679 > 58101531 > >>> 58101531*4096/1024/1024/1024 > 221 > >>> > > This is when lowmem triggered: > % vmstat -z | egrep "ITEM|pgcache" > ITEM SIZE LIMIT USED FREE REQ > FAILSLEEP XDOMAIN > vm pgcache: 4096, 0, 5336, 337, 410052, 0, > 0, 0 > vm pgcache: 4096, 0, 3126129, 117,56689945, 24, > 0, 0 > vm pgcache: 4096, 0, 49771, 3910,413657845,1828, > 0, 0 > vm pgcache: 4096, 0, 4249924, 706,224519238, 562, > 0, 0 > % bc > >>> 5336+3126129+49771+4249924 > 7431160 > >>> 7431160*4096/1024/1024/1024 > 28 > >>> > > Look at the graph: > https://imgur.com/yhqK1p8.png > > -- > WBR, Andrey V. Elsukov > From nobody Tue Aug 3 14:54:26 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B1D313408D0; Tue, 3 Aug 2021 14:54:35 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward100j.mail.yandex.net (forward100j.mail.yandex.net [5.45.198.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfHvv1Dy0z4ffD; Tue, 3 Aug 2021 14:54:35 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from myt5-c177f9f90ce4.qloud-c.yandex.net (myt5-c177f9f90ce4.qloud-c.yandex.net [IPv6:2a02:6b8:c12:1094:0:640:c177:f9f9]) by forward100j.mail.yandex.net (Yandex) with ESMTP id 0F59750E2381; Tue, 3 Aug 2021 17:54:27 +0300 (MSK) Received: from myt5-89cdf5c4a3a5.qloud-c.yandex.net (myt5-89cdf5c4a3a5.qloud-c.yandex.net [2a02:6b8:c12:289b:0:640:89cd:f5c4]) by myt5-c177f9f90ce4.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 2CRJuV28KH-sQI4ROdA; Tue, 03 Aug 2021 17:54:27 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1628002467; bh=Ft2aWw+F8gnN8WUKVU3Ri6ZicHgJyZHh1O3Kb2Sl1SQ=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=mG7dfp5YTrnp3ljRdLTKgJy/wGjNuVBsbWHeLZ/2LDnRvtQ6IC15bQRL9jf1rxCWL NK+fOACAalhYaMJqG3bpc5GhY24G+0fMlpYVajelLRyi7VNywDf47dod2/qQD2nBf6 a/+FsebGUrhNP99yt05u6bityjh19PSn2crDj4UY= Received: by myt5-89cdf5c4a3a5.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id hfo1Pr8VuO-sQ2qEbLM; Tue, 03 Aug 2021 17:54:26 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: Wired Memory Increasing about 500MBytes per day To: Mark Johnston Cc: =?UTF-8?Q?=c3=96zkan_KIRIK?= , FreeBSD Net , freebsd-stable References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> <35e9249e-37f7-3ff8-23c5-a22d8b909f09@yandex.ru> From: "Andrey V. Elsukov" Message-ID: Date: Tue, 3 Aug 2021 17:54:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1ehNXUCzQL8rKBB2xRwtAlGKhDVOh1RF6" X-Rspamd-Queue-Id: 4GfHvv1Dy0z4ffD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1ehNXUCzQL8rKBB2xRwtAlGKhDVOh1RF6 Content-Type: multipart/mixed; boundary="sh6HA8tMJQpMMQ1w5BlYJ9fOLpeUqyeOW"; protected-headers="v1" From: "Andrey V. Elsukov" To: Mark Johnston Cc: =?UTF-8?Q?=c3=96zkan_KIRIK?= , FreeBSD Net , freebsd-stable Message-ID: Subject: Re: Wired Memory Increasing about 500MBytes per day References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> <35e9249e-37f7-3ff8-23c5-a22d8b909f09@yandex.ru> In-Reply-To: --sh6HA8tMJQpMMQ1w5BlYJ9fOLpeUqyeOW Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 03.08.2021 17:30, Mark Johnston =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> So if there is some wired page leak, the pgcache zones are probably n= ot >>> directly responsible. >> >> We don't see any leaks, but our monitoring shows that "free" memory >> migrates to "wired" and only these zones are grow. >=20 > How are you measuring this? USED or USED+FREE? AFAIK, monitoring uses sysctl variables: vm.stats.vm.v_page_size vm.stats.vm.v_free_count vm.stats.vm.v_wire_count --=20 WBR, Andrey V. Elsukov --sh6HA8tMJQpMMQ1w5BlYJ9fOLpeUqyeOW-- --1ehNXUCzQL8rKBB2xRwtAlGKhDVOh1RF6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAmEJWKIFAwAAAAAACgkQAcXqBBDIoXqh EAgAiOdejLmxbMqxVPDdrNUmfqiNdRSOZqkOVlfDTIjHe+KVpRCNAZjlfIpxlnLHmT84rLibPWd6 vgzju78oAt7Lw6nLqIpyPGYT30Io3c4S0ZnLkegaODoeS6oESXa9dixn7vjAYWLg0q0e/rl0CX7B NYvkucn1OJogBn+IJ9OWJqUFFwRXt1VqEkUUL7ym3dVB4KanYlrW42J/T2Lx6bnb6BjSJggAc5re bjq2DZytCveD4ni5KwSodS/X9xJvRRTC78VvkWrtGPAZLjLAMa08I6xi9fX+//tGlzV7FZ3mFLiI v09H9bqAbXmz9CeNbl8ybLfMHSFbQJvV1UXW87gX0Q== =eGw2 -----END PGP SIGNATURE----- --1ehNXUCzQL8rKBB2xRwtAlGKhDVOh1RF6-- From nobody Tue Aug 3 15:27:51 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8432913711F0 for ; Tue, 3 Aug 2021 15:27:52 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d3::107:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfJfJ2nxjz4prV for ; Tue, 3 Aug 2021 15:27:52 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from smtpclient.apple (p200300cd873f1bfc2588dc7e5f960169.dip0.t-ipconnect.de [IPv6:2003:cd:873f:1bfc:2588:dc7e:5f96:169]) by host64.shmhost.net (Postfix) with ESMTPSA id 4GfJfH4hF4zNtK0; Tue, 3 Aug 2021 17:27:51 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: igb(4) and VLAN issue? From: Franco Fichtner In-Reply-To: Date: Tue, 3 Aug 2021 17:27:51 +0200 Cc: FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kevin Bowling X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Virus-Scanned: clamav-milter 0.103.2 at host64.shmhost.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4GfJfJ2nxjz4prV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Kevin, [RESENT TO MAILING LIST AS SUBSCRIBER] > On 2. Aug 2021, at 7:51 PM, Kevin Bowling = wrote: >=20 > I caught wind that an igb(4) commit I've done to main and that has > been in stable/12 for a few months seems to be causing a regression on > opnsense. The commit in question is > = https://cgit.freebsd.org/src/commit/?id=3Deea55de7b10808b86277d7fdbed2d05d= 3c6db1b2 >=20 > The report is at: > https://forum.opnsense.org/index.php?topic=3D23867.0 Looks like I spoke to soon earlier. This is a weird one for sure. :) So first of all this causes an ifconfig hang for VLAN/LAGG combo = creation, but later reports were coming in about ahci errors and cam timeouts. Some reported the instabilities start with using netmap, but later = others confirmed the same for high load scenarios without netmap in use. The does not appear to happen when MSIX is disabled, e.g.: # sysctl -a | grep dev.igb | grep msix dev.igb.5.iflib.disable_msix: 1 dev.igb.4.iflib.disable_msix: 1 dev.igb.3.iflib.disable_msix: 1 dev.igb.2.iflib.disable_msix: 1 dev.igb.1.iflib.disable_msix: 1 dev.igb.0.iflib.disable_msix: 1 What's also being linked to this is some form of softraid misbehaving and the general tendency for cheaper hardware with particular igb chipsets. > I haven't heard of this issue elsewhere and cannot replicate it on my > I210s running main. I've gone over the code changes line by line > several times and verified all the logic and register writes and it > all looks correct to my understanding. The only hypothesis I have at > the moment is it may be some subtle timing issue since VLAN changes > unnecessarily restart the interface on e1000 until I push in a work in > progress to stop doing that. I also have no way of reproducing this locally, but the community is probably willing to give any kernel change a try that would address the problem without havinbg to back out the commit in question. > I'd like to see the output of all the processes or at least the > process configuring the VLANs to see where it is stuck. Franco, do > you have the ability to 'control+t' there or otherwise set up a break > into a debugger? Stacktraces would be a great start but a core and a > kernel may be necessary if it isn't obvious. Let me see if I can deliver on this easily. Cheers, Franco From nobody Tue Aug 3 15:50:48 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D39A21376496 for ; Tue, 3 Aug 2021 15:51:00 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfK905Y2qz3C9J for ; Tue, 3 Aug 2021 15:51:00 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-yb1-xb2c.google.com with SMTP id w17so34495402ybl.11 for ; Tue, 03 Aug 2021 08:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W09Vx21c0KFoGG7KHoN+WGSZCyxsd/mvI8HEZelYbv0=; b=jN+s6mS3FfAcR6oDGzc1G1lEGic8WjTsBhis54575SLRpcA8Wn/UvCoLeLZsKHaFeS 71XYNH2EVJ2jrDC2t5w7G5CFRwqrAR8YYwaL9J3qPwbXpQ2OinoIkRcO8R6fYnvSKwoR V5uZxrtg94KdqbliEG9n6DLKkXcVP3UoFt1mw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W09Vx21c0KFoGG7KHoN+WGSZCyxsd/mvI8HEZelYbv0=; b=s0y3mNZ/H7+DbqAEiGxX9ZYDbqHAcFfCfcu7EpcJ8HHPviCZo5CwG6wldrWZBsaBMs T5WB9th1rrrqQEth4DBiVyuh82TXnNf5TUH44+o/xOdz64DlEL9CrTcGq7y9WvPeYavi woqj3VVRBEUAiTiFFOSi+/wlVI5xodQzuPoF/liFANvDvhB4XEy+7qZQyVkmov6ukDRs Pc7Os2DH3ouHrf3ipcQ+9Jp50rMZtgr6kDbFIpt690IXWjRxxtGMjXEyjo1Sib1GDxav RkaJb5C7GlnFipqY24W0Yla4ZLKr5r3eBxyE0XWqX7ex+lXNqs1+yp6hsemjHGRSEozj SJ0A== X-Gm-Message-State: AOAM532IR8IfK5ffa4jtDXT9ocvh2eU3UVxUsa1fHwRZ09A/6+ss4xg0 MFZrdZ8aYpuENm1jE/uURtkPIwrqvRsPnHtNkmm4CffVGQE= X-Google-Smtp-Source: ABdhPJwG3yB4KfkY6FXwg8eC1i1n9O5+ByrqUC4e6zX0akMQ/OEnxxzpzNBqjMAf0G/WDx4VUQEU3GzFp40PbmyV54c= X-Received: by 2002:a25:18a:: with SMTP id 132mr28857139ybb.123.1628005860128; Tue, 03 Aug 2021 08:51:00 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kevin Bowling Date: Tue, 3 Aug 2021 08:50:48 -0700 Message-ID: Subject: Re: igb(4) and VLAN issue? To: Franco Fichtner Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GfK905Y2qz3C9J X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Aug 3, 2021 at 8:27 AM Franco Fichtner wrote: > > Hi Kevin, > > [RESENT TO MAILING LIST AS SUBSCRIBER] > > > On 2. Aug 2021, at 7:51 PM, Kevin Bowling wrote: > > > > I caught wind that an igb(4) commit I've done to main and that has > > been in stable/12 for a few months seems to be causing a regression on > > opnsense. The commit in question is > > https://cgit.freebsd.org/src/commit/?id=eea55de7b10808b86277d7fdbed2d05d3c6db1b2 > > > > The report is at: > > https://forum.opnsense.org/index.php?topic=23867.0 > > Looks like I spoke to soon earlier. This is a weird one for sure. :) > > So first of all this causes an ifconfig hang for VLAN/LAGG combo creation, > but later reports were coming in about ahci errors and cam timeouts. > Some reported the instabilities start with using netmap, but later others > confirmed the same for high load scenarios without netmap in use. > > The does not appear to happen when MSIX is disabled, e.g.: > > # sysctl -a | grep dev.igb | grep msix > dev.igb.5.iflib.disable_msix: 1 > dev.igb.4.iflib.disable_msix: 1 > dev.igb.3.iflib.disable_msix: 1 > dev.igb.2.iflib.disable_msix: 1 > dev.igb.1.iflib.disable_msix: 1 > dev.igb.0.iflib.disable_msix: 1 > > What's also being linked to this is some form of softraid misbehaving > and the general tendency for cheaper hardware with particular igb > chipsets. Hmm, there is so much that /could/ be going on it's not easy to pinpoint anything yet. If nothing jumps out after getting more data it may be worth mitigating in your build that way and retrying once you have updated to FreeBSD 13. > > I haven't heard of this issue elsewhere and cannot replicate it on my > > I210s running main. I've gone over the code changes line by line > > several times and verified all the logic and register writes and it > > all looks correct to my understanding. The only hypothesis I have at > > the moment is it may be some subtle timing issue since VLAN changes > > unnecessarily restart the interface on e1000 until I push in a work in > > progress to stop doing that. > > I also have no way of reproducing this locally, but the community is > probably willing to give any kernel change a try that would address > the problem without havinbg to back out the commit in question. I need some more info before making any changes. A full dmesg of the older working version and a (partial?) dmesg of the broken would be another useful data point to start out with, let's see if there is something going on during MSI-X vector allocation etc. > > I'd like to see the output of all the processes or at least the > > process configuring the VLANs to see where it is stuck. Franco, do > > you have the ability to 'control+t' there or otherwise set up a break > > into a debugger? Stacktraces would be a great start but a core and a > > kernel may be necessary if it isn't obvious. > > Let me see if I can deliver on this easily. > > > Cheers, > Franco > From nobody Wed Aug 4 10:33:21 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D0F41137CB2F for ; Wed, 4 Aug 2021 10:33:22 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gfp423ynkz3Qnh for ; Wed, 4 Aug 2021 10:33:22 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 722112540B for ; Wed, 4 Aug 2021 10:33:22 +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 174AXMNs086028 for ; Wed, 4 Aug 2021 10:33:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 174AXM9s086027 for net@FreeBSD.org; Wed, 4 Aug 2021 10:33:22 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 256882] cc(4): Panic on DELL R630 with Chelsio T62100-SO-CR) lagg0 and vlans in VNET jails (VNET): ip_tryforward / ip_findroute Date: Wed, 04 Aug 2021 10:33:21 +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: 13.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: konrad.kreciwilk@korbank.pl X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: melifaro@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256882 --- Comment #8 from Konrad --- Created attachment 226942 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D226942&action= =3Dedit core.txt after a few hours system crashed, I attache core.txt I have set: net.route.algo.inet.algo=3Ddpdk_lpm4 net.route.algo.inet6.algo=3Ddpdk_lpm6 --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Thu Aug 5 03:47:03 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 745C311E4FEB for ; Thu, 5 Aug 2021 19:16:36 +0000 (UTC) (envelope-from admin@freebsd.org) Received: from mail0.justmytrade.com (vmi639138.contaboserver.net [207.244.252.233]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GgddJ2bjFz3qPC for ; Thu, 5 Aug 2021 19:16:36 +0000 (UTC) (envelope-from admin@freebsd.org) From: admin@freebsd.org To: freebsd-net@freebsd.org Subject: Secure your account freebsd-net@freebsd.org Date: 4 Aug 2021 20:47:03 -0700 Message-ID: <20210804204703.889D8B4E1E9C68E5@freebsd.org> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4GgddJ2bjFz3qPC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:40021, ipnet:207.244.240.0/20, country:US] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y
<= /TBODY>
New Feature Update
Hi freebsd-net@freebsd.org,
A new and = secure Feature was just added to your admin account. You are receiving this= email to make sure you accept or reject this feature. Use the button = below to view and accept this feature.

            &nb= sp;            =             &nb= sp;            =        PREVIEW FE= ATURE
Your mailing service may malfunction If you= ignore this feature update. If this isn't freebsd-net@freebsd.org, yo= u may ignore. 
If you hav= e any questions or need assistance, please reach out to Support.
From nobody Fri Aug 6 10:01:06 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8BC9111F9664 for ; Fri, 6 Aug 2021 10:01:07 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gh1Fv2SVPz3sqF for ; Fri, 6 Aug 2021 10:01:07 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 32B3F3C0D for ; Fri, 6 Aug 2021 10:01:07 +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 176A17Rc097851 for ; Fri, 6 Aug 2021 10:01:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 176A1760097850 for net@FreeBSD.org; Fri, 6 Aug 2021 10:01:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 257302] net/syncthing: Panic in in6_getmulti at /usr/src/sys/netinet6/in6_mcast.c:451 Date: Fri, 06 Aug 2021 10:01:06 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable13? mfc-stable12? mfc-stable11? 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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257302 --- Comment #10 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dd477a7feed177d0ad5c12bc6e2cce804d= 427ed38 commit d477a7feed177d0ad5c12bc6e2cce804d427ed38 Author: Andrey V. Elsukov AuthorDate: 2021-08-05 08:51:46 +0000 Commit: Andrey V. Elsukov CommitDate: 2021-08-06 09:57:59 +0000 Fix panic in IPv6 multicast code. Add check that ifp supports IPv6 multicasts in in6_getmulti. This fixes panic when user application tries to join into multicast group on an interface that doesn't support IPv6 multicasts, like IFT_PFLOG interfaces. PR: 257302 Reviewed by: melifaro MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D31420 sys/netinet6/in6_mcast.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From nobody Fri Aug 6 10:34:41 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0703911FBD1A for ; Fri, 6 Aug 2021 10:34:42 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gh20d6l4Rz3wHx for ; Fri, 6 Aug 2021 10:34:41 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CE466450C for ; Fri, 6 Aug 2021 10:34:41 +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 176AYfdV017883 for ; Fri, 6 Aug 2021 10:34:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 176AYf2p017882 for net@FreeBSD.org; Fri, 6 Aug 2021 10:34:41 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 218508] Tunneling and aliases using the tun device, reusing a destination address works with IPv4, but not IPv6 Date: Fri, 06 Aug 2021 10:34:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: zlei.huang@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218508 Zhenlei Huang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zlei.huang@gmail.com --- Comment #3 from Zhenlei Huang --- (In reply to Christian Sturm from comment #0) The IPv6 stack does not behave the same as IPv4 stack. In this case, you can add an IPv6 alias without the destination address to tun0. ``` ifconfig tun0 inet6 2001:db8:: 2001:db8::1 prefixlen 128 ifconfig tun0 inet6 alias 2001:db8::2 prefixlen 128 ``` The long answer: In principle, a tunnel interface can be unnumbered. For a router, you can "borrow" the global unique address on loopback interface as the local addre= ss. As for numbered tunnel interface, is the peer should be numbered? No, at le= ast in principle not required. We give another thought on the remote address of tunnel interface, if both = ends are numbered, then should either end has only exactly one IP address? No. Due to historical reason, the destination address of tunnel interface can n= ot be omitted of the FreeBSD IPv4 stack implementation. But it is not the case= of IPv6 stack. Still we can teach the FreeBSD kernel to "smartly" process IPv6 aliases with same destination address. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Aug 6 21:17:30 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EA29111FAA2D for ; Fri, 6 Aug 2021 21:17:31 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GhJGM5ysRz3Q7V for ; Fri, 6 Aug 2021 21:17:31 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B597514C56 for ; Fri, 6 Aug 2021 21:17:31 +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 176LHVI2054727 for ; Fri, 6 Aug 2021 21:17:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 176LHV14054726 for net@FreeBSD.org; Fri, 6 Aug 2021 21:17:31 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 257642] e1000 doesn't check for bad Rx UDP checksum Date: Fri, 06 Aug 2021 21:17:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords 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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257642 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org Keywords| |IntelNetworking --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Aug 7 04:36:58 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 265D0174A7D4 for ; Sat, 7 Aug 2021 04:36:59 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GhV1R0MCfz4cBB for ; Sat, 7 Aug 2021 04:36:59 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EA3171AC59 for ; Sat, 7 Aug 2021 04:36:58 +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 1774awWC089763 for ; Sat, 7 Aug 2021 04:36:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1774awCC089762 for net@FreeBSD.org; Sat, 7 Aug 2021 04:36:58 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 257642] e1000 doesn't check for bad Rx UDP checksum Date: Sat, 07 Aug 2021 04:36:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kbowling@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257642 Kevin Bowling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #1 from Kevin Bowling --- (In reply to Nick Reilly from comment #0) Nick, can you give this a try https://reviews.freebsd.org/D31449? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Aug 7 12:50:22 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 05D6213768F2 for ; Sat, 7 Aug 2021 12:50:23 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ghhyk6ZHbz3NwD for ; Sat, 7 Aug 2021 12:50:22 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C3C03215C5 for ; Sat, 7 Aug 2021 12:50:22 +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 177CoMIM042679 for ; Sat, 7 Aug 2021 12:50:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 177CoM0g042678 for net@FreeBSD.org; Sat, 7 Aug 2021 12:50:22 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 256882] cc(4): Panic on DELL R630 with Chelsio T62100-SO-CR) lagg0 and vlans in VNET jails (VNET): ip_tryforward / ip_findroute Date: Sat, 07 Aug 2021 12:50:22 +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: 13.0-STABLE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: melifaro@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: melifaro@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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256882 --- Comment #9 from Alexander V. Chernikov --- Okay, so looks like the returned nexthop has NULL ifp, which really shouldn= 't happen. Is there any chance you can privately share the kernel & core? --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Sun Aug 8 21:00:38 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 30CC1137DE91 for ; Sun, 8 Aug 2021 21:00:39 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GjWny603rz3m6T for ; Sun, 8 Aug 2021 21:00:38 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9047B1B4DA for ; Sun, 8 Aug 2021 21:00:38 +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 178L0c4G047241 for ; Sun, 8 Aug 2021 21:00:38 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 178L0cDg047240 for net@FreeBSD.org; Sun, 8 Aug 2021 21:00:38 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202108082100.178L0cDg047240@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 8 Aug 2021 21:00:38 +0000 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16284564387.6D4cAC7fC.46296" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16284564387.6D4cAC7fC.46296 Date: Sun, 8 Aug 2021 21:00:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 221146 | [ixgbe] Problem with second laggport New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 213410 | [carp] service netif restart causes hang only whe Open | 7556 | ppp: sl_compress_init() will fail if called anyth Open | 166724 | if_re(4): watchdog timeout Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194453 | dummynet(4): pipe config bw parameter limited to Open | 200319 | Bridge+CARP crashes/freezes Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 207261 | netmap: Doesn't do TX sync with kqueue Open | 217978 | dhclient: Support supersede statement for option Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo Open | 225438 | panic in6_unlink_ifa() due to race Open | 227720 | Kernel panic in ppp server Open | 230807 | if_alc(4): Driver not working for Killer Networki Open | 236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open | 236983 | bnxt(4) VLAN not operational unless explicit "ifc Open | 237072 | netgraph(4): performance issue [on HardenedBSD]? Open | 237840 | Removed dummynet dependency on ipfw Open | 238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open | 238707 | Lock order reversal: rtentry vs "nd6 list" Open | 240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open | 241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open | 241162 | Panic in closefp() triggered by nginx (uwsgi with Open | 241191 | route flush panic with RADIX_MPATH Open | 243463 | ix0: Watchdog timeout Open | 244066 | divert: Add sysctls for divert socket send and re Open | 118111 | rc: network.subr Add MAC address based interface 28 problems total for which you should take action. --16284564387.6D4cAC7fC.46296--