On Tuesday 27 July 2010 17:33:06 Alan Stern wrote: > 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)? I mean the TD that follows. > > > > 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. I grepped the EHCI specification for the word short, and in section 3.5.2 it says about the alternate next pointer that this will alaways be used when a short packet is received. If the alternate next pointer is set to the terminate value, shouldn't the QH be retired aswell? Is a ZLP not regarded a short packet? If your view is correct, than you cannot setup more than 16K of TD's when doing mass storage, risking that on IN transactions the Command Status Wrapper block will get part of the data buffer. --HPS -- 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
