Re: uvcvideo logging kernel warnings on device disconnect

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Greg,

On Wednesday 21 Dec 2016 10:59:54 Greg KH wrote:
> On Tue, Dec 20, 2016 at 11:19:23AM +0000, Dave Stevenson wrote:
> > On 09/12/16 09:43, Greg KH wrote:
> >> On Fri, Dec 09, 2016 at 11:14:41AM +0200, Laurent Pinchart wrote:
> >>> On Friday 09 Dec 2016 10:11:13 Greg KH wrote:
> >>>> On Fri, Dec 09, 2016 at 10:59:24AM +0200, Laurent Pinchart wrote:
> >>>>> On Friday 09 Dec 2016 08:25:52 Greg KH wrote:
> >>>>>> On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> >>>>>>> On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
> >>>>>>>> Hi All.
> >>>>>>>> 
> >>>>>>>> I'm working with a USB webcam which has been seen to
> >>>>>>>> spontaneously disconnect when in use. That's a separate
> >>>>>>>> issue, but when it does it throws a load of warnings into
> >>>>>>>> the kernel log if there is a file handle on the device open
> >>>>>>>> at the time, even if not streaming.
> >>>>>>>> 
> >>>>>>>> I've reproduced this with a generic Logitech C270 webcam on:
> >>>>>>>> - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the
> >>>>>>>> latest media tree from linuxtv.org
> >>>>>>>> - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
> >>>>>>>> - an old 3.10.x tree on an embedded device.
> >>>>>>>> 
> >>>>>>>> To reproduce:
> >>>>>>>> - connect USB webcam.
> >>>>>>>> - run a simple app that opens /dev/videoX, sleeps for a
> >>>>>>>> while, and then closes the handle.
> >>>>>>>> - disconnect the webcam whilst the app is running.
> >>>>>>>> - read kernel logs - observe warnings. We get the disconnect
> >>>>>>>> logged as it occurs, but the warnings all occur when the
> >>>>>>>> file descriptor is closed. (A copy of the logs from my
> >>>>>>>> Ubuntu 14.04 machine are below).
> >>>>>>>> 
> >>>>>>>> I can fully appreciate that the open file descriptor is
> >>>>>>>> holding references to a now invalid device, but is there a
> >>>>>>>> way to avoid them? Or do we really not care and have to put
> >>>>>>>> up with the log noise when doing such silly things?
> >>>>>>> 
> >>>>>>> This is a known problem, caused by the driver core trying to
> >>>>>>> remove the same sysfs attributes group twice.
> >>>>>> 
> >>>>>> Ick, not good.
> >>>>>> 
> >>>>>>> The group is first removed when the USB device is
> >>>>>>> disconnected. The input device and media device created by the
> >>>>>>> uvcvideo driver are children of the USB interface device,
> >>>>>>> which is deleted from the system when the camera is unplugged.
> >>>>>>> Due to the parent-child relationship, all sysfs attribute
> >>>>>>> groups of the children are removed.
> >>>>>> 
> >>>>>> Wait, why is the USB device being removed from sysfs at this
> >>>>>> point, didn't the input and media subsystems grab a reference to
> >>>>>> it so that it does not disappear just yet?
> >>>>> 
> >>>>> References are taken in uvc_prove():
> >>>>>         dev->udev = usb_get_dev(udev);
> >>>>>         dev->intf = usb_get_intf(intf);
> >>>> 
> >>>> s/uvc_prove/uvc_probe/ ?  :)
> >>> 
> >>> Oops :-)
> >>> 
> >>>>> and released in uvc_delete(), called when the last video device
> >>>>> node is closed. This prevents the device from being released
> >>>>> (freed), but device_del() is synchronous to device unplug as far
> >>>>> as I understand.
> >>>> 
> >>>> Ok, good, that means the UVC driver is doing the right thing here.
> >>>> 
> >>>> But the sysfs files should only be attempted to be removed by the
> >>>> driver core once, when the device is removed from sysfs, not twice,
> >>>> which is really odd.
> >>>> 
> >>>> Is there a copy of the "simple app that grabs the device node"
> >>>> anywhere so that I can test it out here with my USB camera device to
> >>>> try to track down where the problem is?
> >>> 
> >>> Sure. The easiest way is to grab http://git.ideasonboard.org/yavta.git
> >>> and run
> >>> 
> >>> yavta -c /dev/video0
> >>> 
> >>> (your mileage may vary if you have other video devices)
> >> 
> >> I'll point it at the correct device, /dev/video0 is built into this
> >> laptop and can't be physically removed :)
> >> 
> >>> While the application is running, unplug the webcam, and then
> >>> terminate the application with ctrl-C.
> >> 
> >> Ok, will try this out this afternoon and let you know how it goes.
> > 
> > I hate to pester, but wondered if you had found anything obvious.
> > I really do appreciate you taking the time to look.
> 
> Sorry, I haven't had the chance and now will not be able to until
> January....

Did you mean January 2017 or 2018 ? :-)

-- 
Regards,

Laurent Pinchart