On 2/28/06 9:35 AM, "Rhoads Hollowell" <email@hidden> wrote:
> Yes it is possible that not all of your completion routines is
> getting called. We just fixed a bug along those lines. The signature
> is a log message saying something like "...expected frame (NN) and
> see frame (NN) - should do something here!!"
Ah, yes, I was getting that message. That explains why the code was getting
so confused.
> This bug will be fixed in a future software update. In the meantime,
> you might try structuring your code so that you don't call Abort() on
> Isoch pipes, but I am not 100% sure that will always work. This only
> affects Full Speed Isoch IN devices attached to High Speed hubs.
Thanks. It looks like by changing the number and structure of the requests
that we can absorb the error, recover, and continue.
Mark
> On Feb 28, 2006, at 8:25 AM, Mark Cookson wrote:
>
>> The interesting part of the problem I'm seeing is that it looks
>> like, but I
>> haven't been able to verify/disprove yet, that not all of my
>> completion
>> routine calls are being called when I get the USBNotSent2Err error.
>>
>> Could this be possible? Without all of the completion routines being
>> called, I wouldn't have all of the reads queued that I was
>> expecting, and
>> that would certainly go a long way towards explaining the problem
>> that I'm
>> seeing.
>>
>> Thanks,
>> Mark
>>
>> On 2/27/06 9:24 AM, "David Ferguson" <email@hidden> wrote:
>>
>>> The EHCI controllers found in the 17" Intel Core Duo iMac can look
>>> more than a millisecond ahead into scheduled periodic transactions
>>> (like high-speed isoch, or split-transactions to full-speed isoch
>>> device attached to a high-speed hub), if it doesn't see any
>>> transactions scheduled it can decide not to traverse the list at that
>>> time, even if a transaction is added later. This behavior will lead
>>> to more "USBNotSent2Err" -- Steve Sisak's suggestions for dealing
>>> with them is exactly correct. If you really want to avoid them
>>> altogether, just schedule your IN transactions further in the future.
>>>
>>> David Ferguson
>>> USB Software Team
>>> Apple Computer
>>>
>>> At 4:34 PM -0600 2/24/06, Mark Cookson wrote:
>>>> On the 17" Intel Core Duo iMac a couple of our USB audio devices
>>>> get the
>>>> USBNotSent2Err on one of their interfaces.
>>>>
>>>> The particular device I'm looking at has three interfaces, two
>>>> for input
>>>> (recording) and one for output (playback). It's only ever one of
>>>> the input
>>>> interfaces that has the error, output is always fine, and the
>>>> particular
>>>> interface changes from run to run. After getting this error (in
>>>> frStatus
>>>> the completion routine) my standard bit of error correction isn't
>>>> able to
>>>> get things going again, though no errors are reported from the
>>>> pipe->Read()
>>>> call that's made after this error is returned.
>>>>
>>>> What's causing this error in the first place? And how should I
>>>> try to
>>>> recover from it?
>>>>
>>>> I'm hoping that this means that my error correction is missing a
>>>> case, but
>>>> I'm not seeing it. I'm hoping someone on this list can tell me
>>>> more about
>>>> what the USBNotSent2Err means and how I should try to recover
>>>> from it.
>>>>
>>>> These are isoc reads on a USB 1.1 device, Mac OS X 10.4.4 and
>>>> 10.4.5, Intel
>>>> Macs seem to be far more likely (by orders of magnitude) to have
>>>> this
>>>> problem than PPC ones.
_______________________________________________
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
This email sent to email@hidden
