Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1624365 > unrolled thread

Re: uvcvideo logging kernel warnings on device disconnect

Started byLaurent Pinchart <laurent.pinchart@ideasonboard.com>
First post2017-04-16 13:20 +0200
Last post2017-04-17 15:00 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: uvcvideo logging kernel warnings on device disconnect Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-04-16 13:20 +0200
    Re: uvcvideo logging kernel warnings on device disconnect Daniel Axtens <dja@axtens.net> - 2017-04-17 11:00 +0200
      Re: uvcvideo logging kernel warnings on device disconnect Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-04-17 15:00 +0200

#1624365 — Re: uvcvideo logging kernel warnings on device disconnect

FromLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Date2017-04-16 13:20 +0200
SubjectRe: uvcvideo logging kernel warnings on device disconnect
Message-ID<twQnO-302-55@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#1624610

FromDaniel Axtens <dja@axtens.net>
Date2017-04-17 11:00 +0200
Message-ID<txaFQ-70u-7@gated-at.bofh.it>
In reply to#1624365
Hi,

>> > 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 ? :-)

I stumbled across this problem independently, and with the help of some
of the info on this thread (especially yavta), I have what I think is a
solution: https://patchwork.kernel.org/patch/9683663/

Regards,
Daniel

[toc] | [prev] | [next] | [standalone]


#1624666

FromLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Date2017-04-17 15:00 +0200
Message-ID<txeq6-Jw-5@gated-at.bofh.it>
In reply to#1624610
Hi Daniel,

On Monday 17 Apr 2017 18:57:57 Daniel Axtens wrote:
> Hi,
> 
> >> > 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 ? :-)
> 
> I stumbled across this problem independently, and with the help of some
> of the info on this thread (especially yavta), I have what I think is a
> solution: https://patchwork.kernel.org/patch/9683663/

Thank you for that !

I've reviewed your patch. Greg, there's a question for you in my reply, could 
you have a look when you'll have time ?

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web