Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Isoch read - kIOReturnIsoTooOld never seen on Leopard?

Coincidentally enough, I have been working on a very similar problem in the last day or two. I will assume that you are talking about a hi- speed device. Comments/questions inline:


On Dec 12, 2007, at 12:39 PM, Stuart Smith wrote:

One of my developers tells me that he never sees kIOReturnIsoTooOld returned
by an isochronous read on Leopard. However, if the read request is for a
time in the past, it is never scheduled. Because we don’t get an error when
making the request, we wait forever for its completion routine to be called.


The EHCI driver will return an immediate error of kIOReturnIsoTooOld if a request is for more than 1024 frames in the past. Anything between now and that time will be accepted, but will get return with a kIOReturnNotSent error. Don't ask why it's 1024, it's just the way it was designed and there probably is a good reason for it.

Does this problem happen under heavy loads?


When we want to stop reading, we usually simply stop posting reads and wait
a little while for the reads to return on their own. Some of the reads don't
return, so we abort the pipe, and *still* some of the reads don't return.

This was my problem as well. In a logging version of the USB family at a level 6 log, you will see some messages with AbortIsochEP and, perhaps, some indication that there were either scheduledTDs at the end, and/or the deferredTDs. The problem I debugged was that we ended up putting 'old' transactions into our deferred queue, but we never processed them. Sounds similar to what you are seeing. I have fixed this and eventually it will go out to the world.


We want to work around this by asking for the current frame number with
GetBusFrameNumber before posting every read, and ensuring that our posted
request is for some reasonable time in the future. This "should work"
assuming that the thread posting the reads isn't interrupted for any
significant time between the call to GetBusFrameNumber and the call to
ReadIsochPipeAsync.

Our question is this - how expensive is GetBusFrameNumber? We post many
isochronous reads per second.

Well, it is going to take some time as it has to go from user space into the kernel and back. Other than that, it's a couple of reads to a PCI register with an IOSync. It does not go thru the gate() or anything, so it should be pretty inexpensive. That was my first solution to the problem I was seeing in my video digitizer.


Obviously we need to do some more investigation before possibly filing a bug
here. I haven't yet deliberately tried to schedule reads in the past to see
what happens. 

Radars are always good.




Incidentally, this problem may have some bearing on a recent posting to this
list:

Date: Wed, 21 Nov 2007 18:42:31 -0500
From: Cobey Gatos <email@hidden>
Subject: Read Completions Under Leopard
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

I have written an audio driver that supports several USB 1.1
devices.  When audio is stopped, the driver will wait for all of its
outstanding isoch reads to complete before moving on. I have had no
problem with this code on various systems and machines dating back to
OS 10.2.

I did some testing on an Intel iMac running OS 10.5.1 with the audio
device plugged into a USB 2.0 hub. I found that when audio is stopped
and I stop posting new reads and wait for the outstanding ones to
complete, the completion for the last read will not be called unless
I either unplug the device, or I add a pipe->abort call to my audio
stop routine. I do not have this problem when the device is plugged
directly into the computer's USB port, and I do not have this problem
on the same machine with the same hub running under OS 10.4.11.

I am curious if anyone has any insight into why this occurs, and if
there is any reason I shouldn't call abort() to flush out the pesky
read completion.

Thanks for your help.

Cobey





_______________________________________________
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 

--
Fernando Urbina
USB Technology Team
Apple Inc.




_______________________________________________
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
References: 
 >Isoch read - kIOReturnIsoTooOld never seen on Leopard? (From: Stuart Smith <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.