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: Fri, 09 Dec 2016 11:14:41 +0200 [thread overview]
Message-ID: <2080235.u14sVkzQLZ@avalon> (raw)
In-Reply-To: <20161209091113.GB27160@kroah.com>
Hi Greg,
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)
While the application is running, unplug the webcam, and then terminate the
application with ctrl-C.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2016-12-09 9:14 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 [this message]
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
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=2080235.u14sVkzQLZ@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).