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. > Although we don't include support for it at the moment, I can easily > imagine that some applications will need certain Iso packets to be > scheduled in certain frames or uframes. This will mean that in some > circumstances the HCD might be forced to schedule a packet for a frame > without knowing whether or not the controller has already progressed > too far. If it has, the result is an underrun. As you said, "we don't include support for it". Should such support ever be added, that's when such issues would need to be addressed. > > > Wouldn't it be safer to continue scanning until you reach transactions > > > scheduled for the current uframe or later? > > > > Put it this way: (b) has already been confirmed to fix some bugs > > that prevented a microphone-equipped fullspeed webcam from working. > > (Well, in conjunction with another fix; but that's silicon-specific > > and not related to this issue.) > > Stopping at an incomplete transaction will turn out to be a bug the > first time an underrun is encountered. Neither that packet nor any > later ones would ever be returned. If that's a bug, it's not a new one. This stuff is complex enough without trying to fix multiple unrelated bugs in one patch. :) > > And scanning for "current" had its own issues ... like the problems > > fixed by (a). The previous scanning logic was trying to be a bit > > too clever; and needlessly so. > > This doesn't need to be very clever. Just keep scanning until you > reach a transaction which is incomplete _and_ is scheduled for >= T, > where T is the (u)frame index as of when the scanning began. T doesn't > have to be exactly equal to "current". Again, that would be a different bug. I really don't want to be tossing in precautionary changes to sensitive code, just to guard against things we've never observed and which *should* not happen. That path leads to madness and bugs. Let's wait till we observe an actual failure, rather than going purely hypothetical. - Dave - 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
