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@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
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
On Fri, 2010-06-11 at 17:10 -0400, m.roth@5-cent.us wrote:
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.
Umm, you never want to do that (sleep) in imaging. You can fill a buffer and reassemble the frames/packets in there order cpu intensive dearly it is. Your better to skip the frames because the human eye can never see it. Believe it or not medical imaging takes on this method and lives get saved every day from tomography/mri/cat/ultra sound scans in real time.
Check out the load when it starts streaming.
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.
Quick Search found this for el5. You could get the src rpm and rebuild it for all machines. Or test a binary out first with one. No idea the version that was compiled or against what just found it. http://atrpms.net/dist/el5/gspca/
You know 2007 is a good while ago and there are many compiler changes in between the time. I say it may be something getting introduced from the current compiler methods that is not supported now.
John
On 06/11/2010 10:38 PM, JohnS wrote:
On Fri, 2010-06-11 at 17:10 -0400, m.roth@5-cent.us wrote:
Kernel. gspcs is a module, used by the motion daemon.
Quick Search found this for el5. You could get the src rpm and rebuild it for all machines. Or test a binary out first with one. No idea the version that was compiled or against what just found it. http://atrpms.net/dist/el5/gspca/
You know 2007 is a good while ago and there are many compiler changes in between the time. I say it may be something getting introduced from the current compiler methods that is not supported now.
The standalone gspca code is old and deprecated. It's now maintained as part of the Video4Linux v4l-dvb tree here:
Elrepo.org has a version built for el5 that supports many gspca based devices:
http://elrepo.org/tiki/kmod-video4linux
The most recent version, compiled from a 2010-04-10 snapshot, is in the testing repo here:
http://elrepo.org/linux/testing/el5/
if you are looking for newer drivers.
On 06/11/2010 10:38 PM, JohnS wrote:
On Fri, 2010-06-11 at 17:10 -0400, m.roth@5-cent.us wrote:
Kernel. gspcs is a module, used by the motion daemon.
Quick Search found this for el5. You could get the src rpm and rebuild it for all machines. Or test a binary out first with one. No idea the version that was compiled or against what just found it. http://atrpms.net/dist/el5/gspca/
You know 2007 is a good while ago and there are many compiler changes in between the time. I say it may be something getting introduced from the current compiler methods that is not supported now.
Compiler changes shouldn't make a difference, and I haven't heard of any major revision.
<side rant>"methods" - since it's C, I *assume* that what's meant are function calls....</side rant>
I know it's old, and was surprised that it hadn't been updated since my manager brought it down a few years ago. I didn't see anything mentioning where else to go.
The standalone gspca code is old and deprecated. It's now maintained as part of the Video4Linux v4l-dvb tree here:
Thanks. However, that's not an overly friendly site for non-project developers - don't see any current tarballs, for poor, overworked systems administrators to d/l and build. Do you know what I might need to be able to run the motion daemon? All I've seen are vcs/mercurial, or git or whatever repositories, and I do *not* see "version x.y.z stable", or "current release". I know my manager's willing to let me look at smaller stuff, but not to spend days on building and debugging (whether or not I'd like to, I've got other stuff to do).
Elrepo.org has a version built for el5 that supports many gspca based devices:
Don't need new versions, our video cams are years old, and inexpensive. We want stable. However, do you have a clue as to what the el repo package was built from? I just checked a CentOS mirror, and couldn't find either video4linux, or v4l*.
mark
On 14/06/10 18:58, m.roth@5-cent.us wrote:
The standalone gspca code is old and deprecated. It's now maintained as part of the Video4Linux v4l-dvb tree here:
Thanks. However, that's not an overly friendly site for non-project developers - don't see any current tarballs, for poor, overworked systems administrators to d/l and build. Do you know what I might need to be able to run the motion daemon? All I've seen are vcs/mercurial, or git or whatever repositories, and I do *not* see "version x.y.z stable", or "current release". I know my manager's willing to let me look at smaller stuff, but not to spend days on building and debugging (whether or not I'd like to, I've got other stuff to do).
AFAIK it's rolling development, so just grab the latest snapshot. At present the v4l-dvb tree is largely maintained by Douglas Schilling Landgraf and the gspca tree by Hans de Goede, both of Red Hat.
The main v4l-dvb tree is here - just grab the latest tarball and build it. Here if you don't see it:
http://linuxtv.org/hg/v4l-dvb/archive/tip.tar.bz2
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 based devices:
Don't need new versions, our video cams are years old, and inexpensive. We want stable. However, do you have a clue as to what the el repo package was built from? I just checked a CentOS mirror, and couldn't find either video4linux, or v4l*.
Isn't it obvious from the package names?
For example, kmod-video4linux-0.0-7.20100410.el5.elrepo is build from the v4l-dvb source code snaphot dated 2010-04-10.
On 14/06/10 18:58, m.roth@5-cent.us wrote:
The standalone gspca code is old and deprecated. It's now maintained as part of the Video4Linux v4l-dvb tree here:
Thanks. However, that's not an overly friendly site for non-project developers - don't see any current tarballs, for poor, overworked systems administrators to d/l and build. Do you know what I might need to be able to run the motion daemon? All I've seen are vcs/mercurial, or git or whatever repositories, and I do *not* see "version x.y.z stable", or "current release". I know my manager's willing to let me look at smaller stuff, but not to spend days on building and debugging (whether or not I'd like to, I've got other stuff to do).
AFAIK it's rolling development, so just grab the latest snapshot. At present the v4l-dvb tree is largely maintained by Douglas Schilling Landgraf and the gspca tree by Hans de Goede, both of Red Hat.
I have absolutely no intention of taking the latest snapshot. Did you just skim over the last sentence I wrote, above? I don't need anything LATEST AND GREATEST, I just want something ->STABLE<- that will run the bloody old Labtech (Labtek?) cameras, and *not* spit out pointless error messages.
By the way, what is "rolling development"? Does this mean that there are *no* releases, or version numbers? If so, how can I tell what was the last stable version, and what is where they started adding features for the next release?
The main v4l-dvb tree is here - just grab the latest tarball and build it. Here if you don't see it:
When you say "latest", do you mean the last stable version, or what somebody checked in last night (or just before lunch today)?
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 based devices:
Don't need new versions, our video cams are years old, and inexpensive. We want stable. However, do you have a clue as to what the el repo package was built from? I just checked a CentOS mirror, and couldn't find either video4linux, or v4l*.
Isn't it obvious from the package names?
For example, kmod-video4linux-0.0-7.20100410.el5.elrepo is build from the v4l-dvb source code snaphot dated 2010-04-10.
So I just need that, and *not* the apps? I mean, gspca is a video driver that motion can use.
mark
On 14/06/10 20:24, m.roth@5-cent.us wrote:
I have absolutely no intention of taking the latest snapshot. Did you just skim over the last sentence I wrote, above? I don't need anything LATEST AND GREATEST, I just want something ->STABLE<- that will run the bloody old Labtech (Labtek?) cameras, and *not* spit out pointless error messages.
It may be latest and greatest, but it is also hopefully the most stable version as a lot of the development work done involves fixing bugs, and that's generally how software becomes more stable. If you're getting errors, try reporting them upstream - in my experience they are very swiftly fixed.
All this started because JohnS and yourself were talking about the old gspca driver that is deprecated, and over 4 years old now. All I'm trying to say is if you need a driver for gspca, don't use that (old unsupported) one, use this (newer supported) one.
By the way, what is "rolling development"? Does this mean that there are *no* releases, or version numbers? If so, how can I tell what was the last stable version, and what is where they started adding features for the next release?
There is no last stable version, releases or version numbers in much the same way that the kernel has no version numbers for the vast majority of individual drivers it contains. People fix bugs and add features as necessary on a continual basis. Rhetorical: What would you propose - every Monday at noon everything stops for an hour while they take a snapshot and call it "STABLE". That is what I mean by rolling development.
But as you run Enterprise Linux, and are rightly concerned with stability, rather than update your whole kernel to the latest and greatest, ELRepo gives you the opportunity to retain your stable Enterprise Linux kernel and run *only* the updated hardware drivers that you need to support hardware that isn't directly supported by your stable Enterprise Linux kernel.
<snip>
So I just need that, and *not* the apps? I mean, gspca is a video driver that motion can use.
Yes, gspca is the driver for the webcam. The apps live in a separate branch here:
http://linuxtv.org/hg/dvb-apps/
which you can build/package separately if you need them. ELRepo don't build/offer them as they are not kernel drivers.
Ned wrote:
On 14/06/10 20:24, m.roth@5-cent.us wrote:
By the way, what is "rolling development"? Does this mean that there are *no* releases, or version numbers? If so, how can I tell what was the last stable version, and what is where they started adding features for the next release?
There is no last stable version, releases or version numbers in much the same way that the kernel has no version numbers for the vast majority of individual drivers it contains. People fix bugs and add features as necessary on a continual basis. Rhetorical: What would you propose - every Monday at noon everything stops for an hour while they take a snapshot and call it "STABLE". That is what I mean by rolling development.
In fact, done having (among many other hats) been software configuration management for something like a dozen years, in companies ranging from a microscopic one with 12 folks to moderate group in Ameritech (a Baby Bell), that's EXACTLY what I'd do... except you seem to have missed the part where each module was tested, first separately, then integration test, and it all works, bugs that were scheduled to be fixed in this release fixed, all new features scheduled for this release in, and *that's* where the snapshot's done.
Y'know, sort of like, um, the CentOS 5.5 release. <snip> mark
-
JohnS -
m.roth＠5-cent.us -
Ned Slider