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(). > > 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. > > This only happens when an HS hub is between the host controller and the > > FS iso device (and scan_periodic is called all the time). What makes it > > difficult is that printing in the code changed all the timing, and seems > > not telling the situation I am debugging for. I do suspect that > > scan_periodic() is updating counters too fast (without proof yet). > > Which counters? > now_uframe sometimes overpasses clock in scan_periodic without roundup the frame list happening. Need to verify though. > > Any > > suggestions on how to debug this are appreciated. > > Add some debugging statements to sitd_link_urb(). Print out the frame > number the sitd is linked into and the controller's current frame > number. > I did that, and it looks fine. Since the scheduling is to put sitd's into frames interval's apart, so there is no mistake there. Thanks, Julie. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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
