On 13/02/14 12:44, Andrew Lunn wrote:
it is invoked every time the interface is brought up. So if you disconnect and then reconnect the cable (e.g. to connect the NIC to a faster switch) this function is invoked again and the bandwidth is updated.
Are we sure that auto-negotiation has finished? It can take a few seconds to complete after the interface is brought up. It would not be good to have batman use 10Mbps/Half Duplex on my gigabit links...
So it can take up to "few" seconds? I did not expect such a delay!
It varies a lot between devices. I have a NAS box which i use for kernel hacking. I TFTP boot the kernel, using u-boot configuration variables. I found that for a cold boot it works great, but a warm boot seems to be faster and the TFTP GET command is sent while the phy is still auto-negotiating, and it gets lost. This then triggers a bug in u-boot, it never re-transmits the GET command, and then whole TFTP boot times out eventually.
So i'm just cautious about making assumptions here, especially assumptions which might be mostly true, but in some odd edge case turn out to be false.
However this function if invoked when the NETDEV_UP event is issued by the underlying system. I expect the event to be thrown when the interface is ready to be used, not when the auto-negotiatin is still going on. I will double check.
I had a quick look at the code. It seems like NETDEV_UP is issued directly after the device is opened. There does not seem to be any waiting around for auto-neg.
Hi Andrew,
This morning I've been trying to dig into the tg3 Ethernet driver to get an idea of what happens before the NETDEV_UP event is fired.
The network stack invokes the ndo_open() callback implemented by the driver and, as far as I can see, this function does not return until having set speed and half/full_duplex state. Thus it looks like that when NETDEV_UP is fired the speed and the full_duplex attribute have already a meaningful value.
Of course this may vary depending on the driver, so this may not be the case everywhere.
I think that we can keep this approach for now and then perform some tests on a couple of platforms before merging the code. This way we should be "sure" about this particular behaviour.
I think that your NAS might also be a good testing platform, assuming that the owner is willing to insmod batman-adv on that machine :-)
Cheers,