On (10/11/07 18:06), Artem Kachitchkine wrote: > > so it may be that the mi_ref is getting scribbled on somewhere else. > > It's worth investigating, but might not be related to this particular > issue. Detaching a driver instance is not the only way to change MTU. > bge_m_setprop(DLD_PROP_DEFMTU) only returns EBUSY when > bgep->bge_mac_state == BGE_MAC_STARTED. If you stop the mac then call > mi_setprop, it should reinitialize with the the value. I think we should > work this angle first.
This is along the lines of what Erik Nordmark suggested: of reiniting the chip (at the potential penalty of dropping some packets). Can you actually stop the mac of a driver easily when it is running? This would be ideal to do.. however, the problem is that, in practice, we can't always do this technique (stop/start) for every property considered because of the unfortunate fact that many drivers (including the network stack, sometimes) may need a major rewrite to achieve this.. in the case of default_mtu, we are able to reset the ire state information via mac_maxsdu_update() but this may not always be easy to do (e.g., for some parameters like interrupt coalescing, where Crossbow is doing the rewrite). Getting back to the question on hand: Why doesn't the mac_prop_load() invocation in mac_start() pull in the new property definitions on the replumb? --Sowmini
