On Sat, 7 Jul 2012, Oleksij Rempel wrote: > >> Ok, i guess i know your problem but i doubt it will be completely fixed > >> by changing powermanagement behavior. Two logitech cams i tested is > >> really easy to confuse/brake/freeze. Just turn off the stream before it > >> will send first frame. It looks like it take longer to boot buildin > >> controller or image processor. On second (hot) start it take less time. > >> If the cam was suspended it need this boot time again. The problem, even > >> if we do hot start and turn of stream before first frame, like some apps > >> did, the cam will brake again. By disabling auto suspend, we will reduce > >> probability to brake it, but not fix it.
I don't think that was the problem. As far as I can tell, the problem with these Logitech webcams is that they often fail to resume correctly following a suspend. They require a reset before they will start working again. Apparently the behavior before commit e1620d5 was that the webcam didn't get suspended, and after the commit it did. Unfortunately the usbmon traces do not explain this difference; all they show is when/whether a suspend took place. For example, the prelog.9975961.out trace shows that the webcam wasn't suspended before the trace began, and the postlog.e1620d5.out trace shows that it was (although when the webcam was resumed, it did work okay -- this was one of the times it didn't crash during the resume). > >> Some times i have the splitimage issue too, but i can't 100% reproduce it. > > > > So does your description of the problem explain why commit e1620d5 > > causes this problem to happen 100% of the time on the second start, even > > though I cannot reproduce this problem at all before that commit? > > Please note, i said "i guess", i'm not sure if it is same issue. With > 3.5.0-rc5-00098-g9e85a6f i can't reproduce this issue at least after > fresh start. After long work some times i get some thing similar to your > description. > > > Isn't > > that the mystery that still remains unsolved? Do the usbmon logs not > > answer that question? > > no. Same configuration sequence, same responses. I see only one > difference, on e1620d5 the cam needed longer to start streaming. This > is know on other cams, but they work. > > > Going back also to the patch I submitted, it seems (at least in my > > testing) that USB_QUIRK_RESET_RESUME does work around this issue > > consistently, at least for my webcam. The quirk tells Linux to reset the webcam whenever it is resumed. > ok. the problem is, e1620d5 moves existing CONFIG_USB_SUSPEND from one > place to another. uvcvideo used autosuspend before. This is why this > quirk make no sense. Well, the quirk does make sense. What doesn't make sense is why moving the runtime PM operation pointers from usb_bus_type to usb_device_type should cause any change in the autosuspend behavior. That's what we would like to know. Eric, are your kernel-hacking skills up to debugging this? I can tell you where to look and what to look for. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
