WdfPdoRequestEject

The documentation for WdfPdoRequestEject seems to be a little light. I’m sending this for my network card and in some cases the eject is not completing. In the “Orderly Removal” help page I can see that there are some circumstances where my request may not be honoured, but none of those are true in this case.

The scenario I’m testing is a torture test for add/remove where 5 virtual network cards are removed in quick succession by the xen backend. The first thing that happens is that the “backend” (xen) component flags that it is changing to the "closing’ state, and my driver receives this event and issues the WdfPdoRequestEject. The first one or two remove successfully, but then for the next card nothing progresses after the call to WdfPdoRequest

The full Eject procedure is supposed to work as follows:

. Backend state changes
. Frontend (my driver) notices it, and knows that it hasn’t initiated the removal and so issues a WdfPdoRequestEject
. One of the following things happen:

  1. The device shuts down and is removed
  2. EvtDevicePnpStateChange is called where Type == StateNotificationEnterState && CurrentState == WdfDeviceStatePnpQueryRemovePending && NewState == WdfDevStatePnpQueryCanceled, and a surprise removal is initiated

Is there another possible thing that can happen and I’m losing the request?

Thanks

James

Does !wdflogdump give any clues? Since eject is a state changing operation, it could be blocked by another stack holding the pnp state lock. In the end, is eject what you want? why not just surprise remove the NICs?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Wednesday, December 4, 2013 2:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfPdoRequestEject

The documentation for WdfPdoRequestEject seems to be a little light. I’m sending this for my network card and in some cases the eject is not completing. In the “Orderly Removal” help page I can see that there are some circumstances where my request may not be honoured, but none of those are true in this case.

The scenario I’m testing is a torture test for add/remove where 5 virtual network cards are removed in quick succession by the xen backend. The first thing that happens is that the “backend” (xen) component flags that it is changing to the "closing’ state, and my driver receives this event and issues the WdfPdoRequestEject. The first one or two remove successfully, but then for the next card nothing progresses after the call to WdfPdoRequest

The full Eject procedure is supposed to work as follows:

. Backend state changes
. Frontend (my driver) notices it, and knows that it hasn’t initiated the removal and so issues a WdfPdoRequestEject . One of the following things happen:

  1. The device shuts down and is removed
  2. EvtDevicePnpStateChange is called where Type == StateNotificationEnterState && CurrentState == WdfDeviceStatePnpQueryRemovePending && NewState == WdfDevStatePnpQueryCanceled, and a surprise removal is initiated

Is there another possible thing that can happen and I’m losing the request?

Thanks

James


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

>

Does !wdflogdump give any clues? Since eject is a state changing operation,
it could be blocked by another stack holding the pnp state lock. In the end, is
eject what you want? why not just surprise remove the NICs?

The bus driver that requests the eject doesn’t actually know what the child device is - it also enumerates storage devices, where an Eject allows Windows the opportunity to clean up first.

James

Your frontend should translate xen unplug to surprise removal rather than
eject. The unplug is non-negotiable, so presenting the unplug as an eject
request on the frontend is really problematic.

Mark Roddy

On Wed, Dec 4, 2013 at 5:05 AM, James Harper
wrote:

> The documentation for WdfPdoRequestEject seems to be a little light. I’m
> sending this for my network card and in some cases the eject is not
> completing. In the “Orderly Removal” help page I can see that there are
> some circumstances where my request may not be honoured, but none of those
> are true in this case.
>
> The scenario I’m testing is a torture test for add/remove where 5 virtual
> network cards are removed in quick succession by the xen backend. The first
> thing that happens is that the “backend” (xen) component flags that it is
> changing to the "closing’ state, and my driver receives this event and
> issues the WdfPdoRequestEject. The first one or two remove successfully,
> but then for the next card nothing progresses after the call to
> WdfPdoRequest
>
> The full Eject procedure is supposed to work as follows:
>
> . Backend state changes
> . Frontend (my driver) notices it, and knows that it hasn’t initiated the
> removal and so issues a WdfPdoRequestEject
> . One of the following things happen:
> 1. The device shuts down and is removed
> 2. EvtDevicePnpStateChange is called where Type ==
> StateNotificationEnterState && CurrentState ==
> WdfDeviceStatePnpQueryRemovePending && NewState ==
> WdfDevStatePnpQueryCanceled, and a surprise removal is initiated
>
> Is there another possible thing that can happen and I’m losing the request?
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

>

Your frontend should translate xen unplug to surprise removal rather than
eject. The unplug is non-negotiable, so presenting the unplug as an eject
request on the frontend is really problematic.

As per my followup email, the bus driver also enumerates storport drivers, and so requesting eject gives windows the opportunity to flush caches cleanly. Only if the eject is denied do I go ahead with the surprise removal. The backend waits a considerable amount of time before it declares the unplug as failed.

Think of it like a physical media eject button that cannot be blocked indefinitely, but can be blocked for a short time to give the OS time to flush buffers.

Even better would be if I could force a dismount of all volumes (like chkdsk does for non-system disks), but I think that may require interaction from usermode.

James

Incidentally, this is how parts of Hyper-V work as well. The guest OS gets to play along with the protocol, and if it does, it sees good results. If it fails to continue to play along nicely, the devices get removed more dramatically. (This mostly applies to SR-IOV.)

  • Jake

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Wednesday, December 4, 2013 3:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfPdoRequestEject

Your frontend should translate xen unplug to surprise removal rather than
eject. The unplug is non-negotiable, so presenting the unplug as an eject
request on the frontend is really problematic.

As per my followup email, the bus driver also enumerates storport drivers, and so requesting eject gives windows the opportunity to flush caches cleanly. Only if the eject is denied do I go ahead with the surprise removal. The backend waits a considerable amount of time before it declares the unplug as failed.

Think of it like a physical media eject button that cannot be blocked indefinitely, but can be blocked for a short time to give the OS time to flush buffers.

Even better would be if I could force a dismount of all volumes (like chkdsk does for non-system disks), but I think that may require interaction from usermode.

James


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer