I'm using a codeless kext on a HID device to manually pipe data from my
app to/from interrupt endpoints. Previously, I was using the HID APIs
to communicate with the device. I have some customers using this
non-HID beta version of the app that are having problems that did not
exist when they were using the HID version (when they revert to the
older version of the app that uses the HDI APIs everything is fine). As
always happens in cases like this, I'm not having any problems on my
systems in-house. :-).
I suspect the problem is my code is not handling stalled pipes
correctly, whereas the HID driver automatically handled them. I've read
through the docs online and looked at the sample code, but I haven't
been able to figure out exactly how to detect pipe stalls. If there is
a tech note or some other documentation I missed that might help, then
let me know.
Anyhow, I believe I've tracked down the problem to my WritePipeAsync()
completion callback never being called. This happens infrequently (a
couple of times a day over hundreds of write pipe calls) but
consistently for these users. Currently, I'm calling CFRunLoopRun()
after my WritePipeAsync() call, and have the corresponding
CFRunLoopStop() inside the completion routine. Because the completion
routine is never called in the failure case, the run loop never exits
and my app waits forever for the data to be sent.
Question #1: Is this likely a stalled pipe? To fix this, I was planning
on using CFRunLoopInMode() and if it times-out I was going to call
AbortPipe() followed by ClearPipeStallBothEnds(), then I'd try the
WritePipeAsync() again. Sound reasonable? I was surprised my completion
routine was not being called in this case -- I had thought it would
always be called in a somewhat timely manner even if there was a
failure. (note that the WritePipeAsync() call is always returning
kIOReturnSuccess, which I used as a conditional before I called
CFRunLoopRun())
Question #2: Is the non-call of the write completion function the only
way to detect an async write pipe stall, or is it possible the
completion callback will be called but with a non-kIOReturnSuccess
ioResult value? If so what value would hint at a possible pipe stall
(kIOReturnNotResponding?)?
Question #3: What about pipe stalls on async reads (ReadPipeAsync())? I
always have one outstanding ReadPipeAsync() pending and I prime the
next one inside the read's completion routine. How do I detect a pipe
stall on read (ioResult == kIOReturnNotResponding?)?
Thanks in advance for the help.
Regards,
Matt Bendiksen
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
