Re: Apparent fxp regression in FreeBSD 8.4-RC3
On Fri, May 24, 2013 at 04:36:46PM +0900, Hiroki Sato wrote: Hiroki Sato h...@freebsd.org wrote in 20130524.162926.395058052118975996@allbsd.org: hr YongHyeon PYUN pyu...@gmail.com wrote hr in 20130524054720.ga1...@michelle.cdnetworks.com: hr hr A workaround is specifying the following line in rc.conf: hr hr ifconfig_fxp0=DHCP media 100baseTX mediaopt full-duplex Hmm, I guess this can happen on other NICs when the link negotiation causes a link-state flap. Is it true? Probably not. AFAIK fxp(4) is the only controller that requires two full resets to support flow control. Multicast programming for fxp(4) also requires full controller reset so trying to renew its existing lease for fxp(4) looks wrong to me. -- Hiroki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Apparent fxp regression in FreeBSD 8.4-RC3
On Fri, May 24, 2013 at 03:32:29AM -0400, Charles Sprickman wrote:
On May 24, 2013, at 1:47 AM, YongHyeon PYUN wrote:
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 have a system up and running and showing the problem (that was
non-trival, just for the record - one machine blew the PSU after
POST, the other refused to boot off an IDE drive, and then required
two CD-ROM drives before I found a functional one, and it took a
good half-hour to find what's apparently the last piece of writable
CD-R media I own).
I am not awesome with svn, but I'll see if I can manually undo
r247336 and give it a spin.
Download
http://svnweb.freebsd.org/base/stable/8/sbin/dhclient/dhclient.c?r1=231278r2=247336view=patch
And apply the patch with -R.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Apparent fxp regression in FreeBSD 8.4-RC3
On Sun, May 26, 2013 at 08:38:41PM +0900, YongHyeon PYUN wrote: On Fri, May 24, 2013 at 04:36:46PM +0900, Hiroki Sato wrote: Hiroki Sato h...@freebsd.org wrote in 20130524.162926.395058052118975996@allbsd.org: hr YongHyeon PYUN pyu...@gmail.com wrote hr in 20130524054720.ga1...@michelle.cdnetworks.com: hr hr A workaround is specifying the following line in rc.conf: hr hr ifconfig_fxp0=DHCP media 100baseTX mediaopt full-duplex Hmm, I guess this can happen on other NICs when the link negotiation causes a link-state flap. Is it true? Probably not. AFAIK fxp(4) is the only controller that requires two full resets to support flow control. Multicast programming for fxp(4) also requires full controller reset so trying to renew its existing lease for fxp(4) looks wrong to me. After reading code again, I think the dhclient change may affect all controllers that don't have protection against multiple initialization of upper stack. if_init() of driver is called whenever an IP address is assigned to an interface. The stack could be changed to call if_init() only when IFF_DRV_RUNNING flag is not set but that would break old drivers which may require full controller reset for multicast filter reprogramming. I also guess there may be several drivers that do not implement reinitialization protection in arm/mips. It seems fxp(4)'s simple protection against unnecessary controller initialization does not work well due to the limitation of controller. We may be able to improve fxp(4) case but other old/buggy drivers should be fixed too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
