From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Greg KH <greg@kroah.com>
Cc: Dave Stevenson <linux-media@destevenson.freeserve.co.uk>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: uvcvideo logging kernel warnings on device disconnect
Date: Sun, 16 Apr 2017 14:11:31 +0300 [thread overview]
Message-ID: <8113252.R6OEHK1FMB@avalon> (raw)
In-Reply-To: <20161221095954.GG27395@kroah.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
next prev parent reply other threads:[~2017-04-16 11:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ab3241e7-c525-d855-ecb6-ba04dbdb030f@destevenson.freeserve.co.uk>
2016-12-08 23:09 ` uvcvideo logging kernel warnings on device disconnect Laurent Pinchart
2016-12-09 7:25 ` Greg KH
2016-12-09 8:59 ` Laurent Pinchart
2016-12-09 9:11 ` Greg KH
2016-12-09 9:14 ` Laurent Pinchart
2016-12-09 9:43 ` Greg KH
2016-12-20 11:19 ` Dave Stevenson
2016-12-21 9:59 ` Greg KH
2017-04-16 11:11 ` Laurent Pinchart [this message]
2017-04-17 8:57 ` Daniel Axtens
2017-04-17 12:57 ` Laurent Pinchart
2017-04-30 16:19 ` Greg KH
2017-04-30 16:20 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8113252.R6OEHK1FMB@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@destevenson.freeserve.co.uk \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).