Hi, Alan, Steve and all, > > > > 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? > My trace show that active sitd's being unlinked if the schedule goes around the frame list, the ones that scheduled on the head of frame list are unlinked with active bit set. Our frame list is 256 long. The following is the detail of one of the traces (that have failed): The packet 69, which is put onto the bus, is submitted to frame 253 at frame time 167, with ehci->next_uframe >> 3 as 167. At the time sitd_complete() is called, frame is 253, clock frame is 9. The packet 70, which is unlinked with active bit set, therefore does not go onto the bus, is submitted to frame 1 at frame time 167, with ehci->next_uframe >> 3 as 167. At the time sitd_complete() is called, frame is 1, clock frame is 9. This is strange, hardware does not see anything at frame 1. There is nothing wrong with software unlinking at frame 9. The packet 71, which is unlinked with active bit set, is submitted to frame 5 at frame time 167, with ehci->next_uframe >> 3 as 167. At the time sitd_complete() is called, frame is 5, clock_frame is 9. Packets 70 and 99 are all unlinked with active bit set, therefore not seen on the bus. The same thing happens on other traces with HS hub. With FS hub, where tests pass, the following is about the scheduled sitd's that are across the frame list boundary: The packet 51, scheduled to frame 253 at frame time 239, with ehci->next_uframe >> 3 as 239. At the time sitd_complete() is called, frame is 253, clock frame is 81. The packet 52, scheduled to frame 1 at frame time 239, with ehci->next_uframe >> 3 as 239. At the time sitd_complete() is called, frame is 1, clock frame is 81. The difference I see is that with HS hub, the scan_periodic goes much sooner than FS hub (9 versus 81). Hardware trace shows the same thing, that if connected through HS hub, the frame list has no sitd's once goes to the beginning of the frame list (frame list roll over). I still do not see what is causing this. 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
