Hi, Vidar
> uvcvideo: Failed to resubmit isoc URB (-45).
> uvcvideo: Failed to resubmit isoc URB (-45).
> uvcvideo: Failed to resubmit isoc URB (-45).
> uvcvideo: Failed to resubmit isoc URB (-45).
> usb 1-4: USB disconnect, address 6
> usb 1-4: new high speed USB device using ehci_hcd and address
On 11/16/06, Evgeny <[EMAIL PROTECTED]> wrote:
> Please try the next version attached.
I faulty modified sleep code.
Please change schedule() call at line 43 of uvc_video.c to udelay(500);
schedule() is not suitable here
The new version seems to work even longer before causing trouble, as f
Hi Evgeny,
> > Please try the next version attached.
>
> I faulty modified sleep code.
> Please change schedule() call at line 43 of uvc_video.c to udelay(500);
> schedule() is not suitable here
That's not a good idea. You will end up with an non interruptible delay. Why
was schedule not suitabl
Hi Evgeny,
> It seems that there is an interference between concurrent usb transfers.
> E.g. submitting isochronus URB and control URB. The source of problem is
> definitely in camera hardware, but we can avoid it in driver using software
> methods.
Are you sure about that ? Could you give more i
> Please try the next version attached.
I faulty modified sleep code.
Please change schedule() call at line 43 of uvc_video.c to udelay(500);
schedule() is not suitable here
Evgeny Marchenko
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlio
Hi, all
It seems that there is an interference between concurrent usb transfers. E.g.
submitting isochronus URB and control URB. The source of problem is
definitely in camera hardware, but we can avoid it in driver using software
methods.
Laurent and Martin, what do you think about using mute
> I really love this patch! It works much better than the reset patch for me.
> I am able to
> record alot more times
Nice to read this. Thank you for participation in this work.
> before I get an error, but now I get a new, exciting
> one. This is
> the output from "dmesg | tail":
> uvcvideo:
On 11/13/06, Evgeny <[EMAIL PROTECTED]> wrote:
Hi, all
Please look at this patch. It contains at least 500 microseconds delay
before
сonsistent usb_control_msg() calls. Reset patch is also included, but
disabled by default.
In my test I never get -110 error. -32 returned in case of incorrect
c
Hi, all
Please look at this patch. It contains at least 500 microseconds delay before
сonsistent usb_control_msg() calls. Reset patch is also included, but
disabled by default.
In my test I never get -110 error. -32 returned in case of incorrect control
value (for example changing white balanc
Hi, all
Patch definitely is not a solution. I performed a deep investigation of this
problem. I tested driver on x86 and amd64 architectures with "reply"
and "reset" patches and without them. As a result I found, that replying
control message almost doesn't help. At some point camera doesn't ac
> >> That's the thing. On Windows, the hardware bug simply isn't triggered.
> >> The timing of the USB packets is slightly different on Linux and
> >> Windows and apparently that's enough to trigger the problem.
> >
> > Is this something that should be addressed in the USB subsystem? Is
> > either
On Sat, 11 Nov 2006 00:06:17 +0100, Nick Wiltshire <[EMAIL PROTECTED]>
wrote:
> On Friday 10 November 2006 06:04, Martin Rubli wrote:
>> That's the thing. On Windows, the hardware bug simply isn't triggered.
>> The timing of the USB packets is slightly different on Linux and
>> Windows and a
On Friday 10 November 2006 06:04, Martin Rubli wrote:
> That's the thing. On Windows, the hardware bug simply isn't triggered. The
> timing of the USB packets is slightly different on Linux and Windows and
> apparently that's enough to trigger the problem.
Is this something that should be addres
> > My question is - even though this is a (nescesary) ugly workaround,
> > will it ever be merged into the 'offical' driver?
>
> Absolutely. We still want to find the nicest possible workaround, but
> _something_ will be integrated in the official driver.
I'll merge the retry patch in the driver
Hi Vidar,
> I installed this patch on a computer used for webcam surveillance
> (yes, I finally got ffmpeg working!), but now I have a strange issue:
> This computer has 2 webcams connected, but it seems that sometimes
> only one of it is "shown" - only one of the videoX devices show up in
> /dev.
Hi Evgeny,
> Another question.
> Can anybody tell me, why not to use HZ as a timeout multiplier when calling
> usb_control_msg() ?
Because the usb_control_msg() documentation states that the timeout parameter
is expressed in milliseconds.
Laurent Pinchart
___
Hi everybody,
> Could you try changing the line that reads
>
> if(ret >= 0 || ret != -EPIPE)
>
> to
>
> if(ret >= 0 || (ret != -EPIPE && ret != -ETIMEDOUT))
Make it
if(ret >= 0 || (ret != -EPIPE && ret != -ETIMEDOUT && ret != -EPROTO && ret !=
-EOVERFLOW))
> to see if the camera recovers from
On Fri, 10 Nov 2006 17:05:59 +0100, Evgeny <[EMAIL PROTECTED]> wrote:
>> Other errors that were reported to occur are EOVERFLOW and EPROTO but
>> those are pretty rare and therefore more difficult to test.
>
> Martin, is there good reason why not to resend USB control message in
> case of
> EO
Another question.
Can anybody tell me, why not to use HZ as a timeout multiplier when calling
usb_control_msg() ?
___
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
> Other errors that were reported to occur are EOVERFLOW and EPROTO but
> those are pretty rare and therefore more difficult to test.
Martin, is there good reason why not to resend USB control message in case of
EOVERFLOW, EPROTO or any other error?
_
Hey George,
> I am also a victim of this issue... FWIW i found the patch worked fine
> last time I tried it (i have since updated from SVN, and as I run
> motion which just opens the camera and keeps it open, the bug doesnt
> hit me that often, so I havent bothered to reapply. However, if my nfs
>
On Fri, 10 Nov 2006 11:07:53 +0100, Evgeny <[EMAIL PROTECTED]> wrote:
>> Good question ... The only computer I can currently test it on doesn't
>> seem to give me the ETIMEDOUT error at all. If you experience ETIMEDOUT,
>> what happens if you retry in that case, too?
>>
>> Other errors that were r
Hey Vidar,
Could you try changing the line that reads
if(ret >= 0 || ret != -EPIPE)
to
if(ret >= 0 || (ret != -EPIPE && ret != -ETIMEDOUT))
to see if the camera recovers from error -110 (ETIMEDOUT) in the same way
as it does from -32 (EPIPE)?
I don't know much about store return policies bu
> Good question ... The only computer I can currently test it on doesn't
> seem to give me the ETIMEDOUT error at all. If you experience ETIMEDOUT,
> what happens if you retry in that case, too?
>
> Other errors that were reported to occur are EOVERFLOW and EPROTO but
> those are pretty rare and th
On 11/7/06, Martin Rubli <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Attached is a rather ugly patch that has proven to make the Logitech UVC
> cameras work fine for some people. It works around the USB errors by
> retrying control requests up to three times.
>
> We would like to get as much feedback
Hello,I installed this patch on a computer used for webcam surveillance(yes, I finally got ffmpeg working!), but now I have a strange issue:This computer has 2 webcams connected, but it seems that sometimes
only one of it is "shown" - only one of the videoX devices show up in/dev. First time I noti
>> It works around the USB errors by
>> retrying control requests up to three times.
>
>> + if(ret >= 0 || ret != -EPIPE)
>> + break;
>
> Thank you for your work. The only question is what happens when ret ==
> ETIMEOUT ? The camera usually becomes unaccessable a
Hi Martin
>It works around the USB errors by
> retrying control requests up to three times.
> + if(ret >= 0 || ret != -EPIPE)
> + break;
Thank you for your work. The only question is what happens when ret ==
ETIMEOUT ? The camera usually becomes unaccessable
Hi all,
Attached is a rather ugly patch that has proven to make the Logitech UVC
cameras work fine for some people. It works around the USB errors by
retrying control requests up to three times.
We would like to get as much feedback as possible, so if you try it out,
please let us know wh
29 matches
Mail list logo
