On Tuesday 04 April 2006 12:10 pm, Alan Stern wrote: > Dave: > > Here are the results from a few tests of my net2280 card, fresh as of this > afternoon. > > (1) Testing with a Beagle analyzer showed that when running at full-speed, > the net2280 always finishes a transfer on ep0 by NAKing the first > status-stage transaction and sending the expected packet the second time. > This is odd because the transfers were running without FSBR, so there was > only one transaction per frame. The net2280 therefore had a millisecond > to prepare for finishing the transfer, which should have been plenty of > time. This was all stuff like descriptor fetches, nothing fancy.
So it's sub-optimal but not incorrect? That sounds like it should be fixable by someone with time to apply. And possibly related to #2 below. > (2) Editing zero.c to set various string descriptors to exactly 31 bytes > showed that the net2280 did not respond correctly after all the data had > been sent. A Get-String-Descriptor request for 255 bytes transferred 64 > bytes in the first Data packet, and after that the net2280 NAKed all > further IN packets until the transfer timed out. I verified this directly > using the Beagle analyzer at full speed; at high speed usbmon showed the > same results. OK, that's a bug and is incorrect. The configuration descriptor is also 64 bytes, right? But it doesn't have that failure mode... > (3) After timing out on the Serial number descriptor transfer, Linux does > a Get-Device-Status, which is a 2-byte transfer. The data was transferred > correctly, but again the net2280 NAKed the status stage until the transfer > timed out. Oddly enough, when I changed the Manufacturer string (which is > fetched immediately before the Serial number string) to be 31 bytes long > so that it timed out, and made the Serial number either 30 or 32 bytes, > the Serial number transfer proceeded correctly. > Clearly something is not working right. However I have no idea where to > look or what to change in the driver. Net2280 can give IRQs for most EP0 events. I recall avoiding most NAK irqs, since they are rarely meaningful. Grab the chip spec and watch the events for EP0 as they're happening. - Dave ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
