Problem with receiving packets right after remote-interface is up

[M. V.]

Hi guys,

On Sun, 9/6/15, Artem Belevich <artemb at gmail.com> wrote:
> While you can indeed set speed/duplex manually, you will also need
> to make sure both have have proper clock master/slave
>  selection  which is normally done via autonegotiation. On
> Freebsd some interfaces support "mediaopt master"
> option ..

Thanks again for your answer. I continuted tests on this yesterday, and I found root of the problem. As I told you, I checked ifconfig and there was no support for changing master/slave option. Yesterday I tested to see if this master/slave option affects my tests. I found out every time interface of remote system gets down and up, If our interface gets slave, everything is ok, but anytime our interface gets master, we don't receive sent packets in the first second after getting up.
So I changed driver code to manualy force interface to get slave (by changing values of 82574's related registers) and my problem was solved completely (even with auto-neg. enabled)
It seems getting master needs extra work and extra time to setup in hardware level ('cause I didn't find any code in driver to do things differently when we are master). 

So my question is, 
- Is there anything I can do to make my scenario work in master-mode too? (interestingly cisco router doesn't have this problem in both master/slave modes)
- Is it OK to force interface to always gets slave like this? (I found no problem in my tests. I even checked what happens if 2 connected ports both were forced to be slave. In that situation one of the ports gets master even though we manually set it to slave, so connection is OK)

Thank you.

> On Saturday, September 5, 2015, M. V. via freebsd-net
> < freebsd-net at freebsd.org> wrote: 
>> Our product is being tested with Spirent TestCenter,
>> and we're facing an unusual problem with the tests.
>> We use NICs with intel 82574 and 82576 on FreeBSD 9.2
>> with latest em and igb drivers (we also tested this on 
>> FreeBSD-10.1) It seems what Spirent TestCenter does to 
>> start any individual test is, it disables its own interface, 
>> and at the beginning of the new test, it suddenly "up"s its 
>> interface and sends test packet right after that.
>> This is where we have problem, and we don't receive this
>> first packets most of the time (result is vary, in 100 tests, 
>> we lose about 60~70% of this "first" packets on each test,
>> so we FAIL most of tests because apparently we need
>> about 0.5~1 seconds after setup and renegotiation
>> before we can receive packets)