From laurajames@attlabs.att.com Tue, 21 Nov 2000 13:39:57 -0800 Date: Tue, 21 Nov 2000 13:39:57 -0800 From: James, Laura laurajames@attlabs.att.com Subject: [cpia] usb errors using cpia/gqcam Hi, I'm using an Aiptek HyperVcam Fun on kernel 2.4.0test10. Gqcam appears to work fine with the kernel USB support and cpia. However, when I have run gqcam (even for just a few seconds), if I then do a dmesg, I get vast quantities of output ( >1k lines per second, AFAICT) which say: usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters and so on. I'm running this on a Sony Vaio PCG-505GX notebook, with an internal USB hub and no other external USB devices. The messages don't seem to cause any trouble but I'd like to find out if there's anything I can do to eliminate them, as in the future I'll be running gqcam for longer periods. Thanks, Laura From johannes@erdfelt.com Tue, 21 Nov 2000 16:59:58 -0500 Date: Tue, 21 Nov 2000 16:59:58 -0500 From: Johannes Erdfelt johannes@erdfelt.com Subject: [cpia] usb errors using cpia/gqcam On Tue, Nov 21, 2000, James, Laura wrote: > I'm using an Aiptek HyperVcam Fun on kernel 2.4.0test10. Gqcam appears to > work fine with the kernel USB support and cpia. > > However, when I have run gqcam (even for just a few seconds), if I then do a > dmesg, I get vast quantities of output ( >1k lines per second, AFAICT) which > say: > > usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters > usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters > usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters > usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters > usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters > usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters > > and so on. I'm running this on a Sony Vaio PCG-505GX notebook, with an > internal USB hub and no other external USB devices. > > The messages don't seem to cause any trouble but I'd like to find out if > there's anything I can do to eliminate them, as in the future I'll be > running gqcam for longer periods. Those aren't errors, but are for debugging. A patch has been submitted to 2.4.0-test11 which removes those messages. Or you can comment them out yourself. JE From Peter_Pregler@email.com Wed, 22 Nov 2000 11:24:43 +0100 Date: Wed, 22 Nov 2000 11:24:43 +0100 From: Peter Pregler Peter_Pregler@email.com Subject: [cpia] usb errors using cpia/gqcam Hi, thanx for the info, something to rule out in my debugging. I have got a second USB-cam now and tried it out with the latest 2.2.18pre. It does work if in the USB-tree the cameras are on different usb-buses (0x0553/0x0002 is the camera): root@gretel:~# lsusb -t Bus# 2 `-Dev# 1 Vendor 0x0000 Product 0x0000 `-Dev# 2 Vendor 0x058f Product 0x9254 `-Dev# 3 Vendor 0x0553 Product 0x0002 Bus# 1 `-Dev# 1 Vendor 0x0000 Product 0x0000 `-Dev# 2 Vendor 0x0553 Product 0x0002 But is does not work with the cameras on the same buses. The open of the second camera fails. root@gretel:~# lsusb -t Bus# 2 `-Dev# 1 Vendor 0x0000 Product 0x0000 `-Dev# 2 Vendor 0x058f Product 0x9254 |-Dev# 3 Vendor 0x0553 Product 0x0002 `-Dev# 4 Vendor 0x0553 Product 0x0002 Bus# 1 `-Dev# 1 Vendor 0x0000 Product 0x0000 I have yet to check what is really going on. Do you have any idea? How different it the usb-core code in 2.2.18pre and 2.4? Which of the usb-uhci drivers is to prefer to see if the problem is cpia or usb-core related? Greetings, Peter On Tue, Nov 21, 2000 at 04:59:58PM -0500, Johannes Erdfelt wrote: > On Tue, Nov 21, 2000, James, Laura wrote: > > I'm using an Aiptek HyperVcam Fun on kernel 2.4.0test10. Gqcam appears to > > work fine with the kernel USB support and cpia. > > > > However, when I have run gqcam (even for just a few seconds), if I then do a > > dmesg, I get vast quantities of output ( >1k lines per second, AFAICT) which > > say: > > > > usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters > > usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters > > usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters > > usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters > > usb.c: bandwidth alloc reduced by 75 to 75 for 1 requesters > > usb.c: bandwidth alloc increased by 75 to 150 for 2 requesters > > > > and so on. I'm running this on a Sony Vaio PCG-505GX notebook, with an > > internal USB hub and no other external USB devices. > > > > The messages don't seem to cause any trouble but I'd like to find out if > > there's anything I can do to eliminate them, as in the future I'll be > > running gqcam for longer periods. > > Those aren't errors, but are for debugging. A patch has been submitted > to 2.4.0-test11 which removes those messages. > > Or you can comment them out yourself. > > JE > > > _______________________________________________ > cpia mailing list - cpia@risc.uni-linz.ac.at > http://mailman.risc.uni-linz.ac.at/mailman/cgi-bin/listinfo/cpia > -- I will not waste chalk. --Bart Simpson at the blackboard -------------------------------------------------------- Email: Peter_Pregler@email.com WWW: http://www.risc.uni-linz.ac.at/people/ppregler ICQ: 61011460 From johannes@erdfelt.com Wed, 22 Nov 2000 11:41:30 -0500 Date: Wed, 22 Nov 2000 11:41:30 -0500 From: Johannes Erdfelt johannes@erdfelt.com Subject: [cpia] usb errors using cpia/gqcam On Wed, Nov 22, 2000, Peter Pregler wrote: > thanx for the info, something to rule out in my debugging. I have got > a second USB-cam now and tried it out with the latest 2.2.18pre. It > does work if in the USB-tree the cameras are on different usb-buses > (0x0553/0x0002 is the camera): > > root@gretel:~# lsusb -t > Bus# 2 > `-Dev# 1 Vendor 0x0000 Product 0x0000 > `-Dev# 2 Vendor 0x058f Product 0x9254 > `-Dev# 3 Vendor 0x0553 Product 0x0002 > Bus# 1 > `-Dev# 1 Vendor 0x0000 Product 0x0000 > `-Dev# 2 Vendor 0x0553 Product 0x0002 > > But is does not work with the cameras on the same buses. The open of > the second camera fails. > > root@gretel:~# lsusb -t > Bus# 2 > `-Dev# 1 Vendor 0x0000 Product 0x0000 > `-Dev# 2 Vendor 0x058f Product 0x9254 > |-Dev# 3 Vendor 0x0553 Product 0x0002 > `-Dev# 4 Vendor 0x0553 Product 0x0002 > Bus# 1 > `-Dev# 1 Vendor 0x0000 Product 0x0000 > > I have yet to check what is really going on. Do you have any idea? > How different it the usb-core code in 2.2.18pre and 2.4? Which of the > usb-uhci drivers is to prefer to see if the problem is cpia or > usb-core related? You can't use 2 cpia cameras on the same bus because there isn't enough bandwidth. The open failing is the USB core telling you that. It works on 2 busses because each bus has it's own bandwidth. JE From Peter_Pregler@email.com Thu, 23 Nov 2000 10:00:02 +0100 Date: Thu, 23 Nov 2000 10:00:02 +0100 From: Peter Pregler Peter_Pregler@email.com Subject: [cpia] usb errors using cpia/gqcam On Wed, Nov 22, 2000 at 11:41:30AM -0500, Johannes Erdfelt wrote: > > You can't use 2 cpia cameras on the same bus because there isn't enough > bandwidth. The open failing is the USB core telling you that. > It works on 2 busses because each bus has it's own bandwidth. A bandwidth traffic shaper was what I suspected. Thanx for the info. And of cause this answers the question for all guys that connect several cameras to a bus and had problems. Make sure that the open/close of the camera is serialized by software means. Hmmm, thinking of the following scenario I see no real need for such a hard limit. Imagine that you have ten webcams that take a picture every 10 seconds. It would be fine if the usb-system would allow the user to issue the requests and deliver the data with a unspecified bit rate (comparable to ATM-UBR ;). Or is the isochronous mode for USB we use (AFAIK) just capable of handling constant bit rate. Sorry for asking such simple questions but I am not that familiar with the usb-spec. In other words, is it possible to modify the cpia-driver to allocate and use the usb-bus in a less rigid way? Greetings, Peter -- I will not waste chalk. --Bart Simpson at the blackboard -------------------------------------------------------- Email: Peter_Pregler@email.com WWW: http://www.risc.uni-linz.ac.at/people/ppregler ICQ: 61011460 From johannes@erdfelt.com Thu, 23 Nov 2000 12:24:21 -0500 Date: Thu, 23 Nov 2000 12:24:21 -0500 From: Johannes Erdfelt johannes@erdfelt.com Subject: [cpia] usb errors using cpia/gqcam On Thu, Nov 23, 2000, Peter Pregler wrote: > On Wed, Nov 22, 2000 at 11:41:30AM -0500, Johannes Erdfelt wrote: > > > > You can't use 2 cpia cameras on the same bus because there isn't enough > > bandwidth. The open failing is the USB core telling you that. > > > It works on 2 busses because each bus has it's own bandwidth. > > A bandwidth traffic shaper was what I suspected. Thanx for the info. > And of cause this answers the question for all guys that connect > several cameras to a bus and had problems. Make sure that the > open/close of the camera is serialized by software means. > > Hmmm, thinking of the following scenario I see no real need for such a > hard limit. Imagine that you have ten webcams that take a picture > every 10 seconds. It would be fine if the usb-system would allow the > user to issue the requests and deliver the data with a unspecified bit > rate (comparable to ATM-UBR ;). Or is the isochronous mode for USB we > use (AFAIK) just capable of handling constant bit rate. Sorry for > asking such simple questions but I am not that familiar with the > usb-spec. In other words, is it possible to modify the cpia-driver to > allocate and use the usb-bus in a less rigid way? The USB spec mandates that certain transfers are guaranteed bandwidth. Isochronous is at the top of the list. The USB core enforces this. We could workaround this by postponing the transfer for Isochronous transfers, but it wouldn't be perfect. The CPiA camera doesn't start transferring data immediately so there will always be dead frames. I don't think you could get 10 cameras working like this tho. There may be another way. I'll have to think about it. The reason why it fails at open is because it tests one frame or something (I haven't looked at the code recently) at open and the bandwidth allocation fails. JE From Peter_Pregler@email.com Fri, 24 Nov 2000 08:57:46 +0100 Date: Fri, 24 Nov 2000 08:57:46 +0100 From: Peter Pregler Peter_Pregler@email.com Subject: [cpia] usb errors using cpia/gqcam On Thu, Nov 23, 2000 at 12:24:21PM -0500, Johannes Erdfelt wrote: > > We could workaround this by postponing the transfer for Isochronous > transfers, but it wouldn't be perfect. The CPiA camera doesn't start > transferring data immediately so there will always be dead frames. I > don't think you could get 10 cameras working like this tho. > > There may be another way. I'll have to think about it. Okay, maybe a better place to discuss this is the usb-list since this is something that affects all usb-video devices? Shall I raise the question there. > The reason why it fails at open is because it tests one frame or > something (I haven't looked at the code recently) at open and the > bandwidth allocation fails. Okay, I will check the error-handling of the driver. The correct error should be something like EBUSY. Thanx, Peter -- I will not waste chalk. --Bart Simpson at the blackboard -------------------------------------------------------- Email: Peter_Pregler@email.com WWW: http://www.risc.uni-linz.ac.at/people/ppregler ICQ: 61011460 From jylam@hangover.fr Sat, 25 Nov 2000 17:19:46 +0000 Date: Sat, 25 Nov 2000 17:19:46 +0000 From: jylam jylam@hangover.fr Subject: [cpia] device busy again ... Hi I made working my webcamII under linux using cpia drivers, but it worked only one time. I rebooted, then when I re-insmod'd drivers, I had this message : cpia_pp.o: init_module: Device or resource busy I *think* it comes from the parport_pc module (modprobe says that), but I can rmmod parport_pc (devive busy, yes, but by who ?) here are my logs , thanks a lot : dmesg : V4L-Driver for Vision CPiA based cameras v1.1.0 Parallel port driver for Vision CPiA based cameras v1.1.0 0 camera(s) found /var/log/messages: Nov 25 18:18:59 talisker kernel: V4L-Driver for Vision CPiA based cameras v1.1.0 Nov 25 18:18:59 talisker insmod: /lib/modules/2.2.5-22/misc/cpia_pp.o: unresolved symbol cpia_unregister_camera Nov 25 18:18:59 talisker insmod: /lib/modules/2.2.5-22/misc/cpia_pp.o: unresolved symbol cpia_register_camera Nov 25 18:18:59 talisker kernel: Parallel port driver for Vision CPiA based cameras v1.1.0 Nov 25 18:18:59 talisker kernel: 0 camera(s) found lsmod: Module Size Used by cpia 61308 0 videodev 2400 0 [cpia] lp 4412 1 (autoclean) parport_pc 5012 1 nfs 29944 1 (autoclean) lockd 30856 1 (autoclean) [nfs] sunrpc 52356 1 (autoclean) [nfs lockd] parport 7092 1 (autoclean) [lp parport_pc] eepro100 12112 1 (autoclean) es1371 23212 0 soundcore 2372 4 [es1371] -- ,-------------------. ,------------------. |Jean-Yves Lamoureux \___/ Jylam@hangover.fr | `-------------------------------^------------' Administrateur systeme Linux Hangover (http://www.hangover.fr) From bdjohns1@uiuc.edu Sun, 26 Nov 2000 23:22:11 -0600 Date: Sun, 26 Nov 2000 23:22:11 -0600 From: Ben Johnson bdjohns1@uiuc.edu Subject: [cpia] Compilation failure in 2.4.0-test11 / RH7 Hello, I just got an Ezonics USB cam (the one that was free after rebate at Best Buy over the Thanksgiving weekend), and I'm trying to get it working with the CPiA driver. I tried compiling it with the driver in the kernel (which reports itself as being v0.7.4, I think). This didn't work - I could modprobe the drivers (cpia, videodev, cpia_usb), but it didn't tell that it detected a camera, and gqcam said it couldn't find a device. I do have a /dev/video, linked to /dev/video0 (81,1) with approrpiate ownership. Next, I downloaded v1.1 from SourceForge. I changed the makefile to use kgcc (egcs 1.1.2) like the rest of the kernel, and got the following: kgcc -c -D_CPIA_DEBUG_ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -fomit-frame-pointer -fno-strength-reduce -I. -I/usr/src/linux/include -D__KERNEL__ -DMODULE -DCONFIG_VIDEO_CPIA_MODULE -DCONFIG_VIDEO_CPIA_PP_MODULE -DCONFIG_VIDEO_CPIA_PP_DMA -DCONFIG_VIDEO_CPIA_USB_MODULE cpia.c cpia.c: In function `uvirt_to_kva': cpia.c:272: invalid operands to binary | cpia.c: In function `rvmalloc': cpia.c:313: warning: implicit declaration of function `MAP_NR' cpia.c:313: invalid type argument of `->' cpia.c: In function `rvfree': cpia.c:341: invalid type argument of `->' {standard input}: Assembler messages: {standard input}:8: Warning: Ignoring changed section attributes for .modinfo make: *** [cpia.o] Error 1 I saw a post in the October archive with this same error, but I never saw a solution to the problem. Any help? Please CC responses to me, since I'm not subscribed to the list... --ben -- Ben Johnson email: bdjohns1@uiuc.edu web: http://www.uiuc.edu/~bdjohns1/