From owner-freebsd-current@freebsd.org Wed Jan 11 11:06:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 615CACABAB2 for ; Wed, 11 Jan 2017 11:06:24 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4496E14B8 for ; Wed, 11 Jan 2017 11:06:23 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1484132779875682.9384231169385; Wed, 11 Jan 2017 03:06:19 -0800 (PST) Date: Wed, 11 Jan 2017 03:06:19 -0800 From: Matthew Macy To: "O. Hartmann" Cc: 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> Subject: Re: CURRENT: em0 NIC freezes under heavy I/O on net MIME-Version: 1.0 User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Zoho-Virus-Status: 2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:06:24 -0000 =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 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: 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