ok, so in my case, since I had problem on a surprise removal, I must have
some callback on D0exit to address the pending or remaining request that I
would have in my queue. But, since my device never goes off or support
selective suspend, it seems ok to have power managed queues and let the
framework do its thing.
"Doron Holan [MSFT]" wrote:
> power managed queues are used to control if you get presented IO only when
> the device has power. this means in a non power managed queue you could get
> a io request when you are off, and if in that state you try to touch the hw,
> it will fail.
>
> d
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Bhentai" <> wrote in message
> news:25425413-9598-4497-AA47-...
> > Ok, but my device doesn't support selective suspend and I haven't
> > implemented
> > anything about power policy for my device in my driver. The only thing I
> > have
> > specified is the surprise removal when setting the pnp capabilities in my
> > OnDeviceAdd call. Is there anything that could be influenced by changing
> > my
> > queues power setting? I have two of them, one for IOCTL and the other is a
> > manual one.
> >
> > Regards
> >
> > "Doron Holan [MSFT]" wrote:
> >
> >> blindly turning the queue into a power managed queue has other side
> >> effects.
> >> for instance it can effect selective suspend (if you enabled it)
> >>
> >> d
> >>
> >> --
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> "Bhentai" <> wrote in message
> >> news:62CBF13C-4CF0-41B3-AB18-...
> >> > You were right, it was something that had to do with my non power
> >> > managed
> >> > queue. So I changed my queue to power manage and now the
> >> > DeviceIoControl
> >> > call
> >> > isn't blocked and returns ERROR_OPERATION_ABORTED, which is alright.
> >> >
> >> > Thank a lot.
> >> >
> >> > "Doron Holan [MSFT]" wrote:
> >> >
> >> >> my guess is that you have not completed some IWdfIoRequest in your
> >> >> UMDF
> >> >> driver. it is probably parked in a non power managed io queue
> >> >>
> >> >> d
> >> >>
> >> >> --
> >> >>
> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> rights.
> >> >>
> >> >>
> >> >> "Bhentai" <> wrote in message
> >> >> news:8CD9CA27-0511-486A-8E78-...
> >> >> > No, the DeviceIoControl is not Overlapped and the Createfile for the
> >> >> > handle
> >> >> > doesn't have the FILE_FLAG_OVERLAPPED specified.
> >> >> >
> >> >> > "Doron Holan [MSFT]" wrote:
> >> >> >
> >> >> >> if you still have an open handle, the driver is still loaded b/c of
> >> >> >> that
> >> >> >> outstanding handle. is the call to DeviceIoControl on an
> >> >> >> OVERLAPPED
> >> >> >> handle
> >> >> >> ?
> >> >> >>
> >> >> >> --
> >> >> >>
> >> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> >> rights.
> >> >> >>
> >> >> >>
> >> >> >> "Bhentai" <> wrote in message
> >> >> >> news:A248EF36-8B1E-4BE5-96B3-...
> >> >> >> > Hi,
> >> >> >> > I'm faced with something weird when calling DeviceIoControl in a
> >> >> >> > user
> >> >> >> > application on my UMDF driver based on the osrusbfx2 driver. What
> >> >> >> > happens
> >> >> >> > is
> >> >> >> > that if I unplug my usb device and a user application calls
> >> >> >> > DeviceIoControl
> >> >> >> > with a previously valid handle to my driver, the call hangs
> >> >> >> > there.
> >> >> >> > My
> >> >> >> > driver
> >> >> >> > is totally unmounted so normally, the pnp manager would know that
> >> >> >> > the
> >> >> >> > handle
> >> >> >> > used by DeviceIoControl is not longer valid and the call would
> >> >> >> > return a
> >> >> >> > failure but instead it hangs. Is it something that is not done
> >> >> >> > right
> >> >> >> > in
> >> >> >> > my
> >> >> >> > driver that causes this? Should I manage in the user app and
> >> >> >> > verify
> >> >> >> > that
> >> >> >> > the
> >> >> >> > handle is still valid?
> >> >> >> >
> >> >> >> > Regards
> >> >> >>
> >> >> >> .
> >> >> >>
> >> >> .
> >> >>
> >> .
> >>
> .
>
|
Similar Threads
Linear Mode
