On 07.07.2012 11:20, Eric Ding wrote: > On 07/06/2012 11:47 PM, 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. > > I'm really out of my league here; I only submitted a bug report because > my webcam stopped working, never imagining it'd lead to 4-5 days of > kernel bisection (which I've never done before) and/or submitting a > kernel patch. Still, though, if I can be of any further help in getting > to the bottom of this, I'd like to try. > > I thought that getting some comparative usbmon logs might help, but I'm > not equipped to parse them. To generate these logs, I ran guvcview once > after plugging in the webcam, then did the following upon quiting > guvcview: start listening via usbmon, sleep for four seconds, start > guvcview again and stop listening via usbmon after four seconds. > > I did this both at commit e1620d5 (the commit which triggered this > issue) and once at commit 9975961 (one commit prior). Going through > these motions also confirmed that the problem is readily reproducible > the second time I start guvcview at e1620d5, but not at 9975961. I've > attached both logs in case they're helpful. > > Please let me know if there's anything more I can do to help. > > Thanks, > Eric >
In both logs you send the cam start to stream video. Major difference is that, after suspend/resume it need more time (about 10 seconds) to start stream. Is it correct? -- Regards, Oleksij -- 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
