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