none
NDIS miniport reset overlap with checkforhang RRS feed

  • Question

  • Hi, I need to clarify a couple of aspects in the behavior of miniport reset with correlation to checkforhang behavior:

    - Is there any formal time limit for the execution of miniport reset callback?

    - What will happen if reset doesn't complete when the next check-for-hang should be triggered? I.e., will the check-for-hang be called in this case? And if so, what is the expected behavior from it's callback? Should it return true/false or just block till the completion of reset? If returning true, will the OS schedule another miniport reset regardless of the running one?

    Thanks

    Friday, October 28, 2016 6:48 AM

Answers

  • There's currently no formal time limit for a miniport reset callback.  NDIS reserves the right to add a formal limit in future versions.

    Despite the lack of a formal time limit, we still expect that reset completes promptly enough that the user doesn't notice an extended interruption. E.g., 10seconds is too long -- the end-user will notice this and have gotten quite frustrated by then.

    NDIS will continue to periodically invoke your miniport's CFH, even if a reset is in progress.  Do not block your CFH if a reset is in progress.  You can return TRUE or FALSE -- it doesn't matter too much, since NDIS coalesces reset requests.  If your CFG returns TRUE and the miniport is currently resetting, then NDIS will drop the redundant reset request and won't queue up a second reset operation.  (Subject to the natural race here.)  If you have a choice, prefer to return FALSE, since that avoids the natural race.

    Finally - please note that CFH and MiniportReset are somewhat discouraged.  They're still supported in most cases, but they're not allowed for Connected Standby NICs.  Future versions of NDIS will likely remove CFH in more scenarios.  We encourage you to think about how to detect hangs without needing to poll the hardware every few seconds, as polling is bad for battery-powered systems.


    Sunday, November 6, 2016 6:04 PM

All replies

  • Why do you ask? Have you seen any weird behavior, like CFH called during the reset?

    There's concurrency, edge cases can occur in special environment, like in a virtual machine. When you receive reset request, set a flag to avoid nested reset calls, this is cheap and simple. As for the time limit, IIRC you have at least one second (again, unless a VM plays tricks with the time).

    Hope someone can offer a better answer...

    Regards,

     --pa

    Sunday, October 30, 2016 2:26 PM
  • Why do you ask? Have you seen any weird behavior, like CFH called during the reset?

    There's concurrency, edge cases can occur in special environment, like in a virtual machine. When you receive reset request, set a flag to avoid nested reset calls, this is cheap and simple. As for the time limit, IIRC you have at least one second (again, unless a VM plays tricks with the time).

    Hope someone can offer a better answer...

    Regards,

     --pa

    I vaguely recall seeing CFH during reset a few years ago, but don't remember the exact details...

    I'm mostly interested in what is the expected miniport behavior in such case and whether having such overlap in the first place already screws something in the NDIS SM? I mean, unlike the standard miniport SM transitions, there is no complete documentation of the dependencies between reset and check-for-hang calls.

    Sunday, October 30, 2016 5:18 PM
  • There's currently no formal time limit for a miniport reset callback.  NDIS reserves the right to add a formal limit in future versions.

    Despite the lack of a formal time limit, we still expect that reset completes promptly enough that the user doesn't notice an extended interruption. E.g., 10seconds is too long -- the end-user will notice this and have gotten quite frustrated by then.

    NDIS will continue to periodically invoke your miniport's CFH, even if a reset is in progress.  Do not block your CFH if a reset is in progress.  You can return TRUE or FALSE -- it doesn't matter too much, since NDIS coalesces reset requests.  If your CFG returns TRUE and the miniport is currently resetting, then NDIS will drop the redundant reset request and won't queue up a second reset operation.  (Subject to the natural race here.)  If you have a choice, prefer to return FALSE, since that avoids the natural race.

    Finally - please note that CFH and MiniportReset are somewhat discouraged.  They're still supported in most cases, but they're not allowed for Connected Standby NICs.  Future versions of NDIS will likely remove CFH in more scenarios.  We encourage you to think about how to detect hangs without needing to poll the hardware every few seconds, as polling is bad for battery-powered systems.


    Sunday, November 6, 2016 6:04 PM