On Thu, 27 Aug 2009, Julie Zhu wrote: > Hi, Alan, > > > Hardware trace shows that only part of the submitted sitd's are in > there > > > when hardware going through the periodic frame list (and they all go > > > onto the bus), > > > > If the hardware doesn't see all of the submitted sitd's in the > periodic > > list then how can it send all of them over the bus? > > > > Exactly. That is what we are to find out. The software prints (almost > useless) show that active sitd's are unlinked in sitd_complete(). So these sitd's were not completed by the hardware. Have you tried printing out the values of frame and clock_frame just before sitd_complete() is called? > > > however, software saw all 100 submitted sitd's being > > > completed, and part of the completed sitd's have their active bit > set. > > > > Are you sure that all the sitd's are added to the frame list quickly > > enough? If an sitd is added to a frame after the controller has > > already started processing that frame then the sitd won't get > executed. > > > > Again, (almost useless) software prints show that the first sitd is > scheduled about 29 frames away, which is 29 milliseconds, should be > fine. And the first one is always there to be sent out, and it is on the > bus too. It is the middle ones that are missing. And the missing starts > when HS hub interrupt happens. Maybe the controller doesn't handle split transactions correctly when an interrupt occurs between the Start-Split and the Complete-Split. > now_uframe sometimes overpasses clock in scan_periodic without roundup > the frame list happening. Need to verify though. I'm not sure what you mean by "roundup", but this should not be possible. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
