Hello.
I ran bisect between 2.6.27 and 2.6.31, which was time between that
could broke.
My tests was:
compile kernel, with my standart .config (+-) with RTL8187 and UVC drivers.
boot with NetworkManager activated and in console run "mplayer -vo null tv://"
first camera start is _always_ successful, but second or trird mostly not.
I found commit:
commit 04a37e0f32f9882430bc1899899d2ed91b8aaf5b
Author: Laurent Pinchart <laurent.pinchart@xxxxxxxxx>
Date: Tue May 19 10:08:03 2009 -0300
V4L/DVB (11837): uvcvideo: Start status polling on device open
Most UVC camera include an interrupt endpoint to report control
value changes,
video streaming errors and camera button events. The USB controller
continuously polls the interrupt endpoint to retrieve such events. This
prevents the device from being auto-suspended, and thus consumes power.
Reporting video streaming errors don't make sense when the V4L2 device is
closed. Control value changes are probably useless as well if
nobody listens to
the events, although caching will probably have to be completely
disabled then.
No polling is thus be required when /dev/videoX is not opened.
To enable auto-suspend and save power do not poll the interrupt
endpoint until
the device is open. We lose the ability to detect button events if no
application is using the camera.
http://bugzilla.kernel.org/show_bug.cgi?id=11948
Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxx>
Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
Seems after once or twice run mplayer camera fails and take with it
whole USB subsystem. Only problem is that, I actual can't revert that
patch with actual kernel. Maybe camera in Toshiba A210-15j need some
another quirk.
David
2010/12/3 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Fri, 3 Dec 2010, okias wrote:
>
>> Hello,
>>
>> after long time I tested ehci->broken_periodic, but it didn't helped.
>> Perfect way to reproduce is: run system, let wifi connect, run mplayer
>> tv:// and try run it again, it fail and usb wifi disasociate after few
>> seconds.
>>
>> Any other ideas? Btw. for SB600 is already one workaround "ehci_hcd
>> 0000:00:13.5: applying AMD SB600/SB700 USB freeze workaround", maybe I
>> could try disable it?
>
> Yes, it won't hurt to try that. ÂYou also could try doing a git
> bisection.
>
> Alan Stern
>
>
--
Jabber/XMPP: okias@xxxxxxxxxxx
Skype: okiasxxx
ICQ: 283-633-094
--
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
