Irritating quirkyness: we have a bunch of videocams. To use, we use gspca.
Usually, on an upgrade, I just go into the gspca directory (which appears,
from their website, to have not been updated since '07), make clean, make,
make install.
Having gone up to 5.5, did the same. What's happening now is that it
works, delivers the mpgs... but dumps errors in the logs:
<snip>
kernel: /usr/local/src/gspcav1-20071224/gspca_core.c:
[spca50x_move_data:1611] ISOC data error: [0] len=0, status=-18
<snip>
Looking at the code, I see
<snip>
static int
spca50x_move_data(struct usb_spca50x *spca50x, struct urb *urb)
{
unsigned char *cdata; //Pointer to buffer where we do store next
packet
unsigned char *pData; //Pointer to buffer where we do store next
packet
int i;
for (i = 0; i < urb->number_of_packets; i++) {
int datalength = urb->iso_frame_desc[i].actual_length;
int st = urb->iso_frame_desc[i].status;
unsigned long ms_times_now;
unsigned long ms_times_before;
struct spca50x_frame *frame; //Pointer to frame data
int sequenceNumber;
int sof;
int iPix; //Offset of pixel data in the ISO packet
if (st) {
PDEBUG(0, "ISOC data error: [%d] len=%d, status=%d
\n",
i, datalength, st);
continue;
}
cdata = ((unsigned char *) urb->transfer_buffer) +
<snip>
so the first number is the packet #, which I see 0 through 3 or 5 in my
logs. The error, which is the status, *if* errno.h has any relation, says
that it's an EXDEV, which suggests that it's trying to hard link across
devices, which AFAIK it's not: the home directory for the user the device
runs is is automounted, and it gets created there.
Anyone have any clues why, all of a sudden, the first few packets are
showing a status code? Could it be a timing issue?
mark
On Fri, 2010-06-11 at 16:15 -0400, m.roth at 5-cent.us wrote:> Irritating quirkyness: we have a bunch of videocams. To use, we use gspca. > Usually, on an upgrade, I just go into the gspca directory (which appears, > from their website, to have not been updated since '07), make clean, make, > make install. > > Having gone up to 5.5, did the same. What's happening now is that it > works, delivers the mpgs... but dumps errors in the logs: > <snip> > kernel: /usr/local/src/gspcav1-20071224/gspca_core.c: > [spca50x_move_data:1611] ISOC data error: [0] len=0, status=-18 > <snip> > Looking at the code, I see > <snip> > static int > spca50x_move_data(struct usb_spca50x *spca50x, struct urb *urb) > { > unsigned char *cdata; //Pointer to buffer where we do store next > packet > unsigned char *pData; //Pointer to buffer where we do store next > packet > int i; > for (i = 0; i < urb->number_of_packets; i++) { > int datalength = urb->iso_frame_desc[i].actual_length; > int st = urb->iso_frame_desc[i].status; > unsigned long ms_times_now; > unsigned long ms_times_before; > struct spca50x_frame *frame; //Pointer to frame data > int sequenceNumber; > int sof; > int iPix; //Offset of pixel data in the ISO packet > if (st) { > PDEBUG(0, "ISOC data error: [%d] len=%d, status=%d > \n", > i, datalength, st); > continue; > } > cdata = ((unsigned char *) urb->transfer_buffer) + > <snip> > so the first number is the packet #, which I see 0 through 3 or 5 in my > logs. The error, which is the status, *if* errno.h has any relation, says > that it's an EXDEV, which suggests that it's trying to hard link across > devices, which AFAIK it's not: the home directory for the user the device > runs is is automounted, and it gets created there. > > Anyone have any clues why, all of a sudden, the first few packets are > showing a status code? Could it be a timing issue? > > mark--- Well I find these things interesting. Could very well be timing in the frame buffers/packets. I'm guessing this is the newest latest kernel. I've seen somewhere this week somewhere on the web about a related issue. So guessing it works correctly on the previous kernel? Just something to ponder here is the machine really loaded heavily? I ask because if so the kernel can't function on "us" microsecond timing. It becomes very critical when it comes to that nature. Last thing is the timing routine function getting called in userspace or kernel? I have had my share of day to day problems like this. Last thing was anything in /etc/sysctl.conf changed? Finally whats nice is, it could have been coded to skip a frame sequence where the before and after timing did not match and you eye would never see it.. John
> On 14/06/10 18:58, m.roth at 5-cent.us wrote: >>> >>> The standalone gspca code is old and deprecated. It's now maintainedas part of the Video4Linux v4l-dvb tree here:>>> >>> http://linuxtv.org/<snip>> The main v4l-dvb tree is here - just grab the latest tarball and buildit. Here if you don't see it:> > http://linuxtv.org/hg/v4l-dvb/archive/tip.tar.bz2<snip>> Development work on the gspca branch appears to happen here: > > http://linuxtv.org/hg/~hgoede/gspca/ > > before being merged into the main v4l-dvb tree. > >>> Elrepo.org has a version built for el5 that supports many gspca baseddevices:>>> >>> http://elrepo.org/tiki/kmod-video4linux<snip> Ok, so I got the src rpm from el repo. Lessee, first I tried rpmbuild, and that failed, because it *required* xen-devel. So I grabbed the tarfile from /usr/src/redhat/SOURCES, unbzip2'd it, untar'd it, and did a make. And ten or so later, I had 265 kernel modules. I don't want or need to install all of that, so I tried just building gspca, and that failed with unresolved errors. Does anyone know if I can just install gspca*.ko, or even some subgroup of that, or is it dependent on other of the built modules? Two other notes: on an FC 13 box, I see that gspca literally comes with the kernel - does anyone have a clue whether part of that subsystem is available, or is that what I'm looking at, above? Finally, in googling, I found a UVC that's supposed to deal with most USB cameras. Does anyone know anything about it, or will I still need gspca? mark