Hi guys,
On Sun, 9/6/15, Artem Belevich <art...@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@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)
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
