From owner-freebsd-stable@FreeBSD.ORG Fri May 24 03:38:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F39A0EDA for ; Fri, 24 May 2013 03:38:07 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by mx1.freebsd.org (Postfix) with ESMTP id BE6E13D8 for ; Fri, 24 May 2013 03:38:07 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta10.emeryville.ca.mail.comcast.net with comcast id ffYi1l0050cQ2SLAAfe70U; Fri, 24 May 2013 03:38:07 +0000 Received: from jdc.koitsu.org ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id ffe61l00K1t3BNj8Wfe6aB; Fri, 24 May 2013 03:38:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7F80373A33; Thu, 23 May 2013 20:38:06 -0700 (PDT) Date: Thu, 23 May 2013 20:38:06 -0700 From: Jeremy Chadwick To: Glen Barber Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 Message-ID: <20130524033806.GA39720@icarus.home.lan> References: <20130508174721.GD1651@glenbarber.us> <20130524010943.GA37252@icarus.home.lan> <20130524012117.GE1672@glenbarber.us> <20130524030351.GA39091@icarus.home.lan> <20130524031303.GC28865@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130524031303.GC28865@glenbarber.us> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369366687; bh=+ZVjgXzrC8HKP6XYjHpIVp1ks117JofWSnitgqvUV+Q=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=jacwPhGFvpNBBpjKORAD6TGvDewOga9lvwD4ZumgmRqpGz3L42LIz6xP45kSomGVQ V4omP1pm9bQVmE8Ae/thRjj+UKPA6Wv1bC1+BEDocqQw9zMO6/AJ7LsLIh5/Nlp+U/ kLrDu9y/nwQuy+Zgkj3gF2wcVnNUFpjDVmJRXtRIf6RcGmngexBMvV9TI5Y5D1s7Ly YXMKUit3JxMsrrENsUMPcama4+cBwAsSoVuV+H9JiH8TcSV5/abcVWUbnHLuj5l6JU 5aWbxs9EtaUz4kVPALlJaDFliQyOzc7IBYTEkNTjTgCFALHc5JYX4yeXR3eX7fxyup ySxHrPktlITKw== Cc: YongHyeon PYUN , FreeBSD Release Engineering Team , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 03:38:08 -0000 On Thu, May 23, 2013 at 11:13:03PM -0400, Glen Barber wrote: > On Thu, May 23, 2013 at 08:03:51PM -0700, Jeremy Chadwick wrote: > > On Thu, May 23, 2013 at 09:21:17PM -0400, Glen Barber wrote: > > > On Thu, May 23, 2013 at 06:09:43PM -0700, Jeremy Chadwick wrote: > > > > On Thu, May 23, 2013 at 08:18:33PM -0400, Michael L. Squires wrote: > > > > > I've just tested 8.4-RC3 using a different Supermicro 1U box with a fresh > > > > > installation of 8.4-RC3. I had problems with the installation, wouldn't > > > > > boot until I used a Windows 98 FDISK to write a master boot record > > > > > (no idea why; this system uses an Adaptec SATA 1.5 6-channel PCI-X > > > > > board with two > > > > > drives in RAID 1). > > > > > > > > > > Using the em0 interface there are no problems with DHCP; when I > > > > > switch to the fxp0 interface the interface starts going up/down in > > > > > the same manner as reported. > > > > > > > > > > The problem appears associated with "world", not with the kernel (running > > > > > the 8.4 kernel with the 8.3 world does not have this problem). > > > > > > > > > > This motherboard is an X5DPL-iGM with 2 Xeon 2.8GHz CPUs and 4 GB of RAM. > > > > > The other unit (an earlier board) has a Serverworks chipset with a single > > > > > Xeon CPU but also with a 100Mbit Intel Pro100 Ethernet port and a 1000Mbit > > > > > Intel Pro1000 Ethernet port. > > > > > > > > > > This unit isn't doing anything useful, so testing isn't a problem. > > > > > > > > Mike, Yong-Hyeon asked you a very important question which you didn't > > > > answer: > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073458.html > > > > > > > > If you assign a static IP address, does fxp0 behave properly? > > > > > > > > I'm also re-adding Yong-Hyeon to the CC list here. > > > > > > > > > > At this point, I am not convinced we have a problem with what will turn > > > out to be 8.4-RELEASE. > > > > > > There have been several attempts to ensure the upgraded version is > > > actually 8.4-RC3 (and again, 'uname -a' is not provided in this > > > email...). > > > > > > I find it very hard to believe that we have exactly one fxp(4) user > > > upgrading to 8.4-*. > > > > > > I'd really like to make sure that this is not an issue that will affect > > > an uncountable number of users, but truthfully, at this point have to > > > consider it a local configuration problem. > > > > I have numerous Supermicro 1U boxes sitting in my garage from closing > > down my hosting organisation back in August 2012. I am certain one or > > two of them have Intel NICs that use fxp(4) -- the problem is that I > > don't know what exact NIC and PHY model they use. > > > > >From what I can tell, there are at least two systems Mike has which > > experience this anomaly. One of those systems' dmesg: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073440.html > > > > The relevant lines start at "fxp0: > the way down to "pci0:0:8:0: bad VPD cksum, remain 14". I'm not sure if > > the bad VPD checksum message is relevant to the fxp0 device or not. > > > > The 2nd system is mentioned above/in this post: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073530.html > > > > But there's no verbose dmesg etc. for the 2nd system so I don't know if > > it has the same NIC/PHY. > > > > My understanding from the start of this thread is that "both" machines > are actually the same machine, but with different combinations of > userland/kernel. (No, not arguing anything - only one person can answer > if my understanding is correct or not.) > > The model of NIC and PHY matters greatly; most users don't seem to > > realise how important this is, they think in terms of "Intel vs. > > Broadcom vs. Realtek". > > > > Output from "pciconf -lvbc", specifically the lines relevant to the fxp0 > > device, from both systems, would be highly beneficial. > > > > In the meantime, I'll head down to my garage to see if I can find those > > fxp(4) boxes and see if they're 85551s (I sure hope I haven't pulled the > > CPUs/RAM from them). If I find a match, I can try to reproduce this. > > > > It has been quite costly now (time) waiting for information on this > particular issue at this point, unfortunately. I made a typo above -- I meant to say "82551" not "85551". Anyways... Hearing you on FM. :-) Inventory of old systems of mine didn't take long. I had 3 systems; one used dual Broadcom NICs (so that's out), the other used dual Intel 82541EI NICs (which is driven by em(4) so that's out). The remaining system: - Supermicro 5010E -- Have CPU + RAM -- NIC: Intel DA82562EM -- NIC: Intel GD82559 -- Supermicro site states (1) Intel 82559 and (1) Intel VE CNR -- http://www.supermicro.com/products/system/1U/5010/SYS-5010E.cfm -- fxp(4) driver claims to support 82562EM and 82559 -- http://svnweb.freebsd.org/base/stable/8/sys/dev/fxp/if_fxp.c?revision=242909&view=markup However neither of these are 82551. Summary: I do have a system I can use to test fxp(4), however it does not use the Intel 82551 (in case this turns out to be a chip-specific driver bug). If someone wants me to test DHCP via fxp(4) on the above system (I can do so with both NICs), just let me know; it should only take me half an hour or so. I'll politely wait for someone to say "please do so" else won't bother. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |