Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 May 2013 20:38:06 -0700
From:      Jeremy Chadwick <jdc@koitsu.org>
To:        Glen Barber <gjb@FreeBSD.org>
Cc:        YongHyeon PYUN <pyunyh@gmail.com>, FreeBSD Release Engineering Team <re@freebsd.org>, freebsd-stable@freebsd.org
Subject:   Re: Apparent fxp regression in FreeBSD 8.4-RC3
Message-ID:  <20130524033806.GA39720@icarus.home.lan>
In-Reply-To: <20130524031303.GC28865@glenbarber.us>
References:  <20130508174721.GD1651@glenbarber.us> <alpine.BSF.2.00.1305112240040.1240@familysquires.net> <CAG=rPVf0W2U4OwRUzVB5TgVVX%2BAD44VL1fBCtLMiqtDSL%2Bg4Vg@mail.gmail.com> <alpine.BSF.2.00.1305161103370.1222@familysquires.net> <alpine.BSF.2.00.1305232013110.14717@familysquires.net> <20130524010943.GA37252@icarus.home.lan> <20130524012117.GE1672@glenbarber.us> <20130524030351.GA39091@icarus.home.lan> <20130524031303.GC28865@glenbarber.us>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <Intel 82551 ..." and continue all
> > 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 |



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130524033806.GA39720>