Hi, I was checking other v4l1 drivers for the hang-on-usb-disconnect problem I found in cpia and ov511 drivers, and it seems to me now that this is a bug breaking a number of driver's behavior under surprise camera disconnects. In official kernel 2.4.18 and earlier, there is a kernel lock in videodev.c:video_release(), which calls (a pointer to the) v4l close() function, but there is no lock in videodev.c:unregister_video_device(), which would allow the v4l close() function to also unregister the video device in the case where the camera was unplugged while open, as a number of drivers do. In the 2.4.18-5 RedHat kernel source, and official 2.4.19, 2.4.20, there is a new down(&videodev_lock) ... up(&videodev_lock) to replace the kernel lock in video_release() AND a similar lock now also added in video_unregister_device(). Is there any reason for this, or was it just over-zealous lock-adding that actually breaks the procedures for dealing with unplugged open devices? I know it breaks cpia and ov511, but studying the pwc-if code which is supposed to "do it correctly" it seems to me that that will be broken too..(since 2.4.19) Could someone test what actually happens when the usb cable is yanked on some other open webcams on 2.4.19 or later? Thanks Duncan. -------------------------- P.S.: a side issue: is it necessary to kfree(&cam->dev) where dev is the struct video_device, after it is unregistered? The pwc-if driver does this (and goes to great lengths to be able to do a postponed kfree() after unregistration, with its "mem_leak") mechanism if the camera was open when disconnected), but as far as I can see,no other v4l1 drivers seem to free the video_device struct in this way. Is it in fact necessary? On 09-Dec-2002 Duncan Haldane wrote: > > On 02-Dec-2002 Johannes Erdfelt wrote: >> On Mon, Dec 02, 2002, Duncan Haldane <f.duncan.m.haldane@xxxxxxxxxxxxxxxx> >> wrote: >>> If you have a USB webcam please let me know what happens if you >>> disconnect its usb cable while it is streaming images to a v4l viewer >>> (mine hangs) >> Sounds like a bug. I'll take the blame since I originally wrote the code >>:) >> >>> The same thing happens when I yank the usb cable of a running ov511 >>> cam, so its not just a cpia issue.... >>> (I only have cpia and ov511 cams to test with). >> >> Could be because ov511 was based on the original cpia code so it has the >> same bug? > > > AARGH!!! Yes!! After much wailing and gnashing of teeth I found why cpia > and ov511 drivers hang when the usb cable is yanked out while the camera > is open.... > > In both cases, in this special case, the unregister_video_device() call is > postponed to be the penultimate act of the [cpia,ov51x_v4l1]_close() > call.... > > BUT.... > > cpia_close is itself called by videodev.c:video_release() when the v4l app is > closed..., as follows: > > down(videodev_lock); > vfl->close(vfl); > up(videodev_lock); > > unfortunately, vfl->close is a pointer to cpia_close(), > which if it calls unregister_video_device(), hangs because > that also starts out with a > down(videodev_lock); ...... > > Moral: You can't postpone unregistering the video device > until the *_close() call.
