On Wed, 9 Jan 2008, David Brownell wrote: > On Wednesday 09 January 2008, Alan Stern wrote: > > On Wed, 9 Jan 2008, David Brownell wrote: > > > > > On Wednesday 09 January 2008, Alan Stern wrote: > > > > > > > > > > (b) When we encounter an ISO transfer (either speed, but this > > > > > > hits mostly at full speed) that's not yet been completed, > > > > > > immediately stop scanning; we've caught up to the hardware, > > > > > > no matter what other indications might say. > > > > > > > > Is this known to be correct? What if an ISO transfer gets added to the > > > > schedule just a little too late (after the starting frame has ended)? > > > > > > That would be called a scheduler bug. > > > > Maybe. Or maybe it's just an overrun. > > Nope; scheduler bug. There's an explicit requirement for a gap > between "now" and when the first new transfer can be added. Should > that requirement be expressed wrong, or not implemented correctly, > that'd be a bug.
Hmmm... Where is this requirement made explicit? There are comments about what should happen when URB_ISO_ASAP is set, but what about when it isn't set? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
