Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

WdfPdoRequestEject

James_HarperJames_Harper Member Posts: 1,615
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

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,428
    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
    d
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > 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
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    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
    >
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space