Date: Wed, 11 Jan 2017 03:06:19 -0800 From: Matthew Macy <mmacy@nextbsd.org> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: <freebsd-current@freebsd.org> Subject: Re: CURRENT: em0 NIC freezes under heavy I/O on net Message-ID: <1598d35075b.10642de0a7607.7672646196802078650@nextbsd.org> In-Reply-To: <20170111091643.1d45ab39@freyja.zeit4.iv.bundesimmobilien.de> References: <20170111091643.1d45ab39@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
=20
=20
It looks like I have the wrong msix bar value for your NIC. Wil=
l fix in the next day or so.-M---- On Wed, 11 Jan 2017 00:27:30 -0800 O. H=
artmann<ohartmann@walstatt.org> wrote ----Running recent CURRENT (FreeBSD 1=
2.0-CURRENT #5 r311919: Wed Jan 11 08:24:28 CET 2017 amd64), the system fre=
ezes when doing a rsync over automounted (autofs) NFSv4 filesystem, mounted=
from another CURRENT server (same revision, but with BCM NICs). The host =
in question is a Fujitsu Celsius M740 equipted with an Intel NIC: [...] em=
0: <Intel(R) PRO/1000 Network Connection> port 0xf020-0xf03f mem 0xfb300000=
-0xfb31ffff,0xfb339000-0xfb339fff at device 25.0 numa-domain 0 on pci1 em0:=
attach_pre capping queues at 1 em0: using 1024 tx descriptors and 1024 rx =
descriptors em0: msix_init qsets capped at 1 em0: Unable to map MSIX table =
em0: Using an MSI interrupt em0: allocated for 1 tx_queues em0: allocated =
for 1 rx_queues em0: netmap queues/slots: TX 1/1024, RX 1/1024 [...] The p=
ciconf output reveals: em0@pci0:0:25:0: class=3D0x020000 card=3D0x1=
1ed1734 chip=3D0x153a8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corpo=
ration' device =3D 'Ethernet Connection I217-LM' class =3D=
network subclass =3D ethernet bar [10] =3D type Memory, range =
32, base 0xfb300000, size 131072, enabled bar [14] =3D type Memory, r=
ange 32, base 0xfb339000, size 4096, enabled bar [18] =3D type I/O Po=
rt, range 32, base 0xf020, size 32, enabled cap 01[c8] =3D powerspec 2 =
supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 b=
it enabled with 1 message cap 13[e0] =3D PCI Advanced Features: FLR TP =
I have a customized kernel. The NIC has revealed itself all the time as an=
"emX" device (never as igbX). The kernel contains device netmap (if releve=
vant). The phenomenon: Syncing a poudriere repository between to remote h=
osts, I use rsync on a NGSv4 exported filesystem, mounted via AUTOFS. So fa=
r, this work two days ago perfectly. Since yesterday, syncing brings down t=
he network connection - the connection is simply dead. Terminating the rsyn=
c, bringing em0 down and up again doesn't help much, for short moments, the=
connection is established, but dies within seconds. Restarting via "servic=
e netif restart" all network services have the same effect: after the desas=
ter, it is impossible for me to bring back the NIC/connection to normal, I =
have to reboot. The same happens when having heavy network load, but it tak=
es a time and even rsync isn't "deadly" within the same timeframe - it take=
s sometimes a couple of seconds, another takes only one or two seconds to m=
ake the connection die. I checked with dd'ing a large file over that conn=
ection, it takes several seconds then to make the connection freezing (so, =
someone could reproduce iy not ncessarily using rsync). Kind regards, oh =
_______________________________________________ freebsd-current@freebsd.org=
mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To=
unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"=20
=20
=20
=20
=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1598d35075b.10642de0a7607.7672646196802078650>