On Tue, 27 Jul 2010, Alan Stern wrote: > > 2) Send from the USB gadget the following byte sequence in a HS BULK endpoint: > > 512 + ZLP or 1024 + ZLP or 2048 + ZLP or 4096 + ZLP. Try also to replace ZLP > > with a short packet. One of these cases should trigger the bug, that the EHCI > > continues working on the next TD, though filling some crap into the bytes bits > > of the status DWORD. > > When you say "the next TD", do you mean the second TD above (at > 0x0178e400) or rather the TD that follows it (at 0x0178e380)? > > In each case, I would expect the controller to store N bytes in the > first 16-KB buffer (where N is 512, 1024, 2048, or 4096 respectively) > and 0 bytes in the second buffer, and then to move on to the following > TD. If you had set altnext to some other value, then the controller > would behave differently. Oops, sorry, that's wrong. I would expect the controller to store N bytes in the first 16-KB buffer and then to start executing the second qTD. What gets stored in the second buffer would depend on the following packets. 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
