Re: nve(4) patch - please test!

:    In addition to moving the nv_setmulti() and nv_ifmedia_upd() calls
:    to a slightly different place in DFly (after pfnInit and before pfnStart),
:    I also noticed that pfnStop() seems to take a flags argument which the
:    header files define AFFECT_RECEIVER and AFFECT_TRANSMITTER for,
:    but both our codes have been calling pfnStop() with a flags argument of
:    0.
:
:    I don't know if adding the flags has any effect but it doesn't seem to
:    make things worse.  If pfnStop() isn't actually stopping the hardware
:    due to incorrect flags then all sorts of bad things can happen.
:
:						-Matt

    Bah.  On the second part the pfnStop() function seems to expect some
    other type of argument,. 'ucIsPowerDown':

    typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_STOP)   (PNV_VOID pvContext, NV_UINT8 ucIsPowerDown);

    So it is unclear what those AFFECT_* flags refer to.  It looks like
    Nvidia has made changes to the ABI and not cleaned up after themselves.

    However, for some reason I have not gotten another complete lockup
    (requiring replugging the physical power cord to fix) since making
    both changes, so I've decided to leave it in for the moment even though
    the flags are not likely related to the ucIsPowerDown argument.

    I also noticed an ABI call which resets the PHY called
    pfnResetPhyInitState().  It might be worth calling that if
    the adapter gets stuck.  If I can get my adapter to stick again I'll
    try it.

						-Matt