fxp hack in sys/net/if.c?

[Kip Macy]

The reasoning behind moving the delay in to shared code is not very compelling.

-Kip

On Wed, Jun 10, 2009 at 2:17 PM, Kip Macy<kip.macy at gmail.com> wrote:
> From "cvs blame":
>
> Add workaround for fxp issue at interface initialization with IPv6.
>
>  Some LAN card chip for fxp is known to cause problem at
>  interface initialization with IPv6 enabled. It happens at
>  some delicate timing.
>  And also, just adding some DELAY before IPv6 address
>  autoconfiguration is known to avoid the problem.
>
>  Complete fix is changing the driver not to use interrupt at
>  multicast filter initialization, but trying such change in
>  this stage will be dangerous.
>
>  So I add some DELAY() only inside #ifdef INET6 part,
>  as temporal workaround only for 4.0.
>
> Approbed by: jkh
>
> Noticed by: Mattias Pantzare <pantzer at ludd.luth.se>
>
> Obtained from: openbsd-tech mailing list
>
>
>
> On Wed, Jun 10, 2009 at 2:03 PM, Bjoern A.
> Zeeb<bzeeb-lists at lists.zabbadoz.net> wrote:
>> Hi,
>>
>> could anyone having a clue why that is there look at it and either
>> remove it or remove it and properly handle it elsewhere?
>>
>> I have continuesly noticed it for a while so I think the "temporary"
>> as given in the comment rather means "forgotten"?
>>
>> sys/net/if.c:           DELAY(100);/* XXX: temporary workaround for fxp
>> issue*/
>>
>> /bz
>>
>> --
>> Bjoern A. Zeeb                      The greatest risk is not taking one.
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
>
>
> --
> When bad men combine, the good must associate; else they will fall one
> by one, an unpitied sacrifice in a contemptible struggle.
>
>    Edmund Burke
>



-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

    Edmund Burke