ov538-ov7690

ov538-ov7690

[Michael Trimarchi]

Hi all

I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive

[ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71
[ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71
[ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71
[ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71
[ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71
[ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71
[ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71
[ 1275.666684] gspca: ISOC data error: [94] len=1020, status=-71
[ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71
[ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71

This error from the usb, how are they related to the camera?

Michael

Re: ov538-ov7690

[Michael Trimarchi]

Hi,

Michael Trimarchi wrote:
> Hi all
> 
> I'm working on the ov538 bridge with the ov7690 camera connected. 
> Somentimes I receive
> 
> [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71
> [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71
> [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71
> [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71
> [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71
> [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71
> [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71
> [ 1275.666684] gspca: ISOC data error: [94] len=1020, status=-71
> [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71
> [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71
> 
> This error from the usb, how are they related to the camera?
> 

Ok, this is not a big issue because I can use vlc to test the camera. But anybody
knows why camorama, camstream, cheese crash during test. is it driver depend? or not?

Michael

> Michael
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: ov538-ov7690

[Randy Dunlap]

On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote:

> Hi,
> 
> Michael Trimarchi wrote:
> > Hi all
> > 
> > I'm working on the ov538 bridge with the ov7690 camera connected. 
> > Somentimes I receive
> > 
> > [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71
> > [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71
> > [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71
> > [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71
> > [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71
> > [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71
> > [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71
> > [ 1275.666684] gspca: ISOC data error: [94] len=1020, status=-71
> > [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71
> > [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71
> > 
> > This error from the usb, how are they related to the camera?

-71 = -EPROTO (from include/asm-generic/errno.h).

-EPROTO in USB drivers means (from Documentation/usb/error-codes.txt):

-EPROTO (*, **)		a) bitstuff error
			b) no response packet received within the
			   prescribed bus turn-around time
			c) unknown USB error

footnotes:
(*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
hardware problems such as bad devices (including firmware) or cables.

(**) This is also one of several codes that different kinds of host
controller use to indicate a transfer has failed because of device
disconnect.  In the interval before the hub driver starts disconnect
processing, devices may receive such fault reports for every request.


> Ok, this is not a big issue because I can use vlc to test the camera. But anybody
> knows why camorama, camstream, cheese crash during test. is it driver depend? or not?

Could be driver.  Easily could be a device problem too.

---
~Randy

Re: ov538-ov7690

[Michael Trimarchi]

Hi,

Randy Dunlap wrote:
> On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote:
> 
>> Hi,
>>
>> Michael Trimarchi wrote:
>>> Hi all
>>>
>>> I'm working on the ov538 bridge with the ov7690 camera connected. 
>>> Somentimes I receive
>>>
>>> [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71
>>> [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71
>>> [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71
>>> [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71
>>> [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71
>>> [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71
>>> [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71
>>> [ 1275.666684] gspca: ISOC data error: [94] len=1020, status=-71
>>> [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71
>>> [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71
>>>
>>> This error from the usb, how are they related to the camera?
> 
> -71 = -EPROTO (from include/asm-generic/errno.h).
> 
> -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt):
> 
> -EPROTO (*, **)		a) bitstuff error
> 			b) no response packet received within the
> 			   prescribed bus turn-around time
> 			c) unknown USB error
> 
> footnotes:
> (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
> hardware problems such as bad devices (including firmware) or cables.
> 

OK, but it's a failure of the ehci transaction on my laptop and seems that is
not so frequent. I think that can be a cable problem.

> (**) This is also one of several codes that different kinds of host
> controller use to indicate a transfer has failed because of device
> disconnect.  In the interval before the hub driver starts disconnect
> processing, devices may receive such fault reports for every request.
> 
> 
>> Ok, this is not a big issue because I can use vlc to test the camera. But anybody
>> knows why camorama, camstream, cheese crash during test. is it driver depend? or not?
> 
> Could be driver.  Easily could be a device problem too.

I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using
the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :(

Michael

> 
> ---
> ~Randy
> 

Re: ov538-ov7690

[Randy Dunlap]

On Tue, 10 Nov 2009 17:51:15 +0100 Michael Trimarchi wrote:

> Hi,
> 
> Randy Dunlap wrote:
> > On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote:
> > 
> >> Hi,
> >>
> >> Michael Trimarchi wrote:
> >>> Hi all
> >>>
> >>> I'm working on the ov538 bridge with the ov7690 camera connected. 
> >>> Somentimes I receive
> >>>
> >>> [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71
> >>> [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71
> >>> [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71
> >>> [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71
> >>> [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71
> >>> [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71
> >>> [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71
> >>> [ 1275.666684] gspca: ISOC data error: [94] len=1020, status=-71
> >>> [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71
> >>> [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71
> >>>
> >>> This error from the usb, how are they related to the camera?
> > 
> > -71 = -EPROTO (from include/asm-generic/errno.h).
> > 
> > -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt):
> > 
> > -EPROTO (*, **)		a) bitstuff error
> > 			b) no response packet received within the
> > 			   prescribed bus turn-around time
> > 			c) unknown USB error
> > 
> > footnotes:
> > (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
> > hardware problems such as bad devices (including firmware) or cables.
> > 
> 
> OK, but it's a failure of the ehci transaction on my laptop and seems that is
> not so frequent. I think that can be a cable problem.

Probably could be a cable problem.

If you suspect that it is a USB (ehci) problem, you should raise this issue
on the linux-usb@vger.kernel.org mailing list.

> > (**) This is also one of several codes that different kinds of host
> > controller use to indicate a transfer has failed because of device
> > disconnect.  In the interval before the hub driver starts disconnect
> > processing, devices may receive such fault reports for every request.
> > 
> > 
> >> Ok, this is not a big issue because I can use vlc to test the camera. But anybody
> >> knows why camorama, camstream, cheese crash during test. is it driver depend? or not?
> > 
> > Could be driver.  Easily could be a device problem too.
> 
> I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using
> the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :(

I don't even know what vl2 vl1 means. ;)


---
~Randy

Re: ov538-ov7690

[Mauro Carvalho Chehab]

Em Tue, 10 Nov 2009 09:09:10 -0800
Randy Dunlap <rdunlap@xenotime.net> escreveu:

> > > (**) This is also one of several codes that different kinds of host
> > > controller use to indicate a transfer has failed because of device
> > > disconnect.  In the interval before the hub driver starts disconnect
> > > processing, devices may receive such fault reports for every request.
> > > 
> > > 
> > >> Ok, this is not a big issue because I can use vlc to test the camera. But anybody
> > >> knows why camorama, camstream, cheese crash during test. is it driver depend? or not?
> > > 
> > > Could be driver.  Easily could be a device problem too.
> > 
> > I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using
> > the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :(
> 
> I don't even know what vl2 vl1 means. ;)

He is probably referring to V4L1 x V4L2 API calls. Very unlikely. What libv4l
does is to convert userspace calls via V4L1 to a V4L2 call to kernel. So,
you're basically using the same API to communicate to userspace.

It should be noticed that, if you're not using libv4l for the other
applications, then you may be using a different format at the driver, since
libv4l has the capability of doing format conversions.

So, it could be possible that the device firmware for some formats are broken.

Another possibility is that maybe libv4l is just discarding such errors.

Or, as Randy mentioned, it can be just a cable or a connector with bad contact.

Cheers,
Mauro

Re: ov538-ov7690

[Michael Trimarchi]

Mauro Carvalho Chehab wrote:
> Em Tue, 10 Nov 2009 09:09:10 -0800
> Randy Dunlap <rdunlap@xenotime.net> escreveu:
> 
>>>> (**) This is also one of several codes that different kinds of host
>>>> controller use to indicate a transfer has failed because of device
>>>> disconnect.  In the interval before the hub driver starts disconnect
>>>> processing, devices may receive such fault reports for every request.
>>>>
>>>>
>>>>> Ok, this is not a big issue because I can use vlc to test the camera. But anybody
>>>>> knows why camorama, camstream, cheese crash during test. is it driver depend? or not?
>>>> Could be driver.  Easily could be a device problem too.
>>> I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using
>>> the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :(
>> I don't even know what vl2 vl1 means. ;)
> 
> He is probably referring to V4L1 x V4L2 API calls. Very unlikely. What libv4l

Yes

> does is to convert userspace calls via V4L1 to a V4L2 call to kernel. So,
> you're basically using the same API to communicate to userspace.

Ugly but very usefull in such application like skype, and people want it :(

> 
> It should be noticed that, if you're not using libv4l for the other
> applications, then you may be using a different format at the driver, since
> libv4l has the capability of doing format conversions.
> 
> So, it could be possible that the device firmware for some formats are broken.
> 
> Another possibility is that maybe libv4l is just discarding such errors.
> 
> Or, as Randy mentioned, it can be just a cable or a connector with bad contact.

Change the connector fix the packet problem. So at least the version ov538-ov7690
seems ok.

Thanks