[cpia] Creative Webcam II: 2.4.20 crashes when loading cpia.o

Duncan Haldane f.duncan.m.haldane@worldnet.att.net
Tue, 17 Dec 2002 23:21:02 -0500 (EST)


On 17-Dec-2002 Torben Weibert wrote:
>> Which driver source are you using?
>> did it:
>> --come with the kernel
>> --come as a tarball from the sourceforge site (which version)
>> -- is it the cvs "kernel-source-2.4" source I posted about
>>   yesterday?
> 
> It's the driver that came with the 2.4.20 kernel.
>

I tested the patched driver for 2.4.20 (in CVS as "
kernel-source-2.4") with a parallel port Webcam II 
on a machine with TRISTATE but no ECP capability.
(My machines all have EPP not ECP parports, I wonder if its easy
to make the cpia drive use EPP?)
 
It worked without any crashes, though the image was very slow, 
about one frame per two seconds, and the X-display als became very
unresponsive while "streaming" was taking place.   I guess this 
was because I was not using ECP mode.

But the driver is working.  

I guess I should have tested the
unpatched 2.4.20 code to see if it caused a hang.  There was
a change in the Video4Linux interface in 2.4.19 that may have
broken some things.....  It did break how the usb cpia driver
handles a "hot unplugging" event when the cable is yanked while
the camera is running (=nasty hang because of new conflicting
locks in videodev.c)    My updates fix this by converting
the cpia derive to the new V4L interface.  Maybe the parport
stuf got broken too? In that case my patches to use the new
V4L interface will also fix this.

Duncan.


Note.  RedHat 7.x and 8.x is using a patch 2.4.18 kernel 
which patched in the new V4L interface from one of the
2.4.18-ac* kernels.  Unfortunately, it is partially broken
in RedHat 2.4.18 (but works in the 2.4.19 official kernel)
so you need to use the older version of the driver.     To avoid the
"hot-usb-unplug hang", you need to patch videodev.c in 
RedHat 2.4.18 kernels.

Here is the patch from Gerd Knorr: ( I guess it will apply to
Red Hat 2.4.18 patched kernel sources) 2.4.18)
The (newly added in 2.4.19) "down(&videodev_lock)" before the 
"vfl->close" is quite fatal in the event of a hot-unplug....
(vfl->close is NULL when the driver uses the new V4L interface)
==============================[ cut here ]==============================
--- videodev.c.lock     2002-12-10 11:06:04.000000000 +0100
+++ videodev.c  2002-12-10 11:21:44.000000000 +0100
@@ -187,13 +187,19 @@
 {
        struct video_device *vfl;
 
-       down(&videodev_lock);
        vfl = video_devdata(file);
        if(vfl->close)
                vfl->close(vfl);
-       vfl->users--;
-       if(vfl->owner)
-               __MOD_DEC_USE_COUNT(vfl->owner);
+
+       down(&videodev_lock);
+       /* ->close() might have called video_device_unregister()
+           in case of a hot unplug, thus we have to get vfl again */
+       vfl = video_devdata(file);
+       if (NULL != vfl) {
+               vfl->users--;
+               if(vfl->owner)
+                       __MOD_DEC_USE_COUNT(vfl->owner);
+       }
        up(&videodev_lock);
        return 0;
 }
=================================================