From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 21:07:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF2CD10656AA for ; Mon, 16 Aug 2010 21:07:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 68EA38FC0A for ; Mon, 16 Aug 2010 21:07:12 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7GL77V5094081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Aug 2010 17:07:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7GL76pA080191; Mon, 16 Aug 2010 17:07:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008162107.o7GL76pA080191@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Aug 2010 17:07:11 -0400 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20100702193654.GD10862@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:07:12 -0000 Hi Jack, FYI, I am still seeing this same problem on RELENG_8 (code as of today). Unfortunately I cant try Pyun's patch since the underlying code has changed since then. em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c pci3: on pcib3 em4: port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci3 em4: Using MSI interrupt em4: [FILTER] em4: Ethernet address: 00:15:17:ed:3e:c4 ---Mike At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > > Hi Jack, > > Just a followup to the email below. I now saw what appears > > to be the same problem on RELENG_8, but on a different nic and with > > VLANs. So not sure if this is a general em problem, a problem > > specific to some em NICs, or a TSO problem in general. The issue > > seemed to be triggered when I added a new vlan based on > > > > em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > > chip=0x109a8086 rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > > pci14: on pcib5 > > em3: port 0x6000-0x601f > > mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > > em3: Using MSI interrupt > > em3: [FILTER] > > em3: Ethernet address: 00:30:48:9f:eb:81 > > > > em3: flags=8943 > > metric 0 mtu 1500 > > options=2098 > > ether 00:30:48:9f:eb:81 > > inet 10.255.255.254 netmask 0xfffffffc broadcast 10.255.255.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > I had to disable tso, rxcsum and txsum in order to see the devices on > > the other side of the two vlans trunked off em3. Unfortunately, the > > other sides were switches 100km and 500km away so I didnt have any > > tcpdump capabilities to diagnose the issue. I had already created > > one vlan off this NIC and all was fine. A few weeks later, I added a > > new one and I could no longer telnet into the remote switches from > > the local machine.... But, I could telnet into the switches from > > machines not on the problem box. Hence, it would appear to be a > > general TSO issue no ? I disabled tso on the nic (I didnt disable > > net.inet.tcp.tso as I forgot about that).. Still nothing. I could > > always ping the remote devices, but no tcp services. I then > > remembered this issue from before, so I tried disabling tso on the > > NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > > then telnet into the remote devices. > > > > This newly observed issue was from a buildworld on Mon Jun 14 > > 11:29:12 EDT 2010. > > > > I will try and recreate the issue locally again to see if I can > > trigger the problem on demand. Any thoughts on what it might be ? > > Perhaps an issue specific to certain em nics ? > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 >I'm not sure whether you're seeing the same issue though. >I didn't have chance to try latest em(4) on stable/7. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike