From owner-freebsd-stable@FreeBSD.ORG Sun Feb 23 17:51:22 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 377EC83A for ; Sun, 23 Feb 2014 17:51:22 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B644E153B for ; Sun, 23 Feb 2014 17:51:21 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id k14so3998752wgh.35 for ; Sun, 23 Feb 2014 09:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-type; bh=3MmjgEylWSlbu632b/ALgL/dLnVWvnWPuWxz8DgBBno=; b=pPtKfCeLBlMd1TnOSj3jZ0hnij56gdvlP4/h4GYGgNGDrdjOeuzH6EEwfmDNATyvxN G48n9TECadsNykKN9BCoc9ZidoHQsb7pIfqOONxnGObZvaJ6CmSbbugc2KH9t6B3GXiG kxQDEwLFvCY087/ByTa6VgWpJ1Ie9a8bNnxQbh1ryqAwxFKsdlK1Q2lhjuyCKq0IIpf2 sj6cKbX2gQr6KYiceHGIE0N83nod1f32uQQYTI3m22zejg/68NvF1MD5lvLLDydsZexe LHDYeOX2vGh1guhRtMRm5PkqOKO74KSbL5Xlhp7STRvFWlCVR7Vnf8utRhUkjNpCfP29 GlVg== X-Received: by 10.180.37.162 with SMTP id z2mr10946357wij.51.1393177880025; Sun, 23 Feb 2014 09:51:20 -0800 (PST) Received: from dragon.dg ([197.87.228.138]) by mx.google.com with ESMTPSA id v6sm16360180wif.0.2014.02.23.09.51.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Feb 2014 09:51:18 -0800 (PST) Sender: David Naylor From: David Naylor To: pyunyh@gmail.com Subject: Re: [SOLVED] MPCP Opcode Pause and unresponsive computer Date: Sun, 23 Feb 2014 19:51:10 +0300 Message-ID: <7109858.LYNIHJIJOi@dragon.dg> Organization: FreeBSD User-Agent: KMail/4.10.5 (FreeBSD/9.2-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <20140217022329.GA3675@michelle.cdnetworks.com> References: <1403963.5sDsKbxfoF@dragon.dg> <20140217022329.GA3675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2670731.5FePk0oNts"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 17:51:22 -0000 --nextPart2670731.5FePk0oNts Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi, The issue was hardware error (corrupt memory module). Once removed all symptoms disappeared. Please see below for specific follow up messages. Regards On Monday, 17 February 2014 11:23:29 Yonghyeon PYUN wrote: > On Thu, Feb 13, 2014 at 10:01:56PM +0300, David Naylor wrote: > > Hi, > > > > I recently installed FreeBSD 10.0-RELEASE on an headless Intense-PC. I am > > experiencing two network related issues with the computer. > > > > First issue > > ----------- > > When compiling lang/ruby19 the network freezes. The build was done > > directly from the command line using ssh. After a while ssh reports > > "Write failed: Broken pipe". I attached the monitor and no messages were > > displayed on the output (and the machine was still running). > > > > The Intense-PC does not respond to pings at this point either. Of note, I > > was capable of transferring multiple GB of data and successfully compiled > > other ports but compiling lang/ruby19 messes up everything. > > > > Second issue > > ------------ > > After a period of uptime (after the freeze from building lang/ruby19) the > > entire network stops working, nothing is capable of connecting or > > communicating on the network. When I do a tcpdump (from a different, > > affected computer) I find the following: > > > > 20:57:58.254626 MPCP, Opcode Pause, length 46 > > > > These messages get repeated a few times a second. The moment I disconnect > > the Intense-PC from the network functionality is restored (and is clearly > > illustrated by the tcpdump). > > > > Information > > ----------- > > # uname -a > > FreeBSD dragonbsd 10.0-RELEASE FreeBSD 10.0-RELEASE #0 > > d44ce30(releng/10.0): Sun Feb 9 20:11:55 SAST 2014 > > root@dragon.dg:/tmp/home/freebsd/10.0/src/sys/MODULAR amd64 > > > > # ifconfig > > lo0: flags=8049 metric 0 mtu 16384 > > > > options=600003 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > > inet 127.0.0.1 netmask 0xff000000 > > nd6 options=21 > > > > em0: flags=8843 metric 0 mtu 1500 > > > > options=4219b > O4,WOL_MAGIC,VLAN_HWTSO> ether XX:XX:XX:XX:XX:XX > > inet 192.168.0.160 netmask 0xffffff00 broadcast 192.168.0.255 > > nd6 options=29 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > re0: flags=8843 metric 0 mtu 1500 > > > > options=8209b > L_MAGIC,LINKSTATE> ether XX:XX:XX:XX:XX:XX > > nd6 options=29 > > media: Ethernet autoselect (none) > > status: no carrier > > > > Any assistance to resolve this issue will be greatly appreciated. > > It's not normal to see pause frames with tcpdump. If my memory > serves me right, MAC control frames which include pause frames > should not be passed to host. Which network driver do you see > above pause frames? Some drivers like fxp(4) allow passing pause > frames to host but I think that's a bug in driver. I didn't change > that behavior of the driver just because it used to enable that > feature in the past. This is what a web search also indicated. In this case the machine receiving pause frames has: # dmesg | grep 'em0\|re0' em0: port 0xf040-0xf05f mem 0xf7300000-0xf731ffff,0xf7328000-0xf7328fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt DragonSA@dragon:/tmp> dmesg | grep re0 re0: port 0xd000-0xd0ff mem 0xf7220000-0xf72200ff irq 16 at device 0.0 on pci3 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 miibus0: on re0 # ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=9 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: re0 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 55 member: em0 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 2000000 Could it be bridge0 is causing the pause frames to be visible? > I'm not sure what's happening there but receiving pause frames will > inhibit sending frames until the pause time expires such that you'll > not get any response from the host. Probably you have to know > which host is sending these lots of pause frames. Once you > identify the guilty host, you have to narrow down what condition > makes it send pause frames. It turns out that the guilty host had a faulty memory module (that didn't show up in memtest86+ when run with another module in). I've removed the offending memory module and no repeat of the incidences. --nextPart2670731.5FePk0oNts Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEABECAGYFAlMKNRFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NDBCNDdDNTRBQTNFQkFCMjNCNThBQzUx QTY4NTgwRkY2OTE2QjIACgkQUaaFgP9pFrI0vQCeKqI0k/fCkTdo+w991TYZOUBW pQ0AnjaKypfbJuF13/yLHnfYsFyHMEVN =b7fL -----END PGP SIGNATURE----- --nextPart2670731.5FePk0oNts--