Date: Wed, 11 Jan 2017 03:08:57 -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: <1598d376de0.eca911bf7358.1828247947352727343@nextbsd.org> In-Reply-To: <1598d35075b.10642de0a7607.7672646196802078650@nextbsd.org> References: <20170111091643.1d45ab39@freyja.zeit4.iv.bundesimmobilien.de> <1598d35075b.10642de0a7607.7672646196802078650@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=20
=20
Sorry, I meant to send that to the other thread.=C2=A0Was this =
after the iflib driver commit? If so it's odd that we haven't seen anything=
like this and I'll try to get a fix in ASAP.---- On Wed, 11 Jan 2017 03:06=
:19 -0800 Me<mmacy@nextbsd.org> wrote ----It looks like I have the wrong m=
six bar value for your NIC. Will fix in the next day or so.-M---- On Wed, 1=
1 Jan 2017 00:27:30 -0800 O. Hartmann<ohartmann@walstatt.org> wrote ----Ru=
nning recent CURRENT (FreeBSD 12.0-CURRENT #5 r311919: Wed Jan 11 08:24:28 =
CET 2017 amd64), the system freezes when doing a rsync over automounted (au=
tofs) NFSv4 filesystem, mounted from another CURRENT server (same revision,=
but with BCM NICs). The host in question is a Fujitsu Celsius M740 equipt=
ed with an Intel NIC: [...] em0: <Intel(R) PRO/1000 Network Connection> po=
rt 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 1=
024 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 pciconf output reveals: em0@pci0:0:25:0: =
class=3D0x020000 card=3D0x11ed1734 chip=3D0x153a8086 rev=3D0x05 hdr=3D0=
x00 vendor =3D 'Intel Corporation' device =3D 'Ethernet Connect=
ion 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, range 32, base 0xfb339000, size 4096, enabled=
bar [18] =3D type I/O Port, 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 bit 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 relevevant). The phenomenon: Syncing a poudri=
ere repository between to remote hosts, I use rsync on a NGSv4 exported fil=
esystem, mounted via AUTOFS. So far, this work two days ago perfectly. Sinc=
e yesterday, syncing brings down the network connection - the connection is=
simply dead. Terminating the rsync, bringing em0 down and up again doesn't=
help much, for short moments, the connection is established, but dies with=
in seconds. Restarting via "service netif restart" all network services hav=
e the same effect: after the desaster, it is impossible for me to bring bac=
k the NIC/connection to normal, I have to reboot. The same happens when hav=
ing heavy network load, but it takes a time and even rsync isn't "deadly" w=
ithin the same timeframe - it takes sometimes a couple of seconds, another =
takes only one or two seconds to make the connection die. I checked with =
dd'ing a large file over that connection, 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/m=
ailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-c=
urrent-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?1598d376de0.eca911bf7358.1828247947352727343>