Stuart, thanks for the feedback.
I looked at the issue with a fresh pair of eyes this morning and
indeed, you are partially correct, its not a power issue. ... but
neither is it a protocol problem.
I'm seeing a very reproducible case with ReadPipeAsyncTo() where,
issued multiple concurrent calls to this creates issues under OSX
10.10, but not 10.9
struct buf_s {
unsigned char *ptr;
int len; /* total size of allocation in ptr */
int readlen; /* bytes returned from readpipeasyncto() */
/// other buffer stats
};
I submit the buf->ptr and buf->len to ReadPipeAsyncTo() and pass the
buffer struct as the context. A fairly standard thing to do. My USB
interface is in the run loop so I get callbacks and timeouts as
expected.... Except that I've previously 'submitted' 8-16 of these
readPipeAsyncTO() calls concurrently (much like any driver would do
for usb bulk transfers, queue up a few).
I'm finding that after a small number of completions, the callbacks
only timeout (wire protocol to the hardware is perfect). Adjusting the
number of concurrent ReadPipeAsyncTo() calls varies the failure rate
dramatically.
I've always had an assumption that calls to ReadPipeAsyncTO() were
queued by iokit or the kernel, as a thin wrapper around a more
standard usb_bulk_transfer() type implementation. I'm starting to
doubt that now, or doubt thats how its intended to work in 10.10.
Also, interestingly, assuming I queue a large number of these (all
calls return success) and immediately abort the pipe, only a small
handful of those are returned to the completion handler, the rest
'disappear'. The also feels new and unexpected.
Something's going on inside ReadPipeAsyncTo() that's new to 10.10. Grrr.
Thanks again for your earlier comments.
- Steve
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
On Fri, Jan 30, 2015 at 6:23 PM, Stuart Smith <[email protected]> wrote:
> I don't think you're running into a power issue. If you consume more
> current than the port is able to deliver, the hardware current-limits and
> this is reported at a very low level to the OS - you'll see a "This device
> is drawing too much power" notification, and the port won't work at all
> until the offender is removed.
> You could also monitor the power supply to the device - if it stays above
> 4.75V, you should be fine (it will probably work well below that, but
> AFAIR the USB spec limit is down to 4.75V at the device power pins).
> You could also run the device from a USB hub which you know can provide
> more than 500mA per port (i.e. almost any powered USB hub).
>
> Although the USB 2.0 spec says that a USB device shouldn't consume more
> than 500mA, USB 3.0 devices are allowed to take up to 900mA and many Apple
> devices negotiate much more. The USB ports usually have a fixed current
> limit.
>
> I think that you probably need to look closer at the analyzer trace -
> something before the timeout caused your device to hang. Are you sure that
> your device is enumerated as a High-Speed device?
>
> hth, Stuart
>
>
> On 1/30/15, 12:00 PM, "[email protected]"
> <[email protected]> wrote:
>
>>Message: 1
>>Date: Thu, 29 Jan 2015 15:48:08 -0500
>>From: Steven Toth <[email protected]>
>>To: [email protected]
>>Subject: USB power budget - New issues with 10.10 and/or new iMacs?
>>Message-ID:
>> <CALzAhNWeh3_Zh0vmSJgN=K_2OO0ZfbT_ae7q2OMrHF-cBSJR=w...@mail.gmail.com>
>>Content-Type: text/plain; charset=UTF-8
>>
>>Hey folks,
>>
>>I'd welcome some feedback on this, before we're forced to withdraw our
>>software product from general sale. Yes, today is a bad day. :(
>>
>>We produce a retail s/w application that provides support for a USB HD
>>H.264 video compressor device. It works well on OSX 10.7/8/9 on
>>multiple systems including older Mac Pros, MBP's, MBA's etc.
>>
>>Its not working well on all the 10.10 based Macs we have, namely a
>>iMac 5K and a MBP 13" retina, both (probably) using usb3 controllers,
>>older machines above are probably USB2 controllers. We have customers
>>in the field reporting the same issue "Used to work great, upgraded to
>>10.10 now it hangs".
>>
>>The USB2.0 device we're controlling has always ran (overbudget) at
>>around 560ma during peak use, idling around 420ma. (Same power
>>measurements under windows also). We have no issues with the device
>>when its running around 420ma on 10.10, although the video compressor
>>is not running at this point, we're doing basic status calls.
>>
>>The behavior we see under 10.10 is that when the device starts to
>>compress video, and the power starts to peak, climbing to 530ma and
>>potentially beyond, we start to see our urbs timing out, the device
>>stops responsing to AsyncBulkAsync reads. Rarely does an urb complete
>>without error, and if it does it's marked as overrun. The important
>>point to note is that the device never gets to 560ma.
>>
>>I've noticed on the Macs running 10.10 that the current never seems to
>>go beyond 530, suggesting some kind of operating system USB current
>>limit, or physical USB3 port current limit that doesn't occur on
>>slightly older systems (or on 10.9).
>>
>>Looking at the usb analyzer we see no protocol issues, only timeouts
>>waiting for posted urbs to be filled. No resets, not failed controll
>>transfers, no visible errors other than timeouts.
>>
>>I should point out that the application works very well with other USB
>>Capture devices on 10.10, all of which run at less than 500ma, I'm
>>confident the application is fine.
>>
>>Are their any known differences between 10.9 and 10.10 with regards to
>>allowable current that can be drawn from either a USB2 or USB3 port? I
>>realize the device runs overbudget, but is the OS (or USB controllers)
>>starting to enforce 500ma limits - that we're only just seeing?
>>
>>Many thanks,
>>
>>- Steve
>>
>>--
>>Steven Toth - Kernel Labs
>>http://www.kernellabs.com
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com
This email sent to [email protected]
