John wrote:
On Fri, 2010-06-11 at 16:15 -0400, m.roth@5-cent.us wrote:
Irritating quirkyness: we have a bunch of videocams. To use, we use gspca.
<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?
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.
Yep - just upgraded the other day.
So guessing it works correctly on the previous kernel? Just something
Yep.
to ponder here is the machine really loaded heavily? I ask because if
Nope. Low loads, as well, according to top.
so the kernel can't function on "us" microsecond timing. It becomes very critical when it comes to that nature.
Right - my manager actually encouraged me to look at the code, and I was trying to recompile after putting a sleep(1) before any of the streaming is called, but I'm having all kinds of grief, since it can't find <unistd.h>, and when I put it in as #include "/usr/include/unistd.h", it spits out a ton of undefineds, and unuseds, etc.
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
Kernel. gspcs is a module, used by the motion daemon.
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..
Doesn't look like it - /etc/sysctl.conf is dated last Aug.
Thanks for the thoughts.
mark