[Bug 235031] [em] em0: poor NFS performance, strange behavior

[Bruce Evans]

On Thu, 15 Aug 2019 a bug that doesn't want replies at freebsd.org wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031
>
> --- Comment #36 from Martin Birgmeier <d8zNeCFG at aon.at> ---
> I just notice that the console and syslog have about 20 messages of
>
> em: frame error: ignored
> em: frame error: ignored
> em: frame error: ignored
> em: frame error: ignored
> em: frame error: ignored
>
> Uptime is 2 1/2 hours.

You seem to be using my old patch which is not in -current:

Index: em_txrx.c
XX ===================================================================
XX --- em_txrx.c	(revision 348771)
XX +++ em_txrx.c	(working copy)
XX @@ -629,9 +629,20 @@
XX 
XX  		/* Make sure bad packets are discarded */
XX  		if (errors & E1000_RXD_ERR_FRAME_ERR_MASK) {
XX +#if 0
XX  			adapter->dropped_pkts++;
XX -			/* XXX fixup if common */
XX  			return (EBADMSG);
XX +#else
XX +			/*
XX +			 * XXX the above error handling is worse than none.
XX +			 * First it it drops 'i' packets before the current
XX +			 * one and doesn't count them.  Then it returns an
XX +			 * error.  iflib can't really handle this error.
XX +			 * It just resets, and this usually drops many more
XX +			 * packets (without counting them) and much time.
XX +			 */
XX +			printf("lem: frame error: ignored\n");
XX +#endif
XX  		}
XX 
XX  		ri->iri_frags[i].irf_flid = 0;
XX @@ -692,8 +703,12 @@
XX 
XX  		/* Make sure bad packets are discarded */
XX  		if (staterr & E1000_RXDEXT_ERR_FRAME_ERR_MASK) {
XX +#if 0
XX  			adapter->dropped_pkts++;
XX  			return EBADMSG;
XX +#else
XX +			printf("em: frame error: ignored\n");
XX +#endif
XX  		}
XX 
XX  		ri->iri_frags[i].irf_flid = 0;

Without this patch, no message is printed and the device takes a long
time to recover (when I wrote the patch, recovery was from something
like a watchdog timeout after many seconds).  With the patch, the recovery
is good enough for nfs over udp to not lose any data or time out, but I
don't trust this so I print the message.

Pre-iflib versions of [l]em handled this correctly by dropping a single
packet, which was easy to do.  Unpatched iflib makes a mess by returning
with subsequent packets unprocessed.  It apparently just stops receiving
until kicked by a watchdog.

I don't know what causes this error.  Maybe just a bad cable or switch.
I don't see it for I218V with the same cable and switch.

Bruce