Hi David, Thanks for the info. From your post I understand that, strangely, Alex Sanks' last reply on this issue hasn't landed on the list. It comes below.
> That said: you mentioned chip markings on that net2280 > device, and they match what I have on an old rev1 (0100) > RDK board. And I've always had problems getting that to > work at full speed. Only early developers saw rev1 parts, > as I understand it, and most of them updated to rev1a; > no products should have shipped with rev1. > > The net2280 driver should announce rev1a (0110) as it > starts up ... what does it say for you? net2280 0000:00:07.0: NetChip 2280 USB Peripheral Controller net2280 0000:00:07.0: irq 3, pci mem e0820000, chip rev 0100 net2280 0000:00:07.0: version: 2004 Jan 14; dma enabled Olav ---------- Forwarded message ---------- Date: Tue, 1 Feb 2005 17:35:23 -0800 From: Alex Sanks <[EMAIL PROTECTED]> To: 'Olav Kongas' <[EMAIL PROTECTED]> Cc: "'[email protected]'" <[email protected]>, 'Alan Stern' <[EMAIL PROTECTED]> Subject: RE: [linux-usb-devel] usbtest 14 fails: is host or gadget theprit ? Hi Olav, > -----Original Message----- > > Alex, before you ask, here is what I found on the chip: > NetChip > NET2280 rev 1 > 0234K 2002 > Thanks for pointing that out, it turns out that's actually the root of the problem. I ran test 14 on several NEC and Intel hosts (including the same Intel UHCI you had trouble with) with my rev1a board and had no problems as all. I dug around the lab and found an old rev1 board. I was then able to see the failure when testing with the Intel UHCI host. It looks like you're falling victim to one of the cases in errata 631-0177-0106: FULL SPEED OUT PACKETS MIGHT BE DOUBLED (Fixed in REV 1A) <..snipped first form..> The second form of the erratum occurs when: 1. The FIFO has enough space to hold the entire newly arriving OUT packet. 2. The host sends an OUT token with an associated data packet. 3. The NAK OUT Packets bit is set (true) so that the Net2280 will return a NAK handshake. 4. The PCI bus is bursting data to or from an endpoint FIFO. In the second form, the PCI bursting causes writes from the USB state machine into the FIFO to be held off. The USB state machine stores the held-off data in a separate holding register. The USB state machine sends a NAK to the host and restores the FIFO pointer to the position at the start of the packet, so most of the packet is discarded. However, the last few bytes of the packet are still in the separate holding register. Finally, the PCI burst allows the USB holding register to be written to the FIFO after the pointer is restored. These extra bytes have been written, but they are not yet visible (by reading the EP_AVAIL register, for example). When the next OUT packet is accepted by the Net2280, the extra bytes will appear inserted in front of the newly accepted packet. According to the USB protocol, the packet data should be the same, so the extra inserted bytes should be a duplication of the last few bytes of the newly accepted packet. (there are comments relating to this situation in read_fifo()/out_flush() ) This seems consistent with that I'm seeing when I watch this with a bus analyzer. The code in there now seems like a reasonable version of a workaround mentioned in the errata document, but apparently some cases still slip thru the cracks. At this point, I'd say your best bet would be to look into upgrading to a rev1a device which has eliminated this errata entirely. Regards, Alex ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
