From owner-freebsd-net@freebsd.org Sun Jan 20 08:15:41 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FF1C14AA64E for ; Sun, 20 Jan 2019 08:15:41 +0000 (UTC) (envelope-from d8zNeCFG@aon.at) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB0B8BC2B for ; Sun, 20 Jan 2019 08:15:40 +0000 (UTC) (envelope-from d8zNeCFG@aon.at) Received: by mailman.ysv.freebsd.org (Postfix) id 4ACC914AA64D; Sun, 20 Jan 2019 08:15:40 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2590B14AA64C for ; Sun, 20 Jan 2019 08:15:40 +0000 (UTC) (envelope-from d8zNeCFG@aon.at) Received: from smtpout-fallback.aon.at (smtpout-fallback.aon.at [195.3.96.120]) (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 759B68BC2A for ; Sun, 20 Jan 2019 08:15:39 +0000 (UTC) (envelope-from d8zNeCFG@aon.at) Received: (qmail 24545 invoked from network); 20 Jan 2019 08:15:37 -0000 Received: from unknown (HELO smtpout.aon.at) ([172.18.1.216]) (envelope-sender ) by fallback44.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 20 Jan 2019 08:15:37 -0000 X-A1Mail-Track-Id: 1547972137:24544:fallback44:172.18.1.216:1 Received: (qmail 24446 invoked from network); 20 Jan 2019 08:15:29 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on WARSBL503.highway.telekom.at X-Spam-Level: Received: from 188-23-243-129.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([188.23.243.129]) (envelope-sender ) by smarthub86.res.a1.net (qmail-ldap-1.03) with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 Jan 2019 08:15:28 -0000 X-A1Mail-Track-Id: 1547972127:24404:smarthub86:188.23.243.129:1 Received: from mizar.xyzzy (mizar.xyzzy [192.168.1.19]) by gandalf.xyzzy (8.15.2/8.15.2) with ESMTP id x0K8FR2h004590; Sun, 20 Jan 2019 09:15:27 +0100 (CET) (envelope-from d8zNeCFG@aon.at) Subject: Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior To: Bruce Evans References: <20190119204156.D929@besplex.bde.org> <3e407ee7-54e3-a6ac-5535-d11aceca9558@grosbein.net> <20190120061258.X3312@besplex.bde.org> <16ce1832-13da-d7bb-cce2-6682e058b5a6@aon.at> <20190120145627.X1077@besplex.bde.org> <20190120163533.K1342@besplex.bde.org> Cc: Eugene Grosbein , net@freebsd.org From: Martin Birgmeier Message-ID: Date: Sun, 20 Jan 2019 09:15:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190120163533.K1342@besplex.bde.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 759B68BC2A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2019 08:15:41 -0000 I am not using resume at all... just normal startup/shutdown. -- Martin On 20.01.19 07:19, Bruce Evans wrote: > On Sun, 20 Jan 2019, Bruce Evans wrote: > >> [iflib_media_change() is missing iflib_stop(), like iflib_resume() was] >> >> I don't know what the media was after the broken resume.  Its reported >> result can't be trusted anyway.  To recover from the broken resume, it >> usually worked to repeat down/up a few times.  This is consistent with >> bug -- eventually, previous down/up's change the state to close enough >> to stopped.  But using the interface in any way (including pinging it >> to see if it is still broken) makes it not so close to being stopped. > > Further debugging after restoring the bug in resume: > - I use mainly zzz to suspend > - the bug usually doesn't break the interface if I copy zzz from nfs to >   non-nfs and use the copy.  This explains why almost no one except me >   noticed the bug -- zzz is usually not on nfs, and other nfs activity >   is usually lighter than mine too.  (Suspend apparently doesn't do > enough >   stopping or syncing generally.  It should fsync() all files ...) > - the bug usually does break the interface if zzz is on nfs > - when the bug breaks the interface: >   - the media is reported as unchanged >   - after DUPs starting with a delay of many seconds and reducing by the >     ping interval of 1 second for each until the delay is less than 1 >     second, the ping latency stabilizes at quite different values after >     each suspend/resume.  These values tend to be higher than for media >     change (several hundred ms instead of 76 ms). >   - my ifconfig excutable is one of several under /sbin which is not > on nfs, >     but my ifconfig is actually a shell script in $HOME/bin; the script >     selects the correct version of ifconfig for the current kernel; it is >     on nfs, and uses utilties on nfs.  I sometimes forget this, and then >     running plain ifconfig to attempt to recover takes too long, and if I >     wait then the nfs activity for finding ifconfig not on nfs tends to >     propagate the broken interface (like zzz not on nfs breaks it). >     Manually selecting the correct version of ifconfig under /sbin and > using >     it tends to work right (like zzz not on nfs). >   - even an mtu change is enough to recover.  This is not surprising, > since >     it does slightly more than down/up as an implementation detail.  This >     shows that the reported media value is at least used by the reinit > for >     the mtu change. >   - pinging the interface didn't make it active enough for the > recovery to >     not usually work. > > Bruce