Hi Alan, On Friday 06 July 2012 11:47:01 Alan Stern wrote: > On Fri, 6 Jul 2012, Alan Cox wrote: > > > Yes, but we still need to know the reason why. Neither Rafael nor I > > > has been able to figure out why that commit messed things up. > > > > Was the driver doing any dynamic autosuspend at all until that point ? > > I don't know... but whatever it was doing before the commit, it should > be doing the same thing afterward. > > > From the bug report it goes castors up in windows too if a suspend/resume > > occurs. > > Yes, it's definitely a bug in the webcam. > > On the other hand, there is a similar bug report for a Logitech C525 > webcam which works properly when suspended/resumed by an xHCI > controller but crashes when suspended/resumed by an EHCI controller. I > have no idea why. > > Laurent, you might want to take a look at that thread, in particular, > at this message: > > http://marc.info/?l=linux-usb&m=134115837927619&w=2 > > Can you explain the difference between the USB-2 and USB-3 usbmon > traces? (quoting your e-mail from the above link) > There are two significant differences between the USB-2 and USB-3 > traces, although I don't know what to make of them. > > Initially it looks like the driver writes a bunch of values to the > webcam and asks it to repeat them back. That's what happens in the > USB-3 trace, anyway. The USB-2 trace shows the values being written, > but when asked to repeat them back the webcam sends nothing. > > For example, with USB-3: > > ffff8804085042c0 470397794 S Co:3:003:0 s 22 01 0100 0086 0003 3 = 803e00 > ffff8804085042c0 470399896 C Co:3:003:0 0 3 > > ffff8804085042c0 470400004 S Ci:3:003:0 s a2 81 0100 0086 0003 3 < > ffff8804085042c0 470401270 C Ci:3:003:0 0 3 = 803e00 > > The 803e00 values get sent and then received. The analogous part of > the USB-2 trace shows: > > ffff88040cc1f5c0 208122798 S Co:1:006:0 s 22 01 0100 0086 0003 3 = 803e00 > ffff88040cc1f5c0 208124781 C Co:1:006:0 0 3 > > ffff88040cc1f5c0 208124818 S Ci:1:006:0 s a2 81 0100 0086 0003 3 < > ffff88040cc1f5c0 208126156 C Ci:1:006:0 0 0 > > Exactly the same values are sent and the request is the same, but no > data gets returned. I have no idea what that means. Neither do I, because those requests are sent to an audio endpoint. They're not related to UVC. It might be helpful to retest this without using audio. > Secondly, both traces show that the webcam stopped being used for a > short time and was suspended. A few seconds later, when it was resumed > again, it worked okay in the USB-3 trace. But in the USB-2 trace, it > didn't. After the resume it failed to reply to the first packet sent > (a Get-Device-Status request), and thus it had to be re-enumerated. USB2 and USB3 timings are probably slightly different, and Logitech devices have been known to suffer from race conditions in the past. Some would crash pretty much immediately in Linux depending on the USB controller used and the overall system "speed", while they worked fine on Windows. It turned out the firmware contained something like events = read(IRQ_EVENTS register); write(IRQ_EVENTS registers, 0xffff); I'm unfortunately not surprised by device-side bugs anymore. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
