On Thu, 20 Dec 2007, Laurent Pinchart wrote: > Sunplus, the chip maker, investigated the problem and here is their > explanation: > > "STALL: The command timing in the linux is much faster than windows > system. This situation happens after the USB command is finished after > status stage occasionally. In the ISR, when firmware takes care an ACK > interrupt, for example an IN_ACK interrupt, firmware will clean the IN_ACK > event by â CBREG_USB_Ep0AckEvt &= ~INTR_USB_EP0_IN_ACK; â. In this code, > CPU will do (1) Read CBREG_USB_Ep0AckEvt to a buffer, (2) Use buffer to do > the AND operation, (3) Write the buffer value back to register > CBREG_USB_Ep0AckEvt. If a SETUP_ACK event is enabled after between (1) and > (3), this event will be clear after (3) is done. This will cause the STALL > problem. Firmware will miss the SETUP_ACK event and thinks that a NAK event > is received after the USB command is finished and then return a STALL." > > A related USB trace captured with a USB analyser is available at > http://www.irobotique.be/sunplus-trace.jpg. Please note that this trace isn't > related to the usbmon trace I sent in my last e-mail.
The events shown in the USB trace don't match the text above. The text describes a STALL response to a SETUP, but the trace shows a STALL response to an IN. > The explanation seems a bit unclear to me. What I understand is that > interrupts can be lost if they arrive at the wrong time (seems like a broken > microcontroller to me if you can clear interrupt bits by writing 0). Yes, that seems to be what they are trying to say. The end result shouldn't be fatal; the next control transfer will time out and fail, so the driver should be able to retry it. > Windows and Linux probably schedule transactions that make a control transfer > differently. I doubt that. The scheduling is done in the EHCI hardware, not by software. I did go back and look at some old Windows traces; the time interval between adjacent packets is extremely small. I doubt it is any slower than Linux. Now maybe Windows has a longer time interval _between_ control transfers. That's certainly possible. You could get the same effect by modifying the Linux driver to add a short delay. > Some Linux users are unlucky and have their EHCI controller > schedule some packet exactly in the race condition time window. > Could you have a look at the trace captured by Sunplus ? You might understand > their explanation differently than I do. It's hard to tell much from a single trace like that. It would be easier if we had two similar traces to compare, one from Linux and one from Windows. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
