Hi Alan, sorry for the late reply.
On Sunday 16 December 2007, Alan Stern wrote: > On Sat, 15 Dec 2007, Laurent Pinchart wrote: > > On Saturday 15 December 2007, Greg KH wrote: > > > On Sat, Dec 15, 2007 at 11:56:02AM +0100, Laurent Pinchart wrote: > > > > On Friday 14 December 2007, Greg KH wrote: > > As far as I know, neither EHCI nor OHCI hardware offers any reasonable > way to schedule transactions in separate frames, unless the device runs > at low speed (in which case it wouldn't be handled by EHCI anyway). > > It does seem odd that a device with an interface designed to run at > high speed would be crippled so that it couldn't take advantage of that > speed. I doubt the developers introduced those nasty bugs on purpose :-) > > > > The broken devices we are talking about have trouble with USB control > > > > requests. I'm still not 100% sure about this, but it seems the device > > > > misses the interrupt associated with the control transfer's status > > > > stage. Windows seems to schedule the setup and status transactions in > > > > different frames, while Linux seems to pack them in the same frame. > > > > > > Ok, I'm confused, can you please show me the commands that are failing > > > here? Can you use usbmon and show the dump of when this fails? > > > > I attached a dump to this e-mail. It shows the device enumeration process > > and two control requests initiated by the UVC driver (URBs 43 to 46). I > > added a 5 seconds delay before each request to make sure the device has > > time to initialize/recover/whatever. > > > > The first request is successful while the second isn't. It should be > > noted that on other computers both request succeed. From the information > > Logitech developers have been able to gather, the device receives the > > second request setup transaction but misses the data stage interrupt. It > > then just times out. > > Above you said the device misses the status-stage interrupt. Do you > know which one actually causes the problem? 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 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). Windows and Linux probably schedule transactions that make a control transfer differently. Some Linux users are unlucky and have their EHCI controller schedule some packet exactly in the race condition time window. > It's worth mentioning that the device doesn't have any trouble handling > the control transfers during enumeration. But that may be > understandable, because they are probably handled by very different > code in the firmware. That's what I believe too. > I'd have to go back and check to be certain, but I don't recall the bus > traces I've seen of Windows high-speed transfers showing that the > transactions making up a control message are scheduled in different > frames (or micro-frames)>. Could you have a look at the trace captured by Sunplus ? You might understand their explanation differently than I do. Best regards, Laurent Pinchart - 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
