On Sun, 9 May 2004, Heiko Rosemann wrote: > Hi everyone, > > On Sun, 9 May 2004, Alan Stern wrote: > > > Just so. For some reason, under 2.6 the modem is returning for most of > > the queries the answer to the _previous_ query. This makes no sense to me > > at all. It's not a simple matter of changing the string index -- on the > > two occasions the modem was asked for string 6 it gave two different > > results! > > > > I can't imagine why it should behave like this. Firmware bug, obviously, > > but a very strange one. > > Well, I can somewhat imagine why this happens - had some of those problems > while re-coding a HUB and a HID firmware to enumerate with linux as well - > since I have no userspace program yet, I can only hope the device will send > data properly too... > > The problem is in the nature of how many cheap USB devices are made today: A > microcontroller with a USB interface, running display updates, reading > inputs, writing outputs and, just for fun, also doing USB communication. > Normally, you get an IRQ for every packet that is sent or received. Now > imagine you receive a setup packet, process it and load the transmit buffer > with the appropriate data. Then for every IN request, the endpoint toggles > an IRQ and in the IRQ handler it is re-armed to send more data. > > Now imagine you get another IN request before you're program can handle the > IRQ. The USB interface transmits the same data again, but with the same data > sequence (DATA0/DATA1) so the host discovers something is wrong and discards > that packet. > > But, if you get another SETUP request and just by bad luck the data > registers are still set up for an IN request with previous data, you easily > get the wrong data if you send the IN request before the controller can > handle the setup-token-IRQ. > > Remember, you are running with (at best) 6MHz=6MIPS, normally no operating > system with multi-tasking. It's fun. And then you try to implement what you > understand from the USB specification... and things still don't work. > > One example: If you read data (e.g. for a descriptor read), you read it in > multiples of the endpoint buffer size. If you do a full read (i.e. read as > many bytes as the device sends out), the device just sends data until there > is none available anymore, ending with a packet of 0-7 bytes if the endpoint > buffer length is 8 bytes. If you do a short read (i.e. read less data than > the full descriptor), you are not allowed to end the read with a 0 > byte-packet, but instead you have to end with a packet of 1-8 bytes. Don't > ask me why, with Windows, you don't have that limitation. And I didn't find > any information about this particular matter in the USB specs either. > > Just for your information, > > Heiko
That's a nice analysis, although perhaps things aren't quite as bad as you indicate since there will be an OUT packet that has to be acknowledged before the next SETUP packet is sent. More to the point, do you have any recommendations for how the host should try to cope with this sort of problem? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
