Apparent fxp regression in FreeBSD 8.4-RC3

[Hiroki Sato]

YongHyeon PYUN <pyunyh at gmail.com> wrote
  in <20130524054720.GA1496 at michelle.cdnetworks.com>:

py> On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
py> > On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
py> > > On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
py> > > > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
py> > > > > If someone wants me to test DHCP via fxp(4) on the above system (I can
py> > > > > do so with both NICs), just let me know; it should only take me half an
py> > > > > hour or so.
py> > > > >
py> > > > > I'll politely wait for someone to say "please do so" else won't bother.
py> > > > >
py> > > >
py> > > > For the sake of completeness...
py> > > >
py> > > > "Please do so."  :)
py> > >
py> > > Issue reproduced 100% reliably, even within sysinstall.
py> > >
py> > > {snip}
py> >
py> > Forgot to add:
py> >
py> > This issue ONLY happens when using DHCP.
py> >
py> > Statically assigning the IP address works fine; fxp0 goes down once,
py> > up once, then stays up indefinitely.
py>
py> I asked Mike to try backing out dhclient(8) change(r247336) but it
py> seems he missed that. Jeremy, could you try that?
py>
py> I guess dhclient(8) does not like flow-control negotiation of
py> fxp(4) after link establishment.

 Okay, I could reproduce this issue on my box.  After invocation of
 dhclient(8), a link is up and then state_reboot() drops the link
 establishment.  Removing the changes around RTM_IFINFO in r247336
 makes it work with no problem.

 A workaround is specifying the following line in rc.conf:

 ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex"

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130524/94117710/attachment.sig>