Apparent fxp regression in FreeBSD 8.4-RC3

[YongHyeon PYUN]

On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
> On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
> > On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
> > > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
> > > > 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.
> > > > 
> > > 
> > > For the sake of completeness...
> > > 
> > > "Please do so."  :)
> > 
> > Issue reproduced 100% reliably, even within sysinstall.
> >
> > {snip} 
> 
> Forgot to add:
> 
> This issue ONLY happens when using DHCP.
> 
> Statically assigning the IP address works fine; fxp0 goes down once,
> up once, then stays up indefinitely.

I asked Mike to try backing out dhclient(8) change(r247336) but it
seems he missed that. Jeremy, could you try that?

I guess dhclient(8) does not like flow-control negotiation of
fxp(4) after link establishment.

> 
> I also tested network I/O in the statically-assigned scenario.  Pinging
> the box from another machine on the LAN:
> 
> $ ping 192.168.1.192
> PING 192.168.1.192 (192.168.1.192): 56 data bytes
> 64 bytes from 192.168.1.192: icmp_seq=0 ttl=64 time=0.180 ms
> 64 bytes from 192.168.1.192: icmp_seq=1 ttl=64 time=0.138 ms
> 64 bytes from 192.168.1.192: icmp_seq=2 ttl=64 time=0.214 ms
> 64 bytes from 192.168.1.192: icmp_seq=3 ttl=64 time=0.165 ms
> 64 bytes from 192.168.1.192: icmp_seq=4 ttl=64 time=0.114 ms
> ^C
> --- 192.168.1.192 ping statistics ---
> 5 packets transmitted, 5 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.114/0.162/0.214/0.034 ms