I have a continuous reader on a bulk endpoint (which is fine). On one pc
every so often the EvtUsbTargetPipeReadersFailed (status =
STATUS_UNSUCCESSFUL, usbd_status = 0) callback will be triggered when the pc
resumes from sleep. So I return TRUE from EvtUsbTargetPipeReadersFailed (let
framework reset the pipe). The problem is the failure callback gets called
again and the loop goes around and around.
With a USB analyzer I can see that the hub is sending “ClearFeature
(Endpoint 1 IN, Halt)” (which is acknowledged) over and over to the device
but is never sending any IN tokens asking for bulk data.
The question is why is the continuous reader erroring out without actually
asking the device for data? Is this a problem with WDF, the lower usb driver
stack, the hub, my driver?
I would say that the problem is with your hardware, not WDF or the core USB stack. i don’t think it is your driver either since this appears to be an on the wire problem.
I have a continuous reader on a bulk endpoint (which is fine). On one pc
every so often the EvtUsbTargetPipeReadersFailed (status =
STATUS_UNSUCCESSFUL, usbd_status = 0) callback will be triggered when
the pc resumes from sleep. So I return TRUE from
EvtUsbTargetPipeReadersFailed (let framework reset the pipe). The
problem is the failure callback gets called again and the loop goes
around and around.
With a USB analyzer I can see that the hub is sending “ClearFeature
(Endpoint 1 IN, Halt)” (which is acknowledged) over and over to the
device but is never sending any IN tokens asking for bulk data.
The question is why is the continuous reader erroring out without
actually asking the device for data? Is this a problem with WDF, the
lower usb driver stack, the hub, my driver?
The bulk transfer urbs are failing (USBD_STATUS_STALL_PID), the rest then
cancelled (Irp Cancel -> USBD_STATUS_CANCELED) and then some control
transfers are sent (hard to decipher these in ETW but I guess they are the
“ClearFeature (Endpoint 1 IN, Halt)” I see in the bus analyzer).
The bus analyzer shows that there is no STALL response from the device and
in fact the host never starts a bulk transfer at all.
This leaves me with a few possible conclusions:
a) the hub is lying to usb core
b) a bug in the usb core stack
c) I am reading the traces incorrectly
Any further thoughts?
Thanks guys,
Dan
On Fri, Jan 28, 2011 at 8:21 AM, Philip Ries wrote:
> It might help to take a USB ETW trace to see what (if anything) is failing > in the USB core stack. > > > http://blogs.msdn.com/b/usbcoreblog/archive/2009/12/04/etw-in-the-windows-7-usb-core-stack.aspx > > > On 1/26/2011 5:08 PM, Daniel Newton wrote: > >> I have a continuous reader on a bulk endpoint (which is fine). On one pc >> every so often the EvtUsbTargetPipeReadersFailed (status = >> STATUS_UNSUCCESSFUL, usbd_status = 0) callback will be triggered when >> the pc resumes from sleep. So I return TRUE from >> EvtUsbTargetPipeReadersFailed (let framework reset the pipe). The >> problem is the failure callback gets called again and the loop goes >> around and around. >> >> With a USB analyzer I can see that the hub is sending “ClearFeature >> (Endpoint 1 IN, Halt)” (which is acknowledged) over and over to the >> device but is never sending any IN tokens asking for bulk data. >> >> The question is why is the continuous reader erroring out without >> actually asking the device for data? Is this a problem with WDF, the >> lower usb driver stack, the hub, my driver? >> >> Cheers, >> Daniel >> >> > — > NTDEV is sponsored by OSR > > 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 >