On Thu, 27 Aug 2009, Julie Zhu wrote: > 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. Maybe this means your controller doesn't implement the 256-entry frame list correctly. Have you tried testing with a 1024-entry frame list? > 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. Why do you call it packet 69? Is it the 19th packet of the second URB? > 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. This certainly sounds like a bug in the controller hardware. > 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). This depends on when scan_periodic() runs. Since your URBs contain 50 packets with an interval of 4 frames, scan_periodic() should be called every 200 ms. But the I/O watchdog timer will run every 100 ms. So I think the actual frame (9 vs 81) is somewhat random -- it could be anywhere between 0 and 100. > 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. It does not appear to be a problem in the driver. That means the problem must be in your controller hardware. 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
